Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
  • H04L51/02—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail using automatic reactions or user delegation, e.g. automatic replies or chatbot-generated messages
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
  • H04L51/21—Monitoring or handling of messages
  • H04L51/216—Handling conversation history, e.g. grouping of messages in sessions or threads
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L12/00—Data switching networks
  • H04L12/02—Details
  • H04L12/16—Arrangements for providing special services to substations
  • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
  • H04L12/1836—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with heterogeneous network architecture
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
  • H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
  • H04L51/18—Commands or executable codes
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
  • H04L51/58—Message adaptation for wireless communication

Definitions

• the present invention relates to enabling a messaging system to create an association between a notification message and a corresponding response message.
• SMS short messaging system
• Figure 1 is a block diagram of one embodiment of the system.
• Figure 2 is a flowchart of one embodiment of constructing a notification message.
• Figure 3 is a flowchart of one embodiment of handling a response to the notification message.
• the method and apparatus described is response enabled messaging system, which allows a stateless messaging system to associate a notification/original message with a response.
• a stateless messaging system does not preserve the original message's message ID in a response.
• stateless messaging systems include short messaging system (SMS), multimedia messaging system (MMS), and others.
• SMS short messaging system
• MMS multimedia messaging system
• SMS will be used.
• SMS will be used.
• the processes described herein would apply to any other stateless messaging system.
• the system will automatically associate any response with the original notification. This enables an employee to respond to a notification with directives/actions.
• a directive/action may be automatically processed by a workflow system. This system provides improved productivity since the employee can not only receive notifications when they are mobile, but they can also respond to them immediately.
• One use of the response enabled messaging permits an employee receiving a message originated from an enterprise application to respond with one or more keywords that can initiate an action. Furthermore, in one embodiment the system permits a message thread, enabling error messages, clarifications, and other related message exchanges to be maintained together. [0011] In one embodiment, the system may use the ORACLE Enterprise SuiteTM and associated applications, or other enterprise applications. In one embodiment, the enterprise application utilizes one or more underlying databases. However, the methodology may be used with any SMS-sending system, and does not require an underlying database or enterprise system.
• Some Enterprise Suites generate workflow notifications for end users. These notifications are typically email based. Users receive an email including one or more hyperlinks. Users can then click on hyperlinks for "Accept" "Reject” etc. that typically launch the email client with a pre-populated message template that includes an appropriate keyword (accept, reject, approve, forward, etc.) corresponding to the hyperlink that the user clicked and an ID that identifies the corresponding workflow item. The ID and the keyword from the reply are used to affect the appropriate change to the corresponding workflow item.
• SMS does not provide such a response function. Natively, SMS messages are unconnected to each other. Although you can press "reply" what is generated is an unconnected SMS, directed at the originator of your message. While this may work in a personal messaging environment, where an individual sends and receives only a few messages a day, it does not function well in a corporate environment. An enterprise suite may generate hundreds of messages in a day.
• FIG. 1 is a block diagram of one embodiment of the system.
• the primary components in one embodiment include: • Enterprise Mobile Notification System 110: This system converts the Enterprise workflow notifications to Mobile Notifications and sends them to the Enterprise Messaging Gateway via an API.
• Enterprise Messaging Gateway 120 This Gateway manages the scheme to route a reply back to the originating enterprise system element, along with the original NotificationlD or an equivalent identifier.
• the Enterprise Mobile Notification System (EMNS) 110 may, in one embodiment reside on the enterprise database system. Alternatively, the EMNS 110 may reside on a separate server, but be coupled to the database system. The EMNS 110 maps workflow notifications to mobile notifications (which have constrained length compared to email notifications). In one embodiment, the functionality of the EMNS 110 may be integrated into the enterprise database system. Thus, the EMNS 110 need not be a separate software application from the notification originating system, but is simply logic to enable the notification to be sent via SMS or similar mobile protocol.
• a Ul tool enables an authorized user, for example an Enterprise IT manager, to select the appropriate fields in the various types of workflow notifications to assemble into a mobile notification.
• the mobile notification may be assembled automatically by the EMNS 110.
• Typical fields are Subject, Amount to be approved (for Expense Report, Purchase Order, etc), and others.
• Accepted and expected action keywords are created for various user actions that are possible for this workflow event.
• the workflow system automatically triggers such workflow notifications to be sent.
• the EMNS 110 converts the notifications to SMS or another mobile format.
• the notifications in one embodiment, are sent via an API (application programming interface) to the Enterprise Messaging Gateway 120.
• the components of a mobile notification include:
• NotificationlD This ID is used by the Enterprise Messaging Gateway for the corresponding reply from user.
• the EMNS 110 receives a reply from the Enterprise Messaging gateway 120 with the user-selected action keyword (Approve, Reject, etc.) and the appropriate NotificationlD.
• the EMNS 110 then passes the response data to the enterprise systems to affect the change associated with the keyword.
• the EMNS 110 may translate the response into a proper format for the enterprise application.
• the Enterprise Messaging Gateway (EMG) 120 is the system that correlates replies with corresponding input messages. This correlation is important since SMS clients on handsets do not preserve any state in a reply. [0019] In one embodiment, the Gateway 120 stores the following information for the input message:
• Enterprise ID The enterprise making the message delivery request is identified by the corresponding connection point to this system (in one embodiment each Enterprise has a dedicated connection point).
• Enterprise Keyword is identified for the Enterprise: for example: VRSN for Verisign.
• the Enterprise ID can be replaced by the Enterprise Keyword, and vice versa.
• the Enterprise keyword may be as short as a single letter, if that is all that is needed to uniquely identify the enterprise. Generally, minimizing keyword length is useful because typing on a mobile device may be difficult.
• Notification I D set by Enterprise for identifying the workflow event.
• Message Keyword An Alpha-numeric keyword for Message is generated.
• the Message Keyword may be a 3 digit keyword.
• the Gateway 120 splits messages larger than the SMS maximum (in one embodiment 160 characters) into multiple messages. In one embodiment, such split messages receive a single NotificationlD and Message Keyword.
• An SMS or similar stateless originating message, or notification is generated for the client device.
• an SMS message is constructed, requesting a response from the user.
• an exemplary SMS message may read "VRSN Purchase Order #ABC $999 For Some Project Hardware. Reply with VRSN MXY ACCEPT/REJECT.” This message has the following components:
• a short message code is assigned to the message.
• the short message code is a part of the SMS specification.
• Short Codes are phone numbers that are 5 digits long. These phone numbers are used in SMS messaging instead of long numbers such as 1-206-555-4321 , i.e. telephone numbers with area codes.
• a provider can lease these short codes to a corporation. In one embodiment, the corporation may have a range of short codes (i.e. the codes between 50000 and 51000).
• the user is prompted to create a response.
• the response in one embodiment, must include all three components prompted for by the instructions Enterprise Keyword, Message Keyword, Action Keyword).
• the Enterprise Keyword can be eliminated if an Enterprise uses a dedicated short code (say 55555) so that the reply can be routed back to enterprise based on the dedicated short code that it was sent to.
• the Enterprise Keyword is only used to distinguish between enterprises on a shared Short Code.
• the Message Keyword can also be eliminated by the Enterprise Messaging Gateway by rotating through a set of short codes, such that the short code of the response is likely to be unique.
• the system may rotate through 1000 short codes sequentially for a particular destination MDN.
• the short code is associated with the input message in the database. Therefore, the reply can be correlated back to the originating message.
• This approach assumes that the user responds to a message in a timely manner. Since very few SMS clients store a large number of messages (older messages are discarded), if the range of available short codes is large enough, there is minimal possibility of conflict.
• this cycle may be repeated. That is, the response sent by the user may trigger an error message, or request for clarification.
• the EMG 120 would associate this subsequent message with the original notification and response.
• the EMG builds a message thread based on communications between the enterprise system (or other message originator) and the user, or users. In one embodiment, this message thread may be archived or made available to the enterprise system or outside systems.
• the Enterprise Mobile Notification System transmits message details and action keywords to the Enterprise Messaging gateway.
• the end user clicks on the link he or she is taken to a WAP page hosted by the Enterprise Messaging Gateway.
• the notification message body is shown.
• the original SMS message may include such a WAP notification.
• the WAP page in on embodiment also includes action links.
• the end user can click on an Action link.
• an API call is made back to the Enterprise Mobile Notification System with appropriate NotificationlD and Keyword.
• the message may include multiple URLs, corresponding to the response options. The user may then select one of the URLs, and this may be sufficient to make a selection. This would enable the selection of a URL which does not have any content, reducing the bandwidth usage and rendering time for the WAP page. This may be useful for devices which charge for the bandwidth used.
• the Enterprise Messaging Gateway can pass the response to the Enterprise database.
• the WAP Page is branded per the enterprise originating message.
• a single Enterprise Messaging Gateway can service a plurality of corporations.
• FIG. 2 is a flowchart of one embodiment of the process. The process starts at block 210, when a notification message which needs a response is generated.
• the process determines whether the enterprise has a dedicated short code. If it does not, at block 225 an indication of the enterprise keyword which should be included with the response is added to the message.
• the process determines whether the system uses a set of rotating short codes. If so, at block 235, the process determines whether a short code is available for this message. If no short code is available for this message, the process at block 240 adds a message keyword to the message. This message keyword is to be returned by the SMS responder.
• the query is added to the SMS message, as are the possible responses.
• possible responses are defined by the message originator. In one embodiment, they are automatically defined. In one embodiment, the default responses are agree/disagree/no decision.
• the user may be provided with an appropriate abbreviation for each option, to minimize the required typing.
• the query may be: "Authorize Project Review? Respond with BU#2 MSG1234 (Y)es/(N)o. n ⁇ The user may respond with "BU#2 MSG1234 Y,” if no dedicated short codes are available. If there are dedicated short codes the BU#2 and/or MSG1234 identifiers may be absent from the message.
• the response from the user may be as simple as "Y.”
• the stateless message (SMS or otherwise) is sent to the user.
• the message includes instructions.
• the message may be sent in two or more parts.
• the system stores the short code associated with the message. If the short code is not unique for the message, the message ID is also stored. If the short code is also not unique for the enterprise, the enterprise keyword is also stored. The process then ends.
• Figure 3 is a flowchart of one embodiment of handling a received response.
• the system stores the short code associated with the message. If the short code is not unique for the message, the message ID is also stored. If the short code is also not unique for the enterprise, the enterprise keyword is also stored.
• the process starts, at block 310, when a stateless response is received from a user.
• the available data is extracted from the stateless response from the user.
• the data that can be extracted from the response includes the short code to which it was sent, and its contents. It has no other referent for the originating message.
• the system looks up the short code.
• the short code may identify a particular message, a particular business unit, or a particular enterprise.
• the process determines whether the short code is unique to a particular message. If so, the received response is associated with the original notification message at block 330. In another embodiment, the entire enterprise may share a short code. In that case, this step may be skipped. If the short code is not unique to the message, the process continues to block 335.
• the process retrieves the message identification. If no message identification is found, the process fails at block 340. Otherwise, the process continues to block 345.
• the process determines whether the short code & message identification combination is unique to the organization. If it, then the received response is associated with the original notification at block 350. Otherwise, the process continues to block 350.
• the process attempts to retrieve the business unit information from the response. If the business unit information is not found, the process fails, at block 340. Otherwise, the received response is associated with the original notification at block 330.
• the depth of identification may be increased or decreased, as appropriate.
• a particular system may simply use unique message IDs, and thus obviate the need for business unit and/or enterprise identification.
• Another system may use a depth of four or more separate identifiers, for example message ID, work group, business unit, corporate entity, all of which exist under the same short message code.
• stateless messaging such as the messaging provided by short messaging system (SMS), multimedia messaging system (MMS), or universal resource locators (URL) to provide state- linked responses to queries.
• SMS short messaging system
• MMS multimedia messaging system
• URL universal resource locators
• the process continues to block 360.
• the response is translated to the appropriate language and/or format for the original notification generator. This format change may include everything from changing a "Y" to an "Approved” or similar language shift, or the change of a text message into HTML, a programming language, a spreadsheet format, etc.
• the response is sent to the logic which generated the original notification.
• the system sends this response using the conventional path of the notification generator. Therefore, the enterprise system which generates notifications need not be modified in any way to enable it to use SMS as a path for notifications.
• the system intercepts messages generated by the notification system, and forwards them on, after generating a copy for use in the stateless messaging system. This ensures that complete records are available.
• the entire exchange is stored in the system, to enable review of actions which occurred.
• the system may further generate an acknowledgement message to the user.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Telephonic Communication Services (AREA)
• Data Exchanges In Wide-Area Networks (AREA)
• Mobile Radio Communication Systems (AREA)

Priority Applications (2)

Applications Claiming Priority (2)

Publications (2)

Family

ID=39325156

Family Applications (1)

Country Status (3)

Cited By (2)

Citations (2)

Family Cites Families (3)

• 2007
  • 2007-10-22 EP EP07839732A patent/EP2092762A4/de not_active Withdrawn
  • 2007-10-22 WO PCT/US2007/022437 patent/WO2008051522A2/en active Application Filing
  • 2007-10-22 CA CA2666911A patent/CA2666911C/en active Active

Patent Citations (2)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events