IPR2017-01668
`Petitioners’ Reply
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`FACEBOOK, INC. and WHATSAPP, INC.
`Petitioner
`
`v.
`
`UNILOC USA, INC. and UNILOC LUXEMBOURG S.A.,
`Patent Owner.
`
`
`Case IPR2017-01668
`Patent 8,724,622 B2
`
`
`PETITIONERS’ REPLY
`
`
`
`
`
`
`Petitioners’ Reply
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`FACEBOOK, INC. and WHATSAPP, INC.
`Petitioner
`
`v.
`
`UNILOC USA, INC. and UNILOC LUXEMBOURG S.A.,
`Patent Owner.
`
`
`Case IPR2017-01668
`Patent 8,724,622 B2
`
`
`PETITIONERS’ REPLY
`
`
`
`
`
`
`
`TABLE OF CONTENTS
`
`
`Page
`
`
`I.
`II.
`
`CLAIM CONSTRUCTION ........................................................................... 2
`CLAIMS 4, 5, 12 and 24-26 ARE UNPATENTABLE ................................. 3
`A.
`Zydney Discloses and Renders Obvious “wherein the instant
`voice message includes an object field including a digitized
`audio file” (claims 4, 5, and 12) ........................................................... 3
`The Prior Art Discloses and Renders Obvious the “action field”
`Limitations (claims 4 and 5) ............................................................... 10
`The Prior Art Discloses and Renders Obvious the “connection
`object” Limitations (claims 24-26) .................................................... 12
`III. CONCLUSION ............................................................................................. 20
`
`
`
`B.
`
`C.
`
`
`
`
`
`
`
`‐i‐
`
`
`
`
`
`TABLE OF AUTHORITIES
`
`Page(s)
`
`
`Cases
`Allied Erecting & Dismantling Co. v. Genesis Attachments, LLC,
`825 F.3d 1373 (Fed. Cir. 2016) ............................................................................ 7
`Anchor Wall Sys., Inc. v. Rockwood Retaining Walls, Inc.,
`340 F.3d 1298 (Fed. Cir. 2003) ............................................................................ 4
`DePuy Spine, Inc. v. Medtronic Sofamor Danek, Inc.,
`567 F.3d 1314 (Fed. Cir. 2009) .......................................................................... 12
`Epos Techs. Ltd. v. Pegasus Techs. Ltd.,
`766 F.3d 1338 (Fed. Cir. 2014) ............................................................................ 4
`Galderma Labs., LP v. Tolmar, Inc.,
`737 F.3d 731 (Fed. Cir. 2016) ............................................................................ 12
`In re Keller,
`642 F.2d 413 (C.C.P.A. 1981) .............................................................................. 7
`MCM Portfolio LLC v. Hewlett-Packard Co.,
`812 F.3d 1284 (Fed. Cir. 2015) ............................................................................ 7
`In re Merck & Co., Inc.,
`800 F.2d 1091 (Fed. Cir. 1986) ............................................................................ 7
`In re Mouttet,
`686 F.3d 1322 (Fed. Cir. 2012) ............................................................................ 7
`Nidec Motor Corp. v. Zhongshan Broad Ocean Motor Co.,
`868 F.3d 1013 (Fed. Cir. 2017) .......................................................................... 13
`Santarus, Inc. v. Par Pharm., Inc.,
`694 F.3d 1344 (Fed. Cir. 2012) .......................................................................... 12
`Tyco Healthcare Group LP v. Ethicon Endo-Surgery,
`774 F.3d 968 (Fed. Cir. 2014) ............................................................................ 12
`Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc.,
`200 F.3d 795 (Fed. Cir. 1999) ............................................................................ 14
`‐ii‐
`
`
`
`
`
`
`
`
`TABLE OF AUTHORITIES
`
`Page(s)
`
`Statutes
`35 U.S.C. § 103 ........................................................................................................ 19
`
`
`
`
`
`
`‐iii‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`
`Petitioners Facebook, Inc. and WhatsApp, Inc. (“Petitioners”) respectfully
`
`submit this Reply in support of Inter Partes Review of claims 4, 5, 12 and 24-26 of
`
`U.S. Patent No. 8,724,622 (Ex. 1101) (“’622 patent”) and addressing Patent
`
`Owner’s Response (Paper 16 (“Response”)).
`
`Petitioners note that the issues in this proceeding overlap with the issues in
`
`IPR2017-01667 where the challenged claims include claim 3 of the ’622 patent.
`
`Claims 4, 5, and 12 challenged in the present case depend directly or indirectly
`
`from claim 3.
`
`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.
`
`
`
`
`
`‐1‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`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
`
`meaning of the claim language in view of the specification, claims 4, 5, 12, and 24-
`
`26 are unpatentable as obvious over the prior art.
`
`For the term “connection object messages” recited in claim 24, the prior art
`
`also discloses and renders obvious the claim limitations under the parties’ agreed
`
`proposed claim construction as discussed further below. (See Petition at 7-8;
`
`Response at 5.)
`
`For the term “communication platform system,” Patent Owner argues that
`
`“the claims themselves of the ’622 Patent defines [sic] ‘communications platform
`
`system.’” (Response at 6.) To begin with, to the extent the Board determines that
`
`any claim construction is necessary (which it is not), Petitioner’s construction is
`
`correct for the reasons explained in the Petition. (Petition at 8-9.) 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 31-33, 46.)
`
`
`
`
`
`‐2‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`
`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
`
`“maintain[s] connection information for each of the plurality of instant voice
`
`message client systems.”
`
`II. CLAIMS 4, 5, 12 AND 24-26 ARE UNPATENTABLE
`A. Zydney Discloses and Renders Obvious “wherein the instant voice
`message includes an object field including a digitized audio file”
`(claims 4, 5, and 12)
`The Patent Owner Response recycles nearly verbatim several arguments
`
`already considered and rejected by the Board. (See Paper 8 at 20-24.) 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 observed, Patent Owner’s arguments are premised in
`
`part on an implied construction of “instant voice message” as encompassing only
`
`audio data and excluding all else. (Paper 8 at 22-23.) As explained below, such a
`
`construction is incorrect.
`
`The claim language does not support Patent Owner’s erroneous narrow
`
`interpretation. The ’622 patent claims recite an “instant voice message” without
`
`specifying that it must be narrowly limited to consist only of audio data. Nor do
`
`‐3‐
`
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`the claims support such an interpretation. On the contrary, the claims at issue
`
`recite, for example, that “the instant voice message includes an action field” (claim
`
`4), indicating that the instant voice message contains more than just audio data.
`
`(See also, e.g., ’622, claims 6-8 (“wherein the instant voice message includes an
`
`identifier field,” “… includes a source field,” “… includes a destination field”).)
`
`The specification also does not support Patent Owner’s
`
`incorrect
`
`construction. The specification describes that the instant voice message object can
`
`contain various fields, consistent with the above-noted claim recitations. (’622,
`
`col. 14:6-40.) Patent Owner’s implicit claim interpretation that an “instant voice
`
`message” is limited to audio data without any additional content would
`
`impermissibly exclude these embodiments. 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, 1308 (Fed. Cir. 2003)).
`
`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 30-31.)
`
`
`
`
`
`‐4‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`
`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” in independent claim 3 (incorporated into
`
`challenged claims 4, 5, and 12). 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 12-13.) 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 content of the
`
`object field is a block of data . . . .” (’622, 14:37-38 (underlining added); Response
`
`at 17.) 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. 1124
`
`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
`
`34-36; Paper 8 at 22-24.)
`
`
`
`
`
`‐5‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`
`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 24.)
`
`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
`
`considered a “field.” (Response at 14-15.) 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 17; Petition at 34.) 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 35-36.)
`
`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
`
`
`
`
`
`‐6‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`1521, thus encoding the voice data in the body (an “object field”) of the message.”
`
`(Petition at 35-36 (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 14.) 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
`
`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 35-36.)
`
`
`
`
`
`‐7‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`
`Patent Owner also incorrectly asserts that Petitioner presents inconsistent
`
`mappings to the instant voice message. (Response at 15.) 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 34-36 (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).)
`
`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.” (Response at 17.) 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. 1109). Hethmon explains:
`
`
`
`
`
`‐8‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`
`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.
`
`
`(Ex. 1109 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
`
`
`
`
`
`‐9‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`transmit various types of items, including compressed items.1 Where HTTP would
`
`be used as a transport protocol for the Zydney system, the voice content 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.
`
`B.
`
`The Prior Art Discloses and Renders Obvious the “action field”
`Limitations (claims 4 and 5)
`Dependent claim 4 recites that the instant voice message includes “an action
`
`field identifying one of a predetermined set of permitted actions requested by the
`
`user.” Claim 5 depends from claim 4. The Petition explains how this limitation is
`
`rendered obvious by Zydney in view of Hethmon. In particular, the “Request-
`
`Line” in HTTP 1.1, described by Hethmon, discloses the “action field” identifying
`
`one of a predetermined set of permitted actions requested by the user (e.g.,
`
`“POST”). (Petition at 37-45.)
`
`Patent Owner does not dispute that the Request-Line in Hethmon discloses
`
`“an action field identifying one of a predetermined set of permitted actions
`
`requested by the user.” However, Patent Owner argues that Zydney allegedly
`
`1 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.
`
`
`
`
`
`‐10‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`“teaches away” from combination with Hethmon because Zydney states that a
`
`“voice container” refers to “a container object that contains no methods.”
`
`(Response at 18-20 (italics in original), quoting Zydney, 12:6-8.)
`
`Patent Owner’s “teach away” argument is meritless for multiple reasons.
`
`First, Patent Owner’s argument misstates the proposed obviousness combination.
`
`The combination would not result in the voice container itself containing any
`
`methods. Rather, the Petition explains that it would have been obvious to transport
`
`the voice containers in Zydney as the “payload” contained in HTTP 1.1 messages
`
`as taught by Hethmon. (Petition at 40-42.) Using HTTP 1.1, the voice container
`
`would be contained as the “entity body” in an HTTP POST message, for example.
`
`(Petition at 39-40; Hethmon, pp. 54 (“Entity-Body” field), 78 (“[u]sing the POST
`
`method, the client sends an entity body to the server for processing”).) The
`
`Request-Line in the HTTP message is distinct from the Entity-Body “payload” of
`
`the message. (See id.) Therefore, the Zydney voice container, transported as the
`
`payload of an HTTP message disclosing the claimed “instant voice message,”
`
`would not contain any methods.
`
`Furthermore, even if the combination would result in the voice container
`
`itself containing the Request-Line (which it would not), that would not amount to
`
`any “teach away” as Patent Owner contends, as there is no “clear discouragement
`
`
`
`
`
`‐11‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`of that combination.” Tyco Healthcare Group LP v. Ethicon Endo-Surgery, 774
`
`F.3d 968, 977 (Fed. Cir. 2014), quoting Santarus, Inc. v. Par Pharm., Inc., 694
`
`F.3d 1344, 1356 (Fed. Cir. 2012). “A reference does not teach away . . . if it
`
`merely expresses a general preference for an alternative invention but does not
`
`criticize, discredit, or otherwise discourage investigation into the invention
`
`claimed.” Galderma Labs., LP v. Tolmar, Inc., 737 F.3d 731, 738 (Fed. Cir.
`
`2016), quoting DePuy Spine, Inc. v. Medtronic Sofamor Danek, Inc., 567 F.3d
`
`1314, 1327 (Fed. Cir. 2009). Zydney merely provides a neutral statement of
`
`terminology, namely that “[t]he term ‘voice containers’ as used throughout this
`
`application refers to a container object that contains no methods.” (Zydney, 12:6-
`
`8.) Nothing in this statement, or anything else in Zydney, specifically discourages
`
`any modification of the voice container to include methods.
`
`C. The Prior Art Discloses and Renders Obvious the “connection
`object” Limitations (claims 24-26)
`Claim 24 recites “wherein the messaging system receives connection object
`
`messages from the plurality of instant voice message client systems, wherein each
`
`of the connection object messages includes data representing a state of a logical
`
`connection with a given one of the plurality of instant voice message client
`
`systems.” The Petition relies on the combination of Zydney with Hethmon as
`
`
`
`
`
`‐12‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`rendering obvious this limitation. (Petition at 46-53.) Claims 25 and 26 depend
`
`from claim 24.
`
`The parties agree that “connection object messages” may be interpreted to
`
`mean “messages containing data representing the state of the connection and code
`
`(one or more methods) for establishing and maintaining the logical connections
`
`between an instant voice messaging server and instant voice messaging clients.”
`
`(Petition at 7-8; Response at 5.) However, in its institution decision, the Board
`
`found that no express claim constructions were needed. (Paper 8 at 9.)
`
`Patent Owner does not dispute that the HTTP 1.1 messages including the
`
`Request-Line (as described in Hethmon) disclose “connection object messages
`
`[that] include[] data representing a state of a logical connection with a given one of
`
`the plurality of instant voice message client systems,” either under the parties’
`
`proposed construction of “connection object messages” or under the plain and
`
`ordinary meaning applied by the Board. Accordingly, since there is no material
`
`dispute about the application of this claim language to the prior art, the Board need
`
`not provide any express claim construction. Nidec Motor Corp. v. Zhongshan
`
`Broad Ocean Motor Co., 868 F.3d 1013, 1017 (Fed. Cir. 2017) (only those claim
`
`terms “that are in controversy” need to be construed, and then “only to the extent
`
`
`
`
`
`‐13‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`necessary to resolve the controversy”), quoting Vivid Techs., Inc. v. Am. Sci. &
`
`Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999).
`
`Although Patent Owner does not dispute that the combination of references
`
`discloses the claim limitations, Patent Owner raises another meritless “teaching
`
`away” argument. It argues, again, that Zydney teaches away from the use of HTTP
`
`because it states that the term “voice container” refers to “a container object that
`
`contains no methods.” (Response at 18-20 (italics in original), quoting Zydney,
`
`12:6-8.)
`
`Patent Owner misstates the references and their teachings. For the claimed
`
`“connection object messages,” the Petition relies upon Zydney’s disclosure that the
`
`central messaging system receives status messages from the instant voice message
`
`client systems. (Petition at 46-48.) As explained in the Petition, Zydney does not
`
`specify the transport protocol or format for those status messages, and it would
`
`have been obvious to use HTTP 1.1 (as taught by Hethmon) to transmit those
`
`status messages, thereby disclosing connection object messages including code
`
`(one or more methods) contained in the Request-Line of the HTTP message.
`
`(Petition at 48-49.)
`
`More specifically, as discussed in the Petition and by Dr. Lavian, a POST
`
`message contains a Request-Line that includes code instructing the server to POST
`
`
`
`
`
`‐14‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`the payload content to a server at a specified location, such as the first line of the
`
`message shown in the below example from Hethmon:
`
`
`
`(Hethmon, p. 78; see Ex. 1102, ¶ 330, Petition at 48.) As Dr. Lavian explains,
`
`unrebutted, the POST instructions in the Request-Line disclose code (one or more
`
`methods) that instruct the server to take action accordingly, such as instructions to
`
`POST the payload to the specified server location “/cgi-bin/survey” using HTTP
`
`1.1 in the example depicted above. (Ex. 1102, ¶ 331.)2
`
`
`2 The Board, in its Institution Decision, queried whether the method “keyword” by
`
`itself (e.g., the word “POST” by itself) discloses a method, as opposed to merely
`
`being a keyword identifying a method. (Paper 8 at 24.) However, the Petition
`
`relies on the entirety of the Request-Line as disclosing code providing instructions
`
`to the server, as discussed by Dr. Lavian. The HTTP message including the
`
`Request-Line therefore discloses the connection object limitation per claim 24,
`
`including code (one or more methods) in the Request-Line to the extent that the
`
`Board were to adopt a claim construction of “connection objects.” Uniloc did not
`
`
`
`
`
`‐15‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`
`Contrary to Patent Owner’s suggestions, claim 24 does not recite that the
`
`instant voice message itself contains connection object messages, and the Petition
`
`does not rely upon the transmission of a voice container in Zydney as disclosing
`
`the transmission of the connection object message, as discussed above.3 The
`
`mapping relies upon the connection status messages communicated by client
`
`devices in Zydney, which are distinct from the voice messages recorded and
`
`transmitted by users.
`
`Furthermore, Patent Owner misstates Zydney’s teachings when it asserts that
`
`Zydney discloses that its “container object” must be “used in transporting all
`
`messages” and “is specifically designed to contain no methods.” (Response at 21.)
`
`Zydney does not state or suggest that all messages must be transported using a
`
`container object that contains no methods. In fact, Zydney does not use the term
`
`
`dispute that Hethmon discloses the connection object limitation and did not rebut
`
`Dr. Lavian’s opinions on these points.
`
`3 The Board observed at institution that there was no basis to find that “claim 24
`
`requires the recited ‘connection objects’ to be included within the recited instant
`
`voice message itself.” (Paper 8 at 26-27.) The Board’s initial determination was
`
`correct. The language of the claim does not recite or impose any such requirement,
`
`and Patent Owner did not raise any argument to the contrary.
`
`
`
`
`
`‐16‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`“container object” outside of the single sentence defining a “voice container.”
`
`Zydney also does not disclose that the connection status messages must be
`
`transmitted using voice containers (which would make no sense, because the voice
`
`containers contain users’ voice recordings that would not be part of the status
`
`message). Rather, as noted above, Zydney merely states, as a matter of neutral
`
`definition, that the “[t]he term ‘voice containers’ as used throughout this
`
`application refers to a container object that contains no methods.” (Zydney, 12:6-
`
`8.) Nothing about this definition of “voice container” has any bearing on the
`
`connection object messages disclosed and rendered obvious by Zydney in view of
`
`Hethmon.
`
`Finally, Patent Owner argues that Zydney would not have used the HTTP
`
`disclosed by Hethmon because Zydney does not explicitly describe the use of
`
`HTTP for its system and describes that communications are transported using
`
`TCP/IP. (Response at 21-23.) However, Patent Owner ignores the Board’s well-
`
`reasoned rejection of this same argument. (Paper 8 at 27.) As the Board observed,
`
`Dr. Lavian testified, unrebutted, that “[b]ecause HTTP is built on top of TCP/IP, it
`
`would have been straightforward to use HTTP to facilitate voice container delivery
`
`from clients to the central server.” (Ex. 1102, ¶ 319 (emphasis added).) Zydney
`
`extensively discusses HTTP and its known features and benefits, and incorporates
`
`
`
`
`
`‐17‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`by reference a draft of the HTTP 1.1 standard. (Petition at 40-42, citing Zydney,
`
`7:21-8:3, 8:3-6.) Dr. Lavian and the Petition explain in detail—without any
`
`meaningful rebuttal—why it would have been obvious to use HTTP as a transport
`
`protocol for the Zydney system with no significant technical obstacles. (Petition at
`
`40-45 (extensive discussion of why it would have been obvious to use HTTP as a
`
`transport protocol for Zydney), 47-48 (for claim 24, referring to the motivation to
`
`use HTTP with Zydney as discussed for claims 4 and 5).)
`
`Patent Owner also raises a baseless argument that Zydney was not consistent
`
`with HTTP because HTTP purportedly did not have built-in compression
`
`capability as of August 2000. (Response at 23.) 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.
`
`1109). 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 its
`
`
`
`
`
`‐18‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`
`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.
`
`
`(Ex. 1109 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. (Ex. 1109 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. 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
`
`
`
`
`
`‐19‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`the data could obviously be transported in an object field (e.g., MIME message
`
`body) as part of the HTTP transmission.
`
`III. CONCLUSION
`For the foregoing reasons, the Board should enter a final written decision
`
`finding claims 4, 5, 12 and 24-26 invalid under 35 U.S.C. § 103.
`
`
`Dated: June 19, 2018
`
`COOLEY LLP
`ATTN: Patent Group
`1299 Pennsylvania Ave., NW, Suite 700
`Washington, DC 20004
`Tel: (650) 843-5001
`Fax: (650) 849-7400
`
`
`
`
`
`
`By:
`
`
`
`
`Respectfully submitted,
`
`
`/Heidi L. Keefe/
`Heidi L. Keefe
`Reg. No. 40,673
`Counsel for Petitioners
`Facebook, Inc. and WhatsApp
`Inc.
`
`
`
`
`
`
`
`‐20‐
`
`
`
`
`
`IPR2017-01668
`Petitioners’ Reply
`
`
`
`CERTIFICATE OF COMPLIANCE WITH WORD COUNT
`
`
`
`Pursuant to 37 C.F.R. § 42.24(d), I certify that this petition complies with
`the type-volume limits of 37 C.F.R. § 42.24(c)(1) because it contains 4,084 words,
`according to the word-processing system used to prepare this petition, excluding
`the parts of
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
