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 .
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
Examiner notes that it does not appear that there is support for the subject matter of the independent claims in any of the provisional patent applications filed in this patent family. Accordingly, all claims are being accorded an effective filing date of 16 May 2022. Applicant can overcome this by pointing out with particular detail, how the provisional applications provide the necessary support for any claim where Applicant wishes to receive the benefit of the earlier filing date.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 25 November 2024 has been considered by the examiner.
Claim Rejections - 35 USC § 112
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 7 is 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 7 recites the limitation "the confidence score" in line 1. There is insufficient antecedent basis for this limitation in the claim as no confidence score is recited in claim 1. Claim 3 would provide antecedent basis for this claim, and for the purposes of examination, claim 7 is being treated as if it depends from claim 3. Appropriate correction is required.
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, 3-13 and 15-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1, 13 and 20 are directed to an abstract idea without significantly more.
Step 2A, prong 1: Claims 1, 13 and 20 are directed to an abstract idea because the following claim limitations recite an abstract idea: verifying ownership, provenance, and lineage of an asset; (Certain Methods of Organizing Human Activity; verifying stock ownership in order to issue replacement certificates);
generating one or more tokens corresponding to the asset, wherein the one or more tokens contain information providing proof of the ownership, the provenance, and the lineage of the digital asset (Certain Methods of Organizing Human Activity; issuing the certificate
mapping, in an registry, the asset to the one or more tokens (Certain Methods of Organizing Human Activity; registering the certificate) and
depositing the one or more tokens into a wallet, wherein the one or more tokens are tradeable on a asset exchange, and a valuation of the one or more tokens is based on at least a valuation of the asset (Certain Methods of Organizing Human Activity; paling the certificate in an account where it can be traded).
Claims 1, 13 and 20 all contain the common additional elements of the asset, tokens and wallet are digital, the registry is electronic and that a first and second block chain are involved. Claim 13 recites the additional elements of a generic processor and memory. Claim 20 recites the additional element of a non-transitory processor-readable medium.
Step 2A, prong 2:The claim amounts to organizing the activity of asset ownership and, therefore, fails to provide any improvement to the functioning of a computer or technology. No technical solution is recited to a technical problem. Regarding claims 1, 13 and 20, the additional elements fail to integrate the abstract idea into a practical application because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea. Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Step 2B:Likewise, the claims fail to recite, both when viewing the additional elements alone and in combination the abstract idea, significantly more than the abstract idea itself. Claims 1, 13 and 20 fail to recite significantly more than the abstract idea because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea. Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Therefore, claims 1, 13 and 20 are directed to an abstract idea without significantly more and are unpatentable under 35 USC 101.
With respect to claims 2 and 14, Claims 2 and 14 recite the additional element wherein the verifying comprises blockchain forensic analysis and triangulation of one or more electronic devices involved in one or more blockchain transactions relating to the digital asset. This limitation is not directed to the abstract idea of claims 1 and 13, and represents “significantly more” than the abstract idea.
Claims 3 and 15 are directed to an abstract idea without significantly more.
Step 2A, prong 1: Claims 3 and 15 are directed to an abstract idea because the following claim limitations recite an abstract idea: computing a confidence score corresponding to the asset, wherein the confidence score is a measurement derived from the verifying, and the valuation of the one or more tokens is further based on the confidence score (Certain Methods of Organizing Human Activity; risk assessment).
Claims 3 and 15 both contain the common additional elements of the asset and tokens are digital.
Step 2A, prong 2:The claim amounts to organizing the activity of asset ownership and risk assessment and, therefore, fails to provide any improvement to the functioning of a computer or technology. No technical solution is recited to a technical problem. Regarding claims 3 and 15, the additional elements fail to integrate the abstract idea into a practical application because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea. Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Step 2B:Likewise, the claims fail to recite, both when viewing the additional elements alone and in combination the abstract idea, significantly more than the abstract idea itself. Claims 3 and 15 fail to recite significantly more than the abstract idea because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea. Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Therefore, claims 3 and 15 are directed to an abstract idea without significantly more and are unpatentable under 35 USC 101.
Claims 4 and 16 are directed to an abstract idea without significantly more.
Step 2A, prong 1: Claims 4 and 16 have no elements that directly recite the abstract idea
Claims 4 and 16 both contain the common additional elements of wherein the first blockchain and the second blockchain are different blockchains.
Step 2A, prong 2:The claim amounts to organizing the activity of asset ownership and risk assessment and, therefore, fails to provide any improvement to the functioning of a computer or technology. No technical solution is recited to a technical problem. Regarding claims 4 and 16, the additional elements fail to integrate the abstract idea into a practical application because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea, as they only serve to describe various of the additional elements Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Step 2B:Likewise, the claims fail to recite, both when viewing the additional elements alone and in combination the abstract idea, significantly more than the abstract idea itself. Claims 4 and 16 fail to recite significantly more than the abstract idea because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea. Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Therefore, claims 4 and 16 are directed to an abstract idea without significantly more and are unpatentable under 35 USC 101.
Claim 5 is directed to an abstract idea without significantly more.
Step 2A, prong 1: Claim 5 has no elements that directly recite the abstract idea
Claim 5 contains the additional element of wherein the valuation of the one or more digital tokens is further based on one or more economic conditions.
Step 2A, prong 2:The claim amounts to organizing the activity of asset ownership and risk assessment and, therefore, fails to provide any improvement to the functioning of a computer or technology. No technical solution is recited to a technical problem. Regarding claim 5, the additional elements fail to integrate the abstract idea into a practical application because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea, as they only serve to describe various of the additional elements Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Step 2B:Likewise, the claims fail to recite, both when viewing the additional elements alone and in combination the abstract idea, significantly more than the abstract idea itself. Claim 5 fails to recite significantly more than the abstract idea because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea. Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Therefore, claim 5 is directed to an abstract idea without significantly more and are unpatentable under 35 USC 101.
Claim 6 is directed to an abstract idea without significantly more.
Step 2A, prong 1: Claim 6 is directed to an abstract idea because the following claim limitations recite an abstract idea: predicting one or more activities relating to the asset.
Claim 6 contains the additional elements of wherein the verifying comprises utilizing one or more machine learning models and where the asset is digital.
Step 2A, prong 2:The claim amounts to organizing the activity of asset ownership and risk assessment and, therefore, fails to provide any improvement to the functioning of a computer or technology. No technical solution is recited to a technical problem. Regarding claim 6, the additional elements fail to integrate the abstract idea into a practical application because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea. Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Step 2B:Likewise, the claims fail to recite, both when viewing the additional elements alone and in combination the abstract idea, significantly more than the abstract idea itself. Claim 6 fails to recite significantly more than the abstract idea because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea. Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Therefore, claim 6 is directed to an abstract idea without significantly more and are unpatentable under 35 USC 101.
Claim 7 is directed to an abstract idea without significantly more.
Step 2A, prong 1: Claim 5 has no elements that directly recite the abstract idea
Claim 5 contains the additional element of wherein the confidence score is computed based on one or more verification parameters..
Step 2A, prong 2:The claim amounts to organizing the activity of asset ownership and risk assessment and, therefore, fails to provide any improvement to the functioning of a computer or technology. No technical solution is recited to a technical problem. Regarding claim 7, the additional elements fail to integrate the abstract idea into a practical application because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea, as they only serve to describe various of the additional elements Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Step 2B:Likewise, the claims fail to recite, both when viewing the additional elements alone and in combination the abstract idea, significantly more than the abstract idea itself. Claim 7 fails to recite significantly more than the abstract idea because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea. Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Therefore, claim 7 is directed to an abstract idea without significantly more and are unpatentable under 35 USC 101.
Claims 8 and 17 are directed to an abstract idea without significantly more.
Step 2A, prong 1: Claims 8 and 17 are directed to an abstract idea because the following claim limitations recite an abstract idea: monitoring the asset; (Certain Methods of Organizing Human Activity; risk assessment);
updating the confidence score based on the monitoring (Certain Methods of Organizing Human Activity; risk assessment).
Claims 8 and 17 both contain the common additional elements of the asset is digital.
Step 2A, prong 2:The claim amounts to organizing the activity of asset ownership and risk assessment and, therefore, fails to provide any improvement to the functioning of a computer or technology. No technical solution is recited to a technical problem. Regarding claims 8 and 17, the additional elements fail to integrate the abstract idea into a practical application because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea. Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Step 2B:Likewise, the claims fail to recite, both when viewing the additional elements alone and in combination the abstract idea, significantly more than the abstract idea itself. Claims 8 and 17 fail to recite significantly more than the abstract idea because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea. Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Therefore, claims 8 and 17 are directed to an abstract idea without significantly more and are unpatentable under 35 USC 101.
Claims 9 and 18 are directed to an abstract idea without significantly more.
Step 2A, prong 1: Claims 9 and 18 are directed to an abstract idea because the following claim limitations recite an abstract idea: wherein the confidence score is updated if a private key corresponding to the asset is lost (Certain Methods of Organizing Human Activity; risk assessment).
Claims 9 and 18 both contain the common additional elements of the asset is digital.
Step 2A, prong 2:The claim amounts to organizing the activity of asset ownership and risk assessment and, therefore, fails to provide any improvement to the functioning of a computer or technology. No technical solution is recited to a technical problem. Regarding claims 9 and 18, the additional elements fail to integrate the abstract idea into a practical application because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea. Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Step 2B:Likewise, the claims fail to recite, both when viewing the additional elements alone and in combination the abstract idea, significantly more than the abstract idea itself. Claims 9 and 18 fail to recite significantly more than the abstract idea because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea. Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Therefore, claims 9 and 18 are directed to an abstract idea without significantly more and are unpatentable under 35 USC 101.
Claims 10 and 19 are directed to an abstract idea without significantly more.
Step 2A, prong 1: Claims 10 and 19 are directed to an abstract idea because the following claim limitations recite an abstract idea: wherein the confidence score is updated if the asset is under a third-party attack. (Certain Methods of Organizing Human Activity; risk assessment).
Claims 10 and 19 both contain the common additional elements of the asset is digital.
Step 2A, prong 2:The claim amounts to organizing the activity of asset ownership and risk assessment and, therefore, fails to provide any improvement to the functioning of a computer or technology. No technical solution is recited to a technical problem. Regarding claims 10 and 19, the additional elements fail to integrate the abstract idea into a practical application because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea. Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Step 2B:Likewise, the claims fail to recite, both when viewing the additional elements alone and in combination the abstract idea, significantly more than the abstract idea itself. Claims 10 and 19 fail to recite significantly more than the abstract idea because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea. Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Therefore, claims 10 and 19 are directed to an abstract idea without significantly more and are unpatentable under 35 USC 101.
Claim 11 is directed to an abstract idea without significantly more.
Step 2A, prong 1: Claim 11 is directed to an abstract idea because the following claim limitations recite an abstract idea: wherein the valuation of the asset is updated based on the confidence score
Claim 6 contains the additional element of where the asset is digital.
Step 2A, prong 2:The claim amounts to organizing the activity of asset ownership and risk assessment and, therefore, fails to provide any improvement to the functioning of a computer or technology. No technical solution is recited to a technical problem. Regarding claim 11, the additional elements fail to integrate the abstract idea into a practical application because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea. Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Step 2B:Likewise, the claims fail to recite, both when viewing the additional elements alone and in combination the abstract idea, significantly more than the abstract idea itself. Claim 11 fails to recite significantly more than the abstract idea because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea. Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Therefore, claim 11 is directed to an abstract idea without significantly more and are unpatentable under 35 USC 101.
Claim 12 is directed to an abstract idea without significantly more.
Step 2A, prong 1: Claim 12 is directed to an abstract idea because the following claim limitations recite an abstract idea: wherein the one or more tokens are sold on the asset exchange
Claim 12 contains the additional element of where the exchange and tokens are digital.
Step 2A, prong 2:The claim amounts to organizing the activity of asset ownership and risk assessment and, therefore, fails to provide any improvement to the functioning of a computer or technology. No technical solution is recited to a technical problem. Regarding claim 12, the additional elements fail to integrate the abstract idea into a practical application because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea. Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Step 2B:Likewise, the claims fail to recite, both when viewing the additional elements alone and in combination the abstract idea, significantly more than the abstract idea itself. Claim 12 fails to recite significantly more than the abstract idea because all the additional elements, even when considered under 112f, are all recited at a level of generality and are merely using computers as a tool to implement the abstract idea. Thus, the additional elements amount to mere instructions to apply the exception (see MPEP 2106.05(f)).
Therefore, claim 12 is directed to an abstract idea without significantly more and are unpatentable under 35 USC 101.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 4-5, 12-14, 16 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No. 12,380,416 to Goldberg et al. in view of U.S. Patent Application Publication No. 2018/0158054 by Ardashev et al.
As to claims 1, 13 and 20, Goldberg discloses a method/system/medium comprising:
generating, on a second blockchain, one or more digital tokens corresponding to the digital asset, wherein the one or more digital tokens contain information providing proof of the ownership, the provenance, and the lineage of the digital asset (Goldberg: Col 5, Line 58 - Col 6, Line 34; “As used herein, a “cryptographic digital asset” or “CDA” can be any type of cryptographic digital asset such as, for example, a coin, a token, a fungible token, or a non-fungible token (NFT). A CDA such as an NFT is a cryptographically signed representation of ownership rights relating to a unique asset or item and may, but does not necessarily, provide or convey any ownership or interest in the asset or item itself.” And “A CDA including any associated smart contract is generally registered on a digital ledger (e.g., blockchain) to provide such things as a record of the purchase of the CDA, proof of ownership of the CDA, immutable evidence of the smart contract and its terms, etc”.)
mapping, in an electronic registry, the digital asset to the one or more digital tokens (Goldberg: Fig 8; Col 18 Lines 25-51; “FIG. 8 is a flowchart depicting updating a CDA on a CFT system, in accordance with some embodiments of the present disclosure. Control begins at 804 to receive a scan of a tag along including associated information such as lifecycle information, a photograph of the lifecycle item, a location of the lifecycle item, a timestamp, etc. Control continues to 808 to update a corresponding CDA on the digital public ledger with the tag information (based on the received identifier of the tag that is also associated with the CDA). The CDA is updated (which could also be updated off-chain based on the tag identifier or the unique ID of the CDA) with information such as lifecycle information, a photo, a location, a timestamp, etc. Control continues to 812 to optionally notify the CDA owner of updated lifecycle information. In various implementations, such as when the CDA is not owned, step 812 may be skipped or optional. Control proceeds to 816 to determine if lifecycle information indicated that the corresponding item (e.g., plant) has been reached a completion event. If no, control ends. If yes, control continues to 820 to determine if the completion event represents a successful completion event or an unsuccessful completion event. Then, control continues to 824 to decouple the RFID tag associated with the item from the NFT (that is, decoupling the identifier of the RFID tag and the unique ID of the NFT). Control then proceeds to 828 to complete payment to CDA owner with the redemption value if the completion event was a successful completion event. Then, control ends.”); and
depositing the one or more digital tokens into a digital wallet, wherein the one or more digital tokens are tradeable on a digital asset exchange, and a valuation of the one or more digital tokens is based on at least a valuation of the digital asset (Goldberg: Fig 8; Col 18 Lines 25-51; “FIG. 8 is a flowchart depicting updating a CDA on a CFT system, in accordance with some embodiments of the present disclosure. Control begins at 804 to receive a scan of a tag along including associated information such as lifecycle information, a photograph of the lifecycle item, a location of the lifecycle item, a timestamp, etc. Control continues to 808 to update a corresponding CDA on the digital public ledger with the tag information (based on the received identifier of the tag that is also associated with the CDA). The CDA is updated (which could also be updated off-chain based on the tag identifier or the unique ID of the CDA) with information such as lifecycle information, a photo, a location, a timestamp, etc. Control continues to 812 to optionally notify the CDA owner of updated lifecycle information. In various implementations, such as when the CDA is not owned, step 812 may be skipped or optional. Control proceeds to 816 to determine if lifecycle information indicated that the corresponding item (e.g., plant) has been reached a completion event. If no, control ends. If yes, control continues to 820 to determine if the completion event represents a successful completion event or an unsuccessful completion event. Then, control continues to 824 to decouple the RFID tag associated with the item from the NFT (that is, decoupling the identifier of the RFID tag and the unique ID of the NFT). Control then proceeds to 828 to complete payment to CDA owner with the redemption value if the completion event was a successful completion event. Then, control ends.”).
Goldberg does not expressly disclose verifying ownership, provenance, and lineage of a digital asset on a first blockchain.
Ardashev discloses verifying ownership, provenance, and lineage of a digital asset on a first blockchain (Ardashev: Page 3, Sec 28; “FIG. 3B illustrates a flow diagram of an example method of tracking asset ownership according to example embodiments. Referring to FIG. 3B, the method 350 comprises one or more of creating an initial identifier representing an asset and an owner entity of the asset in a blockchain 352, identifying an identity block associated with the initial identifier 354, identifying an asset transfer of the asset from the owner entity to a blockchain entity 356, responsive to the asset transfer, verifying one or more previous asset owners associated with the asset 358, and completing the asset transfer based on the verification of the one or more previous asset owners 362. In this embodiment, verifying provenance is important, however, individual verification by a participant each time may also be used to ensure the transfer is valid and the identity block is not falsified. The asset may be quarantined until the verification is complete. The verification may be affirmed and then the asset can be forwarded after the verification is confirmed.”).
Goldberg and Ardashev are analogous art because they are from the common area of blockchain based assets.
It would have been obvious to one of ordinary skill in the art, at or before the effective filing date of the instant application, to use the asset validation of Ardashev in the system of Goldberg. The rationale would have been to effectively track digital assets (Ardashev: Page 3, Sec 28).
As to claims 2 and 14, the modified Goldberg/Ardashev reference further discloses wherein the verifying comprises blockchain forensic analysis and triangulation of one or more electronic devices involved in one or more blockchain transactions relating to the digital asset (Ardashev: Page 3, Sec 28; “FIG. 3B illustrates a flow diagram of an example method of tracking asset ownership according to example embodiments. Referring to FIG. 3B, the method 350 comprises one or more of creating an initial identifier representing an asset and an owner entity of the asset in a blockchain 352, identifying an identity block associated with the initial identifier 354, identifying an asset transfer of the asset from the owner entity to a blockchain entity 356, responsive to the asset transfer, verifying one or more previous asset owners associated with the asset 358, and completing the asset transfer based on the verification of the one or more previous asset owners 362. In this embodiment, verifying provenance is important, however, individual verification by a participant each time may also be used to ensure the transfer is valid and the identity block is not falsified. The asset may be quarantined until the verification is complete. The verification may be affirmed and then the asset can be forwarded after the verification is confirmed.”).
As to claims 4 and 16, the modified Goldberg/Ardashev reference further discloses wherein the first blockchain and the second blockchain are different blockchains (Goldberg: Fig 8; Col 18 Lines 25-51; and Ardashev: Page 3, Sec 28).
As to claim 5, the modified Goldberg/Ardashev reference further discloses wherein the valuation of the one or more digital tokens is further based on one or more economic conditions (Goldberg: Fig 8; Col 18 Lines 25-51; “FIG. 8 is a flowchart depicting updating a CDA on a CFT system, in accordance with some embodiments of the present disclosure. Control begins at 804 to receive a scan of a tag along including associated information such as lifecycle information, a photograph of the lifecycle item, a location of the lifecycle item, a timestamp, etc. Control continues to 808 to update a corresponding CDA on the digital public ledger with the tag information (based on the received identifier of the tag that is also associated with the CDA). The CDA is updated (which could also be updated off-chain based on the tag identifier or the unique ID of the CDA) with information such as lifecycle information, a photo, a location, a timestamp, etc. Control continues to 812 to optionally notify the CDA owner of updated lifecycle information. In various implementations, such as when the CDA is not owned, step 812 may be skipped or optional. Control proceeds to 816 to determine if lifecycle information indicated that the corresponding item (e.g., plant) has been reached a completion event. If no, control ends. If yes, control continues to 820 to determine if the completion event represents a successful completion event or an unsuccessful completion event. Then, control continues to 824 to decouple the RFID tag associated with the item from the NFT (that is, decoupling the identifier of the RFID tag and the unique ID of the NFT). Control then proceeds to 828 to complete payment to CDA owner with the redemption value if the completion event was a successful completion event. Then, control ends.”).
As to claim 12, the modified Goldberg/Ardashev reference further discloses wherein the one or more digital tokens are sold on the digital asset exchange (Goldberg: Fig 8; Col 18 Lines 25-51; “FIG. 8 is a flowchart depicting updating a CDA on a CFT system, in accordance with some embodiments of the present disclosure. Control begins at 804 to receive a scan of a tag along including associated information such as lifecycle information, a photograph of the lifecycle item, a location of the lifecycle item, a timestamp, etc. Control continues to 808 to update a corresponding CDA on the digital public ledger with the tag information (based on the received identifier of the tag that is also associated with the CDA). The CDA is updated (which could also be updated off-chain based on the tag identifier or the unique ID of the CDA) with information such as lifecycle information, a photo, a location, a timestamp, etc. Control continues to 812 to optionally notify the CDA owner of updated lifecycle information. In various implementations, such as when the CDA is not owned, step 812 may be skipped or optional. Control proceeds to 816 to determine if lifecycle information indicated that the corresponding item (e.g., plant) has been reached a completion event. If no, control ends. If yes, control continues to 820 to determine if the completion event represents a successful completion event or an unsuccessful completion event. Then, control continues to 824 to decouple the RFID tag associated with the item from the NFT (that is, decoupling the identifier of the RFID tag and the unique ID of the NFT). Control then proceeds to 828 to complete payment to CDA owner with the redemption value if the completion event was a successful completion event. Then, control ends.”).
Claims 3, 6-8, 11, 15 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No. 12,380,416 to Goldberg et al. in view of U.S. Patent Application Publication No. 2018/0158054 by Ardashev et al. further in view of U.S. Patent Application Publication No. 2023/0298016 by Osborn et al.
As to claims 3 and 15, the modified Goldberg/Ardashev reference discloses all recited elements of claims 1 and 13 from which claims 3 and 15 depend.
The modified reference does not expressly disclose further comprising: computing a confidence score corresponding to the digital asset, wherein the confidence score is a measurement derived from the verifying, and the valuation of the one or more digital tokens is further based on the confidence score.
Osborn discloses further comprising: computing a confidence score corresponding to the digital asset, wherein the confidence score is a measurement derived from the verifying, and the valuation of the one or more digital tokens is further based on the confidence score (Osborn; Page 8, Sec 75- Page 9, Sec 95; “[0075] In some examples, disclosed systems or methods may involve one or more of the following clauses: [0076] Clause 1: An oracle device, comprising: a processor; and memory in communication with the processor and storing instructions that, when executed by the processor, are configured to cause the oracle device to: train a machine learning model based on transaction pattern data for a plurality of blockchain payment transactions associated with a plurality of entities; receive transaction context data from a wallet application executed by a client device, wherein the transaction context data comprises a destination blockchain address and is associated with a proposed transaction that comprises a transfer of an asset maintained by the wallet application to a recipient via a blockchain network; apply the trained machine learning model to the transaction context data to generate a confidence score indicative of validity of the proposed transaction; send the confidence score to the wallet application in response to the transaction context data and for display by the client device; and update the machine learning model based on the transaction context data and a completion indication received from the wallet application and indicative of whether the asset was transferred to the recipient via the destination blockchain address. [0077] Clause 2: The oracle device of clause 1, wherein the transaction pattern data comprises, for one or more of the blockchain payment transactions, a payment type indicating a purchase, sale, or peer-to-peer transfer, an amount, or a category of associated goods or services. [0078] Clause 3: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to, responsive to determining that the confidence score is below a threshold value as a result of the machine learning model having insufficient data, record the destination blockchain address in a database. [0079] Clause 4: The oracle device of clause 3, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to asynchronously retrieve the destination blockchain address from the database and perform a forensic analysis of the destination blockchain address. [0080] Clause 5: The oracle device of clause 4, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to one or more of determine whether fraud has been reported as associated with the destination blockchain address, query one or more blockchain exchange service databases to obtain address identity verification data, or perform web scraping of one or more websites based on the destination blockchain address, in order to perform the forensic analysis. [0081] Clause 6: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to: receive from the wallet application an indication of fraudulent activity associated with the proposed transaction subsequent to completion of the proposed transaction; and update the machine learning model based on the indication of fraudulent activity. [0082] Clause 7: The oracle device of clause 1, wherein the transaction context data comprises an identity of the recipient and the confidence score reflects a likelihood that the recipient identity corresponds with the destination blockchain address. [0083] Clause 8: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to, in order to update the machine learning model, update one or more distributions for a plurality of destination blockchain addresses associated with a plurality of monitored historical blockchain transactions, wherein the distributions comprise a payment type distribution, an amount distribution, a purpose distribution, or a category of associated goods or services distribution. [0084] Clause 9: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to generate the confidence score at least in part based on a comparison of one or more portions of the transaction context data to one or more generated distributions for the destination blockchain address. [0085] Clause 10: The oracle device of clause 1, wherein the transaction context data comprises an identity of the recipient and the instructions, when executed by the processor, are further configured to cause the oracle device to, responsive to determining that the confidence score exceeds a threshold value, record a non-fungible token (NFT) in the blockchain network, wherein the NFT comprises an association of the destination blockchain address and the recipient identity. [0086] Clause 11: An oracle device, comprising: a processor; and memory in communication with the processor and storing instructions that, when executed by the processor, are configured to cause the oracle device to: receive transaction context data from a blockchain node of a blockchain network and following execution of a smart contract on the blockchain node, wherein the transaction context data comprises a destination address and is associated with an automated transfer of an asset via the blockchain network; apply a machine learning model to the transaction context data to generate a confidence score indicative of validity of the automated transfer; send the generated confidence score to the blockchain node; and update the machine learning model based on the transaction context data and a completion indication received from the blockchain node and indicative of whether the asset was transferred via the destination address and the blockchain network. [0087] Clause 12: The oracle device of clause 11, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to, responsive to determining that the confidence score exceeds a threshold value, send a positive binary value to the blockchain node. [0088] Clause 13: The oracle device of clause 11, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to train the machine learning model based on transaction pattern data for a plurality of blockchain payment transactions associated with a plurality of entities. [0089] Clause 14: The oracle device of clause 11, wherein the generated confidence score comprises a binary value and the smart contract is configured to allow the automated transfer of the asset to the destination address via the blockchain network, when the binary value is a positive value, and disallow the automated transfer of the asset, when the binary value is a negative value. [0090] Clause 15: The oracle device of clause 11, wherein the transaction context data comprises one or more of an identity of a recipient of the asset, a purpose of the automated transfer, an amount of the automated transfer, or a category of goods or services associated with the automated transfer. [0091] Clause 16: The oracle device of clause 11, wherein the transaction context data comprises an identity of a recipient of the asset and the confidence score reflects a likelihood that the destination address belongs to the identity. [0092] Clause 17: An oracle device, comprising: a processor; and memory in communication with the processor and storing instructions that, when executed by the processor, are configured to cause the oracle device to: receive transaction context data from a source device, wherein the transaction context data comprises a destination address and is associated with a transfer of an asset via a blockchain network; apply a machine learning model to the transaction context data to generate a confidence score; send the generated confidence score to the source device in response to the transaction context data; and update the machine learning model based on the transaction context data and a completion indication received from the source device and indicative of whether the asset was transferred via the destination address. [0093] Clause 18: The oracle device of clause 17, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to train the machine learning model based on transaction pattern data for a plurality of blockchain payment transactions associated with a plurality of entities. [0094] Clause 19: The oracle device of clause 17, wherein the source device comprises a client device, transaction context data is received from a wallet application executed by the client device, and the generated confidence score is sent to the wallet application. [0095] Clause 20: The oracle device of clause 17, wherein the source device comprises a blockchain node of a blockchain network and the transaction context data is received following execution of a smart contract on the blockchain node.”).
The modified reference and Osborn are analogous art because they are from the common area of blockchain based assets.
It would have been obvious to one of ordinary skill in the art, at or before the effective filing date of the instant application, to use the confidence score of Osborn in the system of the modified reference. The rationale would have been to measure confidence in transactions (Osborn; Page 8, Sec 75- Page 9, Sec 95).
As to claim 6, modified Goldberg/Ardashev/Osborn reference further discloses wherein the verifying comprises utilizing one or more machine learning models to predict one or more activities relating to the digital asset (Osborn; Page 8, Sec 75- Page 9, Sec 95; “[0075] In some examples, disclosed systems or methods may involve one or more of the following clauses: [0076] Clause 1: An oracle device, comprising: a processor; and memory in communication with the processor and storing instructions that, when executed by the processor, are configured to cause the oracle device to: train a machine learning model based on transaction pattern data for a plurality of blockchain payment transactions associated with a plurality of entities; receive transaction context data from a wallet application executed by a client device, wherein the transaction context data comprises a destination blockchain address and is associated with a proposed transaction that comprises a transfer of an asset maintained by the wallet application to a recipient via a blockchain network; apply the trained machine learning model to the transaction context data to generate a confidence score indicative of validity of the proposed transaction; send the confidence score to the wallet application in response to the transaction context data and for display by the client device; and update the machine learning model based on the transaction context data and a completion indication received from the wallet application and indicative of whether the asset was transferred to the recipient via the destination blockchain address. [0077] Clause 2: The oracle device of clause 1, wherein the transaction pattern data comprises, for one or more of the blockchain payment transactions, a payment type indicating a purchase, sale, or peer-to-peer transfer, an amount, or a category of associated goods or services. [0078] Clause 3: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to, responsive to determining that the confidence score is below a threshold value as a result of the machine learning model having insufficient data, record the destination blockchain address in a database. [0079] Clause 4: The oracle device of clause 3, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to asynchronously retrieve the destination blockchain address from the database and perform a forensic analysis of the destination blockchain address. [0080] Clause 5: The oracle device of clause 4, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to one or more of determine whether fraud has been reported as associated with the destination blockchain address, query one or more blockchain exchange service databases to obtain address identity verification data, or perform web scraping of one or more websites based on the destination blockchain address, in order to perform the forensic analysis. [0081] Clause 6: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to: receive from the wallet application an indication of fraudulent activity associated with the proposed transaction subsequent to completion of the proposed transaction; and update the machine learning model based on the indication of fraudulent activity. [0082] Clause 7: The oracle device of clause 1, wherein the transaction context data comprises an identity of the recipient and the confidence score reflects a likelihood that the recipient identity corresponds with the destination blockchain address. [0083] Clause 8: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to, in order to update the machine learning model, update one or more distributions for a plurality of destination blockchain addresses associated with a plurality of monitored historical blockchain transactions, wherein the distributions comprise a payment type distribution, an amount distribution, a purpose distribution, or a category of associated goods or services distribution. [0084] Clause 9: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to generate the confidence score at least in part based on a comparison of one or more portions of the transaction context data to one or more generated distributions for the destination blockchain address. [0085] Clause 10: The oracle device of clause 1, wherein the transaction context data comprises an identity of the recipient and the instructions, when executed by the processor, are further configured to cause the oracle device to, responsive to determining that the confidence score exceeds a threshold value, record a non-fungible token (NFT) in the blockchain network, wherein the NFT comprises an association of the destination blockchain address and the recipient identity. [0086] Clause 11: An oracle device, comprising: a processor; and memory in communication with the processor and storing instructions that, when executed by the processor, are configured to cause the oracle device to: receive transaction context data from a blockchain node of a blockchain network and following execution of a smart contract on the blockchain node, wherein the transaction context data comprises a destination address and is associated with an automated transfer of an asset via the blockchain network; apply a machine learning model to the transaction context data to generate a confidence score indicative of validity of the automated transfer; send the generated confidence score to the blockchain node; and update the machine learning model based on the transaction context data and a completion indication received from the blockchain node and indicative of whether the asset was transferred via the destination address and the blockchain network. [0087] Clause 12: The oracle device of clause 11, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to, responsive to determining that the confidence score exceeds a threshold value, send a positive binary value to the blockchain node. [0088] Clause 13: The oracle device of clause 11, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to train the machine learning model based on transaction pattern data for a plurality of blockchain payment transactions associated with a plurality of entities. [0089] Clause 14: The oracle device of clause 11, wherein the generated confidence score comprises a binary value and the smart contract is configured to allow the automated transfer of the asset to the destination address via the blockchain network, when the binary value is a positive value, and disallow the automated transfer of the asset, when the binary value is a negative value. [0090] Clause 15: The oracle device of clause 11, wherein the transaction context data comprises one or more of an identity of a recipient of the asset, a purpose of the automated transfer, an amount of the automated transfer, or a category of goods or services associated with the automated transfer. [0091] Clause 16: The oracle device of clause 11, wherein the transaction context data comprises an identity of a recipient of the asset and the confidence score reflects a likelihood that the destination address belongs to the identity. [0092] Clause 17: An oracle device, comprising: a processor; and memory in communication with the processor and storing instructions that, when executed by the processor, are configured to cause the oracle device to: receive transaction context data from a source device, wherein the transaction context data comprises a destination address and is associated with a transfer of an asset via a blockchain network; apply a machine learning model to the transaction context data to generate a confidence score; send the generated confidence score to the source device in response to the transaction context data; and update the machine learning model based on the transaction context data and a completion indication received from the source device and indicative of whether the asset was transferred via the destination address. [0093] Clause 18: The oracle device of clause 17, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to train the machine learning model based on transaction pattern data for a plurality of blockchain payment transactions associated with a plurality of entities. [0094] Clause 19: The oracle device of clause 17, wherein the source device comprises a client device, transaction context data is received from a wallet application executed by the client device, and the generated confidence score is sent to the wallet application. [0095] Clause 20: The oracle device of clause 17, wherein the source device comprises a blockchain node of a blockchain network and the transaction context data is received following execution of a smart contract on the blockchain node.”).
As to claim 7, modified Goldberg/Ardashev/Osborn reference further discloses wherein the confidence score is computed based on one or more verification parameters (Osborn; Page 8, Sec 75- Page 9, Sec 95; “[0075] In some examples, disclosed systems or methods may involve one or more of the following clauses: [0076] Clause 1: An oracle device, comprising: a processor; and memory in communication with the processor and storing instructions that, when executed by the processor, are configured to cause the oracle device to: train a machine learning model based on transaction pattern data for a plurality of blockchain payment transactions associated with a plurality of entities; receive transaction context data from a wallet application executed by a client device, wherein the transaction context data comprises a destination blockchain address and is associated with a proposed transaction that comprises a transfer of an asset maintained by the wallet application to a recipient via a blockchain network; apply the trained machine learning model to the transaction context data to generate a confidence score indicative of validity of the proposed transaction; send the confidence score to the wallet application in response to the transaction context data and for display by the client device; and update the machine learning model based on the transaction context data and a completion indication received from the wallet application and indicative of whether the asset was transferred to the recipient via the destination blockchain address. [0077] Clause 2: The oracle device of clause 1, wherein the transaction pattern data comprises, for one or more of the blockchain payment transactions, a payment type indicating a purchase, sale, or peer-to-peer transfer, an amount, or a category of associated goods or services. [0078] Clause 3: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to, responsive to determining that the confidence score is below a threshold value as a result of the machine learning model having insufficient data, record the destination blockchain address in a database. [0079] Clause 4: The oracle device of clause 3, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to asynchronously retrieve the destination blockchain address from the database and perform a forensic analysis of the destination blockchain address. [0080] Clause 5: The oracle device of clause 4, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to one or more of determine whether fraud has been reported as associated with the destination blockchain address, query one or more blockchain exchange service databases to obtain address identity verification data, or perform web scraping of one or more websites based on the destination blockchain address, in order to perform the forensic analysis. [0081] Clause 6: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to: receive from the wallet application an indication of fraudulent activity associated with the proposed transaction subsequent to completion of the proposed transaction; and update the machine learning model based on the indication of fraudulent activity. [0082] Clause 7: The oracle device of clause 1, wherein the transaction context data comprises an identity of the recipient and the confidence score reflects a likelihood that the recipient identity corresponds with the destination blockchain address. [0083] Clause 8: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to, in order to update the machine learning model, update one or more distributions for a plurality of destination blockchain addresses associated with a plurality of monitored historical blockchain transactions, wherein the distributions comprise a payment type distribution, an amount distribution, a purpose distribution, or a category of associated goods or services distribution. [0084] Clause 9: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to generate the confidence score at least in part based on a comparison of one or more portions of the transaction context data to one or more generated distributions for the destination blockchain address. [0085] Clause 10: The oracle device of clause 1, wherein the transaction context data comprises an identity of the recipient and the instructions, when executed by the processor, are further configured to cause the oracle device to, responsive to determining that the confidence score exceeds a threshold value, record a non-fungible token (NFT) in the blockchain network, wherein the NFT comprises an association of the destination blockchain address and the recipient identity. [0086] Clause 11: An oracle device, comprising: a processor; and memory in communication with the processor and storing instructions that, when executed by the processor, are configured to cause the oracle device to: receive transaction context data from a blockchain node of a blockchain network and following execution of a smart contract on the blockchain node, wherein the transaction context data comprises a destination address and is associated with an automated transfer of an asset via the blockchain network; apply a machine learning model to the transaction context data to generate a confidence score indicative of validity of the automated transfer; send the generated confidence score to the blockchain node; and update the machine learning model based on the transaction context data and a completion indication received from the blockchain node and indicative of whether the asset was transferred via the destination address and the blockchain network. [0087] Clause 12: The oracle device of clause 11, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to, responsive to determining that the confidence score exceeds a threshold value, send a positive binary value to the blockchain node. [0088] Clause 13: The oracle device of clause 11, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to train the machine learning model based on transaction pattern data for a plurality of blockchain payment transactions associated with a plurality of entities. [0089] Clause 14: The oracle device of clause 11, wherein the generated confidence score comprises a binary value and the smart contract is configured to allow the automated transfer of the asset to the destination address via the blockchain network, when the binary value is a positive value, and disallow the automated transfer of the asset, when the binary value is a negative value. [0090] Clause 15: The oracle device of clause 11, wherein the transaction context data comprises one or more of an identity of a recipient of the asset, a purpose of the automated transfer, an amount of the automated transfer, or a category of goods or services associated with the automated transfer. [0091] Clause 16: The oracle device of clause 11, wherein the transaction context data comprises an identity of a recipient of the asset and the confidence score reflects a likelihood that the destination address belongs to the identity. [0092] Clause 17: An oracle device, comprising: a processor; and memory in communication with the processor and storing instructions that, when executed by the processor, are configured to cause the oracle device to: receive transaction context data from a source device, wherein the transaction context data comprises a destination address and is associated with a transfer of an asset via a blockchain network; apply a machine learning model to the transaction context data to generate a confidence score; send the generated confidence score to the source device in response to the transaction context data; and update the machine learning model based on the transaction context data and a completion indication received from the source device and indicative of whether the asset was transferred via the destination address. [0093] Clause 18: The oracle device of clause 17, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to train the machine learning model based on transaction pattern data for a plurality of blockchain payment transactions associated with a plurality of entities. [0094] Clause 19: The oracle device of clause 17, wherein the source device comprises a client device, transaction context data is received from a wallet application executed by the client device, and the generated confidence score is sent to the wallet application. [0095] Clause 20: The oracle device of clause 17, wherein the source device comprises a blockchain node of a blockchain network and the transaction context data is received following execution of a smart contract on the blockchain node.”).
As to claims 8 and 17, the modified Goldberg/Ardashev/Osborn reference further discloses further comprising: monitoring the digital asset; and updating the confidence score based on the monitoring (Osborn; Page 8, Sec 75- Page 9, Sec 95; “[0075] In some examples, disclosed systems or methods may involve one or more of the following clauses: [0076] Clause 1: An oracle device, comprising: a processor; and memory in communication with the processor and storing instructions that, when executed by the processor, are configured to cause the oracle device to: train a machine learning model based on transaction pattern data for a plurality of blockchain payment transactions associated with a plurality of entities; receive transaction context data from a wallet application executed by a client device, wherein the transaction context data comprises a destination blockchain address and is associated with a proposed transaction that comprises a transfer of an asset maintained by the wallet application to a recipient via a blockchain network; apply the trained machine learning model to the transaction context data to generate a confidence score indicative of validity of the proposed transaction; send the confidence score to the wallet application in response to the transaction context data and for display by the client device; and update the machine learning model based on the transaction context data and a completion indication received from the wallet application and indicative of whether the asset was transferred to the recipient via the destination blockchain address. [0077] Clause 2: The oracle device of clause 1, wherein the transaction pattern data comprises, for one or more of the blockchain payment transactions, a payment type indicating a purchase, sale, or peer-to-peer transfer, an amount, or a category of associated goods or services. [0078] Clause 3: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to, responsive to determining that the confidence score is below a threshold value as a result of the machine learning model having insufficient data, record the destination blockchain address in a database. [0079] Clause 4: The oracle device of clause 3, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to asynchronously retrieve the destination blockchain address from the database and perform a forensic analysis of the destination blockchain address. [0080] Clause 5: The oracle device of clause 4, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to one or more of determine whether fraud has been reported as associated with the destination blockchain address, query one or more blockchain exchange service databases to obtain address identity verification data, or perform web scraping of one or more websites based on the destination blockchain address, in order to perform the forensic analysis. [0081] Clause 6: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to: receive from the wallet application an indication of fraudulent activity associated with the proposed transaction subsequent to completion of the proposed transaction; and update the machine learning model based on the indication of fraudulent activity. [0082] Clause 7: The oracle device of clause 1, wherein the transaction context data comprises an identity of the recipient and the confidence score reflects a likelihood that the recipient identity corresponds with the destination blockchain address. [0083] Clause 8: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to, in order to update the machine learning model, update one or more distributions for a plurality of destination blockchain addresses associated with a plurality of monitored historical blockchain transactions, wherein the distributions comprise a payment type distribution, an amount distribution, a purpose distribution, or a category of associated goods or services distribution. [0084] Clause 9: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to generate the confidence score at least in part based on a comparison of one or more portions of the transaction context data to one or more generated distributions for the destination blockchain address. [0085] Clause 10: The oracle device of clause 1, wherein the transaction context data comprises an identity of the recipient and the instructions, when executed by the processor, are further configured to cause the oracle device to, responsive to determining that the confidence score exceeds a threshold value, record a non-fungible token (NFT) in the blockchain network, wherein the NFT comprises an association of the destination blockchain address and the recipient identity. [0086] Clause 11: An oracle device, comprising: a processor; and memory in communication with the processor and storing instructions that, when executed by the processor, are configured to cause the oracle device to: receive transaction context data from a blockchain node of a blockchain network and following execution of a smart contract on the blockchain node, wherein the transaction context data comprises a destination address and is associated with an automated transfer of an asset via the blockchain network; apply a machine learning model to the transaction context data to generate a confidence score indicative of validity of the automated transfer; send the generated confidence score to the blockchain node; and update the machine learning model based on the transaction context data and a completion indication received from the blockchain node and indicative of whether the asset was transferred via the destination address and the blockchain network. [0087] Clause 12: The oracle device of clause 11, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to, responsive to determining that the confidence score exceeds a threshold value, send a positive binary value to the blockchain node. [0088] Clause 13: The oracle device of clause 11, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to train the machine learning model based on transaction pattern data for a plurality of blockchain payment transactions associated with a plurality of entities. [0089] Clause 14: The oracle device of clause 11, wherein the generated confidence score comprises a binary value and the smart contract is configured to allow the automated transfer of the asset to the destination address via the blockchain network, when the binary value is a positive value, and disallow the automated transfer of the asset, when the binary value is a negative value. [0090] Clause 15: The oracle device of clause 11, wherein the transaction context data comprises one or more of an identity of a recipient of the asset, a purpose of the automated transfer, an amount of the automated transfer, or a category of goods or services associated with the automated transfer. [0091] Clause 16: The oracle device of clause 11, wherein the transaction context data comprises an identity of a recipient of the asset and the confidence score reflects a likelihood that the destination address belongs to the identity. [0092] Clause 17: An oracle device, comprising: a processor; and memory in communication with the processor and storing instructions that, when executed by the processor, are configured to cause the oracle device to: receive transaction context data from a source device, wherein the transaction context data comprises a destination address and is associated with a transfer of an asset via a blockchain network; apply a machine learning model to the transaction context data to generate a confidence score; send the generated confidence score to the source device in response to the transaction context data; and update the machine learning model based on the transaction context data and a completion indication received from the source device and indicative of whether the asset was transferred via the destination address. [0093] Clause 18: The oracle device of clause 17, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to train the machine learning model based on transaction pattern data for a plurality of blockchain payment transactions associated with a plurality of entities. [0094] Clause 19: The oracle device of clause 17, wherein the source device comprises a client device, transaction context data is received from a wallet application executed by the client device, and the generated confidence score is sent to the wallet application. [0095] Clause 20: The oracle device of clause 17, wherein the source device comprises a blockchain node of a blockchain network and the transaction context data is received following execution of a smart contract on the blockchain node.”).
As to claim 11, modified Goldberg/Ardashev/Osborn reference further discloses wherein the valuation of the digital asset is updated based on the confidence score (Osborn; Page 8, Sec 75- Page 9, Sec 95; “[0075] In some examples, disclosed systems or methods may involve one or more of the following clauses: [0076] Clause 1: An oracle device, comprising: a processor; and memory in communication with the processor and storing instructions that, when executed by the processor, are configured to cause the oracle device to: train a machine learning model based on transaction pattern data for a plurality of blockchain payment transactions associated with a plurality of entities; receive transaction context data from a wallet application executed by a client device, wherein the transaction context data comprises a destination blockchain address and is associated with a proposed transaction that comprises a transfer of an asset maintained by the wallet application to a recipient via a blockchain network; apply the trained machine learning model to the transaction context data to generate a confidence score indicative of validity of the proposed transaction; send the confidence score to the wallet application in response to the transaction context data and for display by the client device; and update the machine learning model based on the transaction context data and a completion indication received from the wallet application and indicative of whether the asset was transferred to the recipient via the destination blockchain address. [0077] Clause 2: The oracle device of clause 1, wherein the transaction pattern data comprises, for one or more of the blockchain payment transactions, a payment type indicating a purchase, sale, or peer-to-peer transfer, an amount, or a category of associated goods or services. [0078] Clause 3: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to, responsive to determining that the confidence score is below a threshold value as a result of the machine learning model having insufficient data, record the destination blockchain address in a database. [0079] Clause 4: The oracle device of clause 3, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to asynchronously retrieve the destination blockchain address from the database and perform a forensic analysis of the destination blockchain address. [0080] Clause 5: The oracle device of clause 4, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to one or more of determine whether fraud has been reported as associated with the destination blockchain address, query one or more blockchain exchange service databases to obtain address identity verification data, or perform web scraping of one or more websites based on the destination blockchain address, in order to perform the forensic analysis. [0081] Clause 6: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to: receive from the wallet application an indication of fraudulent activity associated with the proposed transaction subsequent to completion of the proposed transaction; and update the machine learning model based on the indication of fraudulent activity. [0082] Clause 7: The oracle device of clause 1, wherein the transaction context data comprises an identity of the recipient and the confidence score reflects a likelihood that the recipient identity corresponds with the destination blockchain address. [0083] Clause 8: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to, in order to update the machine learning model, update one or more distributions for a plurality of destination blockchain addresses associated with a plurality of monitored historical blockchain transactions, wherein the distributions comprise a payment type distribution, an amount distribution, a purpose distribution, or a category of associated goods or services distribution. [0084] Clause 9: The oracle device of clause 1, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to generate the confidence score at least in part based on a comparison of one or more portions of the transaction context data to one or more generated distributions for the destination blockchain address. [0085] Clause 10: The oracle device of clause 1, wherein the transaction context data comprises an identity of the recipient and the instructions, when executed by the processor, are further configured to cause the oracle device to, responsive to determining that the confidence score exceeds a threshold value, record a non-fungible token (NFT) in the blockchain network, wherein the NFT comprises an association of the destination blockchain address and the recipient identity. [0086] Clause 11: An oracle device, comprising: a processor; and memory in communication with the processor and storing instructions that, when executed by the processor, are configured to cause the oracle device to: receive transaction context data from a blockchain node of a blockchain network and following execution of a smart contract on the blockchain node, wherein the transaction context data comprises a destination address and is associated with an automated transfer of an asset via the blockchain network; apply a machine learning model to the transaction context data to generate a confidence score indicative of validity of the automated transfer; send the generated confidence score to the blockchain node; and update the machine learning model based on the transaction context data and a completion indication received from the blockchain node and indicative of whether the asset was transferred via the destination address and the blockchain network. [0087] Clause 12: The oracle device of clause 11, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to, responsive to determining that the confidence score exceeds a threshold value, send a positive binary value to the blockchain node. [0088] Clause 13: The oracle device of clause 11, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to train the machine learning model based on transaction pattern data for a plurality of blockchain payment transactions associated with a plurality of entities. [0089] Clause 14: The oracle device of clause 11, wherein the generated confidence score comprises a binary value and the smart contract is configured to allow the automated transfer of the asset to the destination address via the blockchain network, when the binary value is a positive value, and disallow the automated transfer of the asset, when the binary value is a negative value. [0090] Clause 15: The oracle device of clause 11, wherein the transaction context data comprises one or more of an identity of a recipient of the asset, a purpose of the automated transfer, an amount of the automated transfer, or a category of goods or services associated with the automated transfer. [0091] Clause 16: The oracle device of clause 11, wherein the transaction context data comprises an identity of a recipient of the asset and the confidence score reflects a likelihood that the destination address belongs to the identity. [0092] Clause 17: An oracle device, comprising: a processor; and memory in communication with the processor and storing instructions that, when executed by the processor, are configured to cause the oracle device to: receive transaction context data from a source device, wherein the transaction context data comprises a destination address and is associated with a transfer of an asset via a blockchain network; apply a machine learning model to the transaction context data to generate a confidence score; send the generated confidence score to the source device in response to the transaction context data; and update the machine learning model based on the transaction context data and a completion indication received from the source device and indicative of whether the asset was transferred via the destination address. [0093] Clause 18: The oracle device of clause 17, wherein the instructions, when executed by the processor, are further configured to cause the oracle device to train the machine learning model based on transaction pattern data for a plurality of blockchain payment transactions associated with a plurality of entities. [0094] Clause 19: The oracle device of clause 17, wherein the source device comprises a client device, transaction context data is received from a wallet application executed by the client device, and the generated confidence score is sent to the wallet application. [0095] Clause 20: The oracle device of clause 17, wherein the source device comprises a blockchain node of a blockchain network and the transaction context data is received following execution of a smart contract on the blockchain node.”).
Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No. 12,380,416 to Goldberg et al. in view of U.S. Patent Application Publication No. 2018/0158054 by Ardashev et al. further in view of U.S. Patent Application Publication No. 2023/0298016 by Osborn et al. further in view of U.S. Patent Application Publication No. 2019/0007205 by Corduan et al.
As to claims 9 and 18, the modified Goldberg/Ardashev/Osborn reference discloses all recited elements of claims 8 and 17 from which claims 9 and 18 depend.
The modified reference does not expressly disclose wherein the confidence score is updated if a private key corresponding to the digital asset is lost.
Corduan discloses wherein the confidence score is updated if a private key corresponding to the digital asset is lost (Corduan: Page 4, Sec 40; “he owner of a lost wallet can retrieve the shares of their private key from the trusted parties after their identity is verified using a new wallet using multi-party consensus on the immutable ledger. When a new wallet is created, it will include the key manager 202A and then use the key recovery engine to initiate the recovery of the private key. A wallet can collect access grants (which may contain a confidence score) from third parties and other smart contracts. The wallet of a trusted third party will contain a list of required access grants needed to return a share back to its original owner. If the owner's new wallet contains the necessary access grants for a given trusted party, they can issue a request on the immutable ledger to be given the corresponding share back, encrypted with the new wallet's public key”.)
The modified reference and Corduan are analogous art because they are from the common area of asset protection.
It would have been obvious to one of ordinary skill in the art, at or before the effective filing date of the instant application, to use the confidence score update of Corduan in the system of the modified reference. The rationale would have been to kee the score up to date (Corduan: Page 4, Sec 40).
Claims 10 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No. 12,380,416 to Goldberg et al. in view of U.S. Patent Application Publication No. 2018/0158054 by Ardashev et al. further in view of U.S. Patent Application Publication No. 2023/0298016 by Osborn et al. further in view of U.S. Patent Application Publication No. 2022/0301288 by Higuchi et al.
As to claims 10 and 19, the modified Goldberg/Ardashev/Osborn reference discloses all recited elements of claims 8 and 17 from which claims 10 and 19 depend.
The modified reference does not expressly disclose wherein the confidence score is updated if the digital asset is under a third-party attack.
Higuchi discloses wherein the confidence score is updated if the digital asset is under a third-party attack (Higuchi: Page 6, Sec 76-77; “[0076] As a simple attack method premised on the black-box attack, one method considered is to repeatedly input an image to the classification model 141 to obtain the confidence score of a specified class and update the image so as to increase the confidence score until the confidence score is sufficiently high. In the case of using a gradient-based search algorithm such as a gradient descent-based search algorithm, the gradient of confidence score with respect to the pixel values of an image (the partial derivatives of confidence score with respect to the pixel values) is calculated, and the pixel values are updated based on the gradient. [0077] In the above simple attack method, however, the number of updates of an image increases and the number of accesses to the classification model 141 to input the image thereto increases in order to obtain a sufficiently high confidence score, because images have a large number of dimensions and high flexibility. For example, the number of accesses to the classification model 141 may reach several hundreds of millions, and even if the time taken to make one access is one millisecond, it took several days to complete the inference. In addition, in the case where an initial image to be first input is an image that is oddly different from a desired sample image, such as a completely white image or a completely black image, the image update may converge to a local solution. In this case, an image obtained by maximizing the confidence score may be greatly different from the sample image, meaning that the model inversion attack fails”.)
The modified reference and Higuchi are analogous art because they are from the common area of asset protection.
It would have been obvious to one of ordinary skill in the art, at or before the effective filing date of the instant application, to use the confidence score update of Higuchi in the system of the modified reference. The rationale would have been to keep the score up to date (Higuchi: Page 6, Sec 76-77).
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,182,232. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims if the instant application represent a broadening of the claims of the ‘232 Patent and as such the claims of the ‘232 Patent anticipate the claims if the instant application.
As to claim 1, the ‘232 Patent discloses a method comprising (Claim 1: A method comprising):
verifying ownership, provenance, and lineage of a digital asset on a first blockchain (Claim 1: verifying a digital asset to determine ownership, provenance, and lineage of the digital asset, wherein the verifying includes blockchain forensic analysis and triangulation of one or more electronic devices involved in one or more blockchain transactions relating to the digital asset);
generating, on a second blockchain, one or more digital tokens corresponding to the digital asset (Claim 1: generating one or more digital tokens on a blockchain), wherein the one or more digital tokens contain information providing proof of the ownership, the provenance, and the lineage of the digital asset (Claim 1: and the one or more digital tokens contain information providing proof of the ownership, the provenance, and the lineage of the digital asset for valuation of the digital asset);
mapping, in an electronic registry, the digital asset to the one or more digital tokens (Claim 1: maintaining a record of the digital asset in an electronic registry, wherein the record includes the confidence score and is indicative of the ownership, the provenance); and
depositing the one or more digital tokens into a digital wallet, wherein the one or more digital tokens are tradeable on a digital asset exchange, and a valuation of the one or more digital tokens is based on at least a valuation of the digital asset (Claim 1: wherein the one or more digital tokens are deposited into a digital wallet, the one or more digital tokens are tradeable on a digital asset exchange, valuation of the one or more digital tokens is based on the confidence score).
As to claim 2, the ‘232 Patent discloses the method of claim 1, wherein the verifying comprises blockchain forensic analysis and triangulation of one or more electronic devices involved in one or more blockchain transactions relating to the digital asset (Claim 1: wherein the verifying includes blockchain forensic analysis and triangulation of one or more electronic devices involved in one or more blockchain transactions relating to the digital asset).
As to claim 3, the ‘232 Patent discloses the method of claim 1, further comprising: computing a confidence score corresponding to the digital asset, wherein the confidence score is a measurement derived from the verifying (Claim 1: computing a confidence score corresponding to the digital asset, wherein the confidence score is a measurement derived from the verifying), and
the valuation of the one or more digital tokens is further based on the confidence score (Claim 1: valuation of the one or more digital tokens is based on the confidence score).
As to claim 4, the ‘232 Patent discloses the method of claim 1, wherein the first blockchain and the second blockchain are different blockchains (Imputed from Claim 1: verifying a digital asset to determine ownership, provenance, and lineage of the digital asset, wherein the verifying includes blockchain forensic analysis and triangulation of one or more electronic devices involved in one or more blockchain transactions relating to the digital asset and Claim 1: generating one or more digital tokens on a blockchain).
As to claim 5, the ‘232 Patent discloses the method of claim 1, wherein the valuation of the one or more digital tokens is further based on one or more economic conditions (Claim 1: valuation of the one or more digital tokens is based on the confidence score, and Claim 2: wherein the confidence score is computed based on one or more verification parameters).
As to claim 6, the ‘232 Patent discloses the method of claim 1, wherein the verifying comprises utilizing one or more machine learning models to predict one or more activities relating to the digital asset (Claim 6: The method of claim 1, wherein the digital asset is monitored on a continuing basis or a periodic basis, the monitoring comprises utilizing one or more machine learning models to predict one or more activities relating to the digital asset, and the monitoring further comprises updating the one or more machine learning models based on data collected during the monitoring).
As to claim 7, the ‘232 Patent discloses the method of claim 1, wherein the confidence score is computed based on one or more verification parameters (Clam 2: The method of claim 1, wherein the confidence score is computed based on one or more verification parameters).
As to claim 8, the ‘232 Patent discloses the method of claim 3, further comprising: monitoring the digital asset; and updating the confidence score based on the monitoring (Claim 6: The method of claim 1, wherein the digital asset is monitored on a continuing basis or a periodic basis, the monitoring comprises utilizing one or more machine learning models to predict one or more activities relating to the digital asset, and the monitoring further comprises updating the one or more machine learning models based on data collected during the monitoring).
As to claim 9, the ‘232 Patent discloses the method of claim 8, wherein the confidence score is updated if a private key corresponding to the digital asset is lost (Claim 9: The method of claim 8, wherein the digital asset is distressed if a private key corresponding to the digital asset is lost).
As to claim 10, the ‘232 Patent discloses the method of claim 8, wherein the confidence score is updated if the digital asset is under a third-party attack (Claim 10: The method of claim 8, wherein the digital asset is distressed if the digital asset is under a third-party attack).
As to claim 11, the ‘232 Patent discloses the method of claim 3, wherein the valuation of the digital asset is updated based on the confidence score (Claim 1: and the one or more digital tokens contain information providing proof of the ownership, the provenance, and the lineage of the digital asset for valuation of the digital asset, and Clam 5: The method of claim 4, further comprising: updating the one or more digital tokens on the blockchain in response to the one or more changes; wherein the digital tokens are generated based on the smart contract, and the valuation of the digital asset is different from the valuation of the digital tokens.).
As to claim 12, the ‘232 Patent discloses the method of claim 1, wherein the one or more digital tokens are sold on the digital asset exchange (Claim 1: wherein the one or more digital tokens are deposited into a digital wallet, the one or more digital tokens are tradeable on a digital asset exchange).
Claims 13-19 recite a system commensurate in scope to the methods of claims 1-4 and 8-10 and are rejected under a substantially similar rationale, particularly in view of Claims 13-18 of the ‘232 Patent that disclose the structural elements of the system.
Claim 20 recites non-transitory processor-readable medium commensurate in scope to the methods of claims 1-4 and 8-10 and are rejected under a substantially similar rationale particularly in view of claims 19-20 or the ‘232 Patent.
Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. Patent Application Publication No. 2019/0251551 by Mousavi discloses valuation of digital assets
U.S. Patent Application Publication No. 2020/0050690 by Gauer et al. discloses using blockchain to store digital assets
U.S. Patent Application Publication No. 2020/0084045 by Cohen et al. discloses using blockchain to establish the provenance of a digital asset
U.S. Patent No. 10,795,977 to Soloman discloses using a distributed ledger to trace digital assets
U.S. Patent Application Publication No. 2021/0184859 by Wilbrecht et al. discloses validating a digital asset using a blockchain
U.S. Patent Application Publication No. 2022/0327235 by Lyren discloses using a smart contract on a blockchain to protect a digital asset
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL S MCNALLY whose telephone number is (571)270-1599. The examiner can normally be reached Monday-Friday, 8:30 AM - 5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey L Nickerson can be reached at (469)295-9235. 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.
MICHAEL S. MCNALLY
Primary Examiner
Art Unit 2432
/Michael S McNally/Primary Examiner, Art Unit 2432