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 Amendment
The amendment filed on 09/30/2025 has been accepted and considered in this office action. Claims 1 and 9 have been amended. Claims 7-8 and 15-16 have been cancelled. No new claims have been added.
Response to Arguments
Applicant’s arguments, See Remarks, filed on 09/30/2025, with respect to the amended limitations have been fully considered and are persuasive. However, upon further consideration, a new ground of rejection is made in view of discovery of new prior Sangle-Ferriere (US 20200351100 A1) in view of Driscoll (US20210075620A1) in view of Su (US 10447483 B1) in view of Vidal (US 20110296393 A1) as set forth below.
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
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.
Claim(s) 1-6 and 9-14 are rejected under 35 U.S.C. 103 as being unpatentable over Sangle-Ferriere (US 20240250826 A1) in view of Driscoll (US 20210075620 A1) in view of Su (US 10447483 B1) further in view of Vidal (US 20110296393 A1).
Regarding Claim 1, Sangle-Ferriere teaches:
A system (100) comprising: first processing circuitry (112) configured to: (i) generate a first hash sum using first information and second information; (Sangle-Ferriere, para 208, discloses the software distributor A carries out a random hashing of a software package to be transmitted to client B; para 198, Sangle-Ferriere also discloses that random hashing is the operation of mixing a datum with a random mixer number followed by the hashing operation.)
(ii) generate an encrypted string using the second information, the first hash sum;
(Sangle-Ferriere, para 209, discloses encrypting random number and the random hash which is the mixing of a datum with a random mixer number followed by the hashing operation.)
and second processing circuitry (122) configured to (i) receive the encrypted string and the first information from the first processing circuitry (112); (Sangle-Ferriere, para 210, discloses that the software distributor A sends a dataset containing the software package, the encrypted hash of the software package and the encrypted random number to the client B.)
(ii) extract a third information, a second hash sum using the encrypted string, wherein the second hash sum is equal to the first hash sum; (Sangle-Ferriere, para 211, discloses that Client B performs decryption to recover the hash and the random number; para 77, 78, Sangle-Ferriere also discloses the purpose of the mechanism is to detect any alteration or changes by unauthorized third party. This implies that the extracted hash should be identical to the previous hash value.)
(iii) generate a third hash sum using third information and first information; (Sangle-Ferriere, para 211, 212, 213, discloses rehashing (steps 803 and 804 are re-executed at programmed time intervals) using the random number and package data, Sangle-Ferriere discloses that the random number and the package data are reused to reconstruct a hash for comparison)
(iv) compare the third hash sum with the second hash sum, and (v) generate an initiation signal based on the comparison; (Sangle-Ferriere, para 212, discloses if the computed hash is identical to the received hash, the Client B permits the execution of the received software package with the version that it just received.)
Sangle-Ferriere does not explicitly teach; However, Driscoll teaches:
(i) determine a transaction time based on the second timestamp and (ii) compare the transaction time with a predefined threshold value (Driscoll, para 90 discloses the processing circuitry is also configured to determine that the second message was received within an acceptable time window and determine that the second message is authentic in response to determining that the hashed element matches the first element of the hash chain);
wherein, when the transaction time is less than the predefined threshold value, the second processing circuitry (122) is configured to generate an acknowledgement signal, transmit the acknowledgement signal to the first processing circuitry (112) (Driscoll, para 90 discloses that if the message was received within an acceptable time window then the message is determined to be authentic; para 36, Driscoll implies if the authentication code arrives within the acceptable time window would allow unlocking the door. This implies a signal to allow unlocking the door has been sent.);
and wherein, when the transaction time is greater than or equal to the predefined threshold value, the second processing circuitry (122) is configured to (i) generate a first alert signal, (ii) transmit the first alert signal to the first processing circuitry (112) (Driscoll, para 24 discloses if the received message 152 is not within the acceptable time window, processing circuitry 122 can discard message 152 or notify other receivers that message 152 is not authentic.);
(iii) discard the transaction from the first processing circuitry (112) (Driscoll, para 24 discloses if the received message 152 is not within the acceptable time window, processing circuitry 122 can discard message 152 or notify other receivers that message 152 is not authentic.);
It would have been obvious to a person having ordinary skill in the art to modify Sangle-Ferriere’s system to incorporate Driscoll’s teachings to determine whether a received message was received within an acceptable time window based on a timestamp. Driscoll teaches determining that a message is authentic only if it is received within a predetermined time window and discarding or rejecting messages that fall outside that window to mitigate replay or delayed-message attacks. One would be motivated to perform such modification on Sangle-Ferriere’s system to enhance secure message handling and ensuring that messages are not only cryptographically correct but also timely, thereby reducing the risk of replay, delayed delivery, or man-in-the-middle attacks.
Driscoll does not explicitly teach; However, Su teaches:
wherein, when the third hash sum is mismatched with the second hash sum, the initiation signal enables the second processing circuitry (122) to
(i) generate a second alert signal,
(ii) transmit the second alert signal to the first processing circuitry (112), and
(iii) discard the transaction from the first processing circuitry (112)
(Su, Col 17, lines 28-56 discloses if the first and second hash values do not match,
the verification component 142 can determine that the received firmware update file was corrupted or altered, either accidentally or maliciously, and can prevent installation of the firmware update file on the digital hardware component 156. The verification component 142 can further provide a notification or alert to the data processing system 102 of the detected corruption or alteration and discard, delete or remove the received firmware update)
It would have been obvious to a person having ordinary skill in the art to modify Sangle-Ferriere’s system to incorporate Su’s teachings to handle a hash mismatch condition by generating an alert, transmitting the alert and discarding the received update. Su teaches that when computed hash value do not match, the system can determine that the received data has been corrupted or altered and in response, generate an alert and prevent further processing by discarding the received data. One would be motivated to perform such modification on Sangle-Ferriere’s system to enhance secure message handling and ensures that potentially corrupted or malicious data is immediately identified and prevented from propagating further in the system.
Butler/Driscoll/Su does not explicitly teach; However, Vidal teaches:
Wherein the first information comprises a package name (Vidal, para 15 discloses performing hash using package names, process or application names, version numbers, package dates and/or other package attributes or data.);
Wherein the second information comprises a first identifier (Vidal, para 15 discloses performing hash using package names, process or application names, version numbers, package dates and/or other package attributes or data.);
Wherein the third information comprises a second identifier (Vidal, para 15 discloses performing hash using package names, process or application names, version numbers, package dates and/or other package attributes or data.);
It would have been obvious to a person having ordinary skill in the art to modify Sangle-Ferriere’s system to incorporate Vidal’s teachings of using package names and related identifiers like version number and other attributes that may be hashed to generate an encoded identifier. One would be motivated to perform such modification on Sangle-Ferriere’s system to apply the hash computation to package-identifying information as a predicable design choice for identifying and validating package-based transactions or requests, thereby improving applicability of Sangle-Ferriere’s verification mechanism to package centric transaction scenarios.
Regarding Claim 2, Butler/Kuperman/Driscoll/Su/Vidal teaches the system (100) as claimed in claim 1,
Butler teaches:
wherein, prior to the generation of the first hash sum, the first processing circuitry (112) is configured to determine the first information, the second information (Butler, para 89 discloses digital asset ownership validation program 301 generates a liveness hash based on the image and nonce, such as liveness hash=sha256(sha256(image)∥ nonce).);
Butler does not explicitly teach determining the first timestamp; However, Kuperman teaches:
wherein, prior to the generation of the first hash sum, the first processing circuitry (112) is configured to determine the first identifier, the first timestamp, that are associated with a request to a transaction from the first processing circuitry (112) to the second processing circuitry (122) (Kuperman, para 77 discloses SDK determining the attributes for the token including UID and timestamp which are associated with the API request before using the hash function before the proxy receives the API request.)
It would have been obvious to a person having ordinary skill in the art to modify Butler’s system to incorporate Kuperman’s teachings of determining a timestamp prior to hash generation. Kuperman teaches determining a timestamp associated with an API request prior to generating a hash and incorporate that timestamp into cryptographic processing to ensure that the resulting token is bound to a specific time of issuance. One would be motivated to perform such modification on Butler’s system to strengthen transaction validation by binding hash to the time and identifier which would improve security against replay and delayed-delivery attacks and improve transaction integrity and temporal verification.
Butler/Driscoll/Su does not explicitly teach; However, Vidal teaches:
Wherein the first information comprises a package name (Vidal, para 15 discloses performing hash using package names, process or application names, version numbers, package dates and/or other package attributes or data.);
Wherein the second information comprises a first identifier (Vidal, para 15 discloses performing hash using package names, process or application names, version numbers, package dates and/or other package attributes or data.);
It would have been obvious to a person having ordinary skill in the art to modify Butler’s system to incorporate Vidal’s teachings of using package names and related identifiers like version number and other attributes that may be hashed to generate an encoded identifier. One would be motivated to perform such modification on Butler’s system to apply the hash computation to package-identifying information as a predicable design choice for identifying and validating package-based transactions or requests, thereby improving applicability of Butler’s verification mechanism to package centric transaction scenarios.
Regarding Claim 3, Butler/Kuperman/Driscoll/Su/Vidal teaches the system (100) as claimed in claim 1,
Butler teaches:
wherein, to generate the first hash sum, the first processing circuitry (112) is configured to
(i) combine the first information and the second information to generate first combined data and
(ii) perform hashing of the first combined data using a hashing technique. (Butler, para 89 discloses digital asset ownership validation program 301 generates a liveness hash based on the image and nonce, such as liveness hash=sha256(sha256(image)∥ nonce).)
Butler/Driscoll/Su does not explicitly teach; However, Vidal teaches:
Wherein the first information comprises a package name (Vidal, para 15 discloses performing hash using package names, process or application names, version numbers, package dates and/or other package attributes or data.);
Wherein the second information comprises a first identifier (Vidal, para 15 discloses performing hash using package names, process or application names, version numbers, package dates and/or other package attributes or data.);
It would have been obvious to a person having ordinary skill in the art to modify Butler’s system to incorporate Vidal’s teachings of using package names and related identifiers like version number and other attributes that may be hashed to generate an encoded identifier. One would be motivated to perform such modification on Butler’s system to apply the hash computation to package-identifying information as a predicable design choice for identifying and validating package-based transactions or requests, thereby improving applicability of Butler’s verification mechanism to package centric transaction scenarios.
Regarding Claim 4, Butler/Kuperman/Driscoll/Su/Vidal teaches the system (100) as claimed in claim 1,
Butler/Driscoll/Su/Vidal does not explicitly teach, However Kuperman teaches:
wherein, to generate the encrypted string, the first processing circuitry (112) is configured to
(i) combine the first identifier, the first hash sum, and the timestamp to generate second combined data and (ii) encrypt the second combined data using a cryptography technique. (Kuperman, para 77 discloses generating encrypted token encrypting "UID:Timestamp:Hash" string.)
It would have been obvious to a person having ordinary skill in the art to modify Butler/Driscoll/Su/Vidal’s system to incorporate Kuperman’s teachings of generating an encrypted token by combining an identifier, a timestamp and a hash value into a single data structure (e.g., UID:Timestamp:Hash) and encrypting that combined data to securely transmit credentials. Kuperman further teaches that encrypting the combined data protects the confidentiality of the identifier and hash and ensures that the receiving entity can securely extract and verify the contents. One would be motivated to perform such modification on Butler/Driscoll/Su/Vidal’s system to improve security of transaction handling, with improved confidentiality and integrity of credentials.
Regarding Claim 5, Butler/Kuperman/Driscoll/Su/Vidal teaches the system (100) as claimed in claim 1,
Butler/Driscoll/Su/Vidal does not explicitly teach, However Kuperman teaches:
wherein, to extract the second identifier, the second hash sum, and the second timestamp, the second processing circuitry (122) is configured to
(i) decrypt the encrypted string using the cryptography technique to generate third combined data and (ii) segregate the third combined data into the second identifier, the second hash sum, and the second timestamp. (Kuperman, para 78 discloses that the proxy decrypts the encrypted token inherently extracting UID:Timestamp:Hash; Kuperman, further discloses that, upon decryption, the proxy inherently extracts the UID, timestamp and the hash from the decrypted token in order to perform verification.)
It would have been obvious to a person having ordinary skill in the art to modify Butler/Driscoll/Su/Vidal’s system to incorporate Kuperman’s teachings of decrypting an encrypted token at the receiving entity and, upon decryption, inherently extracting the individual components of the token, including the UID, timestamp and hash value in order to perform authentication and verification. One would be motivated to perform such modification on Butler/Driscoll/Su/Vidal’s system to strengthen secure message handling, reducing ambiguity in how the verification data is extracted from encrypted transmission, and ensuring security check operates on correctly isolated data elements.
Regarding Claim 6, Butler/Kuperman/Driscoll/Su/Vidal teaches the system (100) as claimed in claim 1,
Butler teaches:
wherein, to generate the third hash sum, the second processing circuitry (122) is configured to
(i) combine the third information and the first information to generate fourth combined data and
(ii) perform hashing of the fourth combined data using the hashing technique. (Butler, para 82 discloses that the smart contract decrypts the digital asset (A) and computes a liveness hash H′ using the digital asset and the nonce. Butler discloses that the liveness hash is generated by hashing the combined data elements (e.g., digital asset and nonce) using a hashing technique such as SHA-256.)
Butler/Driscoll/Su does not explicitly teach; However, Vidal teaches:
Wherein the first information comprises a package name (Vidal, para 15 discloses performing hash using package names, process or application names, version numbers, package dates and/or other package attributes or data.);
Wherein the third information comprises a second identifier (Vidal, para 15 discloses performing hash using package names, process or application names, version numbers, package dates and/or other package attributes or data.);
It would have been obvious to a person having ordinary skill in the art to modify Butler’s system to incorporate Vidal’s teachings of using package names and related identifiers like version number and other attributes that may be hashed to generate an encoded identifier. One would be motivated to perform such modification on Butler’s system to apply the hash computation to package-identifying information as a predicable design choice for identifying and validating package-based transactions or requests, thereby improving applicability of Butler’s verification mechanism to package centric transaction scenarios.
Regarding Claim 9, Butler teaches:
A method (400) comprising: generating, by way of first processing circuitry (112), a first hash sum using a first information and a second information (Butler, para 89 discloses digital asset ownership validation program 301 generates a liveness hash based on the image and nonce, such as liveness hash=sha256(sha256(image)∥ nonce).);
receiving, by way of second processing circuitry (122), the encrypted string and the first information from the first processing circuitry (112) (Butler, para 81 discloses the smart contract 330 receives encrypted digital asset, nonce, and liveness hash.);
generating, by way of the second processing circuitry (122), a third hash sum using the third information and the first information (Butler, para 82 discloses smart contract 330 decrypts digital asset (A), computes a liveness hash H′.);
comparing, by way of the second processing circuitry (122), the third hash sum with the second hash sum; (Butler, para 82 discloses comparing the hash values H==H');
and generating an initiation signal based on the comparison; wherein, when the third hash sum matches with the second hash sum, enabling, the second processing circuitry (122) by way of the initiation signal (Butler, para 92 discloses that digital asset ownership validation program 301 validates ownership if the second liveness hash matches the liveness hash of the image and the nonce.);
Butler, para 81 teaches the smart contract 330 receives encrypted digital asset, nonce, and liveness hash.
Butler, para 82 discloses smart contract 330 decrypts digital asset (A); para 81, Butler discloses the smart contract receives the liveness hash which is the exact hash generated and sent, so it inherently is the same hash.
Butler does not explicitly teach; However, Kuperman teaches:
generating, by way of the first processing circuitry (112), an encrypted string using the first identifier, the first hash sum, and a first timestamp; (Kuperman, para 77 discloses generating encrypted token encrypting "UID:Timestamp:Hash" string);
extracting, by way of the second processing circuitry (122), a second identifier, a second hash sum, and a second timestamp using the encrypted string, wherein the second hash sum is equal to the first hash sum (Kuperman, para 78 discloses that the proxy decrypts the encrypted token inherently extracting UID:Timestamp:Hash; Kuperman further discloses that if the hash matches, the token may be verified and client may be authenticated.);
Kuperman, para 48 also discloses that if the timestamp is not approximately current (within a threshold) with the current time of the token verifier 217, the token verifier 217 may fail verification of the token (e.g., token has expired);
It would have been obvious to a person having ordinary skill in the art to modify Butler’s system to incorporate Kuperman’s teachings of generating and encrypting a token that includes an identifier, a hash value and a timestamp. One would be motivated to perform such modification on Butler’s system to enhance transaction handling by binding the cryptographically verified digital asset and identifier to a specific timestamp, thereby preventing reuse of otherwise valid encrypted data outside the time window. This modification would improve resistance to replay and delayed-delivery attacks.
Kuperman does not explicitly teach; However, Driscoll teaches:
(i) determining a transaction time based on the second timestamp and (ii) comparing the transaction time with a predefined threshold value (Driscoll, para 90 discloses the processing circuitry is also configured to determine that the second message was received within an acceptable time window and determine that the second message is authentic in response to determining that the hashed element matches the first element of the hash chain);
wherein, when the transaction time is less than the predefined threshold value, generating, by way of the second processing circuitry (122), an acknowledgement signal and transmitting, by way of the second processing circuitry (122) the acknowledgement signal to the first processing circuitry (112) and enabling, by way of the second processing circuitry (122) the transaction from the first processing circuitry (112) (Driscoll, para 90 discloses that if the message was received within an acceptable time window then the message is determined to be authentic; para 36, Driscoll implies if the authentication code arrives within the acceptable time window would allow unlocking the door. This implies a signal to allow unlocking the door has been sent.);
wherein, when the transaction time is greater than or equal to the predefined threshold value (a) generating, by way of the second processing circuitry (122), a first alert signal, (b) transmitting, by way of the second processing circuitry (122), the first alert signal to the first processing circuitry (112), and (Driscoll, para 24 discloses if the received message 152 is not within the acceptable time window, processing circuitry 122 can discard message 152 or notify other receivers that message 152 is not authentic.);
(iii) discarding, by way of the second processing circuitry (122), the transaction from the first processing circuitry (112); (Driscoll, para 24 discloses if the received message 152 is not within the acceptable time window, processing circuitry 122 can discard message 152 or notify other receivers that message 152 is not authentic.);
It would have been obvious to a person having ordinary skill in the art to modify Butler’s system to incorporate Driscoll’s teachings to determine whether a received message was received within an acceptable time window based on a timestamp. Driscoll teaches determining that a message is authentic only if it is received within a predetermined time window and discarding or rejecting messages that fall outside that window to mitigate replay or delayed-message attacks. One would be motivated to perform such modification on Butler’s system to enhance secure message handling and ensuring that messages are not only cryptographically correct but also timely, thereby reducing the risk of replay, delayed delivery, or man-in-the-middle attacks.
Driscoll does not explicitly teach; However, Su teaches:
wherein, when the third hash sum is mismatched with the second hash sum, enabling, the second processing circuitry (122), by way of the initiation signal for
(i) generating a second alert signal,
(ii) transmitting the second alert signal to the first processing circuitry (112), and
(iii) discarding the transaction from the first processing circuitry (112)
(Su, Col 17, lines 28-56 discloses if the first and second hash values do not match,
the verification component 142 can determine that the received firmware update file was corrupted or altered, either accidentally or maliciously, and can prevent installation of the firmware update file on the digital hardware component 156. The verification component 142 can further provide a notification or alert to the data processing system 102 of the detected corruption or alteration and discard, delete or remove the received firmware update)
It would have been obvious to a person having ordinary skill in the art to modify Butler’s system to incorporate Su’s teachings to handle a hash mismatch condition by generating an alert, transmitting the alert and discarding the received update. Su teaches that when computed hash value do not match, the system can determine that the received data has been corrupted or altered and in response, generate an alert and prevent further processing by discarding the received data. One would be motivated to perform such modification on Butler’s system to enhance secure message handling and ensures that potentially corrupted or malicious data is immediately identified and prevented from propagating further in the system.
Butler/Driscoll/Su does not explicitly teach; However, Vidal teaches:
Wherein the first information comprises a package name (Vidal, para 15 discloses performing hash using package names, process or application names, version numbers, package dates and/or other package attributes or data.);
Wherein the second information comprises a first identifier (Vidal, para 15 discloses performing hash using package names, process or application names, version numbers, package dates and/or other package attributes or data.);
Wherein the third information comprises a second identifier (Vidal, para 15 discloses performing hash using package names, process or application names, version numbers, package dates and/or other package attributes or data.);
It would have been obvious to a person having ordinary skill in the art to modify Butler’s system to incorporate Vidal’s teachings of using package names and related identifiers like version number and other attributes that may be hashed to generate an encoded identifier. One would be motivated to perform such modification on Butler’s system to apply the hash computation to package-identifying information as a predicable design choice for identifying and validating package-based transactions or requests, thereby improving applicability of Butler’s verification mechanism to package centric transaction scenarios.
Regarding Claim 10, Butler/Kuperman/Driscoll/Su/Vidal teaches the method (400) as claimed in claim 9,
Butler teaches:
wherein, prior to generating the first hash sum, the method (400) comprising, determining, by way of the first processing circuitry (112), the first information, the second information (Butler, para 89 discloses digital asset ownership validation program 301 generates a liveness hash based on the image and nonce, such as liveness hash=sha256(sha256(image)∥ nonce).);
Butler does not explicitly teach determining the first timestamp; However, Kuperman teaches:
wherein, prior to generating the first hash sum, the method (400) comprising, determining, by way of the first processing circuitry (112), the first identifier, the first timestamp, that are associated with a request to a transaction from the first processing circuitry (112) to the second processing circuitry (122) (Kuperman, para 77 discloses SDK determining the attributes for the token including UID and timestamp which are associated with the API request before using the hash function before the proxy receives the API request.)
It would have been obvious to a person having ordinary skill in the art to modify Butler’s system to incorporate Kuperman’s teachings of determining a timestamp prior to hash generation. Kuperman teaches determining a timestamp associated with an API request prior to generating a hash and incorporate that timestamp into cryptographic processing to ensure that the resulting token is bound to a specific time of issuance. One would be motivated to perform such modification on Butler’s system to strengthen transaction validation by binding hash to the time and identifier which would improve security against replay and delayed-delivery attacks and improve transaction integrity and temporal verification.
Butler/Driscoll/Su does not explicitly teach; However, Vidal teaches:
Wherein the first information comprises a package name (Vidal, para 15 discloses performing hash using package names, process or application names, version numbers, package dates and/or other package attributes or data.);
Wherein the second information comprises a first identifier (Vidal, para 15 discloses performing hash using package names, process or application names, version numbers, package dates and/or other package attributes or data.);
It would have been obvious to a person having ordinary skill in the art to modify Butler’s system to incorporate Vidal’s teachings of using package names and related identifiers like version number and other attributes that may be hashed to generate an encoded identifier. One would be motivated to perform such modification on Butler’s system to apply the hash computation to package-identifying information as a predicable design choice for identifying and validating package-based transactions or requests, thereby improving applicability of Butler’s verification mechanism to package centric transaction scenarios.
Regarding Claim 11, Butler/Kuperman/Driscoll/Su/Vidal teaches the method (400) as claimed in claim 9,
Butler teaches:
wherein, for generating the first hash sum, the method (400) comprising (i) combining, by way of the first processing circuitry (112), the first information and the second information to generate first combined data and (ii) hashing, by way of the first processing circuitry (112), the first combined data using a hashing technique. (Butler, para 89 discloses digital asset ownership validation program 301 generates a liveness hash based on the image and nonce, such as liveness hash=sha256(sha256(image)∥ nonce).)
Butler/Driscoll/Su does not explicitly teach; However, Vidal teaches:
Wherein the first information comprises a package name (Vidal, para 15 discloses performing hash using package names, process or application names, version numbers, package dates and/or other package attributes or data.);
Wherein the second information comprises a first identifier (Vidal, para 15 discloses performing hash using package names, process or application names, version numbers, package dates and/or other package attributes or data.);
It would have been obvious to a person having ordinary skill in the art to modify Butler’s system to incorporate Vidal’s teachings of using package names and related identifiers like version number and other attributes that may be hashed to generate an encoded identifier. One would be motivated to perform such modification on Butler’s system to apply the hash computation to package-identifying information as a predicable design choice for identifying and validating package-based transactions or requests, thereby improving applicability of Butler’s verification mechanism to package centric transaction scenarios.
Regarding Claim 12, Butler/Kuperman/Driscoll/Su/Vidal teaches the method (400) as claimed in claim 9,
Butler/Driscoll/Su/Vidal does not explicitly teach, However Kuperman teaches:
wherein, for generating the encrypted string, the method (400) comprising (i) combining, by way of the first processing circuitry (112), the first identifier, the first hash sum, and the timestamp to generate second combined data and (ii) encrypting, by way of the first processing circuitry (112), the second combined data using a cryptography technique. (Kuperman, para 77 discloses generating encrypted token encrypting "UID:Timestamp:Hash" string.)
It would have been obvious to a person having ordinary skill in the art to modify Butler/Driscoll/Su/Vidal’s system to incorporate Kuperman’s teachings of generating an encrypted token by combining an identifier, a timestamp and a hash value into a single data structure (e.g., UID:Timestamp:Hash) and encrypting that combined data to securely transmit credentials. Kuperman further teaches that encrypting the combined data protects the confidentiality of the identifier and hash and ensures that the receiving entity can securely extract and verify the contents. One would be motivated to perform such modification on Butler/Driscoll/Su/Vidal’s system to improve security of transaction handling, with improved confidentiality and integrity of credentials.
Regarding Claim 13, Butler/Kuperman/Driscoll/Su/Vidal teaches the method (400) as claimed in claim 9,
Butler/Driscoll/Su/Vidal does not explicitly teach, However Kuperman teaches:
wherein, for extracting the second identifier, the second hash sum, and the second timestamp, the method (400) comprising (i) decrypting, by way of the second processing circuitry (122), the encrypted string using the cryptography technique to generate third combined data and (ii) segregating, by way of the second processing circuitry (122), the third combined data into the second identifier, the second hash sum, and the second timestamp. (Kuperman, para 78 discloses that the proxy decrypts the encrypted token inherently extracting UID:Timestamp:Hash; Kuperman, further discloses that, upon decryption, the proxy inherently extracts the UID, timestamp and the hash from the decrypted token in order to perform verification.)
It would have been obvious to a person having ordinary skill in the art to modify Butler/Driscoll/Su/Vidal’s system to incorporate Kuperman’s teachings of decrypting an encrypted token at the receiving entity and, upon decryption, inherently extracting the individual components of the token, including the UID, timestamp and hash value in order to perform authentication and verification. One would be motivated to perform such modification on Butler/Driscoll/Su/Vidal’s system to strengthen secure message handling, reducing ambiguity in how the verification data is extracted from encrypted transmission, and ensuring security check operates on correctly isolated data elements.
Regarding Claim 14, Butler/Kuperman/Driscoll/Su/Vidal teaches the system (100) as claimed in claim1,
Butler teaches:
wherein, for generating the third hash sum, the method (400) comprising (i) combining, by way of the second processing circuitry (122), the third information and the first information to generate fourth combined data and (ii) hashing, by way of the second processing circuitry (122), the fourth combined data using the hashing technique. (Butler, para 82 discloses that the smart contract decrypts the digital asset (A) and computes a liveness hash H′ using the digital asset and the nonce. Butler discloses that the liveness hash is generated by hashing the combined data elements (e.g., digital asset and nonce) using a hashing technique such as SHA-256.)
Butler/Driscoll/Su does not explicitly teach; However, Vidal teaches:
Wherein the first information comprises a package name (Vidal, para 15 discloses performing hash using package names, process or application names, version numbers, package dates and/or other package attributes or data.);
Wherein the third information comprises a second identifier (Vidal, para 15 discloses performing hash using package names, process or application names, version numbers, package dates and/or other package attributes or data.);
It would have been obvious to a person having ordinary skill in the art to modify Butler’s system to incorporate Vidal’s teachings of using package names and related identifiers like version number and other attributes that may be hashed to generate an encoded identifier. One would be motivated to perform such modification on Butler’s system to apply the hash computation to package-identifying information as a predicable design choice for identifying and validating package-based transactions or requests, thereby improving applicability of Butler’s verification mechanism to package centric transaction scenarios.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIT KHADKA whose telephone number is (703)756-1440. The examiner can normally be reached Monday - Friday, 8:00 am - 5:00 pm.
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, Jeffrey L. Nickerson can be reached at (469) 295-9235. 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.
/AMIT KHADKA/Examiner, Art Unit 2432
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432