DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
On response filed on 8/3/2026, claims 1,19 and 20 were/was amended; no new claims were added; no claims was/were cancelled. As a result, claims 1-20 are pending, of which claims 1, 10 and 20 are in independent form.
Response to Arguments
On Pages 9-10 of Remarks filed on 8/3/2026, applicant argues that “In Liu, by contrast, the large language model does not incorporate the received data related to the second user. Rather, the specific therapeutic journey that is the subject of authentication is retrieved from a separate, stored data source and is accessed and conditionally revealed to the trusted person. Because the therapeutic journey data in Liu is deliberately stored so that it can be accessed and revealed, i.e., it is meant to be accessed, the enhanced-security benefit of claim 1, of not storing the data explicitly, has no application in Liu. It is noted that Liu states that ‘fine-tuning a large language model (LLM) to understand a user's therapeutic journey and authenticate access based on that knowledge comprises collecting a dataset of information related to therapeutic journeys, preprocessing the data, selecting an appropriate LLM, and then fine-tuning the model using techniques such as transfer learning and reinforcement learning.’ See Liu column 11, lines 55-64. Even if, for the sake of argument, it was submitted that such fine-tuning constitutes a form of incorporating data, the described process is not what is required by claims 1, 19, and 20 as amended. The data used to fine-tune the model in Liu is a general dataset of therapeutic- journey information used to teach the model to understand and generate responses about therapeutic journeys generally; it is not the specific ‘data related to the second user’ received from the first user…” with regards to independent claims 1, 19 and 20. The argument has been carefully and respectfully considered but is moot in a new ground of rejection in view of Ponnivalavan et al. (US 2025/0371117 A1).
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed 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 has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 8/3/2026 has been entered.
Claim Rejections - 35 USC § 103
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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Foote et al. (US 11,816,749 B1) hereinafter Foote, in view of Jakobsson (US 2023/0086191 A1), in view of Lembcke (US 2015/0169898 A1), and further in view of Ponnivalavan et al. (US 2025/0371117 A1) hereinafter Ponnivalavan.
As to claim 1, Foote teaches a computer software product comprising a tangible non-transitory computer-readable medium in which program instructions are stored, which instructions, when read by one or more processors, cause the one or more processors to:
receive, from a first user:
a digital item designated for sharing with at least one second user (e.g., information which may be used to create a last will, information regarding digital assets, for example, NFT, cryptocurrency, and blockchain; see col. 4, lines 15-33 “A will creation module 318 may prompt the user for information which may be used to create a last will and testament. A social directives creation module 320 may enable the user to choose which sites and social media platforms the user would like to have deleted, memorialized, or made accessible. A digital inheritance module 322 may prompt the user for information regarding digital assets, for example, NFT, cryptocurrency, and blockchain.”; see also. col. 4, lines 37-50 for storing the received important files such as will, living trust and cryptocurrency and NFT directives to be transferred to beneficiaries when the user passes away.),
at least one communication point for the second user (e.g., collected information necessary to prepare an estate planning model for the user…contact information and permission, or access levels for trusted parties, potential beneficiary (-ies), trustee(s), executor, and attorney; see col. 3, lines 55-67 “A future messaging module 304 may enable the user to send a digital time capsule on a specific date, for example, on a loved one's birthday or anniversary, before or after the user has passed away. The user may specify the date for the message to be sent and the recipients' electronic address (e.g., email, or social platform page). The digital time capsule may include, for example, photos, recorded videos, songs, and personalized messages. A legacy journal 306 may be used for documenting key events, milestones and achievements in the user's life. A memory vault 308 may provide secure file storage for images, videos, and music.”), and
data related to the second user (see col. 6, lines 1-7 “For financial instruments and financial products such stocks, bonds, life insurance policies, bank accounts, loans, mortgages, etc., this information may include the location of documents, and for those with an online presence, website addresses, passwords, login ids, and secondary verification information, e.g., challenge questions, for accessing the documents.”).
Foote does not explicitly teach but Jakobsson teaches the following limitation -
execute an authentication process, and provided the authentication process is successful, provide access to the digital item (see para. [0333] “NFT security platforms in accordance with many embodiments of the invention can be used to prove access rights to external resources (e.g., service providers), which can be beneficial. NFT security platforms can be used to protect wallet contents (e.g., crypto currencies, NFTs, among others) against bad actors and action (e.g., against theft), by storing contents of a wallet in an in an encrypted form that can be decrypted based on a user performing a successful biometric authentication.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Foote and Jakobsson before him or her, to modify the scheme of Foote by including Jakobsson. The suggestion/motivation for doing so would have been to use any authentication method such as biometric authentication via a trusted third party to determine right to access to the private key for decrypting important document(s)/asset(s) or to provide access to the important document/asset(s).
The combination of Foote and Jakobsson does not explicitly teach but Lembcke teaches - execute an authentication process, by:
providing, to the communication point, access to the authentication questions, and
receiving respective responses to the authentication questions,
determine an outcome of the authentication process based on a correctness of the responses (see para. [0081] “Once the above conditions have been met, all beneficiaries designated by the subscriber are notified of the respective beneficiary capsules. To access the content, the beneficiaries must, submit a death certificate number for the subscriber and receive, after authentication, a single use code from the website server 12 which is then transmitted to the beneficiary through a separate communication means which is prearranged by the subscriber. The single use code can then be entered by the respective beneficiary into the website server to grant access to the respective beneficiary authorization criteria 30. The criteria typically comprise a series of challenge questions which are intended to be personalized to the beneficiary. Once the challenge questions have been met, the beneficiary then gains access to the digital memory stored within the respective capsule 28 within the beneficiary zone of the proprietary server.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Foote, Jakobsson and Lembcke before him or her, to modify the scheme of Foote and Jakobsson by including Lembcke. The suggestion/motivation for doing so would have been to securely identify the authenticity of beneficiary identity for access to the time capsule component by adding another layer of verification with a series of questions and answers personalized to the beneficiary, as briefly discussed in Lembcke, para. [0019]-[0025].
The combination of Foote, Jakobss and Lembcke does not explicitly teach but Ponnivalavan teaches the following limitations - incorporate the data into a large language model (see figs 1a, 1b, 3 and 4; see para. [0015] “It is assumed that a data service provider has access to user data containing information about the activity associated with a legitimate user. An unverified user seeking access to the secure system function is asked a number of identity verification questions based on stored information relating to the activity associated with a legitimate user of the system. Based on the responses of the unverified end user (seeking access to the secure system) to each one of the identity verification questions presented, a score is calculated. This score could be an average score of the different scores obtained by answering the individual identity verification questions. The score is used to validate the identity of the user seeking access to the system and to determine whether to grant access or deny access to such a user. By improving the robustness of user identify verification in this manner, a consequent improvement in the security of the secure system is obtained. More generally, improvements in system security are obtained by determining an authentication outcome based on a comparison of an expected answer to a question about a legitimate user's past activity with and-end users' actual response. In some embodiments, the methods presented herein, describing user identity validation based on user activity, are applied on their own. In other embodiments, in the methods are applied in conjunction with other user identity validation processes such as a credential-based authentication (e.g. username-password) or biometric validation. The unverified user does not directly interact with any of the data service providers in the system, so unverified user's responses to the verification questions are parsed and secured before passing them to different data providers (large language model (LLM), enterprise data provider, non-enterprise data provider etc etc.) to prevent any cyber-attacks on the data providers (the user is prevented from running any custom queries for the LLM). This separation of the data service providers and the LLM from the end-user provides an additional layer of security, thus yielding a further improvement in overall system security. In this regard, in some embodiments, an authentication system performing the authentication process uses an LLM to perform an authentication-related function or functions such as deriving a fact from a data item, generating a question-answer pair from a fact, performing a comparison between an end-user response and an expected answer etc. Such interactions with the LLM are handled by the authentication system, and can therefore be tightly controlled, and do not require an interface to the LLM to be exposed to the end-user.”; see para. [0018] “. The data access interface 108 may be an interface to an online data repository (such as Microsoft SharePoint, Google Workspace, Apple iCloud, Dropbox etc.) or messaging system (e.g. email system such as Microsoft Outlook, Gmail etc.). In some embodiments, the data access interface 108 interacts with authentication system 105, for example, to provide information regarding a legitimate user of the secure system 103. The data access interface 108 has access to data stores containing user activity information such as emails, documents, repositories, pull-requests, dashboards etc., belonging to a legitimate user of the secure system 103. In one embodiment the data access interface 108 is separate from the secure system 103. In another embodiment, the data access interface 108 is hosted on the secure system 103 itself. In either case, the data access interface 108 and data store 110 may be local to or remote from the authentication system 105 ”; It is noted that the data store 110 stores general user activity data of a legitimate user, provided to the data store from secure system 103 and that the data store 110 is accessible by authentication system along with LLM 106 in order to generate questions and expected answers based on facts selected from the data stored in the data store 110.); generating one or more authentication questions from the data using a large language model using the large language model (see para. [0030] “In other implementations, step S304 is performed by the data access interface 108. In Step S306, facts are derived from the individual data items to produce a list of facts. In step S308, a fact is randomly selected from the list of facts. After a fact has been selected, the fact is removed so that the same fact is not selected again. In step S310, a question and an expected answer to the question are generated based on the randomly selected fact. In some embodiments, steps S306-S310 are performed by the authentication system 105. In some examples, the authentication system 105 uses the LLM 106 to perform steps S306 and S310. Using an LLM may involve generating a prompt that includes the fact and providing instructions for generating the fact. In step S312, the question is presented to the user via interface 104. In some examples, the user may responds to the question via the interface 104, for example by inputting, via a user input device, a user response in a relevant field displayed on the interface 104. The interface 104 provides the user response to the authentication system 105 for verification. In step S314, a score is computed based on a comparison between the user response and the expected answer. In step S316, the score for the question is stored for the average score computation. In some embodiments, steps S314 and S316 are performed by the authentication system 105. In some examples, steps S308-S316 are repeated several times, i.e., the user is presented with multiple questions, each generated by a randomly selected fact, and the individual scores corresponding to the multiple questions are stored. In step S318, an average score, averaged over multiple questions presented to the user, is computed. Based on the average score, an authentication outcome is determined. In one example, the authentication outcome is, for example, an instruction to allow or deny access to the user 102. In some examples, the authentication outcome is determined, by comparing the average score to a pre-defined threshold. In some embodiments, steps S318-S320 are performed by the authentication system 105. In some examples, the authentication system 105 uses the LLM 106 to perform steps S318-S320. In step S322, the authentication outcome is communicated to a relevant party. The relevant party may be the enterprise data provider 108 or the user 102, or both. In step S324, depending on the authentication outcome, the system 100 allows or denies the user 102 access to the system 100.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Foote, Jakobsson, Lembcke, and Ponnivalavan before him or her, to modify the scheme of Foote, Jakobsson, and Lembcke by including Ponnivalavan. The suggestion/motivation for doing so would have been to add a robust authentication mechanism by using a data item representative of an activity associated with a legitimate user and authenticating the user by comparing the end-user response to the question generated based on a fact derived from the data item with the expected answer generated by the LLM.
Claims 19-20 include similar limitations as claim 1 and thus claim 1 is rejected under the same rationale as in claim 1.
As to claim 2, in view of claim 1, Foote teaches wherein the digital item includes a digital item selected from the group consisting of: at least one document, a digital asset, and a text composed by the first user (see col. 4, lines 15-29, “A will creation module 318 may prompt the user for information which may be used to create a last will and testament. A social directives creation module 320 may enable the user to choose which sites and social media platforms the user would like to have deleted, memorialized, or made accessible. A digital inheritance module 322 may prompt the user for information regarding digital assets, for example, NFT, cryptocurrency, and blockchain. A health care directives creation module 324 may prompt the user to specify which actions should be taken for their health the user is no longer able to make decisions for themselves due to of illness or incapacity. A power of attorney creation module 326 may be used to store power of attorney documents. A revocable living trust creation module 328 may be used to store revocable living trust documents.”).
As to claim 3, in view of claim 1, Lembcke teaches wherein the instructions cause the processors to generate each of the authentication questions, following an initial one of the authentication questions, only after receiving the response to an immediately-preceding one of the authentication questions (see para. [0081] “The single use code can then be entered by the respective beneficiary into the website server to grant access to the respective beneficiary authorization criteria 30. The criteria typically comprise a series of challenge questions which are intended to be personalized to the beneficiary. Once the challenge questions have been met, the beneficiary then gains access to the digital memory stored within the respective capsule 28 within the beneficiary zone of the proprietary server.””; The examiner notes that the series of authentication is progressive in that a previous authentication need to be successfully completed to progress onto next stage.)
As to claim 4, in view of claim 1, Lembcke teaches wherein the instructions further cause the processors to:
receive, from the first user, one or more conditions for sharing the digital item with the second user,
store the digital item, and
keep the digital item in storage, without executing the authentication process, until the conditions are satisfied (see para. [0080] “The content left in the beneficiary capsules typically becomes available to the respective designated beneficiaries only upon one of two conditions being met. The conditions include either the death of the subscriber being confirmed or the incapacitation of the subscriber being confirmed. Confirmation of incapacitation can only occur if a group of incapacitation contacts preselected by the subscriber can confirm the incapacitation.”).
As to claim 5, in view of claim 4, Foote teaches wherein the instructions further cause the processors to encrypt the digital item prior to storing the digital item, and wherein the instructions cause the processors to provide access to the digital item by decrypting the digital item (see col. 10, lines 35-43 “In an embodiment, the user may enter their private key for a given wallet into the system. The system may divide the key into portions, or “shards”, each shard being encrypted and secured in a different portion in the blockchain. At the time of asset distribution, after the user's death, the system may access the private key shards on the back-end and reconstruct the private key for the purpose of fulfilling the terms of the will. As this process occurs at the system back-end, the private key is never exposed.; It is noted that the private key needed to decrypt the digital asset is divided into shards and are stored in different blockchain locations such that as the time-capsule conditions the shards are retrieved to be assembled and made accessible to the beneficiary.”).
As to claim 6, in view of claim 5, Foote teaches wherein the instructions cause the processors to encrypt the digital item using an encryption key, wherein the instructions further cause the processors to distribute portions of the encryption key to different respective servers for storage, and wherein the instructions cause the processors to decrypt the digital item by:
reassembling the portions of the encryption key, and
using the encryption key, decrypting the digital item (see col. 10, lines 35-43 “In an embodiment, the user may enter their private key for a given wallet into the system. The system may divide the key into portions, or “shards”, each shard being encrypted and secured in a different portion in the blockchain. At the time of asset distribution, after the user's death, the system may access the private key shards on the back-end and reconstruct the private key for the purpose of fulfilling the terms of the will. As this process occurs at the system back-end, the private key is never exposed.; It is noted that the private key needed to decrypt the digital asset is divided into shards and are stored in different blockchain locations such that as the time-capsule conditions the shards are retrieved to be assembled and made accessible to the beneficiary.”).
As to claim 7, in view of claim 4, Foote wherein the instructions cause the processors to store the digital item by distributing portions of the digital item to different respective servers for storage, and wherein the instructions cause the processors to provide access to the digital item by reassembling the portions (see col. 10, lines 35-43 “In an embodiment, the user may enter their private key for a given wallet into the system. The system may divide the key into portions, or “shards”, each shard being encrypted and secured in a different portion in the blockchain. At the time of asset distribution, after the user's death, the system may access the private key shards on the back-end and reconstruct the private key for the purpose of fulfilling the terms of the will. As this process occurs at the system back-end, the private key is never exposed.; It is noted that the private key needed to decrypt the digital asset is divided into shards and are stored in different blockchain locations such that as the time-capsule conditions the shards are retrieved to be assembled and made accessible to the beneficiary.”; The examiner notes the private key can be the instant application’s digital item.).
As to claim 8, in view of claim 1, Ponnivalavan teaches wherein the instructions cause the processor to determine the outcome of the authentication process by comparing a percentage of the responses that are correct to a predefined correctness threshold (see para [0030] In some examples, the authentication outcome is determined, by comparing the average score to a pre-defined threshold.”)
As to claim 9, in view of claim 8, Ponnivalavan teaches wherein the instructions further cause the processors to receive the correctness threshold from the first user (see para. [0032] “In some examples, the authentication outcome is determined, by comparing the average score to a pre-defined threshold.”).
As to claim 10, in view of claim 1, Lembcke teaches wherein the instructions further cause the processors to execute a security process (e.g., authentication of beneficiary) in response to one or more conditions being satisfied (see para. [0080]-[0081], e.g., confirmation of incapacitation of user).
As to claim 11, in view of claim 10, Jakobsson teaches wherein the conditions include the authentication process not being successful (see para. [0076]; e.g., overwriting a URL in the token to a dummy value in the event of blocking of the performing of the transfer of ownership of the token).
As to claim 12, in view of claim 10, Jakobsson teaches wherein the instructions cause the processors to execute the security process instead of the authentication process (see para. [0076]).
As to claim 13, in view of claim 10, Jakobsson teaches wherein the security process includes providing access to a decoy digital item instead of the digital item (see para. [0076]).
As to claim 14, in view of claim 13, Jakobsson teaches wherein the instructions further cause the processors to create the decoy digital item based on the digital item (see para. [0076]).
As to claim 15, in view of claim 13, Jakobsson teaches wherein the instructions further cause the processors to store the digital item and the decoy digital item in response to receiving the digital item (see para. [0076]).
As to claim 16, in view of claim 15, Jakobsson teaches wherein the instructions cause the processors to execute the same process for storing the decoy digital item as for storing the digital item (see para. [0076]).
As to claim 17, in view of claim 10, Jakobsson teaches wherein the security process includes sharing the digital item with an emergency contact (see para. [00411]).
As to claim 18, in view of claim 10, Jakobsson teaches wherein the security process includes deleting the digital item (see para. [00395]; The examiner considers not providing decryption keys to unlock the content or digital item upon unsuccess authentication/verification of beneficiary as equivalent to deleting the digital item.).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HEE K SONG whose telephone number is (571)270-3260. The examiner can normally be reached on M-F 9:00 am – 5:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Eleni Shiferaw can be reached on (571)272-3867 . The fax phone number for the organization where this application or proceeding is assigned is 571-273-7291.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HEE K SONG/PRIMARY Examiner, Art Unit 2497
Prosecution Insights