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 .
DETAILED ACTION
1. This action is responsive to: an original application filed on 21 April 2025.
2. Claims 1-20 are currently pending and rejected.
Information Disclosure Statement
3. The information disclosure statement (IDS) submitted on 21 April 2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Priority
4. Priority claimed date considered.
Drawings
5. The drawings filed on 21 April 2025 are accepted by the examiner.
Double Patenting
6. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents /process/ file/efs/guidance /eTD-info-I.jsp.
Claims 1-20 are rejected under the grounds of non-statutory obviousness-type double patenting, as they are deemed unpatentable over claims 1-20 of US Patent application No. 18/061,863.
Although the conflicting claims are not identical, they are considered not patentably distinct from one another, as they convey the same inventive concept. Specifically, both sets of claims disclose a method for generating a safe image from a steganographic image by filtering List Significant Bit (LSB) data. Furthermore, it would have been obvious to one of ordinary skill in the art, at the time of the invention’s filing, to employ this approach to prevent and protect data from embedded malware in images, thereby rendering the claims unpatentable.
Claim Rejections - 35 USC § 102
7. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
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 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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-20 are rejected 35 U.S.C §102 (a)(2) as being anticipated by Andras Ferenczi (US Publication No. 20230034169), hereinafter Ferenczi.
Regarding claim 1:
receiving, by a server computer, an authorization request message comprising a contract address and a token identifier during an interaction between a user device and a resource provider computer (Ferenczi, ¶9-10), wherein, authenticating the identity of user using non-fungible tokens (NFTs). An NFT is a unique digital identifier that is recorded on a distributed ledger and can be used to certify authenticity and ownership of a given digital or real asset (e.g., artwork, recordings, digital images, etc.). According to various embodiments, the asset associated with the NFTs of the present disclosure corresponds to a credential verification of the user's identity. In various examples, a token issuer verifies a user's identity according to identifying credentials (e.g., government issued identification, passport, driver's license, etc.) presented by the user and creates a non-fungible token in response to verifying the credentials. The non-fungible token is associated with a user identifier and can be used by an access provider to authenticate a user requesting access to restricted content provided by the access provider.
verifying, by the server computer, that a non-fungible token (NFT), referenced by the contract address and the token identifier, is assigned to a first address and a second address (Ferenczi, ¶27, 20-21), wherein authentication service 147 determines whether the user is verified for authentication. In particular, the authentication service 147 validates the token data 130 by determining that the public key 133 corresponding to the private key 150 used to sign the cryptographic challenge is included in the token data 130 of the token smart contract 121 corresponding to the NFT. For example, if the public key 133 included in the token data 130 can be used to decrypt the signed cryptographic challenge, the authentication service 147 validates the token data 130 associated with the NFT. Further, the authentication service 147 verifies that the signed challenge corresponds to the challenge that was originally sent to the client device 112 for signature by comparing the signed challenge with the originally sent challenge. If the user is verified, the authentication service 147 proceeds to block 618. Otherwise, the authentication service 147 proceeds to block 621.
responsive to verifying that the NFT is referenced by the contract address and the token identifier, is assigned to the first address and the second address, determining, by the server computer, a credential stored in association with the contract address and the token identifier using a conversion table (Ferenczi, ¶87, ¶38), wherein , access provider system 109 uses the received token address 127 to look-up the token data 130 associated with the token smart contract 121 corresponding to the NFT for the user credentials. In various examples, the distributed ledger client application 124b sends or otherwise broadcasts a request to look-up the non-fungible token corresponding to the token smart contract 121 on the distributed ledger 118 using the token address 127 provided by the client application 136. The request or broadcast is received by the nodes 103 associated with the distributed ledger 118. For example, the distributed ledger client application 124b can make an application programming interface (API) call that includes the token address 127 to look-up the token smart contract 121 and obtain the token data 130 including the public key 133.
Regarding claim 2:
wherein processing the interaction with the credential further comprises: modifying, by the server computer, the authorization request message to include the credential; and providing, by the server computer, the authorization request message to an authorizing entity computer for authorization for the interaction (Ferenczi, ¶14, ¶77, ¶31).
Regarding claim 3:
further comprising: generating, by the server computer, an NFT request message comprising the first address associated with a user of the user device and the second address associated with an entity(Ferenczi, ¶10, ¶41); providing, by the server computer, the NFT request message for the NFT to a service provider computer associated with a blockchain network that manages NFTs, wherein the service provider computer and the blockchain network records ownership of the NFT to the first address and the second address (Ferenczi, ¶27); receiving, by the server computer from the service provider computer, NFT identifying data comprising the contract address and the token identifier that identifies the NFT (Ferenczi, ¶44-45); and providing, by the server computer, the NFT identifying data comprising the contract address and the token identifier to the user device, wherein the user device subsequently provides the NFT identifying data to the entity in the interaction, wherein the entity validates the NFT in the interaction (Ferenczi, ¶35-37).
Regarding claim 4:
wherein the authorization request message is from the resource provider computer associated with a resource provider (Ferenczi, abstract).
Regarding claim 5:
further comprising: storing, by the server computer, an expiry date in association with the contract address, the token identifier, and the credential (Ferenczi, ¶87-88).
Regarding claim 6:
further comprising: determining, by the server computer, whether or not the contract address and the token identifier are expired based on the expiry date (Ferenczi, ¶87-88).
Regarding claim 7:
wherein the server computer is a processing network computer, wherein the method further comprises: storing, by the processing network computer, the contract address, and the token identifier in association with the credential (Ferenczi, ¶18).
Regarding claim 8:
wherein the server computer is an authorizing entity computer (Ferenczi, ¶9).
Regarding claim 9:
wherein the interaction is a location access interaction, a data access interaction, a secure webpage access interaction, and/or a payment transaction (Ferenczi, ¶17).
Regarding claim 10:
wherein the first address is a user public key and the second address is a server computer public key (Ferenczi, ¶10).
Regarding claim 11:
a processor (Ferenczi, ¶16).
and a non-transitory computer-readable medium coupled to the processor, the computer-readable medium comprising code executable by the processor for implementing a method comprising (Ferenczi, ¶94):
receiving an authorization request message comprising a contract address and a token identifier during an interaction between a user device and a resource provider computer (Ferenczi, ¶9-10) wherein, authenticating the identity of user using non-fungible tokens (NFTs). An NFT is a unique digital identifier that is recorded on a distributed ledger and can be used to certify authenticity and ownership of a given digital or real asset (e.g., artwork, recordings, digital images, etc.). According to various embodiments, the asset associated with the NFTs of the present disclosure corresponds to a credential verification of the user's identity. In various examples, a token issuer verifies a user's identity according to identifying credentials (e.g., government issued identification, passport, driver's license, etc.) presented by the user and creates a non-fungible token in response to verifying the credentials. The non-fungible token is associated with a user identifier and can be used by an access provider to authenticate a user requesting access to restricted content provided by the access provider.
verifying that an NFT, referenced by the contract address and the token identifier, is assigned to a first address and a second address (Ferenczi, ¶27, ¶20-21), wherein authentication service 147 determines whether the user is verified for authentication. In particular, the authentication service 147 validates the token data 130 by determining that the public key 133 corresponding to the private key 150 used to sign the cryptographic challenge is included in the token data 130 of the token smart contract 121 corresponding to the NFT. For example, if the public key 133 included in the token data 130 can be used to decrypt the signed cryptographic challenge, the authentication service 147 validates the token data 130 associated with the NFT. Further, the authentication service 147 verifies that the signed challenge corresponds to the challenge that was originally sent to the client device 112 for signature by comparing the signed challenge with the originally sent challenge. If the user is verified, the authentication service 147 proceeds to block 618. Otherwise, the authentication service 147 proceeds to block 621.
if verified, determining a credential stored in association with the contract address and the token identifier using a conversion table (Ferenczi, ¶21, ¶62-63), wherein, The token smart contract 121 includes token data 130 that defines the attributes of a given NFT. For example, the token data 130 includes a mapping of a user identifier and a credential ticket. The user identifier is unique to the user. In various examples, the user identifier corresponds to a public key 133 of a key-pair generated by a client application 136 executed on the client device 112. In accordance to various embodiments, the authentication service 147 executed on the access provider system 109 validates or otherwise authenticates a user and/or user account requesting access by accessing the token smart contract 121 and determining that the user identifier (e.g., public key 133) associated with the requesting user and/or user account is included in the token data 130. The credential ticket that is mapped to the user identifier corresponds to an identification of the credential asset of the user or user account that the NFT is used to represent.
and processing, by the server computer, the interaction with the credential (Ferenczi, ¶13, ¶9, ¶20-21, ¶25). The token issuer service 139 executed by the token issuer system 106 interacts with the client application 136 of the client device 112 by receiving requests for creating a non-fungible token that is to be associated with an authentication of a user and receiving credential data 143 that is used to verify the identity of the requesting user. In addition, the token issuer service 139 analyzes the user credentials included in the credential data 143 (e.g., government issued identification, passport, driver's license, etc.) to verify the identity of the requesting user and/or user account.
Regarding claim 12:
wherein the server computer is an authorizing entity computer (Ferenczi, ¶9).
Regarding claim 13:
wherein the server computer is a network processing computer (Ferenczi, ¶14).
Regarding claim 14:
wherein the method further comprises: generating an NFT request message comprising the first address associated with a user of the user device and the second address associated with an entity (Ferenczi, ¶10, ¶41).; providing the NFT request message for the NFT to a service provider computer associated with a blockchain network that manages NFTs, wherein the service provider computer and the blockchain network records ownership of the NFT to the first address and the second address (Ferenczi, ¶27); receiving, from the service provider computer, NFT identifying data comprising the contract address and the token identifier that identifies the NFT (Ferenczi, ¶44-45); and providing the NFT identifying data comprising the contract address and the token identifier to the user device, wherein the user device subsequently provides the NFT identifying data to the entity in the interaction, wherein the entity validates the NFT in the interaction (Ferenczi, ¶62-63).
Regarding claim 15:
wherein the entity validates the NFT in the interaction further includes wherein the entity validates whether or not the NFT, identified by the NFT identifying data, is associated with the user device in a smart contract identified by the contract address (Ferenczi, ¶27).
Regarding claim 16:
wherein the entity is the server computer, wherein the method further comprises: validating the NFT and the NFT identifying data during the interaction (Ferenczi, ¶21).
Regarding claim 17:
wherein the NFT is stored on an NFT blockchain (Ferenczi, ¶10).
Regarding claim 18:
receiving, by a service provider computer from a server computer, an NFT request message comprising a first address associated with a user and a second address associated with an entity (Ferenczi, ¶62), wherein uses the received token address 127 to look-up the token data 130 associated with the token smart contract 121 corresponding to the NFT for the user credentials. In various examples, the distributed ledger client application 124b sends or otherwise broadcasts a request to look-up the non-fungible token corresponding to the token smart contract 121 on the distributed ledger 118 using the token address 127 provided by the client application 136. The request or broadcast is received by the nodes 103 associated with the distributed ledger 118. For example, the distributed ledger client application 124b can make an application programming interface (API) call that includes the token address 127 to look-up the token smart contract 121 and obtain the token data 130 including the public key 133.
recording, by the service provider computer, ownership of an NFT to the first address and the second address with a blockchain network, wherein the NFT is identified by NFT identifying data comprising a contract address and a token identifier (Ferenczi, ¶19-21), wherein The token smart contract 121 includes token data 130 that defines the attributes of a given NFT. For example, the token data 130 includes a mapping of a user identifier and a credential ticket. The user identifier is unique to the user. In various examples, the user identifier corresponds to a public key 133 of a key-pair generated by a client application 136 executed on the client device 112. In accordance to various embodiments, the authentication service 147 executed on the access provider system 109 validates or otherwise authenticates a user and/or user account requesting access by accessing the token smart contract 121 and determining that the user identifier (e.g., public key 133) associated with the requesting user and/or user account is included in the token data 130. The credential ticket that is mapped to the user identifier corresponds to an identification of the credential asset of the user or user account that the NFT is used to represent.
and providing, by the service provider computer, the NFT identifying data to the server computer, wherein the server computer provides the NFT identifying data comprising the contract address and the token identifier to a user device, wherein the user device subsequently provides the NFT identifying data to the entity in an interaction, wherein the entity validates the NFT in the interaction (Ferenczi, ¶44-45), wherein the authentication service 147 directs the distributed ledger client application 124b to access the token smart contract 121 corresponding to the non-fungible token using the provided token address 127 and look-up the token data 130 associated with the token smart contract 121. The authentication service 147 determines whether the token data 130 includes the public key 133 that corresponds to the private key 150 used to sign the cryptographic challenge.
Regarding claim 19:
wherein the service provider computer is associated with the blockchain network that manages NFTs (Ferenczi, ¶10).
Regarding claim 20:
wherein the server computer is an authorizing entity computer or a network processing computer (Ferenczi, ¶12).
Conclusion
8. The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Monjour Rahim whose telephone number is (571)270-3890.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shewaye Gelagay can be reached on 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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (in USA or CANANDA) or 571-272-1000.
/Monjur Rahim/
Patent Examiner
United States Patent and Trademark Office
Art Unit: 2436; Phone: 571.270.3890
E-mail: monjur.rahim@uspto.gov
Fax: 571.270.4890
Prosecution Insights