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 .
Status of the Claims
This is a FINAL Office Action rejection prepared in response to Applicant’s amendments filed on
12/06/2025.
Claims 1-10, 13-17, 21-24 and 28-31 are cancelled.
Claims 11, 20, 27, 32, 35, 39 and 41 are amended.
Claims 42-43 were added.
Claims 11-12, 18-20, 25-27 and 32-43 are pending.
Claim Objections
Claim 27 is objected to because of the following informalities:
Regarding claim 27, recites the limitation “the instructions further cause…” in line 8 and the limitation “parsing a request to determine a type of…” in line 19. There is insufficient antecedent basis for these limitations in the claim.
Appropriate correction is required.
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 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 claims 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.
Claims 27 and 42-43 are rejected for reciting “specifically creating a plurality of cryptocurrency wallets including the cryptocurrency wallet associated with the request for at least one of: specific key requests, specific messages of the key requests, and specific requesting devices of the key requests” which introduce new matter not originally disclosed on the specification. The originally filed specifications and drawings do not contain any description, suggestion or mention of creating multiple wallets simultaneously. Therefore, because the original specifications fail to reasonably convey to a person of ordinary skills in the art that the applicant had possession of the claimed concept, the limitation constitutes new matter under 35 U.S.C. 112(a). The applicant is advised to delete or amend the unsupported limitation.
Claims 27 and 42-43 recite the limitation “managing the specifically created plurality of cryptocurrency wallets sufficiently to maintain an anonymity of the requesting user during performance of the requested cryptographic key service;”. The specification does not provide sufficient detail regarding how the plurality of cryptocurrency wallets are managed to maintain anonymity. Although the
general subject of managing cryptocurrency wallets is discussed in the specifications, it lacks sufficient description on the process or algorithm by which the plurality cryptocurrency wallets are managed in a manner that maintains anonymity of the requesting user as claimed. The applicant is advised to delete or amend the limitation.
Claims 32 and 39-41 are also rejected as they depend from claim 27.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 27, 32 and 39-43 are 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.
The term “sufficiently” in claims 27, 42 and 43 is a relative term which renders the claim indefinite. The term “sufficiently” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
Claims 27, 42 and 43, recite the limitation “wherein identifying the cryptocurrency wallet associated with the request based on the identifier of the electronic message indicated in the request the instructions further cause the processor to: specifically creating a plurality of cryptocurrency wallets including the cryptocurrency wallet associated with the request for at least one of: specific key requests, specific messages of the key requests, and specific requesting devices of the key requests; managing the specifically created plurality of cryptocurrency wallets sufficiently to maintain an anonymity of the requesting user during performance of the requested cryptographic key service; and encrypting or decrypting the electronic message without revealing an identity of the requesting user;”. This limitation is ambiguous because there is no direct link between the instructions and the request, making it unclear as to what the instructions are modifying. One in the ordinary skill in the art would not be able to reasonably determine the metes and bounds of the claim.
Claim 27, recites the limitations “encrypting or decrypting the electronic message without revealing an identity of the requesting user.” and “performing the cryptographic key service requested”. These limitations are indefinite. It is unclear whether these steps are two different steps or the step of “encrypting or decrypting…” is included within the “performing the cryptographic key service” step. As drafted the claim appears to recite the same operation twice. Therefore, one in the ordinary skill in the art will not be able to determine with certainty whether the claim requires multiple steps of encryption/decryption or if only one encryption/decryption operation satisfies both steps.
Claims 32 and 39-41 are also rejected as they depend from claim 27.
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 11-12, 18-20, 25-27 and 32-43 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 11-12, 18-19, 33-35 and 42-43 are directed to an apparatus. Claims 20, 25-26 and 36-38 are directed to a non-transitory computer-readable storage medium (i.e., manufacture). Claims 27, 32 and 39-41 are directed to a method (i.e., process). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One: Claim 27, recites (i.e., sets forth or describes) an abstract idea. More specifically, the following bolded claim elements recite abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
A method comprising:
receiving, using an interface circuit, a request for a cryptographic key service from a device associated with a requesting user, wherein the cryptographic key service requested comprises encryption of an electronic message;
identifying a cryptocurrency wallet associated with the request based on an anonymous identifier of the electronic message indicated in the request, wherein identifying the cryptocurrency wallet associated with the request based on the identifier of the electronic message indicated in the request the instructions further cause the processor to: specifically creating a plurality of cryptocurrency wallets including the cryptocurrency wallet associated with the request for at least one of: specific key requests, specific messages of the key requests, and specific requesting devices of the key requests; managing the specifically created plurality of cryptocurrency wallets sufficiently to maintain an anonymity of the requesting user during performance of the requested cryptographic key service; and encrypting or decrypting the electronic message without revealing an identity of the requesting user;
parsing the request to determine a type of cryptographic key service requested and the cryptocurrency wallet associated with the request;
determining a status of the cryptocurrency wallet associated with the request, wherein the status of the cryptocurrency wallet is active during a designated time period or inactive outside the designated time period; and if the status of the cryptocurrency wallet is active, then:
performing the cryptographic key service requested; and
causing an electronic ledger associated with the cryptographic key service to be updated.
Claim 27, recites (i.e., sets forth or describes) a method for determining whether a requestor has an active account, and if the requestor does perform a requested service. The claim achieves this by:
receiving a request for a cryptographic key service
parsing the request to determine the type of cryptographic key service being requested and the wallet
identifying a wallet associated with the request
determine a status of the wallet
performing the cryptographic key service requested if the wallet is active
updating a ledger.
Claim 11 and 20 are significantly similar to claim 27. However claim 11 and claim 20 do not recite the additional steps of creating a plurality of wallets and managing those wallets. The omission of these additional limitations do not change the fact that claims 11 and 20 recite an abstract idea. As such claims 11 and 20 also recite an abstract idea. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas (i.e., fundamental economic practices and commercial or legal interactions).
Step 2A Prong Two: Because the claim recites abstract ideas, the analysis proceeds to
determine whether the claim recites additional elements that recite a practical application of the
abstract ideas. According to MPEP 2106.04(d), additional elements that recite an instruction to apply
the abstract ideas using a computer, that recite insignificant extra-solution activities, or that generally
link the use of the abstract ideas to a particular technological environment or field of use are not
indicative of a practical application. Here, the additional elements of an interface circuit, a device and a cryptocurrency wallet merely serve as tools to perform the abstract idea (MPEP § 2106.05(f)). Further, the additional element “electronic” generally links the use of the judicial exception to a particular technological environment, that being of cryptocurrencies (MPEP § 2106.05(h)). Therefore, the claim as a whole fail to recite a practical application of the abstract ideas.
Step 2B: Determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims: Claims 12, 18-19, 25-26 and 32-43 have also been analyzed for subject matter eligibility. However, 12, 18-19, 25-26 and 32-43 also fail to recite patent eligible subject matter for the following reasons:
Claim 12 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the cryptographic key service requested comprises at least one of: encryption, decryption, electronic signature and electronic verification.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of “electronic” generally links the use of the judicial exception to a particular technological environment, that being of cryptocurrencies (MPEP § 2106.05(h)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 18 and 25 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
determine that the cryptographic key service requested is encryption of an electronic message; and identify the cryptocurrency wallet for the request based on an identifier of the electronic message indicated in the request.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a cryptocurrency wallet fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element “crypto” and “electronic” generally links the use of the judicial exception to a particular technological environment, that being of cryptocurrencies (MPEP § 2106.05(h)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 19 and 26 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the cryptocurrency wallet is identified in a database based on the identifier of the electronic message.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a cryptocurrency wallet fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claim 32 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
determining the cryptographic key service requested is encryption of an electronic message
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of “electronic” generally links the use of the judicial exception to a particular technological environment, that being of cryptocurrencies (MPEP § 2106.05(h)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 33 and 36 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the cryptographic key service requested comprises a request to encrypt an electronic message, and wherein performing the cryptographic key service requested comprises transferring an encrypted message to a recipient.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of “electronic” generally links the use of the judicial exception to a particular technological environment, that being of cryptocurrencies (MPEP § 2106.05(h)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 34, 37 and 40 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the cryptographic key service requested comprises a request to decrypt the encrypted message, and wherein performing the cryptographic key service requested comprises transferring a decrypted message to a recipient.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas.
Claims 35, 38 and 41 recite the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
instructions further cause the processor to: if the status of the cryptocurrency wallet is inactive, then send a request to renew authorization for the cryptocurrency wallet to the device.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a cryptocurrency wallet and a processor fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claim 39 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
performing the cryptographic key service requested comprises transferring an encrypted message to a recipient.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas.
Claim 42 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
identify the cryptocurrency wallet associated with the request in an absence of the requesting user being identified, the instructions further cause the processor to:
specifically create a plurality of cryptocurrency wallets including the cryptocurrency wallet associated with the request for at least one of: specific key requests, specific messages of the key requests, and specific requesting devices of the key requests; and
manage the specifically created plurality of cryptocurrency wallets sufficiently to maintain an anonymity of the requesting user during performance of the requested cryptographic key service.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a cryptocurrency wallet and a processor fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claim 43 recites the following bolded claim elements as abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
identify the cryptocurrency wallet associated with the request based on the identifier of the electronic message indicated in the request the instructions further cause the processor to:
specifically create a plurality of cryptocurrency wallets including the cryptocurrency wallet associated with the request for at least one of: specific key requests, specific messages of the key requests, and specific requesting devices of the key requests;
manage the specifically created plurality of cryptocurrency wallets sufficiently to maintain an anonymity of the requesting user during performance of the requested cryptographic key service; and
encrypt or decrypt the electronic message without revealing an identity of the requesting user.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of a cryptocurrency wallet and a processor fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional element “crypto” and “electronic” generally links the use of the judicial exception to a particular technological environment, that being of cryptocurrencies (MPEP § 2106.05(h)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 11-12, 18-20, 25-26, 35 and 38 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Fountain (US 2006/0149962 A1) in view of Alness (US 2016/0344543 A1), further view of Lee (US 20140046788 A1).
Regarding claims 11 and 20, Fountain discloses:
receive, using the interface circuit, a request for a cryptographic key service from a device associated with a requesting user; (Fountain ¶0019, The application server 14 provides requested services to the clients 12 via the computer network 18. Services requested by the clients 12 may specifically involve cryptographic services, or may precipitate the need for cryptographic services. For example, the client requested services may require the storage of sensitive data on the network database 20, or the retrieval of encrypted data from the network database 20. The cryptographic key server 16 is available to the application server 14 to perform cryptographic services, thus offloading the computational intensities of cryptographic services from the application server 14. Fountain ¶0056, Accordingly, in a step 206 the key server receives a request for cryptographic services via the secure channel. See claim 2.)
parsing the request to determine a type of cryptographic key service requested (Fountain ¶0056, In receiving the cryptographic service request, the key server will unmarshal the request from encrypted network format. As described above with reference to FIG. 2, in certain embodiments this may be performed by a secure network interface engine. In a step 208, the key server will perform an authorization analysis of the cryptographic service request. The authorization analysis of step 208 determines whether the requested services should be provided to the requesting client. Fountain ¶0057, When step 208 determines that the request may be performed, process control flows from step 208 to a step 210 that performs the requested cryptographic services. For example, the application server may be requesting that certain data be encrypted or decrypted.)
and cause an electronic ledger associated with the cryptographic key service to be updated. (¶0003, SSL and TLS protect data while in transit by encrypting the data using a session-key, (i.e., a cryptographic key), known only to the web server and the client computer. According to these protocols, the data is decrypted upon arrival at the receiving web server. The receiving server processes the data (e.g., validating the credit card number) and then often stores the sensitive data in a server database. ¶0019, For example, the client requested services may require the storage of sensitive data on the network database 20, or the retrieval of encrypted data from the network database 20. ¶0057, When step 208 determines that the request may be performed, process control flows from step 208 to a step 210 that performs the requested cryptographic services. For example, the application server may be requesting that certain data be encrypted or decrypted. In a step 212, the cryptographic key server will respond to the application server via the secure channel. This includes marshalling the data into secure format for transmission across the network. In a next step 214, a variety of housekeeping functions related to satisfaction of an authorized request are performed. In certain embodiments, these include maintaining a database related to cryptographic requests (time, client identity, service requested, satisfactory completion, etc.) ¶0058, When step 208 determines that the request may not be performed for failure of the authorization step 208, a step 216 performs housekeeping functions related to a failed request for services. In certain embodiments, this includes include maintaining a database related to cryptographic requests (time, client identity, service requested, etc.). This database can be used to evaluate whether an attack is being made, or to determine errors in the system.)
Fountain further discloses:
an interface circuit operably coupled to the processor (¶0051, The hardware architecture 100 includes a central processing unit (CPU) 104, a persistent storage device 106 such as a hard disk, a transient storage device 108 such as random access memory (RAM), a network I/O device 110, an encryption device 112 such as a cryptographic accelerator card, a hardware security module (HSM) 114, and a smart card interface 116, all bi-directionally coupled via a databus 102.)
Processor and a non-transitory computer-readable data storage medium storing instructions (Fountain ¶0069, Aspects of the invention can be embodied in a special purpose computer or data processor that is specifically programmed, configured or constructed to perform one or more of the computer-executable instructions explained in detail below. Indeed, the term "computer," as used generally herein, refers to any of the above devices, as well as any data processor. Further, the term "processor" as generally used herein refers to any logic processing unit, such as one or more central processing units (CPUs), digital signal processors (DSPs), application-specific integrated circuits (ASIC), etc. Fountain ¶0072, While certain aspects of the invention are presented below in certain claim forms, the inventors contemplate the various aspects of the invention in any number of claim forms. For example, while only one aspect of the invention is recited as embodied in a computer-readable medium, other aspects may likewise be embodied in a computer-readable medium.)
Fountain does not disclose, however Alness teaches:
identify a cryptocurrency wallet associated with the request in an absence of the requesting user being identified; (¶0005, Transactions do not explicitly identify the payor and payee by name or wallet. Instead, a bitcoin transaction transfers ownership to a new address, referred to as a “Bitcoin address”. The Bitcoin address is derived from the public portion of one or more cryptographic key pairs. The private portion of a key pair is not disclosed to the public. To send bitcoin sent to an address, a user broadcasts a payment message that is digitally signed with the associated private key. ¶0015, receive a request for payment to a bitcoin address, the request for payment including an amount of bitcoin to be paid, generate an unsigned transaction in response to receiving the request for payment, the unsigned transaction including the amount of bitcoin to be paid in the request for payment, requesting a signing of the unsigned transaction to create a signed transaction and a payment module configured to receive the request for signing the transaction, determine the address corresponding to the bitcoin address in the unsigned transaction, determine the private key stored in association with the address, ¶0052, At 114, the payment module 60 looks up the respective private key. The payment module 60 compares the address “B” in the transaction with the addresses in the database 52. When a match is found, the payment module 60 extracts the respective encrypted private key from the address “B” found in the database 52. The payment module 60 then decrypts the private key with the operational master key 64.)
the cryptocurrency wallet associated with the request; (Alness ¶0020, receiving, by the service, the request for signing the transaction, determining, by the service, the address corresponding to the bitcoin address in the unsigned transaction, determining, by the service, the encrypted private key stored in association with the address… ¶0050, FIG. 7 illustrates a payment process that is initiated by a wallet 108, for example on a mobile device or on a personal computer. It is assumed that the address “B” has 10 bitcoin (BTC) stored therein. When a user selects a “Send” button, the user, at 111, sends a request from the wallet 108 to the web application 48 to send 1 BTC to A. When the web application 48 receives the request transmitted at 111, the web application 48, at 112, generates an unsigned transaction (Tx). The transaction includes an “In” designating address “B”. The transaction includes a “OUT” reference of 1 BTC to address “A” and 8 BTC to address “B”. A further 1 BTC (not shown) represents a miner's fee.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify Fountain’s invention with Alness’s teaching. One of ordinary skills in the art would have been motivated to combine these elements that the system is able to extract the wallet identifier from the request message and identify the corresponding wallet to properly apply payments for the services requested.
The combination does not disclose, however Lee teaches:
determining a status of the cryptocurrency wallet associated with the request, wherein the status of the cryptocurrency wallet is active during a designated time period or inactive outside the designated time period; and (Lee ¶0123, The account verification unit 335 can verify status and balance of each electronic wallet account of a user. Lee ¶0124, For example, the account verification unit 335 i) verifies the electronic wallet account corresponding to (linked to) terminal information of the user terminal 110 with a payment request of the user terminal 110, ii) determines if the electronic wallet account is available (for example, if the electronic wallet account is a dormant account or if a balance is enough to make a payment, and so forth.), and iii) notifies the result to the user terminal 110. Lee ¶0165, The payment support server 120 verifies the status of the electronic wallet account corresponding to the virtual account according to the virtual account deposit notification from the financial institution system 140 in Step 715. Lee ¶0167, Here, if the electronic wallet account is in a dormant condition due to long-term unused, the payment support server 120 can notify the status to the user terminal 110, perform activation of the dormant account and, if necessary, recharge it. Lee ¶0229, For example, the payment support server 120 determines the status and the balance of the user electronic wallet account and further determines if it is possible to process the payment amount according to the payment request. Lee ¶0230, The payment support server 120 also determines the status of the POS electronic wallet account and further determines if it is possible to reflect the deposit.)
if the status of the cryptocurrency wallet is active, then perform the cryptographic key service requested , Lee ¶0166, If it is not possible to use the electronic wallet account (e.g., insufficient funds in account), the payment support server 120 transmits an information message for unavailable electronic wallet account to the user terminal 110 in Step 720. Lee ¶0168, If the electronic wallet account is available and usable (e.g., sufficient funds in account), the payment support server 120 identifies the limit amount of the electronic wallet account in Step 725. Here, the limit amount is the maximum amount to be deposited to the electronic wallet account. Lee ¶0170, if charging amount is within the limit, the payment support server 120 adds and deposits the charged amount to the balance of the electronic wallet account in Step 735.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify Fountain and Alness’s teaching with Lee’s teaching. One of ordinary skills in the art would have been motivated to combine these elements to ensure that the access to the key services is contingent upon the wallet’s validation status.
Further, the claim limitation in claim 27 (method claim) “if the status of the cryptocurrency wallet is active, then perform the cryptographic key service requested” is a conditional limitation which means that the claim limitation is only required when the stated condition is met.
Regarding claim 12, Fountain, Alness and Lee disclose each and every element of claim 11. Fountain further discloses:
the cryptographic key service requested comprises at least one of: encryption, decryption, electronic signature and electronic verification. (Fountain ¶0030, The cryptographic service engine 70 is operable to provide cryptographic services requested by the application server 52 via the secure network interface engine 72. Cryptographic services may include: 1) hashing operations, and 2) signing and verification operations such as RSA and DSA. Fountain ¶0031, The cryptographic functions exposed to the applications 60 would include those most likely desired by the remote clients. These cryptographic functions must be performed either at the application server 52, or more preferably at the cryptographic key server 54 in order to offload from the application server 52 the burden of performing cryptographic services. Thus, it is preferred that the cryptographic service engine 70 be capable of performing any exposed cryptographic services not provided at the application server 52. Typical exposed functionality would include, but is not limited to, functions such as encryption and decryption (e.g. DES, 3DES, AES, RSA, DSA, ECC, etc.), signing and verification (e.g. RSA, DSA, etc.), and hashing and verification (e.g. SHA-1, HMAC, etc.). Generally, encryption and decryption functions include: [0032] symmetric block ciphers, [0033] generic cipher modes, [0034] stream cipher modes, [0035] public-key cryptography, [0036] padding schemes for public-key systems, [0037] key agreement schemes, [0038] elliptic curve cryptography, [0039] one-way hash functions, [0040] message authentication codes, [0041] cipher constructions based on hash functions, [0042] pseudo random number generators, [0043] password based key derivation functions, [0044] Shamir's secret sharing scheme and Rabin's information dispersal algorithm (IDA), [0045] DEFLATE (RFC 1951) compression/decompression with gzip (RFC 1952) and zlib (RFC 1950) format support, [0046] fast multi-precision integer (bignum) and polynomial operations, [0047] finite field arithmetic, including GF(p) and GF(2.sup.n), and [0048] prime number generation and verification.)
Furthermore, the claimed limitation “the cryptographic key service requested comprises at least one of: encryption, decryption, electronic signature and electronic verification” is non-functional material that does not move to distinguish over prior art as it does not affect the recited steps of in claim 11.
Regarding claims 18 and 25, Fountain, Alness and Lee disclose each and every element of claims 11 and 20. Fountain further discloses:
determining the cryptographic key service requested is encryption of an electronic message; and (Fountain ¶0057, When step 208 determines that the request may be performed, process control flows from step 208 to a step 210 that performs the requested cryptographic services. For example, the application server may be requesting that certain data be encrypted or decrypted. In a step 212, the cryptographic key server will respond to the application server via the secure channel. This includes marshalling the data into secure format for transmission across the network. In a next step 214, a variety of housekeeping functions related to satisfaction of an authorized request are performed. In certain embodiments, these include maintaining a database related to cryptographic requests (time, client identity, service requested, satisfactory completion, etc.)
Alness further teaches:
identifying the cryptocurrency wallet for the request based on an identifier of the electronic message indicated in the request. (Alness ¶0114, In some embodiments, the authorization module 808 may check a digital wallet identifier included in an authorization request message and authorize or decline a transaction based at least in part on the digital wallet identifier. The authorization module 808 may further extract a digital wallet identifier from an authorization request message and cause it to be stored in a database (such as the digital wallet database 820) or transmit it to a different module (such as the wallet identifier module 811).)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify Fountain, Alness and Lee’s teaching with Alness’ additional teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to provide a system that can automatically associate message requests with the appropriate wallet in the database, which is a common approach use for linking unique identifiers to specific resources.
Regarding claims 19 and 26, Fountain, Alness and Lee disclose each and every element of claims 18 and 25. Alness further teaches:
the cryptocurrency wallet is identified in a database based on the identifier of the electronic message. (Alness ¶0114, In some embodiments, the authorization module 808 may check a digital wallet identifier included in an authorization request message and authorize or decline a transaction based at least in part on the digital wallet identifier. The authorization module 808 may further extract a digital wallet identifier from an authorization request message and cause it to be stored in a database (such as the digital wallet database 820) or transmit it to a different module (such as the wallet identifier module 811).)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify Fountain, Alness and Lee’s teaching with Alness’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to provide a system that can automatically associate message requests with the appropriate wallet in the database, which is a common approach use for linking unique identifiers to specific resources.
Regarding claims 35 and 38, Fountain, Alness and Lee disclose each and every element of claims 11 and 20. Lee further teaches:
the instructions further cause the processor to: if the status of the cryptocurrency wallet is inactive perform the cryptographic key service requested, then send a request to renew authorization for the cryptocurrency wallet the device. (Lee ¶0167, Here, if the electronic wallet account is in a dormant condition due to long-term unused, the payment support server 120 can notify the status to the user terminal 110, perform activation of the dormant account and, if necessary, recharge it.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify Fountain, Alness and Lee’s teaching with Lee’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements to ensure that the access to the key services is contingent upon the wallet’s threshold balance and send notifications messages to the user if balance is below the threshold to ensure that the user provides the required amount to process the request in a timely manner.
Claims 33-34 and 36-37 are rejected under 35 U.S.C. 103 as being unpatentable over Fountain, Alness and Lee as applied to claims 11 and 20 above, and further in view of Chou (US 2009/0210708 A1).
Regarding claims 33 and 36, Fountain, Alness and Lee disclose each and every element of claims 11 and 20. Fountain further discloses:
the cryptographic key service requested comprises a request to encrypt an electronic message, and wherein (Fountain ¶0057, When step 208 determines that the request may be performed, process control flows from step 208 to a step 210 that performs the requested cryptographic services. For example, the application server may be requesting that certain data be encrypted or decrypted. In a step 212, the cryptographic key server will respond to the application server via the secure channel. This includes marshalling the data into secure format for transmission across the network. In a next step 214, a variety of housekeeping functions related to satisfaction of an authorized request are performed. In certain embodiments, these include maintaining a database related to cryptographic requests (time, client identity, service requested, satisfactory completion, etc.)
The combination does not disclose, however Chou teaches:
performing the cryptographic key service requested comprises transferring an encrypted message to a recipient. (Chou ¶0014, Another object of this invention is to provide methods to combine receiver authentication protocols with encryption key services, such that a transmitted electronic message can be encrypted to prevent unintended audiences from viewing the contents of the message. Chou ¶0018, Another advantage of this invention is that methods to combine receiver authentication protocols with encryption key services are provided such that a transmitted electronic message can be encrypted to prevent unintended audiences from viewing the contents of the message. Chou ¶0041, The sender email client 302 first sends a plain email to the sender's agent 304 to encrypt it. The sender's agent 304 encrypts the message and attaches a message ID to the encrypted email, then sends it back to the sender email client 302. The sender's agent 304 sends the message ID and the encryption key used to encrypt the message to the receiver ID server 306. Shortly after encryption of the email, the encrypted email with the message ID embedded in the encrypted email is sent to the receiver email client 310. See claim 1.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify Fountain, Alness and Lee’s teaching with Chou’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to protect the content of the message and ensure that only authorized users obtain access to it.
Regarding claims 34 and 37,Fountain, Alness and Lee disclose each and every element of claim 33 and 36. Fountain further discloses:
the cryptographic key service requested comprises a request to encrypt an electronic message, and wherein (Fountain ¶0057, When step 208 determines that the request may be performed, process control flows from step 208 to a step 210 that performs the requested cryptographic services. For example, the application server may be requesting that certain data be encrypted or decrypted. In a step 212, the cryptographic key server will respond to the application server via the secure channel. This includes marshalling the data into secure format for transmission across the network. In a next step 214, a variety of housekeeping functions related to satisfaction of an authorized request are performed. In certain embodiments, these include maintaining a database related to cryptographic requests (time, client identity, service requested, satisfactory completion, etc.)
The combination does not disclose, however Chou teaches:
performing the cryptographic key service requested comprises transferring a decrypted message to a recipient. (Chou ¶0034, The receiver 108 receives the encrypted email, but is not able to read it since the body of the email has been encrypted. The receiver 108 sends a request to read the email to the receiver's agent 110. The receiver's agent 110 then fetches a key, also referred to as a decryption key, from the receiver ID server 106 to decrypt the email. The receiver's agent 110 connects to the receiver ID server 106 using a secure channel. The receiver's agent 110 can then email the message ID to the receiver ID server 106. Chou ¶0039, The receiver's agent 208 decrypts the email for the receiver 206 to read and/or modify it.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify Fountain, Alness and Lee’s teaching with Chou’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to protect the content of the message and ensure that only authorized users obtain access to it.
Claims 42-43 are rejected under 35 U.S.C. 103 as being unpatentable over Fountain, Alness and Lee as applied to claims 11 and 18 above, and further in view of Haulotte (US 10380586 B2).
Regarding claim 42, Fountain, Alness and Lee disclose each and every element of claims 11. The combination do not disclose, however Haulotte teaches:
specifically create a plurality of cryptocurrency wallets including the cryptocurrency wallet associated with the request (col 6 lines 13-26, The purse component 220 is configured to communicate with the interface component 210, and manage one or more purses associated with a cardholder account. Each purse includes or is associated with one or more parameters that allows funds for one or more financial transactions to be strategically managed based on the parameters. The parameters may include, for example, a purse balance (e.g., an amount of funds allocated to the purse), a purse category (e.g., housing, transportation, utilities, groceries, restaurants, health, hobbies, savings), a purse priority, and the like. In some embodiments, the purse priority may be associated with one or more permissions and/or restrictions that control access to at least some funds allocated to the corresponding purse. col 6 lines 66-67 & col 7 lines 1-2, In some embodiments, the attributes are analyzed and/or processed to generate and/or modify one or more purses and/or establish and/or modify one or more purse priorities for one or more purses. col 10 lines 4-18, One or more purses may be generated at 420. In some embodiments, the electronic funds manager 200 generates at least a first purse based on the attributes. For example, the electronic funds manager 200 may identify that a spending history includes transaction data for a housing-related expense (e.g., mortgage payment), a food-related expense (e.g., groceries, restaurants), and a hobbies-related expense (e.g., sports equipment, race registrations), and generate a housing purse, a food purse, and a hobbies purse based on the spending history. Additionally or alternatively, the electronic funds manager 200 may identify that a spending history for one or more comparable cardholders includes transaction data for a transportation-related expense (e.g., car payment), and generate a transportation purse based on the comparable cardholders' spending history. Col 13 lines 41-60, receive a response to a prompt, and/or retrieve one or more attributes associated with a profile; the purse component 220, when executed by the processor 620, causes the processor 620 to generate a purse, establish one or more parameters associated with a purse, identify one or more parameters associated with a purse, and manage one or more purses; the profile component 230, when executed by the processor 620, causes the processor 620 to analyze one or more attributes associated with a profile, identify a purse associated with a cardholder account, and manage one or more profiles; and the transaction component 240, when executed by the processor 620, causes the processor 620 to compare a purse balance with a transaction amount to determine a difference between the purse balance and the transaction amount, determine whether to approve a request for authorization, determine whether a purse priority satisfies a predetermined threshold, determine whether a difference between a purse balance and a transaction amount satisfies a predetermined threshold, and transfer funds between a plurality of purses.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the combination of Fountain, Alness and Lee with Haulotte’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to dynamically process requests and ensure that the services are performed even if a wallet does not exist for the request service.
Regarding claim 43, Fountain, Alness and Lee disclose each and every element of claims 18. Fountain further teaches:
encrypt or decrypt the electronic message without revealing an identity of the requesting user. (¶0057, When step 208 determines that the request may be performed, process control flows from step 208 to a step 210 that performs the requested cryptographic services. For example, the application server may be requesting that certain data be encrypted or decrypted.)
The combination do not disclose, however Haulotte teaches:
specifically create a plurality of cryptocurrency wallets including the cryptocurrency wallet associated with the request (col 6 lines 13-26, The purse component 220 is configured to communicate with the interface component 210, and manage one or more purses associated with a cardholder account. Each purse includes or is associated with one or more parameters that allows funds for one or more financial transactions to be strategically managed based on the parameters. The parameters may include, for example, a purse balance (e.g., an amount of funds allocated to the purse), a purse category (e.g., housing, transportation, utilities, groceries, restaurants, health, hobbies, savings), a purse priority, and the like. In some embodiments, the purse priority may be associated with one or more permissions and/or restrictions that control access to at least some funds allocated to the corresponding purse. col 6 lines 66-67 & col 7 lines 1-2, In some embodiments, the attributes are analyzed and/or processed to generate and/or modify one or more purses and/or establish and/or modify one or more purse priorities for one or more purses. col 10 lines 4-18, One or more purses may be generated at 420. In some embodiments, the electronic funds manager 200 generates at least a first purse based on the attributes. For example, the electronic funds manager 200 may identify that a spending history includes transaction data for a housing-related expense (e.g., mortgage payment), a food-related expense (e.g., groceries, restaurants), and a hobbies-related expense (e.g., sports equipment, race registrations), and generate a housing purse, a food purse, and a hobbies purse based on the spending history. Additionally or alternatively, the electronic funds manager 200 may identify that a spending history for one or more comparable cardholders includes transaction data for a transportation-related expense (e.g., car payment), and generate a transportation purse based on the comparable cardholders' spending history. Col 13 lines 41-60, receive a response to a prompt, and/or retrieve one or more attributes associated with a profile; the purse component 220, when executed by the processor 620, causes the processor 620 to generate a purse, establish one or more parameters associated with a purse, identify one or more parameters associated with a purse, and manage one or more purses; the profile component 230, when executed by the processor 620, causes the processor 620 to analyze one or more attributes associated with a profile, identify a purse associated with a cardholder account, and manage one or more profiles; and the transaction component 240, when executed by the processor 620, causes the processor 620 to compare a purse balance with a transaction amount to determine a difference between the purse balance and the transaction amount, determine whether to approve a request for authorization, determine whether a purse priority satisfies a predetermined threshold, determine whether a difference between a purse balance and a transaction amount satisfies a predetermined threshold, and transfer funds between a plurality of purses.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the combination of Fountain, Alness and Lee with Haulotte’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to dynamically process requests and ensure that the services are performed even if a wallet does not exist for the request service.
Claims 27, 32 and 41 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Fountain (US 2006/0149962 A1) in view of Alness (US 2016/0344543 A1), further view of Lee (US 20140046788 A1), further in view of Haulotte (US 10380586 B2).
Regarding claim 27, Fountain discloses:
receiving, using an interface circuit, a request for a cryptographic key service from a device associated with a requesting user, wherein the cryptographic key service requested comprises encryption of an electronic message; (Fountain ¶0019, The application server 14 provides requested services to the clients 12 via the computer network 18. Services requested by the clients 12 may specifically involve cryptographic services, or may precipitate the need for cryptographic services. For example, the client requested services may require the storage of sensitive data on the network database 20, or the retrieval of encrypted data from the network database 20. The cryptographic key server 16 is available to the application server 14 to perform cryptographic services, thus offloading the computational intensities of cryptographic services from the application server 14. Fountain ¶0056, Accordingly, in a step 206 the key server receives a request for cryptographic services via the secure channel. See claim 2.)
encrypting or decrypting the electronic message without revealing an identity of the requesting user; (¶0057, When step 208 determines that the request may be performed, process control flows from step 208 to a step 210 that performs the requested cryptographic services. For example, the application server may be requesting that certain data be encrypted or decrypted.)
parsing the request to determine a type of cryptographic key service requested and (Fountain ¶0056, In receiving the cryptographic service request, the key server will unmarshal the request from encrypted network format. As described above with reference to FIG. 2, in certain embodiments this may be performed by a secure network interface engine. In a step 208, the key server will perform an authorization analysis of the cryptographic service request. The authorization analysis of step 208 determines whether the requested services should be provided to the requesting client. Fountain ¶0057, When step 208 determines that the request may be performed, process control flows from step 208 to a step 210 that performs the requested cryptographic services. For example, the application server may be requesting that certain data be encrypted or decrypted.)
causing an electronic ledger associated with the cryptographic key service to be updated. (¶0003, SSL and TLS protect data while in transit by encrypting the data using a session-key, (i.e., a cryptographic key), known only to the web server and the client computer. According to these protocols, the data is decrypted upon arrival at the receiving web server. The receiving server processes the data (e.g., validating the credit card number) and then often stores the sensitive data in a server database. ¶0019, For example, the client requested services may require the storage of sensitive data on the network database 20, or the retrieval of encrypted data from the network database 20. ¶0057, When step 208 determines that the request may be performed, process control flows from step 208 to a step 210 that performs the requested cryptographic services. For example, the application server may be requesting that certain data be encrypted or decrypted. In a step 212, the cryptographic key server will respond to the application server via the secure channel. This includes marshalling the data into secure format for transmission across the network. In a next step 214, a variety of housekeeping functions related to satisfaction of an authorized request are performed. In certain embodiments, these include maintaining a database related to cryptographic requests (time, client identity, service requested, satisfactory completion, etc.) ¶0058, When step 208 determines that the request may not be performed for failure of the authorization step 208, a step 216 performs housekeeping functions related to a failed request for services. In certain embodiments, this includes include maintaining a database related to cryptographic requests (time, client identity, service requested, etc.). This database can be used to evaluate whether an attack is being made, or to determine errors in the system.)
Fountain does not disclose, however Alness teaches:
identifying a cryptocurrency wallet associated with the request based on an anonymous identifier of the electronic message indicated in the request, wherein identifying the cryptocurrency wallet associated with the request based on the identifier of the electronic message indicated in the request the instructions further cause the processor to: (¶0005, Transactions do not explicitly identify the payor and payee by name or wallet. Instead, a bitcoin transaction transfers ownership to a new address, referred to as a “Bitcoin address”. The Bitcoin address is derived from the public portion of one or more cryptographic key pairs. The private portion of a key pair is not disclosed to the public. To send bitcoin sent to an address, a user broadcasts a payment message that is digitally signed with the associated private key. ¶0015, receive a request for payment to a bitcoin address, the request for payment including an amount of bitcoin to be paid, generate an unsigned transaction in response to receiving the request for payment, the unsigned transaction including the amount of bitcoin to be paid in the request for payment, requesting a signing of the unsigned transaction to create a signed transaction and a payment module configured to receive the request for signing the transaction, determine the address corresponding to the bitcoin address in the unsigned transaction, determine the private key stored in association with the address, ¶0052, At 114, the payment module 60 looks up the respective private key. The payment module 60 compares the address “B” in the transaction with the addresses in the database 52. When a match is found, the payment module 60 extracts the respective encrypted private key from the address “B” found in the database 52. The payment module 60 then decrypts the private key with the operational master key 64.)
the cryptocurrency wallet associated with the request; (Alness ¶0020, receiving, by the service, the request for signing the transaction, determining, by the service, the address corresponding to the bitcoin address in the unsigned transaction, determining, by the service, the encrypted private key stored in association with the address… ¶0050, FIG. 7 illustrates a payment process that is initiated by a wallet 108, for example on a mobile device or on a personal computer. It is assumed that the address “B” has 10 bitcoin (BTC) stored therein. When a user selects a “Send” button, the user, at 111, sends a request from the wallet 108 to the web application 48 to send 1 BTC to A. When the web application 48 receives the request transmitted at 111, the web application 48, at 112, generates an unsigned transaction (Tx). The transaction includes an “In” designating address “B”. The transaction includes a “OUT” reference of 1 BTC to address “A” and 8 BTC to address “B”. A further 1 BTC (not shown) represents a miner's fee.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify Fountain’s invention with Alness’s teaching. One of ordinary skills in the art would have been motivated to combine these elements that the system is able to extract the wallet identifier from the request message and identify the corresponding wallet to properly apply payments for the services requested.
The combination of Fountain and Alness do not disclose, however Lee teaches:
determining a status of the cryptocurrency wallet associated with the request, wherein the status of the cryptocurrency wallet is active during a designated time period or inactive outside the designated time period; and (Lee ¶0123, The account verification unit 335 can verify status and balance of each electronic wallet account of a user. Lee ¶0124, For example, the account verification unit 335 i) verifies the electronic wallet account corresponding to (linked to) terminal information of the user terminal 110 with a payment request of the user terminal 110, ii) determines if the electronic wallet account is available (for example, if the electronic wallet account is a dormant account or if a balance is enough to make a payment, and so forth.), and iii) notifies the result to the user terminal 110. Lee ¶0165, The payment support server 120 verifies the status of the electronic wallet account corresponding to the virtual account according to the virtual account deposit notification from the financial institution system 140 in Step 715. Lee ¶0167, Here, if the electronic wallet account is in a dormant condition due to long-term unused, the payment support server 120 can notify the status to the user terminal 110, perform activation of the dormant account and, if necessary, recharge it. Lee ¶0229, For example, the payment support server 120 determines the status and the balance of the user electronic wallet account and further determines if it is possible to process the payment amount according to the payment request. Lee ¶0230, The payment support server 120 also determines the status of the POS electronic wallet account and further determines if it is possible to reflect the deposit.)
if the status of the cryptocurrency wallet is active, then performing the cryptographic key service requested; (Lee ¶0166, If it is not possible to use the electronic wallet account (e.g., insufficient funds in account), the payment support server 120 transmits an information message for unavailable electronic wallet account to the user terminal 110 in Step 720. Lee ¶0168, If the electronic wallet account is available and usable (e.g., sufficient funds in account), the payment support server 120 identifies the limit amount of the electronic wallet account in Step 725. Here, the limit amount is the maximum amount to be deposited to the electronic wallet account. Lee ¶0170, if charging amount is within the limit, the payment support server 120 adds and deposits the charged amount to the balance of the electronic wallet account in Step 735.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify Fountain and Alness’s teaching with Lee’s teaching. One of ordinary skills in the art would have been motivated to combine these elements to ensure that the access to the key services is contingent upon the wallet’s validation status.
The combination of Fountain, Alness and Lee do not disclose, however Haulotte teaches:
specifically creating a plurality of cryptocurrency wallets including the cryptocurrency wallet associated with the request (col 6 lines 13-26, The purse component 220 is configured to communicate with the interface component 210, and manage one or more purses associated with a cardholder account. Each purse includes or is associated with one or more parameters that allows funds for one or more financial transactions to be strategically managed based on the parameters. The parameters may include, for example, a purse balance (e.g., an amount of funds allocated to the purse), a purse category (e.g., housing, transportation, utilities, groceries, restaurants, health, hobbies, savings), a purse priority, and the like. In some embodiments, the purse priority may be associated with one or more permissions and/or restrictions that control access to at least some funds allocated to the corresponding purse. col 6 lines 66-67 & col 7 lines 1-2, In some embodiments, the attributes are analyzed and/or processed to generate and/or modify one or more purses and/or establish and/or modify one or more purse priorities for one or more purses. col 10 lines 4-18, One or more purses may be generated at 420. In some embodiments, the electronic funds manager 200 generates at least a first purse based on the attributes. For example, the electronic funds manager 200 may identify that a spending history includes transaction data for a housing-related expense (e.g., mortgage payment), a food-related expense (e.g., groceries, restaurants), and a hobbies-related expense (e.g., sports equipment, race registrations), and generate a housing purse, a food purse, and a hobbies purse based on the spending history. Additionally or alternatively, the electronic funds manager 200 may identify that a spending history for one or more comparable cardholders includes transaction data for a transportation-related expense (e.g., car payment), and generate a transportation purse based on the comparable cardholders' spending history. Col 13 lines 41-60, receive a response to a prompt, and/or retrieve one or more attributes associated with a profile; the purse component 220, when executed by the processor 620, causes the processor 620 to generate a purse, establish one or more parameters associated with a purse, identify one or more parameters associated with a purse, and manage one or more purses; the profile component 230, when executed by the processor 620, causes the processor 620 to analyze one or more attributes associated with a profile, identify a purse associated with a cardholder account, and manage one or more profiles; and the transaction component 240, when executed by the processor 620, causes the processor 620 to compare a purse balance with a transaction amount to determine a difference between the purse balance and the transaction amount, determine whether to approve a request for authorization, determine whether a purse priority satisfies a predetermined threshold, determine whether a difference between a purse balance and a transaction amount satisfies a predetermined threshold, and transfer funds between a plurality of purses.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify the combination of Fountain, Alness and Lee with Haulotte’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to dynamically process requests and ensure that the services are performed even if a wallet does not exist for the request service.
Further, the claimed limitation “including the cryptocurrency wallet associated with the request” and “wherein the status of the cryptocurrency wallet is active during a designated time period or inactive outside the designated time period” only describe characteristics of the cryptocurrency wallet which are non-functional descriptive material that does not move to distinguish over prior art. When descriptive material is not functionally related to the substrate, the descriptive material will not distinguish the invention from prior art in terms of patentability. It has been held that where the printed matter is not functionally related to the substrate, the printed matter will not distinguish the invention from the prior art in terms of patentability.
Furthermore, the combination of prior art does not teach “…for at least one of: specific key requests, specific messages of the key requests, and specific requesting devices of the key requests;” and “to maintain an anonymity of the requesting user during performance of the requested cryptographic key service”. However these expressions consist of language disclosing an intended use or intended result, so they are considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
Finally, the claim limitation “if the status of the cryptocurrency wallet is active, then performing the cryptographic key service requested;” is a conditional limitation which means that the claim limitation is only required when the status of the cryptocurrency wallet is active.
Regarding claim 32, Fountain, Alness, Lee and Haulotte disclose each and every element of claim 27. Fountain further discloses:
determining the cryptographic key service requested is encryption of an electronic message;(Fountain ¶0057, When step 208 determines that the request may be performed, process control flows from step 208 to a step 210 that performs the requested cryptographic services. For example, the application server may be requesting that certain data be encrypted or decrypted. In a step 212, the cryptographic key server will respond to the application server via the secure channel. This includes marshalling the data into secure format for transmission across the network. In a next step 214, a variety of housekeeping functions related to satisfaction of an authorized request are performed. In certain embodiments, these include maintaining a database related to cryptographic requests (time, client identity, service requested, satisfactory completion, etc.)
Regarding claim 41, Fountain, Alness, Lee and Haulotte disclose each and every element of claim 27. Lee further teaches:
the instructions further cause the processor to: if the status of the cryptocurrency wallet is inactive perform the cryptographic key service requested, then sending a request to renew authorization for the cryptocurrency wallet the device. (Lee ¶0167, Here, if the electronic wallet account is in a dormant condition due to long-term unused, the payment support server 120 can notify the status to the user terminal 110, perform activation of the dormant account and, if necessary, recharge it.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify Fountain, Alness, Lee and Haulotte’s teaching with Lee’s additional teaching. One of ordinary skills in the art would have been motivated to combine these elements to ensure that the access to the key services is contingent upon the wallet’s threshold balance and send notifications messages to the user if balance is below the threshold to ensure that the user provides the required amount to process the request in a timely manner.
Further, the method claim limitation “if the status of the cryptocurrency wallet is inactive perform the cryptographic key service requested, then send a request to renew authorization for the cryptocurrency wallet the device” is a conditional limitation which means that the claim limitation is only required when the stated condition is met.
Claims 39-40 are rejected under 35 U.S.C. 103 as being unpatentable over Fountain, Alness, Lee and Haulotte as applied to claim 27 above, and further in view of Chou (US 2009/0210708 A1).
Regarding claim 39, Fountain, Alness, Lee and Haulotte disclose each and every element of claim 27. The combination do not disclose, however Chou teaches:
performing the cryptographic key service requested comprises transferring an encrypted message to a recipient. (Chou ¶0014, Another object of this invention is to provide methods to combine receiver authentication protocols with encryption key services, such that a transmitted electronic message can be encrypted to prevent unintended audiences from viewing the contents of the message. Chou ¶0018, Another advantage of this invention is that methods to combine receiver authentication protocols with encryption key services are provided such that a transmitted electronic message can be encrypted to prevent unintended audiences from viewing the contents of the message. Chou ¶0041, The sender email client 302 first sends a plain email to the sender's agent 304 to encrypt it. The sender's agent 304 encrypts the message and attaches a message ID to the encrypted email, then sends it back to the sender email client 302. The sender's agent 304 sends the message ID and the encryption key used to encrypt the message to the receiver ID server 306. Shortly after encryption of the email, the encrypted email with the message ID embedded in the encrypted email is sent to the receiver email client 310. See claim 1.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify Fountain, Alness, Lee and Haulotte’s teaching with Chou’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to protect the content of the message and ensure that only authorized users obtain access to it.
Regarding claim 40, Fountain, Alness, Lee and Haulotte disclose each and every element of claim 39. Fountain further discloses:
the cryptographic key service requested comprises a request to encrypt an electronic message, and wherein (Fountain ¶0057, When step 208 determines that the request may be performed, process control flows from step 208 to a step 210 that performs the requested cryptographic services. For example, the application server may be requesting that certain data be encrypted or decrypted. In a step 212, the cryptographic key server will respond to the application server via the secure channel. This includes marshalling the data into secure format for transmission across the network. In a next step 214, a variety of housekeeping functions related to satisfaction of an authorized request are performed. In certain embodiments, these include maintaining a database related to cryptographic requests (time, client identity, service requested, satisfactory completion, etc.)
The combination does not disclose, however Chou teaches:
performing the cryptographic key service requested comprises transferring a decrypted message to a recipient. (Chou ¶0034, The receiver 108 receives the encrypted email, but is not able to read it since the body of the email has been encrypted. The receiver 108 sends a request to read the email to the receiver's agent 110. The receiver's agent 110 then fetches a key, also referred to as a decryption key, from the receiver ID server 106 to decrypt the email. The receiver's agent 110 connects to the receiver ID server 106 using a secure channel. The receiver's agent 110 can then email the message ID to the receiver ID server 106. Chou ¶0039, The receiver's agent 208 decrypts the email for the receiver 206 to read and/or modify it.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modify Fountain, Alness, Lee and Haulotte’s teaching with Chou’s teaching. One of ordinary skills in the art would have been motivated to combine these elements in order to protect the content of the message and ensure that only authorized users obtain access to it.
Response to Arguments
Claim Rejections – 35 U.S.C. § 101
The applicant presents several assertions/arguments, i.e., “the amended claim 27 does not primary pertain to the economy or commerce and instead relate to improvement in ledger based cryptographic key services management by enabling anonymous cryptographic operations”, “steps such as communicating with a cryptocurrency system using blockchain technology, etc. cannot be performed mentally because they require electronic computer and communication equipment, and exposing the information being processed to human view would defeat the claimed anonymization purpose”, “Amended claim 27 now recites additional technical features that enable the algorithm the asserted technical improvement to the extant problems described in the application in the technological field of ledger-based (e.g., blockchain) computerized cryptographic key services management (id.), thereby integrating the asserted abstract idea into a practical application and “the claim meets the requirements of Step 2B by providing a unique and particularly recited utilization of computerized apparatus for ledger-based key management that includes technical features providing anonymization in a manner Applicant submits is neither taught nor fairly suggested by the cited references and that the amended claim 27 enablement of anonymous access to key services by allowing a key manager to authorize key usage without requiring identity disclosure, or related documents or infrastructure represents a significant enhancement to conventional technology”. The basis of these assertions are based on the applicant’s argument on pages 8-12.
Regarding the applicant’s assertion that “the amended claim 27 does not primary pertain to the economy or commerce and instead relate to improvement in ledger based cryptographic key services management by enabling anonymous cryptographic operations”, the examiner finds it not persuasive and respectfully disagrees. As amended the claim does not recite how the alleged improvement is achieved in a technical sense and instead recites certain methods of organizing human activity (i.e., fundamental economic principles and commercial or legal interactions). For example, the receiving a request, parsing the request to obtain information, identifying a wallet based on the information, creating a wallet, managing a wallet, encrypting or decrypting a message, determining the type of request based on the parsed data, performing the request if the balance meets a certain threshold and updating a leger are equivalent to managing access to a service using account information or identifiers, which fall under fundamental economic principles and commercial or legal interactions.
Further, regarding the applicant’s argument that “steps such as communicating with a cryptocurrency system using blockchain technology, etc. cannot be performed mentally because they require electronic computer and communication equipment, and exposing the information being processed to human view would defeat the claimed anonymization purpose”, the examiner finds them not persuasive and respectfully disagrees. While certain steps such as communicating with a cryptocurrency system using blockchain technology and transmitting information to a user device, cannot be performed in human mind, the underlining concept of receiving a request, parsing it, identifying a wallet, creating a wallet, managing the wallet, checking a condition and approving or denying the request falls within the “certain methods of organizing human activity” grouping of abstract ideas and mental processes.
Furthermore, the applicant asserts that “Amended claim 27 now recites additional technical features that enable the algorithm the asserted technical improvement to the extant problems described in the application in the technological field of ledger-based (e.g., blockchain) computerized cryptographic key services management (id.), thereby integrating the asserted abstract idea into a practical application.”, the examiner finds them not persuasive and respectfully disagrees. The claim merely implements a fundamental economic principle and commercial or legal interactions as described above. In response, the examiner finds that a method receiving a request, parsing the request to obtain information, identifying a wallet based on the information, creating a wallet, managing a wallet, encrypting or decrypting a message, determining the type of request based on the parsed data, performing the request if the balance meets a certain threshold and updating a leger does not provide any specific improvement to the functioning of the computer or technology as stated by the applicant. Further, the applying of the abstract idea does not improve upon the cryptographic system or ledger. Therefore, the claim does not recite any technological advancement or inventive integration beyond applying these tools to an abstract concept and thus fail to impose any meaningful limit that would transform the abstract idea into a practical application under the second prong of step 2A of the subject matter eligibility framework.
Finally, the applicant’s assertion that “the claim meets the requirements of Step 2B by providing a unique and particularly recited utilization of computerized apparatus for ledger-based key management that includes technical features providing anonymization in a manner Applicant submits is neither taught nor fairly suggested by the cited references and that the amended claim 27 enablement of anonymous access to key services by allowing a key manager to authorize key usage without requiring identity disclosure, or related documents or infrastructure represents a significant enhancement to conventional technology”, the examiner finds them not persuasive and respectfully disagrees. The analysis under 101 is distinct from 102 and 103 and novelty or uniqueness is not sufficient to establish an inventive concept under step 2b. Further, the claimed features such as enablement of anonymous access to key services by allowing a key manager to authorize key usage without requiring identity disclosure, or related documents or infrastructure are recited at a very high level of generality and describe desired results rather than technological improvements. Accordingly, the claims do not include any additional elements sufficient to amount to significantly more than the abstract idea.
As such the claims remain within an abstract idea and rejection is maintained based on the newly amended claims.
Claim Rejections – 35 U.S.C. § 103
Applicant’s arguments with respect to claim rejections 35 U.S.C. § 103 have been considered but are moot because the new ground of rejection.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
US 2017-0032370 A1 to Beltramino et al. discloses: The method involves receiving an indication to conduct a purchase transaction. A secure mobile wallet application is initialized. A selection of a payment account is received from multiple stored payment accounts. A pre-loaded wallet single use key (W-SUK) is retrieved (512). A wallet session key (W-SK) utilizing the W-SUK is derived (514). The transaction data is encrypted (516) using the W-SK. A machine readable code utilizing the encrypted transaction data is generated (518). The machine readable code is displayed (520) for reading by merchant scanner to conduct a purchase transaction.
US 2016/0203477 A1 to Yang et al. discloses: Various embodiments include a wallet service that processes a cryptocurrency deposit into a cryptocurrency wallet account maintained in a wallet service system. The wallet service can receive an authentication parameter to authenticate the cryptocurrency deposit and record a transfer of a cryptocurrency amount from a first cryptocurrency address to a second cryptocurrency address. In response to and substantially immediately after authenticating the authentication parameter, the wallet service can exchange the cryptocurrency amount associated with the cryptocurrency deposit for fiat currency proceeds and deposit the fiat currency proceeds into a fiat reserve account. The wallet service can then associate exchangeable credit equal to the fiat currency proceeds to the cryptocurrency wallet account. In response to receiving a user-initiated request to spend a target portion of the exchangeable credit, the cryptocurrency wallet service can exchange, from the fiat reserve account, for cryptocurrency proceeds equal to the target portion.
US 7,668,093 B1 to Clubb discloses: A framework to transition and re-partition information for event processing and downstream processing can be used in a real time system comprising components such as a consumer server, a file control database, an event manager, an event store, and a configurable output stream. The event manager may be a process which can be enhanced through the use of tags which are inserted to provide information for various downstream systems. The configurable output stream can be defined through an application programming interface which is configured to receive a filter to be applied to the output.
US 8856045 B1 to Patel discloses: Described herein is a mobile-device-to-machine payment system and method for facilitating a cashless transaction for purchase of at least one product or service by a user from a payment accepting unit.
US 2020/0311725 A1 to Savolainen discloses: According to an example aspect of the present invention, there is provided an apparatus comprising memory configured to store a measurement device identifier, and at least one processing core configured to compile a measurement request, the measurement request comprising the measurement device identifier, a public key of the apparatus and cryptographic payment information, to cause transmission of the measurement request, and to decrypt measurement data using a private key of the apparatus.
US 2010/0037050 A1 to Karul discloses: An apparatus and method for exchanging encrypted messages or data. According to an embodiment, messages are encrypted according to credentials associated with a user and the encrypted messages are stored in memory. The credentials are encrypted and stored in a key services module. To retrieve a message, the user logs onto to a server with a password, and the server retrieves the encrypted credentials associated with the user from the key services and applies the user password to decrypt or recover the encrypted credentials. If the credentials are successfully recovered, the server uses the decrypted credentials to decrypt the message and the decrypted message is made available to the user.
US 2015/0019443 A1 to Sheet et al. discloses: Embodiments of the present invention are directed to methods, apparatuses, computer readable media and systems for securely processing remote transactions. One embodiment of the invention is directed to a method of processing a remote transaction initiated by a mobile device comprising a server computer receiving a payment request including encrypted payment information. The encrypted payment information being generated by a mobile payment application of the mobile device and being encrypted using a third party key. The method further comprises decrypting the encrypted payment information using the third party key, determining a transaction processor public key associated with the payment information, and re-encrypting the payment information using the transaction processor public key. The method further comprises sending a payment response including the re-encrypted payment information to a transaction processor. The transaction processor decrypts the re-encrypted payment information using a transaction processor private key and initiates a payment transaction.
CN 101334914 A to Sun discloses: The invention claims a method for prompting balance information of e-wallet, e-wallet storage card and mobile terminal. The method comprises inquiring the balance information of e-wallet according to the balance inquiry request information and comparing the balance information with the pre-set balance threshold value; sending prompt information of insufficient balance to the mobile terminal if said balance information is smaller than said pre-set balance threshold value. The mobile terminal would prompt the user to credit so as to improve the service quality after finishing a credit purchase and the balance information is smaller than said pre-set balance threshold value by comparing the e-wallet balance with the pre-set balance threshold value; the invention only needs to do some modification to the software of the SIM card with low cost and short development period.
US 6934664 B1 to Webb et el. discloses: A system and method for monitoring a security state of a portable electronic device (PED), such as a personal digital assistant (PDA), are provided. A security state may be determined by physical or electronic characteristics of the PED. The relative position of PED pieces, the position of a latch, and/or the status of a software application may determine a security state. Furthermore, a PED may have open, closed, and partially open security states. Information about a current security state of a PED may be transmitted to a point-of-sale device (POS), system processor, and/or financial institution. The PED or any of these other devices may use this information to determine whether to allow or restrict a financial transaction involving the PED. Additionally, a software program on the PED may be allowed or restricted from running depending on the information about the current security state.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JANICE LOZA whose telephone number is (571)270-3979. The examiner can normally be reached Monday - Friday 7:30am - 5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.L./Examiner, Art Unit 3698
/STEVEN S KIM/Primary Examiner, Art Unit 3698