`Petitioners’ Reply
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`FACEBOOK, INC., WHATSAPP, INC., HUAWEI DEVICE CO., LTD., LG
`ELECTRONICS, INC.,1
`Petitioner
`
`v.
`
`UNILOC USA, INC. and UNILOC LUXEMBOURG S.A.,
`Patent Owner.
`
`
`Case IPR2017-01667
`Patent 8,724,622 B2
`
`
`PETITIONERS’ REPLY
`
`
`
`
`
`
`1 Huawei Device Co., Ltd. and LG Electronics, Inc., which filed a petition in Case
`
`IPR2017-02090, have been joined as petitioners in this proceeding.
`
`
`
`
`
`TABLE OF CONTENTS
`
`
`Page
`
`
`I.
`
`II.
`
`CLAIM CONSTRUCTION ........................................................................... 1
`A.
`“Instant Voice Message” Is Not Limited to an “Audio File” .............. 2
`CLAIMS 3, 6-8, 10, 11, 13, 14-23, 27-35, 38 and 39 ARE
`UNPATENTABLE ......................................................................................... 6
`A.
`Zydney Discloses Attaching One or More Files to the Instant
`Voice Message ..................................................................................... 6
`Zydney Discloses the “Instant Voice Messaging Application,”
`“Client Platform System” and “Communication Platform
`System” Even Under Patent Owner’s Proposed Claim
`Interpretation ........................................................................................ 8
`Zydney Discloses and Renders Obvious “wherein the instant
`voice message includes an object field including a digitized
`audio file” (independent claim 3) ....................................................... 11
`Zydney and Clark Disclose and Render Obvious the “Message
`Database” Limitations ........................................................................ 16
`1.
`Patent Owner Improperly Attacks the References
`Individually .............................................................................. 17
`Patent Owner Relies On an Incorrect Claim Construction
`Regarding “Database Record” ................................................. 18
`Even Under Patent Owner’s Incorrect Claim
`Construction, Clark Discloses the Claimed “Database
`Record” .................................................................................... 21
`Clark’s Database Disclosures Do Not Teach Away From
`Zydney ................................................................................................ 22
`Clark Does Not Teach Away From Zydney and The
`Combination of Clark and Zydney is Not Inoperable ........................ 22
`Claims 38 and 39 are Obvious ........................................................... 23
`F.
`III. CONCLUSION ............................................................................................. 26
`
`
`
`B.
`
`B.
`
`C.
`
`2.
`
`3.
`
`D.
`
`E.
`
`
`
`
`
`
`
`‐i‐
`
`
`
`
`
`TABLE OF AUTHORITIES
`
`Page(s)
`
`
`Cases
`Allied Erecting & Dismantling Co. v. Genesis Attachments, LLC,
`825 F.3d 1373 (Fed. Cir. 2016) .................................................................... 13, 18
`Anchor Wall Sys., Inc. v. Rockwood Retaining Walls, Inc.,
`340 F.3d 1298 (Fed. Cir. 2003) ............................................................................ 5
`Epos Techs. Ltd. v. Pegasus Techs. Ltd.,
`766 F.3d 1338 (Fed. Cir. 2014) ............................................................................ 5
`In re Keller,
`642 F.2d 413 (C.C.P.A. 1981) ............................................................................ 14
`MCM Portfolio LLC v. Hewlett-Packard Co.,
`812 F.3d 1284 (Fed. Cir. 2015) .................................................................... 14, 18
`In re Merck & Co., Inc.,
`800 F.2d 1091 (Fed. Cir. 1986) .............................................................. 13, 18, 26
`In re Mouttet,
`686 F.3d 1322 (Fed. Cir. 2012) .................................................................... 14, 18
`Paice LLC v. Ford Motor Co.,
`681 F. App’x 904 (Fed. Cir. 2017) ....................................................................... 9
`Statutes
`35 U.S.C. § 103 ........................................................................................................ 26
`Other Authorities
`U.S. Patent No. 8,199,747 .......................................................................................... 5
`U.S. Patent No. 8,724,622 .................................................................................passim
`
`
`
`
`
`
`
`
`‐ii‐
`
`
`
`
`
`IPR2017-01667
`Petitioners’ Reply
`
`
`
`Petitioners Facebook, Inc. and WhatsApp, Inc. (“Petitioners”) respectfully
`
`submit this Reply in support of Inter Partes Review of claims 3, 6-8, 10, 11, 13,
`
`14-23, 27-35, 38 and 39 of U.S. Patent No. 8,724,622 (Ex. 1001) (“’622 patent”)
`
`and to address Patent Owner’s Response (Paper 17 (“Response”)).
`
`Petitioners note that the issues in this proceeding overlap with the issues in
`
`IPR2017-01668 where the challenged claims include claims 4, 5, and 12, which
`
`depend directly or indirectly from claim 3 challenged in the present case.
`
`Patent Owner’s Response rehashes the same arguments from its Preliminary
`
`Response that the Board already considered and rejected in its Institution Decision
`
`(Paper 8). The Board was not persuaded by Patent Owner’s arguments on the
`
`record existing at the time of institution, and the evidentiary record has not
`
`materially changed since that time. Patent Owner did not submit any new expert
`
`declaration or documents with its post-institution Response.
`
`Patent Owner largely ignores the Board’s detailed analysis and instead
`
`recycles the same unpersuasive arguments from its pre-institution submission. The
`
`Patent Owner does not identify any error in the Board’s reasoning, let alone
`
`provide any basis for the Board to depart from the reasoned Institution Decision.
`
`I.
`
`CLAIM CONSTRUCTION
`In its Institution Decision, the Board determined that no express claim
`
`constructions were necessary. (Paper 8 at 9.) Under the plain and ordinary
`
`‐1‐
`
`
`
`
`
`
`IPR2017-01667
`Petitioners’ Reply
`
`
`meaning of the claim language, claims 3, 6-8, 10, 11, 13, 14-23, 27-35, 38 and 39,
`
`are unpatentable as obvious over the prior art.
`
`A.
`“Instant Voice Message” Is Not Limited to an “Audio File”
`Patent Owner erroneously contends that an “instant voice message,” at least
`
`as recited in independent claim 27, must be limited to “an audio file recording
`
`voice data.” (Response at 13 (“the recitation ‘attaching one or more files to the
`
`instant voice message’ requires attaching one or more files to the audio file
`
`recording voice data”) (italics in original, underlining added).) Patent Owner’s
`
`narrow construction equating “instant voice message” with “audio file recording
`
`voice data” is not required by the intrinsic evidence, and is not the broadest
`
`reasonable interpretation of the claim language.
`
`The claim language does not support Patent Owner’s erroneous narrow
`
`interpretation. The ’622 patent claims at issue merely recite an “instant voice
`
`message” without specifying that it must be an “audio file.” On the contrary, the
`
`claims recite that a “file” can be attached to an instant voice message, suggesting
`
`that the instant voice message need not be a “file.” (’622, claim 26 (“attaching one
`
`or more files to the instant voice message”).) Patent Owner cites a claim recitation
`
`“instant voice messages recorded by a user” (Response at 11 (emphasis in
`
`original)), but that does not require the entire instant voice message to be only
`
`audio file recording voice data, as opposed to another type of file or data item that
`
`‐2‐
`
`
`
`
`
`
`IPR2017-01667
`Petitioners’ Reply
`
`
`contains recorded voice content and that may also contain other information. In
`
`fact, claim 32 (which depends from claim 27) recites “creating an audio file for the
`
`instant voice message,” thereby distinguishing the “instant voice message” from
`
`the “audio file” and confirming that “instant voice message” is not synonymous
`
`with “an audio file recording voice data.” If every “instant voice message” was
`
`limited to an audio file as Patent Owner contends, then the recitation of creating an
`
`audio file “for the instant voice message” would be superfluous.
`
`The specification also does not support Patent Owner’s
`
`incorrect
`
`construction. Patent Owner cites an exemplary embodiment where the instant
`
`voice message may take the form of an audio file. (Response at 12-13.) But that
`
`is merely one disclosed embodiment. The challenged claims are not limited to that
`
`embodiment, especially under the broadest reasonable interpretation. In fact, in
`
`another preferred embodiment using an “intercom mode,” the “instant voice
`
`message” specifically is not an audio file and instead takes the form of a buffered
`
`transmission:
`
`[T]he instant voice messaging system 200 also supports an “intercom
`mode” of voice messaging. The “intercom mode” represents real-time
`instant voice messaging. In the “intercom mode,” instead of creating
`an audio file 210, one or more buffers (not shown) of a predetermined
`size are generated in the IVM client 206, 208 or local IVM server 202.
`The one or more buffers are used to automatically write successive
`‐3‐
`
`
`
`
`
`
`
`
`IPR2017-01667
`Petitioners’ Reply
`
`
`
`portions of the instant voice message. . . . If the entire instant voice
`message or a successive portion thereof (such as a last successive
`portion in the instant voice message) written to either buffer is smaller
`[than] the predetermined size, then the buffered content of less than
`the predetermined size is automatically transmitted to the IVM
`server 202. The foregoing buffering using the first and second buffers
`is repeated until the entire instant voice message has been transmitted
`to the IVM server 202 for transmission to the one or more IVM
`recipients. . . . The foregoing buffering and transmission allows a
`“real-time” instant voice message to be transmitted to the one or more
`IVM recipients.
`
`(’622, 11:32-61 (underlining added).) Here, claim 36 (which depends from claim
`
`27) specifies “the instant voice messaging application communicates in an
`
`intercom mode when a recipient . . . is currently available to receive the instant
`
`voice message” (’622, 27:1-4), indicating that the “instant voice message” recited
`
`in independent claim 27 must encompass an “intercom mode.” But Patent
`
`Owner’s proposed claim construction that an “instant voice message” must be an
`
`“audio file” would exclude the “intercom mode” preferred embodiment in the
`
`specification. A “claim construction that excludes a preferred embodiment . . . is
`
`rarely, if ever correct and would require highly persuasive evidentiary support.”
`
`Epos Techs. Ltd. v. Pegasus Techs. Ltd., 766 F.3d 1338, 1347 (Fed. Cir. 2014)
`
`(quoting Anchor Wall Sys., Inc. v. Rockwood Retaining Walls, Inc., 340 F.3d 1298,
`
`
`
`
`
`‐4‐
`
`
`
`
`
`IPR2017-01667
`Petitioners’ Reply
`
`
`1308 (Fed. Cir. 2003)). Thus, at most, the specification identifies an “audio file”
`
`as an illustrative example of an instant voice message in one embodiment among
`
`multiple alternative embodiments.
`
`Patent Owner also points to a related patent, U.S. Patent No. 8,199,747,
`
`where institution was denied over prior art Zydney in IPR2017-01257. (Response
`
`at 16-17.) But that patent only illustrates why it would be incorrect to construe
`
`“instant voice message” as “an audio file recording voice data.” The ’747 patent
`
`contains the same written description as the ’622 patent. Claim 1 of the ’747
`
`patent recites: “generating an instant voice message, wherein generating includes
`
`recording the instant voice message in an audio file and attaching one or more files
`
`to the audio file.” (IPR2017-01257, Ex. 1001, claim 1 (emphasis added).) This
`
`language again distinguishes the “instant voice message” from the “audio file” and
`
`confirms that “instant voice message” is not synonymous with “an audio file
`
`recording voice data.” As noted above, if every “instant voice message” was
`
`limited to an audio file, then the recitation of recording the instant voice message
`
`“in an audio file” would be superfluous.
`
`Therefore, Patent Owner’s proposed construction should be rejected and the
`
`term “instant voice message” can be left to its plain and ordinary meaning,
`
`encompassing the instant voice messages disclosed by Zydney. (Petition at 24-28.)
`
`
`
`
`
`‐5‐
`
`
`
`
`
`IPR2017-01667
`Petitioners’ Reply
`
`
`
`Patent Owner’s additional claim construction positions are addressed below
`
`where applicable. As shown below, even under those proposed constructions, the
`
`prior art still discloses and renders obvious the challenged claims.
`
`II. CLAIMS 3, 6-8, 10, 11, 13, 14-23, 27-35, 38 AND 39 ARE
`UNPATENTABLE
`A. Zydney Discloses Attaching One or More Files to the Instant
`Voice Message
`Based on its erroneous claim construction that “instant voice message”
`
`means “an audio file recording voice data,” Patent Owner argues that Zydney does
`
`not disclose “attaching one or more files to the instant voice message” as recited in
`
`claim 27. (Response at 15-21.) Patent Owner’s argument is premised on its
`
`incorrect claim interpretation: it contends that the claim requires attaching one or
`
`more files “to an audio file recording voice data” (id. at 15) and asserts that the
`
`“voice container” disclosed in Zydney does not disclose an “instant voice
`
`message” under Patent Owner’s construction (id. at 15-18).
`
`However, as discussed previously as a matter of claim construction, an
`
`“instant voice message” is not limited to “an audio file recording voice data.”
`
`Zydney’s voice container discloses an “instant voice message” under the plain and
`
`ordinary meaning of the term. (Petition at 27-28.) As the Petition explained,
`
`Zydney discloses that voice containers “can be stored, transcoded and routed to the
`
`appropriate recipients instantaneously or stored for later delivery.” (Petition at 27
`
`‐6‐
`
`
`
`
`
`
`IPR2017-01667
`Petitioners’ Reply
`
`
`(quoting Zydney, 1:21-22).) A recipient of the voice container “can reply in a
`
`complementary way, allowing for near real-time communication.” (Id. (quoting
`
`Zydney, 16:14-15).) Zydney describes this exchange of voice containers as “a
`
`voice instant messaging session.” (Id. at 27-28 (citing Zydney, 15:8-13, 10:19-
`
`11:3, 16:1-12).)
`
`Given that Zydney’s voice container discloses an instant voice message,
`
`Zydney’s teaching of attaching files to voice containers discloses “attaching one or
`
`more files to the instant voice message” as shown in the Petition. (Petition at 54-
`
`56.)
`
`Patent Owner also argues that Petitioner has not pointed “to any portion of
`
`Zydney . . . allegedly disclosing a software program that includes all the limitations
`
`set forth in the claim language for the ‘instant voice messaging application’,
`
`including those limitations specifically directed to the ‘document handler system’.”
`
`(Response at 20.) As explained in the following section, even under Patent
`
`Owner’s proposed constructions, Zydney discloses and renders obvious the instant
`
`voice messaging application and its included components as claimed.
`
`
`
`
`
`‐7‐
`
`
`
`
`
`IPR2017-01667
`Petitioners’ Reply
`
`
`
`B.
`
`Zydney Discloses the “Instant Voice Messaging Application,”
`“Client Platform System” and “Communication Platform
`System” Even Under Patent Owner’s Proposed Claim
`Interpretation
`Patent Owner repeats its argument from its Preliminary Response that
`
`Petitioners have not shown that Zydney teaches or suggests an “instant voice
`
`messaging application,” “client platform system” and “communication platform
`
`system” under Patent Owner’s proposed interpretations. (Response at 6-11.) To
`
`begin with, for the reasons explained in the Petition, to the extent the Board were
`
`to determine that any express claim constructions were required (which they are
`
`not), Petitioners’ proposed constructions are correct and Patent Owner’s should be
`
`rejected. (Petition at 6-11.) But as explained below, even under Patent Owner’s
`
`proposed constructions, the claim limitations would still be disclosed by the prior
`
`art.
`
`The thrust of Patent Owner’s argument regarding “instant voice messaging
`
`application” and “client platform system” is that those terms should be limited to
`
`software and should not encompass hardware. But even if those terms were
`
`limited to software, the Petition demonstrated how Zydney discloses them. The
`
`Petition in fact mapped them to Zydney’s “software (including a software agent)”
`
`installed on the client device. (Petition at 43-44 (underlining added), 52-53
`
`(explaining how “the software agent in Zydney includes a client platform system
`
`
`
`
`
`‐8‐
`
`
`
`
`
`IPR2017-01667
`Petitioners’ Reply
`
`
`for generating the instant voice message”) (underlining added).) (Indeed, Patent
`
`Owner has not pointed to any place where Petitioners relied on hardware
`
`functionality as disclosing the claimed instant messaging application or client
`
`platform system.)
`
`The Petition also explained how each of the claimed components included as
`
`part of the “instant voice messaging application,” such as the “document handler
`
`system,” is disclosed by or obvious over Zydney’s client software. (Petition at 58-
`
`64 (re claim 14, obvious for message database to be integrated with Zydney client
`
`software), 65-66 (re claim 16), 66-68 (re claim 17), 45-46 (re claim 18), 46-48 (re
`
`claim 19), 48-49 (re claim 20), 49 (re claim 21), 72 (re claim 22, obvious for
`
`Zydney’s software agent to display indicia in view of Appelman), 49-50 (re claim
`
`23), 52-56 (re claim 27).)
`
`As to the “document handler system” in particular, the Petition explained
`
`how Zydney discloses that the client system software attaches files to voice
`
`containers. (Petition at 54-55.) Patent Owner does not dispute that the client
`
`system software includes this functionality. The Petition further explained, citing
`
`the testimony of Dr. Lavian, that it would have been obvious to a person of
`
`ordinary skill for the client software agent to perform that functionality. (Petition
`
`at 55-56.) Nothing more is required to meet the claim. See, e.g., Paice LLC v.
`
`
`
`
`
`‐9‐
`
`
`
`
`
`IPR2017-01667
`Petitioners’ Reply
`
`
`Ford Motor Co., 681 F. App’x 904, 917 (Fed. Cir. 2017) (combining elements
`
`from embodiments in a single reference is a “predictable variation” that “does not
`
`require a leap of inventiveness”).
`
`Patent Owner also argues that the term “communication platform system” is
`
`“expressly defined within the claim language itself” and that Petitioner’s
`
`construction “unreasonably expands the claim scope to encompass any server
`
`system that simply ‘relays communications.’” (Response at 10.) To begin with, to
`
`the extent the Board determines that any claim construction is necessary (which it
`
`is not), Petitioner is correct for the reasons explained in the Petition. (Petition at
`
`10-11.)
`
`But even if Patent Owner’s construction of “communication platform
`
`system” were adopted, Zydney still discloses it. In fact, Patent Owner fails to
`
`explain why its proposed construction resolves any invalidity dispute in its favor.
`
`Patent Owner’s proposed construction is simply the claim language itself, and the
`
`Petition explained in detail how the prior art discloses the claim language.
`
`(Petition at 28-30.) Moreover, there is no meaningful difference for purposes of
`
`the cited prior art between Petitioner’s proposed construction of a “system of the
`
`server which relays communications and/or tracks client connection information”
`
`and Patent Owner’s proposed construction that the communication platform system
`
`
`
`
`
`‐10‐
`
`
`
`
`
`IPR2017-01667
`Petitioners’ Reply
`
`
`“maintain[s] connection information for each of the plurality of instant voice
`
`message client systems.”
`
`B.
`
`Zydney Discloses and Renders Obvious “wherein the instant voice
`message includes an object field including a digitized audio file”
`(independent claim 3)
`The Patent Owner Response recycles nearly verbatim several arguments
`
`already considered and rejected by the Board. (Compare Paper 6 (“Preliminary
`
`Response”) at 22-26 with Response at 22-28; Paper 8 at 18-20.) Patent Owner
`
`does not address the Board’s reasoning, let alone identify any error in it, and does
`
`not submit any new evidence on this issue.
`
`As the Board correctly found, Patent Owner’s arguments are premised on an
`
`implied construction of “instant voice message” as encompassing only audio data
`
`and excluding all else. (Paper 8 at 19.) As explained above, such a construction is
`
`incorrect.
`
`Patent Owner nevertheless argues that Zydney does not disclose or render
`
`obvious the claim language “wherein the instant voice message includes an object
`
`field including a digitized audio file.” As a matter of claim interpretation, Patent
`
`Owner appears to assume an unstated narrow claim interpretation of the term
`
`“object field” (e.g., that it is a “specific type of field”). (Response at 22-23.)
`
`However, Patent Owner does not propose any specific claim construction. On the
`
`contrary, it admits that the ’622 patent specification broadly teaches that “[t]he
`
`‐11‐
`
`
`
`
`
`
`IPR2017-01667
`Petitioners’ Reply
`
`
`content of the object field is a block of data . . . .” (’622, 14:37-38 (underlining
`
`added).) In fact, in co-pending litigation, Patent Owner proposed to construe
`
`“object field” broadly as “a block of data being carried by the message object.”
`
`(Ex. 1024 at 9 (underlining added).) Patent Owner does not demonstrate any basis
`
`for the Board to adopt any narrower interpretation in this proceeding.
`
`Under either the plain and ordinary meaning informed by the specification or
`
`under the construction Patent Owner proposed in litigation, Zydney discloses and
`
`renders obvious that the instant voice message (voice container) contains an object
`
`field (block of data) including an audio file, for the reasons explained in the
`
`Petition and discussed in detail by the Board in its institution decision. (Petition at
`
`31-33; Paper 8 at 16-17, 20.)
`
`Patent Owner ignores the Board’s detailed reasoning and discussion of the
`
`evidence, and does not identify any error in it. As the Board noted, while “Zydney
`
`does not utilize the term ‘field’ ipsissimis verbis,” the unrebutted testimony of Dr.
`
`Lavian, supported by RFC1521, indicates that when in MIME format, Zydney’s
`
`voice container would contain the digitized audio file in an object field. (Paper 8
`
`at 20.)
`
`Patent Owner repeats its pre-institution argument that because the RFC 1521
`
`uses the word “field” in connection with “headers,” a message body would not be
`
`
`
`
`
`‐12‐
`
`
`
`
`
`IPR2017-01667
`Petitioners’ Reply
`
`
`considered a “field.” (Response at 24-25.) However, as both Petitioner and Patent
`
`Owner have noted, the ’622 patent itself states that the “content of the object field
`
`is a block of data . . . .” (Id. at 27; Petition at 31.) The message body of the MIME
`
`formatted item consistent with RFC 1521 discloses an “object field” within the
`
`meaning of the claim language at issue. (Petition at 32-33.)
`
`Patent Owner also incorrectly suggests that Petitioners rely only on
`
`“inherency” for the “object field” limitation. But Patent Owner overlooks the
`
`obviousness showing in the Petition. The Petition explains why “it would have
`
`been plainly obvious to a person of ordinary skill in the art to provide the receiving
`
`software agent with the ability to format the voice container according to RFC
`
`1521, thus encoding the voice data in the body (an “object field”) of the message.”
`
`(Petition at 32-33 (underlining added, bold in original).)
`
`Patent Owner also improperly attacks the references individually, arguing
`
`that RFC 1521 itself does not describe that the message body includes an “audio
`
`file.” (Response at 24-25.) See In re Merck & Co., Inc., 800 F.2d 1091, 1097
`
`(Fed. Cir. 1986) (“[n]on-obviousness cannot be established by attacking references
`
`individually where the rejection is based upon the teachings of a combination of
`
`references.”); Allied Erecting & Dismantling Co. v. Genesis Attachments, LLC,
`
`825 F.3d 1373, 1381 (Fed. Cir. 2016) (“The test for obviousness is not whether the
`
`
`
`
`
`‐13‐
`
`
`
`
`
`IPR2017-01667
`Petitioners’ Reply
`
`
`features of a secondary reference may be bodily incorporated into the structure of
`
`the primary reference.”) (quoting In re Keller, 642 F.2d 413, 425-26 (C.C.P.A.
`
`1981)); MCM Portfolio LLC v. Hewlett-Packard Co., 812 F.3d 1284, 1294 (Fed.
`
`Cir. 2015); In re Mouttet, 686 F.3d 1322, 1332 (Fed. Cir. 2012) (“It is well-
`
`established that a determination of obviousness based on teachings from multiple
`
`references does not require an actual, physical substitution of elements.”). As the
`
`Petition explains, it would have been obvious to incorporate the voice audio “file”
`
`explicitly disclosed by Zydney into the MIME format, rendering obvious that the
`
`object field (message body) includes that audio file. (Petition at 33.)
`
`Patent Owner also incorrectly asserts that Petitioner presents inconsistent
`
`mappings to the instant voice message. (Response at 25.) Petitioner consistently
`
`identified Zydney’s voice container as corresponding to the claimed instant voice
`
`message, whose format discloses and also renders obvious the claimed “object
`
`field.” (Petition at 31-33 (stating, for example, “[i]t would also have been obvious
`
`that the Zydney voice container would contain an ‘object field’ . . .” and “it would
`
`have been plainly obvious . . . to provide the receiving software agent with the
`
`ability to format the voice container according to RFC 1521, thus encoding the
`
`voice data in the body (an ‘object field’) of the message”) (bold in original,
`
`underlining added).)
`
`
`
`
`
`‐14‐
`
`
`
`
`
`IPR2017-01667
`Petitioners’ Reply
`
`
`
`Patent Owner also repeats its argument that Zydney does not enable “using
`
`packet-switched fields of hypertext transfer protocol (‘HTTP’), as it existed in
`
`August 7, 2000.” The Board correctly declined to adopt this assertion. First,
`
`Patent Owner’s argument appears to be based on incorrectly reading Zydney to
`
`require data compression when transmitting voice containers. Patent Owner has
`
`not identified any disclosure of Zydney where compression is required. Second,
`
`even if Zydney did require data compression for voice containers, HTTP did
`
`support data compression as of August 2000. HTTP support for compression is
`
`described in Hethmon (Ex. 1009). Hethmon explains:
`
`In order to reduce the number of bytes transferred between
`HTTP applications, a content encoding transformation of the
`entity body may be performed. This allows an application to
`server resources in compressed format, while preserving the
`underlying media type. As an example of this usage, this
`mechanism would be an HTTP server which distributes video
`files. Typical video files are rather large, so the server stores the
`files in compressed format and transfers them to the client in
`this format. By using a content coding, the server can indicate
`the compressed form of the file, while still sending the original
`media type of the file. . . . For HTTP/1.1, three different content
`codings are defined: GZIP, compress and deflate. GZIP is
`defined in RFC 1952, deflate in RFC 1950 and RFC 1951.
`Compress is the common Unix format.
`‐15‐
`
`
`
`
`
`
`
`
`IPR2017-01667
`Petitioners’ Reply
`
`
`
`(Ex. 1009 at Page 39 (emphasis added).)
`
`Third, Hethmon makes clear that HTTP can be used to transfer various types
`
`of data, including data that has been compressed separately from the HTTP
`
`protocol itself, such as transmitting files in the well-known “zip” and “gif”
`
`compression formats. (Id. at Page 44.) In other words, it is irrelevant whether
`
`HTTP itself had built-in compression protocols because HTTP could be used to
`
`transmit various types of items, including compressed items.2 Petitioners’
`
`obviousness mapping is based on the use of HTTP as the transport protocol for the
`
`instant voice messages in Zydney. Those instant voice messages would be
`
`separately compressed and decompressed by software on the client devices, and
`
`the data would obviously be transported in an object field (e.g., MIME message
`
`body) as part of the HTTP transmission.
`
`C. Zydney and Clark Disclose and Render Obvious the “Message
`Database” Limitations
`Dependent claims 14 and 28 both recite a system including functionality for
`
`transmitting an instant voice message and “a message database storing the instant
`
`
`2 Just about anyone who used the Web in 2003 will recall that HTTP was
`
`commonly used to transmit these and other types of compressed files, such as
`
`“mp3” audio files.
`
`
`
`
`
`‐16‐
`
`
`
`
`
`IPR2017-01667
`Petitioners’ Reply
`
`
`voice message, wherein the instant voice message is represented by a database
`
`record including a unique identifier.” The Petition demonstrates in detail why it
`
`would have been obvious to combine Zydney’s instant voice messaging
`
`application with Clark’s teaching of a message database that stores outgoing (sent)
`
`and incoming (received) messages. (Petition at 58-64.) Patent Owner does not
`
`identify any deficiency in the showing of obviousness.
`
`1.
`
`Patent Owner
`Individually
`Patent Owner argues that Clark, by itself, does not disclose storing “instant
`
`Improperly Attacks
`
`the References
`
`voice messages in particular” and that instant voice messages are different from
`
`voicemail messages. (Response at 29-30.) Patent Owner similarly asserts that
`
`neither Clark nor Zydney, by itself, discloses a message database “included as part
`
`of a client-side ‘instant voice messaging application’.” (Id. at 30.)
`
`As noted previously, Patent Owner cannot rebut Petitioners’ evidence of
`
`obviousness by merely addressing the references individually, instead of
`
`addressing the combined teachings Petitioners rely upon, and obviousness does not
`
`require that the features of a secondary reference can be bodily incorporated into
`
`the structure of the primary reference. In re Merck, 800 F.2d at 1097; Allied
`
`Erecting & Dismantling Co., LLC, 825 F.3d at 1381; MCM Portfolio, 812 F.3d at
`
`1294; In re Mouttet, 686 F.3d at 1332.
`
`
`
`
`
`‐17‐
`
`
`
`
`
`IPR2017-01667
`Petitioners’ Reply
`
`
`
`Aside from attacking the references individually, Patent Owner does not
`
`meaningfully rebut the strong motivation to combine Zydney and Clark. Clark
`
`expressly motivates the use of its message database system with any “electronic
`
`messages, such as e-mail messages, instant messages, voice messages and fax
`
`messages,” and “can be applied to organizing any sort of electronic messages . . .”
`
`(Petition at 15 (quoting Ex. 1008 at 4:9-12), 62 (quoting Ex. 1008 at 8:31-44).)
`
`Clark also teaches that its “invention can advantageously be integrated with
`
`messaging software . . . to facilitate the organization of electronic messages.” (Id.
`
`at 62 (quoting Ex. 1008 at 4:36-38).) A person of ordinary skill in the art would
`
`have readily appreciated the applicability of Clark’s message database to
`
`efficiently organize and retrieve the electronic messages disclosed by Zydney
`
`(instant voice messages), integrated with Zydney’s messaging software (software
`
`agent) disclosing the claimed “instant voice messaging application.” (Petition at
`
`61-64.) Patent Owner ignores these teachings and submits no contrary evidence.
`
`2.
`
`Patent Owner Relies On an Incorrect Claim Construction
`Regarding “Database Record”
`Patent Owner further relies on an incorrect narrow claim interpretation.
`
`(Response at 30-34.) It contends that “each ‘database record’ itself comprises both
`
`a message identifier and the instant voice message,” requiring that the “instant
`
`voice message” “is itself included within the database record.” (Response at 31-32
`
`
`
`
`
`‐18‐
`
`
`
`
`
`IPR2017-01667
`Petitioners’ Reply
`
`
`(“The phrase ‘represented by’ in the claim language must be understood in light of
`
`these informative teachings, i.e., the claimed ‘database record’ includes as content
`
`both the ‘message identifier’ and the ‘instant voice message.’”).) Based on its
`
`flawed claim interpretation, Patent Owner argues that “Petitioners have not shown
`
`that a database record in Clark includes both a unique identifier and an instant
`
`voice message.” (Response at 32-34 (underlining added) (arguing that the message
`
`data is stored separately from the