trials@uspto.gov
`571-272-7822
`
`
`
`
`
`IPR2015-01872, Paper No. 28
`January 12, 2017
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`ERICSSON INC. And TELEFONAKTIEBOLAGET LM
`ERICSSON,
`Petitioner,
`
`v.
`
`INTELLECTUAL VENTURES II LLC,
`Patent Owner.
`____________
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`____________
`
`Held: December 8, 2016
`____________
`
`
`
`
`
`BEFORE: BRYAN F. MOORE, BRIAN J. McNAMARA, and
`DAVID C. McKONE, Administrative Patent Judges.
`
`The above-entitled matter came on for hearing on Thursday,
`December 8, 2016, commencing at 1:01 p.m., at the U.S. Patent
`and Trademark Office, 600 Dulany Street, Alexandria, Virginia.
`
`
`
`
`571-272-7822
`
`
`
`
`
`IPR2015-01872, Paper No. 28
`January 12, 2017
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`ERICSSON INC. And TELEFONAKTIEBOLAGET LM
`ERICSSON,
`Petitioner,
`
`v.
`
`INTELLECTUAL VENTURES II LLC,
`Patent Owner.
`____________
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`____________
`
`Held: December 8, 2016
`____________
`
`
`
`
`
`BEFORE: BRYAN F. MOORE, BRIAN J. McNAMARA, and
`DAVID C. McKONE, Administrative Patent Judges.
`
`The above-entitled matter came on for hearing on Thursday,
`December 8, 2016, commencing at 1:01 p.m., at the U.S. Patent
`and Trademark Office, 600 Dulany Street, Alexandria, Virginia.
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`
`
`
`
`
`
`
`
`
`ON BEHALF OF PATENT OWNER:
`
`J. ROBERT BROWN, Jr., ESQUIRE
`CHARLES J. ROGERS, ESQUIRE
`Conley Rose, P.C.
`5601 Granite Parkway
`Suite 500
`Plano, Texas 75024-6608
`
`BYRON L. PICKARD, ESQUIRE
`LORI A. GORDON, ESQUIRE
`Sterne, Kessler, Goldstein Fox
`1100 New York Avenue, N.W.
`Washington, D.C. 20005
`
`
`
`
`
` 2
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`
`
`
`P R O C E E D I N G S
`- - - - -
`JUDGE McNAMARA: Good afternoon, everyone.
`This is the oral hearing in case IPR2015-01872, Ericsson and
`another Ericsson entity which I won't even try and pronounce
`versus Intellectual Ventures. Beginning with the petitioner,
`would the parties please introduce themselves.
`MR. ROGERS: Charles Rogers, backup counsel. I
`have with me here my colleague, Robert Brown, lead counsel,
`and in-house counsel, Brian Kearns.
`MR. PICKARD: Good afternoon. Byron Pickard on
`behalf of the patent owner, and I'm joined today by my partner,
`Lori Gordon.
`JUDGE McNAMARA: As you can see, Judge McKone
`is participating remotely. So I would ask everyone to please
`speak from the microphones, and in reference to any
`demonstrative or paper that you are displaying here, please refer
`to it so that -- where it is in the record so that Judge McKone can
`access it as well.
`Today the petitioner will open the hearing, present its
`arguments with respect to the challenged claims that we've
`instituted on. Patent owner will then respond and the petitioner
`can then exercise its right to rebuttal. Is there any amount of time
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
` 3
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`that the petitioner would like to reserve for rebuttal? There are
`45 minutes argument for both sides.
`MR. ROGERS: Petitioners would like to reserve ten
`minutes.
`JUDGE McNAMARA: Okay. If everybody is
`prepared, we can begin.
`MR. ROGERS: Good afternoon. May it please the
`Board, we are going to start out with slide 2. And side 2 lists the
`instituted claims, the majority of which are based upon a 103
`single-reference obviousness assertion, the single reference being
`the prior art Lu patent. And that is the majority of the claims.
`Then with the exception of claims 22 and 25, which bring in
`Pankaj as a combination of Lu and Pankaj as a 103 obviousness
`assertion.
`Moving to slide 3, slide 3 is the overview of the '994
`patent. The '994 patent generally relates to methods of processing
`queued packet datas that are described as a combination of
`hierarchical, which is tier-based, and weighted fair queueing.
`And the specification in the '994 patent refers to this combination
`as tier-based weighted fair queueing. And the spec of the '994
`patent says that this approach of combining these two prior art
`queueing schemes has not been considered in the past, but as
`we'll see going forward here, this combination is precisely what
`the Lu prior art reference discloses.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
` 4
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`
`Moving on to slide 4, there were no claim construction
`issues in the institution decision. There were no disputed claim
`construction issues. The only claim construction that was done in
`the institution decision was the Board properly construing claims
`11 through 19 and 24 as reciting means-plus-function terms. And
`the patent owner has not disputed the construction for these
`means-plus-function terms. There is one claim construction issue
`that's come about after the institution decision that arises from the
`patent owner's response regarding the term in claim 1 "queued
`packet data users." And we'll see that as we go forward here.
`Next slide, 5, the goal as stated in the specification for
`the '994 patent is to provide a fair and optimal allocation of
`limited communication resources to data packet users having
`different requirements or throughputs. And this is specifically
`described in column 2 as quoted here on slide 5 where the spec
`for the '994 patent says it is important to optimize use of the
`limited communication resource which becomes even more
`important when individual data packets have different
`requirements with respect to delay, bit error rate, et cetera, such
`as quality of service requirements.
`And slide 6, this is a reference to the background
`section of the '994 patent which begins with the description of the
`two prior art queueing schemes that it describes, first weighted
`fair queueing and then hierarchical queueing. And moving to
`slide 7, after the initial description of these two prior art queueing
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
` 5
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`schemes, the '994 spec describes the pros and the cons of each of
`these two prior art queueing schemes.
`JUDGE McNAMARA: Could you take just a minute
`and summarize for me the difference between weighted fair
`queueing and hierarchical round-robin.
`MR. ROGERS: So weighted fair queueing, that prior
`art scheme uses weights, and it's to provide proportions of the
`communication resource. So if you go through the prior art,
`beginning with first-in/first-out as queueing and then there's
`priority queueing, which will queue to one input over the other
`and won't even get to the other lower priority input to service that
`queue until the higher priority queue is idle or empty.
`Then there's fair queueing which will give an equal
`amount to each -- this is an example which is two inputs. It gives
`equal amounts to two different inputs. And then weighted fair
`queueing, actually instead of giving equal amounts to the
`example of two inputs will provide a percentage of the two.
`So that then is a great segue into hierarchical queueing
`and hierarchical weighted queueing. Hierarchical has -- you'll
`have two different levels. So you may provide one queueing
`scheme, whether it's 5-0, fair queueing, weighted fair queueing or
`priority queueing, you provide that at one level and then you have
`a hierarchy that you move down to the next level and you provide
`another queueing scheme.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
` 6
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`
`So the best example of the hierarchical weighted fair
`queueing would be where you have -- first you apply, let's say,
`75 percent and 25 percent at one level and then you work your
`way down a tree down to the next level. If you apply 75 percent,
`25 percent again, that far left-hand side root down to the leaf is
`the amount of the resource that's provided would be a product of
`the two. And that is specifically described in the Lu disclosure,
`that particular example.
`So moving forward, slide 7, pros and cons of each. And
`then moving to slide 8, you have the proposed solution in the '994
`specification to the cons, to the disadvantages of the prior art
`queueing schemes is described. The proposed solution is
`described as a packet data queueing algorithm based around a
`concept of employing different tiers of service to provide users
`with a commitment that a portion of the entire system bandwidth
`will be allocated to users operating on that particular tier. And
`the abstract of the '994 spec describes this method as including
`allocating a tier service for substantially each of a plurality of
`individual packet data queues in which a proportion of a total
`number of data packets is allocated to a number of the tiers of
`service.
`
`And if you go moving to slide 9, what slide 9 shows
`you is we'll get to the claims, the specific claims and how Lu
`discloses or renders obvious the claims of the '994 patent. But
`first I want to compare the description in Lu to the description of
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
` 7
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`what the '994 patent describes as its invention. The '994 patent at
`column 4 describes its approach of combining hierarchical and
`weighted fair queueing saying that it's never been considered in
`the past. Well, we know from the Lu disclosure that it has been
`considered. So precisely what the '994 patent claims describe, it's
`an invention to be specifically disclosed in the prior art of Lu. Lu
`at column 2 describes its invention as the class queueing system
`that uses a weighted-based scheduling scheme.
`And if you go to slide 10, further similarities between
`the Lu disclosure and the '994 spec. The '994 spec describing its
`data queueing algorithm as based around the concept of
`employing different tiers of service. The apparatus and method is
`summarized and described to provide a tier-based weighted fair
`queueing scheme in which packets are allocated in a round-robin
`fashion.
`Similarly in Lu --
`JUDGE McKONE: Mr. Rogers, you are welcome to
`proceed however you would like here, but given the limited
`amount of time, it may be more beneficial to concentrate on the
`specific elements of the claims that are really in dispute at this
`time.
`
`MR. ROGERS: Understood. So let's move forward in
`the slides to slide 12 where I'll give a summary of how we are
`going to go through these claims. We are going to first deal with
`claim 1 and then the corresponding claims 11 and 24. So 1 is a
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
` 8
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`method claim, 11 being corresponding apparatus and system
`claims. Then the next group of claims is 7 and 17, which we'll
`deal with together. And then 21, 22, and 25 is where we bring in
`Pankaj as a combination for the 103 obviousness.
`We do have slides on the Section 315(a) and (b)
`arguments but I'm reserving those as necessary for rebuttal
`because when we saw the patent owner's request for oral
`argument and the statutory requirement for listing issues that are
`to be argued, they are not listed. Nor do we see any 315(a) or (b)
`arguments in their slides. I understand that still is our burden of
`proof, but I did not plan on reserving time for making those
`arguments unless the Board has questions or allows the patent
`owner to make those type of arguments. So like I said, we do
`have slides on that, but we may not get to them.
`So moving, as suggested, to slide 13, claim 1, claim 1
`has a method claim that has five steps. We've got allocating a tier
`of service, determining a total number of data packets that can
`use in available communication resource, you've got two more
`allocating steps allocating different weights and then allocating a
`proportion of the data packets to the tiers, and then finally
`providing the communication resource to users of queued packet
`data users on a tier-by-tier basis. Those are the five method steps.
`There's only two in dispute at this point. So I want to limit the
`discussion to elements identified as B and E.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
` 9
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`
`So moving to slide 14, element B, this can be broken
`down into two different disputed areas. It's determining a total
`number of data packets that can use an available communication
`resource. The first aspect of this element B is determining the
`total number of data packets. So I'll handle that first.
`This determining a total number of data packets is
`disclosed in Lu as a weight-based scheduling scheme that may
`operate in cycles where you have for each cycle a number of data
`packets is selected for transfer. That's done based on weights.
`And the data packet volume for any period of time for each class
`may be determined.
`We go to slide 15, this is where we see --
`JUDGE McKONE: Before you move much further,
`just so I have the right context, what is it that you contend is the
`communication resource, the available communication resource?
`MR. ROGERS: Well, the communication resource, it's
`shown it can be a connection on a network, the bandwidth for
`transmitting data or it can be storing data. But in this case, the
`most prevalent example is communicating data and the
`communication resources defined as the bandwidth, the available
`bandwidth for the communication.
`JUDGE McKONE: So it would be the bandwidth, if we
`look at, you know, any of the figures, like Figures 4 or 5, that
`bandwidth of the line out, say, 209?
`MR. ROGERS: Yes, link 209.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
` 10
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`
`JUDGE McNAMARA: So it's the bandwidth of the
`length then after all of this processing has been done to figure out
`what should be transmitted?
`MR. ROGERS: Yes. I mean, in Lu you could also
`consider the final point where the data is queued also as a
`communication resource, but it's easier to think of it as the link
`209.
`
`JUDGE McNAMARA: Okay.
`MR. ROGERS: So it's the bandwidth of the link. So
`we'll see on slide 15 you have the '994 patent describing this
`determining of a total number of data packets with reference to a
`preferred embodiment where it assumes that allocation of
`resources can only be made at certain time intervals or rounds. In
`this particular example at column 7 it has each round 100 packets
`are allocated. Lu discloses the determining of the number of data
`packets in similar terms per round. It refers to cycles. And it
`uses a weight-based scheduling scheme that can operate in cycles
`where for each cycle a number of data packets is selected for
`transfer. So you are seeing precisely what the '994 patent
`describes is its determining step as disclosed in Lu.
`JUDGE McNAMARA: As I understand, though, the
`patent owner's position is that this weighting that goes on in Lu is
`not the same as finding the total number of packets. And you
`disagree with that; is that right?
`MR. ROGERS: Absolutely. In Lu --
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
` 11
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`
`JUDGE McNAMARA: That's probably a good issue to
`try to make really clear why you disagree with that.
`MR. ROGERS: Lu is done in two steps where you first
`determine the weights and then the weights determine the number
`of packets. That's what weighted fair queueing is. You apply
`weights so that you can proportion the bandwidth that's going to
`be provided to the various inputs, the various users. And so that's
`pretty straightforward that you apply weights and it's a portion of
`the bandwidth. You multiply and the product of that determines
`then the number of packets.
`JUDGE MOORE: When you say a portion of the
`bandwidth, are you saying that the number of packets, let's say
`the weights are 25 and 75, are the number of packets that's in that
`25 basket and the number of packets that are in that 75 basket
`determined by the total bandwidth available at the link or by the
`number of packets moving towards that link, if I'm saying that
`correctly? In other words, is the bandwidth the determiner of the
`exact number of packets in each bucket?
`MR. ROGERS: It is, because for weighted fair
`queueing you are giving a weight and multiplying that weight as a
`proportion of the available bandwidth, the bandwidth that has
`been selected. So if you look at Lu in column 4 that goes through
`column 5 -- this particular example we are getting to is in column
`6. You have a one-to-one correspondence between the weights
`and the number of packets. But that's really just a simplified
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
` 12
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`explanation of the way the selection of the packets is done. If
`you look at column 4 and column 5 in the Lu patent, it describes
`the minimum amounts assigned to the weight classes and
`applies -- you look at the minimum amounts that can be
`guaranteed and calculate your weights based upon the minimum
`balance and it becomes a proportion.
`And then as Lu describes, you have two different stages
`when you are selecting data. You have got a predetermined
`selection of data and then at the outset, before the process begins
`and then throughout the process as Lu describes, it's keeping track
`through soft and hard buffer thresholds. It's keeping track of the
`amount of data that is actually used and all the way to the point of
`knowing what the available bandwidth is because it keeps track
`and uses these thresholds to determine when you have an
`overcapacity. Lu describes that you use these soft and hard
`buffer thresholds to determine situations of overcapacity and to,
`along the way, adjust the weights and the capacity.
`So the system knows in Lu, it knows what the
`bandwidth is, it knows what the capacity is, and it provides a
`proportion of that through its weighting system so that the
`available resource is -- and use of the available resource is
`optimized.
`This example in 17 is really just a simplified example
`where your weights in determining the number of packets, there's
`a one-to-one correspondence. So in this example shown at slide
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
` 13
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`17, you have weights for classes, high, medium and low, that are
`assigned weights of 5, 2 and 1. And in this particular simplified
`example, when you have one-to-one correspondence, that
`determines that you have got five data packets selected for the
`high class, two for the medium and one for the low.
`Then you go -- so that's being transferred on that first
`
`cycle.
`
`JUDGE McKONE: But that's being transferred within
`the various buffers. Not transferred out to link 209, for example,
`correct?
`MR. ROGERS: Well, when it's weighted fair queueing,
`you work your way through the system. So you work your way
`through levels, and then transferred out is the final level. The
`answer to your question is yes and no because when you are
`talking about the lower levels, that's just the precursor to when
`you get to the ultimate higher level that is then transmitted out.
`So these are data packets selected along the way for each level.
`And as is done in hierarchical queueing, when you get to the top
`of the hierarchy, then it's output and queued to the
`communication resource.
`JUDGE McNAMARA: The question I have is that the
`claim element 1B says determining a total number of packets that
`can use an available communication resource. So as I understand
`this weighting that's going on in Lu, it's saying, well, I'm going to
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
` 14
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`assign five high, two medium, one low. How is it determined that
`it's eight that can use that resource?
`MR. ROGERS: With its buffer thresholds. This is the
`predetermined amount. With the soft and hard buffer thresholds
`it's monitoring the amount of data that's actually being used
`throughout the system. And it monitors the system and adjusts.
`As it says in Lu, it adjusts the weights and capacity accordingly.
`So it's monitoring the system. It's keeping track of overcapacity
`situations through its thresholds. And in some instances it talks
`about dropping data, but that's the hard threshold.
`In particular with respect to the soft ones, it's using
`those to make sure there's not data drop and it keeps track of what
`the capacity is. It can adjust the capacity as well. So it knows
`what the bandwidth is and the available communication resource,
`and it uses these weighting schemes and adjusts the weights so
`that it is determining the amount that can be used.
`JUDGE McKONE: Now, why do you conclude that Lu
`is determining a number of packets that can use the resource
`rather than other potential indirect measurements of bandwidth
`such as we are dropping packets, we probably have to decrease
`the input or it seems like there's a lot of extra space, maybe we
`increase the input. Why is it necessarily determining a number of
`packets that can use an output resource?
`MR. ROGERS: Because it's selecting the packets to be
`used and then it modifies and selects packets along the way. So
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
` 15
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`even if the predetermined selection of packets is interpreted to not
`fall within this determining step, it certainly is along the way in
`the process how Lu describes the actual number of packets being
`used and adjusting the weights so that it makes that selection of
`what is actually being used all the way to the point of fully taking
`advantage of the capacity of the communication resource.
`JUDGE McNAMARA: Again, it's determining the
`number of packets that can use a communication resource. So if
`the communication resource is a fiber optic cable versus another
`communication resource that is something of much lower
`bandwidth, can you point to something in Lu by column, line,
`whatever, that describes that Lu figures out how many packets
`that particular communication resource can use?
`MR. ROGERS: If you look at column 2, lines 46
`through 49, Lu discloses that based on a specific selection of
`class specification parameters, the resulting bandwidth/line,
`quality/error rate, et cetera, may be determined and applied as
`appropriate. And that application is the selection of the data
`packets that can use the available resource.
`JUDGE McNAMARA: And then is there some
`disclosure of changing that then to -- with that information,
`figuring out the number of packets that can be used?
`MR. ROGERS: Yes, because the weights determine the
`number of packets. So moving on to slide 18, I think we've
`covered all this, so I'm going to go to element E, slide 20.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
` 16
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`Element E at slide 20 is the final step of claim 1, providing said
`communication resource to queue packet data users on a
`tier-by-tier basis such that said communication resource is made
`available to a number of tiers. So I read that explicitly the way
`it's phrased, but this is where we have a claim construction
`dispute. The way the Board should read this, if you go back to
`slide 19 -- slide 20, if you look at slide 20, the reference to
`queued packet data users should be read as users of queued
`packet data. The patent owner wants this to be instead interpreted
`as users of packet data that are queued. They want you to
`narrowly read this claim to require queueing of users as opposed
`to the way this should be read.
`What this limitation is talking about is providing the
`communication resource to the users. There's no requirement in
`this limitation that says that the users are required to be queued.
`And so let's move on to slide 21, and you'll see the
`patent owner's argument. They say that queued packet data users
`mean users themselves are queued. Well, setting aside the
`physical impossibility of queueing users we know from the patent
`owner's expert that that's really not what they are arguing.
`JUDGE McKONE: But of course it's not what they are
`arguing. I don't think anybody is arguing that users are in a bread
`line or something or in a line at Disney World waiting for a ride.
`I think everybody is well aware that the argument is that an
`indication of some sort of the user is being queued. It seems like
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
` 17
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`the difference between your construction and theirs is that you are
`arguing that packets are queued. Whereas, patent owner has
`argued that an indication of the users are queued which is then
`correlated later to packets that are set. What support do you have
`that your construction is correct?
`MR. ROGERS: Because if you look at the claim, they
`are trying to read into this claim this requirement that users are
`queued. There's nothing in the claim that requires that users be
`queued or indication that users be queued. That's in claims that
`are not instituted. That's in claim 5. So if you are going to use
`claim differentiation as it should for interpreting these claims,
`you don't read requirements from a non-instituted claim into the
`independent claim.
`Claim 5 requires that there be an identification code that
`is queued. That's not in claim 1. Claim 1 is broader. And
`claim 1 should be read as what was understood at the time of the
`invention and even now that you are queueing data packets. And
`even if you read into a requirement that not only the data packets
`are queued, but some kind of identification is required, that's
`disclosed in Lu as well. If you look at slide --
`JUDGE McKONE: Before dealing with the claim
`construction argument, could you show me what your support is
`in the '994 patent for your construction of claim 1 that packets
`rather than indications of users are queued.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
` 18
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`
`And maybe I could be more focused on that. I
`understand patent owner's argument to be that Figure 3, for
`example, of the '994 patent shows queueing of user identifications
`which are later correlated to packets when a particular user
`identification is found in a queue. Is that incorrect, an incorrect
`characterization of Figure 3?
`MR. ROGERS: I think in that particular example in
`Figure 3 they are queueing -- you are correct, they are queueing
`the user identification, and the data itself is referenced and stored
`separate in memory in that particular example.
`JUDGE McKONE: Is there another example that you
`would like to point us to where the '994 patent describes queueing
`of packets as you would read claim 1?
`MR. ROGERS: Well, at column 7, lines 45 through 49
`it discusses allocation of data packets and it talks about tiers and
`these data packets are allocated to each tier. And under queueing
`schemes when you are talking about allocating a data packet to a
`tier or a queue, you are queueing the packet data. And --
`JUDGE McKONE: Isn't this in the context of a
`description of Figure 3 which you just agreed was queueing user
`IDs rather than packets themselves?
`MR. ROGERS: It's in the same area where they are
`discussing Figure 3, yes, but I don't read it as that limited. Under
`the broadest reasonable interpretation standard, I wouldn't think
`it's appropriate to limit these claims in that fashion. It may be
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
` 19
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`reading into the claim an embodiment. And then under claim
`differentiation, you look in that description of having a customer
`identification is limited to this dependent claim 5. So traditional
`claim construction constructs would have you not read that claim
`5 into claim 1. It would be redundant to require -- to read claim 1
`to be so narrow that it requires queueing of a user reference, user
`identification as opposed to queueing the data packets
`themselves.
`If you are intent on limiting the construction of even
`claim 1, then --
`JUDGE McKONE: I don't see this as an issue of
`limiting the construction. It seems like there's an either/or that we
`are presented with here. Either we are construing the claim to
`require queueing of packets or we are construing the claim to
`require queueing of user identifications.
`MR. ROGERS: Well, I view it as either/or is a way to
`characterize it. The other is and/or. The claim should be broad
`enough under the broadest reasonable interpretation to cover
`both. And if you are not going to have the claim interpreted, if
`you are going to have the claim interpreted to require queueing of
`not only the data packet, but of the user identification, you can
`find that disclosure in Lu as well. You'll see that Lu talks about
`queueing a data packet that has user identification in the header.
`And so even Lu itself you wouldn't interpret -- if you are going to
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
` 20
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`interpret the claim, claim 1 of the '994 to require queueing of user
`information --
`JUDGE McKONE: I assume you are talking about, for
`example, if we look at Figure 7 of Lu there is an identification
`field. That's what you are claiming is a user identification?
`MR. ROGERS: Yes. And that's one aspect.
`JUDGE McKONE: Do you have any evidence that
`that's a user identification?
`MR. ROGERS: Well, that's what our expert testified as
`to what one of ordinary skill in the art would understand. And I
`see it as well. When you have a data packet with the header and
`it has information, identification information, that's identifying
`who the user is. You are not going to send a data packet through
`a communication system willy-nilly just to go off into space.
`You’ve got to keep track of who the user is, and you do that
`through the header information.
`If you look in Lu --
`JUDGE McKONE: In the petition with regard to
`claim 5, it's my recollection that you argued that this
`identification field, it would have been obvious to make this
`identification field a user identification rather than the
`identification field actually disclosing a user identification field.
`Am I incorrect about your earlier arguments as to claim 5?
`MR. ROGERS: I think that's one way to look at it. But
`the other way is really --
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
` 21
`
`
`
`
`
`
`
`Case IPR2015-01872
`Patent 7,385,994 B2
`
`
`JUDGE McKONE: I'm asking about the way you
`looked at it in the petition.
`MR. ROGERS: I didn't see it as that narrow. If you
`look at the way obviousness arguments are handled is, yes, we'd
`like to see Lu when it says identification information to
`specifically say customer ID. That would be better. But when it
`says identification information, that is -- as we approached it, is
`that makes it obvious to one of ordinary skill in the art that it
`knows that it's either there or it could be.
`But you know, the more important point is the system,
`all these systems have to keep track of the user and its association
`with the data. I'll point out another example. If you look at Lu on
`column 2, this talks about the state the art prior to the '994 patent
`and it talks about at column 2 at the very top, the class queueing
`system may use a weight -- hold on a second. I'm on the wrong
`one. Hold on.
`There is a discussion which I'll talk about as I look for
`the specific cite to it, but there's a discussion in Lu talking about
`dropping data packets and when it's voice data packets. And you
`want to drop -- if you are going to use dropping of data packets
`for voice, you have got -- you want to drop data packets in the
`same communication. An
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
