IES20020003A2 - A messaging system - Google Patents

Abstract

The present invention relates generally to telecommunications and in particular to the composition and sending of text messages to a mobile phone and provides a messaging system comprising a server (1) connectable to a network (6), using for example TCP/IP protocols, and adapted to receive data in a predetermined XML format, optionally SOAP, from one or more clients (2,3,4), a message processing means for translating data received by the server into one or more items of message data, each piece of message data comprising a message and an associated message address, a message delivery means, connected to one or more wireless modems (5), for delivery of the messages of the items of message data message to their associated message address (8). <Figure 1>

Description

A MESSAGING SYSTEM The present invention relates generally to telecommunications and in particular to the composition and sending of text messages to a mobile phone and provides a messaging system comprising a server (1) connectable to a network (6), using for example TCP/IP protocols, and adapted to receive data in a predetermined XML format, optionally SOAP, from one or more clients (2;3;4), a message processing means for translating data received by the server into one or more items of message data, each piece of message data comprising a message and an associated message address, a message delivery means, connected to one or more wireless modems (5), for delivery of the messages of the items of message data message to their associated message address (8).

Title IEO 2 It A MESSAGING SYSTEM .....-.....

Technical Field of the invention The present invention relates generally to telecommunications and in particular to the composition and sending of text messages to a mobile phone.

Description of Related Art The vast majority of text messages commonly referred to as SMS (short messaging service) messages, which are sent by consumers, are composed and sent using mobile phones. While this method is suitable for personal messaging between two individuals, this process of typing one message at a time to single recipients is too restrictive and inconvenient to be suitable for business use.

Text messaging is a relatively new channel of communication and presents the business community with huge opportunities for utilising the channel to conduct a wide range of business activities, including for example but not limited to, marketing, promotion, remote communication with staff and reservation/appointment confirmations. In order to facilitate these activities, businesses have looked to the information technology industry to provide solutions and in particular to provide the ability to originate text messages from a desktop PC in a flexible and easy-to-use manner which facilitates the above types of activities. The primary II ,.,..0 'I'SER SECTION 2Sit .1 23 .Λ. t ...

IE 0 2 00 0 3 type of service currently available comprises web-based applications offered by mobile network operator or an affiliate of a mobile network operator in which a web based interface is provided which enables to send text messages from a PC.

This approach is only feasible for mobile operators or affiliates of the mobile operators who have direct access to SMS infrastructure (known as an SMS centre).

While this approach enables many users to send text messages from different computers connected to the Internet, the lack of reliability, control, convenience, availability and the limitations of the web interfaces provided make them entirely unsuitable for business users. The kind of functionality that tends to be available is similar to e-mail, where users can send messages to multiple recipients, view sent messages etc. Users connect to the service using the Internet and access the web form provided to compose and send messages. However this type of service is completely unsuitable for many businesses for a variety of reasons, including for example: a) Dependability. In order to reduce costs, some business use free services however these are extremely unreliable and there is no guarantee that the service will remain available or deliver messages. This is entirely unacceptable in many business scenarios where the communication must be delivered at a certain time and the service must be available on an on-going basis. b) Connectability. Many smali-to-medium (SME) organisations do not have a permanent connection (or indeed in some case, any connection at ail) to the Internet so the costs and inconvenience of connecting to the service negate any cost benefits of using the service c) Reliability. As the service is being offered as a managed service by a third party, in many cases there is no service level agreement in place so the availability of the service is not guaranteed, even in cases where the user is a paid subscriber. In addition, the user is dependant on an available Internet connection, which regularly fails, and thus the service is unavailable.

The type of functionality available is limited by the web form interface and in general only provides the most general of messaging features. Users cannot add or extend the functionality of the service and integration with any existing systems is extremely difficult.

Lacking the complete criteria of flexibility, reliability, convenience, availability, cost efficiency and open interface, as described above, the existing methods of PC text messaging fail to meet the needs of today's business community.

Accordingly, there is a need for an improved messaging system which overcomes the problems associated with the existing systems.

Summary of the Invention These needs and others are met by the present invention, a first embodiment of which provides; a messaging system comprising: a server connectable to a network and adapted to receive data in a predetermined XML format from one or more clients, a message processing means for translating data received by the server from the clients into one or more items of message data, each piece of message data comprising a message and an associated message address, a message delivery means, connected to one or more wireless modems, for delivery of the messages of the items of message data message to their associated message address .

The delivery of the messages to their associated message address is by means of a text messaging channel, for example SMS. These channels are routinely provided by wireless telephony networks.

In a preferred embodiment, the server uses a TCP/IP protocol to communicate data on the network. Preferably, the predetermined XML format is preferably a SOAP XML protocol.

The message data may further comprise an indicator of the delivery method. The message delivery means being responsive to the indicator to determine the method of delivery of each of the messages and being adapted to deliver the message using the indicated method of delivery. The delivery methods may be conventional SMS or Flash SMS formats .

The message data may further comprise an indicator of the time for delivery, with the message delivery means being responsive to the indicator of time for delivery and being adapted to forward the message at the indicated time .

A second embodiment of the invention provides an organiser software application for operating a scheduler for at least one user, in which a plurality of events may be entered, and wherein the software may be configured to generate reminders for individual events, characterised in that: the software application is adapted to selectably generate at least one reminder for each activated event in the form of a message comprising a message body and a pre-stored wireless device number of the at least one user, and wherein the software application is further adapted to send such reminders to a wireless message server for dispatch to the wireless device of the user.

The present invention preferably uses a new web architecture called Web services and consists of a Web service, incoming text processing module, GSM modem and a number of desktop clients. The use of an industry standard communication model, SOAP, means that any application that supports XML can send text messages from within the application. As such, the owner of the service may use the service to send text messages from a PC for any purpose that they conceive, without waiting for a software vendor or service provider to add that feature to the service.

An important technical advantage of the present invention is that as the service has been developed as a Web service, the ability to send text messages may be considered to be Open meaning that any person, any application, or any IT system within an organisation has the ability to send text messages electronically using the service in any way they see fit.

In addition, as the service is Open, a business can offer the service to other businesses for a fee. To this end, the service of the present invention, optionally provides a management, reporting and service management facility to enable businesses to actually gain revenue while simultaneously cutting costs.

An additional technical advantage and cost saving of the present invention is that the time required to add text messaging to any existing application is minimal and can be developed within the native code for that application. The web services architecture is platform neutral, meaning that the ability to send text messages can be integrated in any application, regardless of the platform used by the application. The effect of this feature is that a software vendor of an application can offer this facility as an integrated part of their application in a seamless way.

Brief Description of the Drawings A more complete understanding of the method and apparatus of the present invention may be had by Ί reference to the following detailed description when taken with the accompany drawings in which: Figure 1 is a high level diagram of the typical hardware configuration of the present invention, Figure 2 represents an exemplary technical architecture diagram for the software configuration of the present invention, Figure 3 shows a screen capture of a software application adapted to work with the present invention, Figure 4 shows a screen capture of a bulk SMS client adapted for use with the present invention, and Figure 5 illustrates a flow chart of how the invention may be used to offer pre-paid SMS services.

Detailed Description of the Drawings The present invention has been developed using a new web architecture called Web services and consists of a Web service, incoming text processing module, GSM modem and a number of desktop clients. As such, the owner of the service can use the service to send text messages from a PC for any purpose that they conceive, without waiting for a software vendor or service provider to add that feature to the service.

The present invention provides a solution to the previously described problems by combining a server to facilitate a web services architecture and a mobile phone (e.g. GSM) modem to send SMS messages. The use of a GSM modem is of significance as this guarantees the availability and reliability of the service while delivering significant cost savings. The use of a Web services architecture and SOAP clients provide an unlimited degree of flexibility, convenience and an open interface, which further add to the advantages provided by the present invention.

More specifically, figure 1 is a high level diagram of an exemplary hardware configuration of a preferred embodiment of the present invention and shows a central server 1 connected to at least one wireless (e.g. GSM) modem 5, and via a network 6, using for example TCP\IP to a plurality of clients 2,3,4. The server 1 is suitably configured to receive and send data over the network 6. The server is running a suitable operating system 11, examples of which would include Windows 2000, Windows NT, Solaris, Linux or FreeBSD. The at least one GSM modem contains a standard Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM) card for which an account with a licensed mobile operator exists and is suitable for sending and receiving text messages through a mobile (wireless) telephone network 7 to and from mobile phones connected to the same and other mobile telephone networks.

To improve the reliability and speed of operation of the services provided by the present invention, the central server 1 may be provided with a plurality of wireless (GSM) modems 5, with each individual modem being assigned to separate serial ports. Suitable types of wireless modem would include the M-20 or TC-35 from Siemens of Germany, and the data card from Nokia of Finland. Using a plurality of modems, it is possible, for example, to provide SIM cards from different mobile network operator, with each modem having a SIM card for a different network operator. The use of at least one modem for each major mobile operator in the area of operation of the central· server 1 increases the reliability of the service by ensuring a greater level of network coverage. In addition, messages are delivered quicker when they remain on the same mobile network, thus providing a greater level of service. In countries where for example, there are four mobile network operators, a preferable configuration would be having four GSM modems, with each of the four modems containing a GSM SIM card for a different mobile network. Additionally, one or more modems may be configured to function as a back-up modem in the event of failure of another modem.

The exemplary clients 2,3,4, as shown in Figure 1, comprise a number of PC computers running client applications 2,3 and an application running on a server 4 distinct from the central server 1. It will be appreciated that there is no explicit limit on the number of physical clients that may use the services of the system of the present invention.

An exemplary technical architecture of the messaging system of the present invention, as illustrated in Figure 2, comprises a number of different elements including an operating system 11, a SOAP Application Programming Interface (API) 17 embodying a message processing means, and a core application which includes a message delivery means 12. The message processing means is suitably adapted to translate data received by the server into one or more items of message data. Each item of message data comprises a message and an associated message address.

The message delivery means of the core application comprises suitable program code, which is suitably written to enable receipt of the data from the SOAP interface. The message delivery means is further configured to provide a connection with the one or more wireless modems 5 of the central server 1 for delivery of the SMS messages via one or more mobile telephone networks 7 to the mobile telephones 8 identified by the associated message address (numbers) of the messages. It will be appreciated that the message processing means and message delivery means may be implemented as functions, subroutines or separate program elements.

The present invention has been developed to incorporate the features and advantages of Web services. Web services are self-describing, self-contained, modular applications that can be combined with other Web services to create products and processes. Based on open Internet standards, Web services enable developers to construct Web-based applications using any platform, object model, and programming language they desire.

The Web services applications programming interface (API) 17 provides a transparent platform-neutral, language-neutral interface between incompatible technologies. For example, a Visual Basic (VB) client may now access remotely call methods on a Java application using native VB code.

The web service of the present invention uses the Simple Object Access Protocol (SOAP) to enable invocation of the services of the central server by client applications and to communicate with clients. SOAP is a protocol specification that defines a uniform way of passing XML-encoded data. In also defines a way to IF 0 2 (J 0 0 ϊ perform remote procedure calls (RPC's) using HTTP as the underlying communication protocol. Essentially, SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. SOAP is platform and language independent and is supported in COM. This means that Microsoft applications, for example Outlook, and other custom applications can execute the methods/procedures contained on the server of the present invention. In effect, any application developed using standard technology can communicate with the server of the present invention to send SMS messages. The use of SOAP dramatically reduces the complexities of interfacing systems and facilitates users developing or modifying their own proprietary applications using the SMS services provided by the system of the present invention The server accepts SOAP (Simple Object Access Protocol) messages on a configurable TCP port number. To facilitate the sending of an SMS message, the SOAP message information (message data) comprises a message to be sent and an associated message address, i.e. phone number to be messaged.

As described previously, the system 1 may be configured to operate using a plurality of modems 5, with each modem configured to process messages for a certain network operator. For example, if a first modem contains a SIM card for a first network, the message delivery means may be adapted to ensure that messages for delivery to the first network are sent using the first modem. In operation, each modem will be assigned to a different serial (COM) port on the server. Thus to facilitate this manner of operation, a configuration file or dataset may be provided identifying which modem (or serial (COM) port) is to be used for which destinations. The configuration file may specify which number prefixes should be handled by each COM port. For example, the entry COM4=086 may identify that the modem connected to the communications port COM4 is preferably to be used for all destinations (numbers) commencing with the digits 086, i.e. the prefix of a first mobile operator. Whereas the entry COM5=087,* may signify that the communications port COM5 is preferably to be used for all destinations (numbers) commencing with the digits 087, i.e. the prefix of a second mobile operator or, by virtue of the * symbol, all prefixes not assigned to another COM port (modem). The message delivery means when sending a message may refer to the stored values in the configuration file to determine which port (and hence modem) the SMS message should be dispatched from and direct the message to correct port accordingly. It will be appreciated that incoming messages are collected on all ports since when message recipients reply to a message, these message replies are sent back to the originating modem. This arrangement using multiple modems provides for greater reliability and performance in the actual delivery of messages. With Solaris and Windows operating systems, the message delivery means may talk directly to the serial port that the modem is installed on, whereas with other operating systems, for example Linux, a hardware interface layer may be required to access the serial port.

The server of the present invention may also be adapted to accept SOAP messages containing an indication of the delivery method. Two different types of delivery methods may be supported, namely standard SMS and flash SMS. The difference between the two messages is how the resulting message is displayed on the handset of the person receiving the SMS message. A standard SMS message is stored on the phone in an inbox and usually an envelope symbol is displayed on the phone indicating that there is a message in the inbox, whereas a Flash SMS message is displayed directly on the screen. When a user sends a message, they may specify which type of SMS they wish to send. The message delivery means is responsive to the indication of delivery method received by the SOAP interface and is adapted to deliver the message using the GSM modem using the indicated delivery method. If no indication of delivery method is provided, the SOAP interface may generate an appropriate error message or alternatively the message delivery means may use a default delivery method, for example standard SMS.

A disadvantage of existing SMS systems is that existing systems are configured for immediate dispatch of a message, although the message itself may take some time to reach the intended recipient. Accordingly, the user must be present and connected at the time of creation and dispatch of the message.

To overcome this serious drawback, the present invention provides for the timed delivery of messages. To facilitate this the SOAP interface is suitable adapted to receive messages containing a time indicator, for example in the format hh:mm dd/mm/yy. Upon receipt of message data from a client containing a time indicator, the message processing means may validate that the time identified is valid. In the event that the time indicated is invalid, the SOAP response from the web service suitably indicates an error. In the event that no time indicator is received for a message, the system may use a default dispatch time, for example, as soon as possible.

To facilitate the timed delivery of messages, the message delivery means may be provided with an associated data store or database containing a list of all messages to be sent, their associated destination numbers, a time for dispatch indication and optionally a indicator for the format of message (standard or flash). Messages without a time for delivery may have their time of entry on the database entered as their delivery time. The message delivery means may interrogate the database to determine which message is ready and next in-line for dispatch. Messages may be marked as sent or deleted once the message has been dispatched through the appropriate modem.

The use of an associated database for messages also provides the advantage that in the event of a power or similar failure, the messages stored for dispatch are not irretrievably lost.

Messages that are accepted from a client for immediate delivery are put in a queue for delivery. If there is a failure, for example due to lack of network ip Π 2 <5 0 5 ϊ coverage, the message delivery means of the server may re-try sending the message for a pre-determined trial period, for example 1 minute, and in the event of continued failure cause the SOAP interface to return an error message to the SOAP client. Upon receipt of this error message, the user may attempt to re-send the message. This feature will be described in greater detail with reference to the exemplary Microsoft Outlook client described below.

For accounting purposes, the service of the present invention may maintain a complete log of all messages sent. Additionally, an Account Manager module may be provided as part of the system to enable administrators to set up user accounts with passwords and to fix a limit on the number of messages that individual users may send. The operation of the account manager will be better understood with reference to the exemplary process flow diagram of figure 5, which commences with the user purchasing credit 100 to send a fixed number of text messages. The administrator then assigns 101 a unique username and password to the user and notifies the user accordingly. At the same time, a message counter for the user is set with a credit equating to the number of credits they have purchased 102. When the user wants to send a message, they can login 103 to the system by providing their username and password. The user may then compose and send 104 as many messages as they elect. For each message that the user sends, the system reduces 105 the message counter value for the user by one.

When the user's message counter reaches 106 a predetermined warning level the system may send 107 a warning message to the user to warn them of the level of their message counter. Upon receipt of this warning message, the user may purchase additional credit 108 for sending more text messages. Any additional credit purchased causes a corresponding increase 102 in the counter value, in effect a top-up of the counter. When the message counter has been reduced to zero, the user may be prevented from sending further messages. If in these circumstances the user attempts to send a message, they may be presented with a suitable error message. The pre-determined warning level may be zero.

An exemplary client 2 uses web browser software to access a web form, for example as a hyper text mark-up language HTML document. The form provides suitable data entry fields that enable users to type in a message body and a message address. The form may also provide a button or other activation means to cause the browser software to send the entered messages to the central server for dispatch as SMS messages to a mobile telephone network 7.

Preferably each user has an account, for example as described previously with reference to figure 5. Additional features that may be provided with a web form type interface include an address book, which may be used to store frequently used contacts and a directory for storing templates of frequently sent messages.

The interface may also provide a user-visible counter, for indicating to the user how many characters of the allowed maximum characters, currently 160 for SMS messages, remain as they type the message. Optionally, a further facility may be provided to allow a user to access a report of all sent messages. A facility may also be provided to supply the user with a report/partial report of messages sent and/or received, for example as a standard Microsoft excel· file, which may be viewed and analysed. In addition, the interface may provide for the sending of messages to multiple recipients either using a comma-separated list or as a pre-stored group of numbers.

An additional feature, for example provided by a custom Microsoft Excel file, may be supplied to allow a user to concatenate an existing list of mobile numbers so that the same message may easily be sent to many recipients .

Optionally, the interface may provide time and date fields for entry by the user so that messages may be submitted to the central server for dispatch at a particular time as described previously. This feature would allow a user to create meeting/appointment reminders, which would be messaged to them by the central server at the requested time. As described previously, the web browser client uses SOAP io connect to the web service provided by the central server and sends the messages in an XML format for processing and subsequent forwarding on by the server as SMS messages.

Another exemplary client 3 embodying an organiser software application (Microsoft Outlook) is demonstrated in the exemplary Graphical User Interface 150 shown in Figure 3. This exemplary client demonstrates the flexibility provided by using the configuration described previously of the central server, and illustrates how an existing application (Microsoft Outlook) can be enhanced to add text-messaging functionality.

The exemplary Outlook client 3 operates as a plug-in developed in native Outlook code. This means that the messaging functionality is integrated seamlessly into the Outlook application. This is possible because of the arrangement and interface provided by the SOAP interface of the central server.

As illustrated in Figure 3, as a user accesses Outlook, the SMS facility 151 appears as a menu option on a number of standard menus including Actions 155, Inbox 154 and Contacts 153. The Actions menu 155 contains a Send SMS option 151. Upon selection of this option 151 by a user, the client code provides the user with a further GUI form (not shown), which preferably appears as a standard Outlook form and provides the user with access to the contact details features of Outlook including individual contacts and distribution lists. A user may select a message address (number) from these details or type in a number directly. As described previously in respect of the browser client, the interface may provide a visual counter, which informs a user how many characters of the allowed maximum message size remain as they type a message.

A further feature provided by the outlook client allows a user to enter an email address and/or a time duration. This feature will facilitate the user sending a a status report confirming message delivery and/or failure within the user specified time duration to send the messages, for example 30 minutes. It will, be appreciated that for this feature to operate, the server must be adapted to receive items of message data, which comprise a status return address and/or a time duration value.

When the user selects the Send button, the Outlook client connects to the web service provided by the server using SOAP and uploads the message data to the server. In a preferred embodiment, the server responds with an accept message and message ID for the uploaded message data. The message may then stored be stored in a Sent folder within the Outlook program with a sent status.

This status may be updated in response to an indication received from the web service provided by the server when a message is delivered or fails to be delivered within a specified time .

In addition, if a user has, as described previously, opted for e-mail notification, the server is configured to send an email to the address specified to notify the user of the status of all messages during the attempted send period. For example, if the user specified that messages should be sent within ten minutes and entered their email address for notification, and some messages cannot be delivered during this period, the user will get an email stating which messages have been sent and which have not.

Additional functionality that may be provided in the outlook client includes the facility to send messages to multiple recipients using a comma-separated list or as a pre-stored distribution list from the contacts file.

Preferably, the interface contains a time and date entry field so that messages may be submitted to the server for subsequent dispatch as SMS messages at a particular entered time, for example meeting/appointment reminders .

This feature may suitably be extended to provide an extremely useful and beneficial feature within the calendar (scheduler) section 152 of Microsoft Outlook and/or other organiser software applications. The calendar section 152 of Microsoft Outlook provides for one or more events to be entered for one or more users of the software, and for which the Outlook program may be configured to selectably generate one or more reminder for each of the individual events. The reminder feature may be activated/deactivated for individual events. Conventionally, these reminders take the form of a pop-up message and/or alarm on the computer of the user on which the organiser software is operating. This of course necessitates the user being at their computer to receive the reminder .

However, using native Outlook code, the software application may be adapted to selectably generate a message comprising a message body and a pre-stored wireless device number corresponding to the mobile number of the user in addition/in place of the previously described conventional reminder devices, where the user requests (activates) the option of using an SMS message as a reminder. The software application may readily be further adapted to send such reminders to the central server for dispatch as text messages to the wireless device of the user via a wireless telephone network, as IEO 200 0 3 described previously with reference to the operation of other clients.

Similar functionality can readily be included in other organiser programs including for example, Lotus Notes, which has the same type of functionality as Outlook. As with the Outlook example, Lotus Notes would preferably be adapted to use SOAP to connect to the central server.

The present invention also comprises a custom mail server, which interprets incoming e-mail messages, converts them into message data, and sends the converted message data to the central server for subsequent dispatch as text messages.

This may best be explained by way of an example. The user may wish to send an SMS text message to a message address (number), to achieve this using the custom mail server of the present invention, the user composes an email using a conventional e-mail package or web mail service. The user sends the e-mail to the domain (server name) of the custom mail server with the message number indicated as the recipient, i.e. using the format messagenumber@servername. For example, if the user were to send the e-mail having the following address 0897211290@b2m.somecomany.com, then the b2m.somecompany.com would correspond to the domain where the custom server resides, whereas the number 0897211290 indicates the mobile number to which the message is ultimately to be directed.

Upon receipt of such an e-mail message, the custom mail server is suitably adapted to extract the mobile number from the e-mail address in the to field of the e-mail header, e.g. by removing the domain name of the mail server from the address. The mail server also extracts the sent message from the message body. These items may then readily be included in the message format previously described.

Once these steps have been completed, the mail server may connect to the central server and forward the message using SOAP to the server for subsequent dispatch of the message as an SMS to the previously extracted mobile number. The provision of this custom mail server in combination with the previously described central server means that all email packages that support the Simple Mail Transport Protocol (SMTP) may be used to send SMS text messages .

Additional features may be added to the mail server to enhance the functionality of the server. For example the mail server may be adapted to respond to instructions contained within the subject field of the e-mail. For example, if the user included F in the subject line, this could be used to denote that the message should be delivered as a flash message. Upon receipt of the message, the mail server would respond by including a corresponding identifier in the message data for sending to the central server. Similarly, information corresponding to a desired time for dispatch may be included as an instruction within the subject field.

A mail merge client 200 may additionally be provided as part of the present invention. This runs as a Java swing client 14, downloadable from the server 1, that runs on a desktop or as a Java applet in a browser. Users can browse a suitable data file 201 comprising a series of data fields arranged in columns, for example a Microsoft Excel file in CSV format, on their desktop. Users may select which column of the file contains the destination mobile numbers. They may then compose a text message, and optionally, include data from the file by selecting and inserting field names into the interface. For example, if a file contained three columns named NAME, NUMBER, BIRTHDAY, the user would be able to select the column NUMBER as the list of recipient numbers and construct a personalised message 202 for each recipient such as Hello NAME, your birthday is BIRTHDAY as illustrated in Figure 4. The user may preview 203 the resulting merged messages individually. Once the user has finalised their message, they may click an appropriate send button. Upon which, the mail merge client creates the individual messages by combining the message text with the data appropriately inserted at the fields in the message from the data contained in the corresponding columns of the file and forwards the messages uses SOAP, as previously described for other embodiments, to the central server 1.

Using this mechanism, users may send out thousands of personalised messages using a GSM modem, from any location without needing any other connections or dependencies .

For management purposes, a Service management module is provided. This enables administrators to set details such as PIN numbers, COM ports, and text of message attachments and set security. The administrator may set up the service as unrestricted (anyone who accesses the SOAP service may send a message), or apply restrictions e.g. using account validation (i.e. requiring user log-in and password) or IP validation (i.e. where only requests from certain IP addresses are permitted).

In the case of validation, only those with valid accounts may send messages and/or messages originating within one or more specified IP ranges. The administrator may use the Service management module to temporarily suspend services, certain modems and/or SIM cards.

Heretofore, the operation server of the present invention has been described with reference to cases where the text message is outgoing, i.e. server to mobile phone, the operation of the server will now be described briefly for incoming messages. The message processing means comprises an Incoming Text module for processing incoming text messages. This is preferably a flexible, configurable, rules based engine that processes the text message and triggers actions. Actions may be include, but are not limited to, the following: a) Store and display. Messages received are stored in the database and available through a web based interface so that if messages sent using the server are replied to, an administrator may pick up the replies. Alternatively this feature may be used for polls, surveys and quizzes. b) Forward to email. The text of the message is sent as an email. So if a message is received in the format: name@server.com Some message, this may be sent as an email to the address contained in the message, i.e. name@server.com. c) Reply with information. The text of the message contains a key word that triggers an information source, which in turn provides message data, which is forwarded by the server as text message back to the sender. This may for example be used to provide a lotto results texting service, whereby if a user sends a message with the keyword lotto, the server sends back the lotto results in a text message to the user. d) Look up data source. The text of the message contains a key word that triggers a lookup in a database e.g. db sales sends back the latest sales results from the sales database. This may be achieved by triggering a different action for each keyword. This may be implemented using a simple rules file as illustrated in cable 1, containing a List of keywords and associated actions. The associated actions may for example comprise functions or programs stored on the server and suitably configured to perform specific actions.

KEYWORD ACTION lotto lotto . java db sales dblookup.java StoreandDisplay.j ava Table 1 In a preferred embodiment, the actions are provided as JAVA elements 14, which are stored on the server and which may be run by a JAVA engine 16 running on the server 1. Developers may add new rules as required, simply by adding new JAVA elements to the server 1.

Although a preferred embodiment of the method and apparatus of the present invention has been illustrated in the accompanying Drawing and described in the forgoing Detailed Description, it will be understood that the invention is not limited to the embodiment disclosed, bit is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.

Claims (6)

Claims

1. A messaging system comprising: a server connectable to a network, using for example TCP/IP protocols, and adapted to receive data in a predetermined XML format, optionally SOAP, from one or more clients, a message processing means for translating data received by the server into one or more items of message data, each piece of message data comprising a message and an associated message address, a message delivery means, connected to one or more wireless modems, for delivery of the messages of the items of message data message to their associated message address.

2. A messaging system according to claim 1, wherein the message data further comprises an indicator of the delivery method, with the message delivery means being responsive to the indicator to determine the method of delivery of each of the messages.

3. A messaging system according to claim 1 or claim 2, wherein the message data further comprises an indicator of the time for delivery, with the message delivery means being responsive to the indicator of time for delivery and being adapted to forward the message at the indicated time.

4. An organiser software application for operating a scheduler for a user, in which a plurality of evenrs may be entered, and wherein the software may be configured to generate reminders for individual IE 0 2 0 0 0 3 events, characterised in that: the software application is adapted to selectably generate at least one reminder for each event in the form of a message comprising a message body and the wireless

5. Device number of the user, and wherein the software application is further adapted to send such reminders to a message server for dispatch to the wireless device of the user.

6. 10 5. A messaging system substantially as hereinbefore described with reference to and/or as illustrated in the accompanying drawings.