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

Description

System and method for linking pre-installed software to a user account of an online store

The present invention relates generally to the dissemination of digital products and, more particularly, to techniques for linking software applications to user accounts of online stores.

This application is filed on July 12, 2011 entitled "System and Method for Linking Pre-installed Software to User Accounts of Online Stores (SYSTEM AND METHOD FOR LINKING PRE-INSTALLED SOFTWARE TO A USER ACCOUNT ON AN Part of the continuation application of US Patent Application No. 13/181,424 to ONLINE STORE); this application is also entitled "Users for linking pre-installed software to online stores" on September 29, 2011 Part of the continuation application of U.S. Patent Application Serial No. 13/248,942, the entire disclosure of which is incorporated herein by reference. The United States, which was filed on February 9th, entitled "SYSTEM AND METHOD FOR LINKING PRE-INSTALLED SOFTWARE TO A USER ACCOUNT ON AN ONLINE STORE" The priority of Provisional Patent Application No. 61/596,928, the entire disclosure of which is hereby incorporated by reference in its entirety.

Manufacturers of electronic devices often offer consumers a variety of options available at Personalize and customize electronic devices before purchase. For example, a personal computing device such as a computer can be customized by selecting a processor, a memory, a hard drive, or an accessory. Manufacturers also work with a variety of software vendors to provide software applications or programs that can be purchased with a computer and pre-installed before the consumer extracts the computer. Some software applications, which are typically established by the manufacturer but may also include third party applications, can be pre-installed on the computing device for free, either manually or as part of, for example, a preset factory image. Thus, the hardware components and pre-installed software can be personalized by the consumer to ensure that the purchased product meets the consumer's needs.

After the consumer receives the electronic device, the consumer may sometimes need to reinstall or update the pre-installed software in the future. For example, a software provider may issue an updated version of software pre-installed on an electronic device. This is often referred to as a software update. In order to obtain a software update, the consumer accesses the entity or online store of the software provider and purchases or obtains an updated version of the software. However, this procedure is time consuming and sometimes confusing. Similarly, when the purchaser reformats the storage of the electronic device, the purchaser typically has to reinstall the software. During reinstallation, the purchaser can be prompted with a variety of compact discs (CDs) or other media containing pre-installed software. However, the purchaser may have misplaced the CD, thus making the reinstallation process very cumbersome.

The additional features and advantages of the invention will be set forth in part in the description. The features and advantages of the present invention can be realized and obtained by means of the instrument and combinations particularly pointed out in the appended claims. This hair These and other features will become more fully apparent from the following description and the appended claims.

The present invention discloses systems, methods, and non-transitory computer readable storage media for associating an application (ie, a packaged software), a pre-installed application, or a separately purchased application with a user account. The user account can be associated with an online store or stored on an online store. This procedure can be called adoption. Use can provide certain special permissions to the user account, such as application downloads, re-downloads, and updates. In other instances, the user account can be configured to permit other special permissions regarding the employed application, such as a gifted application or a sale of the employed application. In a common situation, the new computer includes some pre-installed software. The user can execute and use the pre-installed software on the new computer. However, in order to receive and/or update, back up and/or other software related content or services, the user may "use" the pre-installed software. Pre-installed software is associated with a particular user account (such as an online e-shop account) by employing pre-installed software. The online e-shop can then handle updates, backups, restores, in-app purchases, and more. However, the user may choose to use pre-installed software instead of "featured" pre-installed software with full functionality, with the exception of features that rely on user accounts or access to online e-shop accounts. When the user uses pre-installed software, the online e-shop can modify the account, database, and/or software itself so that the pre-installed software is not suitable for use by another user. In another common scenario, install a packaged software or application that has been purchased, presented, or otherwise obtained by the user. On the user's computing device. The computing device can transmit the request to the server by the user account using the software of the package software or the application. The software employs an indication that the request can include the package software and an identifier associated with the user account. In some instances, proof of entitlement is also included in the request to prove the authenticity of the packaged software. This proof of entitlement can be a value that can be derived only from owning the packaged software. For example, the proof of entitlement can be associated with the serial number of the packaged software or derived from the serial number of the packaged software. The proof of entitlement may also be a value that can be derived from the packaged software and associated with the electronic device. For example, the data associated with the electronic device can be a value that can be derived from the hardware associated with the electronic device. Once the application has been adopted, updates, backups, and/or other software-related content or services are available to the user.

The system configured to practice the method presents an application available for downloading, receives a request to download the application to the computing device, and determines that the application is a pre-installed application. Next, the system presents an authorization prompt configured to request authorization of the user to link the application to the user account, receive the user authorization, and generate a unique hardware identifier or response in response to receiving the user authorization. Take the proof of entitlement associated with the computing device. The system determines that the application can be linked based on a unique hardware identifier or proof of entitlement and links the available application to the user account when the application can be linked. The system can present an application available for download by receiving a request to update the page and collect a stub receipt associated with the application in response to receiving the request. The stub receipt can include the version number and name associated with the application. Then, the system base The update of the version number and the name determination application is available for download on the server and the name of the application is presented.

Alternatively, the system can present an application available for download by receiving a request for a purchase page, receiving a list of information associated with the computing device, and presenting a list of pre-installed applications based on the list of information. The list of information may include a list of pre-installed applications available for download from the server, wherein the list of pre-installed applications includes the application. The system can determine that the application has available updates on the server by searching the application database and comparing the version number of the application stored on the computing device with the version number of the application stored on the application database. Based on the comparison of the version numbers, a determination can be made as to whether the application update exists on the application database. The system can determine that the application is a pre-installed application by determining that the application is associated with the stub receipt. The system can determine, by the following steps, that the application is a pre-installed application: receiving a list of information associated with the computing device, the list of information including a list of pre-installed applications; and determining that the application is included in the pre-installation The list of applications. The system can determine that the pre-installed application can be linked by transmitting a unique hardware identifier or proof of purchase to the server and determining whether the pre-installed application has been linked to another user account. In still other examples, the system causes the pre-installed application to use the pre-installed application by associating the pre-installed application with the user account and updating the uniqueness table to include a unique hardware identifier or proof of purchase. Account link. The uniqueness table can include another unique hardware identifier associated with another electronic device having another pre-installed application Or proof of purchase, and the other pre-installed application can be linked to another user account.

In another variation, the system receives a request to link a pre-installed application to a user account of an online store, the online store configured to transfer an application associated with the user account to the user The account is associated with one or more computing devices. Next, the system generates a unique hardware identifier or proof of purchase associated with the computing device and determines that the pre-installed application is linkable based on the unique hardware identifier or proof of purchase. When the pre-installed application is connectable, the system links the pre-installed application to the user account. The unique hardware identifier can be based on one or more hardware components of the electronic device, such as a MAC address, a Universal Device Identifier (UDID), a logical board serial number, or an Ethernet hardware address. In other instances, proof of purchase can be used. The proof of purchase may be based on hardware components of the electronic device, associated with the application, purchase, or acquisition. Determining that the pre-installed application can be linked may include: transmitting a unique hardware identifier or proof of purchase to the server; and determining whether the pre-installed application or proof of purchase has been linked to another user account. The system can determine that the pre-installed application is connectable by determining that the original configuration of the computing device includes a pre-installed application. Linking the pre-installed application to the user account can include: associating the pre-installed application with the user account; updating the uniqueness table to include the unique hardware identifier or proof of purchase, the uniqueness The table includes another unique hardware identifier or proof of purchase associated with another electronic device having another pre-installed application that has been linked to another user account. In yet another example, linking the pre-installed application to the user account further includes removing information from the information listing associated with the pre-installed application, the information listing configured to list the usage not yet used Pre-installed apps linked to the account. The system can download the pre-installed application to the computing device.

For a more detailed description of the preferred embodiments of the invention, the invention may It is understood that the drawings are merely illustrative of the exemplary embodiments of the invention, and are not intended to Description and explanation.

Various embodiments of the invention are discussed in detail below. While specific implementations are discussed, it should be understood that this discussion is made solely for the purpose of illustration. Those skilled in the art will recognize that other components and configurations can be used without departing from the spirit and scope of the invention.

The present invention addresses the need in the art to associate pre-installed software on an electronic device with a user account of a distribution center or online store. The present invention also addresses the need in the art to associate other types of software than pre-installed software with user accounts. For example, purchased software, software received as a gift, software distributed free of charge from a software manufacturer or symbolic fee, or software obtained using other methods may be associated with a user account of an online store or store. This program can be referred to as the "adoption" of the user account of the online store. By making software and online quotient The store's user account is associated with the ability to download software updates and reinstalls from online stores, thus demonstrating a simpler and more convenient way to manage software on electronic devices. In addition, other computing devices associated with the user account may also receive software updates and reinstallations from the online store. The following description in Figures 1 through 15 applies to pre-installed application software, packaged software, and applications obtained via other means, such as gifts, purchases, or otherwise distributed or acquired. Thus, as used herein, the term "pre-installed application" may be used interchangeably with the gifted application, the purchased application, the distributed application, the acquired application, and others. In other words, a "pre-installed application" can be any application that the user has ownership of. Similarly, a "unique hardware identifier" can be any unique identifier configured to provide proof of entitlement or ownership to an application installed on a computing device. For example, the proof of entitlement can be a value that is unique to each copy of the established application. The proof of entitlement can also be a redemption code for redemption of the application. In other examples, the proof of entitlement may be a combination of a unique value and a non-unique value, such as a combined redemption code (which may not be unique) and a unique identifier (which is unique) associated with the user account Union. A brief introductory description of a basic general purpose system or computing device that may be used in a practical concept is illustrated in FIG. A more detailed description of how to associate the pre-installed software with the user account will be followed, including several variations, as set forth in various embodiments. The invention now turns to Figure 1.

Referring to FIG. 1, an exemplary system 100 includes a general purpose computing device 100 that includes a processing unit (CPU or processor) 120 and a system bus 110 that will include system memory 130 (such as, for example, Various system components of read only memory (ROM) 140 and random access memory (RAM) 150) are coupled to processor 120. System 100 can include a cache memory 122 of high speed memory that is directly coupled to processor 120, intimately coupled to processor 120, or integrated as part of processor 120. System 100 copies the data from memory 130 and/or storage device 160 to cache memory 122 for quick access by processor 120. In this manner, the cache memory provides an increase in performance that avoids delays in processor 120 while waiting for data. These and other modules can be controlled or configured to control processor 120 to perform various actions. Other system memory 130 is also available. Memory 130 can include a plurality of different types of memory having different performance characteristics. It will be appreciated that the present invention can operate on computing device 100 having more than one processor 120, or on a group or cluster of computing devices that are connected together via a network to provide greater processing power. The processor 120 can include any general-purpose processor and a hardware module or a software module (such as the module 1 162, the module 2 164, and the module 3 166 stored in the storage device 160. The modules are configured. The control processor 120) and the dedicated processor (where the software instructions are incorporated into the actual processor design). The processor 120 can be essentially a fully self-contained computing system that includes multiple cores or processors, bus bars, memory controllers, cache memory, and the like. Multi-core processors can be symmetric or asymmetrical.

The system bus bar 110 can be any of several types of bus bar structures including a memory bus or memory controller, a peripheral bus bar, and a region using any of a variety of bus bar architectures. Bus bar. A basic input/output (BIOS) stored in ROM 140 or the like can provide assistance in transferring information between components within computing device 100 (eg, The basic routine during startup. Computing device 100 further includes storage device 160, such as a hard disk drive, a magnetic disk drive, a compact disk drive, a tape drive, or the like. The storage device 160 can include software modules 162, 164, 166 for controlling the processor 120. Other hardware or software modules are expected. The storage device 160 is connected to the system bus bar 110 by a drive interface. The drive and associated computer readable storage medium provide non-volatile storage of computer readable instructions, data structures, program modules, and other materials for computing device 100. In one aspect, a hardware module that performs a particular function includes a combination of necessary hardware components (such as processor 120, bus bar 110, display 170, etc.) stored in a non-transitory computer readable medium to perform functions. Software component. The basic components are known to those skilled in the art and are expected to vary as appropriate depending on the type of device, such as the device 100 being a small handheld computing device, a desktop computer, or a computer server.

Although the exemplary embodiments described herein use hard disk 160, those skilled in the art will appreciate that other types of computer readable media that can store data accessible by a computer can also be used in an exemplary operating environment. Such as tape cassettes, flash memory cards, digital video discs, cassettes, random access memory (RAM) 150, read only memory (ROM) 140, cable or wireless signals containing bit stream and the like . Non-transitory computer readable storage media explicitly excludes media such as energy, carrier signals, electromagnetic waves, and signals themselves.

In order to enable user interaction with the computing device 100, the input device 190 represents any number of input mechanisms, such as a microphone for voice, a touch sensitive screen for gestures or graphical input, a keyboard, a mouse, a sports loser. In, voice, etc. Output device 170 can also be one or more of several mechanisms known to those skilled in the art. In some examples, the multimodal system enables a user to provide multiple types of inputs to communicate with computing device 100. Communication interface 180 generally controls and manages user input and system output. It is not limited to operate on any particular hardware configuration, and thus the improved hardware or firmware configuration (when it is developed) can be readily substituted for the essential features herein.

For clarity of explanation, illustrative system embodiments are presented as including individual functional blocks including functional blocks labeled "processor" or processor 120. The functions indicated by such blocks may be provided through the use of common or special purpose hardware, including but not limited to hardware capable of executing software and specially constructed to be equivalent to the software executed on a general purpose processor. The hardware of the operation (such as processor 120). For example, the functionality of one or more of the processors presented in FIG. 1 may be provided by a single shared processor or multiple processors. (The use of the term "processor" should not be interpreted as referring specifically to hardware capable of executing software). Illustrative embodiments may include a microprocessor and/or digital signal processor (DSP) hardware, a read-only memory (ROM) 140 for storing software that performs the operations discussed below, and a random number for storing results Access memory (RAM) 150. A very large integrated circuit (VLSI) hardware embodiment and a custom VLSI circuit combined with a general purpose DSP circuit are also available.

The logical operations of the various embodiments are implemented as: (1) a sequence of computer implemented steps, operations or programs executed on a programmable circuit within a general purpose computer; (2) computer implemented steps executed on a dedicated programmable circuit ,operating Or a sequence of programs; and/or (3) an interconnected machine module or program engine within the programmable circuit. The system 100 shown in FIG. 1 can practice all or part of the described methods, can be part of the described system, and/or can operate in accordance with the instructions in the non-transitory computer readable storage medium described. These logical operations can be implemented as modules that are configured to control the processor 120 to perform specific functions in accordance with the stylization of the modules. For example, FIG. 1 illustrates three modules Mod1 162, Mod2 164, and Mod3 166 that are configured to control the modules of processor 120. The modules can be stored on storage device 160 and loaded into RAM 150 or memory 130 during the execution phase or can be stored in other computer readable memory locations as is known in the art.

Having disclosed some components of a computing system, the present invention now returns to a discussion of a particular technique for making a computing device (such as a personal computer, laptop, game console, smart phone, mobile phone, or tablet PC) The pre-installed software on the software is associated with a user account that distributes the store or mall (which is similar to a link or adoption). The methods described herein can be used to upgrade a pre-installed software or reinstall a pre-installed software to a computing device by linking pre-installed software to a user account that distributes the website on an online basis, such as an online store or distribution center. Efficiency and convenience. The online distribution website transmits the pre-installed software associated with the user account to one or more computing devices linked to the user account. Both the pre-installed software and the pre-installed software updates can be transmitted to one or more computing devices. In some instances, the scatter website 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, the pre-installed software is The portion of the standard "image" that is generated and copied to each of the device groups at a time. For example, a standard device "image" may include an operating system, drivers, programs, settings, and the like. Therefore, each imaging device has the same software configuration, including pre-installed software, and after the end user (or other entity) sets up the device, pre-installed software can be used and made to be linked to a user account of an online store or mall. Associated.

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, an internet 250 or other network, a computing device 260, a computing device 270, and a portable device 280. The distribution center 210, the application repository 220, and the configuration server 230 together may represent different individual components of the server side 240 of the master-slave model. Similarly, computing device 260, computing device 270, and portable device 280 can represent different individual components on the client side 290 of the master-slave model. Thus, a broad overview of the scatter system 200 includes the server side 240 communicating with the client side 290 via the internet 250. As an example, server side 240 may be represented to a user as an online store for selling and distributing applications, or as multiple cloud servers. The device from the client side 290 can communicate with the online store using an application management computer program stored on the device. In other examples, the Internet 250 can be replaced with other communication networks such as computer networks, telephone networks, Ethernet, regional networks, wired networks, wireless networks, and other networks.

Computing device 260 can include an application 261. The application 261 can include an application pre-installed on the computing device 260, provided as part of the package, or provided with a certain type of installation media. In a common situation, The owner of computing device 260 purchases computing device 260 from which the application has been installed from the manufacturer. Application 261 may also include applications (or suites of software) that are obtained by computing device 260 via other means, such as applications that are gifted, purchased, or distributed freely (to name a few). The application 261 can also include an application purchased by the user of the computing device 260 from the distribution center 210. In order to purchase the desired application from the distribution center 210, the user logs into the user account 291, which contains the back-end information associated with the application that the user has purchased and the payment for the payment to the distribution center 210 in exchange for the desired Post-data related to the payment information of the application. Once logged in, the user can select the desired application to purchase. When the user agrees to pay the purchase price of the application, the user's payment information is used to complete the transaction. Once the transaction is completed, the desired application is associated with the user account 291, thus allowing the user to download the desired application and updates to the desired application. The application associated with the user account 291 can also be updated or re-downloaded to other devices associated with the user account 291.

In some instances, the user may have an option to associate the application with the user account at this point in time. For example, a user receiving an application as a gift may not have a user account or would like to associate the application with its user account. In the first scenario, computing device 260 can allow a user to install an application without requiring the user to set up a user account. If the user wishes to receive an update or install the application on other electronic devices owned by the user, the user can select the user account and link the application to its user account (ie, employ). In this In the example, computing device 260, computing device 270, and portable device 280 are all associated with user account 291 and are thus configured to receive updates and re-downloads of all applications that have been associated with user account 291. In addition, portable device 280 can communicate with computing device 270 to transfer digital data and applications between the two devices. In an example, computing device 270 can be configured to be a central repository containing all of the applications associated with user account 291 and to communicate the selected application to 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 instances, digital products other than software applications and software programs (such as system software, enterprise software, multimedia files, video files, audio files, and video files) that are pre-installed on computing devices (such as The software application with ownership 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 repository 220 is configured to sell, deliver, and maintain applications from the application repository 220. The application repository 220 can be configured to store some or all of the applications available for deployment from the server side 240. The applications can be sold, updated, and delivered (i.e., transmitted) to the devices in the client side 290 via the Internet 250. Thus, the distribution center 210 represents the online store of the application. For example, the application repository 220 can receive a request for an application from the distribution center 210 and, in response to the request, transmit the requested application to the distribution center 210, which then transmits the application to the request. Device. The requested application can be an application that can be used for purchase. Or an application previously associated with a user account (that is, an application that has been acquired separately or pre-installed). In other examples, the application repository 220 can directly transfer the requested application to the requesting device. In still other examples, the application repository 220 can reside on the client side 290, wherein the server side 240 can grant a particular application to the application repository 220 based on the application associated with the user account. access.

The device on the client side 290 can transmit a request to connect (i.e., associate or employ) a pre-installed application on the device or an otherwise acquired application that is not employed to the user account. The link application allows the user to associate the application with the user account, thus allowing the user to download the application to other devices that are also associated with the same user account. This program can be called a "link", "take" or "associate" application. For example, computing device 260 can request that the application from application 261 be linked to user account 291. The request can be transmitted via the internet 250 along with a unique identifier associated with the application or computing device 260 to the distribution center 210 to determine if the application can be associated with the user account 291. The unique hardware identifier is a unique identifier based on the device hardware that is used to distinguish a particular device from all other devices. For example, the manufacturer can ensure that each device manufactured includes a unique hardware identifier that is unique and therefore unique to the unique hardware identifier of any other device. As an example, the unique hardware identifier can be based on the logical board number of the device and/or the Ethernet hardware address. In an example, these two values can be concatenated and hashed to produce a unique hardware identifier. in In other examples, a plurality of data manipulation algorithms may be used in tandem, hashed, or otherwise combined with other device-specific post-data to form a unique hardware identifier. In still other examples, the unique identifier used to determine whether the application can be associated with the user account 291 can be based on any other purchase or proof of entitlement that can serve as an application associated with the unique identifier. The program (ie, the package software) is evidence that is legally obtained from the software manufacturer. In one example, the unique identifier can be derived from the data or attributes associated with the application. In another example, the unique identifier can be derived from the association with the following: an application, a client device, a user account, other client devices associated with the user account, or both. A combination of one or more.

In an 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 the user account. In some situations, an application cannot be associated with a user account. For example, if the device's application has previously been associated with another user account, the application may not be associated with the user account. As another example, if the application is not an authorized copy, the application may not be associated with a user account. This situation may occur when a user manually copies an application originally installed on one device to another device. As yet another example, the associated program may require the user to log into a user account on the electronic device to link the application to the user account.

In another 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 the user account. As an example, processing the unique identifier may include comparing by The unique identifier is associated with the database to verify the unique identifier. The database can have a plurality of entries, each of which stores a unique identifier associated with the authorized copy of the application. The result of the comparison can be used to determine the status of the application, such as whether the application is a valid copy or if the application is an invalid copy, or if the application is already associated with a user account. As another example, processing the unique identifier can include entering the unique identifier into the hash table to determine the state of adoption of the application. In yet another example, the unique identifier can be received as input to the verification engine, and the verification engine determines if the installation of the application is valid and has not been adopted. In still other examples, other data processing techniques can be applied to the unique identifier to determine if the application can be associated with a user account. The app is recently available to the user. In other words, the application may have been acquired by the user after purchase and receipt of the electronic device from the distribution or manufacture. Alternatively, the application can be obtained when purchasing an electronic device. Once the adoption status has been determined by the distribution center 210, an acknowledgment based on the status of use can be transmitted to the electronic device. The confirmation can be transmitted to inform the electronic device of the status of the program. Based on the confirmation, the electronic device can request the download of the package software or the update of the package software. In other examples, the scatter server 210 can automatically begin the process of downloading updates to the packaged software or packaged software to the electronic device based on the state of adoption.

The server side 240 can have a number of servers and tables to determine if a connection request should be authorized. For example, the distribution center 210 includes a uniqueness server 211 that is configured to process a unique identifier to determine the validity or legitimacy of the join request. The uniqueness server 211 can include a uniqueness table configured to maintain one or more pre-installed links with the user account A database or table of programs for electronic devices. As an example, the uniqueness table can be configured to store the unique hardware of the device that has the pre-installed application linked to the user account (ie, the device that has the pre-installed application associated with the device). Identifier. The uniqueness table can also be configured to store back-end material associated with an application that has been associated with a user account. The device's unique hardware identifier or adopted application when the device uses some or all of its applications (ie, links some or all of its applications to the user's account) through the user's account. The unique identifier is stored in the uniqueness table. This situation prevents future requests from linking to an already used application. For example, performing a query as to whether the unique identifier is in the uniqueness table determines whether the device associated with the unique hardware identifier has linked its pre-installed application to the user account. Similarly, the query can also determine if the application associated with the unique identifier has been linked to the user account. As another example, the uniqueness table can be configured to store a unique hardware identifier of the electronic device along with one or more pre-installed applications that have been previously employed (ie, linked to the user account) of the electronic device. Associated post-data. In other words, the uniqueness table is configured as a one-to-many mapping between the unique hardware identifier of the device and one or more of the post-set data, and the one or more subsequent sets of data and devices have been selectively employed The installed app is associated. If the unique hardware identifier does not exist in the uniqueness table, then querying the uniqueness table to find a unique hardware identifier may not return any data, and if the unique hardware identifier does exist in the uniqueness table, then the query The uniqueness table looks up the unique hardware identifier to pass back the back-end data associated with the pre-installed application that has been selectively used. This situation can be generated Optionally, the first user account employs a pre-installed application on the device and the second user account employs the ability of another pre-installed application on the device. In still other examples, the uniqueness table can be configured to maintain a database or table of applications that are linked to a user account. Connected applications can have a unique identifier stored in a uniqueness table to maintain an up-to-date database of used applications.

In an example, the configuration server 230 can verify the validity of the link request by checking the original configuration of the electronic device to verify or determine that the particular application has been pre-installed on the device when the electronic device leaves the manufacturer. on. The configuration server can also verify or identify the application that the user has ownership, regardless of whether the application is already installed on the user device or associated with the user account. Therefore, it is also possible to identify an application that the user has ownership but has not yet associated or installed. The configuration server 230 includes a repository that stores the original configuration of the electronic device established by the manufacturer. The original configuration may include the version of the operating system and the version of the application (if present) delivered with the electronic device. For example, a user who orders an electronic device via an online store can configure the device with one or more applications at the time of purchase. These applications are installed on the electronic device by manufacturing based on the configuration at the time of purchase. Manufacturing communicates the configuration of the electronic device to the configuration server 230 for subsequent lookups. When the configuration server 230 receives a lookup request containing a unique hardware identifier from the electronic device, the configuration server 230 performs a search or query of the database and returns the version and/or contains of the operating system installed on the device. A list of versions of the application installed on the electronic device. The configuration server 230 can compare the list of installed applications with the user's test The application associated with the user account is determined to determine if the application the user is attempting to associate is an authorized installation or has previously been associated with another user account. Alternatively, the configuration server 230 can pass a list of pre-installed applications to the distribution center 210 to determine if a link request should be granted. This check prevents the user from attempting to circumvent the distribution system 200 by copying the pre-installed application from one device to another.

Once one or more components on server side 240 have the connection request valid, the pre-installed application is associated with the user account (ie, the application is employed). Additionally, the unique server 211 or the configuration server 230 can be updated to take into account application adoption. For example, a new entry may be added to the uniqueness table of the unique server 211 because some or all of the pre-installed applications associated with the electronic device have been employed. In some examples, the distribution center 210 can transmit an update of the pre-installed application to the computing device 260 after the pre-installed application is associated with the user account. In other examples, the distribution center 210 can transmit the pre-installed application to other devices, such as the computing device 270, associated with the user account, but the computing device 270 is not initially configured with a pre-installed application. The pre-installed application stored in the application 271 and the pre-installed application stored in the application 281 of the portable device 280 by the computing device 270 may be associated with the user account 291 via a similar request to the application. Together, and ultimately distributed to computing device 260, computing device 270, and/or portable device 280.

Figure 3 illustrates an exemplary master-slave system. The master-slave system 300 includes a client device 350 and a server 360. Server 360 can be configured to be from a user The request of the end device 350 responds and may include one or more components from the server side 240 of FIG. The client device 350 can associate the application (pre-installed or otherwise acquired) with the user account by submitting the page request to the server 360. The client device 350 can also associate other applications with the user account by submitting the same or similar page request to the server 360 as in the context of a pre-installed application.

One type of page request is an update page request 301. The update page request 301 can be a request to transmit to the server 360 to perform a query for an available application update. In response to the update page request 301, the server 360 can return a Hypertext Markup Language ("HTML") page 303 that is configured to inform the user of the application with the available updates stored in the client device 350. In some examples, server 360 can pass the back data back to client device 350, which in turn generates an HTML page for presentation to the user. The update page request 301 can include a digital receipt stored in each of the applications in the client device 350. The receipt contains information related to the application and is used to document the purchase or ownership of the software. One type of receipt is a real receipt that is associated with a purchased application or an applied application. The actual receipt may include a description of the application, the version number of the application, the date of purchase of the application, information relating to the purchaser of the application, information about the device on which the application was originally installed, and other information. In other words, the real receipt is the only proof of purchase for the purchaser and/or the electronic device that has purchased the application. Another type of receipt is a stub receipt. The stub receipt contains a subset of the information in the real receipt, and the application is still It is part of the application when it is not used by the user account. In one example, the stub receipt uniquely identifies the duplicate of the application with other replicas. This situation may allow the server to determine whether this particular copy of the application (which may be presented to the user or otherwise obtained by the user) is acceptable to the user. In another example, the stub receipt is generated by the manufacturer as a receipt to be associated with the pre-installed application. To speed up and simplify the installation of the application by the manufacturer, the stub receipt can include less information than the amount of information in the real receipt. For example, the stub receipt can include identifying the application identifier of the application to the server and identifying the version number of the version of the application. The application identifier can be the name associated with the application. The stub receipt may not include information specific to the purchaser, such as the date of purchase of the application and information relating to the purchaser of the application or the installation of the pre-installed application. In other words, the stub receipt may not contain user accounts, user account information, or information related to the client device, computing device, or other device. The application identifier can be the name associated with the pre-installed application. In some instances, the stub receipt is generated by the manufacturer when the application is pre-installed on the device or the device is ready for delivery. In other examples, the stub receipt may be generated by the server 260 and subsequently transmitted to the client device 350 for association with the pre-installed application. The server 360 may generate a stub receipt in response to a request by the client device 350 or a periodic schedule communication between the server 360 and the client device 350. Once the pre-installed application is used, the stub receipt can be replaced with a real receipt. In another example, the stub receipt is generated as a purchase that is not associated with the client device when the application is acquired, A receipt associated with an app that is given or otherwise obtained. This stub receipt can be generated by the manufacturer, application spreader, online store, or others. In some cases, stub receipts can be processed in batches and assigned to applications for distribution. The stub receipt is stored on the server and used to authenticate the request. As in the previous example, the stub receipt can be replaced with a real receipt while the application is using the program. The real receipt may be generated by the client device 350, the server 360, or other components in the master-slave 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 a real receipt associated with the application 330 331. The application 330 is purchased from the server 360 after purchase of the client device 350, and thus the application 330 includes a real receipt. In response to the update page request 301, the server 360 generates an HTML 303 that informs the user whether the pre-installed application 310, the pre-installed application 320, or the application 330 has available updates available for download from the server 360. The available updates associated with a pre-installed application that has not been used (ie, associated with a user account or associated with a user account) cannot be downloaded until the pre-installed application has been adopted by the user account. Once the available updates are downloaded and installed on the client device 350, the stub receipt can be replaced with a real receipt, including other back-end materials, such as the date the application was purchased (ie, the date the update was installed), the purchase The user of the application and the electronic device on which the application was originally installed.

Another type of page request is a purchase page request 302. The purchase page request 302 can be transmitted to the server 360 to request that the user device 350 has been requested A list of applications purchased by the user. In response to the request, the server 360 can pass back an HTML page 303 that is configured to inform the user that the application that has been purchased by the user of the client device 350 and, as appropriate, has been installed on the client device 350. The application in the middle. The purchased application not stored in the client device 350 can be downloaded and installed. The HTML page 303 can also include applications that can be used (i.e., linked to a user account or associated with a user account). An application on the client device that is not yet associated with the user account may be selected for adoption via the update page request 301 or alternatively via the purchase page request 302. An unused application can transmit a receipt or other form of proof of entitlement in the request to install the application or desired application on the client device.

The purchase page request 302 can include an information list 340. The information list 340 can be configured to store information associated with pre-installed applications or otherwise acquired applications. This information can be used by the server 360 to inform the user of the applications available for use. The information list 340 includes a list, a table, or other data structure configured to store the version number of the application in the client device 350. The version number of the application can be found in the stub receipt or other post-data associated with the application. In one example, the information list 340 is generated when the client device 350 is first launched. For example, the information list can be generated by using the "spotlight" (ie, search) function on the client device to search for the stub receipt during the first startup of the client device, and the stub receipts are subsequently generated. Used to generate a list of information. As will be discussed below, the information list can be stored in the configuration server to link the application to the user account or to the electronic device. Access during complex mode.

In this example, the client device 350 is queried to locate the stub receipt 311 and the stub receipt 321 , and the stub receipt 311 and the stub receipt 321 are then used to generate the information list 340 . During the reformatting or recovery of the client device 350, both the pre-installed application and the otherwise obtained application may be deleted from the client device 350. The application that has been linked to the user account can be re-downloaded to the client device 350. However, pre-installed applications that are not yet linked to a user account are at full risk of loss. As will be described in further detail below, the information manifest 340 acts as a mechanism to prevent application loss that has not yet been adopted. Applications that are available for use cannot be downloaded until the pre-installed application is linked or associated with the user account. Once the available updates are downloaded and installed on the client device 350, the newsletter 340 can be edited to remove the stub receipt associated with the currently employed application. In addition, the installed app contains a real receipt. In some examples, the generation of the update page request 301 and the purchase page request 302 and the processing and retrieval of the HTML page 303 are managed and processed by an application management program (not shown) installed in the client device 350. The application manager can be proprietary to the manufacturer and configured to specifically communicate with servers belonging to the manufacturer.

The master-slave system 300 can also employ an application that is acquired by the client device 350 but is not associated with a user account (eg, gifted, purchased but not linked to a user account, or otherwise distributed to the client device) . As an example, the acquired application can be linked to the user account via an update page request, a purchase page request, or other page request. The request can be Include a stub receipt or associate with the stub receipt or export data from the stub receipt. As another example, the information list 340 may be updated when the application device 350 (ie, an application that has not been linked to the user account) is obtained by the client device 350.

Figure 4 illustrates an exemplary method for processing an update page request. The method 400 illustrating the actions performed by the client and the server can be configured to manage communication between the client and the server during the update page request. The actions performed by the server may be performed by a distribution program stored on a distribution center or other component located on the server side, and the actions performed by the client may be performed by an application management program stored on the electronic device of the client. The method 400 can begin by the user selecting an update tag link in a graphical user interface provided by the client device. An exemplary update tag link can be the link 451 in FIG. Once the client has received a user request for the updated page (401), the client queries or searches the client device for a receipt or other form of proof of entitlement associated with the application installed in the client device (403) . In other instances, the query can start automatically without user interaction. For example, the server can initiate the query by communicating with the client at predetermined time intervals or at predetermined time points. The search can be performed using the functionality associated with the operating system of the client device or alternatively using an application or routine stored on the client device. The receipt will be found or a copy of the receipt will be transmitted to the server (405). The receipts can be transmitted across any communication network, such as an Ethernet, internet, regional network, or other network. The server receives the receipt and processes it to determine if the application associated with the receipt has an update (407). This processing can include accessing The application database of the application database 220 in Figure 2, and the version number of the comparison receipt and the version number of the application stored in the application database. The process can also include verifying that the application is suitable for adoption by determining that the application installed on the client device is configured for server dissemination. In some embodiments, the server may also verify that the application has not been previously employed at this point in time, and the verification may include the steps of: capturing a unique identifier that uniquely identifies the replica of the installed application; and verifying the unique The identifier has not been associated with any user accounts. A list of updated applications, such as a desktop application or a smart phone application, can be used when generating an HTML page (408) or manipulating some other user interface. The HTML page can include information about the application with the available updates. This information may include the original purchase date of the application, a description of the application, and a description of the changes or modifications in the updated application. HTML is only one instance of a notification that can be sent to the client to notify the client that one or more applications have updates or are available for adoption. The server can then transfer the HTML page to the client (409). In some instances, the server may transmit the HTML page via the same channel as the channel on which the client transmits the receipt. Alternatively, the server can transmit sufficient information to the client to update the client application installed on the local end, instead of pre-packaging the HTML page and transmitting the HTML page to the client.

Figure 5 illustrates an example of an HTML page associated with an update page request for a pre-installed application that has been or is associated with a user account of an online store or store. The HTML page 450 includes an "updates" link 451, which can be The user chooses to request an update page. The "Updates" link 451 can be located on a menu bar with other links such as "featured", "top charts", "categories" and "purchases" to provide users with access to different features of the application management program. A convenient and quick method. In some examples, the representation of the "updates" link 451 can include a number that specifies the number of applications having available updates stored in the client device. The numbers in the figure can be generated via periodic communication between the server and the client device before the user selects the "updates" tag link 451.

For example, the client device can periodically communicate with the server and retrieve the latest version number of the stored application with the available updates. In this example, the "updates" link 451 has been selected and one of the available updates is presented in the HTML page 450. An application is rendered by 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 issue of the application, or other information associated with the application. The application description 457 can further include an icon 455 providing an identification code for the application, and a summary 459 of the changes implemented in the updated version of the application. This provides information to the user so that the user can make a decision about whether or not they wish to upgrade. The HTML page 450 also includes an optional link 461 that can be selected by the user if the user wishes to receive an application update. The number of available updates is shown at heading 453. Header 453 is configured to provide another convenient location where the user can quickly determine the number of available updates. In a In some examples, HTML page 450 may also include a selectable link adjacent to title 453 for updating all applications with available updates.

Returning to Figure 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 lists the applications with available updates, a description of the applications, and one or more updates that can be selected by the user to authorize the application. Links. The client can receive a user authorization to update the application (413). If the user authorization has been received, the client can determine if the application needs to be used (415) before the application can be updated. This determination may include checking 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 a pre-installed application that may not have been used by the user account. Thus, user authorization is required, and the client can present the HTML page of the user authorization requesting the application to be used by the user account or associated with the user account (417). User authorization can involve the transmission of personal information across a communication network. For privacy reasons, the HTML page informs the user that personal information will be sent during the authorization process and request permission to transmit this personal information across the communication network.

Figure 6 illustrates an example of an HTML page requesting authorization from a user of an application that may have been consolidated and/or pre-installed upon purchase of a computing device. The HTML page 470 is an update page that presents four applications with available updates to the user. Therefore, the "updates" link 471 has a number "4". In this example, the user has selected via The "update all" link 475 updates all applications. However, in other examples, the user may also choose to update a single application by selecting one of the "update" links 476, 477, 478 or 479. Applications with available updates include pre-installed applications 472 and purchased applications 473. In some instances, at this stage, there is no difference in presenting pre-installed applications and purchased applications. However, once the user chooses to update an application that is pre-installed or otherwise not linked to the user account, the HTML page 470 presents the prompt 480 to the user. The prompt 480 is described in more detail in FIG.

Figure 7 illustrates another example of an HTML page requesting authorization from a user of an application. When the user chooses to update an application that is pre-installed on the computer and may not have been associated with the user account or simply choose to update the acquired application that has not been associated with the user account, it will also be referred to as an authorization prompt. The prompt 480 is presented to the user. In this example, prompt 480 includes icon 481, login 482, password 483, password assistance 484, description 485, help link 486, account creation 487, cancellation 488, and login 489. Description 485 provides textual information to inform the user that if the user needs to update the applications, the pre-installed (ie, integrated) application on the electronic device will be associated with the user account. The description 485 can also inform the user that for the application, the unique hardware identifier associated with the electronic device will be sent to the server to determine if the application should be authorized for adoption. The icon 481 can be used to add an application update function to the (brand) application management program. Login 482 and password 483 can specify a user account, and the user wants the pre-installed application to be associated with the user account. Union. Password assist 484 may be selected by a user who needs assistance with the password. Once the desired user account has been typed and the correct password has been typed, the user can begin the process by selecting Login 489. If the user does not have a user account or the user wishes to associate the pre-installed application with the new account, the user can select account creation 487. If the user wishes to cancel and does not update the application, the user may choose to cancel 488. Alternatively, if the user desires a more detailed description of any of the elements described above, the user may select the description link 486. In other instances where the HTML page is requesting user authorization to associate an application that is not pre-installed on the electronic device but is otherwise separately acquired by the electronic device, the description 485 can be changed to deliver the appropriate message to the user. For example, the description 485 can state "To receive future updates, applications 'X', 'Y', and 'Z' will be assigned to this apple ID. A unique identifier stored on your computer must be sent to Apple to verify eligibility "."

Returning to Figure 4, the client can receive a user authorization (419) using the application. This user authorization can be received by the user by typing the user account and password into the prompt as described in FIG. 7 presented by the client. Once the user has received the user authorization, the client can continue to use the application (421). An illustrative procedure for causing an application to be employed by a user account is described below in FIG. In some instances, all pre-installed applications must be associated with a user account at the same time. Therefore, the user cannot selectively connect a pre-installed application associated with the electronic device with a user account, and cannot selectively associate another pre-installed application associated with the electronic device with another A user account link. Using electronics at the same time All pre-installed applications on the device simplify the computational effort in the management application because the unique hardware identifier associated with the electronic device is sufficient to notify the server that the pre-installed application has been adopted. In other examples, a pre-installed application on an electronic device can be selectively associated with multiple accounts. Thus, the first pre-installed application can be associated with the first electronic device and the second pre-installed application can be associated with the second electronic device. However, managing pre-installed applications on the server may require storing the unique hardware identifier of the electronic device plus the pre-installed application that has been used. These examples are also applicable to applications that are acquired separately from the purchase of an electronic device. For example, bundles of applications that are presented and installed on an electronic device can be associated with a user account individually or as a group.

Figure 8 illustrates an exemplary method for processing a purchase page request. A method 500 illustrating the actions performed by the client and server can be configured to manage communication between the client and the server during a purchase page request. The actions performed by the server may be performed by a distribution program stored on a distribution center or other component located on the server side, and the actions performed by the client may be performed by an application management program stored on the electronic device on the user side. In some examples, the scatter program stored on the distribution center and the application management program stored on the electronic device can be configured to perform the method 400 of FIG. 4 during the update page request. The method 500 can begin by the user selecting a purchase tag link in a graphical user interface provided by the client device. An exemplary purchase tag link can be the link 551 in FIG. After the user receives the user request for the purchase page (501), the user can perform a search or check. Ask for application information. In this exemplary method, the application information can include a list of information and/or a receipt (503). In other instances, the application information may include an application or suite of software that has not been associated with a user account, where the user account has ownership of the packaged software. This title can be a proof of entitlement, such as a digital receipt. In some examples, the listing of information can be similar or substantially similar to the listing of information 340 of FIG. The search or query can be performed by one or more programs or functions available on the client. In some examples, application information may be transmitted to the server (505) as a software request, the application information may include a list of information, receipts (real receipts and stub receipts), user account information, and other information (such as , Proof of Entitlement or Ownership of the application that has not been used). For the purpose of generating a purchase page, the application information is transmitted to the server 505, which informs the user of the installed application, the application that can be used for installation, and the application that can be used. The transmitted application information may depend on whether the user has logged in on the client. For example, the user account information is accessible and can be transmitted as part of the application information if the user logs in on the client. As discussed above, user account information may include information about the application associated with the user account. Similarly, the receipt may contain information about the application associated with the electronic device that is executing the client. The information list may include information of an application originally pre-installed on the electronic device, or an application that the user has ownership but is not yet installed on or associated with the user device. This information is only an exemplary type of application information, as other types of applications can also be transferred to the server for production. Health purchase page.

The server receives the transmitted application information (i.e., the information list, the receipt, the user account, and other user account information), and generates one or more lists of applications based on the received information (507). The list of applications and the programs used to generate the list of applications may vary depending on the information received. The first application manifest can include an application installed on the electronic device of the client. The second application manifest can include an application associated with the user account and mountable on the electronic device of the client. The third application manifest can include applications that may be linked to a user account. The application in the third list may include an application pre-installed on the electronic device of the client and/or an application owned by the client but not yet adopted or installed. Other application listings may also be generated, such as purchased or otherwise acquired applications that are not associated with a user account. Depending on the application information received by the server, one or more of the list of applications described above may be generated. In some instances, the generation of the application manifest may involve accessing an application repository such as the application repository 220 of FIG. The server can generate an HTML page based on the generated application manifest (508). The generation of the HTML page can include accessing an application database to receive post-data associated with the application in the application manifest. For example, the post-data may include the name of the application, the description of the application, the version number of the application, the purchase information of the application, the image associated with the application, and other information. Once the HTML page is generated, the server transmits the HTML page to the client (509). The client then presents the HTML page to the user (511). take Depending on whether the user has logged in on the client, different information is presented to the user.

Figure 9 illustrates an example of an HTML page associated with a purchase page request when the user is not logged in. In this example, the HTML page 550 presents the user with a list 557 of applications that are available for adoption. As explained in the texts 558 and 559 respectively, among the three applications that can be used, the applications "iMovie" and "GarageBand" have available updates. The HTML page 550 includes a "purchases" link 551. In some examples, the "purchases" link 551 can function the same or substantially the same as the "updates" link 451 of FIG. The HTML page 550 further includes a title 553 that informs the user of the number of applications available for adoption. Description 555 provides the user with an explanation of the application, and it is desirable to assist the user in determining whether they wish to adopt the application. The HTML page 550 also includes an instruction 552 to inform the user that the user must log into their user account to receive information about the purchase associated with their user account. In this example, the HTML page 550 includes an "accept" link 554 that, when selected by the user, initiates the application. In other examples, the HTML page 550 can include an "accept" link for each application that can be used, thereby allowing the user to choose to accept a single application available for adoption, multiple applications available for adoption, or available. For all applications used. The user can select the "accept" link 554 via a touch screen, a mouse click, a keyboard or other user input device.

Figure 10 illustrates the association with a purchase page request when the user logs in Another example of an HTML page. The HTML page 560 presents two application listings to the user. In this example, the presentation of the application manifest 562 includes an application that is available for adoption, and the presentation of the application manifest 564 includes the previously purchased application. The two application listings are presented in separate and separate sections of the HTML page 560. The presentation of the application manifest 564 includes post-data associated with the previously purchased application, such as the name of the application, the image associated with the application, the software vendor, the date of purchase, and the status 566. State 566 can be configured to display the current status of the purchased application. For example, when the application is currently installed on the electronic device of the client, state 566 can be in an "installed state." When in this state, state 566 can be configured to display the text "INSTALLED". In this example, four purchased applications are installed in the electronic device on the client side. As another example, state 566 may be in an "installed state" when the application is purchased but not installed in the electronic device at the client. For example, an application may not have been downloaded to the device or the application may have been selectively removed from the device. When in this state, state 566 can be configured to display the text "INSTALL". Additionally, when in the "installed state", state 566 can include a user selectable link. Selecting the user to select the link causes the application to be downloaded to the electronic device and installed.

Returning to Figure 8, the client can receive user input as a request to apply the application (513). In some examples, the user input can be an "accept" link 554 of FIG. The client can request a user authorization to link the application to the user account (515). In Figure 11, the description contains the authorization prompt. An instance of an HTML page that is used to request authorization for a user to link an application to a user account.

Figure 11 illustrates another example of an HTML page associated with a purchase page request that includes an authorization prompt. The HTML page 570 can include an authorization prompt 575 when the user chooses to accept the adoption of the pre-installed application. An authorization prompt 575 can be included as part of the transmitted HTML page from the server, and the authorization prompt 575 is presented to the user after the user has selected to accept the application of the pre-installed application. In some examples, authorization prompt 575 can be the same or substantially similar to authorization prompt 480 of FIG.

Returning to Figure 8, the client can receive a user authorization to link the application to the user account. The user account is a user account typed during user authorization. For example, the user can type in the username and password of the user account that will be associated with the application. After the user receives the user authorization, the client can continue to use the application (519). An illustrative procedure for causing an application to be employed by a user account is described below in FIG. In some instances, all pre-installed applications must be associated with a user account at the same time. Therefore, the user cannot selectively associate a pre-installed application associated with the electronic device with a user account, and cannot selectively cause another pre-installed application associated with the electronic device. Another user account is associated. Simultaneous use of all pre-installed applications on the electronic device simplifies the computational overhead of the management application because the unique hardware identifier associated with the electronic device is sufficient to notify the server that the pre-installed application has been adopted. . Among other instances in which a pre-installed application on an electronic device can optionally be associated with multiple accounts, In addition to storing the unique hardware identifier of the electronic device, managing the pre-installed application on the server may also require the storage of the pre-installed application that has been used.

Figure 12 illustrates an exemplary method for linking a pre-installed application to a user account. A method 600 illustrating a communication protocol executed between a client and a server can be configured to manage a program that links a pre-installed application to a user account. The actions performed by the server may be performed by a program on a server or other component on the server side, and the actions performed by the client may be performed by an application management program stored on the electronic device of the client. The application manager can be configured to install, delete, maintain, or otherwise manage software applications stored on the client. In some examples, the distribution program stored on the distribution center and the application management program stored on the electronic device can be configured to also perform the method 400 of FIG. 4 and/or the method 500 of FIG. In some examples, method 600 can be performed after "Continue Application Adoption" (421) of Figure 4 or "Continue Application Adoption" (519) of Figure 8.

Method 600 can generate a unique hardware identifier (620). This unique hardware identifier can serve as a digital receipt for the effective ownership or rights of the application. The unique hardware identifier can be generated by combining one or more identifiers specific to the electronic device. For example, the unique hardware identifier can be based on one or more identifiers associated with a hardware component of the electronic device. Because the identifier of the hardware component is unique, no two unique hardware identifiers will be the same. As an example, a unique hardware identifier can be generated by the logical board number of the combined device and the Ethernet hardware address of the device. Can use tandem, hash, edit Code scheme or other data mediation algorithm to combine the logic board serial number and the Ethernet hardware address. The unique hardware identifier can be transmitted from the client to the server as part of the request to associate the pre-installed application with the user account (630). In other instances where a pre-installed application is optionally employed, post-data associated with the pre-installed application is also transmitted from the client to the server. The post-data will allow the server to identify the details of the selected pre-installed application that the user is attempting to use by the user account to the server. After the server receives the unique hardware identifier and (as appropriate) the data, the server can verify the proof of entitlement by determining if the pre-installed application has been linked to the user account (640). The server can determine if the application is linked by checking the uniqueness table to find a unique hardware identifier. Because the uniqueness table stores entries containing the unique hardware identifier of the electronic device that has the pre-installed application, the unique hardware identifier not found in the table indicates that the electronic device has not been pre-installed with the application. One is associated. If method 600 allows for the selective adoption of a pre-installed application, the decision may include querying the uniqueness table to find an entry associated with the unique hardware identifier. If a unique hardware identifier is found, it is determined that an entry with pre-installed application post-data can be evaluated to determine if the selected pre-installed application has previously been adopted.

If the self-search (i.e., query) uniqueness table determines that the application has been previously employed, the error is transmitted back to the client (641). The client receives the error and presents the user with a warning that the application has been taken (642). Figure 13 illustrates an example of the use of a warning. Warning 700 notifies the user that one or more applications that the user wishes to associate with their user account have been assigned to different User accounts, so these pre-installed apps cannot be assigned. On the other hand, if the self-search uniqueness table determines that the application has not been previously used, the server may perform a sanity check to determine whether the pre-installed application is part of the original or preset configuration of the electronic device. (650). In other words, the server determines whether the electronic device is pre-installed with the application configured and delivered by the manufacturer. This routine check prevents the user from copying a pre-installed application originally installed on an electronic device to another electronic device and attempting to associate the illegal copy with the user account. The server can query the configuration server based on the 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 is trying to use to determine if the application is available for adoption. In other instances, a copy of the database used to query to find the original configuration may be stored in the distribution center, thus allowing the evaluation of the unique hardware identifier to be performed entirely in the distribution center. This situation can be reduced to the network traffic of the configuration server.

If it is determined that the application that the user wishes to use is not part of the original configuration of the electronic device, an error message can be transmitted to the client (651). Once the client receives the error message, the client can present the user with a warning that the electronic device is not suitable for use (642). Figure 14 illustrates another example of employing a warning. The warning 750 informs the user that the application cannot be assigned to the user account because the electronic device (referred to herein as "Mac") is not suitable for associating the pre-installed application with the user account. In other examples, the alert 750 can include a schema or other sentence provided for the following purposes Sub: Tells the user that the electronic device was not initially configured with a pre-installed application. On the other hand, if it is determined that the application that the user wishes to use is part of the original configuration of the electronic device, an additional routine check (if any) can be performed. Once the server has verified that the pre-installed application can be linked to the user account, the server can update the uniqueness table and user account (660) stored on the server to indicate that the pre-installed application of the electronic device has been Adopted (and therefore cannot be adopted by another user account). As discussed above, the pre-installed application that has been employed is a pre-installed application of the electronic device that is now associated with the user account, and thus the update and re-download associated with the application can be downloaded to the user. The electronic device associated with the account. The server may transmit an approval message to the client to inform the client that the request is approved (670). The approval message informs or informs the client that the application pre-installed on the server is now associated with the user account because the link request has been evaluated and considered a real request. The client receives the approval message and links the pre-installed application to the user account stored on the client (680). In some examples, the client may also update the list of information stored on the electronic device by removing the post-data associated with the pre-installed application that has been linked to the user account from the information list. Removing the post-data associated with the pre-installed application can simplify the adoption of the program by minimizing the checks performed to determine if the application is available. The client can then transfer the request to the distribution center or other component of the server to download the application (690).

Method 600 can also be configured for use with a post-installed application (i.e., an application installed by a user). Post-installed applications include A gifted, purchased, redeemed, or otherwise obtained application that has been installed on the device after the user's device has left the manufacturer or after the device has been purchased by the user. For example, instead of generating a unique hardware identifier (620), method 600 can generate a unique identifier associated with the application. The unique identifier may be associated with the application to display the application's proof of entitlement or proof of purchase. The unique identifier can be stored in the post-application data and subsequently retrieved by the client device. Alternatively, the unique identifier can be generated based on the data set by the application. For example, the unique identifier may be derived from: a unique or non-unique receipt of the application, a data associated with the receiving application (such as the date and/or location of the application), and associated with the client device. A unique identifier associated with, and/or other post-data associated with the application or client device.

In some instances, the communication protocol may depend on whether the unique identifier is an application installed with a pre-installed application (ie, an application installed by the manufacturer) or a later installed application (ie, an application installed by the user) Associated. For example, when the unique identifier received from the client is associated with the post-installed application and is therefore not part of the original configuration of the electronic device, the communication protocol may skip the confirmation that the application is the original configuration of the electronic device. Part (650). The truth is that the server can verify the application's proof of entitlement or ownership by comparing the database of unique identifiers with valid unique identifiers. This situation allows the server to distinguish and distinguish between valid and invalid copies of the application. Once the proof of entitlement is verified, the application is used as part of the user account. To determine if the application is pre-installed or After installation, the server can analyze the flag or other post-data associated with the unique identifier.

In still other examples, the communication protocol may depend on whether the unique identifier received from the client is based on the associated data associated with the client electronic device. For example, a database or table accessed by the server to determine if an application has been linked may depend on a unique identifier. The first repository can be accessed and updated by the server for a unique identifier associated with the client electronic device. The first database can be keyed and searchable based on the hardware of the electronic device. The second repository can be accessed and updated by the server for a unique identifier that is not associated with the client device. In other words, these unique identifiers are based only on the proof of entitlement associated with the application, and therefore, searching for the second repository will be based on a change in the proof of entitlement or proof of entitlement.

Figure 15 illustrates an exemplary procedure for a recovery mode on an electronic device. In general, the recovery mode allows the electronic device to resolve serious internal errors in the application or even the operating system. In the extreme case of restoring the entire operating system, this method can even reformat the storage unit and reinstall the operating system. The reinstalled operating system can vary depending on the particular implementation of the recovery model. As an example, the reinstalled operating system can be an operating system initially installed on the electronic device, which can then be manually and/or automatically updated. As another example, the reinstalled operating system may have one or more updates that have been issued since the originally installed operating system. In still other examples, the latest available operating system from the manufacturer can be reinstalled. In general, recovery mode only reinstalls the operating system without reinstalling the pre-installed application. For this reason, it has not been associated or linked to a user account The pre-installed application can be lost. The program 800 solves this problem by extracting a list of information from the configuration server during the recovery mode.

The process 800 can begin by entering a recovery mode (820). Entering recovery mode triggers the download of the basic operating system from the manufacturer. The basic operating system can be configured to generate a unique hardware identifier (830). The unique hardware identifier can be generated using one of the methods described above. Once the unique hardware identifier is generated, the base operating system can transmit the unique hardware identifier to the configuration server (840). Based on the unique hardware identifier received, the configuration server can return a list of information including the applications pre-installed on the electronic device and the version numbers of their applications. The information list may also include other applications that the owner of the electronic device has ownership of. In some examples, the communication server can communicate with the scatter server to determine if the electronic device has employed the applications. If the unique hardware identifier is found in the uniqueness table of the distribution center, one or more of the pre-installed applications of the electronic device have been adopted. Therefore, the communication server can return an empty list of information or a list of information that does not include the particular pre-installed application that has been used. This situation may result in a minimum purchase page request to present the pre-installed application to the user when the pre-installed application has been adopted. In other instances where the local copy of the configuration repository is stored in the distribution center, the unique hardware identifier can be transferred to the distribution center instead of the configuration server. By using a unique hardware identifier, the distribution center can determine pre-installed applications and applications that are associated with user accounts in their applications.

The configuration server (or distribution center) can return the operating system accompanying the electronic device A list of information on the version number and pre-installed applications based on electronic devices (850). In other examples, the information list may also include an application (850) installed after the electronic device, and the subsequently installed application has not been linked to the user account. When an electronic device installs an application that has not been associated with a user account, the list of information stored on the configuration server can be updated periodically. This situation can occur for a variety of reasons, such as a network failure, a server failure, or an option by the user to not associate an application with a user account at this point in time. The version number of the operating system is transmitted to the operating system server (860), which in turn transmits the original operating system to the electronic device. The electronic device receives the original operating system (870) and installs the original operating system as appropriate. The electronic device now includes a list of the latest copies of the original operating system and a list of pre-installed applications based on the electronic device. If the user has not associated the pre-installed application with the user account, the user can do so by selecting the purchase page link as described above.

Embodiments within the scope of the present invention may also include a tangible and/or non-transitory computer readable storage medium for carrying or storing computer executable instructions or data structures. Such non-transitory computer readable storage media can be any available media that can be accessed by a general purpose or special purpose computer, including the functionality of any special purpose processor as discussed above. By way of example and not limitation, such non-transitory computer-readable media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage or other magnetic storage device, or may be used for carrying or storing Any other medium of the desired code component in the form of a computer executable instruction, data structure or processor chip design body. When information is transmitted or provided to a computer via a network or another communication connection (a fixed line connection, a wireless connection, or a combination thereof), the computer properly views the connection as a computer readable medium. Accordingly, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included in the context of computer readable media.

Computer-executable instructions include, for example, instructions and materials for causing a general purpose computer, special purpose computer, or special purpose processing device to perform a function or group of functions. Computer-executable instructions also include program modules that are executed by a computer in an independent or network environment. In general, program modules include functions inherent in the design of routines, programs, components, data structures, objects, and specialized processors that perform specific tasks or implement specific abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of code components for performing the steps of the methods disclosed herein. The particular sequences of such executable instructions or associated data structures represent examples of corresponding acts for implementing the functions described in the steps.

Those skilled in the art will appreciate that other embodiments of the present invention can be practiced in a network computing environment, including personal computers, handheld devices, multiprocessor systems, by many types of computer system configurations. , microprocessor-based or programmable consumer electronics, network PCs, small computers, large computers, and the like. The embodiment can also be implemented in a distributed computing environment. In a distributed computing environment, tasks are performed by the local and remote processing devices, and the local and remote processing devices are linked via a communication network (by a fixed line) Link, wireless link or a combination thereof). In a distributed computing environment, the program module can be located in the local memory storage device and remote memory. In both body storage devices.

The various embodiments described above are provided by way of illustration only and should not be construed as limiting the scope of the invention. Those skilled in the art will readily appreciate that the embodiments described herein can be carried out without departing from the exemplary embodiments and applications described and described herein, and without departing from the spirit and scope of the invention. The principles are subject to various modifications and changes.

100‧‧‧System/General Purpose Computing

110‧‧‧System Bus

120‧‧‧Central Processing Unit (CPU) or processor

122‧‧‧Cache memory

130‧‧‧System Memory

140‧‧‧Read-only memory (ROM)

150‧‧‧ Random Access Memory (RAM)

160‧‧‧Storage device/hard disk

162‧‧‧Module 1/Software Module

164‧‧‧Module 2/Software Module

166‧‧‧Module 3/Software Module

170‧‧‧Display/output device

180‧‧‧Communication interface

190‧‧‧ Input device

200‧‧‧Distribution system

210‧‧‧Distribution Center/Distribution Server

211‧‧‧ Unique server

220‧‧‧Application Database

230‧‧‧Configuration Server

240‧‧‧server side

250‧‧‧Internet

260‧‧‧ Computing device

261‧‧‧Application

270‧‧‧ computing device

271‧‧‧Application

280‧‧‧ portable device

281‧‧‧Application

290‧‧‧User side

291‧‧‧User account

300‧‧‧Master-slave system

301‧‧‧Update page request

302‧‧‧ Purchase page request

303‧‧‧ Hypertext Markup Language ("HTML") page

310‧‧‧Pre-installed applications

311‧‧‧Stub receipt A

320‧‧‧Pre-installed applications

321‧‧‧Stub receipt B

330‧‧‧Application

331‧‧ Real receipts

340‧‧‧Information List

350‧‧‧Customer device

360‧‧‧Server

400‧‧‧Description of the actions performed by the client and the server

450‧‧‧ Hypertext Markup Language (HTML) page

451‧‧‧"Updates" link

453‧‧‧ heading

455‧‧‧ icon

457‧‧‧Application Description

459‧‧‧Overview

461‧‧‧Optional link

470‧‧‧ Hypertext Markup Language (HTML) page

471‧‧‧"Updates" link

472‧‧‧Pre-installed applications

473‧‧‧ Purchased application

475‧‧‧"update all" link

476‧‧‧"update" link

477‧‧‧"update" link

478‧‧‧"update" link

479‧‧‧"update" link

480‧‧‧ Tips

481‧‧‧ icon

482‧‧‧ Login

483‧‧‧ password

484‧‧‧ Password Assistance

485‧‧‧Description

486‧‧‧ Description link

487‧‧‧ Account Creation

488‧‧‧ Cancelled

489‧‧‧ Login

500‧‧‧Methods for performing actions performed by the client and the server

550‧‧‧ Hypertext Markup Language (HTML) page

551‧‧‧"purchases" link

552‧‧‧ directive

553‧‧‧ heading

554‧‧‧"accept" link

555‧‧‧Description

557‧‧‧Application list

558‧‧‧ text

559‧‧‧ text

560‧‧‧ Hypertext Markup Language (HTML) page

562‧‧‧Application List

564‧‧‧Application List

566‧‧‧ Status

570‧‧‧ Hypertext Markup Language (HTML) page

575‧‧‧ Authorization Tips

600‧‧‧ Explain the communication protocol between the client and the server Methods

700‧‧‧ Warning

750‧‧‧ Warning

800‧‧‧ procedures

1 illustrates an exemplary system embodiment; FIG. 2 illustrates an exemplary application distribution system; FIG. 3 illustrates an exemplary master-slave system; FIG. 4 illustrates an exemplary method for processing an update page request; FIG. An example of an HTML page associated with an update page request; Figure 6 illustrates an example of a user-authorized HTML page requesting a pre-installed application; Figure 7 illustrates a user-authorized HTML requesting a pre-installed application Another example of a page; Figure 8 illustrates one exemplary method for processing a purchase page request; Figure 9 illustrates one example of an HTML page associated with a purchase page request when the user is not logged in; Figure 10 illustrates when the user logs in Another example of an HTML page associated with a purchase page request; Figure 11 illustrates another example of an HTML page associated with a purchase page request that includes an authorization prompt; Figure 12 illustrates a method for linking a pre-installed application to use Account Exemplary method; Figure 13 illustrates an example of the use of a warning; Figure 14 illustrates another example of the use of a warning; and Figure 15 illustrates an exemplary procedure for a recovery mode on an electronic device.

300‧‧‧Master-slave system

301‧‧‧Update page request

302‧‧‧ Purchase page request

303‧‧‧ Hypertext Markup Language ("HTML") page

310‧‧‧Pre-installed applications

311‧‧‧Stub receipt A

320‧‧‧Pre-installed applications

321‧‧‧Stub receipt B

330‧‧‧Application

331‧‧ Real receipts

340‧‧‧Information List

350‧‧‧Customer device

360‧‧‧Server

Claims (20)

A method for linking a software application to a user account, comprising: configuring, by a server, an application installed on a first client device to be distributed by a server Determining that the installed application on the first client device is suitable for adoption, wherein the employing relates to associating the user account with the installed application; verifying the application by the server The program has not been previously employed, and includes automatically capturing a unique identifier that uniquely identifies one of the installed applications from a metadata associated with the installed application (metadata) An individual replica, and verifying that the unique identifier has not been associated with any user account; and delivering a notification from the server suitable for the installed application to the first client device. The method of claim 1, further comprising employing, by the server, the application for the user account, wherein configuring the user account to permit one or more associations with the user account The client device has special permissions with respect to the employed application. The method of claim 2, wherein the special rights include downloading, re-downloading, and updating the application. The method of any one of claims 2 to 3, further comprising: registering a second client device with the user account; and Transmitting the employed application to the second client device. The method of any one of claims 1 to 3, wherein the unique identifier is one of the individual copies of the proof of entitlement. The method of any one of clauses 2 to 3, wherein the application has previously been installed on one or more client devices associated with the user account. The method of any one of clauses 1 to 3, wherein the method is performed in response to a user request. The method of any one of claims 1 to 3, further comprising: notifying the client device that the plurality of applications are available for adoption; and accepting an input for selecting at least one of the plurality of applications for adoption. The method of any one of claims 1 to 3, wherein automatically capturing the unique identifier comprises querying a database on the server to find the unique identifier. The method of any one of claims 1 to 3, wherein the using the package software further comprises: updating a database based on a proof of entitlement of the package software. The method of any one of clauses 1 to 3, wherein the unique identifier comprises a value that can be derived from a hardware associated with the client device. A system for linking a software application to a user account, comprising: a processor; a storage device; A memory configured to store instructions for controlling the processor to perform steps comprising: configuring, by a server, an application installed on a client device to be configured for Detecting, by a server, that the installed application on the client device is suitable for use, wherein the employing involves associating the user account with the installed application; verifying the application by the server The program has not been previously employed, and includes automatically capturing a unique identifier that uniquely identifies a duplicate of the installed application from a post-data associated with the installed application. And verifying that the unique identifier has not been associated with any user account; and delivering a notification from the server suitable for the installed application to the client device. The system of claim 12, wherein the memory further comprises instructions for causing the application to be the user account by the server, wherein the user account is configured to permit the user account The associated one or more client devices have special permissions regarding the employed application. The system of claim 13, wherein the special rights include downloading, re-downloading, and updating the application. The system of any one of claims 12 to 14, wherein the memory further comprises for registering another user device with the user account and An instruction transmitted by the application to the other client device. The system of any one of claims 12 to 14, wherein the application has previously been installed on the one or more client devices associated with the user account. The system of any one of claims 12 to 14, wherein the memory further comprises instructions for notifying the client device that the plurality of applications are operable to accept and accept selection of one of the plurality of applications . A non-transitory computer readable recording medium storing, when executed by a computing device, causing the computing device to execute an instruction comprising the steps of: determining, by a server, that one of the user devices is installed The application is configured to be verified by a server to verify that the installed application on the client device is suitable for use, wherein the employing involves associating a user account with the installed application; The server verifies that the application has not been previously employed, and includes automatically capturing a unique identifier that uniquely identifies the installed application from a post-profile associated with the installed application A duplicate of the program, and verifying that the unique identifier has not been associated with any user account; and delivering a notification from the server suitable for the installed application to the client device. The non-transitory computer readable recording medium of claim 18, wherein the verification application is installed on a client device, and the application is verified The steps that have not previously been adopted and delivered the notification are performed in response to a user request. The non-transitory computer readable recording medium of any one of claims 18 to 19, further comprising, by the server, causing the application to be used by the user account, wherein the user account is configured to One or more of the client devices associated with the user account are permitted to have special privileges with respect to the employed application.