Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; 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/08—Payment architectures
  • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; 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/08—Payment architectures
  • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
  • G06Q20/123—Shopping for digital content
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; 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/08—Payment architectures
  • G06Q20/16—Payments settled via telecommunication systems
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; 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
  • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; 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
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; 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

• This invention relates to a system and method for opting-in to a phone-on-file relationship for purposes of billing a consumer.
• a consumer who shops for goods or services online may often be given the option to use a selection of payment sources during checkout, such as payment by credit card, debit card, payment from an account held by an institution, or to charge for a purchase on their phone bill.
• a merchant server instructs a billing server which is aligned with a carrier server to carry out the charge.
• the billing server usually communicates with a consumer mobile phone to confirm the charge before placing the charge on the phone bill at the carrier server.
• the billing server When the billing server communicates with a consumer mobile phone the billing server often transmits a PIN code to the consumer mobile phone. The consumer then has to enter the PIN code into a user interface of the merchant server. This is a requirement by the carrier server because the carrier server usually requires to confirm the charge with the consumer mobile phone. Such a process may be arduous for many consumers who make many purchases from a particular merchant, in which case the purchase may be lost to the merchant.
• the invention provides a method of managing transactions with a billing server including executing a phone-on-file opt-in method with the billing server.
• the phone-on- file opt-in method includes receiving a first phone-on-file opt-in request at the billing server including a msisdn and a merchant supplied unique consumer identifier, confirming, with the billing server, the first phone-on-file opt-in with a consumer device and recording, with the billing server, a phone-on-file opt-in status as active if the first phone-on-file is confirmed, and executing a charge method with the billing server including receiving, at the billing server, a charge API call from a merchant server at the billing server, including at least one identifier and an amount, determining a phone-on-file opt-in status corresponding to the identifier at the billing server and transmitting a request to charge a user account to a carrier server if the phone-on-file opt-in status is active, but not if the phone-on-file opt-in
• the invention also provides a computer-readable medium having stored thereon a set of instructions which, when executed by a processor of a computer performs a method of managing transactions with a billing server including executing a phone-on-file opt-in method with the billing server.
• the phone-on-file opt-in method includes receiving a first phone-on-file opt-in request at the billing server including a msisdn and a merchant supplied unique consumer identifier, confirming, with the billing server, the first phone-on-file opt-in with a consumer device and recording, with the billing server, a phone-on-file opt-in status as active if the first phone-on-file is confirmed, and executing a charge method with the billing server including receiving, at the billing server, a charge API call from a merchant server at the billing server, including at least two identifiers and an amount; determining a phone-on- file opt-in status corresponding to the identifiers within the data structure at the billing server and transmitting a request to charge a user account to a carrier server if the phone-on- file opt-in status is active, but not if the phone-on- file opt-in status is inactive, the request including an amount corresponding to the amount received in the charge API call.
• the invention further provides a billing server including a processor, a computer- readable medium connected to the processor and a set of instructions on the computer- readable medium and executable by the processor.
• the set of instructions includes an SMS messaging module, a consumer phone-on- file opt-in management module executing a phone-on- file opt-in method including receiving a first phone-on-file opt-in request including a msisdn and a unique consumer id, confirming, with the billing server, the first phone-on-file opt-in with a consumer device and recording, with the billing server, a phone- on-file opt-in status as active if the first phone-on-file is confirmed, and a carrier billing module executing a charge method including receiving a charge API call from a merchant server, including at least two identifiers and an amount, determining a phone-on-file opt-in status corresponding to the identifier in the data structure and transmitting a request to charge a user account to a carrier server if the phone-
• the invention provides a method of managing transactions with a billing server including receiving a first phone-on-file opt-in request at the billing server including a msisdn, confirming, with the billing server, the first phone-on-file opt-in with a consumer device, recording, with the billing server, a phone-on-file opt-in status as active if the first phone-on-file is confirmed, receiving, at the billing server, a charge API call from a merchant server at the billing server, including at least one identifier and an amount, determining a phone-on-file opt-in status corresponding to the identifier at the billing server and transmitting a request to charge a user account to a carrier server if the phone-on-file opt-in status is active, without transmitting a text message with a PIN code to a consumer mobile device, the request including an amount corresponding to the amount received in the charge call.
• the invention also provides a computer-readable medium having stored thereon a set of instructions which, when executed by a processor of a computer performs a method of managing transactions with a billing server comprising receiving a first phone-on-file opt-in request at the billing server including a msisdn, confirming, with the billing server, the first phone-on-file opt-in with a consumer device, recording, with the billing server, a phone-on- file opt-in status as active if the first phone-on-file is confirmed, receiving, at the billing server, a charge API call from a merchant server at the billing server, including at least one identifier and an amount, determining a phone-on-file opt-in status corresponding to the identifier at the billing server and transmitting a request to charge a user account to a carrier server if the phone-on-file opt-in status is active, without transmitting a text message with a PIN code to a consumer mobile device, the request including an amount corresponding to the amount received in the
• the invention further provides a billing server including a processor, a computer- readable medium connected to the processor and a set of instructions on the computer- readable medium and executable by the processor.
• the set of instructions includes an SMS messaging module, a consumer phone-on-file opt-in management module executing a phone-on-file opt-in method including receiving a first phone-on-file opt-in request including a msisdn, confirming, with the billing server, the first phone-on-file opt-in with a consumer device, recording, with the billing server, a phone-on-file opt-in status as active if the first phone-on-file is confirmed, and a carrier billing module executing a charge method including receiving a charge API call from a merchant server, including at least one identifier and an amount, determining a phone-on-file opt-in status corresponding to the identifier in the data structure and transmitting a request to charge a user account to a carrier server if the phone-on-file opt-in status is active
• the invention provides a method of managing transactions with a merchant server including executing a phone-on-file opt-in method with the merchant server, including receiving a msisdn from a consumer device at the merchant server, transmitting a first phone-on-file opt-in request from the merchant server to a billing server, including the msisdn, receiving a PIN code from the consumer device, transmitting a second phone-on-file opt-in request from the merchant server to the billing server, including the PIN code, and receiving a response from the billing server at the merchant server indicating whether the PIN code is verified or invalid, and executing a charge method with the merchant server including transmitting a charge API call from the merchant server to the billing server if the PIN code is verified but not if the PIN code is invalid, the charge API call including an amount and an identifier for the billing server to determine a phone-on- file opt-in status corresponding to the identifier and receiving a chargeresult callback notification from the billing server at the
• the invention also provides a computer-readable medium having stored thereon a set of instructions which, when executed by a processor of a computer performs a method of managing transactions with a merchant server including executing a phone-on- file opt-in method with the merchant server, including receiving a msisdn from a consumer device at the merchant server, transmitting a first phone-on- file opt-in request from the merchant server to a billing server, including the msisdn, receiving a PIN code from the consumer device, transmitting a second phone-on- file opt-in request from the merchant server to the billing server, including the PIN code and receiving a response from the billing server at the merchant server indicating whether the PIN code is verified or invalid, and executing a charge method with the merchant server including transmitting a charge API call from the merchant server to the billing server if the PIN code is verified but not if the PIN code is invalid, the charge API call including an amount and an identifier for the billing server to determine a phone-on- file
• the invention further provides a merchant server including a processor, a computer-readable medium connected to the processor and a set of instructions on the computer-readable medium and executable by the processor, including a user interface transmitted to a consumer device with a msisdn field for entry of a msisdn and receivable by the processor and transmitted to a billing server in a first phone-on- file opt-in request and a PIN code field for entry of a PIN code and receivable by the processor and transmitted to the billing server in a second phone-on- file opt-in request, and a recurring billing management module executing a charge method including transmitting a charge API call from the merchant server to the billing server if the PIN code is verified but not if the PIN code is invalid, the charge API call including an amount and an identifier for the billing server to determine a phone on- file opt-in status corresponding to the identifier and receiving a chargeresult call back notification from the billing server at the merchant server indicating
• the invention provides a method of managing transactions with a merchant server including receiving a msisdn from a consumer device at the merchant server, transmitting a first phone-on- file opt-in request from the merchant server to a billing server, including the msisdn, receiving a PIN code from the consumer device, transmitting a second phone-on- file opt-in request from the merchant server to the billing server, including the PIN code and receiving a response from the billing server at the merchant server indicating whether the PIN code is verified or invalid, and if the opt-in status is verified, transmitting a charge API call from the merchant server to the billing server if the PIN code is verified but not if the PIN code is invalid, the charge API call including an amount and an identifier for the billing server to determine a phone-on- file opt-in status corresponding to the identifier and receiving a chargeresult callback notification from the billing server at the merchant server indicating whether a user account at a carrier server has been charged by the billing server
• the invention also provides a computer-readable medium having stored thereon a set of instructions which, when executed by a processor of a computer performs a method of managing transactions with a merchant server including receiving a msisdn from a consumer device at the merchant server, transmitting a first phone-on- file opt-in request from the merchant server to a billing server, including the msisdn, receiving a PIN code from the consumer device, transmitting a second phone-on- file opt-in request from the merchant server to the billing server, including the PIN code and receiving a response from the billing server at the merchant server indicating whether the PIN code is verified or invalid, and if the opt-in status is verified, transmitting a charge API call from the merchant server to the billing server if the PIN code is verified but not if the PIN code is invalid, the charge API call including an amount and an identifier for the billing server to determine a phone-on- file opt-in status corresponding to the identifier and receiving a chargeresult
• the invention further provides a merchant server including a processor, a computer-readable medium connected to the processor and a set of instructions on the computer-readable medium and executable by the processor.
• the set of instructions includes a user interface transmitted to a consumer device with a msisdn field for entry of a msisdn and receivable by the processor and transmitted to a billing server in a first phone- on-file opt-in request and a PIN code field for entry of a PIN code and receivable by the processor and transmitted to the billing server in a second phone-on- file opt-in request and a recurring billing management module executing a charge method including if the opt-in status is invalid, transmitting a charge API call from the merchant server to the billing server if the PIN code is verified but not if the PIN code is invalid, the charge API call including an amount and an identifier for the billing server to determine a phone on- file opt-in status corresponding to the identifier and receiving a chargeresult
• Figure 1 is a block diagram of a system for managing transactions, the system including a consumer mobile phone, a merchant server, a billing server and a carrier server;
• Figure 2 is an interactive diagram illustrating how the consumer mobile phone, merchant server, billing server and carrier server interact for establishing a phone-on- file opt-in and a subsequent charge;
• Figure 3 is a view of a user interface that resides on the merchant server and is transmitted to the consumer mobile phone or another consumer device where a consumer selects payment by phone;
• Figure 4 is a flow chart illustrating a charge-info method that is used by the merchant server to retrieve charge elements from the billing server, presenting a view of the user interface to the consumer mobile phone and retrieving data entered into fields corresponding to the charge elements from the consumer mobile phone;
• Figure 5A shows a view of the user interface in Figure 1 wherein a consumer is prompted to enter a phone number that is then recorded by the merchant server for purposes of making a purchase via the billing server;
• Figure 5B is a text message that is received by the consumer mobile phone from the billing server after the billing server has generated a PIN code and the PIN code is included the text message;
• Figure 5C is a view of the user interface in Figure 1 wherein the user enters the PIN code that is received in the text message of Figure 5B;
• Figure 5D is a view of the user interface in Figure 1 after the user has entered the PIN code and the transaction has been confirmed;
• Figure 5E is a message that is received by the consumer mobile phone after the transaction has been completed
• Figure 6 is a flow chart illustrating extensions, or a variation, of the charge-info method
• Figure 7 is a view of the user interface wherein a consumer can select to opt-in to a phone-on-file relationship
• Figure 8 is a view of the user interface for the consumer to enter a PIN code
• Figure 9 is a flow chart of a phone-on-file opt-in method that is used to send the text message, including the PIN code for purposes of the consumer to enter the PIN code in the view of Figure 8 during a phone-on-file opt-in request by the merchant server to the billing server;
• Figure 10 is a view of the user interface that is displayed at the consumer mobile phone to indicate that the PIN code has been validated and that the purchase is now available to the consumer account on the merchant server;
• Figure 11 shows a text message that is received by the consumer mobile phone indicating successful phone-on-file opt-in and discloses the terms of the phone-on-file relationship and provides instructions to the consumer how to cancel their phone-on-file with the merchant;
• Figure 12 shows a data structure to indicate an active/inactive phone-on-file opt-in within the billing server
• Figure 13 is a flow chart of a charge method wherein the merchant server instructs the billing serve to charge a user account at the carrier server;
• Figure 14A is a view of the interchange wherein the user selects to make a purchase
• Figure 14B is a view of the interface after the consumer makes the purchase
• Figure 14C shows a text message that is received by the consumer mobile phone when the charge to the carrier server has occurred
• Figure 15 is a flow chart showing extensions to the charge method in Figure 15;
• Figure 16 is an interactive chart showing how the consumer can cancel the phone- on-file through the interface of the merchant server
• Figure 17 is an interactive chart showing how the consumer can cancel the phone- on-file by sending a text message to the billing server;
• Figure 18 shows an example of text messages that are exchanged to cancel the phone-on- file as described with reference to Figure 17;
• Figure 19 illustrates a flow chart of the functioning of the system in its entirety
• Figure 20 is a block diagram of the consumer mobile phone illustrating
• Figure 21 is a block diagram of a machine in the form of a computer system forming part of the phone-on- file system.
• FIG. 1 of the accompanying drawings illustrates a phone-on-file based billing system 10, according to an embodiment of the invention, including a consumer mobile phone 12, a merchant server 14, a billing server 16 and a carrier server 18.
• the merchant server 14 includes a user interface 20 for a consumer using the consumer mobile phone 12 or other consumer device to purchase and manage phone-on-file opt-in, and a phone-on-file billing management module 22.
• the billing server 16 includes a consumer opt-in management module 24, a carrier billing module 26, a risk module 27 and a Short Message Service (SMS) messaging module 28.
• SMS Short Message Service
• the consumer mobile phone 12 communicates with the merchant server 14 at 30 through the user interface 20 to opt-in to an automatic charging for future purchases by storing a phone number on file (phone-on-file) and the merchant server 14 communicates with the billing server 16 at 32 with a set of data that allows the billing server 16 to communicate with the consumer mobile phone 12 for purposes of confirming phone-on-file opt-in by the consumer mobile phone 12.
• the SMS messaging module 28
• the recurring billing management module 22 initiates a charge through the carrier billing module 26.
• the carrier billing module 29 attempts to place the charge on an account corresponding to a phone number of the consumer mobile phone 12 on the carrier server 18.
• charges for additional purchases are applied for the phone-on-file opt-in and at 39 are communicated to the carrier server 18.
• the consumer mobile phone 12 can cancel the phone-on- file opt-in through the user interface 20, which results in a communication at 44 to cancel the phone-on- file opt-in and receive a corresponding text message at 46 from the SMS messaging module 28.
• the consumer mobile phone 12 can at 48 send a text message directly to the billing server 16 to cancel the phone-on- file opt-in and then receive the text message at 46 from the SMS messaging module 28.
• Figure 2 illustrates the process for the consumer mobile phone 12 to opt-in to a phone-on- file billing and charging arrangement and subsequent charging of the consumer.
• the consumer makes a selection using the user interface 20 in Figure 1 to pay using mobile payment.
• Figure 3 shows a view of the user interface 20 that is displayed to the consumer mobile phone 12 for making the selection.
• the merchant server 14 at 52 transmits a charge-info application programmable interface (API) call to the billing server 16.
• the charge-info call is submitted to a dedicated uniform response locator (URL) of the billing server 16 such as https:/gateway.billingserver.com/charge-info.
• the charge-info method is then used by the billing server 16 to obtain information regarding the elements required to charge a consumer and the required localized strings to display to a consumer. These elements are country specific and in some cases may be network specific.
• a charge-info API response transmitted at 54 contains the input elements required for each country and network.
• the charge-info API response also supplies localized strings that can be used as labels for these input fields.
• the primary text that needs to be displayed to the consumer mobile phone 12 is the terms and conditions strings for the country or network.
• the API returns a terms-and- conditions element for the country and, if required, for the network as well and are in many cases different for different countries or networks.
• the localized text for the terms and conditions is returned in ' ⁇ string>' tags. If a country or network requires that the consumer mobile phone 12 accept terms and conditions, a terms and conditions input element will be included as a checkbox.
• the charge-info API response returns information regarding all countries that the billing server 16 supports.
• the API supports an optional country parameter to filter the response to a specific country.
• Table 1 shows the charge-info request parameters that are required and Table 2 shows the charge-info response parameters.
• FIG. 4 An example of the charge-info method is illustrated in Figure 4.
• the merchant sends the charge-info request to the billing server 16.
• the billing server 16 returns an XML structure that contains all required charge elements, supported networks in each country, and the terms and conditions string to display in each country or network.
• the merchant server 14 inspects ⁇ inputs> in the XML structure to determine required elements to collect from the consumer.
• the merchant server 14 selects ⁇ string> from the XML structure for relevant labels and hints in the appropriate language.
• the merchant server 14 displays terms and conditions for the selected country.
• the user selects the network and enters their mobile number.
• the merchant server 14 inspects for network specific terms and conditions and if found, displays these to the consumer at the consumer mobile phone 12.
• the merchant server 14 sends a charge-info request to the billing server 16 for a specific country.
• the billing server 16 returns a response that contains charge elements, networks and terms and conditions for the specific country.
• Figure 5A shows a view of the user interface 20 in Figure 1 wherein a consumer is prompted to enter a phone number that is then recorded by the merchant server 14 for purposes of making a purchase via the billing server 16.
• Figure 5B illustrates a text message that is received by the consumer mobile phone 12 from the billing server 16 after the billing server 16 has generated a PIN code and the PIN code is included in the text message. The text message prompts the user to enter the PIN code into a user interface.
• Figure 5C illustrates a view of the user interface 20 in Figure 1 wherein the user enters the PIN code that is received in the text message of Figure 5B.
• the PIN code is then transmitted through the merchant server 14 to the billing server 16.
• the billing server 16 verifies the PIN code received from the merchant server 14 against the PIN code transmitted to the consumer mobile phone 12 and approves the transaction if verified.
• the billing server 16 then communicates with the carrier server 18 to charge an account at the carrier server 18.
• Figure 5D illustrates a view of the user interface 20 in Figure 1 after the user has entered the PIN code and the transaction has been confirmed.
• Figure 5E illustrates a message that is received by the consumer mobile phone 12 after the transaction has been completed. It should be noted at this point that once the consumer proceeds with the phone-on- file opt-in, that the message in Figure 5A and the view in Figure 5E will be bypassed by the merchant server 14 and the billing server 16. As such, the consumer will not be asked to enter a PIN code or to confirm a transaction. Instead, after making a purchase, the consumer will only receive the message as shown in Figure 5E.
• Figure 6 illustrates an extension (a variation) of the charge-info method.
• the merchant server 14 sends a charge-info request to the billing server 16 for a specific country.
• the billing server 16 returns a response that contains charge elements, network and terms and conditions for the specific country.
• the merchant server 14 After the merchant server 14 receives the data from the consumer mobile phone 12 at 62 in Figures 2 and 4, the merchant server 14 at 72 in Figure 2 transmits a first phone-on- file opt-in API call to the billing server 16.
• the first phone-on- file opt-in API call is submitted to a dedicated URL of the billing server 16 such as https://gateway.billing server.com/opt-in.
• a phone-on-file opt-in method is then used by the merchant server 14 and the billing server 16 to obtain a phone-on-file opt-in from a consumer mobile phone 12 to share a phone number on file and automatically bill against the phone number without confirmation from the consumer mobile phone 12.
• the phone-on-file opt-in method is used to obtain a phone-on-file opt-in from a consumer to place their phone-on- file for a specific set of terms with a merchant (e.g., $100 or 90 days of spend). For example, when a merchant offers a phone-on-file opt-in, this method is used to obtain a consumer phone-on-file opt-in that confirms their approval for the phone-on-file and requires that the merchant provide the following:
• the risk module 27 in Figure l that is used to evaluate a set of risk rules to determine the validity of a phone-on-file opt-in including:
• Figure 7 illustrates a view of the user interface 20 after the consumer has completed a transaction, wherein the consumer is asked to opt-in to a phone-in- file relationship by selecting a check box. The consumer can also mouse over "details" and receive terms and conditions as indicated at the bottom of Figure 5D. The consumer opts in to a phone-on-file relationship and limits the purchases for that opt-in for up to $100 or 90 days of spend.
• the billing server 16 generates a unique PIN code and transmits the PIN code in a text message to the consumer mobile phone 12 at 76 in Figure 2, the user interface 20 in Figure 1 displays a PIN code field to the consumer mobile phone 12 as further illustrated in Figure 8.
• the consumer at the consumer mobile phone 12 enters the PIN code received in the text message of Figure 7 into the PIN code field and transmits it to the merchant server 14.
• the merchant server 14 receives the PIN code from the consumer mobile phone 12 and at 80 in Figure 2 transmits the retrieved PIN code, along with the msisdn and the consumer-id, in a second phone-on- file opt-in request to the same URL as the first phone-on- file opt-in request at the billing server 16.
• the billing server 16 then verifies and validates the PIN code received from the merchant server 14 at 80 against the PIN code transmitted in the text message at 74, and sends a response back to the merchant server 14.
• the billing server 16 and the merchant server 14 each record or store the result of the consumer's phone-on- file opt-in so that it can be referenced on subsequent charge API calls that occur when the user makes subsequent purchases.
• Table 3 shows the phone-on- file opt-in request parameters that are transmitted at 72 and 80 in Figure 2.
• Tables 4 and 5 show phone-on-file opt-in response parameters that are determined by the billing server 16 and provided to the merchant server 14 in response to the calls at 72 and 80 in Figure 2.
• MCC and MNC are used together.
• MNC Mobile Network Code
• network String Billing server network code as Conditional supplied from the 'charge-info'.
• FIG. 9 An example of the phone-on-file opt-in method is illustrated in Figure 9.
• the merchant server 14 sends a phone-on- file opt-in request containing the msisdn, consumer-id, network and country values.
• VERIFICATION IN PROGRESS if there is a current, unexpired PIN code that has not been verified, then VERIFICATION IN PROGRESS is returned. Otherwise, a new PIN code is generated and VERIFICATION IN PROGRESS is returned.
• the billing server 16 at 74 in Figure 2 sends a message to the consumer mobile phone 12 that is appropriate for the country and that includes the PIN code, the phone-on- file relationship (e.g. $100 or 30 days approval).
• the merchant server 14 collects the PIN code transmitted at 78 in Figure 2, and at 80 in Figure 2, sends a phone-on- file opt-in request containing the retrieved PIN code. If the submitted PIN code is correct, then VERIFIED is returned and the billing server 16 sends a confirmation message to the consumer mobile phone 12 that includes the terms of the phone-on- file opt-in, the purchase, and STOP instructions (to cancel the subscription via SMS). Otherwise, INVALID PIN is returned. Only three PIN code entry attempts (or other limited number of attempts) are allowed.
• the merchant server 14 collects a PIN code after 24 hours and sends a phone-on- file opt-in request containing the PIN. If PIN code is expired, then PIN EXPIRED is returned.
• Figure 10 is a view of the user interface 20 in Figure 2 that is displayed to the consumer mobile phone 12 to indicate that the PIN code has been transmitted and has been verified and that the phone-on- file opt-in is now available to the consumer account on the merchant server 14.
• Figure 11 shows a text message that the SMS messaging module 28 transmits to the consumer mobile phone 12 at 90 in Figure 2 indicating successful processing of opt-in for the phone-on- file opt-in and discloses the terms of the phone-on-file opt-in and provides instructions to the consumer how to cancel their phone-on-file opt-in.
• the text message in Figure 11 is not sent if the phone-on-file opt-in fails due to the PIN code not being verified.
• the method described in steps 72 to 90 using PIN code verification is one way of confirming a phone-on-file opt-in with a consumer device and then recording the phone-on- file status as active (or not active).
• Another way may for example, include the use of a mobile device handshake, such as sending an SMS text message to the mobile device then waiting for a consumer to reply "Y" for "Yes" in a reply text message.
• a payment panel may be hosted by a merchant server through which a billing server can communicate with a user device to confirm the opt-in request.
• Figure 12 shows a data structure within the consumer opt-in management module 24 in Figure 1.
• the data structure maintains a phone-on-file opt-in status per merchant-id, msisdn, and consumer- id.
• a consumer is effectively identified through the combination of msisdn and consumer- id.
• children may use the phone number of their parent as the msisdn to bill.
• each child and the parent will have their own unique consumer-id with a given merchant.
• the data structure maintains the status of the opt-in along with the date and time of the last status change.
• the date and time are used to evaluate whether the phone-on-file status has expired at the time of a consumer purchase.
• the data structure also maintains data on cumulative spend by the consumer. This is used to determine if the phone-on-file opt-in has expired by exceeding a defined spend threshold.
• the data on cumulative spend on a phone-on- file may also be included in the purchase receipt sent to the consumer.
• the merchant server 14 at 98 transmits a charge API call to the billing server 16 to request processing of a payment from the consumer mobile phone 12 in a single step.
• the charge API call is submitted to a dedicated URL of the billing server 16.
• a charge method can be used to support a one-time charge scenario.
• the merchant-id, msisdn and consumer- id values that are received in the charge API call enable the billing server 16 to check whether there is a corresponding consumer phone-on-file opt-in for with a status that is active. If the opt-in status is active, the billing server 16 proceeds to step 100. If the opt-in status is inactive, the billing server 16 again executes the steps as described with reference to Figures 5A to 5E wherein a PIN code verification is carried out.
• a charge-id is returned from the billing server 16 to the merchant server 14 at 104 in Figure 2.
• Acceptance means that the request has been successfully validated and has been submitted at 100 in Figure 2 to the carrier server 18 for processing with a valid response from the carrier server 18 at 102.
• risk checks Prior to submitting a charge to the carrier server 18 for processing, risk checks would have already been performed by the billing server 16.
• Charge is an asynchronous request.
• the billing server 16 having received the charge result from the carrier server 18, sends a callback notification to the merchant server 14 with the final result of the charge attempt.
• the charge request is idempotent. Each request is uniquely identified by the request-id supplied by the merchant server 14. For example, if two charge requests are made with the same merchant request-id, the user's account is charged only once and both charge requests receive the same response.
• a chargeresult callback notification provides the final status of a transaction (success or failure). Callback notifications are used by the merchant server 14 to fulfill purchases. For a given transaction, identified by the unique charge-id field value, fulfillment occurs only once.
• the merchant server 14 may receive a chargeresult callback for the same transaction multiple times if there are communication issues between the billing server 16 and the merchant server 14. Improper acknowledgement responses (ACKs) from the merchant server 14 to the billing server 16 are a common cause of continually retried callback notifications.
• ACKs Improper acknowledgement responses
• the merchant server 14 only receives callbacks from the billing server 16 for requests that have been accepted. If a request was not accepted due to a validation error or due to a risk check, the billing server 16 does not submit the request to the carrier server 18 for processing and therefore callback notification is not sent from the billing server 16 to the merchant server 14.
• Table 9 shows parameters for the charge request at 98 in Figure 2.
• Table 10 shows parameters for the charge request response at 104 in Figure 2.
• end-merchant-id String Billing server assigned Conditional (if merchant identifier for reseller) an end merchant
• Figure 13 shows an example of a charge method.
• a consumer at a consumer mobile phone 12 or other consumer device has a previously registered phone-on- file with phone-on- file opt-in API method.
• the consumer at a consumer mobile phone 12 or other consumer device returns to the merchant server 14 and selects a service or product.
• the merchant server 14 submits a charge request to the billing server 16 containing the customer- id, msisdn, network and purchase details.
• the billing server 16 performs phone-on- file limits, spend limit, velocity checks, and other consumer protection checks. If phone-on- file limits fail, the consumer, at 114, is asked to renew his phone-on- file opt-in for his phone-on- file.
• the charge request fails at 116 and an appropriate error message is returned.
• the billing server 16 detects the carrier (using supplied network or a lookup if the network is not supplied) and submits a charge request to renew the carrier.
• the billing server 16 returns the final result of the charge request in a chargeresult callback notification to the merchant server 14.
• the SMS messaging module 28 then at 120 in Figure 2 transmits a text message to the consumer mobile phone 12 to confirm the purchase.
• the charge is processed without communicating with the consumer mobile phone 12 as at 74 in Figure 2. If the opt-in status is inactive, however, then the billing server 16 proceeds as described at 74 in Figure 2 to send a text message containing a new PIN code to the consumer mobile phone 12 and the steps up to step 90 in Figure 2 are repeated.
• Figure 14A is a view of the interchange wherein the user selects to make a purchase.
• Figure 14B is a view of the interface after the consumer makes the purchase
• Figure 15 shows extensions to the charge flow method in Figure 13. The assumption is that at 122 the charge request fails.
• the merchant server 14 retries charge submitting the charge request with a new request-id. Due to idempotency, if the charge is retried with a request-id that failed earlier, the billing server 16 will return the same failure response.
• the billing server 16 uses the carrier charge method to charge the consumer's account.
• the billing server 16 returns information indicating the success or failure of the charge request in a chargeresult callback notification.
• Tables 11 and 12 show parameters for a chargeresult callback notification.
• request-id String 50 Unique merchant supplied identifier for this request to ensure that charges are not duplicated.
• test Boolean Boolean Used to identify test transactions.
• anti- fraud limits may result in a
• billing server system e.g. minors.
• Figure 16 shows the method referenced with respect to Figure 1 wherein the consumer mobile phone 12 cancels the phone-on-file opt-in via the user interface 20.
• the consumer mobile phone 12 cancels with the merchant server 14 using the user interface 20 in Figure 1 of the merchant server 14.
• the merchant server 14 submits a cancel-phone-on-file opt-in API call at a dedicated URL of the billing server 16 to notify the billing server 16 to cancel the phone-on- file opt-in corresponding to the merchant- id, msisdn, and consumer- id.
• the billing server 16 cancels the consumer phone-on- file opt-in and updates the relevant opt-in entry in Figure 12 as inactive.
• Figure 17 shows the method referenced with respect to Figure 1 wherein the consumer cancels the phone-on-file opt-in via text messaging.
• the consumer mobile phone 12 sends STOP via SMS text.
• the text message can be sent as a reply to the short code 723-53 from which the texts were received by the consumer mobile phone 12.
• the billing server 16 cancels the phone-on-file opt-in and updates the relevant opt-in entry in Figure 12 as inactive. Further charges against this merchant-id, msisdn, and consumer- id, if submitted by the merchant server 14, will be confirmed via text message with the consumer mobile phone 12.
• the billing server 16 sends a confirmation of cancellation SMS text to the consumer mobile phone 12.
• the billing server 16 sends a consumer phone-on- file opt-in cancelation notification to the merchant server 14 so that the phone-on-file relationship is cancelled at the merchant server 14.
• Figure 18 shows an example of text messages that are exchanged to cancel the phone-on- file opt-in as described with reference to Figure 17.
• the text messages received and sent at 48 and 46 in Figure 19 are both shown as the second and third messages in Figure 20.
• Figure 19 illustrates how the procedures hereinbefore described are repeated.
• the first purchase is completed with PIN code verification.
• a phone-on- file opt-in procedure is carried out.
• a subsequent purchase is initiated, but not completed.
• a determination is made whether there is a phone-on- file opt-in.
• the purchase is completed without PIN code verification. If there is a subsequent purchase, the subsequent purchase is initiated at 204.
• the invention further provides a method for the consumer to renew their phone-on- file opt-in and for merchants to remind consumers of phone-on-file opt-ins that need renewal.
• the consumer may renew their phone-on-file with the steps outlined herein.
• SMS-only interaction Another option for the consumer to renew their phone-on-file is via an SMS-only interaction, in which a consumer may renew their phone-on-file with a reply to an SMS sent by the system.
• the SMS may be sent during a purchase transaction, or at some point determined by a merchant or carrier (for example, as a reminder one-week prior to phone- on-file expiration).
• a merchant server may communicate with the billing server to obtain data on phone-on-file opt-ins that will need renewal based on spend or time limits. This enables a merchant to send notifications in advance of an expiration to prompt consumers to renew their phone-on- file opt-in.
• a merchant may also be given the ability to check when an opt-in will expire, e.g. within 10 days, or with a particular amount of additional spending.
• Figure 20 is a block diagram illustrating the consumer mobile phone 12, illustrating a touch-sensitive display 1120 or a "touch screen" for convenience.
• the consumer mobile phone 12 includes a memory 1020 (which may include one or more computer readable storage mediums), a memory controller 1220, one or more processing units (CPU's) 1200, a peripherals interface 1180, RF circuitry 1080, audio circuitry 1100, a speaker 1110, a microphone 1130, an input/output (I/O) subsystem 1060, other input or control devices 1160 and an external port 1240. These components communicate over one or more
• FIG. 20 The various components shown in Figure 20 may be implemented in hardware, software or a combination of hardware and software, including one or more signal processing and/or application specific integrated circuits.
• the memory 1020 may include high-speed random access memory and may also include non- volatile memory, such as one or more magnetic disk storage devices, flash memory devices, or other non-volatile solid-state memory devices. Access to the memory 1020 by other components of the consumer mobile phone 12, such as the CPU 1200 and the peripherals interface 1180, is controlled by the memory controller 1220.
• the peripherals interface 1180 connects the input and output peripherals of the device to the CPU 1200 and memory 1020.
• the one or more processors 1200 run or execute various software programs and/or sets of instructions stored in the memory 1020 to perform various functions for the consumer mobile phone 12 and to process data.
• the RF (radio frequency) circuitry 1080 receives and sends RF signals, also called electromagnetic signals.
• the RF circuitry 1080 converts electrical signals to/from electromagnetic signals and communicates with communications networks and other communications devices via the electromagnetic signals.
• the RF circuitry 1080 includes well-known circuitry for performing these functions, including an antenna system, an RF transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a CODEC chipset, a subscriber identity module (SIM) card, memory, and so forth.
• SIM subscriber identity module
• the RF circuitry 1080 may communicate with networks, such as the Internet, also referred to as the World Wide Web (WWW), an intranet and/or a wireless network, such as a cellular telephone network, a wireless local area network (LAN) and/or a metropolitan area network (MAN), and other devices by wireless communication.
• networks such as the Internet, also referred to as the World Wide Web (WWW), an intranet and/or a wireless network, such as a cellular telephone network, a wireless local area network (LAN) and/or a metropolitan area network (MAN), and other devices by wireless communication.
• the wireless communication may use any of a plurality of communications standards, protocols and technologies that are known in the art.
• the audio circuitry 1100, the speaker 1110, and the microphone 1130 provide an audio interface between a user and the consumer mobile phone 12.
• the audio circuitry 1100 receives audio data from the peripherals interface 1180, converts the audio data to an electrical signal, and transmits the electrical signal to the speaker 1110.
• the speaker 1110 converts the electrical signal to human-audible sound waves.
• the audio circuitry 1100 also receives electrical signals converted by the microphone 1130 from sound waves.
• the audio circuitry 1100 converts the electrical signal to audio data and transmits the audio data to the peripherals interface 1180 for processing.
• the audio circuitry 1100 also includes a headset jack serving as an interface between the audio circuitry 1100 and removable audio input/output peripherals, such as output-only headphones or a headset with both output (e.g., a headphone for one or both ears) and input (e.g., a microphone).
• a headset jack serving as an interface between the audio circuitry 1100 and removable audio input/output peripherals, such as output-only headphones or a headset with both output (e.g., a headphone for one or both ears) and input (e.g., a microphone).
• the I/O subsystem 1060 connects input/output peripherals on the consumer mobile phone 12, such as the touch screen 1120 and other input/control devices 1160, to the peripherals interface 1180.
• the I/O subsystem 1060 includes a display controller 1560 and one or more input controllers 1600 for other input or control devices.
• the one or more input controllers 1600 receive/send electrical signals from/to other input or control devices 1160.
• the other input/control devices 1160 may include physical buttons (e.g., push buttons, rocker buttons, etc.), dials, slider switches, joysticks, click wheels, and so forth all serving as forming part of an interface.
• the input controllers 1600 may be connected to any of the following: a keyboard, infrared port, USB port, and a pointer device such as a mouse.
• the one or more buttons may include an up/down button for volume control of the speaker 1110 and/or the microphone 1130.
• the one or more buttons may include a push button. A quick press of the push button may disengage a lock of the touch screen 1120 or begin a process that uses gestures on the touch screen to unlock the device. A longer press of the push button may turn power to the consumer mobile phone 12 on or off.
• the touch screen 1120 is used to implement virtual or soft buttons and one or more soft keyboards.
• the touch-sensitive touch screen 1120 provides an input interface and an output interface between the device and a user.
• the display controller 1560 receives and/or sends electrical signals from/to the touch screen 1120.
• the touch screen 1120 displays visual output to the user.
• the visual output may include graphics, text, icons, video, and any combination thereof (collectively termed "graphics"). In some embodiments, some or all of the visual output may correspond to user-interface objects, further details of which are described below.
• a touch screen 1120 has a touch-sensitive surface, sensor or set of sensors that accepts input from the user based on haptic and/or tactile contact.
• the touch screen 1120 and the display controller 1560 (along with any associated modules and/or sets of instructions in memory 1020) detect contact (and any movement or breaking of the contact) on the touch screen 1120 and converts the detected contact into interaction with user- interface objects (e.g., one or more soft keys, icons, web pages or images) that are displayed on the touch screen.
• user- interface objects e.g., one or more soft keys, icons, web pages or images
• a point of contact between a touch screen 1120 and the user corresponds to a finger of the user.
• the touch screen 1120 may use LCD (liquid crystal display) technology, or LPD (light emitting polymer display) technology, although other display technologies may be used in other embodiments.
• the touch screen 1120 and the display controller 1560 may detect contact and any movement or breaking thereof using any of a plurality of touch sensing technologies now known or later developed, including but not limited to capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with a touch screen 1120.
• the user may make contact with the touch screen 1120 using any suitable object or appendage, such as a stylus, a finger, and so forth.
• the user interface is designed to work primarily with finger-based contacts and gestures, which are much less precise than stylus-based input due to the larger area of contact of a finger on the touch screen.
• the device translates the rough finger-based input into a precise pointer/cursor position or command for performing the actions desired by the user.
• the consumer mobile phone 12 also includes a power system 1620 for powering the various components.
• the power system 1620 may include a power management system, one or more power sources (e.g., battery, alternating current (AC)), a recharging system, a power failure detection circuit, a power converter or inverter, a power status indicator (e.g., a light-emitting diode (LED)) and any other components associated with the generation, management and distribution of power in portable devices.
• a power management system e.g., one or more power sources (e.g., battery, alternating current (AC)), a recharging system, a power failure detection circuit, a power converter or inverter, a power status indicator (e.g., a light-emitting diode (LED)) and any other components associated with the generation, management and distribution of power in portable devices.
• power sources e.g., battery, alternating current (AC)
• AC alternating current
• the software components stored in memory 1020 include an operating system 1260, a communication module (or set of instructions) 1280, a contact/motion module (or set of instructions) 1300, a graphics module (or set of instructions) 1320, a text input module (or set of instructions) 1340, and applications (or set of instructions) 1360.
• the operating system 1260 (e.g., Darwin, RTXC, LINUX, UNIX, OS X, WINDOWS, or an embedded operating system such as VxWorks) includes various software components and/or drivers for controlling and managing general system tasks (e.g., memory management, storage device control, power management, etc.) and facilitates
• the communication module 1280 facilitates communication with other devices over one or more external ports 1240 and also includes various software components for handling data received by the RF circuitry 1080 and/or the external port 1240.
• the external port 1240 e.g., Universal Serial Bus (USB), FIREWIRE, etc.
• USB Universal Serial Bus
• FIREWIRE FireWire
• the external port 1240 is adapted for coupling directly to other devices or indirectly over a network (e.g., the Internet, wireless LAN, etc.).
• the contact/motion module 1300 may detect contact with the touch screen 1120 (in conjunction with the display controller 1560) and other touch sensitive devices (e.g., a touchpad or physical click wheel).
• the contact/motion module 1300 includes various software components for performing various operations related to detection of contact, such as determining if contact has occurred, determining if there is movement of the contact and tracking the movement across the touch screen 1120, and determining if the contact has been broken (i.e., if the contact has ceased). Determining movement of the point of contact may include determining speed (magnitude), velocity (magnitude and direction), and/or an acceleration (a change in magnitude and/or direction) of the point of contact. These operations may be applied to single contacts (e.g., one finger contacts) or to multiple simultaneous contacts (e.g., "multitouch'Vmultiple finger contacts).
• the contact/motion module 1300 and the display controller 1560 also detects contact on a touchpad.
• the graphics module 1320 includes various known software components for rendering and displaying graphics on the touch screen 1120, including components for changing the intensity of graphics that are displayed.
• graphics includes any object that can be displayed to a user, including text, web pages, icons (such as user-interface objects including soft keys), digital images, videos, animations and the like.
• the text input module 1340 which may be a component of graphics module 1320, provides soft keyboards for entering text in various applications (e.g., contacts, e-mail, IM, blogging, browser, and any other application that needs text input).
• the applications 1360 may include the mobile application 208.
• Figure 21 shows a diagrammatic representation of a machine in the exemplary form of a computer system 900 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.
• the machine operates as a standalone device or may be connected (e.g., networked) to other machines.
• the machine may operate in the capacity of a server or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.
• the machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.
• PC personal computer
• PDA Personal Digital Assistant
• STB set-top box
• WPA Personal Digital Assistant
• the exemplary computer system 900 includes a processor 930 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory 932 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), and a static memory 934 (e.g., flash memory, static random access memory (SRAM, etc.), which communicate with each other via a bus 936.
• a processor 930 e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both
• main memory 932 e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.
• DRAM dynamic random access memory
• SDRAM synchronous DRAM
• RDRAM Rambus DRAM
• static memory 934 e.g., flash memory
• the computer system 900 may further include a video display 938 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)).
• the computer system 900 also includes an alpha-numeric input device 940 (e.g., a keyboard), a cursor control device 942 (e.g., a mouse), a disk drive unit 944, a signal generation device 946 (e.g., a speaker), and a network interface device 948.
• a video display 938 e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)
• the computer system 900 also includes an alpha-numeric input device 940 (e.g., a keyboard), a cursor control device 942 (e.g., a mouse), a disk drive unit 944, a signal generation device 946 (e.g., a speaker), and a network interface device 948.
• the disk drive unit 944 includes a machine-readable medium 950 on which is stored one or more sets of instructions 952 (e.g., software) embodying any one or more of the methodologies or functions described herein.
• the software may also reside, completely or at least partially, within the main memory 932 and/or within the processor 930 during execution thereof by the computer system 900, the memory 932 and the processor 930 also constituting machine readable media.
• the software may further be transmitted or received over a network 954 via the network interface device 948.
• machine-readable medium should be taken to understand a single medium or multiple media (e.g., a centralized or distributed database or data source and/or associated caches and servers) that store the one or more sets of instructions.
• the term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention.
• the term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories and optical and magnetic media.

Landscapes

• Business, Economics & Management (AREA)
• Accounting & Taxation (AREA)
• Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• Strategic Management (AREA)
• Theoretical Computer Science (AREA)
• Finance (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Telephonic Communication Services (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)
• Meter Arrangements (AREA)

Priority Applications (2)

Applications Claiming Priority (8)

Publications (2)

Family

ID=52142839

Family Applications (1)

Country Status (3)

Cited By (1)

Family Cites Families (16)

• 2014
  • 2014-06-26 EP EP14818355.1A patent/EP3014557A4/en not_active Withdrawn
  • 2014-06-26 JP JP2016524215A patent/JP6400698B2/ja active Active
  • 2014-06-26 WO PCT/US2014/044432 patent/WO2014210375A2/en not_active Ceased
• 2018
  • 2018-09-05 JP JP2018165765A patent/JP6907168B2/ja active Active
  • 2018-09-05 JP JP2018165766A patent/JP6772228B2/ja active Active

Also Published As

Similar Documents

Legal Events