1. Field of the Invention
The present invention relates to the management of information handling systems. More specifically, embodiments of the invention provide a system, method, and computer-readable medium for separating the installation of an operating system from the fulfillment, installation, and entitlement of other digital assets.
2. Description of the Related Art
As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
In recent years, it has become common for manufacturers to offer standardized configurations of these systems bundled with an operating system (OS) and a selection of software applications, digital content, and associated services. Some of these same manufacturers also offer purchasers the ability to order a system custom-configured to their specification. These custom-configured systems, which are often ordered on-line, allow the purchaser to select the OS of their choice along with a selection of software and other digital assets to meet their individual needs. In some cases, the manufacturer may preinstall the OS and the selected digital assets on the system prior to delivery. In addition, the system may be further personalized (e.g., desktop themes and colors, etc.) as a service to the customer. Such customizations and personalizations may be limited only by the customer's patience and willingness to define or describe their ideal system.
However, the manufacture of custom-configured systems, commonly referred to as Custom Factory Integration (CFI), has begun to take longer and longer as the number of system options has grown. What used to be produced in a matter of days may now take weeks. As a result, system vendors are increasingly moving away from the CFI model to an Original Design Manufacturer (ODM) model where standardized system configurations are preloaded with a standard software image. Moreover, even large retailers may not have all of the digital assets desired by the customer, causing them to go to other retailers or on-line to complete their system purchase.
Furthermore, some OS vendors are known to impose various restrictions on system vendors as to what they can and cannot do. In some cases, these restrictions are intended to protect the OS vendor's brand, the user's out-of-box experience (OOBE), and the ability to be the first to make up-sell or cross-sell offers. Due to these restrictions, system vendors are generally not allowed to alter the initial user experience presented to the customer nor pre-install customer-desired changes, even when that information is available or could be provided by the customer. In view of the foregoing, there is a need for performing the fulfillment of digital assets while adhering to any restrictions imposed by an OS or digital assets vendor. Furthermore, there is also a need for separating the purchase of digital assets from their fulfillment resulting from transactions that are made on-line, at a physical Point of Sale (POS), those made After Point Of Sale (APOS), and those made within an enterprise business environment.
A system, method, and computer-readable medium are disclosed for separating the installation of an operating system from the fulfillment, installation, and entitlement of other digital assets. In various embodiments, a digital assets entitlement system is implemented for managing the entitlement of a system to process digital assets. In these and other embodiments, the system comprises a unique system identifier, which in turn comprises the unique identifiers of predetermined system components.
In various embodiments, the digital assets entitlement system receives purchase information associated with the purchase of a system, including its unique system identifier, and digital assets to be processed by the system. In these and other embodiments, the purchase transaction may be performed as an on-line, physical point-of-sale (POS), after-point-of-sale (APOS), or enterprise purchase transaction. The digital assets entitlement system associates the unique system identifier with the digital assets to generate digital assets entitlement data. Once the system is purchased, an operating system is installed, followed by the installation of a personalization agent, which then determines the system's unique system identifier.
The personalization agent then automatically establishes a connection to the digital assets entitlement system. Once connected, the personalization agent downloads the purchased digital assets, and their associated digital assets entitlement data, to the system. Once downloaded, the personalization agent uses the digital assets entitlement data to install the purchased digital assets on the system, thereby entitling the system to process the installed digital assets. In various embodiments, the digital assets comprise an operating system (OS), which is installed before any other digital assets are installed. In these and other embodiments, the operating system is installed according to restrictions imposed by the operating system manufacturer to protect the OS vendor's brand, the user's out-of-box experience (OOBE), and the ability to be the first to make up-sell or cross-sell offers.
The present invention may be better understood, and its numerous objects, features and advantages made apparent to those skilled in the art by referencing the accompanying drawings. The use of the same reference number throughout the several figures designates a like or similar element.
a-b are a simplified block diagram of a unique system identifier that remains the same when one of its associated system component identifiers has been changed;
a-b are a simplified block diagram of a unique system identifier that is changed when one of its associated system component identifiers has been changed;
a-b are a generalized flow chart of the performance of digital asset entitlement operations;
a-b are a generalized flow chart of the performance of digital assets entitlement and personalization operations in an on-line environment;
a-b are a generalized flow chart of the performance of digital assets entitlement and personalization operations in an after-point-of-sale (APOS) environment; and
a-d are a generalized flow chart of the performance of digital assets entitlement and personalization operations within an enterprise environment.
A system, method, and computer-readable medium are disclosed for separating the installation of an operating system from the fulfillment, installation, and entitlement of other digital assets. For purposes of this disclosure, an information handling system may include any instrumentality or aggregate of instrumentalities operable to compute, classify, process, transmit, receive, retrieve, originate, switch, store, display, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an information handling system may be a personal computer, a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. The information handling system may include random access memory (RAM), one or more processing resources such as a central processing unit (CPU) or hardware or software control logic, ROM, and/or other types of nonvolatile memory. Additional components of the information handling system may include one or more disk drives, one or more network ports for communicating with external devices as well as various input and output (I/O) devices, such as a keyboard, a mouse, and a video display. The information handling system may also include one or more buses operable to transmit communications between the various hardware components.
As used herein, a digital asset 246 refers to any digital asset such as a software application, a deliverable or performable service, music, video, software activation key, personalization instructions, files, etc. that are digitally deliverable either wholly or partially. As likewise used herein, a digital assets entitlement refers to the association of a predetermined digital asset 246 with a target system 204. In various embodiments, an entitlement record contains the digital assets entitlement data (e.g., license information, etc.) that allows the digital asset 246 to be processed by a target system 204 identified by a corresponding unique system identifier 206. In these and other embodiments, the entitlement record is processed by the entitlement module 228 and stored in the entitlement data repository 214. Likewise, as used herein, a system 204 may comprise a personal computer, a laptop computer, or a tablet computer operable to establish an on-line session with the digital assets entitlement system 218 over a connection to network 252. The system 204 may also comprise a personal digital assistant (PDA), a mobile telephone, or any other suitable device operable to store a unique system ID 206, perform digital asset entitlement operations with a personalization agent, and likewise operable to establish a connection with network 252.
In this embodiment, digital assets entitlement and system personalization operations are performed by a user, such as a system purchaser 202, in either a physical environment or an on-line environment. As an example, a physical environment may comprise a retailer 240 operating a physical point-of-sale (POS) system 242. As another example, an on-line environment may comprise a system manufacturer 234, after-point-of-sale (APOS) vendor 236, or digital assets vendor 238, that respectively accepts on-line orders for systems or digital assets over a connection to network 252.
If the digital assets entitlement and system personalization operations are performed in an on-line environment, then the system purchaser 202 decides whether to purchase a custom-configured or pre-configured system 204. If the system 204 is to be pre-configured, then it is selected for on-line purchase by the system purchaser 202 and its unique identifier 206 is determined. In one embodiment, the unique system identifier 206 is stored in the BIOS of the pre-configured system 204. However, if the system 204 is to be custom-configured, then it is custom-configured for on-line purchase by the system purchaser 202. Once manufactured by the system manufacturer 234, a unique system identifier is generated as described in greater detail herein.
In various embodiments, the manufacturing integration module 232 coordinates the custom configuration of the system 204 with the digital assets entitlement system 218. Likewise, the system identification and security module 224 coordinates the generation of the unique system identifier 204 and its storage in the repository of system identifier data 216. The system purchaser then selects a digital asset 246 for on-line purchase, followed by selecting personalization options for the pre-configured or custom-configured system. In various embodiments, the personalization module 226 coordinates the selection of personalization options with the digital assets entitlement system 218. As used herein a system personalization option refers to any feature, capability, or function that may be applied to a target system. As an example, a personal computer desktop wallpaper or user interface options (e.g., a “classic” interface) are personalization options.
However, if the digital assets entitlement and system personalization operations are performed in a physical environment, then the system purchaser 202 selects a pre-configured system 204 and physical representations of digital assets 246 to be purchased. In various embodiments, the digital asset 246 is physically represented as images and text on a card or a package, yet the digital assets themselves are not contained within the card or package. The system purchaser 202 then selects system personalization options for the pre-configured system. In various embodiments, the system personalization options are likewise physically represented as images and text on a card or a package.
The digital assets product identifier (ID) is then scanned with a scanner 244 from its corresponding physical representation, followed by scanning its corresponding digital assets activation key or other entitlement data. In various embodiments, it is not necessary to scan the digital assets activation key or other entitlement data as it is provided by the digital assets entitlement system 218 during digital asset entitlement operations described in greater detail herein. Data related to the previously selected personalization options are then likewise scanned, followed by determining the unique system identifier 206 of the pre-configured system 204. In various embodiments, the digital assets product ID, its associated activation key or entitlement data, the personalization option data, and the unique system identifier are represented by a bar code 248 or other indicia on a card or physical package. In various other embodiments, the digital assets product ID, its associated activation key or entitlement data, the personalization option data, and the unique system identifier is contained in a radio frequency identifier (RFID) 250 tag affixed to the physical representation of the digital asset. Those of skill in the art will realize that many such embodiments are possible and that the foregoing is not intended to limit the spirit, scope, or intent of the invention.
A purchase transaction for the custom-configured or pre-configured system 204 and any associated digital assets 246 and personalization options is then completed. In various embodiments, the processing of the purchase transaction is performed by the sales integration module 230. In these and other embodiments, the financial proceeds of the purchase transaction may be settled between multiple parties. For example, a system manufacturer 234 may receive a portion of the purchase transaction corresponding to the cost of the system 204. One or more digital assets vendors 238 may likewise receive a proportionate share of the purchase transaction corresponding to the digital asset 246 they respectively provide.
Digital asset entitlement operations, as described in greater detail herein, are then performed by the digital assets entitlement system 218 to bind the digital asset 246, the personalization options, and their respective digital assets entitlement data to the unique system identifier 206 of the target system 204. The resulting bound data, including data associated with the digital assets (e.g., installation files, etc.) is then stored in the repository of entitlement data 214 and the purchased system 204 is then delivered to the system purchaser 202. In various embodiments, the entitlement module 228 generates, and then processes, the digital assets entitlement data and the user service and support module 220 coordinates the delivery of the system 204 to the system purchaser 202.
Standard operating system (OS) out-of-the-box-experience (OOBE) or hypervisor boot operations are performed on the system 204, followed by loading a personalization agent 208. In various embodiments, the personalization agent 208 has a unique identifier that is associated with one or more unique system component identifiers. In one embodiment, the unique identifier of the personalization agent is uniquely associated with the current unique system identifier 206 associated with the system 204. In another embodiment, a portion of the personalization agent 208 is delivered to the system 204 in an encrypted form and is then decrypted prior to being loaded on the system 204. In this embodiment, the primary system identifier (e.g., service tag number, serial number, etc.), is used as a decryption key to decrypt the personalization agent 208.
In various other embodiments, secondary system identifiers are stored on the system 204 (e.g., in the BIOS, in Flash memory, on a hard disk, etc.) as well as in the digital assets entitlement system 218. In these and other embodiments, the digital assets entitlement system 218 uses the secondary system identifiers to encrypt a portion of the personalization agent 208 before it is downloaded to the system 204. Once downloaded, the unencrypted portion of the personalization agent 208 uses the secondary system identifiers stored on the system 204 to decrypt the encrypted portion of the personalization agent 208. In one embodiment, the secondary system identifiers are likewise encrypted and are first decrypted before they are used to decrypt the encrypted portion of the personalization agent 208. In another embodiment, the secondary system identifiers are stored in a Trusted Platform Module (TPM). Skilled practitioners of the art will recognize that many such embodiments are possible and the foregoing is not intended to limit the spirit, scope, or intent of the invention.
The personalization agent 208 queries the target system for its unique system identifier 206. In various embodiments, the unique system identifier 206 associated with the system 204 is stored in the target system's BIOS, flash memory, a hard disk, or other memory device. The personalization agent 208 then automatically establishes a connection with the digital assets entitlement system 218 and uses the unique system identifier 206 to authenticate the system 204. The unique system identifier 206 is then used by the personalization agent 208 to determine entitled digital assets and personalization options corresponding to the unique system identifier 206.
Once determined, the corresponding personalization options and digital asset 246, along with their associated digital assets entitlement data, are respectively downloaded to the target system 204 from the repository of digital assets 212 and the repository of entitlement data 214. In one embodiment, the personalization options and digital assets, along with their associated digital assets entitlement data, are downloaded from a single server 210 on the network 252. In another embodiment, the personalization options and digital assets are downloaded from one or more servers 210 on the network 252. In yet another embodiment, the personalization options, digital assets, and associated digital assets entitlement data are respectively downloaded from a plurality of servers 210 on a network 252. As an example, a first digital asset 246 may be provided by the system manufacturer 234 and a second digital asset 246 may be provided by a digital assets vendor 238. Likewise, a plurality of digital assets 246 may be provided by a corresponding plurality of digital assets vendors 238. Skilled practitioners of the art will realize that many such embodiments and examples are possible and the foregoing is not intended to limit the spirit, scope, or intent of the invention.
In various embodiments, the digital assets entitlement system 218 manages the respective location of the personalization options, digital assets, and associated digital assets entitlement data to initiate its provision. Once downloaded, the personalization agent 208 uses the digital assets entitlement data to install the digital assets 246 and personalization options on the system 204. Thereafter, the system purchaser 202 may decide to perform an after-point-of-sale (APOS) purchase of a digital asset 246. As used herein, an APOS purchase of digital assets refers to any purchase of a digital asset 246 made after the initial on-line or physical purchase of the system 204. In various embodiments, the APOS purchase of a digital asset 246 may be performed in a physical, on-line, or enterprise point-of-sale environment. If the APOS purchase is performed in an on-line environment, such as from APOS vendor 236, then the system purchaser 202 selects a digital asset 246 for on-line purchase. The personalization agent 208 then determines the unique system identifier 206 of the system 204. An APOS purchase transaction is then performed for purchase of the selected digital asset 246. However, if the APOS purchase is performed in a physical environment, then the purchaser selects a physical representation of a digital asset 246 to be purchased. The digital assets product identifier (ID) is then scanned from its corresponding physical representation, followed by scanning its corresponding digital assets activation key or other entitlement data.
Digital asset entitlement operations, as described in greater detail herein, are then performed by the digital assets entitlement system 218 to bind the digital asset 246 and their respective digital assets entitlement data associated with the APOS purchase to the unique system identifier 206 of the target system 204. The resulting bound data, including data associated with the digital assets (e.g., installation files, etc.) is then stored, as described in greater detail herein, in the digital assets entitlement system 218. The personalization agent 208, as likewise described in greater detail herein, then automatically establishes a connection with the digital assets entitlement system 218, downloads the purchased digital asset 246 and their associated digital assets entitlement data. Once downloaded, the personalization agent 208 then uses the associated digital assets entitlement data to install the downloaded digital asset 246 on the system 204.
a-b are a simplified block diagram of a unique system identifier that remains the same when one of its associated system component identifiers has been changed in accordance with an embodiment of the invention. As shown in
As described in greater detail herein, once generated, the original unique system identifier 320 is associated, such as through a binding operation, with predetermined digital assets 332 to generate a digital assets entitlement 330. As likewise described in greater detail herein, the digital assets entitlement 330 entitles a target system, which is associated with the original unique system identifier 320, to process the digital assets 332. However, it is not uncommon for system components to be replaced due to failure, erratic performance, becoming outmoded, or for other reasons. It will be appreciated that the entitlement 330 between the original unique system identifier 320 and the digital assets 332 may be compromised as a result of such a replacement. For example, as illustrated in
In various embodiments, extract, transform, and load (ETL) and other database operations are performed to manage the integrity of the relationship between the original unique system identifier 320 and the plurality of unique system component identifiers 302. As an example, the Original Motherboard ID 314 ‘19374WS238017BH’ may remain as a subset of the original unique system identifier 320, even though it may have been deactivated or invalidated as a unique system component identifier 302. However, in these and other embodiments, relational database operations known to those of skill in the art may be applied to maintain the relationship between the original unique system identifier 320, the New Original Motherboard ID 334 ‘56812FR853945PL’, and the unchanged unique system component identifiers 302. Accordingly, the integrity of the entitlement 330 between the original unique system identifier 320 and the digital assets 332 is perpetuated. It will be apparent to skilled practitioners of the art that many such embodiments are possible and the foregoing is not intended to limit the spirit, scope, or intent of the invention.
a-b are a simplified block diagram of a unique system identifier that is changed when one of its associated system component identifiers has been changed in accordance with an embodiment of the invention. As shown in
As described in greater detail herein, once generated, the original unique system identifier 320 is associated, such as through a binding operation, with predetermined digital assets 332 to generate a digital assets entitlement 330. As likewise described in greater detail herein, the digital assets entitlement 330 entitles a target system, which is associated with the original unique system identifier 320, to process the digital assets 332. However, it is not uncommon for system components to be replaced due to failure, erratic performance, becoming outmoded, or for other reasons. It will be appreciated that the entitlement 330 between the original unique system identifier 320 and the digital assets 332 may be compromised as a result of such a replacement. For example, as illustrated in
In various embodiments, a first set of operations are performed to remove the entitlement 330 between the original unique system identifier 320 and digital assets 332. A second set of operations are then performed to associate the new unique system identifier 420 with the digital assets 332 to generate a new entitlement 430. In these and other embodiments, the original unique system identifier 320 is then invalidated. Accordingly, the integrity of the original entitlement 330 between the original unique system identifier 320 and the digital assets 332 is perpetuated by the new entitlement 430 between the new unique system identifier 420 and the digital assets 332. Skilled practitioners of the art will recognize that many such embodiments are possible and the foregoing is not intended to limit the spirit, scope, or intent of the invention.
An encryption operation 524 is then performed on the source unique system identifier 520 to generate an original encrypted unique system identifier 528. In various embodiments, the encryption operation may comprise the use of a private key, a public key, key pairs, or any combination of keys and cryptographic operations such as implemented in a public key infrastructure (PKI). As an example, the original encrypted unique system identifier 528 may be generated using a private key associated with the manufacturer of the system and a public key associated with the system itself. In one embodiment, the Timestamp Date 510 ‘111909’ and the Timestamp Time 512 ‘14:27:26:34’ are likewise used to generate the encrypted unique system identifier 528. Skilled practitioners of the art will be familiar with such cryptographic operations and recognize that many such embodiments are possible and that the foregoing is not intended to limit the spirit, scope, or intent of the invention.
As described in greater detail herein, once generated, the original encrypted unique system identifier 528 is associated, such as through a binding operation, with predetermined digital assets 332 to generate a digital assets entitlement 530. As likewise described in greater detail herein, the digital assets entitlement 530 entitles a target system, which is associated with the original encrypted unique system identifier 528, to process the digital assets 332.
In various embodiments, the unique system component identifier of the replacement system component is unknown until it is replaced in the target system. In these and other embodiments, the system component is replaced in the target system, the target system is then initiated (e.g., booted), and an inventory of unique system component identifiers is performed. In one embodiment, one or more unique system component identifiers, such as a serial number or service tag, are visible and may be visually inventoried. In another embodiment, one or more unique system component identifiers, such as a motherboard, processor, or hard drive serial number, are not visible and may be automatically inventoried.
As shown in
An encryption operation 652 is then performed on the new source unique system identifier 650 to generate a new encrypted unique system identifier 628. As an example, the encryption operation may be performed using a private key associated with the target system and a public key associated with the provider of the replacement system component. The new encrypted unique system identifier 628 is then communicated to a digital assets entitlement system, which in turn performs a decryption operation 626 to generate a decrypted unique system identifier 622.
As likewise shown in
In various other embodiments, the provider of the replacement system component is able to determine its associated unique system component identifier. In one embodiment, the unique system component identifier is known in advance. In another embodiment, the unique system component identifier may be one of a pool of, or a range of, possible unique system component identifiers set aside for replacement purposes. As described in greater detail herein, a new source unique identifier is generated, using the unique system component identifier of the component to be replaced. Once the new source unique identifier is generated the unique system component identifier of the replaced system component is invalidated. In these and other embodiments, the system component is replaced in the target system, the target system is then initiated (e.g., booted), and an inventory of unique system component identifiers is performed. In one embodiment, one or more unique system component identifiers, such as a serial number or service tag, are visible and may be visually inventoried. In another embodiment, one or more unique system component identifiers, such as a motherboard, processor, or hard drive serial number, are not visible and may be automatically inventoried.
As shown in
Comparison operations 654 are then performed between the new source unique system identifier and the decrypted unique system identifier 622. If the comparison operations 654 are successful, then a first set of operations are performed to remove the entitlement between the original encrypted unique system identifier and digital assets 332. A second set of operations are then performed to associate the new encrypted unique system identifier 628 with the digital assets 332 to generate a new entitlement 630. Accordingly, the integrity of the original entitlement between the original encrypted unique system identifier and the digital assets 332 is perpetuated by the new entitlement 630 between the new encrypted unique system identifier 628 and the digital assets 332. Skilled practitioners of the art will recognize that many such embodiments are possible and the foregoing is not intended to limit the spirit, scope, or intent of the invention.
a-b are a generalized flow chart of the performance of digital asset entitlement operations in an embodiment of the invention, In this embodiment, digital asset entitlement operations are started in step 702, followed by the selection of a target system in step 704 for digital assets entitlement. The unique system identifier of the target system, as described in greater detail herein, is determined in step 706, followed by a determination being made in step 708 whether a device record has been established for the target system. If not, then the device record is generated in step 710. As used herein, a device record refers to a data record containing data related to a system which will receive an entitlement to process associated digital assets. In various embodiments, the unique system identifier of the target system is stored in the device record. In various embodiments, other records may be associated with the device record to further describe the system, such as its model, type, make, internal identifiers, etc.
Once the device record has been generated, or if it is determined in step 708 that it has already been established, then a determination is made in step 712 whether an account record has been established for a user. If not, then the account record is generated for the user in step 714. As used herein, an account record refers to a data record containing data related to the association of multiple devices or systems to one or more entities. In various embodiments, the entity may be a single individual or a group of individuals. As an example, the entity may be a household with multiple PCs, a small business with several employees, a large corporation with many employees, etc. Other records may be attached to the account to further describe the account holder, payment information related to the account, etc. Accounts may further be broken down or organized into sub-accounts as needed, such as to describe departments within an enterprise). In various embodiments, a user may be associated with a single device or system or multiple devices or systems in the account record. Conversely, a group of users may be associated with a single device or system or multiple devices in the account record. Further more groups of individual users may likewise be associated with groups of individual devices or systems. Those of skill in the art will recognize that many such associations are possible and the foregoing is not intended to limit the spirit, scope, or intent of the invention. Once the account record has been generated, or if it is determined in step 712 that it has already been established, then a determination is made in step 716 whether the account record is associated with the target system. If not, then the account record is associated with the target system in step 718.
Once the account record has been associated with the target system, or if it is determined in step 716 that it has already been associated, then a target list of digital assets is presented in step 720 for entitlement. A determination is then made in step 722 whether to generate an entitlement for a digital asset. If not, then a determination is made in step 732 whether to continue digital asset entitlement operations. If so, then the process is continued, proceeding with step 704. Otherwise digital asset entitlement operations are ended in step 734. However, if it is determined in step 722 to generate an entitlement for a digital asset, then a target digital asset is selected in step 724. A digital assets entitlement is then generated in step 726 by performing operations to associate the selected digital asset's corresponding license record with the aforementioned device record, account record, and other predetermined records. The resulting digital assets entitlement association is then added to the entitlement record in step 728. A determination is then made in step 730 whether to generate another digital assets entitlement. If so, the process is continued, proceeding with step 724. Otherwise, a determination is made in step 732 whether to continue digital asset entitlement operations. If so, then the process is continued, proceeding with step 704. Otherwise digital asset entitlement operations are ended in step 734.
a-b are a generalized flow chart of the performance of digital assets entitlement and personalization operations as implemented in an embodiment of the invention in an on-line environment. Various operating system (OS) vendors are known to impose restrictions on system vendors to protect their brand, the user's out-of-box experience (OOBE), and the ability to be the first to make up-sell or cross-sell offers. Due to these restrictions, system vendors are generally not allowed to alter the initial user experience presented to the customer, nor pre-install customer-desired changes, even when that information is available or could be provided by the customer.
In various embodiments, the installation of an OS on a target system is separated from the fulfillment, installation, and entitlement of digital assets to comply with any restrictions, user interaction or otherwise, imposed by an OS or digital assets vendor. In this embodiment, on-line digital assets entitlement and personalization operations are begun in step 802. In one embodiment, the on-line environment comprises telephone communications between the system purchaser and a human agent of a system and digital assets vendor. In another embodiment, the on-line environment comprises an interactive session between the system purchaser and a web site associated with a system and digital assets vendor.
A determination is then made in step 806 whether the target system is to be custom-configured or pre-configured. If it is determined in step 806 that the target system is to be a pre-configured system, then the system purchaser selects the target system for on-line purchase in step 808. The unique identifier for the selected pre-configured system is then determined in step 810. However, if it is determined in step 806 that the target system is to be a custom-configured system, then the system purchaser configures the target system for on-line purchase in step 812. The target system is then manufactured in step 814 according to the custom configuration selections made by the purchaser in step 812. Once manufactured, a unique system identifier is generated in step 816, as described in greater detail herein. Then, or after the unique system identifier is determined for the pre-configured system in step 810, the system purchaser selects digital assets for on-line purchase in step 818, followed by selecting personalization options for the custom-configured system in step 820.
A purchase transaction for the custom-configured or pre-configured target system and any associated digital assets and personalization options is completed in step 836. Digital asset entitlement operations, as described in greater detail herein, are then performed by a digital assets entitlement system in step 838 to bind the digital assets, the personalization options, and their respective digital assets entitlement data to the unique system identifier of the target system. The resulting bound data, including data associated with the digital assets (e.g., installation files, etc.) is then stored in the digital assets entitlement system in step 840 and the custom-configured or pre-configured system is then delivered to the system purchaser in step 842.
Standard operating system (OS) out-of-the-box-experience (OOBE) boot operations are performed on the new target system in step 844, followed by loading a personalization agent on the target system in step 846. The personalization agent then queries the target system for its unique system identifier in step 848. The personalization agent then automatically establishes a connection with the digital assets entitlement system in step 850 and uses the unique system identifier to authenticate the system. Then, in step 852, the unique system identifier is used by the digital assets entitlement system to determine entitled digital assets and personalization options corresponding to the unique system identifier.
Once determined, the corresponding personalization options and digital assets, along with their associated digital assets entitlement data, are downloaded in step 854 to the target system. Once downloaded, the personalization agent uses the digital assets entitlement data in step 856 to install the digital assets and personalization options on the target system. On-line digital assets entitlement and personalization operations are then ended in step 886.
The digital assets product identifier (ID) is then scanned, as described in greater detail herein, from its corresponding physical representation in step 928, followed by scanning its corresponding digital assets activation key or other entitlement data in step 930. Data related to the previously selected personalization options are then likewise scanned in step 932, followed by determining the unique system identifier of the pre-configured system in step 934.
A purchase transaction for the pre-configured target system and any associated digital assets and personalization options is completed in step 936. Digital asset entitlement operations, as described in greater detail herein, are then performed by a digital assets entitlement system in step 938 to bind the digital assets, the personalization options, and their respective digital assets entitlement data to the unique system identifier of the target system. The resulting bound data, including data associated with the digital assets (e.g., installation files, etc.) is then stored in the digital assets entitlement system in step 940 and the pre-configured system is then delivered to the system purchaser in step 942.
Standard operating system (OS) out-of-the-box-experience (OOBE) boot operations are performed on the new target system in step 944, followed by loading a personalization agent on the target system in step 946. The personalization agent then queries the target system for its unique system identifier in step 948. The personalization agent then automatically establishes a connection with the digital assets entitlement system in step 950 and uses the unique system identifier to authenticate the system. Then, in step 952, the unique system identifier is used by the personalization agent to determine entitled digital assets and personalization options corresponding to the unique system identifier.
Once determined, the corresponding personalization options and digital assets, along with their associated digital assets entitlement data, are downloaded in step 954 to the target system. Once downloaded, the personalization agent uses the digital assets entitlement data in step 956 to install the digital assets and personalization options on the target system. Point-of-sale digital assets entitlement and personalization operations are then ended in step 986.
a-b are a generalized flow chart of the performance of digital assets entitlement and personalization operations as implemented in an embodiment of the invention in an after-point-of-sale (APOS) environment. In various embodiments, the installation of an OS on a target system is separated from the fulfillment, installation, and entitlement of digital assets to comply with any restrictions, user interaction or otherwise, imposed by an OS or digital assets vendor. In this embodiment, APOS digital assets and personalization entitlement operations are begun in step 1002, followed by a determination being made in step 1004 whether the APOS purchase will be performed in an on-line or physical environment. If it is determined in step 1004 that the APOS purchase is to be performed in an on-line environment, then the purchaser selects digital assets in step 1006 to purchase on-line. The purchaser then likewise selects any personalization options to purchase on-line in step in step 1008. The personalization agent then determines the unique system identifier of the target system in step 1009.
However, if it was determined in step 1004 that the APOS purchase is to be performed in a physical environment, then the purchaser selects a physical representation of digital assets to be purchased in step 1010. The digital assets product identifier (ID) is then scanned from its corresponding physical representation in step 1012, followed by scanning its corresponding digital assets activation key or other entitlement data in step 1014. The system purchaser then selects system personalization options, which are likewise scanned in step 1016. The unique system identifier of the target system is then provided in step 1018. In various embodiments, the unique system identifier may be encoded in a bar code, a radio frequency identifier (RFID) tag, a flash memory device, or presented in printed in either printed form or verbally communicated. Skilled practitioners of the art will realize that many such embodiments are possible and that the foregoing is not intended to limit the spirit, scope, or intent of the invention.
Once the unique system identifier has been determined in step 1020 or provided in step 1018, APOS purchase transaction is then performed in step 1020 for the purchase of the digital assets and personalization options. Digital asset entitlement operations, as described in greater detail herein, are then performed by the digital assets entitlement system in step 1022 to bind the digital assets, the personalization options, and their respective digital assets entitlement data associated with the APOS purchase to the unique system identifier of the target system. The resulting bound data, including data associated with the digital assets (e.g., installation files, etc.) is then stored in the digital assets entitlement system in step 1024.
Standard operating system (OS) out-of-the-box-experience (OOBE) are performed on the new target system in step 1026. A determination is then made in step 1030 whether a personalization agent is installed on the existing system. If not, then a personalization agent is downloaded and installed on the existing system in step 1032. Then, or if it is determined in step 1030 that a personalization agent is already installed on the existing system, the personalization agent queries the existing system for its unique system identifier in step 1048.
The personalization agent then automatically establishes a connection with the digital assets entitlement system in step 1050 and uses the unique system identifier to authenticate the system. Then, in step 1052, the unique system identifier is used by the personalization agent to determine entitled digital assets and personalization options corresponding to the unique system identifier. Once determined, the corresponding personalization options and digital assets, along with their associated digital assets entitlement data, are downloaded in step 1054 to the target system. Once downloaded, the personalization agent uses the digital assets entitlement data in step 1056 to install the digital assets and personalization options on the target system. APOS digital assets and personalization entitlement operations are then ended in step 1058.
a-d are a generalized flow chart of the performance of digital assets entitlement and personalization operations as implemented in an embodiment of the invention within an enterprise environment. In various embodiments, an enterprise or large business may have their systems, associated unique system identifiers, and their corresponding digital assets entitlements, organized within a single account or in multiple sub-accounts. As an example, sub-accounts may be associated with corresponding branch offices, departments, or other organizational units are established by an enterprise manager. In these and other embodiments, the enterprise manager may establish policies that govern the approved procurement and use of certain systems, software, services, content, personalizations, and other digital assets as approved for corporate use. Likewise, the enterprise manager may also disallow certain systems and digital assets as well.
In various embodiments, the installation of an OS on a target system is separated from the fulfillment, installation, and entitlement of digital assets to comply with any restrictions, user interaction or otherwise, imposed by an OS or digital assets vendor. In this embodiment, digital assets entitlement and system personalization operations are begun by a system purchaser in step 1102, followed by a determination being made in step 1104 whether the entitlement and system personalization operations are performed in a physical environment or an on-line environment. If it is determined in step 1104 that the digital assets entitlement and system personalization operations are performed in an on-line environment, then a determination is made in step 1106 whether the target system is to be custom-configured or pre-configured. If it is determined in step 1106 that the target system is to be a pre-configured system, then the system purchaser selects the target system for on-line purchase in step 1108. The unique identifier for the selected pre-configured system is then determined in step 1110.
However, if it is determined in step 1106 that the target system is to be a custom-configured system, then the system purchaser configures the target system for on-line purchase in step 1112. The target system is then manufactured in step 1114 according to the custom configuration selections made by the purchaser in step 1112. Once manufactured, a unique system identifier is generated in step 1116, as described in greater detail herein. Then, or after the unique system identifier is determined for the pre-configured system in step 1110, the system purchaser selects digital assets for on-line purchase in step 1118, followed by selecting personalization options for the custom-configured system in step 1120. However, if it is determined in step 1104 that the entitlement and system personalization operations are to be performed in a physical environment, then the system purchaser selects a pre-configured system in step 1122 to purchase. The system purchaser then selects a physical representation of digital assets to be purchased in step 1124. In various embodiments, the digital goods are physically represented as images and text on a card or a package, yet the digital goods themselves are not contained within the card or package. The system purchaser then selects system personalization options for the pre-configured system in step 1126. In various embodiments, the system personalization options are physically represented as images and text on a card or a package. The digital goods product identifier (ID) is then scanned from its corresponding physical representation in step 1128, followed by scanning its corresponding digital goods activation key or other entitlement data in step 1130. Data related to the previously selected personalization options are then likewise scanned in step 1132, followed by determining the unique system identifier of the pre-configured system in step 1134.
Once the system personalization data has been provided in step 1120, or the unique system identifier has been determined in step 1134, a determination is made in step 1136 whether the selections conform to enterprise procurement, purchase transaction, and usage rules. If not, then the selection of system, digital assets, and personalization options are revised in step 1138 and the process is continued, proceeding with step 1136. Otherwise, a purchase transaction for the custom-configured or pre-configured target system and any associated digital assets and personalization options is completed in step 1140. Digital asset entitlement operations, as described in greater detail herein, are then performed by a digital assets entitlement system in step 1142 to bind the digital assets, the personalization options, and their respective digital assets entitlement data to the unique system identifier of the target system. The resulting bound data, including data associated with the digital assets (e.g., installation files, etc.) is then stored in the digital assets entitlement system in step 1144 and the custom-configured or pre-configured system is then delivered to the system purchaser in step 1146.
Standard operating system (OS) out-of-the-box-experience (OOBE) boot operations are performed on the new target system in step 1148, followed by loading a personalization agent on the target system in step 1150. The personalization agent then queries the target system for its unique system identifier in step 1152. The personalization agent then automatically establishes a connection with the digital assets entitlement system in step 1154 and uses the unique system identifier to authenticate the system. Then, in step 1156, the unique system identifier is used by the personalization agent to determine entitled digital assets and personalization options corresponding to the unique system identifier.
Once determined, the corresponding personalization options and digital assets, along with their associated digital assets entitlement data, are downloaded in step 1158 to the target system. Once downloaded, the personalization agent uses the digital assets entitlement data in step 1160 to install the digital assets and personalization options on the target system. A determination is then made in step 1162 whether to perform an after-point-of-sale (APOS) purchase of digital assets. If it is determined in step 1162 to not perform an APOS purchase of digital assets, then a determination is made in step 1188 whether to continue digital assets entitlement and system personalization operations. If so, then the process is continued, proceeding with step 1160. Otherwise, digital assets entitlement and system personalization operations are ended in step 1190.
However, if it is determined in step 1162 to perform an APOS purchase of digital assets, then a determination is made in step 1164 whether the APOS purchase will be performed in an on-line or physical environment. If it is determined in step 1164 that the APOS purchase is to be performed in an on-line environment, then the purchaser selects digital assets in step 1165 to purchase on-line. The purchaser then likewise selects any personalization options to purchase on-line in step in step 1166. The personalization agent then determines the unique system identifier of the target system in step 1178, and a determination is made in step 1180 whether the selections conform to enterprise procurement, purchase transaction, and usage rules. If not, then the selection of digital assets and personalization options are revised in step 1182 and the process is continued, proceeding with step 1180. Otherwise, an APOS purchase transaction is performed in step 1184 for the purchase of the digital assets and personalization options.
Digital asset entitlement operations, as described in greater detail herein, are then performed by the digital assets entitlement system in step 1186 to bind the digital assets, the personalization options, and their respective digital assets entitlement data associated with the APOS purchase to the unique system identifier of the target system. The resulting bound data, including data associated with the digital assets (e.g., installation files, etc.) is then stored in the digital assets entitlement system in step 1188. The process is then continued, proceeding with step 1152.
However, if it was determined in step 1164 that the APOS purchase is to be performed in a physical environment, then the purchaser selects a physical representation of digital assets to be purchased in step 1167. The digital assets product identifier (ID) is then scanned from its corresponding physical representation in step 1168, followed by scanning its corresponding digital assets activation key or other entitlement data in step 1170. The system purchaser then selects system personalization options, which are likewise scanned in step 1172. The process is then continued, proceeding with step 1178.
The present invention is well adapted to attain the advantages mentioned as well as others inherent therein. While the present invention has been depicted, described, and is defined by reference to particular embodiments of the invention, such references do not imply a limitation on the invention, and no such limitation is to be inferred. The invention is capable of considerable modification, alteration, and equivalents in form and function, as will occur to those ordinarily skilled in the pertinent arts. The depicted and described embodiments are examples only, and are not exhaustive of the scope of the invention.
For example, the above-discussed embodiments include software modules that perform certain tasks. The software modules discussed herein may include script, batch, or other executable files. The software modules may be stored on a machine-readable or computer-readable storage medium such as a disk drive. Storage devices used for storing software modules in accordance with an embodiment of the invention may be magnetic floppy disks, hard disks, or optical discs such as CD-ROMs or CD-Rs, for example. A storage device used for storing firmware or hardware modules in accordance with an embodiment of the invention may also include a semiconductor-based memory, which may be permanently, removably or remotely coupled to a microprocessor/memory system. Thus, the modules may be stored within a computer system memory to configure the computer system to perform the functions of the module. Other new and various types of computer-readable storage media may be used to store the modules discussed herein. Additionally, those skilled in the art will recognize that the separation of functionality into modules is for illustrative purposes. Alternative embodiments may merge the functionality of multiple modules into a single module or may impose an alternate decomposition of functionality of modules. For example, a software module for calling sub-modules may be decomposed so that each sub-module performs its function and passes control directly to another sub-module.
Consequently, the invention is intended to be limited only by the spirit and scope of the appended claims, giving full cognizance to equivalents in all respects.
Number | Name | Date | Kind |
---|---|---|---|
5440498 | Timm | Aug 1995 | A |
5442541 | Hube et al. | Aug 1995 | A |
5490216 | Richardson, III | Feb 1996 | A |
5502831 | Grube et al. | Mar 1996 | A |
5659614 | Bailey, III | Aug 1997 | A |
5715314 | Payne et al. | Feb 1998 | A |
5745568 | O'Connor et al. | Apr 1998 | A |
5864664 | Capps, Jr. et al. | Jan 1999 | A |
5890165 | Boudrie | Mar 1999 | A |
5892900 | Ginter et al. | Apr 1999 | A |
5912696 | Buehl | Jun 1999 | A |
5948078 | Joffe | Sep 1999 | A |
5956505 | Manduley | Sep 1999 | A |
6032184 | Cogger | Feb 2000 | A |
6032859 | Muehlberger et al. | Mar 2000 | A |
6080207 | Kroening et al. | Jun 2000 | A |
6112188 | Hartnett | Aug 2000 | A |
6170059 | Pruett et al. | Jan 2001 | B1 |
6189008 | Easty | Feb 2001 | B1 |
6209089 | Selitrennikoff et al. | Mar 2001 | B1 |
6226618 | Downs | May 2001 | B1 |
6243468 | Pearce et al. | Jun 2001 | B1 |
6292941 | Jollands | Sep 2001 | B1 |
6301612 | Selitrennikoff et al. | Oct 2001 | B1 |
6314418 | Namba | Nov 2001 | B1 |
6321231 | Jebens | Nov 2001 | B1 |
6321262 | Springer | Nov 2001 | B1 |
6324525 | Kramer et al. | Nov 2001 | B1 |
6389403 | Dorak, Jr. | May 2002 | B1 |
6425126 | Branson et al. | Jul 2002 | B1 |
6502205 | Yanai et al. | Dec 2002 | B1 |
6642946 | Janes et al. | Nov 2003 | B1 |
6647532 | Boede et al. | Nov 2003 | B1 |
6694384 | Moeller et al. | Feb 2004 | B1 |
6721881 | Bian et al. | Apr 2004 | B1 |
6816090 | Teckchandani | Nov 2004 | B2 |
6829704 | Zhang et al. | Dec 2004 | B2 |
6865655 | Andersen | Mar 2005 | B1 |
6931407 | Brown | Aug 2005 | B1 |
6931558 | Jeffe et al. | Aug 2005 | B1 |
6944611 | Flank | Sep 2005 | B2 |
7047411 | DeMello et al. | May 2006 | B1 |
7093032 | Minogue et al. | Aug 2006 | B2 |
7120593 | Fry et al. | Oct 2006 | B1 |
7130807 | Mikurak | Oct 2006 | B1 |
7278131 | Gunyakti et al. | Oct 2007 | B2 |
7290149 | Alababra et al. | Oct 2007 | B2 |
7308410 | Bowe, Jr. | Dec 2007 | B2 |
7330997 | Odom | Feb 2008 | B1 |
7352999 | Miettinen | Apr 2008 | B2 |
7412534 | Tsang et al. | Aug 2008 | B2 |
7415439 | Kontio et al. | Aug 2008 | B2 |
7417546 | Llorca et al. | Aug 2008 | B2 |
7428413 | Fink | Sep 2008 | B2 |
7444436 | Wille | Oct 2008 | B2 |
7472272 | Stamos | Dec 2008 | B2 |
7483860 | Cronce et al. | Jan 2009 | B2 |
7496739 | Raghavan et al. | Feb 2009 | B1 |
7503072 | Hughes et al. | Mar 2009 | B2 |
7506382 | Padole et al. | Mar 2009 | B2 |
7516104 | Scardino | Apr 2009 | B1 |
7523072 | Stefik et al. | Apr 2009 | B2 |
7526451 | Park et al. | Apr 2009 | B2 |
7546545 | Garbow et al. | Jun 2009 | B2 |
7555447 | Chinnappan et al. | Jun 2009 | B2 |
7565325 | Lenard et al. | Jul 2009 | B2 |
7593898 | Tsuei et al. | Sep 2009 | B1 |
7594275 | Zhu et al. | Sep 2009 | B2 |
7653574 | Harper | Jan 2010 | B2 |
7656271 | Ehrman | Feb 2010 | B2 |
7743064 | Faulkner | Jun 2010 | B2 |
7761921 | Gannon | Jul 2010 | B2 |
7783737 | Fujino et al. | Aug 2010 | B2 |
7809699 | Passmore | Oct 2010 | B2 |
7925973 | Allaire et al. | Apr 2011 | B2 |
7971199 | Chen | Jun 2011 | B1 |
8001052 | Dunkeld | Aug 2011 | B2 |
8065303 | Probst et al. | Nov 2011 | B2 |
8126814 | Yellai et al. | Feb 2012 | B2 |
8180681 | Pieper | May 2012 | B2 |
8219769 | Wilk | Jul 2012 | B1 |
8219850 | Wang et al. | Jul 2012 | B1 |
8229858 | Mazza et al. | Jul 2012 | B1 |
8230434 | Armstrong | Jul 2012 | B2 |
8261258 | Jianu et al. | Sep 2012 | B1 |
8271336 | Mikurak | Sep 2012 | B2 |
8341455 | Maki et al. | Dec 2012 | B2 |
8429641 | O'Connor | Apr 2013 | B2 |
8452731 | Preslan et al. | May 2013 | B2 |
8468139 | O'Connor et al. | Jun 2013 | B1 |
8510226 | Coley et al. | Aug 2013 | B2 |
8533156 | Ryder | Sep 2013 | B2 |
8538458 | Haney | Sep 2013 | B2 |
8548919 | Lo | Oct 2013 | B2 |
8615446 | O'Connor et al. | Dec 2013 | B2 |
8645398 | Xia | Feb 2014 | B2 |
8682795 | Lenkov | Mar 2014 | B2 |
8688586 | Pride | Apr 2014 | B2 |
8700533 | Levin et al. | Apr 2014 | B2 |
8949401 | Haze | Feb 2015 | B2 |
20010044782 | Hughes et al. | Nov 2001 | A1 |
20020046232 | Adams et al. | Apr 2002 | A1 |
20020059270 | Schlabach et al. | May 2002 | A1 |
20020076204 | Nakano et al. | Jun 2002 | A1 |
20020077986 | Kobata | Jun 2002 | A1 |
20020087345 | Bly | Jul 2002 | A1 |
20020088855 | Hodes | Jul 2002 | A1 |
20020091456 | O'Connor | Jul 2002 | A1 |
20030028439 | Cox | Feb 2003 | A1 |
20030028451 | Ananian | Feb 2003 | A1 |
20030033205 | Nowers et al. | Feb 2003 | A1 |
20030060157 | Henrick | Mar 2003 | A1 |
20030088571 | Ekkel | May 2003 | A1 |
20030110126 | Dunkeld et al. | Jun 2003 | A1 |
20030120928 | Cato et al. | Jun 2003 | A1 |
20030149750 | Franzenburg | Aug 2003 | A1 |
20040003039 | Humphrey et al. | Jan 2004 | A1 |
20040022227 | Lynch | Feb 2004 | A1 |
20040044901 | Serkowski et al. | Mar 2004 | A1 |
20040059938 | Hughes et al. | Mar 2004 | A1 |
20040093273 | Laurent et al. | May 2004 | A1 |
20040128551 | Walker et al. | Jul 2004 | A1 |
20040133792 | Dublish et al. | Jul 2004 | A1 |
20040143746 | Ligeti et al. | Jul 2004 | A1 |
20040250066 | DiLuoffo et al. | Dec 2004 | A1 |
20040268267 | Moravcsik | Dec 2004 | A1 |
20050027657 | Leontiev et al. | Feb 2005 | A1 |
20050060388 | Tasumi et al. | Mar 2005 | A1 |
20050229047 | Hanes et al. | Oct 2005 | A1 |
20050262573 | Bo et al. | Nov 2005 | A1 |
20050268115 | Barde et al. | Dec 2005 | A1 |
20060062426 | Levy et al. | Mar 2006 | A1 |
20060161635 | Lamkin et al. | Jul 2006 | A1 |
20060212649 | Roberts | Sep 2006 | A1 |
20060229904 | Hunter et al. | Oct 2006 | A1 |
20060276174 | Katz et al. | Dec 2006 | A1 |
20070106586 | Mack | May 2007 | A1 |
20070124349 | Taylor | May 2007 | A1 |
20070130233 | Christensen | Jun 2007 | A1 |
20070157196 | Goicea et al. | Jul 2007 | A1 |
20070174621 | Ducharme | Jul 2007 | A1 |
20070233580 | Pike | Oct 2007 | A1 |
20070255758 | Zheng et al. | Nov 2007 | A1 |
20070294566 | Solyanik | Dec 2007 | A1 |
20080005033 | Clark et al. | Jan 2008 | A1 |
20080077927 | Armstrong | Mar 2008 | A1 |
20080109446 | Wang | May 2008 | A1 |
20080172583 | Mahajan et al. | Jul 2008 | A1 |
20080177807 | Dile et al. | Jul 2008 | A1 |
20080195871 | Peinado et al. | Aug 2008 | A1 |
20080208933 | Lyon | Aug 2008 | A1 |
20080215633 | Dunkeld et al. | Sep 2008 | A1 |
20080234047 | Nguyen | Sep 2008 | A1 |
20080301676 | Alpern | Dec 2008 | A1 |
20090063350 | Briggs et al. | Mar 2009 | A1 |
20090083843 | Wilkinson et al. | Mar 2009 | A1 |
20090089340 | Ohr et al. | Apr 2009 | A1 |
20090094647 | Inoue et al. | Apr 2009 | A1 |
20090125393 | Hwang et al. | May 2009 | A1 |
20090164470 | Savage et al. | Jun 2009 | A1 |
20090187491 | Bull et al. | Jul 2009 | A1 |
20090193102 | Trujillo | Jul 2009 | A1 |
20090217352 | Shen et al. | Aug 2009 | A1 |
20090228368 | Brown | Sep 2009 | A1 |
20090228488 | Brand et al. | Sep 2009 | A1 |
20090234892 | Anglin et al. | Sep 2009 | A1 |
20090248883 | Suryanarayana et al. | Oct 2009 | A1 |
20090265545 | Satoh et al. | Oct 2009 | A1 |
20090300673 | Bachet et al. | Dec 2009 | A1 |
20090300719 | Ferris | Dec 2009 | A1 |
20100106687 | Marcy et al. | Apr 2010 | A1 |
20100106691 | Preslan et al. | Apr 2010 | A1 |
20100122030 | Peters et al. | May 2010 | A1 |
20100125903 | Devarajan et al. | May 2010 | A1 |
20100146425 | Lance et al. | Jun 2010 | A1 |
20100174918 | Hoffman et al. | Jul 2010 | A1 |
20100235921 | Foster | Sep 2010 | A1 |
20100257142 | Murphy et al. | Oct 2010 | A1 |
20100257185 | Dvir et al. | Oct 2010 | A1 |
20100257346 | Sosnosky et al. | Oct 2010 | A1 |
20100257403 | Virk et al. | Oct 2010 | A1 |
20100306227 | Fleming et al. | Dec 2010 | A1 |
20100306267 | Zamkoff et al. | Dec 2010 | A1 |
20100319072 | Abzarian et al. | Dec 2010 | A1 |
20100325735 | Etchegoyen | Dec 2010 | A1 |
20110016466 | Liu et al. | Jan 2011 | A1 |
20110022812 | van der Linden et al. | Jan 2011 | A1 |
20110063234 | Liu | Mar 2011 | A1 |
20110072291 | Murase | Mar 2011 | A1 |
20110099200 | Blount et al. | Apr 2011 | A1 |
20110107411 | McClain | May 2011 | A1 |
20110173405 | Grabarnik et al. | Jul 2011 | A1 |
20110178886 | O'Connor | Jul 2011 | A1 |
20110178887 | O'Connor | Jul 2011 | A1 |
20110184998 | Palahnuk et al. | Jul 2011 | A1 |
20110231280 | Farah | Sep 2011 | A1 |
20110231281 | O'Connor | Sep 2011 | A1 |
20110246766 | Orsini et al. | Oct 2011 | A1 |
20110314363 | Isozu et al. | Dec 2011 | A1 |
20120036041 | Hesselink | Feb 2012 | A1 |
20120191272 | Andersen | Jul 2012 | A1 |
20120191568 | Gandhi | Jul 2012 | A1 |
20120197811 | Kearney | Aug 2012 | A1 |
20120221709 | Bowes | Aug 2012 | A1 |
20120304248 | Watts | Nov 2012 | A1 |
20130067332 | Greenwood et al. | Mar 2013 | A1 |
20130074011 | Nakamura et al. | Mar 2013 | A1 |
20130339501 | Haze et al. | Dec 2013 | A1 |
20140020105 | Nix | Jan 2014 | A1 |
20140059236 | Lo | Feb 2014 | A1 |
20140108616 | Haze | Apr 2014 | A1 |
20140317057 | O'Connor | Oct 2014 | A1 |
20140330934 | O'Connor | Nov 2014 | A1 |
20140358802 | Biswas | Dec 2014 | A1 |
20150089598 | Keyes | Mar 2015 | A1 |
Number | Date | Country |
---|---|---|
2445303 | Jul 2008 | GB |
Entry |
---|
Adaptive approach to hardware alteration for digital rights management by Yinyan Yu and Zhi Tang, National key Lab of Text processing Technology, Peking University, WISA 2004, LNCS 3325, pp. 238-260, 2004. |
Lifeboat—An automatic backup by Ted Bonkemburg, Dejan Diklic, 2004 LISA XVIII Nov. 14-19, 2004, pp. 159-170. |
Yu et al., An adaptive approach to hardware alteration for digital rights management [Online], 2004 [Retrieved: Apr. 28, 2014] Proceedings of the 5th international conference on Information Security Applications (WISA'04), Springer-Verlag, pp. 238-250, [Retrieved from: http://link.springer.com/content/pdf/1 0.1 007%2F978-3-540-31815-6—20.pdf]. |
Hill, Keith, “A Perspective: The Role of Identifiers in Managing and Protecting Intellectual Property in the Digital Age” [Online], v Jul. 1999 [Retrieved on: Apr. 28, 2014], Proceedings of the IEEE (vol. 87, Issue: 7), pp. 1228-1238, [Retrieved from: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber= 771074]. |
Laplink, Laplink Offers Licensing for Windows XP to Windows 7 Upgrade Solution, Oct. 28, 2009. |
Backup P2P Secured peer to peer backup, http://www.ohloh.net/p/p2pbackupsmile, printed Jun. 18, 2010. |
Landers et al., PeerStore: Better Performance by Relaxing in Peer-to-Peer Backup, Fakultät Für Informatik , Technische Universität München, 2004 http://www.computer.org/portal/web/csdl/doi/10.1109/PTP.2004.1334933. |
Peer-to-Peer Viral Backup: Cucku 2.0 Definitely Scores Points for Imagination, http://www.fileslinger.com/2009/05/peer-to-peer-viral-backup-cucku-20-definitely-scores-points-forimagination, printed Jun. 18, 2010. |
T. Bonkenburg et al, LifeBoat—An Autonomic Backup and Restore Solution, http://www.usenix.org/event/lisa04/tech/full—papers/bonkenburg/bonkenburg.pdf, 2004 LISA XVIII—Nov. 14-19, 2004—Atlanta, GA. |
M. Vrable, Cumulus: Filesystem Backup to the Cloud, http://cseweb.ucsd.edu/˜voelker/pubs/cumulus-fast09.pdf, Feb. 26, 2009. |
L. Mearian, Start-up unveils hybrid cloud/on-site backup service, http://www.itworld.com/storage/64972/start-unveils-hybrid-cloudon-site-backup-service, Mar. 24, 2009. |
storage-switzerland.com, Hybrid Cloud Backup for the SMB, http://www.storage-switzerland.com/Articles/Entries/2009/4/24—Hybrid—Cloud—Backup—for—the—SMB.html, Apr. 24, 2009. |
M. Staimer, Asigra, Why Cloud Backup/Recovery (Private, Public, or Hybrid) Will be Your Data Protection, http://www.docstoc.com/docs/16851799/Why-Cloud-Backup-Recovery-(Private-Public-or-Hybrid)-Will-be, printed Jun. 18, 2010. |
Cisco License Manager 2.2, http://www.cisco.com/en/US/products/ps7138/index.html, printed Jun. 15, 2010. |
Sprint and MercuryMD Team Up to Offer Healthcare Providers One-Stop Shopping Opportunity for Mobility Solutions, PR Newswire. New York: Apr. 27, 2004. p. 1; http://proquest.umi.com/pqdweb?did=624136671 &sid=4&Fmt=3&clientld=19649&RQT =309& VName=POD. |
Michigan Retailers Association, Member Services, Electronic Gift Card Processing FAQ, http://www.retailers.com/memberservices/giftcardsfaq.html, printed Apr. 19, 2010. |
Proquest, Sprint and MercuryMD Team up to Offer Healthcare Providers One-Stop Shopping Opportunity for Mobility Solutions, PR Newswire, New York, Apr. 27, 2004. |
Number | Date | Country | |
---|---|---|---|
20110178886 A1 | Jul 2011 | US |