System for and method of backing up content for use on a mobile device

DETAILED DESCRIPTION

The modalities of the present invention are aimed at retrieving, updating and offering content on electronic devices, such as mobile phones, personal digital assistants, personal computers and the like.

Different modalities of the present invention are capable of retrieving content to an electronic device in different ways. In one embodiment, a link to the content is stored on a mobile phone, allowing the mobile phone to automatically access multiple content stored in one or more remote locations (for example, third party). In this way, the content is accessed and stored on the mobile phone only when necessary, thereby more efficiently using a memory on the mobile phone.

10/36

Other modalities ensure continuous access to the subscribed content, even when the mobile phone is deactivated. For example, when a mobile phone is deactivated and then reactivated, or when service for a mobile phone is migrated to another mobile phone, the user is able to continuously recover access to the subscribed content.

Other modalities allow a user to replace content on a mobile device. As an example, when a mobile phone is reactivated, the mobile phone is recovered with an upgrade of content previously stored on the mobile phone or its equivalent. The content provider thereby increases their opportunities to sell content or subscriptions to content to customers, and gives customers opportunities to obtain the latest version of content.

In integrity content already invention ensures that of the customer, retrieves telephone handset is general, present purchase data purchased when a restored one, provides customers with the opportunity to upgrade applications previously stored on a telephone handset, conserves bandwidth once the content is only transferred when retrieved from a phone device, and content, upgrades or phone devices, limited to, data allows users to transfer equivalent content in new ones Content includes, but is not contact from address book, user generated sound and image recordings, ringtones, wallpapers and videos purchased or subscribed from third party content providers, ' and Binary to Wireless Runtime Environment (BREW) applications purchased through a Content Provider BREW mobile store.

11/36

Figure 1 is a high level diagram of components of a system according to an embodiment of the present invention. The system includes a mobile phone 101 attached to an intermediate platform 110, which in turn is attached to a content provider 120. The mobile phone 101 contains both user-generated content and other content 105, such as ringtones, calendars, images video, audio data, wallpaper, etc. Platform 110 stores a user record 115 that contains a link to content 105 at a content provider 120. When mobile device 101 must retrieve content 105, such as when it is reactivated or initialized, it notifies platform 110. Platform 110 contacts the content provider 120, identifying the mobile phone 101 and using the link to content 105, content 105. The content provider 120 then transmits the content 105 to the mobile phone 101, which retrieves the content 105.

During device setup, a user purchases or otherwise purchases content for the mobile phone 101. When the purchase is made, user registration 115 is added to platform 110, and content provider 120 records that the user (identified, for example, by mobile phone number) purchased the content. Any license usage counts are initialized at this stage, so that the user is able to retrieve content 105 only the allowed number of times. An icon is stored on the mobile phone 101 to access platform 110 and thereby finally content provider 120, as described here.

Advantageously, mobile phone 101 and platform 110 do not require extra storage for content 105, storing only links to it. Preferably, the content is stored at a service provider

12/36 content, from which the content is retrieved. This structure allows the content provider to track and notify user d, and that updates and equivalent content, which are generally under the control of the content provider, are available. Content provider 120 is also able to replace updated or equivalent content when available. In alternative modes, content 105 is stored on platform 110, from where it is transmitted to mobile 101.

Although figure 1 shows the mobile device 101 and platform 110 coupled to a single content provider, it will be recognized that the mobile device · 101 is capable of containing content acquired from and thereby being retrieved by multiple content providers. Thus, figure 2 shows a system in which the mobile device 101 and platform 110 are both coupled to multiple content providers 120A-D, which all function similarly to the content provider 120 in figure 1. It will also be recognized that although figure 1 shows a single user record 115, platform 110 will generally store multiple user records for multiple users.

Preferably, platform 110 is coupled to multiple content providers 120A-D through an aggregator 140, which receives a request for content from platform 110 and forwards the request to the appropriate provider from multiple content providers 120A-D containing the fetched content . Alternatively, aggregator 140 consults all content providers 120A-D, and content that hosts the content fetched even for the mobile phone 101.

preferred embodiment, aggregator 140 forms platform 110; in an alternative embodiment, aggregator 140 and platform 110 are separate components.

provider transmits the

In one part of

13/36

It will be recognized that although figures 1 and; 2 show lines directly connecting the components (for example, directly connecting the mobile device 101 to the platform 110), the components are preferably coupled over a wireless network, or are coupled over a network remote as Internet, over a local network, or any combination of these.

Figure 3 shows user registration 115, according to an embodiment of the present invention. User record 115 contains a mobile phone identifier 201 (the phone number, 15555551212), a uniform resource locator (URL) for content provider 203 (contentprovider.com), a content name 205 (Tetris), a content sorter 207 (game), a content version number 209 (4.0), a content size 211 (500 kB), a format for displaying content on the mobile device 213 (720 p 1080i), an encoding scheme for the content (JEG) 215, a content author 217 (GameMaker), a mobile phone identifier 219 (PhoneVendor1), and a mobile phone model 221 (3.1). Those skilled in the art will recognize that user record 115 is capable of containing other metadata, a subset of the metadata shown in figure 3, or any combination of appropriate metadata to identify the content and communicate with the content provider 120 to transmit the content for mobile phone 101. In operation, platform 110 analyzes user record 115 to determine (e.g., URL 203) the content provider content is retrieved for storage on mobile device 101.

source (by which the

As discussed above, in one embodiment, aggregator 140 in Figure 2 probes content provider locations 120A-D to determine whether they contain content to be

14/36 retrieved for mobile phone 101. Figure 4 shows steps 250 that each 120A-iD content provider site takes in response to the poll. With reference to the location of the exemplary content provider 120A, first, in step 251, the content provider 120A receives a request to retrieve content for the mobile phone 101. Preferably, the request includes the mobile phone number 101; alternatively, the request includes some other mobile phone identifier 101 or some mobile phone user identifier. In step 253, content provider 120A consults all content that has been purchased for mobile phone 101. In step 255, content provider 120A determines whether any upgrades are available for the purchased content and replace upgrades when available. In step 257, content provider 120A transmits the content (including upgrades, if available) to the mobile phone 101. The process ends at step 259. It will be recognized that new content can be resized, reformatted, or otherwise changed to ensure that runs or is displayed properly on the mobile device 101.

In other modalities, discussed below, if no previously purchased content or an upgrade is available, equivalent content is transmitted to the mobile phone 101 in step 257. In other modalities, the mobile phone user is given the option to purchase an upgrade or content equivalent. Figure 5 shows the mobile device 101, with a display that offers content equivalent to what was previously purchased for the mobile device 101 (Tetris 3.1) and a selectable link 190 to acquire the equivalent content.

15/36

Figure 6 shows the mobile phone 101 offering a list of upgrades, which the user has the option to accept or decline.

Figure 7 is a sequence diagram 300 showing user data (for example, metadata) on platform 110, updated when equivalent (or upgraded) content is transmitted to mobile phone 101. Preferably, the user is presented on mobile phone 101 with a list from which you can select equivalent content. After selecting equivalent content, in step 301, mobile phone 101 transmits a request for specific equivalent content to content provider 120. In step 303, content provider 120 transmits equivalent content to mobile phone 101. In step 305, content provider 305 transmits information (for example, metadata) to platform 110 to reflect that mobile phone 101 has now acquired the equivalent content (for example, previously purchased content has been replaced). The user registry (figure 3) is then updated to reflect what equivalent content has been purchased.

The system should ensure that equivalent content or other substitute content is selected so that it is compatible with the mobile device. In this way, equivalent content must be selected so that its device form factor, image size and binary, and its encoding format are all appropriate for the mobile device. To that end, content providers (or intermediary platforms) maintain mapping databases that map appropriate content to a device to content appropriate to the device.

content to another

16/36

Preferably, a history of purchases, subscriptions, and other purchases is generated for the mobile phone 101. As discussed below, this history is used to determine upgrades or equivalent content for the content purchased for the mobile phone 101. Based on this history, the mobile phone 101 user is offered upgrades and equivalent content for content previously purchased for the mobile phone 101, as well as offers for similar or related content to the content previously purchased.

It will be recognized that modalities of the present invention are capable of being used, not only to retrieve content to a mobile phone, but also to migrate content from one mobile phone to another. In this way, for example, a user can upgrade their mobile phone and want to transfer content from the mobile phone to a new one. Figure 8A shows the mobile phone 101 attached to platform 110, which in turn is attached to content provider 120. Figure 8B shows a mobile phone 350, an upgrade of mobile phone 101, coupled to platform 110 and content provider 120. In one embodiment, when mobile phone 350 is first activated, it automatically communicates with platform 120. A platform 120 is programmed to recognize that mobile phone 350 is an upgrade of mobile phone 101 and performs the steps of retrieving previously purchased content for mobile phone 101 to mobile phone 350, as described above. This may be because, for example, mobile phone 350 receives the same phone number as mobile phone 101. Alternatively, the user of mobile phone 350 identifies himself to platform 110 and initiates content retrieval, as described above.

17/36

In yet other embodiments of the invention, a mobile phone is programmed to store content efficiently. In one embodiment, instead of storing links to content on a remote platform (for example, platform 110, figure 1), the mobile phone itself stores links to content. Preferably, the content is accessed using one or more icons displayed on the mobile phone. Figure 9 shows a mobile phone 400 according to an embodiment of the invention. The mobile phone 400 includes a display screen 405 showing icons 401 (Tetris), 402 (Chess game), and 403 (train schedule). Each 401403 icon has an associated link, 401A-403A, respectively, so that when one of the 401-403 icons is selected, its associated link is accessed, thereby connecting the mobile device 400 to a content provider associated with the selected content. (for example, a third-party content provider) to trigger the content provider to download the content to the mobile phone 400.

As an example, the 401A link associated with the 401 icon is the URL, contentprovider.com/tetris/4.0/15555551212 which contains the content provider's Network address (contentprovider.com), the name of the content to be retrieved (Tetris), the content version (4.0) and the mobile phone number (5555551212). When contacted, the content provider analyzes this URL, determines which content to store on the mobile phone 400, and then, using the mobile phone number, transmits the content to the mobile phone 400. Preferably, after the content is no longer used on the mobile phone 400 (for example, the application is closed), it is removed from the mobile phone 400. Thus, as the mobile phone 400 does not persistently keep all content to which

18/36 has access, can access content larger than its available memory.

In an alternative embodiment, after the content has been retrieved from the content provider, it is stored both on the mobile phone 400 and in an intermediate storage location. In this way, any future recovery of the content (which can be deleted on the mobile phone after use) is from the intermediate storage location, which functions as a proxy server. In this modality, the 401A link is updated to refer to the intermediate storage location.

In one embodiment, the content is not automatically deleted from the mobile phone after use. Instead, the content is removed manually and remains on the mobile device for future use. Again using the 401 icon and its associated link as an example, when the 401 icon is selected, the mobile device 400 is programmed to first determine whether the associated content is available on the mobile phone · 400. Preferably, mobile phone 400 stores a hash of the content as part of the metadata about the content. The mobile phone 400 compares this hash against the hashes of all other content stored on the mobile phone 400. If the mobile phone 400 determines that it does not contain the content, it will retrieve the content from the content provider, as described above. Alternatively, the content is stored on an intermediate platform, which stores and uses a hash to determine content available in a similar way.

It will be recognized that characteristics of each modality described in that application can be used in other modalities. For example, link 401A is able to include metadata similar to metadata 200, which also contains an address from a third-party content provider

19/36 (element 203). Similarly, when updating or changing mobile phones, icons 401-403 and associated links 401A403A are all capable of being transferred to the new mobile phone. This can occur during an initial setup of the new mobile phone.

Use-case diagrams

Figures 10 and 11 are use case diagrams 500 and 600, respectively, used to model backing up and content recovery according to the modalities of the present invention. The use-case diagrams shown in that application use the well-known labels use, extend, and include. To make diagrams more readable, cases that use the uses relation are left unlabeled.

With reference to figure 10, a mobile device is able to subscribe to a 501 app, buy a 502 app, end a 503 app subscription, delete a 504 app, access a 505 mobile store for the first time, and perform a device recovery 507. All cases 501-504 are capable of being extended to update a user application state data store 521. The case of performing a device recovery is also capable of providing applications to device 521, providing equivalent content to device 523, providing user generated content (UG) to device 525, and querying a user application state data store 527 From the case of accessing a mobile store for the first time 505, the system is also capable of performing 507 device recovery.

As illustrated in Figure 10, any subscription or purchase of content or application is reported to and maintained in the backup system data stores. When a

20/36 recovery is started, subscribed applications, application definitions, purchased multimedia content,, - and user generated content are retrieved to the mobile device, as described here.

A popular trigger for a mobile recovery is the launch of the mobile store device device mobile store application may not be configured to launch the recovery process when it is a device.

one launched by Alternatively, determined purchased, first time in a stub app can be pre-loaded on the device. The stub app will launch shortly after the mobile phone is activated and delivered and will induce the user to retrieve applications and purchased content.

Any desired business logic can be implemented in the application: client or specific content rules can be applied and an appropriate user interface displayed to the user. Examples of these rules and user interfaces include free download and installation of subscription-based applications, reduced rate prompt prompts for pay-per-download and content applications, download free of charge by ringtones operator previously reduced special rates for ringtones previously purchased specifics, reminders about previously downloaded but deleted applications, offers to continue previously started but subsequently canceled application subscriptions, and simple reminders (or recommended alternative applications) detailing what content the user previously had.

Figure 11 is a high-level 600 use-case diagram for application and content backup and recovery. As shown in use case diagram 600, a

21/36 client is able to recover a 601 phone and backup a 603 application. A phone can be recovered by retrieving standard 605 data, retrieving user generated content 610, retrieving 620 premium content, and retrieving 640 applications. User generated content retrieves 610 can be retrieved by providing user generated content to a device, which in turn performs image transcoding 613, video file transcoding 614, and audio file transcoding 615.

Premium content is retrieved 520 for obtaining a list of premium 621 purchase content, providing premium content to the 623 device, and displaying the 630 content and application specific repurchase user interface. Premium content is provided to the 623 device for querying content equivalent premium 625 and provide premium content to the 627 device. Premium content is delivered to the 627 device by checking a 629 content delivery program.

An app is retrieved 640 by displaying a 630 content and app specific buyback user interface, getting a purchased app list 641, getting a subscribed app list 645, and giving the app to device 650. The two cases of getting a purchased application list 641 and getting a subscribed application list 645 are extended by querying the application state database 643.

Applications are provided to a device 650 by querying equivalent applications 651, checking the application delivery program 653, and updating the application state database 655.

An app is backed up 630 by registering a purchased 660 app, registering a subscribed app

22/36

665, and backing up multimedia content 670. A purchased application is registered 660 and a subscribed application is registered 665 for updating the application state database 655. The multimedia content is backed up 670 to register the purchase of multimedia content, which is extended by updating the 673 multimedia content status database.

Figure 12 shows steps 680 of a process for acquiring content (for example, purchasing, licensing, etc.) for a mobile phone, according to an embodiment of the present invention. With reference to figures 1 and 12, the process starts at step 681, and at step 682, the content is requested.

of

At

In step 683, content is transferred from content provider 120 to mobile phone 101. in step 684, user record 115 is stored on intermediate platform 110. In step 685, content provider 120 records the acquisition (along with other acquisitions for mobile phone 101) used to later retrieve mobile phone 101. In one embodiment, the acquisition is recorded in an acquisition table, as shown in figure 13. The process ends in step 686.

Figure 13 shows an acquisition table 690 maintained at content provider 120 according to an embodiment of the present invention. The 690 acquisition table contains a history of purchases passed by the user to the mobile phone 101. Individual purchases are stored in individual records of the 690 acquisition table. When content provider 120 is subsequently polled, acquisition table 690 can be used to determine what content content provider 120 has provided to mobile phone 101, and thus what content

23/36 (or equivalents or upgrades) must be retrieved for mobile phone 101.

The 690 acquisition table includes lines 691-694. The line (also referred to as a record) 691 is used, among other things, to identify mobile phone 101. Record 691 contains a phone number 691A (15555551212) for mobile phone 101, a name (for example, owner) 691B associated with the phone

Smith), and an Internet address 691C mobile phone AddressQdomain.com). The phone number 691A, the Internet address 691C or both can be used to transmit content to the mobile phone 101 according to the present invention.

Records 692-694 all contain information about previously purchased content. For example, record 692 indicates that the Tetris game (692A), version 3.0 mobile (Joe associated with (692C) was for (692B), for the phone brand Phonemakerl purchased for the mobile phone 101. So, for example, when Tetris 3.0 is purchased for mobile phone 101, record 692 is added to acquisition table 690. In a similar fashion, record 693 indicates that Chessgame (693A), version 1.0 (693B), for the phone brand Phonemakel (693C) was acquired; and record 694 indicates that the Train Schedules (694A) app, version 3.0 (694B) for the phone brand (694C) was also purchased.

It will be recognized that the 690 acquisition table is illustrative only. Those skilled in the art will recognize that acquisition tables containing other information can also be used in accordance with the present invention.

Hardware components

24/36

Figures 14-17 show components used to implement embodiments of the present invention. Some of these components are described below. .

Backup client

The backup client is preloaded on the mobile device and is programmed to implement the client-side business logic required for a content and application backup and recovery system. The main function of a user interface for the user to backup content on the device, and in the case of a device migration or new device, to recover the content to the new device.

client is to present user that allows

Content delivery interface

This is a server-side interface that provides scheduled recovery of applications and premium content from the server-side database. Preferably HTTP with a simple protocol encoded in it is used. The interface can also use opaque tokens, as used with the Retrieve Manager and buy multimedia / application. This interface should preferably also be programmed to analyze metadata to determine the source of content.

Manager to recover and buy multimedia / application

This manager interfaces with the application billing system to determine which applications a user has purchased, subscribed to, or both, which equivalent application is appropriate for a given device, and a mechanism to push that application to the backup client. Preferably, this manager generates data for offers of new content from the user's purchase history and transmits those offers to the backup client.

25/36

Preferably, the Recover Manager communicates with the mobile phone using a wireless protocol like Wireless Application Protocol (WAP).

Equivalent application mapping data storage

An extended version of the currently available data store, which shows which applications replace existing applications, and which application binary is appropriate for a given mobile device. Preferably, the mapping database is populated by entries from content providers when submitting content for inclusion in the content / application catalog and can be updated as new versions of applications are provided for new platforms.

Equivalent mapping data stores

These databases map from a specific piece of content (for example, the ringtone Who let the dogs out) to a number of platform-specific formats. Mapping data storage is used by the portability interface to report which occurrence of a piece of content is appropriate for a given platform. Preferably, if a piece of content is not available for a given platform, the storage of mapping data recommends an occurrence of substitute content, if appropriate.

data storage of application definitions and user-generated content

Application and content providers provide and maintain mapping and equivalency databases, which contain information allowing the customer to retrieve the appropriate device version of an application or content

26/36 premium. These data stores are consulted when retrieving before downloading an application or occurrence of premium content.

Premium content portability interface

This is the third-party implementation of a specified interface that allows the synchronization platform to determine which of the third-party content a given user has acquired, metadata about the content in question (eg title and ringtone description), which equivalent content should be provided to the device, and a URL that the sync platform can access to retrieve the third party’s content.

Synchronization server platform components

When contacted by the backup client at the time of recovery, the synchronization server connects to each third-party content provider and queries its content portability interface to determine which content belonging to the provider should be retrieved to the handset. The appropriate content is recovered through the same interface and provided to the backup client, who installs it on the telephone to complete the recovery process.

The synchronization server provides a standardized interface for websites (such as an operator's customer-facing website) that allows the website to provide information and action interfaces relevant to user content.

Third-party mapping interface

This layer is a conduit that connects to each of the third party content providers and uses their interfaces to implement the business logic in accordance with the present invention. This layer is also capable of

27/36 poll content providers to determine what content has been provided to a specific user or mobile phone.

User purchase history directory

The content provider's purchase history databases are populated by queries by the server-side components in the course of determining which applications can be offered to a user when recovering to the new device.

Figure 14 is a block diagram of a backup and recovery system 700, according to an embodiment of the present invention. The 700 system allows an operator or original device manufacturer (ODM) the ability to keep track of multimedia content and applications and its delivery system, while relying on the synchronization server to handle the details of what is installed on the mobile device ( along with user-generated content). The 700 system includes a mobile device 705 (for example, a mobile phone) coupled to a synchronization server platform 720. The mobile device 705 includes a backup client 709, an application data store 707, and a data store of 711 multimedia content. The 720 sync server platform includes a 721 content delivery interface, a 723 retrieve and buy multimedia / application manager, 730 user purchase history data stores, 740 application / multimedia content mapping data stores, 751 user-generated content and application definitions data store, 753 multimedia content data store, 755 application data store, and 760 synchronization server platform components.

28/36

In operation, when content is retrieved to the mobile device 705, backup client 709 sends a request to retrieve data to the content delivery interface 721. The Retrieve Manager - and buy media / application 723 queries the history databases purchase order 730 to determine what the user previously subscribed to (using data store 731) or purchased (using data store 733 and 735). The 7223 manager also queries the 740 application / multimedia content mapping stores to determine any equivalent content, and also generates new offers, if applicable. The content delivery interface 721 responds to the mobile device 705 with a list of content to be retrieved, including upgrades, updates, equivalents, and new offers, if any. Client 705 responds with a list of content to be retrieved. The 720 platform responds with application definitions and user generated content (to ensure that content is formatted for use on the mobile phone), as well as multimedia content (from data storage 753) and application (from data storage) 755).

Preferably, the content delivery interface 721 and backup client communicate using HTTP. It will be recognized, however, that other protocols such as HTTPS (secure HTTP) and Secure Sockets Layer (SSL) can also be used.

Figures 15-17 are high-level diagrams of backup and recover systems 800, 900 and 1000, respectively, according to other modalities of the present invention. Throughout this order, the same label refers to the same component. 800, 900 and 1000 systems provide different levels of control over content

29/36 between mobile phone operators and third-party content providers.

System 800 in figure 15 includes the device a mobile catalog component server platform 705 coupled with synchronization 850 and third party application / content 810. Preferably, components 810 work similarly to the intermediate platform 110 of figure 1. In the 800 system, the operator or manufacturer of the original device is able to keep track of applications and multimedia content and its delivery system, while relying on a 851 synchronization server platform component to control what is installed on the 705 mobile device. . The 850 sync server platform includes an 855 multimedia / application retrieve manager, the 851 sync server platform component, 730 user purchase history data stores, and a 860 user generated content data store.

Third party application / content catalog components 810 include content delivery interface 721, application data storage 755, storage of equivalent storage, multimedia content data 753, Application mapping data data storage mapping

Equivalent multimedia content 743 and a third party mapping interface 845.

As shown in figure 15, client 709 is coupled to the multimedia retrieval / application manager 855 and the content delivery interface 7231, preferably using an HTTP interface. The synchronization server 850 is coupled to the third party mapping interface 845, also preferably using a

30/36 HTTP interface. In this modality, a third party controls equivalent mapping information.

In operation, the mobile device 705 communicates with the content delivery interface 721, which recognizes the mobile device 705 by the URL used to request content, as described above. The 810 components store applications and multimedia (755 and 753), of which some requests for content can be met. When requested content is not hosted on components, components 810 determine equivalent content, if any, using mapping data stores 741 and 743, and then communicate with the sync server platform 850 using the third party mapping interface 845 The synchronization server platform is responsible for transmitting the requested content, or its equivalent, to the mobile device 705, as described above.

Figure 16 shows a system 900 for backing up content according to another embodiment of the present invention. In the 900 system, purchase information, application equivalence, and content delivery are all provided by a third party. The 900 system includes the 705 mobile device coupled to a 910 platform and a third-party application / content catalog of 950 components. The third party application / content catalog for components 950 is similar to the component catalog 810, except that the 730 user purchase history data stores are included in the 950 catalog but not in the 810 catalog.

Figure 17 shows a system 1000 for backing up content according to another embodiment of the present invention. System 1000 includes the mobile device 705 coupled with a third-party application / content catalog,

31/36 of components 1010. The third party application / content catalog, of components 1010, is similar to the component catalog 950, except that the third party mapping interface 845 in figure 14 is replaced with a retrieve application / content manager 1015, which is coupled to the backup client 709.

Figure 18 is a 1100 sequence diagram of interactions between a mobile device client, a synchronization platform server, and a content repository according to an embodiment of the invention. In step 1110, the user starts a routine to acquire (for example, buy, license, subscribe to, etc.) content, and in step 1115, the client communicates with the server to register the new order, thus updating the appropriate application data store in step 1120. In step 1125, the user selects to purchase the application, and in step 1130, the customer registers the application purchased on the server, thereby updating the application data store in step 1135. In step 1140, the user indicates that he is acquiring content new, and at step 1145 the customer notifies the server that the purchase is complete. The data store is updated in step 1150.

Later, when the device must be recovered, such as when it was deactivated and must be reactivated, in step 1155, the client notifies the server to recover the device. In step 1160, the device sends a command to query the subscriptions that have been purchased for the device. In step 1165, the server retrieves a list of subscribed applications, including equivalents, and returns that list to the client in step 1170. In step 1175, the customer presents this list to the user, allowing them to select the content they want. At

32/36 step 1180, the customer requests the applications (original, equivalent, upgrades, etc.) that are returned to the clientce in step 1185. In step 1190, the applications are installed on the device. In step 1195, the mobile device requests the settings for the applications, which are retrieved in step 1195 and installed on the device in step 1199.

Consult third-party content providers

As discussed above, third-party content providers support a consultable interface, which allows the synchronization platform to retrieve, for a given user, a list of previously purchased content, metadata about items in the content catalog, equivalency data on previously purchased content. , and a mechanism to retrieve equivalent content on a new phone.

The list of previously purchased content may include a unique identifier that the synchronization platform presents to the content provider on subsequent calls to these interfaces, which provides an occurrence of content (for example, ringtone Who let the dogs out in MP3 @ 128 kbps) . Metadata can include information such as the name, description size and format of a specific content item in the catalog. Equivalence data may include, given a previously acquired content ID, appropriate new content ID for a given BREW platform ID. A preferred mechanism for retrieving equivalent content includes an interface that returns an HTTP Uniform Resource Locator (URL) through which binary data can be retrieved. When this interface is accessed, a third-party content provider can apply any desired digital rights management (DRM), such as the remaining number of downloads allowed. It will be recognized that mechanisms

33/36 other than HTTP are capable of being used in accordance with the present invention.

Third-party content providers are able to be consulted in many ways. As an example, a third-party content provider is consulted for accessing the

<td>same</td><td>using URL</td><td>what</td><td>contains</td><td>the command</td><td>in</td><td>Query.</td>

<td>In that</td><td>example, the URL</td><td colspan="2">contains a</td><td>route of</td><td colspan="2">Base URL</td>

<td>(on here,</td><td>/ la / flcpi) and</td><td>an</td><td>series</td><td>that includes</td><td>one</td><td>code of</td>

<td colspan="2">operation, a number of</td><td colspan="2">version of</td><td>operation and</td><td>one</td><td>number of</td>

<td colspan="2">user phone. 0</td><td>URL</td><td colspan="2">has the general form:</td><td></td><td></td>

https: // address / base URL path / cpi? op = operationcode &amp; v = versionnumber &amp; u = telep honenumber where the address is the domain of the third party content provider.

So, for example, if the third party content provider's address is contentprovider.com, the query is to retrieve a list of user content acquired by the user (operationcode = l), the operation version is 1, and the user is identified by phone number 15555551212, so the URL on it is https://contendprovider.com/al/flcpi?op=l&amp;v=l&amp;u= 15555551212

Accessing the third party content provider using the URL will return results as a list of unique, persistent content identifiers.

In another example, the query is to retrieve content details such as metadata about a specific occurrence in content belonging to a third-party content provider. In this example, the URL that you query is given as:

34/36 http: // contentprovider. com / al · / flcpi? op = 2 &amp; v = i &amp; cid = A123897ADFAD where the operation code is 1 and the operation version number is 1. The A123897ADFAC series is the content occurrence ID in question. Accessing the third-party content provider using this URL will display the returned results as delimiter-separated fields containing metadata about content occurrences such as content file name, content description, content size, content format description, encoding description content, and content author.

In a similar way, using an appropriate operation code and associated parameters, a content portability interface can be consulted to return a list of correct equivalent content and return content URLs usable by the synchronization platform to download the appropriate version of an item of specific premium content.

Content migration

The modalities of the present invention provide an interface for configuring or updating mobile devices to access content available for other mobile devices. Figure 19A, for example, shows a system 12000 that displays icons 1210, 1220 and 1230, corresponding to Tetris, a game of Chess, and a train schedule application, respectively, and icons 1215, 1225 and 1235, corresponding to a first mobile phone (mobile phone 1), a second mobile phone (mobile phone 2) and a third mobile phone (mobile phone 3). As shown in figure 19A, across the dotted lines, the 1210 icon is dragged and dropped onto the 1215 icon, the 1220 icon is dragged and dropped onto the 1225 icon, and the 1230 icon is dragged and dropped onto the 1235 icon. is

35/36 that a link to the Tetris game on a content provider (for example, a URL), as described above, is stored on the mobile phone 1. As shown in figure 19B, the icon for Tetris 401 and the corresponding link 401A are stored in mobile phone 1 and mobile phone 2, as shown in figure 9. Similarly, an icon for chess game 402 and its associated link are also stored on mobile phone 2, and an icon for train schedule app 403 and its associated link 403A are stored on mobile phone 3. Preferably, icons 401 -403 and associated links 401A-403A are transmitted to mobile phones 1-3 wirelessly.

In one embodiment, the 1200 system is programmed to receive icons and associated links from any of the mobile phones 1-3. As an example, the 1200 system receives an icon and related link from the mobile phone 1. The icon is then displayed on the 1200 system, individually or in a list of other icons. The icon and associated link are then selected and transferred to mobile phones 2 and 3, as discussed above.

It will also be recognized that although system 1200 is programmed to transfer content to mobile phones, system 1200 can also be used to deliver new content to mobile phones 1-3. These new offers may be based on past purchases for any one or more of the 1-3 mobile phones, as found in the purchase history databases discussed above. The 1200 system can be programmed to deliver content, list prices for content and transmit content to mobile phones. According to one modality, links to content are automatically and periodically transferred from one mobile device to another so that the two are synchronized.

36/36

In operation, links to content are stored on a remote platform in relation to a mobile phone. When content must be retrieved on the mobile, the mobile phone communicates with a platform that associates the content with one or more content providers. The platform contacts one or more content providers, who directly transmit the content to the mobile phone. Substitute content, such as upgrades, equivalent content, related and similar content, can be offered to the mobile phone user, who can then select the replacement content, for a regular fee, a reduced fee or even no fee. Substitute content can be determined from a history of the user's previous purchases, which is stored and used for this purpose.

In the operation of other modalities, a link to content is stored on the mobile phone; when a wireless phone icon is selected, the mobile phone communicates directly with the content provider, which transmits the content to the mobile phone. In the operation of still other modalities, links to content are stored on a central device and transmitted to selected mobile phones. In this way, a mobile phone can be configured so that it can access content previously accessible to another mobile phone.

It will be recognized that while many of the examples included in this application refer to mobile phones, other electronic devices are capable of using modalities of the present invention including, but not limited to, personal digital assistants and personal computers.

It will be readily apparent to a person skilled in the art that various modifications can be made to the modalities without departing from the spirit and scope of the invention as defined by the appended claims.