DETAILED ACTION
Claim Status
This is first office action on the merits in response to the application filed on 1/17/2025.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 2-21 are currently pending and have been examined.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 4/23/2025 is(are) in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 2-21 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,243,153. Although the claims at issue are not identical, they are not patentably distinct from each other because it recites the additional features of determining at least a first subset for a first denomination and a second subset for a second denomination of the first user secondary wallet private keys for the payment amount based on the different denomination and the different predefined amount of each of the first user secondary wallet private keys, wherein the first subset in the first denomination and the second subset in the second denomination add up to the payment amount; combining the first subset and the second subset of the first user secondary wallet private keys; enabling a private key disablement functionality that disables copies of the first user secondary wallet private keys that have been combined for the payment amount from being used by the plurality of first user secondary wallets. Since U.S. Patent No. 12,243,153 and the claims at issue of the present application perform similar functions, it would have been obvious to a person of ordinary skill in the art to modify claims 1-20 of U.S. Patent No. 12,243,153 by removing the additional features. It is well settled that omission of an element and its function is an obvious expedient if the remaining elements perform the same function as before. In re Karison, 136 USPQ 184 (CCPA 1963) Also note Ex parte Rainu, 168 USPQ 375 (Bd. App. 1969). Thus, omission of a reference element whose function is not needed would be obvious to one of ordinary skill in the art.
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 2-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Under the Step 1 of the Section 101 analysis, Claims 1-10 are drawn to a method which is within the four statutory categories (i.e., a process), Claims 11-17 are drawn to a system which is within the four statutory categories (i.e. a machine), and Claims 18-21 are drawn to a non-transitory computer-readable medium which is within the four statutory categories (i.e., a manufacture).
Since the claims are directed toward statutory categories, it must be determined if the claims are directed towards a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea). Based on consideration of all of the relevant factors with respect to the claim as a whole, claims 2-21 are determined to be directed to an abstract idea. The rationale for this determination is explained below:
Regarding Claim 2:
Claim 2 is drawn to an abstract idea without significantly more. The claims recite “receiving a transaction request for a transaction between two accounts for a certain amount; accessing, based on the certain amount of the transaction, a first wallet and two or more secondary wallets of a first account of the two accounts and associated with virtual currency, wherein the first wallet includes a first wallet private key, wherein the two or more secondary wallets each include a respective secondary wallet private key of secondary wallet private keys; determining, based on the transaction request, to transfer the certain amount of the virtual currency to a second wallet of a second account of the two accounts via the two or more of the secondary wallets, wherein each of the two or more of the secondary wallets are each associated with different predefined amounts of the virtual currency; identifying, in response to said determining to transfer the certain amount to the second wallet, a subset of secondary wallet private keys that are associated with the two or more of the secondary wallets; and causing to be transmitted, to the second wallet, the subset of the secondary wallet private keys.”
Under the Step 2A Prong One, the limitations, as underlined above, are processes that, under its broadest reasonable interpretation, cover Certain Methods Of Organizing Human Activity such as commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations). For example, but for the “wallet”, “virtual currency”, and “private keys” language, the underlined limitations in the context of this claim encompass the human activity. The series of steps belong to a typical sales activities or behaviors, because processing of currencies and their amounts is performed for transferring of certain amount for transactions.
Under the Step 2A Prong Two, this judicial exception is not integrated into a practical application. In particular, the claim only recites additional elements – “A method for transferring virtual currency between wallets, comprising:”, “wallet”, “virtual currency”, and “private keys”. The additional elements are recited at a high-level of generality (i.e., performing generic functions of an interaction) such that it amounts no more than mere instructions to apply the exception using a generic computer component, merely implementing an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea. Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present, there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present, there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present, there is no effecting a transformation or reduction of a particular article to a different state or thing present, and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present such that the claim as a whole is more than a drafting effort designed to monopolize the exception. Accordingly, these additional elements, individually or in combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
Under the Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements in the process amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
Regarding Claims 11 and 18:
Claims 11 and 18 are drawn to an abstract idea without significantly more. The claims recite “access, based on a transaction between two accounts for a certain amount, a first wallet of a first account of the two accounts and associated with virtual currency, wherein the first wallet includes a first wallet private key; determine, based on the transaction, to transfer the certain amount of the virtual currency to a second wallet of a second account of the two accounts via two or more secondary wallets, wherein each of the two or more of the secondary wallets are each associated with different predefined amounts of the virtual currency, wherein the two or more secondary wallets each include a respective secondary wallet private key of secondary wallet private keys; and transmit, to the second wallet, a subset of the secondary wallet private keys that are associated with the two or more of the secondary wallets.”
Under the Step 2A Prong One, the limitations, as underlined above, are processes that, under its broadest reasonable interpretation, cover Certain Methods Of Organizing Human Activity such as commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations). For example, but for the “wallet”, “virtual currency”, and “private keys” language, the underlined limitations in the context of this claim encompass the human activity. The series of steps belong to a typical sales activities or behaviors, because processing of currencies and their amounts is performed for transferring of certain amount for transactions.
Under the Step 2A Prong Two, this judicial exception is not integrated into a practical application. In particular, the claim only recites additional elements – “A virtual currency transaction system, comprising: a non-transitory memory storing instructions; and one or more hardware processors coupled to the non-transitory memory and configured to execute the instructions to cause the system to:”, “A non-transitory machine-readable medium having stored thereon machine- readable instructions executable to cause a machine to perform operations comprising:”, “wallet”, “virtual currency”, and “private keys”. The additional elements are recited at a high-level of generality (i.e., performing generic functions of an interaction) such that it amounts no more than mere instructions to apply the exception using a generic computer component, merely implementing an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea. Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present, there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present, there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present, there is no effecting a transformation or reduction of a particular article to a different state or thing present, and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present such that the claim as a whole is more than a drafting effort designed to monopolize the exception. Accordingly, these additional elements, individually or in combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
Under the Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements in the process amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
Regarding Claims 3-10, 12-17, and 19-21:
Dependent claims 3-10, 12-17, and 19-21 include additional limitations, for example, “wallet”, “user device”, and “virtual currency” (Claims 3, 13, and 20); “virtual currency” and “wallet” (Claims 4 and 15); “virtual currency” and “wallet” (Claim 5); “wallet” (Claims 6, 12, and 19); “wallet” and “server” (Claims 7 and 14); “wallet” and “user device” (Claim 8); “virtual currency”, “wallet”, and “automatically” (Claim 9); “wallet”, “virtual currency”, and “private keys” (Claims 10 and 17); and “wallet”, “server”, and “user device” (Claims 16 and 21), but none of these limitations are deemed significantly more than the abstract idea because, as stated above, they require no more than generic computer structures or signals to be executed, and do not recite any Improvements to the functioning of a computer, or Improvements to any other technology or technical field.
Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology, and their collective functions merely provide conventional computer implementation or implementing the judicial exception on a generic computer.
Therefore, whether taken individually or as an ordered combination, claims 3-10, 12-17, and 19-21 are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
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.
Claim(s) 2-5, 7-11, 13-18, 20-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ramanathan (US 10262321 B1; already of record in IDS) in view of Questembert (US 20070179883 A1; already of record in IDS).
Regarding Claim 2, Ramanathan teaches A method for transferring virtual currency between wallets, comprising (Ramanathan: Abstract):
receiving a transaction request for a transaction between two accounts for a certain amount (Ramanathan: Col. 5, lines 16-23 teach(es) FIG. 1 shows a Payer (i.e., a first user) who has his coins managed in a Digital Wallet (i.e., involving an account of a first user), and a Payee who has her coins managed in a Digital Wallet; the Payer wants (i.e., a transaction request) to send 100 units of Digital Coin to the Payee); accessing, based on the certain amount of the transaction, a first wallet and two or more secondary wallets of a first account of the two accounts and associated with virtual currency, wherein the first wallet includes a first wallet private key, wherein the two or more secondary wallets each include a respective secondary wallet private key of secondary wallet private keys (Ramanathan: Col. 5, lines 22-33; Col. 5, line 56 ~ Col. 6, line 10; Col. 6 , lines 25-39; Col. 6, lines 25-39; Col. 9, lines 4-12 teach(es) FIG. 2 describes an example implementation of a Digital Wallet (i.e., a first user primary wallet) inside a computing device, which can be a laptop or a mobile phone or a tablet or a personal computer (PC) (i.e., a first user device) or a Server; Trusted Component is a secure and trusted component of the Digital Wallet that can securely send and receive money, validate and communicate with Issuing Trusts and other Digital Wallets, securely store and manage digital coins (i.e., virtual currency), private keys of Digital Coins, Digital Wallets, and/or other secure elements of a coin and its transaction; a Digital Wallet may have a Public Key and a Private Key cryptographic key pair (i.e., a first user wallet private key); the Payer wants to send 100 units of Digital Coin to the Payee. The Digital Wallet builds a Digital Coin of 100 units by working with its Issuing Trust via a Network. The Digital Coin can comprise one coin worth of 100 units or multiple coins (i.e., two or more of a plurality of first user secondary wallets) of total value 100 units (i.e., certain amount of the transaction); the Digital Wallet securely store and manage digital coins, private keys of Digital Coins (i.e., first user secondary wallets), Digital Wallets, and/or other secure elements of a coin and its transaction; Digital Coins having their private keys also can be interpreted as wallets); determining, based on the transaction request, to transfer the certain amount of the virtual currency to a second wallet of a second account of the two accounts via the two or more of the secondary wallets, wherein each of the two or more of the secondary wallets are each associated with different predefined amounts of the virtual currency (Ramanathan: Col. 5, lines 16-33; Col. 6, lines 25-39 teach(es) a Payer who has his coins managed in a Digital Wallet, and a Payee who has her coins managed in a Digital Wallet (i.e., a second user wallet); the Payer wants (i.e., a transaction request) to send 100 units of Digital Coin to the Payee (i.e., a second user wallet); The Digital Coin can comprise one coin worth of 100 units or multiple coins (i.e., via the two or more of the plurality of first user secondary wallets) of total value 100 units; The Digital Coin can comprise one coin worth of 100 units or multiple coins (i.e., a first subset and a second subset of first user secondary wallet private keys) of total value 100 units; Since the only difference of the first subset and the second subset is the different predefined amounts, the multiple coins, the total value of the multiple coins must be 100 units, can be interpreted to include the first subset and the second subset); [identifying], in response to said determining to transfer the certain amount to the second wallet, a subset of secondary wallet private keys that are associated with the two or more of the secondary wallets (Ramanathan: Col. 5, lines 16-33 teach(es) a Payer who has his coins managed in a Digital Wallet, and a Payee who has her coins managed in a Digital Wallet (i.e., a second user wallet); the Payer wants (i.e., a transaction request) to send 100 units (i.e., payment amount) of Digital Coin to the Payee (i.e., a second user wallet); The Digital Coin can comprise one coin worth of 100 units or multiple coins (i.e., combining the first subset and the second subset for the payment amount)); and causing to be transmitted, to the second wallet, the subset of the secondary wallet private keys (Ramanathan: Col. 5, lines 16-33; Col. 11, lines 11-18 teach(es) Digital Wallet (Payer) sends (i.e., transmitting) the Digital Coin (e.g., multiple coins; i.e., the first subset and the second subset of the first user secondary wallet private keys) to the Digital Wallet (Payee; i.e., second user wallet) securely via the Network).
However, Ramanathan does not explicitly teach identifying, in response to said determining to transfer the certain amount to the second wallet, a subset of secondary wallet private keys that are associated with the two or more of the secondary wallets.
Questembert from same or similar field of endeavor teaches identifying, in response to said determining to transfer the certain amount to the second wallet, a subset of secondary wallet private keys that are associated with the two or more of the secondary wallets (Questembert: Paragraph(s) 0510, 0792, 0799, 0507-0508 teach(es) When using that method (i.e. the “drag-copy” mechanism) on a digital cash bundle, the digital cash electronic wallet may prompt the user for the desired denomination for the target digital cash bundle, create the digital cash bundle with the specified denomination (i.e., a first subset and a second subset of the first user secondary wallet private keys, correspond to one of the different predefined amounts) accordingly; When the user drops a cash bundle (i.e., the plurality of first user secondary wallets) with the required value, the ActiveX sends to the Vendor web server the bundle content along with information identifying the item; Another extension is to use not just one bundle file, but a number of smaller cash bundle files (i.e., the two or more of the plurality of first user secondary wallets) until the total amount has been provided by the aggregate value of the digital cash bundles (i.e., determining a first subset and a second subset). The ActiveX control may update its display to indicate the remaining amount for the payment, and wait till the total value meets the required purchase price and the User confirms the purchase).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Ramanathan to incorporate the teachings of Questembert for identifying, in response to said determining to transfer the certain amount to the second wallet, a subset of secondary wallet private keys that are associated with the two or more of the secondary wallets.
There is motivation to combine Questembert into Ramanathan because a transaction can be facilitated by using digital cash payment, which is distributed as a digital cash bundle file or an aggregate value of the digital cash bundles with desired denominations (Questembert: Paragraph(s) 0144-0145, 0799, 0268, 0510).
Regarding Claims 11 and 18, Ramanathan teaches A virtual currency transaction system, comprising: a non-transitory memory storing instructions; and one or more hardware processors coupled to the non-transitory memory and configured to execute the instructions to cause the system to (Ramanathan: Abstract; Col. 25, line 65 ~ Col. 26, line 7): A non-transitory machine-readable medium having stored thereon machine- readable instructions executable to cause a machine to perform operations comprising (Ramanathan: Col. 25, line 65 ~ Col. 26, line 7):
access, based on a transaction between two accounts for a certain amount, a first wallet of a first account of the two accounts and associated with virtual currency, wherein the first wallet includes a first wallet private key (Ramanathan: Col. 5, lines 16-23; Col. 5, line 56 ~ Col. 6, line 10; Col. 6 , lines 25-39 teach(es) FIG. 1 shows a Payer (i.e., a user) who has his coins managed in a Digital Wallet (i.e., a first user primary wallet that is associated with a first user account), and a Payee who has her coins managed in a Digital Wallet; the Payer wants (i.e., a transaction request) to send 100 units of Digital Coin to the Payee; FIG. 2 describes an example implementation of a Digital Wallet (i.e., a first user primary wallet) inside a computing device, which can be a laptop or a mobile phone or a tablet or a personal computer (PC) (i.e., a first user device) or a Server; Trusted Component is a secure and trusted component of the Digital Wallet that can securely send and receive money, validate and communicate with Issuing Trusts and other Digital Wallets, securely store and manage digital coins (i.e., virtual currency), private keys of Digital Coins, Digital Wallets, and/or other secure elements of a coin and its transaction; a Digital Wallet may have a Public Key and a Private Key cryptographic key pair (i.e., a first user wallet private key)); determine, based on the transaction, to transfer the certain amount of the virtual currency to a second wallet of a second account of the two accounts via two or more secondary wallets, wherein each of the two or more of the secondary wallets are each associated with different predefined amounts of the virtual currency, wherein the two or more secondary wallets each include a respective secondary wallet private key of secondary wallet private keys (Ramanathan: Col. 5, lines 16-33; Col. 9, lines 4-12; Col. 17, lines 31-52; Col. 32, lines 13-24 & 41-43 teach(es) a Payer who has his coins managed in a Digital Wallet, and a Payee who has her coins managed in a Digital Wallet (i.e., a second user wallet); the Payer wants (i.e., a transaction request) to send 100 units of Digital Coin to the Payee (i.e., a second user wallet); The Digital Coin can comprise one coin worth of 100 units or multiple coins (i.e., via the two or more of the plurality of first user secondary wallets) of total value 100 units; the Payer wants to send 100 units of Digital Coin to the Payee. The Digital Wallet builds a Digital Coin of 100 units by working with its Issuing Trust via a Network. The Digital Coin can comprise one coin worth of 100 units or multiple coins (i.e., two or more of a plurality of first user secondary wallets) of total value 100 units (i.e., transaction parameters of a transaction request); the Digital Wallet securely store and manage digital coins, private keys of Digital Coins (i.e., first user secondary wallets), Digital Wallets, and/or other secure elements of a coin and its transaction; Digital Coins having their private keys also can be interpreted as wallets; A new coin of same value can be generated from the old coin, and also multiple coins (i.e., the two or more of the plurality of first user secondary wallets) can be generated, whose resultant value is same as the old coin, in which the multiple coins may have different predefined amounts of the value, as long as their resulting sum value is same as the old coin; a Digital Wallet (i.e., first user secondary wallets) may have a Public Key and a Private Key (i.e., first user secondary wallet private keys) cryptographic key pair. The Private Key is securely managed by the Trusted Component whereas the Public Key may be publically available in a public ledger or with a Certificate Authority for public use; a Payer has his coins managed in a Digital Wallet; The Digital Coin can comprise one coin worth of 100 units or multiple coins of total value 100 units; Therefore, each of multiple wallets having different predefined amount of value has a private key, and thus each of the first user secondary wallet private keys corresponds to a respective one of the different predefined amounts); and transmit, to the second wallet, a [subset] of the secondary wallet private keys that are associated with the two or more of the secondary wallets (Ramanathan: Col. 5, lines 16-33; Col. 11, lines 11-18 teach(es) Digital Wallet (Payer) sends (i.e., transmitting) the Digital Coin (e.g., multiple coins; i.e., the first subset and the second subset of the first user secondary wallet private keys) to the Digital Wallet (Payee; i.e., second user wallet) securely via the Network).
However, Ramanathan does not explicitly teach a subset of the secondary wallet private keys.
Questembert from same or similar field of endeavor teaches transmit, to the second wallet, a subset of the secondary wallet private keys that are associated with the two or more of the secondary wallets (Questembert: Paragraph(s) 0510, 0792, 0799, 0507-0508 teach(es) When using that method (i.e. the “drag-copy” mechanism) on a digital cash bundle, the digital cash electronic wallet may prompt the user for the desired denomination for the target digital cash bundle, create the digital cash bundle with the specified denomination (i.e., a first subset and a second subset of the first user secondary wallet private keys, correspond to one of the different predefined amounts) accordingly; When the user drops a cash bundle (i.e., the plurality of first user secondary wallets) with the required value, the ActiveX sends to the Vendor web server the bundle content along with information identifying the item; Another extension is to use not just one bundle file, but a number of smaller cash bundle files (i.e., the two or more of the plurality of first user secondary wallets) until the total amount has been provided by the aggregate value of the digital cash bundles (i.e., identifying a first subset and a second subset). The ActiveX control may update its display to indicate the remaining amount for the payment, and wait till the total value meets the required purchase price and the User confirms the purchase).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Ramanathan to incorporate the teachings of Questembert for a subset of the secondary wallet private keys.
There is motivation to combine Questembert into Ramanathan because a transaction can be facilitated by using digital cash payment, which is distributed as a digital cash bundle file or an aggregate value of the digital cash bundles with desired denominations (Questembert: Paragraph(s) 0144-0145, 0799, 0268, 0510).
Regarding Claims 3, 13, and 20, the combination of Ramanathan and Questembert teaches all the limitations of claims 2, 11, and 18 above; and Ramanathan further teaches wherein said accessing the first wallet comprises identifying the first wallet that is associated with a first user of a first user device, wherein the first wallet is further associated with a virtual currency (Ramanathan: Col. 5, line 56 ~ Col. 6, line 10; Col. 6 , lines 25-39 teach(es) FIG. 2 describes an example implementation of a Digital Wallet (i.e., a first user primary wallet) inside a computing device, which can be a laptop or a mobile phone or a tablet or a personal computer (PC) (i.e., a first user device) or a Server; Trusted Component is a secure and trusted component of the Digital Wallet that can securely send and receive money, validate and communicate with Issuing Trusts and other Digital Wallets, securely store and manage digital coins (i.e., virtual currency), private keys of Digital Coins, Digital Wallets, and/or other secure elements of a coin and its transaction; a Digital Wallet may have a Public Key and a Private Key cryptographic key pair (i.e., a first user wallet private key)).
Regarding Claims 4 and 15, the combination of Ramanathan and Questembert teaches all the limitations of claims 2 and 11 above; and Ramanathan further teaches wherein said determining to transfer the certain amount of the virtual currency to the second wallet of the second account via the two or more of the secondary wallets comprises selecting, based on the certain amount of the transaction, a combination of two or more of a plurality of first user secondary wallets that are associated with the first user (Ramanathan: Col. 5, lines 22-33; Col. 6, lines 25-39; Col. 9, lines 4-12 teach(es) the Payer wants to send 100 units of Digital Coin to the Payee. The Digital Wallet builds a Digital Coin of 100 units by working with its Issuing Trust via a Network. The Digital Coin can comprise one coin worth of 100 units or multiple coins (i.e., two or more of a plurality of first user secondary wallets) of total value 100 units (i.e., certain amount of the transaction); the Digital Wallet securely store and manage digital coins, private keys of Digital Coins (i.e., first user secondary wallets), Digital Wallets, and/or other secure elements of a coin and its transaction; Digital Coins having their private keys also can be interpreted as wallets).
Regarding Claim 5, the combination of Ramanathan and Questembert teaches all the limitations of claim 2 above; and Ramanathan further teaches wherein said determining to transfer the certain amount of the virtual currency to the second wallet of the second account via the two or more of the secondary wallets comprises associating the two or more of the secondary wallets with the different predefined amounts of the virtual currency (Ramanathan: Col. 17, lines 31-52; Col. 6 , lines 25-39; Col. 5, lines 22-33 teach(es) A new coin of same value can be generated from the old coin, and also multiple coins (i.e., the two or more of the plurality of first user secondary wallets) can be generated, whose resultant value is same as the old coin, in which the multiple coins may have different predefined amounts of the value, as long as their resulting sum value is same as the old coin; a Digital Wallet (i.e., first user secondary wallets) may have a Public Key and a Private Key (i.e., first user secondary wallet private keys) cryptographic key pair. The Private Key is securely managed by the Trusted Component whereas the Public Key may be publically available in a public ledger or with a Certificate Authority for public use; a Payer has his coins managed in a Digital Wallet; The Digital Coin can comprise one coin worth of 100 units or multiple coins of total value 100 units; Therefore, each of multiple wallets having different predefined amount of value has a private key, and thus each of the first user secondary wallet private keys corresponds to a respective one of the different predefined amounts).
Regarding Claims 7 and 14, the combination of Ramanathan and Questembert teaches all the limitations of claims 2 and 11 above; and Ramanathan further teaches wherein said causing the subset of the secondary wallet private keys to be transmitted to the second wallet comprises causing the subset of the secondary wallet private keys to be transferred to the second wallet stored on a server that hosts the first wallet (Ramanathan: Col. 5, lines 16-33 & 56-65; Col. 11, lines 11-18 teach(es) Digital Wallet (Payer) sends the Digital Coin (e.g., multiple coins; i.e., the first subset and the second subset of the first user secondary wallet private keys) to the Digital Wallet (Payee; i.e., second user wallet) securely via the Network; FIG. 2 describes an example implementation of a Digital Wallet inside a computing device (i.e., stored on a server), including a laptop or a mobile phone or a tablet or a personal computer (PC) or a Server (i.e., a server that hosts the first user primary wallet)).
Regarding Claim 8, the combination of Ramanathan and Questembert teaches all the limitations of claim 2 above; and Ramanathan further teaches wherein said causing the subset of the secondary wallet private keys to be transmitted to the second wallet comprises causing the subset of the secondary wallet private keys to be transferred to the second wallet that is stored on a second user device associated with a second user who associated with the second account (Ramanathan: Col. 5, lines 16-33 & 56-65; Col. 11, lines 11-18 teach(es) Digital Wallet (Payer) sends the Digital Coin (e.g., multiple coins; i.e., the first subset and the second subset of the first user secondary wallet private keys) to the Digital Wallet (Payee; i.e., second user wallet) securely via the Network; FIG. 2 describes an example implementation of a Digital Wallet inside a computing device (i.e., stored on a second user device), including a laptop or a mobile phone or a tablet or a personal computer (PC) (i.e., a second user device associated with the second user) or a Server).
Regarding Claim 9, the combination of Ramanathan and Questembert teaches all the limitations of claim 2 above; and Ramanathan further teaches further comprising: determining that the virtual currency has been associated with the first wallet, and in response, automatically performing respective virtual currency transactions associated with the first account to transfer the association of predefined amounts of the virtual currency from the first wallet to each of the secondary wallets (Ramanathan: Col. 17, lines 25-45 teach(es) operators ‘Generate’ can create a new coin of same value from an old coin, and operators ‘Split’ can split a Coin into multiple Coins (i.e., the association of each of the different predefined amounts of the virtual currency, as interpreted in claim 2), automatically).
Regarding Claims 10 and 17, the combination of Ramanathan and Questembert teaches all the limitations of claims 2 and 11 above; and Ramanathan further teaches further comprising: determining, in response to determining to transfer the certain amount to the second wallet, an exchange rate between the virtual currency and a physical currency, wherein the subset of the secondary wallet private keys is selected based on the exchange rate (Ramanathan: Col. 23, line 58 ~ Col. 24, line 2; Col. 5, lines 16-33 & 56-65 teach(es) when Issuing Trust generates a new Digital Coin 303 form the Digital Coin 300 it will be in Indian Rupee units of equivalent value as determined by the exchange rates (i.e., determining an exchange rate between the virtual currency and a physical currency) at that time; Digital Wallet directly creates a new Coin or multiple coins (i.e., first subset and the second subset) in Indian Rupee of equivalent value (i.e., based on the exchange rate) and sends that new Coin to Digital Wallet).
Regarding Claims 16 and 21, the combination of Ramanathan and Questembert teaches all the limitations of claims 11 and 18 above; and Ramanathan further teaches wherein said causing the subset of the secondary wallet private keys to be transmitted to the second wallet comprises causing the subset of the secondary wallet private keys to be transferred to the second wallet stored on a server that hosts the first wallet or on a second user device associated with a second user who associated with the second account (Ramanathan: Col. 5, lines 16-33 & 56-65; Col. 11, lines 11-18 teach(es) Digital Wallet (Payer) sends the Digital Coin (e.g., multiple coins; i.e., the first subset and the second subset of the first user secondary wallet private keys) to the Digital Wallet (Payee; i.e., second user wallet) securely via the Network; FIG. 2 describes an example implementation of a Digital Wallet inside a computing device (i.e., stored on a server), including a laptop or a mobile phone or a tablet or a personal computer (PC) or a Server (i.e., a server that hosts the first user primary wallet)).
Claim(s) 6, 12, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ramanathan in view of Questembert, as applied to claims 2, 11, and 18 above, and in further view of Scherzer (WO 2014040717 A1; already of record in IDS).
Regarding Claim 6, the combination of Ramanathan and Questembert teaches all the limitations of claim 2 above; however the combination does not explicitly teach wherein the secondary wallets are implemented as shadow wallets that are inaccessible to a user associated with the first account.
Scherzer from same or similar field of endeavor teaches wherein the secondary wallets are implemented as shadow wallets that are inaccessible to a user associated with the first account (Scherzer: Page 2, lines 5-15 teach(es) Amount of money recorded on a shadow account (i.e., implemented as shadow secondary wallets) in the background system (i.e., inaccessible to the first user) of the purse).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Ramanathan and Questembert to incorporate the teachings of Scherzer for wherein the plurality of the first user secondary wallets are implemented as shadow secondary wallets that are inaccessible to the first user.
There is motivation to combine Scherzer into the combination of Ramanathan and Questembert because it can be avoided to duplicate the money or virtual currency in the course of the direct transfer from one purse or wallet to another, by using a shadow account or wallet (Scherzer: Page 2, lines 9-15).
Regarding Claims 12 and 19, the combination of Ramanathan and Questembert teaches all the limitations of claims 11 and 18 above; and Ramanathan further teaches wherein executing the instructions further causes the system to: create the secondary wallets using a certain distribution of an amount of virtual currency of the first wallet, (Ramanathan: Col. 17, lines 32-52; Col. 5, lines 16-33; Col. 6, lines 25-39 teach(es) ‘Generate’ can create multiple coins (i.e., the plurality of the first user secondary wallets) whose resultant value is same as the old coin (i.e., using a certain distribution of the amount of the virtual currency of the first user primary wallet); Digital Coins having their private keys also can be interpreted as wallets).
However, the combination of Ramanathan and Questembert does not explicitly teach wherein the secondary wallets are implemented as respective shadow secondary wallets that are inaccessible to a first user associated with the first account.
Scherzer from same or similar field of endeavor teaches wherein the secondary wallets are implemented as respective shadow secondary wallets that are inaccessible to a first user associated with the first account (Scherzer: Page 2, lines 5-15 teach(es) Amount of money recorded on a shadow account (i.e., implemented as shadow secondary wallets) in the background system (i.e., inaccessible to the first user) of the purse).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of the combination of Ramanathan and Questembert to incorporate the teachings of Scherzer for wherein the secondary wallets are implemented as respective shadow secondary wallets that are inaccessible to a first user associated with the first account.
There is motivation to combine Scherzer into the combination of Ramanathan and Questembert because it can be avoided to duplicate the money or virtual currency in the course of the direct transfer from one purse or wallet to another, by using a shadow account or wallet (Scherzer: Page 2, lines 9-15).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
DeCastro (US 20150170112 A1): Systems and methods for providing multi-currency platforms comprising means for exchanging and interconverting tangible and virtual currencies in various transactions, banking operations, and wealth management scenarios.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CLAY LEE whose telephone number is (571)272-3309. The examiner can normally be reached Monday-Friday 8-5pm EST.
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.
/CLAY C LEE/Primary Examiner, Art Unit 3699