JP6772228B2 - Registration phone - Google Patents

Description

[Cross-reference with related applications]
This application is 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. It claims the priority of US Patent Application No. 13 / 928,016 filed on 26th and US Patent Application 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 systems and methods for opt-in to registered telephone relationships in order to charge consumers.

When a consumer purchases a product or service online, use a payment source choice such as credit card, debit card payment, payment from a group-owned account at checkout, or make the purchase a telephone bill. You may be given the option to charge. When the consumer chooses to charge his or her telephone bill, the retailer server directs the billing server, which works with the carrier server, to charge. Normally, the billing server communicates with the consumer mobile phone to confirm the billing before charging the telephone bill on the carrier server.

The billing server often sends a PIN code to the consumer mobile phone when communicating with the consumer mobile phone. At this time, the consumer must enter the PIN code in the user interface of the retail store server. This is a requirement for the carrier server, as the carrier server usually needs to confirm the charges to the consumer mobile phone. Such processing can be difficult for many consumers who make many purchases from a particular retail store, in which case no purchases are made to this retail store.

The present invention provides a transaction management method using a billing server, which method comprises performing a registered telephone opt-in method using a billing server. The registered telephone opt-in method is between a step of receiving a first registered telephone opt-in request at the billing server, including the msisdn and a unique consumer identifier provided by the retailer, and a consumer device using the billing server. The above transaction management method includes a step of confirming the first registered telephone opt-in and a step of recording the registered telephone opt-in status as active by using the billing server when the first registered telephone is confirmed. Further including the step of executing the billing method using the billing server, the billing method includes a step of receiving a billing API call including at least one identifier and an amount from the retail store server on the billing server and an identifier on the billing server. A step to determine the corresponding registered phone opt-in status and a billing request to the user account including the amount corresponding to the amount received in the billing API call are sent to the carrier server if the registered phone opt-in status is active. And includes a step not to send if the registered phone opt-in status is inactive.

The present invention also provides a computer-readable medium that stores an instruction set that executes a transaction management method using a billing server when executed by a computer processor, the transaction management method being a registered telephone opt-in method using a billing server. Includes steps to perform. The registered telephone opt-in method is between a step of receiving a first registered telephone opt-in request at the billing server, including the msisdn and a unique consumer identifier provided by the retailer, and a consumer device using the billing server. The above transaction management method includes a step of confirming the first registered telephone opt-in and a step of recording the registered telephone opt-in status as active by using the billing server when the first registered telephone is confirmed. Further including the step of executing the billing method using the billing server, the billing method includes a step of receiving a billing API call including at least two identifiers and an amount from the retail store server on the billing server and a data structure on the billing server. Steps to determine the registered phone opt-in status corresponding to the identifier in, and a billing request to the user account including the amount corresponding to the amount received in the billing API call, communication business if the registered phone opt-in status is active Includes a step of sending to the server and not sending if the registered phone opt-in status is inactive.

The present invention further provides a billing server that includes a processor, a computer-readable medium connected to the processor, and an instruction set on the computer-readable medium that can be executed by the processor. The instruction set includes an SMS messaging module and a consumer registered telephone opt-in management module that performs a registered telephone opt-in method, wherein the registered telephone opt-in method includes a first registered telephone opt-in request that includes msisdn and a unique consumer ID. And the step of confirming the first registered phone opt-in with the consumer device using the billing server, and the step of confirming the first registered phone opt-in using the billing server. The instruction set further includes a carrier billing module that executes the billing method, including a step of recording the state as active, and the billing method makes a billing API call from the retailer server containing at least two identifiers and an amount. The registered phone opt-in state is active, with the step to receive, the step to determine the registered phone opt-in status corresponding to the identifier in the data structure, and the billing request to the user account including the amount corresponding to the amount received in the billing API call. Includes a step of sending to the carrier server if there is one and not sending if the registered phone opt-in status is inactive.

The present invention further provides a transaction management method using a billing server, the transaction management method using a step of receiving a first registered telephone opt-in request including msisdn at the billing server and a consumer using the billing server. In the step of confirming the first registered telephone opt-in with the device, the step of recording the registered telephone opt-in status as active by using the billing server when the first registered telephone is confirmed, and the billing server. A step of receiving a billing API call containing at least one identifier and amount from the retail server, a step of determining the registered phone opt-in status corresponding to the identifier on the billing server, and a PIN if the registered phone opt-in state is active. It includes the step of sending a billing request to the user account including the amount corresponding to the amount received in the billing call to the carrier server without sending a text message containing the code to the consumer mobile device.

The present invention also provides a computer-readable medium that stores an instruction set that executes a transaction management method using a billing server when executed by a computer processor, the transaction management method comprising the first msisdn in the billing server. The step of receiving the registered telephone opt-in request, the step of confirming the first registered telephone opt-in with the consumer device using the billing server, and the step of confirming the first registered telephone opt-in, and the billing server when the first registered telephone is confirmed. The step of recording the registered phone opt-in status as active, the step of receiving a billing API call containing at least one identifier and the amount on the billing server from the retail store server, and the step of receiving the billing API call corresponding to the identifier on the billing server. The step to determine the status and if the registered phone opt-in status is active, to the user account containing 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. Includes a step of sending a billing request to a carrier server.

The present invention further provides a billing server that includes a processor, a computer-readable medium connected to the processor, and an instruction set on the computer-readable medium that can be executed by the processor. The instruction set includes an SMS messaging module and a consumer registered phone opt-in management module that performs a registered phone opt-in method, the registered phone opt-in method is a step of receiving a first registered phone opt-in request including msisdn and a billing server. A step of confirming the first registered telephone opt-in with the consumer device and a step of recording the registered telephone opt-in status as active using the billing server when the first registered telephone is confirmed. The instruction set further includes a carrier billing module that executes the billing method, the billing method includes a step of receiving a billing API call from the retailer server containing at least one identifier and amount, and within the data structure. The step of determining the registered phone opt-in status corresponding to the identifier of, and when the registered phone opt-in state is active, corresponds to the amount received in the billing call without sending a text message containing the PIN code to the consumer mobile device. Includes a step of sending a billing request to the user account, including the amount to be charged, to the carrier server.

The present invention provides a transaction management method using a retail store server, the transaction management method comprising performing a registered telephone opt-in method using a retail store server, the registered telephone opt-in method at the retail store server. A step of receiving msisdn from the consumer device, a step of sending a first registered telephone opt-in request including msisdn from the retail store server to the billing server, a step of receiving a PIN code from the consumer device, and a second step including the PIN code. This method includes sending a registered telephone opt-in request from the retail store server to the billing server and receiving a response from the billing server indicating whether the PIN code has been validated or invalid at the retail store server. Further includes the step of executing the billing method using the retail store server, which comprises a billing API call containing the amount and an identifier for the billing server to determine the corresponding registered phone opt-in status, PIN code. If is verified, the retail store server sends it to the billing server, and if the PIN code is invalid, it is not sent. In the retail store server, the user account on the carrier server is charged by the billing server. Includes a step of receiving a billing result callback notification from the billing server indicating whether or not it was done.

The present invention also provides a computer-readable medium that stores an instruction set that executes a transaction management method using a retail store server when executed by a computer processor, the transaction management method using a retail store server to register telephones. The registered telephone opt-in method includes a step of receiving the msisdn from the consumer device at the retail store server and a step of transmitting a first registered telephone opt-in request including the msisdn from the retail store server to the billing server. And, the step of receiving the PIN code from the consumer device, the step of sending the second registered telephone opt-in request including the PIN code from the retail store server to the billing server, and whether the PIN code has been verified on the retail store server, or This method includes the step of receiving a response from the billing server indicating whether it is invalid, the method further includes the step of executing the billing method using the retail store server, and the billing method includes the amount and the corresponding registered telephone opt-in state. A billing API call containing an identifier for the billing server to determine 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 retail The store server includes a step of receiving a billing result callback notification from the billing server indicating whether or not the billing server has charged the user account on the telecommunications carrier server.

The present invention further provides a retail server with a processor, a computer readable medium connected to the processor, and an instruction set on the computer readable medium that can be executed by the processor, the instruction set being received by the processor. The msisdn field for entering msisdn, which can be received by the processor and sent to the billing server in the second registered phone opt-in request, is sent to the billing server in the first registered phone opt-in request. A user interface sent to a consumer device, including a PIN code field for entering a PIN code, and a continuous billing management module that executes a billing method, the billing method includes the amount and the corresponding registered phone opt-in. A step of sending a billing API call including an identifier for the billing server to determine the status from the retailer server to the billing server if the PIN code is verified, and not sending it if the PIN code is invalid. The retail store server includes a step of receiving a billing result callback notification from the billing server indicating whether or not the user account on the carrier server has been billed by the billing server.

The present invention provides a transaction management method using a retail store server, wherein the transaction management method makes a step of receiving msisdn from a consumer device on the retail store server and a first registered telephone opt-in request including msisdn at the retail store. In the step of sending from the server to the billing server, the step of receiving the PIN code from the consumer device, the step of sending the second registered telephone opt-in request including the PIN code from the retail store server to the billing server, and in the retail store server. A step to receive a response from the billing server indicating whether the PIN code is verified or invalid, and if the opt-in status is verified, the amount and the identifier for the billing server to determine the corresponding registered telephone opt-in status. When the PIN code is verified, the billing API call including is sent from the retail store server to the billing server, and when the PIN code is invalid, it is not sent. In the retail store server, the user on the carrier server Includes the step of receiving a billing result callback notification from the billing server indicating whether the account was billed by the billing server, and if the opt-in status was disabled, using the retail server to include the phone number and billing amount. The step of sending the call to the billing server, the step of sending the interface containing the PIN field to the consumer device using the retail server, and the PIN code entered by the user in the PIN code field on the retail server. It includes a receiving step, a step of transmitting a PIN code to the billing server using the retail store server, and a step of receiving a confirmation that the amount has been charged from the billing server using the retail store server.

The present invention also provides a computer-readable medium that stores an instruction set that executes a transaction management method using a retail store server when executed by a computer processor, the transaction management method from a consumer device on the retail store server. A step of receiving msisdn, a step of sending a first registered telephone opt-in request including msisdn from the retail server to the billing server, a step of receiving a PIN code from the consumer device, and a second registered telephone opt-in containing the PIN code. When the request is sent from the retail server to the billing server, the retail server receives a response from the billing server indicating whether the PIN code is validated or invalid, and the opt-in status is validated. A billing API call containing the amount and an identifier for the billing server to determine the corresponding registered phone opt-in status is sent from the retail server to the billing server if the PIN code is verified and the PIN code is invalid. In the case of not sending, the retail server receives a billing result callback notification from the billing server indicating whether the user account on the carrier server has been billed by the billing server, and the opt-in status is invalid. If so, the retail server is used to send a call containing the phone number and billing amount to the billing server, and the retail server is used to send an interface containing the PIN field to the consumer device. , In the retail server, the step of receiving the PIN code entered in the PIN code field by the user, the step of sending the PIN code to the billing server using the retail server, and the amount of money using the retail server. Includes a step of receiving a billed confirmation from the billing server.

The present invention further provides a retail store server that includes a processor, a computer-readable medium connected to the processor, and an instruction set on the computer-readable medium that can be executed by the processor. The instruction set can be received by the processor and sent to the billing server in the first registered phone opt-in request, the msisdn field for entering the msisdn, and the second registered phone opt-in request that can be received by the processor. The billing method includes a user interface sent to the consumer device, including a PIN code field for entering a PIN code sent to the billing server in, and a continuous billing management module that executes the billing method. If the opt-in status is invalid, a billing API call containing the amount and an identifier for the billing server to determine the corresponding registered phone opt-in status is issued from the retail server to the billing server if the PIN code is verified. From the billing server, a step of sending to, and not sending if the PIN code is invalid, and a billing result callback notification indicating whether or not the billing server has charged the user account on the carrier server at the retail store server. A step to receive, a step to send a call containing a phone number and a billing amount to the billing server using the retail server if the opt-in state was invalid, and an interface containing a PIN field using the retail server. To the consumer device, to receive the PIN code entered by the user in the PIN code field at the retail server, and to send the PIN code to the billing server using the retail server. This includes the step of receiving confirmation from the billing server that the amount has been charged using the retail store server.

The present invention will be further described as just one example with reference to the accompanying drawings below.

It is a block diagram of the transaction management system including a consumer mobile phone, a retail store server, a billing server and a telecommunications carrier server. It is an interaction diagram which shows how a consumer mobile phone, a retail store server, a billing server and a telecommunications carrier server interact in order to establish an opt-in of a registered telephone and a subsequent billing. A user interface screen that resides on a retail store server and is sent to a consumer mobile phone or another consumer device when the consumer chooses to pay by telephone. The billing information method used by the retail server that retrieves the billing element from the billing server, presents the user interface screen to the consumer mobile phone, and retrieves the data entered in the field corresponding to the billing factor from the consumer mobile phone. It is a flowchart which shows. FIG. 5 shows a user interface screen of FIG. 1 that prompts a consumer to enter a telephone number recorded by a retail store server to make a purchase via a billing server. A text message containing a PIN code that is received from the billing server by the consumer mobile phone after the billing server has generated the PIN code. This is the user interface screen of FIG. 1 in which the user inputs the PIN code received in the text message of FIG. 5B. This is the user interface screen of FIG. 1 after the user inputs the PIN code and the transaction is confirmed. A message received by a consumer mobile phone after the transaction is completed. It is a flowchart which shows the extended example or the modification example of the billing information method. A user interface screen that allows consumers to choose to opt in to a registered phone relationship. This is a user interface screen for consumers to enter a PIN code. FIG. 6 is a flow chart of a registered telephone opt-in method used by a retailer server to send a text message containing a PIN code to enter on the screen of FIG. 8 during a registered telephone opt-in request to a billing server. It is a user interface screen displayed on the consumer mobile phone that the PIN code is confirmed and the purchase is possible for the consumer account on the retail store server. It is a diagram showing a text message received by a consumer mobile phone, showing the success of the registered phone opt-in, disclosing the terms of the registered phone relationship, and giving the consumer instructions on how to cancel the registered phone to the retail store. It is a figure which shows the data structure for showing the active / inactive registered telephone opt-in in a billing server. It is a flowchart which shows the billing method which a retail store server instructs a billing server to charge a user account in a telecommunications carrier server. This is an exchange screen where the user selects a purchase. This is the interface screen after the consumer makes a purchase. It is a figure which shows the text message which a consumer mobile phone receives when a charge is made to a telecommunications carrier server. It is a flowchart which shows the extension of the billing method of FIG. It is an interaction diagram showing how a consumer can cancel a registered call through the interface of a retail store server. It is an interaction diagram showing a method in which a consumer can cancel a registered call by sending a text message to a billing server. It is a figure which shows the example of the text message exchanged for cancellation of registration telephone as described with reference to FIG. It is a flowchart which shows the whole function of a system. It is a block diagram which shows the smartphone function of a consumer mobile phone. It is a block diagram of a machine in the form of a computer system that forms part of a registered telephone system.

FIG. 1 of the accompanying drawing shows a registered telephone-based billing system 10 including 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 consumers 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.

At 30, the consumer mobile phone 12 opts in 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), and the retail store server 14 32 communicates to the billing server 16 a series of data that allows the billing server 16 to communicate with the consumer mobile phone 12 for the purpose of confirming the registered telephone 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 telephone opt-in by the consumer mobile phone 12, and at 36, confirms the registered telephone 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, an additional purchase charge is applied to the registered telephone opt-in, and at 39, communication is performed with the carrier server 18.

In 42, the consumer mobile phone 12 can cancel the registered telephone opt-in through the user interface 20, and as a result, the communication for canceling the registered telephone opt-in is performed in 44, and the SMS messaging module 28 responds in 46. Receive a text message. Alternatively, the consumer mobile phone 12 may at 48 send a text message to deregister the registered phone opt-in directly to the billing server 16 and then at 46, receive the text message from the SMS messaging module 28.

FIG. 2 shows 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, which is displayed on the consumer mobile phone 12.

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

In general, the inputs required to collect information from the consumer mobile phone 12 are the consumer mobile phone 12's mSISDN and network. In some countries there may be additional elements such as zip code or resident registration number. The billing information API response transmitted at 54 includes input elements required for each country and network. The billing information API response also provides a localized string that can be used as a label for these input fields.

The main text that needs to be displayed on the consumer mobile phone 12 is a country or network transaction condition string. The API returns the terms and conditions of a country and, if necessary, a network, which often varies from country to country or network. Localized text about the terms and conditions is returned with the "<string>" tag. If a country or network requires acceptance of the terms and conditions by the consumer mobile phone 12, the terms and conditions input element will be included as a check box.

表２

By default, the billing information API response returns information about all countries supported by the billing server 16. The API supports arbitrary country parameters to filter responses to specific countries. Table 1 shows the required billing information request parameters, and Table 2 shows the billing 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 the billing server 16. At 54, the billing server 16 returns an XML structure containing all required billing elements, nationally supported networks, and transaction terms strings to be displayed in each country or network. At 56, the retail store server 14 examines the <imputs> in the XML structure to determine the factors that need to be collected from the consumer. At 58, the retail store server 14 selects a <string> for labels and hints in the relevant appropriate language from the XML structure. At 60, the retail store server 14 displays the transaction terms of the selected country. At 62, the user selects a network and enters his or her mobile number. At 63, the retail store server 14 examines network-specific transaction conditions and, if found, displays them to the consumer on the consumer mobile phone 12. At 64, the retail store server 14 transmits a billing information request for a particular country to the billing server 16. At 65, the billing server 16 returns a response that includes the billing elements, networks, and terms and conditions of the particular country.

FIG. 5A shows the 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 to make a purchase via the billing server 16. FIG. 5B shows a text message containing a 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 the PIN code in the user interface. FIG. 5C shows the screen of the user interface 20 of FIG. 1 in which the user inputs the PIN code received in the text message of FIG. 5B. After that, this PIN code is 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 if verified, approves the transaction. After that, the billing server 16 communicates with the telecommunications carrier server 18 and charges the account on the telecommunications carrier server 18. FIG. 5D shows the screen of the user interface 20 of FIG. 1 after the user inputs the PIN code and the transaction is 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 of the registered telephone, the retail store server 14 and the billing server 16 bypass the message of FIG. 5A and the screen of FIG. 5E. Therefore, consumers will not be required to enter a PIN code or confirm a transaction. Instead, the consumer receives only the message as shown in FIG. 5E after making the purchase.

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

In FIG. 2 and FIG. 462, after the retailer server 14 receives data from the consumer mobile phone 12, in FIG. 272, the retailer server 14 makes a first registered telephone opt-in API call to the billing server 16. To send. This first registered telephone opt-in API call is available at https://gateway. billing server. It is submitted to the 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 telephone number on the file, and the registered telephone is so that the telephone number is automatically charged without confirmation from the consumer mobile phone 12. Obtain a registered phone opt-in 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 a consumer to tailor a consumer's registered phone to a specific set of conditions with a retailer (eg, $ 100 or 90 sunrise costs). Will be done. For example, if a retailer offers a registered phone opt-in, this method is used to obtain a consumer registered phone opt-in that confirms the consumer's registered phone approval and requires the retailer to provide: Will be done.
-Consumer-id (consumer ID) (consumer's unique identifier)
・ MSISDN (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 the registered telephone opt-in.
-Country- and network-specific rules-Rules that apply to a single retail store-Rules that set time-based limits such as 90 days-Rules that set spending-based limits such as 100 USD-mSISdn opt-in for individual mSISDN Rule to block by level (blacklist to register registered phones)

FIG. 7 shows a screen of user interface 20 prompting a consumer to opt in to a registered telephone relationship by selecting a checkbox after completing a transaction. Consumers can also hover their mouse over "Details" to receive terms and conditions as shown at the bottom of FIG. 5D. Consumers opt in to a registered telephone relationship and limit purchases for this opt-in to a maximum of $ 100 or 90 sunrises.

Referring to FIG. 2 again, the billing server 16 generates a unique PIN code, and in 76 of FIG. 2, the PIN code is transmitted to the consumer mobile phone 12 by text message, and 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 into 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 the msisdn and consumer-id (consumer ID) are registered in the first registration on the billing server 16. The second registered telephone opt-in request is sent to the same URL as the telephone opt-in request. After that, the billing server 16 verifies and confirms the PIN code received from the retail store server 14 at 80 against the PIN code transmitted by text message at 74, and returns a response to the retail store server 14. Each of the billing server 16 and the retail store server 14 records or stores the result of the consumer's registered telephone 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 transmitted in 72 and 80 of FIG. Tables 4 and 5 show the parameters of the registered telephone opt-in response 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 containing the values of mSISDN, 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 (under verification) is returned. Otherwise, a new PIN code is generated and VERIFICATION IN PROGRESS (under verification) is returned. In 74 of FIG. 2, the billing server 16 sends a country-appropriate message to the consumer mobile phone 12, including a PIN code, a registered telephone relationship (eg, $ 100 or 30 days of consent).

At 86, the retail store server 14 collects the PIN code transmitted in 78 of FIG. 2 and transmits the registered telephone opt-in request including the acquired PIN code at 80 of FIG. If the submitted PIN code is correct, VERIFIDE will be returned and the billing server 16 will send a confirmation message containing the terms of the registered phone opt-in, the purchased item and the STOP command (to unsubscribe through SMS). It is transmitted to the consumer mobile phone 12. Otherwise, an INVALID PIN (invalid PIN) is returned. The PIN code can only be entered three times (or any other limited number of trials).

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 is returned.

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

The method using PIN code confirmation shown in steps 72 to 90 is one method of verifying the opt-in of the registered telephone with the consumer device and recording the status of the registered telephone as active (or inactive). .. For example, another method of handshaking a mobile device, such as sending an SMS text message to the mobile device and then waiting for the consumer to respond "Y" or "Yes" in the response text message. Can include use. Alternatively, the retail server can host the payment panel and the billing server can communicate with the user device through the payment panel to confirm the opt-in request.

FIG. 12 shows the 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), mSISDN and consumer-id (consumer ID). In this data structure, consumers are effectively identified through a combination of mSISDN and consumer-id (consumer ID). This data structure supports use cases that can be billed to multiple consumers using mSISDN. For example, a child may use the parent's phone number as the billing mSISDN. However, each child and its parent has a unique consumer-id with a given retailer. This data structure holds the opt-in state along with the date and time of the last state change. Use this date and time to assess whether the status of the registered phone has expired at the time of the consumer's purchase. The data structure also holds data on cumulative spending by consumers. This data is used to determine if the registered telephone opt-in has expired due to exceeding the specified spending threshold. Data on cumulative spending on registered phones can also be included in purchase receipts sent to consumers.

Referring again to FIG. 2, when the consumer makes a purchase at the retail store server 14, the retail store server 14 makes a billing API call at 98 requesting payment processing in one step from the consumer mobile phone 12. Send to the billing server 16. The billing API call is submitted to the dedicated URL of the billing server 16. Billing methods that support one-time payment scenarios can be used. The billing server 16 determines whether there is a corresponding consumer registration phone opt-in in the active state, depending on the merchant-id (retail store ID), mSISDN and consumer-id (consumer ID) values 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 re-executes the steps described with reference to FIGS. 5A-5E to perform PIN code verification.

When the billing request is approved, the charge-id (billing 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 validated, submitted to carrier server 18 for processing at 100 in FIG. 2, and has a valid response from carrier server 18 at 102. A risk check has already been performed by the billing server 16 before submitting the bill to the carrier server 18 for processing.

Billing is an asynchronous request. When the billing request is completed, the billing server 16 receives the billing result from the carrier server 18 and sends a callback notification to the retailer server 14 including the final result of the billing attempt, regardless of the success or failure of the billing. 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 you make two billing requests with the request-id (request ID) of the same retail store, the user's account will be billed only once and both requests will 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 complete 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 billing result callbacks for the same transaction multiple times. A common cause of continuous retry of callback notifications is an improper 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 by a validation error or risk check, the billing server 16 does not submit a processing request to the carrier server 18, so the billing server 16 sends a callback notification to the retail server 14. There is no.

表１０

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

Table 10

FIG. 13 shows an example of a billing method. In 106, the consumer of the consumer mobile phone 12 or other consumer device 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 that includes a customer-id (customer ID), mSISDN, network, and purchase details. At 112, the billing server 16 performs registered phone limits, spending limits, speed checks and other consumer protection checks. If the registered phone restriction fails, the consumer is required to renew the registered phone opt-in for his registered phone at 114. If the expense or speed check fails, or if mSISDN is blacklisted, the billing request fails at 116 and an appropriate error message is returned. At 118, the billing server 16 detects the carrier (using the provided network, or search if the network is not 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 in the billing result callback notification. Then, at 120 in FIG. 2, the SMS module sends a text message confirming the purchase to the consumer mobile phone 12.

As described above, as shown in 74 of FIG. 2, the billing is processed without communicating with the consumer mobile phone 12. However, when 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 in 74 in FIG. 2, and steps up to step 90 in FIG. Repeat.

FIG. 14A is an exchange screen in which the user selects a purchase. FIG. 14B is an interface screen after the consumer makes a purchase.

FIG. 15 shows an extension of the billing flow method of FIG. Suppose the billing request fails at 122. At 124, the retail store server 14 submits a billing request with a new request-id (request ID) and retries billing. When billing is retried with the request-id (request ID) that failed last time, the billing server 16 returns the same failure response due to idempotency. At 126, the billing server 16 charges the consumer's account using the 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 the parameters of the billing result callback notification.
Table 11

Table 12

FIG. 16 shows how the consumer mobile phone 12, with reference to FIG. 1, cancels the registered phone opt-in via the user interface 20. In 42 of FIG. 18, the consumer mobile phone 12 releases from the retail store server 14 using the user interface 20 of FIG. 1 of the retail store server 14. At 44, the retail store server 14 submits a registration telephone opt-in cancellation API call at the dedicated URL of the billing server 16 to register corresponding to merchant-id (retail store ID), msisdn and consumer-id (consumer ID). Notify the billing server 16 that the telephone opt-in is canceled. At 130, the billing server 16 deopters of the consumer registration phone and updates the relevant opt-in entry of FIG. 12 as inactive. A text to the consumer mobile phone 12 if additional charges for this merchant-id (retail store ID), mSISDN and consumer-id (consumer ID) are submitted by the retail store server 14 to the billing server 16. Confirmed through a message. At 132, the retail store server 14 updates the user interface 20 to reflect that the registered telephone opt-in has been canceled.

FIG. 17 shows how a consumer deactivates a registered phone opt-in through text messaging with reference to FIG. At 48, the consumer mobile phone 12 transmits 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 cancels the registered telephone opt-in and updates the relevant opt-in entry of FIG. 12 as inactive. If additional charges for the merchant-id (retail store ID), mSISDN and consumer-id (consumer ID) are submitted by the retail store server 14, they will be confirmed through a text message with the consumer mobile phone 12. At 46, the billing server 16 sends a confirmation of the release SMS text to the consumer mobile phone 12. At 136, the billing server 16 sends a consumer registration phone opt-in cancellation notification to the retail store server 14 so that the retail store server 14 cancels the registered phone relationship.

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

FIG. 19 shows how the procedure described so far is repeated. At 200, the first purchase is completed using PIN code verification. At 202, the registration 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 in 206 that a registered telephone opt-in exists, then in 208 the purchase is completed without PIN code verification. If the next purchase exists, start the next purchase at 204.

If it is determined in 206 that the registered phone opt-in does not exist, the purchase is completed in 200 and the registered phone opt-in procedure is performed in 202.

The present invention further provides a way for consumers to renew their registered telephone opt-ins and retailers to remind consumers of registered telephone opt-ins that require renewal. Consumers can update their registered phone using the steps outlined herein. Another way for consumers to update their registered phone is through SMS-only interaction, where consumers can update their registered phone with a reply to the SMS sent by the system. 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 registered phone expires). The retail server can communicate with the billing server to obtain data about registered phone opt-ins that need to be renewed based on spending or time limits in order to remind consumers before they expire. This allows retailers to send pre-expiration notices urging consumers to renew their registered phone opt-ins.

Retailers can also be given the ability to check when an opt-in expires, for example within 10 days or for a particular additional expense.

FIG. 20 is a block diagram showing a consumer mobile phone 12 showing a touch sensor 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 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 and software combinations, including hardware, software, or one or more signal processing and / or application-specific integrated circuits.

The memory 1020 can include high speed random access memory and can also include one or more non-volatile memories such as 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 peripheral interface 1180, is controlled by the memory controller 1220.

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

The 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 identification module (SIM) card and memory, and the like. Includes well-known circuits for performing the functions of. The RF circuit 1080 includes networks such as the Internet and intranets, also known as World Wide Web (WWW), and / or wireless networks such as cellular telephone networks, wireless local area networks (LANs) and / or metropolitan area networks (MANs). It can 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.

The audio circuit 1100, the speaker 1110 and the microphone 1130 provide an audio interface between the user and the 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 electrical signal into a sound wave that can be heard by humans. The audio circuit 1100 also receives an electrical signal converted from sound waves by the microphone 1130. The audio circuit 1100 converts the electrical signal into audio data and transmits the audio data to the peripheral interface 1180 for processing. The audio circuit 1100 includes the audio circuit 1100 and removable audio input / output peripherals such as output-only headphones or a headset with both outputs (eg, one-ear or binaural headphones) and inputs (eg, microphones). It also includes a headphone jack that acts as an interface between.

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 peripheral interface 1180. The I / O subsystem 1060 includes a display controller 1560 and one or more input controllers 1600 for other inputs or controls. 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 pointer device such as a keyboard, infrared port, USB port, and mouse. One or more buttons may include up / down buttons for volume control of the speaker 1110 and / or microphone 1130. One or more buttons may include push buttons. By pressing the push button quickly, the process of unlocking the touch screen 1120 or unlocking the device using gestures on the touch screen can be initiated. Press and hold the push button to turn 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 sensor type touch screen 1120 provides an input interface and an output interface between the device and the user. The display controller 1560 transmits and receives an electric signal to and from the touch screen 1120. The touch screen 1120 displays a 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.

The touch screen 1120 comprises a touch sensitive surface, a sensor, or a set of sensors that accept input from the user based on tactile and / or tactile contact. The touch screen 1120 and the display controller 1560 (and any relevant module and / or instruction set in memory 1020) detect a contact (and any contact movement or interruption) on the touch screen 1120 and this detected contact. Is transformed into an interaction with a user interface object (eg, one or more softkeys, icons, web pages or images) displayed on the touch screen. In an exemplary embodiment, the point of contact between the 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, but other display technologies can be used in other embodiments. The touch screen 1120 and display controller 1560 are, 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. Contact and any movement or interruption thereof can be detected using any of a number of contact sensing techniques currently known or developed in the future, including other elements for identifying.

The user can make contact with the touch screen 1120 using any suitable object or accessory such as a stylus and a finger. In some embodiments, the user interface is designed to work primarily with finger touches and gestures, which are significantly more than stylus-based inputs due to the wide range of finger touches on the touch screen. The accuracy drops. In some embodiments, the device translates a rough finger input into a precise pointer / cursor position, or a 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 is a power management system, one or more power sources (eg, battery, alternating current (AC)), charging system, power fault detection circuit, power converter or inverter, power status indicator (eg, light emitting diode (LED)). ), And any other component related to the generation, management and distribution of power in the portable device.

The software components stored in memory 1020 are operating system 1260, communication module (or instruction set) 1280, contact / motion module (or instruction set) 1300, graphics module (or instruction set) 1320, text input module (or instruction set). Includes 1340 (set) and 1360 application (or instruction set).

Operating systems 1260 (eg, embedded operating systems such as Darwin, RTXC, LINUX®, UNIX®, OS X, WINDOWS®, or VxWorks) are common system tasks (eg, memory). Includes software components and / or drivers for controlling and managing management, storage control, power management, etc.) to facilitate communication between various hardware and software components.

Communication module 1280 facilitates communication with other devices via one or more external ports 1240 and also includes various software components for processing the data received by the RF circuit 1080 and / or external port 1240. .. External ports 1240 (eg, Universal Serial Bus (USB), IEEE®, etc.) are adapted to be coupled directly to other devices or indirectly via a network (eg, Internet, WiFi, etc.). Will be done.

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

The graphics module 1320 includes various known software components for rendering and displaying graphics on the touch screen 1120, including components for varying the intensity 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 and animations.

The text input module 1340, which can be a component of the graphics module 1320, can be used in a variety of 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 mobile application 208.

FIG. 21 is a schematic representation of a machine in the exemplary form of a computer system 900 capable of internally executing an instruction set 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 connect to other machines (eg, network connections). In network deployments, 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), tablet PC, set-top box (STB), personal digital assistant (PDA), mobile phone, web appliance, network router, switch or bridge, or what the machine should do. It can be any machine capable of executing an instruction set (sequential or otherwise). Further, although referring to only one machine, the term "machine" individually or sets instructions (or multiple sets) for performing any one or more of the methods described herein. It should be interpreted as including any group of machines that run together.

An exemplary computer system 900 includes a processor 930 (eg, central processing unit (CPU)), graphics processor (GPU), or both) and main memory 932 (eg, read-only memory (ROM), flash. Includes memory, dynamic random access memory (DRAM) such as synchronous DRAM (CPU) 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.

The 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 can also include an alphanumeric input device 940 (eg keyboard), a cursor control device 942 (eg mouse), a disk drive unit 944, a signal generator 946 (eg 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 be present entirely or at least partially in the main memory 932 and / or in the processor 930 during execution by the computer system 900, and the memory 932 and the processor 930 may also 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 embodiments indicate that the instruction 952 resides on a single medium, the term "machine readable medium" refers to a single medium or a single medium that stores one or more instruction sets. It should be interpreted 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" is any medium that allows a machine to perform any one or more of the methods herein that can store, encode, or convey a set of instructions that the machine executes. Should be interpreted as including. Therefore, the term "machine readable medium" should be construed to include, but is not limited to, solid-state memory, optical and magnetic media.

Although some exemplary embodiments have been described and shown in the accompanying drawings, such embodiments are not limited to the present invention and are merely exemplary, and those skilled in the art will likely come up with modifications. Therefore, it should be understood that the present invention is not limited to the specific configurations and arrangements illustrated and described.

10 Billing system 12 Consumer mobile phone 14 Retail store server 16 Billing server 18 Carrier server 20 (for consumers to manage purchase / registered phone) User interface 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 the box to register on the registered phone at the time of purchase 32 Consumer opt-in to the registered phone 34 Opt-in message for registered phone conditions 36 For registered phone billing Confirmation message 38 Initial charge for registered phone 39 Communication 40 Charge for additional purchase 42 Cancel subscription 44 Cancel opt-in to registered phone 46 Confirm STOP cancellation 48 Cancel registered phone opt-in through STOP

Claims (12)

A transaction management method executed by the billing server
In the billing server, a step of receiving a first registered telephone opt-in request including mSISDN, which is an identifier that identifies a consumer ,
A step of confirming the registered telephone opt- in corresponding to the identifier that identifies the consumer based on the first registered telephone opt-in request using the billing server.
When the registered telephone opt-in is confirmed, the step of recording the registered telephone opt-in status as active using the billing server, and
A step of receiving a billing API call from a retail store server that includes at least one identifier and an amount including an identifier that identifies the consumer at the billing server.
A step of determining the registered telephone opt-in status corresponding to the consumer-identifying identifier in the billing server, and
When the registered telephone opt-in state is active, the consumer is identified, including the amount corresponding to the amount received in the billing API call, without sending a text message containing the PIN code to the consumer mobile device. The step of sending a billing request to the user account corresponding to the identifier to the carrier server,
A method characterized by including. The confirmation and the record
The step of generating a PIN code using the billing server and
A step of transmitting a text message including the PIN code to the consumer mobile phone in the mSISDN using the billing server, and
The step of receiving a second registered telephone opt-in request including a PIN code at the billing server,
A step of verifying the PIN code received in the second registered telephone opt-in request in the billing server against the PIN code transmitted by the text message.
If the PIN code is verified, the billing server includes a step of recording the registered phone opt-in state for the mSISDN as active in the data structure.
The method according to claim 1. The first registered telephone opt-in request includes a merchant-id (retail store ID), and the registered telephone opt-in state is recorded as active in the light of the merchant-id (retail store ID).
The method according to claim 1 or 2. The mSISDN includes a plurality of merchant-ids (retailer IDs), each having a separate registered telephone opt-in parameter that is selectively set to active or inactive.
The method according to claim 3. Before receiving the first registered telephone opt-in request at the billing server
A step of transmitting a text message including a PIN code generated by the billing server to the consumer mobile device using the billing server.
In the billing server, the step of receiving the PIN code from the retail store server and the PIN code received from the retail store server using the billing server are compared with the PIN code transmitted to the consumer portable device. Steps to verify and
When the PIN code is verified, the step of communicating with the telecommunications carrier server using the billing server and charging the telecommunications carrier server for the amount of money,
Including,
The method according to any one of claims 1 to 4. If it is determined that the registered telephone opt-in is invalid,
A step of transmitting a text message including a PIN code generated by the billing server to the consumer mobile device using the billing server.
In the billing server, the step of receiving the PIN code from the retail store server and the PIN code received from the retail store server using the billing server are compared with the PIN code transmitted to the consumer portable device. Steps to verify and
When the PIN code is verified, the step of communicating with the telecommunications carrier server using the billing server and charging the telecommunications carrier server for the amount of money,
Including,
The method according to claim 1 . In the billing server, the step of receiving the call to cancel the subscription, and
In response to the call to unsubscribe, the step of inactively updating the registered telephone opt-in state for the mSISDN, and
Including,
The method according to any one of claims 1 to 6. The call to cancel the registered phone opt-in takes the form of a text message from a consumer mobile phone on the mSISDN.
The method according to claim 7. The call for canceling the registered telephone opt-in is received at the billing server via the registered telephone opt-in canceling API from the retail store server.
The method according to claim 7 or 8. A computer-readable medium that stores an instruction set that executes a transaction management method using a billing server when executed by a computer processor, said transaction management method.
In the billing server, a step of receiving a first registered telephone opt-in request including mSISDN, which is an identifier that identifies a consumer ,
A step of confirming the registered telephone opt- in corresponding to the identifier that identifies the consumer based on the first registered telephone opt-in request using the billing server.
When the registered telephone opt-in is confirmed, the step of recording the registered telephone opt-in status as active using the billing server, and
A step of receiving a billing API call from a retail store server that includes at least one identifier and an amount including an identifier that identifies the consumer at the billing server.
A step of determining the registered telephone opt-in status corresponding to the consumer-identifying identifier in the billing server, and
When the registered telephone opt-in state is active, the consumer is identified, including the amount corresponding to the amount received in the billing API call, without sending a text message containing the PIN code to the consumer mobile device. The step of sending a billing request to the user account corresponding to the identifier to the carrier server,
including,
A computer-readable medium characterized by that. With the processor
A computer-readable medium connected to the processor,
An instruction set on the computer-readable medium that can be executed by the processor.
The instruction set is a billing server.
SMS messaging module and
With the Consumer Registered Phone Opt-in Management Module, which performs the Registered Phone Opt-in Method,
The above-mentioned registered telephone opt-in method includes
The step of receiving a first registered telephone opt-in request containing the consumer-identifying identifier mSISDN, and
A step of confirming the registered telephone opt- in corresponding to the identifier that identifies the consumer based on the first registered telephone opt-in request using the billing server.
When the registered telephone opt-in is confirmed, the step of recording the registered telephone opt-in status as active using the billing server, and
The instruction set includes
Carrier billing module, which executes the billing method,
The billing method further includes
A step of receiving a billing API call from a retail store server that includes at least one identifier and an amount that includes an identifier that identifies the consumer .
The step of determining the registered telephone opt-in status corresponding to the consumer-identifying identifier in the data structure,
When the registered telephone opt-in state is active, the consumer is identified, including the amount corresponding to the amount received in the billing API call, without sending a text message containing the PIN code to the consumer mobile device. The step of sending a billing request to the user account corresponding to the identifier to the carrier server,
including,
A billing server that features that. The consumer registration telephone opt-in management module
Steps to generate a PIN code and
A step of sending a text message containing the PIN code to a consumer mobile phone in the mSISDN using an SMS messaging module, and
Steps to receive a second registered phone opt-in request containing a PIN code,
A step of verifying the PIN code received in the second registration telephone opt-in request against the PIN code transmitted in the text message, and
If the PIN code is verified, the step of recording the registered phone opt-in state for the mSISDN as active in the data structure and
including,
The billing server according to claim 11.

Images