DIRECT CARRIER BILLING
BACKGROUND
Field
[0001] Embodiments relate generally to systems for billing users for purchases.
Background
[0002] 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.
[0003] 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
[0004] 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.
[0005] 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.
[0006] 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.
[0007] 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
[0008] 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.
[0009] 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] FIGS. 3 A and 3B are flow charts 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 flow chart illustrating another example method in accordance with an embodiment;
[0017] FIG. 9 is a block diagram schematically illustrating an example computer system in which embodiments can be implemented.
[0018] 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
I. Introduction
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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
[0023] 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 110, and a network 102.
[0024] 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.
[0025] 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.
[0026] Subscriber account database 126 stores account information for billing users for services provided by service provider 120. Subscriber account database 126 responds to queries from components of service provider 120, such as billing server 124.
[0027] 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.
[0028] Transaction server 1 10 can include a marketplace engine 1 18 and a billing processor 115. Billing processor 115 includes a payment processing engine 114, a purchaser account database 116, and a billing gateway 112.
[0029] Marketplace engine 118 provides a purchasing point for obtaining services used with user device 106. For example, marketplace engine 1 18 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 118, for simplicity, an example embodiment will be described in which the offered services are applications compatible with user device 106.
[0030] The services offered to users from marketplace engine 118 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 114, purchaser account database 116, and billing gateway 112.
[0031] 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 114 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.
[0032] Purchaser account database 116 stores transaction information regarding purchases made by the user from marketplace engine 118. For example, payment processing engine 114 can access purchaser account database 116 to record information regarding specific transactions and actions taken by marketplace engine 118 and payment processing engine 114 in support of those transactions.
[0033] 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.
[0034] 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
[0035] 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, components of transaction server 110 are configured to generate and receive messages using remote procedure calls (RPC), while transaction server 1 10 and service provider 120 are configured to send and receive Single Object Access Protocol (SOAP) messages over an HTTPS connection. FIGS. 2A and 2B will be described further with respect to FIGS. 3A and 3B.
[0036] FIGS. 3 A and 3B are flowcharts 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 deyice 106 of FIGS. 1 and 2, but embodiments of the method are not limited thereto.
[0037] Method 300 begins in block 302 with generating and transmitting a provisioning request result indicating that the user is authorized to bill a service provider for purchases made at an online market. In an embodiment, user device 106 is configured to transmit provisioning request 250 to service provider 120. Provisioning request 250 can be sent in response to a number of different triggers, e.g., powering up user device 106 or replacing the subscriber identity module (SIM) card in user device 106. User device 106 may be configured to transmit provisioning request 250 at periodic time intervals.
[0038] 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 determine whether the user is authorized to use carrier billing with service provider 120 for purchases made at marketplace engine 118. In an embodiment, service provider 120 can be configured to indicate that the user is not authorized to use carrier billing for various reasons, including for example, the user's credit status with the service provider, or a current low available account balance for the user. [0039] 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.
[0040] In another embodiment, the identifier obtained from provisioning request 250 can be a Media Access Control (MAC) address associated with user device 106.
[0041] 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 can be configured to extract 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.
[0042] 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, MAC address, or other identifier associated with user device 106 or the user. Fields 508, 510, 512, 514, and 516 contain-billing information for the respective subscriber ID. For example, field 510 indicates that subscriber 012321321321 is not authorized to bill services to service provider 120, while field 510 indicates that subscriber 037653486211 is authorized to perform carrier billing.
[0043] 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, IMSI or IMEI numbers, MAC address, or other identifier associated with the user or user device 106, 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 provisioning request result 252 to user device 106. [0044] In block 304 of method 300 an authorization token is generated and transmitted in response to a request from a user. In an embodiment, the user can use user device 106 to transmit credential request 253 to service provider 120. User device 106 can be configured to generate transmit credential request 253 in response to selecting carrier billing as the FOP for a purchasing transaction with marketplace engine 118.
[0045] In an embodiment, user device 106 can be configured to present provisioning
. request result 252 to the marketplace engine 118 during a purchasing transaction initiated from user device 106. Marketplace engine 118 can be configured to present the option for carrier billing as an FOP in response to receiving the provisioning request result 252. In another embodiment, payment processing engine 114 can be responsible for presenting the option for carrier billing as an FOP after the user has elected to purchase an application.
[0046] Service provider 120 can be configured to extract information identifying the user from credential request 253. In an embodiment, billing server 124 can be configured to obtain an identifier from credential request 253 using methods similar to those methods described for obtaining an identifier from provisioning request 250.
[0047] In an embodiment, billing server 124 can be configured to query subscriber account database 126 with the identifier extracted from credential request 253 to retrieve billing information, including transaction parameters for the user, from subscriber account database 126. Billing server 124 can be configured to generate an authorization token that includes identifying information for the user.
[0048] .In an embodiment, the transaction parameters based on the subscriber information for the user can include one or more of information indicating that the user is allowed to conduct carrier billing with service provider 120, information identifying the user's transaction limit and available balance 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 available billing balance for the user is 100 United States Dollars (USD) and that transaction limit for the user's billing transactions with service provider 120 is 50 USD, and that the currency or currencies to be used for carrier billing transactions are, for example, USD only or USD and Euros, respectively.
[0049] In an embodiment, some or all of the information in the authorization token can be encrypted using one or more encryption keys. For example, personal information identifying the user can be encrypted using a public encryption key controlled by service provider 120. Encryption can be used to control access to private information of users, as the encrypted information can be effectively opaque (i.e. resistant to attempts to read the information) to entities that do not have access to the corresponding private encryption key. In other embodiments, any encryption type can be used that renders the authorization token effectively opaque to entities that do not have the information used to decrypt the information. For example, the encryption can be based on a symmetric encryption algorithm.
[0050] In an embodiment, user device 106 can be configured to verify the identity of service provider 120 during the credential request using certifications transmitted using HTTPS. As described above, service provider 120 verifies user device 106 using its IMEI or IMSI or using other communication protocol-dependent unique identifiers. Billing processor 115 and service provider 120 can be mutually authenticated using secure sockets layer (SSL) certifications. One of skill in the relevant arts will appreciate that other protocols and techniques can be used to verify the identities of service provider 120 and billing processor 115.
[0051] As shown in FIG. 2A, upon successful generation of the authorization token, service provider 120 is configured to transmit a credential response message 254 including the authorization token and the transaction parameters to user device 106.
[0052] In block 306, a purchase request with an authorization token is received from a user device. In an embodiment, a component of transaction server 1 10, for example, marketplace engine 118, receives a purchase request message 202 from user device 106. Purchase request message 202 can include the authorization token received from service provider 120, and purchase selection information identifying an application that user wants to purchase from marketplace engine 118. In an embodiment, the user can select the FOP at another point during the transaction (e.g., during interactions with payment proces sing engine 114) . [0053] 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 118 can host applications that present an online forum for purchasing Android compatible applications.
[0054] 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 118. In an embodiment, marketplace engine 118 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.
[0055] 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.
[0056] At decision block 308 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 308 is executed.
[0057] Referring now to FIG. 2B, payment processing engine 114 of billing processor
115 can be configured to receive purchase request message 204. In an embodiment, payment processing engine 114 is configured to determine whether purchase request message 204 meets transaction criteria based on the transaction parameters.
[0058] 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.
[0059] 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. [0060] 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.
[00611m m embodiment, the authorization token can include 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.
[0062] 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 308 to rejecting the purchase request in block 324. 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. In an embodiment, marketplace engine 118 and/or payment processing engine 114 can be configured to accept forms of payment for purchasing the selected application other than carrier billing (e.g., in response to a determination that the transaction criteria were not met).
[0063] Upon a determination that the transaction criteria have been met, method 300 continues along the 'Yes' branch from decision block 308 to block 310 with sending the authorization token and the purchase price to service provider 120.
[0064] In an embodiment, billing gateway 112 can be configured to transmit request message 208 to service provider 120. Billing gateway 112 can be configured to include the authorization token, the purchase price, and an identifier for the transaction in authorization request message 208.
[0065] Payment processing engine 114 of billing processor 115 can record information regarding the purchase transaction and the sending of authorization requests in purchaser account database 1 16. [0066] FIG. 7 shows an example data table 700 for recording purchaser transactions in purchaser account database 116 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.
[0067] In an embodiment, billing gateway 112 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 114. 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.
[0068] Method 300 continues in decision block 312 with determining whether the request to reserve the purchase price will be granted. In an embodiment, billing server 124 of service provider 120 can be configured to determine whether the reservation request meets service provider criteria for granting the request. For example, billing server 124 can be configured to deny a reservation request if the authorization token has expired, is missing from authorization request message 208, or cannot be properly decrypted. In an embodiment, billing server 124 can be configured to deny a reservation of the billing price if the carrier available billing balance for the user is too low to support the purchase transaction. One of skill in the relevant arts will appreciate that billing server 124 can be configured to use various criteria to determine whether to grant the reservation request.
[0069] Upon a determination that the reservation request meets service provider criteria for granting the reservation request, method 300 continues along the 'Yes' branch from decision block 312 to block 314 with reserving the purchase price in the user's subscriber billing account with the service provider. 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 upon receiving reservation request message 208 from billing gateway 112.
[0070] 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 602a, 602b, and 602c containing information relating to transactions for a user with subscriber ID 037653486211. Field 604 of records specifies a purchase transaction ID for a given transaction. Field 606 indicates the reservation amount of 1.99 USD for the transaction in record 602a, which corresponds to the purchase price for the application. 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.
[0071] In an embodiment, billing server 124 reserves the purchase price for a new transaction 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 carrier available billing balance for the subscriber in field 512.
[0072] 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 115. 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 conducted by service provider 120. 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 1 14.
[0073] Upon a determination that the reservation request meets service provider criteria for granting the reservation request, method 300 continues along the "No" branch from decision block 312 to block 324 with rejecting the reservation request for the purchase transaction.
[0074] In an embodiment, billing server 124 of 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 does not meet service provider criteria for granting the request.
[0075] In an embodiment, one or more components of billing processor 115 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 114 in response to receiving reservation denied message 218 from service provider 120.
[0076] In an embodiment, payment processing engine 114 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 118 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. Payment processing engine 1 14 can be configured to update database 116 to reflect the denial of the request for carrier billing with service provider 120.
[0077] 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.
[0078] Method 300 continues in block 316 with sending the purchased application to the user's device.
[0079] 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. [0080] For example, in an embodiment, marketplace engine 118 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 118 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 118 can provide information identifying the purchase transaction to user device 106.
[0081] Method 300 then continues in decision block 318 with a determination of whether a cancel request has been received during a time period.
[0082] 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.
[0083] In an embodiment, payment processing engine 114 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. In an embodiment, marketplace engine 118 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 118 in response to a user uninstalling the application from the user device. Marketplace engine 118 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 118 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.
In an embodiment, marketplace engine 118 can be configured to generate cancellation order message 230 in response to a user uninstalling an application after the trial period has expired. For example, marketplace 118 may configured to receive an indication from the owner of the application purchased by the user that a late refund is authorized for the user and to generate cancellation order message 230 in response to receiving indication that the user has uninstalled the application from user device 106 at a time after expiration of the time period. In response to the cancellation order message 230, billing processor 115 transmits reserve cancellation request 234 to service provider 120.
Method 300 continues to block 326 to send a reserve cancellation request to a service provider in response to a cancellation request being received during the trial , period. [0087] In an embodiment, payment processing engine 114 can be configured to receive cancellation order message 230 and can be configured send cancellation order message 232 to billing gateway 112 in response to receiving cancellation order message 230.
[0088] Billing gateway 112 can be configured to send a reserve cancellation request message 234 to service provider 120 in response to receiving cancellation order message 232.
[0089] Method 300 then continues in block 328 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 126. In a further embodiment, payment processing engine 114 can be configured to update table 700 to indicate that the purchase transaction has been canceled.
[0090] For example, service provider 120 can be configured to respond to reserve 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/or decreasing a total reserve amount for the user by the purchase price for the transaction, and by incrementing the carrier available billing balance for the respective user in field 512 of table 500 by the purchase price for the application.
[0091] Method 300 continues along the 'No' branch from decision block 318 to block 320 with the sending of a request to capture the purchase price from the user's service provider account in response to a determination that no cancellation request has been made during the trial period to cancel the purchase.
[0092] 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 118 has not received cancel request message 228 during the time period. Payment processing engine 1 14 can be configured to update database 116 to reflect the sending of the capture request message to service provider 120
[0093] Method 300 then continues in block 324 with capturing of the purchase price from the user's account. [0094] Capture is the process by which the service provider 120 bills the client for the purchase price of the services. In an embodiment, billing server 124 can be configured to capture the purchase price from the user's subscriber account in response to receiving capture request message 226.
[0095] In an embodiment, during capture, billing server 124 releases the reservation of the purchase price in subscriber account database 126, but the carrier available billing balance 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 by clearing the reserve amount for the transaction from field 606 of table 600, and/or decreasing a total reserved amount for all of the user's transactions by the reserve amount. In an embodiment, the carrier available billing balance in field 512 of table 500 (shown in FIG. 5) is not changed as a result of capturing the reserve amount.
[0096] In an embodiment, service provider 120 can provide a cancellation window in which users may cancel purchase transactions by contacting service provider 120. For example, a cancellation window implemented by billing server 124 of 30 or 48 hours after reservation of the purchase price covers a period longer than, and compatible with, a trial period implemented on transaction server 110 of 24 hours after a reservation request.
[0097] In another embodiment, service provider 120 may be configured to determine whether a request to capture the reserve amount for a transaction should be granted. Service provider 120 may be configured to deny a request to capture a reserve amount for various reasons. For example, service provider 120 may deny a request to capture a reserve amount if the reserve amount has been previously released, if the capture request does not correspond to a reserve transaction, or if a time period for capturing a reserve amount has expired.
[0098] FIG. 4 is a flow chart that shows an example method 400 for billing the user according to an embodiment. For ease of explanation, method 400 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.
[0099] Method 400 beings in block 402 with reviewing the status of capture requests. In an embodiment, payment engine 114 can be configured to update purchaser account database 116 to reflect the status of carrier billing transactions. For example, payment engine 114 can be configured to update table 700 in purchaser account database 116 with details of one or more action, such as the making of reservation request, send of cancellation orders, acknowledgments of cancellation orders by service provider 120, and the generation of capture requests, and the acknowledgement of capture requests by service provider 120. Referring again to example table 700 in FIG. 7, field 712, indicates the time of the last capture request for transaction 00001236, and field 714 indicates that an acknowledgement of a capture request has not been received at transaction server 110 for transaction 00001236. In an embodiment of the invention, the payment engine can be configured to identify outstanding capture request based on the status information stored in table 700.
[00100] Method 400 continues in decision block 404 with determining whether capture requests generated during transactions have been acknowledged by the service provider.
[00101] In response to identifying an unacknowledged 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 114 can be configured retry the sending of capture request message 226 to service provider 120.
[00102] Method 400 continues in decision block 408 with a determination of whether one or more retries of sending capture request 226 were acknowledged 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 1 14 can be configured to determine information stored in purchaser account database 116^ whether all retries of capture request 226 were unsuccessful for the duration of the window period.
[00103] Upon a determination that the retries were unsuccessful, method 400 continues along the 'No' branch from decision block 408 to block 410 with releasing the purchase price from the user's account. In an embodiment, payment processing engine 114 can update purchaser account database 116 to indicate that the reservation of the purchase price for the selected application has been canceled. In a further embodiment, billing' server 124 of service provider 120 can be configured to update subscriber account database 126 to reflect the cancellation of the reservation request.
[00104] In an embodiment, method 400 can continue in block 412, with uninstalling the application from the user's device, respectively. Marketplace engine 118 can be configured to initiate uninstalling or deactivating of the purchased application on user device 106. For example, payment processing engine 114 can configured to send carrier billing denied message 222 to marketplace engine 118. As discussed above, marketplace engine 118 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.
[00105] In another embodiment, block 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).
[00106] In response to a determination that a retry of a capture request has been successful, method 400 ends by proceeding along the 'Yes' branch from block 408 to termination block 416. In an embodiment, payment processing engine 114 updates purchaser account database 116 to reflect that the capture request was successful.
[00107] 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 1 18 and payment processing engine 114 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.
[00108] 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 112. 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.
[00109] FIG. 8 is a flow chart that shows an example method 800 according to an embodiment. For ease of explanation, method 800 is described with respect to transaction system 100, service provider 120 ,and user device 106 of FIGS. 1 and 2, but embodiments of the method are not limited thereto.
[00110] Method 800 begins in block 802 with generating a settlement file. In an embodiment billing server 124 can be configured to generate a settlement file that includes a list of transactions acted on by service provider 120 for billing users for purchases made at marketplace engine 118. For example, billing server 124 can identify transactions by retrieving transaction information from database 126 related to carrier billing transactions involving marketplace engine 1 18. The identified transactions can include one or more of charges, refunds, and charge backs processed by billing server 124.
[00111] In an embodiment, billing server 124 can be configured to generate the settlement file periodically. For example, billing server 124 can be configured to generate a daily settlement file that describes transactions generated during the previous day. In another embodiment, billing server 124 can be configured to generate a monthly settlement file that describes transactions generated during the past month. For example, billing server 124 can be configured to generate a monthly settlement file that describes the charge and refund transactions for the previous month.
[00112] In another embodiment, billing server 124 can be configured to generate a settlement file containing only a particular type of transaction. For example, billing * server 124, can be configured to generate a chargeback settlement file that includes describes the charge backs transactions for a day or other period. Billing server 124 can generate a reconciliation settlement file whenever service provider 120 deposits money into an account for the marketplace engine 118 received from users. [00113] One of skill in the relevant arts will appreciate that the generation of settlement files can be triggered by various techniques, and that the settlement files may include details of transactions as appropriate for the purpose.
[00114] In a further embodiment, billing server 124 can be configured to generate the settlement file in any format. For example, billing server 124 may generate the settlement file in an extendable markup language (XML) format using XML tags negotiated agreed on by an operator of service provider 120 and an operator of a component of transaction server 1 10. In an embodiment of the invention, billing server 124 may be configured to compressed the settlement file using a compression algorithm (e.g., gzip compression.)
[00115] In an embodiment, billing server 124 can be configured to limit the size of settlement files by generating multiple settlement files to contain the transaction information. For example, billing server 124 can be configured to generate multiple settlement files so that no more than a predetermined number of transactions is contained in a single settlement file.
[00116] In a further embodiment, billing server 124 can be configured to encrypt and/or sign a generated settlement file. For example, billing server 124 may be configured to encrypt the settlement file using a public key belonging to an operator of a component of transaction server 1 10, (e.g. an operator of payment engine 114 or marketplace engine 118) and to sign the settlement file using a private key of an operator of service provider 120.
[00117] Method 800 continues in block 804 with transmitting the settlement file. In an embodiment, billing server 124 can be configured to transmit the settlement file to the billing processor 115 of transaction server 110.
[00118] Method 800 continues in block 806 with identifying discrepancies in the settlement file. In an embodiment of the invention, payment processing engine 1 14 can be configured to retrieve the transaction information from the settlement file and to compare the information in the settlement file to information stored in purchaser account database 1 16 related to transactions with service provider 120.
[00119] In an exemplary embodiment, payment processing engine 114 can be configured to decrypt and/or decompress the settlement file to access the transaction information included in the settlement file using algorithms and information corresponding to the algorithms and information used to encrypt and/or compress the settlement file. Payment processing engine 114 can be configured identify discrepancies in the settlement file by retrieving, transaction information for transactions with service provider 120 for a time period corresponding to the time period for the transactions contained in the settlement file. For example, payment processing engine 114 can be configured identify as a discrepancy a transaction for which a capture request is recorded in purchaser account database 116, but for which there is no corresponding charge in the settlement file. As a further example, payment processing engine 114 may be configured to recognize as any cancel requests recorded in purchaser account database 116- for which there is no corresponding refund in the settlement file as discrepancies.
[00120] In a response to a determination that there are no discrepancies with the settlement file, method 800 continues along the 'No' branch from decision block 806 to end in block 810.
[00121] In a response to a determination that there are discrepancies, method 800 continues along the 'Yes' branch from decision block 806 to block 808 where identified discrepancies are revolved.
[00122] Various methods may be used to resolve identified discrepancies with the settlement file. In an embodiment, billing processor 115 may be configured to retry capture requests that are within a capture window period of service provider 120 by re- sendihg capture request message 226 to service provider 120. In another embodiment, discrepancies may be resolved manually.
VI. Example Computer System Implementation
[00123] Embodiments shown in FIGS. 1-8, 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.
[00124] FIG. 9 illustrates an example computer system 900 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 110, and user device 106 in FIG. 1 can be implemented in computer system 900 using hardware, software, 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. Hardware, software, or any combination of such may embody any of the modules and components in FIG. 1.
[00125] If programmable logic is used, such logic may execute on a commercially available processing platform or a special purpose device. One of skill in the relevant arts will 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.
[00126] 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."
[00127] Various embodiments are described in terms of this example computer system 900. 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.
[00128] Processor device 904 may be a special purpose or a general purpose processor device. As will be appreciated by persons skilled in the relevant art, processor device 904 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 904 is connected to a communication infrastructure 906, for example, a bus, message queue, network, or multi-core message-passing scheme. [00129] Computer system 900 also includes a main memory 908, for example, random access memory (RAM), and may also include a secondary memory 910. Secondary memory 910 may include, for example, a hard disk drive 912, removable storage drive 914. Removable storage drive 914 may comprise a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, or the like. The removable storage drive 914 reads from and/or writes to a removable storage unit 918 in a well known manner. Removable storage unit 918 may comprise a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 914. As will be appreciated by persons skilled in the relevant art, removable storage unit 918 includes a computer usable storage medium having stored therein computer software and/or data.
[00130] In alternative implementations, secondary memory 910 may include other similar means for allowing Computer programs or other instructions to be loaded into computer system 900. Such means may include, for example, a removable storage unit 922 and an interface 920. 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 922 and interfaces 920 which allow software and data to be transferred from the removable storage unit 922 to computer system 900.
[00131] Computer system 900 can include a display interface 932 for interfacing a display unit 930 to computer system 900. Display unit 930 can be any device capable of displaying user interfaces according to this invention, and compatible with display interface 932. 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 930 for displaying graphical user interface elements for interacting with transaction server 110.
[00132] Computer system 900 may also include a communications interface 924.
Communications interface 924 allows software and data to be transferred between computer system 900 and external devices. Communications interface 924 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 924 may be in the form of signals, which may be electronic, electromagnetic, optical, or other signals capable of being received by communications interface 924. These signals may be provided to communications interface 924 via a communications path 926. Communications path 926 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.
[00133] Auxiliary I/O device interface 934 represents general and customized interfaces that allow processor device 904 to send and/or receive data from other devices 936, 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 934 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 936 with the operations of computer system 900. 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.
[00134] 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 918, removable storage unit 922, and a hard disk installed in hard disk drive 912. Computer program medium and computer usable medium may also refer to memories, such as main memory 908 and secondary memory 910, which may be memory semiconductors (e.g. DRAMs, etc.).
[00135] Computer programs (also called computer control logic) are stored in main memory 908 and/or secondary memory 910. Computer programs may also be received via communications interface 924. Such computer programs, when executed, enable computer system 900 to implement embodiments as discussed herein. In -particular, the computer programs, when executed, enable processor device 904 to implement the processes of embodiments, such as the stages of the methods illustrated by flowcharts 300, 400 and 800 of FIGS. 3 A and B, 4 and 8, and message flow diagrams 2A and 2B, respectively, as discussed above. Accordingly, such computer programs can be used to implement controllers of the computer system 900. Where embodiments are implemented using software, the software may be stored in a computer program product and loaded into computer system 900 using removable storage drive 914, interface 920, and hard disk drive 912, or communications interface 924.
[00136] 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 300, 400 and 800 shown in FIGS. 3A and 3B, 4, and 8, respectively and to transmit messages shown in FIGS. 2 A and 2B.
[00137] 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
[00138] As would be understood by a person skilled in the relevant arts, 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 relevant arts 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.
[00139] 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 112 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