Access-control method for software module and programmable electronic device therefor

RELATED INVENTION

This patent application is a divisional patent application of “Access-Control Method For Software Modules And Programmable Electronic Device Therefor,” U.S. patent application Ser. No. 10/177,555, filed 21 Jun. 2002, now U.S. Pat. No. 7,290,144.

GOVERNMENT RIGHTS

This invention was made with Government support under MDA904-99-C-6512 awarded by NSA. The Government has certain rights in this invention.

TECHNICAL FIELD OF THE INVENTION

The present invention relates generally to the field of programmable electronic devices. More specifically, the present invention relates to controlling access to a plurality of software modules loaded in said electronic devices.

BACKGROUND OF THE INVENTION

A programmable electronic device that processes data may be put to a variety of different uses by a variety of different users who have a variety of different concerns about the data processed by the device. Such a programmable electronic device may be a computerized device on which a variety of different software programs can be executed to do a variety of data processing tasks. Data may take the form of, but is not limited to, voice, audio, or video electronic signals or information. Such devices include personal computers, workstations, servers, laptops, palmtops, cellular phones, telephones, audio equipment, video equipment, and a wide variety of other devices in which different computer programs are stored and launched to perform a variety of data processing jobs. Manufacturers need to control the software usable on such devices. Users sometimes need to tightly control who has access to the processed data, or at least some of the data, and other times wish to exert little or no control.

The complicated task of controlling the software involves making sure the right device gets loaded with the right software, supporting that software, and upgrading that software. When different devices get different software packages, this software becomes difficult and expensive to manage due to the vast number of combinations of software programs and versions of software programs that may be loaded throughout a population of similar devices. Mistakes in knowing which device has or should have which software lead to tremendously increased costs through the distribution of unlicensed software, providing support to unlicensed users, misdirected problem-solving efforts, and the like.

Another aspect of controlling the software involves taking steps to minimize unauthorized uses of software. For example, manufacturers wish to insure that software licensed for use on one device cannot be easily used on a different device.

Controlling access to the device becomes more complex as more users are capable of utilizing the device. If no more than a few users use the device and no communication link or network is available to afford greater access, then users often wish to avoid the burdens of imposing user restrictions on the device. Security may be adequately maintained merely by controlling physical access to the device. However, as more users have access or potential access, then the benefits of imposing user restrictions tend to outweigh the burdens.

In one example, a stand-alone workstation may require no password before access is permitted to the workstation's computer software and data. However, a server available to a number of workstations may require passwords to control access to the server's software and data. In a conventional situation, the server will provide an access-control system that gives an administrator certain permissions that other users or user groups do not have. Such permissions may include the ability to define new users and user groups and the ability to indicate which users and user groups have access to which data and software. Unfortunately, no single access-control system adequately serves this range of needs. Either very little security is provided but greater user flexibility is realized, or more security is provided with significantly reduced user flexibility. It would be advantageous if a single access-control system implemented on a device could serve a wide range of needs.

SUMMARY OF THE INVENTION

It is an advantage of the present invention that an improved access-control method for software modules and programmable electronic device therefor are provided.

Another advantage of the present invention is that a flexible access-control system is provided which permits the device with which it is used to be operated over a range of security controls, from a permissive system that does not require tokens to a highly restrictive permission system wherein only certain user tokens are granted access to certain software modules.

Another advantage of the present invention is that an access-control system is provided in which an entire set of software modules may be delivered to a customer, even though that customer is licensed to use only a subset of the entire set of software modules.

Another advantage of the present invention is that an access-control system is provided in which a manufacturer has assurance that software modules and permissions provided for one device are not usable on another device.

Another advantage of the present invention is that an access-control system is provided in which the management of different versions of different software modules and the upgrading thereof are user-friendly for manufacturer and customers alike.

These and other advantages are realized in one form by an improved method of managing a plurality of software modules used in a programmable electronic device which selectively activates at least a portion of the plurality of software modules by controlling access to the software modules. The method encrypts each one of an entire set of original, plain-text software modules using at least one cipher-key to form cipher-text software modules. The entire set of cipher-text software modules is loaded in the device, and the device is delivered to a customer. Later versions of at least some of the original plain-text software modules are generated to form updated plain-text software modules. The updated plain-text software modules are encrypted to generate updated cipher-text software modules. The device is upgraded after delivery of the device to the customer by providing the entire set of software modules to the customer, wherein the entire set includes the updated cipher-text software modules.

These and other advantages are realized in another form by an improved programmable electronic device having an access-control system configured to selectively activate any of a plurality of software modules. The device includes a memory having a plurality of software modules which have been classified into software-restriction classes. An access-control-model-activator is configured to activate one of a plurality of access-control models. An input device is configured to receive a request to access one of the plurality of software modules. An access-control-processor is configured to evaluate the software-restriction class for the one of the plurality of software modules and to evaluate the one of the plurality of access-control models to determine whether to grant access to the one of the plurality of software modules. A module-activator is configured to activate the one of the plurality of software modules when the access-control processor determines to grant access to the one of the plurality of software modules.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present invention may be derived by referring to the detailed description and claims when considered in connection with the Figures, wherein like reference numbers refer to similar items throughout the Figures, and:

<figref idref="DRAWINGS">FIG. 1</figref> shows a block diagram of an example of a programmable device configured in accordance with the teaching of the present invention;

<figref idref="DRAWINGS">FIG. 2</figref> shows a flow chart depicting an exemplary form of operation for an access-control processor segment of a processor included in the device of <figref idref="DRAWINGS">FIG. 1</figref>;

<figref idref="DRAWINGS">FIG. 3</figref> shows a table depicting an exemplary access-control system implemented by the device of <figref idref="DRAWINGS">FIG. 1</figref>;

<figref idref="DRAWINGS">FIG. 4</figref> shows a flow chart depicting an exemplary form of operation for a module-activator segment of the processor included in the device of <figref idref="DRAWINGS">FIG. 1</figref>;

<figref idref="DRAWINGS">FIG. 5</figref> shows a flow chart depicting an exemplary form of operation for an access-control-model-activator segment of the processor included in the device of <figref idref="DRAWINGS">FIG. 1</figref>;

<figref idref="DRAWINGS">FIG. 6</figref> shows a flow chart depicting an exemplary form of operation for a delete user process which may be performed by the access-control-model-activator segment of <figref idref="DRAWINGS">FIG. 5</figref>;

<figref idref="DRAWINGS">FIG. 7</figref> shows a flow chart of a software manufacturing process that may be carried out by a manufacturer in connection with software to be loaded on the device of <figref idref="DRAWINGS">FIG. 1</figref>;

<figref idref="DRAWINGS">FIG. 8</figref> shows a flow chart of a hardware manufacturing process that may be carried out by a manufacturer with respect to the device of <figref idref="DRAWINGS">FIG. 1</figref>;

<figref idref="DRAWINGS">FIG. 9</figref>. shows a flow chart of a delivery process that may be carried out by a manufacturer with respect to the device of <figref idref="DRAWINGS">FIG. 1</figref>;

<figref idref="DRAWINGS">FIG. 10</figref> shows a flow chart of a post-delivery process that may be carried out by a manufacturer with respect to the device of <figref idref="DRAWINGS">FIG. 1</figref>; and

<figref idref="DRAWINGS">FIG. 11</figref> shows a flow chart of an exemplary form of operation for a customer license process which may be performed by the device of <figref idref="DRAWINGS">FIG. 1</figref> in support of the post-delivery process of <figref idref="DRAWINGS">FIG. 10</figref>.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

<figref idref="DRAWINGS">FIG. 1</figref> shows a block diagram of an example of a programmable electronic device <b>10</b> configured in accordance with the teaching of the present invention. Device <b>10</b> is an electronic device intended to process a wide variety of data, both public and private, using a wide variety of software programs. The data processed may take the form of, but is not limited to, voice, audio, or video electronic signals, or any other information or data that is conventionally processed by computers and computer-controlled equipment. Examples of device <b>10</b> may take the form of personal computers, workstations, servers, laptops, palmtops, cellular phones, telephones, radios, audio equipment, video equipment, and a wide variety of other equipment in which different computer programs are stored and launched to perform a variety of data processing jobs.

Device <b>10</b> includes a non-volatile memory <b>12</b> in which cipher-text software modules <b>14</b> are stored. Cipher-text modules <b>14</b> appear to be random data, but may be decrypted to reveal plain-text software modules <b>16</b>, provided the appropriate decryption algorithms and the appropriate decryption keys are used to do the decrypting. Desirably, each cipher-text software module <b>14</b> is isolated from all other modules <b>14</b> through the use of a key associated with that module <b>14</b>. Any number of cipher-text software modules <b>14</b> may be stored in memory <b>12</b>. While <figref idref="DRAWINGS">FIG. 1</figref> depicts only cipher-text software modules <b>14</b> stored in memory <b>12</b>, nothing prevents memory <b>12</b> from additionally storing plain-text modules <b>16</b>. <figref idref="DRAWINGS">FIG. 1</figref> depicts different blocks <b>14</b> using different cross-hatching techniques to indicate that different blocks <b>14</b> may have been encrypted using different encryption algorithms and/or keys, hereinafter called cipher-keys, and therefore require correspondingly different decryption algorithms and/or cipher-keys to achieve a successful decryption. However, nothing requires device <b>10</b> to use different encryption algorithms and/or cipher-keys in forming cipher-text software modules <b>14</b> from plain-text software modules <b>16</b>.

Those skilled in the art will appreciate that the number of encryption/decryption algorithms and or keys, the precise mathematical and logical manipulations performed by such algorithms, and the precise nature of the functions performed by the various plain-text software modules <b>16</b> are not critical features in the present invention. Moreover, plain-text software modules <b>16</b> may be executable computer programs, data processed, manipulated, or simply moved or copied by computer programs, or a combination of both computer programs and data.

Plain-text software modules <b>16</b>, and correspondingly the associated cipher-text software modules <b>14</b>, have been classified in accordance with a hierarchical software-restriction classification system, which is discussed in more detail below. Briefly, an “administration” classification (A) indicates that an externally-supplied administrator token may be required to access the plain-text software modules <b>16</b>. As will be discussed in more detail below, a determination of whether or not the externally-supplied administrator token will be required also depends upon which one of a plurality of different access-control models has been activated.

A token is an item of information that desirably serves to authenticate a user of device <b>10</b>. A token may take the form of a personal identification number (“pin”), a password, data obtained from a data-conveying medium, biometric data scanned directly from users' bodies, or the like. Examples of data-conveying media include a magnetic stripe card, smart card, bar code printed on a card, and the like. Examples of biometric data include fingerprints, irises, facial features, DNA, and the like. A token may include any number of token-keys, wherein each token-key represents a subset of the token data. Thus, a plurality of token-keys may be associated together in a single token. In the above-discussed related invention, a pin expander process is described wherein a simple pin is expanded to a token having a plurality of cryptographically independent token-keys, with the entropy of the pin applying to each of the token-keys.

In the exemplary preferred software-restriction classification system described herein, the administration class is the most restrictive. Typical software modules classified in the administration software-restriction class (A) would perform security-sensitive utility functions related to loading and upgrading modules on device <b>10</b>, adding and deleting users, assigning permissions for different users to access different modules, and the like. A “constrained” (C) class is less restrictive than the administration class, and a “global” (G) class is even less restrictive than the constrained class. Application software (i.e., software most directly involved in performing the functions for which device <b>10</b> is provided) would typically by classified in the constrained software-restriction class (C). For software modules <b>16</b> classified as being in the global software-restriction class (G), no externally-supplied token is required to gain access. Security-insensitive utility functions may desirably be classified in the global software-restriction class (G).

<figref idref="DRAWINGS">FIG. 1</figref> depicts memory <b>12</b> as storing encrypted versions of plain-text software modules <b>1</b>-<b>5</b>, although any number of such modules may be present. Software modules <b>1</b>-<b>5</b> are all licensed. So long as a user presents the token required of the software-restriction class into which a requested software module <b>16</b> has been classified, if any, then the user may be granted access to the requested software module <b>16</b>.

In contrast to licensed modules <b>1</b>-<b>5</b>, <figref idref="DRAWINGS">FIG. 1</figref> also depicts an encrypted form of an unlicensed plain-text software module <b>18</b>. No user of device <b>10</b> can be granted access to unlicensed module <b>18</b> regardless of the software-restriction class into which unlicensed module <b>18</b> has been classified because the keys needed to decrypt unlicensed module <b>18</b> are not present in device <b>10</b> to generate the cipher-key that could decrypt unlicensed module <b>18</b>. Any number of unlicensed modules <b>18</b> may be present in memory <b>12</b>. In one scenario, unlicensed modules <b>18</b> may be applications that are originally installed by the manufacturer of device <b>10</b>, but not paid for or desired by the customer. As discussed below, a licensing process may take place to change unlicensed modules <b>18</b> into licensed modules. Those skilled in the art will appreciate that the terms “licensed” and “unlicensed” are used herein to indicate mutually exclusive status conditions and need not mandate any particular legal, rental, lease, ownership, or other arrangement or contract.

Plain-text software modules <b>16</b>, when successfully decrypted, are loaded in and/or executed by a processor <b>20</b> which couples to non-volatile memory <b>12</b>. Processor <b>20</b> is desirably configured as a single-chip microprocessor that includes at least a central processing unit (CPU) and an internal memory <b>22</b> located in a single integrated circuit device. Internal memory <b>22</b> may be configured as read only memory and/or as read-write memory.

In internal memory <b>22</b>, or in the alternative other memory coupled to processor <b>20</b>, any number of plain-text computer programs may be stored which, when executed in processor <b>20</b>, cause processor <b>20</b> to perform a variety of different processing functions. These computer programs include an access-control-processor <b>24</b>, a module-activator <b>26</b>, and an access-control-model-activator <b>28</b>, to name but a few, which are discussed below in more detail. Desirably, processor <b>20</b> is configured so that no computer program may be loaded in device <b>10</b> or executed in device <b>10</b> unless an associated cryptographic authentication mechanism can be verified, a process well known to those skilled in the art.

An input/output (I/O) interface <b>30</b> couples processor <b>20</b> to a variety of I/O devices, which may include a microphone <b>32</b>, keypad <b>34</b>, a phone jack <b>36</b>, and a card reader <b>38</b>. No one type of I/O device is essential for inclusion in device <b>10</b>, and numerous other well-known input and output devices may also be included. Such other I/O devices may include a speaker, network interface card (NIC), modem, radio frequency (RF) transceiver, display, printer, removable memory interface, keyboard, pointing device, optical scanner, magnetic card reader, bar code scanner, smart card reader, memory-stick reader, scanner of biometric features, or the like.

Processor <b>20</b> also couples to an anti-tamper memory <b>40</b>. Anti-tamper memory <b>40</b> is a volatile memory device or set of devices desirably energized through the use of conductors and connections that are easily broken should the housing (not shown) which contains anti-tamper memory <b>40</b> be tampered with. However, anti-tamper memory <b>40</b> is desirably continuously energized, such as by battery backup if necessary, so that it functions as a non-volatile memory that retains its contents when device <b>10</b> is powered down in a normal manner. In one embodiment, internal memory <b>22</b> serves as anti-tamper memory <b>40</b>. Accordingly, the act of tampering with the aim of discovering data stored in anti-tamper memory <b>40</b> is highly likely to cause power to be removed and the contents of anti-tamper memory <b>40</b> to be destroyed.

Among other things, anti-tamper memory <b>40</b> is configured to store any number of user tables <b>42</b>, with one table <b>42</b> being provided for each user that has been installed on device <b>10</b>. One user table <b>42</b>, hereinafter referred to as internal user table <b>44</b>, differs from the other user tables <b>42</b> because it is not associated with any particular “external” user of device <b>10</b>. Internal user table <b>44</b> is provided for a virtual “internal” user. The internal user represents any user that may wish to use device <b>10</b>, without consideration of the user's identity or authorization to use device <b>10</b>.

Each table <b>42</b> includes a split-key register <b>46</b> associated with any number of user ID registers (not shown). Each split-key register <b>46</b> holds split-keys <b>48</b> that have been created for the subject user. One split-key <b>48</b> is desirably created for each cipher-text software module <b>14</b> in a one-to-one correspondence. As discussed below, split-keys <b>48</b> are desirably created even for unlicensed cipher-text software modules <b>18</b>.

The split-keys <b>48</b> stored in a split-key register <b>46</b> are cryptographically independent of one another. In other words, any correlation between split-keys <b>48</b> is desirably less than or equal to the correlation found in the cipher-text software module <b>14</b> of cipher data encrypted with the strongest encryption algorithm supported by device <b>10</b>. The precise length of any particular one of the various split-keys <b>48</b> is not a critical feature of the present invention, but cryptographic goals are generally better achieved using longer bit-lengths for split-keys <b>48</b>.

<figref idref="DRAWINGS">FIG. 1</figref> illustrates an example data format for split-keys <b>48</b> stored in a split-key register <b>46</b>. This format indicates one split-key <b>48</b> for each cipher-text software module <b>14</b> in non-volatile memory <b>12</b> in a one-to-one correspondence. For purposes of illustration, split-keys <b>48</b> associated with licensed plain-text software modules <b>1</b>-<b>5</b> are genuine split-keys (G-S-K) <b>50</b>, and the split-key <b>48</b> associated with unlicensed module <b>18</b> is depicted as being an artificial split-key (A-S-K) <b>52</b>. A genuine split-key <b>50</b> is a split-key <b>48</b> that, when combined in a predetermined fashion with a token of a user installed on device <b>10</b>, generates the appropriate cipher-key that permits successful decryption of the associated cipher-text software module <b>14</b>. An artificial split-key <b>52</b> is a split-key <b>48</b> that, when combined in the same predetermined fashion with a token of a user installed on device <b>10</b>, fails to generate the cipher-key that permits successful decryption of the associated module <b>14</b>. Any split-key <b>48</b> may be either a genuine split-key <b>50</b> or an artificial split-key <b>52</b>. In order to best achieve cryptographic goals, even artificial split-keys <b>52</b> maintain cryptographic independence from one another and from genuine split-keys <b>50</b>. Thus, artificial split-keys <b>52</b> are desirably generated based, at least in part, on random numbers.

Internal user table <b>44</b> includes an internal token-key register <b>54</b> in which is stored an internally-supplied token <b>55</b> having any number of token-keys <b>57</b>. Internal user table <b>44</b> also includes a split-key register <b>46</b>. Internal token-keys <b>57</b> from token <b>55</b> are associated with split-keys <b>48</b> in split-key registers <b>46</b> in a one-to-one correspondence. Token <b>55</b> is internally-supplied because it is supplied from within device <b>10</b> for use by the virtual internal user. In contrast, externally-supplied tokens, discussed below, are supplied from outside device <b>10</b> through an input device, such as keypad <b>34</b> or reader <b>38</b>. Desirably, externally-supplied tokens have substantially the same format as internal token <b>55</b> and also include any number of token-keys <b>57</b>. Internal user table <b>44</b> also includes a split-key register <b>47</b> which contains artificial split-keys <b>52</b> that are not associated with any token-key <b>57</b> currently usable with device <b>10</b>. But the artificial split-keys <b>52</b> in register <b>47</b> may be used later in activating unlicensed modules <b>18</b>.

<figref idref="DRAWINGS">FIG. 2</figref> shows a flow chart depicting an exemplary form of operation for access-control-processor <b>24</b>. <figref idref="DRAWINGS">FIG. 3</figref> shows a table <b>56</b> depicting an exemplary access-control system implemented by device <b>10</b>. Processor <b>24</b> operates a continuous programming loop in the embodiment depicted in <figref idref="DRAWINGS">FIG. 2</figref>. In this continuous programming loop, processor <b>24</b> reacts to a request received from a user of device <b>10</b>, through keypad <b>34</b> (<figref idref="DRAWINGS">FIG. 1</figref>) or another input device, to activate an identified one of plain-text software modules <b>16</b> (<figref idref="DRAWINGS">FIG. 1</figref>). Referring to <figref idref="DRAWINGS">FIG. 3</figref>, processor <b>24</b> evaluates a software-restriction class <b>58</b> into which the requested software module <b>16</b> has been classified and the active access-control model <b>60</b> to determine whether or not to activate the requested software module <b>16</b>.

Table <b>56</b> indicates that this exemplary preferred access-control system contemplates the global software-restriction class <b>62</b>, labeled with a “G” in <figref idref="DRAWINGS">FIG. 1</figref>, the constrained software-restriction class <b>64</b>, labeled with a “C” in <figref idref="DRAWINGS">FIG. 1</figref>, and the administration software-restriction class <b>66</b>, labeled with an “A” in <figref idref="DRAWINGS">FIG. 1</figref>.

Table <b>56</b> also indicates that this exemplary preferred access-control system contemplates the implementation of three different access-control models. At any given instant, either an uncontrolled-access-control model <b>68</b> or a controlled-access-control model <b>70</b> may be active. Two controlled-access-control models <b>70</b> are depicted. One is an unadministered-controlled-access-control model <b>72</b>, and the other is an administered-controlled-access-control model <b>74</b>. Uncontrolled-access-control model <b>68</b> is the least restrictive access-control model <b>60</b>, while administered-controlled-access-control model <b>74</b> is the most restrictive access-control model <b>60</b>. Those skilled in the art will appreciate the precise number or nature of software-restriction classes <b>58</b> and/or access-control models <b>60</b> may vary from application to application.

Table <b>56</b> further indicates that licensing may be of the “licensed” status <b>76</b> or the “unlicensed” status <b>78</b>. Accordingly, for the exemplary preferred access-control system shown in <figref idref="DRAWINGS">FIG. 3</figref>, eighteen different access scenarios are presented, with each scenario characterized by a software-restriction class into which the requested software module <b>16</b> has been classified, an access-control model <b>60</b> that has been activated for device <b>10</b>, and a licensing status for the requested software module <b>16</b>. Of the eighteen scenarios, nine are associated with unlicensed modules <b>18</b> (<figref idref="DRAWINGS">FIG. 1</figref>). In each of these nine unlicensed scenarios, no access is granted to the requested software module <b>16</b>.

Three of the remaining nine scenarios occur when uncontrolled-access-control model <b>68</b> is active and a requested module <b>16</b> is licensed. When uncontrolled-access-control model <b>68</b> is active, no externally-supplied token is required to grant access to a requested, licensed plain-text software module <b>16</b>, regardless of which software-restriction class <b>58</b> into which the requested software module may have been classified. Thus, table <b>56</b> indicates that internally-supplied token <b>55</b> is used to grant access. Likewise, whenever the requested software module <b>16</b> has been classified in the global software-restriction class <b>62</b>, no externally-supplied token is required to grant access, regardless of which access-control model <b>60</b> may be active for device <b>10</b>. Again, table <b>56</b> indicates that internally-supplied token <b>55</b> is used to grant access.

However, externally-supplied tokens <b>80</b> or <b>82</b> are required in order to grant access to a requested plain-text software module <b>16</b> in several scenarios. When unadministered-controlled-access-control model <b>72</b> is active and the requested software module <b>16</b> has been classified as being either in the constrained software-restriction class <b>64</b> or the administration software-restriction class <b>66</b>, then an externally-supplied common token <b>80</b> is required before access is granted to the requested software module <b>16</b>. When administered-controlled-access-control model <b>74</b> is active and the requested software module <b>16</b> has been classified as being in constrained software-restriction class <b>64</b>, then an externally-supplied token is required before access is granted to the requested software module <b>16</b>. The externally-supplied token may be either a common token <b>80</b> or an administrator token <b>82</b>. However, when administered-controlled-access-control model <b>74</b> is active and the requested software module <b>16</b> has been classified as being in administration software-restriction class <b>66</b>, then the externally-supplied administrator token <b>82</b> is required before access is granted to the requested software module <b>16</b>.

Referring to <figref idref="DRAWINGS">FIGS. 2-3</figref>, processor <b>24</b> includes a query task <b>84</b> that determines whether a request for a plain-text software module <b>16</b> has been received. Program control remains at task <b>84</b> until such a request is detected. Upon the receipt of a request to access one of software modules <b>16</b>, a query task <b>86</b> determines whether uncontrolled-access-control model <b>68</b> is currently active for device <b>10</b>. Task <b>86</b> may make its determination by examining a memory location in anti-tamper memory <b>40</b> (<figref idref="DRAWINGS">FIG. 1</figref>) used to identify the currently active access-control model <b>60</b>. If uncontrolled-access-control model <b>68</b> is found to be active at task <b>86</b>, a task <b>88</b> is performed to get an appropriate token-key <b>57</b> (<figref idref="DRAWINGS">FIG. 1</figref>) from internally-supplied token <b>55</b> (<figref idref="DRAWINGS">FIGS. 1-2</figref>), and program control proceeds to module-activator <b>26</b>. By using internally-supplied token <b>55</b>, access will be automatically granted to the requested software module <b>16</b> if it is licensed. No externally-provided token is required.

If task <b>86</b> determines that a controlled-access-control model <b>70</b> is active, then a query task <b>90</b> determines whether the software-restriction (SW-restriction) class <b>58</b> of the requested software module <b>16</b> is greater (i.e., more restrictive) than global software-restriction class <b>62</b>. If the software-restriction (SW-restriction) class <b>58</b> of the requested software module <b>16</b> is not greater than global software-restriction class <b>62</b> (i.e., equals global software-restriction class <b>62</b>) then task <b>88</b> is performed to get an appropriate token-key <b>57</b> from internally-supplied token <b>55</b> (<figref idref="DRAWINGS">FIGS. 1-2</figref>), and program control proceeds to module-activator <b>26</b>. Access will be automatically granted without requiring an externally-provided token so long as the requested software module <b>16</b> is licensed.

If task <b>90</b> determines that the software-restriction class <b>58</b> of the requested software module <b>16</b> is greater than global (i.e., is constrained or administration software-restriction classes <b>64</b> or <b>66</b>), then a task <b>92</b> gets an externally-supplied token <b>80</b> or <b>82</b> from the user. If no such token is eventually provided, then an appropriate error handler (not shown) may effectively deny access to the requested software module <b>16</b> and return program control to task <b>84</b>. In addition, task <b>92</b> may also obtain a user ID from the user, and the user ID may desirably be associated with a flag indicating whether or not the user is an administrator.

Next, a query task <b>94</b> determines whether the current scenario is one where the requested software module <b>16</b> has been classified into constrained software-restriction class <b>66</b>. If such a scenario is detected, then program control passes to module-activator <b>26</b> where access will be granted using externally-supplied common token <b>80</b> or administrator token <b>82</b> so long as the requested software module <b>16</b> is licensed.

When task <b>94</b> fails to detect such a scenario, a query task <b>96</b> determines whether the current scenario is one where the requested software module <b>16</b> has been classified into administration software-restriction class <b>66</b>, administered-controlled-access-control model <b>74</b> is currently active, and the administrator token <b>82</b> was provided above in task <b>92</b>. If such a scenario is detected, then program control again passes to module-activator <b>26</b> where access will be granted using externally-supplied administrator token <b>82</b> so long as the requested software module <b>16</b> is licensed.

When task <b>96</b> fails to detect such a scenario, a query task <b>98</b> determines whether the current scenario is one where unadministered-controlled-access-control model <b>72</b> is currently active, and a common token <b>80</b> has been provided above in task <b>92</b>. If such a scenario is detected, then program control again passes to module-activator <b>26</b> where access will be granted using externally-supplied common token <b>80</b> so long as the requested software module <b>16</b> is licensed.

When task <b>98</b> fails to detect such a scenario, an appropriate deny access process <b>100</b> is performed. Process <b>100</b> may inform the user that access is being denied, but process <b>100</b> will prevent the requested plain-text software module <b>16</b> from becoming decrypted, much less activated thereafter. After deny access process <b>100</b>, program control loops back to task <b>84</b> to await another request for access to a software module <b>16</b>. Likewise, when module-activator <b>26</b> is complete, program control loops back to task <b>84</b> to await another request for access to a software module <b>16</b>.

<figref idref="DRAWINGS">FIG. 4</figref> shows a flow chart depicting an exemplary form of operation for module-activator <b>26</b>. Module-activator <b>26</b> is invoked from access-control-processor <b>24</b> (<figref idref="DRAWINGS">FIG. 1</figref>) as discussed above. Module-activator <b>26</b> includes a task <b>102</b> in which an appropriate split-key <b>48</b> (<figref idref="DRAWINGS">FIG. 1</figref>) for the requested module <b>14</b> is obtained from split-key register <b>46</b> (<figref idref="DRAWINGS">FIG. 1</figref>). If internally-supplied token <b>55</b> is being used, then split-key <b>48</b> is obtained from internal user table <b>44</b> (<figref idref="DRAWINGS">FIG. 1</figref>). Otherwise, if an externally-supplied token <b>80</b> or <b>82</b> is being used, then split-key <b>48</b> is obtained from the user table <b>42</b> of the user that provided the token. The split-key <b>48</b> obtained in task <b>102</b> may be either a genuine split-key <b>50</b> (<figref idref="DRAWINGS">FIG. 1</figref>) or an artificial split-key <b>52</b> (<figref idref="DRAWINGS">FIG. 1</figref>).

After task <b>102</b>, a task <b>104</b> combines an appropriate token-key <b>57</b> from the token <b>55</b>, <b>80</b>, or <b>82</b> obtained above in tasks <b>88</b> or <b>92</b> (<figref idref="DRAWINGS">FIG. 2</figref>), with split-key <b>48</b> to regenerate a cipher-key <b>106</b>. Task <b>104</b> desirably stores the just-generated cipher-key <b>106</b> in internal memory <b>22</b> (<figref idref="DRAWINGS">FIG. 1</figref>). Task <b>104</b> implements a predetermined combination function with the following property: when a token-key <b>57</b> is combined with a split-key <b>48</b>, a cipher-key <b>106</b> results; when this cipher-key <b>106</b> is combined with the same token-key <b>57</b>, the same split-key <b>48</b> appears; and, when the cipher-key <b>106</b> is combined with the same split-key <b>48</b>, the same token-key <b>57</b> appears. A bitwise exclusive-or and a bitwise exclusive-nor operation represent two combination functions that provide this property, but other combinations functions may be devised as well. Desirably, split-key <b>48</b>, token-key <b>57</b>, and cipher-key <b>106</b> all have the same bit length. The same combination function is used at the various tasks within device <b>10</b> where token-keys <b>57</b> and split keys <b>48</b> are combined, where split-keys <b>48</b> and cipher-keys <b>106</b> are combined, where token-keys <b>57</b> and cipher-keys <b>106</b> are combined, and the like.

Next, a task <b>108</b> uses cipher-key <b>106</b> to decrypt a cipher-text software module <b>14</b> to form the requested plain-text software module <b>16</b>, which is desirably then stored in internal memory <b>22</b> (<figref idref="DRAWINGS">FIG. 1</figref>). Following task <b>108</b>, a task <b>110</b> destroys cipher-key <b>106</b> to promote the security of software modules <b>16</b> by completely removing cipher-key <b>106</b> from device <b>10</b>. Those skilled in the art will appreciate that cipher-key <b>106</b> or other data may be destroyed by overwriting the physical memory location where that data was stored with other data having no particular relationship with the just-destroyed data.

Nothing mandates the decryption to have been carried out successfully above in task <b>108</b>. In fact, if an improper token-key <b>57</b> or an artificial split-key <b>52</b> (<figref idref="DRAWINGS">FIG. 1</figref>) was used in generating cipher-key <b>106</b>, then the decryption was not carried out successfully. One situation where an unsuccessful decryption will take place is when an attempt is made to decrypt unlicensed modules <b>18</b> (<figref idref="DRAWINGS">FIG. 1</figref>) because artificial split-keys <b>52</b> are stored therefor in user tables <b>42</b> (<figref idref="DRAWINGS">FIG. 1</figref>). Only if the proper token-key <b>57</b> and a genuine split-key <b>50</b> were combined in task <b>104</b> to generate cipher-key <b>106</b> will the decryption have been carried out successfully. Following task <b>110</b>, a query task <b>112</b> determines whether the decryption was successful. A variety of diverse activities may take place at task <b>112</b> to evaluate whether a decryption was successful. In one embodiment, task <b>112</b> may look for specific test data embedded in module <b>16</b>. In another embodiment, task <b>112</b> may verify a digital certificate or checksum for module <b>16</b>. If an unsuccessful decryption is detected, deny access process <b>100</b> is performed, and program control passes back to access-control-processor <b>24</b>. Access will be denied to the requested software module <b>16</b>. When task <b>112</b> determines that the decryption was successful, an activate module process <b>114</b> is performed. Activate module process <b>114</b> launches, executes, invokes, opens, or otherwise makes the requested plain-text software module <b>16</b> available to the user on device <b>10</b>. The precise nature of the processing performed and of the data upon which processing takes place are not relevant in the present invention.

For the purposes of illustrating the preferred embodiment of the present invention, <figref idref="DRAWINGS">FIG. 4</figref> illustrates activate module process <b>114</b> as including a query task <b>116</b>. Query task <b>116</b> would typically be implemented only by a software module <b>16</b> which, when activated, permitted a user to add or delete users of device <b>10</b>. In a typical application, such a software module <b>16</b> would be classified into the administration software-restriction class <b>66</b> (<figref idref="DRAWINGS">FIG. 3</figref>). If uncontrolled-access-control model <b>68</b> (<figref idref="DRAWINGS">FIG. 3</figref>) were active, then any user with physical access to device <b>10</b> could automatically activate such a module without supplying an externally-supplied token <b>80</b> or <b>82</b>. If unadministered-controlled-access-control model <b>72</b> (<figref idref="DRAWINGS">FIG. 3</figref>) were active, then a user would be required to produce a suitable common token <b>80</b> that, when combined with a genuine split-key <b>50</b> for that user and for that software module <b>16</b>, would produce the proper cipher-key <b>106</b> in order to activate such a module. If administered-controlled-access-control model <b>74</b> (<figref idref="DRAWINGS">FIG. 3</figref>) were active, then a user would be required to produce a proper administrator token <b>82</b> that, when combined with a genuine split-key <b>50</b> for that user and for that software module <b>16</b>, would produce the proper cipher-key <b>106</b> in order to activate such a module. When query task <b>116</b> determines that a request is being made to add or delete a user, access-control-model-activator <b>28</b> is performed. Access-control-model-activator <b>28</b> is discussed in more detail below in connection with <figref idref="DRAWINGS">FIG. 5</figref>.

In addition, activate module process <b>114</b> also includes a query task <b>118</b> which determines when the user is finished with the requested plain-text software module <b>16</b>. So long as the user is not yet finished, program control remains in activate module process <b>114</b>. However, when the user is finished, program control exits activate module process <b>114</b> and proceeds to a task <b>120</b>, which then destroys the plain-text software module <b>16</b> resident in internal memory <b>22</b> (<figref idref="DRAWINGS">FIG. 1</figref>). At this point, neither plain-text software module <b>16</b> nor the cipher-key <b>106</b> needed to decrypt it is available within device <b>10</b>, and program control passes back to access-control processor <b>24</b>.

<figref idref="DRAWINGS">FIG. 5</figref> shows a flow chart depicting an exemplary form of operation for access-control-model-activator <b>28</b>. Access-control-model-activator <b>28</b> determines which one of access-control models <b>60</b> (<figref idref="DRAWINGS">FIG. 3</figref>) is currently active for device <b>10</b>. Access-control-model-activator <b>28</b> is automatically driven in the preferred embodiment by the addition and deletion of users, and may be automatically invoked when activate module process <b>114</b> (<figref idref="DRAWINGS">FIG. 4</figref>) is also active in connection with a software module <b>16</b> that provides the function of adding and deleting users, as discussed above in connection with <figref idref="DRAWINGS">FIG. 4</figref>.

Access-control-model-activator <b>28</b> includes a query task <b>121</b> which determines whether a user is being added or deleted. If a user is being deleted, then a delete user process <b>122</b> is performed. Delete user process <b>122</b> is discussed below in connection with <figref idref="DRAWINGS">FIG. 6</figref>. When delete user process <b>122</b> is complete, program control returns to a calling routine, such as access-control-processor <b>24</b> (<figref idref="DRAWINGS">FIG. 4</figref>).

When task <b>121</b> determines that a user is to be added, a task <b>124</b> initially specifies that internally-supplied token <b>55</b> should be used as a sponsor token. This initial specification may be overwritten later with an externally-supplied token <b>80</b> or <b>82</b>, and subsequent tasks will use the sponsor token, regardless of whether it is an internally-supplied or externally-supplied token.

As depicted in <figref idref="DRAWINGS">FIG. 3</figref>, if device <b>10</b> is being operated with uncontrolled-access-control model <b>68</b> (<figref idref="DRAWINGS">FIG. 3</figref>), there is no need to add a user. Anyone who has access to device <b>10</b> will be granted access to any licensed software module <b>16</b> through the use of internally-supplied token <b>55</b>. The virtual “internal” user serves as a proxy for all users. Accordingly, the act of adding a user serves as a signal to device <b>10</b> to deactivate uncontrolled-access-control model <b>68</b>, if it is active, and activate some other access-control model <b>60</b> (<figref idref="DRAWINGS">FIG. 3</figref>).

After task <b>124</b>, a query task <b>126</b> determines whether the current active access-control model <b>60</b> (<figref idref="DRAWINGS">FIG. 3</figref>) is the uncontrolled-access-control model <b>68</b> (<figref idref="DRAWINGS">FIG. 3</figref>). If task <b>126</b> determines the current active access-control model <b>60</b> is not uncontrolled-access-controlled model <b>68</b>, but is a controlled-access-control model <b>70</b> (<figref idref="DRAWINGS">FIG. 3</figref>), then a task <b>128</b> overwrites the sponsor token with the externally-supplied token <b>80</b> or <b>82</b> obtained above in task <b>92</b> of access-control processor <b>24</b> (<figref idref="DRAWINGS">FIG. 2</figref>). When task <b>126</b> determines that uncontrolled-access-control-model <b>68</b> is currently active or upon the completion of task <b>128</b>, a task <b>130</b> gets a new token from the user being added to device <b>10</b>. This new token will be an externally-supplied token since it is coming from outside device <b>10</b>.

Next, a query task <b>132</b> determines whether administered-controlled-access-control model <b>74</b> (<figref idref="DRAWINGS">FIG. 3</figref>) is currently active. If administered-controlled-access-control model <b>74</b> is currently active, the adding of a new user signals that model <b>74</b> should remain active, and program control proceeds to a task <b>134</b>. Task <b>134</b> gets token-keys <b>57</b> for all software modules <b>16</b> classified in constrained software-restriction class <b>64</b> (<figref idref="DRAWINGS">FIG. 3</figref>). Token-keys <b>57</b> for software modules <b>16</b> are desirably obtained regardless of whether the software modules <b>16</b> have a licensed status <b>76</b> or an unlicensed status <b>78</b> (<figref idref="DRAWINGS">FIG. 3</figref>). In the preferred embodiment, only one administrator is permitted for device <b>10</b>. Since device <b>10</b> is currently operating with administered-controlled-access-control model <b>74</b> activated, an administrator has already been assigned and another one will not be permitted. Hence, task <b>134</b> may omit token-keys <b>57</b> for software-modules <b>16</b> classified in administration software-restriction class <b>66</b> (<figref idref="DRAWINGS">FIG. 3</figref>) because this new user will not be permitted to access such software modules <b>16</b>. The token-keys <b>57</b> are supplied in response to the token obtained above in task <b>130</b>, and this token will become a common token <b>80</b> (<figref idref="DRAWINGS">FIG. 3</figref>). When the user has been added, the new access-control model <b>60</b> will again be administered-controlled-access-control model <b>74</b> (<figref idref="DRAWINGS">FIG. 3</figref>), and the new user will be granted access only to software modules <b>16</b> classified in constrained software-restriction class <b>64</b>.

When query task <b>132</b> determines that administered-controlled-access-control model <b>74</b> is not currently active (i.e., either uncontrolled- or unadministered-controlled-access-control models <b>68</b> or <b>72</b> are active) the adding of a new user may signal a desire to activate a more restrictive model <b>60</b>. In this situation, a query task <b>136</b> determines, perhaps through user-supplied responses to user-presented prompts, whether the new user and token are to be associated with the administrator role. If task <b>136</b> determines that an administrator role is to be assumed by the new user and token, then a task <b>138</b> gets token-keys <b>57</b> from the new token obtained above in task <b>130</b> for all software modules <b>16</b> classified in administration software-restriction class <b>66</b> (<figref idref="DRAWINGS">FIG. 3</figref>). Token-keys <b>57</b> for software modules <b>16</b> are desirably obtained regardless of whether the software modules <b>16</b> have a licensed status <b>76</b> or an unlicensed status <b>78</b> (<figref idref="DRAWINGS">FIG. 3</figref>). Following task <b>138</b>, a task <b>140</b> tags the new user's ID as being in the administrator role. Program control then proceeds to task <b>134</b>, where token-keys <b>57</b> are obtained for software modules <b>16</b> classified in constrained software-restriction class <b>64</b> (<figref idref="DRAWINGS">FIG. 3</figref>). The token supplied above in task <b>130</b> will become an administrator token <b>82</b> (<figref idref="DRAWINGS">FIG. 3</figref>), when the user has been added the new access-control model <b>60</b> will be administered-controlled-access-control model <b>74</b> (<figref idref="DRAWINGS">FIG. 3</figref>), and the new user will be granted access to software modules <b>16</b> classified in administration software-restriction class <b>66</b> and constrained software-restriction class <b>64</b>.

When task <b>136</b> determines that an administrator role is not to be assumed by the new user and token, the new access-control model <b>60</b> will end up being unadministered-controlled-access-control model <b>72</b> (<figref idref="DRAWINGS">FIG. 3</figref>). Accordingly, a task <b>142</b> gets token-keys <b>57</b> for all software modules <b>16</b> classified in administration software-restriction classes <b>66</b> (<figref idref="DRAWINGS">FIG. 3</figref>). Token-keys <b>57</b> for software modules <b>16</b> are desirably obtained regardless of whether the software modules <b>16</b> have a licensed status <b>76</b> or an unlicensed status <b>78</b> (<figref idref="DRAWINGS">FIG. 3</figref>). After task <b>142</b>, program control flows to task <b>134</b> to get token-keys <b>57</b> for all software modules <b>16</b> classified in constrained software-restriction class <b>64</b> (<figref idref="DRAWINGS">FIG. 3</figref>). The token obtained above in task <b>130</b> will become a common token <b>80</b>, and the new user will be granted access to all software modules <b>16</b> classified in constrained and administration software-restriction classes <b>64</b> and <b>66</b>.

Upon the completion of task <b>134</b>, a task <b>144</b> is performed. Task <b>144</b> combines the sponsor's token-keys obtained above in task <b>124</b> but possibly overwritten in task <b>128</b> with their corresponding split-keys <b>48</b> (<figref idref="DRAWINGS">FIG. 1</figref>) to form cipher-keys <b>106</b> (<figref idref="DRAWINGS">FIG. 4</figref>). The corresponding split-keys <b>48</b> may be either genuine split-keys <b>50</b> or artificial split-keys <b>52</b>. Consequently, the resulting cipher-keys <b>106</b> may or may not be usable to successfully decrypt the subject software modules <b>16</b>. For example, artificial split-keys <b>52</b> will be obtained for any unlicensed modules <b>18</b> (<figref idref="DRAWINGS">FIG. 1</figref>), and the resulting cipher-keys <b>106</b> would produce an unsuccessful decryption. Next, a task <b>146</b> gets the new token-keys obtained above in tasks <b>134</b>, <b>138</b>, or <b>142</b> for the new user.

Following task <b>146</b>, a task <b>148</b> combines these new token-keys <b>57</b> with those cipher-keys <b>106</b> generated above in task <b>144</b> that correspond to the new token-keys <b>57</b>. The combination operation performed in task <b>148</b> generates new split-keys <b>48</b> for the new token-keys <b>57</b>. To the extent that genuine split-keys <b>50</b> were used above in task <b>144</b>, the resulting split-keys <b>48</b> generated in task <b>148</b> will also be genuine split-keys <b>50</b>. However, for those software modules <b>16</b> for which artificial split-keys <b>52</b> were used above in task <b>144</b>, artificial split-keys <b>52</b> will be generated in task <b>148</b>.

After task <b>148</b>, a task <b>150</b> saves the new split-keys <b>48</b> in a split-key register <b>46</b> (<figref idref="DRAWINGS">FIG. 1</figref>) of a user table <b>42</b> for the new user. The new split-keys <b>48</b> are stored in association with the software modules <b>16</b> for which they are provided. After task <b>150</b>, a task <b>152</b> deactivates the old access-control model <b>60</b> that was active upon entry to access-control-model-activator <b>28</b> and activates the new access-control model <b>60</b>. As discussed above, the new access-control model <b>60</b> will be one of the controlled access-control models <b>70</b>. In certain scenarios both the old and new controlled access-control models <b>60</b> may be the same controlled access-control model <b>70</b>. Task <b>152</b> may be performed by recording an appropriate entry at an appropriate location in the memory space of processor <b>20</b> (<figref idref="DRAWINGS">FIG. 1</figref>). After task <b>152</b>, program flow exits access-control-model-activator <b>28</b> and returns to a calling routine, such as access-control-processor <b>24</b> (<figref idref="DRAWINGS">FIG. 4</figref>).

<figref idref="DRAWINGS">FIG. 6</figref> shows a flow chart depicting an exemplary form of operation for delete user process <b>122</b>. Delete user process <b>122</b> may be invoked as a part of access-control-model-activator <b>28</b> (<figref idref="DRAWINGS">FIG. 5</figref>) when an appropriately authorized user wishes to delete a user from device <b>10</b>. In the preferred embodiment, delete user process <b>122</b> is classified in global software-restriction class <b>62</b> so that any user is authorized to delete a user. However, this is not a requirement and other classifications may be applied as well.

Delete user process <b>122</b> includes a task <b>154</b> that obtains the user ID of the user that is to be deleted. The user ID may be obtained from the user table <b>42</b> (<figref idref="DRAWINGS">FIG. 1</figref>) for the to-be-deleted user. Task <b>154</b> is preferably configured so that the virtual internal user cannot be deleted.

Following task <b>154</b>, a task <b>156</b> destroys all split-keys <b>48</b> (<figref idref="DRAWINGS">FIG. 1</figref>) stored in the split-key register <b>46</b> (<figref idref="DRAWINGS">FIG. 1</figref>) of the to-be-deleted user's user table <b>42</b>. When the to-be-deleted user's split-keys <b>46</b> have been destroyed, the to-be-deleted user's token will no longer be able to generate, within a reasonable degree of cryptographic certainty, a cipher-key that can successfully decrypt any software module <b>16</b>, and the installation of the user has effectively been deleted from device <b>10</b>. However, nothing prevents the now-deleted user from accessing licensed software modules <b>16</b> classified in global software-restriction class <b>62</b> (<figref idref="DRAWINGS">FIG. 3</figref>), or from accessing any licensed software module <b>16</b> should uncontrolled-access-control model <b>68</b> (<figref idref="DRAWINGS">FIG. 3</figref>) become active.

After task <b>156</b>, a query task <b>158</b> determines whether the now-deleted user is the last user installed on device <b>10</b>. So long as other external users remain installed on device <b>10</b>, device <b>10</b> is automatically signaled to remain in the controlled-access-control model <b>70</b> that is now active. Consequently, program control exits delete user process <b>122</b> and returns to a calling routine, such as access-control-model-activator <b>28</b>.

When task <b>158</b> discovers that the last user has just been deleted from secure device <b>10</b>, a task <b>160</b> deactivates the controlled-access-control model <b>70</b> (<figref idref="DRAWINGS">FIG. 3</figref>) that is currently active and then activates uncontrolled-access-control model <b>68</b> (<figref idref="DRAWINGS">FIG. 3</figref>). Task <b>166</b> may be performed by recording an appropriate entry at an appropriate location in the memory space of processor <b>20</b> (<figref idref="DRAWINGS">FIG. 1</figref>). Presumably, this last user is the very same user that is currently logged on device <b>10</b>. After task <b>160</b>, program flow returns to a calling routine.

The access-control system implemented by device <b>10</b> and described above allows software to be managed in a beneficial manner throughout the lifecycle of the software. The software lifecycle would typically, but not necessarily, begin prior to delivery of device <b>10</b> to a customer and continue long after device <b>10</b> has been delivered to the customer. Moreover, this software lifecycle would apply to an entire population of devices similar to device <b>10</b>.

<figref idref="DRAWINGS">FIG. 7</figref> shows a flow chart of a software manufacturing process <b>172</b> that may be carried out by a manufacturer in connection with software modules <b>16</b> to be loaded on device <b>10</b>. Process <b>172</b> is performed prior to the delivery of device <b>10</b> to a customer, but may also be performed from time-to-time as needed with respect to new and/or revised software for device <b>10</b>. Process <b>172</b> may be performed without respect to any single particular device <b>10</b> and without respect to which software modules <b>16</b> will be used on or licensed for use by any particular device <b>10</b>.

Process <b>172</b> includes a task <b>174</b> during which the latest versions of an entire set <b>176</b> of plain-text software modules <b>16</b> are obtained. Entire set <b>176</b> may include unlicensed modules <b>18</b> (<figref idref="DRAWINGS">FIG. 1</figref>). Desirably, entire set <b>176</b> includes all software modules <b>16</b> that are or will be supported by the manufacturer for device <b>10</b> and may include a greater number of software modules <b>16</b> than will be licensed for any single device <b>10</b>.

After task <b>174</b>, software manufacturing process <b>172</b> as depicted in <figref idref="DRAWINGS">FIG. 7</figref> operates in a loop, where one iteration of the loop is performed for each software module <b>16</b> in entire set <b>176</b>. A task <b>178</b> in this loop identifies (ID) the next software module <b>16</b> in set <b>176</b> that has not been previously processed by software manufacturing process <b>172</b>. Next, a task <b>180</b> classifies this software module <b>16</b> into an appropriate software-restriction class <b>58</b> (<figref idref="DRAWINGS">FIG. 3</figref>). Task <b>180</b> may occur interactively or otherwise in response to input from the engineers and designers of device <b>10</b>, entire set <b>176</b>, and the subject software module <b>16</b>.

After task <b>180</b>, a task <b>182</b> encrypts the subject software module <b>16</b> using a designated cipher-key <b>106</b>. Cipher-key <b>106</b> is desirably a random number that is desirably maintained in a secure state by the manufacturer. Cipher-key <b>106</b> may itself be encrypted for storage by the manufacturer as cipher-text, decrypted into a plain-text cipher-key <b>106</b> for use by process <b>172</b>, then the plain-text cipher-key <b>106</b> may be destroyed after task <b>182</b>. In one preferred embodiment, during each performance of software manufacturing process <b>172</b>, the same cipher-keys <b>106</b> are used to encrypt the same software modules <b>16</b> of entire set <b>176</b>. In other words, a given software module <b>16</b> is encrypted using the same cipher-key <b>106</b> each time process <b>172</b> is performed. But nothing requires different software modules <b>16</b> to be encrypted using the same cipher-keys <b>106</b>; and, in fact, different software modules <b>16</b> are encrypted using different cipher-keys <b>106</b> in the preferred embodiment. The consistent use of cipher-keys <b>106</b> provides benefits with respect to licensing previously unlicensed software modules <b>16</b> and upgrading software modules <b>16</b> after delivery of device <b>10</b>, as discussed in more detail below.

After task <b>182</b>, a task <b>184</b> saves the encrypted, cipher-text subject software module <b>14</b> formed by task <b>182</b>. The subject software module <b>14</b> is saved in connection with an entire set <b>186</b> of cipher-text software modules <b>14</b>. After task <b>184</b>, a query task <b>188</b> determines whether the last software module <b>16</b> from entire set <b>176</b> has been encrypted. So long as additional software modules <b>16</b> remain in entire set <b>176</b>, process flow loops back to task <b>178</b> to process an additional software module <b>16</b>. When the last software module <b>16</b> has been encrypted, software manufacturing process <b>172</b> ends.

<figref idref="DRAWINGS">FIG. 8</figref> shows a flow chart of a hardware manufacturing process <b>190</b> that may be carried out by the manufacturer with respect to a batch that includes any number of programmable electronic devices <b>10</b>. Hardware manufacturing process <b>190</b> is presumably carried out some time after a performance of software manufacturing process <b>172</b>, and an entire set <b>186</b> (<figref idref="DRAWINGS">FIG. 7</figref>) of cipher-text software modules <b>14</b> are available for installation on devices <b>10</b>.

Hardware manufacturing process <b>190</b> includes a task <b>192</b> in which a specific physical device <b>10</b> is obtained. Device <b>10</b> may be manufactured or assembled by this manufacturer, or device <b>10</b> may be purchased as a completed assembly by this manufacturer. However, device <b>10</b> need not have software installed thereon.

Next, a task <b>194</b> is performed to load entire set <b>186</b> of original cipher-text software modules <b>14</b> in device <b>10</b>. At task <b>194</b>, entire set <b>186</b> is considered to be original software modules <b>14</b> because these software modules <b>14</b> will be the ones originally delivered to a customer. These original software modules <b>14</b> may be contrasted with updated modules <b>14</b> that may be provided after delivery. Desirably, task <b>194</b> does nothing to load any cipher-key, split-key, or token-key in device <b>10</b>. Consequently, at this point no information is present in device <b>10</b> with which to decrypt and use any software module <b>16</b>, at least to a cryptographically reasonable degree of certainty. However, additional plain-text software may also be loaded in device <b>10</b> during task <b>194</b>, and such plain-text software may very well be usable.

After task <b>194</b>, a query task <b>196</b> determines whether original cipher-text software modules <b>14</b> have been loaded in the last device <b>10</b> in the batch of devices <b>10</b>. So long as additional devices <b>10</b> remain, process flow loops back to task <b>192</b> to load entire set <b>186</b> in another device <b>10</b>. When the last device <b>10</b> has been loaded, hardware manufacturing process <b>190</b> ends. Accordingly, through the performance of hardware manufacturing process <b>190</b>, a plurality of devices <b>10</b> are configured so that each device <b>10</b> is loaded with entire set <b>186</b> of cipher-text software modules <b>14</b>.

<figref idref="DRAWINGS">FIG. 9</figref>. shows a flow chart of a delivery process <b>198</b> that may be carried out by the manufacturer with respect to a specific device <b>10</b>. Delivery process <b>198</b> may be repeated for each device <b>10</b> to be delivered within a population of customers. In general, delivery process <b>198</b> provisions device <b>10</b> so that at least some of cipher-text software modules <b>14</b> loaded therein are licensed to and usable by the customer that is to receive the device <b>10</b>. Delivery process <b>198</b> is performed after hardware manufacturing process <b>190</b> (<figref idref="DRAWINGS">FIG. 8</figref>).

Delivery process <b>198</b> includes a task <b>200</b> which generates a unique token having a number of token-keys at least equal to the number of cipher-keys <b>106</b> used during software manufacturing process <b>172</b> (<figref idref="DRAWINGS">FIG. 7</figref>) to encrypt entire set <b>176</b> of original plain-text software modules <b>16</b>. Desirably, task <b>200</b> uses a random number in generating its token, and the resulting token is unique to the device <b>10</b> for which it is generated. Of course, the token need only be unique to the extent that it is highly unlikely that another device <b>10</b> will get the same token.

Next, a task <b>202</b> activates a specified access-control model <b>60</b> (<figref idref="DRAWINGS">FIG. 3</figref>) for the subject device <b>10</b>. Task <b>202</b> may be performed by recording an appropriate entry at an appropriate location in the memory space of processor <b>20</b> (<figref idref="DRAWINGS">FIG. 1</figref>). In the preferred embodiment, uncontrolled-access-control model <b>68</b> is activated at task <b>202</b>. By activating uncontrolled-access-control model <b>68</b>, device <b>10</b> will be immediately usable by the customer upon delivery. In other words, device <b>10</b> will be usable “out-of-the-box”. As the customer becomes more familiar with the capabilities of device <b>10</b> and with its own security needs, a range of more restrictive access-control models <b>60</b> may be activated as discussed above. However, other access-control models <b>60</b> may be activated in task <b>202</b>. For example, certain customers may prefer that the manufacturer to deliver device <b>10</b> with administered-controlled access-control model <b>74</b> active.

After task <b>202</b>, delivery process <b>198</b> operates in a programming loop, with each iteration of the loop being dedicated to a different software module <b>14</b> included in entire set <b>186</b> (<figref idref="DRAWINGS">FIG. 7</figref>) loaded in device <b>10</b>. This loop includes a task <b>204</b>, which identifies the next original cipher-text software module <b>14</b> previously loaded in device <b>10</b>. Next, a query task <b>206</b> determines whether this subject software module <b>14</b> is to be licensed for use on this device <b>10</b>. The determination of task <b>206</b> may be made by obtaining information from an order-form document or the like. In one embodiment, a customer may wish to have device <b>10</b> delivered with certain security-critical software modules <b>14</b> classified as being unlicensed modules, even though that customer is otherwise entitled to access such modules. Such unlicensed modules may become licensed later through a licensing process, discussed below.

If the subject software module <b>14</b> is to be delivered as an unlicensed module, a task <b>208</b> saves a token-key generated above in task <b>200</b> and an artificial split-key <b>52</b> (<figref idref="DRAWINGS">FIG. 1</figref>) in user table <b>44</b> (<figref idref="DRAWINGS">FIG. 1</figref>) for the virtual internal user. The token-key and split-key are saved in a way that associates them with the subject software module <b>14</b> within device <b>10</b>. The artificial split-key <b>52</b> may be generated by a random number generator and should share no cryptographically significant relationship with the token-key and the cipher-key <b>106</b> used in encrypting the subject software module <b>14</b>. Accordingly, the customer will have no key or other information within device <b>10</b> with which to form a cipher-key <b>106</b> that will allow the unlicensed subject software module <b>14</b> to be used on device <b>10</b>.

Following task <b>208</b>, a task <b>209</b> records the artificial split-key <b>52</b> generated above in task <b>208</b> in a secure database maintained by the manufacturer. Desirably, this artificial split-key <b>52</b> is saved in association with other identifying information, such as customer identity, device <b>10</b> serial number, and the like. The recorded artificial split-key saved by the manufacturer may be used later to license the subject software module <b>14</b>.

After task <b>209</b>, a query task <b>210</b> determines whether the subject software module <b>14</b> was the last software module <b>14</b> within entire set <b>186</b> (<figref idref="DRAWINGS">FIG. 7</figref>). So long as another software module <b>14</b> remains to be evaluated for licensing status, program flow returns to task <b>204</b>.

When task <b>206</b> determines that a subject software module <b>14</b> is to be licensed for use on the subject device <b>10</b>, a task <b>212</b> is performed. Task <b>212</b> gets the same cipher-key <b>106</b> (<figref idref="DRAWINGS">FIG. 7</figref>) that was used in software manufacturing process <b>172</b> (<figref idref="DRAWINGS">FIG. 7</figref>) to encrypt the subject software module <b>16</b>. Then, a task <b>214</b> combines a token-key obtained above in task <b>200</b> with this cipher-key <b>106</b> to generate a genuine split-key <b>50</b>. At the completion of task <b>214</b>, cipher-key <b>106</b> may be destroyed or otherwise secured to preserve its security.

Since the token-key obtained in task <b>200</b> was unique to this device <b>10</b>, the genuine split-key <b>50</b> will also be unique to this device <b>10</b>. Consequently, within a population of devices <b>10</b>, a token-key that combines with a genuine split-key <b>50</b> on one device <b>10</b> to enable access to a software module <b>16</b> will not combine with a corresponding genuine split-key <b>50</b> in another device <b>10</b> to enable access to the same software module <b>16</b>. The manufacturer is assured that software modules <b>14</b> that have been licensed for use on one device <b>10</b> cannot be used on another device <b>10</b> for which it is not licensed, even though the software modules <b>14</b> are loaded on both devices <b>10</b> and even though users may share tokens. Likewise, if a user's token becomes compromised, that compromised token will not be usable on other devices <b>10</b>.

After task <b>214</b>, a task <b>218</b> saves the genuine split-key <b>50</b> generated above in task <b>214</b> and the token-key used in its generation in internal user table <b>44</b> (<figref idref="DRAWINGS">FIG. 1</figref>). Consequently, regardless of the software-restriction class <b>58</b> (<figref idref="DRAWINGS">FIG. 3</figref>) of the subject software module <b>14</b>, the subject licensed software module <b>14</b> will be immediately usable on device <b>10</b> upon receipt by the customer because access will automatically be granted through the proxy of the virtual internal user. Following task <b>218</b>, program flow proceeds back to task <b>210</b> to determine whether to stop processing software modules <b>14</b>.

While uncontrolled-access-control model <b>68</b> is preferred for delivery process <b>198</b>, nothing prevents a controlled-access-control model <b>70</b> from being initially specified. If a controlled-access-control model <b>70</b> is specified and the subject software module <b>14</b> is classified in constrained or administration software-restriction classes <b>64</b> and <b>66</b>, then desirably only the genuine split-key <b>50</b> is saved, and it is saved in the user table <b>42</b> for user <b>1</b>. The token-key is desirably not saved in device <b>10</b> but printed or otherwise saved outside device <b>10</b> for delivery to the customer separate from device <b>10</b>. Moreover, another token-key is desirably generated and saved in internal user table <b>44</b> (<figref idref="DRAWINGS">FIG. 1</figref>) for such software modules <b>14</b>, but a corresponding genuine split-key <b>50</b> is not saved in internal user table <b>44</b>. This other token-key is included for potential future use only.

When task <b>210</b> eventually determines that the last software module <b>14</b> has been evaluated for licensing status, a task <b>219</b> generates and records additional artificial split-keys <b>52</b> in split-key register <b>47</b> (<figref idref="DRAWINGS">FIG. 1</figref>) of device <b>10</b> and in the secure database maintained by the manufacturer. The additional artificial split-keys <b>52</b> may be generated by a random number generator and should be unique to device <b>10</b> and share no cryptographically significant relationship with other token-keys and/or cipher-keys associated with device <b>10</b>. Desirably, these additional artificial split-keys <b>52</b> are saved in the manufacturer database in association with other identifying information, such as customer identity, device <b>10</b> serial number, and the like. The recorded artificial split-keys saved by the manufacturer may be used later to license the subject software module <b>14</b>.

After task <b>219</b>, a task <b>220</b> is performed to deliver device <b>10</b> to the customer. After task <b>220</b>, delivery process <b>198</b> ends with respect to the subject device <b>10</b>. However, process <b>198</b> may be repeated for any number of devices <b>10</b>, and nothing requires different devices <b>10</b> to be delivered separately to a common customer.

<figref idref="DRAWINGS">FIG. 10</figref> shows a flow chart of a post-delivery process <b>222</b> that may be carried out by a manufacturer with respect to one or more devices <b>10</b>. While process <b>222</b> may be performed at any time, it is most relevant to devices <b>10</b> that have been delivered to customers. Process <b>222</b> includes an upgrade sub-process <b>224</b> and a manufacturer license sub-process <b>226</b>.

Upgrade sub-process <b>224</b> includes an iteration of software manufacturing process <b>172</b> (<figref idref="DRAWINGS">FIG. 7</figref>) using versions of one or more of plain-text software modules <b>16</b> that may have been generated following delivery of device <b>10</b> to the customer, and possibly including modules <b>16</b> that may not have been available in any version prior to the delivery of device <b>10</b>. This iteration of software manufacturing process <b>172</b> may be performed without regard to any particular device <b>10</b>, without regard to which software modules <b>14</b> have been licensed or unlicensed on any particular device <b>10</b>, and without regard to which access-control model <b>60</b> (<figref idref="DRAWINGS">FIG. 3</figref>) may be activated on any particular device <b>10</b>. During this post-delivery iteration of software manufacturing process <b>172</b>, an entire set <b>228</b> of updated plain-text software modules <b>16</b> are encrypted using the same cipher-keys <b>106</b> that were used for corresponding software modules <b>16</b> from the original entire set <b>176</b> (<figref idref="DRAWINGS">FIG. 7</figref>). As a result of performing this iteration of software manufacturing process <b>172</b>, an entire set <b>230</b> of updated cipher-text software modules <b>14</b> are produced.

Following process <b>172</b>, a task <b>232</b> is performed to provide entire set <b>230</b> of updated cipher-text software modules <b>14</b> to a delivered device <b>10</b>. Task <b>232</b> may be carried out by posting entire set <b>230</b> on an Internet web-site, by sending a CD ROM to the customer, or any other manner customary in the industry. Since entire set <b>230</b> is cipher-text and since it is not associated with the keys needed for decryption, security is maintained. Moreover, since updated entire set <b>230</b> is encrypted using the same cipher-keys <b>106</b> as were used with original entire set <b>186</b> (<figref idref="DRAWINGS">FIG. 7</figref>), it will be immediately usable on each device <b>10</b> in which it is installed in precisely the manner that is correct for that device <b>10</b>. Software modules <b>14</b> that were previously loaded but unlicensed, will still be unavailable to users because the keys needed for their decryption are not available within device <b>10</b>. Likewise, any changes in activated access-control models <b>60</b> (<figref idref="DRAWINGS">FIG. 3</figref>) or in externally-supplied tokens will be supported because such changes have taken place in a manner that maintained the consistent generation of those cipher-keys <b>106</b> that are successful in decrypting licensed software modules <b>14</b> in the various scenarios depicted in <figref idref="DRAWINGS">FIG. 3</figref>. Following task <b>232</b>, upgrade sub-process <b>224</b> ends.

Manufacturer license sub-process <b>226</b> is used to license a particular unlicensed software module <b>18</b> (<figref idref="DRAWINGS">FIG. 1</figref>) for use on a particular device <b>10</b>. Manufacturer license sub-process <b>226</b> includes a task <b>234</b> in which a newly licensed software module <b>16</b> is authorized. Task <b>234</b> may be carried out in response to receiving an order, collecting money, collecting identifying information, and the like.

After authorization of the newly licensed software module <b>16</b>, a task <b>236</b> is performed to get the associated artificial split-key <b>52</b> loaded in device <b>10</b> for the subject module <b>16</b>. This artificial split-key <b>52</b> is obtained from the manufacturer database, where it was saved during delivery process <b>198</b>. If the subject software module was not originally delivered with device <b>10</b>, then one of the additional artificial split-keys <b>52</b> saved in task <b>219</b> of delivery process <b>198</b> may be used instead.

Next, a task <b>237</b> generates a token-key <b>57</b> that will convert the artificial split-key <b>52</b> into a genuine split-key <b>50</b> for the subject module <b>16</b>. The conversion of task <b>237</b> may be performed by combining the artificial split-key <b>52</b> obtained above in task <b>236</b> with the cipher-key <b>106</b> used to encrypt the subject module <b>16</b>.

Following task <b>237</b>, a task <b>238</b> provides the customer with the token-key <b>57</b> generated above in task <b>237</b>. The token-key <b>57</b> may be provided in any convenient manner, and may desirably be encrypted prior to sending, then automatically decrypted by device <b>10</b> and saved therein. Manufacturer license sub-process <b>226</b> ends after task <b>238</b>.

<figref idref="DRAWINGS">FIG. 11</figref> shows a flow chart of an exemplary form of operation for a customer license process <b>240</b> which may be performed by the device <b>10</b> of <figref idref="DRAWINGS">FIG. 1</figref> in support of manufacturer license sub-process <b>226</b> (<figref idref="DRAWINGS">FIG. 10</figref>) performed by the manufacturer of device <b>10</b>. In one preferred embodiment, customer license process <b>240</b> is itself included in a software module <b>16</b> classified in administration software-restriction class <b>66</b> (<figref idref="DRAWINGS">FIG. 3</figref>). License process <b>240</b> may therefore be activated in the appropriate scenario during activate module process <b>114</b> (<figref idref="DRAWINGS">FIG. 4</figref>).

Customer license process <b>240</b> includes a task <b>244</b> in which the current user of device <b>10</b> makes an artificial cipher-key. The artificial cipher-key is made by combining the current user's token-key and corresponding artificial split-key <b>52</b> for the subject module. This cipher-key is artificial because it does not successfully decrypt the newly licensed software module <b>16</b>. However, artificial split-keys <b>52</b> were generated for this unlicensed software module <b>18</b> in connection with new users in the manner discussed above in <figref idref="DRAWINGS">FIG. 5</figref>. These artificial split-keys <b>52</b> were generated so that when combined with new users' token-keys this artificial cipher-key would result. Consequently, this artificial cipher-key is useful in synthesizing other user's token-keys even though the other users may be absent.

After task <b>244</b> a task <b>246</b> obtains the token-key <b>57</b> for the subject newly licensed software module <b>16</b>. This token-key <b>57</b> is obtained from the manufacturer during task <b>238</b> (<figref idref="DRAWINGS">FIG. 10</figref>). The existence of this token-key <b>57</b> converts the heretofore artificial split-key <b>52</b> into a genuine split-key <b>50</b> without modifying the split-key <b>48</b>. Following task <b>246</b>, a task <b>250</b> combines the now-genuine split-key <b>50</b> with the sponsoring user's newly-obtained token-key <b>57</b> for the newly licensed software module <b>16</b> to generate a genuine cipher-key <b>106</b> that will enable successful decryption of the newly licensed software module <b>16</b>. Next, a task <b>252</b> combines the artificial cipher-key generated above in task <b>244</b> with the artificial split-key <b>52</b> associated with other internal or external users of device <b>10</b>, if there be any other users. This combination function regenerates the other user's token-keys for the newly licensed software module <b>16</b>.

After task <b>252</b>, for other users a task <b>254</b> combines the other users' regenerated token-keys with the genuine cipher-key <b>106</b> generated above in task <b>250</b> to generate genuine split-keys <b>50</b> for the other users. Next, a task <b>256</b> overwrites the artificial split-keys <b>52</b> of the other users with the genuine split-keys <b>50</b> generated above in task <b>254</b>, and a task <b>258</b> destroys the genuine cipher-key <b>106</b>. Following task <b>258</b>, license process <b>240</b> ends. The newly licensed software module <b>16</b> is no longer an unlicensed module <b>18</b> and can now be successfully decrypted by various users of device <b>10</b> in the appropriate access-control scenarios.

In summary, an improved access-control method for software modules and programmable electronic device therefor are provided by the present invention. A flexible access-control system is provided which permits the device with which it is used to be operated over a range of security controls, from a permissive system that does not require tokens to a highly restrictive system wherein only certain user tokens are granted access to certain software modules. In addition, an access-control system is provided in which an entire set of software modules may be delivered to a customer, even though that customer is licensed to use only a subset of the entire set of software modules. The access-control system provides a manufacturer with assurance that software modules and permissions provided for one device are not usable on another device. Moreover, the access-control system enables the management of different versions of different software modules and the upgrading thereof in a manner that is user-friendly both for manufacturer and for the customers.

Although the preferred embodiments of the invention have been illustrated and described in detail, it will be readily apparent to those skilled in the art that various modifications and additions may be made therein without departing from the spirit of the invention or from the scope of the appended claims. For example, the access-control system described herein supports and enables numerous equivalent provisioning and licensing alternatives besides those described herein. In one such alternative, temporary licenses may be provided wherein genuine split-keys associated with certain software modules are destroyed at a certain future date. These and other alternatives and equivalents are intended to be included within the scope of the present invention.