DETAILED ACTION
Notice of Pre-AIA or AIA Status
This is a non-final Office action in response to communications received on 11/07/2024. Claims 1 through 20 are presented for examination. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
No foreign priority or provisional date is recognized.
Drawings
The drawings filed on 07/31/2024 are acknowledged.
Objection to Specification
The abstract of the disclosure is objected to because of the language. The proper language and format for an abstract should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 7, 9, 17 and 19 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 applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 7 and 17 are rejected as indefinite because there is insufficient antecedent basis for the claim limitation “the smart contract”. No smart contract has been introduced in these claims or the parent claims from which they depend. Appropriate clarification/correction is required.
Claims 9 and 19 are rejected as indefinite because there is insufficient antecedent basis for the claim limitations “the smart contract” and “the computer-executable instructions”. Appropriate clarification/correction is required.
Claim Rejections - 35 USC § 103
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 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 2, 5, 7-9, 11, 12, 15, and 17-29 are rejected under U.S.C 103 as being unpatentable over Strauss (US 11790459B1) in view of Lieginger (US 20250117860A1).
Regarding claim 1, Strauss teaches the limitations of claim 1 as follows:
A computing system for applying zero knowledge proof in predictive analytics, the computing system comprising: (Strauss col. 17, lines 20-24, col. 19, lines 12-17, col. 21, lines 23-26 system that applies zero knowledge sets (i.e. zero knowledge-proof)) and predictive trendlines (i.e. predictive analytics) for future data)
a processor; (Strauss col. 2, lines 31-39: included at least one processor (i.e. processor)
memory storing computer-executable instructions that, when executed by the processor, cause the processor to: (Strauss col. 2, lines 31-39, col. 5, lines 49-52, col. 11, lines 12-14: a memory containing instructions (i.e. memory storing computer-executable instructions) configuring the processor to (i.e. executed by the processor) receive and categorize a ledger file);
receive a request for a policy for a user, the request including an identifier associated with the user; (Strauss col. 4, lines 64-67, col. 5, lines 1-5, col. 5, lines 64-67, col.6, lines 1-2, & 37-44, col. 21, lines 23-30): receiving edits or a query from a user (i.e. request) for ledger information, wherein the ledger information includes user insurance policy data (i.e. policy for a user) and the query includes specific properties to be matched against membership information (i.e. identifiers associated with users/members) stored in the immutable sequential listing associated with insurance ledger files)
generate an automated program in a first block of a blockchain, the automated program corresponding to the request and defining an execution condition; (Strauss col. 5, lines 13-16 & 35-46, co. 6, lines 37-44 & 52-57, col. 19, lines 4-20, col. 21, lines 23-30 & 35-42, col. 25, lines 39-52: using machine learning to generate & classify ledger data and automatedly generating an algorithm (i.e. automate program) to be performed by device storing ledger files to an immutable sequential listing (i.e. block of a blockchain), that may be implemented as a blockchain based on a determining matches (i.e. defining an execution condition), wherein processing of the ledger data and storing the ledger data in the blockchain occurs in relation to the user updating the ledger data and querying the ledger data (i.e. corresponding to requests))
cause the automated program to acquire based on the identifier (Strauss col. 4, lines 64-67, col. 5, lines 1-5; col. 21, lines 23-30: the immutable program ledger acquires a query or user edits based upon the specific properties identifying a user member (i.e. identifier) included in the query)
execute, the automated program in the first block (Strauss col. 5, lines 13-16 & 35-46, col. 6, lines 37-44 & 52-57, col. 19, lines 4-20, col. 21, lines 35-42: implemented as a blockchain, where sub-listings are blocks (i.e. first block) and where ledger files stored in the immutable sequential listing are processed by the processor (i.e. executed))
store in a second block of the blockchain; and (Strauss col. 5, lines 13-16 & 35-46, col. 16, lines 53-60, col.18, lines 26-40; col. 19, lines 4-20: storing ledger files and elements of ledger data into immutable sequential listing (i.e. second block) entries / blocks (i.e. blockchain))
attach the second block to the first block. (Strauss col. 5, lines 13-16 & 35-46, col. 18, lines 30-33, col. 19, lines 4-20, col. 21, lines 32-38: blocks are placed (i.e. attached) in chronological and sequential order (i.e. second block to the first block) and linked)
Strauss does not explicitly disclose the remaining part of the limitation as follows:
cause the automated program to acquire from a data source, using a protocol, a fact indicative of the execution condition being satisfied;
based on the fact, generate the policy for the user;
the policy for the user
However, in the same field of endeavor, Lieginger discloses the remaining limitations of claim 1 as follows:
cause the automated program to acquire from a data source, using a protocol, a fact indicative of the execution condition being satisfied; (Lieginger paras [0054], [0067], [0080]- [0081], [0096]: automatically generating underwriting assessment scores, rating class determinations, and factor values (i.e. fact indicative) and determine if they satisfy criteria to produce a decision (i.e. condition being satisfied) based off obtaining data representing inputs from multiple data sources (i.e. data source), and pass the data via an API (i.e. using a protocol))
based on the fact, generate the policy for the user; (Lieginger paras [0066], [0096]- [0098]: based on an underwriting assessment score and determination (i.e. based on the fact), confirm a class decision of binding the policy and issuing a policy number for a user (i.e. generate the policy for the user))
the policy for the user (Lieginger paras [0097]- [0098]: binding the policy and issuing a policy number for a user (i.e. policy for the user))
Lieginger is combinable with Strauss because both are from the same the same field of endeavor of storing data in blockchains and employing computer-implemented insurance analytics systems for processing data to evaluate, predict, and support policy determinations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to integrate Lieginger’s method of obtaining data and generating policies based off facts and satisfying conditions with Strauss in order to improve data integrity, and accurate responsiveness for policy generation, and enables auditability in automated life insurance platforms.
Regarding claims 2 and 12, Strauss and Lieginger disclose the limitations of the system of claim 1, and the method of claim 11.
Strauss and Lieginger teach the limitations of claims 2 and 12 as follows:
wherein the automated program is configured to be automatically executed in the first block (Strauss col. 5, lines 13-16, col. 19, lines 4-20, col. 21, lines 35-42, col. 25, lines 39-52, col. 30, lines 22-26: automatedly generating (i.e. generated to be automatically executed) an algorithm (i.e. automated program) to be performed by device storing ledger files to an immutable sequential listing (i.e. first block), that may be based on a determination matching (i.e. execution condition)) upon the execution condition being satisfied (Lieginger paras [0066], [0096]- [0098]: determine if factors satisfy criteria to produce a decision (i.e. condition being satisfied)
The same motivation to combine utilized in claim 1 is equally applicable in the instant claim.
Regarding claims 5 and 15, Strauss and Lieginger disclose the limitations of the system of claim 1, and the method of claim 11.
Lieginger teaches the limitations of claims 5 and 15 as follows:
wherein the execution condition includes an average daily number of steps taken by the user being equal to or greater than a threshold number of steps. (Lieginger paras [0082], [0087], [0090]: determining an average daily step count (i.e. average daily number of steps) and evaluating the average steps per day by comparing (i.e. being equal to or greater than) the average step count against predefined ranges (i.e. a threshold number of steps)
It would have been obvious to one of ordinary skill in the art at before the effective filing date of the claimed invention to integrate Lieginger’s physical activity thresholds with Strauss in order to ensure that automated actions are personalized, safe, and effective for optimizing policies for users.
Regarding claims 7 and 17, Strauss and Lieginger disclose the limitations of the system of claim 1, and the method of claim 11.
Strauss and Lieginger teach the limitations of claims 7 and 17 as follows:
wherein the computer-executable instructions that, when executed by the processor, further cause the processor to:
receive inputs indicative of adding a second execution condition to the smart contract (Strauss, col. 6, lines 37-45, col. 19, lines 4-20: receiving updates input by a user which trigger updating of the ledger information and storing the updated ledger information that matches to be processed as new blocks of the immutable sequential listing (i.e. adding new execution conditions to smart contract) (see also Lieginger paras [0048], [0058], [0067], [0077] fig. 2, fig. 4: receiving inputs of multiple factors (i.e. receive inputs) and weightings to drive underwriting decisions (i.e. indicative of adding) for additional determinations (i.e. adding a second execution condition))
cause the automated program to acquire from a second data source, using the protocol and based on the identifier, a second fact indicative of the second execution condition being satisfied; (Lieginger paras [0067], [0080]- [0081], [0096]: automatically generating underwriting assessment scores, rating class determinations, and factor values (i.e. second fact indicative) and determine if they satisfy criteria to produce a decision (i.e. second execution condition being satisfied) based off obtaining data representing inputs from multiple data sources (i.e. second data source), and pass the data via an API (i.e. using a protocol))
update, based on the second fact, the policy (Strauss, col. 4, lines 64-67, col. 5, lines 1-5, col.6, lines 1-2 & 37-44: user updates ledger information, including policy information) (see also Lieginger paras [0059]- [0060]: periodically adjusting (i.e. update) associated with underwriting assessment scores and determinations (i.e. second fact) the monthly insurance premium of a policy (i.e. monthly premium of the policy)) by executing the automated program in the first block; (Strauss col. 5, liens 13-16, col. 21, lines 35-42, col. 30, lines 22-26: implemented as a blockchain, where sub-listings are blocks (i.e. first block) and where ledger files stored in the immutable sequential listing are processed by the processor (i.e. executed))
and update the second block, associated with the policy (Lieginger paras [0097]- [0098]: binding the policy and issuing a policy number for a user (i.e. the policy)) in the blockchain. (Strauss col. 4, lines 64-67, col. 5, lines 1-5, col.6, lines 1-2 & 37-44, col. 16, lines 53-60, col.18, lines 26-40: in response to user updates, automatically updating ledger information including policy information in the ledger data & storing ledger files and elements of ledger data into immutable sequential listing (i.e. second block) entries / blocks (i.e. blockchain))
The same motivation to combine utilized in claim 1 is equally applicable in the instant claim.
Regarding claims 8 and 18, Strauss and Lieginger disclose the limitations of the system of claim 1, and the method of claim 11.
Lieginger teaches the limitations of claims 8 and 18 as follows:
wherein the computer-executable instructions that, when executed by the processor, further cause the processor to:
update, based on the second fact, a monthly premium of the policy. (Lieginger paras [0059]- [0060]: periodically adjusting (i.e. update) associated with underwriting assessment scores and determinations (i.e. second fact) the monthly insurance premium of a policy (i.e. monthly premium of the policy))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to integrate Lieginger’s adjustment of monthly premiums with Strauss in order to ensure that changes in policyholder data, and premium calculations are processed accurately and keeping up pace with life’s changes.
Regarding claims 9 and 19, Strauss and Lieginger disclose the limitations of the system of claim 1, and the method of claim 11.
Strauss and Lieginger teach the limitations of claims 9 and 19 as follows:
wherein the automated program defines a plurality of execution conditions (Strauss col. 5, lines 13-16, col. 19, lines 4-20, col. 21, lines 23-30 & 35-42, col. 25, lines 39-52, col. 30, lines 22-26: generate & classify ledger data and automatedly generating an algorithm (i.e. automated program) to be performed and may be implemented as a blockchain based on a determining matches (i.e. defining an execution condition), that when the plurality of execution conditions are satisfied, upon the execution condition being satisfied (Lieginger paras [0066], [0096]- [0098]: determine if factors satisfy criteria to produce a decision (i.e. condition being satisfied) cause the automated program to automatically execute in the blockchain to generate the policy, (Strauss col. 5, lines 13-16, col. 19, lines 4-20, col. 21, lines 35-42, col. 25, lines 39-52, col. 30, lines 22-26: automatedly generating (i.e. cause to be automatically executed) an algorithm (i.e. automated program) to be performed by device storing ledger files to an immutable sequential listing (i.e. blockchain), and wherein the computer-executable instructions that, when executed by the processor, further cause the processor to:
cause the smart contract to acquire from one or more second data sources, using the protocol and based on the identifier (Strauss col. 4, lines 64-67, col. 5, lines 1-5; col. 21, lines 23-30: the immutable program ledger acquires a query or user edits based upon the specific properties identifying a user member (i.e. identifier) included in the query), a plurality of facts indicative of the plurality of execution conditions being satisfied. (Lieginger paras [0067], [0080]- [0081], [0096]: automatically generating underwriting assessment scores, rating class determinations, and factor values (i.e. plurality of facts indicative) and determine if they satisfy criteria to produce a decision (i.e. plurality of execution conditions being satisfied) based off obtaining data representing inputs from multiple data sources (i.e. one or more second data sources), and pass the data via an API (i.e. using a protocol))
The same motivation to combine utilized in claim 1 is equally applicable in the instant claim.
Regarding claim 11, Strauss teaches the limitations of claim 11 as follows:
A computer-implemented method for applying zero knowledge proof in predictive analytics, comprising: (Strauss col. 17, lines 20-24, col. 19, lines 12-17; col. 21, lines 23-26: system that applies zero knowledge sets (i.e. zero knowledge-proof)) and predictive trendlines (i.e. predictive analytics) for future data)
receiving, by a processor, a request for a policy for a user, the request including an identifier associated with the user; (Strauss col. 4, lines 64-67, col. 5, lines 1-5, col. 5, lines 64-67, col.6, lines 1-2 & 37-44, col. 21, lines 23-30): receiving edits or a query from a user (i.e. request) for ledger information, wherein the ledger information includes user insurance policy data (i.e. policy for a user) and the query includes specific properties to be matched against membership information (i.e. identifiers associated with users/members) stored in the immutable sequential listing associated with insurance ledger files , where ledger data contains information stored (i.e. identifier) to an immutable sequential listing related to identification of a user (i.e. associated with the user) and life insurance policy data (i.e. policy of a user), after cryptographically hashing the ledger file)
generating, by the processor, an automated program in a first block of a blockchain, the automated program corresponding to the request and defining an execution condition; (Strauss col. 5, lines 13-16 & 35-46, col. 6, ll. 37-44 & 52-57; col. 19, lines 4-20, col. 21, lines 23-30 & 35-42, col. 25, lines 39-52, col. 30, lines 22-26: using machine learning to generate & classify ledger data and automatedly generating an algorithm (i.e. automate program) to be performed by device storing ledger files to an immutable sequential listing (i.e. block of a blockchain), that may be implemented as a blockchain based on a determining matches (i.e. defining an execution condition), wherein processing of the ledger data and storing the ledger data in the blockchain occurs in relation to the user updating the ledger data and querying the ledger data (i.e. corresponding to requests))
cause the automated program to acquire based on the identifier (Strauss col. 4, lines 64-67, col. 5, lines 1-5; col. 21, lines 23-30: the immutable program ledger acquires a query or user edits based upon the specific properties identifying a user member (i.e. identifier) included in the query)
executing, the automated program in the first block (Strauss col. 5, lines liens 13-16 & 35-46, col. 6, ll. 37-44 & 52-57; col. 19, lines 4-20, col. 21, lines 35-42: implemented as a blockchain, where sub-listings are blocks (i.e. first block) and where ledger files stored in the immutable sequential listing are processed by the processor (i.e. executed))
storing, by the processor, in a second block of the blockchain; and (Strauss col. 5, lines 13-16 & 35-46, col. 16, lines 53-60, col.18, lines 26-40; col. 19, lines 4-20: storing ledger files and elements of ledger data into immutable sequential listing (i.e. second block) entries / blocks (i.e. blockchain))
attaching, by the processor, the second block to the first block. (Strauss col. 5, lines 13-16 & 35-46, col. 18, lines 30-33, col. 19, lines 4-20, col. 21, lines 32-38: blocks are placed (i.e. attached) in chronological and sequential order (i.e. second block to the first block) and linked)
Strauss does not explicitly disclose the remaining part of the limitation as follows:
causing, by the processor, the automated program to acquire from a data source, using a protocol, a fact indicative of the execution condition being satisfied;
based on the fact, generate the policy for the user;
the policy for the user
However, in the same field of endeavor, Lieginger discloses the remaining limitations of claim 11 as follows:
causing, by the processor, the automated program to acquire from a data source, using a protocol, a fact indicative of the execution condition being satisfied; (Lieginger paras [0067], [0080]- [0081], [0096]: automatically generating underwriting assessment scores, rating class determinations, and factor values (i.e. fact indicative) and determine if they satisfy criteria to produce a decision (i.e. condition being satisfied) based off obtaining data representing inputs from multiple data sources (i.e. data source), and pass the data via an API (i.e. using a protocol))
based on the fact, generate the policy for the user; (Lieginger paras [0066], [0096]- [0098]: based on an underwriting assessment score and determination (i.e. based on the fact), confirm a class decision of binding the policy and issuing a policy number for a user (i.e. generate the policy for the user))
the policy for the user (Lieginger paras [0097]- [0098]: binding the policy and issuing a policy number for a user (i.e. policy for the user))
Lieginger is combinable with Strauss because both are from the same the same field of endeavor of computer-implemented insurance analytics systems for processing data to evaluate, predict, and support policy determinations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to integrate Lieginger’s method of obtaining data and generating policies based off facts and satisfying conditions with Strauss in order to improve data integrity, and accurate responsiveness for policy generation, and enables auditability in automated life insurance platforms.
Claims 3, 4, 6, 13, 14, and 16 are unpatentable under U.S.C 103 as being unpatentable Strauss (US 11790459B1) and Lieginger (US 20250117860A1), as applied to claims 1 and 11, further in view of Kaleal (US 2022/0384027 A1)
Regarding claims 3 and 13, Strauss and Lieginger disclose the limitations of the system of claims 1 and 2, and the method of claims 11 and 12.
Strauss and Lieginger teach the limitations of claims 3 and 13 as follows:
wherein the computer-executable instructions that, when executed by the processor, further cause the processor to:
cause the automated program to call an application program interface (API) of the protocol to: (Lieginger paras [0067], [0080], [0096]: passes factors via API (i.e. call an application program interface (API))
obtain from the data source, (Lieginger paras [0067], [0080]- [0081], [0096]: obtaining data from sources (i.e. obtain from data source) based on the identifier, data associated with the execution condition, (Strauss col. 4, lines 64-67, col. 5, lines 1-5, col. 5, lines 46-50, col. 19, lines 4-20: where ledger data contains information stored (i.e. identifier) to an immutable sequential listing related to identification of a user, determination matches (i.e. execution condition)
the fact indicative of the execution condition being satisfied; (Lieginger paras [0067], [0080]- [0081], [0083], [0096]: underwriting assessment scores, rating class determinations, and factor values (i.e. fact indicative) and determine if they satisfy criteria to produce a decision (i.e. condition being satisfied)
and determine, based on the fact indicative of the execution condition being satisfied, an estimated rate associated with the policy. (Lieginger paras [0067], [0080]- [0081], [0083], [0096]: from underwriting assessment scores, rating class determinations, and factor values (i.e. fact indicative) and determine if they satisfy criteria to produce a decision (i.e. condition being satisfied), establish a policy’s price (i.e. estimated rate associated with the policy)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to integrate Lieginger’s API leverage and prices associated with policies with Strauss in order to efficiently manage and exchange data between sources, as well as accurately bill users based on accommodating rates.
Neither Strauss or Lieginger disclose the limitations of claim 3 and 13 as follows:
generate, based on the data and using a cryptographic hash function
However, in the same field of endeavor, Kaleal discloses the limitations of claims 3 and 13 as follows:
generate, based on the data and using a cryptographic hash function, (Kaleal paras [0247], [0290], [0318]: using cryptographic hashes and encryption (i.e. cryptographic hash function)
Strauss and Lieginger are combinable with Kaleal because all are from the same field of endeavor of computer-implemented health analytics systems for processing data to evaluate, predict, and support determinations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to integrate Kaleal’s cryptographic hashing method with the system of Strauss and Lieginger in order to maintain data integrity, verify authenticity, and protect sensitive health data related to users.
Regarding claims 4 and 14, Strauss and Lieginger disclose the limitations of the system of claim 1, and the method of claim 11.
Neither Strauss or Lieginger disclose the limitations of claims 4 and 14 as follows:
wherein the protocol includes a Decentralize Oracle (DECO) protocol
However, in the same field of endeavor Kaleal teaches the limitations of claims 4 and 14 as follows:
wherein the protocol includes a Decentralize Oracle (DECO) protocol. (Kaleal paras [0247], [0290], [0318]: using cryptographic hashes and encryption protocols (i.e. Decentralize Oracle (DECO) protocol) for transactions in the decentralized database)
Kaleal is combinable with Strauss and Lieginger because all are from the same field of endeavor of computer-implemented health analytics systems for processing data to evaluate, predict, and support determinations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to integrate Kaleal’s cryptographic hashing and encryption protocols with the system of Strauss and Lieginger in order to enable secure, privacy-preserving verification of sensitive user data without exposing underlying, confidential information.
Regarding claims 6 and 16, Strauss and Lieginger disclose the limitations of the system of claim 1, and the method of claim 11.
Strauss teaches the limitations of claims 6 and 16 as follows:
and the policy is associated with a life insurance policy (Strauss col. 2, lines 15-20, col. 11, lines 5-8: and life insurance policy data (i.e. policy of a user), after cryptographically hashing the ledger file)
Neither Strauss or Lieginger teach the remaining limitations of claims 6 and 16 as follows:
wherein: the data source includes a third-party server associated with a fitness service provided to the user
However, in the same field of endeavor Kaleal teaches the limitations of claims 6 and 16 as follows:
wherein: the data source includes a third-party server associated with a fitness service provided to the user, (Kaleal paras [0262], [0286], [0364]: using other third-party health and fitness systems (i.e. third-party server) that record user health and fitness activity data (i.e. fitness service)
Kaleal is combinable with Strauss and Lieginger because all are from the same field of endeavor of computer-implemented health analytics systems for processing data to evaluate, predict, and support determinations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to integrate Kaleal’s use of third-party fitness sources with the system of Strauss and Lieginger in order to allow insurers to accurately assess risk, lower premium costs for active users, and emphasize healthier lifestyles that could reduce long-term claims.
Claims 10 and 20 are unpatentable under U.S.C 103 as being unpatentable over Strauss (US 11790459B1) and Lieginger (US 20250117860A1), as applied to claim 1, further in view of Wasser (US 9, 830, 646 B1)
Regarding claims 10 and 20, Strauss and Lieginger disclose the limitations of the system of claim 1, and the method of claim 11.
Strauss and Lieginger teach the limitations of claims 10 and 20 as follows:
wherein the computer-executable instructions that, when executed by the processor, further cause the processor to: (Strauss col. 2, lines 31-39, col. 5, lines 49-52, col. 11, lines 12-14: a memory containing instructions (i.e. computer-executable instructions) configuring the processor to (i.e. executed by the processor) receive and categorize a ledger file)
receive a second request for a second policy for the user, the second request including the identifier associated with the user; (Strauss col. 4, lines 64-67, col. 5, lines 1-5, col. 5, lines 64-67, col.6, lines 1-2, col. 21, lines 23-26): retrieving user information by query (i.e. second request) associated with insurance ledger files, where ledger data contains information stored (i.e. identifier) to an immutable sequential listing related to identification of a user (i.e. associated with the user) and life insurance policy data (i.e. policy of a user), after cryptographically hashing the ledger file)
generate a second automated program executed in a third block of the blockchain, the second automated program defining a second execution; (Strauss col. 5, lines 13-16, col. 19, lines 4-20, col. 21, lines 35-42, col. 25, lines 39-52, col. 30, lines 22-26: generating an algorithm (i.e. second automated program) to be performed by device storing ledger files to an immutable sequential listing (i.e. third block of a blockchain), that may be implemented as a blockchain based on a determining matches (i.e. defining a second execution condition))
using the protocol (Lieginger paras [0067], [0096]: and pass the data via an API (i.e. using a protocol))
and based on the identifier, (Strauss col. 4, lines 64-67, col. 5, lines 1-5: where ledger data contains information stored (i.e. identifier) to an immutable sequential listing related to identification of a user)
execute, the second automated program in the third block to generate the second policy; (Strauss col. 5, liens 13-16, col. 21, lines 35-42, col. 30, lines 22-26: implemented as a blockchain, where sub-listings are blocks (i.e. third block) and where ledger files stored in the immutable sequential listing are processed by the processor (i.e. executed))
store the second policy in a fourth block of the blockchain; and attach the fourth block to the third block in the blockchain. (Strauss col. 16, lines 53-60, col.18, lines 26-40, col. 21, lines 32-38: storing ledger files and elements of ledger data into immutable sequential listing (i.e. fourth block) entries / blocks (i.e. blockchain)); blocks are placed (i.e. attached) in chronological and sequential order (i.e. fourth block to the third block) and linked)
Lieginger is combinable with Strauss because both are from the same the same field of endeavor of computer-implemented insurance analytics systems for processing data to evaluate, predict, and support policy determinations. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to integrate Lieginger’s method of obtaining data with Strauss in order to improve data integrity, and accurate responsiveness for policy generation, and enables auditability in automated life insurance platforms.
Neither Strauss or Lieginger disclose the limitations of claims 10 and 20 as follows:
condition being that a credit score of the user satisfies a criteria
cause the second automated program to acquire from a credit bureau, a second fact indicative of the credit score satisfying the criteria;
based on the second fact
However, in the same field of endeavor, Wasser discloses the limitations of claims 10 and 20 as follows:
condition being that a credit score of the user satisfies a criteria (Wasser col. 4, lines 51-65, col. 11, lines 23-33, col 16, lines 55-60, fig. 1: evaluating credit reports based on them meeting threshold levels (i.e. satisfying the criteria)
cause the second automated program to acquire from a credit bureau, a second fact indicative of the credit score satisfying the criteria; (Wasser col. 4, lines 51-65, col. 11, lines 23-33, col 16, lines 55-60, fig. 1: collect credit reports from a credit bureau (i.e. credit bureau), and evaluating the credit scores as goal or warning (i.e. a second facts indicative) based on it meeting threshold levels (i.e. satisfying the criteria)
based on the second fact (Wasser col. 4, lines 51-65: evaluating the credit scores as goal or warning (i.e. a second facts indicative)
Strauss and Lieginger are combinable with Wasser because all are from the same field of endeavor of computer-implemented systems for processing financial data to support risk evaluation. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to integrate Wasser’s credit score evaluation and collection methods with the system of Strauss and Lieginger in order to make sure insurers set premiums that align with the potential risk of loss, and provide lower rates to those with better credit.
Prior Art Not Relied Upon but Considered Includes:
US 20240046362 A1, “System and Method for Configuring an Insurance Policy with Digital Assets”, by James Eason. This reference teaches a system using smart contracts for configuring an insurance policy so that payouts can be converted into and held as digital assets. It discloses storing the policy on a blockchain, managing authorization, and distributing assets while complying with insurance regulations (see paras. [0033], [0043], [0044], [0089- [0095]).
Conclusion
Claims 1-20 are rejected.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAELYN MCCRACKEN whose telephone number is (571)272-2075. The examiner can normally be reached Monday-Friday 7:30 am- 5pm.
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, Taghi T Arani can be reached at (571) 272-3787. 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.
/J.D.M./Examiner, Art Unit 2438
/TAGHI T ARANI/Supervisory Patent Examiner, Art Unit 2438