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 .
DETAILED ACTION
This communication is a Final Office Action in response to communications received on 10/30/25.
Claims 1, 8 and 15 have been amended.
Therefore, Claims 1-20 are now pending and have been addressed below.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (an abstract idea) without significantly more.
Step 1: Identifying Statutory Categories
In the instant case, claims 1-7 are directed to a system, claims 15-20 are directed to a non-transitory medium and claims 8-14 are directed to a method. Thus, the claims fall within one of the four statutory categories. Nevertheless, the claims fall within the judicial exception of an abstract idea.
Step 2A: Prong 1 Identifying a Judicial Exception
Under Step 2A, prong 1, Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention recites an abstract idea without significantly more. Independent claims 1, 8 and 15 recite methods that the return request corresponding to a return of an item associated with a transaction; identify stored data associated with the transaction, the stored data comprising user data, merchant data, and issuer data; generate a plurality of prompts associated with the stored data; apply the plurality of prompts; determine a return recommendation based at least in part on an output and based at least in part on a set of communication data associated with the user; generate comprising the return recommendation; and transmit the recommendation (Claim 1); registering a user with a return management service in response to receiving a registration request associated with the user, the return management service functioning as an intermediary between the user and a merchant with respect to one or more item returns; obtaining user data associated with the user based at least in part on permissions granted during registration of the user with the return management service; obtaining merchant data associated with at least one or more merchants; obtaining issuer data associated with one or more issuers of payment instruments of the user; generate training inputs based at least in part on the user data, the merchant data, and the issuer data; and make one or more recommendations associated with the one or more item returns (Claim 8) and detect a transaction between a user and a merchant; obtain user data associated with the user during a time window associated with a date of the transaction including a set of communication data associated with the user communicating with the merchant; poll a merchant computing environment for merchant data associated with the merchant during the time window; obtain issuer data associated with an issuer of a payment instrument used during the transaction (Claim 15)
These limitations as drafted, are a process that, under its broadest reasonable interpretation, covers methods of organizing human activity (including commercial interactions such as business relations, managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) including interaction between person and computer), but for the recitation of generic computer components. That is, other than reciting the structural elements (such as a computing device comprising a processor and a memory; a client device , a large language model (LLM), a user interface (Claim 1); a client device, training a large language model (Claim 8); memory, processor (Claim 15)), the claims are directed to providing return recommendations based on transaction data. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation of organizing human activity but for the recitation of generic computer components, the claim recites an abstract idea.
Step 2A Prong 2 - This judicial exception is not integrated into a practical application because the claim merely describes how to generally “apply” the concept of receiving data, analyzing it, and providing return recommendation. In particular, the claims only recites the additional element – a computing device comprising a processor and a memory; a client device , a large language model (LLM), a user interface (Claim 1); a client device, training a large language model (Claim 8); memory, processor (Claim 15). The additional elements are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component or merely uses a computer as a tool to perform an abstract idea, as discussed in MPEP 2106.05(f). Furthermore, the limitations of “using a large language model trained using a set of communication data (Claim 1); training a large language model (LLM) based at least in part on the training inputs (Claim 8)”, are simply application of a computer model, itself an abstract idea. Furthermore, such training and applying of a model is no more than putting data into a black box machine learning operation, devoid of technological implementation and application details. Each step requires a generic computer to perform generic computer functions. The additional element in claim 1 of ‘a user interface’ to receive and display data associated with the abstract idea, is merely an example of generally linking the abstract idea to a particular technological environment or field of use as outlined in MPEP 2106.05(h). User interfaces are recited so generally that they do not meaningfully limit the abstract idea. Simply implementing the abstract idea on generic components is not a practical application of the abstract idea. Accordingly, these additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
In addition, limitations reciting data gathering such as “receiving a return request” (Claim 1) is insignificant pre-solution activity that merely gather data and, therefore, do not integrate the exception into a practical application for that additional reason. See In re Bilski, 545 F.3d 943, 963 (Fed. Cir. 2008) (en bane), aff’d on other grounds, 561 U.S. 593 (2010) (characterizing data gathering steps as insignificant extra-solution activity); see also CyberSource, 654 F.3d at 1371-72 (noting that even if some physical steps are required to obtain information from a database (e.g., entering a query via a keyboard, clicking a mouse), such data-gathering steps cannot alone confer patentability); GIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015) (presenting offers and gathering statistics amounted to mere data gathering). Accord Guidance, 84 Fed. Reg. at 55 (citing MPEP § 2106.05(g)). Also, the limitations reciting “transmitting the recommendation/user interface…(Claim 1).; store the user data…with transaction (Claim 15)” are merely a post-solution step of transmitting/storing data output—a nominal addition to the claim that does not meaningfully limit the claim. Therefore, these limitations are insignificant extra-solution activity. See MPEP 2106.05(g).
The claims are directed to an abstract idea. When considered in combination, the claims do not amount to improvements to the functioning of a computer, or to any other technology or technical field, as discussed in MPEP 2106.05(a), applying the judicial exception with, or by use of, a particular machine, as discussed in MPEP 2106.05(b), effecting a transformation or reduction of a particular article to a different state or thing, as discussed in MPEP 2106.05(c), or applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception, as discussed in MPEP 2106.05(e). Accordingly, the additional elements do not integrate the abstract idea into a practical application because they does not impose any meaningful limits on practicing the abstract idea. Therefore, the claims are directed to an abstract idea.
Step 2B: Considering Additional Elements
The claimed invention is directed to an abstract idea without significantly more. The claim does not include additional elements that are sufficient to amount significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the claims describe how to generally “apply” to; provide return recommendations based on transaction data. The claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception because mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The independent claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Even when viewed as a whole, nothing in the claim adds significantly more (i.e., an inventive concept) to the abstract idea. The claims are not patent eligible. The dependent claim(s) when analyzed as a whole are held to be patent ineligible under 35 U.S.C. 101 because the additional recited limitation(s) fail to establish that the claim(s) is/are not directed to an abstract idea. The dependent claims are not significantly more because they are part of the identified judicial exception. See MPEP 2106.05(g). The claims are not patent eligible. With respect to a computing device comprising a processor and a memory; a client device , a large language model (LLM), a user interface (Claim 1); a client device, training a large language model (Claim 8); memory, processor (Claim 15), these limitations are described in Applicant’s own specification as generic and conventional elements. See Applicants specification, Paragraph [0052] details “ Such a computer system can be embodied in the form of a personal computer (e.g., a desktop computer, a laptop computer, or similar device), a mobile computing device.” These are basic computer elements applied merely to carry out data processing such as, discussed above, receiving, analyzing, transmitting and displaying data, which fall under well-understood, routine and conventional functions of generic computers. As discussed in Step 2A, Prong Two above, the recitations of “receiving steps” and “transmitting/storing steps” amount to receiving or transmitting/storing data over a network and are well understood, routine, conventional activity. See MPEP 2106.05(d), subsection II. Furthermore, the use of such generic computers to receive or transmit data over a network has been identified as a well understood, routine and conventional activity by the courts. See Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AVAuto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); Presenting offers and gathering statistics, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93, OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result-a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added)); Also see MPEP 2106.05(d) discussing elements that the courts have recognized as well-understood, routine and conventional activities in particular fields. Lastly, the additional elements provides only a result-oriented solution which lacks details as to how the computer performs the claimed abstract idea. Therefore, the additional elements amount to mere instructions to apply the exception. See MPEP 2106.05(f).
Furthermore, these steps/components are not explicitly recited and therefore must be construed at the highest level of generality and amount to mere instructions to implement the abstract idea on a computer. Therefore, the claimed invention does not demonstrate a technologically rooted solution to a computer-centric problem or recite an improvement to another technology or technical field, an improvement to the function of any computer itself, applying the exception with, or by use of, a particular machine, effect a transformation or reduction of a particular article to a different state or thing, add a specific limitation other than what is well-understood, routine and conventional in the field, add unconventional steps that confine the claim to a particular useful application, or provide meaningful limitations beyond generally linking an abstract idea to a particular technological environment such as computing. Viewing the limitations as an ordered combination does not add anything further than looking at the limitations individually. Taking the additional claimed elements individually and in combination, the computer components at each step of the process perform purely generic computer functions. Viewed as a whole, the claims do not purport to improve the functioning of the computer itself, or to improve any other technology or technical field. Use of an unspecified, generic computer does not transform an abstract idea into a patent-eligible invention. Thus, the claims do not amount to significantly more than the abstract idea itself.
Dependent claims 2-7, 9-14, and 16-20 add additional limitations, but these only serve to further limit the abstract idea by further defining type of user data, merchant data, issuer data, and hence are nonetheless directed towards fundamentally the same abstract idea as Independent claims. The claims do not provide any new additional elements beyond abstract idea. Therefore, whether analyzed individually or as an ordered combination, they fail to integrate the abstract idea into a practical application or provide significantly more than the abstract idea. The limitations of using an LLM merely adds the words apply it (or an equivalent) with the judicial exception , or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea as discussed in MPEP 2106.05(f). The receiving function is similar to a data gathering function. The generating function is a mental process or organizing human activity (and is also a generic computer function). The displaying/transmitting function is a generic computer function and is also considered as an insignificant post solution activity. The dependent claims do not integrate into a practical application. As such, the additional elements individually or in combination do not integrate the exception into a practical application, but rather, the recitation of any additional element amounts to merely reciting the words “apply it” (or equivalent) with the judicial exception, or merely includes instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea (See MPEP 2106.05(f)). The dependent claims also do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements are merely used to apply the abstract idea to a technological environment. These limitations do not include an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of the abstract idea to a particular technological environment. See MPEP 2106.05d. Thus, the claims do not add significantly more to an abstract idea. The claims are ineligible. Therefore, since there are no limitations in the claim that transform the exception into a patent eligible application such that the claim amounts to significantly more than the exception itself, the claims are rejected under 35 USC 101 as being directed to non-statutory subject matter. See (Alice Corporation Pty. Ltd. v. CLS Bank International, et al.).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 7 are rejected under 35 U.S.C. 103 as being unpatentable over Tessler et al. (US 2023/0401528 A1) in view of Ghoche (US 2024/0386213 A1)
Regarding Claim 1, Tessler discloses the system (Abstract systems and methods of facilitating product return), comprising:
Tessler discloses a computing device comprising a processor and a memory ([0003] a system that comprises a processor coupled to a memory that includes instructions); and machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to at least:
Tessler discloses receive a return request associated with a user ([0022] If the probability that the user 110 will return a product meets a predetermined threshold, the product can be considered (e.g., identified) as a return candidate, and notifications (return request) can be sent to the user 110 to remind the user 110 to return this return candidate (e.g., product), [0034] Upon initiation of returns (return request), the refund notification component 320 can render the timing of refunds to the user 110. The refund notification component 320 can display the timing of the refunds in the transaction history or render notifications), the return request corresponding to a return of an item associated with a transaction ([0019] Information on products purchased, such as information on transactions (e.g., purchase and return information) and credit backs (e.g., refund information), can be collected by return window calculation system 200 (e.g., return window calculating system) via an application or browser extension installed on the electronic device 115. [0025] The analysis component 210 can identify a plurality of products purchased by the user 110 from the merchant 120. The user 110 can make purchases and returns using electronic device 115, which can be installed with an application or browser extension for making payments or collecting receipt information containing the products purchased or returned. [0027] Return information can include the product returned, the date or time of the return, and the amount being credited back, among other things. The refund information can be information such as the source (and destination) of the refund (e.g., the merchant 120 who is providing the refund and to which account), the date or time the refund is credited back to the user 110’s charge account, and the amount credited back, among other things.;
Tessler discloses identify stored data associated with the transaction, the stored data comprising user data, merchant data, and issuer data ([0004] transaction data that captures purchase debits and return credits for products and merchants, and return history of the user identifying a product purchased by a user from a merchant from transaction data of the user [0019] User 110 (e.g., a customer) can make purchases from merchant 120 using electronic device 115 (e.g., mobile device, computer, laptop, tablet, IoT (Internet of Things) device). Information on products purchased, such as information on transactions (e.g., purchase and return information) and credit backs (e.g., refund information), can be collected by return window calculation system 200 (e.g., return window calculating system) via an application or browser extension installed on the electronic device 115. Obtaining information, such as the products purchased, the merchant data, the date or time of the purchase, and the purchase amount of the products. The payment application and the browser extension can also be used to collect returned transaction data and retain an electronic copy of the return receipt, thereby obtaining information, such as the products returned, the merchant providing the credit back (e.g., the source and destination of the refund), the date or time of the return, and the amount to be credited back, among other things. [0027]Return information can include the product returned, the date or time of the return, and the amount being credited back, among other things. The refund information can be information such as the source (and destination) of the refund (e.g., the merchant 120 who is providing the refund and to which account), the date or time the refund is credited back to the user 110’s charge account, and the amount credited back, among other things.);
Tessler discloses generate a plurality of prompts associated with the stored data ([0022] If the probability that the user 110 will return a product meets a predetermined threshold, the product can be considered (e.g., identified) as a return candidate, and notifications can be sent to the user 110 to remind the user 110 (prompts) to return this return candidate (e.g., product). Frequency and method of notification delivery can also be triggered upon the level of probability determined.);
Tessler discloses apply the plurality of prompts to machine learning model ([0038] At 460, the computer-implemented method 400 can comprise invoking (e.g., via the machine learning component 240), by the return window calculation system 200, machine learning to identify a subset of the plurality of products as return candidates.) trained using a set of communication data associated with a plurality of users ([0004] machine learning model trained on transaction data that captures purchase debits and return credits for products and merchants, and return history of the user identifying a product purchased by a user from a merchant from transaction data of the user, predicting a return window of the merchant for the product with a first machine learning model trained with data scraped from merchant websites, industry standards, and transaction data that captures time between when products from merchants are purchased and a credit is issued for return of the products);
Tessler discloses determine a return recommendation based at least in part on an output of the model ([0038] Fig 4 # 450-470, At 460, the computer-implemented method 400 can comprise invoking (e.g., via the machine learning component 240), by the return window calculation system 200, machine learning to identify a subset of the plurality of products as return candidates. At 470, the computer-implemented method 400 can comprise rendering (e.g., via the notification component 250), by the return window calculation system 200, a return timing notification for the return candidates (recommendation) including rendering the return window in the user 110’s transaction history for the plurality of products).;
Tessler discloses generate a user interface comprising the return recommendation ([0022] send notifications for purchases that have a high probability of being returned meeting a predetermined threshold. If the probability that the user 110 will return a product meets a predetermined threshold, the product can be considered (e.g., identified) as a return candidate, and notifications can be sent to the user 110 to remind the user 110 to return this return candidate (e.g., product).); and transmit the user interface to the client device. ([0031] information on the return window for the products purchased can be provided in the transaction history of a charge account via online or mobile application, reminders to make returns can also be sent to the user 110 to remind the user 110 to return products that the user 110 typically return (e.g., return candidates). The machine learning component 240 can invoke machine learning to identify a subset of the plurality of products as return candidates., [0018] send notifications to remind users to make returns within the return windows, e.g., if there is a probability that the user would likely want to return)
Tessler does not specifically teach receive a return request from a client device associated with a user; apply the plurality of prompts to a large language model (LLM) trained using a set of communication data associated with a plurality of users; determine a return recommendation in part on an output of the LLM based at least in part on a set of communication data associated with the user
Ghoche teaches receive a return request from a client device associated with a user ( [0188] tickets (return request) related to a topic/intent of a customer request for a refund [0243] an issue/request about “returning an item.” In this example, it might be the case that there are two large clusters of answers corresponding to the following: [0244] 1—essentially telling the customer “this is how you return your item and you will receive a refund within 3 business days”); apply the plurality of prompts to a large language model (LLM) trained using a set of communication data associated with a plurality of users ([0081] The history of tickets is a valuable resource for training an AI engine to mimic the way human agents respond to common questions. Historical tickets (communication data) track the lifecycle of responding to a support question. [0115] The marked tickets are fed into GPT2. The model is trained to generate word prompts based on the entire question as well as anything that the agent has typed so far in their answer. [0213] in block 4010, prompts may be selected for a generative LLM model to perform slot filling. For example, slot filling may include issuing calls for a generative LLM model and any prompts necessary for the generative model to perform slot filling for a particular workflow, [0225] the large language model is provided to support an AI chatbot implementing a workflow. For example, in one implementation, a customer may input free-form text describing their problem. Upon intent detection (e.g., detecting that the intent of the customer corresponds to checking order status), a workflow is triggered. When the workflow is triggered, the AI chatbot has available to it the workflow policy, details on available tools for that workflow [0226] the large language model has available to it as prompts the conversation associated with a ticket (communication data), the workflow policy description [0228] the large language model is provided with prompts that serve as “guard rails” to help ensure proper operation of the large language model. [0230] the large language model may be trained on a set of customer support examples. [0243] an issue about “returning an item.” (apply prompt). In this example, it might be the case that there are two large clusters of answers corresponding to the following: [0244] 1—essentially telling the customer “this is how you return your item and you will receive a refund within 3 business days” [0247] the workflow policy might be “Check whether the item was purchased within the last 30 days. If yes, give return instructions xyz. [0175] Large language models (LLMs) can be used to aid in providing customer support. Generative AI models, such as ChatGPT may be used to correctly respond to a customer inquiry about a refund or an order status for a specific business), determine return recommendation in part on an output of the LLM based at least in part on a set of communication data associated with the user ([0148] A recommendations module 1420 may be provided to generate various types of recommendations based on the granular taxonomy. As some examples, recommendations may be generated on recommended answers to be provided to agents handling specific topics in the granular taxonomy. For example, previous answers given by agents for a topic in the granular taxonomy may be used to generate a recommended answer when an incoming customer support ticket is handled by an agent. [0175] Large language models (LLMs) can be used to aid in providing customer support. Generative AI models, such as ChatGPT may be used to correctly respond to a customer inquiry about a refund or an order status for a specific business [0243] an issue about “returning an item.” (apply prompt). In this example, it might be the case that there are two large clusters of answers corresponding to the following: [0244] 1—essentially telling the customer “this is how you return your item and you will receive a refund within 3 business days” [0247] the workflow policy might be “Check whether the item was purchased within the last 30 days. If yes, give return instructions xyz.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included receive a return request from a client device associated with a user; apply the plurality of prompts to a large language model (LLM) trained using a set of communication data associated with a plurality of users; determine a return recommendation in part on an output of the LLM based at least in part on a set of communication data associated with the user, as disclosed by Ghoche in the system disclosed by Tessler, for the motivation of providing a method of correctly respond to a customer inquiry about a refund or an order status for a specific business by understanding context about an inquiry ([0175] Ghoche).
Regarding Claim 2. Tessler as modified by Ghoche teaches the system of claim 1,
Tessler teaches wherein the user data comprises at least one of user communication data, user transaction data, or a user persona profile associated with return behavior of the user. (Fig 4 #410 and [0038] identifying (e.g., via the analysis component), by the return window calculation system 200, a plurality of products purchased by the user 110 from the merchant 120. (user transaction data), [0019] obtaining information, such as the products purchased, the merchant data, the date or time of the purchase, and the purchase amount of the products., [0020] the return window calculation system 200 can track and display purchase dates and return dates in the user 110’s transaction history (e.g., a graphical user interface (GUI))., [0022] the probability of whether the user 110 will return a product can be determined based on tracking and analyzing which type of products, category of merchants, demographics of the user, or type of retailers the user 110 typically returns. For example, the user 110 can have a higher probability of returning clothing ordered from an online merchant than returning books purchased from a bookstore. As another example, the user 110 can have a higher probability of returning items purchased at retail stores than grocery stores. )
Regarding Claim 3. Tessler as modified by Ghoche teaches the system of claim 1,
Tessler teaches wherein the merchant data corresponds to a merchant associated with the transaction and comprises at least one of merchant policy data, merchant communication data, or a merchant persona profile associated with return behavior of the merchant. (Fig 1 #120 merchant, [0003] notify the user of available methods and location of return for a merchant based on the return policy of the merchant., [0021] For example, the transaction history can display last-day-to-return dates along with respective products purchased. The transaction history can also display a hyperlink opening to a new screen providing information on return policy, including return window, methods to return, and locations to return, among other things., [0023] merchant return policy)
Regarding Claim 4. Tessler as modified by Ghoche teaches the system of claim 1,
Tessler teaches wherein the issuer data is associated with an issuer of a payment account of the user associated with the transaction ([0017] Financial institutions that issue charge accounts used to make purchases often do not track details of specific products purchased by customers. Thus, transaction history generally does not show the type or price of products purchased and instead shows the total amount of a transaction. Through payment networks, financial institutions can receive information such as transaction data such as date and time of purchases, merchant information such as merchant category code (MCC), and location data indicating the type of retailer, such as whether a transaction was made with an online retailer or in-person.), the issuer data comprising transaction data and benefit data associated with the issuer.([0017] payment networks, financial institutions can receive information such as transaction data such as date and time of purchases, merchant information such as merchant category code (MCC), and location data indicating the type of retailer, such as whether a transaction was made with an online retailer or in-person., [0018] track transactions (e.g., purchase and return information) and credit backs (e.g., refund information) to calculate return windows and send notifications to remind users to make returns within the return windows [0019] the application can be a payment application, and the browser extension can also be used with a virtual card number to make payments. Both the payment application and the browser extension can be used to make payments, collect purchase transaction data, and retain an electronic copy of the purchase receipt, thereby obtaining information, such as the products purchased, the merchant data, the date or time of the purchase, and the purchase amount of the products. The payment application and the browser extension can also be used to collect returned transaction data and retain an electronic copy of the return receipt (benefit data), thereby obtaining information, such as the products returned, the merchant providing the credit back (e.g., the source and destination of the refund), the date or time of the return, and the amount to be credited back, among other things.)
Regarding Claim 5. Tessler as modified by Ghoche teaches the system of claim 1, wherein the machine-readable instructions further cause the computing device to at least:
Tessler teaches notifying user to return the return candidate ([0003] a second machine learning model trained on transaction data that captures purchase debits and return credits for products and merchants and notify the user of the return window and confidence score for the product when the likelihood the product is a return candidate satisfies a predetermined threshold. [0022]), and receive a selection of the return recommendation ([0034] initiate a return, [0038] At 460, the computer-implemented method 400 can comprise invoking (e.g., via the machine learning component 240), by the return window calculation system 200, machine learning to identify a subset of the plurality of products as return candidates. At 470, the computer-implemented method 400 can comprise rendering (e.g., via the notification component 250), by the return window calculation system 200, a return timing notification for the return candidates (return recommendation) including rendering the return window in the user 110’s transaction history for the plurality of products
Tessler teaches initiate the return of the item between the user and a merchant associated with the transaction based at least in part on the return recommendation. ([0034] Upon initiation of returns, the refund notification component 320 can render the timing of refunds to the user 110. The refund notification component 320 can display the timing of the refunds in the transaction history or render notifications, for example, via email, text message, push notification, browser extension notification, or graphical user interface (e.g., of a mobile application or online account) such as a display or pop-up notification in addition to the transaction history.)
Tessler does not specifically teach receive a user selection of the return recommendation from the user interface
Ghoche teaches receive a user selection of the return recommendation from the user interface ([0092] in response to a refund macro, a confirmation email could be sent to the customer, an email to a client could be sent giving the client options for a refund (e.g., a full refund, a credit for other products or services), a customer satisfaction survey sent, etc., [0197] a topic for “reissue card” may branch depending on options the user selects from. FIG. 38 illustrates the user selecting an option from the choices in FIG. 37, which leads to a branching to a response for the selected option.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included receive a user selection of the return recommendation from the user interface, as disclosed by Ghoche in the system disclosed by Tessler, for the motivation of providing a method of correctly respond to a customer inquiry about a refund or an order status for a specific business using trained LLM ([0175] Ghoche).
Regarding Claim 7. Tessler as modified by Ghoche teaches the system of claim 1,
Tessler teaches wherein the model is trained on historical data associated with a plurality of transactions and a plurality of returns obtained from a plurality of users, a plurality of merchants, and a plurality of issuers. ([0003] a second machine learning model trained on transaction data that captures purchase debits and return credits for products and merchants and notify the user of the return window and confidence score for the product when the likelihood the product is a return candidate satisfies a predetermined threshold., [0004] a first machine learning model trained with one or more of data scraped from merchant websites, industry standards, or transaction data that captures time between when products from merchants are purchased and a credit is issued for return of the products, wherein the first machine learning model outputs a return window that is a length of time and a confidence score that captures a likelihood that the return window is correct, predict a likelihood that the product is a candidate for return with a second machine learning model trained on transaction data that captures purchase debits and return credits for products and merchants, and return history of the user identifying a product purchased by a user from a merchant from transaction data of the user). Tessler does not specifically teach the LLM is trained
Ghoche teaches the LLM is trained ([0023] trained classifier to identify topics, [0047] model training, [0072] The AI augmented customer service module 140 may, for example, have individual AI/ML training modules, trained models and classifiers, and customer service analytical modules., [0175] Large language models (LLMs) can be used to aid in providing customer support. Generative AI models, such as ChatGPT may be used to correctly respond to a customer inquiry about a refund or an order status for a specific business )
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included the LLM is trained, as disclosed by Ghoche in the system disclosed by Tessler, for the motivation of providing a method of correctly respond to a customer inquiry about a refund or an order status for a specific business using trained LLM ([0175] Ghoche).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Tessler et al. (US 2023/0401528 A1) in view of Ghoche (US 2024/0386213 A1), as applied to claim 5, further in view of Cunningham (US 10,290,002 B1)
Regarding Claim 6. Tessler as modified by Ghoche teaches the system of claim 5, wherein,
Tessler teaches initiating the return of the item ([0034] Upon initiation of returns, the refund notification component 320 can render the timing of refunds to the user 110.), the machine-readable instructions further cause the computing device to at least:
Tessler/Ghoche do not specifically teach generate a communication on behalf of the user indicating the return of the item; and send the communication to a merchant computing device associated with the merchant.
Cunningham generate a communication on behalf of the user indicating the return of the item (Col 1 lines 51-53 receive, from a user device, return data indicating that a user account associated with the user device is to be credited, the return data including merchant data identifying a merchant, Col 6 lines 28-32 the refund management platform receives return data from the user device, the merchant device, and/or the shipping device.); and send the communication to a merchant computing device associated with the merchant (Col 3 lines 57-62 the merchant receiving an indication that the user is requesting a refund and the merchant notifying a user account entity (e.g., a bank with access to the user account and/or merchant account) to process the refund.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included generate a communication on behalf of the user indicating the return of the item; and send the communication to a merchant computing device associated with the merchant, as disclosed by Cunningham in the system disclosed by Tessler, for the motivation of providing a method of receiving return data from user and predicting refund time based on data (Col 1 lines 51-53 Cunningham).
Claims 8-14, 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Tessler et al. (US 2023/0401528 A1) in view of Cunningham (US 10,290,002 B1), further in view of Ghoche (US 2024/0386213 A1)
Regarding Claim 8. Tessler discloses the method, comprising:
Tessler discloses registering a user ([0024] information or notifications can be rendered via email, text message, push notification (e.g., via a mobile application), browser notification (e.g., via a browser extension), graphical user interface (e.g., of a mobile application or online account) (registering a user on application) such as a display or pop-up notification, or a combination thereof., [0025] The user 110 can make purchases and returns using electronic device 115, which can be installed with an application or browser extension for making payments or collecting receipt information containing the products purchased or returned. [0018] collect information on specific products purchased by a user. Customers who opt-in (account) can share their transaction data to track transactions (e.g., purchase and return information) and credit backs (e.g., refund information) to calculate return windows and send notifications to remind users to make returns within the return windows),
Tessler discloses obtaining user data associated with the user based at least in part on permissions granted during registration of the user with the return management service ([0018] collect information on specific products purchased by a user. Customers who opt-in (permission granted) can share their transaction data to track transactions (e.g., purchase and return information) and credit backs (e.g., refund information) to calculate return windows and send notifications to remind users to make returns within the return windows)
Tessler discloses obtaining merchant data associated with at least one or more merchants (Fig 1 #120 merchant, [0003] notify the user of available methods and location of return for a merchant based on the return policy of the merchant., [0021] For example, the transaction history can display last-day-to-return dates along with respective products purchased. The transaction history can also display a hyperlink opening to a new screen providing information on return policy, including return window, methods to return, and locations to return, among other things., [0023] merchant return policy;
Tessler discloses obtaining issuer data associated with one or more issuers of payment instruments of the user ([0017] Financial institutions that issue charge accounts used to make purchases often do not track details of specific products purchased by customers. Thus, transaction history generally does not show the type or price of products purchased and instead shows the total amount of a transaction. Through payment networks, financial institutions can receive information such as transaction data such as date and time of purchases, merchant information such as merchant category code (MCC), and location data indicating the type of retailer, such as whether a transaction was made with an online retailer or in-person);
Tessler discloses generate training inputs based at least in part on the user data, the merchant data, and the issuer data ([0003] a second machine learning model trained on transaction data that captures purchase debits and return credits for products and merchants and notify the user of the return window and confidence score for the product when the likelihood the product is a return candidate satisfies a predetermined threshold., [0004] a first machine learning model trained with one or more of data scraped from merchant websites, industry standards, or transaction data that captures time between when products from merchants are purchased and a credit is issued for return of the products, wherein the first machine learning model outputs a return window that is a length of time and a confidence score that captures a likelihood that the return window is correct, predict a likelihood that the product is a candidate for return with a second machine learning model trained on transaction data that captures purchase debits and return credits for products and merchants, and return history of the user identifying a product purchased by a user from a merchant from transaction data of the user); and
Tessler discloses training a model based at least in part on the training inputs, the model being trained to make one or more recommendations associated with the one or more item returns based on communication data associated with the user communicating with the merchant ([0004] a first machine learning model trained with one or more of data scraped from merchant websites, industry standards, or transaction data that captures time between when products from merchants are purchased and a credit is issued for return of the products, wherein the first machine learning model outputs a return window that is a length of time and a confidence score that captures a likelihood that the return window is correct, predict a likelihood that the product is a candidate for return (recommendation) with a second machine learning model trained on transaction data that captures purchase debits and return credits for products and merchants, and return history of the user identifying a product purchased by a user from a merchant from transaction data of the user)
Tessler does not specifically teach registering a user with a return management service in response to receiving a registration request from a client device associated with the user; the return management service functioning as an intermediary between the user and a merchant with respect to one or more item returns;
Cunningham teaches registering a user with a return management service in response to receiving a registration request from a client device associated with the user (Col 1 lines 51-53 receive, from a user device, return data indicating that a user account associated with the user device is to be credited, the return data including merchant data identifying a merchant, Col 6 lines 28-32 the refund management platform receives return data from the user device, the merchant device, and/or the shipping device. Col 10 lines 65-67 User device 210 may include one or more applications designed to facilitate the collection and/or transmittal of refund data and/or return data to refund management platform 240. For example, user device 210 may include an application associated with refund management platform 240, and the application may be designed to receive user input that includes return data and cause user device 210 to transmit the return data to refund management platform 240.); and the return management service functioning as an intermediary between the user and a merchant with respect to one or more item returns (Col 3 lines 57-62 the merchant receiving an indication that the user is requesting a refund and the merchant notifying a user account entity (e.g., a bank with access to the user account and/or merchant account) to process the refund., Col 6 lines 54-58 the user device, merchant device, and/or shipping device may provide return data to an intermediary device (e.g., an intermediary data storage device) from which the refund management platform may obtain the return data. Col 10 lines 65-67 User device 210 may include one or more applications designed to facilitate the collection and/or transmittal of refund data and/or return data to refund management platform 240. For example, user device 210 may include an application associated with refund management platform 240, and the application may be designed to receive user input that includes return data and cause user device 210 to transmit the return data to refund management platform 240. Fig 2 #240 refund management platform)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included registering a user with a return management service in response to receiving a registration request from a client device associated with the user; the return management service functioning as an intermediary between the user and a merchant with respect to one or more item returns, as disclosed by Cunningham in the system disclosed by Tessler, for the motivation of providing a method of receiving return data from user and predicting refund time based on data (Col 1 lines 51-53 Cunningham).
Tessler/Cunningham do not specifically teach training a large language model (LLM) based at least on training inputs; the LLM being trained to make one or more recommendations with the one or more item returns based at least in part on a set of communication data associated with the user communicating with the merchant
Ghoche teaches training a large language model (LLM ([0023] trained classifier to identify topics, [0047] model training, [0072] The AI augmented customer service module 140 may, for example, have individual AI/ML training modules, trained models and classifiers, and customer service analytical modules., [0175] Large language models (LLMs) can be used to aid in providing customer support. Generative AI models, such as ChatGPT may be used to correctly respond to a customer inquiry about a refund or an order status for a specific business, [0081] The history of tickets is a valuable resource for training an AI engine to mimic the way human agents respond to common questions. Historical tickets (communication data) track the lifecycle of responding to a support question. [0115] The marked tickets are fed into GPT2. The model is trained to generate word prompts based on the entire question as well as anything that the agent has typed so far in their answer. [0213] in block 4010, prompts may be selected for a generative LLM model to perform slot filling. For example, slot filling may include issuing calls for a generative LLM model and any prompts necessary for the generative model to perform slot filling for a particular workflow, [0225] the large language model is provided to support an AI chatbot implementing a workflow. For example, in one implementation, a customer may input free-form text describing their problem. Upon intent detection (e.g., detecting that the intent of the customer corresponds to checking order status), a workflow is triggered. When the workflow is triggered, the AI chatbot has available to it the workflow policy, details on available tools for that workflow [0226] the large language model has available to it as prompts the conversation associated with a ticket (communication data), the workflow policy description [0228] the large language model is provided with prompts that serve as “guard rails” to help ensure proper operation of the large language model. [0230] the large language model may be trained on a set of customer support examples. [0243] an issue about “returning an item.” (apply prompt). In this example, it might be the case that there are two large clusters of answers corresponding to the following: [0244] 1—essentially telling the customer “this is how you return your item and you will receive a refund within 3 business days” [0247] the workflow policy might be “Check whether the item was purchased within the last 30 days. If yes, give return instructions xyz. [0175] Large language models (LLMs) can be used to aid in providing customer support. Generative AI models, such as ChatGPT may be used to correctly respond to a customer inquiry about a refund or an order status for a specific business); the LLM being trained to make one or more recommendations with the one or more item returns based at least in part on a set of communication data associated with the user communicating with the merchant ([0230] the large language model may be trained on a set of customer support examples. [0243] an issue about “returning an item.” (apply prompt). In this example, it might be the case that there are two large clusters of answers corresponding to the following: [0244] 1—essentially telling the customer “this is how you return your item and you will receive a refund within 3 business days” [0247] the workflow policy might be “Check whether the item was purchased within the last 30 days. If yes, give return instructions xyz.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included training a large language model (LLM) based at least on training inputs; the LLM being trained to make one or more recommendations with the one or more item returns based at least in part on a set of communication data associated with the user communicating with the merchant, as disclosed by Ghoche in the system disclosed by Tessler/Cunningham, for the motivation of providing a method of correctly respond to a customer inquiry about a refund or an order status for a specific business using trained LLM ([0175] Ghoche).
Regarding Claim 9, Tessler as modified by Cunningham/Ghoche teaches the method of claim 8, further comprising
Tessler teaches storing the user data, the merchant data, and the issuer data in at least one database. ([0019] Information on products purchased, such as information on transactions (e.g., purchase and return information) and credit backs (e.g., refund information), can be collected by return window calculation system 200 (e.g., return window calculating system) via an application or browser extension installed on the electronic device 115. For example, the application can be a payment application, and the browser extension can also be used with a virtual card number to make payments. Both the payment application and the browser extension can be used to make payments, collect purchase transaction data, and retain an electronic copy of the purchase receipt, thereby obtaining information, such as the products purchased, the merchant data, the date or time of the purchase, and the purchase amount of the products. [0026] collected information on purchases and returns, the analysis component 210 can also analyze transactions (e.g., purchase and return information) and credit back (e.g., refund information) of returned products for the merchant 120 to determine an average, minimum, and maximum number of days between the transaction and the credit back. Purchase information can include the product purchased, the date or time of the purchase, and the amount paid for the product purchased. Return information can include the product returned, the date or time of the return, and the amount being credited back, among other things. The refund information can be information such as the source (and destination) of the refund (e.g., the merchant 120 who is providing the refund and to which account), the date or time the refund is credited back to the user 110's charge account, and the amount credited back)
Regarding Claim 10, Tessler as modified by Cunningham/Ghoche teaches the method of claim 8,
Tessler teaches wherein the user data is associated with a plurality of transactions between the user and at least one of the one or more merchants. (Fig 4 #410 and [0038] identifying (e.g., via the analysis component), by the return window calculation system 200, a plurality of products purchased by the user 110 from the merchant 120. (user transaction data), [0019] obtaining information, such as the products purchased, the merchant data, the date or time of the purchase, and the purchase amount of the products., [0020] the return window calculation system 200 can track and display purchase dates and return dates in the user 110's transaction history (e.g., a graphical user interface (GUI))., [0022] the probability of whether the user 110 will return a product can be determined based on tracking and analyzing which type of products, category of merchants, demographics of the user, or type of retailers the user 110 typically returns. For example, the user 110 can have a higher probability of returning clothing ordered from an online merchant than returning books purchased from a bookstore. As another example, the user 110 can have a higher probability of returning items purchased at retail stores than grocery stores. )
Regarding Claim 11, Tessler as modified by Cunningham/Ghoche teaches the method of claim 8,
Tessler teaches wherein the user data comprises communication data that is obtained from a communication server associated with a communication account of the user.([0020] the return window calculation system 200 can track and display purchase dates and return dates in the user 110's transaction history (e.g., a graphical user interface (GUI), [0026] Return information (user data) can include the product returned, the date or time of the return, and the amount being credited back, among other things. The refund information can be information such as the source (and destination) of the refund (e.g., the merchant 120 who is providing the refund and to which account), the date or time the refund is credited back to the user 110's charge account, and the amount credited back, among other things.).
Regarding Claim 12, Tessler as modified by Cunningham/Ghoche teaches the method of claim 8, further comprising:
Tessler discloses receive a return request associated with a user ([0022] If the probability that the user 110 will return a product meets a predetermined threshold, the product can be considered (e.g., identified) as a return candidate, and notifications (return request) can be sent to the user 110 to remind the user 110 to return this return candidate (e.g., product), [0034] Upon initiation of returns, the refund notification component 320 can render the timing of refunds to the user 110. The refund notification component 320 can display the timing of the refunds in the transaction history or render notifications), for a return of an item associated with a transaction ([0019] Information on products purchased, such as information on transactions (e.g., purchase and return information) and credit backs (e.g., refund information), can be collected by return window calculation system 200 (e.g., return window calculating system) via an application or browser extension installed on the electronic device 115. [0025] The analysis component 210 can identify a plurality of products purchased by the user 110 from the merchant 120. The user 110 can make purchases and returns using electronic device 115, which can be installed with an application or browser extension for making payments or collecting receipt information containing the products purchased or returned. [0027] Return information can include the product returned, the date or time of the return, and the amount being credited back, among other things. The refund information can be information such as the source (and destination) of the refund (e.g., the merchant 120 who is providing the refund and to which account), the date or time the refund is credited back to the user 110's charge account, and the amount credited back, among other things)
Tessler teaches determining at least one return recommendation with respect to the return of the item based at model. ([0038] Fig 4 # 450-470, At 460, the computer-implemented method 400 can comprise invoking (e.g., via the machine learning component 240), by the return window calculation system 200, machine learning to identify a subset of the plurality of products as return candidates. At 470, the computer-implemented method 400 can comprise rendering (e.g., via the notification component 250), by the return window calculation system 200, a return timing notification for the return candidates (recommendation) including rendering the return window in the user 110's transaction history for the plurality of products
Tessler does not specifically teach receiving a return request, from the client device associated with the user; and determining at least one return recommendation with respect to the return of the item based at least in part on the LLM.
Ghoche teaches receive a return request from a client device associated with a user ( [0188] tickets related to a topic/intent of a customer request for a refund [0243] an issue/request about “returning an item.” In this example, it might be the case that there are two large clusters of answers corresponding to the following: [0244] 1—essentially telling the customer “this is how you return your item and you will receive a refund within 3 business days”); apply the plurality of prompts to a large language model (LLM) ([0213] in block 4010, prompts may be selected for a generative LLM model to perform slot filling. For example, slot filling may include issuing calls for a generative LLM model and any prompts necessary for the generative model to perform slot filling for a particular workflow, [0228] the large language model is provided with prompts that serve as “guard rails” to help ensure proper operation of the large language model. [0230] the large language model may be trained on a set of customer support examples. [0243] an issue about “returning an item.” (apply prompt). In this example, it might be the case that there are two large clusters of answers corresponding to the following: [0244] 1—essentially telling the customer “this is how you return your item and you will receive a refund within 3 business days” [0247] the workflow policy might be “Check whether the item was purchased within the last 30 days. If yes, give return instructions xyz. [0175] Large language models (LLMs) can be used to aid in providing customer support. Generative AI models, such as ChatGPT may be used to correctly respond to a customer inquiry about a refund or an order status for a specific business), determine return recommendation in part on an output of the LLM ([0243] an issue about “returning an item.” (apply prompt). In this example, it might be the case that there are two large clusters of answers corresponding to the following: [0244] 1—essentially telling the customer “this is how you return your item and you will receive a refund within 3 business days” [0247] the workflow policy might be “Check whether the item was purchased within the last 30 days. If yes, give return instructions xyz.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included receiving a return request, from the client device associated with the user; and determining at least one return recommendation with respect to the return of the item based at least in part on the LLM., as disclosed by Ghoche in the system disclosed by Tessler, for the motivation of providing a method of correctly respond to a customer inquiry about a refund or an order status for a specific business using trained LLM ([0175] Ghoche).
Regarding Claim 13. Tessler as modified by Cunningham/Ghoche teaches the method of claim 8, further comprising:
Tessler teaches identifying a transaction in response to an analysis of at least one of the user data, merchant data, or issuer data ([0019]Information on products purchased, such as information on transactions (e.g., purchase and return information) and credit backs (e.g., refund information), can be collected by return window calculation system 200 (e.g., return window calculating system) via an application or browser extension installed on the electronic device 115. Both the payment application and the browser extension can be used to make payments, collect purchase transaction data, and retain an electronic copy of the purchase receipt, thereby obtaining information, such as the products purchased, the merchant data, the date or time of the purchase, and the purchase amount of the products. ); and
Tessler teaches identifying a portion of the user data, a portion of the merchant data, and a portion of the issuer data associated with the transaction based at least in part on a time window associated with a date of the transaction ([0019] Both the payment application and the browser extension can be used to make payments, collect purchase transaction data, and retain an electronic copy of the purchase receipt, thereby obtaining information, such as the products purchased, the merchant data, the date or time of the purchase, and the purchase amount of the products. [0017]financial institutions can receive information such as transaction data such as date and time of purchases, merchant information such as merchant category code (MCC), and location data indicating the type of retailer, such as whether a transaction was made with an online retailer or in-person.), the training inputs being generated based at least in part on the portion of the user data, the portion of the merchant data, and the portion of the issuer data. ([0004] identifying a product purchased by a user from a merchant from transaction data of the user, predicting a return window of the merchant for the product with a first machine learning model trained with one or more of data scraped from merchant websites, industry standards, or transaction data that captures time between when products from merchants are purchased and a credit is issued for return of the products [0036] the machine learning component 240 can employ such mechanisms to identify a subset of the plurality of products as return candidates. In aspects, these AI, ML, and knowledge-based systems can be trained using historical data related to specific and/or similar consumers' purchase and return data.)
Regarding Claim 14. Tessler as modified by Cunningham/Ghoche teaches the method of claim 8,
Tessler teaches wherein the merchant data comprises merchant policy data and merchant communication data. (Fig 1 #120 merchant, [0003] notify the user of available methods and location of return for a merchant based on the return policy of the merchant., [0021] For example, the transaction history can display last-day-to-return dates along with respective products purchased. The transaction history can also display a hyperlink opening to a new screen providing information on return policy, including return window, methods to return, and locations to return, among other things., [0023] merchant return policy)
Regarding Claim 17. Tessler as modified by Cunningham teaches the non-transitory, computer-readable medium of claim 15, wherein the machine-readable instructions, when executed by the processor, further cause the computing device to at least:
Tessler discloses receive a return request ([0034] initiate a return), determine the return recommendation ([0022] send notifications for purchases that have a high probability of being returned meeting a predetermined threshold. If the probability that the user 110 will return a product meets a predetermined threshold, the product can be considered (e.g., identified) as a return candidate, and notifications can be sent to the user 110 to remind the user 110 to return this return candidate (e.g., product).); and transmit the user interface to the client device. ([0031] information on the return window for the products purchased can be provided in the transaction history of a charge account via online or mobile application, reminders to make returns can also be sent to the user 110 to remind the user 110 to return products that the user 110 typically return (e.g., return candidates). The machine learning component 240 can invoke machine learning to identify a subset of the plurality of products as return candidates., [0018] send notifications to remind users to make returns within the return windows, e.g., if there is a probability that the user would likely want to return)
Tessler does not teach receive a return request for a return of an item associated with the transaction from a client device associated with the user; determine at least one return recommendation with respect to the return of the item
Ghoche teaches receive a return request for a return of an item associated with the transaction from a client device associated with the user ( [0188] tickets related to a topic/intent of a customer request for a refund [0243] an issue/request about “returning an item.” In this example, it might be the case that there are two large clusters of answers corresponding to the following: [0244] 1—essentially telling the customer “this is how you return your item and you will receive a refund within 3 business days”); determine at least one return recommendation with respect to the return of the item. ([0243] an issue about “returning an item.” (apply prompt). In this example, it might be the case that there are two large clusters of answers corresponding to the following: [0244] 1—essentially telling the customer “this is how you return your item and you will receive a refund within 3 business days” [0247] the workflow policy might be “Check whether the item was purchased within the last 30 days. If yes, give return instructions xyz.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included receive a return request for a return of an item associated with the transaction from a client device associated with the user; and determine at least one return recommendation with respect to the return of the item, as disclosed by Ghoche in the system disclosed by Tessler, for the motivation of providing a method of correctly respond to a customer inquiry about a refund or an order status for a specific business using trained LLM ([0175] Ghoche).
Regarding Claim 18. Tessler as modified by Cunningham/Ghoche teaches the non-transitory, computer-readable medium of claim 17, wherein the machine-readable instructions, when executed by the processor, further cause the computing device to at least:
Tessler teaches obtain the user data, the merchant data, and the issuer data stored in association with the transaction ([0018] collect information on specific products purchased by a user. Customers who opt-in (permission granted) can share their transaction data to track transactions (e.g., purchase and return information) and credit backs (e.g., refund information) to calculate return windows and send notifications to remind users to make returns within the return windows, Fig 1 #120 merchant, [0003] notify the user of available methods and location of return for a merchant based on the return policy of the merchant., [0021] For example, the transaction history can display last-day-to-return dates along with respective products purchased. The transaction history can also display a hyperlink opening to a new screen providing information on return policy, including return window, methods to return, and locations to return, among other things., [0023] merchant return policy, [0017] Financial institutions that issue charge accounts used to make purchases often do not track details of specific products purchased by customers. Thus, transaction history generally does not show the type or price of products purchased and instead shows the total amount of a transaction. Through payment networks, financial institutions can receive information such as transaction data such as date and time of purchases, merchant information such as merchant category code (MCC), and location data indicating the type of retailer, such as whether a transaction was made with an online retailer or in-person);
Tessler teaches generate a plurality of prompts based at least in part on the user data, the merchant data, and the issuer data ([0022] If the probability that the user 110 will return a product meets a predetermined threshold, the product can be considered (e.g., identified) as a return candidate, and notifications can be sent to the user 110 to remind the user 110 (prompts) to return this return candidate (e.g., product). Frequency and method of notification delivery can also be triggered upon the level of probability determined.); and
Tessler does not specifically teach apply the plurality of prompts to a trained large language model(LLM), the at least one return recommendation being based at least in part on an output of the LLM
Ghoche teaches apply the plurality of prompts to a trained large language model(LLM) ([0213] in block 4010, prompts may be selected for a generative LLM model to perform slot filling. For example, slot filling may include issuing calls for a generative LLM model and any prompts necessary for the generative model to perform slot filling for a particular workflow, [0228] the large language model is provided with prompts that serve as “guard rails” to help ensure proper operation of the large language model. [0243] an issue about “returning an item.” (apply prompt). In this example, it might be the case that there are two large clusters of answers corresponding to the following: [0244] 1—essentially telling the customer “this is how you return your item and you will receive a refund within 3 business days” [0247] the workflow policy might be “Check whether the item was purchased within the last 30 days. If yes, give return instructions xyz. [0175] Large language models (LLMs) can be used to aid in providing customer support. Generative AI models, such as ChatGPT may be used to correctly respond to a customer inquiry about a refund or an order status for a specific business), determine return recommendation in part on an output of the LLM ([0243] an issue about “returning an item.” (apply prompt). In this example, it might be the case that there are two large clusters of answers corresponding to the following: [0244] 1—essentially telling the customer “this is how you return your item and you will receive a refund within 3 business days” [0247] the workflow policy might be “Check whether the item was purchased within the last 30 days. If yes, give return instructions xyz.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included apply the plurality of prompts to a trained large language model(LLM), the at least one return recommendation being based at least in part on an output of the LLM, as disclosed by Ghoche in the system disclosed by Tessler, for the motivation of providing a method of correctly respond to a customer inquiry about a refund or an order status for a specific business using trained LLM ([0175] Ghoche).
Regarding Claim 19. Tessler as modified by Cunningham/Ghoche teaches the non-transitory, computer-readable medium of claim 17, wherein the machine-readable instructions, when executed by the processor, further cause the computing device to at least:
Tessler teaches generate a user interface comprising the at least one return recommendation ([0022] send notifications for purchases that have a high probability of being returned meeting a predetermined threshold. If the probability that the user 110 will return a product meets a predetermined threshold, the product can be considered (e.g., identified) as a return candidate, and notifications can be sent to the user 110 to remind the user 110 to return this return candidate (e.g., product).); and transmit the user interface to the client device. ([0031] information on the return window for the products purchased can be provided in the transaction history of a charge account via online or mobile application, reminders to make returns can also be sent to the user 110 to remind the user 110 to return products that the user 110 typically return (e.g., return candidates). The machine learning component 240 can invoke machine learning to identify a subset of the plurality of products as return candidates., [0018] send notifications to remind users to make returns within the return windows, e.g., if there is a probability that the user would likely want to return)
Tessler teaches notifying user to return the return candidate ([0003] a second machine learning model trained on transaction data that captures purchase debits and return credits for products and merchants and notify the user of the return window and confidence score for the product when the likelihood the product is a return candidate satisfies a predetermined threshold. [0022]), and receive a selection of the return recommendation ([0034] initiate a return, [0038] At 460, the computer-implemented method 400 can comprise invoking (e.g., via the machine learning component 240), by the return window calculation system 200, machine learning to identify a subset of the plurality of products as return candidates. At 470, the computer-implemented method 400 can comprise rendering (e.g., via the notification component 250), by the return window calculation system 200, a return timing notification for the return candidates (return recommendation) including rendering the return window in the user 110's transaction history for the plurality of products
Tessler teaches initiate the return of the item between the user and a merchant associated with the transaction based at least in part on the return recommendation. ([0034] Upon initiation of returns, the refund notification component 320 can render the timing of refunds to the user 110. The refund notification component 320 can display the timing of the refunds in the transaction history or render notifications, for example, via email, text message, push notification, browser extension notification, or graphical user interface (e.g., of a mobile application or online account) such as a display or pop-up notification in addition to the transaction history.)
Tessler does not specifically teach receive a user selection of the return recommendation from the user interface
Ghoche teaches receive a user selection of the return recommendation from the user interface ([0092] in response to a refund macro, a confirmation email could be sent to the customer, an email to a client could be sent giving the client options for a refund (e.g., a full refund, a credit for other products or services), a customer satisfaction survey sent, etc., [0197] a topic for “reissue card” may branch depending on options the user selects from. FIG. 38 illustrates the user selecting an option from the choices in FIG. 37, which leads to a branching to a response for the selected option.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included receive a user selection of the return recommendation from the user interface, as disclosed by Ghoche in the system disclosed by Tessler, for the motivation of providing a method of correctly respond to a customer inquiry about a refund or an order status for a specific business using trained LLM ([0175] Ghoche).
Regarding Claim 20. Tessler as modified by Cunningham/Ghoche teaches the non-transitory, computer-readable medium of claim 17,
Tessler teaches wherein the merchant data comprises merchant policy data and merchant communication data (Fig 1 #120 merchant, [0003] notify the user of available methods and location of return for a merchant based on the return policy of the merchant., [0021] For example, the transaction history can display last-day-to-return dates along with respective products purchased. The transaction history can also display a hyperlink opening to a new screen providing information on return policy, including return window, methods to return, and locations to return, among other things., [0023] merchant return policy), the user data comprises user communication data and user interaction history (Fig 4 #410 and [0038] identifying (e.g., via the analysis component), by the return window calculation system 200, a plurality of products purchased by the user 110 from the merchant 120. (user transaction data), [0019] obtaining information, such as the products purchased, the merchant data, the date or time of the purchase, and the purchase amount of the products., [0020] the return window calculation system 200 can track and display purchase dates and return dates in the user 110's transaction history (e.g., a graphical user interface (GUI))., [0022] the probability of whether the user 110 will return a product can be determined based on tracking and analyzing which type of products, category of merchants, demographics of the user, or type of retailers the user 110 typically returns. For example, the user 110 can have a higher probability of returning clothing ordered from an online merchant than returning books purchased from a bookstore. As another example, the user 110 can have a higher probability of returning items purchased at retail stores than grocery stores. ), and the issuer data comprising transaction data and benefit data associated with the issuer.([0017] payment networks, financial institutions can receive information such as transaction data such as date and time of purchases, merchant information such as merchant category code (MCC), and location data indicating the type of retailer, such as whether a transaction was made with an online retailer or in-person., [0018] track transactions (e.g., purchase and return information) and credit backs (e.g., refund information) to calculate return windows and send notifications to remind users to make returns within the return windows [0019] the application can be a payment application, and the browser extension can also be used with a virtual card number to make payments. Both the payment application and the browser extension can be used to make payments, collect purchase transaction data, and retain an electronic copy of the purchase receipt, thereby obtaining information, such as the products purchased, the merchant data, the date or time of the purchase, and the purchase amount of the products. The payment application and the browser extension can also be used to collect returned transaction data and retain an electronic copy of the return receipt (benefit data), thereby obtaining information, such as the products returned, the merchant providing the credit back (e.g., the source and destination of the refund), the date or time of the return, and the amount to be credited back, among other things.)
Claims 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Tessler et al. (US 2023/0401528 A1) in view of Cunningham (US 10,290,002 B1)
Regarding Claim 15. Tessler discloses the non-transitory, computer-readable medium, comprising machine-readable instructions that, when executed by a processor of a computing device, cause the computing device to at least:
Tessler discloses detect a transaction between a user and a merchant ([0003] identify a product purchased by a user from a merchant from transaction data of the user and predict a return window of the merchant for the product);
Tessler discloses obtain user data associated with the user during a time window associated with a date of the transaction ([0017] financial institutions can receive information such as transaction data such as date and time of purchases, merchant information such as merchant category code (MCC), and location data indicating the type of retailer, such as whether a transaction was made with an online retailer or in-person, [0018] collect information on specific products purchased by a user. For example, customers who opt-in can share their transaction data to use the disclosed embodiments. In addition, the embodiments herein can track transactions (e.g., purchase and return information) and credit backs (e.g., refund information) to calculate return windows and send notifications to remind users to make returns within the return windows, e.g., if there is a probability that the user would likely want to return, Fig 1 #110 user data); including a set of communication data associated with the user communicating with the merchant ([0003] historical data that captures when a return was initiated and when a refund was credited to a user account for the merchant and notify the user of the refund time. [0004] return history of the user identifying a product purchased by a user from a merchant from transaction data, [0036] knowledge-based systems can be trained using historical data related to specific and/or similar consumers' purchase and return data., [0038] rendering (e.g., via the notification component 250), by the return window calculation system 200, a return timing notification for the return candidates including rendering the return window in the user 110's transaction history for the plurality of products.)
Tessler discloses merchant data associated with the merchant during the time window ([0019] Information on products purchased, such as information on transactions (e.g., purchase and return information) and credit backs (e.g., refund information), can be collected by return window calculation system 200 (e.g., return window calculating system) via an application or browser extension installed on the electronic device 115. Receive information such as transaction data such as date and time of purchases, merchant information such as merchant category code (MCC), and location data indicating the type of retailer, such as whether a transaction was made with an online retailer or in-person., Fig 1 #120 merchant);
Tessler discloses obtain issuer data associated with an issuer of a payment instrument used during the transaction ([0017] financial institutions can receive information such as transaction data such as date and time of purchases, merchant information such as merchant category code (MCC), and location data indicating the type of retailer, such as whether a transaction was made with an online retailer or in-person [0019]Information on products purchased, such as information on transactions (e.g., purchase and return information) and credit backs (e.g., refund information), can be collected by return window calculation system 200 (e.g., return window calculating system) via an application or browser extension installed on the electronic device 115.); and
Tessler discloses store the user data, the merchant data, and the issuer data in association with the transaction ([0019] Information on products purchased, such as information on transactions (e.g., purchase and return information) and credit backs (e.g., refund information), can be collected by return window calculation system 200 (e.g., return window calculating system) via an application or browser extension installed on the electronic device 115. For example, the application can be a payment application, and the browser extension can also be used with a virtual card number to make payments. Both the payment application and the browser extension can be used to make payments, collect purchase transaction data, and retain an electronic copy of the purchase receipt, thereby obtaining information, such as the products purchased, the merchant data, the date or time of the purchase, and the purchase amount of the products. [0026] collected information on purchases and returns, the analysis component 210 can also analyze transactions (e.g., purchase and return information) and credit back (e.g., refund information) of returned products for the merchant 120 to determine an average, minimum, and maximum number of days between the transaction and the credit back. Purchase information can include the product purchased, the date or time of the purchase, and the amount paid for the product purchased. Return information can include the product returned, the date or time of the return, and the amount being credited back, among other things. The refund information can be information such as the source (and destination) of the refund (e.g., the merchant 120 who is providing the refund and to which account), the date or time the refund is credited back to the user 110's charge account, and the amount credited back)
Tessler does not specifically teach poll a merchant computing environment for merchant data associated with the merchant during the time window
Cunningham teaches poll a merchant computing environment for merchant data associated with the merchant during the time window (Fig 2 #220 merchant device. Col 11 lines 15-24 Merchant device 220 may include one or more applications designed to facilitate the collection and/or transmittal of refund data and/or return data to refund management platform 240. For example, merchant device 220 may include an application designed to detect when merchant device 220 is processing a refund and cause merchant device 220 to transmit return data associated with the refund to refund management platform 240.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included poll a merchant computing environment for merchant data associated with the merchant during the time window, as disclosed by Cunningham in the system disclosed by Tessler, for the motivation of providing a method of receiving return data from user and predicting refund time based on data (Col 1 lines 51-53 Cunningham).
Regarding Claim 16. Tessler as modified by Cunningham teaches the non-transitory, computer-readable medium of claim 15, wherein the machine-readable instructions, when executed by the processor, further cause the computing device to at least:
Tessler discloses receive a registration request from a client device associated with the user; ([0024] information or notifications can be rendered via email, text message, push notification (e.g., via a mobile application), browser notification (e.g., via a browser extension), graphical user interface (e.g., of a mobile application or online account) (registering a user) such as a display or pop-up notification, or a combination thereof., [0025] The user 110 can make purchases and returns using electronic device 115, which can be installed with an application or browser extension for making payments or collecting receipt information containing the products purchased or returned. [0018] collect information on specific products purchased by a user. Customers who opt-in (account) can share their transaction data to track transactions (e.g., purchase and return information) and credit backs (e.g., refund information) to calculate return windows and send notifications to remind users to make returns within the return windows); and
Tessler does not specifically teach register the user with a return management that acts as an intermediary between the user and a merchant with respect to one or more item returns.
Cunningham teaches register the user with a return management that acts as an intermediary between the user and a merchant with respect to one or more item returns (Col 1 lines 51-53 receive, from a user device, return data indicating that a user account associated with the user device is to be credited, the return data including merchant data identifying a merchant, Col 6 lines 28-32 the refund management platform receives return data from the user device, the merchant device, and/or the shipping device. Col 10 lines 65-67 User device 210 may include one or more applications designed to facilitate the collection and/or transmittal of refund data and/or return data to refund management platform 240. For example, user device 210 may include an application associated with refund management platform 240, and the application may be designed to receive user input that includes return data and cause user device 210 to transmit the return data to refund management platform 240., Col 3 lines 57-62 the merchant receiving an indication that the user is requesting a refund and the merchant notifying a user account entity (e.g., a bank with access to the user account and/or merchant account) to process the refund., Col 6 lines 54-58 the user device, merchant device, and/or shipping device may provide return data to an intermediary device (e.g., an intermediary data storage device) from which the refund management platform may obtain the return data. Col 10 lines 65-67 User device 210 may include one or more applications designed to facilitate the collection and/or transmittal of refund data and/or return data to refund management platform 240. For example, user device 210 may include an application associated with refund management platform 240, and the application may be designed to receive user input that includes return data and cause user device 210 to transmit the return data to refund management platform 240. Fig 2 #240 refund management platform)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have included register the user with a return management that acts as an intermediary between the user and a merchant with respect to one or more item returns, as disclosed by Cunningham in the system disclosed by Tessler, for the motivation of providing a method of receiving return data from user and predicting refund time based on data (Col 1 lines 51-53 Cunningham).
Response to Arguments
Applicant's arguments filed 10/30/25 have been fully considered but they are not persuasive.
Regarding 101 rejection, applicants remarks have been considered and they are not persuasive. Applicant on page 11 states claims provide technical solution using large language model. The claims recites additional element including– a computing device comprising a processor and a memory; a client device , a large language model (LLM), a user interface (Claim 1); a client device, training a large language model (Claim 8); memory, processor (Claim 15). The additional elements are recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component or merely uses a computer as a tool to perform an abstract idea, as discussed in MPEP 2106.05(f). Furthermore, the limitations of “using a large language model trained using a set of communication data (Claim 1); training a large language model (LLM) based at least in part on the training inputs (Claim 8)”, are simply application of a computer model, itself an abstract idea. Furthermore, such training and applying of a model is no more than putting data into a black box machine learning operation, devoid of technological implementation and application details. Each step requires a generic computer to perform generic computer functions. The additional element in claim 1 of ‘a user interface’ to receive and display data associated with the abstract idea, is merely an example of generally linking the abstract idea to a particular technological environment or field of use as outlined in MPEP 2106.05(h). User interfaces are recited so generally that they do not meaningfully limit the abstract idea. Simply implementing the abstract idea on generic components is not a practical application of the abstract idea. Accordingly, these additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Regarding 103 rejection, applicant states prior art does not teach new limitations. New limitations have been considered in claim rejection above. As noted in rejection above, Ghoche teaches a large language model (LLM) trained using a set of communication data associated with a plurality of users ([0081] The history of tickets is a valuable resource for training an AI engine to mimic the way human agents respond to common questions. Historical tickets (communication data) track the lifecycle of responding to a support question. [0115] The marked tickets are fed into GPT2. The model is trained to generate word prompts based on the entire question as well as anything that the agent has typed so far in their answer. [0213] in block 4010, prompts may be selected for a generative LLM model to perform slot filling. For example, slot filling may include issuing calls for a generative LLM model and any prompts necessary for the generative model to perform slot filling for a particular workflow, [0225] the large language model is provided to support an AI chatbot implementing a workflow. For example, in one implementation, a customer may input free-form text describing their problem. Upon intent detection (e.g., detecting that the intent of the customer corresponds to checking order status), a workflow is triggered. When the workflow is triggered, the AI chatbot has available to it the workflow policy, details on available tools for that workflow [0226] the large language model has available to it as prompts the conversation associated with a ticket (communication data), the workflow policy description [0228] the large language model is provided with prompts that serve as “guard rails” to help ensure proper operation of the large language model. [0230] the large language model may be trained on a set of customer support examples
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Junger (US7,797,164) teaches initiating a return process (Col 6 lines 20-27 enables the consumer or the purchaser of the product to access the stored information, via a Web site or the like, to obtain information about a return of the product and/or to initiate a return procedure., Fig 20 e-returns); generate a communication on behalf of the user indicating the return of the item (Col 6 lines 20-26 obtain information about a return of the product and/or to initiate a return procedure. The initiation of the return procedure may include, for example, providing the consumer with a return authorization and return instructions upon request and upon verifying that the return meets the applicable return criteria. Fig 22 good for return interface).
WO202019666 discloses processing returns based on individual user return behavior profiles. Returns from client devices for a first subset of unique user IDs are processed while obtaining observed user return attributes for each user ID in the first subset. A predictive model is learned based on the observed user return behavior attributes and transaction data for the processed returns.
Ranatunga (US 2025/0104006) discloses system designed to modernize and optimize the handling of returned products in a warehouse setting. The system links returned items to their corresponding orders using identifiers like tracking or RMA numbers and retrieves pertinent Standard Operating Procedure (SOP) instructions for the warehouse operator.
McKenna US12530384 discloses the system uses multiple models to retrieve data relevant to queries and appropriate for the requesting user and to output the data in a certain style. In particular, the system uses a first model to determine a type of user submitting a query, a second model to retrieve data relevant to the query, subject to constraints based on the type of user, and a third model to formulate a response to the query, based on the retrieved data, using a consistent style.
Rahman (US12505352) discloses a system to use generative AI (e.g., GAI, GenAI, generative artificial intelligence) models, such as a large language model (LLM) in the above-described data generation platform, to map gaps in controls to corresponding operative standards.
He (US 2024/0419941) teaches apply the plurality of prompts to a large language model (LLM) trained using a set of communication data associated with a plurality of users ([0030] the language models are large language models (LLM) that are trained on a large corpus of training data to generate outputs for the NLP tasks. An LLM may be trained on massive amounts of text data (communication data), often involving billions of words or text units. The large amount of training data from various data sources allows the LLM to generate outputs for many tasks. [0031] The LLM may be pre-trained by the online concierge system 140 or one or more entities different from the online concierge system 140. An LLM may be trained on a large amount of data from various data sources. For example, the data sources include websites, articles, posts on the web, and the like. [0035] The online concierge system 140 prepares a prompt for input to the LLM of the model serving system 150. The prompt may include a transcript of a chat conversation, [0082] The online concierge system 140 requests 405 (e.g., via the prompting module 250) a LLM (e.g., LLM of the model serving system 150) to determine, based on a prompt input into the LLM, information about a refund event for a first order placed with the online concierge system 140 by a user of the online concierge system 140. The online concierge system 140 may generate (e.g., via the prompting module 250) the prompt for input into the LLM.); determine a return recommendation in part on an output of the LLM based at least in part on a set of communication data associated with the user ([0079] The fraud inference model 360 may be trained to detect a fraudulent behavior associated with the placed order. When the fraud inference model 360 determines that no fraudulent behavior occurred (e.g., at least one item is OOS), the activity flag 365 may trigger a final approval for a whole order refund or a final approval for a partial (e.g., per-item) refund. When the fraud inference model 360 determines that the fraudulent behavior actually occurred, the activity flag 365 may trigger one or more actions in relation to an offending account, such as a recommendation for temporary suspension of the offending account, recommendation for permanent suspension of the offending account, recommendation of additional review of purchasing activities for a customer associated with the offending account, etc. [0083’ The online concierge system 140 applies 415 the computer model to determine a score associated with the refund event, based on the information about the refund event received from the LLM. The information about the refund event may include information about one or more items associated with the refund event and a textual description of a reason for the refund event Fig 4 #415-425 and [0084] The online concierge system 140 may determine (e.g., via the fraud detection module 260), based on the score, that the refund event was due to the fraudulent behavior. The online concierge system 140 may suspend (e.g., via the fraud detection module 260) an account of the user at the online concierge system 140, based on the determination of the fraudulent behavior.).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANGEETA BAHL whose telephone number is (571)270-7779. The examiner can normally be reached 7:30 - 4PM.
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 at 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.
/SANGEETA BAHL/Primary Examiner, Art Unit 3626