Please type a plus sign (4) insidethis box ——f» [)¥]
`
`PTO/SBAG (8-00)
`Approved for use through 10/31/2002. OMB 0651-0032
`LS. Patent and Trademark Office; U.S. DEPARTMENT OF COMMERCE
`Under the Paperwork. Reduction Act of 1995, no persons are required.to respond to a‘collection of information unless:it displays a valid OMB control number.
`
`PROVISIONAL APPLICATION FOR PATENT COVER SHEET
`This is a requestforfiling a PROVISIONAL APPLICATION FOR PATENT under 37 CFR 1.53(c)}.
`
`Given Name(first'and middle [if any]) = Name or Sumame
`
`City and-either State or Foreign Country
`
`Shenzhen, Guangdong, China
`
`INVENTOR(S)
`
`Residence
`
`[| Additional! investors are being narned on the. separately numbered sheets atlached hereto
`TITLE OF THE INVENTION (280 characters:max
`
`Secure Manager to Emulate Multiple Cards
`
`Direct all correspondencefo:
`
`CORRESPONDENCE ADDRESS
`
`ys
`
`Firm or
`Individual Name
`
`26/97
`
`Type Customer Number here
`
`BarCodeftabelhere
`
`eea
`
`ENCLOSED. APPLICATION PARTS (check all that appt
`x Specification Number of Pages
`CX] Drawing(s) Number of Sheets[25|
`[_] Application Data Sheet. See 37 CFR 1.76
`
`Applicant: claims small entity status. See. 37 CFR 4.27.
`A check or money orderis enclosed to coverthe filing fees
`
`The Commissioneris. herebyauthorizedto.charge filing
`
`fees or credit any everpayment.to Depesit Account Number:
`Payment by creditcard. Form PTO-2033 is attached.
`
`required
`
`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.
`ea No.
`CC Yes, the name ofthe U.S. Gavernment agency andthe Government contract number are:
`
`.
`
`Respectfully submitted,
`
`04/02/2012
`Date
`/joezheng /
`SIGNATURE
`39,450
`(ifappropriate)
`Joe Zhen
`
`
` Docket Number:(408)777-8873 |TYPED or PRINTED NAME [_RFID-o84P|TELEPHONE
`
`
`USE ONLY FOR FILING A PROVISIONAL APPLICATION FOR PATENT
`This collection of information is required by 37 CFR 41.51. The information is used by the public.to file (and by the PTO to process) a
`provisional application. Confidentiality is governed by 35-U.S.C. 122 and 87 CFR 1.14. This collection 1s estimated to take & hours-to
`complete, including gathering, preparing, and ‘submitting the complete
`provisional application to the PTO. Time will vary depending upon
`the individual case.
`Any comments.on fhe amountoftitre you require fo complete this form and/or suggestions for reducing this burden,
`should be sent to the Chief Information Cficer, U.S..Patent and Trademark. Office. U.S: Department of Commerce, Vvashington, D.C.
`20231. DO NOT SEND FEES OR COMPLETED FORMS TO THIS ADDRESS. SEND TO: Box Provisional Application, Assistant
`Commissioner for Patents, Washington, D.C. 20231.
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 1 of 84
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 1 of 84
`
`

`

`
`
`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
`
`ProvisionalFiling Fees
`
`Description
`
`Fee Code
`
`Quantity
`
`Sub-Total in
`USD(S)
`
`Basic Filing:
`
`
`
`Pages:
`
`
`Claims:
`
`Miscellaneous-Filing:
`
`Petition:
`
`
`Patent-Appeals-and-Interference:
`
`Post-Allowance-and-Post-Issuance:
`
`Extension-of-Time:
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 2 of 84
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 2 of 84
`
`

`

`Sub-Total in
`Quantity AmountFee Code USD(S)
`Description
`
`
`
`
`
`
`
`Total in USD ($)
`
`Miscellaneous:
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 3 of 84
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 3 of 84
`
`

`

`Electronic Acknowledgement Receipt
`
`
`12442764
`
`Confirmation Number:
`
`
`
`
`Title of Invention:
`
`Customer Initiated Land-Based Payment Using Secure Elements
`
`
`
`First Named Inventor/Applicant Name:
`
`Xiangzhen Xie
`
`ee
`
`Filer Authorized By:
`
`
`Attorney Docket Number:
`
`RFID-O85P
`
`09:54:21
`Time Stamp:
`
`
`
`
`Application Type: Provisional
`
`Paymentinformation:
`
`Submitted with Payment
`
`
`
`Payment Type Credit Card
`
`Payment was successfully received in RAM
`RAM confirmation Number
`
`$125
`
`
`
`Deposit Account
`
`Authorized User
`
`File Listing:
`
`Document
`
`Pocument Pescription
`
`sigs
`
` Filetame Message Digest
`
`File Size(Bytes)/
`
`Multi
`
`Part/.zip (ifappl.)
`
`Pages
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 4 of 84
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 4 of 84
`
`

`

`Specification
`
`ProvisionalAsFiled.pdf
`
`fb8e9ef4badcl5c2c51b539bf1 O8dfe25.e20|
`
`104038
`
`Specification
`
`Appendix.pdf
`
`289897
`
`7160[6cb86a97bad7245825¢29e91 361758}
`be520
`
`Information:
`
`Drawings-only black and white line
`drawings
`
`742377
`
`Drawings.pdf
`
`62635523d5a77ef4b31 853b6307f4be40b3|
`23b2
`
`Warnings:
`Information:
`
`PROVAppTransmittal.pdf
`Transmittal of New Application
`03 10f03087b3850c8a0d9b9be4f53.c64dbe
`Ob4as
`
`465647
`
`
`
`93681 25adt8c32963b074052bf221633d7)
`
`Warnings:
`
`Fee Worksheet (SBO6)
`
`fee-info.pdf
`
`29255
`
`off
`
`This Acknowledgement Receipt evidences receipt on the noted date by the USPTOof 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
`If a new application is being filed and the application includes the necessary componentsfor 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 shownon this
`Acknowledgement Receiptwill establish thefiling date of the application.
`
`National Stage of an International Application under 35 U.S.C. 371
`If a 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/DO/EO/903 indicating acceptance of the application asa
`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
`If a new international application is being filed and the international application includes the necessary componentsfor
`an international filing date (see PCT Article 11 and MPEP 1810), a Notification of the International Application Number
`and ofthe International Filing Date (Form PCT/RO/105)will be issued in due course, subject to prescriptions concerning
`national security, and the date shownon this Acknowledgement Receiptwill establish the international filing date of
`the application.
`
`
`Google LLC v. RFCyber Corp. / Page 5 of 84
`
`GOOG-1030
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 5 of 84
`
`

`

`Docket No.: RFID-O85P
`
`In the United States Patent and TrademarkOffice
`
`US Provisional Patent Application for
`
`Customer Initiated Land-Based Payment Using Secure Elements
`
`Inventor(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
`| 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, Commissionerfor Patents,
`P.O. Box 1450, Alexandria, VA 22313"
`
`Signed:
`
`—_/joe zheng /
`Joe Zheng
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page6 of 84
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 6 of 84
`
`

`

`Customer Initiated Land-Based Payment Using Secure Elements
`
`For many land-based credit or debit card transactions, the paymentprocessis
`
`started by a customer asking for a bill wnen 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) counterto initiate a transaction payment. The service staff then brings
`
`back a receipt to the customer to authorize the transaction. It is a lengthy processthat
`
`typically takes a couple of minutes. In addition, in the case for debit card transactions, it
`
`is even more troublesome whenthe 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 servicestaff will bring a Mobile POS
`
`to the customerto start a transaction. However, the customer still needs to trust and
`
`relay on the POS by the merchantto 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 POSable to start secure
`
`paymentis challenged.
`
`In this invention, we propose a method that uses secure
`
`elements as an instrumentto transportbills 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
`
`¢
`
`¢
`
`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 bethe traditional payment method such as credit and debit card,
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 7 of 84
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 7 of 84
`
`

`

`or new internet payment method such as Paypal, Alipay, or new contactless epurse
`
`such as PBOC2, CEPSortransportation 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 Request
`
`SmartBill Payment Gateway
`
`Paymentinfo with-etectronic bill
`
`
`
`
`Payment Authorization Response
`
`
`
`Personal NFC device with
`
`wallet software
`
`Signed electronic bill
`
`Dedicated land-based POS with
`
`contactless reader OR NFC
`
`device with SE (suh as Mobile
`
`Contactless Smart Card
`(or Secure Element in
`NFC devices) with
`SmartBill Applet
`
`Electronic bill
`
`Fig 1. System components
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 8 of 84
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 8 of 84
`
`

`

`The following figure showsa 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 smartbill applet on his contactless smart card or SE
`on NFC device
`
`Customer service delivers the contactless smartbill
`
`card (or SE) to customer
`
`Customer with NFC device that installed a SmartBill enabled
`
`Wallet Application will retrieve the electronic bill signed by
`the smartbill 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
`
`forwarded back to the merchant
`
`SmartBill enabled application will send the transaction
`information to the backend smartbill gateway for processing
`
`SmartBill gateway verifies the electronic bill and will reject if the
`payment amount is less than the billed amount.
`
`SmartBill gateway from there on uses the traditional financial
`payment networkflow to send payment request and get
`paymentresponse. 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
`
`Google LLC v. RFCyber Corp. / Page 9 of 84
`
`GOOG-1030
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 9 of 84
`
`

`

`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 numberof 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:
`
`e Assigned merchantid
`
`¢ Applet serial number for the 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
`
`¢
`
`Electronic bill
`
`¢ Transaction detail information
`
`e Amount
`
`¢
`
`Bill Number
`
`¢ Transaction Time
`
`e Signed electronic bill
`
`¢ Append personalized smart bill info: merchant id, serial number
`
`* Generate a signature (either MAC ordigital digest)
`
`e Payment Information
`
`* Total payment amountincluding tips
`
`
`
`5
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 10 of 84
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 10 of 84
`
`

`

`*
`
`*
`
`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 paymentserver.
`
`The processes, sequencesor steps and features discussed above and in the
`
`appendix (part of the application) are related to each other and eachis 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 sequencesin
`
`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 reducedto practice in the disclosure herein.
`
`The foregoing and attached areillustrative 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 systemsare not intendedto limit the
`
`scopeof the invention whichfinds itself in the various permutations of the features
`
`disclosed and described herein as conveyed to one ofskill 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;
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 11 of 84
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 11 of 84
`
`

`

`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 comesfrom an institution where the customerhas held an
`
`account or the NFC devicedirectly.
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 12 of 84
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 12 of 84
`
`

`

`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, whicharedifficult 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 suchas the Internet for e-commerce
`
`and/or wireless networks for m-commerceas 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
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 13 of 84
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 13 of 84
`
`

`

`cards contain volatile memory and microprocessor components. Smart cards may also
`
`provide strong security authentication for single sign-on (SSO)within large
`
`organizations. The benefits of smart cards are directly related to the volume of
`
`information and applications that are programmedfor 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 embeddedinto 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 masstransit and highwaytolls. Such Near Field Communication
`
`(NFC) between a contactless smart card and a reader presents significant business
`
`opportunities when used in NFC-enabled mobile phonesfor 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 natureof their individual roles, these
`
`players need to communicate with each other and exchange messagesin 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 comesto 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
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 14 of 84
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 14 of 84
`
`

`

`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 purposeof the section,
`
`the title and the abstract. Such simplifications or omissions are not intendedtolimit
`
`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 networkwith
`
`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 purchasekey), default PINs, administration keys (e.g., an
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 15 of 84
`
`23
`
`
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 15 of 84
`
`

`

`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 comprisesinitiating
`
`data communication with a server, sending device information of the secure elementin
`
`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 determinesthat the
`
`computing device is registered therewith, wherein the device information is a
`
`sequence ofcharacters uniquely identifying the secure element, and the requestis 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
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 16 of 84
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 16 of 84
`
`

`

`[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 serveran 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 setof key set installed in the secure element, receiving
`
`data prepared by the serverto enable the application to function as designed on the
`
`mobile device; and sending out an acknowledgementto 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 serverusing a set
`
`of key set installed on the secure element, preparing data necessaryfor 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
`
`networkinterface, 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 servervia the
`
`networkinterface 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
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 17 of 84
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 17 of 84
`
`

`

`serveris 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 acknowledgementto a
`
`provider of the application about a status of the application that is now active with the
`
`secure element. The processoris 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 advantagesof 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(é.g., the Internet).
`
`[0019]
`
`Other objects, features, and advantagesof 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 showsa simplified architecture of an NFC-enabled mobile
`
`device with a secure element (SE);
`
`[0022]
`
`FIG. 1B showsa flowchart or process of personalizing an SE according
`
`to one embodiment of the present invention;
`
`[0023]
`
`FIG. 1C showsrelationships 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 deviceitself, a TSM server, a corresponding SE
`
`manufacturer and an SE issuer;
`
`
`
`6
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 18 of 84
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 18 of 84
`
`

`

`[0025]
`
`FIG. 1E showsa data flowchart or process of personalizing data flow
`
`amongthree 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. 2B showsa flowchart or processof provisioning one or more
`
`applications according to one embodiment;
`
`[0028]
`
`FIG. 2C showsa dataflowillustrating various interactions among
`
`different parties when an application is being provisioned in one embodiment;
`
`[0029]
`
`FIG. 2D showsa data flow among different entities when preparing the
`
`application data in provisioning an application;
`
`[0030]
`
`FIG. 2E showsa flowchart or processfor 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 whatis 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 showsa block diagram of related modulesinteracting with each
`
`other to achieve whatis referred to herein as e-purse personalization by a user of the
`
`e-purse;
`
`[0034]
`
`FIG. 3C showsa flowchart or process of personalizing an e-purse
`
`according to one embodiment of the present invention;
`
`[0035]
`
`FIG. 4A and FIG. 4B showtogether a flowchart or processoffinancing,
`
`funding, load or top-up an e-purse according to one embodiment of the present
`
`invention;
`
`
`
`7
`
`
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 19 of 84
`
`GOOG-1030
`Google LLC v. RFCyber Corp. / Page 19 of 84
`
`

`

`[0036]
`
`FIG. 4C 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-commercefunctionalities over a cellular
`
`communications network(i.e., 3G, LTE or GPRS network), according an embodiment
`
`of the present invention;
`
`[0038]
`
`FIG. 5B is a diagram showing a second exemplary architecture of a
`
`portable device for enabling e-commerce and m-commercefunctionalities over a wired
`
`and/or wireless data network (e.g., Internet), according another embodiment of the
`
`presentinvention;
`
`[0039]
`
`FIG. 5C is a flowchart illustrating an exemplary process of enabling the
`
`portable device of FIG. 5A for services/applications provided by one or more service
`
`providers in accordance with one embodiment of the present invention;
`
`[0040]
`
`FIG. 6A is a diagram showing an exemplary architecture, in which a
`
`portable device is enabled as a mobile POS conducting e-commerce and m-
`
`commerce, according to one embodiment of the present invention;
`
`[0041]
`
`FIG. 6B is a diagram showing an exemplary architecture, in which a
`
`portable device is enabled as a mobile POS conducting a transaction upload operation
`
`over a network, according to an embodi