EP2411947A1 - Systèmes et procédés pour traiter des transactions fondées sur un réseautage social - Google Patents

Systèmes et procédés pour traiter des transactions fondées sur un réseautage social

Info

Publication number
EP2411947A1
EP2411947A1 EP10756532A EP10756532A EP2411947A1 EP 2411947 A1 EP2411947 A1 EP 2411947A1 EP 10756532 A EP10756532 A EP 10756532A EP 10756532 A EP10756532 A EP 10756532A EP 2411947 A1 EP2411947 A1 EP 2411947A1
Authority
EP
European Patent Office
Prior art keywords
user
phone number
request
interchange
mobile phone
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP10756532A
Other languages
German (de)
English (en)
Other versions
EP2411947A4 (fr
Inventor
Glyn Barry Smith
Ron Hirson
Nicholas Reidy
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Boku Inc
Original Assignee
Boku Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US12/473,230 external-priority patent/US8160943B2/en
Priority claimed from US12/473,217 external-priority patent/US8224727B2/en
Application filed by Boku Inc filed Critical Boku Inc
Publication of EP2411947A1 publication Critical patent/EP2411947A1/fr
Publication of EP2411947A4 publication Critical patent/EP2411947A4/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/229—Hierarchy of users of accounts
    • G06Q20/2295—Parent-child type, e.g. where parent has control on child rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/384—Payment protocols; Details thereof using social networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation

Definitions

  • At least some embodiments of the disclosure relate to mobile communications in general and, more particularly but not limited to, mobile communications to control online transactions.
  • SMS Short Message Service
  • SMS messages are typically sent via a Short Message Service Center (SMSC) of a mobile carrier, which uses a store-and-forward mechanism to deliver the messages.
  • SMSC Short Message Service Center
  • the SMSC stores the message for later retry.
  • SMS messages can be sent via gateways.
  • Some gateways function as aggregators. An aggregator typically does not have the capacity to deliver the messages directly to the mobile phones. An aggregator typically interfaces with and relies upon the SMSC of a mobile carrier to deliver SMS messages.
  • Some gateways function as providers that are capable of sending text messages to mobile devices directly, without going through the SMSC of other mobile operators.
  • Text messaging between mobile phones can also be performed using other protocols, such as SkyMail and Short Mail in Japan.
  • Some mobile carriers provide email gateway services to allow text messages to be sent to mobile phones via email. For example, a non-subscriber of the mobile carrier may send a message to an email address associated with a mobile phone of a subscriber of the mobile carrier to have the message delivered to the mobile phone via text messaging.
  • Emails can also be sent to mobile phone devices via standard mail protocols, such as Simple Mail Transfer Protocol (SMTP) over Internet Protocol
  • SMTP Simple Mail Transfer Protocol
  • TCP Control Protocol
  • IP Internet Protocol
  • Short messages may be used to provide premium services to mobile phones, such as news alerts, ring tones, etc.
  • the premium content providers may send the messages to the SMSC of the mobile operator using a TCP/IP protocol, such as Short Message Peer-to-peer Protocol (SMPP) or Hypertext Transfer
  • SMPP Short Message Peer-to-peer Protocol
  • Protocol for delivery to a mobile phone; and the mobile phone is billed by the mobile operator for the cost of receiving the premium content.
  • Premium services may also be delivered via text messages initiated from the mobile phone.
  • a televoting service provider may obtain a short code to receive text messages from mobile phones; and when the user sends a text message to the short code, the mobile carrier routes the message to the televoting service provider and charges the user a fee, a portion of which is collected for the televoting service provider.
  • a system in one aspect, includes a data storage facility to store data associated with a first phone number; and an interchange coupled with the data storage facility.
  • the interchange includes a common format processor and a plurality of converters to interface with a plurality of controllers.
  • the converters are configured to communicate with the controllers in different formats, and communicate with the common format processor in a common format.
  • the common format processor is to receive a request from a user via a social networking website, which identifies the first phone number of the user.
  • the common format processor is to communicate with the social networking website to identify a second phone number based on data stored in a social network database coupled to the social networking website, where the social network database associates the first phone number with the second phone number based on a social network of the user.
  • the common format processor is to instruct a first controller of the controllers, via a first converter of the converters, to communicate with a mobile phone at the first phone number to confirm the request.
  • the system is to transfer funds between the user at the first phone number and a user at the second phone number according to the request.
  • a method includes: receiving at a server computer a request from a user via a social networking website, the request identifying a first phone number of the user; communicating by the server computer with the social networking website to identify a second phone number based on data stored in a social network database coupled to the social networking website; communicating by the server computer with a mobile phone at the first phone number to confirm the request; and in response to a confirmation of the request confirmed via the mobile phone at the first phone number, transferring funds between the user at the first phone number and a user at the second phone number according to the request.
  • 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.
  • Figure 1 shows a system to control online transactions according to one embodiment.
  • Figure 2 shows an interchange to route messages according to one embodiment.
  • Figure 3 shows a message processor according to one embodiment.
  • Figures 4 - 7 show methods to control an online transaction using an interchange according to a plurality of embodiments.
  • Figures 8 - 11 show interfaces to obtain information of related phone numbers according to a plurality of embodiments.
  • Figure 12 illustrates a user interface to provide advance approval according to one embodiment.
  • Figure 13 illustrates a user interface to initiate a payment transaction according to one embodiment.
  • Figure 14 illustrates a user interface to initiate a payment request according to one embodiment.
  • Figure 15 illustrates a user interface to confirm a payment request according to one embodiment.
  • Figure 16 illustrates a user interface to approve a confirmed payment request according to one embodiment.
  • Figure 17 illustrates a way to redirect a payment confirmation according to one embodiment.
  • Figure 18 illustrates a user interface to receive payment options according to one embodiment.
  • Figure 19 shows a method to control an online payment according to one embodiment.
  • Figure 20 shows another method to facilitate a payment transaction according to one embodiment.
  • Figures 21 - 23 show systems to process transactions using a social networking website according to some embodiments.
  • Figure 24 shows a method to process a transaction request received via a social networking website according to one embodiment.
  • Figure 25 shows a method to process a transaction between two users of a social networking website according to one embodiment.
  • Figure 26 shows a data processing system, which can be used in various embodiments.
  • an interchange is used to interface with a plurality of different controllers of mobile communications, such as SMS messages.
  • the interchange is coupled with a data storage facility that stores data associating two or more phone numbers of mobile devices, such as cellular phones, operated by different users.
  • the interchange allows one of the mobile devices to control the purchase requests confirmed via the other mobile devices and/or to provide funds for the approved purchase requests.
  • the interchange can be used to associate account information with phone numbers to facilitate electronic payments via the mobile devices, or to collect funds via the phone bills of the mobile devices.
  • the interchange is configured to communicate with the mobile phones through the different controllers to provide security and convenience for online transactions.
  • Figure 1 shows a system to facilitate online transactions according to one embodiment.
  • an interchange (101) is provided to interface with a plurality of different controllers (115) for communications with the mobile phones (e.g., 116, 117) over the wireless telecommunications network (105).
  • a data storage facility (107) stores user account information (121) and the corresponding phone number A (123) of the mobile phone A (116).
  • the data storage facility (107) also stores data to associate the phone number B (122) with the phone number A (123).
  • the mobile phone B (117) can be reached at the phone number B (122).
  • different telecommunication carriers provide telecommunication services to the mobile phones (116 and 117).
  • the mobile phone A (116) may be with a first telecommunication carrier in a first country; and the mobile phone B (117) may be with a second telecommunication carrier in a second country different from the first country.
  • the same telecommunication carrier may provide telecommunication services to the mobile phones (116 and 117).
  • the controllers (115) are operated by the telecommunication carriers of the mobile phones (e.g., 116, 117, etc.)
  • Figure 1 illustrates one group of mobile phones (116 and 117) that are associated with each other via the data in the data storage facility (107). However, a group may have more than two mobile phones; and the data storage facility (107) may store data to associate multiple groups of mobile phones.
  • the interchange (101) is coupled with the data storage facility (107) to communicate with the mobile phone B (117) at the corresponding phone number B (122) to confirm purchase requests and to communicate with the mobile phone A (116) at the corresponding phone number A (123) to approve the purchase request, which is to be funded by the account associated with the phone number A (123).
  • the account information (121) includes the account numbers of financial accounts with banking systems, such as bank accounts, credit card accounts, debit card accounts, and others. Since the account information (121) is secured by the interchange (101), the account information (121) can be used to pay for products and services offered by the servers (113) of various merchants, without being revealed to the merchants. [0046] In one embodiment, the server (113) offers products and/or services adapted for a virtual world environment, such as an online game environment, a virtual reality environment, etc. The products may be virtual goods, which can be delivered via the transmission of data or information (without having to physically deliver an object to the user).
  • the virtual goods may be a song, a piece of music, a video clip, an article, a computer program, a decorative item for an avatar, a piece of virtual land in a virtual world, a virtual object in a virtual reality world, etc.
  • an online game environment hosted on a server (113) may sell services and products via points or virtual currency, which may be consumed by the user while engaging in a game session.
  • a virtual reality world hosted on a server (113) may have a virtual currency, which may be used by the residents of the virtual reality world to conduct virtual commerce within the virtual reality world (e.g., buy virtual lands, virtual stocks, virtual objects, services provided in the virtual reality world, etc).
  • the server (113) may also offer physical goods, such as books, compact discs, photo prints, postcards, etc.
  • the funds for the purchase requests are collected via the phone bill of the mobile phone A (116).
  • the interchange (101) may send a set of premium messages to the mobile phone A (116) to collect the funds via the premium messages.
  • the interchange (101) may request the mobile phone A (116) to send a set of premium messages to the interchange (101) to provide the funds.
  • the interchange (101) may communicate with the telecommunication carrier of the mobile phone A (116) to charge an amount on the monthly phone bill of the mobile phone A (116), or to deduct an amount from the prepaid amount of the mobile phone A (116).
  • the interchange (101) may communicate with different controllers (115) of mobile communications via different networks (e.g., 105 and 103) and/or protocols.
  • the interchange (101) processes the requests in a common format and uses a set of converters for communications with the different controllers (115) respectively.
  • the controllers (115) may be different aggregators, providers and/or SMSCs of different mobile carriers. Based on the phone number A (123), the interchange (101) interfaces with the corresponding controllers (115) to communicate with the mobile phone B (117) via text messaging to approve and fund the purchases confirmed by the associated mobile phone B (117). In some embodiments, the user of the mobile phone A (116) may also directly confirm, approve and fund the purchases.
  • the user terminals (111) may use a unified interface to send requests to the interchange (101).
  • the user terminals (111) are typically different from the mobile phones. However, in some embodiments, users may use the mobile phone (116 or 117) to access the web and submit the account information (121).
  • a website of the interchange (101) may be used to receive the account information (121) and/or the indication of the association between the phone numbers (122 and 123) from the web browsers running in the user terminals (111).
  • the users may use the mobile phone (116 or 117) to submit the account information (121) to the interchange (101) via text messaging, email, instant messaging, etc.
  • the indication of the association between the phone numbers (122 and 123) may be received from the mobile phone (116 or 117), or from the telecommunication carrier of the mobile phone (116 or 117) (e.g., when the mobile phones share a phone bill).
  • the interchange (101) may use the phone bills of the mobile phones (116 and 117) to pay for purchases in one embodiment, use the account information (121) to pay for the phone bills, and/or deposit funds into the accounts identified by the account information (121) by charging on the phone bills of the corresponding mobile phones (116 and 117).
  • the accounts identified by the account information (121) are hosted on the data storage facility (107).
  • the accounts are hosted on the account servers (125) of financial institutions, such as banks, credit unions, credit card companies, etc.
  • the user of the mobile phone B (117) may use the user terminal (111) to access online servers (113) of various merchants or service providers to make purchases and have the purchases funded by the user of the mobile phone A (116).
  • the user of the mobile phone B (117) may confirm the purchase via the mobile phone B (117). Once the purchase request is confirmed via the mobile phone B (117), the user of the mobile phone A (116) may approve the purchase request via the mobile phone A (116). Once the purchase request is confirmed and approved, the interchange (101) may use the account information (121) to fund the purchase.
  • the user of the mobile phone A (116) when the user of the mobile phone A (116) approves the purchase, the user may choose to use the accounts identified by the account information (121) to provide the funds for the purchases, without revealing their account information (121) to the operators of the servers (113). Alternatively, the user may choose to provide the funds via the phone bill of the mobile phone A (116) (e.g., prepaid, or monthly bill).
  • the phone bill of the mobile phone A (116) e.g., prepaid, or monthly bill.
  • the user of the mobile phone B (117) may use the user terminal (111) to provide the phone number B (122) to the servers (113) and/or the interchange (101) to make a purchase.
  • the interchange (101) sends a message to the mobile phone B (117) via the phone number B (122) to confirm the purchase request.
  • the interchange (101) sends a message to the mobile phone A (116) based on the association of the phone numbers (122 and 123) in the data storage facility (107).
  • the interchange (101) charges the account identified by the account information (121) (e.g., by communicating with the account server (125) on which the corresponding accounts are hosted) and pays the server (113) on behalf of the user, using the funds obtained from the corresponding account identified by the account information (121).
  • the user terminal (111) does not have to provide the phone number B (122) to the server (113) to process the payment.
  • the server does not have to provide the phone number B (122) to the server (113) to process the payment.
  • (113) may redirect a payment request to the interchange (101), which then prompts the user terminal (111) to provide the phone number B (122) to the website of the interchange (101) to continue the payment process.
  • the server (113) may redirect the payment request to the website of the interchange (101) with a reference indicating the purchase made via the user terminal (111).
  • the interchange (101) can use the reference to subsequently complete the payment with the server (113) for the purchase, after receiving the phone number B (122) directly from the user terminal (111) to confirm the purchase via the mobile phone B (117).
  • the user may provide other information to identify the phone number B (122), such as an account identifier of the user assigned to the user for obtaining the services of the interchange
  • the account information (121) is pre-associated with the phone number A (123) prior to the payment request.
  • the account information (121) may be submitted to the interchange (101) via the user terminal
  • the user of the mobile phone A (116) may supply the account information (121) to the interchange (101) at the time of approving the payment request, after the purchase is confirmed via the mobile phone B (117).
  • the user does not have to resubmit the account information (121) in subsequent payment requests.
  • the user of the mobile phone A (116) may use a reference to the account information (121) to instruct the interchange (101) to use the account information (121) to collect the funds.
  • the system as shown in Figure 1 can increase the security of using the account information (121) in an online environment, while allowing the user of the mobile phone A (116) to control and pay for the purchases made by others, such as the user of the mobile phone B (117), without revealing the account information (121) to them.
  • the interchange (101) can also fulfill the payment requests using the funds collected via the phone bill of the phone number A (123).
  • the interchange (101) can collect the funds via sending premium messages to the mobile phone A (116) at the phone number A (123), after receiving confirmation from the mobile phone A (116).
  • the interchange (101) performs operations to collect funds via the phone bill of the phone number A (123).
  • the interchange (101) may calculate the required premium messages to bill to the mobile phone A (116).
  • mobile terminated premium SMS messages may have a predetermined set of prices for premium messages.
  • the interchange (101) determines a combination of the premium messages that has a price closest to the amount required for the purchase, and sends this combination of premium messages to the mobile phone A (116).
  • mobile originated premium SMS messages may also have a predetermined set of prices for premium messages.
  • the interchange (101) can calculate the set of messages required for the purchase and transmit a text message to the mobile phone A (116) of the user to instruct the user to send the required number of premium messages to provide the funds.
  • the user of the mobile phone A (116) can specify a set of restrictions that are applied to the purchase requests made by the users of the associated mobile phone B (117).
  • the restrictions may include the allowable frequency of the purchases, the allowable types of purchases (e.g., the type of products or services purchased), the allowable spending limit for each purchase, a budget for a predetermined period of time (e.g., a month, a week, etc.), the allowable time period during a day for purchases, etc.
  • a parent may use the restrictions to apply parental control of the purchase activities of a child.
  • the interchange (101) communicates with the mobile phone B (117) for purchase confirmation, if the purchase satisfies the restrictions.
  • the mobile phones (116 and 117) are used by the corresponding users to make payments and/or manage funds, such as for making purchases in various websites hosted on the servers (113) of merchants and service providers and/or for transfer funds to or from an account identified by the account information (121), such as phone bills of land-line phone services, credit card accounts, debit card accounts, bank accounts, etc., or an account hosted on the data storage facility (107) or telecommunication accounts of the mobile phones (116 and 117) with telecommunication carriers.
  • the mobile phones (116 and 117) are used to confirm and/or approve the transactions associated with the account identified by the account information (121) (or other accounts).
  • the interchange (101) interfaces the mobile phones (116 and 117) and the servers (113) to confirm and/or approve transactions and to operate on the account identified by the account information (121) (and/or other accounts associated with the phone numbers (122 and 123)).
  • the user of the mobile phone A (116) may provide an advance approval for one or more anticipated purchases made by the users of the mobile phone B (117).
  • the mobile phones (116 and 117) may be in different countries in different time zones; and the user of the mobile phone A (116) may not be available to provide the approval when the user of the mobile phone B (117) makes a purchase.
  • the user of the mobile phone A (116) may provide an advance approval with limitations, such as allowable amount/budget and expiration date, to avoid the delay in the approval of the purchases by the user of the mobile phone B (117).
  • a user may use a social networking website, e.g., hosted on a social networking server (127), to initiate a request to make a purchase, to transfer funds to another user, or to transfer funds from an account to another account, etc.
  • a social networking website e.g., hosted on a social networking server (127)
  • the social networking server (127) provides a service to allow users to form online communities of shared interests and/or activities.
  • the users may identify their friends among the users of the social networking website; and the social networking server (127) can identify the social networks of the users based on aggregating the friend relationships identified by the users and stored in the social network database (129) of the social networking server (127).
  • the social networking server (127) allows the users to set up and customize profile pages.
  • the profile pages can be used to describe interests and/or activities of the corresponding users, to express opinions, etc.
  • the users may have access to settings to control who sees what, and block any unwanted member.
  • the users may have blog pages or notes and individual picture albums to share information.
  • the users may see the friends of friends and invite them to become friends.
  • the users may also invite non- members of the social networking website to become members and friends in the social network.
  • the social networking server (127) is accessible from a web browser running on a device, such as user terminals (111) and the mobile phones (116 and 117).
  • the social networking server (127) provides content to the mobile phones (116 and 117) via web pages, Wireless Application Protocol (WAP) applications, text messages (e.g., sent via short message service (SMS)), and/or multimedia messages (e.g., sent via multimedia messaging service (MMS)).
  • WAP Wireless Application Protocol
  • SMS short message service
  • MMS multimedia messaging service
  • the social networking server (127) identifies the phone numbers of the users based on the social network database (129) and provides the phone numbers (122 and 123) to the interchange (101) for the transaction.
  • the interchange (101) then performs the transaction via the telecommunication carriers of the mobile phones (116 and 117) at the phone numbers (123 and 122) (e.g., via transmitting premium messages to the mobile phones), or using the account information (121) stored and associated with the phone number A (123) in the data storage facility (107) of the interchange (101) and/or the account information (not shown in Figure 1) stored and associated with the phone number B (122) in the data storage facility (107) of the interchange (101).
  • the user at the phone number A (123) may request the transferring of funds to, or from, the user at the phone number B (122).
  • the user at the phone number A (123) may purchase a virtual object from the user at the phone number B (122), such as a decorative item for an avatar, a virtual currency, points redeemable for playing a game, etc.
  • the user at the phone number A (123) may pay a fee to access contents provided by the user at the phone number B (122), such as an article, a photo image, a piece of music, a clip of video, etc.
  • the user at the phone number A (123) may purchase a physical object from the user at the phone number B (122).
  • the interchange (101) may assist the social networking server (127) in building the social network database (129).
  • the transaction may include the user at the phone number A (123) requesting the user at the phone number B (122) to accept an invitation to form a friend relationship in the social network hosted on the social networking server (127).
  • the interchange (101) transmits a message to the mobile phone B (117) at the phone number B (122) to ask the user at the mobile phone B (117) to confirm the establishment of the friend relationship with the user at the phone number A (123).
  • the interchange (101) notifies the social networking server (127) about the confirmation of the friend relationship between the users at the phone numbers (122 and 123).
  • the social networking server (127) then stores data in the social network database (129) to represent a direct connection between the user at the phone number A (123) and the user at the phone number B (122) in the social network.
  • a user at the phone number (123) may purchase an item or service from a third party which may not be a member of the social networking website (e.g., via an advertisement presented on the social networking website).
  • the social networking server (125) identifies the phone number (123) from the profile data of the user and provides the phone number (123) to the interchange (101) to process the payment.
  • the interchange (101) notifies the social networking server (127) and/or the third party (e.g., when the third party is identified in the request received via the social networking server (127)).
  • Figure 2 shows an interchange to route messages according to one embodiment.
  • the interchange (101) includes a unified data interface (135) for interaction with the servers (113).
  • the servers (113) may redirect the payment requests to the interchange (101) to allow the interchange (101) to subsequently communicate with the user to process the payment request, including obtaining payment options and identifying user accounts, before returning to communicating with the server (113).
  • the servers (113) may collect account related information (e.g., the phone number of the user) to request payment from the interchange (101).
  • the interchange (101) includes a common format processor (133), which processes various payment options in a common format.
  • the common format processor (133) can handle the payments via mobile terminated text message, mobile originated text message, operator bill, credit card, stored value account, and other online payment options.
  • the common format processor (133) determines the actual amount that is to be billed to the user, based on the payment options (e.g., mobile terminated premium SMS, mobile originated premium SMS, operator billing, credit cards, etc.), and selects a converter (131) to communicate with a corresponding controller (115).
  • Different converters (131) are configured to communicate with corresponding controllers (115) in different languages and protocols.
  • the converters (131) perform the translation between the common format used by the common format processor (133) and the corresponding formats used by the controllers (115).
  • the common format processor (133) simplifies the structure of the interchange (101) and reduces the development effort required for the interchange (101) to interface with the increasing number of different controllers, such as SMSC, mobile providers, aggregators, gateways, etc.
  • Figure 3 shows a message processor according to one embodiment.
  • the common format processor (133) includes a billing engine (157) that calculates the amount to be billed to the user, by adding or subtracting transaction costs for different billing methods, such as mobile terminated text message, mobile originated text message, operator billing, credit card, stored value account, and other online payment options.
  • the interchange (101) sends mobile terminated premium SMS messages to the mobile phone (116) to bill the user, or requests the mobile phone (116) to send mobile originated premium SMS messages to a short code representing the interchange (101).
  • the interchange (101) directly sends a message to the mobile carrier of the mobile phone (116) to bill the amount on the phone bill of the mobile phone (116), without having to send a premium message to the mobile phone (116).
  • the common format processor (133) includes a decision engine (151) which decides how to generate a set of one or more messages to the mobile phone (117) based on a set of rules (141), regulations (143), limits (145), records (147) and restrictions (149).
  • the user of the mobile phone (116) at the phone number (123) may provide account information (121) to the interchange (101) for association with the phone number (123).
  • the user may use a device running a web browser as the user terminal (111) to submit the account information (121) via a secure web connection.
  • the user terminal (111) is typically different from the mobile phone (116).
  • the mobile phone (116) may also be used as the user terminal (111) to submit the account information (121) (e.g., via a wireless application protocol (WAP) application, or via a message sent via short message service (SMS) or multimedia message service (MMS), or via an email message or an instant message).
  • WAP wireless application protocol
  • SMS short message service
  • MMS multimedia message service
  • the user of the mobile phone A (116) After the user of the mobile phone A (116) provides the account information (121) to the interchange (101) for storage in the data storage facility (107), the user of the associated mobile phone B (117) can send (177) a purchase request to the server (113) of a merchant from the user terminal (111).
  • the users of the mobile phones (116 and 117) may use the same user terminal (111) or different user terminals.
  • the server (113) of the merchant can send or redirect (179) the charge request to the interchange (101).
  • the interchange (101) sends (173) a confirmation message to the mobile phone B (117). If the user of the mobile phone B (117) sends (173) a confirmation to the interchange (101), the interchange (101) sends (174) a message to the mobile phone A (116) for approval, since the data stored in the data storage facility (107) indicates that the purchases made by the user of the mobile phone B (117) at the phone number B (122) are to be funded by the user of the mobile phone A (116) at the phone number A (123).
  • the interchange (101) communicates with the account server (125) to charge an account identified by the account information (121), without revealing the account information (121) to the server (113).
  • the interchange (101) pays the merchant on behalf of the user using the funds collected via charging the account of the user of the mobile phone A (116).
  • the interchange (101) may use its own bank account to pay the merchant operating the server (113). Thus, the financial information of the user is not revealed to the merchant.
  • the interchange (101) can notify the mobile phone B (117), the mobile phone A (116) and/or the user terminal (111).
  • the server (113) of the merchant redirects the charge request to allow the user terminal (111) to communicate with the interchange (101) to continue the payment process; and the user terminal (111) may provide (171) the phone number (122), or both the phone numbers (122 and
  • the user of the mobile phone A (116) may provide the account information (121) from the mobile phone A (116) together with the approval of the purchase request.
  • the interchange (101) communicates with the mobile phone B (117) for the confirmation of the charge request via SMS messages.
  • the confirmation communications can be sent (173) via emails, instant messages, voice message, live calls from operators, etc.
  • the interchange (101) communicates with the mobile phone A (116) for the approval of the charge request via SMS messages.
  • the approval communications can be sent (173) via emails, instant messages, voice message, live calls from operators, etc.
  • the confirmation communications may include only a one-way message from the interchange (101) to the mobile phone B (117) or from the mobile B phone (117) to the interchange (101).
  • the interchange (101) may provide a code (e.g., a one time code with an expiration time limit) to the mobile phone B (117) and the user may be required to provide the code back to the interchange (101) via the user terminal (111) to confirm the request.
  • the interchange (101) may provide the code to the user terminal (111) to request the code back from the mobile phone B (117) to confirm the request.
  • the approval communications may include only a one-way message from the interchange (101) to the mobile phone A (116) or from the mobile phone A (116) to the interchange (101).
  • the interchange (101) may provide a code (e.g., a one time code with an expiration time limit) to the mobile phone A (116) and the user may be required to provide the code back to the interchange (101) via the user terminal (111) to confirm the request.
  • the interchange (101) may provide the code to the user terminal (111) to request the code back from the mobile phone A (116) to confirm the request.
  • the interchange (101) may provide the code representing the transaction to the mobile phone B (117) and request the code back from the mobile phone (116) to confirm and approve the transaction.
  • the interchange (101) may provide the code representing the transaction to the mobile phone A (116) and request the code back from the mobile phone B (117) to confirm and approve the transaction.
  • the users of the mobile phones (117 and 116) may communicate with each other via any communication links to allow the code be reported back to the interchange (101). For example, the users of the mobile phones (116 and 117) may forward the code via SMS, emails, instant messages, voice message, or live calls, etc.
  • the user of the mobile phone B (117) may choose to fulfill the charge request via the phone bill, instead of charging the account identified by the account information (121), as illustrated in Fig. 5.
  • the interchange (101) sends (173) a confirmation code to the mobile phone B (117)
  • the user of the mobile phone B (117) provides (175) the code to the mobile phone A (116) via a notification message (e.g., via SMS, emails, instant messages, voice message, live calls, etc.).
  • the user of the mobile phone A (116) then provides (174) the confirmation code to the interchange (101) to approve the transaction.
  • the interchange (101) may request the mobile phone A (116) to send (176) a set of premium messages from the mobile phone (176) to collect the funds for the purchase request, as illustrated in Figure 6.
  • the set of premium messages includes the approval message sent from the mobile phone A (116) to the interchange (101).
  • the interchange (101) separately communicates with the mobile phone B (117) of the purchaser and the mobile phone A (116) of the approver/payer for confirmation and for approval.
  • the interchange (101) obtains the approval from the mobile phone A (116) of the approver/payer prior to obtaining confirmation from the mobile phone B (117) of the purchaser. In some embodiments, the interchange (101) obtains the confirmation from the mobile phone B (117) of the purchaser prior to obtaining the approval from the mobile phone A (116) of the approver/payer. In other embodiments, the interchange (101) sends (173 and 174) messages to both the mobile phones (116 and 117) prior to receiving replies from any of the mobile phones (116 and 117). [00106] Figure 7 illustrates an example of an advanced approval from the mobile phone A (116) of the approver/payer.
  • the data storage facility (107) stores data indicating the advance approval (178), which may include a budget limit, an expiration date, and a reference to the phone number B (122) associated with the phone number A (123) of the mobile phone A (116).
  • the interchange (101) communicates (173) with the mobile phone B (117) to confirm the request, if the request meets the limitations of the advance approval (178).
  • Figures 8 - 11 show interfaces to obtain information of related phone numbers according to a plurality of embodiments.
  • the user interface (180) (e.g., presented on the user terminal (111) or the mobile phone B (117)) prompts the user to provide the phone number B (122) in the input box (181) and to provide an indication of the age of the user in the selection box (183). If it is determined that the user is a child under an age limit, the user interface illustrated in Figure 9 is presented to require the user to provide the phone number A (123) of the parent in the entry box (185). Once the child user provides the phone number A (123) of the parent, the data storage facility (107) stores data to associate the phone number B (122) of the child with the phone number A (123) of the parent and an indication that the funds for the purchases made by the child come from the parent at the phone number A (123).
  • the data storage facility (107) stores data to associate the phone number B (122) of the child with the phone number A (123) of the parent and an indication that the funds for the purchases made by the child come from the parent at the phone number A (123).
  • the server (113) presents the user interface (180) via an online shopping cart system or a third party checkout system.
  • the server (113) presents the user interface (180) via a web widget.
  • a web widget may include a program code that is portable and executable within a web page without requiring additional compilation.
  • the web widget allows the user to interact with the user interface (180) to pay for the product and/or service without leaving the web page or refreshing the web page.
  • the interchange (101) provides the web widget to facilitate the payment processing.
  • the user interface (180) allows the user to link the phone number (123) with one or more phone numbers specified in the input box (181). If the user links the phone numbers (122 and 123) via the user interface (180) illustrated in Figure 9, the data storage facility (107) allows the user of the mobile phone B (117) at the phone number B (122) to fund purchases using the account information (121) provided via the entry box (188). The interchange (101) is then configured to communicate with the mobile phone A (116) at the phone number A (123) provided in the entry box (185) for approval of the purchases made by the user of the associated mobile phone B (117).
  • Figure 10 illustrates the example of specifying a credit card number in the entry box (188) as the account information (121).
  • the user interface (180) may allow the user to specify one or more of various other types of accounts, such as bank accounts, charge card accounts, etc.
  • the user interface (180) may further present a text field (not shown in Figure 10) to allow the user to specify an alias for the account information (121) supplied in the text input field (181).
  • the alias can be used for subsequent communications with the user to select one account from a plurality of accounts without revealing the account information (121).
  • the user interface (180) may be presented via a web browser (or a custom application) to submit account information (121) from a user terminal (111) to the interchange (101).
  • the account number can be submitted from the mobile phone (116) via a message sent via SMS,
  • WAP voice mail
  • IVR interactive voice response
  • Figure 11 illustrates the mobile phone B (117) of a child prompting the child to provide a phone number of the parent of the child.
  • the interchange (101) may prompt the child to provide the phone number A (123) of the parent.
  • the interchange (101) can communicate with the mobile phone A (116) of the parent for approval and billing.
  • the mobile phone B (117) of the child is used to prompt for the phone number of the parent, when the child registers with the interchange (101).
  • the interchange (101) provides the message to the mobile phone B (117) to confirm that the user is in possession of the mobile phone B
  • a user of the mobile phone B may also request the interchange (101) to link the phone number B (122) with the phone number A (123) of a family member, a relative, or a friend who is willing to fund some purchases made by the user.
  • the relationship between the users of the mobile phones (116 and 117) is not limited to the child and parent relationship.
  • Figure 12 illustrates a user interface to provide advance approval according to one embodiment.
  • the user of the mobile phone A (116) provides a message (194) to approve one or more future purchases requests initiated by the user of the mobile phone B (117).
  • the advance approval is in response to a request from the mobile phone B (117).
  • the interchange (101) sends a message (192) to the mobile phone A (116), in response to the request for advance approval from the mobile phone B (117).
  • the message (192) identifies the phone number B (122) of the mobile phone B (117); and the advance approval message (194) includes restrictions, such as a budget limit, an expiration limit of the advance approval, etc. Other restrictions may include the location and time of the purchase, the type of products and services to be purchased, the maximum number of purchase requests, the frequency of purchase requests, etc.
  • the user of the mobile phone A (116) at the phone number A (123) may directly send a message to interchange (101) provide the advance approval for the phone number B (122), without a corresponding incoming message from the interchange (101).
  • the users of the mobile phones (116 and 117) may communicate with each other to identify the need for the advance approval, prior to the user of the mobile phone A (116) sending the advance approval to the interchange (101).
  • Figure 13 illustrates a user interface to initiate a payment transaction according to one embodiment.
  • the user interface (201) provides an option (205) to request the interchange (101) to process the payment for the amount (203) required to make a purchase from the server (113) of a merchant.
  • the server (113) directs the request to the web server of the interchange (101), with a set of parameters to indicate the amount (203), the identity of the merchant, a reference to the purchase, etc.
  • the user does not have to provide any personal information to the server (113) of the merchant to complete the payment process.
  • the user may provide the phone number to the merchant to process the payment.
  • the user does not have to visit the website of the interchange (101) to complete the payment.
  • Figure 14 illustrates a user interface to initiate a payment request according to one embodiment, after the payment request is redirected to the website of the interchange (101).
  • the user interface (201) includes the identity of the merchant and the amount (203) of the requested payment.
  • the user interface (201) includes a text field (181) to allow the user to provide the phone number B (122) of the mobile phone B (117) to confirm the purchase request.
  • user authentication may be used to reduce false messages to the phone number (122).
  • the user interface (201) may request a personal identification number (PIN) for enhanced security.
  • PIN personal identification number
  • the user may be required to register with the interchange (101) prior to using the services of the interchange (101); and after registering with the interchange (101), the user is provided with the PIN or can created a customized PIN to access the functionality provided by the user interface (201).
  • the user interface (201) may request an identifier associated with the phone number B (122) to initiate the payment transaction.
  • the user interface (201) requires the user to provide no information other than the phone number B (122) in the text field (181) to initiate the transaction.
  • the user interface (201) provides a list of options for the user at the phone number B (122) to fund the purchases, such as credit cards or bank accounts associated with the phone number B (122), or accounts associated with the phone number A (123).
  • the user interface (201) may present the payment options after authenticating the user (e.g., via a personal identification number or password) for enhanced security.
  • the interchange (101) transmits a confirmation message to the mobile phone B (117) according to the phone number B (122) provided in the text field (181).
  • the interchange (101) transmits the confirmation to the mobile phone A (116) after the user is authenticated via the user interface (201) to reduce the possibility of unauthorized/unwelcome messages to the mobile phone A (116), which may occur when the user intentionally or unintentionally provides an unrelated phone number in the entry box (181).
  • Figure 15 illustrates a user interface to confirm a payment request according to one embodiment.
  • the confirmation message (217) from the interchange (101) includes the amount (203) of the requested payment and the identity of the payee (e.g., a merchant operating the server (113)).
  • the confirmation message (217) includes the instruction to reply with a code, such as a code (e.g., "pay") provided in the confirmation message (217) as illustrated in Figure 15.
  • the presence of the code in the reply message is an indication of the user approving the request; and the requirement for such a code in the reply eliminates false confirmations (e.g., generated via accidental replies or automated replies).
  • the requested code may include a PIN associated with the phone number B (122), and/or a code (not shown) randomly generated and presented in the user interface used to initiate the payment transaction (e.g., user interface (201)).
  • the code requested in the text message (217) may be a personal identification number (PIN) associated with the phone number A (123).
  • PIN personal identification number
  • the text message (217) does not include the code; and the knowledge of the code is an indication of the identity of the user. Thus, the use of such a code increases the security of the transaction.
  • the code requested in the text message (217) includes a code that is provided in response to the payment request (e.g., via the user interface (201), not shown in Figure 14).
  • the code may be generated randomly at the time the request is received via the user interface (201), or when the user interface (201) is presented to the user.
  • the code provided to the user interface (201) can be requested in the reply received from the user interface (190) to indicate that the user who is in possession of the mobile phone B (117) has actual knowledge about the payment request submitted via the user interface
  • the user of the mobile phone B (117) may optionally provide a message with the code to the interchange (101).
  • the interchange (101) then relays the message to the mobile phone A (116) to assist the approval decision making at the mobile phone A (116).
  • Figure 16 illustrates a user interface to approve a confirmed payment request according to one embodiment.
  • the interchange (101) sends a message (227) to the mobile phone A (116) at the phone number A (123), based on the association relationship between the phone numbers (122 and 123).
  • the message (227) requests approval of a purchase made by the user of the mobile phone B (117).
  • the interchange (101) confirms the identity of the purchaser via the communications with the mobile phone B (117), as illustrated in Figure 15.
  • the approval request message (227) requests a code, such as a PIN associated with the phone number A (123).
  • the approval request (227) may include a code provided in the message (227) and/or the code provided to the user of the mobile phone B (117) for the purchase transaction.
  • the user may provide the PIN on a web site of the interchange (101) to approve the purchase.
  • the user may log in a web site of the interchange (101) by identifying the phone number A
  • the approval request message (227) also includes a copy of the optional message to assist the user of the mobile phone A (116) in deciding whether or not to approve the purchase.
  • the user of the mobile phone A (116) may optionally provide the account information (121) to provide the funds for the purchase.
  • the interchange (101) communicates with the account server (125) to electronically charge the user of the mobile phone A (116) using the associated account information (121) and pays the payee using the funds collected via communicating with the account server (125).
  • the interchange (101) may send premium messages to the mobile phone A (116) to collect the funds via the telecommunication carrier of the mobile phone A (116), request premium messages from the mobile phone A (116), or communicate with the telecommunication carrier of the mobile phone A (116) to collect the funds via the phone bill of the mobile phone A (116).
  • the interchange (101) notifies the users when the payment transaction is complete.
  • the interchange (101) may notify the user of the mobile phone B (117) and/or the user of the mobile phone A (116) via a text message. Once the payment transaction is complete, the user would have access to the product purchased via the payment transaction.
  • the interchange (101) stores an address of the user associated with the phone number B (122). After the completion of the payment transaction, the interchange (101) provides the address to the server (113) of the merchant for the delivery of the purchased product.
  • the user of the mobile phone B (117) may provide multiple addresses associated with the phone number B (122) and may select one as a delivery address in the confirmation message to the interchange (101).
  • the interchange (101) may receive an address for product delivery from the mobile phone B (117) together with the confirmation message and then forward the address to the server (113) of the merchant.
  • the shipping address of the transaction is verified to be associated with the mobile phone B (117).
  • the user may directly provide the shipping address in the website hosted on the server (113) of the merchant.
  • the user is provided with the options to pay via the mobile phone bill associated with the phone number A (123).
  • the interchange (101) may dynamically calculate a set of premium messages, based on a set of limited number of predetermined prices for premium messages, to match the purchase price.
  • the interchange (101) sends the set of premium messages to the mobile phone A (116) at the phone number A (123) to collect the funds via the telecommunication carriers to pay for the purchases.
  • the purchase prices are not limited to the set of predetermined prices for premium messages.
  • the interchange (101) may send the set of premium messages in a period of time (e.g., a week, a month, a number of mouths, etc.) to spread the payments over the period of time (e.g., to overcome budget limits and/or limits imposed by regulations).
  • a period of time e.g., a week, a month, a number of mouths, etc.
  • Figure 17 illustrates a way to redirect a payment confirmation according to one embodiment.
  • the interchange (101) may present the user interface (201) illustrated in Figure 17 to the user.
  • the user interface (201) indicates that the request is being processed; and the user interface (201) is periodically updated to show progress.
  • the user interface (201) provides a confirmation message and may automatically redirect the user back to the website of the payee (e.g., to access the purchased products or services).
  • the confirmation and approval from the users are required within a predetermined period of time of the request. If the user fails to provide the confirmation from the mobile phone B (117), or the approval from the mobile phone A (116), within the predetermined period of time, the payment request may be rejected; and the user interface (201) may present a message indicating the failure and then redirect the user back to the website of the payee.
  • Figure 18 illustrates a user interface to receive payment options according to one embodiment.
  • the interchange (101) sends a message (227) to the mobile device (116) to provide a number of options to the user.
  • the message (227) identifies the amount (203) of the requested payment and the identity of the payee (e.g., a merchant operating the server (113)) and asks the user to approve the payment request via a reply that contains a selected payment option.
  • the user may reply with the code "1" to approve the payment request and to pay via the phone bill of the mobile device (116).
  • the user may reply with the credit card information to charge the payment to a credit card, as illustrated in Figure 18.
  • the credit card account information is stored and associated with the phone number (123) in the data storage facility (107).
  • the data storage facility (107) may store account information for each of a plurality of account types (e.g., Visa, MasterCard, checking, savings, etc.).
  • account types e.g., Visa, MasterCard, checking, savings, etc.
  • each of the accounts can be identified to the user via the account type in the confirmation message, without revealing the details of the account information.
  • the interchange (101) may combine the name of the financial institutions and the type of accounts to generate aliases for the account information.
  • the user may define the aliases for the account information by supplying the aliases with the account information (121) for association with the phone number (123).
  • Figure 19 shows a method to control an online payment according to one embodiment.
  • the interchange (101) receives (301) an indication of association between a first phone number and a second phone number.
  • the interchange (101) stores (303) data in the data storage facility (107) to associate the first phone number and the second phone number.
  • the interchange (101) After the interchange (101) receives (305) a payment request including the first phone number, the interchange (101) identifies (307) the second phone number based on the association between the first phone number and the second phone number.
  • the interchange (101) communicates with a mobile device at the first phone number to confirm (309) the request and communicates with a mobile device at the second phone number to approve (311) the request.
  • the interchange (101) collects funds from the user of the mobile device at the second phone number for the request.
  • Figure 20 shows another method to facilitate a payment transaction according to one embodiment.
  • the interchange (101) receives (331) an advance approval for a first phone number from a mobile phone at a second phone number. Subsequently, the interchange (101) receives (333) a request associated with the first phone number to pay an amount to a payee. If the interchange (101) determines (335) the request is approved by the advance approval, the interchange (101) transmits (337) a message to a mobile phone at the first phone number to confirm the request.
  • the interchange (101) pays (341) the amount to the payee on behalf of a user of the mobile phone at the first phone number and bills (343) a user of the mobile phone at the second phone number for the amount paid.
  • the interchange (101) bills the user of the mobile phone at the second phone number for an amount equal to the purchase price plus a first fee and charges the merchant a second fee.
  • the merchant may specify the second fee.
  • Different merchants may offer different percentages of the purchase prices as the second fee; and the interchange (101) may calculate the first fee based on the second fee offered by the merchant, by deducting the second fee from the total fees to be charged (e.g., the fees charged by the telecommunication carrier for collecting the funds via the mobile phone bill associated with the phone number and/or the fees charged by the interchange (101) for processing the payments). Since the first fee is charged to the customer (e.g., the payer of products and services), the cost to the customer can vary based on the selection of the merchant. For the same purchase prices, the first fee (and thus the cost to the customer) may be different for purchases made via different merchants, because the merchants may offer different percentages of the purchase price as the second fee.
  • the first fee and thus the cost to the customer
  • the first and second fees include both fees charged by the telecommunication carrier for collecting the funds via the mobile phone bill/account associated with the phone number (123) and the fees charged by the interchange (101) for processing the payments.
  • the first fee includes the fees charged by the telecommunication carrier but no fees charged by the interchange (101).
  • the second fee includes the fees charged by the telecommunication carrier but no fees charged by the interchange (101).
  • the first fee and/or the second fee do not include the fees charged by the telecommunication carrier.
  • the first fee is not charged; and in other embodiments, the second fee is not charged.
  • a social networking website is used to sell products and services, such as applications, games, access to online games, software, tokens, avatars, decoration/customization of avatars, and other virtual goods or tangible goods.
  • the products and services can be sold to the members of the social network by other members of the social network, by third parties who might not be members of the social networking website, or by the social networking website.
  • the products and services can be sold on the social networking website via advertisement, online stores, or via third party websites that allow the buyers to authenticate themselves via the social networking website for payment processing.
  • the social networking website is coupled to the interchange (101) to allow the members to pay for the purchases using mobile phones (e.g., 116).
  • the interchange (101) determines scores based on data about the members in the social network, such as social graph, distance, geographical location, interest, preference, time of activities, number of shared friends in the social network, etc.
  • the scores represent a measure of creditworthiness of the respective members (or the transactions between respective members).
  • the scores are not only specific to the members making the purchase, but also specific to the relationship between the seller and the buyer in relation to the social networking website.
  • the members of the social networking website can use their social network credentials to purchase items hosted on third party websites, such as a casual game or a massively multiplayer online (MMO) game.
  • a casual game typically has simple rules and does not require commitment from players.
  • a massively multiplayer online (MMO) game enables players to cooperate and compete with each other on a large scale over a network, such as the Internet.
  • the products or services of the third party websites may be advertised on, or hyperlinked from, the social network site, so that the login credentials of the social networking website may be used to authenticate the users on the third party websites.
  • the members of the social networking website may log in directly on the third party website, using the credentials of the respective members in the social network site.
  • the third party website may temporarily redirect the login credentials to the social networking website for verification and obtain an indication from the social networking website when the member is authenticated via the social networking website.
  • the third party website may redirect the login credentials via a background communication with the social networking website, and/or via redirecting the web page to the social networking website.
  • the interchange (101) communicates with the social networking website to authenticate the buyer via the social networking website.
  • the members of social networks can send money and/or gifts to other members and pay via their mobile phones using the interchange (101).
  • the sender and the recipient may or may not be the members of the same social networks.
  • the users may not request the transaction on the social networking websites.
  • a user may initiate the request on a web server of the interchange (101), which when determines that the user is a member of a social networking website, may forward the user to the social networking website for authentication (or communicating with the social networking website in the background to authenticate the user).
  • the interchange (101) may ask the user to identify whether the user is a member of a social networking website (e.g., to pay via presenting the credentials of the user as a member of a social networking website), and/or may check the data storage facility to association between a phone number submitted by the user to process payment and the member IDs of social networking websites.
  • Figures 21 - 23 show systems to process transactions using a social networking website according to some embodiments.
  • a user of the mobile phone A (116) at the phone number A (123) may use the user terminal (111) to visit the social networking server (127) and make a request (411) involving a user of the mobile phone B (117) at the phone number B (122).
  • the interchange (101) is configured to process the request via communicating with the social networking server (127).
  • the user terminal (111) is a device distinct and separate from the mobile phone A (116).
  • the user terminal (111) may be a personal computer, a notebook computer, a personal digital assistant (PDA), etc.
  • the user terminal (111) is combined and/or integrated with the mobile phone A (116).
  • the user terminal may be a web browser implemented on the mobile phone A (116).
  • the user terminal (111) is used to request access to the item (421) offered by the user at the phone number B (122).
  • the item (421) for example, may be a blog entry, a photo image, a clip of audio and/or video recording, a program, or a virtual object.
  • access to the item (421) may have a single price for any users who want to access the item (421), or may have a price based on the social distance (423) between the buyer at the phone number A (123) and the seller at the phone number B (122).
  • the social distance (423) is the smallest number of direct connections (e.g., friend connections) between the two users in a collection of connections stored in the social network database (129).
  • access to the item (421) is limited to users within a predetermined threshold in the social distance to the user at the phone number B (122) who offers the item (421).
  • the social networking server (127) and/or the interchange (101) accepts the transaction requests if the social distance (423) between the user at the phone number A (123) and the user at the phone number B (122) is within a predetermined threshold.
  • the request may be rejected if the social distance (423) between the user at the phone number A (123) and the user at the phone number B (122) is not within a predetermined threshold.
  • the interchange (101) confirms the request with the user at the phone number A (123) and/or the user at the phone number B (122), as a security measure, prior to performing the transaction specified by the request (411).
  • the request may specify the transferring of funds from the user of the phone number A (123) to the user at the phone number B (122) (e.g., to purchase access to the item (421), to purchase the item (421), or without a purchase transaction).
  • the interchange (101) may communicate with the mobile phone A (116) for the confirmation (417) of the request.
  • the interchange (101) may confirm the request by transmitting a message to the mobile phone A (116) to receive a reply to the message from the mobile phone A (116), or by receiving a code from the mobile phone A (116), or by receiving a code transmitted to the mobile phone A (116).
  • the request may specify the transferring of funds from the user at the phone number B (122) to the user of the phone number A (123) (e.g., to request a loan, to sell an item or access to an item, to request funds as a gift).
  • the interchange (101) may communicate with the mobile phone B (117) for the confirmation (415) of the request (e.g., in addition to the confirmation (417) with the mobile phone A (116)).
  • the interchange (101) may confirm the request by transmitting a message to the mobile phone B (117) to receive a reply to the message from the mobile phone B (117), or by receiving a code from the mobile phone B (117), or by receiving a code transmitted to the mobile phone B (117).
  • the social distance between the user at the phone number A (123) and the user at the phone number B (122) is used to select a security measure for the confirmation of the transaction.
  • the interchange (101) may perform the transaction specified by the request without sending a confirmation to the mobile phone A (116), or without waiting for a reply from the mobile phone A (116), or without waiting for a reply to the confirmation message sent to the mobile phone A (116).
  • interchange (101) may perform the transaction specified by the request without sending a confirmation to the mobile phone B (117) at the phone number B (122), or without waiting for a reply from the mobile phone B (117), or without waiting for a reply to the confirmation message sent to the mobile phone B (117).
  • the social distance between the user at the phone number A (123) and the user at the phone number B (122) and/or other social networking data can be used to determine whether a transaction is valid or permissible.
  • the user at the phone number A (123) may send a request to transfer money to the user at the phone number B (122); the interchange (101) can check the number of degrees separated, number of friends, number of friends in common, physical location stated on profile pages, years on the social network site, number of direction communications between the users in the social networking website, etc. to determine whether the transaction should be authorized.
  • the social networking data can be used as the basis to determine a degree of trustworthiness between the users of the phone numbers (122 and 123); and the degree of trustworthiness can be used to determine a level of security measure applied to the requested transaction and/or to authorize the transaction.
  • the interchange (101) transfers funds between the user at the phone number A (123) and the user at the phone number B (122) via the telecommunications carriers of the mobile phones (116 and 117).
  • the interchange (101) may charge a user by sending premium messages to the mobile phone A (116) to collect funds from the user of the mobile phone A (116), and/or to provide funds to a user by sending premium messages to the mobile phone B (117).
  • the interchange (101) determines a combination of premium messages, based on a set of predetermined prices for premium messages, to match the amount for the transaction.
  • the interchange (101) may send messages to the telecommunication carriers directly to provide funds or collect funds, without sending the messages to the mobile phones (116 and 117).
  • the interchange (101) uses the account information (425 and 121) associated with the phone numbers (122 and 123) in the data storage facility (107) of the interchange (101) to perform the transaction.
  • the interchange (101) may use the account information (425 and 121) in its communication with at least one account server (125) to deposit (419) funds and/or to charge the users.
  • the user terminal (111) may submit the request directly to the interchange (101), identifying both the phone numbers (122 and 123).
  • the interchange (101) communicates with the social networking server (127) to determine whether the social distance (423) between the user at the phone number A (123) and the user at the phone number B (122) is within a predetermined threshold.
  • the interchange (101) may allow the transferring of funds between the users within a threshold of social distance.
  • the interchange (101) may provide discounts for the transferring of funds between the users within a threshold of social distance.
  • the interchange (101) may skip a confirmation message to the mobile phone A (116) or the mobile phone B (117) when the identity of the users have been confirmed via the social networking server (127).
  • the interchange (101) obtains the list of friends from the social networking server (127) when the user registers with the interchange (101) (e.g., to provide the account information (121)).
  • the list of friends may be updated periodically, or via notifications from the social networking server (127) when new friends are added to the social network database (129).
  • the interchange (101) may limit the transferring of funds between direct friends in the social network.
  • the interchange (101) maintains the social network database (129) to improve security of transactions.
  • the interchange (101) allows a friend to pay for a purchase made by a user.
  • the user of the mobile phone A (116) may make a purchase at the social networking server (127) and request the friend at the mobile phone B (117) to pay for the purchase.
  • the social network database (129) is used to verify the friend relationship before the interchange (101) transmits a message to the mobile phone B (117) to request confirmation (415).
  • the user may use the user terminal (111) to make a request (411) to purchase an item (421) offered by a server (113) via the social networking server (127).
  • the social networking server (127) may present an advertisement for the item (421) on the social networking website hosted on the social networking server (127).
  • the social networking server (127) obtains the phone number A (123) (e.g., from the profile data of the user stored in the social network database (129)) and formulates a communication (413) to the interchange (101) to process the payment for the purchase.
  • the user does not have to explicitly provide the phone number A (123) to process the request.
  • the interchange (101) may present a confirmation message to the user terminal (111) before communicating with the mobile phone (116) to verify the identity of the user.
  • the confirmation message sent to the user terminal (111) may include the phone number A (123), an identification of the item (421) and the price of the item (421).
  • the user of the user terminal (111) has an opportunity to pay via a different phone number, if the user does not want to pay via the phone number A (123) identified from the social network database (129).
  • the interchange (101) may communicate with the mobile phone A (116) at the phone number A (123) for confirmation (417) of the request and collect the funds from the user of the mobile phone A (116) via the telecommunication carrier of the mobile phone A (116).
  • the interchange (101) may use the account information (121) associated with the phone number A (123) in the data storage facility (107) of the interchange (101) to charge (419) an account of the user via communicating with the account server (125).
  • the interchange (101) After the processing of the payment, the interchange (101) notifies the social networking server (127) and/or the server (113) to complete the purchase.
  • the item (421) is a virtual object or a service offered by the server (113) which is separate from the social networking server (127).
  • the item (421) may be a object or a service offered by the social networking server (127).
  • the item (421) represents a physical object, or a service provided in person and/or outside a computer network.
  • the interchange (101) may rely upon the social networking server (127) to authenticate the user and to eliminate the need to confirm the request (411) via the mobile phone A (116). For example, after the user uses the user terminal (111) to confirm the request to purchase the item (421) (or to purchase the access to the item (421)) via the phone number A (123) identified from the social network database (129), the interchange (101) may directly transmit the premium message (418) to the mobile phone A (116) at the phone number A (123) to collect the funds for the payment, as illustrated in Figure 23.
  • the user of the mobile phone A (116) may optionally reply to the premium message (418) to report error, abuse, or misuse, if the premium message (418) is not a result of the authorized use of the phone number A (123).
  • the interchange (101) may require the user of the social networking website to at least confirm once the association between the user and the mobile phone A (116) via communications with the mobile phone A (116). After the association is confirmed, the interchange (101) may rely upon the social networking server (127) to authenticate the user and to eliminate the need to confirm the request (411) via the mobile phone A (116).
  • the interchange (101) may determine a pattern of the transactions of the user of the social networking server (127) and match the current request (411) with the pattern.
  • the interchange (101) may skip the requirement of a confirmation via the mobile phone A (116), prior to the transmission of the premium message (418).
  • the social networking server (127) looks up the phone number A (123) of the user from the social network database (129), based on the identification of the user in the social networking website.
  • the social networking server (127) provides the phone number A (123) to the interchange (101) as an identifier of the user of the user terminal (111).
  • the social networking server (127) may identify the user to the interchange (101) using the identifier of the user in the social networking website, such as a user name of the user as known in the social networking website.
  • the interchange (101) may prompt the user to provide the phone number (123) and associate the phone number (123) with the identifier of the user in the social networking website as provided by the social networking server (127).
  • the interchange (101) can automatically identify the phone number (123) based on the association between the phone number (123) and the identifier of the user provided by the social networking server (127) (e.g., the user ID of the user in the social networking website).
  • the phone number A (123) may be associated with another phone number B (122) in the data storage facility (107) so that the purchase made via the phone number A (123) is submitted to the mobile phone B (117) at the phone number B (122) for approval and/or charged to the user of the phone number B (122) (e.g., the phone bill of a parent phone, the credit card of the parent phone).
  • Figure 24 shows a method to process a transaction request received via a social networking website according to one embodiment.
  • Figure 25 shows a method to process a transaction between two users of a social networking website according to one embodiment.
  • a request is received (451) from a first user via a social networking website hosted on the social networking server (127).
  • a first phone number (123) of the first user and a second phone number (122) of a second user of the social networking website are identified (453).
  • the request may be accepted (456) based at least on a social distance (423) between the first user and the second user.
  • the social network database (129) associates the first phone number (123) with the second phone number (122) based on a social network of the user.
  • the interchange (101) may query the social networking server (127) to determine whether the social distance (423) between the users of the first and second phone number (122 and 123) is within a threshold.
  • the social networking server (127) may forward the request to the interchange (101) after determining that the social distance (423) between the users of the first and second phone number (122 and 123) is within a threshold.
  • the amount of the funds to be processed is based on a social distance between the user at the first phone number (123) and the user at the second phone number (122).
  • the interchange (101) After accepting the request based on the social distance (423), the interchange (101) communicates (457) with at least one of a mobile phone A (116) at the first phone number (123) and a mobile phone B (117) at the second phone number (122) to confirm the request.
  • the interchange (101) communicates with both the mobile phones (116 and 117) to confirm the request.
  • the interchange (101) may skip the confirmation process and rely upon the social networking server (127) for authenticating the user.
  • the interchange (101) identifies (459) account information (121 and/or 425) associated with at least one of the first phone number (123) and the second phone number (122).
  • the interchange (101) performs (461) the transaction using at least the account information (121 and/or 425), such as the account number of a credit card, a debit card, or a bank account, or a stored value account hosted on the data storage facility (107) of the interchange (101).
  • the interchange (101) may provide funds from the user at the first phone number (123) to the user at the second phone number (122), e.g., via transmitting at least one premium message to the mobile phone A (116) to collect the funds from a telecommunication carrier of the mobile phone A (116) at the first phone number (123) and/or transmitting at least one premium message to a mobile phone B (117) at the second phone number (122) to provide the funds via a telecommunication carrier of the mobile phone B (117) at the second phone number (122).
  • the interchange (101) determines the set of premium messages based on an amount of the funds required to fulfill the request and a set of predetermined prices of premium messages.
  • the interchange (101) notifies (463) the social networking website about the completion of the transaction, such that the social networking website may release the item purchased by the first user, to provide the first user with the access to the item, etc.
  • the item may be an image, a video clip, an audio clip, an article, or a virtual object.
  • the item may be a physical object to be shipped to the user at the first phone number (123) (e.g., via an arrangement by the social networking server (127), or by a third party server (113).
  • the interchange (101) transfers funds to the user at the first phone number (123) from the user at the second phone number (122), according to the request; and the interchange (101) communicates with a mobile phone B (117) at the second phone number (122) to confirm the request. Further, the interchange (101) may reject such a request when the social distance (423) between the user at the first phone number (123) and the user at the second phone number (122) is above a predetermined threshold (e.g., not a direct friend in the social network database (129)).
  • a predetermined threshold e.g., not a direct friend in the social network database (129)
  • Figure 26 shows a data processing system, which can be used in various embodiments. While Figure 26 illustrates various components of a computer system, it is not intended to represent any particular architecture or manner of interconnecting the components. Some embodiments may use other systems that have fewer or more components than those shown in Figure 26. [00205] In one embodiment, each of the interchange (101), the data storage facility (107), the controllers (115), the mobile phones (e.g., 116, 117), the user terminals (111), the account server (125) and the servers (113) can be implemented as a data processing system, with fewer or more components, as illustrated in Figure 26.
  • the interchange (101) is a server computer system implemented using a data processing system illustrated in Figure 26, without some of the components (e.g., a display device).
  • the data processing system (401) includes an interconnect (402) (e.g., bus and system core logic), which interconnects a microprocessor(s) (403) and memory (408).
  • the microprocessor (403) is coupled to cache memory (404) in the example of Figure 26.
  • the inter-connect (402) interconnects the microprocessor(s) (403) and the memory (408) together and also interconnects them to a display controller, display device (407), and to peripheral devices such as input/output (I/O) devices (405) through an input/output controller(s) (406).
  • I/O input/output
  • Typical I/O devices include mice, keyboards, modems, network interfaces, printers, scanners, video cameras and other devices which are well known in the art.
  • the data processing system is a server system, some of the I/O devices, such as printer, scanner, mice, and/or keyboards, are optional.
  • the inter-connect (402) may include one or more buses connected to one another through various bridges, controllers and/or adapters.
  • the I/O controller (406) includes a USB (Universal Serial Bus) adapter for controlling USB peripherals, and/or an IEEE-1394 bus adapter for controlling IEEE-1394 peripherals.
  • USB Universal Serial Bus
  • IEEE-1394 IEEE-1394
  • the memory (408) may include ROM (Read Only Memory), volatile RAM (Random Access Memory), and non-volatile memory, such as hard drive, flash memory, etc.
  • ROM Read Only Memory
  • RAM Random Access Memory
  • non-volatile memory such as hard drive, flash memory, etc.
  • Volatile RAM is typically implemented as dynamic RAM (DRAM) which requires power continually in order to refresh or maintain the data in the memory.
  • Non-volatile memory is typically a magnetic hard drive, a magnetic optical drive, an optical drive (e.g., a DVD RAM), or other type of memory system which maintains data even after power is removed from the system.
  • the non-volatile memory may also be a random access memory.
  • the non-volatile memory can be a local device coupled directly to the rest of the components in the data processing system.
  • a non-volatile memory that is remote from the system such as a network storage device coupled to the data processing system through a network interface such as a modem or Ethernet interface, can also be used.
  • At least some aspects disclosed can be embodied, at least in part, in software. That is, the techniques may be carried out in a computer system or other data processing system in response to its processor, such as a microprocessor, executing sequences of instructions contained in a memory, such as ROM, volatile RAM, non-volatile memory, cache or a remote storage device.
  • processor such as a microprocessor
  • a memory such as ROM, volatile RAM, non-volatile memory, cache or a remote storage device.
  • Routines executed to implement the embodiments may be implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions referred to as "computer programs.”
  • the computer programs typically include one or more instructions set at various times in various memory and storage devices in a computer, and that, when read and executed by one or more processors in a computer, cause the computer to perform operations necessary to execute elements involving the various aspects.
  • a machine readable medium can be used to store software and data which when executed by a data processing system causes the system to perform various methods.
  • the executable software and data may be stored in various places including for example ROM, volatile RAM, non-volatile memory and/or cache. Portions of this software and/or data may be stored in any one of these storage devices.
  • the data and instructions can be obtained from centralized servers or peer to peer networks. Different portions of the data and instructions can be obtained from different centralized servers and/or peer to peer networks at different times and in different communication sessions or in a same communication session.
  • the data and instructions can be obtained in entirety prior to the execution of the applications. Alternatively, portions of the data and instructions can be obtained dynamically, just in time, when needed for execution. Thus, it is not required that the data and instructions be on a machine readable medium in entirety at a particular instance of time.
  • Examples of computer-readable media include but are not limited to recordable and non-recordable type media such as volatile and non-volatile memory devices, read only memory (ROM), random access memory (RAM), flash memory devices, floppy and other removable disks, magnetic disk storage media, optical storage media (e.g., Compact Disk Read-Only Memory (CD).
  • recordable and non-recordable type media such as volatile and non-volatile memory devices, read only memory (ROM), random access memory (RAM), flash memory devices, floppy and other removable disks, magnetic disk storage media, optical storage media (e.g., Compact Disk Read-Only Memory (CD
  • ROMS Read Only Memory
  • DVDs Digital Versatile Disks
  • the computer-readable media may store the instructions.
  • the instructions may also be embodied in digital and analog communication links for electrical, optical, acoustical or other forms of propagated signals, such as carrier waves, infrared signals, digital signals, etc.
  • a tangible machine readable medium includes any mechanism that provides (i.e., stores and/or transmits) information in a form accessible by a machine (e.g., a computer, network device, personal digital assistant, manufacturing tool, any device with a set of one or more processors, etc.).
  • a machine e.g., a computer, network device, personal digital assistant, manufacturing tool, any device with a set of one or more processors, etc.
  • hardwired circuitry may be used in combination with software instructions to implement the techniques.
  • the techniques are neither limited to any specific combination of hardware circuitry and software nor to any particular source for the instructions executed by the data processing system.
  • stages could be implemented in hardware, firmware, software or any combination thereof.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Human Resources & Organizations (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Security & Cryptography (AREA)
  • General Health & Medical Sciences (AREA)
  • Child & Adolescent Psychology (AREA)
  • Development Economics (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Health & Medical Sciences (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention porte sur des systèmes et des procédés pour vérifier et traiter des requêtes reçues par l'intermédiaire de sites Internet de réseautage social. Sous un aspect, un système comprend une installation de stockage de données pour stocker des données associées à un premier numéro de téléphone ; et un central couplé à l'installation de stockage de données. Le central comprend un processeur de format commun et une pluralité de convertisseurs pour servir d'interface avec une pluralité de contrôleurs de communication mobile. Les convertisseurs communiquent avec les contrôleurs dans différents formats et avec le processeur de format commun dans un format commun. Le processeur de format commun reçoit une requête d'un premier utilisateur par l'intermédiaire d'un site Internet de réseautage social, identifie un premier numéro de téléphone du premier utilisateur et un second numéro de téléphone d'un second utilisateur, sur la base du site Internet de réseautage social, et utilise les convertisseurs pour communiquer avec au moins l'un des téléphones mobiles aux premier et second numéros de téléphone pour confirmer et/ou approuver la requête.
EP10756532.7A 2009-03-27 2010-02-18 Systèmes et procédés pour traiter des transactions fondées sur un réseautage social Withdrawn EP2411947A4 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US16437109P 2009-03-27 2009-03-27
US12/473,230 US8160943B2 (en) 2009-03-27 2009-05-27 Systems and methods to process transactions based on social networking
US12/473,217 US8224727B2 (en) 2009-05-27 2009-05-27 Systems and methods to process transactions based on social networking
PCT/US2010/024525 WO2010110966A1 (fr) 2009-03-27 2010-02-18 Systèmes et procédés pour traiter des transactions fondées sur un réseautage social

Publications (2)

Publication Number Publication Date
EP2411947A1 true EP2411947A1 (fr) 2012-02-01
EP2411947A4 EP2411947A4 (fr) 2014-08-06

Family

ID=44991026

Family Applications (1)

Application Number Title Priority Date Filing Date
EP10756532.7A Withdrawn EP2411947A4 (fr) 2009-03-27 2010-02-18 Systèmes et procédés pour traiter des transactions fondées sur un réseautage social

Country Status (4)

Country Link
EP (1) EP2411947A4 (fr)
AU (1) AU2010229232B2 (fr)
CA (1) CA2756768A1 (fr)
WO (1) WO2010110966A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10987701B2 (en) 2016-06-28 2021-04-27 Bühler UK Limited Sorting or classifying apparatus

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9652761B2 (en) 2009-01-23 2017-05-16 Boku, Inc. Systems and methods to facilitate electronic payments
US8116730B2 (en) 2009-01-23 2012-02-14 Vidicom Limited Systems and methods to control online transactions
US20120221437A1 (en) * 2011-02-24 2012-08-30 Boku, Inc. Systems and Methods to Automate Social Networking Activities
US11531986B2 (en) * 2020-09-30 2022-12-20 Snap Inc. Cross-platform data management and integration

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070198510A1 (en) * 2006-02-03 2007-08-23 Customerforce.Com Method and system for assigning customer influence ranking scores to internet users
WO2008061151A2 (fr) * 2006-11-14 2008-05-22 Globaltel Media, Inc. Procédé et système de paiement de mobile à mobile
US20080140569A1 (en) * 2006-12-12 2008-06-12 David Brian Handel Method, System, and Apparatus for Approval of an e-Commerce Transaction, using One or More Approving Agents

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090029687A1 (en) * 2005-09-14 2009-01-29 Jorey Ramer Combining mobile and transcoded content in a mobile search result
US20090006184A1 (en) * 2006-04-25 2009-01-01 Leach Andrew K Systems and methods for demand aggregation for proposed future items
US20080288299A1 (en) * 2006-10-31 2008-11-20 Genmobi Technologies, Inc. System and method for user identity validation for online transactions
WO2009042758A2 (fr) * 2007-09-25 2009-04-02 Swipepay Mobile, Inc. Système et procédé pour l'interopérabilité de transaction financière sur de multiples réseaux mobiles

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070198510A1 (en) * 2006-02-03 2007-08-23 Customerforce.Com Method and system for assigning customer influence ranking scores to internet users
WO2008061151A2 (fr) * 2006-11-14 2008-05-22 Globaltel Media, Inc. Procédé et système de paiement de mobile à mobile
US20080140569A1 (en) * 2006-12-12 2008-06-12 David Brian Handel Method, System, and Apparatus for Approval of an e-Commerce Transaction, using One or More Approving Agents

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO2010110966A1 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10987701B2 (en) 2016-06-28 2021-04-27 Bühler UK Limited Sorting or classifying apparatus

Also Published As

Publication number Publication date
EP2411947A4 (fr) 2014-08-06
WO2010110966A1 (fr) 2010-09-30
CA2756768A1 (fr) 2010-09-30
AU2010229232A1 (en) 2011-10-13
AU2010229232B2 (en) 2014-07-10

Similar Documents

Publication Publication Date Title
US8160943B2 (en) Systems and methods to process transactions based on social networking
US8386353B2 (en) Systems and methods to process transactions based on social networking
US20180247293A1 (en) Systems and methods to provide information
US8116730B2 (en) Systems and methods to control online transactions
AU2010206987B2 (en) Systems and methods to facilitate electronic payments
US8700530B2 (en) Systems and methods to process user initiated transactions
US8548426B2 (en) Systems and methods to approve electronic payments
AU2010332132B2 (en) Systems and methods to facilitate electronic payments
AU2011209757B2 (en) Systems and methods to authenticate users
AU2010229232B2 (en) Systems and methods to process transactions based on social networking

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20110921

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
A4 Supplementary search report drawn up and despatched

Effective date: 20140703

RIC1 Information provided on ipc code assigned before grant

Ipc: G06Q 10/10 20120101AFI20140629BHEP

Ipc: G06Q 20/34 20120101ALI20140629BHEP

Ipc: G06Q 20/32 20120101ALI20140629BHEP

Ipc: G06Q 30/06 20120101ALI20140629BHEP

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20150203