70243-00075
`
`SYSTEM AND METHOD FOR DEVICE AUTHENTICATION
`
`WITH BUILT-IN TOLERANCE
`
`Field of the Invention
`
`
`Background of the Invention
`
`The present invention is directed toward a method and system for building tolerance
`
`into comparisons of device fingerprints when authenticating a device.
`
`10
`
`
`Description of the Related Art
`
`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
`
`15
`
`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
`
`20
`
`authentication is rejected or denied.
`
`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.
`
`25
`
`30
`
`2843871
`
`Page 1 of40
`
`-1-
`
`M1014
`
`IA1014
`
`Page 1 of 40
`
`

`

`70243-00075
`
`
`Summary of the Invention
`
`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.
`
`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.
`
`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.
`
`10
`
`15
`
`20
`
`25
`
`2843871
`
`Page 2 of40
`
`-2-
`
`M1014
`
`IA1014
`
`Page 2 of 40
`
`

`

`70243-00075
`
`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.
`
`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.
`
`In one embodiment, the authentication process may fiarther 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
`
`10
`
`15
`
`20
`
`25
`
`being caused by an entirely different device.
`
`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 the component with which the fingerprint portion was
`
`generated base on. During the comparison of a received digital fingerprint from the
`
`30
`
`device with stored digital fingerprints of known devices, the authentication server may flag
`
`2843871
`
`Page 3 of40
`
`-3-
`
`M1014
`
`IA1014
`
`Page 3 of 40
`
`

`

`70243-00075
`
`each portion that it failed to find a match. When the comparison process is completed, the
`
`device may be validly authenticated if there are matching portions for at least 75% of the
`
`logical portions of the received fingerprint. It should be noted that other percentage could
`
`be implemented.
`
`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-upgrade/non-typical-upgrade ratio.
`
`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.
`
`10
`
`15
`
`20
`
`25
`
`2843871
`
`Page 4 of40
`
`-4-
`
`m1014
`
`IA1014
`
`Page 4 of 40
`
`

`

`70243-00075
`
`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 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-upgrade/non-typical-upgrade ratio.
`
`To the accomplishment of the foregoing and related ends, the one or more
`
`10
`
`embodiments comprise the features hereinafter fially 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
`
`15
`
`and their equivalents.
`
`
`Brief Description of the Drawings
`
`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.
`
`Figure
`
`1
`
`illustrates an exemplary environment with which a method for
`
`authenticating remote devices may be implemented according to one embodiment of the
`
`20
`
`25
`
`present invention.
`
`Figure 2 illustrates the components of an exemplary device identifier.
`
`Figures 3A-B, and 4 illustrate exemplary operational flow diagrams of methods for
`
`authenticating a device according to embodiments of the present invention.
`
`2843871
`
`Page 5 of40
`
`-5-
`
`LAIOI4
`
`IA1014
`
`Page 5 of 40
`
`

`

`70243-00075
`
`Figures 5-6 illustrate
`
`exemplary computing systems with which software
`
`components can be executed to perform the method for authenticating a device according
`
`to one or more embodiments of the present invention.
`
`Detailed Description
`
`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.
`
`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.
`
`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 filture
`
`authentication processes.
`
`10
`
`15
`
`20
`
`25
`
`2843871
`
`Page 6 of40
`
`-6-
`
`LAIOI4
`
`IA1014
`
`Page 6 of 40
`
`

`

`70243-00075
`
`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,
`
`10
`
`PCI Bus, System CMOS Clock, etc.
`
`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.
`
`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.
`
`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
`
`15
`
`20
`
`25
`
`30
`
`2843871
`
`Page 7 of40
`
`-7-
`
`M1014
`
`IA1014
`
`Page 7 of 40
`
`

`

`70243-00075
`
`more fingerprints of one or more components of a device. The request code may be
`
`configured to 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.
`
`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 fianction such as a one-way hash or a two-way hash fianction
`
`using the information gathered in response to the request code.
`
`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.
`
`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
`
`usemame 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 usemame and password is bypassed. When the device is registering for the first time,
`
`the user may be required to enter the usemame and password.
`
`10
`
`15
`
`20
`
`25
`
`2843871
`
`Page 8 of40
`
`-8-
`
`LAIOI4
`
`IA1014
`
`Page 8 of 40
`
`

`

`70243-00075
`
`Before describing the invention in fiarther detail, it is useful to describe an example
`
`environment with which the invention can be implemented.
`
`Figure 1
`
`is a diagram
`
`illustrating an example environment 100 with which the online commerce restriction,
`
`system, and apparatus is 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.
`
`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.
`
`Referring again to Figure 1, computing devices 110a-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.
`
`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
`
`10
`
`15
`
`20
`
`25
`
`30
`
`2843871
`
`Page 9 of40
`
`-9-
`
`LAIOI4
`
`IA1014
`
`Page 9 of 40
`
`

`

`70243-00075
`
`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 associated with the
`
`firmware in use.
`
`The system information may filrther include system configuration
`
`information, such as amount of memory, type of processor, software or operating system
`
`serial number, etc.
`
`Based on the collected information, the security client may generate a response
`
`code based on one or more identifiers or fingerprints 224 (see Figure 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.
`
`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.
`
`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,
`
`10
`
`15
`
`20
`
`25
`
`30
`
`2843871
`
`Page 10 of40
`
`-lO-
`
`LAIOI4
`
`IA1014
`
`Page 10 of 40
`
`

`

`70243-00075
`
`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 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.
`
`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 fimction, 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.
`
`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.
`
`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.
`
`10
`
`15
`
`20
`
`25
`
`2843871
`
`Page 11 of40
`
`-l l-
`
`LAIOI4
`
`IA1014
`
`Page 11 of 40
`
`

`

`70243-00075
`
`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 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.
`
`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.
`
`Device parameter sampling, damage measurement and chip benchmarking make up
`
`just a part of device fingerprinting technologies described herein. These tools may be
`
`fiarther 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.
`
`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
`
`10
`
`15
`
`20
`
`25
`
`machine service tag.
`
`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.
`
`2843871
`
`Page 12 of40
`
`-12-
`
`LAIOI4
`
`IA1014
`
`Page 12 of 40
`
`

`

`70243-00075
`
`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.
`
`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.
`
`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.
`
`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.
`
`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.
`
`The device identifier may also be generated by utilizing machine parameters
`
`associated with one or more of the following: chassis manufacturer; chassis type; chassis
`
`10
`
`15
`
`20
`
`version; and chassis serial number.
`
`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.
`
`The device identifier may also be generated by utilizing machine parameters
`
`25
`
`associated with one or more of the following: port connector designator; port connector
`
`type; port connector port type; and system slot type.
`
`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.
`
`2843871
`
`Page 13 of40
`
`-l3-
`
`LAIOI4
`
`IA1014
`
`Page 13 of 40
`
`

`

`70243-00075
`
`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.
`
`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.
`
`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.
`
`With reference to Figure 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 other parameters which are variable may be utilized
`
`in other embodiments. The system key portion 228 may include the above described
`
`parameters expected to be unique to the device 110, such as, for example, hard disk
`
`volume name, user name, computer name, user password, hard disk initialization date, or
`
`combinations thereof Portions 226 and/or 228 may be combined with the IP address
`
`and/or other platform parameters of the device 110.
`
`It is noted that device identifiers,