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 .
Status of Claims
This Office action is in response to correspondence received December 5, 2025.
Claims 1, 17, and 19 have been amended. Claims 1-20 are pending and have been examined.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on December 5, 2025 has been entered.
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. The claim(s) recite(s):
Claims 1, 17, and 19, which are similar in scope:
continuously monitoring one or more consumer computing devices; detecting, based on the continuous monitoring, a plurality of transactions between a consumer computing device of the one or more consumer computing devices and an enterprise organization computing device; storing the plurality of transactions in a transaction history associated with the consumer computing device; assigning a score to each transaction of the plurality of transactions; receiving a consumer concern requesting assistance with a transaction; receiving a token comprising details that describe the consumer concern and the consumer computing device wherein the details that describe the consumer computing device include personal identifiable information of a consumer associated with the consumer computing device; determining whether the consumer concern corresponds to at least one transaction within the transaction history associated with the consumer computing device, wherein the details that describe the consumer computing device include personal identifiable information of a consumer associated with the consumer computing device; based on determining the consumer concern corresponds to at least one transaction within the transaction history, determining whether the transaction is similar to at least one previously received transaction; based on determining the transaction is different from previously received transactions, generating a solution to the consumer concern; extracting, from the token, the personal identifiable information of the consumer associated with the consumer computing device; and transmitting instructions to initiate communication with the consumer computing device to resolve the consumer concern, wherein transmitting the instructions to initiate communication causes the enterprise organization to initiate communication and transmit the generated solution for execution resolve the consumer concern.
The steps, above, are a certain method of organizing human activity, commercial interactions, because the steps are for after sales customer support. Such an activity is similar to marketing or sales activities or behaviors, or business relations, two of the examples (inclusive examples) in MPEP 2106.04(a) for commercial interactions. Performing post sales customer service would be treated as a commercial interaction as it makes up a part of “sales activities or behaviors,” being related to sales and something which is done to ameliorate customer concerns during a sale. It is noted that a token under a broadest reasonable interpretation in light of the specification is a data representation of a transaction, so it could be a serial number or file number, neither of which is technical and if it were technical, is applied and therefore would be fairly interpreted as a Therefore, Applicant has recited an abstract idea in the independent claims.
The additional elements in claim 1 are:
at a computing device including one or more processors and memory:
“from/to a/the consumer/enterprise organization computing device”
Transmitting to/initiating communication with the consumer computing/enterprise organization computing device.
Transmitting via a communication channel associated with the personal identifiable information of the consumer associated with the consumer computing device; transmitting via the communication channel.
The additional elements in claim 17 are:
A computing platform comprising: at least one processor; a communication interface communicatively coupled to the at least one processor; and memory storing computer-readable instructions that, when executed by the at least one processor, cause the computing platform to:
“from/to a/the consumer/enterprise organization computing device”
Transmitting to/initiating communication with the consumer computing/enterprise organization computing device.
Transmitting via a communication channel associated with the personal identifiable information of the consumer associated with the consumer computing device; transmitting via the communication channel.
The additional elements of claim 19 are:
One or more non-transitory computer-readable media storing instructions that, when executed by a computing platform comprising at least one processor, memory, and a communication interface, cause the computing platform to
“from/to a/the consumer/enterprise organization computing device”
Transmitting to/initiating communication with the consumer computing/enterprise organization computing device.
Transmitting via a communication channel associated with the personal identifiable information of the consumer associated with the consumer computing device; transmitting via the communication channel.
This judicial exception is not integrated into a practical application because the additional elements in combination are, under a broadest reasonable interpretation in light of the specification, instructions to apply generic computers to the abstract idea. Claims 1, 17, and 19 are similar in scope but recite method, system, and CRM claims, and the body of the claims has information going from and to a consumer computing device and an enterprise organization computing device. Sending information to and from computers, where the information is the abstract idea steps, is instructing computers to be applied to the abstract idea. Transmitting via a channel that is associated with personal identifiable information of the consumer associated with the computing device would be: any communication that is connected to the consumer via their device that identifies the consumer. This would include a mobile device which as explained in MPEP 2106.05(f)(2) a server and a mobile unit are apply it limitations, see TLI Communications. Taken in combination, aside from the CRM, device, computer-implemented limitations (“do it” on a computer), the additional elements in combination are computers communicating with one another including one that could be a mobile device connected to a consumer with their identifiable information such as a cell number. The phone number is an example given in par 050 of the specification.
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, the combination of elements is apply it and apply it elements are not significantly more than the abstract idea. The reasoning in the previous section is carried over.
Dependent claims 2-15 further define the abstract idea. Limitations such as determining scores and likelihoods are analysis steps that further define the commercial interaction and have no technical elements that would be analyzed as additional elements. Any additional elements claims are recited, like the independent claims, as apply it elements and therefore are not a practical application or significantly more.
Claims 16, 18, and 20 recite making a phone call which is an additional element of apply it instructions because making a phone call is something a generic computer can do (VoIP) or a generic computer in the form of a smartphone. Therefore this additional element along with the generic enterprise and consumer computers sending/receiving information are not a practical application or significantly more.
Therefore, claims 1-20 are rejected under 35 USC 101.
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.
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-4, 6, 8-12, and 15-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shimpi et al., US 12058219 B1 (“Shimpi”), in view of Bajpay et al., US Pat No 7357301 B1 (“Bajpay”).
Per claims 1, 17, and 19, which are similar in scope, Shimpi teaches A method comprising: at a computing device including one or more processors and memory: continuously monitoring one or more consumer computing devices in col 5 ln 47-56: “Context processor 150 may be in electronic communication with information database 110 and the Information Channels, and may receive account activity data associated with a customer in response to internal system 101 receiving a communication (e.g., a telephone call) from the customer. Context processor 150 may also be in electronic communication with real-time stream processor 135, which may retrieve real time account activity data from the Information Channels in response to receiving a communication from a customer.” Being in electronic communication and receiving account data in response to receiving a communication teaches continuously monitoring. This is because the systems are in electronic communication, therefore they are coupled without interruption (continuous) and the actions occur in response to receiving a communication, which can only happen through continuous monitoring. This is also taught in col 22 ln 26-31: “Moreover, where the micro-app desires an input from a user, the micro-app may be configured to request a response from the operating system which monitors various hardware components and then communicates a detected input from the hardware to the micro-app.” The monitoring is continuous as there is no interruption taught.
detecting, based on the continuous monitoring, a plurality of transactions between a consumer computing device of the one or more consumer computing devices and an enterprise organization computing device in col 2 ln 50 – col 3 ln 2: “To expedite the process of communicating with the customer, predictive communication system 120 comprised in internal system 101 may have the capability of accessing and analyzing account activity data (reflecting activity a customer has conducted through his or her customer profile and/or transaction account, which may reflect activity trends) in order to predict the intent of the customer in initiating the customer communication (i.e., the reason for the customer's telephone call or other communication).” See also col 4 ln 15-34: “ In various embodiments, internal channels 84 may comprise various communication channels available to the customer to communicate with internal system 101 and the associated entity (e.g., a transaction account issuer). For example, internal channels 84 may comprise account activity data related to customer communications between internal system 101 and the customer through a customer profile, a mobile device and/or application, electronic messaging (e.g., email, instant messaging, social media channels, video calls or the like), telephone calls, and/or the like.” See also: col 5 ln 47-56: “Context processor 150 may be in electronic communication with information database 110 and the Information Channels, and may receive account activity data associated with a customer in response to internal system 101 receiving a communication (e.g., a telephone call) from the customer. Context processor 150 may also be in electronic communication with real-time stream processor 135, which may retrieve real time account activity data from the Information Channels in response to receiving a communication from a customer.” The underlined sections are specifically taught above and therefore this teaches based on the continuous monitoring.
Shimpi then teaches storing the plurality of transactions in a transaction history associated with the consumer computing device in col 3 ln 18 – 41: “ In various embodiments, information database 110 may comprise hardware and/or software capable of storing data. For example, information database 110 may comprise a server appliance running a suitable server operating system (e.g., MICROSOFT INTERNET INFORMATION SERVICES or, “IIS”) and having database software (e.g., ORACLE) installed thereon. In various embodiments, information database 110 may store account activity data and customer profile information associated with a customer profile, which is associated with a customer. In various embodiments, information database 110 may store numerous customer profiles associated with numerous customers. The customer profile may be associated with and/or comprise multiple transaction accounts (i.e., the customer utilizes numerous transaction instruments, each of which may be associated with a transaction account). Customer profile information may comprise information about the customer and/or her transaction history such as, merchants transacted with, types of transactions, type of transaction account, frequency of transactions, number of transactions, timing of transactions demographic information, personal information (e.g., gender, race, religion), social media posts, social media comments about the customer, pictures of the customer, video of the customer, or any other information.”
Shimpi then teaches assigning a score to each transaction of the plurality of transactions in col 5 ln 57 – col 6 ln 11: “Context processor 150, via predictive model 154 comprising analysis rules, may analyze the account activity, including real-time insights 156, to determine ranking of the intent insights comprised in the account activity data. The analysis rules of predictive model 154 may be based on prior customer servicing interactions (e.g., the number, frequency, topics, of such interactions), communication channels, and other information used to train predictive model 154 to determine priority ranking of intent insights.”
Shimpi then teaches receiving, from the consumer computing device, a consumer concern requesting assistance with a transaction in col 9 ln 19-35: “With combined reference to FIGS. 1A, 1B, and 2, in accordance various embodiments, a method 200 for predicting a customer communication intent is depicted. In various embodiments, a customer having a customer profile associated and/or comprised in internal system 101 may initiate a communication with internal system 101. Such customer communications will be referred to as telephone calls herein, however, the customer communication may be any communication (e.g., in real time), such as instant messaging, or other types of electronic messaging, video chat, and/or the like. In various embodiments, internal system 101 may have transmitted a notification to the customer profile instructing the customer to contact internal system 101. In response to the customer initiating a customer communication with internal system 101, internal system 101 and/or predictive communication system 120 may receive the customer communication (step 202).”
Shimpi then teaches receiving, from the enterprise organization computing device, … details that describe the consumer computing device include personal identifiable information of a consumer associated with the consumer computing device in col 9 ln 36-55: “Internal system 101, in response to receiving the customer communication, may identify the customer profile (step 204) associated with the customer initiating the customer communication. In various embodiments, internal system 101 may identify the customer profile by receiving a customer profile identifier (e.g., a password, social security number, biometric (e.g., fingerprint, voice print or facial recognition from a video call), or the like) and matching the customer profile identifier with a saved identifier. In various embodiments, the customer profile identifier may be a telephone number, in which case, internal system 101 may automatically match the telephone number from which the telephone call is received with a stored telephone number associated with the customer profile, thereby identifying the customer profile and authenticating the identity of the customer. In various embodiments, the customer profile identifier may be requested of customer by internal system 101, and input by the customer. The system may require the customer to answer additional security questions or enter additional identifying data.” For customer computing device that would correspond to the telephone number see col 4 ln 18-24: “For example, internal channels 84 may comprise account activity data related to customer communications between internal system 101 and the customer through a customer profile, a mobile device and/or application, electronic messaging (e.g., email, instant messaging, social media channels, video calls or the like), telephone calls, and/or the like.”
Shimpi then teaches determining whether the consumer concern corresponds to at least one transaction within the transaction history associated with the consumer computing device in col 10 ln 5-30: “Context processor 150, utilizing real-time insights 156, customer feedback 152, and the analysis rules of predictive model 154, may analyze the account activity data (step 208). As discussed herein, predictive model 154 may analyze the account activity data by ranking the intent insights comprised in the account activity data by priority (or the likelihood that an action reflected by a certain intent insight is the reason for the customer communication). Again, intent insights may be pieces of data that reflect past and/or recent actions (including communications) by the customer or related to the customer whether thru the customer profile in internal system 101 or through external channels 86. For example, predictive model 154 may rank the intent insights chronologically, with the most recent intent insight (reflecting the most recent action taken by the customer) ranked first. For example, if the customer tried most recently to replace a card, or internal system 101 instructed the customer to initiate a customer communication with internal system 101, an intent insight reflecting such action would be ranked highest. In various embodiments, the analysis rules of predictive model 154 may cause ranking of intent insights in any suitable manner (e.g., by type, wherein certain types of intent insights are ranked higher, such as fraud-related insights, or by chronology and type, and/or the like). Accordingly, predictive model 154 may create a ranked list of intent insights.”
Shimpi then teaches based on determining the consumer concern corresponds to at least one transaction within the transaction history, determining whether the transaction is similar to at least one previously received transaction in col 7 ln 35 – col 8 ln 7: “As an example, arbitration engine 184 may recognize that an intent insight reflecting an account payment is always conducted on a certain day of the month by the customer calling into internal system 101. Therefore, if the customer calls internal system 101 on that day of the month, the intent insight reflecting account payment may be ranked higher than other intent insights having different characteristics. By analyzing the ranking of the intent contexts, arbitration engine 184 may determine an intent prediction (i.e., the most likely reason for a customer's communication (e.g., telephone call)). Arbitration engine 184 may transmit the intent prediction to communication decision engine 186.”
Shimpi then teaches based on determining the transaction is different from previously received transactions, generating a solution to the consumer concern in col 8 ln 7-37: “Communication decision engine 186, in various embodiments, may receive the intent prediction from arbitration engine 184. Communication decision engine 186 may be configured to route the customer communication (e.g., telephone call) to the appropriate service system 188. A service system 188 may be the communication that the customer receives, in response to initiating a customer communication. Accordingly, communication decision engine 186 may analyze the intent prediction and match the intent prediction with an appropriate service system 188 to respond to the customer communication. For example, if the intent prediction reflects a prediction that the customer wishes to request a replacement transaction instrument, communication decision engine 186 may route the customer communication to an automated (voice) response system that is specifically for card replacement. The intent prediction and routing to an appropriate service system 188 may occur before the customer has to take any action after initiating a communication with internal system 101 (except, in some cases, providing a customer identifier to confirm the customer's identity). As another example, communication decision engine 186 may recognize that an intent prediction is related to a predicted action by the customer that cannot be completed by certain service systems 188 (e.g., automated service systems 188), such as to address fraud on a transaction account. Accordingly, communication decision engine 186 may route the customer communication to a service system 188 allowing person-to-person communication. In various embodiments, there may be a service system 188 for each action to be completed by the customer, or multiple actions may be associated with a service system 188.” The service system teaches the solution. For example, it could be replace a card, or route the customer to person-to-person communication. It is based on the insight and therefore where an insight is ranked higher than one that is temporally closer, that teaches “based on determining a transaction is different than previous transactions” because under a broadest reasonable interpretation, the transaction is not like the transactions that are temporally closer and is therefore “different” than “previous” (temporally closer) transactions. See
col 7 ln 35 – col 8 ln 7: “Arbitration engine 184 may also determine that an intent insight of the plurality of intent insights received by communication response system 170 may be a priority insight. As examples of priority insights, the business rules in arbitration engine 184 for prioritizing intent insights may cause intent insights related to fraud to rank highest, or certain correlations may cause an intent insight to be ranked higher than another that is temporally closer to the customer's communication.” The rest of the paragraph (see cols 7 and 8) describes analyzing transactions based on the time of the month which necessitates previous transactions as the pattern is based on previous transactions in the month.
Shimpi then teaches extracting the personal identifiable information of the consumer associated with the consumer computing device in col 9 ln 36-50: ”Internal system 101, in response to receiving the customer communication, may identify the customer profile (step 204) associated with the customer initiating the customer communication. In various embodiments, internal system 101 may identify the customer profile by receiving a customer profile identifier (e.g., a password, social security number, biometric (e.g., fingerprint, voice print or facial recognition from a video call), or the like) and matching the customer profile identifier with a saved identifier. In various embodiments, the customer profile identifier may be a telephone number, in which case, internal system 101 may automatically match the telephone number from which the telephone call is received with a stored telephone number associated with the customer profile, thereby identifying the customer profile and authenticating the identity of the customer.” For customer computing device that would correspond to the telephone number see col 4 ln 18-24: “For example, internal channels 84 may comprise account activity data related to customer communications between internal system 101 and the customer through a customer profile, a mobile device and/or application, electronic messaging (e.g., email, instant messaging, social media channels, video calls or the like), telephone calls, and/or the like.”
Shimpi then teaches and transmitting, to the enterprise organization computing device, instructions to initiate communication with the consumer computing device to resolve the consumer concern in col 8 ln 7 – 38: “As another example, communication decision engine 186 may recognize that an intent prediction is related to a predicted action by the customer that cannot be completed by certain service systems 188 (e.g., automated service systems 188), such as to address fraud on a transaction account. Accordingly, communication decision engine 186 may route the customer communication to a service system 188 allowing person-to-person communication.” See also col 11 ln 14-46: “Each service system 188 may be a communication system to address certain actions (e.g., transaction instrument replacement, account freezing, fraud, balance payment, etc.). For example, if the action is something that can be taken care of over an automated service system 188, communication decision engine 186 may route the customer communication to an automated service system 188”
Then, Shimpi teaches wherein transmitting the instructions to initiate communication with the consumer computing device causes the enterprise organization to initiate communication with the consumer computing device via a communication channel associated with the personal identifiable information of the consumer associated with the consumer computing device and transmit, to the consumer computing device via the communication channel, the generated solution for execution resolve the consumer concern in col 8 ln 7-37: “Communication decision engine 186, in various embodiments, may receive the intent prediction from arbitration engine 184. Communication decision engine 186 may be configured to route the customer communication (e.g., telephone call) to the appropriate service system 188. A service system 188 may be the communication that the customer receives, in response to initiating a customer communication. Accordingly, communication decision engine 186 may analyze the intent prediction and match the intent prediction with an appropriate service system 188 to respond to the customer communication. For example, if the intent prediction reflects a prediction that the customer wishes to request a replacement transaction instrument, communication decision engine 186 may route the customer communication to an automated (voice) response system that is specifically for card replacement. The intent prediction and routing to an appropriate service system 188 may occur before the customer has to take any action after initiating a communication with internal system 101 (except, in some cases, providing a customer identifier to confirm the customer's identity). As another example, communication decision engine 186 may recognize that an intent prediction is related to a predicted action by the customer that cannot be completed by certain service systems 188 (e.g., automated service systems 188), such as to address fraud on a transaction account. Accordingly, communication decision engine 186 may route the customer communication to a service system 188 allowing person-to-person communication. In various embodiments, there may be a service system 188 for each action to be completed by the customer, or multiple actions may be associated with a service system 188.” See also col 11 ln 28-46: “In response, presentation layer 180 may present the intent prediction (step 214) to the customer (e.g., via a push notification). Such a presentation may comprise an accuracy inquiry, inquiring if the action reflected in the intent prediction is the reason for the customer's call. In response, the customer may indicate “yes” or “no” (in various embodiments, by pressing a button, speaking, or otherwise providing an electronic input to predictive communication system 120), which may be an accuracy response (customer feedback 152). Internal system 101 and/or predictive communication system 120 may receive the accuracy response (step 216), and transmit the results as customer feedback 152 for predictive model 154 to utilize. In response to receiving a positive accuracy response, presentation layer 180 may continue with the same service system 188. In response to receiving a negative accuracy response, presentation layer 180 may re-route the customer communication to another service system 188 (e.g., a selection menu to allow the customer to input the reason for the call).” See also col 13 ln 65 – col 14 ln 34: “In various embodiments, the system and method may include alerting a subscriber when their computer (e.g., web client 192) is offline. The system may include generating customized information and alerting a remote subscriber that the information can be accessed from their computer. The alerts are generated by filtering received information, building information alerts and formatting the alerts into data blocks based upon subscriber preference information. The data blocks are transmitted to the subscriber's wireless device which, when connected to the computer, causes the computer to auto-launch an application to display the information alert and provide access to more detailed information about the information alert. More particularly, the method may comprise providing a viewer application to a subscriber for installation on the remote subscriber computer; receiving information at a transmission server sent from a data source over the Internet, the transmission server comprising a microprocessor and a memory that stores the remote subscriber's preferences for information format, destination address, specified information, and transmission schedule, wherein the microprocessor filters the received information by comparing the received information to the specified information; generates an information alert from the filtered information that contains a name, a price and a universal resource locator (URL), which specifies the location of the data source; formats the information alert into data blocks according to said information format; and transmits the formatted information alert over a wireless communication channel to a wireless device associated with a subscriber based upon the destination address and transmission schedule, wherein the alert activates the application to cause the information alert to display on the remote subscriber computer and to enable connection via the URL to the data source over the Internet when the wireless device is locally connected to the remote subscriber computer and the remote subscriber computer comes online.” This teaches that the enterprise organization initiates communication with the consumer computer.
See also col 12 ln 1-9: “That way, the operator will have the information reflecting the predicted reason for the customer's call (provided by the context message), and the customer does not have to convey the reason to the operator, which may be repetitive (e.g., if a process was started online via computer, and then required a telephone call, on the telephone call, the customer would not have to repeat the information already provided online).” Telephone call is via the communication channel to the consumer computing device that is associated with personal identifiable information of the consumer, the phone number.
Shimpi does not teach a token comprising details that describe the consumer concern and the consumer; extracting, from the token, the personal identifiable information of the consumer
Bajpay teaches a problem ticket that describes a priority level indictor and a customer identifier. See abstract.
Bajpay teaches a token comprising details that describe the consumer concern and the consumer in col 3 ln 5-16: “When the problem ticket 200 is created, the priority level indicator 202 and the customer identifier 204 are included in the problem ticket 200. The priority level indicator 202 and customer identifier 204 can be automatically included by referencing a database that contains information about the customer reporting the problem and information about the telecommunications services that are affected or included by a ticketing agent and/or system that creates the problem ticket 200. The ticketing agent and/or system can require that a priority level indicator and customer identifier be included in the problem ticket 200 for the problem ticket 200 to be a valid ticket.” Problem ticket teaches token comprising details because the token is defined by the details of the consumer concern and the consumer, which is the customer number.
Bajpay then teaches extracting, from the token, the personal identifiable information of the consumer in col 3 ln 54 – col 4 ln 10: “After being received in one of the workcenters 370, the problem ticket 300 is further routed by the router within the workcenter, using the customer identifier, to the appropriate division within the workcenter. In the special workcenter 340, the problem ticket is routed by the special workcenter router 348 using the customer identifier 340 to one of three divisions, 342, 344, or 346. In the regular workcenter 380, the problem ticket is routed by the regular workcenter router 388 using the customer identifier 360 to one of three divisions, 382, 384, or 386.
The routing within one of the workcenters 370 to a specific division using the customer identifier 360 can be based on variables such as region, customer type, and/or problem type. For example, if each of the divisions within the workcenters 370 resolves problem tickets 300 only for a particular region of the telecommunications network, a database can be referenced using the customer identifier to identify where the customer is located so that the problem ticket 300 can be routed to the appropriate division. In some embodiments, problem tickets 300 can be routed to divisions that resolve issues for only certain customers. In this situation, the problem ticket 300 can be properly routed by querying a database that indicates which divisions resolve problem tickets 300 for particular customers.” See also col 4 ln 40-43: “The information in the problem ticket 300 can be sent to the manager based on the customer identifier and using a database that links the customer identifier to the manager.” Using the customer identifier in the problem ticket teaches under a broadest reasonable interpretation extracting the personal identifiable information of the consumer because the consumer identifier is used from the ticket, and therefore is extracted. The customer identifier is the personal identifier information of the consumer.
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the transaction communication teaching of Shimpi with the token comprising details that describe the consumer concern and the consumer teaching of Bajpay because Bajpay teaches in col 1 ln 23-34: “Problem tickets, which describe problems with telecommunications services, are created in a general ticketing system that cannot distinguish between normal and high priority customers. The disconnect between the ticketing system which tracks problems and resources which resolve problems can result in an intolerable delay of the resolution of problems for high priority customers. Thus, there is a need for a method to route a problem ticket from a general ticketing system to workcenters and divisions within workcenters set aside for resolving the problems of high priority customers.” One would be motivated by this teaching to combine the references because one would want to identify high priority customers along with their related problems, and this would enable the further selling of premiums to high priority customers. See col 1 ln 12-24. As this would enhance revenue streams at telecom and related providers one would be motivated to modify Shimpi with Bajpay.
Per claim 2, Shimpi and Bajpay teach the limitations of claim 1, above. Shimpi further teaches assigning the score to each transaction of the plurality of transactions further comprises predicting, for each transaction, a likelihood that consumer computing device will request assistance with the transaction in col 7 ln 10-34: “In various embodiments, presentation layer 180 may comprise an insight parser 182, an arbitration engine 184, a communication decision engine 186, and/or a service system 188. Insight parser 182 may be configured to receive the ranked list of intent insights from servicing layer 172 that was comprised in API 165, read the rank of each intent insight of the ranked list (the rank may be a rank marker placed on each intent insight by predictive model 154), map the intent insights according to each rank, and transmit the mapped, ranked intent insights to arbitration engine 184. For example, mapping the intent insights by insight parser 182 may comprise insight parser 182 notating which intent insight is ranked as the highest priority, and then mapping or ordering the intent insights from there.” See also col 7 ln 35 – col 8 ln 6: “In various embodiments, arbitration engine 184 may implement business rules to determine which intent insights may be the highest ranking. For example, arbitration engine 184 may determine that the closest intent insight in time to the communication by the customer may be the highest ranking intent insight. As an example, a customer may access the associated customer profile online and an attempt to order a replacement transaction instrument, which may not be completed. In response, the customer may then call internal system 101 soon after attempting the online replacement to complete the replacement order”
Per claim 3, Shimpi and Bajpay teach the limitations of claim 2, above. Shimpi further teaches the score assigned to a transaction, of the plurality of transactions, is within one of: a first level of likelihood, wherein the score within the first level of likelihood indicates the consumer computing device will request assistance with the transaction; or a second level of likelihood, wherein the score within the second level of likelihood indicates the consumer computing device will not request assistance with the transaction in col 11 ln 14-44: “For example, if the action is something that can be taken care of over an automated service system 188, communication decision engine 186 may route the customer communication to an automated service system 188. In response, presentation layer 180 may present the intent prediction (step 214) to the customer (e.g., via a push notification). Such a presentation may comprise an accuracy inquiry, inquiring if the action reflected in the intent prediction is the reason for the customer's call. In response, the customer may indicate “yes” or “no” (in various embodiments, by pressing a button, speaking, or otherwise providing an electronic input to predictive communication system 120), which may be an accuracy response (customer feedback 152). Internal system 101 and/or predictive communication system 120 may receive the accuracy response (step 216), and transmit the results as customer feedback 152 for predictive model 154 to utilize. In response to receiving a positive accuracy response, presentation layer 180 may continue with the same service system 188. In response to receiving a negative accuracy response, presentation layer 180 may re-route the customer communication to another service system 188 (e.g., a selection menu to allow the customer to input the reason for the call).”
Per claim 4, Shimpi and Bajpay teach the limitations of claim 1, above. Shimpi further teaches generating the token, wherein the generating comprises determining whether the consumer computing device corresponds to a unique consumer identifier, and wherein the token is used to: transmit the details that describe the consumer concern and the consumer computing device; and confirm receipt of the consumer concern in col 9 ln 36 – col 10 ln 4: “" In various embodiments, the customer profile identifier may be requested of customer by internal system 101, and input by the customer. The system may require the customer to answer additional security questions or enter additional identifying data.
In response to identifying the customer profile, internal system and/or predictive communication system 120 may access the account activity data (step 206) associated with the customer profile (and/or a spouse account activity, supplemental account activity, etc). "
Per claim 6, Shimpi and Bajpay teach the limitations of claim 4, above. Shimpi further teaches based on determining the consumer computing device corresponds to the unique consumer identifier, requesting, from the consumer computing device, a code that corresponds to the unique consumer identifier, wherein the code comprises at least one of: a password that corresponds to the unique consumer identifier; or a personal identification number (PIN) that corresponds to the unique consumer identifier in col 9 ln 36-55: “In various embodiments, internal system 101 may identify the customer profile by receiving a customer profile identifier (e.g., a password, social security number, biometric (e.g., fingerprint, voice print or facial recognition from a video call), or the like) and matching the customer profile identifier with a saved identifier.”
Per claim 8, Shimpi and Bajpay teach the limitations of claim 1, above. Shimpi further teaches the details that describe the consumer concern may consist of at least one of: a transactional issue that the consumer computing device experienced; an enterprise organization service with which the consumer computing device experienced the transactional issue; or an enterprise organization program within which the consumer computing device experienced the transactional issue in col 10 ln 48 – col 11 ln 13: “As a further example, intent insights reflecting matters of fraud or transaction account decline may be prioritized higher (i.e., may be priority insights) than other types of intent insights or chronological rankings.”
Per claim 9, Shimpi and Bajpay teach the limitations of claim 1, above. Shimpi further teaches the details that describe the consumer computing device consist of at least one of: a phone number that corresponds to the consumer computing device; or a unique consumer identifier that corresponds to the consumer computing device in col 9 ln 36-55 “and matching the customer profile identifier with a saved identifier. In various embodiments, the customer profile identifier may be a telephone number, in which case, internal system 101 may automatically match the telephone number from which the telephone call is received with a stored telephone number associated with the customer profile, thereby identifying the customer profile and authenticating the identity of the customer.”
Per claim 10, Shimpi and Bajpay teach the limitations of claim 1, above. Shimpi further teaches based on determining the consumer concern does not correspond to transactions within the transaction history, requesting, from the consumer computing device, details that describe at least one transactional issue that consumer computing device experienced in col 12 ln 20-58: “ In various embodiments, the recommended action may be actions available to the customer, unrelated to the intent insight ranking. For example, predictive communication system 120 may recognize that a balance payment due data for a transaction account is on a day which the customer has travel plans (e.g., through internal system's 101 integration with an external channel 86 such as an airline). Therefore, arbitration engine 184 may determine that the recommended action may be payment of the balance. In response to determining a recommended action, presentation layer 180 may present the recommended action to the customer (step 306). The presentation may comprise routing the customer communication to the appropriate service system 188, such as, following the example above, a service system which may allow balance payment. Presentation layer 180, similar to method 200, may present an accuracy inquiry to see if the customer would like to take the recommended action, and the customer may input an accuracy response. “
Per claim 11, Shimpi and Bajpay teach the limitations of claim 1, above. Shimpi further teaches based on determining the transaction is not similar to the at least one previously received transaction, generating a solution to the consumer concern in col 12 ln 20-58: " In various embodiments, the recommended action may be actions available to the customer, unrelated to the intent insight ranking. For example, predictive communication system 120 may recognize that a balance payment due data for a transaction account is on a day which the customer has travel plans (e.g., through internal system's 101 integration with an external channel 86 such as an airline). Therefore, arbitration engine 184 may determine that the recommended action may be payment of the balance.
In response to determining a recommended action, presentation layer 180 may present the recommended action to the customer (step 306). The presentation may comprise routing the customer communication to the appropriate service system 188, such as, following the example above, a service system which may allow balance payment."
Per claim 12, Shimpi and Bajpay teach the limitations of claim 11, above. Shimpi further teaches the generating the solution to the consumer concern comprises identifying, from a plurality of enterprise organization programs and services, at least one enterprise organization program or at least one enterprise organization service that addresses at least one transactional issue indicated in the consumer concern in col 12 ln 45-58: “In response to determining a recommended action, presentation layer 180 may present the recommended action to the customer (step 306). The presentation may comprise routing the customer communication to the appropriate service system 188, such as, following the example above, a service system which may allow balance payment.”
Per claim 15, Shimpi and Bajpay teach the limitations of claim 1, above. Shimpi further teaches based on determining the transaction is similar to the at least one previously received transaction: identifying at least one solution that corresponds to the at least one previously received transaction; analyzing the at least one previously received transaction and the at least one solution that corresponds to the at least one previously received transaction; and transmitting the at least one solution that corresponds to the at least one previously received transaction to the consumer computing device in col 12 ln 20-58: “Predictive communication system 120 may determine a recommended action (step 304), or multiple recommended actions. Arbitration engine 184 may analyze the ranked intent insights received from context system 130, and determine a recommended action based on the business or analysis rules, similar to the analysis comprised in step 208 of method 200 (FIG. 2). The recommended action may be another action which the customer may wish to take during the customer communication. In various embodiments, the recommended action may be the second highest priority of the ranked invent insights. For example, a priority insight may have ranked highest (e.g., relating to fraud), but the closest intent insight temporally may have been a notice that an account balance payment is due (which was ranked second). Therefore, arbitration engine 184 may determine the recommended action may be paying the account balance. In various embodiments, the recommended action may be actions available to the customer, unrelated to the intent insight ranking. For example, predictive communication system 120 may recognize that a balance payment due data for a transaction account is on a day which the customer has travel plans (e.g., through internal system's 101 integration with an external channel 86 such as an airline). Therefore, arbitration engine 184 may determine that the recommended action may be payment of the balance.
In response to determining a recommended action, presentation layer 180 may present the recommended action to the customer (step 306). The presentation may comprise routing the customer communication to the appropriate service system 188, such as, following the example above, a service system which may allow balance payment. Presentation layer 180, similar to method 200, may present an accuracy inquiry to see if the customer would like to take the recommended action, and the customer may input an accuracy response. Based on the accuracy response, communication decision engine 186 may route the customer communication to the appropriate service system 188 (or allow the customer communication to remain at the current service system 188).”
Per claims 16, 18, and 20, which are similar in scope, Shimpi and Bajpay teach the limitations of claims 1, 17, and 19, above. Shimpi further teaches the receiving the consumer concern further causes the computing platform to receive, by the enterprise organization computing device, a phone call from the consumer computing device in col 7 ln 35- col 8 ln 6: “In various embodiments, arbitration engine 184 may implement business rules to determine which intent insights may be the highest ranking. For example, arbitration engine 184 may determine that the closest intent insight in time to the communication by the customer may be the highest ranking intent insight. As an example, a customer may access the associated customer profile online and an attempt to order a replacement transaction instrument, which may not be completed. In response, the customer may then call internal system 101 soon after attempting the online replacement to complete the replacement order. Arbitration engine 184 may recognize the temporal proximity of the intent insight reflecting the online attempted replacement (which may have been received by predictive communication system 120 from systems of record 82 and/or internal channels 84), and the customer call. Therefore, arbitration engine 184 may determine that the highest ranking intent insight is the most recent intent insight regarding the attempted online transaction instrument replacement. Arbitration engine 184 may also determine that an intent insight of the plurality of intent insights received by communication response system 170 may be a priority insight. As examples of priority insights, the business rules in arbitration engine 184 for prioritizing intent insights may cause intent insights related to fraud to rank highest, or certain correlations may cause an intent insight to be ranked higher than another that is temporally closer to the customer's communication. As an example, arbitration engine 184 may recognize that an intent insight reflecting an account payment is always conducted on a certain day of the month by the customer calling into internal system 101. Therefore, if the customer calls internal system 101 on that day of the month, the intent insight reflecting account payment may be ranked higher than other intent insights having different characteristics. By analyzing the ranking of the intent contexts, arbitration engine 184 may determine an intent prediction (i.e., the most likely reason for a customer's communication (e.g., telephone call)). Arbitration engine 184 may transmit the intent prediction to communication decision engine 186.” See also col 10 ln 48 – col 11 ln 14.
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.
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) 5 and 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shimpi et al., US 12058219 B1 (“Shimpi”), in view of Bajpay et al., US Pat No 7357301 B1 (“Bajpay”), further in view of Kirillin et al., US PGPUB 20130297513 A1 (“Kirillin”).
Per claim 5, Shimpi and Bajpay teach the limitations of claim 4, above. Shimpi does not teach based on determining the consumer computing device does not correspond to the unique consumer identifier, requesting personal identifiable information from the consumer computing device, wherein the personal identifiable information comprises at least one of: a phone number that is registered with the enterprise organization and is associated with the consumer computing device; the unique consumer identifier that is registered with the enterprise organization and is associated with the consumer computing device; or a unique party identification number that is registered with the enterprise organization and is associated with the consumer computing device.
Kirillin teaches multi factor security. See abstract.
Kirillin teaches based on determining the consumer computing device does not correspond to the unique consumer identifier, requesting personal identifiable information from the consumer computing device, wherein the personal identifiable information comprises at least one of: a phone number that is registered with the enterprise organization and is associated with the consumer computing device; the unique consumer identifier that is registered with the enterprise organization and is associated with the consumer computing device; or a unique party identification number that is registered with the enterprise organization and is associated with the consumer computing device in par 048: “At 410, SPOC server 307 can authorize customer 301 as a registered bank customer based on the login information, and find their user id of customer 301. If the login information does not match a known bank customer, SPOC server 307 can inform bank server (UD) 403 which can inform unauthorized client device 401 that the user is not authenticated and the session can be terminated. If the login information does match a known bank customer, SPOC server 307 can send the user id to bank server (UD) 403 at 412. At 414, bank server (UD) 403 can establish a user session with a session id, generate a RAND to prevent a replay of the session as a client accessing the session would need to know RAND. RAND can then be assigned to the session id. At 416, the session id and RAND can be sent to unauthorized client device 401. At 418, customer 301 is logged in and can see the balance of any account he or she holds, but cannot perform banking operations.” See also pars 47 and 49.
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the transaction authentication and issue resolution teaching of Shimpi with the authentication teaching of Kirillin because Kirillin teaches “With customer expectations demanding multiple device connectivity, detecting fraudulent access to a customer’s accounts becomes more complex. Creating an online hub for customers to access their accounts necessarily involves creating a public portal capable of granting a plurality of customers’ access to their accounts. This public portal is also capable of being accessed by those without accounts such as those seeking to fraudulently access a customer’s account. One way of preventing such fraudulent access is through restricting account access to authenticated users and restricting the performance of banking operations to those who have passed a multi factor authentication process. However, protocols must be established to prevent improper access to bank accounts and improper performance of banking operations.” Par 003. Kirillin’s taught advantage, which would motivate one to combine, is that customers are able to interact with the bank using multiple forms but are also protected from fraud or other bad actors. One would therefore be motivated to combine Shimpi and Kirillin because one would be able to have more flexibility in connecting to a bank, for example, but the security would be preserved. Therefore, for these reasons, one would be motivated to modify Shimpi with Kirillin.
Per claim 7, Shimpi and Bajpay teach the limitations of claim 6, above. Shimpi does not teach based on determining the code fails to correspond to the unique consumer identifier, transmitting, to the consumer computing device, a notification indicating the consumer concern cannot be processed; or based on determining the code corresponds to the unique consumer identifier, transmitting the token to the consumer computing device.
Kirillin teaches based on determining the code fails to correspond to the unique consumer identifier, transmitting, to the consumer computing device, a notification indicating the consumer concern cannot be processed; or based on determining the code corresponds to the unique consumer identifier, transmitting the token to the consumer computing device in par 048: “At 410, SPOC server 307 can authorize customer 301 as a registered bank customer based on the login information, and find their user id of customer 301. If the login information does not match a known bank customer, SPOC server 307 can inform bank server (UD) 403 which can inform unauthorized client device 401 that the user is not authenticated and the session can be terminated. If the login information does match a known bank customer, SPOC server 307 can send the user id to bank server (UD) 403 at 412. At 414, bank server (UD) 403 can establish a user session with a session id, generate a RAND to prevent a replay of the session as a client accessing the session would need to know RAND. RAND can then be assigned to the session id. At 416, the session id and RAND can be sent to unauthorized client device 401. At 418, customer 301 is logged in and can see the balance of any account he or she holds, but cannot perform banking operations.”
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the transaction authentication and issue resolution teaching of Shimpi with the authentication teaching of Kirillin because Kirillin teaches “With customer expectations demanding multiple device connectivity, detecting fraudulent access to a customer’s accounts becomes more complex. Creating an online hub for customers to access their accounts necessarily involves creating a public portal capable of granting a plurality of customers’ access to their accounts. This public portal is also capable of being accessed by those without accounts such as those seeking to fraudulently access a customer’s account. One way of preventing such fraudulent access is through restricting account access to authenticated users and restricting the performance of banking operations to those who have passed a multi factor authentication process. However, protocols must be established to prevent improper access to bank accounts and improper performance of banking operations.” Par 003. Kirillin’s taught advantage, which would motivate one to combine, is that customers are able to interact with the bank using multiple forms but are also protected from fraud or other bad actors. One would therefore be motivated to combine Shimpi and Kirillin because one would be able to have more flexibility in connecting to a bank, for example, but the security would be preserved. Therefore, for these reasons, one would be motivated to modify Shimpi with Kirillin.
Claim(s) 13 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shimpi et al., US 12058219 B1 (“Shimpi”), in view of Bajpay et al., US Pat No 7357301 B1 (“Bajpay”), further in view of Sait, 20210049489 A1 (“Sait”).
Per claim 13, Shimpi and Bajpay teach the limitations of claim 11, above. Shimpi does not teach the generating the solution to the consumer concern comprises: identifying at least one of: an enterprise organization department that offers at least one enterprise organization service with which the consumer computing device experienced a transaction issue; or an enterprise organization department that offers at least one enterprise organization program within which the consumer computing device experienced the transactional issue; parsing enterprise organization procedures and protocols that correspond to the enterprise organization department; determining, based on the parsing, whether the enterprise organization procedures and protocols resolve at least one transactional issue indicated in the consumer concern; and based on determining the enterprise organization procedures and protocols resolve the at least one transactional issue indicated in the consumer concern, transmitting the enterprise organization procedures and protocols to the consumer computing device.
Sait teaches using stochastic modeling for arriving at resolution steps. See abstract.
Sait teaches the generating the solution to the consumer concern comprises: identifying at least one of: an enterprise organization department that offers at least one enterprise organization service with which the consumer computing device experienced a transaction issue; or an enterprise organization department that offers at least one enterprise organization program within which the consumer computing device experienced the transactional issue; parsing enterprise organization procedures and protocols that correspond to the enterprise organization department; determining, based on the parsing, whether the enterprise organization procedures and protocols resolve at least one transactional issue indicated in the consumer concern; and based on determining the enterprise organization procedures and protocols resolve the at least one transactional issue indicated in the consumer concern, transmitting the enterprise organization procedures and protocols to the consumer computing device in par 013: “The technique based on the present subject matter operates in three steps. As a first step, a knowledge representation for each issue is created in terms of the relationships between resolution steps employed by the customer care agents. This is so done by analyzing case logs created by multiple customer care agents for that issue. Thereafter, as a second step, the resolution steps in the knowledge representation may be mapped with standard resolution steps existing in a library. Finally, as a third step, for a given issue, a list of resolution steps for providing appropriate resolution may be identified from the set of mapped and unmapped resolution steps in the knowledge representation.” See also par 045: “ In one example, the mapping engine 308 map the unique resolution steps and the standard resolution steps at three levels. At a first level, the mapping engine 308 may fetch a manual from the library 114 that corresponds to the specific issue and for the specific product. Once the manual is fetched, the mapping engine 308 selects one unique resolution step from the knowledge representation and searches for a corresponding standard resolution step in the library. In one example, the mapping engine 308 may employ techniques, like Word2Vec for the mapping. In one example, the mapping engine 308 may parse each resolution step and may assign a vector to each word in the resolution step. Once each word is assigned a vector, the mapping engine 308 may compute a vector for the resolution step by computing an average of the vectors of the words in the resolution step. Thereafter, the mapping engine 308 may compare the computed vector with pre-defined vectors for the standard resolutions steps. In one example, the mapping engine 308 may employ cosine similarity technique to find a match between the vector of the resolution step and the pre-defined vectors of the standard resolution steps to identify the standard resolution step. Once the mapping engine 308 finds the corresponding standard resolution step, the mapping engine 308 may associate a documentation, corresponding to the identified unique resolution step, with the unique resolution step whose mapping is being done. This mapping is performed for each unique resolution step in the knowledge representation. “ See also par 048: “ Once the system 102 is prepared in the manner explained above, the system 102 may cater to queries and provide appropriate solutions to the queries, in accordance with the present subject matter. Accordingly, in an aspect, the query engine 310 may receive a query from a user. The query engine 310, for instance, may receive the query from one or more computing devices 104, 106, 108, 110. Once the query engine 310 receives the query, the query engine 310 may identify an issue from the query. The query engine 310 may parse the query to identify the query and identify the issue that the query is associated to the issue. In one example, the query engine 310 may perform parsing of the query using techniques, such as Word2Vec. In one example, the query engine 310 may parse the query to identify the words and assign a vector to each query. Thereafter, the query engine 310 may compute a vector for the query by computing an average of the assigned vectors of each word in the query. Once the query engine 310 obtains a vector for the query, the query engine 310 may compare the vector with pre-calculated vector based on sample queries. The sample queries are the queries related to pre-defined issues. Once the query engine 310 find a match with a corresponding sample query, the query engine 310 may identify the issue. Once the query engine 310 identifies the issue, the resolution generation engine 206 may search for a knowledge representation in the knowledge representation database 116 that corresponds to the identified issue. In one example, the resolution generation engine 206 may search for a knowledge representation that corresponds to the issue identified from the query. Once the resolution generation engine 206 identifies the knowledge representation that corresponds to the issue, the resolution generation engine 206 fetches the identified knowledge representation. Further, the resolution generation engine 206 may provide a primary solution for the issue in form a list of unique resolution step from the in response to the query based on the computed probabilities of transition.”
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the transaction issue teaching of Shimpi with the resolution and parsing teaching of Sait because Sait teaches: “The current customer support systems may assist the customer care agents in the resolving different issues. However, the customer support system may not get updated with new resolution steps employed by the customer care agents. In other words, the database that the customer support system relies on is static and provide the standard resolution step.” Par 011. Sait’s teachings overcome the static nature of manuals and resolutions through stochastics and one would be motivated to modify Shimpi with Sait because this would make resolution finding more adaptable to what works better over time. As this would improve finding resolutions for people one would be motivated to modify Shimpi with Sait.
Per claim 14, Shimpi, Bajpay, and Sait teach the limitations of claim 13, above. Shimpi does not teach based on determining the enterprise organization procedures and protocols do not resolve the at least one transactional issue indicated in the consumer concern, modifying the enterprise organization procedures and protocols to address the at least one transactional issue.
Sait teaches based on determining the enterprise organization procedures and protocols do not resolve the at least one transactional issue indicated in the consumer concern, modifying the enterprise organization procedures and protocols to address the at least one transactional issue in pars 051-052: “”In one example, the resolution generation engine 206 may start from the last unique resolution step that has been successfully performed and completed by the user. Thereafter, in an example, the resolution generation engine 206 may check for the probabilities of transition to other unique resolution step from the last unique resolution step. Accordingly, the resolution generation engine 206 may select the unique resolution steps that have higher probabilities of transition with respect to the last successfully performed unique resolution step. Further, the resolution generation engine 206 may present the selected unique resolution steps as a new list in order of higher probabilities of transition. In other example, the resolution generation engine 206 may provide an alternate unique resolution step, again, also referred to as the secondary solution for the issue, from amongst the list of resolution steps as a replacement for a previously provided unique resolution step that is incapable of providing the solution for the issue or that the user is unable to perform. Thereafter, the user may be instructed to continue performing the unique resolution steps in the list until the issue is resolved.
The operation for providing the resolution for the query may be recorded in a case log and the same case log is stored in the case log database 112. The case log may then be analyzed by the analysis engine 204 as mentioned above to update the knowledge representation. As a result, the system 102 may constantly learn in parallel.”
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the transaction issue teaching of Shimpi with the resolution and parsing teaching of Sait because Sait teaches: “The current customer support systems may assist the customer care agents in the resolving different issues. However, the customer support system may not get updated with new resolution steps employed by the customer care agents. In other words, the database that the customer support system relies on is static and provide the standard resolution step.” Par 011. Sait’s teachings overcome the static nature of manuals and resolutions through stochastics and one would be motivated to modify Shimpi with Sait because this would make resolution finding more adaptable to what works better over time. As this would improve finding resolutions for people one would be motivated to modify Shimpi with Sait.
Therefore, claims 1-20 are rejected under 35 USC 103.
Response to Remarks:
Applicant writes:
Claims 1-20 stand rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception without significantly more. The Office Action asserts that the claims are directed to "after sales customer support" which the Office Action asserts fails into the "certain methods of organizing human activity" category of abstract ideas. Office Action at p. 3. Applicant disagrees and traverses the rejection of the claims under 35 U.S.C. § 101.
With respect to the assertion that the claims recite an abstract idea, Applicant submits that the claims, at best, involve an exception and do not recite an exception. In this regard, the MPEP states that "Examiners should ... be careful to distinguish claims that recite an exception (which require further eligibility analysis) and claims that merely involve an exception (which are eligible and do not require further eligibility analysis)." MPEP § 2106.04(II)(A)(1) (emphasis in original). The claims are directed to continuously monitoring one or more consumer computing devices to detect transactions, evaluating the transactions for issues, generating solutions to those issues and transmitting and executing the solutions via a communication channel selected based on data extracted from a generated token. While the present claims may merely involve an exception, they do not recite an exception. The claims, when taken as a whole, recite steps that include a technical solution to an internet-centric problem. That is, the claims recite features for predicting and controlling identification and communication of solutions to user devices. The claims clearly do not recite an abstract idea.
Examiner responds:
The traversal is noted. The argument is that the claims at best involve an exception and do not recite an exception. Applicant has characterized the claims as “continuously monitoring one or more consumer computing devices to detect transactions, evaluating the transactions for issues, generating solutions to those issues and transmitting and executing the solutions via a communication channel selected based on data extracted from a generated token.” With respect, the central issue in this sentence is that transactions are monitored, evaluated for issues, and solutions are generated for those issues, with an add-on that does not match the claims of “transmitting and executing the solutions via a communication channel selected based on data extracted from a generated token” There’s only “instructions to initiate communication with the consumer computing device to resolve the consumer concern. The execution is happening by someone somewhere else, but not claimed. There is no solution executed. Monitoring transactions, evaluating for issues, and generating solutions for those issues are the nut of the abstract idea which examiner feels is validated as “after sales customer support.” As this describes a non technical interaction between people in a commercial setting, Examiner maintains that this recites an abstract idea, following all guidance.
Applicant writes:
However, even if the Office considers the claims to recite elements from one of the enumerated groupings of abstract ideas-which Applicant does not concede-the claims are not "directed to" an abstract idea because the claims integrate any alleged abstract idea into "a practical application." The 2019 Guidance explains that "if a claim recites a judicial exception," such as "an abstract idea as grouped in Section I, above, it must then be analyzed to determine whether the recited judicial exception is integrated into a practical application of that exception. A claim is not 'directed to' a judicial exception, and thus is patent eligible, if the claim as a whole integrates the recited judicial exception into a practical application of that exception." 2019 Guidance at 13.
The claims clearly recite a practical application of any alleged abstract idea. For example, claim 1 recites multiple, specific, detailed, unique steps performed at particular devices that continuously monitor one or more consumer computing devices to detect transactions, evaluate the transactions for issues, generating solutions to those issues and transmitting and executing the solutions via a communication channel selected based on data extracted from a generated token. The claims are necessarily rooted in computer technology.
Examiner responds:
The steps claimed are largely for the abstract idea with communication between computers. The recitation of token under a broadest reasonable interpretation is also a part of the abstract idea. Applicant has not explained how a token is not understood as a piece of information that identifies something, as is taught by Shimpi and Bajpay. “multiple, specific, detailed, unique steps” are not persuasive arguments as in this instance they are abstract idea steps that may be all of these descriptors but only involve additional elements at an applied level. “performed at particular devices” is only the case where various non-technical labels are applied to generic computing devices which means that a few PCs that are talking over the internet would teach what Applicant claims. The claims being necessarily rooted in computer technology is half of a DDR argument, the problem is that while computers are necessary for the claims, there is no solution being claimed that requires computers as this is customer service support that could happen between people.
Applicant writes:
The features of the claims clearly impose a meaningful limit on the judicial exception such that the claim is "more than a drafting effort designed to monopolize the judicial exception." See 2019 Guidance at 13-14. In other words, claim 1 does not monopolize every possible method of "after sales customer support," or any other alleged abstract idea, but instead is limited to a practical application of doing so, including particular steps relying on particular devices and performed in a particular order.
Examiner responds:
Applicant’s claims presupposes a practical application however because Examiner has shown that the additional elements are apply it elements, there is no practical application. There are no particular devices claimed considering that Applicant has claimed a scope of any and all PCs that could perform these tasks. Performing steps in a particular order has no basis in 101 but is simply how method claims are constructed and related device and CRM claims. Therefore this is not persuasive. As the additional elements were considered both individually and as a combination, and found to be apply it elements, see MPEP 2106.05(e), there is no meaningful limitation recited.
Applicant writes:
As discussed in the October 2019 Update, "the limitations containing the judicial exception, as well as the additional elements in the claim besides the judicial exception need to be evaluated together to determine whether the claim integrates the judicial exception into a practical application. The additional limitations should not be evaluated in a vacuum..." October 2019 Update at p. 12. "[T]ak[ing into consideration all the claim limitations and how those limitations interact and impact each other," as required in the October 2019 update when evaluating whether the exception is integrated into a practical application, it is clear that the claims integrate any alleged abstract idea into a practical application. (Emphasis added). Therefore, claim 1 is not "directed to" a judicial exception, and thus is patent eligible. See 2019 Guidance at 13.
The 2019 Guidance explains that when a claim integrates a recited exception "into a practical application of the exception, then the claim is eligible at Prong Two of revised Step 2A. This concludes the eligibility analysis." 2019 Guidance at 16. But if the claim is not patent eligible at Step 2A, further analysis is still required under Step 2B. See 2019 Guidance at 16; see also 22-24. "Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself." MPEP 2106.05.
Examiner responds:
The claims and their additional elements were not interpreted in a vacuum, as the abstract idea correctly identified, characterized, then the additional elements applied by the claims then analyzed alone and in combination and therefore ensured that there was no practical application or significantly more claimed. This was written into the rejection which is maintained.
Applicant writes:
When the language of each claim feature is considered, both alone and in combination, it is clear that the claims recite significantly more than merely "after sales customer support," or any alleged abstract idea. See MPEP § 2106.05(a) (noting that "it is critical that examiners look at the claim 'as a whole,' in other words, the claim should be evaluated 'as an ordered combination, without ignoring the requirements of the individual steps"'). Further, the claim features are necessarily rooted in computer technology, and include particular processes and devices for continuously monitoring one or more consumer computing devices to detect transactions, evaluating the transactions for issues, generating solutions to those issues and transmitting and executing the solutions via a communication channel selected based on data extracted from a generated token. For instance, features such as, "continuously monitoring one or more consumer computing devices,""detecting, based on the continuous monitoring, a plurality of transactions between a consumer computing device of the one or more consumer computing devices and an enterprise organization computing device,""receiving, from the enterprise organization computing device, a token comprising details that describe the consumer concern and the consumer computing device, wherein the details that describe the consumer computing device include personal identifiable information of a consumer associated with the consumer computing device,""extracting, from the token, the personal identifiable information of the consumer associated with the consumer computing device," and "transmitting, to the enterprise organization computing device, instructions to initiate communication with the consumer computing device to resolve the consumer concern, wherein transmitting the instructions to initiate communication with the consumer computing device causes the enterprise organization to initiate communication with the consumer computing device via a communication channel associated with the personal identifiable information of the consumer associated with the consumer computing device and transmit, to the consumer computing device and via the communication channel, the generated solution for execution to resolve the consumer concern," are significantly more than any alleged abstract idea.
Examiner writes:
By Examining the particulars of these claims, whether abstract idea (information limitations and customer support steps) or practical application (of the particular consumer computing device, which would be difficult to distinguish technically from the enterprise organization computing device, being they are both computing devices only further described by who they belong to), the claim as a whole was examined, and though Applicant argues that significantly more was claimed, Applicant does not explain what was significantly more claimed than the abstract idea. Examiner acknowledges that several limitations are repeated here but Examiner carefully considered these limitations and the analysis is in the rejection above. Examiner has reconsidered these limitations but is unpersuaded that on their face they are significantly more than the abstract idea, for the reasons stated in the rejection above. For these reasons the 101 – judicial exception rejection is maintained.
35 USC 103
Applicant has written remarks however these are for the newly amended claims which required further search and consideration. After search and consideration new art is applied rendering the arguments moot.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RICHARD W. CRANDALL whose telephone number is (313)446-6562. The examiner can normally be reached M - F, 8:00 AM - 5:00 PM.
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, Anita Coupe can be reached at (571) 270-3614. 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.
/RICHARD W. CRANDALL/ Primary Examiner, Art Unit 3619
Prosecution Insights