DETAILED ACTION
Responsive to the Applicant reply filed on 05/01/2025, Applicant' s amendments to claims have been entered and respective arguments carefully considered and responded in following:
On this Office Action, claims 1-20, consisting of independent claims 1, 8 and 15.
Claims 1-20 are pending.
Claims 1-20 are rejected under the 35 USC § 103.
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 .
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 05/01/2025 has been entered.
Response to Amendment
The amendment filed 05/01/2025 has been entered.
Claims 1, 8 and 15 have been amended.
Response to Arguments
With respect to the Claim Rejections - 35 USC § 103:
Applicants arguments, see amended independent claims and Applicant’s Remarks regarding the newly added limitation have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. Upon further consideration, a new ground of rejection is presented in this Office Action. For a comprehensive understanding of rejection, please refer to the 35 U.S.C. § 103 section below.
With respect to the Double Patenting Rejection:
The examiner confirms that the applicant has filed a Terminal Disclosure for Application No. 17/898,382, and that the Terminal Disclaimer has been recorded. Accordingly, Applicant’s arguments have been fully considered and are persuasive. The rejection is therefore withdrawn.
With respect to the Claim Rejections - 35 USC § 112:
Applicant’s arguments have been fully considered and are persuasive. The rejection is therefore withdrawn.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 4, 6-9, 11, 13-16, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Murray (US 20220263655 A1) in view of Erickson et al. (US 20220124078 A1, hereinafter “Erickson”) in view of Patil et al. (US 20200389869 A1, hereinafter “Patil”).
Regarding independent claim 1, (Currently Amended) Murray discloses a method comprising:
generating, by the KMS, a digital certificate using the public key of the client device (Murray: [0081] It is often the case that a customer-owned KMS/KMIP server is its own certificate authority (CA) that issues digital certificates to the components/modules/servers connected to system 200 (“generating, by the KMS, a digital certificate”); [0095]The public key is incorporated into a digital or public key certificate for KMS 108 that is digitally signed by CA 122 (“using public key of the client device”));
storing, by the user device, the digital certificate in a storage device of a cloud service (Murray: [0104] CA 122 (“user device”) also issues digital certificates for storage resources/items 202A-D, and specifically to their respective hosts, … , cloud storage management system 218C);
Although Murray discloses, in paragraph [0100], “the public key of CA 122 is known by every “client” module in the system,” it does not teach “transmitting, by a user device, a public key of a client device to a key management server; generating, by the client device, a signed command to access the storage device, the signed command signed using a private key corresponding to the public key of the client device; and issuing, by the client device, the signed command to the storage device to access data stored by the storage device.”
In a same field of endeavor Erickson discloses the method, wherein transmitting, by a user device, a public key of a client device to a key management server (KMS) (Erickson: [0042] user device 204(1) has received public key 218(2) of user device 204(2) and may share public key 218(2) with intermediary device 208 (analogous to “key management server” and cured by Murray above)).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the key-metadata based encrypted storage management system disclosed by Murray with the teachings of Erickson to transmit, by a user device, a public key of a client device to a key management server. One of ordinary skill in the art would have been motivated to make this modification because the system rather than simply sending public key to intermediary device, user device may sign an message using private key, indicating that public key is to be trusted in association with the user account (para.0042).
Although Murray discloses, in paragraph [0087], “a cloud storage management system or host 218C,” it does not teach “generating, by the client device, a signed command to access the storage device, the signed command signed using a private key corresponding to the public key of the client device; and issuing, by the client device, the signed command to the storage device to access data stored by the storage device.”
Erickson further discloses the method, wherein generating, by the client device, a signed command to access the storage device, the signed command signed using a private key corresponding to the public key of the client device (Erickson: [0036] User device 204(1) may send public key 218(1) (“public key of the client device”) to the intermediary device 208. Intermediary device 208 (analogous to “key management server” and cured by Murray above) may associate the public key 218(1) with the user device 204(1) and/or with the user account. Intermediary device 208 may also hold the public key 218(1) in storage 224. In some cases, storage 224 may represent cloud storage for the cloud authenticator. Since the cloud authenticator now has access to public key 218(1), the cloud authenticator will be able to verify future messages received from user device 204(1) that are signed with the corresponding private key 220(1) of the keypair (“the signed command signed using a private key”). As such, Step 1 of FIG. 2A may represent a “trust on first use” type arrangement; [0037] The message 226A may be signed with the private key 220(1) (“the signed command signed using a private key”), and therefore the cloud authenticator may trust that the message 226A is coming from user device 204(1) and that user device 204(1) is under control of the user);
issuing, by the client device, the signed command to the storage device to access data stored by the storage device (Erickson: [0036] Since the cloud authenticator now has access to public key 218(1), the cloud authenticator will be able to verify future messages received from user device 204(1) that are signed with the corresponding private key 220(1) (“issuing, by the client device, the signed command”) of the keypair. As such, Step 1 of FIG. 2A may represent a “trust on first use” type arrangement; [0037] The message 226A (“signed command”) may be signed with the private key 220(1), and therefore the cloud authenticator may trust that the message 226A is coming from user device 204(1) and that user device 204(1) is under control of the user); and
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the key-metadata based encrypted storage management system disclosed by Murray with the teachings of Erickson to generate, by the client device, a signed command to access the storage device, the signed command signed using a private key corresponding to the public key of the client device; and issue, by the client device, the signed command to the storage device to access data stored by the storage device. One of ordinary skill in the art would have been motivated to make this modification because the cloud authenticator will be able to verify future messages received from user device that are signed with the corresponding private key of the keypair. This may represent a “trust on first use” type arrangement (para.0036).
Although Erickson discloses, in paragraph 0048,“items in storage 224 of the cloud authenticator and/or storage 228 at any of user devices 204 may be updated, removed, replaced, edited, moved, etc.,” it does not teach “validating, by the storage device, the signed command using the public key included in the digital certificate.”
In a same field of endeavor, Patil discloses the method, wherein validating, by the storage device, the signed command using the public key included in the digital certificate (Patil: [0106] In some implementations, each client device may generate its own private key locally (and determine a public key based on that generated private key). The client device can then send its public key to the cloud service during an installation, configuration or subscription setup so that a certificate with that public key can be digitally signed. For example, the client device's certificate may be signed by a public key of the cloud service. An uplink communication from the client device may include the signed certificate or signature that can be validated using a public key of the cloud service).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the cloud storage for the cloud authenticator disclosed by Erickson with the teachings of Patil to validate, by the storage device, the signed command using the public key included in the digital certificate. One of ordinary skill in the art would have been motivated to make this modification because the obtained the public key of the cloud service via an intermediate proxy server may maintain or manage relationships with various remote destination networks (para.[0106]). Therefore, using public keys in cloud systems provides strong security through confidentiality, authenticity, and integrity, enabling secure key exchange, digital signatures for identity verification.
Regarding claim 2, (Previously Presented) the combination of Murray, Erickson and Patil teaches all elements of the current invention as stated above. Murray discloses the method of claim 1, wherein generating the digital certificate using the public key of a client device comprises
generating, by the KMS, the digital certificate by using the public key of the client device as a Subject Public Key and signing the digital certificate using a KMS private key (Murray: [0081] It is often the case that a customer-owned KMS/KMIP server is its own certificate authority (CA) that issues digital certificates to the components/modules/servers connected to system 200 (“generating, by the KMS, a digital certificate”). In such a scenario, internal CA 122 is not needed and if present, can be turned off; [0099] CA 122 creates a digital certificate for KMS 102, which is preferably in X.509 format (“Subject Public Key”); [0102] CA 122 also issues a signed digital certificate to console server 112 containing the public key of the console server (“Subject Public Key”)).
Regarding claim 4, (Original) the combination of Murray, Erickson and Patil teaches all elements of the current invention as stated above. Patil discloses the method of claim 1, wherein storing the digital certificate in a storage device of a cloud service further comprises
setting at least one access permission based on the digital certificate (Patil: [0106] The connectivity unit 124 of the AP 102 receiving the uplink communication may verify that there is a certificate signed by the public key of the cloud service that the AP 102 trusts. Thus, before forwarding an uplink communication, the connectivity unit 124 may perform a source authentication to verify that the client device (such as wireless device 144) is authorized to communicate with the remote destination network 140).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the cloud storage for the cloud authenticator disclosed by Erickson with the teachings of Patil to set at least one access permission based on the digital certificate. One of ordinary skill in the art would have been motivated to make this modification because the obtained the public key of the cloud service via an intermediate proxy server may maintain or manage relationships with various remote destination networks (para.[0106]). Therefore, using public keys in cloud systems provides strong security through confidentiality, authenticity, and integrity, enabling secure key exchange, digital signatures for identity verification.
Regarding claim 6, (Previously Presented) the combination of Murray, Erickson and Patil teaches all elements of the current invention as stated above. Patil discloses the method of claim 1, further comprising
receiving, by the storage device, the signed command and validating the signed command by validating a digital signature included in the signed command using a public key included in the digital certificate (Patil: [0106] In some implementations, each client device may generate its own private key locally (and determine a public key based on that generated private key). The client device can then send its public key to the cloud service during an installation, configuration or subscription setup so that a certificate with that public key (“public key included in the digital certificate”) can be digitally signed. For example, the client device's certificate may be signed (“signed command”) by a public key of the cloud service. An uplink communication from the client device may include the signed certificate or signature that can be validated using a public key of the cloud service).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the cloud storage for the cloud authenticator disclosed by Erickson with the teachings of Patil to receive, by the storage device, the signed command and validating the signed command by validating a digital signature included in the signed command using a public key included in the digital certificate. One of ordinary skill in the art would have been motivated to make this modification because the obtained the public key of the cloud service via an intermediate proxy server may maintain or manage relationships with various remote destination networks (para.[0106]). Therefore, using public keys in cloud systems provides strong security through confidentiality, authenticity, and integrity, enabling secure key exchange, digital signatures for identity verification.
Regarding claim 7, (Original) the combination of Murray, Erickson and Patil teaches all elements of the current invention as stated above. Patil discloses the method of claim 6, further comprising:
returning, by the storage device, data responsive to the signed command; and processing, by the client device, the data (Patil: [0106] For example, the client device's certificate may be signed by a public key of the cloud service. An uplink communication from the client device may include the signed certificate or signature that can be validated using a public key of the cloud service. … Thus, before forwarding an uplink communication, the connectivity unit 124 may perform a source authentication to verify that the client device (such as wireless device 144) is authorized to communicate with the remote destination network 140).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the cloud storage for the cloud authenticator disclosed by Erickson with the teachings of Patil to return, by the storage device, data responsive to the signed command; and process, by the client device, the data. One of ordinary skill in the art would have been motivated to make this modification because the obtained the public key of the cloud service via an intermediate proxy server may maintain or manage relationships with various remote destination networks (para.[0106]). Therefore, using public keys in cloud systems provides strong security through confidentiality, authenticity, and integrity, enabling secure key exchange, digital signatures for identity verification.
Regarding independent claim 8, (Currently Amended) it is a non-transitory computer-readable storage medium claim that corresponds to claim 1. Therefore, the claim is rejected for at least the same reasons as the method of claim 1.
Regarding claim 9, (Previously Presented) it is a non-transitory computer-readable storage medium claim that corresponds to claim 2. Therefore, the claim is rejected for at least the same reasons as the method of claim 2.
Regarding claim 11, (Original) it is a non-transitory computer-readable storage medium claim that corresponds to claim 4. Therefore, the claim is rejected for at least the same reasons as the method of claim 4.
Regarding claim 13, (Previously Presented) it is a non-transitory computer-readable storage medium claim that corresponds to claim 6. Therefore, the claim is rejected for at least the same reasons as the method of claim 6.
Regarding claim 14, (Original) it is a non-transitory computer-readable storage medium claim that corresponds to claim 7. Therefore, the claim is rejected for at least the same reasons as the method of claim 7.
Regarding independent claim 15, (Currently Amended) Murray discloses a system comprising (Fig. 3):
a key management server (KMS) (Murray: Fig. 3, key management server (KMS) 108);
a storage device (Murray: Fig.3, Cloud storage management server/system/host 218 and 202C);
a client device associated with a public key (Murray: Fig.3, certificate authority (CA) 122); [0095]The public key is incorporated into a digital or public key certificate for KMS 108 that is digitally signed by CA 122; and
a user device, the user device having access to the storage device via a network (Murray: Fig.3, console server 112 provides the ability to an admin via its user interfaces 214A-B; [0123] Based on key-metadata stored in the respective KMSes, either of the user interfaces 214A-B of console server 112 provide an overall view or list of encrypted storage resources 202A, 202B1-2, 202C, 224B and 224C for an admin based on the instant design),
the KMS configured to generate a digital certificate using the public key of the client device in response to the public key of the client device (Murray: [0081] It is often the case that a customer-owned KMS/KMIP server is its own certificate authority (CA) that issues digital certificates to the components/modules/servers connected to system 200 (“generating, by the KMS, a digital certificate”); [0095]The public key is incorporated into a digital or public key certificate for KMS 108 that is digitally signed by CA 122 (“using public key of the client device”)), and
store the digital certificate in a storage device of a cloud service (Murray: [0104] CA 122 (“user device”) also issues digital certificates for storage resources/items 202A-D, and specifically to their respective hosts, … , cloud storage management system 218C).
However, Murray does not teach, Erickson, in a same field of endeavor, discloses the system, wherein the user device is configured to
transmit the public key of the client device to the KMS (Erickson: [0042] user device 204(1) has received public key 218(2) of user device 204(2) and may share public key 218(2) with intermediary device 208 (analogous to “key management server” and cured by Murray above)).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the key-metadata based encrypted storage management system disclosed by Murray with the teachings of Erickson to transmit the public key of a client device to the KMS. One of ordinary skill in the art would have been motivated to make this modification because the system rather than simply sending public key to intermediary device, user device may sign an message using private key, indicating that public key is to be trusted in association with the user account (para.0042).
Erickson further discloses the system, wherein the client device is configured to:
generate a signed command to access the storage device, the signed command signed using a private key corresponding to the public key of the client device (Erickson: [0036] User device 204(1) may send public key 218(1) (“public key of the client device”) to the intermediary device 208. Intermediary device 208 (analogous to “key management server” and cured by Murray above) may associate the public key 218(1) with the user device 204(1) and/or with the user account. Intermediary device 208 may also hold the public key 218(1) in storage 224. In some cases, storage 224 may represent cloud storage for the cloud authenticator. Since the cloud authenticator now has access to public key 218(1), the cloud authenticator will be able to verify future messages received from user device 204(1) that are signed with the corresponding private key 220(1) of the keypair (“the signed command signed using a private key”). As such, Step 1 of FIG. 2A may represent a “trust on first use” type arrangement; [0037] The message 226A may be signed with the private key 220(1) (“the signed command signed using a private key”), and therefore the cloud authenticator may trust that the message 226A is coming from user device 204(1) and that user device 204(1) is under control of the user); and
issue the signed command to the storage device to access data stored by the storage device (Erickson: [0036] User device 204(1) may send public key 218(1) (“public key of the client device”) to the intermediary device 208. Intermediary device 208 (analogous to “key management server” and cured by Murray above) may associate the public key 218(1) with the user device 204(1) and/or with the user account. Intermediary device 208 may also hold the public key 218(1) in storage 224. In some cases, storage 224 may represent cloud storage for the cloud authenticator. Since the cloud authenticator now has access to public key 218(1), the cloud authenticator will be able to verify future messages received from user device 204(1) that are signed with the corresponding private key 220(1) of the keypair (“the signed command signed using a private key”). As such, Step 1 of FIG. 2A may represent a “trust on first use” type arrangement; [0037] The message 226A may be signed with the private key 220(1) (“the signed command signed using a private key”), and therefore the cloud authenticator may trust that the message 226A is coming from user device 204(1) and that user device 204(1) is under control of the user).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the key-metadata based encrypted storage management system disclosed by Murray with the teachings of Erickson to generate a signed command to access the storage device, the signed command signed using a private key corresponding to the public key of the client device; and issue the signed command to the storage device to access data stored by the storage device. One of ordinary skill in the art would have been motivated to make this modification because the cloud authenticator will be able to verify future messages received from user device that are signed with the corresponding private key of the keypair. This may represent a “trust on first use” type arrangement (para.0036).
However, the combination does not teach, Patil, in a same field of endeavor, discloses the system,
wherein the storage device is configured to validate the signed command using the public key included in the digital certificate (Patil: [0106] In some implementations, each client device may generate its own private key locally (and determine a public key based on that generated private key). The client device can then send its public key to the cloud service during an installation, configuration or subscription setup so that a certificate with that public key can be digitally signed. For example, the client device's certificate may be signed by a public key of the cloud service. An uplink communication from the client device may include the signed certificate or signature that can be validated using a public key of the cloud service).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the cloud storage for the cloud authenticator disclosed by Erickson with the teachings of Patil to include the storage device that is configured to validate the signed command using the public key included in the digital certificate. One of ordinary skill in the art would have been motivated to make this modification because the obtained the public key of the cloud service via an intermediate proxy server may maintain or manage relationships with various remote destination networks (para.[0106]). Therefore, using public keys in cloud systems provides strong security through confidentiality, authenticity, and integrity, enabling secure key exchange, digital signatures for identity verification.
Regarding claim 16, (Original) it is a system claim that corresponds to claim 2. Therefore, the claim is rejected for at least the same reasons as the method of claim 2
Regarding claim 18, (Original) it is a system claim that corresponds to claim 4. Therefore, the claim is rejected for at least the same reasons as the method of claim 4.
Regarding claim 20, (Previously Presented) it is a system claim that corresponds to claim 6. Therefore, the claim is rejected for at least the same reasons as the method of claim 6.
Claims 3, 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Murray (US 20220263655 A1) in view of Erickson et al. (US 20220124078 A1, hereinafter “Erickson”) in view of Patil et al. (US 20200389869 A1, hereinafter “Patil”) as applied to claim above, and further in view of Cromer et al. (US 20020080973 A1, hereinafter “Cromer”).
Regarding claim 3, (Previously Presented) the combination of Murray, Erickson and Patil teaches all elements of the current invention as stated above. Erickson discloses the method of claim 2, wherein storing the digital certificate in the storage device of the cloud service comprises:
validating, by the storage device, the digital certificate using the KMS public key (Erickson: [0106] In some implementations, each client device may generate its own private key locally (and determine a public key based on that generated private key). The client device can then send its public key to the cloud service during an installation, configuration or subscription setup so that a certificate with that public key can be digitally signed. For example, the client device's certificate may be signed by a public key of the cloud service (“validating, by the storage device, the digital certificate”). An uplink communication from the client device may include the signed certificate or signature that can be validated using a public key of the cloud service).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the key-metadata based encrypted storage management system disclosed by Murray with the teachings of Erickson to validate, by the storage device, the digital certificate using the KMS public key. One of ordinary skill in the art would have been motivated to make this modification because the obtained the public key of the cloud service via an intermediate proxy server may maintain or manage relationships with various remote destination networks (para.[0106]). Therefore, using public keys in cloud systems provides strong security through confidentiality, authenticity, and integrity, enabling secure key exchange, digital signatures for identity verification.
However, the combination does not teach, but Cromer, in a same field of endeavor, discloses reading, by the storage device, a KMS public key stored in a write-protected region of the storage device (Cromer: [0047-0048] FIG. 5 illustrates a high level flow chart which depicts an example of using a virtual certificate in accordance with the method and system of the present invention. The security subsystem validating the signature by reading the master public key (“reading a public key”) from protected storage 262);
writing the public key of the client device to the write-protected region (Cromer: [0048] the security subsystem validating the signature by reading the master public key (“written the public key”) from protected storage 262).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the key-metadata based encrypted storage management system disclosed by Murray with the teachings of Cromer to read, by the storage device, a KMS public key stored in a write-protected region of the storage device; and write the public key of the client device to the write-protected region. One of ordinary skill in the art would have been motivated to make this modification because it would allow a computer system to securely store the public keys in protected storage, which can only be accessed via a processor of the computer system. Therebefore, this modification would prevent unauthorized access to data (e.g., using the public key) and underlying storage systems.
Regarding claim 10, (Previously Presented) it is a non-transitory computer-readable storage medium claim that corresponds to claim 3. Therefore, the claim is rejected for at least the same reasons as the method of claim 3.
Regarding claim 17, (Original) it is a system claim that corresponds to claim 3. Therefore, the claim is rejected for at least the same reasons as the method of claim 3.
Claims 5, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Murray (US 20220263655 A1) in view of Erickson et al. (US 20220124078 A1, hereinafter “Erickson”) in view of Patil et al. (US 20200389869 A1, hereinafter “Patil”) as applied to claim above, and further in view of Pai et al. (US 20230122665 A1, hereinafter “Pai”) in view of Jones et al. (US 20220116229 A1, hereinafter “Jones”).
Regarding claim 5, (Original) the combination of Murray, Erickson and Patil teaches all elements of the current invention as stated above.
Pai discloses the method of claim 1, wherein the digital certificate includes a validity period (Pai: [0033] The memory 330 may also further store information regarding an expiration time indicating a time at which the bootstrap information assigned to a particular identity will no longer be valid).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the key-metadata based encrypted storage management system disclosed by Murray with the teachings of Pai to include a digital certificate with a validity period. One of ordinary skill in the art would have been motivated to make this modification because longer-lasting digital certificates may provide hackers a wider window of opportunity to find security holes. Digital certificates with expiration time can stay on top of the latest encryption and security.
However, the combination of Murray, Erickson and Patil may not explicitly teach, but Jones in is a same field of endeavor, discloses the method further comprises removing the digital certificate when the validity period expires (Jones: [0008] when every end entity certificate digitally signed by a respective intermediate certificate authority in the chain of intermediate certificate authorities has been added to the certificate revocation list and the current time is at or after an end of the respective validation time period of the respective intermediate certificate authority (“when the validity period expires”), the operations include removing each of the plurality of leaf certificates from the certificate revocation list (“remove the digital certificate”) and adding the respective intermediate certificate associated with the respective intermediate certificate authority to the certificate revocation list).
Before the effective filing date of the claimed invention, it would have been obvious for one of ordinary skill in the art to have modified the key-metadata based encrypted storage management system disclosed by Murray with the teachings of Jones to remove the digital certificate when the validity period expires. One of ordinary skill in the art would have been motivated to make this modification because using an expired certificate makes users vulnerable to cyber-attacks, which can break its trust.
Regarding claim 12, (Original) it is a non-transitory computer-readable storage medium claim that corresponds to claim 5. Therefore, the claim is rejected for at least the same reasons as the method of claim 5.
Regarding claim 19, (Original) it is a system claim that corresponds to claim 5. Therefore, the claim is rejected for at least the same reasons as the method of claim 5.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREW SUH whose telephone number is (571)270-5524. The examiner can normally be reached 9:00 AM- 5:00 PM.
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, Carl Colin can be reached at (571) 272-3862. 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.
/ANDREW SUH/Examiner, Art Unit 2493