DETAILED ACTION
Acknowledgements
This office action is in response to the claims filed 11/17/2025.
Claims 1, 10 and 18 are amended.
Claims 2 and 3 are cancelled.
Claims 1, and 4-20 are pending.
Claims 1, and 4-20 have been examined.
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 .
Response to Arguments
Applicant's arguments filed 11/17/2025 have been fully considered but they are not persuasive.
101
Applicant argues “amended claim 1 clearly involve components that must be implemented on by a machine-a human mind cannot execute an application, let alone enter and exit an offline session.” Examiner disagrees.
First, the limitations recite the receipt of a trigger, the trigger indicating information about the connectivity and establishing an offline session. A human is capable of receiving information about connectivity and traditional transactions were processed offline sessions, secondly, the limitations do not recite entering or exiting offline sessions, just the receipt of information about entering an offline session, establishing an offline session and “causing” an application to end the offline session, the term “causing” is a broad term that can range from a generic computing device gaining internet connection to an arbitrary action like a call that “causes” what was an offline transaction to become online. The claims do not recite the concepts Applicant argues overcomes the 101 rejection. The rejection is maintained.
112
The claim recites the functions of a second computing system and an application executed on a user device, etc., which means one processor, is unable to perform the claimed steps. It is unclear whether the user device is the same as the second computing system to utilize a single processor. The rejection is maintained.
103
Ludin teaches receiving, by an application executed on a user device, a trigger indicating that the user device is offline; in response to receiving the trigger, establishing, by the application executed on the user device, an offline processing session (¶ 79-82);
Ludin – In diagram 300c, the steps and interactions may proceed similarly to diagram 300b up to cryptogram generation 330, and thus, user device 110 and POS device 130 may, during offline token processing, interact to perform and process transaction initiation 322, token polling 324, exchange of list and preference 326, token selection 328, and cryptogram generation 330. However, after cryptogram generation 330, diagram 300c may differ during offline token processing due to the lack of network connectivity of POS device 130 with transaction processor 140. In this regard, POS device 130 may be operating in an offline mode and/or without sufficient network connectivity with transaction processor 140…As such, during a transaction processing 342, user device 110 and POS device 130 may interact to negotiate an approval offline of the electronic transaction. (¶ 80, 81)
in response to determining that the user device is online (¶ 73, 74):
Ludin – diagram 300b shows how user device 110 may interact with POS device 130 for online token processing 320 with transaction processor 140. The operations and processing flow in diagram 300b for online token processing 320 may occur when POS device 130 has network connectivity with transaction processor 140 at a time of receiving a selected digital token from user device 110… For example, user device 110 may connect with POS device 110 and/or transmit a ping or other indication over short- range wireless communications to POS device 130. (¶ 73, 74)
the second computing system associated with the application and the background application (¶ 35-39, 51-55, 60-81);
Ludin– user device 110 includes other applications as may be desired in particular embodiments to provide features to user device 110. For example, the other applications may include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network 150, or other types of applications. … Other applications may include social networking applications, media viewing, and/or merchant applications… The full wallet token may also allow for offline token processing, for example, by providing data that may be validated and trusted by POS 204 without a network connection. (¶ 39, 61)
in response to receiving the token, causing the application to end the offline processing session (¶ 82)
Ludin – Thereafter, asynchronously from transaction processing 342 (e.g., at a later time, such as when network connectivity is restored and/or transaction processing of stored offline transaction data is performed), an asynchronous token processing 344 between POS device 130 and transaction processor 140 may occur. Asynchronous token processing 344 may include providing the offline digital token, application cryptogram, and/or transaction data to transaction processor 140 to effectuate a payment to POS device 130 and/or corresponding account. (¶ 82)
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 and 4-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Subject Matter Eligibility Standard
When considering subject matter eligibility under 35 U.S.C. § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter (101 Analysis: Step 1). Even if the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea) (101 Analysis: Step 2a(Prong 1), and if so, Identify whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluate those additional elements to determine whether they integrate the exception into a practical application of the exception. (101 Analysis: Step 2a (Prong 2). If additional elements does not integrate the exception into a practical application of the exception, claim still requires an evaluation of whether the claim recites additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception. If the claim as a whole amounts to significantly more than the exception itself (there is an inventive concept in the claim), the claim is eligible. If the claim as a whole does not amount to significantly more (there is no inventive concept in the claim), the claim is ineligible. (101 Analysis: Step 2b).
The 2019 PEG explains that the abstract idea exception includes the following groupings of subject matter: a) Mathematical concepts b) Certain methods of organizing human activity and c) Mental processes
Analysis
In the instant case, claim 1 is directed to a method, and claims 10 and 18 are directed to an article of manufacture.
Step 2a.1– Identifying an Abstract Idea
The claims recite the steps of “receiving… establishing… session…receiving, …data… generating, …data… retrieving…data… transmitting, …data… receiving, …data… generating, …token… transmitting, …token and receiving, …token … causing… end… session.” The recited limitations fall within the certain methods of organizing human activity grouping of abstract ideas, specifically, fundamental economic principles, for example, sending and receiving data towards facilitation a transaction. Accordingly, the claims recites an abstract idea.
See MPEP 2106.
Step 2a.2 – Identifying a Practical Application
The claim does not currently recite any additional elements or combination of additional elements that integrate the judicial exception into a practical application.
With regards to generating a token, According to the disclosure(29), “The token 116 may be a response token including the validation data 114, a digital signature, and/or a certificate.” The disclosure does not provide an algorithm of how the token is generated but the token appears to be a collection of data. Generating a collection of information is an insignificant extra solution activity of a generic computing device and not an additional element.
Accordingly, even in combination, these elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Mere instructions to apply the exception using generic computer components and limitations to a particular field of use or technological environment do not amount to practical applications. The claim in directed to an abstract idea.
Step 2b
The claim limitations recite “receiving… establishing… session…receiving, …data… generating, …data… retrieving…data… transmitting, …data… receiving, …data… generating, …token… transmitting, …token and receiving, …token … causing… end… session.” which are not additional elements and they amount to no more than mere instructions to apply the exception using a generic computer component. For the same reason these elements are not sufficient to provide an inventive concept. This is also determined to be well-understood, routine and conventional activity in the field. The Symantec, TLI, and OIP Techs, court decision cited in MPEP 2106.05(d)(II) indicates that mere receipt or transmission of data over a network is a well-understood, routine and conventional function when it is claimed in a merely generic manner, as it is here. Therefore, when considering the additional elements alone, and in combination, there is no inventive concept in the claim and thus the claim is not eligible.
Viewed as a whole, instructions/method claims recite the concept of a fundamental economic practice as performed by a generic computer. The claims do not currently recite any additional elements or combination of additional elements that amount to significantly more than the judicial exception. The elements used to perform the claimed judicial exception amount to no more than mere instructions to implement the abstract idea in a network, and/or merely uses a network as a tool to perform an abstract idea and/or generally linking the use of the judicial exception to a particular environment.
Claims 4-9, 11-17, 19 and 20 provide descriptive language surrounding the abstract idea. As such, these elements do not provide the significantly more to the underlying abstract idea necessary to render the invention patentable.
The claims do not, for example, purport to improve the functioning of the computer itself. Nor do they effect an improvement in any other technology or technical field. Therefore, based on case law precedent, the claims are claiming subject matter similar to concepts already identified by the courts as dealing with abstract ideas. See Alice Corp. Pty. Ltd., 573 U.S. 208 (citing Bilski v. Kappos, 561, U.S. 593, 611 (2010)).
The claims at issue amount to nothing significantly more than an instruction to apply the abstract idea using some unspecified, generic computer. See Alice Corp. Pty. Ltd., 573 U.S. 208. Mere instructions to apply the exception using a generic computer component and limitations to a particular field of use or technological environment cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Conclusion
The claim as a whole, does not amount to significantly more than the abstract idea itself. This is because the claim does not affect an improvement to another technology or technical filed; the claim does not amount to an improvement to the functioning of a computer system itself; and the claim does not move beyond a general link of the use of an abstract idea to a particular technological environment.
Accordingly, the Examiner concludes that there are no meaningful limitations in the claim that transform the judicial exception into a patent eligible application such that the claim amounts to significantly more than the judicial exception itself.
Dependent claims do not resolve the deficiency of independent claims and accordingly stand rejected under 35 USC 101 based on the same rationale.
Dependent claims 4-9, 11-17, 19 and 20 are also rejected.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 10-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 10 recites “A system for validating data exchanges via a response token during an offline processing session, comprising: one or more processors; and a computer-readable memory comprising instructions that,… receive, by an application executed on a user device, … receive, by a second computing system,… by a second computing system”. The claim is unclear and indefinite. The recited system contains one or more processors to perform the claims but does not contain a “second computing system” or an “application executed on a user device” but the claim recites the functions of a second computing system and an application executed on a user device, which means one processor, is unable to perform the claimed steps. It is unclear whether the user device is the same as the second computing system. The claim is unclear and indefinite. Dependent claims 11-17 are also rejected.
Claims 10 and 18 recite “A system for validating data exchanges via a response token during an offline processing session, comprising: one or more processors;”, “A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising:”, receiving, by an application executed on a user device, and “receive, by a second computing system,… by a second computing system,”. The claims are unclear and indefinite. The claims recite functions performed by multiple remote entities/devices, yet the independent claims recite that the functions are capable of being performed by a single processor. The claims are therefore unclear and indefinite. Dependent claims 11-17, 19 and 20 are also rejected.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4-8, 10-16, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Tadiparti (US 20180330371)(“ Tadiparti”), and further in view of Ludin et al. (WO 2025071896) (“Ludin”).
Regarding claim 1, Tadiparti discloses receiving, by an application executed on the user device, sensitive data associated with one or more data exchanges (¶ 57-76, 80, 81);
Tadiparti – a user of the client device 102 may initiate the process 300 at 302 by accessing a resource provider computer 104 and generating a request for a good or service…When initiating the transaction, the user may provide a mobile device identifier (e.g., a phone number) in a text input field of the webpage. (¶ 67)
generating, by a background application executed on the user device, validation data comprising an exchange count, a session identifier, and a device identifier (¶ 51-68, 76-81);
Tadiparti – the resource provider computer 104 may generate a transaction request that includes a number of transaction details related to the submitted transaction and may transmit that transaction request to the service provider computer 106. In particular, the transaction request may include at least the mobile device identifier provided by the user, an amount of the transaction, and indication of at least one resource involved in the transaction, and/or any other transaction-related information…For example, the second token may be generated from a stored token by using some function that involves a transaction counter or any other suitable dynamic element…For example, the second token may be generated from a stored token by using some function that involves a transaction counter or any other suitable dynamic element. (¶ 68, 76)
retrieving, by the application executed on the user device, the validation data from the background application (¶ 51-55, 67-76);
Tadiparti – Upon receiving this second request, the resource provider computer 104 may, upon determining that the stored token information is not expired, utilize the stored token information at the resource provider computer 104 to complete a second transaction. Similar to the first transaction, the resource provider computer 104 may generate an authorization request message using the received token information (e.g., the first token). (¶ 76)
transmitting, by the application executed on the user device, the validation data and the sensitive data to a first computing system (¶ 67-77);
Tadiparti – the service provider computer 106, upon receiving the transaction request, may identify the mobile device identifier within the transaction request. In some embodiments, the service provider computer 106 may determine whether the mobile device identifier is associated with a user account maintained by the service provider computer 106, and if so, may identify relevant account-related information to be appended to the transaction request. (¶ 69)
receiving, by a second computing system, the validation data from the first computing system (¶ 51-55, 65-70);
Tadiparti – the resource provider computer 106 may generate an authorization request message including the phone number. The phone number may be present in a data field normally reserved for a primary account number for a credit or debit card. In some cases, the phone number may be padded with characters to fill in the data field. The service provider computer 106 may then generate a message (e.g., a short messaging service (SMS) message) to be transmitted to the mobile device 110 associated with that phone number. The message may include a number of transaction details associated with the transaction to be completed. Once the message has been received at the mobile device 110, the mobile device 110 may be caused to display a notification to the user that includes at least a portion of the transaction details. …upon receiving the transaction information, the mobile device 110 may identify one or more token applications installed on the mobile device 110 that may be used to complete the transaction. (¶ 50, 70)
generating, by the second computing system, the token, the token digitally signed by the second computing system(¶ 50, 51, 61-67, 81-84);
Tadiparti – In some embodiments, the software on the mobile device 102 and the software in the processing network 114 and/or authorizing computer may be in synchronization and both computers may generate tokens for use and verification based upon common variable data elements such as the time, date, transaction amount, a counter, etc., and optionally with one or more static data elements such as a real account identifier, device identifier, etc.. The user may also be asked to select a token application installed on the mobile device 102 to complete the transaction. In this example, the token application may be a token application that generates or otherwise obtains (¶ 50, 51)
transmitting, by the second computing system, the token and some or all of the validation data to the first computing system; and (¶ 51-55, 60-77, 81-84);
Tadiparti – The token application may then generate a token, which may then be relayed to the service provider computer 106 by the mobile device 102. (¶ 50)
receiving, by the background application executed on the user device, the token from the first computing system; and (¶ 50-53, 61-65, 71);
Tadiparti – Once the payment token has been received at the service provider computer 106, the service provider computer 106 may relay that payment token to the resource provider computer 104 operated by online retailer (¶ 52)
Tadiparti does not disclose receiving, by an application executed on a user device, a trigger indicating that the user device is offline; in response to receiving the trigger, establishing, by the application executed on the user device, an offline processing session; in response to determining that the user device is online: the second computing system associated with the application and the background application in response to receiving the token, causing the application to end the offline processing session.
Ludin teaches receiving, by an application executed on a user device, a trigger indicating that the user device is offline; in response to receiving the trigger, establishing, by the application executed on the user device, an offline processing session (¶ 79-82);
Ludin – In diagram 300c, the steps and interactions may proceed similarly to diagram 300b up to cryptogram generation 330, and thus, user device 110 and POS device 130 may, during offline token processing, interact to perform and process transaction initiation 322, token polling 324, exchange of list and preference 326, token selection 328, and cryptogram generation 330. However, after cryptogram generation 330, diagram 300c may differ during offline token processing due to the lack of network connectivity of POS device 130 with transaction processor 140. In this regard, POS device 130 may be operating in an offline mode and/or without sufficient network connectivity with transaction processor 140…As such, during a transaction processing 342, user device 110 and POS device 130 may interact to negotiate an approval offline of the electronic transaction. (¶ 80, 81)
in response to determining that the user device is online (¶ 73, 74):
Ludin – diagram 300b shows how user device 110 may interact with POS device 130 for online token processing 320 with transaction processor 140. The operations and processing flow in diagram 300b for online token processing 320 may occur when POS device 130 has network connectivity with transaction processor 140 at a time of receiving a selected digital token from user device 110… For example, user device 110 may connect with POS device 110 and/or transmit a ping or other indication over short- range wireless communications to POS device 130. (¶ 73, 74)
the second computing system associated with the application and the background application (¶ 35-39, 51-55, 60-81);
Ludin– user device 110 includes other applications as may be desired in particular embodiments to provide features to user device 110. For example, the other applications may include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network 150, or other types of applications. … Other applications may include social networking applications, media viewing, and/or merchant applications… The full wallet token may also allow for offline token processing, for example, by providing data that may be validated and trusted by POS 204 without a network connection. (¶ 39, 61)
in response to receiving the token, causing the application to end the offline processing session (¶ 82)
Ludin – Thereafter, asynchronously from transaction processing 342 (e.g., at a later time, such as when network connectivity is restored and/or transaction processing of stored offline transaction data is performed), an asynchronous token processing 344 between POS device 130 and transaction processor 140 may occur. Asynchronous token processing 344 may include providing the offline digital token, application cryptogram, and/or transaction data to transaction processor 140 to effectuate a payment to POS device 130 and/or corresponding account. (¶ 82)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Tadiparti and Ludin in order to provide further protection for transaction information (Ludin; ¶ 1-4).
Regarding claims 4 and 13, Ludin teaches wherein the application executed on the user device retrieves the validation data from the background application in response to determining that the user device is online(¶ 15, 26, 78, 86).
Regarding claims 5 and 14, Ludin teaches wherein during the offline processing session, the application is permitted to receive sensitive data for a predetermined time period(¶ 25, 37, 66, 72, 73, 79, 81).
Regarding claim 6, Tadiparti discloses determining, by the background application, that the device identifier, the session identifier, and the data exchange count indicated in the token match the validation data (¶ 51-68, 76-81).
Regarding claims 7 and 15, Ludin teaches wherein the sensitive data and the validation data are encrypted using a public private key pair (¶ 25; claim 9, 15).
Regarding claims 8, 16 and 20, Tadiparti discloses wherein the sensitive data comprises transaction data (¶ 51-76, 80, 81).
Regarding claims 10 and 18, Tadiparti discloses receiving, by an application executed on a user device, sensitive data associated with one or more data exchanges (¶ 57-76, 80, 81);
Tadiparti – a user of the client device 102 may initiate the process 300 at 302 by accessing a resource provider computer 104 and generating a request for a good or service…When initiating the transaction, the user may provide a mobile device identifier (e.g., a phone number) in a text input field of the webpage. (¶ 67)
generating, by a background application executed on the user device, validation data comprising an exchange count, a session identifier, a device identifier (¶ 51-68, 76-81);
Tadiparti – the resource provider computer 104 may generate a transaction request that includes a number of transaction details related to the submitted transaction and may transmit that transaction request to the service provider computer 106. In particular, the transaction request may include at least the mobile device identifier provided by the user, an amount of the transaction, and indication of at least one resource involved in the transaction, and/or any other transaction-related information…For example, the second token may be generated from a stored token by using some function that involves a transaction counter or any other suitable dynamic element…For example, the second token may be generated from a stored token by using some function that involves a transaction counter or any other suitable dynamic element. (¶ 68, 76)
retrieving, by the application executed on the user device, the validation data from the background application (¶ 51-55, 67-76);
Tadiparti – Upon receiving this second request, the resource provider computer 104 may, upon determining that the stored token information is not expired, utilize the stored token information at the resource provider computer 104 to complete a second transaction. Similar to the first transaction, the resource provider computer 104 may generate an authorization request message using the received token information (e.g., the first token). (¶ 76)
transmitting, by the application executed on the user device, the validation data and the sensitive data to a first computing system (¶ 67-77);
Tadiparti – the service provider computer 106, upon receiving the transaction request, may identify the mobile device identifier within the transaction request. In some embodiments, the service provider computer 106 may determine whether the mobile device identifier is associated with a user account maintained by the service provider computer 106, and if so, may identify relevant account-related information to be appended to the transaction request. (¶ 69)
receiving, by a second computing system, the validation data from the first computing system, (¶ 51-55, 65-70);
Tadiparti – the resource provider computer 106 may generate an authorization request message including the phone number. The phone number may be present in a data field normally reserved for a primary account number for a credit or debit card. In some cases, the phone number may be padded with characters to fill in the data field. The service provider computer 106 may then generate a message (e.g., a short messaging service (SMS) message) to be transmitted to the mobile device 110 associated with that phone number. The message may include a number of transaction details associated with the transaction to be completed. Once the message has been received at the mobile device 110, the mobile device 110 may be caused to display a notification to the user that includes at least a portion of the transaction details. …upon receiving the transaction information, the mobile device 110 may identify one or more token applications installed on the mobile device 110 that may be used to complete the transaction. (¶ 50, 70)
generating, by the second computing system, a response token comprising the exchange count, the session identifier, and the device identifier (¶ 50, 51, 61-67, 81-84);
Tadiparti – In some embodiments, the software on the mobile device 102 and the software in the processing network 114 and/or authorizing computer may be in synchronization and both computers may generate tokens for use and verification based upon common variable data elements such as the time, date, transaction amount, a counter, etc., and optionally with one or more static data elements such as a real account identifier, device identifier, etc.. The user may also be asked to select a token application installed on the mobile device 102 to complete the transaction. In this example, the token application may be a token application that generates or otherwise obtains (¶ 50, 51)
transmitting, by the second computing system, the response token to the first computing system; and (¶ 51-55, 60-77, 81-84);
Tadiparti – The token application may then generate a token, which may then be relayed to the service provider computer 106 by the mobile device 102. (¶ 50)
receiving, by the background application executed on the user device, the response token from the first computing system(¶ 50-53, 61-65, 71);
Tadiparti – Once the payment token has been received at the service provider computer 106, the service provider computer 106 may relay that payment token to the resource provider computer 104 operated by online retailer (¶ 52)
Tadiparti does not disclose receiving, by an application executed on a user device, a trigger indicating that the user device is offline; in response to receiving the trigger, establishing, by the application executed on the user device, an offline processing session; the second computing system associated with the application and the background application.
Ludin teaches receiving, by an application executed on a user device, a trigger indicating that the user device is offline; in response to receiving the trigger, establishing, by the application executed on the user device, an offline processing session (¶ 79-82);
Ludin – In diagram 300c, the steps and interactions may proceed similarly to diagram 300b up to cryptogram generation 330, and thus, user device 110 and POS device 130 may, during offline token processing, interact to perform and process transaction initiation 322, token polling 324, exchange of list and preference 326, token selection 328, and cryptogram generation 330. However, after cryptogram generation 330, diagram 300c may differ during offline token processing due to the lack of network connectivity of POS device 130 with transaction processor 140. In this regard, POS device 130 may be operating in an offline mode and/or without sufficient network connectivity with transaction processor 140…As such, during a transaction processing 342, user device 110 and POS device 130 may interact to negotiate an approval offline of the electronic transaction. (¶ 80, 81)
the second computing system associated with the application and the background application (¶ 35-39, 51-55, 60-81);
Ludin– user device 110 includes other applications as may be desired in particular embodiments to provide features to user device 110. For example, the other applications may include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network 150, or other types of applications. … Other applications may include social networking applications, media viewing, and/or merchant applications… The full wallet token may also allow for offline token processing, for example, by providing data that may be validated and trusted by POS 204 without a network connection. (¶ 39, 61)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Tadiparti and Ludin in order to provide further protection for transaction information (Ludin; ¶ 1-4).
Regarding claim 11, Ludin teaches wherein the response token is protected using a public-private key pair (¶ 25; claim 9, 15).
Regarding claim 12, Ludin teaches wherein the application enters the offline processing session in response to determining that the user device is offline (¶ 76-81).
Claims 9, 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Tadiparti (US 20180330371)(“ Tadiparti”), in view of Ludin et al. (WO 2025071896) (“Ludin”) and further in view of Liu (US 20020143710) (“Liu”).
Regarding claims 9 and 17, Tadiparti discloses wherein the validation data further comprises respective data exchange identifiers, each associated with a respective data exchange and(¶ 51-68, 76-81). Neither Tadiparti nor Ludin teaches a hash of at least a portion of the sensitive data. Liu teaches a hash of at least a portion of the sensitive data(¶ 25, 26, 31). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Tadiparti, Ludin and Liu in order to provide transmission confirmations and information security (Liu; ¶ 1-4).
Regarding claim 19, Liu teaches wherein the sensitive data and the validation data are encrypted using hybrid public key encryption(¶ 36).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Chan et al., (US 20230334444) teaches offline transactions.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ILSE I IMMANUEL whose telephone number is (469)295-9094. The examiner can normally be reached Monday-Friday 9:00 am to 5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, NEHA H PATEL can be reached on (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 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.
/ILSE I IMMANUEL/Primary Examiner, Art Unit 3699