DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
The present office action is responsive to communication filed on . Claims 1, 6-7, 15, and 18-20 have been amended. Claims 3, 5, and 17 have been cancelled. Application’s amendments with respect the object have been fully considered and are persuasive. Therefore, the claim objection have been withdrawn.
Application’s arguments and amendments, with respect of 35 USC 112(a) and 35 USC 112(b), as seen in pages 6-9, have been fully considered but not fully persuasive. Although, applicant gave a high level overview of the invention the concepts do not reflect clearly in the claims. There is still ambiguity of the use of the claim terms such as spreading key shards over the large language model within the claims. Within the Remarks there were no reasonable explanation for the specific use of term of “spread” within the context of the large language models. Additionally with regards to Applicant’s arguments and amendments to the claims with regards to 35 USC 102 and 35 USC 103, as seen pages 9-13, have been fully considered and persuasive. Therefore the rejections have been withdrawn. However, upon further considerations, an new grounds of rejection is made in view of Huang et al. (US-12158929-B1), Wentz et al. (US-20200351098-A1), Amisano et al. (US-20210271963-A1), Corduan et al. (US-20190007205-A1), Noam et al. (US-20200374113-A1), and Norton Jr. (US-20250112925-A1).
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claim 1:
Regarding the limitation “processing the request via a large language model to generate a response,” the specification generally describes that a large language model generates responses to prompts, but does not provide any specific architecture, algorithm, or operational detail regarding how the large language model processes prompts in conjunction with the claimed key identifier functionality. The disclosure lacks any concrete examples, flowcharts, or pseudo-code illustrating the interaction of the generation process with the cryptographic features, and thus does not demonstrate possession of this limitation as it relates to the claimed invention.
For the limitation “processing the key identifier via the large language model to retrieve a signature key,” the specification describes, at a conceptual level, that key shards are associated with secure identifiers and that the model is trained to retrieve shards in response to identifiers. However, the disclosure fails to provide any structural or algorithmic detail as to how the large language model encodes, stores, or retrieves such shards in response to key identifiers. There is no disclosure of the neural network architecture, parameter encoding, mapping logic, or retrieval mechanism, nor any representative example, flow, or pseudo-code illustrating how the key identifier input results in the retrieval of key material. The written description is limited to high-level statements and does not demonstrate possession of the full scope of this limitation.
Further with regards to the amended limitation of, “…key shards spread over the language model…” and “…aggregating the signature key shards to construct the signature key…” the specification states that key shards may be spread over the large language model and retrieved using a secure identifier, and that aggregation may occur using a threshold scheme such as Shamir’s Secret Sharing. However, the disclosure does not provide any details regarding the manner in which shards are distributed within the model, the data structures or encoding used, the retrieval mechanism by which a threshold number of shards are accessed, or the algorithmic steps for aggregation. There is no example, architecture ,or pseudo-code illustrating how the key shards are spread over the large language model. Further, there is no example, architecture, or pseudo-code illustrating how the model’s parameters or outputs correspond to key shards, nor how the threshold is enforced or validated, and thus the written description does not demonstrate possession of the full scope of this claim.
Regarding claim 2:
With respect to the claim 2, the specification describes that a signature may be generated and sent with the response, but does not provide any details as to how the signature key, once reconstructed, is used in a cryptographically secure signing operation, nor does it disclose the data flow, input/output formats, or security measures for transmitting the signature and response to the requestor. The disclosure lacks any concrete implementation, protocol, or example showing the integration of the signing process with the large language model output or the secure handling of signature keys, and therefore does not demonstrate possession of this limitation.
Regarding claim 4:
With respect to claim 4, the specification mentions that training data may comprise key identifiers and associated shards, and that the model can be fine-tuned to return shards in response to identifiers. However, the disclosure does not provide any detail regarding the construction or structure of such training data, the training protocol, loss function, or validation method, nor does it provide examples or architectures that would enable a POSITA to understand how the model is trained to reliably map identifiers to shards. The written description is insufficient to show possession of this limitation.
Regarding claim 6:
With respect to claim 6, the specification mentions that the threshold number of shards may be greater than three, but does not provide any supporting detail, example, or structural description for how such a threshold is enforced, validated, or operationalized in the model or in the aggregation process. The disclosure is limited to a conclusory statement and does not demonstrate possession of this limitation.
Regarding claim 7:
With respect to claim 7, the specification mentions that key identifier validation may be performed, such as by checking against an access control table, but does not disclose any structure, data flow, or algorithm for performing validation, nor does it provide an example or protocol for how validation interacts with the model or the signing process. The lack of detail prevents a POSITA from recognizing that the inventor was in possession of this limitation.
Regarding claim 8:
With respect to claim 8, the specification states that validation may involve retrieving a threshold number of key shards, but does not provide any detail as to how success is measured, how the threshold is checked, or how the retrieval process is linked to validation logic. There is no example, flowchart, or structural description, and thus the written description is insufficient.
Regarding claim 9:
With respect to claim 9, the specification mentions that a public key may be provided to the requestor, but does not provide any detail regarding the mechanism for public key generation, distribution, association with signature keys, or the protocol for securely transmitting the public key to the requestor. The disclosure does not include any concrete implementation or example, and thus does not demonstrate possession of this limitation.
Regarding claim 10:
With respect to claim 10, the specification briefly refers to signature verification using a public key, but does not disclose any detail regarding the authentication process, verification protocol, data formats, or operational flow at the requestor, nor does it provide any example or structural description. The written description is insufficient to show possession of this limitation.
Regarding claim 11:
With respect to claim 11, as with claim 7, the specification mentions validation of the key identifier, but lacks any detailed structure, protocol, or example for performing validation prior to sending the response and signature.
Regarding claim 12:
With respect to claim 12, the specification refers to the possibility of using an access control table of authorized key identifiers, but does not disclose the structure, implementation, or operation of such a table, nor does it provide any example or protocol for performing the lookup or for integrating this step with the model and signing process.
Regarding claim 13:
With respect to claim 13, the specification mentions that responses may be augmented with co-signed information from additional data sources, but does not provide any detail regarding the mechanism, protocol, or structure for augmenting responses, integrating co-signed information, or coordinating signing between the model and additional sources. There is no example or operational detail, and thus the written description is insufficient.
Regarding claim 14:
With respect to claim 14, the specification refers to the use of data source unique signature keys for co-signing, but does not provide any structural or algorithmic detail regarding the management, generation, or use of such unique keys, nor does it disclose any example or protocol for co-signing or integrating such information with the response.
Regarding claim 15:
With respect to claim 15, the specification generically describes the possibility of implementing the methods on a machine-readable storage device, but does not provide any detail regarding the structure, format, or implementation of such instructions, nor does it provide any concrete example, pseudo-code, or operational flow for carrying out the claimed method on a processor (see also rejection of claim 1 above).
Regarding claim 16:
With respect to claim 16, the specification lacks any detail regarding the structure, logic, or implementation of the signing and sending operations in the context of a machine-readable storage device, nor does it provide any example or operational description. The written description is insufficient for this limitation.
Regarding claim 18:
With respect to claim 18, the specification mentions training with key identifier and shard examples, but does not provide any structural, architectural, or procedural detail regarding spreading shards over the model, the training process, or the retrieval mechanism in the context of a device claim. There is no example or operational flow, and thus the written description is insufficient.
Regarding claim 19:
With respect to claim 19, the specification describes, at a high level, a computing device with a processor and memory, but does not provide any detail, architecture, or example for carrying out the claimed operations on such a device, nor does it show possession of the specific interaction between processor, memory, and the large language model for the claimed cryptographic retrieval functionality (see also rejection of claim 1 above).
Regarding claim 20:
With respect to claim 20, the specification does not provide any structural, architectural, or operational detail regarding the integration of signing, key shard management, retrieval, or aggregation in the context of a device with processor and memory, nor does it provide any example or implementation detail for the claimed operations. The written description does not show possession of this limitation.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
Regarding claim 1:
The specification conceptually describes (i) prompts containing a key identifier and requests, (ii) training a large language model (LLM) with examples that pair key identifiers with key shards, (iii) the existence of key shards distributed across the model and the use of threshold reconstruction (e.g., Shamir’s Secret Sharing is mentioned), and (iv) subsequent signing of generated outputs. The specification lacks concrete architectures, pseudo-code, tokenization/encoding schemes, training schedules or hyperparameters, representative datasets, empirical performance metrics, or practical examples showing a working system that embeds, protects, retrieves, and reconstructs private key material from an LLM in response to a key identifier.
Application of Wands factors to the critical limitation “processing the key identifier via the large language model to retrieve a signature key”:
Quantity of experimentation necessary to make and use the invention: High. A POSITA would need to discover (a) how to encode key shards so they survive training and model updates, (b) how to reliably map an arbitrary key identifier in a prompt to the correct set of shard outputs across potentially thousands of parameters, (c) how to design training data and objectives that produce deterministic or reliably extractable shard outputs despite stochastic sampling and varied decoding strategies, and (d) how to reconcile security constraints (preventing exfiltration) with retrievability. These engineering tasks require many empirical trials across model architectures, tokenizers, training curricula, and prompt formats.
Amount of direction or guidance presented in the specification: Minimal. The specification gives high-level conceptual steps (tokenize, fine-tune, optionally use reinforcement learning, employ secret sharing) but provides no step-by-step procedures, no training recipes, no loss functions tied to shard retrieval integrity, no token encoding format for shards/identifiers, and no guidance on critical parameters (e.g., shard size, share encoding, threshold selection relative to share count, acceptable error rates). The lack of concrete instructions obliges substantial independent experimentation.
Presence or absence of working examples: Absent. The specification supplies no working examples, experimental results, or implementation data demonstrating successful embedding/retrieval of key shards from an LLM, nor any metrics showing reliability, false-positive/false-negative retrieval rates, or robustness to model versioning—factors critical to practical implementation.
Nature of the invention (complexity and predictability): Complex and unpredictable. The claimed invention combines cryptographic secret-sharing (which normally expects exact bit preservation and deterministic combinability) with stochastic generative models whose internal representations and outputs are inherently non-deterministic and sensitive to training regimes and sampling parameters. Predicting success and producing robust, repeatable retrieval behavior is not a straightforward or routine application of known ML or cryptographic techniques.
State of the prior art: Limited and not determinative. While prior art discloses secret sharing and conventional secure enclaves / HSM approaches for key storage, embedding secret key shards inside an LLM and reliably retrieving them via prompt processing is not a well-established, routine practice. The specification does not point to established prior art that would make the claimed LLM-based retrieval predictable to a POSITA without substantial development.
Relative skill of those in the art: High, but insufficient to negate undue experimentation. Practitioners skilled in machine learning and cryptography possess relevant background, but even such practitioners would face uncertain and potentially extensive trial-and-error to achieve the claimed functionality given the lack of enabling detail and the novelty of embedding cryptographic material in model parameters for prompt-triggered retrieval.
Predictability of the art: Low. Neural network behavior for precise, bit-accurate storage and retrieval is unpredictable; small changes in hyperparameters, tokenization, or model updates can alter outputs. Ensuring security (avoiding accidental leakage) while ensuring reliable retrieval increases unpredictability and reduces the expectation that routine experimentation will quickly succeed.
Breadth of the claims relative to the disclosure: Broad. Claim 1 covers any LLM that, upon processing a “key identifier,” retrieves a “signature key” (including many possible internal/external architectures: in-model shards, generative reconstruction, LLM-mediated external lookup, hybrid protocols). The specification does not enable each of these embodiments nor provides a unifying algorithmic framework that would render the entire claim breadth enabled.
Independent claim 1’s enablement failure applies equally to dependent claims 2, 3, 4, 6, 7, 8, 9, 10, 11, 12, 13, and 14 because none of these furnish the required structural or procedural detail: each merely adds functional results (signing responses, public-key distribution, validation by threshold shard retrieval, co-signing, shard counts, etc.) or generic computing elements (processor, memory) without disclosing how an LLM is trained, how identifiers map to shards in model parameters, how shards are encoded or aggregated, or how reliability and security are achieved.
Likewise, the same § 112(a) enablement deficiency for claim 1 applies to independent claim 15 and is not overcome by dependent claims 16 , which merely recite signing the response and shard thresholds in the context of machine-readable instructions without supplying any additional enabling structure or algorithm.
Similarly, the enablement deficiency for claim 19 is not remedied by dependent claim 20; although claim 20 adds signing and shard aggregation steps to claim 19’s processor-and-memory framework, it still lacks any concrete disclosure of the critical mechanisms—tokenization schemes, model architectures, training objectives, retrieval algorithms, or secure aggregation logic—required to enable a POSITA to practice the full scope of the claimed invention without undue experimentation.
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 1-20 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.
Regarding claim 1:
The phrase “large language model” is broad and undefined. In practice, LLMs differ dramatically in architecture (transformer, RNN, attention variants), size (millions to hundreds of billions of parameters), tokenization scheme, determinism of outputs (sampling parameters), API surface (sync vs. streaming), and extensibility (ability to fine-tune vs. only prompt-engineer). Because the specification gives no required characteristics, a POSITA cannot determine whether the claim requires a model of a minimum parameter count, a specific architecture that supports embedding exact bit sequences, or any other technical constraint. As a result, a wide range of software and hardware implementations could plausibly be read onto the term, creating uncertainty as to the metes and bounds of the claim.
The functional step “processing the request via a large language model to generate a response” lacks any algorithmic or structural boundaries. Reasonable interpretations include: (1) the LLM returns natural language text that constitutes the response; (2) the LLM returns a structured object or serialized binary representing a response; (3) the LLM triggers an external retrieval or algorithmic pipeline that actually produces the response; or (4) the LLM simply classifies the request and an external component constructs the response. The specification gives no cues to distinguish these alternatives (no API examples, no control flow diagrams, no pseudo-code), so a POSITA cannot determine which implementation variants fall within the claim scope.
The critical phrase “processing the key identifier via the large language model to retrieve a signature key” is especially indefinite because it combines two unresolved ambiguities (what the key identifier is and what “processing … via the LLM” means) and adds an ambiguous verb—“retrieve”—with many possible readings. “Retrieve” could mean: (A) the LLM emits the private key or a shard of it as a generated token sequence; (B) the LLM outputs a pointer that an external service resolves to key material; © the LLM produces evidence (e.g., a deterministic token) that, when combined with an offline algorithm, reconstructs the key; (D) the LLM activates an internal lookup table or side-channel that returns key bits; or (E) the LLM invokes a secure enclave or KMS that returns key material. These interpretations differ sharply in security, implementation, and scope, yet the specification contains no statement that disambiguates them or ties the claim to a single known mechanism. Without such a boundary, a POSITA cannot determine whether an accused product that, for example, returns only a pointer to an external keystore, literally “retrieves” the signature key as claimed.
Regarding claim 2, the recitation of “signing the response with the signature key to generate a signature; and sending the response and signature to the requestor” introduces the term “signature” without defining whether it must be a cryptographic digital signature, a symmetric message authentication code, or some other form of attestation, and “sending” is recited without any indication of the communication medium, protocol, or format. The absence of these boundaries leaves the scope of the claim uncertain to a person of ordinary skill in the art.
Regarding claim 9, the phrase “providing a public key to the requestor, the public key corresponding to the signature key” uses “public key” without specifying algorithm, format, or encoding, and “corresponding” is vague as to whether the relationship is mathematical, database-linked, or policy-based. The lack of definition renders the scope unclear.
Regarding claim 10, the step “authenticating the signature at the requestor using the public key” uses “authenticating” in a purely functional sense without specifying the method or criteria for authentication, and “using the public key” without identifying the cryptographic scheme or process, leaving multiple reasonable interpretations.
Regarding claim 13, the phrase “augmenting the response with co-signed information from an additional data source” introduces “augmenting” without explaining whether it means appending, merging, or replacing content, “co-signed information” without defining the signature scheme or format, and “additional data source” without limiting the nature or type of source, creating uncertainty in scope.
Regarding claim 14, the phrase “co-signed information is signed using a data source unique signature key” uses “data source unique signature key” without clarifying whether “unique” refers to uniqueness per source, per transaction, or per other criteria, and without specifying the type, format, or algorithm of the key, leaving the bounds of the claim unclear.
Regarding claim 16, the recitation of “signing the response with the signature key to generate a signature; and sending the response and signature to the requestor” repeats the same ambiguity introduced in claim 2 with respect to “signature” and “sending” in the context of a machine-readable storage device.
Regarding claim 20, the recitation of “signing the response with the signature key to generate a signature; and sending the response and signature to the requestor; and wherein the signature key comprises a plurality of key shards spread over the large language model … retrieving a threshold number of signature key shards; and aggregating the signature key shards to construct the signature key” combines the same ambiguities introduced in claims 2 and 3 with respect to “signature,” “sending,” “key shard,” “spread,” “threshold number,” and “aggregating” in the context of a device claim.
The indefiniteness issues identified in claim 1 apply equally to other independent claims in the application that recite substantially the same functional limitations and terminology, including independent claims 15 and 19. Each of these claims uses the same undefined and ambiguous terms such as “prompt,” “request,” “key identifier,” “large language model,” “processing … to generate a response,” “processing … to retrieve a signature key,” “retrieve,” and “signature key,” without providing structural, syntactic, semantic, or algorithmic boundaries in the specification. As with claim 1, a person of ordinary skill in the art would not be able to determine the metes and bounds of these claims with reasonable certainty, rendering them indefinite under 35 U.S.C. § 112(b).
The dependent claims do not overcome the indefiniteness deficiencies of their parent claims. Specifically, claims 2, 4, 6, 7, 8, 9, 10, 11, 12, 13, and 14 depend from claim 1 and merely add additional functional results, broad descriptive terms, or generic computing elements without supplying the missing definitions, structural detail, or algorithmic constraints needed to resolve the ambiguity in the parent claim. Similarly, claims 16 depend from claim 15, and claim 20 depends from claim 19, but these dependent claims likewise fail to provide any clarifying disclosure that would enable a person of ordinary skill in the art to determine the scope of the invention with reasonable certainty. Instead, they inherit the same indefinite terminology and functional recitations from their respective independent claims.
Accordingly, the indefiniteness rejections under § 112(b) for the independent claims apply equally to the dependent claims, as none of the dependent limitations cure the deficiencies of the parent claims. All claims remain indefinite for the reasons stated.
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.
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.
Claims 1, 2, 7, 9, 10, 11, 15, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Fairoze et al. ("Publicly-Detectable Watermarking for Language Models", (Year: 2023)) in view of Huang et al. (US-12158929-B1) and Wentz et al. (US-20200351098-A1).
With respect to claim 1, Fairoze teaches a computer implemented method comprising: receiving a prompt from a requestor for a large language model, (Page 3, 2.2 Entities: Users generate prompts which are sent to the model provider in exchange for the model output. Users may test text for the presence of a watermark by sending candidate text to the detector.);
the prompt including a request and [a key identifier;] (Under the broadest reasonable interpretation, the “key identifier” is met by the prompt itself, which inherently serves as the trigger that causes the large language model system to access its signing key for watermarking/signing; Page 3, § 2.1 Assumptions: “For any prompt ρ and tokens t, the new tokens t′ ← GenModelℓ(ρ, t) ∈ Tℓ were sampled from distributions with min-entropy at least α.” The prompt inherently contains the request for model output and functions as the identifier that initiates the signing process.)
processing the request via a large language model to generate a response; and (Page 3, 2.2 Entities: Model provider The model provider provides the LM service: given a prompt, it returns the LM output for that prompt for a given LM configuration. An honest model provider will run the watermarking protocol at text generation time. This entity has white-box access to the model weights in addition to any secret material specific to the watermarking protocol, e.g., a secret watermarking key.);
Fairoze does not disclose:
the prompt including a request and a key identifier;
processing the key identifier via the large language model to retrieve a signature key,
Fairoze does disclose a prompt containing a request, but Fairoze does not explicitly disclose a key identifier. However, Huang teaches the prompt including a request and a key identifier; (¶0657: A front-end client may send the static identifier an access token may be received. A front-end may send the static identifier and access token to a backend server.);
processing the key identifier via the large language model to retrieve a signature key, (¶0657: The static identifier may be validated by submitting the access token to an external authentication service. The private key may be generated using the static identifier and encryption salt received from a secure database.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Huang with regards of the prompt including a key identifier to the method of Fairoze in order to prevent forgery or fraudulent activities (Huang ¶0019-0011).
Fairoze in view of Huang does not disclose:
wherein the signature key comprises a plurality of key shards spread over the large language model and
wherein processing the key identifier via the large language model comprises: retrieving a threshold number of signature key shards; and aggregating the signature key shards to construct the signature key.
However, Wentz teaches wherein the signature key comprises a plurality of key shards spread over the large language model and wherein processing the key identifier via the large language model comprises: (¶0032: TPM 112 may have a hard-coded process for signing a digital signature, which may be performed using a private key, which is associated with a public key. This private key and/or signing process may be produced using a genuinely random process during manufacturing, and/or unique object (UNO) fingerprint, and/or a physically unclonable function (PUF), or any other disorder-based security primitive. ) retrieving a threshold number of signature key shards; and aggregating the signature key shards to construct the signature key. (¶0028:In embodiment, sharding may involve splitting a private key into several pieces or shards, so that each individual shard alone cannot be used to used to reconstruct the private key or perform other authentication and/or are present it is possible to reconstruct the private key. or example, without limitation and as an illustration, a private key may be split into five shards, but only three may be needed to reconstruct the private key. In an embodiment, transfer processing device 104, and/or receptacle device 124, acting as authenticating devices, may require one, a threshold number, or all of the shards to reconstruct the private key.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Wentz with regards of signature to the method of Fairoze in view of Huang in order to better authenticate the user (Wentz ¶0012).
With respect to claim 2, the combination of Fairoze in view of Huang and Wentz teaches the method of claim 1 (see rejection of claim 1 above) further comprising: signing the response with the signature key to generate a signature; and sending the response and signature to the requestor. (Huang ¶0089-0093: The Private Key 103, also known as a signing key, is securely stored in the Content Source Apparatus 100 and is used to create the digital signatures on the content data and other components of the secure content package In some embodiments, the Content Source Apparatus 100 may generate one or more digital signature using Private Key 103. he digital signatures are computed on a message comprising other components of the secure content package, such as the digital audiovisual content, the source entity information, and the content annotations. The digital signatures serve to authenticate the content data and the source entity, ensuring the integrity and authenticity of the secure content package. In some aspects, one or more of the computed digital signatures may serve to validate the account identity. For instance, an OAuth JSON Web Token (JWT) from an external secure account login may be used to validate the identity of the registered source entity.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Huang with regards of the signing the response with signature key to generate a signature to the method of Fairoze in view of Wentz in order to prevent forgery or fraudulent activities (Huang ¶0019-0011).
With respect to claim 7, the combination of Fairoze in view of Huang and Wentz teaches the method of claim 1 (see rejection of claim 1 above) disclose further comprising: validating the key identifier prior to sending the response and signature to the requestor. (Huang ¶0094: An authentication package comprising a static identifier and an access token may be received. A front-end client may send the static identifier and access token to a backend server. The static identifier may be validated by submitting the access token to an external authentication service. The private key may be generated using the static identifier and an encryption salt retrieved from a secure database.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Huang with regards of validating the key identifier to the method of Fairoze in view of Wentz in order to prevent forgery or fraudulent activities (Huang ¶0019-0011).
With respect to claim 9, the combination of Fairoze in view of Huang and Wentz teaches the method of claim 2 (see rejection of claim 2 above) further comprising providing a public key to the requestor, the public key corresponding to the signature key. (Huang ¶0023: The source identity 106 may contain information identifying the registered source entity that generated or owns the content. This information may include, but is not limited to, a unique identifier for the source, a username, an email address, a device ID, or a cryptographic public key associated with the source. ¶0080-0081: The registered source may comprise one or more physical cameras, physical devices, software applications, generative AI models, digital libraries, or user accounts. The type, identity, and public keys of the source are recorded in a remote database so that the data can be later retrieved using a source identifier. In some embodiments, the registered source stores, in a secure manner, a local private key (signature key) that corresponds to a recorded public key.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Huang with regards to the public key to the requestor to generate a signature to the method of Fairoze in view of Wentz in order to prevent forgery or fraudulent activities (Huang ¶0019-0011).
With respect to claim 10, the combination of Fairoze in view of Huang and Wentz teaches the method of claim 9 (see rejection of claim 9 above) further comprising authenticating the signature at the requestor using the public key. (Huang ¶0089: The Public Key 102 may be used by other components of the system, such as the Watermarking Apparatus 115 and the Verifier Apparatus 130, to authenticate the digital signatures included in the secure content package.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Huang with regards to the public key to the requestor to generate a signature to the method of Fairoze in view of Wentz in order to prevent forgery or fraudulent activities (Huang ¶0019-0011).
With respect to claim 11, the combination of Fairoze in view of Huang and Wentz teaches the method of claim 1 (see rejection of claim 1 above) but does not disclose further comprising: validating the key identifier prior to sending the response and signature to the requestor. (Huang ¶0094: An authentication package comprising a static identifier and an access token may be received. A front-end client may send the static identifier and access token to a backend server. The static identifier may be validated by submitting the access token to an external authentication service. The private key may be generated using the static identifier and an encryption salt retrieved from a secure database.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Huang with regards of validating the key identifier to the method of Fairoze in view of Wentz in order to prevent forgery or fraudulent activities (Huang ¶0019-0011).
With respect to claim 15, Fairoze teaches receiving a prompt from a requestor for a large language model, (Page 3, 2.2 Entities: Users generate prompts which are sent to the model provider in exchange for the model output. Users may test text for the presence of a watermark by sending candidate text to the detector.);
the prompt including a request and [a key identifier;] (Under the broadest reasonable interpretation, the “key identifier” is met by the prompt itself, which inherently serves as the trigger that causes the large language model system to access its signing key for watermarking/signing; Page 3, § 2.1 Assumptions: “For any prompt ρ and tokens t, the new tokens t′ ← GenModelℓ(ρ, t) ∈ Tℓ were sampled from distributions with min-entropy at least α.” The prompt inherently contains the request for model output and functions as the identifier that initiates the signing process.)
processing the request via a large language model to generate a response; and (Page 3, 2.2 Entities: Model provider The model provider provides the LM service: given a prompt, it returns the LM output for that prompt for a given LM configuration. An honest model provider will run the watermarking protocol at text generation time. This entity has white-box access to the model weights in addition to any secret material specific to the watermarking protocol, e.g., a secret watermarking key.);
Fairoze does not disclose:
a machine-readable storage device having instructions for execution by a processor of a machine to cause the processor to perform operations to perform a method, the operations comprising:
the prompt including a request and a key identifier;
processing the key identifier via the large language model to retrieve a signature key,
Fairoze does disclose a prompt containing a request, but Fairoze does not explicitly disclose a key identifier. However, Huang teaches a machine-readable storage device having instructions for execution by a processor of a machine to cause the processor to perform operations to perform a method, the operations comprising: (¶0027: According to another aspect of the present disclosure, a non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to perform a method of watermarking digital media is provided.);
the prompt including a request and a key identifier; (¶0657: A front-end client may send the static identifier an access token may be received. A front-end may send the static identifier and access token to a backend server.);
processing the key identifier via the large language model to retrieve a signature key, (¶0657: The static identifier may be validated by submitting the access token to an external authentication service. The private key may be generated using the static identifier and encryption salt received from a secure database.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Huang with regards of the prompt including a key identifier to the method of Fairoze in order to prevent forgery or fraudulent activities (Huang ¶0019-0011).
Fairoze in view of Huang does not disclose:
wherein the signature key comprises a plurality of key shards spread over the large language model and wherein processing the key identifier via the large language model comprises:retrieving a threshold number of signature key shards; andaggregating the signature key shards to construct the signature key.
However, Wentz teaches wherein the signature key comprises a plurality of key shards spread over the large language model and wherein processing the key identifier via the large language model comprises: (¶0032: TPM 112 may have a hard-coded process for signing a digital signature, which may be performed using a private key, which is associated with a public key. This private key and/or signing process may be produced using a genuinely random process during manufacturing, and/or unique object (UNO) fingerprint, and/or a physically unclonable function (PUF), or any other disorder-based security primitive. ) retrieving a threshold number of signature key shards; and aggregating the signature key shards to construct the signature key. (¶0028:In embodiment, sharding may involve splitting a private key into several pieces or shards, so that each individual shard alone cannot be used to used to reconstruct the private key or perform other authentication and/or are present it is possible to reconstruct the private key. or example, without limitation and as an illustration, a private key may be split into five shards, but only three may be needed to reconstruct the private key. In an embodiment, transfer processing device 104, and/or receptacle device 124, acting as authenticating devices, may require one, a threshold number, or all of the shards to reconstruct the private key.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Wentz with regards of signature to the method of Fairoze in view of Huang in order to better authenticate the user (Wentz ¶0012).
With respect to claim 16, the combination of Fairoze in view of Huang and Wentz teaches the method of device 15 (see rejection of claim 15 above) wherein the operations further comprise: signing the response with the signature key to generate a signature; and sending the response and signature to the requestor. (Huang ¶0089-0093: The Private Key 103, also known as a signing key, is securely stored in the Content Source Apparatus 100 and is used to create the digital signatures on the content data and other components of the secure content package In some embodiments, the Content Source Apparatus 100 may generate one or more digital signature using Private Key 103. he digital signatures are computed on a message comprising other components of the secure content package, such as the digital audiovisual content, the source entity information, and the content annotations. The digital signatures serve to authenticate the content data and the source entity, ensuring the integrity and authenticity of the secure content package. In some aspects, one or more of the computed digital signatures may serve to validate the account identity. For instance, an OAuth JSON Web Token (JWT) from an external secure account login may be used to validate the identity of the registered source entity.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Huang with regards of the signing the response with signature key to generate a signature to the method of Fairoze in view of Wentz in order to prevent forgery or fraudulent activities (Huang ¶0019-0011).
With respect to claim 19, Fairoze teaches receiving a prompt from a requestor for a large language model, (Page 3, 2.2 Entities: Users generate prompts which are sent to the model provider in exchange for the model output. Users may test text for the presence of a watermark by sending candidate text to the detector.);
the prompt including a request and [a key identifier]; (Page 3, 2.1 Assumptions: For any prompt ρ and tokens t, the new tokens t′ ← GenModelℓ(ρ, t) ∈ T ℓ were sampled from distributions with min-entropy at least α.);
processing the request via a large language model to generate a response; and(Page 3, 2.2 Entities: Model provider The model provider provides the LM service: given a prompt, it returns the LM output for that prompt for a given LM configuration. An honest model provider will run the watermarking protocol at text generation time. This entity has white-box access to the model weights in addition to any secret material specific to the watermarking protocol, e.g., a secret watermarking key.);
Fairoze does not disclose:
a device comprising: a processor; and a memory device coupled to the processor and having a program stored thereon for execution by the processor to perform operations comprising:
the prompt including a request and a key identifier;
processing the key identifier via the large language model to retrieve a signature key,
Fairoze does disclose a prompt containing a request, but Fairoze does not explicitly disclose a key identifier. However, Huang teaches a device comprising: a processor; and a memory device coupled to the processor and having a program stored thereon for execution by the processor to perform operations comprising: (¶0237: Referring to Figure 14, the system 900 is depicted as a computerized architecture for executing the methods of watermarking and processing digital audiovisual content. The system 900 includes a processing device 902, which may be a central processing unit (CPU), a graphics processing unit (GPU), or any other type of processing device capable of executing instructions. The processing device 902 is connected to a main memory 904 and a static memory 906, which store instructions 926 that are executed by the processing device 902.);
the prompt including a request and a key identifier; (¶0657: A front-end client may send the static identifier an access token may be received. A front-end may send the static identifier and access token to a backend server.);
processing the key identifier via the large language model to retrieve a signature key, (¶0657: The static identifier may be validated by submitting the access token to an external authentication service. The private key may be generated using the static identifier and encryption salt received from a secure database.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Huang with regards of the prompt including a key identifier to the method of Fairoze in order to prevent forgery or fraudulent activities (Huang ¶0019-0011).
Fairoze in view of Huang does not disclose:
wherein the signature key comprises a plurality of key shards spread over the large language model and wherein processing the key identifier via the large language model comprises:retrieving a threshold number of signature key shards; and aggregating the signature key shards to construct the signature key.
However, Wentz teaches wherein the signature key comprises a plurality of key shards spread over the large language model and wherein processing the key identifier via the large language model comprises: (¶0032: TPM 112 may have a hard-coded process for signing a digital signature, which may be performed using a private key, which is associated with a public key. This private key and/or signing process may be produced using a genuinely random process during manufacturing, and/or unique object (UNO) fingerprint, and/or a physically unclonable function (PUF), or any other disorder-based security primitive. ) retrieving a threshold number of signature key shards; and aggregating the signature key shards to construct the signature key. (¶0028:In embodiment, sharding may involve splitting a private key into several pieces or shards, so that each individual shard alone cannot be used to used to reconstruct the private key or perform other authentication and/or are present it is possible to reconstruct the private key. For example, without limitation and as an illustration, a private key may be split into five shards, but only three may be needed to reconstruct the private key. In an embodiment, transfer processing device 104, and/or receptacle device 124, acting as authenticating devices, may require one, a threshold number, or all of the shards to reconstruct the private key.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Wentz with regards of signature to the method of Fairoze in view of Huang in order to better authenticate the user (Wentz ¶0012).
With respect to claim 20, the combination of Fairoze in view of Huang and Wentz teaches the method of claim 19 (see rejection of claim 19 above) wherein the operations further comprise: signing the response with the signature key to generate a signature; and sending the response and signature to the requestor. (Huang ¶0089-0093: The Private Key 103, also known as a signing key, is securely stored in the Content Source Apparatus 100 and is used to create the digital signatures on the content data and other components of the secure content package In some embodiments, the Content Source Apparatus 100 may generate one or more digital signature using Private Key 103. he digital signatures are computed on a message comprising other components of the secure content package, such as the digital audiovisual content, the source entity information, and the content annotations. The digital signatures serve to authenticate the content data and the source entity, ensuring the integrity and authenticity of the secure content package. In some aspects, one or more of the computed digital signatures may serve to validate the account identity. For instance, an OAuth JSON Web Token (JWT) from an external secure account login may be used to validate the identity of the registered source entity.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Huang with regards of the signing the response with signature key to generate a signature to the method of Fairoze in view of Wentz in order to prevent forgery or fraudulent activities (Huang ¶0019-0011).
Claims 4 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Fairoze et al. ("Publicly-Detectable Watermarking for Language Models", (Year: 2023)) in view of Huang et al. (US-12158929-B1), Wentz et al. (US-20200351098-A1), and Amisano et al. (US-20210271963-A1) .
With respect to claim 4, the combination of Fairoze in view of Huang and Wentz teaches the method of claim 1 (see rejection of claim 1 above) but does not disclose wherein the large language model is trained with training data comprising the key identifier and a signature key shard such that signature key shards are retrieved responsive to the key identifier.
However, Amisano teaches wherein the large language model is trained with training data comprising the key identifier and a signature key shard such that signature key shards are retrieved responsive to the key identifier. (¶0037: Subsequent to training deep neural network model 222 using the selected and combined sets of sensitive data owned by different entities, trusted execution environment 218 sends the trained deep neural network to the client device of the user for use. ¶0052: In a preferred illustrative embodiment, all trusted execution environments that perform deep neural network training share a private key. This shared private key only exists inside authorized trusted execution environments. For example, one trusted execution environment internally generates a public/private key pair and shares the private key with the other trusted execution environments according to a private key sharing protocol. No mechanism is provided to move the private key outside of the trusted execution environments under any circumstances.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Amisano with regards to the training data to the large language model of Fairoze in view of Huang and Wentz in order to enable convenient, on-demand access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or interaction. (Amisano: ¶0002-0005).
With respect to claim 18, the combination of Fairoze in view of Huang in view of Wentz teaches the method of device 15 (see rejection of claim 15 above) but does not disclose wherein the large language model is trained with training data comprising the key identifier and a signature key shard such that signature key shards are spread over the large language model and are retrieved responsive to the key identifier.
However, Amisano teaches wherein the large language model is trained with training data comprising the key identifier and a signature key shard such that signature key shards are retrieved responsive to the key identifier. (¶0037: Subsequent to training deep neural network model 222 using the selected and combined sets of sensitive data owned by different entities, trusted execution environment 218 sends the trained deep neural network to the client device of the user for use. ¶0052: In a preferred illustrative embodiment, all trusted execution environments that perform deep neural network training share a private key. This shared private key only exists inside authorized trusted execution environments. For example, one trusted execution environment internally generates a public/private key pair and shares the private key with the other trusted execution environments according to a private key sharing protocol. No mechanism is provided to move the private key outside of the trusted execution environments under any circumstances.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Amisano with regards to the training data to the large language model of Fairoze in view of Huang and Wentz in order to enable convenient, on-demand access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or interaction. (Amisano: ¶0002-0005).
Claims 6 is rejected under 35 U.S.C. 103 as being unpatentable over Fairoze et al. ("Publicly-Detectable Watermarking for Language Models", (Year: 2023)) in view of Huang et al. (US-12158929-B1), Wentz et al. (US-20200351098-A1), and Corduan et al. (US-20190007205-A1).
With respect to claim 6, the combination of Fairoze in view of Huang and Wentz teaches the method of claim 1 (see rejection of claim 1 above) but does not disclose wherein the threshold number of signature key shards is greater than three.
However, Corduan teaches wherein the threshold number of signature key shards is greater than three. (¶0028: For example, a secret could be split into five shares so that the secret is only revealed when 3 or more shares are combined. The minimum number of shares to reveal the secret is called a threshold. The recovery method outlined here will use secret sharing to distribute shares of a wallet's private key. );
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Courduan with regards of a threshold number of signature key shards being greater than three to the method of Fairoze in view of Huang and Wentz in order to reduce private cryptography key access loss (Courduan ¶0006).
Claims 8 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Fairoze et al. ("Publicly-Detectable Watermarking for Language Models", (Year: 2023)) in view of Huang et al. (US-12158929-B1), Wentz et al. (US-20200351098-A1), and Noam et al. (US-20200374113-A1).
With respect to claim 8, the combination of Fairoze in view of Huang and Wentz teaches the method of claim 7 (see rejection of claim 7 above) but does not disclose wherein validating the key identifier comprises successfully retrieving a threshold number of key shards.
However, Noam teaches wherein validating the key identifier comprises successfully retrieving a threshold number of key shards. ( ¶0275-0282: At operation 990, one or more shares are received (e.g., shares of the secret/cryptographic key associated with the user identifier), e.g., from multiple nodes. In certain implementations, such shares can be decrypted (e.g., at the client) with the referenced private session key (e.g., as generated at operation 910). For example, the client receives/collects a threshold of sent shares, decrypts them with Ts, and acts upon them. Additionally, as noted, in certain implementations the described technologies can be implemented to initiate and/or execute operations pertaining to threshold signature(s). For example, the described technologies can be configured to sign data (e.g., a document or its hash) using the referenced secret/strong cryptographic key. For example, the system can be used to sign a piece of data B (e.g., a document, etc.) with the stored secret upon receiving or otherwise determining that a defined threshold of signatures complying with the required signature scheme has been met (successfully retrieving threshold number of key shares). );
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Noam with regards of validating the key identifier comprises successfully retrieving number of key shares to the method of Fairoze in view of Huang and Wentz in order to reduce confirmation time and increase throughput of a decentralized application systems (Noam ¶0037-0038).
With respect to claim 12, the combination of Fairoze in view of Huang and Wentz teaches the method of claim 11 (see rejection of claim 11 above), but does not disclose
However, Noam teaches wherein validating the key identifier comprises finding the key identifier in a table of authorized key identifiers. (¶0269-0270: In certain implementations, such a challenge can be generated in accordance with an authentication protocol associated with the user identifier (e.g., authentication protocol (AP′) 844A as stored in database 840, which is associated with user ID 842A corresponding to user 860). ¶0256-0257: Authentication engine 830 can be an application that configures/enables the node to implement various authentication protocols, e.g., as described in detail herein. Database 840 can be a storage resource such as an object-oriented database, a relational database, a non-relational database (e.g., NoSQL) that stores various information pertaining to the referenced authentication protocols, as described herein. );
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Noam with regards of validating the key identifier to the method of Fairoze in view of Huang and Wentz in order to reduce confirmation time and increase throughput of a decentralized application systems (Noam ¶0037-0038).
Claims 13 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Fairoze et al. ("Publicly-Detectable Watermarking for Language Models", (Year: 2023)) in view of Huang et al. (US-12158929-B1), Wentz et al. (US-20200351098-A1), and Norton JR. et al. (US-20250112925-A1).
With respect to claim 13, the combination of Fairoze in view of Huang and Wentz teaches the method of claim 2 (see rejection of claim 2 above) but does not disclose further comprising: augmenting the response with co-signed information from an additional data source.
However, Norton JR. teaches further comprising: augmenting the response with co-signed information from an additional data source. ( ¶0045: During an active login attempt, if the data obtained from more than two of the user data sources is not consistent with the person being the authorized user associated with the user profile containing the submitted credentials, then the security system may require a second user to authorize, corroborate or co-sign the authentication process.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Norton JR. with regards to co-signed information to the method of Fairoze in view of Huang and Wentz in order to protect a digital sign data structure from unauthorized access (Norton JR. ¶0017).
With respect to claim 14, the combination of Fairoze in view of Huang, Wentz, and Norton JR. teaches the method of claim 13 (see rejection of claim 13 above) wherein the co-signed information is signed using a data source unique signature key. (Armleder ¶0233: For example, the second user could be a system administrator, the user's direct manager, or any user with higher credentials than the person performing the login attempt. In one option, the security system may send a message to the second user and request that they login (authenticate) to the system (unique signature key), then authorize the active login attempt of the person or otherwise authenticate that the person is the authorized user associated with the user profile with the received user credentials.);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Norton JR. with regards to co-signed information to the method of Fairoze in view of Huang and Wentz in order to protect a digital sign data structure from unauthorized access (Norton JR. ¶0017).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAYLOR P VU whose telephone number is (703)756-1218. The examiner can normally be reached MON - FRI (7:30 - 5:00).
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, Alexander Lagor can be reached at (571) 270-5143. 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.
/T.P.V./ Examiner, Art Unit 2437
/MENG LI/ Primary Examiner, Art Unit 2437
Prosecution Insights