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 .
The following is a Final Office Action in response to communications received October 01, 2025. No Claims have been cancelled. Claims 1-9, 13 and 15 have been amended. No new claims have been added. Therefore, claims 1-20 are pending and addressed below.
Priority
Application No. 18/316179 filing date: 05/11/2023
Applicant Name/Assignee: Block, Inc
Inventors: Vu Thuy, Esquivel, Rhoda, Nguyen, Bang
Claim Interpretation
The amended limitations recite the language “a first user interface in a sequence of user interfaces that includes a prompt for input of context information associated with the payee”, “receiving, via the first user interface in the sequence, the context information associated with the payee”,” a second user interface in the sequence of user interfaces that includes one or more prompts for input of additional information identifying an interaction between the payor and the payee”, “a third user interface in the sequence of user interface” and “causing funds to be withdrawn from a stored balance associated with the account of the payor and transferred to the account of the payee via the third user interface in the sequence without leaving the payment application”. The specification discloses the interfaces of the transaction as “unified user interface or sequence of user interfaces may serve as an initiating point for …different types of payment transactions…of payment service applications that facilitates both peer-to-peer payments and payments to external service providers and computing platform” (para 0020, para 0021). The common meaning of “unified user interface” is a standardized design that ensures consistent and streamlined accessibility across various devices and applications. The examiner is interpreting the “sequence of user interfaces” interchangeable with the term “unified interfaces”, where interfaces in a workflow process for performing a transaction are integrated in the process.
Response to Amendment/Argument
Claim Rejections - 35 USC § 101
Applicant's arguments filed 10/01/2025 have been fully considered but they are not persuasive.
In the remarks applicant pointing to MPEP 2106.04 (II)(A)(1), MPEP 2106.04(a), MPEP 2106.04 (d), MPEP 2106.04 (d)(4) and MPEP 2106 (d)(III), reciting the guidance for analysis of evaluation for abstract subject matter, arguing that the claim limitations are not directed toward abstract subject matter. Specifically, applicant argues that the amended claim 1 provide evidence of practical integration limitations (1) causing a payment application of a payment service executing on a payor device to enable payor to initiate a payment to any type of payee (2) utilizing a model trained to predict type of payee and based on identifier received via the payment application, that the payee does not have an account with the payment service (payee is external payee), (3) based on the payee being an external payee, enabling payment service to connect with an external service to confirm that the payee does in fact have an account with the external service (4) based on the payee being an external payee, the backend selects a first user interface in a sequence of user interfaces from a database of payment transaction flow modules, present it to the payor via payment application such that payor can input data associated with payee (5) based on data, the model can determine a type of payee that is to be paid (6) based on type of payee determined, selects second user interface in the sequence where the payor can input additional data (7) based on additional data, select third interface enables payor to initiate transaction (8) connect with external service to exchange transaction information and negotiate communication protocols to user for the exchange (9) cause funds from internal account of payor to be transferred. The examiner respectfully disagrees that the claim limitations technical elements impose meaningful limits upon the identified abstract idea. Instead the recited additional elements (sequence of user interfaces, computer platforms, various user devices) impose meaningful limits upon the identified abstract transaction process. Instead the additional elements are merely applied as tools to perform the identified transaction process. The focus of the application of the technology is not the technology itself but instead to perform the abstract idea. Accordingly the claimed limitations as a whole or as a combination of parts fail to integrate the judicial exception into a practical applicant as set forth under step 2A prong 2. The rejection is maintained.
In the remarks applicant argues that under step 2A prong 1 pointing to MPEP 2106.04(d) III and the corresponding memo, the claimed limitations as a whole provide additional elements in the claim that provide significantly more that the identified abstract idea (transaction process). Applicant argues that the previous rejection does not establish a preponderance of the evidence to make a proper rejection under the statutory bases (i.e. 101, 102, 103, 112). Applicant argues amended claim 1 recites a “sequence of user interfaces”, that are “selected” based on “payee type” and presenting the sequence of user interfaces to facilitate “funds to be withdrawn from a balance associated with the account of the payor and transferred to account of the payee”, “without leaving payment application”. Applicant argues that such processes cannot reasonably be performed by the human mind. The examiner agrees that the amended limitations are not directed toward the abstract category of mental processes. However, the examiner maintains that under step 2A prong 1, the claim limitations are directed toward the abstract category “methods of organizing human activity”. The examiner maintains that the claim limitations when considered as a whole are directed toward the abstract category of methods of organizing human activity.
In the remarks applicant argues that the claim limitations when considered in part are as a whole are directed toward improvement to technology, pointing to the USPTO memo p. 4. This is because the claimed technical provide technical improvements to payment services and computing platforms and databases. The techniques provide a unified user interface of user interfaces of payment service application facilitating peer-to-peer payments and payment to external service provider and computer platform. The user interfaces appear seamless to payor, wherein backend services are employed to modify payment transaction flow utilized by payor based on identification of payee type. The backend services include calls to internally managed components to determine/predict payee identifier is associated with payment service account/external service and to external components (e.g., API calls to external services to confirm identifier). Applicant argues the unified user interface/sequence of user interfaces and payment transaction flow reduce the number of redundant and/or unnecessary user interfaces the payment service application would otherwise present to the payor. The user interfaces and payment transaction flow may use API’s and other system interaction features to streamline information requested from payor pointing to the specification para 0021. Applicant argument is not persuasive. The applicant does not identify how the claimed limitations improve unified interfaces, API’s, computer platforms, computer payment applications or databases. Furthermore, applicant does not identify how the claimed limitations provide a solution to a problem rooted in interface technology or any other of the computer elements recited in the claims. Instead applicant’s arguments focus on the use of the interfaces, API’s, payment applications, computer platforms in the payment transaction process. According to Alice and USPTO 101 Guidance, limitations which “apply” technology with an abstract idea are no more than mere instructions to implement the abstract idea on a computer requiring no more than generic computer functions do not go beyond generally linking the use of the transaction process to a particular technical environment. The instant application, therefore, still appears only to implement the abstract idea to the particular technological environments apply what generic computer functionality in the related arts. The claim provides no technical details regarding how the operations performed by the “sequence of user interfaces” as a technical process that go beyond high level functions implemented in the transaction process with an expected to result for performing the transaction. Instead, similar to the claims at issue in Intellectual Ventures I LLC v. Capital One Financial Corp., 850 F.3d 1332 (Fed. Cir. 2017), “the claim language . . . provides only a result-oriented solution with insufficient detail for how a computer accomplishes it. The steps are still a combination made to perform a transaction activity and does not provide any of the determined indications of patent eligibility set forth in the 2019 USPTO 101 guidance. The additional steps only add to those abstract ideas using generic functions, and the claims do not show improved ways of, for example, an particular technical function for performing the abstract idea that imposes meaningful limits upon the abstract idea. The rejection is maintained.
In the remarks applicant pointing to MPEP 2106.04 (d), 2106.05(II), argues that under step 2B, the limitations when considered individually, as an ordered combination or as a whole transform the nature of the claim into patent eligible subject matter. This is because the claims add specific limitations that are not well understood or conventional providing significantly more than the alleged abstract idea. Applicant recites the limitations emphasizing the limitations which include applying “one or more servers of payment service and via payment application” being applied to cause a user interface of a user mobile device to initiate a payment; Applying “one or more servers of payment service and payment application in a transaction process to initiate a payment is well known application of technology in transaction processes.
The limitation process which applies a “model trained” to determine/predict which payee types are associated with specific payee is merely applying technology to analyze transaction data which is a well-known application of technology without any details as to how the “model” determine/predicts payee types.
The limitation process which applies an “API” to request confirmation that payee has an account-lacking technical description is performing insignificant extra solution activity of transmitting data – See MPEP 2106.05(d) section II (i);
The limitation process which applies “one or more servers of the payment service and from a database of transaction flow modules” to perform the operations of selecting a second interface at a high level that include prompts lacking technical description. The use of interfaces include prompts is well known function of interface technology.
The limitation process which applies “”one or more servers of payment service and from a database of flow modules” “a first user interface in a sequence of user interfaces” for selecting a prompt for input lacks technical description on the how the selecting process is performed. The selecting limitation is so high level as to include any known technical means using any known programming capable of performing the selecting of interfaces that include prompts - a known application of interface technology.
The limitations process which applies the “first user interface” applied to perform receiving the context information -lacking technical description is performing insignificant extra solution activity of transmitting data – See MPEP 2106.05(d) section II (i);
The limitations process which recites “utilizing the model” applied for determining a payee type-is merely applying technology to analyze transaction data which is a well-known application of technology without any details as to technical details as to how the “model” is utilized to determine payee type.
The limitations process which applies the “one or more servers of payment service and from a database” for selecting a second user interface that includes prompts The selecting limitation is so high level as to include any known technical means using any known programming capable of performing the selecting of interfaces that include prompts.
The limitations process which applies the “one or more servers of the payment service and form the database of transaction flow modules” for selecting a third user interface to enable payment- The selecting limitation is so high level as to include any known technical means using any known programming capable of performing the selecting of interfaces to enable payment which is a well-known application of technology in payment applications.
The limitations process which applies the “one or more API calls” for exchanging data; -lacking technical description is performing insignificant extra solution activity of transmitting data – See MPEP 2106.05(d) section II (i);
The limitations process which applies the “third user interface” to cause funds withdrawn.- the application of the third user interface is so high level as to include any known technical means using any known programming capable of performing the funds withdrawn which is a well-known application of technology in payment applications.
When considered as a combination of parts, the claim limitations recite the combination of the technical functions “enable payor initiate a payment”, “receiving…identifier”, “determining…payee lacks an account associated with payment service”, “confirmation that payee has an account with external service”, “selecting …a first interface that includes a prompt to input…”, “receiving …information”, “determining …payee type…”, “selecting …a second user interface that includes one or more prompts for input additional information…”, “selecting a third user interface …to enable payment service to initiate the payment”, “exchanging transaction data and communication protocol data between …servers of payment service and …servers associated with external service”, “causing funds to be withdrawn” which as a combination are not a combination of a particular technical process but rather a combination to perform the transaction process. According the combination of the functions claimed are conventional lacking a particular technical process. The rejection is maintained.
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 instant application is directed to non-patentable subject matter. Specifically, the claims are directed toward at least one judicial exception without reciting additional elements that amount to significantly more than the judicial exception. The rationale for this determination is in accordance with the guidelines of USPTO, applies to all statutory categories, and is explained in detail below.
In reference to Claims 1-4:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a method, as in independent Claim 1 and the dependent claims. Such methods fall under the statutory category of "process." Therefore, the claims are directed to a statutory eligibility category.
STEP 2A Prong 1. The claimed invention is directed to an abstract idea without significantly more. Method claim 1 recites a method steps (1) causing user interactive interface to be presented to initiate payment (2) receiving data (3) determining payee lacks an account associated with payment service (4) requesting confirmation that payee has an account (5) selecting a first user interface that includes a prompt (6) receiving information (7) determining a payee type associated with payee based on payee information and the prediction of a payee types (8) selecting a second user interface that includes one or more prompts for input of additional information (9) selecting based on additional information identifying interaction a third user interface (7) selecting a payment flow based on payee type to facilitate payment service (8) payment flow selected utilizes second interface specific to payee type (9)presenting user interface by payment application (10) requesting additional information (11) enabling payment service to initialize interface to facilitate payment (12) exchanging transaction data and communication protocol in response to initiating payment (13) causing funds to be withdrawn and transferred. The claimed limitations which under its broadest reasonable interpretation, covers performance of a transaction process. The specification using an application to facilitate user account services to facilitate user management of assets (funds, accounts, payments, balances, etc. -para 0016) and different payment flows (e.g., a payment transaction flow for payments between ordinary users, also known as "peer-to-peer" payments, distinct from a payment transaction flow for payments responsive to invoices or to service providers-para 0017). Claim 1 limitations and in light of the specification focuses on the abstract idea of commercial interactions and sales activities- (facilitate account management using applications and interactive interface for user input and selections). Thus as a whole the limitations covers performance of a sales activity/commercial interaction. These concepts are enumerated in Section I of the 2019 revised patent subject matter eligibility guidance published in the federal register (84 FR 50) on January 7, 2019) is directed toward abstract category of methods of organizing human activity.
STEP 2A Prong 2: The identified judicial exception is not integrated into a practical application because the claims fail to provide indications of patent eligible subject matter that integrate the alleged abstract idea into a practical application. The additional elements recited in the claim beyond the abstract idea include “one or more servers of a payment service”, “a payment application executed on a device of a payor”, a “first user interface”, a “second user interface”, a “third user interface”, a “model trained”, an “API”, and a “database of payment transaction flow modules”.
The claimed “first user interface” applied to perform the operations of “receiving…an identifier”, “receiving …context information”; the claimed “API call” applied to perform the operations “requesting…confirmation”; the claimed “one or more second API calls” to perform the operations of “exchanging transaction data and communication protocol data between the one or more servers of payment service and one or more servers associated with …external service”; the claimed “third user interface” to perform the operations of transfer funds to the account from stored balance” without any details of technical implementation. According to MPEP 2106.05(d) II (see also MPEP 2106.05(g)) the courts have recognized the following computer functions are claimed in a merely generic manner (e.g., at a high level of generality) where technology is merely applied to perform the abstract idea or as insignificant extra-solution activity.
Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014)
Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93
The claimed additional element “one or more servers of a payment service and “payment application executing on a device of a payor” applied at a high level of generality to “cause… a first interface to be presented” for enabling payor to initiate a payment…” which amounts to no more than mere instructions to present an interface for initiating a payment where the “one or more servers” and “payment application on a device” is merely a field of use for payment transactions.
The additional elements “model trained” is utilized to “predict which payee types are associated with specific payee” and “determining…a payee type to associated with the payee” that “lacks an account associated with payment service” which amounts to no more than mere instructions to analyze data for an expected result.
The additional elements “one or more servers of a payment service and from a database of payment transaction flow module is applied to “selecting… a first user interface… that includes a prompt for input…”, “selecting a second user interface …that includes one or more prompts for input of additional information” and “selecting…a third user interface in the sequence of user interfaces to enable payment service to initiate the payment to the external service…” which is merely applying technology at a high level to select an interface to input data for a transaction.
The claim limitations when considered individually fail to provide any indications of patent eligible subject matter, according to MPEP guidance (see MPEP 2106.05 (a)-(c), (e )-(h).
(i) an improvement to the functioning of a computer;
(ii) an improvement to another technology or technical field;
(iii) an application of the abstract idea with, or by use of, a
particular machine;
(iv) a transformation or reduction of a particular article to a
different state or thing; or
(v) other meaningful limitations beyond generally linking the
use of the abstract idea to a particular technological environment.
The claimed model is applied at a high level to determine that the payee lacks an account associated with a payment service lacking technical details and therefore, amounts to no more than mere instructions to analyze transaction related data for determining whether a payee lacks an account associated with a payment service. The additional element “payment application by a payment service” recited to perform the steps “causing interface to be presented” and the additional element “via interface” to perform the steps “receiving data”, “requesting additional information”, “causing funds withdrawn” and “causing funds transferred” and the nominal mention of a model used to predict payee types” are is recited at a high-level of generality such that it amounts to no more mere instructions to apply the exception on a generic computer. The model determining process is not directed toward any processes related to technology and is merely applied as a tool to analyze transaction related data.
The application of the payment service is generally applied without limiting how the application as a technical process causes the interface to be presented. Taking the claim elements separately, the operation performed by the method at each step of the process is purely in terms of results desired and devoid of implementation of details. The steps of the Technology is not integral to the process as the claimed subject matter is so high level that any generic programming could be applied and the functions could be performed by any known means. Furthermore, the claimed functions do not provide an operation that could be considered as sufficient to provide a technological implementation or application of/or improvement to this concept (i.e. integrated into a practical application).
When the claims are taken as a whole, as an ordered combination, the combination of limitations 1-2 are directed toward utilizing a generic payment service via a payment application to present a user interface which is applied to initiate a payment which is not directed toward a particular technological process but rather a transaction process using a payment system and payment application on a user device of a payor. The combination of limitations 3-6 is directed toward utilizing a model for determining that payee lacks an account associated with payment service and requesting “via a first API” call confirmation payee has external service account, selecting by the payment service a first user interface that includes an input prompt for payee data, where “via the user interface” the payee associated information is received which as a combination is directed toward a transaction process and not toward providing a solution to a problem rooted in technology or to improve upon the capability of any of the recited underlying technology applied to perform the transaction in combination with limitations 1-2. The combination of limitations 7-8 is directed toward utilizing a model for determining a payee type to associated with the payee and based on payee type selecting using the payment service a second interface in sequence of user interface which is directed toward a transaction process using servers of a payment system and model in combination of limitations 1-6. The combination of limitations 9-12 are directed toward selecting a third interface used to initiate the payment based on additional identifying information where “via second API” calls exchanging transaction data and communication protocol data between payment service and servers of payment service which causes the funds to be withdrawn of payor account and transferred to payee account via the third user interface without leaving payment application. The combination of limitations 9-12 is directed toward initiating a transaction and the withdrawal and exchange of funds between payor and payee account in combination of limitations 1-8. The combinations of parts is not directed toward any technical process or technological technique or technological solution to a problem rooted in technology in any of the underlying technology.
Therefore, when the claims are taken as a whole, as an ordered combination, the combination of steps not integrate the judicial exception into a practical application as the claim process fails to impose meaningful limits upon the abstract idea. . This is because there is no indication in the claim language that the structure and/or the manner in which any underlying technology is changed in any way. The Specification describes the advantage for an entire set of different user interactions and payment transaction flows may be performed and executed for within a unified payment service application without having to exit the application (para 0017) where a user interface may select/generate a payment transfer transaction flow in accordance with the identified intended payee (para 0019). The claim provides no technical details regarding how the “utilizing model” operation is performed. Instead, similar to the claims at issue in Intellectual Ventures I LLC v. Capital One Financial Corp., 850 F.3d 1332 (Fed. Cir. 2017), “the claim language . . . provides only a result-oriented solution with insufficient detail for how a computer accomplishes it. Our law demands more.” Intellectual Ventures, 850 F.3d at 1342 (citing Elec. Power Grp. LLC v Alstom, S.A., 830 F.3d 1350, 1356 (Fed. Cir. 2016)).
The claimed subject matter fails to provide additional elements or combination or elements to apply or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception. The functions recited in the claims recite the concept of applying a user interface to receive identifiers associated with payee, selecting a payment flow, request additional information and initialize and perform a payment transfer which is a process directed toward a business practice. The integration of elements do not improve upon technology or improve upon computer functionality or capability in how computers carry out one of their basic functions. The integration of elements do not provide a process that allows computers to perform functions that previously could not be performed. The integration of elements do not provide a process which applies a relationship to apply a new way of using an application. The instant application, therefore, still appears only to implement the abstract idea to the particular technological environments apply what generic computer functionality in the related arts. The steps are still a combination made to recite “outcomes” of the payment transfer steps without any details about how the outcomes are accomplished as it relates to a technical process and therefore, does not provide any of the determined indications of patent eligibility set forth in the 2019 USPTO 101 guidance. The additional steps only add to those abstract ideas using generic functions, and the claims do not show improved ways of, for example, an particular technical function for performing the abstract idea that imposes meaningful limits upon the abstract idea. Moreover, Examiner was not able to identify any specific technological processes that goes beyond merely confining the abstract idea in a particular technological environment, which, when considered in the ordered combination with the other steps, could have transformed the nature of the abstract idea previously identified. Accordingly, this additional element does 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 2B; The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above with respect to concepts of the abstract idea into a practical application. The additional elements recited in the claim include “one or more servers of a payment service”, “payment application on a device of payor”, “user interface”, a “model trained”, “API call”, “database of payment transaction flow modules”, first, second and third interface of “sequence of user interfaces”. The sequence of the interfaces are applied to perform the operations of “receiving…identifier”, “includes a prompt for input”, “receiving …information” and “funds…transferred to the account” which according to MPEP 2106.05(d) II (i), have been recognized by the courts as well-understood, routine and conventional functions when claimed in a generic high level manner.
The applied “one or more servers of a payment service” performing the operations at a high level of causing a first user interface to be presented in a payment application is a well understood, routine and conventional use of technology. The additional operation applied by the one or more servers of the payment service includes the high level performance of selecting a first user interface that includes a prompt for input, selecting a second user interface in the sequence based on payee type, and selecting a third user interface in the sequence to enable payment service to initiate a payment which merely applies a field of use for initiating and enabling a transaction. As evidence that user interfaces including input prompts is well known technological process and used in the arts. US Pub No. 2021/0325341 A1 by Galen et al. –[0095]… The preset routines can include prompts for user input received from a user interface 854 or input from another computing device or the processing circuitry can prompt a user for input before, during, or after analysis of a patient sample; US Pub No. 2018/0018065 A1 by Gao et al –[0045]… A graphic computer element is generally the available element in any current or future Graphic User Interface (GUI) computer software design, such as a button, a hyperlink, a frame, a browser window, a scrolling bar, a text editor window, etc. In computer technology, graphic user interface is commonly distinguished from CLI input prompt and interface.; US Pub No. 2015/0221052 A1 by Messing – [0018]… The graphic user interface thus prompts for user input of operative facts that apply to the commonly encountered situation. (background – well known and understood); US Pub No. 2015/0012324 A1 by Lance et al. –[0014]… The initial assessment may be conducted by various means, such as: a question-and-answer session to draw out data on what is currently planned or in progress; a questionnaire; standardized interview decks; an input-interface or prompt on a computerized system; and/or equivalents or combinations thereof; US Pub No. 2008/0178252 A1 by Michaud – [0056]… The functionality required to display prompts and receive user inputs, typically as a GUI, is provided by the user-interface module 824.
The applied “payment application on a device of payor” is used to cause a user interface presented within the payment application to include a prompt for input.
The applied a “model trained” is nominal mention of a model used to determine payee lacks an account associated with payment service and determine payee types to associate with payee without technical details amount to no more than mere instructions to perform the transaction associated payee of a transaction.
The applied “API call” is applied to perform “requesting …confirmation that the payee has an account with the external service” and “one or more second API calls” used in its ordinary capacity at a high level of generality to exchange transaction data and communications protocol data between the payment service and external service which is well understood routine and conventional application of API technology. As evidence the examiner provides US Patent No. 11,153,227 B1 by Chamberlain “The microservices may use a common API for communicating between themselves, which may be reconfigured based on the network traffic travelling between the microservices. By reconfiguring the microservices, communication may be exchanged between communication by way of HyperText Transfer Protocol Secure (HTTPS), HyperText Transfer Protocol (HTTP), inter-process communication, and direct function calls.”-Col 3 lines 31-39; US Pub No. 2019/0199693 A1 by Vityaz - As a result, communication (data exchange in terms of nodal-based object transfer) may be achieved using a standardized and format-agnostic protocol (contrasting the conventional API-exchanged data)-para 0150; US Pub No. 2023/0140096 A1 by Shive –“he programming of the software according to the present invention, using standard API for communication between the vendor and customer computers” -para 0029; US Pub No. 2016/0182433 A1 by McDaid et al- [0067] It should be noted that there is a common API between the requestor/client and the RRS, of which there is one instance of a dedicated RRS (regardless of the servers to which the RRS is providing the connection).
With respect to the limitation “interface in sequence”, the examiner provides evidence that the interface claimed is well known in the art- US Pub No. 2016/0054922 A1 by Awasthi et al- [0047]… the memory interconnect 104 may provide the processor 102 with a unified or common interface or protocol for accessing the plurality of storage mediums…memory interconnect 104 may provide the various storage mediums 116, 126, 136, and 146 with respective interfaces that employ the respective protocols employed by the plurality of storage mediums; US Patent No. 11,546,243 B1 by Menon et al -…wherein the common file is accessible via the unified interface, and wherein the unified interface includes a graphical user interface (GUI), a command line interface, or a backend interface…(Claim 4); US Pub No. 2019/0207867 A1 by Sivasubramanian et al. – [0024] … the service herein may provide a unified monitoring interface that can receive application performance data from different runtime environments and output/display the application performance information via a common and unified user interface….; WO 2012/097168 A2 by Luna et al; Fig. 9; para 0014; para 0088; US Pub No. 2011/0246298 A1 by Williams et al- para 0182
As explained above in step 2A prong 2, the additional elements are equivalent to “applying” the technology to the judicial exception. The interface as claimed is operating in its ordinary capacity without any indications of significantly more.
Taking the claim elements separately, the function performed by the interface at each step of the process is purely conventional. Using an interface for “receiving” data, “requesting” data, “initializing” payment facilitation of payment service, “causing” funds withdrawn and transferred ----are some of the most basic functions of an interface. The additional elements a “payment application” is applied to cause an interactive interface to be presented without any indications of significantly more. The specification discloses an “application (payment application) running on user devices to enable users to manage assets (para 0016). The specification discloses para 0026, that the payment service application executing …a user interface component may cause the payment service to display a user interface.
See also NPL “Power Apps Unified interface” by github.com (2022), “unified payment interface- An Advancement in Payment Systems” by American Journal (2017); “Checklist for unified interface transactions” by Microsoft (2023)
When the claims are taken as a whole, as an ordered combination, the combination of steps does not add “significantly more” by virtue of considering the steps as a whole, as an ordered combination. Absent a possible narrower construction of the terms “causing” interface to be presented, “receiving”, “determining” “ selecting”, “requesting”, “initializing the interface” to enable payment and “causing funds to be withdrawn/transferred” ... are functions can be achieved by any general purpose payment application applying a user interface without special programming. None of these activities are used in some unconventional manner nor do any produce some unexpected result.
As to the data operated upon, "even if a process of collecting and analyzing information is 'limited to particular content' or a particular 'source,' that limitation does not make the collection and analysis other than abstract." SAP America, Inc. v. Invest Pic LLC, 898 F.3d 1161, 1168 (Fed. Cir. 2018). Considered as an ordered combination, the computer components of Applicant’s claimed functions add nothing that is not already present when the steps are considered separately. The sequence of data reception-analysis modification-transmission is equally generic and conventional. See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 715 (Fed. Cir. 2014) (sequence of receiving, selecting, offering for exchange, display, allowing access, and receiving payment recited as an abstraction), Inventor Holdings, LLC v. Bed Bath & Beyond, Inc., 876 F.3d 1372, 1378 (Fed. Cir. 2017) (sequence of data retrieval, analysis, modification, generation, display, and transmission), Two-Way Media Ltd. v. Comcast Cable Communications, LLC, 874 F.3d 1329, 1339 (Fed. Cir. 2017) (sequence of processing, routing, controlling, and monitoring). The ordering of the steps is therefore ordinary and conventional. The analysis concludes that the claims do not provide an inventive concept because the additional elements recited in the claims do not provide significantly more than the recited judicial exception.
According to 2106.05 well-understood and routine processes to perform the abstract idea is not sufficient to transform the claim into patent eligibility. As evidence the examiner provides:
[0018] In some examples, the payment service provider and payment service computing platform may utilize rules, associations or mappings, a1tificial intelligence models, and/or the like to determine whether a payor is intending to initiate a payment to an intended payee corresponding to another user having an account internal to the payment service provider and payment service computing platform or corresponding to an external service provider and computing platform, and may dynamically adjust the payment transaction flow accordingly. In one non-limiting example, the payment service provider and payment service computing platform may utilize one or more search engines to perform a search of a database of identifiers to identify an intended payee by comparing one or more identifiers inputted by the payor on the payment service application to identifiers stored in the database of identifiers. That is, in one example, the payment service provider and payment service computing platform can utilize rules, associations or mappings, and/or the like to identify the intended payee based on identifier(s) provided to initiate the payment. In an additional or alternative example, the payment service provider and payment service computing platform may utilize one or more artificial intelligence models to generate a prediction of an intended payee type based on context associated with the payment (e.g., one or more identifiers that may be associated with the intended payee type, an amount of the payment, a date of the payment, a time of the payment, payment history of the payor, a payment amount, recent interactions between the user and applications and/or webpages, an entry point or previous
application and/or webpage from which the user accessed the payment service application, attachments associated with the payment, emojis and/or text description associated with the payment, and/or the like). The one or more artificial intelligence models may be trained to generate a prediction of an intended payee by way of, for example, one or more of text classification, image classification, and/or object detection. The use of artificial intelligence models to make predictions relating to the payor's intent for a transaction and to facilitate dynamic modifications of a payment
service application user interface in real-time or near-time-real allows for continuous and on demand improvement of the user interface in a manner that cannot be done through human activity. At the same time, it allows for each transaction and transaction flow to be customized to the payor, increasing the payor' s engagement and familiarity with user interface. Increasing user engagement can be particularly beneficial when the user is initiating transactions with unfamiliar payees and/or is using a computing device with limited user input functionality or display availability.
[0025] The payment service application may be a respective instance of the payment service application provided by a payment service operating the payment service system 106 and executing on the user devices 112a, 112b. The payment service may be associated with the payment service system 106 such that operations described as being performed by the payment service may be performed by the payment service system 106. In some examples, the payment service system 106 may include a "backend" and the payment service application may be referred
to as a "client" or "frontend." In some examples, individual of the components described herein may include a "frontend" and other components may include a "backend." In general, the components described herein as performing operations may be combined or divided, can have different names or functions, be used alone or in combination, be implemented by the server(s) 104 or user devices, and so on.
[0019] In some examples, upon the one or more search engines or the one or more artificial intelligence models identifying that the intended payee is a payee type internal to the payment service and payment service computing platform, a user interface management component may dynamically select or generate a payment transfer transaction flow in accordance with the identified intended payee. In some examples, upon the one or more search engines or the one or more artificial intelligence models identifying the intended payee is a payee type external to the
payment service and payment service computing platform, an application programming (API) management component may dynamically select or generate a payment transaction flow, such as a bill ( or invoice) payment transaction flow. The bill payment transaction flow may be constructed from existing components of a bill payment transaction flow and used to modify a general or universal starting user interface that receives the initial user information used to derive the user's intent. In some examples, the one or more artificial intelligence models and API management component may access, for example, a database of payment transaction flow modules and select
one of a number of predetermined or pre-generated payment transaction flows in accordance with the identified intended payee and a specified amount of funds for the intended payment transaction. In other examples, the API management component may access a database of payment transaction flow modules and generate a customized payment transaction flow by deriving in real-time or near real-time a customized payment transaction flow in accordance with the identified intended payee and a specified amount of funds for the intended payment transaction.
The specification para 0018-0019 discloses using models as a tool to analyze data lacking technical disclosure.
[0026] In some examples, a payor 103a may send a request to the payment service system 106 through the payment service application executing on the user device 112a. For example, a user interface component 117 may cause the payment service application to display a user interface 102 (e.g., 102a, 102b, 102c, 102d, 102e, or the like) on the user device 112a. In some examples, the user interface component 117 may include any user-facing web application and/or web application features (e.g., affordances, input controls, navigational elements, informational elements, and so forth) that may be suitable for causing the payment service application executing on the user device 112a to display the user interface 102 (e.g., 102a, 102b, 102c, 102d, 102e, or the like). The user interface component 117 may further allow the payor 103a to initiate a payment transaction, such as a request of funds, an execution of payments, such as payment transfers to a payee 103b (e.g., another user on the payment service system 106), bill payments, or utility payments, or a transfer of funds between different accounts on the payment service system 106
that are linked to the payor 103a. In some examples, by way of the user interface 102 (e.g., 102a, 102b, 102c, 102d, 102e, or the like), the user interface component 117 may allow the payor 103a to initiate a payment to any of various types of payees, such as payments to one or more payee(s) 103b on the payment service system 106, payments to business organizations or entities on the payment service system 106, or payments to entities external to the payment service system 106.
[0027] In some examples, as further depicted by the user interface 102a, the user interface component 117 may cause the user device 112a to display to the payor 103a the user interface 102a. In user interface 102a, one or more text fields 11 0a and 11 Ob may presented for the payor 103a to initiate one payment transaction of a variety of types of payment transactions, such as a request of funds, an execution of a payment (e.g., to another user (e.g., a P2P payment), a bill payment, a utility payment, etc.), or a transfer of funds in accordance with the presently disclosed
techniques. That is, the single user interface 102a acts as the initiating point for a variety of different types of types of payment transactions to different payee types. As described herein, the user interface 102 is dynamically selected, generated, or modified according to the type of payment transaction, as determined based on payee type, that the payment service system 106 detects as being requested by the payor 103a. For example, as illustrated by the user interface 102a, the payor 103a may initiate a payment transaction by selecting the text field 110a (e.g., "To: ... ") and
inputting one or more characters corresponding to an identifier associated with an intended payee. As used herein, a "payee" may refer to an intended recipient payment transaction, including, but not limited to, a payment, a transfer of funds, a transfer of assets, or other similar payment transaction.
[0035] In some additional examples, the artificial intelligence component 118 may include a combination of hardware and software artificial intelligence accelerators for executing one or more machine-learning models (e.g., one or more of a univariate logistic regression model, a multivariate logistic regression model, a random forest model, a Naive Bayes model, a gradient boosting model, a neural network, and so forth) or other predictive models that may be suitable for predicting, based on an identifier associated with an intended payee, a payee type for the intended
payee. Specifically, the artificial intelligence component 118 may be suitable for 1) predicting a payee type for an intended payee, including an identification of the payee and whether the payee type has a payee account internal to the payment service system 106 or payee account external to the payment service system 106, and further 2) predicting a type of a service provider or other entity having a payee account external to the payment service system 106 as described in greater detail below.
[0036] In some examples, the artificial intelligence component 118 may include hardware (e.g., a general purpose processor, a graphic processing unit (GPU), an application-specific integrated circuit (ASIC), a system-on-chip (SoC), a microcontroller, a field-programmable gate array (FPGA), a central processing unit (CPU), an application processor (AP), a visual processing unit (VPU), a neural processing unit (NPU), a neural decision processor (NDP), a tensor processing unit (TPU), a neuromorphic processing unit (NPU), a deep-learning processor (DLP), and/or other artificial intelligence accelerator that may be suitable for processing various transaction data and financial data and making one or more predictions based thereon), software (e.g., instructions running/executing on one or more processing devices), firmware (e.g., microcode), or some combination thereof. For example, the artificial intelligence component 118 that may identify a payee type of an intended payee by accessing one or more identifiers associated with an intended payee from the database of identifiers or context data 132, inputting the one or more identifiers into the artificial intelligence component 118 trained to generate a prediction of payee type based on identifiers associated with a payee, and causing the artificial intelligence component 118 to output the prediction of a payee type for the intended payee based on the one or more identifiers.
The specification para 0035-0036 discloses a laundry list of machine learning models that can be used as a tool to analyze data using general purpose computer components lacking technical disclosure.
The instant application, therefore, still appears to only implement the abstract ideas to the particular technological environments using what is generic components and functions in the related arts. The claim is not patent eligible.
The remaining dependent claims—which impose additional limitations—also fail to claim patent-eligible subject matter because the limitations cannot be considered statutory. In reference to claims 2-4 these dependent claim have also been reviewed with the same analysis as independent claim 1. Dependent claim 2 is directed toward sending an identifier, and receiving confirmation- insignificant extra solution activity and transaction process. Dependent claim 3 is directed toward comparing identifier, and selecting payment flow- analyzing data and performing a transaction a business process. Dependent claim 4 is directed toward selecting payment flow based on analysis- a transaction process.
The dependent claim(s) have been examined individually and in combination with the preceding claims, however they do not cure the deficiencies of claim 1. Where all claims are directed to the same abstract idea, “addressing each claim of the asserted patents [is] unnecessary.” Content Extraction & Transmission LLC v. Wells Fargo Bank, Nat 7 Ass ’n, 776 F.3d 1343, 1348 (Fed. Cir. 2014). If applicant believes the dependent claims 2-4 are directed towards patent eligible subject matter, they are invited to point out the specific limitations in the claim that are directed towards patent eligible subject matter.
In reference to Claims 5-14:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a method, as in independent Claim 5 and the dependent claims. Such methods fall under the statutory category of "process." Therefore, the claims are directed to a statutory eligibility category.
STEP 2A Prong 1. The claimed invention is directed to an abstract idea without significantly more. Method claim 5 recites a method steps (1) receiving request, (2) determining payee lacks an account associated with payment service (3) requesting confirmation that payee has an account with external service (4) selecting first user interface that includes input prompt (5) receiving information (6) determining payee type (7) exchanging transaction data and communication protocol between payment system and payment service associated servers (8) generating transaction flow (9) execute payment transactions executing payment transaction in response to receiving user selection in response to inputs (10) causing funds to be withdrawn
The claimed limitations which under its broadest reasonable interpretation, covers performance of sales activity. The specification using an application to facilitate user account services to facilitate user management of assets (funds, accounts, payments, balances, etc. -para 0016) and different payment flows (e.g., a payment transaction flow for payments between ordinary users, also known as "peer-to-peer" payments, distinct from a payment transaction flow for payments responsive to invoices or to service providers-para 0017). Claim 1 limitations and in light of the specification focuses on the abstract idea of commercial interactions and sales activities- ( facilitate account management using applications and interactive interface for user input and selections). These concepts are enumerated in Section I of the 2019 revised patent subject matter eligibility guidance published in the federal register (84 FR 50) on January 7, 2019) is directed toward abstract category of methods of organizing human activity.
STEP 2A Prong 2: The identified judicial exception is not integrated into a practical application because the claims fail to provide indications of patent eligible subject matter that integrate the alleged abstract idea into a practical application. The additional elements recited in the claim beyond the abstract idea include “payment service system”, “interface of a payment application on electronic device”, “model trained”, an “API call”, “user interface in sequence/unified”, “one or more API calls”, “one or more servers associated with payee account external to payment service”, a “database of payment transaction flow modules” and “sequence/unified user interfaces.
The claimed payment service system to perform the operation “receiving …request” and “transferred [funds] to the payee account…”
The claimed first API call to perform the operation of “requesting …confirmation.”
The claimed first user interface in sequence/unified to perform the operation “receiving…information”.
The claimed “one or more second API calls” to perform the operations “exchanging …data and communications protocol data between …system and one or more servers…”.
The claimed “sequence of user interfaces” to perform the operations of “receiving one or more user inputs…
The limitations performed by the payment service system, first user interface, API calls, one or more second API calls, sequence of user interfaces, are high level lacking technical disclosure of any details of technical implementation. According to MPEP 2106.05(d) II (see also MPEP 2106.05(g)) the courts have recognized the following computer functions are claimed in a merely generic manner (e.g., at a high level of generality) where technology is merely applied to perform the abstract idea or as insignificant extra-solution activity.
Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014)
Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93
The additional element payment service is recited at a high level of generality to perform as part of the transaction process selecting a first user interface in a sequence [unified] of user interfaces that includes a prompt and generating transaction flow for executing the payment transaction. The limitations limits the sequence of user interaction of the payment transaction flow modules in order to perform the execution and then executing the payment transaction causing the funds to be withdrawn from payor account and then transferring funds to the payee account. The additional element “payment service” is merely providing a field of use in order to perform the transaction.
The additional elements “model trained” is utilized for “determining…a payee type to associated with the payee” that lacks an account associated with payment service and for “determining…payee type associated with payee corresponds to service provider having a payment account external to payment service” which amounts to no more than mere instructions to analyze data for an expected result.
The claim limitations when considered individually fail to provide any indications of patent eligible subject matter, according to MPEP guidance (see MPEP 2106.05 (a)-(c), (e )-(h).
(i) an improvement to the functioning of a computer;
(ii) an improvement to another technology or technical field;
(iii) an application of the abstract idea with, or by use of, a
particular machine;
(iv) a transformation or reduction of a particular article to a
different state or thing; or
(v) other meaningful limitations beyond generally linking the
use of the abstract idea to a particular technological environment.
The claimed model is applied at a high level to determine that the payee lacks an account associated with a payment service lacking technical details and therefore, amounts to no more than mere instructions to analyze transaction related data for determining whether a payee lacks an account associated with a payment service. The additional element “payment application by a payment service” recited to perform the steps “causing interface to be presented” and the additional element “via interface” to perform the steps “receiving data”, “requesting additional information”, “causing funds withdrawn” and “causing funds transferred” and the nominal mention of a model used to predict payee types” are is recited at a high-level of generality such that it amounts to no more mere instructions to apply the exception on a generic computer. The model determining process is not directed toward any processes related to technology and is merely applied as a tool to analyze transaction related data.
The application of the payment service is generally applied without limiting how the application as a technical process causes the interface to be presented. Taking the claim elements separately, the operation performed by the method at each step of the process is purely in terms of results desired and devoid of implementation of details. The steps of the Technology is not integral to the process as the claimed subject matter is so high level that any generic programming could be applied and the functions could be performed by any known means. Furthermore, the claimed functions do not provide an operation that could be considered as sufficient to provide a technological implementation or application of/or improvement to this concept (i.e. integrated into a practical application).
When the claims are taken as a whole, as an ordered combination, the combination of limitations performed by a claimed payment service system comprising a payment service to perform transaction method receiving a request to execute a payment transaction using a payment application where a model is utilized for determining payee types associated with specific payee in the combination of limitations 1-2– a transaction process and not for providing indications of patent eligibility under step 2A prong 2. The combination of limitations 1-2 and 3-5 applying an API as a tool to call confirm the payee has an account with an external service for the transaction process where a user interface is selected based on the confirmation as part of the transaction process using payment flow transaction modules where the user interface includes a prompt for input information related to the transaction for receiving payee associated information in combination with the transaction request of limitations 1-2. The combination of limitations 1-5 and 6-8 where limitations 6-8 is directed toward utilizing (applying) the model for determining payee type corresponding to service provider, where an API is applied as a tool to perform one or more API calls to exchange transaction data and communication data between the payment service system and one or more servers associated with the payee account for the transaction process. The data exchanged by the API calls is applied by the payment service system which is applied for generating the transaction flow for executing the payment to complete the payment transaction between payor and payee in response to the combination of limitations 1-5. The combination of limitations 1-8 and 9 is directed toward applying the payment service system to execute the payment by withdrawing funds from payor accounts and transferred to the payee account.
The combinations of parts is not directed toward any technical process or technological technique or technological solution to a problem rooted in technology.
Therefore, when the claims are taken as a whole, as an ordered combination, the combination of steps not integrate the judicial exception into a practical application as the claim process fails to impose meaningful limits upon the abstract idea. . This is because there is no indication in the claim language that the structure and/or the manner in which any underlying technology is changed in any way. The Specification describes the advantage for an entire set of different user interactions and payment transaction flows may be performed and executed for within a unified payment service application without having to exit the application (para 0017) where a user interface may select/generate a payment transfer transaction flow in accordance with the identified intended payee (para 0019). The claim provides no technical details regarding how the “model” utilization operation is performed. Instead, similar to the claims at issue in Intellectual Ventures I LLC v. Capital One Financial Corp., 850 F.3d 1332 (Fed. Cir. 2017), “the claim language . . . provides only a result-oriented solution with insufficient detail for how a computer accomplishes it. Our law demands more.” Intellectual Ventures, 850 F.3d at 1342 (citing Elec. Power Grp. LLC v. Alstom, S.A., 830 F.3d 1350, 1356 (Fed. Cir. 2016)).
The claimed subject matter fails to provide additional elements or combination or elements to apply or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception. The functions recited in the claims recite the concept of applying a user interface to receive identifiers associated with payee, selecting a payment flow, request additional information and initialize and perform a payment transfer which is a process directed toward a business practice. The integration of elements do not improve upon technology or improve upon computer functionality or capability in how computers carry out one of their basic functions. The integration of elements do not provide a process that allows computers to perform functions that previously could not be performed. The integration of elements do not provide a process which applies a relationship to apply a new way of using an application. The instant application, therefore, still appears only to implement the abstract idea to the particular technological environments apply what generic computer functionality in the related arts. The steps are still a combination made to recite “outcomes” of the payment transfer steps without any details about how the outcomes are accomplished as it relates to a technical process and therefore, does not provide any of the determined indications of patent eligibility set forth in the 2019 USPTO 101 guidance. The additional steps only add to those abstract ideas using generic functions, and the claims do not show improved ways of, for example, an particular technical function for performing the abstract idea that imposes meaningful limits upon the abstract idea. Moreover, Examiner was not able to identify any specific technological processes that goes beyond merely confining the abstract idea in a particular technological environment, which, when considered in the ordered combination with the other steps, could have transformed the nature of the abstract idea previously identified. Accordingly, this additional element does 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 2B; The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above with respect to concepts of the abstract idea into a practical application. The additional elements recited in the claim include a “payment service system to perform the transaction process “receiving …request”, “identifying …payee type”, “generating…sequence of user interaction for payment transaction” and “executing payment transaction” and “utilizing model trained” for determining function without any details as to technical implementation. The model is nominal mention. The user interface in a sequence merely transmits transaction data according to transaction flow modules for executing the payment transaction lacking technical disclosure.
As explained above in step 2A prong 2, the additional elements are equivalent to “applying” the technology to the judicial exception. The payment service system, user interface, transaction modules and model as claimed is operating in its ordinary capacity lacking any details as to a technical process, merely reciting high level functions with an expected outcome for performing the transaction process, without any indications of significantly more applying technology to implement the transaction payment.
With respect to the limitation “interface in sequence”, the examiner provides evidence that the interface claimed is well known in the art- US Pub No. 2016/0054922 A1 by Awasthi et al- [0047]… the memory interconnect 104 may provide the processor 102 with a unified or common interface or protocol for accessing the plurality of storage mediums…memory interconnect 104 may provide the various storage mediums 116, 126, 136, and 146 with respective interfaces that employ the respective protocols employed by the plurality of storage mediums; US Patent No. 11,546,243 B1 by Menon et al -…wherein the common file is accessible via the unified interface, and wherein the unified interface includes a graphical user interface (GUI), a command line interface, or a backend interface…(Claim 4); US Pub No. 2019/0207867 A1 by Sivasubramanian et al. – [0024] … the service herein may provide a unified monitoring interface that can receive application performance data from different runtime environments and output/display the application performance information via a common and unified user interface….; WO 2012/097168 A2 by Luna et al; Fig. 9; para 0014; para 0088; US Pub No. 2011/0246298 A1 by Williams et al- para 0182
Taking the claim elements separately, the function performed by the interface at each step of the process is purely conventional. The steps performed by the payment service system “receiving” data”, “identifying …payee type”, “generating…sequence of user interaction for payment transaction” and “executing payment transaction” ----are some of the most basic functions of payment systems.
See also NPL “Power Apps Unified interface” by github.com (2022), “unified payment interface- An Advancement in Payment Systems” by American Journal (2017); “Checklist for unified interface transactions” by Microsoft (2023)
According to 2106.05 well-understood and routine processes to perform the abstract idea is not sufficient to transform the claim into patent eligibility. As evidence the examiner provides:
The specification discloses payment service system as:
[0024] FIG. 1 illustrates an example operating environment for providing dynamic user interfaces and operational flows as discussed herein. The example environment 100 may include a payment service system 106. The payment service system 106 may include one or more servers 104 and a datastore 128 that may be suitable for exchanging electronic communications through network(s) 101 with one or more other computing devices. For example, the server(s) 104 or datastore 128 may exchange electronic communications with a user device 112a associated with a
user, such as a payor 103a, by way of a payment service application (e.g., a mobile payment application) executing on the user device 112a and a user device 112b associated with a user, such as a payee 103b, by way of a payment service application (e.g., a mobile payment application) executing on the user device 112b.
0018] In some examples, the payment service provider and payment service computing platform may utilize rules, associations or mappings, a1tificial intelligence models, and/or the like to determine whether a payor is intending to initiate a payment to an intended payee corresponding to another user having an account internal to the payment service provider and payment service computing platform or corresponding to an external service provider and computing platform, and may dynamically adjust the payment transaction flow accordingly. In one non-limiting example, the payment service provider and payment service computing platform may utilize one or more search engines to perform a search of a database of identifiers to identify an intended payee by comparing one or more identifiers inputted by the payor on the payment service application to identifiers stored in the database of identifiers. That is, in one example, the payment service provider and payment service computing platform can utilize rules, associations or mappings, and/or the like to identify the intended payee based on identifier(s) provided to initiate the payment. In an additional or alternative example, the payment service provider and payment service computing platform may utilize one or more artificial intelligence models to generate a prediction of an intended payee type based on context associated with the payment (e.g., one or more identifiers that may be associated with the intended payee type, an amount of the payment, a date of the payment, a time of the payment, payment history of the payor, a payment amount, recent interactions between the user and applications and/or webpages, an entry point or previous
application and/or webpage from which the user accessed the payment service application, attachments associated with the payment, emojis and/or text description associated with the payment, and/or the like). The one or more artificial intelligence models may be trained to generate a prediction of an intended payee by way of, for example, one or more of text classification, image classification, and/or object detection. The use of artificial intelligence models to make predictions relating to the payor's intent for a transaction and to facilitate dynamic modifications of a payment
service application user interface in real-time or near-time-real allows for continuous and on demand improvement of the user interface in a manner that cannot be done through human activity. At the same time, it allows for each transaction and transaction flow to be customized to the payor, increasing the payor' s engagement and familiarity with user interface. Increasing user engagement can be particularly beneficial when the user is initiating transactions with unfamiliar payees and/or is using a computing device with limited user input functionality or display availability.
[0025] The payment service application may be a respective instance of the payment service application provided by a payment service operating the payment service system 106 and executing on the user devices 112a, 112b. The payment service may be associated with the payment service system 106 such that operations described as being performed by the payment service may be performed by the payment service system 106. In some examples, the payment service system 106 may include a "backend" and the payment service application may be referred
to as a "client" or "frontend." In some examples, individual of the components described herein may include a "frontend" and other components may include a "backend." In general, the components described herein as performing operations may be combined or divided, can have different names or functions, be used alone or in combination, be implemented by the server(s) 104 or user devices, and so on.
[0019] In some examples, upon the one or more search engines or the one or more artificial intelligence models identifying that the intended payee is a payee type internal to the payment service and payment service computing platform, a user interface management component may dynamically select or generate a payment transfer transaction flow in accordance with the identified intended payee. In some examples, upon the one or more search engines or the one or more artificial intelligence models identifying the intended payee is a payee type external to the
payment service and payment service computing platform, an application programming (API) management component may dynamically select or generate a payment transaction flow, such as a bill ( or invoice) payment transaction flow. The bill payment transaction flow may be constructed from existing components of a bill payment transaction flow and used to modify a general or universal starting user interface that receives the initial user information used to derive the user's intent. In some examples, the one or more artificial intelligence models and API management component may access, for example, a database of payment transaction flow modules and select
one of a number of predetermined or pre-generated payment transaction flows in accordance with the identified intended payee and a specified amount of funds for the intended payment transaction. In other examples, the API management component may access a database of payment transaction flow modules and generate a customized payment transaction flow by deriving in real-time or near real-time a customized payment transaction flow in accordance with the identified intended payee and a specified amount of funds for the intended payment transaction.
The specification para 0018-0019 discloses using models as a tool to analyze data lacking technical disclosure.
[0035] In some additional examples, the artificial intelligence component 118 may include a combination of hardware and software artificial intelligence accelerators for executing one or more machine-learning models (e.g., one or more of a univariate logistic regression model, a multivariate logistic regression model, a random forest model, a Naive Bayes model, a gradient boosting model, a neural network, and so forth) or other predictive models that may be suitable for predicting, based on an identifier associated with an intended payee, a payee type for the intended
payee. Specifically, the artificial intelligence component 118 may be suitable for 1) predicting a payee type for an intended payee, including an identification of the payee and whether the payee type has a payee account internal to the payment service system 106 or payee account external to the payment service system 106, and further 2) predicting a type of a service provider or other entity having a payee account external to the payment service system 106 as described in greater detail below.
[0036] In some examples, the artificial intelligence component 118 may include hardware (e.g., a general purpose processor, a graphic processing unit (GPU), an application-specific integrated circuit (ASIC), a system-on-chip (SoC), a microcontroller, a field-programmable gate array (FPGA), a central processing unit (CPU), an application processor (AP), a visual processing unit (VPU), a neural processing unit (NPU), a neural decision processor (NDP), a tensor processing unit (TPU), a neuromorphic processing unit (NPU), a deep-learning processor (DLP), and/or other artificial intelligence accelerator that may be suitable for processing various transaction data and financial data and making one or more predictions based thereon), software (e.g., instructions running/executing on one or more processing devices), firmware (e.g., microcode), or some combination thereof. For example, the artificial intelligence component 118 that may identify a payee type of an intended payee by accessing one or more identifiers associated with an intended payee from the database of identifiers or context data 132, inputting the one or more identifiers into the artificial intelligence component 118 trained to generate a prediction of payee type based on identifiers associated with a payee, and causing the artificial intelligence component 118 to output the prediction of a payee type for the intended payee based on the one or more identifiers.
The specification para 0035-0036 discloses a laundry list of machine learning models that can be used as a tool to analyze data using general purpose computer components lacking technical disclosure.
When the claims are taken as a whole, as an ordered combination, the combination of steps does not add “significantly more” by virtue of considering the steps as a whole, as an ordered combination. Absent a possible narrower construction of the terms “causing” interface to be presented, “receiving”, “ selecting”, “requesting”, “initializing the interface” to enable payment and “causing funds to be withdrawn/transferred” ... are functions can be achieved by any general purpose payment application applying a user interface without special programming. None of these activities are used in some unconventional manner nor do any produce some unexpected result.
As to the data operated upon, "even if a process of collecting and analyzing information is 'limited to particular content' or a particular 'source,' that limitation does not make the collection and analysis other than abstract." SAP America, Inc. v. Invest Pic LLC, 898 F.3d 1161, 1168 (Fed. Cir. 2018). Considered as an ordered combination, the computer components of Applicant’s claimed functions add nothing that is not already present when the steps are considered separately. The sequence of data reception-analysis modification-transmission is equally generic and conventional. See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 715 (Fed. Cir. 2014) (sequence of receiving, selecting, offering for exchange, display, allowing access, and receiving payment recited as an abstraction), Inventor Holdings, LLC v. Bed Bath & Beyond, Inc., 876 F.3d 1372, 1378 (Fed. Cir. 2017) (sequence of data retrieval, analysis, modification, generation, display, and transmission), Two-Way Media Ltd. v. Comcast Cable Communications, LLC, 874 F.3d 1329, 1339 (Fed. Cir. 2017) (sequence of processing, routing, controlling, and monitoring). The ordering of the steps is therefore ordinary and conventional. The analysis concludes that the claims do not provide an inventive concept because the additional elements recited in the claims do not provide significantly more than the recited judicial exception.
The instant application, therefore, still appears to only implement the abstract ideas to the particular technological environments using what is generic components and functions in the related arts. The claim is not patent eligible.
The remaining dependent claims—which impose additional limitations—also fail to claim patent-eligible subject matter because the limitations cannot be considered statutory. In reference to claims 6-14 these dependent claim have also been reviewed with the same analysis as independent claim 5. Dependent claim 6 is directed toward reoccurring payment transactions – sales activity. Dependent claim 7 is directed toward identifier associated with payee- business practice. Dependent claim 8 is directed toward receiving data- insignificant extra solution activity. Dependent claim 9 is directed toward selecting transaction flow- sales activity. Dependent claim 10 is directed toward deriving transaction flow- sales activity. Dependent claim 11 is directed toward identifying payee type -by accessing data, analyzing data and outputting the result- Electric Power Group. Dependent claim 12 is directed toward data content- non-functional descriptive subject matter. Dependent claim 13 is directed toward receiving data-insignificant extra solution activity. Dependent claim 14 is directed toward data content – non-functional descriptive subject matter.
The limitations which recite applying machine learning algorithms for analysis lacks technical disclosure. The dependent claim(s) have been examined individually and in combination with the preceding claims, however they do not cure the deficiencies of claim 5. Where all claims are directed to the same abstract idea, “addressing each claim of the asserted patents [is] unnecessary.” Content Extraction & Transmission LLC v. Wells Fargo Bank, Nat 7 Ass ’n, 776 F.3d 1343, 1348 (Fed. Cir. 2014). If applicant believes the dependent claims 6-14 are directed towards patent eligible subject matter, they are invited to point out the specific limitations in the claim that are directed towards patent eligible subject matter.
In reference to Claims 15-20:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a system, as in independent Claim 15 and the dependent claims. Such systems fall under the statutory category of "machine." Therefore, the claims are directed to a statutory eligibility category.
STEP 2A Prong 1. The functions of system claim15 corresponds to steps of method claim 5. Therefore, claim 15 has been analyzed and rejected as being directed toward an abstract idea of the categories of concepts directed toward mental processes and methods of organizing human activity previously discussed with respect to claim 1.
STEP 2A Prong 2: The functions of system claim15 corresponds to steps of method claim 5. Therefore, claim 15 has been analyzed and rejected as failing to provide limitations that are indicative of integration into a practical application, as previously discussed with respect to claim 5.
STEP 2B; The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above with respect to concepts of the abstract idea into a practical application. The additional elements beyond the abstract idea include a payment server system processor comprising a comprising “one or more processors”, “a memory coupled to the one or more processors comprising instructions executable by the one or more processors”–is purely functional and generic. Nearly every computer system for implementing a method will include a “processor” capable of performing the basic computer functions -of “one or more processors”, “a memory coupled to the one or more processors comprising instructions executable by the one or more processors”- As a result, none of the hardware recited by the system claims offers a meaningful limitation beyond generally linking the use of the method to a particular technological environment, that is, implementation via computers.
The functions of system claim 15 corresponds to steps of method claim 5. Therefore, claim 5 has been analyzed and rejected as failing to provide additional elements that amount to an inventive concept –i.e. significantly more than the recited judicial exception. Furthermore, as previously discussed with respect to claim 1, the limitations when considered individually, as a combination of parts or as a whole fail to provide any indication that the elements recited are unconventional or otherwise more than what is well understood, conventional, routine activity in the field.
According to 2106.05 well-understood and routine processes to perform the abstract idea is not sufficient to transform the claim into patent eligibility. As evidence the examiner provides:
With respect to the limitation “interface in sequence”, the examiner provides evidence that the interface claimed is well known in the art- US Pub No. 2016/0054922 A1 by Awasthi et al- [0047]… the memory interconnect 104 may provide the processor 102 with a unified or common interface or protocol for accessing the plurality of storage mediums…memory interconnect 104 may provide the various storage mediums 116, 126, 136, and 146 with respective interfaces that employ the respective protocols employed by the plurality of storage mediums; US Patent No. 11,546,243 B1 by Menon et al -…wherein the common file is accessible via the unified interface, and wherein the unified interface includes a graphical user interface (GUI), a command line interface, or a backend interface…(Claim 4); US Pub No. 2019/0207867 A1 by Sivasubramanian et al. – [0024] … the service herein may provide a unified monitoring interface that can receive application performance data from different runtime environments and output/display the application performance information via a common and unified user interface….; WO 2012/097168 A2 by Luna et al; Fig. 9; para 0014; para 0088; US Pub No. 2011/0246298 A1 by Williams et al- para 0182
See also NPL “Power Apps Unified interface” by github.com (2022), “unified payment interface- An Advancement in Payment Systems” by American Journal (2017); “Checklist for unified interface transactions” by Microsoft (2023)
The specification discloses:
[0024] FIG. 1 illustrates an example operating environment for providing dynamic user interfaces and operational flows as discussed herein. The example environment 100 may include a payment service system 106. The payment service system 106 may include one or more servers 104 and a datastore 128 that may be suitable for exchanging electronic communications through network(s) 101 with one or more other computing devices. For example, the server(s) 104 or datastore 128 may exchange electronic communications with a user device 112a associated with a
user, such as a payor 103a, by way of a payment service application (e.g., a mobile payment application) executing on the user device 112a and a user device 112b associated with a user, such as a payee 103b, by way of a payment service application (e.g., a mobile payment application) executing on the user device 112b.
0018] In some examples, the payment service provider and payment service computing platform may utilize rules, associations or mappings, a1tificial intelligence models, and/or the like to determine whether a payor is intending to initiate a payment to an intended payee corresponding to another user having an account internal to the payment service provider and payment service computing platform or corresponding to an external service provider and computing platform, and may dynamically adjust the payment transaction flow accordingly. In one non-limiting example, the payment service provider and payment service computing platform may utilize one or more search engines to perform a search of a database of identifiers to identify an intended payee by comparing one or more identifiers inputted by the payor on the payment service application to identifiers stored in the database of identifiers. That is, in one example, the payment service provider and payment service computing platform can utilize rules, associations or mappings, and/or the like to identify the intended payee based on identifier(s) provided to initiate the payment. In an additional or alternative example, the payment service provider and payment service computing platform may utilize one or more artificial intelligence models to generate a prediction of an intended payee type based on context associated with the payment (e.g., one or more identifiers that may be associated with the intended payee type, an amount of the payment, a date of the payment, a time of the payment, payment history of the payor, a payment amount, recent interactions between the user and applications and/or webpages, an entry point or previous
application and/or webpage from which the user accessed the payment service application, attachments associated with the payment, emojis and/or text description associated with the payment, and/or the like). The one or more artificial intelligence models may be trained to generate a prediction of an intended payee by way of, for example, one or more of text classification, image classification, and/or object detection. The use of artificial intelligence models to make predictions relating to the payor's intent for a transaction and to facilitate dynamic modifications of a payment
service application user interface in real-time or near-time-real allows for continuous and on demand improvement of the user interface in a manner that cannot be done through human activity. At the same time, it allows for each transaction and transaction flow to be customized to the payor, increasing the payor' s engagement and familiarity with user interface. Increasing user engagement can be particularly beneficial when the user is initiating transactions with unfamiliar payees and/or is using a computing device with limited user input functionality or display availability.
[0025] The payment service application may be a respective instance of the payment service application provided by a payment service operating the payment service system 106 and executing on the user devices 112a, 112b. The payment service may be associated with the payment service system 106 such that operations described as being performed by the payment service may be performed by the payment service system 106. In some examples, the payment service system 106 may include a "backend" and the payment service application may be referred
to as a "client" or "frontend." In some examples, individual of the components described herein may include a "frontend" and other components may include a "backend." In general, the components described herein as performing operations may be combined or divided, can have different names or functions, be used alone or in combination, be implemented by the server(s) 104 or user devices, and so on.
[0019] In some examples, upon the one or more search engines or the one or more artificial intelligence models identifying that the intended payee is a payee type internal to the payment service and payment service computing platform, a user interface management component may dynamically select or generate a payment transfer transaction flow in accordance with the identified intended payee. In some examples, upon the one or more search engines or the one or more artificial intelligence models identifying the intended payee is a payee type external to the
payment service and payment service computing platform, an application programming (API) management component may dynamically select or generate a payment transaction flow, such as a bill ( or invoice) payment transaction flow. The bill payment transaction flow may be constructed from existing components of a bill payment transaction flow and used to modify a general or universal starting user interface that receives the initial user information used to derive the user's intent. In some examples, the one or more artificial intelligence models and API management component may access, for example, a database of payment transaction flow modules and select
one of a number of predetermined or pre-generated payment transaction flows in accordance with the identified intended payee and a specified amount of funds for the intended payment transaction. In other examples, the API management component may access a database of payment transaction flow modules and generate a customized payment transaction flow by deriving in real-time or near real-time a customized payment transaction flow in accordance with the identified intended payee and a specified amount of funds for the intended payment transaction.
The specification para 0018-0019 discloses using models as a tool to analyze data lacking technical disclosure.
[0026] In some examples, a payor 103a may send a request to the payment service system 106 through the payment service application executing on the user device 112a. For example, a user interface component 117 may cause the payment service application to display a user interface 102 (e.g., 102a, 102b, 102c, 102d, 102e, or the like) on the user device 112a. In some examples, the user interface component 117 may include any user-facing web application and/or web application features (e.g., affordances, input controls, navigational elements, informational elements, and so forth) that may be suitable for causing the payment service application executing on the user device 112a to display the user interface 102 (e.g., 102a, 102b, 102c, 102d, 102e, or the like). The user interface component 117 may further allow the payor 103a to initiate a payment transaction, such as a request of funds, an execution of payments, such as payment transfers to a payee 103b (e.g., another user on the payment service system 106), bill payments, or utility payments, or a transfer of funds between different accounts on the payment service system 106
that are linked to the payor 103a. In some examples, by way of the user interface 102 (e.g., 102a, 102b, 102c, 102d, 102e, or the like), the user interface component 117 may allow the payor 103a to initiate a payment to any of various types of payees, such as payments to one or more payee(s) 103b on the payment service system 106, payments to business organizations or entities on the payment service system 106, or payments to entities external to the payment service system 106.
[0027] In some examples, as further depicted by the user interface 102a, the user interface component 117 may cause the user device 112a to display to the payor 103a the user interface 102a. In user interface 102a, one or more text fields 11 0a and 11 Ob may presented for the payor 103a to initiate one payment transaction of a variety of types of payment transactions, such as a request of funds, an execution of a payment (e.g., to another user (e.g., a P2P payment), a bill payment, a utility payment, etc.), or a transfer of funds in accordance with the presently disclosed
techniques. That is, the single user interface 102a acts as the initiating point for a variety of different types of types of payment transactions to different payee types. As described herein, the user interface 102 is dynamically selected, generated, or modified according to the type of payment transaction, as determined based on payee type, that the payment service system 106 detects as being requested by the payor 103a. For example, as illustrated by the user interface 102a, the payor 103a may initiate a payment transaction by selecting the text field 110a (e.g., "To: ... ") and
inputting one or more characters corresponding to an identifier associated with an intended payee. As used herein, a "payee" may refer to an intended recipient payment transaction, including, but not limited to, a payment, a transfer of funds, a transfer of assets, or other similar payment transaction.
[0035] In some additional examples, the artificial intelligence component 118 may include a combination of hardware and software artificial intelligence accelerators for executing one or more machine-learning models (e.g., one or more of a univariate logistic regression model, a multivariate logistic regression model, a random forest model, a Naive Bayes model, a gradient boosting model, a neural network, and so forth) or other predictive models that may be suitable for predicting, based on an identifier associated with an intended payee, a payee type for the intended
payee. Specifically, the artificial intelligence component 118 may be suitable for 1) predicting a payee type for an intended payee, including an identification of the payee and whether the payee type has a payee account internal to the payment service system 106 or payee account external to the payment service system 106, and further 2) predicting a type of a service provider or other entity having a payee account external to the payment service system 106 as described in greater detail below.
[0036] In some examples, the artificial intelligence component 118 may include hardware (e.g., a general purpose processor, a graphic processing unit (GPU), an application-specific integrated circuit (ASIC), a system-on-chip (SoC), a microcontroller, a field-programmable gate array (FPGA), a central processing unit (CPU), an application processor (AP), a visual processing unit (VPU), a neural processing unit (NPU), a neural decision processor (NDP), a tensor processing unit (TPU), a neuromorphic processing unit (NPU), a deep-learning processor (DLP), and/or other artificial intelligence accelerator that may be suitable for processing various transaction data and financial data and making one or more predictions based thereon), software (e.g., instructions running/executing on one or more processing devices), firmware (e.g., microcode), or some combination thereof. For example, the artificial intelligence component 118 that may identify a payee type of an intended payee by accessing one or more identifiers associated with an intended payee from the database of identifiers or context data 132, inputting the one or more identifiers into the artificial intelligence component 118 trained to generate a prediction of payee type based on identifiers associated with a payee, and causing the artificial intelligence component 118 to output the prediction of a payee type for the intended payee based on the one or more identifiers.
The specification para 0035-0036 discloses a laundry list of machine learning models that can be used as a tool to analyze data using general purpose computer components lacking technical disclosure.
When the claims are taken as a whole, as an ordered combination, the combination of steps does not add “significantly more” by virtue of considering the steps as a whole, as an ordered combination. Absent a possible narrower construction of the terms “causing” interface to be presented, “receiving”, “ selecting”, “requesting”, “initializing the interface” to enable payment and “causing funds to be withdrawn/transferred” ... are functions can be achieved by any general purpose payment application applying a user interface without special programming. None of these activities are used in some unconventional manner nor do any produce some unexpected result.
As to the data operated upon, "even if a process of collecting and analyzing information is 'limited to particular content' or a particular 'source,' that limitation does not make the collection and analysis other than abstract." SAP America, Inc. v. Invest Pic LLC, 898 F.3d 1161, 1168 (Fed. Cir. 2018). Considered as an ordered combination, the computer components of Applicant’s claimed functions add nothing that is not already present when the steps are considered separately. The sequence of data reception-analysis modification-transmission is equally generic and conventional. See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 715 (Fed. Cir. 2014) (sequence of receiving, selecting, offering for exchange, display, allowing access, and receiving payment recited as an abstraction), Inventor Holdings, LLC v. Bed Bath & Beyond, Inc., 876 F.3d 1372, 1378 (Fed. Cir. 2017) (sequence of data retrieval, analysis, modification, generation, display, and transmission), Two-Way Media Ltd. v. Comcast Cable Communications, LLC, 874 F.3d 1329, 1339 (Fed. Cir. 2017) (sequence of processing, routing, controlling, and monitoring). The ordering of the steps is therefore ordinary and conventional. The analysis concludes that the claims do not provide an inventive concept because the additional elements recited in the claims do not provide significantly more than the recited judicial exception.
The instant application, therefore, still appears to only implement the abstract ideas to the particular technological environments using what is generic components and functions in the related arts. The claim is not patent eligible.
The remaining dependent claims—which impose additional limitations—also fail to claim patent-eligible subject matter because the limitations cannot be considered statutory. In reference to claims 16-20 these dependent claim have also been reviewed with the same analysis as independent claim 15. Dependent claim 16 is directed toward reoccurring payment transactions – sales activity. Dependent claim 17 is directed toward identifier associated with payee- business practice. Dependent claim 18 is directed toward receiving data- insignificant extra solution activity. Dependent claim 9 is directed toward selecting transaction flow- sales activity. Dependent claim 19 is directed toward identifying payee type -by accessing data, analyzing data and outputting the result- Electric Power Group. Dependent claim 20 is directed toward data content of data identifiers- non-functional descriptive subject matter.
The dependent claim(s) have been examined individually and in combination with the preceding claims, however they do not cure the deficiencies of claim 15. Where all claims are directed to the same abstract idea, “addressing each claim of the asserted patents [is] unnecessary.” Content Extraction & Transmission LLC v. Wells Fargo Bank, Nat 7 Ass ’n, 776 F.3d 1343, 1348 (Fed. Cir. 2014). If applicant believes the dependent claims 16-20 are directed towards patent eligible subject matter, they are invited to point out the specific limitations in the claim that are directed towards patent eligible subject matter.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. AU 2012352157 by Makhotin et al, CA 3133979 A1 by Zhang et al, EP 4116907 A1 by Diamond, JP 2019/522833 A by アスベ、 ディリップ and translation, WO 2024/151309 A1 by Uchil et al
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARY M GREGG whose telephone number is (571)270-5050. The examiner can normally be reached M-F 9am-5pm.
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 Behncke can be reached at 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.
/MARY M GREGG/Examiner, Art Unit 3695
/CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695
Prosecution Insights