throbber
Paper No. 32
`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

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