Method and apparatus for provisioning software

This patent relates to computers in general, and more specifically to computer management systems.

A large proportion of the world's population cannot afford to own a computer and / or various software that enables it to be used efficiently. There is a need to provide people in developing countries with affordable access to computing. This is also true in light of the traditional structure of the software industry, where software licenses are generally sold on the basis of perpetual licenses. People are also forbidden to even use such software for a short period of time, such as for training purposes, as a result of not having sufficient funds to purchase permanent licenses for various software. .. Even in developed countries, computer users are discouraged by the need to purchase a permanent license for a particular software if they need to use it for a period of time.

This is especially true for operating systems for computers. When using the computing power of a technologically advanced computer and the resources available through the Internet, use the computer and a high-performance operating system to control the communication between that computer and the Internet and other resources. It is necessary to. But as with software, operating systems are generally sold with perpetual licenses, and the price of such perpetual licenses is usually very high compared to the purchasing power of people in different countries of the Third World. Is.

<p> Various business models have been tested to provide a solution that replaces existing ones so that software can be used without the need to purchase a permanent license. For example, various companies have ASP (application service). It provides software based on the provider) model, which allows users to access software that resides on a server in a network such as the Internet by logging in to that server. However, this method requires the user to be constantly connected to the server over the Internet. This is not a solution that can be developed in various developing countries where access to the Internet is expensive and unreliable. Alternatively, software providers often allow users to download software for a period of time, which is generally for trial purposes, after which the user must purchase a permanent license for the software. Must be. However, the time to use such trial software is usually fixed, and users can buy time for their own choice or add fixed time. You cannot choose to update the user of the trial software. For easy understanding, there is a need to provide users with such services in a way that allows them to purchase software services in a variety of different ways.</p>

<p> A dynamic software provisioning system makes it possible to deliver software on multiple different computing devices based on the desired business process. This dynamic software provisioning system allows users to use the operating system for a specific amount of time, for a specific amount of usage, or any other desired method. You can request it from service) or from a third party. This provisioning service handles requests from users or third parties who want to provide use of the operating system, responds to the request, and operates system for the specific device specified by the request. Provide use of. This dynamic software activation system also includes a local provisioning module located on a device that uses the operating system, which activates or activates the operating system based on instructions received from the provisioning service. Deactivate it.</p><p> In one alternative implementation, a dynamic software provisioning system allows a user to purchase a right to use the software by purchasing a prepaid card. The prepaid card allows the user to download a provisioning packet, which allows the user to use the software for a specified amount of time. In yet another implementation, the dynamic software system allows the underwriter to sell the computer with the software and a specified amount of time to use the software.</p><p> In yet another alternative implementation, a dynamic software provisioning system allows users to purchase operating system usage rights by purchasing a prepaid card. The prepaid card allows the user to download a provisioning packet, which allows the user to use the operating system for a specified amount of time. In yet another implementation, a dynamic software system allows an underwriter to sell a computer with an operating system and a specified amount of time to use that operating system.</p><p> In yet another implementation, the dynamic software provisioning system is the step of receiving a registration request to register the provided device, which registration request is the hardware ID of the provided device. A step that includes, a step that creates a certificate for the provided device, and a step that receives a packet creation request requesting that a packet for the provided device be created, and the packet creation request is for the provided device. A step that includes the initialization key for the device and a step that creates a packet for the provided device, and the packet for the provided device approves the first usage of the service on the provided device. Includes computer-readable media with computer-executable instructions for performing methods including steps including information.</p>

The following text provides a detailed description of many different embodiments, but the legal scope of this description is defined by the wording of the claims attached to this patent. I want to be understood. This detailed description should be construed as merely exemplary and does not describe all possible embodiments. This is because it seems impractical, if not impossible, to explain all possible embodiments. Many alternative embodiments can be implemented using current technology or technology developed after the filing date of the patent, which will continue to fall within the claims that define the invention.

In addition, the terms are clearly defined in the present patent by using the sentence "when used in the present specification, the term" "is defined as meaning ..." or a similar sentence. Unless, there is no intention to limit the meaning of the term beyond its candid or ordinary meaning, either explicitly or implicitly, and such term is in any section of this patent. It should be understood that it should not be construed as being limited to the scope based on any of the statements made in (excluding the terms of the scope of patent claims). As long as any of the terms in the claims attached to this patent is referred to within this patent in a manner consistent with a single meaning, it exclusively confuses the reader. It is intended to be clear so as not to cause it, and it is not intended to limit the terms in the scope of such claims to their single meaning by implication or the like. Finally, the scope of any claim element is 35. It is not intended to be construed in accordance with the application of USC Section 112, paragraph 6.

(Network) Figure 1 shows a network 10 that can be used to implement a dynamic software provisioning system. Network 10 can be the Internet, a VPN (virtual private network), or any other network that allows one or more computers, communication devices, databases, etc. to be communicatively connected to each other. .. The network 10 can be connected to the personal computer 12 and the computer terminal 14 via Ethernet (registered trademark) 16, router 18, and terrestrial communication line 20. On the other hand, network 10 is a laptop computer 22 and personal data over wireless communication station 26 and wireless link 28. You can connect to assistant) 24 wirelessly. Similarly, the server 30 can be connected to the network 10 using the communication link 32, and the mainframe 34 can be connected to the network 10 using another communication link 36. As described in more detail below, one or more components of this dynamic software provisioning system can be stored and function on any of the various devices connected to network 10.

(Computer) Figure 2 shows a computing device in the form of a computer 110 that can be used by connecting to network 10 to implement one or more components of a dynamic software provisioning system. The components of the computer 110 can include, but are not limited to, a processor 120, a system memory 130, and a system bus 121 that connects various system components, including system memory, to the processor 120. The system bus 121 can be of any of multiple types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus that uses one of a variety of bus architectures. For example, such architectures include ISA (Industry Standard Architecture) bus, MCA (Micro Channel Architecture) bus, EISA (Enhanced ISA) bus, and VESA (Video Electronics Standards). It includes, but is not limited to, the Association) local bus and the PCI (Peripheral Component Interconnect) bus, also known as the mezzanine bus.

Computer 110 typically includes a variety of computer-readable media. Computer-readable media can be any media available that can be accessed by the computer 110, including both volatile and non-volatile media, as well as removable and fixed media. For example, computer-readable media can include, but are not limited to, computer storage media and communication media. Computer storage media are volatile and non-volatile media implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules, and other data, as well as removable and fixed media. Including media. Computer storage media can be RAM, ROM, EEPROM, flash memory, or other memory technology, CD-ROM, DVD (digital versatile). disk), or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage, or other magnetic storage devices, or any other media that can be used to store desired information and is accessible by computer 110. , But not limited to these. Communication media typically embody computer-readable instructions, data structures, program modules, or other data within a modulated data signal such as a carrier wave or other transmission mechanism, and include any information transmission medium. The term "modulated data signal" means a signal that has one or more of its characteristics set or modified in such a way that information is encoded within the signal. For example, communication media includes, but is not limited to, wired media such as wired networks and direct wired connections, and wireless media such as sound wave media, radio frequency media, infrared media, and other wireless media. Moreover, any combination of the above is included in the range of a computer-readable medium.

System memory 130 includes computer storage media in the form of volatile and / or non-volatile memory such as ROM (read only memory) 131 and RAM (random access memory) 132. The BIOS (basic input / output system) 133 includes a basic routine that assists in transmitting information between elements in the computer 110 during booting and is usually stored in the ROM 131. RAM 132 typically includes data modules and / or program modules that are readily accessible to processing device 120 and / or are currently being operated by processing device 120. FIG. 1 shows, but is not limited to, an operating system 134, an application program 135, other program modules 136, and program data 137 as examples.

Computer 110 can also include other removable / fixed, volatile / non-volatile computer storage media. FIG. 1 shows the magnetic reading and writing between the hard disk drive 141, which reads and writes to and from a fixed non-volatile magnetic medium, and the removable non-volatile magnetic disk 152, for illustration purposes only. An optical disk drive 155 that reads or writes between a disk drive 151 and a removable non-volatile optical disk 156 such as a CD-ROM or other optical media is shown. Other removable / fixed, volatile / non-volatile computer storage media that can be used in typical operating environments include magnetic tape cassettes, flash memory cards, digital versatile disks, digital videotapes, solid-state RAM, and solid-state. There are ROMs, etc., but they are not limited to these. The hard disk drive 141 is typically connected to the system bus 121 via a fixed memory interface such as interface 140, and the magnetic disk drive 151 and optical disk drive 155 are typically connected to the system bus 121 via a removable memory interface such as interface 150. It is connected to the.

The above-mentioned drives and their associated computer storage media, shown in FIG. 1, provide computer-readable instructions, data structures, program modules, and other data storage for the computer 110. For example, in FIG. 1, hard disk drive 141 is shown as storing operating system 144, application program 145, other program modules 146, and program data 147. Note that these components may be the same as or different from the operating system 134, the application program 135, the other program modules 136, and the program data 137. Here, different numbers are assigned to indicate that the operating system 144, the application program 145, the other program modules 146, and the program data 147 are at least different copies. The user can enter commands and information into the computer 110 via an input device such as a keyboard 162 or a pointing device 161 usually called a mouse, trackball, or touchpad. Other input devices (not shown) can include microphones, joysticks, gamepads, satellite receiving antennas, scanners, and the like. These and other input devices are often connected to the processor 120 via a user input interface 160 coupled to the system bus, but are a parallel port, game port, or USB (universal serial). It can also be connected by other interface structures such as bus) and bus structures. The monitor 191 and other types of display devices are also connected to the system bus 121 via an interface such as the video interface 190. In addition to the monitor, the computer can also include other peripheral output devices such as speakers 197 and printer 196, which can be connected via the peripheral output interface 195.

Computer 110 can function within a networked environment using a logical connection to one or more remote computers, such as remote computer 180. The remote computer 180 can be a personal computer, server, router, network PC, peer device, or other common network node, and although only memory storage device 181 is shown in Figure 1, it is usually a computer. Includes many or all of the above elements related to 110. The logical connections shown in Figure 1 include LAN (local area network) 171 and WAN (wide area network) 173, but can also include other networks. Such networking environments are common in offices, enterprise-scale computer networks, intranets, and the Internet.

When used in a LAN networking environment, the computer 110 is connected to the LAN 171 via a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 and other means for establishing communication over the WAN 173, such as the Internet. Modem 172 can be internal or external and can be connected to system bus 121 via user input interface 160 or other suitable mechanism. In a networked environment, the program modules shown associated with computer 110, or parts thereof, can be stored in remote memory storage devices. FIG. 1 shows, as an example, the remote application program 185 resident on the memory device 181 but is not limited to this form. It will be appreciated that the network connections shown are exemplary and other means of establishing communication links between computers can also be used.

(Software provisioning system) FIG. 3 shows a dynamic software provisioning system 200 for providing the use of an operating system on a computing device 202, where the computing device 202 is a desktop computer 12, a laptop computer 22, It can be any of the commonly known computing devices, such as PDA24, mobile phones, or any similar device. The software provisioning system 200 is shown as being implemented to provide the use of an operating system, but in some alternative implementations, the use of other resources such as software, firmware, or a feature of a computing device. Can also be used to provide. Similarly, the software provisioning system 200 is shown to provide the use of resources on a computing device 202 that is communicably connected to network 10, but cannot connect to or to network 10. It can also be used to implement such use on computing devices that can only be connected temporarily.

The software provisioning system 200 can include a provisioning service module 204 having a core provisioning service module 206, a distribution service module 208, a certificate service module 210, a core database 212, and a distribution database 214. The provisioning system 204 can communicate with the billing system 216 via the billing adapter 218, while the core provisioning service module 206 can communicate with the distribution database 214 via the database writer 220. , The distribution database 214 communicates with the distribution service 208 via the database reader 222. The computing device 202 can include a local provisioning module (LPM) 224, which communicates with the delivery service module 208 via the delivery web service module 226 and the billing system 216 via the billing web service module 228. Communicate with.

The provisioning service module 204 can be placed on a server system such as server 30 or on other systems communicatively connected to network 10. Similarly, the billing system 216 can also be placed on a server system such as server 30 or on any other system communicatively connected to network 10. In addition, one or more of the various components of the provisioning service module 204 can be located on the same server or on a number of different servers located at different locations. For example, the core database 212 can be located on a plurality of different database servers, each located in a different location and communicatively connected to network 10. The features of the provisioning service module 204 and its various component modules are described in more detail below.

Further in FIG. 3, the computing device 202 is shown as communicating with the delivery service module 208 via the web service module 226 and with the billing system 216 via the web service module 228. In some situations, Web Services Module 226 can recognize an increase in activity beyond the desired level. The user of the load management service 230, the computing device 202 in the alternative embodiment can communicate with the distribution service module 208 and the billing system 216 via communication in an alternative mode such as a telephone. For example, in situations where it is not possible for the computing device 202 to connect to network 10, users of the computing device 202 will be able to use the telephone and voice-recognition-enabled user interface attached to the delivery service module 208. Alternatively, it can communicate via a customer service representative or the like who can communicate with the distribution service module 208.

If the computing device 202 is a computer such as the computer 110, the LPM 224 may be part of system memory 130, part of various hardware components of computer 110 including processing device 120, or any of these. As a combination of, it can be placed on a fixed non-volatile memory 140. The functions of the LPM224 will be described in more detail below.

(Flowchart of provisioning system) Then, referring to FIG. 4, the provisioning program 250 shows the general functions of the software provisioning system 200. Block 251 can provide the user with a registration key for using the operating system on the computing device 202. As a result of the user's purchase of additional time to use the operating system, etc., the registration key can be provided to the user with the new purchase of the computing device 202. Multiple different entities can provide the registration key to the user, for example, a computer store that sells the computing device 202 can provide the key to the user and the operating system for the computing device 202. An Internet service provider that sells a set of services, including the use of an operating system, can provide a registration key to a user, and so on.

The registration key can be created by the provisioning service module 204 using the certificate service 210 and sent to the registration key provider in a secure manner, as described in more detail below. Alternatively, the registration key provider can create the registration key in a manner agreed with the provisioning service module 204. The registration key may or may not contain information specific to the hardware and other components that use the registration key to identify the computing device 202. In one implementation of the software provisioning system 200, each registration key uniquely identifies the computing device 202 by the HWID (hardware identification) of the computing device 202. In yet another implementation, the registration key is a production identification, such as an operating system product key. It can be number) and can be created by an entity other than the provisioning service, such as an operating system developer or a manufacturer of computing devices that use that operating system. This registration key, also called an InitKey (Initialization key), can be in the form of a series of alphanumeric characters, RFID (radio frequency identification) tags, or any other agreed format.

After providing the registration key to the user, in block 252, the provisioning program 250 can determine whether it is necessary to register the registration key with the provisioning service module 204. If the InitKey was originally created by the provisioning service module 204, it may already be stored in the provisioning service module 204's database, so it is necessary to register the InitKey. It may not be. Alternatively, if the software provisioning system 200 is set up in such a way that a third-party vendor can create an InitKey based on the agreed procedure, such vendor will create the InitKey when it is created. Or it may need to be registered, at least when provided to the user.

If it is determined that it is necessary to register the InitKey, the vendor can register the InitKey with the provisioning service module 204 at block 254. The registration of InitKey will be described in more detail in FIG. 9 below.

After registering the InitKey, in block 256, the provisioning program 250 creates a provisioning packet (also called a "packet") for the computing device 202. The computing device 202 can use provisioning packets to allow users to use the operating system for a specified amount of time, for a specified period of time, or in any other agreed manner. In some alternative implementations, provisioning packets can be used to make any other resource, such as software or an application, available to the user for a specified period of time. The provisioning packet created by the provisioning service module 204 can include information about the user of the packet, usage allowed by the packet, and so on. For example, if the vendor sells the compute device 202 with a one-month prepaid usage right of the operating system on that compute device 202, at block 256, the provisioning service module 204 computes. You can create a provisioning packet for a computing device 202 that allows the device 202 to use its operating system for only one month. However, the provisioning packet can be created in such a way that only the computing device 202 can use that particular provisioning packet. The creation of the provisioning packet will be described in more detail in FIG. 10 below.

When the user attempts to activate the operating system on the computing device 202 by powering on the computing device 202 or in any other way, the LPM224 controls the activation of the operating system. can do. This is indicated by block 258 in program 250. If LPM224 detects that this is the first time the user has attempted to use this operating system, LPM224 may require the user to enter an Init Key. In one alternative implementation, the LPM224 can scan the computing device 202 to determine if the computing device 202 has already populated the InitKey, and if so, the LPM224 will Automatically retrieve InitKey from compute device 202. After receiving the InitKey from the user, the LPM224 can connect with the provisioning service module 204 to request a certificate for the computing device 202, in which case there are numerous requests for a certificate. The information includes the InitKey and HWID of the computing device 202. The design and operation of the LPM224 will be described in more detail below in FIG.

In response to a request for a certificate, in block 260, the provisioning service module 204 can receive a certificate from the certificate service module 210 and deliver that certificate through the delivery service module 208 to the computing device 202. Send to. The process of creating a certificate from the certificate service module 210 and sending the certificate to the client device will be described in more detail below in FIG.

Upon receiving the certificate from the provisioning service module 204, at block 262, the LPM 224 can determine if additional provisioning packets need to be obtained in order to use the operating system on the computing device 202. The LPM224 receives provisioning packets from the provisioning service module 204 based on business rules such as the time the compute device 202 has been used, the current time period, or any similar business rule. Can be consumed. As further described below, the LPM 224 can have a local provisioning packet storage module containing provisioning packets previously received from the provisioning service module 204. LPM224 is such a local packet store (local packet) You can select one provisioning packet from store) and analyze its contents to determine if the provisioning service module 204 needs to request more packets. The selection of provisioning packets and the analysis of the selected provisioning packets will be described in more detail in FIG. 7 below.

If it is determined that it is necessary to request additional provisioning packets, at block 264, the LPM 224 can send a request to the provisioning service module 204 to receive additional provisioning packets. The LPM224 either by connecting to the web service module 226 of the delivery service module 208, by requesting the user of the computing device 202 to contact the customer service representative of the provisioning service module 204, or any other desired. Such requests can be sent to the PSM in a number of different ways, including. Requests for provisioning packets can include information that identifies a client device, the operating system used by that client device, and so on.

Upon receiving the request for the provisioning packet from the computing device 202, in block 266, the provisioning service module 204 can create the provisioning packet and deliver it to the LPM 224. Each provisioning packet provided to the LPM224 is the computing device 202, the operating system used by that computing device 202, the type of packet, the sequence number of the packet, the time that the computing device 202 can use the operating system, or It can contain a variety of information that identifies things like the date the operating system expires. A digital signature that allows the LPM224 to authenticate the information in the provisioning packet can also be included in the provisioning packet. Alternatively, under another security protocol, a separate digital signature can be sent to the LPM224 that allows the LPM224 to authenticate the information in the provisioning packet. The creation and delivery of provisioning packets will be described in more detail in FIG. 12 below.

Upon receiving the provisioning packet, the LPM224 can process the provisioning packet in block 268, which will be described in more detail in FIG. 7 below. If, after analyzing the contents of the provisioning packet, LPM224 determines that the provisioning packet can enable the use of the operating system on the computing device 202, at block 270, the computing device 202 The operating system can be booted on the computing device 202.

(Core provisioning system) Figure 5 shows a detailed block diagram of the core provisioning service module 206 in Figure 3. The core provisioning service module 206 can be implemented on server 30, mainframe 34, or any other suitable device communicatively connected to network 10. The core provisioning service module 206 can communicate with the certificate service module 210, the billing adapter 218, the core DB212, and the delivery service module 208. The core provisioning service 206 includes a billing interface 280 for communicating with the billing adapter, a certificate service interface 282 for communicating with the certificate service module 210, a delivery service interface 288 for communicating with the delivery service module 208, and an account update. Module 284 can include a packet generator 286 and a data access module 290 that communicates with the core database 212 and the distribution database 214.

The billing interface 280 can be implemented using a web interface, a VPN to the billing adapter 218, or any other desired method well known to those of skill in the art. In certain implementations, the billing interface 280 can be implemented using the MSMQ (Microsoft message queue) interface. Alternatively, use an interface designed using another industry protocol, such as Microsoft Biztalk , which is designed using the EAI (enterprise application interface) protocol. It can also be implemented. MSMQ technology can also be used to implement delivery service interface 288 and data access module 290.

The billing interface module 280 receives a request from the billing adapter 218 to register an InitKey for the computing device, communicates with the account renewal, provides account renewal information, bootstraps various computing devices, and computes. You can request a client certificate for the interface from the certificate service module 210, and so on.

Account update module 284 can be responsible for creating, retaining, and updating accounts for computing device 202. The account update module 284 can receive information from the billing adapter 218 regarding account setup and renewal for the compute device 202, and also communicates with the packet generator 286 to provide provisioning packets for the compute device 202. Can be created and saved. For example, underwriters, telecommunications carriers, etc. sell a certain amount of time the operating system is used on the computing device 202 and use the billing adapter 218 to renew the account on the computing device 202 accordingly. An account renewal request can be sent to the core provisioning service 206. Upon receiving the account renewal request from the billing adapter 218, the account renewal module 284 uses the data access module 290 to make the necessary inputs to the core database 212 and communicate with the packet generator to create the required provisioning packets. can do. In another case, the delivery service module 208 can receive a request from the computing device 202 to purchase a provisioning packet for the computing device 202.

Meanwhile, when the computing device 202 sends a request for a certificate or a request for a provisioning packet to the core provisioning service 206, the account update module 284 looks up the provisioning packet from the core database 212 for the computing device 202. Account information can be updated to communicate with the delivery service module 208 and send its provisioning packets to the computing device 202.

When the core provisioning service 206 receives a request for a certificate or a request for a provisioning packet from the computing device 202, it uses the certificate service interface 282 to communicate with the certificate service module 210 to receive the certificate. Or you can check the certificate. The Certificate Services Module 210 can be implemented using any of the standard certificate techniques that allow the creation and management of encrypted certificates. For example, the certificate service module 210 can be implemented using a certificate authority that complies with PKI (public key infrastructure). The certificate service module 210 can include a key manager 292, which can create encrypted asymmetric twin keys and identify key subscribers. And is in charge of authentication. The certificate service module 210 is a certificate generator (certificate). Generator) can also be included, and this certificate generator uses digital certificates to issue, retain, manage, revoke, suspend, revive, and renew such certificates, as well as public key repositories. Bind the public key to the client account for the creation and management of (public key repository). Creating and managing certificates for clients is described in more detail in Figure 11 below.

The certificate service interface 282 signs the provisioning packet by using the certificate created by the certificate service module 210 before the provisioning packet created by the packet generator 286 is sent to the computing device 202. can do. The certificate service interface 282 can also communicate with the certificate service module 210 to verify client signatures such as packet requests.

The core provisioning service 206 can be responsible for issuing provisioning packets and other client device bootstrapping information, such as client device certificates, into the delivery database 214. The distribution service module 208 can be allowed to read information from the distribution database 214, but in order to maintain the integrity of the account information, the distribution service module 208 generally publishes into the distribution database 214. Please note that this is not allowed.

The various modules within Core Provisioning Service 206 are shown as separate modules that perform the various tasks described above, but this depiction is for illustration purposes only and is actually these separate modules. All of these modules can be implemented in different ways, allowing one or more of these modules to be combined or all of these modules to interact with each other in different ways. Please understand that it becomes something like that.

(Core Database Schema) Figure 6 shows the core database schema 310 that can be used to implement core database 212. The core database schema 310 includes bootstrap table 312, compute device table 314, job table 316, packet table 318, configuration table 320, compute device log table 322, type table 324, job log table 326, and status table 328. Can include. The core database schema 310 can be implemented using any of the well-known relational database software, and the various tables in the core database schema 310 can be on a single database server or on network 10. It can be stored on separate database servers that are interconnected via a network such as.

Bootstrap table 312 can store bootstrap data for computing devices such as computing device 202 which can be provided using software provisioning system 200, such data from the underwriter. Received via billing adapter 218. Each record in Bootstrap table 312 identifies the record ID field, the ID for the computing device, the InitKey provided to the user of the computing device, and the number of times the packet was delivered to the computing device. It can contain information including the number of times and the bootstrap status of the computing device.

The computing device table 314 can store data related to a computing device, such as the computing device 202, which can be provided using the software provisioning system 200. The computing device table 314 can store various data related to the computing device added to the registration packet and the provisioning packet sent to the computing device. The computing device table 314 can be used to identify a computing device and track the status of that computing device. Each record in Compute Device Table 314 has a record ID field, a hardware ID that specifies the hardware configuration of the compute device, and the most recent sequence number that represents the sequence number of the last provisioning packet sent to the compute device. It can contain information including such as.

Job table 316 stores data that can be created based on various provisioning requests to the provisioning service module 204, and each provisioning request creates a new record in job table 316. The records in job table 316 can be used to track the provisioning job status of various provisioning requests. Each record in job table 316 has a record ID field, a compute device ID, a job type ID, a job tracking ID, a token for a provisioning request, an account ID for the computing device making the provisioning request, and provisioning. Contains information including the date and time of the request, the status of processing the provisioning request, and so on.

Packet table 318 stores packet data that can be created based on job data, in which case one job can create one or more packets. The packet table is used to track the delivery status of various provisioning packets created in response to provisioning requests received from delivery service module 208 or from billing adapter 218. Each record in the packet table contains a record ID, a job ID that represents the job that causes the packet to be created, various data contained within the packet, and the last packet download acknowledgment from a particular computing device. It can include information about the number of deliveries that indicate how many times a packet has been delivered to that particular computing device since it was received, and the status that indicates the stage of processing the packet.

The configuration table 320 can store data that represents all of the name-value pairs of server configuration data that describe the server used to implement the core database 212. Each record in configuration table 320 can contain information about the server namespace and the names and settings of server name-value pairs.

The computing device log table 322 can record various activities related to a computing device (other than jobs related to that computing device). Each record in the compute device log table 322 has a record ID, a compute device ID, a compute device type, data describing the compute device, and the compute device logged in using the provisioning service module 204. Can include information about time. For example, the types of compute devices are: type for which a bootstrap record has been created, type for which bootstrap is in progress, type for which bootstrap has been completed, and (more than the specified number of certificates have been delivered to the compute device. The bootstrap can be one of more than the limit type, certificate requested type, packet requested type, etc. (indicating that no acknowledgment has been received from the computing device). ..

Type table 324 can be used to predefine the various enumerable types used by job table 316, compute device log table 322, and job log table 326.

The job log table 326 can be used to record various activities related to jobs and packets, in which case each record has a record ID, job ID, job type, job description, It can contain information including the time the job was recorded, and so on.

Status table 328 can be used to predefine the various enumerable statuses used within bootstrap table 312, compute device table 314, job table 316, and packet table 318.

(Delivery Database Schema) Figure 7 shows the delivery database schema 340 that can be used to implement delivery database 214. The delivery database schema 340 can include a delivery bootstrap table 342 and a delivery packet table 344. The delivery database schema 340 can be implemented using any of the well-known relational database software, and the various tables in the delivery database schema 340 can be on a single database server or on the network 10. It can be stored on separate database servers that are interconnected via a network such as.

The delivery bootstrap table 342 can store bootstrap data issued by the core provisioning service 206 during the registration of the computing device. Each record in the delivery bootstrap table 342 can contain information including a record ID, an InitKey associated with a particular computing device, and a hardware ID for that particular computing device. The records in 342 can be deleted by the core provisioning service 206 when the bootstrap for that particular computing device is complete.

The delivery packet table 344 can store the packets created by the core provisioning service 206. Each record in the delivery packet table 344 can correspond to a particular packet, the record ID, the hardware ID that describes the computing device that will use that particular packet, and the particular packet. The packet sequence number, the contents of that particular packet, the number of deliveries that specify how many times that particular packet was sent to the client device without an acknowledgment, and the delivery service module 208 delivering that particular packet. Contains information including a maximum number of deliveries that specifies the number of attempts to deliver to the client device. Once a particular packet has been successfully downloaded by the client computing device, the records associated with that particular packet can be deleted from the delivery packet table 344. Further, when the number of times of delivery of a specific packet exceeds the maximum number of times of delivery, the record related to the specific packet can be deleted from the delivery packet table 344.

(Local Provisioning Module) Figure 8 shows a more detailed block diagram of the LPM224. The LPM224 is a client-side component of the software provisioning system 200 that resides on a computing device, such as the computing device 202. The LPM224 performs a variety of functions, including interacting with users of computing devices using the services provided by the software provisioning system 200, interacting with delivery service modules 208 over network 10, and so on. Can be done.

The LPM224 can perform the function of enforcing a particular state on the client computing device 202 by interacting with the particular login program used by the client computing device 202. The client device uses WPA (Windows® product) as the login logic. In certain implementations using an activation) system, the LPM224 can interact with the WPA to enforce a particular state on the client computing device 202. However, in some alternative implementations, the LPM224 can interact with any other suitable operating system login program. The implementation of LPM224 is shown in FIG. 8 as a grouping of various logical components implemented in software and configured as a library linked to a login program used by WPA. However, in the alternative implementation of LPM224, one or more of the various logical components of LPM224 can be implemented in hardware.

Specifically, the LPM224 has an enforcement add-on module 352 to force the computing device 202 to function in a particular state and the resource usage provided by the software provisioning system 200. To provide a measuring module 354 for measuring, a transaction engine 356 for processing using the provisioned packets provided by the core provisioning service 206, and secure storage for the provisioned packets. It can include a secure storage manager 358, a communication module 360 for communicating with the core provisioning service 206, and a user experience module 362 for interacting with users.

The forced add-on module 352 can be inserted into the login logic 364 of the computing device 202. When a user logs on to compute device 202 using login logic 364, the forced add-on module 352 in login logic 364 can query measurement module 354 for remaining provisioned packet information. .. The forced add-on module 352 can allow the login logic 364 to function within its normal routine if it determines that the compute device 202 has sufficient provisioning packets, and the user computes. You can enable you to log on to the provisioning device 202. However, the coercion add-on module 352 forces the computing device 202 to enter an inactive state if it determines that the computing device 202 does not have enough provisioning packets. In such an inactive state, the user of the computing device 202 is provided with just the limited user interface needed to boot the computing device 202.

The measurement module 354 can include a balance manager 366, which reads and confirms the current remaining amount available to use the provided resources and is currently Update the remaining amount and process provisioning packets. The measurement module 354 can also include a configuration manager 368 and a reliable clock manager 370 to maintain a constantly increasing timer. The Reliable Clock Manager 370 can use the Reliable hardware clock 372 to accomplish the task of maintaining a constantly increasing timer. The Remaining Manager 366 and Reliable Clock Manager 370 are very sensitive and important to the secure operation of the LPM224 and are therefore likely to be exposed to various security attacks during the operation of the LPM224.

The forced add-on module 352 and the measurement module 354 can work together to activate and deactivate the resources provided on the computing device 202. Forced add-on module 352 can act as an event dispatcher within login logic 364 that calls Remaining Manager 366 based on a particular event, while Remaining Manager 366 was called in response to an event. You can decide which action to take. Examples of various events that can activate Remaining Manager 366 on Forced Add-on Module 352 are (1) logon event, (2) system unlock event, (3) recovery from high banation event, and (4) standby. Invoking from an event, (5) user-triggered event, (6) logoff event, (7) packet download, (8) timer tick tick), (10) system lock event, (11) screen saver start event, (12) screen saver stop event, etc. The remaining amount manager 366 can take the event as input and return the resulting action to the forced add-on module 352.

For example, the forced add-on module 352 can send a user logon event to the fuel indicator 366 when the user is logged on. In response to that user logon event, the remaining amount manager 366 can query the current remaining amount available to use the provided resources, and if the remaining amount is sufficient, the remaining amount manager. The 366 can return logon actions to the forced add-on module 352. However, if the remaining amount is not enough, the forced add-on module 352 can cause the login logic 364 to return the notification user interface (UI) 398, in which case the notification UI allows the user to provision the provisioning service. You can increase the remaining amount by purchasing additional provisioning packets from module 204 and therefore activate computing device 202.

The transaction engine 356 can process provisioning packets to update the remaining amount and packet consumption counters in the remaining amount manager 366. The transaction engine 356 can ensure that any provisioning packet is consumed only once in order to update the remaining amount. The transaction engine 356 updates the remaining amount and packet consumption counters together, and therefore either both the remaining amount and the packet consumption counter are updated, or neither the remaining amount nor the packet consumption counter is updated. It can be designed to be. Alternatively, the transaction engine 356 can be used to maintain the consistency of the remaining data so that it is not spoiled by some unexpected event. An example of the functions of the transaction engine 356 will be provided below.

In this example, the user uses two prepaid cards to purchase usage time for the resources provided, the first card is for 10 hours and the second card is for 20 hours. Suppose. Since the provisioning service module 204 does not hold the total remaining amount, two separate sets of license information, one for 10 hours and one for 20 hours, are created in the provisioning service module 204. When the user contacts the provisioning service module 204 to download the provisioning packet onto the computing device 202, each provisioning packet downloaded onto the computing device 202 has a unique provisioning packet number. .. When processing the first packet, the transaction engine 356 advances the packet consumption counter to increase the remaining amount by 10 hours, and then when processing the second packet, advances the packet consumption counter again to increase the remaining amount. Increase for another 20 hours.

Secured storage manager 358 allows the LPM224 to store the remaining amount data in a protected manner so that the remaining amount data cannot be tampered with by the user and only the LPM224 can access the remaining amount data. can do. The provisioning packet can be stored in Secured Storage Manager 358 after being downloaded by LPM224. Similarly, the remaining amount counter and the packet consumption counter can be stored in the Secured Storage Manager 358. In the illustrated implementation, the Secured Storage Manager 358 is implemented as a dll (dynamic link library), which allows the User Experience Module 362 to access the Secured Storage Manager 358.

To ensure the security of the data stored in the Secured Storage Manager 358, you can use the data encryption key to store the data in the Secured Storage Manager 358, only for modules that have the data encryption key. Can read data from Secured Storage Manager 358. Secured Storage Manager 358 is a local security authority (LSA) subsystem for communicating with LSA database 376, 374, secure hardware. It can communicate with the storage driver 378 to communicate with the storage) 380 and the file system driver 382 to communicate with the file 384 on the computing device 202. For additional security, an alternative implementation of Secured Storage Manager 358 can also use multiple copies of the data stored within Secured Storage Manager 358, thereby cross-referencing each copy. No single copy of the data can be tampered with. In the LPM224 implementation discussed here, the Secured Storage Manager 358 is implemented in software, but in some alternative implementations, the Secured Storage Manager 358 can also be implemented in hardware.

Communication module 360 purchases packet / certificate request manager 386 for requesting provisioning packets and / or certificates from provisioning service module 204, and additional provisioning packets from billing system 216 and / or provisioning service module 204. It can include a purchase manager 388 for and a web service communication manager 390 that allows the LPM 224 to communicate with network 10.

The packet / certificate request manager 386 can receive a request from the user experience module 362 and request a packet or certificate from the provisioning service module 204. For example, if the user is logging on to the client device for the first time by entering the InitKey in the UI, the user experience module 362 can pass the InitKey to the Packet / Certificate Request Manager 386, which allows the Packet / Certificate. The request manager 386 can communicate with the provisioning service module 204 to receive a certificate from the provisioning service module 204. The Packet / Certificate Request Manager 386 can also be responsible for acknowledgeing the provisioning service module 204 once the certificate or provisioning packet has been successfully downloaded. The Packet / Certificate Request Manager 386 can use the provisioning protocol to communicate with the provisioning service module 204. Packets downloaded by Packet / Certificate Request Manager 386 can be stored within Secured Storage Manager 358.

The purchase manager 388 receives payment information from a user of computing device 202 and propagates the payment information to the billing system 216 or to the provisioning service module 204 so that the user can purchase additional provisioning packets. can do. Both Packet / Certificate Request Manager 386 and Purchase Manager 388 can use Web Services Communication Manager 390 to communicate with Network 10. The web service communication manager can use the network service manager 392 and the network interface card (NIC) 394 to communicate with network 10. In this implementation, the web service communication manager 390 is used to communicate with network 10, but in the alternative implementation, other such as FTP (file transfer protocol) drivers are used to communicate with network 10. Please note that you can use the communication tools of.

The user experience module 362 has an activation user interface (UI) 396 and LPM224 to require the user to enter an InitKey that allows the Packet / Certificate Request Manager 386 to download certificates from the Provisioning Service Module 204. It can include a notification UI 398 that allows you to interact with the user. For example, if the user has purchased a prepaid card to use the provided resources, the activation UI396 prompts the user to enter the number provided by that prepaid card, and the packet / certificate. You can call Request Manager 386 to download the latest provisioning packet for that prepaid card number. Activation UI396 can also call Purchase Manager 388 to allow users to purchase additional provisioning packets, and automatically call Packet / Certificate Request Manager 386 when the purchase is complete to accommodate the purchase. It can be designed so that provisioning packets can be downloaded.

The notification UI 398 can include various user interfaces that allow the user to inquire about current remaining amount information, usage history, and so on. Notification UI398 can be called by the user or by login logic 364. In situations where the available resources are low to use the provided resources, login logic 364 can call the notification UI398 to inform the user that further purchases are needed. The notification UI can be constantly active, via taskbar icons, control panel applets, balloon pop-ups, or by using any other commonly known UI method. , Notification service can be provided to the user.

Although the various components of the software provisioning system 200 have been described, the subsequent operations of the software provisioning system 200 will be described in more detail in FIGS. 9 to 12.

(Registration of InitKey) FIG. 9 shows a flowchart of the registration program 430 that can be used to register the InitKey with the core provisioning service 206. At block 432, the InitKey provider sends an InitKey registration request to the core provisioning service 206. As mentioned earlier, this provider is a third party, including a vendor for computing device 202, a vendor for usage rights for the operating system for computing device 202, and a customer service representative (CSR) for software provisioning system 200. It can be a billing system 216 that can be managed by.

The InitKey registration request can be received in the message queue of core provisioning service 206. When the core provisioning service 206 recognizes the InitKey registration request in its message queue, it can start the registration process at block 434.

In block 436, the InitKey can be added to the bootstrap table 312 of the core database 212, and registration program 430 can set the bootstrap status to "Created".

Then, at block 438, the core provisioning service 206 can record a "Bootstrap Created" message in the compute device log table 322.

Finally, at block 440, the core provisioning service 206 can send a "Bootstrap Publish" message to the message queue of delivery database 214.

(Packet Creation) Figure 10 shows a flowchart of the packet creation program 450 that can be used to create a provisioning packet used by LPM224 on compute device 202.

At block 452, billing adapter 218 can send a provisioning request message requesting a provisioning packet to core provisioning service 206. Since the core provisioning service 206 can connect to multiple underwriters, such provisioning request messages are queued within the MSMQ interface that connects the billing adapter 218 to the core provisioning service 206.

Upon retrieving the provisioning request message from billing adapter 218, at block 454, core provisioning service 206 can initiate a packet creation transaction.

At block 456, core provisioning service 206 can add a new compute device record to compute device table 314 using the hardware ID from the provisioning request message. However, if a record containing that hardware ID already exists in compute device table 314, it may not be necessary to add a new compute device record.

Then, at block 458, the core provisioning service 206 can add new job records to job table 316 to record new job requests for provisioning packets. The core provisioning service 206 can set the status of the newly added job record to "Created". At block 460, core provisioning service 206 can add new records in job log table 326 along with the date and time of the provisioning request message.

At block 462, core provisioning service 206 can create provisioning packets based on provisioning request messages. Packet creation can include checking the certificate provided in the provisioning request message, adding the amount of time the provisioning packet is used, and so on.

At block 464, the core provisioning service 206 can communicate with the key manager 292 to sign the provisioning packet with a secure key and create an XML-based provisioning packet.

Once the provisioning packet is created, at block 466, the core provisioning service 206 can increment the last sequence number in compute device table 314 by one.

At block 468, the core provisioning service 206 can insert the newly created provisioning packet into packet table 318 and set the status of the provisioning packet in packet table 318 to "packet created".

Then, in block 370, the core provisioning service 206 can record a "packet created" message in the job log table 326. And finally, in block 372, the core provisioning service 206 can send a "packet publish" message into the message queue to the delivery database writer 220 and add the packet into the delivery database 214.

(Bootstrapping) Figure 11 shows a flowchart of the bootstrapping program 500 that can be used to request a certificate from the certificate service module 210 and send the certificate to the computing device 202.

At block 502, the delivery service module 208 can receive a certificate request from a computing device such as the computing device 202. This certificate request is created by Packet / Certificate Request Manager 386 and can contain information including a hardware ID for the computing device 202, such as the InitKey.

At block 504, core provisioning service 206 can find the InitKey in bootstrap table 312. At block 506, core provisioning service 206 can check compute device table 314 to see if it contains a record for the hardware ID provided in the certificate request. If there are no records in compute device table 314, core provisioning service 206 can add records in compute device table 314.

At block 508, the core provisioning service 206 can record the message "computing device created" in the computing device log table 322. Then, at block 510, the core provisioning service 206 can begin processing the certificate request transaction.

At block 512, the core provisioning service 206 can check bootstrap table 312 to see if the number of deliveries is greater than the maximum number of deliveries specified by configuration table 320, and if so. Can transfer control to block 524.

If the number of deliveries is not greater than the maximum number of deliveries, at block 514, the core provisioning service 206 can check the bootstrap status in the bootstrap table 312. If the bootstrap status does not correspond to "created" or "In Progress", control can be moved to block 524.

However, if the bootstrap status corresponds to either "created" or "In Progress", at block 516, the core provisioning service 206 updates the bootstrap status in the bootstrap table 312 to "In Progress". can do.

Then, in block 518, the core provisioning service 206 can record a "bootstrap in progress" message in the computing device log table 322.

At block 520, core provisioning service 206 can call the certificate utility to create a new client certificate. Upon receiving the new certificate from the certificate utility, at block 522, the core provisioning service 206 can send its client certificate into the message queue of delivery service module 208, transferring control to block 530. Can be done.

At block 524, the core provisioning service 206 can update the bootstrap status in the bootstrap table 312 to "over limit" because the number of deliveries in the bootstrap table exceeds the maximum number of deliveries. This "over limit" status means that the core provisioning service 206 has not received an appropriate acknowledgment from the LPM 224 in response to issuing a certificate for the computing device 202. Therefore, at block 526, the core provisioning service 206 sends a "bootstrap over limit" message in the compute device log table 322 indicating that no acknowledgment has been received from the compute device requesting the certificate. Can be recorded in.

At block 528, core provisioning service 206 can send a "remove bootstrap" message into the message queue of delivery database writer 220 to remove bootstrap records from delivery database 214.

Block 530 can receive control from block 522 when the certificate is sent to the client, thus representing the end of processing of the certificate request.

When the certificate request is processed, at block 532, the core provisioning service 206 can receive the certificate download complete message in the message queue of delivery service module 208. Such a certificate download completion message can be sent by the LPM224 Packet / Certificate Request Manager 386 after the certificate has been successfully downloaded.

Upon receiving the certificate download completion message, at block 534, the core provisioning service 206 can initiate a bootstrap completed transaction. At block 536, core provisioning service 206 can update the bootstrap status in bootstrap table 312 to "completed". Then, in block 538, the core provisioning service 206 sends a "bootstrap completed" message in the compute device log table 322 indicating that the bootstrap process for the compute device sending the certificate request has been completed. Can be recorded in.

Finally, in block 540, the core provisioning service 206 sends a "remove bootstrap" message into the message queue of delivery database writer 220 to remove the bootstrap record from bootstrap table 342 of delivery database 214. Can be done.

(Packet Delivery) Figure 12 shows a flowchart for the packet delivery program 550 that can be used to deliver provisioning packets from the core provisioning service 206 to various computing devices such as computing device 202. The packet delivery program 550 can be initiated by the Packet / Certificate Request Manager 386, by a customer service representative who assists the user of the computing device, or in other similar ways.

At block 552, the core provisioning service 206 is capable of receiving packet download messages in the message queue of delivery service module 208. Such a message can be sent, for example, by Packet / Certificate Request Manager 386 on compute device 202. Upon receiving the packet download message, at block 554, the core provisioning service 206 can initiate a packet request transaction.

At the beginning of the packet request transaction, in block 556, confirmation service 209 acknowledges that the status in packet table 318 is that the computing device sending the packet download message acknowledges the previous packet transmission by core provisioning service 206. It can be determined if it is a "packet over limit" that specifies that it has not done, and control is transferred to block 564.

In block 558, the core provisioning service 206 can update the status in packet table 318 to "delivery in progress" if it is determined that the status in packet table 318 is not "packet over limit". ..

Then, in block 560, the core provisioning service 206 can update the number of deliveries in the packet table 318 to the value specified in the packet download message. For example, if the packet download message requests two packets from the core provisioning service 206, the number of deliveries in packet table 318 is incremented by 2. At block 562, the core provisioning service 206 can record a "packet delivery in progress" message in the job log table 326.

Block 564 can receive control by the absence of acknowledgments from the computing device, so in block 564 the core provisioning service 206 can update the status in packet table 318 to "over limit". ..

In block 566, the core provisioning service 206 can update the number of deliveries in packet table 318 to the value specified in the packet download message, and in block 568 the CPS changes the status of job table 316 to " Update to "error". Finally, at block 570, the core provisioning service 206 can record a "packet over limit" message in the job log table 326.

At block 572, the core provisioning service 206 can terminate processing of the packet request transaction and wait for an acknowledgment from the computing device requesting the packet. At block 574, the core provisioning service 206 can receive a packet download complete message within the message queue of delivery service module 208. This packet download completion message can be sent by Packet / Certificate Request Manager 386 when the requested package has been successfully downloaded.

Upon receiving the packet download completion message, at block 576, the core provisioning service 206 can initiate a packet download completion transaction. As part of the packet download complete transaction, in block 578 the confirmation service can update the status in the packet table 318 to "completed" and in block 580 the status in the job table can also be updated to "completed".

Further, in block 580, the core provisioning service 206 can record a "job completed" message in the job log table 326 and end the packet download completion transaction in block 582.

Having described the operation of the various components of the software provisioning system 200, Figures 13-16 below describe various exemplary scenarios that show the user's experience under different circumstances.

(Scenario 1-Checking the remaining amount during login) Figure 13 shows Flowchart 600 showing the first scenario during the operation of LPM224. Specifically, Flowchart 600 shows a scenario when a user is logged on to a computer. As shown in FIG. 13, in block 602, the forced add-on module 352 can send a logon event to the fuel level manager 366 when the user is attempting to log on to the computing device 202. In response to this logon event, in block 604, the remaining amount manager 366 can check the remaining amount available to use the operating system on the computing device 202. If the remaining amount is sufficient, in block 606, the remaining amount manager 366 can notify the login logic 364 to activate the operating system in the usual way.

However, if the remaining amount manager 366 determines that the remaining amount is not sufficient, the remaining amount manager 366 can activate the activation UI396 in the block 608. The purpose of activating the activation UI is to allow users to purchase additional usage time.

At block 610, activation UI396 can activate purchase manager 388 and the user can make a purchase. The user can make a purchase by connecting to the billing system 216, by calling a customer service representative, or by any other desired method. Then, at block 612, the certificate / packet request manager 386 can download the provisioning packet.

Certificate / Packet Request Manager 386 can serve downloaded provisioning packets to Secure Store Manager 358 for secure storage. At block 614, the remaining amount manager 366 can analyze the downloaded provisioning packets, and at block 616, the provisioning balance available to the computing device 202 can be increased accordingly.

(Scenario 2-Purchase of usage rights after logon) Figure 14 shows Flowchart 620 showing a second scenario during LPM224 operation. Specifically, Flowchart 620 shows a scenario in which the user is already logged on to the compute device 202 and selects the Control Panel applet or taskbar icon to activate the Fuel Manager 366.

At block 622, the user can activate a control panel applet that sends an event to the fuel gauge manager 366. The remaining amount manager 366 can display the current remaining amount information to the user and call the activation UI396, thereby activating the purchase manager 388. The Certificate / Packet Request Manager 386 can download provisioning packets as the user makes additional time purchases.

Certificate / Packet Request Manager 386 can serve downloaded provisioning packets to Secure Store Manager 358 for secure storage. At block 628, the remaining amount manager 366 can analyze the downloaded provisioning packets, and at block 630, the remaining amount of provisioning available to the computing device 202 can be increased accordingly.

(Scenario 3-Update and notification of remaining capacity after logon) Figure 15 shows Flowchart 640 showing a third scenario during LPM224 operation. Specifically, flowchart 640 shows a scenario in which the user is already logged on to the computing device 202 and the login logic 364 receives an event as a result of a time tick from the Reliable Clock Manager 370.

At block 642, the login logic 364 can receive a time tick event from the Reliable Clock Manager 370. As a result, the login logic 364 can send a time tick event to the fuel gauge manager 366.

In response to that time tick event, at block 644, the remaining amount manager 366 can update the remaining amount available to use the operating system on the computing device 202. Then, in block 646, the remaining amount manager 366 checks the available remaining amount. Based on the results of that evaluation, in block 648, the remaining amount manager 366 can take appropriate actions, such as activating activation UI396, logging off the user, and so on. Appropriate actions can be continued.

(Scenario 4-Deactivation of Computing Device) Figure 16 shows Flowchart 660 showing a fourth scenario during the operation of LPM224. Specifically, Flowchart 660 shows a scenario in which the user is already logged on to the computing device 202 and the login logic 364 receives an event as a result of a time tick from the Reliable Clock Manager 370.

At block 662, the login logic 364 can receive a time tick event from the Reliable Clock Manager 370. As a result, the login logic 364 can send a time tick event to the fuel gauge manager 366.

In response to that time tick event, at block 664, the remaining amount manager 366 can update the remaining amount available to use the operating system on the computing device 202. Then, in block 666, the remaining amount manager 366 can check the remaining amount available. Based on the results of that evaluation, in block 668, the remaining amount manager 366 can take appropriate actions, such as activating activation UI396, logging off the user, and so on. Appropriate actions can be continued.

In this case, for example, the remaining amount manager 366 detects that the remaining amount available for the computing device 202 is at or below the threshold, such as zero. As a result, in block 668, the remaining amount manager 366 can display a logoff message in the notification UI398, eventually logging off the user from using the operating system on the computing device 202. In other cases, Notification UI398 can also activate Purchase Manager 388 to allow users to purchase additional usage time.

(Scenario 5-Enter prepayment after logon) Figure 17 shows Flowchart 680 showing a fifth scenario during LPM224 operation. Specifically, flowchart 680 shows when the user is already logged on to compute device 202 and selects the control panel applet or taskbar icon to activate the activation wizard to enter information from the prepaid card. The scenario is shown. This may be the case if the user has previously purchased a prepaid card and decides to add the usage time available with that prepaid card to their account.

At block 682, the user can activate a control panel applet that sends an event to the activation UI396 to display the activation wizard. An example of a GUI window that can be displayed to the user will be described with reference to the additional time window 684 in FIG. The user can enter the information from the prepaid card by selecting the additional time button from the additional time window 684.

Then, in block 686, the activation UI396 can inform the user of various information that may be needed to enable the user to use the activation wizard, which is shown in Figure 19. Shown by GUI688.

At block 690, the activation UI396 can present a network connection GUI692 as shown in FIG. 20, which allows the web service communication manager 390 to access the core provisioning service 206 on the Internet. Notify the user that they are connected to.

Then, in block 694, the activation UI396 can prompt the user to enter the key received from the pre-paid usage card. Keys on prepaid cards can contain strings of alphanumeric characters and other characters. In this case, the key is an alphanumeric key that is 25 characters long, as shown as being entered into GUI696 in Figure 21.

Upon receiving the key from the prepaid card, in block 698, the activation UI396 can prompt the user to log in to the .NET® system, as indicated by the GUI700 in Figure 22. Note that it may not always be necessary for the user to log in to the .NET® system.

Then, in block 702, the activation UI396 may receive confirmation from the core provisioning service 206 that the user's key from the prepaid card has been accepted and that the user's account should grow by the corresponding time. it can. The message notifying that the time has been added successfully is indicated by GUI704 in Figure 23.

Finally, in block 706, the activation UI396 is credited to the compute device 202 in minutes just after the user has just added time by using a prepaid card, as shown by GUI708 in Figure 24. It is possible to notify the user to that effect.

Although the text described above provides a detailed description of many different embodiments of the invention, it is noted that the scope of the invention is defined by the wording of the claims attached to this patent. I want to be understood. This detailed description should be construed as merely exemplary and does not describe all possible embodiments of the invention. This is because it seems impractical, if not impossible, to explain all possible embodiments. Many alternative embodiments can be implemented using current technology or technology developed after the filing date of the patent, which will continue to fall within the claims that define the invention.

Therefore, many modifications and variations can be made in the techniques and structures described and illustrated herein without departing from the spirit and scope of the invention. Therefore, it should be understood that the methods and devices described herein are exemplary only and do not limit the scope of the invention.

<figref num="1">It is a block diagram which shows the network which interconnects a plurality of computing resources.</figref><figref num="2">It is a block diagram which shows the computer which can connect to the network of FIG.</figref><figref num="3">It is a block diagram which shows the software provisioning system for providing the operating system on the computer of the network of FIG.</figref><figref num="4">It is a flowchart which shows the registration of the computer on the software provisioning system of FIG.</figref><figref num="5">It is a block diagram which shows the core provisioning system of the software provisioning system of FIG.</figref><figref num="6">It is a block diagram which shows the core database used by the core provisioning system of FIG.</figref><figref num="7">It is a block diagram which shows the distribution database used by the core software provisioning system of FIG.</figref><figref num="8">It is a block diagram which shows the local provisioning module (local provisioning module) of the software provisioning system of FIG.</figref><figref num="9">It is a flowchart which shows the key registration program used by the software provisioning system of FIG.</figref><figref num="10">It is a flowchart which shows the packet making program used by the software provisioning system of FIG.</figref><figref num="11">It is a flowchart which shows the bootstrapping program used by the software provisioning system of FIG.</figref><figref num="12">It is a flowchart which shows the packet delivery program used by the software provisioning system of FIG.</figref><figref num="13">It is a flowchart which shows the operating scenario (operating scenario) for a local provisioning module of FIG.</figref><figref num="14">Another flowchart showing an operating scenario for the local provisioning module in Figure 8.</figref><figref num="15">Another flowchart showing an operating scenario for the local provisioning module in Figure 8.</figref><figref num="16">Another flowchart showing an operating scenario for the local provisioning module in Figure 8.</figref><figref num="17">Yet another flowchart showing an operating scenario for the local provisioning module in Figure 8.</figref><figref num="18">FIG. 5 illustrates an exemplary GUI presented to the user during the operating scenario of FIG.</figref><figref num="19">FIG. 5 illustrates another exemplary GUI presented to the user during the operating scenario of FIG.</figref><figref num="20">FIG. 5 illustrates another exemplary GUI presented to the user during the operating scenario of FIG.</figref><figref num="21">FIG. 5 illustrates another exemplary GUI presented to the user during the operating scenario of FIG.</figref><figref num="22">FIG. 5 illustrates another exemplary GUI presented to the user during the operating scenario of FIG.</figref><figref num="23">FIG. 5 illustrates another exemplary GUI presented to the user during the operating scenario of FIG.</figref><figref num="24">FIG. 5 illustrates another exemplary GUI presented to the user during the operating scenario of FIG.</figref>