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 Objections
Claims 1-2, 4-17, 19-20, and 22-24 are objected to because of the following informalities:
Regarding claim 1:
the individual method steps are not separated by commas or semicolons;
the phrase “while said method” is grammatically incorrect and should be revised, for example, to “wherein said method”;
and the phrase “providing of at least one risk management verification data” is grammatically incorrect as data is plural and it is unclear what is meant with “at least one risk management verification data”, and should be revised for clarity, for example, to “providing risk management verification data”
Appropriate correction is required.
Claims 2, 4-17, 19-20, and 22-24 depend on object claim 1 and inherit all the limitations of claim 1 and do not overcome the objections raised in their parent claim and are objected for the same reasons as those provided in the objection of claim 1.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
Claim 14 recites a “data processing system comprising means for carrying out the steps of the method according to claim 1.” The phrase “means for” is followed by functional language and does not recite sufficient structure for carrying out the recited functions. Accordingly, the limitation is interpreted under 35 U.S.C. 112(f) to cover the corresponding structure, material, or acts described in the specification for carrying out the steps of claim 1, and equivalents thereof.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 2, 4-17, 19-20, and 22-24 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recites, in part, “receiving at least two verification requests regarding the person or organization via said first computing device in the computing network,” “providing of at least one risk management verification data, at least based on information delivered in the at least two verification requests,” and “creating at least one tokenized personal identification data in a decentralized computer network,” wherein the tokenized personal identification data “consider” the risk management verification data.
The specification describes particular embodiments involving KYC verification, AML verification, cryptocurrency wallet ownership verification, risk scores/risk levels generated from such verification information, and a CryptoPass or cryptographic token generated from that information. However, claim 1 is not limited to KYC, AML, wallet ownership verification, cryptocurrency-related verification, the disclosed risk scores/risk levels, or the disclosed CryptoPass/token generation process. Instead, claim 1 broadly encompasses any two verification requests regarding a person or organization, any risk management verification data based on information delivered in those requests, and any tokenized personal identification data that merely “consider” the risk management verification data.
The specification does not describe a representative number of species or common identifying characteristics sufficient to reasonably convey to a person of ordinary skill in the art that applicant had possession of this broader functional genus. The disclosure is directed to specific KYC, AML, wallet ownership, risk-score/risk-level, and CryptoPass implementations, and does not reasonably convey possession of the full scope of the broadly claimed functional limitations.
As explained in MPEP § 2161.01, written description issues may arise when claim language is generic or functional, or both. See Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1350-51 (Fed. Cir. 2010) (en banc). The specification must show that the applicant was in possession of the claimed invention as broadly claimed, not merely of one or more disclosed embodiments. See also LizardTech, Inc. v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1344-46 (Fed. Cir. 2005).
Here, the specification describes particular KYC, AML, wallet ownership verification, risk information, and CryptoPass implementations. It does not reasonably convey possession of the broader claimed functional concepts of any verification requests, any risk management verification data based on such requests, and any tokenized personal identification data that merely considers such risk management verification data, as encompassed by claim 1.
Claims 2, 4-17, 19-20, and 22-24 depend directly or indirectly from claim 1 and do not cure the written description deficiency.
Claims 14-17 and 19-20 are rejected separately and in addition to the earlier rejection under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph, because the claims purports to invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, but fail to recite a combination of elements as required by that statutory provision and thus cannot rely on the specification to provide the structure, material or acts to support the claimed function. As such, the claims recite a function that has no limits and covers every conceivable means for achieving the stated function, while the specification discloses at most only those means known to the inventor. Accordingly, the disclosure is not commensurate with the scope of the claim.
Claims 15-17 and 19-20 depend directly or indirectly from claim 14 and do not cure the written description deficiency.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-2, 4-17, 19-20, and 22-24 areare rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre -AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 is rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “Providing a connection of a first computing device in a computer network” is unclear as to who performs the step and what action is required. Therefore, the metes and bounds of claim 1 are not reasonably certain.
Claim 1 is further rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “Receiving at least two verification requests regarding the person or organization via said first computing device in the computing network” is unclear as to who receives the verification requests, where the requests are received, and what constitutes a verification request. Therefore, the metes and bounds of claim 1 are not reasonably certain.
Claim 1 is further rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “Providing of at least one risk management verification data, at least based on information delivered in the at least two verification requests in the computer network” is grammatically unclear and does not clearly identify who provides the data, what constitutes the risk management verification data, or what specific action is required. Therefore, the metes and bounds of claim 1 are not reasonably certain.
Claim 1 is further rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “while said tokenized personal identifications data consider at least the risk management verification data” does not reasonably apprise a person of ordinary skill in the art of the metes and bounds of the claims. The term “consider” is unclear because it is not clear whether the tokenized personal identification data stores, includes, uses, references, is generated based on, or is otherwise associated with the risk management verification data. Therefore, the scope of claim 1 is unclear.
Claim 11 is rejected under 35 U.S.C. 112(b) as being indefinite because the term “said certified document” lacks sufficient basis. Claim 11 depends from claim 1, but claim 1 does not introduce a “certified document.” Although claim 10 introduce a “certified document,” claim 11 does not depend from claim 10. Therefore, it is unclear what certified document is being referenced by “said certified document,” and the scope of claim 11 is unclear.
Claim 14 is rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “means for carrying out the steps of the method according to claim 1” invokes 35 U.S.C. 112(f), but the specification does not clearly disclose sufficient corresponding structure, material, acts, or algorithm for carrying out the complete recited function.
The claim uses the term “means” and recites functional language without reciting sufficient structure. Although the specification describes general components such as computers, an AI module, a database, a blockchain environment, a CryptoPass environment, KYC providers, AML providers, and a third-party institution, the specification does not clearly link or associate those components with the claimed “means” for carrying out the complete method of claim 1, including receiving at least two verification requests, providing risk management verification data based on information delivered in the verification requests, and creating tokenized personal identification data in a decentralized computer network.
Therefore, because the claim invokes 35 U.S.C. 112(f) but the specification does not clearly disclose corresponding structure or algorithm for the recited function, the scope of claim 14 is unclear.
Claim 20 is rejected under 35 U.S.C. 112(b) as being indefinite because claim language is grammatically unclear and does not reasonably apprise a person of ordinary skill in the art of the metes and bounds of the claims. Claim 20 recites “The data processing system according one of the claims 14, where in at least data server (1270) is connected to the decentralized computer network, providing historical data.” However, the phrase “wherein at least data server” is unclear because it appears to omit “one” before “data server.” Therefore, the scope of claim 20 is unclear.
Claim 24 is rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “using the information of at least one information of the person or the organization” is grammatically unclear. It is unclear what “at least one information” means, what information of the person or organization is required by the formula, and how the information is used by the artificial intelligence module. Therefore, the scope of claim 24 is unclear.
Claims depending from the rejected claims inherit the indefiniteness of their respective
base claims. Accordingly, claims 2, 4-17, 19-20, and 22-24 depend directly or indirectly from claim 1 and inherit the indefiniteness of claim 1. Claims 15-17, and 19-20 depend directly or indirectly from claim 14 and inherit the indefiniteness of claim 14.
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, 2, 4-12, 14-17, 19-20, and 22-24 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Regarding Claims 1, 13, and 14:
Applying Step 1 of the Subject Matter Eligibility Test (SMET), does the claim as a whole
fall within one of the four statutory categories of invention? Yes.
Claim 1 is directed to a method for creating a tokenized personal identification of a person or an organization in a decentralized computer network, and therefore falls within the process category.
Claim 14 is directed to a data processing system comprising means for carrying out the steps of the method according to claim 1, and therefore falls within the machine category.
Applying Step 2A of the SMET, also known at this stage as the Alice/Mayo Test, Prong
One, is the claim as a whole directed to a law of nature, a natural phenomenon (product of nature) or an abstract idea? Yes.
The claim recites the abstract steps of:
Receiving verification requests;
Providing risk management verification data based on the requests;
Creating tokenized personal identification data that considers the risk management verification data amount to collecting identity/asset information;
Analyzing risk and compliance information; and
Issuing or creating a credential reflecting that verification.
The claim is directed to identity verification, KYC/AML compliance, wallet ownership verification, risk scoring, and credentialing of a person or organization. These limitations fall within the certain methods of organizing human activity grouping because they relate to commercial, legal, and financial interactions, including verifying a person or organization, evaluating trustworthiness or asset origin, and providing a credential for use by third parties. (see MPEP § 2106.04(a)(2).
The limitations also resemble collecting, analyzing, and outputting information, which courts have found abstract. (Electric Power Group, 830 F.3d at 1353-54; TLI Communications, 823 F.3d at 612-13)
It should be noted that a person can, either with or without a physical aid, receive identity documents, review KYC/AML information, evaluate wallet ownership, or asset-origin information, assign a risk score or risk level, and issue a certificate/passport/credential indicating verification. Therefore, the claimed concept can be practically performed in the human mind or with pen and paper.
Applying Step 2A, Prong Two, does the claim recite additional elements that integrate
the judicial exception into a practical application? No.
The claim recites the additional elements of:
A first computing device;
A computer network;
A decentralized computer network;
At least one cryptocurrency wallet;
A second computer device;
A public blockchain and private blockchain;
A database comprising historical data;
A certified document;
A third-party institution;
An artificial intelligence (AI) module;
A computer program;
A data processing system;
Several computers;
An interface;
A backend computer; and
A data server.
A claim reciting a judicial exception is not directed to the judicial exception if it also recites additional elements demonstrating that the claim as a whole integrates the exception into a practical application One way to demonstrate such integration is when the claimed invention improves the functioning of a computer or improves another technology or technical field. However, the additional elements recited above do no such thing and do not improve the functioning of the computer, database, blockchain, wallet, AI module, or decentralized computer network.
The claimed invention merely uses generic computer network components to receive verification information, process KYC/AML/wallet ownership information, generate risk management verification data, and create tokenized personal identification data. The claim does not recite an improved blockchain consensus mechanism, improved cryptographic protocol, improved wallet authentication protocol, improved AI model, improved database operation, or improved computer-network functionality.
The recited blockchain/decentralized network is used for its ordinary purpose of storing or hosting data in a tamper-resistant manner, and the AI module is recited at a high level of generality to calculate or provide risk information. Merely applying identity verification and risk scoring to generic blockchain and AI components does not integrate the abstract idea into a practical application.
Thus, this judicial exception is not integrated into a practical application and the claim
does not include additional elements that are sufficient to amount to significantly more than the judicial exception as argued above.
Applying, Step 2B, do the additional elements amount to an inventive concept? No.
Simply appending well-understood, routine, conventional activities previously known to
the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an
abstract idea requiring no more than a generic computer to perform generic computer functions
that are well-understood, routine and conventional activities previously known to the industry, as
discussed in Alice Corp., 573 U.S. at 225, 110 USPQ2d at 1982-83, is not enough to supply an
inventive concept. The additional elements are generic computer components carrying out routine computer functions, such as receiving data, storing data, validating data, analyzing data, generating a risk score, creating a token/credential, recording data in a blockchain, and providing access to third parties. Using a blockchain to make records tamper-resistant or using an AI nodule to calculate risk merely automates the abstract compliance risk-assessment process using known technology for its ordinary purpose. These additional elements are not enough to qualify as “significantly more” when recited in a claim with a judicial exception.
Because claims 1, 13, and 14 fails Step 2B, the claim as a whole is found ineligible for being drawn to an abstract idea and therefore is non-statutory under 35 U.S.C. § 101.
Regarding claims 2, 4-12, 15-17, 19-20, and 22-24:
The dependent claims do not alter the analysis applied to claim 1.
Claim 2 merely recites KYC and/or AML verification requests.
Claim 4 merely recites connecting at least one cryptocurrency wallet to the computer network before step b).
Claim 5 merely recites performing a wallet ownership verification data process.
Claim 6 merely recites that the risk management verification data comprises a risk score computed in a second computer device.
Claim 7 merely recites that the risk management verification data compromises at least one level of risk information.
Claim 8 merely recites that the decentralized computer network comprises a public blockchain and private blockchain.
Claim 9 merely recites a database connected to the computer network and comprising historical data.
Claim 10 merely recites storing the tokenized personal identification data in a certified document.
Claim 11 merely recites verification/delivery involving a third-party institute.
Claim 12 merely recites providing the risk management verification data using an AI module.
Claim 15 merely recites several computers connected to form the decentralized computer network.
Claim 16 merely recites an interface for connecting the first computing device to at least one computer.
Claim 17 merely recites a cryptocurrency wallet connected to a computer.
Claim 19 merely recites a backend computer providing at least one AI module.
Claim 20 merely recites a data server connected to the decentralized computer network and providing historical data.
Claim 22 merely recites that the risk management verification data is further based on information delivered by the ownership verification.
Claim 23 merely recites multi-level risk information.
Claim 24 merely recites that the AI module is based on a formula using person/organization information, wallet information, and cryptocurrency information.
These additional limitations either further narrow the abstract idea, specify the type of verification/risk information being collected or analyzed, specify the technological environment, or add routine blockchain, wallet, AI, database, interface, server, or third-party access features. None of these limitations improves computer functionality, improves blockchain technology, improves AI technology, or adds significantly more than the abstract idea itself. Accordingly, claims 2, 4-12, 15-17, 19-20 and 22-24 are also rejected under 35 U.S.C. 101.
Claim 13 rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the claim is directed to a computer program per se. A computer program, standing alone and not embodied in a statutory machine or manufacture, is not a process, machine, manufacture, or composition of matter. Therefore, claim 13 is not directed to statutory subject matter under 35 U.S.C. 101.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-2, 4-17, 19-20, and 22-24 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Paschini et al, (U.S. Pub. No. 2020/0387891 A1, hereinafter “Paschini”)
As to claim 1, Paschini teaches:
(Original) Method for creating a tokenized personal identification of a person or an organization in a decentralized computer network, while said method comprises the following steps: (see Paschini, [¶¶0007, 0010, 0012, 0049]: “The system and methods disclose herein address the issues referenced above by enabling the users to be identified, verified and scoring of their transactions tracked on the blockchain. Each user of the system may be issued a wallet address comprising a public and private key pair. Verification of the identity of a user will occur when, for example, a wallet is issued and may follow accepted standards. The identity and risk score data are stored on the blockchain and are able to be retrieved by the wallet user creating a restricted used key. The system 100 further includes a blockchain database 112 containing metadata 170 relating to the user digital wallets 108 and transaction rules 122 specified by owners if digital wallets 108. The database 112 further includes KYC information 174, and ID classifications and risk scores 176 of users. The transactions involving the digital wallets 108 are recorded as one or more blockchains within a transaction validation and recording network 164 including a plurality of distributed nodes 166.”);
(Paschini teaches a method in which a user or person business organization is identified and verified, issued a wallet address, key pair, and associated with identity risk data stored on a blockchain distributed node network. The wallet based blockchain identity risk metadata teaches tokenized personal identification in a decentralized computer network.)
a) Providing a connection of a first computing device in a computer network: (see Paschini, [¶¶0047, 0057]: “The wallet interface 107.sub.N may be in the form of an application executed by, for example, a mobile communication device 109 in communication with a network interface 141 of the platform via one or more wireless or other networks. As shown in FIG. 2, the cloud-based management platform 240 is in communication with a transaction validation and recording network 248 including a plurality of distributed nodes 252.”);
(A first computing device/wallet interface connected through a network to a management platform distributed node blockchain network.)
b) Receiving at least two verification requests regarding the person or organization via said first computing device in the computing network: (see Paschini, [¶¶0055, 0057, 0067]: “The KYC module 110 collects wallet owner personal or business data and validates it based upon geographic profiles and routines defined in smart contracts. This includes validation of submitted documents (passports, utility bills, corporate registration documents), validation against public databases, image comparison, fingerprinting from devices, device fingerprinting (i.e., IMEI of mobile phone). A number of external data, technology and service providers 264 may provide a variety of validation or check information 265 to the cloud-based management platform 240 in connection with evaluating requests by new users to be issued digital wallets for use within the system 200. This information may include, for example, a social media profile check 266, an Identity check 267, a source of wealth check 268 and an anti-money launder (AML) check or sanctions check 269. As an initial step in the onboarding process a user 102 sends a request to the platform 140 to create a wallet address.”);
(The user’s wallet creation, onboarding request and submitted KYC, identity information via the first computing device constitute verification requests. Paschini also teaches multiple checks, including identity, source of wealth, and AML/sanctions checks.)
c) Providing of at least one risk management verification data, at least based on information delivered in the at least two verification requests in the computer network: (see Paschini, [¶¶0048-0049, 0071]: “The AI-based management platform 140 includes a know your customer (KYC) module 110, an ID and risk score module 114, and a smart contract module 118. The database 112 further includes KYC information 174, and ID classifications and risk scores 176 of users. In one embodiment various user parameters, a social score, past transactions, and a financial score are used in computing a risk score. Exemplary user parameters may include, for example, ID verification, address verification, source of funds, source of wealth, a sanctions check, and the like.”);
(Paschini teaches risk management verification data as ID classifications and risk score based on KYC, identity, financial, transaction, and sanctions check information.)
d) Creating at least one tokenized personal identification data in a decentralized computer network, while said tokenized personal identifications data consider at least the risk management verification data: (see Paschini, [¶¶0012, 0049, 0052]: “In one implementation the wallet address will have a flag associated with identify verification and fields indicative of a risk score associated with the wallet. The identity and risk score data are stored on the blockchain and are able to be retrieved by the wallet user creating a restricted used key. The system 100 further includes a blockchain database 112 containing metadata 170 relating to the user digital wallets 108. The database 112 further includes KYC information 174, and ID classifications and risk scores 176 of users. The transactions involving the digital wallets 108 are recorded as one or more blockchains (hereinafter “blockchain wallet” or “blockchain”) within a transaction validation and recording network 164 including a plurality of distributed nodes 166. In one embodiment the metadata 170 stored by the smart contract module 118 comprises a user ID, KYC data and risk score. Metadata will generally be hashed and/or cryptographically encrypted and cannot be read by anyone without permission of the owner of the digital wallet 108 to which such metadata 170 pertains.”);
(Paschini’s hashed blockchain metadata comprising a user ID, KYC data, and risk score constitutes the claimed tokenized personal identification data in a decentralized computer network and includes the claimed risk management verification data.)
As to Claim 2, Paschini teaches:
(Currently amended) wherein said at least two verification requests comprise a KYC and/or an AML verification request: (see Paschini, [¶¶0055, 0057-0058]: “The KYC module 110 collects wallet owner personal or business data and validates it based upon geographic profiles and routines defined in smart contracts. A number of external data, technology and service providers 264 may provide a variety of validation or check information 265 to the cloud-based management platform 240 in connection with evaluating requests by new users to be issued digital wallets for use within the system 200. This information may include, for example, a social media profile check 266, an Identity check 267, a source of wealth check 268 and an anti-money launder (AML) check or sanctions check 269. The validations and controls may include, for example: wallet account validation (KYC), i.e., management of the registration of KYC to a wallet.”);
(Paschini teaches that the verification request/checks include KYC validation and AML sanctions checks, which correspond to the claimed KYC and AML verification request.)
As to Claim 4, Paschini teaches:
(Currently amended) wherein before step b) at least one cryptocurrency wallet is connected to said computer network: (see Paschini, [¶¶0046-0047, 0067]: “As is discussed herein, the platform 140 communicates with wallet interface applications 107, which may be referred to simply as wallet interfaces 107, associated with or including digital wallets 108. The wallet interface 107.sub.N may be in the form of an application executed by, for example, a mobile communication device 109 in communication with a network interface 141 of the platform via one or more wireless or other networks. As an initial step in the onboarding process a user 102 sends a request to the platform 140 to create a wallet address (stage 302). In response to the request, the transaction manger 144 creates a new wallet address with metadata and KYC score (stage 304). A KYC check is then completed using preferred methods (based upon jurisdiction rules) (stage 306).”);
(Paschini teaches digital wallets/wallet interfaces connected to the computer network. It also teaches creating the wallet address before completing the KYC check, which corresponds to the cryptocurrency wallet being connected before the verification requests of step b.)
As to Claim 5, Paschini teaches:
(Currently amended) wherein an ownership verification data process of the at least one cryptocurrency wallet is performed: (see Paschini, [¶¶0010, 0012, 0067, 0077]: “Each user of the system may be issued a wallet address comprising a public and private key pair. Verification of the identity of a user will occur when, for example, a wallet is issued and may follow accepted standards. The identity and risk score data are stored on the blockchain and are able to be retrieved by the wallet user creating a restricted used key which is generated by the user and determines the restrictions associated with the retrieval of the data. As an initial step in the onboarding process a user 102 sends a request to the platform 140 to create a wallet address (stage 302). In response to the request, the transaction manger 144 creates a new wallet address with metadata and KYC score (stage 304). A KYC check is then completed using preferred methods (based upon jurisdiction rules) (stage 306). Each participant in the token system will be issued a wallet address comprising of a public and private key pair. In one embodiment each key pair and generated restricted use keys is associated with identity documents and or acceptable identity verification methods and risk data.”);
(Paschini teaches verifying the identity of the user when a wallet is issue and associating the wallet address, key pair with identity documents, verification methods, and risk data.)
As to Claim 6, Paschini teaches:
(Currently amended) wherein said at least one risk management verification data comprises a risk score, computed in a second computer device in the computer network: (see Paschini, [¶¶0048-0049, 0071]: “The AI-based management platform 140 includes a know your customer (KYC) module 110, an ID and risk score module 114, and a smart contract module 118. The database 112 further includes KYC information 174, and ID classifications and risk scores 176 of users. The ID and risk score module 114 determines a risk score for each digital wallet 108 based at least in part on such transactions in the manner described herein. In one embodiment various user parameters, past transactions, and a financial score are used in computing a risk score.”);
(Paschini teaches risk management verification data comprising a risk score computed by the ID and risk score module of the AI bases management platform, which corresponds to a second computer device in the computer network.)
As to Claim 7, Paschini teaches:
(Currently amended) wherein said at least one risk management verification data comprises at least one level of risk information: (see Paschini, [¶¶0049, 0063-0064]: “The database 112 further includes KYC information 174, and ID classifications and risk scores 176 of users. The smart contract module 118 could also provide the seller with an indication of a risk score of the counter party (e.g., low, medium or high risk). On the other hand, to the extent the vehicle seller determines that the identity of the counter party is not up to date and/or the counter party has a high risk score, the seller may not elect to proceed with the transaction.”);
(Paschini teaches risk management verification data comprising at least one level of risk information, such as low, medium, or high risk.)
As to Claim 8, Paschini teaches:
(Currently amended) wherein said decentralized computer network comprise at least one public blockchain and/or private blockchain: (see Paschini, [¶¶0049, 0057, 0060]: “The transactions involving the digital wallets 108 are recorded as one or more blockchains (hereinafter “blockchain wallet” or “blockchain”) within a transaction validation and recording network 164 including a plurality of distributed nodes 166. As shown in FIG. 2, the cloud-based management platform 240 is in communication with a transaction validation and recording network 248 including a plurality of distributed nodes 252. In this case the smart contract module 118 will generally still be configured to read the blockchain history of the first and second digital wallets 108 recorded in the blockchain history.”);
(Paschini teaches a decentralized computer network comprising at least one blockchain because transactions are recorded on blockchain data structures within a transaction validation and recording network having distributed nodes.)
As to Claim 9, Paschini teaches:
(Currently amended) wherein a database is connected to the computer network, comprising historical data: (see Paschini, [¶¶0049, 0060, 0071]: “The system 100 further includes a blockchain database 112 containing metadata 170 relating to the user digital wallets 108 and transaction rules 122 specified by owners if digital wallets 108. The database 112 further includes KYC information 174, and ID classifications and risk scores 176 of users. In this case the smart contract module 118 will generally still be configured to read the blockchain history of the first and second digital wallets 108 recorded in the blockchain history. In one embodiment various user parameters, a social score, past transactions, and a financial score are used in computing a risk score.”);
(Paschini teaches a blockchain database connected to the computer network and containing historical data, including blockchain history and past transaction data used for risk score computation.)
As to Claim 10, Paschini teaches:
(Currently amended) wherein said at least one tokenized personal identification data is stored in a certified document: (see Paschini, [¶¶0012, 0049, 0052]: “The identity and risk score data are stored on the blockchain and are able to be retrieved by the wallet user creating a restricted used key which is generated by the user and determines the restrictions associated with the retrieval of the data. The system 100 further includes a blockchain database 112 containing metadata 170 relating to the user digital wallets 108. The database 112 further includes KYC information 174, and ID classifications and risk scores 176 of users. The transactions involving the digital wallets 108 are recorded as one or more blockchains within a transaction validation and recording network 164 including a plurality of distributed nodes 166. In one embodiment the metadata 170 stored by the smart contract module 118 comprises a user ID, KYC data and risk score.”);
(Paschini teaches user ID, KYC data, and risk-score metadata stored through a blockchain/smart contract environment. An immutable blockchain ledger record or smart contract state record corresponds to a digital certified document because its authenticity is cryptographically validated by the transaction validation network.)
As to Claim 11, Paschini teaches:
(Currently amended) wherein a third-party institution is verified to the computer network and said at least one tokenized personal identification data and or said certified document is delivered to the third-party institution: (see Paschini, [¶¶0012, 0048, 0065]: “Restricted use keys are provided to counter parties in which the wallet may make transactions with such as personal transactions, vendors, financial institutions, and government agencies. The AI-based management platform 140 further includes a token issuer/smart contract/trade manager module 144, a liquidity manager module 152, and a bank/financial institution connectivity interface 160. As another example, a bank contemplating a transaction with an owner of a digital wallet 108 may request the owner to provide the bank with a copy of the wallet owner's passport, ID score, risk score, and countries in which the wallet owner has done business. In this case the wallet owner directs, via the wallet interface 107, the wallet owner's digital wallet 108 to create a restricted use key allowing bank personnel to view (through the bank's wallet interface 107) an image of the wallet owner's passport, the wallet owner's ID entity score, a list of countries with which the wallet owner does business, and the wallet owner's risk score.”);
(Paschini teaches verified network verified network participating third partis such as banks, financial institutions, vendors, and government agencies receiving access to user identity/risk information through restricted use keys.)
As to Claim 12, Paschini teaches:
(Currently amended) wherein said risk management verification data is provided using an artificial intelligence (AI) module, connected in the computing network: (see Paschini, [¶¶0046, 0048, 0050, 0071]: “As shown, the system 100 includes an AI-based management platform 140 configured to facilitate digital wallet transactions. As shown, the AI-based management platform 140 includes a know your customer (KYC) module 110, an ID and risk score module 114, and a smart contract module 118. The liquidity calculations are managed by an AI-based service provided by the AI engine 148. In one embodiment various user parameters, past transactions, and a financial score are used in computing a risk score.”);
(Paschini teaches risk management verification data, including ID classifications and risk scores, providing through an AI based management platform connected in the computing network.)
As to Claim 13, Paschini teaches:
(Currently amended) Computer program, configured to perform a method as claimed in claim 1: (see Paschini, [¶¶0081-0083]: “The various methods or processes outlined herein may be coded as software that is executable on one or more processors that employ any one of a variety of operating systems or platforms. In this respect, various inventive concepts may be embodied as a non-transitory computer readable storage medium encoded with one or more programs that, when executed on one or more computers or other processors, perform methods that implement the various embodiments of the invention discussed above. The terms “program” or “software” are used herein in a generic sense to refer to any type of computer code or set of computer-executable instructions that can be employed to program a computer or other processor to implement various aspects of embodiments as discussed above.”);
(Paschini teaches that the disclosed methods may be coded as executable software, computer code, or programs configured to perform the disclosed processes. Because claim 13 is configured to perform method of claim 1, the same grounds of rejection and technical reasoning set forth for claim 1 apply to claim 13.)
As to Claim 14, Paschini teaches:
(Currently amended) Data processing system (1200) comprising means for carrying out the steps of the method according to claim 1: (see Paschini, [¶¶0024, 0048, 0082]: “The management platform includes a memory configured to store computer program instructions relating to at least a smart contract module and an identity (ID) and risk score module, and one or more physical computer processors configured by the computer program instructions to implement at least the smart contract module and the ID and risk score module. As shown, the AI-based management platform 140 includes a know your customer (KYC) module 110, an ID and risk score module 114, and a smart contract module 118. In this respect, various inventive concepts may be embodied as a non-transitory computer readable storage medium encoded with one or more programs that, when executed on one or more computers or other processors, perform methods that implement the various embodiments of the invention discussed above.”);
(Paschini teaches a data processing system including memory, computer program instructions, and processors configured to carry out the disclosed KYC, wallet, blockchain, and risk scoring method steps. Because claim 14 carries out the method of claim 1, the same grounds of rejection and technical reasoning set forth for claim 1 apply to claim 14.)
As to Claim 15, Paschini teaches:
(Currently amended) wherein several computers (1210;1220) are connected to form [[a]] the decentralized computer network: (see Paschini, [¶¶0049, 0057, 0060]: “The transactions involving the digital wallets 108 are recorded as one or more blockchains (hereinafter “blockchain wallet” or “blockchain”) within a transaction validation and recording network 164 including a plurality of distributed nodes 166. As shown in FIG. 2, the cloud-based management platform 240 is in communication with a transaction validation and recording network 248 including a plurality of distributed nodes 252.”);
(Paschini’s plurality of distributed nodes constitutes several computers connected to form a decentralized computer network.)
As to Claim 16, Paschini teaches:
(Currently amended) comprising at least one interface for connecting [[a]] the first computing device (1240) to at least one computer (1210; 1220): (see Paschini, [¶¶0047-0048, 0057]: “The wallet interface 107.sub.N may be in the form of an application executed by, for example, a mobile communication device 109 in communication with a network interface 141 of the platform via one or more wireless or other networks. The AI-based management platform 140 includes a know your customer (KYC) module 110, an ID and risk score module 114, and a smart contract module 118. As shown in FIG. 2, the cloud-based management platform 240 is in communication with a transaction validation and recording network 248 including a plurality of distributed nodes 252.”);
(Paschini teaches a wallet interface/mobile computing device connected through a network interface to the platform and distributed node network, which corresponds to an interface connecting the first computing device to at least one computer.)
As to Claim 17, Paschini teaches:
(Currently amended) wherein at least one cryptocurrency wallet is connected to [[said]] a computer (1210; 1220): (see Paschini, [¶¶0046-0047]: “As is discussed herein, the platform 140 communicates with wallet interface applications 107, which may be referred to simply as wallet interfaces 107, associated with or including digital wallets 108. The wallet interface 107.sub.N may be in the form of an application executed by, for example, a mobile communication device 109 in communication with a network interface 141 of the platform via one or more wireless or other networks.”);
(Paschini teaches digital wallets/wallet interfaces connected through a computing device to the network management platform, which corresponds to at least one cryptocurrency wallet connected to a computer.
As to Claim 19, Paschini teaches:
(Currently amended) wherein at least one computer (1210; 1220) is a backend computer providing at least one AI module (1260): (see Paschini, [¶¶0046, 0048, 0050, 0071]: “As shown, the system 100 includes an AI-based management platform 140 configured to facilitate digital wallet transactions. As shown, the AI-based management platform 140 includes a know your customer (KYC) module 110, an ID and risk score module 114, and a smart contract module 118. The liquidity calculations are managed by an AI-based service provided by the AI engine 148. In one embodiment various user parameters, past transactions, and a financial score are used in computing a risk score.”);
(Paschini teaches a network backend management platform having AI-based services or modules, including an AI engine and ID/risk-score functionality.
As to Claim 20, Paschini teaches:
(Currently amended) wherein at least data server (1270) is connected to the decentralized computer network, providing historical data: (see Paschini, [¶¶0049, 0060, 0071]: “The system 100 further includes a blockchain database 112 containing metadata 170 relating to the user digital wallets 108 and transaction rules 122 specified by owners if digital wallets 108. The database 112 further includes KYC information 174, and ID classifications and risk scores 176 of users. In this case the smart contract module 118 will generally still be configured to read the blockchain history of the first and second digital wallets 108 recorded in the blockchain history. In one embodiment various user parameters, a social score, past transactions, and a financial score are used in computing a risk score.”);
(Paschini teaches a blockchain database connected to the computer network and containing historical data, including blockchain history and past transaction data used for risk score computation.)
As to Claim 22, Paschini teaches:
(New) wherein said at least one risk management verification data is further based on information data delivered by the ownership verification in the computer network: (see Paschini, [¶¶0010, 0077-0078]: “Each user of the system may be issued a wallet address comprising a public and private key pair. Verification of the identity of a user will occur when, for example, a wallet is issued and may follow accepted standards. Each participant in the token system will be issued a wallet address comprising of a public and private key pair. In one embodiment each key pair and generated restricted use keys is associated with identity documents and or acceptable identity verification methods and risk data. The KYC and/or KYB documents can be verified by more than one source to strengthen the score of the validity of the documents and the results of these confirmations are recorded on the block chain associated with the wallet address.”);
(Paschini teaches that wallet issuance includes identity verification and that wallet key pairs or restricted use keys are associated with identity documents, verification methods, and risk data. Paschini further teaches that verification confirmations strengthen the score and are recorded on the blockchain associated with the wallet address.)
As to Claim 23, Paschini teaches:
(New) wherein said at least one risk management verification data comprises a multi-level of risk information: (see Paschini, [¶¶0049, 0063-0064]: “The database 112 further includes KYC information 174, and ID classifications and risk scores 176 of users. The smart contract module 118 could also provide the seller with an indication of a risk score of the counter party (e.g., low, medium or high risk). On the other hand, to the extent the vehicle seller determines that the identity of the counter party is not up to date and/or the counter party has a high risk score, the seller may not elect to proceed with the transaction.”);
(Paschini teaches risk management verification data comprising at least one level of risk information, such as low, medium, or high risk.)
As to Claim 24, Paschini teaches:
(New) wherein said artificial intelligence module is based on a formula using the information of at least one information of the person or the organization, and/or at least one wallet information data and/or at least one information of the cryptocurrency: (see Paschini, [¶¶0021-0022, 0071, 0077]: “The system may determine a participant's risk score using an artificial intelligence (AI) algorithm which may take into account, for example, actions and data associated with network participants. The risk score algorithm will preferably take geography and transaction amounts into consideration. In one embodiment various user parameters, a social score, past transactions and a financial score are used in computing a risk score. Exemplary user parameters may include, for example, ID verification, address verification, source of funds, source of wealth, a sanctions check, and the like. The risk score may comprise a single value on a predefined scale and be influenced by, for example, wallet-related actions, transactions, KYC or KYB, geographical and other data inputs.”);
(Paschini teaches an AI algorithm, risk score formula using person or organization information, wallet related actions, transactions, KYC/KYB information, geography, and cryptocurrency/token transaction information.)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARHAM AHMED whose telephone number is (571)272-8950. The examiner can normally be reached Monday-Friday 7:30 am - 5 pm. Alternate Friday off..
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, Alexander Lagor can be reached at (571) 270-5143. 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.
/A.N.A./Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437
Prosecution Insights