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
CONTINUATION
This application is a continuation application of U.S. application no. 18/466,510 filed on September 13, 2023, now U.S. Patent 12,293,358 (“Parent Application”). See MPEP §201.07. In accordance with MPEP §609.02 A. 2 and MPEP §2001.06(b) (last paragraph), the Examiner has reviewed and considered the prior art cited in the Parent Application. Also in accordance with MPEP §2001.06(b) (last paragraph), all documents cited or considered ‘of record’ in the Parent Application are now considered cited or ‘of record’ in this application. Additionally, Applicant(s) are reminded that a listing of the information cited or ‘of record’ in the Parent Application need not be resubmitted in this application unless Applicants desire the information to be printed on a patent issuing from this application. See MPEP §609.02 A. 2. Finally, Applicants are reminded that the prosecution history of the Parent Application is relevant in this application. See e.g., Microsoft Corp. v. Multi-Tech Sys., Inc., 357 F.3d 1340, 1350, 69 USPQ2d 1815, 1823 (Fed. Cir. 2004) (holding that statements made in prosecution of one patent are relevant to the scope of all sibling patents).
Applicant’s claim for the benefit of U.S. provisional patent application 63/406,397 filed September 14, 2022 under 35 U.S.C. 119(e) is acknowledged.
Claim Interpretation
Claims 1, 4, 5, 6, 11, 12, 13, 14 and 17-19 each use the word “decode” or a variation of the term. Claim 4 recites a particular operation associated with the decoding i.e. “…wherein decoding further comprises decrypting a portion of the encoded transfer data” and claim 5 also recites a particular operation associated with the decoding “…wherein decoding further comprises decompressing a portion of the encoded transfer data.” However claims 1, 6, 11-14 and 17-19 do not associate any particular type of operation with the decoding and the written disclosure appears to only recite non-limiting examples in paragraph 0089 without any clear definition of the term. Therefore the broadest reasonable interpretation of the term “decode” would be the broadest dictionary definition of the term available which Examiner is providing here:
PNG
media_image1.png
792
620
media_image1.png
Greyscale
PNG
media_image2.png
112
802
media_image2.png
Greyscale
It is apparent that definition 2 “to find or understand the true or hidden meaning of (something)” is the broadest definition of the term decode particularly given the absence of any particular indication of what portion of the received request was encoded and given the absence of any specificity as to how that portion was encoded and given that the claim does not apparently require any form of secret messages or documents and merely requires that they be encoded in an unspecified manner.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recites “…receiving, via the digital wallet, a request to perform a transfer of a cryptographic asset, the request comprising encoded transfer data; decoding the encoded transfer data to determine decoded transfer data comprising a source, a destination, an activity; at least one input for the activity, and a digital signature”. Claims 6 and 14 contain similar recitations. MPEP § 2161.01 (I) states:
The written description requirement of 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph, applies to all claims including original claims that are part of the disclosure as filed. Ariad, 598 F.3d at 1349, 94 USPQ2d at 1170. As stated by the Federal Circuit, "[a]lthough many original claims will satisfy the written description requirement, certain claims may not." Id. at 1349, 94 USPQ2d at 1170-71; see also LizardTech, Inc. v. Earth Res. Mapping, Inc., 424 F.3d 1336, 1343-46, 76 USPQ2d 1724, 1730-33 (Fed. Cir. 2005); Regents of the Univ. of Cal. v. Eli Lilly & Co., 119 F.3d 1559, 1568, 43 USPQ2d 1398, 1405-06 (Fed. Cir. 1997)("The description requirement of the patent statute requires a description of an invention, not an indication of a result that one might achieve if one made that invention."). Problems satisfying the written description requirement for original claims often occur when claim language is generic or functional, or both. Ariad, 593 F.3d at 1349, 94 USPQ2d at 1171 ("The problem is especially acute with genus claims that use functional language to define the boundaries of a claimed genus. In such a case, the functional claim may simply claim a desired result, and may do so without describing species that achieve that result. But the specification must demonstrate that the applicant [inventor] has made a generic invention that achieves the claimed result and do so by showing that the applicant [inventor] has invented species sufficient to support a claim to the functionally-defined genus.").
For instance, generic claim language in the original disclosure does not satisfy the written description requirement if it fails to support the scope of the genus claimed. Ariad, 598 F.3d at 1349-50, 94 USPQ2d at 1171 ("[A]n adequate written description of a claimed genus requires more than a generic statement of an invention’s boundaries.") (citing Eli Lilly, 119 F.3d at 1568, 43 USPQ2d at 1405-06); Enzo Biochem, Inc. v. Gen-Probe, Inc., 323 F.3d 956, 968, 63 USPQ2d 1609, 1616 (Fed. Cir. 2002) (holding that generic claim language appearing in ipsis verbis in the original specification did not satisfy the written description requirement because it failed to support the scope of the genus claimed); Fiers v. Revel, 984 F.2d 1164, 1170, 25 USPQ2d 1601, 1606 (Fed. Cir. 1993) (rejecting the argument that "only similar language in the specification or original claims is necessary to satisfy the written description requirement").
The Federal Circuit has explained that a specification cannot always support expansive claim language and satisfy the requirements of 35 U.S.C. 112 "merely by clearly describing one embodiment of the thing claimed." LizardTech v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1346, 76 USPQ2d 1731, 1733 (Fed. Cir. 2005). The issue is whether a person skilled in the art would understand the inventor to have invented, and been in possession of, the invention as broadly claimed. In LizardTech, claims to a generic method of making a seamless discrete wavelet transformation (DWT) were held invalid under 35 U.S.C. 112, first paragraph, because the specification taught only one particular method for making a seamless DWT and there was no evidence that the specification contemplated a more generic method. "[T]he description of one method for creating a seamless DWT does not entitle the inventor . . . to claim any and all means for achieving that objective." LizardTech, 424 F.3d at 1346, 76 USPQ2d at 1733.
Claims 1, 6 and 14 each recite the entirety of a genus in the form of encoding however the written description at paragraph 0089 in describing the encoding service 117 only recites the function at a high level other than the last sentence of paragraph 0089 which describes two species by virtue of the recitation “…The encoding service 117 can decompress or decrypt various portions of the encoded transfer data 124 to generate the decoded transfer data 124.” However as these are the only two species named the recitation must be viewed as deficient as the language is not sufficient to support the claiming of the entire genus.
MPEP § 2161.01 (I) also recites that an original claim may be deficient when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the invention is performed:
Similarly, original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved. For software, this can occur when the algorithm or steps/procedure for performing the computer function are not explained at all or are not explained in sufficient detail (simply restating the function recited in the claim is not necessarily sufficient). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed. See MPEP §§ 2163.02 and 2181, subsection IV.
The level of detail required to satisfy the written description requirement varies depending on the nature and scope of the claims and on the complexity and predictability of the relevant technology. Ariad, 598 F.3d at 1351, 94 USPQ2d at 1172; Capon v. Eshhar, 418 F.3d 1349, 1357-58, 76 USPQ2d 1078, 1083-84 (Fed. Cir. 2005). Computer-implemented inventions are often disclosed and claimed in terms of their functionality. For computer-implemented inventions, the determination of the sufficiency of disclosure will require an inquiry into the sufficiency of both the disclosed hardware and the disclosed software due to the interrelationship and interdependence of computer hardware and software. The critical inquiry is whether the disclosure of the application relied upon reasonably conveys to those skilled in the art that the inventor had possession of the claimed subject matter as of the filing date. Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 682. 114 USPQ2d 1349, 1356 (citing Ariad Pharm., Inc. V. Eli Lilly & Co, 598 F.3d 1336, 1351, 94 USPQ2d 1161, 1172 (Fed. Cir. 2010) in the context of determining possession of a claimed means of accessing disparate databases).
When examining computer-implemented functional claims, examiners should determine whether the specification discloses the computer and the algorithm (e.g., the necessary steps and/or flowcharts) that perform the claimed function in sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor possessed the claimed subject matter at the time of filing. An algorithm is defined, for example, as "a finite sequence of steps for solving a logical or mathematical problem or performing a task." Microsoft Computer Dictionary (5th ed., 2002). Applicant may "express that algorithm in any understandable terms including as a mathematical formula, in prose, or as a flow chart, or in any other manner that provides sufficient structure." Finisar Corp. v. DirecTV Grp., Inc., 523 F.3d 1323, 1340, 86 USPQ2d 1609, 1623 (Fed. Cir. 2008) (internal citation omitted). It is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. See, e.g., Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-683, 114 USPQ2d 1349, 1356, 1357 (Fed. Cir. 2015) (reversing and remanding the district court’s grant of summary judgment of invalidity for lack of adequate written description where there were genuine issues of material fact regarding "whether the specification show[ed] possession by the inventor of how accessing disparate databases is achieved"). If the specification does not provide a disclosure of the computer and algorithm in sufficient detail to demonstrate to one of ordinary skill in the art that the inventor possessed the invention a rejection under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph, for lack of written description must be made. For more information regarding the written description requirement, see MPEP § 2162- § 2163.07(b). If the specification does not provide a disclosure of sufficient corresponding structure, materials, or acts that perform the entire claimed function of a means- (or step-) plus- function limitation in a claim under 35 U.S.C. 112(f) or the sixth paragraph of pre-AIA 35 U.S.C. 112, "the applicant has in effect failed to particularly point out and distinctly claim the invention" as required by the 35 U.S.C. 112(b) [or the second paragraph of pre-AIA 35 U.S.C. 112 ]. In re Donaldson Co., 16 F.3d 1189, 1195, 29 USPQ2d 1845, 1850 (Fed. Cir. 1994) (en banc). A rejection under 35 U.S.C. 112(b) or the second paragraph of pre-AIA 35 U.S.C. 112 must be made in addition to the written description rejection. See also MPEP § 2181, subsection II.B.2(a).
In reviewing the written description further the only recitation of encryption is at paragraph 0042 where it is recited that “The first token 104 and the second token 106 may be cryptographic tokens (e.g., encrypted strings that may be decrypted via secret data, such as a private key).” This recitation is tied to a token transfer but as the claim does not recite the transfer of a token the recitation cannot be viewed as being related to the claimed subject matter. Paragraph 0041 recites that “The first digital wallet 103 and the second digital wallet 105 may each include a public key (e.g., a wallet address) and a private key. The private key may be used to sign cryptocurrency transactions, such as a transfer of a cryptographic asset.” However the claim already recites the inclusion of a digital signature (as does claim 3) and therefore this recitation from paragraph 0041 cannot be fairly tied to the encoding and decoding operations of the claim. Therefore for both independent claim 1 and dependent claims 3 and 4 are held as being deficient as the claim and the underlying written disclosure merely recite a desired result without sufficiently describing how that result is achieved as applied to encryption and decryption. With regard to the decompression species from paragraph 0089 no decompression or compression algorithm is ever recited in the written disclosure. Therefore independent claim 1 along with dependent claim 3 and dependent claim 5 which expressly recites the decompressing operation as being part of the decoding operation the written disclosure is also held as being deficient as it merely recites an obtained result without describing how that result is obtained.
Analysis of independent claims 6 and 14 along with dependent claims 7, 10, 16 and 20 also recite encoded data and claims 11, 12, 13, 17, 18 and 19 recite decoded transfer data and as these claims would rely on the same portions of the written description used in analyzing claims 1, 3, 4 and 5. Therefore claims 1, 3, 4, 5, 6, 7, 10, 11, 12, 13, 16, 17, 18, 19 and 20 are all held as lacking insufficient support in the written description for both the claiming of a genus when the written description describes an insufficient amount of species necessary to support the claiming of a genus and for lacking insufficient written description as the written description merely describes an obtained result without any algorithm that teaches how the result would be obtained.
Claim 2 recites “The method of claim 1, wherein registering the service comprises obtaining cryptographic authorization for the digital wallet.” Claims 9 and 15 contain a similar recitation. While the written description contains seven instances of the term “cryptographic authorization” (at paragraphs 0030, 0032, 0062 and 0105) the written description does not describe any algorithm for performing the cryptographic authorization and therefore states nothing more than a desired result. Therefore claims 2, 9 and 15 are also held as lacking sufficient written description support for the claims.
Claim 13 recites “The system of claim 6, wherein the at least one computing device is further configured to analyze the decoded transfer data based on properties associated with the request comprising a geolocation.” Claim 19 contains a similar recitation. In reviewing the written description there are eight instances of the word “geolocation” at paragraphs 0049, 0052, 0058, 0088, 0090, 0091, 0097 and 0108. Paragraph 0091 is the most descriptive and recites “…Non-limiting examples of user settings and historical user activities include request timestamp (e.g., requests made outside of normal activity periods may be fraudulent), geolocation of the computing device from which the request was received (e.g., requests from outside one or more geozones, or within other geozones, may be fraudulent), and device data of the request-transmitting computing device (e.g., requests associated with a computing device that is different from a historically used computing device may be fraudulent).” Nothing in this recitation suggests any algorithm or other mechanism for either determining if a particular geolocation is within a geozone or how a particular geozone is determined to either be fraudulent or not fraudulent and the claim does nothing more than recite an obtained result without describing how the result was obtained. Therefore claims 13 and 19 are held as lacking sufficient written description support for the claims.
Claims 2-5 are also rejected as being dependent upon claim 1.
Claims 7-13 are also rejected as being dependent upon claim 6.
Claims 15-20 are also rejected as being dependent upon claim 14.
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 5 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 5 recites “wherein decoding further comprises decompressing a portion of the encoded transfer data”. Compression and decompression is typically associated with a file where the file is compressed in order to reduce the size of the file prior to transmission (or archived) and then decompressed when received in order to restore the file to something that can be used by an application (where a typical compression/decompression application would be a Zip file). However there is nothing in the claim that would apparently require compression and subsequent decompression and the written disclosure provides no context for how compression and decompression would be applied to what appear to be nothing more than simple (and relatively small) data expressions. Therefore it is unclear as to how to interpret the operation given the absence of any explanation as to what the intended use of the stated decompression operation would be or what data present in claim 1 would even require decompression as none of the data in the received request of claim 1 is expressed as being compressed and therefore does not provide any antecedent basis for the decompression operation. Therefore claim 5 is held as being indefinite.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta (U.S. Patent Publication 2023/02980007) in view of Dagan “The Actual Networking behind the Ethereum Network: How It Works”, August 16, 2018, 12 pages, in view of Transactions, Author unknown, retrieved from internet archive of https://ethereum.org/en/developers/docs/transactions/, August 27, 2022, 13 pages, in view of Kim et al. (Korean Patent Application KR 2021/0086378 A, hereinafter referred to as Kim).
As per claims 1, 6 and 14
Gupta discloses registering a service with a digital wallet associated with a user account for processing of cryptographic transactions (0030 “The digital wallet verification system 200 may include a user device (now shown) for providing a user input through an application. The digital wallet verification system may include the application adapted to be installed in the user device or operated as Software as a service (SAAS) from the user device of the user.”, 0040 “In an example embodiment, the digital wallet 108, 118 may allow the profiles to store, manage and perform transaction of their cryptocurrency over the blockchain 102. In the example, the digital wallet 108, 118 may contain cryptocurrencies. The digital wallet 108, 118 may include an identification key which may be a public key on any public or private or hybrid blockchain. The public key allows to view the profile and its information associated with the digital wallet. Each of the digital wallet (W1, W2, W3) 108, 118 may have a unique public key associated with them.”)
Gupta discloses receiving, via the digital wallet, a request to perform a transfer of a cryptographic asset, the request comprising encoded transfer data; (0052 “In an example, the blockchain transaction is having a cryptocurrency amount transferred from the digital wallet 108 associated with the first profile. In case, the first profile 104 has associated more than one digital wallet (W1, W2, W3,....Wn) 108, then the registration module 212 may determine the ownership for each of the digital wallet (W1, W2, W3,....Wn) 108 associated with the first profile 104. In an example embodiment, the registration module 212 may determine the ownership for the digital wallet 108 if the first profile 104 submits a cryptographically verifiable document (CVD) or a verifiable credentials. The submission of CVD may be indicative of verifying the ownership of the digital wallet 108 by the first profile 104.”)
Gupta discloses analyzing the decoded transfer data to determine whether to permit the transfer of the cryptographic asset for the request (0067 “In an embodiment, the notification module 224 may be further configured to tagging the digital wallet 108, 118 or the respective status 106, 116 of the first profile 104 and the second profile 114 as potentially associated with a blacklisted transaction. The blacklisted transaction may be defined by the external agency or the institution indicating that the transaction is a suspicious activity with some criminal antecedents. The tagging of the digital wallet 108, 118 or the respective status 106, 116 associated with the blacklisted transaction is based on at least one of: [0068] (a) determining the digital wallet processing the blockchain transaction 102 in the cluster of related transactions is contained on a public or private blacklist; [0069] (b) determining the profile associated with digital wallet processing the blockchain transaction 112 in the cluster of related transactions is associated with a sanctions list or sanctioned country [0070] (c) determining the profile associated with digital wallet processing the blockchain transaction 112 in the cluster of related transactions is associated with a transaction amount over a predetermined threshold and the status of the profile is not updated after the predetermined criteria”)
As per claim 6 Gupta discloses a data store (0048 “The data 208 serves, amongst other things, as a repository for storing data processed, received, and generated by one or more of the modules 206.”)
As per claim 6 Gupta discloses at least one computing device in communication with the data store (0043 “The digital wallet verification system 200 may include, but is not limited to, a processor 202, a memory 204, modules 206, and a data 208. The modules 206 and the memory 204 may be coupled to the processor 202.”)
As per claim 14 Gupta discloses a non-transitory computer readable medium embodying a program (0044 “The processor 202 can be a single processing unit or several units, all of which could include multiple computing units. The processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 202 is adapted to fetch and execute computer-readable instructions and data stored in the memory 204”, 0045 “The memory 204 may include any non-transitory computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read-only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.”)
Gupta does not explicitly discloses decoding the encoded transfer data to determine decoded transfer data decoding the encoded transfer data (pages 6 and 7 “RLPx and Data Transfer
For data transfer, Ethereum uses a protocol named RLPx. RLPx enables nodes to transfer encrypted, serialized data. Firstly, RLPx’s node discovery protocol is a Kademlia-like protocol similar to the one mentioned above.
When two nodes want to communicate, they send each other some cryptographic data (public keys and such) to make sure all of the subsequent data transfer is encrypted (using ECDH, ECDHE, ECIES and more elliptic curve cryptography) and cryptographically signed (you can learn more about elliptic curve cryptography here). Then, both nodes send to each other which protocols and which versions of these protocols they support: The Ethereum protocol is “eth,” Ethereum’s Whisper protocol is “shh” (Get it?), and the Light Ethereum Node Subprotocol is “les.”
After all messages are encrypted and a protocol agreed upon, the subsequent messages are dependent on the protocol chosen.”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the due diligence system for cryptocurrencies of Gupta with the networking behind the Ethereum network of Dagan for the purpose of communicating securely with the suite of protocols and technologies developed to make sure the internet can be somewhat decentralized (Dagan at page 7).
Neither Gupta nor Dagan explicitly disclose the transfer data comprising a source, a destination, an activity; at least one input for the activity, and a digital signature. Transactions teaches the transfer data comprising a source, a destination, an activity; at least one input for the activity, and a digital signature. (pages 2 and 3
“A submitted transaction includes the following information:
from – the address of the sender, that will be signing the transaction. This will be an externally-owned account as contract accounts cannot send transactions
to – the receiving address (if an externally-owned account, the transaction will transfer value. If a contract account, the transaction will execute the contract code)
signature – the identifier of the sender. This is generated when the sender's private key signs the transaction and confirms the sender has authorized this transaction
nonce - a sequentially incrementing counter which indicates the transaction number from the account
value – amount of ETH to transfer from sender to recipient (denominated in WEI, where 1ETH equals 1e+18wei)
input data – optional field to include arbitrary data
gasLimit – the maximum amount of gas units that can be consumed by the transaction. The EVM specifies the units of gas required by each computational step
maxPriorityFeePerGas - the maximum price of the consumed gas to be included as a tip to the validator
maxFeePerGas - the maximum fee per unit of gas willing to be paid for the transaction (inclusive of baseFeePerGas and maxPriorityFeePerGas)”
(Examiner deems that the maxFeePerGas can be viewed as an activity and the baseFeePerGas and maxPriorityFeePerGas can be viewed as inputs to the maxFeePerGas).
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the due diligence system for cryptocurrencies of Gupta with the networking behind the Ethereum network of Dagan with Transactions for the purpose of ensuring that the transactions execute.
Neither Gupta nor Dagan or Transactions explicitly disclose in response to determining to deny the transfer, storing the request to perform the transfer in a queue for review by the user account. Kim teaches in response to determining to deny the transfer, storing the request to perform the transfer in a queue for review by the user account (Page 5 “Hereinafter, the components of the hacking response system, which are the core showing the characteristics of the present invention, will be described in more detail. The hacking response system 20 includes a filter database unit 101 , a corresponding transaction storage unit 102 , a transaction receiving unit 103 , a transaction control unit 104 , and a transaction transmitting unit 105 . Here, the filter database unit 101 receives and stores the monitoring target data and the monitoring exclusion data from the cryptocurrency owner 10 . For example, as shown in FIG. 2 , the filter database unit 101 allows transmission of preset information, that is, information on cryptocurrency owned by the user, information on tokens, and transaction information explicitly approved by the user.”, Pages 5-6 “The corresponding transaction storage unit 102 stores the hacking-response transaction for setting the transactions suspected of being hacked to be invalid or sub-priority. The corresponding transaction storage unit 102 receives and stores the private key from the cryptocurrency owner 10 or invalidates the signature transaction module that requests the cryptocurrency owner 10 to sign using the private key and the transaction suspected of being hacked. It includes a hacking response transaction module that stores a hacking response transaction that makes it or makes it subordinate”, Page 6 “Through this, the corresponding transaction storage unit 102 stores the corresponding transactions signed in advance by the cryptocurrency owner 10 as shown in FIG. 3 or transmits the signature or not transaction to the cryptocurrency owner 10 whenever necessary. to have it signed. In other words, the cryptocurrency owner 10 receives a signature request transaction requesting transmission of the private key from the corresponding transaction storage unit 102 and converts the signature request transaction into a signed transaction using the private key. At this time, the cryptographic currency owner 10 who signed the signature transaction using the private key may be the signer 11”, Page 6 “The transaction control unit 104 suspects a transaction that attempts to change the address registered by the cryptocurrency owner 10 or the owner of the registered cryptocurrency or token as a hacking attempt. On the other hand, a transaction explicitly approved by the cryptocurrency owner 10 is not considered as a hacking attempt.”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the due diligence system for cryptocurrencies of Gupta with the networking behind the Ethereum network of Dagan with Transactions with the method for preventing fraud transactions in a distributed ledger of Kim for the purpose of developing a system that blocks and prevents block chain hacking.
As per claims 2, 9 and 15
Gupta discloses wherein registering the service comprises obtaining cryptographic authorization for the digital wallet (0040 “The digital wallet 108, 118 may include an identification key which may be a public key on any public or private or hybrid blockchain. The public key allows to view the profile and its information associated with the digital wallet. Each of the digital wallet (W1, W2, W3) 108, 118 may have a unique public key associated with them. In an example, with the help of the public key of the digital wallet (W1) 108, first profile 104 information and a status 106 may be viewed.”, 0052 “In an example embodiment, the registration module 212 may determine the ownership for the digital wallet 108 if the first profile 104 submits a cryptographically verifiable document (CVD) or a verifiable credentials”)
As per claims 3, 10 and 16
Dagan teaches encoding updated transfer data (pages 6 and 7 “RLPx and Data Transfer
For data transfer, Ethereum uses a protocol named RLPx. RLPx enables nodes to transfer encrypted, serialized data. Firstly, RLPx’s node discovery protocol is a Kademlia-like protocol similar to the one mentioned above.
When two nodes want to communicate, they send each other some cryptographic data (public keys and such) to make sure all of the subsequent data transfer is encrypted (using ECDH, ECDHE, ECIES and more elliptic curve cryptography) and cryptographically signed (you can learn more about elliptic curve cryptography here). Then, both nodes send to each other which protocols and which versions of these protocols they support: The Ethereum protocol is “eth,” Ethereum’s Whisper protocol is “shh” (Get it?), and the Light Ethereum Node Subprotocol is “les.”
After all messages are encrypted and a protocol agreed upon, the subsequent messages are dependent on the protocol chosen.”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the due diligence system for cryptocurrencies of Gupta with the networking behind the Ethereum network of Dagan for the purpose of communicating securely with the suite of protocols and technologies developed to make sure the internet can be somewhat decentralized (Dagan at page 7).
Neither Gupta nor Dagan explicitly disclose the transfer data comprising a source, a destination, an activity; at least one input for the activity, and a digital signature. Transactions teaches the transfer data comprising a source, a destination, an activity; at least one input for the activity, and a digital signature. (pages 2 and 3
“A submitted transaction includes the following information:
from – the address of the sender, that will be signing the transaction. This will be an externally-owned account as contract accounts cannot send transactions
to – the receiving address (if an externally-owned account, the transaction will transfer value. If a contract account, the transaction will execute the contract code)
signature – the identifier of the sender. This is generated when the sender's private key signs the transaction and confirms the sender has authorized this transaction
nonce - a sequentially incrementing counter which indicates the transaction number from the account
value – amount of ETH to transfer from sender to recipient (denominated in WEI, where 1ETH equals 1e+18wei)
input data – optional field to include arbitrary data
gasLimit – the maximum amount of gas units that can be consumed by the transaction. The EVM specifies the units of gas required by each computational step
maxPriorityFeePerGas - the maximum price of the consumed gas to be included as a tip to the validator
maxFeePerGas - the maximum fee per unit of gas willing to be paid for the transaction (inclusive of baseFeePerGas and maxPriorityFeePerGas)”
(Examiner deems that the maxFeePerGas can be viewed as an activity and the baseFeePerGas and maxPriorityFeePerGas can be viewed as inputs to the maxFeePerGas).
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the due diligence system for cryptocurrencies of Gupta with the networking behind the Ethereum network of Dagan with Transactions for the purpose of ensuring that the transactions execute.
Neither Gupta nor Dagan or Transactions explicitly disclose receiving approval from the user account for the request from the queue. Kim teaches receiving approval from the user account for the request from the queue (Pages 5-6 “The corresponding transaction storage unit 102 stores the hacking-response transaction for setting the transactions suspected of being hacked to be invalid or sub-priority. The corresponding transaction storage unit 102 receives and stores the private key from the cryptocurrency owner 10 or invalidates the signature transaction module that requests the cryptocurrency owner 10 to sign using the private key and the transaction suspected of being hacked. It includes a hacking response transaction module that stores a hacking response transaction that makes it or makes it subordinate”, Page 6 “Through this, the corresponding transaction storage unit 102 stores the corresponding transactions signed in advance by the cryptocurrency owner 10 as shown in FIG. 3 or transmits the signature or not transaction to the cryptocurrency owner 10 whenever necessary. to have it signed. In other words, the cryptocurrency owner 10 receives a signature request transaction requesting transmission of the private key from the corresponding transaction storage unit 102 and converts the signature request transaction into a signed transaction using the private key. At this time, the cryptographic currency owner 10 who signed the signature transaction using the private key may be the signer 11”, Page 6 “The transaction control unit 104 suspects a transaction that attempts to change the address registered by the cryptocurrency owner 10 or the owner of the registered cryptocurrency or token as a hacking attempt. On the other hand, a transaction explicitly approved by the cryptocurrency owner 10 is not considered as a hacking attempt.”)
Kim teaches requesting an updated digital signature from the digital wallet (Pages 5-6 “The corresponding transaction storage unit 102 stores the hacking-response transaction for setting the transactions suspected of being hacked to be invalid or sub-priority. The corresponding transaction storage unit 102 receives and stores the private key from the cryptocurrency owner 10 or invalidates the signature transaction module that requests the cryptocurrency owner 10 to sign using the private key and the transaction suspected of being hacked. It includes a hacking response transaction module that stores a hacking response transaction that makes it or makes it subordinate”, Page 6 “Through this, the corresponding transaction storage unit 102 stores the corresponding transactions signed in advance by the cryptocurrency owner 10 as shown in FIG. 3 or transmits the signature or not transaction to the cryptocurrency owner 10 whenever necessary. to have it signed. In other words, the cryptocurrency owner 10 receives a signature request transaction requesting transmission of the private key from the corresponding transaction storage unit 102 and converts the signature request transaction into a signed transaction using the private key. At this time, the cryptographic currency owner 10 who signed the signature transaction using the private key may be the signer 11”, Page 6 “The transaction control unit 104 suspects a transaction that attempts to change the address registered by the cryptocurrency owner 10 or the owner of the registered cryptocurrency or token as a hacking attempt. On the other hand, a transaction explicitly approved by the cryptocurrency owner 10 is not considered as a hacking attempt.”)
Kim teaches sending an updated request to perform the transfer of the cryptographic asset to a transfer processing service (Page 5 “Hereinafter, the components of the hacking response system, which are the core showing the characteristics of the present invention, will be described in more detail. The hacking response system 20 includes a filter database unit 101 , a corresponding transaction storage unit 102 , a transaction receiving unit 103 , a transaction control unit 104 , and a transaction transmitting unit 105 . Here, the filter database unit 101 receives and stores the monitoring target data and the monitoring exclusion data from the cryptocurrency owner 10 . For example, as shown in FIG. 2 , the filter database unit 101 allows transmission of preset information, that is, information on cryptocurrency owned by the user, information on tokens, and transaction information explicitly approved by the user.”, Pages 5-6 “The corresponding transaction storage unit 102 stores the hacking-response transaction for setting the transactions suspected of being hacked to be invalid or sub-priority. The corresponding transaction storage unit 102 receives and stores the private key from the cryptocurrency owner 10 or invalidates the signature transaction module that requests the cryptocurrency owner 10 to sign using the private key and the transaction suspected of being hacked. It includes a hacking response transaction module that stores a hacking response transaction that makes it or makes it subordinate”, Page 6 “Through this, the corresponding transaction storage unit 102 stores the corresponding transactions signed in advance by the cryptocurrency owner 10 as shown in FIG. 3 or transmits the signature or not transaction to the cryptocurrency owner 10 whenever necessary. to have it signed. In other words, the cryptocurrency owner 10 receives a signature request transaction requesting transmission of the private key from the corresponding transaction storage unit 102 and converts the signature request transaction into a signed transaction using the private key. At this time, the cryptographic currency owner 10 who signed the signature transaction using the private key may be the signer 11”, Page 6 “The transaction control unit 104 suspects a transaction that attempts to change the address registered by the cryptocurrency owner 10 or the owner of the registered cryptocurrency or token as a hacking attempt. On the other hand, a transaction explicitly approved by the cryptocurrency owner 10 is not considered as a hacking attempt.”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the due diligence system for cryptocurrencies of Gupta with the networking behind the Ethereum network of Dagan with Transactions with the method for preventing fraud transactions in a distributed ledger of Kim for the purpose of developing a system that blocks and prevents block chain hacking.
As per claim 4
Dagan teaches wherein decoding further comprises decrypting a portion of the encoded transfer data (pages 6 and 7 “RLPx and Data Transfer
For data transfer, Ethereum uses a protocol named RLPx. RLPx enables nodes to transfer encrypted, serialized data. Firstly, RLPx’s node discovery protocol is a Kademlia-like protocol similar to the one mentioned above.
When two nodes want to communicate, they send each other some cryptographic data (public keys and such) to make sure all of the subsequent data transfer is encrypted (using ECDH, ECDHE, ECIES and more elliptic curve cryptography) and cryptographically signed (you can learn more about elliptic curve cryptography here). Then, both nodes send to each other which protocols and which versions of these protocols they support: The Ethereum protocol is “eth,” Ethereum’s Whisper protocol is “shh” (Get it?), and the Light Ethereum Node Subprotocol is “les.”
After all messages are encrypted and a protocol agreed upon, the subsequent messages are dependent on the protocol chosen.”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the due diligence system for cryptocurrencies of Gupta with the networking behind the Ethereum network of Dagan for the purpose of communicating securely with the suite of protocols and technologies developed to make sure the internet can be somewhat decentralized (Dagan at page 7).
As per claims 7 and 20
Gupta discloses transmit the request to a transaction processing service (0063 “In an embodiment, the transaction module 222 is in communication with the receiving module 210, the registration module 212, the verification module 214, the scoring module 216, the CDD module 218 and the information module 220. The transaction module 222 is adapted to ensure exchange of a public and a private transaction information between the first profile 104 and the second profile 114…In an example, the private transaction information may only be available when the blockchain transaction 112 is performed. In an example, both the first profile 104 and the second profile 114 may provide input for the private transaction information and the private transaction information.”)
Gupta does not explicitly disclose generate second encoded transfer data. Dagan teaches generate second encoded transfer data. (pages 6 and 7 “RLPx and Data Transfer
For data transfer, Ethereum uses a protocol named RLPx. RLPx enables nodes to transfer encrypted, serialized data. Firstly, RLPx’s node discovery protocol is a Kademlia-like protocol similar to the one mentioned above.
When two nodes want to communicate, they send each other some cryptographic data (public keys and such) to make sure all of the subsequent data transfer is encrypted (using ECDH, ECDHE, ECIES and more elliptic curve cryptography) and cryptographically signed (you can learn more about elliptic curve cryptography here). Then, both nodes send to each other which protocols and which versions of these protocols they support: The Ethereum protocol is “eth,” Ethereum’s Whisper protocol is “shh” (Get it?), and the Light Ethereum Node Subprotocol is “les.”
After all messages are encrypted and a protocol agreed upon, the subsequent messages are dependent on the protocol chosen.”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the due diligence system for cryptocurrencies of Gupta with the networking behind the Ethereum network of Dagan for the purpose of communicating securely with the suite of protocols and technologies developed to make sure the internet can be somewhat decentralized (Dagan at page 7).
Neither Gupta nor Dagan or transactions explicitly disclose an updated digital signature. Kim teaches an updated digital signature (Pages 5-6 “The corresponding transaction storage unit 102 stores the hacking-response transaction for setting the transactions suspected of being hacked to be invalid or sub-priority. The corresponding transaction storage unit 102 receives and stores the private key from the cryptocurrency owner 10 or invalidates the signature transaction module that requests the cryptocurrency owner 10 to sign using the private key and the transaction suspected of being hacked. It includes a hacking response transaction module that stores a hacking response transaction that makes it or makes it subordinate”, Page 6 “Through this, the corresponding transaction storage unit 102 stores the corresponding transactions signed in advance by the cryptocurrency owner 10 as shown in FIG. 3 or transmits the signature or not transaction to the cryptocurrency owner 10 whenever necessary. to have it signed. In other words, the cryptocurrency owner 10 receives a signature request transaction requesting transmission of the private key from the corresponding transaction storage unit 102 and converts the signature request transaction into a signed transaction using the private key. At this time, the cryptographic currency owner 10 who signed the signature transaction using the private key may be the signer 11”, Page 6 “The transaction control unit 104 suspects a transaction that attempts to change the address registered by the cryptocurrency owner 10 or the owner of the registered cryptocurrency or token as a hacking attempt. On the other hand, a transaction explicitly approved by the cryptocurrency owner 10 is not considered as a hacking attempt.”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the due diligence system for cryptocurrencies of Gupta with the networking behind the Ethereum network of Dagan with Transactions with the method for preventing fraud transactions in a distributed ledger of Kim for the purpose of developing a system that blocks and prevents block chain hacking.
As per claim 8
Gupta discloses wherein the transaction processing service comprises a blockchain environment. (0063 “In an embodiment, the transaction module 222 is in communication with the receiving module 210, the registration module 212, the verification module 214, the scoring module 216, the CDD module 218 and the information module 220. The transaction module 222 is adapted to ensure exchange of a public and a private transaction information between the first profile 104 and the second profile 114…In an example, the private transaction information may only be available when the blockchain transaction 112 is performed. In an example, both the first profile 104 and the second profile 114 may provide input for the private transaction information and the private transaction information.”)
As per claims 11 and 17
Gupta discloses wherein the at least one computing device is further configured to analyze the decoded transfer data by determining whether a quantity of the cryptographic asset exceeds a predetermined threshold (0059 “In an example embodiment, the scoring module is further configured take into consideration the following factor but not limiting to including, risk of country, risk of amounts, risk, and other risk as per guidelines of regulators for calculating the score. Such mentioned factors improve or reduce the score 110.”, 0067 “The tagging of the digital wallet 108, 118 or the respective status 106, 116 associated with the blacklisted transaction is based on at least one of: [0068] (a) determining the digital wallet processing the blockchain transaction 102 in the cluster of related transactions is contained on a public or private blacklist; [0069] (b) determining the profile associated with digital wallet processing the blockchain transaction 112 in the cluster of related transactions is associated with a sanctions list or sanctioned country [0070] (c) determining the profile associated with digital wallet processing the blockchain transaction 112 in the cluster of related transactions is associated with a transaction amount over a predetermined threshold and the status of the profile is not updated after the predetermined criteria.”)
As per claims 12 and 18
Gupta discloses wherein the at least one computing device is further configured to analyze the decoded transfer data based on at least one setting associated with a user account (0059 “In an example embodiment, the scoring module is further configured take into consideration the following factor but not limiting to including, risk of country, risk of amounts, risk, and other risk as per guidelines of regulators for calculating the score. Such mentioned factors improve or reduce the score 110.”, 0067 “The tagging of the digital wallet 108, 118 or the respective status 106, 116 associated with the blacklisted transaction is based on at least one of: [0068] (a) determining the digital wallet processing the blockchain transaction 102 in the cluster of related transactions is contained on a public or private blacklist; [0069] (b) determining the profile associated with digital wallet processing the blockchain transaction 112 in the cluster of related transactions is associated with a sanctions list or sanctioned country [0070] (c) determining the profile associated with digital wallet processing the blockchain transaction 112 in the cluster of related transactions is associated with a transaction amount over a predetermined threshold and the status of the profile is not updated after the predetermined criteria.”)
As per claims 13 and 19
Gupta discloses wherein the at least one computing device is further configured to analyze the decoded transfer data based on properties associated with the request comprising a geolocation (0059 “In an example embodiment, the scoring module is further configured take into consideration the following factor but not limiting to including, risk of country, risk of amounts, risk, and other risk as per guidelines of regulators for calculating the score. Such mentioned factors improve or reduce the score 110.”, 0067 “The tagging of the digital wallet 108, 118 or the respective status 106, 116 associated with the blacklisted transaction is based on at least one of: [0068] (a) determining the digital wallet processing the blockchain transaction 102 in the cluster of related transactions is contained on a public or private blacklist; [0069] (b) determining the profile associated with digital wallet processing the blockchain transaction 112 in the cluster of related transactions is associated with a sanctions list or sanctioned country [0070] (c) determining the profile associated with digital wallet processing the blockchain transaction 112 in the cluster of related transactions is associated with a transaction amount over a predetermined threshold and the status of the profile is not updated after the predetermined criteria.”)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Tian et al. “Enabling Cross-Chain Transactions: A Decentralized Cryptocurrency Exchange Protocol”, IEEE Transactions on Information Forensics and Security, Vol. 16, 2021, August 16, 2021, 14 pages proposes a distributed cryptocurrency trading scheme to solve the problem of centralized exchanges, which can achieve secure trading between different types of cryptocurrencies.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES D NIGH whose telephone number is (571)270-5486. The examiner can normally be reached 6:00 to 9:45 and 10:30 to 2:45.
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, Neha Patel can be reached at (571) 270-1492. 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.
/JAMES D NIGH/ Senior Examiner, Art Unit 3699