(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2011/0093920 A1
`Etchegoyen
`(43) Pub. Date:
`Apr. 21, 2011
`
`US 2011 0093.920A1
`
`(54) SYSTEMAND METHOD FOR DEVICE
`AUTHENTICATION WITH BUILT-IN
`TOLERANCE
`
`(76) Inventor:
`
`Craig S. Etchegoyen, Irvine, CA
`(US)
`s
`s
`
`(21) Appl. No.:
`
`12/903,948
`
`(22) Filed:
`
`Oct. 13, 2010
`
`O
`O
`Related U.S. Application Data
`(60) Provisional application No. 61/252,960, filed on Oct.
`19, 2009.
`
`Publication Classification
`
`(51)
`
`Int. C.
`G06F 7/04
`
`(2006.01)
`
`(52) U.S. Cl. ............................................................ 726/3
`(57)
`ABSTRACT
`
`A system for building tolerance into authentication of a com
`puting device includes a means for executing, from a com
`puter-readable medium, computer-implementable steps of
`(a) receiving and storing a first digitalfingerprint of the device
`during a first boot of an authenticating Software on the device,
`the first digital fingerprint based on a first set of device com
`ponents, (b) receiving a second digital fingerprint from the
`device at a Subsequent time, (c) comparing the second digital
`fingerprint with a plurality of Stored digital fingerprints of
`known devices, (d) 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, (e)
`sending the request code to the remote device, (f) receiving
`the third digital fingerprint from the remote device in
`response to the request code, and (g) authenticating the device
`based on a comparison of the first and third digital finger
`prints.
`
`RECEIVE AND STORE FIRST DIGITAL
`FINGERPRINT DURING A FIRST BOOT OF
`AUTHENTICATING SOFTWARE ON: DEVICE
`
`
`
`RECEIVE SECOND DIGITAL FINGERPRINT
`FROM THE DEVICE
`
`COMPARESECOND DIGITAL FINGERPRINT
`WITH STORED DIGITAL FINGERPRINTS OF
`KNOWN: DEVICES
`
`x. 330
`
`IN RESPONSE TO THE COMPARISON
`INDICATING AMSMATCH BETWEEN THE
`SECOND DIGITAL FINGERPRINT AND THE
`PLURALITY OF STORED DIGITAL FINGERPRINTS,
`GENERATE AREOUEST CODE COMPRISING
`INSTRUCTIONS FOR THE DEVICE TO GENERATE
`A THIRD DIGITAL FINGER PRINT USING THE
`FIRST SET OF DEVICE COMPONENTS
`
`/* 34.O
`
`Page 1 of 18
`
`GOOGLE EXHIBIT 1010
`
`

`

`Patent Application Publication
`
`Apr. 21, 2011 Sheet 1 of 7
`
`US 2011/0093.920 A1
`
`
`
`115
`
`Secy site
`335
`
`A: i: site
`S.
`
`Sirags Risis
`s:
`
`ic-Cessing iodie
`
`Page 2 of 18
`
`

`

`Patent Application Publication
`
`Apr. 21, 2011 Sheet 2 of 7
`
`US 2011/0093.920 A1
`
`226
`
`
`
`228
`
`Variable Key
`POrtion
`
`^
`
`A
`
`224
`
`System Key
`POrtion
`
`FIG. 2
`
`Page 3 of 18
`
`

`

`Patent Application Publication
`
`Apr. 21, 2011 Sheet 3 of 7
`
`US 2011/0093.920 A1
`
`3OO
`
`RECEIVE AND STORE FIRST DIGITAL
`FINGERPRINT DURING A FIRST BOOT OF
`AUTHENTICATING SOFTWARE ON DEVICE
`
`ax. 310
`
`
`
`
`
`RECEIVE SECOND DIGITAL FINGERPRINT
`FROM THE DEVICE
`
`COMPARESECOND DIGITAL FINGERPRINT
`x. 330
`WITH STORED DIGITAL FINGERPRINTS OF -
`KNOWN DEVICES
`
`IN RESPONSE TO THE COMPARISON
`INDICATING AMISMATCH BETWEEN THE
`SECOND DIGITAL FINGERPRINT AND THE
`PLURALITY OF STORED DIGITAL FINGERPRINTS,
`GENERATE AREOUEST CODE COMPRISING
`INSTRUCTIONS FOR THE DEVICE TO GENERATE
`ATHIRD DIGITAL FINGERPRINTUSING THE
`FIRST SET OF DEVICE COMPONENTS
`
`Ar 340
`
`Page 4 of 18
`
`

`

`Patent Application Publication
`
`Apr. 21, 2011 Sheet 4 of 7
`
`US 2011/0093.920 A1
`
`
`
`
`
`RECEIVE THIRD DIGITAL FINGER PRINT
`FROM THE DEVICE IN RESPONSE TO THE
`REQUEST CODE
`
`COMPARE THIRD DIGITAL FINGERPRINT WITH
`STORED DIGITAL FINGERPRINT
`
`AUTHENTICATE DEVICE BASED ON
`
`COMPARISON OF FIRST AND THIRD DIGITAL -
`FINGERPRINT
`
`Page 5 of 18
`
`

`

`Patent Application Publication
`
`Apr. 21, 2011 Sheet 5 of 7
`
`US 2011/0093.920 A1
`
`RECEIVE FIRST DIGITAL FINGERPRINT HAVING
`A PLURALITY OF DIGITAL FINGERPRINT
`PORTIONS FROM THE DEVICE, EACHPORTION -
`BEING ASSOCIATED WITH ACOMPONENT OF
`
`
`
`COMPARE RECEIVED DIGITAL FINGERPRINT
`r 42O
`WITHSTORED DIGITAL FINGERPRINTS OF Y
`AUTHENTICATED DEVICES ::::::::::::::::::::
`
`FLAG EACH DIGITAL FINGERPRINT PORTION
`CREATING ANERRORDURING
`AUTHENTICATION
`
`- 43O
`i
`
`CATEGORIZE ASSOCIATED COMPONENT OF
`- 440
`EACH FINGERPRINT PORTION THAT PRODUCED
`
`
`
`Page 6 of 18
`
`

`

`Patent Application Publication
`
`Apr. 21, 2011 Sheet 6 of 7
`
`US 2011/0093.920 A1
`
`s X
`
`8 $8.
`
`of Kh
`
`8
`
`is
`
`
`
`r
`
`s:
`
`.
`
`s
`
`
`
`
`
`
`
`
`
`
`
`(~~~~ ži
`
`FIG. 5
`
`Page 7 of 18
`
`

`

`Patent Application Publication
`
`Apr. 21, 2011 Sheet 7 of 7
`
`US 2011/0093.920 A1
`
`s
`
`S.
`
`S. 3. s
`
`:SS 8:rk &R&S
`
`
`
`*
`
`8888 is
`Sä.
`R&RG is SERR
`& SäS 8:
`
`8F Es: Si:S rR
`is SS: Es Sir
`
`33
`
`$8:33, 8: ... is:SE:
`SSSSSSSSS
`
`FIG. 6
`
`SE:
`
`S. s
`
`Page 8 of 18
`
`

`

`US 2011/0093.920 A1
`
`Apr. 21, 2011
`
`SYSTEMAND METHOD FOR DEVICE
`AUTHENTICATION WITH BUILT-N
`TOLERANCE
`
`0001. This application claims priority to U.S. Provisional
`Application No. 61/252,960 which was filed Oct. 19, 2009
`and which is fully incorporated herein by reference.
`
`BACKGROUND
`0002 1. Field of the Invention
`0003. The present invention is directed toward a method
`and system for building tolerance into comparisons of device
`fingerprints when authenticating a device.
`0004 2. Description of the Related Art
`0005 Controlling access to a secured network is one of the
`biggest challenges for critical infrastructure. Since the major
`ity of existing infrastructures use computers to connect to the
`Ethernet or Internet, there is an increased possibility for secu
`rity 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 authen
`ticated versus a database of known fingerprints corresponding
`to known authorized devices, then the request for authentica
`tion is rejected or denied.
`0006 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.
`
`SUMMARY
`0007. The following presents a simplified summary of one
`or more embodiments in order to provide a basic understand
`ing 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 embodi
`ments in a simplified form as a prelude to the more detailed
`description that is presented later.
`0008. 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 soft
`
`ware/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.
`0009. 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 plu
`rality 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.
`0010. In the foregoing method, the first digital fingerprint
`may be generated using specific components, such as a typi
`cal-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 com
`ponents such as motherboard, USB host controller, central
`microprocessor, PCI Bus, and System CMOS Clock.
`0011. 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 exclu
`sively comprise components from the list. In this way, a
`control digital fingerprint may be generated to be compared
`with the first digital fingerprint.
`0012. 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 dif
`ferences 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 authen
`ticated when the associated component of the control metric
`and the associated component of the second metric are iden
`tical. 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.
`0013. 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 finger
`prints of known devices, the authentication server may flag
`
`Page 9 of 18
`
`

`

`US 2011/0093.920 A1
`
`Apr. 21, 2011
`
`each portion for 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 percentages could be implemented.
`0014. In accordance with yet another embodiment of the
`present invention a computer readable medium is provided.
`The computer readable medium having stored thereon, com
`puter 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 fin
`gerprint a valid authenticated Status when the flagged finger
`print portions have a predetermined typical-upgrade/non
`typical-upgrade ratio.
`0015. 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 plu
`rality 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.
`0016. 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 digi
`tal fingerprint with stored digital fingerprints of known
`devices; flagging each digital fingerprint portion that creates
`an error during authentication; categorizing associated com
`ponent of each fingerprint portion as a typical-upgrade com
`ponent 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.
`0017. 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 embodi
`ments are intended to include all Such aspects and their
`equivalents.
`BRIEF DESCRIPTION OF THE DRAWINGS
`0018. The present invention, in accordance with one or
`more various embodiments, is described in detail with refer
`
`ence 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 inven
`tion and shall not be considered limiting of the breadth, Scope,
`or applicability of the invention.
`0019 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.
`0020 FIG. 2 is a block diagram representing memory
`allocation for a device identifier used in accordance with
`principles of the present invention.
`0021
`FIG. 3A is a process flow chart illustrating one
`embodiment of a method according to the invention for
`device authentication with built-in tolerance.
`0022 FIG. 3B is a continuation of the process flow dia
`gram of FIG. 3A.
`0023 FIG. 4 is a process flow chart illustrating another
`embodiment of a method according to the invention for
`device authentication with built-in tolerance.
`0024 FIG. 5 is a block diagram illustrating a system
`within which Software components can be executed to per
`form a method for authenticating a device according to one or
`more embodiments of the present invention.
`0025 FIG. 6 is a block diagram illustrating another system
`within which Software components can be executed to per
`form a method for authenticating a device according to one or
`more embodiments of the present invention.
`
`DETAILED DESCRIPTION
`0026. 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 authen
`tication 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 con
`figurations or statuses, and Software version, etc.
`0027. By building in tolerance into the authentication pro
`cess, the risk of rejecting a valid device is reduced. Some
`tolerance is needed because users may upgrade their hard
`ware 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, with
`out tolerance a valid device may be rejected once an upgrade
`is made to the device.
`0028. 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 appli
`cation, 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 authentica
`tion processes.
`
`Page 10 of 18
`
`

`

`US 2011/0093.920 A1
`
`Apr. 21, 2011
`
`0029. The first bootfingerprint may be generated using the
`overall environmental information collected by the authenti
`cation module. Alternatively, the first boot fingerprint may be
`generated using specific components of the device as prede
`termined by the authentication client. The specific compo
`nents may include components from a typical-upgrade com
`ponents 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 con
`troller, or other routinely upgraded components. The non
`typical-upgrade components list may include components
`such as: motherboard, USB host controller, central micropro
`cessor, PCI Bus, System CMOS Clock, etc.
`0030. In one embodiment, at the first boot of the authen
`tication client, two different digital fingerprints are generated.
`One of the fingerprints may be generated using only compo
`nents 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 com
`ponents from both typical and non-typical upgrade lists or
`environmental information of the device as a whole to gen
`erate the fingerprint instead of using specific components.
`Once the authentication client generates the digital finger
`prints, 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.
`0031 Where the device is registering with the authenticat
`ing 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 authen
`ticated. The authentication process may also request the user
`to enter a username and a password in addition to the verifi
`cation of the response code.
`0032. 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 offingerprints 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.
`0033. 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 offinger
`prints 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.
`0034. The response code may be transmitted to an authen
`ticating server via email or short messaging system (SMS).
`Where SMS is used, the device may be configured to auto
`
`matically 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.
`0035. Once the response code is received at the authenti
`cating 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.
`0036 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 com
`merce restriction, System, and apparatus is implemented
`according to one or more embodiments of the present inven
`tion. 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 appli
`cation 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 back
`ground with little or no interaction with the user of device
`110.
`0037. 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.
`0038 Referring again to FIG. 1, computing devices
`110a-b may be in operative communication with authenticat
`ing 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 com
`munication device, an onboard vehicle computer, or any other
`device capable of communication with a computer network.
`0039 Per the request code received from the authenticat
`ing 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
`
`Page 11 of 18
`
`

`

`US 2011/0093.920 A1
`
`Apr. 21, 2011
`
`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 amount of
`memory, type of processor, software or operating system
`serial number, etc.
`0040 Based on the collected information, the security cli
`ent 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 compo
`nent of device 110. Alternatively, the request code may
`specify one or more fingerprints in whole.
`0041. 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.
`0042. It is noted that the security client running on the
`computing device or otherwise having access to the comput
`ing 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 compo
`nent, 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 portions of the device identifier as requested by
`the request code.
`0043. 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 pro
`cess 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.
`0044. The application may operate by performing a sys
`tem scan to determine a present configuration of the comput
`ing 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 depend
`ing on the system configuration. Once the parameters are
`selected, the application may generate the identifier.
`0045. 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 deg
`radation and Small device failures.
`0046. The process of measuring carbon and silicone deg
`radation may be accomplished by measuring a chip's ability
`to process complex mathematical computations, and its abil
`ity 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 degrada
`tions manifest as gradually slower speeds that extend the
`processing time required to compute various benchmarking
`algorithms.
`0047. In addition to the chip benchmarking and degrada
`tion measurements, the process for generating a device iden
`tifier may include measuring physical, non