JP6400698B2 - Registration phone - Google Patents

Description

[Cross-reference with related applications]
This application is filed on U.S. Patent Application No. 13 / 927,574, filed June 26, 2013, U.S. Patent Application No. 13 / 927,982, filed June 26, 2013, June 2013. Claims the priority of U.S. Patent Application No. 13 / 928,016 filed on the 26th and U.S. Patent Application No. 13 / 928,046 filed on June 26, 2013. Each of the patent applications is incorporated herein by reference in its entirety.

  The present invention relates to a system and method for opt-in to a registered telephone relationship to charge a consumer.

  If a consumer purchases goods or services online, use payment source choices such as credit card, debit card payments, payments from group-owned accounts at checkout, or purchase on phone bill You may be given the option to charge. When the consumer chooses to charge his / her telephone bill, the retail store server instructs the billing server associated with the carrier server to charge. Usually, the billing server communicates with the consumer mobile phone to confirm billing before billing the telephone bill at the carrier server.

  The billing server often transmits a PIN code to the consumer mobile phone when communicating with the consumer mobile phone. At this time, the consumer must enter a PIN code into the user interface of the retail store server. Usually, this is a necessary condition for the carrier server because the carrier server needs to confirm the billing to the consumer mobile phone. Such a process may be difficult for many consumers who make many purchases from a particular retail store, in which case purchases to this retail store may not be made.

  The present invention provides a transaction management method using a billing server, which includes performing a registered telephone opt-in method using the billing server. The registered telephone opt-in method includes receiving at a billing server a first registered telephone opt-in request that includes msdisdn and a unique consumer identifier provided by a retail store, and using the billing server to communicate with a consumer device. Confirming the first registered telephone opt-in and, if the first registered telephone is confirmed, using the billing server, recording the registered telephone opt-in status as active, the transaction management method comprising: The billing method further includes performing a billing method using the billing server, the billing method receiving at the billing server a billing API call including at least one identifier and an amount from the retail store server; The step of determining the corresponding registered phone opt-in status and the money received in the billing API call A billing request for a user account including an amount corresponding to is sent to the carrier server when the registered phone opt-in status is active, and not sent when the registered phone opt-in status is inactive. Including.

  The present invention also provides a computer readable medium storing a set of instructions for executing a transaction management method using a billing server when executed by a processor of the computer, the transaction management method using a billing server and registering telephone opt-in method The step of performing is included. The registered telephone opt-in method includes receiving at a billing server a first registered telephone opt-in request that includes msdisdn and a unique consumer identifier provided by a retail store, and using the billing server to communicate with a consumer device. Confirming the first registered telephone opt-in and, if the first registered telephone is confirmed, using the billing server, recording the registered telephone opt-in status as active, the transaction management method comprising: The method further includes performing a billing method using the billing server, the billing method receiving at the billing server a billing API call including at least two identifiers and an amount from the retail store server; Determining a registered telephone opt-in state corresponding to the identifier in the billing API call; Send a billing request for a user account that includes an amount corresponding to the amount received to the carrier server when the registered phone opt-in status is active, and not when the registered phone opt-in status is inactive Steps.

  The present invention further provides a billing server including a processor, a computer readable medium coupled to the processor, and an instruction set on the computer readable medium executable by the processor. The instruction set includes an SMS messaging module and a consumer registration phone opt-in management module that performs a registration phone opt-in method, wherein the registration phone opt-in method includes a first registration phone opt-in request that includes msdisdn and a unique consumer ID. A first registration telephone opt-in with the consumer device using the billing server, and a registration telephone opt-in using the billing server if the first registered telephone is confirmed. And the instruction set further includes a carrier billing module that executes a billing method, the billing method including a billing API call including at least two identifiers and an amount from the retail store server. The receiving step and the registered telephone opt-in corresponding to the identifier in the data structure And when the registration telephone opt-in state is active, a request for charging a user account including an amount corresponding to the amount received by the charging API call is transmitted to the carrier server and registered telephone opt-in. And not transmitting if the state is inactive.

  The present invention further provides a transaction management method using a billing server, wherein the transaction management method receives a first registered telephone opt-in request including msdisdn at the billing server, and uses the billing server to A first registration phone opt-in with the device; if a first registration phone is confirmed, a billing server is used to record the registered phone opt-in status as active; Receiving a billing API call including at least one identifier and amount from the retail server, determining a registered telephone opt-in state corresponding to the identifier at the billing server, and if the registered telephone opt-in state is active, PIN Without sending a text message containing the code to the consumer mobile device And transmitting the charging request to the user account, including the amount corresponding to the amount of money received in the billing call your wireless service provider server.

  The present invention also provides a computer readable medium storing an instruction set for executing a transaction management method using a billing server when executed by a processor of the computer, the transaction management method including a first message including msdisdn in the billing server. Receiving a registered telephone opt-in request, using a billing server to confirm the first registered telephone opt-in with the consumer device, and if the first registered telephone is confirmed, using the billing server Recording a registered telephone opt-in state as active, receiving at the billing server a billing API call including at least one identifier and amount from the retail server, and at the billing server, registering telephone opt-in corresponding to the identifier The step of determining the status and the registered telephone opt-in status is And if so, sending a billing request to the user account that includes the amount corresponding to the amount received in the billing call without sending a text message containing the PIN code to the consumer mobile device; and including.

  The present invention further provides a billing server including a processor, a computer readable medium coupled to the processor, and an instruction set on the computer readable medium executable by the processor. The instruction set includes an SMS messaging module and a consumer registration telephone opt-in management module that performs a registration telephone opt-in method, the registration telephone opt-in method receiving a first registration telephone opt-in request including msdisdn, and a billing server And confirming the first registered telephone opt-in with the consumer device and, if the first registered telephone is confirmed, using the billing server to record the registered telephone opt-in status as active. And the instruction set further includes a carrier billing module for performing the billing method, the billing method receiving a billing API call including at least one identifier and the amount from the retail store server; and in the data structure Determining a registered telephone opt-in status corresponding to the identifier of If the registered phone opt-in status is active, the carrier will issue a billing request to the user account that includes the amount corresponding to the amount received in the billing call without sending a text message containing the PIN code to the consumer mobile device. Sending to the server.

  The present invention provides a transaction management method using a retail store server, the transaction management method including executing a registered telephone opt-in method using the retail store server, wherein the registered telephone opt-in method is performed at the retail store server. Receiving msisdn from the consumer device; sending a first registered telephone opt-in request including msdisdn from the retail store server to the billing server; receiving a PIN code from the consumer device; and second including a PIN code. Registering the registered telephone opt-in request from the retail server to the billing server and receiving a response from the billing server at the retail server indicating whether the PIN code has been verified or invalid. Further includes executing a billing method using the retail server. The billing method sends a billing API call including the amount and an identifier for the billing server to determine the corresponding registered phone opt-in status from the retail server to the billing server if the PIN code is verified, and the PIN Not transmitting if the code is invalid, and receiving at the retail store server a billing result callback notification from the billing server indicating whether the billing server has charged the user account at the carrier server. .

  The present invention also provides a computer readable medium storing a set of instructions for executing a transaction management method using a retail store server when executed by a computer processor, the transaction management method using the retail store server. Performing a opt-in method, wherein the registered telephone opt-in method receives the msisdn from the consumer device at the retail store server and sends a first registered telephone opt-in request including the msisdn from the retail store server to the billing server. Receiving a PIN code from the consumer device; sending a second registration telephone opt-in request including the PIN code from the retail server to the billing server; and verifying whether the PIN code is verified at the retail server, or Response from billing server indicating invalidity And the method further comprises performing a billing method using the retail store server, the billing method including an amount and an identifier for the billing server to determine the corresponding registered phone opt-in status. A billing API call that includes: a PIN code verified from the retail store server to the billing server and no PIN code invalid, and at the retail store server the user at the carrier server Receiving a billing result callback notification from the billing server indicating whether the account has been billed by the billing server.

  The present invention further provides a retail store server comprising a processor, a computer readable medium coupled to the processor, and an instruction set on the computer readable medium executable by the processor, the instruction set received by the processor. A msisdn field for entering msdisdn, which is sent to the billing server in a first registered phone opt-in request, and a processor can receive and sent to the billing server in a second registered phone opt-in request; A user interface that is transmitted to the consumer device including a PIN code field for entering a PIN code, and a recurring billing management module that executes the billing method, the billing method comprising the amount and the corresponding registered telephone opt-in Billing including identifier for billing server to determine status A PI call is sent from the retail server to the billing server if the PIN code is verified, and not sent if the PIN code is invalid, and at the retail server, the user account at the carrier server is billed. Receiving from the billing server a billing result callback notification indicating whether billing has been performed by the server.

  The present invention provides a transaction management method using a retail store server, wherein the transaction management method receives a msdisdn from a consumer device at the retail store server and sends a first registered telephone opt-in request including msdisdn to the retail store. At the retail store server, transmitting from the server to the billing server; receiving a PIN code from the consumer device; transmitting a second registration telephone opt-in request including the PIN code from the retail store server to the billing server; Receiving from the billing server a response indicating whether the PIN code has been verified or invalid, and if the opt-in status is verified, an amount and an identifier for the billing server to determine the corresponding registered phone opt-in status; A billing API call that includes a retail store if the PIN code is verified And a billing result callback indicating whether or not the billing server has charged the user account in the carrier server at the retail store server, and a step of not transmitting if the PIN code is invalid. Receiving a notification from the billing server; if the opt-in state is invalid, using the retail store server to send a call including the phone number and the billing amount to the billing server; using the retail store server; Sending an interface including the PIN field to the consumer device; receiving at the retail server a PIN code entered by the user in the PIN code field; and using the retail server to pass the PIN code to the billing server. Sending and using the retail server And a step of receiving the billing has been confirmation from billing server.

  The present invention also provides a computer readable medium storing an instruction set for executing a transaction management method using a retail store server when executed by a processor of the computer, the transaction management method from a consumer device at the retail store server. receiving msidn, transmitting a first registration telephone opt-in request including msidn from the retail store server to the billing server, receiving a PIN code from the consumer device, and a second registration telephone opt-in including the PIN code. Sending a request from the retail server to the billing server; receiving a response from the billing server indicating whether the PIN code is verified or invalid at the retail server; and if the opt-in state is verified, Check the amount and the corresponding registered phone opt-in status A billing API call including an identifier for the server to determine from the retail server when the PIN code is verified to the billing server and not when the PIN code is invalid; Receiving a billing result callback notification from the billing server indicating whether the billing server has been billed for the user account at the carrier server, and if the opt-in state is invalid, using the retail store server, Transmitting a call including a telephone number and a billing amount to a billing server; using the retail store server to transmit an interface including a PIN field to the consumer device; and at the retail store server, a PIN code field by the user Receiving a PIN code entered in With retail server, and transmitting the PIN code to the billing server, using the retail server, and receiving a confirmation of amount of money is charged from the billing server.

  The present invention further provides a retail store server that includes a processor, a computer readable medium coupled to the processor, and an instruction set on the computer readable medium executable by the processor. The instruction set can be received by the processor and sent to the billing server in a first registration telephone opt-in request, an msisdn field for entering msdisdn, and the processor can receive a second registration telephone opt-in request. A user interface transmitted to the consumer device, including a PIN code field for entering a PIN code, transmitted to the billing server, and a continuous billing management module for executing the billing method, If the opt-in status is invalid, a billing API call including the amount and an identifier for the billing server to determine the corresponding registered telephone opt-in status is sent from the retail store server to the billing server if the PIN code is verified. And if the PIN code is invalid, do not send In the server, a step of receiving from the billing server a billing result callback notification indicating whether or not the billing server has been billed for the user account in the carrier server, and if the opt-in state is invalid, Sending a call including a telephone number and a billing amount to the billing server; using the retail server to send an interface including a PIN field to the consumer device; and at the retail server, a PIN code by the user Receiving a PIN code entered in the field; using the retail store server to send the PIN code to the billing server; and using the retail store server to receive a confirmation that the amount has been charged from the billing server Including.

  The invention will be further described by way of example only with reference to the accompanying drawings in which:

1 is a block diagram of a transaction management system including a consumer mobile phone, a retail store server, a billing server, and a carrier server. FIG. 5 is an interaction diagram showing how a consumer mobile phone, retail store server, billing server and carrier server interact to opt-in for registered phone and subsequent billing. A user interface screen that exists on a retail store server and is transmitted to a consumer mobile phone or another consumer device when the consumer chooses to pay by phone. A billing information method used by a retail store server that obtains a billing element from a billing server, presents a user interface screen on the consumer mobile phone, and obtains data entered in a field corresponding to the billing element from the consumer mobile phone It is a flowchart which shows. FIG. 2 shows the user interface screen of FIG. 1 prompting the consumer to enter a telephone number recorded by the retail store server for making a purchase via the billing server. A text message containing a PIN code that is received from a billing server by a consumer mobile phone after the billing server generates a PIN code. 5 is a user interface screen of FIG. 1 in which a user inputs a PIN code received by the text message of FIG. 5B. It is the user interface screen of FIG. 1 after a user inputs a PIN code and a transaction is confirmed. This message is received by the consumer mobile phone after the transaction is completed. It is a flowchart which shows the example of an expansion or modification of an accounting information method. FIG. 5 is a user interface screen that allows a consumer to select opt-in to a registered telephone relationship. It is a user interface screen for a consumer to input a PIN code. FIG. 9 is a flowchart of a registered telephone opt-in method used to send a text message including a PIN code for a consumer to enter on the screen of FIG. 8 during a registered telephone opt-in request to a billing server by a retail store server. FIG. 5 is a user interface screen displayed on a consumer mobile phone showing that the PIN code has been verified and that a purchase is possible for a consumer account on the retail store server. FIG. 6 shows a text message received by a consumer mobile phone that indicates the success of a registered phone opt-in, discloses the terms of the registered phone relationship, and gives the consumer instructions on how to cancel the registered phone call to the retail store. FIG. 6 illustrates a data structure for indicating active / inactive registered telephone opt-ins in a billing server. It is a flowchart which shows the charging method which a retail store server directs a billing server to charge a user account in a communication carrier server. It is an exchange screen where a user chooses purchase. It is an interface screen after a consumer makes a purchase. It is a figure which shows the text message which a consumer mobile telephone receives when the charge to a communication carrier server is performed. It is a flowchart which shows the expansion of the charging method of FIG. FIG. 5 is an interaction diagram illustrating how a consumer can cancel a registered phone call through a retail server interface. FIG. 5 is an interaction diagram illustrating how a consumer can cancel a registered phone by sending a text message to a billing server. It is a figure which shows the example of the text message exchanged for registration telephone cancellation | release as demonstrated with reference to FIG. It is a flowchart which shows the whole function of a system. It is a block diagram which shows the smart phone function of a consumer mobile phone. FIG. 2 is a block diagram of a machine that takes the form of a computer system that forms part of a registered telephone system.

  FIG. 1 of the accompanying drawings illustrates a registered telephone-based billing system 10 that includes a consumer mobile phone 12, a retail store server 14, a billing server 16, and a carrier server 18 according to an embodiment of the present invention. The retail store server 14 includes a user interface 20 for a consumer using a consumer mobile phone 12 or other consumer device to purchase and manage a registered telephone opt-in, and a registered telephone 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.

  The consumer mobile phone 12 opts in at 30 for automatic billing for future purchases by communicating with the retail store server 14 through the user interface 20 and storing the phone number in a file (registered phone) at 30. Communicates to the billing server 16 a series of data that enables the billing server 16 to communicate with the consumer mobile phone 12 for the purpose of confirming the registered phone opt-in by the consumer mobile phone 12. At 34, the SMS messaging module 28 communicates with the consumer mobile phone 12 via text messaging to confirm the registered phone opt-in by the consumer mobile phone 12, and at 36 confirms the registered phone opt-in by the consumer mobile phone 12. Send a text message. At 38, the continuous billing management module 22 starts billing through the carrier billing module 26. At 39, the carrier billing module 29 attempts to charge the account corresponding to the telephone number of the consumer mobile phone 12 on the carrier server 18. At 40, additional purchase billing is applied to the registered telephone opt-in, and at 39, communication is made to the carrier server 18.

  At 42, the consumer mobile phone 12 can cancel the registered phone opt-in through the user interface 20, which results in a communication to release the registered phone opt-in at 44, and a corresponding response from the SMS messaging module 28 at 46. Receive a text message. Alternatively, the consumer mobile phone 12 can send a text message to unlock the registered phone opt-in directly at 48 to the billing server 16 and then receive a text message from the SMS messaging module 28 at 46.

  FIG. 2 illustrates the process by which the consumer mobile phone 12 opts in to the registered telephone billing and billing configuration and the subsequent consumer billing. At 50, the consumer chooses to pay using mobile payments using the user interface 20 of FIG. FIG. 3 shows a screen of the user interface 20 for making a selection displayed on the consumer mobile phone 12.

  After selection by consumer mobile phone 12 at 50, retail store server 14 sends a billing information application programmable interface (API) call to billing server 16 at 52. This billing information call is https: // gateway. billingserver. to a dedicated uniform response locator (URL) of the billing server 16, such as com / charge-info. Thereafter, the billing server 16 uses this billing information method to obtain information relating to elements necessary for billing the consumer and a localized character string necessary for display to the consumer. These factors vary from country to country and in some cases from network to network.

  In general, the input required to collect information from the consumer mobile phone 12 is the msdisdn and network of the consumer mobile phone 12. In some countries, additional elements such as postal codes or resident registration numbers may exist. The billing information API response transmitted at 54 includes input elements necessary for each country and network. The billing information API response also provides localized strings that can be used as labels for these input fields.

  The main texts that need to be displayed on the consumer mobile phone 12 are country or network transaction term strings. The API returns country and, if necessary, network terms and conditions elements, which are often different for each country or network. Localized text about the deal terms is returned with a “<string>” tag. If a country or network requires the acceptance of transaction terms by the consumer mobile phone 12, a transaction terms input element will be included as a check box.

表２

The billing information API response returns information about all countries that the billing server 16 supports by default. The API supports any country parameter to filter responses to a specific country. Table 1 shows necessary charging information request parameters, and Table 2 shows charging information response parameters.
Table 1

Table 2

The following is an example of a character string in the billing information response to the billing information request.
[Program code]

  FIG. 4 shows an example of the billing information method. At 52, the retail store sends a billing information request to billing server 16. At 54, the billing server 16 returns an XML structure that includes all necessary billing elements, the networks supported in each country, and the transaction terms string to be displayed in each country or network. At 56, the retail store server 14 examines <inputs> in the XML structure to determine the elements that need to be collected from the consumer. At 58, the retail store server 14 selects <string> from the XML structure for the relevant appropriate language label and hint. At 60, the retail store server 14 displays the transaction conditions for the selected country. At 62, the user selects a network and enters his mobile number. At 63, the retail store server 14 examines the network specific transaction conditions and, if found, displays them on the consumer mobile phone 12 to the consumer. At 64, the retail store server 14 sends a billing information request for a particular country to the billing server 16. At 65, billing server 16 returns a response that includes the billing factors, network and transaction terms for the particular country.

  FIG. 5A shows a screen of the user interface 20 of FIG. 1 that prompts the consumer to enter a telephone number recorded by the retail store server 14 for making a purchase via the billing server 16. FIG. 5B shows a text message including the PIN code that the consumer mobile phone 12 receives from the billing server 16 after the billing server 16 generates the PIN code. This text message prompts the user to enter a PIN code into the user interface. FIG. 5C shows a screen of the user interface 20 of FIG. 1 where the user inputs the PIN code received by the text message of FIG. 5B. The PIN code is then transmitted to the billing server 16 through the retail store server 14. The billing server 16 verifies the PIN code received from the retail store server 14 against the PIN code transmitted to the consumer mobile phone 12 and approves the transaction if verified. Thereafter, the billing server 16 communicates with the carrier server 18 and charges an account in the carrier server 18. FIG. 5D shows the screen of the user interface 20 of FIG. 1 after the user has entered the PIN code and the transaction has been confirmed. FIG. 5E shows a message received by the consumer mobile phone 12 after the transaction is completed. At this time, when the consumer proceeds to opt-in for the registration telephone, the retail store server 14 and the billing server 16 bypass the message of FIG. 5A and the screen of FIG. 5E. Accordingly, the consumer is not required to enter the PIN code or confirm the transaction. Instead, the consumer receives only a message as shown in FIG. 5E after making a purchase.

  FIG. 6 shows an extended example (modification) of the billing information method. At 66, the retail store server 14 sends a billing information request for a particular country to the billing server 16. At 68, billing server 16 returns a response that includes the billing factors, network and transaction terms for a particular country.

  2 and 4, after the retail store server 14 receives data from the consumer mobile phone 12, at 72 in FIG. 2, the retail store server 14 makes a first registered phone opt-in API call to the billing server 16. Send. This first registered telephone opt-in API call is https: // gateway. billingserver. It is submitted to a dedicated URL of the billing server 16, such as com / opt-in. Next, the retail store server 14 and the billing server 16 share the phone number on the file and automatically register for this phone number without confirmation from the consumer mobile phone 12. The registered telephone opt-in is obtained from the consumer mobile phone 12 using the opt-in method.

The registered phone opt-in method is used to obtain a registered phone opt-in from the consumer to set the consumer's registered phone to a specific set of conditions (eg $ 100 or 90 sunrise charges) with the retail store. Is done. For example, if a retail store offers a registered phone opt-in, this method can be used to obtain a consumer registered phone opt-in that confirms the consumer's registration phone authorization and requests the retailer to provide: Is done.
Consumer-id (consumer ID) (unique identifier of the consumer)
-Msdisdn (International format mobile number)

The risk module 27 of FIG. 1 is used to evaluate a set of risk rules including the following to determine the effectiveness of a registered telephone opt-in.
• Country and network specific rules • Rules that apply to a single retailer • Rules that set limits based on time, eg 90 days • Rules that set limits based on spending eg 100 USD • msdisdn opt-in for individual msisdn Rules to block by level (blacklist to register registered phone)

  FIG. 7 shows a screen of the user interface 20 that prompts the consumer to opt-in to a registered phone relationship by selecting a check box after completing the transaction. The consumer can also move the mouse to “details” to receive the transaction terms as shown at the bottom of FIG. 5D. The consumer opts in to the registered telephone relationship and limits purchases related to this opt-in to a maximum of $ 100 or 90 sunrise expenses.

  Referring again to FIG. 2, the billing server 16 generates a unique PIN code and sends the PIN code in text message to the consumer mobile phone 12 at 76 in FIG. 2, where the user interface 20 of FIG. A PIN code field as further shown in FIG. 8 is displayed on the consumer mobile phone 12. In 78 of FIG. 2, the consumer of the consumer mobile phone 12 inputs the PIN code received in the text message of FIG. 7 in the PIN code field and transmits it to the retail store server 14. The retail store server 14 receives the PIN code from the consumer mobile phone 12, and in 80 of FIG. 2, the received PIN code, and msdisdn and consumer-id (consumer ID) are first registered in the billing server 16. A second registered telephone opt-in request is transmitted to the same URL as the telephone opt-in request. The billing server 16 then verifies and confirms the PIN code received from the retail server 14 at 80 against the PIN code sent in text message at 74 and returns a response to the retail server 14. Each of the billing server 16 and retail store server 14 records or stores the result of the consumer's registered phone opt-in so that it can be referenced in the next billing API call made when the user makes the next purchase.

表４

表５

Table 3 shows the parameters of the registered telephone opt-in request sent at 72 and 80 in FIG. Tables 4 and 5 show registered telephone opt-in response parameters determined by the billing server 16 and provided to the retail store server 14 in response to the calls 72 and 80 of FIG.
Table 3

Table 4

Table 5

  FIG. 9 shows an example of a registered telephone opt-in method. At 82, the retail store server 14 sends a registered telephone opt-in request that includes the values of msdn, consumer-id (consumer ID), network and country (country). At 84, if there is a current valid PIN code that has not been verified, VERIFICATION IN PROGRESS is returned. Otherwise, a new PIN code is generated and VERIFICATION IN PROGRESS is returned. At 74 in FIG. 2, billing server 16 sends a message suitable for the country, including PIN code, registered phone relationship (eg, $ 100 or 30 day consent), to consumer mobile phone 12.

  At 86, the retail store server 14 collects the PIN code transmitted at 78 of FIG. 2, and transmits a registered telephone opt-in request including the acquired PIN code at 80 of FIG. If the submitted PIN code is correct, VERIFIED (verified) is returned and the billing server 16 sends a confirmation message containing the registration phone opt-in conditions, purchases and a STOP command (to unsubscribe via SMS). It transmits to the consumer mobile phone 12. Otherwise, an INVALID PIN (invalid PIN) is returned. PIN code entry can only be attempted 3 times (or other limited number of attempts).

  At 88, the retail store server 14 collects the PIN code after 24 hours and sends a registered telephone opt-in request containing this PIN. If the PIN code has expired, PIN EXPIRED (PIN expired) is returned.

  FIG. 10 is displayed on the consumer mobile phone 12 to indicate that the PIN code has been transmitted and verified and registered phone opt-in is now available for the consumer account on the retail store server 14. This is a screen of the user interface 20. FIG. 11 shows the success of the registered phone opt-in process that the SMS messaging module 28 sends to the consumer mobile phone 12 at 90 in FIG. 2, discloses the registered phone opt-in conditions, and informs the consumer of the registered phone opt-in. Indicates a text message giving instructions on how to cancel. The text message of FIG. 11 is not sent if the registered phone opt-in fails because the PIN code has not been verified.

  The method using PIN code verification, shown in steps 72-90, is one method of verifying the registration phone opt-in with the consumer device and recording the status of the registration phone as active (or inactive). . For example, another method of handshaking a mobile device, such as waiting for the consumer to respond “Y” or “Yes” with a response text message after sending an SMS text message to the mobile device. Use can be included. Alternatively, the retail store server can host a payment panel through which the billing server communicates with the user device to confirm the opt-in request.

  FIG. 12 shows a data structure in the consumer opt-in management module 24 of FIG. This data structure holds a registered telephone opt-in state for each merchant-id (retail store ID), msdisdn and consumer-id (consumer ID). In this data structure, a consumer is effectively identified through a combination of msdn and consumer-id (consumer ID). This data structure supports use cases that can be billed to multiple consumers using msdisdn. For example, a child may be using the parent's phone number as a billing msdisdn. However, each child and its parent has a unique consumer-id (consumer ID) with a given retail store. This data structure holds the opt-in state along with the date and time of the last state change. This date and time is used to evaluate whether the status of the registered phone has expired at the time of consumer purchase. The data structure also holds data relating to cumulative spending by consumers. This data is used to determine whether the registered telephone opt-in has expired due to exceeding a prescribed spending threshold. Data regarding the cumulative cost of registered telephones can also be included in purchase receipts sent to consumers.

  Referring again to FIG. 2, once a consumer purchase is made at the retail store server 14, the retail store server 14 issues a billing API call at 98 requesting a one-step payment process from the consumer mobile phone 12. Send to billing server 16. The billing API call is submitted to the dedicated URL of the billing server 16. A billing method that supports a one-time payment scenario can be used. The billing server 16 determines whether there is a corresponding consumer registration telephone opt-in in an active state according to the values of merchant-id (retail store ID), msdisdn and consumer-id (consumer ID) received in the billing API call. Can be checked. If the opt-in state is active, billing server 16 proceeds to step 100. When the opt-in state is inactive, the billing server 16 performs the PIN code verification by executing again the steps described with reference to FIGS. 5A to 5E.

  If the charging request is approved, a charge-id (charging ID) is returned from the billing server 16 to the retail store server 14 in 104 of FIG. Approval means that the request has been correctly verified, submitted to the carrier server 18 for processing at 100 in FIG. 2, and a valid response from the carrier server 18 at 102. A risk check has already been performed by the billing server 16 before submitting a charge to the carrier server 18 for processing.

  Billing is an asynchronous request. When the billing request is completed, regardless of whether the billing is successful or unsuccessful, the billing server 16 receives the billing result from the carrier server 18 and sends a callback notification including the final result of the billing attempt to the retail store server 14. To do.

  The billing request is idempotent. Each request is uniquely identified by a request-id (request ID) provided by the retail store server 14. For example, if two billing requests are made with a request-id (request ID) of the same retail store, the user's account is billed only once and both requests receive the same response.

  The billing result callback notification provides the final state (success or failure) of the transaction. The callback notification is used by the retail store server 14 to fulfill the purchase. Execution is performed only once for a given transaction identified by a unique charge-id field value. If there is a communication problem between the billing server 16 and the retail store server 14, the retail store server 14 may receive a billing result callback for the same transaction multiple times. A common cause of continually retrying callback notifications is an inappropriate acknowledgment (ACK) from the retail store server 14 to the billing server 16.

  The retail store server 14 receives callbacks from the billing server 16 only for approved requests. If the request is not approved due to a validation error or risk check, the billing server 16 does not submit a processing request to the carrier server 18, so a callback notification is sent from the billing server 16 to the retail store server 14. There is no.

表１０

Table 9 shows the billing request parameters at 98 in FIG. Table 10 shows charging request response parameters in 104 of FIG.
Table 9

Table 10

  FIG. 13 shows an example of a charging method. At 106, the consumer mobile phone 12 or other consumer device consumer has a registered phone that has been pre-registered using the registered phone opt-in API method. At 108, the consumer of the consumer mobile phone 12 or other consumer device returns to the retail store server 14 to select a service or product. At 98, the retail store server 14 submits a billing request to the billing server 16 including the customer-id (customer ID), msdisdn, network and purchase details. At 112, billing server 16 performs registered phone restrictions, spending limits, speed checks, and other consumer protection checks. If the registered phone restriction fails, the consumer is asked at 114 to update the registered phone opt-in for his registered phone. If the spending or speed check fails, or if msdisdn is blacklisted, the billing request fails at 116 and an appropriate error message is returned. At 118, billing server 16 detects the carrier (using the provided network or search if no network is provided) and submits a billing request to update the carrier. At 120, the billing server 16 returns the final result of the billing request to the retail store server 14 with a billing result callback notification. Thereafter, at 120 in FIG. 2, the SMS module sends a text message confirming the purchase to the consumer mobile phone 12.

  As described above, billing is processed without communication with the consumer mobile phone 12 as indicated by 74 in FIG. However, if the opt-in state is inactive, the billing server 16 sends a text message containing the new PIN code to the consumer mobile phone 12 as described at 74 in FIG. 2, and steps up to step 90 in FIG. Repeat.

  FIG. 14A is an AC screen for the user to select purchase. FIG. 14B is an interface screen after the consumer makes a purchase.

  FIG. 15 shows an extension of the accounting flow method of FIG. Assume that the billing request failed at 122. At 124, the retail store server 14 submits a billing request with a new request-id (request ID) and retries billing. When charging is retried with the previously failed request-id (request ID), the billing server 16 returns the same failure response due to idempotency. At 126, billing server 16 charges the consumer's account using a carrier billing method. At 128, the billing server 16 returns information indicating the success or failure of the billing request in the billing result callback notification.

表１２

Tables 11 and 12 show charging result callback notification parameters.
Table 11

Table 12

  FIG. 16 shows how the consumer mobile phone 12 cancels the registered phone opt-in via the user interface 20 with reference to FIG. At 42 in FIG. 18, the consumer mobile phone 12 is released from the retail store server 14 using the user interface 20 in FIG. 1 of the retail store server 14. At 44, the retail store server 14 submits a registered telephone opt-in release API call at the dedicated URL of the billing server 16 to register corresponding merchant-id (retail store ID), msdisdn and consumer-id (consumer ID). The billing server 16 is notified that the telephone opt-in is cancelled. At 130, billing server 16 unoptimizes the consumer registration phone and updates the associated opt-in entry of FIG. 12 as inactive. If further charges for this merchant-id (retail store ID), msdisn and consumer-id (consumer ID) are submitted by the retail store server 14 to the billing server 16, the text to the consumer mobile phone 12 Confirmed through message. At 132, the retail store server 14 updates the user interface 20 to reflect that the registered phone opt-in has been released.

  FIG. 17 illustrates a method for a consumer to cancel a registered telephone opt-in through text messaging, as referenced with respect to FIG. At 48, the consumer mobile phone 12 sends a STOP through the SMS text. This text message can be sent as a response to the short code 723-53 that the consumer mobile phone 12 received the text. At 134, the billing server 16 releases the registered telephone opt-in and updates the associated opt-in entry of FIG. 12 as inactive. If a further charge for this merchant-id (retail store ID), msdisn and consumer-id (consumer ID) is submitted by the retail store server 14, it will be confirmed through a text message with the consumer mobile phone 12. At 46, billing server 16 sends a confirmation of the unlocked SMS text to consumer mobile phone 12. At 136, the billing server 16 sends a consumer registration phone opt-in cancellation notice to the retail store server 14 to cause the registered phone relationship to be released at the retail store server 14.

  FIG. 18 shows an example of a text message exchanged to cancel the registered telephone opt-in as described with reference to FIG. FIG. 20 shows both text messages transmitted and received at 48 and 46 in FIG. 19 as second and third messages.

  FIG. 19 shows how to repeat the procedure described so far. At 200, the first purchase is completed using PIN code verification. At 202, a registered telephone opt-in procedure is performed. At 204, the next purchase is started but not completed. At 206, it is determined whether a registered telephone opt-in exists.

  If it is determined at 206 that there is a registered telephone opt-in, at 208 the purchase is completed without PIN code verification. If there is a next purchase, the next purchase begins at 204.

  If it is determined at 206 that there is no registered telephone opt-in, the purchase is completed at 200 and a registered telephone opt-in procedure is performed at 202.

  The present invention further provides a way for a consumer to update their registered phone opt-in and the retail store to remind the consumer of the registered phone opt-in that needs to be updated. The consumer can renew his registered phone using the steps outlined herein. Another way for consumers to update their registered phone is through an SMS-only interaction, where the consumer can update his registered phone in response to an SMS sent by the system. The SMS can be sent during a purchase transaction or at some point determined by the retailer or carrier (eg, as a reminder one week before the registration phone expires). The retail store server can communicate with the billing server to obtain data regarding registered phone opt-ins that need to be updated based on spending or time limits to remind consumers before expiration. This allows the retail store to send a notification prior to expiration that prompts the consumer to renew his registered phone opt-in.

  Retail stores may also be given the ability to check when an opt-in expires, for example within 10 days or a certain additional expense.

  FIG. 20 is a block diagram illustrating the consumer mobile phone 12 showing 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 media), a memory controller 1220, one or more processing units (CPUs) 1200, and a peripheral device interface 1180. RF circuit 1080, audio circuit 1100, speaker 1110, microphone 1130, input / output (I / O) subsystem 1060, other input or control device 1160, and external port 1240. These components communicate via one or more communication buses or signal lines 1030.

  The various components shown in FIG. 20 can be implemented in hardware, software, or a combination of hardware and software including one or more signal processing and / or application specific integrated circuits.

  Memory 1020 can include high-speed random access memory and can 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 peripheral device interface 1180, is controlled by the memory controller 1220.

  The peripheral device interface 1180 connects input / output peripheral devices of the apparatus to the CPU 1200 and the memory 1020. The one or more processors 1200 activate or execute various software programs and / or instruction sets stored in the memory 1020 to perform various functions and data processing of the consumer mobile phone 12.

  An RF (radio frequency) circuit 1080 transmits and receives RF signals, also called electromagnetic signals. The RF circuit 1080 converts between an electrical signal and an electromagnetic signal, and communicates with a communication network and other communication devices via the electromagnetic signal. The RF circuit 1080 includes 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 and memory, etc. Including well-known circuits for performing the functions. The RF circuit 1080 is a network such as the Internet, also called the World Wide Web (WWW), and / or a wireless network such as a cellular telephone network, a wireless local area network (LAN) and / or a metropolitan area network (MAN). It is possible to communicate with other devices by wireless communication. Wireless communication can use any of a number of communication standards, protocols, and techniques well known in the art.

  Audio circuit 1100, speaker 1110 and microphone 1130 provide an audio interface between the user and consumer mobile phone 12. The audio circuit 1100 receives audio data from the peripheral device interface 1180, converts the audio data into an electric signal, and transmits the electric signal to the speaker 1110. The speaker 1110 converts an electric signal into a sound wave that can be heard by a human. The audio circuit 1100 also receives an electrical signal converted from sound waves by the microphone 1130. Audio circuit 1100 converts the electrical signal into audio data and transmits the audio data to peripheral device interface 1180 for processing. Audio circuit 1100 includes audio circuit 1100 and removable audio input / output peripherals such as headsets with output-only headphones or outputs (eg, one or both ear headphones) and inputs (eg, microphones). It also includes a headphone jack that serves as an interface between the two.

  The I / O subsystem 1060 connects input / output peripheral devices on the consumer mobile phone 12, such as the touch screen 1120 and other input / control devices 1160, to the peripheral device interface 1180. The I / O subsystem 1060 includes a display controller 1560 for other inputs or control devices and one or more input controllers 1600. One or more input controllers 1600 send and receive electrical signals to and from other inputs or control devices 1160. Other input / control devices 1160 can include physical buttons (eg, push buttons, rocker buttons, etc.), dials, slider switches, joysticks, click wheels, etc., all of which serve to form part of the interface. Fulfill. The input controller 1600 can be connected to any of a keyboard, an infrared port, a USB port, and a pointer device such as a mouse. The one or more buttons may include up / down buttons for volume control of the speaker 1110 and / or microphone 1130. The one or more buttons can include a push button. By quickly pressing the push button, the process of unlocking the touch screen 1120 or unlocking the device using a gesture on the touch screen can be started. When the push button is pressed and held, the power of the consumer mobile phone 12 can be switched on or off. The touch screen 1120 is used to implement virtual buttons or soft buttons and one or more soft keyboards.

  Touch-sensitive touch screen 1120 provides an input interface and an output interface between the device and the user. The display controller 1560 transmits and receives electrical signals to and from the touch screen 1120. Touch screen 1120 displays visual output to the user. The visual output can include graphics, text, icons, video, and any combination thereof (collectively referred to as “graphics”). In some embodiments, some or all of the visual output can correspond to user interface objects, further details of which are described below.

  Touch screen 1120 includes a touch-sensitive surface, sensor, or series of sensors that accepts input from a user based on tactile and / or tactile contact. Touch screen 1120 and display controller 1560 (and any associated modules and / or instruction set in memory 1020) detect touches (and any touch movements or interruptions) on touch screen 1120 and detect the detected touches. Into an interaction with a user interface object (eg, one or more soft keys, icons, web pages or images) displayed on the touch screen. In the exemplary embodiment, the contact between touch screen 1120 and the user corresponds to the user's finger.

  The touch screen 1120 can use LCD (Liquid Crystal Display) technology or LPD (Published Polymer Display) technology, although other display technologies can be used in other embodiments. Touch screen 1120 and display controller 1560 include, but are not limited to, capacitive, resistive, infrared and surface acoustic wave technologies, and one or more contacts with other proximity sensor arrays or touch screen 1120. Any of a plurality of currently known or later developed touch sensing techniques, including other elements for identifying, can be used to detect touch and any movement or interruption thereof.

  A user can make contact with touch screen 1120 using any suitable object or accessory, such as a stylus and fingers. In some embodiments, the user interface is designed to work primarily with finger touches and gestures, which are much larger than stylus-based input due to the wide finger touch range on the touch screen. The accuracy drops. In some embodiments, the device converts a rough finger input into a precise pointer / cursor position or command to perform the action desired by the user.

  The consumer mobile phone 12 also includes a power system 1620 for supplying power to various components. The power system 1620 includes a power management system, one or more power sources (eg, battery, alternating current (AC)), charging system, power failure detection circuit, power converter or inverter, power status indicator (eg, light emitting diode (LED)). ), And any other components related to the generation, management and distribution of power within the portable device.

  Software components stored in the memory 1020 include an operating system 1260, a communication module (or instruction set) 1280, a touch / motion module (or instruction set) 1300, a graphics module (or instruction set) 1320, a text input module (or instructions). Set) 1340 and application (or instruction set) 1360.

  An operating system 1260 (eg, an embedded operating system such as Darwin, RTXC, LINUX®, UNIX®, OS X, WINDOWS®, or VxWorks) is a common system task (eg, memory Management, storage device control, power management, etc.) to control and manage software components and / or drivers to facilitate communication between the various hardware components and software components.

  The communication module 1280 facilitates communication with other devices via one or more external ports 1240 and also includes various software components for processing data received by the RF circuit 1080 and / or the external port 1240. . The external port 1240 (eg, universal serial bus (USB), FIREWIRE, etc.) is adapted to couple directly to other devices or indirectly via a network (eg, the Internet, wireless LAN, etc.).

  Contact / motion module 1300 may detect contact with touch screen 1120 and other touch sensitive devices (eg, a touchpad or physical click wheel) (in conjunction with display controller 1560). The contact / motion module 1300 determines whether a contact has occurred, whether the contact has moved, and tracking the movement across the touch screen 1120, determining whether the contact has been interrupted (ie, the contact has stopped). And various software components that perform various operations related to contact detection. Identification of contact movement can include identification of contact speed (scale), speed (scale and direction), and / or acceleration (change in scale and / or direction). These motions can be applied to a single contact (eg, contact with one finger) or multiple simultaneous contacts (eg, “multi-touch” / contact with multiple fingers). Contact / motion module 1300 and display controller 1560 also detect contact on the touchpad.

  Graphics module 1320 includes various known software components for rendering and displaying graphics on touch screen 1120 and includes components for changing the strength of the displayed graphics. As used herein, the term “graphics” includes any object that can be displayed to the user, including text, web pages, icons (such as user interface objects including softkeys), digital images, videos, animations, and the like.

  Text input module 1340, which can be a component of graphics module 1320, can be used in various applications (eg, contacts, email, IM, blogs, browsers, and any other application that requires text input). Provides a soft keyboard for entering text. Application 1360 can include a mobile application 208.

  FIG. 21 is a diagrammatic representation of a machine taking the exemplary form of a computer system 900 that can internally execute a set of instructions for causing the machine to perform any one or more of the methods disclosed herein. In another embodiment, the machine can operate as a stand-alone device or can be connected (eg, networked) to other machines. In a network deployment, this machine can operate as a server or client machine in a server-client network environment or as a peer machine in a peer-to-peer (or distributed) network environment. This machine specifies a personal computer (PC), a tablet PC, a set top box (STB), a personal digital assistant (PDA), a mobile phone, a web appliance, a network router, a switch or bridge, or an operation to be performed by this machine. It can be any machine that can execute an instruction set (sequential or otherwise). Furthermore, although only one machine is shown, the term “machine” refers to an instruction set (or sets) for performing any one or more of the methods described herein, individually or It should be construed to include any group of machines that work together.

  The exemplary computer system 900 includes a processor 930 (eg, a central processing unit (CPU)), a graphics processing unit (GPU), or both) and a main memory 932 (eg, read only memory (ROM), flash, etc. Memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), and static memory 934 (eg, flash memory, static random access memory (SRAM, etc.)), which are buses Communicate with each other via 936.

  Computer system 900 can further include a video display 938 (eg, a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 900 may also include an alphanumeric input device 940 (eg, a keyboard), a cursor control device 942 (eg, a mouse), a disk drive unit 944, a signal generator 946 (eg, a speaker), and a network interface device 948. .

  The disk drive unit 944 includes a machine readable medium 950 that stores one or more instruction sets 952 (eg, software) that embody any one or more of the methods or functions described herein. . The software may reside entirely or at least partially in the main memory 932 and / or the processor 930 during execution by the computer system 900, and the memory 932 and the processor 930 may constitute a machine-readable medium. . Further, the software can be transmitted and received via the network 954 via the network interface device 948.

  Although the exemplary embodiment shows instructions 952 as being on a single medium, the term “machine-readable medium” refers to a single medium or one or more instruction sets that store one or more instruction sets. It should be construed to be understood as multiple media (eg, centralized or distributed databases or data stores, and / or associated caches and servers). Also, the term “machine-readable medium” refers to any medium that causes a machine to perform any one or more of the methods herein, which can store, encode, or carry the instruction set that the machine executes. Should be interpreted as including. Thus, the term “machine-readable medium” should be construed to include, but is not limited to, solid state memory, optical and magnetic media.

  While several exemplary embodiments have been described and illustrated in the accompanying drawings, such embodiments are merely illustrative rather than limiting of the invention, and modifications will occur to those skilled in the art. Thus, it should be understood that the invention is not limited to the specific arrangements and arrangements shown and described.

DESCRIPTION OF SYMBOLS 10 Billing system 12 Consumer mobile phone 14 Retail store server 16 Billing server 18 Carrier server 20 User interface (for consumer managing purchase / registered phone) 22 Registered phone billing management module 24 Consumer opt-in management module 26 Carrier billing module 27 Risk module 28 SMS messaging module 30 Check box to register on registered phone upon purchase 32 Consumer opt-in to registered phone 34 Opt-in message for registered phone requirements 36 For billing registered phone Confirmation message 38 Initial charge of registered phone 39 Communication 40 Charge for additional purchase 42 Cancel subscription 44 Cancel opt-in to registered phone 46 Confirm stop STOP 48 Cancel registered phone opt-in via STOP

Claims (13)

A transaction management method executed by a retail store server,
a) performing a registered telephone opt-in method using the retail store server, the registered telephone opt-in method comprising:
Receiving msdisdn from a consumer device at the retail store server;
Sending a first registered telephone opt-in request including the msdisdn from the retail store server to a billing server;
Receiving a PIN code from the consumer device;
Sending a second registration telephone opt-in request including the PIN code from the retail store server to the billing server;
Receiving at the retail store server a response from the billing server indicating whether the PIN code is verified or invalid;
The transaction management method includes:
b) further comprising executing a billing method using the retail store server, wherein the billing method comprises:
A billing API call including an amount and a mesdn for the billing server to determine a corresponding registered phone opt-in status from the retail store server to the billing server if the PIN code is verified; A step of not sending if the PIN code is invalid;
Receiving at the retail store server a billing result callback notification from the billing server indicating whether the billing server has been billed for the user account at the carrier server;
including,
A method characterized by that. The first registered phone opt-in request includes a merchant-id (retail store ID), and the registered phone opt-in status is recorded as active against the merchant-id (retail store ID).
The method of claim 1. The msdisdn includes a plurality of merchant-ids (retail store IDs) each having a separate registered phone opt-in parameter that is selectively set to active or inactive.
The method of claim 2 . The first registration phone opt-in request includes consumer-id (unique consumer identifier provided by the retail store), country (country code in ISO 3166-1-alpha-2 standard), item-description (s) The exact quantity and name of the item to be purchased, if multiple items are purchased (eg “1000 credits”), the quantity must be included, overriding “Product Description”, limited to 20 characters Longer strings are truncated), merchant-id (the retailer identifier value assigned by the billing server), msdisdn (international MSISDN format: country mobile phone number + mobile phone number), and service- id (an identifier provided by the retail store) Including,
The method of claim 1. The second registration phone opt-in request includes consumer-id (unique consumer identifier provided by the retail store), country (country code in ISO 3166-1-alpha-2 standard), item-description (s) The exact quantity and name of the item to be purchased, if multiple items are purchased (eg “1000 credits”), the quantity must be included, overriding “Product Description”, limited to 20 characters Longer strings are truncated), merchant-id (the retailer identifier value assigned by the billing server), msdisdn (international MSISDN format: country mobile phone number + mobile phone number), and service- id (an identifier provided by the retail store) Including,
The method of claim 4. The billing API call is consumer-id (zip or rrn, ie a JSON structure containing any billing element such as {'zip94939}), consumer-ip-address (consumer's outgoing IP address, used for risk check. If not available, submit “NOT_AVAILABLE” value), country (country code in ISO 3166-1-alpha-2 standard), currency (three-letter currency code of ISO 4217), end-merchant-id (billing server) Assigned by, the retailer ID of the final retailer submitting the transaction through the reseller, item-description (product disclosure describing the quantity and type of items purchased (ie, “10 credits” instead of “credits”). Limit to 0 characters, strings longer than that are truncated), merchant-id (retail store identifier value assigned by billing server), request-id (unique request ID assigned by retail store), subscription-frequency (subscription) Update frequency (DAILY (daily), MONTHLY (monthly), YEARLY (yearly)), subscription-id (unique identifier assigned by retailer to the consumer's subscription), service-id (identifier provided by retailer) , And total-amount
The method of claim 1. The billing result callback notification includes consumer-auth-required (billing identifier assigned by the billing server (returned when the “billing” request is successful)), result-code (result code of the request), and result-message. Including a human-readable description of the result,
The method of claim 1 . c) before the registration telephone opt-in method, further comprising executing a billing information method using the retail store server, wherein the billing information method comprises:
Transmitting a billing information request from the retail server to the billing server;
Receiving a billing element from the billing server at the retail store server in response to the billing information request;
Transmitting a user interface having a field based on the billing factor from the retail store server to a consumer device;
Receiving data entered in the field at the consumer device at the retail store server;
The received data is included in the first registered telephone opt-in request,
The method of claim 1 . The billing information request includes a merchant-id (a retail store identifier value assigned by the billing server).
The method of claim 8 . The billing element includes a country and a network,
The method of claim 9 . c) further comprising executing a release method at the retail store server, the release method comprising:
Transmitting a user interface screen from the retail store server to the consumer device that allows for the selection of unsubscribe;
Receiving at the retail store server a call to unsubscribe from the consumer device via the interface;
Making a registered telephone opt-in cancellation API call from the retail store server to the billing server to update the registered telephone opt-in status to inactive;
Further including
The method of claim 1 . A computer readable medium storing an instruction set for executing a transaction management method using a retail store server when executed by a processor of the computer, the transaction management method comprising: a) a registered telephone opt-in using the retail store server Including the step of performing a method, wherein the registered telephone opt-in method comprises:
Receiving msdisdn from a consumer device at the retail store server;
Sending a first registered telephone opt-in request including the msdisdn from the retail store server to a billing server;
Receiving a PIN code from the consumer device;
Sending a second registration telephone opt-in request including the PIN code from the retail store server to the billing server;
Receiving at the retail store server a response from the billing server indicating whether the PIN code is verified or invalid;
The transaction management method includes:
b) further comprising executing a billing method using the retail store server, wherein the billing method comprises:
A billing API call including an amount and a mesdn for the billing server to determine a corresponding registered phone opt-in status from the retail store server to the billing server if the PIN code is verified; A step of not sending if the PIN code is invalid;
Receiving at the retail store server a billing result callback notification from the billing server indicating whether the billing server has been billed for the user account at the carrier server;
including,
A computer-readable medium characterized by the above. A processor;
A computer readable medium connected to the processor;
An instruction set on the computer-readable medium executable by the processor;
And the instruction set includes:
A msisdn field for entering msdisdn, which can be received by the processor and sent to the billing server in a first registration phone opt-in request; and the processor can receive and in the second registration phone opt-in request A user interface sent to the consumer device, including a PIN code field for entering a PIN code sent to the billing server;
A continuous billing management module that executes the billing method;
The charging method includes:
A billing API call including an amount and a mesdn for the billing server to determine a corresponding registered phone opt-in status from the retail store server to the billing server if the PIN code is verified; A step of not sending if the PIN code is invalid;
Receiving at the retail store server a billing result callback notification from the billing server indicating whether the billing server has been billed for the user account at the carrier server;
including,
A retail store server characterized by that.

Images