The advent of mobile communication networks has opened many new mechanisms for cashless payments for products and services using personal wireless devices. Products purchased with mobile payments have become diverse, ranging from mobile contents to vending machine items. Equally diverse are the mobile payment methods owing to the relatively new payment system that can be implemented in many different ways. One common step in these methods of mobile payment is the authentication and authorization in which all users who wishes to make a payment via a mobile device must be authenticated such that the merchant will receive the authorization to proceed with the sale.
In the context of this specification, the term “subscriber” means the owner of the line or the payer of the bills. The term “user” means the user of a mobile phone, who may or may not be the owner of the line who pays the bills, who is making a purchase.
In existing Mobile Payment Systems, the user makes a purchase at the point-of-sale (POS) terminal or website, and the POS sends a message including such information as the mobile phone number of the user to the mobile payment system for authentication. The payment system then verifies the mobile account subscriber and proceeds to authorize the purchase. A deficiency of this method is that all users with mobile phones are treated as independent account subscribers, and such mechanisms allow account users (other mobile phone users under the main subscriber account) equal access to purchasing as the account subscriber. For this reason, contemporary Mobile Payment Systems do not provide any ability to control the purchase of products and services for different levels or types of users, such as children whose parents may want to control their mobile purchase. Prepaid types of billing have provided limited opportunities for customizing the product type or service and limiting the billing period amount.
Therefore, what is needed is a mechanism that overcomes the described problems and limitations.
Aspects of the present disclosure are best understood from the following detailed description when read with the accompanying figures, in which:
It is to be understood that the following disclosure provides many different embodiments, or examples, for implementing different features of various embodiments. Specific examples of components and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to be limiting. In addition, the present disclosure may repeat reference numerals and/or letters in the various examples. This repetition is for the purpose of simplicity and clarity and does not in itself dictate a relationship between the various embodiments and/or configurations discussed.
POS 110 is communicatively coupled with a Mobile Payment System 140, e.g., via a network such as the Internet 130. Mobile Payment System 140 may be implemented as a data processing system, such as a server, and is adapted to process mobile-originated purchases. To this end, Mobile Payment System 140 may include or interface with a user database 150 that maintains records of users that are registered to make purchases via the mobile payment system. User records of database 150 may specify various account attributes, such as a user names, phone numbers, authorization levels, purchase limits, and the like.
Mobile Payment System 140 is communicatively interfaced with a short message service (SMS) provider, such as a wireless carrier network 170. In the illustrative example, Mobile Payment System 140 is interfaced with carrier network 170 via an SMS gateway 160. SMS gateway 160 may be hosted by carrier network 170, or alternatively by an independent or third party SMS provider. SMS gateway 160 may be communicatively interfaced with an SMS Center (SMSC) 172 which may operate as a store-and-forward platform. SMSC 172 may interface with a mobile switching system, e.g., a mobile services switching center (MSC) 174. The mobile switching system may include or interface with a Home Location Register (HLR) 176, and a Visitor Location Register (VLR) 178. MSCs carry out switching functions and manage the communications between mobile phones and the Public Switched Telephone Network (PSTN). HLR 176 comprises the central database that contains details of each mobile phone user that is authorized to use the cellular core network. VLR 178 comprises a database which stores information about all the mobiles terminals that are currently serviced by the associated MSC. VLR 178 stores various information regarding the mobile terminals, such as the current location area identity that specifies a particular base station controller (BSC) that currently services the mobile phone. MSC 174 interfaces with a radio access network comprising a base station subsystem (BSS). In the illustrative example, the radio access network comprises a BSC 180 and various base transceiver stations (BTSs) 182a-182c operated under the control of BSC 180. BSC 180 manages and directs allocation of radio channels, receives measurements from the mobile phones, and controls handovers between BTSs among other functions. BTSs 182a-182c comprise one or more respective antenna and equipment for transmitting and receiving radio signals, and functions for encrypting and decrypting communications with BSC 180. BTSs 182a-182c provide for communications with mobile terminal 120 over an air-interface.
In accordance with embodiments disclosed herein, a user operating mobile terminal 120 may submit a product for purchase at POS 110. A product ID is obtained by POS 110, e.g., via product scanner 116. A product price may additionally be obtained by POS, e.g., via a product database 118 included or interfaced with POS 110. Product database 118 maintains product “descriptions” which may include product classification (e.g., “adult”, “child” or other product classifications), product ratings, price, or other descriptive information. The product descriptions may be associated with respective product identifiers (PIDs) additionally stored in product database 118. Product identifiers may comprise UPCs obtained from barcodes or other product identifiers. The user may then enter the user's phone number and personal identification number (PIN) at POS 110, e.g., via keypad 112. An authentication and authorization process is then performed to authenticate the user and authorize the transaction. In an embodiment, POS 110 generates an encrypted message that is transmitted to Mobile Payment System 140 for user authentication and purchase authorization. The encrypted message includes the user's mobile phone number and PIN, as well as the product ID, e.g., UPC code of the product to be purchased. Additionally, the encrypted message includes product description data including but not limited to product classification. The encrypted message may include a merchant ID that comprises an identifier uniquely assigned to the merchant hosting POS 110. On receipt of the encrypted message, Mobile Payment System 140 may authenticate the user, e.g., via the user's phone number and PIN. If the user is successfully authenticated, the purchase request may be evaluated to determine if the user is authorized to purchase the product. For example, a classification of the product may be used to determine if the user authorization level is sufficient for purchasing the product. Furthermore, the user's purchase limit may be evaluated to determine if the user has a sufficient purchase limit for the product. If the user is authenticated and authorized successfully, a one-time-password (OTP) is generated by Mobile Payment System 140. The OTP may then be encrypted and transmitted to POS 110. An encryption key may also be transmitted to POS 110 for decrypting the OTP. On receipt of the encrypted message and the key, POS 110 may decrypt the message to obtain the OTP.
Additionally, an SMS request may be transmitted from Mobile Payment System 140 to an SMS provider. The SMS request may include the user's mobile phone number and the OTP. The SMS provider, in turn, generates an SMS message that is addressed to the user's mobile phone number and that includes the OTP. An SMS message including the OTP is then transmitted from the SMS service provider to the user's mobile phone. On receipt of the SMS message, the user may read the OTP and provide the OTP as input to POS 110, e.g., at keypad 112. POS 110 may then compare the OTP provided by Mobile Payment System 140 with the OTP provided by the user. If the OTPs match, the purchase may be completed, and a receipt for the product may be issued. If the OTPs do not match, the purchase may be denied by POS 110.
In accordance with a particular embodiment, multiple users may be associated with a common account. Each user may have a distinct identifier, such as a personal identification number, that is used to authenticate a particular user of the account. The personal identification number may be used in conjunction with a mobile phone number associated with the particular account user. Each of the plurality of users of a common account may have different authorization levels assigned thereto. For instance, an adult that is responsible for the account subscription may have an adult authorization designation, while children or other users of the account may have different authorization levels. Assignment of different authorization levels to users of a common account facilitates purchase restrictions, e.g., age-based product restrictions, as well as account spending limits that may be different for different account users.
Mobile Payment System 140 may be a symmetric multiprocessor (SMP) system that includes a plurality of processors 202 and 204 connected to a system bus 206 although other single-processor or multi-processor configurations may be suitably substituted therefor. A memory controller/cache 208 that provides an interface to local memory 210 may also be connected with system bus 206. An I/O bus bridge 212 may connect with system bus 206 and provide an interface to an I/O bus 214. Memory controller/cache 208 and I/O bus bridge 212 may be integrated into a common component.
A bus bridge 216, such as a Peripheral Component Interconnect (PCI) bus bridge, may connect with I/O bus 214 and provide an interface to a local bus 222, such as a PCI local bus. Communication links to other network nodes of system 100 in
Those of ordinary skill in the art will appreciate that the hardware depicted in
A user may register with Mobile Payment System 140 and have account characteristics assigned thereto. In an embodiment, the user's name, mobile phone number and a personal identification number (PIN) are stored in a record of user database 150. The user may additionally specify an authorization level and purchase limit that is assigned to the user. Alternatively, a Mobile Payment System administrator may assign an authorization level for a user, e.g., based on the user's age. Other users may be assigned to the account and may have different authorization levels and purchase limits assigned thereto.
User database 150 comprises a plurality of records 310a-310c (collectively referred to as records 310) and fields 320a-320e (collectively referred to as fields 320). Database 150 may be stored on a disk drive, fetched therefrom by a processor of Mobile Payment System 140, and processed thereby.
In the present example, fields 320a-320e have labels of “Name”, “Phone_No”, “PIN”, “Authorization”, and “Limit”. Name field 320a stores user names that are registered for mobile product purchases via Mobile Payment System 140. In the present example, each of records 310a-310c is allocated for a user named “John Doe”. Phone_No field 320b stores a mobile phone number assigned to the user of a corresponding record. Thus, in the illustrative example, the user “John Doe” has three mobile phones that are registered to make mobile phone facilitated product purchases. PIN field 320c stores user PINs associated with a mobile phone of a respective record. In the illustrative example, PINs of “8426”, “2312”, and “4534” are assigned to mobile phones with numbers specified in field 320b of a corresponding record. Accordingly, different users sharing a common account may be authenticated with a respective mobile phone number and PIN pair specified by fields 320b and 320c. Authorization field 320d stores an authorization level that is assigned to the user's mobile phone of a corresponding record. In the illustrative example, an authorization level may be assigned “Adult”, “Junior”, or “Child”. In the present example, the mobile phone having a phone number of 214-555-3423 is allocated an authorization level of “Adult”, the mobile phone having a phone number of 214-555-3424 is allocated an authorization level of “Junior”, and the mobile phone having a phone number of 214-555-3425 is allocated an authorization level of “Child”. The authorization level facilitates purchase of products that may be age-restricted products. For example, alcohol or tobacco products may be registered as adult-only products and may not be legally acquired by non-adults, e.g., persons of age 21 years or older. In accordance with an embodiment, when an attempt is made to purchase a product, a classification level of the product may be compared with the user's authorization level to determine if the purchase should be granted or denied. Limit field 320e may specify a monetary limit of product purchases that may be made with an associated phone. For example, the phone having the phone number 2145553423 has a limit of “None” indicating that no purchase limit is assigned to the phone. The phone having the phone number 2145553424 has a limit of “20” dollars, and the phone having the phone number 2145553425 has a limit of “10” dollars. The purchase limit specified by Limit field 320e may comprise a monthly purchase limit, a daily purchase limit, or another suitable interval-based purchase limit. When a purchase is successfully made, the limit specified for the mobile phone from which the purchase was made may be deducted by the purchase amount.
Product database 118 comprises a plurality of records 330a-330c (collectively referred to as records 330) and fields 340a-340c (collectively referred to as fields 340). Database 118 may be stored on a memory or other storage device, fetched therefrom by a processor of POS terminal 110, and processed thereby.
In the present example, fields 340a-340c have labels of “PID”, “Price”, and “Classification”. PID field 340a stores product identifiers assigned to merchant products. In the present example, PIDs of records 330a-330c are illustratively designated PIDA-PIDC. Price field 340b stores a product price assigned to a product specified in PID field 340a of a corresponding record. Thus, in the illustrative example, the products having PIDs of “PIDA”-“PIDC” have respective prices of “19.95”, “30.00”, and “8.95”. Classification field 340c stores product classifications associated with products specified in PID field 340a of a corresponding record. In the illustrative example, products having product IDs of “PIDA”, “PIDB”, and “PIDC” are assigned respective product classifications of “Junior”, “Adult”, and “Child”. Product classifications specified by field 340c associated with product IDs specified in field 340a facilitate evaluation of a user's authorization for purchasing a product in accordance with disclosed embodiments.
The routine is invoked (step 502), and a product ID to be purchased along with product description data (PDD) is received (step 504). The product ID may comprise, for example, a universal product code (UPC). The PDD may include the product classification as well as the product price. The PDD may be obtained by interrogating product database 118 with the PID obtained from the product scanner. The point-of-sale terminal then receives the user mobile phone number (step 506) and personal identification number (PIN) (step 508) as supplied by the user. The point-of-sale terminal then generates an encrypted message containing the phone number, PIN, merchant ID (MID), product ID, and PDD (step 510). The PDD included in the encrypted message may include the product price as well as the product classification. Merchant IDs may, for example, comprise unique identifier each respectively assigned to a merchant that participates in the disclosed mobile payment system. The encrypted message is then transmitted to the Mobile Payment System (step 512). The merchant POS then awaits for a reply from the Mobile Payment System. If the purchase is denied, a denial response will be received at the merchant POS, and an indication of the denial may be displayed to the user. Assuming the purchase is not denied, the merchant POS receives an encryption key from the Mobile Payment System (step 514) as well as an OTP in an encrypted form (step 516). The encrypted OTP may then be decrypted (step 518). An OTP is received by the user via SMS or another messaging service, and the OTP is supplied to the merchant POS by the user. On receipt of the OTP by the merchant POS from the user (step 520), the merchant POS compares the user-supplied OTP with the OTP received from the Mobile Payment System (step 522). An evaluation may then be made to determine if the user-supplied OTP matches the OTP supplied by the Mobile Payment System (step 524). If the OTPs do not match, the purchase request is denied, and a purchase denial message may be displayed by the POS (step 526). The POS processing routine cycle may then end (step 530). If the OTPs are determined to match at step 524, the product purchase transaction may be successfully completed, and a receipt may be issued by the merchant POS (step 528). The POS processing routine cycle may then end according to step 530.
The routine is invoked (step 602), and the Mobile Payment System receives an encrypted message including the user's mobile phone number, PIN, MID, the PID, and the PDD (step 604). The message may be decoded (step 606), and an attempt to authenticate the user based, at least in part, on the user's mobile phone number and PIN is made (step 608). An evaluation may then be made to determine if the user was successfully authenticated (step 610). In the event that the user was not successfully authenticated, the Mobile Payment System processing routine may send a failure notification to the merchant POS (step 612), and the Mobile Payment System processing routine cycle may then end (step 628).
Returning again to step 610, if the user is successfully authenticated, the Mobile Payment System processing routine may query the user record to obtain an authorization level (step 614). Retrieval of the authorization level may include a purchase limit assigned to the user. An evaluation may then be made to determine if the user is authorized to purchase the product (step 616) as described more fully hereinbelow with reference to
The authorization subroutine is invoked (step 702), and the user authorization level may then be compared with the PID classification to determine if the user authorization level is suitable for purchasing the product (step 704). If the user authorization level is insufficient for the PID classification, the purchase may be denied (step 706), and the authorization subroutine cycle may then end (step 712).
Returning again to step 704, if the user authorization level is sufficient for the PID classification, the authorization subroutine may then evaluate the user purchase limit to determine if the purchase limit equals or exceeds the product purchase price (step 708). If the purchase limit is insufficient for the product purchase price, the authorization subroutine may deny the purchase according to step 706. If it is determined that the purchase limit equals or exceeds the product purchase price, the authorization subroutine may then authorize purchase of the product (step 710), and the authorization subroutine cycle may then end according to step 712.
As described, a user operating a mobile terminal may submit a product for purchase at a POS. A product ID is obtained by the POS, and a product price may additionally be obtained by the POS. The user may then enter the user's phone number and PIN at the POS. An authentication and authorization process is then performed to authenticate the user and authorize the transaction. In an embodiment, the POS generates an encrypted message that is transmitted to a Mobile Payment System for user authentication and purchase authorization. The encrypted message includes the user's mobile phone number and PIN, as well as the product ID. On receipt of the encrypted message, the Mobile Payment System may authenticate the user, e.g., via the user's phone number and PIN. If the user is successfully authenticated, the purchase request may be evaluated to determine if the user is authorized to purchase the product. In one implementation, a classification of the product may be evaluated to determine if a user authorization level is sufficient for purchasing the product. Furthermore, a purchase limit assigned to the user may be evaluated to determine if the user has a sufficient purchase limit for the product. If the user is authenticated and authorized successfully, a one-time-password is generated by the Mobile Payment System 140. The one-time-password may then be encrypted and transmitted to the POS along with an encryption key. On receipt of the encrypted message and the key, the POS may decrypt the message to obtain the one-time-password. Additionally, an SMS request may be transmitted from the Mobile Payment System to an SMS provider. The SMS request may include the user's mobile phone number and the one-time-password. The SMS provider then generates an SMS message that is addressed to the user's mobile phone number and that includes the one-time-password. An SMS message including the one-time-password is then transmitted from the SMS service provider to the user's mobile phone. On receipt of the SMS message, the user may read the one-time-password and provide the one-time-password as input to the POS. The POS 110 may then compare the one-time-password provided by Mobile Payment System with the one-time-password provided by the user. If the one-time-passwords match, the purchase may be completed, and a receipt for the product may be issued. If the one-time-passwords do not match, the purchase may be denied by the POS.
In accordance with a particular embodiment, multiple user's may be associated with a common account. Each user may have a distinct identifier, such as a personal identification number, that is used to authenticate a particular user of the account. The personal identification number may be used in conjunction with a mobile phone number associated with the particular account user. Each of the plurality of users of a common account may have different authorization levels assigned thereto. For instance, an adult that is responsible for the account subscription may have an adult authorization designation, while children or other users of the account may have different authorization levels. Assignment of different authorization levels to users of a common account facilitates purchase restrictions, e.g., age-based product restrictions, as well as account spending limits that may be different for different account users.
The flowchart of
Aspects of the present invention may be implemented in software, hardware, firmware, or a combination thereof. The various elements of the system, either individually or in combination, may be implemented as a computer program product tangibly embodied in a machine-readable storage device for execution by a processing unit. Various steps of embodiments of the invention may be performed by a computer processor executing a program tangibly embodied on a computer-readable medium to perform functions by operating on input and generating output. The computer-readable medium may be, for example, a memory, a transportable medium such as a compact disk, a floppy disk, or a diskette, such that a computer program embodying the aspects of the present invention can be loaded onto a computer. The computer program is not limited to any particular embodiment, and may, for example, be implemented in an operating system, application program, foreground or background process, driver, network stack, or any combination thereof, executing on a single computer processor or multiple computer processors. Additionally, various steps of embodiments of the invention may provide one or more data structures generated, produced, received, or otherwise implemented on a computer-readable medium, such as a memory.
Although embodiments of the present disclosure have been described in detail, those skilled in the art should understand that they may make various changes, substitutions and alterations herein without departing from the spirit and scope of the present disclosure.
This patent application claims the benefit of provisional U.S. Patent Application Ser. No. 60/863,431, filed Oct. 30, 2006, which is hereby incorporated by reference.
Number | Date | Country | |
---|---|---|---|
60863431 | Oct 2006 | US |