DETAILED ACTION
The present application, filed on 4/8/2024 is being examined under the AIA first inventor to file provisions.
The following is a FINAL Office Action in response to Applicant’s amendments filed on 12/10/2025.
a. Claims 1-3, 5-17 are amended
Overall, Claims 1-17 are pending and have been considered below.
Claim Rejections - 35 USC § 101
35 USC 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-17 are rejected under 35 USC 101 because the claimed invention is not directed to patent eligible subject matter. The claimed matter is directed to a judicial exception, i.e. an abstract idea, not integrated into a practical application, and without significantly more.
Per Step 1 of the multi-step eligibility analysis, claims 1-7 are directed to a system, claims 8-13 are directed to a system, claims 14-16 are directed to a system, and claim 17 is directed to a system.
Thus, on its face, each independent claim and the associated dependent claims are directed to a statutory category of invention.
[INDEPENDENT CLAIMS]
Per Step 2A.1. Independent claim 1, is rejected under 35 USC 101 because the independent claim is directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application.
The limitations of the independent claim 1 recite an abstract idea, shown in bold below:
[A] A recovery unit in an electronic payment transaction system, the recovery unit:
[B] receive, from a plurality of secure transaction units, token recovery data sets, and
a computer-readable storage unit coupled to the communication interface and configured to
[C] store the token recovery data sets,
[D] wherein each token recovery data set comprises one or more token references that are uniquely assigned to one or more tokens being managed by one of the plurality of secure transaction units at the time of generating the respective token recovery data set, each token comprising at least a monetary value and a private key of a token-individual key pair and each token reference comprising at least the monetary value and a public key corresponding to the private key of the token-individual key pair,
[E] wherein the recovery unit is configured, upon a recovery request received via the communication interface from a participant to whom the one of the plurality of secure transaction units is assigned, to
[F] read the token recovery data set associated with that secure transaction unit and to
[G] generate, based on the token references in the token recovery data set, one or more registration requests for a token reference register to block and/or to recover the one or more tokens upon request.
Independent claim 1 recites: read the token recovery dataset ([F]) and generate a request to block or recover tokens ([G]), which, based on the claim language and in view of the application disclosure, represents a process aimed at: “recovering or blocking payment tokens in a tokenized electronic payment system”.
This is a combination that, under its broadest reasonable interpretation, agreements in the form of contracts, legal obligations, sales activities or behaviors, business relationships (e-commerce), which falls under Certain Methods of Organizing Human Activity, i.e., Commercial or Legal Interactions grouping of abstract ideas (see MPEP 2106.04(a)(2)).
Accordingly, it is concluded that independent claim 1 recites an abstract idea that corresponds to a judicial exception.
[INDEPENDENT CLAIMS – QUALIFIERS]
Per Step 2A.2. The identified abstract idea is not integrated into a practical application because the additional elements in the independent claims only amount to instructions to apply the judicial exception to a computer, or are a general link to a technological environment (see MPEP 2106.05(f); MPEP 2106.05(h)).
For example, the added elements “communication interface,” “computer-readable storage unit,” and recite computing elements at a high level of generality, generally linking the use of a judicial exception to a particular technological environment (see MPEP 2106.05(h)), or merely using a computer as a tool to perform an abstract idea (MPEP 2106.05(f)). Further, the qualifiers “wherein each token recovery data set comprises one or more token references that are uniquely assigned to one or more tokens being managed by one of the plurality of secure transaction units at the time of generating the respective token recovery data set, each token comprising at least a monetary value and a private key of a token-individual key pair and each token reference comprising at least the monetary value and a public key corresponding to the private key of the token-individual key pair,” as applied to the token recovery dataset, are nothing more than (a) descriptive limitations of claim elements, such as describing the nature, structure and/or content of other claim elements, or (b) general links to the computing environment, which amount to instructions to “apply it,” or equivalent (MPEP 2106.05(f)).
These qualifiers of the independent claims do not preclude from carrying out the identified abstract idea “recovering or blocking payment tokens in a tokenized electronic payment system”, and do not serve to integrate the identified abstract idea into a practical application.
[INDEPENDENT CLAIMS – ADDITIONAL STEPS]
The additional steps in the independent claims, shown not bolded above, recite: receive, from a plurality of secure transaction units, token recovery data sets ([B]), store the token recovery data sets ([C]). When considered individually, they amount to nothing more than receiving data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) into a practical application (see MPEP 2106.05(f)(2)).
Therefore, the additional claim elements of independent claim 1 do not integrate the identified abstract idea into a practical application and the claims remain a judicial exception.
Per Step 2B. Independent claim 1 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when the independent claim is reevaluated as a whole, as an ordered combination under the considerations of Step 2B, the outcome is the same like under Step 2A.2.
Overall, it is concluded that independent claim 1 is deemed ineligible.
Independent claim 8, is rejected under 35 USC 101 because the independent claim is directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application.
The limitations of the independent claim 8 recite an abstract idea, shown in bold below:
[A] A secure transaction unit:
[B] perform electronic payment transactions for a participant in an electronic payment system, the secure transaction unit comprising:
a token storage configured to
[C] store tokens, each token comprising at least a monetary value and a private key of a token-individual key pair;
a communication interface configured to
[D] receive and transmit one or more tokens to one or more other secure transaction units in the electronic payment transaction system to cause an exchange of the one or more tokens between secure transaction units in the electronic transaction system; and
control circuitry coupled with the token storage and the communication interface and arranged to
[E] generate one or more token recovery data sets, each token recovery data set comprising a list of token references that are uniquely assigned to one or more tokens being managed by the secure transaction unit at the time of generating the token recovery data set, each token reference comprising the monetary value of the assigned token and a public key corresponding to the private key of the token-individual key pair; and to
[F] transmit the one or more token recovery data sets to a recovery unit managed by the participant or by a service provider unit.
Independent claim 8 recites: receive and transmit tokens ([D]); generate token recovery datasets ([E]); transmit the token recovery datasets to a token recovery unit ([F]), which, based on the claim language and in view of the application disclosure, represents a process aimed at: “recovering or blocking payment tokens in a tokenized electronic payment system”.
This is a combination that, under its broadest reasonable interpretation, agreements in the form of contracts, legal obligations, sales activities or behaviors, business relationships (e-commerce), which falls under Certain Methods of Organizing Human Activity, i.e., Commercial or Legal Interactions grouping of abstract ideas (see MPEP 2106.04(a)(2)).
Accordingly, it is concluded that independent claim 8 recites an abstract idea that corresponds to a judicial exception.
[INDEPENDENT CLAIMS – QUALIFIERS]
Per Step 2A.2. The identified abstract idea is not integrated into a practical application because the additional elements in the independent claims only amount to instructions to apply the judicial exception to a computer, or are a general link to a technological environment (see MPEP 2106.05(f); MPEP 2106.05(h)).
For example, the added elements “a secure transaction unit,” “token storage,” and “communication interface” recite computing elements at a high level of generality, generally linking the use of a judicial exception to a particular technological environment (see MPEP 2106.05(h)), or merely using a computer as a tool to perform an abstract idea (MPEP 2106.05(f)).
These qualifiers of the independent claims do not preclude from carrying out the identified abstract idea “recovering or blocking payment tokens in a tokenized electronic payment system”, and do not serve to integrate the identified abstract idea into a practical application.
[INDEPENDENT CLAIMS – ADDITIONAL STEPS]
The additional steps in the independent claims, shown not bolded above, recite: performing electronic payment transactions ([B]), storing tokens ([C]). When considered individually, they amount to nothing more than receiving data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) into a practical application (see MPEP 2106.05(f)(2)).
Therefore, the additional claim elements of independent claim 8 do not integrate the identified abstract idea into a practical application and the claims remain a judicial exception.
Per Step 2B. Independent claim 8 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when the independent claim is reevaluated as a whole, as an ordered combination under the considerations of Step 2B, the outcome is the same like under Step 2A.2.
Overall, it is concluded that independent claim 8 is deemed ineligible.
Independent claim 14, is rejected under 35 USC 101 because the independent claim is directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application.
The limitations of the independent claim 14 recite an abstract idea, shown in bold below:
[A] An electronic payment transaction system
[B] perform electronic payment transactions for a participant in an electronic payment system, each secure transaction unit comprising:
a token storage configured to
[C] store tokens, each token comprising at least a monetary value and a private key of a token-individual key pair;
a communication interface configured to
[D] receive and transmit one or more tokens to one or more other secure transaction units in the electronic payment transaction system to cause an exchange of the one or more tokens between secure transaction units in the electronic transaction system; and
control circuitry coupled with the token storage and the communication interface and arranged: to
[E] generate one or more token recovery data sets, each token recovery data set comprising a list of token references that are uniquely assigned to one or more tokens being managed by the secure transaction unit at the time of generating the token recovery data set, each token reference comprising the monetary value of the assigned token and a public key corresponding to the private key of the token-individual key pair; and to
[F] transmit the one or more token recovery data sets to a recovery unit managed by the participant or by a service provider unit;
a plurality of recovery units, each of the plurality of recovery units comprising: a communication interface configured to
[G] receive, from a plurality of secure transaction units, token recovery data sets, and
a computer-readable storage unit coupled to the communication interface and
configured to
[H] store the token recovery data sets,
[I] wherein each token recovery data set comprises one or more token references that are uniquely assigned to one or more tokens being managed by one of the plurality of secure transaction units at the time of generating the respective token recovery data set, each token comprising at least a monetary value and a private key of a token-individual key pair and each token reference comprising at least the monetary value and a public key corresponding to the private key of the token-individual key pair,
wherein the recovery unit is configured, upon a recovery request received via the communication interface from a participant to whom the one of the plurality of secure transaction units is assigned, to
[J] read the token recovery data set associated with that secure transaction unit and to
[K] generate, based on the token references in the token recovery data set, one or more registration requests for a token reference register to block and/or to recover the one or more tokens upon request;
one or more token registers for
[L] registering tokens in the electronic transaction system; and
one or more protocol data registers for
[M] storing protocol data of payment transactions performed between secure transaction units.
Independent claim 14 recites: generate token recovery datasets and transmit to a recovery unit ([E], F]); receive store and read token recovery datasets ([G], [H], [J]); generate registration requests ([K]); and registering the tokens and storing the protocol data ([L], [M]), which, based on the claim language and in view of the application disclosure, represents a process aimed at: “recovering or blocking payment tokens in a tokenized electronic payment system”.
This is a combination that, under its broadest reasonable interpretation, agreements in the form of contracts, legal obligations, sales activities or behaviors, business relationships (e-commerce), which falls under Certain Methods of Organizing Human Activity, i.e., Commercial or Legal Interactions grouping of abstract ideas (see MPEP 2106.04(a)(2)).
Accordingly, it is concluded that independent claim 14 recites an abstract idea that corresponds to a judicial exception.
[INDEPENDENT CLAIMS – QUALIFIERS]
Per Step 2A.2. The identified abstract idea is not integrated into a practical application because the additional elements in the independent claims only amount to instructions to apply the judicial exception to a computer, or are a general link to a technological environment (see MPEP 2106.05(f); MPEP 2106.05(h)).
For example, the added elements “secure transaction unit,” “token storage unit,” and “on a communication interface” recite computing elements at a high level of generality, generally linking the use of a judicial exception to a particular technological environment (see MPEP 2106.05(h)), or merely using a computer as a tool to perform an abstract idea (MPEP 2106.05(f)). Further, the qualifiers “wherein each token recovery data set comprises one or more token references that are uniquely assigned to one or more tokens being managed by one of the plurality of secure transaction units at the time of generating the respective token recovery data set, each token comprising at least a monetary value and a private key of a token-individual key pair and each token reference comprising at least the monetary value and a public key corresponding to the private key of the token-individual key pair”; “wherein the recovery unit is configured, upon a recovery request received via the communication interface from a participant to whom the one of the plurality of secure transaction units is assigned” as applied to the token recovery dataset, and the token recovery unit, are nothing more than (a) descriptive limitations of claim elements, such as describing the nature, structure and/or content of other claim elements, or (b) general links to the computing environment, which amount to instructions to “apply it,” or equivalent (MPEP 2106.05(f)).
These qualifiers of the independent claims do not preclude from carrying out the identified abstract idea “recovering or blocking payment tokens in a tokenized electronic payment system”, and do not serve to integrate the identified abstract idea into a practical application.
[INDEPENDENT CLAIMS – ADDITIONAL STEPS]
The additional steps in the independent claims, shown not bolded above, recite: perform payment transactions, store and receive/transmit tokens ([B]), ([C]), ([D]). When considered individually, they amount to nothing more than receiving data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) into a practical application (see MPEP 2106.05(f)(2)).
Therefore, the additional claim elements of independent claim 14 do not integrate the identified abstract idea into a practical application and the claims remain a judicial exception.
Per Step 2B. Independent claim 14 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when the independent claim is reevaluated as a whole, as an ordered combination under the considerations of Step 2B, the outcome is the same like under Step 2A.2.
Overall, it is concluded that independent claim 14 is deemed ineligible.
Independent claim 17, is rejected under 35 USC 101 because the independent claim is directed to an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application.
The limitations of the independent claim 17 recite an abstract idea, shown in bold below:
[A] A token reference register:
[B] store token references for registering tokens in an electronic payment transaction system,
wherein each token comprises at least a monetary value and a private key of a token-individual key pair;
one or more verification units configured to
[C] verify a registration request received from a secure transaction unit or a recovery unit by:
[D] (i) validating a digital signature of the registration request;
[E] (ii) checking that a command type specified in the registration request is consistent with monetary values of tokens represented by token references in the registration request; and
[F] (iii) determining whether at least one token reference of the registration request is stored in the token reference register;
one or more fraud detection units configured, based on results of the verification units and in response to a recovery request, to
[G] store token references corresponding to tokens to be recovered in a recovery area of the one or more storage units;
[H] wherein each stored token reference in the token reference register comprises the monetary value of the token and a public key corresponding to the private key of the token-individual key pair.
Independent claim 17 recites: verify the registration request ([C]); validating the signature, checking the command type, determining the token reference is stored in the register ([D], [E], [F]), which, based on the claim language and in view of the application disclosure, represents a process aimed at: “recovering or blocking payment tokens in a tokenized electronic payment system”.
This is a combination that, under its broadest reasonable interpretation, agreements in the form of contracts, legal obligations, sales activities or behaviors, business relationships (e-commerce), which falls under Certain Methods of Organizing Human Activity, i.e., Commercial or Legal Interactions grouping of abstract ideas (see MPEP 2106.04(a)(2)).
Accordingly, it is concluded that independent claim 17 recites an abstract idea that corresponds to a judicial exception.
[INDEPENDENT CLAIMS – QUALIFIERS]
Per Step 2A.2. The identified abstract idea is not integrated into a practical application because the additional elements in the independent claims only amount to instructions to apply the judicial exception to a computer, or are a general link to a technological environment (see MPEP 2106.05(f); MPEP 2106.05(h)).
For example, the added elements “verification unit,” “fraud detection unit,” recite computing elements at a high level of generality, generally linking the use of a judicial exception to a particular technological environment (see MPEP 2106.05(h)), or merely using a computer as a tool to perform an abstract idea (MPEP 2106.05(f)). Further, the qualifiers “wherein each token comprises at least a monetary value and a private key of a token-individual key pair;”; “wherein each stored token reference in the token reference register comprises the monetary value of the token and a public key corresponding to the private key of the token-individual key pair.” as applied to the token, are nothing more than (a) descriptive limitations of claim elements, such as describing the nature, structure and/or content of other claim elements, or (b) general links to the computing environment, which amount to instructions to “apply it,” or equivalent (MPEP 2106.05(f)).
These qualifiers of the independent claims do not preclude from carrying out the identified abstract idea “recovering or blocking payment tokens in a tokenized electronic payment system”, and do not serve to integrate the identified abstract idea into a practical application.
[INDEPENDENT CLAIMS – ADDITIONAL STEPS]
The additional steps in the independent claims, shown not bolded above, recite: storing the token references ([G]). When considered individually, they amount to nothing more than receiving data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) into a practical application (see MPEP 2106.05(f)(2)).
Per Step 2B. Independent claim 17 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when the independent claim is reevaluated as a whole, as an ordered combination under the considerations of Step 2B, the outcome is the same like under Step 2A.2.
Overall, it is concluded that independent claim 17 is deemed ineligible.
[DEPENDENT CLAIMS]
Dependent claim 2 recites:
issue and/or manage at least the one of the plurality of secure transaction units.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “recovering or blocking payment tokens in a tokenized electronic payment system”. The elements in this dependent claim are comparable to receiving/transmitting data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) into a practical application (see MPEP 2106.05(f)(2)).
The dependent claim elements have the same relationship to the underlying abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”).
Therefore, dependent claim 2 is deemed ineligible.
Dependent claim 3 recites:
read the token recovery data set upon request from the participant in the electronic payment transaction system to whom the one of a plurality of secure transaction units is assigned.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “recovering or blocking payment tokens in a tokenized electronic payment system”. The elements in this dependent claim are comparable to “receiving or transmitting data over a network, e.g., using the Internet to gather or provide data”, which has been recognized by a controlling court as "well-understood, routine and conventional computing functions" when claimed generically as they are in these dependent claims. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) into a practical application (see MPEP 2106.05(d) II)).
The dependent claim elements have the same relationship to the underlying abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”).
Therefore, dependent claim 3 is deemed ineligible.
Dependent claim 5 recites:
store the token recovery data set as a data record signed with a private key of a token of the one or more tokens that is to be blocked and/or recovered.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “recovering or blocking payment tokens in a tokenized electronic payment system”. The elements in this dependent claim are comparable “storing and retrieving information in/from memory”, which has been recognized by a controlling court as "well-understood, routine and conventional computing functions" when claimed generically as they are in these dependent claims. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) into a practical application (see MPEP 2106.05(d) II)).
The dependent claim elements have the same relationship to the underlying abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”).
Therefore, dependent claim 5 is deemed ineligible.
Dependent claim 6 recites:
update the token recovery data set when:
a registration request is sent to a token reference register; and/or
a payment transaction involving the secure transaction units is performed in the electronic payment transaction system; and/or
an update command is received from the secure transaction units.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “recovering or blocking payment tokens in a tokenized electronic payment system”. The elements in this dependent claim are comparable to “performing repetitive calculations” “re-computing”, which has been recognized by a controlling court as "well-understood, routine and conventional computing functions" when claimed generically as they are in these dependent claims. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) into a practical application (see MPEP 2106.05(d) II)).
The dependent claim elements have the same relationship to the underlying abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”).
Therefore, dependent claim 6 is deemed ineligible.
Dependent claim 7 recites:
generate a registration request concerning a token to be blocked for a token reference register,
wherein the registration request comprises a switch command that is signed with a private key of the financial service provider unit.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “recovering or blocking payment tokens in a tokenized electronic payment system”. The elements in this dependent claim are comparable to receiving/transmitting data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) into a practical application (see MPEP 2106.05(f)(2)).
The dependent claim elements have the same relationship to the underlying abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”).
Therefore, dependent claim 7 is deemed ineligible.
Dependent claim 9 recites:
transmit means one or more registration requests to a token reference register of the electronic transaction system,
wherein each registration request comprises one or more token references, each token reference being uniquely assigned to a token in the electronic payment transaction system,
wherein one or more token references of a registration request comprises the monetary value of the assigned token and a public key corresponding to the private key of the token-individual key pair.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “recovering or blocking payment tokens in a tokenized electronic payment system”. The elements in this dependent claim are comparable to “receiving or transmitting data over a network, e.g., using the Internet to gather or provide data”, which has been recognized by a controlling court as "well-understood, routine and conventional computing functions" when claimed generically as they are in these dependent claims. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) into a practical application (see MPEP 2106.05(d) II)).
The dependent claim elements have the same relationship to the underlying abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”).
Therefore, dependent claim 9 is deemed ineligible.
Dependent claim 10 recites:
transmit token references assigned to tokens of the secure transaction unit and currently residing in the secure transaction unit as the token recovery data set to the recovery unit.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “recovering or blocking payment tokens in a tokenized electronic payment system”. The elements in this dependent claim are comparable to “receiving or transmitting data over a network, e.g., using the Internet to gather or provide data”, which has been recognized by a controlling court as "well-understood, routine and conventional computing functions" when claimed generically as they are in these dependent claims. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) into a practical application (see MPEP 2106.05(d) II))..
The dependent claim elements have the same relationship to the underlying abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”).
Therefore, dependent claim 10 is deemed ineligible.
Dependent claim 11 recites:
generate and transmit a void registration request to the service provider unit or the token reference register, the void registration request being signed with the private key of the token being part of the token recovery data set.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “recovering or blocking payment tokens in a tokenized electronic payment system”. The elements in this dependent claim are comparable to receiving/transmitting data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) into a practical application (see MPEP 2106.05(f)(2)).
The dependent claim elements have the same relationship to the underlying abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”).
Therefore, dependent claim 11 is deemed ineligible.
Dependent claim 12 recites:
generate each token recovery data set as a list of token references of one or more tokens currently managed by the secure transaction unit.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “recovering or blocking payment tokens in a tokenized electronic payment system”. The elements in this dependent claim are comparable to receiving/transmitting data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) into a practical application (see MPEP 2106.05(f)(2)).
The dependent claim elements have the same relationship to the underlying abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”).
Therefore, dependent claim 12 is deemed ineligible.
Dependent claim 13 recites:
generate protocol data comprising token references of tokens involved in payment transactions with other secure transaction units together with a transaction unit group identifier, and to
send the protocol data to a protocol data register in the electronic payment transaction system.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “recovering or blocking payment tokens in a tokenized electronic payment system”. The elements in this dependent claim are comparable to receiving/transmitting data, processing data, storing results or transmitting data that serves merely to implement the abstract idea using computing components for performing computer functions (corresponding to the words “apply it” or an equivalent), or merely uses a computer as a tool to perform the identified abstract idea. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) into a practical application (see MPEP 2106.05(f)(2)).
The dependent claim elements have the same relationship to the underlying abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”).
Therefore, dependent claim 13 is deemed ineligible.
Dependent claim 16 recites:
provide new tokens to the participant upon a recovery request from a participant of the electronic payment transaction unit and a predefined time period being lapsed.
When considered individually, these added claim elements further elaborate on the abstract idea identified in the independent claims, because the dependent claim continues to recite the identified abstract idea: “recovering or blocking payment tokens in a tokenized electronic payment system”. The elements in this dependent claim are comparable to “receiving or transmitting data over a network, e.g., using the Internet to gather or provide data”, which has been recognized by a controlling court as "well-understood, routine and conventional computing functions" when claimed generically as they are in these dependent claims. Thus, it is concluded that these claim elements do not integrate the identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) into a practical application (see MPEP 2106.05(d) II))..
The dependent claim elements have the same relationship to the underlying abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”) as outlined in the independent claims analysis above. Thus, it is readily apparent that the dependent claim elements are not directed to any specific improvements of the independent claims and do not practically or significantly alter how the identified abstract idea would be performed. When considered as a whole, as an ordered combination, the dependent claim further elaborates on the previously identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”).
Therefore, dependent claim 16 is deemed ineligible.
Dependent claims 4, 15 recite:
wherein each token recovery data set comprises one or more token references that are uniquely assigned to the one or more tokens at the time of generating the token recovery data set, the recovery data set preferably further comprising a secure transaction unit identifier for uniquely identifying the at least one secure transaction unit.
wherein each registration request comprises a switch command that is signed with a private key of the recovery unit.
These further elements in the dependent claims do not perform any claimed method steps. They describe the nature, structure and/or content of other claim elements – the token recovery data set; the registration request – and as such, cannot change the nature of the identified abstract idea (“recovering or blocking payment tokens in a tokenized electronic payment system”), from a judicial exception into eligible subject matter, because they do not represent significantly more (see MPEP 2106.07). The nature, form or structure of the other claim elements themselves do not practically or significantly alter how the identified abstract idea would be performed and do not provide more than a general link to a technological environment.
Therefore, dependent claims 4, 15 are deemed ineligible.
When the dependent claims are considered as a whole, as an ordered combination, the claim elements noted above appear to merely apply the abstract concept to a technical environment in a very general sense. The most significant elements, which form the abstract concept, are set forth in the independent claims. The fact that the computing devices and the dependent claims are facilitating the abstract concept is not enough to confer statutory subject matter eligibility, since their individual and combined significance do not transform the identified abstract concept at the core of the claimed invention into eligible subject matter. Therefore, it is concluded that the dependent claims of the instant application, considered individually, or as a as a whole, as an ordered combination, do not amount to significantly more (see MPEP 2106.07(a)II).
In sum, Claims 1-17 are rejected under 35 USC 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 112(a)
Written Description (Possession)
The following is a quotation of 35 U.S.C. 112(a):
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 USC 112(a) as failing to comply with the written description requirement. The claim 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(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 6, 8, 14, 19 are rejected for reciting the subject matter “calculation of a real time probable amount” which is not adequately described in the specification, in the drawings or in the original set of claims to satisfy the requirements as described in MPEP 2163.05 V: “While there is a presumption that an adequate written description of the claimed invention is present in the specification as filed, In re Wertheim, 541 F.2d 257, 262, 191 USPQ 90, 96 (CCPA 1976), a question as to whether a specification provides an adequate written description may arise in the context of an original claim. An original claim may lack written description support when (1) the claim defines the invention in functional language specifying a desired result but the disclosure fails to sufficiently identify how the function is performed or the result is achieved …” Further "Even if a claim is supported by the specification, the language of the specification, to the extent possible, must describe the claimed invention so that one skilled in the art can recognize what is claimed. The appearance of mere indistinct words in a specification or a claim, even an original claim, does not necessarily satisfy that requirement. "Enzo Biochem, Inc. v. Gen-Probe, Inc., 323 F.3d 956, 968, 63 USPQ2d 1609, 1616 (Fed. Cir. 2002) (holding that generic claim language appearing in ipsis verbis in the original specification did not satisfy the written description requirement).”
In the instant situation, the application specification attempts to describe the subject matter “calculation of a real time probable amount” at [0010] – “In an embodiment of the present disclosure, the calculation of the real time probable amount is based on a real time bidding process.” No further information, like calculation method or algorithm is provided; i.e. HOW the function is performed. In addition, the specification verbally recites (ipsis verbis) the language of the claim. While the specification discloses the function, it discloses neither the necessary structure, nor the necessary algorithm to perform the function, i.e. HOW the calculation is performed.
The question is, given the disclosure, would a POSITA conclude that the inventor was in possession of the subject matter “calculation of a real time probable amount” in order to cause a system to perform the functions? The answer is clearly “no.” It looks as if the invention recites subject matter that have neither structure nor algorithm.
Therefore, the subject matter was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor(s), at the time the application was filed, had possession of the claimed invention.
For examination purpose, Examiner will interpret “calculation of a real time probable amount” as any type of calculation, which is what the prior art of record discloses. The reference is provided for compact prosecution purpose.
The remainder of the claims are rejected by virtue of dependency. The reference is provided for compact prosecution purpose.
Claim Rejections - 35 USC § 112(a)
Written Description (Possession)
The following is a quotation of 35 U.S.C. 112(a):
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 2-3 are rejected under 35 USC 112(a) as failing to comply with the written description requirement. The claim 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(s), at the time the application was filed, had possession of the claimed invention.
Claims 1, 6, 8, 14, 19 are rejected for reciting the subject matter “issue and/or manage …” which is not adequately described in the specification, in the drawings or in the original set of claims to satisfy the requirements as described in MPEP 2163.05 V: “While there is a presumption that an adequate written description of the claimed invention is present in the specification as filed, In re Wertheim, 541 F.2d 257, 262, 191 USPQ 90, 96 (CCPA 1976), a question as to whether a specification provides an adequate written description may arise in the context of an original claim. An original claim may lack written description support when (1) the claim defines the invention in functional language specifying a desired result but the disclosure fails to sufficiently identify how the function is performed or the result is achieved …” Further "Even if a claim is supported by the specification, the language of the specification, to the extent possible, must describe the claimed invention so that one skilled in the art can recognize what is claimed. The appearance of mere indistinct words in a specification or a claim, even an original claim, does not necessarily satisfy that requirement. "Enzo Biochem, Inc. v. Gen-Probe, Inc., 323 F.3d 956, 968, 63 USPQ2d 1609, 1616 (Fed. Cir. 2002) (holding that generic claim language appearing in ipsis verbis in the original specification did not satisfy the written description requirement).”
In the instant situation, the application specification attempts to describe the subject matter “issue and/or manage …” at [0097] – “A token “managed by” a token transaction unit, such as the above-described secure wallets, is a token that resides in a memory (storage) space.” No further information, like calculation method or algorithm is provided; i.e. HOW the function is performed. In addition, the specification verbally recites (ipsis verbis) the language of the claim. While the specification discloses the function, it discloses neither the necessary structure, nor the necessary algorithm to perform the function, i.e. HOW the calculation is performed.
The question is, given the disclosure, would a POSITA conclude that the inventor was in possession of the subject matter “issue and/or manage …” in order to cause a system to perform the functions? The answer is clearly “no.” It looks as if the invention recites subject matter that have neither structure nor algorithm.
Therefore, the subject matter was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor(s), at the time the application was filed, had possession of the claimed invention.
For examination purpose, Examiner will interpret “issue and/or manage …” as any type of calculation, which is what the prior art of record discloses. The reference is provided for compact prosecution purpose.
The remainder of the claims are rejected by virtue of dependency. The reference is provided for compact prosecution purpose.
The prior art made of record and not relied upon which, however, is considered pertinent to applicant's disclosure:
US 20010021927 A1 Laurent, Christophe et al. Electronic wallet system - The electronic wallet system comprises a plurality of devices interconnected through a local network and capable of conducting electronic business transaction on an open network (40). Each device contains a smart card reader. A plurality of smart cards (31-3p) represent the electronic purses of the system. One of the devices comprises an entity called the server which contains a list of purses liable to receive tokens from others purses of the system. The tokens transferred between purses are stored temporally by said server.
US 20230050481 A1 Nagaraja; Vinjith et al. DISTRIBUTED PRIVATE KEY RECOVERY - A method performed by a user device is disclosed. The method comprising generating a secret and measuring a biometric template of a user operating the user device. The method then generates a plurality of secret shares of the secret and of the biometric template. The user device then transmits the secret shares of the secret and of the biometric template to a plurality of recovery devices. After, the user device may then initiate a recovery of the secret and measure a biometric measurement of the user. Data of the biometric measurement may be transmitted to the plurality of recovery devices, where the recovery devices perform a partial computation. The user device use the plurality of partial computations to determine a match between the biometric template and the biometric measurement. If the two biometrics match, the user device can reconstruct the secret using shares of the secret from the recovery devices.
US 20200242232 A1 Machani; Salah E. USER ACCOUNT RECOVERY TECHNIQUES USING SECRET SHARING SCHEME WITH TRUSTED REFEREE - Account recovery control systems and methods are provided to support a self-service account recovery process for registered users of an information system. Account recovery protocols implement a secret sharing scheme between trusted referees and registered users of the information system to enable a registered user to regain access to the user's registered account when one or more authentication factors of the registered user are lost (e.g., forgotten, misplaced, damaged, stolen, etc.).
US 20240135364 A1 AGUDELO; Charly et al. METHOD FOR TRANSFERRING DATA OVER A BLOCKCHAIN NETWORK FOR DIGITAL TRANSACTIONS - The present disclosure relates to methods and systems for transferring data in a blockchain network. Specifically, the present disclosure relates to computer-implemented methods for creating and encrypting electronic wallets in blockchain networks and systems and methods configured to carry out data transactions in the blockchain network. For example, the present disclosure describes a method for creating and encrypting an electronic wallet of a blockchain network, comprising a step of obtaining the electronic wallet by a computing device from a user. The electronic wallet may include a private password data, a public password data, and a wallet identification data. The method has steps wherein the private password data, the public password data and/or the wallet identification data are encrypted with random salt data. The encrypted data is transmitted via an API to computing modules having functions of data storage, processing of requests, and blockchain network access. Moreover, the method may include steps wherein the electronic wallet may be retrieved or restored, and steps in which the private password data can be decrypted to enable the use of transactional functions of the electronic wallet. Upon decrypting the encrypted private password, the computing device may store the private password data in a memory module, e.g., in a volatile memory module.
US 20220393881 A1 Ow; Benedict et al. AUTONOMOUS EXCHANGE VIA ENTRUSTED LEDGER DIGITAL SIGNATURE MANAGEMENT AND ADMINISTRATION - A signature is a unique identifier that is created by the signor or signatory for the purpose of acknowledging or otherwise providing acceptance of a transaction such as signing a check, contract or other transactional vehicle. The system and method disclosed herein provides for the authenticating and tracking of each signature within a digital environment such as a blockchain by applying a unique identifier to each signature. The identifier created for the signature is then attached to the vehicle being signed such as a document or a contract, which is then also assigned an identifier to enable the permanent association of the signature and the vehicle that was signed. These unique identifiers ensure that the signature and the associated vehicle or correspondence being signed cannot be copied, separated or otherwise used more than a single time during a single signing event.
US 20240154800 A1 Fernando; Gabriel Emilio et al. TOKEN RECOVERY - To support token recovery at a token management system, a custodial token platform may receive via a user interface, an identifier of a first blockchain transaction that is associated with a crypto token that is not supported by the custodial token platform and that is to be recovered from an inbound address of the custodial token platform. Information associated with the first blockchain transaction may be displayed, and the user interface may receive an indication of a user address associated with a user and that is external to the custodial token platform. The custodial token platform may verify the user address using a signed message and may broadcast, subsequent to verifying that the message is signed, a second blockchain transaction configured to transfer the crypto token from the inbound address to the user address.
US 20190324958 A1 Ow; Benedict et al. AUTONOMOUS EXCHANGE VIA ENTRUSTED LEDGER IMMUTABLE DISTRIBUTED DATABASE - An Autonomous Exchange via Entrusted Ledger (AXEL) blockchain is discussed herein. The AXEL blockchain enables users to perform transactions in a private setting while enabling the transaction records thereof to be verified by other network users without publicly divulging the contents or details of the transaction records. The token identification system and method allows the tokens to carry an immutable identification to prevent negative blockchain occurrences such as double spending. A payment methodology allowing integration of external financial institutions with user owned and managed wallet. The AXEL blockchain can also interface with and utilize a distributed database to create an immutable record of each transaction while providing a complete backup of the transactions that occur within the system and on the AXEL blockchain.
US 20210349988 A1 LOBBAN; Tyrone et al. SYSTEMS AND METHODS FOR DECENTRALIZED RECOVERY OF IDENTITY ATTRIBUTES - Systems and methods for decentralized recovery of identity attributes are disclosed. In one embodiment, a method for decentralized storage of identity data may include: (1) receiving, at an identity management computer program executed by a computer processor, identity data from a user electronic device; (2) parsing, by the identity management computer program, the identity data into a plurality of portions; (3) mapping, by the identity management computer program, each portion to one of a plurality of storage locations; and (4) storing, by the identity management computer program, the plurality of portions to the plurality of storage locations based on the mapping.
Response to Amendments/Arguments
Applicant’s submitted remarks and arguments have been fully considered.
Applicant disagrees with the Office Action conclusions and asserts that the presented claims fully comply with the requirements of 35 U.S.C. § 101 regrading judicial exceptions. Further, Applicant is of the opinion that the prior art fails to teach Applicant’s invention.
Examiner respectfully disagrees in both regards.
With respect to Applicant’s Remarks as to the claims Objection.
After further consideration, the objection is withdrawn.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 101.
Applicant submits:
a. The pending claims are not directed to an abstract idea.
b. The identified abstract idea is integrated into a practical application.
c. The pending claims amount to significantly more.
Furthermore, Applicant asserts that the Office has failed to meet its burden to identify the abstract idea and to establish that the identified abstract idea is not integrated into a practical application and that the pending claims do not amount to significantly more.
Examiner responds – The arguments have been considered in light of Applicants’ amendments to the claims. The arguments ARE NOT PERSUASIVE. Therefore, the rejection is maintained.
The pending claims, as a whole, are directed to an abstract idea not integrated into a practical application. This is because (1) they do not effect improvements to the functioning of a computer, or to any other technology or technical field (see MPEP 2106.05 (a)); (2) they do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or a medical condition (see the Vanda memo); (3) they do not apply the abstract idea with, or by use of, a particular machine (see MPEP 2106.05 (b)); (4) they do not effect a transformation or reduction of a particular article to a different state or thing (see MPEP 2106.05 (c)); (5) they do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the identified abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designated to monopolize the exception (see MPEP 2106.05 (e) and the Vanda memo).
In addition, the pending claims do not amount to significantly more than the abstract idea itself.
As such, the pending claims, when considered as a whole, are directed to an abstract idea not integrated into a practical application and not amounting to significantly more.
More specific:
Applicant submits “However, properly construed in light of the specification, the amended claims are directed to a specific technical improvement in the way a computer-implemented token system operates, not to the business concept of token recovery.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
Base on the claim language (“A recovery unit in an electronic payment transaction system …”) and in light of the specification (“[0002] The invention relates to a recovery unit. The invention further relates to a secure transaction unit. The invention also relates to a token reference register. The invention also relates to an electronic transaction system in particular an electronic payment transaction system.”), the claims are directed to commercial activity, specifically to secure payment transactions.
Thus, the rejection is proper and has been maintained.
Applicant submits “Under MPEP 2106.04(d), claims focused on improved computer security and data-integrity mechanisms are generally not directed to the judicial exceptions, such that the current claims provide a patent eligible solution to a technical problem.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
MPEP 2106.05(a) discloses that the additional claim elements bring about “improvements to the functioning of a computer, or any other technology or technical field.” Improving electronic payment transaction systems is a pure BUSINESS problem, rather than a technology or technical field problem. As such, the limitations which have not been deemed as being part of the identified abstract idea, i.e., the “additional limitations,” do not integrate the identified abstract idea into a practical application, as disclosed by MPEP 2106.05(a).
Thus, the rejection is proper and has been maintained.
Applicant submits “Even if "recovering payment tokens" could be viewed at a high level as an abstract concept, the independent claims recite additional elements that integrate any such concept into a particular practical application. For example, independent claim 1 requires a recovery unit that receives and stores a plurality of token recovery data sets, each token recovery data set "uniquely assigned to one or more tokens being managed by one of a plurality of secure transaction units at the time of generating the respective token recovery data set," and the recovery unit reads the token recovery data set to block and/or recover tokens upon request. The specification explains that "managed by" refers to tokens in or under control of a specific secure transaction unit or participant, and that reading the token recovery data set causes either blocking of existing token references or provision of newly issued tokens having the same monetary value, in response to a participant's explicit recovery request.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
MPEP 2106.04(d)(1) discloses:
An important consideration to evaluate when determining whether the claim as a whole integrates a judicial exception into a practical application is whether the claimed invention improves the functioning of a computer or other technology .... In short, first the specification should be evaluated to determine if the disclosure provides sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art .... Second, if the specification sets forth an improvement in technology. the claim must be evaluated to ensure that the claim itself reflects the disclosed improvement. (Emphasis added)
That is, the claimed invention may integrate the judicial exception into a practical application by demonstrating that it improves the relevant existing technology although it may not be an improvement over well-understood, routine, conventional activity. (Emphasis added)
Thus, the rejection is proper and has been maintained.
Applicant submits “The claims require using these unconventional token references in concert with a token reference register and protocol data register for fraud detection and surveillance, while keeping actual tokens in offline secure transaction units and preserving user anonymity. These features represent a non-conventional arrangement of components that improves security and traceability in an electronic coin system, and thus amount to significantly more than any alleged abstract idea.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
MPEP 2106.05(a) discloses that the additional claim elements bring about “improvements to the functioning of a computer, or any other technology or technical field.” Improving electronic payment transaction systems is a pure BUSINESS problem, rather than a technology or technical field problem. As such, the limitations which have not been deemed as being part of the identified abstract idea, i.e., the “additional limitations,” do not integrate the identified abstract idea into a practical application, as disclosed by MPEP 2106.05(a).
Thus, the rejection is proper and has been maintained.
Applicant submits “Likewise, the current claims describe a specific way to solve the problem of token recovery where security and anonymity are maintained. The recited "rules" of the current claims are accordingly analogous to those of McRo and realize an improvement to technology in a manner analogous to McRo, rather than merely claiming the idea of a solution or outcome, and are not directed to an abstract idea.”
Examiner has carefully considered, but doesn’t find Applicant’s arguments persuasive.
First, “a specific way to solve the problem” is not an eligibility criterion (see MPEP 2106.04-07).
Second, it is not proper practice to go and find a particular Example from the Office published material and use the specific arguments from that Example to determine eligibility of a particular claimed invention, unless the particular claimed invention uniquely matches (i.e. a case that involves identical or similar facts or similar legal issues) the subject matter claimed in that particular Example, which in the instant situation it does not. The Office periodically publishes Examples with detailed analyses only to serve as rational and argumentation models to determine eligibility. Each application has to be considered on its own merits. Examples provided by the Office are nothing more than the name suggests: EXAMPLES, that are to be considered or not, as they are neither laws, nor rules, nor regulations.
Thus, the rejection is proper and has been maintained.
It follows from the above that there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself. Therefore, the rejection under 35 U.S.C. § 101 is maintained.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 112(a) and 35 USC § 112(b), as a Result of Interpreting the Claims under 35 USC § 112(f).
The rejections are withdrawn, as a result of the amendments.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 112(a) Possession.
The rejections are withdrawn, as a result of the amendments.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 112(d).
The rejections are withdrawn, as a result of the amendments.
With respect to Applicant’s Remarks as to the claims being rejected under 35 USC § 103.
The rejection is withdrawn, as a result of the amendments.
Examiner has reviewed and considered all of Applicant’s remarks. The rejection is maintained, necessitated by the extensive amendments and by the fact that the rejection of the claims under 35 USC § 101 and under 35 USC § 101 have not been overcome.
Conclusion
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 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.
Inquiries
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Radu Andrei whose telephone number is 313.446.4948. The examiner can normally be reached on Monday – Friday 8:30am – 5pm EST. 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.
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.
As disclosed in MPEP 502.03, communications via Internet e-mail are at the discretion of the applicant. Without a written authorization by applicant in place, the USPTO will not respond via Internet e-mail to any Internet correspondence which contains information subject to the confidentiality requirement as set forth in 35 U.S.C. 122. A paper copy of such correspondence will be placed in the appropriate patent application. The following is a sample authorization form which may be used by applicant:
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with me concerning any subject matter of this application by electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center information webpage. Status information for unpublished applications is available to registered users through Patent Center information webpage only.
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.
Any response to this action should be mailed to:
Commissioner of Patents and Trademarks
P.O. Box 1450
Alexandria, VA 22313-1450
or faxed to 571-273-8300
/Radu Andrei/
Primary Examiner, AU 3698