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 .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on March 02, 2026 is being considered by the examiner.
Status of the Claims
This is a Final Office Action rejection prepared in response to applicant’s amendments filed on
March 02, 2026.
Claims 1, 3-5, 8, 10-12, 15 and 17-19 are amended.
Claims 1-20 are pending.
Claim Interpretation
Nonfunctional language
Regarding claims 1, 8 and 15, the claimed limitations “…wherein the transaction framework provides a transaction token to a developer entity associated with the software application, and the transaction token corresponds to the transaction and includes information relevant to facilitate the reconciliation procedures, wherein the transaction token is generated by an entity independent from the computing device.” and “wherein, when the transaction is performed, the transaction token enables the reconciliation procedure procedures to be carried out.” only describes characteristics of the transaction token which is non-functional descriptive material that does not move to distinguish over prior art. When descriptive material is not functionally related to the substrate, the descriptive material will not distinguish the invention from prior art in terms of patentability. It has been held that where the printed matter is not functionally related to the substrate, the printed matter will not distinguish the invention from the prior art in terms of patentability.
Regarding claims 1, 8 and 15, the claimed limitation “… associated with the software application” only describes characteristics of the developer entity which is non-functional descriptive material that does not move to distinguish over prior art. When descriptive material is not functionally related to the substrate, the descriptive material will not distinguish the invention from prior art in terms of patentability. It has been held that where the printed matter is not functionally related to the substrate, the printed matter will not distinguish the invention from the prior art in terms of patentability.
Regarding claims 3, 10 and 17, the claimed limitation “…wherein the reconciliation procedures comprises: performing a second transaction that is based on the transaction; and providing, to the developer entity, a report that includes information associated with at least the second transaction.” only describes characteristics of the reconciliation procedures which is non-functional descriptive material that does not move to distinguish over prior art. When descriptive material is not functionally related to the substrate, the descriptive material will not distinguish the invention from prior art in terms of patentability. It has been held that where the printed matter is not functionally related to the substrate, the printed matter will not distinguish the invention from the prior art in terms of patentability.
Regarding claims 4, 11 and 18, the claimed limitation “wherein the transaction framework comprises an Application Programming Interface (API) that is communicatively coupled to: at least the software application and [[the]]a management entity that is associated with the computing device and separate from the software application executing on the computing device.” only describes characteristics of the transaction framework which is non-functional descriptive material that does not move to distinguish over prior art. When descriptive material is not functionally related to the substrate, the descriptive material will not distinguish the invention from prior art in terms of patentability. It has been held that where the printed matter is not functionally related to the substrate, the printed matter will not distinguish the invention from the prior art in terms of patentability.
Regarding claims 5, 12 and 19, the claimed limitation “…wherein the third request includes: a session identifier associated with the third request, a unique identifier associated with the software application, transaction type information that defines that the transaction will take place through the website rather than through the software application, and storefront information that includes locale, currency, tax, and commission information associated with the software application, the computing device, the transaction, or some combination thereof.” only describes characteristics of the third request which is non-functional descriptive material that does not move to distinguish over prior art. When descriptive material is not functionally related to the substrate, the descriptive material will not distinguish the invention from prior art in terms of patentability. It has been held that where the printed matter is not functionally related to the substrate, the printed matter will not distinguish the invention from the prior art in terms of patentability.
Regarding claims 7 and 14, the claimed limitation “…wherein the first request is based on a user of the software application seeking to engage in the transaction with the software application.” only describes characteristics of the first request which is non-functional descriptive material that does not move to distinguish over prior art. When descriptive material is not functionally related to the substrate, the descriptive material will not distinguish the invention from prior art in terms of patentability. It has been held that where the printed matter is not functionally related to the substrate, the printed matter will not distinguish the invention from the prior art in terms of patentability.
Intended use/result language
Regarding claims 1-2, 7-9, and 14-15, the claimed limitations below consist of language disclosing an intended use/result, so they are considered but given no patentable weight. (see MPEP 2111.05, MPEP 2114 and authorities cited therein). The reference is provided for the purpose of compact prosecution.
“to…” in “receiving a first request to perform a transaction” and “a second request to perform the transaction” in claims 1, 8 and 15.
“to…” in “the UI includes a first option to approve the transaction”, “receiving a selection of the first option to approve the transaction” and “in response to receiving the selection of the first option to approve the transaction” in claims 1, 8 and 15.
“to…” in “a second option to cancel the transaction” in claims 1, 8 and 15.
“to…” in “a website that corresponds to the developer entity” in claims 1, 8 and 15.
“that…” in “…that indicates the transaction will be performed independent from the software application executing on the computing device” in claims 1, 8 and 15.
“to…” in “the selection of the first option to approve the transaction” in claims 2, 9 and 16.
“to…” in “the software application seeking to engage in the transaction with the software application” in claims 7 and 14.
Conditional Language
Regarding claims 5, 12 and 19, the claimed limitation “…wherein the transaction token is provided in response to a third request issued by the transaction framework to a management entity that is associated with the computing device and separate from the software application executing on the computing device” is a conditional limitation which means that the claim limitation is only required when the stated condition is met.
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 5, 12 and 19 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 5, 12 and 19, recites the limitation “the transaction token is provided in response to a third request issued by the transaction framework to a management entity” which make the claims indefinite. Claims 1, 8 and 15 recite “a third request to the developer entity” while dependent claims 5, 12 and 19 recite “a third request …to a management entity”. Therefore, it is unclear whether claim 5, 12 and 19 refers to the same third request previously presented on claim 1, 8 and 15 with a different recipient entity, or whether claim 5, 12 and 19 means to introduce a different third request. Further, it is unclear whether the management entity is the same or distinct from, the developer entity. Accordingly, the claim is indefinite and rejected under 35 U.S.C. 112(b).
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an
abstract idea without significantly more.
Step 1: Claims 1-7 are directed to computer-implemented method (i.e., process are directed to a system (i.e., machine, and manufacture). Claims 8-14 are directed to a non-transitory computer readable storage medium (i.e., manufacture). Claims 15-20 are directed to a system (i.e., machine, and manufacture). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One: Claim 1, recites (i.e., sets forth or describes) an abstract idea. More specifically, the following bolded claim elements recite abstract ideas while the non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
A method for managing transaction tokens to facilitate reconciliation procedures, the method comprising, by a software application executing on a computing device:
receiving a first request to perform a transaction;
providing, to a transaction framework implemented on the computing device, a second request to perform the transaction;
displaying, under instruction of the transaction framework, a user interface (UI) that indicates the transaction will be performed independent from the software application executing on the computing device, wherein
the UI includes a first option to approve the transaction, and a second option to cancel the transaction;
receiving a selection of the first option to approve the transaction, wherein the transaction framework provides a transaction token to a developer entity associated with the software application, and the transaction token corresponds to the transaction and includes information relevant to facilitate the reconciliation procedures, wherein the transaction token is generated by an entity independent from the computing device;
in response to receiving the selection of the first option to approve the transaction,
loading, under instruction of the transaction framework, a web browser application;
loading, via the web browser application, a website that corresponds to the developer entity associated with the software application; and
providing, via the web browser application, a third request to the developer entity to perform the transaction, wherein,
when the transaction is performed, the transaction token enables the reconciliation procedures to be carried out.
Claim 1, recites (i.e., sets forth or describes) a method for managing and approving financial transactions using transaction tokens. The claim achieves this by receiving a request to perform a transaction, providing a second request to perform a transaction to a responsible party, displaying options to either approve or cancel the transaction, providing approval to the responsible party to perform the transaction, transferring a token from the responsible party to the executing party, executing the transaction, recording the transaction results and updating the token with the transaction results. Claims 8 and 15 are significantly similar to claim 1. As such claims 8 and 15 also recite an abstract idea. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas (i.e., fundamental economic practices and commercial or legal interactions).
Step 2A Prong Two: Because the claim recites abstract ideas, the analysis proceeds to
determine whether the claim recites additional elements that recite a practical application of the
abstract ideas. Here, the additional elements of at least one processor, at least one memory, a software application, a transaction framework, a computer device, a user interface (UI), a web browser application and a website merely serve as tools to perform the abstract idea (MPEP § 2106.05(f)). Therefore, the claim as a whole fail to recite a practical application of the abstract ideas.
Step 2B: Determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims: Claims 2-7, 9-14 and 16-20 have also been analyzed for subject matter
eligibility. However, claims 2-7, 9-14 and 16-20 also fail to recite patent eligible subject matter for the
following reasons:
Claims 2, 9 and 16 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the UI is hidden in response to receiving, via the UI, the selection of the first option to approve the transaction.
The non-bolded additional elements of an UI fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 3, 10 and 17 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
performing a second transaction that is based on the transaction; and
providing, to the developer entity, a report that includes information associated with at least the second transaction.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas.
Claims 4, 11 and 18 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the transaction framework comprises an Application Programming Interface (API) that is communicatively coupled to: at least the software application and a management entity that is associated with the computing device and separate from the software application executing on the computing device.
The non-bolded additional elements of an Application Programming Interface (API) and a software application fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 5, 12 and 19 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the transaction token is provided in response to a third request issued by the transaction framework to a management entity, that is associated with the computing device and separate from the software application executing on the computing device, wherein the third request includes: a session identifier associated with the third request, a unique identifier associated with the software application, transaction type information that defines that the transaction will take place through the website rather than through the software application, and storefront information that includes locale, currency, tax, and commission information associated with the software application, the computing device, the transaction, or some combination thereof.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional elements of software application, a website and a computing device fail to recite a practical application or significantly more than the abstract idea because they merely serve as tools to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Claims 6, 13 and 20 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
receiving transaction results from the developer entity; and
updating the transaction token based on the transaction results.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas.
Claims 7 and 14 recite the following bolded claim elements as abstract ideas while the
non-bolded claim elements recite additional elements according to MPEP 2106.04(a).
the first request is based on a user of the software application seeking to engage in the transaction with the software application.
The claim further recites an abstract idea. In other words, it recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The non-bolded additional element of software application fails to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP §2106.05(f)). Further, the additional elements, taken individually and in combination, do not result in the claim as a whole, amounting to significantly more than the judicial exception. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
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-5, 7-12 and 14-19 are rejected under 35 U.S.C. 103 as being unpatentable over Wang (US 2024009536 A1) in view of Vogel (US 9882892 B1), in further view of Graylin (US 20170154330 A1), in further view of Dhodapkar (US 11386418 B1).
Regarding claims 1, 8 and 15, Wang discloses:
receiving a first request to perform a transaction; (Wang ¶0030, A user installs (110) an app, then opens (120) the app for the first time. Wang ¶0094, When a user selects a digital component (510), e.g., by tapping on a touch screen within the boundaries of the displayed area of the digital component, the screen component of the client device can create and deliver (520) a tap event to the OS. Wang ¶0100, The user interacts (610) with the app. As described above, types of interaction can include installing or opening the app. Installation of the app can be determined, for example, by receiving an event from the operating system on the user's client device that indicates app install. Opening the app can be determined using various approaches, including receiving an event from the operating system on the user's client device that indicates an app has opened and/or receiving an event from the app indicating that the app has opened. In response to determining that the user has interacted with the app, the application sends (620) an initialization message to the DC SDK. The message can be, for example, a call to an API provided by the DC SDK that indicates to the DC SDK that an interaction has occurred. The initialization message can include an indication of a selected attribution model.)
providing, to a transaction framework implemented on the computing device, a second request to perform the transaction; (Wang ¶0030 A user installs (110) an app, then opens (120) the app for the first time. The app sends (130) a message to an attribution software development kit (SDK) that exists within the app. Wang ¶0095, The OS can then transmit (530) the tap event to the DC SDK. In response, the attribution SDK component of the DC SDK requests (540) that that trusted program perform the attribution using the selected attribution model, Wang ¶0101, The DC SDK requests (630) that the trusted program perform the attribution using the selected attribution model, e.g., last click attribution. As described above, the trusted program can support a wide variety of predefined attribution models, and if no attribution model is indicated, the trusted program can use an attribution model that has been configured to be a default model.)
receiving a selection of the first option to approve the transaction, wherein the transaction framework provides a transaction token to a developer entity associated with the software application, and (Wang ¶0073, The system detects (320) a user interaction with the digital component that initiates installation of the app on the user device. The system can detect the user interaction by monitoring events provided by an operating system running on the device. In some implementations, the system can register interest in events (e.g., installation or opening) related to interaction with the digital component. In response to receiving an event related to an interaction with the digital component, the system can determine whether the event initiates installation of the app. For example, if the digital component includes an “install” user interface button, and the system receives an interaction indicating that the install button was selected, the system can determine that the installation will begin on the client device and produce an event reflecting the install.¶0093, FIG. 5 is a flow diagram of an example process 500 for user component interaction attestation. (For brevity, "user component interaction attestation" can be called "click attestation," which can indicate that a user interacted with a digital component, e.g., but clicking on or otherwise selecting the component. Wang ¶0097, The trusted program can create (580) an interaction attestation token and return (590) the interaction attestation token to the DC SDK. The DC SDK can provide (595) the click attestation, including the interaction attestation token, to the content provider, for example, by transmitting the interaction attestation token over the network using a suitable networking protocol such as HTTP or HTTPS.)
Wang further discloses:
at least one processor; and at least one memory storing instructions (Wang ¶0112, he system 700 includes a processor 710, a memory 720, a storage device 730, and an input/output device 740. Each of the components 710, 720, 730, and 740 can be interconnected, for example, using a system bus 750. The processor 710 is capable of processing instructions for execution within the system 700. In one implementation, the processor 710 is a single-threaded processor. In another implementation, the processor 710 is a multi-threaded processor. The processor 710 is capable of processing instructions stored in the memory 720 or on the storage device 730.)
Wang does not disclose however Vogel teaches:
displaying, under instruction of the transaction framework, a user interface (UI) that indicates the transaction will be performed independent from the software application executing on the computing device, wherein the UI includes a first option to approve the transaction, and a second option to cancel the transaction; (col 7 lines 38-44, In particular, FIG. 3B shows a screenshot of a user interface for approving access to the resource on the second service for the user of the first service. For example, the user interface of FIG. 3B may be accessed from the second service by an authorized user of the second service, such as a user who is authenticated with the second service and has ownership of the resource. col 7 lines 47-59, In response to the entered passcode, the user interface of FIG. 3B includes information 310 related to the request represented by the passcode (e.g., “MyApp would like to access the company data of your QuickBooks company: casper 106”). For example, information 310 may allow the authorized user to identify the first service (e.g., “MyApp”) and the resource (e.g., company data of “casper 106”) associated with the request. The user may select a user-interface element 312 (e.g., “Allow”) to approve the request and enable access to the resource by the first service, or the user may select a user-interface element 314 (e.g., “Cancel”) to exit the user interface of FIG. 3B without approving the request.
It would have been obvious to one of ordinary skill in the art before the effective filing date of
the claimed invention to have modify Wang with Vogel’s teaching. One of ordinary skills in the art would have been motivated in order to provide information as well as options for handling the transactions and prevent unintended transactions to the user.
The combination of Wang and Vogel do not disclose, however Graylin teaches:
the transaction token corresponds to the transaction and includes information relevant to facilitate the reconciliation procedures, wherein the transaction token is generated by an entity independent from the computing device; (abstract, The checkout application receives a checkout token created by a checkout server that identifies the purchase transaction. ¶0095, In one aspect, the shopping application creates a checkout token that is used to uniquely identify a payment transaction by calling an API method hosted by the checkout server 600. Information about the transaction including product information, price and amount, and flow control information such as redirection URLs are provided as input parameters. The URLs can be used to set the redirection or switching back to the calling application or webpage. All the redirection and flow control can be performed with this checkout token, which is used to track the payment transaction. ¶0096, The application 504 calls 910 the checkout server 600, via the merchant server 904, and passes the information about the product, transaction amount, etc. The merchant server receives 912 a checkout token 914 from the checkout server 600.
loading, via the web browser application, a website that corresponds to the developer entity associated with the software application; and (¶0008, the customer's browser is temporarily redirected to a checkout webpage hosted by the payment service provider, such as the PayPal™ checkout process. The customer completes the transaction in the webpage hosted by the payment service provider. After the transaction, the browser is redirected back to the original online shopping website. ¶0079, The checkout server 600, optionally, may also include a checkout webpage for online checkout in a browser. ¶0097, The application 504 receives 916 the checkout token 914 and redirects 918 to the checkout application 502 with a custom URL and the checkout token as a parameter.)
providing, via the web browser application, a third request to the developer entity to perform the transaction, wherein, when the transaction is performed, the transaction token enables the reconciliation procedures to be carried out. (¶0097, Once authenticated, the customer 900 confirms the transaction with the checkout server 600, and the checkout application 502 calls 922 the checkout server 600 or website API 602 to complete the transaction identified by the checkout token. The checkout server 600 forwards 924 the transaction to a payment processor 926, which may include generating and forwarding the transaction/payment data including a dynamic cryptogram to the payment processor 926. The payment processor 926 returns 928 the transaction results to the checkout application 502, via the checkout server 600, illustrated as 930. When the transaction/payment data includes the cryptogram, the payment processor 926 may interpret the cryptogram to complete the transaction. ¶0098, The cryptogram may be generated using the checkout token, primary account number (PAN), expiration or expiry date (EXP), timestamp, and/or counter, at the time of the transaction. The resulting cryptogram generated at the time of the transaction can be based on a number of methods depending on the level of security required or desired, and be in a proper format recognizable by the payment processor 926. The cryptogram can be generated locally at the mobile device, or it can be generated from a secure server and delivered to the mobile application for use via the server. The MST is able to transmit different track data payloads with different cryptograms each in the proper magnetic card format recognizable by point of sale terminals. The PAN (whether static or dynamic/token) along with expiry date (which can be used as a token mode indicator to the card issuers' TSP) and the one time use cryptogram (can be used in the CVV2 field) can also be used for remote purchases via existing website or in-app checkout that require the field.
It would have been obvious to one of ordinary skill in the art before the effective filing date of
the claimed invention to have modify the combination of Wang and Vogel with Graylin’s teaching. One of ordinary skills in the art would have been motivated in order to ensure that the transaction token contains all the necessary information to perform the transaction and providing it to the third party to complete the transaction.
The combination of Wang, Vogel and Graylin do not disclose, however Dhodapkar teaches:
in response to receiving the selection of the first option to approve the transaction, loading, under instruction of the transaction framework, a web browser application; (Dhodapkar col 29 lines 20-23, Interface 830c shows the web browser, having executed the URL 831. The interface shows that a web server associated with the payment service is preparing to redirect the web browser through an element 833.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of
the claimed invention to have modify the combination of Wang, Vogel and Graylin with Dhodapkar’s teaching. One of ordinary skills in the art would have been motivated in order to ensure that the transaction is completed through the developer checkout webpage utilizing the token passed thru the selection of the approve option from the user interface.
Regarding claims 2, 9 and 16, the combination of Wang, Vogel, Graylin and Dhodapkar further disclose:
the UI is hidden in response to receiving, via the UI, the selection of the first option to approve the transaction (Dhodapkar col 27 lines 29-34, The payment application may transition to interface 820a which shows a transfer initiated screen. Interface 820a includes an image 826 associated with the recipient account and a message 827 explaining the details of the transaction including a customized note sent from the user to the recipient.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of
the claimed invention to have modify the combination of Wang, Vogel, Graylin and Dhodapkar with Dhodapkar’s additional teaching. One of ordinary skills in the art would have been motivated in order to prevent duplicate submissions and provide visual evidence that the transaction is being processed.
Regarding claims 3, 10 and 17, the combination of Wang, Vogel, Graylin and Dhodapkar further disclose:
the reconciliation procedures comprises: performing a second transaction that is based on the transaction; and providing, to the developer entity, a report that includes information associated with at least the second transaction. (Wang ¶0067, In some implementation, in response to the install, an attribution SDK, which can be a component of a DC SDK 217, can provide the attribution token 225, which can include a third attestation token 226, to an attribution processing apparatus 280. The attribution processing apparatus 280 can be managed by an independent entity and can include a technology platform implemented in hardware and/or software that automates the process of attributing content platforms 250 for providing digital components that result in the download and/or installation of applications. When the attribution processing apparatus 280 receives an attribution token, the attribution processing apparatus 280 can determine, store, and/or distribute the attributions for each content platform 250. The attribution can be in the form of a credit to the content platform 250, e.g., a monetary or non-monetary credit. Processing relating to installation is described further in reference to FIG. 6, below. Wang ¶0105, In some implementations, the trusted program can optionally provide (685) an event-level attribution notification, which can include install tokens, to a content platform. The content platform can create (690) aggregate measurements from the received attribution tokens. For example, if a content provider has received attribution credit related to multiple digital component impressions, the content provider can aggregate and report those statistics. In some implementations, the aggregated statistics do not include an indicator of the user of the client device, preserving the user's privacy. See ¶0103-0108)
Regarding claims 4, 11 and 18, the combination of Wang, Vogel, Graylin and Dhodapkar further disclose:
the transaction framework comprises an Application Programming Interface (API) that is communicatively coupled to: at least the software application and a management entity that is associated with the computing device and separate from the software application executing on the computing device. (Wang ¶0076, In some implementations, when the system determines that an install button was interacted with, e.g., pressed (as described above), the system can cause the operating system to install the application referenced by the digital component by calling an API provided by the operating system that notifies the operating system that an application should be installed. Wang ¶0097, The trusted program can create (580) an interaction attestation token and return (590) the interaction attestation token to the DC SDK. The DC SDK can provide (595) the click attestation, including the interaction attestation token, to the content provider, for example, by transmitting the interaction attestation token over the network using a suitable networking protocol such as HTTP or HTTPS. Wang ¶0100, In response to determining that the user has interacted with the app, the application sends (620) an initialization message to the DC SDK. The message can be, for example, a call to an API provided by the DC SDK that indicates to the DC SDK that an interaction has occurred.)
Regarding claims 5, 12 and 19, the combination of Wang, Vogel, Graylin and Dhodapkar further disclose:
the transaction token is provided in response to a third request issued by the transaction framework to a management entity that is associated with the computing device and separate from the software application executing on the computing device, wherein the third request includes: a session identifier associated with the third request, a unique identifier associated with the software application, transaction type information that defines that the transaction will take place through the website rather than through the software application, and storefront information that includes locale, currency, tax, and commission information associated with the software application, the computing device, the transaction, or some combination thereof. (Wang ¶0050, The payload can include data for the individual secure message. For example, if the secure message is a request for a digital component, the payload can include data that can be used to select a digital component. This payload could include the resource that has the digital component slot ( or a URL for the resource), information about a resource ( e.g., topic of the resource), information about the digital component slot ( e.g., the number of slots, the type of slots, the size of the slots, etc.), information about the client device 210 (e.g., type of device, geographic location of the client device 210, etc.) if the user has enabled this feature, and/or other appropriate information. Wang ¶0090, When an application directs the DC SDK to render a DC (410), the DC SDK requests (420) that the trusted program create an impression attestation token. The request can include metadata such as the purpose of the DC (e.g., to provide information about a referenced app ), an identifier for a referenced application ( e.g., a video player app ), and an attribution lookback window applicable to the current digital component. The lookback window directs the trusted program to cache the impression metadata for a specified duration. In some implementations, if a lookback window is not specified, the trusted program can cache the impression metadata for a configured time period. Upon receiving the request, the DC SDK can also store (430) the metadata in secure storage.)
Regarding claims 7 and 14, the combination of Wang, Vogel, Graylin and Dhodapkar further disclose:
the first request is based on a user of the software application seeking to engage in the transaction with the software application. (Wang ¶0030, A user installs (110) an app, then opens (120) the app for the first time. The app sends (130) a message to an attribution software development kit (SDK) that exists within the app. Wang ¶0094, When a user selects a digital component (510), e.g., by tapping on a touch screen within the boundaries of the displayed area of the digital component, the screen component of the client device can create and deliver (520) a tap event to the OS. Wang ¶0095, The OS can then transmit (530) the tap event to the DC SDK. Wang ¶0100, The user interacts (610) with the app. As described above, types of interaction can include installing or opening the app. Installation of the app can be determined, for example, by receiving an event from the operating system on the user's client device that indicates app install. Opening the app can be determined using various approaches, including receiving an event from the operating system on the user's client device that indicates an app has opened and/or receiving an event from the app indicating that the app has opened.)
Claims 6, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Wang, Vogel, Graylin and Dhodapkar as applied to claims 1, 8 and 15 above, and in further view of Harris (WO 2012145530 A2).
Regarding claims 6, 13 and 20, the combination of Wang, Vogel, Graylin and Dhodapkar do not disclose, however Harris teaches:
receiving transaction results from the developer entity; and updating the transaction token based on the transaction results (Harris ¶0042, The system may monitor usage of the tokens in one or more transactions by the users (e.g., user 102 and merchant 104). In response to data received from this monitoring, the system may update a given token from a first state (e.g., StateA of Token! or Token2) to a second state (e.g., StateB of Token! or Token2). Harris ¶0053, In one embodiment, the monitoring of the usage of the tokens further includes, responsive to receiving transaction data for two or more users of the plurality of users other than the first user, updating the first token to a different state based on purchases of the two or more users.
It would have been obvious to one of ordinary skill in the art before the effective filing date of
the claimed invention to have modify the combination of Wang, Vogel, Graylin and Dhodapkar with Harris’s teaching. One of ordinary skills in the art would have been motivated in order to ensure accurate status of the transaction and improve user feedback.
Response to Arguments
Claim Objections
Claim objections in the previous non-final action dated 11/03/2025 are withdrawn in light of the claim amendments.
Claim Rejections – 35 U.S.C. § 101
The applicant presents several assertions in regards to the 101 rejection on the previous office action. The basis for these assertions are based on the applicant’s argument on pages 10-11.
First, the applicant’s assertion that “the claims is integrated into the decidedly practical application of providing secure transactions using transaction tokens generated by a trusted entity, which are persistent and verifiable across a plurality of different entities, coupled with embedding reconciliation-relevant information in the tokens and requiring explicit user approval before issuing tokens.” is not persuasive and the examiner respectfully disagrees. The claim as amended is directed to receiving requests, forwarding the requests, displaying approval options, obtaining user content, issuing a transaction token, launching a browser and opening a website , and processing a transaction reconciliation utilizing a token. Theses steps together represent commercial transaction management, authorizations and data recording which constitute methods of organizing human activities. The alleged practical application represent an improvement to the transaction process and do not constitute an improvement to the computer technology.
Second, the applicant’s assertion that “the claim improves reliability (e.g., the transaction token acts as a persistent reference that links user authorization, execution events, and reconciliation events), auditability (e.g., the transaction token reduces ambiguity in attributing transactions to their initiating context), and security of transaction workflows to prevent fraudulent transactions, and thus are not directed to an abstract idea” is also not persuasive and the examiner respectfully disagrees. As mention with regard to the previous assertion, the improvement of reliability, auditability, and security of a transaction does not constitute an improvement to a technology unless explicitly recited on the claim. As amended the claim do not recite any specific or concrete technical mechanism to reduce fraud and improve security. Therefore, as amended the claims recite generic computer components implemented to perform the abstract idea of managing and approving financial transactions using transaction tokens.
Third, the applicant asserts that “the claims of this application address inefficiencies caused by different heterogeneous transaction execution environments” in a way similar to Visual Memory, LLC v. Nvidia Corp. The examiner finds this assertion also not persuasive and respectfully disagrees. The amended claim does not address heterogenous transaction environments in the same manner as claimed in Visual Memory, LLC v. Nvidia Corp. In the case of Visual Memory, LLC v. Nvidia Corp the claims were directed to an improvement to a computer memory system that enhanced performance across different processors. In contrast, the present claim recites steps for managing and coordinating transactions among multiple entities utilizing generic computer components. Further, the amended claim does not recite any new architecture, protocol or improvement to how the computer operate similar to the cited case.
Finally, the applicant asserts that the claims integrate the judicial exception into a practical application because “the claims unmistakably include additional limitations that do not simply "monopolize" the alleged abstract idea. The claims do not monopolize the use of transaction tokens nor reconciling transactions, or any judicial exception identified by the Office Action” and “The claims provide a technical improvement to a computing problem of correlating transaction initiation, execution, and reconciliation across distributed computing systems.” The examiner finds these assertions not persuasive and respectfully disagrees. The claim does not recite any technological advancement or inventive integration beyond applying the additional elements of at least one processor, at least one memory, a software application, a transaction framework, a computer device, a user interface (UI), a web browser application and a website as tools to an abstract concept and thus fail to impose any meaningful limit that would transform the abstract idea into a practical application.
As such, the amended claims fail to meet the eligibility requirements under 35 U.S.C. § 101. The rejection is therefore maintained.
Claim Rejections – 35 U.S.C. § 103
Applicant submits remarks and arguments geared toward the amendments. Examiner has carefully reviewed and considered Applicant’s remarks, however they ARE MOOT in light of the fact that they are geared towards the newly added claimed expression in the amendments.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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.
The following prior art made of record and not relied upon is considered pertinent to applicant's
disclosure.
US 11656746 B2 to Figueroa discloses: Aspects described herein may provide methods and systems for loading a second application from a first application while maintaining a consistent user experience. A technique may comprise receiving, by a client application, a first application from web servers. Upon receipt of a request for a second application, the first application may display a first loading display. The client application and/or the first application may then retrieve the second application and, in the process of retrieving the second application, cause the second application to display a similar loading display. When the client application switches from the first application to the second application, the client may display the second loading display. The similarity of the two loading displays may minimize the interruption perceived by the user. The loading displays may comprise indications of loading status, advertisements, interactive elements, or other content for display to the user.
US 11049101 B2 to Ansari et al. discloses: Embodiments of the invention are directed to systems and methods of providing secure remote transaction (SRT) transactions. In some embodiments, upon selection of a checkout element, a user may be identified with respect to a transaction to be completed. A number of accounts may then be identified in relation to that user. Upon selection of a particular account, the user may be authenticated using a facilitator application installed on a mobile computing device that supports authentication for the selected account. In some embodiments, the system may involve the use of a transaction-specific token generated upon receiving an authentication indicator from the facilitator application.
US 20240396884 A1 to Lin discloses: Systems and methods for enforcing compliance-program conformity during authorization-token generation are presented. Applications may be registered with an identity and access management (IAM) system. The registration of the application may include whether the application is subject to one or more compliance program(s). When an authorization token is requested from the IAM system, the IAM system may (a) determine the set of authorization information needed in the token, and (b) determine whether the application is subject to a compliance program. The IAM system may then check an approval source of record to determine whether the user was legitimately approved for the required authorization prior to granting an authorization token. If there is a mismatch between the approval source of record and the authorization information associated with the user identity, then the mismatch may cause certain mitigation actions to be performed.
US 20220012701 A1 to Ouellette et al. discloses: Systems and methods for facilitating payment service-based guest checkout with a merchant are disclosed. According to one embodiment, a method for facilitating payment service-based guest checkout with a merchant may include: (1) receiving, from a merchant's application or website, a redirect of an online interaction between the merchant and a customer; (2) retrieving, from an issuer payment service, wallet information comprising a plurality of payment options for the customer; (3) receiving a selection of one of the payment options; (4) communicating the selection of the payment option to the payment service for the issuer. The issuer payment service provides a session identifier to the merchant application website, the merchant application or website provides transaction information and the session identifier to a merchant payment host, the merchant payment host retrieves the selected payment option from the issuer payment service and conducts the transaction using the selected payment option.
US 20200250694 A1 to Mock et al. discloses: A system and method for matching transactions across heterogenous, multi-entity distributed computing platforms are disclosed. In more detail, a system and method for matching and settling offers in a computerized system involves receiving a plurality of created offers, receiving logic for honoring one or more of the plurality of created offers, creating a plurality of tokens and associating each of the plurality of offers with one or more of the created tokens, distributing one or more of the created offers through electronic messages to a plurality of potential customers, receiving an indication that a consumer has selected at least one of the plurality of offers, linking the consumer with a token associated with the selected at least one offer, upon a consumer transaction, deploying the logic for honoring offers to determine whether the selected offer will be honored; and receiving messages related to the propagation or efficacy of the offer.
WO 2020201898 A1 to Botes et al. discloses: A system and method for effecting a transaction using a mobile communications device of a user who is a receiver of transaction information are provided. The method comprises receiving a data set on the mobile communications device containing metadata, transaction information, a transaction public key and a digital signature. Verifying that the transaction public key has not expired and verifying the transaction information by checking the validity of the digital signature. If the digital signature is valid, verifying that the received transaction information is uniquely associated with a sender of the transaction information and the receiver of the transaction information by verifying a transaction association value. If the transaction association value is verified then displaying the transaction information to the user, receiving a user input to approve the transaction and transmitting the transaction information from the mobile communications device to a payment system to effect the transaction.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JANICE LOZA whose telephone number is (571)270-3979. The examiner can normally be reached Monday - Friday 7:30am - 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, Patrick McAtee can be reached at (571) 272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
/J.L./Examiner, Art Unit 3698
/STEVEN S KIM/Primary Examiner, Art Unit 3698
Prosecution Insights