Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This is first office action on the merits in response to application filed on 02/03/2024.
Claims 1-18 have been cancelled. Claims 19-36 are currently pending and have been examined.
Priority
Applicant's claim for the benefit of PCT Application No. PCT/EP2022/025325 filed on 07/12/2022 is acknowledged. Applicant's claim for the benefit of Germany Application No. DE10 2021 004 020.1 filed on 08/04/2021 is acknowledged.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 02/03/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
a token reference register of the transaction system, receiving a registration request comprising at least one token reference uniquely assigned to a token of the transaction system in Claims 19 and A token reference register for a transaction system, configured to perform the method steps according to claim 19 in Claim 33;
verifying, using a verification unit of the token reference register, whether the at least one token reference of the received registration request is stored in the token reference register in Claim 19 and one or more verification units for verifying received registration requests in Claims 24 and 34;
storing the at least one token reference in a memory unit of the token reference register in order to register the token uniquely assigned to this token reference in the transaction system in Claim 19 and the one or more memory units for storing token references for registering the token in the transaction system in Claims 24 and 34;
wherein the registration request is received by a subscriber unit, in particular a secure element in Claim 23 and subscriber unit: creating a new private part of a token-individual key pair, applying a cryptographic function to the new private part in order to obtain a public part of the token-individual key pair for the switched token; creating the registration request using the token reference for the token to be switched and the public part of the token-individual key pair for the switched token in Claim 29;
subscriber unit: creating a new private part of a token-individual key pair, applying a cryptographic function to the new private part to obtain a corresponding public part of the token-individual key pair for the connected token; calculating the token value for the connected token by forming the sum of the respective token values of the tokens to be connected; creating a token reference for the connected token comprising the calculated token value and the public part of the token-individual key pair for the connected token; and creating the registration request using each token reference of the tokens to be connected and the token reference for the connected token in Claim 31;
one or more check units for checking the received registration request, in particular for syntactic correctness and/or sum of the token values in the registration request, before the verification; and/or a check unit for checking a total token value of all token values of registered tokens of the transaction system in Claims 24 and 34;
a new registration unit for registering new tokens or deleted tokens as implemented by a token issuer in Claims 24 and 34 and a register layer with a token reference register according to claim 33 for registering token references in Claim 36;
a direct transaction layer with a plurality of subscriber units which are designed at least partially as a secure element which is configured as a subscriber unit of a transaction system, for the direct exchange of tokens with a further subscriber unit in Claim 36
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. Therefore, by choosing to use a means-plus-function limitation and invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant limits that claim limitation to the disclosed structure, i.e., implementation by hardware or the combination of hardware and software, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 19 limitations “a token reference register of the transaction system, receiving a registration request comprising at least one token reference uniquely assigned to a token of the transaction system,” “verifying, using a verification unit of the token reference register, whether the at least one token reference of the received registration request is stored in the token reference register,” and “storing the at least one token reference in a memory unit of the token reference register in order to register the token uniquely assigned to this token reference in the transaction system” and invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. No correlation between the structure and the function is defined in the specification. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claim 23 limitation “wherein the registration request is received by a subscriber unit, in particular a secure element” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. No correlation between the structure and the function is defined in the specification. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claims 24 and 34 limitations “one or more verification units for verifying received registration requests,” “the one or more memory units for storing token references for registering the token in the transaction system,” “one or more check units for checking the received registration request, in particular for syntactic correctness and/or sum of the token values in the registration request, before the verification; and/or a check unit for checking a total token value of all token values of registered tokens of the transaction system,” limitation invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. No correlation between the structure and the function is defined in the specification. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claim 29 limitation “subscriber unit: creating a new private part of a token-individual key pair, applying a cryptographic function to the new private part in order to obtain a public part of the token-individual key pair for the switched token; creating the registration request using the token reference for the token to be switched and the public part of the token-individual key pair for the switched token” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. No correlation between the structure and the function is defined in the specification.
Claim 31 limitation “subscriber unit: creating a new private part of a token-individual key pair, applying a cryptographic function to the new private part to obtain a corresponding public part of the token-individual key pair for the connected token; calculating the token value for the connected token by forming the sum of the respective token values of the tokens to be connected; creating a token reference for the connected token comprising the calculated token value and the public part of the token-individual key pair for the connected token; and creating the registration request using each token reference of the tokens to be connected and the token reference for the connected token” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. No correlation between the structure and the function is defined in the specification.
Claim 33 limitation “A token reference register for a transaction system, configured to perform the method steps according to claim 19” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. No correlation between the structure and the function is defined in the specification. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Claim 36 limitations “a direct transaction layer with a plurality of subscriber units which are designed at least partially as a secure element which is configured as a subscriber unit of a transaction system, for the direct exchange of tokens with a further subscriber unit” and “a register layer with a token reference register according to claim 33 for registering token references” invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. No correlation between the structure and the function is defined in the specification
Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph. Claims 20-34 and 36 are rejected based on rejected base claim 19.
Applicant may:
(a) Amend the claim so that the claim limitations will no longer be interpreted as limitations under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claim Rejections - 35 USC § 112(a)
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 19, 23-24, 29, 31, 33-34, and 36 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention. As mentioned above, the disclosure does not provide adequate description for the limitations that invoke 112(f). The specification does not demonstrate that applicant has made an invention that achieves the claimed function because the invention is not described in sufficient detail that one of ordinary skill in the art at the time the application was filed can reasonably conclude that the inventor had possession of the claimed invention.
Claims 20-34 and 36 are rejected based on rejected base claim 19.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 19-36 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-15 of copending Application No. 18/610,584 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because both applications involve token reference register for registering tokens comprising a public key corresponding to the private key of the token-individual key pair.
Claims 19-36 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 17-32 of copending Application No. 18/689,662 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because both applications involve creating a registration request for a token reference register of the transaction system at least comprising a token reference uniquely assigned to the token to be transmitted as a token reference to be registered, wherein the token reference comprises at least one token value of the token and the generated public part of the token-specific key pair as token reference elements and a token reference assigned to a token of the first subscriber unit as a previously registered token reference.
Claims 19-36 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-15 of copending Application No. 18/678,636 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because both applications involve means for transmitting registration requests to a token reference register of the electronic transaction system for registering the tokens in the electronic payment transaction system and control means configured to generate single registration requests comprising only single modification-commands concerning a modification of a token of the secure transaction unit.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
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 19, 33, and 35 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Under Step 1 of the Section 101 analysis, claim 19 is a method, claim 33 is directed to a token reference register, and claim 35 is directed to a secure element (a process, an apparatus, and an apparatus).
Under Step 2A Prong One, Claims 19 and 33 recite: receiving, in a token reference register of the transaction system, a registration request comprising at least one token reference uniquely assigned to a token of the transaction system, wherein the token reference comprises at least the token value of the token and a public part of the token-individual key pair as token reference elements, wherein the public part of the token-individual key pair was obtained by applying a cryptographic one-way function to the private part of the token-individual key pair of the token, verifying, using a verification unit of the token reference register, whether the at least one token reference of the received registration request is stored in the token reference register, and storing the at least one token reference in a memory unit of the token reference register in order to register the token uniquely assigned to this token reference in the transaction system if it is established in the verification step that the at least one token reference of the received registration request is not stored in the token reference register.
Under Step 2A Prong One, Claim 35 recites: a secure element which is configured as a subscriber unit of a transaction system, for the direct exchange of tokens with a further subscriber unit, wherein each token of the transaction system comprises at least one token value and a private part of a token-individual key pair as token elements, for creating a modified token from an existing token to be modified, wherein a token reference uniquely assigned to the modified token of the transaction system comprises at least the token value of the token and a public part of the token-individual key pair as token reference elements, wherein the public part of the token-individual key pair is obtained by applying a cryptographic one-way function to the private part of the token-individual key pair of the token, and for providing a registration request to a token reference register of the transaction system, wherein the registration request has at least the token reference uniquely assigned to the token of the transaction system.
Claims 19 and 33 as drafted include language (see underlined language above) that recite an abstract idea of registering tokens for an electronic transaction system, which falls under the abstract idea of certain methods of organizing human activity (i.e., commercial or legal interactions).
Claim 35 as drafted include language (see underlined language above) that recite an abstract idea of registration request of tokens for an electronic transaction system, which falls under the abstract idea of certain methods of organizing human activity (i.e., commercial or legal interactions).
Under Step 2A Prong Two, the additional claim element(s), considered individually, do not apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception and in a manner that integrates the exception into a practical application of the exception. The additional claim elements(s) “a token reference register,” “cryptographic one-way function,” “verification unit,” “memory unit” “a secure element” and “subscriber unit,” generally “apply” the concept of registering tokens for an electronic transaction system after receiving the registration request. The claimed computer components are recited at a high level of generality and are merely invoked as tools to perform the abstract idea. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Under Step 2A Prong Two, the additional claim element(s), considered in combination, do not apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception and in a manner that integrates the exception into a practical application of the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a token reference register, cryptographic one-way function, verification unit, memory unit, a secure element, and subscriber unit amounts to no more than applying the abstract idea of registering tokens for an electronic transaction system after receiving the registration request. Mere instructions to apply an exception using a generic component cannot provide an inventive concept. The claim is not patent eligible.
Under Step 2B, the additional claim element(s), considered individually and in combination, do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself for similar reasons outlined under Step 2A Prong Two.
A similar analysis can be applied to dependent claim 20 which claims “wherein in the verification step by the verification unit of the token reference register, the following is also established: whether the token reference can be assigned to a token in the received registration request; and/or whether the received registration request is syntactically correct; and/or whether a sum of token values of all token references within the registration request is zero” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 21 which claims “wherein the public key part of the token-individual key pair of the token reference simultaneously is a database index in the token reference register” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 22 which claims “wherein the received registration request is signed with the private part of the token-individual key pair in order to be able to verify an assignment of the token reference to the token” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 23 which claims “wherein the registration request is received by a subscriber unit, in particular a secure element; and/or the registration request relates to a modification of at least one previously registered token, and at least the token reference of the at least one previously registered token and the at least one token reference of the token to be registered, which is the modification of the previously registered token” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claims 24 and 34 which claims “wherein the token reference register also comprises: the one or more memory units for storing token references for registering the token in the transaction system; and/or the one or more verification units for verifying received registration requests; and/or one or more check units for checking the received registration request, in particular for syntactic correctness and/or sum of the token values in the registration request, before the verification; and/or a check unit for checking a total token value of all token values of registered tokens of the transaction system; and/or a new registration unit for registering new tokens or deleted tokens as implemented by a token issuer” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 25 which claims “wherein the token reference comprises at least one of the further token reference elements: a count value, an identity of a subscriber unit or of an owner of the subscriber unit, and/or a pseudonym of a subscriber entity or of an owner of the subscriber unit” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 26 which claims “wherein the registration request is a splitting of a token, and the registration request comprises a token reference of the token to be split and a token reference of the split token to be registered” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 27 which claims “wherein for splitting the token the following method steps are carried out in a subscriber unit: creating a new private part of a token-individual key pair for a first split token, applying a cryptographic function to the new private part in order to obtain a corresponding public part of the token-individual key pair for the first split token; creating a new private part of a token-individual key pair for a second split token; applying a cryptographic function to the new private part to obtain a corresponding public part of the token-individual key pair for the second split token; splitting the token value into a first token part value and into a second token part value, wherein the sum of the first token part value and the second token part value corresponds to the token value of the token to be split; creating a token reference for the first split token comprising the first token part value and the public part of the token-individual key pair of the first split token; creating a token reference for the second split token comprising the second token part value and the public part of the token-individual key pair of the second split token; and creating the registration request using the token reference of the token to be split, the token reference for the first split token and the token reference for the second split token” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 28 which claims “wherein the registration request relates to a switching of a token to be switched to a switched token, and the registration request comprises a token reference of the token to be switched and the token reference of the switched token” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 29 which claims “wherein for switching the token the following method steps are carried out in a subscriber unit: creating a new private part of a token-individual key pair, applying a cryptographic function to the new private part in order to obtain a public part of the token-individual key pair for the switched token; creating the registration request using the token reference for the token to be switched and the public part of the token-individual key pair for the switched token” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 30 which claims “wherein the registration request is a connection of at least two tokens and comprises a token reference of the connected token and a token reference of each of the tokens to be connected” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 31 which claims “wherein for connecting the token the following method steps are carried out in a subscriber unit: creating a new private part of a token-individual key pair, applying a cryptographic function to the new private part to obtain a corresponding public part of the token-individual key pair for the connected token; calculating the token value for the connected token by forming the sum of the respective token values of the tokens to be connected; creating a token reference for the connected token comprising the calculated token value and the public part of the token-individual key pair for the connected token; and creating the registration request using each token reference of the tokens to be connected and the token reference for the connected token” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 32 which claims “wherein the registration request has been sent by a token issuer, and wherein the registration request relates to a creation of a token or a deletion of a token” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 36 which claims “a register layer with a token reference register according to claim 33 for registering token references; and a direct transaction layer with a plurality of subscriber units which are designed at least partially as a secure element which is configured as a subscriber unit of a transaction system, for the direct exchange of tokens with a further subscriber unit, wherein each token of the transaction system comprises at least one token value and a private part of a token- individual key pair as token elements, for creating a modified token from an existing token to be modified, wherein a token reference uniquely assigned to the modified token of the transaction system comprises at least the token value of the token and a public part of the token- individual key pair as token reference elements, wherein the public part of the token-individual key pair is obtained by applying a cryptographic one-way function to the private part of the token-individual key pair of the token, and for providing a registration request to a token reference register of the transaction system, wherein the registration request has at least the token reference uniquely assigned to the token of the transaction system” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
Claim Rejections - 35 USC § 102(a)(1)
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim 35 is rejected under 35 U.S.C. 102(a)(1) as being anticipated by Fritzhanns (DE102018009950A1).
Regarding Claim 35, Fritzhanns ‘950 teaches a secure element which is configured as a subscriber unit of a transaction system, for the direct exchange of tokens with a further subscriber unit, wherein each token of the transaction system comprises at least one token value and a private part of a token-individual key pair as token elements, for creating a modified token from an existing token to be modified, wherein a token reference uniquely assigned to the modified token of the transaction system comprises at least the token value of the token and a public part of the token-individual key pair as token reference elements, wherein the public part of the token-individual key pair is obtained by applying a cryptographic one-way function to the private part of the token-individual key pair of the token, and for providing a registration request to a token reference register of the transaction system, wherein the registration request has at least the token reference uniquely assigned to the token of the transaction system (Paragraphs 0072 and 0030-0032 teach a security element may be provided in a participant's terminal device for transmission purposes and is preferably special software, particularly in the form of a secure runtime environment within an end-device operating system, known as a Trusted Execution Environment (TEE); alternatively, the security element can be, for example, special hardware, particularly in the form of a secure hardware platform module (Trusted Platform Module, TPM) or an embedded security module (eUICC, eSIM); the security element provides a trusted environment and also secures, for example, a machine-to-machine (M2M) application; the partial amount is genuinely signed, meaning without any additional obfuscation, because otherwise a recipient of the partial amount cannot verify its authenticity and correct derivation; in the subsequent verification process, the calculated genuine signature is then compared with the received genuine signature, thus verifying possession of the monetary amount; in this way, the authenticity of the received genuine signature can be verified, and it is ensured that the participant-generated secret was actually generated by the participant; therefore, the partial amount is valid; finally, the eMD is calculated using the participant-generated public key, the signed unblinded eMD, the publisher information, and a public key of the signature publisher, and the calculated eMD is compared with the received eMD, and the authenticity of the blind signature is verified if the calculated eMD matches the received eMD; during this calculation and verification process, it is not possible to infer the participant-generated serial number of the eMD, so although the blind signature can be verified, the full monetary value of the eMD cannot be decrypted; only the partial amount confirmed with the genuine signature can be transferred in this way and further used by the recipient (participant, auditing body)).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 19-34 and 36 are rejected under 35 U.S.C. 103 as being unpatentable over Fritzhanns (DE102018009950A1) in view of Fritzhanns (DE102018009945A1).
Regarding Claims 19, Fritzhanns ‘950 teaches a method for registering tokens of an electronic transaction system, wherein each token of the transaction system comprises at least a token value and a private part of a token-individual key pair as token elements (Paragraph 0008 teaches the object of the present invention is therefore to create a method and a system in which it is transparently verifiable whether a signature issuer of a blind signature has actually signed an eMD; furthermore, the monetary value (coin value) of a signed eMD should be easily divisible without a blind signature losing its validity), the method comprising the method steps of: receiving, in a token reference register of the transaction system, a registration request comprising at least one token reference uniquely assigned to a token of the transaction system, wherein the token reference comprises at least the token value of the token and a public part of the token-individual key pair as token reference elements (Paragraphs 0023 and 0039 teach the eMD is preferably the result of a scatter value function from a subscriber-generated public key and a subscriber-calculated point of an elliptic curve, the subscriber-generated public key being derived from the subscriber-generated serial number; the parties involved agreed on the respective curve parameters in advance of the signing process; in this embodiment, the subscriber-generated serial number remains with the subscriber as a secret (i.e. a private key) and the signature issuer is provided with a public key derived from the serial number; a method for checking a blind signature of an eMD is now provided for this purpose, the blind signature also being generated according to the previously described method; the eMD is received; a subscriber-generated public key used to generate the eMD; a signed unblended eMD; a monetary portion of the eMD; a (real) signature via a link between the monetary partial amount and another subscriber-generated public key; the participant-generated secret; and the publisher information; generation of a public key from a participant-generated serial number by the participant; generation of an eMD using the generated public key by the participant; masking of the generated eMD to obtain a masked unsigned eMD by the participant; sending of the masked unsigned eMD by the participant to a signature issuer; receipt of a signed masked eMD from the signature issuer by the participant), wherein the public part of the token-individual key pair was obtained by applying a cryptographic one-way function to the private part of the token-individual key pair of the token (Paragraph 0023 teaches for example, this public key is generated on the subscriber side in that the serial number is linked to a base point of the elliptic curve, for example a logical link or a simple mathematical operation, for example a multiplication; in this way, parts of a monetary amount of an eMD can also be transferred from one participant to another participant, which will be explained later; the signature is created over the entire monetary amount of the eMD), verifying, using a verification unit of the token reference register, whether the at least one token reference of the received registration request is stored in the token reference register (Paragraphs 0024-0026 teach a method for verifying a blind signature of an eMD is now also provided, the blind signature being generated in accordance with the previous method; to verify the signature, the unsigned, unblended (unfaced) eMD and a serial number used to generate the eMD and a signed unfaced (unfaced) eMD and the publisher information are obtained; this allows the full monetary amount of the eMD can be verified and, if the verification is successful, it changes hands based on knowledge of the (secret) serial number; in contrast to the previous verification of blindly signed eMD, the eMD is now calculated using the received serial number, the signed unblended eMD, the publisher information and a public key of the signature publisher; since the publisher information is also an invariable part of the blind signature, the blind signature can now be checked for correctness of the publisher information by obtaining the (plain text) publisher information; the calculated eMD is compared with the received eMD and the authenticity of the blind signature is verified if the calculated eMD matches the received eMD; the eMD obtained is preferably the result of a scatter value function from a combination of a subscriber-generated serial number with a base point and a subscriber-calculated point of an elliptical curve, a subscriber-generated public key being derived from the subscriber-generated serial number before the eMD is calculated; the blind signature of the eMD was created with the subscriber-generated public key instead of the subscriber-generated serial number; for example, this public key is generated on the subscriber side in that the serial number is linked to a base point of the elliptic curve, for example by a logical link or a simple mathematical operation, for example by multiplication; parts of a monetary amount of an eMD can also be transferred from one participant to another participant, which will be explained later; the blind signature is nevertheless created over the entire monetary amount of the eMD; to verify the authenticity of the subscriber-generated public key must then be provided to eMD; in the eMD described so far, a monetary amount (= maximum amount of the eMD) is linked to the subscriber-generated serial number, that is, the blind signature of the publisher is valid for the total amount of the monetary amount; so far, this has prevented parts of the total monetary amount from eMD from being sent, since the signature check for partial amounts is invalid; in addition, the verification also transmits the serial number (the secret) of the eMD and if the verification is successful, the secret is vented and the monetary amount can be redeemed - similar to DigiCash; now it is often desirable to share the eMD and only hand over partial amounts of the signed eMD).
However, Fritzhanns ‘950 does not explicitly teach storing the at least one token reference in a memory unit of the token reference register in order to register the token uniquely assigned to this token reference in the transaction system if it is established in the verification step that the at least one token reference of the received registration request is not stored in the token reference register.
Fritzhanns ‘945 from same or similar field of endeavors teaches storing the at least one token reference in a memory unit of the token reference register in order to register the token uniquely assigned to this token reference in the transaction system if it is established in the verification step that the at least one token reference of the received registration request is not stored in the token reference register (Paragraph 0035 teaches preferably, a query for the coin data record is made from a transaction database before the coin data record is obtained; based on the requested monetary amount, the coin data record is then generated by the transaction database or an affiliated coin issuer and made available to the first security element; the generation process includes, in particular, generating a random number and applying a cryptographic function to generate each individual element of the coin dataset by using the random number and a position of the element in the coin dataset; the coin data set is then made available to the first security element in a cryptographically secured manner, for example by the coin issuer; the random number is provided to the verification unit; upon receipt, the received coin data record is then displayed to the verification unit for use in the process; alternatively, the coin record is generated or issued by the verification unit, thus eliminating the need for a display after receiving the coin record).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Fritzhanns ‘950 to incorporate the teachings of Fritzhanns ‘945 to store the at least one token reference in a memory unit of the token reference register in order to register the token uniquely assigned to this token reference in the transaction system if it is established in the verification step that the at least one token reference of the received registration request is not stored in the token reference register.
There is motivation to combine Fritzhanns ‘945 into Fritzhanns ‘950 because by displaying the coin data record C<sub>1</sub> in the verification unit 2, the second security element SE2 indicates the legitimate possession of the coin data record C<sub>1</sub>. The verification unit 2 knows the random number r and can therefore check whether the elements C_NER175 and C_NER176 contained in the derived coin data set C_NER174 are correct and informs the second security element SE2 if necessary. The verification unit 2 logs the display, so that the first security element SE1 cannot issue this coin record C_NER177 a second time. Verification Unit 2 would notice the assignment of this sequence in such a prohibited repeat case and would warn the indicating security element SEx accordingly and not confirm its authenticity (Fritzhanns ‘945 Paragraph 0100).
Regarding Claim 20, the combination of Fritzhanns ‘950 and Fritzhanns ‘945 teaches all the limitations of claim 19 above; and Fritzhanns ‘950 further teaches wherein in the verification step by the verification unit of the token reference register, the following is also established: whether the token reference can be assigned to a token in the received registration request; and/or whether the received registration request is syntactically correct; and/or whether a sum of token values of all token references within the registration request is zero (Paragraph 0024 teaches since the publisher information is also an invariable part of the blind signature, the blind signature can now be checked for correctness of the publisher information by obtaining the (plain text) publisher information; the calculated eMD is compared with the received eMD and the authenticity of the blind signature is verified if the calculated eMD matches the received eMD).
Regarding Claim 21, the combination of Fritzhanns ‘950 and Fritzhanns ‘945 teaches all the limitations of claim 19 above; and Fritzhanns ‘950 further teaches wherein the public key part of the token-individual key pair of the token reference simultaneously is a database index in the token reference register (Paragraph 0023 teaches the participant-generated serial number remains with the participant as a secret (i.e., a private key), and the signature issuer is provided with a public key derived from the serial number; for example, this public key is generated on the participant side by linking the serial number to a base point of the elliptic curve, for example a logical operation or a simple mathematical operation, for example a multiplication).
Regarding Claim 22, the combination of Fritzhanns ‘950 and Fritzhanns ‘945 teaches all the limitations of claim 19 above; and Fritzhanns ‘950 further teaches wherein the received registration request is signed with the private part of the token-individual key pair in order to be able to verify an assignment of the token reference to the token (Paragraph 0023 teaches in this configuration, the participant-generated serial number remains with the participant as a secret (i.e., a private key), and the signature issuer is provided with a public key derived from the serial number).
Regarding Claim 23, the combination of Fritzhanns ‘950 and Fritzhanns ‘945 teaches all the limitations of claim 19 above; and Fritzhanns ‘950 further teaches wherein the registration request is received by a subscriber unit, in particular a secure element (Paragraph 0072 teaches a security element may be provided in a participant's terminal device for transmission purposes; a security element is preferably special software, particularly in the form of a secure runtime environment within an end-device operating system, known as a Trusted Execution Environment (TEE); alternatively, the security element can be, for example, special hardware, particularly in the form of a secure hardware platform module (Trusted Platform Module, TPM) or an embedded security module (eUICC, eSIM); the security element provides a trusted environment and also secures, for example, a machine-to-machine (M2M) application); and/or the registration request relates to a modification of at least one previously registered token, and at least the token reference of the at least one previously registered token and the at least one token reference of the token to be registered, which is the modification of the previously registered token (Paragraphs 0030-0032 teach the partial amount is genuinely signed, meaning without any additional obfuscation, because otherwise a recipient of the partial amount cannot verify its authenticity and correct derivation; in the subsequent verification process, the calculated genuine signature is then compared with the received genuine signature, thus verifying possession of the monetary amount; in this way, the authenticity of the received genuine signature can be verified, and it is ensured that the participant-generated secret was actually generated by the participant; therefore, the partial amount is valid; finally, the eMD is calculated using the participant-generated public key, the signed unblinded eMD, the publisher information, and a public key of the signature publisher, and the calculated eMD is compared with the received eMD, and the authenticity of the blind signature is verified if the calculated eMD matches the received eMD; during this calculation and verification process, it is not possible to infer the participant-generated serial number of the eMD, so although the blind signature can be verified, the full monetary value of the eMD cannot be decrypted; only the partial amount confirmed with the genuine signature can be transferred in this way and further used by the recipient (participant, auditing body)).
Regarding Claim 24, the combination of Fritzhanns ‘950 and Fritzhanns ‘945 teaches all the limitations of claim 19 above; however, the combination does not explicitly teach wherein the token reference register also comprises: the one or more memory units for storing token references for registering the token in the transaction system; and/or the one or more verification units for verifying received registration requests; and/or one or more check units for checking the received registration request, in particular for syntactic correctness and/or sum of the token values in the registration request, before the verification; and/or a check unit for checking a total token value of all token values of registered tokens of the transaction system; and/or a new registration unit for registering new tokens or deleted tokens as implemented by a token issuer.
Fritzhanns ‘945 further teaches wherein the token reference register also comprises: the one or more memory units for storing token references for registering the token in the transaction system; and/or the one or more verification units for verifying received registration requests; and/or one or more check units for checking the received registration request, in particular for syntactic correctness and/or sum of the token values in the registration request, before the verification; and/or a check unit for checking a total token value of all token values of registered tokens of the transaction system; and/or a new registration unit for registering new tokens or deleted tokens as implemented by a token issuer (Paragraphs 0072-0075 teach the coin data record C<sub>root</sub> is sent to the first security element; a confirmation command can also be exchanged, which may include a signature from the verification unit; the coin data record C<sub>root</sub> is represented by the random number r and also has an identifier ID; more information on this can be found in Fig. 4; the maximum value C<sub>max</sub> is securely managed in a memory area of the first security element SE1, hereinafter referred to as the repository; the terminal M1 is now configured to perform direct transactions with other terminals M2, M3 in direct transaction layer 3 at the maximum value C<sub>max</sub>; in the simplest case, the entire monetary value Cmax of the coin data record C<sub>root</sub> switches between the first security element SE1 and the second security element SE2 by completely transferring the coin data record C<sub>root</sub> (not shown in Fig. 2 or Fig. 3); the second security element SE2 would transmit the coin data record C<sub>root</sub> with the identifier ID and random number r; the second security element SE2 can then display this coin data record C<sub>root</sub> at the verification unit 2 in step 107 and thus check its authenticity, and afterwards exchange this coin data record C<sub>root</sub> for further payment transactions with other security elements SE1 , SE3).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Fritzhanns ‘950 and Fritzhanns ‘945 to incorporate the further teachings of Fritzhanns ‘945 for the token reference register to also comprise: the one or more memory units for storing token references for registering the token in the transaction system; and/or the one or more verification units for verifying received registration requests; and/or one or more check units for checking the received registration request, in particular for syntactic correctness and/or sum of the token values in the registration request, before the verification; and/or a check unit for checking a total token value of all token values of registered tokens of the transaction system; and/or a new registration unit for registering new tokens or deleted tokens as implemented by a token issuer.
There is motivation to further combine Fritzhanns ‘945 into the combination of Fritzhanns ‘950 and Fritzhanns ‘945 because due to the trusted security elements SE1 and SE2, the monetary value Cmax is transferred securely (Fritzhanns ‘945 Paragraph 0075).
Regarding Claim 25, the combination of Fritzhanns ‘950 and Fritzhanns ‘945 teaches all the limitations of claim 19 above; and Fritzhanns ‘950 further teaches wherein the token reference comprises at least one of the further token reference elements: a count value, an identity of a subscriber unit or of an owner of the subscriber unit, and/or a pseudonym of a subscriber entity or of an owner of the subscriber unit (Paragraphs 0011 and 0014 teach with the (digital) blind signature method, it is possible to remain anonymous as the owner of an eMD, so that payment transactions carried out by a participant cannot be verified by the signature issuer or a verification authority; the signature publisher is therefore unaware of the eMD, as it only receives a masked eMD; for example, "blinding" refers to adding or subtracting the eMD with an integer random number generated by the participant; it is therefore not possible to identify the participant based on possession of the defaced, unsigned eMD; the publisher information is provided independently of the signed, masked eMD as separate information; this independent provision ensures that the publisher information and the eMD are completely separate pieces of information and were originally generated by different entities; while the eMD can be generated by the participant themselves, the publisher information has been generated by the (trusted) signature publisher; in this way, anonymity is preserved in the payment system on the one hand, while on the other hand, this publisher information provides additional eMD-independent information that is also co-signed).
Regarding Claim 26, the combination of Fritzhanns ‘950 and Fritzhanns ‘945 teaches all the limitations of claim 23 above; and Fritzhanns ‘950 further teaches wherein the registration request is a splitting of a token, and the registration request comprises a token reference of the token to be split and a token reference of the split token to be registered (Paragraphs 0027-0028 teach a method for verifying a blind signature of an eMD is provided, wherein the blind signature was also generated according to the method described above. The following are received: the eMD; a participant-generated public key used to generate the eMD; a signed, unblinded eMD; a monetary value portion of the eMD; a (genuine) signature via a link between the monetary value portion and another participant-generated public key; the participant-generated secret; and the issuer information; the monetary value is a fraction of the total monetary value associated with the eMD. This monetary amount can take on any value, it can be an odd amount and/or it can be the change in a payment transaction).
Regarding Claim 27, the combination of Fritzhanns ‘950 and Fritzhanns ‘945 teaches all the limitations of claim 26 above; and Fritzhanns ‘950 further teaches wherein for splitting the token the following method steps are carried out in a subscriber unit: creating a new private part of a token-individual key pair for a first split token, applying a cryptographic function to the new private part in order to obtain a corresponding public part of the token-individual key pair for the first split token; creating a new private part of a token-individual key pair for a second split token; applying a cryptographic function to the new private part to obtain a corresponding public part of the token-individual key pair for the second split token; splitting the token value into a first token part value and into a second token part value, wherein the sum of the first token part value and the second token part value corresponds to the token value of the token to be split; creating a token reference for the first split token comprising the first token part value and the public part of the token-individual key pair of the first split token; creating a token reference for the second split token comprising the second token part value and the public part of the token-individual key pair of the second split token; and creating the registration request using the token reference of the token to be split, the token reference for the first split token and the token reference for the second split token (Paragraphs 0047-0056 teach a method is provided for deriving a monetary value partial amount of a signed, defaced eMD in a participant; the eMD is preserved according to the previously described procedure; this derivation process includes the following steps: generating a participant-generated secret and another public key from the participant-generated secret by the participant; determining a monetary value portion of the eMD; and calculating a signature via a combination of the monetary value portion and the other public key; the partial amount can be set as desired; it can be the change in a payment transaction or any other value; the participant-generated secret is different from the participant-generated serial number and is used instead of the serial number to transfer monetary amounts between participants; it is advantageous to transfer only a partial amount instead of the full monetary value of the eMD; this derivation process thus sets up an already blindly signed eMD for the transfer of partial monetary amounts; the creation of the participant-generated secret can be done by a first participant if they wish to divide a portion of the total amount; preferably, this generation is carried out by another participant who has not generated the participant-generated serial number; thus, a partial amount can also be allocated by any other participant who has legitimately acquired the eMD; eMDs can be shared while the blind signature of the eMD remains valid; furthermore, payment transactions using eMD are now possible, in which the eMD recipient (paid party) can send back a divided eMD, for example comparable to change or change in cash transactions or as part of a discount promotion; preferably, the additional public key is a link between a base point of the elliptic curve and the participant-generated secret; this combination is, for example, a logical operation or a simple mathematical operation, which minimizes the computational effort without compromising the security and tamper resistance of the procedure; as an alternative to the base point, another agreed value can also be used; the derivation further comprises generating a second participant-generated secret and a second additional public key from the second participant-generated secret by the participant or another participant; determining a second monetary sub-amount of the eMD, wherein the second monetary sub-amount is smaller than the monetary sub-amount, and calculating a second signature via a combination of the monetary sub-amount and the second additional public key; the second participant-generated secret can be created by the first participant if they wish to further divide a portion of the amount; preferably, this generation is carried out by a participant who did not generate the (first) participant-generated secret; therefore, the partial amount can also be further divided by any other participant; eMDs can be shared multiple times, while the blind signature still remains valid; furthermore, payment transactions using eMD are now possible, where the eMD recipient (paid party) can return a shared eMD, for example comparable to change or change in cash transactions or as part of a discount promotion; the second partial amount can be set arbitrarily, i.e., it can be any value smaller than the (first) partial amount; preferably, the second additional public key is a link between a base point of the elliptic curve and the second participant-generated secret; this combination is, for example, a logical operation or a simple mathematical operation, which minimizes the computational effort without compromising the security and tamper resistance of the procedure; as an alternative to the base point, another agreed value can also be used; a method for verifying a blind signature of an eMD is provided, wherein the blind signature was obtained according to the method described above; the verification process involves the following steps: obtaining the eMD, a serial number used to generate the eMD, and a signed, unredacted eMD; since the serial number, and not the derived public key, is obtained, the entire monetary value of the eMD can now be verified, decrypted, and transferred; transferring the serial number generally allows access to the entire monetary amount; for verification purposes, the public key is calculated from the participant-generated serial number; furthermore, the eMD is calculated using the calculated public key, the signed unblinded eMD, and a public key of the signature issuer; it should be noted that the calculated public key is used for verification instead of the serial number, because in this aspect of the invention the serial number remains hidden from the signature issuer and the blind signature is created via the public key; the calculated public key must then be used to verify the signature; finally, the calculated eMD is compared with the received eMD and the authenticity of the blind signature is verified if the calculated eMD matches the received eMD).
Regarding Claim 28, the combination of Fritzhanns ‘950 and Fritzhanns ‘945 teaches all the limitations of claim 23 above; however, the combination does not explicitly teach wherein the registration request relates to a switching of a token to be switched to a switched token, and the registration request comprises a token reference of the token to be switched and the token reference of the switched token.
Fritzhanns ‘945 further teaches wherein the registration request relates to a switching of a token to be switched to a switched token, and the registration request comprises a token reference of the token to be switched and the token reference of the switched token (Paragraph 0075 teaches in the simplest case, the entire monetary value Cmax of the coin data record C<sub>root</sub> switches between the first security element SE1 and the second security element SE2 by completely transferring the coin data record C<sub>root</sub> (not shown in Fig. 2 or Fig. 3); the second security element SE2 would transmit the coin data record C<sub>root</sub> with the identifier ID and random number r; the second security element SE2 can then display this coin data record C<sub>root</sub> at the verification unit 2 and thus check its authenticity, and afterwards exchange this coin data record C<sub>root</sub> for further payment transactions with other security elements SE1 , SE3).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Fritzhanns ‘950 and Fritzhanns ‘945 to incorporate the further teachings of Fritzhanns ‘945 for the registration request to relate to a switching of a token to be switched to a switched token, and the registration request comprises a token reference of the token to be switched and the token reference of the switched token.
There is motivation to further combine Fritzhanns ‘945 into the combination of Fritzhanns ‘950 and Fritzhanns ‘945 because of the same reasons listed above for claim 24.
Regarding Claim 29, the combination of Fritzhanns ‘950 and Fritzhanns ‘945 teaches all the limitations of claim 28 above; however, the combination does not explicitly teach wherein for switching the token the following method steps are carried out in a subscriber unit: creating a new private part of a token-individual key pair, applying a cryptographic function to the new private part in order to obtain a public part of the token-individual key pair for the switched token; creating the registration request using the token reference for the token to be switched and the public part of the token-individual key pair for the switched token.
Fritzhanns ‘945 further teaches wherein for switching the token the following method steps are carried out in a subscriber unit: creating a new private part of a token-individual key pair, applying a cryptographic function to the new private part in order to obtain a public part of the token-individual key pair for the switched token; creating the registration request using the token reference for the token to be switched and the public part of the token-individual key pair for the switched token (Paragraph 0075 teaches the entire monetary value Cmax of the coin data record C<sub>root</sub> switches between the first security element SE1 and the second security element SE2 by completely transferring the coin data record C<sub>root</sub> (not shown in Fig. 2 or Fig. 3); the second security element SE2 would transmit the coin data record C<sub>root</sub> with the identifier ID and random number r; due to the trusted security elements SE1 and SE2, the monetary value Cmax is transferred securely; the second security element SE2 can then display this coin data record C<sub>root</sub> at the verification unit 2 and thus check its authenticity, and afterwards exchange this coin data record C<sub>root</sub> for further payment transactions with other security elements SE1 , SE3).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Fritzhanns ‘950 and Fritzhanns ‘945 to incorporate the further teachings of Fritzhanns ‘945 for switching the token the following method steps to be carried out in a subscriber unit: creating a new private part of a token-individual key pair, applying a cryptographic function to the new private part in order to obtain a public part of the token-individual key pair for the switched token; creating the registration request using the token reference for the token to be switched and the public part of the token-individual key pair for the switched token.
There is motivation to further combine Fritzhanns ‘945 into the combination of Fritzhanns ‘950 and Fritzhanns ‘945 because of the same reasons listed above for claim 24.
Regarding Claim 30, the combination of Fritzhanns ‘950 and Fritzhanns ‘945 teaches all the limitations of claim 23 above; however, the combination does not explicitly teach wherein the registration request is a connection of at least two tokens and comprises a token reference of the connected token and a token reference of each of the tokens to be connected.
Fritzhanns ‘945 further teaches wherein the registration request is a connection of at least two tokens and comprises a token reference of the connected token and a token reference of each of the tokens to be connected (Paragraphs 0041 and 0122 teach these procedures include the step of receiving a coin data set, as described above; this is followed by the transfer of a first coin data set derived from the received coin data set from the first security element to a second security element, wherein the derived coin data set includes at least one element of the received coin data set and the position of the element in the received coin data set; additionally, a second coin data set derived from the received coin data set is transferred to the second security element, wherein the second derived coin data set has at least one further element of the received coin data set that directly follows the element of the first derived coin data set and the position of the further element in the received coin data set; both derived coin datasets are therefore taken from the received coin dataset; in this case, these derived coin records do not need to be treated separately, but instead, the first derived coin record is combined with the second derived coin record to obtain a combined derived coin record, and finally, the possession of the combined derived coin record is indicated by the second security element at a verification unit; if this check shows that all elements of the coin data records C<sub>3</sub>, C<sub>4</sub> (possibly without gaps) are derived from the received coin data record C<sub>root</sub>, these coin data records C<sub>3</sub>, C<sub>4</sub> can be combined with each other, which is also done; the result of combining is a combined derived dataset C<sub>6</sub>; the combined derived coin data set C<sub>6</sub>has a monetary value which corresponds to the sum of all individual coin data sets C<sub>3</sub>, C<sub>4</sub>; the combined derived coin data set C<sub>6</sub>is displayed of the verification unit, which independently of the security element SE2 checks the combinability and thus verifies the authenticity).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Fritzhanns ‘950 and Fritzhanns ‘945 to incorporate the further teachings of Fritzhanns ‘945 for the registration request to be a connection of at least two tokens and comprises a token reference of the connected token and a token reference of each of the tokens to be connected.
There is motivation to further combine Fritzhanns ‘945 into the combination of Fritzhanns ‘950 and Fritzhanns ‘945 because by combining the derived coin data sets, the amount of data to be transferred for transmission, crediting and/or verification is significantly reduced, thus enabling a faster exchange of electronic coin data sets between end devices (Fritzhanns ‘945 Paragraph 0041).
Regarding Claim 31, the combination of Fritzhanns ‘950 and Fritzhanns ‘945 teaches all the limitations of claim 30 above; however, the combination does not explicitly teach wherein for connecting the token the following method steps are carried out in a subscriber unit: creating a new private part of a token-individual key pair, applying a cryptographic function to the new private part to obtain a corresponding public part of the token-individual key pair for the connected token; calculating the token value for the connected token by forming the sum of the respective token values of the tokens to be connected; creating a token reference for the connected token comprising the calculated token value and the public part of the token-individual key pair for the connected token; and creating the registration request using each token reference of the tokens to be connected and the token reference for the connected token.
Fritzhanns ‘945 further teaches wherein for connecting the token the following method steps are carried out in a subscriber unit: creating a new private part of a token-individual key pair, applying a cryptographic function to the new private part to obtain a corresponding public part of the token-individual key pair for the connected token; calculating the token value for the connected token by forming the sum of the respective token values of the tokens to be connected; creating a token reference for the connected token comprising the calculated token value and the public part of the token-individual key pair for the connected token; and creating the registration request using each token reference of the tokens to be connected and the token reference for the connected token (Paragraphs 0044-0048 teach preferably, the first derived coin data set and/or the second derived coin data set each contain only a starting element of the sequence; an ending element of the sequence; and their respective positions in the received (original) coin data set; this means that not all elements need to be transferred individually, which further significantly reduces the amount of data to be transferred in the coin data records; the starting and ending elements simply define the boundaries of the sequence; alternatively, other elements can be sent, as long as it is ensured that the sequence of elements is uniquely represented (and also recognized); the element of the received coin data set is the result of a cryptographic function consisting of the random number unknown to the receiving security element and the position of the element in the coin data set, as described above and optionally using an additional coin data set-specific transmission count value; the coin-specific transmission count value is generated and monitored in the sending security element; preferably, the element of the received derived coin data set is the result of a second cryptographic function derived from the previously calculated cryptographic function and a coin data set-specific transmission count value; preferably, the (coin record) element-specific result of the cryptographic function consisting of a random number and position is provided by a transaction database or the verification unit; this result is then combined with the transmission count value, preferably via the second cryptographic function. This allows the count value to be generated by the security element in a derivation-specific manner and transmitted in a tamper-proof way; the count value is increased by one count value for each derivation of a coin data set from the received coin data set; in a preferred embodiment, before the combining step, it is checked whether the coin-specific transfer count value of the second derived coin-specific record differs from the coin-specific transfer count value of the first derived coin-specific record by more than one count value; preferably, combining coin data records in the security element is prevented, or verifying and crediting combined coin data records in the verification unit is prevented if the count values are not consecutive; a combined derived coin record can now be treated like a derived coin record and, for example, sent to other security elements or to a transaction database for crediting, as described above; the procedure further includes calculating a cryptographic function for at least one element of the sequence of the first or second derived coin data set using a derived value from the sequence of the first or second derived coin data set and the position of the element in the sequence, and adding the result of the cryptographic function and the position of the element in the received coin data set to the combined derived coin data set).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Fritzhanns ‘950 and Fritzhanns ‘945 to incorporate the further teachings of Fritzhanns ‘945 for connecting the token the following method steps to be carried out in a subscriber unit: creating a new private part of a token-individual key pair, applying a cryptographic function to the new private part to obtain a corresponding public part of the token-individual key pair for the connected token; calculating the token value for the connected token by forming the sum of the respective token values of the tokens to be connected; creating a token reference for the connected token comprising the calculated token value and the public part of the token-individual key pair for the connected token; and creating the registration request using each token reference of the tokens to be connected and the token reference for the connected token.
There is motivation to further combine Fritzhanns ‘945 into the combination of Fritzhanns ‘950 and Fritzhanns ‘945 because derived coin data sets can be easily identified and verified by their count value (Fritzhanns ‘945 Paragraph 0047).
Regarding Claim 32, the combination of Fritzhanns ‘950 and Fritzhanns ‘945 teaches all the limitations of claim 19 above; however, the combination does not explicitly teach wherein the registration request has been sent by a token issuer, and wherein the registration request relates to a creation of a token or a deletion of a token.
Fritzhanns ‘945 further teaches wherein the registration request has been sent by a token issuer, and wherein the registration request relates to a creation of a token or a deletion of a token (Paragraph 0035 teaches based on the requested monetary amount, the coin data record is then generated by the transaction database or an affiliated coin issuer and made available to the first security element; the generation process includes, in particular, generating a random number and applying a cryptographic function to generate each individual element of the coin dataset by using the random number and a position of the element in the coin dataset; the random number is provided to the verification unit; upon receipt, the received coin data record is then displayed to the verification unit for use in the process; alternatively, the coin record is generated or issued by the verification unit, thus eliminating the need for a display after receiving the coin record).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Fritzhanns ‘950 and Fritzhanns ‘945 to incorporate the further teachings of Fritzhanns ‘945 for the registration request to have been sent by a token issuer, and wherein the registration request relates to a creation of a token or a deletion of a token.
There is motivation to further combine Fritzhanns ‘945 into the combination of Fritzhanns ‘950 and Fritzhanns ‘945 because the coin data set is then made available to the first security element in a cryptographically secured manner, for example by the coin issuer (Fritzhanns ‘945 Paragraph 0035).
Regarding Claim 33, the combination of Fritzhanns ‘950 and Fritzhanns ‘945 teaches all the limitations of claim 19 above; and Fritzhanns ‘950 further teaches a token reference register for a transaction system (Paragraphs 0008 and 0036 teach the object of the present invention is therefore to create a method and a system in which it is transparently verifiable whether a signature issuer of a blind signature has actually signed an eMD; furthermore, the monetary value (coin value) of a signed eMD should be easily divisible without a blind signature losing its validity; a payment system for transmitting an electronic coin data set between at least two participants comprises a first participant for generating an unsigned blinded eMD; a signature issuer for generating a blind signature according to the method described above; and a second participant for receiving the generated eMD, a signed unstained eMD, and a serial number used to generate the eMD).
Regarding Claim 34, the combination of Fritzhanns ‘950 and Fritzhanns ‘945 teaches all the limitations of claim 33 above; however, the combination does not explicitly teach at least one memory unit for storing token references for registering tokens in the transaction system; at least one verification unit for verifying whether a token reference of a received registration request is stored in the token reference register, a new registration unit for registering a token newly generated by a token issuer or a token deleted by a token issuer, optionally a check unit for checking the received registration request before the verification by the verification unit, and optionally a check unit for checking a total sum of the token values of registered token of the transaction system stored in the memory unit.
Fritzhanns ‘945 further teaches at least one memory unit for storing token references for registering tokens in the transaction system; at least one verification unit for verifying whether a token reference of a received registration request is stored in the token reference register, a new registration unit for registering a token newly generated by a token issuer or a token deleted by a token issuer, optionally a check unit for checking the received registration request before the verification by the verification unit, and optionally a check unit for checking a total sum of the token values of registered token of the transaction system stored in the memory unit (Paragraphs 0072-0075 teach the coin data record C<sub>root</sub> is sent to the first security element; a confirmation command can also be exchanged, which may include a signature from the verification unit; the coin data record C<sub>root</sub> is represented by the random number r and also has an identifier ID; more information on this can be found in Fig. 4; the maximum value C<sub>max</sub> is securely managed in a memory area of the first security element SE1, hereinafter referred to as the repository; the terminal M1 is now configured to perform direct transactions with other terminals M2, M3 in direct transaction layer 3 at the maximum value C<sub>max</sub>; in the simplest case, the entire monetary value Cmax of the coin data record C<sub>root</sub> switches between the first security element SE1 and the second security element SE2 by completely transferring the coin data record C<sub>root</sub> (not shown in Fig. 2 or Fig. 3); the second security element SE2 would transmit the coin data record C<sub>root</sub> with the identifier ID and random number r; due to the trusted security elements SE1 and SE2, the monetary value Cmax is transferred securely; the second security element SE2 can then display this coin data record C<sub>root</sub> at the verification unit and thus check its authenticity, and afterwards exchange this coin data record C<sub>root</sub> for further payment transactions with other security elements SE1 , SE3).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Fritzhanns ‘950 and Fritzhanns ‘945 to incorporate the further teachings of Fritzhanns ‘945 for at least one memory unit for storing token references for registering tokens in the transaction system; at least one verification unit for verifying whether a token reference of a received registration request is stored in the token reference register, a new registration unit for registering a token newly generated by a token issuer or a token deleted by a token issuer, optionally a check unit for checking the received registration request before the verification by the verification unit, and optionally a check unit for checking a total sum of the token values of registered token of the transaction system stored in the memory unit.
There is motivation to further combine Fritzhanns ‘945 into the combination of Fritzhanns ‘950 and Fritzhanns ‘945 because of the same reason listed above for claim 24.
Regarding Claim 36, the combination of Fritzhanns ‘950 and Fritzhanns ‘945 teaches all the limitations of claim 33 above; and Fritzhanns ‘950 further teaches a transaction system comprising: a register layer with a token reference register according to claim 33 for registering token references; and a direct transaction layer with a plurality of subscriber units which are designed at least partially as a secure element which is configured as a subscriber unit of a transaction system, for the direct exchange of tokens with a further subscriber unit, wherein each token of the transaction system comprises at least one token value and a private part of a token-individual key pair as token elements, for creating a modified token from an existing token to be modified, wherein a token reference uniquely assigned to the modified token of the transaction system comprises at least the token value of the token and a public part of the token-individual key pair as token reference elements, wherein the public part of the token-individual key pair is obtained by applying a cryptographic one-way function to the private part of the token-individual key pair of the token, and for providing a registration request to a token reference register of the transaction system, wherein the registration request has at least the token reference uniquely assigned to the token of the transaction system (Paragraphs 0072 and 0030-0032 teach a security element may be provided in a participant's terminal device for transmission purposes; a security element is preferably special software, particularly in the form of a secure runtime environment within an end-device operating system, known as a Trusted Execution Environment (TEE); the security element provides a trusted environment and also secures, for example, a machine-to-machine (M2M) application; the partial amount is genuinely signed, meaning without any additional obfuscation, because otherwise a recipient of the partial amount cannot verify its authenticity and correct derivation; the calculated genuine signature is then compared with the received genuine signature, thus verifying possession of the monetary amount; the authenticity of the received genuine signature can be verified, and it is ensured that the participant-generated secret was actually generated by the participant; therefore, the partial amount is valid; finally, the eMD is calculated using the participant-generated public key, the signed unblinded eMD, the publisher information, and a public key of the signature publisher, and the calculated eMD is compared with the received eMD, and the authenticity of the blind signature is verified if the calculated eMD matches the received eMD; during this calculation and verification process, it is not possible to infer the participant-generated serial number of the eMD, so although the blind signature can be verified, the full monetary value of the eMD cannot be decrypted; only the partial amount confirmed with the genuine signature can be transferred in this way and further used by the recipient (participant, auditing body)).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Hurry et al. (US 20230026665) teaches receiving, by a central entity computer, a request for digital currency. The request includes a serial number and a denomination of a physical currency. The central entity computer generates the digital currency for the denomination and linked to the serial number. The generating includes recording the digital currency on a blockchain. The central entity computer transmits a notification of the generation of the digital currency. The central entity computer causes removal of the physical currency from circulation in a fiat currency system.
Johnson (US 20210256487) teaches a method performed by a processing system including a processor of sending a passed ledger associated with a virtual coin to a requestor; receiving a next block for the passed ledger from the requestor; calculating a hash value for the next block; and sending an identifier for the next block and the hash of the next block for recording in the hash ledger responsive to the hash value matching the hash of the next block. Other embodiments are disclosed.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY JONES whose telephone number is (469) 295-9137. The examiner can normally be reached on 7:30 am - 4:30 pm CST (M-Th).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel can be reached at (571) 270-1492. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/COURTNEY P JONES/Primary Examiner, Art Unit 3699