WO2002098152A1

WO2002098152A1 - Applications platform

Info

Publication number: WO2002098152A1
Application number: PCT/AU2002/000702
Authority: WO
Inventors: Chris Boden; Matthew Talbot
Original assignee: Mobile Internet Group Pty Limited
Priority date: 2001-05-31
Filing date: 2002-05-31
Publication date: 2002-12-05
Also published as: WO2002098152A9; AUPR537401A0

Abstract

An applications platform (40) to provide software applications services to users (20) via mobile communications devices, the applications platform (40) comprising: an application server (42) to receive applications data from users, to allocate that data to appropriate applications (60), to process the data according to the rules of the appropriate applications (60) and to generate new applications data in response; a communications gateway (41) to communicate applications data between the application server (42) and users (20) in the form of data packages containing the following properties: user addressing information, connection specific information, application specific information and the applications data; a communications properties store to store user addressing information and connection specific information for all connections supported by the platform (40); where, the communications gateway (41) operates to deconstruct an incoming data package from a user (20) into its different data package properties and to forward the applications data to the application server (42), and then , to receive applications data from the application server (42) and use it to construct an outgoing data package to a user (20) reusing other data package properties from the deconstructed data package that are appropriate and where they are not appropriate retrieving appropriate data package properties from the communications properties store.

Description

Title

Applications Platform

Field of Invention This invention concerns an applications platform to provide software applications services and content via mobile communications devices. In another aspect, it concerns a method of providing software applications services and content.

In yet a further aspect, the invention concerns a gaming platform to provide games via mobile communications devices. In yet another aspect it concerns a method of providing the. games. In a further aspect it concerns a message used to play the games.

Background of the invention There are already over 400 million Short Message Service enabled mobile phones in the world. The market is expected to exceed 1 billion customers by the end of 2002. SMS traffic has enjoyed exponential growth and is likely to enjoy future success.

Summary of the Invention

The invention is an applications platform to provide software applications services to users via mobile communications devices, the applications platform comprising: an application server to receive applications data from users, to allocate that data to appropriate applications, to process the data according to the rules of the appropriate applications and to generate new applications data in response; a communications gateway to communicate applications data between the application server and users in the form of data packages containing the following properties: user addressing information, connection specific information, application specific information and the applications data; a communications properties store to store user addressing information and connection specific information for all connections supported by the platform; where, the communications gateway operates to deconstruct an incoming data package from a user into its different data package properties and to forward the applications data to the application server, and then, to receive applications data from the application server and use it to construct an outgoing data package to a user reusing other data package properties from the deconstructed data package that are appropriate and where they are not appropriate retrieving appropriate data package properties from the communications properties store.

The present invention advantageously mediates between different connection protocols and allows the sharing of applications across different Presentation Interfaces and network infrastructures. User addressing information may be a user MSISDN.

Connection specific information may be a network protocol including GSM, CDMA, TDMA, GPRS.

Connection specific information may be a data protocol including MMS, SMPP, HTTP, CMPP, UCP. Connection specific information may be a Presentation Interface including SMS, MMS, HTML, WAP.

Connection specific information may be a connection identifier derived from a Virtual Private Connection the data package is sent through.

Application specific information may be the type of application. Applications data may be a common data element including message content.

A rule of an application may be the condition of whether the communications gateway sends a message back to a user.

A rule of an application may be the type of message to send to a user. A rule of an application may be which user the message is to be sent to.

A rule of an application may be the type of Presentation Interface to present the message to a user.

A rule of an application may be the language the message is to be presented in. A rule of an application may be the type of carrier connection to be used by the communications gateway to send the message to a user.

The application may be a game for mobile communications devices.

The application may be a dating application for mobile communications devices. The data package may be a message. The applications platform may provide content via mobile communications devices for users. This allows content to be communicated over multiple carrier regardless of the type of protocols implemented by each individual carriers. This provides the same application or content through multiple Presentation Interfaces and multiple languages and character sets. This allows users from different countries which may use different Presentation Interfaces to communicate the same application or content.

The communications gateway may comprise a plurality of connectors to connect to a plurality of communication networks. This provides scalability to the platform where if additional protocols or carriers are needed, a new connector can be added.

The applications platform may provide an application programming interface to allow third parties to distribute their content. This allows third party developers to leverage from the platform. The applications platform may provide a software development kit to allow third parties to create applications to run on the platform. This allows third party developers to leverage from the platform.

The applications platform may provide an administration module to allow remote management, configuration and monitoring of the platform. This allows efficient administration and maintenance of the platform.

The applications platform may provide a customer relationship management module to allow third parties to access usage data and profiling information. This enables third parties to track and monitor the effectiveness of their marketing. In another aspect, the invention is a method of providing applications via mobile communications devices for users, comprising the steps of: providing an application server to receive applications data from users, to allocate that data to appropriate applications, to process the data according to the rules of the appropriate applications and to generate new applications data in response; communicating applications data between the application server and users in the form of data packages containing the following properties: user addressing information, connection specific information, application specific information and the applications data; storing user addressing information and connection specific information for all connections supported by the platform; deconstructing an incoming data package from a user into its different data package properties and forwarding the applications data to the application server, and then, receiving applications data from the application server and using it to construct an outgoing data package to a user reusing other data package properties from the deconstructed data package that are appropriate and where they are not appropriate retrieving appropriate data package properties from the stored user addressing information and connection specific information.

In a further aspect, the invention concerns a data package that is communicated from a mobile communications device to an applications platform to interact with an application, where the data package contains user addressing information, connection specific information, application specific information and applications data.

It is an advantage of at least one embodiment of the present invention to facilitate interactions between end users regardless of which carrier they belong and the wireless protocols used.

In another aspect, the invention is a gaming platform to provide games via mobile communications devices for users to play, the gaming platform, comprising: an application server to receive game input messages from users, to allocate that data to a game application, to process the data according to the rules of the game application and to generate game output messages in response; a communications gateway to communicate messages between the application server and users containing the following properties: a user identifier, connection specific information and a game input, a communications properties store to store the user identifiers and connection specific information for all connections supported by the platform; where, the communications gateway operates to deconstruct an incoming message from a user into its different message properties and to forward the game input to the application server, and then, to receive game output from the application server and use it to construct an outgoing message to a user reusing other message properties from the deconstructed message that are appropriate and where they are not appropriate retrieving appropriate message properties from the communications properties store. A single user may play a game session with the gaming platform in which case all the messages are transmitted back and forth with that user. Alternatively, several users may be involved, in which case the rules of the game may determine the order in which the users are sent messages, and the order in which messages from users are accepted. In another situation an artificial other player, created and controlled by the game engine layer may participate in a game with one or more users.

The game engine may provide an artificial moderator for a user to interact with. The gaming platform may have a message library to store messages for each moderator. The messages may indicate personalities of the moderators, such as being whimsical or capricious, and the rules of the games may allow moderators to act outside the scope of the rules for the players in order to affect the outcome of games or players scores in an unpredictable way. By connecting to multiple carriers from the same ASP platform, the system creates a virtual Internet link between these carriers, allowing end users to play against each other across carriers. This allows an unprecedented level of interaction between carrier end users, potentially allowing people in different countries to play against each other. The platform may support Short Message Service, Wireless Application

Protocol via General Packet Radio Service. This includes the ability to manage drop-outs, where a WAP session may end and be resumed via an SMS session. _ύ

The platform may provide connectivity for 3G, iTV, packet video and Bluetooth enabled mobile devices. This provides a complete end to end solution for the delivery and management of convergent applications.

A registration module may be provided for intelligent registration of new users and to provide user driven preferences within a gaming environment. The module may provide that user aliases across different services be mapped to a single unique identifier, to remove the need for re-registration and to provide a level of transparency for the user. The module may further provide intelligent scheduling, such that user-driven preferences determine each user's availability for multiplayer game invitations.

The platform may adhere to business rules that allow an Application Service Provider architecture to be multichannel and multicarrier enabled. These business rules may comprise of system rules, connection rules, registration rules and moderator rules which encapsulate the business logic behind gaming on this platform.

In another aspect the invention is a method of playing games via mobile communications devices, comprising the steps of: providing a game engine containing rules for games which are operable to provide game sessions to users in which game input messages are received from users and processed according to the rules to produce game output messages for transmission to users; and processing messages communicated between mobile communications devices and the game engine, where the messages from the game engine, when a game is in- session, are processed to contain a user identifier and a game output for display on the user's mobile communications device, and where the game output invites the user to select one of a number of valid game inputs, and where messages from the communications devices, when a game is in session, contain a user identifier and a game input, and the message is processed to use the user identifier to identify a current session of the game and then passes the game input to the game engine.

In a further aspect the invention concerns a message that is communicated from a mobile communications device to a game platform to play a game, where the message contains a unique user identifier and a game input. It may also contain a unique game platform identifier, a timestamp or a game code.

In a still further aspect the invention is a game played by at least one real player via a mobile communications device which sends messages containing a gaming input, representing that players turn in the game, to a gaming engine and which receives messages from the gaming engine containing a gaming output, representing the outcome of that round of the game.

Brief description of the drawings An example of the invention will now be described with reference to the accompanying drawings, in which:

Figure 1 is a block diagram of the platform.

Figure 2 is a block diagram of the platform illustrating mediation between network and data protocols. Figure 3 is a block diagram of the platform illustrating mediation between

Presentation Interfaces. Figure 4 is a software architectural diagram of the Communications Gateway.

Figure 5 is a software architectural diagram of the Mobile Application Server. Figure 6 is a block diagram of an embodiment of the present invention involving a gaming application.

Figure 7 is a process flow chart of a carrier intelligence module shown in Figure 6.

Figure 8 is a process flow chart of a session intelligence module shown in Figure 6.

Figure 9 is a process flow chart of a service intelligence module shown in Figure 6.

Figure 10 is a process flow chart of a user intelligence module shown in Figure 6. Figure 11 is a process flow chart of a game intelligence module shown in

Figure 6.

Figure 12 is a process flow chart of a registration module shown in Figure 6.

Detailed Description of the Drawings

The applications platform 40 has a Communications Gateway 41 and Mobile Application Server 42. The Communications Gateway 41 provides the communications link between the platform 40 and mobile operators 30 in the carrier environment 11. The Communications Gateway 41 comprises a number of connectors 50 which connect the platform 40 to the network infrastructure of the mobile operators to allow the sending and receiving of data from end users, for example, in the form of SMS messages, MMS messages, WAP push messages, WAP pages and HTTP requests. This allows connections to a wide variety of mobile operator network infrastructures over many different connection protocols. For example, using SMS, the mobile operators' infrastructure is responsible for sending and receiving SMS messages to and from end users through SMSC/SMS 31 gateways which use SMPP, the most widely accepted protocol. Other protocols that are used include CMPP, UCP, HTTP and a number of proprietary protocols. Connections between the platform 40 and mobile operator network 30 takes place over the Internet, using point to point or VPN (Virtual Private Network) connections. The SMSC or MMSC in the carrier environment 11 together with VPN can generally be referred to as the integration environment 12. The purpose of the integration environment 12 is to facilitate communications between the mobile operators 30 and the platform 40 and allows for multi-carrier operation. The Communications Gateway 41 is multi-threaded, meaning that any number of copies of the Gateway software can be running on any number of servers at the same time. Transaction controls ensure that the same data is processed only once regardless of the number of Gateway instances running. This means that scalability is limited only by the amount of hardware and processing power available to the platform. As new carriers and Service Providers 30 are added to the network and the demand for increased throughput grows, further hardware components can be added, to run additional instances of the Communications Gateway 41.

The ability to have multiple instances of the Communications Gateway 41 running on multiple hardware components allows for the balancing of data processing loads between these components. This means that if a hardware component fails for any reason and its instance of the Communications Gateway 41 becomes unavailable, the instances running on other hardware components can assume its load and process it without being affected. The Communications Gateway 41 mediates between all of the different connection protocols by separating the incoming data into its constituent components and passing the relevant data to the Mobile Application Server 42 where it is processed according to specific rules or business logic. Mediation allows for the sharing of common applications across multiple disparate carrier networks regardless of which network or data protocols are used. For example, the sharing of common applications between a CDMA network and GSM network can occur. An example of an application is a person-to-person SMS dating application accessible across multiple countries. This dating application allows users from multiple different carriers to find a suitable partner. Between these carriers, multiple different data protocols are used (SMPP, UCP, HTTPs and XML over HTTP).

Referring to Figure 2, in this example, the Communications Gateway 41 is connected to the SMSC 31 of two mobile operators, A and B, both supporting SMS messaging, Operator A differs from Operator B as outlined in the table below:

The Communications Gateway 41 mediates between mobile operators A and B by abstracting the message/data into its constituent parts to ascertain the lowest common denominator. In this case, the common components are the message text and the user's MSISDN. This data is then passed through to the Mobile Application Server 42 where it is processed by the dating application, resulting in a response message being passed back to the Communications Gateway 41 for sending back to the end user.

Through this mediation process, the platform enables a common application to be shared between two mobile operators with differing network and infrastructure environments. The number of mobile operators that the Communications Gateway 41 can provide mediation to is unlimited, as long as there are data elements that are common between them.

In the gaming embodiment of the present invention where a game called M-Trivia is played, Operator A differs from Operator B as outlined in the table below:

A player on Operator A sends a message containing "MT PLAY" to operator A's SMSC through the GSM Network and is sent through the VPN 121 to the Communications Gateway 41 as a data package using the SMPP data protocol.

The player on Operator B also sends a message containing "MT PLAY" which is passed to the Communications Gateway 41 as a data package using the UCP protocol. The Communications Gateway 41 unpacks the data package and decodes it to ascertain the core components, namely the User MSISDN, System MSISDN, message text and timestamp.

For the player on Operator A, this process is performed by the SMPP connector 51 which uses the rules of the protocol specification to decode the data package. These data components are common to the data package received, decoded and unpacked by the UCP connector. Two additional data components are derived for both players from the VPN 121 (or IP Connection / pipe) through which the data package has arrived, that is, the GSP ID and the Presentation Interface. These common data components are extracted or derived and passed to the MO message thread 75 that inserts the common components into a database table 43 for processing by the Mobile Application Server 42.

Similarly, once the data is processed by the Mobile Application Server 42, the resulting outgoing message (or data package) is inserted into the same database table 43 where it is "picked up" by the appropriate connector 50 to be sent to the end user 20 through the operator's SMSC 31 (MMSC 34, WAP Gateway 32, etc).

Referring to Figure 3, the Communications Gateway 41 mediates between Presentation Interfaces to allow for a common application to be accessed through multiple Presentation Interfaces. In this example, the Communications Gateway 41 is connected to the MMSC (Multimedia Messaging Service Center) of Operator A and the SMSC of Operator B. Operator A differs from Operator B as outlined in the table below:

In this example, the Communications Gateway 41 uses its MMS connector 301 to receive the incoming data and passes the appropriate components to the Mobile Application Server 42 where it is processed by the dating application. The Mobile Application Server 42 processes this data and the responding data is passed back to the Communications Gateway 41 with the corresponding content and Presentation Interface (MMS and SMS respectively) 61. i By establishing a lowest common denominator between the incoming data protocols, the platform is able to present a common application through multiple Presentation Interfaces. Using the same example, the end users 20 which access this application can interact with each other despite the fact that their mobile devices may support different Presentation Interfaces. This approach to serving applications allows mobile operators to migrate end users from one Presentation Interface to another without losing the critical mass of users that have access to the most basic Presentation Interface, in this case, SMS. In the gaming embodiment of the present invention, a player can have a WAP enabled mobile phone and play against another player whose phone only supports SMS. Referring to Figure 5, the Mobile Application Server 42 processes the data received from the Communications Gateway 41 according to a set of rules or business logic. These rules specify: • Whether data is passed back to the Communications Gateway 41 to be sent back to end-users.

• What data is passed back and to whom it should be sent

• Which Presentation Interface is to be used to present the data (SMS, WAP, MMS, etc)

• Which language the data should be presented in

• Which carrier connection should be used by the Communications Gateway 41 to send the data

The Mobile Application Server 42 is responsible for storing and retrieving data from the database 43, including User Data and Application Persistence. In an example where the Communications Gateway 41 is connected to the SMSC 31 of two mobile operators, A and B, which both support SMS messaging and use the same network and data protocols, there are differences as outlined in the table below:

In this example, the Mobile Application Server 42 is providing the mediation function, calling the appropriate content 61 when serving the return data back to the Communications Gateway 41. This is handled through the use of content templates 70. That is, when the data is passed through from the Communications Gateway 41 , the application 60 identifies that the mobile operator from which the data has originated, supports Chinese content. The application 60 then inserts the appropriate Chinese content 71 into the SMS Templates 70 for serving back to the Communications Gateway 41. Similarly, Operator A supports English content causing the application to insert the English content 72 into the SMS Templates 70 and serve it to the Communications Gateway 41 which in turn passes the data back to Operator As SMSC.

This approach to serving applications allows for the sharing of common applications between mobile operators who may support different languages and character sets. Using the example above, it allows end users to interact with each other through a common application such as a role-playing soccer game 60. Operator A's end users 20 are presented with content such as options to "shoot" or "save" while the corresponding content is provided to Operator B's end users in Chinese 71. The resulting inputs from the respective users is then processed by the Mobile Application Server 42 using the common application logic. The outcomes are presented to both end users in the appropriate language, for example, Chinese 71 or English 72. By providing content in English, Mandarin, Cantonese and Thai, it allows end users to interact with each other through the same application regardless of their language.

In an embodiment of the present invention involving game applications, a gaming platform 40 compπses the Communications Gateway 41 and Mobile Application Server 42 in an ASP environment 13. The gaming application exists in the Mobile Application Server 42 and determines which Presentation Interface is to be used. The Communications Gateway 41 provides a carrier intelligence module 140 and the Mobile Application Server 42 provides a session intelligence module 141 , service intelligence module 142, user intelligence module 143 and game intelligence module 144. These modules are part of the message processing layer 133 which parse and pass incoming SMS messages to allow game play to occur. For different applications, modules with similar functionality to parse and pass incoming data can be used. Module design may vary according to the type of application without departing from the scope of the present invention.

Referring to Figures 3 and 4, each connection to a Mobile Operator or Service Provider 30 is implemented in a separate connector 50. Each connector 50 is executed as a distinct process to send and receive messages from the Service Provider 30. For each Service Provider 30 there can be multiple connectors 50, one for each Presentation Interface (PI). For example, a single Service Provider can have connectors loaded for the SMS Presentation Interface and a MMS PI in the same Communications Gateway 41.

Although connectors implement a variety of protocols, the function they carry out is similar. Each connector is responsible for sending and receiving messages. Even in different Presentation Interfaces such as SMS and MMS, the basic function of the connector is the same, despite having a different over the wire protocol and Presentation Interface. Taking an object oriented design approach, a connector can be programmed with methods using a series of a simple functions, to take care of sending messages, receiving messages, starting and stopping a connector, and various monitoring functions.

Many of the connections to the Service Providers use the Short Message Peer to Peer (SMPP) protocol. This protocol is well-known for sending short messages. The platform 40 has a connector for SMPP and by loading different configuration information; the same connector is used to establish connections to many different Service Providers. That is, the same SMPP connector is loaded for carriers such as Vodafone and Optus, but loads with different attributes depending on the carrier.

Connectors are autonomous blocks of code, that is, they look after themselves. Even the startup code executes in a separate thread. Each connector must support the Init API. This API copies the variables it needs into its own local storage and then spawn a main thread that completes any initialisation that might block the sending and receiving of messages. Sending and receiving messages are often down in additional threads inside the connector, with the main thread remaining active purely to monitor the state of the connection. If any connector fails it is designed to never block and hold up the processing in another connector. This is to avoid deadlock. The connectors are frictionless with respect to the main gateway code.

All connectors, particularly TCP/IP connectors, encounter disconnection at some stage, and are able to implement a reconnect strategy. Although the Internet is relatively stable, on average, Service Providers are less predictable. Each connector's reconnect strategy depends on the type of protocol it implements. Once the connection is down, the connector does several things. Firstly, subsequent messages that are being added to its queue are failed immediately with an appropriate exception. This avoids the internal list of unsent messages inside the connector growing prohibitively large. Secondly, the connector raises a connection event into the event log and attempt a reconnect. Whilst reconnecting, the sender thread within the connector cannot be active.

The connector is also able to close down cleanly. That is, when the connector gets a 'close down' request from the Communications Gateway 41 it immediately stops sending messages, and blocks until the main thread inside the connector has exited. The connector also ensures that any messages in the connector's internal queue that have not been sent, are updated in the database 43 as being 'not sent'. Once the Sender Thread 74 has added a message to a connector 50, it is assumed to have been sent.

Some protocols require a two-step sending process. Firstly the message is submitted to the SMSC. At this stage, the SMSC has the message in its internal queues and is attempts to send it. The connector keeps the message in its internal list, flagged as sent but not acknowledged. At some point in the future, usually ranging in seconds to minutes, the SMSC responds with an acknowledgment (ACK) or a negative acknowledgment (NACK). If the response is a NACK, the connector 50 can decide to reset the message status in the database 43 to cause it to be re-sent

The connector 50 records an entry in the event log when the SMSC responds with a NACK. Often a NACK from the SMSC is due to an error at the SMSC or the handling of the message content. Message content handling problems can be due to a character-encoding problem, an error at the SMSC or an invalid destination address. An administration module 45 is then responsible for assessing the severity of the event that has been logged and raises an alarm where appropriate.

Most SMSC's expect the message content to be delivered in GSM 7Bit character set. The database 43 of the platform stores data in UCS-2. Connectors are responsible for ensuring messages are sent with the correct character set. The byte stream sent to the SMSC needs to be specifically encoded to the required character set before writing the data to the wire. Failure to do so indicates that some characters will not be delivered or mapped correctly. Messages received from the SMSC need to be decoded from the inbound encoding, for example, GSM 7bit, to be saved into the database 43.

Any unexpected failures in the connector are recorded in the event log. Connection based events such as connection down, connection back up are also recorded, to allow the administration module's 45 monitoring tools to determine the current state of the connection. Connection events are not be placed into the event log as Alarm severity events. The Administration module 45 examines all of the connection events in the event log and only alarms if a connection stays down for more than three minutes. This avoids spurious alarms being raised because of glitches in a connection that might last only seconds or minutes. Failure in any one connector 50 does not affect another connector's ability to process messages. Referring to Figure 4, in a typical scenario, the Communications Gateway 41 starts and loads a startup class SMSStartServlet 70 which is defined in the web.xml configuration file. Several Java system properties are defined when the servlet engine 70 is started. These system properties are:

When the startup class SMSStartServlet 70 loads, it initialises the main gateway class SMSManager 72. The SMSManager 72 then searches the database 43 and loads all the Service Providers and their properties. Once these are loaded, the SMSManager starts iterating over this list looking for connectors that are marked with a default. server property matching the System Property server. id that the servlet engine was initialised with. Those connectors that match are then loaded and initialised with the Service Provider configuration information from the database 43. Since each connector can use different initialisation information, the configuration information is passed in as a bundle of properties. The Communications Gateway 41 starts several threads 71 during initialisation. These threads are the Sender Thread 74, Redundancy Thread 73 and the MO message Thread 75.

The Sender Thread 74 starts after all the connectors have been initialised, that is, after each connector's lnit() method has been called. The Sender Thread 74 then fetches a block of outgoing messages for the Service Providers whose connectors are loaded in the Communications Gateway 41. For each message, the Sender Thread 74: • Locks the message in the database 43. • Looks up a table for the connector, which matches the Service Provider and Presentation Interface for the current message.

• Passes the message to the connector

• Updates the database 43 flagging the message as sent This sending strategy is optimistic and reduces the number of calls made to the database 43, thus reducing database load. For example, once the message is sent to a connector, it is assumed that is has been sent successfully. The connector 50 can internally fail to send the message, but in the majority of cases succeeds. When the connector fails to send the message, it typically calls a SendMessage API to reset the Sent Status on the message to "not sent" in the database 43. Using this method, the majority of messages only need a single database call - fetch and update - to mark them as sent, rather than two updates, one as "being sent" and the next as "really sent". To work efficiently, each connector's SendMessage API is asynchronous. That is, it must never block or be in a state where it prevents the processing of other messages. Typically, this is implemented by placing the message into the connector's internal list and returning immediately.

The Redundancy Thread 73 provides the failover between separate Communications Gateways 41. Failover is the process by which the services that were running a now-failed server migrate to a functional server and resume serving their clients. At least two Communications Gateways 41 are run, each on a different machine where each Gateway starts a Redundancy Thread 73. Every three minutes the redundancy thread wakes up and checks the state of all the connectors. For each connector that a first Gateway has loaded, the Redundancy

Thread 73 updates a timestamp in the provider table in the database 43 with the system date. For all other connectors which are assumed to have been loaded in a second Gateway, the Redundancy Thread 73 checks the timestamp to see when it was last updated. If the difference between the current time and this timestamp falls outside a pre-determined allowable range, the first Gateway brings up each of those connectors that the second Gateway should have loaded. This occurs when the second Gateway is stopped for a length of time on the computer running the second Gateway or when the computer running the second Gateway fails or crashes. When a connector 50 fails, an alarm is generated into the system log. The MO message thread 75 asynchronously saves messages to the database 43. This reduces the time to process an inbound message in the connector from the message unpacking time (1-5 milliseconds) plus the time to insert the message into the database (10-20 milliseconds) to just the time required unpack the message. The MO Message thread 75 also decreases the number of objects created during the processing of an inbound message, and potentially, a single prepared statement can be used to insert multiple messages.

The Communications Gateway 41 also contains several API entry points or servlets that can be used for reporting and configuration. These servlets use Apache Tomcat's servlet container 70 as a simple mechanism to communicate with the running Communications Gateway 41.

Utility servlets 71 in the Communications Gateway 41 can be used to carry out: • Sending test messages on a connector. Messages can be dropped directly into the connector, bypassing the database, to test message delivery over the connector.

• Reloading / reinitialising a connector. If the properties (IP address/ port/ keyword) change, the connectorManager servlet 72 can be used to close the connector, reload properties from the database and reconnect to the target server without restarting the Communications Gateway 41.

• Resetting the Communications Gateway 41 to its default connectors. If the connectors failover to another Communications Gateway 41 , then this API resets the Gateway to its default set of connectors 50 if it has picked up connectors other than its own.

• Gracefully closing the Communications Gateway 41 down. Its important that all the connectors are closed gracefully. Each connector can contain messages that have not been sent, but are currently flagged as sent in the database. The closed connector resets the status of the un-sent messages in the database, reflecting the true state of the message.

The Administration Module 45 is a secure web site allows the system state to be monitored, traffic viewed and servers restarted. It includes a suite of web-based tools used for monitoring:

• VPN Connections SMSC / SMS Gateway Connections Message Round-Tripping Hardware Performance Software Performance Load A web-based Administration Module 45 allows for the remote management, configuration and monitoring of the platform. It includes: Access to event logging information

Interface to manage alarming (configuration, filtering, rules, etc) • Interface to manage the build and release process

Interface for monitoring real-time data flows Interface for interrogating log files Interface for managing content in real time

Client provisioning interface (assign applications, reports access, edit client properties)

A web-based Customer Relationship Management (CRM) tool 44 allows clients and platform partners to access usage data and profiling information. It provides access to data traffic reports which have been broken down according to application. This enables clients and commercial partners to measure and monitor the performance of individual services. The profiling tool uses data which is gathered from users as they access the applications and provides a consolidated picture of who they are and how they use the applications.

The platform has an open API 46 to allow third parties to use the

Communications Gateway 41 and carrier network for the distribution of their content. Based on open standards, the interface consists of a bi-directional

XML data flow over the Internet via a HTTP connection between third parties and the platform 40.

The platform 40 also provides a downloadable SDK 47 allowing third party developers to create applications that run on the platform 40. The SDK provides an emulator, a graphical user interface which simulates the behaviour of the platform and allows end to end testing and debugging of applications. Once developed these can easily be ported across to the hosted environment to be run on the platform 40.

Connections between the platform 40 and mobile operator network 30 takes place over the Internet, using point to point or VPN (Virtual Private

Network) connections. A number of tools have been developed specifically to handle the reliability issues relating to data communication over the Internet. These tools ensure that data is not lost when connections between the platform 40 and the mobile operator network 30 drop for any reason. These tools include:

Connection failure management (reconnect process and alarming) SNMP Traps Alarms

Exception logging Delivery and receipt notification • Transaction control

The system has an event log, into which is generated various error and information events. For example when a connection to a carrier) drops, an event is generated with a severity level resulting in an "alarm". These alarms take the form of SMS alerts (sent from an independent GSM modem) or email being generated and sent to the appropriate support team for action. In certain cases, mobile operators are provided with an interface for receiving SNMP traps for proactive monitoring of events that relate to their applications and the connection from the platform to their network infrastructure.

In addition to gaming applications, the platform also offers other interactive SMS applications including: SMS chat SMS Pop email SMS Polling SMS Alerts • SMS Information on demand

Ringtones, Logos and Picture Messages SMS to voice services

MMS, WAP and Java 2 MicroEdition (J2ME) games. Software components or reusable engines are provided by the platform that can be used by third parties to extend their content or brands to wireless forme ts like SMS or WAP.

One of the embodiments of the invention provides major television stations with access to trivia engines and polling applications to create wireless interactivity with television viewers. A further embodiment of the invention concerns advertising and marketing agencies who use the SDK to develop their own applications on behalf of their clients.

In the case of third party applications, there is provided a global application developer program supported by regional mobile carriers for the deployment, delivery and distribution of third party applications via the platform. Developers which download the SDK and supporting documentation are allowed to create applications that run on the platform. The SDK consists of a test harness, a graphical user interface which simulates the behaviour of the platform and allows end to end testing and debugging of applications. Applications developed using the SDK are easily ported across to the hosted environment and can run on the platform.

In the case of third party developers, there is provided an interface to the Communications Gateway 41 so that the developers can leverage off the distribution network by connecting remotely over the Internet. Developers can maintain their own applications within their own hosted environments and use the Communications Gateway 41 and the connectivity to carriers as a conduit for their content and applications.

An embodiment of the present invention involving a gaming application is generally described with reference to Figures 6 to 12. Referring to Figure 6, a gaming environment 10 has a carrier environment 11 in which a user 20 uses their handset or mobile communications device to receive incoming messages or to transmit outgoing messages via a telecommunications network carrier 30.

The integration environment 12 includes the carrier's short message service center (SMSC) 31 and a virtual private network (VPN) 121 to facilitate communications between the carrier 30 and an Application Service Provider

(ASP) environment 13.

The Application Service Provider (ASP) environment 13 is where the game platform 40 exists. The game platform 40 comprises four layers: an interface layer 132, a message processing layer 133, a game engine layer 134 and a database layer 43.

The interface layer 132 of the ASP environment 13 includes a virtual private network (VPN) 121 for each carrier it is connected to. This allows for multi-carrier operation. Users access the game platform by dialling and sending an SMS message to a system mobile subscriber ISDN (system MSISDN) which is uniquely associated with a games service provider.

Messages sent from a user 20 to a game platform 40 in the ASP environment 13 contain the following variables:

As a message is transmitted from a user it passes through the carrier's VPN 121 to the platform 40 using a loadable connector module 50. These connectors 50 have been described earlier in the description.

The message processing layer 133 is responsible for parsing and passing incoming SMS messages through at least some of five intelligence modules: a carrier intelligence module 140, a session intelligence module 141 , a service intelligence module 142, a user intelligence module 143 and a game intelligence module 144; as shown in Figure 7.

The carrier intelligence module 140 interprets an incoming message (or transmits an outgoing message) and identifies the originating carrier from the message. In the example, the carrier intelligence module 140 identifies the three different carriers Vodafone, Smart or Optus as the originating carrier of the respective incoming messages 150, 151 and 152, and sets a carrier ID accordingly. The carrier ID can be derived from the URL, IP address or gateway connector ID from which a message is sent. Alternatively, the connector used for the carrier can identify the originating carrier.

Referring to Figure 8, the session intelligence module 141 determines if an incoming message belongs to an existing session of a game or is a signal to initiate a new session. The module initiates a session lookup 160 after the carrier intelligence module has executed based on the user MSISDN number in the incoming message. The user MSISDN number is in the form of 6141629347, 61 being the country code of Australia. A session lookup involves searching the user MSISDN in the ID column of a Current_Games table in a database of the database layer 43. If the user MSISDN exists, the session ID is set to true 161 , otherwise it is set to false 162. If the session ID is true, the remaining modules: Service 142, User 143 and Game intelligence 144 are bypassed and game play resumes. Resumption of game play involves the incoming message from the user to provide a game input to the game engine layer 134 so that the appropriate response can be generated using the rules for that game. The response message includes a game output and passes back to the carrier intelligence layer 140 for transmission to the appropriate user. This may involve a transmission to the originator of the incoming message, for instance when they are playing a solo game. Alternatively, the message is- sent to the next player, when several players are involved in the same game. Or messages may be sent to several players.

The game engine layer 134 provides two functions: the game logic and a moderator . A moderator such as Mr. Big is an artificial character with personality traits reflected in the messages that it sends. Moderators can be assigned to particular games, or available throughout the ASP environment 13. Moderator personalities may be mixed with system generated messages and attached to different levels of hierarchy such as the top level for the entire ASP environment, the service provider level such as Vodafone or at the game level such as Russian Roulette.

A message library is provided with the platform and has a compilation of system generated message categories to suit different events. Each moderator has a series of messages to reflect their personality. Categories are not restrictive and new ones may be added allowing access for more than one moderator . For a gaming event that calls on a message category, an outgoing message will be selected at random from that category. For example:

Game logic processes game messages as they are passed to the game modules. Game logic includes the rules of the games and probabilities of winning and losing them. The resulting game state determines the category of responding messages from which one of the messages in that category will be chosen at random. The game engine will then send the chosen message to the player in the name of the allocated moderator of the game.

The database layer 43 supports the game engine by storing all the player detail, carrier detail; game service provider details, service details, game details, moderator response messages and all the game transaction states details. Relationships between these data are also stored and maintained by the database. User privacy and security are protected by firewalls and encryption mechanisms within and around the platform environment.

Referring to Figure 9, when the user is out of session, that is when the session ID is set to false, the service intelligence module 142 is initiated to determine what service is being requested by conducting a system MSISDN lookup 165. A system MSISDN number is also transmitted with every incoming message and refers to a unique identifier to discover which service is being requested by a user. A system MSISDN lookup involves searching the system MSISDN in the ID column of the Services table. When there is a match, a service ID is set to a particular service, for example Vfone_games 166.

Referring to Figure 10, the user intelligence module 143 determines if the user is registered with a GSP and is initiated following completion of the service intelligence module. A user MSISDN lookup 167 is conducted where the user MSISDN refers to a unique identifier to discover registered users for the identified service discovered by the service intelligence module. A user MSISDN lookup involves searching the user's MSISDN in the ID column of the Vfone_Users table. T a table to search on varies, depending on the service discovered by the service intelligence module. If the user is not discovered in the table 168, a registration module 170 is initiated to register the user, otherwise the game intelligence module 144 is initiated and the player ID is set to the user MSISDN. .

Referring to Figure 11 , the game intelligence module 144 determines which game within a service is being requested by a user. The module parses the game code from an incoming message and attempts to match it to the game codes for the service. For Vodafone, the game codes include HP - Hot Potato, RR - Russian Roulette, SP - Splat, M - M-Trivia, BD - Brain Drain and H for Help. If the command code matches a game code, game play can commence 176 and the game ID is set to the command code. Otherwise, the system returns a message to the user stating that the message text is not recognised and a games menu module 177 is initiated to provide a list of available options to the user.

Referring to Figure 12, a registration module 180 is initiated when a recognised user is not discovered in a users table for a particular service. In other words, the user MSISDN number is not found 181. Creation of a new recognised user 182 involves the user requesting a nickname 183, and the name is then validated 184, provided it is available. If it is not available, the user is prompted to choose another nickname.

Users are identified by the nickname they choose at registration. Users can register with more than one Games Service provided by an ASP. Each unique user MSISDN is mapped to a unique nickname which is used throughout the platform. This allows game play over different carriers. But there may be instances where a GSP will require their own unique nicknames for games within their games service. These GSPs would be precluded from sharing a game with another ASP.

The registration module also allows the user to set their own preferences regarding game play and scheduling.

The platform also checks the user's mobile phone number against the player database for all service providers. If the number already exists, a message notifies them that they are already registered. Once a user is registered, the platform informs the GSP of the new registration. Terms and conditions of use are messaged to the user and user-defined preferences can be set from this moment.

The platform also remembers what game the user was attempting to initiate so that play can resume after the user has registered.

Alternatively, a user can send a registration SMS to a dedicated number. The SMS contains a code that is recognised as a registration code for that carrier or GSP. The format of a registration SMS is: Registration Code <space> Nickname, for example REG Nicole.

Help messages are consistent across all ASPs. The help system is interactive, allowing the user to enter help commands and responding with the appropriate message. Recent gaming history and recent history time period are also available as contextual functions for the help system. Business Rules

The platform uses an ASP architecture and follows business rules comprising of system rules, connection rules, registration rules and moderator rules.

Some of the system rules include that users are grouped into service groups by registering to an ASP NODE that provides one or more game services; each service group is serviced by one game service; each user must be a valid mobile end user with a carrier, each user must have a valid and unique user MSISDN allocated by the carrier; each game service must be owned by one ASP NODE; each game service must host one or more games on one node; a game can be hosted by one or more game services within a node; the system MSISDN is the number that the users send their gaming SMS messages to; the system MSISDN uniquely identifies the game service that the user is interacting with; a node can have many game services; a game service provider can have one or more game services per node.

Some of the connection rules include that each game service must have one or more carriers per node; a game service can have more than one connection with one carrier within a node; a carrier can connect to or service many game services on one or many nodes; each connection between a game service and its carrier can have an IP address allocated to it by the carrier and the Internet Service Provider (ISP); system MSISDN are allocated to each connection by the carrier that is unique across the carriers MSISDN range.

Some of the registration rules include that a user must choose a nickname if the user MSISDN does not exist in the service group of the node; nicknames must be unique within a node across all service groups that are on this node; some ASPs may choose to have their own isolated service and their own group of unique nicknames; a user can be in more than one service group.

Some of the moderator rules include that the moderator for a distinct ASP can have exactly one personality; personalities are reflected by the set of responding messages that are given to the moderators; the responding messages are categorised; the responding messages are drawn from the categories according to the context of the gaming message and are drawn at random; each game in a node must have exactly one moderator, although many games can have the same moderator; a moderator can service players at different levels within the gaming platform (game level, service provider level); a node can have one or many moderators.

In a typical scenario where a user decides to play a moderator, for example Mr Big. The modules are executed sequentially when an incoming message arrives. An example is when the carrier intelligence detects and sets the carrier ID to "Vodafone" , the session intelligence detects and sets the session ID to "False" , the service intelligence detects and sets the service ID to "VFONE_GAMES" , the user intelligence detects and sets the player ID to "041629347" and the game intelligence detects and sets the game ID to "HP" for Hot Potato.

From a user's perspective, a user must first register on the web site or via their handset. After registration, the user is given a nickname, in addition to an opening float of points. At any time the user can access the web page and see how many points they have available. The web site contains full account details, and also important game information. If a user chooses to engage in a solo game of Russian Roulette for example, the game is initiated by the user sending a text message to a moderator called Mr Big using the code RR PLAY. All game messages are sent between a user and Mr Big. All messages are sent using a blank screen and use blank spaces between message parts. Once the game has started, the user is sent a message containing a game output asking them to choose a chamber and how many points to wager. There is a time limit of five minutes to send a text message after being sent the game output. A wager cannot exceed the points in the user',? account. To choose a chamber and set the wager, a message is sent in the following format: Game, Chamber & Wager . For example, if the user chooses chamber 2 and to wager 100 points the message would be RR 2 100. Game logic determines whether or not the chamber was loaded and the player receives one of two messages: "Click' you live', or 'BANG^** you're dead'. If the user survives, the wager is won. If not, the game continues and its Mr Big's turn to face the same decision as the user did. If the user is shot, half of the points the player wagered goes to Mr Big and the other half goes into the user's sucker points . pool. The game continues until either the user or Mr Big have been shot. If the user wins the game, they keep the winnings. During the game, the user can leave the game by sending a text message with the code: RR Q. A table below lists the available messages to send to the platform. All messages sent to the platform for Russian Roulette must start with the letters RR.

In a scenario where a user decides to play another human player, the platform provides a seamless link between the playing parties. The messages which are transmitted and received occur almost instantaneously, unnoticed by the playing parties. Module execution is identical to the "user plays moderator" scenario and also the user is provided with different methods of inviting other human players to join in their game. One method is where the moderator selects and invites a player from the user's favourite player's list or from the general database of players. Another method which is more user-interactive is where the user is able to select a specific player when initiating a game by sending a message containing a game code and the player's nickname, for example "SP PLAY Johnny" to play Splat with a player whose nickname is Johnny. This method is available for two player games and across different ASPs. When sending a player to player request, the requested nickname must exist and their playing preferences shows availability to play at that time. If these conditions are not met, the user is notified that play will be against a moderator.

From a user's perspective, to initiate a group game, a text message is sent to the platform using the code RR PLAY 4. The game engine attempts to source four players from the user's pre-defined 'Favourites' list . If there is no favourites list, or the user's friends are not available, the game engine sources a player randomly or play himself. Once the game has started, a message is sent asking the user to choose a chamber and how many points they wish to wager. A wager cannot exceed the points in the player's account. To choose a chamber and the wager, a message is sent in the following format: Game, Chamber and Wager. For example, to choose chamber 2 and wager 100 points, the message would be: RR 2 100. In each round, the user's group of friends participating each face the same decision, choosing a game, chamber and wager. Game logic 26 determines whether or not the chamber was loaded and a reply could be one of two messages: "Click" you live, or "BANG" you're dead. If the user survives, they win their wager and continue the game. If a user gets shot during the game, the points he wagered go into a group pool and receives a message saying how many points they lost. The last player alive at the end of the game wins the group's points. If the user wins the game, they share all the points with Mr Big, as well as gain a 41 point bonus. Each player has a time limit of five minutes to make their move and a maximum of 41 points can be wagered per round. The user can quit the game at any time by sending a message with the code: RR Q.

A table below lists the available messages to send to the platform. All messages sent to the platform for Russian Roulette must start with the letters RR.

Other games available

The game of 'hide and seek' is played between a user and a moderator called Mr Big. In each game, one plays the hunter, and the other plays a runner. With each turn, if the user is the runner they find a hiding spot. It is the other player's turn to 'go-a-hunting'. If the hunter finds the user's hiding spot '^**SPLAT^**'. You're dead. A game is initiated by sending a text message to Mr. Big. To play against Mr Big a message is sent containing the code SP PLAY.

A message is sent to the game initiator, in this case, asking whether the player wants to be the hunter or runner. To be the hunter, a message containing the code SP H is sent to the server. To be the runner, a message containing the code SP R is sent to the server. A message is sent to the runner asking them where they want to hide, offering a range of locations. For bed: SP 1 , study: SP 2 , yard: SP 3 , kitchen: SP 4, table SP 5 , porch: SP 6 , attic: SP 7 or garage: SP 8. The runner makes their selection by entering the following code SP 1 . In this case, the runner chose option 1 , the bed. A message is then sent to the hunter asking them where they want to hunt. For bed: SP 1 , study: SP 2 , yard: SP 3 , kitchen: SP 4, table SP 5 , porch SP 6 , attic SP 7 or garage SP 8. The hunter then makes their selection using the same code format, such as SP 3. In this case, the hunter chose SP 3, the yard, so the runner lives. If the hunter chooses the correct hiding spot in any of his six attempts, he wins the game and the points. If the runner evades the hunter successfully throughout the game, he wins the game and the points. A user can quit the game at any time by sending a message with the code: SP Q.

The game of 'hide and seek' can be played between two human players. To play against a friend, a message is sent containing the code SP PLAY NICKNAME to Mr Big. Alternatively, Mr Big attempts to source players from the user's 'favourites' list. If friends aren't available, he attempts to find other players willing to participate. Otherwise, Mr Big will play himself. The game play is similar to the solo version of 'hide and seek'.

A table below lists the available messages to send to the platform. All messages sent to the platform for 'hide and seek' must start with the letters SP.

A game of "Hot Potato" begins when one player rallies some friends and launches a virtual potato into play. Each player then gets rid of the potato by passing it to another friend. The potato explodes on a random basis, and if you're the player holding the potato, you lose points. The number of passes of the potato can be set for each game. The more passes chosen, the more points can be won or potentially lose. All game messages are sent between the user and the platform. All messages sent to the platform use a common prefix, HP. All messages must be sent using a blank screen using blank spaces between message parts. To initiate a group game, a text message is sent to the platform, with the number of friends to play. In this case, to play four players, the message sent is HP PLAY 4. If a message HP is sent without a number, the game engine prompts the user to find out how many players they wish to play with. A user must then reply with the full code, for example HP 4. Mr Big attempts to find players from the user's favourites list, but if a favourites list does not exist, or players in that list are not available, Mr Big finds other people for the user to play against.

The game engine asks for a maximum number of passes per game. The more passes of the potato, the longer the game will run. A good standard is to have twice as many passes as players. The message format to set the number of passes is HP 8. In this case, eight is the maximum number of passes. When the game engine has found available players, he sends a list of their names to the user. To pass the potato, the message format is: HP KEITH. In this case, Keith is the Softgame nickname of a player in a game list. If a player does not respond within five minutes, the potato explodes in the player's phone and they lose the game. Otherwise, play continues until the potato explodes. When the potato explodes, everyone is informed by the game engine. He explains who got burnt and how many points have been won or lost. Any player can quit the game at any time by sending a message with the code: HP Q

A table below lists the available messages to send to the platform. All messages sent to the platform for 'Hot Potato' must start with the letters HP.

'M-Trivia' is a game where the level of difficulty levels can be chosen and game points can be wagered on the answer. The higher the difficulty level, the more points can be won or potentially lose. To initiate a game, a text message is sent to the platform with the code prefix MT PLAY. The game engine then asks the difficulty level the user wishes to play: MT VE for very easy, MT E for easy MT M for medium MT H for hard MT VH for very hard. The game engine then asks the amount to wager for each question. With each game, a wager can be made up to 100 points, but the odds for wining vary according to the difficulty of the question attempted. The harder the question, the more points that can be earned. The message format for selecting a wager amount is MT 50 where 50 points is wagered on the current question. Next, the game engine asks a question such as: Which country has the largest population of elephants in the world? A: India B: Sri Lanka, C: Africa, D: Thailand. The message format for selecting an answer is MT C, where C represents the answer Africa. If the correct answer is guessed, Mr Big awards the wager multiplied by the odds for that level of question difficulty. If guessed incorrectly, the amount wagered is lost. The game engine then asks if play is to continue. Possible replies are MT Y for Yes or MT N for No. A user can quit the game at any time by sending a message with the code: MT Q

A table below lists the available messages to send to the platform. All messages sent to the platform for 'M-trivia' must start with the letters MT.

In other variations of the games described, some further rules may be imposed. Regarding Points:

The gaming platform allocates 1000 points when a user registers. Points won and lost on any of the games are taken from this main points account. The user can access their points account through an SMS code to check the number of points they have available to them. Regarding Player Preferences:

If a user's preferences are set to 'Play' for a certain game at a certain time, the platform sends games requests to them when looking for players in games.

A user may still start games outside their preference times. Regarding Prizes:

Prizes are offered at various times, for monthly winners of each game, monthly overall points winners. Prize winners are published on the games web site. Although the invention has been described with reference to a particular example it should be understood that it could be exemplified in many other ways. For instance, WAP may be used, and processes within each intelligence module may be combined together but their individual functionality remain unchanged.

Although end users have been described with reference to mobile communications devices, it is possible that a user can interact with the platform using a terminal connected to the Internet. In this example, the Communications Gateway is accessible via the Internet and the Internet user is mediated by the Communications Gateway having TCP/IP as the network protocol, HTTP as the data protocol and HTML as the Presentation Interface.

It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims

THE CLAIMS DEFINING THE INVENTION ARE:

1. An applications platform to provide software applications services to users via mobile communications devices, the applications platform comprising: an application server to receive applications data from users, to allocate that data to appropriate applications, to process the data according to the rules of the appropriate applications and to generate new applications data in response; a communications gateway to communicate applications data between the application server and users in the form of data packages containing the following properties: user addressing information, connection specific information, application specific information and the applications data; a communications properties store to store user addressing information and connection specific information for all connections supported by the platform; where, the communications gateway operates to deconstruct an incoming data package from a user into its different data package properties and to forward the applications data to the application server, and then, to receive applications data from the application server and use it to construct an outgoing data package to a user reusing other data package properties from the deconstructed data package that are appropriate and where they are not appropriate retrieving appropriate data package properties from the communications properties store.

2. The platform of claim 1 wherein the user addressing information is a user MSISDN.

3. The platform of claim 1 wherein the connection specific information is a network protocol including GSM, CDMA, TDMA, GPRS.

4. The platform of claim 1 wherein the connection specific information is a data protocol including MMS, SMPP, HTTP, CMPP, UCP.

5. The platform of claim 1 wherein the connection specific information is a Presentation Interface including SMS, MMS, HTML, WAP.

6. The platform of claim 1 wherein the connection specific information is a connection identifier derived from a Virtual Private Connection the data package is sent through.

7. The platform of claim 1 wherein the application specific information is the type of application.

8. The platform of claim 1 wherein the applications data is a common data element including message content.

9. The platform of claim 1 wherein the rule of an application is the condition of whether the communications gateway sends a message back to a user.

10. The platform of claim 1 wherein the rule of an application is the type of message to send to a user.

11. The platform of claim 1 wherein the rule of an application is which user the message is to be sent to.

12. The platform of claim 1 wherein the rule of an application is the type of Presentation Interface to present the message to a user.

13. The platform of claim 1 wherein the rule of an application is the language the message is to be presented in.

14. The platform of claim 1 wherein the rule of an application is the type of carrier connection to be used by the communications gateway to send the message to a user.

15. The platform of any one of the preceding claims wherein the application is a game for mobile communications devices.

16. The platform of any one of claims 1 to 14 wherein the application is a dating application for mobile communications devices.

17. The platform of any one of the preceding claims wherein the data package is a message.

18. The platform of any one of the preceding claims wherein the applications data includes content.

19. The platform of any one of the preceding claims wherein the communications gateway comprises a plurality of connectors to connect to a plurality of communication networks.

20. The platform of any one of the preceding claims further comprising an application programming interface to allow third parties to distribute their content.

21. The platform of any one of the preceding claims further comprising a software development kit to allow third parties to create applications to run on the platform.

22. The platform of any one of the preceding claims further comprising an administration module to allow remote management, configuration and monitoring of the platform.

23. The platform of any one of the preceding claims further comprising a customer relationship management module to allow third parties to access usage data and profiling information.

24. A method of providing applications via mobile communications devices for users, comprising the steps of: providing an application server to receive applications data from users, to allocate that data to appropriate applications, to process the data according to the rules of the appropriate applications and to generate new applications data in response; communicating applications data between the application server and users in the form of data packages containing the following properties: user addressing information, connection specific information, application specific information and the applications data; storing user addressing information and connection specific information for all connections supported by the platform; deconstructing an incoming data package from a user into its different data package properties and forwarding the applications data to the application server, and then, receiving applications data from the application server and using it to construct an outgoing data package to a user reusing other data package properties from the deconstructed data package that are appropriate and where they are not appropriate retrieving appropriate data package properties from the stored user addressing information and connection specific information.

25. A data package that is communicated from a mobile communications device to an applications platform to interact with an application, where the data package contains user addressing information, connection specific information, application specific information and applications data.

26. A gaming platform to provide games via mobile communications devices for users to play, the gaming platform, comprising: an application server to receive game input messages from users, to allocate that data to a game application, to process the data according to the rules of the game application and to generate game output messages in response; a communications gateway to communicate messages between the application server and users containing the following properties: a user identifier, connection specific information and a game input, a communications properties store to store the user identifiers and connection specific information for all connections supported by the platform; where, the communications gateway operates to deconstruct an incoming message from a user into its different message properties and to forward the game input to the application server, and then, to receive game output from the application server and use it to construct an outgoing message to a user reusing other message properties from the deconstructed message that are appropriate and where they are not appropriate retrieving appropriate message properties from the communications properties store.

27. The platform of claim 26 wherein a single user plays a game session with the gaming platform against an artificial other player.

28. The platform of claim 26 wherein the game engine provides an artificial moderator for a user to interact with.

29. The platform of claim 26 further comprising a message library to store messages for each moderator.

30. The platform of claim 29 wherein the messages indicate personalities of the moderators, such as being whimsical or capricious.

31. The platform of claim 26 wherein the rules of the games allows moderators to act outside the scope of the rules for the players in order to affect the outcome of games or players scores in an unpredictable way.

32. The platform of claim 26 wherein Short Message Service, Wireless Application Protocol and General Packet Radio Service is supported.

33. The platform of claim 26 wherein connectivity for 3G, iTV, packet video and Bluetooth enabled mobile devices is provided.

34. The platform of claim 26 further comprising a registration module to provide intelligent registration of new users and user driven preferences within a gaming environment.

35. The platform of claim 34 wherein the module provides that user aliases across different services be mapped to a single unique identifier, to remove the need for re-registration and to provide a level of transparency for the user.

36. The platform of claim 34 or 35 wherein the module provides intelligent scheduling, such that user-driven preferences determine each user's availability for multiplayer game invitations.

37. The platform of claim 26 wherein adheres to business rules that allow an Application Service Provider architecture to be multichannel and multicarrier enabled.

38. The platform of claim 37 wherein the business rules comprise system rules, connection rules, registration rules and moderator rules which encapsulate the business logic behind gaming on this platform.

39. A method of playing games via mobile communications devices, comprising the steps of: providing a game engine containing rules for games which are operable to provide game sessions to users in which game input messages are received from users and processed according to the rules to produce game output messages for transmission to users; and processing messages communicated between mobile communications devices and the game engine, where the messages from the game engine, when a game is in session, are processed to contain a user identifier and a game output for display on the user's mobile communications device, and where the game output invites the user to select one of a number of valid game inputs, and where messages from the communications devices, when a game is in session, contain a user identifier and a game input, and the message is processed to use the user identifier to identify a current session of the game and then passes the game input to the game engine.

40. A message that is communicated from a mobile communications device to a game platform to play a game, where the message contains a unique user identifier and a game input.

41. he message of claim 40 further containing a unique game platform identifier, a timestamp or a game code.

42. game played by at least one real player via a mobile communications device which sends messages containing a gaming input, representing that players turn in the game, to a gaming engine and which receives messages from the gaming engine containing a gaming output, representing the outcome of that round of the game.

Dated this thirty first day of May 2002

Softgame International Pty Limited Patent Attorneys for the Applicant:

F B RICE & CO