KR20050050656A - Method and apparatus for an e-commerce message using sms - Google Patents

Abstract

The invention provides a method for generating an SMS business message for processing by a software application comprising the steps of: a data collection interface accepting outgoing instructions and outgoing data from said software application; a message encoding engine encoding said outgoing instructions and outgoing data from said software application using an encoding template to generate the SMS business message as a categorized SMS message formatted for processing by a data processing system; and a dispatcher runtime processor processing said SMS business message for transmission over a network to a recipient.

Description

Method and apparatus for e-commerce message using SMS {METHOD AND APPARATUS FOR AN E-COMMERCE MESSAGE USING SMS}

FIELD OF THE INVENTION The present invention relates to the field of wireless e-commerce communications, and more particularly to methods and apparatuses for providing short message services and other messaging services used for mobile wireless communications as commerce messaging.

Mobile commerce provides convenience for users by allowing them to conduct business transactions anytime, anywhere. Wireless application protocols (WAP) have existed for many years, but the market penetration of WAP enabled cellular phones and other such web enabled wireless devices is still very low. The most established technology in the field of mobile commerce today is Short Message Service (SMS) on mobile wireless devices. With the high penetration and adoption of SMS in the market, SMS has been a major target for mobile commerce use.

Examples of SMS notifications with commerce functions planned by the present invention are:

Marketing driven messages for the user: for example, discount information, promotions and other commerce campaign information;

Notifications for business events: for example, received confirmation order, sending confirmation; And

Notification for functional efficiency, such as payment deadlines or other deadline push type reminders.

However, various pure technical hurdles and limitations exist in today's SMS, so applications and use in commerce web applications are difficult and impracticable.

There are many limitations in the prior art and there is a need in the business environment for the use of SMS messaging. These limitations and needs are reviewed below.

Limitations of Using SMS in Commerce

The lack of semantics concept in SMS makes SMS use difficult in commerce applications. The difficulties are as follows:

Encoding SMS messages to accurately implement a given business purpose, and runtime handling of corresponding SMS messages if business purposes are required.

Encoding barriers

For data processing systems, SMS messages are inherently typeless, stateless, sessionless, and meanless. Currently, the main purpose of SMS messaging is person-to-person communication between mobile devices.

However, in order for SMS messages to be viable as a means of business transaction, SMS cannot be merely a short exchange of two parties. Business transactions include the requirements for traceability, confirmation, and nonrepudiation. SMS should also be understood by any web application or other data processor that handles SMS. We collectively define these requirements as 'semantics' of SMS messaging.

For example:

A given set of business rules will require a subset of SMS messages to be identified at delivery for non repudiation of the following transactions:

Iii. Verified arrival

Ii. Recorded arrival timestamp for non repudiation

Iii. Acknowledge receipt of SMS messages

It may also be a business requirement to have a given set of SMS messages delivered on a regular basis based on a given schedule . Examples include the following:

Iii. Monthly reminder of billing statement

Ii. Scheduled promotions by SMS messages

Businesses may require broadcast type SMS messages to reach multiple users without having to check or confirm message arrival. Examples include the following:

Iii. Broad Promotional Stores

In this case no approval will be needed.

If a user wants to send an SMS message to trade, the user's intention (eg, the purchase of a given item) is a web application or other application that handles incoming SMS messages encoded in the SMS message text and coming from the user. It must be clearly understood.

SMS messages correctly encoded to accurately represent business intentions are technically complex and difficult tasks and are very prone to human error. Human errors in encoding are often very expensive and difficult to debug and fix. Business users want efficiency and trust while using SMS to fulfill their business objectives. When using SMS messages in users' business processes, users need to avoid such technical complexity. Business users typically focus on:

Iii. Determine business intent of a given SMS message:

Ii. The formation of an accurate representation of the message (without worrying about the different technical details of the encoding); And,

Iii. Notification of error if the message sent does not meet the intent of the message classification.

Business users initiating these business transactions are currently faced with a significant technical challenge of correctly and manually encoding all of these SMS messages so that they map precisely to the different specific business objectives they are beginning to achieve.

Difficulties in Semantic Handling at Runtime

Apart from the manual and technical challenges in SMS message encoding, semantic handling at runtime to meet business process requirements is also a major problem.

For example, an SMS message that informs a user of a substantial payment typically requires that user's approval and defines a business process that defines a "completed customer touch point."

In this case the lack of authorization by the user while receiving the SMS message will be treated differently than other SMS messages.

However, the concept of semantics and categorization does not currently exist in the SMS field.

The absence of syntax in SMS messages makes the use of SMS in commerce business processes difficult and impractical.

Lack of SMS Text Stream Mapping to Commerce Business Activity

SMS messages are simple text messages without any encoding scheme. Thus, simple and simple text SMS messages are not suitable for commerce for the reasons described below in addition to those mentioned above.

Iii. Simple SMS messages are not possible to indicate the type of commerce currently being performed.

Ii. The additional parameters required for a particular transaction cannot be encoded in a standard manner and therefore cannot be parsed by a backend commerce application.

Iii. Additional details such as user authentication and authorization cannot be handled in a standard way.

Iii. The lack of a request-response model of state information means necessary for commerce cannot be applied to commerce SMS messages.

Iii. The free form configuration of 160 characters as responses by human users makes it impossible to adopt and to execute.

The problem poses serious usability problems for SMS users (both human and web applications) that need to respond to business messages from web applications or other data processing applications.

Lack of notation for parameters encoded as parts of SMS message

All inbound SMS messages that carry transaction information need to verify data integrity and data validity. In addition, users sending SMS messages to a given web application need to encode enough information into inbound SMS messages for correct authentication.

For example, the use of SMS in an online auction requires the back-end web application used to communicate with bidders to notify the signed bidder whenever someone else has a higher bid than the auction bidder. Upon notification, bidders should be given a mechanism to respond in order to raise their bids.

In this example, it is necessary to send an SMS message in a non-repudiation manner so that signed bidders cannot refuse to receive auction fee notifications. Also, in order for messages to reach bidders as soon as possible, they should be sent over a high priority channel if available. Additionally, it is necessary for auction bidders to call back to the backend commerce application used for the auction and submit a new bid price using a standard SMS message template that can be accepted by the backend commerce application. These SMS messages must be correctly parsed by the backend commerce application so that the backend web application can perform the appropriate semantics.

For example, one of the parameters required in an auction scenario would be the SKU number for product identification at auction. Both backend server and bidder authentication require non-repudiation purposes.

The lack of syntax in SMS messaging makes application to the following business processes extremely difficult:

Commerce process mapping;

User authentication;

Parameter passing;

Check your data.

Technical Complexities of SMS Encoding Prevent Adopting the Use of SMS

The creators of business SMS messages are business users who need to send business messages. Their main concern is to focus on the business logistics of the message (time spent, who to send it to, etc.) and the message itself (such as the choice of expression). They do not want to burden the delivery mediation technique (and typically cannot afford to). For example, business users do not want to deal with the technical knowledge of how to send SMS messages and do not expect to handle them.

Request for confirmation in commerce use

An important requirement of SMS use in commerce is the need for confirmation from SMS message recipients. The following is a list of examples for such critical requirements when using SMS in commerce:

Upon receiving an SMS notification from a commerce server, the receiver often needs to respond by sending an SMS message back to the commerce server. For example: The recipient may send an SMS message back to the commerce server to purchase the product advertised by the SMS promotional message.

-Fulfillment of the non-repudiation request, eg: all customer touch points need to be recorded.

Acknowledgment also requires confirmation of the user ID in the inbound message.

Security requirements in commerce use

Another important requirement for using SMS in commerce is the need for security in conducting business transactions. This request includes:

User ID authentication by a web application such as WebSphere when a user initiates a transaction using an SMS message;

Web application authentication by the user to ensure that the user knows that the correct web application is handling the user's request;

User authentication to confirm that no unauthorized mobile device is used for the transaction; The PIN may preferably be used as an additional layer of user confirmation.

Session request in commerce use

Another important requirement of using SMS in commerce is that of a session. Often, when a web application sends an outbound message to its user (e.g., a campaign message such as '50% discount for all electronics if purchased within the next 6 hours'), the web application used is the user Expects the SMS to respond back to the corresponding outbound message within a certain time. Typically the request of a session includes:

Request and response model mapping for outbound and inbound SMS messages;

Timeout mechanism; And,

Session data sharing mechanism.

One of the biggest drawbacks in the use of SMS messages in commerce applications is the absence of SMS message syntax, which makes the use of SMS messages in commerce business processes difficult and impractical. Another major drawback is the lack of SMS text mapping for predefined commerce business activities or transactions. Often, SMS text is mapped to the type of commerce to be performed, and most commerce business activities require additional parameters. Free form configuration of 160 characters by human users is not feasible.

In addition, for SMS to be incorporated into a commerce application, user authentication; Web application identification; Receive confirmation from SMS message recipients; And security mechanisms are strongly required to provide the ability to relate user responses to intended commerce events.

Referring to the following figures, preferred embodiments of the present invention are described by way of example:

1 is a convex diagram illustrating a system for performing electronic commerce using SMS in an embodiment of the present invention.

2 shows a structural mapping of SMS commerce based configurations.

3 illustrates creating a new SMS type in an SMS universal encoding template using the SMS Message Configuration Wizard.

4 illustrates creating a new SMS type using the SMS message composition GUI.

5 shows an SMS encoding flow chart.

6 shows an SMS message encoding engine DCI structure diagram.

7 shows an SMS message encoding engine flow diagram.

8 shows an example of the actual outbound SMS message seen by the receiving user.

9 shows an SMS inbound message with a user response entered.

10 shows a GUI for composing an SMS message.

11 illustrates adding an SMS message template to a message type.

12 shows an inbound template manager structure diagram.

13 shows a flow for inbound template management.

14 shows a structure diagram of a business user sending an SMS message.

15 shows a flow chart for FIG. 16.

16 illustrates the acknowledgment runtime flow.

17A shows an outbound flow chart 1.

17B shows an outbound flow chart 2.

17C shows an outbound flow chart 3.

18A shows Inbound Flowchart 1.

18B shows inbound flow chart 2.

18C shows an inbound flow chart 3.

As a first aspect, the present invention provides a method of generating an SMS business message for processing by a software application, comprising the following steps: instructions for sending and sending outgoing data from the software application; Accepting data; A message encoding engine uses an encoding template to encode instructions sent from the software application and the data sent to generate an SMS business message as a formatted and categorized SMS message for processing by a data processing system; And a dispatcher runtime processor processing the SMS business message for transmission to a recipient on a network.

As a second aspect, the present invention provides a means for generating an SMS business message for processing by a software application, comprising the following steps: a data collection interface accepts instructions sent and data sent from the software application; Means for doing so; Means for a message encoding engine to use the encoding template to encode instructions sent from the software application and the data sent to generate an SMS business message as a formatted and categorized SMS message for processing by a data processing system; And means for the dispatcher runtime processor to process the SMS business message for transmission to a recipient on a network.

As a third aspect, the present invention provides a computer program product loadable directly into an internal memory of a digital computer, when the product is executed on a computer, the product includes software code portions for performing a method comprising the following steps: A data collection interface accepting instructions sent from the software application and data sent; A message encoding engine uses an encoding template to encode instructions sent from the software application and the data sent to generate an SMS business message as a formatted and categorized SMS message for processing by a data processing system; And a dispatcher runtime processor processing the SMS business message for transmission to a recipient on a network.

1 illustrates an SMS-enabled e-commerce system focusing on the improvements of the preferred embodiment over the conventional system. Improvements provided in the present invention are shaded.

As mentioned above, SMS is not novel. Referring to FIG. 1, which describes an SMS-enabled commerce communication system in connection with a preferred embodiment, the current technology is located in the space indicated by the prior art. Attempts have been made in the past to solve the problem of correctly sending SMS messages to applications running on mobile devices (eg, mobile phones).

The space labeled 'new problem space' of FIG. 1 is new except for a few existing basic building blocks. Although some of the basic building blocks exist, they are adequate enough to take account of the new possibilities provided by the preferred embodiments, so that the preferred embodiments herein enable their improvement. Conventional configurations are not highlighted, but new configurations are highlighted in gray.

Referring to the embodiment described in FIG. 1, the e-commerce server 104 includes many configurations:

Application configurations 108: The application configurations 108 form the business subsystems of a given commerce server. Each business subsystem is an implementation of a given business process. Examples of business subsystems include, among others, order management: user management; Marketing and campaign subsystems.

Normal Message Subsystem 107: The Normal Message Subsystem 107 is a generic message handling system that handles (and processes) the messages generated by the application configurations 108. The message subsystem usually handles email, file transfers and other issues related to the handling and processing of messages.

The embodiment illustrated in FIG. 1 uses existing features and processes that include the following.

SMS Messages: SMS messages are limited to simple text messages up to 160 characters long. SMS messages can be sent over many wireless networks. Most mobile phones can send and receive SMS messages.

Wireless Message Gateway: The wireless message gateway may be implemented by a computer capable of sending SMS messages between the wireless network and the e-commerce server 104.

SMS Center: SMS Center 102 is typically operated by a telecommunications company to deliver SMS messages to selected mobile devices.

Data Collection Interface (# 1): Data Collection Interface 117 is

Iii. User input through SMS message configuration wizard 112; And,

Ii. Data generated by the application configurations 108 and sent by the normal message subsystem 107.

Create a collection of SMS input data to be used by message encoding engine 111, including a set of interfaces to collect.

Message Encoding Engine # 2: The Message Encoding Engine 111 takes as input the input data collection generated by the data collection interface 117.

The message encoding engine 111 uses the data of the SMS input data collection to generate an SMS message encoding with the appropriate characteristics for the SMS type selected by the user. The message encoding engine validates user input against the SMS universal encoding template 113 for error checking.

This automatic generation capability of the engine 111 eliminates encoding errors such as those caused by human mistakes. It also hides from the technical users the technical complexity of encoding characteristics for the implementation of message intent. The message encoding engine 111 creates an SMS message instance 114 that is typed as output.

Runtime Processor # 3: SMS Message Runtime Processor 110 handles the business semantics defined in SMS categorization at runtime.

Basic functions of the runtime processor 110 are:

If the SMS message requires confirmation of a forwarded or expected response, the SMS message runtime processor 110 continues the confirmation.

The SMS runtime processor 110 also takes a response back from the end user and finds the corresponding inbound message template from the inbound template database 115.

If the SMS message is a scheduled message, the SMS message runtime processor 110 will handle the scheduling of the sent SMS message.

Another semantic action may be taken in the absence of user confirmation.

The runtime processor also performs runtime error checking and error handling.

SMS Message Configuration Wizard (# 4): Referring to FIG. 2, which describes the structural mapping of an SMS commerce based system in accordance with an embodiment of the present invention, SMS Message Configuration Wizard 112 clarifies the intended use of a message by a user. Guide it. The SMS message encoding engine 111 uses the user input to generate an SMS message by mapping the user input to a predefined and predefined type in the SMS categorization template 113 as follows:

Iii. The message construction wizard 112 invokes a data collection interface 117 that takes user input and in turn produces an accurate SMS input data collection.

Ii. In addition, when a user defines a new SMS categorization through the message composition wizard 112, the message configuration wizard 112 updates the SMS universal encoding template 113.

Iii. If a business user defines an SMS message related to a response required from an end user, the business user will define the required response as needed and understood by the application configurations 108 in the template form via the message configuration wizard 112. The message configuration wizard 112 will take this input and update the inbound template database (parts # 9, 115) (see Figure 1).

SMS Universal Encoding Template (# 5): The SMS Universal Encoding Template 113 includes metadata that defines categorization (or 'type') of outbound and inbound SMS messages. Each SMS categorization represents the intended use of a given business. It provides a definition of semantics for encoding as well as runtime.

With this well-defined SMS message categorization, it is now possible to automatically generate SMSs that are correctly encoded to reflect their intended use. Additional SMS message categorization may come further from existing types.

This entity provides an important aspect of the present invention by providing a mechanism for semantic definition and handling to enable proper semantic handling in SMS.

With the SMS universal encoding template 113, a business user can define a new SMS message type in the message encoding engine 111 and the runtime processor 110 without changing the code, making both configurations generally.

Classified SMS message instances # 6: Classified SMS message instances 114 are generated by the message encoding engine 111 and used by the runtime processor 110.

Examples of categorized SMS message instances are as follows:

<GenericSMSMessage>

<short message_text> Something </ short message text>

<ReceiverProfile>

<userid> steve </ userid>

<cellphonenumber> 4161234567 @ cellphone. com </ cellphonenumber>

<deliverychannel> SMTP </ delichannel

</ ReceiverProfile>

</ GenericSMSMessage>

SMS Response Tracking DB (# 7): The SMS Response Tracking Database 116 captures all response required messages required for the encoded type. This enables the runtime processor 110 to ensure that the necessary response messages receive the expected responses and perform appropriate runtime processing. This also allows the underlying mechanism to handle inbound messages initiated by the expected user.

Inbound Template Database # 8: The inbound template database 115 stores the specific inbound message templates of all business users.

Note on the flow of FIG. 1: The construction, processing, and communication of SMS messages according to an embodiment of the present invention described is indicated by arrows of alphanumeric labels in FIG. 1. 2 shows a structural mapping of the SMS commerce system according to FIG. 1. The true value of the embodiments will be appreciated from the following description with reference to FIGS. 1 and 2.

A1: A business user 105, usually using the user interface 106, invokes the SMS Message Configuration Wizard # 4, 112 to prepare the message.

B1: The business user uses the message construction wizard 112 to send an SMS message based on the existing type defined in the SMS universal encoding template # 5, 113.

A2: Wizard 112 captures all user input and invokes data collection interfaces # 1 and 117.

B2: The business user uses the SMS Message Configuration Wizard 112 to define a new SMS message type.

A3: The business user defines the preset user response by creating a new inbound template using the wizard 112. The wizard 112 updates the inbound template DBs # 8 and 115.

C1: The message encoding engine (# 2, 111)

    Retrieve the SMS universal encoding template (# 5, 113) (C1);

    -Check the data captured by the data collection interfaces # 1, 117 in contrast to the SMS universal encoding template 113 and perform error checking.

C2: Message encoding engine 111 generates SMS message instance # 6 classified as output. Referring to FIG. 2, the message may be an XML encoded message 201.

D2: The message encoding engine 111 invokes the runtime processors # 3 and 110 that retrieve the classified SMS message instance 114 generated in C2.

D3: If a user response is required for this SMS message type, the runtime processor 110 registers this message as requiring a user response by updating the SMS response tracking DB (# 7, 116).

D4: The runtime processor 110 sends this classified SMS message instance 114 to the wireless message gateway 103 referred to the everyplace wireless gateway 203 of FIG.

D5: When an incoming SMS message is sent to the wireless message gateway 103, the wireless message gateway 103 sends the incoming message to the runtime processor 110, and the runtime processor 110 sends an inbound template ID from the incoming SMS message. Extract sequentially.

D1: The runtime processor 110 reads the SMS universal encoding template 113 and handles semantics of the type appropriate for outbound runtime processing and correct instances.

D6: Runtime processor 110 extracts the corresponding inbound template from inbound template DB (# 8, 115) and parses the inbound SMS message using the inbound template. Runtime processor 110 decodes the inbound SMS message and sends it to the corresponding application configuration 108 for handling.

   SMS communication between a user's SMS device (120 in FIG. 2), such as a mobile phone (101 in FIG. 1), is handled by the telephone company's cellular phone interface 102, and the wireless gateway 103 transmits messages in the communication. And mobile phone interface 102 to receive.

Dx: The runtime processor 110 reports the runtime error back to the application configuration 108.

1. SMS message categorization (type) method and apparatus for defining SMS message categorization

The SMS universal encoding template 113 provides a mechanism for defining SMS message categorization. The mechanism for defining SMS message categorization is preferably implemented in an XML manner in which the metadata (eg, features and characteristics of a given message) of the SMS message constituting the SMS message categorization is specified.

The commerce SMS message template is preferably designed to provide the commerce type (categorization) of the SMS messages. The SMS universal encoding template 113 provides a mechanism by which a user inherits existing defined types and extends and defines new SMS message types. Thus, users can extend the SMS message type of the original SMS categorization template to define new SMS types.

Business users can use existing SMS types and extend them to create new message types. The business user only needs to specify new features of the extended type. All the properties of the default message types (which extend to this new message type) are set and the business user does not have to specify them again.

Mechanism for defining semantics associated with a given SMS category

In the preferred embodiment of the present invention, when it is necessary to encode an SMS message, the message encoding engines # 2 and 111 call the XML parser to convert the SMS universal encoding template 113 into Java runtime objects. The XML parser may be part of the message encoding engine or may be available to the message encoding engine as would be understood by those skilled in the art. These runtime objects provide the necessary semantic information so that the message encoding engine 111 generates SMS messages.

In this situation the message encoding engine 111 can now parse the given instance of the message by using the XML parser to match against the SMS universal encoding template 113. This provides an automatic mechanism for error checking. Information missing or unexpected in a given SMS message that is not appropriate for the type definition of the SMS message will result in an error in message parsing.

At run time, the SMS runtime processor # 3, 110 reads the categorization information provided by the SMS universal encoding template 113 to handle other runtime semantics as well as error checking based on the SMS message type.

Runtime processing of SMS messages covers the following aspects:

1. Parsing outbound SMS messages.

2. Error checking of outbound messages.

3. Message tracking and scheduling possibilities.

4. Generation of outbound SMS template messages.

5. Error checking of inbound messages.

6. Convert inbound templates to XML SMS messages.

7. Map outbound types to corresponding inbound SMS messages.

The templates we introduced are now encoded so that runtime parsing of outbound SMS messages is possible. During this parsing step information about the message type, transmission medium, transmission priority, etc. are parsed out.

Error checking is an additional benefit of runtime parsing of outbound messages. Since outbound SMS messages are now strictly encoded type, various errors such as missing parameters can be detected and handled at this stage. This ensures that the final outbound message is correct.

A sample source code list that can be used to implement an SMS universal encoding template according to one embodiment of the invention is as follows:

<xsd: schema

     xmlns: xsd = "http://www.w3.org/2001/XMLSchema"

     xmlns: cep =

"http: //www.ibm.com/WebsphereCommerceEnabledPortal/SMSCommerceDefi

nitionSchema ">

<annotation>

<documentation xml: lang = "en">

  Schema for Websphere Commerce Enabled Portal SMS Commerce Type Definition

   Copyright 2002 IBM Corporation

<documentation>

</ annotation>

<! -Dynamic Context Group Instance-->

<xsd: element name = "ScheduledGenericSMSMessage"

       type = "ScheduledGenericSMSMessageType",

minOccurs = "0" />

<xsd: element name = "ResponseRequiredGenericSMSMessage"

       type = "ResponseRequiredGenericSMSMessageType",

minOccurs = "0" />

<xsd: element name = "HighPriorityGenericSMSMessage"

       type = "HighPriorityGenericSMSMessageType",

minOccurs = "0" />

<xsd: element name = "GenericSMSMessage"

       type = "GenericSMSMessageType",

minOccurs = "0" />

<xsd: element name = "BroadcastSMSMessage"

       type = "BroadcastSMSMessageType",

minOccurs = "0" />

<xsd: complexType name = "ScheduledGenericSMSMessageType">

<xsd: sequence>

<xsd: element name = "GenericSMSMessage"

type = "GenericSMSMessageType" />

<xsd: attribute name = "DateToBeSentOn" type = "xs: date" />

<xsd: attribute name = "TimeToBeSentOn" type = "xs: time" />

</ xsd: sequence>

</ xsd: complexType>

<xsd: complexType name = "ResponseRequiredGenericSMSMessageType">

<xsd: sequence>

<xsd: element name = llGenericSMSMessage ''

type = "GenericSMSMessageType" />

<xsd: attribute name = "InboundTemplateId" type = "xs: string" />

</ xsd: sequence>

</ xsd: complexType>

<xsd: complexType name = "HighPriorityGenericSMSMessageType">

<xsd: sequence>

<xsd: element name = "GenericSMSMessage" type = "GenericSMSMessageType" />

<xsd: attribute name = "DeliveryPriority"

type = "DeliveryPriorityType" fixed = "HIGH" />

</ xsd: sequence>

</ xsd: complexType>

<xsd: complexType name = "GenericSMSMessageType">

<xsd: sequence>

<xsd: element name = "shortmessagetext"

type = "xsd: string" maxLength = "160" />

<xsd: attribute name = "ReceiverProfile"

type = "ReceiverProfileType" minOccurs = "1" maxOccurs = "1" />

</ xsd: sequence>

</ xsd: complexType>

<xsd: complexType name = "BroadcastSMSMessageType">

<xsd: sequence>

<xsd: element name = "shortmessagetext" type = "xsd: string"

maxLength = "160" />

<xsd: attribute name = "ReceiverProfile" type = "ReceiverProfileType"

minOccurs = "l" maxOccurs = "unbounded" />

</ xsd: sequence>

</ xsd: complexType>

<xsd: simpleType name = "DeliverPriorityType">

<xsd: restriction base = "xsd: string">

<xsd: enumeration value = "HIGH" />

<xsd: enumeration value = "MEDIUM" />

<xsd: enumeration value = "LOW" />

</ xsd: restriction>

</ xsd: simpleType>

<xsd: complexType name = "ReceiverTransmissionProfileType">

<xsd: sequence>

<xsd: element name = "userid" type = "xsd: string" />

<xsd: element name = "cellphonenumber" type = "xsd: string" />

<xsd: element name = "deliverychannel" type = "DeliveryChannelType" />

</ xsd: sequence>

</ xsd: complexType>

<xsd: simpleType name = "DeliveryChannelType">

<xsd: restriction base = "xsd: string">

<xsd: enumeration value = "SMTP" />

<xsd: enumeration value = "GSM" />

<xsd: enumeration value = "SNPP" />

<xsd: enumeration value = "Mobitex" />

<xsd: enumeration value = "DataTAC" />

</ xsd: restriction

</ xsd: simpleType>

</ xsd: schema>

The following source code list provides examples of categorized (categorized) SMS message instances.

XSD Definition of Commerce Payment Exception SMS Message

<xsd: complexType name = "PaymentExceptionSMSMessage">

<xsd: sequence>

<xsd: elementname = "ResponseRequiredSMSMessage"

type = "ResponseRequiredSMSMessageType" />

</ xsd: sequence>

</ xsd: complexType>

Message instance of payment exception SMS message

<PaymentExceptionSMSMessage>

<ResponseRequiredSMSMessage>

<HighPriorityGenericSMSMessage>

<GenericSMSMessage>

<short ~ message ~ text>

           Your cheque bounced!

</ shortmessagetext>

<ReceiverProfile>

<userid> steve </ userid>

<cellphonenumber>

4161234567 @ cellphone. com

</ cellphonenumber>

<deliverychannel> SMTP </ delichannel

</ ReceiverProfile>

</ GenericSMSMessage>

<DeliveryPriority> HIGH </ DeliveryPriority>

</ HighPriorityGenericSMSMessage>

<ConfirmationOfDelivery> CONFIRMED </ ConfirmationOfDelivery>

</ ResponseRequiredSMSMessage>

</ PaymentExceptionSMSMessage>

XSD method definition of broadcast SMS message that campaign started

<xsd: complexType name = "CampaignStartedSMSMessage">

<xsd: sequence>

<xsd: elementname = "BroadcastSMSMessage"

type = "BroadcastSMSMessageType" />

</ xsd: sequence>

</ xsd: complexType>

Message instance of campaign started SMS message

<CampaignStartedSMSMessage>

<BroadcastSMSMessage>

<short message ~ text>

      New campaign has been started, visit our website

</ shortmessagetext>

<ReceiverProfile>

<userid> steve </ userid>

<cellphonenumber>

4161234567 @ cellphone. com

</ cellphonenumber>

<deliverychannel> SMTP </ delichannel

</ ReceiverProfile>

    ...

    ...

<ReceiverProfile>

<userid> joe </ userid>

<cellphonenumber>

4161234568@cellphone.com

</ cellphonenumber>

<deliverychannel> SMTP </ delichannel

</ ReceiverProfile>

</ BroadcastSMSMessage>

</ CampaignStartedSMSMessage>

The SMS encoding engine 111 may automatically generate an SMS message instance based on the selected SMS message. SMS message runtime processor 110 is adapted to handle semantics of a given predefined type. At run time, if the sent SMS message is a ResponseRequiredSMSMessageType, the SMS message runtime processor 110 waits for a preset wait time for user confirmation. If a confirmation is received after a preset wait time, the runtime processor 11 may send an error to the corresponding application configuration 108 and perform an action as defined in the business process represented by that application configuration. For example, the application configuration 108 may retransmit or roll back a transaction and provide to mark the transaction that has failed to complete. (In Dx of FIG. 1, runtime processor 110 reports runtime errors to the application configuration for handling.)

How a user creates a new SMS type by extension from an existing type

FIG. 3 describes a process for creating a new SMS type in an SMS universal encoding template using the SMS Message Configuration Wizard, and FIG. 1 describes an SMS message configuration GUI for creating a new SMS type. By reference, it will be readily understood how to generate a new SMS type using an embodiment of the present invention.

At the beginning of the process sequence (step 300), the business user clicks the button provided in the message configuration wizard 112 (FIGS. 1 and 2) to instruct the system of the embodiment to generate a new message type (step 301). The message construction wizard then reads the SMS universal encoding template 113 (FIGS. 1 and 2) and shows the source SMS type 405 that the user can select to create a new type in step 302. In step 303 the user enters a new message type name 404 and by the descriptions provided, reference numerals 406, 407, 408, 409, 410, 411, 414, 415, 416, and basic (source) type 405 Create a new SMS type by filling in all the new properties displayed. Add and delete buttons, 412 and 413, allow insertion and deletion of items in the response section, respectively, and buttons 402 and 403 are used to save or cancel the new message type to be appreciated.

If a new response template is needed for the new message type (step 304), the user invokes the response template manager to generate the required inbound template (step 305) and the inbound template database 115 is updated (step 306). If no new template is needed, the new message type is stored in the SMS universal encoding template 113 (step 307) and reaches the end (step 308) which is the process described in FIG.

2. Overall Flow of Encoding

Referring to FIG. 5 showing the SMS message encoding flow, it will be understood that:

A: The business user invokes a new message type generator to create a new message type.

B: The business user brings up the inbound template manager to create a new inbound template for the new message type (via the inbound template manager).

C: The inbound template manager retrieves one list from the predefined command list from the inbound template DB. The command list is defined by the application configuration owners.

D: The inbound template manager inserts a new line into the inbound template DB with response actions and commands selected by the business users from the GUI.

E: The inbound template manager returns the newly created inbound template ID (generated by the inbound template DB) to the new message type generator.

F: The new message type generator then stores the newly created message type (embedded inbound template ID) in the SMS universal encoding template (part # 5).

2.1 encoding outbound message only message

The SMS Message Configuration Wizard enables business users to send messages to users registered with the e-commerce system. The business user only needs to select the message type, enter the message text, and click the Submit button.

Microscopic flows: data collection interface, SMS input data collection and message encoding engine

Message processing by the encoding engine is indicated by arrows indicated by letters in FIG. 6 as discussed below.

A: Normally, the message subsystem 107 or the SMS message GUI wizard (parts # 4, 112) call the APIs 510-516 of the data collection interface 117, part # 1 to collect data from the message creator. Hand over.

B: APIs 510-516 of the data collection interface pass the data to the data collection object 518. For example, by calling the text message setup API 514 with the message text as a parameter, the API 514 will store the text in the data collection object 518.

C: The message transfer API 516 invokes the classified SMS message encoder 701. It retrieves the message type name from the data collection object 518. The message type name is captured by the message instance generation API 510. Also at this stage, the sorted SMS message encoder 701 collects other information from the data collection object 518 such as transmission time, transmission priority, response template ID, text message, recipient information.

D: Using the message type name, the sorted SMS message encoder 701 retrieves the SMS universal encoding template 113 for this message type.

E: The classified SMS message encoder 701 converts the SMS universal encoding template 113 into a temporary classified SMS message instance 702 represented as a document object model (which is an internal structure of XML). 702 is generated and populates the information collected from the data collection object 518 in step C.

F: Send the temporary classified SMS message instance 702 to the SMS message verifier 703 and perform the verification. The verification process checks for essential data, data semantics, data syntax, and data ranges.

G: If the verification is successful, the SMS message verifier copies the temporary classified SMS message instance 702 to the final classified SMS message instance (parts # 6, 114).

The steps 801 through 808 of FIG. 8 describe the process in a graphical flow chart.

2.2 Encoding of Response Needed Message

For SMS messages that require a response, an inbound template must be included in the original outbound SMS message to the recipient. Inbound templates provide a form-based input mechanism to the receiver. The inbound template is adapted to encode the expected response of the SMS message recipient. Inbound templates relieve the receiving user of the need to formulate a response back to the application configuration 108 that generates outbound SMS messages to the recipient. The response template serves to force the user's response by indicating the format of the response the user needs. As a result, the user's response will be a form that can be automatically processed by the web application server.

Inbound Template: The structure of the inbound template is illustrated below.

<Short Message Text>

-

<Encrypted String>

-

<response action 1>

<response action 2>

<response action n>

PIN: <mobile user personal identification>

The inbound template structure described above supports a plurality of response actions. Depending on the type of transaction, the recipient, such as the wireless user, will pick one of the response actions.

8 describes the appearance of an outbound SMS message indicating that the receiving user needs to respond, as shown on the user's digital cellular phone screen 901.

The SMS message string that achieves this will look like this: Your cheque bounced! -Kis2-CONFIRMED: _PIN: _

2.2.1 SMS Response Message Encoding Template Configurations

As shown in FIG. 9, SMS response message encoding template configurations for inbound templates include:

C Short Message Text (902)

C encrypted string (903)

C <response action 904>: <response data 906>

C PIN (905)

10 illustrates an SMS inbound message with a user response entered before being sent.

2.1.1.1 Short Message Text (902)

This is the message the message creator intends to send to the recipient.

2.2.1.2 Encrypted Strings (903)

An encrypted string is a four-character hashed string delimited by a pair of '-'s.

The encrypted string is based on the fusion of the following information.

-Web application ID (e.g. store ID) (predefined by the web application manager)

-User ID (recipient login ID for this store)

-Inbound template ID (including command and expected parameters) as each database entry

Action ID (ID representing the response actions allowed for this message)

Hash Key-The user can change the key to expire at any time. This can be stored in a file in a restricted directory.

The runtime processor 110 uses this information as input to generate this encrypted string. The runtime processor also generates an inbound template before sending the SMS message to the wireless message gateway 103.

Advantages of using encrypted strings:

Encrypted strings are limited to 4 bytes, saving space from the 160 character limit.

Encrypted strings are hard to understand

Business users can change the hash key at any time by imposing an arbitrary timeout.

Runtime processor 110 may filter out unwanted incoming messages. Invalid or missing encryption strings indicate that the message is unwanted.

Users can store inbound templates on their mobile devices so that they can initiate transactions with the designated web application at any time by free will. This advantage will be discussed in detail in section 2.3.

2.2.1.3 <response action>: <response data>

The response action 904 is a keyword that identifies the allowed response actions and corresponding parameters. For example, the accepted response 904 is CONFIRMED. For example, the user of FIG. 10 has entered a response 906 Y. There may be one or more allowed responses for further transactions. There are three subelements in this response:

1. Response action-a keyword that represents the action, such as CONFIRMED

2. Instructions-Web application programs or instructions invoked by the runtime processor

These response actions and commands are stored in an inbound template DB (part # 8) indexed with a unique inbound template ID. Business users can use the SMS Message Configuration Wizard (part # 4) to manage these response actions. See Section 2.2.3, How to Manage Inbound Templates Using the SMS Message Configuration Wizard.

The runtime processor invokes a command with <response data 906> when a responding SMS message is received.

2.2.1.4 PIN

The PIN element 905 provides the user to enter a PIN number 904 specified by the user upon user registration (1234 entered by the user in this example). With the user ID and PIN (encrypted in the encryption string), the runtime processor 110 can authenticate that the inbound message is real.

2.2.2 SMS response showing user input in response

9 illustrates a screen 1001 of a digital cellular phone with a user response.

If the mobile cellular phone user has responded to the SMS message, the user selects "Forward Message" only at the phone number designated for the web application; You will have to enter response data for one of the response actions, enter a PIN number and press the "Send" button.

In this example, the mobile cell phone user entered Y 906 next to CONFIRMED: 904 and this indicates that he / she confirmed the message.

The SMS message to be received by the web application will be similar to the following: Your cheque bounced! -Kis2-CONFIRMED: Y PIN: 1234

See section 3.2 "Response Needed Message and End-to-End Inbound Message Flow" for the processing of inbound SMS messages.

2.2.3 How to Manage Inbound Templates by Using the SMS Message Configuration Wizard

Inbound template manager 502 (FIG. 5), a sub-configuration of the SMS Message Configuration Wizard (part # 4 in FIG. 4) manages inbound templates. This includes creating and deleting mappings between response actions and web application commands.

2.2.3.1 GUI

10 illustrates a GUI 1101 that can be used to construct an SMS message for a web application server to send to a mobile user. In this instance, it illustrates a GUI for a payment exception message that could be used to generate the message of FIG.

If the business user wants to create a new SMS message type coming from this GUI 1101, pressing the "New Message" button 1102 will bring up a new SMS message type panel 400 as illustrated in FIG. . This panel can then be used to create a new message type.

Clicking the "Add" button 412 will bring up the Add SMS (Response) Inbound Template panel illustrated in FIG.

2.2.3.2 Inbound Template Manager Schematic

12 illustrates the structure of inbound template manager 202.

The flow annotations for the inbound template manager are:

A: Business user 900 invokes new message type generator 201 to create a new message type.

B: Business user 900 invokes inbound template manager 202 to create a new inbound template for the new message type.

C: The inbound template manager retrieves a list of predefined commands from the inbound template DB 115. The command list is defined by the application configuration 108 (FIG. 1).

D: The inbound template manager 202 collects the information from the GUI and updates the inbound template DB 115.

E: Inbound template manager 202 returns the newly created inbound template ID (generated by inbound template DB 115) to new message type generator 201.

F: The new message type generator 201 then stores the newly created message type (embedded in the inbound template ID) in the SMS universal encoding template (parts # 5, 113).

2.2.3.3 Inbound Template Management Flowchart

FIG. 13 illustrates a flow diagram illustrating steps 150 through 158 how the SMS message construction wizard will be used to manage the response actions described above:

2.3 Inbound Message Encoding for Consumer Consumption

Another useful application of the inbound template is to enable mobile users to submit requests to the web application. For example, a user can send a request for an account balance to a web application. Using the stored inbound template for the account balance request of the mobile device, the user can send this inbound template as an inbound SMS message. In response to this request, the web application will send the account balance as an outbound SMS message in which the incoming message is assumed to have been verified and authenticated.

2.3.1 Steps to implement this feature:

Step 1: The business user defines a list of inbound templates. This can be done using procedures similar to the creation of a new message type. A new message type called "InboundRequestGenericMsg" must be defined initially. The business user can then derive another inbound request message type with the attached inbound template.

Step 2: An application configuration called "customer services" publishes a list of defined inbound templates on the store website.

Step 3: Users log on to the store website and select the inbound templates they want to download.

Step 4: The customer service application configuration sends the selected inbound templates to the mobile device. Transmission can be completed by using a normal message subsystem that calls the APIs (part # 1) of the data collection interface.

2.3.1 Structure

14 is a structural diagram of an SMS system according to a preferred embodiment of the present invention, which describes a procedure of sending an SMS message by a business user.

The flow annotation looks like this:

A: Business user 900 defines new message types and corresponding inbound templates. This is done by using the SMS Message Configuration Wizard 112 (FIG. 1).

B: The SMS message configuration wizard 112 stores these new message types and inbound templates in an SMS universal encoding template (parts # 5, 113) and an inbound template DB (parts # 8, 115), respectively.

C: The mobile user 901 logs on to the web site for that system and requests a list of inbound templates.

D: The customer service application configuration 161 obtains inbound template IDs from the SMS universal encoding template 113. Using the IDs, customer service application configuration 161 retrieves the available inbound templates from inbound template DB 115.

E: The customer service application configuration 161 displays the list of inbound templates to the mobile user 901.

F: The mobile user 901 selects the desired inbound templates and requests them to be sent to his / her mobile device.

G: The customer service application configuration 161 typically sends a request to the message subsystem 107 to send the selected inbound templates as generic SMS messages.

H: Normal message subsystem 107 calls APIs (parts # 1, 117) of the data collection interface to send inbound templates as normal SMS messages.

I: The SMS message encoding engine (parts # 2, 111) encodes SMS messages containing inbound templates and sends them to the runtime processor (parts # 3, 110).

J: Runtime processor 110 inserts the encrypted string into SMS messages. This encrypted string should preferably not have an expiration time since templates are used for input requests. Send SMS messages to wireless message gateway 162.

K: Wireless message gateway 162 delivers these messages to mobile user 901.

L: The wireless user 901 stores these inbound templates in the storage of his / her mobile device. The mobile user 901 can now use these inbound templates to submit a request or requests to the application configuration 108.

M: The wireless gateway 162 sends inbound SMS messages from mobile users to the runtime processor 110.

N: Runtime processor 110 examines the encrypted string of the inbound SMS message to determine if it is an inbound request. If the message is authenticated, the runtime processor 110 invokes the corresponding command that the appropriate application configuration 108 of the SMS-enabled commerce system has.

2.3.2 Flowchart

FIG. 15 illustrates a flow diagram in which a business user obtains selected inbound templates in accordance with a preferred embodiment of the present invention, similar to that described in FIG.

3. Overall flow of runtime

This section outlines the runtime processing of an embodiment of the present invention and covers outbound message generation and inbound response message processing.

3.1 Overall processing flow from outbound message to message

5 is an outbound flow chart describing the outbound message handling flow of an SMS e-commerce system as one embodiment of the invention.

17 illustrates an outbound flow chart in the environment of the present invention. Referring to FIG. 17, the following can be seen:

Check whether the classified SMS message instance 114, generated by the message encoding engine 111, is a scheduled message.

If it is a scheduled message to be sent later, store the message in SMS message tracking DB 195. The scheduler 182 periodically reads the SMS message tracking DB 195 to retrieve messages that are scheduled to be sent.

If the message is to be sent, the message will be checked for type error by comparing with the type stored in the universal encoding template 113.

If there is a type error, generate and return an error.

If there is no type error, the XML parser 1918 is used to parse the message as input to the universal encoding template 113.

XML parser 1918 parses the classified SMS message instances in DOM tree format 1912.

Check if the message requires a response

If no response is needed, the wireless gateway 103 is used to dispatch the message and stop it.

If a response is needed, extract the message template ID from the parsed message.

Find inbound template 1916 using message template ID from inbound template DB 115.

Create a final SMS message using the classified SMS message instance 114 and inbound template 1916.

Create a session object 1927.

Generate an encrypted string 1924 using a session object, WebAppID (WebAppID) 1928, UserID (UserID, 1929), Template ID (1930) and Encoding Key (1931).

Insert the encrypted string 1924 into the final SMS message.

Dispatch the last SMS message using the wireless gateway 103 and stop.

3.2 Overall processing flow of inbound and inbound messages

18 shows an inbound flow chart. You can see:

Wireless gateway 103 receives inbound SMS message 2003.

The runtime processor 110 extracts an encrypted four character string 2005 from the inbound SMS message 2003.

Decode the encrypted string 2005 with the encoding key 1931.

• If decoding is not successful, stop.

If decoding is successful, extract the web application ID from the encrypted string 2005.

• If the web application ID does not match the current web application ID, stop.

If the web application ID matches the current web application ID, the template ID is extracted from the encrypted string 2005.

Inbound template 2014 is obtained from inbound template DB 115 using the template ID extracted above.

Extract parameter names, commands, values 2017 from the inbound SMS message 2003.

Extract the user ID from the encrypted string 2005.

Generate a message for the commerce server (command context object 2020) using the command name, parameters and user ID extracted above.

Dispatch the message to commerce server 108.

All are completed.

16 illustrates a detailed example of a runtime processor 110 that is an embodiment of the present invention, describing details sufficient to describe the acknowledgment runtime processing flow. A description of the configurations of the runtime processor 110 and their interactions is as follows:

Classified Message Instances: Classified message instances 114 are actual outbound SMS messages received from the encoding engine (or scheduler for scheduled messages). In the current implementation, this message is encoded in XML according to the Universal Encoding Template Scheme.

Classified Message Parsing Subsystem: The Classified Message Parsing Subsystem 181 consists of parsers for Classified XML Messages. Its role is to verify that the incoming message is encoded correctly according to the method and also parse this message into a DOM tree (for the current implementation).

The output of this subsystem is a parsed object that contains all of the contents of an outbound SMS message in a computer readable memory object format.

Message Tracking Subsystem: The message tracking subsystem 183 updates the SMS tracking DB with statistics regarding message transmission time, message reception time, and the like.

Scheduler: The scheduler subsystem 182 provides timely relaying of SMS messages. If it is necessary to send an SMS message at some scheduled time, this subsystem caches the message in the message tracking DB.

The subsystem also polls the message tracking DB at a time interval determined by the business manager, picks up the messages that are ready to be dispatched, and sends them to the classified message parsing subsystem for delivery.

Application Key Generator Subsystem: The application key generator subsystem 184 generates an encrypted string that is sent in SMS messages that require a user response. This subsystem encodes this session string using a system wide, time sensitive encoding / decoding key.

Encrypted strings include:

1. Web Application ID

2. User ID

3. Inbound Template ID

4. Session Object ID

Since this encrypted string is based on time sensitive encoding and decoding keys, it is possible to achieve session effects of SMS which were not previously possible.

As a concept of sessions currently introduced in SMS, we can now create session objects that can be used for SMS-based session data storage.

After the encrypted string is decoded with a time sensitive decoding key, each element (Web Application ID, User ID, Inbound Template ID, and Session ID) is assigned to the corresponding decoding key (Web Application ID Key, User ID Key, Inbound Template ID). Key, and session ID key) can be decoded in two steps.

Therefore, the final decoding is a two stage encoding scheme that can be successfully decoded if both the system wide encoding and the web application ID are correct. This brings additional security to the outbound session string.

Outbound message generator: The outbound message generator subsystem 185 uses the parsed outbound SMS messages generated by the classified message parsing subsystem and the session strings generated by the application key generator subsystem to generate the final 160 character outs. Encode the bound message. After generating this SMS message, the outbound message generator sends the outbound message to the wireless gateway 103 for final delivery to the end user.

Inbound Message Parsing Subsystem: The inbound message parsing subsystem 186 has a first task of decoding each incoming message using an encrypted string and a system wide encoding key and a web application ID. After verifying that this message can be decoded correctly, the subsystem extracts the inbound template ID and looks up the inbound template from the inbound template DB to parse the incoming message.

Successful parsing of inbound messages results in the extraction of incoming commands and parameters. This subsystem then extracts the user ID from the encrypted string and creates a command context object for this incoming request. Before creating the command context object, this configuration also verifies the PIN number entered using the authentication mechanism of the application configuration 108 for authentication.

The next step is to actually dispatch this message to the appropriate application configuration.

Tracking of incoming messages for reception time and other statistics works in conjunction with the message tracking system.

The embodiments described herein provide advantages and features over existing SMS messaging systems.

1. Confirmation

Inbound templates, which are part of the outbound SMS message text body, provide the system for confirmation to be processed immediately by the web application.

The SMS response database enables runtime verification for message types.

Absence of verification in existing SMS systems hinders SMS applications in commerce. The solution to this limitation is disclosed with an encrypted string, such as a user ID and a PIN, which enables the user to be identified.

2. Security

Preferably the inbound SMS message comprises an encrypted string with two levels of password. This ensures that only a suitable web application handles incoming SMS messages destined for that web application.

User ID is obtained by two levels of User ID key, along with user specific PIN number and provides additional layers of security protection.

4-byte security mechanism can enable SMS applications in commerce.

The two-level encoding used here is new, such as fusing four elements (web application ID, user ID, inbound template ID, session object ID) into four bytes and decoding them into two levels of keys.

3. Session Control

If the session ID is encrypted in the SMS string, this will provide timeout control for typical http sessions.

Matching encrypted strings to outbound messages provides a request and response model and enables session establishment.

With this session, close requests and responses between the user and the web application are possible and enable the commerce application of SMS to be realized.

The 4-byte encrypted string in the message is new.

-Time stamps and system keys added to encrypted strings are new.

The SMS Response DB, which manages the session effect of request / response SMS messages at runtime with the runtime process, is new to SMS messaging.

4. Scalable syntax: rules for encoding and decoding SMS messages

The encoded inbound message template enables accurate conversion of inbound SMS messages, resulting in accurate mapping to selected business activities of the messaging system web application.

This syntax is extensible for creating new inbound message templates.

Incorporating inbound message templates into outbound messages is new to SMS so that users do not need to formulate their inbound messages. Now the user only needs to fill in the specific parameters required.

-The scalability of the syntax to create different syntax for new message types is new.

5.1 Extensible Semantics: Conversion of Encoding Mapped to Obvious Business Activity

The predefined categorization of embodiments of the invention is serviced as a contract between the user of the business process and the web application, so that the conversion of a given SMS message is accurate and maps the predefined business process to explicit business activity. Enables commerce application of SMS.

Basic categorization is extensible to define new categorizations for new mappings of business activities.

In the field of SMS, XML-based applications (such as SMS universal encoding templates, with unique characteristics that include categorization and bring in new categorization) are new.

5.2 Extensible Semantics: Handling SMS Messages at Run Time According to Encoding Characteristics of Corresponding Message Types

The SMS Universal Encoding Template makes it possible to share extra information about SMS messages between the web application and the message runtime processor. The runtime processor (based on additional semantic characteristics defined in the SMS type) can now perform runtime tasks that conform to the type that matches the intent of the sender (business user) as understood by the web application.

6. Improved usability

Business users can now avoid the technical complexity of encoding SMS messages to match their business intentions. Business users can now focus on the content of a message without being confused by SMS message encoding.

The SMS commerce solution of the present invention reduces the likelihood of encoding errors (because SMS encoding errors are difficult and expensive to resolve at runtime). The encoding mechanism ensures error checking and enables early identification of encoding errors.

Claims (28)

A method for generating an SMS business message for processing by a software application, the method comprising: A data collection interface accepting instructions sent from the software application and data sent; A message encoding engine encoding the outgoing instructions and outgoing data from the software application using an encoding template to generate an SMS business message as a formatted and categorized SMS message for processing by a data processing system; And And a dispatcher runtime processor processing the SMS business message for transmission to a recipient on a network. 2. The method of claim 1, further comprising sending the SMS business message to a recipient on a network. The method of claim 2, wherein the SMS business message, A message text entry field for changing a recipient for a commerce event; And And an encryption string entry field. The method of claim 3, wherein the SMS business message, Response indicator label; A receiver data entry field associated with the response indicator label; Recipient authentication indicator label; And And a recipient authentication data entry field associated with the recipient authentication indicator label. 5. The method of claim 3 or 4, wherein the encrypted string entry field is adapted to accept communication session identification data. 6. The method of claim 5, wherein said session identification data can be used in connection with a response of a sent message. 7. The method of claim 6, wherein said session identification data can be used to identify a software application that processes a response of a sent message. 5. The method of claim 3 or 4, wherein the encrypted string entry field is adapted to accept secure data. 5. The method of claim 4, wherein said recipient authentication data entry field is adapted to accept a personal identification code (PIN) from said recipient. The method of claim 4, wherein the SMS business message, A first recipient data entry field associated with the response indicator label, the first recipient data entry field adapted to allow the responding recipient to insert a response; And  And a second recipient data entry field associated with the authentication indicator label, the second receiver data entry field adapted to allow the responding recipient to insert a response. The method of claim 1, The encoding template includes the categorization metadata defining the categorization of SMS business messages, The categorization indicates the intended usage of particular businesses; The categorization metadata provides a definition of the categorization; Categorization metadata is parseable by the data processing system to generate SMS business messages. The method of claim 11, The encoding template includes a message entry field for insertion of a message entry of full SMS message length for access by the recipient, The template provides additional fields in the SMS business message for categorization metadata; And wherein said metadata provides instructions for encoding the intended usage of an SMS business message. The method of claim 12, The metadata includes instructions for dispatching the SMS business message, the message priority; Delivery time; Number of recipients; Delivery channel; Need for confirmation; Authentication required; Encryption required; And instructions selected from a web application intended to handle the response. 13. The method of claim 12, wherein said metadata includes instructions for identifying a software application intended to handle a response to said SMS business message. The method of claim 2, Receiving, by a server, response messages from a receiver as a response to the transmission of the SMS business message; Decoding an encrypted string in the SMS response message with an appropriate key to confirm that the response message is directed to the server; Extracting an identification from the SMS response message to process the information in the response; Identifying and obtaining an inbound template corresponding to the response message from the server; Optionally, parsing the response message into the inbound template to extract incoming data and incoming instructions contained in the response message to process data and instructions. 16. The method of claim 15, further comprising sending the incoming data and incoming instructions to an application server for processing. The method of claim 16, wherein the SMS response message, An encrypted string encoded with an encoding key; Identification of a software application capable of processing the response; And SMS business message generation method comprising the user authentication information. The method of claim 17, The server can access the encoding key; And the server has access to the inbound template. The method of claim 2, Receiving, by a server, response messages from a receiver as a response to the transmission of the SMS business message; And The response tracking database further comprises the step of tracking the SMS response message in the response tracking database. The method of claim 19, Identifying and parsing the SMS response message by an inbound template database; And And the dispatcher processes the SMS response message and sends the SMS response messages to the software application. Means for generating an SMS business message for processing by a software application, Means for the data collection interface to accept instructions and data sent out from the software application; Means for a message encoding engine to encode the outgoing instructions and outgoing data from the software application using an encoding template to generate an SMS business message as a formatted and categorized SMS message for processing by a data processing system; And Means for processing the SMS business message for dispatcher runtime processor to send to the recipient on a network. 21. A computer program product loadable directly into an internal memory of a digital computer and comprising software code portions for performing the method of any one of claims 1 to 20 when the product is run on a computer. A method for processing incoming e-commerce SMS response messages received by a server from a recipient responding to an outgoing e-commerce SMS message, comprising: Receiving the SMS response message; Decoding an encrypted string in the SMS response message with an appropriate key to confirm that the response message is directed to the server; Extracting an identification from the SMS response message to process the information in the response; Identifying and obtaining an inbound template corresponding to the response message from the server; And In some cases, an incoming e-commerce SMS response message processing method is characterized by parsing the response message into the inbound template to extract data and instructions contained in the response message to process data and instructions. An SMS commerce message format for use in sending commerce messages to recipients over a network. A message text entry field for changing a recipient for a commerce event; An encrypted string entry field; Response indicator label; A receiver data entry field associated with the response indicator label; And an recipient authentication data entry field associated with the recipient authentication indicator label. 25. The SMS commerce message format of claim 24, wherein the encrypted string entry field is adapted to accept communication session identification data. 25. The SMS commerce message format of claim 24, wherein the encrypted string entry field is adapted to accept secure data. 25. The SMS commerce message format of claim 24, wherein the recipient authentication data entry field is adapted to accept a PIN number from the recipient. An SMS universal encoding template for encoding outbound SMS messages for a data processing system for transmission over a network, wherein: Categorization metadata defining categorization of outbound SMS messages; The categorization indicating usage intended for a particular business; And And the categorization metadata that provides definitions of messages and instructions that are parseable by the data processing system to generate SMS business messages.