DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Specification
The specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Drawings
Figure 8 as drawn is objected to under 37 CFR 1.83(a). The drawing must show every feature of the invention specified in the claims. The instant specification reads as follows:
[0097] Thereafter, the purchase support server may receive second text containing additional information from the user terminal (S150). Thereafter, the purchase support server may proceed again with step S130 to determine whether the first text and the second text contain sufficient product purchase-related information.
Figure 8 does not illustrate this claimed feature. Execution of S150 returns to S130 which pertains to the First Text only, not both the first text and second text. The result is an endless loop if S130 decision is “NO.” It will always be “NO.”
The claimed subject matter must be shown or the feature(s) canceled from the claim(s). No new matter should be entered.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
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-19 are rejected under 35 USC 101 because the claimed invention is directed to an abstract idea without adding significantly more.
When considering subject matter eligibility under 35 U.S.C. 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. If the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea), and if so, it must additionally be determined whether the claim is a patent-eligible application of the exception. If an abstract idea is present in the claim, any element or combination of elements in the claim must be sufficient to ensure that the claim amounts to either a practical application of the abstract idea or significantly more than the abstract idea itself. Groupings of abstract ideas include: Mathematical Concepts, Mental Processes and Certain Methods of Organizing Human Activity.
Certain Methods of Organizing Human Activity include:
Fundamental economic principles or practices,
Commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations), and
Managing personal behavior or relationships or interaction between people (including social activities, teaching and following rules or instructions).
Mathematical Concepts
Mathematical relationships
Mathematical formulas
Mathematical calculations
Mental Processes
Concepts performed in the human mind (including an observation, evaluation, judgement, opinion)
Step 1
In the instant case, claim 13 is directed to a process. Analysis of claim 13 applies to analysis of claims 1-12 and 14-19.
Step 2A Revised (First Prong)
Determine whether claim 13 is directed to a judicial exception. Elements of an abstract idea are underlined. See Analysis.
Step 2A Revised (Second Prong)
Determine whether claim 13 has additional elements (in italics) integrated into a practical application:
a) requires an additional element or a combination of elements in the claim to apply, rely on, or use the judicial exception in a manger that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception; and
b) uses the considerations laid out by the Supreme Court and the Federal Circuit to evaluate whether the judicial exception is integrated into a practical application.
See Analysis.
Step 2B (Revised)
In Step 2B, evaluate whether claim 13recites additional elements that amount to an inventive concept that adds significantly more than the recited judicial exception. See Analysis.
Analysis
In Claim 13:
A product purchase support method performed by a computing system, comprising:
receiving, from a user terminal, text expressed in natural language;
acquiring one or more pieces of recommended product information, including estimated cost information and product-related images, by inputting the received text into an artificial intelligence (AI) model; and
transmitting the acquired recommended product information to the user terminal.
Claim 13 executes methods that are directed to abstract ideas comprising processes that can be executed by a human while following a procedure that organizes human activity related to commercial interactions using conventional computing elements.
No evidence of an improvement to the functioning of a computer, or to any other technology or technical field.
No evidence exists in the instant specification or claims of a particular machine.
No evidence exists of a transformation or reduction of a particular article to a different state or thing.
The claim does not go beyond generally linking the use of the judicial exception to a particular technological environment, e.g. processor, device.
The claim is merely applying an artificial intelligence model. Claim 13 lacks computing elements that actually apply the AI model to produce a result.
Claim 13 does not recite additional elements that amount to inventive concepts that are “significantly more” than the recited judicial exception. Claim 13 relies on conventional computer processing functions. Courts have routinely found conventional computer processing functions (e.g. sending/receiving data, formatting data, storing data, retrieving data, manipulating data, calculating, searching data, displaying data, organizing data) insignificant to transform an abstract idea into a patent-eligible invention. See Alice, 134 S. Ct. at 2360. As such, the claims amount to nothing significantly more than an instruction to implement the abstract idea across a generic computer network which is not enough to transform an abstract idea into a patent-eligible invention.
The elements of the instant process, when taken in combination, together do not offer substantially more than the sum of the functions of the steps when each is taken alone. That is, the steps involved in the recited process undertake their roles in performance of their activities according to their generic functionalities which are well-understood, routine and conventional. The elements together execute in routinely and conventionally accepted coordinated manners and interact with their partner elements to achieve an overall outcome which, similarly, is merely the combined and coordinated execution of generic computer functionalities which are well-understood, routine and conventional activities previously known to the industry.
Conclusion
Accordingly, the examiner concludes there are no meaningful limitations in claims 1-19 that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 13-18 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 13: The preamble reads “A product purchase support method performed by a computing system, comprising:” Please insert “the method” before “comprising” in order to ensure that the body of claim 13 is interpreted as a method rather than a computing system lacking required computing structure specificity.
Claim 13 and dependents are examined as method claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 6-12 and 19 are rejected under 35 USC 103 as being unpatentable over He et al., US 11,416,904 “He,” in view of Rivera et al., US 2002/0107913 “Rivera.”
In He see at least (underlined text is for emphasis):
Regarding claim 1: A product purchase support method performed by a computing system, comprising:
(He: B1: col. 1, lines 22-27) The present disclosure generally relates to systems and methods for an account manager (AM) virtual assistant staging for facilitating quotes and orders. More particularly, to methods and systems for facilitating automated quote and order staging and processing via electronic communication using machine learning (ML) techniques.
receiving, from a user terminal, first text expressed in natural language;
(He: D17: col. 6, lines 23-36) The customer 104 may use a customer device 160 to submit an RFQ via the network 108. For example, the customer 104 may use a mobile computing device (e.g., a smart phone, a laptop, etc.) to send an email or other electronic communication message, which includes an RFQ (e.g., a request for quote with respect to a particular product, an order instruction with respect to a particular product, a quote/order cancellation, a quote/order modification, etc.). In an embodiment, the customer 104 may submit the RFQ to the mail server 140 using a computer application provided by the company which may include shortcuts for RFQ submission (e.g., an order form). The RFQ may include a set of header fields followed by a body, including a message written in natural language:
(He: D35: col. 8, lines 2-26) FIG. 2 depicts a flow diagram of a preferred example message staging method 200, according to an embodiment. The AM virtual assistant staging environment 100 may implement the method 200 for implementing automated processing and staging of electronic messages from users (e.g., customers, AMs, other employees, etc.). The method 200 may include performing an Extract-Transform-Load (ETL) procedure on an electronic message (block 202). The method 200 may receive an electronic message (e.g., an email) from a customer/AM and perform various ETL operations on the electronic message. The method 200 may parse metadata and data of the electronic message. Specifically, in an email context, the method 200 may examine the content type of the email message, and check whether the message is a multipart message. If the message is multipart, then the method 200 may loop through each subpart of the multipart message. For each part, whether single part or multipart, the method 200 may remove spurious information (e.g., emojis and whitespace) from the email message, save any attachments, decode the body of the message into a particular message encoding (e.g., UTF-8), and save the headers of the message. The method 200 may store some or all portions of the metadata and data of the electronic message. If the message is a text message, then the method 200 may execute a different set of instructions.
extracting one or more product purchase-related items from the received first text;
(He: D15: col. 5, lines 39-51) The product API 138 may be an API for accessing information about the company's products. In some embodiments, the product API 138 may include multiple APIs relating to different companies. For example, the company may be a reseller of products from company B. In that case, product API 138 may permit a user of the electronic device 102 to programmatically obtain results relating to the products of company B such as: current price, quantity available, item weights/dimensions, logistical information (e.g., shipping times), etc. In some embodiments, the product API 138 may include an API for obtaining discrete information relating to a particular service (e.g., an API which allows the company to send mass/newsletter emails).
(He: D33: col. 7, lines 51-60) Once the hybrid models are trained, the models may be loaded into the AM virtual assistant staging environment 100 at runtime, and used to process emails during the runtime of the AM virtual assistant staging environment 100. Specifically, the hybrid trained models may be used to analyze email messages received by the mail server 140. For example, the first ML model may be used to determine a set of (Item, Quantity) tuples within an RFQ sent by a customer/AM, wherein the Item uniquely identifies a product for sale and the Quantity identifies the respective quantity desired.
(He: D40: col. 9, lines 7-15) The method 200 may analyze the message. For example, the method 200 may check whether the content type of the message is valid. If a particular document type (e.g., a spreadsheet) is found to be attached to the message, then the method 200 may transform each sheet of the spreadsheet into an individual machine-readable data structure, and may store the data structure. The method 200 may use a series of regular expressions for extraction of various parts of the message (e.g., a sender's name).
determining whether the first text contains sufficient product purchase-related information based on the one or more extracted items; and
(He: B3: col. 1, line 55-col. 2, line 3) An AM may identify the intent of an RFQ or other message (e.g., requesting a quote, placing an order, canceling an order, modifying an order, etc.) received from a buyer (e.g., a customer, purchaser, etc.). In some cases, a message may be eligible for immediate disposition based on analysis of the AM. For example, an AM may receive a message from an existing customer whose account is in good standing, wherein the message unambiguously identifies a quantity of product, pricing information, shipping instructions, etc. In that case the AM may immediately place an order on the customer's behalf. Some customer messages may not be capable of immediately [sic] disposition. For example, a message may be tentative in nature. For example, a message may request a quote and/or may contain information insufficient to allow the AM to place an order (e.g., an invalid or missing quantity).
(He: D69: col. 12, lines 44-59) In some embodiments, accessing the trained model at block 216 may include executing multiple trained binary classifiers. For example, the method 200 may include applying the message to a first binary classifier to determine whether the message corresponds to a quote. The method 200 may include applying the message to a second binary classifier to determine whether the message corresponds to an order. The method 200 may execute the second binary classifier based on the result of the first classifier. For example, the second classifier may only be executed if the first classifier indicates that the message is not a quote. The method 200 may executed more than one trained classifier in sequence and/or in parallel with respect to a given message. Multiple messages may be analyzed by multiple sets of classifiers simultaneously. The method 200 may abort based on certain criteria.
(He: D99: col. 19, lines 28-40) The method 200 may include staging the quote (block 232). As discussed above, the staging module of FIG. 1 may create electronic records representing staging state information. For example, the staging module may receive the quote generated at block 230. The staging module may access various attributes of the quote (e.g., buyer information, quantity information, pricing information, etc.). The staging module may check whether the quote is complete by executing a set of quote completion rules. The quote completion rules may include default checks with respect to attributes of the quote (e.g., quantity must be a positive integer, buyer name cannot be blank, etc.). The quote completion rules may include customer-specific rules.
transmitting, to the user terminal, a message requesting additional input when the first text is determined as not containing the sufficient product purchase-related information.
Rejection is based in part on teachings applied to claim 1 by He and further upon the combination of He-Rivera. Although He’s system a) processes a request for quote or purchase order when the received message is unambiguous, b) may abort processing based on certain criteria and c) executes default checks with respect to attributes of the quote (e.g., quantity must be a positive integer, buyer name cannot be blank, etc.), He does not expressly mention techniques for requesting additional input to render the message unambiguous in order to process the product purchase request or request for a quotation. Rivera on the other hand would have taught He such techniques.
In Rivera see at least:
[Rivera: 0055] The operation of the workflow coordinator 196 and the interaction of the other components of the data manager 135 are illustrated by reference to the exemplary flowchart in FIG. 9. Initially, the data manager 135 receives a request from the buyer to upload a purchase order (step 225). Once the security module 222 checks the identity and the authorization of the buyer against the authentication database 220, the buyer is permitted to push a purchase order to the data manager 135. (The data manager 135 could instead pull the purchase order.) The verification module 205 can then verify the integrity and/or completeness of the purchase order (step 230). For example, the verification module 205 can do the necessary data validity checks to guarantee that the purchase order was received error free. If the validity checks indicate that an error was introduced into the document during transmission, the data manager 135 can so notify the buyer and/or request retransmission, queue the error for manual intervention, or automatically initiate corrective action.
[Rivera: 0056] Additionally, the data manager 135 can verify that the order data contained in the order form is proper. For example, the verification module 205 can compare the product numbers in the purchase order against the relevant supplier's catalog data 206 to verify that the product numbers in the purchase order match actual products. In another embodiment, the verification module 205 can compare the quantity ordered by the purchase order against maximums and minimums required by the supplier. For either of the above cases, however, when a problem is detected, the purchase order can be returned to the buyer along with an appropriate error message, or the data manager 135 could alter the purchase order to reflect its likely intention and so notify the buyer and/or supplier.
One of ordinary skill in the art before the effective filing date would have recognized that applying the known techniques of Rivera, which return an incorrect purchase order, e.g. incorrect quantity, to the buyer and request retransmission for corrective action, would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the techniques of Rivera to the teachings of He would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such data processing features into similar systems. Obviousness under 35 USC 103 in view of the Supreme Court decision KSR International Co. vs. Teleflex Inc.
Regarding claim 2: Rejection is based upon the teachings and rationale applied to claim 1 by He-Rivera and further upon He-Rivera regarding missing quantity retransmission request, see (He: B3: col. 1, line 67-col. 2, line 3) previously recited.
Regarding claim 3: Rejection is based upon the teachings and rationale applied to claim 1 by He-Rivera and further upon He-Rivera regarding: inputting the first text into a first artificial intelligence (Al) model; and extracting the one or more product purchase-related items based on data output from the first Al model.
(He: D5: col. 3, lines 23-40) The present techniques may include training one or more ML models using electronic messages (e.g., an email, a text message, etc.) sent to the company using one or more ML models. The one or more ML models may be trained to recognize specific requests of customers and/or AMs. For example, a general RFQ email inbox and/or an inbox of an AM may be monitored. Emails delivered to the email inbox may be automatically forwarded to an RFQ processing module in response to an event (e.g., the delivery of an email) to be analyzed by one or more trained ML model. The present techniques may process the output of the trained ML models to respond to the specific requests of the customer and/or AM. The present techniques may include information extraction and classification processes which are implemented using big data tools (e.g., Apache Hadoop and/or Apache NiFi), and the company may construct parallel computing environments for various purposes (e.g., for testing, development and production).
Regarding claim 6: Rejection is based upon the teachings and rationale applied to claim 1 by He-Rivera and further upon He-Rivera regarding less than or equal to a threshold:
[Rivera: 0056] … In another embodiment, the verification module 205 can compare the quantity ordered by the purchase order against maximums and minimums required by the supplier. Please note: Both maximum and minimum quantity are established thresholds.
Regarding claims 7 and 8: Rejections are based upon the teachings and rationale applied to claim 1 by He-Rivera and further upon the combination of He-Rivera regarding inputting the first text and the second text into a third Al model:
(He: D32: col. 7, lines 34-50) In operation, the electronic device 102 may be accessed by a user (e.g., a coworker of the AM 106) to perform offline training of one or more ML models, using the user interface 132. The user may load computer-executable instructions in the memory 112 which, when executed by the processor 110, cause an ML model to access training data (e.g., manually-labeled training data) stored in the database 130. The ML model may be iteratively trained until a loss function is minimized. Once the ML model is sufficiently trained, the ML model may be stored for later use in the database 130, Hadoop server, etc. Multiple ML models may be trained. For example, a first ML model may be trained to perform an information extraction function, and a second ML model may be trained to perform a classification function. The use of a hybrid random forest classifier and deep learning classifier to implement an AM virtual assistant is not currently known in the art.
(He: D81: col. 15, lines 23-29) The ML modules accessed during information extraction may be pre-trained offline and loaded by the method 200 at runtime. Information extraction at block 218 may identify information needed to generate a quote such as part numbers and respective quantities by analyzing free-form messages, including those RFQs that the trained information extraction ML model has not previously examined. Please note: Per the instant specification sending a response to the RFQ qualifies as “recommended product information.”
(He: D99: col. 19, lines 28-34) The method 200 may include staging the quote (block 232). As discussed above, the staging module of FIG. 1 may create electronic records representing staging state information. For example, the staging module may receive the quote generated at block 230. The staging module may access various attributes of the quote (e.g., buyer information, quantity information, pricing information, etc.). Please note: Lacking any language in the claim specific to developing an estimate, it is interpreted that “estimated cost” in claim 8 reads on He’s pricing.
The combination of He-Rivera: a) process a request for quote or purchase order when the received message is unambiguous, b) may abort processing based on certain criteria, c) execute default checks with respect to attributes of the quote (e.g., quantity must be a positive integer, buyer name cannot be blank, etc.), and d) run validity checks that may indicate that an error was introduced into the document during transmission, and notify the buyer and/or request retransmission, queue the error for manual intervention, or automatically initiate corrective action. Given that the intent is to render the buyer’s message unambiguous by taking corrective action, one of ordinary skill in the art before the effective filing date would have ascertain the corrected information, e.g. corrected quantity, in combination with the original text, i.e. first text, would render the buyer’s request unambiguous and therefore be processed by He-Rivera’s AI models as previously recited.
Regarding claim 9: Rejection is based upon the teachings and rationale applied to claim 7 by He-Rivera and further upon the combination of He-Rivera determining a sequence of calling a plurality of APIs for configuring the recommended product; and creating a cloud product related to the recommended product based on the determined is API call sequence:
(He: D4: col. 3, lines 8-15) The present techniques include a virtual AM digital assistant for interpreting, classifying, staging, and processing RFQs and other message instructions. A multi-brand technology solutions company may provide a broad array of offerings, ranging from hardware and software to information technology (IT) product (e.g., security, cloud, data center and networking) services and solutions to customers in the public and private sectors.
(He: D15: col. 5, lines 39-51) The product API 138 may be an API for accessing information about the company's products. In some embodiments, the product API 138 may include multiple APIs relating to different companies. For example, the company may be a reseller of products from company B. In that case, product API 138 may permit a user of the electronic device 102 to programmatically obtain results relating to the products of company B such as: current price, quantity available, item weights/dimensions, logistical information (e.g., shipping times), etc. In some embodiments, the product API 138 may include an API for obtaining discrete information relating to a particular service (e.g., an API which allows the company to send mass/newsletter emails).
(He: D23: col. 6, lines 47-53) The customer 104 may include one or more EDC numbers including respective corresponding quantities that the customer 104 desires to purchase within the body of the RFQ message. In some embodiments, EDC codes may correspond to services (e.g., cloud-based services) rather than products.
(He: D72: col. 13, lines 52-58) … Further, the pricing API may return information in addition to pricing information. This additional information may be displayed to the AM in conjunction with a quote, so that the AM can see not only pricing but also the additional information, allowing the AM to make a more informed decision as compared with any current approaches that may include only pricing.
(He: D80: col. 15, lines 10-13) … Accessing the one or more trained models may include submitting data to the ML operating module 122 (e.g., via an API call) and receiving a result.
(He: D91: col. 18, lines 11-32) When the method 200 determines that the classification of the message corresponds to an order at block 222, the method 200 may include generating an order based on the information extracted at block 218 (block 226). Generating an order may include checking a pricing API (block 228). For example, the method 200 may retrieve a real-time price corresponding to a product identified in the message from the pricing API. It should be appreciated that in circumstances wherein the intent of the message (e.g., that the message corresponds to an order), the method 200 may completely bypass any staging. The method 200 may bypass staging based on a confidence assigned to the message classification and/or other conditions identified at previous steps of the method 200. For example, if message classification at step 214 classifies the message as an order with confidence greater than 0.75, and the classify sender block 210 identifies the sender as a known commercial customer, then the order may be automatically generated without staging at block 226. It should be envisioned that many business rules may be encoded using such rules. In cases wherein a confidence is beneath a threshold, the method 200 may stage the message for further retrieval and/or analysis.
(He: D93: col. 18, lines 44-63) Generating the quote may include checking a pricing API (block 228). The pricing API may be queried according to one or more inputs (e.g., EDC, customer code, company code, etc.). In response to queries, the pricing API may output price, price code, price level, price source, etc. If multiple prices are available for a certain input, then the API may return the lowest price. The method 200 may include passing the lowest price and/or other information returned by the pricing API to another system/API for generating a quote. For example, when the information extraction step at block 218 determines that a customer wants to order a quantity of 10 widgets associated with a particular code, the method 200 may call a pricing API passing the quantity and code of the widgets as parameters. The pricing API may return an overall price, or an itemized price that the method 200 may insert into the generated quote (e.g., in the body of an email). For example, the method 200 may include instructions for outputting a list of prices formatted in an HTML table. In some embodiments, the pricing API may be an aspect of the product API 138.
Please note: The above teachings offer examples of API sequencing.
(He: D100: col. 20, lines 12-14) … When the customer accepts the quote, the quote may be transformed into an order (block 226).
Regarding claims 10 and 11: Rejections are based upon the teachings and rationale applied to claim 9 by He-Rivera and further upon the combination of He-Rivera regarding the sequence of calling the plurality of APIs comprises acquiring the sequence of calling the plurality of APIs by inputting information regarding the recommended product into the Al model:
(He: D14: col. 5, lines 32-38) The user may use the electronic device 102 to access the application modules 114 (e.g., to load data for training an ML model, or to load a saved model to test the predictions of the trained ML model, to view email in the mail server 140, etc.). The user may query a product application programming interface (API) 138 for information relating to various products.
(He: D80: col. 14, line 65-col. 15, line 21) The method 200 may include extracting information from the message using a trained ML model (block 218). In some embodiments, extracting information may include accessing one or more trained models (block 216). The models accessed at block 218 may be the same or different as those accessed at block 214. Accessing one or more trained models may include making a network call (e.g., via the network 108) and/or by accessing a database (e.g., the database 130). The one or more trained models may be trained and used by the method 200 as discussed with respect to FIG. 1. Accessing the trained models may include loading the one or more trained models via the ML operating module 122, and/or the ML training module 120. Accessing the one or more trained models may include submitting data to the ML operating module 122 (e.g., via an API call) and receiving a result. For example, an application module in the application modules 114 may pass the message to the ML operating module 122, wherein the ML operating module 122 may process the message using an already-trained ML model, and return the result of processing the message to the application module (e.g., a classification, a set of extracted information, etc.). One or more input layers of the trained ML model may be configured to receive aspects of the message (e.g., headers, body, etc.).
Regarding claim 12: Rejection is based upon the teachings and rationale applied to claim 1 by He-Rivera and further upon He-Rivera regarding inputting the 20 first text into a third Al model; and transmitting the generated recommended product information to the user terminal:
(He: D32: col. 7, lines 34-50) In operation, the electronic device 102 may be accessed by a user (e.g., a coworker of the AM 106) to perform offline training of one or more ML models, using the user interface 132. The user may load computer-executable instructions in the memory 112 which, when executed by the processor 110, cause an ML model to access training data (e.g., manually-labeled training data) stored in the database 130. The ML model may be iteratively trained until a loss function is minimized. Once the ML model is sufficiently trained, the ML model may be stored for later use in the database 130, Hadoop server, etc. Multiple ML models may be trained. For example, a first ML model may be trained to perform an information extraction function, and a second ML model may be trained to perform a classification function. The use of a hybrid random forest classifier and deep learning classifier to implement an AM virtual assistant is not currently known in the art.
(He: D81: col. 15, lines 23-29) The ML modules accessed during information extraction may be pre-trained offline and loaded by the method 200 at runtime. Information extraction at block 218 may identify information needed to generate a quote such as part numbers and respective quantities by analyzing free-form messages, including those RFQs that the trained information extraction ML model has not previously examined. Please note: Per the instant specification sending a response to the RFQ qualifies as “recommended product information.”
Regarding claim 19: Rejection is based upon the teachings and rationale applied to claim 1 by He-Rivera and further upon He-Rivera regarding system level elements, e.g. processor(s), memory and program execution:
(He: D8: col. 3, line50-col. 3, line 7) The electronic device 102 may be a computing device such as a desktop computer, laptop, or server. The electronic device 102 may include a processor 110, a memory 112, and a set of application modules 114. The processor 110 may include any number of processors, including one or more graphics processing unit (GPU) and/or one or more central processing unit (CPU). In some embodiments, the processor 110 may include specialized parallel processing hardware configurations to permit the electronic device 102 to simultaneously train and/or operate multiple ML models (e.g., multiple GPUs, application-specific integrated circuits (ASICs), etc.). The memory 112 may include a random-access memory (RAM), a read-only memory (ROM), a hard disk drive (HDD), a magnetic storage, a flash memory, a solid-state drive (SSD), and/or one or more other suitable types of volatile or non-volatile memory. The processor 110 may execute computer-executable instructions stored in the memory 112. For example, the processor 110 may execute code stored in an SSD, causing data (e.g., a data set, a trained ML model, an email file, etc.) to be loaded into a RAM. The processor 110 may also cause an email file to be read from a file (e.g., from a memory or from a network location). The processor 110 may execute instructions stored in the memory 112 which instantiate, or load, the application modules 114.
Claims 13-16 are rejected under 35 USC 103 as being unpatentable over He, US 11,416,904, in view of Johnson, US 8,121,904.
In He see at least (underlined text is for emphasis):
Regarding claim 13: A product purchase support method performed by a computing system, the method comprising:
(He: B1: col. 1, lines 22-27) The present disclosure generally relates to systems and methods for an account manager (AM) virtual assistant staging for facilitating quotes and orders. More particularly, to methods and systems for facilitating automated quote and order staging and processing via electronic communication using machine learning (ML) techniques.
receiving, from a user terminal, text expressed in natural language;
(He: D17: col. 6, lines 23-36) The customer 104 may use a customer device 160 to submit an RFQ via the network 108. For example, the customer 104 may use a mobile computing device (e.g., a smart phone, a laptop, etc.) to send an email or other electronic communication message, which includes an RFQ (e.g., a request for quote with respect to a particular product, an order instruction with respect to a particular product, a quote/order cancellation, a quote/order modification, etc.). In an embodiment, the customer 104 may submit the RFQ to the mail server 140 using a computer application provided by the company which may include shortcuts for RFQ submission (e.g., an order form). The RFQ may include a set of header fields followed by a body, including a message written in natural language:
(He: D35: col. 8, lines 2-26) FIG. 2 depicts a flow diagram of a preferred example message staging method 200, according to an embodiment. The AM virtual assistant staging environment 100 may implement the method 200 for implementing automated processing and staging of electronic messages from users (e.g., customers, AMs, other employees, etc.). The method 200 may include performing an Extract-Transform-Load (ETL) procedure on an electronic message (block 202). The method 200 may receive an electronic message (e.g., an email) from a customer/AM and perform various ETL operations on the electronic message. The method 200 may parse metadata and data of the electronic message. Specifically, in an email context, the method 200 may examine the content type of the email message, and check whether the message is a multipart message. If the message is multipart, then the method 200 may loop through each subpart of the multipart message. For each part, whether single part or multipart, the method 200 may remove spurious information (e.g., emojis and whitespace) from the email message, save any attachments, decode the body of the message into a particular message encoding (e.g., UTF-8), and save the headers of the message. The method 200 may store some or all portions of the metadata and data of the electronic message. If the message is a text message, then the method 200 may execute a different set of instructions.
acquiring one or more pieces of recommended product information, including estimated cost information and product-related images, …
Rejection is based in part upon the teachings applied to claim 13 by He and further upon the combination He-Johnson.
In He see at least:
(He: D81: col. 15, lines 23-29) The ML modules accessed during information extraction may be pre-trained offline and loaded by the method 200 at runtime. Information extraction at block 218 may identify information needed to generate a quote such as part numbers and respective quantities by analyzing free-form messages, including those RFQs that the trained information extraction ML model has not previously examined. Please note: Per the instant specification sending a response to the RFQ qualifies as “recommended product information.”
(He: D99: col. 19, lines 28-34) The method 200 may include staging the quote (block 232). As discussed above, the staging module of FIG. 1 may create electronic records representing staging state information. For example, the staging module may receive the quote generated at block 230. The staging module may access various attributes of the quote (e.g., buyer information, quantity information, pricing information, etc.). Please note: Lacking any language in the claim specific to developing an estimate, it is interpreted that “estimated cost” in claim 13 reads on He’s pricing.
Although He does not expressly mention techniques that include images with recommended product information, i.e. a product proposal, Johnson on the other hand would have taught He such techniques.
In Johnson see at least:
(Johnson: B10: col. 2, lines 30-3 ) Based upon the customer's answers to the queries, the system links product pictures, environment pictures, and textual descriptions together in a customized proposal. The system also has the capability to link together other aspects in the proposal, which may include environment text describing the product in a particular setting or environment. The customized proposal, therefore, contains pictures, textual descriptions, and pricing information that is all of interest to and relevant to a specific customer, since all of the pictures and text were linked together based upon the customer's answers.
(Johnson: B11: col. 2, lines 40-47) Since each proposal is customized for a particular customer, each proposal will have a much more persuasive effect in selling the product. Also, if any information about the product changes, such as prices of options, the system information stored in a data base may be simply changed in order to accommodate the new information. Additional textual descriptions or pictures may also be added to the system data base to be used in linking together information for a proposal.
One of ordinary skill in the art before the effective filing date would have recognized that applying the known techniques of Johnson, which customize a proposal that contains pictures, textual descriptions and pricing information that is of interest to and relevant to a specific customer, would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the techniques of Johnson to the teachings of He would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such data processing features into similar systems. Obviousness under 35 USC 103 in view of the Supreme Court decision KSR International Co. vs. Teleflex Inc.
… by inputting the received text into an artificial intelligence (Al) model; and
Rejection is based upon the teachings and rationale applied to claim 13 by He-Johnson and further upon the combination of He-Johnson:
(He: D32: col. 7, lines 34-50) In operation, the electronic device 102 may be accessed by a user (e.g., a coworker of the AM 106) to perform offline training of one or more ML models, using the user interface 132. The user may load computer-executable instructions in the memory 112 which, when executed by the processor 110, cause an ML model to access training data (e.g., manually-labeled training data) stored in the database 130. The ML model may be iteratively trained until a loss function is minimized. Once the ML model is sufficiently trained, the ML model may be stored for later use in the database 130, Hadoop server, etc. Multiple ML models may be trained. For example, a first ML model may be trained to perform an information extraction function, and a second ML model may be trained to perform a classification function. The use of a hybrid random forest classifier and deep learning classifier to implement an AM virtual assistant is not currently known in the art.
(He: D81: col. 15, lines 23-29) The ML modules accessed during information extraction may be pre-trained offline and loaded by the method 200 at runtime. Information extraction at block 218 may identify information needed to generate a quote such as part numbers and respective quantities by analyzing free-form messages, including those RFQs that the trained information extraction ML model has not previously examined. Please note: Per the instant specification sending a response to the RFQ qualifies as “recommended product information.”
transmitting the acquired recommended product information to the user terminal.
Rejection is based upon the teachings and rationale applied to claim 13 by He-Johnson and further upon the combination of He-Johnson:
(He: D100: col. 19, line 55-col. 20, line 3) The AM may review the staged quote in a number of formats, depending on the embodiment. In one embodiment, the staging module may create a forwarded email or an email reply message (e.g., a MIME or plain text email). The email may be automatically inserted into a folder of the AM's email account (e.g., a drafts folder, an inbox, etc.). In some embodiments, an AM may review staged quotes in a web application (e.g., a virtual shopping cart). The virtual shopping cart may depict a list of staged quotes, grouped by customer. The virtual shopping cart may display the staging state information relating to each staged quote. The AM may approve the quote by, for example, replying to an email or selecting an approval user interface element (e.g., a link, button, etc.). Once the AM approves a staged quote, the method 200 may include transmitting the AM-approved quote to the customer (block 236).
Regarding claim 14: Rejection is based upon the teachings and rationale applied to claim 13 by He-Johnson and further upon the combination of He-Johnson determining a sequence of calling a plurality of APIs for configuring the recommended product; and creating a cloud product related to the recommended product based on the determined is API call sequence:
(He: D4: col. 3, lines 8-15) The present techniques include a virtual AM digital assistant for interpreting, classifying, staging, and processing RFQs and other message instructions. A multi-brand technology solutions company may provide a broad array of offerings, ranging from hardware and software to information technology (IT) product (e.g., security, cloud, data center and networking) services and solutions to customers in the public and private sectors.
(He: D15: col. 5, lines 39-51) The product API 138 may be an API for accessing information about the company's products. In some embodiments, the product API 138 may include multiple APIs relating to different companies. For example, the company may be a reseller of products from company B. In that case, product API 138 may permit a user of the electronic device 102 to programmatically obtain results relating to the products of company B such as: current price, quantity available, item weights/dimensions, logistical information (e.g., shipping times), etc. In some embodiments, the product API 138 may include an API for obtaining discrete information relating to a particular service (e.g., an API which allows the company to send mass/newsletter emails).
(He: D23: col. 6, lines 47-53) The customer 104 may include one or more EDC numbers including respective corresponding quantities that the customer 104 desires to purchase within the body of the RFQ message. In some embodiments, EDC codes may correspond to services (e.g., cloud-based services) rather than products.
(He: D72: col. 13, lines 52-58) … Further, the pricing API may return information in addition to pricing information. This additional information may be displayed to the AM in conjunction with a quote, so that the AM can see not only pricing but also the additional information, allowing the AM to make a more informed decision as compared with any current approaches that may include only pricing.
(He: D80: col. 15, lines 10-13) … Accessing the one or more trained models may include submitting data to the ML operating module 122 (e.g., via an API call) and receiving a result.
(He: D91: col. 18, lines 11-32) When the method 200 determines that the classification of the message corresponds to an order at block 222, the method 200 may include generating an order based on the information extracted at block 218 (block 226). Generating an order may include checking a pricing API (block 228). For example, the method 200 may retrieve a real-time price corresponding to a product identified in the message from the pricing API. It should be appreciated that in circumstances wherein the intent of the message (e.g., that the message corresponds to an order), the method 200 may completely bypass any staging. The method 200 may bypass staging based on a confidence assigned to the message classification and/or other conditions identified at previous steps of the method 200. For example, if message classification at step 214 classifies the message as an order with confidence greater than 0.75, and the classify sender block 210 identifies the sender as a known commercial customer, then the order may be automatically generated without staging at block 226. It should be envisioned that many business rules may be encoded using such rules. In cases wherein a confidence is beneath a threshold, the method 200 may stage the message for further retrieval and/or analysis.
(He: D93: col. 18, lines 44-63) Generating the quote may include checking a pricing API (block 228). The pricing API may be queried according to one or more inputs (e.g., EDC, customer code, company code, etc.). In response to queries, the pricing API may output price, price code, price level, price source, etc. If multiple prices are available for a certain input, then the API may return the lowest price. The method 200 may include passing the lowest price and/or other information returned by the pricing API to another system/API for generating a quote. For example, when the information extraction step at block 218 determines that a customer wants to order a quantity of 10 widgets associated with a particular code, the method 200 may call a pricing API passing the quantity and code of the widgets as parameters. The pricing API may return an overall price, or an itemized price that the method 200 may insert into the generated quote (e.g., in the body of an email). For example, the method 200 may include instructions for outputting a list of prices formatted in an HTML table. In some embodiments, the pricing API may be an aspect of the product API 138.
Please note: The above teachings offer examples of API sequencing.
(He: D100: col. 20, lines 12-14) … When the customer accepts the quote, the quote may be transformed into an order (block 226).
Regarding claims 15 and 16: Rejections are based upon the teachings and rationale applied to claim 14 by He-Johnson and further upon the combination of He-Johnson regarding the sequence of calling the plurality of APIs comprises acquiring the sequence of calling the plurality of APIs by inputting information regarding the recommended product into the Al model:
(He: D14: col. 5, lines 32-38) The user may use the electronic device 102 to access the application modules 114 (e.g., to load data for training an ML model, or to load a saved model to test the predictions of the trained ML model, to view email in the mail server 140, etc.). The user may query a product application programming interface (API) 138 for information relating to various products.
(He: D80: col. 14, line 65-col. 15, line 21) The method 200 may include extracting information from the message using a trained ML model (block 218). In some embodiments, extracting information may include accessing one or more trained models (block 216). The models accessed at block 218 may be the same or different as those accessed at block 214. Accessing one or more trained models may include making a network call (e.g., via the network 108) and/or by accessing a database (e.g., the database 130). The one or more trained models may be trained and used by the method 200 as discussed with respect to FIG. 1. Accessing the trained models may include loading the one or more trained models via the ML operating module 122, and/or the ML training module 120. Accessing the one or more trained models may include submitting data to the ML operating module 122 (e.g., via an API call) and receiving a result. For example, an application module in the application modules 114 may pass the message to the ML operating module 122, wherein the ML operating module 122 may process the message using an already-trained ML model, and return the result of processing the message to the application module (e.g., a classification, a set of extracted information, etc.). One or more input layers of the trained ML model may be configured to receive aspects of the message (e.g., headers, body, etc.).
Allowable Subject Matter
Subject to overcoming rejection of parent claim 1 under 35 USC 101-Subject Matter Eligibility, claims 4 and 5 are objected to as being dependent upon rejected base claim 1, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Subject to overcoming rejection of parent claim 13 under 35 USC 101-Subject Matter Eligibility, claims 17 and 18 are objected to as being dependent upon rejected base claim 13, but would be allowable if rewritten in independent form including all of the limitations of the base claim 13 and intervening claim 14.
Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US 2008/0281722 (Balasubramanian et al.) “Text-to-Buy WAP Application Server,” discloses: [Abstract] An electronic platform (10) for facilitating mobile commerce transactions includes: a user interface (20) that is provided to a user (60), the user interface (20) being operable to retrieve from the user (60) a plurality of settings for different parameters that regulate a manner in which the platform (10) operates for a given entity that is being served by the platform (10); a conversation tracking engine (40) that monitors messages exchanged between the platform (10) and mobile device users (72) accessing the platform (10), the conversation tracking engine (40) being operative to recognize which ones of selected monitored messages together form a common conversation and keep track of a current state of that conversation; and, a mobile content rendering engine (30) that is operable to dynamically render mobile content in response to the platform (10) receiving a request from a mobile device (74) for mobile content, the mobile content being rendered in accordance with the parameter settings entered via the user interface (20).
Conclusion
.Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROBERT M POND whose telephone number is (571)272-6760. The examiner can normally be reached M-F, 8:30 AM-6:30 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Smith can be reached at 571-272-6763. 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.
/ROBERT M POND/Primary Examiner, Art Unit 3688 June 12, 2026
Prosecution Insights