Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Status of the Claims
The following office action in response to the amendments filed on 1/30/2026.
Claims 1, 4, 8, 11 and 15 are currently amended.
Therefore, claims 1-20 are pending and addressed below.
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 1, 8 and 15 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claims 1 and 8 recites the limitation "… the carrier-specific API endpoint …”. There is insufficient antecedent basis for this limitation in the claims.
Claim 15 recites the limitation "… the payment screen…”. There is insufficient antecedent basis for this limitation in the claims.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claims 1-20 are directed to a method, a system, a GUI and thus a statutory category of invention (Step 1: YES).
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention recites an abstract idea without significantly more. The claim recites the limitations of “…a user to confirm or edit coverage details; upon receiving confirmation of the coverage details, recalculating the insurance quote based on the confirmed coverage details; the user to select a payment method, upon selection of a payment method, generating a payment token based on the entered payment details; sending a bind request including the payment token and the recalculated quote for binding the insurance policy; receiving a policy number; storing the received policy number; and updating customer relationship management (CRM) data with the policy information, property, driver, vehicle details, the policy number, and the bound status of the insurance policy”. These recited limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of fundamental economic principles or practices (including insurance, i.e. providing an insurance policy for the user) but for the recitation of generic computer components. If a claim limitation, under its broadest reasonable interpretation, covers concepts of fundamental economic principles or practices but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
The additional limitations (besides those that recite the abstract idea) include the presence in the claimed method of a user interface, an application programming interface (API), the carrier-specific API endpoint, an insurance provider system and a database that are all recited at a high level of generality to perform the functions of “…displaying … a confirmation page; recalculating …the insurance quote…; displaying… a payment screen, wherein the payment screen presents… one or more payment options identified as associated with the insurance carrier…; generating… a payment token; sending…a bind request; receiving… a policy number; storing …the received policy number; and updating …customer relationship management (CRM) data…”, such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, the additional elements do not integrate the abstract idea into a particular application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception or amount to an inventive concept. As discussed above with respect to integration of the abstract idea into a practical application, the additional limitations of the user interface, the application programming interface (API), the carrier-specific API endpoint, the insurance provider system and the database that are all recited at a high level of generality to perform the functions of “…displaying … a confirmation page; recalculating …the insurance quote…; displaying… a payment screen, wherein the payment screen presents… one or more payment options identified as associated with the insurance carrier…; generating… a payment token; sending…a bind request; receiving… a policy number; storing …the received policy number; and updating …customer relationship management (CRM) data…”, above amounts to mere instructions to apply the exception using the generic computer components. When viewing the additional elements either individually or as an ordered combination, the claim as a whole does not amount to significantly more than the judicial exception because the claim does not include improvements to another technology or technical field, improvements to the function of the computer itself, and does not provide meaningful limitations beyond general linking the use of an abstract idea to a particular technological environment. In effect, the additional limitations add the words “apply it” (or an equivalent) to the judicial exception, or mere instructions to implement an abstract idea on a computer. Mere instructions to apply an exception using the generic computer component cannot provide an inventive concept. Thus, the claim is not patent eligible.
Independent claim 8 recite limitations substantially similar to claim 1. Thus, the claims are rejected based on the same reasoning as above in claim 1. Thus, the claims are not eligible.
Dependent claims 2-7 and 9-14 are dependent on claims 1 and 8. Therefore, claims 2-7 and 9-14 are directed to the same abstract idea of claims 1 and 8. Claims 2-7 and 9-14 further recite the limitations that merely refer back to further details of the abstract idea. In addition, the additional limitations (besides those that recite the abstract idea) of the payment screen, the third-party database, the API and the payment processor included in the dependent claims 3-6 and 9-13 that are all recited at a high level of generality to perform the functions of “…displaying…the confirmation page…” (claims 2 and 9); “…allow…the user to select the payment methods…” (claims 3 and 10); “…pulled…the mortgage information…” (claims 4 and 11); “…updating…the user’s payment method…” (claims 5 and 12); and “…secure transmission…the encrypted payment details…” (claims 6 and 13); and “updating…the CRM data …” (claims 7 and 14), such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
The dependent claims 2-7 and 9-14 does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception or amount to an inventive concept. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to nothing more than an instruction to “apply it” with the judicial exception. In addition, the additional limitations (besides those that recite the abstract idea) of the payment screen, the third-party database, the API and the payment processor included in the dependent claims 3-6 and 9-13 that are all recited at a high level of generality to perform the functions of “…displaying…the confirmation page…” (claims 2 and 9); “…allow…the user to select the payment methods…” (claims 3 and 10); “…pulled…the mortgage information…” (claims 4 and 11); “…updating…the user’s payment method…” (claims 5 and 12); and “…secure transmission…the encrypted payment details…” (claims 6 and 13); and “updating…the CRM data …” (claims 7 and 14), above amounts to mere instructions to apply the exception using the generic computer components. When viewing the additional elements either individually or as an ordered combination, the claim as a whole does not amount to significantly more than the judicial exception because the claim does not include improvements to another technology or technical field, improvements to the function of the computer itself, and does not provide meaningful limitations beyond general linking the use of an abstract idea to a particular technological environment. In effect, the additional limitations add the words “apply it” (or an equivalent) to the judicial exception, or mere instructions to implement an abstract idea on a computer. Mere instructions to apply an exception using the generic computer component cannot provide an inventive concept. Thus, when considering the combination of elements and the claimed as a whole, the dependent claims 2-7 and 9-14 are not patent eligible.
Claim 15 is rejected under 35 U.S.C. 101 because the claimed invention recites an abstract idea without significantly more. The claim recites the limitations of “…receive input for property and vehicle details for insurance coverage; validation of the inputted insurance coverage details; accept a user's selection of a payment method; receive user input relating to mortgage details pertinent to the insurance policy; and display a summary of the insurance policy details for final user confirmation”. These recited limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of fundamental economic principles or practices (including insurance, i.e. providing an insurance policy for the user) but for the recitation of generic computer components. If a claim limitation, under its broadest reasonable interpretation, covers concepts of fundamental economic principles or practices but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
The additional limitations (besides those that recite the abstract idea) include the presence in the claimed GUI of a plurality of user-interactive fields, a confirmatory screen page, a payment interface page, a carrier-specific API endpoint, a mortgage information interface page and a final review interface page that are all recited at a high level of generality to perform the functions of “receive… input for insurance coverage; prompting… user validation; accept… a user's selection of a payment method; wherein the payment screen presents… one or more payment options identified as associated with the insurance carrier…; receive … user input; and display… a summary of the insurance policy details for final user confirmation”, such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, the additional elements do not integrate the abstract idea into a particular application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception or amount to an inventive concept. As discussed above with respect to integration of the abstract idea into a practical application, the additional limitations of the plurality of user-interactive fields, the confirmatory screen page, the payment interface page, the carrier-specific API endpoint, the mortgage information interface page and the final review interface page that are all recited at a high level of generality to perform the functions of “receive… input for insurance coverage; prompting… user validation; accept… a user's selection of a payment method; wherein the payment screen presents… one or more payment options identified as associated with the insurance carrier…; receive … user input; and display… a summary of the insurance policy details for final user confirmation”, above amounts to mere instructions to apply the exception using the generic computer components. When viewing the additional elements either individually or as an ordered combination, the claim as a whole does not amount to significantly more than the judicial exception because the claim does not include improvements to another technology or technical field, improvements to the function of the computer itself, and does not provide meaningful limitations beyond general linking the use of an abstract idea to a particular technological environment. In effect, the additional limitations add the words “apply it” (or an equivalent) to the judicial exception, or mere instructions to implement an abstract idea on a computer. Mere instructions to apply an exception using the generic computer component cannot provide an inventive concept. Thus, the claim is not patent eligible.
Dependent claims 16-20 are dependent on claim 15. Therefore, claims 16-20 are directed to the same abstract idea of claim 15. Claims 16-20 further recite the limitations that merely refer back to further details of the abstract idea. In addition, the additional limitations (besides those that recite the abstract idea) of the confirmatory screen page, the payment interface page, the discount and additional coverage interface page, the update interface page, the backend application programming interface (API) and the issuance interface page that are all recited at a high level of generality to perform the functions of “…editing… of the inputted details…” (claim 16); “generate… a secure payment token…” (claim 17); “presents …a selection of discounts and additional coverages…” (claim 18); “retrieve and display… updated mortgage information” (claim 19); and “display …the status of the insurance policy…” (claim 20), such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
The dependent claims 16-20 does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception or amount to an inventive concept. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to nothing more than an instruction to “apply it” with the judicial exception. In addition, the additional limitations (besides those that recite the abstract idea) of the confirmatory screen page, the payment interface page, the discount and additional coverage interface page, the update interface page, the backend application programming interface (API) and the issuance interface page that are all recited at a high level of generality to perform the functions of “…editing… of the inputted details…” (claim 16); “generate… a secure payment token…” (claim 17); “presents …a selection of discounts and additional coverages…” (claim 18); “retrieve and display… updated mortgage information” (claim 19); and “display …the status of the insurance policy…” (claim 20), above amounts to mere instructions to apply the exception using the generic computer components. When viewing the additional elements either individually or as an ordered combination, the claim as a whole does not amount to significantly more than the judicial exception because the claim does not include improvements to another technology or technical field, improvements to the function of the computer itself, and does not provide meaningful limitations beyond general linking the use of an abstract idea to a particular technological environment. In effect, the additional limitations add the words “apply it” (or an equivalent) to the judicial exception, or mere instructions to implement an abstract idea on a computer. Mere instructions to apply an exception using the generic computer component cannot provide an inventive concept. Thus, when considering the combination of elements and the claimed as a whole, the dependent claims 16-20 are not patent eligible.
Response to Arguments
Previous Abstract Objection
The previous abstract objection has been withdrawn in the light of Applicant’s amendments.
Previous Claim rejections – 35 USC § 101
The updated rejections of claims 1-20 under the 35 USC 101 have been provided in the light of Applicant’s amendments.
Applicant's arguments filed 1/30/2026 have been fully considered but they are not persuasive.
Argument 1: Applicant argued that: “…Amended claim 1 now requires that the payment screen presents one or more payment options identified as associated with the insurance carrier via the carrier-specific API endpoint… This limitation is not a field-of-use label. It imposes a concrete, technical constraint: the system must programmatically determine which payment options are available for the selected carrier by interacting with a carrier-specific endpoint and then condition the UI presentation on that carrier- derived result…Step 2A, Prong 1 (recites an abstract idea) - at least the claim is not a "mental process"… Step 2A, Prong 2 - the claim is integrated into a practical application…” (Please see the remarks on pages 8-11).
Answer 1: The Examiner respectfully disagrees.
As the office has explained above that the claim recites the limitations of “…a user to confirm or edit coverage details; upon receiving confirmation of the coverage details, recalculating the insurance quote based on the confirmed coverage details; the user to select a payment method, upon selection of a payment method, generating a payment token based on the entered payment details; sending a bind request including the payment token and the recalculated quote for binding the insurance policy; receiving a policy number; storing the received policy number; and updating customer relationship management (CRM) data with the policy information, property, driver, vehicle details, the policy number, and the bound status of the insurance policy”. These recited limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of fundamental economic principles or practices (including insurance, i.e. providing an insurance policy for the user) but for the recitation of generic computer components. If a claim limitation, under its broadest reasonable interpretation, covers concepts of fundamental economic principles or practices but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
The additional limitations (besides those that recite the abstract idea) include the presence in the claimed method of a user interface, an application programming interface (API), the carrier-specific API endpoint, an insurance provider system and a database that are all recited at a high level of generality to perform the functions of “…displaying … a confirmation page; recalculating …the insurance quote…; displaying… a payment screen, wherein the payment screen presents… one or more payment options identified as associated with the insurance carrier…; generating… a payment token; sending…a bind request; receiving… a policy number; storing …the received policy number; and updating …customer relationship management (CRM) data…”, such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, the additional elements do not integrate the abstract idea into a particular application because it does not impose any meaningful limits on practicing the abstract idea.
In addition, the MPEP 2106.04(a) states that: “…Examiners should determine whether a claim recites an abstract idea by (1) identifying the specific limitation(s) in the claim under examination that the examiner believes recites an abstract idea, and (2) determining whether the identified limitations(s) fall within at least one of the groupings of abstract ideas listed above. If the identified limitation(s) falls within at least one of the groupings of abstract ideas, it is reasonable to conclude that the claim recites an abstract idea in Step 2A Prong One”. Thus, according to the MPEP 2106.04(a), Examiner (1) identifying the specific limitation(s) (a user to confirm or edit coverage details; upon receiving confirmation of the coverage details, recalculating the insurance quote based on the confirmed coverage details; the user to select a payment method, upon selection of a payment method, generating a payment token based on the entered payment details; sending a bind request including the payment token and the recalculated quote for binding the insurance policy; receiving a policy number; storing the received policy number; and updating customer relationship management (CRM) data with the policy information, property, driver, vehicle details, the policy number, and the bound status of the insurance policy) falls within the subject matter groupings of abstract ideas of “Certain Methods Of Organizing Human Activity: fundamental economic principles or practices (including insurance, i.e. providing an insurance policy for the user) in the Applicant’s claim under examination that the examiner believes recites an abstract idea, and (2) determining whether the identified limitations(s) (a user to confirm or edit coverage details; upon receiving confirmation of the coverage details, recalculating the insurance quote based on the confirmed coverage details; the user to select a payment method, upon selection of a payment method, generating a payment token based on the entered payment details; sending a bind request including the payment token and the recalculated quote for binding the insurance policy; receiving a policy number; storing the received policy number; and updating customer relationship management (CRM) data with the policy information, property, driver, vehicle details, the policy number, and the bound status of the insurance policy) fall within at least one of the groupings of abstract ideas listed above. If the identified limitation(s) falls within at least one of the groupings of abstract ideas, it is reasonable to conclude that the claim recites an abstract idea in Step 2A Prong One”.
Therefore, the claim recites an abstract idea of “Certain Methods Of Organizing Human Activity: fundamental economic principles or practices” and the claim does not integrate the abstract idea into a particular application because it does not impose any meaningful limits on practicing the abstract idea. Thus, Applicant’s arguments are not persuasive.
Argument 2: Applicant argued that: “…Step 2B - the ordered combination provides "significantly more" Even assuming arguendo that claim 1 "recites" an abstract idea, the claim still includes an inventive concept when its elements are considered as an ordered combination…” (Please see the remarks on pages 11-12).
Answer 2: The Examiner respectfully disagrees.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception or amount to an inventive concept. As discussed above with respect to integration of the abstract idea into a practical application, the additional limitations of the user interface, the application programming interface (API), the carrier-specific API endpoint, the insurance provider system and the database that are all recited at a high level of generality to perform the functions of “…displaying … a confirmation page; recalculating …the insurance quote…; displaying… a payment screen, wherein the payment screen presents… one or more payment options identified as associated with the insurance carrier…; generating… a payment token; sending…a bind request; receiving… a policy number; storing …the received policy number; and updating …customer relationship management (CRM) data…”, above amounts to mere instructions to apply the exception using the generic computer components. When viewing the additional elements either individually or as an ordered combination, the claim as a whole does not amount to significantly more than the judicial exception because the claim does not include improvements to another technology or technical field, improvements to the function of the computer itself, and does not provide meaningful limitations beyond general linking the use of an abstract idea to a particular technological environment. In effect, the additional limitations add the words “apply it” (or an equivalent) to the judicial exception, or mere instructions to implement an abstract idea on a computer. Mere instructions to apply an exception using the generic computer component cannot provide an inventive concept. Thus, the claim is not patent eligible.
For the above reasons, it is believed that Appellant's arguments have been fully considered but they are not persuasive and the rejections should be sustained.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tien C. Nguyen whose telephone number is 571-270-5108. The examiner can normally be reached on Monday-Thursday (6am-2pm EST).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor,
Bennett Sigmond can be reached on 303-297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-270-6108.
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.
/TIEN C NGUYEN/Primary Examiner, Art Unit 3694
Prosecution Insights