Prosecution Insights
Last updated: July 17, 2026
Application No. 18/119,517

SYSTEMS AND METHODS FOR REMOTE TRANSACTION CONTROL USING A HIERARCHICAL DATA STRUCTURE

Non-Final OA §101§103
Filed
Mar 09, 2023
Examiner
CHOI, YUE YIN
Art Unit
3699
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
U.S. Bank National Association
OA Round
3 (Non-Final)
60%
Grant Probability
Moderate
3-4
OA Rounds
6m
Est. Remaining
69%
With Interview

Examiner Intelligence

Grants 60% of resolved cases
60%
Career Allowance Rate
88 granted / 147 resolved
+7.9% vs TC avg
Moderate +9% lift
Without
With
+9.0%
Interview Lift
resolved cases with interview
Typical timeline
3y 10m
Avg Prosecution
20 currently pending
Career history
178
Total Applications
across all art units

Statute-Specific Performance

§101
13.9%
-26.1% vs TC avg
§103
81.0%
+41.0% vs TC avg
§102
2.7%
-37.3% vs TC avg
§112
1.6%
-38.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 147 resolved cases

Office Action

§101 §103
DETAILED ACTION This office action is in response to applicant’s communication dated on 2/09/2026. 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 . Claims’ Status Claims 1, 13, 15 and 19 are amended. Claims 1-20 are pending for consideration in this office action. Response/Arguments 101 Applicant contends that the claims recite a specific technical solution for remotely controlling transactions using a hierarchical data structure. Examiner respectfully disagrees. The claims enabling a transaction processing server to store hierarchical data structures with parent and child profiles in claim 1 are recited at a high level of generality and are merely performing generic data management based on conventional file comparison/queries/lookup. The limitations do not provide a technical solution, they recite an improvement to a business process; "it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology. For example, in Trading Technologies Int'l V. IBG, 921 F.3d 1084, 1093-94, 2019 USPQ2d 138290 (Fed. Cir. 2019), the court determined that the claimed user interface simply provided a trader with more information to facilitate market trades, which improved the business process of market trading but did not improve computers or technology." MPEP 2106.05(a) (II). 103 Applicant’s rest of the argument is moot in light of a new art and new grounds of rejection due to amended claims. 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 not directed to patent eligible subject matter. The claimed matter is directed to a judicial exception (i.e. an abstract idea not integrated into a practical application) without significantly more. Step 1 (The Statutory Categories): Is the claim to a process, machine, manufacture or composition of matter? MPEP 2106.03 Per Step 1, claim 1 is a system claim; claim 13 is a method claim; claim 19 a non-transitory computer-readable storage medium claim. Thus, independent claims 1, 13, and 19 are directed to statutory subject matter. However, independent claims 1, 13, and 19 are rejected under 35 U.S.C. 101 because the claims recite an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application. Independent claim recites: (claims 1, 13, and 19 being similar in scope): Claim 1: storing, in the memory, a data structure comprising a parent profile comprising a parent value linked with one or more child profiles, each child profile comprising a child restriction and a child value linked with the parent value, the child restriction and the child value configured by an account associated with the parent profile; receiving, via the network interface from a computing device, a transaction request comprising a value, a transaction attribute, and an identifier of a first child profile of the one or more child profiles; using the identifier of the first child profile as a key in a lookup in a profile database stored in the memory to identify the first child profile that contains a matching identifier to the identifier of the first child profile in the transaction request; identifying, by the processor, the transaction attribute from preconfigured fields of the transaction request, the preconfigured fields dedicated to containing specific types of transaction data; determining whether to facilitate a transaction of the transaction request based on a first comparison between the value and a first child value of the first child profile and a second comparison between the transaction attribute and a first child restriction of the first child profile; and responsive to determining not to facilitate the transaction based on the first comparison and the second comparison, transmitting, via the network interface, a message to the computing device comprising instructions not to enable the transaction, wherein the computing device receives the message and restricts the transaction from occurring based on the instructions. Step 2A Prong 1: Does the claim recite an abstract idea, law of nature, or natural phenomenon? MPEP 2106.04 The limitations, as drafted, constitute a process that, under its broadest reasonable interpretation, covers managing, 1) Commercial Interaction in the form of business relation 2) managing personal behavior or relationships or interactions between people, under the Certain methods of organizing human activity, but for the recitation of generic computer components. The abstract idea, recited above, includes: storing a data structure comprising a parent profile comprising a parent value linked with one or more child profiles; receiving a transaction request comprising a value, a transaction attribute, and an identifier of a first child profile of the one or more child profiles; using the identifier of the first child profile as a key in a lookup in a profile database stored in the memory to identify the first child profile that contains a matching identifier to the identifier of the first child profile in the transaction request; identifying the transaction attribute from preconfigured fields of the transaction request; responsive to determining not to facilitate the transaction based on the first comparison and the second comparison, transmitting a data packet to the computing device restricting the transaction from occurring. If a claim limitation, under its broadest reasonable interpretation, covers performance of limitations of 1) commercial interactions or 2) managing personal behavior or relationships, but for the recitation of generic computer components, it falls within the Certain Methods of Organizing Human Activity – 1) Commercial Interaction in the form of business relation 2) managing personal behavior or relationships or interactions between people, grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Step 2A Prong 2: Does the claim recite additional elements that integrate the judicial exception into a practical application? MPEP 2106.04. The recited computing elements (claim 1: “a processor; a memory; a network interface; a transaction processing server”; claim 19: “a non-transitory computer-readable storage medium”) are recited at a high-level of generality, i.e. as generic computing element performing generic computer functions such that it amounts to no more than mere instructions to apply the exception using generic computer components (see MPEP 2106.05(f)). Simply adding a general purpose computer or computer components after the fact to an abstract idea does not integrate a judicial exception into a practical application or provide significantly more, since it amounts to no more than a recitation of the words "apply it" (or an equivalent) to implement an abstract idea or other exception on a computer, as set forth in MPEP 2106.05(f). The additional positive elements are: “each child profile comprising a child restriction and a child value linked with the parent value, the child restriction and the child value configured by an account associated with the parent profile; determining whether to facilitate a transaction of the transaction request based on a first comparison between the value and a first child value of the first child profile and a second comparison between the transaction attribute and a first child restriction of the first child profile” in claim 1; which amounts to linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). Accordingly, these additional claim elements, alone and in combination do not integrate the abstract idea into a practical application, because (1) they do not effect improvements to the functioning of a computer, or to any other technology or technical field (see MPEP 2106.05(a)); (2) they do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or a medical condition (see the Vanda memo); (3) they do not apply the abstract idea with, or by use of, a particular machine (see MPEP 2106.05(b)); (4) they do not effect a transformation or reduction of a particular article to a different state or thing (see MPEP 2106.05(c)); (5) they do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the identified abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designated to monopolize the exception (see MPEP 2106.05(e) and the Vanda memo). Therefore, per Step 2A, Prong Two, the claim is directed to an abstract idea not integrated into a practical application. Step 2B (The Inventive Concept): Does the claim recite additional elements that amount to significantly more than the judicial exception? MPEP 2106.05. Step 2B of the eligibility analysis concludes that the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. Examiner carries over the analysis from Step 2A related to the generic computing elements being no more than a recitation of the words "apply it" (or an equivalent) to implement an abstract idea or other exception on a computer (MPEP 2106.05(f)). The additional claim elements that are just “determining whether to facilitate ….based on a first comparison” link the use of the judicial exception to a particular technological environment or field of use” are mere instructions to implement an abstract idea on a computer, are carried over for further analysis in Step 2B. When the independent claims are considered as a whole, as a combination, the claim elements noted above do not amount to any more than they amount to individually. The operations appear to merely apply the abstract concept to a technical environment in a very general sense, i.e. an transaction processing server. The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified as an abstract idea. Therefore, it is concluded that the elements of the independent claims are directed to one or more abstract ideas and do not amount to significantly more. (MPEP 2106.05) Further, Step 2B of the analysis takes into consideration all dependent claims as well, both individually and as a whole, as a combination: Claims 2-12 are further directed to additional abstract ideas because the steps performed are simply narrowing the scope of the abstract idea of claim 1 since their individual and combined significance is still not significantly more than the abstract concept at the core of the claimed invention. For example, claim 2 further describes the steps of receiving a new value and aggregating the new value step, etc; claim 3 further describes steps of receiving a second transaction request; determining whether to facilitate a transaction; etc; claim 4 describes receiving a second child restriction; claim 5 adjusting the first child restriction; claim 6 describes proving a user interface for authentication; claim 7 determining to facilitate a transaction of the second transaction request based on a third comparison; claim 8 describes comparing the timestamp with a time or date range of the first child restriction; and claim 9 describes receiving a type of object of the transaction and a timestamp; claim 10 aggregating the first value, the second value, and an aggregated value for the parent profile; claim 11 describes adjusting the second value according to the first format and the second format; claim 12 describes receiving a message comprising a new value without an identifier identifying any child profiles, which all of the limitation are narrowing the steps performed in claim 1. Moreover, the claims in the instant application do not constitute significantly more also because the claims or claim elements only serve to implement the abstract idea using computer components to perform computing functions (Enfish, see MPEP 2106.05(a)). Specifically, the computing system encompasses general purpose hardware and software modules. The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified in the independent claims as an abstract idea. The fact that the associated computing devices are facilitating the abstract concept is not enough to confer statutory subject matter eligibility. In sum, the additional elements do not serve to confer subject matter eligibility to the invention since their individual and combined significance is still not heavier than the abstract concepts at the core of the claimed invention. Similarly for other dependent claims 14-18 and 19-20, which depends on other respective independent claims 13 and 19. Therefore, it is concluded that the dependent claims of the instant application do not amount to significantly more either. (see MPEP 2106.05) In sum, claims 1-20 are rejected under 35 USC 101 as being directed to non-statutory subject matter. 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 of this title, 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-8, 13, and 17-19 are rejected under 35 U.S.C 103 as obvious over Sahni et al. (US10445739B1) in view of Goodwin et al. (US20210326877A1), and further in view of Srinivasan et al. (US20150112855A1) With respect to claim 1, 13, and 19 Sahni teaches: each child profile comprising a child restriction (col.5ln9-ln21, In an alternative arrangement, the primary account holder can fund a secondary wallet in the mobile wallet system 100 with the funds of the account. The secondary wallet is essentially a second account in the name of the secondary user. Although the first arrangement is described (the secondary user arrangement) for simplicity's sake, the described systems and methods can be applied to the second arrangement (the second account/wallet arrangement). Accordingly, in arrangements where a new second account is created instead of adding a second authorized user to an existing account, the second account can be subject to the same rules and limitations as the secondary user's access rights are subject to in the described arrangement; see also col.9ln25-col.9 ln33., Yet another type of rule or limit the primary account holder can impose on secondary users are restrictions of purchases by the secondary users from the account based on the purpose of the purchase. In some arrangements, the primary account holder can request that the secondary user provide a purpose for each purpose prior to the purchase being authorized by the mobile wallet client application. Similar to the restrictions on the types of goods and services and the types of stores, the restrictions based on the purposes of the purchase can work two different ways. A first way is for the primary account holder to indicate acceptable purchase purposes. For example, an employer (primary account holder) may be in the delivery business and provide his employee delivery drivers (secondary users) access to a spending account via the mobile wallet client application. The employer may limit the employees' spending to purchases for refueling purposes. A second way is for the primary account holder to indicate non-acceptable purchase purposes.), the child restriction and the child value configured by an account associated with the parent profile (col.8 ln8-ln14, Another type of rule or limit the primary account holder can impose on secondary users are restrictions on the types and goods and services the secondary user can purchase. The restrictions on the types of goods and services may be implemented in different ways. A first way is for the primary account holder to indicate acceptable types of goods and services for the secondary users to purchase.); receiving, via the network interface from a computing device, a transaction request comprising a value, a transaction attribute, and an identifier of a first child profile of the one or more child profiles (col.13 ln31-col.14 ln1, Referring to FIG. 4, a flow diagram of a method 400 of processing a purchase request by a secondary user of an account via a mobile wallet system (e.g., system 100) is shown according to an exemplary embodiment………… The purchase request includes, among other purchase information, an identification of the merchant, an identification of the person attempting to make the purchase (e.g., in the present case, the person is the secondary user), an identification of the account (e.g., in the present case, the account is the account owned by the primary account holder), and a cost of the purchase.); determining whether to facilitate a transaction of the transaction request based on a first comparison between the value and a first child value of the first child profile and a second comparison between the transaction attribute and a first child restriction of the first child profile (col.14 ln18-ln33, The purchase information of the purchase request is compared to the identified rules and limitations associated with the secondary user (406). The rules and limitations set by the primary account holder may relate to spending limits, types of goods and services restrictions, store specific restrictions, purpose of purchase rules, purchase timing rules, geographic restrictions, group purchase rules, or a combination thereof. Each of these rules and limitations are explained above in further detail. If the purchase falls outside of the boundaries of one of the rules or limitations, the purchase will be rejected by the financial institution. For example, if one of the limitations relates to a spending limit of $100 and the purchase is for $150, the financial institution will reject the purchase request because the secondary user is not authorized to make the purchase based on the limit set by the primary account holder.); responsive to determining not to facilitate the transaction based on the first comparison and the second comparison, transmitting, via the network interface, a message to the computing device comprising instructions not to enable the transaction, wherein the computing device receives the message and restricts the transaction from occurring based on the instructions (col.14 ln37-ln63, The backend system determines if the purchase is allowed (404). The backend system transmits a purchase authorization decision to the merchant computing system based at least in part on the determination of 404. If the purchase is determined to be allowable at 404 (e.g., the purchase is in compliance with the rules and limitations), an approval is communicated to the merchant (406). The approval signals to the merchant that the purchase is allowed…… If the purchase is determined to be not allowable at 404 (e.g., the purchase is not in compliance with the rules and limitations), a rejection is communicated to the merchant (414). The rejection signals to the merchant that the purchase is not allowed such that the purchase is not completed by the merchant.) Sahni doesn’t explicitly disclose, but Goodwin teaches: using the identifier of the first child profile as a key in a lookup in a profile database stored in the memory to identify the first child profile that contains a matching identifier to the identifier of the first child profile in the transaction request ([0050], Continuing with the above example, the secondary user may receive the identifier for the second account (e.g., the token) on his or her client device 102. Upon receiving the token, the secondary user may wish to complete a purchase related to the project to which the secondary user has been assigned. In this example, the secondary user may approach a resource provider and may, upon initiating a transaction with that resource provider, provide the token for the secondary account to the resource provider server 106 to complete the transaction (e.g., via the transaction application 112). The resource provider server 106 may then generate an authorization request message to be provided to the transaction processing platform 110 for authorization. In this example, the authorization request message may be received by the service provider server 110(A), which may consult the provided itinerary and dynamically generate a set of protocols for the secondary account. The service provider server 110 may then determine whether the requested transaction is in compliance with the dynamically-generated set of protocols and may either provide authorization for services for the transaction or forward the generated set of protocols to the authorization entity along with the authorization request message.); It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Sahni with the teaching of Goodwin as they relate to a system/method of managing primary and secondary payment accounts, similar to parent and child payment relationships through use of rules and limitation. One of ordinary skill in the art before effective filing date of the claimed invention would have recognized the system of allowing a master wallet associated with a primary account holder to provide limited access for a secondary users in Sahni to include a method of matching secondary identifier to the same identifier in the transaction request as taught in Goodwin for the predicated result of an improved system of allocating funds restriction and usage between parent and child accounts. Sahni in view of Goodwin don’t explicitly disclose, but Srinivasan teaches: a processor coupled with memory and a network interface ([0039]) storing, in the memory, a data structure comprising a parent profile comprising a parent value linked with one or more child profiles ([0015], The solution may involve designating an account including a balance as a parent account, and designating other accounts to be used to access the balance as child accounts. When a communication is initiated using one of the child accounts, a portion of the parent account balance may be transferred to the child account, and added to the balance associated with the child.) each child profile comprising ([0015], The solution may involve designating an account including a balance as a parent account, and designating other accounts to be used to access the balance as child accounts. When a communication is initiated using one of the child accounts, a portion of the parent account balance may be transferred to the child account, and added to the balance associated with the child.) identifying, by the processor, the transaction attribute from preconfigured fields of the transaction request, the preconfigured fields dedicated to containing specific types of transaction data ([0042], In some cases, the account may be designated as a child account by the inclusion of a row associated with the account in the account relationships 126. The account may also be indicated as a child account by a value in a type field in the account record; see also [0020], In some implementations, the amount to transfer may be preconfigured, or the amount may be computed based on attributes of the communication, such as the intended destination, the rate associated with the communication, or other attributes.); It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Sahni/Goodwin with the teaching of Srinivasan as they relate to a system/method of managing parent and child payment transaction relationships through use of rules and limitation. One of ordinary skill in the art before effective filing date of the claimed invention would have recognized the combined systems of Sahni/Goodwin, for example allowing a master wallet associated with a primary account holder to provide limited access for a secondary users in Sahni, to include a method of allowing a certain amount of funds transferred from the parent account to the child account as taught in Srinivasan for the predicated result of an improved system of allocating funds restriction and usage between parent and child accounts. With respect to claim 5 and 17 The combination of Sahni, Goodwin, and Srinivasan teaches the limitation of claim 1 and 13 respectively. Sahni further teaches: receiving, via the network interface from a client device, a request to change the first child restriction; and adjusting the first child restriction according to the request (col.7 ln3-ln19, Referring to FIG. 2C, a user interface 220 for modifying an access type (e.g., setting up new rules and limits or removing existing rules and limits) for a secondary user via the mobile wallet client application 128 is shown according to an exemplary embodiment. The primary account holder is directed to the user interface 220 by interacting with button 206 of user interface 200. Through the user interface 220, the primary account holder can limit a secondary user's access to the funds in the account by providing spending rules and limits for each secondary user. As shown in FIG. 2C, Jim Smith has limited access to the primary account holder's account. Specifically, Jim Smith is limited to spending $500 a month out of the account and is limited to only purchases at gas stations within California. Any one of the three rules can be edited (e.g., changed from California to California and Nevada, spending limit increased or decreased, etc.) or deleted via the user interface 220.) With respect to claim 6 and 18 The combination of Sahni, Goodwin, and Srinivasan teaches the limitation of claim 5 and 17 respectively. Sahni further teaches: providing a user interface to the client device comprising fields for authentication; authenticating a user according to credentials associated with the account associated with the parent profile (col.11 ln17-ln37, Method 300 begins when primary account holder login information is received (302). The primary account holder login information is received by the backend system from a user's computing device (such as a mobile device). The receipt of the primary account holder login information signals to the backend system that the primary account holder is attempting to access his accounts through a financial institution application (e.g., mobile wallet client application 128)……After the primary account holder login information is verified, the user of the computing device is authenticated as the primary account holder, and the user is provided access to the primary account holder's accounts. Access to the accounts allows the user to view account information for each of the accounts (e.g., balance information, transaction information, etc.), perform transactions via the primary account holder's mobile wallet, add secondary users to specific accounts, assign limits and rules to secondary users on accounts, and the like.); and receiving the request to change the first child restriction from the account associated with the parent profile (col.7 ln3-ln19, Referring to FIG. 2C, a user interface 220 for modifying an access type (e.g., setting up new rules and limits or removing existing rules and limits) for a secondary user via the mobile wallet client application 128 is shown according to an exemplary embodiment. The primary account holder is directed to the user interface 220 by interacting with button 206 of user interface 200. Through the user interface 220, the primary account holder can limit a secondary user's access to the funds in the account by providing spending rules and limits for each secondary user. As shown in FIG. 2C, Jim Smith has limited access to the primary account holder's account. Specifically, Jim Smith is limited to spending $500 a month out of the account and is limited to only purchases at gas stations within California. Any one of the three rules can be edited (e.g., changed from California to California and Nevada, spending limit increased or decreased, etc.) or deleted via the user interface 220.) With respect to claim 7 The combination of Sahni, Goodwin, and Srinivasan teaches the limitation of claim 1. While the prior arts do not explicitly disclose: receiving, via the network interface from a second computing device, a second transaction request comprising a second value, a second transaction attribute, and an identifier of a second child profile of the one or more child profiles; determining to facilitate a transaction of the second transaction request based on a third comparison between the second value and a second child value of the second child profile and a fourth comparison between the second transaction attribute and a second child restriction of the second child profile; and responsive to determining to facilitate the transaction based on the third comparison and the fourth comparison, transmitting, via the network interface, a second data packet to the second computing device enabling the transaction to occur, but it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have a duplication of parts of the same limitation. It is well within the knowledge of one of ordinary skill to duplicate the steps of “receiving a transaction request comprising a value….; determining whether to facilitate a transaction of the second transaction request….; response to determining not to facilitate the transaction based on the first comparison…..“ as claimed in claim 1, which are a similar duplicate of claim 7. Furthermore, the mere duplication of parts has no patentable significance and does not produce new and unexpected results. For example, the processing of the secrets are performed in parallel and have no bearing on each other. See MPEP 2144.04 VI B; In re Harza, 124 USPQ 378 (CCPA 1960). With respect to claim 8 The combination of Sahni, Goodwin, and Srinivasan teaches the limitation of claim 1. Sahni further teaches: wherein the processor receives the transaction attribute by receiving a timestamp of the transaction, the processor: comparing the timestamp with a time or date range of the first child restriction; and determining not to facilitate the transaction responsive to determining the timestamp is outside of the time or date range (col.9 ln38-ln49, A further rule or type of limit the primary account holder can impose on secondary users is restrictions on the timing of purchases made by the secondary users. The timing restriction may relate to allowing or prohibiting purchases during designated time periods. The designated time period may be a time range (e.g., from 12 am through 7 am), a day of the week, a month of the year, holidays, or a combination thereof. For example, an employer (primary account holder) may prohibit employees (secondary users) from making purchases during non-business hours (e.g., no purchases allowed all day Saturday and Sunday and between the hours of 5:01 pm through 8:59 am Mondays through Fridays). Claims 2, 3, 14, 15, and 20 are rejected under 35 U.S.C 103 as obvious over Sahni et al. (US10445739B1) in view of Goodwin et al. (US20210326877A1) in view of Srinivasan et al. (US20150112855A1), and further in view of Fenichel et al. (US20220180344A1). With respect to claim 2, 14, and 20 The combination of Sahni, Goodwin, and Srinivasan teaches the limitation of claim 1, 13, and 19 respectively. The combination doesn’t explicitly disclose, but Fenichel teaches: receiving, via the network interface from a client device, a new value and an identifier of the first child profile; and aggregating the new value with the child value and, separately based on a link between the parent value and first child value, the new value with the parent value ([0049], the first entity may submit payments or contributions towards an account balance of the parent account (e.g., for one or more transactions that are also associated with the simulated account) without relying on a payment from the simulated account. For example, the first entity may be enabled to submit payments and/or manage the parent account via the first client device. A payment towards the account balance of the parent account submitted by the first entity may not change an account balance of the simulated account. In this way, the first entity may be enabled to manage the parent account (e.g., and avoid missing payments associated with the parent account), while still enabling the second entity to manage the simulated account based on the real world transactions completed using resources of the parent account.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Sahni/Goodwin/ Srinivasan with the teaching of Fenichel as they relate to a system/method of managing parent and child payment transaction relationships through use of rules and limitation. One of ordinary skill in the art before effective filing date of the claimed invention would have recognized the combined systems of Sahni/Goodwin/Srinivasan, for example allowing a master wallet associated with a primary account holder to provide limited access for a secondary users in Sahni, to include the method of aggregating values between parent and child as taught in Fenichel for the predicated result of an improved system of allocating funds restriction and usage between parent and child accounts. With respect to claim 3 and 15 The combination of Sahni, Goodwin, and Srinivasan teaches the limitation of claim 2 and 14 respectively. While the prior arts do not explicitly disclose: receiving, via the network interface from the computing device, a second transaction request comprising a second value, a second transaction attribute, and the identifier of the first child profile of the one or more child profiles; determining whether to facilitate a transaction of the second transaction request based on a third comparison between the second value and the aggregated value of the first child profile and a fourth comparison between the transaction attribute and the first child restriction of the first child profile; and responsive to determining to facilitate the transaction of the second transaction request based on the third comparison and the fourth comparison, transmitting, via the network interface, a data packet to the computing device enabling the transaction to occur, but it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have a duplication of parts of the same limitation. It is well within the knowledge of one of ordinary skill to duplicate the steps of “receiving a transaction request comprising a value….; determining whether to facilitate a transaction of the second transaction request….; response to determining not to facilitate the transaction based on the first comparison…..“ as claimed in claim 1, which are a similar duplicate of claim 3. Furthermore, the mere duplication of parts has no patentable significance and does not produce new and unexpected results. For example, the processing of the secrets are performed in parallel and have no bearing on each other. See MPEP 2144.04 VI B; In re Harza, 124 USPQ 378 (CCPA 1960). Claims 4 and 16 are rejected under 35 U.S.C 103 as obvious over Sahni et al. (US10445739B1) in in view of Goodwin et al. (US20210326877A1) in view of Srinivasan et al. (US20150112855A1), and further in view of Kallugudde (US20200111081A1). With respect to claim 4 and 16 The combination of Sahni, Goodwin, and Srinivasan teaches the limitation of claim 1 and 13 respectively. The combination doesn’t explicitly disclose, but Kallugudde teaches: receiving, via the network interface, a second child restriction and an identifier of the first child profile; and inserting the second child restriction into the first child profile (see [0031-0032]) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Sahni/Goowdwin/Srinivasan with the teaching of Kallugudde as they relate to a system/method of managing parent and child payment transaction relationships through use of rules and limitation. One of ordinary skill in the art before effective filing date of the claimed invention would have recognized the combined systems of Sahni/Goodwin/Srinivasan, for example allowing a master wallet associated with a primary account holder to provide limited access for a secondary users in Sahni, to include the method of integrating a second child restriction into the first child profile as taught in Kallugudde for the predicated result of an improved system of allocating funds restriction and usage between parent and child accounts. Claim 9 is rejected under 35 U.S.C 103 as obvious over Sahni et al. (US10445739B1) in view of Goodwin et al. (US20210326877A1) in view of Srinivasan et al. (US20150112855A1), and further in view of Wu et al. (US20230419292A1). With respect to claim 9 The combination of Sahni, Goodwin, and Srinivasan teaches the limitation of claim 1. The combination doesn’t explicitly disclose, but Wu teaches: receiving the transaction request comprising a type of object of the transaction and a timestamp of the transaction ([0085], Lucy, the second user, then attempts to make a purchase for $20 of gas, which is received from the merchant by user profile system 320 (block 114). The user profile system 320 determines that the transaction is not allowed because of the overall spend limit of $75, and a purchase of $20 would be over the limit (see block 216A). Therefore, the user profile system 320 does not charge the transaction, but, because the spend limit is setup as a soft limit (see block 216B), an alert of Lucy's transaction for gas is sent to the primary user's device 402 (see block 216C). The primary user allows the transaction (see block 216D) using the primary user device 402. Lucy, the second user, is then allowed to make a purchase within a short time after the original attempt (see block 218B). The second transaction information is received by user profile system 320 (block 114) and is allowed because it is within the soft limit attributes (block 116), and is charged to the PAN (block 118). The second transaction is then associated with the second user profile account (block 120) and the system generates and sends a second GUI with the additional balance and transaction data to the primary user's smartphone (blocks 122 and 124); comparing the type of object to a second child restriction of the first child profile; responsive to determining the type of object does not satisfy the second child restriction, comparing the timestamp with a time or date range of the first child restriction ([0032], Additionally, the user profile system 320 may receive more than one transaction, associated with more than one secondary user account, with each user account with different attributes and different VCNs. The user profile system 320 may use the transaction information to determine which user profile to attribute the charge to. For example, in an office setting, a manager may be the primary user with a secretary as the second user. The secretary's profile may contain attributes only allowing the secretary to purchase office supplies under $200. The third user may be a janitor who is allowed to purchase building materials up to $500. The fourth user may be a salesman who is allowed to purchase meals at restaurants up to $300; see [0026] on description of attributes); determining not to facilitate the transaction responsive to determining the timestamp is outside of the time or date range ([0095], The system of clause 6, wherein when the second directions are not received within a time threshold, the first transaction is declined.) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Sahni/ Goodwin/Srinivasan with the teaching of Wu as they relate to a system/method of managing parent and child payment transaction relationships through use of rules and limitation. One of ordinary skill in the art before effective filing date of the claimed invention would have recognized the combined systems of Sahni/ Goodwin/Srinivasan, for example allowing a master wallet associated with a primary account holder to provide limited access for a secondary users in Sahni, to include the system of facilitating transaction based on time as taught in Wu for the predicated result of an improved system of allocating funds restriction and usage between parent and child accounts. Claim 10 is rejected under 35 U.S.C 103 as obvious over Sahni et al. (US10445739B1) in view of Goodwin et al. (US20210326877A1) in view of Srinivasan et al. (US20150112855A1) in view of Kallugudde (US20200111081A1), and further in view of Kootale (US6988104B2). With respect to claim 10 The combination of Sahni, Goodwin, and Srinivasan teaches the limitation of claim 1. The combination doesn’t explicitly disclose, but Kallugudde teaches: receiving, via the network interface, a first value from a first client device and a second value from a second client device, the first value having a first format and the second value having a second format ([0028-0031], Each of the child tokens 113-115 may be created by the tokenization platform 130 and may be mapped to the parent token 112 at the tokenization platform 130 and also at the mobile wallet application on the mobile device 110. To create the child tokens 113-115, the tokenization platform 130 may generate a new/different token for each child token with respect to the parent token 112 such that each child token 113-115 appears to be a different payment card when read by a POS terminal. ….According to various embodiments, the child tokens 220A and 220B may each include different token values which include different non-sensitive elements 222A and 222B with respect to the non-sensitive element 212 of the parent token 210. Accordingly, the non-sensitive elements 222A and 222B appear as if they are linked to different payment cards than the parent token 210 and than each other.); It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Sahni/ Goodwin/Srinivasan with the teaching of Kallugudde as they relate to a system/method of managing parent and child payment transaction relationships through use of rules and limitation. One of ordinary skill in the art before effective filing date of the claimed invention would have recognized the combined systems of Sahni/Goodwin/Srinivasan, for example allowing a master wallet associated with a primary account holder to provide limited access for a secondary users in Sahni, to include the method of receiving first and second value in different formats as taught in Kallugudde for the predicated result of an improved system of allocating funds restriction and usage between parent and child accounts. Sahni in view of Goodwin in view of Srinivasan in view of Kallugudde don’t explicitly disclose, but Kootale teaches: aggregating the first value, the second value, and an aggregated value for the parent profile to generate an updated aggregated value for the parent profile; and storing the updated aggregated value in the parent profile in the data structure (see claim 1, determining new values for one or more parents in the organization of data; determining current values for one or more children in the organization of data, each child being hierarchically related to one or more of the parents; determining the relationship between each parent and its children; determining a variation for each child; and determining a new value for each child by allocating the new values of the parents to the children based on the parent-child relationships, the current values of the children, and either the sum of the variations of the children or a matrix of the variations of the children; see also col.1 ln23-29, the data concerning various products or other items may be stored hierarchically in data storage or derived in a hierarchical fashion. Furthermore, the data may be stored at a storage location associated with multiple dimensions, such as a product dimension (the storage location being associated with a particular product or product component)….) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Sahni/Goodwin/ Srinivasan/ /Kallugudde with the teaching of Kootale as they relate to a system/method of managing parent and child payment transaction relationships through use of rules and limitation. One of ordinary skill in the art before effective filing date of the claimed invention would have recognized the combined systems of Sahni/Goodwin/Srinivasan /Kallugudde, for example allowing a master wallet associated with a primary account holder to provide limited access for a secondary users in Sahni, to include the method of aggregating the parent and child values as taught in Kootale for the predicated result of an improved system of allocating funds restriction and usage between parent and child accounts. Claim 11 is rejected under 35 U.S.C 103 as obvious over Sahni et al. (US10445739B1) in view of Goodwin et al. (US20210326877A1) in view of Srinivasan et al. (US20150112855A1) in view of Kallugudde (US20200111081A1) in view of Kootale (US6988104B2), and further in view of Yao et al. (US20200183979A1). With respect to claim 11 The combination of Sahni, Goodwin, Srinivasan, Kallugudde, and Kootale teaches the limitation of claim 10. The combination doesn’t explicitly disclose, but Yao teaches: adjusting the second value according to the first format and the second format (see [0063]), wherein the processor aggregates the first value, the second value, and the aggregated value by aggregating the first value, the adjusted second value, and the aggregated value (see [0076]) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Sahni/Goodwin/ Srinivasan/Kallugudde/ Kootale with the teaching of Yao as they relate to a system/method of managing parent and child payment transaction relationships through use of rules and limitation. One of ordinary skill in the art before effective filing date of the claimed invention would have recognized the combined systems of Sahni/Goodwin/ Srinivasan/ Kallugudde/ Kootale, for example allowing a master wallet associated with a primary account holder to provide limited access for a secondary users in Sahni, to include the method of adjusting a value according to different formats as taught in Yao for the predicated result of an improved system of allocating funds restriction and usage between parent and child accounts. Claim 12 is rejected under 35 U.S.C 103 as obvious over Sahni et al. (US10445739B1) in view of Goodwin et al. (US20210326877A1) in view of Srinivasan et al. (US20150112855A1), and further in view of Yao et al. (US20200183979A1). With respect to claim 12 The combination of Sahni, Goodwin, and Srinivasan teaches the limitation of claim 1. The combination doesn’t explicitly disclose, but Yao teaches: receiving, via the network interface from a client device, a message comprising a new value without an identifier identifying any child profiles; determining the message does not contain an identifier identifying any child profiles; and responsive to the determining the message does not contain an identifier identifying any child profiles, aggregating the new value with a value of the parent profile without adjusting any values of the one or more child profiles (see [0054-0060]) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Sahni/Goodwin/ Srinivasan with the teaching of Yao as they relate to a system/method of managing parent and child payment transaction relationships through use of rules and limitation. One of ordinary skill in the art before effective filing date of the claimed invention would have recognized the combined systems of Sahni/Goodwin/ Srinivasan, for example allowing a master wallet associated with a primary account holder to provide limited access for a secondary users in Sahni, to include the method of adding a new value that does not belong to a child profile as taught in Yao for the predicated result of an improved system of allocating funds restriction and usage between parent and child accounts. Conclusion THIS ACTION IS MADE Non-FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). Any inquiry concerning this communication or earlier communications from the examiner should be directed to YIN Y CHOI whose telephone number is (571)272-1094 or yin.choi@uspto.gov. The examiner can normally be reached on M-F 7:30 - 5:30pm EST. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha 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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /YIN Y CHOI/Examiner, Art Unit 3699 6/17/2026
Read full office action

Prosecution Timeline

Show 5 earlier events
Jan 14, 2026
Final Rejection mailed — §101, §103
Jan 20, 2026
Examiner Interview Summary
Jan 20, 2026
Response after Non-Final Action
Jan 20, 2026
Applicant Interview (Telephonic)
Feb 09, 2026
Request for Continued Examination
Mar 01, 2026
Response after Non-Final Action
Jun 24, 2026
Non-Final Rejection mailed — §101, §103
Jul 09, 2026
Interview Requested

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12682330
IN-STREAMING APPLICATION FOR FINANCIAL SERVICES FOR LLM-BASED OPERATING SYSTEMS
2y 5m to grant Granted Jul 14, 2026
Patent 12651263
SYSTEMS AND METHODS FOR AUTHENTICATING ONLINE USERS
6y 11m to grant Granted Jun 09, 2026
Patent 12651248
WALLET AS A SERVICE
3y 3m to grant Granted Jun 09, 2026
Patent 12646050
ELECTRONIC ACCOUNT TRANSFERS IN CASINO ENVIRONMENTS
3y 8m to grant Granted Jun 02, 2026
Patent 12619974
System and method for conducting secure financial transactions
3y 4m to grant Granted May 05, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
60%
Grant Probability
69%
With Interview (+9.0%)
3y 10m (~6m remaining)
Median Time to Grant
High
PTA Risk
Based on 147 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month