Patent Publication Number: US-8117124-B2

Title: Transferring funds electronically

Description:
RELATED APPLICATIONS 
     The present application claims priority to United Kingdom Patent Application Number 08 09 386.6, filed on May 23, 2008 and entitled “Transferring Funds Electronically,” the disclosure of which is incorporated herein by reference. 
     FIELD OF THE TECHNOLOGY 
     At least some embodiments of the disclosure relate to apparatuses for transferring funds electronically from a customer to a supplier. 
     BACKGROUND 
     Systems for ordering products and/or services over the Internet and then making payment via the Internet are known. Many of these conventional systems involve identifying credit or debit card numbers such that funds may be obtained from a bank in a manner substantially similar to conventional credit card transactions. 
     A system for instructing payment to be made via mobile telephone text messages is described in United States patent application publication No. 2007/0203836 A1, published Aug. 30, 2007. This provides an alternative method of payment that may be considered more secure than entering credit card details into a networked computer system, but it has a disadvantage in that it requires a set up procedure in order for the method to be deployed. 
     An alternative approach is described in United States patent application publication number 2009/0006217 A1, published Jan. 1, 2009, which was filed Jun. 29, 2007 and assigned U.S. patent application Ser. No. 11/824,607. This process has been successfully deployed and is trading under the service mark “MOBILLCASH.” The MOBILLCASH system allows an order to be placed over the Internet and for funds to be transferred by transmitting a plurality of premium rate mobile terminating text messages to a mobile telephone held by the customer. Thus, by this method, a customer is only required to enter their telephone number, resulting in a charge being made to their mobile telephone account, from which it is then possible for funds to be transferred to the supplier. 
     A problem with relying upon the mobile telephone network to make payments is that the service provider and the seller are not actually aware of the person to whom the sale is being made. In order to achieve the transaction, it is only necessary to be aware of the actual telephone number. From a seller&#39;s perspective, advantages may be gained from knowing the identity of the purchaser, given that it is then possible to produce statistics identifying the type of customers to whom sales are being made, so that marketing activities may become more targeted. 
     SUMMARY OF THE DESCRIPTION 
     Apparatuses and methods to transfer funds electronically via premium messages are described herein. Some embodiments are summarized in this section. 
     In one aspect, there is provided a system for the electronic transfer of funds from a customer to a supplier, including: a customer browser component connected to a network; a supplier browser component connected to the network; a server component connected to the network and having a database component; a mobile cellular telephone with a telephone number operable by the customer; a mobile cellular operator providing mobile cellular services to the mobile cellular telephone; wherein: the server is configured to transmit a plurality of premium rate mobile terminating text messages to the mobile cellular telephone to effect a payment from the customer to the supplier after the customer has placed an order with the supplier; the server component is configured to populate the database with an identification of each customer&#39;s telephone number; the server component is configured to prompt customers to supply additional personal data; and upon receiving additional personal data, the server component is configured to populate the database with the additional personal data. 
     In a preferred embodiment, the server component is configured to prompt customers to supply additional personal data by issuing an additional text message. 
     In a second aspect, there is provided a method of transferring funds electronically, including: transmitting a plurality of premium rate mobile terminating text messages from a server to a mobile cellular telephone to effect payment from the customer to a supplier after the customer has placed an order with the supplier via a network connected browser; populating a database at the server with an identification of each customer&#39;s telephone number; prompting customers to supply additional personal data; and upon receiving the additional personal data, populating the database with the additional personal data. 
     The disclosure includes methods and apparatuses which perform these methods, including data processing systems which perform these methods, and computer readable media containing instructions which when executed on data processing systems cause the systems to perform these methods. 
     Other features will be apparent from the accompanying drawings and from the detailed description which follows. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements. 
         FIG. 1  shows a representation of the Internet. 
         FIG. 2  shows components forming a preferred embodiment working within the environment of  FIG. 1  conducted within the environment of  FIG. 2 . 
         FIG. 3  shows procedures conducted within the environment of  FIG. 2 . 
         FIG. 4  shows an example of a browser. 
         FIG. 5  details the visual display unit identified in  FIG. 4 . 
         FIG. 6  details graphical user interfaces displayed by the visual display unit identified in  FIG. 5 . 
         FIG. 7  shows procedures implemented by a service server. 
         FIG. 8  details procedures for confirming a payment identified in  FIG. 7 . 
         FIG. 9  details procedures for the allocation of messages identified in  FIG. 7 . 
         FIG. 10  shows an example of a constraints file of the type identified in  FIG. 9 . 
         FIG. 11  shows various use types. 
         FIG. 12  shows an environment substantially similar to that of  FIG. 2 , implementing one embodiment. 
         FIG. 13  shows an example of an invitation of the type identified in  FIG. 12 . 
         FIG. 14  shows a graphical user interface for receiving information. 
         FIG. 15  shows a database table for recording information. 
         FIG. 16  shows the generation of a report. 
     
    
    
     DETAILED DESCRIPTION 
     The following description and drawings are illustrative and are not to be construed as limiting. Numerous specific details are described to provide a thorough understanding. However, in certain instances, well known or conventional details are not described in order to avoid obscuring the description. References to one or an embodiment in the present disclosure are not necessarily references to the same embodiment; and, such references mean at least one. 
     A representation of the Internet  101  is illustrated in  FIG. 1  in which potential customers are provided with customer browsers  101  to  108  and a plurality of suppliers are provided with supplier browsers  111  to  115 . The environment therefore allows customers to place orders with suppliers for the delivery of products and/or services and for the customers to transfer funds to the suppliers in order to effect payment for the goods and/or services. 
     It is known practice for a transaction to be initiated by a customer, such as customer  102 , by the customer making a request for a web page to be served, which provides details of a supplier&#39;s products, allows product selections to be made and facilitates payment for these products. 
       FIG. 2  shows components forming a preferred embodiment working within the environment of  FIG. 1  conducted within the environment of  FIG. 2 . 
     Within the environment identified in  FIG. 1 , a preferred aspect of one embodiment provides an apparatus for the electronic transfer of funds from a customer to a supplier as illustrated in  FIG. 2 . A customer browser component  102  is connected to the Internet  101  and a supplier server component  111  is also connected to the Internet. A service server component  201  is connected to the Internet  101  and a mobile cellular telephone  202  is operable by the customer, that is to say, the same customer who is using browser  102 . 
     A mobile cellular operator  203  provides mobile cellular services to the mobile cellular telephone  202 . The service server component  201  is configured to transmit a plurality of premium rate mobile terminating text messages  204  to the mobile cellular telephone to effect a payment from the customer (at  102 ) to the supplier (at  111 ) after the customer has placed an order with the supplier. 
     The mobile terminating premium rate messages are included in telephone bills received by the mobile telephone owner, resulting in payment  210  being made to the mobile operator  203 . Thereafter, the mobile operator  203  effects the appropriate transfer  211  to the supplier  111 . The supplier  111  has now received funds and is therefore prompted to perform delivery  212  of the purchased product or service. 
     Procedures conducted within the environment of  FIG. 2  are detailed in  FIG. 3 , in the form of a telecommunications protocol diagram. The diagram of  FIG. 3  includes the browser  102 , the cellular telephone  202 , the supplier server  111  and the service server  201 . 
     Initially, the browser issues a signal  301  to request a page to be supplied from the supplier server  111 . In response to receiving this request, a page of data  302  is returned to the browser  102 , resulting in a page being displayed to the customer at the browser  102 . 
     In response to reviewing the served page, a request  303  for an order is conveyed to the supplier server  111 . In response to receiving this order, the product server  111  makes an invitation  304  for a payment to be made. In response to receiving an invitation for a payment to be made, the browser makes an instruction  305  in order to effect the payment. Thus, in accordance with one embodiment, payment is made by issuing premium rate text messages to the mobile telephone. 
     The supplier server  111  issues an instruction  306  to the service server  201 . The service server  201  issues a request  307  to the mobile cellular telephone  202  for a confirmation to the effect that the payment is to be made. Thus, in order to achieve payment by the mobile telephone mechanism, it is necessary to enter a telephone number and it is also necessary for the purchaser to be in possession of the mobile telephone so that the purchaser may effect that confirmation. 
     The mobile cellular telephone therefore issues a confirmation  308  back to the service server  201  (via the cellular telephone network) to the effect that the purchase has been confirmed. 
     Upon receiving the request confirmation  308 , the service server schedules and issues a plurality of premium rate mobile terminating text messages  309 . Thereafter, the product, virtual product or service is sent from the supplier to the purchaser, as illustrated by arrow  310 . 
     An example of a browser  201  is illustrated in  FIG. 4 , in which a visual display unit  401  is provided to allow web pages to be displayed. In addition, user input is facilitated by a keyboard  402  and a mouse  403 . The applicant has become aware that browser environments are particularly attractive for displaying catalogues of goods and receiving orders for goods. However, problems arise in terms of effecting payment over the Internet due to security concerns. The mobile telephone system described herein thereby provides an alternative mechanism for payment. 
     Generally, the relationship between customers and mobile providers is a strong relationship built on mutual trust. Within the Internet environment it is unlikely for this level of trust to exist. Furthermore, it is not necessary for the user to have access to a credit card or to even possess a credit card. Furthermore, it has been found that the browser environment is not very successful when a supplier requests information back from a user. The present preferred embodiment allows information to be returned to suppliers easily via the customer&#39;s mobile cellular telephone. 
     In the example shown in  FIG. 4 , the browser takes the form of a desktop computer but equally it could take the form of a laptop computer or similar device. It is also envisaged that the browser and mobile telephone text messaging services could be constrained within a unified product, such as a high level mobile device. 
       FIG. 5  details the visual display unit  401  identified in  FIG. 4 . The visual display unit  401  in  FIG. 5  shows an image relevant for initiating the process of making a payment. Display  501  includes a field  502  in which the current price is displayed. The user is then prompted to identify a means of payment, which in this example shows a credit card link  503 , a debit card link  504  and the mobile telephone account link  505 . In practice, many of these links may be repeated for different credit card types, for example, and often each credit card link would include its associated logo or graphical representation, etc. 
       FIG. 6  details graphical user interfaces displayed by the visual display unit identified in  FIG. 5 . 
     Having clicked through on link  505  (as shown in  FIG. 5 ) screen  601  is displayed, that also includes a field  602  identifying the required payment. Having clicked through for this type of payment, it is possible that the total payment figure may have increased so as to include an additional charge for effecting payment via the mobile cellular telephone network. Thus, assuming a user wishes to continue, the user is invited to enter their cellular telephone number in a field  603  and the user may be asked to confirm this number in a further field  604 . After confirming the payment, a further screen  605  may be displayed, subject to the particular implementation of the application. 
     Screen  605  includes a field  606  again identifying the total payment. The screen then continues to say that this amount will be deducted from the telephone account and a user is invited to accept the transaction by clicking button  607  or declining the transaction by clicking cancel button  608 . 
     Procedures implemented by the service server  201  are identified in  FIG. 7 . The service server provides for the operating of a payment via the Internet in which details are received, of a transaction, from a product server  111  identifying a price to be paid by the customer. Details of the customer&#39;s mobile telephone are received at the service server and thereafter a plurality of premium rate text messages are transmitted to the mobile telephone to effect that payment. 
     In response to receiving instructions  306 , the service server  201  seeks confirmation from the mobile cellular telephone in operation  701  to the effect that payment is to be made. 
     Upon receiving confirmation  308 , messages are allocated in operation  702 , and in operation  703  the premium rate messages are transmitted with confirmation to the supplier being provided in operation  704 . 
       FIG. 8  details procedures for confirming a payment identified in  FIG. 7 . 
     The result of procedure  701  for confirming the payment is illustrated in  FIG. 8 , in which the mobile cellular telephone  202  receives a message displayed on the mobile telephone display  801 . In this example, the message states “please confirm your payment of,” and the amount to be paid is displayed in field  802 . In this example, it is possible to confirm the payment by operating the central navigation button  803 . Alternatively, the transaction may be cancelled by the operation of a cancel button  804 . 
     The confirmation of the payment creates a mobile originating message. This message may incur a modest charge for transmission over the mobile network. In this example, a dedicated mobile telephone is shown. However it should be appreciated that the mobile telephone designation also includes other devices with mobile telephony functionality. 
       FIG. 9  details procedures for the allocation of messages identified in  FIG. 7 . 
     Procedure  702  for the allocation of messages is illustrated in  FIG. 9 . In operation  901  a file  902  of data is read that identifies appropriate local constraints for the transaction. Alternatively, these details may be supplied from an appropriately configured database. The local constraints are relevant for the particular country in which the financial transaction is taking place, including appropriate currency for the transaction and other regulations relating to the use of premium rate messages. 
     The constraints contained within file  902  identify the specific examples of premium rate messages that may be deployed, along with a level of payment that is associated with each of these messages. In addition, the constraints also specify maximum transaction values, usually restricting the total level of transactions that may occur during a day and often also identifying a maximum level of transactions that may take place over a month, given that many customers are billed on a monthly basis. 
     In this example, an operator may specify that total transactions for a day must not exceed 30 dollars and total transactions for the month must not exceed 400 dollars. Typically, these constraints are applied across an operator&#39;s network and are not allocated on a customer-by-customer basis. 
     In operation  903  the total value of the transaction is divided into a plurality of messages such that in combination, the value of the messages adds up to the total value of the transaction. 
     In operation  904  an allocation is made over a number of months. If the total value of the transaction exceeds a monthly limit, it is necessary to spread the transmission of the messages over two or more months. 
     In operation  905  an allocation is made over a number of days. Again, if either total transactions or monthly transactions exceed the total transactions allowed, the actual transmissions must take place over a number of days, with a plurality of messages being allocated for each individual day within the batch. 
     It is possible for the maximum transmissions to occur within, for example, three days over a particular month. It is possible that the transactions could occur over more days, until the allocation for the month is reached. If the allocation for the month is reached, it is then necessary to continue making transmissions upon entering the next month. 
     In operation  906  the transmissions are scheduled, resulting in the generation of a transmission schedule  907 . 
       FIG. 10  shows an example of a constraints file  902  of the type identified in  FIG. 9 . This defines a total transmission value for the day and a total transmission value for the month. In addition, it identifies valid premium rate message codes. Thus, in this example, at line  1001  a code 861000 effects a charge of 50 cents, as shown at line  1002 . Similarly, a code of 861100 effects a charge of 1 dollar and as illustrated at line  1003 , a charge of 1.50 dollars is effected as a result of transmitting code 861110. A code of 861111 results in a charge of 3 dollars and similarly a five dollar charge results from the transmission of code 861112. An example of a displayed field  802  is also shown in  FIG. 10  which, for the purposes of this illustration, indicates a charge of 25.50 dollars. 
       FIG. 11  shows various use types. 
     The present preferred apparatus performs a method of transferring funds electronically in which a plurality of premium rate mobile text messages are transmitted from the server to a mobile cellular telephone to effect payment from the customer to the supplier after the customer has placed an order with a supplier via a network connected browser. A database is populated at the server with an identification of each customer&#39;s telephone number. It is then possible for customers to make purchases via this mechanism in a nonregistered mode of operation. However, in accordance with a preferred aspect of one embodiment, the customer is prompted to supply additional personal data. Thus, as illustrated in  FIG. 11 , nonregistered use of the system is illustrated at  1101 . After this nonregistered use, a question is asked at  1102  of a customer as to whether they wish to register their use of the system. Thus, when answered in the negative, further nonregistered use may occur at  1101 . 
     If, however, the customer agrees to the registration process (the question asked in operation  1102  being answered in the affirmative), a registration process is performed in operation  1103 . 
     Thereafter, registered use occurs in operation  1104 , and thereafter in operation  1105 , transaction information may be transferred to suppliers and third parties. 
       FIG. 12  shows an environment substantially similar to that of  FIG. 2 , implementing one embodiment. Multiple premium rate mobile terminating text messages  204  are shown being issued from the server  201  to the mobile cellular telephone  202 . However, in addition, the user also receives an invitation  215  to supply additional personal information. 
       FIG. 13  shows an example of an invitation  215  of the type identified in  FIG. 12 . In the example of an invitation  215  to a browser illustrated in  FIG. 13 , the browser receives a message  1301  which states “would you like to receive a discount?” In response to receiving this, it is possible for the user to press a cancel button  1302 . Alternatively, pressing an “OK” button  1303  results in an affirmative response being returned to the server  201 . 
       FIG. 14  shows a graphical user interface for receiving information. In a preferred embodiment, personal information is received from the user via the user&#39;s browser  102 . 
     When the user makes use of browser  102  to effect payment via this method again, the user is presented with a screen of the type shown in  FIG. 14 . At the browser, the user selects fields within the graphical user interface using mouse  403  and enters the text by keyboard  402 . The user then applies a mouse click to the “send” link  1401 . 
     In this example, a first name is received at field  1402  and a family name is received at field  1403 . These are text boxes allowing any text entry to be made. Further fields  1404  to  1407  are provided in the form of pull down boxes from which predefined selections can be made. Thus, in field  1404  the user is invited to identify their gender and at field  1405  they are invited to identify their city of residence. Similarly, pull down box  1406  invites the user to identify a favorite entertainment and a similar pull down box at  1407  allows a favorite hobby to be identified within the field. As previously stated, the user then selects link  1401  and the information is transmitted over channel  215  to the database  208  within server  201 . 
       FIG. 15  shows a database table for recording information. Within database  208  a table is created so as to record the information received from each user. At column  1501  a unique identification is given for the user which is then recorded against the user&#39;s telephone number at column  1502 . For nonregistered use, only columns  1501  and  1502  are populated. Alternatively, it would be possible for telephone numbers to be recorded in a separate linked table. 
     Columns  1503  to  1508  only become populated after a registration process. Thus, a given name and a family name are recorded at columns  1503  and  1504  respectively in response to receiving free text entries  1402  and  1403 . 
     Gender is recorded at  1505  (from entry  1404 ), with city, entertainment and hobbies being recorded at  1506 ,  1507  and  1508 , in response to entries from  1405 ,  1406  and  1407 . 
       FIG. 16  shows the generation of a report. It is envisaged that personal data will be collected over a period of time and a plurality of tables may be included within a database of substantially similar configuration to that shown in  FIG. 15 . Registered users are identified as such, and in a preferred embodiment the user is provided with a discount each time the service is used. As previously described with respect to  FIG. 10 , the possibility of providing an additional charges for the service was described, and in a preferred embodiment this charge may be made against nonregistered users whereas registered users may be able to make use of the service for free. 
     Similarly, suppliers, such as supplier  111 , may be in a position to make use of the service effectively for free, but a charge may be required if they wish to obtain user transaction data, essentially for marketing purposes. In a preferred embodiment, it is possible for a supplier to receive transaction data relating to the specific transactions made with them. Alternatively, average data may be of greater assistance such that specific telephone numbers are not required, whereupon it will be possible to provide a broader range of data, including data obtained from transactions relating to other suppliers. 
     Furthermore, in an alternative preferred embodiment, given that the personal nature of the data has been removed, it would be possible for this accumulated data to be made available to external parties not actually themselves registered as a supplier. Furthermore, the availability of this data may encourage suppliers to make this service available to their customers. 
     In a first embodiment it is possible for suppliers to gain access to database  208 . Alternatively, it may be possible for the suppliers to receive designated reports, such as report  1601  of the type shown in  FIG. 16 . 
     In the example shown in  FIG. 16 , a supplier is interested in advertising entertainment packages and therefore wishes to know which type of entertainments are preferred by their existing customers. Thus, by referring to the information collected within column  1507 , for a number of users, it is possible to perform calculations to determine percentages. Thus, in this example, the supplier receives information to the effect that 40% of their users prefer playing computer games, compared to the other options of watching movies, watching plays, watching sports or watching comedy. Thus, with this information on hand, the supplier may make an educated decision to the effect that further website promotions would best be directed at computer games in preference to DVDs and movie downloads, etc. 
     In the foregoing specification, the disclosure has been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.