Apple's Patent Background

 

Devices located in close proximity to each other can communicate directly using proximity technologies such as Near-Field Communications (NFC), Radio Frequency Identifier (RFID), and the like. These protocols can establish wireless communication links between devices quickly and conveniently, without, for example, performing setup and registration of the devices with a network provider. NFC can be used in electronic transactions, e.g., to securely send order and payment information for online purchases from a purchaser's mobile device to a seller's point of sale (POS) device.

 

Currently, payment information such as credit card data in mobile devices is sent directly from a secure element (SE) located in a device such as a mobile phone through proximity interfaces, such as near field communications (NFC), without an associated application processor (AP), such as an application program in the device, accessing the payment information. Preventing the AP from accessing the sensitive payment information is necessary because current payment schemes use real payment information (credit card number, expiration date, etc.) that can be used to make purchases through other means, include online and via the phone, and data in the AP can be intercepted and compromised by rogue applications.

 

Thus, there exists a need for a secure method of executing a commercial transaction that is both secure and user friendly.

 

Apple's Invention Relates to a Future iWallet System

 

Apple's invention generally relates to methods (air interfaces) and apparatuses for conducting a wireless commercial transaction that is both user friendly and secure.

 

In one or more embodiments, a portable device can make purchases by using near field communications (NFC) to establish a secure link with a point of sale (POS) device connected to a backend system that is configured to execute commercial transactions. This secure link can be established by positioning the portable device to be within close proximity of the point of sale device. Increased mobility is provided to users of the portable device making purchases by establishing a second secure link that uses a different protocol, such as WIFI or Bluetooth, that has more desirable characteristics for maintaining the link over time than NFC.

 

It would appear that Apple is referring to iBeacon without naming it as such. In one application, Wikipedia notes that iBeacon "could enable payments at the point of sale (POS) where you don't need to remove your wallet or card to make a payment. It could be a possible Near Field Communication (NFC) competitor." So it's a perfect fit for the application noted in Apple's invention.

 

Using a Shared Secret

 

Apple notes that in one or more embodiments, a second secure link is established using a shared secret known to the portable device and the backend server, and using an alias to identify a purchasing account such as a credit card.

 

When a request to make a transaction using the credit card is submitted to the backend server, the server determines whether the combination of the alias and crypto data is valid using a shared secret that is known to a secure element in the portable device and the backend server.

 

The backend server uses the shared secret (e.g., symmetric keys, public private keys, etc.) to verify the alias and the crypto data. The backend receives the alias from the portable device via the point of sale device and combines the alias with other information, such as counter value known to both the backend and the secure element. The backend can then generate the same crypto data using the shared secret and received data, and compare the result with the received crypto data. If the comparison indicates that the values are the same, then the credit card that corresponds to the credit card alias is provided back to the partner, and the transaction proceeds as normal. Otherwise, the credit card alias is rejected and the transaction is denied.

 

Air Interfaces: Performing a Commercial Transaction

 

In one or more embodiments, a method of performing a commercial transaction is provided. The method includes establishing a first secure link over a first air interface by a purchasing device, the first secure link between the purchasing device and a point of sale device, identifying a second air interface different from the first air interface, establishing a second secure link over a second air interface, the second secure link between the purchasing device and a backend server, and conducting, using the second air interface, a secure commercial transaction between the purchasing device and the backend server using payment data secured by a shared secret known to a secure element in the purchasing device and to the backend server.

 

Embodiments of the invention may include one or more of the following features:

 

The payment data may include an alias associated with a payment account, and establishing the second secure link may include encrypting the payment data by the secure element at the purchasing device using the shared secret as an encryption key.

 

Establishing the second secure link may include decrypting, at the backend server, the payment data using the shared secret, and verifying, at the backend server, the payment data, where verifying includes comparing the payment data to independently known payment data stored at the backend server.

 

Comparing the payment data to independently known payment data may include retrieving an alias from the decrypted received payment data, identifying a credit card account associated with the alias, determining if the alias is associated with the credit card account according to an association stored in a memory of the backend server, and, in response to determining that the alias is associated with the credit card account, approving the commercial transaction.

 

Comparing the payment data may further include retrieving a counter value from the decrypted retrieved payment data, and comparing the counter value to an independently known counter value stored in a memory of the backend server.

 

Establishing the first secure link may include establishing a near field communication link between the purchasing device and the point of sale device. Identifying a second air interface different from the first air interface may include identifying an air interface having properties more desirable than the first air interface to communicate data to a user over a time period longer than the time used to establish the first secure link.

 

Apple's Secure iWallet System

 

 

Apple's patent FIG. 1 shows a portable device that includes a secure element (SE) #108 configured to securely store and provide access to credit card information #106 in accordance with one or more embodiments.

 

The device also includes an application processor (AP) #104 that executes applications to, for example, purchase goods and services using the credit card information to send payments to vendor systems such as a point of sale (POS) device #116.

 

The portable device also includes one or more air interfaces, such as near field communications (NFC), WIFI (e.g., wireless local area network (WLAN) products that are based on the Institute of Electrical and Electronics Engineers' (IEEE) 802.11 standard) and Bluetooth (BT). NFC, Bluetooth, and WIFI are wireless communication protocols.

 

In one example, the portable device can make purchases by using near field communications (NFC) to wirelessly establish a secure link with the point of sale (POS) device, which is connected to a backend system #118 configured to execute commercial transactions, e.g., a bank, acquirer, or the like.

 

This secure link using NFC can be established by positioning the portable device to be within close proximity of, within e.g., 3 to 6 cm of, the point of sale device. In this example, credit card information is sent by the secure element as plaintext (i.e., not encrypted) data directly to the NFC. The plaintext credit card data is not sent to the application processor.

 

If the plaintext credit card data were to be sent to the application processor, a rogue program could access the credit card data and use it to make unauthorized purchases. In the example of FIG. 1, access to the credit card data by rogue programs is prevented because the communication between the secure element and the NFC is not accessible to the application processor.

 

Using Protocols other than NFC

 

In other embodiments, the portable device can use protocols other than NFC to establish the secure link between the portable device and the POS device, particularly protocols that have desirable characteristics for establishing a secure link, e.g., protocols that can establish a secure link quickly and securely. Protocols with desirable characteristics for establishing a secure link can have undesirable characteristics for maintaining the link over time, e.g., such protocols may involve keeping the portable device in the same location for the duration of a transaction.

 

The NFC protocol, for example, establishes a secure link quickly and conveniently at a point of sale. However, transactions that include sending additional data between the POS terminal and the portable device, such as additional payment information, coupon offers, coupon data, and the like, can continue for some time, during which the portable device is kept in the same location within centimeters of the POS terminal. Holding or setting the device near the POS terminal becomes inconvenient for users, so NFC is less desirable for longer transactions such as those that involve transferring more data than used by the payment information or use more time than used in the NFC connection establishment process.

 

The establishment of the NFC link, which occurs quickly, is referred to herein as an initial "bump" because the devices may touch each other momentarily when the NFC connection is being established. NFC is used herein as an example, and other types of proximity technology can be used in other embodiments.

 

In one or more embodiments, the NFC secure link can be used to establish a second secure link that uses a different protocol, such as WIFI 110, Bluetooth 112, or another wireless protocol that has more desirable characteristics for maintaining the link over time than NFC. The particular protocol that is used for the second link can be selected based on configured information, e.g., depending on the type of communication hardware available in the device, or according to user preferences, signal strength, the amount of data expected to be transferred, and so on.

 

Conducting a Secure Commercial Transaction

 

In Apple's patent FIG. 2 illustrated below shows us a portable device conducting a secure commercial transaction using a second air interface #110 (WIFI) or #112 (Bluetooth). The second air interface is different from the first air interface #114 (NFC) that was used to establish the secure link.

 

As an example, patent FIG. 2 shows the portable device conducting a secure commercial transaction using the WIFI air interface for a secure link that was established using NFC. In this way, purchase information may be transferred through the WIFI interface instead of the NFC interface. WIFI is more convenient than NFC for users, since the limited communication range of NFC requires the portable device to be in close proximity to the POS device, e.g., within 3 to 6 inches. The second air interface (NFC) can be used, for example, to send information such as offers by customers or merchants, coupon offers and redemptions, receipts, follow up information, and so on. The second air interface (WIFI or Bluetooth) link can be closed upon completion of the transaction(s) by, for example, sending a completion or termination message.

 

Apple's patent FIG. 2 further shows the secure element #108 passing encrypted credit card data (CC data) to the application processor. Normal, i.e., plaintext, credit card data (CC data) includes a credit card number, expiration date and other information. Encrypted credit card data includes an alias # 234 and other cryptographic data such as counter number, merchant ID, etc.

 

Generating an Alias

 

As described above, the confidentiality of data sent to the application processor may be compromised, e.g., by a rogue application. Therefore, the credit card data is encrypted by the secure element to produce encrypted cryptographic data. The secure element generates an "alias" for the credit card data, which is passed to the application processor instead of the unencrypted credit card data.

 

The alias is an identifier for the credit card data but can't be used to make a payment without valid crypto data #238 that corresponds to the alias. Thus, the alias need not be stored securely, because payments made with the alias are not accepted by the backend unless the corresponding crypto data is also supplied, e.g., in a request to process a payment.

 

Apple states that the crypto data may, for example, be a digitally-signed combination of one or more of the alias, a counter value that is incremented for each alias value, a random number, a merchant identifier, or any other value that is believed to be important.

 

The Shared Secret

 

Apple notes that the shared secret #207 may be, for example, a symmetric key distributed to the secure element at the time the device is manufactured, and loaded into the backend via secure communication behind a firewall.

 

In other embodiments, a cryptographic key exchange mechanism may be used to establish the shared secret. Therefore, the alias can be known by the application processor without compromising security. The crypto data is, in one or more embodiments stored in the secure element and used to generate the crypto data at the portable device based upon the alias received from the application processor. A user may enter the alias into the application processor and the alias is also known to the backend. The alias is, for example, provided to the user by the organization that operates the backend, e.g., an online merchant.

 

In one or more embodiments, when a request to make a transaction using the credit card is submitted to the backend server #414, the server determines whether the combination of the alias and crypto data are valid using a shared secret that is known to the secure element and the backend server.

 

The backend uses the shared secret (e.g., symmetric keys, public private keys, etc.) to verify the alias and the crypto data. The backend receives the alias from the portable device via the point of sale, combines the alias with other information as described above (e.g., a counter value known to both the backend and the secure element and so on).

 

The backend can then generate the same crypto data using the shared secret and received data, and compare the result with the received crypto data. If the comparison indicates that the values are the same, then the credit card that corresponds to the credit card alias is provided back to the partner #412, and the transaction proceeds as normal. Otherwise, the credit card alias is rejected and the transaction is denied.

 

Apple's patent FIG. 3 noted below shows us a flow chart of an example method of conducting a secure commercial transaction.

 

Making a Mobile Payment Online

 

In Apple's patent FIG. 4 noted below we're able to see an example method of making mobile payments online. A mobile device includes a secure element and a wallet #406, which is similar to the secure element of FIG. 2. Payment data #408, including the credit card alias, expiration date, and crypto CVV (e.g., credit card security code) is sent to the merchant which is analogous to the point of sale #116 of patent FIG. 2 above. The merchant sends an authorization request to a partner, e.g., a credit card network, and a backend server validates the payment information, e.g., credit card number, CVV, counter, alias, and any other information using a secret key that is known to both the backend server and the wallet. If the payment information matches corresponding values independently known to the backend server, then the server authorizes the transaction. Otherwise, the transaction is declined.

 

Patent Credits

 

Apple credits Ahmer Khan, Brian Tucker, David Haggerty and Scott Herz as the inventors of patent application 20140019367 which was originally filed in Q3 2012. To understand more about Apple's iWallet project, review our extensive iWallet Patent Archive.

 

A Note for Tech Sites covering our Report: We ask tech sites covering our report to kindly limit the use of our graphics to one image. Thanking you in advance for your cooperation. 

 

Patently Apple presents a detailed summary of patent applications with associated graphics for journalistic news purposes as each such patent application is revealed by the U.S. Patent & Trade Office. Readers are cautioned that the full text of any patent application should be read in its entirety for full and accurate details. Revelations found in patent applications shouldn't be interpreted as rumor or fast-tracked according to rumor timetables. About Making Comments on our Site: Patently Apple reserves the right to post, dismiss or edit any comments.

 

New on Patent Bolt this Week

 

Motorola Reveals a Crazy Future Flexible, Rollable Smartphone

LG Reveals a Future Smartphone with a Multifunctional Backside Control Button

Motorola Invents New 3D Display for their Xoom Tablet & Beyond

Google Invents Digital Photo Frame with Dial-a-Tag Functionality