GB2470751A

GB2470751A - Delivering messages/content by determining if a target device is equipped with the appropriate application to enable the message/content to be conveyed.

Info

Publication number: GB2470751A
Application number: GB0909570A
Authority: GB
Inventors: Niall B O'kelly; Robert Wakelam
Original assignee: IQ2 Ltd
Current assignee: IQ2 Ltd
Priority date: 2009-06-04
Filing date: 2009-06-04
Publication date: 2010-12-08
Also published as: GB0914090D0; GB2470790A; GB0909570D0

Abstract

A method of delivering content/message between mobile devices, the content/message requiring a particular software application to enable it to be conveyed (played, displayed, run) at a mobile device to a user, the method comprising generating a message at a first device containing at least one item of content requiring the software application to be opened or to enable that content to be conveyed to a user; selecting a target device; conducting at least one check to determine if the target device is equipped with/in possession of the appropriate application, and to take appropriate actions if not.Aspects of the invention include the appropriate actions comprising withholding the message and sending software related for installation of the application, or the application, or a link to it, to the target device and wherein a database provided on the device is interrogated to determine if the second device is equipped with the appropriate software. Further aspects include after the target device obtains and installs the application, a message is sent to the transmitting device and the desired content is allowed to be transmitted to the target device and wherein the application downloading software checks the specification of the receiving device and downloads an appropriate version of the application form one of the servers.

Description

INTELLECTUAL

. .... PROPERTY OFFICE Application No. GB0909570.4 RTM Date:14 August 2009 The following terms are registered trademarks and should be read as such wherever they occur in this document: Bluetooth, WiFi, 02, Orange, Windows, Symbian, Blackberry, Iphone Intellectual Property Office is an operating name of the Patent Office www.ipo.gov.uk Mobile Messaging This invention relates to mobile messaging. In particular, but not exclusively, it relates to mobile messaging for messaging between two mobile handsets on a network, such as a wireless network, for example a cellular network.

Although arising initially to provide wireless telephone (voice) capabilities, mobile networks have now evolved and are very commonly used for messaging between users.

Typically messaging systems include SMS (short message service), otherwise known as text messaging where short text messages are sent between users, or MMS (mobile media services) where a richer variety of content may be shared between users. These type of systems transmit messages via a server and the messages are stored at a server if a user is unavailable because his mobile terminal is switched off, out of coverage or otherwise unavailable. The type of content which can be transferred is also limited, even using the MMS protocols to relatively small picture, video and audio files. Bluetooth and similar short range wireless technology can transmit larger content but the use of these is limited to handsets within the same locality.

The present invention arose in an attempt to provide an improved messaging system.

According to the present invention, in a first aspect, there is provided a method of delivering content between mobile devices, the content requiring a particular software application to enable it to be conveyed at a mobile device to a user, the method comprising generating a message at a first device containing at least one item of content requiring the software application to be opened; selecting a target device; conducting at least one check to determine if the target device is already likely to be in possession of the application and, if not, then withholding the message and sending software related to installation of the application or the application, or a link to it, to the target device.

By conveying is meant making the content available to the user, eg by displaying a picture or viewing, playing a sound, music file or video file, running an application, displaying a message and so on.

Most preferably, the at least one check comprises a check of a locally stored database at the sending device for an indication of whether the target device is on a contacts list associated with the software and/or is likely to have or installed the software.

If the target device is considered unlikely to have the software then a connection is made automatically with a remote database, for example one stored on a server to check for the target device on a server-side database. The connection may be by HTTP.

If the target device is not in the server-side database it is considered not to have the software then software is delivered which has the ability to determine the type (ie specification) of the target device and make an HTTP connection to the server to automatically download the correct version of the Messaging software for that specific device in a suitable format such as a JAR file.

In a preferred embodiment, the sending device is adapted to first contact a local database on device to determine whether the target device is included. If it is not found, then the sending device is adapted to interrogate a remote database to determine if a target device is listed thereon and therefore is likely to already have the software. The software is most preferably a software for conveying a plurality of multimedia content types to a user such as video, audio, picture content and most particular content which can be user manipulated by a user of a device.

In a further aspect, the invention provides a mobile messaging system, comprising at least two mobile devices, means for storing a software application on the devices; a database provided on at least one of the devices; that device being adapted to transmit a message including at least one item of content requiring the software application to enable that content to be conveyed to a user, the device being adapted, when it wishes to send that content to the other device, to interrogate said database to determine if the second device is equipped with the appropriate software and to take appropriate actions if not.

Thus, in some embodiments if the receiver is considered not to possess the application, a relatively small application (which is small enough to be sent by MMS or a plurality of MMS messages) is sent which a) checks the specificationl configuration of the receiving device, and b) makes a direct connection to a server which stores an appropriate version of the full application and downloads the application to the receiving device.

The invention further provides any novel methods and/or apparatus or combinations of methods and apparatus disclosed herein.

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: Figure 1 shows schematic part of a messaging system; and Figure 2 shows a push registry based system.

Figure 1 shows part of a wireless network. The functioning of the wireless network, the radio system and associated components are not shown in the drawing for clarity.

These would include the necessary components for enabling wireless communication over a network, for example using GSM, GPRS, third generation networks such as UMTS, further so-called 3.5, fourth or further generations of wireless communication protocol and so on.

Other wireless communications such as Bluetooth, WiFi or similar may also fully or partially be used. The components shown in Figure 1 comprise an application server 1 and two mobile devices 2 and 3. These may be mobile telephones, PDA, laptop computers or many other types of devices capable of communicating over a wireless network as discussed. Each device has a screen 4, 5 and will usually have a microphone and loud speaker (particularly if they are telephone device) and input means which may be a keypad, touchpad, and so on; or they might be a touch-type device in which the screen itself forms part of the input device.

An aggregator' s server 12 is connected by a WAP gateway 13 to the application server. Aggregator servers are known in themselves and thus including WAP Billing 14 and WAP Portal 15 applications. This connects by WAP download to the mobile devices and has a billing connection 16 to Mobile Network Operators 17 (eg 02, Orange, etc in UK).

The server 1 is associated with a particular software application which will be termed Message Maker' (MM) in this patent specification. This may be a particular software application that enables a mobile handset to view many different types of multimedia content in particular ways. In particular, it may be adapted to convey content to a user which is manipulable by the user, such as the user being able to change the properties of images, to view three-dimensional content and to rotate it, change shapes, texture, relationships between items and so on. However, the precise nature of the software is beyond the content of this patent specification. The application server holds at least a user database 11, Registration means hA and a WAP portal 11B. It communicates by WAP HTTP or otherwise to the mobile devices 2, 3.

In order for mobile device to be able to use the software, it must be provided with and install it. The server 1 therefore provides a repository for a software application usable in one or more different operating systems of handset and which can be downloaded by users. Mechanisms for downloading are well known and include WAP downloads, SMS downloads and other mechanism. The download part of the server is shown generally at 6 in the schematic figure.

In one example, the software may be downloadable to run on the JAVATM platforms and/or WINDOWS Mobile, in which case JAD and JAR files may be used, as is well known. Alternatively, or in addition, other versions of the software may be provided from the server which might operateable on different systems, such as Symbian, UIQ, Iphone, Blackberry and many other types of operating systems. Thus, if the user of a mobile device wishes to download the software in the conventional way from the server 1 over schematic wireless link 7 or 8 his mobile device will identify itself and/or its type to the server so that the correct version of the software can be downloaded from the repository 6.

In some embodiments of the invention, multimedia messages may be sent from one mobile device directly to another mobile device, peer-peer.

Thus, when a user of device 2, which has the MM software 10 installed, wishes to send a message requiring that software to a third party, it is firstly assumed that the recipient device 3 may not have the MM software installed on the device. The sender device therefore has a contacts database 9 which is populated with contact details (such as mobile numbers and names) of all recipients of messages, or just of all recipients of messages requiring the MM software, from that mobile device. Note that either this will typically be the mobile telephone number of the target device, or other unique identifier, such as an TP address, MAC address or others.

If such an identifier is not found in the contacts database 9 on the mobile device, then a connection may be made to the server 1 to check whether the intended recipient is in a user database 11 on or associated with the server. Note that although a single server is shown in Figure 1 this may of course be a number of severs either mounted together locally or distributed over a network. If the recipient's mobile number is not in the user database 11 on the server/portal, then the recipient is not registered and therefore does not have the MM software installed.

The step of interrogating database 11 may be omitted.

In the event it is considered that the target device does not have the software installed, then the first message which is sent from sending device 2 to target device 3 is an application distribution' message, typically in the form of an MMS message. The content of this application distribution message (shown schematically at 12) is preferably a JAR file containing an application that checks the device for its specification and then downloads an appropriate version of the software from server 1. At the same time as, before or after the application distribution message is sent, the recipient's mobile number is automatically added to the contact database 9 at sending device 2 and the user is also given an option to add a name to that contact number. A notifier is preferably displayed to alert the sender that their message is pending delivery, awaiting confirmation from the recipient that they have the software installed.

In a currently less-preferred modification, the JAR file may includes the actual MM software itself, together perhaps with a link to the server in case there is a problem and the software cannot be installed from the message.

The actual message that was originally composed is sent to and held at an outbox 12 at sending device 2 and flagged as pending until such time as a confirmation message is received from the recipient that they have the software installed. This pending' flag enables sending software at the device 2 to ignore that message and not attempt to send it.

Any subsequent messages that are composed for recipient 3 before confirmation is received that the MM software is installed at that device are also sent to the outbox and flagged as pending'. The sender may also receive messages to the effect that there are now X messages pending confirmation in the outbox' or similar for that particular recipient.

Once MM is installed a confirmation message can be sent automatically to the sender 2 to confirm this, perhaps from the server. This can instigate sending of the originally intended message.

If the recipient alternatively already has the software installed, then the MM software is opened and displays the contained MM message, or makes other appropriate services available (eg automatically forwarding, etc).

Furthermore, when the application distribution message is received by the recipient and already has the software then the sender's contact details (eg mobile number) can be automatically added to the recipient's contact database 13 and the recipient is given the option to add a name and/or other details.

After the receiving device 3 transmits a confirmation message to device 2 indicating that it now has the software installed, the pending' flag is removed from all messages in the outbox destined for that recipient and thus these can then be sent either automatically or manually and these messages include all the original content that was destined for device 3.

A notifier may also be displayed to inform the sender of the recipients confirmation and that the pending message are now being sent.

In a little more detail, in one embodiment the flow is as follows: The purpose of peer-peer application distribution is to deliver the ability to view a MM message with the message itself to a mobile device that does not have MM installed yet.

When sending a message, which requires MM to someone that the user has not previously sent a message to, it is assumed that the recipient may not have MM installed on their mobile device.

To determine the likelihood of the recipient not having MM installed, a MM contacts database 9 is populated with the mobile numbers (and names) of all recipients of messages from that mobile device. This makes the assumption that any recipient not in the contacts database may not have MM installed.

If, when a message is being sent, the recipient's mobile number is not in the MM contacts database on the mobile device, an P connection is automatically made with the portal 6 to check if the recipient's number is in the user database on the portal.

If the recipient's mobile number is not in the user database on the portal, the recipient is not registered and therefore does not have MM installed.

To handle this situation, the first message sent to such an individual is an application distribution' MMS message. The content of this application distribution' MMS is a JAR file containing an application that checks the device for its specification and then downloads the appropriate version of the MM from the server.

When the application distribution' MMS is sent, MM automatically adds the recipient's mobile number to the contacts database and gives the user the option to add a number to that contact number. A notifier is immediately displayed to alert the sender that their message is pending delivery awaiting a MM confirmation from the recipient.

The actual message that was composed is sent to the outbox and flagged as pending' until such time as a confirmation MMS is received from the recipient that they now have MM installed. The pending' flag causes the sender thread to ignore that message and not attempt to send it.

Any subsequent messages composed and sent to that new recipient before the confirmation MMS is received also sent to the outbox and flagged as pending' and the notifier is displayed to alert the sender that there are now X messages pending confirmation in the outbox' for that recipient.

The software application is, as indicated, also installable directly from the server, typically by WAP or other means and links may be provided to the download portion either by direct messages sent by mobile device, by word of mouth, published on websites or published literature or other means. If a WAP download is used, then both a JAR and JAD file will be downloaded from the portal in known manner in a JAVA environment.

To assist in portal identification of both sender and recipient in message delivery and to help track distribution of the software application, each downloaded application may be provided with a unique ID. This may be generated at the portal 6 during application download and is automatically inserted into a JAD file and then the corresponding JAR file is automatically updated with the revised JAD file before the files are downloaded. This unique ID may, in one embodiment, be in the form of a hexadecimal number consisting of simply incremented number appended to an application version number, further appended to the hexadecimal date of the downloads. An APP ID' tag is automatically inserted into the JAD file followed by the applications unique ID. The application JAR file is then automatically updated with the new JAD file before actual download proceeds. The installed software application at a user device has access to this APP ID' tag in the JAD file and will upload the unique ID back to the server 1 along with other identification details and message senders details on receipt of a message.

Embodiments may have the ability to create multimedia messages for sending to other mobile devices.

When creating a MM message, one or more multimedia channels in the message are populated with media content.

This composing of a message is done by inserting the relevant media type into each media channel in the message.

The media content is available on the mobile device in the MM content database.

To populate the MM content database, it is possible to download new content from a WAP download portal (or other types of download portal) and install it into MM.

To access the WAP download portal while browsing the MM content database folders, the user is presented with a media download option, or a WAP or web browser or application store.

Selecting the media download option in MM opens the mobile device's standard WAP browser and directs it to the WAP portal media content download page.

The WAP portal media content download page contains instructions on browsing, purchasing and downloading media content.

The media content on the WAP download portal is located in separate media type folders, each containing sub-folders of different media content. Each media item is displayed as an icon. This icon is the same icon that is downloaded with that media to identify it in MM.

-10 -Browsing through the sub-folders of media content on the WAP download portal and selecting an item of content or a theme (grouped content on a similar theme) highlights a buy' option on the WAP page.

Selecting the buy' option on the WAP page redirects the user to a secure transactions portal to carry out the purchase.

When the purchase is completed successfully (via premium rate SMS, PayPal TM or other online transaction service, credit card or similar transaction), the user is redirected back to the WAP portal media content download page.

The media content download page contains a list of purchased media content, a download option and instructions on how to download and install the media content into MM.

When the download option is selected, a drm protected file, such as an OMA vi.0 DD file is downloaded onto the mobile device.

When the confirm download option is selected, the purchased media content is downloaded to the user's mobile handset contained in an encrypted file.

The downloaded media is suitably encrypted so that it can only be viewed or played inside the MM application (only decrypted in memory during use). The downloaded file is OMA vi.0 DRM forward locked, so that it cannot be transferred to a different device, even by moving the memory card. It is also not possible to open the JAR file on the mobile device to access or remove the content.

Alternatively, a standard WAP browser may be run on the mobile device while MM is not running.

Then the WAP portal media content download page may be accessed and browsed for media content.

Then the media content may be selected, purchased and downloaded as above.

The program searches and finds the downloaded content file and installs the encrypted content into its database.

The media content is stored in the MM content database in its encrypted state, only being decrypted when being viewed or played inside MM.

The media content folders in the MM database exactly match the media content folders on the WAP portal for the specific media downloaded. If the sub-folder that the media is downloaded from on the WAP portal does not exist in the MM database on the mobile device, it is automatically created by MM and the downloaded media is inserted into it by the media installation' application.

This whole process allows media content to be browsed, selected, purchased and downloaded onto the mobile device using the generic WAP browser with all its inherent WAP interaction and WAP billing capabilities independently of MM. Then the downloaded media content is installed into the MM media content database using the integral media installation' application. When MM is subsequently run, the new media content is automatically added to the appropriate media folders for use in future messages.

Application in Content Download To increase the ease of acquiring MM first time users may be able to download MM with their first set of media content from the WAP site.

This capability will also allow for simple notification of new versions of MM when media content is browsed on the WAP site. Then the new version of the application may be downloaded with the media content.

When downloading media content from the WAP download portal through the -12 -mobile device's generic WAP browser, a new user who does not yet have MM will be prompted to download the application along with the media content.

Existing users will be similarly prompted to download a new version of the MM application when one is available (this prompt will also instruct the existing user to close their current version of MM before commencing the download of the new version).

Another method of notifying existing users that a new version of MM is available is by having the WAP portal check the user's mobile device specification and current version number when their MM makes an IP connection to the portal on receiving an incoming message. Then the WAP portal can have MM open a notifier to inform the user of the availability of the new version for download through their generic WAP browser.

This notifier prompt will have a WAP link to the WAP download page.

The prompt on the WAP page to download the application will have a Download' option.

Selecting the Download' option downloads the MM application onto the mobile device in the form of a JAR file and JAD file.

Closing the WAP browser and selecting the downloaded JAD file initiates installation of MM on the mobile device.

Once installed, the user is prompted to run the MM application.

Message Delivery and Billing Mobile network operator infrastructures may be used to deliver messages peer-peer and automatically bill the sender.

To achieve this peer-peer message delivery in some embodiments, the existing MMS messaging system may be used as a carrier.

-13 -When a composed message is sent from MM, the data and media content of the message is packaged into an MMS message (or an associated sequence of MMS messages) and sent to the recipient.

When the recipient's mobile network operator has successfully delivered the MMS, it sends an MMS delivery report to the sender.

When the recipient's mobile device receives the MMS message, one of three things happen: * If MM is running, the MMS is recognised by the push registry which passes access to the MMS to MM to access its contained data, which then displays the message in MM * If MM is not running, the MMS is recognised by the push registry which launches MM and passes access to the MMS to MM to access its contained data, which then displays the message in MM * If MM is not installed, the MMS is received on the mobile device's regular MMS port and stored in the MMS inbox When the message is viewed in MM an HTTP/IP connection may be immediately opened to the service providers portal and the mobile device's unique ID, the MM application's unique lID and the sender's details may be transmitted to the service provider for billing purposes. When this billing data has been successfully sent to the service provider, MM opens the message for viewing.

Billing is preferably, however, done by WAP Billing, in normal manner (ie according to number of messages downloaded, or amount of data used).

This whole warning notification and view locking/unlocking process is handled by settings in the user database on the portal during IP connection on message receipt.

-14 -In some embodiments (eg in which WAP Billing is not used) the service provider portal then automatically sends a premium MT to the sender's mobile network operator.

They in turn send a reverse billing premium rate SMS to the sender (the cost of this premium rate SMS covers the costs of the MM message and appears on the sender's monthly mobile bill or is deducted from their current pay-as-you-go balance).

An SMS delivery report is then automatically sent to the service provider by the sender's mobile network operator.

If the sender is in the USA, SMS type billing is used it is necessary to acquire a confirmation from them that they intended to send the message and currently be billed appropriately, so before the reverse billing premium rate SMS can be sent to a US sender: * The service provider portal sends an SMS to the sender requesting confirmation of their intent to send the message and whether they will accept the charge for it.

* The sender then replies with an SMS stating "Yes", and then the portal automatically sends a premium MT to the sender's mobile network operator. They in turn send a reverse billing premium rate SMS to the sender.

Sending a Message A further feature is to be able to control a user's capabilities in sending messages if they fail to comply with the terms and conditions of use (eg a message is sent in the US, but the billing confirmation SMS is consistently not replied to).

It is useful to be able to warn and sanction the user if necessary for abuse of the system or non-payment of bills.

When a message is sent from MM, an IP connection is automatically made with the application portal and the sender's ID and version number are uploaded and checked against the user database for any default of payment or infractions of the terms and -15 -conditions of use.

If a problem is flagged with their account the service provider portal can then automatically trigger a warning message or suspend specific functionality in the user's MM.

The IP connection would also allow the service provider portal to display new version or new content notifiers on the user's mobile device.

In summary:

There are several possible states the target mobile device may be in when the message is delivered.

* MM not installed on the target mobile device * MM installed on the target mobile device but not currently running * MM installed on the target mobile device and currently running Application not installed If a MM MMS is delivered to a mobile device that does not have MM installed, it will automatically appear in the mobile device's MMS Inbox.

MM MMS messages may have an initial readable portion of the text message part that explains what it is. This will also contain a link to the WAP site to get more information and download a version of MM.

In an attempt to limit this scenario happening, MM on the sending mobile device will have checked to see if this is the first message it has sent to this mobile device. If it is the first message sent to this mobile device, MM will have assumed the device does not -16-have MM installed yet (which will become less and less the case as MM becomes more widespread).

If, when a message is being sent, the recipient's mobile number is not in the MM contacts database on the mobile device, an lIP connection is automatically made with the portal 6 to check if the recipient's number is in the user database on the portal.

MM will have then held this first message in the outbox as pending' and sent the JAR file containing the application that checks the device for it specification then downloads the appropriate version of MM from the server.

This MMS will arrive in the mobile device's MMS inbox. When it is opened by the recipient, the MMS will explain who sent it, what the attached application is and how to install it.

If there is a problem with the JAR file attachment (eg not present due to network delivery restrictions), there is a WAP download link in the MMS.

Once MM is downloaded and installed, the user can run it and register the application and device on the application server, then a confirmation of installation is sent to the sender via the server.

Receipt of this confirmation will cause the pending' flag to be removed from the pending' messages in the outbox for this recipient. This allows the message sender thread to now send the messages.

If a MM MMS is delivered to a mobile device that has MM installed but not currently running, it will be intercepted by the Push Registry.

-17 -Figure 2 shows the use of a Push Registry 20. This includes a list of inbound connections 21, including the MMS TD and port number, and a list of applications 22, ie the Mobile Messaging Application. It captures incoming MMS Message Data 23 and pushes this, if appropriate, to the Mobile Messaging Application (MMS) 24. A Push Registry Application Program Interface (API) 25 is implemented in the MM application.

The Push Registry enables applications to set themselves up to be launched automatically, without user initiation.

In this embodiment, the Push Registry is used to intercept incoming MMS messages that are destined for the mobile messaging application.

Registering the application and the port to expect the incoming MMS on the Push Registry causes it to listen for such an incoming MMS and launch the application.

When the application is then running, it reads the data from the MMS into its messaging database and alerts the user of the arrival of a new message.

If the application is already running when the incoming MMS arrives on the device, it is alerted by the Push Registry of the new MMS. This causes the application to read the data from the MMS into its messaging database and alert the user of the arrival of a new message.

As shown, data (files, etc) is imported directly from the incoming MMS to the application 24.

This new messages' notifier has view and ignore options on the two soft keys of the mobile device.

Selecting the ignore option removes the notifier from the screen.

-18 -Selecting the view option causes the MM application to open the MM message inbox and display the new message in the message viewer.

If a subsequent MM message arrives on the mobile device, the Push Registry detects it and pushes the MM application to open the notifier as before, stating that a new MM message has been received.

If the user of the mobile device is not near to it when each MM message is received, they will clearly not have closed the first message notifier. So when the second MM message arrives, the Push Registry detects it and pushes the MM application to replace the notifier with another notifier, stating that two new MM messages have been received, and so on.

As each new incoming MM message is captured, the notifier is updated to state the current number of received messages and ringtone and vibration alert are played as appropriate.

When the user of the mobile device returns to it and finds the received message MM notifier, they can select either view or ignore on the soft keys as above, selecting the ignore option removes the notifier from the screen.

Selecting the view option causes the MM application to display the message inbox.

The inbox lists all of the last messages received, with the latest messages at the top, highlighted as unread.

All other screens within MM display an unread message(s) icon at the top of the screen when there are any unread messages in the inbox.

Receipt -Application running If a MM MMS is delivered to a mobile device that has MM installed and currently running, the message listener detects the incoming MM message MMS or MM application distribution MMS and opens the notifier on the mobile device s screen in front of the -19-current MM screen that states that a new message has been received. II also plays the ringtone selected in the MM settings and vibrates the mobile device if vibration alert is selected in the MM settings.

The options on the soft keys switch to view and ignore.

Selecting either the view or the ignore option removes the notifier from the screen and MM inserts the new message(s) into the MM message inbox and activates or updates the unread message(s) icon on all MM screens.

Selecting the ignore option redisplays the current MM screen.

Selecting the view option displays the MM message inbox screen with the latest messages at the top, highlighted as unread.

If a subsequent MM message arrives on the mobile device, MM detects it and opens the notifier as before, stating that a new MM message has been received.

If the user of the mobile device is not near to it when each MM message is received but has left MM running, they will clearly not have closed the first message notifier. So when the second MM message arrives, MM detects it and replaces the notifier with another notifier, stating that two new MM messages have been received, and so on.

As each new incoming MM message is captured, the notifier dialog is updated to state the current number of received messages and ringtone and vibration alert are played as appropriate.

When the user of the mobile device returns to it and finds the received MM messages notifier, they can select either view or ignore on the soft keys as above, to view the new messages in the inbox or ignore the notifier and return to where they were in MM.

-20 -The appearance of the notifier dialog in front of the MM screen and the selection of the ignore option to capture the new message(s) in the inbox must not interrupt the flow of current functionality.

The user interaction must not be diverted.

The user must be able to continue from where they left off before the notifier dialog appeared and they selected the ignore option.

A non-limiting folder structure for a software application will now be described schematically.

MM will have all its media content stored in the media content database and displayed appropriately to the user in a suitable folder structure There are two main types of media that will be stored on the mobile device within MMs media content database: * Reusable content -(downloaded/purchased and user originated) * Non-reusable content -(received in a message) Reusable Content consists of: * media items that may be inserted into a new message when composing * media items that may remain in a new message when editing an existing message Non-reusable Content consists of: * media items that may not be reused in a new message A "reusable" flag is set or not set in each media item appropriately.

The media content database's folder structure is as follows: * Images Audio -21 -* Movies * Scripts * Text backdrop images * Themes *3D scenes * 3D objects * Backdrop images

* Background sounds

These folders and sub-folders appear in the MM database browser on the mobile device * Media content may be selected for insertion into a new message from the database browser * Media content may be managed in the database browser When media content is downloaded from the WAP site onto the mobile device, it is stored in the matching sub-folder from the WAP site in MMs media content database.

If that sub-folder (or any of its parent folders) does not exist in the media content database on the mobile device, MM automatically creates the folder(s) and stores the media item in the matching sub-folder.

Each of these media folders and sub-folders may contain multiple tiers of sub-folders.

The sub-folders are automatically created and named by MM when an item of their contained media content is downloaded.

The associated icon for each sub-folder is automatically included in the media download.

-22 -When the last media item is deleted from a sub-folder by the user, that sub-folder is automatically deleted from the media content database by MM.

Similarly, any sub-folder that then contains no sub-folders is automatically deleted from the media content database by MM. Tnvisible folders may be used and retained, however.

The media content database will also contain the following non-user visible folders: * Received Media * Textures * M3Gs The received media folder contains the received media items from received messages.

The textures folder contains textures used in 3D objects that are either downloaded or received in messages.

The M3Gs folder contains imported M3G files used in 3D objects that are either downloaded or received in messages.

None of these folders appears in the MM database browser on the mobile device.

None of these folders contains any sub-folders.

When an incoming message is received, all of the media content in that message is stored in the received media folder in MMs media content database. Associated icons are stored in an icons folder.

Any textures used in the 3D object in the received message are stored in the textures folder in the media content database.

-23 -A link is automatically created to each media item from the received message header in the inbox.

However, if a received media item already exists anywhere in the media content database, it is discarded and the received message header is linked to the existing copy of that media item.

If the user subsequently downloads a media item that they have previously received in a message, the downloaded media item is stored in the matching media content database sub-folder to the WAP site.

Then the original copy of that media item in the received media folder is automatically deleted and the received message header(s) is linked to the new copy.

When a new media item is originated by the user by: * Capture from the mobile's gallery * Capture from the mobile's camera * Capture from the mobile's microphone * Text input (script) The user is prompted to select a sub-folder in the appropriate media folder hierarchy to store the new media item into.

The default sub-folder is "miscellaneous" (or maybe "my pictures" or "my sounds" etc). User originated content is reusable.

However, when saving the new media item the user is prompted as to whether they wish to allow their message recipients to be able to reuse it.

This sets a "reusable" flag in the received message content item, causing it to be stored in the appropriate media "miscellaneous" sub-folder in the recipient's media content database. The recipient may then use that received media item when creating a new message.

-24 -Note that the term server' may encompass one or more servers.

The data sent is preferably encrypted or DRM data. It may be date stamped and, for example, limited for use/viewing within a specific time period, or only to be used/viewed a predetermined number of times or only a number or uses or predetermined time. Other parameters may be determined by the encryption.

Claims

-25 -Claims 1. A method of delivering content between mobile devices, the content requiring a particular software application to enable it to be conveyed at a mobile device to a user, the method comprising generating a message at a first device containing at least one item of content requiring the software application to be opened; selecting a target device; conducting at least one check to determine if the target device is already likely to be in possession of the application and, if not, then withholding the message and sending software related to installation of the application or the application, or a link to it, to the target device.
2. A method as claimed in Claim 1, wherein the at least one check comprises a check of a locally stored database at the sending device.
3. A method as claimed in Claim 2, wherein the check is for an indication of whether the target device is on the contacts list associated with the application and/or is likely to have or installed the application.
4. A method as claimed in any preceding claim, wherein if the target device is likely to be in possession of the application then the message with the content is transmitted to the target device.
5. A method as claimed in any preceding claim, wherein if the receiving device is considered unlikely to have the application then application downloading software is sent to the receiving device and the content is held at the transmitting device at least temporarily.
6. A method as claimed in Claim 5, wherein the application downloading software checks the specification of the receiving device and downloads an appropriate version of the application from one or more servers.

-26 -
7. A method as claimed in Claim 6, wherein, after the target device eventually obtains and installs the application, a message is sent to the transmitting device and the desired content is allowed to be transmitted to the target device.
8. A method as claimed in Claim 7, wherein the content is transmitted automatically to the target device when notification is received that the target device has the required application.
9. A method as claimed in any preceding claim, wherein the application downloading software is delivered from the transmitting to target device in a JAR file.
10. A method as claimed in any preceding claim, wherein the transmitting device is arranged to first interrogate a local database on the device to determine whether the target device is likely to have or have installed the software and, if not, then the transmitting device is adapted to interrogate a remote database for information regarding the target device.
11. A method as claimed in any preceding claim, wherein the software is a software for conveying a plurality of multimedia content types to a user.
12. A method as claimed in any preceding claim, wherein the software provided to the target device is provided with a unique identifier.
13. A mobile messaging system, comprising at least two mobile devices, means for storing a software application on the devices; a database provided on at least one of the devices; that device being adapted to transmit a message including at least one item of content requiring the software application to enable that content to be conveyed to a user, the device being adapted, when it wishes to send that content to the other device, to interrogate said database to determine if the second device is equipped with the appropriate software and to take appropriate actions if not.

-27 -
14. Apparatus as claimed in Claim 13, wherein the first device is arranged, if the second device is considered unlikely to have the application, to transmit software for downloading the application to the second device from an external source.
15. Apparatus as claimed in claim 14 wherein the software is adapted to determine the specification of the second device and instigate downloading of a version of the applicationappropriate to that specification.
16. Apparatus as claimed in Claim 14 or 15, including a store on at least the first device for temporarily storing the original message and/or content.
17. Apparatus as claimed in any of Claims 13 to 16, including a remote database populated with details of devices having the appropriate software.
18. A method substantially as hereinbefore described with reference to, and as illustrated by, the accompanying drawings.
19. Apparatus substantially as hereinbefore described with reference to, and as illustrated by, the accompanying drawings.