DETAILED ACTION
Status of Application
This action is a Non-Final Rejection. This action is in response to the amendment and response filed on June 16, 2026.
Claims 1-24 have been canceled.
Claims 25-27, 29, and 34-38 have been amended.
Claims 25-38 are rejected.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Response to Arguments
Regarding the rejections under 35 U.S.C. §§ 112(a) and (b), the rejections are withdrawn in light of Applicants amendments and remarks. Any terms not defined in the Specification are interpreted using the broadest reasonable interpretation.
Regarding the rejection under 35 U.S.C. § 101, Applicant argues that “the claims integrate any alleged abstract idea into a practical application, as the functional specifications are not merely business interactions.” Remarks at 21. However, the claims are using existing technology to implement a business process.
Applicant further argues that “[t]he claimed architecture improves the functioning and security of a computer-implemented system. In the claimed arrangement, one coin deposit managing unit can manage coin deposits of different users with different functional restrictions while using a common secure execution unit. The disclosure explains that this provides high flexibility in the coin deposit managing unit independent of the coin register and transaction register, and that the coin register, which is already subject to particularly high requirements in a digital currency system, is not slowed down (para. [0057]). This is a technological improvement to the way the digital coin system enforces deposit-specific functions without requiring the central coin register to implement each user-specific or issuer-specific restriction.” Remarks at 21. However, Applicant is not describing a technological improvement. Instead, applicant is describing alleged improvements to the abstract idea.
Applicant further argues that “the claims recite significantly more than any alleged abstract idea. The ordered combination of hardware components, stored coin deposit data, coin deposits of different users, deposit-specific functional specifications, a secure execution unit that checks the functional specifications when managing coin data sets, and registration requests to a coin register defines a particular technological implement.” Remarks at 21. However, even when the additional elements are viewed as a combination, they only require a programmed general purpose computing device to implement an abstract idea. As such, the rejection under 35 U.S.C. 101 is maintained.
Regarding the rejection under 35 U.S.C. § 103, Applicant argues that the checks in Myshkin “are global operational checks for the secure computer and its hot/cold memory modules, not different functional specifications stored in first and second coin deposits of different users.” Remarks at 23. There is a new ground of rejection in light of Applicant’s amendments. Simonson teaches that each user can set of their own spending rules.
Applicant further argues that “Myshkin further fails to teach or suggest a secure execution unit that sends registration requests to a coin register of a central bank, as the receive/release block of Myshkin receives requests from the platform server and stores or removes electronic documents from hot memory modules, then sends response messages confirming deposit or withdrawal (paras. [0017]-[0020]).” Remarks at 25. This limitation in claim 25 of “wherein the secure execution unit is configured to exchange digital coin data sets with coin managing units via the communication interface and to send registration requests to a coin register of the central bank” is written broadly. It appears that it means that data is sent to the central bank so that the central bank can track balances. Myshkin teaches that the platform server or other networked computer sends requests (i.e,. registration requests) to the secure computer. When combined with Quibria, which discusses central bank digital currencies, this limitation is obvious. As such, the rejection is maintained.
Claim Interpretation
Applicant should be aware that there is claim language that does not serve to differentiate the claims from the prior art and/or provide an additional element that can be a consideration for eligibility1. See MPEP 2103(c).
Nonfunctional Descriptive Material
Nonfunctional descriptive material is generally not given patentable weight. See MPEP 2111.05. Any difference related merely to the meaning and information conveyed through labels (i.e., the type of the item) which does not explicitly alter or impact the steps of the method is nonfunctional descriptive material and does not patentably distinguish the claimed invention from the prior art in terms of patentability.
The following limitations include nonfunctional descriptive material:
Claim 38: “wherein the secure execution unit for managing the coin data sets transmits transaction register data to a transaction register, wherein the transaction register data comprise in particular a unique transaction identifier, a transaction amount, a coin managing unit identifier of the sender, a coin managing unit identifier of the recipient, and the register reference of the coin data set in the coin register, and/or transmits registration requests to the coin register, each registration request comprising at least one register reference of a coin data set previously registered in the coin register and a register reference of a coin data set to be registered in the coin register.” (The content of the data is nonfunctional descriptive material.)
Other
The claims use the language of “and/or.” The broadest reasonable interpretation of “and/or” includes “or.” When a claim includes alternative options by using “and/or,” only one option is required according to the broadest reasonable interpretation.
Claim Objections
Claim 25 is objected to for the following reason: Claim 25 recites “wherein the first coin deposit comprises a first functional specification comprising a first condition of provision to be checked when the secure execution unit manages coin data sets of the first coin deposit, and the secure execution unit is configured to check the first functional specification when managing coin data sets of the first coin deposit.” Because the last limitation of claim 25 refers to “the first condition or provision” and “a second condition or provision,” it appears that “of” is a typographical error. Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 25-38 are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Does the Claim Fall within a Statutory Category? (see MPEP 2106.03)
Yes, with respect to claims 25-38, which recite a coin deposit managing unit that comprises at least one processor.
Step 2A, Prong One: Is a Judicial Exception Recited? (see MPEP 2106.04(a))
The following claims identify the limitations that recite the abstract idea in regular text and that recite additional elements in bold:
25. A coin deposit managing unit, comprising:
a communication interface;
a computer-readable memory storing coin deposit data; and
at least one processor coupled to the communication interface and the computer-readable memory and configured as a secure execution unit for managing digital coin data sets of a central bank,
wherein the secure execution unit is configured to exchange digital coin data sets with coin managing units via the communication interface and to send registration requests to a coin register of the central bank,
wherein the coin deposit data comprises a first coin deposit that comprises at least a first digital coin data set, and a second coin deposit that comprises at least a second digital coin data set;
wherein the coin deposit managing unit manages coin deposits of different users; and
wherein the first coin deposit comprises a first functional specification comprising a first condition of provision to be checked when the secure execution unit manages coin data sets of the first coin deposit, and the secure execution unit is configured to check the first functional specification when managing coin data sets of the first coin deposit, and
wherein the second coin deposit comprises a second, different functional specification comprising a second condition or provision to be checked when the secure execution unit manages coin data sets of the second coin deposit, the second condition or provision being different from the first condition or provision, and the secure execution unit is configured to check the second functional specification when managing coin data sets of the second coin deposit.
26. The coin deposit managing unit according to claim 25, wherein the first and second functional specifications relate to a function executable by the secure execution unit, and respectively completely or partially restricting, or not restricting, the executable function for the corresponding first or second coin deposit.
27. The coin deposit managing unit according to claim 25, wherein the first and/or the second functional specification is a transmit or receive specification which restricts the sending of coin data sets or the receiving of coin data sets for the corresponding first or second coin deposit.
28. The coin deposit managing unit according to claim 25, wherein
a transmit specification of the first and/or the second coin deposit is different from its receive specification; and/or
at least one partially restricting transmit specification restricts the sending of coin data sets to exactly one recipient, exactly one recipient group, or to several recipients and/or recipient groups; and/or
at least one partially restricting receive specification restricts the receiving of coin data sets to exactly one sender, exactly one sender group, or several senders and/or sender groups; and/or
the first functional specification as a send or receive specification of the first coin deposit comprises the second coin deposit,
wherein in particular the second coin deposit is a recipient or sender, and the only authorized recipient or sender, for coin data sets of the first coin deposit.
29. The coin deposit managing unit according to claim 25, wherein the first and/or the second functional specification is a specification for conditional transactions.
30. The coin deposit managing unit according to claim 29, wherein
a conditional transaction for a coin deposit is buffer stored, in particular in a buffer store of the coin deposit or in a buffer store, extending over more than one coin deposit, of the coin deposit managing unit; and/or
the secure execution unit executes the conditional transaction only when a condition is met that is contained in the conditional transaction, and/or a conditional transaction comprises a temporal condition;
and/or a conditional transaction comprises an external triggering event and/or a securing value; and/or
a specification for conditional transactions contains a type of condition and/or a type of the conditional transaction which is permissible for the coin deposit.
31. The coin deposit managing unit according to claim 25, wherein
the first and the second coin deposit each comprise several functional specifications, and/or
the first and second functional specification relate to the same function executable by the secure execution unit.
32. The coin deposit managing unit according to claim 25, wherein the first and/or the second coin deposit further comprises an amount specification, i.e., a non- functional specification:
a maximum value for the amount of the coin data sets to be sent and/or for the amount of the coin data sets to be received, or
a maximum value or a minimum value for the total amount of the stored coin data sets.
33. The coin deposit managing unit according to claim 25, wherein the first and second functional specification comprise:
a defined functional minimum specification, which is initially defined in particular by an issuer of the coin deposit, and/or
a selectable functional specification, which is to be selected in particular by the user so that it is narrower than a defined functional specification.
34. The coin deposit managing unit according to claim 25, wherein, the first and the second coin deposit are assigned to a first user; or
wherein the first coin deposit is assigned to a first user, and the second coin deposit is assigned to a second user.
35. The coin deposit managing unit according to claim 25, wherein the first and/or the second coin deposit further comprises one or more of the following data elements:
a unique coin managing unit identifier, which in particular identifies the coin deposit and the secure execution unit,
a public coin managing unit key of an asymmetric key pair; optionally, a secret coin managing unit key of the asymmetric key pair; and/or
a coin managing unit certificate, which in particular comprises the coin deposit identifier and/or the public coin deposit key as certified contents.
36. The coin deposit managing unit according to claim 25, wherein the first and/or the second coin deposit comprises at least one partially freely-readable specification, and in particular the first or second functional specification;
wherein in particular a readable portion and a non-readable portion of the at least partially freely-readable specification are present; and
wherein the two portions are stored in different data elements, or
stored in a common data element in a non-readable manner, and additionally the readable portion is stored in a separate readable data element.
37. The coin managing unit according to claim 25, wherein the first and/or the second functional specification is a counter-performance specification that specifies whether the corresponding coin deposit is permitted to execute a transaction,
wherein the counter-performance comprises response data provided in response to at least one received coin data set to the sender of the received coin data set.
38. The coin deposit managing unit according to claim 25, wherein the secure execution unit for managing the coin data sets
transmits transaction register data to a transaction register,
wherein the transaction register data comprise in particular a unique transaction identifier, a transaction amount, a coin managing unit identifier of the sender, a coin managing unit identifier of the recipient, and the register reference of the coin data set in the coin register, and/or
transmits registration requests to the coin register, each registration request comprising at least one register reference of a coin data set previously registered in the coin register and a register reference of a coin data set to be registered in the coin register.
Yes. But for the recited additional elements as shown above in bold, the remaining limitations of the claims recite certain methods of organizing human activity. The claims are directed to managing digital coins. This type of method of organizing human activity is a commercial interaction such as sales activities or behaviors and business relations. Thus, the claims recite an abstract idea.
Step 2A, Prong Two: Is the Abstract Idea Integrated into a Practical Application? (see MPEP 2106.04(d))
No. The claims as a whole merely use a computer as a tool to perform the abstract idea. The claimed units or software components (i.e., additional elements that are in bold above) are recited at a high level of generality and are merely invoked as a tool to implement the steps. For example, only software implemented on a programmed general purpose computing device is needed to perform the claimed process. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Additionally, there is no improvement to the functioning of a computer or technology. Therefore, the abstract idea is not integrated into a practical application.
Step 2B: Does the Claim Provide an Inventive Concept? (see MPEP 2106.05)
No. As discussed with respect to Step 2A, Prong 2, the additional elements in the claims, both individually and in combination, amount to no more than tools to perform the abstract idea. Merely performing the abstract idea using a computer cannot provide an inventive concept. Therefore, the claims do not provide an inventive concept.
As such, the claims are not patent eligible.
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 25-38 are rejected under 35 U.S.C. 103 as being unpatentable over Myshkin et al., U.S. Patent Application Publication No. 2018/0341931 A1; Quibria, Nasreen. “Digital Dollar Digest: What Central Bank Digital Currency Architecture Means for Community Banks,” https://www.icba.org/w/digital-dollar-digest-what-central-bank-digital-currency-architecture-means-for-community-banks (June 3, 2021); and Simonson, U.S. Patent Application Publication Number 2021/0406908 A1.
Claim 25:
Myshkin teaches:
a communication interface; a computer-readable memory storing coin deposit data; and at least one processor coupled to the communication interface and the computer-readable memory and configured as (see at least Myshkin, Figure 2 and associated text).
a secure execution unit for managing digital coin data sets…, (see at least Myshkin, Figure 2 and associated text; paragraph 0020 (“…receive/release block 214 can store the cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents in a hot memory module (or a hot wallet), such as hot memory module 224a (or hot wallet 224a).”)).
wherein the secure execution unit is configured to exchange digital coin data sets with coin managing units via the communication interface and to send registration requests to a coin register of the central bank, (see at least Myshkin, paragraph 0019 (“Receive/release block 214 enables secure computer 210 to respond to requests for receipt and/or release of cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents of interest to an authorized user. Receive/release block 214 can receive these requests from another networked computer, such as platform server 130 in FIG. 1. Receive/release block 214 includes a non-IP network interface controller that enables it to receive and respond to requests over a non-IP communication link, such as secure connection 132 in FIG. 1.”); paragraph 0020 (“In response to a request for release of cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents from a withdrawing authorized user, receive/release block 214 can remove the cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents from a hot memory module (or a hot wallet), such as hot memory module 224a (or hot wallet 224a), and send the electronic documents in a response message.”)).
wherein the coin deposit data comprises a first coin deposit that comprises at least a first digital coin data set, and a second coin deposit that comprises at least a second digital coin data set; wherein the coin deposit managing unit manages coin deposits of different users; and (see at least Myshkin, Figure 2 and associated text; paragraph 0015 (Authorized users use the secure electronic system.); paragraph 0020 (“…receive/release block 214 can store the cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents in a hot memory module (or a hot wallet), such as hot memory module 224a (or hot wallet 224a).”)).
wherein the first coin deposit comprises a first functional specification comprising a first condition of provision to be checked when the secure execution unit manages coin data sets of the first coin deposit, and the secure execution unit is configured to check the first functional specification when managing coin data sets of the first coin deposit, and wherein the second coin deposit comprises a second, … comprising a second condition or provision to be checked when the secure execution unit manages coin data sets of the second coin deposit, … and the secure execution unit is configured to check the second functional specification when managing coin data sets of the second coin deposit (see at least Myshkin, Figure 2 and associated text; Figure 4 and associated text (Before a withdrawal can be released, several conditions must be met.); Figure 6 and associated text (Before a deposit can be received, several conditions must be met.)).
Myshkin does not explicitly teach, but Quibria, however, does teach:
…of a central bank (see at least Quibria (This reference discusses central bank digital currencies (CBDC).)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Quibria’s central bank with Myshkin’s secure electronic system for managing digital currencies. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of managing a digital currency such as CBDC that is issued by a central bank. Digital currency transactions are convenient and quick and it would be obvious to use one that is the liability of a central bank in order to reduce risk associated with a transaction.
Myshkin does not explicitly teach, but Simonson, however, does teach:
different functional specification…, the second condition or provision being different from the first condition or provision… (see at least Simonson, paragraph 0010 (“The user may establish one or more spending or transaction processing limits on the payment card and/or digital account for use of the credit limit and/or balance, which may include different throttle parameters. For example, a transaction processing limit and/or spending throttle may limit available credit to the payment card to less than a maximum amount of credit, such as $3,000 even though the maximum credit limit is $10,000. Thereafter, the online transaction processor may monitor the payment card and/or digital accounts usage on an electronic card network to enforce the spending throttle and limit card usage. This data processing may occur in certain time intervals or after a time period or cycle, such as weekly, monthly, or the like (e.g., after a billing cycle). Thereafter, as the user utilizes the payment card to process transactions, the online transaction processor may prevent data processing if a throttle is exceeded.”)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Simonson’s customized spending limits with Myshkin’s secure electronic system for managing digital currencies. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of providing a way for each user to individually configure an account to prevent overspending and reduce the likelihood of fraud. See Simonson, paragraph 0002.
Claim 26:
Myshkin further teaches:
wherein the first and second functional specifications relate to a function executable by the secure execution unit, and respectively completely or partially restricting, or not restricting, the executable function for corresponding first or second the coin deposit (see at least Myshkin, Figure 2 and associated text; Figure 4 and associated text (Before a withdrawal can be released, several conditions must be met.); Figure 6 and associated text (Before a deposit can be received, several conditions must be met.)).
Claim 27:
Myshkin further teaches:
wherein the first and/or the second functional specification is a transmit or receive specification which restricts the sending of coin data sets or the receiving of coin data sets for the corresponding first or second coin deposit (see at least Myshkin, Figure 2 and associated text; Figure 4 and associated text (Before a withdrawal can be released, several conditions must be met.); Figure 6 and associated text (Before a deposit can be received, several conditions must be met.)).
Claim 28:
Myshkin further teaches:
wherein a transmit specification of the first and/or the second coin deposit is different from its receive specification; and/or at least one partially restricting transmit specification restricts the sending of coin data sets to exactly one recipient, exactly one recipient group, or to several recipients and/or recipient groups; and/or at least one partially restricting receive specification restricts the receiving of coin data sets to exactly one sender, exactly one sender group, or several senders and/or sender groups; and/or the first functional specification as a send or receive specification of the first coin deposit comprises the second coin deposit, wherein in particular the second coin deposit is a recipient or sender, and the only authorized recipient or sender, for coin data sets of the first coin deposit (see at least Myshkin, Figure 2 and associated text; Figure 4 and associated text (Before a withdrawal can be released, several conditions must be met.); Figure 6 and associated text (Before a deposit can be received, several conditions must be met.)).
Claim 29:
Myshkin further teaches:
wherein the first and/or the second functional specification is a specification for conditional transactions (see at least Myshkin, Figure 2 and associated text; Figure 4 and associated text (Before a withdrawal can be released, several conditions must be met.); Figure 6 and associated text (Before a deposit can be received, several conditions must be met.)).
Claim 30:
Myshkin further teaches:
wherein a conditional transaction for a coin deposit is buffer stored, in particular in a buffer store of the coin deposit or in a buffer store, extending over more than one coin deposit, of the coin deposit managing unit; and/or the secure execution unit executes the conditional transaction only when a condition is met that is contained in the conditional transaction, and/or a conditional transaction comprises a temporal condition; and/or a conditional transaction comprises an external triggering event and/or a securing value; and/or a specification for conditional transactions contains a type of condition and/or a type of the conditional transaction which is permissible for the coin deposit (see at least Myshkin, Figure 2 and associated text; Figure 4 and associated text (Before a withdrawal can be released, several conditions must be met.); Figure 6 and associated text (Before a deposit can be received, several conditions must be met.)).
Claim 31:
Myshkin further teaches:
wherein the first and the second coin deposit each comprise several functional specifications, and/or the first and second functional specification relate to the same function executable by the secure execution unit (see at least Myshkin, Figure 2 and associated text; Figure 4 and associated text (Before a withdrawal can be released, several conditions must be met.); Figure 6 and associated text (Before a deposit can be received, several conditions must be met.)).
Claim 32:
Myshkin further teaches:
wherein the first and/or the second coin deposit further comprises an amount specification, i.e., a non- functional specification: a maximum value for the amount of the coin data sets to be sent and/or for the amount of the coin data sets to be received, or a maximum value or a minimum value for the total amount of the stored coin data sets (see at least Myshkin, paragraph 0028 (“Memory powering block 220 and empty/full checker 218 may communicate to power up cold memory modules 226b, 226c, and 226d (or cold wallets 226b, 226c, and 226d) when empty/full checker 218 detects an empty condition. Empty/full checker 218 can detect an empty condition when cryptocurrencies, digital currencies, tokens, smart contracts, or public or private keys stored in hot memory module 224a (or hot wallet 224a) fall below a low threshold. In one implementation, a low threshold can be a fixed quantity, such as zero. For example, if receive/release block 214 is required to release 700,000 units of cryptocurrencies, but hot memory module 224a (or hot wallet 224a) presently contains only 508,000 units, empty/full checker 218 can detect this condition and flag the anticipated empty condition, and memory powering block 220 can power up and make hot one of cold memory modules 226b, 226c, or 226d (or cold wallets 226b, 226c, or 226d) to provide additional cryptocurrencies for the anticipated deficit due to the upcoming empty condition of hot wallet 224a. In various implementation, a low threshold can be dynamic and depend on a quantity of cryptocurrencies presently requested to be released, an expected quantity of cryptocurrencies needed for satisfying upcoming requests, time, or other algorithms.”)).
Claim 33:
Myshkin further teaches:
wherein the first and second functional specification comprise: a defined functional minimum specification, which is initially defined in particular by an issuer of the coin deposit, and/or a selectable functional specification, which is to be selected in particular by the user so that it is narrower than a defined functional specification (see at least Myshkin, paragraph 0028 (“Memory powering block 220 and empty/full checker 218 may communicate to power up cold memory modules 226b, 226c, and 226d (or cold wallets 226b, 226c, and 226d) when empty/full checker 218 detects an empty condition. Empty/full checker 218 can detect an empty condition when cryptocurrencies, digital currencies, tokens, smart contracts, or public or private keys stored in hot memory module 224a (or hot wallet 224a) fall below a low threshold. In one implementation, a low threshold can be a fixed quantity, such as zero. For example, if receive/release block 214 is required to release 700,000 units of cryptocurrencies, but hot memory module 224a (or hot wallet 224a) presently contains only 508,000 units, empty/full checker 218 can detect this condition and flag the anticipated empty condition, and memory powering block 220 can power up and make hot one of cold memory modules 226b, 226c, or 226d (or cold wallets 226b, 226c, or 226d) to provide additional cryptocurrencies for the anticipated deficit due to the upcoming empty condition of hot wallet 224a. In various implementation, a low threshold can be dynamic and depend on a quantity of cryptocurrencies presently requested to be released, an expected quantity of cryptocurrencies needed for satisfying upcoming requests, time, or other algorithms.”)).
Claim 34:
Myshkin further teaches:
wherein, the first and the second coin deposit are assigned to a first user; or wherein the first coin deposit is assigned to a first user, and the second coin deposit is assigned to a second user (see at least Myshkin, Figure 2 and associated text; paragraph 0015 (Authorized users use the secure electronic system.); paragraph 0020 (“…receive/release block 214 can store the cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents in a hot memory module (or a hot wallet), such as hot memory module 224a (or hot wallet 224a).”)).
Claim 35:
Myshkin further teaches:
wherein the first and/or the second coin deposit further comprises one or more of the following data elements: a unique coin managing unit identifier, which in particular identifies the coin deposit and the secure execution unit, a public coin managing unit key of an asymmetric key pair; optionally, a secret coin managing unit key of the asymmetric key pair; and/or a coin managing unit certificate, which in particular comprises the coin deposit identifier and/or the public coin deposit key as certified contents (see at least Myshkin, paragraph 0014 (“FIG. 1 illustrates a diagram of a portion of an exemplary secure system 100 for creation, verification, management and storage of electronic documents such as cryptocurrencies, digital currencies, tokens, and smart contracts according to one implementation of the present application. As used in the present application, “electronic documents” may refer to any electronic representation capable of being stored. Electronic documents can be cryptocurrencies, digital currencies, tokens, or smart contracts. Electronic documents can also be public or private keys, such as public or private keys utilized in a cryptocurrency network.”))
Claim 36:
Myshkin further teaches:
wherein the first and/or the second coin deposit comprises at least one partially freely-readable specification, and in particular the first or second functional specification; wherein in particular a readable portion and a non-readable portion of the at least partially freely-readable specification are present; and wherein the two portions are stored in different data elements, or stored in a common data element in a non-readable manner, and additionally the readable portion is stored in a separate readable data element (see at least Myshkin, Figure 2 and associated text; Figure 4 and associated text (Before a withdrawal can be released, several conditions must be met.); Figure 6 and associated text (Before a deposit can be received, several conditions must be met.)).
Claim 37:
Myshkin further teaches:
wherein the first and/or the second functional specification is a counter-performance specification that specifies whether the corresponding coin deposit is permitted to execute a transaction, wherein the counter-performance comprises response data provided in response to at least one received coin data set to the sender of the received coin data set (see at least Myshkin, Figure 2 and associated text; Figure 4 and associated text (Before a withdrawal can be released, several conditions must be met.); Figure 6 and associated text (Before a deposit can be received, several conditions must be met.); paragraph 0019 (“Receive/release block 214 enables secure computer 210 to respond to requests for receipt and/or release of cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents of interest to an authorized user. Receive/release block 214 can receive these requests from another networked computer, such as platform server 130 in FIG. 1. Receive/release block 214 includes a non-IP network interface controller that enables it to receive and respond to requests over a non-IP communication link, such as secure connection 132 in FIG. 1.”); paragraph 0020 (“In response to a request for release of cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents from a withdrawing authorized user, receive/release block 214 can remove the cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents from a hot memory module (or a hot wallet), such as hot memory module 224a (or hot wallet 224a), and send the electronic documents in a response message.”)).
Claim 38:
Myshkin further teaches:
wherein the secure execution unit for managing the coin data sets transmits transaction register data to a transaction register, wherein the transaction register data comprise in particular a unique transaction identifier, a transaction amount, a coin managing unit identifier of the sender, a coin managing unit identifier of the recipient, and the register reference of the coin data set in the coin register, and/or transmits registration requests to the coin register, each registration request comprising at least one register reference of a coin data set previously registered in the coin register and a register reference of a coin data set to be registered in the coin register (see at least Myshkin, Figure 2 and associated text; paragraph 0020 (“…receive/release block 214 can store the cryptocurrencies, digital currencies, tokens, smart contracts, and in general electronic documents in a hot memory module (or a hot wallet), such as hot memory module 224a (or hot wallet 224a).”)).
Relevant Prior Art
The following references are relevant to Applicant’s invention:
Mallela et al., U.S. Patent Application Publication Number 2021/0224794 A1. This reference teaches a system for conducting and managing cryptocurrency transactions.
Fogg, U.S. Patent Number 10,915,895 B1. This reference teaches a system for managing and transferring electronic currencies.
Email Communications
Per MPEP 502.03, Applicant may authorize email communications by filing Form PTO/SB/439, available at https://www.uspto.gov/sites/default/files/documents/sb0439.pdf, via the USPTO patent electronic filing system.
Conclusion
THIS ACTION IS MADE FINAL. 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 extension fee 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ELIZABETH H ROSEN whose telephone number is (571) 270-1850 and email address is elizabeth.rosen@uspto.gov. The examiner can normally be reached Monday - Friday, 10 AM ET - 7 PM ET.
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, Michael Anderson, can be reached at 571-270-0508. 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.
/ELIZABETH H ROSEN/Primary Examiner, 3693
1 See MPEP 2106.04(d)(2) (“Examiners should keep in mind that in order to qualify as a "treatment" or "prophylaxis" limitation for purposes of this consideration, the claim limitation in question must affirmatively recite an action that effects a particular treatment or prophylaxis for a disease or medical condition. An example of such a limitation is a step of "administering amazonic acid to a patient" or a step of "administering a course of plasmapheresis to a patient." If the limitation does not actually provide a treatment or prophylaxis, e.g., it is merely an intended use of the claimed invention or a field of use limitation, then it cannot integrate a judicial exception under the "treatment or prophylaxis" consideration. For example, a step of "prescribing a topical steroid to a patient with eczema" is not a positive limitation because it does not require that the steroid actually be used by or on the patient, and a recitation that a claimed product is a "pharmaceutical composition" or that a "feed dispenser is operable to dispense a mineral supplement" are not affirmative limitations because they are merely indicating how the claimed invention might be used.”)
Prosecution Insights