throbber
IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`Patent Owner Preliminary
`Response under 35 U.S.C. § 131
`and 37 C.F.R. § 42.107
`
`|
`|
`|
`|
`|
`|
`|
`|
`|
`|
`|
`|
`|
`|
`|
`|
`|
`|
`|
`|
`|
`|
`
`RELOADED GAMES, INC.
`(Petitioner)
`
`v.
`
`PARALLEL NETWORKS LLC
`(Patent Owner)
`
`Case No. IPR2014-00950
`
`Patent No. 7,188,145
`
`Inventors:
`Keith A. Lowery
`Bryan S. Chin
`David A. Consolver
`Gregg A. DeMasters
`
`Filed January 12, 2001
`
`For: Method and System for
`Dynamic Distributed Data Caching
`
`Mail Stop: PATENT BOARD
`Patent Trial and Appeal Board
`US Patent and Trademark Office
`PO Box 1450
`Alexandria, VA 22313-1450
`
`
`
`RESPONSE TO PETITION FOR
`INTER PARTES REVIEW OF US PATENT NO. 7,188,145
`CASE No: IPR2014-00950
`
`59147898_3
`
`

`
`Table of Contents
`Introduction ...................................................................................................... 1 
`
`I.

`
`II.

`
`The Petition is merely a response to the Decision and Patent Owner’s
`
`Preliminary Response in the ‘136 IPR. ........................................................... 2 
`
`
`
`  The combination of Smith and Inohara does not render the Challenged III.
`
`Claims obvious. ............................................................................................... 4 
`
`A. 
`
`B. 
`
`The Teachings of Inohara ...................................................................... 5 
`
`Claims 1, 4, 5, 8, 9, and 11-14 are not obvious over Smith in view of
`
`Inohara. ................................................................................................ 10 
`
`C. 
`
`Claims 15, 18, 19, 22, 23, and 25-28 are not obvious over Smith in
`
`view of Inohara. ................................................................................... 21 
`
`D. 
`
`Conclusion regarding Smith in view of Inohara ................................. 22 
`
`IV.
`
`  Conclusion ..................................................................................................... 23 
`
`A. Appendix of Exhibits .......................................................................................... 25 
`
`
`
`59147898_3
`
`

`
`IPR2014-00950
`Patent No. 7,188,145
`
`
`Introduction
`I.
`In its decision to institute an IPR in related matter IPR2014-00136 (“the
`
`‘136 IPR”), the Board declined to institute an inter partes review of claims 1, 5, 8,
`
`9, 11-15, 18-19, 22-23 and 25-28 of United States Patent No. 7,188,145 (“the ’145
`
`Patent”). In response to the Board’s decision (IPR2014-00136, Paper 13) to
`
`institute the ‘136 IPR (the “Board’s Decision”), the Petitioner now files a new
`
`petition for inter parties review of the aforementioned claims based on the same
`
`prior art references that were the subject of the ‘136 IPR (IPR2014-00950, Paper 3
`
`– the “Petition”).
`
`Procedurally and from a policy perspective, the Petition should be denied
`
`because it is merely a response to the Patent Owner’s Preliminary Response
`
`(IPR2014-00136, Paper 9) and the Board’s Decision. The Petition does not cite
`
`any new art or make any arguments that were not available when Petitioner filed
`
`its petition in the ‘136 IPR. The rules relating to inter partes review (IPR) provide
`
`for a petition, a preliminary patent owner response, and additional briefing and
`
`motion practice (if IPR is granted). These rules do not provide for a petitioner’s
`
`response to the Preliminary Response or to the Board’s Decision, and the Board
`
`should not sanction the filing of serial IPR Petitions as an avenue for motion
`
`practice that is otherwise not allowed by the rules. See generally, 37 CFR § 42.
`
`Such a practice encourages petitioners to withhold arguments that should rightfully
`
`59147898_3
`
`1
`
`

`
`IPR2014-00950
`Patent No. 7,188,145
`be presented in an initial petition, nullifies the procedural rules of this proceeding,
`
`harasses and burdens patent owners by requiring additional responses and potential
`
`changes in tactics, and frustrates the mandate of Congress for the “just, speedy, and
`
`inexpensive resolution” of these disputes. 35 U.S.C. § 316(b).
`
`Substantively, the Petition should be denied because Smith and Inohara are
`
`not combinable to teach or suggest the systems and methods of claims 1, 4, 5, 8, 9,
`
`11-15, 18, 19, 22, 23, and 25-28 (the “Challenged Claims”). Neither Smith nor
`
`Inohara teaches a system that allows a client to join a cache community. Inohara is
`
`cumulative to Smith insofar as the reference is relied upon to teach the claimed
`
`step of allowing a client to join a cache community, and inoperable to the extent
`
`the server group described in Inohara is interpreted as an analog for the claimed
`
`cache community. Neither Smith nor Inohara teaches that a client may be denied
`
`entrance to a cache community and both references consider that each server
`
`seeking to join a cache community is automatically admitted without any potential
`
`for rejection.
`
` The Petition is merely a response to the Decision and Patent Owner’s
`II.
`Preliminary Response in the ‘136 IPR.
`Part 42 of Title 37 of the Code of Federal Regulations sets forth the
`
`documents that may be filed or otherwise entered in the course of instituting an
`
`inter partes review. Part 42 provides for a Petition, Preliminary Response by the
`
`59147898_3
`
`2
`
`

`
`IPR2014-00950
`Patent No. 7,188,145
`Patent Owner, and a Board Decision. §42.71 also provides for a request for
`
`rehearing in response to a Board Decision, but the regulations are otherwise not
`
`crafted to allow a Petitioner to increase the burden on a Patent Owner and the
`
`Board by inundating them with additional pleadings.
`
`The Petition is based on the same art that was referenced in the ‘136
`
`Petition, was not based on any change in facts that occurred since the filing of the
`
`‘136 Petition, and does not include any arguments that Petitioner could not have
`
`made when filing the ‘136 Petition. Instead, the Petition responds to the Board’s
`
`Decision in the ‘136 IPR and Patent Owner’s Preliminary Response in the ‘136
`
`IPR. Thus, the Petition should be viewed as a responsive pleading that is not
`
`provided for in the Code of Federal Regulations or in the ‘136 IPR. See Amended
`
`Scheduling Order, IPR2014-00136, Paper 20, at 6. Granting the Petition in this
`
`matter would effectively sanction the filing of serial IPR Petitions in cases where a
`
`Petitioner is unhappy with the outcome of a Board decision or a portion of the
`
`outcome of a Board Decision – a procedural option that is unduly burdensome for
`
`the Patent Owner and for the Board. For at least the foregoing reasons, the Petition
`
`should be denied.
`
`59147898_3
`
`3
`
`

`
` The combination of Smith and Inohara does not render the Challenged III.
`
`IPR2014-00950
`Patent No. 7,188,145
`
`Claims obvious.
`The Petition contends that the combination of Smith and Inohara render the
`
`Challenged Claims obvious. The allegations of the Petition appear to be based on
`
`the Board’s Decision to order an inter partes review of claims 2-4, 6, 7, 10, 16-18,
`
`20, 21, 24, and 29-36 of the ‘145 Patent to consider whether such claims are
`
`obvious over the combination of Smith and Inohara. More particularly, the
`
`Petitioner asserts that the combination of Smith and Inohara renders all of the
`
`Challenged Claims obvious for the same reasons outlined in the Board’s Decision
`
`with respect to claims 2-4, 6, 7, 10, 16-18, 20, 21, 24, and 29-36, which were based
`
`primarily on the Board’s initial interpretation of Inohara as potentially teaching the
`
`claimed element of “allowing...” as recited by claim 1. However, Inohara can in
`
`no way be said to disclose a limitation of “allowing…” a server to join a cache
`
`community, even using
`
`the Board’s proposed construction of
`
`the
`
`term
`
`“allow[ing]…” as “permit[ting] the presence of…” Moreover, both the Board’s
`
`combination of Smith and Inohara and the Board’s initial interpretation of the
`
`teaching of the disclosed caching system of Inohara would render such system
`
`inoperable for its intended purpose.
`
`59147898_3
`
`4
`
`

`
`IPR2014-00950
`Patent No. 7,188,145
`
`A. The Teachings of Inohara
`
` careful reading of Inohara as a whole is critical to understanding why
`
` A
`
`Inohara cannot be said to teach the recited element of “allowing...” Inohara
`
`describes a process in which all servers requesting to participate in the described
`
`system are added to a single distributed cache hierarchy by an algorithm that
`
`determines an appropriate location for each server in the hierarchy. See Ex. 1007,
`
`FIG. 4; 9:17-10:36. There is no reference in Inohara to a process for determining
`
`whether a server will be added to the single distributed cache hierarchy, much less
`
`denying a server entrance into the single distributed cache hierarchy. In fact, the
`
`primary goal of Inohara is to provide an organizational structure allowing the easy
`
`addition and administration of a large number of servers within a single cache
`
`hierarchy, thereby overcoming limitations on the number of members of previous
`
`cache structures. Id. at 3:48-50; 3:16-22. According to the teachings of Inohara
`
`and using the administrative scheme described in further detail below, the cache
`
`hierarchy disclosed by Inohara is utilized to administer a large scale cache suitable
`
`for use, for example, with an explosively growing network such as the world wide
`
`web. Id. at 1:41-49; 4:20-22.
`
`Inohara describes a hierarchical cache structure that works by caching
`
`content at multiple tiers of a hierarchical tree structure wherein a server at a higher
`
`tier (such as upper leader server 234 in Figure 2 of Inohara) forms a group with
`
`59147898_3
`
`5
`
`

`
`IPR2014-00950
`Patent No. 7,188,145
`each of its branch or leaf servers (such as servers 232, 232’ and 232’’ in Figure 2
`
`of Inohara), which are each logically organized under such higher tier server. Id. at
`
`Figure 2; 7:58-64. A server from the group may obtain content by accessing
`
`content cached by other servers in the hierarchy by interacting with a higher tier
`
`server. For example, upper leader server 234 would in turn have its own group of
`
`branch or leaf servers 234’ and 234’’ and its own upper leader server. Only a
`
`subset of the cached content is stored at each group of servers in a multi-group
`
`configuration, thereby requiring each group to form a common caching hierarchy
`
`with other groups in order to access all cached content according to the teachings
`
`of Inohara. See, e.g., Id. at 6:48-53, 17:1-19, 17:46-48, and 8:14-24 (evidencing
`
`that Inohara employs a “cache movement” process that allocates cached content to
`
`servers in other groups by describing a “cache movement” that includes a
`
`destination of transmission “determined by use of the group table 110 in a manner
`
`similar to that in the case of circulation of the hierarchy maintenance message.”
`
`The group table is defined as “a table that holds some proximate server groups”,
`
`and the hierarchy maintenance message is described as being circulated “over a
`
`plurality of groups.”).
`
`In Inohara, the cache hierarchy is described as being “mutually supporting”,
`
`and as including “groups of a tree structure formed by server groups.” Id. at 4:4-9.
`
`The cache management protocol of Inohara does not function by allocating cached
`
`59147898_3
`
`6
`
`

`
`IPR2014-00950
`Patent No. 7,188,145
`content across an individual server group. Instead, Inohara discloses a “wide-area
`
`cooperative cache management protocol … [that] performs the propagation of a
`
`cache directory (a list of URL's and servers which hold the URL's in caches) using
`
`the multi-cast hierarchy formed by the above-mentioned server status propagation
`
`protocol and a cache control...” Id. at 4:23-32. As taught by Inohara, the multi-
`
`cast hierarchy allows a larger caching community to be structured than would be
`
`possible if single caching groups were utilized with no hierarchical structure. See
`
`Id. at 11:39-42; 3:48-50.
`
`In Inohara, the term “group” consistently denotes a subset of the hierarchical
`
`cache system and not a stand-alone cache system. See, e.g., Id. at 7:46-64; 11:39-
`
`42; 14:21-33. For example, Inohara states that “the multi-cast hierarchy includes
`
`groups of a tree structure formed by server groups” in which servers may request
`
`and be granted membership in the group in accordance with the process shown in
`
`FIG. 5. See Id. at 4:5-6, FIG. 5. Inohara, however, also teaches that each server
`
`and each server group in the multi-cast hierarchy participates in the common cache
`
`management protocol (the multi-cast hierarchy) as a whole, and does not provide
`
`any disclosure to indicate that that the groups are operable as cache systems
`
`without being joined to the hierarchy. See Id. at 14:46-53. Put simply, Inohara
`
`combines server groups to form a single caching system that consists of multiple
`
`server groups included in a single hierarchical structure.
`
`59147898_3
`
`7
`
`

`
`IPR2014-00950
`Patent No. 7,188,145
`Figure 5 of Inohara (focused on by Petitioner) describes how servers are
`
`added to individual server groups and how such server groups are organized
`
`relative to one another in the overall caching hierarchy. As noted by Petitioner,
`
`Inohara does consider the size of an individual server group in determining
`
`whether to add new servers as leafs within the server group or to reorganize the
`
`group relative to such new servers and the overall hierarchy. As Inohara describes,
`
`if “the judgment […] of whether or not the sum of the number of old members and
`
`the number of new members is smaller than MAX” yields a negative result, the
`
`hierarchy representing the cache community and the portion of the cache
`
`community represented by the group are reorganized in either steps 514 and 515 or
`
`518 and 519 to include the server. Id. at FIG. 5, 11:6-42. In the case of steps 514
`
`and 515, the reorganization includes placing the first of the new members into an
`
`existing group and placing the other new members in a lower tier group wherein
`
`the first of the new members is the leader of the lower tier group. Id. at 11:6-17.
`
`Thus, in steps 514 and 515, one previously existing group becomes two groups,
`
`with one upper tier group and one lower tier group that cooperate with each other
`
`(and with the rest of the multi-cast hierarchy) in a single cache community to cache
`
`and share content. Id.
`
`In the case of steps 518 and 519, the reorganization includes placing the first
`
`of the new members into a group with the first of the existing members, placing the
`
`59147898_3
`
`8
`
`

`
`IPR2014-00950
`Patent No. 7,188,145
`other new members in a lower tier group wherein the first of the new members is
`
`the leader of the lower tier group, and placing the other existing members in a
`
`second lower tier group wherein the first of the existing members is the leader of
`
`the second lower tier group. Id. at 11:17-42. Thus, in steps 518 and 519, one
`
`previously existing group becomes three groups, with one upper tier group and two
`
`lower tier groups, such that all groups are part of the same cache community and
`
`cooperate together (and with the rest of the caching hierarchy) to cache and share
`
`data. Id. Importantly, in both of the foregoing methods of reorganization, all of
`
`the new members are accepted into the cache community, all of such new members
`
`are linked with and interact with all of the previous members of the server group,
`
`and there is no potential for refusal to grant entrance to the cache community.
`
`Inohara teaches that the dynamic nature of organizing and reorganizing
`
`groups as the numbers of servers within such groups change allows the groups to
`
`interact as a single caching hierarchy. More particularly, Inohara states that,
`
`“[w]ith the foregoing operation, it becomes possible to make hierarchization
`
`corresponding to a dynamic increase in the number of servers while the maximum
`
`number of members in each group is kept equal to or smaller than MAX.” Id. at
`
`11:39-42. In fact, Inohara even notes that the purpose of arranging the servers into
`
`groups in Inohara is to manage administrative communications within a large
`
`caching hierarchy by limiting the propagation of server information. Id. at 14:21-
`
`59147898_3
`
`9
`
`

`
`IPR2014-00950
`Patent No. 7,188,145
`33. Utilizing the disclosed branched hierarchy of interconnected server groups
`
`therefore allows Inohara to achieve the advantages of having a single caching
`
`hierarchy that is fully scalable with a “very large” number of servers without the
`
`size limitations found in prior art caching systems. See Id. at 4:10-22; 3:34-40;
`
`3:48-50; 4:23-32.
`
`Looking past the individual group formation process focused on by
`
`Petitioner, the overall hierarchical formation of the cache community of Inohara is
`
`described with regard
`
`to FIGS. 4 and 7 of Inohara (construction and
`
`reconstruction), and neither process includes any determination as to whether to
`
`admit a server or server group to the hierarchy. See Id. at 5:11-19, 9:10-10:36, and
`
`13:64-40. Put simply, Inohara never contemplates the possibility of permitting a
`
`server or denying a server entry into a cache community (i.e., the hierarchy
`
`described by Inohara). Instead, the process of Inohara determines how to organize
`
`the new server within the hierarchy. See Id. at 10:37-11:37. Thus, Inohara only
`
`makes a determination of where in a cache community a server should be logically
`
`located.
`
`B. Claims 1, 4, 5, 8, 9, and 11-14 are not obvious over Smith in view
`of Inohara.
`
`Petitioner’s assertion that claims 1, 4, 5, 8, 9, and 11-14 are obvious over
`
`Smith in view of U.S. Patent No. 6,256,747 (“Inohara”) is keyed on interpreting
`
`59147898_3
`
`10
`
`

`
`IPR2014-00950
`Patent No. 7,188,145
`Smith and Inohara as disclosing the element of “allowing a client to join the cache
`
`community.” See Petition at 15-16. As established with regard to the ‘136 IPR,
`
`contrary to Petitioner’s claim chart and citations to Smith in the Petition, Smith
`
`does not disclose this limitation. See Decision, IPR2014-00136, Paper 15 at 24
`
`(“... Smith does not describe that the proxy server to be added is allowed to join the
`
`proxy server array
`
`in accordance with our construction of ‘allow’ and
`
`‘allowing’...”). Thus, Petitioner’s allegation that claim 1 is obvious in view of
`
`Smith and Inohara hinges on whether Inohara discloses the step of “allowing a
`
`client to join the cache community.”
`
`Given Inohara’s stated goal of achieving a single hierarchical cache structure
`
`that is fully scalable without the size limitations as to the number of servers found
`
`in prior art caching systems, it is ironic that Inohara is being asserted as teaching
`
`that a cache server may not be permitted entrance to a cache community based on
`
`the size of such cache community. The entire purpose of Inohara is to establish a
`
`single, hierarchical cache that is scalable yet manageable because of the way the
`
`cache is organized. The assertion that Inohara teaches “allowing a client to join a
`
`cache community” is simply incorrect.
`
`a. Cache Community.
`
`In the Board’s Decision, the Board construed “community” as “similarity or
`
`identity” and “sharing, participation and fellowship.” See Decision, IPR2014-
`11
`
`59147898_3
`
`

`
`IPR2014-00950
`Patent No. 7,188,145
`00136, Paper 15 at 13. Assuming for purposes of this Petition that such
`
`construction is correct, a cache community is a common identity that shares,
`
`participates, and forms a fellowship to cache content.
`
`The Petitioner seeks to interpret Inohara as teaching that a server group is a
`
`cache community. Such an interpretation of Inohara is necessary for Petitioner’s
`
`argument that reorganizing server groups (as described above and in Figure 5 of
`
`Inohara) when servers are added to the hierarchy somehow teaches not permitting
`
`such servers to be added to a cache community. This interpretation, however, is
`
`incorrect, as Inohara actually teaches that servers are always added to the
`
`hierarchy. Similarly, Inohara does not teach that a single server group is a cache
`
`community. The cache sharing arrangement of Inohara is repeatedly referred to as
`
`a “hierarchy.” Indeed, Inohara introduces the concept of a cache community in
`
`referring to an article entitled “A Hierarchical Internet Object Cache.” See Ex.
`
`1007, 1:66-2:10. Further, the “brief summary” of Inohara identifies the disclosed
`
`invention as “[a] ‘server status propagation protocol’ for distributed management
`
`of server operation information (or a list of operating servers) [...]. Each server
`
`starts from the names of a small number of other servers given from an
`
`administrator to dynamically structure a multi-cast of server operation information
`
`by virtue of the mutual support of server groups. The multi-cast hierarchy includes
`
`groups of a tree structure formed by server groups. Each group is composed of
`
`59147898_3
`
`12
`
`

`
`IPR2014-00950
`Patent No. 7,188,145
`several to several-tens servers. As a part of servers are stopped or restarted, the
`
`dynamic reconstruction of the multi-cast hierarchy is made.” Id. at 3:65-4:9
`
`(emphasis added). The invention of Inohara also includes “a ‘wide-area
`
`cooperative cache management protocol’ [that] performs the propagation of a
`
`cache directory (a list of URL's and servers which hold the URL's in caches) using
`
`the multi-cast hierarchy formed by the above-mentioned server status propagation
`
`protocol...” Id. at 4:23-28. Inohara repeatedly and consistently describes the
`
`dynamic construction and reconstruction of a cache sharing system that Inohara
`
`references as a hierarchy and not as one of the individual server “groups” that are
`
`merely components of such hierarchy.
`
`Clearly, the structure within Inohara that shares, participates, and forms a
`
`fellowship in caching content is the overall hierarchy, not an individual group of
`
`server leafs forming one branch of such cache hierarchy. See Supra at 5, citing Ex.
`
`1007 at Figure 2; 7:58-64. Since each server or server group contemplated by
`
`Inohara is identified in the same, single multi-cast hierarchy, each such server
`
`group, as described above, stores only a portion of the content cached by the
`
`hierarchy. See Supra at pp. 5-6, citing Ex. 1007 at 6:48-53, 17:1-19, 17:46-48, and
`
`8:14-24. According to the teachings of Inohara, the server group could not be
`
`operated as a cache community by itself because it would not provide access to all
`
`requests for cached content without accessing the complete hierarchy. Id.
`
`59147898_3
`
`13
`
`

`
`IPR2014-00950
`Patent No. 7,188,145
`Interpreting Inohara as teaching that a single server group is a cache
`
`community would mean that the single server group does not share cache content
`
`with servers not found in the single server group, but this is not the case. On the
`
`contrary, Inohara teaches that such servers cache additional content and share such
`
`content with servers outside of their group (which servers may have been denied
`
`entry to their group), participate in a cache community with servers outside of their
`
`group, and form a fellowship with servers outside of their group in a single caching
`
`hierarchy. Id. In fact, as described above, the principal goals of Inohara are to
`
`achieve a cache community that encompasses more than just a single server group
`
`in a single scalable hierarchy that interacts to share cached content with one
`
`another, participate in a single cache hierarchy, and form a common fellowship.
`
`Id. at 3:65-4:6 (“In order to solve the first problem, a "server status propagation
`
`protocol" for distributed management of server operation information (or a list of
`
`operating servers) is provided. Each server starts from the names of a small
`
`number of other servers given from an administrator to dynamically structure a
`
`multi-cast hierarchy of server operation information by virtue of the mutual
`
`support of server groups. The multi-cast hierarchy includes groups of a tree
`
`structure formed by server groups.”). To hold that Inohara’s single server group is
`
`a cache community or community is therefore inconsistent with the Board’s
`
`construction of community, as Inohara’s central teaching is that a single cache
`
`59147898_3
`
`14
`
`

`
`IPR2014-00950
`Patent No. 7,188,145
`hierarchy of multiple server groups form a cooperative community. Id. at 4: 23-32
`
`(“In order to solve the second problem, a "wide-area cooperative cache
`
`management protocol" is provided. This protocol performs the propagation of a
`
`cache directory (a list of URL's and servers which hold the URL's in caches) using
`
`the multi-cast hierarchy formed by the above-mentioned server status propagation
`
`protocol and a cache control (which URL does which server hold in a cache, and
`
`when is which URL to be transferred from a certain server to another server)
`
`without needing a centrally managing server corresponding to the manager in
`
`Reference 4.”).
`
`Interestingly, no citation provided by Petitioners references the hierarchy of
`
`Inohara or even acknowledges the hierarchy’s role relative to the individual server
`
`groups. Yet, the entire process of forming the groups described in Inohara is
`
`executed for the purpose of building out the described hierarchy into a single cache
`
`community. See Id. at 11:38-42 (stating that the process of organizing servers into
`
`groups described in FIG. 5 and relied upon in the Petition “is the group
`
`participation request processing”, and that “[w]ith the foregoing operation, it
`
`becomes possible to make hierarchization corresponding to a dynamic increase in
`
`the number of servers while the maximum number of members in each group is
`
`kept equal to or smaller than MAX.”). Thus, an individual server group is merely
`
`59147898_3
`
`15
`
`

`
`IPR2014-00950
`Patent No. 7,188,145
`a building block of the hierarchical cache structure that forms the cache
`
`community of Inohara.
`
`b. Allowing a Client to Join a Cache Community.
`
`In the Board’s Decision, the Board construed “allowing” as “permit[ting] the
`
`presence of…” relative to Claims 1 and 15. See Decision, IPR2014-00136, Paper
`
`15 at 14. The Board noted that such construction is consistent with the
`
`Specification of the ‘145 Patent’s teaching of allowing “client 404 to join
`
`community 402 based on a suitable criterion and that client 404 may be denied
`
`entry.” Id.
`
`The Petitioner contends that Inohara teaches “allowing” a client to join a
`
`cache community in the portion of FIG. 5 recited above that discusses various
`
`methods of reorganizing server groups when additional servers are added to the
`
`caching hierarchy. See Petition at 15-16. As noted above, however, Inohara does
`
`not teach any permission process or scheme for adding such additional servers and
`
`at no time are such additional servers denied entrance to the caching hierarchy.
`
`The Petitioner contends that the reorganization process that is triggered if such
`
`additional servers would cause a server group to exceed a maximum size is such a
`
`denial. Id. at 16. However, even if the disclosure of Inohara with reference to
`
`FIG. 5 could be said to teach denying a server entry to a server group (as opposed
`
`59147898_3
`
`16
`
`

`
`IPR2014-00950
`Patent No. 7,188,145
`to merely reorganizing the placement of such server and such server group within a
`
`hierarchy), as noted above, a single server group of Inohara is not a cache
`
`community. The denial of entry of a server into an intended server group in
`
`Inohara would not mean the denial of entry into a cache community, because
`
`according to the express teachings of Inohara, the server would still be placed into
`
`the overall cache hierarchy and share cached content with, participate with, and be
`
`in fellowship with all other servers in the hierarchy, including the server group.
`
`Ex. 1007 at 11:18-42. The previous statement warrants repeating and emphasis.
`
`According to the express teachings of Inohara, an additional server that would
`
`cause a server group to exceed a maximum size is still added to the cache hierarchy
`
`and still shares cached content with, participates with, and is in fellowship with the
`
`same server group in a single caching architecture. A server that shares cached
`
`content with, participates with, and is in fellowship with a server group (despite not
`
`being placed directly within such server group) cannot be said to be denied entry
`
`into the cache community, particularly in view of the Board’s construction of
`
`“community”. See Supra at 11, 12.
`
`Even if an individual server group could be said to be a cache community by
`
`itself (contrary to the contentions above and the express teachings of Inohara), for
`
`Petitioner to succeed in Petitioner’s contention that Inohara teaches allowing a
`
`server to enter a cache community by denying entrance of a server into a server
`
`59147898_3
`
`17
`
`

`
`IPR2014-00950
`Patent No. 7,188,145
`group, Petitioner would have to demonstrate that such denied server does not
`
`participate in a caching architecture with any members of that server group. That
`
`is not the case, however, as Inohara teaches that such server is still placed in a
`
`caching architecture with the members of that server group in order to
`
`cooperatively cache content with such server group in a single hierarchy. See Id.
`
`at FIG. 5 generally.
`
`To hold that Inohara’s not placing an additional server within a particular
`
`server group is denying entrance into a cache community would therefore be
`
`counter to Inohara’s express teachings that such additional server does become part
`
`of the same cache community. Such a holding would also render Inohara
`
`inoperative for its central teaching of achieving a cache community that is scalable
`
`in size beyond the constraints of a single server group. Thus, an interpretation of
`
`Inohara as teaching allowing a client to join a cache community in a forced
`
`combination with Smith renders Inohara inoperative and therefore Inohara and
`
`Smith as non-combinable. See MPEP at § 2143(I)(A), Example 2, citing DePuy
`
`Spine, Inc. v. Medtronic Sofamor Danek, Inc., 567 F.3d 1314, 90 USPQ2d 1865
`
`(Fed. Cir. 2009) (noting that because the combination of two prior art elements
`
`would have rendered (the prior art) device inoperative for its intended purpose, the
`
`references could not be combined). If anything, Inohara teaches away from
`
`limiting membership in a cache community by disclosing a cache structure that is
`
`59147898_3
`
`18
`
`

`
`IPR2014-00950
`Patent No. 7,188,145
`scalable and therefore does not require limited membership. The entire goal of
`
`Inohara is to teach an administration scheme for a caching hierarchy that no longer
`
`requires limitations on the number of cache servers that can cooperate in a single
`
`structure. Ironically, as noted above, the teachings of Inohara cited by the
`
`Petitioners (reorganizing the hierarchy when a server group becomes too large) as
`
`limiting the membership of a cache community are the very teachings that enable
`
`the cache community of Inohara to be infinitely scalable through the disclosed
`
`administration scheme.
`
`It follows that, in accordance with the only permissible interpretation of
`
`Inohara, any server that is included elsewhere in the hierarchy outside of a
`
`particular server group (because it was purportedly “denied” entry to the server
`
`group) cannot be said to be “denied” entrance to the cache community (despite
`
`having been purportedly “denied” entry to the server group) because the server and
`
`the particular server group still work in concert to cache data as one hierarchical
`
`community (i.e., as a single sharing arrangement or fellowship of caching devices).
`
`For the Board to hold otherwise would violate both the Board’s proposed
`
`construction of community and the Board’s construction of allowing. Such a
`
`holding would also mean that a decision on the specific placement of a cache
`
`server in any organizational caching scheme of tiers, groups, levels, clusters, or
`
`branches would nonsensically mean that the cache server did not participate in a
`
`59147898_3
`
`19
`
`

`
`IPR2014-00950
`Patent No. 7,188,145
`cache community with other servers located in a different tier, group, level, cluster,
`
`or branch – even though such participation in a unified caching structure among
`
`such tiers, groups, levels, clusters, or branches is the entire purpose of distributed
`
`caching networks.
`
` Petitioner’s basis for alleging that Inohara discloses the aforem

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket