Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
In the remarks filed on 11/20/2025. The applicant amended claims 1-3, 5, 7, 8, 10-16, and 20 are amended. No claims were added.
With respect to 35 U.S.C. §102 and 103 rejections:
Applicant's arguments filed on 11/20/2025 have been received and entered.
Applicant's arguments with respect to the newly amended independent claims, see Applicant Arguments 14-17, with respect to the rejection (s) of independent claims 1,11 and 16 have been fully considered.
Applicant argues that Wright (US 20210306139 A1) in view of Acun (US 20200265168 A1) in further view of Shemesh (US 10830863 B1) fails to teach the amended limitation “wherein said digital fingerprint comprises at least two of: an agent-based fingerprint, a network-based fingerprint, a web rendering fingerprint, a cookie-based fingerprint, or an audio-based fingerprint” and also Wright is “silent to fingerprinting”. Examiner understands the applicant’s perspective; however, examiner respectfully disagrees. The applied references particularly Shemesh expressly teaches fingerprinting and fingerprint matching for device identification/authentication. Shemesh discloses dynamic computer network fingerprint matching to authenticate and track the identity of client devices and repeatedly describes collecting fingerprint attributes associated with client device and matching the collected fingerprint attributes to previously stored fingerprint attributes to determine whether the device has been previously identified, see (Field, summary). Therefore, Applicant’s position that applied references are “silent to fingerprinting” is not persuasive. Also, applicant amended claim 23 to require that “digital fingerprint comprises at least two of” the claimed fingerprint types. Under BRI, this limitation requires any two of the listed fingerprint types. Shemesh teaches at least two of the enumerated fingerprints, for example (a) cookie-based fingerprint (b) Network based fingerprint. The reference discloses receiving a client access request that “includes a cookie”, validating the cookie (e.g., based on timestamp, IP address, and cryptography) and using the cookie validation result within the fingerprint matching flow, (steps 302-304, also description fig 4) and using network identifiers/parameters (e.g., Ip address; and also describing that a network identifier may include and IP address and /or MAC address associated with the client device) as part of client device validation/identification, (see step 304, step 306). Thus, Shemesh teaches a “digital fingerprint” that comprises at least two of the claimed fingerprint types, thereby meeting the amended limitation under BRI.
Applicant also argues that it would not have been obvious in combining the applied references to arrive at the claimed invention. Examiner respectfully disagrees. Shemesh expressly teaches collecting fingerprint attributes, determining uniqueness values, accounting for attribute volatility/updating history, ranking candidate fingerprints, determining matches against previously validated fingerprints, and employing dynamic learning/scoring over time, (see Shemesh, Background, see steps 306-316), this disclosure clearly teaches that the fingerprinting/matching techniques for device identification/authentication. Wright relates to secure handling of protected data/keys, Acun relates to generating device identifying attributes/fingerprints using measurable hardware/performance characteristics, and Shemesh relates to fingerprint attribute collection and matching/validation using stored fingerprints, thus it would have been obvious to a POSITA to apply known fingerprint matching/validation techniques (Shemesh) in context of device identification/authentication systems (including those using hardware/performance attributes as in Acun and secure handling as in wright) to improve identification and mitigate spoofing and other security risks.
Applicant argues that the specification states that using one fingerprinting technique alone may yield “suboptimal” results, however the amended claim only require that digital fingerprint comprises at least two claimed fingerprint types. As explained above, Shemesh teaches at least two such types, thus applicant arguments about the specification does not fall within the scope of the claims.
Applicant argues that other references such as Green, Edwards, Quinlan, Zhang, Matsukawa, Akella, Steffen respectively does not cure the deficiencies of Wright, Acun and Shemesh. Applicant further argues Green, Edwards are silent to fingerprinting. However, as discussed above, Shemesh expressly teaches fingerprinting. The remaining references are relied upon only to teach the specific missing elements, not to disclose the entire claimed invention and just to supply only the identified missing limitations as permitted under 103.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION. —The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 23, 45, and, 47- 49 recite the limitation "wherein said digital fingerprint comprises at least two of: an agent-based fingerprint, a network-based fingerprint, a web rendering fingerprint, a cookie-based fingerprint, or an audio-based fingerprint”. The claim requires the digital fingerprint itself to comprise two or more fingerprints. However, the specification repeatedly describes the ML output as a score/vector that serve as digital “fingerprint” (e.g., a score unique to the client device), [0025,0036-0037]. In contrast, the claimed fingerprints such as agent-based, network-based, web rendering, cookie-based, audio-based are described in specifications as fingerprinting techniques or sources of attributes, not as components contained within a single digital fingerprint output. As a result, It makes the claim limitation unclear whether the claimed “digital fingerprint” is a single score/vector generated by the machine learning algorithm, or a composite data structure containing multiple distinct fingerprints or a result derived from applying multiple fingerprinting techniques. Moreover, if the “digital fingerprint” is a score or vector, it is unclear how such score “comprises” all these multiple fingerprints each of which itself typically understood as a distinct fingerprint or attributes. Furthermore, The terms “agent-based fingerprint”, “network-based fingerprint”, and “cookie-based fingerprint” are recited as required components of digital fingerprint but are not defined in the claims nor it is clear what specific data or characteristics qualify each. The claim does not specify what data constitutes these respective fingerprints and how such fingerprints are distinguished from one another within the digital fingerprint, Examiner suggests applicant to clarify the scope of the claims. Dependent claims are also rejected for inheriting the deficiencies set forth above for independent claims. Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 23-28, 30, 32, 33, 38-41, and 45-47 are rejected under 35 U.S.C. 103 as being unpatentable over Wright (US 20210306139 A1) in view of Acun (US 20200265168 A1) in further view of Shemesh (US 10830863 B1).
Regarding claim 23, Wright teaches a method, comprising:
obtaining a first partial key and a plurality of encrypted parameters from a database implemented on said hardware device and a second partial key from a remote server (Wright, The client user device (i.e., hardware device) only stores part of the cryptographic key (i.e., a first partial key) with the encrypted data (i.e., a plurality of encrypted parameters), [0020] a slot server (i.e., a remote server) which stores the second half of the cryptographic key(i.e., the second partial key), [0021] The data storage device 122 is included within the slot server 102, which includes a remote data storage accessed by the computing device via the network 112, such as a remote data storage device, a data storage in a remote data center, or a cloud storage, [0039] the client-generated partial key 132 is stored separately from the slot server generated partial key 128. The encrypted data on a data storage on the client or accessible by the client can only be decrypted with the composite key, which is composed of both the partial key 132 and the partial key 128, [0047]) [Examiner interprets that client user device (i.e., hardware device) using the cryptographic key (i.e., a first partial key) with the encrypted data (i.e., a plurality of encrypted parameters) stored in the client device and the second half of the cryptographic key (i.e., the second partial key) from slot server (i.e., the remote server) to create composite key to decrypt the encrypted data stored in the client user device as obtaining a first partial key and a plurality of encrypted parameters from a database implemented on said hardware device and a second partial key from a remote server].
decrypting said plurality of encrypted parameters using said first partial key and said second partial key, to thereby generate a plurality of decrypted parameters (Wright, the client-generated partial key 132 is stored separately from the slot server generated partial key 128. The encrypted data on a data storage on the client or accessible by the client can only be decrypted with the composite key, which is composed of both the partial key 132 and the partial key 128, [0047]) [Examiner interprets that client user device (i.e., hardware device) combining the cryptographic key (i.e., a first partial key) stored in the client device and the second half of the cryptographic key (i.e., the second partial key) from slot server (i.e., the remote server) to create composite key to decrypt the encrypted data (i.e., plurality of encrypted parameters) stored in the client user device as decrypting said plurality of encrypted parameters using said first partial key and said second partial key, to thereby generate a plurality of decrypted parameters].
Wright does not teach:
A method for uniquely identifying a hardware device comprising: obtaining a plurality of attributes of said hardware device, wherein said plurality of attributes comprises a state of a central processing unit (CPU) or a graphics processing unit (GPU) of said hardware device; processing, on said hardware device, said plurality of attributes with a first machine learning algorithm to generate a digital fingerprint of said hardware device, wherein said first machine learning algorithm comprises said plurality of decrypted parameters; processing, on said remote server, at least said digital fingerprint of said hardware device and said plurality of attributes with a second machine learning algorithm to determine whether said hardware device has been previously identified
However, Acun teaches:
obtaining a plurality of attributes of said hardware device, wherein said plurality of attributes comprises a state of a central processing unit (CPU) or a graphics processing unit (GPU) of said hardware device (Acun, creating a hardware fingerprint of a device such as mobile device…To distinguish devices of different model, a performance profile can be sufficient. For example, a compute intensive kernel, e.g., a matrix multiply operation, can be run and using the flops count result the frequency of the CPU can be determined. Similarly, the cache size of the chips can be determined by measuring the performance of the matrix multiply with different matrix sizes. ..devices of same model can be distinguished by profiling power and/or temperature of a component or components on a device. For example, power and/or temperature of each core in the processor such as a central processing unit (CPU) and other components on the device such as graphics and memory units can be profiled. Such a profile can help to determine the manifested hardware manufacturing differences, [0025] a unique fingerprint can be calculated given power distribution profile of device components. Number of possible CPU combinations increase exponentially with number of cores: # Possible CPU Configurations=Power Variation.sup.Num Cores, [0026]) [ Examiner interprets that profiling power and/or temperature of each core in the processor such as a central processing unit (CPU) and other components on the device such as graphics and memory units, performance profiles etc., to create the fingerprint of respective user device as obtaining a plurality of attributes of said hardware device, wherein said plurality of attributes comprises a state of a central processing unit (CPU) or a graphics processing unit (GPU) of said hardware device];
a method for uniquely identifying a hardware device and processing, on said hardware device, said plurality of attributes with a first machine learning algorithm to generate a digital fingerprint of said hardware device, wherein said first machine learning algorithm comprises said plurality of decrypted parameters; and (Acun, when creating the fingerprint of the chip, a calibration may be performed depending on the environment temperature. ..dynamic power of the device, e.g., CPU, can change with the utilization depending on the activity level of the device during the profile time, the power fingerprint may be calibrated. Using measurements of power and temperature at a set of utilization values, a model fitting technique can be used to derive the constant values C, k.sub.1, k.sub.2, k.sub.3 in the model for a device, for example, for each device being considered, [0034] Measurement data of power (e.g., dynamic power) can be obtained, for example, by running an activity or function on a device. For example, a double precision general matrix multiplication (DGEMM) kernel or another compute function can be run calculate the active power of a device. ..This data can be collected from an environment with stable ambient temperature with the device allocated for that task only…. Data obtained from running a function or activity under such an environment on multiple devices shows that there can be power variation for all device components, e.g., with +/−3σ (standard variation)….measurement data of power provide battery status or how much energy is consumed per time or time period, for instance, average power consumption, [0035] static and dynamic power can be used as independent metrics for fingerprinting…the system and method can uniquely fingerprint or identify devices, which may have different device configurations with different power consumption and variation levels, [0036]) [ Examiner interprets that system having model fitting technique (i.e., ML technique such as regression) that utilizes device specific parameters such as power consumption data and temperature profiles (i.e. plurality of attributes) to derive constant in the model for each device and creates unique finger print as a method for uniquely identifying a hardware device and processing, on said hardware device, said plurality of attributes with a first machine learning algorithm to generate a digital fingerprint of said hardware device, wherein said first machine learning algorithm comprises said plurality of decrypted parameters]
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright to include a concept of obtaining a plurality of attributes of said hardware device, wherein said plurality of attributes comprises a state of a central processing unit (CPU) or a graphics processing unit (GPU) of said hardware device; a method for uniquely identifying a hardware device and processing, on said hardware device, said plurality of attributes with a first machine learning algorithm to generate a digital fingerprint of said hardware device, wherein said first machine learning algorithm comprises said plurality of decrypted parameters as taught by Acun for the purpose of creating a hardware fingerprint of a device such as mobile device to distinguish devices of different model, a performance profile [Acun:0025] and using measurements of power and temperature at a set of utilization values in a model fitting technique to derive the constant values C, k.sub.1, k.sub.2, k.sub.3 in the model for a device, to uniquely identify each respective device using their fingerprint [Acun:0034, 0036].
Wright and Acun does not explicitly teach:
wherein said digital fingerprint comprises at least two of: an agent-based fingerprint, a network-based fingerprint, a web rendering fingerprint, a cookie-based fingerprint, or an audio-based fingerprint; processing, on said remote server, at least said digital fingerprint of said hardware device and said plurality of attributes with a second machine learning algorithm to determine whether said hardware device has been previously identified
However, Shemesh teaches:
wherein said digital fingerprint comprises at least two of: an agent-based fingerprint, a network-based fingerprint, a web rendering fingerprint, a cookie-based fingerprint, or an audio-based fingerprint (Shemesh, The received client access request includes a cookie. In this example, the client access request is received from the client device 16(1). In step 304, the network traffic management apparatus 12 of the network traffic management system 10 determines if the received cookie is valid. The network traffic management apparatus 12 determines if the received cookie is valid based on the timestamp of the cookie, IP address associated with the cookie and the cryptography of the cookie. The network traffic management apparatus 12 determines if the timestamp associated with the cookie has expired in comparison to a predefined time threshold, by way of example, 15 minutes….. The network traffic management apparatus 12 determines if the cryptography associated with a key of the cryptography then the cookie is determined to be a valid cookie. If either one of the timestamp of the cookie, IP address associated with the cookie and the cryptography of the cookie fails the validation then the cookie is determined to be invalid and the method proceeds to step 306. When all three of the timestamp of the cookie, IP address associated with the cookie and the cryptography of the cookie are successfully validated then the cookie is determined to be valid and the method proceeds to step 318, (see col 10, lines 26-54) each fingerprint record, Fingerprint-1, Fingerprint-2 and Fingerprint-3 is a network identifier of the client device 16(1). The network identifier may include an IP address and/or MAC address associated with the requesting client device 16(1), (see col 11, lines 21-26) This matching to validate the client device 16(1) also helps in identifying that no other malicious entity has made the request by spoofing the client device network identifier over the network to determine any potential security threats and/or attacks, (see col 17, lines 63-67) The network traffic management apparatus 12 also checks a browser local storage of a browser associated with the client device 16(1) to collect fingerprint attributes and client device identifier (ID) of the requesting client device 16(1) stored in the browser local storage The collected client device ID is an encrypted identifier which is decrypted by the network traffic management apparatus 12 to determine the client device ID. A client device ID is an identifier assigned to each requesting client device 16(1) by the network traffic management apparatus 12. The client device ID associated with the requesting client device 16(1) is stored as a record or a Fingerprint in the fingerprint data storage stored in the memory, (see col 11, lines 1-14) one or more of the client devices 16(1)-16(n) can be configured to execute software code (e.g., JavaScript code within a web browser) in order to log client-side data and provide the logged data to the network traffic management apparatus 12, (see col 9, lines 32-36)). [Examiner interprets that incorporating cookie presence/ validity/ cryptography into the fingerprinting/authentication flow and IP/MAC/network identifier features, client-side agent/script collecting device data, JS/browser local storage collection and using these attributes to identify and track a device as cookie-based fingerprint, Network based fingerprint, and Agent based fingerprint];
processing, on said remote server, at least said digital fingerprint of said hardware device and said plurality of attributes with a second machine learning algorithm to determine whether said hardware device has been previously identified (Shemesh, the network traffic management system 10 collects fingerprint attributes associated with the client device 16(1) such as client device type, user profile information associated with the user of the client device 16(1), an application type utilized by the client device 16(1), and/or a web browser type utilized by the client device 16(1).. see (Col 10 , lines 55-62) in step 306 match to previously stored fingerprint attributes in the fingerprint database Table 1,The network traffic management apparatus 12 compares the collected fingerprint attributes of step 306 to the fingerprint attributes of stored device fingerprints, (Col 11 , lines 35-44) In step 310, the network traffic management system 10 determines if a learning algorithm is to be applied based on determining that the collected attributes match with a previously stored fingerprint attributes associated with a client device ID. Even though the there is a matching client device ID with the same attributes, the system administrator may still assign policies causing the network traffic management apparatus 12 to proceed to step 312 to apply a learning algorithm to further learn the results of the method….If the network traffic management apparatus 12 of the network traffic management system 10 determines that the learning algorithm is to be applied then the method proceeds to step 312 (Col 11 , lines 63-67, Col 12 lines 1-14)) [ Examiner interprets that the network traffic management system 10 collecting fingerprint attributes associated with the client device such as client device type, user profile information associated with the user of the client device etc., and matching client’s fingerprint with stored list of fingerprints to identify if the finger print is previously identified and further using learning algorithm to validate the result as processing, on said remote server, at least said digital fingerprint of said hardware device and said plurality of attributes with a second machine learning algorithm to determine whether said hardware device has been previously identified]
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright and Acun to include a concept of wherein said digital fingerprint comprises at least two of: an agent-based fingerprint, a network-based fingerprint, a web rendering fingerprint, a cookie-based fingerprint, or an audio-based fingerprint; processing, on said remote server, at least said digital fingerprint of said hardware device and said plurality of attributes with a second machine learning algorithm to determine whether said hardware device has been previously identified as taught by Shemesh for the purpose of comparing the collected fingerprint attributes to the fingerprint attributes of stored device fingerprints and matching them with the previously stored fingerprint attributes in the fingerprint database and applying a learning algorithm to further learn the results of the method [Shemesh: See Col 11, lines 38-67,Col 12, lines 1-13].
Regarding claim 24, Wright, Acun, and Shemesh teaches the method of claim 23, further comprising, prior to (c), executing a function on said CPU or said GPU of said hardware device through an application programming interface (API) of a web browser (Acun, a device may be profiled under workloads with different characteristics… mobile or a desktop device that is composed of multiple types of units that may have ICs ..To fingerprint such a device, …a system and/or method may run multiple software workloads on the device to profile the power consumption and performance characteristics of the device components. Different software workloads may be run on the device to analyze power and performance characteristics …these workloads can be run via an app (or application) installed on the device or through a browser page, or through another mechanism, [0043]) [Examiner interprets user device invoking any CPU/GPU workload through a browser page prior to creating digital fingerprint as prior to (c), executing a function on said CPU or said GPU of said hardware device through an application programming interface (API) of a web browser].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright to include a concept of executing a function on said CPU or said GPU of said hardware device through an application programming interface (API) of a web browser as taught by Acun for the purpose of running multiple software workloads on the device to profile the power consumption and performance characteristics of the device components to analyze power and performance characteristics via an app (or application) installed on the device or through a browser page, [Acun:0043]
Regarding claim 25, Wright, Acun, and Shemesh teaches the method of claim 24, further comprising, subsequent to executing said function, identifying said state of said CPU or said GPU (Acun, responsive to detecting that the device is connected, a web-service (or the computer) may trigger a code to execute on the device. Performance, power, temperature characteristics of the device while executing the code can be collected and the web-service may receive the data. The web-service may analyze the data and identify the number of components (e.g., core(s), memory device(s), processor(s)) in the device (e.g., an IC or chip of the device) by looking at the performance of a threaded code. For instance, core count or component count and frequency of the chip can be identified by observing the performance of a multi-threaded DGEMM-like benchmark (i.e., said state of said CPU or said GPU, [0045]) [ Examiner interprets that a web-service triggering a code to execute on the device in order to collect Performance, power, temperature characteristics of the device (i.e., state of said CPU or said GPU) for analyzing and identifying the number of components (e.g., core(s), memory device(s), processor(s)) in the device (e.g., an IC or chip of the device etc., as subsequent to executing said function, identifying said state of said CPU or said GPU].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright to include a concept of subsequent to executing said function, identifying said state of said CPU or said GPU as taught by Acun for the purpose of collecting performance, power, temperature characteristics of the device (i.e., state of said CPU or said GPU) for analyzing and identifying the number of components (e.g., core(s), memory device(s), processor(s)) in the device (e.g., an IC or chip of the device etc., [Acun:0045]
Regarding claim 26, Wright, Acun, and Shemesh teaches the method of claim 25, wherein said state of said CPU or said GPU comprises a state of a storage component of said CPU or said GPU (Acun, FIG. 1B shows combinations of a two-core CPU with five different power efficiency levels. In one aspect, this multiplicity may allow many different combinations of power efficiency so that it can be used to distinguish devices of the same model. ..power analysis can be used create fingerprints of same model devices, [0021] creating a hardware fingerprint of a device such as mobile device…To distinguish devices of different model, a performance profile can be sufficient. For example, a compute intensive kernel, e.g., a matrix multiply operation, can be run and using the flops count result the frequency of the CPU can be determined. Similarly, the cache size of the chips can be determined by measuring the performance of the matrix multiply with different matrix sizes. .. [0025] a unique fingerprint can be calculated given power distribution profile of device components. Number of possible CPU combinations increase exponentially with number of cores: # Possible CPU Configurations=Power Variation.sup.Num Cores, [0026]) [ Examiner interprets that profiling memory components such as Cache sizes, memory units of each core in the processor such as a central processing unit (CPU) and other components on the device such as graphics said state of said CPU or said GPU comprises a state of a storage component of said CPU or said GPU];
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright to include a concept of said state of said CPU or said GPU comprises a state of a storage component of said CPU or said GPU as taught by Acun for the purpose of profiling memory components such as Cache sizes, memory units of each core in the processor such as a central processing unit (CPU) and other components on the device [Acun:0025].
Regarding claim 27, Wright, Acun, and Shemesh teaches the method of claim 25, wherein said state of said CPU or said GPU comprises a state of a logic component of said CPU or said GPU (Acun, Processors may have variability in their power, operational frequency, and temperature. There may be different types of variations affecting microprocessors: e.g., environmental factors and physical factors…. Physical factors can occur while manufacturing of the chips due to the limitations in processing and masking resulting in different parametric values that are permanent. This permanent process variation is used as a fingerprint to identify devices. In one aspect, the decreasing size of Complementary Metal-Oxide-Semiconductor (CMOS) transistors and lower voltage thresholds for energy efficient chip design may cause manufacturing-related process variation, [0022] process variation may affect both static (or idle) and dynamic power of the chips due to, for example, different reasons: variations in leakage current and gate delays. Decreased device and interconnect dimensions may contribute to the first type of variation. For example, distribution of relatively small dopant ions may create differences in transistor threshold voltages which become significant as the device dimensions gets smaller, [0023]) [ Examiner interprets that physical variation in CPU or GPU of user device such as gate delays, leakage current (i.e., a state of a logic component of said CPU or said GPU) making every user device distinct to each other for creating unique fingerprint as said state of said CPU or said GPU comprises a state of a logic component of said CPU or said GPU].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright to include a concept of said state of said CPU or said GPU comprises a state of a logic component of said CPU or said GPU as taught by Acun for the purpose of profiling permanent process variation is used as a fingerprint to identify devices such as the decreasing size of Complementary Metal-Oxide-Semiconductor (CMOS) transistors and lower voltage thresholds for energy efficient chip design may cause manufacturing-related process variation [Acun:0022].
Regarding claim 28, Wright, Acun, and Shemesh teaches the method of claim 24, wherein said function is selected from the group consisting of a polynomial function, a random number generator, a matrix function, and a combination thereof (Acun, Measurement data of power (e.g., dynamic power) can be obtained, for example, by running an activity or function on a device. For example, a double precision general matrix multiplication (DGEMM) kernel or another compute function can be run calculate the active power of a device. Another function such as a benchmarking function or activity may be selected, [0035]) [Examiner interprets that measuring the data power of a user device by running compute function on a device such as double precision general matrix multiplication (DGEMM) kernel as said function is selected from the group consisting of a polynomial function, a random number generator, a matrix function, and a combination thereof].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright to include a concept of said function is selected from the group consisting of a polynomial function, a random number generator, a matrix function, and a combination thereof as taught by Acun for the purpose of measuring data of power (e.g., dynamic power) by running an activity or function on a device such as a double precision general matrix multiplication (DGEMM) kernel or another compute function to calculate the active power of a device [Acun:0035].
Regarding claim 30, Wright, Acun, and Shemesh teaches the method of claim 24, wherein said function comprises a physical unclonable function (Acun, perform a device identification based on manufacturing differences in device's components such as a processor, core, memory and/or others. For instance, complementary metal-oxide-semiconductor (CMOS) manufacturing differences in devices can be utilized to identify a device, [0018] A hardware fingerprinting method in one embodiment can use CMOS related hardware manufacturing as a fingerprint to identify devices. Hardware manufacturing differences manifest themselves as power variations among the same model hardware components such as processors, graphics cards and memory. These variations can be permanent and can be used as a fingerprint to identify unique devices…power measurement such as a battery status application programming interface (API) can enable a device to be uniquely identified based on the device's power and performance efficiency characteristics, [0019] Processors may have variability in their power, operational frequency, and temperature….Physical factors can occur while manufacturing of the chips due to the limitations in processing and masking resulting in different parametric values that are permanent. This permanent process variation is used as a fingerprint to identify devices. In one aspect, the decreasing size of Complementary Metal-Oxide-Semiconductor (CMOS) transistors and lower voltage thresholds for energy efficient chip design may cause manufacturing-related process variation, [0022]) [ Examiner interprets that using permanent CMOS power/voltage variation to create finger print as function comprises a physical unclonable function].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright to include a concept of said function comprises a physical unclonable function as taught by Acun for the purpose of performing a device identification based on manufacturing differences in device's components such as a processor, core, memory and/or others. For instance, complementary metal-oxide-semiconductor (CMOS) manufacturing differences in devices to identify a device, [Acun:00318].
Regarding claim 32, Wright, Acun, and Shemesh teaches the method of claim 23, wherein said plurality of attributes comprises an attribute of software running on said hardware device (Acun, power consumption data can be collected or obtained by running a benchmark activity such as a multi-threaded compute intensive benchmark. In one aspect, the core count and frequency of the device or chip (IC of the device) can be identified by observing the performance of a multi-threaded compute intensive benchmark. Power consumption, temperature and performance can be observed while running one or more benchmarks that stress each component of the device or chip such as a core, memory, GPU, and/or another processing unit. In one embodiment, to identify component count such as the number of cores, a parallel compute intensive application with various thread/process counts can be run, and the performance and/or execution time observed. For example, consider that on 1 thread (core), execution time is 100 seconds, on 2 threads (cores) it is expected to be 50 seconds, on 4 threads (cores) 25 seconds if four cores are available. By profiling an application performance, for instance, as described above, one can determine the core count. In one aspect, frequency may be determined similarly by measuring the floating-point operations per second (FLOPs), [0038] a system and method is as software running on a hardware processor. Such software can extract a fingerprint of a device using power consumption data of the device components such as cores, [0044]) [Examiner interprets that measuring the performance (FLOPs) of matrix multiply to identify core count and frequency as said plurality of attributes comprises an attribute of software running on said hardware device]
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright to include a concept of said plurality of attributes comprises an attribute of software running on said hardware device as taught by Acun for the purpose of profiling an application performance to determine the core count and frequency may by measuring the floating-point operations per second (FLOPs) [Acun:0038].
Regarding claim 33, Wright, Acun, and Shemesh teaches the method of claim 32, wherein said software comprises a web browser (Acun, components (such as CPU, GPU, memory, disk, and/or others) in a mobile device is used to profile their leakage and switching power and to create a digital fingerprint of the device using the power and performance characteristics. ..a device may be profiled under workloads with different characteristics. In one embodiment, a system and/or method may create a fingerprint of a mobile or a desktop device that is composed of multiple types of units that may have ICs. To fingerprint such a device, ..run multiple software workloads on the device to profile the power consumption and performance characteristics of the device components…different software workloads may be run on the device to analyze power and performance characteristics. …these workloads can be run via an app (or application) installed on the device or through a browser page, or through another mechanism. ..running of such apps on the device may be triggered from a system performing a fingerprint analysis. For instance, such a system may cause the running of a software workload, for example, to collect measurement data, [0043]) [Examiner interprets that system executing multiple software workloads an app (or application) installed on the device or through a browser page for performing a fingerprint analysis as said software comprises a web browser].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright to include a concept of said software comprises a web browser as taught by Acun for the purpose of creating a fingerprint of a mobile or a desktop device that is composed of multiple types of units that may have ICs by running multiple software workloads on the device to profile the power consumption and performance characteristics of the device components to analyze power and performance characteristics [Acun:0043].
Regarding claim 38, Wright, Acun, and Shemesh teaches the method of claim 23, further comprising, prior to (e), transmitting said digital fingerprint and said plurality of attributes to said remote server (Shemesh, the network traffic management system 10 (i.e., the remote server) collects fingerprint attributes associated with the client device 16(1) such as client device type, user profile information associated with the user of the client device 16(1), an application type utilized by the client device 16(1), and/or a web browser type utilized by the client device 16(1).. see (Col 10 , lines 55-62) in step 306 match to previously stored fingerprint attributes in the fingerprint database Table 1,The network traffic management apparatus 12 compares the collected fingerprint attributes of step 306 to the fingerprint attributes of stored device fingerprints, (Col 11 , lines 35-44))[ Examiner interprets that the network traffic management system 10 collecting fingerprint attributes associated with the client device such as client device type, user profile information associated with the user of the client device etc., as transmitting said digital fingerprint and said plurality of attributes to said remote server].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright and Acun to include a concept of prior to (e), transmitting said digital fingerprint and said plurality of attributes to said remote server as taught by Shemesh for the purpose of comparing the collected fingerprint attributes to the fingerprint attributes of stored device fingerprints and matching them with the previously stored fingerprint attributes in the fingerprint database and applying a learning algorithm to further learn the results of the method [Shemesh: See Col 11, lines 38-67,Col 12, lines 1-13].
Regarding claim 39, Wright, Acun, and Shemesh teaches the method of claim 38, wherein said second machine learning algorithm is configured to generate a score that indicates a similarity between said hardware device and a previously identified hardware device (Shemesh, in step 306 match to previously stored fingerprint attributes in the fingerprint database Table 1,The network traffic management apparatus 12 compares the collected fingerprint attributes of step 306 to the fingerprint attributes of stored device fingerprints, (Col 11 , lines 35-44) In step 310, the network traffic management system 10 determines if a learning algorithm is to be applied based on determining that the collected attributes match with a previously stored fingerprint attributes associated with a client device ID. Even though the there is a matching client device ID with the same attributes, the system administrator may still assign policies causing the network traffic management apparatus 12 to proceed to step 312 to apply a learning algorithm to further learn the results of the method….If the network traffic management apparatus 12 of the network traffic management system 10 determines that the learning algorithm is to be applied then the method proceeds to step 312 (Col 11 , lines 63-67, Col 12 lines 1-14)) [ Examiner interprets that the network traffic management system 10 comparing and matching client’s fingerprint with stored list of fingerprints to identify if the finger print is previously identified and further using learning algorithm to validate the result as said second machine learning algorithm is configured to generate a score that indicates a similarity between said hardware device and a previously identified hardware device].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright and Acun to include a concept of said second machine learning algorithm is configured to generate a score that indicates a similarity between said hardware device and a previously identified hardware device as taught by Shemesh for the purpose of comparing the collected fingerprint attributes to the fingerprint attributes of stored device fingerprints and matching them with the previously stored fingerprint attributes in the fingerprint database and applying a learning algorithm to further learn the results of the method [Shemesh: See Col 11, lines 38-67,Col 12, lines 1-13].
Regarding claim 40, Wright, Acun, and Shemesh teaches the method of claim 38, further comprising, responsive to determining that said hardware device has not been previously identified, generating a unique device identifier for said hardware device (Shemesh, When the network traffic management apparatus 12 determines that the attribute values of both of the highest ranked fingerprints, Fingerprint 1 and Fingerprint 2 do not match with the attribute values of any of the fingerprints from the list of stored fingerprints then the method takes the No branch to step 320. In step 320, the network traffic management apparatus 12 of the network traffic management system 10 creates an entry in a fingerprint database table with the collected fingerprint attributes. The network traffic management apparatus 12 updates the Table-1 for each of the fingerprint records, See (Col 13, lines 47-59) In step 322, the network traffic management apparatus 12 of the network traffic management system 10 creates an entry in the Table-2 inverse index table based on the attribute values stored in the fingerprint database table. The network traffic management apparatus 12 determines a uniqueness value associated with each of the attributes values based on the attribute values stored in the fingerprint database table, See (Col 13, lines 63-67, col 14 lines 1-2)) [Examiner interprets that system creating new entry for the finger print when it doesn’t match the potential lists of finger print in the table with its unique identifier or value as responsive to determining that said hardware device has not been previously identified, generating a unique device identifier for said hardware device].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright and Acun to include a concept of responsive to determining that said hardware device has not been previously identified, generating a unique device identifier for said hardware device as taught by Shemesh for the purpose of comparing the collected fingerprint attributes to the fingerprint attributes of stored device fingerprints and matching them with the previously stored fingerprint attributes in the fingerprint database and applying a learning algorithm to further learn the results of the method [Shemesh: See Col 11, lines 38-67,Col 12, lines 1-13].
Regarding claim 41, Wright, Acun, and Shemesh teaches the method of claim 23, wherein said second machine learning algorithm comprises a machine learning classifier (Shemesh, in step 306 match to previously stored fingerprint attributes in the fingerprint database Table 1,The network traffic management apparatus 12 compares the collected fingerprint attributes of step 306 to the fingerprint attributes of stored device fingerprints, (Col 11 , lines 35-44) In step 310, the network traffic management system 10 determines if a learning algorithm is to be applied based on determining that the collected attributes match with a previously stored fingerprint attributes associated with a client device ID. Even though the there is a matching client device ID with the same attributes, the system administrator may still assign policies causing the network traffic management apparatus 12 to proceed to step 312 to apply a learning algorithm to further learn the results of the method….If the network traffic management apparatus 12 of the network traffic management system 10 determines that the learning algorithm is to be applied then the method proceeds to step 312 (Col 11 , lines 63-67, Col 12 lines 1-14)) [ Examiner interprets that the network traffic management system 10 comparing and matching client’s fingerprint with stored list of fingerprints to identify if the finger print is previously identified and further using learning algorithm to validate the result and classifying the fingerprint as new or previously identified as said second machine learning algorithm comprises a machine learning classifier].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright and Acun to include a concept of wherein said second machine learning algorithm comprises a machine learning classifier as taught by Shemesh for the purpose of comparing the collected fingerprint attributes to the fingerprint attributes of stored device fingerprints and matching them with the previously stored fingerprint attributes in the fingerprint database and applying a learning algorithm to further learn the results of the method [Shemesh: See Col 11, lines 38-67,Col 12, lines 1-13].
Regarding claims 45 and 46, Claims 45 and 46 recite commensurate subject matter as claim 23. Therefore, they are rejected for the same reasons. Except the additional elements:
Acun further teaches:
A system comprising one or more computer processors and computer memory coupled thereto, wherein the computer memory comprises machine-executable code that, upon execution by the one or more computer processors, implements a method for uniquely identifying a hardware device (Acun, A system include at least one hardware processor coupled with a memory device…further operable to create a fingerprint of the device based on the at least one parameter, [0005])
A non-transitory computer-readable medium comprising machine-executable code that, upon execution by one or more computer processors, implements a method for uniquely identifying a hardware device (Acun, perform a device identification based on hardware manufacturing differences in a device, [0003] A computer readable storage medium storing a program of instructions executable by a machine to perform one or more methods, [0006])
Regarding claim 47, Wright, Acun, and Shemesh the method of claim 23, wherein said digital fingerprint comprises at least three of: an agent-based fingerprint, a network-based fingerprint, a web rendering fingerprint, a cookie-based fingerprint, or an audio-based fingerprint (Shemesh, The received client access request includes a cookie. In this example, the client access request is received from the client device 16(1). In step 304, the network traffic management apparatus 12 of the network traffic management system 10 determines if the received cookie is valid. The network traffic management apparatus 12 determines if the received cookie is valid based on the timestamp of the cookie, IP address associated with the cookie and the cryptography of the cookie. The network traffic management apparatus 12 determines if the timestamp associated with the cookie has expired in comparison to a predefined time threshold, by way of example, 15 minutes….. The network traffic management apparatus 12 determines if the cryptography associated with a key of the cryptography then the cookie is determined to be a valid cookie. If either one of the timestamp of the cookie, IP address associated with the cookie and the cryptography of the cookie fails the validation then the cookie is determined to be invalid and the method proceeds to step 306. When all three of the timestamp of the cookie, IP address associated with the cookie and the cryptography of the cookie are successfully validated then the cookie is determined to be valid and the method proceeds to step 318, (see col 10, lines 26-54) each fingerprint record, Fingerprint-1, Fingerprint-2 and Fingerprint-3 is a network identifier of the client device 16(1). The network identifier may include an IP address and/or MAC address associated with the requesting client device 16(1), (see col 11, lines 21-26) This matching to validate the client device 16(1) also helps in identifying that no other malicious entity has made the request by spoofing the client device network identifier over the network to determine any potential security threats and/or attacks, (see col 17, lines 63-67) The network traffic management apparatus 12 also checks a browser local storage of a browser associated with the client device 16(1) to collect fingerprint attributes and client device identifier (ID) of the requesting client device 16(1) stored in the browser local storage The collected client device ID is an encrypted identifier which is decrypted by the network traffic management apparatus 12 to determine the client device ID. A client device ID is an identifier assigned to each requesting client device 16(1) by the network traffic management apparatus 12. The client device ID associated with the requesting client device 16(1) is stored as a record or a Fingerprint in the fingerprint data storage stored in the memory, (see col 11, lines 1-14) one or more of the client devices 16(1)-16(n) can be configured to execute software code (e.g., JavaScript code within a web browser) in order to log client-side data and provide the logged data to the network traffic management apparatus 12, (see col 9, lines 32-36)). [Examiner interprets that incorporating cookie presence/ validity/ cryptography into the fingerprinting/authentication flow and IP/MAC/network identifier features, client-side agent/script collecting device data, JS/browser local storage collection and using these attributes to identify and track a device as cookie-based fingerprint, Network based fingerprint, and Agent based fingerprint].
Claim 29 is rejected under 35 U.S.C. 103 as being unpatentable over Wright (US 20210306139 A1) in view of Acun (US 20200265168 A1) in further view of Shemesh (US 10830863 B1) in further view of Green (US 20130120418 A1).
Regarding claim 29, Wright, Acun, and Shemesh teaches the method of claim 24,
Wright, Acun, and Shemesh does not explicitly teach:
wherein said function comprises a graphics rendering function
However, Green teaches:
wherein said function comprises a graphics rendering function (Green, plugin interface 120 may implement an API between web application 116 and plugin 108. For example, plugin interface 120 may carry out method calls to plug in 108 from web application 116 by executing code from plugin 108 corresponding to the methods called from web application 116. Such method calls may extend both the capabilities and processing power of web application 116 by providing web application 116 access to resources on computing system 102 through plugin 108, [0056] once graphics model 118 and the render command are obtained by plugin 108, plugin 108 may generate a GPU command stream from graphics model 118 and send the GPU command stream to GPU 106, [0060] rendering engine 210 may interface directly with the GPU by emitting hardware commands to registers and memory on the GPU. As a result, rendering engine 210 may execute one or more stages of a graphics pipeline using the GPU, including the use of fragment and/or pixel shaders in the graphics pipeline. On the other hand, if a GPU is unavailable for use by rendering engine 210, a software renderer 212 may be used by render thread 204 to render images corresponding to the graphics model using a CPU, [0070]) [Examiner interprets that web application calling into browser’s plugin API and plugin translating those calls into GPU command stream for rendering graphic images as said function comprises a graphics rendering function]
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright, Acun, and Shemesh to include a concept of said function comprises a graphics rendering function as taught by Green for the purpose of executing one or more stages of a graphics pipeline using the GPU, including the use of fragment and/or pixel shaders in the graphics pipeline [Green:0070]
Claim 31 is rejected under 35 U.S.C. 103 as being unpatentable over Wright (US 20210306139 A1) in view of Acun (US 20200265168 A1) in further view of Shemesh (US 10830863 B1) in further view of Edwards (US 20210279837 A1).
Regarding claim 31, Wright, Acun, and Shemesh teaches the method of claim 24,
Wright, Acun, and Shemesh does not explicitly teach:
wherein said plurality of attributes comprises a number of iterations of said function or a number of bytes allocated per iteration
However, Edwards teaches:
wherein said plurality of attributes comprises a number of iterations of said function or a number of bytes allocated per iteration (Edwards, scratch memory 102 stores data values used by one or more programs running on a PPU, such as a GPU, or other processing units ..scratch memory 102 stores data values in blocks, where each block is assigned an address for reference by one or more programs. …one or more programs are software programs containing instructions that, when executed, perform operations using a PPU, such as a GPU, or other processing unit …one or more software programs use an application programming interface (API) for parallel computation, such as compute unified device architecture (CUDA) or other APIs, [0051] one or more memory operations 112, 114, 116 are a search 114 operation…a search 114 operation is a sequence of software instructions that, when executed, find a region of memory in scratch memory 102 that can be allocated 112 by a CG 104, 106, 108, [0055] a bin is an organizational data structure in memory, such as scratch memory, that stores data for a cooperative group (CG) or other software program, bin's size is a function of said bin's level within a dynamic radix tree 300. ..a bin's size is 2.sup.(3+level*4) bytes., (i.e., a number of bytes allocated per iteration) [0058]) [Examiner interprets that system allocating exactly bin size of bytes per every allocation when function runs (i.e., search operation) or software instruction when executed in scratch memory 102 as said plurality of attributes comprises a number of iterations of said function or a number of bytes allocated per iteration].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright, Acun, and Shemesh to include a concept of plurality of attributes comprises a number of iterations of said function or a number of bytes allocated per iteration as taught by Edwards for the purpose of finding a search 114 operation (i.e., sequence of software instructions) that, when executed, find a region of memory in scratch memory 102 that can be allocated [Edward:0055].
Claim 34 is rejected under 35 U.S.C. 103 as being unpatentable over Wright (US 20210306139 A1) in view of Acun (US 20200265168 A1) in further view of Shemesh (US 10830863 B1) in further view of Quinlan (US 20140283061 A1).
Regarding claim 34, Wright, Acun, and Shemesh teaches the method of claim 32,
Wright, Acun, and Shemesh does not explicitly teach:
wherein said attribute of said software is selected from the group consisting of a user-agent string, a color depth, a memory, a CPU allocation, and a time zone
However, Quinlan teaches:
wherein said attribute of said software is selected from the group consisting of a user-agent string, a color depth, a memory, a CPU allocation, and a time zone (Quinlan, a fingerprint generated for a particular device may include data points relating to a number of attributes associated with the device, such as User Agent, HTTP_ACCEPT headers, browser plugin details, time zone of the device, screen size and color depth of a monitor of the device, installed system fonts, and whether or not cookies are enabled. In some examples, the fingerprint also includes a data point relating to the IP address of the device, [0020]).
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright, Acun, and Shemesh to include a concept of said attribute of said software is selected from the group consisting of a user-agent string, a color depth, a memory, a CPU allocation, and a time zone as taught by Quinlan for the purpose of generating a fingerprint for a particular device that include data points relating to a number of attributes associated with the device [Quinlan:0020].
Claim 35 and 48 are rejected under 35 U.S.C. 103 as being unpatentable over Wright (US 20210306139 A1) in view of Acun (US 20200265168 A1) in further view of Shemesh (US 10830863 B1) in further view of Zhang (US 20190362064 A1).
Regarding claim 35, Wright, Acun, and Shemesh teaches the method of claim 32,
Wright, Acun, and Shemesh does not explicitly teach:
wherein said plurality of attributes comprises an audio attribute comprising a parameter required to trigger an audio API
However, Zhang teaches:
wherein said plurality of attributes comprises an audio attribute comprising a parameter required to trigger an audio API (Zhang, The web server admits the attempted user when the 2FA response and one or more of: the speaker fingerprint, the microphone fingerprint, and the distance measurement, pass verification, [0068] the system transmit the 2FA response via acoustic signals emitted by the enrolled mobile phone's speaker and received by the login device's microphone. Note that login devices or web browsers executing thereon can access the login device's speaker and microphone via the standard Web Audio API. It uses OFDM-based acoustic signals to provide reliable service even in the event of severe channel conditions, [0070] Embodiments use high-frequency inaudible signals to avoid disturbing users and also exploit the fact that the high-frequency band is usually very quiet in various environments….Embodiments divide [18, 20] kHz into 20 non-overlapping sub-channels with each spanning 100 Hz. The OFDM sub-carrier frequencies are ƒ.sub.m=18+0.1 m kHz form∈[1, 20]…uses On-Off Keying as the modulation scheme for its simplicity, and the mobile phone generates the n-the (n≥1) time-domain sample, [0072] After receiving x.sub.n via its microphone, the login device/web-browser performs a Fast Fourier transform (FFT) to extract the amplitude of each sub-carrier signal component, denoted by I.sub.m for sub-carrier ƒ.sub.m. Since no signal is transmitted at 18 kHz, embodiments of the invention denote the signal amplitude detected at 18 kHz by I.sub.O and use it as a reference. The login device/web-browser then decodes X.sub.m by comparing I.sub.m with I.sub.O. If the difference between I.sub.m and I.sub.O exceeds a predefined system threshold (e.g., 10 dB in the experiments), X.sub.m is decoded as bit-1 and otherwise bit-0, [0074]) [ Examiner interprets that the system login devices or web browsers executing to access the login device's speaker and microphone via the standard Web Audio API and generating frequency parameter, amplitude parameter (i.e. Audio attributes) to configure in the web API to trigger the correct audio signal as said plurality of attributes comprises an audio attribute comprising a parameter required to trigger an audio API].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright, Acun, and Shemesh to include a concept of said plurality of attributes comprises an audio attribute comprising a parameter required to trigger an audio API as taught by Zhang for the purpose of using existing browser and mobile audio interferences to generate and capture device specific acoustic signals to enhance distinctiveness and reliability of hardware fingerprint [Zhang:0070].
Regarding claim 48, Wright, Acun, and Shemesh the method of claim 23, wherein said digital fingerprint comprises at least four of: an agent-based fingerprint, a network-based fingerprint, a web rendering fingerprint, a cookie-based fingerprint, or an audio-based fingerprint (Shemesh, The received client access request includes a cookie. In this example, the client access request is received from the client device 16(1). In step 304, the network traffic management apparatus 12 of the network traffic management system 10 determines if the received cookie is valid. The network traffic management apparatus 12 determines if the received cookie is valid based on the timestamp of the cookie, IP address associated with the cookie and the cryptography of the cookie. The network traffic management apparatus 12 determines if the timestamp associated with the cookie has expired in comparison to a predefined time threshold, by way of example, 15 minutes….. The network traffic management apparatus 12 determines if the cryptography associated with a key of the cryptography then the cookie is determined to be a valid cookie. If either one of the timestamp of the cookie, IP address associated with the cookie and the cryptography of the cookie fails the validation then the cookie is determined to be invalid and the method proceeds to step 306. When all three of the timestamp of the cookie, IP address associated with the cookie and the cryptography of the cookie are successfully validated then the cookie is determined to be valid and the method proceeds to step 318, (see col 10, lines 26-54) each fingerprint record, Fingerprint-1, Fingerprint-2 and Fingerprint-3 is a network identifier of the client device 16(1). The network identifier may include an IP address and/or MAC address associated with the requesting client device 16(1), (see col 11, lines 21-26) This matching to validate the client device 16(1) also helps in identifying that no other malicious entity has made the request by spoofing the client device network identifier over the network to determine any potential security threats and/or attacks, (see col 17, lines 63-67) The network traffic management apparatus 12 also checks a browser local storage of a browser associated with the client device 16(1) to collect fingerprint attributes and client device identifier (ID) of the requesting client device 16(1) stored in the browser local storage The collected client device ID is an encrypted identifier which is decrypted by the network traffic management apparatus 12 to determine the client device ID. A client device ID is an identifier assigned to each requesting client device 16(1) by the network traffic management apparatus 12. The client device ID associated with the requesting client device 16(1) is stored as a record or a Fingerprint in the fingerprint data storage stored in the memory, (see col 11, lines 1-14) one or more of the client devices 16(1)-16(n) can be configured to execute software code (e.g., JavaScript code within a web browser) in order to log client-side data and provide the logged data to the network traffic management apparatus 12, (see col 9, lines 32-36)). [Examiner interprets that incorporating cookie presence/ validity/ cryptography into the fingerprinting/authentication flow and IP/MAC/network identifier features, client-side agent/script collecting device data, JS/browser local storage collection and using these attributes to identify and track a device as cookie-based fingerprint, Network based fingerprint, and Agent based fingerprint].
Zhang further teaches:
audio based fingerprint (Zhang, identify a particular electronic device, such as a mobile communications device, based on a unique frequency response to audio communications exchanged with its speaker and/or its microphone, and application of such to automatically and securely respond to a multi-factor authentication request, [0003] a computer utilizes the unique speaker and/or microphone fingerprints that are inherent to the mobile device for authentication, [0029] a method for the login device to extract the speaker and/or microphone fingerprints of an enrolled mobile phone (also referred to herein as a prover phone) for comparison with stored copies of the speaker and/or microphone fingerprints, [0032] each speaker (or microphone) has a unique frequency response which measures the gain or attenuation at each frequency and can identify the mobile device in which the speaker or microphone is installed, [0081]) [Speaker /mic acoustic fingerprinting as audio based fingerprinting] Same motivation applies as claim 35].
Claim 36, 37, and 44 are rejected under 35 U.S.C. 103 as being unpatentable over Wright (US 20210306139 A1) in view of Acun (US 20200265168 A1) in further view of Shemesh (US 10830863 B1) in further view of Matsukawa (US 20210065731 A1).
Regarding claim 36, Wright, Acun, and Shemesh teaches the method of claim 23,
Wright, Acun, and Shemesh does not explicitly teach:
wherein said first machine learning algorithm comprises an unsupervised machine learning algorithm
However, Matsukawa teaches:
wherein said first machine learning algorithm comprises an unsupervised machine learning algorithm (Matsukawa, Fig 3A, the architecture 300 includes a generator (G) 302, a discriminator (D) 304, and a cost determination block 306. …the generator 302 may use any type of machine learning or other type of AI. For example, GAN may be used, which comprise a CNN-auto encoder and an RNN-auto encoder, [0032] a machine learning training phase is used to train a model to learn the type of noise that is to be removed from a subject signal. The real noise, such as a sample of the real noise, is used during the training phase so that the model can learn to identify and predict the noise. After the training phase, the model is used in actual use (or a test phase) to generate an estimate of the noise to be removed, which is used as a reference signal in a noise cancellation, removal, suppression, reduction, and/or source separation process, technique, technology, method, algorithm, scheme, etc. Any kind or type of cancellation, removal, suppression, reduction, and/or source separation process, technique, etc., may be used to subtract, cancel, remove, suppress, and/or otherwise reduce the noise from the subject signal, [0051]) [Examiner interprets that ML model such as CNN or RNN auto encoder inputting subject signals into the models to remove noise from the signal as said first machine learning algorithm comprises an unsupervised machine learning algorithm]
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright, Acun, and Shemesh to include a concept of wherein said first machine learning algorithm comprises an unsupervised machine learning algorithm as taught by Matsukawa for the purpose of generating an estimate of the noise to be removed, which is used as a reference signal in a noise cancellation, removal, suppression, reduction, and/or source separation process etc., from the subject signal [Matsukawa:0051].
Regarding claim 37, Wright, Acun, Shemesh and Matsukawa teaches the method of claim 36,
Wright, Acun, and Shemesh does not explicitly teach:
wherein said unsupervised machine learning algorithm comprises an autoencoder
However, Matsukawa teaches:
wherein said unsupervised machine learning algorithm comprises an autoencoder (Matsukawa, Fig 3A, the architecture 300 includes a generator (G) 302, a discriminator (D) 304, and a cost determination block 306. …the generator 302 may use any type of machine learning or other type of AI. For example, GAN may be used, which comprise a CNN-auto encoder and an RNN-auto encoder, [0032] a machine learning training phase is used to train a model to learn the type of noise that is to be removed from a subject signal. The real noise, such as a sample of the real noise, is used during the training phase so that the model can learn to identify and predict the noise. After the training phase, the model is used in actual use (or a test phase) to generate an estimate of the noise to be removed, which is used as a reference signal in a noise cancellation, removal, suppression, reduction, and/or source separation process, technique, technology, method, algorithm, scheme, etc. Any kind or type of cancellation, removal, suppression, reduction, and/or source separation process, technique, etc., may be used to subtract, cancel, remove, suppress, and/or otherwise reduce the noise from the subject signal, [0051]) [Examiner interprets that ML model such as CNN or RNN auto encoder inputting subject signals into the models to remove noise from the signal as said unsupervised machine learning algorithm comprises an autoencoder].
The motivation for claim 37 is same rationale as claim 36.
Regarding claim 44, Wright, Acun, and Shemesh teaches the method of claim 23,
Wright, Acun, and Shemesh does not explicitly teach:
wherein said first machine learning algorithm comprises a noise reduction algorithm
However, Matsukawa teaches:
wherein said first machine learning algorithm comprises a noise reduction algorithm (Matsukawa, Fig 3A, the architecture 300 includes a generator (G) 302, a discriminator (D) 304, and a cost determination block 306. …the generator 302 may use any type of machine learning or other type of AI. For example, GAN may be used, which comprise a CNN-auto encoder and an RNN-auto encoder, [0032] a machine learning training phase is used to train a model to learn the type of noise that is to be removed from a subject signal. The real noise, such as a sample of the real noise, is used during the training phase so that the model can learn to identify and predict the noise. After the training phase, the model is used in actual use (or a test phase) to generate an estimate of the noise to be removed, which is used as a reference signal in a noise cancellation, removal, suppression, reduction, and/or source separation process, technique, technology, method, algorithm, scheme, etc. Any kind or type of cancellation, removal, suppression, reduction, and/or source separation process, technique, etc., may be used to subtract, cancel, remove, suppress, and/or otherwise reduce the noise from the subject signal, [0051]) [Examiner interprets that ML model such as CNN or RNN auto encoder inputting subject signals into the models to remove noise from the signal as said first machine learning algorithm comprises a noise reduction algorithm].
The motivation for claim 44 is same rationale as claim 36.
Claim 42 is rejected under 35 U.S.C. 103 as being unpatentable over Wright (US 20210306139 A1) in view of Acun (US 20200265168 A1) in further view of Shemesh (US 10830863 B1) in further view of Akella (US 20210279565 A1).
Regarding claim 42, Wright, Acun, and Shemesh teaches the method of claim 23,
Wright, Acun, and Shemesh does not explicitly teach:
wherein said second machine learning algorithm comprises a clustering algorithm
However, Akella teaches:
wherein said second machine learning algorithm comprises a clustering algorithm (Akella , a network structure and associated weights hold information to identifying one or more computing devices. Group information is stored based on group definitions as learned normal behavior of a group a device belongs to. This could be represented in forms of average and standard deviation, or mode complex models like unsupervised clustering. Device composite fingerprint 710 includes all the features of each of device identity fingerprint 704, device group fingerprint 706, and device operational fingerprint 708. Device composite fingerprint 710 can be used to uniquely identify the corresponding computing device…are stored in a database such as database 102, [0114] a presence of one or more abnormal devices on the network which could potentially be hostile. In some embodiments, outputs from feature store 1716 are received by a device clustering 1730 that is configured to find clusters of devices which essentially means detecting groups of devices that behave similarly. This function is also used in group identity establishment. Outputs from device clustering 1730 are stored in ML output 1734. In some embodiments, ML output 1734 includes device hyper contexts for one or more computing devices, [0252]) [ Examiner interprets that system consisting unsupervised ML model consisting clustering algorithm to identify computing device that belongs to the particular group of cluster based on the fingerprint (i.e., behaving similarly) and features as said second machine learning algorithm comprises a clustering algorithm].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright, Acun, and Shemesh to include a concept of said second machine learning algorithm comprises a clustering algorithm as taught by Akella for the purpose of detecting groups of devices that behave similarly for group identity establishment by using a device clustering 1730 to find specific cluster where the specific device belongs [Akella:0252]
Claim 43 is rejected under 35 U.S.C. 103 as being unpatentable over Wright (US 20210306139 A1) in view of Acun (US 20200265168 A1) in further view of Shemesh (US 10830863 B1) in further view of Steffen (US 20190018903 A1).
Regarding claim 43, Wright, Acun, and Shemesh teaches the method of claim 23,
Wright, Acun, and Shemesh does not explicitly teach:
wherein said database is implemented via a web browser API
However, Steffen teaches:
wherein said database is implemented via a web browser API (Steffen, the method includes the steps of storing on an HTML5 local storage database on the client an ECMAScript file and a parameter from a web server of the website, [0008] At step 230, the script files specified from the web server will then be loaded via another AJAX request, into the HTML5 local storage database (i.e., said database). In other words, in this embodiment, the HTML5 local storage database is updated with the newer version number, i.e. from “1” to “2”. The filename can then be used as a key to store the content of the script file(s), [0038] At step 232, if the web server version number of the parameter from the <localversion number> tag matches the local version number stored on the HTML5 local storage database (e.g., the web server version number and the local version number are each “1”, for example), the script files will be retrieved from the HTML5 local storage database, [0039] At step 234, the ECMAScript file content is retrieved from the HTML5 local storage database and can be appended as ECMAScript code to the webpage. If the web browser used by the client doesn't support the HTML5 local storage database feature, the script can locate and link the files according to a previously known and understood method, [0040]) [Examiner interprets that the script using HTTP (AJAX) request to write the version number and script content into the HTML HTML5 local storage via the browser API when the server version is newer and reading them back out when the versions match as said database is implemented via a web browser API].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Funk to include a concept of said database is implemented via a web browser API as taught by Steffen for the purpose of storing on an HTML5 local storage database on the client an ECMAScript file and a parameter from a web server of the website [Steffen:0008].
Claim 49 are rejected under 35 U.S.C. 103 as being unpatentable over Wright (US 20210306139 A1) in view of Acun (US 20200265168 A1) in further view of Shemesh (US 10830863 B1) in further view of Zhang (US 20190362064 A1) in further view of Trunick (US 20210359993 A1).
Regarding claim 49, Wright, Acun, and Shemesh the method of claim 23, wherein said digital fingerprint comprises each of: an agent-based fingerprint, a network-based fingerprint, a web rendering fingerprint, a cookie-based fingerprint, or an audio-based fingerprint (Shemesh, The received client access request includes a cookie. In this example, the client access request is received from the client device 16(1). In step 304, the network traffic management apparatus 12 of the network traffic management system 10 determines if the received cookie is valid. The network traffic management apparatus 12 determines if the received cookie is valid based on the timestamp of the cookie, IP address associated with the cookie and the cryptography of the cookie. The network traffic management apparatus 12 determines if the timestamp associated with the cookie has expired in comparison to a predefined time threshold, by way of example, 15 minutes….. The network traffic management apparatus 12 determines if the cryptography associated with a key of the cryptography then the cookie is determined to be a valid cookie. If either one of the timestamp of the cookie, IP address associated with the cookie and the cryptography of the cookie fails the validation then the cookie is determined to be invalid and the method proceeds to step 306. When all three of the timestamp of the cookie, IP address associated with the cookie and the cryptography of the cookie are successfully validated then the cookie is determined to be valid and the method proceeds to step 318, (see col 10, lines 26-54) each fingerprint record, Fingerprint-1, Fingerprint-2 and Fingerprint-3 is a network identifier of the client device 16(1). The network identifier may include an IP address and/or MAC address associated with the requesting client device 16(1), (see col 11, lines 21-26) This matching to validate the client device 16(1) also helps in identifying that no other malicious entity has made the request by spoofing the client device network identifier over the network to determine any potential security threats and/or attacks, (see col 17, lines 63-67) The network traffic management apparatus 12 also checks a browser local storage of a browser associated with the client device 16(1) to collect fingerprint attributes and client device identifier (ID) of the requesting client device 16(1) stored in the browser local storage The collected client device ID is an encrypted identifier which is decrypted by the network traffic management apparatus 12 to determine the client device ID. A client device ID is an identifier assigned to each requesting client device 16(1) by the network traffic management apparatus 12. The client device ID associated with the requesting client device 16(1) is stored as a record or a Fingerprint in the fingerprint data storage stored in the memory, (see col 11, lines 1-14) one or more of the client devices 16(1)-16(n) can be configured to execute software code (e.g., JavaScript code within a web browser) in order to log client-side data and provide the logged data to the network traffic management apparatus 12, (see col 9, lines 32-36)). [Examiner interprets that incorporating cookie presence/ validity/ cryptography into the fingerprinting/authentication flow and IP/MAC/network identifier features, client-side agent/script collecting device data, JS/browser local storage collection and using these attributes to identify and track a device as cookie-based fingerprint, Network based fingerprint, and Agent based fingerprint].
Zhang further teaches:
audio based fingerprint (Zhang, identify a particular electronic device, such as a mobile communications device, based on a unique frequency response to audio communications exchanged with its speaker and/or its microphone, and application of such to automatically and securely respond to a multi-factor authentication request, [0003] a computer utilizes the unique speaker and/or microphone fingerprints that are inherent to the mobile device for authentication, [0029] a method for the login device to extract the speaker and/or microphone fingerprints of an enrolled mobile phone (also referred to herein as a prover phone) for comparison with stored copies of the speaker and/or microphone fingerprints, [0032] each speaker (or microphone) has a unique frequency response which measures the gain or attenuation at each frequency and can identify the mobile device in which the speaker or microphone is installed, [0081]) [Speaker /mic acoustic fingerprinting as audio based fingerprinting] Same motivation applies as claim 35].
Wright, Acun, Shemesh, and Zhang does not explicitly teach:
Web rendering based fingerprint
However, Trunick teaches:
Web rendering based fingerprint (Turnick, methods for identifying improved browser fingerprinting techniques that may be implemented to more effectively and efficiently identify computing devices with which a server or other entity may be communicating, [0004] storing browser fingerprints of the computing devices that visit a website or otherwise communicate online, [0016] browser fingerprinting may include collecting a browser type and version (e.g., Google Chrome, Microsoft Internet Explorer, Apple Safari, Mozilla Firefox, etc.), the operating system on which the browser may be running (e.g., Windows, Apple OS, Linux, etc.), active plugins on the browser, the time zone, the language, the screen resolution, the font, [0017] browser fingerprinting that may be referred to as canvas fingerprinting. In canvas fingerprinting, the programing code (e.g., Java, HTMLS, etc.) that is used to program a website or other online software may include code to determine the browser fingerprint for a particular computing device… he programing script may then initiate an application program interface (API), such as Canvas API's ToDataURL method, to which may return canvas pixel data in dataURL format…, [0018-0019] The computing devices 55a-e may generate data from the test, such as a device identifier, test ID, hash code, elapsed test time, browser settings, operating system, etc. At 108, 112, 116, 120, and 124, the computing devices 55a-e may transmit the test data to the testing server 85, which may receive the test data at 128, [0047] [Examiner interprets that generating fingerprint by collecting browser/device attributes such as browser type, version, OS, plugins, time zone, screen resolution, fonts, canvas (web rendering) fingerprinting in which a fingerprinting script causes a web browser to draw text/images using the device’s GPU/processor, extracting pixel data via canvas API, and hashes the pixel data to produce a hash value that is fingerprint and stored and used for comparison as web rendering fingerprint].
Therefore, it would have been obvious to PHOSITA before the effective filing date to modify the teaching of Wright, Acun, Shemesh, and Zhang to include a concept of web rendering fingerprint as taught by Turnick for the purpose of determine the browser fingerprint such as canvas fingerprint for a particular computing device [Turnick:0018-0019].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 8954560 B2: “directed to fingerprinting a remote computing device in stages using information retrievable from a web browser”
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMIKSHYA POUDEL whose telephone number is (703)756-1540. The examiner can normally be reached 7:30 AM - 5PM Mon- Fri.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SHEWAYE GELAGAY can be reached at (571)272-4219. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/S.N.P./Examiner, Art Unit 2436
/TRONG H NGUYEN/Primary Examiner, Art Unit 2436