Patent Application
20140279455
1). Field of the Invention
This invention relates to a system and method for managing subscriptions in a scenario where a merchant server repeatedly instructs a billing server to charge a user account at a carrier server.
2). Discussion of Related Art
A consumer who shops for goods or services online may often be given the option to use a selection of payment sources during checkout, such as payment by credit card, debit card, payment from an account held by an institution, or to charge for a purchase on their phone bill. When the consumer selects to charge to their phone bill, a merchant server instructs a billing server which is aligned with a carrier server to carry out the charge. The billing server usually communicates with a consumer mobile phone to confirm the charge before placing the charge on the phone bill at the carrier server.
Consumers also purchase subscriptions online, typically for services such as music or movies, and then make repeat payments on a monthly or other billing cycle. These subscriptions are usually charged directly to a credit card account held by a financial institution. Repeated communications with the consumer to confirm each renewal charge is not required in such a situation. However, if such a charge would be submitted by a merchant server to a carrier server, the carrier server typically has a requirement to confirm the charge with the consumer mobile phone. A billing cycle may go by wherein the consumer has neglected to confirm the charge, in which case the subscription would be lost to the merchant.
The invention provides a method of managing subscriptions with a billing server including a) executing an opt-in method with the billing server, including receiving a first opt-in request at the billing server including a msisdn, generating, with the billing server, a PIN code, transmitting, with the billing server, a text message to a consumer mobile phone at the msisdn with the PIN code, receiving a second opt-in request at the billing server, including a PIN code, verifying, at the billing server, the PIN code received in the second opt-in request against the PIN code transmitted in the text message and recording, at the billing server, an opt-in status as active for the msisdn within the data structure if the PIN code is verified, and b) executing a charge method with the billing server including, receiving, at the billing server, a charge API call from a merchant server at the billing server, including at least one identifier and an amount, determining an opt-in status corresponding to the identifier at the billing server, and transmitting a request to charge a user account to a carrier server if the opt-in status is active, but not if the opt-in status is inactive, the request including an amount corresponding to the amount received in the charge API call.
The invention also provides a computer-readable medium having stored thereon a set of instructions which, when executed by a processor of a computer performs a method of managing subscriptions with a billing server including a) executing an opt-in method with the billing server, including receiving a first opt-in request at the billing server including a msisdn, generating, with the billing server, a PIN code, transmitting, with the billing server, a text message to a consumer mobile phone at the msisdn with the PIN code, receiving a second opt-in request at the billing server, including a PIN code, verifying, at the billing server, the PIN code received in the second opt-in request against the PIN code transmitted in the text message, and recording, at the billing server, an opt-in status as active for the msisdn within a data structure if the PIN code is verified, and b) executing a charge method with the billing server including receiving, at the billing server, a charge API call from a merchant server at the billing server, including at least one identifier and an amount, determining an opt-in status corresponding to the identifier within the data structure at the billing server, and transmitting a request to charge a user account to a carrier server if the opt-in status is active, but not if the opt-in status is inactive, the request including an amount corresponding to the amount received in the charge API call.
The invention further provides a billing server including a processor, a computer-readable medium connected to the processor and a set of instructions on the computer-readable medium and executable by the processor. The set of instructions includes an SMS messaging module, a consumer opt-in management module executing an opt-in method including receiving a first opt-in request including a msisdn, generating a PIN code, transmitting, using the SMS messaging module, a text message to a consumer mobile phone at the msisdn with the PIN code, receiving a second opt-in request including a PIN code, verifying the PIN code received in the second opt-in request against the PIN code transmitted in the text message, and recording an opt-in status as active within a data structure for the msisdn if the PIN code is verified. The set of instructions also includes a carrier billing module executing a charge method including receiving a charge API call from a merchant server, including at least one identifier and an amount, determining an opt-in status corresponding to the identifier in the data structure, and transmitting a request to charge a user account to a carrier server if the opt-in status is active, but not if the opt-in status is inactive, the request including an amount corresponding to the amount received in the charge API call.
The invention is further described by way of example with reference to the accompanying drawings, wherein:
The consumer mobile phone 12 communicates with the merchant server 14 at 30 through the user interface 20 to opt-in to a subscription and the merchant server 14 communicates with the billing server 16 at 32 with a set of data that allows the billing server 16 to communicate with the consumer mobile phone 12 for purposes of confirming opt-in by the consumer mobile phone 12. At 34 the SMS messaging module 28 communicates via text messaging with the consumer mobile phone 12 to confirm opt-in by the consumer mobile phone 12 and at 36 transmits a text message confirming opt-in by the consumer. At 38 the recurring billing management module 22 initiates a charge through the carrier billing module 26. At 39 the carrier billing module 29 attempts to place the charge on an account corresponding to a phone number of the consumer mobile phone 12 on the carrier server 18. At 40 renewal charges are applied for the subscription and at 39 are communicated to the carrier server 18.
At 42 the consumer mobile phone 12 can cancel the subscription through the user interface 20, which results in a communication at 44 to cancel opt-in and receive a corresponding text message at 46 from the SMS messaging module 28. Alternatively, the consumer mobile phone 12 can at 48 send a text message directly to the billing server 16 to cancel the subscription and then receive the text message at 46 from the SMS messaging module 28.
Referring again to
In general, the mobile subscriber integrated services digital network number (msisdn) and the network of the consumer mobile phone 12 are required inputs to collect from the consumer mobile phone 12. In some countries there can be additional elements such as a zip code or a resident registration number. A charge-info API response transmitted at 54 contains the input elements required for each country and network. The charge-info API response also supplies localized strings that can be used as labels for these input fields.
The primary text that needs to be displayed to the consumer mobile phone 12 are the terms and conditions strings for the country or network. The API returns a terms-and-conditions element for the country and, if required, for the network as well and are in many cases different for different countries or networks. The localized text for the terms and conditions is returned in ‘<string>’ tags. If a country or network requires that the consumer mobile phone 12 accept terms and conditions, a terms and conditions input element will be included as a checkbox.
By default, the charge-info API response returns information regarding all countries that the billing server 16 supports. The API supports an optional country parameter to filter the response to a specific country. Table 1 shows the charge-info request parameters that are required and Table 2 shows the charge-info response parameters.
The following is an example of strings in a charge-info response to a charge-info request:
An example of the charge-info method is illustrated in
After the merchant server 14 receives the data from the consumer mobile phone 12 at 62 in
The opt-in method, on the billing server 16, generates and at 74 in
At 76 in
Table 3 shows the opt-in request parameters that are transmitted at 72 and 80 in
An example of the opt-in method is illustrated in
At 86, the merchant server 14 collects the PIN code at 78 in
At 88, the merchant server 14 collects PIN code after 24 hours and sends an opt-in request containing the PIN. If PIN code is expired, then PIN EXPIRED is returned.
Referring again to
Table 6 shows parameters for the remind-charge API call at 90 in
Referring again to
If the charge request is accepted, a charge-id is returned from the billing server 16 to the merchant server 14 at 104 in
Charge is an asynchronous request. When the charge request has been completed, regardless of a successful or failed charge, the billing server 16, having received the charge result from the carrier server 18, sends a callback notification to the merchant server 14 with the final result of the charge attempt.
The charge request is idempotent. Each request is uniquely identified by the request-id supplied by the merchant server 14. For example, if two charge requests are made with the same merchant request-id, the user's account is charged only once and both charge requests receive the same response.
A chargeresult callback notification provides the final status of a transaction (success or failure) successfully billed chargeresult callback notifications are used by the merchant server 14 to fulfill purchases. For a given transaction, identified by the unique charge-id field value, fulfillment occurs only once. The merchant server 14 may receive a chargeresult callback for the same transaction multiple times if there are communication issues between the billing server 16 and the merchant server 14. Improper acknowledgement responses (ACKs) from the merchant server 14 to the billing server 16 is a common cause of continually retried callback notifications.
The merchant server 14 only receives callbacks from the billing server 16 for requests that have been accepted. If a request was not accepted due to a validation error or due to a risk check, the billing server 16 does not submit the request to the carrier server 18 for processing and therefore callback notification is not sent from the billing server 16 to the merchant server 14.
Table 9 shows parameters for the charge request at 98 in
The SMS messaging module 28 then at 120 in
Tables 11 and 12 show parameters for a chargeresult callback notification.
The various components shown in
The memory 1020 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic disk storage devices, flash memory devices, or other non-volatile solid-state memory devices. Access to the memory 1020 by other components of the consumer mobile phone 12, such as the CPU 1200 and the peripherals interface 1180, is controlled by the memory controller 1220.
The peripherals interface 1180 connects the input and output peripherals of the device to the CPU 1200 and memory 1020. The one or more processors 1200 run or execute various software programs and/or sets of instructions stored in the memory 1020 to perform various functions for the consumer mobile phone 12 and to process data.
The RF (radio frequency) circuitry 1080 receives and sends RF signals, also called electromagnetic signals. The RF circuitry 1080 converts electrical signals to/from electromagnetic signals and communicates with communications networks and other communications devices via the electromagnetic signals. The RF circuitry 1080 includes well-known circuitry for performing these functions, including an antenna system, an RF transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a CODEC chipset, a subscriber identity module (SIM) card, memory, and so forth. The RF circuitry 1080 may communicate with networks, such as the Internet, also referred to as the World Wide Web (WWW), an intranet and/or a wireless network, such as a cellular telephone network, a wireless local area network (LAN) and/or a metropolitan area network (MAN), and other devices by wireless communication. The wireless communication may use any of a plurality of communications standards, protocols and technologies that are known in the art.
The audio circuitry 1100, the speaker 1110, and the microphone 1130 provide an audio interface between a user and the consumer mobile phone 12. The audio circuitry 1100 receives audio data from the peripherals interface 1180, converts the audio data to an electrical signal, and transmits the electrical signal to the speaker 1110. The speaker 1110 converts the electrical signal to human-audible sound waves. The audio circuitry 1100 also receives electrical signals converted by the microphone 1130 from sound waves. The audio circuitry 1100 converts the electrical signal to audio data and transmits the audio data to the peripherals interface 1180 for processing. The audio circuitry 1100 also includes a headset jack serving as an interface between the audio circuitry 1100 and removable audio input/output peripherals, such as output-only headphones or a headset with both output (e.g., a headphone for one or both ears) and input (e.g., a microphone).
The I/O subsystem 1060 connects input/output peripherals on the consumer mobile phone 12, such as the touch screen 1120 and other input/control devices 1160, to the peripherals interface 1180. The I/O subsystem 1060 includes a display controller 1560 and one or more input controllers 1600 for other input or control devices. The one or more input controllers 1600 receive/send electrical signals from/to other input or control devices 1160. The other input/control devices 1160 may include physical buttons (e.g., push buttons, rocker buttons, etc.), dials, slider switches, joysticks, click wheels, and so forth all serving as forming part of an interface. The input controllers 1600 may be connected to any of the following: a keyboard, infrared port, USB port, and a pointer device such as a mouse. The one or more buttons may include an up/down button for volume control of the speaker 1110 and/or the microphone 1130. The one or more buttons may include a push button. A quick press of the push button may disengage a lock of the touch screen 1120 or begin a process that uses gestures on the touch screen to unlock the device. A longer press of the push button may turn power to the consumer mobile phone 12 on or off. The touch screen 1120 is used to implement virtual or soft buttons and one or more soft keyboards.
The touch-sensitive touch screen 1120 provides an input interface and an output interface between the device and a user. The display controller 1560 receives and/or sends electrical signals from/to the touch screen 1120. The touch screen 1120 displays visual output to the user. The visual output may include graphics, text, icons, video, and any combination thereof (collectively termed “graphics”). In some embodiments, some or all of the visual output may correspond to user-interface objects, further details of which are described below.
A touch screen 1120 has a touch-sensitive surface, sensor or set of sensors that accepts input from the user based on haptic and/or tactile contact. The touch screen 1120 and the display controller 1560 (along with any associated modules and/or sets of instructions in memory 1020) detect contact (and any movement or breaking of the contact) on the touch screen 1120 and converts the detected contact into interaction with user-interface objects (e.g., one or more soft keys, icons, web pages or images) that are displayed on the touch screen. In an exemplary embodiment, a point of contact between a touch screen 1120 and the user corresponds to a finger of the user.
The touch screen 1120 may use LCD (liquid crystal display) technology, or LPD (light emitting polymer display) technology, although other display technologies may be used in other embodiments. The touch screen 1120 and the display controller 1560 may detect contact and any movement or breaking thereof using any of a plurality of touch sensing technologies now known or later developed, including but not limited to capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with a touch screen 1120.
The user may make contact with the touch screen 1120 using any suitable object or appendage, such as a stylus, a finger, and so forth. In some embodiments, the user interface is designed to work primarily with finger-based contacts and gestures, which are much less precise than stylus-based input due to the larger area of contact of a finger on the touch screen. In some embodiments, the device translates the rough finger-based input into a precise pointer/cursor position or command for performing the actions desired by the user.
The consumer mobile phone 12 also includes a power system 1620 for powering the various components. The power system 1620 may include a power management system, one or more power sources (e.g., battery, alternating current (AC)), a recharging system, a power failure detection circuit, a power converter or inverter, a power status indicator (e.g., a light-emitting diode (LED)) and any other components associated with the generation, management and distribution of power in portable devices.
The software components stored in memory 1020 include an operating system 1260, a communication module (or set of instructions) 1280, a contact/motion module (or set of instructions) 1300, a graphics module (or set of instructions) 1320, a text input module (or set of instructions) 1340, and applications (or set of instructions) 1360.
The operating system 1260 (e.g., Darwin, RTXC, LINUX, UNIX, OS X, WINDOWS, or an embedded operating system such as VxWorks) includes various software components and/or drivers for controlling and managing general system tasks (e.g., memory management, storage device control, power management, etc.) and facilitates communication between various hardware and software components.
The communication module 1280 facilitates communication with other devices over one or more external ports 1240 and also includes various software components for handling data received by the RF circuitry 1080 and/or the external port 1240. The external port 1240 (e.g., Universal Serial Bus (USB), FIREWIRE, etc.) is adapted for coupling directly to other devices or indirectly over a network (e.g., the Internet, wireless LAN, etc.).
The contact/motion module 1300 may detect contact with the touch screen 1120 (in conjunction with the display controller 1560) and other touch sensitive devices (e.g., a touchpad or physical click wheel). The contact/motion module 1300 includes various software components for performing various operations related to detection of contact, such as determining if contact has occurred, determining if there is movement of the contact and tracking the movement across the touch screen 1120, and determining if the contact has been broken (i.e., if the contact has ceased). Determining movement of the point of contact may include determining speed (magnitude), velocity (magnitude and direction), and/or an acceleration (a change in magnitude and/or direction) of the point of contact. These operations may be applied to single contacts (e.g., one finger contacts) or to multiple simultaneous contacts (e.g., “multitouch”/multiple finger contacts). The contact/motion module 1300 and the display controller 1560 also detects contact on a touchpad.
The graphics module 1320 includes various known software components for rendering and displaying graphics on the touch screen 1120, including components for changing the intensity of graphics that are displayed. As used herein, the term “graphics” includes any object that can be displayed to a user, including text, web pages, icons (such as user-interface objects including soft keys), digital images, videos, animations and the like.
The text input module 1340, which may be a component of graphics module 1320, provides soft keyboards for entering text in various applications (e.g., contacts, e-mail, IM, blogging, browser, and any other application that needs text input). The applications 1360 may include the mobile application 208.
The exemplary computer system 900 includes a processor 930 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory 932 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), and a static memory 934 (e.g., flash memory, static random access memory (SRAM, etc.), which communicate with each other via a bus 936.
The computer system 900 may further include a video display 938 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 900 also includes an alpha-numeric input device 940 (e.g., a keyboard), a cursor control device 942 (e.g., a mouse), a disk drive unit 944, a signal generation device 946 (e.g., a speaker), and a network interface device 948.
The disk drive unit 944 includes a machine-readable medium 950 on which is stored one or more sets of instructions 952 (e.g., software) embodying any one or more of the methodologies or functions described herein. The software may also reside, completely or at least partially, within the main memory 932 and/or within the processor 930 during execution thereof by the computer system 900, the memory 932 and the processor 930 also constituting machine readable media. The software may further be transmitted or received over a network 954 via the network interface device 948.
While the instructions 952 are shown in an exemplary embodiment to be on a single medium, the term “machine-readable medium” should be taken to understand a single medium or multiple media (e.g., a centralized or distributed database or data source and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding, or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories and optical and magnetic media.
While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative and not restrictive of the current invention, and that this invention is not restricted to the specific constructions and arrangements shown and described since modifications may occur to those ordinarily skilled in the art.
