DETAILED ACTION
This is office action on the merits in response to the application filed on 02/24/2026.
Claims 1-20 have been filed by the applicant.
Claims 1-8 and 15 are currently amended.
Claims 1-20 are currently pending and have been examined.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/24/2026 has been entered.
Response to Argument
Claim Objections:
Previous claim objection has been withdrawn based on amendment.
101 Rejection:
The applicant argues that the claims are directed to a practical application because the claim recites collecting and generating fingerprint data by an edge extended reality device to enhance security and compliance. The examiner respectfully disagrees. The claim is focusing on validating and verifying a notarization document, which is an abstract idea of agreements in the form of contract. Without improving the XR device itself or solving a problem specific to the technology, the collecting data using XR device merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)).
The applicant further argues that the claims introduce significant technological improvement by using quantum key distribution (QKD) and AI algorithm. The examiner respectfully disagrees. The claim does not recite how the QKD and AI are implemented to improve the functionality of the system. There elements are used for their expected purpose of securing and analyzing data, which constitutes applying the abstract idea using generic technology.
The applicant further argues that the claims improves security, authenticity and compliance of the notarization process because the claims recite steps and a mechanism for real-time retrieval of rules/regulations for compliance check of the documents. The examiner respectfully disagrees. Checking laws and regulations before notarization is the abstract idea itself. Therefore, the claim itself is merely a recitation of the abstract idea and an instruction to “apply it” on a computer.
Therefore, 101 rejection is maintained.
103 Rejection:
The applicant argues that the prior arts do not teach an edge extended reality device. The examiner agrees the claims now positively recites an edge extended reality device. New prior art is provided. See 103 rejections.
Claim Objections
Claim 1, 8 and 15 recites repeated language “maintain an audit trail …..smart contract smart contract”. Appropriate correction is required.
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.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “smart contract generator”, “tagging module” and “rules engine” in claim 1.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
Claim 1-7 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 “a computing platform… to implement a smart contract generator” and “mapping, via smart contract generator”. However, the examiner found “Smart Contract Generator 140” is not part of “Smart E-Notary Computing Platform 110” in Fig. 1A. Therefore, the specification fails to provide support for how “a computing platform” to implement function on another device/system (i.e., smart contract generator). All dependent claims are rejected.
As noted above in 112(f), claim 1 recites “a rule engine configure to identify….laws… applicable to electronic notarization”. The specification is required to provide lacks adequate written description under 35 U.S.C. 112(a). The specification in paragraph [0033] only states that “the rule engine 112e may store instructions and/or data that may cause or enable smart e-notary computing platform 110 to ensure verification of legal documents with defined metadata checks, identify local and/or state defined protocols (e.g., policies, procedures, guidelines, or the like), and notify users of any discrepancies or take other appropriate actions”. The specification fails to disclose sufficient structure for “a rule engine”. The specification also fails to provide algorithms of how to perform the recited function/steps by “a rule engine”.
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.
Claim 1-7 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.
As noted above in 112(f), claim limitation “a rule engine configure to identify….laws… applicable to electronic notarization” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. For a computer-implemented 35 U.S.C. 112(f) claim limitation, the specification must disclose an algorithm for performing the claimed specific computer function, or else the claim is indefinite under 35 U.S.C. 112(b). The specification in paragraph [0033] only states that “the rule engine 112e may store instructions and/or data that may cause or enable smart e-notary computing platform 110 to ensure verification of legal documents with defined metadata checks, identify local and/or state defined protocols (e.g., policies, procedures, guidelines, or the like), and notify users of any discrepancies or take other appropriate actions”. However, the examiner cannot identify any steps or algorithms described in the specification for performing the recited functions “identify, in real time from external data source, laws, regulations and rules applicable to electronic notarization document”. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claim 1 recites a system, claim 1 further recites “wherein one or more individuals associated with the document, from a remote location, scanned and collected physical fingerprints to generate the fingerprints synthetically in the extended immersive environment via the extended reality capable device”. A single claim which claims both an apparatus and the method steps of using the apparatus is indefinite under 35 U.S.C. 112(b), it is indefinite because the amended feature is not directed to the system, but rather to actions of one or more individual, which creates confusion as to when direct infringement occurs (MPEP § 2173.05(p)).
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.
In the instant case, claims 1-7 are directed to a system comprising a memory and a processor, claims 8-14 are directed to a method, and claims 15-20 are directed to a non-transitory computer-readable storage medium. Therefore, these claims fall within the four statutory categories of invention.
The limitations of independent claim 1, which is representative of independent claims 8 and 15, have been denoted with letters by the Examiner for easy reference. The judicial exceptions recited in claim 1 are identified in bold below:
A system for remote online notarization comprising: an extended reality capable edge device comprising: a biometric sensor comprising a fingerprint sensor, and an extended reality interface configured to simulate a physical presence of a user in an extended immersive environment;
a computing platform comprising: at least one processor; a communication interface communicatively coupled to the at least one processor; and memory storing computer-readable instructions that, when executed by the at least one processor, cause the computing platform to implement:
a smart contract generator configured to retrieve, via the communication interface, from a node in a decentralized distributed ledger system, a smart contract associated with a document for remote online notarization, wherein the smart contract associated with the document comprises one or more metadata attributes from the document, wherein the metadata attributes include fingerprint metadata synthetically generated by a generative artificial intelligence module based on biometric data captured via the biometric sensor of the extended reality capable edge device, wherein one or more individuals associated with the document, from a remote location, scanned and collected physical fingerprints to generate the fingerprints synthetically in the extended immersive environment via the extended reality capable device, wherein the synthetically generated fingerprint metadata corresponds to the one or more individuals associated with the document and resembles physical fingerprint characteristics of the one or more individuals, and wherein the fingerprint metadata is encoded using quantum key distribution;
a tagging module configured to tag the smart contract based on the metadata attributes;
a rules engine configured to identify, in real time from an external data source, state-specific laws, regulations, and procedural compliance rules applicable to electronic notarization of the document;
a checklist for mapping, via the smart contract generator, the document to the identified state-specific laws, regulations, and procedural compliance rules using the checklist, wherein the smart contract generator identifies inconsistencies between the document and the mapped requirements, wherein the smart contract generator transmits, via the communication interface, a notification to the one or more individuals requesting resubmission of information to correct identified inconsistencies,
wherein the computing platform requests and receives approval of the tagging from the one or more individuals associated with the document, digitally notarizes the document upon receipt of the approval, transmits the tagged smart contract to the node in the decentralized distributed ledger system and causes the tagged smart contract to be stored in the node, and wherein an audit trail is maintained for any changes or updates to the smart contract smart contract associated with a document.
Limitations C through G under the broadest reasonable interpretation covers steps or functions of commercial interactions. Other than reciting generic computer hardware in limitation C-G, nothing in the claim element differentiates the limitation from processes of commercial interactions. Therefore, limitations C through G recite an abstract idea, as highlighted above, that is consistent with the agreements in the form of contract aspects of commercial interactions.
Accordingly, claim 1, and by analogy similar claims 8 and 15, recite an abstract ideas and the analysis proceed to Step 2A.2.
The judicial exception is not integrated into a practical application. In particular, claim 1 recites the additional elements in bold below:
A system for remote online notarization comprising: an extended reality capable edge device comprising: a biometric sensor comprising a fingerprint sensor, and an extended reality interface configured to simulate a physical presence of a user in an extended immersive environment;
a computing platform comprising: at least one processor; a communication interface communicatively coupled to the at least one processor; and memory storing computer-readable instructions that, when executed by the at least one processor, cause the computing platform to implement:
a smart contract generator configured to retrieve, via the communication interface, from a node in a decentralized distributed ledger system, a smart contract associated with a document for remote online notarization, wherein the smart contract associated with the document comprises one or more metadata attributes from the document, wherein the metadata attributes include fingerprint metadata synthetically generated by a generative artificial intelligence module based on biometric data captured via the biometric sensor of the extended reality capable edge device, wherein one or more individuals associated with the document, from a remote location, scanned and collected physical fingerprints to generate the fingerprints synthetically in the extended immersive environment via the extended reality capable device, wherein the synthetically generated fingerprint metadata corresponds to the one or more individuals associated with the document and resembles physical fingerprint characteristics of the one or more individuals, and wherein the fingerprint metadata is encoded using quantum key distribution;
a tagging module configured to tag the smart contract based on the metadata attributes;
a rules engine configured to identify, in real time from an external data source, state-specific laws, regulations, and procedural compliance rules applicable to electronic notarization of the document;
a checklist for mapping, via the smart contract generator, the document to the identified state-specific laws, regulations, and procedural compliance rules using the checklist, wherein the smart contract generator identifies inconsistencies between the document and the mapped requirements, wherein the smart contract generator transmits, via the communication interface, a notification to the one or more individuals requesting resubmission of information to correct identified inconsistencies,
wherein the computing platform requests and receives approval of the tagging from the one or more individuals associated with the document, digitally notarizes the document upon receipt of the approval, transmits the tagged smart contract to the node in the decentralized distributed ledger system and causes the tagged smart contract to be stored in the node, and wherein an audit trail is maintained for any changes or updates to the smart contract smart contract associated with a document.
The additional element(s) in limitation A and B are recited at a high level of generality. The “generator”, “module” and “engine” elements of limitations C through F, are merely software “instructions” that as an ordered combination with limitation A and B amount to a computer programmed to carry out the abstract idea. The use of decentralized distributed ledger system and smart contract highlights generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)). As such, when the additional elements are considered individually and as an ordered combination, the claim as a whole amounts to no more than or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea. Accordingly, the additional element(s) do not integrate the abstract idea into a practical application because they do not recite any additional elements indicative of integration into a practical application. Rather, the claim as whole generally links the judicial exception to a technological environment defined by high level recitations of a computer and the Internet. Therefore, the claim is directed to an abstract idea and the analysis proceeds to Step 2B.
The additional elements, both individually and as an ordered combination, do not amount to significantly more than the judicial exception because the outcome of the considerations at Step 2B will be the same when the considerations from Step 2A.2 are reevaluated. As discussed under Step 2A.2, the additional element(s) amount to no more than generally link the abstract idea to a technological environment through “instructions” performed by a generic computer. Because those instructions embody the abstract idea, the claim itself is merely a recitation of the abstract idea and an instruction to “apply it” on a computer. This is not enough to provide an inventive concept. Therefore, claims 1, 8, and 15 are not patent eligible.
Dependent claims 2-3, 9-10 and 16-17 further describe fingerprint and identification data. The claim does not recite additional elements that integrate the abstract idea to a practical application nor provide significantly more than the abstract idea.
Dependent claims 4, 11 and 18 further recites tagging rules which further recites the abstract idea. The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Dependent claims 5, 12 and 19 further defines the individual. The additional elements fail to recite a practical application nor significantly more than the abstract idea.
Dependent claims 6-7, 13-14 and 20 further defines the smart contract. The additional elements fail to recite a practical application nor significantly more than the abstract idea.
In summary, the dependent claims considered both individually and as an ordered combination do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself. The claims do not recite an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or provide meaningful limitations beyond generally linking an abstract idea to a particular technological environment. Therefore, the claims are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-5, 8-12, 15-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lindley et al. (US 10671712 B1), and further in view of Obradovic et al. (US 20200027297 A1) and Treat et al. (US 20190253240 A1) and Mesrsmid et al. (US 20230267192 A1) and Spaling et al. (US 20230206363 A1).
With respect to claim 1, 8 and 15:
Lindley teaches (in italic):
A system for remote online notarization comprising: a computing platform comprising: at least one processor; a communication interface communicatively coupled to the at least one processor; and memory storing computer-readable instructions that, when executed by the at least one processor, cause the computing platform to implement. (Fig. 3)
retrieve, via the communication interface, from a node in a decentralized distributed ledger system, […] a document for remote online notarization. (Data stores 125 and 130 can be used to manage storage and access to user data such as user profiles, documents, previous virtual notarization procedures and history…...Virtual notarization system 120 and/or other servers may collect and/or access data from data stores 125 and 130. Conferencing operation 406 engages in a video conference between a notary and the user. In some embodiments, the options are determined by the notary's location based on the requirements in the location (e.g., some states do not allow video conference notarization, some states may accept cryptographic signatures). [Col5:65-Col6:8, Col10:20-28])
wherein the computing platform requests and receives approval of the tagging from the one or more individuals associated with the document, digitally notarizes the document upon receipt of the approval. (For example, the notary can request the user to provide via the video conference various identity verification documents to fulfill the notary requirement. Receiving operation 410 receives a signature in accordance with the option selected or requested. the notary applies a notary seal to the document in applying operation 412. In some embodiments, the notary seal is a digitally encoded seal. [Col 10:27-50])
transmits the tagged smart contract to the node in the decentralized distributed ledger system and causes the tagged smart contract to be stored in the node. (Distributed ledger 160 records transactions such as the exchange of a document or digest of a document or the signing of a document. When distributed ledger 160 receives a transaction signed with the proper key from the user or from virtual notarization system 120 and the transaction is verified by network nodes, distributed ledger 160 associates the document or digest of the document with the proper addressed account and records the transaction. [Col6:23-30])
wherein an audit trail is maintained for any changes or updates to the smart contract smart contract associated with a document. (Notarizing operation 812 notarizes the signed document by a third party reviewing the signature and document and signing the document after verifying the user's signature and the document. In some embodiments, after the document is notarized, a transaction that includes metadata can be recorded on the blockchain, The metadata can describe the identities of the parties and include a digest of the document. [Col13 :27-34])
Lindley does not teach an extended reality capable edge device comprising: a biometric sensor comprising a fingerprint sensor, and an extended reality interface configured to simulate a physical presence of a user in an extended immersive environment;…. [...] of the extended reality capable edge device, wherein one or more individuals associated with the document, from a remote location, scanned and collected physical fingerprints to generate the fingerprints synthetically in the extended immersive environment via the extended reality capable device [...]. However,
Obradovic teaches an extended reality capable edge device comprising: a biometric sensor comprising a fingerprint sensor, and an extended reality interface configured to simulate a physical presence of a user in an extended immersive environment;…. [...] of the extended reality capable edge device, wherein one or more individuals associated with the document, from a remote location, scanned and collected physical fingerprints to generate the fingerprints synthetically in the extended immersive environment via the extended reality capable device [...]. (In some cases, a biometric sensor (e.g., a fingerprint sensor, a retinal scan sensor, a facial recognition sensor, a biosensor, a genome sensor, or any combination thereof) may be coupled with the virtual reality device that is configured to perform biometric authentication of an identity of the voter. [0008])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Lindley to utilizing a XR device to obtain data with the technique as disclosed by Obradovic to provide enhanced privacy during interaction as Obradovic suggests in [0005].
Lindley in view of Obradovic does not teach the following limitations. However,
Treat teaches:
a smart contract generator configured to retrieve […] a smart contract associated with a document for remote online notarization. (In general, Corda supports use of smart contracts, which can be provided as computer-executable code. A smart contract can be described as an agreement is automatically executed as computer code with user (human) input and control. For example, in response to receiving a request to notarize a transaction. [0039][0047])
wherein the smart contract associated with the document comprises one or more metadata attributes from the document; a tagging module configured to tag the smart contract based on the metadata attributes. (For example, in response to receiving a request to notarize a transaction, the notary service determines whether any of the input states were included in a previously signed transaction (e.g., a “double spend” of an input state). If the input states are not included in a previously signed transaction, the notary service signs the transaction. If one or more input states are included in a previously signed transaction, the notary service rejects the transaction and flags that a double-spend attempt has occurred. [0047])
wherein the […] metadata is encoded using quantum key distribution. (For example, if two nodes want to keep a transaction private, such that other nodes cannot discern details of the transaction, the nodes can encrypt the transaction data. Example cryptography includes, without limitation, symmetric encryption, and asymmetric encryption. [0026]). Treat discloses two encryption methods and suggests other methods. It would have been obvious for other inventor to try other encryption methods as Treats suggests.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Lindley in view of Obradovic to utilizing smart contract and tag smart contract with the technique as disclosed by Treat to prevent double spending as suggested by Treat in [0047]
Lindley in view of Obradovic and Treat does not teach wherein the metadata attributes include fingerprint metadata synthetically generated by a generative artificial intelligence module based on biometric data captured via the biometric sensor […] wherein the synthetically generated fingerprint metadata corresponds to the one or more individuals associated with the document and resembles physical fingerprint characteristics of the one or more individuals. However,
Mesrsmid teaches wherein the metadata attributes include fingerprint metadata synthetically generated by a generative artificial intelligence module based on biometric data captured via the biometric sensor […] wherein the synthetically generated fingerprint metadata corresponds to the one or more individuals associated with the document and resembles physical fingerprint characteristics of the one or more individuals. (In another example well-suited for unique body feature synthetic biometric signatures, artificial intelligence methods such as adversarial networks are used to generate the signature. In some examples, the synthetic biometric signature is based at least in part on the user's actual biometric signature but is modified using an artificial biometric signature. Biometric signatures in some examples comprise actual biometric characteristics as they may be captured by an electronic input device (microphone, camera, fingerprint scanner, iris scanner, mouse, touch screen, accelerometers, location sensors etc.) and/or as subsequently processed by biometric processing algorithms that typically extract most important physical or behavioral features of the biological characteristics specifically designed to provide similar results for the same person when re-taking the scan. [0027-0028])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Lindley in view of Obradovic and Treat to generate synthetic fingerprint using AI with the technique as disclosed by Mesrsmid to provide a degree of security as Mesrsmid suggests in [0028].
Lindley in view of Obradovic and Treat and Mesrsmid does not teach the following limitations. However,
Spaling teaches (in italic):
a rules engine configured to identify, in real time from an external data source, state-specific laws, regulations, and procedural compliance rules applicable to […] of the document; a checklist for mapping, […], the document to the identified state-specific laws, regulations, and procedural compliance rules using the checklist, […] identifies inconsistencies between the document and the mapped requirements (In one embodiment when the original document is uploaded, it may be checked for compliance with the jurisdictional formalities at the time the document was executed. In this embodiment the system may produce these records in a form that is in compliance with the guidelines, rules or legislation of the courts in that particular jurisdiction in accordance with the SDM's duty to account or similar duty thereof. [0101, 0105]). Spaling discloses check compliance for document. It would have been understood to modify the system with Spaling to check compliance for electronic notarization.
wherein […] transmits, via the communication interface, a notification to the one or more individuals requesting resubmission of information to correct identified inconsistencies. (In the event that insufficient information or non-compliant information is entered, the Authorized User may be provided with a notification outlining the prospective deficiency and/or risk. For example, the system automatically prints off a list of the missing information or the required statements to be made by the presenting party. [0101])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Lindley in view of Obradovic and Treat and Mesrsmid to check document and notify user for information discrepancy or inconsistency with the technique as disclosed by Spaling to assist user complete draft as suggested by Spaling [0069].
claim 8, a method with the same scope as claim 1, is rejected.
claim 15, a non-transitory computer medium with the same scope as claim 1, is rejected.
With respect to claim 2, 9 and 16:
Spaling further teaches wherein the one or more metadata attributes comprise a photograph identification or a digital signature. (In the current embodiment, the SDM may be asked to provide identification information to the system to confirm the SDM's identity. Examples may include biometric testing, photo identification. [0123])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system to include identification information with the technique as disclosed by Spaling to assist user complete draft as suggested by Spaling [0069].
claim 9, a method with the same scope as claim 2, is rejected.
claim 15, a non-transitory computer medium with the same scope as claim 2, is rejected.
With respect to claim 3, 10 and 17:
Mesrsmid further teaches wherein the smart contract retrieved from the node in the decentralized distributed ledger system is generated using, synthetically generated fingerprint metadata of the one or more individuals associated with the document for remote online notarization. (In another example well-suited for unique body feature synthetic biometric signatures, artificial intelligence methods such as adversarial networks are used to generate the signature. In some examples, the synthetic biometric signature is based at least in part on the user's actual biometric signature but is modified using an artificial biometric signature. Biometric signatures in some examples comprise actual biometric characteristics as they may be captured by an electronic input device (microphone, camera, fingerprint scanner, iris scanner, mouse, touch screen, accelerometers, location sensors etc.) [0027-0028])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system to generate synthetic fingerprint using AI with the technique as disclosed by Mesrsmid to provide a degree of security as Mesrsmid suggests in [0028].
claim 10, a method with the same scope as claim 3, is rejected.
claim 16, a non-transitory computer medium with the same scope as claim 3, is rejected.
With respect to claim 4, 11 and 18:
Lindley further teaches wherein the memory stores additional computer-readable instructions that, when executed by the at least one processor, cause the computing platform to: tag the smart contract based on rule information corresponding to location specific protocols. (In some embodiments, the options are determined by the notary's location based on the requirements in the location (e.g., some states do not allow video conference notarization, some states may accept cryptographic signatures). [Col 10:20-24])
claim 11, a method with the same scope as claim 4, is rejected.
claim 18, a non-transitory computer medium with the same scope as claim 4, is rejected.
With respect to claim 5, 12 and 19:
Lindley further teaches wherein the one or more individuals associated with the document for remote online notarization comprise parties to the smart contract. (For example, the notary can request the user to provide via the video conference various identity verification documents to fulfill the notary requirement. Receiving operation 410 receives a signature in accordance with the option selected or requested. [Col 10:27-50])
claim 12, a method with the same scope as claim 5, is rejected.
claim 19, a non-transitory computer medium with the same scope as claim 5, is rejected.
Claim(s) 6-7, 13-14 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Lindley”, “Obradovic”, “Treat” and “Mesrsmid” and “Spaling” as applied to claim 1 above, and further in view of Khuong (US 20230206219 A1).
With respect to claim 6, 13 and 20:
Lindley in view of Obradovic and Treat and Mesrsmid and Spaling does not teach wherein the smart contract is generated based on a blockchain-based smart contract token standard. However,
Khuong teaches:
wherein the smart contract is generated based on a blockchain-based smart contract token standard. (In a standard non-fungible token (NFT) (e.g. ERC-721) smart contract, there is one member called tokenId. The tokenId is an unsigned integer member that represents the id of the NFT within the smart contract. [0142])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Lindley in view of Obradovic and Treat and Mesrsmid and Spaling to generate smart contract token with the technique as disclosed by Khuong to reduce privacy issue as Khuong suggested in [0300].
claim 13, a method with the same scope as claim 6, is rejected.
claim 20, a non-transitory computer medium with the same scope as claim 6, is rejected.
With respect to claim 7 and 14:
Khuong further teaches wherein the smart contract comprises a hexadecimal address. (the Token Address is a 32-byte long value computed by concatenating its creator's smart contract address (20 bytes) with its tokenId number written in hexadecimal format [0093])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system to generate smart contract with address with the technique as disclosed by Khuong to reduce privacy issue as Khuong suggested in [0300].
claim 14, a method with the same scope as claim 7, is rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20170352012 A1: A method and system are provided to support a decentralized distributed ledger in which transactions are recorded by parties to the transactions without the use of a blockchain. A distributed ledger system provides a protocol framework that supports the development of protocol flows. A protocol flow is computer code that controls the performance of a transaction by the party or parties to the transaction. Protocol flows can be developed for different types of transactions. The distributed ledger system allows transactions to be proposed, accepted, and notarized by a notary and stored without the use of a blockchain ledger. The distributed ledger system can avoid the expense of the computational and storage resources needed to redundantly verify a transaction and store evidence on the many nodes of a blockchain distributed ledger.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZESHENG XIAO whose telephone number is (571)272-6627. The examiner can normally be reached 10:00am-4:30pm M-F.
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 on (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.
/Z.X./Examiner, Art Unit 3685
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights