DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is responsive to claims filed 10/27/2025 and Applicant’s communication regarding application 14/461711 filed 10/27/2025.
Claims 1, 12, 14, 16, 19-22, 26, 30, 38, and 41 have been examined with this office action.
Claim Interpretation
availability scripts - define the relationships that read the rules from system tables [0051].
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, 12, 14, 16, 19-22, 26, 30, 38, and 41 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea of insurance product model relationships without significantly more.
Subject Matter Eligibility Standard
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 significantly more than the abstract idea itself. Examples of abstract ideas include fundamental economic practices; certain methods of organizing human activities; an idea itself; and mathematical relationships/formulas. Alice Corporation Pty. Ltd. v.CLS Bank International, et al., 573 U.S. _ (2014) as provided by the interim guidelines FR 12/16/2014 Vol. 79 No. 241.
Analysis
Step 1, the claimed invention must be to one of the four statutory categories. 35 U.S.C. 101 defines the four categories of invention that Congress deemed to be the appropriate subject matter of a patent: processes, machines, manufactures and compositions of matter. In this case independent claims 1 and all claims which depend from it are directed toward an apparatus and independent claim 19 and 20 and all claims which depend from it are directed toward a method.
Step 2A Prong 1, Under Step 2 A, Prong 1 of the 2019 Revised § 101 Guidance, it is determined whether the claims are directed to a judicial exception such as a law of nature, a natural phenomenon, or an abstract idea (See Alice, 134 S. Ct. at 2355) by identify the specific limitation(s) in the claim that recites abstract idea(s); and then determine whether the identified limitation(s) falls within at least one of the groupings of abstract ideas enumerated in the 2019 PEG.
Specifically, claims 1 comprises inter alia the functions or steps of “A system, comprising: one or more memories configured to: store a relationship rules data store in a centralized file, the centralized relationship rules data store comprising a plurality of relationship rules, wherein a relationship rule in the centralized relationship rules data store comprises a specification of a relationship between a source insurance product model pattern and a target insurance product model pattern, wherein unique identifiers for the source and target insurance product model patterns are stored in the relationship rules data store, wherein the relationship between the source insurance product model pattern to the target insurance product model pattern is specified based at least in part on a relationship type, wherein the source insurance product model pattern comprises at least one of a source coverage, a source term, and a source option, wherein the target insurance product model pattern comprises at least one of a target coverage, a target coverage term, and a target option, wherein the relationship rule is associated with an availability table and an availability script, and wherein relationship rules are added or edited and stored in the centralized relationship rules data store; andone or more processors configured to: mirror, in a database, the centralized file comprising the relationship rules data store; update relationship rule changes at least in part by performing a server update, wherein performing the server update comprises dynamically reloading, during run-time, relationship rules into the database in which the centralized file comprising the relationship rules data store is mirrored; cause a user interface to be loaded, wherein loading of the user interface comprises loading information indicating which user interface elements in the user interface have dependency relationships; detect an indication that a portion of the user interface associated with the source insurance product model pattern is to be updated, wherein the indication is triggered in response to detecting a user input with respect to a user interface element associated with the source insurance product model pattern, and wherein the user interface element comprises an input widget; based at least in part on the loaded information indicating which user interface elements in the user interface have dependency relationships, determine that the user interface element with respect to which the user input was detected has a dependency; the determination that the user interface element with respect to which the user input was detected has a dependency, check, by the user interface element comprising the input widget, the centralized relationship rules data store for a dependency relationship, wherein the relationship rule between the source insurance product model pattern and the target insurance product model pattern is identified in the centralized relationship rules data store based at least in part on the checking;present, via the user interface, user interface elements, comprising:
receiving a selection of a first insurance product model pattern element of insurance product model pattern elements via the user interface;
in response to the receiving of the selection, performing one or more of the following:
A) determining that the first insurance product model pattern element is dependently exclusive with the second insurance product model pattern element; and
in response to a determination that the first insurance product model pattern element is dependently exclusive with the second insurance product model pattern element, automatically excluding availability of the second insurance product model pattern element;
B) determining that the first insurance product model pattern element is mutually exclusive with a third insurance product model pattern element; and in response to a determination that the first insurance product model pattern element is mutually exclusive with the third insurance product model pattern element, uncheck the third insurance product model pattern element; and/or
C) determining that the first insurance product model pattern element is
dependently grouped with a fourth insurance product model pattern element; and in response to a determination that the first insurance product model pattern element is dependently grouped with the fourth insurance product model pattern element, automatically select the fourth insurance product model pattern element;
and rendering the insurance product model pattern elements, comprising: rendering an expanded navigation tree associated with the first specific insurance product model pattern element, wherein elements of the expanded navigation tree directly map to a portion of the insurance product model pattern elements: when the rendering of the insurance product model pattern elements is performed, determine a visibility of the target insurance product model pattern in the user interface based on an evaluation of conditional dependencies, wherein determining the visibility of the target insurance product model pattern in the user interface comprises determining whether to show or hide the target insurance product model pattern in the user interface at least in part by based at least in part on evaluating (1) the availability table associated with the relationship rule, (2) a relationship type specified for the identified relationship rule, and (3) the availability script associated with the relationship rule; in response to determining that the target insurance product model pattern is to be shown, update an affected portion of the user interface associated with the target insurance product model pattern at least in part by automatically refreshing a target element associated with the target insurance product model pattern; in response to modification of a value associated with the target element, refresh a container comprising an iterator associated with the target element, wherein a user interface widget refresh attribute associated with the iterator is set to target the container; in response to determining that the target insurance product model pattern is available, perform re-evaluation of availability for relationship rules in different portions of the user interface, wherein performing the re-evaluation comprises checking the availability of only those relationship rules that potentially affect the target insurance product model pattern; determine a change to the centralized relationship rules data store, wherein the centralized relationship rules data store is comprised in an insurance product model editor that is connected over a network with policy center software comprising the user interface, wherein the insurance product model editor comprising the centralized relationship rules data store resides on a separate server, wherein the centralized relationship rules data store is changed at least in part by accessing the centralized relationship rules data store via an administration interface, and wherein code of the user interface is configured to check the centralized relationship rules data store comprised in the insurance product model editor residing on the separate server to determine the change to the centralized relationship rules data store; in response to determining the change in the centralized relationship rules data store: dynamically reload relationship rules into the database during run-time; and refresh the user interface to load information pertaining to the change; and periodically check the centralized relationship rules data store for changes, wherein the user interface is subsequently refreshed to load the changes;
in response to an occurrence of an out of sequence policy change, trigger an out of sequence conflict resolution user interface, wherein the occurrence of the out of sequence policy change is associated with a conflict that is created for one of the source insurance product model pattern or the target insurance product model pattern involved in the relationship between its value at two different slice dates, wherein a user is prompted, via the out of sequence conflict resolution user interface to resolve the conflict, wherein the out of sequence conflict resolution user interface renders the relationship such that a user is unable to make a change that violates the relationship specified in the centralized relationship rules data store, wherein the source insurance product model pattern comprises a set of one or more elements in an insurance product model, and wherein the insurance product model is synchronized following out of sequence conflict resolution: and
wherein the one or more memories are coupled to the one or more processors and configured to provide the one or more processors with instructions”.
Claims 19 comprises inter alia the functions or steps of “A method, comprising: storing a relationship rules data store in a centralized file, the centralized relationship rules data store comprising a plurality of relationship rules, wherein a relationship rule in the centralized relationship rules data store comprises a specification of a relationship between a source insurance product model pattern and a target insurance product model pattern, wherein unique identifiers for the source and target insurance product model patterns are stored in the relationship rules data store, wherein the relationship between the source insurance product model pattern to the target insurance product model pattern is specified based at least in part on a relationship type, wherein the source insurance product model pattern comprises at least one of a source coverage, a source term, and a source option, wherein the target insurance product model pattern comprises at least one of a target coverage, a target coverage term, and a target option, wherein the relationship rule is associated with an availability table and an availability script, and wherein relationship rules are added or edited and stored in the centralized relationship rules data store; mirroring, in a database, the centralized file comprising the relationship rules data store; updating relationship rule changes at least in part by performing a server update, wherein performing the server update comprises dynamically reloading, during run-time, relationship rules into the database in which the centralized file comprising the relationship rules data store is mirrored; causing a user interface to be loaded, wherein loading of the user interface comprises loading information indicating which user interface elements in the user interface have dependency relationships; detecting an indication that a portion of the user interface associated with the source insurance product model pattern is to be updated, wherein the indication is triggered in response to detecting a user input with respect to a user interface element associated with the source insurance product model pattern, and wherein the user interface element comprises an input widget; based at least in part on the loaded information indicating which user interface elements in the user interface have dependency relationships, determining that the user interface element with respect to which the user input was detected has a dependency; based at least in part on the determination that the user interface element with respect to which the user input was detected has a dependency, checking, by the user interface element comprising the input widget, the centralized relationship rules data store for a dependency relationship, wherein the relationship rule between the source insurance product model pattern and the target insurance product model pattern is identified in the centralized relationship rules data store based at least in part on the checking; presenting, via the user interface, user interface elements, comprising:
receiving a selection of a first insurance product model pattern element of insurance product model pattern elements via the user interface; and
in response to the receiving of the selection, performing one or more of the following:
A) determining that the first insurance product model pattern element is dependently exclusive with the second insurance product model pattern element; and
in response to a determination that the first insurance product model pattern element is dependently exclusive with the second insurance product model pattern element, automatically excluding availability of the second insurance product model pattern element;
B) determining that the first insurance product model pattern element is mutually exclusive with a third insurance product model pattern element; and in response to a determination that the first insurance product model pattern element is mutually exclusive with the third insurance product model pattern element, uncheck the third insurance product model pattern element; and/or
C) determining that the first insurance product model pattern element is
dependently grouped with a fourth insurance product model pattern element; and in response to a determination that the first insurance product model pattern element is dependently grouped with the fourth insurance product model pattern element, automatically select the fourth insurance product model pattern element;
rendering the insurance product model pattern elements, comprising: rendering an expanded navigation tree associated with the first specific insurance product model pattern element, wherein elements of the expanded navigation tree directly map to a portion of the insurance product model pattern elements: when the rendering of the insurance product model pattern elements is performed, determine a visibility of the target insurance product model pattern in the user interface based on an evaluation of conditional dependencies, wherein determining the visibility of the target insurance product model pattern in the user interface comprises determining whether to show or hide the target insurance product model pattern in the user interface at least in part by evaluating (1) the availability table associated with the relationship rule, (2) a relationship type specified for the identified relationship rule, and (3) the availability script associated with the relationship rule; in response to determining that the target insurance product model pattern is to be shown, updating an affected portion of the user interface associated with the target insurance product model pattern at least in part by automatically refreshing a target element associated with the target insurance product model pattern; in response to modification of a value associated with the target element, refreshing a container comprising an iterator associated with the target element, wherein a user interface widget refresh attribute associated with the iterator is set to target the container; in response to determining that the target insurance product model pattern is available, performing re-evaluation of availability for relationship rules in different portions of the user interface, wherein performing the re-evaluation comprises checking the availability of only those relationship rules that potentially affect the target insurance product model pattern; determining a change to the centralized relationship rules data store, wherein the centralized relationship rules data store is comprised in an insurance product model editor that is connected over a network with policy center software comprising the user interface, wherein the insurance product model editor comprising the centralized relationship rules data store resides on a separate server, wherein the centralized relationship rules data store is changed at least in part by accessing the centralized relationship rules data store via an administration interface, and wherein code of the user interface is configured to check the centralized relationship rules data store comprised in the insurance product model editor residing on the separate server to determine the change to the centralized relationship rules data store; in response to determining a change in the centralized relationship rules data store: dynamically reloading relationship rules into the database during run-time; and refreshing the user interface to load information pertaining to the change; periodically checking the centralized relationship rules data store for changes, wherein the user interface is subsequently refreshed to load the changesin response to an occurrence of an out of sequence policy change, trigger an out of sequence conflict resolution user interface, wherein the occurrence of the out of sequence policy change is associated with a conflict that is created for one of the source insurance product model pattern or the target insurance product model pattern involved in the relationship between its value at two different slice dates, wherein a user is prompted, via the out of sequence conflict resolution user interface to resolve the conflict, wherein the out of sequence conflict resolution user interface renders the relationship such that a user is unable to make a change that violates the relationship specified in the centralized relationship rules data store, wherein the source insurance product model pattern comprises a set of one or more elements in an insurance product model, and wherein the insurance product model is synchronized following out of sequence conflict resolution”.
Claims 20 comprises inter alia the functions or steps of “A computer program product embodied in a non-transitory computer readable storage medium and comprising computer instructions for: storing a relationship rules data store in a centralized file, the centralized relationship rules data store comprising a plurality of relationship rules, wherein a relationship rule in the centralized relationship rules data store comprises a specification of a relationship between a source insurance product model pattern and a target insurance product model pattern, wherein unique identifiers for the source and target insurance product model patterns are stored in the relationship rules data store, wherein the relationship between the source insurance product model pattern to the target insurance product model pattern is specified based at least in part on a relationship type, wherein the source insurance product model pattern comprises at least one of a source coverage, a source term, and a source option, wherein the target insurance product model pattern comprises at least one of a target coverage, a target coverage term, and a target option, wherein the relationship rule is associated with an availability table and an availability script, and wherein relationship rules are added or edited and stored in the centralized relationship rules data store; mirroring, in a database, the centralized file comprising the relationship rules data store; updating relationship rule changes at least in part by performing a server update, wherein performing the server update comprises dynamically reloading, during run-time, relationship rules into the database in which the centralized file comprising the relationship rules data store is mirrored; causing a user interface to be loaded, wherein loading of the user interface comprises loading information indicating which user interface elements in the user interface have dependency relationships; detecting an indication that a portion of the user interface associated with the source insurance product model pattern is to be updated, wherein the indication is triggered in response to detecting a user input with respect to a user interface element associated with the source insurance product model pattern, and wherein the user interface element comprises an input widget; based at least in part on the loaded information indicating which user interface elements in the user interface have dependency relationships, determining that the user interface element with respect to which the user input was detected has a dependency; based at least in part on the determination that the user interface element with respect to which the user input was detected has a dependency, checking, by the user interface element comprising the input widget, the centralized relationship rules data store for a dependency relationship, wherein the relationship rule between the source insurance product model pattern and the target insurance product model pattern is identified in the centralized relationship rules data store based at least in part on the checking;present, via the user interface, user interface elements, comprising:
receiving a selection of a first insurance product model pattern element of insurance product model pattern elements via the user interface; and
in response to the receiving of the selection, performing one or more of the following:
A) determining that the first insurance product model pattern element is dependently exclusive with the second insurance product model pattern element; and
in response to a determination that the first insurance product model pattern element is dependently exclusive with the second insurance product model pattern element, automatically excluding availability of the second insurance product model pattern element;
B) determining that the first insurance product model pattern element is mutually exclusive with a third insurance product model pattern element; and in response to a determination that the first insurance product model pattern element is mutually exclusive with the third insurance product model pattern element, uncheck the third insurance product model pattern element; and/or
C) determining that the first insurance product model pattern element is
dependently grouped with a fourth insurance product model pattern element; and in response to a determination that the first insurance product model pattern element is dependently grouped with the fourth insurance product model pattern element, automatically select the fourth insurance product model pattern element;
rendering the insurance product model pattern elements, comprising: rendering an expanded navigation tree associated with the selected first insurance product model pattern element, wherein elements of the expanded navigation tree directly map to a portion of the insurance product model pattern elements: when the rendering of the insurance product model pattern elements is performed, determine a visibility of the target insurance product model pattern in the user interface based on an evaluation of conditional dependencies, wherein determining the visibility of the target insurance product model pattern in the user interface comprises determining whether to show or hide the target insurance product model pattern in the user interface at least in part by evaluating (1) the availability table associated with the relationship rule, (2) a relationship type specified for the identified relationship rule, and (3) the availability script associated with the relationship rule; in response to determining that the target insurance product model pattern is to be shown, updating an affected portion of the user interface associated with the target insurance product model pattern at least in part by automatically refreshing a target element associated with the target insurance product model pattern; in response to modification of a value associated with the target element, refreshing a container comprising an iterator associated with the target element, wherein a user interface widget refresh attribute associated with the iterator is set to target the container; in response to determining that the target insurance product model pattern is available, performing re-evaluation of availability for relationship rules in different portions of the user interface, wherein performing the re-evaluation comprises checking the availability of only those relationship rules that potentially affect the target insurance product model pattern; determining a change to the centralized relationship rules data store, wherein the centralized relationship rules data store is comprised in an insurance product model editor that is connected over a network with policy center software comprising the user interface, wherein the insurance product model editor comprising the centralized relationship rules data store resides on a separate server, wherein the centralized relationship rules data store is changed at least in part by accessing the centralized relationship rules data store via an administration interface, and wherein code of the user interface is configured to check the centralized relationship rules data store comprised in the insurance product model editor residing on the separate server to determine the change to the centralized relationship rules data store; in response to determining a change in the centralized relationship rules data store: dynamically reloading relationship rules into the database during run-time; and refreshing the user interface to load information pertaining to the change; periodically checking the centralized relationship rules data store for changes, wherein the user interface is subsequently refreshed to load the changes; and in response to an occurrence of an out of sequence policy change, trigger an out of sequence conflict resolution user interface, wherein the occurrence of the out of sequence policy change is associated with a conflict that is created for one of the source insurance product model pattern or the target insurance product model pattern involved in the relationship between its value at two different slice dates, wherein a user is prompted, via the out of sequence conflict resolution user interface to resolve the conflict, wherein the out of sequence conflict resolution user interface renders the relationship such that a user is unable to make a change that violates the relationship specified in the centralized relationship rules data store, wherein the source insurance product model pattern comprises a set of one or more elements in an insurance product model, and wherein the insurance product model is synchronized following out of sequence conflict resolution”.
Those claim limits in bold are identified as claim limits directed toward the abstract idea, while those that are un-bolded are identified as additional elements.
The cited limitations as drafted are systems and methods that, under their broadest reasonable interpretation, covers performance of a method of organizing human activity, but for the recitation of the generic computer components. The claim limit of “cause a user interface to be loaded, wherein loading of the user interface comprises loading information including which user interface elements in the user interface have dependency relationships” is interpreted in view of the specification [00190] as a user opening a page which is an extra-solution activity. Further, none of the limitations recite technological implementations details for any of the steps but, instead, only recite broad functional language being performed by the generic use of at least one processor. Insurance product model relationships is a fundamental economic practice long prevalent in commerce systems. If a claim limitation, under its broadest reasonable interpretation, covers a fundamental economic principle or practice but for the general linking to a technological environment, then it falls within the organizing human activity grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong 2, Next, it is determined whether the claim is directed to the abstract concept itself or whether it is instead directed to some technological implementation or application of, or improvement to, this concept, i.e., integrated into a practical application. See, e.g., Alice, 573 U.S. at 223, discussing Diamond v. Diehr, 450 U.S. 175 (1981). The mere introduction of a computer or generic computer technology into the claims need not alter the analysis. See Alice, 573 U.S. at 223—24. “[T]he relevant question is whether the claims here do more than simply instruct the practitioner to implement the abstract idea on a generic computer.” Alice, 573 U.S. at 225.
In the present case, the judicial exception is not integrated into a practical application. The claim limitations are not indicative of integration into a practical application by claiming an improvement to the functioning of the computer or to any other technology or technical field. Further, the claim limitations are not indicative of integration into a practical application by applying or using the judicial exception in some other meaningful way. In particular the claim limits of storing (maintaining and caching), rendering, navigation trees, detecting, and receiving (loading) data including the use of widgets or availability scripts which are claimed and described at a high level of generality and are functions any general purpose computer performs such that it amount no more than mere instruction to apply the exception to a particular technological environment. Further, none of the limitations recite technological implementations details for any of the steps but, instead, only recite broad functional language being performed by the generic use of at least one processor. The claim limits also recite the use of a processor, memory, a network, user interface, widgets, iterator, and container. However, the use of these additionally elements described at a high level of generality and perform generic computer functions such that it amount no more than mere instruction to apply the exception to a particular technological environment. The claim limits “cache the re-evaluation wherein performing the caching comprises limiting checking of availability of relationship rules to those relationship rules that potentially affect the target insurance product model pattern determined to be available” involves the use of cache. However, the caching in the specification [00140][00203] is described at a high level of generality various ways to cache as to merely apply caching to the abstract idea. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaning limits on practicing the abstract idea. Thus, the claim is directed toward an abstract idea.
Step 2B, the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as an ordered combination do not amount to significantly more that the abstract idea(s). As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a processor to perform the abstract idea(s) amounts to no more than mere instructions to apply the exaction using a generic computer component. Mere instruction to apply an exertion using a generic computer component cannot provide an inventive concept. These generic computer components are claimed at a high level of generality to perform their basic functions which amount to no more than generally linking the use of the judicial exception to the particular technological environment of field of use (Specification, metadata [¶26-33] programmed computer [¶202-211] availability scripts [0051] “Various ways to cache the re-evaluations may be used to efficiently minimize the performance and complexity impact” [0141] “For example, processor 1602 can also directly and very rapidly retrieve and store frequently needed data in a cache memory (not shown)” [0173] “Because each relationship rule has its own availability table and availability script there may be interaction effects that require re-evaluation of availability for relationship rules in different screens. As an example, if a user changes the State in a screen from NJ to CA for which a relationship rule becomes available, this requires re-evaluation of the availability calculations for the relationship rule and then re-evaluation of the rule conditions itself. Various ways to cache the re-evaluations may be used to efficiently minimize the performance and complexity impact. For example, one performance-saving technique is to "lazy-evaluate" the availability of relationship rules. This means that if a pattern becomes available, then the system can check the availability of only those relationship rules that potentially affect that pattern.” [00140] [00178]) and further see insignificant extra-solution activity MPEP § 2106.05 I. A. iii, 2106.05(b), 2106.05(b) III, 2106.05(g). Thus, the claims are not patent eligible.
As for dependent claims 12, 14, 16, 21, 22, 26, 30, 37, 38, 41, these claims recite limitations that further define the same abstract idea noted from the respective independent claims from which they depend. In addition, the cited dependent claims recite the additional elements of storing (maintaining), detecting, and receiving (loading) to and from the payment server. The server in both steps is recited at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer component. Even in combination, these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself. Therefore, the cited dependent claims are ineligible.
Prior Art
The claims overcome the prior art of record such that none of the cited prior art reference’s disclosures can be applied to form the basis of a 35 USC § 102 rejection nor can they be combined to fairly suggest in combination, the basis of a 35 USC § 103 rejection when the limitations directed toward the abstract idea of insurance product model relationships are read in the particular environment of the claims. Therefore, the claims may be allowable if amended to overcome the rejection(s) under 35 U.S.C. 101, set forth in this Office action.
Response to Arguments
Applicant's arguments with regards to claims have been fully considered but they are not persuasive.
EXAMINER’S RESPONSE to APPLICANT REMARKS CONCERNING Claim Rejections - 35 USC § 101: The Examiner respectfully disagrees with Applicant’s arguments that amendments overcome the standing 35 USC § 101 rejection.
Regarding applicant’s argument directed toward independent claims 1, 19, and 20 and claims which depend therefrom, that the claims do not recite an abstract idea, the examiner disagrees. Insurance product model relationships is a fundamental economic practice long prevalent in commerce systems. If a claim limitation, under its broadest reasonable interpretation, covers a fundamental economic principle or practice but for the general linking to a technological environment, then it falls within the organizing human activity grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
There is no claimed improvement to a computer, to a technology, or to a technical field. The amended claims merely apply add additional abstract ideas involving the determination of an insurance product based on rules (patterns). There is no improvement to the underlying technical environment.
Regarding applicant’s argument that “"[t]he features described herein make the definitions of insurance product model pattern relationships easier to configure. In some embodiments, a generic framework within the insurance product model editor (e.g., product designer) is used to define the relationships in table format and make the insurance product model input widgets check that information SO no extra user interface configuration is required. This makes it easier for customers and service teams to configure interrelationships in the insurance product model, and for development teams to create line of business content,”, a general purpose computer is flexible—it can do anything it is programmed to do. Therefore, the disclosure of a general purpose computer or a microprocessor as corresponding structure for a software function does nothing to limit the scope of the claim and “avoid pure functional claiming.” Further, the “prohibition against patenting abstract ideas ‘cannot be circumvented by attempting to limit the use of the formula to a particular technological environment’ or adding ‘insignificant postsolution activity.’” Bilski v. Kappos, 561 U.S. 593, 610–11 (2010) (quoting Diamond v. Diehr, 450 U.S. 175, 191–92 (1981)). Relying on a computer to perform routine tasks more quickly or more accurately (tasks that are tedious) is insufficient to render a claim patent eligible. See Alice, 134 S. Ct. at 2359 (“use of a computer to create electronic records, track multiple transactions, and issue simultaneous instructions” is not an inventive concept); Bancorp Servs., L.L.C. v. Sun Life Assur. Co. of Can. (U.S.), 687 F.3d 1266, 1278 (Fed. Cir. 2012) (a computer “employed only for its most basic function . . . does not impose meaningful limits on the scope of those claims”); cf. DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258–59 (Fed. Cir. 2014) (finding a computer-implemented method patent eligible where the claims recite a specific manipulation of a general-purpose computer such that the claims do not rely on a “computer network operating in its normal, expected manner”).
As such, the examiner maintains the rejection.
Conclusion
For prior art made of record and not relied upon is considered pertinent to applicant's disclosure see Notice of References Cited items A submitted 03/28/2022 used as prior art and in the conclusion section in the office action submitted 03/28/2022.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Gregory A Pollock whose telephone number is (571) 270-1465. The examiner can normally be reached M-F 8 AM - 4 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, Abhishek Vyas can be reached on 571 270-1836. 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.
/Gregory A Pollock/Primary Examiner, Art Unit 3691
01/10/2026