DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This action is in reply to response to restriction requirement filed on 10/17/25. Claims 17-20 were withdrawn. Claims 1-16 are pending and examined.
Information Disclosure Statement
The information disclosure statements (IDS) were submitted on 9/11/24 and 1/27/25. The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements were considered by the examiner.
Election/Restrictions
Applicant’s election without traverse of group 1, claims 1-16, in the reply filed on 10/17/25 is acknowledged.
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 1-16 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. (Step 1) The claims recite a process (claim 1) and an apparatus (claim 12). For the purposes of this analysis, representative claim 12 is addressed. (Step 2A, prong 1) Abstract ideas are in bold below, and represent organizing human activity as a method of managing a payment transaction, as are all a form of commercial or legal interactions and managing personal behavior or relationships or interactions between people.
A user device comprising:
a processor; and
a computer-readable medium coupled to the processor, the computer- readable medium comprising code executable by the processor for implementing a method comprising:
receiving an interaction request message for an interaction, the interaction request message comprising an amount from a resource provider computer;
selecting, by a secure element on the user device, between an offline balance and an offline amount of program tokens stored in the secure element, wherein the offline amount of program tokens is selected;
deducting, by the secure element on the user device, the amount from the offline amount of program tokens; and
completing the interaction with the resource provider computer based on the amount.
(Step 2A prong 2) The additional elements are as follows:
“A user device comprising”, “a processor” and “a computer-readable medium coupled to the processor, the computer- readable medium comprising code executable by the processor for implementing a method comprising”. This is merely “apply it” as the “user device”, “processor, “computer-readable medium” are claimed at a high level of generality, receive the information, perform the abstract idea, and output the results.
“a resource provider computer”. This is merely “apply it” as the “resource provider computer” is claimed at a high level of generality, receives the information, performs the abstract idea, and outputs the results.
“program [tokens] stored in the secure element”. This is merely “apply it” as the “program [tokens] stored in the secure element” is claimed at a high level of generality, receives the information, performs the abstract idea, and outputs the results.
(Step 2B) The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount do no more than provide mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of managing a payment transaction, over a generic computer network with generic computing elements, and generic hardware.
Analysis of dependent claim 2 recited “wherein the program tokens are created by a program computer as indicated by a program smart contract that references a central authority smart contract, wherein the program computer assigns the program tokens to a user of the user device in the program smart contract”, additional details which further narrow the abstract idea and additional elements.
The additional elements are as follows:
“the program [tokens] are created by a program computer as indicated by a program smart contract that references a central authority smart contract”. This is merely “apply it” as the “the program [tokens] are created by a program computer as indicated by a program smart contract that references a central authority smart contract” is claimed at a high level of generality, receives the information, performs the abstract idea, and outputs the results. This is general linking as the “smart contract” and “central authority smart contract” do no more than link the use of the abstract idea to a particular technological environment or field of use.
“the program computer” and “the user device”. This is merely “apply it” as the “the program computer” and “user device” are claimed at a high level of generality, receive the information, perform the abstract idea, and output the results.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount do no more than provide mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of managing a payment transaction, over a generic computer network with generic computing elements, and generic hardware.
Analysis of dependent claim 3 recited “wherein the interaction occurs between the user device and the resource provider computer for one or more resources, wherein the user device and the resource provider computer are both enrolled in a program associated with the program tokens.”, additional details which further narrow the abstract idea and additional elements.
The additional elements are as follows:
“the user device” and “resource provider computer’. This is merely “apply it” as the “user device” and “resource provider computer” are claimed at a high level of generality, receive the information, perform the abstract idea, and output the results.
“the user device and the resource provider computer are both enrolled in a program associated with the program tokens”. This is merely “apply it” as the “the user device and the resource provider computer are both enrolled in a program associated with the program tokens” is claimed at a high level of generality, receives the information, performs the abstract idea, and outputs the results.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount do no more than provide mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of managing a payment transaction, over a generic computer network with generic computing elements, and generic hardware.
Analysis of dependent claim 4 recited “wherein the program tokens are created by a program computer as indicated by a program smart contract that references a central authority smart contract, wherein the program computer assigns the program tokens to a user of the user device in the program smart contract”, additional details which further narrow the abstract idea and additional elements.
The additional elements are as follows:
“the program [tokens] are created by a program computer as indicated by a program smart contract that references a central authority smart contract”. This is merely “apply it” as the “the program [tokens] are created by a program computer as indicated by a program smart contract that references a central authority smart contract” is claimed at a high level of generality, receives the information, performs the abstract idea, and outputs the results. This is general linking as the “program smart contract” does no more than link the use of the abstract idea to a particular technological environment or field of use.
“the program computer” and “the user device”. This is merely “apply it” as the “program computer” and “user device” are claimed at a high level of generality, receive the information, perform the abstract idea, and output the results.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount do no more than provide mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of managing a payment transaction, over a generic computer network with generic computing elements, and generic hardware.
Analysis of dependent claim 5 recited “receiving, by the user device, a program token creation message from a program computer, wherein the program token creation message indicates that the program token created one or more program tokens that are assigned to the user device and/or a user of the user device as indicated in a program smart contract”, additional details which further narrow the abstract idea and additional elements.
The additional elements are as follows:
“the user device”, “program [token]”, “a program computer” and “a program smart contract”. This is merely “apply it” as the “user device” and “program computer” are claimed at a high level of generality, receive the information, perform the abstract idea, and output the results. This is general linking as the “program [token]” and “program smart contract” do no more than link the use of the abstract idea to a particular technological environment or field of use.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount do no more than provide mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of managing a payment transaction, over a generic computer network with generic computing elements, and generic hardware.
Analysis of dependent claim 6 recited “generating, by the user device, an interaction response message comprising an amount equal to the requested amount” and “transmitting, by the user device, the interaction response message to the resource provider computer”, additional details which further narrow the abstract idea and additional elements.
The additional elements are as follows:
“the user device”, “transmitting, by the user device, the interaction response message to the resource provider computer”. This is merely “apply it” as the “user device” and “transmitting, by the user device, the interaction response message to the resource provider computer” are claimed at a high level of generality, receive the information, perform the abstract idea, and output the results.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount do no more than provide mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of managing a payment transaction, over a generic computer network with generic computing elements, and generic hardware.
Analysis of dependent claim 7 recited “wherein the resource provider computer receives the interaction response message and increases a resource provider offline balance based on the amount”, additional details which further narrow the abstract idea and additional elements.
The additional elements are as follows:
“the resource provider computer”. This is merely “apply it” as the “the resource provider computer” is claimed at a high level of generality, receives the information, performs the abstract idea, and outputs the results.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount do no more than provide mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of managing a payment transaction, over a generic computer network with generic computing elements, and generic hardware.
Analysis of dependent claim 8 recited “generating, by the user device, a program token transfer message comprising a number of program tokens”, “providing, by the user device, the program token transfer message to a service provider computer, wherein the service provider computer provides the program token transfer message to a program smart contract stored on a blockchain, wherein the program smart contract, in conjunction with an offline interaction smart contract stored on the blockchain, increase an online balance associated with the user device based on the number of program tokens”, “receiving, by the user device, a transfer completion message from the service provider computer”, additional details which further narrow the abstract idea and additional elements.
The additional elements are as follows:
“the user device”, “a program [token]”, “a service provider computer”. This is merely “apply it” as the “user device”, “program [token]”, “service provider computer” are claimed at a high level of generality, receive the information, perform the abstract idea, and output the results.
“a program smart contract stored on a blockchain, wherein the program smart contract, in conjunction with an offline interaction smart contract stored on the blockchain”. This is merely “apply it” as the “program smart contract stored on a blockchain, wherein the program smart contract, in conjunction with an offline interaction smart contract stored on the blockchain” is claimed at a high level of generality, receives the information, performs the abstract idea, and outputs the results. This is as the “program smart contract”, “blockchain” and “offline interaction smart contract” do no more than link the use of the abstract idea to a particular technological environment or field of use.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount do no more than provide mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of managing a payment transaction, over a generic computer network with generic computing elements, and generic hardware.
Analysis of dependent claim 9 recited “wherein the interaction request message further comprises a program eligibility indicator, and wherein the selection between the offline balance and the offline amount of program tokens is based on the program eligibility indicator”, additional details which further narrow the abstract idea and additional elements.
The additional elements are as follows:
“a program [token]”. This is merely “apply it” as the “program [token]” is claimed at a high level of generality, receives the information, performs the abstract idea, and outputs the results.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount do no more than provide mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of managing a payment transaction, over a generic computer network with generic computing elements, and generic hardware.
Analysis of dependent claim 10 recited “after receiving the interaction request message, determining, by the secure element of the user device, whether or not there is a first sufficient amount of the offline amount of program tokens in the secure element and/or a second sufficient amount of the offline balance to satisfy the requested amount”, additional details which further narrow the abstract idea and additional elements.
The additional elements are as follows:
“the security element of the user device” and “program [tokens]”. This is merely “apply it” as the “security element of the user device” and “program [tokens]” are claimed at a high level of generality, receive the information, perform the abstract idea, and output the results.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount do no more than provide mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of managing a payment transaction, over a generic computer network with generic computing elements, and generic hardware.
Analysis of dependent claim 11 recited “if there is not the first sufficient amount of the offline amount of program tokens in the secure element to satisfy the requested amount, wherein the offline amount of program tokens is nonzero, applying, by the secure element of the user device, the offline amount of program tokens to the requested amount to determine a remaining amount” and “applying, by the secure element of the user device, the offline balance to the remaining amount”, additional details which further narrow the abstract idea and additional elements.
The additional elements are as follows:
“the security element of the user device” and “program [tokens]”. This is merely “apply it” as the “security element of the user device” and “program [tokens]” are claimed at a high level of generality, receive the information, perform the abstract idea, and output the results.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount do no more than provide mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of managing a payment transaction, over a generic computer network with generic computing elements, and generic hardware.
Analysis of dependent claim 13 recited “wherein the interaction request message further comprises a program eligibility indicator, and wherein the selection between the offline balance and the offline amount of program tokens is based on the program eligibility indicator, and wherein the method further comprises: after receiving the interaction request message, if the program eligibility indicator indicates that the interaction is eligible for program tokens, determining whether or not there is a first sufficient amount of the offline amount of program tokens in the secure element and/or a second sufficient amount of the offline balance to satisfy the requested amount”, additional details which further narrow the abstract idea and additional elements.
The additional elements are as follows:
“the security element” and “program [tokens]”. This is merely “apply it” as the “security element” and “program [tokens]” are claimed at a high level of generality, receive the information, perform the abstract idea, and output the results.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount do no more than provide mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of managing a payment transaction, over a generic computer network with generic computing elements, and generic hardware.
Analysis of dependent claim 14 recited “generating an interaction response message comprising the amount equal to the requested amount and a user device secure element certificate” and “transmitting the interaction response message to the resource provider computer, wherein the resource provider computer receives the interaction response message and increases a resource provider offline balance based on the amount.”, additional details which further narrow the abstract idea and additional elements.
The additional elements are as follows:
“user device secure element [certificate]” and “transmitting the interaction response message to the resource provider computer”. This is merely “apply it” as the “user device secure element [certificate]” and “transmitting are claimed at a high level of generality, receive the information, perform the abstract idea, and output the results.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount do no more than provide mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of managing a payment transaction, over a generic computer network with generic computing elements, and generic hardware.
Analysis of dependent claim 15 recited additional elements.
The additional elements are as follows:
“the secure element, wherein the secure element securely processes cryptographic operations for the user device”. This is merely “apply it” as the “the secure element, wherein the secure element securely processes cryptographic operations for the user device” is claimed at a high level of generality, receives the information, performs the abstract idea, and outputs the results.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount do no more than provide mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of managing a payment transaction, over a generic computer network with generic computing elements, and generic hardware.
Analysis of dependent claim 16 recited additional elements.
The additional elements are as follows:
“wherein the user device and the resource provider computer are offline from a trusted third party computer”. This is merely “apply it” as the “the user device and the resource provider computer are offline from a trusted third party computer is claimed at a high level of generality, receives the information, performs the abstract idea, and outputs the results.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount do no more than provide mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of managing a payment transaction, over a generic computer network with generic computing elements, and generic hardware.
Claim Rejections - 35 USC § 102
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.
Claims 1-16 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by WO 2012122994 A1 (Kreft).
As to claims 1 and 12,
Kreft teaches,
receiving, by a user device (p. 74, ll. 13-15 “actions to be taken by Alice and Bob (the users), their CASTORs (eWallets), and their NetNodes (i.e. the devices housing the CASTORs of Alice and Bob)”), an interaction request message for an interaction, the interaction request message comprising a requested amount from a resource provider computer (p. 74, ll. 16-22 “Alice collects all information to conduct a payment … i.e.: the amount of money to be payable by Alice …”);
selecting, by a secure element on the user device (FIG. 17, p. 141, l. 20 “CASTOR or a (tamper-protected) semiconductor module”), between an offline balance (p. 98, ll. 1-7 “the "means of exchange" used so far in the described system are financial instruments like Euros (€), Dollars ($), … eCoins”, p. 79, l.. 21-27 “the off-line transaction … the atomic eCoins available to her CASTOR”) and an offline amount of program tokens stored in the secure element (p. 79, ll. 21-27 “the atomic eCoins available to her CASTOR”), wherein the offline amount of program tokens is selected (p. 79, ll. 21-27);
deducting, by the secure element on the user device, the requested amount from the offline amount of program tokens (p. 25, ll. 2-6 “It should be noticed that electronic tokens successfully sent by a peer-device/ tamper-protected hardware module (…) are automatically irrevocably destroyed by the transmitting peer device/tamper-protected hardware module”);
completing, by the user device, the interaction with the resource provider computer (p. 25, ll. 2-6 “electronic tokens successfully sent by a peer-device/ tamper-protected hardware module”).
additionally, with respect to claim 12,
Kreft teaches,
A user device (FIG. 7, p. 20, l. 17 “network node”, p. 63, l. 15 “The physical node identity may identify a peer-device 'X'”, p. 74, ll. 13-15 “their NetNodes (i.e. the devices housing the CASTORs of Alice and Bob)”), comprising,
a processor (p. 20, l. 17 “network node”),
a computer-readable medium coupled to the processor, the computer- readable medium comprising code executable by the processor for implementing a method (p. 9, ll. 32-35 “a storage unit of the tamper-protected hardware module may store signed configuration information indicating the initial configuration of the array of processing-elements of the FPGA of the hardware module. The hardware module's processor unit could …”) comprising.
As to claim 2, Kreft teaches all limitations of claim 1.
Kreft teaches,
generating, by the user device, a program token request message comprising a requested number of program tokens (p. 79, ll. 21-27 “Alice's CASTOR executing the off-line transaction protocol collects the information available to negotiate the transfer details for electronic tokens”);
providing, by the user device, the program token request message to a service provider computer (p. 79, ll. 21-27, p. 70, ll. 6-10 “the eDoc is continuously updated to document the state of the transaction and is exchanged by Alice and Bob”, p. 16, ll. 10-15 “an issuing authority”), wherein the service provider computer determines whether or not a user of the user device has an online amount of program tokens as indicated by a program smart contract referenced by an offline interaction system smart contract (p. 81, ll. 9-12 “the initial eDoc (so-called eDoc[I] object) has all necessary information to compile a first RSL of eCoin combinations for "paying". The RSL may be determined based on the policies outlined above. The initial RSL includes possible eCoin sets to achieve the eCoin exchange, taking only into account the own local CASTOR database (i.e. the locally available eCoins)”);
receiving, by the secure element of the user device, a program token response message indicating the requested number of program tokens from the service provider computer (p. 25, ll. 2-6 “electronic tokens successfully sent by a peer-device/ tamper-protected hardware module”);
increasing, by the secure element of the user device, the offline amount of program tokens by the requested number of program tokens (p. 25. ll. 2-6 “electronic tokens successfully sent by a peer-device/ tamper-protected hardware module”).
As to claim 3, Kreft teaches all limitations of claim 1.
Kreft teaches,
wherein the interaction occurs between the user device and the resource provider computer for one or more resources (pp. 74, ll. 13-15 “Alice and Bob (the users), their CASTORs (eWallets), and their NetNodes”),
wherein the user device and the resource provider computer are both enrolled in a program associated with the program tokens (pp. 74, ll. 13-15 “Alice and Bob (the users), their CASTORs (eWallets)”, p. 69, ll. 31-32 “(e.g. CFVs, denomination of eCoins and change eCoins, etc.) allowing the CASTORs of Alice and Bob to conclude on how to conduct the electronic token transfer”).
As to claim 4, Kraft teaches all limitations of claim 1.
Kreft teaches,
wherein the program tokens are created by a program computer as indicated by a program smart contract that references a central authority smart contract, wherein the program computer assigns the program tokens to a user of the user device in the program smart contract (p. 69, ll. 29-32 “the eDoc defines a flexible container format to exchange the necessary information (e.g. CFVs, denomination of eCoins and change eCoins, etc.) for allowing the CASTORs of Alice and Bob to conclude on how to conduct the electronic token transfer”).
As to claim 5, Kraft teaches all limitations of claim 1.
Kreft teaches,
receiving, by the user device, a program token creation message from a program computer (p. 81, ll. 9-10 “compile a first RSL of eCoin combinations for "paying"), wherein the program token creation message indicates that the program token created one or more program tokens that are assigned to the user device and/or a user of the user device as indicated in a program smart contract (p. 81, ll. 9-12 “The initial RSL includes possible eCoin sets to achieve the eCoin exchange”).
As to claim 6, Kraft teaches all the limitations of claim 1.
Kreft teaches,
wherein completing the interaction with the resource provider computer (p. 25, ll. 2-6 “electronic tokens successfully sent by a peer-device/ tamper-protected hardware module”) comprises:
generating, by the user device, an interaction response message comprising an amount equal to the requested amount (p. 74, ll. 16-22 “Alice collects all information to conduct a payment … i.e.: the amount of money to be payable by Alice …”);
transmitting, by the user device, the interaction response message to the resource provider computer (p. 25, ll. 2-6 “electronic tokens successfully sent by a peer-device/ tamper-protected hardware module”).
As to claim 7, Kraft teaches all the limitations of claim 1.
Kreft teaches,
wherein the resource provider computer receives the interaction response message and increases a resource provider offline balance based on the amount (p. 82, ll. 10-15 “Bob is able to make a counterproposal (optionally using partial knowledge from the previous proposal: Bob „learns", which eCoins Alice has in her CASTOR eWallet by studying the denominations of her RSL) and sends his own RSL of denominations of eCoins for the payment, which Alice has then to choose from”).
As to claim 8, Kraft teaches all the limitations of claim 1.
Kreft teaches,
generating, by the user device, a program token transfer message comprising a number of program tokens (p. 81, ll. 9-10 “compile a first RSL of eCoin combinations for "paying");
providing, by the user device, the program token transfer message to a service provider computer (p. 16, ll. 10-15 “an issuing authority”), wherein the service provider computer provides the program token transfer message to a program smart contract stored on a blockchain (p. 81, ll. 9-12), wherein the program smart contract, in conjunction with an offline interaction smart contract stored on the blockchain, increase an online balance associated with the user device based on the number of program tokens (p. 82, ll. 10-15; p. 83, ll. 3-14 “the user and the user's bank may first determine the amount of money (eCoins) to be deposited/withdrawn”);
receiving, by the user device, a transfer completion message from the service provider computer (p. 25, ll. 2-6).
As to claim 9, Kraft teaches all the limitations of claim 1.
Kreft teaches,
wherein the interaction request message further comprises a program eligibility indicator (p. 81, ll. 9-12 “The initial RSL includes possible eCoin sets to achieve the eCoin exchange, taking only into account the own local CASTOR database (i.e. the locally available eCoins)”), and wherein the selection between the offline balance and the offline amount of program tokens is based on the program eligibility indicator (p. 81, ll. 9-12, p. 83, ll. 3-14 “the user and the user's bank may first determine the amount of money (eCoins) to be deposited/withdrawn”).
As to claim 10, Kraft teaches all the limitations of claim 1.
Kreft teaches,
after receiving the interaction request message, determining, by the secure element of the user device, whether or not there is a first sufficient amount of the offline amount of program tokens in the secure element and/or a second sufficient amount of the offline balance to satisfy the requested amount (p. 81, ll. 9-12; p. 83, ll. 3-14 “the user and the user's bank may first determine the amount of money (eCoins) to be deposited/withdrawn”).
As to claim 11, Kraft teaches all the limitations of claims 1 and 10.
Kreft teaches,
if there is not the first sufficient amount of the offline amount of program tokens in the secure element to satisfy the requested amount, wherein the offline amount of program tokens is nonzero, applying, by the secure element of the user device, the offline amount of program tokens to the requested amount to determine a remaining amount (p. 81, ll. 9-12; p. 83, ll. 3-14);
applying, by the secure element of the user device, the offline balanceto the remaining amount (p. 81, ll. 9-12; p. 83, ll. 3-14).
As to claim 13, Kraft teaches all the limitations of claim 12.
Kreft teaches,
wherein the interaction request message further comprises a program eligibility indicator (p. 81, ll. 9-12), and wherein the selection between the offline balance and the offline amount of program tokens is based on the program eligibility indicator (p. 81, ll. 9-12; p. 83, ll. 3-14), and wherein the method further comprises:
after receiving the interaction request message, if the program eligibility indicator indicates that the interaction is eligible for program tokens, determining whether or not there is a first sufficient amount of the offline amount of program tokens in the secure element and/or a second sufficient amount of the offline balance to satisfy the requested amount (p. 81, ll. 9-12; p. 83, ll. 3-14).
As to claim 14, Kraft teaches all the limitations of claim 12.
Kreft teaches,
wherein completing the interaction with the resource provider computer (p. 25. ll. 2-6) comprises:
generating an interaction response message comprising the amount equal to the requested amount and a user device secure element certificate (p. 25. ll. 2-6; p. 16, ll. 10-15);
transmitting the interaction response message to the resource provider computer (p. 25. ll. 2-6), wherein the resource provider computer receives the interaction response message and increases a resource provider offline balance based on the amount (p. 25. ll. 2-6).
As to claim 15, Kreft teaches all the limitations of claim 12.
Kreft teaches,
the secure element, wherein the secure element securely processes cryptographic operations for the user device (FIG. 17, p. 141, l. 20 “CASTOR or a (tamper-protected) semiconductor module”, p. 76, ll. 30-35 “Protocol messages sent via the VPC/VPN are encrypted and/or signed by the CASTOR”).
As to claim 16, Kreft teaches all the limitations of claim 12.
Kreft teaches,
wherein the user device and the resource provider computer are offline from a trusted third party computer (p. 74, ll. 13-15; p. 79, l.. 21-27; p. 16, ll. 10-15 “an issuing authority”).
Conclusion
References made of record, not relied upon, pertinent to Applicant’s disclosure include:
US 20190081796 A1 (Chow) disclosing management of cryptographically secure exchanges of data using permissioned distributed ledgers,
US 20200184455 A1 (Anantha ) disclosing managing payment sessions in a connected environment,
US 20230186296 A1 (Vines) disclosing enabling confidential and non-confidential transactions on a digital token architecture.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BROCK E TURK whose telephone number is (571)272-5626. The examiner can normally be reached Monday-Friday 9AM-5PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ryan Donlon can be reached at 571-270-3602. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BROCK E TURK/Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692 January 30, 2026