WO2003088688A1

WO2003088688A1 - Method and system relating to control of mobile radio messaging communications

Info

Publication number: WO2003088688A1
Application number: PCT/SE2003/000583
Authority: WO
Inventors: Jan Fredrik Erland Erlandson; Paul John Martlew; Per Anders Bertil Olin
Original assignee: Mobile Arts Ab
Priority date: 2002-04-12
Filing date: 2003-04-10
Publication date: 2003-10-23
Also published as: SE0201108D0; AU2003223151A1

Abstract

The present invention relates generally to a method and system for end-user controlled processing and routing of messages based upon parameters other than message destination address, such as Time, Location, Subscriber Identity, Equipment Identity and Service Control Commands, etc in a mobile radio communication system. The Service Control Commands, which are transferred as part of the message and handle the control and request of specific network services, are transferred to a central message processing point, the Message Handling Server, which can understand these commands and act upon them. A set of commands is presented that allow the end user to control aspects of his/her pre-payment service, messaging service, ascertain the availability of others, locate others and indicate that others are allowed to locate the end-user, etc.

Description

METHOD AND SYSTEM RELATING TO CONTROL OF MOBILE RADIO MESSAGING COMMUNICATIONS

Field of the Invention

The present invention relates generally to the field of mobile radio messaging communications, and more particularly to a method and system for handling mobile system end-user service preferences and behaviour via mobile messaging in a mobile radio communication system.

Background of the Invention

Mobile radio telephony has become an important part of today's society, and many people are in the possession of a Mobile Station. One of the most widely used forms of communication using these Mobile Stations is messaging, which encompasses the sending of text, pictures, audio or other media content to and from Mobile Stations. Routing of the message to its destination can be via for example an e-mail server, a short message service centre or a multi-media messaging service centre. The type of messaging can be performed either by virtual circuit establishment for confirmed transfer, or via datagram for unconfirmed transfer. - -- _ - . ,

Irrespective of the way message contents are transferred, it is beneficial for the end-user of the Mobile Station sending a message to be able to control the way that messaging and other services provided by the network to the user are performed. It is also beneficial for the end-user and/or the service provider to be able to route messages not only based on message destination address, but based on other parameters as well. These parameters could be used in combination or in place of message destination address, and include equipment and subscriber identifiers such as International Mobile Station Identifier (IMSI), International Mobile Equipment Identifier (IMEI); commands embedded in the content of messages; time; etc. These routing analysis alternatives may be summarised by stating that routing is best performed using a combination of one or more end-user controlled parameters and one or more network parameters. Examples of end-user controlled parameters are the destination address, message originating address (if the end-user is subscribed to services such as multiple subscriber profile) and commands embedded in message user data, whilst examples of the network-based parameters are time, IMEI, IMSI, originating or terminating party location, etc.

Routing analysis performed in this way allows the user to be able to request notification when an end user has attached to the network and is thus reachable for instant messaging purposes, to append his location, to request the location of the party or parties to whom the message was delivered, etc. A simple way of controlling message routing and handling using message user data is to construct the messaging system such that the message contains control information to indicate how analysis shall be performed, and upon what message or network information. A central message processing point then analyses the control information plus relevant message parameters and selects an Application that can provide further handling of the message. This handling may include changing the destination address to modify onward routing of the message, reformatting the message, adding elements to the message, terminating the message and sending a response, interacting with other network services, etc.

For this flexible control of message-handling to be exercised in the network using parameters other than destination address that are embedded in the message itself or using network parameters such as location or time, it is sufficient to construct suitable handling in the central message processing point. However, for flexible control of message handling to be exercised in the network using message user data, the end-user must instruct

("command") the network regarding the control to be exercised, and the network must be able to understand these instructions ("commands"). These commands and the parameters other than message destination address will be parsed by the short message service centre, multi-media messaging service centre, e-mail server, etc that has been adapted to interpret the commands - henceforth referred to by the generic name of Message Handling Centre

For the user and for the network operator, it is beneficial if the method of defining the commands requires change at only the network side to introduce new commands. This is because the user is significantly disadvantaged if a new terminal has to be purchased to support new commands and the network operator is significantly disadvantaged if any network nodes other that the server acting as the command interpreter need to be updated or purchased. In both cases, the penalty is in terms of cost and convenience. In addition, it is beneficial if the commands are introduced in user data, as they are then portable between standardised messaging specifications and require no synchronisation of protocol parameter usage and definition between these specifications, such as would be required if user-specific fields were to be used in GSM SMS-specific User Data Header SMSC- specific parameters. Such synchronisation again causes considerable disadvantage to the end-user, as it is difficult to achieve.

In order to address these disadvantages, it is proposed to embed the commands directly into the transferred media content, such that only the end-user and the server acting as the command interpreter need handle the input and analysis of the commands. This approach allows the commands to be used across multiple messaging systems and terminal types, with the use of different media types also possible. As an example, to append the message originators' location using the GSM short message system for data transfer, the character combination ".A" can be used to indicate append as the first characters in the message user data. If the UMTS multi-media messaging service is being used then a suitable graphic or audio clip indicating location append can be included as user data e.g. a picture of a Mobile Station or a digitised voice clip saying 'my location' .

As a refinement of this technique, the Mobile Station could have a role as a command formatter with the commands being selected by the end-user using man-machine interface menus, radio buttons, etc. The Mobile Station would then generate the corresponding command and include in the message user data. This could be achieved today using various combinations of technology such as Wireless Application Protocol Wireless Telephony

Application (WTA), J2ME or SIM Application Toolkit to accept command requests via the man-machine interface in a programmable manner and translate them for inclusion in the message. Again, because these types of interface are programmable and downloadable from the central server only the central server is impacted when additional commands are added, the program interpretation interfaces on the Mobile Station remaining fixed.

Finally, it is noted that the basic mechanism described above could be expanded to allow the use of such commands with other types of value-added services e.g. CAMEL or IN services, for easy pre-paid service credit refill or for the control of service options such as NPN forwarding settings, etc. Because this is the case, the name "Service Control Commands" is given to these embedded message user data commands. Note that the identity of the party originating the message and the specific Service Control Command will for example normally be used by the Application called for those Service Control Commands relevant to such network services. This is in order to modify the message destination address such that it can be routed to the appropriate IN or CAMEL server that the message originating party is registered at and which contains the originating party's subscription details.

Some attempts have been made in prior art to enable a subscriber to monitor and govern routing of circuit-related telephone calls. EP,A1, 651 548, for example, reveals a system for routing telephone calls in which a dialled telephone number is translated into a routing number according to instructions from a database maintained by a telephone subscriber. This system enables a subscriber to customize and maintain its own database for the routing of circuit-related telephone calls made in telephone networks supporting Intelligent Network systems. The system is call related, and the central database only handles the flexible setup of the signalling virtual circuit and associated speech path towards one of many destinations via translation of the dialled number into a routable number, under operator and/or subscriber control. WO,Al, 94/29992 reveals a system and method for providing a subscriber with the ability to screen and route incoming circuit-related calls based on the role or function associated with the numbers dialled by a calling party.

The major difference from presented prior art, besides that present invention deals with routing of datagram messages and not of circuit-related telephone calls, is that present invention does not translate the number at the network database to point out the destination. The present invention, as will become more apparent by the following description, instead redirects a message to an intermediate node using a preset number associated with the combination of services that shall be operated upon the terminating message, preserving the origin and destination numbers. This enables the ability to transparently intercept, analyse, modify and then route the datagram message to the original receiver.

Objects of the Invention

One object of the present invention is to make the network handling of Service Control Commands possible at all times and with all Mobile Stations supporting a messaging service, to a subscriber of services in a mobile radio network. Another object of the invention is to make the network formatting, onward routing, termination and response handling of mobile messages conditional upon both the command being analysed and a fixed set of message parameters, the semantic interpretation of which are governed by the identity of the Service Control Command. Another object of the invention is to allow for direct entry by the subscriber of Service Control Commands, such that neither the Mobile Station nor any network node other than the Message Handling Centre need be updated in order to process the entered command successfully.

Yet another object of the present invention is to allow for the subscriber to enter Service Control Commands via a remotely programmable interface on the Mobile Station, such that the man-machine interface on the Mobile Station can be changed at the request of the Message Handling Centre or other coordinated network node. In this case, the transformation of the data entered in man-machine interface data entry format into Service Control Command format and the subsequent inclusion of the translated command into the user data part of a message is defined by the downloaded program. In this way, neither the Mobile Station nor any network node other than the Message Handling Centre need to be updated in order to process the entered Service Control Commands successfully.

Yet another object of the present invention is to allow the Message Handling Centre to execute internal or external hardware/software functions (Applications) to process the received Service Control Command.

Disclosure of the Invention

According to the invention, the stated objects are met by a method of handling Service Control Command entry and the incorporation of one or more Service Control Command(s) into message user data. The Mobile Station (or user equipment for UMTS) transmits messages containing user data (provided that the end-user has a valid network subscription) to a Message Handling Centre via a mobile radio network, the mobile radio network being part of a mobile radio communication system. The Message Handling Centre has the capability of receiving and processing the message, of being associated with different internal and/or external hardware/software Applications and of exchanging data with these Applications via internal or external protocols.

In the inventive method, the end user either enters Service Control Commands into message user data directly or indirectly via Mobile Station man-machine interface commands, which are then translated into Service Control Commands and inserted into the message user data. The Service Control Command(s) embedded in the message user data are sent from the Mobile Station to the Message Handling Centre, which parses the message user data. If a Service Control Command is found by this parsing, the Message Handling Centre formats the Service Control Command data appropriately, and relays it to the Application associated with the Service Control Command. Note that the Message

Handling Centre will handle each command in different ways. For instance, if a location is to be appended to a Mobile Station originated message then the Message Handling Centre will send the Service Control Command to the Application (which may be trusted and collocated or external and 3^rd party) using an appropriate protocol; the Application will retrieve the terminal location. If the whole message user data was passed, it can insert the location itself in the message and pass it back to the message service centre for onward routing. Otherwise, if passing of all of the user data is not possible the Application will pass the location back to the Message Handling Centre for insertion into the message at the desired point.

The objects of the invention are further met by the specification of a basic Service Control Command set. The minimum prerequisite for the command set is that command specification using text shall be possible in order to ensure ubiquitous usage of the system, with optional audio and graphical command specifications being possible when applicable. An illustrative example of a Basic Service Control Command Set with text and audio commands is given in figure 1. No examples of graphics are being given, which does not preclude their use.

For all of the text and audio commands, it is assumed that the message user data may be in any media format, and that at least two parts of user data in different formats may be carried. Inclusion of message text or other media (picture, voice message, etc) is optional for some services but mandatory for others e.g. pre-paid refill and balance enquiry, and it is left to the Application and/or end-user to decide on inclusion. Entry of the message user data per se is not detailed in the audio commands above.

The Mobile Station is associated with a subscription to messaging services, said subscription having the possibility of being associated with different Mobile Stations at different times. The Mobile Station comprises a Subscriber Identity Module (SIM) with message sending and receipt capabilities for storing Mobile Station phonebook contents, and optionally a WAP browser with WTA user agent and repository or an ME and SIM that supports the SIM Application Toolkit or a-J2ME execution environment. Optionally the Mobile Station may be divided into two parts. The first part comprises a mobile equipment part that has battery, man machine interface, control circuitry and radio interface, etc. The second part comprises a Subscriber Identity Module, containing subscriber specific control algorithms and data. The inventive system for mobile radio communication comprises a first server section comprising a server containing a Message Handling Centre for analysis and modification of received messages, the first server section also for sending the received messages to a destination Mobile Station or Application as a result of routing analysis based on message destination address and Service Control Command(s). The inventive system further comprises a second server section containing Applications for operating on Service Control

Commands received from the Message Handling Centre, the second server section also returning the results of this operation to the Message Handling Centre in the first server section. The inventive system further comprises optionally a third server section for storage and downloading of programs to the Mobile Station for the translation of terminal-specific input data into Service Control Command(s) using Mobile Station-based execution environments such as J2ME, SAT or WAP/WTA. These commands are then sent to the Message Handling Centre in the first server section. In the inventive system, the Mobile Equipment repository or the SIM optionally comprises storage for default Service Control Commands. The first, second and third server sections could be logically and/or physically co-located, or located at separate servers. Brief Description of the Drawings

FIG. 1 illustrates an example table of a Basic Service Control Command Set with given text and audio commands; FIG. 2 illustrates the general topology of a GSM network, showing the network functions that are necessary in order to route short messages;

FIG. 3 illustrates an example of Mobile Messaging showing Application Invocation by

Service Control Commands; FIG. 4 illustrates an example table of Basic Service Control Command analysis/actions at the Message Handling Centre and Applications; FIG. 5a illustrates MO Message Reception Handling;

FIG. 5b illustrates Message Handling Centre Invocation; FIG. 5c illustrates Message Report Handling; FIG. 5d illustrates Application Report Handling; FIG. 5e illustrates GSM Report Handling; FIG. 5e illustrates Outgoing Route Analysis.

Description of the Preferred Embodiments

In the inventive method, the end-user either enters Service Control Commands into message user data directly or indirectly via Mobile Station man-machine interface commands, which are then translated into Service Control Commands and inserted into the message user data. The Service Control Command(s) embedded in the message user data are sent from the Mobile Station to the Message Handling Centre, which parses the message user data. If a Service Control Command is found by this parsing, then the Message Handling Centre formats the Service Control Command data appropriately, and relays it to the Application associated with the Service Control Command.

In one embodiment of the inventive method, the user directly enters the Service Control Command into the message user data, and the transfer of data between the Mobile Station and the Message Handling Centre is performed under user control using only basic Mobile

Station messaging capabilities.

In one embodiment of the inventive method, the Mobile Station comprises a Wireless Telephony Application (WTA) user agent, and the transfer of data between the Mobile Station and the Message Handling Centre can be performed by use of the Wireless

Application protocol (WAP). In this embodiment, the WTA text message sending capability could be utilised to provide a WAP-based message sending capability with an advanced API that gives the user access to the phonebook or group lists as well as to a list of Service Control Commands that can be optionally included and/or set up as messaging defaults. Storage of the defaults in the WTA repository would give the WTA-based MMI a persistent memory of Service Control Command settings.

In one embodiment of the inventive method, the Mobile Station/user equipment is equipped with GSM/UMTS SIM Application Toolkit (SAT) capabilities, and the transfer of data between the Mobile Station/user equipment and the Message Handling Centre can be performed by use of the SAT procedures. In this embodiment, the SAT short message- handling capability could be utilised to provide a SAT-based message sending function incorporating an advanced API giving the user access to the phonebook as well as to a list of Service Control Commands that can be optionally included and/or set up as messaging defaults, as well as allow receipt of delivery reports. Storage of the defaults in the SIM or USIM would give the SAT-based MMI a persistent memory of Service Control Command settings.

The inventive system for subscriber-controlled processing and routing of messages and service requests in a mobile radio communication system comprises a first server section comprising a server containing a Message Handling Centre for analysis and modification of received messages, the first server section also for sending the received messages to a destination Mobile Station or Application as a result of routing analysis based on message destination address and Service Control Command(s). The inventive system further comprises a second server section containing Applications for operating on Service Control Commands received from the Message Handling Centre, the second server section also returning the results of this operation to the Message Handling Centre in the first server section. The inventive system further comprises optionally a third server section for storage and downloading of programs to the Mobile Station for the translation of terminal-specific input data into Service Control Command(s) using Mobile Station-based execution environments such as J2ME, SAT or WAP/WTA. These commands are then sent to the Message Handling Centre in the first server section. In the inventive system, the Mobile Equipment repository or the SEVI optionally comprises storage for default Service Control Commands. The first, second and third server sections could be logically and/or physically co-located, or located at separate servers.

In one embodiment of the inventive system said first server section comprises Service Control Command analysis capabilities allowing it to recognise, for one or more media types including text, a Service Control Command embedded in message user data requesting the inclusion of the message sending party's location in the message. On analysis, the first server section shall communicate with the second server section. The second server section shall further analyse the message originating party and message- receiving party in order to ascertain that the originating party allows his/her location to be sent to the destination party. If the analysis indicates that this is allowed, the second server section obtains the location of the message sending party. This location shall for example be in coordinate or textual description form and shall be included in the message in a suitable media format by replacement of the location request. The first or second server section, dependant upon the protocol used between them, can either perform this inclusion.

In one embodiment of the inventive system said first server section comprises Service Control Command analysis capabilities allowing it to recognise, for one or more media types including text, a Service Control Command embedded in message user data requesting the inclusion of the message-receiving party's location in a response message to be sent back to the message sending party. On analysis, the first server section shall communicate with the second server section. The second server section shall further analyse the originating message originating party and message-receiving party in order to ascertain that the destinationecond server section sion to send location can also be performed in the first server sect the destination party. If t party allows his/her location to be sent to the originating party. If the analysis indicates that this is allowed, the second server section obtains the location of the message-receiving party. This location shall for example be in coordinate or textual description form and shall be included in the response message in a suitable media format and at a suitable point in the returned user data. The first or second server section, dependant upon the protocol used between them, can either perform this inclusion.

In one embodiment of the inventive system said first server section comprises Service Control Command analysis capabilities allowing it to recognise, for one or more media types including text, a Service Control Command embedded in message user data indicating that the message-receiving party is allowed to locate the message sending party. On analysis, the first server section shall communicate with the second server section in order to set the location preference for the message receiving party with respect to being allowed to locate the message sending party. Upon successful setting of the message- receiving party's preferences by the second server segment then the second server segment may either terminate message sending by request to the first server segment or request the first server segment to send the message to the message-receiving party. If sent, the message may have the original message user data replaced by user data in a suitable media format (text, audio, graphic) indicating that the message-receiving party is able to locate the message sending party.

In one embodiment of the inventive system said first server section comprises Service Control Command analysis capabilities allowing it to recognise, for one or more media types including text, a Service Control Command embedded in message user data indicating that the message-receiving party is not allowed to locate the message sending party. On analysis, the first server section shall communicate with the second server section in order to set the location preference for the message receiving party with respect to being not allowed to locate the message sending party. Upon successful setting of the message- receiving party's preferences by the second server segment then the second server segment may either terminate message sending by request to the first server segment or request the first server segment to send the message to the message-receiving party. If sent, the message may have the original message user data replaced by user data in a suitable media format (text, audio, graphic) indicating that the message-receiving party is not able to locate the message sending party.

In one embodiment of the inventive system said first server section comprises Service Control Command analysis capabilities allowing it to recognise, for one or more media types including text, a Service Control Command embedded in message user data indicating that the destination party indicated in the message is to be located by the message sending party. On analysis, the first server section shall communicate with the second server section in order to ensure that the message sending party is allowed to locate the message receiving party. If location is allowed, the message receiving party is located. This location shall for example be in coordinate or textual description form and shall be included in the response message in a suitable media format and at a suitable point in the returned user data. The first or second server section, dependant upon the protocol used between them, can either perform this inclusion.

In one embodiment of the inventive system said first server section comprises Service Control Command analysis capabilities allowing it to recognise, for one or more media types including text, a request embedded in message user data requesting that a check of the pre-paid account balance of party indicated by destination address be performed. On analysis, the first server section shall communicate with the second server section. The second server section shall then analyse the message originating party's address in order to ascertain the address of the network node holding the message-receiving party's pre-paid account details. The second server section shall then request the first server section to forward the message with the message destination address set to the address of the network node containing the pre-paid account balance and the message user data holding the command followed by the original message destination address. In this embodiment, it is the responsibility of the network node holding the pre-paid account balance to validate the message sender and then to retrieve the pre-paid account balance. Pre-paid account balance inclusion in a message response sent to the message sending party shall then be performed. This account balance shall for example be in graphical or textual description form and shall be included in the message in a suitable media format, at a suitable point in the message. The network node holding the pre-paid account balance shall perform this inclusion.

In one embodiment of the inventive system said first server section comprises Service Control Command analysis capabilities allowing it to recognise, for one or more media types including text, a request embedded in message user data requesting that a refill of the pre-paid account balance of party indicated by destination address be performed. On analysis, the first server section shall communicate with the second server section. The second server section shall then analyse the message originating party's address in order to ascertain the address of the network node holding the message-receiving party's pre-paid account details. The second server section shall then request the first server section to forward the message with the message destination address set to the address of the network node containing the pre-paid account balance and the message user data holding the command followed by the original message destination address. In this embodiment, it is the responsibility of the network node holding the pre-paid account balance to validate the message sender and then to add to the pre-paid account the monies indicated by the validated refill amount. Resultant pre-paid account balance inclusion in a message response sent to the message sending party may then optionally be performed. This account balance shall for example be in graphical or textual description form and shall be included in the message in a suitable media format, at a suitable point in the message. The network node holding the pre-paid account balance shall perform this inclusion.

In one embodiment of the inventive system said first server section comprises Service Control Command analysis capabilities allowing it to recognise, for one or more media types including text, a Service Control Command embedded in message user data indicating that the message-receiving party is allowed to receive presence information

(subscriber reachable/not reachable) pertaining to the message sending party. On analysis, the first server section shall communicate with the second server section in order to set the presence preference for the message-receiving party with respect to being allowed to obtain the message sending party's presence status. Upon successful setting of the message- receiving party's preferences by the second server segment then the second server segment may either terminate message sending by request to the first server segment or request the first server segment to send the message to the message-receiving party. If sent, the message may have the original message user data replaced by user data in a suitable media format (text, audio, graphic) indicating that the message-receiving party is able to receive presence information pertaining to the message sending party.

In one embodiment of the inventive system said first server section comprises Service Control Command analysis capabilities allowing it to recognise, for one or more media types including text, a Service Control Command embedded in message user data indicating that the message-receiving party is not allowed to receive presence information (subscriber reachable/not reachable) pertaining to the message sending party. On analysis, the first server section shall communicate with the second server section in order to set the presence preference for the message-receiving party with respect to not being allowed to obtain the message sending party's presence information. Upon successful setting of the message-receiving party's preferences by the second server segment then the second server segment may either terminate message sending by request to the first server segment or request the first server segment to send the message to the message-receiving party. If sent, the message may have the original message user data replaced by user data in a suitable media format (text, audio, graphic) indicating that the message-receiving party is not able to receive presence information pertaining to the message sending party.

In one embodiment of the inventive system said first server section comprises Service Control Command analysis capabilities allowing it to recognise, for one or more media types including text, a request embedded in message user data for the notification of the message sending party when the destination party attaches to the network and thus becomes reachable for communication. On analysis, the first server section shall communicate with the second server section. The second server section shall check that the message originating party can obtain presence information for the message receiving party. If he/she can do this then the second server segment registers the message sending party's request for destination party availability. This Application shall monitor the message destination party for presence in the network, and when the message destination party's state is noted to be attached (which may be immediate) the second server section shall via the first server section send a message response to the message originating party indicating that the message destination party has attached to the network.

In one embodiment of the inventive system said first server section comprises Service Control Command analysis capabilities allowing it to recognise, for one or more media types including text, a request embedded in message user data requesting the storage in the second server section of user defined data. This data pertains to the message originating party for inclusion in message user data when the message originating party subsequently requests this. On analysis, the first server section shall communicate with the second server section in order to pass it the user-defined data pertaining to the message sending party. This user-defined data shall for example be in graphic, audio or textual description form and shall be included in the message user data by the sending party in a suitable media format, for storage in the second server segment Application. Note that any message destination address may be entered in the message as this Service Control Command results in analysis of the message originating address only. The message shall not be forwarded to the destination address after analysis by the first server segment.

In one embodiment of the inventive system said first server section comprises Service Control Command analysis capabilities allowing it to recognise, for one or more media types including text, a request embedded in message user data requesting the inclusion of the message sending party's user-defined data in the message. On analysis, the first server section shall communicate with the second server section in order to obtain the user- defined data pertinent to the message sending party. This user-defined data shall be included in the message in a suitable media format by replacement of the user-defined data inclusion request. The first or second server section can either perform this inclusion. In one embodiment of the inventive system said first server section comprises Service Control Command analysis capabilities allowing it to recognise, for one or more media types including text, a request embedded in message user data to the copy the message to the sending party's e-mail address. The e-mail address can either be entered by the sending party in the message user data or stored on the first server section. On analysis, the first server section shall communicate with the second server section in order to forward the message as e-mail to the mailbox of the message sending party.

In one embodiment of the inventive system said first server section comprises Service Control Command analysis capabilities allowing it to recognise, for one or more media types including text, a request embedded in message user data requesting sending of the message in real-time only to the message destination party i.e. the message shall not be stored for later forwarding. If the message cannot be delivered then the message sending party shall be notified and the second server section Application shall monitor the message destination party for presence in the network. When the message destination party's state is noted to be attached (which may be immediate) the second server section shall via the first server section send a message to the message originating party indicating that the message destination party has attached to the network.

As noted in the Disclosure chapter, the Service Control Command method described is applicable to all networks where messaging is possible between a mobile network terminal and another terminal or Application, for the exchange of user data in a defined media format. This section shall concentrate on illustrating an example implementation of the method in the GSM network, as this is widely used and well understood.

The GSM short message tele-service as defined in the GSM standard can be used to send messages between defined end-points. Such an end-point is called a Short Message Entity (SME). SMEs must be capable of handling message reception, processing and if necessary response syntactically and semantically. SMEs can either be GSM Mobile Stations or any other function or device known herein as an Application. The messaging permutations allowed by the GSM standard are:

• From Message Originating Mobile Station (MO MS) to Mobile Terminating Mobile Station (MT MS) • From MO MS to Application

• From Application to MT MS

Note that because SMEs are defined as end-points the GSM standard dictates that the Application must be addressed using a message destination address or origination address. The message can be transferred between SMEs using packet- or circuit-based bearers. Functionally the delivery of messages from the SME to the Short Message Service Centre (SMSC) is handled asynchronously with respect to the delivery of messages from the SMSC to the SME.

Figure 2 illustrates the general topology of a GSM network, showing the network functions that are necessary in order to route short messages. As shown, the clouds represent combined GSM core and access networks. The diagram shows two such networks, to each of which is shown attached to an MS. Each network is shown as being attached to an SMSC. The SMSC is usually operated by the network operator to whose network the MO MS belongs, but it must be emphasized that this need not be the case i.e. in cases where the SMSC belongs to a 3^rd party Application provider. The dashed lines separating the networks from the messaging centre itself show this separation of network functions from SMSC. Note that in the case where the subscriber is roaming in the Home Public Land Mobile Network (HPLMN) network operators 1 and 2 are the same for MO short message submission to the SMSC, and network operators 2 and 3 are the same for MT short message delivery by the SMSC.

For the case of message submission to an SMSC from an MS in a GSM network the message is passed from the MS through the access network to either an SGSN (packet access) or MSC (circuit access). The MSC checks with its collocated NLR that message submission from the MS is allowed, and if it is then the message is submitted to the SMSC via an SMS inter-working MSC (SMS-IWMSC) using an SMS-SUBMIT relay layer component carried in a MAP MO-Forward SM message. The subscription information held at the NLR is transmitted to it from the HPLMΝ Home Location Register (HLR) when the

GSM Location Update, Data Insertion or Data Restoration procedures are performed. The SMSC address is held in the GSM Subscriber Information Module (SIM), but may be changed by the owner of the SIM via the MS (Man-Machine Interface (MMI) or by remote provisioning using the 3GPP GSM/UMTS SEVI data download facility. Note that if this is done then the operator of the SMSC addressed by the new entry should have already authorized access to it by the owner of the MS.

In the case of message submission to the SMSC by Application, one of a number of proprietary or industry-standard protocols may be used. An example is the SMPP protocol. These protocols are based on HTTP or XML and are mostly extensible via the addition of messages and parameters. Because the Applications are SMEs, they must be addressed by MSISDN as network message destinations.

For the case of message delivery by an SMSC to an MS in a GSM network the message is passed to the MS through the access network by either an SGSN (packet access) or MSC

(circuit access). In order to access one of these nodes the SMSC first delivers the message to an SMS-GMSC. The SMS-GMSC function checks with the home network HLR that message delivery to the MS is allowed by use of the MAP message Send Routing Information for Short Message, and if it is then the message is submitted by the SMS- GMSC using an SMS-DELINER relay layer component carried in a MAP MT-Forward SM message to either an SGSΝ or MSC. If delivery fails or is not allowed by the HLR, a negative response is sent to the SMSC by the SMS-GMSC and the message may (dependant upon whether delivery reattempt is required) be stored for later delivery by the SMSC. In this latter case, either the SMSC resends the message at periodic intervals until sending is successful, or (in the case of the MS being detached from the network) the SMS-

GMSC sends a Delivery Report Status message to the HLR requesting the HLR to inform the SMSC of terminal reactivation. This is done by the HLR sending an SMS Alert message to the SMSC when the MS reattaches to the network. In the case of message delivery to the SMSC by an Application, one of a number of proprietary or industry-standard protocols may be used. An example is again the SMPP protocol. These protocols are based on HTTP or XML and are mostly extensible via the addition of messages and parameters. Because the Applications are SMEs, they must set the message origination address as their own MSISDN, and the receiving MS as the network message destination.

The previous description of the routing principles applied to GSM short messages showed firstly that Applications are treated as end-points for message initiation and receipt by other end users of the GSM short message service. This means that:

• Application identities must be included in short messages as destination addresses, entered directly or from the phonebook.

• Messages cannot be easily relayed via Applications to destinations, because the destination address is occupied by the Application address and the phonebook cannot easily be used to insert numbers into user data with standard GSM Mobile Stations.

As shown in Figure 3, Service Control Commands can be used to allow such a message relay via invocation of Applications for messages destined for other destination addresses, these indicating either Mobile Stations or other Applications. The message flows for the message submission to the SMSC and subsequent delivery to the terminating Application or MS are the same as described previously. However upon receipt of a submitted message by the SMSC the user data is passed to the Message Handling Centre and parsed, and if a Service Control Command is encountered then it is interpreted and the Application associated with it is invoked. In the event of more than one Service Control Command being invoked it is possible to either invoke one Application to handle all commands, or to invoke more than one Application with each Application handling one or a set of commands. The External Server function shown in Figure 3 is used by the Applications to collect information from the network pertinent to the successful execution of the Service

Control Command. Thus the External Server may be a Location Server, a Presence Server, an e-mail server, etc.

It is assumed herein that the SMSC to Application protocols shall allow the carriage of Service Control Command information either explicitly or implicitly. In the former case, an

Application shall be able to handle the interpretation of multiple Service Control Commands on receipt in user data. In the latter case, the Application shall be run for specific, fixed single Service Control Commands or sets of Service Control Commands. It is not the intention of this method to place any constraints over the protocol, save that the Application should be able to be passed enough information such that it can act upon

Service Control Commands correctly.

An example of command interpretation is illustrated in the Figure 4, for some of the many possible routing selection mechanisms that could be incorporated into the Message Handling Centre. Note that the partitioning of command handling functionality can be done in such a way as to make the Message Handling Centre statefull or stateless behaviour with respect to Application interactions. The tabular representation shown illustrates a stateless Message Handling Centre, and the reader should note that the Service Control Command analysis functions could also be implemented using tree- or list-based structures. Note also that the Application identities are referred to by Application addresses 1 to 6 in the table only in order to match those shown in Figure 3, and in no way should be taken as implying a fixed link between Service Control Commands and Application addresses, or Applications and the functionality they contain. The assumed implementation does contain internal state behaviour in order to handle the modification of message reports, etc as a result of earlier Application invocation, for use when appending receiver destination address to the SMS Delivery Report, etc.

As can be seen from Figure 4, the proposal for realization of the stateless functionality of the Message Handling Centre within an SMSC is both invariant with respect to command type and simple to implement. All of the variable logic is contained within the Applications, with the variable parts of the Message Handling Centre confined to data entries in end-user controlled data, containing parameters such as destination address and Service Control Command keywords, network controlled data such as IMSI, IMEI, Time, Location for message originating and destination parties. These data structures allow the evaluation of these input parameters to produce a destination address and route type. The Application addresses are just a type of destination address, and in the outbound destination analysis the route type can be used to select the protocol to be used to send the message to the Application i.e. SMPP, GSM short messaging.

It should be noted that the interpretation of all Service Control Commands can be done sequentially if the Applications remove the command(s) that they have been invoked to handle. Indeed, as noted previously in the table the outbound routing analysis can select destinations and corresponding routes based on a combination of user defined addresses, data, locations, times, etc. The messages received from the Applications are subjected to route analysis in the same way as messages received from the message originating party and are thus treated as message originating parties, allowing Applications to insert their own Service Control Commands for distributed Application execution. Figure 5 details the successful handling of messages in the SMSC, showing the involvement of the Message-Handling Centre. For simplicity, error cases are not shown in these diagrams.

One skilled in the art will appreciate that the present invention is not limited to the embodiments disclosed in the enclosed drawings and the foregoing description, which are presented for purposes of illustration only, but it can be implemented in a number of different ways, as defined by the following claims.

It should be appreciated by those skilled in the art that the conception and specific embodiment disclosed might be readily utilised as a basis for modifying or designing other structures for carrying out the same purposes of the present invention.

It should also be realised by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims.

Claims

CLA S

1. A method for end-user controlled processing and routing of messages in a mobile radio communication system, characterised by the steps of:

defining at a central message processing point, the Message Handling Centre,:

rules governing message routing analyses based on the presence and content of:

end-user defined data including Service Control Command(s), message originating address or identity, message destination address or identity, message length or content; and/or

network defined data including time, IMSI, IMEI, message originating and/or terminating location; and

type of routing to be applied as a result of a particular routing analysis, including whether to modify data sent back to the message originator in subsequent message submit or status reports and what communication methods to use towards the message destination obtained as a result of analysis;

including Service Control Command(s) and/or other end-user defined data in a message;

sending the message;

receiving sent message at the Message Handling Centre, where the message is parsed and analysed; and

routing the message in accordance with the result of the parsing and routing analysis to an Application associated with the Service Control Command(s) and/or routing rules, or onwards to a message destination point.

2. Method as claimed in claim 1 including the steps of:

performing modification of the contents of a subsequently received message report in order to insert Application-derived data into a submitted message deliver or message status report; and

transmitting such reports to the message originator.

3. Method as claimed in claim 1, wherein the inclusion of Service Control Command(s) in the message is performed by: a message originating subscriber directly by text, voice, dedicated buttons, touch pad, menu or graphical interface; or a programmable man-machine interface, such as Wireless Telephony Application

(WTA), GSM/UMTS S Application Toolkit (SAT) or J2ME, which generates the command(s) and includes them into the message; or a message originating messaging Application.

4. A method as claimed in claim 1, wherein the parsing and analysing of the message includes recognising, for one or more message media types including text, Service Control Command(s) included in the message, interpreting included Service Control Command(s) and possibly modifying/formatting one or several of the included Service Control Command(s).

5. A method as claimed in claim 1 including the step of (re-) routing the results of the operation(s), such as requested service information, a modified message and/or modified Service Control Command(s), from the Application to a message destination point, the message originating point, another Application or to the Message Handling Centre for onward routing, wherein the result can be (re-) routed as a part of the original message, if the whole message was routed to the Application in the first place, or separate for insertion into the message at a desired point, if only the Service Control Command itself was routed to the Application.

6. A method as claimed in any preceding claim, wherein the message can be of a SMS-, WAP-, or GSM UMTS SIM Application Toolkit (SAT)-type.

7. A method as claimed in claim 3 or 6, wherein the API incorporated in the WAP- and SAT-based messaging type enables use of Service Control Command lists that can be optionally included and/or set up as messaging defaults for easy handling and inclusion of Service Control Command(s) in messages.

8. A method as claimed in any preceding claim, wherein the Service Control Command is associated with presence specific services, such as: allowing message-destination party to obtain presence information pertaining to message sending party, for example by including the character combination . AA (Attach Allow) in the message; or disallowing message-destination party to obtain presence information pertaining to message sending party, for example by including the character combination .AD (Attach Disallow) in the message; or

requesting notification when party identified by destination address attaches to network, for example by including the character combination .A (Attach) in the message.

A method as claimed in any preceding claim, wherein the Service Control Command is associated with location specific services, such as:

appending message-originating party's location to sent message, for example by including the character combination .M (My location) in the message; or

appending message-destination party's location to message delivery response, for example by including the character combination .DL (Deliver and Locate) in the message.

10. A method as claimed in any preceding claim, wherein the Service Control Command is associated with pre-paid specific services, such as:

checking pre-paid account balance of party indicated by destination address, for example by including the character combination .B 'PIN' (Balance PIN, e.g. syntax .B 4589) in the message; or

refilling pre-paid account of receiver indicated by destination address, for example by including the character combination .R 'Voucher number' (Refill 'Voucher number', e.g. syntax .R 15885556) in the message.

11. A method as claimed in any preceding claim, wherein the Service Control Command is associated with services concerning friends, their location and their presence, such as:

inviting the party indicated by the message destination address to join the message originating party's friend list, for example by including the character combination .1 (Invite) in the message; or

allowing the party indicated by the message destination address to receive the message originating party's location, for example by including the character combination .LA (Location Allowed) in the message; or

disallowing the party indicated by the message destination address from receiving the message originating party's location, for example by including the character combination .LD (Location Disallowed) in the message; or locating the party indicated by the message destination address without sending a text message, for example by including the character combination L (Locate) in the message; or sending a message in real-time to the party indicated by the message destination address and, if the message cannot be delivered, notifying the party originating the message and setting a request for that party to be notified when the party indicated by the message destination address attaches to the network, for example by including the character combination .R (Real time) in the message.

12. A method as claimed in any preceding claim, wherein the Service Control Command is associated with user-defined message items, such as:

appending user-defined item (e-mail address, web address, etc) to message, for example by including the character combination .U (User) in the message; or

defining user-defined item, for example by including the character combination .D 'Item' (User 'Item', e.g. syntax .D 'www.mobilearts.se' or .D 'Paul is at .M') in the message.

13. A method as claimed in any preceding claim, wherein the Service Control Command is associated with user-defined message items, such as: sending copy of the message to the message originating party's e-mail address, for example by including the character combination .C (Copy) in the message.

14. A System for end-user controlled processing and routing of messages in a mobile radio communication system, comprising:

a first server section containing a Message Handling Centre with means for:

receiving and storing rules governing message routing analyses based on the presence and content of:

parsing and analysing received messages; and

modification and routing of received messages in accordance with the result of the parsing and routing analysis to a second server section associated with the Service Control Command(s) and/or routing rules, or onwards to a message destination point

a second server section containing one or several Applications associated with and operating on Service Control Commands and/or routing rules received from the Message Handling Centre.

15. System as claimed in claim 14, characterised in that the Message Handling Centre in the first server section consists of a short message service centre, a multi-media messaging service centre or an e-mail server, with additional internal and/or external hardware/software.

16. System as claimed in claim 14, characterised in that the second server section also comprises means for (re-) routing the results of the operation(s), such as requested service information, a modified message and/or modified Service Control Command(s), to a message destination point, to the message originator point, to another Application or to the Message Handling Centre in the first server section for onward routing, the result as a part of the original message, if the whole message was routed to the Application in the first place, or separate for insertion into the message at a desired point, if only the Service Control Command itself was routed to the Application.

17. System as claimed in claim 14, characterised in that the system further comprises a third server section with means for:

storage and downloading of programs to mobile terminals for the translation of terminal-specific input data into Service Control Command(s) using mobile equipment-based execution environments such as J2ME, SAT or WAP/WTA; and

sending these commands to the Message Handling Centre in the first server section.

18. System as claimed in claim 17, characterised in that default Service Control Commands are stored in the mobile terminal repository or SIM.

19. System as claimed in any preceding claim 14 - 18, characterised in that the first, second and third server sections could be logically and/or physically co-located, or located at separate servers, exchanging data with appropriate internal or external protocols.

20. System as claimed in any preceding claim 14 -19, characterised in that it further comprises means for: performing modification of the contents of a subsequently received message delivery report in order to insert Application-derived data into a submitted message delivery or message status report for transmission of such reports to the message originating party; and/or changing the destination address or identity to modify onward routing of the message; and/or reformatting the message; and/or adding elements to the message; and/or deleting the Service Control Command(s) or message and sending a response; and/or terminating the message and sending a response; and/or interacting with other network services.

21. System as claimed in any preceding claim 14 - 20, characterised in that included server sections in combination comprises means for processing and routing service requests, messages and service responses concerning: presence specific services; and/or location specific services, and/or pre-paid specific services; and/or friends specific services, their location and their presence; and/or user-defined specific services.

22. A computer program product having a computer readable medium with computer program logic recorded thereon for use in a system for providing services based on

Service Control Commands and/or routing rules comprising means for: receiving and storing rules governing message routing analyses; and parsing and analysing received messages; and formatting, modifying and routing said data according to routing rules and parsed and analysed Service Control Commands to an Application associated with the Service Control Command(s), or onwards to a message destination point.