Chart B-1
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Fintiv, Inc. v. Apple Inc., Case No. 1:19-CV-1238-ADA (W.D. Tex.)
`
`Filtering Based on Mobile Device Information
`
`CLAIM LIMITATIONS: “receiving filtered contactless card applet for provisioning, wherein the contactless card applet is filtered based on the mobile
`device information” (’125 patent claim 14), “a rule engine configured to filter a widget based on the mobile device information” (’125 patent claim 18)
`and “an over-the-air (OTA) proxy configured to provision the contactless card applet, a widget corresponding to the contactless card applet, and the
`WMA, wherein said OTA proxy is configured to capture mobile device information comprising SE information; and wherein said OTA proxy is
`configured to transmit the mobile device information for registering the mobile wallet application” (claim 23 to the extent claim 23 requires filtering).
`
`ASSERTED CLAIMS:
`
` These limitations are present in the following asserted claims: ’125 patent claims 14, 18, and 23 (and their dependent claims).
`
`DISCLOSURE/MOTIVATION TO COMBINE:
` Under Fintiv’s interpretation of these claim limitations, filtering a contactless card applet, a
`corresponding widget, or other software was well-known to persons of ordinary skill in art at the time of the alleged inventions of the Asserted
`Patent. 1
`
`Fintiv does identify how the accused products perform filtering. The entirety of Fintiv’s Preliminary Infringement Contentions for the filtering
`limiation of claim 18 are reproduced below. See Preliminary Infringement Contentions, Ex. A at 68-71.
`
`
`
`1 To the extent that these Invalidity Contentions rely on or otherwise embody particular constructions of terms or phrases in the Asserted Claims, including the constructions
`ordered by the Court in this action, Defendant is not proposing any such constructions as proper constructions of those terms or phrases and reserves the right to adopt different
`claim construction positions in this and other proceedings. Various positions put forth in this document are predicated on Plaintiff’s incorrect and overly broad interpretation of its
`claims as evidenced by its Preliminary Infringement Contentions, dated May 20, 2019 and proposed Amended Infringement Conventions, dated December 6, 2019 (collectively,
`the “Infringement Contentions” or “Preliminary Infringement Contentions”). Those positions are not intended to and do not necessarily reflect Defendant’s interpretation of the
`true and proper scope of Plaintiff’s claims, and Defendant reserves the right to adopt claim construction positions that differ from or even conflict with various positions put forth
`in this document.
`
`1
`
`IPR2020-00019
`Fintiv EX 2031 Page 1
`
`

`

`Chart B-1
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`
`
`
`
`2
`
`IPR2020-00019
`Fintiv EX 2031 Page 2
`
`

`

`Chart B-1
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`
`
`
`
`
`The ’125 patent explains that the “filtered list of downloadable applications” may be filtered based on a variety of information relating to the mobile
`device, including other software stored on the device or even an entity associated with that software: “mobile device 100 attributes may include,
`without limitation, the mobile network provider of the mobile device 100 (e.g. ‘Sprint®’, ‘Verizon®’, ‘AT&T®’, etc.), financial institutions
`associated with the contactless card applets stored (e.g. ‘Wachovia®’, ‘Bank of America®’, ‘Chase®’, etc.), mobile device 100 manufacturer (e.g.
`‘HTC®’, ‘Motorola®’, ‘Apple®’, etc.), and mobile device 100 hardware specifications (i.e. hardware, software, operating system, etc.).” ’125 patent
`at 10:24-34; see also id. at 5:22-24 (“Rule engine 116 may filter widgets based on information related to the mobile device.”). The ’125 patent does
`not disclose that filtering applets, widgets, or other software was done in a way that was unconventional or based on critera that was not well-known.
`
`To the extent Fintiv contends that the claimed “applets” and “widgets” are software applications, a person of ordinary skill in the art would be
`motivated to combine and/or apply teachings beyond only those found in mobile wallet prior art references. For as long as different hardware and
`software configurations have existed in computers, software purveyors have offered users software applications that are compatible with the users’
`
`3
`
`IPR2020-00019
`Fintiv EX 2031 Page 3
`
`

`

`Chart B-1
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`respective devices. For example, vendors offered a Windows user the Windows-compitable version of a software application, a Linux user the
`Linux-comptaible version of the software, and a Mac user the Mac-compatible version of the same software. There is nothing new or inventive about
`this concept, regardless of whether it is performed by a human or on a server which filters based on “mobile device information.” The fact that the
`software being filtered is a contactless card applet or widget does not make it any less obvious.
`
`In much the same way that a computer such as a laptop, desktop, or smartphone would send information (e.g., OS version, MAC address, etc.) to a
`server in order to receive an operating system update, service pack, or security patch corresponding to the existing software on the device which a
`user could then choose to install, a mobile device would send “mobile device information” to a server to receive notification of compatiable “applets”
`or “widgets” which a user could then choose to install. This technique was well-known and obvious to POSITA prior to the alleged invention of the
`Asserted Patent in view of similar approaches used for things like providing Windows service-pack and security updates.
`
` POSITA would have been motivated to implement this standard practice to advance the goal of ensuring that only the compatible versions of
`applications that work with the particular mobile device at issue are offered or provisioned to that device. See, e.g., Aiglstorfer at ¶ 45 (“It is
`appreciated that a first moblet software module 204 may be installed during manufacturing of the electronic device 210. Alternatively, the first
`moblet software module 204 may be requested 201 from the remote server 230. The request 201 may indicate a device type of the electronic device
`210. In response to the request 201, the remote server 230 may transmit 203 the first moblet software module 204 to the electronic device 210.
`Furthermore, responsive to the request 201, the remote server 130 may transmit 203 a device dependent software, e.g., MOJAX environment.”);
`O’Neill at 11:62-12:32 (“…the client device 104 establishes a communication link with the update device server 136 and transfers identity
`information 113 including, type, model, and/or make of the device, as well as version of operational system software currently being used by the
`client device information and checks the server manifest or queries the update store 133 for the presence of the update package 110. After comparing
`the available versions of operational software on the server manifest or update store 133 to the onboard version of operational software transferred by
`the client device 104, the update store 133 directs the transfer of the update package 110 to the client device 104….”). A POSITA would have been
`motivated to apply filtering in this manner to improve the user experience, avoid the hassles and costs associated with attempting to install
`incompatible software, eliminate service calls and requests from users about compatibility problems, and provide faster response times resulting from
`server-based filtering.
`
`Accordingly, a POSITA at the time of the alleged invention would have found it obvious to use known software filtering techniques in the context of
`provisioning “applets” and “widgets” on a mobile device. More specifically, it would have been obvious to modify or combine known prior art
`systems or methods in which a server filters for software on the basis of information related to the client-side device to achieve provisioning a mobile
`device with a contactless card applet and/or a corresponding widget which were first filtered by the server providing such software based on
`information relating to the mobile device.
`
`
` A
`
`4
`
`IPR2020-00019
`Fintiv EX 2031 Page 4
`
`

`

`Chart B-1
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`To the extent Fintiv contends that any reference identified in Exhibit A does not disclose any portion of the above limitations, such limitations are
`disclosed by the references herein. Moreover, the exemplary pincites to the prior art identified in the table below also establish that the allegedly
`missing portions would have been obvious to one of ordinary skill in the art. Further, a person of ordinary skill in the art would have been motivated
`to combine each reference identified in Exhibit A with any one or more of the following references for at least the reasons explained in the cover
`document of Apple’s Initial Invalidity Contentions or as identified herein.
`
`
`Reference
`
`Disclosure
`
`U.S. Patent Publication No. 2010/0138518
`A1 to Aiglstorfer (“Aiglstorfer”).
`Aiglstorfer was filed on November 18, 2009
`and published on June 3, 2010.
`
`See, e.g.:
`
`• Aiglstorfer at ¶ 12 (“It is appreciated that responsive to a user request, the electronic wallet may send a message to the
`remote server to download the first moblet software module. The sent message may indicate a device type of the
`electronic wallet. Accordingly, the electronic wallet receives from the remote server the device dependent software
`module via a wireless network. Moreover, the electronic wallet receives from the remote server the first moblet
`software module via a wireless network. Accordingly, the electronic wallet executes the first moblet software module
`using the device dependent software module. According to one embodiment, the first and the second moblet software
`modules are written using MOJAX commands.”).
`• Aiglstorfer at ¶ 31 (“It is appreciated that the first moblet software module 106 may be installed during manufacturing
`of the elec tronic device 110. Alternatively, the first moblet software module 106 may be requested 101 from the
`remote server 130 and subsequently downloaded. The request 101 may indicate a device type of the electronic device
`110. In response to the request 101, the remote server 130 may transmit 103 the first moblet software module 106 to
`the electronic device 110. Furthermore, responsive to the request 101, the remote server 130 may also transmit 103 a
`device dependent software, e.g., MOJAX environment, to the electronic wallet.”).
`• Aiglstorfer at Fig. 1:
`
`5
`
`IPR2020-00019
`Fintiv EX 2031 Page 5
`
`

`

`Chart B-1
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`
`
`• Aiglstorfer at ¶ 32 (“The first moblet software module 106 is installed on the electronic device 110 and becomes
`operable on the electronic device 110. The first moblet software module 106 may manage additional moblet Software
`modules. It is appreciated that the first moblet software module 106 may be operating within the electronic wallet
`environment. For example, the electronic wallet environment may have a corresponding graphical element icon. Upon
`a user selection of the electronic wallet environment, additional graphical element icons associated with moblet
`software modules may be displayed. The displayed moblet software modules may be executed upon selection
`thereof.”).
`• Aiglstorfer at ¶ 36 (“The TSA 102 stores the first banking card information 105 in the removable security element 104
`in response to receiving the first banking card information 105. The TSA 102 may also notify 107 the first moblet
`software module 106 that the first banking card information has been received and is stored in the removable security
`element 104. The first moblet software module 106 may in turn notify 109 the remote server 130.”).
`
`6
`
`IPR2020-00019
`Fintiv EX 2031 Page 6
`
`

`

`Chart B-1
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`• Aiglstorfer at ¶ 37 (“The remote server 130, in response to the notification 109, automatically transmits 111a second
`moblet soft ware module to the first moblet software module 106. It is appreciated that the second moblet software
`module may be an application related to the first banking card information 105. The first moblet software module 106
`may receive and install the second moblet software module 108 on the electronic device 110. As a result, the first
`banking card information 105 may be used in conjunction with the execution of the second moblet software module
`108 to enable the user to interact with the second moblet software module 108 and the first banking card information
`105 associated therewith. It is appreciated that the second moblet software module 108 may be a GUI type application
`that when executed enables user interaction therein to perform banking features.”).
`• Aiglstorfer at ¶ 38 (“According to one embodiment, the second moblet software module 108 may be transmitted
`wirelessly and installed on the electronic device 110 transparent to the user.It is appreciated that updates to the second
`moblet software module 108 may be transmitted and installed automatically. However, it is appreciated that the
`second moblet software module 108 or any updates thereof may also be received and installed on the electronic device
`110 responsive to a user request.”).
`• Aiglstorfer at ¶ 39 (“It is appreciated that additional banking card information and moblet software modules
`associated therewith may be similarly received and installed and messaged by the first moblet 106. For example, a
`second banking card information 113 may be transmitted from the TSM120 to the TSA 102. The TSA 102 may store
`the second banking card infor mation 113 in the removable security element 104. The TSA 102 may subsequently
`automatically notify 115 the first moblet software module 106 of the transmission of the second banking card
`information. According to one embodiment, the first moblet software module 106 notifies 117 the remote server 130
`that the second banking card information 113 has been received.”).
`• Aiglstorfer at ¶ 40 (“Responsive to the notification 117, the remote server 130 may automatically transmit 119 a third
`moblet software module to the first moblet software module 106. The first moblet software module 106 may thereafter
`install and store the third moblet software module 112. It is appreciated that the third moblet software module 112
`may be an application related to the second banking card information 113. As a result, the second banking card
`information 113 may be used in conjunction with the execution of the third moblet software module 112 to enable the
`user to interact with the third moblet software module 112 and the second banking card information 113 associated
`therewith. It is appreciated that the third moblet software module 112 may be a GUI type application that enables user
`interaction therein to perform banking applications.”).
`• Aiglstorfer at ¶ 41 (“According to one embodiment of the present invention, the first, the second and the third moblet
`software modules include device independent commands of a generic syntax. In one embodiment, the first, the second
`and the third moblet software modules may be written using MOJAX commands. MOJAX is a language that enables
`manipulation of a web browser and flash. It is appreciated that the MOJAX commands are executed by the dependent
`software of the electronic device 110. The electronic device 110 dependent software resides on the electronic device
`110.”).
`• Aiglstorfer at ¶ 42 (“According to one embodiment, the third moblet software module 112 may be transmitted
`wirelessly and installed on the electronic device 110 transparent to the user. It is appreciated that updates to the third
`
`7
`
`IPR2020-00019
`Fintiv EX 2031 Page 7
`
`

`

`Chart B-1
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`moblet software module 112 may be transmitted and installed automatically. However, it is appreciated that the third
`moblet software module 112 or any update thereof may be received and installed on the electronic device 110
`responsive to a user request.”).
`• Aiglstorfer at ¶ 45 (“It is appreciated that a first moblet software module 204 may be installed during manufacturing
`of the electronic device 210. Alternatively, the first moblet software module 204 may be requested 201 from the
`remote server 230. The request 201 may indicate a device type of the electronic device 210. In response to the request
`201, the remote server 230 may transmit 203 the first moblet software module 204 to the electronic device 210.
`Furthermore, responsive to the request 201, the remote server 130 may transmit 203 a device dependent software, e.g.,
`MOJAX environment.”).
`• Aiglstorfer at Fig. 2:
`
`
`
`8
`
`IPR2020-00019
`Fintiv EX 2031 Page 8
`
`

`

`Chart B-1
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`• Aiglstorfer at ¶ 47 (“It is appreciated that the first moblet software module 204 becomes operable on the electronic
`device 210 when it is installed on the electronic device 210. The first moblet software module 204 may manage
`additional moblet software modules. It is appreciated that the first moblet software module 204 may operate within the
`electronic wallet environment. For example, moblet software modules are operable in a MOJAX environment
`operating on a device. According to one embodiment, MOJAX is device specific while moblet software modules
`operating within the MOJAX environment are device generic. According to one embodiment, the electronic wallet
`environment may have a corresponding graphical element icon. Upon selection of the electronic wallet environment,
`additional graphical element icons associated with moblet software modules may be displayed. The displayed moblet
`Software modules may be executed upon selection thereof.”).
`• Aiglstorfer at ¶ 49 (“The first moblet software module 204 may notify 209 the remote server 230 that the first banking
`card information 205 has been received and stored in the non-removable security element 202. In response to the
`notification 209, the remote server 230 may automatically transmit 2.11a second moblet software module to the first
`moblet software module 204. It is appreciated that the second moblet software module may be an application related
`to the first banking card information 205. The first moblet software module 204 may receive and install the second
`moblet software module 206 on the electronic device 210. As a result, the first banking card information 205 may be
`used in conjunction with the execution of the second moblet software module 206 to enable the user to interact with
`the second moblet software module 206 and the first banking card information 205 associated therewith. It is
`appreciated that the second moblet software module 206 may be a GUI type application that when executed enables
`user interaction therein to perform banking applications.”).
`• Aiglstorfer at ¶ 50 (“According to one embodiment, the second moblet software module 206 may be transmitted
`wirelessly and installed on the electronic device 210 transparent to the user. It is appreciated that updates to the second
`moblet software module 206 may be transmitted and installed automatically. However, it is appreciated that the
`second moblet software module 206 or any updates thereof may be received and installed on the electronic device 210
`responsive to a user initiated request.”).
`• Aiglstorfer at ¶ 51 (“It is appreciated that additional banking card information and moblet software modules
`associated therewith may be similarly received and installed. For example, a second banking card information 213
`may be transmitted from the TSM 220 to the non-removable security element 202. It is appreciated that the second
`banking card information 213 may be transmitted responsive to a request for a third moblet software module that does
`not exist on the electronic device 210. The non-removable security element 202 may store the second banking card
`information 213. The non-removable security element 202 may transmit an acknowledgement signal to the TSM 220
`that the second banking card information 213 has been received and stored. The TSM 220 may subsequently notify
`215 the first moblet software module 204 of the transmission of the second banking card information.”).
`• Aiglstorfer at ¶ 52 (“According to one embodiment, the first moblet software module 204 notifies 217 the remote
`server 230 that the second banking card information 213 has been received. Responsive to the notification 217, the
`remote server 230 may automatically transmit 219 a third moblet software module to the first moblet software module
`204. The first moblet software module 204 may thereafter install and store the third moblet software module 208. It is
`
`9
`
`IPR2020-00019
`Fintiv EX 2031 Page 9
`
`

`

`Chart B-1
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`appreciated that the third moblet software module 208 may be an application related to the second banking card
`information 213. As a result, the second banking card information 213 may be used in conjunction with the execution
`of the third moblet software module 208 to enable the user to interact with the third moblet software module 208 and
`the second banking card information 213 associated therewith. It is appreciated that the third moblet software module
`208 may be a GUI type application that enables user interaction thereinto perform banking applications.”).
`• Aiglstorfer at ¶ 53 (“According to one embodiment of the present invention, the first, the second and the third moblet
`software modules include device independent commands of a generic syntax. In one embodiment, the first, the second
`and the third moblet software modules may be written using MOJAX commands. MOJAX is a language that enables
`manipulation of a web browser and flash. It is appreciated that the MOJAX commands are executed by dependent
`software of the electronic device 210. The dependent software of the electronic device 210 resides on the electronic
`device 210.”).
`• Aiglstorfer at ¶ 54 (“According to one embodiment, the third moblet software module 208 may be transmitted
`wirelessly and installed on the electronic device 210 transparent to the user. It is appreciated that updates to the third
`moblet software module 208 may be transmitted and installed automatically. However, it is appreciated that the third
`moblet software module 208 or any updates thereof may be received and installed on the electronic device 210
`responsive to a user request.”).
`• Aiglstorfer at ¶ 65 (“Referring now to FIGS. 7A and 7B, an exemplary flow diagram 700 for downloading
`information into a secure element in accordance with one embodiment of the present invention is shown. At step 710,
`responsive to a user request, the portable device, e.g., cellular phone, sends a message to a remote server to download
`a first moblet software module. It is appreciated that the message sent to the remote server may indicate a device type
`of the potable device.”).
`• Aiglstorfer at ¶ 66 (“At step 712, the portable device receives a device dependent software module. The device
`dependent software module is transmitted by the remote server via a wireless network. At step 714, the portable
`device receives the first moblet software module from the remote server via a wireless network.”).
`• Aiglstorfer at Fig. 7A:
`
`10
`
`IPR2020-00019
`Fintiv EX 2031 Page 10
`
`

`

`Chart B-1
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`The teachings of this reference are explicitly directed to systems and methods wherein a server filters software for provisioning
`on a mobile device based on information related to that mobile device, and a POSITA at the relevant time would have been
`
`
`
`11
`
`IPR2020-00019
`Fintiv EX 2031 Page 11
`
`

`

`Chart B-1
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`motivated to combine these teachings with other systems and methods in which servers provide software for provisioning on a
`mobile device, such as those identified in Exhibit A.
`
`U.S. Patent No. 6,832,373 to O’Neill
`(“O’Neill”). O’Neill was filed on April 1,
`2003, published on October 28, 2004, and
`issued on December 14, 2004.
`
`See, e.g.:
`
`• O’Neill at 6:67-7:29 (“FIG. 1A illustrates one embodiment of an update distribution system 100. The update
`distribution system 100 includes an update generator 102 and a client device 104. In one embodiment, the update
`generator 102 receives a first code version 106, such as an old version of a software application, and a second code
`version 108, such as a new version of a software application. The update generator 102 produces an update package
`110 comprising an instruction set which represents a plurality of operations that are desirably used to transform the
`first original code version 106 into the second updated code version. The update package 110 is then transferred to a
`client device 104 via a communications medium 112. Viable choices for communications media 112 may include hard
`wired media, removable storage media, wireless media, volatile and non-volatile memory based media, and the
`Internet. Other communications media 112 may include by way of example, local area networks (LANs), wide area
`networks (WANs), public Internets, private Internets, a private computer network, a secure Internet, a private network,
`a public network, a value-added network, interactive television networks, wireless data transmission networks, two-
`way cable networks, interactive kiosk networks, and the like. In addition, the client device 104 may comprise
`numerous types of devices capable of receiving and processing the update package 10, such as computers, personal
`digital assistants (PDAs), hardwired phones, mobile phones, pagers, electronic peripheral devices, appliances, and
`other such devices capable of being config ured to receive the update package.”).
`• O’Neill at Fig. 1A:
`
`12
`
`IPR2020-00019
`Fintiv EX 2031 Page 12
`
`

`

`Chart B-1
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`
`
`• O’Neill at 7:36-8:11 (“At least one method by which the client device 104 may securely and reliably obtain the update
`package 110 from the update generator 102 may occur by transfer of information in the form of the update package
`110 through at least one of the above-mentioned communications media types. The client device 104 may further be
`equipped with the capability to bi-directionally communicate with the update gen erator 102. In one embodiment, the
`client device 104 transfers identity information 113, including type, model, and/or make of the device, as well as the
`version of operational software or applications currently in use by the client device 104. The update generator 102
`receives the identity information 113 from the client device 104 and subsequently generates the desired update
`package 110 required and/or requested by the client device 104. Alternatively, the update generator 102 may be
`equipped with the ability to generate and provide a plurality of update packages 10, which reference a plurality of
`operational software versions or applications, prior to receiving the identity information 113. In this embodiment, the
`update generator 102 may retrieve from memory or storage an archived version of the desired update package 110a. In
`addition, the update generator 102 may create a version manifest, which comprises a list of archived update packages
`110 including operational software version information for a wide range of particular client devices 104. Once the
`update package 110 is generated, validated, and deemed available, the update gen erator 102 may function as a server
`and transfer the desired update package 110 to the client device 104 as requested or required. It will be appreciated
`that one or more update packages 110 may be generated and archived as updated versions of operational software
`become available. Furthermore, update packages 110 can be prepared for use with hardware update systems, such as
`may be required, for example, to update non-volatile memory components or portable electronic devices. One
`
`13
`
`IPR2020-00019
`Fintiv EX 2031 Page 13
`
`

`

`Chart B-1
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`desirable feature of the update management system is that it may be readily adapted for use in wireless update
`procedures or over the air (OTA) updating. This method allows updates for software or firm ware components in
`devices without hardware changes. The updating methods described herein can further be used to update a client
`device including applications, operational functionality, operating system software and the like.
`• O’Neill at Fig. 1B:
`
`• O’Neill at 11:9-30 (“In an exemplary application, the update management system may be used in conjunction with
`over the air updating of portable electronic devices, such as cellular or mobile phones. Mobile communications
`technology is a rapidly changing field which strives to meet the rising demands and expectations of its users. Mobile
`phones are also micro computing devices utilizing integrated operational system software. The operating software,
`throughout the life of the mobile phone, may require periodic software updates for increased adaptability to changes in
`wireless communica tions technology. Updating in the mobile communications industry is complicated by the
`presence of many different manufacturing entities with each having their own operational software systems and user
`functionality being inte grated into various makes and models of mobile phones. In this circumstance, the update
`generator 102 is capable of meeting the adaptive demands of industry by generating a proper update package 110a,
`
`
`
`14
`
`IPR2020-00019
`Fintiv EX 2031 Page 14
`
`

`

`Chart B-1
`
`Invalidity Contentions: U.S. Patent No. 8,843,125
`
`Reference
`
`Disclosure
`
`110b, 110c relative to the newer versions of operational software onboard the client devices 104a, 104b, 104c, which
`pertain to the particular manufacturer’s make and model of the mobile communica tions device.”).
`• O’Neill at 11:62-12:32 (“Server-Side Update Determination In another embodiment, the client device 104 establishes
`a communication link with the update device server 136 and transfers identity information 113 including, type, model,
`and/or make of the device, as well as version of operational system software currently being used by the client device
`information and checks the server manifest or queries the update store 133 for the presence of the update package 110.
`After comparing the available versions of operational software on the server manifest or update store 133 to the
`onboard version of operational software transferred by the client device 104, the update store 133 directs the transfer
`of the update package 110 to the client device 104. In one aspect, the update package 110 is transferred from the
`update store 133 to the update device server (s) 136 for distribution to client devices 104 as requested. In this case, the
`update device server (s) 136 acts as gateways which transfer the update packages 110 to clients as requested by the
`update store 133. Use of the update device server(s) 136 desirably improves load balancing and reduces bandwidth
`limitations imposed by having many client devices 104 connected to the same update package provider. In one aspect,
`if the particular update package 110 that is requested or determined to be required by the client device 104 is not
`available in the update store 133, then the update management component 134 may transfer a request to the update
`generator 102 to generate the particular update package 110. Once the update package 100 is generated, the update
`generator 102 transfers the update package 110 to the update store 133 for storage and request servicing. After saving
`the update package 110 in the memory or storage area of the update store 133, the update management component 134
`may transfer the desired update package 110 to the update device server 136. Subsequently, the update device server
`136 may establish communication with the client device 104b and transfer the requested update package to the client
`device 104.”).
`• O’Neill at 1