(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2011/0093701 A1
`Etchegoyen
`(43) Pub. Date:
`Apr. 21, 2011
`
`US 2011 0093701 A1
`
`(54) SOFTWARESIGNATURE TRACKING
`
`(76) Inventor:
`
`Craig S. Etchegoyen, Irvine, CA
`(US)
`
`(21) Appl. No.:
`y x- - -
`
`(22) Filed:
`
`12/903.980
`9
`Oct. 13, 2010
`
`Related U.S. Application Data
`(60) Provisional application No. 61/252,983, filed on Oct.
`19, 2009.
`
`O
`O
`Publication Classification
`
`(51) Int. Cl.
`H04L 29/06
`H04L 9/32
`G06F 2/14
`H04L 9/28
`
`(2006.01)
`(2006.01)
`(2006.01)
`(2006.01)
`
`(52) U.S. Cl. ............................ 713/165; 713/176; 726/26
`(57)
`ABSTRACT
`A method for preventing unauthorized use of software may be
`achieved by executing computer-readable code with instruc
`tions for recording an indication of at least one selected file of
`a software application in a memory location accessible to a
`security component of the Software application, in which
`Software application the security component is configured to
`cause a hash signature of the at least one selected file to be
`generated in response to a signal arising from use of the
`Software application, hashing the at least one selected file to
`generate a first file signature, transmitting the first file signa
`ture to a secure network-accessible computer memory for
`storage and Subsequent comparison to at least one Subsequent
`file signature generated via operation of the security compo
`nent on a client device, comparing the first file signature to a
`second file signature generated by the security component in
`response to a signal arising from use of the Software applica
`tion on the client device, and disabling the Software applica
`tion on the client device, in response to determining that the
`first file signature does not match the second file signature.
`
`30
`
`SELECT FILE TO BE TRACKED
`
`302
`1.
`
`STORE FILEID FOR SECURITY - 30
`
`COMPONENT
`
`306
`GENERATE BASELNESIGNATURE 1.
`
`REGISTER BASELNESIGNATURE
`
`3O8
`1.
`
`INTEGRATE SECURITY COMPONENT - 310
`
`WITH APPLICATION PARTS
`
`312
`PUBLISHINTEGRATED APPLICATION 1.
`
`Page 1 of 14
`
`GOOGLE EXHIBIT 1011
`
`

`

`Patent Application Publication
`
`Apr. 21, 2011 Sheet 1 of 6
`
`US 2011/0093701 A1
`
`
`
`FIG. 1
`
`Page 2 of 14
`
`

`

`Patent Application Publication
`
`Apr. 21, 2011 Sheet 2 of 6
`
`US 2011/0093701 A1
`
`104
`
`102
`
`PROVIDEDEVELOPERTOOLS
`MANAGESIGNATUREDATA
`ENFORCESECURITYPOLICES
`TRACKING AND REPORTING
`
`
`
`
`
`DEVELOP APPLICATION
`CONFIGURE SECURITY TOOLS
`VERSIONMANAGEMENT
`REVIEW TRACKINGREPORTS
`
`
`
`
`
`
`
`
`
`
`
`APPLICATION ENDUSER
`RUNSSECURITY TOOLS
`AUTHORIZESUPDATES
`
`FIG. 2
`
`Page 3 of 14
`
`

`

`Patent Application Publication
`
`Apr. 21, 2011 Sheet 3 of 6
`
`US 2011/0093701 A1
`
`SELECT FILE TO BE TRACKED
`
`3O2
`1.
`
`STORE FILEID FOR SECURITY - 304
`
`COMPONENT
`
`l
`l
`
`306
`GENERATE BASELNESIGNATURE 1.
`
`REGISTER BASELNESIGNATURE 1.
`
`l
`
`INTEGRATE SECURITY COMPONENT - 310
`WITH APPLICATION PARTS
`
`312
`PUBLISHINTEGRATED APPLICATION 1.
`
`FIG. 3
`
`Page 4 of 14
`
`

`

`Patent Application Publication
`
`Apr. 21, 2011 Sheet 4 of 6
`
`US 2011/0093701 A1
`
`INSTALL OR USE APPLICATION
`
`
`
`GENERATE COMPARISON
`SIGNATURE
`
`
`
`TRANSMIT COMPARISON
`SIGNATURE AND METADATA
`
`
`
`
`
`
`
`
`
`RECEIVE RESULTS
`
`4.08
`
`
`
`410
`
`
`
`
`
`
`
`BASELNE
`SIGNATURE MATCHES
`COMPARISON
`SIGNATUREP
`
`
`
`
`
`
`
`
`
`
`
`ENABLE APPLICATION
`
`414
`
`FIG. 4
`
`412
`
`
`
`DISABLE APPLICATION
`
`Page 5 of 14
`
`

`

`Patent Application Publication
`
`Apr. 21, 2011 Sheet 5 of 6
`
`US 2011/0093701 A1
`
`PROVIDE DEVELOPMENT TOOLS
`
`CONFIGURE DATABASE
`
`RECEIVE SIGNATURE DATA
`AND METADATA
`
`PERFORM COMPARISONS
`
`
`
`
`
`TRANSMIT RESULTS
`
`
`
`
`
`BASELNE
`SIGNATURE MATCHES
`COMPARISON
`SIGNATUREP
`
`512
`
`5O2
`
`504
`
`506
`
`508
`
`51O
`
`514
`
`DISABLE APPLICATION
`
`ENABLE APPLICATION
`
`GENERATE REPORT
`
`518
`
`FIG. 5
`
`Page 6 of 14
`
`

`

`Patent Application Publication
`
`Apr. 21, 2011 Sheet 6 of 6
`
`US 2011/0093701 A1
`
`
`
`Version
`
`61O
`
`Calc-Smart
`
`612
`
`Calc-Smart
`
`614
`
`Calc-Smart
`
`FIG. 6
`
`Page 7 of 14
`
`

`

`US 2011/0093701 A1
`
`Apr. 21, 2011
`
`SOFTWARE SIGNATURE TRACKING
`
`0001. This application claims priority to U.S. Provisional
`Application No. 61/252,983 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 relates to methods and sys
`tems for protection and tracking use of computer software.
`More specifically, the invention relates to identifying soft
`ware for protection and tracking purposes by deriving a char
`acteristic signature from the Software.
`0004 2. Description of Related Art
`0005 Various methods are known in the art for preventing
`unauthorized duplication and use of software and other copy
`righted digital content. While most such methods are at least
`partially effective in preventing piracy, many copyright soft
`ware methods can be defeated by the persistent efforts of
`skilled individuals—sometimes called “hackers' with
`expertise in computer systems and programming. Such hack
`ers are sometimes able to modify distributed copies of soft
`ware to disable its copyright protection features, so that the
`modified software can be freely copied or used without
`license restrictions, while still retaining its essential function
`ality. Software in which protection features are thusly dis
`abled is sometimes referred to as being “cracked.”
`0006. The existence of cracked software versions may
`create a risk of unauthorized or illegal distribution and use,
`which may harm legitimate Software providers. Besides caus
`ing loss of licensing revenue, cracked Software versions may
`not function as originally designed, which may harm user's
`perception of the software provider's quality control. For
`these and other reasons, it is desirable to detect and prevent
`the spread of cracked software or other digital content. Cur
`rent methods for detecting and preventing the spread of
`cracked Software include human monitoring of software dis
`tribution channels to detect and track illegally modified soft
`ware versions. However, such monitoring is relatively expen
`sive and inefficient, and may not provide Sufficient (or any)
`control over use of cracked software even after it is detected.
`It is therefore desirable to provide improved methods for
`detecting and controlling distribution and use of software or
`other digital content that has been tampered with, Such as by
`removing copyright protection features.
`
`SUMMARY
`
`0007. The present disclosure describes systems and meth
`ods for enabling Software signature tracking in conjunction
`with client machine identifiers and distributed code, by soft
`ware developers.
`0008 Prior to release of software under development,
`developers may "wrap an application to provide copyright
`protection features Such as, for example, encryption of code
`requiring a security key. Less robust security wrappers may
`add security features after Software is completed and com
`piled, using separate security tools. More robust security
`wrappers integrate security features in the program code, and
`may be compiled together with application program code. To
`ease programming burdens on Software developers, providers
`of security wrapping tools may implement security wrapping
`
`tools through an interface that is coordinated with or includes
`a component for development of Source code.
`0009. In accordance with the foregoing, an application to
`be protected may be configured with a protected security
`component. The protected Security component comprises
`code that is protected from reverse-engineering, from being
`disabled, or from being deleted using any suitable software
`protection method or combination of methods, for example,
`encryption, physical device detection, obfuscation, and trip
`wires. The protected security component may be integrated
`into the application software to be protected so that it cannot
`be deleted or disabled without impairing or disabling the
`protected application. In some embodiments, the protected
`security component is configured and integrated with the
`application Software to be protected using a Supplied security
`wrapping application. As part of the configuration process,
`the Security wrapping application may receive as input an
`identifier, Such as, for example, a file name, for one or more
`files chosen to be the signature root by the software developer.
`A file selected to be the signature root may be, for example, a
`critical executable file making up part or essentially all of the
`application to be protected.
`0010. Once the signature root file has been selected, the
`security wrapping application may process the root file using
`a predetermined secret hash to generate a file signature. Any
`Suitable hashing algorithm may be used to generate the sig
`nature Such as, for example, a cryptographic MD5, SHA-1, or
`SHA-2 hash. The file signature resulting from the hashing
`process may be securely transmitted to a network-accessible
`database. For greater security, the file signature should not be
`included in the securely wrapped software application.
`0011. The protected application may also be wrapped with
`a protected client application security component that may be
`configured to operate on client devices after distribution of
`the protected application. The client application security
`component is configured to operate as follows in response to
`execution of the protected application on a client device.
`First, the security component regenerates the file signature
`using the hashing algorithm operating on the signature root
`file. Next, the security component determines whether the file
`signature has changed since the last time that the protected
`application has run on the client device. This may be done, for
`example, by comparing the regenerated file signature with a
`stored file signature generated at an earlier time, e.g., prior to
`software release. To reduce risk of a security breach, the client
`security application may be configured to perform the com
`parison by transmitting the regenerated signature to a secure
`remote site, together with another identifier for the protected
`application and optionally, a machine fingerprint for the client
`device running the protected application. The secure remote
`site may access a secure database of signatures using the
`identifier for the application to determine one or more past
`authorized signatures for the protected application. The
`secure remote site may compare the regenerated signature
`with the one or more past authorized signatures and commu
`nicate a result, for example, “match to version 1.1.” or “no
`match, to the client security component.
`0012. The client security component may take a desig
`nated security action in response to the results from the com
`parison. For example, if the signature does not match any
`authorized software version, the client-side security applica
`tion may display an error message and disable normal opera
`tion of the protected application. For further example, the
`security application may display a message alerting the user
`
`Page 8 of 14
`
`

`

`US 2011/0093701 A1
`
`Apr. 21, 2011
`
`that a software update is recommended or required, when the
`regenerated signature matches a signature for an outdated
`Software version while not matching the signature for the
`most current Software version.
`0013 Software signature data communicated to a server
`site by numerous client-side security applications can be used
`to generate version information reports to any interested par
`ties. For example, software publishers may be alerted when
`new file signatures appear at client machines prior to version
`release, or if not matching any authorized file signature. Such
`events may be interpreted as indicating unauthorized pre
`release leaks or software tampering, respectively. Version
`tracking statistics can also be collected and reported, both for
`authorized software versions and unauthorized (e.g., cracked)
`Software versions.
`0014. A more complete understanding of Software signa
`ture tracking will be afforded to those skilled in the art, as well
`as a realization of additional advantages and objects thereof,
`by a consideration of the following detailed description. Ref
`erence will be made to the appended sheets of drawings which
`will first be described briefly.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0015 FIG. 1 is a block diagram showing an example of a
`system in which an embodiment of a software signature track
`ing method may be implemented according to the invention.
`0016 FIG. 2 is a functional block diagram showing an
`example of how various functions may be distributed in meth
`ods or systems for software signature tracking according to
`the present invention.
`0017 FIG. 3 is a process flow chart showing one embodi
`ment of a method according to the invention for Software
`signature tracking at a Software developer node.
`0018 FIG. 4 is a process flow chart showing one embodi
`ment of a method according to the invention for Software
`signature tracking at a client node.
`0019 FIG. 5 is a process flow chart showing one embodi
`ment of a method according to the invention for Software
`signature tracking at an administrative node.
`0020 FIG. 6 is a table showing a simplified example of a
`version tracking report prepared using a method according to
`the present invention.
`
`DETAILED DESCRIPTION OF THE INVENTION
`0021
`FIG. 1 shows an example of a system 100 in which
`a developer node 102 communicates with an administrative
`node 104 and numerous client nodes 106-110 using a network
`112. Each of the developer node, administrative node, and
`client nodes may comprise at least one computing device
`including a processor and memory device, a user input device
`and a display or other output device. By way of example,
`clients 106-110 may have various form factors and functions,
`such as a personal computer 106, portable computer 107.
`notebook or pen computer 108, PDA 109, or mobile phone
`110. Such clients are capable of communicating over wide
`area networks and other communications networks to share
`data, as well as storing and executing Software applications to
`provide various functions for respective end users. The meth
`ods disclosed herein may be adapted for use with any of these
`or similar clients.
`0022 Developer node 102 may similarly comprise a pro
`cessor 114 configured to execute program instructions stored
`in a memory 116 to perform processing functions in response
`
`to input from an input device 118, Such as a keyboard, touch
`screen, microphone, or the like. The processor may direct
`output to an output device 120, for example, a computer
`monitor or display Screen. The processor 114 may also be in
`communication with a storage device 122, for example, an
`HDD, holding a set of computer files 124 making up a soft
`ware application. The Software application 124 comprises at
`least one executable file 126, a security component 128, and
`any non-zero number of other or ancillary files 130, encoded
`in a computer-readable medium. The administrative node 104
`may comprise similar components. The developer node,
`administrative node, and client nodes may each comprise any
`non-Zero number of processors and computers.
`0023 FIG. 2 illustrates how functions may be distributed
`between the various nodes described above. The administra
`tive node 104 may include at least one computer operated to
`perform the functions of: (1) providing software security
`tools for developers to add the Software signature tracking
`functions described herein; (2) managing software signature
`data generated by the software signature tracking functions
`on various clients; (3) enforcing security policies set by the
`developer when Software signature tracking indicates one or
`more clients is in violation of license terms; and (4) tracking
`distribution and use of software versions by the various client
`devices using the Software application 124. These functions
`may be performed using application Software and/or firm
`ware operating on one or more computers in communication
`with client nodes 106 and developer nodes 102.
`0024 Software security tools, as used herein, includes
`specialized software components configured for integration
`in or with Software application, to perform the Software sig
`nature tracking as described herein and any other desired
`security functions, for example, key control and physical
`device tracking. In brief, physical device tracking security
`tools use measurements of physical device parameters as part
`of a security algorithm to prevent unauthorized copying of
`software to unlicensed physical devices. Physical device
`tracking is most effectively implemented probabilistically
`using numerous device parameters to determine a machine
`fingerprint for a particular device. Changes in the machine
`fingerprint that fall below a specified difference threshold do
`not trigger security restrictions in probabilistic implementa
`tions. Conversely, changes in the machine fingerprint that
`exceed the specified difference threshold do trigger security
`restrictions. In other words, minor changes in device configu
`ration are tolerated as being less likely to indicate use of
`licensed software on an entirely new machine, while more
`significant changes in a machine fingerprint are interpreted as
`indicating that the licensed software has been copied to a new
`machine. Software signature tracking may, in the alternative,
`be implemented in a security application without physical
`device tracking. Physical device tracking as referenced above
`is described more fully in U.S. Pat. No. 5.490,216 and in U.S.
`Provisional Application Ser. No. 61/218,558, both of which
`are fully incorporated herein by reference.
`0025 Security features as disclosed herein may be imple
`mented as part of a Suite of integrated or non-integrated
`security wrapping tools provided by an administrative node
`104. For example, the described features may be integrated
`into other application Software using a Supplied Suite of secu
`rity wrapping tools. However, the present technology is not
`limited by this example. In the alternative, and for further
`example, these features may be coded by hand during any
`application development process.
`
`Page 9 of 14
`
`

`

`US 2011/0093701 A1
`
`Apr. 21, 2011
`
`0026. Managing signature data may also be performed by
`the administrative node 104. Signature data includes hashed
`signature data and any associated Software application infor
`mation, descriptive text, dates, times, physical device identi
`fiers, and other data. Such data may be managed at an admin
`istrative node by updating one or more databases with
`qualified data, receiving queries and incoming data, deter
`mining whether incoming data is qualified for inclusion in its
`database, responding to queries and incoming data, and per
`forming routine database management tasks. The administra
`tive node may store and manage data for numerous different
`Software applications and versions, including both unautho
`rized and authorized versions. Each application and version
`pair may be associated with a hashed signature, textual
`description, Software application identifier, developer infor
`mation, signature date and other metadata, in a database or
`other data structure. New software signatures for new ver
`sions may be added by developers; in addition, new signa
`tures indicating unauthorized versions may be discovered by
`client-side security components and reported to the database.
`Signature data reported by client-side security components
`may be included in the database in association with metadata
`identifying the application, network address, physical device
`identifier, geographic location, and other data describing the
`client or clients on which the new signature was discovered,
`together with a time and date of first discovery. Such data may
`be useful in tracking distribution of software versions, both
`unauthorized and authorized, among a client population, as
`well as for license enforcement.
`0027. Another function of the administrative node 104
`may be to enforce security policies and/or license provisions
`defined by software publishers, in response to discovery of
`unauthorized software versions on one or more clients. Physi
`cal device identifiers, assigned client device identifiers, net
`work addresses, or user account identifiers may be used to
`prevent access by clients operating unauthorized versions to
`local or network resources requested by the unauthorized
`Software version, thereby at least partially disabling its opera
`tion. For example, an administrative node may maintain a
`database of client identification data as an electronic “black
`list” for clients operating unauthorized software versions.
`Network resource providers may filter incoming resource
`requests from clients using the database to identify any black
`listed clients, and deny access to the network resource to some
`clients. For further example, use of local resources including
`program files and data may be denied by the administrative
`node sending a signal to a client on which an unauthorized
`version is detected. A “trap door’ i.e., hidden software rou
`tine, may detect the signal and reconfigure system variables
`So as to disable the Software application.
`0028. The administrative node may also generate and dis
`tribute tracking reports based on Software signature data.
`Such reports enable software publishers and others to see
`relationships and distribution patterns for various software
`versions within a population of client devices. Reports may be
`generated using the database of signature and associated data
`maintained by the administrative node.
`0029. One or more developer nodes 102 may include at
`least one computer operated to perform the functions of: (1)
`developing Software applications to be used with the signa
`ture tracking components and methods as disclosed herein;
`(2) configuring the signature tracking tools provided from an
`administrative node to operate with particular application
`versions; (3) managing and coordinating the registration of
`
`Software signatures for each authorized version, optionally
`including registration of unreleased versions; and (4) receiv
`ing, reviewing, and responding to version tracking reports
`provided from the administrative node. Software develop
`ment may generally be performed independently of the
`administrative node and as such, is not within the Scope of the
`present disclosure. The present technology may be useful
`with a wide variety of applications developed for diverse
`computing platforms and clients.
`0030. During or after software application development,
`Software developers may, using a software development tool
`or by manual programming, specify control variables and
`initiate configuration actions for different software versions.
`For example, the developer node may operate to specify one
`or more files for each application to be hashed to generate a
`signature, and initiate a hashing function to generate a signa
`ture using the specified file or files as input. Furthermore, the
`developer node may integrate and configure client-side sig
`nature tracking components of the application, as part of an
`application development process. The client-side signature
`tracking components may be developed and Supplied via the
`administrative node, and integrated at a developer node with
`application code.
`0031. The developer node may also be used to register
`completed signature values and associated metadata with a
`tracking database. Such as by transmitting the signature val
`ues and metadata to the administrative node or other desig
`nated data storage resource. Metadata accompanying the sig
`nature values may include, for example, a textual description
`of the application and version to which the signature relates,
`date and time each signature is generated, identity of the
`developer node, and one or more addresses to receive tracking
`reports. As part of a registration process with an administra
`tive node, the developer node may also specify enforcement
`actions to be taken in response to detection of unauthorized
`Software versions, and configure network resources and/or
`the software application to enable operation of the specified
`enforcement actions.
`0032. Once signature tracking has been configured for an
`initial version of a software application, the developer node
`may similarly configure signature tracking for each Subse
`quently application version to be released, if any. The devel
`oper node may configure tracking for each Subsequent appli
`cation version using the same process as used for an initial
`release version. A signature tracking record may be created
`for each Subsequent version in the signature database. In this
`way, the signature tracking system Supports tracking of later
`versions while retaining tracking capability for earlier
`released versions of an application.
`0033. After releasing an application version and configur
`ing signature tracking for it, the developer node may receive
`tracking reports from the administrative node reporting on
`use of the signed application. The tracking reports may
`include identifying installations and use events for the
`released application, broken down by geographic region,
`date, client type, user account type, or other desired catego
`ries. The reports may also identify any installation or use
`event for new unauthorized software versions, also organized
`by category. As used herein, a “use event' for application
`software refers to any event that is defined as recordable or
`reportable for the client-side signature tracking component;
`for example, a call to load the tracked executable file into
`random access memory for execution by the client processor,
`
`Page 10 of 14
`
`

`

`US 2011/0093701 A1
`
`Apr. 21, 2011
`
`or use of the tracked executable to perform a defined task,
`Such as, for example, joining a multi-user remote game
`instance.
`0034 Client node 106 exemplifies functions that may be
`performed on various types of client nodes. Each client node
`is an end user of the tracked Software application, and makes
`use of the application in a way that triggers operation of the
`application's Software tracking component, sometime called
`a security component. Each client provides a platform for
`operation of the application's tracking component after each
`Such triggering event. In general, operation of the tracking
`component is automated. Once its operation is triggered by
`the user causing occurrence of a use event, user input is not
`required at the client for the tracking component to operate at
`the client. The client-side tracking component may operate in
`coordination with a remote application operating at an admin
`istrative node to perform a reporting and tracking function, as
`described in more detail herein. Another function of the client
`node may be to authorize updates to Software versions when
`an outdated or unauthorized version is detected at the client.
`In the alternative, updates may be performed automatically is
`permitted by the applicable license agreement.
`0035 FIG.3 shows an example of a method 300 for soft
`ware signature tracking at a Software developer node. Method
`300 may be performed by a computer operating program
`instructions, which may be configured as Software using any
`Suitable programming method and encoded on a computer
`readable medium. Certain portions of the method revolve
`responses to inputs received from any suitable user interface
`device or from a cooperating computing or electronic
`memory device, as should be apparent from the accompany
`ing description.
`0036. Initially, a user of the developer node may select302
`one or more executable files to be tracked using software
`signature tracking as disclosed herein. In general, Software
`applications may comprise numerous different files, of both
`executable and non-executable types, required to operate the
`application. Of these, a developer may select at least one file,
`preferably an executable file that is important or critical to
`operation of the application as a whole, to be tracked using
`signature registration. An interface application operating on
`the developer node may select the file to be tracked in
`response to input from a user input device.
`0037. Once selected, the developer node may record an
`identifier for the selected file 304, for example, a file name or
`memory address, in a location accessible to the application
`security component. This process is depicted in block 304. A
`Suitable location may include, for example, code making up
`the application itself. For example, the developer node may
`set a predetermined variable value to the identifier for the
`selected file, such as “tracked file=filename.bin.” This vari
`able may be compiled and encoded with other program code
`and the security component to make up the integrated appli
`cation. In the alternative, the developer node may store the
`identifier in a different location that is, or will be, accessible
`to the security component when operating on the targeted
`client devices. For example, the developer node may cause
`the identifier to be stored in a remote online database.
`0038. After development of the selected file is completed
`and the file is ready for release, the developer node may cause
`a baseline signature of the file to be generated 306, using any
`Suitable cryptographic file hashing algorithm. For example,
`the file signature may be generated using a cryptographic
`MD5, SHA-1, or SHA-2 hash. In the alternative, a different
`
`hashing algorithm may be used. The selected hashing algo
`rithm should result in a relatively compact hash output, for
`example, less than a kilobyte, or less than a few kilobytes, as
`necessary to provide for a secure and unique hash signature.
`A secure and unique hash signature is one that will not result
`in collisions, that is, the same hash output, from different
`input files, and that cannot be cracked or reverse-engineered
`using a reasonable amount of computing resources. Hashing
`techniques tend to evolve over time in response to changing
`computing environments, and the present technology may
`use any hashing technique Suitable for its intended environ
`ment.
`0039. The file signature resulting from the hashing process
`may be registered 308 with a designated administrative node,
`for example, by securely transmitting from the developer
`node to a designated network-accessible secure database. In
`embodiments that use more than one hashing method, an
`indicator of the hashing technique used to obtain the file
`signature may similarly be registered. For greater security, the
`file signature should not be included in the published software
`application, nor should any readily discernable indication of
`the hashing technique be recorded there. However, the secu
`rity component may include encrypted, obfuscated and com
`piled program code for computing a hash signature of the
`target application file or files. In the alternative, or in addition,
`this program code may be configured to require a key or code
`portion from a remote source, for example, from the admin
`istrative node, to enable client-side operation of the hashing
`algorithm.
`0040. In addition, after all application components are
`completed and ready for publishing, the developer node may
`integrate the security component with other application parts
`to provide an integrated application, as depicted in block 310.
`The security component should include those parts of the
`application that provide client-side Software signature track
`ing functions, for example, as described in connection with
`FIG. 4 below. The security component may include other
`security functions, for example, device fingerprinting or pro
`filing, or security key access control, in addition to file sig
`nature tracking. The security component may be obfuscated
`so that its presence and location of its parts cannot readily be
`detected in the integrated application. In the final step 312, the
`developer node may then publish the integrated application
`version through any suitable distribution channel for instal
`lation on a targeted population of client computing devices.
`0041
`FIG. 4 shows an example of a method 400 for soft
`ware signature tracking at a client node. The method may be
`initiated by occurrence of a triggering event 402, for example,
`installation of an application including the security compo
`nent on a client node, or a defined