Notice of Pre-AIA or AIA Status
1. The present application is being examined under the pre-AIA first to invent provisions.
Continued Examination under 37 CFR §1.114
2. A request for continued examination under 37 CFR §1.114, including the fee set forth in 37 CFR §1.17(e), was filed on July 20, 2026 in this application after final rejection. Since this application is eligible for continued examination under 37 CFR §1.114 and the fee set forth in 37 CFR §1.17(e) has been timely paid, the finality of the previous Office action dated May 27, 2026 has been withdrawn pursuant to 37 CFR §1.114 and the submission filed on July 20, 2026 has been entered. Claims 10-15 are newly cancelled by applicant. Claims 1-9 and 16-21 are pending and are rejected for the reasons set forth below.
Claim Rejections - 35 USC §112
3. 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.
4. Claims 2-9 and 16-21 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.
Claim 2 recites the following limitations:
(A) wherein the storing of the revised version as the now-current version comprises to: store the now-current version in its entirety; store only differences between the now-current version and an immediately prior version… and
(B) compress previous versions of the insurance policy.
The process of "compressing" previous versions of the policy is described in Paragraph 50 of the applicant's specification. This portion of the specification states, “the system may compress previous versions of the policy to save space. By one approach, the system is configured to store the currently legally-binding policy version in its entirety, and then to store each prior version by recording only the differences between that prior version and the immediately subsequent version by model number.” This portion of the specification appears to state the process of compressing the previous versions of the insurance policy comprises storing only differences between versions of the insurance policy. Therefore, it is unclear if the “compression” process recited in limitation B is intended to refer to a different compression process, or the “compression” process recited in limitation A and described in Paragraph 50 of the applicant’s specification. However, the applicant’s specification does not appear to describe any alternate process for compressing the policy data. Therefore, for the purpose of examination, the “compression” processes described in limitation B has been interpreted as simply restating the process in limitation A. In other words, these limitations have been interpreted as referring to the same process of storing only the revisions to the policy for previous versions.
Since claims 20 and 21 have the substantially same issue as claim 2, claims 20 and 21 are rejected for the grounds and rationale used to reject claim 2. Since claims 3-9 and 16-19 include the respective limitations of claim 2, these claims are rejected for the grounds and rationale used to reject claim 2. Appropriate correction or clarification of these claims is required. No new matter may be added.
Claim Rejections - 35 USC § 101
5. 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.
6. Claims 2-9 and 16-21 are rejected under 35 U.S.C. §101 because the claimed invention recites and is directed to a judicial exception to patentability (i.e., a law of nature, a natural phenomenon, or an abstract idea) and does not include an inventive concept that is “significantly more” than the judicial exception under the January 2019 and October 2019 patentable subject matter eligibility guidance (2019 PEG) analysis which follows.
Step 1
7. 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 (claim 20), a machine (claims 2-9 and 16-19) and a manufacture (claim 21). Therefore, we proceed to step 2A, Prong 1.
Step 2A, Prong 1
8. 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.
Claim 2 recites the abstract idea of:
[[one or more processors coupled to the memory and configured to]]: in preparation to review the first version of the insurance policy, recall, [[from the memory]], the first version of the insurance policy;
generate, using the first version of the insurance policy recalled [[from the memory]], an editable version comprising a copy of the first version of the insurance policy,
wherein corresponding elements of the insurance policy in the first version and in the editable version have identical corresponding fixed identifiers; and
provide a revised version at least in part by revising the editable version using input received via [[the end-user interface]];
determine that the new corresponding effective date of the revised first policy element is earlier than the creation date of the first version and a revision date of the revised first policy element is later than the creation date of the first version; and
in response to a determination that the new corresponding effective date of the revised first policy element is earlier than the creation date of the first version and the revision date of the revised first policy element is later than the creation date of the first version: perform one or more of the following:
A) determine that a first identifier of the first policy element matches a second identifier of the revised first policy element; and in response to a determination that the first identifier of the first policy element matches the second identifier of the revised first policy element, reevaluate or reprice the revised version; and/or
B) determine that a second policy element of the plurality of policy elements is removed in the first version, wherein the removal of the second policy element occurs at an earlier date than the revised date of the revised version; and in response to a determination that the second policy element is removed in the first version, ignore changes to the second policy element in the revised version.
Here, the recited abstract idea falls within one or more of the three enumerated 2019 PEG categories of patent ineligible subject matter, to wit: certain methods of organizing human activity, which includes fundamental economic practices or principles and/or commercial interactions (e.g., insurance – here, managing insurance policy documents).
Step 2A, Prong 2
9. Under the 2019 PEG step 2A, Prong 2 analysis, the identified abstract idea to which claim 2 is directed does not include limitations or additional elements that integrate the abstract idea into a practical application.
Besides reciting the abstract idea, the limitations of claim 2 also recite generic computer components (e.g., a system comprising: an end-user interface, a memory, and one or more processors). In particular, the recited features of the abstract idea are merely 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, these additional elements are recited at a high level of generality such that they amount to no more than mere instructions to apply the exception using generic computer components. In other words, the additional elements are simply used as tools to perform the abstract idea.
Claim 2 also recites the following limitation:
a memory configured to store a first version of an insurance policy that comprises a current version of the insurance policy, wherein the first version of the insurance policy is associated with a corresponding creation date, and wherein the first version of the insurance policy comprises a plurality of policy elements each having corresponding effective dates and fixed identifiers;
store, in the memory, the revised version as a now-current version of the insurance policy along with a corresponding creation date and at least one new corresponding effective date, wherein a first policy element of the plurality of policy elements is revised to become a revised first policy element of the revised version, wherein the revised first policy element has a new corresponding effective date,
wherein the storing of the revised version as the now-current version comprises to: store the now-current version in its entirety;
store only differences between the now-current version and an immediately prior version, wherein the now-current version of the insurance policy is assigned a first version model number that is immediately subsequent to a second version model number of the immediately prior version of the insurance policy; and
compress previous versions of the insurance policy;
retain the first version of the insurance policy in the memory notwithstanding that the first version of the insurance policy is no longer presently legally effective.
These limitations merely state that the system comprises a memory which stores versions of the insurance policy and various information associated with the versions of the policy. While the claims provide significant detail regarding the type of information stored (e.g., storing only differences between revisions), the claims do not provide significant technical detail regarding how the information is stored. Therefore, such limitations amount to no more than merely storing data, which is a form of insignificant extra-solution activity (See MPEP 2016.05(d): Versata Dev. Group, Inc. v. SAP Am., Inc., 793F.3d 1306, 1334 (Fed. Cir. 2015); and OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d at 1363).
Thus, claim 2 does not include any limitations or additional elements that integrate the abstract idea into a practical application. As a result, claim 2 is directed to an abstract idea.
Step 2B
10. Under the 2019 PEG step 2B analysis, the additional elements of claim 2 are evaluated to determine whether they amount to something “significantly more” than the recited abstract idea. (i.e., an innovative concept). Here, the recited additional elements (e.g., a system comprising: an end-user interface, a memory, and one or more processors), 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 such that they are being used in the claims to simply implement the abstract idea and are not themselves being technologically improved (See e.g., MPEP 2106.05(I)(A)); (See also applicant’s Specification at least Paragraphs 39-43).
Additionally, the following limitation identified above as insignificant extra-solution activity (merely storing data) has been reevaluated under Step 2B:
a memory configured to store a first version of an insurance policy that comprises a current version of the insurance policy, wherein the first version of the insurance policy is associated with a corresponding creation date, and wherein the first version of the insurance policy comprises a plurality of policy elements each having corresponding effective dates and fixed identifiers;
store, in the memory, the revised version as a now-current version of the insurance policy along with a corresponding creation date and at least one new corresponding effective date, wherein a first policy element of the plurality of policy elements is revised to become a revised first policy element of the revised version, wherein the revised first policy element has a new corresponding effective date,
wherein the storing of the revised version as the now-current version comprises to: store the now-current version in its entirety;
store only differences between the now-current version and an immediately prior version, wherein the now-current version of the insurance policy is assigned a first version model number that is immediately subsequent to a second version model number of the immediately prior version of the insurance policy; and
compress previous versions of the insurance policy;
retain the first version of the insurance policy in the memory notwithstanding that the first version of the insurance policy is no longer presently legally effective.
As stated in MPEP 2106.05(d), a factual determination is required to support a conclusion that an additional element (or combination of additional elements) is well-understood, routine, conventional activity (Berkheimer v. HP, Inc., 881 F.3d 1360, 1368 (Fed. Cir. 2018)). In view of this requirement set forth by Berkheimer, this limitation does not integrate the abstract idea into a practical application, or amount to significantly more than the abstract idea, because the courts have found the concept of merely storing data to be well-understood, routine, and conventional activity (See MPEP 2106.05(d): Versata Dev. Group, Inc. v. SAP Am., Inc., 793F.3d 1306, 1334 (Fed. Cir. 2015); and OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d at 1363).
Thus, claim 2 does not recite any additional elements that amount to “significantly more” than the abstract idea.
Additional Independent Claims
11. Independent claims 20 and 21 are similarly rejected under 35 U.S.C. 101 for the reasons described below:
Claim 20 recites limitations that are substantially similar to those recited in claim 2. However, the primary difference between claims 20 and 2 is that claim 20 is drafted as a method rather than as a system. Similarly, as described above regarding claim 2, claim 20 recites generic computer components (e.g., a memory and an end-user interface) that are simply being used as a tool (“apply it”) to implement the abstract idea. Therefore, since the same analysis should be used for claims 2 and 20, claim 20 is not patent eligible (See Alice Corp. Pty. Ltd. V. CLS Bank Int’l, 134 S. Ct. 2347, 2354 (2014)).
Claim 21 recites limitations that are substantially similar to those recited in claim 2. However, the primary difference between claims 21 and 2 is that claim 21 is drafted as a computer-readable medium rather than as a system. Similarly, as described above regarding claim 2, claim 21 recites generic computer components (e.g., a computer program product embodied in a non-transitory computer readable medium, a memory, and an end-user interface) that are simply being used as a tool (“apply it”) to implement the abstract idea. Therefore, since the same analysis should be used for claims 1 and 14, claim 14 is not patent eligible (See Alice Corp. Pty. Ltd. V. CLS Bank Int’l, 134 S. Ct. 2347, 2354 (2014)).
Dependent Claims
12. Dependent claims 3-9 and 16-19 are also rejected under 35 U.S.C. 101 for the reasons described below:
Claims 3-5 simply provide further definition to the “policy elements” recited in claim 1. Simply stating that the policy elements are associated with various effective dates does not provide an indication of an improvement to any technology or technological field. Rather, this merely defines parameters that govern when the policy elements are effective.
Claims 6 and 7 simply refine the abstract idea because they recite process steps (e.g., detecting conflicts between policy versions by matching up changes to policy elements with a fixed identifier) that fall under the category of organizing human activity, as described above regarding claim 1.
Claim 8 simply provides further definition to the process of storing insurance policy recited in claim 1. Simply stating that the policy is stored in a read-only format does not provide an indication of an improvement to any technology or technological field. Rather, this merely defines the format in which the insurance policy is stored.
Claim 16 simply states that the system “compresses” the previous versions of the insurance policy by storing the now-current version of the policy in its entirety, and storing each prior version at least in part by recording differences between a given previous version and an immediately subsequent version. However, these limitations do not provide significant technical detail regarding how the previous versions are compressed. Simply stating that compressing the previous versions includes recording the differences between immediately subsequent versions does not amount to a technical improvement in data storage and management. Rather, this amount to no more than merely storing data associated with the various versions of the insurance policy. Therefore, such limitations amount to no more than merely storing data, which is a form of insignificant extra-solution activity (See MPEP 2016.05(d): Versata Dev. Group, Inc. v. SAP Am., Inc., 793F.3d 1306, 1334 (Fed. Cir. 2015); and OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d at 1363). In view of the requirement set forth by Berkheimer, this limitation does not integrate the abstract idea into a practical application, or amount to significantly more than the abstract idea, because the courts have found the concept of merely storing data to be well-understood, routine, and conventional activity (See MPEP 2106.05(d): Versata Dev. Group, Inc. v. SAP Am., Inc., 793F.3d 1306, 1334 (Fed. Cir. 2015); and OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d at 1363).
Claim 17 simply provides further definition to the “immediately subsequent version of the insurance policy” recited in claim 16. Simply stating that the immediately subsequent version is immediately subsequent by model number does not provide an indication of an improvement to any technology or technological field. Rather, this merely defines how the model numbers relate to the various versions of the insurance policy.
Claims 18 and 19 simply refine the abstract idea because they recite process steps (e.g., reconstructing the insurance policy by applying changes from subsequent versions of the insurance policy) that fall under the category of organizing human activity, as described above regarding claim 1.
Thus, the dependent claims do not add any additional element or subject matter that provides a technological improvement (i.e., an integration into a practical application) that results in the claims being directed to patent eligible subject matter or include an element or feature that is significantly more than the recited abstract idea (i.e., a technological inventive concept under Step 2B).
Claim Rejections - 35 USC § 102
13. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of pre-AIA 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 –
(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on sale in this country, more than one year prior to the date of application for patent in the United States.
14. Claims 2-7, 9, and 16-21 are rejected under pre-AIA 35 U.S.C. 102(b) as being anticipated by Heydon (U.S. Pre-Grant Publication No. 20070255601).
Claim 2
Regarding claim 2, Heydon teaches:
A system, comprising: an end-user interface configured to facilitate revisioning of insurance policies (See at least Paragraphs 68 and 69: Describes a system for insurance policy revisioning. The system comprises a user interface for receiving instructions from the user);
a memory configured to store a first version of an insurance policy that comprises a current version of the insurance policy, wherein the first version of the insurance policy is associated with a corresponding creation date (See at least Paragraphs 26 and 68: The system may comprise a first memory that stores data that defines an insurance policy as a plurality of discrete temporally-sequential policy data revisions. The creation of the policy may be associated with a “submission data” [i.e., a creation data; See Paragraph 31 and Figure 4]), and
wherein the first version of the insurance policy comprises a plurality of policy elements each having corresponding effective dates and fixed identifiers (See at least Paragraph 39: The policy may be associated with a plurality of “policy revisions” comprising a plurality of “policy revision elements” each having a corresponding RIID [i.e., fixed identifier]. The policy revisions associated with the policy revisions may have an associated effective date range [See Paragraph 36]); and
one or more processors coupled to the memory and configured to: in preparation to review the first version of the insurance policy, recall, from the memory, the first version of the insurance policy (See at least Paragraph 33: When a policy data revision is created, the system looks up a most recent legally binding revision as of the effective date of the of the policy. Each revision is stored within the memory [See Paragraph 68]);
generate, using the first version of the insurance policy recalled from the memory, an editable version comprising a copy of the first version of the insurance policy (See at least Paragraph 33: The draft new revision [i.e., an editable version of the policy] is initialized to be a copy of the most temporally recent legally binding revision [i.e., the first version of the policy]),
wherein corresponding elements of the insurance policy in the first version and in the editable version have identical corresponding fixed identifiers (See at least Paragraph 39: Each unique RIID assigned to the policy revision elements remains the same across revisions of the same policy);
provide a revised version at least in part by revising the editable version using input received via the end-user interface (See at least Paragraphs 33 and 34: The system may create a new revision based on changes made to the most temporally recent legally binding revision [Also See Paragraph 24]. A user interface may be used to receive instructions from the user [See Paragraph 69]);
store, in the memory, the revised version as a now-current version of the insurance policy along with a corresponding creation date and at least one new corresponding effective date, wherein a first policy element of the plurality of policy elements is revised to become a revised first policy element of the revised version, wherein the revised first policy element has a new corresponding effective date (See at least Paragraph 61: Each policy data revision is stored with a corresponding change data [i.e., creation date] and a corresponding legally effective date [i.e., effective date]. The change dates and the legally effective dates can then be used to facilitate determination of a present liability. In other words, the dates associated with the revisions may be used to determine the "now-current" version of the insurance policy. A revision of the policy is represented by a revision of the policy elements [See Paragraphs 39 and 40]. In other words, the revision of the policy applies a new "effective date" to the revised policy elements);
wherein the storing of the revised version as the now-current version comprises to: store the now-current version in its entirety (See at least Paragraph 68: The system stores each insurance policy as a plurality of discrete temporally-sequential policy data revisions, wherein each revision incorporates information from temporally prior revisions covering an effective date range of the revision. In other words, the system stores, within the computer memory, a version of the insurance policy that incorporates each revision made to the policy [i.e., the current policy in its entirety]);
store only differences between the now-current version and an immediately prior version (See at least Paragraphs 58 and 59: The system may store each revision in terms of the changes [i.e., delta] made in each revision. These changes may be stored and represented in a table, as showed in Figure 11),
wherein the now-current version of the insurance policy is assigned a first version model number that is immediately subsequent to a second version model number of the immediately prior version of the insurance policy (See at least Paragraphs 31-33: The most recent revision is assigned a letter [i.e., model number] that is "highest." For example, the most recent version in a series of four revisions to a policy is assigned the letter "D." When a new policy data revision is created, the user specifies an effective date for the change. This effective date is used to look up the temporally most recent legally binding revision as of that effective date as described above. This legally binding revision is used as the basis for the new revision. In other words, the most recent revision [e.g., the revision labeled "D" in the example provided above] is recalled based on having the "highest" label value when generating new revisions); and
compress previous versions of the insurance policy (See at least Paragraphs 58 and 59: The system may store each revision in terms of the changes [i.e., delta] made in each revision. These changes may be stored and represented in a table, as showed in Figure 11. Examiner's Note: The process of "compressing" previous versions of the policy is described in Paragraph 50 of the applicant's specification. This portion of the specification states that the process of compression the versions of the policy may include recording only the differences between that prior version and the immediately subsequent version by model number. Therefore, this limitation has been interpreted based on this example provided in the specification);
determine that the new corresponding effective date of the revised first policy element is earlier than the creation date of the first version and a revision date of the revised first policy element is later than the creation date of the first version (See at least Paragraphs 35 and 36: This portion of Heydon, in association with Figure 4, describes a process for managing out-of-sequence endorsements. An out-of-sequence endorsement is defined as an endorsement [which comprises a change to an existing policy] that has a change date that is temporally subsequent to an existing revision but has an effective date that legally precedes that existing revision [See Paragraph 4]. In other words, the system may identify out-of-sequence endorsements, and attempt to remedy any conflicts associated with such endorsements [Also see Paragraphs 43-45]); and
in response to a determination that the new corresponding effective date of the revised first policy element is earlier than the creation date of the first version and the revision date of the revised first policy element is later than the creation date of the first version: perform one or more of the following: A) determine that a first identifier of the first policy element matches a second identifier of the revised first policy element; and in response to a determination that the first identifier of the first policy element matches the second identifier of the revised first policy element, reevaluate or reprice the revised version; and/or B) determine that a second policy element of the plurality of policy elements is removed in the first version, wherein the removal of the second policy element occurs at an earlier date than the revised date of the revised version; and in response to a determination that the second policy element is removed in the first version, ignore changes to the second policy element in the revised version (See at least Paragraphs 43-45: The system may detect "merge conflicts" between policy revisions. For example, an element removed in one revision may have had one of its fields modified in another revision. In this case, the outright removal of the element trumps the field change. In other words, if a policy element has already been removed in a prior revision, any changes made to the policy element in subsequent revisions may be ignored); and
retain the first version of the insurance policy in the memory notwithstanding that the first version of the insurance policy is no longer presently legally effective (See at least Paragraphs 62 and 68: Each revision is stored in the memory regardless of whether that revision is currently effective. As stated in Paragraph 62, the user may view the effective policy at any prior date).
Claim 3
Regarding claim 3, Heydon teaches:
wherein the corresponding effective dates comprise a master effective data that is applicable across the plurality of policy elements (See at least Paragraph 31: The insurance policy may comprise an effective date corresponding to the submission of the newly created policy [i.e., a master effective date]. In other words, the initial effective date of the newly created policy applies to all subsequent revisions to the policy).
Claim 4
Regarding claim 4, Heydon teaches:
wherein different policy elements are associated with different corresponding effective dates (See at least Paragraph 33: The policy elements may be associated with effective dates for the changes they represent).
Claim 5
Regarding claim 5, Heydon teaches:
wherein a policy element comprises a start effective date and an end effective date, wherein the start effective date and the end effective date indicate a date range over which the policy element is effective (See at least Paragraph 30: Each revision may be effective between a range of dates. For example, the revision may be effective starting at the revision effective date and end at the policy period expiration date).
Claim 6
Regarding claim 6, Heydon teaches:
wherein the one or more processors are further configured to detect conflicts based at least in part on the fixed identifiers (See at least Paragraphs 43 and 44: The system may detect “merge conflicts” which occur if the same field was changed to two different values in two different revisions. Conflicts are determined based on changes to elements with the same RIID [i.e., fixed identifiers]).
Claim 7
Regarding claim 7, Heydon teaches:
wherein detecting a conflict comprises comparing differences between two policy versions at least in part by matching up changes to elements with a same fixed identifier (See at least Paragraph 44: Merge conflicts are detected by comparing the differences to the changes that were made to produce the bound revision with the later effective date. Any merge conflicts are detected by comparing the differences to the differences collected by matching up changes to elements with the same RIID).
Claim 9
Regarding claim 9, Heydon teaches:
wherein the one or more processors are further configured to track insurance policy versions (See at least Paragraph 25: The system allows insurance providers to readily track insurance policy revisions [i.e., versions] and accurately process claims based on the effective dates and change dates of the revisions).
Claim 16
Regarding claim 16, Heydon teaches:
wherein the compressing comprises: storing the now-current version of the insurance policy in its entirety (See at least Paragraph 68: The system stores each insurance policy as a plurality of discrete temporally-sequential policy data revisions, wherein each revision incorporates information from temporally prior revisions covering an effective date range of the revision. In other words, the system stores, within the computer memory, a version of the insurance policy that incorporates each revision made to the policy [i.e., the current policy in its entirety]); and
storing each prior version at least in part by recording differences between a given previous version and an immediately subsequent version (See at least Paragraphs 58 and 59: The system may store each revision in terms of the changes [i.e., delta] made in each revision [Also See Figure 11]).
Claim 17
Regarding claim 17, Heydon teaches:
wherein the immediately subsequent version is immediately subsequent by model number (See at least Paragraph 31: The label for the revision is based on when the revision was created. For example, A represents a submission of a newly created policy, and B, C, and D represent policy changes [Also See Figure 4]. In other words, the revision labelled “B” is immediately subsequent to the revision labeled “C”).
Claim 18
Regarding claim 18, Heydon teaches:
wherein the one or more processors are further configured to reconstruct a prior version of the insurance policy (See at least Paragraphs 61 and 62: Querying in terms of the change date allows a user to ask what versions existed when looking at the history of the policy from some earlier date. Therefore, a carrier can determine what an insurance policy looked like on an effective date X based on the history at an earlier date Y. In other words, the prior version of the model can be “reconstructed” based on the18ffecttive terms at an earlier date).
Claim 19
Regarding claim 19, Heydon teaches:
wherein reconstructing the prior version of the insurance policy comprises successively applying changes from a subsequent version (See at least Paragraphs 61 and 62: Querying in terms of the change date allows a user to ask what versions existed when looking at the history of the policy from some earlier date. Therefore, a carrier can determine what an insurance policy looked like on an effective date X based on the history at an earlier date Y. In other words, the prior version of the model can be “reconstructed” by applying changes from each subsequent revision of the policy).
Claim 20
Regarding claim 20, Heydon teaches:
A method, comprising: in preparation to review a first version of an insurance policy, recalling, from a memory, the first version of the insurance policy (See at least Paragraph 33: Describes a system for insurance policy revisioning. When a policy data revision is created, the system looks up a most recent legally binding revision as of the effective date of the of the policy. Each revision is stored within the memory [See Paragraph 68]),
wherein the first version of the insurance policy stored in the memory comprises a current version of the insurance policy, wherein the first version of the insurance policy is associated with a corresponding creation date (See at least Paragraphs 26 and 68: The system may comprise a first memory that stores data that defines an insurance policy as a plurality of discrete temporally-sequential policy data revisions. The creation of the policy may be associated with a “submission data” [i.e., a creation data; See Paragraph 31 and Figure 4]), and
wherein the first version of the insurance policy comprises a plurality of policy elements each having corresponding effective dates and fixed identifiers (See at least Paragraph 39: The policy may be associated with a plurality of “policy revisions” comprising a plurality of “policy revision elements” each having a corresponding RIID [i.e., fixed identifier]. The policy revisions associated with the policy revisions may have an associated effective date range [See Paragraph 36]);
generating, using the first version of the insurance policy recalled from the memory, an editable version comprising a copy of the first version of the insurance policy (See at least Paragraph 33: The draft new revision [i.e., an editable version of the policy] is initialized to be a copy of the most temporally recent legally binding revision [i.e., the first version of the policy]),
wherein corresponding elements of the insurance policy in the first version and in the editable version have identical corresponding fixed identifiers (See at least Paragraph 39: Each unique RIID assigned to the policy revision elements remains the same across revisions of the same policy);
providing a revised version at least in part by revising the editable version using input received via an end-user interface that facilitates revisioning of insurance policies (See at least Paragraphs 33 and 34: The system may create a new revision based on changes made to the most temporally recent legally binding revision [Also See Paragraph 24]. A user interface may be used to receive instructions from the user [See Paragraph 69]);
storing, in the memory, the revised version as a now-current version of the insurance policy along with a corresponding creation date and at least one new corresponding effective date, wherein a first policy element of the plurality of policy elements is revised to become a revised first policy element of the revised version, wherein the revised first policy element has a new corresponding effective date (See at least Paragraph 61: Each policy data revision is stored with a corresponding change data [i.e., creation date] and a corresponding legally effective date [i.e., effective date]. The change dates and the legally effective dates can then be used to facilitate determination of a present liability. In other words, the dates associated with the revisions may be used to determine the "now-current" version of the insurance policy. A revision of the policy is represented by a revision of the policy elements [See Paragraphs 39 and 40]. In other words, the revision of the policy applies a new "effective date" to the revised policy elements);
wherein the storing of the revised version as the now-current version comprises: storing the now-current version in its entirety (See at least Paragraph 68: The system stores each insurance policy as a plurality of discrete temporally-sequential policy data revisions, wherein each revision incorporates information from temporally prior revisions covering an effective date range of the revision. In other words, the system stores, within the computer memory, a version of the insurance policy that incorporates each revision made to the policy [i.e., the current policy in its entirety]);
storing only differences between the now-current version and an immediately prior version (See at least Paragraphs 58 and 59: The system may store each revision in terms of the changes [i.e., delta] made in each revision. These changes may be stored and represented in a table, as showed in Figure 11),
wherein the now-current version of the insurance policy is assigned a first version model number that is immediately subsequent to a second version model number of the immediately prior version of the insurance policy (See at least Paragraphs 31-33: The most recent revision is assigned a letter [i.e., model number] that is "highest." For example, the most recent version in a series of four revisions to a policy is assigned the letter "D." When a new policy data revision is created, the user specifies an effective date for the change. This effective date is used to look up the temporally most recent legally binding revision as of that effective date as described above. This legally binding revision is used as the basis for the new revision. In other words, the most recent revision [e.g., the revision labeled "D" in the example provided above] is recalled based on having the "highest" label value when generating new revisions); and
compressing previous versions of the insurance policy (See at least Paragraphs 58 and 59: The system may store each revision in terms of the changes [i.e., delta] made in each revision. These changes may be stored and represented in a table, as showed in Figure 11. Examiner's Note: The process of "compressing" previous versions of the policy is described in Paragraph 50 of the applicant's specification. This portion of the specification states that the process of compression the versions of the policy may include recording only the differences between that prior version and the immediately subsequent version by model number. Therefore, this limitation has been interpreted based on this example provided in the specification);
determining that the new corresponding effective date of the revised first policy element is earlier than the creation date of the first version and a revision date of the revised first policy element is later than the creation date of the first version (See at least Paragraphs 35 and 36: This portion of Heydon, in association with Figure 4, describes a process for managing out-of-sequence endorsements. An out-of-sequence endorsement is defined as an endorsement [which comprises a change to an existing policy] that has a change date that is temporally subsequent to an existing revision but has an effective date that legally precedes that existing revision [See Paragraph 4]. In other words, the system may identify out-of-sequence endorsements, and attempt to remedy any conflicts associated with such endorsements [Also see Paragraphs 43-45]); and
in response to a determination that the new corresponding effective date of the revised first policy element is earlier than the creation date of the first version and the revision date of the revised first policy element is later than the creation date of the first version: perform one or more of the following: A) determining that a first identifier of the first policy element matches a second identifier of the revised first policy element; and in response to a determination that the first identifier of the first policy element matches the second identifier of the revised first policy element, reevaluating or repricing the revised version; and/or B) determining that a second policy element of the plurality of policy elements is removed in the first version, wherein the removal of the second policy element occurs at an earlier date than the revised date of the revised version; and in response to a determination that the second policy element is removed in the first version, ignoring changes to the second policy element in the revised version (See at least Paragraphs 43-45: The system may detect "merge conflicts" between policy revisions. For example, an element removed in one revision may have had one of its fields modified in another revision. In this case, the outright removal of the element trumps the field change. In other words, if a policy element has already been removed in a prior revision, any changes made to the policy element in subsequent revisions may be ignored); and
retaining the first version of the insurance policy in the memory notwithstanding that the first version of the insurance policy is no longer presently legally effective (See at least Paragraphs 62 and 68: Each revision is stored in the memory regardless of whether that revision is currently effective. As stated in Paragraph 62, the user may view the effective policy at any prior date).
Claim 21
Regarding claim 21, Heydon teaches:
A computer program product embodied in a non-transitory computer readable medium and comprising computer instructions for (See at least Paragraph 68: Describes a system for insurance policy revisioning. The system comprises a second computer memory storing programmed instructions):
in preparation to review a first version of an insurance policy, recalling, from a memory, the first version of the insurance policy (See at least Paragraph 33: When a policy data revision is created, the system looks up a most recent legally binding revision as of the effective date of the of the policy. Each revision is stored within the memory [See Paragraph 68]),
wherein the first version of the insurance policy stored in the memory comprises a current version of the insurance policy, wherein the first version of the insurance policy is associated with a corresponding creation date (See at least Paragraphs 26 and 68: The system may comprise a first memory that stores data that defines an insurance policy as a plurality of discrete temporally-sequential policy data revisions. The creation of the policy may be associated with a “submission data” [i.e., a creation data; See Paragraph 31 and Figure 4]), and
wherein the first version of the insurance policy comprises a plurality of policy elements each having corresponding effective dates and fixed identifiers (See at least Paragraph 39: The policy may be associated with a plurality of “policy revisions” comprising a plurality of “policy revision elements” each having a corresponding RIID [i.e., fixed identifier]. The policy revisions associated with the policy revisions may have an associated effective date range [See Paragraph 36]);
generating, using the first version of the insurance policy recalled from the memory, an editable version comprising a copy of the first version of the insurance policy (See at least Paragraph 33: The draft new revision [i.e., an editable version of the policy] is initialized to be a copy of the most temporally recent legally binding revision [i.e., the first version of the policy]),
wherein corresponding elements of the insurance policy in the first version and in the editable version have identical corresponding fixed identifiers (See at least Paragraph 39: Each unique RIID assigned to the policy revision elements remains the same across revisions of the same policy);
providing a revised version at least in part by revising the editable version using input received via an end-user interface that facilitates revisioning of insurance policies (See at least Paragraphs 33 and 34: The system may create a new revision based on changes made to the most temporally recent legally binding revision [Also See Paragraph 24]. A user interface may be used to receive instructions from the user [See Paragraph 69]);
storing, in the memory, the revised version as a now-current version of the insurance policy along with a corresponding creation date and at least one new corresponding effective date, wherein a first policy element of the plurality of policy elements is revised to become a revised first policy element of the revised version, wherein the revised first policy element has a new corresponding effective date (See at least Paragraph 61: Each policy data revision is stored with a corresponding change data [i.e., creation date] and a corresponding legally effective date [i.e., effective date]. The change dates and the legally effective dates can then be used to facilitate determination of a present liability. In other words, the dates associated with the revisions may be used to determine the "now-current" version of the insurance policy. A revision of the policy is represented by a revision of the policy elements [See Paragraphs 39 and 40]. In other words, the revision of the policy applies a new "effective date" to the revised policy elements);
wherein the storing of the revised version as the now-current version comprises: storing the now-current version in its entirety (See at least Paragraph 68: The system stores each insurance policy as a plurality of discrete temporally-sequential policy data revisions, wherein each revision incorporates information from temporally prior revisions covering an effective date range of the revision. In other words, the system stores, within the computer memory, a version of the insurance policy that incorporates each revision made to the policy [i.e., the current policy in its entirety]);
storing only differences between the now-current version and an immediately prior version (See at least Paragraphs 58 and 59: The system may store each revision in terms of the changes [i.e., delta] made in each revision. These changes may be stored and represented in a table, as showed in Figure 11),
wherein the now-current version of the insurance policy is assigned a first version model number that is immediately subsequent to a second version model number of the immediately prior version of the insurance policy (See at least Paragraphs 31-33: The most recent revision is assigned a letter [i.e., model number] that is "highest." For example, the most recent version in a series of four revisions to a policy is assigned the letter "D." When a new policy data revision is created, the user specifies an effective date for the change. This effective date is used to look up the temporally most recent legally binding revision as of that effective date as described above. This legally binding revision is used as the basis for the new revision. In other words, the most recent revision [e.g., the revision labeled "D" in the example provided above] is recalled based on having the "highest" label value when generating new revisions); and
compressing previous versions of the insurance policy (See at least Paragraphs 58 and 59: The system may store each revision in terms of the changes [i.e., delta] made in each revision. These changes may be stored and represented in a table, as showed in Figure 11. Examiner's Note: The process of "compressing" previous versions of the policy is described in Paragraph 50 of the applicant's specification. This portion of the specification states that the process of compression the versions of the policy may include recording only the differences between that prior version and the immediately subsequent version by model number. Therefore, this limitation has been interpreted based on this example provided in the specification);
determining that the new corresponding effective date of the revised first policy element is earlier than the creation date of the first version and a revision date of the revised first policy element is later than the creation date of the first version (See at least Paragraphs 35 and 36: This portion of Heydon, in association with Figure 4, describes a process for managing out-of-sequence endorsements. An out-of-sequence endorsement is defined as an endorsement [which comprises a change to an existing policy] that has a change date that is temporally subsequent to an existing revision but has an effective date that legally precedes that existing revision [See Paragraph 4]. In other words, the system may identify out-of-sequence endorsements, and attempt to remedy any conflicts associated with such endorsements [Also see Paragraphs 43-45]); and
in response to a determination that the new corresponding effective date of the revised first policy element is earlier than the creation date of the first version and the revision date of the revised first policy element is later than the creation date of the first version: perform one or more of the following: A) determining that a first identifier of the first policy element matches a second identifier of the revised first policy element; and in response to a determination that the first identifier of the first policy element matches the second identifier of the revised first policy element, reevaluating or repricing the revised version; and/or B) determining that a second policy element of the plurality of policy elements is removed in the first version, wherein the removal of the second policy element occurs at an earlier date than the revised date of the revised version; and in response to a determination that the second policy element is removed in the first version, ignoring changes to the second policy element in the revised version (See at least Paragraphs 43-45: The system may detect "merge conflicts" between policy revisions. For example, an element removed in one revision may have had one of its fields modified in another revision. In this case, the outright removal of the element trumps the field change. In other words, if a policy element has already been removed in a prior revision, any changes made to the policy element in subsequent revisions may be ignored); and
retaining the first version of the insurance policy in the memory notwithstanding that the first version of the insurance policy is no longer presently legally effective (See at least Paragraphs 62 and 68: Each revision is stored in the memory regardless of whether that revision is currently effective. As stated in Paragraph 62, the user may view the effective policy at any prior date).
Claim Rejections – 35 USC § 103
15. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
16. Claim 8 is rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Heydon (U.S. Pre-Grant Publication No. 20070255601) in view of Barrett (U.S. Pre-Grant Publication No. 20080154646).
Claim 8
Regarding claim 8, Heydon does not explicitly teach, but Walker, however, does teach:
wherein the first version of the insurance policy is stored in the memory in a read-only format (See at least Paragraph 26: Describes a system for storing information related to a patient, such as insurance billing information. The patient information may be stored in a read-only format).
Therefore, it would have been obvious to one of ordinary skill in the art, at the time of the invention, to combine the teachings of Heydon and Barrett in order to ensures data integrity and accuracy of the information in the system (Barrett: Paragraph 26).
Response to Arguments
17. Applicant’s arguments filed July 20, 2026 have been fully considered.
Arguments Regarding 35 U.S.C. 101
18. Applicant’s arguments (Amendment, Pg. 10) concerning the prior rejection of the claims under 35 USC §101, including supposed deficiencies in the rejection, are not persuasive for the following reasons. Under the prior and current 101 analysis under 2019 PEG, the amended claims recite and are directed to a patent ineligible abstract idea, without something significantly more, for the reasons given above after consideration of the claimed features and elements. The abstract idea has been restated herein in line with the 2019 PEG guidance and the amended claims. Applicant is directed to the above full Alice/Mayo analysis in the 101 rejection.
Additionally, on page 10 of their remarks, the applicant argues, “Claims 2, 20, and 21 have been amended in a manner that is believed to overcome the rejection under 35 U.S.C. §101.” The examiner respectfully disagrees. As noted in the updated 101 rejection above, the claims do not recite any limitation, or combination of limitations, that integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Therefore, for these reasons and the reasons given above, the rejection of these claims under 35 U.S.C. §101 is maintained.
Arguments Regarding 35 U.S.C. 102/103
19. Applicant’s arguments concerning the prior art rejection of the claims under 35 USC §102/103, including supposed deficiencies in the prior art references regarding the amended claims, are not persuasive. Applicant is directed to the discussion of the references of record above in view of the amended claims and the prior art rejections pertaining thereto.
Additionally, on pages 10 and 11 of their remarks, the applicant argues, “As discussed during the interview, the applied references fail to teach or render obvious...” The examiner respectfully disagrees. As noted in the updated rejection above, Heydon does teach these limitations. The applicant is directed to the 102 rejection above for further detail regarding the relevant portions of Heydon.
Therefore, for at least these reasons the rejection of the claims under 35 U.S.C. 102/103 has been maintained. However, the rejection has been updated to address the newly added claim limitations.
Citation of Pertinent Prior Art
20. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Serio (U.S. Pre-Grant Publication No. 20100004952): Describes a system and method of tracking, monitoring and reporting status of a title insurance policy, and in particular a system and method for tracking and correlating property-related activities related to the termination and/or extinguishment of a title insurance policy.
Chatlain (U.S. Patent No. 7877303): Describes systems and processes for proposing, tracking, and converting split-dollar and jointly-owned life insurance policies.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM D NEWLON whose telephone number is (571)272-4407. The examiner can normally be reached Mon - Fri 8:30 - 4:30.
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 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.
/WILLIAM D NEWLON/Examiner, Art Unit 3696
/MATTHEW S GART/Supervisory Patent Examiner, Art Unit 3696
Prosecution Insights