`
`WITH BUILT-IN TOLERANCE
`
`[0001] This application claims priority to U.S. Provisional Application No. 61/252,960 which
`
`was filed October 19, 2009 and which is fully incorporated herein by reference.
`
`1.
`
`Field of the Invention
`
`BACKGROUND
`
`[0002] The present invention is directed toward a method and system for building tolerance
`
`into comparisons of device fingerprints when authenticating a device.
`
`2.
`
`Description of the Related Art
`
`[0003] Controlling access to a secured network is one of the biggest challenges for critical
`
`infrastructure. Since the majority of existing infrastructures use computers to connect to the
`
`Ethernet or
`
`Internet,
`
`there is an increased possibility for
`
`security breaches
`
`into such
`
`infrastructures. One way to reduce security breaches is to strictly enforce authentication methods
`
`such as comparison of password, personal information, secret question, machine identifier, etc.
`
`against various stored data and password information. However, in certain approaches, if there
`
`is even a slight or minor difference between a device identifier or fingerprint for a device that
`
`seeks to be authenticated versus a database of known fingerprints corresponding to known
`
`authorized devices, then the request for authentication is rejected or denied.
`
`[0004]
`
`From a practical standpoint, it is quite possible for a user of given known device (e. g., a
`
`device that is known and authorized to access a secured network),
`
`to upgrade, replace, or
`
`otherwise modify one or more components of the device. If the device fingerprint may be based
`
`on or generated from various device components, including upgraded or modified components, it
`
`is quite possible that the known device may no longer have a fingerprint or identifier that will be
`
`recognized by the authentication system.
`
`For example,, a valid device and machine may
`
`inadvertently be denied an authenticated status because of upgrade(s) to typical components such
`
`as memory, video card, etc. Accordingly, it would be desirable to provide an authentication
`
`method with built in flexibility or tolerance to allow for some upgrades or changes to the device.
`
`Page 1 of37
`
`M1015
`
`IA1015
`
`Page 1 of 37
`
`
`
`SUMMARY
`
`[0005]
`
`The following presents a simplified summary of one or more embodiments in order to
`
`provide a basic understanding of such embodiments. This summary is not an extensive overview
`
`of all contemplated embodiments, and is intended to neither identify key or critical elements of
`
`all embodiments nor delineate the scope of any or all embodiments. Its sole purpose is to present
`
`some concepts of one or more embodiments in a simplified form as a prelude to the more
`
`detailed description that is presented later.
`
`[0006]
`
`In accordance with one or more embodiments and corresponding disclosure thereof,
`
`various aspects are described in connection with a method for allowing tolerance in the
`
`authentication process of a digital fingering of a device. By building in tolerance into the
`
`authentication process, the risk of rejecting a valid device is reduced. Some tolerance is needed
`
`because users may upgrade their hardware and/or software, thus changing the environment of
`
`their devices. Once the environment is changed, the authentication software/client one the
`
`device may generate a different digital fingerprint. Thus, without built in tolerance, a valid
`
`device may be rejected once an upgrade is made to the device.
`
`[0007]
`
`In accordance with one or more embodiments and corresponding disclosure thereof,
`
`various aspects are described in connection with a method for building tolerance into
`
`authentication of a device, the method comprising: receiving and storing first digital fingerprint
`
`of the device during a first boot of an authenticating software on the device, the first digital
`
`fingerprint being based on a first set of device components; receiving a second digital fingerprint
`
`from the device at a subsequent time; comparing the second digital fingerprint with a plurality of
`
`stored digital fingerprints of known devices;
`
`in response to the comparison indicating a
`
`mismatch between the second digital fingerprint and the plurality of stored digital fingerprints,
`
`generating a request code comprising instructions for the device to generate a third digital
`
`fingerprint using the first set of device components; sending the request code to the remote
`
`device; receiving the third digital fingerprint from the remote device in response to the request
`
`code; and authenticating the device based on a comparison of the first and third digital
`
`fingerprints.
`
`Page 2 of37
`
`M1015
`
`IA1015
`
`Page 2 of 37
`
`
`
`[0008]
`
`In the foregoing method, the first digital fingerprint may be generated using specific
`
`components, such as a typical—upgrade list and a non—typical—upgrade list. The typical—upgrade
`
`list may comprise one or more components such as graphic card, random access memory, sound
`
`card, network adaptor, hard drive, CD/DVD drive, and Ethernet controller. The non—typical—
`
`upgrade list may comprise one or more components such as motherboard, USB host controller,
`
`central microprocessor, PCI Bus, and System CMOS Clock.
`
`[0009]
`
`The foregoing method may also include the process of receiving component list of the
`
`device at the first boot of the authenticating software on the device. This list of components may
`
`be used to generate the request code, which may exclusively comprise components from the list.
`
`In this way, a control digital fingerprint may be generated to be compared with the first digital
`
`fingerprint.
`
`[0010]
`
`In one embodiment,
`
`the authentication process may further include: generating a
`
`control metric by comparing differences between the first and second digital fingerprints. The
`
`control metric may identify fingerprint portions and their respective components of the device
`
`that generated the differences between the first and second digital fingerprints. The control
`
`metric may help identify components missing and/or was upgraded in the device. A second
`
`metric may also be generated by comparing differences between the first and third digital
`
`fingerprints. Each metric may comprise data identifying a fingerprint portion and associated
`
`component that caused the difference. The device may be validly authenticated when the
`
`associated component of the control metric and the associated component of the second metric
`
`are identical. This means the difference found in the comparison may be caused by a single
`
`component. When this is the case, there is a high probability that the changed in the digital
`
`fingerprint is caused by an upgrade rather than being caused by an entirely different device.
`
`[0011]
`
`In the foregoing method,
`
`in one embodiment,
`
`the authentication server may be
`
`configured to parse out the digital fingerprint into a plurality of logical portions. Each logical
`
`portion may represent a component corresponding to a fingerprint portion.
`
`During the
`
`comparison of a received digital fingerprint from the device with stored digital fingerprints of
`
`known devices, the authentication server may flag each portion for which it failed to find a
`
`match. When the comparison process is completed, the device may be validly authenticated if
`
`Page 3 of37
`
`M1015
`
`IA1015
`
`Page 3 of 37
`
`
`
`there are matching portions for at least 75% of the logical portions of the received fingerprint.
`
`It
`
`should be noted that other percentages could be implemented.
`
`[0012]
`
`In accordance with yet another embodiment of the present
`
`invention a computer
`
`readable medium is provided. The computer readable medium having stored thereon, computer
`
`executable instructions that, if executed by a device, cause the device to perform a method
`
`comprising: receiving a first digital fingerprint from a device having a plurality of digital
`
`fingerprint portions, each fingerprint portion being associated with a component of the device;
`
`authenticating the received digital fingerprint against stored digital fingerprints; flagging each
`
`digital fingerprint portion creating an error during authentication; categorizing associated
`
`component of each fingerprint portion as a typical—upgrade component or a non—typical—upgrade
`
`component; and granting the digital fingerprint a valid authenticated status when the flagged
`
`fingerprint portions have a predetermined typical—up grade/non—typical—up grade ratio.
`
`[0013]
`
`In accordance with yet another embodiment of the present invention, a computer
`
`readable medium is provided.
`
`The computer readable medium may have stored thereon,
`
`computer executable instructions that, when executed by a device, cause the device to perform a
`
`method comprising:
`
`receiving and storing first digital fingerprint of the device during a first
`
`boot of an authenticating software on the device, the first digital fingerprint being based on a first
`
`set of device components; receiving a second digital fingerprint from the device at a subsequent
`
`time; comparing the second digital fingerprint with a plurality of stored digital fingerprints of
`
`known devices; in response to the comparison indicating a mismatch between the second digital
`
`fingerprint and the plurality of stored digital fingerprints, generating a request code comprising
`
`instructions for the device to generate a third digital fingerprint using the first set of device
`
`components; sending the request code to the remote device; receiving the third digital fingerprint
`
`from the remote device in response to the request code; and authenticating the device based on a
`
`comparison of the first and third digital fingerprints.
`
`[0014]
`
`In accordance with one or more embodiments and corresponding disclosure thereof,
`
`various aspects are described in connection with a method for authenticating a device,
`
`the
`
`method comprising: comparing the received digital fingerprint with stored digital fingerprints of
`
`known devices;
`
`flagging each digital
`
`fingerprint portion that creates
`
`an error during
`
`Page 4 of37
`
`M1015
`
`IA1015
`
`Page 4 of 37
`
`
`
`authentication; categorizing associated component of each fingerprint portion as a typical—
`
`upgrade component or a non—typical—upgrade component; and granting the digital fingerprint a
`
`valid authenticated status when the flagged fingerprint portions exceed a predetermined typical—
`
`up grade/non—typical—up grade ratio.
`
`[0015]
`
`To the accomplishment of
`
`the foregoing and related ends,
`
`the one or more
`
`embodiments comprise the features hereinafter fully described and particularly pointed out in the
`
`claims. The following description and the annexed drawings set forth in detail certain illustrative
`
`aspects of the one or more embodiments. These aspects are indicative, however, of but a few of
`
`the various ways in which the principles of various embodiments may be employed and the
`
`described embodiments are intended to include all such aspects and their equivalents.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0016] The present
`
`invention,
`
`in accordance with one or more various embodiments,
`
`is
`
`described in detail with reference to the following figures. The drawings are provided for
`
`purposes of illustration only and merely depict typical or example embodiments of the invention.
`
`These drawings are provided to facilitate the reader’s understanding of the invention and shall
`
`not be considered limiting of the breadth, scope, or applicability of the invention.
`
`[0017]
`
`FIG. 1 is a block diagram illustrating an exemplary environment within which a method
`
`for authenticating remote devices may be implemented according to one embodiment of the
`
`present invention.
`
`[0018]
`
`FIG. 2 is a block diagram representing memory allocation for a device identifier used in
`
`accordance with principles of the present invention.
`
`[0019]
`
`FIG. 3A is a process flow chart illustrating one embodiment of a method according to
`
`the invention for device authentication with built—in tolerance.
`
`[0020]
`
`FIG. 3B is a continuation of the process flow diagram of FIG. 3A.
`
`[0021]
`
`FIG. 4 is a process flow chart illustrating another embodiment of a method according to
`
`the invention for device authentication with built—in tolerance.
`
`Page 5 of37
`
`M1015
`
`IA1015
`
`Page 5 of 37
`
`
`
`[0022]
`
`FIG. 5 is a block diagram illustrating a system within which software components can
`
`be executed to perform a method for authenticating a device according to one or more
`
`embodiments of the present invention.
`
`[0023]
`
`FIG. 6 is a block diagram illustrating another system within which software
`
`components can be executed to perform a method for authenticating a device according to one or
`
`more embodiments of the present invention.
`
`DETAILED DESCRIPTION
`
`[0024] Users frequently upgrade their devices with new software and hardware components to
`
`keep their devices up to date with current technology. But in upgrading their devices, users may
`
`inadvertently make their devices invalid to a digital fingerprint authentication process. During
`
`an authentication process, according to one embodiment of the present invention, a digital
`
`fingerprint is generated using information from the environment of the device. The information
`
`used to generate the digital fingerprint may include information regarding hardware and software
`
`components, hardware configurations or statuses, and software version, etc.
`
`[0025]
`
`By building in tolerance into the authentication process, the risk of rejecting a valid
`
`device is reduced. Some tolerance is needed because users may upgrade their hardware and/or
`
`software, thus changing the environment of their devices. Once the environment is changed, the
`
`authentication client may generate a different digital fingerprint. Thus, without tolerance a valid
`
`device may be rejected once an upgrade is made to the device.
`
`[0026] According to embodiments of the present invention, a method for authenticating a
`
`device is described below. The method described below can also be implemented in a system or
`
`a computer apparatus. To authenticate a device, the user may install a standalone authentication
`
`client or module on the device. The authentication client may also be an applet application or a
`
`software plug—in of another software application, such as, for example, a web browser. On the
`
`first install or run of the authentication client, a digital fingerprint (“first boot fingerprint”) is
`
`generated using information collected on the device’s hardware and software environment. The
`
`first boot fingerprint may then be stored for later comparison with newly received digital
`
`fingerprints during future authentication processes.
`
`Page 6 of37
`
`M1015
`
`IA1015
`
`Page 6 of 37
`
`
`
`[0027] The first boot fingerprint may be generated using the overall environmental information
`
`collected by the authentication module. Alternatively, the first boot fingerprint may be generated
`
`using specific components of the device as predetermined by the authentication client. The
`
`specific components may include components from a typical—upgrade components list or a non—
`
`typical—upgrade components list. The typical—upgrade components list may include components
`
`such as: graphic card, random access memory, sound card, network adaptor, hard drive,
`
`CD/DVD drive, Ethernet controller, or other routinely upgraded components. The non—typical—
`
`upgrade components list may include components such as: motherboard, USB host controller,
`
`central microprocessor, PCI Bus, System CMOS Clock, etc.
`
`[0028]
`
`In one embodiment, at the first boot of the authentication client, two different digital
`
`fingerprints are generated. One of the fingerprints may be generated using only components
`
`information from the non—typical—upgrade list, while the other digital fingerprint may be
`
`generated using standard technique. This may involve using the information of components
`
`from both typical and non—typical upgrade lists or environmental information of the device as a
`
`whole to generate the fingerprint instead of using specific components. Once the authentication
`
`client generates the digital fingerprints, they may be sent to an authentication server to register
`
`the device, if this is the first run of the authentication client.
`
`In one embodiment, when the
`
`authentication client is not at the first run, only one fingerprint is generated and sent to the
`
`authentication server for verification.
`
`[0029] Where the device is registering with the authenticating server for the first time, the
`
`received digital
`
`fingerprints are stored.
`
`In a subsequent communication and when the
`
`authentication server receives another fingerprint, the later received fingerprint is compared to
`
`the stored fingerprint.
`
`If a match is found between the latest received fingerprint and one of the
`
`stored fingerprints, the device may be validly authenticated. The authentication process may
`
`also request the user to enter a usemame and a password in addition to the verification of the
`
`response code.
`
`[0030] According to another embodiment of the present invention, the authenticating server
`
`may generate a request code,
`
`to be transmitted to the device, representing one or more
`
`fingerprints of one or more components of a device. The request code may be configured to
`
`Page 7 of37
`
`M1015
`
`IA1015
`
`Page 7 of 37
`
`
`
`represent one or more portions of fingerprints of components located in the device. The request
`
`code may be transmitted to the device using wireless communication standard such as WiMAX,
`
`WiFi, HomeRF, CDMA, or other wireless communication protocol.
`
`[0031] The request code may be configured such that when it is read by the device, a response
`
`code is generated by the device. The response code comprises one or more portions of the
`
`requested fingerprints of components inside the device. For example, the request code may
`
`request the following: the first five digits of the serial number of the device; the version of the
`
`operating system; and/or the last four digits of the serial number of a microprocessor.
`
`In
`
`receiving the above request code, the device may collect the requested portions of fingerprints
`
`and generate a response code. The response code may be generated using a hash function such
`
`as a one—way hash or a two—way hash function using the information gathered in response to the
`
`request code.
`
`[0032]
`
`The response code may be transmitted to an authenticating server via email or
`
`short messaging system (SMS). Where SMS is used,
`
`the device may be configured to
`
`automatically transmit
`
`the response code to the authenticating server after receiving and
`
`processing the request code. The device may also request a confirmation from the user prior to
`
`sending the response code to the authenticating server.
`
`[0033]
`
`Once the response code is received at the authenticating server, the authenticating
`
`server may compare each of the one or more portions of fingerprints with predetermined code(s)
`
`or previously stored code(s). Where the device is registering with the authenticating server for
`
`the first time, the response code may be translated and stored.
`
`If a match is found between the
`
`response code and one of the stored codes,
`
`the device may be validly authenticated. The
`
`authenticating process may also request the user to enter a username and a password in addition
`
`to the verification of the response code. Alternatively, the verification of the response code
`
`alone is sufficient and verification of the username and password is bypassed. When the device
`
`is registering for the first time, the user may be required to enter the username and password.
`
`[0034] Before describing the invention in further detail, it is useful to describe an example
`
`environment with which the invention can be implemented. FIG. 1 is a diagram illustrating an
`
`example environment 100 with which the online commerce restriction, system, and apparatus is
`
`Page 8 of37
`
`MIOIS
`
`IA1015
`
`Page 8 of 37
`
`
`
`implemented according to one or more embodiments of the present invention. The illustrated
`
`example environment 100 includes devices 110a and 110b, a network 115, a server 120, and a
`
`software/hardware module 130. Devices 110 may include a security client
`
`(not shown)
`
`configured to authenticate the device to an authenticating server as generally described above.
`
`The security client may comprise a stand—alone application or an applet running within a web
`
`browser on the device 110 (e.g., an applet comprising executable code for a Java Virtual
`
`Machine).
`
`The security client may be embedded in or associated with another software
`
`application, including but not limited to a web browser. For example, the security client may be
`
`embedded in or associated with a tool bar of a software application, such as, for example, a web
`
`browser. The security client may prompt the user to register with an online software registration
`
`service, or may run in the background with little or no interaction with the user of device 110.
`
`[0035] The security client may also be digitally distributed or streamed from one or more
`
`servers. Network 115 may comprise the Internet, a local area network, or other form of
`
`communication network.
`
`[0036] Referring again to FIG.
`
`1, computing devices
`
`llOa—b may be in operative
`
`communication with authenticating server 120. While only one computing device 110 is
`
`illustrated, it will be understood that a given system may comprise any number of computing
`
`devices. Computing device 110 may be, but is not limited to, a mobile phone, netbook, a mobile
`
`game console, mobile computing device, a tablet computer, a personal digital assistant, a
`
`wireless communication device, an onboard vehicle computer, or any other device capable of
`
`communication with a computer network.
`
`[0037]
`
`Per the request code received from the authenticating server or manually entered by the
`
`user of the device, the security client may collect information regarding computing device 110,
`
`as instructed by the request code. The request code may comprises information or instruction
`
`telling the security client to collect a number of parameters which are expected to be unique to
`
`the computing device environment. The parameters collected may include, for example, hard
`
`disk volume name, user name, device name, user password, hard disk initialization date, etc.
`
`The collected information may include information that identifies the hardware comprising the
`
`platform on which the web browser runs, such as, for example, CPU number, or other parameters
`
`Page 9 of37
`
`MIOIS
`
`IA1015
`
`Page 9 of 37
`
`
`
`associated with the firmware in use. The system information may further include system
`
`configuration information, such as amount of memory, type of processor, software or operating
`
`system serial number, etc.
`
`[0038] Based on the collected information, the security client may generate a response code
`
`based on one or more identifiers or fingerprints 224 (see FIG. 2) that
`
`is unique to each
`
`component of computing device 110. The term device identifier, as used herein, refers to one or
`
`more fingerprints of hardware and software components inside of device 110. The request code
`
`may include a code that represents the device identifier, which is a fingerprint of a component of
`
`device 110. As mentioned above, the request code may specify one or more portions of a
`
`fingerprint (device identifier) of a component of device 110. Alternatively, the request code may
`
`specify one or more fingerprints in whole.
`
`[0039] The device identifier 224 may be generated and stored in a hidden directory of the
`
`device 110 and/or at a remote location, such as the server 120. The device identifier 224 may
`
`incorporate the device’s IP address and/or other geo—location code to add another layer of
`
`specificity to device’s unique identifier.
`
`[0040]
`
`It is noted that the security client running on the computing device or otherwise having
`
`access to the computing device’s hardware and file system may generate a unique device
`
`identifier (e.g., device identifier 224) using a process that operates on data indicative of the
`
`computing device’s configuration and hardware. The device identifier may be generated using a
`
`combination of user—configurable and non—user—configurable machine parameters as input to a
`
`process that results in the device identifier, which may be expressed in digital data as a binary
`
`number. Each machine parameter is data determined by a hardware component, software
`
`component, or data component specific to the device that the unique identifier pertains to.
`
`Machine parameters may be selected based on the target device system configuration such that
`
`the resulting device identifier has a very high probability (e. g., greater than 99.999%) of being
`
`unique to the target device.
`
`In addition, the machine parameters may be selected such that the
`
`device identifier includes at least a stable unique portion up to and including the entire identifier,
`
`that has a very high probability of remaining unchanged during normal operation of the target
`
`device. Thus, the resulting device identifier should be highly specific, unique, reproducible and
`
`Page 10 of37
`
`MIOIS
`
`10
`
`IA1015
`
`Page 10 of 37
`
`
`
`stable as a result of properly selecting the machine parameters. Once the device identifier is
`
`generated, a response code is produced using specific portions of the device identifier as
`
`requested by the request code.
`
`[0041] The application for generating the device identifier may also operate on the collected
`
`parameters with one or more algorithms to generate the device identifier. This process may
`
`include at least one irreversible transformation, such as, for example, a cryptographic hash
`
`function, such that the input machine parameters cannot be derived from the resulting device
`
`identifier. Each device identifier, to a very high degree of certainty, cannot be generated except
`
`by the suitably configured application operating or otherwise having had access to the same
`
`computing device for which the device identifier was first generated. Conversely, each
`
`identifier, again to a very high degree of certainty, can be successfully reproduced by the suitably
`
`configured application operating or otherwise having access to the same computing device on
`
`which the identifier was first generated.
`
`[0042]
`
`The application may operate by performing a system scan to determine a present
`
`configuration of the computing device. The application may then select the machine parameters
`
`to be used as input for generating the unique device identifier. Selection of parameters may vary
`
`depending on the system configuration. Once the parameters are selected, the application may
`
`generate the identifier.
`
`[0043]
`
`Further, generating the device identifier may also be described as generating a device
`
`fingerprint and may entail the sampling of physical, non—user configurable properties as well as a
`
`variety of additional parameters such as uniquely generated hashes and time sensitive values.
`
`Physical device parameters
`
`available for
`
`sampling may include,
`
`for example, unique
`
`manufacturer characteristics, carbon and silicone degradation and small device failures.
`
`[0044]
`
`The process of measuring carbon and silicone degradation may be accomplished by
`
`measuring a chip's ability to process complex mathematical computations, and its ability to
`
`respond to intensive time variable computations. These processes measure how fast electricity
`
`travels through the carbon. Using variable offsets to compensate for factors such as heat and
`
`additional stresses placed on a chip during the sampling process allows for each and every
`
`benchmark to reproduce the expected values. During a standard operating lifetime, the process
`
`Page 11 of37
`
`MIOIS
`
`11
`
`IA1015
`
`Page 11 of 37
`
`
`
`of passing electricity through the various switches causes a computer chip to degrade. These
`
`degradations manifest as gradually slower speeds that extend the processing time required to
`
`compute various benchmarking algorithms.
`
`[0045]
`
`In addition to the chip benchmarking and degradation measurements, the process for
`
`generating a device
`
`identifier may include measuring physical,
`
`non—user—configurable
`
`characteristics of disk drives and solid state memory devices. Each data storage device has a
`
`large variety of damage and unusable data sectors that are nearly unique to each physical unit.
`
`The ability to measure and compare values for damaged sectors and data storage failures
`
`provides a method for identifying storage devices.
`
`[0046] Device parameter sampling, damage measurement and chip benchmarking make up just
`
`a part of device fingerprinting technologies described herein. These tools may be further
`
`extended by the use of complex encryption algorithms to convolute the device identifier values
`
`during transmission and comparisons. Such encryption processes may be used in conjunction
`
`with random sampling and key generations.
`
`[0047] The device identifier may be generated by utilizing machine parameters associated with
`
`one or more of the following: machine model; machine serial number; machine copyright;
`
`machine ROM version; machine bus speed; machine details; machine manufacturer; machine
`
`ROM release date; machine ROM size; machine UUID; and machine service tag.
`
`[0048] The device identifier may also be generated by utilizing machine parameters associated
`
`with one or more of the following: CPU ID; CPU model; CPU details; CPU actual speed; CPU
`
`family; CPU manufacturer; CPU voltage; and CPU external clock.
`
`[0049] The device identifier may also be generated by utilizing machine parameters associated
`
`with one or more of the following: memory model; memory slots; memory total; and memory
`
`details.
`
`[0050] The device identifier may also be generated by utilizing machine parameters associated
`
`with one or more of the following: video model; video details; display model; display details;
`
`audio model; and audio details.
`
`Page 12 of37
`
`MIOIS
`
`12
`
`IA1015
`
`Page 12 of 37
`
`
`
`[005 l] The device identifier may also be generated by utilizing machine parameters associated
`
`with one or more of the following: network model; network address; Bluetooth address;
`
`Blackbox model; Blackbox serial; Blackbox details; Blackbox damage map; Blackbox volume
`
`name; NetStore details; and NetStore volume name.
`
`[0052]
`
`The device identifier may also be generated by utilizing machine parameters associated
`
`with one or more of the following: optical model; optical serial; optical details; keyboard model;
`
`keyboard details; mouse model; mouse details; printer details; and scanner details.
`
`[0053]
`
`The device identifier may also be generated by utilizing machine parameters associated
`
`with one or more of the following: baseboard manufacturer; baseboard product name; baseboard
`
`version; baseboard serial number; and baseboard asset tag.
`
`[0054]
`
`The device identifier may also be generated by utilizing machine parameters associated
`
`with one or more of the following: chassis manufacturer; chassis type; chassis version; and
`
`chassis serial number.
`
`[0055]
`
`The device identifier may also be generated by utilizing machine parameters associated
`
`with one or more of the following: IDE controller; SATA controller; RAID controller; and SCSI
`
`controller.
`
`[0056]
`
`The device identifier may also be generated by utilizing machine parameters associated
`
`with one or more of the following: port connector designator; port connector type; port connector
`
`port type; and system slot type.
`
`[0057]
`
`The device identifier may also be generated by utilizing machine parameters associated
`
`with one or more of the following: cache level; cache size; cache maX size; cache SRAM type;
`
`and cache error correction type.
`
`[005 8]
`
`The device identifier may also be generated by utilizing machine parameters associated
`
`with one or more of the following: fan; PCMCIA; modem; portable battery; tape drive; USB
`
`controller; and USB hub.
`
`Page 13 of37
`
`MIOIS
`
`13
`
`IA1015
`
`Page 13 of 37
`
`
`
`[0059] The device identifier may also be generated by utilizing machine parameters associated
`
`with one or more of the following: device model; device model IMEI; device model IMSI; and
`
`device model LCD.
`
`[0060]
`
`The device identifier may also be generated by utilizing machine parameters associated
`
`with one or more of the following: wireless 802.11; webcam; game controller; silicone serial;
`
`and PCI controller.
`
`[0061] With reference to FIG. 2, in one embodiment, the device identifier 224 may include two
`
`components — namely, a variable key portion 226 and a system key portion 228. The variable
`
`key portion 226 may be generated at the time of registration of computing device 110 by
`
`reference to a variable platform parameter, such as via reference to system time information,
`
`although