DETAILED ACTION
Notice of Pre-A/A or A/A Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 101
2. 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.
3. Claims 1–20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
In sum, claims 1–20 are rejected under 35 U.S.C. §101 because the claimed invention is directed to a judicial exception to patentability (i.e., a law of nature, a natural phenomenon, or an abstract idea) and do not include an inventive concept that is something “significantly more” than the judicial exception under the January 2019 patentable subject matter eligibility guidance (2019 PEG) analysis which follows.
Under the 2019 PEG step 1 analysis, it must first be determined whether the claims are directed to one of the four statutory categories of invention (i.e., process, machine, manufacture, or composition of matter). Applying step 1 of the analysis for patentable subject matter to the claims, it is determined that the claims are directed to the statutory category of a process (claims 8–14), a machine (claims 15-20), and a manufacture (claims 1-7), where the machine and manufacture are substantially directed to the subject matter of the process. (See, e.g., MPEP §2106.03).
Therefore, we proceed to step 2A, Prong 1. Under the 2019 PEG step 2A, Prong 1 analysis, it must be determined whether the claims recite an abstract idea that falls within one or more designated categories of patent ineligible subject matter (i.e., organizing human activity, mathematical concepts, and mental processes) that amount to a judicial exception to patentability. Here, the claims recite the abstract idea of receiving insurance rate filing information in order to generate insurance pricing by:
a pricing,…,operable to determine a price of insurance corresponding to at least one insurance product given a set of user data;
an orchestrator for parsing and structuring a,…, into the pricing,…,, wherein the orchestrator is a trained machine learning;
and
….comprising computer-executable instructions that, when executed by at least one,…,
perform a method of generating the pricing,…,based on one or more rate filings, the method comprising:
receiving, in real time, the one or more rate filings corresponding to the at least one insurance product;
translating, via natural language processing, the one or more rate filings, wherein the one or more rate filings are translated into the set of computer-readable,…;
parsing the set of computer-readable,…,to determine a set of pricing information for the at least one insurance product; and
structuring, via the orchestrator, the set of pricing information into the pricing,…,.
Here, the recited abstract idea falls within one or more of the three enumerated 2019 PEG categories of patent ineligible subject matter, to wit: the category of certain methods of organizing human activity, which includes fundamental economic practices or principles and commercial or legal interactions (e.g., receiving insurance rate filing information in order to generate insurance pricing).
Under the 2019 PEG step 2A, Prong 2 analysis, the identified abstract idea to which the claim is directed does not include limitations that integrate the abstract idea into a practical application, since the recited features of the abstract idea are being applied on a computer or computing device or via software programming that is simply being used as a tool (“apply it”) to implement the abstract idea. (See, e.g., MPEP §2106.05(f)). Therefore, the claim is directed to an abstract idea.
Under the 2019 PEG step 2B analysis, the additional elements are evaluated to determine whether they amount to something “significantly more” than the recited abstract idea. (i.e., an innovative concept). Here, the additional elements, such as: a “data, “engine,” and “medium” do not amount to an innovative concept since, as stated above in the step 2A, Prong 2 analysis, the claims are simply using the additional elements as a tool to carry out the abstract idea (i.e., “apply it”) on a computer or computing device and/or via software programming. (See, e.g., MPEP §2106.05(f)). The additional elements are specified at a high level of generality to simply implement the abstract idea and are not themselves being technologically improved. (See, e.g., MPEP §2106.05 I.A.); (see also, paragraph [0007] of the specification). Independent claims 1 and 8 are nearly identical to claim 15 so the same analysis applies to these claims as well.
Dependent claims 2–7, 9–14, and 16-20 have all been considered and do not integrate the abstract idea into a practical application. Dependent claims 2, 7, 9, and 10 are substantially similar and recite limitations that further define the abstract idea noted in claim 15 as they describe that the one or more rate filing are an updated version of an existing rate filing. Dependent claim 3 recites limitations that further define the abstract idea noted in claim 15 as it describes that the natural language processing engine is a large language model. Dependent claim 4 recites limitations that further define the abstract idea noted in claim 15 as it describes transmitting a query for gathering information associated with structuring of the set of pricing information. Dependent claim 5 recites limitations that further define the abstract idea noted in claim 15 as it describes that the query includes a request for rate structure number. Dependent claim 6 recites limitations that further define the abstract idea noted in claim 15 as it describes determining a field number of each rate structure. Dependent claim 11 recites limitations that further define the abstract idea noted in claim 15 as it describes that rate filing corresponding to a single jurisdiction. Dependent claim 12 recites limitations that further define the abstract idea noted in claim 15 as it describes scraping the rate filings from various external systems. Dependent claim 13 recites limitations that further define the abstract idea noted in claim 15 as it describes that the pricing engine corresponds to a plurality of insurance products. Dependent claim 14 recites limitations that further define the abstract idea noted in claim 15 as it describes what the administrative bodies actually are. Dependent claim 16 recites limitations that further define the abstract idea noted in claim 15 as it describes that the rate filings are received in real time. Dependent claim 17 recites limitations that further define the abstract idea noted in claim 15 as it describes that the orchestrator is trained on a plurality of historical rate filings. Dependent claim 18 recites limitations that further define the abstract idea noted in claim 15 as it describes that the pricing engine is structured with various elements. Dependent claim 19 recites limitations that further define the abstract idea noted in claim 15 as it describes that the pricing engine corresponds to a singular insurance product. Dependent claim 20 recites limitations that further define the abstract idea noted in claim 15 as it describes that the one or more rate filings correspond to a plurality of jurisdictions.
The additional elements of the dependent claims merely refine and further limit the abstract idea of the independent claims and do not add any feature that is an “inventive concept” which cures the deficiencies of their respective parent claim under the 2019 PEG analysis. None of the dependent claims considered individually, including their respective limitations, include an “inventive concept” of some additional element or combination of elements sufficient to ensure that the claims in practice amount to something “significantly more” than patent-ineligible subject matter to which the claims are directed.
The elements of the instant process steps when taken in combination do not offer substantially more than the sum of the functions of the elements when each is taken alone. The claims as a whole, do not amount to significantly more than the abstract idea itself because the claims do not effect an improvement to another technology or technical field (e.g., the field of computer coding technology is not being improved); the claims do not amount to an improvement to the functioning of an electronic device itself which implements the abstract idea (e.g., the general purpose computer and/or the computer system which implements the process are not made more efficient or technologically improved); the claims do not perform a transformation or reduction of a particular article to a different state or thing (i.e., the claims do not use the abstract idea in the claimed process to bring about a physical change. See, e.g., Diamond v. Diehr, 450 U.S. 175 (1981), where a physical change, and thus patentability, was imparted by the claimed process; contrast, Parker v. Flook, 437 U.S. 584 (1978), where a physical change, and thus patentability, was not imparted by the claimed process); and the claims do not move beyond a general link of the use of the abstract idea to a particular technological environment (e.g., simply claiming the use of a computer and/or computer system to implement the abstract idea).
Claim Rejections - 35 USC § 102
4. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
5. Claims 1-4, 7-11, and 13-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Fields et al. (U.S. Pub. No. 2025/0265624) (hereinafter “Fields”).
Regarding claims 1, 8, and 15, Fields discloses a pricing engine operable to determine a price of insurance corresponding to at least one insurance product given a set of user data and an orchestrator for parsing and structuring a set of computer-readable data into the pricing engine, wherein the orchestrator is a trained machine learning and one or more non-transitory computer-readable media comprising computer-executable instructions that, when executed by at least one processor, perform a method of generating the pricing engine based on one or more rate filings. Fields states that “One exemplary computer system is an insurance rate filing system, such as those used in the insurance industry to calculate insurance rates or prices for an insurance product. In this example, the MTA computer device may be configured to monitor predicted pricing from a model for an insurance product in a jurisdiction, such as within a particular state within the United States. The MTA computer device is configured to detect differences between predicted pricing output from a predictive pricing sub-model for the jurisdiction as compared to the actual pricing experienced within the jurisdiction for the insurance product. The MTA computer device may execute one or more GPT models to identify data elements that may potentially relate to or be the cause of the pricing differential. The data elements identified may include, but not be limited to, insurance claims history for the persons, assets or vehicles involved, vehicle history of the vehicle involved, prior insurance history for the persons, assets or vehicles involved, and/or public records relating to the same. Additionally or alternatively, the MTA computer device may be programmed to analyze and monitor for trends associated with the differences so that the trends may be further analyzed to better identify the drivers or triggers of the differences and/or trends between different models. The MTA computer device may generate an action item to review the differences identified, and/or other discovered trends. Further, the MTA computer device may be configured to only trigger the generation of the action item when the trend or the differences exceed a predetermined threshold. Thresholds for the different insurance products or items may vary based upon historical analysis and user preferences.” (See paragraph [0025]). Fields discloses receiving, in real time, the one or more rate filings corresponding to the at least one insurance product and translating, via natural language processing, the one or more rate filings, wherein the one or more rate filings are translated into the set of
computer-readable data, parsing the set of computer-readable data to determine a set of pricing information for the at least one insurance product, and
structuring, via the orchestrator, the set of pricing information into the pricing
engine. Fields states that “One exemplary computer system is an insurance rate filing system, such as those used in the insurance industry to calculate insurance rates or prices for an insurance product. In this example, the MTA computer device may be configured to monitor predicted pricing from a model for an insurance product in a jurisdiction, such as within a particular state within the United States. The MTA computer device is configured to detect differences between predicted pricing output from a predictive pricing sub-model for the jurisdiction as compared to the actual pricing experienced within the jurisdiction for the insurance product. The MTA computer device may execute one or more GPT models to identify data elements that may potentially relate to or be the cause of the pricing differential. The data elements identified may include, but not be limited to, insurance claims history for the persons, assets or vehicles involved, vehicle history of the vehicle involved, prior insurance history for the persons, assets or vehicles involved, and/or public records relating to the same. Additionally or alternatively, the MTA computer device may be programmed to analyze and monitor for trends associated with the differences so that the trends may be further analyzed to better identify the drivers or triggers of the differences and/or trends between different models. The MTA computer device may generate an action item to review the differences identified, and/or other discovered trends. Further, the MTA computer device may be configured to only trigger the generation of the action item when the trend or the differences exceed a predetermined threshold. Thresholds for the different insurance products or items may vary based upon historical analysis and user preferences.” (See paragraph [0025]). Fields also states that “In various embodiments, the MTA computer device may receive one or more prompts from the one or more users with instructions, either full or partial, to build the software model template. In some embodiments, the latest production model code may be limited to a specific jurisdiction. In other embodiments, the latest production model code may be limited based upon other factors, such as, but not limited to, specific insurance product, specific item being insured, specific category, and/or any other division of factors desired by the user and/or for compliance, such as with a government entity.” (See paragraph [0030]). Fields states that “In additional embodiments, the MTA computer device 110 may also be in communication with at prompt engineering system 140 that receives natural language text and then converts that text into structured text for interpretation and comprehension by generative AI (artificial intelligence). In some embodiments, the prompt engineering system 140 may be internal to the MTA computer device 110. In other embodiments the prompt engineering system 140 may be separate from the MTA computer device 110. In at least one embodiment, the prompt engineering system 140 acts as an interface between the MTA computer device 110 and one or more client device 145 associated with one or more users.” (See paragraph [0045]).
Regarding claim 2, Fields discloses one or more rate filings are at least one of an updated version of an existing rate filing of an insurance provider or a new rate filing of the insurance provider. Fields states that “In the exemplary embodiment, the MTA computer device determines that the updated predictive pricing model is ready for production and is passed on to other systems that will execute the updated predictive pricing model with live information. In some cases, the MTA computer device is configured to present the updated predictive pricing model along with any changes to the model to a designated party for review purposes. As described herein, in the United States and Canada, predictive pricing models that impact a rating of insurance products may require that rate change filings be approved by a credentialed actuary. Therefore, in those cases where the MTA computer device determines the need for a model change based upon the analysis exceeding one or more thresholds, the MTA computer device may provide reports to the assigned actuary explaining the issues identified and any changes made by the code LLM to generate a new model software template. Dashboards may also be used to better enable the actuary to approve the model changes and track the process of the submission. In other cases, the models being proposed for change may be presented to multiple designated parties for review and approval purposes throughout the change process. In some cases, these changed models may be presented to a party and the approval may be tracked through the MTA system such that an audit may be performed at any time to determine what changes were made to the model, who approved the changes, and when did this all happen. Reports can then be easily generated from this audit trail that is saved in the MTA system.” (See paragraph [0035]).
Regarding claim 3, Fields discloses that the natural language processing engine comprising a large language model based on deep learning. Fields states that “In the exemplary embodiment, the network 105 may include a model training and analysis (MTA) computer device 110. The MTA computer device 110 may begin communication with one or more locally trained large language models (LLM) 115 and one or more external trained LLMs 120. In at least one embodiment, the large language models may be GPT (Generative Pre-trained Transformers) models.” (See paragraph [0039]).
Regarding claim 4, Fields discloses transmitting, by the machine learning model to the administrative body, a query for gathering information associated with structuring of the set of pricing information. Fields states that “One exemplary computer system is an insurance rate filing system, such as those used in the insurance industry to calculate insurance rates or prices for an insurance product. In this example, the MTA computer device may be configured to monitor predicted pricing from a model for an insurance product in a jurisdiction, such as within a particular state within the United States. The MTA computer device is configured to detect differences between predicted pricing output from a predictive pricing sub-model for the jurisdiction as compared to the actual pricing experienced within the jurisdiction for the insurance product. The MTA computer device may execute one or more GPT models to identify data elements that may potentially relate to or be the cause of the pricing differential. The data elements identified may include, but not be limited to, insurance claims history for the persons, assets or vehicles involved, vehicle history of the vehicle involved, prior insurance history for the persons, assets or vehicles involved, and/or public records relating to the same. Additionally or alternatively, the MTA computer device may be programmed to analyze and monitor for trends associated with the differences so that the trends may be further analyzed to better identify the drivers or triggers of the differences and/or trends between different models. The MTA computer device may generate an action item to review the differences identified, and/or other discovered trends. Further, the MTA computer device may be configured to only trigger the generation of the action item when the trend or the differences exceed a predetermined threshold. Thresholds for the different insurance products or items may vary based upon historical analysis and user preferences.” (See paragraph [0025]).
Regarding claims 7 and 10, Fields discloses receiving, from the administrative body, an updated rate filing corresponding to an existing rate filing from the one or more rate filings and updating the pricing engine based on the updated rate filing. Fields states that “In the exemplary embodiment, the MTA computer device determines that the updated predictive pricing model is ready for production and is passed on to other systems that will execute the updated predictive pricing model with live information. In some cases, the MTA computer device is configured to present the updated predictive pricing model along with any changes to the model to a designated party for review purposes. As described herein, in the United States and Canada, predictive pricing models that impact a rating of insurance products may require that rate change filings be approved by a credentialed actuary. Therefore, in those cases where the MTA computer device determines the need for a model change based upon the analysis exceeding one or more thresholds, the MTA computer device may provide reports to the assigned actuary explaining the issues identified and any changes made by the code LLM to generate a new model software template. Dashboards may also be used to better enable the actuary to approve the model changes and track the process of the submission. In other cases, the models being proposed for change may be presented to multiple designated parties for review and approval purposes throughout the change process. In some cases, these changed models may be presented to a party and the approval may be tracked through the MTA system such that an audit may be performed at any time to determine what changes were made to the model, who approved the changes, and when did this all happen. Reports can then be easily generated from this audit trail that is saved in the MTA system.” (See paragraph [0035]).
Regarding claim 9, Fields discloses receiving, from a administrative body from the plurality of administrative bodies, an updated rate filing corresponding to an existing rate filing from the one or more rate filings, determining, using the machine learning model, a difference between the updated rate filing and the existing rate filing from the one or more rate filings, and updating the pricing engine based on the difference between the updated rate filing and the existing rate filing from the one or more rate filings. Fields states that “In the exemplary embodiment, the MTA computer device determines that the updated predictive pricing model is ready for production and is passed on to other systems that will execute the updated predictive pricing model with live information. In some cases, the MTA computer device is configured to present the updated predictive pricing model along with any changes to the model to a designated party for review purposes. As described herein, in the United States and Canada, predictive pricing models that impact a rating of insurance products may require that rate change filings be approved by a credentialed actuary. Therefore, in those cases where the MTA computer device determines the need for a model change based upon the analysis exceeding one or more thresholds, the MTA computer device may provide reports to the assigned actuary explaining the issues identified and any changes made by the code LLM to generate a new model software template. Dashboards may also be used to better enable the actuary to approve the model changes and track the process of the submission. In other cases, the models being proposed for change may be presented to multiple designated parties for review and approval purposes throughout the change process. In some cases, these changed models may be presented to a party and the approval may be tracked through the MTA system such that an audit may be performed at any time to determine what changes were made to the model, who approved the changes, and when did this all happen. Reports can then be easily generated from this audit trail that is saved in the MTA system.” (See paragraph [0035]).
Regarding claim 11, Fields discloses that one or more rate filings from the plurality of administrative bodies correspond to a singular jurisdiction such that the pricing engine determines the price of insurance for the singular jurisdiction. Fields states that “In some embodiments, the latest production model code may be limited to a specific jurisdiction. In other embodiments, the latest production model code is limited based upon other factors, such as, but not limited to, a specific vehicle, a specific asset, a specific category of assets, a specific type of insurance coverage, a category of persons, a health-related category, and/or any other division of factors desired by the user and/or for compliance, such as with a government entity.” (See paragraph [0054]).
Regarding claim 13, Fields discloses that the pricing engine corresponds to a plurality of insurance products. Fields states that “The present embodiments may relate to, inter alia, a system analysis tool that may customize a large language model to work specifically for the system being analyzed. Further, the present embodiments may relate to building, simulating, and validating a machine learning model, and more particularly, to a network-based system and computer-implemented method that uses large language models to build, simulate, and validate a predictive pricing model for calculating insurance rates for one or more insurance products. The computer systems and computer-implemented methods described herein may provide for automating the more time-consuming elements of the building, simulating, and validating of the predictive pricing model(s). These include, but are not limited to, detecting issues with previous predictive pricing models' output, analyzing the predictive pricing models, building model software templates including one or more code changes to the previous predictive pricing model, generating a simulation environment, executing the newly built model software template in the simulation environment, and/or updating the model software template based upon one or more outputs of the execution.” (See paragraph [0007]).
Regarding claim 14, Fields discloses that the plurality of administrative bodies are at least one of federal administrative bodies or state administrative bodies. Fields states that “One exemplary computer system is an insurance rate filing system, such as those used in the insurance industry to calculate insurance rates or prices for an insurance product. In this example, the MTA computer device may be configured to monitor predicted pricing from a model for an insurance product in a jurisdiction, such as within a particular state within the United States. The MTA computer device is configured to detect differences between predicted pricing output from a predictive pricing sub-model for the jurisdiction as compared to the actual pricing experienced within the jurisdiction for the insurance product. The MTA computer device may execute one or more GPT models to identify data elements that may potentially relate to or be the cause of the pricing differential. The data elements identified may include, but not be limited to, insurance claims history for the persons, assets or vehicles involved, vehicle history of the vehicle involved, prior insurance history for the persons, assets or vehicles involved, and/or public records relating to the same. Additionally or alternatively, the MTA computer device may be programmed to analyze and monitor for trends associated with the differences so that the trends may be further analyzed to better identify the drivers or triggers of the differences and/or trends between different models. The MTA computer device may generate an action item to review the differences identified, and/or other discovered trends. Further, the MTA computer device may be configured to only trigger the generation of the action item when the trend or the differences exceed a predetermined threshold. Thresholds for the different insurance products or items may vary based upon historical analysis and user preferences.” (See paragraph [0025]).
Regarding claim 16, Fields discloses that the one or more rate filings are received in real time from at least one of an insurance provider or an administrative body. Fields states that “In various embodiments, training set builder module 408 may be configured to derive training data sets 414 from retrieved subsets 412. Each training data set 414 corresponds to a historical data 404 (“historical” in this context means completed in the past, as opposed to completed in real-time with respect to the time of retrieval by training set builder module 122). Each training data set 414 may include “model input” data fields along with at least one “result” data field representing a historical outcome associated with the model input. The model input data fields represent factors that may be expected to, or unexpectedly be found during model training to, have some correlation.” (See paragraph [0075]).
Regarding claim 17, Fields discloses that the orchestrator is trained on a plurality of historical rate filings and at least one of a plurality of historical pricing engines corresponding to the plurality of historical rate filings or a plurality of quotes corresponding to the plurality of historical rate filings. Fields states that “In various embodiments, training set builder module 408 may be configured to derive training data sets 414 from retrieved subsets 412. Each training data set 414 corresponds to a historical data 404 (“historical” in this context means completed in the past, as opposed to completed in real-time with respect to the time of retrieval by training set builder module 122). Each training data set 414 may include “model input” data fields along with at least one “result” data field representing a historical outcome associated with the model input. The model input data fields represent factors that may be expected to, or unexpectedly be found during model training to, have some correlation.” (See paragraph [0075]).
Regarding claim 18, Fields discloses that the pricing engine is structured with at least one of a matrix, tree, graph, list, or network. Fields states that “In some embodiments, at least one of a plurality of ML methods and algorithms may be applied, which may include but are not limited to: linear or logistic regression, instance-based algorithms, regularization algorithms, decision trees, Bayesian networks, cluster analysis, association rule learning, artificial neural networks, deep learning, combined learning, reinforced learning, dimensionality reduction, and support vector machines. In various embodiments, the implemented ML methods and algorithms are directed toward at least one of a plurality of categorizations of machine learning, such as supervised learning, unsupervised learning, and reinforcement learning.” (See paragraph [0100]).
Regarding claim 19, Fields discloses that the pricing engine corresponds to a singular insurance product. Fields states that “The present embodiments may relate to, inter alia, a system analysis tool that may customize a large language model to work specifically for the system being analyzed. Further, the present embodiments may relate to building, simulating, and validating a machine learning model, and more particularly, to a network-based system and computer-implemented method that uses large language models to build, simulate, and validate a predictive pricing model for calculating insurance rates for one or more insurance products. The computer systems and computer-implemented methods described herein may provide for automating the more time-consuming elements of the building, simulating, and validating of the predictive pricing model(s). These include, but are not limited to, detecting issues with previous predictive pricing models' output, analyzing the predictive pricing models, building model software templates including one or more code changes to the previous predictive pricing model, generating a simulation environment, executing the newly built model software template in the simulation environment, and/or updating the model software template based upon one or more outputs of the execution.” (See paragraph [0007]).
Regarding claim 20, Fields discloses that the one or more rate filings correspond to a plurality of jurisdictions such that the pricing engine can determine the price of insurance for the plurality of jurisdictions. Fields states that “One exemplary computer system is an insurance rate filing system, such as those used in the insurance industry to calculate insurance rates or prices for an insurance product. In this example, the MTA computer device may be configured to monitor predicted pricing from a model for an insurance product in a jurisdiction, such as within a particular state within the United States. The MTA computer device is configured to detect differences between predicted pricing output from a predictive pricing sub-model for the jurisdiction as compared to the actual pricing experienced within the jurisdiction for the insurance product. The MTA computer device may execute one or more GPT models to identify data elements that may potentially relate to or be the cause of the pricing differential. The data elements identified may include, but not be limited to, insurance claims history for the persons, assets or vehicles involved, vehicle history of the vehicle involved, prior insurance history for the persons, assets or vehicles involved, and/or public records relating to the same. Additionally or alternatively, the MTA computer device may be programmed to analyze and monitor for trends associated with the differences so that the trends may be further analyzed to better identify the drivers or triggers of the differences and/or trends between different models. The MTA computer device may generate an action item to review the differences identified, and/or other discovered trends. Further, the MTA computer device may be configured to only trigger the generation of the action item when the trend or the differences exceed a predetermined threshold. Thresholds for the different insurance products or items may vary based upon historical analysis and user preferences.” (See paragraph [0025]).
Conclusion
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to AMIT PATEL whose telephone number is (313) 446-4902. The Examiner can normally be reached on Monday thru Thursday, 7:30 AM - 5:30 PM EST.
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, Matthew Gart can be reached at (571) 272-3955. The Examiner’s fax number is (571) 273-6087. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Amit Patel/
Examiner
Art Unit 3696
/MATTHEW S GART/Supervisory Patent Examiner, Art Unit 3696