Petition for Inter Partes Review of
`U.S. Patent No. 7,188,145
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
` ____________
`
`RELOADED GAMES, INC.
`Petitioner
`
`v.
`
`PARALLEL NETWORKS LLC
`Patent Owner
`
`____________
`
`Case No. TBD
`Patent 7,188,145
` ____________
`
`
`
`PETITION FOR INTER PARTES REVIEW
`
`OF U.S. PATENT NO. 7,188,145
`
`
`
`
`
`

`
`TABLE OF CONTENTS
`
`  
`
`
`
`TABLE  OF  CONTENTS  .............................................................................................................................................  2  
`I.  
`INTRODUCTION  ...............................................................................................................................................  1  
`II.   REQUIREMENTS  FOR  IPR  UNDER  37  C.F.R.  §  42.104  ...............................................................................  1  
`A.   GROUNDS  FOR  STANDING  UNDER  37  C.F.R.  §  42.104(A)  ..............................................................................................  1  
`B.  
`IDENTIFICATION  OF  CHALLENGE  UNDER  37  C.F.R.  §  42.104(B)  AND  RELIEF  REQUESTED  .........................................  1  
`1.   The Grounds For Challenge ................................................................................................ 2  
`2.   Claim Construction Under 37 C.F.R. § 42.104(b)(3) ............................................................. 2  
`3.   Level of a Person Having Ordinary Skill in the Art ............................................................... 9  
`III.   SUMMARY  OF  THE  ‘145  PATENT  ............................................................................................................  10  
`A.   DESCRIPTION  OF  THE  ALLEGED  INVENTION  OF  THE  ‘145  PATENT  ..............................................................................  10  
`B.   SUMMARY  OF  THE  PROSECUTION  HISTORY  OF  THE  ‘145  PATENT  ...............................................................................  11  
`IV.   THERE  IS  A  REASONABLE  LIKELIHOOD  THAT  THE  CHALLENGED  CLAIMS  ARE  UNPATENTABLE
`13  
`A.   TIWANA  ANTICIPATES  CLAIMS  1-­‐28  AND  35  UNDER  35  U.S.C.  §  102(B)  .................................................................  13  
`B.   SMITH  ANTICIPATES  CLAIMS  1,  8-­‐9,  11-­‐15,  22-­‐23,  AND  25-­‐28  UNDER  35  U.S.C.  §  102(E)  ..................................  25  
`C.   SMITH  IN  VIEW  OF  INOHARA  RENDERS  CLAIMS  2-­‐4,  6-­‐7,  10,  16-­‐18,  20-­‐21,  24,  AND  29-­‐36  OBVIOUS  UNDER  35  
`U.S.C.  §  103(A)  ........................................................................................................................................................................  34  
`D.   TIWANA  IN  VIEW  OF  INOHARA  RENDERS  CLAIMS  29-­‐36  OBVIOUS  UNDER  35  U.S.C.  §103(A)  ................................  51  
`V.   MANDATORY  NOTICES  UNDER  37  C.F.R.  §  42.8(A)(1)  .........................................................................  58  
`A.   REAL  PARTY-­‐IN-­‐INTEREST  AND  RELATED  MATTERS  ....................................................................................................  59  
`B.   LEAD  AND  BACK-­‐UP  COUNSEL  UNDER  37  C.F.R.  §  42.8(B)(3)  ..................................................................................  59  
`C.   PAYMENT  OF  FEES  UNDER  37  C.F.R.  §  42.103  .............................................................................................................  60  
`VI.   CONCLUSION  ...............................................................................................................................................  60  
`
`
`
` 2
`
`
`
`

`
`I.
`
`INTRODUCTION
`
`Petitioner Reloaded Games, Inc. (“Petitioner”) requests an Inter Partes Review
`
`(“IPR”) of claims 1-36 (collectively, the “Challenged Claims”) of U.S. Patent No.
`
`7,188,145 (the “’145 Patent”) issued on March 6, 2007 to Keith A. Lowery, et al.
`
`(“Applicants”). Exhibit 1001, ‘145 Patent.
`
`II. REQUIREMENTS FOR IPR UNDER 37 C.F.R. § 42.104
`
`Each requirement for IPR of the ‘145 Patent is satisfied under §42.104.
`
`A. Grounds for Standing Under 37 C.F.R. § 42.104(a)
`
`Petitioner certifies that the ’145 Patent is available for IPR and that the Petitioner is
`
`not barred or estopped from requesting IPR challenging the claims of the ’145 Patent.
`
`Specifically, Petitioner states: (1) Petitioner is not the owner of the ’145 Patent; (2)
`
`Petitioner has not filed a civil action challenging the validity of any claim of the ‘145
`
`Patent; (3) this Petition is filed less than one year after the Petitioner was served with a
`
`complaint alleging infringement of the ‘145 Patent; and (4) this Petition is filed more than
`
`nine months after the ‘145 Patent issued and the ‘145 Patent was not the subject of a post-
`
`grant review.
`
`B.
`
`Identification of Challenge Under 37 C.F.R. § 42.104(b) and Relief
`Requested
`
`In view of the prior art, evidence, and claims charts, claims 1-36 of the ‘145 Patent
`
`are unpatentable and should be cancelled. 37 C.F.R. § 42.104(b)(1).
`
`
`
` 1
`
`

`
`1.
`
`The Grounds For Challenge
`
`Based on the prior art references identified below, IPR of the Challenged Claims
`
`should be granted. 37 C.F.R. § 42.104(b)(2).
`
`Proposed Statutory Rejections for the ‘145 Patent
`Claims 1-28 and 35 are anticipated under §102(e) by Tiwana.
`
`Exhibit No.
`1004, 1005
`
`Claims 1, 8-9, 11-15, 22-23, and 24-28 are anticipated under § 102(e)
`
`1006
`
`by Smith.
`
`Claims 2-4, 6-7, 10, 16-18, 20-21, 24, and 29-36 are obvious under §
`
`1006, 1007
`
`103(a) over Smith in view of Inohara.
`
`Claims 29-36 are obvious under §103(a) over Tiwana in view of
`
`1004, 1005
`
`Inohara.
`
`and 1007
`
`
`
`Section IV identifies where each element of the Challenged Claims is found in the
`
`prior art patents. 37 C.F.R. § 42.104(b)(4). The exhibit numbers of the supporting
`
`evidence relied upon to support the challenges are provided above and the relevance of
`
`the evidence to the challenges raised are provided in Section IV. 37 C.F.R.
`
`§ 42.104(b)(5). Exhibits 1001 – 1010 are also attached.
`
`2.
`
`Claim Construction Under 37 C.F.R. § 42.104(b)(3)
`a) Broadest Reasonable Interpretation of the Claims
`
`A claim subject to IPR receives the “broadest reasonable construction in light of
`
`the specification of the patent in which it appears.” 37 C.F.R. § 42.100(b). For purposes
`
`
`
` 2
`
`

`
`of IPR only, Petitioner submits that all terms of the ‘145 Patent claims should be given
`
`their ordinary and customary meaning that the term would have to one of ordinary skill in
`
`the art1, subject to the following constructions:
`
`i)
`
`“CRMSG_UPDATEPEERLIST,”
`“CRMSG_REQUESTTOJOIN,”
`“CRMSG_WAKEUP” Data Messages
`
`and
`
`Claims 3, 17, 31, and 34
`
`require
`
`the
`
`join
`
`request comprises a
`
`“CRMSG_REQUESTTOJOIN” or “CRMSG_REQUESTTOJOTN” data message.
`
`Claims
`
`6
`
`and
`
`20
`
`require
`
`the
`
`allow message
`
`comprises
`
`a
`
`“CRMSG_UPDATEPEERLTST” or “CRMSG_UPDATEPEERLIST” data message.
`
`Claims 30 and 33 require “the community request comprises a CRMSG_WAKEUP data
`
`message.” The ‘145 patent describes these specific data message types as being part of
`
`the “Dynamic Reef Protocol (DRP).” Ex. 1001 at 27:61-28:17. During the original
`
`prosecution, the Examiner found that a data message conveying each of a request to join
`
`a group, an updated peer list, and a community request satisfies the claimed
`
`“CRMSG_REQUESTTOJOIN,”
`
`“CRMSG_UPDATEPEERLIST,”
`
`and
`
`“CRMSG_WAKEUP” messages, respectively. See, e.g., Ex. 1008, ‘145 File History at
`
`May 16, 2006 Office Action, pp. 9, 11, 13. Petitioner disagrees with the original
`
`
`
` 1
`
` The claim construction analysis is not a concession by Petitioners as to the proper scope
`
`of any claim term in any litigation. These assumptions are not a waiver of any argument
`
`in any litigation that claim terms are indefinite or otherwise invalid.
`
`
`
` 3
`
`

`
`Examiner’s interpretation of these specific message types as overly broad and in violation
`
`of the doctrine of claim differentiation. Petitioner submits that under the broadest
`
`reasonable interpretation, the claims should be limited to the specifically claimed DRP
`
`message types. However, for purposes of this Petition, Petitioner demonstrates that the
`
`prior art references discussed below teach data messages consistent with the original
`
`Examiner’s interpretation.
`
`ii)
`
`Claim 5
`
`Claim 5 depends from claim 4 and includes certain identical limitations to claim 4
`
`(compare claims 4 and 5 “generating an allow message” and “communicating the allow
`
`message to the client”). Claim 5 also includes inconsistent limitations (compare claim 4
`
`“associating the peer list with the allow message” with claim 5 “generating an allow
`
`message comprising the peer list updated to include the client”) that, when read in the
`
`context of the entire claim, are not supported by the ‘145 patent specification. Since
`
`challenges under 35 U.S.C. § 112 are not available in IPR petitions, Petitioner
`
`demonstrates that the method steps of claim 5 are unpatentable.
`
`b) Construction of Means-Plus-Function Terms
`
`Claims 35 and 36 include recitations in means-plus-function form. Petitioner
`
`proposes that each of the below phrases is governed by 35 U.S.C. § 112, ¶6 (now 35
`
`U.S.C. § 112(f)) and proposes the following constructions:
`
`i)
`
`
`
`means for providing a cache community on a first side of a point of presence, the
`cache community comprising at least one peer, the cache community being
`
` 4
`
`

`
`associated with content obtained from a second side of the point of presence, the
`content being cached by the at least one peer
`
`The stated function is “providing a cache community on a first side of a point of
`
`presence, the cache community comprising at least one peer, the cache community being
`
`associated with content obtained from a second side of the point of presence, the content
`
`being cached by the at least one peer.” There is no structure disclosed in the ‘145 patent
`
`to perform the stated function; however, since challenges under 35 U.S.C. § 112 are not
`
`available in IPR petitions, Petitioner demonstrates that the claimed function is
`
`unpatentable below. Ex. 1001 at 9:4-10:12, 17:52-18:30, 18:35-63, Figs. 1, 6.
`
`ii) means for allowing a client to join the cache community
`
`The stated function is “allowing a client to join the cache community.” The only
`
`structure arguably suggested to perform the function is one or more general purpose
`
`computers programmed to: 1) evaluate join request to determine whether the client will
`
`be allowed to join the cache community based on the criteria described at 20:53-64 and
`
`25:1-8; and 2) decide whether the client is allowed to join the cache community based on
`
`the evaluation. Id. at 20:49-21:1, 25:1-10, 25:19-21, 15:11-17:23, 18:4-25, 18:31-34,
`
`22:3-10, Fig. 10, steps 902 and 904.
`
`iii) means for updating a peer list associated with the cache community to include the
`client, the peer list indicating the peers in the cache community
`
`The stated function is “updating a peer list associated with the cache community to
`
`include the client, the peer list indicating the peers in the cache community.” The only
`
`structure arguably suggested to perform the function is one or more general purpose
`
`
`
` 5
`
`

`
`computers. The specification provides no details for how the function of updating a peer
`
`list is accomplished beyond stating that the peer list is updated. Id. at 24:20-21, 18:4-30,
`
`21:1-9, 18:31-34, 22:17-24, Fig. 9, step 614, Fig. 10, step 908.
`
`iv) means for associating the content with the client based on joinder of the client
`
`The stated function is “associating the content with the client based on joinder of
`
`the client.” The only structure arguably suggested to perform the function is one or more
`
`general purpose computers programmed to update an allocation list table to include the
`
`client. The specification provides no details for how the allocation list table is updated. Id.
`
`at 25:21-25, Fig. 10, step 912, claim 11; also 21:10-13, 12:61-13:7, 15:27-16:61.
`
`v) means for re-allocating the cache storage of the content among the peers in the
`cache community in response to allowing the client to join the community
`
`The stated function is “re-allocating the cache storage of the content among the
`
`peers in the cache community in response to allowing the client to join the community.”
`
`The only structure arguably suggested to perform the function is one or more general
`
`purpose computers programmed to: 1) renegotiate cache shares among peers in the cache
`
`community as described at 15:29-34 and 2) update an allocation list table to reflect which
`
`peers cache which content. Petitioner notes that the specification provides no meaningful
`
`difference between the claimed “means for associating …” and the claimed “means for
`
`re-allocating ….” Both functions appear to be accomplished by updating an allocation list
`
`table, but the specification provides no details for how the allocation list table is updated
`
`
`
` 6
`
`

`
`or how cached shares are renegotiated based on joinder of a client. Id. at 21:10-13, 25:21-
`
`25, Fig. 10, step 912, 15:29-34, claim 11.
`
`vi) means for communicating a community request to an administration module
`
`The stated function is “communicating a community request to an administration
`
`module.” The only structure arguably suggested to perform the function is a DSL
`
`modem, a cable modem, a LAN, or other “always-on” Internet connection. Id. at 20:19-
`
`30, 19:33-57, 23:44-46, Fig. 9, step 400, 6:30-7:5, 9:4-52, 13:15-21.
`
`vii) means for receiving a community list from the administration module in response
`to the community request, the community list including a list of communities
`
`The stated function is “receiving a community list from the administration module
`
`in response to the community request, the community list including a list of
`
`communities.” The only structure arguably suggested to perform the function is software
`
`or hardware associated with the client operably connected to the Internet for receiving a
`
`community list. Id. at 20:28-33, 23:44-52, 18:31-34, 18:64-19:13, Fig. 9 step 602.
`
`viii) means for selecting one of the communities to attempt to join
`
`The stated function is “selecting one of the communities to attempt to join.” The
`
`only structure arguably suggested to perform the function is one or more general purpose
`
`computers programmed to evaluate various factors associated with the communities on
`
`the community list to determine which community the client should join based on one or
`
`more factors described at 23:60-64 and 20:33-38. Id. at 20:31-40, 23:54-24:9, 18:31-33,
`
`18:64-19:13, Fig. 9, steps 604, 606, 608.
`
`
`
` 7
`
`

`
`ix) means for generating a join request to attempt to join the selected one of
`communities
`
`The stated function is “generating a join request to attempt to join the selected one
`
`of communities.” The disclosed structure is software and/or hardware associated with the
`
`client operable to provide a data message over the Internet, which indicates that the client
`
`wishes to join the selected one of communities. The specification does not provide any
`
`details for how the message is generated. Id. at 19:14-23, 20:41-48, 24:2-5, 18:31-34,
`
`18:64-19:13, Fig. 9, step 610.
`
`x) means for receiving an allow message associated with the selected one of the
`communities
`
`The stated function is “receiving an allow message associated with the selected
`
`one of the communities.” The only structure arguably suggested to perform the function
`
`is software and/or hardware associated with the client operable to receive a data message
`
`over the Internet, which indicates to the client that the client is being allowed to join the
`
`selected one of the communities. Id. at 20:64-21:4, 24:17-20, 18:23-27, 18:31-34, 18:64-
`
`19:13, 25:19-21, Fig. 9, step 612, Fig. 10, step 910.
`
`xi) means for receiving a peer list associated with the selected one of the communities
`
`The stated function is “receiving a peer list associated with the selected one of the
`
`communities.” The only structure arguably suggested to perform the function is software
`
`and/or hardware associated with the client operable to receive a data message over the
`
`Internet, which indicates a list of peers in the selected one of the communities. Id. at
`
`20:64-21:4, 22:11-24, 25:17-21, 18:28-34, Fig. 10, step 910.
`
`
`
` 8
`
`

`
`xii) means for receiving content allocated for storage in caches of peers in the peer list
`for cache storage re-allocation in response to joining the selected one of the
`communities
`
`The stated function is “receiving content allocated for storage in caches of peers in
`
`the peer list for cache storage re-allocation in response to joining the selected one of the
`
`communities.” The only structure arguably suggested to perform the function is software
`
`or hardware associated with each of the peers in the peer list operable to receive content
`
`for storage in cache. Id. at 16:39-64, Fig. 4 step 306, 18:31-49, 23:34-37, 14:46-51.
`
`xiii) means for providing content for cache storage re-allocation to peers in the peer list
`in response to joining the selected one of the communities
`
`The stated function is “providing content for cache storage re-allocation to peers in
`
`the peer list in response to joining the selected one of the communities.” The only
`
`structure arguably suggested to perform the function is software and/or hardware
`
`associated with each of the peers in the peer list and/or an origin server, each operable to
`
`provide content for cache storage to peers in the peer list. Id. at 16:39-64, Fig. 4, step 306,
`
`18:31-49, 9:53-10:1, 19:24-25, 23:34-37, 14:46-51, Fig. 3, steps 216, 218.
`
`3.
`
`Level of a Person Having Ordinary Skill in the Art
`
`A person having ordinary skill in the art at the time of the ‘145 Patent would have
`
`a B.S. in computer science or related engineering discipline or equivalent experience and
`
`at least two years in networking or equivalent experience or education. The person would
`
`also have some knowledge of networking of computers, distributed systems, data
`
`
`
` 9
`
`

`
`caching, and implementation of distributed networks in computer systems. See, Ex.
`
`1002, Danzig Declaration at ¶ 9.
`
`III. SUMMARY OF THE ‘145 PATENT
`A. Description of the Alleged Invention of the ‘145 Patent
`
`The ‘145 Patent describes a method and system for caching data, for example, in a
`
`community network. Ex. 1001, ‘145 Patent at 1:39-45, Fig. 3. The method of the ‘145
`
`Patent is based on the presence of a cache community having one or more peers that
`
`cache content. Id. at Abstract. The method allows clients to join the community upon
`
`request, after which a peer list is updated to include the client and content is associated
`
`with the client. Id. at 23:43-24:33, 25:17-30. In response to the joinder of a new client, the
`
`cache storage of the peers in the community is re-allocated. Id. at 25:23-25.
`
`In another embodiment of the method, a request is made to an administration
`
`module for a list of communities. Id. at 23:43-46. In response, the client selects a
`
`community and generates a request in an attempt to join the selected community. Id. at
`
`23:48-24:9. If successful, an allow message and peer list associated with the community
`
`are received by the client. Id. at 24:65-25:21. Based on the addition, each peer receives
`
`content for cache storage re-allocation and each peer and/or origin server provides
`
`content for cache storage re-allocation. Id. at claim 29. The systems described by the ‘145
`
`Patent relate to logic encoded on storage and operable to implement the methods
`
`described above, or other “means for” performing the methods. See e.g., claims 15-36.
`
`
`
` 10
`
`

`
`B.
`
`Summary of the Prosecution History of the ‘145 Patent
`
`The ‘145 Patent was filed as U.S. Ser. No. 09/759,406 (“the ‘406 Application”) on
`
`January 12, 2001 with 105 initial claims. See Ex. 1008, ‘145 File History at As-Filed
`
`Application. On August 5, 2004, the Examiner indicated that Applicants had verbally
`
`selected Group One in response to a restriction requirement made over the phone and
`
`also rejected all of the elected claims under 35 U.S.C. §102(e) as anticipated by U.S.
`
`Patent No. 6,330,605 to Christensen, et al. Id. at 3-7. In response, Applicants amended
`
`their claims to include limitations relating to the location of a cache community relative
`
`to a “point of presence.” Id. at November 5, 2004 Office Action Response, p. 2. The PTO
`
`issued a final rejection of all claims on March 1, 2005 as being anticipated by Christensen
`
`and/or obvious over Christensen in view of U.S. Patent No. 6,785,704 to McCanne. Id. at
`
`March 1, 2005 Office Action, pp. 2-7.
`
`After Applicants requested continued examination on April 29, 2005 to garner
`
`consideration of an amendment after final, the PTO again rejected all claims, this time
`
`finding three independent claims anticipated by U.S. Patent No. 5,864,854 to Boyle and
`
`the remaining claims obvious over Boyle in view of U.S. Patent No. 6,477,150 to
`
`Maggenti et al. On September 7, 2005, Applicants attempted to argue over the rejection
`
`without amending the claims and the PTO issued a final rejection on the same grounds on
`
`November 25, 2005.
`
`
`
` 11
`
`

`
`Applicants again requested continued examination after submitting an amendment
`
`after final that was not entered as it would involve further search. In their RCE,
`
`Applicants amended the independent claims to include limitations relating to “allocating
`
`the first content portion and second content portion among the peers in the cache
`
`community in response to allowing the client to join the community.” Id. at February 26,
`
`2006 Response, pp. 2, 5, 12, 13.
`
`On May 16, 2006, the PTO issued another rejection of three independent claims
`
`under §102(b) as anticipated by Boyle, of additional claims as anticipated by Maggenti
`
`under §102(e) and the remaining claims as obvious over Boyle in view of Maggenti. On
`
`August 16, 2006, among other amendments, Applicants amended all claims to include a
`
`limitation generally relating to re-allocation of cache storage among the peers. Id. at
`
`August 16, 2006 Response, at claim 1.
`
`On October 24, 2006, the USPTO mailed a Notice of Allowance and the patent
`
`issued on March 6, 2007 with 36 claims. The Notice of Allowance noted the following
`
`reason for allowance:
`
`The prior art of record does not disclose, teach, or suggest neither singly nor
`in combination the claimed limitation of “re-allocating the cache storage of
`the content among the peers in the cache community, in response to
`allowing the client to join the community” as recited in claims 1, 16, 101
`and similarly recited in claims 95, 98 and 105.
`Id. at October 24, 2006 Notice of Allowance.
`
`
`
` 12
`
`

`
`IV. THERE
`IS A REASONABLE LIKELIHOOD THAT THE
`CHALLENGED CLAIMS ARE UNPATENTABLE
`
`Distributed caching systems were prevalent well before January 12, 2001. The
`
`following prior art references disclose each limitation of the Challenged Claims. As such,
`
`the Challenged Claims are unpatentable. Included in the claim charts below are
`
`exemplary citations to the prior art references.
`
`Tiwana Anticipates Claims 1-28 and 35 Under 35 U.S.C. § 102(b)
`
`A.
`U.S. Patent No. 7,069,324 to Tiwana et al. (Ex. 1004) incorporates by reference a
`
`number of related applications, including U.S. Prov’l Appln. No. 60/168,862 (Ex. 1005),
`
`which further describes portions of the invention (collectively “Tiwana”). Ex. 1004 at 7:64-8:1
`
`Tiwana discloses a distributed web-caching structure. Id. at Abstract. Tiwana teaches a group
`
`of web-caches (referred to as a “web-cache cluster” or “Server Group”) with the main goal of
`
`optimizing resource usage and lowering response times. Id. at 1:28-33, 2:18-19; Ex. 1005 at 1.
`
`Web-caches or “cache systems” are able to join as members in a cache cluster of other cache
`
`systems connected to a router. Id. at 6:16-27. Tiwana describes updating a list of web-caches
`
`in a group, associating content with a web-cache when it joins a group and allocating storage
`
`among the cluster when membership in the group changes. Id. at 5:63-6:15; Ex. 1005 at 9, 43.
`
`The identified structure for performing the corresponding functions of the “means for”
`
`limitations of claim 35 is the same as or equivalent to the structure disclosed in the ‘145
`
`Patent because it performs the same functions in substantially the same ways and with
`
`
`
` 13
`
`

`
`substantially the same results as the corresponding structure in the ‘145 Patent. MPEP
`
`§2283. Claims 1-28 and 35 should be rejected under § 102(b) as anticipated by Tiwana.
`
`Claim 1
`1. A method for
`dynamic
`distributed data
`caching
`comprising:
`
`[1(a)] providing
`a
`cache
`community on a
`first side of a
`point
`of
`presence,
`the
`cache
`community
`at
`comprising
`least one peer,
`the
`cache
`community
`being associated
`with
`content
`obtained from a
`
`
`
`Anticipated By Tiwana (Ex. 1004)
`Tiwana discloses dynamic distributed data caching.
`“Network caching represents an improvement over the proxy server
`model. Network caching
`is
`transparent
`to end users, high
`performance, and fault tolerant. By altering the operating system code
`of an existing router, the router is enabled to recognize and redirect
`data traffic having particular characteristics such as, for example, a
`particular protocol intended for a specified port (e.g., TCP with port
`80), to one or more network caches connected to the router via an
`interface having sufficient bandwidth. If there are multiple caches
`connected to the cache-enabled router, the router selects from among
`the available caches for a particular request based on the destination IP
`address specified in the packet.” Ex. 1004 at 2:17-29.
`“[T]he present invention provides an apparatus and method for
`intelligently assigning a portion of a cluster's traffic (e.g., buckets) to a
`cache system to minimize overloading of such cache system.” Id. at
`3:17-20.
`“A web-cache joins, and maintains its membership of, a Service
`Group by transmitting a WCCP_HERE_I_AM packet to each router
`in the Group[.]”Ex. 1005 at 6; also at 1, 9.
`Tiwana discloses a “cache cluster” (i.e., cache community), also
`referred to as a “Service Group,” on a first side of a point of presence.
`The cache cluster includes one or more cache systems (i.e., peers) that
`are assigned to handle requests for specific objects (i.e., content)
`obtained over the Internet (i.e., from a second side of a point of
`presence) and placed into the appropriate cache system.
`“FIG. 1 is a simplified network diagram which will be used in
`conjunction with the flowcharts of FIGS. 2 and 3 to describe a specific
`embodiment of the present invention. According to this embodiment,
`a plurality of client machines 102 which are resident on a local area
`network (LAN) 104 communicate via router 106 and wide area
`network (WAN) 108, e.g., the internet, with server 110. …
`[T]he router 106 may direct certain traffic, e.g., destined for port 80, to
`a cache system, such as 112a, which is configured to "spoof" server
`
` 14
`
`

`
`second side of
`the
`point
`of
`presence,
`the
`content
`being
`cached by the at
`least one peer;
`
`[1(b)] allowing a
`client to join the
`cache
`community;
`
`110. If there are multiple caches connected to the cache-enabled
`router, the router selects from among the available caches for a
`particular request based on the destination IP address specified in the
`packet. For example, a first set of destination IP addresses may be
`assigned to cache system 112a; a second set of IP addresses to cache
`system 112b; and a third set of IP addresses to cache system 112c. …
`The selected cache system 112 a responds to a request from a client
`102 to obtain objects from destination platform 110. The cache system
`112 a either retrieves objects from destination platform 110 to then
`present to one of the clients or retrieves objects from its own cache
`(which objects were previously retrieved from the destination
`platform 110).” Ex. 1004 at 5:9-51.
`“In the illustrated embodiment, cache systems 112a, 112b, 112c, and
`112d form a cache cluster or farm 120 and cache system 122 form a
`cache cluster 122. Traffic is typically allocated to each cache system
`within the same cache cluster. Traffic may be allocated based on any
`suitable factor. In the illustrated embodiment, traffic is allocated based
`on IP destination address. That is, each cache system is assigned to
`handle requests for objects from a particular set of destination
`addresses.” Id. at 5:63-6:4; also 3:17-20, Fig. 1.
`“Each cache system has a particular capacity. For example, a cache
`system may be configured to handle four buckets of traffic. A bucket
`is generally defined as 1/256th of the total amount of traffic (e.g., IP
`address space) being handled by a particular group of associated cache
`systems (commonly referred to as a "cache cluster" or "cache farm").
`For example, each bucket represents 1/256th of the IP addresses or
`web servers being spoofed by the cache systems within a particular
`cache cluster.” Id. at 2:53-61; also Ex. 1005 at 2, 3, 6.
`Tiwana discloses that a router associated with a cache cluster/Service
`Group receives a “Here I Am” message (i.e., join request) from a
`cache system (i.e., client) wanting to join the cluster and determines
`whether to allow the cache system to join the cluster/Service Group
`based on whether the router has received a valid response from the
`cache system.
`“FIG. 2 is a flowchart representing a bucket assignment process 200
`for a cache system (CS) that is joining a cluster or starting-up in
`accordance with one embodiment of the present invention. Initially,
`the new CS announces its presence in operation 202 to the other CS's
`
`
`
` 15
`
`

`
`and/or router(s) of the cluster. … This bucket allocation procedure
`may be implemented in any of the router’s or CS’s associated with the
`cluster. When allocation is implemented within a CS, that CS is
`commonly referred to as the “lead CS.” The CS with the lowest
`assigned IP address typically functions as the lead CS.” Ex. 1004 at
`6:16-27; also 6:33-34, 12:29-41, 8:11-12.
`“A router considers a web-cache to be a usable member of a Service
`Group only after it has sent that web-cache a WCCP2_I_SEE_YOU
`message and received a WCCP2_HERE_I_AM message with a valid
`"Receive ID" in response.” Ex. 1005 at 4, also at 3.
`Tiwana discloses
`that
`the
`router associated with a cache
`cluster/Service Group updates a list of cache systems (i.e., peer list) in
`the group to include newly allowed cache systems.
`“Each router advertises its view of a Service Group via the Router
`View Info component in the WCCP2_I_SEE_YOU it sends to web-
`caches. This component includes a list of the useable web-caches in
`the Service Group as seen by the router and a list of the routers in the
`Service Group as reported in WCCP2_HERE_I_AMs from web-
`caches. A change number in the component is incremented if the
`Service Group membership has changed
`since
`the
`last
`WCCP2_I_SEE_YOU sent by the router.” Ex. 1005 at 4-5.
`“Identity elements of useable web-caches in Service Group. This list
`contains web-caches
`that
`have
`sent
`the
`router
`a
`WCCP2_HERE_I_AM message with a valid ‘Received ID’.” Id. at
`21.
`“Web Cache 0-n
`List of addresses of useable web-caches in Service Group. The
`position of a web-cache identifier in this list is the web-cache index.
`The first entry in the list has an index of zero.” Id. at 25; also at 3.
`See also Ex. 1004 at 12:29-41, 10:30-60.
`Tiwana discloses that the router or lead CS/designated web-cache
`associated with the cache cluster/Service Group determines and
`assigns the bucket allocation for a new cache system (i.e., client) by,
`for example, updating a hash table.
`“[T]he router 106 may direct certain traffic, e.g., destined for port 80,
`to a cache system, such as 112a, which is configured to "spoof" server
`110. If there are multiple caches connected to the cache-enabled
`router,