`Entered: April 8, 2015
`
`Trials@uspto.gov
`572-272-7822
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`RELOADED GAMES, INC.,
`Petitioner,
`
`v.
`
`PARALLEL NETWORKS, LLC,
`Patent Owner.
`____________
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`____________
`
`Held: February 23, 2015
`____________
`
`
`
`Before: KRISTEN L. DROESCH, BRIAN MCNAMARA, and
`HYUN J. JUNG, Administrative Patent Judges.
`
`
`
`The above-entitled matter came on for hearing on Monday,
`February 23, 2015, commencing at 1:30 p.m., at the U.S. Patent and
`Trademark Office, 600 Dulany Street, Alexandria, Virginia.
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`
`APPEARANCES:
`
`
`
`ON BEHALF OF THE PETITIONER:
`
`
`
`
`
`
`
`ERIC A. BURESH, ESQ.
`MARK LANG, ESQ.
`Erise IP
`6201 College Boulevard, Suite 300
`Overland Park, Kansas 66211
`
`
`
`
`
`
`
`
`
`
`ON BEHALF OF THE PATENT OWNER
`
`
`
`
`
`
`
`
`DARREN COLLINS, ESQ.
`AARON J. PICKELL, ESQ.
`ROBERT C. HILTON, ESQ.
`McGuire Woods, LLP
`2000 McKinney Avenue, Suite 1400
`Dallas, Texas 75201
`
` 2
`
`
`
`
`
`
`
`
`
`
`
`
`
`1
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`
`
`
`
`
`
`
` P R O C E E D I N G S
`- - - - -
`
`1
`2
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`JUDGE MCNAMARA: Please be seated. Good afternoon,
`
`everyone. This is the oral hearing in IPR2014-00136, and we're
`
`consolidating that with the hearing in IPR2014-00139, both Reloaded
`
`Games versus Parallel Networks. Is that the case everyone's here for?
`
`ALL COUNSEL: Yes, Your Honor.
`
`JUDGE MCNAMARA: That's a good sign.
`
`10
`
`Okay, if I could please have the -- starting with the
`
`11
`
`Petitioner, counsel, could you introduce yourselves?
`
`12
`
`MR. BURESH: Yes, Your Honor, Eric Buresh and Mark
`
`13
`
`Lang on behalf of Petitioner.
`
`14
`
`MR. COLLINS: And it's Darren Collins, Aaron Pickell, and
`
`15
`
`Robert Hilton, on behalf of Parallel Networks, the Patent Owner.
`
`16
`
`JUDGE MCNAMARA: Okay. We have no motions or
`
`17
`
`other matters pending before us today, just the arguments on the case
`
`18
`
`in chief. So, the Petitioner will go first, present its case with regard to
`
`19
`
`the challenged claims on which we instituted trial, and then the Patent
`
`20
`
`Owner will argue its opposition to the Petitioner's case, and then the
`
`21
`
`Petitioner can use any time it reserved to rebut the Patent Owner's
`
`22
`
`opposition.
`
`Is everybody ready to begin?
`
`MR. BURESH: Yes, Your Honor.
`
`MR. COLLINS: Yes, Your Honor.
`
` 3
`
`
`
`
`
`23
`
`24
`
`25
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`THE COURT: All right. We will hear first from Petitioner.
`
`Is there some amount of time you would like me to --
`
`MR. BURESH: Let me ask logistically, should we --
`
`because there are two proceedings consolidated, should we argue one
`
`fully and then proceed to the next or would you like to --
`
`JUDGE MCNAMARA: I think we would prefer to have
`
`you just make the arguments on the two patents together instead of
`
`starting and stopping and starting and stopping. Is that all right?
`
`MR. BURESH: That is perfectly fine. So, I will reserve 20
`
`10
`
`minutes for rebuttal.
`
`11
`
`12
`
`13
`
`14
`
`JUDGE MCNAMARA: Okay.
`
`MR. BURESH: May I approach with demonstratives?
`
`JUDGE MCNAMARA: Sure, please.
`
`MR. BURESH: Your Honors, if it pleases the Board, I will
`
`15
`
`start out with proceeding 2014-139, which relates to the '262
`
`16
`
`challenged patent. And I believe as you go through the briefing in this
`
`17
`
`particular proceeding, you will see that there is primarily one term of
`
`18
`
`claim construction. So, I'm going to focus my time with respect to the
`
`19
`
`'262 patent on that claim construction issue, and it relates to the term
`
`20
`
`"master." It relates to the term "master," and I think this permeates
`
`21
`
`the -- both of the limitations that are being challenged with respect to
`
`22
`
`the '262 patent. So, I'm going to dive right in.
`
`23
`
`In the Institution Decision, the Board preliminarily found
`
`24
`
`that the term "master" should be construed as "a peer that provides
`
` 4
`
`
`
`
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`administrative support to other peers." That is at the Institution
`
`Decision at page 7.
`
`That definition was taken from the patent specification at
`
`column 18 in lines 38 through 41, and I believe that was an
`
`appropriate place to cite for purposes of that definition, and I want to
`
`note a point of -- having read the Patent Owner's response -- a patent
`
`of clarification that I would like to make.
`
`At page 15 of their response, their briefing goes through a
`
`series of responsibilities that a master could do, and in their briefing,
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`they say, "after listing several tasks attributable to the master...the
`
`11
`
`specification states that 'master is further responsible for providing
`
`12
`
`administrative support to the community ...'"
`
`13
`
`Now, that quote and the way the quote was structured in the
`
`14
`
`brief makes it appear that there are tasks attributable to the master and
`
`15
`
`then, in addition, there are administrative tasks or administrative
`
`16
`
`support that the master can provide. That is not an accurate reading of
`
`17
`
`what the specification actually states.
`
`18
`
`At Column 18, lines 38 through 41 of the '262 patent, we see
`
`19
`
`that the actual description is "In addition to the functionality provided
`
`20
`
`by members, master is further responsible for providing
`
`21
`
`administrative support to community." So, what we see out of the
`
`22
`
`specification is the concept that you can have a master that is also a
`
`23
`
`member of the community. It has the characteristics of a member, and
`
`24
`
`in addition to what it does as a member, it also serves the
`
`25
`
`administrative role to support the community.
`
` 5
`
`
`
`
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`That is why it is -- this portion of the specification is the
`
`distinguishing factor. It's what distinguishes a member from the
`
`master and is why, in the broadest reasonable interpretation, that this
`
`is a perfect way to describe the role of the master.
`
`Now, there are a number of different examples we see in the
`
`specification of the '262 patent that would fall within this penumbra of
`
`administrative support. We see the concept that Parallel wants to
`
`focus on or the Patent Owner wants to focus on, which is the idea of
`
`adding new members to a community. We also see processing related
`
`10
`
`to how to remove members from a community. We see processing
`
`11
`
`relating to how to reallocate content within a cache community. We
`
`12
`
`see examples of how to balance a cache community and deal with
`
`13
`
`unexpected departures from a cache community.
`
`14
`
`There are a whole plethora of activities that are described
`
`15
`
`with respect to the master, and I would submit to the Board that it is
`
`16
`
`inappropriate to select one of those roles and make that a requirement
`
`17
`
`on the claims, claims that do not otherwise require that specific
`
`18
`
`characteristic.
`
`19
`
`When we look at Patent Claim 1 of the '262 patent -- and I'll,
`
`20
`
`I believe, on the next slide look at a figure describing this -- but in this
`
`21
`
`claim we see that the master is called out, and it is called out as
`
`22
`
`receiving a location request and providing a response to the location
`
`23
`
`request. In other words, a peer may come to the master and say,
`
`24
`
`where is cached content? The master will respond with an
`
` 6
`
`
`
`
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`identification of where the peer can go to retrieve the cached content.
`
`That is the role of the master in this particular claim.
`
`We see in Figure 8 a description of that particular
`
`functionality of the master. At 410, we see the master. We see the
`
`master receiving the location request at 550. We see the master
`
`providing a location response in 554. This description in Figure 8 is
`
`consistent with the claimed embodiment in this particular patent.
`
`Again, there other functionalities of a master, but the question for
`
`present purposes, in addressing the challenged claims, is what is
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`required by those claims? What is required by the claims is described
`
`11
`
`in Figure 8.
`
`12
`
`Chase teaches that specifically. Chase includes a server,
`
`13
`
`that's called a directory server. The directory server is queried to
`
`14
`
`determine if it has the appropriate cached data. If it does, it provides
`
`15
`
`identification of where you can go to retrieve that cached data. That is
`
`16
`
`the description on which the Board instituted, and that is the
`
`17
`
`description of Chase that renders the challenged claims of the '262
`
`18
`
`patent invalid.
`
`19
`
`Now, what is the Patent Owner's argument? This is taken
`
`20
`
`from Patent Owner response at page 17 of their brief: "Since neither
`
`21
`
`the directory server nor any other device disclosed by Chase is 'a
`
`22
`
`device that determines whether to allow a client to join the cache
`
`23
`
`community,' Chase does not disclose a master as required by Claim
`
` 7
`
`24
`
`1..."
`
`
`
`
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`
`That, of course, presumes that a master as required by Claim
`
`1 must be a device that determines whether to allow a client to joint
`
`the cache community, and as I've noted, that particular requirement is
`
`but one example of what a master could do. There is absolutely no
`
`basis in the '262 patent to limit a master, by definition, to that
`
`functionality.
`
`Chase, in view of --
`
`JUDGE MCNAMARA: Counsel, just one quick item that
`
`will make it easier for us when we're looking through the transcript. If
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`you could identify, as you're discussing, what demonstrative you are
`
`11
`
`referring to. I think the last one was number 9.
`
`12
`
`13
`
`14
`
`15
`
`MR. BURESH: DX 9, yes, it was.
`
`JUDGE MCNAMARA: And this one is 10, right?
`
`MR. BURESH: Thank you, Your Honor.
`
`JUDGE MCNAMARA: We're talking about the
`
`16
`
`demonstratives in the 139 case, right? Okay.
`
`17
`
`MR. BURESH: DX 10 introduces the combination of Chase
`
`18
`
`and Scharber, and Chase and Scharber, the combination, was
`
`19
`
`introduced or proposed for purposes of, turning to DX 11, picking up
`
`20
`
`the concept from Claim 2 and other associated dependent claims, that
`
`21
`
`when content is unavailable at an identified peer, Claim 2 states that
`
`22
`
`that particular peer will then go and retrieve the content essentially for
`
`23
`
`the requesting peer. That is Claim 2 and the associated claims.
`
`24
`
`Patent Owner has contended that that combination is
`
`25
`
`improper because, according to Patent Owner, Chase has no need to
`
` 8
`
`
`
`
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`consult with a second peer device, because according to Patent
`
`Owner, Chase already knows beforehand that the second peer device
`
`does not have the requested content available. And I'm referring to
`
`DX 12. That generally is true in Chase.
`
`However, what we've cited in our petition and what the
`
`Board instituted with respect to was the disclosure of Chase cited on
`
`DX 13, Column 6, lines 21 through 31, where Chase describes a
`
`situation where if the requesting station is unable to retrieve the data
`
`from the other station, for example, because the other station is down
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`or because the data, for whatever reason, have been" -- I believe that's
`
`11
`
`a [sic] -- "have been deleted from the cache of the other station, it
`
`12
`
`informs the server, and then we add the teachings of Scharber, where
`
`13
`
`the second server will go to retrieve the content.
`
`14
`
`That was the proposed combination, and it works perfectly
`
`15
`
`when you understand the teachings of Chase actually permit and
`
`16
`
`describe a scenario where the data has been deleted, the selected
`
`17
`
`station is down, and you need to then figure out how to go and get the
`
`18
`
`cached data from another station. Scharber provides the solution for
`
`19
`
`that.
`
`20
`
`And that is the points I wanted to make in my introductory
`
`21
`
`comments with respect to the '262 patent. So, unless there are further
`
`22
`
`questions, I'll transition to the '145 patent, which is the 2014-136
`
`23
`
`proceeding.
`
`24
`
`JUDGE JUNG: Mr. Buresh, before you continue, I would
`
`25
`
`like to ask you some questions about the construction of "master."
`
` 9
`
`
`
`
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`Now, as you already noted, we picked out a certain part of the
`
`specification for our broadest reasonable interpretation of "master" in
`
`this decision to institute, but how would you respond to the Patent
`
`Owner's argument that that might not be the broadest reasonable
`
`interpretation in view of the specification?
`
`The Patent Owner cites various parts of the -- actually, the
`
`majority of the specification that talks about where the master decides
`
`which client should be allowed into the cache community and which
`
`client should not be allowed in the cache community.
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`MR. BURESH: I would respond, and I hope that I've
`
`11
`
`covered this slightly, but I will re-emphasize a couple of points.
`
`12
`
`Even when we look at the specification portions that the
`
`13
`
`Patent Owner will cite to, you're going to see, generally speaking, a
`
`14
`
`couple of different functionalities that the master can perform.
`
`15
`
`For instance, you will see that there is the description of
`
`16
`
`allowing or determining whether to allow a client to joint the
`
`17
`
`community. In the same sentences, you'll find removal of a client
`
`18
`
`from a cache community. Should we also build in the concept, into
`
`19
`
`the definition of "master," that a master must determine how to
`
`20
`
`remove a client from a cache community?
`
`21
`
`JUDGE JUNG: Let's say we just build in the -- what's
`
`22
`
`described in the specification, that there's a function that allows a
`
`23
`
`client to enter the cache community. There's also a -- I'm sorry, but
`
`24
`
`there are also other descriptions of what the master can do for the
`
` 10
`
`
`
`
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`cache community. So, why shouldn't we also include those other
`
`functions mentioned in the specification?
`
`MR. BURESH: Precisely because of claim construction
`
`standards. You're importing limitations from the specification into the
`
`claims that are not otherwise claimed. The concept of a master is a
`
`broad concept that does many things in the '262 patent. It has multiple
`
`functionalities. If you were to take each individual one of those and
`
`rewrite the claims to specify that the master must perform those full
`
`penumbra of functionalities, you would have rewritten the claims to
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`require limitations that simply are not there.
`
`11
`
`In the vast majority of patents, as you know, Your Honor,
`
`12
`
`there is a description of multiple functionalities for any given system.
`
`13
`
`It is the Patent Owner's choice to claim the functionalities that they
`
`14
`
`desire to claim for their invention. No single claim has to claim all
`
`15
`
`functionalities. In fact, as we see in this particular case, there are
`
`16
`
`often other patents that claim other functionalities.
`
`17
`
`We'll see here that we have a divisional patent that claims
`
`18
`
`allowing or determining whether to allow a client to join a
`
`19
`
`community. That limitation is not found in the '262 patent. That was
`
`20
`
`a decision by the Patent Owner not to claim that functionality, and it
`
`21
`
`would be wholly improper, under prevailing standards, to inject that
`
`22
`
`limitation into the claims.
`
`23
`
`24
`
`JUDGE JUNG: Thank you.
`
`One other thing. The specification also mentions that the
`
`25
`
`master carries on these other administrative tasks. So, why can't that
`
` 11
`
`
`
`
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`other administrative task include the allowing a client into a cache
`
`community?
`
`MR. BURESH: It would include that. It does not require
`
`that. In other words, there are -- there are --
`
`JUDGE JUNG: Just to clarify, you're saying the claims do
`
`not require that with respect to -- or the specification does not require
`
`that?
`
`MR. BURESH: Neither requires that. The specification
`
`doesn't state that a master is not a master if it doesn't allow a client --
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`make a determination of whether to allow a client could to join a
`
`11
`
`community. It doesn't say that in the negative. It says that a master
`
`12
`
`can do that. The claims certainly do not require that functionality.
`
`13
`
`JUDGE MCNAMARA: But that would -- that is a possible
`
`14
`
`functionality of the master, a possible administrative function that
`
`15
`
`would be performed by a master.
`
`16
`
`MR. BURESH: No dispute there at all. It is one among
`
`17
`
`many of the possible functionalities of a master. Allowing a client to
`
`18
`
`join a community, removing a client from a community, allocating
`
`19
`
`cached content within a community, those are all possibilities of what
`
`20
`
`a master can do, and at that point it is the Patent Owner's decision as
`
`21
`
`to which of those functionalities to specific claim.
`
`22
`
`Here we see that the claimed functionality, again, is a
`
`23
`
`decision of processing information requests and providing responses
`
`24
`
`to those information requests identifying where cached content may
`
` 12
`
`
`
`
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`be found. That is the claimed functionality of a master in this
`
`particular patent.
`
`Transitioning now to proceeding 2014-136, and here we're
`
`dealing with a combination of Smith and Inohara that is the
`
`combination applied to all of the claims on which this proceeding was
`
`instituted, and the specific disputed limitations I'm going to be talking
`
`about are allowing a client to join the cache community -- again, this
`
`is the '145 patent, not the '262 patent -- and selecting one of the
`
`communities to attempt to join, which we'll see in the later claims,
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`though I'll pick that up separately.
`
`11
`
`Here, looking first at Claim 1, I've highlighted the concepts
`
`12
`
`and where they're found in the claim. We see in Claim 1 "allowing a
`
`13
`
`client to join the cache community" is one of the steps of the method
`
`14
`
`claim, and then Claim 2 further specifies that there is a step of
`
`15
`
`"determining whether to allow the client to join the cache
`
`16
`
`community." I will treat these as one as we go through the
`
`17
`
`proceeding, because the issues are really -- really the same with
`
`18
`
`respect to both of those concepts.
`
`19
`
`I'm now on DX 5, for the record, and this slide --
`
`20
`
`demonstrative provides the two claim constructions that were offered
`
`21
`
`by the Board in its Institution Decision. First, with respect to the
`
`22
`
`concept of allow or allowing, the Board has preliminarily stated that
`
`23
`
`the proper BRI construction is to "permit the presence of." With
`
`24
`
`respect to the word "community" -- the term "community," excuse
`
` 13
`
`
`
`
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`me, we have a "similarity or identity" or "sharing, participation, and
`
`fellowship."
`
`I am going to speak first with respect to Inohara, and let me
`
`just back up a step and describe this combination. Smith has
`
`essentially the meat of these claim limitations with respect to what the
`
`cache system is doing. What it does not have, Smith is a single array
`
`of servers, and it does not describe how to -- how to add new servers
`
`to that array. They're just -- they just come into existence. It doesn't
`
`really describe that process.
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`So, what Inohara describes is a concept of how you would
`
`11
`
`restrict the size of the community so that there is a decision, an
`
`12
`
`explicit decision whether or not to allow a server to join the
`
`13
`
`community. We're taking that teaching from Inohara and combining
`
`14
`
`it with the -- essentially the infrastructure from Smith. With respect to
`
`15
`
`allowing, Inohara's disclosure is extremely similar to the disclosure of
`
`16
`
`the '145 patent.
`
`17
`
`At DX 6, on the left-hand side of the slide, we reference the
`
`18
`
`'145 patent at Column 20, at lines 51 through 55, where we see the
`
`19
`
`master making a decision about whether the addition of a client would
`
`20
`
`exceed the maximum numbers of members that may be in a
`
`21
`
`community. So, there's a desirable size cap described in the '145
`
`22
`
`patent.
`
`23
`
`That same desirable size cap is described in Inohara. This is
`
`24
`
`with respect to the concept of a server group. The judgment is made
`
`25
`
`in Inohara whether or not the sum of the number of old members and
`
` 14
`
`
`
`
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`the number of new members is smaller than the max mentioned
`
`earlier.
`
`Going to DX 7 and referring to the right-hand side to
`
`continue the thought from Inohara, the judgment is made of whether
`
`or not the addition of one to the number of old members is smaller
`
`than max. In other words, if we're going to add one new member and
`
`that will cause us to exceed the maximum allowable in a server group,
`
`what happens? If the judgment is no, a new group is formed. So, you
`
`cannot go into the existing group; you form a new group.
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`That's the same teaching or corresponding teaching with
`
`11
`
`respect to the '145 patent, where, at Column 13, lines 33 through 36, it
`
`12
`
`is described that in a circumstance where you cannot join a
`
`13
`
`community, the cache module may attempt to start its own cache
`
`14
`
`community. So, you start a new group.
`
`15
`
`Moving to slide DX 9, I'm going to go to what I think is the
`
`16
`
`core issue in this case, and this particular dispute is raised by the
`
`17
`
`Patent Owner, which is Inohara's community. We have contended in
`
`18
`
`our petition and the Board has found in the Institution Decision that
`
`19
`
`the server group of Inohara is a community, because the members of
`
`20
`
`each server group have similarity or identity with each other and they
`
`21
`
`cache content within -- essentially within the group.
`
`22
`
`Now, PO's response, the Patent Owner's response, as I
`
`23
`
`pulled from paper 23 at page 20, "A single server group [of Inohara]
`
`24
`
`is not a cache community," would be their contention, and I think that
`
`25
`
`is at the heart of the debate in this particular proceeding.
`
` 15
`
`
`
`
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`I want to cover the two concepts that were introduced by the
`
`Board in its construction of "community." First, the idea of similarity
`
`or identity. In Inohara, we have a group that is defined within a group
`
`table. You have a leader server ID and then the server IDs of the
`
`members of the group. Each member's group table has the exact same
`
`list of a leader server ID and the group member IDs. That is a
`
`similarity. You identify the group by whether you're in the particular
`
`group table listing. That gives you a definable characteristic that is
`
`similar and shared between all of the participants in the server group.
`
`10
`
`With respect to sharing participation and fellowship,
`
`11
`
`Inohara, at 15:19 through 21 -- and I'm on DX 11 now -- in order to
`
`12
`
`update the cache directory of the group, the server acquiring new
`
`13
`
`information transmits a host URL message to members of the group.
`
`14
`
`This is talking about -- and I would encourage the Board, if you're
`
`15
`
`interested, to read above and below this description in Inohara to
`
`16
`
`understand how the cache directories work within a server group in
`
`17
`
`Inohara, but this is kind of the conclusion.
`
`18
`
`And when new data is added, the cache directory of the
`
`19
`
`group is updated, and the new cache directory is circulated within the
`
`20
`
`group. That is sharing and participation and fellowship within the
`
`21
`
`context of caching.
`
`22
`
`So, I would contend and have contended in the petition, and
`
`23
`
`I believe as the Board has found in the Institution Decision, that
`
`24
`
`Inohara does teach the concept of allowing, it does teach the concept
`
`25
`
`of specifically allowing entry into a community in a caching context,
`
` 16
`
`
`
`
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`and, therefore, is combinable to satisfy that limitation in addition to
`
`the other teachings of Smith.
`
`Patent Owner then contends that essentially Inohara
`
`becomes inoperable if we put a cap on membership, because the
`
`overarching point, according to Patent Owner, of Inohara is one of
`
`inclusiveness. In other words, Inohara describes a hierarchical
`
`architecture where you will have groups, server groups, but those
`
`server groups fit within a broader structure so that, at the end of the
`
`day, nobody is denied entry into the overall hierarchical structure.
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`They may be denied entry into a server group, but they are still going
`
`11
`
`to fit in somewhere, into the hierarchical structure.
`
`12
`
`And that may be a rough paraphrase. We will certainly hear
`
`13
`
`more from Patent Owner on how they would describe that, but that's
`
`14
`
`my take on it.
`
`15
`
`And their point would be, with respect to Inohara, if we look
`
`16
`
`at the server groups and cap the size of those, it cuts against that
`
`17
`
`teaching of Inohara and, therefore, renders it inoperable. I believe
`
`18
`
`that's a complete red herring argument, because -- two main reasons:
`
`19
`
`We're not modifying the community in Inohara. That's not
`
`20
`
`the proposed combination. The proposed combination we're looking
`
`21
`
`at is Smith, which has an array of servers that can be added to, and it
`
`22
`
`doesn't describe when to stop it. We apply the teaching from Inohara
`
`23
`
`to Smith to provide a cap on the size of the server array in Smith.
`
`24
`
`There's nothing inoperable about Inohara. We're taking the teachings
`
`25
`
`from that and applying them to a community that's described in Smith.
`
` 17
`
`
`
`
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`And secondarily, Inohara itself expressly teaches restricting
`
`the admission to a server group based on a max size. That is an
`
`express, undisputable teaching from Inohara, and I simply do not
`
`understand how an express teaching from Inohara can itself render
`
`Inohara inoperable. That doesn't make sense to me.
`
`And, again, I would reserve additional time to rebut
`
`whatever I hear from the Patent Owner with respect to that point.
`
`The additional claim limitation I talked about at the
`
`beginning is the idea of selecting one of the communities to attempt to
`
`10
`
`join and generating a join request for that community, which is first
`
`11
`
`found in Claim 29, but it is in several other claims as well, as I've
`
`12
`
`shown on DX 14.
`
`13
`
`I'm not going to belabor this point significantly, because the
`
`14
`
`argument essentially is the exact same argument. Patent Owner states
`
`15
`
`that you cannot select from multiple communities because Inohara
`
`16
`
`teaches only one community, the hierarchical, broadest possible
`
`17
`
`community. And, again, the teachings here line up very, very well.
`
`18
`
`The idea of selecting from Inohara is done exactly on the same basis
`
`19
`
`as what's described in the '145 patent.
`
`20
`
`In the '145 patent, we see latency being the main test to
`
`21
`
`determine which community you want to join. In Inohara, we see
`
`22
`
`latency being the primary test to determine which server group you
`
`23
`
`want to attempt to join. So, the teachings -- the overlapping between
`
`24
`
`those teachings is phenomenal, it lines up very closely, and I see no
`
`25
`
`basis for Patent Owner's argument in this respect.
`
` 18
`
`
`
`
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`Again, that was my -- the comments I wanted to introduce.
`
`I'll reserve the rest of my time for rebuttal, but first, I'm happy to
`
`answer any questions the Board may have.
`
`JUDGE JUNG: Mr. Buresh, in your reply, it didn't seem
`
`like you directly addressed why the hierarchy can't be a cache
`
`community, but can you address that now? Why can't the hierarchy in
`
`Inohara be the recited cache community of the claims?
`
`MR. BURESH: Why can't the -- I'm sorry.
`
`JUDGE JUNG: The hierarchy in Inohara be the cache
`
`10
`
`community, because they bring up some good points, you know, a
`
`11
`
`group -- or, I'm sorry, a group of Inohara is just a subset of that
`
`12
`
`hierarchy, it only stores a portion of the cache, and if you send in a
`
`13
`
`request for cache community, you might not get it from that particular
`
`14
`
`group. You would have to go back to the hierarchy to find it.
`
`15
`
`MR. BURESH: Well, if we look at the teachings of Inohara,
`
`16
`
`I'm going to first answer your question, and then I will follow up by
`
`17
`
`making sure that we're asking the right questions, if that's okay.
`
`18
`
`So, with respect to -- with respect to Inohara -- thank you.
`
`19
`
`Within the context of caching data and retrieving the cached data,
`
`20
`
`we're really -- the description of that is at Column 14 of Inohara, and
`
`21
`
`it begins at about line 53. The heading there is "Search for Cache --
`
`22
`
`Search of Cache and Propagation of Cache Directory."
`
`23
`
`And what you are going to see in that description is that you
`
`24
`
`search for cached content within your group, within the cache
`
`25
`
`directory of your group, if your group does not have the requested
`
` 19
`
`
`
`
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`content in the cache directory, you proceed to external servers, which
`
`are described as, I believe, 13 in Inohara.
`
`So, you're literally looking within your group for cached
`
`content, and then, just like the '145 patent, if it's not in your group,
`
`you go to external servers to retrieve it, and then you subsequently
`
`update your cache to identify that new cached material. That is just
`
`like the asserted patent here or the contested patent, where you have a
`
`community, and if you search within your community and you do not
`
`find the content, you go to an origin server and obtain the content.
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`The teachings are very, very similar.
`
`11
`
`The real and I would say only distinction between the patent
`
`12
`
`in this case and Inohara is that in Inohara a member of one group may
`
`13
`
`also be the member of another group, and that's how your hierarchy
`
`14
`
`essentially forms when you describe the hierarchy. But there's an
`
`15
`
`interesting passage in Inohara. It's, again, at Column 14, but this time
`
`16
`
`I'm backing up to 24.
`
`17
`
`It says: "By structuring a multicast hierarchy dynamically
`
`18
`
`by virtue of mutual support, a change in the operating conditions of
`
`19
`
`other servers and the change in communications feed are grasped
`
`20
`
`without needing a central server. By limiting server information to be
`
`21
`
`propagated to information of proximate servers and remote servers not
`
`22
`
`larger in number than a fixed number and making the number of
`
`23
`
`destinations of propagation not larger than a fixed number in
`
`24
`
`accordance with the structure of a multicast hierarchy, communication
`
` 20
`
`
`
`
`
`
`
`Cases IPR2014-00136 and -00139
`Patents 7,188,145 and 7,730,262
`
`for management does not explode even if the number of servers
`
`become large."
`
`Okay. Now, I will leave you to reread that on your own, but
`
`the point of that passage is simply sa