Petition for Inter Partes Review of U.S. Patent No ...fishpostgrant.com/wp-content/uploads/js_composer/IPR2015-00578... · Petition for Inter Partes Review of U.S. Patent No. 8,055,820

Petition for Inter Partes Review of U.S. Patent No. 8,055,820

Paper No. 1

UNITED STATES PATENT AND TRADEMARK OFFICE

BEFORE THE PATENT TRIAL AND APPEAL BOARD

APPLE INC. Petitioner,

v.

CELLULAR COMMUNICATIONS EQUIPMENT LLC, Patent Owner

Patent No. 8,055,820

Issued: November 8, 2011 Filed: November 5, 2008 Inventor: Benoist Sebire

Title: APPARATUS, SYSTEM, AND METHOD FOR DESIGNATING A BUFFER STATUS REPORTING FORMAT BASED ON DETECTED PRE-SELECTED BUFFER CONDITIONS

____________________ Inter Partes Review No. IPR2015-00578

PETITION FOR INTER PARTES REVIEW OF U.S. PATENT NO. 8,055,820 UNDER 35 U.S.C. §§ 311-319 AND 37 C.F.R. § 42.1-.80 & 42.100-.123

________________________


i

TABLE OF CONTENTS

I. COMPLIANCE WITH REQUIREMENTS FOR A PETITION FOR INTER PARTES REVIEW ....................................................................... 1

A. Certification the ’820 Patent May Be Contested by Petitioner .................. 1

B. Fee for Inter Partes Review (§ 42.15(a)) .................................................... 2

C. Mandatory Notices (37 CFR § 42.8(b)) ..................................................... 2

D. Proof of Service (§§ 42.6(e) and 42.105(a)) .............................................. 3

II. Identification of Claims Being Challenged (§ 42.104(b)) ................................. 3

III. Relevant Information Concerning the Contested Patent .................................... 4

A. Effective Filing Date of the ’820 Patent ..................................................... 4

B. Person of Ordinary Skill in the Art ............................................................ 4

C. The ’820 Patent ........................................................................................... 5

1. Technical Overview .............................................................................. 5

2. Prosecution History ............................................................................... 7

D. Construction of Terms Used in the Claims ..............................................11

1. “a long buffer status reporting format” (All Claims); “a short buffer status reporting format” (All Claims) ........................12

2. “designating one of a plurality of buffer status reporting formats comprising a long buffer status report format and a short buffer status reporting format depending on the pre-selected condition detected” (All Claims) ....................................14

3. “designate[s] the long buffer status reporting format when there is sufficient uplink bandwidth to communicate using the long buffer status reporting format” (All Claims) ........................15

4. “radio bearer group” (Claims 3, 4, 5, 8, 9, 10, 11, 14, 15, 19, 20, 21 and 22) ................................................................................17

5. “monitoring means for monitoring a usage of a plurality of buffers” (Claim 23) .........................................................................18

6. “detecting means for detecting one of a plurality of pre-selected conditions corresponding to the plurality of buffers” (Claim 23) .........................................................................19


ii

7. “designating means for designating one of a plurality of buffer status reporting formats comprising a long buffer status reporting format and a short buffer status reporting format depending on the pre-selected condition detected” (Claim 23) ............................................................................................20

8. “communicating means for communicating a buffer status report to a network device in accordance with the buffer status reporting format designated” (Claim 23) .................................21

IV. Precise Reasons for Relief Requested ..............................................................22

A. U.S. Patent App. Pub. No. 2006/0143444 (“Malkamaki”) (Ex. 1012) .................................................................................................22

B. U.S. Patent App. Pub. No. 2007/0201369 (“Pedersen”) (Ex. 1027) .................................................................................................25

C. U.S. Patent No. 8,031,655 to Ye et al., (“Ye”) (Ex. 1005) ......................28

D. WO Patent Publication No. 2003019960A1 to Sarkkinen et al., (“Sarkkinen”) (Ex. 1030)..........................................................................29

E. Motivation to Combine .............................................................................29

F. Claims 1, 2-7, 9, 12-18, 20, and 23-24 Are Anticipated By Malkamaki ..........................................................................................30

1. Malkamaki Anticipates Claim 1 ..........................................................30

a) Preamble .........................................................................................30

b) Monitoring Step .............................................................................30

c) Detecting Step ................................................................................31

d) Designating Step ............................................................................32

e) Communicating Step ......................................................................33

2. Malkamaki Anticipates Claims 12 and 24 ..........................................34

a) Preamble .........................................................................................34

b) Processor, Memory, Program Code ...............................................35

c) Monitor ...........................................................................................35

d) Detect .............................................................................................35

e) Designate ........................................................................................36

f) Communicate .................................................................................36


iii

3. Malkamaki Anticipates Claim 23 ........................................................37

a) Preamble .........................................................................................37

b) Monitoring Means ..........................................................................38

c) Detecting Means .............................................................................39

d) Designating Means .........................................................................39

e) Communicating Means ..................................................................40

f) Wherein Clause ..............................................................................41

4. Malkamaki Anticipates Claims 2 and 13 ............................................41







G. Claims 1-24 Are Rendered Obvious by Malkamaki ................................45

1. Malkamaki Renders Independent Claims 1, 12, 23 and 24 Obvious ....................................................................................45

2. Malkamaki Renders Claims 2 and 13 Obvious ...................................46





7. Malkamaki Renders Claims 10 and 21 Obvious .................................51

8. Malkamaki Renders Claims 11 and 22 Obvious .................................53

9. Claims 1-24 are Rendered Obvious by Malkamaki in View of Pedersen ............................................................................55

10. Claims 1-24 are Rendered Obvious by Malkamaki in View of Ye ......................................................................................55

11. Malkamaki in View of Ye Renders Claims 3 and 14 Obvious ...........57

12. Malkamaki in View of Ye Renders Claims 10 and 21 Obvious .........58


iv

V. CONCLUSION ................................................................................................59

Attachment A. Proof of Service of the Petition

Attachment B. List of Evidence and Exhibits Relied Upon in Petition


I. COMPLIANCE WITH REQUIREMENTS FOR A PETITION FOR INTER PARTES REVIEW

A. Certification the ’820 Patent May Be Contested by Petitioner

Petitioner certifies it is not barred or estopped from requesting inter partes

review of U.S. Patent No. 8,055,820 (“the ’820 Patent”) (Ex. 1001). Neither

Petitioner, nor any party in privity with Petitioner, has filed a civil action

challenging the validity of any claim of the ’820 Patent. The ’820 Patent has not

been the subject of a prior inter partes review by Petitioner or a privy of Petitioner.

Petitioner also certifies this petition is filed within one year of the date of

service of a complaint alleging infringement of a patent. A complaint alleging

infringement of the ’820 Patent by Petitioner was filed on January 17, 2014, and

led to Civil Action No. 6-14-cv-31 in the United States District Court for Eastern

District of Texas. Based on service of process records, that complaint was not

served on Petitioner. See Ex. 1031. The case was dismissed without prejudice on

February 12, 2014. See Ex. 1006. Petitioner was then served with a complaint

alleging infringement of the ’820 Patent on April 14, 2014, which led to Civil

Action No. 6:14-cv-00251 in the United States District Court for the Eastern

District of Texas. Because the date of this petition is less than one year from the

service of this complaint, this petition complies with 35 U.S.C. § 315(b).

Petitioner therefore certifies this patent is available for inter partes review.


2

B. Fee for Inter Partes Review (§ 42.15(a))

The Director is authorized to charge the fee specified by 37 CFR § 42.15(a)

to Deposit Account No. 50-1597.

C. Mandatory Notices (37 CFR § 42.8(b))

The real party of interest of this petition is Apple Inc. (“Apple”) located at

One Infinite Loop, Cupertino, CA 95014. Lead and backup lead counsel are:

Lead Counsel

Joseph A. Micallef

Reg. No. 39,772

[email protected]

(202) 736-8492

Backup Lead Counsel

Jeffrey P. Kushan

Reg. No. 43,401

[email protected]

(202) 736-8914

Backup Counsel

Howard E. Levin

Reg. No. 50480

[email protected]

(312) 216-1620

Service on Petitioner may be made by mail or hand delivery to: Sidley

Austin LLP, 1501 K Street, N.W., Washington, D.C. 20005. The fax number for

lead and backup counsel is (202) 736-8711.

The ’820 Patent is the subject of IPR2014-01136 filed by Petitioners NEC

Corporation of America; NEC CASIO Mobile Communications, Ltd.; HTC

Corporation; ZTE (USA); Amazon.com, Inc; Pantech Co., Ltd.; Pantech Wireless,

Inc.; LG Electronics, Inc.; LG Electronics U.S.A., Inc.; Dell Inc. In addition to the

lawsuit pending against Petitioner, the ’820 Patent is also the subject of the

following patent infringement lawsuits filed by Patent Owner in the Eastern


3

District of Texas: Case No. 6:13-cv-00507-LED against HTC Corporation et al;

Case No. 6:13-cv-00508-LED against LG Electronics, Inc. et al; Case No. 6:13-cv-

00509-LED against Pantech Co., Ltd. et al; Case No. 6:13-cv-00511-LED against

ZTE Corporation et al; Case No. 6:13-cv-00568-LED against Amazon.com, Inc. et

al; Case No. 6:13-cv-00569-LED against Dell Inc.; Case No. 6:13-cv-00584-LED

against NEC CASIO Mobile Communications, Ltd. et al; Case No. 6:13-cv-00738-

LED against Microsoft Corporation; Case No. 6:14-cv-00251-LED against Apple,

Inc., et al; Case No. 6:13-cv-00572-LED against Motorola Mobility LLC et al;

Case No. 6:13-cv-00510-LED against Blackberry limited et al; and Case No. 6:14-

cv-00759-LED against Samsung Electronics Co., Ltd. et al.

D. Proof of Service (§§ 42.6(e) and 42.105(a))

Proof of service of this petition is provided in Attachment A.

II. Identification of Claims Being Challenged (§ 42.104(b))

Claims 1-24 of the ’820 Patent are unpatentable as being anticipated and

obvious over the prior art. Specifically:

(i) Claims 1-24 of the ’820 Patent are unpatentable as anticipated over U.S.

Patent App. Pub. No. 2006/0143444 by Malkamaki et al., (“Malkamaki”)

(Ex. 1012).

(ii) Claims 1-24 of the ’820 Patent are unpatentable as obvious over Malkamaki

and the knowledge of one of ordinary skill in the art.


4

(iii) Claims 1-24 of the ’820 Patent are unpatentable as obvious over Malkamaki

in view of U.S. Patent App. Pub. No. 2007/0201369 to Pedersen et al.,

(“Pedersen”) (Ex. 1027) and the knowledge of one of ordinary skill in the

art.

(iv) Claims 1-24 of the ’820 Patent are unpatentable as obvious over Malkamaki

in view of U.S. Patent No. 8,031,655 to Ye et al., (“Ye”) (Ex. 1005) and the

knowledge of one of ordinary skill in the art.

Petitioner’s proposed construction of the contested claims, the evidence relied

upon, and the precise reasons why the claims are unpatentable are provided in

§ IV, below. The evidence relied upon in this petition is listed in Attachment B.

III. Relevant Information Concerning the Contested Patent

A. Effective Filing Date of the ’820 Patent

The ’820 Patent issued from U.S. Application No. 12/289,825, filed on

November 5, 2008, and claims priority to Provisional Application No. 60/996,168

which was filed on November 5, 2007. The effective filing date of the claims of

the ’820 Patent is therefore no earlier than November 5, 2007. Ex. 1003 at ¶ 51.

B. Person of Ordinary Skill in the Art

A person of ordinary skill in the art in the field of the ’820 Patent would

have been familiar with the components of a cellular communications system (e.g.,

mobile units and base stations), standards documents describing the schemes for

communicating over wireless radio networks, such as standards documents

describing GSM, 3GSM/UMTS, and CDMA, and techniques for implementing


5

buffer status reporting in a communications system. That familiarity would have

come through at least an undergraduate degree in electrical engineering (or

equivalent degree) and at least three years of relevant work experience in the field

of cellular communications systems. Ex. 1003 at ¶ 117.

C. The ’820 Patent

1. Technical Overview

The ’820 Patent is directed to methods and systems used in cellular

telecommunications for reporting the status of various buffers located in User

Equipment (UE) and for sending reports concerning buffer status to a network

device such as a base station or network node. Ex. 1003 at ¶ 52; Ex. 1001 at

Abstract. The patent aims to increase efficiency and reduce the overhead of

sending buffer status reports by selecting a buffer status reporting format, for

example either a short or long buffer status reporting format, depending on certain

pre-selected conditions. Ex. 1003 at ¶ 52; Ex. 1001 at 1:40–59. The ’820 Patent

also describes determining whether there is enough uplink capacity to send the

long buffer status reporting format. Ex. 1003 at ¶ 52; Ex. 1001 at 1:60–67. Each

of the claims of the ’820 Patent requires designating a long buffer status reporting

format when there is sufficient “uplink bandwidth” to communicate the long buffer

status report. Ex. 1003 at ¶ 52; Ex. 1001 at 11:15–20; 12:1–6; 12:62–67; 14:3–8.


6

Figure 3 of the ’820 Patent illustrates the general method disclosed in the

patent. Ex. 1003 at ¶ 53; Ex. 1001 at Fig. 3. As the ’820 Patent explains, in this

general method the UE monitors a plurality of its buffers, detects one of a plurality

of pre-selected conditions corresponding to those buffers and designates one of a

plurality of buffer status reporting formats depending on the pre-selected condition

that it detects and communicates a buffer status report with the designated format

to the network device. Ex. 1003 at ¶ 54; Ex. 1001 at 5:40–50. The ’820 Patent

states that the “pre-selected conditions” that the UE detects can be, for example,

whether one or more buffers have data to send, or whether the data in the buffers

has exceeded a pre-determined threshold. Ex. 1003 at ¶ 55; Ex. 1001 at 7:58–63.

Figure 4 of the ’820 Patent describes additional details of the purported

invention including details of the “Designate Format” step of Figure 3. Figure 4

illustrates a procedure for detecting buffer conditions and designating a long or

short buffer report format based on “uplink capacity.” Ex. 1003 at ¶¶ 56-57; Ex.

1001 at Fig. 4. In Figure 4, the UE monitors the buffers to determine whether and

how many of those buffers have data. If only one buffer has data, the UE will

designate a short reporting format for the buffer status report. If more than one

buffer has data, then the UE will check to see if there is sufficient capacity for a

long buffer status reporting format. If there is sufficient capacity the UE will

designate the long buffer status reporting format for the multiple buffers with data.


7

If, however, there is not enough uplink capacity to use the long buffer status

reporting format, the UE will designate a short buffer status reporting format for

that buffer. Ex. 1003 at ¶ 57; Ex. 1001 at 8:6–39.

2. Prosecution History

The application from which the ’820 Patent issued was initially filed with 28

claims. Ex. 1003 at ¶ 58; Ex. 1002 at 58–63. In the first Office Action, dated

September 30, 2010, the Examiner rejected all pending claims, inter alia, as

anticipated by U.S. Patent No. 7,769,926 to Wu et al. (“Wu”) (Ex. 1018). Ex.

1003 at ¶ 59; Ex. 1002 at 119–121. At the time of the rejection, application claim

6, which depended from claims 1 and 4, required the designation of the long buffer

status reporting format “only” when there was sufficient “uplink capacity” to

communicate using that format:

6. The method of claim 4, wherein the designating unit is configured

to only designate the long buffer status reporting format when there is

sufficient uplink capacity to communicate using the long buffer status

reporting format.

Ex. 1002 at 59 (emphasis added). Claim 19, which depended from a different base

claim, included identical language. Id. at 61; Ex. 1003 at ¶ 60.

The Examiner explained the rejection of claims 6 and 19 as follows: “As per

claims 6 and 19, Wu also teaches designating the long buffer status reporting

format when there is sufficient uplink capacity to communicate using the long


8

buffer status reporting format (Wu; Col 6 Lines 41 – 47).” Ex. 1003 at ¶ 61; Ex.

1002 at 120. The cited passage of Wu (“Col 6 Lines 41 – 47”) states that the

system of Wu will designate a long buffer status report, instead of a short one, if

there is sufficient remaining space in a “protocol data unit” (“PDU”) about to be

sent by the user equipment to the network. Ex. 1003 at ¶ 61; Ex. 1018 at 6:21–57.

A protocol data unit, or “PDU,” is a message or packet sent from one device to

another. Ex. 1003 at ¶ 61; Ex. 1022, Vocabulary for 3GPP Specifications, 3GPP

TR 21.905 v8.2.0, September 2007, at 20.

Applicant responded on December 2, 2010 by amending claims 6 and 19 by

rewriting them into independent form and removing the requirement that the long

format be designated “only” when there was sufficient uplink capacity. The other

independent claims were similarly amended, such that, as amended, each

independent claim included the following wherein clause: “wherein the

designating [unit is configured to] designate(s) the long buffer status reporting

format when there is sufficient uplink capacity to communicate using the long

buffer status reporting format.” Ex. 1003 at ¶ 62; Ex. 1002 at 130–131, 133–134,

(emphasis added).

The Applicant argued that the claims were patentable over Wu because Wu

supposedly determines if the remaining space of a PDU is enough for an “empty

long BSR” that occurs when the buffers are empty, in contrast to the claimed


9

invention that can involve the amount of padding of the PDU when the buffers are

not all empty:

In addition, when there is no remaining data in the buffers 611-614, if

the remaining space of the PDU to be transmitted is enough to receive

an empty long BSR, the user equipment 61 uses the PDU to be

transmitted to transmit the data and the empty long BSR (step S809),

and otherwise the data and an empty short BSR (step S810).

However, Wu is silent as to teaching or suggesting, at least, "wherein

the designating designates the long buffer status reporting format

when there is sufficient uplink capacity to communicate using the

long buffer status reporting format," as recited in independent claim 6.

Wu appears to simply determine whether the remaining space of the

PDU to be transmitted is enough to receive an empty long BSR.

(Emphasis added) There is no teaching or suggestion of designating a

long buffer status reporting format when there is sufficient uplink

capacity to communicate as recited in independent claim 6.

(Emphasis added)

Ex. 1002 at 142; Ex. 1003 at ¶ 63.

On February 2, 2011, the Examiner issued a Final Office Action rejecting all

claims. In that action the Examiner maintained a number of § 112 and § 101

rejections, and maintained his view that Wu anticipated the pending claims, even

as amended. Ex. 1003 at ¶ 64; Ex. 1002 at 147-49.

On May 23, 2011 the Applicant conducted an Examiner interview where the

meaning of the claim phrase “uplink capacity” was discussed and the Examiner


10

interpreted the phrase “uplink capacity” to mean “the available space in the buffers

to receive sent data.” Ex. 1002 at 176. The Summary also states that the Examiner

“suggested that Applicant more clearly define ‘uplink capacity’ in the claims in

order to more clearly define Applicant’s invention.” Id.; Ex. 1003 at ¶ 65.

On July 1, 2011 the Applicant responded by again amending the claims.

This time, the wherein clause of each of the independent claims was amended such

that the phrase “when there is sufficient uplink capacity” was changed to “when

there is sufficient uplink bandwidth,” so that after the amendment each

independent claim included the following wherein clause: “wherein the designating

designates the long buffer status reporting format when there is sufficient uplink

bandwidth to communicate using the long buffer status reporting format.” Ex.

1002 at 191, 194, 196, 197 (emphasis added); Ex. 1003 at ¶ 67.

The Applicant repeated its argument that the claims were patentable over

Wu because Wu supposedly determines if the remaining space of a PDU is enough

for an “empty long BSR” that occurs when the buffers are empty, in contrast to the

claimed invention that can involve padding bits when the buffers are not all empty:





bandwidth to communicate as recited in independent claim 6[]


11

(Emphasis added) due to PDCP/RLC/MAC header granularity, the

present embodiment recited in the claims can have padding even

though not all buffers are empty. Thus, contrary to the "empty long

BSR" or "empty short BSR" of Wu, the present claim[] is able to

designate [] the long buffer status reporting format when there is

sufficient uplink bandwidth to communicate using the long buffer

status reporting format.

Ex. 1002 at 169-70, 200-201 (italics added); Ex. 1003 at ¶ 68.

A Notice of Allowance issued on July 25, 2011. The Examiner stated that

“Wu does not teach that the designation designates the long buffer status reporting

format when there is sufficient uplink bandwidth to communicate using the long

buffer status reporting format, as required by independent claim 6. Instead, Wu

teaches that the designation is based on the available space in the buffers to receive

sent data.” Ex. 1002 at 208-210 (emphasis in original); Ex. 1003 at ¶ 69.

D. Construction of Terms Used in the Claims

In this proceeding, claims must be given their broadest reasonable

construction in light of the specification. 37 CFR § 42.100(b). If Patent Owner

contends terms in the claims should be read to have a special meaning, those

contentions should be disregarded unless Patent Owner also amends the claims

compliant with 35 U.S.C. § 112 to make them expressly correspond to those

contentions. See 77 Fed. Reg. 48764 at II.B.6 (August 14, 2012); cf. In re Youman,

679 F.3d 1335, 1343 (Fed. Cir. 2012).


12

1. “a long buffer status reporting format” (All Claims); “a short buffer status reporting format” (All Claims)

The broadest reasonable construction of “a long buffer status reporting

format” is a format for reporting buffer status information that is longer than an

alternative format. The broadest reasonable construction of “a short buffer status

reporting format” is a format for reporting buffer status information that is shorter

than an alternative format.

The ordinary meaning of these phrases, particularly when read together, is

that they refer to two separate reporting formats, one being longer than the other.

The claims require that one or the other of these formats be “designat[ed],” see,

e.g., Ex. 1001 at 11:11–14, so they are clearly alternatives. Ex. 1003 at ¶ 77.

These conclusions are consistent with the ’820 Patent specification, which

consistently distinguishes between long and short buffer status reports, including

by suggesting that they each communicate more or less information, respectively.

See, e.g., Ex. 1003 at ¶ 78; Ex. 1001 at 1:53–59; see also id. at 1:60–64 (indicating

that the long format is used when there is sufficient uplink capacity); 1:64–67

(indicating that the long format is used when multiple buffers for different radio

bearer groups store data beyond a pre-selected threshold); 1:67–2:2 (indicating that

the short format is used when there is insufficient uplink capacity); Figs. 5–6

(setting forth short and long formats). A person of ordinary skill would read these

passages as indicating one of the reporting formats is longer (or shorter) than the


13

other, without requiring any particular lengths. Indeed, the ’820 Patent provides an

example with the specific length of the reports set forth, but confirms that it applies

only to “some embodiments”. See Ex. 1003 at ¶¶ 78-79; Ex. 1001 at 2:3–11.

Moreover, before the priority date of the ’820 Patent, it was known that

detailed, and therefore longer, buffer status reports provided the base station better

information with which to allocate network resources, but also required additional

reporting overhead that took up limited uplink bandwidth. See, e.g., Ex. 1003 at ¶

80; Ex. 1013, Standards Proposal R2-074204, “UE Buffer Status Reporting in E-

UTRAN,” October 8, 2007, at 1; Ex. 1014, Standards Proposal R2-071345,

“Enhancement to Buffer Status Reporting,” March 26, 2007, at 1. Conversely, less

detailed, and therefore shorter, buffer status reports provided the base station less

information, but required less overhead. See id. One of ordinary skill in the art

would therefore have known that buffer status reports of various sizes were

possible. See, e.g., Ex. 1003 at ¶ 80; Ex. 1010, Standards Proposal R2-073909,

“Scheduling information for E-UTRAN uplink,” October 8, 2007, at 1–2; Ex.

1011, Standards Proposal R2-060829, “Buffer Reporting for E-UTRAN,” March

27, 2006, at 1–3.

Petitioner also notes the claims use the phrase “reporting format,” and not

“report.” The word “format” usually refers to “a particular method of organizing

data.” Webster’s Third New International Dictionary (3rd ed. 2002), Ex. 1026 at 3.


14

A person of ordinary skill in the art would therefore understand that a “reporting

format” refers to how the information to be reported is arranged, and therefore

could encompass different size reports. Ex. 1003 at ¶ 81; Ex. 1020, Standards

Proposal R2-061915, “Comparison of UL Buffer Reporting/Scheduling Schemes

in LTE,” June 27, 2006, at 1.

Accordingly, the broadest reasonable construction of “a long buffer status

reporting format” is a format for reporting buffer status information that is longer

than an alternative format. The broadest reasonable construction of “a short buffer

status reporting format” is a format for reporting buffer status information that is

shorter than an alternative format. Ex. 1003 at ¶¶ 76–82

2. “designating one of a plurality of buffer status reporting formats comprising a long buffer status report format and a short buffer status reporting format depending on the pre-selected condition detected” (All Claims)

According to arguments made by the Patent Owner that relate to the scope of

the claims, the broadest reasonable construction of “designating one of a plurality

of buffer status reporting formats comprising a long buffer status report format

and a short buffer status reporting format depending on the pre-selected condition

detected” encompasses “designating” a buffer status report based on both the “pre-

selected condition detected” and “sufficient uplink bandwidth” as claimed in two

separate clauses of the claims: the “designating … depending on the pre-selected

condition detected” and a “wherein the designating designates… when there is


15

sufficient uplink bandwidth.” Ex. 1003 at ¶¶ 83–84; Ex. 1028 at 22-23; Ex. 1001 at

claim 1. Patent Owner argued that “the claims recite (and the specification

describes) a single designation … the ‘wherein’ clause, which expressly refers

back to ‘the designating’ already recited.” Ex. 1003 at ¶¶ 83-84; Ex. 1028, Patent

Owner’s Dec. 2, 2014 Response in Opposition to Defendants’ Motion for

Summary Judgment of Invalidity For Indefiniteness at 22-23. Patent Owner

rejected any construction that requires the claims to “designat[e] a particular

format depending only on the preselected condition detected.” Id.

Thus, the broadest reasonable interpretation of “designating one of a

plurality of buffer status reporting formats comprising a long buffer status report

format and a short buffer status reporting format depending on the pre-selected

condition detected” that would include Patent Owner’s interpretation in parallel

litigation is “designating a buffer status report format from the set of long and short

buffer status report formats based in part on the detection of a preselected

condition.” This construction is consistent with Figure 4 of the ’820 patent and

corresponding disclosure. Ex. 1001 at 8:6–39; Ex. 1003 at ¶¶ 56-57. Figure 4

shows a procedure that detects buffer conditions and designates a long or short

format based on “uplink capacity.” Id.

3. “designate[s] the long buffer status reporting format when there is sufficient uplink bandwidth to communicate using the long buffer status reporting format” (All Claims)


16

According to arguments made by the Patent Owner that relate to the scope of

the claims, “designate[s] the long buffer status reporting format when there is

sufficient uplink bandwidth to communicate using the long buffer status reporting

format” encompasses “designate[s] the long buffer status reporting format when

there is space available in the transport block’s padding to communicate using the

long buffer status reporting format regardless of whether the buffers are empty or

not.” Ex. 1003 at ¶¶ 86-89; see Ex. 1029 at 9.

According to Patent Owner, designating the long buffer status report when

there is sufficient uplink bandwidth to communicate using the long buffer status

reporting format includes the situation in which a long buffer status reporting

format is designated and communicated when “uplink resources are allocated for

buffered data (i.e., the buffers contain data waiting to be transferred from the UE to

the network)” and “the number of padding bits is equal to or larger than the size of

a Long BSR plus its sub-header.” Ex. 1003 at ¶86; Ex. 1029 at 9.

During prosecution, the Applicant made arguments to distinguish Wu that

are consistent with Patent Owner’s argument (above): the embodiment recited in

the claims relates to (1) the presence of a non-empty buffer and (2) sufficient

padding bits to hold a long BSR:





17


bandwidth to communicate as recited in independent claim 6[]

(Emphasis added) due to PDCP/RLC/MAC header granularity, the

present embodiment recited in the claims can have padding even

though not all buffers are empty. Thus, contrary to the "empty long

BSR" or "empty short BSR" of Wu, the present claim[] is able to

designate [] the long buffer status reporting format when there is

sufficient uplink bandwidth to communicate using the long buffer

status reporting format.

Ex. 1003 at ¶ 88; Ex. 1002 at 169-70, 200-201 (italics added).

Thus, the broadest reasonable interpretation of “designate[s] the long buffer

status reporting format when there is sufficient uplink bandwidth to communicate

using the long buffer status reporting format” that is consistent with Patent Owners

arguments and the File History encompasses “designate[s] the long buffer status

reporting format when there is space available in the transport block’s padding to

communicate using the long buffer status reporting format regardless of whether

the buffers are empty or not.” Ex. 1003 at ¶¶ 86-89; see Ex. 1029 at 9; Ex. 1002 at

169-70, 200-201.

4. “radio bearer group” (Claims 3, 4, 5, 8, 9, 10, 11, 14, 15, 19, 20, 21 and 22)

The broadest reasonable construction of “radio bearer group” is a group of

logical channels. The phrase “radio bearer” is a term of art in the field of cellular

communications that refers to a logical channel. See Vocabulary for 3GPP


18

Specifications, 3GPP TR 21.905 v8.2.0, September 2007 (Ex. 1022) at 21. In this

context, the phrase “radio bearer group” refers to a grouping of such logical

channels. Accordingly, the broadest reasonable construction of “radio bearer

group” is a group of logical channels. Ex. 1003 at ¶¶ 90-92.

5. “monitoring means for monitoring a usage of a plurality of buffers” (Claim 23)

The broadest reasonable construction of “monitoring means for monitoring a

usage of a plurality of buffers” is: (a) Function: monitoring a usage of a plurality of

buffers; (b) Structure is: the “monitoring unit” of Figure 2. Ex. 1003 at ¶ 95.

Claim 23 of the ’820 Patent is directed to “an apparatus” that includes

several means-plus-function elements, including a monitoring means, a detecting

means, a designating means, and a communicating means. Ex. 1001 at 12:51–67.

Figure 2 of the patent depicts “a block diagram of user equipment,” id. at 4:62–63,

that includes a monitoring unit, a detecting unit, a format designating unit, and a

communication unit, among other things. See Ex. 1001 at Fig. 2. Thus, Figure 2 is

clearly intended to be an example of the apparatus of claim 23. Ex. 1003 at ¶ 96.

The ’820 Patent also describes the operation of the monitoring unit as

follows: “[i]n some embodiments, the monitoring unit 210 is configured to monitor

a usage of the plurality of buffers 220. In certain embodiments, the monitoring

unit 210 and the detecting unit 230 cooperate to enable the detecting unit 230 to

detect one of a plurality of pre-selected conditions corresponding to the plurality of


19

buffers.” Ex. 1001 at 6:1–6 (emphasis added). The ’820 Patent therefore clearly

links the monitoring unit 210 with the function of monitoring a usage of a plurality

of buffers. Ex. 1003 at ¶ 97.

The ‘820 Patent also states that the “unit” structures disclosed in the

specification can be implemented in several different ways, including (i) hardware

circuitry comprising custom VLSI circuits or gate arrays, off-the-shelf

semiconductors such as logic chips, transistors, or other discrete components; (ii)

programmable hardware devices such as field programmable gate arrays,

programmable array logic, programmable logic devices or the like, and (iii)

software for execution by various types of processors, comprising one or more

physical or logical blocks of computer instructions, physically located together or

stored as disparate instructions in different locations (collectively “Structures”).

See Ex. 1003 at ¶ 95; Ex. 1001 at Fig. 2; 7:13–43. Thus, the broadest reasonable

construction is as described above. Ex. 1003 at ¶ 99.

6. “detecting means for detecting one of a plurality of pre-selected conditions corresponding to the plurality of buffers” (Claim 23)

The broadest reasonable construction of “detecting means for detecting one

of a plurality of pre-selected conditions corresponding to the plurality of buffers”

is: (a) Function: detecting one of a plurality of pre-selected conditions

corresponding to the plurality of buffers; (b) Structure is: the “detecting unit” of


20

Figure 2, implemented in the Structures identified above. See Ex. 1003 at ¶¶ 100-

101, 104.

The ’820 Patent describes the operation of the detecting unit as follows:

“[i]n certain embodiments, the monitoring unit 210 and the detecting unit 230

cooperate to enable the detecting unit 230 to detect one of a plurality of pre-

selected conditions corresponding to the plurality of buffers.” Ex. 1001 at 6:2–6

(emphasis added). The ’820 Patent therefore clearly links the detecting unit 230

with the function of detecting one of a plurality of pre-selected conditions

corresponding to the plurality of buffers. Ex. 1003 at ¶ 102.

Moreover, as demonstrated above, the ‘820 Patent states that the “unit”

structures disclosed in the specification can be implemented using the Structures.

See Ex. 1003 at ¶ 103; Ex. 1001 at Fig. 2; 7:13–43. Those structures therefore

constitute corresponding structure for this means element.

7. “designating means for designating one of a plurality of buffer status reporting formats comprising a long buffer status reporting format and a short buffer status reporting format depending on the pre-selected condition detected” (Claim 23)

The broadest reasonable construction of “designating means for designating

one of a plurality of buffer status reporting formats comprising a long buffer status

reporting format and a short buffer status reporting format depending on the pre-

selected condition detected” is: (a) Function: designating one of a plurality of


21

buffer status reporting formats comprising a long buffer status reporting format and

a short buffer status reporting format depending on the pre-selected condition

detected; (b) Structure is: the “format designating unit” of Figure 2, implemented

in the Structures identified above. See Ex. 1003 at ¶¶ 105, 109.

The ’820 Patent also describes the operation of the format designating unit

as follows: “[i]n certain embodiments, the designating unit 260 is configured to

designate one of a plurality of buffer status reporting formats depending on the pre-

selected condition detected. In certain embodiments, the plurality of buffer status

reporting formats may include a short format and a long format.” Ex. 1001 at

6:10–15. The ’820 Patent therefore clearly links the format designating unit 260

with the function of designating one of a plurality of buffer status reporting formats

comprising a long buffer status reporting format and a short buffer status reporting

format depending on the pre-selected condition detected. Ex. 1003 at ¶ 107.

Moreover, as noted above, the ’820 Patent states that the “unit” structures

disclosed in the specification can be implemented using the Structures. See Ex.

1003 at ¶ 108; Ex. 1001 at Fig. 2; 7:13–43. Those structures therefore constitute

corresponding structure for this means element. Ex. 1003 at ¶ 109;

8. “communicating means for communicating a buffer status report to a network device in accordance with the buffer status reporting format designated” (Claim 23)


22

The broadest reasonable construction of “communicating means for

communicating a buffer status report to a network device in accordance with the

buffer status reporting format designated” is: (a) Function: communicating a

buffer status report to a network device in accordance with the buffer status

reporting format designated; (b) Structure is: the “communication unit” of Figure

2, implemented in the Structures. See Ex. 1003 at ¶¶ 110, 115.

The ’820 Patent also clearly links the communication unit 270 with the

function of communicating a buffer status report to a network device in accordance

with the buffer status reporting format designated. Ex. 1003 at ¶¶ 112–113; Ex.

1001 at 6:36–39 (“In certain embodiments, the communicating unit 270 is

configured to communicate a buffer status report to a network device in

accordance with the buffer status reporting format designated.”) (emphasis added).

Moreover, the ’820 Patent states that the “unit” structures disclosed in the

specification can be implemented using the Structures. See Ex. 1003 at ¶ 114; Ex.

1001 at Fig. 2; 7:13–43. Those structures therefore disclose corresponding

structure for this means element.

IV. Precise Reasons for Relief Requested

A. U.S. Patent App. Pub. No. 2006/0143444 (“Malkamaki”) (Ex. 1012)

The Malkamaki patent application publication, entitled “Method and

Apparatus for Communicating Scheduling Information From a UE to a Radio


23

Access Network” was published on June 29, 2006 based on Application No.

11/289,664 filed November 28, 2005. Ex. 1012 at face. The listed inventor of the

’820 Patent, Benoist Sebire, is also listed as an author of Malkamaki. Malkamaki

is prior art to the ’820 Patent at least under Section 102(b). Ex. 1003 at ¶118.

Malkamaki is directed to a method and apparatus for communicating

scheduling information from user equipment (“UE”) to radio access network

equipment (e.g., base station or “Node B”) in wireless communication systems.

Ex. 1003 at ¶ 119; Ex. 1012 at ¶¶ 3, 8-9. Within a wireless communication system,

UEs transmit information in what are called transport blocks that have a fixed size

selected from a set of possible fixed sizes. Ex. 1003 at ¶ 119; Ex. 1012 at ¶ 10-11.

After buffered data that has been collected for transmission and related headers are

added into the transport block, an algorithm in the UE calculates the padding, or

the number of padding bits necessary to fill in the remainder of the transport

block. Ex. 1003 at ¶ 119; Ex. 1012 at ¶ 19-23. Malkamaki discusses the

advantages of frequently sending scheduling information (“SI”) reports to the

network in order to optimize the network, but notes the disadvantages of frequent

SI reports in terms of requiring overhead and use of valuable system resources for

the reports. Ex. 1003 at ¶120; Ex. 1012 at ¶¶ 8-9. Malkamaki identifies the need

for a more efficient way to send frequent SI reports in the uplink direction (from

the UE to the network) with reduced overhead. Id. To address this need,


24

Malkamaki discloses various embodiments of a UE device sending SI reports of

variable sizes to the network, where the size of the SI reports conforms to the

amount of padding bits initially available in the protocol data unit (“PDU”). Ex.

1003 at ¶ 120; Ex. 1012 at ¶¶ 10, 22, 25, 60, Table 1. Malkamaki thereby reduces

overhead by replacing unused padding bits in a communication signal with SI

reports. Id.

The SI reports disclosed in Malkamaki may include UE buffer status

information for one or more buffers. Ex. 1003 at ¶¶121-122; Ex. 1012 at ¶¶ 6, 22,

27, 60, Table 1. Malkamaki discloses embodiments where the buffers and

corresponding SI buffer status reports pertain to different “priorities” or different

MAC-d flows or logical channels. Ex. 1003 at ¶¶ 121-122; Ex. 1012 at ¶ 60.

Priorities in this context are also referred to as traffic priorities or traffic flows, and

correspond to a grouping of logical channels that have the same priority. Id.

As one example, Malkamaki discloses four different sized buffer status

reports (from 6 to 24 bits). Id. In the example, each 6-bit field corresponds to the

buffer status of one of four different priorities and the size of the report depends on

the number of priorities that are represented in the report. Id. In this example, the

shortest buffer format is 6 bits, and the longest format is 24 bits. In another

example, short buffer status reports of 8 bits and long buffer status reports of 16

bits are disclosed. Ex. 1003 at ¶ 121; Ex. 1012 at ¶¶ 24-25.


25

Malkamaki discloses triggering SI buffer status reports “when the buffer

content increases above some threshold.” Ex. 1003 at ¶ 122; Ex. 1012 at ¶¶ 7, 20.

Malkamaki discloses that buffer status reports may be contained in MAC-e PDU

headers or in padding bits. Id. at ¶ 20. In some embodiments, the buffer status

report is always placed in the padding bits if the amount of padding bits is

sufficient size to fit the report. Ex. 1003 at 122; Ex. 1012 at ¶¶ 21, 22.

Malkamaki discloses including a buffer status report “if there is

capacity/space available sufficient to accommodate it.” Ex. 1012 at ¶ 26; Ex. 1003

at ¶ 123. Malkamaki also discloses that “when the size of the padding permits,”

the UE places the buffer status report in the transport block “‘instead’ of padding.”

Id. The size of the buffer status report is variable and “depends on the size of the

padding.” Id. at ¶ 22. “For instance, if there were room for 24 bits in the transport

block, instead of padding the transport block with 24 bits of padding, the UE could

send buffer status for 4 different priorities [using 6 bits for each priority].” Id. at ¶

60; Ex. 1003 at ¶ 123.

B. U.S. Patent App. Pub. No. 2007/0201369 (“Pedersen”) (Ex. 1027)

U.S. Patent App. Pub. No. 2007/0201369 (“Pedersen”) was published

August 30, 2007 and is entitled “Apparatus, Method, and Computer Program

Product Providing Threshold-Based Buffer State Reports from User Equipment to

a Wireless Network.” Ex. 1027 at face. Pedersen claims priority to provisional


26

application No. 60/765,082, filed February 3, 2006, which includes a disclosure of

the substantive teachings of Pedersen. See generally Ex. 1033; Ex. 1003 at ¶ 125.

Pedersen is prior art to the ’820 Patent at least under Section 102(a). Id.

Pedersen is directed to addressing the same problem addressed in

Malkamaki of reducing system overhead when sending frequent SI buffer status

reports to optimize network resources. Ex. 1003 at ¶ 128; Ex. 1010 at §§ 1-2; Ex.

1011 at §§ 1-2; Ex. 1027 at ¶¶ 30-34, 47. Like Malkamaki, Pedersen is directed to

the reduction of overhead used for SI buffer status reporting schemes for at least

3GPP HSUPA wireless network technology. Id. Pedersen explains that prior art

systems are not optimal because they waste system bandwidth. Ex. 1003 at ¶ 128;

Ex. 1027 at ¶ 31.

Similar to the disclosure of Malkamaki, Pedersen pertains to buffer status

reports for different logical channels, flows, or priorities and priority-based buffer

status reports. Ex. 1003 at ¶ 129; Ex. 1027 at ¶ 54. Pedersen discloses that the

priorities correspond to groupings of logical channels such as radio bearer groups.

Ex. 1003 at ¶ 129; Ex. 1027 at ¶ 35, 55, 66. Like Malkamaki, Pedersen discloses

triggering reports based on buffer thresholds as illustrated in Figure 2. Figure 2 of

Pedersen shows a plurality of buffer thresholds used to trigger buffer status reports

for four different traffic priority flows, depending on the amount of data in the

buffers. Ex. 1003 at ¶ 129; Ex. 1027 at Fig. 2, ¶¶ 55, 59.


27

Pedersen discloses hardware and software structures typically found in prior

art UE. Figure 1 illustrates the basic hardware components of a UE device (10)

including a processor, memory, and program code. Ex. 1003 at ¶ 131; Ex. 1027 at

Fig. 1; ¶¶ 48-52.

As further background, two other prior art references, 3GPP Standards

Proposal R2-073909 (Ex. 1010) and 3GPP Standards Proposal R2-060829 (Ex.

1011) include a substantially identical illustrative diagram to Pederson’s Figure 2

and similar disclosure. Ex. 1003 at ¶¶ 126-130. 3GPP Standards Proposals R2-

060829 and R2-073909 disclose various sized buffer status reports reflecting status

of different numbers of logical channels and priorities. These buffer status

reporting formats include “absolute buffer status reports” and “priority-based

buffer status reports.” Ex. 1003 at 130; Ex. 1011 at Section 3.2; Ex. 1010 at

Section 2, 4. 3GPP Standards Proposals R2-060829 also explains that buffer status

reports disclosed may be “piggybacked” to control or user plane data. Ex. 1003 at

¶ 131; Ex. 1011 at Section 4. The term “piggybacking” is a well-known term of art

referring to the concept of including control information in a PDU carrying user

information so that an explicit extra control PDU does not have to be sent, thus

saving bandwidth. Ex. 1003 at ¶ 130. The particular application of piggybacking

disclosed in 3GPP Standards Proposal R2-060829 is replacing the padding bits in a

PDU with a buffer status report. Id.


28

C. U.S. Patent No. 8,031,655 to Ye et al., (“Ye”) (Ex. 1005)

Ye issued on October 4, 2011 from Application No. 11/902,451 filed

September 21, 2007. Ex. 1005 at face. Ye claims priority to provisional

application No. 60/848,641, filed October 3, 2006, which includes a disclosure of

the substantive teachings of Ye. See generally Ex. 1007. Ye is prior art to the

’820 Patent at least under Section 102(e). Ex. 1003 at ¶ 133.

Ye is directed to a method of communicating buffer status information to a

base station in a way that controls and minimizes reporting overhead. Ex. 1003 at

¶ 134; Ex. 1005 at Abstract. In the scheme of Ye, the particular buffer status

reporting format used is designated by and in response to a “granularity level”

calculated by the base station. Ex. 1003 at ¶ 134; Ex. 1005 at Abstract; 4:61–6:50;

6:55–8:12. The appropriate granularity level is determined based on various

system conditions. Ex. 1003 at ¶ 134; Ex. 1005 at Abstract; 4:61–6:50. Ye states

that the base station may employ one or more of these conditions when calculating

the granularity level. Ex. 1003 at ¶134; Ex. 1005 at 4:63–65. Ye explains that one

category of system conditions which can be used in the determination of the

granularity level is the sufficiency of the “scheduling grant” from the base station

to user equipment (“UE”), as indicated by a “satisfaction bit” sent from the user

equipment. See Ex. 1003 at ¶ 137; Ex. 1005 at 5:49–67. Ye states that “[t]he

scheduling grant is an allocation by the base station to the UE of uplink bandwidth


29

resources.” Ex. 1005 5:56–58 (emphasis added). Ye’s “scheduling grant” thus

refers to the uplink bandwidth allocated to the subscriber station. Ex. 1003 at ¶

138. Once the appropriate granularity level is determined based on one or more of

the conditions, the format of the buffer status report is designated. Ex. 1003 at ¶

140. Ye discloses seven different buffer status reporting formats of increasing

length that can be designated based on the granularity level. Id..

D. WO Patent Publication No. 2003019960A1 to Sarkkinen et al., (“Sarkkinen”) (Ex. 1030)

WO Patent Publication No. 2003019960A1 (“Sarkkinen”) was published on

March 6, 2003 and is therefore 102(b) prior art to the ’820 patent. Ex. 1030.

Sarkkinen relates to methods for communicating data within a network. Id. at

Abstract; Ex. 1003 at ¶ 146. Sarkkinen relates to enhancing methods of

communicating data in a communications network. Id. The scheme of Sarkkinen

provides for a specific frame structure that can be used to communicate data and

control information, such as a user buffer size. Id. at Abstract; Ex. 1030, Fig. 8.

The “user buffer size,” is used to inform the communications device how much

data belonging to the same data flow, or buffer, is still left to be transmitted. Id. at

24; Ex. 1003 at ¶ 146.

E. Motivation to Combine

A person of ordinary skill in the art would be motivated to combine

Malkamaki with Pederson, Ye, and Sarkkinen. Ex. 1003 at ¶ 147. Malkamaki,


30

Pederson, Ye, and Sarkkinen each pertain to solving the same problem of reducing

overhead and sending efficient buffer status reports in wireless communications

networks. Id. Malkamaki and Pederson relate to the same HSUPA technology and

threshold-based buffer status reports. Id. Also, each of the claimed elements was

well-known in the prior art at the time of the alleged invention, including

threshold-based buffer status reports and variable-length buffer reporting formats.

Id. Combining these known concepts recited in each of the prior art references,

where each is merely used in its usual and known manner, yields the predictable

result of reduced overhead and efficient buffer status reporting, as a person of

ordinary skill in the art would expect and be motivated to employ. Id. Thus, one a

person of ordinary skill in the art would be motivated to combine these references.

Id.

F. Claims 1, 2-7, 9, 12-18, 20, and 23-24 Are Anticipated By Malkamaki

1. Malkamaki Anticipates Claim 1

a) Preamble

The preamble of claim 1 of the ’820 patent recites “[a] method, comprising.”

Malkamaki discloses a method of communicating buffer status reports between the

UE and base station. Ex. 1012 at ¶¶ 9-10; Ex. 1003 at ¶ 149. Malkamaki therefore

discloses the preamble of claim 1.

b) Monitoring Step


31

Claim 1 requires the step of “monitoring a usage of a plurality of buffers.”

Malkamaki discloses the existence of multiple buffers, each associated with

different priority data. Ex. 1012 at ¶¶ 6, 7, 20, 24, 60; Ex. 1003 at ¶¶ 152-153.

Information about each buffer can be communicated. Id. at ¶¶ 7, 20, and 24. For

example, Malkamaki discloses sending a 6-bit buffer status report for four different

buffers, each having a different priority. Ex. 1012 at ¶ 60; Ex. 1003 at ¶¶ 152-153.

As stated in Malkamaki, “if there were room for 24 bits in the transport block, . . .

the UE could send buffer status for 4 different priorities.” Ex. 1012 at ¶ 60. In

order to send the buffer status report for the four different buffers corresponding to

4 different priorities, the Malkamaki invention must monitor the usage of the

plurality of buffers. See Ex. 1012 at ¶ 60; Ex. 1003 at ¶ 153. Thus, Malkamaki

discloses monitoring usage of a plurality of buffers as claimed in the monitoring

step of claim 1. Ex. 1003 at ¶ 154.

c) Detecting Step

Claim 1 requires the step of “detecting one of a plurality of pre-selected

conditions corresponding to the plurality of buffers.” As described above,

Malkamaki discloses a plurality of buffers. Ex. 1012 at ¶ 60. Malkamaki also

discloses detecting one of a plurality of pre-selected conditions corresponding to

the buffers. Ex. 1012 at ¶¶ 6, 7, 20, 60; Ex. 1003 at ¶ 156. For example,

Malkamaki discloses detecting when data within the buffers exceeds “some


32

threshold.” Ex. 1012. at ¶¶ 7, 20; Ex. 1003 at ¶ 156. This means that the particular

threshold to be detected could take on differing values. Ex. 1003 at ¶ 157. These

threshold conditions correspond to the plurality of buffers because each relates to

the amount of data within the buffers. Ex. 1003 at ¶ 158. Thus, Malkamaki

discloses the detecting step of claim 1. Ex. 1003 at ¶ 159.

d) Designating Step

Claim 1 requires the step of “designating one of a plurality of buffer status

reporting formats comprising a long buffer status reporting format and a short

buffer status reporting format depending on the pre-selected condition detected.”

Malkamaki discloses a plurality of buffer status reporting formats

comprising a long buffer status reporting format and a short buffer status reporting

format. Ex. 1012 at ¶¶ 10, 22, 24-25, 27, 60. In one embodiment, a short 6-bit

format buffer status report comprises 3 bits of priority information and 3 bits of

buffer status information. Ex. 1012 at ¶ 60. A long 24-bit format buffer status

report comprises four 6-bit buffer status fields. Ex. 1012 at ¶ 60. Malkamaki

further discloses that the buffer status report can vary in size depending on the

types of scheduling information reported or the different sets of scheduling

information included in the report. Ex. 1012 at ¶¶ 22, 27; see Ex. 1012 at ¶¶ 24-25

(disclosing an example short buffer status report that is 8 bits long and a long

buffer status report that is 16 bits long).


33

Malkamaki discloses designating one of the plurality of buffer status

reporting formats depending in part on the detection of a pre-selected condition.

Ex. 1012 at ¶¶ 10, 22, 25, 27, 60. For instance, when one or more buffers has data

above a zero threshold (or above a non-zero threshold), a buffer status report is

designated and subsequently communicated. Ex. 1012 at ¶¶ 7, 20, 60; Ex. 1003 at

¶ 167. Thus, Malkamaki discloses the designating step of claim 1 under the

broadest reasonable interpretation set forth above. Ex. 1003 at ¶ 168.

e) Communicating Step

Claim 1 requires the step of “communicating a buffer status report to a

network device in accordance with the buffer status reporting format designated

wherein the designating designates the long buffer status reporting format when


reporting format.”

Malkamaki discloses communicating a long buffer status when there is

sufficient uplink bandwidth for the long buffer status report. Ex. 1012 at ¶¶ 10-11,

22, 26-27, 60; Ex. 1003 at ¶ 171. For example, Malkamaki discloses

communicating a long buffer status report (which can include information about 4

buffers and be 24 bits in length). Ex. 1003 at ¶ 171; Ex. 1012 at ¶ 60. More

generally, Malkamaki discloses that the leftover portion of the MAC PDU should

be used to determine the format communicated, “by comparing the size of the


34

[buffer status reporting] information with the difference between the size of the

communication signal before any padding and the selected fixed size of the

communication signal.” Ex. 1012 at ¶¶ 11, 27, 60; Ex. 1003 at ¶ 172. In contrast

to the supposed distinguishing characteristic that Applicant cited to distinguish Wu

during prosecution (determining whether the remaining space of the PDU to be

transmitted is enough to receive only a empty long BSR), Malkamaki is not limited

to determining the size of the padding for empty BSRs. Ex. 1003 at ¶ 173. In fact,

Malkamaki does not disclose the concept of empty BSRs, and thus cannot be

limited to such. Id. Thus, Malkamaki discloses the communicating step of claim

1. Id. at ¶ 176.

2. Malkamaki Anticipates Claims 12 and 24

a) Preamble

Claim 12 requires “[a]n apparatus, comprising.” Malkamaki discloses both

a UE and a base station apparatus that practice the methods described in

Malkamaki and claim 12 of the ’820 Patent. Ex. 1012 at Figs. 1, 9; ¶¶ 12, 58-61;

cl. 15-16, 19-20; Ex. 1003 at ¶¶ 222-224. Claim 24 recites “[a] non-transitory

computer-readable medium encoded with a computer program configured to

control a processor to perform operations comprising.” Malkamaki discloses a

computer readable storage structure embodying computer program code, which


35

can has instructions for a processor to perform operations. Ex. 1012 at cl. 17; Ex.

1003 at ¶¶ 289-291.

b) Processor, Memory, Program Code

Claim 12 also requires “a processor; and a memory including computer

program code, the memory and the computer program code configured to, with the

processor.” Malkamaki discloses a computer program product comprising

computer readable storage embodying computer program code configured to be

executed by a computer processor. Ex. 1012 at cl. 17; Ex. 1003 at ¶¶ 225-226.

c) Monitor

Claim 12 requires the memory, computer program code, and processor to

“cause the apparatus at least to monitor a usage of a plurality of buffers.” Claim

24 requires that the computer program is configured to control a processor to

perform operations of “monitoring a usage of a plurality of buffers.” For the

reasons stated above for the monitoring step of claim 1, Malkamaki discloses these

claim elements. Ex. 1012 at ¶¶ 6-7, 20, 60, cl. 17; Ex. 1003 at ¶¶ 227-229, 292-

294.

d) Detect

Claim 12 requires the memory and the computer program code configured

to, with the processor, cause the apparatus at least to “detect one of a plurality of

pre-selected conditions corresponding to the plurality of buffers.” Claim 24

requires that the computer program is configured to control a processor to perform


36

operations of “detecting one of a plurality of pre-selected conditions

corresponding to the plurality of buffers.” For the reasons stated with respect to

the detecting step of claim 1, Malkamaki discloses these claim elements. Ex. 1012

at ¶¶ 6, 7, 20, 60, cl. 17; Ex. 1003 at ¶¶ 230-232, 295-297.

e) Designate


to, with the processor, cause the apparatus at least to “designate one of a plurality

of buffer status reporting formats comprising a long buffer status reporting format


detected.” Claim 24 requires that the computer program is configured to control a

processor to perform operations of “designating one of a plurality of buffer status

reporting formats comprising a long buffer status reporting format and a short

buffer status reporting format depending on the pre-selected condition detected.”

For the reasons stated with respect to the designating step of claim 1, Malkamaki

discloses these claim elements. Ex. 1012 at ¶¶ 10, 22, 24-25, 27, 60, cl. 17; Ex.

1003 at ¶¶ 233-235, 298-306.

f) Communicate


to, with the processor, cause the apparatus at least to “communicate a buffer status

report to a network device in accordance with the buffer status reporting format


37

designated, wherein the designating unit is configured to designate the long buffer

status reporting format when there is sufficient uplink bandwidth to communicate

using the long buffer status reporting format.” Claim 24 requires the operations

comprise “communicating a buffer status report to a network device in accordance

with the buffer status reporting format designated, wherein the designating

designates the long buffer status reporting format when there is sufficient uplink

bandwidth to communicate using the long buffer status reporting format.”

For the reasons stated with respect to the communicating step of claim 1,

Malkamaki discloses these claim elements. Ex. 1012 at ¶¶ 10, 11, 22, 26, 27, 60,

cl. 17; Ex. 1003 at ¶¶ 237, 308. As described with respect to claim 1, Malkamaki

discloses that the long buffer status reporting format is designated when there is

sufficient uplink bandwidth. Ex. 1012 at ¶¶ 10, 11, 22, 26, 27, 60; Ex. 1003 at ¶

237 . Thus, Malkamaki discloses the apparatus of claim 12 and computer readable

medium of claim 24; Ex. 1003 at ¶¶ 238, 309.

3. Malkamaki Anticipates Claim 23

a) Preamble

The preamble of claim 23 recites “[a]n apparatus, comprising.”

Malkamaki discloses both a UE and a base station apparatus that are able

practice the methods described in Malkamaki and claim 23 of the ’820 Patent. Ex.

1012 at Figs. 1, 9; ¶¶ 12, 58-61; cl. 15-17, 19-20; Ex. 1003 at ¶ 260.


38

b) Monitoring Means

Claim 23 requires “monitoring means for monitoring a usage of a plurality

of buffers”. As discussed above with respect to claims 1, 12 and 24, Malkamaki

discloses the function of monitoring a usage of a plurality of buffers. Ex. 1012 at

¶¶ 60, 6, 7, 20 and 24; Ex. 1003 at ¶ 264.

Malkamaki also discloses a UE including memory, computer program code,

and a processor for performing the monitoring described above with respect to

claim 1. See Ex. 1003 at ¶ 265; Ex. 1012 at ¶¶ 6-7, 12-13, claim 17. Petitioner

observes that nothing in the ’820 Patent identifies any feature of the corresponding

structure of this means element that is novel, unknown or unconventional in any

way. Malkamaki also discloses the use of conventional software and hardware.

See Ex. 1003 at ¶ 265; Ex. 1012 at ¶¶ 6-7, 12-13, claim 17. There are therefore no

substantial differences between the disclosed corresponding structure of this means

element and the structure of Malkamaki, and a person of ordinary skill in the art

would understand the conventional software and UE hardware of Malkamaki to be

interchangeable with the conventional software and hardware corresponding to this

claim element. Ex. 1003 at ¶ 265. Malkamaki therefore discloses structure that is

at least equivalent to the structure disclosed in the ’820 Patent. See Ex. 1003 at ¶¶

265-66; Ex. 1012 at ¶¶ 6-7, 12-13, claim 17. Malkamaki therefore discloses the

“monitoring means” of claim 23.


39

c) Detecting Means

Claim 23 requires “detecting means for detecting one of a plurality of pre-

selected conditions corresponding to the plurality of buffers.” As discussed above

with respect to claims 1, 12 and 24, Malkamaki discloses the function of detecting

one of a plurality of pre-selected conditions corresponding to the plurality of

buffers. See Ex. 1012 at ¶¶ 6, 7, 20, 60; Ex. 1003 at ¶ 270. For the same reasons

stated above with respect to the “monitoring means” element, the software and UE

hardware structures of Malkamaki are no more than insubstantially different from,

and are interchangeable with, the disclosed corresponding structure for this claim

element, and are therefore at least equivalent. Ex. 1003 at ¶ 271. Malkamaki

therefore discloses the “detecting means” of claim 23. See Ex. 1003 at ¶ 272.

d) Designating Means

Claim 23 requires “designating means for designating one of a plurality of

buffer status reporting formats comprising a long buffer status reporting format


detected.” As discussed above with respect to claims 1, 12 and 24, Malkamaki

discloses the function of designating one of a plurality of buffer status reporting

formats comprising a long buffer status reporting format and a short buffer status

reporting format depending on the pre-selected condition detected. Ex. 1012 at ¶¶

10, 22, 24-25, 27, 60; Ex. 1003 at ¶ 276. For the same reasons stated above with


40

respect to the “monitoring means” element, the software and UE hardware

structures of Malkamaki are no more than insubstantially different from, and are

interchangeable with, the disclosed corresponding structure for this claim element,

and are therefore at least equivalent. Ex. 1003 at ¶¶ 105-109; 273-278.

Malkamaki therefore discloses the “designating means” of claim 23. See Ex. 1003

at ¶¶ 273-278.

e) Communicating Means

Claim 23 requires “communicating means for communicating a buffer status

report to a network device in accordance with the buffer status reporting format

designated.” As discussed above with respect to claims 1, 12 and 24, Malkamaki

discloses the function of communicating a buffer status report to a network device

in accordance with the buffer status reporting format designated. See Ex. 1012 at

¶¶ 10, 11, 22, 26, 27, 60; Ex. 1003 at ¶ 282. For the same reasons stated above

with respect to the “monitoring means” element, the software and UE hardware

structures of Malkamaki are no more than insubstantially different from, and are

interchangeable with, the disclosed corresponding structure for this claim element,

and are therefore at least equivalent. Ex. 1003 at ¶ 283. Malkamaki therefore

discloses the “communicating means” of claim 23. See Ex. 1003 at ¶ 284.


41

f) Wherein Clause

Claim 23 also requires “wherein the designating means designates the long

buffer status reporting format when there is sufficient uplink bandwidth to

communicate using the long buffer status reporting format.” As discussed above

with respect to claims 1, 12 and 24, Malkamaki discloses the limitation “wherein

the designating means designates the long buffer status reporting format when


reporting format.” Ex. 1012 at ¶¶ 10, 11, 22, 26, 27, 60. Accordingly, Malkamaki

anticipates claim 23. Ex. 1003 at ¶ 288.


Claims 2 and 13 require “wherein the buffer status reporting format

minimizes buffer status reporting overhead created by the communicating of the

buffer status report.” Malkamaki explains that “[s]cheduling information requires

some overhead [] and therefore should not be sent too often.” Ex. 1012 at ¶ 8.

Malkamaki subsequently discloses that the purpose of the Malkamaki invention is

to “provide scheduling information [] without using undue network capacity.” Id.

at 9. The buffer status reporting format minimizes reporting overhead created by

the communicating of the buffer status report, for instance, by “send[ing] an SI

data item ‘instead’ of padding.” Id. at ¶ 26. Thus, Malkamaki discloses the

dependent limitation of claims 2 and 13. Ex. 1003 at ¶¶ 177-181, 240.


42


Claims 3 and 14 require “wherein the plurality of pre-selected conditions

comprises a buffer associated with a radio bearer group storing data beyond a

pre-selected threshold.” Malkamaki discloses detecting the condition that a buffer

associated with a radio bearer group has data beyond some threshold. Ex. 1012 at

¶¶ 7, 20; Ex. 1003 at ¶¶182-183, 241-242. Thus, Malkamaki discloses the

dependent claim limitations 3 and 14. Ex. 1003 at ¶¶ 186, 242.


Claims 4 and 15 require “wherein the short buffer status reporting format

corresponds to reporting a buffer status of a single radio bearer group and the

long buffer status reporting format corresponds to reporting a buffer status of

multiple radio bearer groups.” Malkamaki discloses a short buffer status report

that corresponds to a single radio bearer group that is 6 bits long (3 bits of priority

information and 3 bits of buffer status information.) Ex. 1012 at ¶ 60; Ex. 1003 at

¶¶ 187-88, 243-44. Malkamaki also discloses a long buffer status report that is 24-

bits long and contains buffer status information of 4 different buffers, each with a

different priority. Ex. 1012 at ¶ 60; Ex. 1003 at ¶ 188. Thus, Malkamaki discloses

the dependent limitation of claims 4 and 15. Ex. 1003 at ¶¶ 189, 244.


Claims 5 and 16 require “the designating designates the long buffer status

reporting format when multiple buffers for different radio bearer groups store data


43

beyond a pre-selected threshold” and “the memory and the computer program

code are further configured to, with the processor, cause the apparatus at least to

designate the long buffer status reporting format when multiple buffers for

different radio bearer groups store data beyond a pre-selected threshold”

respectively. Malkamaki discloses that the UE detects when data in the buffers

increases above some threshold. Ex. 1012 at ¶ 7; Ex. 1003 at ¶¶ 191-93. In one

described embodiment, the designating step designates the long buffer status

reporting format having 24-bits to report buffer status information of 4 different

priorities. Id. at ¶ 60; Ex. 1003 at ¶ 191. Thus, Malkamaki discloses the dependent

limitation of claims 5 and 16. Ex. 1003 at ¶¶ 194, 246.


Claims 6 and 17 require “designate[s] the short buffer status reporting

format when there is insufficient uplink bandwidth.” Malkamaki discloses

designating a short buffer status reporting format when there is insufficient uplink

bandwidth. Ex. 1003 at ¶¶ 195-196, 248. For example, Malkamaki discloses

sending the largest possible buffer status report depending on the amount of

available padding (or available space leftover after data has been added to the

uplink grant). Ex. 1012 at ¶ 22, 25; Ex. 1003 at ¶ 196. Thus, the short buffer

status format is designated when there is insufficient space for a larger buffer status


44

report size. Ex. 1012 at ¶¶ 25-26, 60; Ex. 1003 at ¶ 196. Thus, Malkamaki

discloses the dependent limitation of claims 6 and 17. Ex. 1003 at ¶¶ 196, 248.



comprises 1 byte of information and the long buffer status reporting format

comprises 3 bytes of information.” Malkamaki discloses that a short reporting

format can be 8 bits (1 byte). Ex. 1012 at ¶ 25. The size of the buffer status report

can vary depending on the information being reporting and the amount of padding

room. Ex. 1012 at ¶ 22; Ex. 1003 at ¶ 198. Malkamaki also discloses a long buffer

status report having 24 bits (3 bytes). Ex. 1012 at ¶ 60. Thus, Malkamaki

discloses the dependent limitation of claims 7 and 18. Ex. 1003 at ¶ 198.


Claims 9 and 20 require “wherein the long buffer status reporting format

comprises four segments of 6-bits of information, each segment corresponding to a

distinct radio bearer group.” Malkamaki explains that a 6-bit block can

communicate information about one priority. Ex. 1012 at ¶ 60; Ex. 1003 at ¶ 208.

The “UE could send buffer status for 4 different priorities,” a long buffer status

report with four segments of 6-bits of information, “if there were room for 24 bits

of in the transport block.” Ex. 1012 at ¶ 60; Ex. 1003 at ¶ 209. Thus, Malkamaki

discloses the dependent limitation of claims 9 and 20. Ex. 1003 at ¶ 210.


45

G. Claims 1-24 Are Rendered Obvious by Malkamaki

1. Malkamaki Renders Independent Claims 1, 12, 23 and 24 Obvious

Each independent claim requires “detecting one of a plurality of pre-selected

conditions corresponding to the plurality of buffers.” To the extent Patent Owner

may argue Malkamaki does not explicitly disclose this element, it would have been

obvious to include in the scheme of Malkamaki.

One of ordinary skill in the art at the time of the ’820 Patent would have

known that it was advantageous to detect more specific information about the data

buffers of a wireless communication device by using multiple thresholds to support

more accurate uplink scheduling. See Ex. 1011 at Fig. 2, Section 3.2.2; Ex. 1010

at Fig. 1; Ex. 1027 at Figs. 2-3, ¶ 34; Ex. 1003 at ¶ 163. Multiple references,

including Pederson and other references similarly disclosing threshold buffer status

reports (“the TBSR references”), published before the priority date of the ’820

patent disclose detection of various threshold conditions corresponding to a

plurality of buffers. Ex. 1003 at ¶ 162. For instance, the TBSR references each

show four priority classes, each with multiple data thresholds set to detect the

amount of data in priority buffers. Ex. 1011 at Fig. 2; Ex. 1010 at Fig. 1; Ex. 1027

at Fig. 2; Ex. 1003 at ¶ 162. As described in Pederson, “The FIG. 2 UL buffers

utilize three threshold values to define four regions in which the aggregate data

flow may fall, with each region identifiable by a two-bit value.” Ex. 1027 at ¶ 55.


46

As the TBSR references disclose detecting a plurality of thresholds relating to the

priority buffers, one of ordinary skill in the art would have known that multiple

data thresholds could be used to detect the amount of data in each buffer, and

would have been motivated to combine this technique with Malkamaki in order to

more accurately detect the amount of data in each buffer. Ex. 1003 at ¶ 163. Thus,

the detecting step of claims 1-24 would be obvious to a person of skill in the art in

view of Malkamaki. Ex. 1003 at ¶ 164.

2. Malkamaki Renders Claims 2 and 13 Obvious

Claims 2 and 13 require “wherein the buffer status reporting format

minimizes buffer status reporting overhead created by the communicating of the

buffer status report.” To the extent Patent Owner may argue Malkamaki does not

explicitly disclose this element, it would have been obvious to include in the

scheme of Malkamaki. Ex. 1003 at ¶ 181. As described above, the object of the

inventions of Malkamaki, the TBSR references and Ye are to reduce overhead with

efficient buffer status reporting schemes. Ex. 1003 at ¶ 181. Thus, claims 2 and

13 are obvious in light of Malkamaki. Ex. 1003 at ¶ 181.




pre-selected threshold.” To the extent Patent Owner may argue Malkamaki does


47

not explicitly disclose this element, it would have been obvious to include this

requirement in the scheme of Malkamaki. Ex. 1003 at ¶¶ 182-186; 241-242.

Malkamaki discloses detecting the condition that a buffer associated with a

radio bearer group has data beyond some threshold. Ex. 1012 at ¶¶ 7, 20; Ex.

1003 at ¶ 183. One of ordinary skill in the art at the time would have known that a

plurality of pre-selected thresholds could be used in the Malkamaki invention. Ex.

1003 at ¶ 184. For instance, the TBSR references show four priority classes, each

with multiple data thresholds set to detect the amount of data in the priority. Ex.

1011 at Fig. 2; Ex. 1010 at Fig. 1; Ex. 1027 at Fig. 2; Ex. 1003 at ¶ 184. One of

ordinary skill in the art would have known that the priorities disclosed correspond

to groupings of logical channels such as radio bearer groups (Ex. 1010 at Section

2; Ex. 1011 at Section 3.2.2; Ex. 1027 at ¶¶ 35, 55, 66) and that a data threshold

could be used to detect the amount of data in each buffer, and would have been

motivated to combine the technique with the Malkamaki invention in order to more

accurately detect the amount of data in each buffer. Ex. 1003 at ¶¶ 129, 184, 186.


Claims 5 and 16 require “the designating designates the long buffer status

reporting format when multiple buffers for different radio bearer groups store data

beyond a pre-selected threshold” and “the memory and the computer program

code are further configured to, with the processor, cause the apparatus at least to


48

designate the long buffer status reporting format when multiple buffers for

different radio bearer groups store data beyond a pre-selected threshold”

respectively. To the extent Patent Owner may argue Malkamaki does not

explicitly disclose this element, it would have been obvious to include this

requirement in the scheme of Malkamaki. Ex. 1003 at ¶ 190-194.

Malkamaki discloses that the UE detects when data in the buffers increases

above some threshold and that the designating step can designate the long buffer

status reporting format to report buffer status information of multiple priorities.

Ex. 1003 at ¶ 193. As disclosed in the TBSR references, one of ordinary skill in

the art would know that it is possible and desirable to detect and report in a buffer

status report when multiple buffers store data beyond a pre-selected threshold. Ex.

1011 at Fig. 2; Ex. 1010 at Fig. 1; Ex. 1027 at Fig. 2; Ex. 1003 at ¶ 193. For

instance, Pederson teaches that each buffer can utilize three thresholds to define

four regions of data flow in multiple buffers corresponding to different priorities or

groups of logical channels. Ex. 1027 at ¶¶ 35, 37, 55, 66; Ex. 1003 at ¶ 193.

Pedersen also discloses a buffer status report format that reports the level of four

buffers with data beyond a plurality of pre-selected thresholds. Ex. 1027. at 55,

59; see Ex. 1011 at Section 3.2.2; Ex. 1010 at Section 2; Ex. 1003 at ¶ 193. One of

ordinary skill in the art would be motivated to combine this aspect of the TBSR

references with the invention of Malkamaki so that the UE uses the long format


49

when a data is above a threshold in multiple traffic priority buffers. Ex. 1003 at ¶

193. Thus, the limitation of claims 5 and 16 would be obvious to a person of skill

in the art in view of Malkamaki. Ex. 1003 at ¶¶ 190-194, 245-246.



comprises 1 byte of information and the long buffer status reporting format

comprises 3 bytes of information.” To the extent Patent Owner may argue

Malkamaki does not explicitly disclose this element, it would have been obvious to

include this requirement in the scheme of Malkamaki.

A person of ordinary skill in the art would recognize that there are a variety

of possible formats and lengths of buffer status reports. See Ex. 1012 at ¶¶ 22, 24-

27, 29, 32, 60; Ex. 1003 at ¶ 200. For example, U.S. Patent No. 8,687,565 to Chun

et al. discloses a short buffer status reporting format of 1 byte of information and a

“normal” buffer status reporting format having 3 bytes of information. See Ex.

1021 at 9:9–27; Fig. 7; Ex. 1003 at ¶ 200. Similarly, the prior art Standards

Proposal R2-074682 (Ex. 1016) includes a 2 bit RBG identification and a 6 bit

long buffer size field for a total of 1 byte short buffer status report. Ex. 1003 at ¶

132, 200. In the case of the long buffer status report, Standards Proposal R2-

074682 discloses a buffer size field for each of the 4 radio bearer groups of 6 bits

for a total of 24 bits, or a 3 byte long buffer status report. Ex. 1016 at 2; Ex. 1003


50

at ¶ 200. A person of ordinary skill in the art would be motivated to use a short

status reporting format comprising 1 byte of information and a long status

reporting format comprising 3 bytes of information in order to convey various

amounts and types of information in the scheme of Malkamaki. Ex. 1003 at ¶ 200.

Thus, the limitation of claims 7 and 18 would be obvious to a person of skill in the

art in view of Malkamaki. Ex. 1003 at ¶¶ 199-201.


Claims 8 and 19 recite “wherein the short buffer status reporting format

comprises a 2-bit radio bearer group identifier and a 6-bit buffer size.” It would

be obvious to one of ordinary skill in the art to modify the invention of Malkamaki

to include this requirement. Ex. 1003 at ¶¶ 202-206, 251-252.

Malkamaki discloses and a person of ordinary skill in the art would

recognize that there are a variety of possible formats and lengths of buffer status

reports. See Ex. 1012 at ¶¶ 22, 24-27, 29, 32, 60; Ex. 1003 at ¶ 204. The length of

a buffer status report, in terms of a particular number of bits and/or bytes, is a

design choice and various lengths would have been obvious variations of known

buffer status reporting formats and within the level of ordinary skill in the art to

employ. See Ex. 1003 at ¶ 204. 3GPP Standards Proposal R2-074682 describes a

2-bit RBG identification and a 6-bit long buffer size field for a total of 1 byte short

buffer status report. Ex. 1016 at 2; Ex. 1003 at ¶ 204. One of skill in the art would


51

recognize this particular format as a possible short buffer status reporting format

for use in the Malkamaki invention. Ex. 1003 at ¶ 204. Thus, the limitation of

claims 8 and 19 would be obvious to a person of skill in the art in view of

Malkamaki. Ex. 1003 at ¶¶ 202-206, 251-252.


Claims 10 and 21 require “selecting a buffer status of a radio bearer group

of a highest priority.” It would have been obvious to modify the scheme of

Malkamaki to include this requirement.

Malkamaki discloses an embodiment in which one 6-bit buffer status report

can convey buffer status information of one buffer. Ex. 1012 at ¶ 60; Ex. 1003 at ¶

212. When less than 12 padding bits calculated to filled the transport block, the

UE can only convey one buffer status report on one buffer. Id. One of skill in the

art would understand that, when selecting one buffer of several to report in a single

buffer status report, it is only logical to select the highest priority buffer. Id. This

logic is evident from Malkamaki’s own disclosure providing for the filling of the

transport block with the highest priority data from the buffer first. Ex. 1012 at ¶

24; Ex. 1003 at ¶ 212. Thus, the dependent limitation of claims 10 and 21 would

have been obvious to a person of skill in the art in view of Malkamaki. Ex. 1003 at

¶¶ 211-217, 255-258.


52

Section 3.2.1 of Standards Proposal R2-073909 discloses a buffer status

report that has scheduling information, which carries information on total buffer

occupancy as well as “the amount of data available from the highest priority

logical channel.” Ex. 1011 at Section 3.2.1; Ex. 1003 at ¶ 214. The proposal

explains that it was assumed that this set of information, which conveyed how

much highest priority data comprises the total buffer status, was sufficient for the

base station scheduler. Ex. 1003 at ¶ 214. According to this scheme, the buffer

status reporting method always reports the buffer status of the highest priority

radio bearer group to report. Ex. 1003 at ¶ 214. One of skill in the art would

recognize it is important to convey information about the buffer status of the radio

bearer group of the highest priority. Ex. 1003 at ¶ 214. That is, by virtue of its

highest priority designation, the highest priority radio bearer group is also naturally

the highest priority for buffer status reporting. Ex. 1003 at ¶ 214. Thus, the

limitation of claims 10 and 21 would be obvious to a person of skill in the art in

view of Malkamaki. Ex. 1003 at ¶¶ 211-217, 255-258.

Further, the scheme of Sarkkinen provides for a specific frame structure that

can be used to communicate data and control information, such as a “user buffer

size” that informs a communication device how much data belongs to a flow or

buffer. Ex. 1030 at Abstract, Fig. 8; Ex. 1003 at ¶ 213. The scheme of Sarkkinen

discloses that this “user buffer size” may be used “in scheduling so that a data flow


53

which has the highest priority and most data in the RNC buffers gets access to the

HSDPA channel earlier than data flow which has a lower priority and a smaller

amount of data in the RNC buffers.” Ex. 1003 at ¶¶ 213 (citing Ex. 1030 at 24).

A person of skill in the art would be motivated to combine Malkamaki and

Sarkkinen because a person of skill would recognize that the techniques disclosed

in Sarkkinen are applicable to other systems, including 3G and LTE systems, to

make the transfer for information more efficient. Thus, Malkamaki in view of

Sarkkinen discloses the dependent limitation of claims 10 and 21. Id. at ¶ 213.


Claims 11 and 22 recite “wherein the radio bearer group of the highest

priority comprises a radio bearer group having a most amount of data in a radio

bearer group buffer.” It would have been obvious to modify the scheme of

Malkamaki to include this element. Ex. 1003 at ¶¶ 218-221, 257-258.

The scheme of Sarkkinen provides for a specific frame structure that can be

used to communicate data and control information, such as a “user buffer size” that

informs a communication device how much data belongs to a flow or buffer. Ex.

1030 at Abstract, Fig. 8. The scheme of Sarkkinen discloses that this “user buffer

size” may be used “in scheduling so that a data flow which has the highest priority

and most data in the RNC buffers gets access to the HSDPA channel earlier than


54

data flow which has a lower priority and a smaller amount of data in the RNC

buffers.” Ex. 1003 at ¶ 219 (citing Ex. 1030 at 24).

A person of skill in the art would be motivated to combine Malkamaki and

Sarkkinen references because a person of skill would recognize that the techniques

disclosed in Sarkkinen are applicable to other systems, including 3G and LTE

systems, to make the transfer for information more efficient. Thus, Malkamaki in

view of Sarkkinen discloses “wherein the radio bearer group of the highest

priority comprises a radio bearer group having a most amount of data in a radio

bearer group buffer” as required by claims 11 and 22. Id. at ¶ 220.

Further, as explained in the analysis for claim 10 above, Malkamaki and

other references disclose or render obvious having radio bearer groups of different

priorities. Ex. 1003 at ¶ 221. It would have been common sense for one of

ordinary skill in the art to choose the radio bearer group with the largest amount of

data as being the group with the highest priority. Ex. 1003 at ¶ 221. One

indication that a radio bearer group needs the most resources is if it requires the

most access to the resources. Ex. 1003 at ¶ 221. A radio bearer group with the

most amount of data in its buffer is an obvious candidate for a group that requires

the most amount of resources and therefore the group with highest priority. Ex.

1003 at ¶ 221. Moreover, there are only a few, well-known techniques for selecting

the highest priority radio bearer group, including amount of data in the buffer and


55

type of data to send. Ex. 1003 at ¶ 221. As explained with respect to claims 10

and 21 above, Malkamaki discloses and/or renders obvious that a UE may select to

report buffer status of the highest priority buffer. Ex. 1003 at ¶¶ 218-221, 257-258.

9. Claims 1-24 are Rendered Obvious by Malkamaki in View of Pedersen

Each independent claim requires “detecting one of a plurality of pre-selected

conditions corresponding to the plurality of buffers.” To the extent Patent Owner

may argue this claim element is not disclosed or obvious in view of Malkamaki, it

would have been obvious to one of ordinary skill in the art to combine Malkamaki

with Pedersen to meet this requirement. Ex. 1003 at ¶¶ 162-164. A skilled artisan

would have looked to both references when considering the goal of increasing

buffer status efficiency with fast and flexible uplink scheduling. Ex. 1003 at ¶¶

147, 164; Ex. 1012 at ¶ 8-9; Ex. 1027 at ¶¶ 33-34. A skilled artisan would be

motivated to combine these references for the reasons stated above (using multiple

thresholds of Pedersen to accurately detect the amount of data in buffers for the

variable-sized buffer status reports of Malkamaki (Ex. 1027 at 55, Fig. 2)), and

since both references are explicitly directed to solving the same problem of

reducing overhead and sending efficient buffer status reports in HSUPA networks.

Ex. 1003 at ¶¶ 147, 162-164.

10. Claims 1-24 are Rendered Obvious by Malkamaki in View of Ye


56

Each independent claim requires “wherein the designating designates the

long buffer status reporting format when there is sufficient uplink bandwidth to

communicate using the long buffer status reporting format.” To the extent Patent

Owner may argue this claim element is not disclosed or obvious in view of

Malkamaki, it would have been obvious to modify the scheme of Malkamaki to

designate the long buffer status reporting format when there is sufficient uplink

bandwidth in view of Ye. Ex. 1003 at ¶¶ 147, 174-175.

Ye discloses that the user equipment in his scheme may only communicate

buffer status information to the base station (i.e., in the uplink) as permitted by the

base station’s scheduling grant. Ex. 1003 at ¶ 175; Ex. 1005 at 1:40–44.

According to Ye, a base station can set a granularity level based on a “scheduling

grant [which] is an allocation by the base station to the UE of uplink bandwidth

resources.” Id. 5:56–58 (emphasis added). Any granularity level above 0 is a

determination by the base station that there is sufficient uplink bandwidth to permit

the UE to communicate a longer buffer status report. Id. 5:56–58; Ex. 1003 at ¶

175. That Ye discloses communicating a long buffer status format in the uplink

bandwidth shows that the long format has been designated “when there is sufficient

uplink bandwidth to communicate using the long buffer status reporting format.”

Ex. 1005 at 2:51–53; 7:41–43. A person of ordinary skill in the art would be

motivated to combine this aspect of Ye with the invention of Malkamaki because


57

both references are directed to achieving the same goal of reducing overhead to

achieve efficient uplink scheduling procedures by using buffer status reports with

varying size or granularity. Ex. 1003 at ¶¶ 147, 175; Ex. 1012 at ¶¶ 8-11; Ex. 1005

at Abstract, 2:15-54.

11. Malkamaki in View of Ye Renders Claims 3 and 14 Obvious



pre-selected threshold.” To the extent Patent Owner may argue claims 3 and 14

are not disclosed or obvious in view of Malkamaki, it would have been obvious to

modify the scheme of Malkamaki to include this requirement in view of Ye. Ex.

1003 at ¶¶ 182-186, 241-242.

As demonstrated above, Ye discloses that one of the pre-selected conditions

is the satisfaction bit sent by the UE to the base station. Ex. 1003 at ¶ 184; Ex.

1005 at 5:49–67. A person of ordinary skill in the art would understand that such a

satisfaction bit is a well-known technique in the art and also that multiple data

thresholds can be used to detect the amount of data in the buffers. Ex. 1011 at Fig.

2; Ex. 1010 at Fig. 1; Ex. 1027 at Fig. 2; Ex. 1003 at ¶ 184. The satisfaction bit

therefore reflects the condition that at least one buffer associated with a radio

bearer group stores data beyond a pre-selected threshold. Ex. 1005 at 5:49–67; Ex.

1003 at ¶¶ 137, 184. Ye therefore discloses this claim element. Ex. 1003 at ¶¶


58

182-186, 241-242. A person of ordinary skill in the art would be motivated to

combine these known techniques with the Malkamaki invention to detect more

accurate information about the amount of data in the buffer. Ex. 1003 at ¶ 185.

12. Malkamaki in View of Ye Renders Claims 10 and 21 Obvious

Claims 10 and 21 require “selecting[select] a buffer status of a radio bearer

group of a highest priority.” To the extent Patent Owner may argue claims 10 and

21 are not disclosed or obvious in view of Malkamaki, it would have been obvious

to modify the scheme of Malkamaki to include these requirements in view of Ye.

See Ex. 1003 at ¶¶ 211-217, 255-257.

Malkamaki discloses taking the opportunity, whenever there is room in the

transport block, to send additional information about the buffer status of a priority.

Ex. 1012 at ¶ 60; Ex. 1003 at ¶ 212. Ye discloses that the granularity level may be

assigned to individual groups of radio bearers which are grouped according to the

nature of the data being communicated. Ex. 1003 at ¶ 215. Specifically, Ye

provides the example of a UE grouping radio bearers into “real time” data

communication and “non real time” data communication, and discloses that the

“real time” radio bearers are selected for a higher granularity level so that the base

station may learn more about the buffer status associated with those radio bearers.

See Ex. 1003 at ¶ 215; Ex. 1005 at 8:33–9:8. The disclosure of that real time data

is selected to have a higher granularity level, and therefore a longer buffer status


59

reporting format, shows that the real time group is of higher priority and also that it

has been selected. Ex. 1003 at ¶ 215.

Moreover, a person of ordinary skill in the art would understand that “real

time” data is of higher priority than “non real time data” because real time data,

such as video streaming, is sensitive to delay. Ex. 1003 at ¶ 216. Such data loses

its value very quickly if not delivered immediately, in part because it loses its

meaning relative to the other data that is also being streamed at the same time. Ex.

1003 at ¶ 216. Non real-time data, such as web browsing data, can be delayed for

a relatively longer period of time before it loses its value and/or meaning. Ex.

1003 at ¶ 216; Ex. 1025 at 13. Therefore a person of ordinary skill in the art would

understand that “real time” data is of higher priority, due to its delay sensitivity.

Ex. 1003 at ¶ 216. Further, in the embodiments of Ye in which radio bearers are

only grouped into “real time” and “non-real time” groups, the real time radio

bearer group would necessarily be the highest priority. Ex. 1003 at ¶ 216. A

person of skill in the art would understand that high priority data is likely to be

sensitive to delay, and would be motivated to modify the invention of Malkamaki

with this aspect of Ye. Ex. 1003 at ¶ 216.

V. CONCLUSION

Petitioner respectfully requests that a Trial be instituted and that claims 1-24

be canceled as unpatentable.


60

Dated: January 20, 2015 Respectfully Submitted, /Joseph A. Micallef/ Joseph A. Micallef Registration No. 39,772 Sidley Austin LLP 1501 K Street NW Washington, DC 20005


PETITION FOR INTER PARTES REVIEW

OF U.S. PATENT NO. 8,055,820

Attachment A:

Proof of Service of the Petition


1

CERTIFICATE OF SERVICE

I hereby certify that on this 20th day of January 2015, a copy of this Petition,

including all attachments, appendices and exhibits, has been served in its entirety

by Federal Express on the following counsel of record for patent owner:

The correspondence address of record for the ’820 Patent:

Martin & Ferraro, LLP 1557 Lake O’Pines Street, NE Hartville, OH 44632

The Patent Owner: Cellular Communications Equipment LLC 2400 Dallas Parkway, Suite 200 Plano, TX 75093

The attorneys of record for Cellular Communications Equipment LLC in Civil Action No. 6:14-cv-31

Nelson Bumgardner Casto, P.C. 3131 West 7th Street, Suite 300 Fort Worth, TX 76107 Ward & Smith Law Firm PO Box 1231 1127 Judson Road, Suite 220 Longview, TX 75606 Dated: January 20, 2015 Respectfully submitted,

/Joseph A. Micallef/ Joseph A. Micallef Reg. No. 39,772 Attorney for Petitioner


PETITION FOR INTER PARTES REVIEW

OF U.S. PATENT NO. 8,055,820

Attachment B:

List of Evidence and Exhibits Relied Upon in Petition

1

Exhibit # Reference Name

1001 U.S. Patent No. 8,055,820

1002 File History of U.S. Patent No. 8,055,820

1003 Declaration of Thomas La Porta

1004 Curriculum Vitae of Thomas La Porta

1005 U.S. Patent No. 8,031,655 to Ye et al.

1006 Order of Dismissal, Case No. 6:14-cv-00031, Dkt. No. 14.

1007 Ye Provisional Application No. 60/848,641, filed October 3, 2006

1008 U.S. Patent No. 8,243,666 (“Torsner”)

1009 Standards Proposal R2-073352 entitled “Optimized Buffer Status Reporting,” August 20, 2007

1010 Standards Proposal R2-073909 entitled “Scheduling information for E-UTRAN uplink,” October 8, 2007

1011 Standards Proposal R2-060829 entitled "Buffer Reporting for E-UTRAN,” March 27, 2006.

1012 U.S. Patent App. Pub. No. 2006/014344 to Malkamaki, June 29, 2006

1013 Standards Proposal R2-074204 entitled “UE Buffer Status Reporting in E-UTRAN”

1014 Standards Proposal R2-071345 entitled “Enhancement to Buffer Status Reporting,” October 8, 2007

1015 3GPP TS 25.321, Release 6, v6.7.0 entitled “Medium Access Control (MAC) protocol specification”

1016 Standards Proposal R2-074682 entitled “Uplink Scheduling Information in E-UTRAN,” November 1, 2007.

1017 Standards Proposal R2-074265 entitled “Buffer Status Reporting,” October 8, 2007.

2


1018 U.S. Patent No. 7,769,926 to Wu

1019 U.S. Patent No. 8,000,272 to Gao et al.

1020 Standards Proposal R2-061915 entitled “Comparison of UL Buffer Reporting/Scheduling Schemes in LTE,” June 27, 2006

1021 U.S. Patent No. 8,687,565 to Chun et al.

1022 Vocabulary for 3GPP Specifications, 3GPP TR 21.905 v8.2.0, September 2007

1023 Plaintiff’s Response to Defendant’s Letter Brief, Case No. 6:13-cv-00507, Dkt. No. 283-1 (E.D. Tex. 2013)

1024 Plaintiff’s Opening Markman Brief, Case No. 6:13-cv-00507, Dkt. No. 277 (E.D. Tex. 2013)

1025 EP1599063 A1

1026 Webster’s Third New International Dictionary (3rd ed. 2002)

1027 U.S. Patent App. Pub. No. 2007/0201369 (“Pedersen”)

1028 Plaintiff’s Dec. 2, 2014 Response in Opposition to Defendants’ Motion for Summary Judgment of Invalidity For Indefiniteness

1029 Plaintiff’s October 30, 2014 First Supplemental Infringement Contentions, Ex. E

1030 WO Patent Publication No. 2003019960A1 to Sarkkinen et al., (“Sarkkinen”)

1031 Declaration of Brian Hickman (CT Corporation)

1032 Intentionally Omitted

1033 U.S. Patent Provisional Application 60/765,082 to Pederson

1034 3GPP_TSG_RAN_WG2 Exploder Archives Upload on Mar. 22, 2006

3


1035 3GPP_TSG_RAN List Serve Email Subscription Page to Receive Uploaded Proposals

1036 3GPP_TSG_RAN_WG2 Exploder Archives Upload on Oct. 2, 2004

1037 3GPP_TSG_RAN_WG2 Exploder Archives Upload on Oct. 30, 2007

Documents

Petition for Inter Partes Review of U.S. Patent No ...fishpostgrant.com/wp-content/uploads/js_composer/IPR2015-00578... · Petition for Inter Partes Review of U.S. Patent No. 8,055,820