Trials@uspto.gov
`571-272-7822
`
`Paper 14
`Date Entered: February 25, 2013
`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`_____________
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________
`
`MICROSOFT CORPORATION
`Petitioner
`
`v.
`
`PROXYCONN, INC.
`Patent Owner
`____________
`
`Case IPR2013-00109 (TLG)
`Patent 6,757,717 B1
`____________
`
`
`
`
`Before SALLY C. MEDLEY, SCOTT R. BOALICK, and THOMAS L.
`GIANNETTI, Administrative Patent Judges.
`
`
`GIANNETTI, Administrative Patent Judge.
`
`
`
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`

`

`IPR2013-00109
`Patent 6,757,717
`
`
`
`I. INTRODUCTION
`
`
`
`
`
`Petitioner Microsoft Corporation requests inter partes review of claims 6, 7,
`
`9, 11, 12, and 14 of US Patent 6,757,717 B1 pursuant to 35 U.S.C. §§ 311 et seq.
`
`Patent Owner ProxyConn, Inc. has waived its right to file a preliminary response
`
`under 37 C.F.R. § 42.107(b). Paper 13. We have jurisdiction under 35 U.S.C.
`
`§ 314.
`
`
`
`
`
`The standard for instituting an inter partes review is set forth in 35 U.S.C.
`
`§ 314(a), which provides as follows:
`
`
`
`
`
`
`
`
`
`THRESHOLD -- The Director may not authorize an inter partes review to be
`instituted unless the Director determines that the information presented in
`the petition filed under section 311 and any response filed under section 313
`shows that there is a reasonable likelihood that the petitioner would prevail
`with respect to at least 1 of the claims challenged in the petition.
`
`Petitioner challenges claims 6, 7, 9, 11, 12, and 14 as unpatentable under
`
`35 U.S.C. § 102 and 35 U.S.C. § 103. Pet. 4-5. We grant the Petition and institute
`
`trial as to those claims on the grounds set forth below.
`
`
`
`Concurrently with the Petition, Microsoft filed a motion seeking to join this
`
`proceeding with IPR2012-00026, involving the same patent and parties. Paper 7.
`
`In a separate decision entered today, we grant that motion and join the two trial
`
`proceedings.1
`
`
`
`
`
`
`
`
`1 The joinder of this proceeding with an existing IPR makes the one-year time
`period under 35 U.S.C. § 315(b), which would otherwise have barred this
`proceeding, not applicable. See 37 C.F.R § 42.122(b).
`
`2
`
`
`

`

`IPR2013-00109
`Patent 6,757,717
`
`
`
`II. BACKGROUND
`
`
`
`
`
`Petitioner’s Prior Request for Inter Partes Review
`
`
`
`
`
`This is Petitioner’s second request for inter partes review of the ʼ717 patent.
`
`The first request, filed on September 18, 2012, was granted-in-part on
`
`December 21, 2012. See IPR2012-00026 Paper 17, Decision On Request For Inter
`
`Partes Review (“Decision”). In that Decision the Board instituted a trial as to
`
`claims 1, 3, 10, and 22-24 of the ʼ717 patent, which claims are not involved in this
`
`Petition. However, the Decision denied the Petition as to claims 11, 12, and 14 of
`
`the ʼ717 patent.2 Those claims are included in this Petition, and as to those claims
`
`Petitioner has provided additional prior art and raised new grounds of challenge
`
`that were not previously considered by the Board. The instant Petition additionally
`
`raises challenges against claims 6, 7, and 9, claims not at issue in IPR2012-00026.
`
`
`
`
`
`
`
`
`
`III. THE ʼ717 PATENT
`
`
`
`The technology of ʼ717 patent is described in the prior Decision at pages 2-
`
`6. For the purposes of this decision we adopt that prior description. The
`
`description that follows will focus on the areas pertinent to the decision that were
`
`not previously covered.
`
`
`2 In a separate decision entered today in IPR2012-00026, the Board denies
`Microsoft’s request for reconsideration of the denial of review as to claims 11, 12,
`and 14.
`
`3
`
`
`

`

`IPR2013-00109
`Patent 6,757,717
`
`
`
`Claims 6, 7, and 9
`
`
`
`
`
`These claims of the ʼ717 patent are directed to the embodiment of the
`
`invention shown in Figure 11 following:
`
`
`
`
`
`
`
`Figure 11 is a block diagram of a gateway system embodiment of the
`
`
`
`invention of the ʼ717 patent. Col. 6, ll. 1-2. As described in the patent, this
`
`embodiment comprises a gateway computer or gateway (60), and a caching
`
`computer (62) connected to the gateway through a “fast” network connection (64)
`
`such as Ethernet. Col. 8, ll. 57-63. The gateway is connected to a wide-area
`
`packet switched network such that network packets sent between computers (42)
`
`and (46) pass through the gateway. Id. at ll. 64-67. The caching computer uses
`
`part of its permanent storage for network cache memory (66). Col. 9, l.1. The
`
`caching computer also has means (68) for calculating a digital digest in its network
`
`cache memory and means (70) for comparison between the calculated digital digest
`
`and a digital digest received by the gateway computer from the wide-area network.
`
`Col. 9, ll. 2-6.
`
`
`
`4
`
`
`

`

`IPR2013-00109
`Patent 6,757,717
`
`
`
`
`Claim 6 further illustrates the technology, and reads as follows:
`
`
`
`6. A system for data access in a packet-switched network,
`
`comprising:
`
`a gateway including an operating unit, a memory and a processor
`connected to said packet-switched network in such a way that network
`packets sent between at least two other computers pass through it;
`
`a caching computer connected to said gateway through a fast local
`network, wherein said caching computer includes an operating unit, a first
`memory, a permanent storage memory and a processor;
`
`said caching computer further including a network cache memory in
`its permanent storage memory, means for calculating a digital digest and
`means for comparison between a digital digest on data in its network cache
`memory and a digital digest received from said packet switched network
`through said gateway.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Claims 7 and 9 both depend from claim 6.
`
`
`
`Claims 11, 12, and 14
`
`
`
`These claims are directed to the embodiment of Figures 8-10 of the
`
`‘717 patent, described in the prior Decision at pp. 4-6. Claim 11 follows:
`
`
`
`11. A method performed by a sender/computer in a packet-switched
`
`network for increasing data access, said sender/computer including an
`operating unit, a first memory, a permanent storage memory and a
`processor and said sender/computer being operative to transmit data to
`a receiver/computer, the method comprising the steps of:
`
`creating and transmitting a digital digest of said data from said
`sender/computer to said receiver/computer;
`
`receiving a response signal from the receiver/computer at said
`sender/computer, said response signal containing a positive, partial or
`negative indication signal for said digital digest, and
`
`if a negative indication signal is received, transmitting said data
`from said sender/computer to said receiver/computer.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`5
`
`
`

`

`IPR2013-00109
`Patent 6,757,717
`
`Claims 12 and 14 depend from claim 11.
`
`
`
`
`
`
`
`
`
`
`
`IV. CLAIM CONSTRUCTION
`
`As part of our analysis we make the following claim constructions using the
`
`broadest reasonable interpretation:
`
`
`
`Caching Computer
`
`
`
`Petitioner has proposed the construction of this term, appearing in claims 6,
`
`7, and 9, as: “any computer(s) (and connected storage devices) capable of caching
`
`or otherwise storing data for later retrieval.” Pet. 8. We agree with and therefore
`
`adopt this proposed construction.
`
`
`
`Operating Unit
`
`
`
`The Decision applied this term, appearing in all claims under consideration,
`
`in accordance with its plain meaning. Decision 14-15. After considering
`
`Petitioner’s proposed construction (which is similar to that proposed previously
`
`and not adopted), we maintain our prior decision that plain meaning applies.
`
`
`
`Network Cache Memory in its Permanent Storage Memory
`
`
`
`The Decision applied this term, appearing in all claims under consideration,
`
`in accordance with its plain meaning. Decision 15. After considering Petitioner’s
`
`proposed construction (which is the same as that proposed previously and not
`
`adopted) we maintain our prior decision that plain meaning applies.
`
`
`
`
`
`6
`
`
`

`

`IPR2013-00109
`Patent 6,757,717
`
`
`
`Data
`
`
`
`
`
`
`
`This term, appearing in all claims under consideration, was previously
`
`construed in accordance with the Patent Owner’s definition as “a file or range of
`
`octets in a file, a range of frames in a video stream or RAM-based range of octets,
`
`a transport level network packet, or the like.” Decision 12. Petitioner does not
`
`challenge this definition. Pet. 9.
`
`
`
`Digital Digest/Digital Digest on Data
`
`
`
`These terms, appearing in claims 6, 7, and 9, were previously construed in
`
`accordance with the Patent Owner’s definition as “a fixed-size binary value
`
`calculated from arbitrary-size binary data in such a way that it depends only on the
`
`contents of the data and the low probability that two different data or objects have
`
`the same digital digest.” See Decision 13; ʼ717 patent, col. 2, ll. 9-13. The patent
`
`further defines the term “digital digest” as referring to the known MD5 algorithm,
`
`but states that other algorithms may be used. For example, a digital digest may be
`
`calculated according to the CRC algorithm, or by applying the CRC algorithm to
`
`different subsets or different recordings of data, or by consecutively applying CRC
`
`and MD5. See Decision 13; ʼ717 patent col. 6, ll. 24-36. Petitioner’s challenge
`
`(Pet. 10) repeats contentions previously considered and rejected, and does not
`
`persuade us to depart from our prior construction.
`
`
`
`Means for Calculating a Digital Digest
`
`
`
`We refer to and adopt our previous construction of “means for creating
`
`digital digests” as the MD5 and CRC algorithms. See Decision 15.
`
`
`
`7
`
`
`

`

`IPR2013-00109
`Patent 6,757,717
`
`
`Means for Comparison between a Digital Digest on Data in its Network Cache
`Memory and the Digital Digest Received from said Packet Switched Network
`through said Gateway
`
`
`
`As Petitioner points out, similar claim language was previously construed.
`
`
`
`Decision 15-16. Petitioner does not challenge this prior construction for the
`
`purpose of this second Petition. Pet. 10. We therefore maintain our previous
`
`construction.
`
`
`
`Means for Storing said Calculated Digital Digest in said Permanent Storage
`Memory
`
`
`
`As Petitioner points out, similar claim language was previously construed.
`
`Decision 16. Petitioner does not challenge this prior construction for the purpose
`
`of this second Petition. Pet. 11. We therefore maintain our previous construction.
`
`
`
` A
`
` Gateway including... Connected to said Packet-switched Network in such a Way
`that Network Packets Sent between at least Two Other Computers Pass Through
`It; [a Caching Computer] Connected to said Gateway through a Fast Local
`Network
`
`
`
`We generally agree with Petitioner that a broad but reasonable construction
`
`of the term “gateway” in claims 6, 7, and 9 would include network proxies and
`
`routers. Pet. 11. We also agree that the gateway and caching computer may be
`
`integrally formed, although this is not required. ʼ717 patent col. 9, ll. 6-8. We also
`
`agree that “fast local network” includes Ethernet. See supra; ʼ717 patent col. 8,
`
`l. 63. We are not persuaded that the written description suggests that an internal
`
`computer bus would be part of the claimed “fast local network” as suggested by
`
`Petitioner, and the Ethernet example in the specification suggests that it would not
`
`8
`
`
`

`

`IPR2013-00109
`Patent 6,757,717
`
`
`be. Pet. 11. Petitioner’s reference to the recitation of “integrally formed” in claim
`
`
`
`8 in support of this argument is not availing. The patentability of claim 8 has not
`
`been challenged; the proper construction of “integrally formed,” which does not
`
`appear in claims 6, 7, or 9, is therefore not before us in this proceeding. Thus, as
`
`Petitioner has provided no persuasive support for its construction of “fast local
`
`network,” we do not adopt it.
`
`
`
`Negative Indication Signal
`
`
`
`We refer to and adopt our previous construction of this term, appearing in
`
`claims 11, 12, and 14, as including the absence of a signal as Petitioner proposes.
`
`Decision 13-14.
`
`
`
`Positive, Partial or Negative Indication Signal
`
`
`
`We see no reason to depart from our prior construction of this term, in
`
`claims 11, 12, and 14, as requiring the issuance of all three alternative signals as
`
`required. Decision 14, 22-24. We accept Petitioner’s further construction of
`
`“partial” indication signal as “any indication treated as a request that a sender send
`
`to the receiver a difference between two data items.” Pet. 12. We further accept
`
`Petitioner’s proposed construction of “positive” indication signal as “any
`
`indication treated as not requesting either the data or a difference.” Id.
`
`
`
`Sender/computer; Receiver/computer
`
`
`
`These terms from claims 11, 12, and 14 were previously construed as “a
`
`computer that sends or receives data, respectively.” Decision 14. Petitioner does
`
`not challenge that construction. Pet. 12. We therefore maintain our previous
`
`construction.
`
`9
`
`
`

`

`IPR2013-00109
`Patent 6,757,717
`
`
`
`
`
`
`
`Receiving a Response Signal from said Receiver/Computer... containing a Positive,
`Partial or Negative Indication Signal for said Digital Digest
`
`
`
`Petitioner does not challenge the previous construction of these terms, from
`
`claims 11, 12, and 14, applying the plain meaning. Pet. 12. We disagree with
`
`Petitioner that the terms “partial” and “positive” have no patentable weight. See
`
`Decision 22-23. We maintain our previous construction.
`
`
`
`If a Negative Indication Signal is Received, Transmitting said Data from said
`Sender Computer to said Receiver Computer
`
`
`
`Similarly, Petitioner does not challenge the previous construction of these
`
`terms, from claims 11, 12, and 14, applying the plain meaning. Pet. 13. We
`
`disagree with Petitioner that the terms have no patentable weight. See Decision
`
`23-24. We maintain our previous construction.
`
`
`
`When a Plurality of Data Objects is to be Sent, a Digital Digest is Sent for Each of
`said Data Objects and a Response Signal is Sent Containing a Separate Indication
`Signal for Each of said Data Objects
`
`
`
`
`Similarly, Petitioner does not challenge the previous construction of these
`
`terms, from claims 11, 12, and 14, applying the plain meaning. Pet. 13. We
`
`disagree with Petitioner that the terms have no patentable weight. See Decision 24.
`
`We maintain our previous construction.
`
`
`
`
`
`
`
`
`
`10
`
`
`

`

`IPR2013-00109
`Patent 6,757,717
`
`
`
`V. PRIOR ART
`
`
`
`
`
`
`
`Petitioner’s challenge to patentability focuses on three references:
`
`(1) Ex. 1003: HTTP DISTRIBUTION AND REPLICATION PROTOCOL, W3C Note
`
`(August 25, 1997) http://www.www3.org/TR/NOTE-drp-19970825 (“DRP”);
`
`(2) Ex. 1004: Mattis et al. US Patent 6,292,880 B1; and (3) Ex. 1006: Yohe et al.
`
`US Patent 5,835,943.
`
`
`
`HTTP Distribution and Replication Protocol (DRP) (Ex. 1003)
`
`
`
`This reference describes a protocol for improving the efficiency and
`
`reliability of data distribution over HTTP. DRP 2, ll.12-13. One of the goals is to
`
`avoid downloading the same data more than once. Id. ll. 29-30. The DRP protocol
`
`makes use of content identifiers based on checksum technology. Id. ll. 37-39. A
`
`content identifier can be used uniquely to identify each piece of data or content and
`
`to determine whether two pieces of content are identical. An example of a
`
`checksum algorithm that can be used for this purpose is the MD5 message digest
`
`algorithm. DRP 3, ll. 24-25.
`
`
`
`To describe the exact state of a set of data files the DRP protocol uses a data
`
`structure called an index. DRP 4, l. 37. An index is a snapshot of the state of a set
`
`of files at a particular moment in time. It is typically stored in memory as a data
`
`tree structure, but to enable clients and servers to communicate this information
`
`over HTTP, an index can be described using XML. Id. at ll. 39-41.
`
`
`
`A DRP index is retrieved by giving a URL to the index. DRP 5, l. 22. The
`
`index can be stored in any file and can be retrieved using a normal HTTP GET
`
`request. Id. at ll. 23-24. Once the initial download is complete, a client can update
`
`content by downloading a new version of the index and comparing it against the
`
`11
`
`
`

`

`IPR2013-00109
`Patent 6,757,717
`
`
`previous versions of the index. Because each file entry in the index has a content
`
`
`
`identifier, the client can determine which files have changed and thus determine
`
`the minimal set of files that need to be downloaded in order to bring the client up
`
`to date. DRP 5, ll. 30-32.
`
`
`
`A new HTTP header field called Content-ID is used to specify the current
`
`correct version of the file that is requested by the client. The server can use the
`
`content identifier in the Content-ID field to determine if the requested version of
`
`the file can be delivered to the client. DPR 7, ll. 30-32. If no content identifier is
`
`specified in the HTTP GET request, the server returns the current version of the
`
`file. Id. at ll. 37-38. When a file is updated on the server, it will be downloaded by
`
`each of the clients that needs the new version. DPR 8, ll. 3-4.
`
`
`
`The DRP protocol document recognizes that updates to files very often
`
`affect only small portions of the file, and it would therefore be much more efficient
`
`if the server could reply with only the parts of the file that have changed. DRP 8,
`
`ll. 4-5. This is achieved using a “differential” GET request. When a file is
`
`modified, the client can issue a differential GET request for the file, which includes
`
`not only the content identifier of the desired version of the file, but also the content
`
`identifier of the current version file on the client. Id. at ll. 11-13. In a differential
`
`GET request the content identifier of the file the client currently possessed is
`
`specified using the Differential-ID field in the HTTP header. Id. at ll. 14-15.
`
`When the server receives a GET request that includes a Differential-ID field, it can
`
`look in its file cache for both versions of the requested file, using the content
`
`identifiers specified in the Content-ID field and the Differential-ID field. If both
`
`versions of the file are found, the server can compute the difference between the
`
`two files and return the difference, rather than the entire file. Id. at ll. 25-27. If the
`
`server does not have access to the version of the file that is indicated by the
`
`12
`
`
`

`

`IPR2013-00109
`Patent 6,757,717
`
`
`differential content identifier, it can ignore the differential content identifier and
`
`
`
`return the entire requested file. Id. at ll. 32-33.
`
`
`
`The DRP reference also describes the use of proxy caching. In this
`
`application, an HTTP proxy can be made aware of the Content-ID and Differential-
`
`ID fields in HTTP requests and replies. DPR 9, ll. 38-39. Because the content
`
`identifier is included in each GET request, the proxy can avoid accidentally
`
`returning the wrong version of the requested file. Id. at ll.39-40. The proxy can
`
`use the content identifier field uniquely to identify the content being transferred as
`
`the same content is likely to have the same content identifier, even when
`
`downloaded from multiple locations. The proxy can thus use this information to
`
`avoid multiple downloads. Id. at ll. 43-45. The proxy can also use the Differential-
`
`ID header field to reply to differential GET requests. If both versions of the file
`
`are in the proxy’s cache, the proxy can provide the differential reply. DPR 10,
`
`ll. 1-2.
`
`
`
`Mattis (Ex. 1004)
`
`
`
`According to Mattis, a key factor limiting the performance of the World
`
`Wide Web is the speed with which servers can supply information to clients via the
`
`Internet. Col. 1, ll. 53-55. Accordingly, client transaction time can be reduced by
`
`storing replicas of popular information objects in repositories geographically
`
`dispersed from the server. Each local repository for object replicas is generally
`
`referred to as cache. Id. at ll. 58-62. In some arrangements, the cache is located in
`
`a proxy server that is logically interposed between clients and the server. The
`
`proxy server is a “middleman gateway,” acting as a server to the client, and the
`
`client to the server. Col. 1 .66 - col.2, l. 3. A proxy server equipped with a cache
`
`is called a “caching proxy server,” or just a “proxy cache.” Col. 2, ll. 3-5.
`
`13
`
`
`

`

`IPR2013-00109
`Patent 6,757,717
`
`
`
`
`The proxy cache intercepts requests for resources that are directed from
`
`
`
`clients to the server. When the cache in the proxy has a replica of the requested
`
`resource that meet certain constraints, the proxy responds to the clients and serves
`
`the resources directly. Col 2, ll. 6-11. In this arrangement the number and volume
`
`of data transfers along the links are greatly reduced. As a result network resources
`
`or objects are provided more rapidly to the clients. Id. at ll. 11-14.
`
`
`
`Mattis uses a “fingerprint” of the content that makes up the object itself to
`
`locate the object. Col. 8, ll. 18-21. Specifically the object key is a unique
`
`“fingerprint” or compressed representation of the contents of the object. A copy the
`
`object is provided as an input to a hash function (e.g. MD5) and its output is the
`
`object key. Given a content fingerprint key, the content can easily be found in the
`
`cache. Id. at ll. 23-36. In some embodiments of Mattis, for each of the objects, the
`
`cache also creates a name object key. The name key is created by applying a hash
`
`function to the name of the object. Id. at ll. 55-58. Mattis recognizes that requests
`
`for objects typically identify requested objects by name such as a URL, file system
`
`name, or network address. Col. 9, l. 65-col. 10, l. 4.
`
`
`
`In one embodiment of Mattis, a lookup operation is used to determine
`
`whether a particular object identified by particular name is currently stored in the
`
`cache. See figure 9A. When the process is applied in the context of the World
`
`Wide Web, the name is a uniform resource locator or URL. Col. 27, ll. 61-62. The
`
`cache converts the name of the object to a key value by passing the object name or
`
`URL to hash function such as MD5. Id. at ll. 63-67. The key is checked against a
`
`directory, and if the requested object is found it is retrieved from storage and sent
`
`to the client. Col. 28, ll. 10-14. If the object is not found in storage the cache
`
`obtains a copy of the object from the appropriate server. Id. at ll. 43-47.
`
`
`
`14
`
`
`

`

`IPR2013-00109
`Patent 6,757,717
`
`Yohe (Ex. 1005)
`
`
`
`
`
`This patent is described in the Decision at pages 7-8.
`
`
`
`
`
`Admitted Art (Ex. 1002, Figs.1,2)
`
`
`
`Additionally, Petitioner relies on ʼ717 patent Figures 1 and 2 (both labeled
`
`“Prior Art”). Pet. 6. Figure 1, described in the patent as a prior art wide-area
`
`network (col. 5, l. 40), depicts a client (4) caching data from network (2) in a
`
`cache (6). When data from a remote server (8) is requested, the client first
`
`searches its local cache. If the requested data is available in the cache, and is
`
`verified to be valid, the client uses it and transmission over the network is not
`
`required. Col. 1, ll. 20-25. In Figure 2, gateway or proxy cache (10, 12) can
`
`operate in a similar manner. Id. at ll. 25-26.
`
`
`
`
`
`VI. ANALYSIS
`
`Anticipation – Claims 6, 7, and 9
`
`
`
`Petitioner contends that each of these claims is anticipated by DRP and
`
`Mattis, and that claims 6 and 7 are anticipated by Yohe. Pet. 4. Petitioner’s
`
`detailed analysis of these claims in relation to DRP, Mattis, and Yohe is set forth at
`
`pages 3-15 of the claim charts that accompanied the Petition as Exhibit A
`
`(Ex. 1001).3 We have reviewed the charts and in addition the supporting
`
`declaration of Professor Darrell D. E. Long. Ex.1013. We find credible and
`
`therefore accept Professor Long’s conclusions on the level of skill in the art and
`
`
`3 Claim charts, when submitted, should be part of the petition and not a separate
`exhibit. See Office Patent Trial Practice Guide, 77 Fed. Reg. 48756, 48764 (Aug.
`14, 2012). Here, however, because the page limit was not exceeded by the
`combined submission, the Board made an exception to the preferred practice.
`
`15
`
`
`

`

`IPR2013-00109
`Patent 6,757,717
`
`
`the state of the art during the relevant time period. Long Decl. pp. 8-9. We will
`
`
`
`address other aspects of the Long declaration in the analysis that follows.
`
`
`
`The legal standard for anticipation is exacting: “A claim is anticipated only
`
`if each and every element as set forth in the claim is found, either expressly or
`
`inherently described, in a single prior art reference.” Verdegaal Bros., Inc. v.
`
`Union Oil Co. of Cal., 814 F.2d 628, 631 (Fed. Cir. 1987).
`
`
`
`The Board is persuaded by Petitioner’s analysis of DRP and Yohe that there
`
`is a reasonable likelihood that Petitioner will prevail on proving anticipation of
`
`claims 6, 7, and 9 by DRP and claims 6 and 7 by Yohe.
`
`
`
`Both DRP and Yohe are reasonably likely to meet the “gateway”
`
`requirement of the claims. As to DRP, we agree with Petitioner that the “gateway”
`
`requirement is likely to be met by the proxy cache server. App. A 3. As to Yohe,
`
`the requirement is likely to be met by the communication server, which acts as a
`
`gateway for communications between client (12) and cache verifying
`
`computer (14) and file server computer (8). App. A 4. We further agree that the
`
`“caching computer” requirement is reasonably likely to be met in both. App. A 6.
`
`In DRP, a client, proxy cache, or HTTP server operating under the DRP protocol
`
`would likely meet the “caching computer” requirement. App. A 6. In the DRP
`
`protocol, each client computer and each HTTP server stores files in its disc cache.
`
`Pet. 14. Each client and each server compares MD5 digests it has previously
`
`stored in its cache memory. Id. In Yohe, this requirement is likely to be met by
`
`the cache verifying computer (14) and file server computer (18) linked by LAN
`
`(20). App. A 6. Finally, we agree with Petitioner that the “network cache
`
`memory” requirement is likely to be met in both. App. A 10. In DRP, the HTTP
`
`servers, clients, and proxy servers have such memory. See supra. In Yohe, the file
`
`server includes permanent disk storage for caching files. App. A10
`
`16
`
`
`

`

`IPR2013-00109
`Patent 6,757,717
`
`
`
`
`We are, however, not persuaded by Petitioner’s contentions that Mattis
`
`
`
`anticipates these claims. While we agree with the analysis of Mattis as generally
`
`meeting the “gateway” and “caching computer” claim requirements (see generally
`
`App. A) , the claims require “means for comparison between a digital digest on
`
`data in its network cache memory and a digital digest received from said packet
`
`switched network through said gateway.” (Emphasis added). In Mattis, as
`
`Petitioner recognizes, the Web cache proxy receives the URL of a requested object
`
`and not its MD5 digest. Pet. 21. Confirming this fact, Mattis observes:
`
`“Unfortunately, requests for objects typically do not identify requested objects
`
`using the object keys for the objects. Rather, requests typically identify requested
`
`objects by name.” Mattis col 9, l. 65- col. 10, l. 1. The examples given by Mattis
`
`include the URL. Id. at col. 10, l. 4. Thus in Mattis’ Figure 9A embodiment for
`
`the World Wide Web, the cache calculates the MD5 digest from the URL. See
`
`supra. It does not receive the digest from the network as the claims require. We
`
`therefore conclude that for this reason Petitioner has not established a reasonable
`
`likelihood of prevailing on this issue of anticipation by Mattis.
`
`
`
`As to dependent claims 7 and 9, we agree with Petitioner that the additional
`
`requirements of those claims are reasonably likely to be met in DRP and Mattis
`
`(for claims 7 and 9) and Yohe (for claim 7). App. A (Ex. 1001) 14-15. Under
`
`DRP the servers compute MD5 digests of all files in the system as required by
`
`claim 7. App. 14. Likewise, in Mattis the proxy cache calculates MD5 digests.
`
`See supra; App. A 14. In Yohe, the verifying agent in the cache computer includes
`
`a block signal generator (54) and a directory signal generator (57) for calculating
`
`digests. Id. In DRP both the proxy and the HTTP servers can store MD5 content
`
`identifiers on disk files as required by claim 9. See App. A 15. In Mattis the proxy
`
`17
`
`
`

`

`IPR2013-00109
`Patent 6,757,717
`
`
`cache stores the MD5 object keys and name keys in permanent, non-volatile
`
`
`
`storage. App A. 15.
`
`
`
`Anticipation – Claims 11, 12, and 14
`
`
`
`Petitioner claims that each of these claims is anticipated by DRP. Pet. 4.
`
`Petitioner’s detailed analysis of the claims in relation to DRP is set forth at
`
`pages 16-22 of Appendix A (Ex. 1001). We have reviewed Petitioner’s analysis
`
`and conclude that Petitioner has a reasonable likelihood of prevailing on this issue.
`
`We agree with Petitioner that the “negative indication” requirement is reasonably
`
`likely to be met by the client’s GET request for a file as described supra. We
`
`further agree that the differential GET request described supra is reasonably likely
`
`to meet the requirement for a “partial indication.” Finally, as we have construed a
`
`“positive indication signal” as “any indication,” the absence of either a GET or a
`
`differential GET in DRP is reasonably likely to meet that requirement.
`
`
`
`We further conclude that the “multi-file get requests” referred to in DRP
`
`(p. 6, l. 43) likely meets the claim 14 requirement for sending a digital digest for
`
`each of a plurality of data object to be sent. Similarly, Petitioner has established a
`
`reasonable likelihood that the other requirements of these claims are met by DRP.
`
`See App. A 15-22.
`
`
`
`Obviousness – Claims 6, 7, and 9
`
`Petitioner contends that these claims would have been obvious over the
`
`combination of Mattis and DRP. Pet. 4. We agree with Petitioner that when
`
`combined the references meet all requirements of these claims. App. A 15-22. A
`
`rationale for combining the references is set forth in the Long Declaration, supra.
`
`Among the reasons given by Professor Long are that the references are directed to
`
`18
`
`
`

`

`IPR2013-00109
`Patent 6,757,717
`
`
`the same problem (the desire to reduce redundancy in network data transmissions),
`
`
`
`the same solution (each uses MD5 digest fingerprints), and the same application
`
`(same type of content and distribution system). Long Decl. 10-14. Professor Long
`
`acknowledges that in Mattis’ disclosure the clients typically request an object by
`
`its URL or other name. Id. 14. Professor Long discusses the fact that Mattis
`
`therefore includes the capability of first converting object names to MD5 digests,
`
`and thereafter uses the MD5 digests. See discussion of object keys supra.
`
`Professor Long concludes that Mattis and DRP would “fully operate together.” Id.
`
`We find Professor Long’s analysis credible, and when considered together
`
`with Petitioner’s claim charts, we are persuaded by this evidence that Petitioner has
`
`demonstrated a reasonable likelihood of prevailing on the issue of obviousness of
`
`claims 6, 7, and 9 over Mattis and DRP.
`
`Petitioner also contends that these claims would have been obvious over the
`
`combination of Mattis, DRP, Yohe, and the Admitted Art discussed supra. Pet. 5,
`
`27. Petitioner has provided a sufficient rationale for combining Mattis and DRP
`
`(see supra), but not the other references. See KSR Int’l Co. v. Teleflex Inc., 550
`
`U.S. 389, 418 (2007) (“…there must be some articulated reasoning with some
`
`rational underpinning to support the legal conclusion of obviousness.”); 37 C.F.R.
`
`§ 42.104 (b)(4)(“The petition must specify where each element of the claim is
`
`found in the prior art patents or printed publications relied upon[.]”) Petitioner has
`
`failed to provide a detailed analysis establishing a reasonable likelihood of
`
`prevailing on the issue of obviousness based on this combination.
`
`
`
`Obvio