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 January 21, 2026. Claim(s) 14 have been canceled. Claims 1, 8 and 15 have been amended. No new claims have been added. Therefore, claims 1-13 and 15-21 are pending and addressed below.
Priority
Application No. 18/346,416 Filing date: 07/03/2023.
Applicant Name/Assignee: Capital One Services, LLC
Inventor(s); Pawar, Pawankumar; Kayton, Elisabeth; Singh, Harvinder; Rajaram, Manikandan
Response to Amendment/Arguments
Claim Rejections - 35 USC § 101
Applicant's arguments filed January 21, 2026 have been fully considered but they are not persuasive.
In the remarks applicant points to MPEP 2106.04(d)(I), arguing that the claimed subject matter when considered as a whole integrates any alleged judicial exception into a practical application. The claimed subject matter provides improvements in the technical field of computerized systems in handling intake of fraudulent/disputed transactions. Applicant points to the specification ¶ 0029 arguing that because the intake workflow is not bound to any particular sequence of screens or user interfaces and is customized to guide the user toward the resolution and can be operable with any suitable communication channel when the user starts an incident file so that the report in a first communication channel and switch to another channel as needed, the claimed subject matter improves technology. This is because the limitations provide a technical solution that improves upon hardcoded channel-specific workflows for intake handling. Applicant recites the limitations which recite screens selected based on data and user inputs which include prompts for users to provide documentation and continues to select and present additional next screens when workflow reaches a decision point. Applicant’s argument is not persuasive. Wizard selection of screens that are presented based on data received and user inputs are not an improvement over existing wizard technology. The recited limitations do not recite any particular technical process of the system process for screen selection and presentation other than the selections are a response to inputs provided by the user. The limitations are not directed toward wizard technology but rather the use of wizard technology which provides a decision tree workflow based on data inputted used to receive user input to a request to resolve a fraudulent incident, where the wizard provides questions related to the incident to collect data to resolve parameters associated with reported incident. The claimed limitation does not improve upon as a technical process the capability of wizard interfaces that guide users through a series of questions in presented windows. The claim limitations merely apply wizard technology to collect data in order to get a resolution for fraud report (for example see US Pub No. 2019/0286462 A1 by Bodnick et al- para 0182-0183, para 0217; US Pub No. 2014/0032485 A1 by Perelman et al-FIG. 2, FIG. 4-5; para 0025, para 0028, para 0033). The rejection is maintained.
Claim Rejections - 35 USC § 103
Applicant's arguments filed January 21, 2026 have been fully considered but they are not persuasive.
In the remarks applicant argues the prior art references fail to teach “wherein the next screen includes a prompt for the user to provide supporting documentation related to the transaction, the documentation being used to further classify the potential incident and to select one or more additional next screens”, the examiner respectfully disagrees. The prior art reference Matsuoka teaches providing a survey/questionnaire through which the user may provide identifying information for task facilitation server and may prompt the member to provide details information regarding user family, physical location, special needs/requirements and prompt user to specify specific task that the user would like assistance on (para 0047). The prior art teaches prompting user to provide identifying information to identify initial categories of tasks of relevance where the analysis applying clustering algorithms to classify categories of tasks relevant to user input.(para 0048)
In the remarks applicant argues that independent claims 8 and 15 recites similar limitations that are allowable over the prior art references. The examiner respectfully disagrees. See response above, the rejection is maintained.
In the remarks applicant argues that the dependent claims based on the allowable subject matter is the independent claims are allowable over the prior art references. See response above, the rejection is maintained.
Claim Interpretation
With respect to the claim limitation “perform…API calls to one or more integrated transaction backend systems to determine whether the user account is eligible to report the potential incident”, the specification discloses “the intake system may check one or more rules to verify whether one or more tokens have been validated or need to be validated for a current screen of the intake workflow, may check one or more rules to determine whether one or more downstream API calls need to be made to obtain relevant transaction data from the integrated transaction backend systems, may invoke the appropriate API calls when needed, and may check one or more rules to return information indicating a next screen to be presented to a user and/or information to be presented on the next screen.” (¶ 0018); “the intake system may perform one or more API calls to determine whether the user is eligible to report a fraud or dispute claim based on the historical data. For example, in some implementations, the intake system may perform one or more API calls to communicate with a transaction backend system to determine an age of the associated account, a date when an address associated with the account was last updated, a status (e.g., active, inactive, or expired) associated with the account, an issue date associated with the account, and/or a status related to whether there are any existing security reports or fraud cases associated with the account. Accordingly, in some implementations, the
intake system may perform the one or more API calls to determine one or more of these and/or other parameters to verify that the user associated with the account is eligible to report a fraud claim or dispute a transaction. For example, in some implementations, the intake system may determine that the user is ineligible to report the potential incident if the account is less than a threshold number of days (e.g., thirty days) old, and/or if the address was changed within a threshold time period (e.g., the last thirty days). In addition, the intake system may obtain information indicating how frequently the user has historically reported fraudulent transactions or disputed transactions, information indicating whether the user has any existing fraud or dispute cases, information indicating whether the allegedly fraudulent or disputed transaction is a recurring transaction, and/or information indicating whether the allegedly fraudulent or disputed
transaction is a transaction related to an alert that was sent to the user (e.g., based on suspicious activity indicative of potential fraud). (¶ 0021); “For example, when the user reports the incident, the intake system may perform one or more API calls to determine whether the user has a purchase history with the associated merchant, whether
the transaction is a recurring transaction, and/or other suitable information that may relate to purchasing patterns, user activity patterns, and/or other patterns that may indicate whether the potential incident is likely to be a fraud claim or to be a dispute” (¶ 0022); “the intake system may perform one or more API calls (e.g., to check for existing
claims and/or other relevant data) to determine whether the user is eligible to report the incident.” (¶ 0027). The specification discloses the perform API calls to be the retrieving of data/rules relevant to determining user eligible. According in light of the specification, the API calls function is interpreted to be a function to “retrieve” data relevant to eligibility.
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-13 and 15-21 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-7 and 21:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a system, as in independent Claim 1 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 claimed invention is directed to an abstract idea without significantly more. System claim 1 recites functional process 1) receive report request 2) perform API calls to determine user account eligible to report incident 3) classify potential incident 4) selecting workflow to resolve potential incident 5) present initial screen with workflow 6) receive user input 7) present selected next screen associated with workflow.
The claim limitations, when considered as a whole the claimed subject matter is directed toward receiving report request related to “potential incidents” in order to select and present a workflow to resolve the “potential incident” with respect to transactions. The Specification is titled “Customized Intake Handling for Fraudulent and/or Disputed Transaction,” and discloses, in the Background section, that credit card transaction are associated with various risk in the form of fraud, disputes and purchase processes. Where in the case of disputes parties have the right to initiate dispute resolution where the disputed transactions are investigated and apply work process toward resolutions. The specification ¶ 0003, states that the current application is to provide a customized “intake” handling by selecting an intake workflow to resolve potential incidents. Accordingly, the specification makes clear that the focus of the invention is to address transaction risk. Such concepts can be found in the abstract category of risk mitigation a fundamental economic practice a sub-category of the abstract category of Methods of Organizing Human Activity.
Additionally, the claimed limitations which under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic system processor to implement the step and the presenting of a selected screen. That is, other than reciting one or more processors used to perform the recited steps and the presentation of a “initial screen” and “next screen”, nothing in the claim precludes the limitations from being reasonably performed using mental processes. Except for the limitation “perform API calls”, nothing in the claim precludes the limitations from being performed using mental processes. The limitations which mimic mental processes include step 1) and 6) “receiving request” and receive inputs (mental concept of observation), steps 3) – 4) (mental concept of analysis and decision). The steps 5) “present initial screen” and 7) “present next screen” limitations do not improve over manual methods of using pen and paper. Presenting workflow screens is merely applying technology to display selected workflow process which is a process which can reasonably under the category of mental concepts, be performed using pen and paper where a human could draw out an initial workflow and a next workflow to observe. With regard the category of mental processes, according to case law mental processes are not entirely limited to processes within a human mind. MPEP 2106.04(a)(2) The courts do not distinguish between mental processes that are performed entirely in the human mind and mental processes that require a human to use a physical aid (e.g., pen and paper or a slide rule) to perform the claim limitation. See, e.g., Benson, 409 U.S. at 67, 65, 175 USPQ at 674-75, 674 (noting that the claimed "conversion of [binary-coded decimal] numerals to pure binary numerals can be done mentally," i.e., "as a person would do it by head and hand."); Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1139, 120 USPQ2d 1473, 1474 (Fed. Cir. 2016) (holding that claims to a mental process of "translating a functional description of a logic circuit into a hardware component description of the logic circuit" are directed to an abstract idea, because the claims "read on an individual performing the claimed steps mentally or with pencil and paper"). Therefore, the limitations, mimic human thought processes of observation, evaluation and opinion, and communication of result which, where the data interpretation is perceptible only in the human mind. See In re TLl Commc'ns LLC Patent Litig., 823 F.3d 607, 611 (Fed. Cir. 2016); FairWarning IP, LLC v. latric Sys., Inc., 839 F.3d 1089, 1093-94 (Fed. Cir. 2016)
The claim limitations under step 2A prong 1 are directed toward concepts 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) which include the abstract category of mental processes and 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 a system comprising one or more memories, one or more processors coupled to the memories, a user device interface and screen, a communication channel, integrated backend systems, one or more application program interface (API).
The claimed generic system processor is applied to perform the operations of “receive…a request”, “present…an initial screen …”, “receive ….user inputs”, “present …a next screen”, which according to MPEP 2106.05(d) II (see also MPEP 2106.05(g)) are directed toward extra solution activity. The courts have recognized the following computer functions are claimed in a merely generic manner (e.g., at a high level of generality) 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)
The claim limitations (“receive…a request”, “present…an initial screen …”, “receive ….user inputs”, “present …a next screen”) are recited at a high level of generality without details of technical implementation and thus are insignificant extra solution activity.
The additional limitations performed by the generic system processor include “perform API calls to determine account eligible to report incident”, “classify…incident and …data”, “select …workflow”, “select one or more additional next screens… until final outcome” are is recited at a high-level of generality such that it amounts to no more than applying the exception using generic computer components for the purpose of analyzing financial transaction data to mitigate fraud and perform a deposit transaction.
The wherein clause “wherein the user interface entry point is used to report the potential incident” does not further limit the “classify” operation but instead limits the associated interface entry points for reporting the potential incident” which is mere applying the interface to collect data an insignificant extra solution activity.
The wherein clause “wherein the initial screen associated with the intake workflow includes one or more questions to request one or more user inputs that indicate one or more parameters related to the potential incident” does not further limit the initial screen but instead limits the data acted upon.
The additional element “integrated transaction backend system” is merely applied to receive calls from the API and does not perform any operations of the system.
The wherein clause “wherein the intake workflow is portable across a plurality of communication channels, including the particular communication channel”, does not further limit the user interface or the selecting step but instead merely limits the workflow as portable. The claim limitations are silent with respect to any processed tied to the portability of the intake workflow.
The wherein clause “wherein the next screen includes a prompt for the user to provide supporting documentation related to the transaction, the documentation being used to further classify the potential incident and to select one or more additional next screens”, lacks technical disclosure with respect to the screens including a prompt. Furthermore, the prompt is merely applying technology for use in the abstract idea performance.
The wherein clause “wherein the next screen is selected based on mapping the one or more parameters to the next screen based on the historical data and the one or more user inputs” merely limits the selection of the next screen by using data parameters which is merely limiting a selection based on data acted upon rather than technology.
The wherein clause “wherein the system continues to select and present one or more additional next screens every time the intake workflow reaches a decision-making point, until a final outcome is reached” merely limits the selection of the next screen based on workflow reaching a decision until final outcome which is merely limiting a selection based on workflow process upon rather than technology.
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 functions are is recited at a high-level of generality such that it amounts to no more than applying the exception using generic computer components. Taking the claim elements separately, the operation performed by the system at each step of the process is purely in terms of results desired and devoid of implementation of details. This is true with respect to the limitations (1) receiving request, (2) perform API calls, (6) receive user inputs and (5) present (output) initial workflow screen and (7) present (output) next workflow screen, are recited at a high level of generality and thus are insignificant extra solution activity. The classifying limitation (3) is directed toward analyzing transaction data The selecting limitation (4) is being performed by a system processor where the processor performs the selecting at a high level of generality amounting to no more than mere instructions to apply the identified abstract idea using generic computer processors. The claimed processor functions are to generally apply the abstract idea without limiting how the processor functions. The limitations only recite outcomes of “receiving”, “performing API calls”, “classify”, “selecting” and “presenting” without any details about how the outcomes are accomplished as a technical process.
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 a business process of receiving a report request related to a transaction related “potential incident” and performing a API call to retrieve information relevant to determining user associated with an account eligible to report potential incident- insignificant extra solution activity and business process. The combination of limitations 1-2 and 3-4 directed toward classifying potential information data of limitations 1-2 and selecting workflow to resolve incident which is directed toward a business process to mitigate risk. The wherein clause of the ”classify” step does not further limit the classify function. The wherein clause of the select step does not affect the operation of the processor for selecting the workflow as it related to a technical process, but rather the transaction data acted upon that is applied for the selection decision. Therefore, the combination of limitations 1-4 are directed toward a business process for risk mitigation. The combination of limitations 1-4 and 5-7 is directed toward outputting workflow questions and request for user response for a transaction process and receiving user input response and outputting additional workflow processes- a business process using technology to assist a user in addressing a business process.
The combinations of parts is not directed toward any technical process or technological technique or technological solution to a problem rooted in technology. The claim provides no technical details regarding how the processor operations 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)).
Accordingly, 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 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 analyzing data received and outputting the result for dispute resolution, 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 apply technology by using historical data and user input data to select and present a workflow for resolving disputes 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. 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. The additional element “one or more processors” 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 beyond the abstract idea include a system comprising “one or more memories”, “one or more processors coupled to the one or more memories, integrated backend system, user interface, user device, API, the processors to perform the functions of “receive” request, “perform API calls”, “select” workflow, “present” an initial screen, “receive” user inputs and “present” a next screen “selected”. The system processor performing the operations is purely functional and generic. Nearly every system will include “one or more memories” and “one or more processors” capable of performing the basic computer functions of “receive”, “select” and “present” functions required by the claim limitations. A user device with an interface and the system processor to perform API calls. The “API” calls perform are recited at a high level for retrieving data operating in its ordinary capacity and is not sufficient to provide the needed significantly more. Further additional elements include user interface, user device, “one or more integrated transaction backend system”, however the claim limitations nominally mention the integrated transaction backend system and do not provide any operations performed by the backend system. 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 recited limitations do not recite a particular technical process directed toward the technology itself or system applied, instead directed toward the abstract idea itself being implemented using generic technology.
Taking the claim elements separately, the function performed by the system processor at each step of the process is purely conventional. Using a system processors to “receive”, “perform…API calls”, “select” and “present” ----are some of the most basic functions of a system processor. 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. All of these system processor functions are generic, routine, conventional computer activities that are performed only for their conventional uses. See Elec. Power Grp. v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). Also see In re Katz Interactive Call Processing Patent Litigation, 639 F.3d 1303, 1316 (Fed. Cir. 2011) ("Absent a possible narrower construction of the terms “generating”, “transmitting”, “intercepting”, identifying”, “determining”, “replacing” and “routing' ... are functions can be achieved by any general purpose computer without special programming"). None of these activities are used in some unconventional manner nor do any produce some unexpected result. Applicants do not contend they invented any of these activities. In short, each step does no more than require a generic computer to perform generic computer functions.
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:
The specification discloses:
[0029]…Furthermore, as described herein, the intake system may use user answers or responses that are provided during the intake workflow in combination with the historical data, machine learning outputs, or the like to select a next screen at each decision-making point in the intake workflow. In this way, the intake workflow is not bound to any particular sequence of screens or user interfaces, and is dynamically customized to guide the user toward the appropriate resolution. Furthermore, the various screens associated with the intake workflow may be operable with any suitable communication channel, which allows the user to start the incident report in a first communication channel and switch to another channel if needed….
[0054] The number and arrangement of devices and networks shown in Fig. 3 are provided as an example. In practice, there may be additional devices and/or networks, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than those shown in Fig. 3. Furthermore, two or more devices shown in Fig. 3 may be implemented within a single device, or a single device shown in Fig. 3 may be implemented as multiple, distributed devices. Additionally, or alternatively, a set of devices (e.g., one or more devices) of environment 300 may perform one or more functions described as being performed by another set of devices of environment 300.
[0055] Fig. 4 is a diagram of example components of a device 400 associated with customized intake handling for fraudulent and/or disputed transactions. The device 400 may correspond to the user device 310 and/or the intake system 320. In some implementations, the user device 310 and/or the intake system 320 may include one or more devices 400 and/or one or more components of the device 400. As shown in Fig. 4, the device 400 may include a bus 410, a processor 420, a memory 430, an input component 440, an output component 450, and/or a communication component 460.
[0056] The bus 410 may include one or more components that enable wired and/or wireless communication among the components of the device 400. The bus 410 may couple together two or more components of Fig. 4, such as via operative coupling, communicative coupling, electronic coupling, and/or electric coupling. For example, the bus 410 may include an electrical connection (e.g., a wire, a trace, and/or a lead) and/or a wireless bus. The processor 420 may include a central processing unit, a graphics processing unit, a microprocessor, a controller, a microcontroller, a digital signal processor, a field-programmable gate array, an application specific integrated circuit, and/or another type of processing component. The processor 420 may be implemented in hardware, firmware, or a combination of hardware and software. In some implementations, the processor 420 may include one or more processors capable of being programmed to perform one or more operations or processes described elsewhere herein.
[0057] The memory 430 may include volatile and/or nonvolatile memory. For example, the memory 430 may include random access memory (RAM), read only memory (ROM), a hard disk drive, and/or another type of memory (e.g., a flash memory, a magnetic memory, and/or an optical memory). The memory 430 may include internal memory (e.g., RAM, ROM, or a hard disk drive) and/or removable memory (e.g., removable via a universal serial bus connection).
The memory 430 may be a non-transitory computer-readable medium. The memory 430 may store information, one or more instructions, and/or software (e.g., one or more software applications) related to the operation of the device 400. In some implementations, the memory 430 may include one or more memories that are coupled (e.g., communicatively coupled) to one or more processors (e.g., processor 420), such as via the bus 410. Communicative coupling between a processor 420 and a memory 430 may enable the processor 420 to read and/or process information stored in the memory 430 and/or to store information in the memory 430.
[0058] The input component 440 may enable the device 400 to receive input, such as user input and/or sensed input. For example, the input component 440 may include a touch screen, a keyboard, a keypad, a mouse, a button, a microphone, a switch, a sensor, a global positioning system sensor, a global navigation satellite system sensor, an accelerometer, a gyroscope, and/or an actuator. The output component 450 may enable the device 400 to provide output, such as via a display, a speaker, and/or a light-emitting diode. The communication component 460 may enable the device 400 to communicate with other devices via a wired connection and/or a wireless connection. For example, the communication component 460 may include a receiver, a transmitter, a transceiver, a modem, a network interface card, and/or an antenna.
[0059] The device 400 may perform one or more operations or processes described herein. For example, a non-transitory computer-readable medium (e.g., memory 430) may store a set of instructions (e.g., one or more instructions or code) for execution by the processor 420. The processor 420 may execute the set of instructions to perform one or more operations or processes described herein. In some implementations, execution of the set of instructions, by one or more processors 420, causes the one or more processors 420 and/or the device 400 to perform one or more operations or processes described herein. In some implementations, hardwired circuitry
may be used instead of or in combination with the instructions to perform one or more operations or processes described herein. Additionally, or alternatively, the processor 420 may be configured to perform one or more operations or processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
[0060] The number and arrangement of components shown in Fig. 4 are provided as an example. The device 400 may include additional components, fewer components, different components, or differently arranged components than those shown in Fig. 4. Additionally, or alternatively, a set of components (e.g., one or more components) of the device 400 may perform one or more functions described as being performed by another set of components of the device 400.
[0071] When "a processor" or "one or more processors" (or another device or component, such as "a controller" or "one or more controllers") is described or claimed (within a single claim or across multiple claims) as performing multiple operations or being configured to perform multiple operations, this language is intended to broadly cover a variety of processor architectures and environments. For example, unless explicitly claimed otherwise (e.g., via the
use of "first processor" and "second processor" or other language that differentiates processors in the claims), this language is intended to cover a single processor performing or being configured to perform all of the operations, a group of processors collectively performing or being configured to perform all of the operations, a first processor performing or being configured to perform a first operation and a second processor performing or being configured to perform a second operation, or any combination of processors performing or being configured to perform the operations. For example, when a claim has the form "one or more processors configured to: perform X; perform Y; and perform Z," that claim should be interpreted to mean "one or more processors configured to perform X; one or more (possibly different) processors configured to perform Y; and one or more (also possibly different) processors configured to perform Z."
As to the API calls performed, the specification discloses:
[0018]… the intake system may check one or more rules to verify whether one or more tokens have been validated or need to be validated for a current screen of the intake workflow, may check one or more rules to determine whether one or more downstream API calls need to be made to obtain relevant transaction data from the integrated transaction backend systems, may invoke the appropriate API calls when needed, and may check one or more rules to return information indicating a next screen to be presented to a user and/or information to be presented on the next screen…
[0021] As further shown in Fig. IA, and by reference number 110, the intake system may determine an incident type and select an appropriate intake workflow based on historical incident data associated with the user and/or other users and/or based on the entry point associated with the request to report the potential incident ( e.g., the communication channel used to report the potential incident and/or the user interface screen or option used to report the potential incident). For example, in some implementations, prior to selecting an intake workflow to initiate a fraud
or dispute resolution process associated with the reported incident, the intake system may perform one or more API calls to determine whether the user is eligible to report a fraud or dispute claim based on the historical data. For example, in some implementations, the intake system may perform one or more API calls to communicate with a transaction backend system to determine an age of the associated account, a date when an address associated with the account was last updated, a status (e.g., active, inactive, or expired) associated with the account, an issue
date associated with the account, and/or a status related to whether there are any existing security reports or fraud cases associated with the account. Accordingly, in some implementations, the intake system may perform the one or more API calls to determine one or more of these and/or other parameters to verify that the user associated with the account is eligible to report a fraud claim or dispute a transaction. For example, in some implementations, the intake system may determine that the user is ineligible to report the potential incident if the account is less than a threshold number of days (e.g., thirty days) old, and/or if the address was changed within a threshold time period (e.g., the last thirty days). …
[0022]… For example, when the user reports the incident, the intake system may perform one or more API calls to determine whether the user has a purchase history with the associated merchant, whether the transaction is a recurring transaction, and/or other suitable information that may relate to purchasing patterns, user activity patterns, and/or other patterns that may indicate whether the potential incident is likely to be a fraud claim or to be a dispute…
[0027]… As shown by reference number 150, in cases where the user selects the option to report or request help with the transaction, the intake system may perform one or more API calls (e.g., to check for existing claims and/or other relevant data) to determine whether the user is eligible to report the incident. In some implementations, in cases where the user is determined to be eligible to report the incident, the intake system may present a transaction review screen to the user to solicit more information about the transaction. …
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-7 and 21 these dependent claim have also been reviewed with the same analysis as independent claim 1. Dependent claim 2 is directed toward limiting the data acted upon with respect to the intake workflow used to report a potential incident – non-functional descriptive subject matter applied for a business process. Dependent claim 3 is directed toward displaying a reactive message in response to user input-outputting data -insignificant extra solution activity. Dependent claim 4 is directed toward presenting the initial screen to report an incident - outputting data -insignificant extra solution activity. Dependent claim 5 is directed toward presenting a final screen associated with workflow with informational message based on user inputs-outputting result insignificant extra solution activity. Dependent claim 6 is directed toward selecting workflow using a Machine learning model- directed toward a business practice with trivial mention of machine learning being applied as a tool. Dependent claim 7 is directed toward a user interface entry point associated with user interface channel and initial or second screen associated with second user interface channel- applying technology for data reception and outputting data on a screen-well understood and conventional application of technology for a data entry and output. Dependent claim 21 is directed toward classifying potential incident as a fraud claim and classify potential incident as a dispute claim…- directed toward 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-7 and 21 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 8-13:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a method, as in independent Claim 8 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 8 recites steps including 1) receiving report request 2) performing API calls to retrieve data 3) classifying potential incident 4) selecting workflow to resolve potential incident 5) presenting initial screen with workflow 6) presenting selected next screen associated with workflow 6) presenting a final screen.
The claim limitations, when considered as a whole the claimed subject matter is directed toward receiving report request related to “potential incidents” in order to select and present a workflow to resolve the “potential incident” with respect to transactions. The Specification is titled “Customized Intake Handling for Fraudulent and/or Disputed Transaction,” and discloses, in the Background section, that credit card transaction are associated with various risk in the form of fraud, disputes and purchase processes. Where in the case of disputes parties have the right to initiate dispute resolution where the disputed transactions are investigated and apply work process toward resolutions. The specification ¶ 0003, states that the current application is to provide a customized “intake” handling by selecting an intake workflow to resolve potential incidents. Accordingly, the specification makes clear that the focus of the invention is to address transaction risk. Such concepts can be found in the abstract category of risk mitigation a fundamental economic practice a sub-category of the abstract category of Methods of Organizing Human Activity.
The claimed limitations which under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic system processor to implement the step and the presenting of a selected screen. That is, other than reciting “by the intake system” used to perform the recited steps and the presentation of a “initial screen”, “next screen” and “final screen”, nothing in the claim precludes the limitations from being reasonably performed using mental processes. The limitations which mimic mental processes include step 1) “receiving request” and 2) “perform API calls (mental concept of observation), steps 3) “classifying potential incident 4) “selecting workflow” (mental concept of analysis and decision). The steps 5) “present initial screen”, 6) presenting next screen and 7) “presenting final screen” limitations do not improve over manual methods of using pen and paper. Presenting workflow screens is merely applying technology to display selected workflow process which is a process which can reasonably under the category of mental concepts, be performed using pen and paper where a human could draw out an initial workflow, next workflow and a final workflow to observe. With regard the category of mental processes, according to case law mental processes are not entirely limited to processes within a human mind. MPEP 2106.04(a)(2) The courts do not distinguish between mental processes that are performed entirely in the human mind and mental processes that require a human to use a physical aid (e.g., pen and paper or a slide rule) to perform the claim limitation. See, e.g., Benson, 409 U.S. at 67, 65, 175 USPQ at 674-75, 674 (noting that the claimed "conversion of [binary-coded decimal] numerals to pure binary numerals can be done mentally," i.e., "as a person would do it by head and hand."); Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1139, 120 USPQ2d 1473, 1474 (Fed. Cir. 2016) (holding that claims to a mental process of "translating a functional description of a logic circuit into a hardware component description of the logic circuit" are directed to an abstract idea, because the claims "read on an individual performing the claimed steps mentally or with pencil and paper"). Therefore, the limitations, mimic human thought processes of observation, evaluation and opinion, and communication of result which, where the data interpretation is perceptible only in the human mind. See In re TLl Commc'ns LLC Patent Litig., 823 F.3d 607, 611 (Fed. Cir. 2016); FairWarning IP, LLC v. latric Sys., Inc., 839 F.3d 1089, 1093-94 (Fed. Cir. 2016)
The claim limitations under step 2A prong 1 are directed toward concepts 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) which include the abstract category of mental processes and methods of organizing human activity.
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 a system, a user device, user interface entry point, communication channel, API and screen, a communication channel, integrated transaction backend systems, one or more application program interface (API).
The claimed generic system interface entry point associate with a communication channel is applied to perform the steps of the method of “receiving…a request”, which according to MPEP 2106.05(d) II (see also MPEP 2106.05(g)) are directed toward extra solution activity.
The claimed system is applied to perform the steps of “presenting…an initial screen …” and “presenting …a next screen”, which according to MPEP 2106.05(d) II (see also MPEP 2106.05(g)) are directed toward extra solution activity.
The courts have recognized the following computer functions are claimed in a merely generic manner (e.g., at a high level of generality) 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)
The claim limitations (“receiving…a request”, “presenting…an initial screen …”, “presenting …a next screen”) are recited at a high level of generality without details of technical implementation and thus are insignificant extra solution activity.
The additional limitations performed by the generic system applying one or more API calls to perform the step “to determine account eligible to report incident” and the system applied to perform the steps of “classifying…incident and …data”, “selecting a …workflow”, “select next screen” and “select one or more additional next screens until decision and final outcome reached” which are is recited at a high-level of generality such that it amounts to no more than applying the exception using generic computer components for the purpose of analyzing financial transaction data to mitigate fraud and perform a deposit transaction.
The additional element “integrated transaction backend system” is merely applied to receive calls from the API and does not perform any operations of the system.
The wherein clause “wherein the intake workflow is portable across a plurality of communication channels, including the particular communication channel”, does not further limit the user interface or the selecting step but instead merely limits the workflow as portable. The claim limitations are silent with respect to any processed tied to the portability of the intake workflow.
The wherein clause “wherein the next screen includes a prompt for the user to provide supporting documentation related to the transaction, the documentation being used to further classify the potential incident and to select one or more additional next screens”, lacks technical disclosure with respect to the screens including a prompt. Furthermore, the prompt is merely applying technology for use in the abstract idea performance.
The wherein clause “wherein the user interface entry point is used to report the potential incident” does not further limit the “classify” operation but instead limits the associated interface entry points for reporting the potential incident” which is mere applying the interface to collect data an insignificant extra solution activity.
The wherein clause “wherein the initial screen associated with the intake workflow includes one or more questions to request one or more user inputs that indicate one or more parameters related to the potential incident” does not further limit the initial screen but instead limits the data acted upon.
The wherein clause “wherein the next screen is selected based on mapping the one or more parameters to the next screen based on the historical data and the one or more user inputs” merely limits the selection of the next screen by using data parameters which is merely limiting a selection based on data acted upon rather than technology.
The wherein clause “wherein the system continues to select and present one or more additional next screens every time the intake workflow reaches a decision-making point, until a final outcome is reached” merely limits the selection of the next screen based on workflow reaching a decision until final outcome which is merely limiting a selection based on workflow process upon rather than technology.
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 steps are recited at a high-level of generality such that it amounts to no more than applying the exception using generic computer components. Taking the claim elements separately, the operation performed by the intake system at each step of the process is purely in terms of results desired and devoid of implementation of details. This is true with respect to the limitations (1) receiving request (2) performing API calls and (4) present (output) initial workflow screen (5) present (output) next workflow screen and (6) present (output) final workflow screen, are recited at a high level of generality and thus are insignificant extra solution activity. The classifying potential incident (3) and selecting limitation (4) is being performed by the intake system where the system performs the analyzing, organizing data and selecting workflow at a high level of generality amounting to no more than mere instructions to apply the identified abstract idea using generic intake system. The claimed system functions are to generally apply the abstract idea without limiting how the system performs the steps. The limitations only recite outcomes of “receiving”, “performing API calls”, “classifying” data, “selecting” and “presenting” without any details about how the outcomes are accomplished as a technical process. 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 a business process of receiving a report request related to a transaction related “potential incident” and performing a API call to retrieve information relevant to determining user associated with an account eligible to report potential incident- insignificant extra solution activity and business process. The combination of limitations 1-2 and 3-4 directed toward classifying potential information data of limitations 1-2 and selecting workflow to resolve incident which is directed toward a business process to mitigate risk. The wherein clause of the ”classify” step does not further limit the classify function. The wherein clause of the select step does not affect the operation of the processor for selecting the workflow as it related to a technical process, but rather the transaction data acted upon that is applied for the selection decision. Therefore, the combination of limitations 1-4 are directed toward a business process for risk mitigation. The combination of limitations 1-4 and 5-7 are directed toward a business process of presenting a next workflow screen and final workflow screen (i.e. outputting the result). The wherein clause does not affect the operation of the intake system for selecting the workflow as it related to a technical process, but rather the transaction data acted upon that is applied for the selection decision. The data that is applied to selection process is the data of step 3-5 is historical data and user parameter inputs of steps 1-3. The combinations of parts is not directed toward any technical process or technological technique or technological solution to a problem rooted in technology. The claim provides no technical details regarding how the processor operations 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)).
Accordingly, 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 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 analyzing data received and outputting the result for dispute resolution, 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 apply technology by using historical data and user input data to select and present a workflow for resolving disputes 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. 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. The additional element “one or more processors” 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 beyond the abstract idea include an intake system to perform the functions of “receiving” request, “performing API calls”, “classifying potential incident”, “selecting” workflow, “presenting” an initial screen, “presenting” a next screen “selected” and to “presenting” a final screen. Further additional elements include user interface, user device, “one or more integrated transaction backend system”, however the claim limitations nominally mention the integrated transaction backend system and do not provide any operations performed by the backend system. The system performing the operations is purely functional and generic. Nearly every system is capable of performing the basic computer functions of “receive”, “perform API calls”, “classify”, “select” and “present” steeps required by the claim limitations. As a result, the system claimed fails to offer a meaningful limitation beyond generally linking the use of the method to a particular technological environment, that is, implementation via computers.
Taking the claim elements separately, the function performed by the system processor at each step of the process is purely conventional. Using a system to “receive”, “select” and “present” ----are some of the most basic functions of a system processor. 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. All of these system processor functions are generic, routine, conventional computer activities that are performed only for their conventional uses. See Elec. Power Grp. v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). Also see In re Katz Interactive Call Processing Patent Litigation, 639 F.3d 1303, 1316 (Fed. Cir. 2011) ("Absent a possible narrower construction of the terms “generating”, “transmitting”, “intercepting”, identifying”, “determining”, “replacing” and “routing' ... are functions can be achieved by any general purpose computer without special programming"). None of these activities are used in some unconventional manner nor do any produce some unexpected result. Applicants do not contend they invented any of these activities. In short, each step does no more than require a generic computer to perform generic computer functions.
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:
The specification discloses:
[0029]…Furthermore, as described herein, the intake system may use user answers or responses that are provided during the intake workflow in combination with the historical data, machine learning outputs, or the like to select a next screen at each decision-making point in the intake workflow. In this way, the intake workflow is not bound to any particular sequence of screens or user interfaces, and is dynamically customized to guide the user toward the appropriate resolution. Furthermore, the various screens associated with the intake workflow may be operable with any suitable communication channel, which allows the user to start the incident report in a first communication channel and switch to another channel if needed….
[0054] The number and arrangement of devices and networks shown in Fig. 3 are provided as an example. In practice, there may be additional devices and/or networks, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than those shown in Fig. 3. Furthermore, two or more devices shown in Fig. 3 may be implemented within a single device, or a single device shown in Fig. 3 may be implemented as multiple, distributed devices. Additionally, or alternatively, a set of devices (e.g., one or more devices) of environment 300 may perform one or more functions described as being performed by another set of devices of environment 300.
[0055] Fig. 4 is a diagram of example components of a device 400 associated with customized intake handling for fraudulent and/or disputed transactions. The device 400 may correspond to the user device 310 and/or the intake system 320. In some implementations, the user device 310 and/or the intake system 320 may include one or more devices 400 and/or one or more components of the device 400. As shown in Fig. 4, the device 400 may include a bus 410, a processor 420, a memory 430, an input component 440, an output component 450, and/or a communication component 460.
[0056] The bus 410 may include one or more components that enable wired and/or wireless communication among the components of the device 400. The bus 410 may couple together two or more components of Fig. 4, such as via operative coupling, communicative coupling, electronic coupling, and/or electric coupling. For example, the bus 410 may include an electrical connection (e.g., a wire, a trace, and/or a lead) and/or a wireless bus. The processor 420 may include a central processing unit, a graphics processing unit, a microprocessor, a controller, a microcontroller, a digital signal processor, a field-programmable gate array, an application specific integrated circuit, and/or another type of processing component. The processor 420 may be implemented in hardware, firmware, or a combination of hardware and software. In some implementations, the processor 420 may include one or more processors capable of being programmed to perform one or more operations or processes described elsewhere herein.
[0057] The memory 430 may include volatile and/or nonvolatile memory. For example, the memory 430 may include random access memory (RAM), read only memory (ROM), a hard disk drive, and/or another type of memory (e.g., a flash memory, a magnetic memory, and/or an optical memory). The memory 430 may include internal memory (e.g., RAM, ROM, or a hard disk drive) and/or removable memory (e.g., removable via a universal serial bus connection).
The memory 430 may be a non-transitory computer-readable medium. The memory 430 may store information, one or more instructions, and/or software (e.g., one or more software applications) related to the operation of the device 400. In some implementations, the memory 430 may include one or more memories that are coupled (e.g., communicatively coupled) to one or more processors (e.g., processor 420), such as via the bus 410. Communicative coupling between a processor 420 and a memory 430 may enable the processor 420 to read and/or process information stored in the memory 430 and/or to store information in the memory 430.
[0058] The input component 440 may enable the device 400 to receive input, such as user input and/or sensed input. For example, the input component 440 may include a touch screen, a keyboard, a keypad, a mouse, a button, a microphone, a switch, a sensor, a global positioning system sensor, a global navigation satellite system sensor, an accelerometer, a gyroscope, and/or an actuator. The output component 450 may enable the device 400 to provide output, such as via a display, a speaker, and/or a light-emitting diode. The communication component 460 may enable the device 400 to communicate with other devices via a wired connection and/or a wireless connection. For example, the communication component 460 may include a receiver, a transmitter, a transceiver, a modem, a network interface card, and/or an antenna.
[0059] The device 400 may perform one or more operations or processes described herein. For example, a non-transitory computer-readable medium (e.g., memory 430) may store a set of instructions (e.g., one or more instructions or code) for execution by the processor 420. The processor 420 may execute the set of instructions to perform one or more operations or processes described herein. In some implementations, execution of the set of instructions, by one or more processors 420, causes the one or more processors 420 and/or the device 400 to perform one or more operations or processes described herein. In some implementations, hardwired circuitry
may be used instead of or in combination with the instructions to perform one or more operations or processes described herein. Additionally, or alternatively, the processor 420 may be configured to perform one or more operations or processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
[0060] The number and arrangement of components shown in Fig. 4 are provided as an example. The device 400 may include additional components, fewer components, different components, or differently arranged components than those shown in Fig. 4. Additionally, or alternatively, a set of components (e.g., one or more components) of the device 400 may perform one or more functions described as being performed by another set of components of the device 400.
[0071] When "a processor" or "one or more processors" (or another device or component, such as "a controller" or "one or more controllers") is described or claimed (within a single claim or across multiple claims) as performing multiple operations or being configured to perform multiple operations, this language is intended to broadly cover a variety of processor architectures and environments. For example, unless explicitly claimed otherwise (e.g., via the
use of "first processor" and "second processor" or other language that differentiates processors in the claims), this language is intended to cover a single processor performing or being configured to perform all of the operations, a group of processors collectively performing or being configured to perform all of the operations, a first processor performing or being configured to perform a first operation and a second processor performing or being configured to perform a second operation, or any combination of processors performing or being configured to perform the operations. For example, when a claim has the form "one or more processors configured to: perform X; perform Y; and perform Z," that claim should be interpreted to mean "one or more processors configured to perform X; one or more (possibly different) processors configured to perform Y; and one or more (also possibly different) processors configured to perform Z."
As to the API calls performed, the specification discloses:
[0018]… the intake system may check one or more rules to verify whether one or more tokens have been validated or need to be validated for a current screen of the intake workflow, may check one or more rules to determine whether one or more downstream API calls need to be made to obtain relevant transaction data from the integrated transaction backend systems, may invoke the appropriate API calls when needed, and may check one or more rules to return information indicating a next screen to be presented to a user and/or information to be presented on the next screen…
[0021] As further shown in Fig. IA, and by reference number 110, the intake system may determine an incident type and select an appropriate intake workflow based on historical incident data associated with the user and/or other users and/or based on the entry point associated with the request to report the potential incident ( e.g., the communication channel used to report the potential incident and/or the user interface screen or option used to report the potential incident). For example, in some implementations, prior to selecting an intake workflow to initiate a fraud
or dispute resolution process associated with the reported incident, the intake system may perform one or more API calls to determine whether the user is eligible to report a fraud or dispute claim based on the historical data. For example, in some implementations, the intake system may perform one or more API calls to communicate with a transaction backend system to determine an age of the associated account, a date when an address associated with the account was last updated, a status (e.g., active, inactive, or expired) associated with the account, an issue
date associated with the account, and/or a status related to whether there are any existing security reports or fraud cases associated with the account. Accordingly, in some implementations, the intake system may perform the one or more API calls to determine one or more of these and/or other parameters to verify that the user associated with the account is eligible to report a fraud claim or dispute a transaction. For example, in some implementations, the intake system may determine that the user is ineligible to report the potential incident if the account is less than a threshold number of days (e.g., thirty days) old, and/or if the address was changed within a threshold time period (e.g., the last thirty days). …
[0022]… For example, when the user reports the incident, the intake system may perform one or more API calls to determine whether the user has a purchase history with the associated merchant, whether the transaction is a recurring transaction, and/or other suitable information that may relate to purchasing patterns, user activity patterns, and/or other patterns that may indicate whether the potential incident is likely to be a fraud claim or to be a dispute…
[0027]… As shown by reference number 150, in cases where the user selects the option to report or request help with the transaction, the intake system may perform one or more API calls (e.g., to check for existing claims and/or other relevant data) to determine whether the user is eligible to report the incident. In some implementations, in cases where the user is determined to be eligible to report the incident, the intake system may present a transaction review screen to the user to solicit more information about the transaction. …
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 9-13 these dependent claim have also been reviewed with the same analysis as independent claim 8. Dependent claim 9 is directed toward limiting the data acted upon with respect to the intake workflow used to report a potential incident – non-functional descriptive subject matter applied for a business process. Dependent claim 10 is directed toward based on account eligibility displaying a reactive message in response to user input-outputting data -insignificant extra solution activity. Dependent claim 11 is directed toward presenting the initial screen to report an incident - outputting data -insignificant extra solution activity. Dependent claim 12 is directed toward presenting steps to resolve the potential incident or instruction message with directions to resolve the incident-outputting result insignificant extra solution activity and risk mitigation. Dependent claim 13 is directed toward selecting workflow using a Machine learning model- directed toward a business practice with trivial mention of machine learning being applied as a tool.
The dependent claim(s) have been examined individually and in combination with the preceding claims, however they do not cure the deficiencies of claim 8. 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 9-13 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 non-transitory computer readable medium storing instructions, as in independent Claim 15 and the dependent claims. Such mediums fall under the statutory category of "manufacture." 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. Medium claim 15 recites functional process 1) receive report request 2) performing API calls to retrieve data 3) classifying potential incident 4) selecting workflow to resolve potential incident 5) present initial screen with workflow 6) present selected next screen associated with workflow using a machine learning model. The claimed limitations which under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic processor to implement the step and the presenting of a selected screen and selected workflow using machine learning model. That is, other than reciting “one or more instructions …executed by one or more processors” and “using machine learning model” used to perform the recited steps and the presentation of a “initial screen” and “next screen”, nothing in the claim precludes the limitations from being reasonably performed using mental processes. The limitations which mimic mental processes include step 1) “receiving request” and 2) “perform API calls (mental concept of observation), steps 3) “classifying potential incident 4) “selecting workflow” (mental concept of analysis and decision).. The steps 3) “present initial screen” and 4) “present next screen” limitations do not improve over manual methods of using pen and paper.
Furthermore, when considered as a whole the claimed subject matter is directed toward receiving report request related to “potential incidents” in order to select and present a workflow to resolve the “potential incident” with respect to transactions. The Specification is titled “Customized Intake Handling for Fraudulent and/or Disputed Transaction,” and discloses, in the Background section, that credit card transaction are associated with various risk in the form of fraud, disputes and purchase processes. Where in the case of disputes parties have the right to initiate dispute resolution where the disputed transactions are investigated and apply work process toward resolutions. The specification ¶ 0003, states that the current application is to provide a customized “intake” handling by selecting an intake workflow to resolve potential incidents. Accordingly, the specification makes clear that the focus of the invention is to address transaction risk. Such concepts can be found in the abstract category of risk mitigation a fundamental economic practice a sub-category of the abstract category of Methods of Organizing Human Activity.
Presenting workflow screens is merely applying technology to display selected workflow process which is a process which can reasonably under the category of mental concepts, be performed using pen and paper where a human could draw out an initial workflow and a next workflow to observe. With regard the category of mental processes, according to case law mental processes are not entirely limited to processes within a human mind. MPEP 2106.04(a)(2) The courts do not distinguish between mental processes that are performed entirely in the human mind and mental processes that require a human to use a physical aid (e.g., pen and paper or a slide rule) to perform the claim limitation. See, e.g., Benson, 409 U.S. at 67, 65, 175 USPQ at 674-75, 674 (noting that the claimed "conversion of [binary-coded decimal] numerals to pure binary numerals can be done mentally," i.e., "as a person would do it by head and hand."); Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1139, 120 USPQ2d 1473, 1474 (Fed. Cir. 2016) (holding that claims to a mental process of "translating a functional description of a logic circuit into a hardware component description of the logic circuit" are directed to an abstract idea, because the claims "read on an individual performing the claimed steps mentally or with pencil and paper"). Therefore, the limitations, mimic human thought processes of observation, evaluation and opinion, and communication of result which, where the data interpretation is perceptible only in the human mind. See In re TLl Commc'ns LLC Patent Litig., 823 F.3d 607, 611 (Fed. Cir. 2016); FairWarning IP, LLC v. latric Sys., Inc., 839 F.3d 1089, 1093-94 (Fed. Cir. 2016)
The claim limitations under step 2A prong 1 are directed toward concepts 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) which include the abstract category of mental processes and 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 a non-transitory computer readable medium storing instructions, one or more processors of an intake system, an intake system, user device , user interface, integrated backend systems, one or more application program interface (API).
The identified judicial exception is not integrated into a practical application because the claims recite a process by a “one or more processors” to (1) receive report request-mere data transmission-insignificant extra solution activity 2) performing API calls to retrieve data-insignificant extra solution activity 3) classifying potential incident – a business process for risk mitigation 4) selecting workflow to resolve potential incident- directed toward a business process to select a workflow to resolve an incident to mitigate risk 5) present initial screen with workflow-outputting result-insignificant extra solution activity 6) present selected next screen associated with workflow insignificant extra solution activity.
The functions are is recited at a high-level of generality such that it amounts to no more than applying the exception using generic computer components. Taking the claim elements separately, the operation performed by the system at each step of the process is purely in terms of results desired and devoid of implementation of details. This is true with respect to the limitations (1) receiving request (2) perform API calls and (3) present (output) initial workflow screen and (4) present (output) next workflow screen, are recited at a high level of generality and thus are insignificant extra solution activity. The classifying potential incident (2) selecting limitation (3) is being performed by a system processor where the processor performs the selecting at a high level of generality amounting to no more than mere instructions to apply the identified abstract idea using generic computer processors. The claimed processor functions are to generally apply the abstract idea without limiting how the processor functions. The limitations only recite outcomes of “receiving”, “performing calls”, “classifying”, “selecting” and “presenting” without any details about how the outcomes are accomplished as a technical process. 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 a business process of receiving a report request related to a transaction related “potential incident” and performing a API call to retrieve information relevant to determining user associated with an account eligible to report potential incident- insignificant extra solution activity and business process. The combination of limitations 1-2 and 3-4 directed toward classifying potential information data of limitations 1-2 and selecting workflow to resolve incident which is directed toward a business process to mitigate risk. The wherein clause of the ”classify” step does not further limit the classify function. The wherein clause of the select step does not affect the operation of the processor for selecting the workflow as it related to a technical process, but rather the transaction data acted upon that is applied for the selection decision. Therefore, the combination of limitations 1-4 are directed toward a business process for risk mitigation. The combination of limitations 5 are directed toward a business process of selecting a next workflow screen and then outputting the result. The wherein clause does not affect the operation of the processor for selecting the workflow as it related to a technical process, but rather the transaction data acted upon that is applied for the selection decision. The data that is applied to selection process is the data of step 5 is historical data and user parameter inputs of steps 1-4. The combinations of parts is not directed toward any technical process or technological technique or technological solution to a problem rooted in technology. The claim provides no technical details regarding how the processor operations 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 additional element “integrated transaction backend system” is merely applied to receive calls from the API and does not perform any operations of the system.
The wherein clause “wherein the intake workflow is portable across a plurality of communication channels, including the particular communication channel”, does not further limit the user interface or the selecting step but instead merely limits the workflow as portable. The claim limitations are silent with respect to any processed tied to the portability of the intake workflow.
The wherein clause “wherein the next screen includes a prompt for the user to provide supporting documentation related to the transaction, the documentation being used to further classify the potential incident and to select one or more additional next screens”, lacks technical disclosure with respect to the screens including a prompt. Furthermore, the prompt is merely applying technology for use in the abstract idea performance.
Accordingly, 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 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 analyzing data received and outputting the result for dispute resolution, 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 apply technology by using historical data and user input data to select and present a workflow for resolving disputes 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. 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. The additional element “one or more processors” 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 beyond the abstract idea include a non-transitory computer-readable medium storing a set of instructions comprising instruction executed by “one or more processors”, the processors to perform the functions of “receive” request, “select” workflow, “present” an initial screen, and “present” a next screen “selected”. The one or more processors performing the operations is purely functional and generic. Nearly every “one or more processors” executing instructions is capable of performing the basic computer functions of “receive”, “perform API calls”, “classify” “select” and “present” functions required by the claim limitations. The limitation “intake workflow …selected using a machine learning model” lacks technical description and is merely trivial mention amount to no more than mere instructions to select a workflow. As a result, none of the hardware/instructions recited by the medium claims offers a meaningful limitation beyond generally linking the use of the instructions to a particular technological environment, that is, implementation via one or more processors.
Taking the claim elements separately, the function performed by the one or more processor at each step of the process is purely conventional. Using “one or more processors” to “receive”, “perform API calls”, “classify”, “select” and “present” ----are some of the most basic functions of processors. 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. All of these processor functions are generic, routine, conventional computer activities that are performed only for their conventional uses. See Elec. Power Grp. v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). Also see In re Katz Interactive Call Processing Patent Litigation, 639 F.3d 1303, 1316 (Fed. Cir. 2011) ("Absent a possible narrower construction of the terms “generating”, “transmitting”, “intercepting”, identifying”, “determining”, “replacing” and “routing' ... are functions can be achieved by any general purpose computer without special programming"). None of these activities are used in some unconventional manner nor do any produce some unexpected result. Applicants do not contend they invented any of these activities. In short, each step does no more than require a generic computer to perform generic computer functions.
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:
A Beauregard claim named after In re Beauregard, 53 F.3d 1583 (Fed.Cir.1995) is a claim to a computer readable medium (e.g., a disk, hard drive, or other data storage device) containing program instructions for a computer to perform a particular process.
In connection with the Beauregard claim, the Federal Circuit held that even though the claim is directed to a manufacture, the claim is not "truly drawn to a specific" computer readable medium, but rather is directed toward the method of detecting credit card fraud over the Internet. Simply reciting the use of a computer to execute an algorithm that can be performed entirely in the human mind will not change the analysis. The Beauregard claim was then treated as a method claim. This current claim limitations is determined not to meet the Alice/May 2A and 2B test. Although the claim applies data, to present workflow, according to Beauregard, "[t]he mere manipulation or reorganization of data, however, does not satisfy the transformation prong." Furthermore, the "incidental use" of a computer did not allow the claim to meet the Alice 2A or 2B requirements. The court noted that even though the method may require the use of a computer, methods that can be performed mentally, or which are the equivalent of human mental work, are unpatentable abstract ideas "even when performed by a computer" has not met its burden to demonstrate that claim 2 is "truly drawn to a specific" computer readable medium, rather than to the underlying method of credit card fraud detection.
In Beauregard, after Abele, the court held that, as a general matter, programming a general purpose computer to perform an algorithm "creates a new machine, because a general purpose computer in effect becomes a special purpose computer once it is programmed to perform particular functions pursuant to instructions from program software." In re Alappat, 33 F.3d 1526, 1545 (Fed.Cir. 1994). But we have never suggested that simply reciting the use of a computer to execute an algorithm that can be performed entirely in the human mind falls within the Alappat rule. Thus, despite its Beauregard claim format, under Abele, we treat claim 2 as a process claim for patent-eligibility purposes.
The specification discloses:
[0005] Some implementations described herein relate to a non-transitory computer-readable medium that stores a set of instructions. The set of instructions, when executed by one or more processors of an intake system, may cause the intake system to receive, from a user device, a request to report a potential incident related to a transaction associated with a user account. The set of instructions, when executed by one or more processors of the intake system, may cause the intake system to select an intake workflow to resolve the potential incident based on historical
data associated with the user account and information associated with a user interface entry point used to report the potential incident. The set of instructions, when executed by one or more processors of the intake system, may cause the intake system to present, to the user device, an initial screen associated with the intake workflow, wherein the initial screen associated with the intake workflow includes one or more questions to request one or more user inputs that indicate one or more parameters related to the potential incident. The set of instructions, when executed
by one or more processors of the intake system, may cause the intake system to present, to the user device, a next screen associated with the intake workflow, wherein the next screen is selected based on the historical data associated with the user account and the one or more user inputs that indicate the one or more parameters related to the potential incident, and wherein one or more of the intake workflow or the next screen associated with the intake workflow are selected using a machine learning model.
[0057] The memory 430 may include volatile and/or nonvolatile memory. For example, the memory 430 may include random access memory (RAM), read only memory (ROM), a hard disk drive, and/or another type of memory (e.g., a flash memory, a magnetic memory, and/or an optical memory). The memory 430 may include internal memory (e.g., RAM, ROM, or a hard disk drive) and/or removable memory (e.g., removable via a universal serial bus connection).
The memory 430 may be a non-transitory computer-readable medium. The memory 430 may store information, one or more instructions, and/or software (e.g., one or more software applications) related to the operation of the device 400. In some implementations, the memory 430 may include one or more memories that are coupled (e.g., communicatively coupled) to one or more processors (e.g., processor 420), such as via the bus 410. Communicative coupling between a processor 420 and a memory 430 may enable the processor 420 to read and/or process information stored in the memory 430 and/or to store information in the memory 430.
[0059] The device 400 may perform one or more operations or processes described herein. For example, a non-transitory computer-readable medium (e.g., memory 430) may store a set of instructions (e.g., one or more instructions or code) for execution by the processor 420. The processor 420 may execute the set of instructions to perform one or more operations or processes described herein. In some implementations, execution of the set of instructions, by one or more processors 420, causes the one or more processors 420 and/or the device 400 to perform one or more operations or processes described herein. In some implementations, hardwired circuitry
may be used instead of or in combination with the instructions to perform one or more operations or processes described herein. Additionally, or alternatively, the processor 420 may be configured to perform one or more operations or processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
[0060] The number and arrangement of components shown in Fig. 4 are provided as an example. The device 400 may include additional components, fewer components, different components, or differently arranged components than those shown in Fig. 4. Additionally, or alternatively, a set of components (e.g., one or more components) of the device 400 may perform one or more functions described as being performed by another set of components of the device 400.
[0071] When "a processor" or "one or more processors" (or another device or component, such as "a controller" or "one or more controllers") is described or claimed (within a single claim or across multiple claims) as performing multiple operations or being configured to perform multiple operations, this language is intended to broadly cover a variety of processor architectures and environments. For example, unless explicitly claimed otherwise (e.g., via the
use of "first processor" and "second processor" or other language that differentiates processors in the claims), this language is intended to cover a single processor performing or being configured to perform all of the operations, a group of processors collectively performing or being configured to perform all of the operations, a first processor performing or being configured to perform a first operation and a second processor performing or being configured to perform a second operation, or any combination of processors performing or being configured to perform the operations. For example, when a claim has the form "one or more processors configured to: perform X; perform Y; and perform Z," that claim should be interpreted to mean "one or more processors configured to perform X; one or more (possibly different) processors configured to perform Y; and one or more (also possibly different) processors configured to perform Z."
With respect to the language “using a machine learning model”, the claim limitations lack technical description. The specification provides a laundry list of possible algorithms that could be applied without any technical details and discloses at a high level as it relates to use, that the ML model can be “used” for observation and decision and “trained” to select workflows that can be presented.(para 0005, 0021, 0022, 0024, 0029 )
[0031] Fig. 2 is a diagram illustrating an example 200 of training and using a machine learning model in connection with customized intake handling for fraudulent and/or disputed transactions, in accordance with some embodiments of the present disclosure. The machine learning model training and usage described herein may be performed using a machine learning system. The machine learning system may include or may be included in a computing device, a server, a cloud computing environment, or the like, such as the intake system described in more detail elsewhere herein.
[0032] As shown by reference number 205, a machine learning model may be trained using a set of observations. The set of observations may be obtained from training data (e.g., historical data), such as data gathered during one or more processes described herein. In some implementations, the machine learning system may receive the set of observations (e.g., as input) from the intake system, a transaction backend system, a transaction data repository, and/or another suitable data source, as described elsewhere herein.
[0033] As shown by reference number 210, the set of observations may include a feature set. The feature set may include a set of variables, and a variable may be referred to as a feature. A specific observation may include a set of variable values ( or feature values) corresponding to the set of variables. In some implementations, the machine learning system may determine variables for a set of observations and/or variable values for a specific observation based on input received from the intake system, a transaction backend system, a transaction data repository, and/or
another suitable data source. For example, the machine learning system may identify a feature set (e.g., one or more features and/or feature values) by extracting the feature set from structured data, by performing natural language processing to extract the feature set from unstructured data, and/or by receiving input from an operator.
[0037] The target variable may represent a value that a machine learning model is being trained to predict, and the feature set may represent the variables that are input to a trained machine learning model to predict a value for the target variable. The set of observations may include target variable values so that the machine learning model can be trained to recognize patterns in the feature set that lead to a target variable value. A machine learning model that is
trained to predict a target variable value may be referred to as a supervised learning model.
[0038] In some implementations, the machine learning model may be trained on a set of observations that do not include a target variable. This may be referred to as an unsupervised learning model. In this case, the machine learning model may learn patterns from the set of observations without labeling or supervision, and may provide output that indicates such patterns, such as by using clustering and/or association to identify related groups of items within the set of observations.
[0039] As shown by reference number 220, the machine learning system may train a machine learning model using the set of observations and using one or more machine learning algorithms, such as a regression algorithm, a decision tree algorithm, a neural network algorithm, a k-nearest neighbor algorithm, a support vector machine algorithm, or the like. After training, the machine learning system may store the machine learning model as a trained machine learning model 225 to be used to analyze new observations.
As to the API calls performed, the specification discloses:
[0018]… the intake system may check one or more rules to verify whether one or more tokens have been validated or need to be validated for a current screen of the intake workflow, may check one or more rules to determine whether one or more downstream API calls need to be made to obtain relevant transaction data from the integrated transaction backend systems, may invoke the appropriate API calls when needed, and may check one or more rules to return information indicating a next screen to be presented to a user and/or information to be presented on the next screen…
[0021] As further shown in Fig. IA, and by reference number 110, the intake system may determine an incident type and select an appropriate intake workflow based on historical incident data associated with the user and/or other users and/or based on the entry point associated with the request to report the potential incident ( e.g., the communication channel used to report the potential incident and/or the user interface screen or option used to report the potential incident). For example, in some implementations, prior to selecting an intake workflow to initiate a fraud
or dispute resolution process associated with the reported incident, the intake system may perform one or more API calls to determine whether the user is eligible to report a fraud or dispute claim based on the historical data. For example, in some implementations, the intake system may perform one or more API calls to communicate with a transaction backend system to determine an age of the associated account, a date when an address associated with the account was last updated, a status (e.g., active, inactive, or expired) associated with the account, an issue
date associated with the account, and/or a status related to whether there are any existing security reports or fraud cases associated with the account. Accordingly, in some implementations, the intake system may perform the one or more API calls to determine one or more of these and/or other parameters to verify that the user associated with the account is eligible to report a fraud claim or dispute a transaction. For example, in some implementations, the intake system may determine that the user is ineligible to report the potential incident if the account is less than a threshold number of days (e.g., thirty days) old, and/or if the address was changed within a threshold time period (e.g., the last thirty days). …
[0022]… For example, when the user reports the incident, the intake system may perform one or more API calls to determine whether the user has a purchase history with the associated merchant, whether the transaction is a recurring transaction, and/or other suitable information that may relate to purchasing patterns, user activity patterns, and/or other patterns that may indicate whether the potential incident is likely to be a fraud claim or to be a dispute…
[0027]… As shown by reference number 150, in cases where the user selects the option to report or request help with the transaction, the intake system may perform one or more API calls (e.g., to check for existing claims and/or other relevant data) to determine whether the user is eligible to report the incident. In some implementations, in cases where the user is determined to be eligible to report the incident, the intake system may present a transaction review screen to the user to solicit more information about the transaction. …
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 limiting the data acted upon with respect to the intake workflow used to report a potential incident – non-functional descriptive subject matter applied for a business process. Dependent claim 17 is directed toward displaying a reactive message in response to user input-outputting data -insignificant extra solution activity. Dependent claim 4 is directed toward presenting the initial screen based on eligibility determination to report an incident - outputting data -insignificant extra solution activity. Dependent claim 18 is directed toward presenting an initial screen based on account eligible-outputting result insignificant extra solution activity. Dependent claim 19 is directed toward present final screen based on analysis of user input-outputting results insignificant extra solution activity. Dependent claim 20 is directed toward a user interface entry point associated with user interface channel and initial or second screen associated with second user interface channel- applying technology for data reception and outputting data on a screen-well understood and conventional application of technology for a data entry and output.
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.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 3, 5-8, 10, 12-, 13, 15 and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over CA 3230604 A1 by Matsuoka et al. (Matsuoka) in view of US Patent No. 12,229,622 B1 by Welch et al (Welch) and further in view of US Pub No. 2019/0129748 A1 by Stevens et al. (Stevens)
In reference to Claim 1:
Matsuoka teaches:
(Currently Amended) A system for customized intake handling ((Matsuoka) in at least FIG. 1; FIG. 3, FIG. 18; para 0013, para 0263), the system comprising:
one or more memories ((Matsuoka) in at least para 0013, para 0263-0264); and
one or more processors, communicatively coupled to the one or more memories ((Matsuoka) in at least para 0013, para 0263), configured to:
receive, from a user device, and via a user interface entry point corresponding to a particular communication channel, a request to report a potential incident related to a transaction associated with a user account ((Matsuoka) in at least para 0046, para 0055-0057, para 0060-0061, para 0066, para 0099, para 0122, para 0160, para 0172-0173); …
classify the potential incident based on information associated with the user interface entry point and historical data associated with the user account, wherein the user interface entry point is used to report the potential incident ((Matsuoka) in at least para 0048-0050, para 0072-0073, para 0102-0103, para 0207-0208, para 0211, para 0260-0261);
select, based on classifying the potential incident, an intake workflow to resolve the potential incident based on the historical data and information associated with the user interface entry point ((Matsuoka) in at least para 0003, para 0048, para 0063-0064, para 0065, para 0074-0075, para 0097, para 0122-0123, para 0162) wherein the intake workflow is portable across a plurality of communication channels, including the particular communication channel ((Matsuoka) in at least FIG. 3 wherein the prior art illustrates task facilitation system which provides workflow across task recommendation system and task coordination system FIG. 4 wherein the prior art teaches task system comprises task creation system coupled to and communication with database and provides workflow across task ranking sub-system, task selection sub-system; FIG. 8A-B; para 0108 wherein the prior art teaches modeling sub-system provides data to pairing sub-system implemented via application/system on computer system of assignment system; para 0109-0110 wherein the prior art teaches representative pairing sub-system implements AI that utilizes attributes as input and data from the data storage may be used by pairing sub-system as input; para 0121-0122, para 0124-0125, para 0130, para 0136, para 0159-0160, para 0164-0166);
present, to the user device, an initial screen associated with the intake workflow, wherein the initial screen associated with the intake workflow includes one or more questions to request one or more user inputs that indicate one or more parameters related to the potential incident ((Matsuoka) in at least FIG. 14; para 0132-0136, para 0162-0166, para 0188);
receive, from the user device and via the initial screen, the one or more user inputs that indicate the one or more parameters related to the potential incident ((Matsuoka) in at least FIG. 17; para 0065-0066, para 0117, para 0134, para 0189 , para 0216, para 0218, para 0239, para 0260)
present, to the user device, a next screen associated with the intake workflow, wherein the next screen is selected based on mapping the one or more parameters to the next screen (display) based on the historical data and the one or more user inputs. and wherein the system continues to select and present one or more additional next screens …((Matsuoka) in at least FIG. 13A-C; FIG. 14-16; para 0003-0004, para 0006, para 0048, para 0050 wherein the prior art teaches identify correlations between different factors and polarities of interaction applying weights on factors; para 0054, para 0056, para 0058, para 0061-0062, para 0064-0075, para 0084, para 0086-0087, para 0109 wherein the prior art teaches identifying correlations, attributes, clusters to identify representatives from groups for assignment to members, para 0230-0231, para 0234-0235, para 0239-0241, para 0243-0250, para 0294 “set of data … analyzed … to identify correlations between different elements of the set of data …using sample or live data to identify potential correlations”),
wherein the next screen includes a prompt for the user to provide supporting documentation [information/testimonials] related to the transaction, the documentation [information/testimonials ] being used to further classify the potential incident [tasks] and to select one or more additional next screens ((Matsuoka) in at least para 0047-0048, para 0057, para 0066-0067, para 0092, para 0151, ),
Matsuoka does not explicitly teach:
perform one or more application program interface (API) calls to one or more integrated transaction backend systems, to determine whether the user account is eligible to report the potential incident;
and wherein the system continues to select and present one or more additional next screens every time the intake workflow reaches a decision-making point, until a final outcome is reached,
Welch teaches:
perform one or more application program interface (API) calls to one or more integrated transaction backend systems, to determine whether the user account is eligible to report the potential incident; ((Welch) in at least Fig. 18, Col 4 lines 13-21, Col 6 lines 49-55, Col 13 lines 4-20, Col 14 lines 63-Col 15 lines 1-2, Col 25 lines 44-48, Col 29 lines 58-67, Col 39 lines 4-67, Col 41 lines 39-Col 42 lines 1-9, Col 44 lines 33-67, Col 48 lines 27-46, Col 52 lines 44-55, Col 57 lines 33-46, Col 64 lines 36-50, Col 67 lines 50-Col 68 lines 1-34, Col 34 lines 53-67)
Both Matsuoka and Welch are directed toward processes for performing financial related user interactive task. Welch teaches the motivation of applying an API verification process in order to prevent fraudulent use of a platform and to prevent fraudulent user to attempt a fraudulent claim action. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the task modification process of Matsuoka to include API verification process as taught by Welch since Welch teaches the motivation of applying an API verification process in order to prevent fraudulent use of a platform and to prevent fraudulent user to attempt a fraudulent claim action
Stevens teaches:
and wherein the system continues to select and present one or more additional next screens every time the intake workflow reaches a decision-making point, until a final outcome is reached ((Stevens) in at least FIG. 5 ref # 570; para 0083-0094, para 0127, para 0130, para 0148-0149, para 0170, para 0175)
Both Matsuoka and Stevens are directed toward performing task flow sequences which are displayed to users with task prompts for the user to interact. Stevens teaches the motivation determining if workflow execution is complete or if further steps need to be executed until the entire workflow execution is complete including checking if data associated with execution of overall workflow is pushed to data sources so that the accumulated information can be implemented for updating the workflow which in then incorporated until the updated workflow is complete. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the task modification process of Matsuoka the incorporation of data sources accumulated as taught by Stevens so that the task in the workflow can be updated and then the sequence of workflow tasks executed to completion since Stevens teaches the motivation determining if workflow execution is complete or if further steps need to be executed until the entire workflow execution is complete including checking if data associated with execution of overall workflow is pushed to data sources so that the accumulated information can be implemented for updating the workflow which in then incorporated until the updated workflow is complete.
In reference to Claim 3:
The combination of Matsuoka, Welch and Stevens discloses the limitations of independent claim 1. Matsuoka further discloses the limitations of dependent claim 3
(Original) The system of claim 1 (see rejection of claim 1 above),
wherein the next screen associated with the intake workflow includes a reactive message that is responsive to the one or more user inputs and provides guidance related to reporting the potential incident.((Matsuoka) in at least FIG. 8B, FIG. 9; para 0186, para 0188-0190, para 0232, para 0245)
In reference to Claim 5:
The combination of Matsuoka, Welch and Stevens discloses the limitations of independent claim 1. Matsuoka further discloses the limitations of dependent claim 5
(Original) The system of claim 1, wherein the one or more processors (see rejection of claim 1 above) are further configured to:
present, to the user device, a final screen associated with the intake workflow based on a determination that the one or more user inputs have resolved all required parameters associated with reporting the potential incident, wherein the final screen includes an informational message that indicates one or more next steps in resolving the potential incident or an instructional message that indicates one or more directions for resolving the potential incident ((Matsuoka) in at least para 0076, para 0131-0132, para 0250, para 0252-0254).
In reference to Claim 6:
The combination of Matsuoka, Welch and Stevens discloses the limitations of independent claim 1. Matsuoka further discloses the limitations of dependent claim 6
(Original) The system of claim 1 (see rejection of claim 1 above),
wherein one or more of the intake workflow or the next screen associated with the intake workflow are selected using a machine learning model ((Matsuoka) in at least para 0209, para 0211-0212, para 0253).
In reference to Claim 7:
The combination of Matsuoka, Welch and Stevens discloses the limitations of independent claim 1. Matsuoka further discloses the limitations of dependent claim 7
(Original) The system of claim 1 (see rejection of claim 1 above),
wherein the user interface entry point is associated with a first user interface channel, and wherein one or more of the initial screen or the next screen of the intake workflow is associated with a second user interface channel ((Matsuoka) in at least para 0171, para 0186, para 0193-0194, para 0216).
In reference to Claim 8:
The combination of Matsuoka, Welch and Stevens discloses the limitations of independent claim 8.
(Currently Amended) A method for customized intake handling ((Matsuoka) in at least para 0003-0004), comprising:
receiving, by an intake system, from a user device, and via a user interface entry point associated with a particular communication channel, a request to report a potential incident related to a transaction associated with a user account ((Matsuoka) in at least para 0046, para 0055-0057, para 0060-0061, para 0066, para 0099, para 0122, para 0160, para 0172-0173); …
classifying, by the intake system, the potential incident based on information associated with the user interface entry point and historical data associated with the user account, wherein the user interface entry point is used to report the potential incident ((Matsuoka) in at least para 0048-0050, para 0072-0073, para 0102-0103, para 0207-0208, para 0211, para 0260-0261);
selecting, by the intake system and based on classifying the potential incident, an intake workflow to resolve the potential incident based on the historical data associated with the user account and information and information associated with the interface entry ((Matsuoka) in at least para 0003, para 0048, para 0063-0064, para 0065, para 0074-0075, para 0097, para 0122-0123, para 0162), wherein the intake workflow is portable across a plurality of communication channels, including the particular communication channel ((Matsuoka) in at least FIG. 3 wherein the prior art illustrates task facilitation system which provides workflow across task recommendation system and task coordination system FIG. 4 wherein the prior art teaches task system comprises task creation system coupled to and communication with database and provides workflow across task ranking sub-system, task selection sub-system; FIG. 8A-B; para 0108 wherein the prior art teaches modeling sub-system provides data to pairing sub-system implemented via application/system on computer system of assignment system; para 0109-0110 wherein the prior art teaches representative pairing sub-system implements AI that utilizes attributes as input and data from the data storage may be used by pairing sub-system as input; para 0121-0122, para 0124-0125, para 0130, para 0136, para 0159-0160, para 0164-0166);
presenting, by the intake system and to the user device, an initial screen associated with the intake workflow, wherein the initial screen associated with the intake workflow includes one or more questions to request one or more user inputs that indicate one or more parameters related to the potential incident ((Matsuoka) in at least FIG. 13A-C; FIG. 14; para 0230-0231, para 0234-0235, para 0239-0241, para 0243-0250);
presenting, by the intake system and to the user device, a next screen associated with the intake workflow, wherein the next screen is selected based on mapping the one or more parameters to the next screen (display) based on the historical data and the one or more user inputs that indicate the one or more parameters related to the potential incident, and wherein the intake system continues to select and present one or more additional next screens ……((Matsuoka) in at least FIG. 13A-C; FIG. 14-16; para 0003-0004, para 0006, para 0048, para 0050 wherein the prior art teaches identify correlations between different factors and polarities of interaction applying weights on factors; para 0054, para 0056, para 0058, para 0061-0062, para 0064-0075, para 0084, para 0086-0087, para 0109 wherein the prior art teaches identifying correlations, attributes, clusters to identify representatives from groups for assignment to members, para 0230-0231, para 0234-0235, para 0239-0241, para 0243-0250, para 0294 “set of data … analyzed … to identify correlations between different elements of the set of data …using sample or live data to identify potential correlations”); and
presenting, by the intake system and to the user device, a final screen associated with the intake workflow based on a determination that the one or more user inputs have resolved all required parameters associated with reporting the potential incident ((Matsuoka) in at least para 0076, para 0132, para 0187-0188, para 0191, para 0202 , para 0207-0208, para 0260),
wherein the next screen includes a prompt for the user to provide supporting documentation [information/testimonials] related to the transaction, the documentation [information/testimonials ] being used to further classify the potential incident [tasks] and to select one or more additional next screens ((Matsuoka) in at least para 0047-0048, para 0057, para 0066-0067, para 0092, para 0151).
Matsuoka does not explicitly teach:
performing, by the intake system, one or more application program interface (API) calls to one or more integrated transaction backend systems, to determine whether the user account is eligible to report the potential incident
and wherein the intake system continues to select and present one or more additional next screens every time the intake workflow reaches a decision-making point, until a final outcome is reached
Welch teaches:
performing, by the intake system, one or more application program interface (API) calls to one or more integrated transaction backend systems to determine whether the user account is eligible to report the potential incident; ((Welch) in at least Fig. 18, Col 4 lines 13-21, Col 6 lines 49-55, Col 13 lines 4-20, Col 14 lines 63-Col 15 lines 1-2, Col 25 lines 44-48, Col 29 lines 58-67, Col 39 lines 4-67, Col 41 lines 39-Col 42 lines 1-9, Col 44 lines 33-67, Col 48 lines 27-46, Col 52 lines 44-55, Col 57 lines 33-46, Col 64 lines 36-50, Col 67 lines 50-Col 68 lines 1-34, Col 34 lines 53-67)
Both Matsuoka and Welch are directed toward processes for performing financial related user interactive task. Welch teaches the motivation of applying an API verification process in order to prevent fraudulent use of a platform and to prevent fraudulent user to attempt a fraudulent claim action. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the task modification process of Matsuoka to include API verification process as taught by Welch since Welch teaches the motivation of applying an API verification process in order to prevent fraudulent use of a platform and to prevent fraudulent user to attempt a fraudulent claim action
Stevens teaches:
and wherein the system continues to select and present one or more additional next screens every time the intake workflow reaches a decision-making point, until a final outcome is reached ((Stevens) in at least FIG. 5 ref # 570; para 0083-0094, para 0127, para 0130, para 0148-0149, para 0170, para 0175)
Both Matsuoka and Stevens are directed toward performing task flow sequences which are displayed to users with task prompts for the user to interact. Stevens teaches the motivation determining if workflow execution is complete or if further steps need to be executed until the entire workflow execution is complete including checking if data associated with execution of overall workflow is pushed to data sources so that the accumulated information can be implemented for updating the workflow which in then incorporated until the updated workflow is complete. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the task modification process of Matsuoka the incorporation of data sources accumulated as taught by Stevens so that the task in the workflow can be updated and then the sequence of workflow tasks executed to completion since Stevens teaches the motivation determining if workflow execution is complete or if further steps need to be executed until the entire workflow execution is complete including checking if data associated with execution of overall workflow is pushed to data sources so that the accumulated information can be implemented for updating the workflow which in then incorporated until the updated workflow is complete.
In reference to Claim 10:
The combination of Matsuoka, Welch and Stevens discloses the limitations of independent claim 8. Matsuoka further discloses the limitations of dependent claim 10
(Original) The method of claim 8 (see rejection of claim 8 above),
wherein the next screen associated with the intake workflow includes a reactive message that is responsive to the one or more user inputs and provides guidance related to reporting the potential incident. .((Matsuoka) in at least FIG. 8B; para 0186, para 0188-0190, para 0232, para 0245)
In reference to Claim 12:
The combination of Matsuoka, Welch and Stevens discloses the limitations of independent claim 1. Matsuoka further discloses the limitations of dependent claim 12
(Original) The method of claim 8 (see rejection of claim 8 above),
wherein the final screen includes an informational message that indicates one or more next steps in resolving the potential incident or an instructional message that indicates one or more directions for resolving the potential incident ((Matsuoka) in at least para 0076, para 0131-0132, para 0250, para 0252-0254).
In reference to Claim 13:
The combination of Matsuoka, Welch and Stevens discloses the limitations of independent claim 8. Matsuoka further discloses the limitations of dependent claim 13
(Original) The method of claim 8 (see rejection of claim 8 above),
wherein one or more of the intake workflow or the next screen associated with the intake workflow are selected using a machine learning model. ((Matsuoka) in at least para 0209, para 0211-0212, para 0253).
In reference to Claim 15:
The combination of Matsuoka, Welch and Stevens discloses the limitations of independent claim 15.
(Currently Amended) A non-transitory computer-readable medium storing a set of instructions ((Matsuoka) in at least para 0013, para 0267, para 0288), the set of instructions comprising:
one or more instructions that, when executed by one or more processors of an intake system ((Matsuoka) in at least para 0288-0292, para 0313), cause the intake system to:
receive, from a user device, and via a user interface entry point associated with a particular communication channel, a request to report a potential incident related to a transaction associated with a user account ((Matsuoka) in at least para 0046, para 0055-0057, para 0060-0061, para 0066, para 0099, para 0122, para 0160, para 0172-0173); …
classify the potential incident based on information associated with the user interface entry point and historical data associated with the user account, wherein the user interface entry point is used to report the potential incident ((Matsuoka) in at least para 0048-0050, para 0072-0073, para 0102-0103, para 0207-0208, para 0211, para 0260-0261);
select, based on classifying the potential incident, an intake workflow to resolve the potential incident based on the historical data and information associated with the user interface entry point ((Matsuoka) in at least para 0003, para 0048, para 0063-0064, para 0065, para 0074-0075, para 0097, para 0122-0123, para 0162) wherein the intake workflow is portable across a plurality of communication channels, including the particular communication channel ((Matsuoka) in at least FIG. 3 wherein the prior art illustrates task facilitation system which provides workflow across task recommendation system and task coordination system FIG. 4 wherein the prior art teaches task system comprises task creation system coupled to and communication with database and provides workflow across task ranking sub-system, task selection sub-system; FIG. 8A-B; para 0108 wherein the prior art teaches modeling sub-system provides data to pairing sub-system implemented via application/system on computer system of assignment system; para 0109-0110 wherein the prior art teaches representative pairing sub-system implements AI that utilizes attributes as input and data from the data storage may be used by pairing sub-system as input; para 0121-0122, para 0124-0125, para 0130, para 0136, para 0159-0160, para 0164-0166);
present, to the user device, an initial screen associated with the intake workflow, wherein the initial screen associated with the intake workflow includes one or more questions to request one or more user inputs that indicate one or more parameters related to the potential incident ((Matsuoka) in at least FIG. 14; para 0132-0136, para 0162-0166, para 0188); and
present, to the user device, a next screen associated with the intake workflow, wherein the next screen is selected based on mapping the one or more parameters to the next screen based on the historical data and the one or more user inputs that indicate the one or more parameters related to the potential incident …((Matsuoka) in at least FIG. 13A-C; FIG. 14-16; para 0003-0004, para 0006, para 0048, para 0050 wherein the prior art teaches identify correlations between different factors and polarities of interaction applying weights on factors; para 0054, para 0056, para 0058, para 0061-0062, para 0064-0075, para 0084, para 0086-0087, para 0109 wherein the prior art teaches identifying correlations, attributes, clusters to identify representatives from groups for assignment to members, para 0230-0231, para 0234-0235, para 0239-0241, para 0243-0250, para 0294 “set of data … analyzed … to identify correlations between different elements of the set of data …using sample or live data to identify potential correlations”), wherein one or more of the intake workflow or the next screen associated with the intake workflow are selected using a machine learning model, and wherein the intake system continues to select and present one or more additional next screens …. ((Matsuoka) in at least FIG. 13A-B; FIG. 14-16; para 0209, para 0211-0212, para 0230-0231, para 0234-0235, para 0239-0241, para 0243-0250, para 0253)
wherein the next screen includes a prompt for the user to provide supporting documentation [information/testimonials] related to the transaction, the documentation [information/testimonials ] being used to further classify the potential incident [tasks] and to select one or more additional next screens ((Matsuoka) in at least para 0047-0048, para 0057, para 0066-0067, para 0092, para 0151, )
Matsuoka does not explicitly teach:
perform one or more application program interface (API) calls to one or more integrated transaction backend systems to determine whether the user account is eligible to report the potential incident;
and wherein the intake system continues to select and present one or more additional next screens every time the intake workflow reaches a decision-making point, until a final outcome is reached
Welch teaches:
perform one or more application program interface (API) calls to one or more integrated transaction backend systems, to determine whether the user account is eligible to report the potential incident; ((Welch) in at least Fig. 18, Col 4 lines 13-21, Col 6 lines 49-55, Col 13 lines 4-20, Col 14 lines 63-Col 15 lines 1-2, Col 25 lines 44-48, Col 29 lines 58-67, Col 39 lines 4-67, Col 41 lines 39-Col 42 lines 1-9, Col 44 lines 33-67, Col 48 lines 27-46, Col 52 lines 44-55, Col 57 lines 33-46, Col 64 lines 36-50, Col 67 lines 50-Col 68 lines 1-34, Col 34 lines 53-67)
Both Matsuoka and Welch are directed toward processes for performing financial related user interactive task. Welch teaches the motivation of applying an API verification process in order to prevent fraudulent use of a platform and to prevent fraudulent user to attempt a fraudulent claim action. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the task modification process of Matsuoka to include API verification process as taught by Welch since Welch teaches the motivation of applying an API verification process in order to prevent fraudulent use of a platform and to prevent fraudulent user to attempt a fraudulent claim action
Stevens teaches:
and wherein the system continues to select and present one or more additional next screens every time the intake workflow reaches a decision-making point, until a final outcome is reached ((Stevens) in at least FIG. 5 ref # 570; para 0083-0094, para 0127, para 0130, para 0148-0149, para 0170, para 0175)
Both Matsuoka and Stevens are directed toward performing task flow sequences which are displayed to users with task prompts for the user to interact. Stevens teaches the motivation determining if workflow execution is complete or if further steps need to be executed until the entire workflow execution is complete including checking if data associated with execution of overall workflow is pushed to data sources so that the accumulated information can be implemented for updating the workflow which in then incorporated until the updated workflow is complete. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the task modification process of Matsuoka the incorporation of data sources accumulated as taught by Stevens so that the task in the workflow can be updated and then the sequence of workflow tasks executed to completion since Stevens teaches the motivation determining if workflow execution is complete or if further steps need to be executed until the entire workflow execution is complete including checking if data associated with execution of overall workflow is pushed to data sources so that the accumulated information can be implemented for updating the workflow which in then incorporated until the updated workflow is complete.
In reference to Claim 17:
The combination of Matsuoka, Welch and Stevens discloses the limitations of independent claim 15. Matsuoka further discloses the limitations of dependent claim 17
(Original) The non-transitory computer-readable medium of claim 15 (see rejection of claim 15 above),
wherein the next screen associated with the intake workflow includes a reactive message that is responsive to the one or more user inputs and provides guidance related to reporting the potential incident. .((Matsuoka) in at least FIG. 8B; para 0186, para 0188-0190, para 0232, para 0245)
In reference to Claim 19:
The combination of Matsuoka, Welch and Stevens discloses the limitations of independent claim 15. Matsuoka further discloses the limitations of dependent claim 19
(Original) The non-transitory computer-readable medium of claim 15 (see rejection of claim 15 above), wherein the one or more instructions further cause the intake system to:
present, to the user device, a final screen associated with the intake workflow based on a determination that the one or more user inputs have resolved all required parameters associated with reporting the potential incident, wherein the final screen includes an informational message that indicates one or more next steps in resolving the potential incident or an instructional message that indicates one or more directions for resolving the potential incident. ((Matsuoka) in at least para 0066, para 0068-0069, para 0073, para 0171, para 0176-0178, para 0181, para 0210)
In reference to Claim 20:
The combination of Matsuoka, Welch and Stevens discloses the limitations of independent claim 15. Matsuoka further discloses the limitations of dependent claim 20
(Original) The non-transitory computer-readable medium of claim 15 (see rejection of claim 15 above),
wherein the user interface entry point is associated with a first user interface channel, and wherein one or more of the initial screen or the next screen of the intake workflow is associated with a second user interface channel. ((Matsuoka) in at least para 0171, para 0186, para 0193-0194, para 0216).
Claim(s) 2 and 21 of claim 1 above, Claim(s) 9 of claim 8 above, Claim 16 of claim 15 above, is/are rejected under 35 U.S.C. 103 as being unpatentable over CA 3230604 A1 by Matsuoka et al. (Matsuoka), in view of US Patent No. 12,229,622 B1 by Welch et al (Welch) in view of US Pub No. 2019/0129748 A1 by Stevens et al. (Stevens) and further in view of US Pub No. 2013/0262473 A1 by Scanlon et al. (Scanlon).
In reference to Claim 2:
The combination of Matsuoka, Welch and Stevens discloses the limitations of independent claim 1. Matsuoka further discloses the limitations of dependent claim 2.
(Previously Presented) The system of claim 1 (see rejection of claim 1 above),
wherein the intake workflow is associated with a fraud claim [issue] type or a dispute claim[issue] type based on the historical data and the information associated with the user interface entry point. ((Matsuoka) in at least para 0003, para 0048, para 0050, para 0055, para 0063, para 0065, para 0075, para 0097, para 0122-0123, para 0162)
Matsuoka does not explicitly teach:
workflow is associated with a fraud claim type or a dispute claim type
Scanlon teaches:
workflow is associated with a fraud claim type or a dispute claim type ((Scanlon) in at least FIG. 6; para 0038, para 0051, para 0094, para 0099)
Matsuoka and Scanlon are directed toward task determination processes. Scanlon teaches the motivation of triggering in the task process an investigation for fraud task process in response to predefined inputs during the task and file review process. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the task modification process of Matsuoka to include fraud investigation task workflow process as taught by Scanlon since Scanlon teaches the motivation of triggering in the task process an investigation for fraud task process in response to predefined inputs during the task and file review process.
In reference to Claim 21:
The combination of Matsuoka, Welch and Stevens, discloses the limitations of independent claim 1. Matsuoka further discloses the limitations of dependent claim 21
(Previously Presented) The system of claim 1 (see rejection of claim 1 above), wherein the one or more processors, to classify the potential incident, are configured to:
Matsuoka does not explicitly teach:
classify the potential incident as a fraud claim when the user interface entry point corresponds to a first communication channel, and
classify the potential incident as a dispute claim when the user interface entry point corresponds to a first communication channel.
Scanlon teaches:
classify the potential incident as a fraud claim when the user interface entry point corresponds to a first communication channel, and classify the potential incident as a dispute claim when the user interface entry point corresponds to a first communication channel.((Scanlon) in at least para 0038, para 0051, para 0054, para 0056, para 0066, para 0076, para 0098-0099, para 0102, para 0111, para 0124)
Both Matsuoka and Scanlon are directed toward task determination processes. Scanlon teaches the motivation of categorizing activities such as fraud task process in order to determine what task to assign or phrases to present in questions presented related to task, during the task and file review process. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the task modification process of Matsuoka to include categorizing activity for task assignment as taught by Scanlon since Scanlon teaches the motivation of categorizing activities such as fraud task process in order to determine what task to assign or phrases to present in questions presented related to task, during the task and file review process.
In reference to Claim 9:
The combination of Matsuoka, Welch and Stevens discloses the limitations of independent claim 8. Matsuoka further discloses the limitations of dependent claim 9.
(Previously Presented) The method of claim 8 (see rejection of claim 8 above),
wherein the intake workflow is associated with a fraud [issue] claim type or a dispute [issue] claim type based on the historical data and the information associated with the user interface entry point. ((Matsuoka) in at least para 0003, para 0048, para 0050, para 0055, para 0063, para 0065, para 0075, para 0097, para 0122-0123, para 0162)
Matsuoka does not explicitly teach:
workflow is associated with a fraud claim type or a dispute claim type
Scanlon teaches:
workflow is associated with a fraud claim type or a dispute claim type ((Scanlon) in at least FIG. 6; para 0038, para 0051, para 0094, para 0099)
Matsuoka and Scanlon are directed toward task determination processes. Scanlon teaches the motivation of triggering in the task process an investigation for fraud task process in response to predefined inputs during the task and file review process. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the task modification process of Matsuoka to include fraud investigation task workflow process as taught by Scanlon since Scanlon teaches the motivation of triggering in the task process an investigation for fraud task process in response to predefined inputs during the task and file review process.
In reference to Claim 16:
The combination of Matsuoka, Welch and Stevens discloses the limitations of independent claim 15. Matsuoka further discloses the limitations of dependent claim 16.
(Previously Presented) The non-transitory computer-readable medium of claim 15 (see rejection of claim 15 above),
wherein the intake workflow is associated with a fraud claim [issue] type or a dispute claim [issue] type based on the historical data and the information associated with the user interface entry point. ((Matsuoka) in at least para 0003, para 0048, para 0050, para 0055, para 0063, para 0065, para 0075, para 0097, para 0122-0123, para 0162)
Matsuoka does not explicitly teach:
workflow is associated with a fraud claim [issue] type or a dispute claim[issue] type
Scanlon teaches:
workflow is associated with a fraud claim type or a dispute claim type ((Scanlon) in at least FIG. 6; para 0038, para 0051, para 0094, para 0099)
Matsuoka and Scanlon are directed toward task determination processes. Scanlon teaches the motivation of triggering in the task process an investigation for fraud task process in response to predefined inputs during the task and file review process. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the task modification process of Matsuoka to include fraud investigation task workflow process as taught by Scanlon since Scanlon teaches the motivation of triggering in the task process an investigation for fraud task process in response to predefined inputs during the task and file review process.
Claim(s) 4 of claim 1 above, Claim(s) 11 of claim 8 above, Claim(s) 18 of claim 15 above, is/are rejected under 35 U.S.C. 103 as being unpatentable over CA 3230604 A1 by Matsuoka et al. (Matsuoka), in view of US Patent No. 12,229,622 B1 by Welch et al (Welch) in view of US Pub No. 2019/0129748 A1 by Stevens et al. (Stevens) and further in view of US Pub No. 2023/0353575 A1 by Chandra et al. (Chandra)
In reference to Claim 4:
The combination of Matsuoka, Welch and Stevens discloses the limitations of independent claim 1. Matsuoka further discloses the limitations of dependent claim 4.
(Previously Presented) The system of claim 1 (see rejection of claim 1 above),
Matsuoka does not explicitly teach:
eligibility to report the potential incident is based on one or more of an incident reporting history associated with the user account, existing incident reports associated with the user account, a recurring or non-recurring status associated with the transaction, or an alert status associated with the transaction.
Chandra teaches:
eligibility to report the potential incident is based on one or more of an incident reporting history associated with the user account, existing incident reports associated with the user account, a recurring or non-recurring status associated with the transaction, or an alert status associated with the transaction((Chandra) in at least para 0013, para 0041, para 0047, para 0065, para 0070, para 0081, para 0087-0089).
Both Matsuoka and Chandra are directed toward effectuating workflow request processes. Chandra teaches the motivation of identifying the entity and action sequence in order to authorized the workflow request so that the task requestor can be verified with an additional motivation that task sequence generally receives sensitive information. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the task modification process of Matsuoka to include an authorization process as taught by Chandra since Chandra teaches the motivation of identifying the entity and action sequence in order to authorized the workflow request so that the task requestor can be verified with an additional motivation that task sequence generally receives sensitive information.
In reference to Claim 11:
The combination of Matsuoka, Welch and Stevens discloses the limitations of independent claim 8. Matsuoka further discloses the limitations of dependent claim 11.
(Previously Presented) The method of claim 8 (see rejection of claim 8 above), further comprising:
Matsuoka does not explicitly teach:
wherein eligibility to report the potential incident is based on one or more of an incident reporting history associated with the user account, existing incident reports associated with the user account, a recurring or non-recurring status associated with the transaction, or an alert status associated with the transaction.
Chandra teaches:
wherein eligibility to report the potential incident is based on one or more of an incident reporting history associated with the user account, existing incident reports associated with the user account, a recurring or non-recurring status associated with the transaction, or an alert status associated with the transaction ((Chandra) in at least para 0013, para 0041, para 0047, para 0065, para 0070, para 0081, para 0087-0089).
Both Matsuoka and Chandra are directed toward effectuating workflow request processes. Chandra teaches the motivation of identifying the entity and action sequence in order to authorized the workflow request so that the task requestor can be verified with an additional motivation that task sequence generally receives sensitive information. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the task modification process of Matsuoka to include an authorization process as taught by Chandra since Chandra teaches the motivation of identifying the entity and action sequence in order to authorized the workflow request so that the task requestor can be verified with an additional motivation that task sequence generally receives sensitive information.
In reference to Claim 18:
The combination of Matsuoka, Welch and Stevens discloses the limitations of independent claim 15. Matsuoka further discloses the limitations of dependent claim 18.
(Previously Presented) The non-transitory computer-readable medium of claim 15 (see rejection of claim 15 above),
Matsuoka does not explicitly teach:
wherein eligibility to report the potential incident is based on one or more of an incident reporting history associated with the user account, existing incident reports associated with the user account, a recurring or non-recurring status associated with the transaction, or an alert status associated with the transaction.
Chandra teaches:
wherein eligibility to report the potential incident is based on one or more of an incident reporting history associated with the user account, existing incident reports associated with the user account, a recurring or non-recurring status associated with the transaction, or an alert status associated with the transaction((Chandra) in at least para 0013, para 0041, para 0047, para 0065, para 0070, para 0081, para 0087-0089).
Both Matsuoka and Chandra are directed toward effectuating workflow request processes. Chandra teaches the motivation of identifying the entity and action sequence in order to authorized the workflow request so that the task requestor can be verified with an additional motivation that task sequence generally receives sensitive information. It would have been obvious to one having ordinary skill before the effective filing date of the claimed invention to modify the task modification process of Matsuoka to include an authorization process as taught by Chandra since Chandra teaches the motivation of identifying the entity and action sequence in order to authorized the workflow request so that the task requestor can be verified with an additional motivation that task sequence generally receives sensitive information.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. WO 2019/170800 A1 by Rollat et al; US Pub No. 2011/0145738 A1 by Laugwitz et al; US Pub No. 2003/0115207 A1 by Bowman et al; US Pub No. 2016/0117466 A1 by Singh; US Pub No. 2018/0115899 A1 by Kedem et al; WO 03094021 A1 by Bales et al; US Pub No. 2015/0134285 A1 by Alvarez et al; WO 2018/132507 A1 by Hayter 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