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 .
Status of the Claims
This is a FINAL Office Action rejection prepared in response to Applicant’s amendments filed on
11/19/2025.
Claims 1-2, 5, 8-10, 14-16 and 19-20 are amended.
Claims 1-20 are pending.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an
abstract idea without significantly more.
Step 1: Claims 1-14 are directed to computer-implemented method (i.e., process). Claims 15-18 are directed to a system (i.e., machine, and manufacture). Claims 19-20 are directed to a computer-storage media (i.e., manufacture). Therefore, these claims fall within the four statutory categories of
invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a
judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One: Claim 1, recites (i.e., sets forth or describes) an abstract idea. More specifically, the following bolded claim elements recite abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
A method for data management, comprising:
receiving, at a custodial token platform and from a client application on a user device, a request to generate an attestation record associated with a user profile of the custodial token platform;
verifying, at the custodial token platform after receiving the request, that data associated with the user profile satisfies one or more criteria indicated by a set of attributes for the requested attestation record;
signing, after verifying that the data associated with the user profile satisfies the one or more criteria, a first message that generates the attestation record using a key that is associated with the custodial token platform;
generating the attestation record by broadcasting the signed first message via a blockchain network, and
storing a mapping of an identifier for the attestation record and a self-custody blockchain address associated with the user profile by broadcasting a second message.
Claim 1, recites (i.e., sets forth or describes) a method directed to a process of managing user data. The claim achieves this by receiving a request to generate a verification record tied to a user profile, verifying that the user profile possesses certain attributes relevant to the requested verification and then transmitting a first signed message indicating the verification record and a second signed message to store the verification. Claim 15 and 19 are significantly similar to claim 1. As such claim 15 and 19 also recite an abstract idea. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas (i.e., managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions)).
Step 2A Prong Two: Because the claim recites abstract ideas, the analysis proceeds to
determine whether the claim recites additional elements that recite a practical application of the
abstract ideas. Here, the additional elements of a custodial token platform, a client application on a user device, a self-custody blockchain address and a blockchain network merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Therefore, the claim as a whole fail to recite a practical application of the abstract ideas.
Step 2B: Determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims: Claims 2-14, 16-18 and 20 have also been analyzed for subject matter
eligibility. However, claims 2-14, 16-18 and 20 also fail to recite patent eligible subject matter for the
following reasons:
Claims 2 and 16 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
The request is associated with the self-custody blockchain address and wherein the first message associates the attestation record with the self-custody blockchain address on the blockchain network.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a self-custody blockchain address and a blockchain network fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements are recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claims 3 and 17 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the mapping further comprises an identifier for the custodial token platform, a schema identifier for the attestation record, or both.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a custodial token platform fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claims 4 and 18 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
receiving, via the client application and prior to receiving the request to generate the attestation record, user input indicating the self-custody blockchain address;
generating, after receiving the request, a verification message to be signed via the self-custody blockchain address; and
verifying that the verification message is signed by a private key associated with the self-custody blockchain address, wherein the user profile is verified after verifying that the verification message is signed by the key.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a self-custody blockchain address and a client application fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element are recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 5 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
verifying that the user profile is associated with the set of attributes further comprises: accessing a user record that is managed by the custodial token platform and that is associated with the user profile; wherein verifying that the data associated with the user profile satisfies the one or more criteria indicated by the set of attributes for the requested attestation record is based at least in part on the accessing.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a custodial token platform fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 6 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the one or more criteria comprise a token balance, a geographic location, a know-your-customer status, an identity, or any combination thereof.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas.
Claim 7 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
verifying that the user profile is associated with the set of attributes comprises: obtaining information associated with the user profile from an external data source; and
determining whether the information associated with the user profile satisfies one or more criteria indicated by the set of attributes.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of an external data source fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claims 8 and 20 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
receiving, at the custodial token platform via user input at the client application, a request to revoke the attestation record; and
revoking the attestation record by broadcasting, after receiving the request to revoke the attestation record, a revocation message via the blockchain network.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a custodial token platform, a client application and a blockchain network fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element are recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 9 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
determining, after broadcasting the first message that the user profile is not associated with the set of attributes; and
revoking the attestation record by broadcasting, after determining that the user profile is not associated with the set of attributes, a revocation message via the blockchain network.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a blockchain network fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 10 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
generating the attestation record by broadcasting the first message comprises: calling a schema, for the attestation record, that is stored in a self-executing program on the blockchain network, by broadcasting the first message wherein the first message includes values that are to be included in fields defined by the schema.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a self-executing program and a blockchain network fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element are recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 11 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
receiving, from a service external to the custodial token platform, a query indicating a criterion associated with the user profile; and
transmitting, in response to the query, an indication of whether the criterion is satisfied by data of a user record associated with the user profile.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a custodial token platform fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 12 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
verifying that the request is received from a service trusted by the custodial token platform, wherein the first message is broadcast based at least in part on verifying that the request is received from the service trusted by the custodial token platform.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a custodial token platform fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element is recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 13 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
receiving, from a service external to the custodial token platform, a query indicating the self-custody blockchain address;
reading, from a smart contract that stores the mapping, the identifier for the attestation record; and
transmitting, in response to the query, an indication of the identifier for the attestation record.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a custodial token platform, a smart contract and a self-custody blockchain address fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element are recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim 14 recites the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
receiving, from a service trusted by the custodial token platform, a request to create a schema for the attestation record, wherein the client application is associated with the service and wherein
the first message is broadcast and calls the schema based at least in part on receiving the request from the client application that is associated with the service.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a custodial token platform and a client application fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element are recited at a high level generally amounting to no more than a tool to perform the abstract idea also failing to recite a practical application or significantly more than the abstract idea.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5-7, 10, 13, 15 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Oberhauser (US 20210218720 A1) in view of Gillian (US 20190281028 A1).
Regarding claims 1, 15 and 19, Oberhauser discloses:
receiving, at a custodial token platform and from a client application on a user device, a request to generate an attestation record associated with a user profile of the custodial token platform; (Oberhauser ¶0027, As one example, a data management service of a user may send attribute values (e.g., date of birth) to a data management service of a trusted party, and may request that the trusted party verify and attest to the attribute values. Oberhauser ¶0049, In some embodiments, the data collections 100A-B may include values of attributes of the entities A and B (e.g., a birth date, a social security number, a private key associated with a cryptocurrency address, an employer identification number, a device serial number, a building access code, etc.). Oberhauser ¶0148, If the asset owner wishes to transfer the digital asset to an asset recipient, the asset owner may submit a transfer request to the custodial key service. Oberhauser ¶0158, In some embodiments, the asset owner and the asset recipient may engage in a transaction via respective applications (not shown in FIG. 6). Oberhauser ¶0173, Returning to FIG. 7, if the counterparty check performed by the data management service 700A is successful, the data management service 700A may, at act 710, submit a transfer request to one or more custodians. For instance, the data management service 700A may establish a secure communication channel (e.g., with end-to-end encryption) with the data management service 700C, and may use the secure channel to send a transfer request to the data management service 700C. Oberhauser ¶0175, Additionally, or alternatively, the transfer request may include information about the asset recipient. For instance, in some embodiments, the transfer request may include a pointer to one or more attribute attestations of the asset recipient, a pointer to a smart contract that manages the one or more attribute attestations, one or more attribute values of the asset recipient, and/or one or more pointers to locations where the one or more attribute values may be fetched. The one or more attribute values may correspond, respectively, to the one or more attribute attestations)
verifying, at the custodial token platform after receiving the request, that data associated with the user profile satisfies one or more criteria indicated by a set of attributes for the requested attestation record; (Oberhauser ¶0149, In some embodiments, upon receiving a transfer request concerning a digital asset, the custodial key service may check an identity of an entity from which the transfer request is received to confirm that the entity is indeed an owner of the digital asset. Additionally, or alternatively, the custodial key service may check an identity of an asset recipient indicated in the transfer request. Oberhauser ¶0159, Upon receiving such a request, the custodian's data management service may perform one or more checks, such as checking an identity of the asset owner, checking an identity of the asset recipient, and/or verifying compliance with one or more digital asset transfer restrictions. Oberhauser ¶0177, At act 715, the custodian's data management service 700C may initiate a counterparty check to check one or more attribute attestations of the asset owner. This counterparty check may be performed in any suitable manner, for example, as described in the '643 application, and/or as described herein in connection with FIG. 4 and/or act 705 of FIG. 7. For instance, the data management service 700A may send, to the data management service 700C, a pointer to one or more attribute attestations of the asset owner, a pointer to a smart contract that manages the one or more attribute attestations, one or more attribute values of the asset owner, and/or one or more pointers to locations where the one or more attribute values may be fetched. The one or more attribute values may correspond, respectively, to the one or more attribute attestations. Oberhauser ¶0179, It should be appreciated that aspects of the present disclosure are not limited to performing act 715 in response to the transfer request of act 710. In some embodiments, the asset owner's data management service 700A may, prior to requesting a transfer, register the one or more digital assets with the custodian's data management service 700C. As part of a registration process, the custodian's data management service 700C may check one or more attribute attestations of the asset owner. Oberhauser ¶0182, Accordingly, in some embodiments, the data management service 700C may check that a distributed ledger address to which the one or more digital assets are to be transferred (e.g., a TO account indicated in the transfer request received at act 710) indeed belongs to an entity associated with the one or more attribute attestations accessed from the distributed ledger. Additionally, or alternatively, the one or more attribute attestations may be stored in a smart contract (and/or organized into a badge), and the data management service 700C may check that the distributed ledger address to which the one or more digital assets are to be transferred indeed belongs to an entity associated with the smart contract (and/or the badge). Oberhauser ¶0183, For instance, in some embodiments, the data management service 700C may check that the one or more attribute attestations include an attestation for a distributed ledger address attribute, and that the corresponding attribute value matches the distributed ledger address to which the one or more digital assets are to be transferred.)
signing, after verifying that the data associated with the user profile satisfies the one or more criteria, a first message that generates the attestation record using a key that is associated with the custodial token platform; (Oberhauser ¶0105, In some embodiments, the data management service 110B may sign an attestation, for example, using a private key associated with the entity B. Any suitable electronic signature scheme may be used, as aspects of the present disclosure are not so limited. In some embodiments, the entity B may have an associated distributed ledger address, and a private key associated with that distributed ledger address may be managed by the distributed ledger client 115B. The data management service 110B may cause the distributed ledger client 115B to use the private key to generate a signature over the attribute attestation. Oberhauser ¶0149, Once the transfer request is checked, the custodial key service may use the cryptographic key of the digital asset to sign the transfer request. In this manner, the asset owner may authorize the transfer without directly handling the cryptographic key. Oberhauser ¶0159, If the one or more checks are successful, the custodian's data management service may use one or more cryptographic keys associated with the one or more digital assets to authorize the proposed transfer. Oberhauser ¶0187, In some embodiments, if all of the one or more checks performed by the data management service 700C are successful, the data management service 700C may, at act 730, allow the proposed transfer to proceed. For example, the data management service 700C may sign a data structure storing information regarding the proposed transfer, and may return the signed data structure to the data management service 700A. The data structure may be in a format suitable for processing by a distributed ledger that is managing the one or more digital assets to be transferred, and the data management service 700C may sign the data structure using a cryptographic key that controls the one or more digital assets (e.g., one of M such keys).
generating the attestation record by broadcasting the signed first message via a blockchain network; and (Oberhauser ¶0106, At act 365, the data management service 110B may cause the one or more attribute attestations to be published to the distributed ledger. Oberhauser ¶0187, In some embodiments, if all of the one or more checks performed by the data management service 700C are successful, the data management service 700C may, at act 730, allow the proposed transfer to proceed. For example, the data management service 700C may sign a data structure storing information regarding the proposed transfer, and may return the signed data structure to the data management service 700A. The data structure may be in a format suitable for processing by a distributed ledger that is managing the one or more digital assets to be transferred, and the data management service 700C may sign the data structure using a cryptographic key that controls the one or more digital assets (e.g., one of M such keys). The data management service 700A may cause the signed data structure to be published to the distributed ledger, thereby effectuating the proposed transfer.)
Oberhauser further discloses:
one or more memories storing processor-executable code; and one or more processors coupled with the one or more memories and individually or collectively operable to execute the code to cause the apparatus (Oberhauser ¶0191, FIG. 8 shows, schematically, an illustrative computer 1000 on which any aspect of the present disclosure may be implemented. In the embodiment shown in FIG. 8, the computer 1000 includes a processing unit 1001 having one or more computer hardware processors and one or more articles of manufacture that comprise non-transitory computer-readable storage media (e.g., system memory 1002) that may include, for example, volatile and/or non-volatile memory. The memory 1002 may store one or more instructions to program the processing unit 1001 to perform any of the functions described herein. The computer 1000 may also include other types of non-transitory computer-readable media, such as storage 1005 (e.g., one or more disk drives) in addition to the system memory 1002. The storage 1005 may also store one or more application programs and/or external components used by application programs (e.g., software libraries), which may be loaded into the memory 1002. To perform any of the functionality described herein, processing unit 1001 may execute one or more processor-executable instructions stored in the one or more non-transitory computer-readable storage media (e.g., memory 1002, storage 1005), which may serve as non-transitory computer-readable storage media storing processor-executable instructions for execution by the processing unit 1001.)
Oberhauser does not disclose, however Gillian teaches:
storing a mapping of an identifier for the attestation record and a self-custody blockchain address associated with the user profile by broadcasting a second message. (Gillian ¶0057, The attestation contract can further include a method to store the message and any additional data about the authentication attempt (e.g. time stamps, channel authentication was sought, etc.) or the authentication response message (e.g. time stamps, hardware identifiers, etc.). This data is stored in the distributed ledger provided by the blockchain and can serve as an audit trail of authentication attempts and grants. The attestation contract can provide a method for storing and querying these attested authentication response messages… In other embodiments, the attestation contract can provide a means to send a message to secure resource upon receiving a verified authentication response message. Secure resource 120 can observe this verification result by periodically polling the attestation contract to determine whether to grant access to the secure resource 120 and the requested account data A1 121. In other embodiments, the attestation contract can provide a means to send a message to secure resource upon receiving a verified authentication response message.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modify Oberhauser by incorporating Gillian’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to ensure that the attestation record is permanently and verifiably tied to the user’s self-custody blockchain address in a way that can be easily discovered and used by others.
Regarding claims 2 and 16, Oberhauser and Gillian disclose each and every element of claim 1 and 15. Oberhauser further discloses:
the request is associated with the self-custody blockchain address and (Oberhauser ¶0068, In some embodiments, the entity A may have a distributed ledger address, and the referenced distributed ledger transaction may be signed using a private key associated with that distributed ledger address. Oberhauser ¶0174, In some embodiments, the transfer request may indicate a distributed ledger address where the one or more digital assets to be transferred are currently held (e.g., a FROM account), one or more respective amounts of the one or more digital assets to be transferred, and/or a distributed ledger address to which the one or more digital assets are to be transferred (e.g., a TO account).
wherein the first message associates the attestation record with the self-custody blockchain address on the blockchain network. (Oberhauser ¶0073, The data management service 110B may cause the distributed ledger client 115B to use the private key to generate a signature over the attribute attestation. In this manner, an entity checking the attribute attestation (e.g., an illustrative entity C in the example of FIG. 4) may use the entity B's distributed ledger address to look up a public key from the distributed ledger, and may use that public key to check the signature over the attribute attestation.)
Further, the claimed limitation “the request is associated with the self-custody blockchain address” is non-functional material that does not move to distinguish over prior art as it does not affect the recited steps in claim 1.
Regarding claims 3 and 17, Oberhauser and Gillian disclose each and every element of claim 1 and 15. Oberhauser further discloses:
the mapping further comprises an identifier for the custodial token platform, a schema identifier for the attestation record, or both. (Oberhauser ¶0063, In some embodiments, an attestation may include one or more items of metadata, such as metadata indicating how a cryptographic proof in the attestation was generated and/or how the cryptographic proof is to be checked. For instance, the attestation may include metadata identifying a cryptographic scheme (e.g., a cryptographic hash function, an asymmetric cryptosystem, etc.) used to generate the cryptographic proof. Additionally, or alternatively, an attestation may include metadata indicating that the attestation is to be signed by a selected entity (e.g., the entity B). However, it should be appreciated that aspects of the present disclosure are not limited to having any particular type of metadata, or any metadata at all, in an attestation.)
Regarding claim 5, Oberhauser and Gillian disclose each and every element of claim 1. Oberhauser further discloses:
verifying that the user profile is associated with the set of attributes further comprises: accessing a user record that is managed by the custodial token platform and that is associated with the user profile; wherein verifying that the data associated with the user profile satisfies the one or more criteria indicated by the set of attributes for the requested attestation record is based at least in part on the accessing. (Oberhauser ¶0109, At act 375, the data management service 110A may cause a received attribute value to be confirmed. For instance, the entity A may be prompted to review the attribute value. Additionally, or alternatively, the data management service 110A may verify whether the attribute value is consistent with one or more other attribute values in a data collection of the entity A (the illustrative data collection 100A in the example of FIG. 1A). Oberhauser ¶0110, Additionally, or alternatively, the data management service 110A may use the distributed ledger reference sent to the data management service 110B at act 355 to look up a corresponding attribute attestation from the distributed ledger, and may perform one or more checks. For instance, the data management service 110A may check that: (i) a cryptographic proof in the attribute attestation is generated from the received attribute value using a cryptographic scheme indicated in the attribute attestation, and/or (ii) the attribute attestation is signed using the entity B's private key. Oberhauser ¶0111, Additionally, or alternatively, the data management service 110A may authenticate the one or more attribute values by checking that the one or more attribute values are signed using the entity B's private key.)
Regarding claim 6, Oberhauser and Gillian disclose each and every element of claim 5. Oberhauser further discloses:
the one or more criteria comprise a token balance, a geographic location, a know-your-customer status, an identity, or any combination thereof. (Oberhauser ¶0049, In some embodiments, the data collections 100A-B may include values of attributes of the entities A and B (e.g., a birth date, a social security number, a private key associated with a cryptocurrency address, an employer identification number, a device serial number, a building access code, etc.). Cryptographic proofs (e.g., salted hashes) of such attribute values may be stored in the distributed ledger states 105A-B, which may be managed by the distributed ledger clients 115A-B. Oberhauser ¶0062, For instance, the entity A's data collection (e.g., the illustrative data collection 100A in the example of FIG. 1A) may include attribute values such as date of birth, passport number, credit card number, mailing address, annual income, etc.)
Regarding claim 7, Oberhauser and Gillian disclose each and every element of claim 1. Oberhauser further discloses:
verifying that the user profile is associated with the set of attributes comprises: obtaining information associated with the user profile from an external data source; and (Oberhauser ¶0027, The trusted party may verify the attribute values in any suitable manner, for instance, by reviewing physical documents (e.g., the user's passport). Oberhauser ¶0069, At act 320, the data management service 110B may cause a received attribute value to be verified directly, for example, by physically examining documentation (e.g., passport, credit card, utility statement, paystub, etc.) and/or biometric features (e.g., fingerprint, iris, voice, etc.).
determining whether the information associated with the user profile satisfies one or more criteria indicated by the set of attributes. (Oberhauser ¶0027, If the verification is successful, the trusted party may attest to the attribute values, for instance, by electronically signing cryptographic proofs of the attribute values. )
Regarding claim 10, Oberhauser and Gillian disclose each and every element of claim 1. Oberhauser further discloses:
generating the attestation record by broadcasting the first message comprises: calling a schema, for the attestation record, that is stored in a self-executing program on the blockchain network, by broadcasting the first message wherein the first message includes values that are to be included in fields defined by the schema. (Oberhauser ¶0063, In some embodiments, an attestation may include one or more items of metadata, such as metadata indicating how a cryptographic proof in the attestation was generated and/or how the cryptographic proof is to be checked. For instance, the attestation may include metadata identifying a cryptographic scheme (e.g., a cryptographic hash function, an asymmetric cryptosystem, etc.) used to generate the cryptographic proof. Additionally, or alternatively, an attestation may include metadata indicating that the attestation is to be signed by a selected entity (e.g., the entity B). However, it should be appreciated that aspects of the present disclosure are not limited to having any particular type of metadata, or any metadata at all, in an attestation. Oberhauser ¶0073, Any suitable electronic signature scheme may be used, as aspects of the present disclosure are not so limited. In some embodiments, the entity B may have an associated distributed ledger address, and a private key associated with that distributed ledger address may be managed by the illustrative distributed ledger client 115B in the example of FIG. 1B. Oberhauser ¶0083, For instance, the data management service 110C may check that: [0084] (i) an entity that signed the attestation (e.g., the illustrative entity B in the example of FIG. 1A) is trusted by the entity C (e.g., by looking up a list of trusted entities); [0085] (ii) a cryptographic proof in the attestation is generated from a corresponding attribute value received from the entity A, and is generated using a cryptographic scheme indicated in the attestation; Oberhauser ¶0182, Additionally, or alternatively, the one or more attribute attestations may be stored in a smart contract (and/or organized into a badge), and the data management service 700C may check that the distributed ledger address to which the one or more digital assets are to be transferred indeed belongs to an entity associated with the smart contract (and/or the badge).)
Regarding claim 13, Oberhauser and Gillian disclose each and every element of claim 1. Oberhauser further discloses:
receiving, from a service external to the custodial token platform, a query indicating the self-custody blockchain address; (Oberhauser ¶0066, At act 315, the data management service 110A may send the one or more selected attribute values to the data management service 110B via a secure channel that is outside the distributed ledger. Oberhauser ¶0067, In some embodiments, the data management service 110A may send, via the secure channel to the data management service 110B, a distributed ledger reference that may be used by the data management service 110B to look up the one or more attribute attestations from the distributed ledger.) Oberhauser ¶0068, In some embodiments, the entity A may have a distributed ledger address, and the referenced distributed ledger transaction may be signed using a private key associated with that distributed ledger address.) Oberhauser ¶0079, In some embodiments, the data management service 110A may send, via the secure channel to the data management service 110C, a distributed ledger reference that may be used by the data management service 110C to look up, from the distributed ledger, the one or more attestations corresponding, respectively, to the one or more attributes indicated by the entity C.)
reading, from a smart contract that stores the mapping, the identifier for the attestation record; and (Oberhauser ¶0067, For instance, the distributed ledger client 115A may be implemented using a smart contract, and the distributed ledger reference may include a reference to a distributed ledger transaction whereby the smart contract is recorded on the distributed ledger. Additionally, or alternatively, the one or more attribute attestations may be organized into a badge, and the distributed ledger reference may include a reference to a distributed ledger transaction whereby the badge is recorded on the distributed ledger. Oberhauser ¶0080, In some embodiments, a distributed ledger client used by the entity A (e.g., the illustrative distributed ledger client 115A in the example of FIG. 1B) may be implemented using a smart contract, and the distributed ledger reference sent to the data management service 110C may include a reference to a distributed ledger transaction whereby the smart contract is recorded on the distributed ledger. Additionally, or alternatively, the one or more attestations may be organized into a badge, and the distributed ledger reference may include a reference to a distributed ledger transaction whereby the badge is recorded on the distributed ledger.)
transmitting, in response to the query, an indication of the identifier for the attestation record. (Oberhauser ¶0071, Accordingly, in some embodiments, the data management service 110A may provide, to the data management service 110B, a distributed ledger reference to an attestation previously signed by another entity, where the previously signed attestation is for the same attribute value being verified by the data management service 110B. The data management service 110B may look up the previously signed attestation from the distributed ledger, and may perform one or more checks. Oberhauser ¶0081, The data management service 110A may send the signature to the data management service 110C along with the attribute value. This may bind the attribute value to the referenced distributed ledger transaction, because the data management service 110C may use the distributed ledger address to look up a public key from the distributed ledger, and may use that public key to check that both the attribute value and the referenced distributed ledger transaction are signed using the same private key. Oberhauser ¶0082, At act 410, the data management service 110C may use a distributed ledger reference received at act 405 to retrieve one or more attestations from a distributed ledger.)
Claims 4, 8-9, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Oberhauser and Gillian as applied to claims 1, 15 and 19 above, and further in view of Smith (US 2017/0317997 A1).
Regarding claims 4 and 18, Oberhauser and Gillian disclose each and every element of claim 1 and 15. The combination does not disclose, however Smith teaches:
receiving, via the client application and prior to receiving the request to generate the attestation record, user input indicating the self-custody blockchain address; (Smith ¶0020, receiving at a processor associated with a verifier the information of the user; Smith ¶0084, In some embodiments, receiving at a processor associated with a user, information and a public key of the digital entity includes sending a request to a processor associated with the digital entity a request for the information and public key of the digital entity. Smith ¶0090, A system for providing verification of the identity of a digital entity is provided, the system includes a computer system having one or more physical processors configured by machine-readable instructions to receive at a processor associated with a user, information and a public key of the digital entity, wherein the information has been previously attested to in an attestation transaction stored within a centralized or distributed ledger at an attestation address, the centralized or distributed ledger providing a record of transactions; derive an attestation address using the information and the public key of the digital entity; verify the existence of the attestation transaction at the attestation address in the centralized or distributed ledger and that the attestation transaction has not been revoked;
generating, after receiving the request, a verification message to be signed via the self-custody blockchain address; and (Smith ¶0020, …sending a cryptographic challenge nonce; Smith ¶0062, In some embodiments, sending a cryptographic challenge nonce includes sending a cryptographic challenge nonce to a digital wallet of the user. Smith ¶0090, send a cryptographic challenge nonce to a processor associated with the digital entity;)
verifying that the verification message is signed by a private key associated with the self-custody blockchain address, wherein the user profile is verified after verifying that the verification message is signed by the key. (Smith ¶0020, receiving at the processor associated with the verifier the cryptographic challenge nonce signed by the user's private key; verifying user identity with the cryptographic challenge nonce signed by the user's private key. Smith ¶0062, In some embodiments, receiving the cryptographic challenge nonce signed by the user's private key includes receiving from the digital wallet of the user the cryptographic challenge nonce signed by the user's private key. Smith ¶0077, receive at the processor associated with the merchant the cryptographic challenge nonce signed by the user's private key; and verify user identity with the cryptographic challenge nonce signed by the user's private key and the user's public key. Smith ¶0090, receive at the processor associated with the user the cryptographic challenge nonce signed by the digital entity's private key; and verify the digital entity's identity with the cryptographic challenge nonce signed by the digital entity's key.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modify Oberhauser and Gillian combination with Smith’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to validate and verify the address to ensure it is a valid address and the user is the owner of it.
Regarding claims 8 and 20, Oberhauser and Gillian disclose each and every element of claim 1 and 19. The combination does not disclose, however Smith teaches:
receiving, at the custodial token platform via user input at the client application, a request to revoke the attestation record; and (Smith ¶0189, The user 110 or attestor 120 may revoke an attestation made in the past with use of a revocation protocol 212. The revocation protocol 212 may utilize a third party digital wallet provider or other third party cosigner, or it may be performed solely by the user 110 or attestor 120, or by the user 110 and the attestor 120. The revocation protocol 212 may be performed using a mobile application or a web-based client or cloud service, as examples. A participant may be allowed to revoke an attestation they have made in the past by signing a new transaction, spending the dust corresponding to the original attestation. Smith ¶0193, The signed transaction in the ledger may be revoked by the user or attestor using a revocation protocol. Smith ¶0199, In one embodiment, the revocation could be initiated by a user because of a fear of a data breach. In one embodiment, this information could be identified by an attestor that had previously attested to information from this user, and who has identified that some of the previously attested to information is no longer valid.)
revoking the attestation record by broadcasting, after receiving the request to revoke the attestation record, a revocation message via the blockchain network. (Smith ¶0197, Beginning at a start block 502 of FIG. 5a, a new signed transaction is generated to revoke the previous attested information (step 504 of FIG. 5a). In one embodiment, there is an attestation transaction associated with the previously attested information. The new, signed transaction is then sent over the network to the centralized or distributed ledger (step 506 of FIG. 5a) which revokes the attestation transaction by spending cryptocurrency associated with the attestation transaction. The flowchart 500 of FIG. 5a ends at a finish block 508. Smith ¶0199, At step 506, the new signed transaction is sent to the centralized or distributed ledger, thereby spending the cryptocurrency associated with the previous attestation transaction. At step 507a, it is determined whether there is new information that needs to be attested to.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modify Oberhauser and Gillian combination with Smith’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to ensure that attestations can be invalidated and revoke in a way that is verifiable and immediately visible to others.
Regarding claim 9, Oberhauser and Gillian disclose each and every element of claim 1. The combination does not disclose, however Smith teaches:
determining, after broadcasting the first message that the user profile is not associated with the set of attributes; and (Smith ¶0197, FIG. 5a, it is noted that an attestation transaction authenticating information has already been generated and stored in the centralized or distributed ledger. In one embodiment, the revocation protocol is used to remove information that has previously been attested to. If a user had attested to a deed for some property that they owned, and later sold the property, then the user may wish to revoke the attestation transaction. In one embodiment, the attestor wants to revoke the attested information. For example, if a driver's license needed to be revoked for some sort of offense, then the department of motor vehicles, who may be the original attestor to this information, would revoke the driver's license. In another example, the attestor may be different from the issuer of the information that needs to be revoked, but may still be the party that revokes the transaction. For example, the attestor may discover that somehow a user had created an account at the attestor using fraudulent identification, and then the attestor would revoke the attestation that the user had created. In one embodiment, the user may wish to revoke their own attested information, for example, if they thought it had been compromised. In one embodiment, the revocation protocol is used to change information that has been previously attested to. If a user had previously attested to personal information including an address and a credit card number, and then the credit card number changed, the user could use the revocation protocol to change the credit card information in the attested information. Smith ¶0199, The protocol begins at start block 502. Previously attested-to information, that is captured in an attestation transaction at an attestation address, that needs to be removed or changed, is identified. In one embodiment, this information could be identified by the user, for example because some personal information like an address, driver's license number, or credit card number has changed. In one embodiment, the revocation could be initiated by a user because of a fear of a data breach. In one embodiment, this information could be identified by an attestor that had previously attested to information from this user, and who has identified that some of the previously attested to information is no longer valid. In one embodiment, an attestor could identify information that needs to be revoked because a user no longer is in existence. In one embodiment, a third party may request that previously attested to information is revoked, for example in the instance of a relationship that was established between the user and the third party which has become invalid.
revoking the attestation record by broadcasting, after determining that the user profile is not associated with the set of attributes, a revocation message via the blockchain network. (Smith ¶0197, Beginning at a start block 502 of FIG. 5a, a new signed transaction is generated to revoke the previous attested information (step 504 of FIG. 5a). In one embodiment, there is an attestation transaction associated with the previously attested information. The new, signed transaction is then sent over the network to the centralized or distributed ledger (step 506 of FIG. 5a) which revokes the attestation transaction by spending cryptocurrency associated with the attestation transaction. The flowchart 500 of FIG. 5a ends at a finish block 508. Smith ¶0199, At step 506, the new signed transaction is sent to the centralized or distributed ledger, thereby spending the cryptocurrency associated with the previous attestation transaction. At step 507a, it is determined whether there is new information that needs to be attested to.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modify Oberhauser and Gillian combination with Smith’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to ensure that attestations can be invalidated and revoke in a way that is verifiable and immediately visible to others.
Claims 11 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Oberhauser and Gillian as applied to claim 1 above, and further in view of Soundararajan (US 2020/0044831 A1).
Regarding claim 11, Oberhauser and Gillian disclose each and every element of claim 1. The combination does not disclose, however Soundararajan teaches:
receiving, from a service external to the custodial token platform, a query indicating a criterion associated with the user profile; and (Soundararajan ¶0148, A secured identity verifier server system 1800 (referred to herein as "secured identity verifier 1800") may be configured to receive queries from a third party verifier system 1700 to determine if a distributed attestation is owned by or otherwise associated with an attestation holder ( e.g., by querying blockchain address mapping server system 600). Soundararajan ¶0166, At operation 2110, verifier 1800 receives, from a server system, a request from an entity ( e.g., third party verifier) to determine if a distributed attestation stored on a blockchain is associated with an attestation holder.
transmitting, in response to the query, an indication of whether the criterion is satisfied by data of a user record associated with the user profile. (Soundararajan ¶0164, Afterward, system 1700 may receive a message from the secured identity verifier 1800 confirming that the claimant is the distributed attestation holder. In response, a service may be performed for the claimant. Alternatively, in cases where the distributed attestation does not include any secured representations of blockchain addresses associated with the claimant, system 1700 may receive a message from the verifier 1800 indicating that the claimant is not the distributed attestation holder. Soundararajan ¶0168, If the entity is authorized to obtain information from the distributed attestation transaction, at operation 2130 verifier 1800 may transmit a response message to the entity indicating if the claimant of the distributed attestation is associated with (e.g., the holder of) the distributed attestation. In implementations, the response message may not share any information about the distributed attestation other than confirming that the claimant of the distributed attestation is ( or is not) the attestation holder.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modify Oberhauser and Gillian combination with Soundararajan ‘s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to allow the platform to act as a trusted verifier for external services. The platform sends a simple confirmation to the externa service indicating whether a condition is met, therefore protecting the privacy and sensitive information in the platform.
Regarding claim 12, Oberhauser and Gillian disclose each and every element of claim 1. The combination does not disclose, however Soundararajan teaches:
verifying that the request is received from a service trusted by the custodial token platform, wherein the first message is broadcast based at least in part on verifying that the request is received from the service trusted by the custodial token platform. (Soundararajan ¶0148, A secured identity verifier server system 1800 (referred to herein as "secured identity verifier 1800") may be configured to receive queries from a third party verifier system 1700 to determine if a distributed attestation is owned by or otherwise associated with an attestation holder ( e.g., by querying blockchain address mapping server system 600). It may also be configured to determine if the third party verifier is authorized, based on its identity, to verify attestation identities ( e.g., determine actual identities of parties associated with secured represent of blockchain addresses) contained in a distributed attestation. In particular implementations, secured identity verifier may be configured to determine if the third party verifier has role based access to obtain any information about a distributed attestation. Soundararajan ¶0167, At operation 2120, verifier 1800 decrypts the message ( e.g., using its private key and public key of entity), and uses the public key of the entity to determine whether the entity (e.g., third party verifier) is authorized to obtain information about the distributed attestation. In particular implementations, secured identity verifier may use the public key of the entity to determine if the entity has role based access rights to obtain any information ( e.g., identities associated with secured representations of blockchain addresses) about the distributed attestation. This determination may be made in accordance with a role based access control configured for a plurality of third party verifiers, where the role based access control may be used to validated if a third party verifier has rights to access information from a distributed attestation. Soundararajan ¶0168, If the entity is authorized to obtain information from the distributed attestation transaction, at operation 2130 verifier 1800 may transmit a response message to the entity indicating if the claimant of the distributed attestation is associated with (e.g., the holder of) the distributed attestation. In implementations, the response message may not share any information about the distributed attestation other than confirming that the claimant of the distributed attestation is ( or is not) the attestation holder.)
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modify Oberhauser and Gillian combination with Soundararajan ‘s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to ensure that only authorized providers receive the information requested.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Oberhauser and Gillian as applied to claim 1 above, and further in view of Guntin (US 2022/0083518 A1).
Regarding claim 14, Oberhauser and Gillian disclose each and every element of claim 1. The combination does not disclose, however Guntin teaches:
receiving, from a service trusted by the custodial token platform, a request to create a schema for the attestation record, wherein the client application is associated with the service and wherein (Guntin ¶0027, One or more aspects of the subject disclosure include a method for receiving a request to create a schema, receiving a schema identifier, user type, and item identifier, the item identifier identifying one or more items to which the schema is to be applied to, generating a plurality of schema elements based on user-generated input, and recording in a database a plurality of records associated with the schema, the records including the schema identifier, the item identifier, and the plurality of schema elements,… Guntin ¶0087, The method 1000 can begin at step 1002 where the schema management system 100 can be configured for receiving a request to create a schema. At step 1004 the schema management system 100 can be configured for receiving a schema identifier, user type, and item identifier, the item identifier identifying one or more items to which the schema is to be applied to. The item identifier can represent, for example, a client identifier or other suitable identifier for identifying a tangible or intangible object.)
Oberhauser further discloses:
the first message is broadcast and calls the schema based at least in part on receiving the request from the client application that is associated with the service. (Oberhauser ¶0072, In some embodiments, the data management service 110B may check that a cryptographic proof in each such attribute attestation is generated from the corresponding received attribute value, using a cryptographic scheme indicated in the attribute attestation. ¶0104, In some embodiments, an attestation may include one or more items of metadata, such as metadata indicating how a cryptographic proof in the attestation was generated and/or how the cryptographic proof is to be checked. For instance, the attestation may include metadata identifying a cryptographic scheme (e.g., a cryptographic hash function, an asymmetric cryptosystem, etc.) used to generate the cryptographic proof.
It would have been obvious to one of ordinary skill in the art, before the effective filing date
of the claimed invention, to have modify Oberhauser and Gillian combination with Soundararajan ‘s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to enable the trusted service provider to define a custom schema specifying the structure and rules according to the service provider’s requirements.
Furthermore, the claimed limitation “wherein the client application is associated with the service” is non-functional material that does not move to distinguish over prior art as it does not affect the recited steps in claim 1.
Response to Arguments
Claim Rejections – 35 U.S.C. § 101
The applicant presents three assertions, i.e., “the claims do not recite a judicial exception” and “the claims recite features that integrate any alleged judicial exception into a practical application”. The basis of these assertions are based on the applicant’s argument on pages 8-14.
Regarding the assertion that “the claims do not recite a judicial exception”, the applicant further asserts that “the claims do not recite a method for organizing human activity because they do not recite features related to the type of activities which the courts classify as managing behavior or relationships or interactions between people, the office action has not provided any support for this assertion and the amended claim recites features that do not relate to any type of “non-technical human activity”, "fundamental activity that forms the basis of our democracy", "tracking financial transactions," etc. for which the courts relate to "methods of organizing human activity." The examiner respectfully disagrees with these assertions. The claim recites operations that fall within the category of certain methods of organizing human activity, specially managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions as classified on the non-final rejection. The steps of “receiving a request to generate an attestation record, verifying the data associated with the user profile, and generating and storing a record of the attestation” amount to evaluating and certifying user information that can be used for further processes. According to USPTO guidance collecting information, analyzing it to determine whether it meets certain requirements and providing a result is an abstract idea that can be performed conceptually. Verifying user information and issuing an attestation is analogous to practices such identity verification and credential issuing, which are forms of managing relationships or interactions between people or organizations, even when implemented on a computing device. Moreover, the applicant asserts that the office provides no support for the assertion that the features of independent claim 1 fall under Certain Methods of Organizing Human Activity”. The examiner also disagrees with this assertion. With this assertion the applicant is attempting to conflate the Step 2A, 1st prong, test , with Step 2A, 2nd prong test. As per MPEP 2106.04(a), in step 2A prong one to determine whether a claim recites an abstract idea, the specific limitations in the claim under examination must be identified and analyzed to determine
whether they fall within at least one of the recognize groupings of abstract ideas. If one of the limitations in the examined claim falls within one of the groups, it is reasonable to conclude that the claims recite an abstract idea and the examination continues to step 2A prong two.
Regarding the assertion that “the claims recite features that integrate any alleged judicial exception into a practical application”, the applicant further asserts that “the claims are directed to an improvement to a relevant technology, which is recognize as an example of an additional element that integrates the exception into a practical application”. According to the applicant the alleged judicial exception is integrated into a practical application because “they access to blockchain network functionality and systems”, “increase the establishment of decentralized identities for users via on-chain attestations and provide greater support for many different parties participating in blockchain networks” and “supports improved flexibility, ease and access to distributed computing system and services via on-chain attestations”. The examiner respectfully disagrees with these assertions. Under Step 2A prong two, the claim as a whole is analyzed to determine if it integrates the judicial exception into a practical application. Here the additional elements of a custodial token platform, a client application on a user device, a self-custody blockchain address and a blockchain network do not integrate the judicial exception into a practical application because they merely use generic computer and blockchain technology as tools to perform the underlining abstract idea of receiving a request to verify user information, verifying user information and issuing an attestation. The claims do not recite any specific technical improvement to how the computer device or the blockchain network operates, how the information is validated or how the network security is improved. Further, the alleged benefits identified by the applicant such as improved flexibility, ease and access to distributed computing system and services via on-chain attestations describe advantages of using the blockchain to implement the abstract idea but not improvement upon it. Therefore, the claim does not recite any technological advancement or inventive integration beyond applying these tools to an abstract concept and thus fail to impose any meaningful limit that would transform the abstract idea into a practical application under the second prong of step 2A of the subject matter eligibility framework.
As such the claims remain within an abstract idea and rejection is maintained based on the
newly amended claims.
Claim Rejections – 35 U.S.C. § 103
Examiner has carefully reviewed and considered Applicant’s remarks in regards to 35 U.S.C. § 103. The applicant asserts that Oberhauser describes a trusted party verifying one or more demographic attributes and generating an attestation. The applicant asserts that this does not suggest verifying at the token platform the attributes and generating the attestation by the token platform. However, the examiner respectfully disagrees with these assertions. Oberhauser teaches a system in where an entity (i.e. a data management, a verification service, a bank, a custodian) receives a request to verify one or more attributes, verifies the attribute values and generates a verification record. The reference teaches the same entity (i.e. entity B) that receives the request performing the verification and generating the attestation. Thus, the reference does not require another entity to perform the verification and/or attestation as argued by the applicant. Rather the same entity (i.e. a data management, a verification service, a bank, a custodian) itself performs the validation and attestation once it receives the request.
Further, the applicant asserts that Oberhauser describes checking one or more demographic attributes, such as birth date or social security number is not the same as and does not teach “verifying… that data associated with the user profile satisfies one or more criteria indicated by a set of attributes for the requested attestation record” because birth date or social security number are not the same as “one or more criteria indicated by a set of attributes” as recited in amended claim 1. The examiner respectfully disagrees with this assertion. Oberhauser teaches verifying attributes associated with a user, including and not limited to demographics, passport number, driver’s license number, birth date, social security number, credit card number, mailing address, annual income, etc. Such attributes match to criteria use to confirm identity or eligibility and therefore corresponds to “one or more criteria indicated by a set of attributes”. Accordingly, the rejection under 35 U.S.C. § 103 is maintained.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 2023/0027100 A1 to Bolser et al. discloses: Broadly speaking, embodiments of the present techniques provide methods and systems to enable a user to securely share user information with a third party. The user information is based on a user data item, but the user data item itself is kept secret and not shared with the third party. The present techniques generate a digital attestation or verifiable credential containing the user information to Receiving an attestation request for a fact be shared.
US 2016/0162897 A1 to Feeney discloses: A method for crypto-currency transaction authentication includes receiving, by a computing device, from a data storage device associated with a first entity, an authentication information demonstrating possession of a private key, retrieving, by the computing device, from an audit chain, at least one crypto-currency transaction to an address associated with a public key corresponding to the private key, and authenticating, by the computing device, based on the retrieved crypto-currency transaction, the first entity.
WO 20191795543 A2 to Qiu et el. discloses: NOVELTY - The method (600) involves sending (602) an attestation request that requests an attestation evidence from the relay system node to a relay system node by a relay system controller. An attestation evidence of the relay system node is received (604) from the relay system node at the relay system controller. The attestation evidence of the relay system node is sent (606) to an attestation verification server by the relay system controller. An attestation verification report is received (608) from the attestation verification server by the relay system controller. The attestation verification report comprises the attestation evidence of the relay system node, an attestation verification result, and a digital signature of the attestation verification server. The attestation verification report is sent (610) to a relay system smart contract by the relay system controller.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JANICE LOZA whose telephone number is (571)270-3979. The examiner can normally be reached Monday - Friday 7:30am - 5:00pm.
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, Patrick McAtee can be reached at (571) 272-7575. 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.
/J.L./Examiner, Art Unit 3698
/STEVEN S KIM/Primary Examiner, Art Unit 3698