US20080214163A1 - System for and method of backing up content for use on a mobile device - Google Patents

Abstract

In accordance with the invention, mobile phones and other electronic devices access content through links, rather than storing the content on the mobile phone or at a location under the control of a mobile phone operator. A user retrieves the content by accessing a link on the mobile phone, which results in transferring the content from a content-provider location directly to the mobile phone. In this way, the mobile phone operator does not have to reserve storage for the content, and the content provider, alerted that the user is restoring or otherwise requesting content, is able to offer the user upgrades, replacement content, and related content. To better offer a user relevant content, a history of purchases for the mobile phone, the user, or both is maintained.

Description

RELATED APPLICATIONS
• This application claims priority under 35 U.S.C. § 119(e) of both the co-pending U.S. provisional patent application Ser. No. 60/897,789, filed Jan. 26, 2007, and titled “CONTENT LOCKER, APPLICATION AND CONTENT BACKUP,” and the co-pending U.S. provisional patent application Ser. No. 60/937,314, filed Jun. 26, 2007, and titled “CONTENT LOCKER, APPLICATION AND CONTENT BACKUP,” both of which are hereby incorporated by reference in their entireties.
FIELD OF THE INVENTION
• This invention is related to transmitting content to electronic devices. More specifically, this invention is related to systems for and methods of restoring content, updating content, storing equivalent content, and offering content for mobile devices such as mobile phones.
BACKGROUND OF THE INVENTION
• Mobile phones and other electronic devices contain ever increasing content, with upgrades, equivalents, and other content created for them each year. Mobile phones, for example, store address books, user-generated content such as digital images, and third-party content such as ringtones, wallpaper, and music files, to name only a few types of content. Content is not easily restored when the phone is deactivated. It is difficult for a user to remember what content was stored on the phone, the correct version of the content for a particular phone, or even where she acquired the content. Even if she can discover all this information, the process of restoring content to the phone is still time-consuming, error prone, and tedious.
• When restoring content to a phone, the user is also unaware of upgrades to content. Unknown to the user, a content provider may have released a new version of content or an equivalent, more popular version. The user misses an opportunity to get upgraded, more desirable content, and the content provider misses an opportunity to sell, license, or offer a subscription to new content.
• Users face these same problems when upgrading to a new phone or other device. The new phone may require different versions of content: a simple transfer of content from the old to the new mobile phone will not work.
SUMMARY OF THE INVENTION
• In a first aspect of the present invention, a method of providing content to a mobile device includes determining a source of the content (e.g., a content provider) and transmitting the content from the source to a storage location accessible to the mobile device, such as directly on the mobile device. Preferably, the content is transmitted wirelessly. Mobile devices include, but are not limited to, mobile telephones, personal digital assistants, and personal computers. Content includes, but is not limited to, a mobile application program, a mobile ring tone, a mobile wallpaper, video data, audio data, a digital image, a ring back tone, or a combination of these.
• In one embodiment, the method also includes storing on the mobile device a selectable link for accessing the content on the storage location and storing data that associates the source with the content, the mobile device, or both. This data is used to determine what content has been acquired for the mobile device and the source (e.g., one or more content providers) that can be accessed to retrieve the content. The data includes a pathname to the source, such as one containing a Uniform Resource Locator, and identifiers for the content itself. The data is parsed to determine the source and the content. Preferably, the data is stored on a system remote from the mobile device, so that when the mobile device retrieves the content it contacts the system, which communicates with the source to transmit the content to the mobile device.
• In one embodiment, the source is determined by querying one or more locations for the content, such as third-party content providers. The content providers respond by transmitting the content (e.g., wirelessly) to the mobile device. In one embodiment, a single aggregation interface is used to automatically retrieve content from multiple sources.
• In a second aspect of the present invention, a method of accessing content from a device includes selecting on the device a link to content stored on a storage system and automatically receiving the content on the device in response to selecting the link. The storage system is remote to the device and when the link is selected, a copy of the content is transmitted from the storage system to the device.
• Preferably, the content is accessed by determining that the content is not stored on the storage system and then receiving the content on the storage system. As one example, content is determined to be on the storage system using a hash. A list containing the hash for each content on the storage system is maintained. If it is determined that a hash for desired content is not in the list, it is determined that the content is not on the storage system and must be retrieved from a content provider.
• In a third aspect of the present invention, a method of offering content for a first device includes storing a history of acquisitions associated with one or more entities and displaying on the first device offers for content based on the history. The one or more entities correspond to a user, to a mobile device, or to both. In other words, offers can be based on what was acquired for a particular mobile phone, for a particular user, or both. The offers are for purchasing, subscribing to, licensing, upgrading, or replacing content, or any combination of these.
• Content is updated, in part, by transcoding or resizing using content in the history. In one embodiment, the method also includes automatically receiving replacement or updated content on the first device. Preferably, the history is stored at a content provider location but can be stored at other locations.
• In one embodiment, the method also includes polling the content provider location for an acquisition associated with the one or more entities, automatically receiving notification from the content provider location of an acquisition for the one or more entities, storing metadata about content acquired by the one or more entities, or any combination of these. The metadata includes a name for content, a description of content, a size of content, a format of content, an encoding of content, an author of content, or any combination of these. The history includes a count of license usages.
• In a fourth aspect of the present invention, a method of offering content for a device includes displaying a first list of content acquired for one or more entities and transmitting one or more items in the first list to a first mobile device. Preferably, from this first list, one or more of the items are selected for storing on the device.
• In one embodiment, the first list is automatically transmitted to the first mobile device. The first list is displayed, and one or more items are selected from it and transmitted to the first mobile device from a location remote to the first mobile device. The method also includes selecting a second list of mobile devices and transmitting the one or more items to the mobile devices in the second list. The first list is generated from a history of acquisitions associated with a second mobile device.
• In a fifth aspect of the present invention, a method of configuring a device includes constructing from a first device a link to content on a storage system and storing the link on a second device. Thus, the second device is configured to access the same content available to the first device. Preferably, storing the link includes storing the content and data for selecting the content. The link, the content, or both are wirelessly transmitted from the storage system to the second device during an initial configuration of the second device. Alternatively, the link, the content, or both are stored on the second device at predetermined time intervals.
• In a sixth aspect of the present invention, a mobile device includes a client module containing a link and programmed to access content using the link, preferably wirelessly. The client module is programmed to display icons for selecting replacement content for replacing content acquired for the mobile device. The replacement content includes an upgrade to content acquired for the mobile device or a different version of the content acquired for the mobile device.
• In a seventh aspect of the present invention, a content management system for a mobile device includes a first content module containing content and a delivery interface programmed to transfer content from the content module to a mobile device. The delivery interface is programmed to transfer content from the content module to a mobile device using a link to the content accessible to the mobile device.
• The system also includes a data store of acquired content, a replacement module for mapping acquired content to replacement content, and an interface programmed to receive content from one or more sources and to poll the one or more sources to determine content acquired from the one or more sources. The interface includes a connection module for connecting to sources using Uniform Resource Indicators to the one or more sources. In one embodiment, the system also includes a parser for parsing the content to thereby determine the one or more sources. Preferably, the one or more sources are third-party sources.
• In one embodiment, the system also includes an offer module for generating offers for replacement content on the mobile device. The offer module is programmed to transmit data associated with the offers to the mobile device and the mobile device is programmed to display and select the offers. The offer module is also programmed to generate the offers from a history of acquisitions for one or more entities such as users or mobile phones.
• Preferably, the system also includes a metadata store containing metadata about content. Metadata includes information indicating a manufacturer of a mobile device, a version of a mobile device, operating capabilities of a mobile device, or any combination of these. The operating capabilities include a screen size, a number of pixels, or both.
• In one embodiment, the system also includes a Web-based interface coupled to the content manager and programmed to manage the content, a multimedia content data store, a user-generated content data store, and an application data store.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 shows a mobile phone, a platform for restoring content, and a content provider in accordance with one embodiment of the present invention.
• FIG. 2 shows a mobile phone, a platform for restoring content, and multiple content providers in accordance with one embodiment of the present invention.
• FIG. 3 shows metadata stored on the platform inFIGS. 1 and 2 and used to locate and restore content in accordance with the present invention.
• FIG. 4 is a flowchart showing the steps in a process for restoring content to a mobile phone in accordance with one embodiment of the present invention.
• FIG. 5 shows a display on a mobile device, allowing a user to store equivalent content on the mobile device in accordance with one embodiment of the present invention.
• FIG. 6 shows a display on a mobile device, allowing a user to upgrade content on the mobile device in accordance with one embodiment of the present invention.
• FIG. 7 is a sequence diagram showing the steps for acquiring equivalent content in accordance with one embodiment of the present invention.
• FIGS. 8A and 8B show transferring links to content from one mobile phone to another in accordance with one embodiment of the present invention.
• FIG. 9 shows a display on a mobile phone and icons of different content and the corresponding links for acquiring the content in accordance with one embodiment of the present invention.
• FIG. 10 is a use-case diagram for restoring/acquiring content in accordance with one embodiment of the present invention.
• FIG. 11 is a use-case diagram for backing up content in accordance with one embodiment of the present invention.
• FIG. 12 shows the steps of purchasing content, transferring content, storing information for restoring content in accordance with one embodiment of the present invention.
• FIG. 13 shows user data stored at a content provider in accordance with one embodiment of the present invention.
• FIGS. 14-17 show components for acquiring, backing up, and restoring content in accordance with embodiments of the present invention.
• FIG. 18 is a sequence diagram for acquiring and restoring content in accordance with one embodiment of the present invention.
• FIG. 19A shows an interface for selecting content and configuring one or more mobile phones to store the selected content, in accordance with one embodiment of the present invention.
• FIG. 19B shows the selected mobile phones ofFIG. 17A, after being configured to store the selected content, in accordance with one embodiment of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
• Embodiments of the present invention are directed to restoring, updating, and offering content on electronic devices, such as mobile telephones, personal digital assistants, personal computers, and the like.
• Different embodiments of the present invention are able to restore content to an electronic device in different ways. In one embodiment, a link to content is stored on a mobile phone, allowing the mobile phone to automatically access multiple content stored at one or more remote (e.g., third-party) locations. In this way, content is accessed and stored on the mobile phone only when needed, thus using memory on the mobile phone more efficiently.
• Other embodiments ensure continued access to subscribed content, even when the mobile phone is deactivated. For example, when a mobile phone is deactivated and then reactivated, or when service to one mobile phone is migrated to another mobile phone, the user is able to seamlessly restore access to the subscribed content.
• Other embodiments allow a user to substitute content on a mobile device. As one example, when a mobile phone is reactivated, the mobile phone is restored with an upgrade of content previously stored on the mobile phone or its equivalent. The content provider thus increases its opportunities to sell to customers content or subscriptions to content, and gives customers opportunities to get the latest version of content.
• In general, the present invention ensures the integrity of customer purchase data, restores already purchased content when a handset is restored, provides customers the opportunity to upgrade applications previously stored on a handset, conserves bandwidth since content is transferred only when restored on a handset, and allows users to transfer content, upgrades, or equivalent content on new handsets. Content includes, but is not limited to, address book contact data, user-generated pictures and sound recordings, ringtones, wallpapers, and videos purchased or subscribed from third-party content provides, and Binary Runtime Environment for Wireless (BREW) applications purchased through a Content Provider BREW mobile shop.
• FIG. 1 is a high-level diagram of components of a system in accordance with one embodiment of the present invention. The system includes amobile phone101 coupled to anintermediate platform110, which in turn is coupled to acontent provider120. Themobile phone101 contains both user-generated andother content105, such as ringtones, calendars, video images, audio data, wallpaper, etc. Theplatform110 stores auser record115 that contains a link to thecontent105 at acontent provider120. When themobile device101 must restorecontent105, such as when it is reactivated or initialized, it notifies theplatform110. Theplatform110 contacts thecontent provider120, identifying themobile phone101 and, using the link to thecontent105, thecontent105. Thecontent provider120 then transmits thecontent105 to themobile phone101, which restores thecontent105.
• During device set up, a user purchases or otherwise acquires content for themobile phone101. When the purchase is made, theuser record115 is added to theplatform110, and thecontent provider120 records that the user (identified, for example, by the telephone number of the mobile phone) has purchased the content. Any license usage counts are initialized at this stage, so that the user is able to retrieve thecontent105 only the allowed number of times. An icon is stored on themobile phone101 to access theplatform110 and thus ultimately thecontent provider120, as described herein.
• Advantageously, themobile phone101 and theplatform110 do not require extra storage for thecontent105, storing only links to it. Preferably, content is stored at a content provider, from which the content is retrieved. This structure allows the content provider to keep track of and notify the user that updates and equivalent content, which are generally under the control of the content provider, are available. Thecontent provider120 is also able to substitute equivalent or updated content when available. In alternative embodiments, thecontent105 is stored on theplatform110, from where it is transmitted to the mobile101.
• WhileFIG. 1 shows themobile device101 andplatform110 coupled to a single content provider, it will be appreciated that themobile device101 is able to contain content acquired from and thus to be restored by multiple content providers. Thus,FIG. 2 shows a system in which themobile device101 andplatform110 are both coupled tomultiple content providers120A-D, which all function similarly to thecontent provider120 inFIG. 1. It will also be appreciated that whileFIG. 1 shows asingle user record115, theplatform110 will generally store multiple user record, for multiple users.
• Preferably, theplatform110 is coupled to themultiple content providers120A-D through anaggregator140, which receives a request for content from theplatform110 and routes the request to the appropriate one of themultiple content providers120A-D containing the content sought. Alternatively, theaggregator140 queries allcontent providers120A-D, and the one content provider hosting the content sought transmits it to themobile phone101. In a preferred embodiment, theaggregator140 is part of theplatform110; in an alternative embodiment, theaggregator140 and theplatform110 are separate components.
• It will be appreciated that althoughFIGS. 1 and 2 show lines directly connecting the components (e.g., directly connecting themobile device101 to the platform110), the components are preferably coupled over a wireless network, or are coupled over a wide area network such as the Internet, over a local area network, or any combination of these.
• FIG. 3 shows theuser record115 according to one embodiment of the present invention. Theuser record115 contains an identifier of the mobile phone201 (the phone number, 15555551212), a uniform resource locator (URL) of the content provider203 (contentprovider.com), a name of the content205 (Tetris), a classifier of the content207 (game), a version number of the content209 (4.0), a size of the content211 (500 kB), a format for displaying the content on the mobile device213 (720p 1080i), an encoding scheme for the content (JPEG)215, an author of the content217 (GameMaker), an identifier of the mobile phone219 (PhoneVendor1), and a model of the mobile phone221 (3.1). Those skilled in the art will recognize that theuser record115 is able to contain other metadata, a subset of the metadata shown inFIG. 3, or any combination of metadata suitable for identifying the content and communicating with thecontent provider120 to transmit the content to themobile phone101. In operation, theplatform110 parses theuser record115 to determine the source (e.g., URL203) of the content provider from which the content is retrieved for storing on themobile device101.
• As discussed above, in one embodiment, theaggregator140 ofFIG. 2 polls thecontent provider locations120A-D to determine whether they contain content to be restored to themobile phone101.FIG. 4 shows thesteps250 that eachcontent provider location120A-D takes in response to the polling. Referring to the exemplarycontent provider location120A, first, in thestep251, thecontent provider120A receives a request to restore content to themobile phone101. Preferably, the request includes the telephone number of themobile phone101; alternatively, the request includes some other identifier of themobile phone101 or some identifier of the user of the mobile phone. In thestep253, thecontent provider120A looks up all the content that has been acquired for themobile phone101. In thestep255, thecontent provider120A determines whether any upgrades are available for the acquired content and substitutes upgrades when available. In thestep257, thecontent provider120A transmits the content (including upgrades, if available) to themobile phone101. The process ends in thestep259. It will be appreciated that new content may be resized, reformatted, or otherwise changed to ensure that it performs or is displayed properly on themobile device101.
• In other embodiments, discussed below, if neither previously acquired content nor an upgrade is available, equivalent content is transmitted to themobile phone101 in thestep257. In still other embodiments, the user of the mobile phone is given the option of acquiring an upgrade or equivalent content.FIG. 5 shows themobile device101, with a display offering content equivalent to what was previously acquired for the mobile device101 (Tetras 3.1) and aselectable link190 for acquiring the equivalent content.
• FIG. 6 shows themobile phone101 offering a list of upgrades, which the user has the option of accepting or declining.
• FIG. 7 is a sequence diagram300 showing user data (e.g., metadata) on theplatform110, updated when equivalent (or upgraded) content is transmitted to themobile phone101. Preferably, the user is presented on themobile phone101 with a list from which she can select equivalent content. After selecting equivalent content, in thestep301, themobile phone101 transmits to the content provider120 a request for particular equivalent content. In thestep303, thecontent provider120 transmits the equivalent content to themobile phone101. In thestep305, thecontent provider305 transmits information (e.g., metadata) to theplatform110 to reflect that themobile phone101 has now acquired the equivalent content (e.g., the previously acquired content has been replaced). The user record (FIG. 3) is then updated to reflect that equivalent content has been acquired.
• The system must ensure that equivalent or other replacement content is selected so that it is compatible with the mobile device. Thus equivalent content must be selected so that its binary, image size and device form factor, and its encoding format are all suitable for the mobile device. To this end, content providers (or intermediate platforms) maintain mapping databases that map content suitable for one device to content suitable for another device.
• Preferably, a history of purchases, subscriptions, and other acquisitions are generated for themobile phone101. As discussed below, this history is used to determine upgrades or equivalent content for the content acquired for themobile phone101. Based on this history, the user of themobile phone101 is offered upgrades and equivalent content for content previously acquired for themobile phone101, as well as offers for content similar or related to previously purchased content.
• It will be appreciated that embodiments of the present invention are able to be used, not only to restore content to a mobile phone, but also to migrate content from one mobile phone to another. Thus, for example, a user may upgrade his mobile phone and wishes to transfer content from the mobile phone to a new one.FIG. 8A showsmobile phone101 coupled to theplatform110, which in turn is coupled to thecontent provider120.FIG. 8B shows amobile phone350, an upgrade of themobile phone101, coupled to theplatform110 and thecontent provider120. In one embodiment, when themobile phone350 is first activated, it automatically communicates with theplatform120. Theplatform120 is programmed to recognize that themobile phone350 is an upgrade of themobile phone101 and performs the steps of “restoring” content previously acquired for themobile phone101 to themobile phone350, such as described above. This may occur because, for example, themobile phone350 is given the same phone number as themobile phone101. Alternatively, the user of themobile phone350 identifies herself to theplatform110 and initiates “restoration” of content, such as described above.
• In still other embodiments of the invention, a mobile phone is programmed to store content efficiently. In one embodiment, rather than store links to content on a remote platform (e.g.,platform110,FIG. 1), the mobile phone itself stores links to content. Preferably, the content is accessed using one or more icons displayed on the mobile phone.FIG. 9 shows amobile phone400 in accordance with one embodiment of the invention. Themobile phone400 includes adisplay screen405 showing icons401 (Tetris),402 (Chess game), and403 (Train schedule). Each icon401-403 has an associated link,401A-403A, respectively, such that when one of the icons401-403 is selected, its associated link is accessed, thereby connecting themobile device400 to a content provider associated with the selected content (e.g., a third-party content provider) to trigger the content provider to download the content to themobile phone400.
• As one example, thelink401A associated with theicon401 is the URL, contentprovider.com/tertris/4.0/15555551212, which contains the Web address of the content provider (contentprovider.com), the name of the content to be retrieved (Tetris), the version of the content (4.0), and the phone number of the mobile phone (5555551212). When contacted, the content provider parses this URL, determines what content to store on themobile phone400, and then, using the phone number of the mobile phone, transmits the content to themobile phone400. Preferably, once the content is no longer used on the mobile phone400 (e.g., the application is closed), it is removed from themobile phone400. In this way, because themobile phone400 does not persistently maintain all the content it has access to, it can access content larger than its available memory.
• In an alternative embodiment, once the content is retrieved from the content provider, it is stored on both themobile phone400 and on an intermediate storage location. In this way, any future retrieval of the content (which may be deleted on the mobile phone after use) is from the intermediate storage location, which functions as a proxy server. In this embodiment, thelink401A is updated to refer to the intermediate storage location.
• In one embodiment, the content is not automatically deleted from the mobile phone after it is used. Instead, the content is removed manually and remains of the mobile device for future use. Again using theicon401 and its associated link as an example, when theicon401 is selected, themobile device400 is programmed to first determine whether the associated content is available on themobile phone400. Preferably, themobile phone400 stores a hash of the content as part of the metadata about the content. Themobile phone400 compares this hash against the hashes of all other content stored on themobile phone400. If themobile phone400 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 available content in a similar manner.
• It will be appreciated that features of each embodiments described in this application can be used on other embodiments. For example, thelink401A is able to include metadata similar to themetadata200, which also contains an address of a third-party content provider (element203). Similarly, when updating or changing mobile phones, the icons401-403 and associatedlinks401A-403A are all able to be transferred to the new mobile phone. This may occur during an initial configuration of the new mobile phone.
Use Case Diagrams
• FIGS. 10 and 11 are use-case diagrams500 and600, respectively, used to model backing up and restoring content in accordance with embodiments of the present invention. The use-case diagrams shown in this application use the well-known labels “uses,” “extends,” and “includes.” To make the diagrams more readable, cases that use the relationship “uses” are left unlabeled.
• Referring toFIG. 10, a mobile device is able to subscribe to anapplication501, purchase anapplication502, end anapplication subscription503, delete anapplication504, access a “mobile shop” for thefirst time505, and perform a device restore507. All of the cases501-504 are able to be extended to update a userapplication status datastore521. The case of performing a device restore is also able to deliver applications to thedevice521, deliver equivalent content to thedevice523, deliver user-generated (UG) content to thedevice525, and query a userapplication status datastore527. From the case of accessing a mobile shop for thefirst time505, the system is also able to perform device restore507.
• As illustrated inFIG. 10, any application or content purchase or subscription is reported to and maintained in the backup system datastores. When a restore is initiated, the subscribed applications, application settings, purchased multimedia content, and user-generated content are restored to the mobile device, as described herein.
• One popular trigger for a mobile device restore is the initiation of the on-device mobile shop. The mobile shop application can be configured to launch the restore process when it is launched for the first time on a device. Alternatively, a stub application may be preloaded onto the device. The stub application will launch shortly after the mobile phone is activated and provisioned and will prompt the user to restore applications and purchased content.
• Any business logic desired may be implemented in the client: application or content-specific rules may be applied and an appropriate user interface displayed to the user. Examples of these rules and user-interfaces include automatic no-fee download and installation of subscription-based applications, reduced-fee “repurchases” prompt for pay-per-download applications and content, no-fee download of operator-determined number of previously purchased ringtones, special reduced fees for particular previously purchased ringtones, reminders about previously downloaded but deleted applications, offers to continue previously initiated but subsequently canceled application subscriptions, and simple reminders (or recommended alternative applications) detailing what content the user had previously.
• FIG. 11 is a high-level use case diagram600 for application and content backup and restore. As shown in the use-case diagram600, a client is able to restore aphone601 and backup anapplication603. A phone can be restored by restoringstandard data605, restoring user-generatedcontent610, restoringpremium content620, and restoringapplications640. User-generated content restores610 can be restored by delivering user-generated content to a device, which in turn performsimage transcoding613,video file transcoding614, andaudio file transcoding615.
• Premium content is restored620 by getting a purchasepremium content list621, delivering premium content to thedevice623, and displaying application and content specificrepurchase user interface630. Premium content is delivered to thedevice623 by looking upequivalent premium content625 and delivering premium content to thedevice627. Premium content is delivered to thedevice627 by checking acontent delivery policy629.
• An application is restored640 by displaying an application and content specificrepurchase user interface630, getting a purchasedapplication list641, getting a subscribedapplication list645, and delivering the application to thedevice650. Both the cases of getting a purchasedapplication list641 and getting a subscribedapplication list645 are extended by querying theapplication state database643.
• Applications are delivered to adevice650 by looking upequivalent applications651, checking theapplication delivery policy653, and updating theapplication state database655.
• An application is backed up603 by registering a purchasedapplication660, registering a subscribedapplication665, and backing upmultimedia content670. A purchased application is registered660 and a subscribed application is registered665 by updating theapplication state database655. Multimedia content is backed up670 by registering multimedia content purchase, which is extended by updating the multimediacontent state database673.
• FIG. 12 shows thesteps680 of a process for acquiring content (e.g., purchase, license, etc.) for a mobile phone in accordance with one embodiment of the present invention. Referring toFIGS. 1 and 12, the process starts in thestep681, and in thestep682, the content is requested. In thestep683, the content is transferred from thecontent provider120 to themobile phone101. In thestep684, theuser record115 is stored on theintermediate platform110. In thestep685, thecontent provider120 records the acquisition (along with other acquisitions for the mobile phone101), used to later restore themobile phone101. In one embodiment, the acquisition is recorded in an acquisition table, such as shown inFIG. 13. The process ends in thestep686.
• FIG. 13 shows an “acquisition table”690 maintained at thecontent provider120 in accordance with one embodiment of the present invention The acquisition table690 contains a history of a user's past acquisitions for themobile phone101. Individual purchases are stored in individual records of the acquisition table690. When thecontent provider120 is later polled, the acquisition table690 can be used to determine what content thecontent provider120 provided to themobile phone101, and thus what content (or equivalents or upgrades) is to be restored to themobile phone101.
• The acquisition table690 includes rows691-694. The row (also referred to as a “record”)691 is used, among other things, to identify themobile phone101. Therecord691 contains a telephone number691A (15555551212) of themobile phone101, a name (e.g., owner)691B associated with the mobile phone (“Joe Smith”), and anInternet address691C associated with the mobile phone “Address@domain.com”). The telephone number691A, theInternet address691C, or both can be used to transmit content to themobile phone101 in accordance with the present invention.
• The records692-694 all contain information about previously acquired content. For example, therecord692 indicates that the game Tetris (692A), version 3.0 (692B), for the phone brand Phonemaker1 (692C) was acquired for themobile phone101. Thus, for example, when Tetris 3.0 is purchased for themobile phone101, therecord692 is added to the acquisition table690. In a similar manner, therecord693 indicates that Chessgame (693A), version 1.0 (693B), for the phone brand Phonemaker1 (693C) was acquired; and therecord694 indicates that the application “Train schedule” (694A), version 3.0 (694B), for the phone brand Phonemaker1 (694C), was also acquired.
• It will be appreciated that the acquisition table690 is only illustrative. 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
• FIGS. 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 an application and content backup and restore system. The client's primary function is to present a user interface to the user which allows the user to backup content on the device, and in the case of a device migration or new device, retrieve the content to the new device.
Content Delivery Interface
• This is a server-side interface that provides programmed retrieval of the applications and premium content from a server-side database. Preferably, HTTP with a simple protocol encoded in it is used. The interface may also use opaque tokens, such as used with the Application/Multimedia Purchase and Restore Manager. Preferably, this interface is also be programmed to parse metadata to determine the source of content. Application/Multimedia Purchase and Restore Manager This manager interfaces with the application billing system to determine which applications a user has purchased, subscribed to, or both, what 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 user purchase histories and transmits these offers to the backup client. Preferably, the Restore Manager communicates with the mobile phone using a wireless protocol such as Wireless Application Protocol (WAP).
Equivalent Application Mapping Datastore
• An extended version of the currently available datastore, which shows which applications supersede existing applications, and which application binary is appropriate for a given mobile device. Preferably, the mapping database is populated by entries from the content providers when they submit content for inclusion on the application/content catalog and may be updated as new versions of applications are provided for new platforms.
“Equivalent” Mapping Datastores
• These databases map from a particular piece of content (e.g., “Who Let the Dogs Out” ringtone) to a number of platform-specific formats. The mapping datastore is utilized by the portability interface to report which instance 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 mapping datastore recommends a substitute content instance, if appropriate.
User Generated Content and Application Settings Datastore
• Content and application providers provide and maintain mapping and equivalence databases, which contain information allowing the client to retrieve the device-appropriate version of an application or premium content. These datastores are queried at restore time before downloading an application or instance 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's content a given user has purchased, metadata about the content in question (e.g., ringtone title and description), which equivalent content should be provided to the device, and a URL that the synchronization platform can access to retrieve the content from the third party.
Synchronization Server Platform Components
• When contacted by the backup client at restore time, 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 restored to the handset. The appropriate content is retrieved over the same interface and provided to the backup client, which installs it on the handset to complete the restore process.
• The synchronization server provides a standardized interface to Web sites (such as an operator's customer-facing Web sites), which enables the Web site to provide information and actionable interfaces pertaining to the user's content.
Third-Party Mapping Interface
• This layer is a conduit that connects to each of the third-party content suppliers and uses their interfaces to implement the business logic in accordance with the present invention. This layer is also able to poll content providers to determine what content was provided to a particular user or mobile phone.
User Purchase History Directory
• The content provider purchase history databases are populated by queries by the server-side components in the course of determining which applications may be offered to a user when restoring to the new device.
• FIG. 14 is a block diagram of a backup and restoresystem700 in accordance with one embodiment of the present invention. Thesystem700 allows an operator or original device manufacturer (ODM) the ability to maintain control of the applications and multimedia content 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). Thesystem700 includes a mobile device705 (e.g., a mobile phone) coupled to asynchronization server platform720. Themobile device705 includes abackup client709, anapplication datastore707, and amultimedia content datastore711. Thesynchronization server platform720 includes acontent delivery interface721, an application/multimedia purchase and restoremanager723, userpurchase history datastores730, multimedia content/application mapping datastores740, a user-generated content and application settings datastore751, amultimedia content datastore753, anapplication datastore755, and synchronizationserver platform components760.
• In operation, when content is restored to themobile device705, thebackup client709 sends a request to restore data to thecontent delivery interface721. The Application/Multimedia Purchase andRestore Manager723 queries the userpurchase history databases730 to determine what the user has previously subscribed to (using the datastore731) or purchased (using thedatastores733 and735). Themanager723 also queries the multimedia content/application mapping datastores740 to determine any equivalent content, and also generates new offers, if applicable. Thecontent delivery interface721 responds to themobile device705 with a list of content to be restored, including upgrades, updates, equivalents, and new offers, if any. Theclient705 responds with a list of content to be restored. Theplatform720 responds with user-generated content and applications settings (to ensure that the content is formatted for use on the mobile phone), as well as the multimedia content (from the datastore753) and the application (from the datastore755).
• Preferably, the content-delivery interface721 and the backup client communicate using HTTP. It will be appreciated, however, that other protocols such as HTTPS (HTTP Secure) and Secure Sockets Layer (SSL) can also be used.
• FIGS. 15-17 are high-level diagrams of backup and restoresystems800,900, and1000, respectively, in accordance with other embodiments of the present invention. Throughout this application, the same label refers to the same component. Thesystems800,900, and1000 provide different levels of control over content among the mobile phone operators and the third-party content providers.
• Thesystem800 inFIG. 15 includes themobile device705 coupled to asynchronization server platform850 and third-party content/application catalog components810. Preferably, thecomponents810 function similarly to theintermediate platform110 ofFIG. 1. In thesystem800, the operator or original device manufacturer is able to maintain control of the applications and multimedia content and its delivery system, while relying on a synchronizationserver platform component851 to control what is installed on themobile device705. Thesynchronization server platform850 includes an application/multimedia restoremanager855, the synchronizationserver platform component851, the userpurchase history datastores730, and a user-generatedcontent datastore860.
• The third-party content/application catalog components810 includes thecontent delivery interface721, theapplication datastore755, themultimedia content datastore753, the “Equivalent Application”mapping datastore741, the “Equivalent Multimedia Content”mapping datastore743, and a third-party mapping interface845.
• As shown inFIG. 15, theclient709 is coupled to the application/multimedia restoremanager855 and thecontent delivery interface721, preferably using an HTTP interface. Thesynchronization server850 is coupled to the third-party mapping interface845, also preferably using an HTTP interface. In this embodiment, a third-party controls equivalent mapping information.
• In operation, themobile device705 communicates with thecontent delivery interface721, which recognizes themobile device705 by the URL used to request content, such as described above. Thecomponents810 store applications and multimedia (755 and753), from which some requests for content can be satisfied. When content requested is not hosted on the components, thecomponents810 determine equivalent content, if any, using themapping data stores 741 and 743, and then communicate with thesynchronization server platform850 using the third-party mapping interface845. The synchronization server platform responds by transmitting the requested content, or its equivalent, to themobile device705, such as described above.
• FIG. 16 shows asystem900 for backing up content in accordance with another embodiment of the present invention. In thesystem900, purchase information, application equivalency, and content delivery are all provided by a third party. Thesystem900 includes themobile device705 coupled to aplatform910 and a third-party content/application catalog ofcomponents950. The third-party content/application catalog ofcomponents950 is similar to the catalog ofcomponents810, except that the userpurchase history datastores730 is included on thecatalog950 but not on thecatalog810.
• FIG. 17 shows asystem1000 for backing up content in accordance with another embodiment of the present invention. Thesystem1000 includes themobile device705 coupled to a third-party content/application catalog ofcomponents1010. The third-party content/application catalog ofcomponents1010 is similar to the catalog ofcomponents950, except that third-party mapping interface845 inFIG. 14 is replaced with a content/application restoremanager1015, which is coupled to thebackup client709.
• FIG. 18 is a sequence diagram1100 of interactions between a mobile device client, a synchronization platform server, and a content repository in accordance with one embodiment of the invention. In thestep1110, the user starts a routine for acquiring (e.g., purchasing, licensing, taking a subscription to, etc.) content, and in thestep1115, the client communicates with the server to register the new application, thereby updating the appropriate application datastore in thestep1120. In thestep1125, the user selects to purchase the application, and in thestep1130, the client registers the purchased application on the server, thereby updating the application datastore in thestep1135. In thestep1140, the user indicates that she is done acquiring new content, and in thestep1145 the client notifies the server that the purchasing is complete. The datastore is updated in thestep1150.
• Later, when the device is to be restored, such as when it has been deactivated and is to be reactivated, in thestep1155, the client notifies the server to restore the device. In thestep1160, the device sends a command to query the subscriptions that have been acquired for the device. In thestep1165, the server retrieves a list of subscribed applications, including equivalents, and returns this list to the client in thestep1170. In thestep1175, the client presents this list to the user, allowing her to select the content that she wants. In thestep1180, the client requests the applications (original, equivalent, upgrades, etc.), which are returned to the client in thestep1185. In thestep1190, the applications are installed on the device. In thestep1195, the mobile device requests the settings for the applications, which are retrieved in thestep1195 and installed on the device in thestep1199.
Querying Third-Party Content Providers
• As discussed above, third-party content providers support a queryable 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 about previously purchased content, and a mechanism for retrieving equivalent content on a new handset.
• The list of previously purchased content can include a unique identifier that the synchronization platform presents to the content provider on subsequent calls to these interfaces, which provides an instance of content (e.g., “Who Let The Dogs Out Ringtone in MP3 @ 128 kbps). Metadata can include information such as the name, description size, and format of a particular content item in the catalog. Equivalency data can include, given a previously purchased content ID, new content ID appropriate for a given BREW platform ID. A preferred mechanism for retrieving equivalent content includes an interface that returns an HTTP Uniform Resource Locator (URL) via which binary data can be retrieved. When this interface is accessed, a third-party content provider can apply any digital rights management (DRM) desired, such as the remaining number of downloads allowed. It will be appreciated that mechanisms other than HTTP are able to be used in accordance with the present invention.
• Third-content providers are able to be queried in many ways. As one example, a third-party content provider is queried by accessing it using a URL that contains the query command. In this example, the URL contains a base URL path (here, “/la/fl cpi”) and a string that includes an operation code, an operation version number, and a user telephone number. The URL has the general form:
• https://address/base URL path/cpi?op=operationcode&v=versionnumber&u=telephonenumber
  where the address is the domain of the third-party content provider.
• Thus, for example, if the address of the third-party content provider is “contentprovider.com,” the query is to retrieve a list of user content purchased by the user (operationcode=1), the operation version is 1, and the user is identified by thetelephone number 15555551212, then the querying URL is
• https://contentprovider.com/al/fl cpi?op=1 &v=1 &u=115555551212
• Accessing the third-party content provider using the URL will return results such as a list of persistent, unique content instance identifiers.
• In another example, the query is to retrieve content details such as metadata about a particular instance on content owned by a third-party content provider. In this example, the querying URL is given as:
• https://contentprovider.com/al/fl cpi?op=2&v=1 &cid=A1123897ADFAD
  where the operation code is 1 and the operation version number is 1. The string A123897ADFAD is the content instance ID in question. Accessing the third-party content provider using this URL will display the returned results such as delimiter separated fields containing metadata about content instances such as content file name, content description, content size, content format description, content encoding description, and content author.
• In a similar manner, using an appropriate operation code and associated parameters, a content portability interface can be queried to return a list of correct equivalent content and to return content URLs usable by the synchronization platform to download the appropriate version of a particular premium content item.
Content Migration
• Embodiments of the present invention provide an interface for configuring or updating mobile devices to access content available to other mobile devices.FIG. 19A, for example, shows asystem1200 that displaysicons1210,1220, and1230, corresponding to Tetris, a Chess game, and a Train schedule application, respectively, andicons1215,1225, and1235, corresponding to a first mobile phone (Mobile phone1), a second mobile phone (Mobile phone2), and a third mobile phone (Mobile phone3). As shown onFIG. 19A, by the dotted lines, theicon1210 is dragged and dropped to theicon1215, theicon1220 is dragged and dropped to theicon1225, and theicon1230 is dragged and dropped to theicon1235. The result of this is that a link to the game Tetris on a content provider (e.g., a URL), such as described above, is stored on themobile phone1. As shown inFIG. 19B, the icon to theTetris401 and thecorresponding link401A are stored on theMobile phone1 and theMobile phone2, such as shown inFIG. 9. Similarly, an icon to theChess game402 and its associated link are also stored on theMobile phone2, and an icon to theTrain schedule application403 and its associatedlink403A are stored on theMobile phone3. Preferably, the icons401-403 and the associatedlinks401A-403A are transmitted to the Mobile phones1-3 wirelessly.
• In one embodiment, thesystem1200 is programmed to receive icons and associated links from any one of the Mobile phones1-3. As one example, thesystem1200 receives an icon and related link from theMobile phone1. The icon is then displayed on thesystem1200, alone or in a list of other icons. The icon and associated link are then selected and transferred to theMobile phones2 and3, as discussed above.
• It will also be appreciated that while thesystem1200 is programmed to transfer content to mobile phones, thesystem1200 can also be used to offer new content for the Mobile phones1-3. These new offers can be based on previous acquisitions for any one or more of the Mobile phones1-3, such as found in purchase history databases discussed above. Thesystem1200 can be programmed to offer content, list prices for content, and transmit content to mobile phones. In accordance with one embodiment, links to content are automatically and periodically transferred from one mobile device to another so that the two are synchronized.
• In operation, links to content are stored on a platform remote to a mobile phone. When content is to be restored on the mobile, the mobile phone communicates with a platform that associates the content with one or more content providers. The platform contacts the one or more contact providers, which directly transmit the content to the mobile phone. Replacement content, such as upgrades, equivalent content, related content, and the like, can be offered to the mobile phone user, who can then select the replacement content, for a regular fee, a reduced fee, or even for no fee. Replacement content can be determined from a history of the user's past purchases, which is stored and used for this purpose.
• In the operation of other embodiments, a link to content is stored on the mobile phone; when an icon on the mobile phone 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 embodiments, 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 appreciated that while many of the examples included in this application refer to mobile phones, other electronic devices are able to use embodiments of the present invention including, but not limited to, personal digital assistants and personal computers.
• It will be readily apparent to one skilled in the art that various modifications may be made to the embodiments without departing from the spirit and scope of the invention as defined by the appended claims.

Claims (86)

1. A method of providing content to a mobile device comprising:

determining a source of the content; and

transmitting the content from the source to a storage location accessible to the mobile device.

2. The method ofclaim 1, wherein the storage location is on the mobile device.

3. The method ofclaim 2, wherein the content is transmitted directly from the source to the mobile device.

4. The method ofclaim 1, wherein the storage location is remote from the mobile device.

5. The method ofclaim 4, further comprising storing on the mobile device a selectable link for accessing the content on the storage location.

6. The method ofclaim 1, further comprising storing data associating the source with the content, the mobile device, or both.

7. The method ofclaim 6, wherein the data is stored at a location different from the mobile device and the storage location.

8. The method ofclaim 6, further comprising parsing the data to thereby determine the source.

9. The method ofclaim 6, wherein the data comprises a pathname to the source.

10. The method ofclaim 9, wherein the pathname comprises a Uniform Resource Locator.

11. The method ofclaim 1, wherein determining the source comprises querying one or more locations for the content.

12. The method ofclaim 11, wherein the locations are third-party content providers.

13. The method ofclaim 1, further comprising:

displaying an icon corresponding to the content on the mobile device; and

selecting the icon to thereby automatically transmit the content from the source to the storage location.

14. The method ofclaim 1, further comprising automatically retrieving the content from multiple sources through a single aggregation interface.

15. The method ofclaim 14, wherein the multiple sources comprise third-party content providers.

16. A method of accessing content from a device comprising:

selecting on the device a link to content stored on a storage system; and

automatically accessing the content on the device in response to selecting the link.

17. The method ofclaim 16, wherein the storage system is remote to the device.

18. The method ofclaim 17, wherein selecting the link comprises transmitting a copy of the content from the storage system to the device.

19. The method ofclaim 16, wherein accessing the content comprises:

determining that the content is not stored on the storage system; and

receiving the content on the storage system.

20. The method ofclaim 19, wherein the location corresponds to a third-party content provider.

21. The method ofclaim 19, wherein determining that the content is not stored on the storage system comprises determining that no content on the storage system has a hash that matches a hash of the content.

22. The method ofclaim 16, wherein the device comprises a mobile telephone, a personal digital assistant, or a personal computer.

23. The method ofclaim 16, wherein the content comprises a mobile application program, a mobile ring tone, a mobile wallpaper, video data, audio data, a digital image, a ring back tone, or a combination of these.

24. A method of offering content for a first device comprising:

storing a history of acquisitions associated with one or more entities; and

displaying on the first device offers for content based on the history.

25. The method ofclaim 24, wherein the one or more entities correspond to a user.

26. The method ofclaim 24, wherein the one or more entities correspond to a mobile device.

27. The method ofclaim 24, wherein the offers are for purchasing, subscribing to, licensing, upgrading, or replacing content, or any combination of these.

28. The method ofclaim 27, wherein updated content comprises content that is transcoded or resized from content corresponding to the history.

29. The method ofclaim 24, further comprising automatically receiving replacement or updated content on the first device.

30. The method ofclaim 24, wherein the history is stored at a content provider location.

31. The method ofclaim 30, further comprising polling the content provider location for an acquisition associated with the one or more entities.

32. The method ofclaim 30, further comprising automatically receiving notification from the content provider location of an acquisition for the one or more entities.

33. The method ofclaim 24, further comprising storing metadata about content acquired by the one or more entities.

34. The method ofclaim 34, wherein the metadata comprises a name for content, a description of content, a size of content, a format of content, an encoding of content, an author of content, or any combination of these.

35. The method ofclaim 24, wherein the history comprises a count of license usages.

36. A method of offering content for a device comprising:

displaying a first list of content acquired for one or more entities; and

transmitting one or more items in the first list to a first mobile device.

37. The method ofclaim 36, wherein the one or more items are transmitted in response to selecting the one or more items.

38. The method ofclaim 36, further comprising transmitting the first list to the first mobile device and selecting on the first mobile device the one or more items.

39. The method ofclaim 38, wherein displaying the first list, selecting the one or more items, and transmitting the one or more items are all performed at a location remote from the first mobile device.

40. The method ofclaim 36, further comprising selecting a second list of mobile devices and transmitting the one or more items to the mobile devices in the second list.

41. The method ofclaim 36, wherein the one or more items are transmitted to the first mobile device automatically.

42. The method ofclaim 36, wherein the first list is generated from a history of acquisitions associated with the first mobile device, a second mobile device, or both.

43. The method ofclaim 42, wherein the first and second mobile devices are different.

44. The method ofclaim 42, wherein the first and second mobile devices are the same.

45. A method of configuring a device comprising:

constructing from a first device a link to content on a storage system; and

storing the link on a second device.

46. The method ofclaim 45, wherein storing the link comprises storing the content and data for selecting the content.

47. The method ofclaim 45, wherein the link, the content, or both are stored on the second device during an initial configuration of the second device.

48. The method ofclaim 45, wherein the link, the content, or both are stored on the second device at predetermined time intervals.

49. The method ofclaim 45, wherein the link, the content, or both are wirelessly transmitted from the storage system to the second device.

50. The method ofclaim 45, wherein the second device comprises a mobile telephone, a personal digital assistant, or a personal computer.

51. A mobile device comprising:

a client module containing a link configured to access content and programmed to access the content using the link.

52. The mobile device ofclaim 51, wherein the content comprises a mobile application program, a mobile ring tone, a mobile wallpaper, video data, audio data, a digital image, a ring back tone, or any combination of these.

53. The mobile device ofclaim 51, wherein the client module is programmed to access the content by requesting a copy of the content.

54. The mobile device ofclaim 53, wherein the client module is also programmed to display icons for selecting replacement content for replacing content acquired for the mobile device.

55. The mobile device ofclaim 54, wherein the replacement content comprise an upgrade to content acquired for the mobile device or a different version of the content acquired for the mobile device.

56. The mobile device ofclaim 51, wherein the client module is programmed to wirelessly retrieve the content using the link.

57. The mobile device ofclaim 51, wherein the mobile device comprises a mobile telephone, a personal digital assistant, or a personal computer.

58. A content management system for a mobile device comprising:

a first content module containing content; and

a delivery interface programmed to transfer content from the content module to a mobile device.

59. The system ofclaim 58, wherein the delivery interface is programmed to transfer content from the content module to a mobile device using a link to the content accessible to the mobile device.

60. The system ofclaim 58, wherein the content comprises a mobile application program, a mobile ring tone, a mobile wallpaper, video data, audio data, digital images, a ring back tone, or a combination of these.

61. The system ofclaim 58, further comprising a data store of acquired content.

62. The system ofclaim 61, further comprising a replacement module for mapping acquired content to replacement content.

63. The system ofclaim 58, further comprising an interface programmed to receive content from one or more sources.

64. The system ofclaim 63, wherein the interface is also programmed to poll the one or more sources to determine content acquired for the mobile device from the one or more sources.

65. The system ofclaim 63, further comprising a parser for parsing the content to thereby determine the one or more sources.

66. The system ofclaim 63, wherein the one or more sources are third-party content providers.

67. The system ofclaim 63, wherein the interface comprises a connection module for connecting to sources using Uniform Resource Indicators to the one or more sources.

68. The system ofclaim 63, further comprising an offer module for generating offers for replacement content on the mobile device.

69. The system ofclaim 68, wherein the offer module is programmed to transmit data associated with the offers to the mobile device and the mobile device is programmed to display and select the offers.

70. The system ofclaim 69, wherein the offer module is also programmed to generate the offers from a history of acquisitions for one or more entities.

71. The system ofclaim 70, wherein the one or more entities comprise a user.

72. The system ofclaim 70, wherein the one or more entities comprise a mobile phone.

73. The system ofclaim 63, further comprising a metadata store containing metadata about content.

74. The system ofclaim 73, wherein the metadata comprises information indicating a manufacturer of a mobile device, a version of a mobile device, operating capabilities of the mobile device, or any combination of these.

75. The system ofclaim 74, wherein the operating capabilities comprise a screen size, a number of pixels, or both.

76. The system ofclaim 63, further comprising a Web-based interface coupled to the content manager and programmed to manage the content.

77. The system ofclaim 63, further comprising:

a multimedia content data store;

a user-generated content data store; and

an application data store.

78. The system ofclaim 63, wherein the mobile device comprises a mobile telephone, a personal digital assistant, or a personal computer.

79. A method of storing content for use on a device comprising:

storing content on a storage system accessible to the device; and

storing a link on the device for automatically accessing the content.

80. The method ofclaim 79, wherein the link comprises metadata about the content and a locator to the content on the storage system.

81. The method ofclaim 80, wherein the storage system is on the device.

82. The method ofclaim 80, wherein the storage system is remote to the device.

83. The method ofclaim 82, wherein the locator to the content comprises a Uniform Resource Indicator.

84. The method ofclaim 79, further comprising displaying on the device a digital image for selecting the link.

85. The method ofclaim 79, wherein the content comprises a mobile application program, a mobile ring tone, a mobile wallpaper, video data, audio data, a digital image, a ring back tone selected on a module different from the device, or any combination of these.

86. The method ofclaim 79, wherein the device comprises a mobile telephone, a personal digital assistant, or a personal computer.

Images