throbber

`
`
`
`
`
`
`
`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`DELL INC.,
`ZTE (USA), INC.,
`and
`ZTE CORPORATION,
`Petitioners
`
`v.
`
`3G LICENSING S.A.,
`Patent Owner.
`
`
`Case No. IPR2020-01157
`
`U.S. Patent No. 7,274,933
`
`
`
`Petitioner Dell Inc.’s Reply to Patent Owner’s Response
`
`
`
`
`
`

`

`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`TABLE OF CONTENTS
`
`I.
`II.
`
`V.
`
`Page
`INTRODUCTION ........................................................................................... 1
`CLAIM CONSTRUCTION ............................................................................ 2
`A.
`“Home Network” ................................................................................... 2
`B.
`“Home Network Display Name”........................................................... 3
`III. GROUNDS 1–4: OBVIOUSNESS OVER MCELWAIN ALONE OR
`IN COMBINATION WITH UCHIDA, HICKS, OR BOTH .................................... 4
`A. Grounds 1–4 Disclose Displaying a Home Network Name ................. 5
`1. McElwain and Hicks Disclose Displaying a Home
`Network Name under the Board’s Construction and
`Patent Owner’s Unduly Narrow Construction ............................ 6
`2. McElwain and Uchida Disclose Displaying a Home
`Network Name When a User Is on a Network With a
`Contractual Relationship with the User’s Service
`Provider ....................................................................................... 9
`Grounds 1–4 Disclose the Use of Multiple MCC/MNC Pairs
`Corresponding to the Home Networks of the HPLMN List ...............12
`1. McElwain and Uchida Disclose an HPLMN List in a
`CDMA and GSM Environment ................................................13
`2. McElwain, Uchida, and Hicks Disclose to a Person of
`Ordinary Skill in the Art an HPLMN List That Is
`Backwards Compatible .............................................................14
`IV. GROUND 5: OBVIOUSNESS OVER THE 3GPP STANDARDS
`AND MCELWAIN ..................................................................................................15
`A.
`The 3GPP Standards Disclose the Use of Multiple MCC/MNC
`Pairs Corresponding to the Home Networks of the HPLMN List ......16
`SECONDARY CONSIDERATIONS ...........................................................18
`A.
`Long-Felt Need Not Met by ’933 Patent .............................................18
`B.
`Acceptance in Industry Not Attributable to ’933 Patent .....................19
`VI. CONCLUSION ..............................................................................................20
`
`
`B.
`
`
`
`i
`
`
`
`

`

`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`TABLE OF AUTHORITIES
`
`Beckman Instruments, Inc. v. LKB Produkter AB,
`892 F.2d 1547 (Fed. Cir. 1989) ..................................................................... 17
`CCS Fitness, Inc. v. Brunswick Corp.,
`288 F.3d 1359 (Fed. Cir. 2002) ....................................................................... 3
`Kennametal, Inc. v. Ingersoll Cutting Tool Co.,
`780 F.3d 1376 (Fed. Cir. 2015) .............................................................. 17, 19
`Lectrosonics, Inc. v. Zaxcom, Inc.,
`No. IPR2018-01129, 2020 WL 407146 (P.T.A.B. Jan. 24, 2020) ............... 20
`Superguide Corp. v. DirecTV Enters., Inc.,
`358 F.3d 870 (Fed. Cir. 2004) ........................................................................ 3
`W. Union Co. v. MoneyGram Payment Sys., Inc.,
`626 F.3d 1361 (Fed. Cir. 2010) .................................................................... 15
`
`
`
`
`
`ii
`
`
`
`

`

`
`
`
`
`
`Exhibit No.
`1001
`1002
`1003
`1004
`1005
`1006
`1007
`
`1008
`
`1009
`
`1010
`1011
`
`1012
`
`1013
`
`1014
`
`1015
`
`1016
`1017
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`PETITIONER’S EXHIBIT LIST
`
`
`Description
`U.S. Patent No. 7,274,933 (“the ’933 patent”)
`Copy of Prosecution History of the ’933 patent
`Declaration of Dr. Apostolos Kakaes
`U.S. Patent Appl. Publ. No. 2003/0022689 (“McElwain”)
`U.S. Patent Appl. Publ. No. 2004/0204136 (“Uchida”)
`U.S. Patent No. 7,027,813 (“Hicks”)
`3rd Generation Partnership Project; Technical Specification
`Group Core Network; NAS Functions related to Mobile Station
`(MS) in idle mode (Release 5) (3GPP TS 23.122 V5.2.0)
`(“TS-23.122”)
`3rd Generation Partnership Project; Technical Specification
`Group Services and System Aspects – Service aspects; Service
`principles (Release 5) (3GPP TS 22.101 V5.8.0) (“TS-22.101”)
`3rd Generation Partnership Project; Technical Specification
`Group Terminals; Characteristics of the USIM Application
`(Release 5) (3GPP TS 31.102 V5.3.0) (“TS-31.102”)
`Declaration of Craig Bishop
`Complaint for Patent Infringement, No. 1:19-cv-01247-LPS
`(D. Del. July 1, 2019)
`Complaint for Patent Infringement, No. 3:19-cv-01694 (N.D.
`Tex. July 15, 2019)
`Amended Complaint for Patent Infringement, No. 1:19-cv-
`01140-MN (D. Del. July 15, 2019)
`Third Amended Complaint for Patent Infringement, No. 1:19-
`cv-01144-MN (D. Del. Feb. 28, 2020)
`Amended Complaint for Patent Infringement, No. 1:20-cv-
`20813 (S.D. Fl. Mar. 25, 2020)
`EIA/TIA-553 Standard (AMPS)
`Excerpts from EIA/TIA/IS-54 Standard (Digital AMPS)
`
`iii
`
`
`
`

`

`
`
`
`
`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`Exhibit No.
`1018
`1019
`1020
`1021
`
`1022
`
`1023
`
`1024
`1025
`1026
`1027
`1028
`1029
`1030
`
`1031
`1032
`
`Description
`Excerpts from TIA/EIA/136.1 Standard
`Excerpts from TIA/EIA/IS-136.2-A Standard
`Excerpts from TIA/EIA/IS-95 Standard
`Excerpts from T. Halonen et al., “GSM, GPRS and EDGE
`Performance: Evolution Towards 3G/UMTS” (2d ed. Wiley
`2003)
`3rd Generation Partnership Project; Technical Specification
`Group Terminals Specification of the Subscriber Identity
`Module – Mobile Equipment (SIM - ME) interface
`(Release 1999) (3GPP TS 11.11 V8.6.0) (“TS-11.11”)
`Excerpts from A. Mehrotra, “GSM System Engineering”
`(Artech House 1997)
`U.S. Patent No. 5,950,130 (“the ’130 patent”)
`U.S. Patent No. 5,862,471 (“the ’471 patent”)
`U.S. Patent No. 6,195,532 (“Bamburak”)
`U.S. Patent Appl. Publ. No. 2001/0001875 (“Hirsch”)
`U.S. Patent Appl. Publ. No. 2002/0111180 (“Hogan”)
`Second Declaration of Dr. Apostolos Kakaes
`3rd Generation Partnership Project; Technical Specification
`Group Terminals; Test Specification for ‘C’-language binding
`to (U)SIM API (Release 6) (3GPP TS 34.131 V6.0.0)
`(“TS-34.131”)
`Deposition of Dr. Apostolos Kakaes (May 10, 2021)
`Third Declaration of Dr. Apostolos Kakaes
`
`iv
`
`
`
`

`

`
`
`
`I.
`
`INTRODUCTION
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`Dell Inc. (“Dell” or “Petitioner”) hereby submits this reply pursuant to
`
`37 C.F.R. § 42.23 and seeks cancellation of claims 1–4, 6–9, 11–14, and 19
`
`(the “Challenged Claims”) of the ’933 patent because they are unpatentable under
`
`35 U.S.C. § 103.
`
`The ’933 patent relates to displaying network names on mobile phones. The
`
`patent purports to solve customer confusion regarding roaming charges. As cellular
`
`technology evolved, many service providers expanded by acquiring new networks
`
`or entered into business relationships with other providers so that customers were
`
`not charged roaming fees when moving among partnering networks. The purported
`
`solution of the patent is simple: use an “HPLMN list” with any network considered
`
`a “home” network—including networks owned by the same provider and networks
`
`treated as “home” networks based on a business relationship—and display the same
`
`network name when connected to any of these “home” networks.
`
`However, the purported invention of the ’933 patent had already been
`
`disclosed in the prior art. Specifically, Petitioner presented five obviousness
`
`grounds demonstrating that all Challenged Claims are unpatentable. See generally
`
`Paper No. 1. Grounds 1–4 presented obviousness based on McElwain alone or in
`
`combination with Uchida, Hicks, or both. Ground 5 presented obviousness based
`
`
`
`1
`
`
`
`

`

`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`on the 3GPP Standards and McElwain. See id. The Board instituted inter partes
`
`review of all claims challenged in the Petition. See generally Paper No. 12.
`
`In its Response, Patent Owner seeks to avoid these invalidity grounds by
`
`advancing little more than the same unduly narrow claim construction arguments
`
`and strained interpretations of the prior art that the Board already considered and
`
`rejected in the Institution Decision. As discussed below, none of these arguments
`
`are supported by the teachings of the patent, the disclosure of prior art, or the
`
`knowledge of one of ordinary skill in the art. Because Patent Owner has failed to
`
`rebut Petitioner’s showing that the Challenged Claims would have been obvious
`
`based on the Grounds presented in the Petition, Petitioner requests that all the
`
`Challenged Claims of the ’933 patent be cancelled.
`
`II. CLAIM CONSTRUCTION
`“Home Network”
`A.
`
`The Board construed “home network” to include “networks operated by a
`
`user’s cellular provider, including networks acquired by that provider, as well as
`
`networks with whom the provider has a contractual relationship that would obviate
`
`roaming charges.” Paper No. 12 at 10–11. Neither the Petitioner nor Patent Owner
`
`disputes the Board’s construction. See Paper No. 25 at 8.
`
`
`
`2
`
`
`
`

`

`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`B.
`
`“Home Network Display Name”
`
`The Board construed “home network display name” to mean “a name string
`
`used for the mobile station’s display for all home-related networks,” that “may, but
`
`need not, include the name of the network provider.” Paper No. 12 at 12. Petitioner
`
`agrees with the Board’s construction of this term.
`
`Patent Owner disagrees and attempts to limit the construction to require “the
`
`actual names of such [service] providers.” Paper No. 25 at 9. However, as the Board
`
`found in its Institution Decision, there is nothing in the ’933 patent that limits the
`
`home network display name to only actual names of service providers. See Paper
`
`No. 12 at 12. As the Board noted, the ’933 patent states that the home network
`
`display name is the “name string used for mobile station’s display for all home-
`
`related networks.” See Ex. 1001 at 12:57–60, 13:37–39. Additionally, while the
`
`specification provides exemplary network display names such as “T-Mobile” and
`
`“AT&T Wireless,” the use of “e.g.” to introduce these indicates that they are merely
`
`examples “and is not limiting or required.” See Paper No. 12 at 12; see also
`
`Superguide Corp. v. DirecTV Enters., Inc., 358 F.3d 870, 875 (Fed. Cir. 2004); CCS
`
`Fitness, Inc. v. Brunswick Corp., 288 F.3d 1359, 1366 (Fed. Cir. 2002). Patent
`
`Owner could have, but did not, claim a “home service provider name.” Therefore,
`
`Patent Owner’s argument that the home network display name should exclude
`
`“anything other than a network provider name” and require “actual names of such
`
`
`
`3
`
`
`
`

`

`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`service providers” improperly limits the claim to specific embodiments, which is
`
`contrary to the law.
`
`The Board should therefore reject Patent Owner’s proposed construction and
`
`adopt the construction set forth in the Institution Decision. However, as explained
`
`below, even if Patent Owner’s proposed construction were adopted, the Challenged
`
`Claims would nonetheless have been obvious based on the same Grounds.
`
`III. GROUNDS 1–4: OBVIOUSNESS OVER MCELWAIN ALONE OR IN
`COMBINATION WITH UCHIDA, HICKS, OR BOTH
`
`The Petition asserted that the Challenged Claims would have been obvious
`
`over McElwain alone (Ground 1), McElwain and Uchida (Ground 2), McElwain,
`
`Uchida, and Hicks (Ground 3), or McElwain and Hicks (Ground 4). See Paper No. 1
`
`at 10–48. In its Institution Decision, the Board thoroughly analyzed each ground for
`
`each of the Challenged Claims and agreed that Petitioner demonstrated a reasonable
`
`likelihood of prevailing on each ground. See Paper No. 12 at 19–48. Patent Owner’s
`
`Response offers no reason to deviate from this determination.
`
`For these Grounds, Patent Owner challenges only two limitations in its
`
`Response: (1) displaying a “home network display name” recited in claim elements
`
`1[e], 6[g], 11[h], & 19[c]; and (2) use of multiple MCC/MNC pairs in an “HPLMN
`
`list” recited in claim elements 1[c], 6[e], & 11[f]. Patent Owner’s arguments
`
`continue to ignore the express teachings in the prior art references raised by
`
`Petitioner, as well as the knowledge of a person of ordinary skill in the art, as
`
`
`
`4
`
`
`
`

`

`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`described by Petitioner’s expert, Dr. Kakaes. Because these two limitations are
`
`taught and/or rendered obvious in the combinations presented in Grounds 1‒4, and
`
`because Patent Owner does not raise any arguments for any of the other the
`
`remaining claim limitations or any arguments that a person of ordinary skill in the
`
`art would not have been motivated to and successful in combining the references,
`
`the Board should find that all Challenged Claims would have been obvious over the
`
`combinations asserted Grounds 1‒4 in the Petition.
`
`A. Grounds 1–4 Disclose Displaying a Home Network Name
`
`Patent Owner offers two reasons why it believes the limitation is not taught in
`
`the prior art. Neither one has merit. First, Patent Owner argues that McElwain and
`
`Hicks individually fail to teach displaying a home network display name under the
`
`Patent Owner’s overly narrow construction, which requires displaying the actual
`
`name of the service provider. However, Patent Owner fails to argue that the
`
`references do not disclose displaying a home network display name under the
`
`Board’s construction, which simply requires “a name string.” Thus, if the Board’s
`
`construction is adopted, Patent Owner’s arguments necessarily fail. But even if the
`
`Board decides to adopt Patent Owner’s overly narrow construction, the references
`
`disclose this limitation as discussed in more detail below.
`
`Second, Patent Owner argues that McElwain and Uchida individually fail to
`
`teach displaying a home network display name because the references do not account
`
`
`
`5
`
`
`
`

`

`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`for displaying a home network name when a user is on a network that has a
`
`contractual relationship with the user’s service provider. However, Patent Owner
`
`ignores that the Board’s construction of “home network” includes multiple networks
`
`operated by a user’s cellular provider, see Paper No. 12 at 10‒11, and Patent Owner
`
`does not dispute that McElwain and Uchida disclose multiple networks under this
`
`construction. Furthermore, even if the Challenged Claims required using the same
`
`home network name for network with whom the provider has a contractual
`
`relationship, Patent Owner ignores express teachings in the prior art of this exact
`
`arrangement.
`
`1. McElwain and Hicks Disclose Displaying a Home Network
`Name under the Board’s Construction and Patent Owner’s
`Unduly Narrow Construction
`
`McElwain and Hicks each teach displaying a home network display name
`
`under the Board’s construction and even under the Patent Owner’s narrower
`
`construction. Because Patent Owner does not argue that the prior art fails to teach
`
`this limitation under the Board’s construction, if the Board adopts its construction
`
`from the Institution Decision, then Patent Owner’s argument necessarily fails. But
`
`even if the Board decides to adopt Patent Owner’s narrower construction, both
`
`McElwain and Hicks teach displaying a home network name under the narrower
`
`construction.
`
`
`
`6
`
`
`
`

`

`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`McElwain discloses displaying a home network name under Patent Owner’s
`
`narrower construction. As explained in Petitioner’s Reply to Patent Owner’s
`
`Preliminary Response, McElwain discloses displaying the same home network name
`
`for multiple “home” networks, even under Patent Owner’s incorrect claim
`
`construction. See Paper No. 10 at 2‒3. Specifically, McElwain teaches that each
`
`MCC/MNC pair in the Cousin SID list is “identified as in the HOME category.”
`
`Ex. 1004 ¶ 52. As Dr. Kakaes explained, the terms “Cousin,” “Partner,” “Favored,”
`
`and “Neutral” used in the pseudo-code of McElwain would be recognized as
`
`variables. See Ex. 1031 at 100:9–101:15; Ex. 1032 ¶ 17. Additionally, the use of
`
`the “/*” notation indicates that the contents contained within the “/* . . . */” are
`
`commentary and is not what the actual code would read. Ex. 1032 ¶ 17. Thus, a
`
`person of ordinary skill in the art would understand that the actual display name
`
`would not be, for example, “Cousin,” but “Cousin” is simply a variable representing
`
`another name, such as the actual network name. Ex. 1032 ¶¶ 17–18.
`
`Furthermore, the pseudo-code states that the “UI uses own naming
`
`convention,” see Ex. 1004 ¶ 54, indicating these variables are intended to be
`
`customized by the service provider so that it displays whatever the provider wants
`
`to display when the user is on a home network. See Ex. 1031 at 100:9–101:15;
`
`Ex. 1032 ¶ 18. For example, it would have been obvious to a person of ordinary
`
`skill in the art to set Cousin equal to, for example, “AT&T Wireless” (under Patent
`
`
`
`7
`
`
`
`

`

`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`Owner’s proposed construction) or some other name string for home networks
`
`(under the Board’s construction). See Ex. 1032 ¶ 18.
`
`Hicks also teaches displaying a home network display name under Patent
`
`Owner’s construction. Hicks discloses that an OPL file containing multiple PLMNs
`
`that point to an alphanumeric tag in a PNN file; for the PLMNs that point to the first
`
`record in the PNN file, that PLMN is determined to be a “home” network and the
`
`home network name stored in the PNN file is displayed. Ex. 1006 at 2:3–24, 2:56–
`
`3:22, 1:7–29, Figs. 2–3. Hicks further teaches that “the first record of the PNN file
`
`could be for the home networks, and the alpha tag could be ‘Carrier X,’” where
`
`“Carrier X” would be the actual name of the service provider. Id. at 2:19–24;
`
`Ex. 1032 ¶ 23. This express disclosure directly contradicts Patent Owner’s
`
`argument that Hicks simply teaches displaying “Home” or “Roam” and does not
`
`display the actual name of the user’s service provider. Paper No. 25 at 15.
`
`Additionally, a person of ordinary skill in the art would have understood that
`
`the words “Home” and “Roam” as used in Figure 3 of Hicks are variables for a home
`
`network and roaming network. Ex. 1032 ¶ 24. Thus, it would have been within the
`
`knowledge of a person of ordinary skill in the art to configure the “Home”
`
`alphanumeric tag to be an actual service provider name like “AT&T Wireless”
`
`(under Patent Owner’s proposed narrower construction) or some other name string
`
`for home networks (under the Board’s construction). Ex. 1032 ¶ 24. Thus, Hicks
`
`
`
`8
`
`
`
`

`

`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`teaches displaying a home network display name, where the display name is the
`
`name of the actual service provider.
`
`Patent Owner further argues that the short variable names used as examples
`
`in Figure 3 “suggest the PNN file does not have the capability for longer more
`
`descriptive service provider actual names.” Paper No. 25 at 15. This argument is
`
`wholly unsupported by any evidence and contrary to the express teachings of Hicks,
`
`which provides that the alpha tag could be “Carrier X” or “Carrier X Roam.” See
`
`Ex. 1006 at 2:19–24. Patent Owner fails to cite to anything to contradict this express
`
`teaching and support its assertion that the PNN file is not capable of storing longer
`
`names. Indeed, a device’s memory module or SIM card at the time of the patent
`
`would have been more than capable of handling longer names. Ex. 1032 ¶ 25.
`
`2. McElwain and Uchida Disclose Displaying a Home Network
`Name When a User Is on a Network With a Contractual
`Relationship with the User’s Service Provider
`
`Patent Owner argues that the prior art fails to disclose displaying a home
`
`network name when on a network apart from that of the user’s service provider. See
`
`Paper No. 25 at 11‒15. As an initial matter, displaying a home network name when
`
`on a network apart from that of the user’s service provider is not a requirement of
`
`the claims, and thus whether or not the prior art discloses this limitation is irrelevant.
`
`In any event, Patent Owner is wrong as a matter of fact because each of Grounds 1‒
`
`
`
`9
`
`
`
`

`

`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`4 teaches displaying a home network name when a user is on a network with a
`
`contractual relationship with the user’s service provider.
`
`There is no requirement in the claims that an HPLMN list necessarily include
`
`networks apart from those operated by the user’s own service provider. The Board
`
`construed “home network” to include one or both of “networks operated by a user’s
`
`cellular provider, including networks acquired by that provider” and “networks with
`
`whom the provider has a contractual relationship that would obviate roaming
`
`charges.” See Paper 12 at 10‒11. Patent Owner does not dispute that the
`
`combinations in Grounds 1‒4 disclose displaying the same home network name for
`
`multiple networks operated by a user’s cellular provider (for example, where a
`
`provider has multiple of its own network but where there are no networks with whom
`
`the provider has a reciprocal roaming agreement). While the ’933 patent
`
`additionally provides for using the same home network name for networks with
`
`which a provider has a contractual relationship, there is nothing in the claims that
`
`requires an HPLMN list to include these networks with a contractual relationship.
`
`In other words, an HPLMN list with multiple home networks all owned by the same
`
`carrier, such as ones added by virtue of an acquisition, is covered by the Challenged
`
`Claims and is indisputably disclosed in Grounds 1‒4.
`
`In any event, even if Patent Owner is correct that the claims require displaying
`
`a home network name when a user is on a network that has a contractual relationship
`
`
`
`10
`
`
`
`

`

`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`with the user’s service provider, McElwain and Uchida teach and render obvious
`
`that limitation. For example, McElwain expressly teaches that a list of home
`
`networks that may include networks associated with the user’s network via a
`
`“business relationship,” i.e., a contractual relationship. Ex. 1004 ¶ 47. Indeed,
`
`McElwain teaches that the home networks on the Cousin SID list “may each be
`
`associated with a different service provider.” Id. (emphasis added). And a user’s
`
`service provider “will typically have business relationships with a number of
`
`different wireless service providers.” Id. (emphasis added). Thus, contrary to Patent
`
`Owner’s argument, McElwain expressly teaches displaying the user’s service
`
`provider name when on another network.
`
`Finally, even if the Board finds that McElwain does not expressly teach this
`
`limitation under Patent Owner’s erroneous view, it would have been obvious based
`
`on McElwain and/or Uchida. For example, in McElwain, if a network owned by
`
`another service provider had a contractual agreement with the user’s cellular
`
`provider not to charge for roaming, the service provider would simply have to
`
`modify the Cousin SID list in order to account for this change by adding the
`
`MCC/MNC pair of the networks with contractual agreements. Ex. 1032 ¶ 22. A
`
`person of ordinary skill in the art would have understood that modifying the Cousin
`
`SID list in this manner would allow the home network display name to display when
`
`the user is on a network that has a contractual agreement with the user’s service
`
`
`
`11
`
`
`
`

`

`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`provider. Ex. 1032 ¶ 22. Similarly, Uchida teaches that a “Home System Tag” is
`
`the mobile station’s display name for all the networks on the home SID/NID list.
`
`Ex. 1005 ¶¶ 17, 37, Fig. 3A. Like with McElwain, a person of ordinary skill in the
`
`art would have understood that adding service providers that have contractual
`
`agreements with the user’s cellular provider to the Home SID/NID List would allow
`
`it to be associated with the same “Home System Tag.” Ex. 1032 ¶¶ 21–22.
`
`B. Grounds 1–4 Disclose the Use of Multiple MCC/MNC Pairs
`Corresponding to the Home Networks of the HPLMN List
`
`Patent Owner offers two reasons why it believes use of multiple MCC/MNC
`
`pairs in an HPLMN list is not taught in the prior art. Neither one has merit. Patent
`
`Owner first argues that McElwain and Uchida individually fail to teach the use of an
`
`HPLMN list because the references are CDMA-oriented, and that a person of
`
`ordinary skill in the art would not consider McElwain and Uchida practical for a
`
`GSM environment. Paper No. 25 at 19. However, this argument, which is repeated
`
`from Patent Owner’s Preliminary Response, has already been rejected by the Board.
`
`Moreover, Patent Owner once again ignores the express teachings in the prior art.
`
`Patent Owner next argues that McElwain, Uchida, and Hicks individually fail
`
`to teach an HPLMN list because a person of ordinary skill in the art would have been
`
`faced with compatibility problems, which was solved by the ’933 patent by creating
`
`a new HPLMN list. Patent Owner claims that because the 3GPP Standards had not
`
`yet implemented the ability to handle multiple HPLMN codes, that legacy phones
`
`
`
`12
`
`
`
`

`

`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`would not have been able to process such files, and thus, an entirely new file was
`
`required. However, Patent Owner improperly creates a new limitation not required
`
`by the claims in the ’933 patent and again ignores the knowledge of a person of
`
`ordinary skill in the art, as explained in more detail below.
`
`1. McElwain and Uchida Disclose an HPLMN List in a CDMA
`and GSM Environment
`
`Both McElwain and Uchida disclose the use of multiple MCC/MNC pairs
`
`corresponding to the home networks of the HPLMN list. Even though McElwain’s
`
`and Uchida’s disclosures are CDMA-oriented, both McElwain and Uchida expressly
`
`disclose that their methods “may be employed alternatively in GSM systems,”
`
`something that the Board has already acknowledged in its Institution Decision.
`
`Ex. 1004 ¶ 40; Ex. 1005 ¶ 6; Paper No. 12 at 28–30. Moreover, a person of ordinary
`
`skill in the art would have understood that an MCC/MNC pair would be used in
`
`GSM systems instead of the SID/NID pairs discussed in McElwain and Uchida.
`
`Ex. 1003 ¶ 89, 100–108, 116; Ex. 1032 ¶ 29. It would have been obvious to a person
`
`of ordinary skill in the art to adapt the teachings of McElwain and Uchida to a GSM
`
`system, and a person of ordinary skill in the art would have had a reasonable
`
`expectation of success in doing so. Ex. 1003 ¶ 89, 100–108, 116; Ex. 1032 ¶ 29.
`
`Thus, both McElwain and Uchida disclose the use of multiple MCC/MNC pairs
`
`corresponding to the home networks of the HPLMN list.
`
`
`
`13
`
`
`
`

`

`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`2. McElwain, Uchida, and Hicks Disclose to a Person of
`Ordinary Skill in the Art an HPLMN List That Is Backwards
`Compatible
`
`Patent Owner next argues that McElwain, Uchida, and Hicks individually fail
`
`to teach an HPLMN list because a person of ordinary skill in the art would have been
`
`faced with compatibility problems, which was solved by the ’933 patent by creating
`
`a “new HPLMN list.” Paper No. 25 at 20. However, the ’933 patent says nothing
`
`about the multiple MCC/MNC pairs having to be in a “new file” and Patent Owner
`
`cites to nothing for this proposition—requiring an HPLMN list is not the same as
`
`requiring a new file. Ex. 1032 ¶ 31. Instead, the multiple MCC/MNC pairs are
`
`simply a list of MCC/MNC pairs “associated with a plurality of communication
`
`networks which are part of the ‘home network.’” E.g., Ex. 1001 at 5:32–34.
`
`Ultimately, the ’933 patent merely requires that the multiple MCC/MNC pairs are
`
`associated with a home network to consist of an HPLMN list rather than require that
`
`all the MCC/MNC pairs must be in a “new file.” Ex. 1032 ¶ 31.
`
`Moreover, Patent Owner again relies on the argument that the HPLMN
`
`Selector from the 3GPP Standards did not implement multiple HPLMN codes at the
`
`time. Paper No. 25 at 20. However, Patent Owner already made this argument,
`
`which the Board rejected. As the Board stated in its Institution Decision, the fact
`
`that the 3GPP Standards state that an HPLMN Selector with multiple MCC/MNC
`
`pairs is not yet implemented does not detract from what the standards disclose to a
`
`
`
`14
`
`
`
`

`

`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`person of ordinary skill in the art, which is “an explicit teaching of an HPLMN
`
`Selector with multiple MCC/MNC pairs.” See Paper No. 12 at 59 (emphasis in
`
`original).
`
`Finally, even if the HPLMN list must be in a “new file,” “applying computer
`
`and internet technology to replace older electronics” is within the knowledge of a
`
`person of ordinary skill in the art and renders the claim limitation obvious. See W.
`
`Union Co. v. MoneyGram Payment Sys., Inc., 626 F.3d 1361, 1370 (Fed. Cir. 2010);
`
`Ex. 1032 ¶ 32. It would have been well within the knowledge of a person of ordinary
`
`skill in the art to modify the HPLMN list taught by McElwain and Uchida in order
`
`to be operable and backwards compatible with legacy phones by modifying an
`
`existing file that would be properly interpreted by newer phones while ignored by
`
`legacy phones or include a new file to be used by new phones only. Ex. 1032 ¶ 32.
`
`Both of these approaches yield predictable results and are routinely used as new
`
`features and capabilities are developed. Ex. 1032 ¶ 32.
`
`IV. GROUND 5: OBVIOUSNESS OVER THE 3GPP STANDARDS AND
`MCELWAIN
`
`The Petition asserted that the Challenged Claims would have been obvious
`
`over the 3GPP Standard and McElwain (Ground 5). See Paper No. 1 at 48–67. In
`
`its Institution Decision, the Board thoroughly analyzed Ground 5 for each of the
`
`Challenged Claims and agreed that Petitioner demonstrated a reasonable likelihood
`
`
`
`15
`
`
`
`

`

`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`of prevailing on Ground 5. See Paper No. 12 at 48–69. Patent Owner’s Response
`
`offers no reason to deviate from this determination.
`
`Patent Owner’s challenges to McElwain have already been discussed with
`
`respect to Grounds 1–4 in the previous section. See supra Section III. With respect
`
`to the 3GPP Standards, Patent Owner argues only that the 3GPP Standards fail to
`
`disclose use of multiple MCC/MNC pairs in an HPLMN list recited in claim
`
`elements 1[c], 6[e], & 11[f] based on the fact that the 3GPP Standards had not yet
`
`implemented multiple HPLMN codes at the time. However, the Board has already
`
`rejected this argument. See Paper No. 12 at 55–60. Patent Owner again does not
`
`separately raise any arguments that the combination of the references does not teach
`
`the above limitation, nor does Patent Owner raise any arguments for any of the other
`
`the remaining claim limitations. Thus, the Board should find that all Challenged
`
`Claims would have been obvious over Ground 5 for the same reasons as detailed in
`
`the Petition and as set forth below.
`
`A. The 3GPP Standards Disclose the Use of Multiple MCC/MNC
`Pairs Corresponding to the Home Networks of the HPLMN List
`
`The 3GPP Standards disclose the use of multiple MCC/MNC pairs
`
`corresponding to the home networks of the HPLMN list. As it did in the Preliminary
`
`Response, Patent Owner once again errs by focusing only on what the 3GPP
`
`Standards had implemented at the time, and not what it explicitly taught to a person
`
`of ordinary skill in the art would be done in future standards. As the Board already
`
`
`
`16
`
`
`
`

`

`
`
`
`
`
`
`Petitioner’s Reply to Patent Owner’s
`Response in IPR2020-01157
`
`found, while “[t]his ve

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket