WO2012098555A1

WO2012098555A1 - Direct carrier billing

Info

Publication number: WO2012098555A1
Application number: PCT/IN2011/000045
Authority: WO
Inventors: Arjun SATYAPAL; Michael Morrissey; Indradeep SAHA
Original assignee: Google Inc.
Priority date: 2011-01-20
Filing date: 2011-01-20
Publication date: 2012-07-26
Also published as: WO2012098556A1

Abstract

A method for purchasing services from a user device is provided. Such a device may provide a way to provide for billing for the purchases at a service provider such as a wireless carrier. A transaction system for purchasing services from a user device is also provided.

Description

DIRECT CARRIER BILLING

BACKGROUND

Field

[001] Embodiments relate generally to systems for billing users for purchases.

Background

[002] Recently, mobile devices such as smart phones have become prevalent. Smart phones provide the functionality of general purpose computers in addition to providing functions for making phone calls. Applications for smart phones have also become very popular, and applications stores for purchasing applications for these devices are becoming more prevalent.

[003] Generally, online stores for purchasing applications use credit card billing or billing to an online payment clearing house, which in turn bills to a credit card. But requiring that users divulge their credit card information can discourage some purchases because entering the credit card information can be cumbersome (especially on a mobile device), the credit card information is highly Confidential, and some users do not have credit cards.

BRIEF SUMMARY

[004] Systems and methods for billing users for purchases of goods and services are provided. Embodiments relate billing user purchases to a service provider associated with the user.

[005] In an embodiment, a computer-implemented method of billing a user is provided that includes receiving a request to purchase an application and transaction parameters from a device of the user. The user's device is associated with a wireless carrier. The method further includes determining whether the purchase request meets transaction criteria, wherein the transaction criteria are determined based on the transaction parameters, and in response to the purchase request meeting the transaction criteria, sending a reserve request to a server of the carrier, the reserve request including an authorization token identifying the user and a purchase price associated with the application. The carrier server is configured to reserve the purchase price from an account associated with the user in response to the reserve request.

[006] In another embodiment, a transaction system is provided that includes, among other things, a marketplace engine configured to receive a request to purchase an application and transaction parameters from a device of the user. The user's device is associated with a wireless carrier. The transaction system further includes a payment processing engine configured to receive the transaction parameters from the marketplace engine and to determine whether the purchase request meets transaction criteria, wherein the transaction criteria are determined based on the transaction parameters, and a billing gateway coupled to the payment processing engine and configured to send a reserve request to a server of the carrier, the reserve request including an authorization token identifying the user and a purchase price. The carrier server is configured to reserve the purchase price from an account associated with the user in response to the reserve request.

[007] In another embodiment, a computer-implemented method of billing a user is provided that includes receiving at a wireless carrier a request to bill a user's account for the purchase of an application. The user's account is associated with the wireless carrier and the user. In an embodiment, the computer-implemented method further includes, responsive to the receiving at the wireless carrier, generating an authorization token and transaction parameters, transmitting the application token and transaction parameters to a mobile device of the user, receiving a request to authorize a purchase of the application that includes the authorization token and a purchase price for the application, and determining whether the purchase request meets transaction criteria, wherein the transaction criteria are determined based on the transaction parameters. The method further includes, responsive to determining that the purchase price meets the criteria, reserving the purchase price in the user account, and transmitting a confirmation message indicating that the purchase price has been reserved in the user account.

BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

[008] Embodiments are described, by way of example only, with reference to the accompanying drawings. In the drawings, like reference numbers may indicate identical or functionally similar elements. The drawing in which an element first appears is typically indicated by the leftmost digit or digits in the corresponding reference number.

[009] FIG. 1 is a diagram of an exemplary transaction system suitable for practicing an embodiment;

[0010] FIGS. 2A and 2B are message flow diagrams illustrating synchronous operation of an embodiment of a transaction system;

[0011] FIG. 3 is a flow chart illustrating an example method in accordance with an embodiment;

[0012] FIG. 4 is a flow chart illustrating another example method in accordance with an embodiment

[0013] FIG. 5 illustrates a data table for storing subscriber account information in accordance with an embodiment;

[0014] FIG. 6 illustrates a data table for storing transaction information for purchasers of applications in accordance with an embodiment;

[0015] FIG. 7 illustrates a data table for storing purchasing transaction information by a service provider in accordance with an embodiment; and

[0016] FIG. 8 is a block diagram schematically illustrating an example computer system in which embodiments can be implemented.

[0017] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate the embodiments, and together with the description further serve to explain the principles and to enable a person skilled in the relevant art(s) to make and use the invention.

DETAILED DESCRIPTION

J. Introduction

[0018] Embodiments are described allow users to make purchases from an online market and to bill a service provider for the purchases. For example, in one embodiment, a transaction system is provided that bills purchases of applications to a service provider associated with the user. In a further embodiment, the user's device can interact with the service provider to obtain an encrypted token. Thereafter, when the user uses the device to interact with a transaction to make a purchase, the user's device sends the token to the transaction server. Without having to decrypt the token, the transaction server can then send the token along with the purchase price to the service provider, which then decrypts the token to identify the user and bills an account associated with the user.

[0019] While description is herein is made with reference to illustrative embodiments for particular applications, it should be understood that embodiments are not limited thereto. Other embodiments are possible, and modifications can be made to the embodiments within the spirit and scope of the teachings herein and additional fields in which the embodiments would be of significant utility. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the relevant art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0020] It would also be apparent to one of skill in the relevant art that the embodiments, as described herein, can be implemented in many different embodiments of software, hardware, firmware, and/or the entities illustrated in the figures. Any actual software code with the specialized control of hardware to implement embodiments is not limiting of the detailed description. Thus, the operational behavior of embodiments will be described with the understanding that modifications and variations of the embodiments are possible, given the level of detail presented herein.

[0021] In the detailed description herein, references to "one embodiment," "an embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

II. System Overview

[0022] FIG. 1 is a diagram of an exemplary transaction system 100 suitable for practicing an embodiment. In the example shown in FIG. 1, transaction system 100 includes a service provider 120, a user device 106, a transaction server 1 10, and a network 102. [0023] Service provider 120 provides one or more services for user device 106. For example, user device 106 may be a mobile phone, and service provider 120 may be a wireless carrier that provides cellular communication services for a mobile device. The services provided by service provider 120 may include wireless voice and data communications services.

[0024] Service provider 120 includes application server 122, billing server 124, and subscriber account database 126. Application server 122 hosts the services to be supplied to users. Billing server 124 hosts applications for billing users for the services supplied to users by service provider 120.

[0025] Subscriber account database 126 stores account information for billing users of services provided by service provider 120. For example, subscriber account database 126 responds to queries from components of service provider 120, such as billing server 124.

[0026] User device 106 can be a mobile device such as a hand held device (e.g., a smart phone or a personal digital assistant.). Alternatively, user device 106 can be a desktop device such as a personal computer. The user of user device 106 has an associated service provider 120, where the association with service provider can include subscribing to voice and data cellular communications services hosted on applications server 122 of service provider 120, and having a subscriber account stored in subscriber account database 126 that is used for billing the user for services provided by service provider 120.

[0027] Transaction server 110 can include a marketplace engine 1 18 and a billing processor 1 15. Billing processor 115 includes a payment processing engine 1 14, a purchaser account database 116, and a billing gateway 112.

[0028] Marketplace engine 118 provides a purchasing point for obtaining services used with user device 106. For example, marketplace engine 118 can host an application store that offers software programs that can be hosted on user device 106. Marketplace engine 118 can host other services such as social and/or business networking services, online magazine and newspaper services, and online shopping services. In particular, one or more of the services offered by marketplace engine 118 are accessible from and are compatible with user device 106. While embodiments can accommodate a variety of services as offerings from marketplace engine 1 18, for simplicity, an example embodiment will be described in which the offered services are applications compatible with user device 106.

[0029] The services offered to users from marketplace engine 1 18 may be offered for free or may be offered to users for a fee. Billing processor 115 includes one or more servers that host applications for billing users for services purchased from marketplace engine 118. As shown in FIG. 1 , billing processor 115 includes payment processing engine 1 14, purchaser account database 116, and billing gateway 1 12.

[0030] Payment processing engine 1 14 hosts applications that allow customers to selection between one or more forms of payment (FOP) for purchases of services offered by marketplace engine 118. For example, payment processing engine 1 14 can be configured to accept payment by credit card and payment by billing to an account on a service provider associated with the user as FOPs.

[0031] Purchaser account database 116 stores transaction information regarding purchases made by the user from marketplace engine 1 18. For example, payment processing engine 1 14 can access purchaser account database 1 16 to record information regarding specific transactions and actions taken by marketplace engine 1 18 and payment processing engine 1 14 in support of those transactions.

[0032] Billing gateway 112 hosts applications that support communicating transaction information between service provider 120 and transaction server 110. Network 102 connects the components of transaction system 100 to provide a communications path between user device 106, transaction server 110, and service provider 120. Network 102 can include one or more networks, such as a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof.

[0033] Transaction system 100 can be configured to perform methods in accordance with embodiments. The description of the example methods includes a description of additional exemplary features of transaction server 110 and service provider 120.

III. Methods

[0034] FIGS 2A and 2B illustrate messages transmitted to and from transaction server

110 in an embodiment. The messages transmitted between components of the transaction server can utilize different message protocols provided that each component is configured to transmit a message compatible with the receiver. In an embodiment, messages between components of transaction server 110 are configured to generate and receive messages using Single Object Access Protocol (SOAP) messages over an HTTP connection. FIGS. 2A and 2B will be described further with respect to FIG. 3.

[0035] FIG. 3 is a flowchart of an exemplary method 300 for billing a user for a purchase of an application, according to an embodiment. For ease of explanation, method 300 is described with respect to transaction system 100 of FIG. 1 and service provider 120 and user device 106 of FIGS. 1 and 2, but embodiments of the method are not limited thereto.

[0036] Method 300 begins in block 302 with generating and transmitting an authorization token in response to a request from a user. In an embodiment, the user can use user device 106 to. transmit provisioning request 250 to service provider 120.

[0037] In response to receiving provisioning request message 250, service provider 120 can determine whether provisioning request 250 was transmitted by a user who is a subscriber of service provider 120, and can generate an authorization token.

[0038] Service provider 120 can be configured to extract information identifying the user from provisioning request 250. In an embodiment, billing server 124 obtains an identifier such as an IMEI or IMSI from the radio interface layer of a call from user device 106 to service provider 120 using an application programming interface call.

[0039] In another embodiment, user device 106 is configured to transmit a provisioning request that contains information identifying the user of user device 106, and billing server 124 extracts the user's identifying information from the provisioning message. Billing server 124 can, be configured to obtain subscriber information for the user subscriber based on the identifying information obtained from provisioning request 250.

[0040] FIG. 5 shows an example data table 500 that can be stored in subscriber account database 126. Records 502a and 502b of table 500 contain subscriber information for subscribers with subscriber IDs 012321321321 and 037653486211 respectively. Field 504 of each record contains the subscriber numbers while field 506 of each record contains the IMSI or IMEI number for a mobile device associated with user. Fields 508, 510, 512, and 514 contain billing information for the respective subscriber ID. For example, field 510 indicates that subscriber 012321.321321 is not authorized to bill services to service provider 120, while field 510 indicates that subscriber 037653486211 is authorized to perform carrier billing.

[0041] In an embodiment, billing server 124 can be configured to query subscriber account database 126 with an identifier associated with user device 106, such as the user's subscriber ID or IMSI or IMEI numbers, to obtain the subscriber billing information for the user included in fields 508-514. In an embodiment, service provider 120 queries the subscriber account database 126 with a user identifier and determines from field 510 whether the user of user device 106 is authorized to bill service provider 120 for services provided by transaction server 110. In response to a determination that the user of user device . 106 is so authorized, service provider 120 can be configured to transmit an authorization token to user device 106. The authorization token can include information identifying service provider 120, user information identifying the user as a subscriber of the service provider, and transaction parameters based on subscriber billing information for the user.

[0042] In an embodiment, the transaction parameters based on the subscriber information for the user can include information indicating that the user is allowed to conduct carrier billing with service provider .120, information identifying the user's transaction limit for carrier billing with service provider 120, and information identifying the currency to be used for carrier billing transactions with service provider 120. For example, the transaction parameters can specify that the user is allowed to conduct carrier billing transactions with service provider 120, that the transaction limit for the user's billing transactions with wireless carrier is 100 United States Dollars (USD), and that the currency or currencies to be used for carrier billing transactions are, for example, USD only or USD and Euros, respectively.

[0043] In an embodiment, some or all of the information in the authorization token can be encrypted using one or more encryption keys. For example, the personal information identifying the user can be encrypted using a public encryption key controlled by service provider 120. Encryption using a public encryption key can be used to control access to private information of users, as the information can be effectively opaque to entities that do not have access to the corresponding private encryption key. [0044] In an embodiment, information identifying service provider 120 can be signed using a cryptographic signature process to provide a method of authenticating service provider 120 as source of the authorization token. For example a cryptographic signature can be provided by encrypting all or portions of the authorization token using a private encryption key controlled by an operator of the service provider 120. Encryption with the private encryption key associated with service provider allows other entities to verify that service provider 120 is the source of information by decrypting the signing information using the publicly available . public encryption key that corresponds to the private encryption key of service provider 120.

[0045] While encryption schemes using public key cryptography have been described above, embodiments are not limited to these examples, and other encryption schemes, for example schemes using symmetric key algorithms, can also be used and access to information can be controlled by limiting the sharing of decryption keys.

[0046] As shown in FIG. 2 A, upon successful generation of the authorization token, service provider 120 is configured to transmit a provisioning response message 252 including the authorization token and the transaction parameters to user device 106.

[0047] In step 304 of FIG. 3, transaction server 110 receives a purchase request message

202 from user device 106. Purchase request message 202 can include the authorization token received from service provider 120, purchase selection information identifying an application that user wants to purchase from the marketplace, and information identifying the FOP the user has selected for the transaction. In another embodiment, the user can select the FGP at another point during the transaction (e.g., during interactions with payment processing engine 114).

[0048] In an embodiment, marketplace engine 118 of transaction server 110 is configured to host applications that provide services for purchase by users of user device 106. For example, user device 106 can be a smart phone capable of hosting applications that run on the Android Mobile Operating System, and marketplace engine 1 18 can host applications that present an online forum for purchasing Android compatible applications.

[0049] Marketplace engine 118 can be configured to transmit data over network 102 to user device 106 that causes user device 106 to display a graphical user interface. Using the graphical user interface, the user can browse and review applications offered for sale from marketplace engine 118 from user device 106. The user can also select applications for purchase using the graphical user interface. In an embodiment, the user can operate the graphical user interface on his smart phone to indicate that he intends to purchase a selected application offered from marketplace engine 1 18. In an embodiment, marketplace engine 1 18 can transmit data to user device 106 using the Hypertext Transfer Protocol (HTTP) format and user device 106 can display the information using an HTTP compatible browser. In an embodiment, marketplace engine 118 can be configured to display a graphical element on user device 106 allowing the user to select billing to a service provider in response to receiving an authorization token issued by the service provider in purchase request message 202.

[0050] As shown in FIG. 2A, marketplace engine 118 can be configured to transmit a purchase request message 204 to billing processor 115 in response to receiving purchase request message 202. Purchase request message 204 includes the authorization token and the purchase selection information included in purchase request message 202. In an embodiment, marketplace engine 118 is configured to include purchase parameters in request message 204. The purchase parameters may include, for example,, the purchase price of the selected application, and the currency acceptable for purchasing the application. Example purchase parameters can describe the price of a selected application as, for example 1.99 USD, and the acceptable currency for purchasing the application as, for example, USD or the Euros.

[0051] At decision block 306 of method 300, a determination is made whether the request message meets transaction criteria that are based on the transaction parameters. In an embodiment, determining whether transaction criteria have been met can happen after a user elects carrier billing as his FOP. For example, payment processing engine 114 can provide a list of different FOPs, including carrier billing. If the user elects carrier billing, decision block 306 is executed.

[0052] Referring now to FIG. 2B, payment processing engine 1 14 of billing processor

115 can be configured to receive purchase request message 204. In an embodiment, payment processing engine 1 14 is configured to determine whether purchase request message 204 meets transaction criteria based on the transaction parameters. [0053] A purchase request message meets the transaction criteria when the purchase parameters included in the request message, optionally supplemented with other purchase information, meet all of the transaction criteria. The transaction criteria are derived from the transaction parameters. For example, one of the transaction criteria might specify that purchases using carrier billing are not to be authorized when the purchase price exceeds some fraction of the transaction limit, such as 50 per cent of the carrier billing transaction limit included in the transaction parameters. A transaction criterion might specify that carrier billing is not to be authorized when the purchase parameters require that the acceptable currency for purchasing the application for an application does not match one of the currencies specified in the transaction parameters.

[0054] For example, payment processing engine 114 can be configured to process the information describing the carrier billing transaction limit as 100 USD to obtain a transaction criterion to not authorize carrier billing when the purchase price is greater than 100 USD. In another example, the transaction criterion might specify that purchases using carrier billing are not to be authorized when the purchase price exceeds some fraction of the transaction limit, such as 50 per cent of the carrier billing transaction limit. In another example, the transaction criteria might specify that carrier billing is not to be authorized when the purchase parameters require that the acceptable currency for purchasing the application does not match one of the currencies specified in the transaction parameters. In addition, the transaction criteria might specify that the subscriber is ineligible for carrier billing with the service provider unless the purchase parameters indicate that the user has elected carrier billing and service provider 120 has authorized carrier billing for the user.

[0055] Determining whether a request message meets the transaction parameters can include determining whether the request message is valid. For example, a request message can be determined to be invalid if the authorization token is not included, if the authorization token or other information does not contain a valid cryptographic signature of a service provider with which the marketplace engine engages in carrier billing, or if one or more pieces of information expected in a request message are missing.

[0056] In an embodiment, the authorization token includes information describing an expiration period for the authorization token, and determining whether the request message is valid includes comparing the time information in the authorization token to the current date and time to determine whether the expiration period has expired.

[0057] In response to a determination that the request message does not meet the transaction criteria based on the transaction parameters, method 300 proceeds along the 'No' branch from decision block 306 to rejecting the purchase request in block 320. Payment processing engine 114 can be configured to transmit carrier billing denied message 222 to marketplace engine 118. Marketplace engine 118 can be configured to display an indication on user device 106 that the purchasing transaction was unsuccessful.

[0058] Upon a determination that the transaction criteria have been met, method 300 continues along the 'Yes' branch from decision block 306 to block 308 with sending the authorization token and the purchase price to service provider 120.

[0059] In an embodiment, billing gateway 112 can be configured to transmit authorization request message 208 to service provider 120. Billing gateway 1 12 can be configured to include the authorization token, the purchase price, and an identifier for the transaction in authorization request message 208.

[0060] Payment processing engine 114 of billing processor 1 15 can record information regarding the purchase transaction and the sending of authorization requests in purchaser account database 116.

[0061] FIG. 7 shows an example data table 700 for recording purchaser transactions in purchaser account database 1 16 of the transaction server. Record 702 of table 700 contains the information for transaction 0001236 for the user having user ID 00002. Field 706 contains the time-stamp information indicating the time of generating the reservation request for purchasing an application. Field 708 contains information identifying the application selected for purchase by user 00002, and Field 710 contains the purchase price for the selected application. Field 712 contains information describing the time of the last request to capture the purchase price in an the user's account with service provider 120. Field 714 indicates that the billing processor 115 has not received an acknowledgement from service provider 120 that the purchase price has been captured in response to a capture request sent to service provider 120.

[0062] In an embodiment, billing gateway 1 12 is configured to communicate with service provider 120 using an interface compatible with the communication systems of service provider 120. Billing gateway 112 can be configured to communicate with service provider 120 using a different interface and different protocols than those used to communicate with the payment processing engine 1 14. For example, the application interface and protocols selected for communicating with service provider 120 can be selected to reduce or eliminate changes to service provider 120 for implementing an embodiment.

[0063] Method 300 continues in decision block 310 with reserving the purchase price in the user's subscriber billing account on service provider 120. In an embodiment, billing server 124 of service provider 120 can be configured to update subscriber account database 126 to indicate the reservation of the purchase price in the user's subscriber account upon receiving reservation request message 208 from billing gateway 112.

[0064] Referring now to FIG. 6, database table 600 shows an example table for storing billing transactions in subscriber account database 126. Database table 600 includes records 606a, 606b, and 606c all relating to a user with a user ID of 037653486211. • Field 604 of records 602a and 602b contains a transaction ID for identifying the transaction. Field 606 indicates the reservation amount of 1.99 USD for record 602a, which corresponds to the purchase price for the application selected for purchase. Field 608 contains a time stamp indicating the date and time of making the reservation. Field 610 specifies the time and date when a reserve request was confirmed.

[0065] In an embodiment, billing server 124 reserves the purchase price by creating a new record 602c in table 600, updating field 606 of the new record to indicate reservation of the purchase price, and updating field 608 of the new record to indicate the date and time the reservation is made. In addition, billing processor 124 can update table 500 (shown in FIG. 5) by deducting the reservation amount from the transaction limit for the subscriber in field 512.

[0066] In an embodiment, service provider 120 can be configured to generate reservation granted message 210 when service provider 120 grants the authorization request, and can be configured to send reservation granted message 210 to billing processor 1 15. The reservation granted message can include time stamp information indicating the time the service provider 120 granted the reservation, information indicating the transaction amount reserved by service provider 120, and information identifying the transaction. In one embodiment, the transaction identifying information can include the authorization token provided in the authorization request 208. In response to receiving reservation granted message 210, billing gateway 112 can send reservation granted message 212 to .payment processing engine 114.

[0067] In an embodiment, service provider 120 can be configured to transmit reservation denied message 218 to billing processor 115 upon a determination that the request for carrier billing for the purchase will not be granted. For example, billing server 124 can be configured to deny a reservation of the billing price to the user's subscriber account if the authorization token has expired or is missing from authorization request message 208.

[0068] One or more components of billing processor 1 15 can be configured to receive reservation denied message 218. In an embodiment, billing gateway 112 is configured to transmit carrier billing denied message 220 to payment processing engine 1 14 in response to receiving reservation denied message 218 from service provider 120.

[0069] In an embodiment, payment processing engine 1 14 can be configured to send carrier billing denied message 222 to marketplace engine 1 18 in response to receiving carrier billing denied message 220 or to send reservation granted message 214 to marketplace engine 1 18 in response to receiving reservation granted message 212. Upon receiving carrier billing denied message 220, marketplace engine 118 can provide an indication to user device 106 that carrier billing for the purchase of the selected application has been denied.

[0070] In an embodiment, marketplace engine 118 is configured to cause user device 106 to display a user interface element that indicates that carrier billing for the application selected by the user has been denied in response to receiving carrier billing denied message 222.

[0071] Method 300 continues in block 312 with sending the purchased application to the user's device.

[0072] In an embodiment, marketplace engine 118 can be configured to respond to a determination that the transaction criteria are met by transmitting data 216 to user device 106 to initiate an installation or activation of the selected application for the user device . 106. Any means can be employed to install or activate the application on the user's device. [0073] For example, in an embodiment, marketplace engine 1 18 can be configured to grant access to the user to download the application from a secure download server and to signal the grant of permission using a graphical user element displayed on user device 106. In another embodiment, marketplace engine 1 18 can allow users of user device 106 to download applications upon request, but can grant permission to download information for activating the application, such as a registration key, only upon receiving an indication that the service provider has authorized carrier billing. In an embodiment, marketplace engine 1 18 can provide information identifying the purchase transaction to user device 106.

[0074] Method 300 then continues in decision block 314 with a determination of whether a cancel request has been received during a time period.

[0075] In an embodiment, marketplace engine 118 can be configured to detect that a purchased application has been uninstalled or deactivated, and one or more components of transaction server 110 can be configured to determine whether the deactivation or uninstall has occurred within or outside of the trial period.

[0076] In an embodiment, payment processing engine 1 14 can be configured to update purchaser account database 116 in response to receiving a message requesting reservation of the purchase price for an application. Payment processing engine 1 14 can be configured to retrieve the time of reservation from purchaser account database 116 in response to receiving cancellation order message 230, and to determine whether the time period has expired by comparing the retrieved reservation time to the current time. In embodiments, the trial period can be a time period having a predetermined duration, for example 24 hours. The trial period can begin at a time based on the time of granting of the reservation request by service provider 120. In another embodiment, the start of the trial period is based on the time that the application was installed on user device 106. For example, the time period can be a trial period during which users can evaluate applications purchased from marketplace engine 118. In an embodiment, transaction server 1 10 is configured to allow users to reject an application for specific reasons, such as the application containing malware (e.g. viruses or spyware) or the application being determined to be unsuitable for an advertised use. [0077] In an embodiment, marketplace engine 1 18 can be configured to receive an indication that the user has uninstalled applications from user device 106. For example, user device 106 can be configured to send cancel request message 228 to marketplace engine 1 18 in response to a user uninstalling the application from the user device. Marketplace engine 1 18 can be configured to send cancellation order message 230 to billing processor 115 in response to receiving cancel request message 228. In an embodiment, the cancellation request messages can contain information identifying the user's reason for refusing the application, information identifying the purchasing transaction for the initial purchase of the application, and information confirming that the application has been uninstalled. Personal information related to the user's identity can be omitted from the cancellation request messages. Various methods can be used to uninstall or deactivate an application on user device 106. In an embodiment, uninstalling is accomplished by deleting one or more components of the application from user device 106. In another embodiment, marketplace engine 1 18 can deny access to one or more services used by the application from user device 106. In another embodiment, the application can include a component that deactivates the application after a time period, and the marketplace engine 118 can deny access to one or more services that allow continued operation of the application after the expiration of the time period.

[0078] Method 300 continues to block 322 in response to a cancellation request being received during the trial period.

[0079] In an embodiment, payment processing engine 1 14 can be configured to receive cancellation order message 230 and can be configured send cancellation order message 232 to billing gateway 1 12 in response to receiving cancellation order message 230.

[0080] Billing gateway 1 12 can be configured to send a cancellation request message 234 to service provider 120 in response to receiving cancellation order message 232. The service provider can be configured to respond to cancellation request message 234 by releasing the reservation of funds set aside for the purchase of the application. For example, billing server 124 can be configured to release the reserved purchase price for the canceled transaction by clearing the reserved amount stored in field 606 of table 600 for the corresponding transaction, and by incrementing the transaction limit for the respective user in field 512 of table 500 by the purchase price for the application. [0081] In an embodiment, billing gateway 112 can be configured to send a capture request message 226 to service provider 120 in response to a determination that the trial period has expired and that marketplace engine 1 18 has not received cancel request message 228. The service provider can be configured to respond to capture request message 234 by billing the client for the purchase price for the application.

[0082] In an embodiment, marketplace engine 118 causes billing gateway 112 to send a cancellation request message to service provider 120 in response to a determination that a cancellation request has been made during the trial period. Method 300 then continues in block 324 with release of the purchase price from the user's account. In an embodiment, billing server 124 is configured to cancel the reservation amount for the purchase by updating tables in database 122. In a further embodiment, payment processing engine 1 14 can be configured to update table 700 to indicate that the purchase transaction has been canceled.

[0083] Method 300 continues along the 'No' path from decision block 314 to block 316 with the sending of a request to capture the purchase price from the user's service provider account in response to a determination by the marketplace engine 118 that no cancellation request has been made during the trial period to cancel the purchase. In an embodiment, billing gateway 1 12 is configured to send a cancellation request message to service provider 120 in response to the determination.

[0084] Method 300 then continues in step 318 with capturing of the purchase price from the user's account if a cancellation request is received within a cancellation window. In an embodiment, the duration of the cancellation window is compatible with the trial period implemented by the transaction server. For example, a cancellation window implemented by billing server 124 of 30 or 48 hours after reservation of the purchase price is compatible with a trial period of 24 hours after a reservation request implemented on transaction server 1 10. In an embodiment, billing server 124 of service provider 120 can configured to allow its subscribers to make requests for cancellations of a purchasing transaction to the service provider during the cancellation period, even though the trial period for initiating cancellations through transaction server 110 has expired. [0085] In an embodiment, billing server 124 can be configured to capture the reserved purchase price in response to receiving capture request message 226 within the cancellation window.

[0086] Capture is the process by which the service provider 120 bills the client for the purchase price of the services. In an embodiment, during capture, the reserve amount is cleared from the subscriber account database 126, but the transaction limit is not increased by the reservation amount. Referring again to FIGS. 5 and 6, billing server 124 can be configured to capture the reserved amount by adding the reserve amount to the user's bill and to clear the reserve amount from field 606 of table 600. In an embodiment, the transaction limit in field 512 of table 500 (shown in FIG. 5) is not increased by the reservation amount during capture.

[0087] FIG. 4 is a flow chart that shows an embodiment of an example method 400 for billing the user using settlement files, according to an embodiment. Method 400 begins in block 402 with comparing a daily settlement file with a list of capture requests.

[0088] In an embodiment, service provider 120 updates subscriber account database 126 when a reservation request is made, when a cancellation of a reservation is completed, and when reservations are captured. Referring again to FIG. 6, fields 606, 608, and 610 indicate that for transaction 1232, payment engine 1 14 has requested reservation of the purchase price of 1.99 USD, and that confirmation of the reservation has not been confirmed by service provider 120. Billing server 124 can be configured to periodically generate a settlement file based on information recorded in subscriber account database 126. In an embodiment, billing server 124 is configured to generate settlement files on a daily basis and to aggregate transaction information into monthly settlement files.

[0089] In an embodiment, service provider 120 can be configured to send the settlement file to a component of transaction server 110 that is configured to compare the settlement file with a list of capture requests (e.g., payment processing engine 114).

[0090] As was described above with reference to FIG. 3, payment processing engine 114 can be configured to update purchaser account database 1 16 with information regarding reservation requests and capture requests generated during purchasing transactions. Payment processing engine 114 can be configured to generate a list of capture requests based on transaction information retrieved from database 1 16. [0091] For example, payment processing engine 1 14 can be configured to generate a list of outstanding captures based on information stored in table 700 shown in FIG, 7.

[0092] Method 400 continues in decision block 404 with an identification of any discrepancies between the capture list and the settlement file based on the comparison performed in step 402. If no discrepancies are identified, method 400 proceeds along the 'No' branch from decision block 404 and ends in termination block 414.

[0093] In an embodiment, a capture request discrepancy can include any transactions for which transaction server 110 had forwarded a capture request to service provider 120 to but for which the purchase price was still indicated as reserved in the database. A capture request discrepancy can also include any capture requests for which the transaction server had not received an acknowledgement from service provider 120 and for which confirming transaction information is absent present in the settlement file.

[0094] In response to identifying a capture request discrepancy method 400 proceeds along the 'Yes' branch from decision block 404 to block 406, With the retrying of unfulfilled capture requests. In an embodiment, payment processing engine 1 14 can retry the sending of capture request message 226 to service provider 120.

[0095] Method 400 continues in decision block 408 with a determination of whether one or more retries of a capture request were successful within a window period. In an embodiment, the window period is set at 48 hours and recapture requests are retried during the window of 48 hours after the first reservation request. Payment processing engine 114 can be configured to determine, from settlement files and from information stored in purchaser account database 116, whether all retries of a capture request were unsuccessful for the duration of the window period. Upon a determination that the retries were unsuccessful, method 400 continues along the 'No' path from decision block 408 to blocks 410 and 412, with releasing the purchase price from the user's account and uninstalling the application from the user's device, respectively. In a further embodiment ■ of the invention, marketplace engine 118 can be configured to initiate uninstalling or deactivating of the purchased application on user device 106.

[0096] In another embodiment, step 412 may not be executed. For example, it may be decided that, as a policy, applications will not be uninstalled from a user's device in response to a billing failure (e.g., to maintain good relations with the user). [0097] In an embodiment, payment processing engine 1 14 updates purchaser account database 116 to indicate that the reservation of the purchase price for the selected application has been canceled. Payment processing engine 114 can also be configured to forward a cancellation request message through billing gateway 112 to service provider 120. Service provider 120 can be configured to update subscriber account database 126 to cancel the reservation request for the transaction by the user to purchase the application.

[0098] In an embodiment, payment processing engine 114 is configured to send carrier billing denied message 222 to marketplace engine 1 18. As discussed above, marketplace engine 1 18 can be configured to uninstall or deactivate the purchased application on user device 106 in response to receiving carrier billing denied message 222. In an embodiment, any of the methods described above for deactivating the application on user device 106 can be employed.

[0099] If a retry of a capture request is successful, method 400 ends by proceeding along the 'Yes' path to termination block 416. In an embodiment, payment processing engine 114 updates purchaser account database 116 to reflect that the capture request was successful.

[00100] In an embodiment, service provider 120 updates subscriber account database 126 when a reservation request is made, when a cancellation of a reservation is completed, and when reservations are captured. Referring again to FIG. 6, field 610 indicates that for transaction 1232, 1.99 USD has been reserved but not added to the user's bill. Billing server 124 can be configured to periodically generate a settlement file based on information recorded in subscriber account database 126. In an embodiment, billing server 124 is configured to generate settlement files on a daily basis and to aggregate transaction information into monthly settlement files.

[00101] In an embodiment, a service provider sends the settlement file to a component of transaction server 1 10, and transaction server 110 compares the settlement file with a list of capture requests. As discussed above, in an embodiment, payment processing engine 1 14 updates purchaser account database 1 16 with information regarding reservation requests and capture requests. Payment processing engine 1 14 can be configured to generate a list of capture requests based on capture request information retrieved from database 1 16. Payment processing engine 1 14 can compare the capture request list to the settlement file.

[00102] Alternatively, payment processing engine 114 can determine whether the purchase request meets transaction criteria by receiving a message from another component that contains the result of a determination that the purchase parameters meets the transaction criteria. For example, the transaction parameters in purchase request messages 202 and 204 can be made effectively opaque to marketplace engine 118 and payment processing engine 1 14 by encrypting the transaction parameters to limit access to personal user information. In an embodiment, one or more entities^ such as the billing gateway or a server of the service provider can be configured to decrypt the transaction parameter information and to determine whether the purchase parameters meet the transaction criteria based on the transaction parameters.

[00103] In an embodiment, transaction server 110 can be configured to receive a message communicating the result of a determination by service provider 120 that the purchase parameters meet the transaction criteria. For example, payment processing engine 114 can send purchase request message 206 to billing gateway 1 12. Purchase request message 206 can include the authorization token and the purchase parameters. In response to receiving purchase request message 206, the billing gateway can generate authorization request message 208 that includes the authorization token and the purchase parameters and can transmit authorization request message 208 to service provider 120.

VI. Example Computer System Implementation

[00104] Embodiments shown in FIGS. 1-7, or any part(s) or function(s) thereof, may be implemented using hardware, software modules, firmware, tangible computer readable media having instructions stored thereon, or a combination thereof and may be implemented in one or more computer systems or other processing systems.

[00105] FIG. 8 illustrates an example computer system 800 in which embodiments, or portions thereof, may be implemented as computer-readable code. For example, the servers and components included in service provider 120, transaction server 1 10, and user device 106 in FIG. 1 can be implemented in computer system 800 using hardware, software, firmware, tangible computer readable media having instructions stored thereon, W

22 or a combination thereof and may be implemented in- one or more computer systems or other processing systems. Hardware, software, or any combination of such may embody any of the modules and components in FIG. 1.

[00106] If programmable logic is used, such logic may execute on a commercially available processing platform or a special purpose device. One of ordinary skill in the art may appreciate that embodiments of the disclosed subject matter can be practiced with various computer system configurations, including multi-core multiprocessor systems, minicomputers, mainframe computers, computer linked or clustered with distributed functions, as well as pervasive or miniature computers that may be embedded into virtually any device.

[00107] For instance, at least one processor device and a memory may be used to implement the above described embodiments. A processor device may be a single processor, a plurality of processors, or combinations thereof. Processor devices may have one or more processor "cores."

[00108] Various embodiments are described in terms of this example computer system 800. After reading this description, it will become apparent to a person skilled in the relevant art how to implement embodiments using other computer systems and/or computer architectures. Although operations may be described as a sequential process, some of the operations may in fact be performed in parallel, concurrently, and/or in a distributed environment, and with program code stored locally or remotely for access by single or multi-processor machines. In addition, in some embodiments the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.

[00109] Processor device 804 may be a special purpose or a general purpose processor device. As will be appreciated by persons skilled in the relevant art, processor device 804 may also be a single processor in a multi-core/multiprocessor system, such system operating alone, or in a cluster of computing devices operating in a cluster or server farm. Processor device 804 is connected to a communication infrastructure 806, for example, a bus, message queue, network, or multi-core message-passing scheme.

[00110] Computer system 800 also includes a main memory 808, for example, random access memory (RAM), and may also include a secondary memory 810. Secondary memory 810 may include, for example, a hard disk drive 812, removable storage drive 814. Removable storage drive 814 may comprise a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, or the like. The removable storage drive 814 reads from and/or writes to a removable storage unit 818 in a well known manner. Removable storage unit 818 may comprise a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 814.. As will be appreciated by persons skilled in the relevant art, removable storage unit 818 includes a computer usable storage medium having stored therein computer software and/or data.

[00111] In alternative implementations, secondary memory 810 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 800. Such means may include, for example, a removable storage unit 822 and an interface 820. Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units 822 and interfaces 820 which allow software and data to be transferred from the removable storage unit 822 to computer system 800.

[00112] Computer system 800 can include a display interface 832 for interfacing a display unit 830 to computer system 800. Display unit 830 can be any device capable of displaying user interfaces according to this invention, and compatible with display interface 832. Examples of suitable displays include liquid crystal display panel based device, cathode ray tube (CRT) monitors, organic light-emitting diode (OLED) based displays, and touch panel displays. For example, user device 106 can include a display 830 for displaying graphical user interface elements for interacting with transaction server 1 10.

[00113] Computer system 800 may also include a communications interface 824.

Communications interface 824 allows software and data to be transferred between computer system 800 and external devices. Communications interface 824 may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, or the like. Software and data transferred via communications interface 824 may be in the form of signals, which may be electronic, electromagnetic, optical, or other signals capable of being received by communications interface 824. These signals may be provided to communications interface 824 via a communications path 826. Communications path 826 carries signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, a radio-frequency (RF) link or other communications channels.

[00114] Auxiliary I/O device interface 834 represents general and customized interfaces that allow processor device 804 to send and/or receive data from other devices 836, such as microphones, touch-sensitive displays, transducer card readers, tape readers, voice or handwriting recognizers, biometrics readers, cameras, portable mass storage devices, and other computers. Device interface 834 may perform signal conditioning and processing functions such as analog to digital and digital to analog conversion, amplification and filtering of device generated signals, and generation of hand-shaking signals to coordination the operation of devices 836 with the operations of computer system 800. For example, user device 106 can include a touch screen device for capturing user manipulation of graphical user interface elements displayed on user device 106.

[00115] In this document, the terms "computer program medium" and "computer readable medium" are used to generally refer to storage media such as removable storage unit 818, removable storage unit 822, and a hard disk installed in hard disk drive 812. Computer program medium and computer usable medium may also refer to memories, such as main memory 808 and secondary memory 810, which may be memory semiconductors (e.g. DRAMs, etc.).

[00116] Computer programs (also called computer control logic) are stored in main memory 808 and/or secondary memory 810. Computer programs may also be received via communications interface 824. Such computer programs, when executed, enable computer system 800 to implement embodiments as discussed herein. In particular, the computer programs, when executed, enable processor device 804 to implement the processes of embodiments, such as the stages of the methods illustrated by flowcharts 400 and 500 of FIGS. 4 and 5, and message flow diagrams 2A and 2B in FIGS 3, 4, 2A and 2B, respectively, as discussed above. Accordingly, such computer programs can be used to implement controllers of the computer system 800. Where embodiments are implemented using software, the software may be stored in a computer program product and loaded into computer system 800 using removable storage drive 814, interface 820, and hard disk drive 812, or communications interface 824.

[00117] Embodiments also may be directed to computer program products comprising software stored on any computer readable medium. Such software, when executed in one or more data processing devices, causes a data processing device(s) to operate as described herein. For example, the software can cause data processing devices to carry out methods 400 and 500 shown in FIGS. 4 and 5 and to transmit messages shown in FIGS. 2A and 2B.

[00118] Embodiments employ any computer useable or readable medium. Examples of tangible, computer readable media include, but are not limited to, primary storage devices (e.g., any type of random access memory), secondary storage devices (e.g., hard drives, floppy disks, CD ROMS, ZIP disks, tapes, magnetic storage devices, and optical storage devices, MEMS, nano-technological storage device, etc.). Other computer readable media include communication mediums (e.g., wired and wireless communications networks, local area networks, wide area networks, intranets, etc.).

VII. Variations

[00119] As would be understood by a person skilled in the art based on the teachings herein, several variations of the above described features for carrying out billing transactions can be envisioned. These variations are within the scope of embodiments of the invention. For example, one skilled in the art can envision several variations in implementing the transaction server and the service provider and carrying out transactions as described in methods 300 and 400 of FIGS. 3 and 4, respectively.

[00120] For example, in a variation, billing gateway 112 can be operated as the clearing house for private user information used in transactions between the transaction server and a service provider. The operator of the billing gateway 1 12 can be a trusted entity with the encryption keys necessary to decrypt information in the authorization token, and can be configured to make the determinations of whether a user is authorized to conduct carrier billing with the service provider and of whether purchase parameters for a purchase transaction meet the transaction criteria required by the service provider. In this variation, one or more transaction parameters included with the authorization token are encrypted to be effectively opaque to operators of the transaction server other than the trusted entity.

[00121] In another variation, the determination of whether the transaction criteria are met can be performed by any component of transaction server 1 10. For example, marketplace engine 118 can be configured to determine whether the purchase parameters for a transaction meet the transaction criteria based on the transaction parameters for the user provided by service provider 120.

VIII. Conclusion

[00122] The Summary and Abstract sections may set forth one or more but not all exemplary embodiments of the present invention as contemplated by the inventor(s), and thus, are not intended to limit the present invention and the appended claims in any way.

[00123] Embodiments have been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed.

[00124] The foregoing description of the specific embodiments will so fully reveal the general nature that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present invention. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.

[00125] The breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should.be defined only in accordance with the following claims and their equivalents.

Claims

WHAT IS CLAIMED IS:

1. A computer-implemented method of billing a user, comprising:

receiving a request to purchase an application and transaction parameters from a device of the user, wherein the device of the user is associated with a wireless carrier;

determining whether the purchase request meets transaction criteria, wherein the transaction criteria are determined based on the transaction parameters; and

responsive to the purchase request meeting the transaction criteria, sending a reserve request to a server of the carrier, the reserve request including an authorization token identifying the user and a purchase price associated with the application;

wherein the carrier server is configured to reserve the purchase price from an account associated with the user in response to the reserve request.

2. The computer implemented method of claim 1 , wherein determining whether the purchase request meets transaction criteria includes:

receiving the authorization token from the device of the user;

responsive to receiving the authorization token, the purchase parameters, and the purchase request from the device of the user, sending the purchase price and the authorization token to a server of the carrier; and

receiving a message responsive to the sending of the purchase price and authorization token indicating the results of a determination that the purchase price meets the transaction criteria.

3. The computer implemented method of claim 1, wherein receiving the authorization token is performed by receiving an encrypted authorization token from the device of the user.

4. The computer-implemented method of claim 1, wherein the authorization token is encrypted.

5. The computer-implemented method of claim 1 , further comprising:

receiving a transmission from the user's device;

generating the authorization token based on the received transmission.

6. The computer-implemented method of claim 5, wherein generating comprises: extracting identifying information from the transmission at a radio level of the transmission.

7. The computer-implemented method of claim 1, wherein determining comprises:

determining whether the user has enabled a carrier billing form of payment.

8. The computer-implemented method of claim 1, wherein the transaction parameters include a transaction limit and wherein determining comprises:

determining whether the purchase price is within the transaction limit.

9. The computer-implemented method of claim 1, wherein the transaction parameters include a currency of the account associated with the user and wherein determining comprises: determining whether the currency of the account associated with the user is the same as a currency associated with a seller of the application.

10. The computer-implemented method of claim 1, further comprising:

responsive to the purchase request not meeting the transaction parameters, rejecting the purchase request.

11. The computer-implemented method of claim 1 , further comprising:

installing the application on the user's device.

12. The computer-implemented method of claim 1 , further comprising:

responsive to a cancel request not being received from the user's device in a time period, sending a capture request to the carrier server, wherein the carrier server is configured to capture the purchase price from the account associated with the user in response to the capture request.

13. The computer-implemented method of claim 1, further comprising:

responsive to receiving a cancel request from the user's device in a time period, sending a cancellation to the carrier server, wherein the carrier server is configured to release the purchase price from the account associated with the user in response to the cancellation.

14. The computer-implemented method of claim 1, further comprising:

responsive to determining a discrepancy between a settlement file received from the carrier server and a list of capture requests, re-sending a capture request associated with the purchase request.

15. The computer-implemented method of claim 14, further comprising:

responsive to determining that the re-sent capture request was unsuccessful, uninstalling the application from the user's device.

16. A transaction system, comprising:

a marketplace engine configured to receive a request to purchase an application and transaction parameters from a device of the. user, wherein the user's device is associated with a wireless carrier;

a payment processing engine configured to receive the transaction parameters from the marketplace engine and to determine whether the purchase request meets transaction criteria, wherein the transaction criteria are determined based on the transaction parameters; and

a billing gateway coupled to the payment processing engine and configured to send a reserve request to a server of the carrier, the reserve request including an authorization token identifying the user and a purchase price;

17. The transaction system of claim 16, wherein the transaction parameters include at least one of an indication of whether the user has enabled a carrier billing form of payment, a transaction limit, or a currency of the account associated with the user.

18. The transaction system of claim 16, wherein the marketplace engine is configured to install the application on the user's device.

19. The transaction system of claim 16, wherein the billing gateway is configured to send a capture request to the carrier server in response to a determination that a cancel request has not been received from the user's device in a time period.

20. The transaction system of claim 16, wherein the billing gateway is configured to send a cancellation to the carrier server in response to a reception of a cancel request from the user's device in a time period.

21. The transaction system of claim 16, wherein the billing gateway is configured to re-send a capture request associated with the purchase request in response to a determination of a presence of a discrepancy between a settlement file received from the carrier server and a list of capture requests.

22. The transaction system of claim 21 , wherein the marketplace engine is configured to uninstall the application from the user's device in response to a determination that the re-sent capture request was unsuccessful.

23. A computer-implemented method of billing a user, comprising:

receiving at a server of wireless carrier, a request to authorize billing to an account of the user associated with the wireless carrier

generating an authorization token and transaction parameters based on information in the users account;

receiving a request to authorize a purchase of an application at a marketplace engine that includes the authorization token, and a purchase price for the application; and

responsive to the receiving a request to authorize a purchase at the marketplace engine, reserving the purchase price in an account of the user on a server of the wireless carrier.

24. The computer-implemented method of claim 23, wherein the receiving at server of a wireless carrier a request to authorize billing includes:

receiving a wireless communication from the mobile device of the user;

exacting an identifier for the mobile device from a radio interface layer of the wireless communication;

querying a database for billing information for the user using the extracted identifier; and generating the authorization token and transaction parameters based on the billing information.

25. The computer-implemented method of claim 23, wherein generating the authorization token and the transaction parameters further includes encrypting the authorization token using a public encryption key controlled by an operator of the wireless carrier.