`
`SYSTEM AND METHOD FOR DEVICE AUTHENTICATION
`WITH BUILT-IN TOLERANCE
`
`Background of the Invention
`
`[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.
`
`
`
`1
`
`IA1026
`
`Page 1 of 24
`
`

`

`
`
`Summary of the Invention
`
`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.
`
`
`
`2
`
`IA1026
`
`Page 2 of 24
`
`

`

`
`
`[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
`
`thea component with which thecorresponding to a fingerprint portion was generated base on. 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 thatfor which 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 percentagepercentages could be implemented.
`
`
`
`3
`
`IA1026
`
`Page 3 of 24
`
`

`

`
`
`[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-
`
`upgrade/non-typical-upgrade 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 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.
`
`
`
`4
`
`IA1026
`
`Page 4 of 24
`
`

`

`
`
`[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
`
`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.
`
`Figure 1 illustrates[0017] FIG. 1 is a block diagram illustrating an exemplary environment
`
`withwithin which a method for authenticating remote devices may be implemented according to one
`
`embodiment of the present invention.
`
`Figure 2 illustrates the components of an exemplary[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.
`
`Figures 3A-B, and 4 illustrate exemplary operational flow diagrams of methods[0022] FIG. 5 is a
`
`
`
`5
`
`IA1026
`
`Page 5 of 24
`
`

`

`
`
`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.
`
`Figures 5-6 illustrate exemplary computing systems with[0023] FIG. 6 is a block diagram illustrating
`
`another system within which software components can be executed to perform thea method for
`
`authenticating a device according to one or more embodiments of the present invention.
`
`Detailed Description
`
`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.
`
`
`
`6
`
`IA1026
`
`Page 6 of 24
`
`

`

`
`
`70243-00075
`
`[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-
`
`typicalnontypical-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
`
`username 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 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
`
`
`
`7
`
`IA1026
`
`Page 7 of 24
`
`

`

`
`
`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. FigureFIG. 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
`
`
`
`8
`
`IA1026
`
`Page 8 of 24
`
`

`

`
`
`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 FigureFIG. 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.
`
`[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 associated with the firmware
`
`in use. The system information may further include system configuration information, such as
`
`
`
`9
`
`IA1026
`
`Page 9 of 24
`
`

`

`
`
`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 FigureFIG. 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 stable as a result of properly selecting the machine
`
`parameters. Once the device identifier is generated, a response code is produced using specific
`
`
`
`10
`
`IA1026
`
`Page 10 of 24
`
`

`

`
`
`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 of passing electricity through the
`
`various switches causes a computer chip to degrade. These degradations manifest as gradually slower
`
`
`
`11
`
`IA1026
`
`Page 11 of 24
`
`

`

`
`
`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.
`
`[0051] 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.
`
`
`
`12
`
`IA1026
`
`Page 12 of 24
`
`

`

`
`
`[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.
`
`[0058] 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.
`
`[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 associat