`
`
`
`
`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