DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to the communication filed on 10/31/2024.
Claims 1-20 are pending.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) ELEMENT IN CLAIM FOR A COMBINATION.—An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term "means" or "step" or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term "means" or "step" or the generic placeholder is modified by functional language, typically, but not always linked by the transition word "for" (e.g., "means for") or another linking word or phrase, such as "configured to" or "so that"; and
(C) the term "means" or "step" or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word "means" (or "step") in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word "means" (or "step") in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word "means" (or "step") are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word "means" (or "step") are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word "means," but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitations use a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are: first computing device is (further) configured to, and second computing device is (further) configured to as recited in claims 1-2, 5-6, 9-12, 14-16, and 18 respectively.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. A review of the specification shows that the following appears to be the corresponding structure described in the specification for the 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph limitations: e.g., figs. 1-6, and [0006]-[0026], [0041], [0061], [0095] of the specification.
If applicant does not intend to have these limitations interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitations to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitations recite sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Objections
Claims 17 and 20 are objected to because of the following informalities:
There is insufficient antecedent basis for the limitation “the verification identifier” as recited in claim 17. For the purpose of examination, the verification identifier has been interpreted as referring to any verification identifier.
For the purpose of examination, claim 20 has been interpreted as an independent claim, claim 20 should be amended to include all the steps recited in claim 19 (instead of reciting “to perform the method of claim 19”).
Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim does not fall within at least one of the four categories of patent eligible subject matter because “A computer program” as recited in claim 20 is not defined in the specification, and for purposes of examination, the term has been interpreted as encompassing software per se, which is not statutory.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-11, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Momchilov et al. (US 2021/0234853) in view of Guccione et al. (US 2023/0041959).
Claim 1, Momchilov teaches:
A system for providing secure access to a digital asset, the system comprising:
a first computing device operating in an offline environment, wherein the first computing device is configured to generate an access control object comprising at least an access control identifier associated with an access policy of a client; and (e.g., figs. 4-5, [0097], “FIG. 5 depicts another example implementation 500 of a logical shared secret vault 520 in accordance with one or more illustrative aspects discussed herein. FIG. 5 illustrates a similar logical shared vault design as FIG. 4. In FIG. 5, the key management may be performed in a similar manner, however the per-app secrets may be stored in application-specific storage 548a, 548b, and 548c, separate from the rest of the vault assets. For example, the vault key records 532, 534, and 536 may be stored in vault record keeping section 530 of unsecured shared application memory 505, and the shared secrets 546 may be stored in vault database 540 of unsecured shared application memory 505, while the application-specific secrets 548a, 548b, 548c may be stored in reserved and/or isolated application memory…The design illustrated in FIG. 5 may provide additional security benefits as it avoids a single point of attack holding all assets…In addition, the split-storage vault design may allow for different types of memory to be used for the different assets in accordance with different security and user experience preferences and policies. Use of different types of memory and the advantages thereof are discussed further below” [0098], “Otherwise, like-named components of FIG. 5 may operate in similar manner to that described above with regard to FIG. 4. Shared memory 505, shared vault 520, vault record keeping section 530, and vault database 540 may store similar information and operate similarly to their counterparts in FIG. 4…Applications 510a, 510i, 510n may correspond to Applications 410a, 410i, and 410n of FIG. 4. Passcode/Authentication UIs 512a, 512i, and 512n and application specific memory 514a, 514i, and 514n may store similar information and operate similarly to their counterparts in FIG. 4” [0166], “An off-line device may continue to update a local cached copy of the vault…Such an arrangement may be useful to provide a seamless restore point on client OSs where local persistent shared storage is available but may be accidentally wiped by another app” [0092], “The vault database may further store per app secrets 448a, 448b, and 448c which may be further encrypted with application specific entropy and/or application specific keys. Per-app secrets 448 may include S1 and S2 information, certificates, STA tickets, and/or policies for a particular application”: shared memory/storage 505 operates locally/offline; vault key records 532, 534, 536 comprising at least the vault key (and/or application specific key), the vault key (and/or application specific key) is associated with the per-app policies because the per-app policies of the per-app secrets are encrypted using at least the vault key (and/or application specific key))
a second computing device operating in an online environment, wherein the second computing device is configured to generate at least one vault object associated with the access control object, the vault object comprising: (e.g., figs. 4-5, [0097], “FIG. 5 illustrates a similar logical shared vault design as FIG. 4. In FIG. 5, the key management may be performed in a similar manner, however the per-app secrets may be stored in application-specific storage 548a, 548b, and 548c…the vault key records 532, 534, and 536 may be stored in vault record keeping section 530 of unsecured shared application memory 505…while the application-specific secrets 548a, 548b, 548c may be stored in reserved and/or isolated application memory” [0098], “Otherwise, like-named components of FIG. 5 may operate in similar manner to that described above with regard to FIG. 4. Shared memory 505, shared vault 520, vault record keeping section 530, and vault database 540 may store similar information and operate similarly to their counterparts in FIG. 4…Applications 510a, 510i, 510n may correspond to Applications 410a, 410i, and 410n of FIG. 4. Passcode/Authentication UIs 512a, 512i, and 512n and application specific memory 514a, 514i, and 514n may store similar information and operate similarly to their counterparts in FIG. 4” fig. 6, [0105], “Each figure is illustrated as including enterprise server 601, master application 602, application i 603, application n 604, shared memory/storage 605, and secure application wrapper 606”: application wrapper comprising app 1, app i, app N operates online and accesses enterprise resources of enterprise server via the network; elements stored in 510a of app 1, 510i of app i, 510n of app N are associated with the vault key records 532, 534, 536)
a first dataset comprising at least the access control identifier; and (e.g., figs. 4-5, [0097], “FIG. 5 illustrates a similar logical shared vault design as FIG. 4. In FIG. 5, the key management may be performed in a similar manner, however the per-app secrets may be stored in application-specific storage 548a, 548b, and 548c” [0092], “The vault database may further store per app secrets 448a, 448b, and 448c which may be further encrypted with application specific entropy and/or application specific keys. Per-app secrets 448 may include S1 and S2 information, certificates, STA tickets, and/or policies for a particular application”: dataset device entropy, vault key, application specific keys comprising at least the vault key (and/or application specific key) for encryption)
a vault identifier, wherein the vault identifier is calculated in dependence on the first dataset; (e.g., figs. 4-5, [0097], “FIG. 5 illustrates a similar logical shared vault design as FIG. 4. In FIG. 5, the key management may be performed in a similar manner, however the per-app secrets may be stored in application-specific storage 548a, 548b, and 548c”: encrypted per-app secrets of 548a, 548b, or 548c is calculated based on at least the vault key (and/or application specific key))
wherein the first computing device is further configured to generate at least one digital asset object associated with the vault object, the digital asset object comprising a digital asset. (e.g., figs. 4-5, [0098], “like-named components of FIG. 5 may operate in similar manner to that described above with regard to FIG. 4” [0095], “The SSO key 442 may be used…to generate a second vault key record 436 comprising the vault key encrypted using the SSO key 442. This second vault key record 436 may be stored in the vault record keeping section 430”: a second vault key record 436/536 stored in the local storage 405/505 is associated with at least the vault key (and/or application specific key) and comprises the encrypted vault key)
Momchilov teaches the vault identifier and the digital asset object comprising a digital asset (see above) and does not appear to explicitly teach but Guccione teaches:
a digital asset object comprising a digital asset and a vault identifier. (e.g., [0041], “A user may create and share secrets using the secrets vault client application 106 on the secrets vault client device 102. Secrets and other data that is intended to be maintained securely may be stored locally in the local vault 105. The secrets may be encrypted before storing in the local vault 105” [0060], “The user may invoke functions of the secrets vault program on the secrets vault client device 102 to create the shared folder, which may also generate a shared folder key. The shared folder may contain individual secret records, which may then be encrypted using the shared folder key. In another embodiment, the shared folder key may include individual secret records, which may each be encrypted by a records key. The records key may be encrypted using the shared folder key when the secrets record and its corresponding records key are contained in the shared folder” [0068], “the secrets vault client device 102 generates the 256-bit AES access token…each access token is hashed using a hashing algorithm to generate a client identifier identifying the sharing client device corresponding to the access token”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings described by Guccione into the invention of Momchilov, and the motivation for such an implementation would be for the purpose of sharing secrets without cumbersome configurations (Guccione [0004]-[0006]).
Claim 2, Momchilov-Guccione teaches:
wherein the second computing device is further configured to calculate the vault identifier by inputting the first dataset to a hash function. (e.g., Momchilov figs. 4-5, [0092], [0097]; Guccione [0068]-[0069]) Same motivation as presented in claim 1 applies.
Claim 3, Momchilov-Guccione teaches:
wherein the first dataset further comprises a client identifier uniquely identifying the client. (e.g., Momchilov figs. 4-5, [0092], [0097]-[0098])
Claim 4, Momchilov-Guccione teaches:
wherein the access control object further comprises the client identifier. (e.g., Momchilov figs. 4-5, [0092]-[0093], [0097]-[0098])
Claim 5, Momchilov-Guccione teaches:
wherein the first computing device is configured to integrity protect the access control object and/or the digital asset object using one or more integrity cryptographic keys stored in the offline environment, wherein the first computing device is optionally configured to apply a digital signature or hash-based message authentication code (HMAC) to the access control object. (e.g., Momchilov figs. 4-5, [0093]-[0096])
Claim 6, Momchilov-Guccione teaches:
wherein the first computing device is further configured to encrypt the digital asset using an encryption key stored in the offline environment, wherein the encryption is optionally an authenticated encryption process. (e.g., Momchilov figs. 4-5, [0093]-[0096])
Claim 7, Momchilov-Guccione teaches:
wherein the digital asset comprises a cryptographic key for digitally signing cryptographic operations. (e.g., Momchilov figs. 4-5, [0095], [0098])
Claim 8, Momchilov-Guccione teaches:
wherein the access control object further comprises the access policy associated with the client, wherein the access policy is indicative of one or more authorisation checks for using a digital asset associated with the client. (e.g., Momchilov figs. 4-5, [0067], [0069], [0092], [0106])
Claim 9, Momchilov-Guccione teaches:
wherein the second computing device is configured to generate a plurality of vault objects associated with the access control object. (e.g., Momchilov figs. 4-5, [0097]-[0098], [0105])
Claim 10, Momchilov-Guccione teaches:
wherein the first computing device is configured to generate a plurality of digital asset objects associated with the vault object. (e.g., Momchilov figs. 4-5, [0095], [0097]-[0098])
Claim 11, Momchilov-Guccione teaches:
wherein the first computing device is configured to authorise access to the digital asset contained in the digital asset object in dependence on the first dataset contained in the vault object. (e.g., Momchilov figs. 4-5, [0094]-[0096], [0098])
Claim 15, Momchilov-Guccione teaches:
wherein the first computing device is further configured to evaluate the integrity of the access control object and digital asset object using one or more integrity cryptographic key stored in the offline environment. (e.g., Momchilov figs. 4-5, [0094]-[0096], [0098])
Claim 16, Momchilov-Guccione teaches:
wherein the first computing device is further configured to verify that the first dataset of the received vault object comprises the access control identifier associated with the access policy. (e.g., Momchilov figs. 4-5, [0092]-[0096])
Claim 17, Momchilov-Guccione teaches:
wherein the verification identifier is calculated by inputting the first dataset of the received vault object to a hash function. (e.g., Momchilov [0088])
Claim 18, Momchilov-Guccione teaches:
wherein the digital asset comprises a cryptographic key for digitally signing cryptographic operations, and wherein the first computing device is further configured to digitally sign a cryptographic operation using the cryptographic key of the digital asset object. (e.g., Momchilov figs. 4-5, [0094]-[0096])
Claim 19, this claim is directed to a method containing similar limitations as recited in claim 1 and is rejected using the same rationale to combine the references.
Claim 20, this claim is directed to a computer program containing similar limitations as recited in claim 1 and is rejected using the same rationale to combine the references.
Allowable Subject Matter
Claims 12-14 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: US 2019/0268165 discloses techniques for secure storage and retrieval of information.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIE C LIN whose telephone number is (571)272-7752. The examiner can normally be reached M-F 9:00AM -5:00PM.
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, GELAGAY SHEWAYE can be reached at (571)272-4219. 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.
/AMIE C. LIN/Primary Examiner, Art Unit 2436
Prosecution Insights