Patent Publication Number: US-2010131397-A1

Title: Providing &#34;on behalf of&#34; services for mobile telephone access to payment card account

Description:
BACKGROUND 
     Embodiments disclosed herein relate to payment systems. In particular, some embodiments relate to methods, apparatus, systems, means and computer program products for implementing a payment system on the basis of a payment card system. 
     Payment card systems are in widespread use. A prominent payment card system is operated by the assignee hereof, MasterCard International Incorporated, and by its member financial institutions. There have been proposals to permit access to payment card systems via an account holder&#39;s mobile telephone. However, one barrier to commercialization of mobile-based access to payment card systems is the possible need for modifications of the computer systems by which card issuers and acquiring financial institutions participate in payment card systems. There are also issues related to transaction security. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Features and advantages of some embodiments of the present invention, and the manner in which the same are accomplished, will become more readily apparent upon consideration of the following detailed description of the invention taken in conjunction with the accompanying drawings, which illustrate preferred and exemplary embodiments and which are not necessarily drawn to scale, wherein: 
         FIG. 1  is a block diagram that illustrates a transaction-handling system in accordance with aspects of the present invention. 
         FIG. 2  is a block diagram of a computer that is part of the system of  FIG. 1  and performs “on behalf of” (OBO) services. 
         FIG. 3  is a block diagram of a computer that is operated by an acquiring financial institution (FI) in the system of  FIG. 1 . 
         FIG. 4  is a flow chart that illustrates a process that may be performed by the acquiring FI computer of  FIG. 3  in accordance with aspects of the present invention. 
         FIG. 5  is a flow chart that illustrates a process that may be performed by the OBO service provider computer of  FIG. 2  in accordance with aspects of the present invention. 
         FIGS. 6A-6B  together form a flow chart that illustrates a process that may be performed by the OBO service provider computer of  FIG. 2  in accordance with other aspects of the present invention. 
         FIG. 7  is a block diagram that illustrates various functions that may be supported in some embodiments by the OBO service provider computer of  FIG. 2 . 
     
    
    
     DETAILED DESCRIPTION 
     In general, and for the purpose of introducing concepts of embodiments of the present invention, a payment card system purchase transaction is initiated using the telephone number for a mobile telephone operated by the holder of a payment card account. A service provider performs “on behalf of” (OBO) services for either or both of the acquiring financial institution (FI) and the issuing FI. As is familiar to those who are skilled in the art, OBO services refer to services performed by a third party provider for an issuer FI or an acquirer FI in a payment card system. As is also well known, the acquirer FI is the organization that transmits a purchase transaction to a payment card system for routing to the issuer of the payment card account in question. Typically, the acquirer FI has an agreement with merchants, wherein the acquirer FI receives authorization requests for purchase transactions from the merchants, and routes the authorization requests to the issuers of the payment cards to be used for the purchase transactions. In some cases, the acquirer FI may contract out transaction handling services to a third party service provider. As used in this disclosure and the appended claims, “acquirer FI” includes both such FIs and third party service providers under contract to such FIs. The terms “acquirer”, “acquirer FI” and “acquiring FI” will be used interchangeably herein. The terms “issuer”, “issuer FI” and “issuing FI” will also be used interchangeably herein to refer to the FI that issued a payment card account to an account/card holder. 
     Continuing with the general overview of concepts of the invention, the OBO service provider may aid the acquirer and issuer by translating the card holder&#39;s mobile telephone number into the PAN (primary account number) for the payment card account in question. Further, the OBO service provider may handle a challenge-and-response security procedure via the card holder&#39;s mobile telephone. In some embodiments, the OBO service provider may be an intermediary between the merchant and the acquirer. In other embodiments (or in other types of transactions in the same embodiment) the acquirer may bring the OBO service provider in to assist on a transaction request received by the acquirer. 
       FIG. 1  is a block diagram that illustrates a transaction-handling system  100  in accordance with aspects of the present invention. The transaction-handling system  100  includes an acquirer  102 , payment system  104  and an issuer  106 . Block  102  may be considered to represent both the acquiring FI and a computer (not separately indicated) that handles the acquirer functions for purchase transactions in a conventional payment card system. Except for certain modifications described herein, the acquirer  102  may function in a generally conventional manner. 
     The payment system  104  may operate in a conventional manner. An example of a suitable payment system is the “Banknet” system operated by MasterCard International Inc., the assignee hereof. As is well-known by those who are skilled in the art, the payment system  104  routes purchase transaction authorization requests from acquirers to issuers, and routes purchase transaction authorization responses back from the issuers to the acquirers. A separate system for clearing purchase transactions may also be provided by the operator of the payment system  104  but is not indicated herein in the interests of simplifying the drawing. 
     Block  106  may be considered to represent both the issuer FI and its computer by which it participates in the payment card system. The issuer FI  106  may operate in a conventional manner to receive authorization requests via the payment system  104  and to transmit authorization responses back to acquirers via the payment system  104 . 
       FIG. 1  shows only components of the transaction-handling system  100  that are involved in handling one transaction. In practice, the transaction-handling system  100  may include many more acquiring FIs than the single acquirer  102  shown in  FIG. 1 , and may include many more issuers than the single issuer  106  shown in  FIG. 1 . 
     The transaction-handling system  100  also includes an OBO service provider computer  108  which exchanges messages with the acquirer  102  and provides services which are described below. Also shown in  FIG. 1  is a merchant device  110  which initiates a purchase transaction to be processed by the transaction-handling system  100 . The merchant device  110  may be, for example, a point of sale terminal or a commerce-enabled mobile telephone. 
     (Although only one merchant device  110  is shown in  FIG. 1 , in practice there may be a large number of merchant devices that may from time to time transmit purchase transaction authorization requests to the acquirer computer  102 .) 
     Also depicted in  FIG. 1  is a mobile telephone  112  which is operated by the individual who is making the purchase represented by the purchase transaction. 
       FIG. 2  is a block diagram of the OBO service provider computer  108 . 
     The OBO service provider computer  108  may be conventional in its hardware aspects but may be controlled by software to cause it to operate in accordance with aspects of the present invention. 
     The OBO service provider computer  108  may include a computer processor  200  operatively coupled to a communication device  201 , a storage device  204 , an input device  206  and an output device  208 . 
     The computer processor  200  may be constituted by one or more conventional processors. Processor  200  operates to execute processor-executable steps, contained in program instructions described below, so as to control the OBO service provider computer  108  to provide desired functionality. 
     Communication device  201  may be used to facilitate communication with, for example, other devices (such as the acquirer computer  102 ). Communication device  201  may, for example, have capabilities for engaging in data communication over conventional computer-to-computer data networks. 
     Input device  206  may comprise one or more of any type of peripheral device typically used to input data into a computer. For example, the input device  206  may include a keyboard and a mouse. Output device  208  may comprise, for example, a display and/or a printer. 
     Storage device  204  may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., magnetic tape and hard disk drives), optical storage devices such as CDs and/or DVDs, and/or semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices, as well as so-called flash memory. Any one or more of the listed storage devices may be referred to as a “memory” or a “storage medium”. 
     Storage device  204  stores one or more programs for controlling processor  200 . The programs comprise program instructions that contain processor-executable process steps of OBO service provider computer  108 , including, in some cases, process steps that constitute processes provided in accordance with principles of the present invention, as described in more detail below. 
     The programs may include an application  210  that manages a process by which customers (i.e., cardholders) may register themselves and/or their mobile devices with the OBO service provider computer  108 . In some embodiments, the cardholder enrollment process may allow the cardholders to register themselves with the OBO service provider computer  108  by accessing via their mobile telephone  112  a suitable web page hosted by the OBO service provider computer  108 . The information gathered from the cardholder during the registration process may include payment card account number and mobile telephone number (or other mobile identifier). The enrollment process may also require the cardholder to select a mobile personal identification number (M-PIN) to be used for security purposes in connection with payment card system purchase transactions to be initiated by the cardholder. 
     In addition or alternatively, the registration of cardholders with the OBO service provider computer  108  may be a batch process in which issuers of the cardholders&#39; payment card accounts transfer information about the cardholders to the OBO service provider computer  108 . 
     The storage device  204  may also store an application  212  for controlling the OBO service provider computer  108  to provide account support services to the cardholders. Details of the account support services will be provided below. 
     Another application that may be stored by the storage device  204  is for handling individual transactions and is indicated by reference numeral  214  in  FIG. 2 . Details of operation of the transaction handling application  214  in accordance with various aspects of the invention will be discussed hereinbelow, particularly with reference to FIGS.  5  and  6 A- 6 B. 
     Still another application  216  may be stored by the storage device  204  and may control the OBO service provider computer  108  to provide customer care services that will be described below. 
     In addition, an application  218  may be stored by the storage device  204 , and may control the OBO service provider computer  108  to provide mobile wallet services that will be described below. 
     Still further, the storage device  204  may store an application  220  for controlling the OBO service provider computer  108  to provide mobile banking services that will be described below. 
     Moreover, the storage device  204  may store an application  222  that controls the OBO service provider computer  108  to provide stored value account management services, as described below. 
     Also, an application  224  may be stored in the storage device  204  to control the OBO service provider computer  108  to provide functions related to data and communication security, including data encryption and encryption key management. 
     A further application  226  may be stored in the storage device  204  to control the OBO service provider computer  108  to provide reports to customers and/or operators of the OBO service provider computer  108 . 
     Still another application  228  may be stored in the storage device  204  and may control the OBO service provider computer  108  to perform billing functions to charge acquirers and/or issuers for services provided by the OBO service provider computer  108 . 
     Reference numeral  230  in  FIG. 2  identifies one or more databases that are maintained by the OBO service provider computer  108  on the storage device  204 . Among these databases may be a customer database, a merchant database, an issuer database, an acquirer database and a transaction database. 
     The application programs of the OBO service provider computer  108 , as described above, may be combined in some embodiments, as convenient, into one, two or more application programs. Moreover, the storage device  204  may store other programs, such as one or more operating systems, device drivers, database management software, web hosting software, etc. 
       FIG. 3  is a block diagram of the acquirer computer  102  that is part of the transaction-handling system  100  shown in  FIG. 1 . The hardware architecture of the acquirer computer  102  may be conventional and may be the same as that of the OBO service provider computer  108 . Thus, the above description of the hardware aspects of the OBO service provider computer  108  is equally applicable to the hardware aspects of the acquirer computer  102 . Nevertheless, the following description is provided to summarize the hardware components of the acquirer computer  102 . 
     The acquirer computer  102  may include a processor  300  that is in communication with a communication device  301 , a storage device  304 , an input device  306  and an output device  308 . The storage device  304  may store an application program or program module  310  which controls the acquirer computer  102  to handle normal transactions in a conventional manner. As used in the previous sentence, “normal transactions” refers to purchase transaction authorization requests that include the PAN for the account to which the transaction is to be charged. 
     The storage device  304  may further store an application program/program module  312  that controls the acquirer computer  102  to handle authorization requests that include a “pseudo PAN” rather than a PAN. As used herein, “pseudo PAN” refers to a customer identifier other than a payment card account PAN. For example, in some embodiments, the pseudo PAN may be the customer&#39;s mobile telephone number. Details of the functionality provided by the program/program module  312  will be provided below, particularly in connection with  FIG. 4 . 
     In addition, the storage device  304  may store one or more databases  314  that are used by the acquirer computer  102  in handling transactions. 
       FIG. 4  is a flow chart that illustrates a process that may be performed by the acquirer computer  102  in accordance with aspects of the present invention. 
     At  402  in  FIG. 4 , the acquirer computer  102  determines whether it has received a purchase transaction authorization request. The authorization request, if received, may have been transmitted to the acquirer computer  102  by the merchant device  110  as indicated at  114  in  FIG. 1 . Until the acquirer computer  102  receives an authorization request, the process of  FIG. 4  may idle, as indicated by branch  404  in  FIG. 4 . 
     If an authorization request is received at  402 , then the process of  FIG. 4  advances from  402  to decision block  406 . At  406 , the acquirer computer  102  determines whether the authorization request includes a PAN or a pseudo PAN. 
     In various embodiments, there are a number of different ways in which the acquirer computer  102  may determine whether the authorization request includes a pseudo PAN. For example, in some embodiments, the merchant device  110  ( FIG. 1 ) may have operated to flag the authorization request to indicate that the authorization request includes a pseudo PAN. For example, the merchant employee who operates the merchant device  110  may have actuated an appropriate key or operated an editing function on the merchant device  110  to cause the merchant device to flag the transaction as including a pseudo PAN. For example, in some embodiments, the customer/cardholder may have entered the pseudo PAN and a card PIN (personal identification number) into the merchant device  110  by operating a keypad associated with the merchant device  110 . In such a case, the pseudo PAN and the card PIN may be included in the authorization request sent from the merchant device  110  to the acquirer computer  102 . The authorization request may also include conventional information for a purchase transaction authorization request, including a transaction amount and a merchant identifier. As noted above, in some embodiments the pseudo PAN may be the customer&#39;s mobile telephone number. In some embodiments, the acquirer computer  102  may determine whether the authorization request includes a PAN or a pseudo PAN based at least in part on the format (e.g., number of digits) of the PAN or pseudo PAN 
     If at  406  the acquirer computer  102  determines that the authorization request received from the merchant device  110  includes a PAN, then the process of  FIG. 4  may advance from  406  to block  408 . At  408 , the acquirer computer  102  may handle the authorization request in a conventional manner. That is, the acquirer computer  102  may transmit the authorization request to the payment system  104  ( FIG. 1 ) for routing to the issuer FI  106 , as indicated by the PAN. 
     Continuing to refer to  FIG. 4 , if at  406  the acquirer computer  102  determines that the authorization request received from the merchant device  110  includes a pseudo PAN, then the process of  FIG. 4  may advance from  406  to block  410 . At  410 , the acquirer computer  102  transmits a request (reference numeral  116  in  FIG. 1 ) to the OBO service provider computer  108  to request that the OBO service provider computer  108  translate the pseudo PAN into the PAN for the payment card account to which the transaction is to be charged. It will be appreciated that the request includes the pseudo PAN received by the acquirer computer  102  in the authorization request from the merchant device  110 . 
     Following  410 , the process of  FIG. 4  may idle, as indicated at  412 , while the acquirer computer  102  awaits a response from the OBO service provider computer  108  to the pseudo PAN translation request. Once the acquirer computer  102  receives the response (reference numeral  118  in  FIG. 1 ) from the OBO service provider computer  108 , the process of  FIG. 4  may advance from  412  to  414 . As will be understood in view of the subsequent discussion of activities of the OBO service provider computer  108 , the response received by the acquirer computer  102  may include the PAN for the customer in question, along with a security code generated by the service provider. At  414 , the acquirer computer  102  generates an authorization request based on the authorization request received from the merchant device  110 , but with the PAN and security code received from the OBO service provider computer  108  inserted into the authorization request by the acquirer computer  102 . In the authorization request as generated by the acquirer computer  102 , the PAN received from the OBO service provider computer  108  is substituted for the pseudo PAN that was received in the authorization request from the merchant device  110 . The authorization request as generated by the acquirer computer  102  may include the card PIN received by the acquirer computer  102  from the merchant device  110 . 
     In the process of  FIG. 4 , block  416  follows  414 . At  416 , the acquirer computer  102  transmits the authorization request generated at  414  to the payment system  104  ( FIG. 1 ) for routing to the issuer FI  106 , as indicated by the PAN provided by the OBO service provider computer  108 . The authorization request as generated at  414  and transmitted at  416  (the authorization request also indicated by reference numerals  120  and  122  in  FIG. 1 ) may include all data elements customarily included in an authorization request provided by an acquirer in accordance with conventional practices. The authorization request may be processed by the payment system  104  and the issuer FI  106  in a conventional manner. 
     Following  416 , the process of  FIG. 4  may idle, as indicated at  418 , while the acquirer computer  102  awaits a response from the issuer  106  to the authorization request. Once the acquirer computer  102  receives the authorization response from the issuer  106  (the authorization response also indicated by reference numerals  124  and  126  in  FIG. 1 ), the process of  FIG. 4  may advance from  418  to  420 . At  420 , the acquirer computer  102  transmits the authorization response (indicated at this point by reference numeral  128  in  FIG. 1 ) to the merchant device  110 . This may be done generally in accordance with conventional practices. For example, the authorization response transmitted from the acquirer computer  102  to the merchant device  110  may include the merchant&#39;s transaction identification number and the PAN to which the transaction will be charged. This allows the merchant device  112  to print a truncated version of the PAN on the customer&#39;s receipt in accordance with conventional practices. 
       FIG. 5  is a flow chart that illustrates a process that may be performed by the OBO service provider computer  108  in accordance with aspects of the present invention. 
     At  502  in  FIG. 5 , the OBO service provider computer  108  determines whether it has received a request to translate a pseudo PAN into a PAN. This request may be of the type described above with respect to block  410  in  FIG. 4  (and indicated at  116  in  FIG. 1 ) and thus may be from the acquirer computer  102 . It should be understood that the acquirer computer  102  shown in  FIG. 1  and discussed in connection with  FIGS. 4 and 5  may be one of numerous similar computers that are operated by or on behalf of various acquiring FIs and that are operated to send requests of this sort to the OBO service provider computer  108 . Thus the OBO service provider computer  108  may provide services to numerous acquiring FIs. 
     As indicated by branch  504  from  502 , the process of  FIG. 5  may idle until a pseudo PAN translation request  116  ( FIG. 1 ) is received. However, once the OBO service provider computer  108  receives such a request, the process of  FIG. 5  may advance from  502  to  506 . At  506 , the OBO service provider computer  108  may determine whether the pseudo PAN received in the request is valid. This may be done, for example, by the OBO service provider computer  108  looking up the pseudo PAN in a database of registered users. If the pseudo PAN received at  502  matches a pseudo PAN for a validly registered user, then the OBO service provider computer  108  may determine that the pseudo PAN is valid. If not, then the OBO service provider computer  108  may determine that the pseudo PAN is invalid. 
     In the latter case, the process of  FIG. 5  may advance from  506  to block  508 . At block  508 , the OBO service provider computer  108  may provide a “decline” or “reject” message to the acquirer computer  102  as a response to the request received at  502 . (In this case, the acquirer computer  102  may provide a negative authorization response to the merchant device  110 ). In some embodiments, the “reject” message from the OBO service provider computer  108  to the acquirer computer  102  may include a reason (e.g., “invalid pseudo PAN”) for the rejection. 
     In the former case (i.e., if the OBO service provider computer  108  determines at  506  that the pseudo PAN in the request was valid), then the process of  FIG. 5  may advance from  506  to block  510 . At block  510 , the OBO service provider computer  108  may issue a challenge (reference numeral  130  in  FIG. 1 ) to the customer mobile telephone  112 . For example, the subscriber profile looked up in connection with the pseudo PAN may indicate what method of challenge the OBO service provider computer  108  is to use. In addition or alternatively, the pseudo PAN itself may be the telephone number for the mobile telephone  112  and may provide the information needed for the OBO service provider computer  108  to initiate the challenge. In some embodiments, the challenge may take the form of a text message sent by the OBO service provider computer  108  to the customer mobile telephone  112 . In other embodiments, the challenge may take the form of initiating a telephone call (e.g., by an automatic device such as an interactive voice response—IVR—unit associated with/incorporated in the OBO service provider computer  108 ) to the customer mobile telephone  112 . 
     (In some embodiments, a mobile device other than a mobile telephone may participate in the challenge and response functions described herein. For example, the challenge may alternatively be issued to a PDA (personal digital assistant) with mobile communication capabilities that is registered to the customer in question. For example, the challenge may take the form of an electronic mail message to the mobile device. In other embodiments, the challenge and response may be performed in a mobile messaging session between the mobile device/telephone and the service provider. The mobile device/telephone may have been programmed with a suitable application program to support receiving and responding to challenges from the OBO service provider computer  108 .) 
     Following  510 , the process of  FIG. 5  may idle, as indicated at  512 , while the OBO service provider computer  108  awaits a response from the customer to the challenge issued at  5   10 . In some embodiments, the challenge prompts the customer to enter a mobile PIN (M-PIN) into the mobile telephone  112  and to transmit the M-PIN (e.g., via a text message, or via keyboard entry in response to a query from an IVR unit, etc.) to the service provider. (In a preferred embodiment, the M-PIN must be manually entered into the mobile telephone  112  by the customer in response to the challenge, and is not stored in the mobile telephone. In some embodiments, the M-PIN may be encrypted by the mobile telephone  112  before it is transmitted to the OBO service provider computer  108 . In some embodiments, the customer may have the option of declining the transaction instead of entering the M-PIN in response to the challenge.) Once the OBO service provider computer  108  receives the response from the mobile telephone  112  (reference numeral  132  in  FIG. 1  indicates the response), the process of  FIG. 5  may advance from  512  to  514 . At  514 , the OBO service provider computer  108  may determine whether the M-PIN received from the mobile telephone  112  is valid. This may be done, for example, by referring to the subscriber profile stored by the OBO service provider computer  108  for the customer in question. (If the M-PIN was encrypted by the mobile telephone  112 , the processing at  514  may include decrypting the M-PIN.) It will be appreciated that the valid M-PIN may have previously been selected by or assigned to the customer and stored in the customer&#39;s profile in a database maintained in the OBO service provider computer  108 . 
     If the OBO service provider computer  108  determines at  514  that the M-PIN is not valid (or if the customer declines the transaction), the process of  FIG. 5  may advance from  514  to  508 . At  508 , as before, the OBO service provider computer  108  may provide a “decline” or “reject” message to the acquirer computer  102 . In some embodiments, the reject message may provide a specific reason for rejecting the transaction such as “M-PIN not valid” or “customer declines transaction”. 
     If the OBO service provider computer  108  determines at  514  that the M-PIN received from the mobile telephone  112  is valid, then the process of  FIG. 5  may advance from  514  to block  516 . At block  516 , the OBO service provider computer  108  may generate a security code for the transaction. This may include simply looking up the security code from the customer&#39;s profile, or may include generating the security code in accordance with a conventional algorithm. In some embodiments the security code may be of the type known as an “AAV” or a “CVC2”. 
     After  516 , the process of  FIG. 5  may advance to block  518 . At block  518 , the OBO service provider computer  108  may generate and transmit to the acquirer computer  102  the response indicated at  118  in  FIG. 1  and referred to above in connection with block  412  in  FIG. 4 . That is, the response from the OBO service provider computer  108  to the acquirer computer  102  may include both the security code generated at  516  and the customer PAN which corresponds to the pseudo PAN received by the OBO service provider computer  108  at  502 . It will be appreciated that the OBO service provider computer  108  may have looked up the customer PAN from the customer&#39;s profile in a database maintained by the OBO service provider computer  108 . 
     In the above scenario ( FIGS. 1 ,  4  and  5 ), the OBO service provider computer  108  may be considered to have provided OBO services both for the acquirer and the issuer. In particular, the OBO services provided by the OBO service provider computer  108  for the acquirer may be considered to include pseudo PAN to PAN translation and provision of the security code. The OBO services provided by the OBO service provider computer  108  for the issuer may be considered to include the transaction security process that involves challenge and response to the customer&#39;s mobile telephone. In some respects the services provided by the OBO service provider computer  108  may be considered to overlap or blend OBO services to the acquirer and the issuer. With the OBO service provider computer  108  providing these services, relatively few modifications to existing practices may be required of the acquirers and issuers in order to implement a highly convenient and secure mobile telephone/device based payment system that cost-effectively piggybacks on existing payment card system infrastructure. 
       FIGS. 6A-6B  together form a flow chart that illustrates a process that may be performed by the OBO service provider computer  108  in accordance with other aspects of the present invention. 
     The process depicted in  FIGS. 6A-6B  assumes a somewhat different message flow from that illustrated in  FIG. 1 . According to the modified message flow contemplated by  FIGS. 6A-6B , the merchant device  110  ( FIG. 1 ) engages in communications with the OBO service provider computer  108  rather than with the acquirer computer  102 . Otherwise the overall message flow of  FIG. 1  is generally similar to that previously described. Differences between the previously described and modified messages flows will be further explained in conjunction with  FIGS. 6A-6B . 
     Referring, then, to  FIG. 6A , at  602  the OBO service provider computer  108  determines whether it has received a transaction message from the merchant device  110 . (Although only one merchant device  110  is shown in  FIG. 1 , in practice there may be a large number of merchant devices that may from time to time transmit transaction messages to the OBO service provider computer  108 .) In the embodiment illustrated in  FIGS. 6A-6B , the merchant device  110  submits the transaction message to the OBO service provider computer  108  in lieu of sending an authorization request directly to an acquirer. Hence, in functional terms, the transaction message may be considered to be an authorization request, and may include the amount of the transaction, a merchant identifier and/or a merchant device identifier and other pertinent information. 
     (It is assumed that the merchant and/or the merchant device  110  have previously been registered with the OBO service provider computer  108  as an authorized merchant for the mobile device based payment system described herein.) 
     Prior to transmitting the transaction message, the merchant may have entered the customer&#39;s pseudo PAN into the merchant device  110  along with other information (e.g., transaction amount) relevant to the transaction in question. In some embodiments, the merchant and the merchant device may be remote from the customer at the time of the transaction, as in the case of a purchase or other transaction carried out by telephone. In other embodiments, the customer may be present at the merchant device  110  and may himself/herself enter his/her pseudo PAN into the merchant device  110 . 
     Until the OBO service provider computer  108  receives a transaction message, the process of  FIGS. 6A-6B  may idle, as indicated by branch  604  in  FIG. 6A . If a transaction message is received by the OBO service provider computer  108  from the merchant device  110 , then the process of  FIGS. 6A-6B  advances from  602  to decision block  606 . At decision block  606 , the OBO service provider computer  108  determines whether the merchant identifier/merchant device identifier in the transaction message is valid. That is, the OBO service provider computer  108  may use the merchant identifier/merchant device identifier included in the transaction message to access a database of registered merchants/merchant devices to determine whether there is a matching merchant identifier/merchant device identifier in the database. If not, then the process of  FIGS. 6A-6B  may advance from  606  to block  608 . At block  608 , the OBO service provider computer  108  sends a message back to the merchant device  110  to indicate that the transaction is rejected. 
     In some embodiments, it may also be required that the transaction message include a merchant PIN. If so, block  606  may also include looking up and validating the merchant PIN. In other embodiments, no PIN is required from the merchant device  110 . 
     Considering again decision block  606 , if the OBO service provider computer  108  determines that the merchant identifier/merchant device identifier is valid, then the process of  FIGS. 6A-6B  may advance from  606  to block  610 . At block  610 , the OBO service provider computer  108  may issue a challenge to the customer mobile telephone  112 . This challenge, and the customer&#39;s response, may be the same as or similar to the challenge and response described hereinabove in connection with blocks  510  and  512  of  FIG. 5 . 
     Following  610 , the process of  FIGS. 6A-6B  may idle, as indicated at  612 , while the OBO service provider computer  108  awaits a response from the customer to the challenge issued at  610 . Once the OBO service provider computer  108  receives the response from the mobile telephone  112 , the process of  FIGS. 6A-6B  may advance from  612  to  614 . At  614 , the OBO service provider computer  108  may determine whether an M-PIN received from the mobile telephone  112 , in response to the challenge, is valid. This may be done in the same manner described above in connection with block  514  in  FIG. 5 . If the OBO service provider computer  108  determines at  614  that the M-PIN is not valid (or if the customer declined the transaction), the process of  FIGS. 6A-6B  may advance from  614  to block  608 . At block  608 , the OBO service provider computer  108  may provide a “decline” or “reject” message to the merchant device  110 . In some embodiments, that message may include a specific reason such as “M-PIN not valid” or “customer declines transaction”. 
     If the OBO service provider computer  108  determines at  614  that the M-PIN received from the mobile telephone  112  is valid, then the process of  FIGS. 6A-6B  may advance from  614  to  616 . At  616 , the OBO service provider computer  108  may generate a security code for the transaction. This may be done in the same manner as described hereinabove in connection with block  516  in  FIG. 5 . 
     After  616 , the process of  FIGS. 6A-6B  may advance to block  618  ( FIG. 6B ). At  618 , the OBO service provider computer  108  may generate an authorization request for the transaction. The authorization request may include the PAN for the customer, which the OBO service provider computer  108  may have looked up from its database of customer profiles, based on the pseudo PAN included in the transaction message received from the merchant device  110  at step  602  ( FIG. 6A ). The authorization request may also include the security code generated by the OBO service provider computer  108  at  616 . The authorization request may be in substantially the same format as that used for purchase transaction authorization requests conventionally provided by merchants to acquirer FIs in payment card systems. The authorization request may for example include the amount of the transaction and a merchant identifier that identifies the merchant which sent the transaction message to the OBO service provider computer  108 . 
     The process of  FIGS. 6A-6B  may advance from  618  to block  620  ( FIG. 6B ). At  620  the OBO service provider computer  108  may transmit, to the acquirer computer  102 , the authorization request generated by the OBO service provider computer  108  at  618 . Following  620 , the process of  FIGS. 6A-6B  may idle, as indicated at  622  in  FIG. 6B , while the OBO service provider computer  108  awaits a response from the acquirer computer  102  to the authorization request. It should be understood that the acquirer computer  102 , the payment system  104  and the issuer  106  may handle and respond to the authorization request in a conventional manner. As a result, the issuer  106  may generate an authorization response that is routed back to the OBO service provider computer  108  via the payment system  104  and the acquirer computer  102 . Once the OBO service provider computer  108  receives the authorization response from the acquirer computer  102 , the process of  FIGS. 6A-6B  may advance from  622  to  624 . At  624 , the OBO service provider computer  108  may transmit the authorization response to the merchant device  110 . In addition, at  626 , the OBO service provider computer  108  may transmit a message to the customer&#39;s mobile telephone  112  to confirm that the transaction has been authorized. 
     The process of  FIGS. 6A-6B  may provide many of the benefits discussed above in connection with  FIGS. 1 ,  4  and  5 , including implementation of a mobile telephone/device based payment system built on the foundation of existing payment card system infrastructure, while requiring minimal or no changes in operation on the part of acquirer and issuer FIs. 
     In addition to the core functionality described above with reference to FIGS.  1  and  4 - 6 B, the OBO service provider computer  108  may provide other features and functions to enhance the usefulness and customer-friendliness of the mobile telephone/device based payment system.  FIG. 7  is block diagram that illustrates functionality that may be provided by the OBO service provider computer  108 . Block  702  in  FIG. 7  represents the purchase transaction functionality illustrated in  FIGS. 6A and 6B . 
     For example, the OBO service provider computer  108  may manage stored-value accounts for the registered subscribers. (This functionality is indicated by block  704  in  FIG. 7 .) The stored-value accounts, in some embodiments, may be funded by one or more of: (a) cash loading from merchant POS terminals, (b) direct debit from a bank direct deposit account (DDA), funding from a credit or debit card account, and account to account transfers. The OBO service provider computer  108  may provide daily account balance reconciliation and settlement information for the stored-value accounts. 
     Also or alternatively, the OBO service provider computer  108  may enable customers to access their bank account information, perform core banking transactions and request information from their banks via the customer&#39;s mobile telephone/device (this functionality indicated by block  706  in  FIG. 7 ). These accesses may include account balance inquiries, requesting information regarding the last X transactions, requesting an account statement, requesting information about rates and charges, and activity alerts and notifications (e.g., based on SMS), including for example notification of payroll deposits. 
     The OBO service provider computer  108  may also function as a general mobile wallet server (block  708 ,  FIG. 7 ), to permit the customer&#39;s payment card account to be linked to the mobile service account. This functionality may support transaction types such as (a) mobile service top-up, (b) remote merchant purchase, and (c) mobile service bill pay via recurring payment. 
     The OBO service provider computer  108  may also supply connectivity (block  710 ,  FIG. 7 ) to mobile network operators (MNOs) so that the payment system is portable across mobile service providers. This connectivity may include the physical and logical connectivity between MNO messaging systems and the OBO service provider computer  108 , including signaling links, messaging links, and data communications to enable communication between the OBO service provider computer  108  and the mobile payment application in the customer mobile telephone/device. 
     Still further, the OBO service provider computer  108  may supply various customer care features (block  712 ,  FIG. 7 ), including mobile payments account customer registration, linking between payment account and mobile account, reporting and administrative support. The administrative functions for issuers and acquirers may be accessed via a Web-based interface. The OBO service provider computer  108  may provide customer “self-care” capabilities such as prepaid account balance and activity queries, and mobile payment account profiles. The OBO service provider computer  108  may further provide reporting capabilities, including end-of-day summary reports and online reporting for acquirers and issuers via a Web-based interface. The reports may include statistical information relating to each FI&#39;s subscribers, mobile payment transactions by subscriber, audit reports, etc. Still further, the OBO service provider computer  108  may implement billing for its services to the acquirers and issuers. 
     In addition, the OBO service provider computer  108  may provide capabilities for registration (block  714 ,  FIG. 7 ) of customers, issuers, MNOs and merchants. Customers may be required to open a prepaid payment card account with a registered issuer as a prerequisite for registration in the mobile payments system. Anti-money laundering and “know your customer” compliance may be handled by the issuing FI with respect to the payment card account. Registration of merchants with the OBO service provider computer  108  may be performed by the acquiring FIs. 
     Still further, the OBO service provider computer  108  may support person-to-person remittance transactions (block  716 ,  FIG. 7 ), utilizing, for example, the “payment transaction” capabilities of the underlying payment card system. 
     One implementation of the above-mentioned mobile account top-up function may operate as follows. (This may be included in mobile account management functionality, represented by block  718 ,  FIG. 7 .) First, the customer may select the “top-up” feature from the device menu. Next the customer may send the transaction request to the OBO service provider computer  108 . The OBO service provider computer  108  may validate the pseudo PAN and perform the above-described challenge-and-response process, including M-PIN validation, with the customer&#39;s mobile telephone/device. The OBO service provider computer  108  may next generate the security code and perform a PAN look-up for the customer, and then transmit an appropriate authorization request to the acquirer for the customer&#39;s MNO. After conventional handling of the authorization request via the acquirer, payment system and issuer, the OBO service provider computer  108  receives the authorization response and (if the auth response is positive) sends a top-up credit message to the MNO and a confirmation/receipt message to the customer&#39;s mobile telephone/device. 
     One implementation of the above-mentioned person-to-person remittance feature (block  716 ,  FIG. 7 ) may operate as follows. Initially the customer selects the remittance feature from the device menu. Then the customer sends the transaction request to the OBO service provider computer  108 . Next, the OBO service provider computer  108  validates the mobile device identifier (pseudo PAN) and performs the above-described challenge-and-response process, with M-PIN validation, with respect to the customer&#39;s mobile telephone/device. The OBO service provider computer  108  then initiates a payment transaction through the payment system via the issuer of the customer&#39;s payment card account. The payment transaction may, for example, conform to the process for remittances via a payment card system, as described in co-pending, commonly assigned U.S. patent application Ser. No. 11/839,956, filed Aug. 10, 2007, which is incorporated herein by reference. Upon approval of the payment transaction via the sending and receiving issuers and the payment system, the OBO service provider computer  108  may send a confirmation/receipt message to the customer and a notification message to the recipient. 
     The OBO service provider computer  108  may also provide a bill payment function (block  720 ,  FIG. 7 ), which may be implemented as follows. Initially, the OBO service provider computer  108  may receive from a billing entity (e.g., a utility company or the like) a data file containing details of individual accounts being billed by the entity. The OBO service provider computer  108  then sends a bill due notice message to the customer&#39;s mobile telephone/device. The customer selects a bill payment feature from the menu presented by the mobile telephone/device and sends a bill pay transaction message from the mobile telephone/device to the OBO service provider computer  108 . The OBO service provider computer  108  may validate the pseudo PAN and perform the above-described challenge-and-response process, including M-PIN validation, with the customer&#39;s mobile telephone/device. The OBO service provider computer  108  may next generate the security code and perform a PAN look-up for the customer, and then transmit an appropriate authorization request to the acquirer for the billing entity. After conventional handling of the authorization request via the acquirer, payment system and issuer, the OBO service provider computer  108  receives the authorization response and (if the auth response is positive) sends a payment advice message to the billing entity and a confirmation/receipt message to the customer&#39;s mobile telephone/device. 
     An implementation of an account-to-account transfer function (mobile banking, block  706 ,  FIG. 7 ) may operate as follows. This process assumes that both accounts are maintained by the issuer of the customer&#39;s payment card account First, the customer may select an account transfer feature from the menu provided by his/her mobile telephone/device. The customer may then send the account transfer transaction to the OBO service provider computer  108 . The OBO service provider computer  108  may validate the pseudo PAN and perform the above-described challenge-and-response process, including M-PIN validation, with the customer&#39;s mobile telephone/device. The OBO service provider computer  108  may next send an account transfer request message to the issuer of the customer&#39;s payment card account. The issuer may perform the account transfer within its internal systems as an “on-us” transaction and then send a response message to the OBO service provider computer  108 . The OBO service provider computer  108  may then send a confirmation/receipt message to the customer&#39;s mobile telephone device. 
     An implementation of the above-mentioned balance query function (mobile banking, block  706 ,  FIG. 7 ) may operate as follows. First, the customer may select a balance query feature from the menu provided by his/her mobile telephone/device. The customer may then send the balance query to the OBO service provider computer  108 . The OBO service provider computer  108  may validate the pseudo PAN and perform the above-described challenge-and-response process, including M-PIN validation, with the customer&#39;s mobile telephone/device. The OBO service provider computer  108  may next send the balance query to the issuer of the customer&#39;s payment card account. The issuer may perform an account balance lookup within its internal systems as an “on-us” transaction and then send a response to the query to the OBO service provider computer  108 . The OBO service provider computer  108  may then send the response to the customer&#39;s mobile telephone/device. An account activity query function and an account rates and fees query function may be performed in a similar fashion. Similarly, a statement request function may be similar, but with the concluding step being issuance of the statement (by electronic mail or hard copy mail) from the issuer to the customer. 
     Still further, the system may implement a function (mobile banking, block  706 ,  FIG. 7 ) with respect to bank branch/bank agent cash loads for the customer&#39;s payment card account. This may be performed as follows. The customer may visit a bank branch or bank agent and deliver cash over the counter. The branch agent may then provide a deposit receipt to the customer. The issuer of the payment card account then credits the account with the amount of the cash deposit, and sends an administrative advice message to that effect to the OBO service provider computer  108  via the payment system  104 . The OBO service provider computer  108  provides a suitable response/acknowledgment back through the payment system  104  to the issuer. Next the OBO service provider computer  108  validates the customer&#39;s PAN and looks up the mobile phone number or other mobile device identifier for the customer. Finally, the OBO service provider computer  108  provides a deposit notification message to the customer via SMS messaging to the customer&#39;s mobile telephone/device. 
     The system may further implement, as follows, cash loads (mobile banking, block  706 ,  FIG. 7 ) to the customer&#39;s payment card account via merchant locations. The customer may visit the merchant location and deliver cash to the merchant. The merchant may then initiate a payment card system payment transaction via the merchant&#39;s acquirer FI and the payment system and targeted to the issuer of the customer&#39;s payment card account. The payment transaction may be performed in a conventional manner, including an auth request from the merchant that includes the load amount and the customer&#39;s PAN. The issuer of the payment card account credits the account with the amount of the load, and sends an administrative message regarding the credit to the OBO service provider computer  108  via the payment system  104 . The OBO service provider computer  108  provides a suitable response/acknowledgment back through the payment system  104  to the issuer. Next the OBO service provider computer  108  validates the customer&#39;s PAN and looks up the mobile phone number or other mobile device identifier for the customer. Finally, the OBO service provider computer  108  provides a load notification message to the customer via SMS messaging to the customer&#39;s mobile telephone/device. 
     Also, the system may implement a function for payroll or social benefits deposits (block  722 ,  FIG. 7 ) to the customer&#39;s payment card account. First, the disbursing entity (e.g., government agency or customer&#39;s employer) may provide a batch file of disbursement instructions to the disbursing bank. The disbursing bank then sends a direct credit to the issuer of the customer&#39;s payment card account via an ACH system or the like. Next the issuer credits the disbursement to the customer&#39;s payment card account via the issuer&#39;s internal system. The issuer also sends an administrative message regarding the credit to the OBO service provider computer  108  via the payment system  104 . The OBO service provider computer  108  provides a suitable response/acknowledgment back through the payment system  104  to the issuer. Next the OBO service provider computer  108  validates the customer&#39;s PAN and looks up the mobile phone number or other mobile device identifier for the customer. Finally, the OBO service provider computer  108  provides a deposit notification message to the customer via SMS messaging to the customer&#39;s mobile telephone/device. 
     The system may implement an account activity alert function (mobile banking, block  706 ,  FIG. 7 ) as follows. First, the customer uses his/her payment card at a POS terminal or an ATM. The purchase transaction authorization request from the merchant or the withdrawal authorization request from the ATM proceed in a conventional manner, and the issuer debits the customer&#39;s payment card account in a conventional manner. The issuer also sends an administrative message regarding the debit to the OBO service provider computer  108  via the payment system  104 . The OBO service provider computer  108  provides a suitable response/acknowledgment back through the payment system  104  to the issuer. Next the OBO service provider computer  108  validates the customer&#39;s PAN and looks up the mobile phone number or other mobile device identifier for the customer. Finally, the OBO service provider computer  108  provides an activity alert message to the customer via SMS messaging to the customer&#39;s mobile telephone/device. 
     The system may implement a low balance alert function (mobile banking, block  706 ,  FIG. 7 ) as follows. When the issuer of the payment card account recognizes that the account balance is below a defined threshold, the issuer sends an administrative message, with transaction detail, to the OBO service provider computer  108  via the payment system  104 . The OBO service provider computer  108  provides a suitable response/acknowledgment back through the payment system  104  to the issuer. Next the OBO service provider computer  108  validates the customer&#39;s PAN and looks up the mobile phone number or other mobile device identifier for the customer. Finally, the OBO service provider computer  108  provides a low balance alert message to the customer via SMS messaging to the customer&#39;s mobile telephone/device. 
     The above depictions and descriptions of processes herein are not intended to imply a fixed order of performing the process steps. Rather, the process steps may be performed in any order that is practicable. 
     As used herein and in the appended claims, the term “transaction amount” refers to a dollar or other currency amount of a purchase transaction. 
     It should be noted that the block  108  as depicted in  FIG. 1  represents both the OBO service provider computer illustrated in  FIG. 2  and the entity which operates the computer. In some embodiments, that entity may be a payment card association (such as MasterCard International Inc., which is the assignee hereof) or a contractor retained by the payment card association. 
     Although the present invention has been described in connection with specific exemplary embodiments, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art can be made to the disclosed embodiments without departing from the spirit and scope of the invention as set forth in the appended claims.