PIease type a plus sign (+) inside this box _>
`
`PTOfSBlts (8-00)
`Approved for use through10!3112002. OMB 0651-0032
`US. Patent and Trademark Office; U.S. DEPARTMENT OF COMMERCE
`Under the Paperwork Reduction Act oftQQS, no persons are required to respond to a collection ofinformation unless it displays avalid OMB control number.
`
`PROVISIONAL APPLICATION FOR PA TENT COVER SHEET
`This is a request for filing a PROVISIONAL APPLICATION FOR PATENT under 37 CFR1.53(C).
`
`INVENTOR('S)
`
`Given Name (first and middle [if any])
`
`Xiangzhen
`
`Family Name or Surname
`XIE
`
`Residence
`Cit and either State or Forei-n Count
`
`‘
`
`V
`
`Shenzhen, Guangdong, China
`
`El Additional inventors are being named on the_ separately numbered sheets attached hereto
`TITLE OF THE INVENTION 280 characters max
`
`Secure Manager to Emulate Multiple Cards
`
`Direct aii correspondence to:
`
`CORRESPONDENCE ADDRESS
`
`OR
`
`Type Customer Number here
`
`Firm or
`I]
`Individual Name
`Add ress.
`
`Address
`
`cw
`Count
`
`V
`
`D Yes, the name ofthe LLS. Government agency and the Government contract number are:
`
`ENCLOSED APPLICATION PARTS check ail that aim
`[XI Specification Number ofPages
`'3 (30(5), Number l:l
`IX] Drawing(s) Number of Sheets
`-
`Appendix - 44 pages
`
`Other (Specify)
`
`[:| Application Data Sheet. See 37 CFR 1.76
`METHOD OF PAYMENT OF FILING FEES FOR THIS PROVISIONAL APPLICATION FOR'F’ATENT (check one)
`
`Applicant claims small entity status. See 37 CFR 1.27.
`A check or money order is enclosed to coverthe filing fees
`The Commissioner is hereby authorized to charge filing
`fees or credit any overpayment to Deposit Account Number:
`Payment by credit card. Form PTO—2038 is attached.
`
`FILING FEE
`‘
`_
`73qu'md
`fee
`
`The invention was made by an agency of the United States Government or under a contract with an agency of the
`United States Govemment.
`E No.
`
`Respectfully submitted
`
`_
`[Jerheng /
`
`TELEPHONE
`
`04/02/2012
`Date
`REGlSTRATION NO.
`S'GNATURE
`(”firmware
`Joe Zhen
`TYPED or PRINTED NAME
`FIFI D-OB4P
`M Docket Number:
`USE ONLY FOR FILING A PROVISIONAL APPLICATION FOR PA TENT
`This collection of information is required by 37 CFR 1.51. The information is used by the public to file (and by the PTO to process) a
`provisional application. Confidentiality is governed b 35 U.S.C. 122 and 3? CFR 114. This collection is estimated to take 8 hours to
`complete, Including gathering, preparin‘ , and submi
`ing the complete
`rovisional application to the PTO. Time will vary depending u on
`the IndIVIduaI case. . y comments on to amount of time you requtre o completet is form andior suggestions for reductng this bur en,
`should be sent to the Chief Information thicer, US. Patent and Trademark Office. US. De artment of Commerce, Washington. DC.
`20231._ DO NOT SEND FEES _OR COMPLETED FORMS TO THIS ADDRESS; SEND O: Box Provrstonal Application, Asststant
`CommisstOner for Patents, Washington, DC. 20231.
`
`395450
`
`Google LLC v. RFCyber Corp. / Page 1 of 84
`
`6006-1030
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 1 of 84
`
`PGR2022-00003
`Apple EX1030 Page 1
`
`

`

`
`
`Electronic Patent Application Fee Transmittal
`
`Title of Invention:
`
`Customer Initiated Land-Based Payment Using Secure Elements
`
`
`
`First Named Inventor/Applicant Name: Xiangzhen Xie
`
`Filer:
`
`Joe Zheng
`
`Filed as Small Entity
`
`Provisional Filing Fees
`
`Description
`
`Fee Code
`
`Quantity
`
`Sub-Total in
`USD($)
`
`Basic Filing:
`
`
`
`
`
`Miscellaneous-Filing:
`
`Petition:
`
`
`Patent-Appeals-and-lnterference:
`
`Post-Allowance-and-Post-lssuance:
`
`Extension-of—Time:
`
`
`
`
`
`Google LLC v. RFCyber Corp. / Page 2 of 84
`
`GOOG-1030
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 2 of 84
`
`PGR2022-00003
`Apple EX1030 Page 2
`
`

`

`
`
`Sub-Total in
`Description USD($) Quantity
`
`Total in USD (5)
`
`
`
`Miscellaneous:
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 3 of 84
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 3 of 84
`
`PGR2022-00003
`Apple EX1030 Page 3
`
`

`

`Electronic Acknowledgement Receipt
`
`1 2442764
`
`Confirmation Number:
`
`
`
`Title of Invention:
`
`Customer Initiated Land-Based Payment Using Secure Elements
`
`
`
`First Named Inventor/Applicant Name:
`
`Xiangzhen Xie
`
`——
`
`Filer Authorized By:
`
`Attorney Docket Number:
`
`RFID—085P
`
`——
`
`09:54:21
`Time Stamp:
`
`
`
`
`Application Type: Provisional
`
`Payment information:
`
`yes
`Submitted with Payment
`Payment Type Credit Card
`
`
`
`Payment was successfully received in RAM
`
`$125
`
`——
`
`
`
`File Size(Bytes)/
`
`Multi
`
`Part I.Zip
`
`Pages
`
`fifappl.)
`
`File Listing:
`
`Document
`
`Document Descrlptlon m message DigeSt
`
`.
`
`.
`
`
`
`Google LLC v. RFCyber Corp. / Page 4 of 84
`
`GOOG-1030
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 4 of 84
`
`PGR2022-00003
`Apple EX1030 Page 4
`
`

`

`Specification
`
`ProvisionalAsFiled.pdf
`
`Specification
`
`Appendixpdf
`
`104038
`
`ibSEQEMbadc I 5(26 “3539be UBderSelD
`6(28
`
`289897
`
`716016Lb86d97bdd7245825L29e91351758
`139520
`
`Information:
`
`Drawings-only black and white line
`drawings
`
`742377
`
`Drangspdf
`
`62635523d5a77ef4b31853b6307f4be40b3
`2C3b2
`
`Warnings:
`Information:
`
`465647
`
`PROVAppTransmittal.pdf
`Transmittal of New Application
`a310f03037b3350c830d9b9bc4f§3c64dbc
`0b4a8
`
`
`
`Warnings:
`
`Fee Worksheet (SB06)
`
`fee-info.pdf
`
`
`
`29255
`
`(9368125adl8c32963b07405ZbDZfb633d7
`92“
`
`This Acknowledgement Receipt evidences receipt on the noted date by the USPTO of the indicated documents,
`characterized by the applicant, and including page counts, where applicable. It serves as evidence of receipt similar to a
`Post Card, as described in MPEP 503.
`
`
`New Applications Under 35 U.S.C. 111
`Ifa new application is being filed and the application includes the necessary components for a filing date (see 37 CFR
`1.53(b)—(d) and MPEP 506), a Filing Receipt (37 CFR 1.54) will be issued in due course and the date shown on this
`Acknowledgement Receipt will establish the filing date of the application.
`
`National Stage of an International Application under 35 U.S.C. 371
`Ifa timely submission to enter the national stage of an international application is compliant with the conditions of 35
`U.S.C. 371 and other applicable requirements a Form PCT/D0/E0/903 indicating acceptance of the application as a
`national stage submission under 35 U.S.C. 371 will be issued in addition to the Filing Receipt, in due course.
`
`New International Application Filed with the USPTO as a Receiving Office
`Ifa new international application is being filed and the international application includes the necessary components for
`an international filing date (see PCT Article 11 and MPEP 1810), a Notification of the International Application Number
`and of the International Filing Date (Form PCT/R0/105) will be issued in due course, subject to prescriptions concerning
`national security, and the date shown on this Acknowledgement Receipt will establish the international filing date of
`the application.
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 5 of 84
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 5 of 84
`
`PGR2022-00003
`Apple EX1030 Page 5
`
`

`

`Docket N0.: RFID-085P
`
`In the United States Patent and Trademark Office
`
`US Provisional Patent Application for
`
`Customer Initiated Land-Based Payment Using Secure Elements
`
`lnventor(s): Xiangzhen Xie
`C505, Long Tai Xuan, Nanguang Village
`Nanshang District
`Shenzhen, Guangdong Province, 518051, China
`Citizenship: P. R. China
`
`Date of Deposit: April 2, 2012
`# E-filing
`Express Mail Label
`I hereby certify that this paper or fee is being deposited with the United States Postal Service
`using "Express Mail Post Office To Addressee" service under 37 CFR 1.10 on the date
`indicated above and is addressed to "Mail Stop: New Application, Commissioner for Patents,
`PO. Box 1450, Alexandria, VA 22313"
`
`Signed:
`
`lioe zheng /
`Joe Zheng
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 6 of 84
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 6 of 84
`
`PGR2022-00003
`Apple EX1030 Page 6
`
`

`

`Customer Initiated Land-Based Payment Using Secure Elements
`
`For many land-based credit or debit card transactions, the payment process is
`
`started by a customer asking for a bill when checking out a purchase. A cashier or
`
`service staff will bring a bill to the customer for verification. The customer then hands
`
`out a credit/debit card to the service staff. The service staff brings the card to a Point of
`
`Sales (POS) counter to initiate a transaction payment. The service staff then brings
`
`back a receipt to the customer to authorize the transaction. It is a lengthy process that
`
`typically takes a couple of minutes. In addition, in the case for debit card transactions, it
`
`is even more troublesome when the PIN is needed to authorize the transaction at the
`
`POS.
`
`According to one aspect of our invention, we provide a Mobile POS solution.
`
`Instead of bringing a financial card to the POS, the service staff will bring a Mobile POS
`
`to the customer to start a transaction. However, the customer still needs to trust and
`
`relay on the POS by the merchant to start the payment process. As more and more
`
`customers are using personal portable devices such as smart phones, the traditional
`
`payment paradigm assuming only merchant’s dedicated POS able to start secure
`
`payment is challenged.
`
`In this invention, we propose a method that uses secure
`
`elements as an instrument to transport bills to customers so that they can initiate
`
`transactions with their personal Near Field Communication (NFC) devices. Secure
`
`elements can be in a form of dedicated contactless smart cards or secure element
`
`components of merchants’ NFC devices. An electronic bill can be either
`
`0
`
`0
`
`created in a smart card at the store’s POS and bring to a customer, or
`
`created in a secure element (SE) of the merchant mobile POS at a customer
`
`Our Solution
`
`Our solution uses a contactless smart card or a secure element in a NFC device to
`
`transport a bill from a merchant to a customer. The customer then uses his NFC
`
`portable device to read the signed bill from the smart card and starts the transaction
`
`using one of the methods that his mobile wallet has enrolled with. This underlying
`
`payment method can be the traditional payment method such as credit and debit card,
`
`
`
`
`
`Google LLC v. RFCyber Corp. / Page 7 of 84
`
`GOOG-1030
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 7 of 84
`
`PGR2022-00003
`Apple EX1030 Page 7
`
`

`

`or new internet payment method such as Paypal, Alipay, or new contactless epurse
`
`such as PBOC2, CEPS or transportation purse. In addition, while most of the mobile
`
`payment methods require the customer to give the cell phone number to the merchants,
`
`our method does not need any contact information to be disclosed. This method
`
`protects customer privacy.
`
`The following figure shows an architecture according to one embodiment of out present
`
`invention.
`
`
` Payment Network
`
`
`Payment Authorization Response
`
`Payment Authorization Req uest
`
`Smart Bill Payment Gateway
`
`Payment info wit
`
`' ectronic bill
`
`Personal NFC device with
`wallet software
`
`Dedicated land-based POS with
`
`contactless reader OR NFC
`.
`_
`.
`deVIce With SE (suh as Mobile
`
` Signed electronic bill
`
`Contactless Smart Card
`
`Electronic bill
`
`(or Secure Element in
`
`NFC devices) with
`
`Smart Bill Applet
`
`Fig 1. System components
`
`
`
`Google LLC v. RFCyber Corp. / Page 8 of 84
`
`GOOG-1030
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 8 of 84
`
`PGR2022-00003
`Apple EX1030 Page 8
`
`

`

`The following figure shows a flowchart or process of performing a transaction according
`
`to one embodiment of out present invention.
`
`Merchant POS prepares an electronic bill and writes to
`
`a smart bill applet on his contactless smart card or SE
`on NFC device
`
`Customer service delivers the contactless smart bill
`
`card (or SE) to customer
`
`Customer with NFC device that installed a Smart Bill enabled
`
`Wallet Application will retrieve the electronic bill signed by
`
`the smart bill applet
`
`Electronic bill is displayed on the NFC device screen. Customer
`
`will verify the amount and add a tip if he wish
`
`Customer can choose a payment method that he enrolled in
`
`his wallet application to initiate the payment
`
`Smart Bill enabled application will send the transaction
`
`information to the backend smart bill gateway for processing
`
`Smart Bill gateway verifies the electronic bill and will reject if the
`
`payment amount is less than the billed amount.
`
`Smart Bill gateway from there on uses the traditional financial
`
`payment network flow to send payment request and get
`
`payment response. It also can use new online payment method
`
`such as Paypal or Alipay to complete transaction.
`
`
`
`Once the transaction is approved or denied, the payment
`
`authorization response will return to the payment gateway to be
`forwarded back to the merchant
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 9 of 84
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 9 of 84
`
`PGR2022-00003
`Apple EX1030 Page 9
`
`

`

`As an exemplary operation, the above flowchart may be described below:
`
`1. Smart Card Applet Issuing Flow
`
`Merchants signed up for smart bill payment will be issued with a number of contactless
`
`smart cards installed with personalized smart bill applet. The applet can also be
`
`installed on an NFC device with SE.
`
`The following information is personalized in each applet:
`
`. Assigned merchant id
`
`0 Applet serial number forthe merchant
`
`- Merchant key (either symmetric or asymmetric key). In general, these are
`
`diversified keys of a set of system master keys.
`
`2. Payment Initiation Flow
`
`As described in the flowchart,
`
`the following are typical Example of
`
`0 Electronic bill
`
`- Transaction detail information
`
`- Amount
`
`-
`
`Bill Number
`
`° Transaction Time
`
`° Signed electronic bill
`
`- Append personalized smart bill info: merchant id, serial number
`
`- Generate a signature (either MAC or digital digest)
`
`° Payment Information
`
`0 Total payment amount including tips
`
`
`
`5
`
`
`
`Google LLC v. RFCyber Corp. / Page 10 of 84
`
`6006-1030
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 10 of 84
`
`PGR2022-00003
`Apple EX1030 Page 10
`
`

`

`-
`
`0
`
`payment method
`
`necessary information needed to conduct the payment
`
`As part of the description of the instant application, the Appendix herewith describes
`
`one exemplary embodiment that may be used to support a payment transaction or
`
`facilitate a payment process. The transaction may be conducted online or offline, with or
`
`without a payment server.
`
`The processes, sequences or steps and features discussed above and in the
`
`appendix (part of the application) are related to each other and each is believed
`
`independently novel in the art. The disclosed processes and sequences may be
`
`performed alone or in any combination to provide a novel and unobvious system or a
`
`portion of a system. It should be understood that the processes and sequences in
`
`combination yield an equally independently novel combination as well, even if combined
`
`in their broadest sense; i.e. with less than the specific manner in which each of the
`
`processes or sequences has been reduced to practice in the disclosure herein.
`
`The foregoing and attached are illustrative of various aspects/embodiments of
`
`the present invention, the disclosure of specific sequence/steps and the inclusion of
`
`specifics with regard to broader methods and systems are not intended to limit the
`
`scope of the invention which finds itself in the various permutations of the features
`
`disclosed and described herein as conveyed to one of skill in the art.
`
`Claim
`
`A method for conducting a payment transaction, the method comprising:
`
`initiating the payment transaction by transporting an electronic check to an NFC
`
`device associated with a customer;
`
`requesting a verification on the check from the customer, wherein the check is being
`
`displayed on a display of the NFC device and requesting an action from the
`
`customer;
`
`
`
`
`
`Google LLC v. RFCyber Corp. / Page 11 of 84
`
`GOOG-1030
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 11 of 84
`
`PGR2022-00003
`Apple EX1030 Page 11
`
`

`

`receiving a message from the NFC device after the customer authorizes the
`
`payment transaction;
`
`clearing the check after receiving a payment from the consumer against the check,
`
`wherein the payment comes from an institution where the customer has held an
`
`account or the NFC device directly.
`
`
`
`
`
`Google LLC v. RFCyber Corp. / Page 12 of 84
`
`GOOG-1030
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 12 of 84
`
`PGR2022-00003
`Apple EX1030 Page 12
`
`

`

`Appendix
`
`Method and apparatus for performing payment transactions
`
`Technical Field
`
`BACKGROUND
`
`[0001]
`
`The present invention is generally related to commerce over networks.
`
`Particularly, the present invention is related to techniques for personalizing a secure
`
`element and provisioning an application such as an electronic purse that can be
`
`advantageously used in portable devices configured for both electronic commerce
`
`(a.k.a., e-commerce) and mobile commerce (a.k.a., m-commerce).
`
`Description of the Related Art
`
`[0002]
`
`Single functional cards have been successfully used in enclosed
`
`environments such as transportation systems. One example of such single functional
`
`cards is MIFARE that has been selected as the most successful contactless smart
`
`card technology. MIFARE is the perfect solution for applications like loyalty and
`
`vending cards, road tolling, city cards, access control and gaming.
`
`[0003]
`
`However, single functional card applications are deployed in enclosed
`
`systems, which are difficult to be expanded into other areas such as e-commerce and
`
`m-commerce because stored values and transaction information are stored in data
`
`storage of each tag that is protected by a set of keys. The nature of the tag is that the
`
`keys need to be delivered to the card for authentication before any data can be
`
`accessed during a transaction. This constraint makes systems using such technology
`
`difficult to be expanded to an open environment such as the Internet for e-commerce
`
`and/or wireless networks for m-commerce as the delivery of keys over a public domain
`
`network causes security concerns.
`
`[0004]
`
`In general, a smart card, chip card, or integrated circuit card (ICC), is any
`
`pocket-sized card with embedded integrated circuits. A smart card or microprocessor
`
`
`
`1
`
`
`
`Google LLC v. RFCyber Corp. / Page 13 of 84
`
`6006-1030
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 13 of 84
`
`PGR2022-00003
`Apple EX1030 Page 13
`
`

`

`cards contain volatile memory and microprocessor components. Smart cards may also
`
`provide strong security authentication for single sign-on (880) within large
`
`organizations. The benefits of smart cards are directly related to the volume of
`
`information and applications that are programmed for use on a card. A single
`
`contact/contactless smart card can be programmed with multiple banking credentials,
`
`medical entitlement, driver’s license/public transport entitlement, loyalty programs and
`
`club memberships to name just a few. Multi-factor and proximity authentication can
`
`and has been embedded into smart cards to increase the security of all services on
`
`the card.
`
`[0005]
`
`Contactless smart cards that do not require physical contact between
`
`card and reader are becoming increasingly popular for payment and ticketing
`
`applications such as mass transit and highway tolls. Such Near Field Communication
`
`(NFC) between a contactless smart card and a reader presents significant business
`
`opportunities when used in NFC-enabled mobile phones for applications such as
`
`payment, transport ticketing, loyalty, physical access control, and other exciting new
`
`services.
`
`[0006]
`
`To support this fast evolving business environment, several entities
`
`including financial institutions, manufactures of various NFC-enabled mobile phones
`
`and software developers, in addition to mobile network operators (MNO), become
`
`involved in the NFC mobile ecosystem. By nature of their individual roles, these
`
`players need to communicate with each other and exchange messages in a reliable
`
`and interoperable way.
`
`[0007]
`
`One of the concerns in the NFC mobile ecosystem is its security in an
`
`open network. Thus there is a need to provide techniques to personalize a secure
`
`element in a contactless smart card or an NFC-enabled mobile device so that such a
`
`device is so secured and personalized when it comes to financial applications or
`
`secure transactions. With a personalized secure element in an NFC-enabled mobile
`
`device, various applications or services, such as electronic purse or payments, can be
`
`realized. Accordingly, there is another need for techniques to provision or manage an
`
`application or service in connection with a personalized secure element.
`
`
`
`2
`
`
`
`Google LLC v. RFCyber Corp. / Page 14 of 84
`
`6006-1030
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 14 of 84
`
`PGR2022-00003
`Apple EX1030 Page 14
`
`

`

`SUMMARY
`
`[0008]
`
`This section is for the purpose of summarizing some aspects of
`
`embodiments of the present invention and to briefly introduce some preferred
`
`embodiments. Simplifications or omissions in this section as well as the title and the
`
`abstract of this disclosure may be made to avoid obscuring the purpose of the section,
`
`the title and the abstract. Such simplifications or omissions are not intended to limit
`
`the scope of the present invention.
`
`[0010]
`
`Broadly speaking, the invention is related to techniques for personalizing
`
`secure elements in NFC devices to enable various secure transactions over a network
`
`(wired and/or wireless network). With a personalized secure element (hence secured
`
`element), techniques for provisioning various applications or services are also
`
`provided. Interactions among different parties are managed to effectuate a
`
`personalization or provisioning process flawlessly to enable an NFC device for a user
`
`thereof to start enjoying the convenience of commerce over a data network with
`
`minimum effort.
`
`[0011]
`
`As an example of application to be provided over a secured element, a
`
`mechanism is provided to enable devices, especially portable devices, to function as
`
`an electronic purse (e-purse) to conduct transactions over an open network with a
`
`payment server without compromising security. According to one embodiment, a
`
`device is installed with an e-purse manager (i.e., an application). The e-purse manager
`
`is configured to manage various transactions and functions as a mechanism to access
`
`an emulator therein. Secured financial transactions can then be conducted over a
`
`wired network, a wireless network or a combination of both wired and wireless
`
`network.
`
`[0012]
`
`According to another aspect of the present invention, security keys
`
`(either symmetric or asymmetric) are personalized so as to personalize an e-purse
`
`and perform a secured transaction with a payment server. In one embodiment, the
`
`essential data to be personalized into an e-purse include one or more operation keys
`
`(e.g., a load key and a purchase key), default Ple, administration keys (e.g., an
`
`Google LLC v. RFCyber Corp. / Page 15 of 84
`
`6006-1030
`
`a3
`
`
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 15 of 84
`
`PGR2022-00003
`Apple EX1030 Page 15
`
`

`

`unblock PIN key and a reload PIN key), and passwords (e.g., from Mifare). During a
`
`transaction, the security keys are used to establish a secured channel between an
`
`embedded e-purse and an SAM (Security Authentication Module) or a backend server.
`
`[0013]
`
`The present invention may be implemented in various forms including a
`
`method, a system, an apparatus, a part of a system or a computer readable medium.
`
`According to one embodiment, the present invention is a method for personalizing a
`
`secure element associated with a computing device. The method comprises initiating
`
`data communication with a server, sending device information of the secure element in
`
`responding to a request from the server after the server determines that the secure
`
`element is registered therewith, wherein the device information is a sequence of
`
`characters uniquely identifying the secure element, and the request is a command
`
`causing the computing device to retrieve the device information from the secure
`
`element, receiving at least a set of keys from the server, wherein the keys are
`
`generated in the server in accordance with the device information of the secure
`
`element, and storing the set of keys in the secure element to facilitate a subsequent
`
`transaction by the computing device.
`
`[0014]
`
`According to another embodiment, the present invention is a method for
`
`personalizing a secure element associated with a computing device. The method
`
`comprises receiving an inquiry to establish data communication between a server and
`
`the computing device, sending a request from the server to the computing device to
`
`request device information of the secure element after the server determines that the
`
`computing device is registered therewith, wherein the device information is a
`
`sequence of characters uniquely identifying the secure element, and the request is a
`
`command that subsequently causes the computing device to retrieve the device
`
`information from the secure element therein, generating at least a set of keys in
`
`accordance with the device information received, delivering the set of keys through a
`
`secured channel over a data network to the computing device, wherein the set of keys
`
`is caused to be stored in the secure element with the computing device, and notifying
`
`at least a related party that the secure element is now personalized for subsequent
`
`trusted transactions.
`
`
`
`4
`
`
`
`Google LLC v. RFCyber Corp. / Page 16 of 84
`
`6006-1030
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 16 of 84
`
`PGR2022-00003
`Apple EX1030 Page 16
`
`

`

`[0015]
`
`According to still another embodiment, the present invention is a method
`
`for provisioning an application installed in a mobile device, the method comprises
`
`sending to a server an identifier identifying the application together with device
`
`information of a secure element associated with a mobile device on which the
`
`application has been installed, establishing a secured channel between the secure
`
`element and the server using a set of key set installed in the secure element, receiving
`
`data prepared by the server to enable the application to function as designed on the
`
`mobile device; and sending out an acknowledgement to a provider of the application
`
`about a status of the application now being active with the secure element on the
`
`mobile device. The data received in the mobile device includes a user interface of the
`
`application per the mobile device and a generated application key set.
`
`[0016]
`
`According to still another embodiment, the present invention is a method
`
`for provisioning an application, the method comprises receiving from a mobile device
`
`an identifier identifying the application together with device information of a secure
`
`element associated with the mobile device on which the application has been installed,
`
`establishing a secured channel between the secure element and the server using a set
`
`of key set installed on the secure element, preparing data necessary for the
`
`application to function as designed on the mobile device, transporting the data from
`
`the server to enable the application via the secured channel; and notifying a provider
`
`of the application about a status of the application now active with the secure element
`
`on the mobile device.
`
`[0017]
`
`According to yet another embodiment, the present invention is a mobile
`
`device for conducting a transaction over a network, the mobile device comprises a
`
`network interface, a secure element, a memory space for storing at least a module and
`
`an application downloaded from the network, a processor coupled to the memory
`
`space and configured to execute the module to cause operations including verifying
`
`whether the application has been provisioned. When it is verified that the application
`
`has not been provisioned, the operations further comprise sending to a server via the
`
`network interface an identifier identifying the application together with device
`
`information of a secure element, establishing a secured channel between the secure
`
`element and the server using a key set installed on the secure element, wherein the
`
`
`
`5
`
`
`
`Google LLC v. RFCyber Corp. / Page 17 of 84
`
`6006-1030
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 17 of 84
`
`PGR2022-00003
`Apple EX1030 Page 17
`
`

`

`server is configured to prepare data necessary for the application to function as
`
`designed on the mobile device, receiving the data from the server to associate the
`
`application with the secure element, and sending out an acknowledgement to a
`
`provider of the application about a status of the application that is now active with the
`
`secure element. The processor is further configured to determine if the secure element
`
`has been personalized before performing a provisioning process of the application. If
`
`the secure element has not been personalized, the mobile device is caused to
`
`personalize the secure element with a designed server.
`
`[0018]
`
`One of the objects, features, and advantages of the present invention is
`
`to enable a mobile device that can be used to perform a secured transaction with a
`
`party (e.g., at a point of sale, with a commercial server or accessing remotely) over an
`
`unsecured network (e.g., the Internet).
`
`[0019]
`
`Other objects, features, and advantages of the present invention, which
`
`will become apparent upon examining the following detailed description of an
`
`embodiment thereof, taken in conjunction with the attached drawings.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0020]
`
`The invention will be readily understood by the following detailed
`
`description in conjunction with the accompanying drawings, wherein like reference
`
`numerals designate like structural elements, and in which:
`
`[0021]
`
`FIG. 1A shows a simplified architecture of an NFC-enabled mobile
`
`device with a secure element (SE);
`
`[0022]
`
`FIG. 18 shows a flowchart or process of personalizing an SE according
`
`to one embodiment of the present invention;
`
`[0023]
`
`FIG. 1C shows relationships among an SE manufacturer, a TSM admin
`
`and the TSM system for both offline and online modes;
`
`[0024]
`
`FIG. 1D illustrates data flows among a user for an NFC device (e.g., an
`
`NFC mobile phone), the NFC device itself, a TSM server, a corresponding SE
`
`manufacturer and an SE issuer;
`
`
`
`6
`
`
`
`Google LLC v. RFCyber Corp. / Page 18 of 84
`
`6006-1030
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 18 of 84
`
`PGR2022-00003
`Apple EX1030 Page 18
`
`

`

`[0025]
`
`FIG. 1E shows a data flowchart or process of personalizing data flow
`
`among three entities: a land-based SAM or a network e-purse server, an e-purse
`
`acting as a gatekeeper, and a single function tag, according to one embodiment;
`
`[0026]
`
`FIG. 2A shows a mobile payment ecosystem in which related parties are
`
`shown in order for the mobile payment ecosystem successful;
`
`[0027]
`
`FIG. 28 shows a flowchart or process of provisioning one or more
`
`applications according to one embodiment;
`
`[0028]
`
`FIG. 20 shows a data flow illustrating various interactions among
`
`different parties when an application is being provisioned in one embodiment;
`
`[0029]
`
`FIG. 2D shows a data flow among different entities when preparing the
`
`application data in provisioning an application;
`
`[0030]
`
`FIG. 2E shows a flowchart or process for locking or disabling an installed
`
`application;
`
`[0031]
`
`FIG. 2F shows an exemplary architecture diagram of a portable device
`
`enabled as an e—purse conducting e-commerce and m-commerce, according to one
`
`embodiment of the present invention;
`
`[0032]
`
`FIG. 3A is a block diagram of related modules interacting with each other
`
`to achieve what is referred to herein as e-purse personalization by an authorized
`
`personnel (a.k.a., personalizing a mobile device or a secure element therein while
`
`provisioning an application);
`
`[0033]
`
`FIG. 3B shows a block diagram of related modules interacting with each
`
`other to achieve what is referred to herein as e-purse personalization by a user of the
`
`e-purse;
`
`[0034]
`
`FIG. 3C shows a flowchart or process of personalizing an e-purse
`
`according to one embodiment of the present invention;
`
`[0035]
`
`FIG. 4A and FIG. 4B show together a flowchart or process of financing,
`
`funding, load or top-up an e-purse according to one embodiment of the present
`
`invenfion;
`
`
`
`7
`
`
`
`Google LLC v. RFCyber Corp. / Page 19 of 84
`
`6006-1030
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 19 of 84
`
`PGR2022-00003
`Apple EX1030 Page 19
`
`

`

`[0036]
`
`FIG. 40 shows an exemplary block diagram of related blocks interacting
`
`with each other to achieve the process FIG. 4A and FIG. 4B;
`
`[0037]
`
`FIG. 5A is a diagram showing a first exemplary architecture of a portable
`
`device for enabling e-commerce and m-commerce functionalities over a cellular
`
`communications network (i.e., 3G, LTE or GPRS network), according an embodiment
`
`of the present invention;
`
`[0038]
`
`FIG. 5B is a d