EA041022B1 - INTERACTIVE PLATFORM FOR INTERACTION OF A USER OF A MOBILE COMMUNICATION DEVICE AND A MOBILE COMMUNICATION NETWORK OPERATOR - Google Patents

Description

Cross-reference to related applications

This application claims priority of U.S. Provisional Application No. 62/156,723, filed May 2015. The contents of that application are incorporated herein by reference in their entirety.

Background of the invention

Mobile network operators (MNO) are constantly looking for new and easy ways to attract their customers and inform them about interesting promotional offers, new tariff plans, discounts and new service offers. Despite the presence of many channels for accessing subscribers, most of them are extremely inefficient. Usually, people refuse to provide the email address associated with their mobile account, or simply ignore promotions sent by mobile operators via email. Often, notifications sent by e-mail and regular mail are not read and considered by customers as spam or junk mail. In many markets, especially emerging markets, mobile subscribers have limited access to the Internet and do not visit the mobile operator's website.

In markets that allow it, one of the most effective ways to reach customers is through the Short Message Service (SMS) channel. Offers are sent to mobile subscribers by mobile operators or third parties via SMS, and subscribers can usually respond with a special code to opt out of an offer or promotion of a new service. This requires the user to view the SMS and understand the instructions on how to subscribe to the offer. In many cases, subscribers receive offers that are delivered to their incoming SMS messages on their mobile phone, and the subscriber does not see the offer until it expires. In other cases, subscribers will delete an offer in an SMS message without even reading it, similar to deleting emails or throwing away paper newsletters. When subscribers view an offer, traditionally many of those who wish to sign up for a promotion do not fully understand the instructions on how to respond to the invitation and do not provide the correct credentials in response to the offer; hence, never join a new promotion. The industry needs a simple, highly interactive, one-click marketing solution that can simultaneously target a wide range of mobile subscribers.

The essence of the invention

One aspect of this disclosure provides a computerized method for automatically prompting a user to respond to an offer on a mobile device after a triggering event. The method includes receiving at the server an indication that a triggering event has occurred; receiving at the server an indication that the triggering event corresponds to a triggering event stored in a database operable to connect to the server; receiving on the server information containing the international subscriber number of the mobile station (MSISDN) of the mobile device; preparing a first proposal message containing one or more first executable response options; and sending the first offer to the mobile device.

In some embodiments, the method further includes comparing the MSISDN of the mobile device with the MSISDN associated with the offer campaign and stored in a database operable to connect to the server. In other embodiments, the method includes comparing the MSISDN of the mobile device with a reject list stored in a database operable to connect to the server, wherein the reject list contains one or more MSISDNs for one or more mobile devices that have opted out of receiving offer messages. . In further embodiments, the method also includes comparing the MSISDN to a blacklist stored in a database operable to connect to the server, where the blacklist contains one or more MSISDNs that the mobile network operator wishes to prevent from receiving offer messages. In still further embodiments, the implementation of the method further includes receiving on the server type of mobile device; and comparing the type of mobile device with a disallow list stored in a database operable to connect to the server, wherein the disallow list contains one or more types of devices that should not receive the offer messages. In yet another further embodiment, the method also includes: determining whether previous sentence messages have been sent to the mobile device; counting how many previous offer messages were sent to the mobile device, if offer messages were sent to the mobile device; and comparing the number of offer messages sent to the mobile device with the limit value, wherein the offer message is not sent to the mobile device if the number of offer messages sent to the mobile device is greater than or equal to the limit value.

In some embodiments, the method also includes obtaining at the server information containing the executable response option selected on the mobile device; and logging

- 1 041022 of the executable response option selected on the mobile device and the MSISDN of the mobile device. In additional embodiments, the method further includes determining if the executable response option selected on the mobile device is positive; sending a registration message to the mobile network operator containing the MSISDN of the mobile device, the campaign code and, if necessary, the date and time, wherein the registration message is sent if the executable response option selected on the mobile device was positive. In some embodiments, the registration message further comprises a short code.

In some embodiments, the method also includes sending a follow-up message to the mobile device, the follow-up message comprising one or more of the following: an acknowledgment message and a thank you message.

In some embodiments, the method also includes updating a positive or negative counter database, wherein the counter database counts positive and negative responses received from a plurality of mobile devices.

In some embodiments, the implementation of the method further comprises receiving information from the mobile device on the server about the lack of response; preparing a second offer message containing one or more second executable response options; and sending a second offer message to the mobile device, wherein the no-response information from the device indicates that at least one of the following events occurred on the mobile device: the first executable response option was not selected on the device, the first offer message disappeared from the screen after the set timeout has been reached, the mobile device failed to display the suggestion message and an unknown error occurred on the mobile device.

In some embodiments, the method further includes updating the offer message counter database, increasing the number of offer messages sent to the MSISDN associated with the mobile device by one.

In some embodiments, the trigger event is selected from the group consisting of a mobile device exhausting the first value of the data plan, a mobile device exhausting the second value of the voice plan, a mobile device exhausting the third value of the SMS tariff plan, a mobile device exhausting the fourth value of the tariff plan MMS when the browser on the mobile device navigates to the first web address, when the location of the mobile device is within the first geographical area, when the balance of the account associated with the mobile device drops below a threshold amount, and after a certain number of phone calls.

Another aspect of this disclosure provides a computerized method for automatically prompting a user to respond to an offer on a mobile device after a triggering event, the method comprising: receiving, in a processor on the mobile phone, an indication that the triggering event has occurred; receiving on the mobile device a first offer message containing one or more first executable response options; and displaying the first polling message on the screen of the mobile device. In some embodiments, the method also includes playing an alert tone on the mobile device when the first offer message is displayed.

In some embodiments, the method further includes launching an application installed on the mobile device, wherein the application causes the first offer message to be displayed. In some embodiments, the application is installed on the SIM card of the mobile device. In other embodiments, the application is installed on the operating system of the mobile device.

In some embodiments of the method, the first offer message further comprises an integrated circuit card identifier (ICCID). In some embodiments, the method further includes comparing the ICCID of the first offer message with the ICCID of the mobile device, wherein the match indicates that further processing of the first offer message is acceptable. This comparison allows the method to provide an additional security step.

In other embodiments, the method further includes determining whether the mobile device can execute the commands contained in the first offer message. In some embodiments, the method also includes determining if the mobile device is roaming.

In some embodiments, the implementation of the method also includes obtaining in the application the first executable response option selected by the user. In some embodiments, the implementation of the method further includes sending to the server information containing the first executable response selected by the user.

In some embodiments, the first offer message further contains the first executable commands. In some embodiments, the executable instructions may be executed by the processor of the mobile phone. In some embodiments, the executable

- 2 041022 commands can be executed by the application. In some embodiments, the method further includes executing the first executable commands by the application, wherein the executable commands comprise commands to call a telephone number, open a browser and navigate to a web address, or display a message on the screen of a mobile device.

In some embodiments, the method also includes receiving a no response response in the application. In some embodiments, the no response response indicates that the first response option message has been removed from the screen of the mobile device due to a timeout.

In some embodiments, the implementation of the method further includes determining the number of displays, wherein the number of displays is the number of displays of the first message with the offer on the screen of the mobile device; comparing the display number with the display number limit; and sending the limit information to the server, wherein the limit information is sent when the number of views is greater than or equal to the display number limit. In certain embodiments, the method also includes re-displaying the first offer message on the screen of the device.

In some embodiments, the trigger event is selected from the group consisting of a mobile device exhausting the first value of the data plan, a mobile device exhausting the second value of the voice plan, a mobile device exhausting the third value of the SMS tariff plan, a mobile device exhausting the fourth value of the tariff plan MMS when the browser on the mobile device navigates to the first web address, when the location of the mobile device is within the first geographical area, when the balance of the account associated with the mobile device drops below a threshold amount, and after a certain number of phone calls.

Yet another aspect of this disclosure provides a computerized method for verifying account login on a mobile device, the method comprising receiving, at a server, an authentication request for an authorization request from a third party, the request comprising the MSISDN of the mobile device; preparing an authentication message containing one or more executable response options; sending an authentication message to the mobile device associated with the MSISDN; receiving a first response message containing an executable response option selected on the mobile device; and sending to the third party a second response message containing the executable response option selected on the mobile device. In some embodiments, the first response message further comprises a second MSISDN.

In some embodiments, the method also includes comparing the second MSISDN to the MSISDN of the mobile device, wherein the second response message indicates that authorization is checked if the second MSISDN is the same as the MSISDN of the mobile device. In some embodiments, the third party is a financial institution.

Brief description of graphic materials

In FIG. 1 is a depiction of exemplary GUI steps that a user may encounter when using the BoosterX embodiment, FIG. 2 is a block diagram illustrating an exemplary architecture of the BoosterX platform, FIG. 3 is a block diagram illustrating exemplary interactions between a mobile network operator and the BoosterX server platform, FIG. 4 is a flowchart illustrating an exemplary logical process that the BoosterX platform uses to determine whether a campaign message should be sent to a particular target mobile subscriber, FIG. 5 is a flowchart illustrating an exemplary process for expressing and interacting a BoosterX application with a user device, FIG. 6 is a flowchart illustrating an exemplary process for BoosterX to log mobile user responses and transmit MNO responses, FIG. 7 is a flowchart illustrating an exemplary process for updating the MNO database of the BoosterX platform with subscriber engagement, participation tracking so that the MNO can change the frequency of campaign offers or promotions depending on the response of the subscriber, FIG. 8 is a flowchart illustrating an exemplary process for configuring BoosterX campaigns on the platform and obtaining lists of target subscribers, FIG. 9 is a flowchart illustrating an exemplary campaign launch process by the BoosterX platform, FIG. 10 is a flowchart illustrating an exemplary BoosterX campaign process, FIG. 11 is a flowchart illustrating an exemplary process for initiating and executing BoosterX automatic retries on the platform, FIG. 12 is a flowchart illustrating an exemplary process for performing automatic retries by BoosterX, FIG. 13 is a block diagram illustrating an exemplary embodiment of an AuthenXicator that provides a layer of encryption and security when customers log in to a bank account from a mobile or computer browser, FIG. 14 is a flowchart illustrating an exemplary embodiment of the interactions between the MNO cloud and the AuthenXicator authorization request and the BoosterX mobile application to confirm or deny authorization, FIG. 15 is a flowchart illustrating an exemplary process for a subscriber to receive an AuthenXicator request and how the subscriber interacts with the display to confirm or deny authorization.

Detailed description

This application provides aspects and embodiments of OnePIN's BoosterX™ service. The term BoosterX is used throughout this application to refer to numerous aspects and embodiments of the methods, applications, services, systems, and platforms disclosed herein. The name BoosterX is not limited to any particular embodiment and may refer to multiple embodiments or individual embodiments. In addition, other names are also used to refer to the embodiments described herein.

In the context of this document, terms in the singular mean one or more than one.

In some aspects, BoosterX is a cloud-based platform that interacts with a client application residing on a mobile phone, either as a downloadable application from an external site, or in the operating system of the device, or on a SIM card. In some aspects, BoosterX is a campaign-based marketing service that allows mobile operators to advertise new services, promotional prices, or other events to their subscribers.

In some embodiments, subscribers (the terms subscriber and mobile user are used interchangeably in this disclosure) can easily upgrade their voice, SMS, MMS or data packages using a simple interactive user interface before their tariff plans expire. They may also opt out of new promotions that may be beneficial to them. MNOs increase their revenues by moving subscribers to higher bandwidth data plans and eliminating time lost between data plan top-ups. Operators also earn revenue when they can offer new services or tariff packages to their existing subscriber base using BoosterX, and subscribers agree to promotions. In some embodiments, mobile users are never charged directly for the BoosterX application or service. Subscribers pay only for voice channel, data, SMS or other promotions offered by the operator or a third party.

With the BoosterX service, MNOs can upgrade to higher data plans monthly using a simple user interface. This private feature is extremely flexible and the MNO can provide the user with many options that are fully customizable based on the specific scenario.

In some embodiments, the BoosterX service available to the MNO is fully configurable. It can be configured in any way desired by the MNO or a third party. MNOs can easily define their own campaigns and their own promotional pricing. In some embodiments, interactions occur via an API (Application Programming Interface), so the BoosterX service is always in sync with the current MNO pricing schemes for all pricing plans.

The BoosterX platform can also be applied to SMS packages, general mobile phone top-ups, voice plans, or any other service or new promotions MNO chooses to offer. BoosterX may be used for any billing-related purchase increase or for general marketing and outreach campaigns. MNOs may choose to focus on offering promotions for data packages, as increasing data revenue is usually a priority in most MNO strategies. MNOs increase the margin on the unused parts of the data package compared to the unused parts of the SMS and/or voice packages. Moving people to a higher bandwidth data plan is a big benefit for MNOs.

In some scenarios, MNOs or BoosterX platform administrators can define a trigger that will launch a campaign for a group of subscribers or an individual subscriber. This is the moment when the MNO would like to remind the subscriber that he or she is approaching the allowable payment limit of the tariff plan by sending a message to the subscriber. For example, if a subscriber is nearing their allowed data limit, the subscriber's MSISDN is automatically provided to the BoosterX server via the API, along with the subscriber's current data plan and the amount of data already used. Also, with each provision of information, the current options for data tariff plans available to the subscriber and the associated prices for each data tariff plan are sent. The BoosterX platform then automatically launches the campaign for the subscriber, giving

- 4 041022 the subscriber to know that he is approaching the exhaustion of his tariff plan, and offer subscribers new top-up options.

In some embodiments, the BoosterX platform includes a web interface that allows commercial organizations, enterprises, market participants, etc. log in and determine which services they would like to see for certain groups of subscribers. This interface also allows administrators to create a campaign. As part of the campaign event, businesses or mobile operators enter relevant information, including, but not limited to, the target telephone number(s) and the time frame for which the campaign will be active. User interface specifics (i.e. text that mobile device users will see) can be entered through the web interface. MNOs can also specify the maximum number of subscribers to be scheduled per day, as well as the duration (days or hours) of the campaign.

In some embodiments, a connection is established between the server (cloud or cloud platform) and the MNO network. On the MNO network, there can be multiple links to the BoosterX server from different systems. For example, the BoosterX platform may receive notifications via web services or APIs or other means from an MNO billing platform, switch, subscriber database, or other data store or customer information platform. When the BoosterX platform receives information via the API, the platform checks the phone number to determine if the subscriber has opted out of receiving promotions. The failure process is fully explained below. If the subscriber cancels the service, the processing ends and no further messages are sent to the subscriber.

If the subscriber is not on the reject list or on the black list (the mobile device on the black list has mobile device specifications that can be problematic to receive these campaigns), then the corresponding campaign message is prepared based on the configuration criteria and sent to the mobile subscriber. Here, this information is described as an SMS message that launches a remote application on the caller's mobile phone. These can be binary SMS, standard text SMS, specialized SMS (immediate display SMS, class 1 SMS) or class 2 SMS) that the phone sends to the SIM card inside the device. Alternatively, communication can be via MMS, email, USSD, or other internet communication channels between the mobile phone and the BoosterX platform. The message contains executable response options.

When a message is received on the caller's mobile device, the client application displays the caller's dialog box. For example, a message displayed on a mobile device might read

You have used 90% of your allowed data limit this month. To avoid overage charges, upgrade your data plan now. Choose one of the following options:

MB - 15 USD,

MB - 25 USD,

100 MB - $40,

500 MB - $60.

The user can navigate through the menu and select a response, which is then sent back to the BoosterX server via the app. Communication with the server can be carried out via a data channel, SMS, MMS or USSD.

The remote client application may be configured to receive information from the platform indicating how to send a response from the mobile user. In one embodiment, the command message sent to the client application may indicate that all user responses should be sent to a specific short number as an SMS. In an alternative embodiment, the platform may send a command message that indicates that only positive responses from the target user should be sent to the specified address, and all other responses from the remote client should be sent to another address. These platform and client functionality provide mobile network operators with charging and billing flexibility. MNO may charge users for specific actions taken when promotions are displayed to the user.

USSD (Unstructured Supplementary Service Data).

The above embodiments can also be implemented in such a way that a client application (either on the phone or on the SIM card) is not required. In this case, the USSD channel is opened, and communication between the mobile subscriber and the BoosterX platform occurs via the USSD connection.

The cloud server may have the intelligence to communicate with one or more client applications. The Cloud Server may collect the device type of the respective mobile devices (also referred to as TAC or Type Allocation Code) and may send a message to the respective client applications to disable the BoosterX client application on mobile devices that are aware of issues and/or bugs that are interfering with the service.

- 5 041022

Refusal process.

Each time the subscriber receives a message from the BoosterX server, he or she has the option of not responding. The BoosterX service has the intelligence to count the number of bounces or message expiration times (i.e. no response received from the user after a certain amount of time), and based on this can ask the subscriber if he or she wants to opt out of receiving future promotions. Bounce counters for subscribers who have used the service and for subscribers who have never used the service may be different. For example, if the mobile subscriber (calling party) has never responded to any promotional prompts, the rejection screen may be displayed for a set number of times when the data prompt screen is cancelled. For example, the counter could be set to 3 (after 3 (three) times no response was sent to a data entry prompt; it will be shown a screen to opt out of service). If a mobile subscriber has responded to an advertising invitation in the past, but has recently declined several invitations, this bounce counter can be increased to, for example, 6 (six) because that user has exhibited a previous behavior indicating that he or she is ready (ready ) respond to promotional invitations for specific offers. In some embodiments, the counter may be set to a percentage of rejects or bounce responses for a specified number of offer messages sent and/or within a specified time period.

BoosterX is preferably used with a mobile phone, but can also be used with other devices that can be configured to receive text SMS or MMS messages. For example, tablets, watches (such as the Apple watch), and other computers may be used with the service.

AuthenXicator.

In another embodiment, the BoosterX platform may be launched and a message generated and sent to the user based on an external event that was not initiated from a mobile device. For example, the BoosterX service can be used as part of an authentication mechanism for banks or other entities that want to provide a different level of encryption and security when customers log in to an account from a mobile or computing device. In this case, when a customer opens a bank account for the first time or decides to access their account online through the web portal for the first time, they will be asked to enter their mobile phone number. An SMS is sent to his mobile phone asking him to verify that he really owns the given mobile number. The next time the subscriber decides to log into his account from the public portal or connected device, there will be an exchange of data between his device, the bank and the mobile operator. In one embodiment, this communication between the customer and the bank is via a simple secure internet connection or web services. Communication between the bank and the mobile operator may be through application programming interfaces, web services, or other automated computing means. When the mobile operator receives a message from the bank, an automatic connection to the BoosterX server is made through another application programming interface or web service. With this connection, the client's mobile phone number is transmitted to the BoosterX server. The BoosterX platform then automatically prepares the messaging campaign for the application that resides on the client's mobile device or SIM card. The application starts and the following question appears on the screen: Please confirm that you want to log into your bank account. If the subscriber confirms by selecting an executable response option, such as selecting Yes or OK, or Accept, or similar, then the application will retransmit the response into a message format and send it back to the BoosterX server. The server broadcasts the source address (client's mobile phone number) and replies to the bank's server with the client's mobile number and the selected answer Yes [or No if the answer is no].

Using the BoosterX platform to support the CallConneXion service.

In yet another embodiment, the BoosterX platform may be triggered by an intelligent inbound call campaign. In one embodiment, the inbound call campaign capability is referred to as the CallConneXion™ service. The platform used in this way allows brands and mobile operators to intelligently navigate and interact with large groups of consumers who have already expressed interest in this promotion. MNOs or trademarks identify the target list of consumers. Each target consumer has an MSISDN associated with it. The platform launches the campaign by sending a command message to each target consumer. The consumer will see an advertising message on their device. In one exemplary scenario, a consumer may see a promotion such as

Want to learn how to get an iPhone 6 for just $1 a month? Click OK to chat with a Sprint support representative and we'll tell you more! The call is free!

When the consumer accepts this, for example by selecting OK or Accept or a similar executable response option, the BoosterX client application on the device automatically calls a predefined number on behalf of the subscriber. Any telephone number may be dialed, including a fixed telephone number, any national number, or any international number. The phone number that is dialed on behalf of the subscriber is determined at the platform level when setting up the campaign configuration. In some embodiments, the phone number is sent as part of a command message that the remote client application interprets. The subscriber does not need to enter numbers or know any codes. The call is placed automatically after the user accepts the promotional invitation.

campaign protocol.

In some embodiments, messages from mobile subscribers (MTs) sent to a remote client application use a dedicated protocol. This is determined by the particular byte array. In one embodiment, byte 0 specifies the message type. The message subtype of the lisa byte, with bits indicating if 1) a tone playback event on the client side should occur when a proactive command request is received; 2) roaming detection must be enabled or disabled; and 3) various short code addresses must be configured so that the application can send responses back to toll or free short numbers as required by the business logic. Roaming detection is a feature where an application can determine if a subscriber is outside their country of residence or home location. In the case where the mobile device is roaming, the application can be configured to remain silent when receiving a proactive command message from the platform. This way, the application will not display messages to the user, thereby creating potentially unwanted billing charges when the user travels outside of their home network.

In some embodiments, the byte array also contains the ICCID (integrated circuit card identifier) of the intended target SIM as an additional security mechanism. The application may be configured to check the ICCID of all incoming messages against the actual ICCID on the card to ensure that there is a match. The proprietary messaging protocol also allows you to set a unique identifier so that each response sent back to the server receives a corresponding platform-level unique identifier. Additional action identifiers can also be set, which can be associated in the remote application with user code. The number of times a preemptive command or retry should be performed can also be defined in case no response is received from the user. In some embodiments, a subscriber parameter check is also added, which allows the remote client application to check if the terminal device supports the requested lookahead command. A detailed description of the lookahead command in accordance with the GSM 11.14 standard is also defined in the messaging protocol.

In some embodiments, mobile subscriber (MO) initiated session proactive response is also defined by a dedicated proprietary protocol. The message type and subtype are defined in the protocol. Similar to the MT messaging protocol, the unique identifier and action identifier can be configured. Ultimately, the terminal response is determined, which allows the platform to decipher whether a response was received from the user, or whether the session timed out, or whether the device can support the command.

Benefits of the BoosterX service.

Listed below are some of the benefits of the BoosterX platform.

Simplicity. Creating campaigns is a simple and straightforward process for mobile operators, enterprises or third parties using the BoosterX platform. MNOs can easily set up campaigns and collect customer input very simply without the need for an external marketing company, sales agents or other resources.

Efficiency. Businesses and businesses receive valuable customer feedback very quickly. Feedback cycle time is reduced, allowing MNOs and commercial organizations to very quickly modify future offerings and tailor offers and promotions based on customer interest levels.

Individual setting. MNOs can easily tailor their campaigns to different market segments. They can collect a wide range of customer interest levels for various promotions in many different market segments.

Wide coverage. Businesses can easily target a large group of subscribers with one quick campaign. This is especially critical in developing regions, as many survey participants may not have access to a computer or landline phone, or to a physical store location (i.e., the typical ways of traditionally collecting customer feedback). However, these customers have mobile phones and can be important participants in the feedback process.

High value. Billing models may be structured such that third party companies must pay for the actual responses received from mobile subscribers.

- 7 041022

Income generating service. Mobile network operators (MNOs) can offer a differentiating service to their business and corporate customers. Businesses pay for valuable input and customer feedback, creating a significant source of revenue for MNOs because each customer response to a survey represents a billing event.

Operational Compatibility. The BoosterX platform works on all mobile phones, regardless of operating system or device type.

Interactivity. End users do not need to manually send an SMS message, MMS message or email reply or remember a complex USSD string. BoosterX uses a one-click interactive user interface that is automatically provided to the subscriber. Ease of use results in a higher response rate from subscribers who have the app on their phone compared to other common advertising techniques used in the market.

High level of agreement. Ease of use results in a level of acceptance for promotions above the industry average.

Compliance with needs. Promotions may appear at appropriate times, such as when the subscriber has almost used up the balance or after a phone call, when the subscriber is most likely looking at his phone. Promotions can also target subscribers who have recently topped up, meaning they have added funds to their account and have money to spend on other new services.

Platform work.

In FIG. 1 shows the interface that a mobile user will interact with when using the BoosterX application to top up their voice, SMS, MMS or data package. At step 100, after initiating an event, campaign, or promotional offer hosted by a mobile network operator (MNO), the device user sees a screen that asks the user if he/she wants to see promotional options (in FIG. 1, data packets) and contains executable response options for the user to select.

In an embodiment in which the user chooses to view offers, he or she is directed to the screen shown in step 105 as an example, in which various promotional or recharge options are laid out in a simple interface in which each plan is horizontally paired with its price (in Fig. 1, data plan options). At this point, if the user still wants to continue with the promotion or top-up, he or she will select the option they prefer and click OK. Alternatively, in some embodiments, the user may select the option they prefer by clicking on the option (without having to also click OK).

In an embodiment in which the user of the mobile device has selected the option he or she prefers, he or she is shown a final screen, as illustrated in step 110, which confirms the selection and payment of the rate plan. You can also provide a link to the MNO website or thank you for the increased user experience.

In one embodiment, as shown in FIG. 2, BoosterX uses the following connection structure.

Operator billing system Application Programming Interface (API), Customer Relationship Management (CRM) and Customer Billing Management (CBM) are also in communication with the BoosterX(Z) cloud server, this allows the operator billing API to notify CRM or CBM MNO about the subscriber's use of a prepaid prepaid plan or credit account.

In various embodiments, the MNO notifies the BoosterX cloud server when Subscriber A (1) reaches 95% data usage to initiate a replenishment questionnaire, or (2) when he or she passes through a radius associated with MNO's storefront geographic locations, or (3 ) when the account balance is low or (4) at the end of the month or quota system that the subscriber can use as a regular tariff plan, or (5) after a predetermined number of events (for example, after 5 calls), or when the subscriber visits the MNO web page through your browser. The above examples are examples of when the MNO can communicate with the BoosterX cloud server for subscriber data A. One skilled in the art will appreciate that these examples are not limiting and that many other triggers can be applied to cause the MNO to communicate with BoosterX cloud server. These additional examples, understood by a person skilled in the art, are covered by this disclosure.

In some embodiments, the BoosterX cloud server may initiate the process described herein as it interacts with and receives responses from the subscriber. Depending on the actions of the subscriber (participating with yes or no responses or not participating), the BoosterX cloud server also transmits the subscriber's responses to the operator's billing system API, CRM and CBM.

- 8 041022

In an embodiment in which the user has agreed to receive promotions or initiate a recharge of rate plans (for example, when subscriber A has reached 95% of his or her data usage), the operator's billing system API triggers the sending of a recharge questionnaire or promotion to subscriber A. This is communicated to the BoosterX cloud server, which forwards the questionnaire to the operator's short message center (SMSC) as a binary SMS message (Y).

The operator's SMSC forwards the recharge questionnaire or promotion to the device (X) of subscriber A.

The questionnaire or promotion is displayed on subscriber A's device as shown in FIG. 1(A), after which the subscriber selects his preferred option.

The BoosterX application on subscriber A's mobile device forwards the answers (A) of the recharge questionnaire to the assigned short number in the SMSC (B) of the operator.

The operator's SMSC receives and forwards the survey responses to the BoosterX cloud server as a binary SMS message (C).

The BoosterX cloud server parses and transmits the user's response to the operator's billing system API, where the user's data billing plans can be updated. These updates will be pushed to the BoosterX (D) cloud server.

The updated tariff plans will be sent to the operator's SMSC via a binary SMS message (E).

The operator's SMSC forwards the rate plan updates to the device user, who is informed of the successful update via a confirmation display (see FIG. 1) (F).

In FIG. 3 is a block diagram illustrating an exemplary embodiment of a mobile network operator's interaction with the BoosterX platform. In the embodiment illustrated at block 300, a triggering event occurs. Triggers may include actions taken by the user or events defined by the mobile operator. Examples might include: (1) the user is topping up their data balance (i.e. they are purchasing more data), (2) the user has made X number of phone calls, (3) the user has just visited the MNO webpage via their mobile phone, or ( 4) the user is running out of voice, SMS or data balance for the month, or (5) the user is geographically close to the MNO storefront where he buys his tariff plan. One of skill in the art will appreciate that a number of other triggering events may lead to the activation of the BoosterX platform. Such other triggering events are covered by this disclosure.

In one embodiment, when a triggering event occurs, the MNO automatically notifies the BoosterX platform of the particular event via an API. The mobile subscriber's MSISDN, also known as the source address, is sent to the BoosterX platform. The flow of information may also be through web services or through any other connection. This process is illustrated at step 305.

Then, in the embodiment illustrated at step 310, the source address is sent to the BoosterX server platform.

In FIG. 4 is a flowchart illustrating exemplary logic that the BoosterX platform uses to determine whether a campaign message should be sent to a specific target mobile subscriber. In the embodiment illustrated at step 400, the BoosterX platform collects the home address (MSISDN of the mobile subscriber) from the MNO via an API, web service, or other connection (step 310 in FIG. 3). In step 405, the BoosterX platform checks the BoosterX campaign definition for the subscriber's MSISDN. In some embodiments, the platform goes through a series of additional checks to determine if a BoosterX campaign message should be sent to the mobile subscriber. At step 410, the BoosterX platform determines if the mobile subscriber is blacklisted. The black list may be defined by the mobile network operator and may include a group of subscribers to whom the MNO does not wish to send messages. In other embodiments, a particular type of device may be blacklisted. Blacklisted devices may be mobile terminals that do not comply with GSM standards or specifications, or simply those that provide a poor user experience. Mobile subscribers with a blacklisted device will not be the target of the campaign, as indicated in step 411.

At 415, the platform may perform the following check to determine if the subscriber has opted out of receiving promotions. If the subscriber has indicated that it does not wish to receive notifications, processing ends as indicated at block 416. Then, at block 420, the platform may also check custom counters to ensure that the target subscriber has not received multiple messages that exceed the total message volume or a certain number of messages. for a certain period of time. In an embodiment in which any counter has been exceeded, the search process for the target mobile subscriber for BoosterX communication ends, as illustrated at step 421.

- 9 041022

In an embodiment in which the user counter has not been reached, the BoosterX platform prepares and executes a lookahead command request and sends a message to the mobile subscriber, as illustrated in step 425.

In FIG. 5 shows an exemplary embodiment of the expression and interaction of the BoosterX application with the user's device. This exemplary process illustrates an embodiment of a user experience.

At step 500, a message with a proactive command is sent from the platform to the remote client application. A proactive session request (a message in FIG. 5 at step 500) is received at the device. At step 505, the client application checks the ICCID (integrated circuit card identifier) in the command message sent from the server and compares it with the ICCID specified on the SIM card in the device. This serves as an additional security check. In an embodiment where the ICCID sent from the platform does not match the ICCID specified on the SIM card, the security check fails and processing ends, as illustrated in step 506. Then, if the ICCIDs match, the client application checks if the device command requested by the platform. This check, occurring at step 510, determines whether the portable telephone device can perform the promotion as determined at the platform level (ie, whether the phone supports command execution). If the device does not support the command, as illustrated in step 511, a response message is sent back to the platform indicating that the device does not support it. If the device reports that the command is supported, then the client application will check to determine if the mobile subscriber is roaming, as illustrated in step 515. The client application may be configured to determine if the user is roaming on another mobile network. operator, or is roaming outside the country, or is roaming outside his home network area. The campaign may be configured to stop processing at 516 in an embodiment where the subscriber is reported to be roaming. These steps and process checks can be performed in a variety of combinations and orders.

In an embodiment when the subscriber is not roaming, at block 520, the client application is launched. In some embodiments, the client application may be configured to play an alert tone to the user, as illustrated at block 525. The client application then proceeds with the advertising campaign. This may include launching a website, displaying screen text to a mobile user, or displaying a list of selectable items. Other embodiments and campaign scenarios are also possible. In one illustrative embodiment, the campaign message text displayed on the screen is shown at step 530. An exemplary message may read:

Add more data to your tariff plan! 10MB for only $15 - available today only! Select OK to add to your plan.

If the mobile user cancels or exits the ad screen or selects No, a response is sent back to the platform at step 540 indicating the user's response.

If the user gives a yes at step 535, at step 550 the client application can prepare and execute another proactive command, such as displaying a different screen for the caller, or automatically placing a phone call to a predefined number, or launching a website. In other embodiments, the user's selection of OK may be sent back to the platform and client-side processing is completed.

If the user does not respond, in some embodiments, the implementation of the proactive session may have a set timeout (for example, the text displayed on the screen may disappear). In this embodiment, at step 560, the repeat counter is incremented. The client application checks if the retry limit has been reached at step 565. In the embodiment where the limit has not been reached, the client application re-runs the proactive command and the promotion screen is displayed again at step 530. In the case where the retry limit is reached at step 565, the client application sends a timeout response to the server at step 570, which is logged to the server. This timeout response indicates that the subscriber did not interact with the BoosterX promotion in any way.

In FIG. 6 is a flowchart illustrating an exemplary process for the BoosterX platform to log responses from mobile device users and transmit MNO responses. In one embodiment, at block 600, the client application processes the user's response to the promotion. At block 602, a user response to the BoosterX campaign request is sent from the client application to the BoosterX platform. The BoosterX platform responds differently depending on the subscriber's response (block 605). If the mobile user's response was not positive (ie, they selected No or Cancel at step 535), the BoosterX platform logs the response (for example, step 610). From this point on, the platform proceeds to update the MNO (see FIG. 7, step 700, for example). In the embodiment where the user's response was yes (ie, he selected Yes or Accept at 535), the BoosterX platform logs the response (at 611).

- 10 041022

In the embodiment illustrated at block 612, the BoosterX platform sends one or more of the user's MSISDN, date, time, and MNO campaign code via an API or via

SMS on behalf of the user to the MNO network to sign him up for promotions.

In a further embodiment, illustrated at step 613, a follow-up message may be sent to the user to confirm their participation in the promotion or to thank them (for example, your 10 MB has been added to your data plan! Thank you for choosing Vodafone). From either step 612 or 613, the BoosterX service proceeds to update the MNO (see FIG. 7, step 700).

In FIG. Figure 7 shows an exemplary process of how the BoosterX platform updates the MNO with subscriber participation, tracking participation so that the MNO can change the frequency of offers or promotions based on subscriber response. The database supporting this process can be on the BoosterX platform or on the MNO network. In the embodiment illustrated at block 700, the BoosterX platform is updated with the user's response (see blocks 610 or 612) in the BoosterX campaign request.

The BoosterX platform then analyzes whether or not the mobile subscriber wants to participate, as illustrated in the request of step 705. trigger/don't resend if the MNO only wants one response per MSISDN or with some similar rule).

In one embodiment, at step 715, the BoosterX service terminates and ends when the user participates in the campaign and the boost counter has received a response in accordance with previously established rules developed by the MNO. In an embodiment in which the user has chosen not to participate in the BoosterX campaign (as illustrated by block 711), the BoosterX platform logs this inaction against the increment counter. In an embodiment where the user has not participated in less than the skipped campaign threshold, the BoosterX service will attempt to send the campaign again after another event. In one embodiment, at step 715, the BoosterX service terminates and ends when (1) the user has chosen not to participate, and (2) the non-participation increment counter threshold has been exceeded.

The previously described BoosterX campaigns were generated on the network and triggered based on a subscriber's action. However, the BoosterX platform also allows MNOs to develop their own campaigns targeting all subscribers or a specific subset of subscribers in order to offer promotions or receive feedback from specific individuals.

In FIG. 8 shows how a target list for a mass marketing campaign is identified. This process may include a methodology whereby the selection criteria is determined by (1) data from the MNO databases, (2) the BoosterX database of historical campaigns (for example, the campaign that generated successful purchases in the MSISDN group), or (3) it could be list of added or loaded numbers. For example, using the MNO database, you can target numbers used in a particular business for a given campaign. Or using BoosterX's historical data, you can target wealthy youth with purchasing power who are more likely to respond.

In one embodiment, at step 800, the campaign is configured on the BoosterX server. At step 805, the target list of subscribers is identified. This list may be in the form of a list of MSISDNs (phone numbers) based on criteria retrieved from (1) other online databases, (2) BoosterX database of historical campaigns, (3) downloaded list of target numbers, or (4) manually entered list). At block 810, the time, date, and average run time (ie, the duration in days that the campaign will run) can be determined at the platform level. Also at steps 800, 805, and 810, the parameter combination for the campaign can be configured. From this moment, the campaign begins (see details in Fig. 9, step 900).

In FIG. Figure 9 shows an example campaign launch process for the BoosterX platform. In one embodiment, at block 900, the BoosterX platform checks the campaign definition for each MSISDN in the target list. In step 905, the BoosterX platform inquires if the mobile subscriber is blacklisted by BoosterX. In the embodiment where the user's phone is blacklisted by BoosterX, the process proceeds to step 906 and the BoosterX campaign ends. If the user is not blacklisted by BoosterX, the campaign proceeds to step 910, at which time the BoosterX platform asks if the user has opted out of receiving promotions. If the user has opted out of receiving promotions, the process proceeds to step 911 and the BoosterX campaign ends. If the user has not opted out of receiving promotions, the BoosterX campaign proceeds to step 915 where the BoosterX platform checks if the counters have been reached (eg, by determining the number of promotions the user should see or how many No responses were received from the user). If the counters are exceeded for any particular user, that subscriber is not included in the campaign's target audience and processing for that MSISDN ends at block 916.

- 11 041022

If the counters have not been exceeded, the BoosterX platform sends a campaign message to the target

MSISDN, as illustrated at 920. Following this exemplary process in FIG. 9, this campaign message will be sent to all subscribers in the target list that comply with the counter limits and campaign service definitions. From this point on, the campaign continues as described above.

In FIG. Figure 10 shows an example process for configuring a BoosterX campaign on the BoosterX platform. In one embodiment, at step 1000, the administrator creates a new campaign. At block 1005, a trigger event for the campaign is determined. At step 1010, the display text to be shown to the target mobile subscribers is determined. At step 1015, counters and rules (ie, the number of times a subscriber can be invited to participate, provided that the recipient's address is activated) are determined.

In FIG. Figure 11 shows a sample process for running BoosterX automatic repeats. The responses collected during the campaign (as in FIG. 6, step 600) can vary considerably and may include (1) the subscriber answered Yes on the screen, (2) the subscriber answered No on the screen, (3) the subscriber pressed Cancel on the screen, (4) the subscriber pressed Back on the screen, (5) no action was taken by the subscriber and the screen display timed out, (6) no response at all, (7) the mobile device is currently unable to process the display of the campaign command, and (8 ) device responds Unknown error. In some embodiments, responses 1-4 give the BoosterX platform a clear understanding of the nature of their response, but responses 5-8 meet the criteria for automatic retries. Many factors can lead to scenarios 5-8, such as the subscriber's phone was disconnected, the subscriber was out of network coverage, the subscriber most likely did not hear / see the campaign, the subscriber was doing something else on the mobile device that interfered with the campaign .

In some embodiments, at step 1100, the BoosterX platform receives a response that corresponds to automatic repeats because it is not explicitly responding to the campaign. This could be due to any of the following: (1) the subscriber's screen timed out, (2) the subscriber did not respond, (3) the mobile device could not process the campaign, or (4) the device responded with an Unknown Error. In one embodiment, at step 1105, in which one of the above four (4) conditions is met, the platform proceeds to read counters with a reset to determine the appropriate number of times to repeat a given campaign. In the embodiment illustrated at block 1110, the platform continues to repeat the same campaign with a custom retry profile (including time interval and number of attempts). From this point on, the campaign continues as described above.

In FIG. Figure 12 shows an example process for performing automatic attempts with the BoosterX client application. In one embodiment, at 1200, a re-campaign request is received at the handset. At block 1205, the remote client application proceeds to verify the ICCID sent from the platform in the command message against the ICCID of the SIM card in the user's device. If the ICCID does not match, then the security check fails at 1205, the request is discarded, and the process ends at 1206. This terminates the automatic retries process for that MSISDN for the specific campaign. If the ICCIDs match, the security check is successful and the BoosterX application continues to extract the timeout limit from the request, as illustrated in step 1210. The timeout limit refers to the amount of time a message must be displayed on the screen without any action from the user. . At 1215, the campaign command is sent to the subscriber's mobile phone.

In an embodiment in which the mobile subscriber sees the promotion and provides a response at 1220, the user's selected response message is sent back to the backend platform at 1225, ending the automatic retries process. In the scenario where the subscriber does not respond immediately, the promotion will remain active on the screen of the subscriber's device for a limited period of time before it disappears (timeout). This timeout period is defined at the platform level and is configurable. The timeout period is sent to the remote client application as part of the command message. The client application applies the timeout limit at step 1221 and continues to display the screen until the limit is reached. The time period can be set to any time range. In one embodiment, the sleep period may be set to 30 s, i. e. The advertising message will only be displayed to the user for 30 seconds. In other embodiments, the timeout may be several minutes, several hours, or may be set to an unlimited value. In an embodiment where the timeout is set to an unlimited value, the promotional screen will be displayed on the user's device until the user performs an action on the screen (provides a response) or until the device turns off.

If the timeout limit is reached, the displayed screen disappears and, at step 1225, a response is sent to the server indicating that the screen timed out and that there was no response from the user. On some mobile devices, the screen may only be displayed for 30-60 seconds due to technical limitations. In order to provide a BoosterX promotion for a longer time on all devices, a remote application can manage the timeout process with

Claims (7)

by the power of a series of counters and re-output commands. In this embodiment, a maximum wait time counter is determined. The remote client application will display the promotion for the set amount of time (30-60 seconds) supported by the device. When this limit is reached, the client application checks if the maximum timeout limit has been exceeded. If it has not been exceeded, the client application will increment the timeout interval counter and reissue the display command to the device at 1222, which ensures that the display request remains active on the device. In FIG. Figure 13 shows an example process for using BoosterX to provide a different level of encryption and security when customers log in to a bank account from a mobile or desktop browser. In the context of this document, the term AuthenXicator refers to aspects and implementations of these validation processes that are a subset of the BoosterX platform. The term AuthenXicator may refer to specific embodiments or to all embodiments taken together. In this example, the AuthenXicator mobile subscriber will be Joe. In one embodiment, in step 1300, Joe (an exemplary mobile subscriber) attempts to log into his Citibank account through a browser while online on his phone or computer. At step 1305, Joe enters his username. Citibank will then ask if Joe has a mobile phone number associated with his account, illustrated at 1310. In one embodiment, when Joe does not have a mobile number associated with his Citibank account, Citibank will continue to prompt him for a password without applying the AuthenXicator, BoosterX check (step 1340). In the case where Joe has a mobile number associated with his Citibank account, Citibank will request authentication of his mobile phone number (MSISDN) (at 1315). From this point on, Joe's mobile phone number authentication passes to the BoosterX cloud server (see FIG. 14, step 1400). After the authentication request, Citibank continues to wait for BoosterX's response confirming Joe's phone number (illustrated at step 1320). At step 1325, a response is received. At step 1330, Citibank must evaluate if the MSISDN matches the MSISDN specified in Joe's account. At step 1335, in which the MSISDN does not match that of Joe's account, Citibank rejects Joe's attempt to log into his account through his phone/computer's web browser. At step 1336, where the MSISDN matches that of Joe's account, Citibank allows login to Joe's account. At step 1340, Citibank asks Joe for his password. Once entered correctly, Joe can log into his account in secure mode. In FIG. Figure 14 shows an exemplary process for an MNO to interact with an AuthenXicator authorization request, as well as with the BoosterX platform to confirm or deny authorization. In this example flow, Joe will remain our mobile subscriber example. In step 1400, the MNO receives a request to authorize the user's MSISDN (initiated by Joe by entering his username associated with a phone number when logging into his Citibank account through his computer or phone's web browser in step 1315). In step 1405, the BoosterX cloud prepares and sends an authentication message to the BoosterX mobile application. From this point on, the AuthenXicator process runs through the mobile device/application (see FIG. 15, step 1500). After requesting authentication from Joe's mobile device, the BoosterX platform continues to wait for a response from the device (illustrated at step 1410). At step 1415, the BoosterX platform receives a response related to the authorization of Joe's phone number (obtained via step 1520). At step 1420, the BoosterX platform sends a response to Citibank. From this point on, the process proceeds through the Internet and according to the Citibank authorization architecture (see Fig. 13, step 1325). In FIG. Figure 15 shows an example process of how the AuthenXicator request appears to the subscriber and how the subscriber can interact with the display to confirm or deny authorization. In this example flow, Joe will remain our mobile subscriber example. In step 1500, Joe's device receives an authentication message through the BoosterX platform in the MNO cloud (see FIG. 14, step 1405). In step 1505, Joe's device continues to offer him an authentication screen. At step 1510, a Citibank authentication screen is displayed (eg, Please click OK to log into your Citibank account. Response options may include OK, No, and Cancel). In step 1515, Joe's response (eg, OK, No, or Cancel) is collected and sent to the BoosterX platform (see FIG. 14, step 1415). From now on, the AuthenXicator process goes through the MNO cloud server. CLAIM 1. A computerized method of interaction between a user of a mobile communication device and a mobile network operator after sending a triggering event to it, wherein the method includes - 13 041022 receiving information about the occurrence of a triggering event on the server to launch campaigns aimed at subscribers using APIs, web services or other means, while the triggering event includes the occurrence of one of the following: exhaustion of the first value of the data plan by the mobile device, exhaustion the second value of the voice tariff plan by the mobile device, the exhaustion of the third value of the SMS tariff plan by the mobile device, the exhaustion of the fourth value of the MMS tariff plan by the mobile device, the exhaustion of the fifth value of the tariff plan of services by the mobile device, the exhaustion of the sixth value of the subscription tariff plan by the mobile device, the decrease in the account balance associated with mobile device, below the threshold amount or making a certain number of phone calls with a mobile device; receiving information on the server for launching subscriber-targeted campaigns from the mobile network operator via APIs, web services or other means, the information containing the International Mobile Subscriber Number (MSISDN) of the mobile device associated with the triggering event; preparing a first offer message from a mobile network operator containing one or more selectable response options on the mobile device; sending from the server to run campaigns the first offer message to the mobile device associated with the specified MSISDN; receiving, at the server for launching campaigns directed to subscribers, information from the mobile device containing the selectable response option on the mobile device selected on the mobile device; determining whether the mobile selectable response option selected on the mobile device was yes; sending from the server for launching campaigns directed to subscribers a registration message to the mobile network operator containing the MSISDN of the mobile device, campaign code, date and time; wherein the registration message is sent if the selectable response option on the mobile device selected on the mobile device was positive. 2. The method of claim 1, further comprising comparing the MSISDN of the mobile device with the MSISDN associated with the offer campaign and stored in a database capable of connecting to the server. 3. The method of claim 2, further comprising comparing the MSISDN of the mobile device with a failure list stored in a database capable of connecting to the server, wherein the failure list contains one or more MSISDNs of one or more mobile devices that opted out of receiving offers. 4. The method according to claim 1, characterized in that it further includes determining whether messages with the previous sentence were sent to the mobile device; counting how many previous offer messages were sent to the mobile device, if offer messages were sent to the mobile device; and comparing the number of offer messages sent to the mobile device with the limit value, wherein the offer message is not sent to the mobile device if the number of offer messages sent to the mobile device is greater than or equal to the limit value. 5. The method according to claim 1, characterized in that it further includes obtaining on the server information containing the response option with the choice on the mobile device selected on the mobile device; and logging the selectable response option on the mobile device selected on the mobile device and the MSISDN of the mobile device. 6. The method according to claim 5, characterized in that it further includes receiving information on the server about the lack of response from the mobile device; preparing a second offer message comprising one or more selectable second response options on the mobile device; and sending a second offer message to the mobile device, wherein the no response information from the mobile device indicates that at least one of the following events has occurred on the mobile device: the first response option was not selected on the device with a choice on the mobile device, the first the suggestion message disappeared from the screen according to the timeout settings, the mobile device was unable to display the suggestion message, and an unknown error occurred on the mobile device. 7. The method according to claim 6, characterized in that it further includes updating the database of offer message counters, wherein the number of offer messages sent to -