CN117999806A - System and method for enriching short message service - Google Patents

System and method for enriching short message service Download PDF

Info

Publication number
CN117999806A
CN117999806A CN202280054967.0A CN202280054967A CN117999806A CN 117999806 A CN117999806 A CN 117999806A CN 202280054967 A CN202280054967 A CN 202280054967A CN 117999806 A CN117999806 A CN 117999806A
Authority
CN
China
Prior art keywords
information
rich
user
brand
short message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202280054967.0A
Other languages
Chinese (zh)
Inventor
英德帕尔·辛格·穆米克
苏林德·辛格·安纳德
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cooper Schuper Co ltd
Original Assignee
Cooper Schuper Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cooper Schuper Co ltd filed Critical Cooper Schuper Co ltd
Priority claimed from PCT/US2022/035822 external-priority patent/WO2023278770A1/en
Publication of CN117999806A publication Critical patent/CN117999806A/en
Pending legal-status Critical Current

Links

Landscapes

  • Telephonic Communication Services (AREA)

Abstract

The present invention provides a method and system for creating and transmitting rich information using a rich short message service application (RSAPP). The rich information includes information and brand identification. RSAPP receives a request to send Short Message Service (SMS) information to the mobile telephone number (MNU) of the user. RSAPP processes the request to send SMS information and determines whether the MNU is enabled on one or more rich information transfer channels (RMCs). When it is determined that the MNU is enabled on the RMC, RSAPP creates the rich information and transmits the rich information to the MNU on the enabled RMC. When it is determined that the MNU is not enabled on the RMC, RSAPP confirms whether the setting specifies that the received SMS information be transmitted to the MNU as SMS information when the MNU is not enabled on the RMC, and RSAPP transmit the received SMS information to the MNU as SMS information.

Description

System and method for enriching short message service
Cross Reference to Related Applications
The present application claims priority and benefit from non-provisional patent application No. 17/85228 (titled "A SYSTEM AND method for Rich Short MESSAGING SERVICE", at the filing date of the U.S. patent and trademark office, 2022, 6, 30), which non-provisional patent application No. 17/85228 claims priority and benefit from provisional patent application No.63/216921 (titled "Rich Short MESSAGING SERVICE", at the filing date of the U.S. patent and trademark office, 2021, 6, 30). The description of the above-mentioned patent application is incorporated herein by reference in its entirety.
Background
Brands (i.e., businesses or organizations) typically send one or more of notifications, promotional information, transaction information, etc. to a user's mobile phone number via Short Message Service (SMS) information to notify the user of transactions, coupons, promotions, news, updates, emergency situations, etc. Typically, the notification or promotional information sent via SMS contains text instructions regarding transactions, coupons, promotions, news, updates, emergency situations, and the like. Also, the SMS notification or SMS promotion may include a Uniform Resource Locator (URL) link that directs the user to a particular web page regarding transactions, coupons, promotions, news, updates, emergency situations, and the like. Conventional SMS notifications or SMS promotions do not contain rich elements such as rich cards, dials, quick Response (QR) codes, rich media, graphic Interchange Formats (GIFs), suggested replies and suggested actions displayed as interactive buttons, etc. for the user to interact with or take necessary actions.
Typically, a user receives one or more of an SMS notification, an SMS promotion, an SMS transaction, etc. on a user device from a short number, a long number, or from an alphanumeric sender mask. Typically, the user does not identify short numbers, long numbers, or sender masks as belonging to a brand. Thus, traditional SMS notifications or SMS promotional information may sometimes confuse the user or may not be trusted. Moreover, when the user does not identify the sender, the user does not have a simple way to verify the authenticity of the SMS notification or SMS promotion. Thus, there has long been a need to increase the trustworthiness of SMS notifications or SMS promotional information by adding a brand identity (e.g., the sender's brand name, brand icon, and/or brand logo) and optionally a verification mark (e.g., a verification mark or trust mark) to indicate that the brand identity has been verified and can be trusted by the recipient.
In general, information including rich elements (e.g., image content, audio content, video content, contacts, other rich media content, etc., and verified sender identification) is referred to as rich information. Such rich information is transferred directly to the user device using one or more of an Application Programming Interface (API), protocol, and other tools, such as an activity manager designed for different rich information transfer channels, e.g., rich Communication Services (RCS), WHATSAPP LLCApple Inc. >/>, Viber MEDIA SARLTelegram FZ-LLC/>, Facebook incGoogle Business Messages, signal Technology Foundation of Messenger, google LLC/>PRIVATE MESSENGER, etc. However, these APIs are not designed to handle typical Short Message Services (SMS) in order to create rich information. Moreover, existing methods of sending rich information require special techniques, APIs, and protocols. These existing methods can be expensive for conventional applications of SMS and current users. For example, sending rich information may require extensive changes to existing SMS applications that use SMS APIs, protocols, or tools to send information to users. As used herein, an "SMS application" refers to an information delivery application that enables a user to send SMS information from various platforms.
Accordingly, there is a long felt need for a method and system for creating and transmitting rich Short Message Service (SMS) information including rich elements. Moreover, there is a long felt need for a method and system for creating rich information with a brand identity of the sender and optionally with a verification mark. Moreover, there is a long felt need for a method and system for processing information transmitted as SMS information in order to create rich information and automatically transmitting the created rich information on a rich information transfer channel when a user is available on the rich information transfer channel. Moreover, there is a long felt need for a solution that can benefit existing SMS applications from rich information delivery.
Disclosure of Invention
This summary is provided to introduce a selection of concepts in a simplified form that are further disclosed below in the detailed description. This summary is not intended to identify the scope of the claimed subject matter.
The methods and systems disclosed herein address the above-described need for creating and transmitting rich Short Message Service (SMS) information including rich elements such as authenticated sender Identifiers (IDs), image content, audio content, video content, contacts, rich cards, dials, interactive buttons, and other rich media content. The rich SMS information is hereinafter referred to as rich information. Moreover, the methods and systems disclosed herein address the need for creating rich information with a brand identity of a sender (e.g., brand name, brand icon, and/or brand logo), and optionally with a verification token (e.g., verification token, trust token, etc.), for increasing the trustworthiness of the rich information, and indicating that the brand identity has been verified and can be trusted by a recipient. Moreover, the methods and systems disclosed herein address the above-described need for processing information sent as SMS information to create rich information and automatically sending the created rich information through a rich information delivery channel when the user is available on the rich information delivery channel. Moreover, the methods and systems disclosed herein address the above-described needs for a solution that allows existing SMS applications to benefit from rich information delivery.
The methods disclosed herein include transmitting rich information on one or more data information transfer channels or rich information transfer channels, such as Rich Communication Services (RCS), WHATSAPP LLCApple Inc. >Business Chat, viber MEDIA SARL/>, apple IncTelegram FZ-LLC/>/>, Facebook incGoogle Business Messages, signal Technology Foundation of Messenger, google LLC/>PRIVATE MESSENGER, or any other information transfer channel that uses data to transfer information or supports rich information transfer features and rich elements (including, for example, images, videos, rich cards, dials, interactive buttons). An interactive button (e.g., a button for suggesting a reply, suggesting an action, etc.) is a button that a user can select or click on in order to send response information or take an action on the user device. The suggested replies enable the user to select or click on interactive buttons displayed on the user device in order to communicate responses to the brands. The suggested actions enable the user to select or click on an interactive button in order to take an action on the user device, e.g., place a call, open a website, share a location, etc. On the RCS, the suggestion reply and suggestion actions are sent as part of a suggestion list, either with a separate rich card or with a rich card that is part of the carousel. Other information delivery channels also support sending interactive buttons in the form of suggested replies and suggested actions, although these rich interactive elements may be referred to by different terms. For example, at/>On instant messaging applications, the suggested replies are called quick replies, and the suggested actions are called call actions, at/>On Messenger, the suggested reply is called quick reply, and the suggested action is called button.
The data information transfer channel or rich information transfer channel disclosed above is implemented by a data information transfer application on the user device and a data information transfer platform (e.g., RCS,Etc.) support. Most of these data information transfer platforms support commercial information transfer that enables branding or branding-representative developers or branding-representative applications to send and receive information to and from users of the data information transfer application over a data network. Some data information transfer platforms such as/>Commercial information transfer is not currently supported, but may be supported in the future. Some rich information delivery platforms (e.g. RCS,Etc.) identify the user by the user's mobile phone number. Other rich information delivery platforms (e.g./>)Messenger) not only enables users to use identifiers that are different from mobile phone numbers, but also enables users to link mobile phone numbers with their accounts. Some other rich information transfer platforms (e.g., google Business Messages) use different identifiers than mobile phone numbers and currently do not support a mechanism to link their channel identifiers with mobile phone numbers at the platform level, but enable users interacting with brands to provide and verify mobile phone numbers to chat robots, thereby establishing a mapping between identifiers used by the rich information transfer platform and the mobile phone numbers of users. "channel" as used herein illustratively relates to SMS, RCS,Etc. Also, as used herein, "rich information transfer channel", "data information transfer application", "data information transfer platform", and "rich information transfer platform" illustratively relate to RCS,/>Etc.
The methods and systems disclosed herein employ a rich Short Message Service (SMS) application (RSAPP) configured to determine computer program instructions executable by at least one processor for creating and transmitting rich information (RSAPP). The rich information includes information and brand identification. In an embodiment, the rich information further comprises a validation mark. The brand identity includes, for example, one or more of a brand name, a brand icon, and a brand logo of a brand requesting the transmission of rich information to the user's mobile phone number. In the methods and systems disclosed herein RSAPP receives a request from a brand (i.e., sender) to send SMS information to a user's mobile phone number. RSAPP checks whether the sender of the SMS message has registered for the rich messaging service provided by the methods and systems disclosed herein. When the sender has registered with the rich information delivery service, RSAPP processes the request to send the SMS message and determines whether the user's (i.e., recipient's) mobile phone number is enabled on one or more of the rich information delivery channels by executing a channel-specific command on each rich information delivery channel. For example, RSAPP performs a rich communication service contact capability check command for the user's mobile phone number to determine if the user's mobile phone number can be used for a Rich Communication Service (RCS). In an embodiment RSAPP determines whether the user's mobile phone number is enabled on one or more other rich information transfer channels by executing an equivalent command specific to the other rich information transfer channels. For example, RSAPP performs the WhatsApp business Application Programming Interface (API) contact method for determining whether the user's mobile phone number is enabled on the WhatsApp rich information delivery channel.
In an embodiment, a rich Short Message Service (SMS) application (RSAPP) creates rich information and transmits it to the user's (i.e., recipient's) mobile phone number without explicitly checking whether the user's mobile phone number is enabled on one or more rich information transfer channels. RSAPP execute a command to transfer the rich information to the user's mobile phone number. When the user's mobile phone number is enabled on the rich information transfer channel, the command to send rich information receives a status response indicating that the send status is successful. When the mobile phone number of the user is not enabled on one or more rich information transfer channels, the status response to the command to send rich information indicates that the mobile phone number of the user is not enabled on the rich information transfer channels.
In another embodiment, a rich Short Message Service (SMS) application (RSAPP) determines whether the user's mobile phone number is enabled on one or more rich information transfer channels by searching the local cache created by RSAPP for the user's mobile phone number. RSAPP creates a local cache by saving the enablement status of each mobile phone number based on explicit or implicit capability check commands to the RCS or status responses to equivalent commands on other rich information transfer channels.
Upon determining that the user's mobile phone number is enabled on one or more rich information transfer channels, a rich Short Message Service (SMS) application (RSAPP) creates rich information including information and a brand identity and transmits the created rich information to the user's mobile phone number on the enabled rich information transfer channel. In an embodiment, the service provider verifies the brand identity. In an embodiment, the rich information further includes one or more of a variety of interactive buttons. The interactive buttons include, for example, a suggested reply button, a suggested action button, and a brand-specific action button. Selecting the suggested reply button using the user's user device will enable the user to respond to the brand or send a user response to the brand. Selection of the suggested action button or brand-specific action button enables the user to perform an action on the user device. In an embodiment RSAPP passes the created rich information from a trusted sender Identifier (ID). In another embodiment RSAPP passes the created rich information from the sender ID of the brand. When it is determined that the user's mobile phone number is not enabled on the one or more rich information transfer channels, RSAPP confirms whether the setting specifies that the received SMS information be transmitted as SMS information to the user's mobile phone number when the user's mobile phone number is not enabled on the one or more rich information transfer channels. RSAPP transmits the received SMS message as SMS message to the user's mobile phone number. In an embodiment RSAPP sends status information to the brand, including one or more of a pass receipt and a read receipt.
In an embodiment, a rich Short Message Service (SMS) application (RSAPP) monitors delivery of the created rich information to a mobile phone number of a user. As part of monitoring delivery, RSAPP delivers the created rich information to the user's mobile phone number via one or more additional information delivery platforms in the event of a failure or delay in delivery of the created rich information to the user's mobile phone number via the first information delivery platform. Additional information delivery platforms include, for example, alternative data information delivery platforms and short message service platforms. In another embodiment RSAPP concurrently transmits the created rich information on a rich information transfer channel that can increase the chances of delivering the created rich information. In this embodiment, RSAPP withdraws the created rich information from the enabled other rich information transfer channels once the created rich information is transferred over one rich information transfer channel.
In an embodiment, a brand enterprise or developer registers a rich SMS with a service provider. Upon performing registration, the service provider receives information about the brand identity from the brand enterprise and verifies the brand identity. In an embodiment, a brand enterprise or developer specifies one of a plurality of rich information templates to be used for sending rich information to a service provider. The service provider transmits the rich information to the user device of the user using the specified rich information template.
In an embodiment, a rich Short Message Service (SMS) application (RSAPP) determines whether a user's mobile phone number can be used for a rich communication service. Also RSAPP determines whether the user's mobile phone number can be used in one or more of a plurality of messaging applications, e.gOr other instant messaging applications. In an embodiment, RSAPP determines whether the user's mobile phone number is linked to the user profile. In another embodiment, RSAPP determines whether the user's mobile phone number is linked to a chat bot created by a branding or messaging platform. RSAPP include, for example/>The created rich information is transmitted to the user profile or branded chat bot on one or more of the plurality of messaging platforms of Messenger, google Business Messages, and Apple Business Chat. In an embodiment, the user profile is part of a profile stored by one or more entities including, for example Facebook, google and Apple.
In an embodiment, a rich Short Message Service (SMS) application (RSAPP) selects one or more rich information transfer channels based on one or more of a plurality of parameters. These parameters include, for example, the size of the SMS message; the capabilities of multiple information delivery platforms; the cost of sending SMS messages over one or more rich information delivery channels in terms of standard pricing and traffic pattern based dynamic pricing; a history of recipients of the SMS message in terms of message delivery status and time, message reading status and time, and user response; and maintaining consistency by sending SMS messages on a single rich information transfer channel instead of switching between multiple rich information transfer channels.
In an embodiment, a rich Short Message Service (SMS) application (RSAPP) augments rich information by one or more of a plurality of automatic augmentations including, for example, replacing Uniform Resource Locator (URL) links within SMS information with one or more of images, video, and other rich media; and automatically adding a suggested reply or suggested action to the SMS message based on the content of the SMS message.
In an embodiment of the method disclosed herein, a rich Short Message Service (SMS) application (RSAPP) receives SMS information from a brand (i.e., sender) that is transmitted to a user's mobile phone number. RSAPP checks if the sender of the SMS has registered for the rich SMS provided by RSAPP. When the sender has registered a rich SMS, RSAPP processes the received SMS message and creates rich information including information and brand identity. In an embodiment, the rich information further comprises a verification mark, thereby presenting a verified brand identity. In an embodiment, the sender Identifier (ID) of the SMS message is set by the messaging partner, aggregator, or RSAPP provider as RSAPP without explicit registration or registration by the brand that owns the sender ID. RSAPP transmits the created rich information over a network to the user's mobile phone number. In an embodiment RSAPP is in a data link (e.g., a mobile data link or Wi-FI ALLIANCE Corporation)Data link) on which rich information is transmitted. RSAPP determine whether a mobile phone number can be used to communicate data via a data messaging application (e.g., rich Communication Service (RCS), Or any other device capable of supporting passage through the RCS,Or any other data information transfer application that sends rich information to the user's mobile phone number). For some data information transfer applications (e.g./>Messenger, which is able to identify the user with an identifier that is different from the mobile phone number), RSAPP determines whether the user's mobile phone number is linked to the data messaging application. The user's mobile phone number receives the rich information sent by RSAPP. RSAPP transfer of rich information into a data information transfer application on a user device having a Subscriber Identity Module (SIM) representing a mobile phone number of a user, such as Google LLCMessages, samsung electronic Co., ltd./>Messages, etc., or in another data messaging application on the user device where the data messaging application registers with the user's mobile phone number, e.g. Etc.
The above disclosed embodiments of the methods disclosed herein are performed using one or more of the following: an Application Programming Interface (API) arranged to send Short Message Service (SMS) information; a protocol arranged to send SMS messages, such as the short message peer-to-peer (SMPP) protocol; an application arranged to send said SMS message; an API configured to send rich information; a protocol configured to transmit rich information; and an application arranged to send the rich information. In an embodiment, the API for sending SMS information is an existing API already in use for SMS information delivery. In another embodiment, the API is a new API configured to send SMS messages that includes features that make it easier or more efficient to send rich information. For example, the new API for sending SMS messages includes attributes that select a particular template for creating rich information from SMS messages. Another instance of the new SMS API supports a callback method that enables the sender to be notified when the user clicks the suggested action button. Similarly, in an embodiment, the protocol used to send the SMS message is an existing protocol already used for SMS message delivery, such as the short message peer-to-peer (SMPP) protocol. In another embodiment, the protocol used to send the SMS message is a new protocol, e.g., a variant of the SMPP protocol with extensions that can notify the brand (i.e., sender) when the user clicks the suggested action button. In an embodiment RSAPP provides rich information to the brand at the same cost or lower than conventional SMS information.
In an embodiment, the rich information further includes one or more of a suggested reply and a suggested action displayed as an interactive button on the user device. These interactive buttons enable the user to communicate a response to the brand when the user selects, taps, or clicks on the suggested reply button, or enable the user to take certain actions on the user device, such as calling a number, opening a website, or sharing a location, when the user clicks on the suggested action button. RSAPP receive a selection of one of the suggested replies from the user device or an indication that the user took an action by clicking on a suggested action button on the user device and notify the brand and/or developer.
In one or more embodiments, the related systems include circuitry and/or programming for performing the methods disclosed herein. The circuitry and/or programming, including one or any combination of hardware, software, and/or firmware, is configured to perform the methods disclosed herein according to the design choices of the system designer. In an embodiment, the various structural elements are employed according to the design choice of the system designer.
Drawings
The foregoing summary, as well as the following detailed description of the invention, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the embodiments herein, there is shown in the drawings exemplary constructions of the embodiments. However, the embodiments herein are not limited to the specific methods and instrumentalities disclosed herein. The description of method steps or components represented by reference numerals in the figures may be used for the description of method steps or components represented by the same reference numerals in any subsequent figures herein.
FIG. 1A illustrates a flow chart of an embodiment of a method for creating and transmitting rich information.
FIG. 1B illustrates a flow chart of another embodiment of a method for creating and transmitting rich information.
FIG. 1C illustrates a flow chart of another embodiment of a method for creating and transmitting rich information.
FIG. 2A illustrates another embodiment of a method for creating and transmitting rich information.
FIG. 2B illustrates another embodiment of a method for creating and transmitting rich information.
FIG. 2C illustrates another embodiment of a method for creating and transmitting rich information.
FIG. 2D illustrates another embodiment of a method for creating and transmitting rich information.
FIG. 3 illustrates a schematic diagram of a process flow for creating and transmitting rich information triggered by a brand or developer representing a brand.
FIG. 4 illustrates a schematic diagram of a process flow for creating and transmitting rich information triggered by a brand or developer representing a brand using one or more Application Programming Interfaces (APIs), protocols, applications, and software tools.
FIG. 5 illustrates an architectural block diagram of an example embodiment of a system for creating and transmitting rich information.
Fig. 6A-6E illustrate a flow chart for creating and transmitting rich information.
FIG. 7 illustrates a flow chart of an embodiment of a method for registering a brand or a developer representative of a brand with a rich Short Message Service (SMS) application provider of a rich SMS.
FIG. 8A illustrates a screen shot of a graphical user interface presented by an information delivery client on a user device, representing short message service information received from a short number to a user's mobile phone number.
FIG. 8B illustrates a screen shot of a graphical user interface presented by an information delivery client on a user device, representing rich information received by a user from a brand's verified sender Identifier (ID) over a rich information delivery channel.
FIG. 8C illustrates a screen shot of a graphical user interface presented by an information delivery client on a user device, showing an embodiment of rich information received by a user from a brand's authenticated sender ID over a rich information delivery channel.
FIG. 8D illustrates a screen shot of a graphical user interface presented by an information delivery client on a user device, showing an embodiment of rich information transmitted from a brand's authenticated sender ID to a user's mobile phone number over another information delivery channel.
FIG. 9A illustrates a screen shot of a graphical user interface presented by an information delivery client on a user device, showing an embodiment of short message service information received from a sender mask to a user's mobile phone number.
FIG. 9B illustrates a screen shot of a graphical user interface presented by an information delivery client on a user device, showing an embodiment of rich information received by a user from a brand's authenticated sender ID over a rich information delivery channel.
FIG. 9C illustrates a screen shot of a graphical user interface presented by an information delivery client on a user device, showing another embodiment of rich information received by a user from a brand's authenticated sender ID over a rich information delivery channel.
FIG. 10A illustrates a screen shot of a graphical user interface presented by an information delivery client on a user device, showing another embodiment of short message service information received from a short number to a user's mobile phone number.
FIG. 10B illustrates a screen shot of a graphical user interface presented by an information delivery client on a user device, showing another embodiment of rich information received by a user from a brand's authenticated sender ID over a rich information delivery channel.
FIG. 10C illustrates a screen shot of a graphical user interface presented by an information delivery client on a user device, showing another embodiment of rich information transmitted from a brand's authenticated sender ID to a user's mobile phone number over another information delivery channel.
FIG. 10D illustrates a screen shot of a graphical user interface presented by an information delivery client on a user device, showing another embodiment of rich information transmitted from a sender ID of a brand to a user profile linked to a user's mobile phone number over another information delivery channel.
FIG. 11A illustrates a screen shot of a graphical user interface presented by an information delivery client on a user device, showing another embodiment of short message service information received from a short number to a user's mobile phone number.
FIG. 11B illustrates a screen shot of a graphical user interface presented by an information delivery client on a user device, representing another embodiment of rich information received by a user from an authenticated sender ID of a brand.
FIG. 11C illustrates a screen shot of a graphical user interface presented by an information delivery client on a user device, showing another embodiment of rich information received by a user from a sender ID of a brand through a rich information delivery channel.
FIG. 12A illustrates a screen shot of a graphical user interface presented by an information delivery client on a user device, showing another embodiment of short message service information received from a trombone to a user's mobile phone number.
FIG. 12B illustrates a screen shot of a graphical user interface presented by an information delivery client on a user device, showing another embodiment of rich information received by a user from a brand's authenticated sender ID over a rich information delivery channel.
FIG. 13 illustrates a screen shot of a graphical user interface presented by an information delivery client on a user device, showing an embodiment of rich information received by a user from an authenticated sender ID with a brand identity of each brand sending the rich information.
Fig. 14A-14C illustrate screen shots of a user interface provided by a rich Short Message Service (SMS) application provider for rich SMS registration.
Detailed Description
Various aspects disclosed herein are implemented as a system, method, or non-transitory computer-readable storage medium having one or more computer-readable program codes stored thereon. Accordingly, the various embodiments disclosed herein take the form of an entirely hardware embodiment, an entirely software embodiment (including, for example, microcode, firmware, software, etc.) or an embodiment combining software and hardware aspects (referred to herein as a "system," "module," "engine," "circuit," or "unit").
FIG. 1 illustrates a flow chart of an embodiment of a method for creating and transmitting rich information. As used herein, "rich information" refers to information including text information, brand identification, optional verification indicia, optional rich cards, and optional interactive buttons. The methods disclosed herein employ a rich Short Message Service (SMS) application (RSAPP) configured to determine computer program instructions executable by at least one processor for creating and transmitting rich information (RSAPP). In an embodiment RSAPP is implemented as a web-based platform hosted on a server or network of servers accessible over a network. In another embodiment RSAPP is implemented in a cloud computing environment. As used herein, a "cloud computing environment" refers to a processing environment that includes settable, computational, physical and logical resources (e.g., networks, servers, storage media, virtual machines, applications, services, etc.) as well as data distributed across networks (e.g., the internet). The cloud computing environment provides on-demand network access to a shared pool of settable computing physical and logical resources. In an embodiment RSAPP is a cloud computing based platform implemented as a service for creating and transmitting rich information. For example, RSAPP is provided as software (as a service (SaaS) platform) or cloud-based software (as a service (CsaaS) platform) that creates and transmits rich information. In another embodiment RSAPP is implemented as a cloud platform service, also known as a platform (as a service (PaaS)). In another embodiment RSAPP is implemented as internal software installed and running on a computer within the premises of the organization. RSAPP receives 101 a request to send Short Message Service (SMS) information from a brand (i.e. sender) to the user's mobile phone number. The term "brand" as used herein refers to a business or a department of a business, or a brand used by a business or organization, that will send SMS messages to users. Wherever a brand is referred to as taking or receiving an action, it refers to a developer or another person taking or receiving an action on behalf of the brand, or an application taking or receiving an action on behalf of the brand.
In an embodiment, the rich information includes text and brand identification. The brand identity includes, for example, one or more of a brand name, a brand icon, and a brand logo of a brand requesting the transmission of rich information to the user's mobile phone number, as illustrated by examples in fig. 8A-13. In an embodiment, the service provider verifies the brand identity as disclosed in the specification of fig. 7. Upon successful verification of the brand identity, a verification mark (e.g., a verification mark) is disposed alongside one or more of the brand name, brand icon, and brand logo, to indicate that the brand is verified and can be trusted by the recipient of the rich information. In another embodiment, the rich information includes an image, for example, wherein a Uniform Resource Locator (URL) linked to the web page is enhanced with the image of the web page. In another embodiment, the rich information further includes one or more interactive buttons, as illustrated by examples in FIG. 8C, FIG. 9C, FIGS. 11B-11C, FIG. 12B, and FIG. 13. The interactive buttons include, for example, suggested reply and/or suggested action buttons that the user can select, click or tap on, to send response information and/or take action on the user's user device, respectively. The interactive buttons enable the user to communicate suggested replies to the brand or take one or more suggested actions. The user can respond to the brand by selecting a suggested reply or can take an action on the user device by selecting a suggested action. The suggestion reply enables the user to select, click or tap an interactive button displayed on a Graphical User Interface (GUI) of the information delivery client to deliver a response to the brand, as illustrated in the examples of fig. 11B-11C and 12B. The suggested actions enable the user to select, click or tap on the interactive button in order to take an action on the user device, such as making a call, opening a website, sharing a location, etc., as illustrated by examples in fig. 8C, 9C and 13. A rich Short Message Service (SMS) application (RSAPP) receives a selection of one suggested reply or an indication of a suggested action selected by the user from the user device and notifies the brand and/or developer.
The rich short message service application (RSAPP) processes 102 the request to send Short Message Service (SMS) information and determines 103 whether the user's (i.e., recipient's) mobile phone number is enabled on one or more of the plurality of rich information transfer channels by executing a channel specific command on each rich information transfer channel. For example, rich communication service contact capability checking commands, whatsapp business API contact commands, and equivalent commands for other channels of the user's mobile phone number. RSAPP 102 determines whether the user's mobile phone number is capable of being enabled on one or more of the plurality of rich information transfer channels by one of executing a command, invoking an Application Programming Interface (API) method, and searching from a database. The method for determining whether the user's mobile phone number is enabled on a particular rich information transfer channel may vary depending on the rich information transfer channel. In an embodiment RSAPP performs a rich communication service contact capability check command for the user's mobile phone number to determine if the user's mobile phone number can be used for a Rich Communication Service (RCS). In another embodiment, RSAPP executes the WhatsApp business API contact command of the WhatsApp business in-house deployment API to verify whether the user's mobile phone number belongs to a valid WhatsApp account and obtain the WhatsApp Identifier (ID) of the mobile phone number to send the information. Rich information transfer channels include, for example, rich Communication Services (RCS), WHATSAPP LLCApple Inc. >/>, Viber MEDIA SARLTelegram FZ-LLC/>, Facebook incGoogle Business Messages, signal Technology Foundation of Messenger, google LLC/>PRIVATE MESSENGER, or any other information transfer channel that uses data to transfer information or supports rich information transfer features and rich elements (including, for example, one or more of images, videos, rich cards, dials, and interactive buttons). In an embodiment RSAPP checks if the sender of the SMS message (i.e. the brand) has registered or registered for the rich information service, and when so, process 102 sends a request for SMS message and determines 103 if the user's mobile phone number is enabled on one or more rich information transfer channels. When it is determined 104 that the user's mobile phone number is enabled on one or more rich information transfer channels, RSAPP creates 104a rich information including information and brand entities with optional authentication marks and transmits 104b the created rich information to the user's mobile phone number on the enabled rich information transfer channel. In an embodiment RSAPP communicates rich information from a trusted sender Identifier (ID). In another embodiment RSAPP communicates rich information from the sender identifier of the brand. When it is determined 105 that the user's mobile phone number is not enabled on the one or more rich information transfer channels, RSAPP confirms 105a whether the setting specifies that the received SMS information be transmitted as SMS information to the user's mobile phone number when the user's mobile phone number is not enabled on the one or more rich information transfer channels, as exemplified in fig. 14B as "fallback routing". The "fallback routing" portion of rich information template 1402 enables branding to send or not send received SMS information to a user's mobile phone number when the mobile phone number is not enabled on one or more rich information transfer channels. RSAPP transmits 105b the received SMS message as an SMS message to the user's mobile phone number. In an embodiment, RSAPP sends status information to the brand including one or more of a transfer receipt and a read receipt.
In an embodiment, a rich Short Message Service (SMS) application (RSAPP) creates rich information and transmits 106 it to the user's (i.e., recipient's) mobile phone number without explicitly checking whether the user's mobile phone number is enabled on one or more rich information transfer channels, as illustrated by way of example in fig. 1B. RSAPP executes the 107 command to transfer the rich information to the user's mobile phone number. It is determined 108 whether the user's mobile phone number is enabled on the rich information transfer channel. When the user's mobile phone number is enabled on the rich information transfer channel, command reception 109 for transmitting rich information indicates that the transmission status is a successfully sent status response. When the user's mobile phone number is not enabled on one or more rich information transfer channels, the status response 110 to the command to transfer rich information indicates that the user's mobile phone number is not enabled on the rich information transfer channels.
In another embodiment, a rich short message service application (RSAPP) receives 101 a request to send Short Message Service (SMS) information from a brand to a user's mobile phone number. RSAPP processes 102 a request to send Short Message Service (SMS) information and determines 111 whether the user's mobile phone number is enabled on one or more rich information transfer channels by searching the local cache created by RSAPP for the user's mobile phone number. RSAPP creates a local cache by saving the enablement status of each mobile phone number based on explicit or implicit capability check commands to the RCS or status responses to equivalent commands on other rich information transfer channels. Upon determining 112 that the user's mobile phone number is enabled on one or more rich information transfer channels, RSAPP creates 112a rich information, including information and brand entities with optional authentication marks, and sends 112b the created rich information to the user's mobile phone number on the enabled rich information transfer channel. When it is determined 1113 that the mobile phone number of the user is not enabled on one or more rich information transfer channels, RSAPP confirms 113a whether the setting specifies that the received SMS information be transmitted as SMS information to the mobile phone number of the user when the mobile phone number of the user is not enabled on one or more rich information transfer channels, as exemplified by "fallback routing" in fig. 14B. The "fallback routing" portion of rich information template 1402 enables branding to send or not send received SMS messages to a user's mobile phone number when the mobile phone number is not enabled on one or more rich information transfer channels. When set enabled RSAPP sends 113b the received SMS message as an SMS message to the user's mobile phone number. When the setting is not enabled (i.e., SMS is not sent), RSAPP sends a response back to the brand indicating that the message cannot be sent.
Fig. 2A illustrates another embodiment of a method for creating and transmitting rich Short Message Service (SMS) information (hereinafter referred to as "rich information"). The method employs a Rich SMS Application (RSAPP), which Rich SMS Application (RSAPP) determines computer program instructions executable by at least one processor for creating and transmitting rich information. An example implementation of RSAPP is disclosed in the example of fig. 1. RSAPP receives a request 201 to send SMS information from the brand to the user's mobile phone number. In an embodiment RSAPP receives the SMS message in the request. RSAPP processes 202 the received SMS message and creates 203 rich information. In an embodiment RSAPP determines if the brand requests rich SMS, and when so, processes 202 the received SMS information and creates 203 the rich information. RSAPP transmits 204 the created rich information to the user's mobile phone number. In an embodiment RSAPP determines whether a user's mobile phone number can be used for a Rich Communication Service (RCS) and creates rich information to be transmitted to the mobile phone number through the RCS. The mobile phone number is considered to be available for RCS when the user has an RCS-capable client application installed on the user's user device, the client application being arranged to receive RCS information transmitted to the mobile phone number. In another embodiment RSAPP determines whether the mobile phone number can be used in one or more of a plurality of information delivery applications, e.g., WHATSAPP LLCInstant messaging applications or other instant messaging applications. For example RSAPP determines if a mobile phone number can be used for instant messaging, e.g./>Messages and create to pass/>The instant messaging application transmits rich information to the mobile phone number. When a user has/>, installed on the user deviceMobile phone numbers are considered to be available for instant messaging applicationsThe/>The instant messaging application is arranged to receive a transmission to a mobile telephone numberInformation. In another embodiment RSAPP determines whether the mobile phone number can be used with one or more rich messaging platforms (i.e., data messaging applications, such as RCS,/>Apple Inc/>, Viber MEDIA SARLEtc.) and determines the type of rich information to be transmitted to the mobile phone number by the rich information delivery platform for which the mobile phone number can be used. RSAPP in a data link (e.g., a mobile data link or Wi-/>, wi-FI ALLIANCE Corporation) And transmitting rich information. RSAPP delivers rich information to RCS clients,/>An instant messaging application or another data messaging application registered with the user's mobile phone number.
In an embodiment, a rich Short Message Service (SMS) application (RSAPP) determines whether a user's mobile phone number is linked to a user profile. RSAPP transmits the created rich information to a plurality of rich information delivery platforms (e.g.Messenger, google Business Messages, apple Business Chat, etc.). In an embodiment, the user profile is a portion of a profile stored by an entity comprising one or more entities (e.g., facebook, google and Apple). In another embodiment RSAPP determines whether the user's mobile phone number is linked to a chat robot or rich information platform created by the brand (e.g.Messenger, google Business Messages, apple Business Chat, etc.), in which the user has linked their mobile phone number to their account. RSAPP in one or more rich information delivery platforms (e.g./>Messenger, google Business Messages, apple Business Chat, etc.) transmits the created rich information to the chat robot of the brand.
In another embodiment, a rich Short Message Service (SMS) application (RSAPP) determines whether a user's mobile phone number is linked to a user profile on a rich information platform (e.g., google Business Messages) in which the user has linked their user profile to their mobile phone number by verifying the mobile phone number provided when interacting with a chat robot belonging to a brand, and when the user's mobile phone number is linked to the user profile, transmits the created rich information to the user profile on the rich information platform.
A user device associated with a user's mobile phone number receives the transmitted rich information as illustrated by way of example in fig. 13. In an embodiment, the user receives rich information from a sender Identifier (ID) (e.g., sender named "RichSMS"), as shown in the example of fig. 13. In another embodiment, the user receives rich information from the brand's sender ID, such as "United air", "ALdI", "MMA Connect", "New Museum", etc., as exemplarily shown in FIGS. 8B-8D, 9B-9C, 10B-10D, 11B-11C, 12B and 13. In another embodiment, a rich Short Message Service (SMS) application (RSAPP) sends information as Short Message Service (SMS) information when the user is not available for a rich channel.
Various embodiments of the methods disclosed above are performed using one or more of the following: an Application Programming Interface (API) arranged to send Short Message Service (SMS) information; a protocol arranged to send SMS messages, such as the short message peer-to-peer (SMPP) protocol; an application arranged to send SMS messages; an API configured to send rich information; a protocol configured to transmit rich information; and an application arranged to send the rich information. In an embodiment, the API for sending SMS messages is an existing API already in use for SMS message delivery. In another embodiment, the API is a new API configured to send SMS messages. For example, the new API for sending SMS messages includes attributes that select a particular template for creating rich information from SMS messages. Another instance of the new SMS API supports a callback method that enables the sender to be notified when the user clicks the suggested action button. Similarly, in an embodiment, the protocol used to send the SMS message is an existing protocol, such as the short message peer-to-peer (SMPP) protocol that has been used for SMS message transfer. In another embodiment, the protocol used to send the SMS message is a new protocol, such as a variation of the SMPP protocol with an extension, that is capable of informing the brand (i.e., sender) when the user clicks the suggested action button. In an embodiment RSAPP provides rich information to the brand at the same cost or lower than conventional SMS information.
FIG. 2B illustrates another embodiment of a method for creating and transmitting rich information. A rich Short Message Service (SMS) application (RSAPP) receives 201 a request to send an SMS message from a brand or a developer representing the brand to a mobile phone number of a user. In an embodiment RSAPP receives the SMS message in the request. RSAPP processes 202 the received SMS message and creates 203 rich information as disclosed in the description of fig. 1 and 2A. RSAPP transmits 204 the created rich information to the user's mobile phone number. RSAPP sends 205 a status response to the brand or to the developer representing the brand. For example, the status response represents one or more of a delivery of the rich information to the user, a timeout without the rich information being delivered, a confirmation that the rich information has been read, a rich information platform for transmitting the rich information, and the like. For example, the status response also indicates that the user's mobile phone number cannot be used for any rich information platform, or whether the information is sent as Short Message Service (SMS) information.
FIG. 2C illustrates another embodiment of a method for creating and transmitting rich information. A rich Short Message Service (SMS) application (RSAPP) receives 201 a request to send an SMS message from a brand or a developer representing the brand to a mobile phone number of a user. In an embodiment RSAPP receives the SMS message in the request. RSAPP processes 202 the received short message service information and creates 203 rich information including information, brand identification, and (in one embodiment) one or more of a plurality of interactive buttons. RSAPP transmits 204 the created rich information to the user's mobile phone number. RSAPP sends 205 a status response to the brand or to the developer representing the brand. Interactive buttons in the rich information include, for example, a suggested reply button, a suggested action button, and a brand-specific action button. The suggest reply button enables the user to communicate a response to the brand. Suggested action buttons or brand-specific action buttons enable a user to take or perform actions suggested by a brand on a user device. The user responds back to the brand or to the developer representing the brand by selecting one of the suggested replies or suggested actions. RSAPP receives 206 a selection of a suggestion reply or a representation of a user selection suggestion action from the user device. RSAPP sends 207 a user response, i.e., a suggested reply or suggested action selected by the user, to the brand or developer representing the brand. In an embodiment, RSAPP sends the status response along with the user response to the brand or to a developer representing the brand.
FIG. 2D illustrates another embodiment of a method for creating and transmitting rich information. A rich Short Message Service (SMS) application (RSAPP) receives 201 a request to send an SMS message from a brand or a developer representing the brand to a mobile phone number of a user. In an embodiment RSAPP receives the SMS message in the request. RSAPP processes 202 the received SMS message and creates 203 rich information including the information, brand identity, and (in one embodiment) one or more of the plurality of interactive buttons. RSAPP transmits 204 the created rich information to the user's mobile phone number. Interactive buttons in the rich information include, for example, suggested replies and/or suggested actions buttons, as disclosed in the description of fig. 2C. Selecting the suggested reply button using the user's user device enables the user to respond to the brand or to represent the developer of the brand. Selection of the suggested action button or the brand-specific action button enables a user to perform an action on the user device. The user responds to the brand or a developer representing the brand by selecting a suggested reply or suggested action. RSAPP receives 206 a selection of a suggestion reply or a representation of a user selection suggestion action from the user device. RSAPP sends 207 a user response, i.e., one of a suggested reply or suggested action selected by the user, to the brand or to a developer representing the brand. In an embodiment, RSAPP sends the status response along with the user response to the brand or to a developer representing the brand.
FIG. 3 illustrates a schematic diagram of a process flow for creating and transmitting rich information triggered by a brand or developer 301 representing a brand. Brand/developer 301 accesses rich Short Message Service (SMS) application (RSAPP) 302 to create rich information and transmit it to the user's mobile phone number. In the embodiment shown as an example in fig. 3 RSAPP a 302 is provided as a cloud platform implemented as a service, accessible through the use of an Application Programming Interface (API). The brand/developer 301 is able to select the transmission of rich information from the verified sender Identifier (ID) (e.g., "RichSMS" as shown by way of example in fig. 13) without using the brand's own sender ID. In an embodiment, one or more brands can choose to transmit rich information from an authenticated sender ID, such as "RichSMS", while one or more other brands can choose to transmit rich information from another authenticated sender ID, such as "United air links", "ALdI", "Newark Museum", etc., as illustrated in the examples of FIGS. 8B-8D, FIGS. 9B-9C, FIGS. 10B-10C, FIGS. 11B, and FIG. 12B, while one or more other brands can choose to transmit rich information from another unverified sender ID, such as "MMA Connect", "United air links", etc., as illustrated in the examples of FIGS. 10D and 11C.
The brand/developer 301 is also able to select the transmission of rich information from its own sender ID (e.g., its own brand name), as illustrated in the examples of FIGS. 8B-8D, 9B-9C, 10B-10C, 11B-11C, and 12B. In another embodiment, the brand's own sender ID is an authenticated sender ID, as illustrated by way of example in FIGS. 8B-8D, 9B-9C, 10B-10C, 11B, and 12B. In another embodiment, the brand's own sender ID is not an authenticated sender ID, as shown by way of example in FIGS. 10D and 11C. In an embodiment, the sender ID used by the rich Short Message Service (SMS) application (RSAPP) 302 to transmit the rich information is visible to the user, e.g., as an alphanumeric string, as a telephone number, as a short code, or any combination thereof. RSAPP 302a 302 receives a request to send SMS information from the brand/developer 301 to the user's mobile phone number, as shown in the example of fig. 3. RSAPP 302a 302 processes the request to send SMS information and creates rich information. RSAPP 302 use one of a plurality of information delivery platforms 303 (e.g., rich Communication Services (RCS) 303a,303B, apple/>303C or other platform 303 z) to transfer the created rich information from the developer-specified sender ID to the user's mobile phone number. RSAPP 302 communicates with the information delivery platform 303 through one or more information delivery Application Programming Interfaces (APIs).
The rich Short Message Service (SMS) application (RSAPP) 302 determines the rich data messaging capability of one or more messaging platforms 303 a-303 z for which the mobile phone number of the user can be used and causes a request for rich information from the brand/developer 301 to be mapped to the messaging platform specific capability in order to create the rich information and transmit it to the mobile phone number of the user. The user device 304 of the user is associated with the user's mobile phone number. The user device 304 includes an information delivery client 304a mounted thereon for receiving information. In an embodiment RSAPP 302 determines whether the user's mobile phone number can be used for Rich Communication Services (RCS) and creates rich information to be transmitted to the user's mobile phone number over the RCS channel. For example, a channel such as RCS supports rich elements including a carousel, suggested responses, and suggested lists that are configured to implement interactive buttons for user actions or replies, such as copying, confirming, completing transactions, reporting potential fraud, unauthorized access, unsolicited, unrecognized transactions, opening websites, opening map locations, sharing locations, selecting menu options, where a user may click on the interactive buttons, as illustrated in the examples in fig. 8C, 9C, 11B-11C, 12B, and 13, in order to complete an action without leaving the information transfer client 304a or having to type a reply (as in person-to-application (P2A) information transfer), and so forth. In an embodiment RSAPP processes text in the received SMS message to add one or more interactive buttons for user selection or tapping, for example by employing an existing two-way interactive SMS channel, and adds rich advice reply buttons to make it easier for the user to interact with the brand or developer 301 representing the brand. In another embodiment RSAPP 302 adds interactive buttons for suggesting replies and suggested actions on top of text in the received SMS message based on details specified in the rich information template by the brand or developer 301 representing the brand in order to increase the interactivity not previously supported in SMS interactions.
In another embodiment, a rich Short Message Service (SMS) application (RSAPP) 302 determines whether a user's mobile phone number can be usedAn instant messaging application (hereinafter "WhatsApP") and creates rich information to be transmitted to the user's mobile phone number by WhatsApp. In an example, an information transfer channel (e.g., whatsApp) may support the transfer of images for brand logos, but may not support other rich elements for implementing an interactive button that a user can click to complete an action, as shown in the examples of fig. 8D and 10C. For such channels RSAPP a menu of options for suggesting replies and suggested actions is sent, e.g. "send or type 1 for confirmation, send or type 2 for reporting fraud". The user types in a response to complete the action. Also, in an embodiment RSAPP sends the network link in rich information to confirm and report fraud. The user clicks on the web link to complete the action, resulting in the web browser opening. If the WhatsApp channel evolves to include rich elements, such as interactive buttons, RSAPP includes the interactive buttons into the rich information. /(I)
In another embodiment, a rich Short Message Service (SMS) application (RSAPP) 302 determines whether a user's mobile phone number can be used with one or more rich information platforms 303 (e.g., RCS, Etc.) and determines the type of rich information to be transmitted to the user's mobile phone number through the available rich information platform. RSAPP 302 allows brand/developer 301 to transmit rich information over a data link to a user's mobile phone number to data information client 304a, such as a Rich Communication Service (RCS) client,/>A client end,Client,/>A client, etc. RSAPP 302 by sending rich information over a data link including, for example, a mobile data link or Wi-/>And (3) a data link. RSAPP 302 delivers the rich information to an information delivery client 304a (i.e., a data information delivery application) on the user device 304 associated with the user's mobile phone number. RSAPP 302 to 302 monitors the delivery of rich information to the user's mobile phone number. In an embodiment, RSAPP 302 transmits/delivers rich information to a user's mobile phone number through one or more additional information delivery platforms, in the event of a failure or delay in the transmission/delivery of rich information to the user's mobile phone number through the first information delivery platform, according to the preferences of brand/developer 301. In another embodiment RSAPP transmits the rich information to user device 304 through a plurality of additional information delivery platforms to increase the reliability of the delivery of the rich information. Additional information delivery platforms include, for example, SMS platforms and alternative data information delivery platforms that allow for rich information. In an embodiment RSAPP 302 withdraws the rich information from the first rich information transfer channel before transmitting the information over the second rich information transfer channel.
In an embodiment, the routing logic of the rich Short Message Service (SMS) application (RSAPP) 302 includes determining whether a user identified by a mobile phone number can be over one or more rich information transfer channels (e.g., RCS,Etc.) are activated. RSAPP 302 selects one or more rich information transfer channels based on one or more of a number of parameters including, for example: the size of the SMS message; the capabilities of multiple information delivery platforms; the cost of sending SMS information over one or more rich information delivery channels according to standard pricing and traffic pattern based dynamic pricing; a history of recipients of the SMS message in terms of message delivery status and time, message reading status and time, and user response; and maintaining consistency by sending SMS messages on a single rich information transfer channel instead of switching between multiple rich information transfer channels. In an embodiment RSAPP is to transmit rich information simultaneously on multiple rich information transfer channels that can increase the chances of communicating rich information. Moreover, RSAPP, 302, once the rich information is delivered over one rich information transfer channel, withdraws the rich information from the other rich information transfer channels that are available. Moreover, in an embodiment RSAPP determines the developer's preferences based on the order of rich information transfer channels used to transfer the rich information and the availability of the user on one or more rich information transfer channels. Moreover, in an embodiment RSAPP enhances the rich information by one or more of a plurality of automatic enhancements including, for example, replacing Uniform Resource Locator (URL) links within SMS information with one or more of images, video, and other rich media; and automatically adding an interactive button based on the content of the SMS message to deliver a suggested reply or suggested action to the SMS message. For example, (1) in the case of one-time passwords (OTP), RSAPP 302 adds the proposed copy action to the SMS message; (2) In the case of information with a URL, RSAPP 302 adds a suggested action to open the website to the SMS message; and (3) based on some other content, RSAPP add suggested actions to open map locations, share locations, select menu options, and so on. Thus, the creation of rich information includes adding automatic enhancements to SMS information received from brands/developers 301.
The rich Short Message Service (SMS) application (RSAPP) 302 receives an acknowledgement of the rich information delivered to the information delivery client 304a on the user device 304 through one or more information delivery platforms 303 and associated information delivery Application Programming Interfaces (APIs). Also, in the case where an interactive button for transmitting one or more of the suggested replies and suggested actions is provided in the rich information, RSAPP 302 receives a confirmation about the selection of one option from the user device 304 of the user. RSAPP 302 communicates a selection of one of the suggested replies and suggested actions received from the user's user device 304 to brand/developer 301. In an embodiment RSAPP 302 communicates a selection of one of the suggested replies and suggested actions received from the user's user device 304 to brand/developer 301 by sending back person-to-application (P2A) information on an SMS Application Programming Interface (API) or by using a short message peer-to-peer (SMPP) protocol. When it is determined that the user's mobile phone number is not available to the one or more information delivery platforms 303, RSAPP 302 confirms whether the setting from the brand/developer 301 specifies to transmit the received SMS message to the user's mobile phone number and transmits the received SMS message to the user's mobile phone number. RSAPP 302 sends confirmation of the back-off delivered SMS message to the brand/developer 301.
In an embodiment, the method disclosed above is performed using an Application Programming Interface (API) provided by RSAPP to developer 301.
FIG. 4 illustrates a schematic diagram of a process flow for creating and transmitting rich information triggered by a brand or a developer 301 representing a brand using one or more Application Programming Interfaces (APIs), protocols, applications, and software tools. The methods disclosed herein are performed using, for example, one or more of the following: an API configured to transmit rich information, for example, a rich Short Message Service (SMS) (RS) API 403; an API configured to send SMS messages; a protocol arranged to send SMS messages, such as the short message peer-to-peer (SMPP) protocol; a Web service; representative state transitions (REST) (API); and a Software Development Kit (SDK) configured to enrich the information. Consider an example in which a brand or developer 301 representing a brand sends SMS information using one of an SMS API and SMPP protocol 401. The Rich SMS Application (RSAPP) 302 receives a request to send SMS information using one of the SMS API and SMPP protocol 401. RSAPP 302 parses the content of the SMS message received, for example, from SMS API 401 and identifies the content type of the received SMS message. RSAPP 302 performs identification of the content type of the received SMS message by analyzing the received SMS message to determine whether the SMS message is to be used to send, for example, one of a notification, promotion, and transaction. In an embodiment RSAPP 302 performs the analysis based on pattern matching or machine learning techniques.
The rich Short Message Service (SMS) application (RSAPP) 302 creates rich information and transmits the created rich information to the user's mobile phone number. An information delivery client 304a on a user's user device 304 receives the rich information and communicates with the user device via one or more information delivery platforms 303 (e.g., rich Communication Services (RCS) 303a,303B, apple/>303C, other platforms 303z, etc.) and an associated information delivery Application Programming Interface (API) to send a confirmation of the received rich information to RSAPP a 302. After transmitting the created rich information to the user's mobile phone number, RSAPP 302 receives a confirmation from information client 304a that the rich information is being received. In an embodiment RSAPP 302 sends a delivery receipt to the brand or to the developer 301 on behalf of the brand in the form of an SMS delivery receipt status sent on SMS API 401 or as a message type Short Message Service Center (SMSC) delivery receipt (e.g. delivery_sm information or data_sm information sent on short message peer-to-peer (SMPP) protocol 401), i.e. an acknowledgement about the rich information delivery to the user's mobile phone number, depending on the API or protocol on which RSAPP 302 receives the SMS message. In another embodiment RSAPP 302 transmits a delivery receipt, i.e., a confirmation about the delivery of the information, by invoking a callback Uniform Resource Locator (URL) and associated required parameters specified in the rich information template by the brand or developer 301 representing the brand.
In an embodiment, a rich Short Message Service (SMS) application (RSAPP) 302 receives a read receipt from an information delivery client 304a on a user device 304 through one or more information delivery platforms 303 and associated information delivery Application Programming Interfaces (APIs) indicating that the rich information has been read or seen by a user. In an embodiment RSAPP 302 transmits a read response piece to the brand or to the developer 301 representing the brand indicating that the information has been read or seen by the user, either in the form of read response piece status information sent on SMS API 401 or as an information type Short Message Entity (SME) delivery acknowledgement in the delivery_sm information or data_sm information sent on short message peer-to-peer (SMPP) protocol 401. In another embodiment RSAPP 302 transmits the read receipt by setting the information status field in the short message parameter to "receive" in the delivery_sm information sent over SMPP protocol 401. In another embodiment RSAPP 302 transmits the read receipt by sending a person-to-application (P2A) SMS message with text (e.g., "information read") from the user's mobile phone number to the brand. In another embodiment RSAPP 302 transmits the read receipt by invoking a callback Uniform Resource Locator (URL) and associated required parameters specified in the rich information template by the brand or developer 301 representing the brand.
Also, in an embodiment, the rich Short Message Service (SMS) application (RSAPP) 302 determines whether the user's mobile phone number supports delivery of rich information or does not support delivery of rich information, and thus transmits the received SMS information as rich information or as standard SMS information, respectively. In an embodiment, a brand or a developer 301 representing the brand can add optional support for suggested replies and/or suggested actions by implementing a callback method for these actions, even when using an existing SMS Application Programming Interface (API). RSAPP 302 receives a confirmation from the user device 304 of the user regarding the selection of one of the suggested replies. In an embodiment RSAPP 302 transmits confirmation about the user's selection of suggested replies or suggested actions to the brand or to the developer 301 on behalf of the brand by sending a person-to-application (P2A) SMS message with text from the user's mobile phone number to the brand 301 specifying the user's selection of suggested replies or suggested actions and the associated additional optional parameters. In another embodiment RSAPP 302 transmits a confirmation to the brand or to the developer 301 on behalf of the brand that the user selects the suggested reply or suggested action by sending a P2A SMS message from the user's mobile phone number to the brand, invoking a callback Uniform Resource Locator (URL) specified in the rich information template, and the associated required parameters. In another embodiment RSAPP transmits a confirmation about the user selection suggestion reply, but does not transmit a confirmation about the user selection suggestion action, as specified in the rich information template.
Also, in an embodiment, a brand or brand-representative developer 301 uses one of a Short Message Service (SMS) Application Programming Interface (API) and short message peer-to-peer (SMPP) protocol 401, a Rich SMS (RS) Software Development Kit (SDK) 402, and an RS API 403 for sending SMS information. The Rich SMS Application (RSAPP) 302 uses one of the SMS API and SMPP protocols 401, RSSDK, 402 and RS API 403 to receive a request to send SMS information. RSAPP 302 parses the content of the SMS message received from one of the SMS API 401, RSSDK 402 and RS API 403 and identifies the content of the received SMS message. RSAPP 302 performs identification of the content by analyzing the received SMS message to determine whether the SMS message is to be used to send one of a notification, promotion, and transaction. RSAPP 302 performs analysis based on pattern matching or machine learning techniques. RSAPP 302 a 302 creates rich information and transmits the created rich information to the user's mobile phone number.
Fig. 5 illustrates an architectural block diagram of an example embodiment of a system 5000 for creating and transmitting rich information. The system 5000 disclosed herein is a computer system which is programmable using a high level computer programming language. The system 5000 may be accessed by brands or by brand-representing developers 301 through the network 5004 by a broad spectrum of techniques and devices such as personal computers, laptop computers, mobile computing devices, smart phones, tablet computing devices, servers, workstations, portable electronic devices, network-enabled computing devices, network-enabled communication devices, any other suitable computing device, combinations of multiple computing devices, and the like, which may access the internet. Further, the system 5000 communicates with a plurality of information delivery platforms 303 through a network 5004. Information delivery platform 303 includes, for example, rich Communication Services (RCS), WHATSAPP LLCApple Inc. >/>, Viber MEDIA SARLFacebook IncMessenger et al. Also, the information delivery platform 303 may access the user device 304 through the network 5004. User device 304 is an electronic device, such as one or more of the following: personal computers, tablet computing devices, mobile computers, mobile phones, smart phones, portable computing devices, laptops, personal digital assistants, wearable computing devices (e.g., smart glasses, smart watches, etc.), touch-centric devices, workstations, client devices, portable electronic devices, network-enabled computing devices, network-enabled communication devices, image capture devices, any other suitable computing device, a combination of multiple computing devices. The user device 304 comprises for example the/>, in google corporationPlatform, apple iOS platform, microsoft corporation/>Platform and other platform-implemented information delivery clients 304a. The information delivery client 304a is arranged to receive information, such as Short Message Service (SMS) information, rich information, etc., over the network 5004. The information delivery client 304A is, for example, WHATSAPP LLC/>Instant messaging application, apple IncInstant messaging application, viber MEDIA SARL/>/>, Facebook incMessenger et al.
The system 5000 interfaces with devices and information delivery platform 303 of brands or brand-representing developers 301, and in turn interfaces with user devices 304, in embodiments with one or more database systems (not shown) and servers (not shown) to implement rich Short Message Services (SMS), so a plurality of specially programmed computing systems are used to implement rich SMS. The network 5004 is, for example, one of: internet, satellite Internet, wireless network, wi-FI ALLIANCE CorporationUltra Wideband (UWB) communication network, wireless Universal Serial Bus (USB) communication network, and implementation of ZigBee alliance corporation/>A General Packet Radio Service (GPRS) network, a mobile telecommunications network (e.g., a Global System for Mobile (GSM) communication network), a Code Division Multiple Access (CDMA) network, a third generation (3G) mobile communication network, a fourth generation (4G) mobile communication network, a fifth generation (5G) mobile communication network, a Long Term Evolution (LTE) mobile communication network, a public telephone network, etc., a local area network, a wide area network, an internet connection network, an infrared communication network, etc., or a network formed by any combination of these networks.
As shown in the example of fig. 5, the system 5000 includes: at least one processor 5001; an Application Programming Interface (API) 5002, the Application Programming Interface (API) 5002 being arranged for enriching information; and a non-transitory computer-readable storage medium, such as memory unit 5003. "non-transitory computer readable storage medium" as used herein refers to all computer readable media that contain and store computer programs and data. Examples of a computer readable medium include a hard disk drive, a solid state drive, an optical or magnetic disk, a memory chip, read Only Memory (ROM), register memory, processor cache, random Access Memory (RAM), and the like. The system 5000 further comprises a rich Short Message Service (SMS) application (RSAPP) 302, the rich Short Message Service (SMS) application (RSAPP) 302 being arranged to determine computer program instructions executable by the at least one processor 5001. A non-transitory computer readable storage medium (referred to herein as the memory unit 5003, for example) is provided to store the computer program instructions determined by RSAPP a 302. In an embodiment, the memory unit 5003 stores RSAPP respective modules 302a, 302b, 302c, 302d, 302e, 302f, 302g, 302h, 302i, and 302j of the module 302 as exemplarily shown in fig. 5.
The processor 5001 is operatively and communicatively connected to the memory unit 5003 for executing computer program instructions determined by the modules (e.g., 302a, 302b, 302c, 302d, 302e, 302f, 302g, 302h, 302i, etc.) of the rich Short Message Service (SMS) application (RSAPP) 302. The memory unit 5003 is a memory unit for recording, storing, and reproducing data, program instructions, and applications. In an embodiment, the memory unit 5003 includes Random Access Memory (RAM) or another type of dynamic storage device, serving as read-write internal memory, and providing short-term or temporary storage for information and instructions executable by the processor 5001. Memory unit 5003 also stores temporary variables and other intermediate information used when executing instructions by processor 5001. In another embodiment, the memory unit 5003 also includes a Read Only Memory (ROM) or another type of static storage device that stores firmware, static information, and instructions for execution by the processor 5001. When loaded into memory unit 5003 and executed by processor 5001, the modules (e.g., 302a, 302b, 302c, 302d, 302e, 302f, 302g, 302h, 302i, and 302 j) of RSAPP transform system 5000 into specially programmed, special-purpose computing devices configured to perform the functions described herein. The processor 5001 refers to one or more microprocessors, central Processing Unit (CPU) devices, finite state machines, computers, microcontrollers, digital signal processors, logic devices, application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs), chips, etc., or any combination thereof, capable of executing a computer program or a series of commands, instructions, or state transitions. In an embodiment, the processor 5001 is implemented as a processor complex including, for example, a programmed microprocessor and a math or graphics coprocessor. RSAPP 302 is not limited to use with the processor 5001. In an embodiment RSAPP employs a controller or microcontroller.
The rich Short Message Service (SMS) application (RSAPP) 302 determines computer program instructions that, when executed by the processor 5001, will cause the at least one processor 5001 to manage actions associated with creating and transmitting rich information. In the example embodiment shown in fig. 5, RSAPP includes a receiving module 302a, a processing module 302b, a routing module 302c, a rich information creating module 302d, a transmitting module 302e, a responding module 302f, a rerouting module 302g, a feedback module 302h, a billing module 302i, a database 302j, and a caching module 302k. The receiving module 302a is arranged to receive a request to send SMS information from the brand or a developer 301 representing the brand to the mobile phone number of the user.
The processing module 302b is configured to process a request to send Short Message Service (SMS) information. The routing module 302c is arranged to determine whether the user's mobile phone number is enabled on one or more of the plurality of rich information transfer channels provided by the information transfer platform 303 by executing a channel specific command on each rich information transfer channel for the user's mobile phone number. For example, a rich communication service contact capability check command is executed to determine whether a user's mobile phone number can be used for a Rich Communication Service (RCS). Rich information transfer channels include, for example, rich Communication Services (RCS), WHATSAPP LLCApple Inc. >/>, Viber MEDIA SARLTelegram FZ-LLC/>/>, Facebook incGoogle Business Messages, signal Technology Foundation of Messenger, google LLC/>PRIVATE MESSENGER, etc. Upon determining that the user's mobile phone number is enabled on one or more rich information transfer channels, the rich information creation module 302d creates rich information including information and brand identification with optional authentication marks. In an embodiment, database 302j stores the created rich information. Database 302j is any storage area or medium that can be used to store rich information and rich media contained in the rich information. In an embodiment, database 302j is any one of a Structured Query Language (SQL) database or more than just a SQL (NoSQL) database. In an embodiment, database 302j is a location on a file system. In another embodiment, database 302j is configured to be remotely accessible by Rich SMS Application (RSAPP) 302 in system 5000 over network 5004. In another embodiment, database 302j is configured as a cloud-based database implemented in a cloud computing environment. The cache module 302K is configured to store the enablement status of each mobile phone number based on a received response to an explicit or implicit capability check command of the RCS or an equivalent command of other rich information transfer channels. The transmission module 302e is arranged to transmit the created rich information to the mobile phone number of the user on the enabled rich information transfer channel. When it is determined that the mobile phone number of the user is not enabled on the rich information transfer channel, the routing module 302c confirms whether the setting designates transmission of the received SMS information to the mobile phone number of the user. The transmission module 302e is arranged to transmit the received SMS message to the mobile phone number of the user.
In an embodiment, the routing module 302c is arranged to determine whether a mobile phone number can be used for one or more of the plurality of rich information transfer platforms 303, and the rich information creating module 302d is arranged to determine the type of rich information to be transferred to the mobile phone number via the rich information transfer platform 303 and create suitable rich information. In another embodiment, the routing module 302c is configured to determine whether the user's mobile phone number can be used for Rich Communication Services (RCS); the rich information creation module 302d is configured to create RCS information; and the transmission module 302e is arranged to transmit the created RCS information to the mobile phone number of the user via the enabled RCS. In an embodiment, the routing module 302c executes an RCS contact capability check command for the mobile phone number to determine whether the mobile phone number is available for RCS.
In an embodiment, the routing module 302c stores the enablement status of the mobile phone numbers of the one or more rich information transfer platforms 303 in a local cache, such as a rich information transfer cache configured for one or more rich information transfer channels and an RCS cache configured for an RCS information transfer channel. In an embodiment, the entries in the RCS cache include one entry for each unique mobile phone number, with the following exemplary attributes:
(1) Keys for each entry in the RCS cache: a mobile telephone number;
(2) Mandatory properties stored in the RCS cache in entries for each key: RCS enabled status (enabled/not enabled); and
(3) Additional (optional) attributes stored in the RCS cache in the entry for each key, including, for example:
a) Information of a platform (MaaP) Identifier (ID) as RCS MaaP serving the mobile phone number;
b) A last timestamp when the RCS enablement status is known based on explicit or implicit capability checking; and
C) Expiration time of the cache entry.
In an embodiment, the routing module 302c searches the rich information cache or RCS cache for an entry for the user's mobile phone number before executing the RCS capability check command. RSAPP performs an explicit capability check or an implicit capability check when there is no entry for the mobile phone number in the RCS cache, or when the entry for the mobile phone number has expired.
In another embodiment, the routing module 302c is configured to determine whether the user's mobile phone number can be used for WhatsApp; the rich information creation module 302d is configured to create WhatsApp information; and the transmission module 302e is arranged to transmit the created WhatsApp information to the user's mobile phone number. In an embodiment, the routing module 302c executes the WhatsApp contact command for the mobile phone number to determine whether the mobile phone number is available for WhatsApp. In another embodiment, the rich information creation module 302d and the transmission module 302e are configured to create standard short message service information and transmit it to the user's mobile phone number when the routing module 302c determines that the mobile phone number cannot be used for any rich information transfer channel (e.g., rich Communication Services (RCS), whatsApp, iMessage, viber, etc.). The transmission module 302e transmits the rich information to the user's mobile phone number over the network 5004. The transmission module 302e delivers the rich information to a default information delivery application, i.e., an information delivery client 304a deployed on a user device 304, the user device 304 having a Subscriber Identity Module (SIM) representing the user's mobile phone number. In an embodiment, the transmission module 302e passes the rich information into a data information transfer application 304a on the user device 304 (the user device 304 is registered on the user's mobile phone number). In an embodiment, the routing module 302c stores the enablement status of the mobile phone numbers of the one or more rich information transfer platforms 303 in a local cache, e.g., a rich information transfer cache configured for one or more rich information transfer channels and a rich information transfer cache configured for one or more rich information transfer channelsWhatsApp cache of information transfer channel. In an embodiment, the entries in the WhatsApp cache include one entry for each unique mobile phone number, with the following example attributes:
(1) Keys for each entry in the RCS cache: a mobile telephone number;
(2) Mandatory properties stored in the RCS cache in entries for each key: whatsApp enabled status (enabled/not enabled); and
(3) Additional (optional) attributes stored in the WhatsApp cache in the entry for each key, including, for example:
a) Information of a platform (MaaP) Identifier (ID) as WHATSAPP MAAP serving the mobile phone number;
b) A last timestamp when the WhatsApp enabled state is known based on explicit or implicit capability checking; and
C) Expiration time of the cache entry.
In an embodiment, the routing module 302c searches the rich information cache or WhatsApp cache for an entry of the user's mobile phone number before executing the WhatsApp capability check command. RSAPP performs an explicit capability check or an implicit capability check when there is no entry for the mobile phone number in the WhatsApp cache, or when the entry for the mobile phone number has expired.
The input for creating and transmitting the rich information is received from one of a rich Short Message Service (SMS) application (RSAPP) Application Programming Interface (API) 5002, an API configured to transmit Short Message Service (SMS) information, a protocol configured to transmit SMS information, an application configured to transmit SMS information, an API configured to transmit rich information, a protocol configured to transmit rich information, and an application configured to transmit rich information. In an embodiment, API 5002 receives SMS information along with the user's mobile phone number and an identifier of a rich information template created by the brand or developer 301 representing the brand. The routing module 302c determines whether the user's mobile phone number can be used for one or more rich information delivery platforms 303 and other data information delivery applications, such as Rich Communication Services (RCS), whatsApp, iMessage, viber, etc. The rich information creation module 302d converts the SMS information into rich information based on the rich information delivery platform 303 and the identified rich information template determined by the routing module 302 c. The transmission module 302e transmits the rich information to the mobile phone number through one or more rich information delivery platforms 303 and other data information delivery applications. In an embodiment, the routing module 302c relies on the transmission module 302e to implicitly determine whether the recipient's mobile phone number is enabled on one or more rich information platforms 303.
In an embodiment, an Application Programming Interface (API) 5002 receives Short Message Service (SMS) information from an SMS Application Programming Interface (API). The receiving module 302a receives the SMS message from the API 5002 and passes the SMS message to the processing module 302b. The processing module 302b parses the received SMS message and determines whether the user's mobile phone number is enabled on one or more rich information transfer channels and determines the type of rich information to be transmitted to the mobile phone number over the one or more rich information transfer channels. The rich information creation module 302d creates rich information when the user's mobile phone number is enabled on one or more rich information transfer channels. The transmission module 302e transmits the created rich information to the user device 304 of the user through the enabled rich information transfer channel. When the received SMS message is identified as not available for one or more rich information delivery channels, the routing module 302c transmits the standard SMS message.
The information delivery client 304a on the user device 304 associated with the user's mobile phone number receives the transmitted rich information as illustrated in the examples of fig. 8A-13. The transmission module 302e communicates the rich information from a trusted sender Identifier (ID) (e.g., richSMS, as shown by way of example in FIG. 13) or from a sender ID (e.g., "United air", "ALDI", "MMA Connect", "New Museum", etc., as shown by way of example in FIGS. 8B-8D, 9B-9C, 10B-10D, 11B-11C, and 12B) built from brands that send the rich information. In an embodiment, the service provider verifies the brand identity included in the rich information. In an embodiment, the rich information further comprises one or more of a plurality of interactive buttons. The interactive buttons include, for example, a suggested reply button, a suggested action button, and a brand-specific action button. The user responds to the brand or sends a user response to the brand by selecting the suggested reply button. The user performs an action on the user device 304 by selecting a suggested action button or a brand-specific action button. The response module 302f receives a selection of a suggested reply button, a suggested action button, or a brand-specific action button from the user device 304 of the user. In an embodiment, the response module 302f is configured to receive status information from the information delivery client 304a on the user device 304, the status information including, for example, one or more of a delivery receipt, a delivery failure, a read receipt, and the like.
The feedback module 302h is arranged to send the delivery status, the read status, the timeout and the user's selection of suggested replies and/or suggested actions to the brand or to the developer 301 representing the brand. The user transmits the suggested replies by selecting or clicking on a suggested reply button displayed on a Graphical User Interface (GUI) 304B of information delivery client 304a in order to transmit a response to the brand, as illustrated by way of example in fig. 11B-11C. The user communicates the suggested actions by selecting or clicking on suggested action buttons displayed on GUI 304b of information transfer client 304a to take actions on the device, such as making a call, opening a website, sharing a location, etc., as illustrated by examples in fig. 8C, 9C, and 13. In an embodiment, the receiving module 302a is arranged to receive a user selection from the information delivery client 304a of the user device 304 and to deliver the user selection to the feedback module 302h. The feedback module 302h is arranged to process actions corresponding to the status and selections received from the receiving module 302a and/or the response module 302 f. In an embodiment, feedback module 302h is configured to provide feedback to the brand on the selection received by receiving module 302a and/or response module 302f by sending a user reply and/or a callback of an action to brand 301 on Application Programming Interface (API) 5002. Brand 301 is free to process feedback received from rich Short Message Service (SMS) application (RSAPP) 302 regarding user replies and/or actions, or take some other action in response to user replies and/or actions. Feedback module 302h also provides feedback to brand or developer 301 on behalf of the brand regarding read receipts that convey status and rich information to allow the brand to take appropriate action. For example, when the rich information is read, the feedback module 302h notifies the brand/developer 301 that the rich information has been read. In another embodiment, the feedback module 302h is arranged to provide feedback to the brand/developer 301 about the information delivery platform 303 for sending rich information to the user's mobile phone number. In another embodiment, feedback module 302h is configured to provide feedback to brand/developer 301 when routing module 302c determines that the mobile phone number is not available for any rich information transfer channel, and brand/developer 301 does not select an option that causes RSAPP to transmit Short Message Service (SMS) information as standard SMS information to the user's mobile phone number, thereby allowing brand/developer 301 to take an alternative action, e.g., to itself send the SMS information as standard SMS information.
The routing module 302c is arranged to determine rich data information transfer capabilities of the plurality of information transfer platforms 303, and the rich information creation module 302d maps requests from brands/developers 301 onto information transfer platform specific capabilities in order to create rich information and instructs the transmission module 302e to transmit the created rich information to the user device 304. The rich information creation module 302d is arranged to use information in a rich information template determined by the brand or by the developer 301 representing the brand to convert the request for rich information into rich information that can be transferred to the information transfer platform 303 determined by the routing module 302 c. The response module 302f is configured to monitor delivery of the rich information to the user's mobile phone number and to respond to user replies/actions to the rich information. The rerouting module 302g is arranged to transfer the rich information to the user, possibly through one or more further information transfer platforms, when there is a transfer failure or delay of the mobile phone number transferring the rich information to the user through the first information transfer platform. Additional information delivery platforms include, for example, alternative data information delivery platforms and short message service platforms. In an embodiment, the rerouting module 302g is arranged to transmit the rich information over a plurality of rich information transfer channels to increase the overall chance of successful delivery of the rich information. In an example, the rerouting module 302g passes when the rich information is not communicated over a Rich Communication Service (RCS) channel within a predetermined time intervalThe information transfer channel delivers rich information to the user's mobile telephone number.
In an embodiment, the rerouting module 302g delivers the rich information as standard Short Message Service (SMS) information to the user's mobile phone number when the rich information cannot be delivered on any rich information platform or rich information transfer channel within a predetermined time interval. In another embodiment, the rerouting module 302g is configured to withdraw the rich information from the first information transfer platform before attempting to transfer the rich information on the second information transfer platform. Withdrawing rich information from the first information transfer platform helps avoid receiving duplicate rich information by the user, and in embodiments helps avoid additional costs transferred across multiple information transfer platforms. The second information transfer platform is another data information transfer platform or SMS platform. In an embodiment, the rerouting module 302g uses the rich information creating module 302d and the transmitting module 302e to create and deliver rich information to the user via the second information delivery platform. In an embodiment, the rerouting module 302g is arranged to monitor the mobile phone number of the rich information delivered to the user via the second information platform. The rerouting module 302g is further configured to deliver the rich information to the mobile phone number of the user via one or more of the third information delivery platform and the fourth information delivery platform when there is a delivery failure or delay in delivering the rich information to the mobile phone number of the user via the second information delivery platform. The rich information creating module 302d is arranged to convert the SMS information into rich information to be transmitted to the mobile phone number based on the selected second, third and fourth messaging platforms, and the rich information template determined by the brand or by the developer 301 representing the brand. In another embodiment, the rerouting module 302g is configured to withdraw the rich information from the other plurality of rich information transfer channels once the rich information is communicated over one or more of the plurality of rich information transfer channels.
Billing module 302i is configured to charge brand/developer 301 a fee for creating the rich information and transmitting it to user device 304. Data information transfer platforms (e.g. Rich Communication Services (RCS), Etc.) may charge a fee to the application for the person (A2P) information, which may be a higher or lower fee than for the Short Messaging Service (SMS) information. Thus, when the Rich SMS Application (RSAPP) 302 transmits rich information to the user's mobile phone number, the rich information will typically be charged for A2P information fee, which A2P information fee may be given to the data information platform for transmitting the rich information. Also, when the user responds to rich information, some data information transfer platforms may charge a per-period fee instead of per-information fee. However, it may be desirable to pay for the rich information at a different price than the per A2P information fee or per period fee for transmitting other A2P information or other period fees on the data information transfer platform. The processing module 302b tracks the amount of rich information sent and suggested replies or suggested actions received in the database 302j and enables the billing module 302i to pay for the rich information in a manner different from standard A2P and period pricing, which helps to achieve flexible pricing of the rich information sent by brands.
The processor 5001 of the system 5000 disclosed herein retrieves instructions determined by the receiving module 302a, the processing module 302b, the routing module 302c, the rich information creating module 302d, the transmitting module 302e, the responding module 302f, the rerouting module 302g, the feedback module 302h, the billing module 302i from the memory unit 5003 for performing the respective functions disclosed above. The modules 302a, 302b, 302c, 302d, 302e, 302f, 302g, 302h, 302i, and 302j of the rich Short Message Service (SMS) application (RSAPP) 302 are disclosed above as software executed by the processor 5001. In an embodiment, modules 302a, 302b, 302c, 302d, 302e, 302f, 302g, 302h, 302i, and 302j of RSAPP are implemented entirely in hardware. In another embodiment, the modules 302a, 302b, 302c, 302d, 302e, 302f, 302g, 302h, 302i, and 302j of RSAPP are implemented by logic circuitry to perform their respective functions as disclosed above. In another embodiment, the system 5000 is also implemented as a combination of hardware and software, including an Application Programming Interface (API) 5002 and one or more processors (e.g., 5001) for implementing modules (e.g., 302a, 302b, 302c, 302d, 302e, 302f, 302g, 302h, 302i, and 302 j) of RSAPP.
For purposes of illustration, the disclosure herein relates to modules 302a, 302b, 302c, 302d, 302e, 302f, 302g, 302h, 302i, and 302j of RSAPP 302 running locally on a single computer system 5000; however, the scope of RSAPP and methods disclosed herein is not limited to modules 302a, 302b, 302c, 302d, 302e, 302f, 302g, 302h, 302i, and 302j running locally on a single computer system 5000 through an operating system and processor 5001, but extends to running modules 302a, 302b, 302c, 302d, 302e, 302f, 302g, 302h, 302i, and 302j remotely on network 5004 through the use of a web browser and remote server, mobile phone, or other electronic device. In an embodiment, one or more portions of the system 5000 disclosed herein are distributed across one or more computer systems (not shown) connected to the network 5004.
A non-transitory computer-readable storage medium (referred to herein as memory unit 5003, for example) stores computer program code including computer program instructions executable by the at least one processor 5001 for creating and transmitting rich information. The computer program code includes: first computer program code for receiving a request to send Short Message Service (SMS) information from a brand to a mobile telephone number of a user; and second computer program code for processing a request to send SMS information. The second computer program code includes third computer program code for determining whether a mobile phone number of the user is enabled on one or more of the plurality of rich information transfer channels. The third computer program code includes: fourth computer program code for creating rich information, the rich information comprising information and a brand identity with an optional authentication mark; and fifth computer program code for transmitting the created rich information to the mobile phone number of the user on the enabled rich information transfer channels, wherein the fourth computer program code and the fifth computer program code are executed when it is determined that the mobile phone number of the user is enabled on one or more rich information transfer channels. The third computer program code further comprises: a sixth computer program code for confirming whether the setting specifies transmitting the received SMS information as SMS information to the user's mobile telephone number when the user is not enabled on one or more rich information transfer channels; and seventh computer program code for transmitting the received SMS message as an SMS message to the mobile phone number of the user, wherein the sixth computer program code and the seventh computer code are executed when it is determined that the mobile phone number of the user is not enabled on the one or more rich information transfer channels.
The computer program code further comprises: eighth computer program code for determining rich data information transfer capabilities of the plurality of information transfer platforms 303 and for mapping requests from the developer to information transfer platform specific capabilities; ninth computer program code for transmitting the rich information to the user device 304; tenth computer program code for monitoring delivery of the rich information to the mobile telephone number of the user; eleventh computer program code for delivering the rich information to the user's mobile telephone number through one or more additional information delivery platforms in case of a delivery failure or a delivery delay of the rich information to the user's mobile telephone number through the first information delivery platform. The computer program code further comprises: twelfth computer program code for simultaneously transmitting rich information on a plurality of rich information transfer channels to increase a transmission opportunity of the rich information; and thirteenth computer program code for revoking the rich information from the enabled other plurality of rich information transfer channels once the rich information is transferred over one rich information transfer channel.
The computer program instructions of the computer program code disclosed above implement the processes of the various embodiments disclosed above and perform additional steps that may be required and desired for creating and transmitting rich information. The computer program instructions, when executed by the processor 5001, cause the processor 5001 to perform the steps of the method for creating and transmitting rich information as disclosed in the illustrations of fig. 1-4 and fig. 6A-6E. In an embodiment, a single computer program code comprising computer program instructions performs one or more steps of the methods disclosed in the description of fig. 1-4 and fig. 6A-6E. The processor 5001 retrieves these computer program instructions and executes them.
A module or engine or unit as used herein refers to any combination of hardware, software, and/or firmware. As an example, a module or engine or unit includes hardware, such as a microcontroller, associated with a non-transitory computer-readable storage medium, in order to store computer program code suitable for execution by the microcontroller. Thus, in an embodiment, reference to a module or engine or unit refers to hardware specifically configured to identify and/or execute computer program code to be maintained on a non-transitory computer readable storage medium. In an embodiment, the computer program code comprising computer readable and executable instructions is implemented in any programming language, such as C, C ++, C#,Fortran、Ruby、/>Visual/>Hypertext Preprocessor (PHP),/>NET、Objective-/>The Swift TM programming language of Apple inc. In another embodiment, other object-oriented, functional, scripting, and/or logical programming languages are also used. In an embodiment, the computer program code or software program is stored as object code on or in one or more media. In another embodiment, the term "module" or "engine" or "unit" refers to a combination of a microcontroller and a non-transitory computer readable storage medium. Typically, the boundaries represented as individual modules or engines or units often vary and may overlap. For example, a module or engine or unit may share hardware, software, firmware, or a combination thereof, while possibly retaining some separate hardware, software, or firmware. In various embodiments, the module or engine or unit includes any suitable logic circuitry.
Fig. 6A-6E illustrate a flow chart for creating and transmitting rich information. A rich Short Message Service (SMS) application (RSAPP) receives 601SMS information from a brand or a developer on behalf of the brand for transmission to a mobile phone number of a recipient (referred to herein as a "user"). RSAPP processes 602 the received SMS message to extract the sender Identifier (ID) and the sender's account. RSAPP checks 603 if the sender ID is set to be used to enrich the rich information in the SMS template 1402, as shown in fig. 14B. RSAPP obtains 604 a list of rich information transfer channels from rich SMS template 1402 when the sender ID is set for rich information. When the sender ID is not set for rich information, RSAPP checks 605 if the sender account is set to send SMS information. RSAPP sends 606 the SMS message when the sender account is set to send SMS messages. When the sender account is not set to send SMS messages, RSAPP sends 607 a response to the brand indicating that SMS messages cannot be sent. After the list of rich information transfer channels is obtained in step 604, RSAPP determines 608 if it is explicitly checked whether the user's mobile phone number is enabled on any rich information transfer channel in the list. RSAPP proceeds to step 618 when the mobile phone number is not enabled on any rich information transfer channel in the list. RSAPP the following steps are performed for each rich information transfer channel in the list. RSAPP checks 609 if there is a cache for the rich information transfer channel. When a cache for the rich information transfer channel exists, RSAPP searches 610 the cache for the user's mobile phone number to determine if the mobile phone number is enabled on the rich information transfer channel. After step 610, RSAPP proceeds to step 613 when the mobile phone number is not enabled on the rich information transfer channel. When there is no entry for the mobile phone number in the cache, RSAPP executes 611 the command to check if the mobile phone number can be used for the rich information transfer channel. In step 609, when there is no cache for the rich information transfer channel, RSAPP executes 611 the command to check whether the mobile phone number can be used for the rich information transfer channel. At step 609, when the user's mobile phone number is not found in the cache set for the rich information transfer channel, RSAPP checks 613 if another rich information transfer channel is listed in the rich SMS template 1402. When another rich information transfer channel is listed in rich SMS template 1402, RSAPP moves 614 to the next rich information transfer channel and step 609 is repeated. In step 613, when there is no other rich information transfer channel, RSAPP executes a command to check 615 if the sender ID is set to be used as a fallback route for SMS. When yes, RSAPP sends 617 the SMS to the user's mobile phone number. When not, RSAPP sends a response 616 to the brand indicating that the information cannot be sent.
After step 611, RSAPP checks 612 if the mobile phone number is enabled on the rich information transfer channel. When the mobile phone number is enabled on the rich information transfer channel RSAPP determines 618 from the rich information template 1402 a sender Identifier (ID) to be used for sending the rich information. RSAPP proceeds to step 613 when the mobile phone number is enabled on the rich information transfer channel. RSAPP checks 619 whether the sender ID is a branded sender ID or a rich SMS sender ID. After step 619, when the sender ID is a rich SMS sender ID, RSAPP creates 620 rich information by: a) The brand name, brand logo (from image file) and rich card image (when present) are obtained 620a from rich SMS template 1402, and the rich card image is selected from the "add-on" section. When the rich card image is not available, a brand logo is obtained; b) Creating 620c a rich card, wherein the brand logo (or rich card image) is the rich media, the brand name is the title, and the SMS text is the description; and c) obtaining 620d a list of suggested actions and suggested replies from the rich SMS template and adding them to the rich card. When the sender ID is the ID of the brand, RSAPP does not use the branding logo, and will only use the rich card from the "additional enhancements" section. After step 619, when the sender ID is the sender ID of the brand, RSAPP creates 620 the rich information by: a) A rich card image is obtained 620b from the rich SMS template 1402 and selected from the "additional enhancements" section. When the rich card image is not available, a brand logo is obtained; b) Creating 620c a rich card, wherein the brand logo (or rich card image) is the rich media, the brand name is the title, and the SMS text is the description; and c) obtaining 620d a list of suggested actions and suggested replies from the rich SMS template and adding them to the rich card. When the sender ID is the ID of the brand, RSAPP does not use the branding logo, and will only use the rich card from the "additional enhancements" section.
In an embodiment, when it is determined in step 619 to send rich information from the sender ID of the brand, RSAPP creates rich information including the following elements: (1) text from the received SMS message; (2) Optional rich media (e.g., images, video, etc.), rich cards, or dials based on the "additional enhancements"/"image for rich cards" portion in rich SMS template 1402; (3) optional rich media based on the content of the received SMS; and (4) optional suggested actions and suggested replies based on the content and/or rich SMS template 1402. Then RSAPP transmits 623 the created rich information from the sender ID of the brand to the user's mobile phone number. When it is determined in step 619 that rich information from the rich SMS sender ID is sent, RSAPP creates rich information including the following elements: (1) text from the received SMS message; (2) Brand names and brand logos in the rich information template; (3) Optional rich media (e.g., images, video, etc.), rich cards, or dials based on the "additional enhancements"/"image for rich card" portion in the rich information template; (4) optional rich media based on the content of the received SMS; and (5) optional suggested actions and suggested replies based on the content and/or rich information templates. Then RSAPP transmits 623 the created rich information from the rich SMS sender ID to the user's mobile phone number.
Following step 620, RSAPP parses 621 the text of the received SMS to find the elements that can be included to add rich media and/or suggested actions. RSAPP in step 620, the created rich information is edited 622 to add rich elements, and when necessary, the text of the created rich information is edited. RSAPP transmits 623 the created rich information to the user's mobile phone number. Following step 623, RSAPP checks 624 the transmission status of the created rich information. When the user's mobile phone number is not enabled on one or more rich messaging channels, the status response indicates that the user's mobile phone number is not enabled on the rich messaging channel and RSAPP proceeds to step 613.
FIG. 7 illustrates a flow chart of an embodiment of a method for registering a brand with a rich Short Message Service (SMS) application (RSAPP) provider of a rich SMS or a developer representative of the brand. RSAPP the provider is an entity that manages RSAPP and provides RSAPP as a service to brands and developers. In an embodiment, one or more RSAPP providers provide rich SMS to brand enterprises or developers. The brand enterprise or a developer representing the brand registers a rich SMS with RSAPP provider. As part of the registration, RSAPP provider receives 701 information regarding brand identification of brands submitted by a brand enterprise or developer. The brand identity includes, for example, one or more of a brand name, a brand icon, a brand logo. The brand may also submit privacy policies and terms of use to RSAPP providers. The brand enterprise, brand, or developer specifies RSAPP providers with one or more rich information templates to be used to send rich information.
A rich Short Message Service (SMS) application (RSAPP) receives 702 a rich information template submitted by a brand enterprise, brand, or developer. The rich information template includes construction details such as one or more sender identifiers (sender IDs) and/or sender masks (sender masks) used by brands to send SMS information to users thought to require rich information transfer, a list of rich information transfer channels considered to send rich information, sender IDs for each rich information transfer channel, construction parameters representing the following example cases of transferring rich information on a rich information transfer channel: (a) Delivering all SMS messages received by RSAPP from the specified sender ID and/or sender mask; (b) Delivering only a subset of the information that matches the pattern/rule expression specified in the rich information delivery template; (c) To only a subset of users in one or more countries or one or more operators; and (d) delivering only a subset of the information transmitted within a predetermined date range, or on a predetermined day of the week, or on a predetermined hour of the day.
In an embodiment, the rich information template varies for different data information transfer applications, such as Rich Communication Services (RCS), based on the capabilities of the underlying platform,Etc. In another embodiment, the rich information template varies for different situations where rich information is sent on the same platform, such as validating banking transactions, logging into a bank account on a network, and logging into a mobile application (app) of a bank. A rich Short Message Service (SMS) application (RSAPP) performs 703 verification of brands and brand identities. In an embodiment, the verification of the brand and brand identity includes the following: 1. verifying that the information (e.g., brand names, their websites, privacy policies) provided in the organization details (shown in the example of FIG. 14A) is valid and belongs to the brand that is sending the information; 2. verifying that a brand logo (shown in the example of FIG. 14B) specified in the rich information template is owned by the brand; any other channel specific checks required for brand verification are met, such as Facebook Business Manager accounts for WhatsApp channels have been verified. The methods for verifying brands and brand identifications are provided for explanation only and should in no way be construed as limiting the embodiments disclosed herein.
RSAPP reviews and approves 704 the submitted rich information template. As part of the review, in an embodiment RSAPP provider ensures that the rich information and the fallback SMS information (at times) are one of notifications from brands, promotional information, transaction information, and other notifications. A brand or developer can specify an approved rich information template to be used when sending rich information. RSAPP use the specified and approved rich information template to transmit rich information to the user's mobile phone number or user device. In an embodiment, a brand or developer optionally adds two or more interactive buttons to a specified rich information template. Selection of the interactive button results in a callback to the brand. In another embodiment, the rich information template is reduced to a mapping of the sender ID of the SMS or sender mask and the sender ID of one or more rich information transfer channels.
Fig. 8A illustrates a screen shot of a Graphical User Interface (GUI) 304b presented by an information delivery client on a user device, thereby representing Short Message Service (SMS) information 800 received from a short number 801 to a user's mobile phone number. Consider an example in which a brand (e.g., united airlinks) sends SMS information 800 to a Rich SMS Application (RSAPP) for creating and transmitting the rich information to a user's mobile phone number, the SMS information 800 including a textual description 802 of flight details (e.g., flight number, date, time, boarding point, destination, etc.) about the user's flight. RSAPP receives a request to send SMS message 800 from the brand to the user's mobile phone number. RSAPP processes the received SMS message 800, determines whether the mobile phone number can be used for a Rich Communication Service (RCS), and creates rich information to be transmitted to the mobile phone number through the RCS. RSAPP transmits the created rich information to the user's mobile phone number through one or more enabled Rich Communication Service (RCS) channels. In an embodiment RSAPP transmits basic rich information to the user's mobile phone number, with SMS text description 802 from the brand's sender ID 803 (e.g., united airfines) along with brand icon 804 and authentication mark 805. GUI 304B presented by the information delivery client on the user device displays basic rich information to the user, as shown by way of example in fig. 8B. Branding icon 804 is displayed with each basic rich message transmitted to the user's mobile phone number. Verification indicia 805 (e.g., verification indicia) disposed alongside one or more of the brand sender ID 803, brand name, brand icon, and brand logo, indicate that the brand is verified and can be trusted by recipients of the rich information. The transmitted rich information represents an illustration of one of sender ID 803 or brand 804, as shown by way of example in FIG. 8B.
In another embodiment, the Rich SMS Application (RSAPP) transmits rich information including the suggested action button "check flight status" 806 to the user's mobile phone number, as shown by way of example in fig. 8C. Clicking on the suggest action button "check flight status" 806 opens a website with the flight status of the flight (e.g., "UA-4516") extracted from the text description 802 of the received SMS message 800. In another embodiment, RSAPP implements "check flight status" as a suggested reply, where the reply is sent back to the brand or to the developer representing the brand. The brand or developer replies to the user with details of the flight status in another message. In another embodiment RSAPP is provided byThe information delivery application sends the rich information as basic rich information to the user along with SMS text description 802 from the sender ID 803 of the brand, as well as brand icon 804 and authentication mark 805, as illustrated in the example of fig. 8D.
FIG. 9A illustrates a screen shot of a Graphical User Interface (GUI) 304b presented by an information delivery client on a user device, thereby representing an embodiment of Short Message Service (SMS) information 900 received from a sender mask 901 (e.g., "DL-ALD-01") to a user's mobile phone number. Consider an example in which a brand (e.g., ALdI) sends SMS information 900 to a Rich SMS Application (RSAPP) for creating and transmitting rich information to a user's mobile phone number, the SMS information 900 including a text description 902 of a bid and a Uniform Resource Locator (URL) link 903 to a brand bid page. RSAPP receives a request to transfer SMS message 900 from the brand to the user's mobile phone number. RSAPP processes the received SMS message 900, determines whether the mobile phone number can be used for a Rich Communication Service (RCS), and creates rich information to be transmitted to the mobile phone number through the RCS when the mobile phone number can be used for the RCS. RSAPP sends the created rich information from the sender ID (e.g., "ALdI") specified by the brand in the rich information template 1402 (e.g., rich SMS template) to the user's mobile phone number over a Rich Communication Service (RCS) channel, as shown in fig. 14B. In an embodiment RSAPP converts a text description 902 of SMS message 900 (referred to herein as "SMS text") into a rich card 904, the rich card 904 having an image 905 representing the brand and SMS text 902, the SMS text 902 being sent as text 906 with the rich card 904 along with the URL link, as shown in the example in fig. 9B. As shown in the example of fig. 9B, text 906 includes the entire SMS message 900 represented in fig. 9A. RSAPP determines an image 905 of the rich card 904 based on criteria and locations specified by the brand in the rich information template 1402, which is shown by way of example in FIG. 14B. For example, an image selected from the Uniform Resource Locator (URL) link "www.ALdI.us/images/weekly-ad.jpg" is used for 60% of the information in a series of arrangements, as specified by the brands in the rich information template 1402 represented by example in FIG. 14B. The use of "images for rich cards" collected in rich information template 1402 is illustrated in FIGS. 9B-9C, 11B-11C, and 12B. RSAPP transmits the rich information along with the authentication mark 908 from the brand sender ID 907 to the user's mobile phone number. RSAPP select an image 905 representing a brand from a pool of images set in rich information template 1402. In another embodiment RSAPP sends SMS text 902 and an image representing the brand, and the image is not derived from SMS message 900, as shown in the examples in FIGS. 8B-8C and 13. An image representing a brand is provided by the brand or a developer of the brand in the "brand logo" portion of rich information template 1402, as shown by way of example in FIG. 14B. In another embodiment RSAPP sends SMS text 902 and an image representing the brand, and the image is derived from SMS message 900, as shown by way of example in FIGS. 10B-10D. In fig. 10B-10D, an image of a boarding pass is derived from the URL link in fig. 10A.
In another embodiment, upon creation of the rich information, a rich Short Message Service (SMS) application (RSAPP) converts the text description 902 of the SMS message 900 into a rich card 904, the rich card 904 having an image 905 representing the brand and the text description 902 of the SMS message 900, the text description 902 being sent as text 906 with the rich card 904. Also, RSAPP converts the Uniform Resource Locator (URL) link from the text description 902 in the SMS message 900 into a suggested action button "offer" 910 in the rich message, as shown in fig. 9C. RSAPP sends rich information from brand sender ID 907 (e.g., ALDI) to the user, along with brand icon 909 and verification mark 908, as shown in the example of FIG. 9C.
Fig. 10A illustrates a screen shot of a Graphical User Interface (GUI) 304b presented by an information delivery client on a user device, thereby representing another embodiment of Short Message Service (SMS) information 1000 received from a short number 1001 to a user's mobile phone number. Consider an example in which a brand (e.g., united airlinks) sends SMS information 1000 to a Rich SMS Application (RSAPP) for creating and transmitting the rich information to a user's mobile phone number, the SMS information 1000 including a text description 1002 about boarding passes and a Uniform Resource Locator (URL) link 1003 to a boarding pass. RSAPP receives a request to send SMS message 1000 from the brand to the user's mobile phone number. RSAPP processes the received SMS message 1000, determines whether the mobile phone number can be used for a Rich Communication Service (RCS), and creates rich information to be transmitted through the RCS when the mobile phone number can be used for the RCS. RSAPP transmits the created rich information to the user's mobile phone number through one or more enabled Rich Communication Service (RCS) channels. In an embodiment RSAPP sends text description 1002 of SMS message 1000 as SMS message 1004 along with brand icon 1005 and replaces URL link 1003 in text description 1002 of SMS message 1000 with image 1006 of a boarding pass, as shown in the example of fig. 10B. RSAPP transmits rich information (including SMS information 1004 with brand icon 1005 and image 1006) along with authentication mark 1008 from brand sender ID 1007 (e.g., united air) to the user's mobile phone number.
In another embodiment, a rich Short Message Service (SMS) application (RSAPP) is provided byThe information delivery application transmits the created rich information to the user's mobile phone number. RSAPP conveys the text description 1002 of the SMS message 1000 as SMS message 1004 and replaces the Uniform Resource Locator (URL) link 1003 in the text description 1002 of the SMS message 1000 with the image 1006 of the boarding pass, as shown in the example in fig. 10C. RSAPP transmits rich information including SMS message 1004 and image 1006 along with brand icon 1005 and authentication mark 1008 from brand sender ID 1007 (e.g., united air) to the user's mobile phone number.
In another embodiment, a rich Short Message Service (SMS) application (RSAPP) is provided byMessenger transmits the created rich information to the user's mobile phone number. RSAPP transmits text description 1002 of SMS message 1000 as SMS message 1004 with brand icon 1005, and replaces Uniform Resource Locator (URL) link 1003 in text description 1002 of SMS message 1000 with image 1006 of a boarding pass with brand icon 1005, as shown in the example of fig. 10D. RSAPP transmits rich information including SMS information 1004 with brand icon 1005 and image 1006 with brand icon 1005 along with brand icon 1005 from brand sender ID 1007 (e.g., united air) to the user's mobile phone number.
Fig. 11A illustrates a screen shot of a Graphical User Interface (GUI) 304b presented by an information delivery client on a user device, thereby representing another embodiment of Short Message Service (SMS) information 1100 received from a short number 1101 to a mobile phone number of a user. Consider an example in which a brand (e.g., mobile Marketing Association (MMA)) sends SMS message 1100 to a Rich SMS Application (RSAPP) for creating and transmitting rich information to a user's mobile phone number, the SMS message 1100 including a text description 1102 about the last opportunity to register an MMA connection, and a reply keyword. RSAPP receives a request to transmit SMS message 1100 from the brand to the user's mobile phone number. RSAPP processes the received SMS message 1100, determines whether the mobile phone number can be used for a Rich Communication Service (RCS), and creates rich information to be transmitted to the mobile phone number through the RCS when the mobile phone number can be used for the RCS. RSAPP transmits the created rich information to the user's mobile phone number through a Rich Communication Service (RCS). In creating the rich information RSAPP converts the text description 1102 of the SMS message 1100 into a rich card 1103 having an image 1104 representing the brand, and the text description 1102 of the SMS message 1100 is sent as text 1105 accompanying the rich card 1103, as shown in the example in fig. 11B. The rich information also includes suggested reply buttons 1106, e.g. "save", "MMA", "help", "stop", etc., added to the text description 1102 of the SMS message 1100 for reply keywords extracted therefrom, as shown by example in fig. 11B. RSAPP select image 1104 from a rich information template submitted by the brand. In an embodiment RSAPP extracts image 1104 from text description 1102 of SMS message 1100 shown in fig. 11A. In an embodiment RSAPP transmits the rich information along with the authentication mark 1108 from the brand sender ID 1107 (e.g., mmaconnect) to the user's mobile phone number, as shown in the example in fig. 11B. In another embodiment RSAPP transmits rich information from brand sender ID 1107 to the user's mobile phone number without a verification tag, as shown in the example of FIG. 11C.
Fig. 12A illustrates a screen shot of a Graphical User Interface (GUI) 304b presented by an information delivery client on a user device, thereby representing another embodiment of Short Message Service (SMS) information 1200 received from a trombone 1201 to a user's mobile phone number. Consider an example in which a brand (e.g., newark Museum) sends an SMS message 1200 to a Rich SMS Application (RSAPP) for creating and transmitting the rich message to a user's mobile phone number, the SMS message 1200 including a text description 1202 with welcome text from Newark Museum and a text menu including: "1 for museum time", "2 for ticket purchase", and "3 for membership". RSAPP receives a request to transfer SMS message 1200 from the brand to the user's mobile phone number. RSAPP processes the received SMS1200, determines whether the mobile phone number can be used for a Rich Communication Service (RCS), and creates rich information to be transmitted through the RCS when the mobile phone number can be used for the RCS. RSAPP transmits the created rich information to the user's mobile phone number through one or more enabled Rich Communication Service (RCS) channels. In creating the rich information RSAPP converts the text description 1202 of the SMS message 1200 into a rich card 1203, the rich card 1203 having an image 1204 representing the brand and popular text sent as text accompanying the rich card 1203, and replaces the text menu, such as museum time, ticket purchase and membership, with a suggestion reply button 1205, as shown in the example of fig. 12B. RSAPP transfer the rich information along with the authentication mark 1207 from the brand sender ID 1206 (e.g., newark Museum) to the user's mobile phone number, as shown in the example of FIG. 12B.
FIG. 13 illustrates a screen shot of a graphical user interface presented by an information delivery client on a user device, thereby representing an embodiment of rich information received by a user from an authenticated sender ID 1301 (e.g., sender ID "RichSMS"), with brand identification of each brand sending their rich information. FIG. 13 illustrates rich information including a rich card 1302, authentication mark 1303, and brand logo 1304 of each brand (e.g., united air and ALDI) that sent the rich information. The rich information also includes suggested action buttons, such as "check flight status" 1305 and "quote" 1306, which are configured to enable the user to perform actions, such as check flight status, check quote, etc.
Fig. 14A-14C illustrate screen shots of user interfaces 1401, 1402, and 1403 provided by a rich Short Message Service (SMS) application (RSAPP) provider for rich SMS registration. The brand or developer representing the brand registers rich SMS of the brand by submitting brand details on the user interface 1401 represented by way of example in fig. 14A, including, for example, company name, surname and name of the contact, electronic mail (email) address, mobile phone number, industry type, web site Uniform Resource Locator (URL), privacy policy URL, callback URL, etc. After registration, the brand or developer submits rich information details, such as brand names, brand icons, brand logos, etc., to RSAPP providers. Enriching card image tags and display name tags (not shown) enable brands or developers to edit and save images, such as brand logos, brand icons, and the like. In an embodiment, a brand or developer registers a rich SMS by submitting information about the brand identity of the brand. The brand or developer specifies one or more rich information templates 1402, as shown in the example of FIG. 14B, for use by RSAPP in sending rich information to the user. Each rich template 1402 includes a plurality of elements. For example, a rich information template 1402 for a Rich Communication Service (RCS) includes: brand name, brand logo, SMS sender details including sender ID type and sender ID, rich information transfer sender details including rich information transfer channel and sender ID, fallback routing, and additional enhancements, such as images for rich cards, suggested actions, etc., as illustrated in the example of fig. 14B. The SMS sender details section of rich information template 1402 enables a brand (e.g., ALDI) or a developer on behalf of the brand to specify a sender ID type (e.g., short code, sender mask, etc.) and a sender ID (e.g., "32043," "DL-ALD-01," etc.), respectively, for use by RSAPP in transmitting SMS information to a user's mobile phone number. The details portion of the rich information transfer sender of rich information template 1402 allows brands/developers to specify one or more rich information transfer channels (e.g., RCS, whatsapp, etc.) and sender IDs (e.g., "ALDI < aldi-us@maap.dotgo.com >", "ALDI < +1-912-321-6239 >") etc., for use by RSAPP, respectively, in transferring rich information to a user's mobile phone number. At the same time as the sender ID is specified, the brand/developer specifies two parts-the sender ID indicated to the user and the internal address used by the rich information transfer channel. For example, for RCS, sender ID "ALDI < aldi-us@maap.dotgo.com >" includes "ALDI" (i.e., the sender ID to be presented to the user) and "ALDI _ us@MaaP.dotgo.com" (i.e., the internal address of the sender ID), illustratively contained within brackets "<" and ">". The fallback routing portion of rich information template 1402 allows brands/developers to confirm settings: "do it send as SMS when the user is not enabled on any rich information transfer channel? By "each setting specifies that the received SMS is transmitted to the user's mobile phone number when the user is not enabled on any rich information transfer channel.
The brand or developer representing the brand specifies account settings and rollback routing on user interface 1403, which is illustrated in FIG. 14A. The account setup portion allows brands/developers to specify account IDs, such as "information transfer partner ABC". The fallback routing section allows brands/developers to confirm settings: "is it sent as an SMS when the sender ID is not set in the rich SMS template? ", thereby specifying a mobile phone number for transmitting the received SMS to the user when the sender ID is not set in the rich SMS template.
In an example, a rich Short Message Service (SMS) application (RSAPP) receives a request to send SMS information from a short code "32043" or sender mask "DL-ALD-01" to a user's mobile phone number. RSAPP processes the SMS message in the received request and creates rich information. Upon creation of the rich information RSAPP selects an image for the rich card from the rich card file based on criteria specified by the brand/developer in rich information template 1402, as exemplarily shown in fig. 14B. For example, RSAPP selects an image from a Uniform Resource Locator (URL) link "www.ALdI.us/images/low-priority. Jpg" for use in 40% of the information in a series of arrangements, as specified by the brand/developer in rich information template 1402 represented in the example of fig. 14B. Also, RSAPP includes a suggested action button in the rich information when the SMS information includes a keyword. In an embodiment, the brand/developer determines the keywords and assigns action types and values to the keywords, as shown by example in FIG. 14B. The action types include, for example, opening a URL, dialing a telephone number, and the like. RSAPP use an information delivery platform (e.g., rich Communication Services (RCS),Or other information delivery platform) to transfer the created rich information from the sender ID specified by the brand/developer in rich information template 1402 to the user's mobile phone number.
Also, in an embodiment, elements in the rich information template are set to be based on a rich information transfer channel (e.g., RCS, Messenger、Google Business Messages、/>Etc.) to modify. For example, some elements of the rich information template may be common to all rich channels, e.g., RCS,/> Messenger、Google Business Messages、/>Etc., while other elements may have different and dedicated values for a particular channel, depending on the type of rich information transfer channel used to transmit the rich information. A rich Short Message Service (SMS) application (RSAPP) provider performs verification of brands and brand identities. RSAPP provider also examines and approves the submitted rich information template. The brand or developer specifies an approval rich information template to be used by RSAPP for sending rich information. RSAPP sends the rich information to the user device using the specified and approved rich information template. Also, the brand or developer can add multiple rich information templates to RSAPP for use by RSAPP in sending rich information to the user's mobile phone number.
It is apparent that in various embodiments, the various methods, algorithms, and computer-readable programs disclosed herein are implemented on a non-transitory computer-readable storage medium for suitable programming of a computing device. A non-transitory computer readable storage medium participates in providing data, such as instructions that are read by a computer, processor, or similar device. In various embodiments, a "non-transitory computer-readable storage medium" also refers to a single medium or multiple media, such as a centralized database, a distributed database, and/or associated caches and servers, that store one or more sets of instructions that are read by a computer, processor, or similar device. "non-transitory computer-readable storage medium" also refers to any medium that is capable of storing or encoding a set of instructions for execution by a computer, processor, or similar device and that cause the computer, processor, or similar device to perform any one or more of the steps of the methods disclosed herein. In embodiments, computer programs implementing the methods and algorithms disclosed herein are stored and transmitted in a variety of ways using a variety of media (e.g., computer readable media). In embodiments, hardwired circuitry or custom hardware is used in place of or in combination with software instructions to implement processes of the various embodiments. Thus, embodiments are not limited to any specific combination of hardware and software. Aspects of the embodiments disclosed herein are implemented in a non-programming environment that includes documents created, for example, in hypertext markup language (HTML), extensible markup language (XML), or other formats that present aspects of a Graphical User Interface (GUI) or perform other functions when viewed in a visual area or window of a browser program. Various aspects of the embodiments disclosed herein are implemented as programmed or non-programmed elements, or any suitable combination thereof.
In describing a database (e.g., database 302j, shown by way of example in FIG. 5), those of ordinary skill in the art will appreciate that (i) alternative database structures to the database structures described may be employed, and (ii) other memory structures besides databases may be employed. Any illustrations or descriptions of any sample database disclosed herein are example arrangements for storing representations of information. In embodiments, any number of other arrangements are employed in addition to those suggested by the figures or the tables shown elsewhere. In another embodiment, although the database is described as a table, other formats including relational databases, object-based models, and/or distributed databases are used to store and manipulate the data types disclosed herein. In an embodiment, the object methods or capabilities of the database are used to implement various processes, such as those disclosed herein. In another embodiment, the database is stored locally or remotely from the device accessing the data in the database in a known manner. In embodiments with multiple databases, the databases are integrated so as to communicate with each other for enabling simultaneous updating of data linked across the databases when there is any update of data in one database.
Embodiments disclosed herein are not limited to a particular computer system platform, processor, operating system, or network. One or more embodiments disclosed herein are distributed among one or more computer systems, such as servers configured to provide one or more services to one or more client computers or perform complete tasks in a distributed system. For example, one or more embodiments disclosed herein are performed on a client-server system that includes components distributed among one or more server systems that perform a plurality of functions in accordance with various embodiments. These components include, for example, executable code, intermediate code, or interpreted code that communicate over a network using a communication protocol. The embodiments disclosed herein are not limited to being executable on any particular system or group of systems and are not limited to any particular distributed architecture, network, or communication protocol.
The foregoing examples and example implementations of the various embodiments are provided for illustration only and should not be construed as limiting the embodiments disclosed herein in any way. While the embodiments have been described with reference to various example implementations, figures and techniques, it is understood that the words which have been used herein are words of description and illustration, rather than words of limitation. Moreover, although the embodiments have been described herein with reference to particular means, materials, techniques and implementations, the embodiments herein are not limited to the particulars disclosed herein; rather, the embodiments herein extend to all functionally equivalent structures, methods, systems and uses, such as are within the scope of the appended claims. Those skilled in the art, having benefit of the teachings of this specification, will appreciate that other embodiments can be devised which do not depart from the scope and spirit of the embodiments disclosed herein, and that the embodiments disclosed herein may be altered.

Claims (24)

1. A method of employing a rich short message service application that determines computer program instructions executable by at least one processor for creating and transmitting rich information, the method comprising:
Receiving a request to send short message service information from a brand to a mobile telephone number of a user;
Processing the request to send the short message service information, comprising:
Determining whether the mobile phone number of the user is enabled on one or more of a plurality of rich information transfer channels for the mobile phone number of the user;
When it is determined that the mobile phone number of the user is enabled on the one or more rich information transfer channels, performing steps comprising:
creating the rich information including information and brand identity; and
Transmitting said created rich information to said mobile telephone number of said user on said enabled one or more of said rich information transfer channels;
when it is determined that the mobile phone number of the user is not enabled on the one or more rich information transfer channels, performing steps comprising:
Confirming whether a setting designates transmission of the received short message service information as short message service information to the mobile telephone number of the user when the mobile telephone number of the user is not enabled on the one or more rich information transfer channels; and
Transmitting the received short message service information as short message service information to the mobile phone number of the user.
2. The method of claim 1, further comprising: the created rich information is communicated from one of a trusted sender identifier and a sender identifier of the brand.
3. The method according to claim 1, wherein: the rich information also includes one or more of a plurality of interactive buttons including a suggested reply button, a suggested action button, and a brand-specific action button, selecting the suggested reply button using the user device of the user allows the user to respond to the brand, and selecting one of the suggested action button and the brand-specific action button allows the user to perform an action on the user device.
4. The method of claim 1, further comprising: one of a brand enterprise and a developer registers a rich short message service with a service provider, wherein the registering includes:
receiving, by the service provider, information from the brand enterprise regarding the brand identity; and
The brand identity is verified by the service provider.
5. The method according to claim 4, wherein: the one of the brand enterprise and the developer specifies one of a plurality of rich information templates to be used for transmitting rich information to the service provider, the rich information being transmitted by the service provider to the user device of the user using the specified one of the rich information templates.
6. The method according to claim 1, wherein: is performed using one or more of an application programming interface arranged for sending short message service information, a protocol arranged for sending said short message service information, an application programming interface arranged for sending said rich information, a protocol arranged for sending said rich information, and an application arranged for sending said rich information.
7. The method of claim 1, further comprising:
determining whether the mobile phone number of the user can be used for a rich communication service; and
Determining whether the mobile phone number of the user is available for one or more of a plurality of messaging applications, wherein one of the instant messaging applications is a WhatsApp instant messaging application.
8. The method of claim 1, further comprising:
determining whether the mobile phone number of the user is linked to one of a chat robot and a user profile created by one of the brands and information delivery platforms; and
The created rich information is sent to one of the user profile and the chat bot of the brand on one or more of a plurality of information delivery platforms, wherein the information delivery platforms include Facebook Messenger, google Business Messages, and Apple Business Chat, the user profile being part of a profile stored by one or more entities including Facebook, google and Apple.
9. The method of claim 1, further comprising: selecting the one or more rich information transfer channels based on one or more of a plurality of parameters including:
The size of the short message business information;
The capabilities of multiple information delivery platforms;
The cost of transmitting the short message service information over the one or more rich information delivery channels according to standard pricing and traffic pattern based dynamic pricing;
the history of the receiver of the short message service information in terms of information transfer state and time, information reading state and time and user response; and
Consistency is maintained by sending the short message service information on a single rich information transfer channel rather than switching between the multiple rich information transfer channels.
10. The method of claim 1, further comprising: enhancing the rich information by one or more of a plurality of automated enhancements, the enhancing comprising:
replacing the uniform resource locator links within the short message service information with one or more of images, video, and other rich media; and
One of a suggested reply and a suggested action is automatically added to the short message service information based on the content of the short message service information.
11. The method of claim 1, further comprising: monitoring delivery of the created rich information to the mobile phone number of the user, wherein the monitoring comprises delivering the created rich information to the mobile phone number of the user through one or more additional information delivery platforms, including one of a surrogate data information delivery platform and a short message service platform, in the event of one of the failure of the delivery and the delay of the delivery of the created rich information to the mobile phone number of the user through a first information delivery platform.
12. The method of claim 1, further comprising: the created rich information is simultaneously transmitted on the plurality of enabled rich information transfer channels to increase the chances of delivering the created rich information.
13. A system for creating and transmitting rich information, the system comprising:
a non-transitory computer readable storage medium configured to store computer program instructions executable by at least one processor;
the at least one processor is communicatively coupled to the non-transitory computer-readable storage medium; and
A rich short message service application determining the computer program instructions that, when executed by the at least one processor, cause the at least one processor to:
Receiving a request to send short message service information from a brand to a mobile telephone number of a user;
Processing the request to send the short message service information, comprising:
Determining whether the mobile phone number of the user is enabled on one or more of a plurality of rich information transfer channels for the mobile phone number of the user;
When it is determined that the mobile phone number of the user is enabled on the one or more rich information transfer channels, performing steps comprising:
creating the rich information including information and brand identity; and
Transmitting said created rich information to said mobile telephone number of said user on said enabled one or more of said rich information transfer channels;
when it is determined that the mobile phone number of the user is not enabled on the one or more rich information transfer channels, performing steps comprising:
Confirming whether a setting designates transmitting the received short message service information as short message service information to the mobile phone number of the user when the mobile phone number of the user is not enabled on the one or more rich information transfer channels; and
And transmitting the received short message service information to the mobile phone number of the user as short message service information.
14. The system of claim 13, wherein: one or more of the computer program instructions, as determined by the rich short message service application, when executed by the at least one processor, cause the at least one processor to communicate the rich information from one of a trusted sender identifier and a sender identifier of the brand.
15. The system of claim 13, wherein: the rich information also includes one or more of a plurality of interactive buttons including a suggested reply button, a suggested action button, and a brand-specific action button, selection of the suggested reply button on the user device of the user allowing the user to respond to the brand, and wherein selection of one of the suggested action button and the brand-specific action button allows the user to perform an action on the user device.
16. The system of claim 13, further comprising: one of a brand enterprise and a developer that registers a rich short message service with a service provider, wherein the registering includes:
receiving, by the service provider, information from the brand enterprise regarding the brand identity; and
The brand identity is verified by the service provider.
17. The system of claim 16, wherein: the one of the brand enterprise and the developer specifies one of a plurality of rich information templates to be used for transmitting rich information to the service provider, the rich information being transmitted by the service provider to the user device of the user using the specified one of the rich short information service templates.
18. The system of claim 13, wherein: the rich short message service application is executed using one or more of an application programming interface configured to send short message service information, a protocol configured to send the short message service information, an application programming interface configured to send the rich information, a protocol configured to send the rich information, and an application configured to send the rich information.
19. The system of claim 13, wherein: one or more of the computer program instructions, as determined by the rich short message service application, when executed by the at least one processor, cause the at least one processor to:
determining whether the mobile phone number of the user can be used for a rich communication service; and
Determining whether the mobile phone number of the user is available for one or more of a plurality of messaging applications, wherein one of the messaging applications is a WhatsApp instant messaging application.
20. The system of claim 13, wherein: one or more of the computer program instructions, as determined by the rich short message service application, when executed by the at least one processor, cause the at least one processor to:
determining whether the mobile phone number of the user is linked to one of a chat robot and a user profile created by one of the brands and information delivery platforms; and
Transmitting the created rich information to one of the user profile and the chat bot of the brand on one or more of a plurality of information delivery platforms, wherein the information delivery platforms include Facebook Messenger, google Business Messages, and Apple Business Chat, and wherein the user profile is part of a profile stored by one or more entities including Facebook, google and Apple.
21. The system of claim 13, wherein: the one or more computer program instructions, which are determined by the rich short message service application, when executed by the at least one processor, cause the at least one processor to select the one or more rich information transfer channels based on one or more of a plurality of parameters including:
The size of the short message business information;
The capabilities of multiple information delivery platforms;
the cost of transmitting the short message service information over the one or more rich information delivery channels according to standard pricing and traffic pattern based dynamic pricing;
the history of the receiver of the short message service information in terms of information transfer state and time, information reading state and time and user response; and
Consistency is maintained by sending the short message service information on a single rich information transfer channel rather than switching between the multiple rich information transfer channels.
22. The system of claim 13, wherein: one or more of the computer program instructions, as determined by the rich short message service application, which when executed by the at least one processor, cause the at least one processor to augment the rich information with one or more of a plurality of automatic augmentations, the augmentations comprising:
replacing the uniform resource locator links within the short message service information with one or more of images, video, and other rich media; and
One of a suggested reply and a suggested action is automatically added to the short message service information based on the content of the short message service information.
23. The system of claim 13, wherein: one or more of the computer program instructions, as determined by the rich short message service application, when executed by the at least one processor cause the at least one processor to monitor delivery of the created rich information to the mobile telephone number of the user, wherein the monitoring comprises delivering the created rich information to the mobile telephone number of the user by one or more additional information delivery platforms in the event of one of the failure of the delivery and the delay of the delivery of the created rich information to the mobile telephone number of the user by a first information delivery platform, and wherein the one or more additional information delivery platforms comprise one of an alternative data information delivery platform and a short message service platform.
24. The system of claim 13, wherein: one or more of the computer program instructions, as determined by the rich short message service application, when executed by the at least one processor, cause the at least one processor to simultaneously send the created rich information on the plurality of enabled rich information transfer channels to increase the chances of communicating the created rich information.
CN202280054967.0A 2021-06-30 2022-06-30 System and method for enriching short message service Pending CN117999806A (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US202163216921P 2021-06-30 2021-06-30
US63/216,921 2021-06-30
PCT/US2022/035822 WO2023278770A1 (en) 2021-06-30 2022-06-30 A system and method for rich short messaging service

Publications (1)

Publication Number Publication Date
CN117999806A true CN117999806A (en) 2024-05-07

Family

ID=90895743

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202280054967.0A Pending CN117999806A (en) 2021-06-30 2022-06-30 System and method for enriching short message service

Country Status (1)

Country Link
CN (1) CN117999806A (en)

Similar Documents

Publication Publication Date Title
US11740950B2 (en) Application program interface analyzer for a universal interaction platform
CN105530175B (en) Message processing method, device and system
US10425422B1 (en) Message content modification devices and methods
US9559992B2 (en) System and method for updating information in an instant messaging application
US20120209685A1 (en) Check-ins to commercial venues
US20140066044A1 (en) Crowd-sourced contact information and updating system using artificial intelligence
US20130217365A1 (en) Automatic profile update in a mobile device with transactional and social intelligence capabilities
US10873553B2 (en) System and method for triaging in a message system on send flow
EP2538641A1 (en) Secure tag management method and system
US10135764B2 (en) Universal interaction platform for people, services, and devices
US20230007449A1 (en) System and method for rich short messaging service
US11044222B2 (en) Automated connection of electronic messaging and social networking services method and apparatus
US20140108621A1 (en) System and method for internet services aggregation
CN110771126A (en) Matching and attribution of user equipment events
WO2014176896A1 (en) System and method for updating information in an instant messaging application
US9491493B2 (en) Unified content posting
US20080176587A1 (en) System and a method for sending digital content to a mobile device
CN117999806A (en) System and method for enriching short message service
US11113723B1 (en) Explicit user history input
US11924718B2 (en) System and method for expanded reach rich business messaging
US20240127212A1 (en) System and method for enabling payments over messaging
US11144970B2 (en) Information processing device and storage medium
WO2012167149A1 (en) System and method for internet services aggregation
WO2023154496A1 (en) System and method for expanded reach rich business messaging
KR101150771B1 (en) Method and apparatus for providing social assurance services

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination