Uniloc 2017 LLC

Patent Trials and Appeals Board

May 19, 2020

IPR2019-01283 (P.T.A.B. May. 19, 2020)

Trials@uspto.gov Paper 15
571-272-7822 Entered: May 19, 2020

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

APPLE, INC., BLACKBERRY CORP.,1
LG ELECTRONICS INC., SAMSUNG ELECTRONICS CO., LTD., and
SAMSUNG ELECTRONICS AMERICA, INC.
Petitioner,

v.

UNILOC 2017 LLC
Patent Owner.
____________

IPR2019-00252
Patent 7,167,487 B2
____________

Before JOSIAH C. COCKS, ROBERT J. WEINSCHENK, and
JOHN F. HORVATH, Administrative Patent Judges.

HORVATH, Administrative Patent Judge.

JUDGMENT
Final Written Decision
Determining All Challenged Claims Unpatentable
35 U.S.C. § 318(a)

1 BlackBerry Corp., who filed a petition in IPR2019-01283, has been joined
as a petitioner to this proceeding.
IPR2019-00252
Patent 7,167,487 B2

2
I. INTRODUCTION
A. Background
Apple Inc., LG Electronics Inc., Samsung Electronics Co., Ltd., and
Samsung Electronics America, Inc. (“Petitioner”)2,3 filed a Petition
requesting inter partes review of claims 11–13 (“the challenged claims”) of
U.S. Patent No. 7,167,487 B2 (Ex. 1001, “the ’487 patent”). Paper 5
(“Pet.”), 4. Uniloc 2017 LLC (“Patent Owner”), filed a Preliminary
Response. Paper 9. Upon consideration of the Petition and Preliminary
Response, we instituted inter partes review of all challenged claims on all
grounds raised. Paper 11 (“Dec. Inst.).
Patent Owner filed a Response to the Petition (Paper 14, “PO Resp.”),
Petitioner filed a Reply (Paper 16, “Pet. Reply”), and Patent Owner filed a
Sur-Reply (Paper 17, “PO Sur-Reply”). An oral hearing was held on March
3, 2020, and the hearing transcript is included in the record. See Paper 27
(“Tr.”).
We have jurisdiction under 35 U.S.C. § 6(b). This is a Final Written
Decision under 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73. For the reasons
set forth below, we find Petitioner has shown by a preponderance of
evidence that claims 11–13 of the ’487 patent are unpatentable.
B. Related Matters
Petitioner and Patent Owner identify various matters between Uniloc
USA, Inc. or Uniloc 2017 LLC, and Apple, Inc., Blackberry Corp., HTC

2 Petitioner identifies LG Electronics U.S.A., Inc. and LG Electronics
Mobilecomm U.S.A. Inc. as real parties-in-interest. See Pet. 72.
3 BlackBerry Corp., which has been joined as a party to this proceeding, is
also a Petitioner in this proceeding. See Paper 15.
IPR2019-00252
Patent 7,167,487 B2

3
America, Inc., Huawei Device USA, Inc., LG Electronics USA, Inc.,
Microsoft Corp., Motorola Mobility, LLC, Samsung Electronics America,
Inc., or ZTE (USA), in various Federal District Courts, including District
Courts for the Eastern, Western, and Northern Districts of Texas, the Central
and Northern Districts of California, the District of Delaware, and the
Western District of Washington, as matters that can affect or be affected by
this proceeding. See Pet. 72; Paper 7, 2.
C. Evidence Relied Upon4
References Effective Date
5 Exhibit
MAC protocol specification (Release 1999),
3rd Generation Partnership Project, 3GPP
TS 25.321 V3.6.0 (2000–12) (“TS 25.321”).
Dec. 10, 2000 1007
Corrections to logical channel priorities in
MAC protocol, 3rd Generation Partnership
Project, 3GPP TSG-RAN WG2 Meeting #18
(“R2-010182”).
Jan. 23, 2001 1008
Services provided by the physical layer
(Release 1999), 3rd Generation Partnership
Project, 3GPP TS 25.302 V3.6.0 (2000–09)
(“TS 25.302”).
Oct. 16, 2000 1009
Peisa US 6,850,540 B1 Feb. 25, 20006 1013

4 Petitioner also relies upon the Declarations of R. Michael Buehrer, Ph.D.,
FIEEE (Exs. 1002, 1019) and Craig Bishop (Exs. 1006, 1018).
5 Petitioner relies upon the Bishop Declaration to establish the public
availability of TS25.302, TS25.321, and R2-010182, and their respective
publication dates. See Pet. 9, 12, 16; Pet. Reply 1–16.
6 Petitioner relies on the U.S. filing date of Peisa to establish its availability
as prior art under 35 U.S.C. § 102(e). See Pet. 19.
IPR2019-00252
Patent 7,167,487 B2

4
D. Instituted Grounds of Unpatentability
We instituted review on the following grounds of unpatentability:
Claims
Challenged
35 U.S.C § Reference(s)/Basis
11–13 103(a) TS 25.321, TS 25.302, R2-010182
11–13 103(a) Peisa
II. ANALYSIS
A. The ’487 Patent
The ’487 patent “relates to a network with a first plurality of logic
channels with which is associated a second plurality of transport channels
. . . for the transmission of transport blocks formed from packet units of the
logic channels.” Ex. 1001, 1:4–8. According to the ’487 patent, “[s]uch a
network is known from the 3rd Generation Partnership Project (3GPP);
Technical Specification Group (TSG) RAN; Working Group 2 (WG2);
Radio Interface Protocol Architecture; TS 25.302 V3.6.0.” Id. at 1:9–12.
The ’487 patent describes the 3GPP network architecture disclosed in
TS 25.302 V3.6.0 as follows:
A physical layer offers transport channels or transport links to
the MAC [Media Access Control] layer. The MAC layer makes
logic channels or logic links available to an RLC layer
(RLC=Radio Link Control). The packet units formed in the
RLC layer are packed in transport blocks in the MAC layer,
which blocks are transmitted from the physical layer through
physical channels to a terminal, or the other way about, by the
radio network control. Apart from such a multiplex or
demultiplex function, the MAC layer also has the function of
selecting suitable transport format combinations (TFC). A
transport format combination represents a combination of
transport formats for each transport channel. The transport
format combination describes inter alia how the transport
IPR2019-00252
Patent 7,167,487 B2

5
channels are multiplexed into a physical channel in the physical
layer.
Id. at 1:14–28. This architecture is illustrated in in Figure 2 of the ’487
patent, which is reproduced below.

Figure 2 is a “layer model” illustrating the various functions of a terminal or
radio network controller in a 3GPP wireless network. Id. at 4:63–64, 6:9–
16. The “layer model” includes a physical layer (PHY), a data connection
layer (MAC and RLC), and a radio resource control layer (RRC). Id. at
6:16–19. The RRC layer is responsible for signaling between a wireless
terminal and a base station’s radio network controller (RNC), and “controls
the layers MAC and PHY via control lines 10 and 11.” Id. at 6:22–27. The
RLC layer receives data in the form of packet units from application
channels 14. Id. at 6:32–35. The MAC layer makes logic channels 13
IPR2019-00252
Patent 7,167,487 B2

6
available to the RLC layer. Id. at 6:30–32. The PHY layer makes transport
channels 12 available to the MAC layer. Id. at 6:29–30.
The MAC layer packs RLC layer packet units into transport blocks
that are transmitted from a base station’s radio network controller to a
mobile terminal, or vice versa, through a radio channel. Id. at 6:34–37. It
does so by selecting a suitable transport format combination from a set of
transport format combinations. Id. at 6:37–40. Each transport format
combination describes “how the transport channels are multiplexed into a
physical channel in the physical layer (time multiplex).” Id. at 6:42–45.
The MAC layer selection is performed by a selection algorithm that can be
implemented in hardware or software, and in a mobile station or radio
network controller. Id. at 7:43–47. The selection algorithm selects a
transport format combination based on MAC logic channel priorities
(MLPs), RLC layer data buffer occupancies (BOs), and transport channel
transmission time intervals (TTIs). Id. at 7:15–22.
The ’487 patent is directed toward “an optimized selection process for
selecting a suitable transport format combination.” Id. at 1:29–31. The
optimized selection process integrates into the MAC selection algorithm “the
condition that a minimum bit rate can be guaranteed suitable for the
respective logic channels.” Id. at 1:61–65.
B. Illustrative Claims
Claim 13 of the ’487 patent is an independent and representative
claim, and is reproduced below.
13. A method of controlling a network with a first
plurality of logic channels with which is associated a
second plurality of transport channels, which
transport channels are provided for transmitting
IPR2019-00252
Patent 7,167,487 B2

7
transport blocks formed from packet units of the
logic channels, wherein a plurality of valid transport
format combinations is allocated to the transport
channels, which combinations indicate the transport
blocks provided for transmission on each transport
channel, wherein a selection algorithm is provided
for selecting the transport format combinations, and
wherein the selection algorithm uses a minimum bit
rate criteria applicable to the respective logic
channel.
Ex. 1001, 16:54–65.
Claim 11 is an independent claim that recites a radio network
controller for a network having the properties of the network controlled in
claim 13. Compare id. at 16:26–40, with id. at 16:54–65. Claim 12 is an
independent claim that recites a terminal for a network having the properties
of the network controlled in claim 13. Compare id. at 16:41–53, with id. at
16:54–65.
C. Level of Ordinary Skill in the Art
The Petition itself does not set forth the qualifications of a person of
ordinary skill in the art, but instead cites to paragraphs 24 through 26 of the
Buehrer Declaration. See Pet. 15 n.3 (citing Ex. 1002 ¶¶ 24–26). According
to Dr. Buehrer, a person of ordinary skill in the art would have had “a
Bachelor’s Degree (or higher degree) in an academic area emphasizing
telecommunications systems with two or more years of work experience in
telecommunications systems” or “at least a Master of Science Degree in an
academic area emphasizing telecommunications systems, or an equivalent
field (or a similar technical Master’s Degree, or higher degree) with a
concentration in telecommunications systems.” Ex. 1002 ¶ 25. Patent
Owner does not dispute this definition or offer an alternative. See PO Resp.
IPR2019-00252
Patent 7,167,487 B2

8
14.
We find Dr. Buehrer’s opinion regarding the qualifications of a person
of ordinary skill in the art reasonably reflects the level of skill evidenced by
the prior art of record. See Okajima v. Bourdeau, 261 F.3d 1350, 1355 (Fed.
Cir. 2001). Accordingly, we adopt it as our own.
D. Claim Construction
In an inter partes review filed before November 13, 2018, claim terms
of an unexpired patent are given their broadest reasonable interpretation in
light of the specification of the patent in which they appear. 37 C.F.R.
§ 42.100(b) (2018); 83 Fed. Reg. 51,340. Under the broadest reasonable
interpretation standard, claim terms are generally given their ordinary and
customary meaning, as would be understood by one of ordinary skill in the
art, in the context of the entire disclosure. In re Translogic Tech., Inc., 504
F.3d 1249, 1257 (Fed. Cir. 2007). Only claim terms which are in
controversy need to be construed and only to the extent necessary to resolve
the controversy. See Nidec Motor Corp. v. Zhongshan Broad Ocean Motor
Co., 868 F.3d 1013, 1017 (Fed. Cir. 2017).
Neither Petitioner nor Patent Owner propose any construction for any
claim term. See Pet. 21–22; PO Resp. 15. Rather, both parties agree that no
claim term requires express construction, and that all terms should be
understood to have their broadest reasonable interpretation in light of the
specification. See Pet. 21–22; PO Resp. 15. We did not construe any claim
term in our Institution Decision, and neither party disputes that decision.
See Dec. Inst. 7–8; PO Resp. 15, Pet. Reply 1–26.
Accordingly, we construe all claim terms to have their plain and
ordinary meaning, and do not expressly construe any claim terms.
IPR2019-00252
Patent 7,167,487 B2

9
E. Public Availability of R2-010182
R2-010182 is a 3GPP change request entitled “Corrections to logical
channel priorities in MAC protocol,” and proposes a modification to
TS 25.321 affecting both the UE and RAN. Ex. 1008, 1, 4. Petitioner
argues R2-010182 is a printed publication that is prior art under 35 U.S.C.
§ 102(a) because it was “discussed during meeting #18 of the working group
(WG2) of 3GPP TSG RAN, held on January 15–19, 2001, and was publicly
available on the 3GPP file server no later than January 23, 2001.” Pet. 12
(citing Ex. 1006 §§ IV, VII).
According to Petitioner’s declarant, Mr. Bishop, R2-010182
(Ex. 1008) is a true and correct copy of a Microsoft Word document dated
January 16, 2001, that is contained in the compressed file R2-010182.zip
that was uploaded to the 3GPP FTP (File Transfer Protocol) server on
January 23, 2001. Ex. 1006 ¶ 35. Once the compressed file was uploaded,
R2-010182 was available to any member of the public because “[n]o
password is needed to access any information on the 3GPP Web site, all
information is openly published.” Id. ¶ 24 (quoting Appx. B, 7) (emphasis
omitted).7 Mr. Bishop further testifies that a version of R2-010182, differing
in editorial but not technical content, was emailed to over 1000 subscribers
of the 3GPP RAN WG2 email distribution list on January 11, 2001. Id.

7 Mr. Bishop identifies Appendix B as the 3GPP FAQ (Frequently Asked
Questions) web page. Ex. 1006 ¶ 23. Although Mr. Bishop cites page 8 of
the web page, the quoted material appears at the bottom of page 7. We
correct the citation here. We also note that Mr. Bishop alternates between
citing the pages of the Appendices to his declaration, as he does here, to
citing the pages of the declaration itself. For example, page 7 of Appendix
B is page 59 of the Bishop Declaration.
IPR2019-00252
Patent 7,167,487 B2

10
¶¶ 27–30, 39–40 (citing Appx. G).8 Once emailed, the technical content of
R2-010182 was “effectively in the public domain, since membership of the
exploder [i.e., email distribution list] is open to all and is (almost)
unpoliced.” Id. ¶¶ 29, 40 (quoting Appx. B, 8). Finally, Mr. Bishop testifies
that (a) meeting # 18 of 3GPP RAN WG2 was held in January 2001 and
attended by 95 people, (b) R2-010182 was discussed at the meeting, and that
(c) as a result, R2-010182 was disseminated to “RAN2 # 18 meeting
participants no later than the last day of the meeting which was January 19,
2001.” Id. ¶ 41 (citing Appx. H, 94–95).9 Mr. Bishop further testifies that it
was the customary practice of 3GPP to place no restrictions on how
“meeting participants dispose of the documents” presented at a meeting. Id.
¶ 40 (citing Appx. B, 4, 8).
Patent Owner argues Petitioner has failed to establish the public
accessibility of R2-010182 for several reasons. PO Resp. 16–20. First,
Patent Owner argues that Petitioner has failed to demonstrate “the 3GPP file
server is indexed or searchable in any meaningful way.” Id. at 17. Second,
Patent Owner argues that R2-010182 “could not have been disseminated at a
meeting held from January 15th to 19th,” as Petitioner contends, because
“[t]here is no evidence . . . that [R2-010182] was created prior to January 23,

8 Mr. Bishop identifies Appendix G as a true and correct copy of R2-0100xx,
a Microsoft Word document having the same technical content as R2-
010182 and contained in the compressed file R2-0100xx.zip that was
attached to an email sent to the 3GPP RAN WG2 email distribution list on
January 11, 2001. Ex. 1006 ¶ 39.
9 Mr. Bishop identifies Appendix H as “[t]he approved meeting report from
RAN WG2 [meeting] # 18,” and cites to the pages of his declaration rather
than to the pages of Appendix H itself. Ex. 1006 ¶ 41.
IPR2019-00252
Patent 7,167,487 B2

11
2001.” Id. at 18. Third, Patent Owner argues that any discussion of R2-
010182 at the January 2001 meeting is evidence of “what was ‘known . . . by
others . . . rather than what was described in a printed publication,” and
cannot be used as prior art in an inter partes review. Id. at 19. Fourth,
Patent Owner argues that Mr. Bishop does not have personal knowledge that
95 people attended the January 2001 meeting and provides no testimony
indicating how many people attended the session at which R2-010182 was
discussed. Id. Fifth, Patent Owner argues that Petitioner has failed to
produce any evidence that R2-010182 was actually “shown to anyone” at the
meeting or that anyone “accessed the document.” Id. Sixth, and finally,
Patent Owner argues that even if R2-010182 had been disseminated at the
January 2001 meeting, there is no evidence that anyone other than 3GPP
members accessed the document, and access by 3GPP members alone “does
not show accessibility of the type of skilled artisans interested in the subject
matter that qualify for public accessibility.” Id. at 20 (citing Samsung Elecs.
Co. v. Infobridge Pte, Ltd., 929 F.3d 1363, 1372 (Fed. Cir. 2019).
Petitioner, in its Reply, addresses each of Patent Owner’s objections
via some combination of Mr. Bishop’s original declaration (Ex. 1006), Mr.
Bishop’s supplemental declaration (Ex. 1018), and citations to public
accessibility case law. See Pet. Reply 1–16. For example, Petitioner
reiterates that R2-010182 was made publicly accessible because it was
discussed at the 3GPP TSG RAN WG2 meeting in January 2001. Id. at 1
(citing Ex. 1006 ¶ 41). Petitioner adds that 95 people attended this meeting,
including delegates from Mitsubishi, Qualcomm, Ericsson, and Philips, and
Mitsubishi’s delegate presented R2-010182 for discussion at the meeting.
Id. at 1–2 (citing Ex. 1006 ¶ 41; Ex. 1018 ¶¶ 15, 19, 20).
IPR2019-00252
Patent 7,167,487 B2

12
Patent Owner, in its Sur-Reply, argues any public accessibility
evidence or argument presented in Petitioner’s Reply should not be
considered because the Reply amounts to “16 pages of entirely new
arguments . . . and an additional over 100 pages of new Declaration and
documents.” PO Sur-Reply 2–3. Patent Owner argues the evidence and
arguments are new because “the terms ‘printed publication’ and ‘public
accessibility’ do not appear in the Petition” and “none of the Court of
Appeals case law relating to the standard of public accessibility . . . appears
in the Petition.” Id. at 5.
Whether a reference “qualifies as a ‘printed publication’ under § 102
is a legal conclusion based on underlying factual determinations.” Kyocera
Wireless Corp. v. Int’l Trade Comm’n, 545 F.3d 1340, 1350 (Fed. Cir.
2008). Public accessibility is “the touchstone in determining whether a
reference constitutes a ‘printed publication.’” In re Hall, 781 F.2d 897,
898–99 (Fed. Cir. 1986). It “is determined on a case-by-case basis, and
based on the ‘facts and circumstances surrounding the reference's disclosure
to members of the public.’” In re Lister, 583 F.3d 1307, 1311 (Fed. Cir.
2009) (quoting In re Klopfenstein, 380 F.3d 1345, 1350 (Fed. Cir. 2004)).
“[A] variety of factors may be useful in determining whether a reference was
publicly accessible.” Id. One such factor is whether a party intended to
make the reference public. See In re Wyer, 655 F.2d 221, 227 (CCPA 1981).
Other factors include the length of time the reference was displayed, the
expertise of the audience to which it was displayed, whether the displaying
party had a reasonable expectation that the reference would not be copied,
efforts made to prevent copying, and the ease or simplicity with which the
reference could have been copied. Klopfenstein, 380 F.3d at 1350–51.
IPR2019-00252
Patent 7,167,487 B2

13
“Evidence of routine business practice can be sufficient to prove that a
reference was made [publicly] accessible.” Constant v. Advanced Micro-
Devices, Inc., 848 F.2d 1560, 1568–69 (Fed. Cir. 1988).
Upon consideration of the evidence and arguments presented, we find
Petitioner has demonstrated by a preponderance of evidence that R2-010182
was publicly accessible. R2-010182 was presented at meeting #18 of 3GPP
RAN WG2, which was attended by ninety-five people, and was discussed at
that meeting. See Ex. 1006 ¶¶ 41–42 (citing Appx. H, 94–95). The
customary practice of 3GPP was to place no restrictions on how “meeting
participants dispose of the [meeting] documents,” and there is no evidence
that 3GPP diverged from that practice with respect to R2-010182. Id. ¶ 40
(citing Appx. B, 4, 8). Moreover, the 3GPP members who were present at
meeting # 18 and participated in the discussion of R2-010182 were
representatives of various commercial entities (e.g., Qualcomm, Ericsson,
and Philips) interested in the development of mobile communications, and
were skilled in the relevant art. Id. at 94–95 (Appx. H).10
Together, these facts lead us to conclude that Mitsubishi Electric, the
author of R2-010182, intended to and did distribute R2-010182 to skilled
artisans who were interested in its technical content, with no restrictions on
their ability to freely copy and distribute R2-010182.11 Thus, R2-010182

10 We cite to the underlying evidence in the Bishop declaration (i.e., to the
documents attached as Appendices to the Bishop declaration) by citing to the
pages of the Bishop declaration and parenthetically indicating the Appendix
to which the pages belong.
11 Indeed, just prior to meeting # 18, Mitsubishi emailed, without restriction,
a draft document having the same technical content as R2-010182 to over
1000 members of the 3GPP RAN WG2 distribution list, which was open to
IPR2019-00252
Patent 7,167,487 B2

14
was made publicly accessible by its disclosure at meeting # 18. See
Klopfenstein, 360 F.3d 1347, 1352 (finding a fourteen-slide presentation was
made publicly accessible when presented at a meeting of the American
Association of Cereal Chemists and printed onto poster boards that were
displayed without restriction for 2.5 days); see also Massachusetts Inst. of
Tech. v. AB Fortia, 774 F.2d 1104, 1108–09 (Fed. Cir. 1985) (“MIT”)
(finding a paper was made publicly accessible when it was presented to 50–
500 cell culturists at the First International Cell Culture Congress and
distributed without restriction to as many as six cell culturists).
We are not persuaded by Patent Owner’s numerous arguments that
Petitioner failed to demonstrate the public accessibility of R2-010182.12
First, the evidence shows that R2-010182 existed before meeting # 18 of
3GPP RAN WG2, and was discussed at that meeting. See Ex. 1006 ¶ 35
(Mr. Bishop’s testimony that the R2-010182.zip file “contain[s] a Microsoft

the public. Ex. 1006 ¶¶ 28–29, 39–40. This further evidences Mitsubishi’s
intent to disseminate the technical content of R2-010182 to the public. See
In re Wyer, 655 F.2d at 227 (finding “intent to make public” an aid in
determining whether a document is a printed publication). To be clear, we
do not rely on Mitsubishi’s email distribution as an independent basis for
finding that R2-010182 was publicly accessible. Rather, we rely on the
email distribution as further evidence of Mitsubishi’s intent to publicly
disseminate R2-010182 at meeting # 18.
12 We conclude that R2-010182 was made publicly accessible solely on the
theories and evidence presented in the Petition and Mr. Bishop’s first
declaration. Patent Owner acknowledged at the oral hearing that there is no
prejudice to Patent Owner if we rely only on the evidence submitted with the
Petition. Tr. 55:24–56:16. Thus, we do not address the merits of Patent
Owner’s argument regarding the propriety of Petitioner’s Reply and Mr.
Bishop’s second declaration.
IPR2019-00252
Patent 7,167,487 B2

15
Word document, ‘R2-010182.doc’, with a date stamp of ‘1/16/2001.’”); id.
at 94–95 (Appx. H) (official minutes of 3GPP RAN WG2 meeting # 18
indicating R2-010182 was discussed at that meeting). Second, the public
accessibility of R2-010182 does not depend on whether it was actually
distributed to or accessed by anyone at meeting # 18. Its presentation,
without restriction, to persons skilled in the art at the meeting is sufficient to
establish its public accessibility. See Klopfenstein, 380 F.3d at 1347 (finding
a document presented at a meeting was publicly accessible even though “no
copies of the presentation were disseminated.”); see also Constant, 848 F.2d
at 1569 (“If accessibility is proved, there is no requirement to show that
particular members of the public actually received the information.”). Third,
Mr. Bishop’s personal knowledge is not needed to prove R2-010182 was
presented at meeting # 18. The documentary evidence cited by Petitioner
and generated as part of 3GPP’s routine business practice is uncontested and
demonstrates that R2-010182 was presented at the meeting. See Constant
848 F.2d at 1568–69 (“Evidence of routine business practice can be
sufficient to prove that a reference was made [publicly] accessible.”).
Lastly, we are not persuaded by Patent Owner’s argument that
Mitsubishi’s disclosure of R2-010182 to “other members of 3GPP who
attended the meeting does not show accessibility by the type of skilled
artisans interest in the subject matter that qualify for public accessibility.”
PO Resp. 20. As discussed above, Mitsubishi disclosed R2-010182, without
restriction, to 3GPP members who were employees and representatives of
various commercial entities that competed with Mitsubishi in the mobile
communications market, including representatives from Qualcomm,
Ericsson, and Philips. See Ex. 1006, 94–95 (Appx. H). The disclosure of a
IPR2019-00252
Patent 7,167,487 B2

16
document to interested members of the relevant public, without restriction
on the subsequent dissemination of the document, is sufficient to establish
the public accessibility of the document, even when the disclosure is made in
a private setting. See, e.g., GoPro, Inc. v. Contour IP Holding LLC, 908
F.3d 690, 695 (Fed. Cir, 2018) (finding dissemination of a document to trade
show attendees who were interested in the art, without restriction, made the
document publicly accessible even though the trade show was not open to
the public); see also Klopfenstein, 360 F.3d at 1347, 1352 (finding the
unrestricted disclosure of a document at a meeting of the American
Association of Cereal Chemists made the document publicly accessible); see
also Garret Corp. v. U.S., 422 F.2d 874, 865 (Ct. Cl. 1970) (finding that
although distribution of a government report “to government agencies and
personnel alone may not constitute publication . . . distribution to
commercial companies without restriction on use clearly does.”) (emphasis
added).13
We disagree with Patent Owner’s argument that Infobridge stands for
the opposite proposition, i.e., that the unrestricted disclosure of R2-010182
to members of 3GPP does not evidence a public disclosure. The facts
presented in Infobridge are readily distinguishable from the facts presented
here. First, the Infobridge petitioner did not argue, and in fact waived any
argument, that a contested “reference was publicly accessible because it was
discussed at a [first] meeting or disseminated at [a second] meeting” of a

13 The Federal Circuit has adopted “the holdings of the Court of Claims and
the Court of Customs and Patent Appeals announced before the close of
business on September 30, 1982.” South Corp. v. U.S., 690 F.2d 1368, 1370
(Fed. Cir. 1982) (en banc).
IPR2019-00252
Patent 7,167,487 B2

17
standardization body. Infobridge, 929 F.3d at 1370. By contrast, Petitioner
argues that R2-010182 was made publicly accessible because it was
discussed at a standardization body meeting, i.e., at meeting # 18 of 3GPP
RAN WG2. See Pet. 12. Second, the Infobridge petitioner could not have
shown that presenting the contested document at a standardization group
meeting made the document publicly accessible prior art because the
evidence showed the contested document “was not created until after the
[first] meeting” and any disclosure at the second meeting “occurred after the
relevant critical date.” Infobridge, 929 F.3d at 1370. By contrast, the
evidence presented by Petitioner sufficiently demonstrates that R2-010182
was created on January 16, 2001, which is before the January 17, 2001 start
date of the portion of meeting # 18 dedicated to non-release 4 contributions,
and that R2-010182 was discussed at meeting #18 sometime between
January 17 and 19, 2001, which is before the critical date of May 21, 2001.14
See Ex. 1006 ¶¶ 35, 41 (citing Appx. H, 94–95).
For the reasons discussed above, we find Petitioner has demonstrated
by a preponderance of evidence that R2-010182 is prior art under 35 U.S.C.
§ 102(a) because it was disclosed without restriction at meeting # 18 of
3GPP RAN WG2 in January 2001 and discussed at that meeting by
interested representatives of competing commercial companies. Moreover,
because we find this disclosure sufficiently demonstrates the public

14 Meeting # 18 of 3GPP TSG RAN WG2 was held between January 15 and
19, 2001. Ex. 1006, 66 (Appx. D). However, “[d]uring the 15th and 16th
January 2001 only Release 4 contributions” were discussed at the meeting.
Id. R2-010182 is dated January 17–19, 2001, i.e., for discussion during the
non-release 4 portion of meeting # 18. Ex. 1008, 1.
IPR2019-00252
Patent 7,167,487 B2

18
accessibility of R2-010182, we need not consider whether the subsequent
uploading of R2-010182 to the 3GPP FTP server on January 23, 2001, also
made the document publicly accessible. See Beloit Corp. v. Valmet Oy, 742
F.2d 1421, 1423 (Fed. Cir. 1984) (finding an administrative agency is at
liberty to reach a decision based on a single dispositive issue).
F. The TS25.321, R2-010182, and TS25.302 challenge
Petitioner argues claims 11–13 are unpatentable as obvious over the
combination of TS 25.321, R2-010182, and TS 25.302. Pet. 22–45; Pet.
Reply 16–21. Patent Owner disputes this. PO Resp. 20–23; PO Sur-Reply
11–16. For the reasons discussed below, Petitioner demonstrates by a
preponderance of evidence that claims 11–13 are unpatentable over
TS 25.321, R2-010182, and TS 25.302.
1. TS 25.321
TS 25.321 is a specification of the UMTS (Universal Mobile
Telephone System) MAC layer protocol. Ex. 1007, 6. The specification
describes, inter alia, the architecture, channel structure, functions, protocol
data units (PDUs), formats, and parameters of the MAC layer. Id. The
channel structure includes transport channels between the MAC layer and
Layer 1 (e.g., Forward Access Channel or FACH), and logical channels
between the MAC and RLC layers (e.g., Broadcast Control Channel or
BCCH). Id. at 15–16. The MAC layer functions to map logical channels to
transport channels, select transport formats for each transport channel,
handle data flow priorities, and multiplex PDUs from higher protocol layers
into transport blocks delivered to physical layer transport channels (and
vice-versa). Id. at 17–18.
IPR2019-00252
Patent 7,167,487 B2

19
A mobile terminal or user equipment (UE) MAC architecture is
illustrated in Figure 4.2.3.1.1 of TS 25.321, which is reproduced below.

Figure 4.2.3.1.1 of TS 25.321 is a schematic illustration of the MAC layer
on the UE side of the network. Id. at 11. The figure illustrates the mapping
of logical channels (e.g., BCCH) to transport channels (e.g., FACH), which
“depends on the multiplexing that is configured by RRC.” Id. at 9. In
particular, RRC maps logical channels to transport channels by generating a
set of transport format combinations (TFCs), and the MAC layer selects one
of these TFCs to fit PDUs from the RLC layer into available transport blocks
on the transport channels. Id. at 9–10.
TS 25.321 discloses another function of the MAC layer—handling
different priorities for different UE data flows. Id. at 17. In particular, the
RRC assigns a priority value—MLP or MAC Logical channel Priority—
between 1 and 8 for each logical channel, and the MAC layer selects a TFC
“according to the priorities between logical channels indicated by RRC.” Id.
IPR2019-00252
Patent 7,167,487 B2

20
at 30, 38. The logical channel priorities are absolute, allowing the MAC to
“maximize the transmission of high priority data.” Id.
In addition to disclosing the UE MAC layer architecture and
functionality, TS 25.321 discloses the RNC (Radio Network Controller)
MAC layer architecture and functionality, which exists on the UTRAN
(UMTS Terrestrial Radio Access Network) side of the network. See id. at
12–15. The RNC MAC layer architecture and functionality is “similar to the
UE case with the exception that there will be one MAC-d for each UE and
each UE (MAC-d) that is associated with a particular cell may be associated
with that cell’s MAC-c/sh.” Id. at 12. Moreover, the “MAC-c/sh is located
in the controlling RNC while MAC-d is located in the serving RNC.” Id.
2. R2-010182
R2-010182 is a change request, entitled “Corrections to logical
channel priorities in MAC protocol,” that proposes a modification to TS
25.321 affecting both the UE and RAN. Ex. 1008, 1, 4. R2-010182
introduces “new parameters to characterise MAC logical channels for TFC
selection,” and modifies the TFC selection algorithm “to take into account
these new parameters.” Id. The new parameters, i.e., MinGBr, MaxBr, and
TW “complete the current MLP for representing logical channel priorities.”
Id. at 1.
R2-010182 identified several problems with “the current algorithm
proposed for TFC selection in MAC . . . because of its absolute priority
scheme.” Id. One problem was that the absolute priority algorithm provided
“only one way to represent the quality of service at logical channel level
(MLP),” which was “not sufficient to characterise all the applications
foreseen for UMTS.” Id. Another problem was that the absolute priority
IPR2019-00252
Patent 7,167,487 B2

21
algorithm systematically prevented low priority logical channels from
transmitting data because “[l]ogical channels of higher MLP [lower priority]
can never preempt lower MLP [higher priority] logical channels.” Id. at 2.
R2-010182 proposed introducing three “new parameters completing
MLP to express accurately the needs of different applications in term[s] of
bit rate.” Id. The new parameters are “TW” representing “the time period
on which the allocated bit rate for the logical channel is estimated” based on
a number of previous TTI (transmission time intervals); “MinGBr”
representing the minimum guaranteed bit rate or “basic needs of the logical
channel,” and “MaxBr” representing the maximum bit rate or “nominal
needs of the logical channel.” Id.
R2-010182 assigns separate values to the MLP, TW, MinGBr, and
MaxBr parameters to characterize each of the logical channels in the
proposed TFC selection algorithm. Id. This is shown in the table provided
on page 2 of R2-010182, which is reproduced below.

The Table shows how separate values of MLP, TW, MinGBr, and MaxBr
are assigned to logical channels LC1 and LC2. Id. In particular, logical
channel LC1 is assigned a priority (MLP) of 1, a minimum guaranteed bit
rate (MinGBr) of 100 bits/TW measured over a time window (TW) of 3 TTI,
and a maximum bit rate (MaxBr) of 200 bits/TW measured over the 3 TTI
IPR2019-00252
Patent 7,167,487 B2

22
time window. Id. It also shows that logical channel LC2 is assigned a
priority (MLP) of 2, a minimum guaranteed bit rate (MinGBr) of 100
bits/TW measured over a time window (TW) of 4 TTI, and a maximum bit
rate (MaxBr) of 200 bits/TW measured over the 4 TTI time window. Id.
The proposed algorithm tries “to reach the MinGBr for each logical
channel in . . . descending order of priority,” and upon achieving that goal
tries “to reach the MaxBr for each logical channel in . . . descending order of
priority,” and upon achieving that goal tries “to serve the logical channels
which still have remaining data (best effort), still in . . . descending order of
priority.” Id.
3. TS 25.302
TS 25.302 is “a technical specification of the services provided by the
physical layer of UTRA [UMTS Terrestrial Radio Access] to upper layers.”
Ex. 1009, 7. TS 25.302 discloses that “[t]he physical layer offers data
transport services to higher layers . . . . through the use of transport channels
via the MAC sub-layer.” Id. at 10. The physical layer operates “according
to the L1 radio frame timing,” and the transport blocks or “the data accepted
by the physical layer to be jointly encoded . . . . is then tied exactly to this L1
frame timing.” Id.
TS 25.302 discloses that transport blocks are transmitted as transport
block sets “exchanged between L1 and MAC at the same time instance using
the same transport channel.” Id. at 17. Transport block sets are “transferred
by the physical layer on the radio interface” over a transmission time
interval (TTI) “defined as the inter-arrival time of Transport Block Sets” that
is “always a multiple of the minimum interleaving period (e.g., 10ms, the
IPR2019-00252
Patent 7,167,487 B2

23
length of one Radio Frame).” Id. This is illustrated in Figure 6 of TS
25.302, which is reproduced below.

Figure 6 of TS 25.302 is a schematic illustration of “an example where
Transport Block Sets, at certain time instances, are exchanged between
MAC and L1 via three parallel transport channels [DCH1–DCH3].” Id.
“Each Transport Block Set consists of a number of Transport Blocks,”
transmitted over a transmission time interval (TTI), which is “the time
between consecutive deliveries of data between MAC and L1.” Id.
TS 25.302 defines a transport format as “a format offered by L1 to
MAC (and vice versa) for the delivery of a Transport Block Set during a
Transmission Time Interval on a Transport Channel.” Id. at 18. TS 25.302
also defines a number of terms that are used to explain how the MAC layer
selects a Transport Format to deliver a Transport Block Set on a Transport
Channel. First, a Transport Format set “is defined as the set of Transport
IPR2019-00252
Patent 7,167,487 B2

24
Formats associated to a Transport Channel.” Id. Next, a Transport Format
Combination is defined as “an authorised combination of the combination of
currently valid Transport Formats that can be submitted simultaneously to
the layer 1 for transmission on a Coded Composite Transport Channel.” Id.
at 19. Lastly, a transport format combination set “is defined as a set of
Transport Format Combinations on a Coded Composite Transport Channel.”
Id. TS 25.302 discloses:
The Transport Format Combination Set is what is given to
MAC for control. However, the assignment of the Transport
Format Combination Set is done by L3. When mapping data
onto L1, MAC chooses between the different Transport Format
Combinations given in the Transport Format Combination Set.
Id.
4. The TS 25.321, TS 25.302, and R2-010182 combination
Petitioner argues a person of ordinary skill in the art would have
combined the teachings of TS 25.302 and TS 25.321 because they “describe
features and functions of adjacent layers of the UMTS network
architecture—TS25.321 describes the MAC protocol specification while
TS25.302 describes the services provided by the physical layer, which is
below the MAC layer and provides services to the MAC layer.” Pet. 17
(citing Ex. 1002 ¶ 92). Petitioner further argues that “TS25.321 relies on
several features corresponding to the physical layer, such as transport
channels, transport format, and TFCs, which are defined in TS25.302,” and
that TS 25.321 cites to TS 25.302 for “provisions which, through reference
in [TS 25.321] text, constitute provisions of the present [TS25.321]”
document. Id. at 17–19 (quoting Ex. 1007 § 2) (alteration in original).
Relying on the testimony of Dr. Buehrer, Petitioner argues that a person of
IPR2019-00252
Patent 7,167,487 B2

25
ordinary skill in the art, looking “to fully understand the specification of the
MAC layer protocol in TS25.321, or to obtain a comprehensive view of the
UMTS network, or both” would have “look[ed] at the two references
together, combining their teachings” because “they are complementary
technical specifications directed towards adjacent layers of the same UMTS
protocol stack.” Id. at 18 (citing Ex. 1002 ¶¶ 101, 103).
Petitioner further argues that a person of ordinary skill in the art
would have combined TS 25.321 and R2-010182 because the latter
“explicitly notes that it is a change request (CR) for TS25.321,” and “copies
verbatim § 11.4 of TS 25.321, marking the TFC selection algorithm in that
section to show changes proposed by R2-010182.” Id. at 15 (citing
Ex. 1008, 4–5). Relying on the testimony of Dr. Buehrer, Petitioner argues
that a person of ordinary skill in the art “with knowledge of TS25.321 and
considering possible limitations to its contents, such as the TFC selection
algorithm, would have looked to routine 3GPP contributions (and change
requests) like R2-010182,” and “would have understood that R2-010182
applies directly to TS25.321, and suggests improvements ‘to solve the
problems encountered in the absolute priority scheme’ of TS25.321’s TFC
selection algorithm.” Id. at 15–16 (citing Ex. 1002 ¶¶ 86–87).
Patent Owner does not dispute Petitioner’s reasoning to combine the
teachings of TS 25.321, TS 25.302, and R2-010182. See PO Resp. 2–27.
We find Petitioner has articulated sufficient reasoning with rational
underpinning to combine the teachings of TS 25.321, TS 25.302, and R2-
010182 in the manner proposed. TS 25.321 and TS 25.302 are technical
specifications for the MAC and PHY layers of the UMTS protocol,
respectively, which are adjacent layers of the UMTS protocol stack designed
IPR2019-00252
Patent 7,167,487 B2

26
to interoperate and pass data between them. Ex. 1002 ¶¶ 92–93. R2-010182
is a change request for TS 25.321 that proposes a specific change to the TFC
selection algorithm described in TS 25.321. Ex. 1008, 4–5.
5. Claim 13
Claim 13 recites a method of controlling a network with a first
plurality of logic channels associated with a second plurality of transport
channels. Ex. 1001, 16:54–56. Petitioner demonstrates how TS 25.321
teaches this limitation. Pet. 23–29 (citing/quoting Ex. 1007 §§ 3.2–6.1,
Figs. 4.2.3.1–4.2.4.2.1; Ex. 1002 ¶¶ 182–187). TS 25.321 is a technical
specification for a Radio Access Network’s MAC layer, and describes the
functions of the MAC layer on either side of the radio network (i.e., UE and
RNC). Ex. 1007 §§ 3.2–4.2.4. The UE MAC layer controls “access to . . .
transport channels,” “mapping between logical and transport channels,”
“scheduling / priority handling . . . based on logical channel priorities,” and
“transport format and transport format combination selection according to
[a] transport format combination set.” Id. §§ 4.2.3–4.2.3.2, Figs. 4.2.3.1.1,
4.2.3.2.1. Likewise, the RNC MAC controls “Scheduling – Priority
handling,” “mapping between logical and transport channels,” and “TFC
selection [] in the downlink.” Id. §§ 4.2.4.1, 4.2.4.2, Figs. 4.2.4.1.1,
4.2.4.2.1.
Petitioner further demonstrates, through an annotated version of
Figure 4.2.3.1 that is reproduced below, how TS 25.321 teaches the MAC
layer maps logical channels to transport channels.
IPR2019-00252
Patent 7,167,487 B2

27

The Figure is a Petitioner-annotated version of Figure 4.2.3.1 shown in
section 4.2.3 of TS 25.321. Pet. 25. TS 25.321 discloses how various
logical channels (e.g., PCCH (paging control channel) CCCH (common
control channel), and DCCH (dedicated control channel)) are mapped to
various transport channels (e.g., RACH (random access channel), FACH
(forward access channel), and PCH (paging channel)). Ex. 1007 §§ 4.3.1–
4.3.3. Patent Owner does not dispute Petitioner’s contentions regarding this
claim limitation. See PO Resp. 16–23.
Claim 13 further recites the transport channels are provided for
transmitting blocks formed from packet units of logic channels. Ex. 1001,
16:56–58. Petitioner demonstrates how TS 25.321 teaches this limitation.
See Pet. 29–30 (citing Ex. 1007 § 3.2–6.1; Ex. 1002 ¶ 189). TS 25.321
teaches transport channels are defined between the MAC and PHY layers,
IPR2019-00252
Patent 7,167,487 B2

28
logical channels are defined between the MAC and RLC layers, and the
RLC layer “provides RLC-PDUs to the MAC, which fit into the available
transport blocks on the transport channels.” Ex. 1007 §§ 4.2.3.1, 4.3.
TS 25.321 further teaches the MAC layer is responsible for “multiplexing/
demultiplexing higher layer PDUs into/from transport blocks delivered
to/from the physical layer.” Id. § 6.1. According to the unrebutted
testimony of Dr. Buehrer, a person skilled in the art would have understand
PDUs or Protocol Data Units to be “packet units of higher layers.” Ex. 1002
¶ 189. Patent Owner does not dispute Petitioner’s contentions regarding this
claim limitation. See PO Resp. 16–23.
Claim 13 further recites a plurality of valid transport format
combinations allocated to the transport channels that indicate the transport
blocks provided for transmission on each transport channel. Ex. 1001,
16:58–61. Petitioner demonstrates how TS 25.302 teaches this limitation by
defining several of the terms used in a manner that expresses the recited
relationships (e.g., that a transport format combination indicates the
transport blocks provided for transmission on a transport channel). See Pet.
31–33 (citing/quoting Ex. 1009 §§ 7.1.2–7.1.9, Fig. 6; Ex. 1002 ¶¶ 199–
201). For example, TS 25.302 defines a Transport Format Combination Set
as “a set of Transport Format Combinations on a Coded Composite
Transport Channel,” where a Transport Format Combination is “a list of
transport formats (Transport Format Set) which are applicable” to the
Transport Channel. Ex. 1009 §§ 7.1.8, 7.1.9. TS 25.302 defines a Transport
Format as a format “for the delivery of a Transport Block Set during a
Transmission Time Interval on a Transport Channel” having dynamic
IPR2019-00252
Patent 7,167,487 B2

29
attributes that include Transport Block Size15 and Transport Block Set
Size.16 Id. § 7.1.6. TS 25.302 defines a Transport Block Set as “a set of
Transport Blocks, which are exchanged between L117 and MAC at the same
time instance using the same transport channel.” Id. § 7.1.2. Thus,
TS 25.302 discloses that a transport format combination includes a list of
transport formats, where each transport format includes a set of transport
blocks that are provided to transmit data over a transport channel.
Moreover, TS 25.302 teaches that only valid transport format
combinations are allocated to transport channels because “a Transport
Format Combination Set need not contain all possible Transport Format
Combinations that can be formed by Transport Format Sets of the
corresponding Transport Channels. It is only the allowed combinations that
are included,” where the allowed combinations contain only “Transport
Formats . . . [that] do not correspond to high bit rates simultaneously.” Id.
§ 7.1.9.
Petitioner’s annotation of Figure 6 of TS 25.302, which is reproduced
below, illustrates the meaning of some of these terms.

15 The Transport Block Size is “the number of bits in a Transport Block,”
and is “fixed within a given Transport Block Set.” Ex. 1009 § 7.1.3.
16 The Transport Block Set Size is “the number of bits in a Transport Block
Set.” Ex. 1009 § 7.1.4.
17 L1 refers to the physical or PHY protocol layer. See Ex. 1009 § 3.2.
IPR2019-00252
Patent 7,167,487 B2

30

The Figure is a Petitioner-annotated version of Figure 6 of TS 25.302. See
Pet. 33. Annotated Figure 6 illustrates the transmission of different
Transport Block Sets on different Transport Channels (DCH1–DCH3)
during different transmission time intervals (TTIs). Ex. 1009 § 7.1.5. The
Transport Block Sets that are shown differ in the number of transport blocks
they contain, the length or size of the transport blocks they contain, and the
number of TTIs over which they are transmitted. Patent Owner does not
dispute Petitioner’s contentions regarding this claim limitation. See PO
Resp. 16–23.
Claim 13 further recites a selection algorithm for selecting the
transport format combinations. Ex. 1001, 16:61–63. Petitioner
demonstrates how TS 25.321 teaches this limitation. See Pet. 34–36
(citing/quoting Ex. 1007 § 4.2.3.1, 11.4; Ex. 1002 ¶¶ 183–184, 204–206).
TS 25.321 teaches the MAC layer performs “transport format and transport
format combination selection according to the transport format combination
IPR2019-00252
Patent 7,167,487 B2

31
set . . . configured by [the] RRC [layer].” Ex. 1007 § 4.2.3.1. TS 25.321
teaches each logical channel is assigned a priority value between 1 and 8 and
“[t]he selection of TFC in the UE shall be done according to the priorities
between logical channels indicated by RRC. Logical channels have absolute
priority i.e. the UE shall maximize the transmission of high priority data.”
Id. § 11.4. Patent Owner does not dispute Petitioner’s contentions regarding
this claim limitation. See PO Resp. 16–23.
Lastly, claim 13 recites the selection algorithm uses a minimum bit
rate criteria applicable to the respective logic channel. Ex. 1001, 16:63–65.
The parties dispute whether this limitation is met. See Pet. 37–40; Pet.
Reply 16–21; PO Resp. 20–23; PO Sur-Reply 11–16. Petitioner argues the
limitation is met because R2-010182 proposes a modification to the TFC
selection algorithm described in § 11.4 of TS 25.321 by adding “new
parameters . . . for MAC TFC selection,” including a minimum guaranteed
bit rate (MinGBr) parameter. Pet. 37 (quoting Ex. 1008, 1, 5) (emphasis
omitted). Petitioner argues MinGBr is the “minimum bit rate criteria” of
claim 1 because it is integrated into the TFC selection algorithm and
represents “the basic [(e.g., minimum)] needs of the logical channel,” which
is consistent with the ’487 patent’s teaching of “integrating into the selection
algorithm[] the condition that a minimum bit rate can be guaranteed suitable
for the respective logical channels.” Id. at 38–39 (quoting Ex. 1001, 1:61–
65; Ex. 1008, 2) (emphasis omitted) (alteration in original).
Patent Owner argues the limitation is not met because the “minimum
bit rate criteria” of claim 13 is a relative parameter that must be “applicable
to the respective logical channel” and “must pertain specifically to that
channel.” PO Resp. 21 (emphasis omitted). By contrast, Patent Owner
IPR2019-00252
Patent 7,167,487 B2

32
argues, “MinGBr [is] a global rate criteria applicable to all logic channels”
because it describes “the basic needs of the logical channel” and the amount
of data that will be “transmitted with an absolute priority scheme.” Id. at 22
(quoting Ex. 1008, 2). Patent Owner further argues that the TFC selection
algorithm in R2-010182 performs a single step for each logical channel,
“and that step is to ‘try to reach the MinGBr,’” which is a single parameter
“without any indication that it depends on the channel being considered.”
Id. at 23. Patent Owner argues the Table on page 2 of R2-010182, which
shows “the same value for MinGBr and MaxBr for both [logical] channels”
LC1 and LC2, confirms that MinGBR is a global parameter. Id. This is
evident from the Table, Patent Owner argues, because logical channels LC1
and LC2 can have different values for other parameters, such as MLP and
TW. See PO Sur-Reply 13.
Petitioner counters that a person skilled in the art would have
understood that R2-010182 “teaches that each logical channel has its own
MinGBr parameter,” i.e., that R2-010182 modifies the TFC selection
algorithm described in TS 25.321 to use a MinGBr “applicable to the
respective logical channel” as required by claim 13. Pet. Reply 17 (citing
Ex. 1002 ¶ 135). This is so, Petitioner argues, because MinGBr, MaxBr, and
TW are introduced to “complete the current MLP [absolute priority scheme]
for representing Logical channel[] priorities,” and TS 25.321 teaches
assigning MLP on a per channel basis. Id. at 18 (quoting Ex. 1008, 1; citing
Ex. 1007 § 11.2.1; Ex. 1019 ¶ 10) (alteration in original). Moreover,
Petitioner argues, R2-010182 introduces MinGBr, MaxBr, and TW to
“express accurately the needs of different applications in terms of bit rate,”
and “[a] global minimum bit rate for all logical channels is inconsistent with
IPR2019-00252
Patent 7,167,487 B2

33
[this] objective.” Id. at 17–18 (quoting Ex. 1008, 2; citing Ex. 1019 ¶ 8).
Petitioner further argues that both the ’487 patent and R2-010182 refer to the
same 3GPP document, TS 23.107 (albeit different versions), to explain their
minimum bit rate criteria. Id. at 19 (citing Ex. 1001, 2:1–6; Ex. 1008, 1;
Exs. 1020–21). Finally, Petitioner argues that although the Table in R2-
010182 shows two logical channels having the same MinGBr (i.e., 100
bits/TW), the two logical channels measure those bit rates over different
TWs (i.e., 3 vs. 4 TTI) and so have different minimum guaranteed bit rates
when measured in bits/sec. Id. at 21 (citing Ex. 1019 ¶¶ 11–13).
Lastly, both parties argue we should ignore the other parties’
arguments. See Pet. Reply 17 (arguing that Patent Owner’s arguments that
MinGBr is a global parameter are “only attorney arguments that should be
given no weight.”); PO Sur-Reply 12–13 (arguing that “Petitioners seek to
introduce the entirely new theory that the value of MinGBr of R2-010182 is
variable. . . . the Board is respectfully requested not to consider Petitioners’
arguments.”).
Upon consideration of the evidence and arguments presented by the
parties, summarized above, we find the combination of TS 25.321,
TS 25.302, and R2-010182 teaches a TFC selection algorithm that “uses a
minimum bit rate criteria applicable to the respective logical channel” as
recited in claim 13. First, we disagree with Patent Owner’s contention that
we should ignore Petitioner’s Reply for seeking “to introduce the entirely
new theory that the value of MinGBr is variable.” See PO Sur-Reply 12–13.
The Petition identifies MinGBr as “read[ing] on the ‘minimum bit rate
criteria’ recited in claim [13].” Pet. 38. Thus, the arguments and evidence
presented in Petitioner’s Reply, i.e., that MinGBr is a “local” rather than a
IPR2019-00252
Patent 7,167,487 B2

34
“global” parameter, were presented in response to Patent Owner’s arguments
to the contrary. See PO Resp. 20–21. Petitioner is “not barred from
elaborating on arguments on issues previously raised.” Chamberlain Grp.,
Inc. v. One World Techs., Inc., 944 F.3d 919, 925 (Fed. Cir. 2019).
Second, in our Institution Decision, we made a preliminary finding,
that:
although claim 1 requires each logical channel to have its own
respective minimum bit rate that does not imply or require the
minimum bit rate for every logical channel must be different
from the minimum bit rate for every other logical channel. For
example, logical channels a, b, and c can have respective
minimum bit rates of (1) 100, 150, and 200, (2) 100, 100, and
200, or (3) 100, 100, and 100. In each case, logical channels a,
b, and c have their own respective minimum bit rates, even
though some or all of the logical channels may have the same
minimum bit rate. In other words, claim 1 does not require the
minimum bit rate for each logical channel to differ from the
minimum bit rate for any or every other logical channel; it
simply requires each logical channel to have its own or
respective minimum bit rate that is independent of, though not
necessary different from, the respective minimum bit rates for
the other logical channels.
Dec. Inst. 40–41. Both parties agree with that preliminary finding, which we
maintain here. See Tr. 24:19–25:5 (Petitioner’s agreement); id. at 72:15–
73:3 (Patent Owner’s agreement).
TS 25.321 teaches a TFC selection algorithm that uses a single
parameter (MLP) assigned to each logical channel to represent that logical
channel’s priority. See Ex. 1007 § 11.2.1 (disclosing “each involved logical
channel is assigned a MAC Logical channel Priority (MLP) in the range
1,…,8.”) (emphasis added). R2-010182 proposes modifying that TFC
selection algorithm by introducing new parameters MinGBr, MaxBr, and
IPR2019-00252
Patent 7,167,487 B2

35
TW to “complete the current MLP for representing Logical channels
priorities.” Ex. 1008, 1 (emphasis added). R2-010182 teaches these new
parameters are needed to “complet[e] MLP to express accurately the needs
of different applications in term[s] of bit rate” because without these
parameters “[t]here is only one way to represent the quality of service at
logical channel level (MLP)” and the single MLP parameter “is not
sufficient to characterise all the applications foreseen for UMTS.” Id. at 1–
2 (emphasis added). R2-010182’s explanation that MinGBr is needed to
“complete the current MLP” in order to accurately express “the needs of
different applications” indicates that MinGBr (like MLP) can have different
values assigned for different logical channels. Id. at 2 (emphasis added).
Thus, MinGBr, MaxBR, and TW (like MLP) are parameters that
“characterise MAC logical channels for TFC selection.” Id. at 4 (emphasis
added).
This is expressly shown in the Table provided on page 2 of R2-
010182, which is reproduced below.

The Table shows two logical channels, LC1 and LC2, and the values
assigned to the parameters MPL, TW, MinGBr, and MaxBr for each logical
channel. Ex. 1008, 2. Logical channel LC1 is assigned an MLP of 1, a
MinGBr of 100 bits/TW measured over a time window (TW) of 3 TTI, and a
IPR2019-00252
Patent 7,167,487 B2

36
MaxBr of 200 bits/TW measured over the 3 TTI time window. Id.18
Logical channel LC2 is assigned an MLP of 2, a MinGBr of 100 bits/TW
measured over a 4 TTI time window, and a MaxBr of 200 bits/TW measured
over the 4 TTI time window. Id.
Significantly, the Table shows logical channels LC1 and LC2 have
separately assigned values for MLP, TW, MinGBr, and MaxBr, even though
the MinGBr parameter for both channels is assigned the same value when
that value is expressed as bits per TW (i.e., 100 bits/TW). However, as
discussed above, claim 13 does not require the minimum guaranteed bit rates
for LC1 and LC2 to be different; only to be independent or separately
assigned. Moreover, even though the Table shows LC1 and LC2 have the
same MinGBr expressed in bits/TW, the Table also shows that LC1 and LC2
have different MinGBr’s expressed in the more physical terms of bits/TTI or
bits/sec. When measured in bits/TTI, LC1 has a MinGBr of 33.3 bits/TTI
and LC2 has a MinGBr of 25 bits/TTI.19 Assuming a TTI of 10 ms, LC1 has
a MinGBr of 3.33 kbits/sec (33.3 bits/10 ms) and LC2 has a MinGBr of
2.5 kbits/sec (25 bits/10 ms).20

18 R2-010182 discloses that both MinGBr and MaxBr are measured in “units
[of] Bits/TW.” Ex. 1008, 2.
19 LC1 and LC2 are both assigned a MinGBr of 100 bits/TW measured over
time windows (TWs) of 3 TTI and 4 TTI, respectively. See Ex. 1008, 2.
Thus, LC1 has a MinGBr of 33.3 bits/TTI (100 bits/3 TTI) and LC2 has a
MinGBr of 25 bits/TTI (100 bits/4 TTI).
20 TTI is “defined as the inter-arrival time of Transport Block Sets” and is
“always a multiple of the minimum interleaving period (e.g., 10 ms, the
length of one Radio Frame).” Ex. 1009 § 7.1.5.
IPR2019-00252
Patent 7,167,487 B2

37
For the reasons discussed above, we find Petitioner has demonstrated
by a preponderance of evidence that the combination of TS 25.321,
TS 25.302, and R2-010182 teaches all the limitations of claim 13, and that a
person of ordinary skill in the art would have combined the teachings of
these references in the manner suggested. Therefore, Petitioner has
demonstrated that claim 13 is unpatentable over the combination of
TS25.321, R2-010182, and TS25.302.
6. Claim 11
Claim 11 is an independent claim, and recites a radio network
controller (RNC) for a network having the properties of the network
controlled by the method recited in claim 13. Compare Ex. 1001, 16:26–40,
with id. at 16:54–65. For example, where claim 13 recites a method for
controlling a network provided with “transport channels . . . for transmitting
transport blocks formed from packet units of the logic channels,” claim 11
recites an RNC “for forming transport bl[o]cks from packet units of the logic
channels and for transmitting the transport blocks through the transport
channels.” Compare id. at 16:28–31, with id. at 16:56–58. Similarly, where
claim 13 recites a method for controlling a network provided with “a
selection algorithm . . . for selecting the transport format combinations . . .
[that] uses a minimum bit rate criteria,” claim 11 recites the “selection
algorithm is provided in the radio network controller for selecting the
transport format combinations . . . while taking into account a minimum bit
rate.” Compare id. at 16:35–40, with id. at 16:61–65.
Given the similarity between claims 11 and 13, Petitioner largely
relies on its analysis of claim 13 to demonstrate how the combination of
TS 25.321, TS 25.302, and R2-010182 teaches the limitations of claim 11.
IPR2019-00252
Patent 7,167,487 B2

38
See Pet. 40–45. For example, Petitioner relies on its analysis of claim 13 to
demonstrate how TS 25.321 teaches a UMTS network having an RNC that
includes a MAC layer that maps logical channels onto transport channels.
Id. at 40–42; see also id. at 25–29. Petitioner then demonstrates how TS
25.321 teaches “the MAC-c/sh entity in the controlling RNC receives RLC-
PDUs from its RLC and ‘fit[s] [these RCL-PDUs] into the available
transport blocks on the transport channels.” Id. at 42–43 (quoting Ex. 1007
§§ 4.2.4, 4.2.4.1; citing Ex. 1002 ¶¶ 227–228) (emphasis omitted).
Petitioner also relies on its analysis of claim 13 to demonstrate how TS
25.302 teaches the RNC’s MAC layer allocates a number of valid transport
format combinations to the transport channels that indicate the transport
blocks for transmission on each transport channel. Id. at 44; see also id. at
30–34. Finally, Petitioner relies on its analysis of claim 13 to demonstrate
how TS 25.321 teaches the RNC’s MAC layer includes a TFC selection
algorithm, and how R2-010182 proposes modifying that algorithm so that it
“relies on the minimum guaranteed bit rate of the logical channels . . . to
select the TFCs.” Id. at 44–45 (emphasis omitted); see also id. at 34–40.
Patent Owner argues that claim 11 is patentable over the combination of
TS 25.321, TS 25.302, and R2-010182 for the same reasons as claim 13.
See PO Resp. 20–23; PO Sur-Reply 11–16.
For the reasons discussed in §§ II.F.4 and II.F.5, supra, having
considered all the evidence and arguments presented by Petitioner and
Patent Owner, we find Petitioner has demonstrated by a preponderance of
evidence that claim 11 is unpatentable over the combination of TS 25.321,
TS 25.302, and R2-010182.
IPR2019-00252
Patent 7,167,487 B2

39
7. Claim 12
Claim 12 is an independent claim, and recites a terminal for a network
having the properties of the network controlled by the method recited in
claim 13. Compare Ex. 1001, 16:41–53, with id. at 16:54–65. For example,
where claim 13 recites a method for controlling a network provided with
“transport channels . . . for transmitting transport blocks formed from packet
units of the logic channels,” claim 12 recites a terminal “for transmitting
transport blocks formed from packet units of the logic channels.” Compare
id. at 16:43–45, with id. at 16:56–58. Similarly, where claim 13 recites a
method for controlling a network provided with “a selection algorithm . . .
for selecting transport format combinations . . . [that] uses a minimum bit
rate criteria,” claim 12 recites a terminal provided with “a selection
algorithm . . . for selecting transport format combinations . . . [where] the
selection of the transport format combinations is carried out while taking
into account a minimum bit rate.” Compare id. at 16:48–53, with id. at
16:61–65.
Given the similarity between claims 12 and 13, Petitioner largely
relies on its analysis of claim 13 to demonstrate how the combination of
TS 25.321, TS 25.302, and R2-010182 teaches the limitations of claim 12.
See Pet. 41–45. For example, Petitioner relies on its analysis of claim 13 to
demonstrate how TS 25.321 teaches a UMTS network having a UE
(terminal) that includes a MAC layer that maps logical channels onto
transport channels. Id. at 41–42. Petitioner then demonstrates how TS
25.321 teaches the UE’s MAC layer transmits transport blocks formed from
packet units of the logic channels. Id. at 43–44. In particular, Petitioner
demonstrates how TS 25.321 teaches an RLC layer in the UE “provides
IPR2019-00252
Patent 7,167,487 B2

40
RLC-PDUs to the MAC, which fit into the available transport blocks on the
transport channels.” Id. at 29–30 (quoting Ex. 1007 § 4.2.3.1) (emphasis
omitted). Petitioner also relies on its analysis of claim 13 to demonstrate
how TS 25.302 teaches the UE’s MAC layer allocates a number of valid
transport format combinations to the transport channels that indicate the
transport blocks for transmission on each transport channel. Id. at 44.
Finally, Petitioner relies on its analysis of claim 13 to demonstrate how
TS 25.321 teaches the UE’s MAC layer includes a TFC selection algorithm,
and how R2-010182 proposes modifying that algorithm so that it “relies on
the minimum guaranteed bit rate of the logical channels . . . to select the
TFCs.” Id. at 44–45 (emphasis omitted); see also id. at 34–40. Patent
Owner argues that claim 12 is patentable over the combination of TS 25.321,
TS 25.302, and R2-010182 for the same reasons as claim 13. See PO Resp.
20–23; PO Sur-Reply 11–16.
For the reasons discussed in §§ II.F.4 and II.F.5, supra, having
considered all the evidence and arguments presented by Petitioner and
Patent Owner, we find Petitioner has demonstrated by a preponderance of
evidence that claim 12 is unpatentable over the combination of TS 25.321,
TS 25.302, and R2-010182.
G. The Peisa challenge
Petitioner argues claims 11–13 are unpatentable over Peisa. See Pet.
46–69; Pet. Reply 21–26. Patent Owner disputes this. See PO Resp. 24–27;
PO Sur-Reply 16–18. For the reasons discussed below, Petitioner
demonstrates by a preponderance of evidence that claims 11–13 are
unpatentable over Peisa.
IPR2019-00252
Patent 7,167,487 B2

41
1. Peisa
Peisa discloses a UMTS network that includes a number of RNCs and
a number of UEs, such as mobile terminals. Ex. 1013, 1:66–2:16. “User
and signaling data may be carried between an RNC 140 and a UE 110 using
Radio Access Bearers (RABs).” Id. at 4:28–30. UEs may be “allocated one
or more RABs, each of which is capable of carrying a flow of user or
signaling data” and each of which is “mapped onto respective logical
channels.” Id. at 4:31–34. The UE includes a MAC layer that maps “a set
of logical channels . . . onto a transport channel.” Id. at 4:34–36. The
transport channel is then “mapped at the physical layer onto a [physical
channel] for transmission over the air interface.” Id. at 4:43–47.
Figure 3 of Peisa, which is reproduced below, discloses the layer 2 or
MAC protocol layer of Peisa’s UMTS network.

IPR2019-00252
Patent 7,167,487 B2

42
Figure 3 of Peisa “illustrates a simplified UMTS layer 2 protocol structure
which is involved in the communication between mobile stations . . . or
more broadly UEs 110, and Radio Network Controllers (RNCs) 140.” Id. at
6:31–37. The protocol structure “includes a set of Radio Access Bearers
(RABs) 305 that make available radio resources (and services) to user
applications.” Id. at 6:41–44. Data flowing from RABs 305 “are passed to
respective Radio Link Control (RLC) entities 310 . . . [that] buffer the
received data,” and map RABs 305 “onto respective logical channels 315.”
Id. at 6:45–50. MAC 320 “receives data transmitted in the logical channels
315 and further maps the data from the logical channels 315 onto a set of
transport channels 325.” Id. at 6:50–54. “The transport channels 325 are
finally mapped to a single physical transport channel 330, which has a total
bandwidth . . . allocated to it by the network.” Id. at 6:54–57.
Although MAC 320 “performs scheduling of outgoing data packets”
buffered by RLC 310, a Radio Resource Controller (RRC) “sets a limit on
the maximum amount of data that can be transmitted from each flow by
assigning a set of allowed Transport Format Combinations” to MAC 320.
Id. at 10:19–25. A Transport Format Combination is a set of “all possible
TFs [transport formats] for a given transport channel.” Id. at 7:17–20. RRC
335 defines the set of all possible TFs for a transport channel in terms of TB
(Transport Block) sizes and TBS (Transport Block Set) sizes. Id. at 7:2–13.
The TB size “tells the MAC entity what packet sizes it can use to transport
data to the physical layer,” and the TBS size tells the MAC entity “the total
number of bits [it] can transmit to the physical layer in a single transmission
time interval (TTI).” Id. at 7:4–11. MAC 320 “independently decide[s] how
IPR2019-00252
Patent 7,167,487 B2

43
much data is transmitted from each flow by choosing the best available
Transport Format Combination (TFC) from the TFCS.” Id. at 10:25–28.
Peisa discloses a number of algorithms by which MAC 320 selects the
best available TFC from a set of TFCs to schedule data transmissions. For
example, Figure 4 is a “method in flowchart form for allocating bandwidth
resources to data flow streams between entities in the exemplary second
layer architecture of FIG. 3.” Id. at 3:49–54. Figures 6 and 8 are similarly
“method[s] in flowchart form for scheduling data flows.” Id. at 3:55–57,
3:61–63. Figure 8 of Peisa is reproduced below.

Figure 8 is an illustration of “the scheduling process in the MAC layer
[that] includes the selection of a TFC from a TFCS using a two-step scoring
process.” Id. at 18:29–34. At step 805, “several parameters are obtained for
IPR2019-00252
Patent 7,167,487 B2

44
each logical channel.” Id. at 18:35–36, Fig. 8. For example, “[t]he QoS
Class for each logical channel may be obtained from the corresponding RAB
parameter,” and “[t]he Guaranteed Rate for each logical channel may also be
obtained from the corresponding RAB parameter.” Id. at 18:36–43. At step
810, a logical channel score and a logical channel bonus score are calculated
for each logical channel. Id. at 18:60–67, Fig. 8. At step 815, for each TFC
in the TFCS, a score is calculated by summing all of the logical channel
scores and a bonus score is calculated by summing all of the logical channel
bonus scores for all of the logical channels in the TFC. Id. at 19:1–6, Fig. 8.
At step 820, the MAC selects the TFC with the largest score, or the TFC
with the largest bonus score if two or more TFCs have the same score. Id. at
19:7–10, Fig. 8. This algorithm “ensures that if there is a TFC that transmits
at least the guaranteed rate for each flow, then that TFC is chosen.” Id. at
19:10–13.
2. Claim 13
Claim 13 recites a method of controlling a network with a first
plurality of logic channels associated with a second plurality of transport
channels. Ex. 1001, 16:54–56. Petitioner demonstrates how Peisa teaches
this limitation. See Pet. 46–48 (citing Ex. 1013, 1:64–2:17, 2:48–51, 6:41–
65, 9:30–35, Fig. 1). Peisa discloses a UMTS cellular network having a
plurality of RNCs and UEs. Ex. 1013, 1:64–2:17, Fig. 1. The UEs and
RNCs execute several processes to control the UMTS network, including
“packet scheduling in accordance of quality of service (QoS) constraints for
data flows.” Id. at 2:48–51, 9:30–34. The UEs and RNCs have a MAC
layer that “receives data transmitted in the logical channels 315 and further
maps the data from the logical channels 315 onto a set of transport channels
IPR2019-00252
Patent 7,167,487 B2

45
325.” Id. at 6:41–65. This is shown, for example, in a Petitioner-annotated
version of Figure 3 of Peisa, which is reproduced below.

The Figure above is a Petitioner-annotated version of Figure 3 of Peisa. See
Pet. 49. The Figure discloses a simplified, exemplary, layer 2 protocol
structure that is involved in communications between UEs 110 and RNCs
140 in Peisa’s UMTS network 100. Ex. 1013, 6:28–37. Peisa teaches that
the entities shown in Figure 3, including the RABs, RLCs, and MAC and
RRC layers are located in both the UE and RNC. Id. at 6:31–37, 17:62–65,
Figs. 3, 7. Patent Owner does not dispute that Peisa teaches this limitation.
See PO Resp. 24–27.
Claim 13 further recites the transport channels are provided for
transmitting blocks formed from packet units of the logic channels.
IPR2019-00252
Patent 7,167,487 B2

46
Ex. 1001, 16:56–58. Petitioner demonstrates how Peisa teaches this
limitation.21 See Pet. 49–52 (quoting/citing Ex. 1013, 4:31–34, 6:41–55,
10:29–56, Fig. 3). Peisa teaches that data flows from “RABs 305 are passed
to respective Radio Link Control (RLC) entities 310,” which “buffer the
received data” and map the RABs “onto respective logical channels 315.”
Ex. 1013, 6:45–50. MAC entity 320 “receives data transmitted in the logical
channels 315 and further maps the data from the logical channels 315 onto a
set of transport channels 325.” Id. at 6:50–54. MAC entity 320 selects a
Transport Format Combination (TFC) that includes transport channels 325,
and RLCs 310 deliver the buffered data flows from RABs 305 as “packets to
the MAC entity [320],” which schedules delivery of the “packets in
accordance with the selected TFC.” Id. at 10:45–53. Patent Owner does not
dispute that Peisa teaches this limitation. See PO Resp. 24–27.
Claim 13 further recites a plurality of valid transport format
combinations allocated to the transport channels that indicate the transport
blocks provided for transmission on each transport channel. Ex. 1001,
16:58–61. Petitioner demonstrates how Peisa teaches this limitation. See
Pet. 52–56 (citing/quoting Ex. 1013, 7:2–16, 7:25–8:2, 10:15–29). Peisa
teaches that for each transport channel 325, RRC 335 defines transport block

21 As noted above, Peisa teaches that the various entities, including the
RABs, RLCs, and MAC and RRC layers are implemented in both UEs and
RNCs. Ex. 1013, 6:31–37, 17:62–65, Figs. 3, 7. Moreover, Peisa teaches
the entities have the same functionality in the UEs and RNCs. Id. at 9:30–
35, 18:17–18. Thus, we limit our discussion to Petitioner’s evidence
demonstrating the existence and functionality of these elements in UEs, but
find Petitioner has also demonstrated that these elements exist in and have
the same functionality in RNCs. See Pet. 58 (quoting Ex. 1013, 9:30–35,
18:17–18).
IPR2019-00252
Patent 7,167,487 B2

47
parameters (TB size and TBS size) that “together with some additional
information . . . form a TF [Transport Format].” Ex. 1013, 7:2–13. Peisa
further teaches that the combination of “all possible TFs for a given
transport channel . . . is called a Transport Format Combination.” Id. at
7:17–20. However, not all Transport Format Combinations are allowed
because RRC 335 “has to ensure that the total transmission capability on all
transport channels 325 does not exceed the transmission capability of
physical channel 330.” Id. at 7:30–33. Thus, RRC 335 provides “MAC
entity 320 a Transport Format Combination Set (TFCS), which contains the
allowed Transport Format Combinations [TFCs] for all transport channels.”
Id. at 7:33–36 (emphasis added). That is, Peisa teaches a plurality of valid
TFCs, where valid TFCs are those that are allowed because they do not
exceed the transmission capability of physical channel 330. See Pet. 54
(citing Ex. 1002 ¶¶ 293–297). Patent Owner does not dispute that Peisa
teaches this limitation. See PO Resp. 24–27.
Claim 13 further recites a selection algorithm for selecting the
transport format combinations. Ex. 1001, 16:61–63. Petitioner
demonstrates how Peisa teaches this limitation. See Pet. 56–59
(citing/quoting Ex. 1013, 9:9–16, 11:43–47, 18:29–34, Figs. 4, 8). Peisa
teaches “a method of allocating transmission resources at a Media Access
Control (MAC) entity,” including by “selecting a Transport Format
Combination (TFC) from a TFC Set.” Ex. 1013, 9:9–16. Peisa discloses
several TFC selection algorithms, including the algorithms shown in Figures
4 and 8. Id. at 11:43–47, 18:29–34, Figs. 4, 8. Patent Owner does not
dispute that Peisa teaches this limitation. See PO Resp. 24–27.
IPR2019-00252
Patent 7,167,487 B2

48
Lastly, claim 13 requires the selection algorithm to use a minimum bit
rate criteria applicable to the respective logic channel. Ex. 1001, 16:61–65.
The parties dispute whether this limitation is met. See Pet. 59–61; Pet.
Reply 23–26; PO Resp. 24–27; PO Sur-Reply 16–18. Petitioner argues
Peisa teaches this limitation because the TFC selection algorithm of Figure 4
“[s]chedules packets by optimizing the throughput while still keeping the
fairness (i.e., guaranteed rates).” Pet. 59 (quoting/citing Ex. 1013, 11:43–49,
Fig. 4) (emphasis omitted, alteration in original). Petitioner further argues
Peisa teaches this limitation because the TFC selection algorithm shown in
Figure 8 “uses a two-step scoring process, relying on logical channel
parameters that include the ‘Guaranteed Rate for each logical channel.’” Id.
(quoting Ex. 1013, 18:29–57) (emphasis omitted). Relying on the testimony
of Dr. Beuhrer, Petitioner argues a person skilled in the art would have
understood “that Peisa’s FIG. 8 flowchart corresponds to a selection
algorithm that uses a minimum bit rate criteria” because it “selects a TFC
that satisfies ‘at least the guaranteed rate for each flow,’ where a flow
corresponds to a logical channel.” Id. at 61 (citing Ex. 1002 ¶¶ 306–309;
Ex. 1013 19:10–13) (emphasis omitted).
Patent Owner argues that Petitioner has failed to establish that the
TFC selection algorithms shown in Figures 4 and 8 of Peisa use “a minimum
bit rate criteria.” See PO Resp. 24–27. Regarding Figure 4, Patent Owner
argues Petitioner fails to explain how (a) “maintaining so-called ‘fairness
(i.e. guaranteed rates),’” (b) “calculating a fair MAC bandwidth share for
each input flow,” or (c) selecting a TFC that “most closely matches the
adjusted fair shares” teaches or suggests using a minimum bit rate criteria.
Id. at 25. Moreover, Patent Owner argues, rather than teaching a minimum
IPR2019-00252
Patent 7,167,487 B2

49
bit rate criteria, “Peisa describes the ‘fairness’ calculation of Figure 4 as
applying ‘the maximum allowed rate for any logical channel.’” Id. (quoting
Ex. 1013, 11:9–10). Regarding Figure 8, Patent Owner argues Petitioner
“fails to explain why the ‘Guaranteed Rate’ . . . necessarily constitutes” a
minimum bit rate criteria, and further argues that a TFC selection that
“meets or exceeds a guaranteed rate . . . does not necessarily mean that a
different minimum rate is not also applicable.” Id. at 26–27.
Petitioner, again relying on the testimony of Dr. Buehrer, responds
that a person skilled in the art “would have understood that Peisa teaches . . .
selecting TFCs based on a minimum bit rate criteria.” Pet. Reply 23 (citing
Ex. 1002 ¶¶ 95–98, 257–260). Petitioner further argues that the term
“guaranteed rate” is a term of art “well known in the context of QoS
constraints of data flows to reflect a minimum resource requirement for the
data flows.” Id. at 23–24 (citing Ex. 1019 ¶¶ 22–23). Petitioner argues the
’487 patent itself recognizes this by defining “minimum bit rate” in terms of
3GPP’s QoS specification, TS23.107, which “does not mention a ‘minimum
bit rate,’ but only defines a ‘guaranteed bitrate’ QoS attribute” as a
“[m]inimum resource requirement.” Id. at 24 (citing Ex. 1001, 2:1–6;
quoting Ex. 1020 § 6.4.3.2) (alteration in original, emphasis omitted).
Regarding Peisa’s Figure 4 algorithm, Petitioner argues it “achieves
the fair rate over time, thus providing a minimum rate over time” by
providing each flow “at least their determined fair rate.” Id. at 25 (quoting
Ex. 1013, 11:29–32) (emphasis omitted). Petitioner further argues the
inclusion and use of a maximum rate as an upper limit in the Figure 4
algorithm “does not conflict with the understanding that the fair rate
corresponds to a minimum rate or lower limit over time.” Id. (citing Ex.
IPR2019-00252
Patent 7,167,487 B2

50
1019 ¶ 26). Regarding Peisa’s Figure 8 algorithm, Petitioner reiterates that a
person skilled in the art would have understood that a “guaranteed rate
corresponds to a minimum bit rate” because the algorithm selects “a TFC
that satisfies ‘at least the guaranteed rate’ for each flow (logical channel),
where the phrase ‘at least’ indicates a lower limit (i.e., minimum)
requirement.” Id. (quoting Ex. 1013, 19:10–13; citing Ex. 1002 ¶¶ 259–
260). Moreover, Peisa teaches the Figure 8 algorithm “provide[s] the
guaranteed rate transfer rate to all service classes” by “providing a minimum
level of service to all flows.” Id. (quoting Ex. 1013, 20:9–32) (emphases
omitted).
In Sur-Reply, Patent Owner argues “Petitioner[] seek[s] to introduce
evidence that Peisa would have used the terms ‘fairness’ and ‘guaranteed
rate[]’ to mean a guaranteed bit rate as used in TS 23.107” but should have
presented this information in the Petition rather than in the Reply. PO Sur-
Reply 17. Patent Owner further argues that Petitioner’s explanation of the
“fairness” of Peisa’s Figure 4 algorithm and of the “guaranteed bit rate” of
Peisa’s Figure 8 algorithm fails to demonstrate how either algorithm teaches
using a “minimum bit rate criteria.” Id. at 17–18.
Upon consideration of the evidence and arguments presented by the
parties, summarized above, we find Peisa teaches a TFC selection algorithm
that “uses a minimum bit rate criteria applicable to the respective logical
channel.” Peisa teaches each logical channel is assigned its own or
respective guaranteed bit rate. For example, the Figure 4 TFC selection
algorithm “[s]chedules packets by optimizing the throughput . . . while still
keeping the fairness (i.e., guaranteed rates).” Ex. 1013, 11:47–49.
Similarly, the Figure 8 TFC selection algorithm schedules packets based on
IPR2019-00252
Patent 7,167,487 B2

51
scores calculated using an array, GuarRateVect[lch], that is indexed by the
logical channel variable “lch.” Id. at 19:18–20:8. The Figure 8 algorithm is
reproduced below.

Figure 8 of Peisa, is a flowchart “for scheduling data flows.” Id. at 18:29–
31. The scheduling algorithm obtains “several parameters . . . for each
logical channel,” including a guaranteed rate “obtained from [a]
corresponding RAB parameter.” Id. at 18:35–43. The algorithm calculates
(a) two scores for each logical channel using that logical channel’s
guaranteed rate (step 810), (b) two scores for each TFC in a set of TFCs,
where each TFC score adds one of the two logical channel scores for all of
the logical channels in the TFC (step 815), and selects (c) one of the TFCs in
IPR2019-00252
Patent 7,167,487 B2

52
the set of TFCs based on the two TFC scores calculated for each TFC.22 See
id. at 18:29–19:10.
According to the unrebutted testimony of Dr. Beuhrer, a person
skilled in the art would have understood “Peisa’s TFC selection algorithm
uses a minimum bit rate criteria . . . that corresponds to the guaranteed rate
of the logical channel, since the algorithm of FIG. 8 selects a TFC that
satisfies ‘at least the guaranteed rate for each flow,’ where a flow
corresponds to a logical channel.” Ex. 1002 ¶ 260 (quoting Ex. 1013,
19:10–13). That is, a person skilled in the art would have understood Peisa’s
algorithm uses “a minimum bit rate criteria of logical channels in performing
TFC selection, since the algorithm attempts to satisfy at least (i.e., lower
limit requirement) the guaranteed rate for each logical channel.” Id.
Although Patent Owner disputes Petitioner’s contention that Peisa’s
fair or guaranteed rates are minimum bit rates, Patent Owner offers no
evidence to counter Dr. Beuhrer’s opinion that a person skilled in the art
would have understood that they are. See PO Resp. 24–27; see also
Johnston v. IVAC Corp., 885 F.2d 1574, 1581 (Fed. Cir. 1989) (“Attorneys’
argument is no substitute for evidence.”). Moreover, Petitioner’s Reply
provides additional evidence supporting Dr. Beuhrer’s opinion. See Pet.
Reply 24 (citing Ex. 1021 § 6.4.3.2; Ex. 1019 ¶¶ 22–24). For example, in a

22 The TFC selection is based on the Score and Bonus_score calculated for
each TFC. See Ex. 1013, 19:7–10. Score is the sum of the scores (Score-
_lch) and Bonus_score is the sum of the bonus scores (Bonus_score_lch)
calculated for each of the logical channels in the TFC. Id. at 18:60–19:6.
Score_lch and Bonus_score_lch are calculated for each logical channel, and
are a function of each logical channel’s Guaranteed Rate. Id. at 18:35–43,
18:60–57; FIG 8.
IPR2019-00252
Patent 7,167,487 B2

53
section entitled “UMTS Bearer Service Attributes” and a subsection entitled
“Attributes discussed per traffic class,” TS 23.107 teaches the guaranteed
bitrate is “used for resource allocation in UMTS” and that a “[m]inimum
resource requirement is determined by [the] guaranteed bitrate.” Ex. 1021
§§ 6.4.3, 6.4.3.2 (emphasis added).
Although Patent Owner argues that we should not consider this
additional evidence because it could have been presented in the Petition, we
find it has been properly presented in response to Patent Owner’s argument
that Peisa’s “fair rate” or “guaranteed rate” is not a minimum bitrate. See
PO Resp. 25–26. The Petition cites Peisa for equating a “fair rate” with a
“guaranteed rate,” and cites Dr. Buerher’s declaration for testimonial
evidence that a person skilled in the art would have understood Peisa’s
“guaranteed rate” to be a “minimum bit rate.” See Pet. 59, 61 (quoting Ex.
1013, 11:43–49; citing Ex. 1002 ¶¶ 306–309). Thus, the evidence presented
in Petitioner’s Reply that persons skilled in the art understood “guaranteed
rates” to be “minimum bit rates” or “minimum resource requirements” is
(a) consistent with arguments raised in the Petition, and (b) responsive to
arguments raised in Patent Owner’s Response. Accordingly, they are
appropriately made in Petitioner’s Reply. See 37 C.F.R. § 42.23(b); see also
Chamberlain Grp., 944 F.3d at 925 (Fed. Cir. 2019) (finding a party is “not
barred from elaborating on arguments on issues previously raised.”).
For all of the reasons discussed above, we find Petitioner has
demonstrated that Peisa discloses a TFC selection algorithm that uses a
minimum bit rate criteria applicable to the respective logic channel.
Accordingly, for the reasons discussed above, we find Petitioner has
demonstrated by a preponderance of evidence that a person skilled in the art
IPR2019-00252
Patent 7,167,487 B2

54
would have understood Peisa to teach or suggest all the limitations of claim
13. Therefore, Petitioner has demonstrated by a preponderance of evidence
that claim 13 is unpatentable over Peisa.
3. Claim 11
Claim 11 recites a radio network controller (RNC) for a network
having the properties of the network controlled by the method recited in
claim 13. Compare Ex. 1001, 16:26–40, with id. at 16:54–65. For example,
where claim 13 recites a method for controlling a network provided with
“transport channels . . . for transmitting transport blocks formed from packet
units of the logic channels,” claim 11 recites an RNC “for forming transport
bl[o]cks from packet units of the logic channels and for transmitting the
transport blocks through the transport channels.” Compare id. at 16:28–31,
with id. at 16:56–58. Similarly, where claim 13 recites a method for
controlling a network provided with “a selection algorithm . . . for selecting
the transport format combinations . . . [that] uses a minimum bit rate
criteria,” claim 11 recites the “selection algorithm is provided in the radio
network controller for selecting the transport format combinations . . . while
taking into account a minimum bit rate.” Compare id. at 16:35–40, with id.
at 16:61–65.
Given the similarity between claims 11 and 13, Petitioner largely
relies on its analysis of claim 13 to demonstrate how Peisa teaches the
limitations of claim 11. See Pet. 62–64, 67–69. For example, Petitioner
relies on its analysis of claim 13 to demonstrate how Peisa teaches a UMTS
network having an RNC that includes a MAC layer that maps logical
channels 315 onto transport channels 325. Id. at 62–64 (quoting Ex. 1013,
1:64–2:17, 6:24–65, 9:30–34, 18:17–18, Fig. 3). Petitioner then relies on its
IPR2019-00252
Patent 7,167,487 B2

55
analysis of claim 13 to demonstrate how Peisa teaches the RNC’s MAC
layer schedules the transmission of data packets by mapping packets in
logical channels to transport blocks transmitted through transport channels.
Id. at 67. Next, Petitioner relies on its analysis of claim 13 to demonstrate
how Peisa teaches the RNC’s MAC layer allocates a number of valid
transport format combinations to the transport channels that indicate the
transport blocks for transmission on each transport channel. Id. at 68–69.
Finally, Petitioner relies on its analysis of claim 13 to demonstrate how Peisa
teaches the RNC’s MAC layer includes a selection algorithm for selecting
transport format combinations while taking into account a minimum bit rate.
Id. at 69. Patent Owner argues that claim 11 is patentable over Peisa for the
same reasons as claim 13. See PO Resp. 24–27; PO Sur-Reply 16–18.
For the reasons discussed in § II.G.2, supra, having considered all the
evidence and arguments presented by Petitioner and Patent Owner, we find
Petitioner has demonstrated by a preponderance of evidence that claim 11 is
unpatentable over Peisa.
4. Claim 12
Claim 12 recites a terminal for a network having the properties of the
network controlled by the method recited in claim 13. Compare Ex. 1001,
16:41–53, with id. at 16:54–65. For example, where claim 13 recites a
method for controlling a network provided with “transport channels . . . for
transmitting transport blocks formed from packet units of the logic
channels,” claim 12 recites a terminal “for transmitting transport blocks
formed from packet units of the logic channels.” Compare id. at 16:43–45,
with id. at 16:56–58. Similarly, where claim 13 recites a method for
controlling a network provided with “a selection algorithm . . . for selecting
IPR2019-00252
Patent 7,167,487 B2

56
transport format combinations . . . [that] uses a minimum bit rate criteria,”
claim 12 recites a terminal provided with “a selection algorithm . . . for
selecting transport format combinations . . . [where] the selection of the
transport format combinations is carried out while taking into account a
minimum bit rate.” Compare id. at 16:48–53, with id. at 16:61–65.
Given the similarity between claims 12 and 13, Petitioner largely
relies on its analysis of claim 13 to demonstrate how Peisa teaches the
limitations of claim 12. See Pet. 64–69. For example, Petitioner relies on its
analysis of claim 13 to demonstrate how Peisa teaches a UMTS network
having a UE (terminal) that includes a MAC layer that maps logical
channels 315 onto transport channels 325. Id. at 64–66 (quoting Ex. 1013,
1:64–2:17, 6:24–65, 9:30–34, 18:17–18, Fig. 3). Petitioner also relies on its
analysis of claim 13 to demonstrate how Peisa teaches the UE’s MAC layer
transmits transport blocks formed from packets of logical channels. Id. at
68. Petitioner further relies on its analysis of claim 13 to demonstrate how
Peisa teaches the UE’s MAC layer allocates a number of valid transport
format combinations to the transport channels that indicate the transport
blocks for transmission on each transport channel. Id. at 68–69. Finally,
Petitioner relies on its analysis of claim 13 to demonstrate how Peisa teaches
the UE’s MAC layer includes a selection algorithm for selecting transport
format combinations while taking into account a minimum bit rate. Id. at
69. Patent Owner argues that claim 12 is patentable over Peisa for the same
reasons as claim 13. See PO Resp. 24–27; PO Sur-Reply 16–18.
For the reasons discussed in § II.G.2, supra, having considered all the
evidence and arguments presented by Petitioner and Patent Owner, we find
IPR2019-00252
Patent 7,167,487 B2

57
Petitioner has demonstrated by a preponderance of evidence that claim 12 is
unpatentable over Peisa.
III. CONCLUSION
We have reviewed the Petition, Patent Owner Response, Petitioner
Reply, and Patent Owner Sur-Reply. We have considered all of the
evidence and arguments presented by Petitioner and Patent Owner, and have
weighed and assessed the entirety of the evidence as a whole.
We determine, on this record, that Petitioner has demonstrated by a
preponderance of evidence that claims 11–13 of the ’487 patent are
unpatentable over TS 25.321, TS 25.302, and R2-010182. 23 We further
determine that Petitioner has demonstrated by a preponderance of evidence
that claims 11–13 of the ’487 patent are unpatentable over Peisa.

23 Should Patent Owner wish to pursue amendment of the challenged
claims in a reissue or reexamination proceeding subsequent to the
issuance of this decision, we draw Patent Owner’s attention to the April
2019 Notice Regarding Options for Amendments by Patent Owner
Through Reissue or Reexamination During a Pending AIA Trial
Proceeding. See 84 Fed. Reg. 16,654 (Apr. 22, 2019). If Patent Owner
chooses to file a reissue application or a request for reexamination of the
challenged patent, we remind Patent Owner of its continuing obligation to
notify the Board of any such related matters in updated mandatory
notices. See 37 C.F.R. § 42.8(a)(3), (b)(2).

Claims 35 U.S.C. § Reference(s)/Basis
Claims
Shown
Unpatentable
Claims
Not Shown
Unpatentable
11–13 103 TS 25.321,
TS 25.302,
R2-010182
11–13
11–13 103 Peisa 11–13
IPR2019-00252
Patent 7,167,487 B2

58

IV. ORDER
It is hereby:
ORDERED that claims 11–13 of the ’487 patent are unpatentable
under 35 U.S.C. § 103(a) as obvious over TS 25.321, TS 25.302 and R2-
010182;
FURTHER ORDERED that claims 11–13 of the ’487 patent are
unpatentable under 35 U.S.C. § 103(a) as obvious over Peisa; and
FURTHER ORDERED that this Decision is final, and a party to this
proceeding seeking judicial review of the Decision must comply with the
notice and service requirements of 37 C.F.R. § 90.2.

Overall
Outcome
11–13
IPR2019-00252
Patent 7,167,487 B2

59
PETITIONER:
W. Karl Renner
Roberto J. Devoto
Ayan Roy-Chowdhury
FISH & RICHARDSON PC
axf-ptab@fr.com
devoto@fr.com
roy-chowdhury@fr.com
Robert Mattson
MATTSON IP PLC
rmattson@mattsonip.com

Timothy Maier
Christopher Maier
MAIER & MAIER, PLLC
tjm@maierandmaier.com
cjm@maierandmaier.com

PATENT OWNER:
Ryan Loveless
Brett Mangrum
James Etheridge
Jeffrey Huang
ETHERIDGE LAW GROUP
ryan@etheridgelaw.com
brett@etheridgelaw.com
jim@etheridgelaw.com
jeff@etheridgelaw.com