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 .
Applicant filed a response dated June 30, 2026 in which claims 1, 4, 10, 13, 17, and 19 have been amended. Therefore, claims 1-20 are currently pending in the application.
Priority
Application 19/072,756 filed on March 6, 2025 and claims benefit of INDIA 202411015372 03/01/2024.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 U.S.C. § 112(a) or § 112 1st paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Claim Objections
Claims 10 and 19 are objected to because of the following informalities:
Claim 10, limitation 1, which recites “A banking system for initiating future payments from a user to a vendor, comprising: a controller including at least one processor, memory, and a communication interface; a gateway manager implemented as executable instructions stored in the memory and executed by the processor, the gateway manager being configured to securely receive payment requests and transaction context data from a user via the communication interface”, appears to have missing punctuation at the end of the limitation.
Claim 19, limitation 1, which recites “A non-transitory computer-readable medium having instructions stored thereon on, the instructions, when executed, cause a processor to perform a method comprising: receiving, via a gateway manager, requests from a user to make current payments to a plurality of vendor payment platforms in accordance with the behavior of the user, the gateway manager being implemented as executable instructions stored in the memory and executed by the processor, the gateway manager being configured to securely receive payment requests and transaction context data from a user via the communication interface,;”, appears to have erroneous punctuation at the end of the limitation.
Appropriate correction is required.
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 a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. (MPEP 2106). The claims are directed to a method, system, and apparatus which is one of the statutory categories of invention (Step 1: YES). The recitation of the claimed invention is analyzed as follows, in which the abstract elements are boldfaced.
Claim 1 recites the limitations of:
A dynamic payment allocation method for initiating future payment transactions, comprising: receiving, via a gateway manager, implemented as executable instructions stored in memory and executed by a processor, requests from a user to make current payments to a plurality of vendor payment platforms in accordance with the behavior of the user;
using artificial intelligence (AI), via an allocation engine, implemented as executable instructions stored in memory and executed by the processor, to dynamically evaluate the received requests by: (a) analyzing stored prior transaction records retrieved from the memory;
(b) correlating the transaction context metadata with user-defined payment profiles and security rules generated by a profiling system agent, implemented as executable instructions stored in memory and executed by a processor, and
(c) recognizing transaction execution patterns associated with successful settlement across a plurality of vendor payment platforms; wherein the allocation engine evaluates transaction requirements, available funds, authentication requirements, and stored transaction execution patterns associated with the plurality of vendor payment platforms to automatically select and execute a payment transaction path for the future payment transaction; and
automatically selecting, and causing execution of, an optimal one of the plurality of vendor payment platforms for future payments by issuing payment execution, wherein the selection and execution are performed in real time under control of the allocation engine and prior to transaction settlement, thereby relieving the user from manual payment-instrument selection.
Claim 10 recites the limitations of:
A banking system for initiating future payments from a user to a vendor, comprising: a controller including at least one processor, memory, and a communication interface; a gateway manager implemented as executable instructions stored in the memory and executed by the processor, the gateway manager being configured to securely receive payment requests and transaction context data from a user via the communication interface
an allocation engine implemented as executable instructions stored in the memory and executed by the processor, the allocation engine configured to: (i) apply an artificial intelligence model to analyze user behavior derived from stored transaction data;
(ii) evaluate authentication requirements and transaction-specific risk levels; and
(iii) control routing and execution of transactions across a plurality of payment-network interfaces;
wherein the controller automatically selects and executes an optimal payment transaction path for future payments based on recognized execution patterns and security constraints and wherein the allocation engine evaluates transaction requirements, available funds, authentication requirements, and stored transaction execution patterns associated with the plurality of vendor payment platforms to automatically select and execute a payment transaction path for the future payment transaction.
Claim 17 recites the limitations of:
A system for profiling payment transactions between a user and selected service provider platforms, the system comprising: a controller including at least one processor and memory; an analytics agent implemented as executable instructions executed by the processor, the analytics agent configured to derive transaction execution patterns from stored payment records;
a profiling agent implemented as executable instructions executed by the processor, the profiling agent configured to generate and update user payment profiles that include vendor payment platform preferences and authentication rules; and
a recommendation agent implemented as executable instructions executed by the processor, the recommendation agent configured to dynamically enhance the user payment profiles for controlling future transaction executions,
wherein the system interacts with external vendor payment application processing interfaces (APIs) to execute payment transactions under control of the controller.
Claim 19 recites the limitations of:
A non-transitory computer-readable medium having instructions stored thereon on, the instructions, when executed, cause a processor to perform a method comprising: receiving, via a gateway manager, requests from a user to make current payments to a plurality of vendor payment platforms in accordance with the behavior of the user, the gateway manager being implemented as executable instructions stored in the memory and executed by the processor, the gateway manager being configured to securely receive payment requests and transaction context data from a user via the communication interface,;
using Al, via an allocation engine, implemented as executable instructions stored in memory and executed by the processor, to dynamically evaluate the received requests, analyze the user's behavior, and recognize patterns responsive to the evaluation and analysis, and wherein the allocation engine evaluates transaction requirements, available funds, authentication requirements, and stored transaction execution patterns associated with the plurality of vendor payment platforms to automatically select and execute a payment transaction path for the future payment transaction; and
automatically selecting an optimal one of the plurality vendor payment platforms for future payments by the user in accordance with the evaluation, the analysis, and the recognized patterns.
The claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to facilitate payment transactions. This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Furthermore, the claims cover the use of a computer system to provide for collecting, analyzing, and transmitting data to facilitate payment transactions. As the steps could be performed by a human without a computer, the claim limitations fall within the mental processes grouping, and the claim recites an abstract idea.
Finally, claim 18 also recites the use of large language models (LLMs) pre-trained on structured and unstructured datasets to facilitate payment transactions. This is a mathematical calculation.
In the alternative, the large language models (LLMs) pre-trained on structured and unstructured datasets is considered a technology that is recited at a high level of generality and merely applied as a tool to implement the abstract idea.
Thus, the claims recite an abstract idea. (Step 2A, prong 1: YES).
Moreover, the judicial exception is not integrated into a practical application. Other than reciting “a gateway manager, implemented as executable instructions stored in memory and executed by a processor”, “artificial intelligence (AI), via an allocation engine, implemented as executable instructions stored in memory and executed by the processor”, “a profiling system agent, implemented as executable instructions stored in memory and executed by a processor”, “a plurality of vendor payment platforms”, “A banking system for initiating future payments from a user to a vendor, comprising: a controller including at least one processor, memory, and a communication interface; a gateway manager implemented as executable instructions stored in the memory and executed by the processor”, “a plurality of payment-network interfaces”, “A system for profiling payment transactions between a user and selected service provider platforms, the system comprising: a controller including at least one processor and memory; an analytics agent implemented as executable instructions executed by the processor”, “a recommendation agent implemented as executable instructions executed by the processor”, “the system interacts with external vendor payment application processing interfaces (APIs)”, and “A non-transitory computer-readable medium having instructions stored thereon on, the instructions, when executed, cause a processor to perform a method comprising: receiving, via a gateway manager”, to perform the steps of “requesting”, “evaluating”, “analyzing”, “correlating”, “recognizing”, “selecting”, “executing”, “profiling”, and “deriving”, nothing in the claim elements preclude the steps from practically being a certain method for organizing human activity, mental process, or mathematical calculation. The claim as a whole does not integrate the judicial exception into a practical application. The claim merely describes how to generally “apply” the concept of a recommendation agent in a computer environment. The additional computer elements recited in the claim limitations are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception utilizing generic computer components.
For example, the Specification discloses “[0077] FIG. 6 illustrates an exemplary controller 600 that may be application-specific hardware, software, and firmware implementation of the exemplary HDBP architecture 200 in FIG. 2, described above. The embodiments are not limited to the computer architecture embodied within the controller 600. Other computer architectures that are well known to those of skill in the art, such as a modified Harvard architecture as one example, may be used and are within the spirit and scope of the present disclosure. [0078] The controller 600 can include a processor 614 configured to execute one or more components of the HBC 202 of FIG. 2 or the functions of the exemplary HBC engine 406, described above. [0079] The processor 614 can have a specific structure imparted to the processor 614 by instructions stored in memory 602 and/or by instructions 618 fetchable by the processor 614 from a storage medium 620. The storage medium 620 can be remote and communicatively coupled to the controller 600. Such communications can be encrypted. [0080] The controller 600 can be a stand-alone programmable system, or a programmable module included in a larger system. For example, the controller 600 may include, or be connected with, the HDBP architecture 200. The controller 600 may include one or more hardware and/or software components configured to fetch, decode, execute, store, analyze, distribute, evaluate, and/or categorize information. [0081] The processor 614 may also include one or more processing devices or cores (not shown). In some embodiments, the processor 614 may be a plurality of processors, each having either one or more cores. The processor 614 can execute instructions fetched from the memory 602 to perform the functionality of the allocation engine, the security engine, the holistic banking core, and/or the AI engine, respectively, stored in memory modules 604, 606, 608, or 610. Alternatively, the instructions can be fetched from the storage medium 620, or from a remote device connected to the controller 600 via a communication interface 616. Furthermore, the communication interface 616 can also interface with computer systems within a computer system of the HDBP architecture 200. An input/output (I/O) module 612 may be configured for additional communications to or from associated remote systems of a host 622 of the HDBP architecture 200. [0082] Without loss of generality, the storage medium 620 and/or the memory 602 can include a volatile or non-volatile, magnetic, semiconductor, optical, removable, non-removable, read-only, random-access, or any type of non-transitory computer-readable computer medium. The storage medium 620 and/or the memory 602 may include programs and/or other information usable by processor 614. Furthermore, the storage medium 620 can be configured to log data processed, recorded, or collected during the operation of the controller 600.”
Furthermore, the Specification discloses “[0069] In the HDBP ecosystem 400 of FIG. 4, for example, the profiling system agent 408 is responsible for the creation of customer profiles and preferences (Payment Rules). The customer profiles are created by large language models (LLMs) that provide AI-assisted profiling. By way of example, the profiling system agent 408 employs context-aware LLMs, pre-trained on structured and unstructured behavioral datasets, to predict preferences of the customers 402 with minimal input. Continuous learning is enabled via reinforcement mechanisms where LLM accuracy improves based on observed deviations between predicted and actual customer actions.”
Further, the clause “relieving the user from manual payment-instrument selection patterns” is interpreted as a statement of intended use and is therefore given limited patentable weight.
Thus, the specification supports that general purpose computers or computer components are utilized to implement the steps of the abstract idea.
Merely implementing the abstract idea on a generic computer is not a practical application of the abstract idea. The claim as a whole, in viewing the additional elements both individually and in combination, does not integrate the judicial exception into a practical application. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. (Step 2A prong two: No)
The claim does not include additional elements, when considered both individually and as an ordered combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using “a gateway manager, implemented as executable instructions stored in memory and executed by a processor”, “artificial intelligence (AI), via an allocation engine, implemented as executable instructions stored in memory and executed by the processor”, “a profiling system agent, implemented as executable instructions stored in memory and executed by a processor”, “a plurality of vendor payment platforms”, “A banking system for initiating future payments from a user to a vendor, comprising: a controller including at least one processor, memory, and a communication interface; a gateway manager implemented as executable instructions stored in the memory and executed by the processor”, “a plurality of payment-network interfaces”, “A system for profiling payment transactions between a user and selected service provider platforms, the system comprising: a controller including at least one processor and memory; an analytics agent implemented as executable instructions executed by the processor”, “a recommendation agent implemented as executable instructions executed by the processor”, “the system interacts with external vendor payment application processing interfaces (APIs)”, and “A non-transitory computer-readable medium having instructions stored thereon on, the instructions, when executed, cause a processor to perform a method comprising: receiving, via a gateway manager”, to perform the steps of “requesting”, “evaluating”, “analyzing”, “correlating”, “recognizing”, “selecting”, “executing”, “profiling”, and “deriving”, amounts to no more than mere instructions to apply the exception using generic computer component. The claim merely describes how to generally “apply” the concept of collecting, analyzing, and transmitting data to facilitate payment transactions in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea. Such additional elements are determined to not contain an inventive concept according to MPEP 2106.05(f). It should be noted that (1) the “recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not provide significantly more because this type of recitation is equivalent to the words “apply it”, and (2) “Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice, commercial interaction, or managing personal behavior or relationships or interactions between people, mental process, or mathematical calculation) does not integrate a judicial exception into a practical application or provide significantly more”.
Additionally,
Claims 3 and 10 recite: “at least one of credit cards, e-wallets, bank transfers, and unified payment interfaces.”
Claims 4 and 13 recite: “a security engine”
Claims 6 and 15 recite: “an intelligent data processing and analysis system”
Claim 9 recites: “a payment engine configured to operate in conjunction with a rules evaluator engine”
Claim 16 recites: “wherein the intelligent data processing and analysis system includes a data processing and analysis agent configured for”
Furthermore, while claim 18 recites the additional elements of “wherein the profiling agent includes large language models (LLMs) pre-trained on structured and unstructured datasets”, in view of the specification, as explained above, the broadest reasonable interpretation of these elements require a mathematical calculation. Therefore, the limitations fall into the mathematical concepts groupings of abstract ideas.
For similar reasons as explained above with regard to claims 1, 10, 17, and 19, under Step 2A, prong two, these additional elements are merely applying generic computer components to implement the abstract idea. Under Step 2B, when viewing the additional elements individually and in combination, the additional elements do not amount to an inventive concept amounting to significantly more than the judicial exception itself as the claimed computer-related technologies are mere tools for implementing the abstract idea as explained with regard to claim 1, 10, 17, and 19.
Dependent claims 2-9, 11-16, 18, and 20 merely limit the abstract idea and do not recite any further additional elements beyond the cited abstract idea and the elements addressed above, thus, they do not amount to significantly more. The dependent claims are abstract for the reasons presented above because there are no additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Thus, the dependent claims are directed to an abstract idea. (Step 2B: No)
Therefore, claims 1-20 are not patent-eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. §§ 102 and 103 (or as subject to pre-AIA 35 U.S.C. §§ 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4 are rejected under 35 U.S.C. 103 as being unpatentable over Ratnakaram, U.S. Patent Application Publication Number 2023/0214841; in view of Walters, U.S. Patent Application Publication Number 2021/0357923; in view of King, U.S. Patent Application Publication Number 2024/0346579; in view of Kolchin, U.S. Patent Application Publication Number 2024/0257124.
As per claim 1,
Ratnakaram explicitly teaches:
A dynamic payment allocation method for initiating [future] payment transactions, comprising: receiving, via a gateway manager, implemented as executable instructions stored in memory and executed by a processor, requests from a user to make current payments to a plurality of vendor payment platforms in accordance with the behavior of the user;
(Ratnakaram US20230214841 at paras. 6-7, 25-35, 104-105) ("[0007] The system may receive a request for payment and event details, including an amount of the event, location of the event, and the like. The amount may be compared to the pre-authorized amount and, if more than the pre-authorized amount, a request for payment authorization may be transmitted to a user device. If the amount is not more than the pre-authorized amount, expected location data of the user may be received and current location data of the user may be requested from a user device. The current location data may be compared to the expected location data and event details and, if the locations match, the payment may be authorized and automatically processed." "[0026] Payment and recommendation control computing platform 110 may be configured to provide intelligent, dynamic, seamless payment processing and option recommendations based on contextual data for a user. For instance, payment and recommendation control computing platform 110 may receive data, such as contextual data, from one or more user devices, such as a smart phone, smart watch, fitness tracker, tablet computing device, or the like, and analyze the data using one or more machine learning models trained on historical data related to contextual data and user preferences. In some examples, the contextual data may include calendar data of the user, data captured from social media platforms, data from user reviews of entities, spending history and habits of the user, food preferences, feed data from IoT devices, and the like. The data may be analyzed to determine one or more recommendations to provide to the user. In some examples, the one or more recommendations may be automatically implemented (e.g., without additional user interaction or input). For example, analyzing the contextual data may identify a restaurant for a user to dine at and the system may automatically connect to the restaurant computing system and reserve a table for the user (e.g., without user interaction). One or more notifications may then be transmitted to the user." "[0031] External entity computing system 140 and/or external entity computing system 145 may be or include one or more computing devices and/or systems that may be associated with one or more entities external to or not associated with the enterprise organization. For instance, external entity computing system 140 and/or external entity computing system 145 may be associated with one or more vendors, restaurants, service providers, or the like. External entity computing system 140 and/or external entity computing system 145 may be configured to communicate with payment and recommendation control computing platform 110 to facilitate scheduling of events, payment for goods or services, and the like. In some examples, external entity computing system 140 and/or external entity computing system 145 may be or include a point-of-sale system at a vendor, restaurant, service provider, or the like." "[0035] Referring to FIG. 1B, payment and recommendation control computing platform 110 may include one or more processors 111, memory 112, and communication interface 113. A data bus may interconnect processor(s) 111, memory 112, and communication interface 113. Communication interface 113 may be a network interface configured to support communication payment and recommendation control computing platform 110 and one or more networks (e.g., private network 190, public network, or the like). Memory 112 may include one or more program modules having instructions that when executed by processor(s) 111 cause payment and recommendation control computing platform 110 to perform one or more functions described herein and/or one or more databases that may store and/or otherwise maintain information which may be used by such program modules and/or processor(s) 111." "[0105] At step 304, event data and a request for payment may be received by payment and recommendation control computing platform 110. For instance, event data and a request for payment may be received from an external entity computing system 140 associated with an entity hosting the event (e.g., the restaurant at which the user is dining, a vendor or service provider working with the user, and the like). In some examples, the event data may include a check or bill for payment due. In some arrangements, the event data may include an image or image data of the check or bill. The event data may further include a location of the event, a date of the event, a time of the event, and the like.")
using artificial intelligence (AI), via an allocation engine, implemented as executable instructions stored in memory and executed by the processor, to dynamically evaluate the received requests by: (a) analyzing stored prior transaction records retrieved from the memory;
(Ratnakaram US20230214841 at paras. 6-7, 25-37, 95-98, 104-105) ("[0027] Payment and recommendation computing platform may host, train, execute, update and/or validate the one or more machine learning models. For instance, training or historical data may be received and used to train the machine learning model. The training or historical data may identify sequences or patterns associated with scheduled events, amounts paid, types of events, recommendations, and the like, and train the machine learning model to predict recommendations, identify pre-authorization amounts, identify or select a payment mode, and the like." "[0035] Referring to FIG. 1B, payment and recommendation control computing platform 110 may include one or more processors 111, memory 112, and communication interface 113. A data bus may interconnect processor(s) 111, memory 112, and communication interface 113. Communication interface 113 may be a network interface configured to support communication payment and recommendation control computing platform 110 and one or more networks (e.g., private network 190, public network, or the like). Memory 112 may include one or more program modules having instructions that when executed by processor(s) 111 cause payment and recommendation control computing platform 110 to perform one or more functions described herein and/or one or more databases that may store and/or otherwise maintain information which may be used by such program modules and/or processor(s) 111." "[0036] For example, memory 112 may have, store and/or include historical/training data module 112a. Historical/training data module 112a may store instructions and/or data that may cause or enable the payment and recommendation control computing platform 110 to receive historical and or training data, including contextual data, related to one or more users, user purchases, user schedules, user orders, and the like and use that data to train one or more machine learning models stored in machine learning engine 112b. The historical and/or training data may include, for instance, a previous restaurant experience of a user, what was ordered, a cost and a tip provided. Information of this nature may be received from a plurality of sources, such as internal entity computing system 125 which may, e.g., process one or more account payments for a user, user devices such as remote user computing device 170, remote user computing device 175, and the like. The data may be gathered from a plurality of users and used to build and train one or more machine learning models stored and/or executed by machine learning engine 112b to identify one or more recommendations for a user, determine a pre-authorized amount and whether to automatically process a payment, and the like." "[0041] Payment and recommendation control computing platform 110 may further have, store and/or include a database 112f. Database 112f may store historical data associated with one or more users, user response data (e.g., user input received in response to a request for user input, and the like), and the like." "[0095] Upon confirming that the location response data matches an expected location and the event location data, the payment may be processed at step 255. For instance, without user input or interaction, based on the payment being authorized by comparing location response data to expected location data and event location data, payment of the check or bill may be processed. In some examples, processing the payment may include selecting a payment device associated with the user from a plurality of payment modes or devices (e.g., different credit cards, debit card, or the like). In some examples, a user may pre-select a payment device. In some arrangements, the user may select different payment devices for different types of payments, different amounts, and the like. Additionally or alternatively, payment and recommendation control computing platform 110 may automatically select a payment device (e.g., based on historical data, amount, account closing date, account balance, or the like). Automatic selection of a payment device or mode may be based on contextual data, event data, and the like.")
(b) correlating the transaction context metadata with user-defined payment [profiles] and [security rules] [generated by a profiling system agent], implemented as executable instructions stored in memory and executed by a processor, and
(Ratnakaram US20230214841 at paras. 6-7, 25-37, 104-105) ("[[0007] The system may receive a request for payment and event details, including an amount of the event, location of the event, and the like. The amount may be compared to the pre-authorized amount and, if more than the pre-authorized amount, a request for payment authorization may be transmitted to a user device. If the amount is not more than the pre-authorized amount, expected location data of the user may be received and current location data of the user may be requested from a user device. The current location data may be compared to the expected location data and event details and, if the locations match, the payment may be authorized and automatically processed." "[0035] Referring to FIG. 1B, payment and recommendation control computing platform 110 may include one or more processors 111, memory 112, and communication interface 113. A data bus may interconnect processor(s) 111, memory 112, and communication interface 113. Communication interface 113 may be a network interface configured to support communication payment and recommendation control computing platform 110 and one or more networks (e.g., private network 190, public network, or the like). Memory 112 may include one or more program modules having instructions that when executed by processor(s) 111 cause payment and recommendation control computing platform 110 to perform one or more functions described herein and/or one or more databases that may store and/or otherwise maintain information which may be used by such program modules and/or processor(s) 111." "[0037] After building and/or training the one or more machine learning models, machine learning engine 112b may receive data, such as contextual data, from various sources and execute the one or more machine learning models to generate an output, such as a recommendation for a user, a pre-authorized amount for a transaction, whether to automatically process a transaction, and the like. For instance, contextual data such as current calendar data of a user (e.g., received from a calendar application executing on remote user computing device 170 and/or remote user computing device 175), reservation data (e.g., received from, e.g., an email application executing on remote user computing device and/or remote user computing device 175 or made via the computing platform 110), previous reservation data, user preferences, historical purchase data, restaurant location data, current user location data (e.g., received from a global positioning system (GPS) executing on remote user computing device 170 and/or remote user computing device 175), or the like, may be used as inputs into the one or more machine learning models and the one or more machine learning models may be executed to generate one or more outputs." "[0095] Upon confirming that the location response data matches an expected location and the event location data, the payment may be processed at step 255. For instance, without user input or interaction, based on the payment being authorized by comparing location response data to expected location data and event location data, payment of the check or bill may be processed. In some examples, processing the payment may include selecting a payment device associated with the user from a plurality of payment modes or devices (e.g., different credit cards, debit card, or the like). In some examples, a user may pre-select a payment device. In some arrangements, the user may select different payment devices for different types of payments, different amounts, and the like. Additionally or alternatively, payment and recommendation control computing platform 110 may automatically select a payment device (e.g., based on historical data, amount, account closing date, account balance, or the like). Automatic selection of a payment device or mode may be based on contextual data, event data, and the like.")
(c) recognizing transaction execution patterns associated with successful settlement across a plurality of vendor payment platforms; wherein the allocation engine evaluates transaction requirements, available funds, authentication requirements, and stored transaction execution patterns associated with the plurality of vendor payment platforms to automatically select and execute a payment transaction path for the future payment transaction; and
(Ratnakaram US20230214841 at paras. 27, 31, 94-100) ("[0027] Payment and recommendation computing platform may host, train, execute, update and/or validate the one or more machine learning models. For instance, training or historical data may be received and used to train the machine learning model. The training or historical data may identify sequences or patterns associated with scheduled events, amounts paid, types of events, recommendations, and the like, and train the machine learning model to predict recommendations, identify pre-authorization amounts, identify or select a payment mode, and the like." "[0031] External entity computing system 140 and/or external entity computing system 145 may be or include one or more computing devices and/or systems that may be associated with one or more entities external to or not associated with the enterprise organization. For instance, external entity computing system 140 and/or external entity computing system 145 may be associated with one or more vendors, restaurants, service providers, or the like. External entity computing system 140 and/or external entity computing system 145 may be configured to communicate with payment and recommendation control computing platform 110 to facilitate scheduling of events, payment for goods or services, and the like. In some examples, external entity computing system 140 and/or external entity computing system 145 may be or include a point-of-sale system at a vendor, restaurant, service provider, or the like." "[0095] Upon confirming that the location response data matches an expected location and the event location data, the payment may be processed at step 255. For instance, without user input or interaction, based on the payment being authorized by comparing location response data to expected location data and event location data, payment of the check or bill may be processed. In some examples, processing the payment may include selecting a payment device associated with the user from a plurality of payment modes or devices (e.g., different credit cards, debit card, or the like). In some examples, a user may pre-select a payment device. In some arrangements, the user may select different payment devices for different types of payments, different amounts, and the like. Additionally or alternatively, payment and recommendation control computing platform 110 may automatically select a payment device (e.g., based on historical data, amount, account closing date, account balance, or the like). Automatic selection of a payment device or mode may be based on contextual data, event data, and the like. [0096] At step 256, one or more payment instructions may be generated. For instance, instructions to process a payment, transfer funds from one account to another account or entity, update an account ledger, and the like, may be generated. [0097] At step 257, the generated one or more payment instructions may be transmitted to external entity computing system 140. For instance, an instruction to process payment for the bill, an account or payment device to process the payment, an amount of payment, and the like, may be transmitted to the external entity computing system 140. [0098] At step 258, the external entity computing system 140 may receive the one or more payment instructions and may execute the instructions. In some examples, executing the instructions may include transmitting and/or receiving data with a financial institution (e.g., associated with the payment device or account of the user) to update account information, record the transaction in a ledger, and the like.")
automatically selecting, and causing execution of, an optimal one of the plurality of vendor payment platforms [for future payments] by issuing payment execution, wherein the selection and execution are performed in real time under control of the allocation engine and prior to transaction settlement, thereby relieving the user from manual payment-instrument selection patterns.
(Ratnakaram US20230214841 at paras. 26-27, 31, 39, 42, 95-98) ("[0026] The data may be analyzed to determine one or more recommendations to provide to the user. In some examples, the one or more recommendations may be automatically implemented (e.g., without additional user interaction or input)." "[0031] External entity computing system 140 and/or external entity computing system 145 may be or include one or more computing devices and/or systems that may be associated with one or more entities external to or not associated with the enterprise organization. For instance, external entity computing system 140 and/or external entity computing system 145 may be associated with one or more vendors, restaurants, service providers, or the like. External entity computing system 140 and/or external entity computing system 145 may be configured to communicate with payment and recommendation control computing platform 110 to facilitate scheduling of events, payment for goods or services, and the like. In some examples, external entity computing system 140 and/or external entity computing system 145 may be or include a point-of-sale system at a vendor, restaurant, service provider, or the like." "[0039] Payment and recommendation control computing platform 110 may further have, store and/or include output selection module 112d. Output selection module 112d may store instructions and/or data that may cause or enable payment and recommendation control computing platform 110 to select, based on one or more outputs generated by the one or more machine learning models and analysis of contextual data, an output for processing. For instance, the one or more machine learning models may generate more than one output with a recommended vendor, restaurant, service provider, or the like. In some examples, output selection module 112d may select one output from the more than one output generated and may generate instructions to process that output (e.g., automatically process a payment, automatically book a reservation for a user, or the like)." "[0042] FIGS. 2A-2K depict one example illustrative event sequence for executing payment and recommendation control functions in accordance with one or more aspects described herein. The events shown in the illustrative event sequence are merely one example sequence and additional events may be added, or events may be omitted, without departing from the invention. Further, one or more processes discussed with respect to FIGS. 2A-2K may be performed in real-time or near real-time." "[0095] Upon confirming that the location response data matches an expected location and the event location data, the payment may be processed at step 255. For instance, without user input or interaction, based on the payment being authorized by comparing location response data to expected location data and event location data, payment of the check or bill may be processed. In some examples, processing the payment may include selecting a payment device associated with the user from a plurality of payment modes or devices (e.g., different credit cards, debit card, or the like). In some examples, a user may pre-select a payment device. In some arrangements, the user may select different payment devices for different types of payments, different amounts, and the like. Additionally or alternatively, payment and recommendation control computing platform 110 may automatically select a payment device (e.g., based on historical data, amount, account closing date, account balance, or the like). Automatic selection of a payment device or mode may be based on contextual data, event data, and the like. [0096] At step 256, one or more payment instructions may be generated. For instance, instructions to process a payment, transfer funds from one account to another account or entity, update an account ledger, and the like, may be generated. [0097] At step 257, the generated one or more payment instructions may be transmitted to external entity computing system 140. For instance, an instruction to process payment for the bill, an account or payment device to process the payment, an amount of payment, and the like, may be transmitted to the external entity computing system 140. [0098] At step 258, the external entity computing system 140 may receive the one or more payment instructions and may execute the instructions. In some examples, executing the instructions may include transmitting and/or receiving data with a financial institution (e.g., associated with the payment device or account of the user) to update account information, record the transaction in a ledger, and the like.")
Ratnakaram does not explicitly teach, however, Walters does teach:
automatically...causing execution...for future payments…
(Walters US20210357923 at paras. 146-155) ("[0146] As further shown in FIG. 6, process 600 may include identifying a transaction pattern associated with a merchant account, wherein the transaction pattern is identified based on a plurality of historical transactions identified in the transaction log being associated with the merchant account (block 630). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may identify a transaction pattern associated with a merchant account, as described above. In some implementations, the transaction pattern is identified based on a plurality of historical transactions identified in the transaction log being associated with the merchant account. [0147] As further shown in FIG. 6, process 600 may include determining, based on the transaction pattern, that a historical transaction of the plurality of historical transactions is not designated for automatic execution (block 640). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may determine, based on the transaction pattern, that a historical transaction of the plurality of historical transactions is not designated for automatic execution, as described above. [0148] As further shown in FIG. 6, process 600 may include determining, based on determining that the historical transaction is not designated for automatic execution, that an execution of an upcoming transaction corresponding to the plurality of historical transactions is not scheduled (block 650). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may determine, based on determining that the historical transaction is not designated for automatic execution, that an execution of an upcoming transaction corresponding to the plurality of historical transactions is not scheduled, as described above. [0149] As further shown in FIG. 6, process 600 may include causing an account transaction associated with the upcoming transaction to be automatically executed before a transaction period expiration, that is associated with the merchant account, passes (block 660). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may cause an account transaction associated with the upcoming transaction to be automatically executed before a transaction period expiration, that is associated with the merchant account, passes, as described above." "[0155] In a fifth implementation, alone or in combination with one or more of the first through fourth implementations, causing the account transaction to be automatically executed comprises at least one of: scheduling an execution of a transaction corresponding to the upcoming transaction, designating a transaction corresponding to the upcoming transaction for automatic execution, or executing, via a transaction back end system, a transaction with the merchant account that corresponds to the upcoming transaction.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ratnakaram and Walters, because it allows for an improved system to cause an account transaction associated with the upcoming transaction to be automatically executed. (Walters at Abstract and paras. 1-4).
Ratnakaram and Walters do not explicitly teach, however, King does teach:
profiles...generated by a profiling system agent…
(King US20240346579 at paras. 25-30, 50, 59-63, 85) ("[0025] Credit builder system 150 offers a service that provides, to the user 110, ongoing feedback to assist the user in achieving financial goals communicated to credit builder system 150. Credit builder system 150 may accept inputs from user 110 about their financial goals (in addition to other information) via client device 112 (described with reference to FIG. 2), and may additionally pull information from third-party databases 140. This information is used to compute a recommended course of action for the user to achieve the specified goals. For instance, credit builder system 150 may recommend to the user 110 to maintain a credit limit of $1,500 and/or to open a car loan to elevate the user's credit score on the desired timeline to that necessary to buy a home. Credit builder system 150 may, from that point forward, continually monitor the financial state of the user 110 as well as changes to the user's credit score over time, and may feed learned information back to a model to reassess the financial health of the user and, if needed, revise or replace the recommendation(s) provided to the user." "[0050] User profile database 341 may also include real-time and/or historic information relating to any of: consumer account creation/removal/edits, deposit/withdrawal activity (e.g., dates of activity, amount of deposit/withdrawal) on consumer accounts, activity by any users that may have shared or joint accounts with the consumer, consumer financial health metrics or scores, purchases made or pending using cards tied to any of the user's accounts, user activity on one or more user interfaces delivered by web server 370, and/or metrics generated on any of the above such information, whether based on an individual account or individual user, or in aggregate. In some embodiments, as various users login, make edits, changes, view, search, click, interact with, or otherwise engage in activities with the user interface on system 150, such activity may be stored in database 341 as indicators that may be considered, individually or in aggregate, in an analysis of user 110's activity. In some embodiments, this information may be understood as user engagement metrics or behavioral biometrics. In some embodiments, some of the data in user profile database 341 may collected from one more external (that is, third-party) databases or websites 170 (e.g., financial, government, media, commercial, or other sources, repositories, or websites, collected via communication logic 322) to determine whether and how a user has followed or communicated regarding the entity managing credit builder system 150 (which may be, e.g., a consumer bank), referrals that the consumer has made to other potential consumers, or similar considerations that may indicate a higher or lower level of user engagement and therefore, a greater interest in their own financial health." "[0059] Credit builder recommendation module 333 derives and selects its recommendations using one or more machine learning models stored in model database 343. At a high level, these machine learning models may be categorized as a clustering model and a selection model, though any number or type of models or algorithms may be applied in different embodiments. The clustering model is configured to group or cluster sets of users (various banking clients) based on similarities in their user histories, so that patterns in their respective user activities that lead to positive or negative credit progress can be seen. The selection model is a user-specific algorithm, taking a set of all potential user activities that may positively impact a user's credit and determining, based on user preferences and other relevant user profile data, which of those activities should be selected and consolidated into recommendations (and the order of such recommendations, where appropriate).")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ratnakaram, Walters, and King, because it allows for an improved banking system may additionally, through monitoring and use of machine learning models, provide continually updated recommendations based on user activity. (King at Abstract and paras. 1-3, 86).
Ratnakaram, Walters, and King do not explicitly teach, however, Kolchin does teach:
security rules...
(Kolchin US20240257124 at paras. 108-114, 197-199, 206-208) ("[0108] In some instances, the method can include the step of marking the transaction as pending until the transaction is approved by the account holder. The approval of the transaction by the account holder can include the approval of the terms of the transaction. The method can include the step of increasing the speed of the transaction based on the account holder's financial credibility by adjusting the predetermined time. [0109] The second account can include one or more accounts and the pre-authorization charge of the second account can be made using one or more accounts (for example a pre-authorized charge of $10,000 can be divided up among several accounts, such that, for example, $5000 is charged to a first credit card and another $5000 is charged to a second credit card). The ACH pre-authorization release time can be adjusted based on the transaction amount or risk of transaction based on the risk assessment data (e.g., the pre-authorization can be held for 60 days for a high-risk transaction and for 20 days for a lower risk transaction). [0110] The system of the present invention is configured to provide a secure way of uploading checks to ensure that sensitive/confidential data is not being exposed by enabling merchants to send check image link/token for remote uploads. In a situation when the merchant and the consumer are located too far apart from each other, the system provides a merchant with the ability to send a consumer an sms/email containing instructions/request to upload a front and back image of the check. A merchant can also send a special link with a link to the application that will allow consumers to upload the image. However, consumers might not like wasting their time on uploading unknown applications. In that case, the system allows a merchant to send to a consumer a website link that will allow secure uploading of images. In both cases the images will be uploaded to an iWallet server, and each image will have a link/token associated with it. A token/link (along with other transaction information such as amount, name, address, ID, date, security information) will then be sent to the merchant or the processor to initiate a transaction. This approach ensures that the sensitive/confidential data is not exposed and provides extra security to consumers and merchants." "[0206] Another embodiment of the present invention, that might be used by itself or in combination with the described-above methods is a holographic image detection on cards using a smartphone. Most major credit card companies such as Visa, MasterCard, and Discover use a holographic image to make it harder to create a fake credit card. There are multiple ways to detect a valid hologram: [0207] a. by taking multiple pictures at different angles and making sure that the hologram is “moving.” [0208] b. since most modern phones have multiple cameras that are located at slightly different angles, it's possible to take a picture/video of the image using multiple cameras at the same time and be able to immediately see/detect the holographic “moving” image with high accuracy.)
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ratnakaram, Walters, King, and Kolchin, because it allows for conducting secure financial transactions using a model-based reflex agent includes receiving transaction-related precepts through sensors, wherein the precepts include transaction details, user credentials, and risk-related information. The system further includes maintaining, by the model-based reflex agent, an internal state that reflects observed and inferred aspects of the transaction based on the received precepts and a world model describing how the financial system evolves and the impact of agent actions. (Kolchin at Abstract and paras. 2-11).
As per claim 2,
Ratnakaram explicitly teaches:
wherein the behavior relates to at least one of selecting payment methods and selecting authentication methods.
(Ratnakaram US20230214841 at paras. 7, 27, 31, 94-100) ("[0007] The system may receive a request for payment and event details, including an amount of the event, location of the event, and the like. The amount may be compared to the pre-authorized amount and, if more than the pre-authorized amount, a request for payment authorization may be transmitted to a user device. If the amount is not more than the pre-authorized amount, expected location data of the user may be received and current location data of the user may be requested from a user device. The current location data may be compared to the expected location data and event details and, if the locations match, the payment may be authorized and automatically processed." "[0095] Upon confirming that the location response data matches an expected location and the event location data, the payment may be processed at step 255. For instance, without user input or interaction, based on the payment being authorized by comparing location response data to expected location data and event location data, payment of the check or bill may be processed. In some examples, processing the payment may include selecting a payment device associated with the user from a plurality of payment modes or devices (e.g., different credit cards, debit card, or the like). In some examples, a user may pre-select a payment device. In some arrangements, the user may select different payment devices for different types of payments, different amounts, and the like. Additionally or alternatively, payment and recommendation control computing platform 110 may automatically select a payment device (e.g., based on historical data, amount, account closing date, account balance, or the like). Automatic selection of a payment device or mode may be based on contextual data, event data, and the like. [0096] At step 256, one or more payment instructions may be generated. For instance, instructions to process a payment, transfer funds from one account to another account or entity, update an account ledger, and the like, may be generated. [0097] At step 257, the generated one or more payment instructions may be transmitted to external entity computing system 140. For instance, an instruction to process payment for the bill, an account or payment device to process the payment, an amount of payment, and the like, may be transmitted to the external entity computing system 140. [0098] At step 258, the external entity computing system 140 may receive the one or more payment instructions and may execute the instructions. In some examples, executing the instructions may include transmitting and/or receiving data with a financial institution (e.g., associated with the payment device or account of the user) to update account information, record the transaction in a ledger, and the like.")
As per claim 3,
Ratnakaram explicitly teaches:
wherein the payment methods include at least one of credit cards, e-wallets, bank transfers, and unified payment interfaces.
(Ratnakaram US20230214841 at paras. 7, 27, 31, 94-100) ("[0007] The system may receive a request for payment and event details, including an amount of the event, location of the event, and the like. The amount may be compared to the pre-authorized amount and, if more than the pre-authorized amount, a request for payment authorization may be transmitted to a user device. If the amount is not more than the pre-authorized amount, expected location data of the user may be received and current location data of the user may be requested from a user device. The current location data may be compared to the expected location data and event details and, if the locations match, the payment may be authorized and automatically processed." "[0095] Upon confirming that the location response data matches an expected location and the event location data, the payment may be processed at step 255. For instance, without user input or interaction, based on the payment being authorized by comparing location response data to expected location data and event location data, payment of the check or bill may be processed. In some examples, processing the payment may include selecting a payment device associated with the user from a plurality of payment modes or devices (e.g., different credit cards, debit card, or the like). In some examples, a user may pre-select a payment device. In some arrangements, the user may select different payment devices for different types of payments, different amounts, and the like. Additionally or alternatively, payment and recommendation control computing platform 110 may automatically select a payment device (e.g., based on historical data, amount, account closing date, account balance, or the like). Automatic selection of a payment device or mode may be based on contextual data, event data, and the like. [0096] At step 256, one or more payment instructions may be generated. For instance, instructions to process a payment, transfer funds from one account to another account or entity, update an account ledger, and the like, may be generated. [0097] At step 257, the generated one or more payment instructions may be transmitted to external entity computing system 140. For instance, an instruction to process payment for the bill, an account or payment device to process the payment, an amount of payment, and the like, may be transmitted to the external entity computing system 140. [0098] At step 258, the external entity computing system 140 may receive the one or more payment instructions and may execute the instructions. In some examples, executing the instructions may include transmitting and/or receiving data with a financial institution (e.g., associated with the payment device or account of the user) to update account information, record the transaction in a ledger, and the like.")
As per claim 4,
Ratnakaram, Walters, and King do not explicitly teach, however, Kolchin does teach:
further comprising a security engine, implemented as executable instructions stored in memory and executed by the processor, the security engine configured to obtain a token for exchange with one or more payment instrument financial institutions and with one or more vendors to complete the future payment transactions and to implement the authentication methods, dynamically adjust the authentication methods based on user-defined preferences, vary security levels, and adapt to transaction amounts;
(Kolchin US20240257124 at paras. 108-114, 197-199, 206-208) ("[0108] In some instances, the method can include the step of marking the transaction as pending until the transaction is approved by the account holder. The approval of the transaction by the account holder can include the approval of the terms of the transaction. The method can include the step of increasing the speed of the transaction based on the account holder's financial credibility by adjusting the predetermined time. [0109] The second account can include one or more accounts and the pre-authorization charge of the second account can be made using one or more accounts (for example a pre-authorized charge of $10,000 can be divided up among several accounts, such that, for example, $5000 is charged to a first credit card and another $5000 is charged to a second credit card). The ACH pre-authorization release time can be adjusted based on the transaction amount or risk of transaction based on the risk assessment data (e.g., the pre-authorization can be held for 60 days for a high-risk transaction and for 20 days for a lower risk transaction). [0110] The system of the present invention is configured to provide a secure way of uploading checks to ensure that sensitive/confidential data is not being exposed by enabling merchants to send check image link/token for remote uploads. In a situation when the merchant and the consumer are located too far apart from each other, the system provides a merchant with the ability to send a consumer an sms/email containing instructions/request to upload a front and back image of the check. A merchant can also send a special link with a link to the application that will allow consumers to upload the image. However, consumers might not like wasting their time on uploading unknown applications. In that case, the system allows a merchant to send to a consumer a website link that will allow secure uploading of images. In both cases the images will be uploaded to an iWallet server, and each image will have a link/token associated with it. A token/link (along with other transaction information such as amount, name, address, ID, date, security information) will then be sent to the merchant or the processor to initiate a transaction. This approach ensures that the sensitive/confidential data is not exposed and provides extra security to consumers and merchants." "[0206] Another embodiment of the present invention, that might be used by itself or in combination with the described-above methods is a holographic image detection on cards using a smartphone. Most major credit card companies such as Visa, MasterCard, and Discover use a holographic image to make it harder to create a fake credit card. There are multiple ways to detect a valid hologram: [0207] a. by taking multiple pictures at different angles and making sure that the hologram is “moving.” [0208] b. since most modern phones have multiple cameras that are located at slightly different angles, it's possible to take a picture/video of the image using multiple cameras at the same time and be able to immediately see/detect the holographic “moving” image with high accuracy.)
wherein the security methods include at least one of multifactor authentication, voice modulation recognition, and a one-time password.
(Kolchin US20240257124 at paras. 108-114, 197-199, 206-208) ("[0198] There are two requirements to validate the “card-present” status, which is (i) a card needs to be present, and (ii) a cardholder needs to be present. The first requirement can be detected using the following method, using just a smartphone with no extra hardware: a) using NFC (by reading special non-visible NFC markers) merchant's phone or cardholders phone or other authorized party; b) using NFC (by writing special non-visible NFC markers into NFC memory) merchant's phone or cardholders phone or other authorized party; c) using camera for picture by merchant's phone or cardholders phone or other authorized party; d) using camera for video by merchant's phone or cardholders phone or other authorized party e) using camera in a combination with merchants certification or cardholder certification or other authorized party; f) certification by merchant's or cardholders or other authorized party; or a combination of the above methods. Extracting other information from the phone such as Google ID/Apple ID/Samsung ID, as well as phone number during the NFC transaction and sending it to the processor can also be used to reduce the transaction risk and to prevent fraud. The second requirement can be detected using the following methods: a) something the cardholder has such as any physical object in the possession of the user, for example a security token (USB stick), a bank card, a key, or a phone; b) something the user knows: certain knowledge only known to the user, such as a password, PIN, or the like; c) some physical characteristic attributable to the user (biometrics), such as a fingerprint, eye iris, voice, typing speed, pattern in key press intervals, etc.; d) the user's location: some connection to a specific computing network, or detection of the location using a GPS, GSM, Bluetooth, or WIFI signal to identify the location, or a combination of the above methods. In some instances, a physical location of a home or a business that is owned by a cardholder plus virtual real-time or offline cardholder authorization might be a way to replace the requirement for physical cardholder presence.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ratnakaram, Walters, King, and Kolchin, because it allows for conducting secure financial transactions using a model-based reflex agent includes receiving transaction-related precepts through sensors, wherein the precepts include transaction details, user credentials, and risk-related information. The system further includes maintaining, by the model-based reflex agent, an internal state that reflects observed and inferred aspects of the transaction based on the received precepts and a world model describing how the financial system evolves and the impact of agent actions. (Kolchin at Abstract and paras. 2-11).
Claims 5-9 are rejected under 35 U.S.C. 103 as being unpatentable over Ratnakaram, U.S. Patent Application Publication Number 2023/0214841; in view of Walters, U.S. Patent Application Publication Number 2021/0357923; in view of King, U.S. Patent Application Publication Number 2024/0346579; in view of Kolchin, U.S. Patent Application Publication Number 2024/0257124; in view of Vasylyev, U.S. Patent Application Publication Number 2024/0412720.
As per claim 5,
Ratnakaram explicitly teaches:
wherein the gateway manager
(Ratnakaram US20230214841 at paras. 6-7, 25-35, 104-105) ("[0007] The system may receive a request for payment and event details, including an amount of the event, location of the event, and the like. The amount may be compared to the pre-authorized amount and, if more than the pre-authorized amount, a request for payment authorization may be transmitted to a user device. If the amount is not more than the pre-authorized amount, expected location data of the user may be received and current location data of the user may be requested from a user device. The current location data may be compared to the expected location data and event details and, if the locations match, the payment may be authorized and automatically processed." "[0026] Payment and recommendation control computing platform 110 may be configured to provide intelligent, dynamic, seamless payment processing and option recommendations based on contextual data for a user. For instance, payment and recommendation control computing platform 110 may receive data, such as contextual data, from one or more user devices, such as a smart phone, smart watch, fitness tracker, tablet computing device, or the like, and analyze the data using one or more machine learning models trained on historical data related to contextual data and user preferences. In some examples, the contextual data may include calendar data of the user, data captured from social media platforms, data from user reviews of entities, spending history and habits of the user, food preferences, feed data from IoT devices, and the like. The data may be analyzed to determine one or more recommendations to provide to the user. In some examples, the one or more recommendations may be automatically implemented (e.g., without additional user interaction or input). For example, analyzing the contextual data may identify a restaurant for a user to dine at and the system may automatically connect to the restaurant computing system and reserve a table for the user (e.g., without user interaction). One or more notifications may then be transmitted to the user.")
Ratnakaram, Walters, King, and Kolchin do not explicitly teach, however, Vasylyev does teach:
securely receives the requests from the user.
(Vasylyev US20240412720 at paras. 37-40, 53-58) ("[0039] Furthermore, the Assistant is equipped to recognize one or more voices, which can be designated as control voices. It monitors the conversation for a control signal which could be a key phrase pronounced by the control voice, a button press, a gesture, non-verbal cues, or other recognizable commands. The control signals could be single or multi-factor and may include biometric security measures. The control signal triggers the Assistant to record a subsequent voice command from the user. According to one embodiment, the Assistant provides the user with the ability to set or change the control signals that trigger the Assistant." "[0054] Throughout this process, the Assistant can engage in a natural back-and-forth conversation with the user to gather any missing information, provide updates on the booking status, and handle any changes or cancellations as needed. The Assistant can also build, as part of the conversation with the user, and use its knowledge of the user's preferences and past behavior to make intelligent decisions on their behalf, such as selecting their preferred ride type or payment method, without requiring explicit input at every step." "[0058] Other examples of potentially useful integrations include but are not limited to calendar and scheduling services (e.g., Google Calendar, Microsoft Outlook) for managing appointments, meetings, and events; task and project management tools (e.g., Asana, Trello) for organizing and tracking work items and collaborations; online shopping and e-commerce platforms (e.g., Amazon, eBay) for product search, comparison, and purchase; social media networks (e.g., Facebook/Meta, Twitter/X, Instagram, LinkedIn, Reddit, Pinterest) for content sharing, engagement tracking, and sentiment analysis; news and media outlets (e.g., CNN, BBC) for personalized news curation and updates; weather and environmental data providers (e.g., NOAA) for real-time weather forecasts and alerts; financial and banking services (e.g., PayPal, Stripe) for secure payment processing and transaction management; and health and fitness platforms (e.g., Fitbit) for tracking and analyzing wellness data and providing personalized recommendations.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ratnakaram, Walters, King, Kolchin, and Vasylyev, because it allows for an improved AI assistant system that can record, store, and process conversations in real-time and provide contextual understanding for reduced latency and improved accuracy and an improved system adaptable to various scenarios, such as in-vehicle, in-person, online, or mobile communications, and to enhance the interaction between multiple conversing parties. (Vasylyev at Abstract and paras. 1-10).
As per claim 6,
Ratnakaram explicitly teaches:
further comprising analyzing, via an intelligent data processing and analysis system, stored previous transactions associated with the user.
(Ratnakaram US20230214841 at paras. 6-7, 25-37, 104-105) ("[0027] Payment and recommendation computing platform may host, train, execute, update and/or validate the one or more machine learning models. For instance, training or historical data may be received and used to train the machine learning model. The training or historical data may identify sequences or patterns associated with scheduled events, amounts paid, types of events, recommendations, and the like, and train the machine learning model to predict recommendations, identify pre-authorization amounts, identify or select a payment mode, and the like." "[0035] Referring to FIG. 1B, payment and recommendation control computing platform 110 may include one or more processors 111, memory 112, and communication interface 113. A data bus may interconnect processor(s) 111, memory 112, and communication interface 113. Communication interface 113 may be a network interface configured to support communication payment and recommendation control computing platform 110 and one or more networks (e.g., private network 190, public network, or the like). Memory 112 may include one or more program modules having instructions that when executed by processor(s) 111 cause payment and recommendation control computing platform 110 to perform one or more functions described herein and/or one or more databases that may store and/or otherwise maintain information which may be used by such program modules and/or processor(s) 111." "[0036] For example, memory 112 may have, store and/or include historical/training data module 112a. Historical/training data module 112a may store instructions and/or data that may cause or enable the payment and recommendation control computing platform 110 to receive historical and or training data, including contextual data, related to one or more users, user purchases, user schedules, user orders, and the like and use that data to train one or more machine learning models stored in machine learning engine 112b. The historical and/or training data may include, for instance, a previous restaurant experience of a user, what was ordered, a cost and a tip provided. Information of this nature may be received from a plurality of sources, such as internal entity computing system 125 which may, e.g., process one or more account payments for a user, user devices such as remote user computing device 170, remote user computing device 175, and the like. The data may be gathered from a plurality of users and used to build and train one or more machine learning models stored and/or executed by machine learning engine 112b to identify one or more recommendations for a user, determine a pre-authorized amount and whether to automatically process a payment, and the like." "[0041] Payment and recommendation control computing platform 110 may further have, store and/or include a database 112f. Database 112f may store historical data associated with one or more users, user response data (e.g., user input received in response to a request for user input, and the like), and the like." )
As per claim 7,
Ratnakaram explicitly teaches:
further comprising analyzing stored previous transactions associated with the user and identifying patterns for associating payment transaction types with different vendors.
(Ratnakaram US20230214841 at paras. 27, 31, 94-100) ("[0027] Payment and recommendation computing platform may host, train, execute, update and/or validate the one or more machine learning models. For instance, training or historical data may be received and used to train the machine learning model. The training or historical data may identify sequences or patterns associated with scheduled events, amounts paid, types of events, recommendations, and the like, and train the machine learning model to predict recommendations, identify pre-authorization amounts, identify or select a payment mode, and the like." "[0031] External entity computing system 140 and/or external entity computing system 145 may be or include one or more computing devices and/or systems that may be associated with one or more entities external to or not associated with the enterprise organization. For instance, external entity computing system 140 and/or external entity computing system 145 may be associated with one or more vendors, restaurants, service providers, or the like. External entity computing system 140 and/or external entity computing system 145 may be configured to communicate with payment and recommendation control computing platform 110 to facilitate scheduling of events, payment for goods or services, and the like. In some examples, external entity computing system 140 and/or external entity computing system 145 may be or include a point-of-sale system at a vendor, restaurant, service provider, or the like." "[0095] Upon confirming that the location response data matches an expected location and the event location data, the payment may be processed at step 255. For instance, without user input or interaction, based on the payment being authorized by comparing location response data to expected location data and event location data, payment of the check or bill may be processed. In some examples, processing the payment may include selecting a payment device associated with the user from a plurality of payment modes or devices (e.g., different credit cards, debit card, or the like). In some examples, a user may pre-select a payment device. In some arrangements, the user may select different payment devices for different types of payments, different amounts, and the like. Additionally or alternatively, payment and recommendation control computing platform 110 may automatically select a payment device (e.g., based on historical data, amount, account closing date, account balance, or the like). Automatic selection of a payment device or mode may be based on contextual data, event data, and the like. [0096] At step 256, one or more payment instructions may be generated. For instance, instructions to process a payment, transfer funds from one account to another account or entity, update an account ledger, and the like, may be generated. [0097] At step 257, the generated one or more payment instructions may be transmitted to external entity computing system 140. For instance, an instruction to process payment for the bill, an account or payment device to process the payment, an amount of payment, and the like, may be transmitted to the external entity computing system 140. [0098] At step 258, the external entity computing system 140 may receive the one or more payment instructions and may execute the instructions. In some examples, executing the instructions may include transmitting and/or receiving data with a financial institution (e.g., associated with the payment device or account of the user) to update account information, record the transaction in a ledger, and the like.")
As per claim 8,
Ratnakaram and Walters do not explicitly teach, however, King does teach:
further comprising creating, via a profiling system agent, personalized payment profiles.
(King US20240346579 at paras. 48-50, 59-63) ("[0049] Memory 310 may include a model database 343 that stores one or more machine learning models used by all or a subset of logics 331-337, as described in greater detail herein. Memory 310 may further be configured, in some embodiments, to include a user profile database 341 that stores account information related to one or more consumer accounts with a financial entity (e.g., a consumer banking service 180) that owns or manages system 150, or accounts with other financial entities linked to such consumer accounts. In some embodiments, user profile database 341 may include one or more tables, each entry corresponding to a unique set of account information. In some embodiments, user profile database 341 may include information about a user and/or a related account, such as a unique account ID, an associated consumer ID, a current account balance, and information regarding pending deposit/withdraw activity, if existent, user name, contact information (e.g., email address, mailing address, telephone number, etc.), date of birth, payment card information (e.g., payment card number, expiration date, cardholder name, security code) for each of any number of associated payment cards, customer account settings and/or preferences, and the like. User profile database 341 may, in some embodiments, store information detailing every transaction made or requested in connection with the user's account(s), including any of approved transactions, rejected transactions, withdrawn transactions, pending transactions, contested transactions, refunded transactions, and the like, along with account balances resulting from such transactions.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ratnakaram, Walters, King, Kolchin, and Vasylyev, because it allows for an improved banking system may additionally, through monitoring and use of machine learning models, provide continually updated recommendations based on user activity. (King at Abstract and paras. 1-3, 86).
As per claim 9,
Ratnakaram does not explicitly teach, however, Walters does teach:
further comprising executing transactions via a payment engine configured to operate in conjunction with a rules evaluator engine.
(Walters US20210357923 at paras. 146-155) ("[0146] As further shown in FIG. 6, process 600 may include identifying a transaction pattern associated with a merchant account, wherein the transaction pattern is identified based on a plurality of historical transactions identified in the transaction log being associated with the merchant account (block 630). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may identify a transaction pattern associated with a merchant account, as described above. In some implementations, the transaction pattern is identified based on a plurality of historical transactions identified in the transaction log being associated with the merchant account. [0147] As further shown in FIG. 6, process 600 may include determining, based on the transaction pattern, that a historical transaction of the plurality of historical transactions is not designated for automatic execution (block 640). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may determine, based on the transaction pattern, that a historical transaction of the plurality of historical transactions is not designated for automatic execution, as described above. [0148] As further shown in FIG. 6, process 600 may include determining, based on determining that the historical transaction is not designated for automatic execution, that an execution of an upcoming transaction corresponding to the plurality of historical transactions is not scheduled (block 650). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may determine, based on determining that the historical transaction is not designated for automatic execution, that an execution of an upcoming transaction corresponding to the plurality of historical transactions is not scheduled, as described above. [0149] As further shown in FIG. 6, process 600 may include causing an account transaction associated with the upcoming transaction to be automatically executed before a transaction period expiration, that is associated with the merchant account, passes (block 660). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may cause an account transaction associated with the upcoming transaction to be automatically executed before a transaction period expiration, that is associated with the merchant account, passes, as described above." "[0155] In a fifth implementation, alone or in combination with one or more of the first through fourth implementations, causing the account transaction to be automatically executed comprises at least one of: scheduling an execution of a transaction corresponding to the upcoming transaction, designating a transaction corresponding to the upcoming transaction for automatic execution, or executing, via a transaction back end system, a transaction with the merchant account that corresponds to the upcoming transaction.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ratnakaram, Walters, King, Kolchin, and Vasylyev, because it allows for an improved system to cause an account transaction associated with the upcoming transaction to be automatically executed. (Walters at Abstract and paras. 1-4).
Claims 10-16 are rejected under 35 U.S.C. 103 as being unpatentable over Ratnakaram, U.S. Patent Application Publication Number 2023/0214841; in view of Walters, U.S. Patent Application Publication Number 2021/0357923; in view of Kolchin, U.S. Patent Application Publication Number 2024/0257124; in view of Vasylyev, U.S. Patent Application Publication Number 2024/0412720.
As per claim 10,
Ratnakaram explicitly teaches:
A banking system for initiating [future] payments from a user to a vendor, comprising: a controller including at least one processor, memory, and a communication interface; a gateway manager implemented as executable instructions stored in the memory and executed by the processor, the gateway manager being configured to [securely] receive payment requests and transaction context data from a user via the communication interface
(Ratnakaram US20230214841 at paras. 6-7, 25-35, 104-105) ("[0007] The system may receive a request for payment and event details, including an amount of the event, location of the event, and the like. The amount may be compared to the pre-authorized amount and, if more than the pre-authorized amount, a request for payment authorization may be transmitted to a user device. If the amount is not more than the pre-authorized amount, expected location data of the user may be received and current location data of the user may be requested from a user device. The current location data may be compared to the expected location data and event details and, if the locations match, the payment may be authorized and automatically processed." "[0026] Payment and recommendation control computing platform 110 may be configured to provide intelligent, dynamic, seamless payment processing and option recommendations based on contextual data for a user. For instance, payment and recommendation control computing platform 110 may receive data, such as contextual data, from one or more user devices, such as a smart phone, smart watch, fitness tracker, tablet computing device, or the like, and analyze the data using one or more machine learning models trained on historical data related to contextual data and user preferences. In some examples, the contextual data may include calendar data of the user, data captured from social media platforms, data from user reviews of entities, spending history and habits of the user, food preferences, feed data from IoT devices, and the like. The data may be analyzed to determine one or more recommendations to provide to the user. In some examples, the one or more recommendations may be automatically implemented (e.g., without additional user interaction or input). For example, analyzing the contextual data may identify a restaurant for a user to dine at and the system may automatically connect to the restaurant computing system and reserve a table for the user (e.g., without user interaction). One or more notifications may then be transmitted to the user." "[0031] External entity computing system 140 and/or external entity computing system 145 may be or include one or more computing devices and/or systems that may be associated with one or more entities external to or not associated with the enterprise organization. For instance, external entity computing system 140 and/or external entity computing system 145 may be associated with one or more vendors, restaurants, service providers, or the like. External entity computing system 140 and/or external entity computing system 145 may be configured to communicate with payment and recommendation control computing platform 110 to facilitate scheduling of events, payment for goods or services, and the like. In some examples, external entity computing system 140 and/or external entity computing system 145 may be or include a point-of-sale system at a vendor, restaurant, service provider, or the like." "[0035] Referring to FIG. 1B, payment and recommendation control computing platform 110 may include one or more processors 111, memory 112, and communication interface 113. A data bus may interconnect processor(s) 111, memory 112, and communication interface 113. Communication interface 113 may be a network interface configured to support communication payment and recommendation control computing platform 110 and one or more networks (e.g., private network 190, public network, or the like). Memory 112 may include one or more program modules having instructions that when executed by processor(s) 111 cause payment and recommendation control computing platform 110 to perform one or more functions described herein and/or one or more databases that may store and/or otherwise maintain information which may be used by such program modules and/or processor(s) 111." "[0105] At step 304, event data and a request for payment may be received by payment and recommendation control computing platform 110. For instance, event data and a request for payment may be received from an external entity computing system 140 associated with an entity hosting the event (e.g., the restaurant at which the user is dining, a vendor or service provider working with the user, and the like). In some examples, the event data may include a check or bill for payment due. In some arrangements, the event data may include an image or image data of the check or bill. The event data may further include a location of the event, a date of the event, a time of the event, and the like.")
an allocation engine implemented as executable instructions stored in the memory and executed by the processor, the allocation engine configured to: (i) apply an artificial intelligence model to analyze user behavior derived from stored transaction data;
(Ratnakaram US20230214841 at paras. 6-7, 25-37, 95-98, 104-105) ("[0027] Payment and recommendation computing platform may host, train, execute, update and/or validate the one or more machine learning models. For instance, training or historical data may be received and used to train the machine learning model. The training or historical data may identify sequences or patterns associated with scheduled events, amounts paid, types of events, recommendations, and the like, and train the machine learning model to predict recommendations, identify pre-authorization amounts, identify or select a payment mode, and the like." "[0035] Referring to FIG. 1B, payment and recommendation control computing platform 110 may include one or more processors 111, memory 112, and communication interface 113. A data bus may interconnect processor(s) 111, memory 112, and communication interface 113. Communication interface 113 may be a network interface configured to support communication payment and recommendation control computing platform 110 and one or more networks (e.g., private network 190, public network, or the like). Memory 112 may include one or more program modules having instructions that when executed by processor(s) 111 cause payment and recommendation control computing platform 110 to perform one or more functions described herein and/or one or more databases that may store and/or otherwise maintain information which may be used by such program modules and/or processor(s) 111." "[0036] For example, memory 112 may have, store and/or include historical/training data module 112a. Historical/training data module 112a may store instructions and/or data that may cause or enable the payment and recommendation control computing platform 110 to receive historical and or training data, including contextual data, related to one or more users, user purchases, user schedules, user orders, and the like and use that data to train one or more machine learning models stored in machine learning engine 112b. The historical and/or training data may include, for instance, a previous restaurant experience of a user, what was ordered, a cost and a tip provided. Information of this nature may be received from a plurality of sources, such as internal entity computing system 125 which may, e.g., process one or more account payments for a user, user devices such as remote user computing device 170, remote user computing device 175, and the like. The data may be gathered from a plurality of users and used to build and train one or more machine learning models stored and/or executed by machine learning engine 112b to identify one or more recommendations for a user, determine a pre-authorized amount and whether to automatically process a payment, and the like." "[0041] Payment and recommendation control computing platform 110 may further have, store and/or include a database 112f. Database 112f may store historical data associated with one or more users, user response data (e.g., user input received in response to a request for user input, and the like), and the like." "[0095] Upon confirming that the location response data matches an expected location and the event location data, the payment may be processed at step 255. For instance, without user input or interaction, based on the payment being authorized by comparing location response data to expected location data and event location data, payment of the check or bill may be processed. In some examples, processing the payment may include selecting a payment device associated with the user from a plurality of payment modes or devices (e.g., different credit cards, debit card, or the like). In some examples, a user may pre-select a payment device. In some arrangements, the user may select different payment devices for different types of payments, different amounts, and the like. Additionally or alternatively, payment and recommendation control computing platform 110 may automatically select a payment device (e.g., based on historical data, amount, account closing date, account balance, or the like). Automatic selection of a payment device or mode may be based on contextual data, event data, and the like.")
(iii) control routing and execution of transactions across a plurality of payment-network interfaces;
(Ratnakaram US20230214841 at Figs. 1A and 1B and paras. 31, 35, 95-98) ("[0031] External entity computing system 140 and/or external entity computing system 145 may be or include one or more computing devices and/or systems that may be associated with one or more entities external to or not associated with the enterprise organization. For instance, external entity computing system 140 and/or external entity computing system 145 may be associated with one or more vendors, restaurants, service providers, or the like. External entity computing system 140 and/or external entity computing system 145 may be configured to communicate with payment and recommendation control computing platform 110 to facilitate scheduling of events, payment for goods or services, and the like. In some examples, external entity computing system 140 and/or external entity computing system 145 may be or include a point-of-sale system at a vendor, restaurant, service provider, or the like." "[0035] Referring to FIG. 1B, payment and recommendation control computing platform 110 may include one or more processors 111, memory 112, and communication interface 113. A data bus may interconnect processor(s) 111, memory 112, and communication interface 113. Communication interface 113 may be a network interface configured to support communication payment and recommendation control computing platform 110 and one or more networks (e.g., private network 190, public network, or the like). Memory 112 may include one or more program modules having instructions that when executed by processor(s) 111 cause payment and recommendation control computing platform 110 to perform one or more functions described herein and/or one or more databases that may store and/or otherwise maintain information which may be used by such program modules and/or processor(s) 111. In some instances, the one or more program modules and/or databases may be stored by and/or maintained in different memory units of payment and recommendation control computing platform 110 and/or by different computing devices that may form and/or otherwise make up payment and recommendation control computing platform 110." "[0097] At step 257, the generated one or more payment instructions may be transmitted to external entity computing system 140. For instance, an instruction to process payment for the bill, an account or payment device to process the payment, an amount of payment, and the like, may be transmitted to the external entity computing system 140. [0098] At step 258, the external entity computing system 140 may receive the one or more payment instructions and may execute the instructions. In some examples, executing the instructions may include transmitting and/or receiving data with a financial institution (e.g., associated with the payment device or account of the user) to update account information, record the transaction in a ledger, and the like.")
wherein the controller automatically selects and executes an optimal payment transaction path for [future] payments based on recognized execution patterns and [security constraints] and wherein the allocation engine evaluates transaction requirements, available funds, authentication requirements, and stored transaction execution patterns associated with the plurality of vendor payment platforms to automatically select and execute a payment transaction path for the [future] payment transaction.
(Ratnakaram US20230214841 at paras. 26-27, 31, 39, 42, 95-98) ("[0026] The data may be analyzed to determine one or more recommendations to provide to the user. In some examples, the one or more recommendations may be automatically implemented (e.g., without additional user interaction or input)." "[0031] External entity computing system 140 and/or external entity computing system 145 may be or include one or more computing devices and/or systems that may be associated with one or more entities external to or not associated with the enterprise organization. For instance, external entity computing system 140 and/or external entity computing system 145 may be associated with one or more vendors, restaurants, service providers, or the like. External entity computing system 140 and/or external entity computing system 145 may be configured to communicate with payment and recommendation control computing platform 110 to facilitate scheduling of events, payment for goods or services, and the like. In some examples, external entity computing system 140 and/or external entity computing system 145 may be or include a point-of-sale system at a vendor, restaurant, service provider, or the like." "[0039] Payment and recommendation control computing platform 110 may further have, store and/or include output selection module 112d. Output selection module 112d may store instructions and/or data that may cause or enable payment and recommendation control computing platform 110 to select, based on one or more outputs generated by the one or more machine learning models and analysis of contextual data, an output for processing. For instance, the one or more machine learning models may generate more than one output with a recommended vendor, restaurant, service provider, or the like. In some examples, output selection module 112d may select one output from the more than one output generated and may generate instructions to process that output (e.g., automatically process a payment, automatically book a reservation for a user, or the like)." "[0042] FIGS. 2A-2K depict one example illustrative event sequence for executing payment and recommendation control functions in accordance with one or more aspects described herein. The events shown in the illustrative event sequence are merely one example sequence and additional events may be added, or events may be omitted, without departing from the invention. Further, one or more processes discussed with respect to FIGS. 2A-2K may be performed in real-time or near real-time." "[0095] Upon confirming that the location response data matches an expected location and the event location data, the payment may be processed at step 255. For instance, without user input or interaction, based on the payment being authorized by comparing location response data to expected location data and event location data, payment of the check or bill may be processed. In some examples, processing the payment may include selecting a payment device associated with the user from a plurality of payment modes or devices (e.g., different credit cards, debit card, or the like). In some examples, a user may pre-select a payment device. In some arrangements, the user may select different payment devices for different types of payments, different amounts, and the like. Additionally or alternatively, payment and recommendation control computing platform 110 may automatically select a payment device (e.g., based on historical data, amount, account closing date, account balance, or the like). Automatic selection of a payment device or mode may be based on contextual data, event data, and the like. [0096] At step 256, one or more payment instructions may be generated. For instance, instructions to process a payment, transfer funds from one account to another account or entity, update an account ledger, and the like, may be generated. [0097] At step 257, the generated one or more payment instructions may be transmitted to external entity computing system 140. For instance, an instruction to process payment for the bill, an account or payment device to process the payment, an amount of payment, and the like, may be transmitted to the external entity computing system 140. [0098] At step 258, the external entity computing system 140 may receive the one or more payment instructions and may execute the instructions. In some examples, executing the instructions may include transmitting and/or receiving data with a financial institution (e.g., associated with the payment device or account of the user) to update account information, record the transaction in a ledger, and the like.")
Ratnakaram does not explicitly teach, however, Walters does teach:
automatically...executes...future payments…
(Walters US20210357923 at paras. 146-155) ("[0146] As further shown in FIG. 6, process 600 may include identifying a transaction pattern associated with a merchant account, wherein the transaction pattern is identified based on a plurality of historical transactions identified in the transaction log being associated with the merchant account (block 630). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may identify a transaction pattern associated with a merchant account, as described above. In some implementations, the transaction pattern is identified based on a plurality of historical transactions identified in the transaction log being associated with the merchant account. [0147] As further shown in FIG. 6, process 600 may include determining, based on the transaction pattern, that a historical transaction of the plurality of historical transactions is not designated for automatic execution (block 640). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may determine, based on the transaction pattern, that a historical transaction of the plurality of historical transactions is not designated for automatic execution, as described above. [0148] As further shown in FIG. 6, process 600 may include determining, based on determining that the historical transaction is not designated for automatic execution, that an execution of an upcoming transaction corresponding to the plurality of historical transactions is not scheduled (block 650). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may determine, based on determining that the historical transaction is not designated for automatic execution, that an execution of an upcoming transaction corresponding to the plurality of historical transactions is not scheduled, as described above. [0149] As further shown in FIG. 6, process 600 may include causing an account transaction associated with the upcoming transaction to be automatically executed before a transaction period expiration, that is associated with the merchant account, passes (block 660). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may cause an account transaction associated with the upcoming transaction to be automatically executed before a transaction period expiration, that is associated with the merchant account, passes, as described above." "[0155] In a fifth implementation, alone or in combination with one or more of the first through fourth implementations, causing the account transaction to be automatically executed comprises at least one of: scheduling an execution of a transaction corresponding to the upcoming transaction, designating a transaction corresponding to the upcoming transaction for automatic execution, or executing, via a transaction back end system, a transaction with the merchant account that corresponds to the upcoming transaction.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ratnakaram and Walters, because it allows for an improved system to cause an account transaction associated with the upcoming transaction to be automatically executed. (Walters at Abstract and paras. 1-4).
Ratnakaram and Walters do not explicitly teach, however, Kolchin does teach:
(ii) evaluate authentication requirements and transaction-specific risk levels; and
(Kolchin US20240257124 at paras. 108-114, 197-199, 206-208) ("[0108] In some instances, the method can include the step of marking the transaction as pending until the transaction is approved by the account holder. The approval of the transaction by the account holder can include the approval of the terms of the transaction. The method can include the step of increasing the speed of the transaction based on the account holder's financial credibility by adjusting the predetermined time. [0109] The second account can include one or more accounts and the pre-authorization charge of the second account can be made using one or more accounts (for example a pre-authorized charge of $10,000 can be divided up among several accounts, such that, for example, $5000 is charged to a first credit card and another $5000 is charged to a second credit card). The ACH pre-authorization release time can be adjusted based on the transaction amount or risk of transaction based on the risk assessment data (e.g., the pre-authorization can be held for 60 days for a high-risk transaction and for 20 days for a lower risk transaction). [0110] The system of the present invention is configured to provide a secure way of uploading checks to ensure that sensitive/confidential data is not being exposed by enabling merchants to send check image link/token for remote uploads. In a situation when the merchant and the consumer are located too far apart from each other, the system provides a merchant with the ability to send a consumer an sms/email containing instructions/request to upload a front and back image of the check. A merchant can also send a special link with a link to the application that will allow consumers to upload the image. However, consumers might not like wasting their time on uploading unknown applications. In that case, the system allows a merchant to send to a consumer a website link that will allow secure uploading of images. In both cases the images will be uploaded to an iWallet server, and each image will have a link/token associated with it. A token/link (along with other transaction information such as amount, name, address, ID, date, security information) will then be sent to the merchant or the processor to initiate a transaction. This approach ensures that the sensitive/confidential data is not exposed and provides extra security to consumers and merchants." "[0206] Another embodiment of the present invention, that might be used by itself or in combination with the described-above methods is a holographic image detection on cards using a smartphone. Most major credit card companies such as Visa, MasterCard, and Discover use a holographic image to make it harder to create a fake credit card. There are multiple ways to detect a valid hologram: [0207] a. by taking multiple pictures at different angles and making sure that the hologram is “moving.” [0208] b. since most modern phones have multiple cameras that are located at slightly different angles, it's possible to take a picture/video of the image using multiple cameras at the same time and be able to immediately see/detect the holographic “moving” image with high accuracy.)
security constraints…
(Kolchin US20240257124 at paras. 108-114, 197-199, 206-208) ("[0108] In some instances, the method can include the step of marking the transaction as pending until the transaction is approved by the account holder. The approval of the transaction by the account holder can include the approval of the terms of the transaction. The method can include the step of increasing the speed of the transaction based on the account holder's financial credibility by adjusting the predetermined time. [0109] The second account can include one or more accounts and the pre-authorization charge of the second account can be made using one or more accounts (for example a pre-authorized charge of $10,000 can be divided up among several accounts, such that, for example, $5000 is charged to a first credit card and another $5000 is charged to a second credit card). The ACH pre-authorization release time can be adjusted based on the transaction amount or risk of transaction based on the risk assessment data (e.g., the pre-authorization can be held for 60 days for a high-risk transaction and for 20 days for a lower risk transaction). [0110] The system of the present invention is configured to provide a secure way of uploading checks to ensure that sensitive/confidential data is not being exposed by enabling merchants to send check image link/token for remote uploads. In a situation when the merchant and the consumer are located too far apart from each other, the system provides a merchant with the ability to send a consumer an sms/email containing instructions/request to upload a front and back image of the check. A merchant can also send a special link with a link to the application that will allow consumers to upload the image. However, consumers might not like wasting their time on uploading unknown applications. In that case, the system allows a merchant to send to a consumer a website link that will allow secure uploading of images. In both cases the images will be uploaded to an iWallet server, and each image will have a link/token associated with it. A token/link (along with other transaction information such as amount, name, address, ID, date, security information) will then be sent to the merchant or the processor to initiate a transaction. This approach ensures that the sensitive/confidential data is not exposed and provides extra security to consumers and merchants." "[0206] Another embodiment of the present invention, that might be used by itself or in combination with the described-above methods is a holographic image detection on cards using a smartphone. Most major credit card companies such as Visa, MasterCard, and Discover use a holographic image to make it harder to create a fake credit card. There are multiple ways to detect a valid hologram: [0207] a. by taking multiple pictures at different angles and making sure that the hologram is “moving.” [0208] b. since most modern phones have multiple cameras that are located at slightly different angles, it's possible to take a picture/video of the image using multiple cameras at the same time and be able to immediately see/detect the holographic “moving” image with high accuracy.)
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ratnakaram, Walters, and Kolchin, because it allows for conducting secure financial transactions using a model-based reflex agent includes receiving transaction-related precepts through sensors, wherein the precepts include transaction details, user credentials, and risk-related information. The system further includes maintaining, by the model-based reflex agent, an internal state that reflects observed and inferred aspects of the transaction based on the received precepts and a world model describing how the financial system evolves and the impact of agent actions. (Kolchin at Abstract and paras. 2-11).
Ratnakaram, Walters, and Kolchin do not explicitly teach, however, Vasylyev does teach:
securely receive payment requests…
(Vasylyev US20240412720 at paras. 37-40, 53-58) ("[0039] Furthermore, the Assistant is equipped to recognize one or more voices, which can be designated as control voices. It monitors the conversation for a control signal which could be a key phrase pronounced by the control voice, a button press, a gesture, non-verbal cues, or other recognizable commands. The control signals could be single or multi-factor and may include biometric security measures. The control signal triggers the Assistant to record a subsequent voice command from the user. According to one embodiment, the Assistant provides the user with the ability to set or change the control signals that trigger the Assistant." "[0054] Throughout this process, the Assistant can engage in a natural back-and-forth conversation with the user to gather any missing information, provide updates on the booking status, and handle any changes or cancellations as needed. The Assistant can also build, as part of the conversation with the user, and use its knowledge of the user's preferences and past behavior to make intelligent decisions on their behalf, such as selecting their preferred ride type or payment method, without requiring explicit input at every step." "[0058] Other examples of potentially useful integrations include but are not limited to calendar and scheduling services (e.g., Google Calendar, Microsoft Outlook) for managing appointments, meetings, and events; task and project management tools (e.g., Asana, Trello) for organizing and tracking work items and collaborations; online shopping and e-commerce platforms (e.g., Amazon, eBay) for product search, comparison, and purchase; social media networks (e.g., Facebook/Meta, Twitter/X, Instagram, LinkedIn, Reddit, Pinterest) for content sharing, engagement tracking, and sentiment analysis; news and media outlets (e.g., CNN, BBC) for personalized news curation and updates; weather and environmental data providers (e.g., NOAA) for real-time weather forecasts and alerts; financial and banking services (e.g., PayPal, Stripe) for secure payment processing and transaction management; and health and fitness platforms (e.g., Fitbit) for tracking and analyzing wellness data and providing personalized recommendations.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ratnakaram, Walters, Kolchin, and Vasylyev, because it allows for an improved AI assistant system that can record, store, and process conversations in real-time and provide contextual understanding for reduced latency and improved accuracy and an improved system adaptable to various scenarios, such as in-vehicle, in-person, online, or mobile communications, and to enhance the interaction between multiple conversing parties. (Vasylyev at Abstract and paras. 1-10).
As per claim 11,
Ratnakaram explicitly teaches:
wherein the behavior relates to at least one of selecting payment methods and selecting authentication methods.
(Ratnakaram US20230214841 at paras. 7, 27, 31, 94-100) ("[0007] The system may receive a request for payment and event details, including an amount of the event, location of the event, and the like. The amount may be compared to the pre-authorized amount and, if more than the pre-authorized amount, a request for payment authorization may be transmitted to a user device. If the amount is not more than the pre-authorized amount, expected location data of the user may be received and current location data of the user may be requested from a user device. The current location data may be compared to the expected location data and event details and, if the locations match, the payment may be authorized and automatically processed." "[0095] Upon confirming that the location response data matches an expected location and the event location data, the payment may be processed at step 255. For instance, without user input or interaction, based on the payment being authorized by comparing location response data to expected location data and event location data, payment of the check or bill may be processed. In some examples, processing the payment may include selecting a payment device associated with the user from a plurality of payment modes or devices (e.g., different credit cards, debit card, or the like). In some examples, a user may pre-select a payment device. In some arrangements, the user may select different payment devices for different types of payments, different amounts, and the like. Additionally or alternatively, payment and recommendation control computing platform 110 may automatically select a payment device (e.g., based on historical data, amount, account closing date, account balance, or the like). Automatic selection of a payment device or mode may be based on contextual data, event data, and the like. [0096] At step 256, one or more payment instructions may be generated. For instance, instructions to process a payment, transfer funds from one account to another account or entity, update an account ledger, and the like, may be generated. [0097] At step 257, the generated one or more payment instructions may be transmitted to external entity computing system 140. For instance, an instruction to process payment for the bill, an account or payment device to process the payment, an amount of payment, and the like, may be transmitted to the external entity computing system 140. [0098] At step 258, the external entity computing system 140 may receive the one or more payment instructions and may execute the instructions. In some examples, executing the instructions may include transmitting and/or receiving data with a financial institution (e.g., associated with the payment device or account of the user) to update account information, record the transaction in a ledger, and the like.")
As per claim 12,
Ratnakaram explicitly teaches:
wherein the payment methods include at least one of credit cards, e-wallets, bank transfers, and unified payment interfaces.
(Ratnakaram US20230214841 at paras. 7, 27, 31, 94-100) ("[0007] The system may receive a request for payment and event details, including an amount of the event, location of the event, and the like. The amount may be compared to the pre-authorized amount and, if more than the pre-authorized amount, a request for payment authorization may be transmitted to a user device. If the amount is not more than the pre-authorized amount, expected location data of the user may be received and current location data of the user may be requested from a user device. The current location data may be compared to the expected location data and event details and, if the locations match, the payment may be authorized and automatically processed." "[0095] Upon confirming that the location response data matches an expected location and the event location data, the payment may be processed at step 255. For instance, without user input or interaction, based on the payment being authorized by comparing location response data to expected location data and event location data, payment of the check or bill may be processed. In some examples, processing the payment may include selecting a payment device associated with the user from a plurality of payment modes or devices (e.g., different credit cards, debit card, or the like). In some examples, a user may pre-select a payment device. In some arrangements, the user may select different payment devices for different types of payments, different amounts, and the like. Additionally or alternatively, payment and recommendation control computing platform 110 may automatically select a payment device (e.g., based on historical data, amount, account closing date, account balance, or the like). Automatic selection of a payment device or mode may be based on contextual data, event data, and the like. [0096] At step 256, one or more payment instructions may be generated. For instance, instructions to process a payment, transfer funds from one account to another account or entity, update an account ledger, and the like, may be generated. [0097] At step 257, the generated one or more payment instructions may be transmitted to external entity computing system 140. For instance, an instruction to process payment for the bill, an account or payment device to process the payment, an amount of payment, and the like, may be transmitted to the external entity computing system 140. [0098] At step 258, the external entity computing system 140 may receive the one or more payment instructions and may execute the instructions. In some examples, executing the instructions may include transmitting and/or receiving data with a financial institution (e.g., associated with the payment device or account of the user) to update account information, record the transaction in a ledger, and the like.")
As per claim 13,
Ratnakaram and Walters do not explicitly teach, however, Kolchin does teach:
further comprising a security engine implemented as executable instructions stored in memory and executed by the processor, the security engine configured to enforce multi-factor authentication during transaction execution by dynamically adjusting authentication methods based on transaction amount, user-defined security profiles, and real-time risk evaluation.
(Kolchin US20240257124 at paras. 108-114, 197-199, 206-208) ("[0108] In some instances, the method can include the step of marking the transaction as pending until the transaction is approved by the account holder. The approval of the transaction by the account holder can include the approval of the terms of the transaction. The method can include the step of increasing the speed of the transaction based on the account holder's financial credibility by adjusting the predetermined time. [0109] The second account can include one or more accounts and the pre-authorization charge of the second account can be made using one or more accounts (for example a pre-authorized charge of $10,000 can be divided up among several accounts, such that, for example, $5000 is charged to a first credit card and another $5000 is charged to a second credit card). The ACH pre-authorization release time can be adjusted based on the transaction amount or risk of transaction based on the risk assessment data (e.g., the pre-authorization can be held for 60 days for a high-risk transaction and for 20 days for a lower risk transaction). [0110] The system of the present invention is configured to provide a secure way of uploading checks to ensure that sensitive/confidential data is not being exposed by enabling merchants to send check image link/token for remote uploads. In a situation when the merchant and the consumer are located too far apart from each other, the system provides a merchant with the ability to send a consumer an sms/email containing instructions/request to upload a front and back image of the check. A merchant can also send a special link with a link to the application that will allow consumers to upload the image. However, consumers might not like wasting their time on uploading unknown applications. In that case, the system allows a merchant to send to a consumer a website link that will allow secure uploading of images. In both cases the images will be uploaded to an iWallet server, and each image will have a link/token associated with it. A token/link (along with other transaction information such as amount, name, address, ID, date, security information) will then be sent to the merchant or the processor to initiate a transaction. This approach ensures that the sensitive/confidential data is not exposed and provides extra security to consumers and merchants." "[0198] There are two requirements to validate the “card-present” status, which is (i) a card needs to be present, and (ii) a cardholder needs to be present. The first requirement can be detected using the following method, using just a smartphone with no extra hardware: a) using NFC (by reading special non-visible NFC markers) merchant's phone or cardholders phone or other authorized party; b) using NFC (by writing special non-visible NFC markers into NFC memory) merchant's phone or cardholders phone or other authorized party; c) using camera for picture by merchant's phone or cardholders phone or other authorized party; d) using camera for video by merchant's phone or cardholders phone or other authorized party e) using camera in a combination with merchants certification or cardholder certification or other authorized party; f) certification by merchant's or cardholders or other authorized party; or a combination of the above methods. Extracting other information from the phone such as Google ID/Apple ID/Samsung ID, as well as phone number during the NFC transaction and sending it to the processor can also be used to reduce the transaction risk and to prevent fraud. The second requirement can be detected using the following methods: a) something the cardholder has such as any physical object in the possession of the user, for example a security token (USB stick), a bank card, a key, or a phone; b) something the user knows: certain knowledge only known to the user, such as a password, PIN, or the like; c) some physical characteristic attributable to the user (biometrics), such as a fingerprint, eye iris, voice, typing speed, pattern in key press intervals, etc.; d) the user's location: some connection to a specific computing network, or detection of the location using a GPS, GSM, Bluetooth, or WIFI signal to identify the location, or a combination of the above methods. In some instances, a physical location of a home or a business that is owned by a cardholder plus virtual real-time or offline cardholder authorization might be a way to replace the requirement for physical cardholder presence." "[0206] Another embodiment of the present invention, that might be used by itself or in combination with the described-above methods is a holographic image detection on cards using a smartphone. Most major credit card companies such as Visa, MasterCard, and Discover use a holographic image to make it harder to create a fake credit card. There are multiple ways to detect a valid hologram: [0207] a. by taking multiple pictures at different angles and making sure that the hologram is “moving.” [0208] b. since most modern phones have multiple cameras that are located at slightly different angles, it's possible to take a picture/video of the image using multiple cameras at the same time and be able to immediately see/detect the holographic “moving” image with high accuracy.)
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ratnakaram, Walters, Kolchin, and Vasylyev, because it allows for conducting secure financial transactions using a model-based reflex agent includes receiving transaction-related precepts through sensors, wherein the precepts include transaction details, user credentials, and risk-related information. The system further includes maintaining, by the model-based reflex agent, an internal state that reflects observed and inferred aspects of the transaction based on the received precepts and a world model describing how the financial system evolves and the impact of agent actions. (Kolchin at Abstract and paras. 2-11).
As per claim 14,
Ratnakaram explicitly teaches:
wherein the gateway manager
(Ratnakaram US20230214841 at paras. 6-7, 25-35, 104-105) ("[0007] The system may receive a request for payment and event details, including an amount of the event, location of the event, and the like. The amount may be compared to the pre-authorized amount and, if more than the pre-authorized amount, a request for payment authorization may be transmitted to a user device. If the amount is not more than the pre-authorized amount, expected location data of the user may be received and current location data of the user may be requested from a user device. The current location data may be compared to the expected location data and event details and, if the locations match, the payment may be authorized and automatically processed." "[0026] Payment and recommendation control computing platform 110 may be configured to provide intelligent, dynamic, seamless payment processing and option recommendations based on contextual data for a user. For instance, payment and recommendation control computing platform 110 may receive data, such as contextual data, from one or more user devices, such as a smart phone, smart watch, fitness tracker, tablet computing device, or the like, and analyze the data using one or more machine learning models trained on historical data related to contextual data and user preferences. In some examples, the contextual data may include calendar data of the user, data captured from social media platforms, data from user reviews of entities, spending history and habits of the user, food preferences, feed data from IoT devices, and the like. The data may be analyzed to determine one or more recommendations to provide to the user. In some examples, the one or more recommendations may be automatically implemented (e.g., without additional user interaction or input). For example, analyzing the contextual data may identify a restaurant for a user to dine at and the system may automatically connect to the restaurant computing system and reserve a table for the user (e.g., without user interaction). One or more notifications may then be transmitted to the user.")
Ratnakaram, Walters, and Kolchin do not explicitly teach, however, Vasylyev does teach:
securely receives the requests from the user.
(Vasylyev US20240412720 at paras. 37-40, 53-58) ("[0039] Furthermore, the Assistant is equipped to recognize one or more voices, which can be designated as control voices. It monitors the conversation for a control signal which could be a key phrase pronounced by the control voice, a button press, a gesture, non-verbal cues, or other recognizable commands. The control signals could be single or multi-factor and may include biometric security measures. The control signal triggers the Assistant to record a subsequent voice command from the user. According to one embodiment, the Assistant provides the user with the ability to set or change the control signals that trigger the Assistant." "[0054] Throughout this process, the Assistant can engage in a natural back-and-forth conversation with the user to gather any missing information, provide updates on the booking status, and handle any changes or cancellations as needed. The Assistant can also build, as part of the conversation with the user, and use its knowledge of the user's preferences and past behavior to make intelligent decisions on their behalf, such as selecting their preferred ride type or payment method, without requiring explicit input at every step." "[0058] Other examples of potentially useful integrations include but are not limited to calendar and scheduling services (e.g., Google Calendar, Microsoft Outlook) for managing appointments, meetings, and events; task and project management tools (e.g., Asana, Trello) for organizing and tracking work items and collaborations; online shopping and e-commerce platforms (e.g., Amazon, eBay) for product search, comparison, and purchase; social media networks (e.g., Facebook/Meta, Twitter/X, Instagram, LinkedIn, Reddit, Pinterest) for content sharing, engagement tracking, and sentiment analysis; news and media outlets (e.g., CNN, BBC) for personalized news curation and updates; weather and environmental data providers (e.g., NOAA) for real-time weather forecasts and alerts; financial and banking services (e.g., PayPal, Stripe) for secure payment processing and transaction management; and health and fitness platforms (e.g., Fitbit) for tracking and analyzing wellness data and providing personalized recommendations.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ratnakaram, Walters, Kolchin, and Vasylyev, because it allows for an improved AI assistant system that can record, store, and process conversations in real-time and provide contextual understanding for reduced latency and improved accuracy and an improved system adaptable to various scenarios, such as in-vehicle, in-person, online, or mobile communications, and to enhance the interaction between multiple conversing parties. (Vasylyev at Abstract and paras. 1-10).
As per claim 15,
Ratnakaram explicitly teaches:
further comprising an intelligent data processing and analysis system.
(Ratnakaram US20230214841 at paras. 6-7, 25-37, 104-105) ("[0027] Payment and recommendation computing platform may host, train, execute, update and/or validate the one or more machine learning models. For instance, training or historical data may be received and used to train the machine learning model. The training or historical data may identify sequences or patterns associated with scheduled events, amounts paid, types of events, recommendations, and the like, and train the machine learning model to predict recommendations, identify pre-authorization amounts, identify or select a payment mode, and the like." "[0035] Referring to FIG. 1B, payment and recommendation control computing platform 110 may include one or more processors 111, memory 112, and communication interface 113. A data bus may interconnect processor(s) 111, memory 112, and communication interface 113. Communication interface 113 may be a network interface configured to support communication payment and recommendation control computing platform 110 and one or more networks (e.g., private network 190, public network, or the like). Memory 112 may include one or more program modules having instructions that when executed by processor(s) 111 cause payment and recommendation control computing platform 110 to perform one or more functions described herein and/or one or more databases that may store and/or otherwise maintain information which may be used by such program modules and/or processor(s) 111." "[0036] For example, memory 112 may have, store and/or include historical/training data module 112a. Historical/training data module 112a may store instructions and/or data that may cause or enable the payment and recommendation control computing platform 110 to receive historical and or training data, including contextual data, related to one or more users, user purchases, user schedules, user orders, and the like and use that data to train one or more machine learning models stored in machine learning engine 112b. The historical and/or training data may include, for instance, a previous restaurant experience of a user, what was ordered, a cost and a tip provided. Information of this nature may be received from a plurality of sources, such as internal entity computing system 125 which may, e.g., process one or more account payments for a user, user devices such as remote user computing device 170, remote user computing device 175, and the like. The data may be gathered from a plurality of users and used to build and train one or more machine learning models stored and/or executed by machine learning engine 112b to identify one or more recommendations for a user, determine a pre-authorized amount and whether to automatically process a payment, and the like." "[0041] Payment and recommendation control computing platform 110 may further have, store and/or include a database 112f. Database 112f may store historical data associated with one or more users, user response data (e.g., user input received in response to a request for user input, and the like), and the like." )
As per claim 16,
Ratnakaram explicitly teaches:
wherein the intelligent data processing and analysis system includes a data processing and analysis agent configured for analyzing stored previous transactions associated with the user, and identifying patterns associating payment transaction types with different vendors.
(Ratnakaram US20230214841 at paras. 27, 31, 94-100) ("[0027] Payment and recommendation computing platform may host, train, execute, update and/or validate the one or more machine learning models. For instance, training or historical data may be received and used to train the machine learning model. The training or historical data may identify sequences or patterns associated with scheduled events, amounts paid, types of events, recommendations, and the like, and train the machine learning model to predict recommendations, identify pre-authorization amounts, identify or select a payment mode, and the like." "[0031] External entity computing system 140 and/or external entity computing system 145 may be or include one or more computing devices and/or systems that may be associated with one or more entities external to or not associated with the enterprise organization. For instance, external entity computing system 140 and/or external entity computing system 145 may be associated with one or more vendors, restaurants, service providers, or the like. External entity computing system 140 and/or external entity computing system 145 may be configured to communicate with payment and recommendation control computing platform 110 to facilitate scheduling of events, payment for goods or services, and the like. In some examples, external entity computing system 140 and/or external entity computing system 145 may be or include a point-of-sale system at a vendor, restaurant, service provider, or the like." "[0095] Upon confirming that the location response data matches an expected location and the event location data, the payment may be processed at step 255. For instance, without user input or interaction, based on the payment being authorized by comparing location response data to expected location data and event location data, payment of the check or bill may be processed. In some examples, processing the payment may include selecting a payment device associated with the user from a plurality of payment modes or devices (e.g., different credit cards, debit card, or the like). In some examples, a user may pre-select a payment device. In some arrangements, the user may select different payment devices for different types of payments, different amounts, and the like. Additionally or alternatively, payment and recommendation control computing platform 110 may automatically select a payment device (e.g., based on historical data, amount, account closing date, account balance, or the like). Automatic selection of a payment device or mode may be based on contextual data, event data, and the like. [0096] At step 256, one or more payment instructions may be generated. For instance, instructions to process a payment, transfer funds from one account to another account or entity, update an account ledger, and the like, may be generated. [0097] At step 257, the generated one or more payment instructions may be transmitted to external entity computing system 140. For instance, an instruction to process payment for the bill, an account or payment device to process the payment, an amount of payment, and the like, may be transmitted to the external entity computing system 140. [0098] At step 258, the external entity computing system 140 may receive the one or more payment instructions and may execute the instructions. In some examples, executing the instructions may include transmitting and/or receiving data with a financial institution (e.g., associated with the payment device or account of the user) to update account information, record the transaction in a ledger, and the like.")
Claims 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Ratnakaram, U.S. Patent Application Publication Number 2023/0214841; in view of Walters, U.S. Patent Application Publication Number 2021/0357923; in view of King, U.S. Patent Application Publication Number 2024/0346579; in view of Vasylyev, U.S. Patent Application Publication Number 2024/0412720.
As per claim 17,
Ratnakaram explicitly teaches:
A system for profiling payment transactions between a user and selected service provider platforms, the system comprising: a controller including at least one processor and memory; an analytics agent implemented as executable instructions executed by the processor, the analytics agent configured to derive transaction execution patterns from stored payment records;
(Ratnakaram US20230214841 at paras. 6-7, 25-35, 104-105) ("[0007] The system may receive a request for payment and event details, including an amount of the event, location of the event, and the like. The amount may be compared to the pre-authorized amount and, if more than the pre-authorized amount, a request for payment authorization may be transmitted to a user device. If the amount is not more than the pre-authorized amount, expected location data of the user may be received and current location data of the user may be requested from a user device. The current location data may be compared to the expected location data and event details and, if the locations match, the payment may be authorized and automatically processed." "[0026] Payment and recommendation control computing platform 110 may be configured to provide intelligent, dynamic, seamless payment processing and option recommendations based on contextual data for a user. For instance, payment and recommendation control computing platform 110 may receive data, such as contextual data, from one or more user devices, such as a smart phone, smart watch, fitness tracker, tablet computing device, or the like, and analyze the data using one or more machine learning models trained on historical data related to contextual data and user preferences. In some examples, the contextual data may include calendar data of the user, data captured from social media platforms, data from user reviews of entities, spending history and habits of the user, food preferences, feed data from IoT devices, and the like. The data may be analyzed to determine one or more recommendations to provide to the user. In some examples, the one or more recommendations may be automatically implemented (e.g., without additional user interaction or input). For example, analyzing the contextual data may identify a restaurant for a user to dine at and the system may automatically connect to the restaurant computing system and reserve a table for the user (e.g., without user interaction). One or more notifications may then be transmitted to the user." "[0031] External entity computing system 140 and/or external entity computing system 145 may be or include one or more computing devices and/or systems that may be associated with one or more entities external to or not associated with the enterprise organization. For instance, external entity computing system 140 and/or external entity computing system 145 may be associated with one or more vendors, restaurants, service providers, or the like. External entity computing system 140 and/or external entity computing system 145 may be configured to communicate with payment and recommendation control computing platform 110 to facilitate scheduling of events, payment for goods or services, and the like. In some examples, external entity computing system 140 and/or external entity computing system 145 may be or include a point-of-sale system at a vendor, restaurant, service provider, or the like." "[0035] Referring to FIG. 1B, payment and recommendation control computing platform 110 may include one or more processors 111, memory 112, and communication interface 113. A data bus may interconnect processor(s) 111, memory 112, and communication interface 113. Communication interface 113 may be a network interface configured to support communication payment and recommendation control computing platform 110 and one or more networks (e.g., private network 190, public network, or the like). Memory 112 may include one or more program modules having instructions that when executed by processor(s) 111 cause payment and recommendation control computing platform 110 to perform one or more functions described herein and/or one or more databases that may store and/or otherwise maintain information which may be used by such program modules and/or processor(s) 111." "[0105] At step 304, event data and a request for payment may be received by payment and recommendation control computing platform 110. For instance, event data and a request for payment may be received from an external entity computing system 140 associated with an entity hosting the event (e.g., the restaurant at which the user is dining, a vendor or service provider working with the user, and the like). In some examples, the event data may include a check or bill for payment due. In some arrangements, the event data may include an image or image data of the check or bill. The event data may further include a location of the event, a date of the event, a time of the event, and the like.")
vendor payment platform preferences and authentication rules; and
(Ratnakaram US20230214841 at paras. 6-7, 25-35, 104-105) ("[0007] The system may receive a request for payment and event details, including an amount of the event, location of the event, and the like. The amount may be compared to the pre-authorized amount and, if more than the pre-authorized amount, a request for payment authorization may be transmitted to a user device. If the amount is not more than the pre-authorized amount, expected location data of the user may be received and current location data of the user may be requested from a user device. The current location data may be compared to the expected location data and event details and, if the locations match, the payment may be authorized and automatically processed." "[0026] Payment and recommendation control computing platform 110 may be configured to provide intelligent, dynamic, seamless payment processing and option recommendations based on contextual data for a user. For instance, payment and recommendation control computing platform 110 may receive data, such as contextual data, from one or more user devices, such as a smart phone, smart watch, fitness tracker, tablet computing device, or the like, and analyze the data using one or more machine learning models trained on historical data related to contextual data and user preferences. In some examples, the contextual data may include calendar data of the user, data captured from social media platforms, data from user reviews of entities, spending history and habits of the user, food preferences, feed data from IoT devices, and the like. The data may be analyzed to determine one or more recommendations to provide to the user. In some examples, the one or more recommendations may be automatically implemented (e.g., without additional user interaction or input). For example, analyzing the contextual data may identify a restaurant for a user to dine at and the system may automatically connect to the restaurant computing system and reserve a table for the user (e.g., without user interaction). One or more notifications may then be transmitted to the user." "[0031] External entity computing system 140 and/or external entity computing system 145 may be or include one or more computing devices and/or systems that may be associated with one or more entities external to or not associated with the enterprise organization. For instance, external entity computing system 140 and/or external entity computing system 145 may be associated with one or more vendors, restaurants, service providers, or the like. External entity computing system 140 and/or external entity computing system 145 may be configured to communicate with payment and recommendation control computing platform 110 to facilitate scheduling of events, payment for goods or services, and the like. In some examples, external entity computing system 140 and/or external entity computing system 145 may be or include a point-of-sale system at a vendor, restaurant, service provider, or the like." "[0035] Referring to FIG. 1B, payment and recommendation control computing platform 110 may include one or more processors 111, memory 112, and communication interface 113. A data bus may interconnect processor(s) 111, memory 112, and communication interface 113. Communication interface 113 may be a network interface configured to support communication payment and recommendation control computing platform 110 and one or more networks (e.g., private network 190, public network, or the like). Memory 112 may include one or more program modules having instructions that when executed by processor(s) 111 cause payment and recommendation control computing platform 110 to perform one or more functions described herein and/or one or more databases that may store and/or otherwise maintain information which may be used by such program modules and/or processor(s) 111." "[0105] At step 304, event data and a request for payment may be received by payment and recommendation control computing platform 110. For instance, event data and a request for payment may be received from an external entity computing system 140 associated with an entity hosting the event (e.g., the restaurant at which the user is dining, a vendor or service provider working with the user, and the like). In some examples, the event data may include a check or bill for payment due. In some arrangements, the event data may include an image or image data of the check or bill. The event data may further include a location of the event, a date of the event, a time of the event, and the like.")
Ratnakaram does not explicitly teach, however, Walters does teach:
controlling future transaction executions,
(Walters US20210357923 at paras. 146-155) ("[0146] As further shown in FIG. 6, process 600 may include identifying a transaction pattern associated with a merchant account, wherein the transaction pattern is identified based on a plurality of historical transactions identified in the transaction log being associated with the merchant account (block 630). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may identify a transaction pattern associated with a merchant account, as described above. In some implementations, the transaction pattern is identified based on a plurality of historical transactions identified in the transaction log being associated with the merchant account. [0147] As further shown in FIG. 6, process 600 may include determining, based on the transaction pattern, that a historical transaction of the plurality of historical transactions is not designated for automatic execution (block 640). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may determine, based on the transaction pattern, that a historical transaction of the plurality of historical transactions is not designated for automatic execution, as described above. [0148] As further shown in FIG. 6, process 600 may include determining, based on determining that the historical transaction is not designated for automatic execution, that an execution of an upcoming transaction corresponding to the plurality of historical transactions is not scheduled (block 650). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may determine, based on determining that the historical transaction is not designated for automatic execution, that an execution of an upcoming transaction corresponding to the plurality of historical transactions is not scheduled, as described above. [0149] As further shown in FIG. 6, process 600 may include causing an account transaction associated with the upcoming transaction to be automatically executed before a transaction period expiration, that is associated with the merchant account, passes (block 660). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may cause an account transaction associated with the upcoming transaction to be automatically executed before a transaction period expiration, that is associated with the merchant account, passes, as described above." "[0155] In a fifth implementation, alone or in combination with one or more of the first through fourth implementations, causing the account transaction to be automatically executed comprises at least one of: scheduling an execution of a transaction corresponding to the upcoming transaction, designating a transaction corresponding to the upcoming transaction for automatic execution, or executing, via a transaction back end system, a transaction with the merchant account that corresponds to the upcoming transaction.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ratnakaram and Walters, because it allows for an improved system to cause an account transaction associated with the upcoming transaction to be automatically executed. (Walters at Abstract and paras. 1-4).
Ratnakaram and Walters do not explicitly teach, however, King does teach:
a profiling agent implemented as executable instructions executed by the processor, the profiling agent configured to generate and update user payment profiles that include
(King US20240346579 at paras. 48-50, 59-63) ("[0049] Memory 310 may include a model database 343 that stores one or more machine learning models used by all or a subset of logics 331-337, as described in greater detail herein. Memory 310 may further be configured, in some embodiments, to include a user profile database 341 that stores account information related to one or more consumer accounts with a financial entity (e.g., a consumer banking service 180) that owns or manages system 150, or accounts with other financial entities linked to such consumer accounts. In some embodiments, user profile database 341 may include one or more tables, each entry corresponding to a unique set of account information. In some embodiments, user profile database 341 may include information about a user and/or a related account, such as a unique account ID, an associated consumer ID, a current account balance, and information regarding pending deposit/withdraw activity, if existent, user name, contact information (e.g., email address, mailing address, telephone number, etc.), date of birth, payment card information (e.g., payment card number, expiration date, cardholder name, security code) for each of any number of associated payment cards, customer account settings and/or preferences, and the like. User profile database 341 may, in some embodiments, store information detailing every transaction made or requested in connection with the user's account(s), including any of approved transactions, rejected transactions, withdrawn transactions, pending transactions, contested transactions, refunded transactions, and the like, along with account balances resulting from such transactions.")
a recommendation agent implemented as executable instructions executed by the processor, the recommendation agent configured to dynamically enhance the user payment profiles for
(King US20240346579 at paras. 49, 53-56) ("[0049] Memory 310 may include a model database 343 that stores one or more machine learning models used by all or a subset of logics 331-337, as described in greater detail herein. Memory 310 may further be configured, in some embodiments, to include a user profile database 341 that stores account information related to one or more consumer accounts with a financial entity (e.g., a consumer banking service 180) that owns or manages system 150, or accounts with other financial entities linked to such consumer accounts. In some embodiments, user profile database 341 may include one or more tables, each entry corresponding to a unique set of account information. In some embodiments, user profile database 341 may include information about a user and/or a related account, such as a unique account ID, an associated consumer ID, a current account balance, and information regarding pending deposit/withdraw activity, if existent, user name, contact information (e.g., email address, mailing address, telephone number, etc.), date of birth, payment card information (e.g., payment card number, expiration date, cardholder name, security code) for each of any number of associated payment cards, customer account settings and/or preferences, and the like. User profile database 341 may, in some embodiments, store information detailing every transaction made or requested in connection with the user's account(s), including any of approved transactions, rejected transactions, withdrawn transactions, pending transactions, contested transactions, refunded transactions, and the like, along with account balances resulting from such transactions." "[0054] The data stored in user profile database 341 and external databases 170 is used by logics 331-337 to provide a recommendation for user activity that may work to meet or approach the user specified goals entered by the user 110, the goals have been received by credit builder service application 211 and transmitted to credit builder system 150. [0055] FIG. 4 illustrates an exemplary process 400 by which credit builder system 150 may provide activity recommendations to users based on feedback from machine learning models. In step 402, user input module 331 receives a transmission from credit builder service application 211. This transmission contains data collected from user 110 via a user interface displayed on client device 112, the data including various user input related to the user's financial condition. Among the data is transmitted is a user-input financial goal. In some embodiments, the user-input data may also contain information regarding account enrollment, income, spending, debt, opt-in and opt-out settings to various forms of user monitoring, and the like. User input module 331 is configured to store, in user profile database 341, a profile associating the input information with one or more identifiers sufficient to uniquely identify a user, for example a user ID or client device ID based on access credentials used to set up credit builder service application 211 during an enrollment process.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ratnakaram, Walters, and King, because it allows for an improved banking system may additionally, through monitoring and use of machine learning models, provide continually updated recommendations based on user activity. (King at Abstract and paras. 1-3, 86).
Ratnakaram, Walters, and King do not explicitly teach, however, Vasylyev does teach:
wherein the system interacts with external vendor payment application processing interfaces (APIs) to execute payment transactions under control of the controller.
(Vasylyev US20240412720 at paras. 37-40, 51-58, 419) ("[0051] According to an aspect, the Assistant is designed to seamlessly integrate with a wide range of third-party services and APIs, enabling it to extend its capabilities and provide a more comprehensive and efficient user experience. This integration allows the Assistant to access and leverage external data sources, functionalities, and services to better understand and fulfill user requests, without requiring the user to manually navigate across multiple platforms or applications. The integration with third-party services and APIs may be achieved through a modular and extensible architecture that allows for the easy addition, removal, or modification of external integrations without disrupting the core functionality of the Assistant. The Assistant may employ a set of standardized protocols, such as REST (Representational State Transfer), SOAP (Simple Object Access Protocol), or GraphQL, to communicate with external services over a network, typically using HTTP (Hypertext Transfer Protocol) or HTTPS (HTTP Secure) as the underlying communication protocol." "[0053] For example, if a user asks the Assistant to book a ride to the airport, the Assistant can integrate with a ride-sharing service's API, such as Uber or Lyft, to handle the request. The Assistant would first authenticate with the ride-sharing service using the user's stored credentials or an API key associated with the user's account. Then, it would extract the relevant information from the user's request, such as the pickup location, destination, and desired time of arrival, and construct the appropriate API request to initiate the booking process. This may involve making multiple API calls to retrieve available ride options, estimate fares and arrival times, and confirm the final booking details." "[0058] Other examples of potentially useful integrations include but are not limited to calendar and scheduling services (e.g., Google Calendar, Microsoft Outlook) for managing appointments, meetings, and events; task and project management tools (e.g., Asana, Trello) for organizing and tracking work items and collaborations; online shopping and e-commerce platforms (e.g., Amazon, eBay) for product search, comparison, and purchase; social media networks (e.g., Facebook/Meta, Twitter/X, Instagram, LinkedIn, Reddit, Pinterest) for content sharing, engagement tracking, and sentiment analysis; news and media outlets (e.g., CNN, BBC) for personalized news curation and updates; weather and environmental data providers (e.g., NOAA) for real-time weather forecasts and alerts; financial and banking services (e.g., PayPal, Stripe) for secure payment processing and transaction management; and health and fitness platforms (e.g., Fitbit) for tracking and analyzing wellness data and providing personalized recommendations." "[0419] Assistant system 2 guides the user through the menu using a combination of voice prompts and visual displays. It asks the user to specify the desired dishes, quantities, and any customizations or special instructions. As the user makes selections, assistant system 2 dynamically updates the order summary, including the subtotal, taxes, and delivery fees, by making API calls to FoodOrderingHub's order calculation endpoint (e.g., https://api.foodorderinghub.com/orders/calculate). Once the user confirms the order, CarAssist proceeds to place the order by sending a POST request to FoodOrderingHub's order placement endpoint (e.g., https://api.foodorderinghub.com/orders). The request payload includes the user's authentication token, selected restaurant ID, order items, delivery address, and payment method. FoodOrderingHub's API processes the payment using the user's selected payment method (e.g., saved credit card or mobile wallet) and returns an order confirmation response, including an order ID and estimated delivery time.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ratnakaram, Walters, King, and Vasylyev, because it allows for an improved AI assistant system that can record, store, and process conversations in real-time and provide contextual understanding for reduced latency and improved accuracy and an improved system adaptable to various scenarios, such as in-vehicle, in-person, online, or mobile communications, and to enhance the interaction between multiple conversing parties. (Vasylyev at Abstract and paras. 1-10).
As per claim 18,
Ratnakaram and Walters do not explicitly teach, however, King does teach:
wherein the profiling agent
(King US20240346579 at paras. 48-50, 59-63) ("[0049] Memory 310 may include a model database 343 that stores one or more machine learning models used by all or a subset of logics 331-337, as described in greater detail herein. Memory 310 may further be configured, in some embodiments, to include a user profile database 341 that stores account information related to one or more consumer accounts with a financial entity (e.g., a consumer banking service 180) that owns or manages system 150, or accounts with other financial entities linked to such consumer accounts. In some embodiments, user profile database 341 may include one or more tables, each entry corresponding to a unique set of account information. In some embodiments, user profile database 341 may include information about a user and/or a related account, such as a unique account ID, an associated consumer ID, a current account balance, and information regarding pending deposit/withdraw activity, if existent, user name, contact information (e.g., email address, mailing address, telephone number, etc.), date of birth, payment card information (e.g., payment card number, expiration date, cardholder name, security code) for each of any number of associated payment cards, customer account settings and/or preferences, and the like. User profile database 341 may, in some embodiments, store information detailing every transaction made or requested in connection with the user's account(s), including any of approved transactions, rejected transactions, withdrawn transactions, pending transactions, contested transactions, refunded transactions, and the like, along with account balances resulting from such transactions.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ratnakaram, Walters, and King, because it allows for an improved banking system may additionally, through monitoring and use of machine learning models, provide continually updated recommendations based on user activity. (King at Abstract and paras. 1-3, 86).
Ratnakaram, Walters, and King do not explicitly teach, however, Vasylyev does teach:
includes large language models (LLMs) pre-trained on structured and unstructured datasets.
(Vasylyev US20240412720 at paras. 32-34, 145-157) ("[0033] Various embodiments of the invention are directed to an Artificial Intelligence (AI) Assistant, which may also be hereinafter referred to as “AI Assistant” or simply “Assistant”, comprise both hardware and software components working synergistically to provide a personalized, contextual conversation experience. The Assistant may be equipped with the ability to perform complex tasks like voice recognition, tokenization, encoding, decoding, and detokenization using various Natural Language Processing (NLP) models. Useful examples of such NLPs include but are not limited to advanced Transformer-Based Models (TBMs), Large Language Models (LLMs), and/or other known forms or combinations of generative AI technology. The LLMs may be trained on a large corpus of text and utilize a neural network with a transformer-based architecture, such as a Generative Pretrained Transformer (GPT) style model that uses self-attention mechanisms. The attention mechanism can be used to weigh the relevance of different words in an input when generating an output, such as predicting the next word in a sentence. The model can be trained on a large amount of text data using an unsupervised learning process during which the model learns to generate human-like text by predicting the next word in a sentence. The model may be configured as an autoregressive model which generates sentences word by word from left to right utilizing the context of the previously generated words to predict the next one. The model may also be fine-tuned on a more specific dataset and may further include humans' review and supervision following various guidelines such as safety, ethics, policy adherence, usefulness, and quality control, to further enhance the model's capacity to generate appropriate, relevant, and contextually sensitive responses." "[0146] For example, when given a prompt or a question, step 868 may include an information retrieval system to search for relevant documents or passages from the external knowledge source. This retrieval process may be configured to find the most pertinent information that can help in generating a contextually appropriate response. In this step, the AI Assistant may first analyze the command and the stored conversation context to identify key information needs. Based on this analysis, the AI Assistant may formulate a search query to retrieve relevant information from an external knowledge base. Useful examples of the knowledge base include but are not limited to structured databases, web resources, and document collections curated for the specific domain or application, and any combination of those. ")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ratnakaram, Walters, King, and Vasylyev, because it allows for an improved AI assistant system that can record, store, and process conversations in real-time and provide contextual understanding for reduced latency and improved accuracy and an improved system adaptable to various scenarios, such as in-vehicle, in-person, online, or mobile communications, and to enhance the interaction between multiple conversing parties. (Vasylyev at Abstract and paras. 1-10).
Claims 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ratnakaram, U.S. Patent Application Publication Number 2023/0214841; in view of Walters, U.S. Patent Application Publication Number 2021/0357923; in view of Vasylyev, U.S. Patent Application Publication Number 2024/0412720.
As per claim 19,
Ratnakaram explicitly teaches:
A non-transitory computer-readable medium having instructions stored thereon on, the instructions, when executed, cause a processor to perform a method comprising: receiving, via a gateway manager, requests from a user to make current payments to a plurality of vendor payment platforms in accordance with the behavior of the user, the gateway manager being implemented as executable instructions stored in the memory and executed by the processor, the gateway manager being configured to [securely] receive payment requests and transaction context data from a user via the communication interface,;
(Ratnakaram US20230214841 at paras. 6-7, 25-35, 104-105, 132-134, 140) ("[0007] The system may receive a request for payment and event details, including an amount of the event, location of the event, and the like. The amount may be compared to the pre-authorized amount and, if more than the pre-authorized amount, a request for payment authorization may be transmitted to a user device. If the amount is not more than the pre-authorized amount, expected location data of the user may be received and current location data of the user may be requested from a user device. The current location data may be compared to the expected location data and event details and, if the locations match, the payment may be authorized and automatically processed." "[0026] Payment and recommendation control computing platform 110 may be configured to provide intelligent, dynamic, seamless payment processing and option recommendations based on contextual data for a user. For instance, payment and recommendation control computing platform 110 may receive data, such as contextual data, from one or more user devices, such as a smart phone, smart watch, fitness tracker, tablet computing device, or the like, and analyze the data using one or more machine learning models trained on historical data related to contextual data and user preferences. In some examples, the contextual data may include calendar data of the user, data captured from social media platforms, data from user reviews of entities, spending history and habits of the user, food preferences, feed data from IoT devices, and the like. The data may be analyzed to determine one or more recommendations to provide to the user. In some examples, the one or more recommendations may be automatically implemented (e.g., without additional user interaction or input). For example, analyzing the contextual data may identify a restaurant for a user to dine at and the system may automatically connect to the restaurant computing system and reserve a table for the user (e.g., without user interaction). One or more notifications may then be transmitted to the user." "[0031] External entity computing system 140 and/or external entity computing system 145 may be or include one or more computing devices and/or systems that may be associated with one or more entities external to or not associated with the enterprise organization. For instance, external entity computing system 140 and/or external entity computing system 145 may be associated with one or more vendors, restaurants, service providers, or the like. External entity computing system 140 and/or external entity computing system 145 may be configured to communicate with payment and recommendation control computing platform 110 to facilitate scheduling of events, payment for goods or services, and the like. In some examples, external entity computing system 140 and/or external entity computing system 145 may be or include a point-of-sale system at a vendor, restaurant, service provider, or the like." "[0035] Referring to FIG. 1B, payment and recommendation control computing platform 110 may include one or more processors 111, memory 112, and communication interface 113. A data bus may interconnect processor(s) 111, memory 112, and communication interface 113. Communication interface 113 may be a network interface configured to support communication payment and recommendation control computing platform 110 and one or more networks (e.g., private network 190, public network, or the like). Memory 112 may include one or more program modules having instructions that when executed by processor(s) 111 cause payment and recommendation control computing platform 110 to perform one or more functions described herein and/or one or more databases that may store and/or otherwise maintain information which may be used by such program modules and/or processor(s) 111." "[0105] At step 304, event data and a request for payment may be received by payment and recommendation control computing platform 110. For instance, event data and a request for payment may be received from an external entity computing system 140 associated with an entity hosting the event (e.g., the restaurant at which the user is dining, a vendor or service provider working with the user, and the like). In some examples, the event data may include a check or bill for payment due. In some arrangements, the event data may include an image or image data of the check or bill. The event data may further include a location of the event, a date of the event, a time of the event, and the like." "[0132] Payment and recommendation control computing device 701 may include a variety of computer readable media. Computer readable media may be any available media that may be accessed by payment and recommendation control computing device 701, may be non-transitory, and may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, object code, data structures, program modules, or other data." "[0134] Software may be stored within memory 715 and/or storage to provide instructions to processor 703 for enabling payment and recommendation control computing device 701 to perform various functions as discussed herein.")
using Al, via an allocation engine, implemented as executable instructions stored in memory and executed by the processor, to dynamically evaluate the received requests, analyze the user's behavior, and recognize patterns responsive to the evaluation and analysis, and wherein the allocation engine evaluates transaction requirements, available funds, authentication requirements, and stored transaction execution patterns associated with the plurality of vendor payment platforms to automatically select and execute a payment transaction path for the future payment transaction; and
(Ratnakaram US20230214841 at paras. 6-7, 25-37, 95-98, 104-105) ("[0027] Payment and recommendation computing platform may host, train, execute, update and/or validate the one or more machine learning models. For instance, training or historical data may be received and used to train the machine learning model. The training or historical data may identify sequences or patterns associated with scheduled events, amounts paid, types of events, recommendations, and the like, and train the machine learning model to predict recommendations, identify pre-authorization amounts, identify or select a payment mode, and the like." "[0035] Referring to FIG. 1B, payment and recommendation control computing platform 110 may include one or more processors 111, memory 112, and communication interface 113. A data bus may interconnect processor(s) 111, memory 112, and communication interface 113. Communication interface 113 may be a network interface configured to support communication payment and recommendation control computing platform 110 and one or more networks (e.g., private network 190, public network, or the like). Memory 112 may include one or more program modules having instructions that when executed by processor(s) 111 cause payment and recommendation control computing platform 110 to perform one or more functions described herein and/or one or more databases that may store and/or otherwise maintain information which may be used by such program modules and/or processor(s) 111." "[0036] For example, memory 112 may have, store and/or include historical/training data module 112a. Historical/training data module 112a may store instructions and/or data that may cause or enable the payment and recommendation control computing platform 110 to receive historical and or training data, including contextual data, related to one or more users, user purchases, user schedules, user orders, and the like and use that data to train one or more machine learning models stored in machine learning engine 112b. The historical and/or training data may include, for instance, a previous restaurant experience of a user, what was ordered, a cost and a tip provided. Information of this nature may be received from a plurality of sources, such as internal entity computing system 125 which may, e.g., process one or more account payments for a user, user devices such as remote user computing device 170, remote user computing device 175, and the like. The data may be gathered from a plurality of users and used to build and train one or more machine learning models stored and/or executed by machine learning engine 112b to identify one or more recommendations for a user, determine a pre-authorized amount and whether to automatically process a payment, and the like." "[0041] Payment and recommendation control computing platform 110 may further have, store and/or include a database 112f. Database 112f may store historical data associated with one or more users, user response data (e.g., user input received in response to a request for user input, and the like), and the like." "[0095] Upon confirming that the location response data matches an expected location and the event location data, the payment may be processed at step 255. For instance, without user input or interaction, based on the payment being authorized by comparing location response data to expected location data and event location data, payment of the check or bill may be processed. In some examples, processing the payment may include selecting a payment device associated with the user from a plurality of payment modes or devices (e.g., different credit cards, debit card, or the like). In some examples, a user may pre-select a payment device. In some arrangements, the user may select different payment devices for different types of payments, different amounts, and the like. Additionally or alternatively, payment and recommendation control computing platform 110 may automatically select a payment device (e.g., based on historical data, amount, account closing date, account balance, or the like). Automatic selection of a payment device or mode may be based on contextual data, event data, and the like.")
automatically selecting an optimal one of the plurality vendor payment platforms for [future] payments by the user in accordance with the evaluation, the analysis, and the recognized patterns.
(Ratnakaram US20230214841 at paras. 26-27, 31, 39, 42, 95-98) ("[0026] The data may be analyzed to determine one or more recommendations to provide to the user. In some examples, the one or more recommendations may be automatically implemented (e.g., without additional user interaction or input)." "[0031] External entity computing system 140 and/or external entity computing system 145 may be or include one or more computing devices and/or systems that may be associated with one or more entities external to or not associated with the enterprise organization. For instance, external entity computing system 140 and/or external entity computing system 145 may be associated with one or more vendors, restaurants, service providers, or the like. External entity computing system 140 and/or external entity computing system 145 may be configured to communicate with payment and recommendation control computing platform 110 to facilitate scheduling of events, payment for goods or services, and the like. In some examples, external entity computing system 140 and/or external entity computing system 145 may be or include a point-of-sale system at a vendor, restaurant, service provider, or the like." "[0039] Payment and recommendation control computing platform 110 may further have, store and/or include output selection module 112d. Output selection module 112d may store instructions and/or data that may cause or enable payment and recommendation control computing platform 110 to select, based on one or more outputs generated by the one or more machine learning models and analysis of contextual data, an output for processing. For instance, the one or more machine learning models may generate more than one output with a recommended vendor, restaurant, service provider, or the like. In some examples, output selection module 112d may select one output from the more than one output generated and may generate instructions to process that output (e.g., automatically process a payment, automatically book a reservation for a user, or the like)." "[0042] FIGS. 2A-2K depict one example illustrative event sequence for executing payment and recommendation control functions in accordance with one or more aspects described herein. The events shown in the illustrative event sequence are merely one example sequence and additional events may be added, or events may be omitted, without departing from the invention. Further, one or more processes discussed with respect to FIGS. 2A-2K may be performed in real-time or near real-time." "[0095] Upon confirming that the location response data matches an expected location and the event location data, the payment may be processed at step 255. For instance, without user input or interaction, based on the payment being authorized by comparing location response data to expected location data and event location data, payment of the check or bill may be processed. In some examples, processing the payment may include selecting a payment device associated with the user from a plurality of payment modes or devices (e.g., different credit cards, debit card, or the like). In some examples, a user may pre-select a payment device. In some arrangements, the user may select different payment devices for different types of payments, different amounts, and the like. Additionally or alternatively, payment and recommendation control computing platform 110 may automatically select a payment device (e.g., based on historical data, amount, account closing date, account balance, or the like). Automatic selection of a payment device or mode may be based on contextual data, event data, and the like. [0096] At step 256, one or more payment instructions may be generated. For instance, instructions to process a payment, transfer funds from one account to another account or entity, update an account ledger, and the like, may be generated. [0097] At step 257, the generated one or more payment instructions may be transmitted to external entity computing system 140. For instance, an instruction to process payment for the bill, an account or payment device to process the payment, an amount of payment, and the like, may be transmitted to the external entity computing system 140. [0098] At step 258, the external entity computing system 140 may receive the one or more payment instructions and may execute the instructions. In some examples, executing the instructions may include transmitting and/or receiving data with a financial institution (e.g., associated with the payment device or account of the user) to update account information, record the transaction in a ledger, and the like.")
Ratnakaram does not explicitly teach, however, Walters does teach:
future payments…
(Walters US20210357923 at paras. 146-155) ("[0146] As further shown in FIG. 6, process 600 may include identifying a transaction pattern associated with a merchant account, wherein the transaction pattern is identified based on a plurality of historical transactions identified in the transaction log being associated with the merchant account (block 630). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may identify a transaction pattern associated with a merchant account, as described above. In some implementations, the transaction pattern is identified based on a plurality of historical transactions identified in the transaction log being associated with the merchant account. [0147] As further shown in FIG. 6, process 600 may include determining, based on the transaction pattern, that a historical transaction of the plurality of historical transactions is not designated for automatic execution (block 640). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may determine, based on the transaction pattern, that a historical transaction of the plurality of historical transactions is not designated for automatic execution, as described above. [0148] As further shown in FIG. 6, process 600 may include determining, based on determining that the historical transaction is not designated for automatic execution, that an execution of an upcoming transaction corresponding to the plurality of historical transactions is not scheduled (block 650). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may determine, based on determining that the historical transaction is not designated for automatic execution, that an execution of an upcoming transaction corresponding to the plurality of historical transactions is not scheduled, as described above. [0149] As further shown in FIG. 6, process 600 may include causing an account transaction associated with the upcoming transaction to be automatically executed before a transaction period expiration, that is associated with the merchant account, passes (block 660). For example, the device (e.g., using processor 520, memory 530, storage component 540, input component 550, output component 560, communication interface 570, and/or the like) may cause an account transaction associated with the upcoming transaction to be automatically executed before a transaction period expiration, that is associated with the merchant account, passes, as described above." "[0155] In a fifth implementation, alone or in combination with one or more of the first through fourth implementations, causing the account transaction to be automatically executed comprises at least one of: scheduling an execution of a transaction corresponding to the upcoming transaction, designating a transaction corresponding to the upcoming transaction for automatic execution, or executing, via a transaction back end system, a transaction with the merchant account that corresponds to the upcoming transaction.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ratnakaram and Walters, because it allows for an improved system to cause an account transaction associated with the upcoming transaction to be automatically executed. (Walters at Abstract and paras. 1-4).
Ratnakaram and Walters do not explicitly teach, however, Vasylyev does teach:
securely receive payment requests…
(Vasylyev US20240412720 at paras. 37-40, 53-58) ("[0039] Furthermore, the Assistant is equipped to recognize one or more voices, which can be designated as control voices. It monitors the conversation for a control signal which could be a key phrase pronounced by the control voice, a button press, a gesture, non-verbal cues, or other recognizable commands. The control signals could be single or multi-factor and may include biometric security measures. The control signal triggers the Assistant to record a subsequent voice command from the user. According to one embodiment, the Assistant provides the user with the ability to set or change the control signals that trigger the Assistant." "[0054] Throughout this process, the Assistant can engage in a natural back-and-forth conversation with the user to gather any missing information, provide updates on the booking status, and handle any changes or cancellations as needed. The Assistant can also build, as part of the conversation with the user, and use its knowledge of the user's preferences and past behavior to make intelligent decisions on their behalf, such as selecting their preferred ride type or payment method, without requiring explicit input at every step." "[0058] Other examples of potentially useful integrations include but are not limited to calendar and scheduling services (e.g., Google Calendar, Microsoft Outlook) for managing appointments, meetings, and events; task and project management tools (e.g., Asana, Trello) for organizing and tracking work items and collaborations; online shopping and e-commerce platforms (e.g., Amazon, eBay) for product search, comparison, and purchase; social media networks (e.g., Facebook/Meta, Twitter/X, Instagram, LinkedIn, Reddit, Pinterest) for content sharing, engagement tracking, and sentiment analysis; news and media outlets (e.g., CNN, BBC) for personalized news curation and updates; weather and environmental data providers (e.g., NOAA) for real-time weather forecasts and alerts; financial and banking services (e.g., PayPal, Stripe) for secure payment processing and transaction management; and health and fitness platforms (e.g., Fitbit) for tracking and analyzing wellness data and providing personalized recommendations.")
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Ratnakaram, Walters, and Vasylyev, because it allows for an improved AI assistant system that can record, store, and process conversations in real-time and provide contextual understanding for reduced latency and improved accuracy and an improved system adaptable to various scenarios, such as in-vehicle, in-person, online, or mobile communications, and to enhance the interaction between multiple conversing parties. (Vasylyev at Abstract and paras. 1-10).
As per claim 20,
Ratnakaram explicitly teaches:
wherein the behavior relates to at least one of selecting payment methods and selecting authentication methods.
(Ratnakaram US20230214841 at paras. 7, 27, 31, 94-100) ("[0007] The system may receive a request for payment and event details, including an amount of the event, location of the event, and the like. The amount may be compared to the pre-authorized amount and, if more than the pre-authorized amount, a request for payment authorization may be transmitted to a user device. If the amount is not more than the pre-authorized amount, expected location data of the user may be received and current location data of the user may be requested from a user device. The current location data may be compared to the expected location data and event details and, if the locations match, the payment may be authorized and automatically processed." "[0095] Upon confirming that the location response data matches an expected location and the event location data, the payment may be processed at step 255. For instance, without user input or interaction, based on the payment being authorized by comparing location response data to expected location data and event location data, payment of the check or bill may be processed. In some examples, processing the payment may include selecting a payment device associated with the user from a plurality of payment modes or devices (e.g., different credit cards, debit card, or the like). In some examples, a user may pre-select a payment device. In some arrangements, the user may select different payment devices for different types of payments, different amounts, and the like. Additionally or alternatively, payment and recommendation control computing platform 110 may automatically select a payment device (e.g., based on historical data, amount, account closing date, account balance, or the like). Automatic selection of a payment device or mode may be based on contextual data, event data, and the like. [0096] At step 256, one or more payment instructions may be generated. For instance, instructions to process a payment, transfer funds from one account to another account or entity, update an account ledger, and the like, may be generated. [0097] At step 257, the generated one or more payment instructions may be transmitted to external entity computing system 140. For instance, an instruction to process payment for the bill, an account or payment device to process the payment, an amount of payment, and the like, may be transmitted to the external entity computing system 140. [0098] At step 258, the external entity computing system 140 may receive the one or more payment instructions and may execute the instructions. In some examples, executing the instructions may include transmitting and/or receiving data with a financial institution (e.g., associated with the payment device or account of the user) to update account information, record the transaction in a ledger, and the like.")
Response to Arguments
Applicant’s arguments filed on June 30, 2026 have been fully considered but are not persuasive for the following reasons:
With respect to Applicant’s arguments as to the § 101 rejections for now pending claims 1-20, Examiner notes the following:
Applicant argues that the claims are not directed to an abstract idea.
Examiner disagrees, however, and notes that the claim as a whole recites a method that, under its broadest reasonable interpretation, covers collecting, analyzing, and transmitting data to facilitate payment transactions. This is a fundamental economic practice of a financial transaction; a commercial interaction, such as for business relations; and managing personal behavior or relationships or interactions between people, which are certain methods of organizing human activity.
Furthermore, the claims cover the use of a computer system to provide for collecting, analyzing, and transmitting data to facilitate payment transactions. As the steps could be performed by a human without a computer, the claim limitations fall within the mental processes grouping, and the claim recites an abstract idea.
Finally, claim 18 also recites the use of large language models (LLMs) pre-trained on structured and unstructured datasets to facilitate payment transactions. This is a mathematical calculation.
In the alternative, the large language models (LLMs) pre-trained on structured and unstructured datasets is considered a technology that is recited at a high level of generality and merely applied as a tool to implement the abstract idea.
Thus, the claims recite an abstract idea.
Regarding the applicant's argument that the amended features would integrate the abstract idea into a practical application, the examiner respectfully disagrees.
Examiner that the additional elements of the computer system - “a gateway manager, implemented as executable instructions stored in memory and executed by a processor”, “artificial intelligence (AI), via an allocation engine, implemented as executable instructions stored in memory and executed by the processor”, “a profiling system agent, implemented as executable instructions stored in memory and executed by a processor”, “a plurality of vendor payment platforms”, “A banking system for initiating future payments from a user to a vendor, comprising: a controller including at least one processor, memory, and a communication interface; a gateway manager implemented as executable instructions stored in the memory and executed by the processor”, “a plurality of payment-network interfaces”, “A system for profiling payment transactions between a user and selected service provider platforms, the system comprising: a controller including at least one processor and memory; an analytics agent implemented as executable instructions executed by the processor”, “a recommendation agent implemented as executable instructions executed by the processor”, “the system interacts with external vendor payment application processing interfaces (APIs)”, and “A non-transitory computer-readable medium having instructions stored thereon on, the instructions, when executed, cause a processor to perform a method comprising: receiving, via a gateway manager”, to perform the steps of “requesting”, “evaluating”, “analyzing”, “correlating”, “recognizing”, “selecting”, “executing”, “profiling”, and “deriving”, in all steps is recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component. The claims at issue covers collecting, analyzing, and transmitting data to facilitate payment transactions. The claims invoke the “a gateway manager, implemented as executable instructions stored in memory and executed by a processor”, “artificial intelligence (AI), via an allocation engine, implemented as executable instructions stored in memory and executed by the processor”, “a profiling system agent, implemented as executable instructions stored in memory and executed by a processor”, “a plurality of vendor payment platforms”, “A banking system for initiating future payments from a user to a vendor, comprising: a controller including at least one processor, memory, and a communication interface; a gateway manager implemented as executable instructions stored in the memory and executed by the processor”, “a plurality of payment-network interfaces”, “A system for profiling payment transactions between a user and selected service provider platforms, the system comprising: a controller including at least one processor and memory; an analytics agent implemented as executable instructions executed by the processor”, “a recommendation agent implemented as executable instructions executed by the processor”, “the system interacts with external vendor payment application processing interfaces (APIs)”, and “A non-transitory computer-readable medium having instructions stored thereon on, the instructions, when executed, cause a processor to perform a method comprising: receiving, via a gateway manager”, to perform the steps of “requesting”, “evaluating”, “analyzing”, “correlating”, “recognizing”, “selecting”, “executing”, “profiling”, and “deriving” merely as tools to execute the abstract idea. Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a certain method of organizing human activity or mental process or mathematical calculation) does not integrate a judicial exception into a practical application. (MPEP 2106.05 (f))
Finally, the Applicant argues that the claims are directed to significantly more than the abstract idea.
Examiner disagrees, however, and notes that, as explained above in the instant rejection under 35 U.S.C. § 101, that the additional elements do not amount to an inventive concept. The additional elements of the computer system - “a gateway manager, implemented as executable instructions stored in memory and executed by a processor”, “artificial intelligence (AI), via an allocation engine, implemented as executable instructions stored in memory and executed by the processor”, “a profiling system agent, implemented as executable instructions stored in memory and executed by a processor”, “a plurality of vendor payment platforms”, “A banking system for initiating future payments from a user to a vendor, comprising: a controller including at least one processor, memory, and a communication interface; a gateway manager implemented as executable instructions stored in the memory and executed by the processor”, “a plurality of payment-network interfaces”, “A system for profiling payment transactions between a user and selected service provider platforms, the system comprising: a controller including at least one processor and memory; an analytics agent implemented as executable instructions executed by the processor”, “a recommendation agent implemented as executable instructions executed by the processor”, “the system interacts with external vendor payment application processing interfaces (APIs)”, and “A non-transitory computer-readable medium having instructions stored thereon on, the instructions, when executed, cause a processor to perform a method comprising: receiving, via a gateway manager”, to perform the steps of “requesting”, “evaluating”, “analyzing”, “correlating”, “recognizing”, “selecting”, “executing”, “profiling”, and “deriving” are merely generic computer components performing their well-known basic functions of collecting, analyzing, and transmitting data to facilitate payment transactions. Per the specification, the recited computer elements and large language models are described only at a high level of generality, (see Spec. at paras. [0069]-[0080]). In view of the specification, the application of the computer elements and large language models is merely being applied to the abstract idea.
The other limitations which are simply supporting the abstract idea correspond to insignificant extra-solution activity which do not transform the abstract idea into a patent eligible subject matter. Also, the functionality here is already present in the recited hardware, which is merely routine and conventional. Collecting, analyzing, and transmitting data is routine and conventional. There is no technological problem or solution identified. This is merely a business solution to transfer data between devices. (MPEP 2106.05 (f))
With respect to Applicant’s arguments as to the §§ 112 and 102 rejections for now pending claims 1-20, Examiner notes that the rejections are withdrawn.
With respect to Applicant’s arguments as to the § 103 rejections for now pending claims 1-20, Examiner notes that the arguments are moot in light of the new grounds for rejection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is available for review on Form PTO-892 Notice of References Cited.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MERRITT J HASBROUCK whose telephone number is (571)272-3109. The examiner can normally be reached M-F 9:00-5:00.
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, Christine Tran can be reached on 571-272-8103. 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.
/MERRITT J HASBROUCK/Examiner, Art Unit 3695
/CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695
Prosecution Insights