KR101439604B1 - System and method for linking pre-installed software to a user account on an online store - Google Patents

Abstract

Disclosed herein are systems, methods, and non-transitory computer readable storage media for associating an application for installation on a computer with a user account on an online store. The method comprising: receiving a software adoption request from a client device, the software acceptance request including an application available for download, an identification associated with the user account and a proof of qualification associated with the software package or user instrumentation, To verify the credentials of the credential by comparing it to the database and, if the credentials are verified, adopts the software package as part of the user account.

Description

SYSTEM AND METHOD FOR LINKING PRE-INSTALLED SOFTWARE IN A USER ACCOUNT ON AN ONLINE STORE. BACKGROUND OF THE INVENTION 1. Field of the Invention < RTI ID = 0.0 >

Cross-references to related applications

This application is a continuation-in-part of U.S. Patent Application No. 13 / 181,424, filed July 12, 2011, entitled " SYSTEM AND METHOD FOR LINKING PRE-INSTALLED SOFTWARE TO A USER ACCOUNT ON AN ONLINE STORE & This application is also a continuation-in-part of U.S. Patent Application No. 13 / 248,942, filed September 29, 2011, entitled " SYSTEM AND METHOD FOR LINKING PRE-INSTALLED SOFTWARE TO A USER ACCOUNT ON AN ONLINE STORE "; This application also claims priority from U.S. Provisional Patent Application No. 61 / 596,928, filed February 9, 2012, entitled " SYSTEM AND METHOD FOR LINKING PRE-INSTALLED SOFTWARE TO A USER ACCOUNT ON AN ONLINE STORE " , All of which are incorporated herein by reference in their entirety.

Technical field

This disclosure relates generally to the distribution of digital products and more specifically to techniques for linking software applications to user accounts on an online store.

Manufacturers of electronic devices usually provide customers with a variety of available options for personalizing and customizing electronic devices prior to purchase. For example, a personal computing device, such as a computer, can be customized by selecting a processor, memory, hard drive, or accessories. Manufacturers also work with various software vendors to provide software applications or programs that can be purchased and preinstalled with the computer before the customer delivers the computer. Some software applications that are typically created by the manufacturer but may also include third party applications may be preinstalled on the computing device, for example, manually or as part of a default factory image for free . Thus, hardware components and preinstalled software can be personalized by the customer to ensure that the purchased product meets the needs of the customer.

After the customer receives the electronic device, the customer may occasionally wish to reinstall or update the software preinstalled in the future. For example, the software provider may have published an updated version of the software preinstalled on the electronic device. This is usually known as a software update. In order to obtain a software update, the customer visits the software provider's physical or online store and purchases or obtains an updated version of the software. However, this process is time consuming and sometimes confusing. Similarly, when a buyer reformats storage of an electronic device, the buyer typically has to reinstall the software. During reinstallation, the buyer may be prompted for various compact discs (CDs) or other media, including preinstalled software. However, the buyer may not have left the CDs in place, which can make the reinstallation procedure very cumbersome.

Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the principles disclosed herein. The features and advantages of the disclosure may be realized and attained by means of the instrumentalities and combinations particularly pointed out in the appended claims. These and other features of the disclosure will become more fully apparent from the following description and appended claims, or may be learned by practice of the principles disclosed herein.

Disclosed are systems, methods, and non-transient computer readable storage media for associating an application (i.e., a software package), a preinstalled application, or a separately purchased application with a user account. User accounts can be associated or stored on the online store. This process can be called adoption. Adoption can provide certain privileges to the user account, such as downloading, re-downloading, and updating of applications. In other instances, the adoption may configure the user account to allow other privileges for the adopted application, such as presenting the adopted applications or selling the adopted applications. In one common scenario, the new computer includes certain preinstalled software. The user can run and use preinstalled software on the new computer. However, in order to receive and / or be entitled to updates, backups, and / or other software-related content or services, the user may " adopt " preinstalled software. By adopting preinstalled software, the preinstalled software is associated with a particular user account, such as an online electronic store account. The online electronic store may then handle updates, backups, restores, in-application purchases, and the like. However, a user may choose to use preinstalled software without " adopting " pre-installed software with full functionality, except for features that rely on access to a user account or an online electronic store account. When a user adopts preinstalled software, the online electronic store may modify the account, the database, and / or the software itself so that the preinstalled software is ineligible for adoption by other users. In other common scenarios, a software package or application purchased by a user, received as a gift, or acquired otherwise is installed on a user's computing device. The computing device may send to the server a software adoption request for the adoption of a software package or application having a user account. The software adoption request may include an indication of the software package and an identifier associated with the user account. In some instances, a proof of entitlement is also included in the adoption request as proof of the authenticity of the software package. The proof of qualification can only be a value that can be derived from owning a software package. For example, the proof of qualification may be associated with or derived from the serial number of the software package. The proof of qualification may also be a value that can be derived from the metadata and software package associated with the electronic device. For example, the metadata associated with an electronic device may be a value that can be derived from hardware associated with the electronic device. Updates, backups, and / or other software-related content or services may be available to the user once the application is adopted.

The system configured to implement the method provides an application available for download, receives a request to download an application to the computing device, and determines that the application is a preinstalled application. The system then provides an authentication prompt configured to request user authentication to link the user account with the application, receives the user authentication, and in response to receiving the user authentication, generates a unique hardware identifier, Search proof of qualification. The system determines that the application is linkable based on the unique hardware identifier or proof of credentials and links the user account with the acceptable application when the acceptable application is linkable. The system may receive a request for an update page, and in response to receiving the request, collect the stub receipt associated with the application to provide an application available for download. The stub receipt can include the version number and name associated with the application. The system then determines based on the version number and name that the update of the application is available on the server for downloading and provides the name of the application.

Alternatively, the system may provide an application available for downloading by receiving a request for a purchase page, receiving a manifest associated with the computing device, and providing a list of pre-installed applications based on the manifest . The manifest may include a list of pre-installed applications available for download from the server if the list of pre-installed applications includes the application. The system may search the application database and compare the version number of the application stored in the application database with the version number of the application stored in the computing device, thereby determining that the application has available updates on the server. Based on the comparison of the version numbers, a determination can be made as to whether an update for the application is present in the application database. The system can determine that the application is a pre-installed application by determining that the application is associated with a stub receipt. The system can receive a manifest associated with the computing device and determine that the application is a preinstalled application by determining that the application is included in a list of preinstalled applications, including a list of preinstalled applications. The system can determine that a preinstalled application is linkable by sending a unique hardware identifier or proof of purchase to the server and determining if the preinstalled application is linked to another user account. In yet another example, the system links a pre-installed application with a user account by associating a pre-installed application with a user account and updating the uniqueness table to include a unique hardware identifier or proof of purchase. The uniqueness table may include other unique hardware identifiers or proof of purchase associated with other electronic devices having other pre-installed applications, and other pre-installed applications may be linked to other user accounts.

In another variation, the system receives a request to link a pre-installed application with a user account on an online store, and the online store is configured to send an application associated with the user account to one or more computing devices associated with the user account. The system then generates a unique hardware identifier or proof of purchase associated with the computing device and determines that the preinstalled application is linkable based on the unique hardware identifier or proof of purchase. The system links the user account with the pre-installed application when the pre-installed application is linkable. The unique hardware identifier may be based on one or more hardware components of the electronic device, such as a MAC address, a universal device identifier (UDID), a logic board serial number, or an Ethernet hardware address. In other instances, a proof of purchase may be used. The proof of purchase may be based on the hardware components of the electronic device, the metadata associated with the purchase, purchase, or acquisition of the application. Determining that a preinstalled application is linkable may include sending a unique hardware identifier or proof of purchase to the server, and determining whether a proof of preinstalled application or purchase is linked to another user account. The system may determine that the preinstalled application is linkable by determining that the original configuration of the computing device includes an application preinstalled. Linking a pre-installed application with a user account may involve associating a pre-installed application with a user account, updating the uniqueness table to include a unique hardware identifier or proof of purchase, Another unique hardware identifier or proof of purchase associated with another electronic device having a different pre-installed application, and other pre-installed applications linked to other user accounts. In another example, linking a pre-installed application with a user account further includes removing metadata associated with the pre-installed application from the manifest, and the manifest is configured to enumerate pre-installed applications that are already linked with the user account do. The system may download pre-installed applications to the computing device.

A more particular description of the principles set forth above will be given with reference to specific embodiments thereof, which are illustrated in the accompanying drawings, in order to describe the manner in which the above and other advantages and features may be achieved. It is understood that these drawings depict only exemplary embodiments of the disclosure and are not therefore to be considered to be limiting of its scope, and that the principles herein may be better understood by reference to the following description and drawings, .
Figure 1 illustrates an exemplary system embodiment.
Figure 2 illustrates an exemplary application distribution system.
3 illustrates an exemplary client-server system.
Figure 4 illustrates an exemplary method for processing an update page request.
Figure 5 shows an example of an HTML page associated with an update page request.
Figure 6 shows an example of an HTML page requesting user authentication to employ pre-installed applications.
Figure 7 shows another example of an HTML page requesting user authentication to employ pre-installed applications.
FIG. 8 illustrates an exemplary method for processing a purchase page request.
Figure 9 shows an example of an HTML page associated with a purchase page request when the user is not signed.
Figure 10 shows another example of an HTML page associated with a purchase page request when signed by a user.
Figure 11 shows another example of an HTML page associated with a purchase page request that includes an authentication prompt.
Figure 12 illustrates an exemplary method for linking an application preinstalled in a user account.
Fig. 13 shows an example of an adoption warning.
Fig. 14 shows another example of the adoption warning.
15 illustrates an exemplary process for a recovery mode in an electronic device.

Various embodiments of the present disclosure are discussed in detail below. While certain implementations are discussed, it should be understood that this is done for illustrative purposes only. Those of ordinary skill in the pertinent art will recognize that other components and configurations may be utilized without departing from the spirit and scope of the disclosure.

This disclosure addresses the need in the art for associating pre-installed software on electronic devices with user accounts on distribution centers or on-line stores. The present disclosure also addresses the need in the art for associating other types of software with user accounts other than preinstalled software. For example, software purchased, software received as a gift, software distributed free or in small amounts from a software manufacturer, or software acquired using other methods may be associated with a user account on an online store or shop. This process can be referred to as "adoption" of the software by the user account in the online store. By associating software with user accounts on an online store, software updates and re-installations can be downloaded from an online store and thus proved to be an easier and more convenient way of managing software on an electronic device. In addition, other computing devices associated with the user account may also receive software updates and reinstallations from an online store. The following description in FIGS. 1-15 is applicable to pre-installed applications, software packages, and applications acquired through other means (e.g., gifts, purchases, or otherwise distributed or acquired). As such, the term "pre-installed application " as used herein may be used interchangeably with a gift application, a purchased application, a distributed application, an acquired application, and others . In other words, "preinstalled application" may be any application for which the user has ownership. Similarly, a "unique hardware identifier" may be any unique identifier that is configured to provide ownership or proof of credentials to an application installed on a computing device. For example, the proof of credentials may be a unique value for every copy of the application being created. The proof of qualification may also be a redemption code for redeeming the application. In other examples, the proof of qualification may be a combination of unique and non-unique values, such as combining a unique identifier associated with a (unique) user account and a redemption code (which may not be unique). A brief introduction of a basic general purpose system or computing device that can be used to implement the concepts is illustrated in FIG. A more detailed description of how the preinstalled software is associated with the user account will follow and includes several variations as various embodiments are described. The disclosure now looks at Figure 1.

1, an exemplary system 100 includes a processing unit (CPU or processor) 120, and a read only memory (ROM) 140 and a random access memory (RAM) Includes a general purpose computing device 100 that includes a system bus 110 that couples various system components including the system memory 130, such as a processor 150, to the processor 120. The system 100 may include a cache 122 of high-speed memory that is directly connected to, is in proximity to, or is integrated as part of the processor 120. [ The system 100 copies data from the memory 130 and / or the storage device 160 to the cache 122 for quick access by the processor 120. [ In this way, the cache provides a performance boost that avoids processor 120 delays while waiting for a date. These and other modules may be configured to control or control the processor 120 to perform various actions. Other system memory 130 may also be available for use. The memory 130 may comprise a plurality of different types of memory having different performance characteristics. It will be appreciated that the present disclosure may operate in a computing device 100 having more than one processor 120 or in a group or cluster of computing devices that are networked together to provide greater processing capability. Processor 120 may include any of a number of general purpose processors and module 1 162 that is stored in storage device 160 that is configured to control processor 120 as well as special purpose processes in which software instructions are contained within an actual processor design, 2 164, and module 3 166, as shown in FIG. The processor 120 may be essentially a fully self-contained computing system including a plurality of cores or processors, a bus, a memory controller, a cache, and the like. The multicore processor may be symmetric or asymmetric.

The system bus 110 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The basic input / output (BIOS) stored in the ROM 140 or the like may provide a basic routine that helps to transfer information between elements within the computing device 100, such as during start-up. The computing device 100 further includes storage devices 160 such as hard disk drives, magnetic disk drives, optical disk drives, tape drives, and the like. The storage device 160 may include software modules 162, 164, 166 for controlling the processor 120. Other hardware or software modules are contemplated. The storage device 160 is connected to the system bus 110 by a drive interface. The drives and associated computer-readable storage media provide non-volatile storage of computer-readable instructions, data structures, program modules and other data for computing device 100. In one aspect, a hardware module that performs a particular function may be coupled to the required hardware components, such as processor 120, bus 110, display 170, and the like, to perform the function and stored in non-transitory computer readable media Software components. Basic components are known to those of ordinary skill in the art and suitable modifications are contemplated depending on the type of device, such as whether the device 100 is a compact, handheld computing device, desktop computer, or computer server.

Exemplary embodiments described herein use hard disk 160 but may include magnetic cassettes, flash memory cards, digital versatile disks, cartridges, random access memories 150, , Read only memory (ROM) 140, and other types of computer readable media capable of storing computer accessible data, such as a wireless signal, including a cable or bit stream, may also be used in an exemplary operating environment As will be appreciated by those of ordinary skill in the art. Non-transient computer readable storage media explicitly exclude media such as energy, carrier signals, electromagnetic waves, and signals themselves.

To enable user interaction with the computing device 100, the input device 190 may include a microphone for speech, a touch sensitive screen for gestures or graphical input, a keyboard, a mouse, motion input, speech, Represent any number of input mechanisms. The output device 170 may also be one or more of a number of output mechanisms known to those of ordinary skill in the art. In some instances, multi-mode systems allow a user to provide multiple types of input to communicate with the computing device 100. Communication interface 180 generally governs and manages user input and system output. Rather than being limited to operating on any particular hardware arrangement, the basic features can therefore be readily replaced with enhanced hardware or firmware arrays as they are developed here.

For purposes of clarity of explanation, the exemplary system embodiment is provided as including a "processor" or individual functional blocks including functional blocks labeled with the processor 120. [ The functions represented by these blocks include, but are not limited to, hardware that is capable of executing hardware and software, such as processor 120, which is purpose-built to operate as equivalent to software running on a general purpose processor May be provided through the use of shared, dedicated hardware. For example, the functions of the one or more processors shown in FIG. 1 may be provided by a single shared processor or multiple processors. (The use of the term "processor" should not be construed as referring exclusively to hardware capable of executing software.) Exemplary embodiments include microprocessor and / or digital signal processor A read-only memory (ROM) 140 for storing software that performs the operations discussed, and a random access memory (RAM) 150 for storing results. Very large scale integration (VLSI) hardware embodiments and a custom VLSI circuit that combines with a general purpose DSP circuit may also be provided.

The logical operations of various embodiments include (1) a sequence of computer-implemented steps, operations, or procedures driven in a programmable circuit in a general purpose computer, (2) computer-implemented steps, Operations, or sequences of procedures, and / or (3) interconnected machine modules or program engines within the programmable circuits. The system 100 shown in FIG. 1 may implement all or part of the described methods and may be part of the described systems and / or may operate in accordance with instructions in the described non-transient computer readable storage medium have. These logical operations may be implemented as modules configured to control the processor 120 to perform certain functions in accordance with the programming of the module. For example, Figure 1 illustrates three modules, Mod1 162, Mod2 164, and Mod3 166, which are modules configured to control the processor 120. [ These modules may be stored in the storage device 160 and loaded into RAM 150 or memory 130 at execution time or may be stored in other computer readable memory locations as known in the art.

Discloses some components of a computing system and the disclosure now links preinstalled software on a computing device, such as a personal computer, laptop, game console, smart phone, mobile phone, or tablet PC, to a user account in an online application distribution store or marketplace Link, or adoption) of the techniques described herein. The approaches disclosed herein may improve the efficiency and convenience of updating or reinstalling preinstalled software on a computing device by linking the preinstalled software with a user account on an online distribution site, such as an online store or distribution center. The online distribution site sends the preinstalled software associated with the user account to one or more computing devices that are linked to the user account. Both the preinstalled software and the updates to the preinstalled software can be sent to one or more computing devices. In some instances, the distribution site may specify a limit on the number of computing devices associated with a given user account that can receive software associated with a given user account. In other instances, preinstalled software is part of a standard 'image' that is generated once and duplicated in each of a group of devices. For example, a standard device 'image' may include an operating system, drivers, programs, settings, and the like. Thus, each imaged device has the same software configuration, including preinstalled software, and after the end user (or other entity) has set up the device, the preinstalled software is used and associated with the user account of the online store or marketplace .

Figure 2 illustrates an exemplary application distribution system. In this example, the distribution system 200 includes a distribution center 210, an application database 220, a configuration server 230, the Internet 250 or other network, a computing device 260, a computing device 270, (Not shown). Together, the distribution center 210, the application database 220, and the configuration server 230 may represent different independent components of the server-side 240 of the client-server model. Similarly, the computing device 260, the computing device 270, and the portable device 280 may represent different independent components of the client-side model 290 of the client-server model. Thus, a broad overview of the distribution system 200 includes a server side 240 that communicates with the client side 290 over the Internet 250. By way of example, the server side 240 may be represented to the user as an online store for the sale and distribution of applications or multiple cloud servers. The device from client side 290 may communicate with the online store using an application management computer program stored on the device. In other instances, the Internet 250 may be replaced by other communication networks such as computer networks, telephone networks, Ethernet, local area networks, wired networks, wireless networks, and the like.

The computing device 260 may include applications 261. [ Applications 261 may include applications that are provided as part of a package, or pre-installed on computing device 260, provided with some kind of installation media. In one common scenario, the owner of the computing device 260 has purchased a computing device 260 with these applications already installed from the manufacturer. Applications 261 also include applications (or software packages) acquired by computing device 260 via some other means, such as, for example, gifts, purchased, or distributed applications can do. The applications 261 may also include applications purchased from the distribution center 210 by a user of the computing device 260. In order to purchase the desired applications from the distribution center 210, the user may include metadata associated with the applications already purchased by the user and metadata associated with payment information for payment to the distribution center 210 in return for desired applications And logs in to the user account 291. Once logged in, the user can select the desired application for purchase. When the user agrees to pay the purchase price of the application, the payment information of the user is used to complete the transaction. Once the transaction is complete, the desired application is associated with the user account 291, thus allowing the user to download the desired application and also the desired application updates. Applications associated with user account 291 may be updated or re-downloaded for other devices associated with user account 291. [

In some instances, the user may have the option not to associate an application with a user account at this point. For example, a user who receives an application as a gift may not have a user account or may not wish to associate an application with his user account. In the first scenario, the computing device 260 may allow a user to install an application without requiring the user to set up a user account. A user may select a user account and link (i.e., adopt) his / her user account with the application if the user wishes to install the application or receive updates on other electronic devices he owns. In this example, computing device 260, computing device 270, and portable device 280 are all associated with user account 291, and thus are responsible for all of the applications associated with user account 291, Lt; / RTI > In addition, the portable device 280 may communicate with the computing device 270 to transfer digital data and applications between the two devices. In one example, the computing device 270 may be configured to be a central repository containing all the applications associated with the user account 291 and may transmit the selected applications to the portable device 280. In this specification, the term "application" refers to a copy of a software program or application provided by a software provider. In other examples, software applications and software programs (e.g., system software, enterprise software, multimedia files, video files, audio files And image files) may also be associated with the user account 291 and distributed / redistributed by the distribution center 210.

The distribution center 210 coupled to the application database 220 is configured to sell, deliver, and maintain applications from the application database 220. The application database 220 may be configured to store some or all of the applications available for distribution from the server side 240. The applications may be sold, updated, and delivered (i.e., transmitted) to the device on the client side 290 via the Internet 250. As such, the distribution center 210 represents an online store for applications. For example, the application database 220 may receive a request for an application from the distribution center 210 and, in response to the request, send the requested application to the distribution center 210, And transmits the application to the requesting device. The requested applications may be applications available for purchase or applications previously associated with a user account (i.e., adopted separately acquired or preinstalled applications). In other examples, application database 220 may send the requested application directly to the requesting device. In another example, the application database 220 may reside on the client side 290 and the server side 240 may provide access to specific applications of the application database 220 based on applications associated with the user account Can grant.

The device on the client side 290 may send a software adoption request to link (i.e., associate or adopt) a preinstalled application on the device or an otherwise acquired but not adopted application with the user account. Linking an application allows a user to associate an application with a user account, thus allowing a user to download an application to other devices that are also associated with the same user account. This process can be said to "link", "adopt", or "associate" an application. For example, the computing device 260 may request to link an application from applications 261 with a user account 291. The request may include a unique identifier (e.g., a unique hardware identifier) associated with the application or computing device 260 to the distribution sensor 210 via the Internet 250 to determine if the application can be associated with the user account 291. [ ≪ / RTI > The unique hardware identifier is a unique identifier based on the hardware of the device used to distinguish a particular device from all other devices. For example, a manufacturer can ensure that each device manufactured is unique and thus contains a unique hardware identifier that is different from the unique hardware identifier of any other device. By way of example, the unique hardware identifier may be based on the logical board serial number and / or the Ethernet hardware address of the device. In one example, these two values may be concatenated and hashed to produce a unique hardware identifier. In other examples, other metadata specific to the device may be joined, scrambled, or otherwise combined using various data manipulation algorithms to form a unique hardware identifier. In yet other instances, the unique identifier used to determine whether an application can be associated with a user account 291 serves as evidence that the application (i.e., software package) associated with the unique identifier is legitimately obtained from the software manufacturer And may be based on any other proof of purchase or qualification possible. In one case, the unique identifier may be derived from the metadata or attributes associated with the application. In other cases, the unique identifier may be derived from metadata associated with the application, client device, user account, other client devices associated with the user account, or a combination of one or more of the above.

In one embodiment, the distribution center 210 receives the unique identifier and processes or analyzes the unique identifier to determine if the application can be associated with a user account. In certain scenarios, an application can not be associated with a user account. For example, an application on a device may not be associated with a user account if the application was previously associated with another user account. As another example, an application may not be associated with a user account if the application is not an authenticated copy. This can happen when you manually copy an application originally installed on one device to another. As another example, the association process may require that a user be logged into the user's account on the electronic device so that the application is linked to the user account.

In another embodiment, the distribution center 210 receives a unique identifier and processes or analyzes the unique identifier to determine if the application can be associated with a user account. As an example, processing the unique identifier may include verifying the unique identifier by comparing the unique identifier with the database. The database may have a plurality of entries, each storing a unique identifier associated with an authenticated copy of the application. The result of the comparison can be used to determine the adoption state of the application, such as whether the application is a valid copy, whether the application is an invalid copy, or the application is already associated with a user account. As another example, processing the unique identifier may include entering a unique identifier into the hash table to determine the adoption state of the application. In yet another example, the unique identifier may be received as input to a validation engine that determines whether such an installation of the application is valid and has not been adopted yet. In other instances, other data processing techniques may be applied to unique identifiers to determine if an application can be associated with a user account. The application may be recently obtained by the user. In other words, the application may have been acquired by the user after purchase and acceptance of the electronic device from distribution or manufacture. Alternatively, the application may be obtained when the electronic device is purchased. Once the adoption state has been determined by the distribution center 210, an acknowledgment according to the adoption state can be sent to the electronic device. The confirmation may be sent to inform the electronic device of the state of the adoption process. Based on the confirmation, the electronic device may request a download of the software package or an update of the software package. In other examples, the distribution server 210 may automatically initiate a process of downloading a software package or updating a software package to an electronic device, depending on the adoption state.

The server side 240 may include a number of servers and tables to determine if the link request is to be authenticated. For example, the distribution center 210 includes a uniqueness server 211 configured to process a unique identifier to determine the validity or legality of the link request. The uniqueness server 211 may include a uniqueness table configured to maintain a table or database of electronic devices having one or more pre-installed applications linked with the user account. By way of example, the uniqueness table can be configured to store unique hardware identifiers of devices that have already linked user accounts and their pre-installed applications (i. E. Devices that already have pre-installed applications associated with the device). The uniqueness table may also be configured to store metadata associated with applications associated with the user account. When the device adopts (i.e., links) some or all of the user account and its applications, the device's unique hardware identifier or the unique identifier of the adopted application is stored in the uniqueness table. This prevents future requests to link already adopted applications. For example, performing a lookup as to whether a unique identifier is in the uniqueness table determines whether the device associated with the unique hardware identifier has already linked its pre-installed applications with the user account. Similarly, the query can also determine if the application associated with the unique identifier has already been linked to the user's account. As another example, the uniqueness table may be configured to store a unique hardware identifier of the electronic device along with metadata associated with one or more preinstalled applications of the electronic device previously adopted (i.e., linked with the user account). In other words, the uniqueness device is configured as a one-to-many mapping between the unique hardware identifier of the device and one or more metadata associated with the pre-installed applications of the selected device. Querying the uniqueness table for the unique hardware identifier can not return anything if the unique hardware identifier does not exist in the uniqueness table and can not return anything if the unique hardware identifier is present in the uniqueness table, ≪ / RTI > < RTI ID = 0.0 > This may result in the ability to selectively employ a first user account and a pre-installed application on the device and a second user account and other pre-installed applications on the device. In yet other examples, the uniqueness table may be configured to maintain a table or database of applications linked to the user account. The already linked applications can have a unique identifier stored in the uniqueness table, thereby keeping the latest database of the adopted applications.

In an example, the configuration server 230 may validate the link request by checking the original configuration of the electronic device to verify or determine that the particular application was pre-installed on the electronic device when the device left the manufacturer. The configuration server may also verify or identify applications for which the user has ownership, whether the application is installed on a user device or associated with a user account. Thus, applications that have ownership but are not associated or installed by the user can also be identified. The configuration server 230 includes a database that stores the original configuration of the electronic devices created by the manufacturer. The original configuration may include the version of the operating system and, if present, the version of the electronic device and delivered applications. For example, a user who orders an electronic device through an online store may configure a device with one or more applications at the time of purchase. Applications are installed on the electronic device by manufacturing based on the configuration at the time of purchase. The manufacturer forwards the configuration of the electronic device to the configuration server 230 for subsequent retrieval. When the configuration server 230 receives a search request that includes a unique hardware identifier from the electronic device, the configuration server 230 performs a search or lookup in the database and returns a list containing the versions of the applications installed on the electronic device, / / Returns the version of the operating system installed on the device. The configuration server 230 may determine the application that the user is attempting to associate with the user account and the list of installed applications to determine whether the application the user is attempting to associate with is an authenticated installation or previously associated with another user account Can be compared. Alternatively, the configuration server 230 may communicate a list of pre-installed applications to the distribution center 210 to determine if the link request should be granted. This check can prevent users from dodging the distribution system 200 by copying pre-installed applications from one device to another.

Once one or more elements of server side 240 validate the link request, the pre-installed application is associated with a user account (i.e., application adoption). In addition, the uniqueness server 211 or the configuration server 230 may be updated to account for application adoption. For example, a new entry may be added to the uniqueness table of the uniqueness server 211, because some or all of the pre-installed applications associated with the electronic device may have been adopted. In some instances, the distribution center 210 may send an update of the preinstalled application to the computing device 260 after the preinstalled application is associated with the user account. In other instances, the distribution center 210 may send an application previously installed to other devices associated with a user account, such as the computing device 270, even though the computing device 270 was not originally configured as a preinstalled application. Pre-installed applications of the computing device 270 stored in the applications 271 and pre-installed applications of the portable device 280 stored in the applications 281 through similar requests for application adoption are stored in the user account 291, And may eventually be distributed to the computing device 260, the computing device 270, and / or the portable device 280.

3 illustrates an exemplary client-server system. The client-server system 300 includes a client device 350 and a server 360. Server 360 may be configured to respond to requests from client device 350 and may include one or more elements from server side 240 of FIG. The client device 350 may associate (pre-installed or otherwise acquired) applications with the user account by submitting page requests to the server 360. [ The client device 350 may also associate the user account with other applications by submitting the same or similar page requests to the server 360, such as in pre-installed applications.

One type of page request is an update page request (301). The update page request 301 may be a request sent to the server 360 to perform an inquiry for available application updates. In response to the update page request 301, the server 360 returns a HyperText Markup Language (HTML) page 303 configured to notify the user about the applications stored in the client device 350 with the available updates . In some instances, the server 360 may return metadata to the client device 350, and the client device 350 also generates an HTML page and presents it to the user. Update page request 301 may include a digital receipt for each application stored in client device 350. [ The receipt includes metadata associated with the application to document the purchase or ownership of the software. One type of receipt is the actual receipt associated with the adopted applications or purchased applications. The actual receipt may include a description of the application, the version number of the application, when the application was purchased, information about the person who purchased the application, information about the device where the application was initially installed, and the like. In other words, the actual receipt is proof of the purchase unique to the electronic device and / or buyer for which the application was purchased. Another type of receipt is a stub receipt. Stub receipts contain a subset of the information in the actual receipts, and are part of the application when the application is not adopted with a user account. In one example, the stub receipt uniquely identifies a copy of this application from other copies. This may allow the server to determine if this particular copy of the application (presented to the user or otherwise obtained by the user) can be adopted by the user. In another example, stub receipts are generated by the manufacturer as receipts to be associated with pre-installed applications. In order to facilitate and simplify the installation of applications by the manufacturer, stub receipts may contain a minimum amount of information that is smaller than actual receipts. For example, the stub receipts may include an application identifier identifying the application to the server and also a version number identifying the version of the application. The application identifier may be a name associated with the application. The stub receipt may not contain information specific to the buyer when the application was purchased, such as information about the person who purchased the application or the device on which the pre-installed application is installed. In other words, the stub receipt may not include user accounts, user account information, or information about a client device, computing device, or other device. The application identifier may be a name associated with the preinstalled application. In some instances, stub receipts are generated by the manufacturer when applications are preinstalled on the device or when the device is being prepared for delivery. In other instances, stub receipts may be generated by the server 260 and subsequently transmitted to the client device 350 to be associated with the pre-installed application. Server 360 may generate stub receipts in response to periodic scheduled communications between server 360 and client device 350 or requests by client device 350. [ Once the pre-installed application is adopted, the stub receipt can be replaced with an actual receipt. In another example, the stub receipt is generated as a receipt to be associated with a purchased, presented, or otherwise acquired application that is not associated with the client device when the application is acquired. This stub receipt can be generated by a manufacturer, an application distributor, an online store, or the like. In some cases, the stub receipts may be batches that are processed and assigned to applications for distribution. Stub receipts are stored on the server and used to authenticate the acceptance requests. As in the previous example, the stub receipt can be replaced with an actual receipt during the application adoption process. The actual receipt may be generated by the client device 350, the server 360, or other elements of the client-server system 300.

In this example, the update page request 301 includes a stub receipt A 311 associated with the pre-installed application 310, a stub receipt B 321 associated with the pre-installed application 320, and an actual receipt associated with the application 330 (331). The application 330 was purchased from the server 360 after purchase of the client device 350 and thus contains the actual receipt. In response to the update page request 301, the server 360 may determine whether the pre-installed application 310, the pre-installed application 320, or the application 330 has available updates that can be downloaded from the server 360 And generates HTML 303 informing the user. An available update associated with a pre-installed application that is not adopted (i.e., linked or associated with a user account) can not be downloaded until the pre-installed application is adopted with the user account. Once an available update has been downloaded and installed on the client device 350, the stub receipt will be displayed at the time the application was purchased (i.e., the date the available update was installed), the user who purchased it, It can be replaced with an actual receipt containing other metadata.

Another type of page request is a purchase page request 302. Purchase page request 302 may be sent to server 360 to request a list of applications purchased by a user of client device 350. [ In response to the request, the server 360 returns an HTML page 303 that is configured to inform the user about the applications purchased by the user of the client device 350 and, optionally, the applications installed on the client device 350 can do. Purchased applications that are not stored in the client device 350 can be downloaded and installed. HTML page 303 may also include applications available for adoption (i.e., linking or associating with a user account). Applications on the client device that are not associated with a user account may be selected for adoption via an update page request 301 or alternatively via a purchase page request 302. [ Unapproved applications may send receipts or other forms of proof of qualification to a request to install an application or a desired application on a client device.

The purchase page request 302 may include a manifest 340. The manifest 340 can be configured to store information associated with pre-installed or otherwise acquired applications. This information can be used by the server 360 to inform the user about the applications available for adoption. The manifest 340 includes a list, table, or other data structure that is configured to store the version number of the applications of the client device 350. The version number of the application may be found in stub receipts or other metadata associated with the application. In one example, the manifest 340 is generated at the first time that the client device 350 starts up. For example, the manifest may be generated during the first boot of the client device by utilizing a spotlight (i.e., search) function on the client device to retrieve the computer for stub receipts, which in turn creates a manifest . The manifest may be stored in the configuration server to be accessed during the link of the user account and the application or during the recovery mode of the electronic device to be discussed below.

In this example, the client device 350 is subsequently queried to deploy the stub receipt 311 and the stub receipt 321 used to create the manifest 340. During the reformatting or recovery of client device 350, both head-on and otherwise acquired applications may be deleted from client device 350. Applications linked with the user account may be downloaded again to the client device 350. [ However, pre-installed applications that are not linked to user accounts are at risk of being completely lost. The manifest 340 serves as a mechanism to prevent the loss of unapplied applications, as will be described in more detail below. Applications available for adoption can not be downloaded until a pre-installed application is linked or associated with a user account. Once the available updates are downloaded and installed on the client device 350, the manifest 340 can be edited to remove the stub receipts associated with the currently adopted application. Also, the installed application includes the actual receipt. In some examples, the occurrence of the update page request 301 and purchase page request 302 along with processing and retrieval of the HTML page 303 is managed by an application management program (not shown) installed in the client device 350 It is treated. The application management program may be proprietary to the manufacturer and may be configured to specifically communicate with servers belonging to the manufacturer.

The client-server system 300 also includes a client device 350 that is obtained by the client device 350 but is not associated with a user account (e.g., presented or purchased, but not linked to a user account, Lt; / RTI > applications). As an example, the acquired application may be linked with a user account via an update page request, a purchase page request, or another page request. The request may include metadata derived from a stub receipt or a stub receipt or from a stub receipt. As another example, the manifest 340 may be updated when unapproved applications (i. E., Applications not yet linked to a user account) are acquired by the client device 350.

4 illustrates an exemplary method for processing an update page request. A method 400 of illustrating actions performed by a client and a server may be configured to manage communications between a client and a server during an update page request. Actions performed by the server may be executed by a distribution program stored in another component located at the distribution center or server side, and actions performed by the client may be executed by an application management program stored in the client ' s electronic device. The method 400 may begin with a user selecting an update tab link in a graphical user interface provided by the client device. An exemplary update tap link may be a link 451 in FIG. Once the client receives 401 a user request for an update page, the client queries or retrieves 403 the client device for receipts or other types of proof of entitlement associated with applications installed on the client device. In other examples, the query can be started automatically without user interaction. For example, the server may initiate a query by communicating with the client at a predetermined time interval or point in time. The retrieval may be performed using a function associated with an application or routine stored on the client device's operating system or, alternatively, on the client device. A copy of the receipts or receipts found is sent to the server (405). Receipts can be transmitted over any communication network, such as Ethernet, Internet, local area networks, and the like. The server receives receipts and processes them to determine if the applications associated with the receipts have updates (407). This may include accessing an application database, such as application database 220 of FIG. 2, and comparing the version number of the receipt with the version number of the application stored in the application database. This may also include verifying that the application is eligible for adoption by determining that the application installed on the client device is configured for distribution by the server. In some embodiments, the server may also verify that the application has not previously been adopted at this time, which may include retrieving a unique identifier (from a server or client) that uniquely identifies a copy of the installed application and And verifying that the unique identifier is not associated with any user account. The list of applications with updates may be used to create an HTML page 408, or to manipulate some other user interface, such as a desktop application or a smartphone application. The HTML page may include information related to applications having available updates. This information may include an original purchase date of the application, a description of the application, and a description of changes or modifications in the updated application. HTML is only one example of a notification that may be sent to a client to notify a client that one or more applications have updates or are available for adoption. The server can then send the HTML page to the client (409). In some instances, the server may send an HTML page over the same channel to which the client has sent receipts. The server may alternatively send enough information to the client to update the locally installed client application rather than pre-packaging and sending the HTML page to the client.

Figure 5 illustrates an example of an HTML page associated with an account of a user of an online store or marketplace and an update page request for a preinstalled application associated with or associated with it. The HTML page 450 includes an update link 451 that can be selected by the user to request an update page. Update links 451 may include "featured", "top charts", "categories" to provide a convenient and quick way for a user to access different features of an application management program, &Quot; and "purchases ". In some instances, the icon representing the update link 451 may include a number that specifies the number of applications stored on the client device with the available updates. The number in the icon may be generated before the user selects the update tab link 451 through the periodic communication between the server and the client device.

For example, the client device may periodically communicate with the server and retrieve the most recent version number of stored applications with available updates. In this example, an update link 451 has been selected, and one application containing the available updates is presented in the HTML page 450. One application is presented with an application description 457 describing the application. The application description 457 may include the name of the application, the author of the application, the version number of the application, the date of publication of the application, or other information associated with the application. The application description 457 may further include an icon 455 providing an identity for the application and a synopsis 459 of changes implemented in this updated version of the application. This can provide information to the user to make a wise decision about whether he wants to upgrade. The HTML page 450 also includes a selectable link 461 that may be selected by the user if he desires to receive the application update. The number of available updates is displayed in the headline 453. The headline 453 is configured to provide another convenient location where the user can quickly determine the number of available updates. In some instances, the HTML page 450 may also include a selectable link next to the headline 453 to update all applications with available updates.

Returning to FIG. 4, the client receives the transmitted HTML page and presents the HTML page to the user (411). As discussed in FIG. 5, the HTML page presents a graphical user interface that enumerates applications with available updates, a description of applications, and one or more links selectable by the user to authenticate an update of the application. The client may receive a user certificate to update the application (413). If user authentication has been received, the client may determine 415 whether the application requires adoption before the application can be updated. This may include inspecting the receipt of the application installed on the client to determine if the receipt is a stub receipt. If the receipt is a stub receipt, the application associated with the stub receipt is potentially a pre-installed application that has not yet been adopted into the user account. Thus, user authentication may be required and the client may present the HTML page to the user requesting user authentication (417) to adopt or associate the application with the user account. User authentication may involve the transmission of personal information over a communication network. For privacy reasons, the HTML page informs the user that personal information will be sent during the authentication process and requests permission to transmit this personal information over the communication network.

Figure 6 illustrates an example of an HTML page requesting user authentication to employ applications, which may be additionally provided and / or pre-installed with the purchase of a computing device. HTML page 470 is an update page that presents four applications with updates available to the user. As such, the icon of update link 471 includes number "4 ". In this example, the user has selected to update all of the applications via a "Update All" However, in other examples, the user may also choose to update a single application by selecting one of update links 476, 477, 478, or 479. [ Applications with available updates include pre-installed applications 472 and purchased applications 473. In some instances, there is no difference in presentation of pre-installed applications and purchased applications at this stage. However, once the user selects to update an application that is pre-installed or otherwise unlinked from the user account, the HTML page 470 may prompt the user 480. The prompt 480 is described in more detail in FIG.

Figure 7 illustrates another example of an HTML page requesting user authentication to employ applications. A prompt 480, also known as an authentication prompt, is presented to the user when the user is preinstalled on the computer and possibly chooses to update the acquired application that is not associated with the user account or simply with the user account. In this example, the prompt 480 includes an icon 481, a login 482, a password 483, a password assistance 484, a description 485, a help link 486, An account creation 487, a cancel 488, and a sign in 489. The description 485 provides textual information to inform the user that preinstalled (i.e., additional bundled) applications on this electronic device will be associated with the user account if the user wishes to update the applications. The description 485 may also inform the user that to adopt the application, a unique hardware identifier associated with the electronic device is sent to the server to determine whether application adoption should be authenticated. The icon 481 may be used to brand an application update function of the application management program. The login 482 and the password 483 may specify a user account that the user prefers to have the pre-installed application associated. The password assistance 484 may be selected by the user requesting assistance for the password. Once the desired user account has been entered and the correct password has been entered, the user can begin the adoption process by selecting the signature at 489. If the user does not have a user account, or if the user wishes to associate pre-installed applications with a new account, the user can select account creation 487. If the user desires to cancel and does not wish to update the application (s), the user may choose to cancel 488. If the user desires a more detailed description of any of the elements described above instead, the user may select the help link 486. In other instances where an HTML page is not pre-installed on an electronic device but instead requests user authentication to associate applications separately acquired by the electronic device, the description 485 may be modified to convey the appropriate message to the user . For example, the description 485 states "that in order to receive future updates, applications X, Y, and Z will be assigned to this Apple ID. "To receive future updates, applications 'X', 'Y', and 'Z' will be assigned to this Apple ID. A unique identifier must be stored on your computer to be sent to Apple verify eligibility).

Returning to FIG. 4, the client may receive a user certificate to adopt the application (419). This user authentication may be received by the user entering a user account and password into the prompt presented by the client as described in FIG. Once user authentication has been received by the client, the client may continue to adopt the application (421). An exemplary process for adapting an application to a user account is described in FIG. 12 below. In some instances, all pre-installed applications must be associated with a user account at the same time. Thus, a user can not selectively link one pre-installed application associated with an electronic device having a single user account, and can not selectively link another pre-installed application associated with an electronic device having a different user account. Adopting all the pre-installed applications on the electronic device at the same time can simplify the computational overhead in managing the adoption process because the unique hardware identifier associated with the electronic device is sufficient to inform the server that pre- It is because. In other instances, the pre-installed applications on the electronic device may be selectively associated with a plurality of accounts. Thus, a first pre-installed application can be associated with a first electronic device, and a second pre-installed application can be associated with a second electronic device. However, management of pre-installed applications on the server may require storing pre-installed applications plus adopted hardware identifiers of the electronic devices. These examples are also applicable to applications that are acquired separately from purchasing electronic devices. For example, bundles of the gift-installed applications on the electronic device may be associated with the user account individually or in groups.

Figure 8 illustrates an exemplary method for processing a purchase page request. A method 500 for illustrating actions performed by a client and a server may be configured to manage communications between a client and a server during a purchase page request. Actions performed by the server may be executed by a distribution program stored in a distribution center or other component placed on the server side, and actions performed by the client may be executed by an application management program stored in the electronic device on the client side. In some instances, the distribution program stored in the distribution center and the application management program stored in the electronic device may be configured to also perform the method 400 of FIG. 4 during an update page request. The method 500 may be initiated by a user selecting a purchase tap link in a graphical user interface supplied by the client device. An exemplary purchase tap link may be a link 551 in FIG. When the client receives 501 a user request for a purchase page (501), the client may perform a search or lookup for the application information. In this exemplary method, the application information may include a manifest and / or receipts (503). In other examples, the application information may include an application or software package that is not associated with a user account, wherein the user account has ownership of the software package. Ownership may be proof of eligibility, such as a digital receipt. In some instances, the manifest may be similar or substantially similar to the manifest 340 of FIG. Search or query may be performed by one or more programs or functions available on the client. Application information, which may include manifests, receipts (actual and stubs), user account information, etc. (such as proof of credentials or ownership of applications not yet adopted), may, in some cases, (Step 505). The application information is transmitted 505 to the server for the purpose of creating a purchase page informing the user of installed applications, applications available for installation, and applications that may be adopted. The transmitted application information may depend on whether the user signed in on the client. For example, if the user is signed at the client, the user account information may be accessible and transmitted as part of the application information. As discussed above, the user account information may include information about applications associated with the user account. Similarly, receipts may include information about applications associated with the electronic device on which the client is running. The manifest may include information of originally pre-installed applications on the electronic device or information of applications that the user owns but is not installed on the user device or is not associated with a user account. These are only exemplary types of application information, and other types of application information may also be sent to the server to create a purchase page.

The server receives the transmitted application information (i.e., manifests, receipts, user accounts, and other user account information) and generates 507 one or more lists of applications based on the received information. The processes used to generate the application lists and application lists may vary depending on the information received. The first list of applications may include applications installed on the client ' s electronic device. The second list of applications may include applications associated with the user account and may be installed in the electronic device of the client. The third application list may possibly include applications that may be linked with a user account. Applications in the third list may include applications preinstalled on the client ' s electronic device and / or applications for which the client owns but is not adopted or installed. Other application lists may also be generated such as purchased or otherwise acquired applications not associated with a user account. Depending on the application information received by the server, one or more of the above-listed application lists may be generated. In some instances, the generation of application lists may involve accessing an application database, such as application database 220, in FIG. The server may generate an HTML page based on the generated application lists (508). The occurrence of an HTML page may include accessing an application database to receive metadata associated with applications in the application lists. For example, the metadata may include the name of the application, a description of the application, a version number of the application, a date of purchase of the application, an image associated with the application, and so on. Once an HTML page is generated, the server sends an HTML page to the client (509). The client subsequently presents an HTML page to the user (511). Depending on whether the user has signed on the client, different information is presented to the user.

Figure 9 shows an example of an HTML page associated with a purchase page request when the user is unsigned. In this example, the HTML page 550 presents the user with a list 557 of applications available for adoption. Among the three applications available for adoption, applications "iMovie" and "GarageBand" have available updates as illustrated by text 558 and 559, respectively. The HTML page 550 includes a purchase link 551. In some instances, the purchase link 551 may function the same or substantially the same as the update link 451 of FIG. The HTML page 550 further includes a headline 553 that informs the user of the number of applications available for adoption. The description 555 provides a description of the adoption process to the user with the hope of assisting the user in deciding whether or not they wish to adopt the application. The HTML page 550 also includes instructions 552 for informing the user that the user must sign his user account to receive information about purchases associated with his user account. In this example, the HTML page 550 includes an accept link 554 that initiates the adoption process when selected by the user. In other examples, the HTML page 550 may include an accept link for each application available for adoption, thus allowing the user to select a single application available for adoption, a plurality of applications available for adoption, or And to choose to accept all applications available for adoption. The user may select the accept link 554 via a touch screen, a mouse click, a keyboard, or other user input devices.

Figure 10 shows another example of an HTML page associated with a purchase page request when the user is signed. The HTML page 560 presents a list of two applications to the user. In this example, presentation of application list 562 includes applications available for adoption, and presentation of application list 564 includes previously purchased applications. The two application lists are presented in independent and separate portions of the HTML page 560. [ The presentation of the application list 564 includes metadata associated with previously purchased applications such as the name of the application, the image associated with the application, the software vendor, the date of purchase, and status 566. [ State 566 may be configured to display the current state of the purchased application. For example, state 566 may be in an "installed state " when an application is currently installed in the client's electronic device. State 566 may be configured to display the text "INSTALLED " when in this state. In this example, the four purchased applications are all installed in the client's electronic device. As another example, state 566 may be in an "install state " when an application is purchased but not installed in the client's electronic device. For example, an application may not have been downloaded to this device yet, or the application may have been selectively deleted from the device. State 566 may be configured to display the text "INSTALL " when in this state. In addition, state 566 may include a user selectable link when in an "installed state. &Quot; Selecting a user selectable link results in an application being downloaded and installed on the electronic device.

Returning to FIG. 8, the client may receive user input 513 as a request to adopt the application. In some instances, the user input may be to select the accept link 554 of FIG. The client may request user authentication to link the application to the user account (515). An example of an HTML page that includes an authentication prompt to request user authentication to link an application to a user account is shown in FIG.

Figure 11 shows another example of an HTML page associated with a purchase page request that includes an authentication prompt. The HTML page 570 may include an authentication prompt 575 when the user chooses to accept the adoption of the preinstalled applications. The authentication prompt 575 may be included as part of the HTML page sent from the server and presented to the user after the user has selected to accept the adoption of the pre-installed applications. In some instances, the authentication prompt 575 may be the same as or substantially the same as the authentication prompt 480 in FIG.

Returning to Figure 8, the client may receive user authentication to link the application to the user account. A user account is a user account that is entered during user authentication. For example, the user may enter the user name and password of the user with which the application is associated. After user authentication is received by the client, the client may continue to adopt the application (519). An exemplary process of employing an application for a user account is described in FIG. 12 below. In some instances, all pre-installed applications must be associated with a user account at the same time. Thus, a user can not selectively link one pre-installed application associated with an electronic device having a single user account, and can not selectively link another pre-installed application associated with an electronic device having a different user account. Adopting all the pre-installed applications on the electronic device at the same time can simplify the computational overhead in managing the adoption process because the unique hardware identifier associated with the electronic device is sufficient to inform the server that pre- It is because. In other instances where pre-installed applications on the electronic device may be selectively associated with a plurality of accounts, management of pre-installed applications on the server may require storing pre-installed applications adopted in addition to the unique hardware identifier of the electronic devices have.

Figure 12 illustrates an exemplary method for linking an application preinstalled in a user account. A method 600 of illustrating a communication protocol performed between a client and a server may be configured to manage a process of linking a preinstalled application to a user account. Actions performed by the server may be executed by a program in another component located at the distribution center or server side, and actions performed by the client may be executed by an application management program stored in the electronic device of the client. The application management program may be configured to install, delete, maintain, or otherwise manage the software applications stored on the client. In some instances, the distribution program stored in the distribution center and the application management program stored in the electronic device may also be configured to perform the method 400 of FIG. 4 and / or the method 500 of FIG. In some instances, method 600 may be performed after "continue application adoption" 421 of FIG. 4 or "continue application adoption" 519 of FIG.

The method 600 may generate 620 a unique hardware identifier. The unique hardware identifier may serve as a digital receipt of a valid ownership or qualification of the application. The unique hardware identifier may be generated from combining one or more identifiers specific to the electronic device. For example, the unique hardware identifier may be based on one or more identifiers associated with hardware components of the electronic device. Because the identifiers of the hardware components are unique, the two unique hardware identifiers are not the same. By way of example, the unique hardware identifier may be generated by combining the device's Ethernet hardware address with the logic board serial number of the device. The logic board serial number and Ethernet hardware address may be combined using joining, hashing, encoding schemes, or other data manipulation algorithms. The unique hardware identifier may be transmitted (630) from the client to the server as part of the request to associate the pre-installed application with the user account. In other instances where preinstalled applications may be selectively employed, the metadata associated with the preinstalled application is also transferred from the client to the server. Metadata provides details to the server so that the server can identify the selected pre-installed application that the user is attempting to adopt into the user account. After the server has received the unique hardware identifier and optionally the metadata, the server may verify the credentials of the credential (640) by determining whether the pre-installed application has already been linked with the user account. The server can determine whether the application is already linked by checking the uniqueness table for the unique hardware identifier. Since the uniqueness table stores entries that include the unique hardware identifiers of the electronic devices that have already pre-installed applications, the unique hardware identifier that is not found in the table does not associate any of the pre-installed applications of the electronic device yet . If the method 600 allows selective adoption of preinstalled applications, the determination may include querying a uniqueness table for an entry associated with a unique hardware identifier. If a unique hardware identifier is found, the determination may evaluate an entry with the metadata of the pre-installed application to determine if the selected pre-installed application was previously adopted.

If it is determined that the application has been previously adopted from retrieving (i.e., querying) the uniqueness table, an error is sent to the client (641). The client receives the error and presents 642 a warning to the user that the application has already been adopted. Fig. 13 shows an example of an adoption warning. Alert 700 notifies the user that one or more applications that the user desires to associate with his / her user account can not be assigned because pre-installed applications have already been assigned to different user accounts. On the other hand, if it is determined that the application has not been previously adopted from retrieving the uniqueness table, the server may perform a sanity check to determine if the preinstalled application is part of the original or default configuration of the electronic device (650). In other words, the server determines whether the electronic device is installed and pre-installed from the manufacturer and delivered. This sanity check prevents the user from copying a preinstalled application originally installed in one electronic device to another electronic device and attempting to associate an illegal copy to the user account. The server may query the configuration server having a unique hardware identifier to receive the original configuration of the electronic device associated with the unique hardware identifier. The original configuration can be checked to determine a list of pre-installed applications. This list of pre-installed applications can be compared to the application the user attempts to adopt to determine if the application is available for adoption. In other instances, a copy of the database used to query the original configurations can be stored in the distribution center, thus allowing evaluation of the unique hardware identifier to be performed entirely in the distribution center. This can reduce network traffic to the configuration server.

If it is determined that the application that the user wants to adopt is not part of the original configuration of the electronic device, an error message may be sent to the client (651). Once the client receives the error message, the client may present 642 an alert to the user that the electronic device is not suitable for adoption. Fig. 14 shows another example of the adoption warning. Alert 750 notifies the user that an application can not be assigned to a user account because the electronic device (referred to herein as a "Mac ") is not eligible to associate a pre-installed application with a user account . In other instances, the alert 750 may include pictures or other sentences provided for the purpose of informing the user that the electronic device was not originally configured with pre-installed applications. On the other hand, if it is determined that the application that the user wishes to adopt is part of the original configuration of the electronic device, additional sanity checks may be performed if so. Once the server has verified that a pre-installed application can be linked to a user account, the server can determine whether the pre-installed applications of the electronic device have been adopted (and thus can not be adopted by other user accounts) The table and user account can be updated 660. As discussed above, the adopted pre-installed application is now a pre-installed application of the electronic device associated with the user account, and thus updates and re-downloads associated with the application can be downloaded to the electronic device associated with the user account. The server may send an acknowledgment message to the client (670) to inform the client that the request has been granted. The acknowledgment message notifies or notifies the client that the pre-installed application is now associated with a user account on the server, since the link request has been evaluated and found to be a legitimate request. The client receives the grant message and links 680 the pre-installed application with the user account stored on the client. In some instances, the client may also update the manifest stored on the electronic device by removing metadata associated with the pre-installed application linked with the user account from the manifest. Removing the metadata associated with the pre-installed application may simplify the adoption process by minimizing the checks performed to determine if the application is acceptable. The client may then send 690 requests to the distribution center or other components of the server to download the application.

The method 600 may also be configured for later adoption of a post-installed application (i.e., an application installed by a user). Applications installed later include applications that are present, purchased, redeemed, or otherwise acquired on the user's device after the device leaves the manufacturer or after the device has been purchased by the user. For example, method 600 may generate 620 a unique identifier associated with an application instead of generating a unique hardware identifier. The unique identifier may be the proof of qualification of the application or the metadata associated with the application used to represent the proof of purchase. The unique identifier may be stored in the metadata of the application and subsequently retrieved by the client device. Alternatively, the unique identifier may be generated based on the metadata of the application. For example, the unique identifier may include metadata associated with receiving an application, such as a unique or non-unique receipt of the application, the date and / or place the application was acquired, a unique identifier associated with the client device, and / Lt; RTI ID = 0.0 > and / or < / RTI >

In some instances, the communication protocol may depend on whether the unique identifier is associated with a pre-installed application (i.e., an application installed by a manufacturer) or a later installed application (i.e., an application installed by a user). For example, the communication protocol may include verifying (650) that the application is part of the original configuration of the electronic device and is therefore not part of the original configuration of the electronic device when a unique identifier received from the client is associated with an installed application later Can be skipped. Instead, the server can verify the credentials or ownership of the application's credentials by comparing the unique identifier with a database of valid unique identifiers. This allows the server to distinguish and distinguish between valid and invalid copies of the application. Once the proof of qualification is verified, the application is adopted as part of the user account. In order to determine whether the application is pre-installed or later installed, the server may analyze the flag or other metadata associated with the unique identifier.

In other instances, the communication protocol may depend on whether the unique identifier received from the client is based on metadata associated with the client electronic device. For example, a database or table accessed by a server to determine whether an application has already been linked may depend on the unique identifier. The first database may be accessed and updated by the server for unique identifiers associated with the client electronic device. The first database may be keyed and searchable based on the hardware of the electronic device. The second database may be accessed and updated by the server for unique identifiers not associated with the client device. In other words, these unique identifiers are based solely on the proof of credentials associated with the application, and thus retrieving the second database may be based on a proof of qualification or a proof of qualification.

15 illustrates an exemplary process for a recovery mode in an electronic device. In general, the recovery mode may enable an electronic device to resolve internal fatal errors for applications or even an operating system. In severe cases of restoring the entire operating system, this approach can even reformat the storage unit and reinstall the operating system. Depending on the specific implementation of the recovery mode, the operating system to be reinstalled may vary. By way of example, the reinstalled operating system may be the operating system originally installed in the electronic device, which may then be manually and / or automatically updated. As another example, a reinstalled operating system may include one or more updates published after the originally installed operating system. In yet other instances, the newest available operating system from the manufacturer may be reinstalled. In general, the resume mode reinstalls the operating system without reinstalling only preinstalled applications. For this reason, pre-installed applications that are not associated with or linked to user accounts may be lost. The process 800 solves this problem by retrieving the manifest from the configuration server during the recovery mode.

Process 800 may begin by entering a recovery mode (820). Entering recovery mode may trigger a download of a basic operating system from the manufacturer. The basic operating system may be configured 830 to generate a unique hardware identifier. The unique hardware identifier may be generated using one of the methods described above. Once a unique hardware identifier is generated, the underlying operating system may send a unique hardware identifier to the configuration server (840). Based on the received unique hardware identifier, the configuration server may return a manifest containing the version number of the applications and their applications pre-installed on the electronic device. The manifest may also include other applications that are owned by the owner of the electronic device. In some instances, the communication server may communicate with the distribution server to determine whether the electronic device has already adopted applications. If a unique hardware identifier is found in the uniqueness table of the distribution center, then one or more of the preinstalled applications of the electronic device have already been adopted. Thus, the communication server may return an empty manifest or a manifest that does not include certain pre-installed applications that have already been adopted. This can minimize the occurrences that a purchase page request presents to the user pre-installed applications for adoption when pre-installed applications have already been adopted. In other instances where the distribution center stores a local copy of the configuration database, the unique hardware identifier may be sent to the distribution center rather than the configuration server. Using a unique hardware identifier, the distribution center can determine which of the pre-installed applications and their applications are already associated with the user account.

The configuration server (or distribution center) may return 850 a manifest based on the version number of the operating system that comes with the electronic device and the pre-installed applications of the electronic device. In other examples, the manifest may also include later installed applications of the electronic device that are not linked with the user account (850). The manifest stored on the configuration server may be periodically updated when the electronic device installs an application that is not associated with a user account. This can occur for a variety of reasons, such as network failures, server crashes, or user selection options to not associate applications with user accounts at this point. The version number of the operating system is transmitted 860 to the operating system server, which also transfers the original operating system to the electronic device. The electronic device receives the original operating system (870) and installs the original operating system as an option. The electronic device now includes a fresh copy of the original operating system and a manifest based on pre-installed applications of the electronic device. If the user has not associated the pre-installed application with a user account, the user can do so by selecting the purchase page link as described above.

Embodiments within the scope of this disclosure may also include tangible and / or non-transitory computer readable storage media for executing or having computer-executable instructions or data instructions stored thereon. Such non-transitory computer readable storage media may be any available media that can be accessed by a general purpose or special purpose computer, including the functional design of any special purpose processor as discussed above. By way of example, and not limitation, such non-transitory computer readable media can include, but is not limited to, RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, Data structures, or any other medium that can be used to carry or store desired program code means in the form of a processor chip design. When information is communicated or provided to a computer via a network or other communication connection (hardwired, wireless, or a combination thereof), the computer appropriately views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer readable medium. Combinations of the above should also be included within the scope of computer readable media.

Computer-executable instructions include, for example, instructions and data that cause a general purpose computer, special purpose computer, or special purpose processing device to perform a particular function or group of functions. Computer-executable instructions also include program modules that are executed by computers in stand-alone or network environments. Generally, program modules include routines, programs, components, data structures, objects, and functions inherent in the design of special-purpose processors that perform particular tasks or implement particular abstract data types . The computer-executable instructions, associated data structures, and program modules represent examples of program code means for executing the steps of the methods disclosed herein. A particular sequence of these executable instructions or associated data structures represent examples of corresponding operations for implementing the functions described in these steps.

Those skilled in the art will appreciate that other embodiments of the present disclosure may be practiced in the personal computer, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, May be implemented in network computing environments having many types of computer system configurations, including non-volatile memory, frame computers, and the like. Embodiments may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (by hardwired links, wireless links, or the like) over a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

The various embodiments described above are provided by way of example only and are not to be construed as limiting the scope of the present disclosure. It will be understood by those of ordinary skill in the art that various changes in form and details may be made without departing from the spirit and scope of the disclosure and without departing from the exemplary embodiments and applications illustrated and described herein, Changes will be easily recognized.

110: bus
120: Processor
122: Cache
130: memory
160: Storage device
170: output device
180: Communication interface
190: input device
200: Application Distribution System
210: Distribution center
220: application database
230: Configuration Server
250: Internet
260, 270: computing device
280: Portable device
350: Client device
360: Server

Claims (20)

Verifying that an application installed on the first client device is eligible for adoption by determining by the server that the application installed on the first client device is configured for distribution by the server, Wherein the application is pre-installed or post-installed on the first client device;
Automatically retrieving a unique identifier that uniquely identifies an individual copy of the installed application from metadata associated with the installed application, and verifying that the unique identifier is not associated with any user account. Verifying, by the server, that the application has not been previously adopted; And
Forwarding, from the server, a notification to the first client device that the installed application is eligible for adoption
≪ / RTI > The method of claim 1, further comprising, by the server, employing the application in a user account, wherein the adoption includes allowing privileges for the adopted application to one or more client devices associated with the user account ≪ / RTI > 3. The method of claim 2, wherein the privileges include downloading, re-downloading, and updating of the application. The method according to claim 2 or 3,
Registering a second client device in the user account; And
Transmitting the adopted application to the second client device
≪ / RTI > 4. The method of any one of claims 1 to 3, wherein the unique identifier is a proof of entitlement for the individual copy. 4. The method of claim 2 or claim 3, wherein the application is previously installed on one or more client devices associated with the user account. 4. The method according to any one of claims 1 to 3, wherein the method is performed in response to a user request. 4. The method according to any one of claims 1 to 3,
Notifying the client device of a plurality of applications available for adoption; And
Accepting input to select at least one of the plurality of applications for adoption
≪ / RTI > 4. The method of any one of claims 1 to 3, wherein automatically retrieving the unique identifier comprises querying a database on the server for the unique identifier. 4. The method according to any one of claims 1 to 3, wherein the adoption comprises updating the database based on proof of credentials for the application. 4. The method of any one of claims 1 to 3, wherein the unique identifier comprises a value derived from hardware associated with the client device. A processor;
A storage device; And
Memory
Lt; / RTI >
The memory comprising:
Verifying that the application installed on the client device is eligible for adoption by determining by the server that the installed application on the client device is configured for distribution by the server, the application being preinstalled on the client device, Installed -;
Automatically retrieving a unique identifier that uniquely identifies an individual copy of the installed application from metadata associated with the installed application, and verifying that the unique identifier is not associated with any user account. Verifying, by the server, that the application has not been previously adopted; And
Forwarding, from the server, a notification to the client device that the installed application is eligible for adoption
And to store the instructions for controlling the processor to perform the steps. 13. The computer program product of claim 12, wherein the memory further comprises instructions for employing the application in a user account by the server, the adoption including privilege to the adopted application for one or more client devices associated with the user account Said system comprising: 14. The system of claim 13, wherein the privileges include downloading, re-downloading, and updating of the application. 15. The system according to any one of claims 12 to 14, wherein the memory further comprises instructions for registering another client device in the user account and for transferring the adapted application to the another client device. 15. The system according to any one of claims 12 to 14, wherein the application is previously installed on one or more client devices associated with the user account. 15. The system according to any one of claims 12 to 14, wherein the memory is adapted to notify the client device for a plurality of applications available for adoption and to accept input to select one of the plurality of applications ≪ / RTI > further comprising instructions. A computer-readable medium having computer-executable instructions that, when executed by a computing device,
Verifying that the application installed on the client device is eligible for adoption by determining by the server that the installed application on the client device is configured for distribution by the server, the application being preinstalled on the client device, Installed -;
Automatically retrieving a unique identifier that uniquely identifies an individual copy of the installed application from metadata associated with the installed application, and verifying that the unique identifier is not associated with any user account. Verifying, by the server, that the application has not been previously adopted; And
Forwarding, from the server, a notification to the client device that the installed application is eligible for adoption
The computer-readable medium storing instructions that cause the processor to perform steps comprising: 19. The method of claim 18, further comprising verifying that the application is installed on a client device, verifying that the application has not been previously adopted, and communicating the notification, Transiently computer readable storage medium. 20. The method of claim 18 or 19, further comprising, by the server, employing the application in a user account, wherein the adoption is based on the privilege on the adopted application for one or more client devices associated with the user account Lt; RTI ID = 0.0 > computer-readable < / RTI >

Images