DETAILED ACTION
This communication is a first Office Action Non-Final rejection on the merits. Claims 1-20 as originally filed are currently pending and considered below.
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 .
Status of Claims
This Non-Final Office action is in response to the application filed on May 01, 2025. Claims 1-20 are pending.
Priority
Application 19/196,650 was filed on 05/01/2025 and claims the benefit of U.S. Provisional Application 63642522 filed 05/03/2024.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 07/16/2025 is in compliance with the provisions of
37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1-10 and 20 are directed to a method (process), and Claims 11-19 are directed to a system (machine/apparatus). Thus, these claims fall within one of the four statutory categories of invention. (Step 1: Yes)
For step 2A, the Examiner has identified independent method Claim 1 as the claim that represents the claimed invention for analysis and is similar to independent claims 11 and 20. Claim 1, as exemplary is recited below, isolating the abstract idea from the additional elements, wherein the abstract idea is set in bold:
A method for identifying and remediating errors involving discrepancies related to Customer Relationship Management (CRM) events, event-associated data and rules, and required actions in response to the events, the method comprising: accessing CRM events, via an event management system, from a payment source data system; loading event-associated data and rules via the event management system that correspond to the CRM events, wherein the event-associated data and rules designate required actions in response to the CRM events; matching the event-associated data and rules to the CRM events; identifying any errors involving discrepancies that exist between the CRM events that were expected and that have occurred, the matched event-associated data and rules corresponding to the CRM events that were expected and that have occurred, and the required actions in response to the CRM events that were expected and that have occurred; and initiating remedial actions to correct the identified errors involving discrepancies that exist between the CRM events that were expected and that have occurred, the matched event-associated data and rules corresponding to the CRM events that were expected and that have occurred, and the required actions in response to the CRM events that were expected and that have occurred.
The above bolded limitations recite the abstract idea of monitoring CRM events by comparing expected actions to actual actions to identify discrepancies and initiate corrective actions. These limitations under its broadest reasonable interpretation, covers certain methods of organizing human activity (i.e., managing personal behavior or relationships or interactions between people, including social activities, teaching, and following rules or instructions). That is, other than reciting a system implemented by an event management system the claimed invention amounts to the abstract idea stated above. For example, the claim encompasses monitoring and auditing CRM-related payment events and associated obligations, which could be performed manually by financial administrators or account managers by reviewing payment records, comparing expected payment obligations with actual payments received, identifying discrepancies such as missed or late payments using ledgers or reports, and initiating corrective actions as part of managing customer accounts. This is considered to be long-standing commercial practice performed by financial administrators when managing customer accounts and payment obligations, which constitutes managing ad enforcing business rules governing finical transactions and customer account management. If a claim limitation, under its broadest reasonable interpretation, covers managing interactions between parties, but for the recitation of generic computer components, then it falls within the “certain methods of organizing human activity” grouping of abstract ideas. The mere nominal recitation of a “an event management system” and “a payment source data system”, do not take the claim out of the methods of organizing human interactions grouping. Thus, claims 1, 11, and 20 recites an abstract idea. (Step 2A- Prong 1: YES. The claims recite an abstract idea).
This judicial exception is not integrated into a practical application (2nd prong of eligibility test for step 2A). In particular, Claim 1 recites additional elements of a “an event management system” and “a payment source data system”. Claim 11 recites the same additional elements of Claim 1 with the addition of “a memory” and “a processor”. Claim 20 recites the same additional elements of Claim 1. These additional elements are all considered nothing more than generic computing devices to perform generic communicating functions such as storing data and instructions, transmitting and receiving data between computers. These elements are recited at a high-level of generality such that they amount no more than mere instructions to apply the exception using a generic computer component in technological environment. See MPEP 2106.05(f) and (h). Accordingly, these additional elements (the use of computer) do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are recited at a high level of generality when considered both individually and as a whole. Thus, Claims 1, 11, and 20 are directed to an abstract idea without an integration into a practical application. (Step 2A-Prong 2: NO: the additional claimed elements are not integrated into a practical application).
For step 2B, the claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception because they do not amount to more than simply instructing one to practice the abstract idea by using generic computer components to carry out the steps that define the abstract idea, as discussed above. This does not render the claims as being eligible. See MPEP 2106.05(f). The additional elements of using computer when considered both individually and as an ordered combination did not add significantly more to the abstract idea because they were simply applying the abstract idea using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept (See MPEP 2106.05(f)). Accordingly, these additional elements, do not change the outcome of the analysis, and claims 1, 11, and 20 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more).
Claims 2-3, 6-7, 9-10, 12-13, 16-17, and 19, recite limitations that further define the same abstract idea of independent claims to include after matching the event- associated data and rules to the CRM events, populating an audit interface comparing expected required actions in response to the CRM events against actual performed required actions in response to the CRM events, after identifying any errors involving discrepancies, creating a flag to initiate remedial actions to correct the identified errors, wherein a line item of the event-associated data and rules includes time frame requirements of the required action in response to the CRM event, mapping to what time period the required action in response to the event occurs, and any time remaining in the CRM event, wherein the event-associated data and rules are commission time frames and amounts on the order for a good or service, and wherein the required action in response to the event is a payment associated with the order for a good or service. Additionally, the dependent claims do not include any new additional elements and therefore are considered patent ineligible for the reasons given above.
Claims 4-5 and 14-15, recite limitations that further define the same abstract idea of independent claims to include submitting a remedial action request to resolve the error and after matching the event-associated data and rules to the CRM events, processing the data and rules of the CRM event. In addition, the claims recite the additional element “payor system” and “event management system””, are both recited at a high-high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component. Even in combination, these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself. Therefore, the claims are patent ineligible.
Claims 8 and 18, recite limitations that further define the same abstract idea of independent claims to include generating a score for all commission item/CRM item relationships on a commission items list; evaluating, all of the commission item/CRM item relationships for comparative strength with respect to a particular commission item; and implementing, a commission item/CRM item relationships with greater comparative strength, while dropping commission item/CRM item relationships with lower comparative strength. In addition, the claims recite the additional element “an (Artificial Intelligence) Al based commission matching system”, which is considered nothing more than a general link to AI technology because there is no recitation of specifics of how this additional element is being used. See MPEP 2106.05(f) and (h) indicate that merely “generally linking” the abstract idea to a particular technological environment or field of use cannot provide a practical application or significantly more. Therefore, the claims are patent ineligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3-7, 11, 13-17, and 20 are rejected over Starikova et al. (US 20150324904) in view of Navas (US 20100125545) further in view of Sliwka et al. (US 20220374981).
With regards to Claim 1, Starikova et al. teaches a method for identifying and remediating errors involving discrepancies related to Customer Relationship Management (CRM) events, event-associated data and rules, and required actions in response to the events, the method comprising: (See Abstract & FIG 1)
accessing [CRM] events, via an event management system, from a payment source data system; (See [0167]- FIG. 8A illustrates an example method 800 that proactively initiates a chat session based on a user's interaction with network accessible content, for example, on a website. The user's interaction with the network accessible content may be through a predefined bank product flow. Flows may exist to step a user 102 using a user device 104 through a defined sequence of events for various products/applications associated with enterprise 112. Also See [0034]-Internal sources 128 may provide any suitable information to server 114. An internal source 128 may be associated with a line of business. As an example, internal source 128a may correspond to a credit card line of business, and user 102 may hold a credit card account with internal source 128a. Internal source 128a may provide server 114 with user data 127 related to the credit card account, such as outstanding balances and payment history, user profile information that the credit card line of business has on file for user 102, or other suitable information. As other examples, internal source 128b may correspond to a mortgage line of business, internal source 128c may correspond to a checking and savings line of business, internal source 128d may correspond to a brokerage business, and so on. Also See [0174]-At step 806, the method monitors activity of the user interacting with the website that administers the bank product flow. As an example, through network 110, server 114 may be in communication with a browser application or native application resident on a user device, such as user device 104, used to access the website using GUI 108.)
identifying any errors involving discrepancies that exist between the [CRM] events that were expected and that have occurred, and the required actions in response to the [CRM] events that were expected and that have occurred; (See [0055]- In some embodiments, payment history may include information relating to payments made on time by first user 102a or whether first user 102a has missed payments when they became due. In some embodiments, the user information associated with first user 102a may include information relating to whether there are any pending actions that user 102a needs to be alerted to. In some embodiments, actions may include any suitable information. For example, actions may include notifications of missed payments or a reminder of an upcoming payment. Also See [0057]- As an example, if user 102a has missed a payment due on a credit card, processor 116 may determine to provide an alert to first user 102a notifying them that their account is past-due. In response to a determination to provide an alert to first user 102a, the method may proceed to step 220.)
*Examiner is interpreting the “missed payments” disclosed by the art to equate to “errors involving discrepancies” recited in the claim language and is interpreting “provide an alert to first user 102a notifying them that their account is past-due” disclosed by the prior art to equate to the “the required actions” recited in the claim language.
*Examiner notes that the prior art reference teaches comparing expected events (payment due dates) with actual events (a missed or late payment) by determining whether payments are made on time or result in a past-due status. It further links these determinations to actions by triggering alerts or notifications to the user the when such discrepancies are identified. Thus, the prior art teaches both comparing expected required events (timey payments) with actual performed events (missed or late payments) and executing a required action (alerting the user) based on that comparison, as recited in the claim.
initiating remedial actions to correct the identified errors involving discrepancies that exist between the [CRM] events that were expected and that have occurred, and the required actions in response to the [CRM] events that were expected and that have occurred (See [0056]- At step 216, processor 116 determines whether to provide a first alert to first user 102a. In some embodiments, the first alert may serve to notify first user 102a of an action by enterprise 112. As one example, enterprise 112 may be a bank, and first user 102a may have missed a payment due on a credit card associated with first user 102a. Under such circumstances, enterprise 112 may desire to notify first user 102a of the missed payment and provide user 102a with an opportunity to make the payment. Also See [0065]- In some embodiments, the second alert may serve to notify user 102b of an action by enterprise 112. As one example, enterprise 112 may be a bank and second user 102b may have missed a payment due on a credit card associated with second user 102b. Under such circumstances, enterprise 112 may notify second user 102b of the missed payment and provide them with an opportunity to make the payment. Also See [0078]- Thus, even where a bank action associated with first user 102a and second user 102b is be the same (e.g., a notification of missed payment). Also See [0039]- Repayment plan module 126b may allow enterprise 112 to select, offer, or administer plans to user 102 for repaying a debt, in accordance with certain embodiments. As an example, repayment plan may include a promise-to-pay option where user 102 promises to repay at least a portion of the debt by a promised date.).
Starikova et al. teaches an event but does not teach the event being a CRM event, loading event-associated data and rules via the event management system that correspond to the CRM events, wherein the event-associated data and rules designate required actions in response to the CRM events, and matching the event-associated data and rules to the CRM events.
Navas teaches:
a CRM event (See [0026]- The enterprise system as described herein includes data sources. The data sources may be any subsystem (e.g., customer relations management (CRM), etc.), database, or other element within the enterprise that implements a change to one or more objects (e.g., structured objects, including business objects that generally are part of a business context such as a “Customer” object). Each change to an object may be referred to as an event.)
loading event-associated data and rules via the event management system that correspond to the CRM events, wherein the event-associated data and rules designate required actions in response to the CRM events; (See [0026]- The enterprise system as described herein includes data sources. The data sources may be any subsystem (e.g., customer relations management (CRM), etc.), database, or other element within the enterprise that implements a change to one or more objects (e.g., structured objects, including business objects that generally are part of a business context such as a “Customer” object). Each change to an object may be referred to as an event. Also See [0050]- events are processed by means of rules including event patterns, actions, and constraints. An event pattern is a template that matches certain sets of events. In one embodiment, the template or event pattern describes not only the events but also their causal dependencies, timing, data parameters, and context. Examples may include: “All orders from customer C in the last month”, “All orders from frequent customers in the last month”, etc. An event pattern rule is a reactive rule that specifies an action to be taken whenever an event pattern is matched. An event pattern may be matched with real-time as well as non real-time event data. A reactive rule has two parts: a trigger, which is an event pattern, and an action, which is an event that is created whenever the trigger matches. A constraint expresses a condition that must be satisfied by the events observed in a system. Constraints can be used to specify not only how a target system should behave, but also how its users should use it. When a pattern is detected, the rule is triggered, and the user (human or automated) can take actions in response.)
matching the event-associated data and rules to the CRM events; (See [0050]- events are processed by means of rules including event patterns, actions, and constraints. An event pattern is a template that matches certain sets of events. In one embodiment, the template or event pattern describes not only the events but also their causal dependencies, timing, data parameters, and context. An event pattern rule is a reactive rule that specifies an action to be taken whenever an event pattern is matched. An event pattern may be matched with real-time as well as non real-time event data. A reactive rule has two parts: a trigger, which is an event pattern, and an action, which is an event that is created whenever the trigger matches. Also See [0080]-Query source 502 sends the query (not shown) with event pattern 504 to LE server node 510. In one embodiment, LE server node 510 stores event pattern 504, and responds when the pattern is matched with enterprise event data. LE server node 510 matches event pattern to real-time event data by querying data sources 572. Also See [0113]-When the fragment's pattern is matched by the local data, then the result is sent to the LE server where the query originated. The LE server that received the query from the user collates the responses from the various fragments and performs any last-minute calculations, joins, or functions.)
Starikova et al. and Navas are both considered to be analogous to the claimed invention because they are in the same field of error identification and remediation for a payment source. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Starikova et al. reference to further include the event being a CRM event, loading event-associated data and rules via the event management system that correspond to the CRM events, wherein the event-associated data and rules designate required actions in response to the CRM events, and matching the event-associated data and rules to the CRM events as taught by Navas. This is desirable such that it allows for an enterprise system includes multiple data sources that generate data that may be associated with an event in the enterprise system. (See Navas, [0022]).
The Starikova-Navas combination teaches matched event-associated data and a CRM event but does not teach identifying any errors involving the matched event-associated data and rules corresponding to the [CRM] events that were expected and that have occurred.
Sliwka et al. teaches:
identifying any errors involving the matched event-associated data and rules corresponding to the [CRM] events that were expected and that have occurred (See [0177]- When a payment is made, the listening thread may notify the ledger management system 104, which updates the distributed ledger to reflect the payment. During this update, the instance of the smart contract governing the loan is provided a notification indicating the payment event, which may cause the smart contract to determine whether the loan is fully repaid. If the loan is fully repaid, the smart contract releases the collateral token to the borrower, bringing the smart contract to a close. If the loan amount is not repaid, the terms of the smart contract (e.g., the loan amount and the next repayment) may be updated based on the payment. If the listening thread does not detect a receipt of a payment before the payment due date, the listening thread may notify the ledger management system 104 of the missed payment. In response to the notification, the ledger management system 104 may update the distributed ledger to reflect the non-payment, which may cause the smart contract to determine whether the loan is in default according to the terms of the contract.)
Starikova et al., Navas, and Sliwka et al. are all considered to be analogous to the claimed invention because they are in the same field of error identification and remediation for a payment source. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Starikova-Navas combination to further include identifying any errors involving the matched event-associated data and rules corresponding to the [CRM] events that were expected and that have occurred as taught by Sliwka et al. This is desirable such that it allows for systems and methods for implementing a variety of transactions in a way that automates much of the transaction while preserving and respecting the legal constraints on such automation. (See Sliwka, [0053]).
In regards to Claim 11, is rejected on a similar basis to Claim 1, with the following additions:
Starikova et al. teaches:
a system for event management, the system comprising: a memory that stores computer instructions and a processor that, when executing the computer instructions, causes the system to (See [0372]- the processor, or any machine utilizing one, may include non-transitory memory that stores methods, codes, instructions and programs as described herein and elsewhere. The processor may access a non-transitory storage medium through an interface that may store methods, codes, and instructions as described herein and elsewhere.)
In regards to Claim 20, is rejected on a similar basis to Claim 1.
In regards to Claim 3 and 13, the Starikova-Navas-Sliwka combination teaches the claimed invention as recited in the independent claim.
Starikova et al. teaches:
after identifying any errors involving discrepancies, creating a flag to initiate remedial actions to correct the identified errors (See [0057]- [0058]- As an example, if user 102a has missed a payment due on a credit card, processor 116 may determine to provide an alert to first user 102a notifying them that their account is past-due. In response to a determination to provide an alert to first user 102a, the method may proceed to step 220.) As an example, processor 116 may execute alert module 126a to determine whether to provide a first alert to first user 102a. Also See [0056]- At step 216, processor 116 determines whether to provide a first alert to first user 102a. In some embodiments, the first alert may serve to notify first user 102a of an action by enterprise 112. Under such circumstances, enterprise 112 may desire to notify first user 102a of the missed payment and provide user 102a with an opportunity to make the payment. Also See [0039]- Repayment plan module 126b may allow enterprise 112 to select, offer, or administer plans to user 102 for repaying a debt, in accordance with certain embodiments. As an example, repayment plan may include a promise-to-pay option where user 102 promises to repay at least a portion of the debt by a promised date.)
In regards to Claim 4 and 14, the Starikova-Navas-Sliwka combination teaches the claimed invention as recited in the independent claim.
Starikova et al. teaches:
submitting a remedial action request to a responsible payor system to resolve the error. (See [0056]-Under such circumstances, enterprise 112 may desire to notify first user 102a of the missed payment and provide user 102a with an opportunity to make the payment. Also See [0039]- Repayment plan module 126b may allow enterprise 112 to select, offer, or administer plans to user 102 for repaying a debt, in accordance with certain embodiments. As an example, repayment plan may include a promise-to-pay option where user 102 promises to repay at least a portion of the debt by a promised date...the promise demonstrates user 102's intent to make a payment, but the promise itself does not transact the payment. To transact the promised payment, promise-to-pay information is communicated to external payment service 134 capable of initiating a funds transfer from a source financial account to a destination financial account specified by user 102. Communicating promise-to-pay information to external payment service 134 may be performed by processor 116 on execution of repayment plan module 126b.)
In regards to Claim 5 and 15, the Starikova-Navas-Sliwka combination teaches the claimed invention as recited in the independent claim.
Navas teaches:
after matching the event-associated data and rules to the CRM events, processing the data and rules of the CRM event by the event management system. (See [0026]- The enterprise system as described herein includes data sources. The data sources may be any subsystem (e.g., customer relations management (CRM), etc.), database, or other element within the enterprise that implements a change to one or more objects (e.g., structured objects, including business objects that generally are part of a business context such as a “Customer” object). Each change to an object may be referred to as an event. Also See [0050]- events are processed by means of rules including event patterns, actions, and constraints. An event pattern is a template that matches certain sets of events. In one embodiment, the template or event pattern describes not only the events but also their causal dependencies, timing, data parameters, and context. An event pattern rule is a reactive rule that specifies an action to be taken whenever an event pattern is matched. An event pattern may be matched with real-time as well as non real-time event data. A reactive rule has two parts: a trigger, which is an event pattern, and an action, which is an event that is created whenever the trigger matches. Also See [0080]-Query source 502 sends the query (not shown) with event pattern 504 to LE server node 510. In one embodiment, LE server node 510 stores event pattern 504, and responds when the pattern is matched with enterprise event data. LE server node 510 matches event pattern to real-time event data by querying data sources 572. Also See [0113]-When the fragment's pattern is matched by the local data, then the result is sent to the LE server where the query originated. The LE server that received the query from the user collates the responses from the various fragments and performs any last-minute calculations, joins, or functions.)
Starikova et al., Navas, and Sliwka et al. are all considered to be analogous to the claimed invention because they are in the same field of error identification and remediation for a payment source. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Starikova-Navas-Sliwka combination to further include after matching the event-associated data and rules to the CRM events, processing the data and rules of the CRM event by the event management system as taught by Navas. This is desirable such that it allows for an enterprise system includes multiple data sources that generate data that may be associated with an event in the enterprise system. (See Navas, [0022]).
In regards to Claim 6 and 16, the Starikova-Navas-Sliwka combination teaches the claimed invention as recited in the independent claim.
Starikova et al. teaches:
wherein a line item of the event-associated data and rules includes time frame requirements of the required action in response to the [CRM] event (See [0071]- For example, the first alert format may provide information relating to the account balance, the current payment due, the amount past due, the total minimum payment due, or the payment due date. Also See [0058]- the first alert may serve to notify first user 102a of an action by enterprise 112. Under such circumstances, enterprise 112 may desire to notify first user 102a of the missed payment and provide user 102a with an opportunity to make the payment. Also See [0039]- Repayment plan module 126b may allow enterprise 112 to select, offer, or administer plans to user 102 for repaying a debt, in accordance with certain embodiments. As an example, repayment plan may include a promise-to-pay option where user 102 promises to repay at least a portion of the debt by a promised date. Also See [0085]-The promise-to-pay information may comprise a promised amount, promised date, payment form, user information, or other details associated with the promise-to-pay agreement.).
Navas teaches:
the CRM event (See [0026]- The enterprise system as described herein includes data sources. The data sources may be any subsystem (e.g., customer relations management (CRM), etc.), database, or other element within the enterprise that implements a change to one or more objects (e.g., structured objects, including business objects that generally are part of a business context such as a “Customer” object). Each change to an object may be referred to as an event.)
Starikova et al., Navas, and Sliwka et al. are all considered to be analogous to the claimed invention because they are in the same field of error identification and remediation for a payment source. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Starikova-Navas-Sliwka combination to further include the CRM event as taught by Navas. This is desirable such that it allows for an enterprise system includes multiple data sources that generate data that may be associated with an event in the enterprise system. (See Navas, [0022]).
In regards to Claim 7 and 17, the Starikova-Navas-Sliwka combination teaches the claimed invention as recited in the independent claim.
Starikova et al. teaches:
mapping to what time period the required action in response to the event occurs, and any time remaining in the [CRM] event (See [0092]- the promise-to-pay information may be communicated within a predetermined time period before the promised date associated with the promise-to-pay information as further described below. Also See [0106]- interface 118 communicates the promise-to-pay information to external payment service 134 according to a predetermined time period. The predetermined time period is configured such that on or before the promised date, interface 118 communicates the promise-to-pay information to external payment service 134. The predetermined time period is specified by enterprise 112, user 102, or any other person or entity. The predetermined time period may be fixed or variable. For example, the predetermined time period may be configured such that the promise-to-pay information is communicated on the n.sup.th day prior to the promised date, or the predetermined time period may be configured such that the promise-to-pay information is communicated anytime within n days prior to the promised date. Also See [0123]-, alert module 126a may determine alert frequency based on alert history, the amount of time until the promise to pay is due, the amount due according to the promise to pay, or the number of promises to pay that have been or are associated with user 102.).
Navas teaches:
the CRM event (See [0026]- The enterprise system as described herein includes data sources. The data sources may be any subsystem (e.g., customer relations management (CRM), etc.), database, or other element within the enterprise that implements a change to one or more objects (e.g., structured objects, including business objects that generally are part of a business context such as a “Customer” object). Each change to an object may be referred to as an event.)
Starikova et al., Navas, and Sliwka et al. are all considered to be analogous to the claimed invention because they are in the same field of error identification and remediation for a payment source. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Starikova-Navas-Sliwka combination to further include the CRM event as taught by Navas. This is desirable such that it allows for an enterprise system includes multiple data sources that generate data that may be associated with an event in the enterprise system. (See Navas, [0022]).
Claims 2 and 12 are rejected over Starikova et al. (US 20150324904) in view of Navas (US 20100125545) further in view of Sliwka et al. (US 20220374981), further in view of Orseno (US 20220157438 ).
In regards to Claim 2 and 12, the Starikova-Navas-Sliwka combination teaches the claimed invention as recited in the independent claim.
Navas teaches:
after matching the event- associated data and rules to the CRM events, (See [0050]- events are processed by means of rules including event patterns, actions, and constraints. An event pattern is a template that matches certain sets of events. In one embodiment, the template or event pattern describes not only the events but also their causal dependencies, timing, data parameters, and context. An event pattern rule is a reactive rule that specifies an action to be taken whenever an event pattern is matched. An event pattern may be matched with real-time as well as non real-time event data. A reactive rule has two parts: a trigger, which is an event pattern, and an action, which is an event that is created whenever the trigger matches. Also See [0080]-Query source 502 sends the query (not shown) with event pattern 504 to LE server node 510. In one embodiment, LE server node 510 stores event pattern 504, and responds when the pattern is matched with enterprise event data. LE server node 510 matches event pattern to real-time event data by querying data sources 572. Also See [0113]-When the fragment's pattern is matched by the local data, then the result is sent to the LE server where the query originated. The LE server that received the query from the user collates the responses from the various fragments and performs any last-minute calculations, joins, or functions.)
Starikova et al., Navas, and Sliwka et al. are all considered to be analogous to the claimed invention because they are in the same field of error identification and remediation for a payment source. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Starikova-Navas-Sliwka combination to further include after matching the event- associated data and rules to the CRM events as taught by Navas. This is desirable such that it allows for an enterprise system includes multiple data sources that generate data that may be associated with an event in the enterprise system. (See Navas, [0022]).
However, the Starikova-Navas combination does not teach populating an audit interface comparing expected required actions in response to the CRM events against actual performed required actions in response to the [CRM] events.
Orseno teaches:
populating an audit interface comparing expected required actions in response to the CRM events against actual performed required actions in response to the [CRM] events (See [0006]- The inventive system and methodology enable the audit to analyze the entirety of all claims selected according to provider criteria to determine all variances in expected claim payments and actual claim payments from all payer sources. Once variances are identified, they can be characterized as permissible/acceptable underpayment, or flagged for lost revenue recovery action. Also See [0025]- In the first steps 1102/1202, 1104/1204, provider revenue cycle data (first data set) and payer claim payment constraints (second data set) are collected and processed 1106/1206 to identify variances between the payments expected by the provider and payments made by the payer. Also See [0014]- he comprehensive, full-spectrum examination and analysis provided by the inventive system and process provides the accuracy and certainty across the entire provider data set. This precision is required for providers to pursue and capture underpayment amounts from payers, either insurance company or individual patients.)
Starikova et al., Navas, and Sliwka et al., and Orseno are all considered to be analogous to the claimed invention because they are in the same field of error identification and remediation for a payment source. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Starikova-Navas-Sliwka combination to further include populating an audit interface comparing expected required actions in response to the CRM events against actual performed required actions in response to the [CRM] events as taught by Orseno. This is desirable such that it allows for a tool for comprehensive, full-spectrum examination and analysis of healthcare provider revenue cycle billing data to identify claim payment variances, identify variances as recoverable or non-recoverable, and capture recoverable underpayments (See Orseno, [0014]).
Subject Matter Free of Prior Art
The cited prior art of record fails to expressly teach or suggest, either alone or in combination, the
features found within dependent claims 8 and 18. Claims 9-10 and 19 are not rejected under prior art by virtue of their dependency of Claim 8. However, the prior art of record neither anticipates nor supports a conclusion of obviousness without the use of impermissible hindsight with respect to the limitations of:
“generating a score, via an (Artificial Intelligence) Al based commission matching system, for all commission item/CRM item relationships on a commission items list; evaluating, via the Al based commission matching system, all of the commission item/CRM item relationships for comparative strength with respect to a particular commission item; and implementing, via the Al based commission matching system, a commission item/CRM item relationships with greater comparative strength, while dropping commission item/CRM item relationships with lower comparative strength”
when the claim is considered as a whole, which is present dependent claims 8 and 18.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Siebel et al. (US 20220405775) discloses a method includes curating CRM data by employing a type system of a model-driven architecture and selecting an AI CRM application from a group of applications. Each CRM application may generate one or more use case insights with one or more objectives. The method also includes obtaining one or more data models including an industry-specific data model from the curated CRM data.
Tamm et al. (US 20220335020) discloses a method includes determining that an identifier for an online order contains an error. The method also includes determining, based on a comparison between the identifier and multiple stored identifiers, that the identifier corresponds to a particular stored identifier within a defined tolerance.
Kelly et al. (US 20110251952) discloses a bill presentment service, wherein bills received from a plurality of billing entities are made available to a plurality of consuming entities via a plurality of consuming entity service providers, is provided under control of an operator of a payment processing network.
Hicks et al. (US 20160063506) discloses adapting a CRM user interface responsive to an analysis of CRM interactions data. In a method of the invention, different organizational representatives assign different qualitative values to correspondingly different interactions with one or more customers registered with the CRM system.
All sources listed above are relevant to the disclosed and claimed invention.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALAA WADIE HUSSEIN whose telephone number is (571) 270-1748. The examiner can normally be reached M-F: 8:00-5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jessica Lemieux can be reached on 571-270-3445. 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.
/A.W.H./
Examiner, Art Unit 3626
/JESSICA LEMIEUX/Supervisory Patent Examiner, Art Unit 3626