DETAILED ACTION
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 .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-10 recite a method, claims 11-17 recite a system, and claims 18-20 recite a non-transitory computer-accessible medium comprising instructions for execution by a computer hardware arrangement. Thus, each claim falls within at least one of the four categories of patent-eligible subject matter enumerated in 35 U.S.C. § 101. However, Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Regarding claim(s) 1, 11, and 18,
Claim 1 recites:
storing, […], one or more unique data records, wherein the one or more unique data records uniquely identifies an entity;
transmitting […], the one or more unique data records […];
verifying, […] , the one or more unique data records stored […];
generating, […] upon verifying the one or more unique data records, a unique token identifier;
and distributing, […] , the unique token identifier, in a reputation network by inserting the token identifier into one or more data blocks , wherein the verification server corresponds to a trusted entity, and wherein the unique token identifier is configured to be used as a query identifier for querying one or more reputation providers on the reputation network, wherein the reputation
components provided by one or more reputation providers,.
This is an abstract idea at least because it involves identity verification, which falls into the abstract idea grouping of fundamental economic principles or practices (including mitigating risk) (see MPEP § 2106.04(a)(2), subsection II.B).
The additional limitations are: a contactless card, an intermediary device, a verification server .
The additional claim elements are recited at a high-level of generality; and so, generally link the use of the judicial exception to a particular technological environment of networked computers and do not impose any meaningful limits on practicing the abstract idea. The claimed invention does not improve the functioning of a computer or improve another technology or technical field. Limitations that amount to merely indicating a field of use or technological environment in which to apply a judicial exception cannot integrate a judicial exception into a practical application. See MPEP 2106.05(h).Thus, the judicial exception is not integrated into a practical application.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately or in combination, they do no more than limit the above-identified abstract idea to the particular technological environment of networked computers, as discussed above. Limitations that merely confine the use of the abstract idea to a particular technological environment fail to add an inventive concept to the claims. See MPEP § 2106.05(h) discussing Affinity Labs of Texas v. DirecTV, LLC, 838 F.3d 1253, 120 USPQ2d 1201 (Fed. Cir. 2016) (particular technological environment of cellular telephones). The claim is not patent-eligible.
Independent claims 11 and 18 recite substantially the same subject matter albeit claim 11 is directed to a system and claim 18 is directed to a non-transitory computer-accessible medium and also recites "integrated memory of the contactless card." These additional elements are recited at a high level of generality, and claims 11 and 18 are rejected for the same reason as clam 1, discussed above.
Regarding claim(s) 2,
Claim 2 specifies that the intermediary devices comprise a mobile device with a near field communication (NFC) reader storing an application configured to read the contactless card. These are generic computing components that do not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 3 and 13,
Claims 3 and 13 recite which kinds of data are to be validated. This is part of the abstract idea and does not provide significantly, more.
Regarding claim(s) 4, 14, and 19,
Claims 4, 14, and 19 describe signing data blocks with a key.
These are generic computing components or functions that do not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 5,
Claim 5 disclosing adding data to a network and authenticating providers using a key. This is applying the abstract idea using generic computer components does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 6,
Claim 6 discloses storing a token on a hardware wallet. This is applying the abstract idea using generic computer components does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 7,
Claim 7 recites storing and retrieving the token using a hardware wallet. This is applying the abstract idea using generic computer components does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 8,
Claim 8 recites storing the token identifier to the contactless card onto an integrated memory of the contactless card and configuration to transmit data to a network. This is applying the abstract idea using generic computer components does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 9,
Claim 9 only specifies informational details of a query. This is applying the abstract idea using generic computer components does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 10,
Claim 10 links the invention to "a blockchain environment". This is applying the abstract idea using generic computer components does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s),
Claim 12 recites generic computing and network components for connecting to a network. This is applying the abstract idea using generic computer components does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 15,
Claim 12 recites a computing device (server) adding data blocks to a network. This is applying the abstract idea using generic computer components does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 16 and 20,
Claims 16 and 20 recite storing the token identifier to the contactless card onto an integrated memory of the contactless card and configuration to transmit data to a network. This is applying the abstract idea using generic computer components does not integrate the abstract idea into a practical application or provide significantly more.
Regarding claim(s) 17,
Claims 17 specifies the source of information/data. This is applying the abstract idea using generic computer components does not integrate the abstract idea into a practical application or provide significantly more.
Accordingly, claims 1-20 are rejected under 35 U.S.C. 101.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5 and 8-20 are rejected as being unpatentable under 35 U.S.C. 103 as being obvious over US 20200334430 A1 to Gupta; Sanjay et al. in view of US 20220311611 A1 to Gaur; Nitin et al.
Regarding claim(s) 1, 11, and 18,
GUPTA discloses:
A method/system/non-transitory computer accessible medium comprising instructions for execution by a computer hardware arrangement for self-sovereign identification assertion in a distributed reputation network (GUPTA: ¶[0002]: self-sovereign identification systems and methods using a device with near-field communication (NFC); ¶[0076]: functionalities executed in a distributed fashion – see GUAR discussion, below, for “reputation network”), the method comprising:
storing, by a contactless card, one or more unique data records, wherein the one or more unique data records uniquely identifies an entity (GUPTA: ¶[0032]: “scan an RFID chip 416 in the ID document 402 using an RFID reader 418 (or an NFC reader)”; ¶[0044]: . The ID document 602 includes a near-field communication (NFC) chip 610 that is adapted to store data such as a country signing certificate, a data hash or other data construct used to store at least information regarding an owner of the ID document; ¶[0043]: user stores a user identity packet related to a passport on their device, future requests for data stored on the ID document can be fulfilled using the user identity packet stored on the mobile device.);
transmitting, by the contactless card via an intermediary device, the one or more unique data records to a verification server (GUPTA: [0046] The mobile device 604 comprises an NFC reader 612 that is configured to read data from the NFC chip 610, an application 614, and a communications module 616 and […] transmit[…] to the service provider 606 using the communications module 616 over the network 608.; ¶[0049]-¶[00050]: data are embedded or stored on the NFC chip 610 of the ID document; The current biometric obtained by the mobile device 604 can be transmitted to the service provider 606. The service provider 606 can evaluate the data extracted from the NFC chip 610 and confirm the identity of the user.; ¶[0047]: Data obtained from the NFC chip 610 can be transmitted to the service provider 606 for verification.; ¶[0047]: The application 614 can further prompt the user to extract data stored on the NFC chip 610. Data obtained from the NFC chip 610 can be transmitted to the service provider 606 for verification);
verifying, by a verification server, the one or more unique data records stored on the contactless card (GUPTA: ¶[0051]: The service provider 606 can also validate that the data stored on the NFC chip 610 has not been tampered with. When the service provider 606 verifies the identity of the owner of the ID document 602 and the validity of the NFC chip 610, the service provider 606 can generate a user identity packet 618. As noted above, the user identity packet 618 serves as a self-sovereign identity for the user that can be used in place of the data stored on the NFC chip 610 of the ID document 602. The SSI is augmented with the validation of the NFC chip 610, which can (as noted herein) create an unbroken chain of trust. The user identity packet as described herein can include the SSI that is backed by validation of the NFC chip.; ¶[0050]: The current biometric obtained by the mobile device 604 can be transmitted to the service provider 606. The service provider 606 can evaluate the data extracted from the NFC chip 610 and confirm the identity of the user.);
generating, by the verification server upon verifying the one or more unique data records, a unique token identifier (GUPTA: ¶[0003]: the user identity packet being generated by the service provider based on verification of an identity of the owner and validity of the NFC chip; ¶[0051]: When the service provider 606 verifies the identity of the owner of the ID document 602 and the validity of the NFC chip 610, the service provider 606 can generate a user identity packet 618. As noted above, the user identity packet 618 serves as a self-sovereign identity for the user that can be used in place of the data stored on the NFC chip 610 of the ID document 602.);
and distributing, by the verification server, the unique token identifier, in a reputation network (GUPTA: [0053] The service provider 606 transmits the user identity packet 618 to the mobile device 604; [0054]: Once the user identity packet 618 is stored locally on the mobile device 604, a requesting device or service 624 can transmit to the mobile device 604 a request for ID data 626; figure 6: Requesting device or service 624 receiving user ID packet 618 over network 608; User ID packet (SSI)),
wherein the verification server corresponds to a trusted entity (GUPTA: ¶[0051]: service provider validates that the data on the NFC chip has not been tampered with; Self Sovereign Identification is augmented with the validation of the NFC chip, which can create an unbroken chain of trust (the user identity packet can include the SSI that is backed by validation the NFC chip; ¶[0044]: The ID document 602 includes a near-field communication (NFC) chip 610 that is adapted to store data such as a country signing certificate, a data hash or other data construct used to store at least information regarding an owner of the ID document. Authentication of data stored on the NFC chip involves performing a chain-of-trust process to analyze the data on the NFC chip that utilizes the country signing certificate.)
GUPTA does not expressly disclose the following limitations, which GUAR however, teaches:
reputation network (GUAR: ¶[0003]: method, system, and computer program product for reputation profile propagation on a blockchain networks; ¶[0005]: a method comprising initiating, by a node in the blockchain network, a non-fungible token identity, establishing, by the node, a profile for the non-fungible token identity, receiving, by the node, reputation data related to the non-fungible token identity, determining, by the node based on the reputation data, a reputation score, appending, by the node, the non-fungible token identity with the reputation score as a non-fungible token metadata tag, and uploading, by the node, the non-fungible token identity and the metadata tag to an ID repository.; ¶[0122]: need for reliable reputation ratings in ever more numerous digital interactions for individuals and enterprises participating in various networks; ¶[0153]: the block is recorded on the ledger making a permanent record of the reputation score that is accessible by the entire network; ¶[0130]: In some embodiments, the ID repository has score data from one or more other networks. For example, an ID in the repository may have information related to the ID from another network such as a profile (i.e., a profile similar to the one generated in operation 604 below), a reputation score (i.e., a score similar to the one generated in operation 604 or updated in operation 606 below), one or more modules/rules used to generate a profile score, and/or data that was used to generate a reputation score.)
by inserting, by the verification server, the unique token identifier into one or more reputation data blocks as a metric of identity associated with the entity (GUAR: [0007] determining, based on the reputation data, a reputation score, appending the identity with the reputation score as a metadata tag, and uploading the identity and the metadata tag to an ID repository.; ¶[0079]: The block metadata 460 may store multiple fields of metadata. Metadata fields may include signature on block creation; ¶[0077] The block data 450 may store transactional information of each transaction that is recorded within the new data block 430. For example, the transaction data may include one or more of a type of the transaction, , a timestamp, a transaction ID, , a client (creator) identity , a signature of the client, identities of endorsers, endorser signatures, and the like.),
wherein the one or more reputation data blocks comprising one or more reputation components provided by one or more reputation providers (GUAR: [0130] In some embodiments, the ID repository has score data from one or more other networks. For example, an ID in the repository may have information related to the ID from another network such as a profile (i.e., a profile similar to the one generated in operation 604 below), a reputation score (i.e., a score similar to the one generated in operation 604 or updated in operation 606 below), one or more modules/rules used to generate a profile score, and/or data that was used to generate a reputation score.; [0131] In some embodiments, the establishing includes retrieving an ID that was generated on another network. In some embodiments, the system may interact with an ID repository to retrieve an established ID. For example, a first organization has generated an ID for an employee-driver based on his name. The first organization establishes an ID for the employee-driver and uploads the established ID to an ID repository. If the driver is now employed with the second organization, the second organization may retrieve the ID from the ID repository instead of establishing an additional ID.),
and wherein the unique token identifier is configured to be used as a query identifier for querying one or more reputation providers on the reputation network (GUAR: [0127]: Process 600 begins with operation 602 of establishing an ID for a profile. In some embodiments, the identity issuance and verification system includes instructions to retrieve an identity that has previously been created, as discussed below; [0129] In some embodiments, the establishing includes generating a new identification for a participant. In some embodiments, an ID may be based on a previously established ID for an entity or user. In some embodiments, the established ID may be stored on an ID repository for use on other networks. For example, the established ID may be stored on the repository, with a reputation generated in operation 604 or 606 below; [0130] In some embodiments, the ID repository has score data from one or more other networks. For example, an ID in the repository may have information related to the ID from another network such as a profile (i.e., a profile similar to the one generated in operation 604 below), a reputation score (i.e., a score similar to the one generated in operation 604 or updated in operation 606 below), one or more modules/rules used to generate a profile score, and/or data that was used to generate a reputation score.; [0131] In some embodiments, the establishing includes retrieving an ID that was generated on another network. In some embodiments, the system may interact with an ID repository to retrieve an established ID. For example, a first organization has generated an ID for an employee-driver based on his name. The first organization establishes an ID for the employee-driver and uploads the established ID to an ID repository. If the driver is now employed with the second organization, the second organization may retrieve the ID from the ID repository instead of establishing an additional ID; [0134]: In some embodiments, the reputation modulator smart contract may direct a node on the blockchain network to retrieve data from other networks that is stored in the ID repository. For example, a first organization may retrieve information from the ID repository for a driver, where the information was uploaded to an ID repository by a second organization.; ¶[0053]: If the chaincode only queried the ledger, the application would inspect the query response; [0056]: a blockchain user 302 may initiate a transaction to a permissioned blockchain 304. In this example, the transaction can be a query and may be issued through a client-side application leveraging an SDK, directly through an API, etc.; ¶[0056]: The network 300 may provide access to a regulator 306, such as an auditor. An auditor may be restricted only to querying the ledger whereas a client may be authorized to deploy, invoke, and query certain types of chaincode.).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of GUPTA, which relates to identification (ID) verification, and self-sovereign identification systems and method (GUPTA [0002]) with the technique of GUAR, which relates to systems and methods for managing the identity and reputation of users (GUAR ¶[0003]-[0007]), in order to enable cross network portability (GUAR ¶[0150]) that enables access to reliable reputation data across various networks (GUAR ¶[0122] ).
Regarding claim(s) 2,
The combination of GUPTA and GUAR teaches the limitations of claim 1,
GUPTA further discloses:
wherein the one or more intermediary devices comprise a mobile device with a near field communication (NFC) reader storing an application configured to read the contactless card (GUPTA: ¶ [0046]: The mobile device 604 comprises an NFC reader 612 that is configured to read data from the NFC chip 610, an application 614, and a communications module 616; ¶[0047]: the application 614 can further prompt the user to extract data stored on the NFC chip 610. Data obtained from the NFC chip 610 can be transmitted to the service provider 606 for verification)
Regarding claim(s) 3 and 13,
The combination of GUPTA and GUAR teaches the limitations of claims 1 and 11.
GUPTA further discloses:
wherein the one or more reputation providers validate one or more reputation components associated with a user, the one or more reputation components comprising records corresponding to educational background, skills, and professional qualifications associated with the entity (GUPTA: ¶[0027]: The ID document may include a student ID, a driver’s license, and an employment ID).
Regarding claim(s) 4, 14, and 19,
The combination of GUPTA and GUAR teaches the limitations of claims 1, 11 and 18.
wherein the one or more reputation data blocks comprising one or more reputation components provided by one or more reputation providers (GUAR: [0130] In some embodiments, the ID repository has score data from one or more other networks. For example, an ID in the repository may have information related to the ID from another network such as a profile (i.e., a profile similar to the one generated in operation 604 below), a reputation score (i.e., a score similar to the one generated in operation 604 or updated in operation 606 below), one or more modules/rules used to generate a profile score, and/or data that was used to generate a reputation score.; [0131] In some embodiments, the establishing includes retrieving an ID that was generated on another network. In some embodiments, the system may interact with an ID repository to retrieve an established ID. For example, a first organization has generated an ID for an employee-driver based on his name. The first organization establishes an ID for the employee-driver and uploads the established ID to an ID repository. If the driver is now employed with the second organization, the second organization may retrieve the ID from the ID repository instead of establishing an additional ID.),
and wherein the one or more reputation data blocks are signed with a private key of a corresponding reputation provider (GUAR: [0052] The set of transaction results, along with the endorsing peer node's 281 signature is passed back as a proposal response; [0053] In response, the application of the client 260 inspects/verifies the endorsing peer's 281 signature and compares the proposal response 292 to determine if the proposal response 292 is valid.; ¶[0077]: The block data 450 may store transactional information of each transaction that is recorded within the new data block 430. For example, the transaction data may include a chaincode path (deploy transaction), input (chaincode and functions), a client (creator) identity such as a public key and certificate); ¶[0111]: The private key is kept secret and used to digitally sign messages sent to other blockchain participants. The signature is included in the message so that the recipient can verify using the public key of the sender. This way, the recipient can be sure that only the sender may have sent this message; ¶[0153]: in some embodiments, the block is recorded on the ledger making a permanent record of the reputation score that is accessible by the entire network. In some embodiments, post consensus, the block may be committed to the blockchain network ledger and the state of the digital corollary is updated. ;
[0112] Generating a key pair may be analogous to creating an account on the blockchain, but without having to actually register anywhere. Also, every transaction that is executed on the blockchain is digitally signed by the sender using their private key. This signature ensures that only the owner of the account can track and process (if within the scope of permission determined by a smart contract) the file of the blockchain.).
Regarding claim(s) 5,
The combination of GUPTA and GUAR teaches the limitations of claims 1 and 4,
GUPTA does not expressly disclose the following limitations, which GUAR however, teaches:
further comprising adding, by the verification server, the reputation data blocks to the distributed reputation network comprising a plurality of reputation providers (GUAR: ¶[0153]: Process 600 continues with operation 610 where the operation output is injected into a block proposal. In some embodiments, the block is recorded on the ledger making a permanent record of the reputation score that is accessible by the entire network. For example, a block may record the reputation score that a driver profile has received and the rules that were used to determine the reputation score; GUAR: [0130] In some embodiments, the ID repository has score data from one or more other networks. For example, an ID in the repository may have information related to the ID from another network such as a profile (i.e., a profile similar to the one generated in operation 604 below), a reputation score (i.e., a score similar to the one generated in operation 604 or updated in operation 606 below), one or more modules/rules used to generate a profile score, and/or data that was used to generate a reputation score.; ¶[0131]: In some embodiments, the establishing includes retrieving an ID that was generated on another network. In some embodiments, the system may interact with an ID repository to retrieve an established ID. For example, a first organization has generated an ID for an employee-driver based on his name. The first organization establishes an ID for the employee-driver and uploads the established ID to an ID repository. If the driver is now employed with the second organization, the second organization may retrieve the ID from the ID repository instead of establishing an additional ID.; ¶[0134]: In some embodiments, the reputation modulator smart contract may direct a node on the blockchain network to retrieve data from other networks that is stored in the ID repository. For example, a first organization may retrieve information from the ID repository for a driver, where the information was uploaded to an ID repository by a second organization.).
wherein each of the plurality of reputation providers is authenticated using a corresponding public key associated with the reputation provider (GUAR: [0030]: An endorsement policy allows chaincode to specify endorsers for a transaction in the form of a set of peer nodes that are necessary for endorsement. When a client sends the transaction to the peers specified in the endorsement policy, the transaction is executed to validate the transaction. After validation, the transactions enter an ordering phase in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks.; ¶[0152]: Process 600 continues with operation 608, where a node in the blockchain network creates an operation output (e.g., transaction) for the reputation score. The operational output is used to verify that the reputation score is well formed and the signature is valid; [0052] The set of transaction results, along with the endorsing peer node's 281 signature is passed back as a proposal response; [0053] In response, the application of the client 260 inspects/verifies the endorsing peer's 281 signature and compares the proposal response 292 to determine if the proposal response 292 is valid.; ¶[0077]: The block data 450 may store transactional information of each transaction that is recorded within the new data block 430. For example, the transaction data may include a chaincode path (deploy transaction), input (chaincode and functions), a client (creator) identity such as a public key and certificate); ¶[0111]: The private key is kept secret and used to digitally sign messages sent to other blockchain participants. The signature is included in the message so that the recipient can verify using the public key of the sender. This way, the recipient can be sure that only the sender may have sent this message; ¶[0153]: in some embodiments, the block is recorded on the ledger making a permanent record of the reputation score that is accessible by the entire network. In some embodiments, post consensus, the block may be committed to the blockchain network ledger and the state of the digital corollary is updated.).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of GUPTA, which relates to identification (ID) verification, and self-sovereign identification systems and method (GUPTA [0002]) with the technique of GUAR, which relates to systems and methods for managing the identity and reputation of users (GUAR ¶[0003]-[0007]), in order to enable cross network portability (GUAR ¶[0150]) that enables access to reliable reputation data across various networks (GUAR ¶[0122] ).
Regarding claim(s) 8,
The combination of GUPTA and GUAR teaches the limitation of claims 1.
wherein distributing the unique token identifier, as a query identifier for the entity, in a reputation network, corresponds to transmitting the unique token identifier to the contactless card for storage onto an integrated memory of the contactless card (GUPTA: ¶[0049]: The NFC chip 610 or the service provider 606 can store baseline biometric data for the user. These baseline biometric data can be obtained when the user originally applies for or obtains the ID document 602. These data are embedded or stored on the NFC chip 610 of the ID document 602 by the issuing authority.; ¶[0053]:The service provider 606 transmits the user identity packet 618 to the mobile device 604 for storage),
wherein the contactless card is configured to transmit the unique token identifier, as a query identity, to the distributed reputation network (GUPTA: ¶[0046]: The mobile device 604 comprises an NFC reader 612 that is configured to read data from the NFC chip 610, an application 614, and a communications module 616. In some embodiments, to obtain a user identity packet from the service provider 606, the user may be prompted to obtain an image of the ID document 602 from on an application 614 executing on the mobile device 604; ¶[0047]: Data obtained from the NFC chip 610 can be transmitted to the service provider 606 for verification. the mobile device 604 can utilize the public key to extract the data on the NFC chip 610 and transmit the same to the service provider 606.),
GUPTA does not expressly disclose the following limitations, which GUAR however, teaches:
the unique token identifier comprising a digital signature of the verification server as the trusted entity (GUAR: ¶[0077]:The block data 450 may store transactional information of each transaction that is recorded within the new data block 430. For example, the transaction data may include one or more of a transaction ID, a client (creator) identity such as a public key and certificate, a signature of the client, identities of endorsers, endorser signatures etc; ¶[0112]: every transaction that is executed on the blockchain is digitally signed by the sender using their private key.).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of GUPTA, which relates to identification (ID) verification, and self-sovereign identification systems and method (GUPTA [0002]) with the technique of GUAR, which relates to systems and methods for managing the identity and reputation of users (GUAR ¶[0003]-[0007]), in order to enable cross network portability (GUAR ¶[0150]) that enables access to reliable reputation data across various networks (GUAR ¶[0122] ).
Regarding claim(s) 9,
The combination of GUPTA and GUAR teaches the limitations of claim 1,
wherein a reputation query comprises the unique token identifier (GUPTA: ¶[0054]: a requesting device or service 624 can transmit to the mobile device 604 a request for ID data 626; ¶[0054]: requesting device or service 624 should be configured to accept the user identity packet)
GUPTA does not expressly disclose the following limitations, which GUAR however, teaches:
and one or more reputation components (GUAR: ¶[0131]: In some embodiments, the establishing includes retrieving an ID that was generated on another network. In some embodiments, the system may interact with an ID repository to retrieve an established ID. For example, a first organization has generated an ID for an employee-driver based on his name. The first organization establishes an ID for the employee-driver and uploads the established ID to an ID repository. If the driver is now employed with the second organization, the second organization may retrieve the ID from the ID repository instead of establishing an additional ID.; ¶[0134]: first organization may retrieve information from the ID repository for a driver, where the information was uploaded to an ID repository by a second organization; ¶[0135]-[0135] In some embodiments, reputation data (such as activities associated with a profile) may be received by the blockchain network and linked to the ID. For example, users may periodically submit a review for the driver associated with the ID to a node on the network. The reviews may be electronically logged with the blockchain network and used when the reputation modulator smart contract is invoked; [0147], validation may be required at regular time intervals, after every review, after a fixed number of reviews, after every transaction, after a set number of transactions, after receiving new information related to a profile, etc. In some embodiments, the reputation score may need to be checked by the blockchain network to determine if it is still valid. In some embodiments, the validation involves running the rules/modules in the reputation module data again to determine if any new reputation data or the age of previous reputation data changes the reputation score and possibly updating the reputation score; [0149]: The reputation score validator may retrieve the null score and the new reviews and run the profile through one or more modules or rules. The score validator may determine a reputation score for the driver and append the driver's NFT ID with a metadata tag indicating his updated reputation score.).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of GUPTA, which relates to identification (ID) verification, and self-sovereign identification systems and method (GUPTA [0002]) with the technique of GUAR, which relates to systems and methods for managing the identity and reputation of users (GUAR ¶[0003]-[0007]), in order to enable cross network portability (GUAR ¶[0150]) that enables access to reliable reputation data across various networks (GUAR ¶[0122] ).
Regarding claim(s) 10,
The combination of GUPTA and GUAR teaches the limitations of claim 1,
GUPTA does not expressly disclose the following limitations, which GUAR however, teaches:
wherein the distributed reputation network is implemented in a blockchain environment (GUAR: ¶[0003]: method, system, and computer program product for reputation profile propagation on a blockchain networks; ¶[0005]: a method comprising initiating, by a node in the blockchain network, a non-fungible token identity, establishing, by the node, a profile for the non-fungible token identity, receiving, by the node, reputation data related to the non-fungible token identity, determining, by the node based on the reputation data, a reputation score, appending, by the node, the non-fungible token identity with the reputation score as a non-fungible token metadata tag, and uploading, by the node, the non-fungible token identity and the metadata tag to an ID repository.; ¶[0122]: need for reliable reputation ratings in ever more numerous digital interactions for individuals and enterprises participating in various networks; ¶[0153]: the block is recorded on the ledger making a permanent record of the reputation score that is accessible by the entire network)
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of GUPTA, which relates to identification (ID) verification, and self-sovereign identification systems and method (GUPTA [0002]) with the technique of GUAR, which relates to systems and methods for managing the identity and reputation of users (GUAR ¶[0003]-[0007]), in order to enable cross network portability (GUAR ¶[0150]) that enables access to reliable reputation data across various networks (GUAR ¶[0122] ).
Regarding claim(s) 12,
The combination of GUPTA and GUAR teaches the limitations of claim 11,
wherein communication between the contactless card and the authentication server is enabled by an application running on the intermediary device with near field communication (NFC) connectivity to the contactless card and network connectivity to the verification server (GUPTA: ¶ [0046]: The mobile device 604 comprises an NFC reader 612 that is configured to read data from the NFC chip 610, an application 614, and a communications module 616; ¶[0047]: the application 614 can further prompt the user to extract data stored on the NFC chip 610. Data obtained from the NFC chip 610 can be transmitted to the service provider 606 for verification); [0046]: transmission to the service provider is made "using the communications module" "over the network").
Regarding claim(s) 15,
The combination of GUPTA and GUAR teaches the limitations of claim 11 and 14.
GUPTA does not expressly disclose the following limitations, which GUAR however, teaches:
wherein the verification server is further configured to add the reputation data blocks to the reputation network (GUAR: ¶[0153]: Process 600 continues with operation 610 where the operation output is injected into a block proposal. In some embodiments, the block is recorded on the ledger making a permanent record of the reputation score that is accessible by the entire network. For example, a block may record the reputation score that a driver profile has received and the rules that were used to determine the reputation score.).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of GUPTA, which relates to identification (ID) verification, and self-sovereign identification systems and method (GUPTA [0002]) with the technique of GUAR, which relates to systems and methods for managing the identity and reputation of users (GUAR ¶[0003]-[0007]), in order to enable cross network portability (GUAR ¶[0150]) that enables access to reliable reputation data across various networks (GUAR ¶[0122] ).
Regarding claim(s) 16 and 20 ,
The combination of GUPTA and GUAR teaches the limitation of claims 11 and 18.
GUPTA further discloses:
wherein distributing the unique token identifier, as a query identifier for the entity, in a reputation network, corresponds to transmitting the unique token identifier to the contactless card for storage onto an integrated memory of the contactless card (GUPTA: ¶[0049]: The NFC chip 610 or the service provider 606 can store baseline biometric data for the user. These baseline biometric data can be obtained when the user originally applies for or obtains the ID document 602. These data are embedded or stored on the NFC chip 610 of the ID document 602 by the issuing authority.; ¶[0053]:The service provider 606 transmits the user identity packet 618 to the mobile device 604 for storage),
wherein the contactless card is configured to transmit the unique token identifier, as a query identity, to the distributed reputation network (GUPTA: ¶[0046]: The mobile device 604 comprises an NFC reader 612 that is configured to read data from the NFC chip 610, an application 614, and a communications module 616. In some embodiments, to obtain a user identity packet from the service provider 606, the user may be prompted to obtain an image of the ID document 602 from on an application 614 executing on the mobile device 604; ¶[0047]: Data obtained from the NFC chip 610 can be transmitted to the service provider 606 for verification. the mobile device 604 can utilize the public key to extract the data on the NFC chip 610 and transmit the same to the service provider 606.).
Regarding claim(s) 17,
GUPTA does not expressly disclose the following limitations, which GUAR however, teaches:
wherein one or more values for each of the one or more reputation components are provided by the one or more reputation providers participating in the distributed reputation network (GUAR: [0130] In some embodiments, the ID repository has score data from one or more other networks. For example, an ID in the repository may have information related to the ID from another network such as a profile (i.e., a profile similar to the one generated in operation 604 below), a reputation score (i.e., a score similar to the one generated in operation 604 or updated in operation 606 below), one or more modules/rules used to generate a profile score, and/or data that was used to generate a reputation score.; ¶[0131]: In some embodiments, the establishing includes retrieving an ID that was generated on another network. In some embodiments, the system may interact with an ID repository to retrieve an established ID. For example, a first organization has generated an ID for an employee-driver based on his name. The first organization establishes an ID for the employee-driver and uploads the established ID to an ID repository. If the driver is now employed with the second organization, the second organization may retrieve the ID from the ID repository instead of establishing an additional ID.; ¶[0134]: In some embodiments, the reputation modulator smart contract may direct a node on the blockchain network to retrieve data from other networks that is stored in the ID repository. For example, a first organization may retrieve information from the ID repository for a driver, where the information was uploaded to an ID repository by a second organization.).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of GUPTA, which relates to identification (ID) verification, and self-sovereign identification systems and method (GUPTA [0002]) with the technique of GUAR, which relates to systems and methods for managing the identity and reputation of users (GUAR ¶[0003]-[0007]), in order to enable cross network portability (GUAR ¶[0150]) that enables access to reliable reputation data across various networks (GUAR ¶[0122] ).
Claims 6-7 are rejected as being unpatentable under 35 U.S.C. 103 as being obvious over US 20200334430 A1 to Gupta; Sanjay et al. in view of US 20220311611 A1 to Gaur; Nitin et al. in further view of US 20200235920 A1 to Kong; Yanbin
Regarding claim(s) 6,
The combination of GUPTA and GUAR teaches the limitations of claim 1,
GUAR further discloses:
wherein distributing the unique token identifier, as a query identifier for the entity, in a reputation network (GUAR: [0127]: Process 600 begins with operation 602 of establishing an ID for a profile. In some embodiments, the identity issuance and verification system includes instructions to retrieve an identity that has previously been created, as discussed below; [0129] In some embodiments, the establishing includes generating a new identification for a participant. In some embodiments, an ID may be based on a previously established ID for an entity or user. In some embodiments, the established ID may be stored on an ID repository for use on other networks. For example, the established ID may be stored on the repository, with a reputation generated in operation 604 or 606 below; [0130] In some embodiments, the ID repository has score data from one or more other networks. For example, an ID in the repository may have information related to the ID from another network such as a profile (i.e., a profile similar to the one generated in operation 604 below), a reputation score (i.e., a score similar to the one generated in operation 604 or updated in operation 606 below), one or more modules/rules used to generate a profile score, and/or data that was used to generate a reputation score.; [0131] In some embodiments, the establishing includes retrieving an ID that was generated on another network. In some embodiments, the system may interact with an ID repository to retrieve an established ID. For example, a first organization has generated an ID for an employee-driver based on his name. The first organization establishes an ID for the employee-driver and uploads the established ID to an ID repository. If the driver is now employed with the second organization, the second organization may retrieve the ID from the ID repository instead of establishing an additional ID; [0134]: In some embodiments, the reputation modulator smart contract may direct a node on the blockchain network to retrieve data from other networks that is stored in the ID repository. For example, a first organization may retrieve information from the ID repository for a driver, where the information was uploaded to an ID repository by a second organization.; ¶[0053]: If the chaincode only queried the ledger, the application would inspect the query response; [0056]: a blockchain user 302 may initiate a transaction to a permissioned blockchain 304. In this example, the transaction can be a query and may be issued through a client-side application leveraging an SDK, directly through an API, etc.; ¶[0056]: The network 300 may provide access to a regulator 306, such as an auditor. An auditor may be restricted only to querying the ledger whereas a client may be authorized to deploy, invoke, and query certain types of chaincode.),
corresponds to storing the unique token identifier on a […] wallet (GUAR: ¶[0133]: storing the reputation profile in an e-wallet or linked to an e-wallet where tokens associated with the ID are stored)
the unique token identifier comprising a digital signature of the verification server as the trusted entity (GUAR: [0127]: Process 600 begins with operation 602 of establishing an ID for a profile. In some embodiments, the identity issuance and verification system includes instructions to retrieve an identity that has previously been created, as discussed below; [0129] In some embodiments, the establishing includes generating a new identification for a participant. In some embodiments, an ID may be based on a previously established ID for an entity or user. In some embodiments, the established ID may be stored on an ID repository for use on other networks. For example, the established ID may be stored on the repository, with a reputation generated in operation 604 or 606 below; [0130] In some embodiments, the ID repository has score data from one or more other networks. For example, an ID in the repository may have information related to the ID from another network such as a profile (i.e., a profile similar to the one generated in operation 604 below), a reputation score (i.e., a score similar to the one generated in operation 604 or updated in operation 606 below), one or more modules/rules used to generate a profile score, and/or data that was used to generate a reputation score.; [0131] In some embodiments, the establishing includes retrieving an ID that was generated on another network. In some embodiments, the system may interact with an ID repository to retrieve an established ID. For example, a first organization has generated an ID for an employee-driver based on his name. The first organization establishes an ID for the employee-driver and uploads the established ID to an ID repository. If the driver is now employed with the second organization, the second organization may retrieve the ID from the ID repository instead of establishing an additional ID; [0134]: In some embodiments, the reputation modulator smart contract may direct a node on the blockchain network to retrieve data from other networks that is stored in the ID repository. For example, a first organization may retrieve information from the ID repository for a driver, where the information was uploaded to an ID repository by a second organization.; ¶[0053]: If the chaincode only queried the ledger, the application would inspect the query response; [0056]: a blockchain user 302 may initiate a transaction to a permissioned blockchain 304. In this example, the transaction can be a query and may be issued through a client-side application leveraging an SDK, directly through an API, etc.; ¶[0056]: The network 300 may provide access to a regulator 306, such as an auditor. An auditor may be restricted only to querying the ledger whereas a client may be authorized to deploy, invoke, and query certain types of chaincode.)GUAR: ¶[0077]:The block data 450 may store transactional information of each transaction that is recorded within the new data block 430. For example, the transaction data may include one or more of a transaction ID, a client (creator) identity such as a public key and certificate, a signature of the client, identities of endorsers, endorser signatures etc; ¶[0112]: every transaction that is executed on the blockchain is digitally signed by the sender using their private key).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of GUPTA, which relates to identification (ID) verification, and self-sovereign identification systems and method (GUPTA [0002]) with the technique of GUAR, which relates to systems and methods for managing the identity and reputation of users (GUAR ¶[0003]-[0007]), in order to enable cross network portability (GUAR ¶[0150]) that enables access to reliable reputation data across various networks (GUAR ¶[0122] ).
GUPTA and GUAR do not expressly disclose the following limitations, which KONG however, teaches:
corresponds to storing the unique token identifier on a hierarchical deterministic (HD) hardware wallet (KONG: ¶[0003]: a digital-currency hierarchical deterministic (HD) wallet ; [0006] A method for generating an HD wallet name card, which is applied to a HD wallet device, wherein the HD wallet device has a preset first trusted key and a first key generated by the seed; the first trusted key comprises a first trusted private key and a first trusted public key; the first key comprises a first private key, a first public key and a first address; and the method for generating the HD wallet name card comprises the following steps: digitally signing first user information with the first private key to obtain first signature information; digitally signing second user information with the first trusted private key to obtain second signature information; and generating the HD wallet name card by integrating the first user information, the second user information, the first signature information, and the second signature information. ; [0127] Further, the operating method further comprises: Step S2003: the sender generates the HD wallet trusted address through the HD wallet device and sends the trusted address to the receiver; Step S2004: the receiver verifies the HD wallet trusted address with the HD wallet name card.)
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of GUPTA, which relates to identification (ID) verification, and self-sovereign identification systems and method (GUPTA [0002]) with the technique of KONG, in order to protect data from tampering and attacks by hacksters and fraudsters (see KONG ¶[0003]).
Regarding claim(s) 7,
GUTPA AND GUAR teaches the limitations of claim 1 and 6,
GUAR further teaches:
is used to provide the unique token identifier, as the query identifier, to the reputation network (GUAR: ¶[0077]:The block data 450 may store transactional information of each transaction that is recorded within the new data block 430. For example, the transaction data may include one or more of a transaction ID, a client (creator) identity such as a public key and certificate, a signature of the client, identities of endorsers, endorser signatures etc; ¶[0112]: every transaction that is executed on the blockchain is digitally signed by the sender using their private key.).
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of GUPTA, which relates to identification (ID) verification, and self-sovereign identification systems and method (GUPTA [0002]) with the technique of GUAR, which relates to systems and methods for managing the identity and reputation of users (GUAR ¶[0003]-[0007]), in order to enable cross network portability (GUAR ¶[0150]) that enables access to reliable reputation data across various networks (GUAR ¶[0122] ).
GUPTA and GUAR do not teach what, KONG, however teaches:
wherein the HD hardware wallet (KONG: ¶[0003]: a digital-currency hierarchical deterministic (HD) wallet ; [0006] A method for generating an HD wallet name card, which is applied to a HD wallet device, wherein the HD wallet device has a preset first trusted key and a first key generated by the seed; the first trusted key comprises a first trusted private key and a first trusted public key; the first key comprises a first private key, a first public key and a first address; and the method for generating the HD wallet name card comprises the following steps: digitally signing first user information with the first private key to obtain first signature information; digitally signing second user information with the first trusted private key to obtain second signature information; and generating the HD wallet name card by integrating the first user information, the second user information, the first signature information, and the second signature information. ; [0127] Further, the operating method further comprises: Step S2003: the sender generates the HD wallet trusted address through the HD wallet device and sends the trusted address to the receiver; Step S2004: the receiver verifies the HD wallet trusted address with the HD wallet name card.)
It would have been obvious to one of ordinary skill in the art before the time of filing to combine/modify the system/method of GUPTA, which relates to identification (ID) verification, and self-sovereign identification systems and method (GUPTA [0002]) with the technique of KONG, in order to protect data from tampering and attacks by hacksters and fraudsters (see KONG ¶[0003]).
Response to Arguments
Objections to the Specification
Applicant’s arguments, see page 13, filed 30 October 2025, with respect to the specification have been fully considered and are persuasive. The objections to the specification have been withdrawn.
35 U.S.C. § 101
Applicant's arguments filed 30 October 2025 have been fully considered but they are not persuasive. Applicant argues at page 14 that the claims are not directed to an abstract idea.
Applicant argues at page 14-15 that the claims are not directed to an abstract idea.
This argument been considered, but it's not persuasive. At page 15 Applicant argues the claims are not directed to an abstract idea at least because independent claim 1 recites:
"storing, by a contactless card, one or more unique data records, wherein the one or more unique data records uniquely identifies an entity," "transmitting, by the contactless card via an intermediary device, the one or more unique data records to a verification server," "verifying, by a verification server, the one or more unique data records stored on the contactless card," "generating, by the verification server upon verifying the one or more unique data records, a unique token identifier," and "distributing, by the verification server, the unique token identifier, in a reputation network by inserting, by the verification server, the unique token identifier into one or more reputation data blocks of the reputation network as a metric of identity associated with the entity," wherein "the one or more reputation data blocks comprising one or more reputation components provided by one or more reputation providers," "the verification server corresponds to a trusted entity," and "the unique token identifier is configured to be used as a query identifier for querying one or more reputation providers on the reputation network."
This argument has been considered but is unpersuasive. The claims are directed to mitigating risk through identity verification using generic elements that amount to merely indicating a field of use or technological environment in which to apply a judicial exception.
At pages 17-20, applicant argues that the claims represent an improvement in technology at least by including the following:
"distributing, by the verification server, the unique token identifier, in a reputation network by inserting, by the verification server, the unique token identifier into one or more reputation data blocks of the reputation network as a metric of identity associated with the entity, wherein the one or more reputation data blocks comprising one or more reputation components provided by one or more reputation provider”.
Applicant further argues that the claims integrate the abstract idea into a practical application and amount to significantly more than any alleged abstract idea.
MPEP 2106.05(d) lists examples of computer functions that are well-understood, routine, and conventional activity when claimed in a generic manner or as insignificant extra-solution activity including:
i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added));
[...[
iii. Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log);
iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93;
[...]
The additional claim elements are recited at a high-level of generality; and so, generally link the use of the judicial exception to a particular technological environment of networked computers and do not impose any meaningful limits on practicing the abstract idea. The claimed invention does not improve the functioning of a computer or improve another technology or technical field. Limitations that amount to merely indicating a field of use or technological environment in which to apply a judicial exception cannot integrate a judicial exception into a practical application. See MPEP 2106.05(h).
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately or in combination, they do no more than limit the above-identified abstract idea to the particular technological environment of networked computers, as discussed above. Limitations that merely confine the use of the abstract idea to a particular technological environment fail to add an inventive concept to the claims. See MPEP § 2106.05(h) discussing Affinity Labs of Texas v. DirecTV, LLC, 838 F.3d 1253, 120 USPQ2d 1201 (Fed. Cir. 2016) (particular technological environment of cellular telephones). The claim is not patent-eligible.
35 U.S.C. § 103
At page 22, Applicant argues that GUPTA does not teach all of the limitations of the claims. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
At pages 22-23 Applicant argues that the references do not teach or suggest that "the one or more reputation data blocks comprising one or more reputation components provided by one or more reputation providers,". This argument has been considered but is unpersuasive. GAUR teaches at paragraph [0130] In some embodiments, the ID repository has score data from one or more other networks. For example, an ID in the repository may have information related to the ID from another network such as a profile (i.e., a profile similar to the one generated in operation 604 below), a reputation score (i.e., a score similar to the one generated in operation 604 or updated in operation 606 below), one or more modules/rules used to generate a profile score, and/or data that was used to generate a reputation score.
At pages 22-24, Applicant argues that GAUR does not cure the deficiency of GUPTA. This argument has been considered but is unpersuasive as GUAR teaches at ¶[0007]: determining, based on the reputation data, a reputation score, appending the identity with the reputation score as a metadata tag, and uploading the identity and the metadata tag to an ID repository and at GUAR: ¶[0153]: Process 600 continues with operation 610 where the operation output is injected into a block proposal. In some embodiments, the block is recorded on the ledger making a permanent record of the reputation score that is accessible by the entire network. For example, a block may record the reputation score that a driver profile has received and the rules that were used to determine the reputation score.)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 10719623 B1 to Miller discloses that status may be passed through blockchain attestations. Accordingly, sovereign status may be conferred through stored assertions that a particular identity should have sovereign status for a particular profile .
US 10979418 B2 to Kravitz discloses an embodiment provides an identity, attribute and reputation management framework that is fully compatible with block chain-based databases.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 BOLKO HAMERSKI whose telephone number is (571)270-7621. The examiner can normally be reached Monday-Friday 10:00 AM to 6: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, BENNETT SIGMOND can be reached at (303) 297-4411. 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.
BOLKO HAMERSKI
Examiner
Art Unit 3694
/BOLKO M HAMERSKI/Examiner, Art Unit 3694
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694