UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________________
`
`BLACKBERRY CORP.,
`
`Petitioner,
`
`v.
`
`UNILOC 2017 LLC,
`
`Patent Owner.
`
`
`____________________
`
`Case No. IPR2019-01283
`Patent No. 7,167,487
`____________________
`
`
`PETITION FOR INTER PARTES REVIEW
`OF U.S. PATENT NO. 7,167,487
`
`
`
`____________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________________
`
`BLACKBERRY CORP.,
`
`Petitioner,
`
`v.
`
`UNILOC 2017 LLC,
`
`Patent Owner.
`
`
`____________________
`
`Case No. IPR2019-01283
`Patent No. 7,167,487
`____________________
`
`
`PETITION FOR INTER PARTES REVIEW
`OF U.S. PATENT NO. 7,167,487
`
`
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`
`TABLE OF CONTENTS
`INTRODUCTION ............................................................................ 4
`I.
`II. CHALLENGE AND RELIEF REQUESTED ................................. 4
`A. Proposed Grounds and Prior Art ............................................ 4
`III. GROUNDS FOR STANDING ......................................................... 5
`IV. OVERVIEW OF THE ’487 PATENT AND PRIOR ART ............... 5
`A.
`’487 Patent Overview .............................................................. 5
`B.
`’487 Patent Prosecution History Summary ........................... 8
`C. TS25.321 ................................................................................ 10
`D. R2-010182 .............................................................................. 13
`E. TS25.302 ................................................................................ 17
`F. Peisa ....................................................................................... 20
`V. CLAIM CONSTRUCTION ............................................................ 24
`VI. DETAILED EXPLANATION OF GROUNDS ............................. 24
`A. Ground 1: TS25.321 in view of R2-010182
`and TS25.302 renders claims 11-13 obvious ...................... 24
`B. Ground 2: Peisa renders claims 11-13 obvious .................... 53
`VII. CONCLUSION ............................................................................... 81
`VIII. MANDATORY NOTICES UNDER 37 C.F.R. §42.8 .................... 81
`IX. PAYMENT OF FEES UNDER 37 C.F.R. §42.15(a) .................... 83
`
`i
`
`
`
`
`
`
`
`
`
`
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`
`LIST OF EXHIBITS
`
`
`EX-1001 U.S. Patent No. 7,167,487 (“the ’487 Patent”)
`EX-1002 Declaration of R. Michael Buehrer, Ph.D., FIEEE
`
`(“Buehrer”)
`EX-1003 Curriculum Vitae of R. Michael Buehrer, Ph.D., FIEEE
`EX-1004 Prosecution History of U.S. Patent No. 7,167,487 (“the
`
`Prosecution History”)
`EX-1005 RESERVED
`EX-1006 Declaration of Craig Bishop (“Bishop”)
`EX-1007 3GPP TS 25.321 V3.6.0 (2000-12) Technical Specification,
`
`“3rd Generation Partnership Project; Technical
`
`
`
`
`Specification Group Radio Access Network; MAC protocol
`
`
`specification (Release 1999)” (“TS25.321”)
`EX-1008 Mitsubishi Electric Telecom (Trium R&D), R2-010182
`
`“Corrections to logical channel priorities in MAC protocol,”
`
`Change Request for 3GPP TS 25.321 V3.6.0, 3GPP TSG-
`WG2 Meeting #18, Edinburgh, Scotland, 17th -19th January
`
`
`2001 (“R2- 010182”)
`EX-1009 3GPP TS 25.302 V3.6.0 (2000-09) Technical Specification,
`“3rd Generation Partnership Project; Technical
`
`
`Specification Group Radio Access Network; Services
`
`provided by the physical layer (Release 1999)” (“TS25.302”)
`EX-1010 3GPP Portal, Specification #: 25.321, Versions,
`
`https://portal.3gpp.org/desktopmodules/Specifications/
`
`SpecificationDetails.aspx?specificationId=1175
`EX-1011 RESERVED
`EX-1012 RESERVED
`
`
`
`ii
`
`
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`
`EX-1013 United States Patent No. 6,850,540 B1 to Peisa et al.
`
`(“Peisa”)
`EX-1014 RESERVED
`EX-1015 Holma and Toskala, “WCDMA for UMTS”, Wiley, 2000
`
`(excerpts) (“Holma”)
`EX-1016 F. Muratore, “UMTS: Mobile Communications for the
`Future”, Wiley, 2001 (“Muratore”)
`
`EX-1017 K. Washburn and J. Evans, “TCP/IP: Running a successful
`
`network”, Addison-Wesley, 1996 (excerpts) (“Washburn”)
`
`
`
`iii
`
`
`
`
`I.
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`INTRODUCTION
`BlackBerry Corp. (“Petitioner”) requests Inter Partes Review
`
`(“IPR”) of claims 11-13 (“the Challenged Claims”) of U.S. Patent No.
`
`7,167,487 (“the ’487 Patent”).
`
`II. CHALLENGE AND RELIEF REQUESTED
`
`
`A. Proposed Grounds and Prior Art
`Petitioner requests IPR of the Challenged Claims on the following
`
`pre- AIA 35 U.S.C. §103(a) grounds, as explained below and in the
`
`Declaration of Prof. R. Michael Buehrer (EX-1002), and in which Prof.
`
`Buehrer has also provided a detailed tutorial to orient the Board to the
`
`relevant technology. See, e.g., Buehrer, ¶¶27-50.
`
`Ground
`1
`
`‘487Claims
`11-13
`
`2
`
`11-13
`
`§103(a) Prior Art Basis
`TS 25.321 v3.6.0 (2000-12), R2-010182
`and TS 25.302 v3.6.0 (2000-09)
`US 6,850,540 (Peisa)
`
`
`
`The earliest proclaimed priority date of the ’487 Patent is May 21,
`
`2001. As shown below, each reference pre-dates this date and qualifies
`
`as prior art at least under the bases set forth below. See also Bishop,
`
`§§II-VII.
`
`
`
`
`
`4
`
`
`
`
`
`Reference
`TS 25.321 v3.6.0 (2000-12)
`TS 25.302 v3.6.0 (2000-09)
`R2-010182
`US 6,850,540 (Peisa)
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`Public Availability Date Prior Art §
`December 10, 2000
`102(a)
`October 16, 2000
`102(a)
`January 23, 2001
`102(a)
`February 1, 2005 (priority)
`102(e)
`date February 25, 2000)
`
`
`
`III. GROUNDS FOR STANDING
`Petitioner certifies that the ’487 Patent is available for IPR.
`
`Petitioner is not barred or estopped. This petition is being filed within
`
`one month of the institution of IPR2019-00252, and is being
`
`accompanied by a motion for joinder with that IPR.
`
`IV. OVERVIEW OF THE ’487 PATENT AND PRIOR ART
`
`’487 Patent Overview
`A.
`The ’487 Patent relates to the Universal Mobile
`
`Telecommunications System (UMTS) radio network standards specified
`by the 3rd Generation Partnership Project (3GPP), describing a wireless
`communications network with a radio network controller (RNC) that
`
`exchanges data with a plurality of terminals, such as mobile stations,
`
`over communication links. See EX-1001, 1:9-12, 4:65-6:8 and FIG. 1; see
`
`also Buehrer, ¶¶27-58.
`
`
`
`5
`
`
`
`
`
`Explaining the exchange of data between the RNC and the
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`terminals with respect to a 3GPP UMTS network protocol architecture,
`
`the ’487 Patent describes that a plurality of logical channels at the data
`
`connection layer (which includes radio link control (RLC) and medium
`
`access control (MAC) layers)—carrying higher-layer application data—
`
`are mapped to a plurality of transport channels that carry data from
`
`the MAC layer to the physical layer. The data received by the logical
`
`channels is in the form of RLC packet units, which are mapped to
`
`transport blocks by the MAC layer for transmission over the transport
`
`channels between the RNC and the terminals. See EX-1001, 6:9-38,
`
`FIG. 2 (reproduced below, showing transport channels (12), logical
`
`channels (13) and application data (14)); see also Id., 1:9-28 and
`Buehrer, ¶¶50-52.1 The patent explains that the MAC layer selects a
`
`
`1 The ’487 Patent discloses logic channels. A POSITA would have
`
`understood that these logic channels refer to logical channels, which is
`
`a term of art that is used in the 3GPP technical specifications,
`
`including TS 25.302 version 3.6.0 cited by the patent. See EX-1009, §9,
`
`p. 32; see also EX-1007, §4.3, pp. 15-17, and Buehrer, ¶52.
`
`
`
`6
`
`
`
`
`suitable transport format combination (TFC), which represents a
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`combination of transport formats and describes “how the transport
`
`channels are multiplexed into a physical channel in the physical layer.”
`
`EX-1001, 6:38-58, 1:15-28.
`
`
`
`’487 Patent, FIG. 2
`
`The ’487 Patent notes that its objective is “to provide a network
`
`which comprises an optimized selection process for selecting a suitable
`
`transport format combination.” Id., 1:29-31. The patent purportedly
`
`achieves this objective by means of a network in which a plurality of
`
`logical channels is associated with a plurality of transport channels,
`
`where a selection algorithm is provided for selecting the transport
`
`format combinations allocated to the transport channels, wherein “the
`
`7
`
`
`
`
`
`
`
`
`
`
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`selection of the transport format combinations is carried out while
`
`maintaining a minimum bit rate applicable to the respective logic[al]
`
`channel.” Id., 1:32-60.
`
`Elaborating on the requirement for the minimum bit rate
`
`proposal, the patent discloses that the purported invention relies on
`
`“the idea of integrating into the selection algorithm for selecting a
`
`suitable or optimum transport format combination the condition that a
`
`minimum bit rate can be guaranteed suitable for the respective logic
`
`channels,” where the requirement is such that “it is attempted as
`
`much as possible in the selection of the TFC to maintain the
`
`minimum bit rate,” but “TFCs may alternatively be chosen which fall
`
`below the minimum bit rate.” Id., 1:61-2:21. See also Buehrer, ¶¶53-
`
`58.
`
`’487 Patent Prosecution History Summary
`B.
`The ’487 Patent issued on January 23, 2007, from U.S.
`
`Application No. 10/151,087, filed on May 20, 2002. See EX-1004, 1.
`
`During prosecution of the application, the Examiner rejected the
`
`original claims in the first office action, finding them anticipated by
`
`prior art. Id., 31-37. In response, the Applicant amended some
`
`
`
`8
`
`
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`claims, including, for claim 1, only the last limitation—that recited
`
`the purported novel feature—to require the selection algorithm to use
`
`a “minimum bit rate criteria,” instead of the original requirement of a
`
`“minimum bit rate.” Id., 22-27. In the accompanying remarks, the
`
`Applicant did not dispute the Examiner’s finding that most limitations
`
`of the independent claims, including claim 1, were anticipated by prior
`
`art, but argued that the prior art:
`
`fails to teach or imply the limitation of “wherein the
`selection algorithm uses a minimum bit rate criteria
`applicable to the respective logic channel,” as recited in
`claim 1.
`
`Id., 28-30.
`
`The Examiner subsequently allowed the claims, agreeing with the
`
`
`
`
`
`Applicant’s argument in noting that “the prior art of record does not
`
`teach wherein the selection algorithm uses a minimum bit rate criteria
`
`applicable to the respective logic channel.” Id., 7-12. However, as
`
`discussed below, this purported novel feature was well known in the
`
`art, as shown, for example, by R2-010182 and Peisa. See Buehrer,
`
`¶¶59-60.
`
`
`
`9
`
`
`
`
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`C. TS25.321
`3GPP TS 25.321 V3.6.0 is a technical specification (TS) from the
`
`3GPP Technical Specifications Group Radio Access Network (TSG
`
`RAN) tasked with specifying Layers 2 and 3 of the Radio Access
`
`interface for UMTS. See TS25.321, Title, p. 2, and Buehrer, ¶62.
`
`TS25.321 describes the MAC protocol specification for a UMTS
`
`network, e.g., the wireless network described by the ’487 Patent. See
`
`TS25.321, Keywords, p. 2; see also id., §§2 and 3, pp. 6-7 and Buehrer,
`
`¶¶63-64. TS25.321 was publicly available on the 3GPP file server no
`
`later than December 10, 2000, qualifying as prior art for the ’487
`
`Patent under pre-AIA 35 USC §102(a). See Bishop, §§V, VII; see also
`
`Nokia Solutions et al. v Huawei Technologies Co. Ltd., IPR2017-00660,
`
`Paper 8, 11-14. A later version—3.7.0—of TS25.321 was disclosed by
`
`the Applicant, but not substantively considered, during prosecution of
`
`the application. See EX-1004, 38, 125.2
`
`
`2 Applicant’s disclosure erroneously noted the publication month of TS
`
`25.321 v3.7.0 as 2000-03, but the correct month is 2001-03. See EX-
`
`1010, Versions.
`
`
`
`10
`
`
`
`
`
`Being a technical specification from a standards-setting
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`organization, TS25.321 provides a detailed description of the MAC
`
`layer of the network protocol architecture implemented by devices in a
`
`UMTS network, e.g., by individual user terminals, such as mobile
`
`stations (referred to as user equipments (UE) by the standard), and
`
`network devices in the wireless access network, such as RNCs in the
`
`UMTS Terrestrial Radio Access Network (UTRAN). See Buehrer, ¶64.
`
`The description includes specification of MAC layer traffic and the
`
`communications channels between UEs and RNCs. Id. In doing so,
`
`TS25.321 teaches most of the features of the Challenged Claims, as
`
`discussed in greater detail in the following sections, including, for
`
`independent claims 1 and 12, most limitations that the Applicant did
`
`not dispute were taught by prior art. See id.¸¶¶68-69.
`
`To illustrate, TS25.321 discloses that the MAC is connected to the
`
`lower physical layer (layer 1) and higher layers, RLC and radio
`
`resource control (RRC), providing data transfer services between MAC
`
`and RLC using logical channels, which are mapped to transport
`
`channels operated between the MAC and physical layers. See, e.g.,
`
`TS25.321, §§4.2.3-4.3.3, pp. 9-17, §8, p. 19, and FIG. 4.2.3.1 (showing
`
`
`
`11
`
`
`
`
`the UE side MAC architecture, reproduced below). See also Buehrer,
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`¶¶65-66.
`
`
`
`TS25.321 FIG. 4.2.3.1 (annotated)
`TS25.321 further discloses that the MAC performs selection of
`
`
`
`transport formats (TFs) and TFCs for the transport channels. See, e.g.,
`
`TS25.321, §§4.2.3.1-4.2.4.1, pp. 10-13, §6.1, p. 17. In particular,
`
`TS25.321 describes a detailed algorithm for “[t]ransport format
`
`combination selection in UE,” which is based on the “priorities between
`
`logical channels” and is used “each time a TFC selection is performed.”
`
`Id., §11.4, pp. 38-39; see also Buehrer, ¶67. As discussed below, a
`
`modified version of this algorithm that was proposed by R2-010182 fully
`
`
`
`12
`
`
`
`
`discloses the purported novel feature of the TFC selection algorithm
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`claimed in the ’487 Patent.
`
`D. R2-010182
`R2-010182, which is a discussion paper with an attached draft
`
`change request for TS25.321, 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. See Bishop, §§IV, VII; see also Nokia Solutions,
`
`IPR2017-00660, Paper 8, 11-14. R2- 010182 accordingly qualifies as
`
`prior art for the ’487 Patent under pre-AIA 35 USC §102(a).
`
`Referring to the TFC selection algorithm described in TS25.321
`
`§11.4, see supra §IV.C, R2-010182 notes that this algorithm “is not
`
`satisfying because of its absolute priority scheme,” since it could lead to
`
`“exclusion of some logical channels for transmission in case some TFC
`
`become[s] [i]nvalid.” R2-010182, Discussion, p. 1. To address the
`
`supposed drawbacks that the authors of R2-010182 perceived in
`
`TS25.321’s TFC selection algorithm, R2- 010182 proposed modifying
`
`the algorithm by adding three new parameters “to express accurately
`
`the needs of different applications in term of bit rate.” Id., 2. The
`
`
`
`13
`
`
`
`
`parameters included: a minimum bit rate criterion, “MinGBr : Min
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`guarant[e]ed bit rate,” which “is the basic needs of the logical channel”;
`
`and maximum bit rate, “MaxBr : Max bit rate,” which represented “the
`
`nominal needs of the logical channel.” Id. See also Buehrer, ¶¶70-71.
`
`The modified TFC selection algorithm proposed by R2-010182 added, to
`
`TS25.321’s existing algorithm, several steps that relied on the new
`
`parameters, thereby replacing the absolute priority scheme of
`
`TS25.321’s algorithm with a relative priority scheme in the modified
`
`algorithm that relied on the MinGBr and MaxBr parameters See R2-
`
`010182, 2; see also Buehrer, ¶72.
`
`R2-010182 included a change request that showed the precise
`
`changes it suggested to the existing TFC selection algorithm
`
`described in §11.4 of TS25.321. R2-010182, 4. The change request
`
`identified the suggested changes to the actual description of §11.4 of
`
`TS25.321, highlighting the changes with additions and deletions, as
`
`shown below.
`
`
`
`
`
`
`14
`
`
`
`
`
`
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`R2-010182, CR page 5
`
`
`The change request also proposed updating the rules—presented
`
`
`
`in pseudocode format—for TS25.321’s TFC selection algorithm, that
`
`would require consideration of a minimum bit rate criteria. Id. (adding
`
`a new step 7 that selected TFCs such that “MinGBr is gu[a]ranteed”).
`
`R2-010182’s proposed change to TS25.321’s TFC selection
`
`algorithm reads precisely on the purported novelty of the ’487 patent,
`
`
`
`15
`
`
`
`
`namely that the selection algorithm “for selecting the transport format
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`combinations” “uses a minimum bit rate criteria applicable to the
`
`respective logic channel,” as recited in claim 1. See Buehrer, ¶¶73-75,
`
`85. This is discussed in greater detail below.
`
`Given the close connection between TS25.321 and R2-010182, a
`person of ordinary skill in the art (POSITA)3 would have found it
`
`obvious to combine R2-010182 with TS25.321. R2-010182 explicitly
`
`notes that it is a change request (CR) for TS25.321. See, e.g., id., p. 4
`
`(noting, in the fields of the Change Request form “CR-Form-v3,” “25.321
`
`CR” with “Current version: 3.6.0.”). See also id., CR pp. 5-6 (indicating,
`
`in the header fields, that it is for “3GPP TS 25.321 v3.6.0 (2000-12)”).
`
`Indeed, in the Change Request section of the document, R2-010182
`
`copies verbatim §11.4 of TS25.321, marking the TFC selection
`
`algorithm in that section to show changes proposed by R2-010182.
`
`See id. A POSITA with knowledge of TS25.321 and considering
`
`possible limitations to its contents, such as the TFC algorithm, would
`
`have looked to routine 3GPP contributions (and change requests) like
`
`R2-010182. See Buehrer, ¶86. Upon learning about R2- 010182,
`
`
`3 See Buehrer, ¶¶24-26.
`
`
`
`16
`
`
`
`
`POSITA would have understood that R2-010182 applies directly to
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`TS25.321, and suggests improvements “to solve the problems
`
`encountered in the absolute priority scheme” of TS25.321’s TFC
`
`selection algorithm.” R2-010182, 2. A POSITA thus would have read
`
`R2-010182 in the context of TS25.321. See Buehrer, ¶87.
`
`E. TS25.302
`3GPP TS 25.302 V3.6.0 is another technical specification from
`
`3GPP TSG RAN, describing the services provided by the physical
`
`layer to upper layers of devices in a UMTS network. See TS25.302,
`
`Keywords, p. 1, §1, p. 7; see also Buehrer, ¶88. TS25.302 was publicly
`
`available on the 3GPP file server no later than October 16, 2000,
`
`qualifying as prior art for the ’487 Patent under pre-AIA 35 USC
`
`§102(a). See Bishop, §§VI-VII. A later version—3.7.0—of the TS was
`
`disclosed by the Applicant, but not substantively considered, during
`
`the prosecution of the application. See EX-1004, 38, 125.
`
`Just as TS25.321 specifies the MAC layer architecture standard
`
`for UMTS networks, TS25.302 provides a detailed technical
`
`specification for the data transport services provided by the physical
`
`layer to the higher layers, noting that the “physical layer (layer 1) is
`
`
`
`17
`
`
`
`
`the lowest layer in the OSI Reference Model and it supports all
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`functions required for the transmission of bit streams on the physical
`
`medium,” interfacing the MAC (layer 2) and RRC (layer 3).
`
`TS25.302, §§4-4.2, p. 9. See also Buehrer, ¶89.
`
`In greater detail, TS25.302 describes the attributes and
`
`configurations of the physical layer that are referenced in other 3GPP
`
`technical standards, e.g., TS25.321. For example, TS25.302 notes that
`
`the physical layer “offers data transport services to higher layers …
`
`through the use of transport channels via the MAC sub-layer,” where
`
`“[t]he characteristics of a transport channel are defined by its transport
`
`format (or format set)” that specifies “the physical layer processing to
`
`be applied to the transport channel in question.” TS25.302, §5.1, p. 10.
`
`Explaining that “Layer 2 [(MAC)] is responsible for the mapping of data
`
`onto L1 [(physical layer)] via the L1/L2 interface that is formed by the
`
`transport channels,” TS25.302 defines the attributes of transport
`
`channels that are used by TS25.321, such as transport block, transport
`
`format and TFC. Id., §§7.1-7.1.11, pp. 16-20. In doing so, TS25.302
`
`discloses several features of the Challenged Claims, e.g., by disclosing
`
`that the Transport Format Combination Set for the transport channels
`
`
`
`18
`
`
`
`
`in the physical layer includes only the allowed or valid TFCs, as recited
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`in claim 1. Id., §7.1.9, p. 19. See also Buehrer, ¶¶90-91.
`
`A POSITA with knowledge of TS25.321 and TS25.302 would have
`
`been motivated to combine the two references. The two technical
`
`specifications 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. See Buehrer, ¶92; see also supra §§IV.C, IV.E. The
`
`specifications in 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. Indeed, TS25.321 cites
`
`toTS25.302, noting that the latter “contain provisions which, through
`
`reference in [TS25.321] text, constitute provisions of the present
`
`[TS25.321].” TS25.321, §2, p. 6. Similarly, TS25.302 refers to several
`
`features related to the MAC layer, such as logical channels, and
`
`mapping of RLC-PDUs to transport blocks, which are described in
`
`detail in TS25.321. See, e.g., TS25.302, §5.3, p. 11, §9, p. 32. See also
`
`Buehrer, ¶¶92-93.
`
`
`
`19
`
`
`
`
`
`A POSITA looking to understand a UMTS network would have
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`looked at the various 3GPP technical specifications for UMTS. In doing
`
`so, the POSITA would have looked at TS25.321 and TS25.302 and
`
`readily noted that they are complementary technical specifications
`
`directed towards adjacent layers of the UMTS protocol stack, with
`
`TS25.321 relying on many features and services that are described in
`
`TS25.302. The two references are also contemporaneous technical
`
`specifications—created within months of each other—and authored by
`
`the same standards-setting organization, 3GPP. Accordingly, as Prof.
`
`Buehrer notes, 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, a POSITA would have been motivated to look at
`
`the two references together, combining their teachings. See id.
`
`As discussed in greater detail below, the combination of
`
`TS25.321 with R2-010182 and TS25.302 reads on all the features of
`
`the Challenged Claims. See id., ¶¶101, 103.
`
`F. Peisa
`Peisa is U.S. Patent No. 6,850,540, which discloses packet
`
`scheduling for data flows by the MAC layer in a UMTS network. See
`
`
`
`20
`
`
`
`
`Peisa, Abstract; see also Buehrer, ¶¶94-95. Having a U.S. priority date
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`of February 25, 2000, Peisa published as a patent on February 1, 2005,
`
`thereby qualifying as prior art for the ’487 Patent under pre-AIA 35
`
`USC §102(e).
`
`During prosecution of the application for the ’487 Patent, the
`
`Examiner had applied selected portions of Peisa to reject the claims as
`
`anticipated. See EX-1004, 31-39. The Applicant’s response narrowly
`
`focused on col. 10, lines 1-12 of Peisa, which was applied to the
`
`purportedly novel feature, arguing that this portion failed to disclose or
`
`suggest the corresponding features. See id., 22- 30; see also supra
`
`§IV.B. This narrow argument was sufficient to persuade the Examiner
`
`to allow the application. See id. However, different portions of Peisa
`
`are considered in this Petition, which, in combination with other
`
`references, clearly render the ’487 Patent claims obvious, as discussed
`
`in detail below and as noted by Prof. Buehrer. See Buehrer, ¶60.
`
`Indeed, the record does not indicate that the Examiner considered the
`
`portions of Peisa cited in this Petition, which are more relevant to the
`
`purportedly novel feature of the ’487 patent than that cited and
`
`considered during original prosecution. This lack of consideration is
`
`
`
`21
`
`
`
`
`corroborated by the Examiner’s reliance on inherency to make his case
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`based on Peisa’s col. 10, lines 1-12 despite express disclosure supporting
`
`his argument being readily available elsewhere in Peisa’s disclosure.
`
`See EX-1004, 31-39. Petitioner respectfully submits that the
`
`arguments advanced herein with respect to the Peisa grounds are,
`
`therefore, new and requests that the Board consider these arguments
`
`on their merits. See, e.g., Becton et al. v. B. Braun Melsungen AG,
`
`IPR2017-01586, Paper 8, 22-28; see also Apple Inc., et al. v. Evolved
`
`Wireless LLC, IPR2016-01209, Paper 7, 14-16.
`
`Similar to the ’487 Patent, Peisa discloses “scheduling packets of
`
`data/informational flows having differing priority levels” in a UMTS
`
`network. Peisa, 1:26-32. Peisa’s invention describes a MAC layer of a
`
`UE or an RNC in a UMTS network that “schedules packet
`
`transmission of various data flows” by selecting valid TFCs from a TFC
`
`set “based on guaranteed rate transmission rates,” among other
`
`criteria. Id., 2:40-67; see also id., 6:20-9:56, 14:6-20:31. In some
`
`implementations, the MAC layer also uses backlog memories to satisfy
`
`“previously unmet guaranteed[] transmission rates.” Id., 2:48-63. See
`
`also Buehrer, ¶¶95-97.
`
`
`
`22
`
`
`
`
`
`In greater detail, Peisa describes that, in some implementations,
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`the MAC layer schedules transmission of user and signaling data of
`
`higher layer flows on transport channels, using algorithms that select a
`
`TFC from the set of permitted TFCs of the transport channels based on
`
`several criteria, which include criteria for choosing TFCs that provide
`
`logical channels with at least their guaranteed bit rates (i.e., minimum
`
`bit rate criteria). See, e.g., Peisa, 9:1-30, 10:29-11:50, 17:48-20:30,
`
`FIGS. 4, 8. Peisa explains that the user and signaling data of flows is
`
`carried by Radio Access Bearers (RABs) allocated to the UEs, where the
`
`RABs are mapped to logical channels in the RLC layer. See, e.g., Peisa,
`
`4:11- 46, 6:41-50. The MAC receives the flow data from the RLC layer
`
`as RLC PDUs over logical channels, and maps these data into transport
`
`blocks of several transport channels in the physical layer. See, e.g., id.,
`
`6:50-7:18. The MAC maps the data into transport blocks using
`
`transport formats of the transport channels that are specified by the
`
`TFC selected according to the disclosed algorithms. See, e.g., id., 7:25-
`
`60. Peisa notes that these schemes are realized by both the UEs and
`
`the RNCs in the UMTS network. See, e.g., id., 9:30-34, 18:17-18. See
`
`also Buehrer, ¶¶98-99.
`
`
`
`23
`
`
`
`
`
`Peisa reads on all the features of claims 11-13, as demonstrated
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`below. See id., ¶¶101, 236.
`
`V. CLAIM CONSTRUCTION
`The challenged claims are unpatentable when construed in
`
`accordance with the ordinary and customary meaning as understood by
`
`one of ordinary skill in the art and the prosecution history pertaining to
`
`the patent or in accordance with their broadest reasonable
`
`interpretation. Rule 42.100(b); Phillips v. AWH Corp., 415 F.3d 1303
`
`(Fed. Cir. 2005) (en banc). No terms require additional construction
`
`beyond their ordinary and customary meaning, as applied herein. See
`
`also Buehrer, ¶61.
`
`VI. DETAILED EXPLANATION OF GROUNDS
`
`As detailed below, this Petition shows a reasonable likelihood
`
`that the Challenged Claims are unpatentable. The grounds
`
`discussed herein incorporate the explanations set forth in §IV.
`
`A. Ground 1: TS25.321 in view of R2-010182 and
`
`TS25.302 renders claims 11-13 obvious
`Petitioner proposes, as Ground 1, that claims 11-13 are obvious
`
`over the combination of TS25.321, R2-010182 and TS25.302. These
`
`
`
`24
`
`
`
`
`references are introduced, and their combination explained, above in
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`§§IV.C-IV.E, and in the following sections.
`
`None of TS25.321, R2-010182 or TS25.302 was considered by
`
`the Examiner during prosecution of ’487 Patent. See supra §IV.B.
`
`As such, Petitioner respectfully submits that the arguments
`
`presented in this Section are new.
`
`[13 Pre] A method of controlling a network with a first plurality
`
`of logic channels with which is associated a second
`
`plurality of transport channels,
`To the extent the preamble of claim 13 is considered limiting,
`
`TS25.321 in view of R2-010182 and TS25.302 teaches this limitation.
`
`To illustrate, TS25.321 operating system directed towards radio
`
`access networks for mobile communications. TS25.321’s title notes
`
`that it is a technical specification for the MAC protocol for “radio
`
`access networks.” TS25.321, Title (emphasis added); see also id., §1,
`
`p. 6, and supra §IV.C. A POSITA would have understood that
`
`TS25.321 describes the MAC protocol specification of the network
`
`protocol layer architecture for a UMTS Terrestrial Radio Access
`
`Network (UTRAN). See TS25.321, Keywords, p. 2, §§2 and 3, pp. 6-
`
`7; see also Buehrer, ¶179.
`
`
`
`25
`
`
`
`
`
`Noting that its objective is to “describe the MAC architecture and
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`the different MAC entities from a functional point of view,” TS25.321
`
`discloses that the network includes “user equipments” and “radio
`
`network controllers,” e.g., by describing the “traffic related
`
`architecture” of the MAC entities (e.g., MAC-c/sh and MAC-d) of the
`
`“UE,” where the “UE[:] User Equipment”; and also the “traffic related
`
`architecture” of the MAC entities for the UTRAN side of the network,
`
`which are “located in the controlling RNC” and “in the serving RNC,”
`
`where “RNC[:] Radio Network Controller.” TS25.321, §§3.2, 4.1, 4.2.4,
`
`pp. 7-12. TS25.321 further teaches that there are multiple UEs in the
`
`network, e.g., by noting that the functions of the MAC include
`
`“identification of UEs.” Id., §6.1, p. 17 (emphasis added). See also
`
`Buehrer, ¶180.
`
`TS25.321 further discloses that the MAC at the UE performs
`
`various functions to control the UMTS network. For example, the
`
`MAC-c/sh entity at the UE “controls access to common transport
`
`channels” while the MAC-d entity at the UE “controls access to
`
`dedicated transport channels.” Id., §4.2.3, p. 9 (emphasis added).
`
`Describing the functionality of the “MAC-c/sh entity – UE Side” in
`
`
`
`26
`
`
`
`
`greater detail, TS25.321 notes that the functionality includes: “TCTF
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
`
`MUX[:] this function represents the handling (insertion for uplink
`
`channels and detection and deletion for downlink channels) of the
`
`TCTF field in the MAC header, and the respective mapping between
`
`logical and transport channels”; “scheduling /priority handling[]
`
`functionality [that] is used to transmit the information received from
`
`MAC-d on RACH and CPCH based on logical channel priorities”; and
`
`“TFC selection[:] transport format and transport format combination
`
`selection according to the transport format combination set (or
`
`transport format combination subset) configured by RRC.” Id., §4.2.3.1,
`
`pp. 9-10 and FIG. 4.2.3.1.1 (reproduced below); see also id., §4.2.3.2, pp.
`
`11-12 and FIG. 4.2.3.2.1 (describing functionality of the “MAC-d entity
`
`– UE Side” in greater detail). See Buehrer, ¶181.
`
`
`
`
`
`
`
`27
`
`
`
`
`
`
`
`
`
`Petition for Inter Partes Review of
`U.S. Patent No. 7,167,487
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
