DETAILED ACTION
This Action is responsive to the Amendments filed on 10/31/2025.
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 .
Claim Status
Claims 1-4, 6-11, 13-18, and 20 are amended. Claims 5, 12, and 19 are cancelled. Claims 1-4, 6-11, 13-18, and 20 are pending and have been examined.
Claim Objections
Claim 15 is objected to because of the following informalities:
Claim 15 recites “the operation request” in the 10th line. In order to improve the clarity of the claim by maintaining consistent nomenclature throughout the claim set, examiner recommends applicant amend Claim 15, 10th line instead to read “the first operation request”, such as recited in Claims 1 and 8.
Appropriate correction is required.
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-3, 6, 7-10, 13, 14-17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over G et al. (US 20230164131 A1)(hereafter referred to as G) further in view of Procopio (US 10958732 B1)(cited by examiner in previous action)(hereafter referred to as Procopio).
Regarding Claim 1,
G discloses the following limitations:
A method for performing operations on storage endpoints (Cloud Data Providers 110, Fig. 1), comprising:
obtaining (¶0055) from a user (User 114, Fig. 1), by an endpoint manager (Security Token Service (STS) 102, Fig. 1), a first operation request (“an initial logon request” [0055]) to perform an operation on a storage endpoint (“In 202, STS 102 retrieves a CUID … in response to receiving an initial logon request from server 104 to a cloud data provider 110. For example, the initial logon request from server 104 may be from user 114” [0055] // Fig. 2 // ¶0001) – As described in ¶0055 (see also Fig. 2), an STS 102 receives “an initial logon request” (i.e., “a first operation request”) from a user 114 (via server 104) so the user can access (i.e., “perform an operation on”) data stored to a particular cloud service provider 110--,
wherein the storage endpoint is one of a plurality of storage endpoints included in a heterogeneous storage endpoint environment (“multiple cloud data providers” [0009] // Fig. 1 // ¶0032) – As shown in Fig. 1 and taught in ¶0009, a system 100 includes multiple “cloud data providers” (i.e., “a plurality of storage endpoints”) of varying types (see ¶0032). Examiner accordingly considers system 100 as “a heterogeneous storage endpoint environment”--;
identifying (Fig. 2, steps 202-206) that the user is associated with the first operation request (“In 202, STS 102 retrieves a CUID … in response to receiving an initial logon request … from user 114 … In 204, STS 102 sends the initial logon request to server 104 based on the CUID in order to perform a first logon to the cloud data provider 110 using a first user identity” [0055-57] // Fig. 2) – As shown in Fig. 2, during steps 202 - 206, STS 102 uses “a first user identity” of the user making the initial logon request to 1) identify a CUID corresponding to the cloud provider 110 being accessed in response to the initial logon request (step 202); 2) provide the CUID to server 104 so the first user identity can be authenticated by the cloud service provider (step 204); and 3) receives an authorization code from the cloud service provider after the server performs a logon to the cloud service provider using the first user identity (step 206). Examiner considers any of steps 202 - 206 as STS 102 generally “identifying” that user 114 is “associated with” the initial logon request--;
making (Fig. 2, step 202), after the identifying, a first determination that the user is not already verified (“In 202, STS retrieves a CUID from database 106 in response to receiving an initial logon request” [0055] // Fig. 3, step 302 // ¶¶0055; 0070) – As shown in Fig. 2, STS 102 retrieves a CUID from a database 106 in response to an “initial” logon request received from a user 114. As shown in Fig. 3 and clarified in ¶0070, STS 102 performs step 202 (i.e., retrieves a CUID from a database) in response to an “initial” (i.e., the first) logon of a user to a cloud data provider; and otherwise performs step 302 (i.e., retrieves a refresh token from the database) in response to “subsequent” logon requests. Examiner accordingly considers the STS performing step 202 of Fig. 2 (e.g., instead of performing step 302 of Fig. 3) as “a first determination” that a given user 114 has not yet transmit an initial logon request (i.e., “is not already verified”)--,
wherein the user is verified if: a user entry associated with the user is identified in a user information repository (Database 106, Fig. 1); and the identified user entry includes a proof of legitimacy (“a corresponding refresh token” [0035]) specific to the storage endpoint (“database 106 may receive a refresh token from STS 102 in order to store it” [0029] // ¶¶0017; 0031; 0035; 0041; 0066; 0078) – As taught in ¶0029, a database 106 stores “refresh tokens” which enable access of particular users to particular cloud data providers (¶¶0017;0031). Each refresh token in the database is associated with “configuration information” used to identify and retrieve the token from the database (¶0035); the configuration information including both a CUID identifying a particular cloud data provider and a client identifier identifying a particular client (¶0041). After an identity of a client is validated, a corresponding refresh token for the client is stored in database 106 (¶0066). Database 106 stores refresh tokens corresponding to each cloud data provider in the system (¶0078). Examiner accordingly considers database 106 storing a plurality of refresh tokens as “a user information repository” storing a plurality of “user entr[ies] associated with the user”; whereby an individual refresh token stored in the database corresponds to an individual entry of the database. Each refresh token corresponds to “a proof of legitimacy” for the associated user (e.g., a refresh token is only stored after the user identity is validated) and is associated with a CUID identifying a particular cloud data provider (i.e., “specific to the storage endpoint”)--;
in response to the first determination: performing endpoint specific user verification (Fig. 2, steps 206-212 // ¶¶0059-66) … to verify an identity of the user (“authorize the first user identity to access the cloud data provider 110” [0059]) – Examiner considers steps 208-212 of Fig. 2 as “endpoint specific user verification” which enables a particular user to access a particular cloud data provider--, wherein performing the endpoint specific user verification comprises:
obtaining (Fig. 2, step 208), from the storage endpoint, the proof of legitimacy specific to the storage endpoint (“In 208, the STS 102 exchanges the authorization code for an identifier token and a refresh token issued by the cloud data provider 110” [0059]) – As shown in Fig. 2, during step 208, STS 102 receives a refresh token (i.e., “the proof of legitimacy specific to the storage endpoint”) and an “identifier token” from the cloud provider 110 being accessed--;
associating (Fig. 2, step 210) the proof of legitimacy specific to the storage endpoint with the user (“In 210, STS 102 validates the identifier token and the refresh token based on the CUID” [0063] // ¶¶0060; 0035) – As shown in Fig. 2, during step 210, STS 102 uses the CUID of the particular cloud data provider being accessed (see also ¶0035) to validate both of the refresh token and the identifier token received from cloud data provider 110. The identifier token identifies a particular user (¶0060). In this context, examiner considers STS 102 validating both the refresh token and the identifier token received from the cloud data provider 110 as the STS generally “associating” the received refresh token with user 114 (e.g., via validation of the identifier token received with the refresh token)--; and
updating (Fig. 2, step 212) the user information repository to include the user entry with the proof of legitimacy specific to the storage endpoint (“In step 212, STS 102 stores the refresh token in database 106 based on the CUID in response to validating the identifier token and the refresh token” [0066]) – As shown in Fig. 2, STS 102 stores the validated refresh token into database 106 using the CUID of the cloud data provider being accessed--; and
performing (Fig. 3, step 304), in response to verifying the identity of the user, the operation associated with the first operation request on the storage endpoint (“Method 300 may be used when a cloud data provider 110 has been configured, and where method 200 has been applied to provide initial authentication and authorization … In 302, the STS retrieves the refresh token from database 106 based on the CUID … In 304, STS 102 exchanges the refresh token for an access token issued by the cloud data provider 110” [0070-73] // ¶0031) – As shown in Fig. 3, after a refresh token is stored to database 106, the refresh token is subsequently exchanged for an access token so that data can be accessed (i.e., “the operation” is performed).
G is silent regarding the following limitations:
performing endpoint specific user verification using a verification API specific to the storage endpoint
However, Procopio discloses the following limitations:
performing endpoint specific user verification using a verification API specific to the storage endpoint (“An authentication flow is supported in which authentication is performed when the archive file comes from a cloud-based storage provider, thereby requiring that the user must first be authenticated (user account verified) according to the authorization and account APIs and standards exposed by the specific cloud storage provider.” [Col. 11, 25-35th lines] // “Whatever the type or provider of the cloud storage … The cloud storage APIs shown in this figure include user account permissions and authentication APIs 160, 175, and 190 … respectively.” [Col. 13, 15-30th lines] // Fig. 1) – Examiner considers the storage environment depicted in Procopio Fig. 1 as analogous to the storage environment depicted in G Fig. 1. As taught in Procopio, “user account permissions and authentication APIs” which are exposed by specific cloud storage providers (i.e., “a verification API specific to the storage endpoint”) are employed to perform user verification.
G and Procopio are considered analogous to the claimed invention because they all relate to the same field of performing user identity verification in a heterogeneous cloud storage environment distributed across multiple cloud storage service providers. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified G with the teachings of Procopio and realize a method for performing user verification using verification APIs specific to a storage endpoint. Doing so enables a centralized browser application to invoke any necessary API to communicate with any cloud storage endpoint upon request by a user, as disclosed in Procopio Cols. 11 + 14: “An authentication flow is supported in which authentication is performed when the archive file comes from a cloud-based storage provider, thereby requiring that the user must first be authenticated (user account verified) according to the authorization and account APIs and standards exposed by the specific cloud storage provider” [Col. 11, 25-40th lines] // “the main in-browser application 130 includes API modules for calling cloud storage APIs. In this way, the main in-browser application 130 can access any of the cloud storage providers upon user-specified command” [Col. 14, 25-35th lines].
Regarding Claim 2,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 2. The combined teachings of G and Procopio disclose the following limitations:
The method of claim 1, wherein the heterogeneous storage endpoint environment comprises a first storage endpoint type (G, Cloud Data Provider 110-1, Fig. 1 // ¶0032) and a second storage endpoint type (G, Cloud Data Provider 110-2, Fig. 1 // ¶0032).
Regarding Claim 3,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 3 The combined teachings of G and Procopio disclose the following limitations:
The method of claim 2, wherein the first storage endpoint type comprises a first user verification application programming interface (API) (Procopio, User Account Permissions and Authentication API 160, Fig. 1) and the second storage endpoint type comprises a second user verification API (Procopio, User Account Permissions and Authentication API 175, Fig. 1)
Regarding Claim 6,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 6. The combined teachings of G and Procopio disclose the following limitations:
The method of claim 1 (see Claim 1 limitation mappings above), further comprising:
obtaining (G, Fig. 3, step 302), by the endpoint manager, a second operation request (G, “a user-impersonation logon request” [0071]) associated with the storage endpoint from a second user (G, User-impersonator 116, Fig. 1 // “In 302, STS 102 retrieves the refresh token from database 106 based on the CUID in response to receiving a user-impersonation logon request … from user-impersonator 116” [0071]) – As shown in Fig. 3, a user-impersonator 116 (i.e., “a second user’”) transmits a “user-impersonation logon request” to the cloud data provider 110--;
identifying that the second user is associated with the second operation request (G, “In 306, the STS 102 sends the user-impersonation logon request and the access token to server 104 in order to perform a second logon to the cloud data provider using a second user identity” [0074]) – As previously discussed (see Claim 1 limitation mappings above) and as evidenced by G ¶0074, STS 102 is aware of the user identity associated with any logon request--;
making a second determination that the second user is already verified (G, “A user-impersonator can seamlessly access the cloud data provider without directly needing to logon” [0013] // ¶0011; 0051; 0070) – As taught in G ¶0013, a user-impersonator 116 (e.g., an administrator or automation/scheduling software) is automatically provided with access to the cloud data provider once user 114 has been validated. Accordingly, once STS 102 receives a user-impersonation logon request during step 302 (i.e., after user 114 has been validated; see ¶0070), STS 102 performs the method of Fig. 3 to provide an access token for the user-impersonator 116 to access the cloud data storage. In the context of Fig. 3, user-impersonator 116 is “already verified” because STS 102 does not require any additional action from user 114 to provide user-impersonator 116 with an access token (e.g., unlike the method of Fig. 2 whereby STS 102 must first receive an “authorization code” prior to receiving an access token for user 114; see step 206); and
in response to the second determination: performing a second operation (G, Fig. 3, step 306) associated with the second operation request on the storage endpoint. (G, “In 306, STS 102 sends the user-impersonation logon request and the access token to server 104 in order to perform a second logon to the cloud data provider 110 using a second user identity” [0074]) – As taught in G Fig. 3, an access token for user-impersonator 116 is provided to server 104 (i.e., “a second operation” associated with the user-impersonation logon request is performed) after the STS 102 receives the user-impersonation logon request.
Regarding Claim 8,
G discloses the following limitations:
A non-transitory computer readable medium comprising computer readable program code, which when executed by a computer processor enables the computer processor to (¶¶0053; 0097) perform a method for performing operations on storage endpoints, the method comprising:
obtaining (¶0055) from a user (User 114, Fig. 1), by an endpoint manager (Security Token Service (STS) 102, Fig. 1), a first operation request (“an initial logon request” [0055]) to perform an operation on a storage endpoint (“In 202, STS 102 retrieves a CUID … in response to receiving an initial logon request from server 104 to a cloud data provider 110. For example, the initial logon request from server 104 may be from user 114” [0055] // Fig. 2 // ¶0001) – As described in ¶0055 (see also Fig. 2), an STS 102 receives “an initial logon request” (i.e., “a first operation request”) from a user 114 (via server 104) so the user can access (i.e., “perform an operation on”) data stored to a particular cloud service provider 110--,
wherein the storage endpoint is one of a plurality of storage endpoints included in a heterogeneous storage endpoint environment (“multiple cloud data providers” [0009] // Fig. 1 // ¶0032) – As shown in Fig. 1 and taught in ¶0009, a system 100 includes multiple “cloud data providers” (i.e., “a plurality of storage endpoints”) of varying types (see ¶0032). Examiner accordingly considers system 100 as “a heterogeneous storage endpoint environment”--;
identifying (Fig. 2, steps 202-206) that the user is associated with the first operation request (“In 202, STS 102 retrieves a CUID … in response to receiving an initial logon request … from user 114 … In 204, STS 102 sends the initial logon request to server 104 based on the CUID in order to perform a first logon to the cloud data provider 110 using a first user identity” [0055-57] // Fig. 2) – As shown in Fig. 2, during steps 202 - 206, STS 102 uses “a first user identity” of the user making the initial logon request to 1) identify a CUID corresponding to the cloud provider 110 being accessed in response to the initial logon request (step 202); 2) provide the CUID to server 104 so the first user identity can be authenticated by the cloud service provider (step 204); and 3) receives an authorization code from the cloud service provider after the server performs a logon to the cloud service provider using the first user identity (step 206). Examiner considers any of steps 202 - 206 as STS 102 generally “identifying” that user 114 is “associated with” the initial logon request--;
making (Fig. 2, step 202), after the identifying, a first determination that the user is not already verified (“In 202, STS retrieves a CUID from database 106 in response to receiving an initial logon request” [0055] // Fig. 3, step 302 // ¶¶0055; 0070) – As shown in Fig. 2, STS 102 retrieves a CUID from a database 106 in response to an “initial” logon request received from a user 114. As shown in Fig. 3 and clarified in ¶0070, STS 102 performs step 202 (i.e., retrieves a CUID from a database) in response to an “initial” (i.e., the first) logon of a user to a cloud data provider; and otherwise performs step 302 (i.e., retrieves a refresh token from the database) in response to “subsequent” logon requests. Examiner accordingly considers the STS performing step 202 of Fig. 2 (e.g., instead of performing step 302 of Fig. 3) as “a first determination” that a given user 114 has not yet transmit an initial logon request (i.e., “is not already verified”)--,
wherein the user is verified if: a user entry associated with the user is identified in a user information repository (Database 106, Fig. 1); and the identified user entry includes a proof of legitimacy (“a corresponding refresh token” [0035]) specific to the storage endpoint (“database 106 may receive a refresh token from STS 102 in order to store it” [0029] // ¶¶0017; 0031; 0035; 0041; 0066; 0078) – As taught in ¶0029, a database 106 stores “refresh tokens” which enable access of particular users to particular cloud data providers (¶¶0017;0031). Each refresh token in the database is associated with “configuration information” used to identify and retrieve the token from the database (¶0035); the configuration information including both a CUID identifying a particular cloud data provider and a client identifier identifying a particular client (¶0041). After an identity of a client is validated, a corresponding refresh token for the client is stored in database 106 (¶0066). Database 106 stores refresh tokens corresponding to each cloud data provider in the system (¶0078). Examiner accordingly considers database 106 storing a plurality of refresh tokens as “a user information repository” storing a plurality of “user entr[ies] associated with the user”; whereby an individual refresh token stored in the database corresponds to an individual entry of the database. Each refresh token corresponds to “a proof of legitimacy” for the associated user (e.g., a refresh token is only stored after the user identity is validated) and is associated with a CUID identifying a particular cloud data provider (i.e., “specific to the storage endpoint”)--;
in response to the first determination: performing endpoint specific user verification (Fig. 2, steps 206-212 // ¶¶0059-66) … to verify an identity of the user (“authorize the first user identity to access the cloud data provider 110” [0059]) – Examiner considers steps 208-212 of Fig. 2 as “endpoint specific user verification” which enables a particular user to access a particular cloud data provider--, wherein performing the endpoint specific user verification comprises:
obtaining (Fig. 2, step 208), from the storage endpoint, the proof of legitimacy specific to the storage endpoint (“In 208, the STS 102 exchanges the authorization code for an identifier token and a refresh token issued by the cloud data provider 110” [0059]) – As shown in Fig. 2, during step 208, STS 102 receives a refresh token (i.e., “the proof of legitimacy specific to the storage endpoint”) and an “identifier token” from the cloud provider 110 being accessed--;
associating (Fig. 2, step 210) the proof of legitimacy specific to the storage endpoint with the user (“In 210, STS 102 validates the identifier token and the refresh token based on the CUID” [0063] // ¶¶0060; 0035) – As shown in Fig. 2, during step 210, STS 102 uses the CUID of the particular cloud data provider being accessed (see also ¶0035) to validate both of the refresh token and the identifier token received from cloud data provider 110. The identifier token identifies a particular user (¶0060). In this context, examiner considers STS 102 validating both the refresh token and the identifier token received from the cloud data provider 110 as the STS generally “associating” the received refresh token with user 114 (e.g., via validation of the identifier token received with the refresh token)--; and
updating (Fig. 2, step 212) the user information repository to include the user entry with the proof of legitimacy specific to the storage endpoint (“In step 212, STS 102 stores the refresh token in database 106 based on the CUID in response to validating the identifier token and the refresh token” [0066]) – As shown in Fig. 2, STS 102 stores the validated refresh token into database 106 using the CUID of the cloud data provider being accessed--; and
performing (Fig. 3, step 304), in response to verifying the identity of the user, the operation associated with the first operation request on the storage endpoint (“Method 300 may be used when a cloud data provider 110 has been configured, and where method 200 has been applied to provide initial authentication and authorization … In 302, the STS retrieves the refresh token from database 106 based on the CUID … In 304, STS 102 exchanges the refresh token for an access token issued by the cloud data provider 110” [0070-73] // ¶0031) – As shown in Fig. 3, after a refresh token is stored to database 106, the refresh token is subsequently exchanged for an access token so that data can be accessed (i.e., “the operation” is performed).
G is silent regarding the following limitations:
performing endpoint specific user verification using a verification API specific to the storage endpoint
However, Procopio discloses the following limitations:
performing endpoint specific user verification using a verification API specific to the storage endpoint (“An authentication flow is supported in which authentication is performed when the archive file comes from a cloud-based storage provider, thereby requiring that the user must first be authenticated (user account verified) according to the authorization and account APIs and standards exposed by the specific cloud storage provider.” [Col. 11, 25-35th lines] // “Whatever the type or provider of the cloud storage … The cloud storage APIs shown in this figure include user account permissions and authentication APIs 160, 175, and 190 … respectively.” [Col. 13, 15-30th lines] // Fig. 1) – Examiner considers the storage environment depicted in Procopio Fig. 1 as analogous to the storage environment depicted in G Fig. 1. As taught in Procopio, “user account permissions and authentication APIs” which are exposed by specific cloud storage providers (i.e., “a verification API specific to the storage endpoint”) are employed to perform user verification.
G and Procopio are considered analogous to the claimed invention because they all relate to the same field of performing user identity verification in a heterogeneous cloud storage environment distributed across multiple cloud storage service providers. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified G with the teachings of Procopio and realize a method for performing user verification using verification APIs specific to a storage endpoint. Doing so enables a centralized browser application to invoke any necessary API to communicate with any cloud storage endpoint upon request by a user, as disclosed in Procopio Cols. 11 + 14: “An authentication flow is supported in which authentication is performed when the archive file comes from a cloud-based storage provider, thereby requiring that the user must first be authenticated (user account verified) according to the authorization and account APIs and standards exposed by the specific cloud storage provider” [Col. 11, 25-40th lines] // “the main in-browser application 130 includes API modules for calling cloud storage APIs. In this way, the main in-browser application 130 can access any of the cloud storage providers upon user-specified command” [Col. 14, 25-35th lines].
Regarding Claim 9,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 9. The combined teachings of G and Procopio disclose the following limitations:
The non-transitory computer readable medium of claim 8, wherein the heterogeneous storage endpoint environment comprises a first storage endpoint type (G, Cloud Data Provider 110-1, Fig. 1 // ¶0032) and a second storage endpoint type (G, Cloud Data Provider 110-2, Fig. 1 // ¶0032).
Regarding Claim 10,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 10. The combined teachings of G and Procopio disclose the following limitations:
The non-transitory computer readable medium of claim 9, wherein the first storage endpoint type comprises a first user verification application programming interface (API) (Procopio, User Account Permissions and Authentication API 160, Fig. 1) and the second storage endpoint type comprises a second user verification API (Procopio, User Account Permissions and Authentication API 175, Fig. 1)
Regarding Claim 13,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 13. The combined teachings of G and Procopio disclose the following limitations:
The non-transitory computer readable medium of claim 8, wherein the method further comprising: obtaining (G, Fig. 3, step 302), by the endpoint manager, a second operation request (G, “a user-impersonation logon request” [0071]) associated with the storage endpoint from a second user (G, User-impersonator 116, Fig. 1 // “In 302, STS 102 retrieves the refresh token from database 106 based on the CUID in response to receiving a user-impersonation logon request … from user-impersonator 116” [0071]) – As shown in Fig. 3, a user-impersonator 116 (i.e., “a second user’”) transmits a “user-impersonation logon request” to the cloud data provider 110--;
identifying that the second user is associated with the second operation request (G, “In 306, the STS 102 sends the user-impersonation logon request and the access token to server 104 in order to perform a second logon to the cloud data provider using a second user identity” [0074]) – As previously discussed (see Claim 8 limitation mappings above) and as evidenced by G ¶0074, STS 102 is aware of the user identity associated with any logon request--;
making a second determination that the second user is already verified (G, “A user-impersonator can seamlessly access the cloud data provider without directly needing to logon” [0013] // ¶0011; 0051; 0070) – As taught in G ¶0013, a user-impersonator 116 (e.g., an administrator or automation/scheduling software) is automatically provided with access to the cloud data provider once user 114 has been validated. Accordingly, once STS 102 receives a user-impersonation logon request during step 302 (i.e., after user 114 has been validated; see ¶0070), STS 102 performs the method of Fig. 3 to provide an access token for the user-impersonator 116 to access the cloud data storage. In the context of Fig. 3, user-impersonator 116 is “already verified” because STS 102 does not require any additional action from user 114 to provide user-impersonator 116 with an access token (e.g., unlike the method of Fig. 2 whereby STS 102 must first receive an “authorization code” prior to receiving an access token for user 114; see step 206); and
in response to the second determination: performing a second operation (G, Fig. 3, step 306) associated with the second operation request on the storage endpoint. (G, “In 306, STS 102 sends the user-impersonation logon request and the access token to server 104 in order to perform a second logon to the cloud data provider 110 using a second user identity” [0074]) – As taught in G Fig. 3, an access token for user-impersonator 116 is provided to server 104 (i.e., “a second operation” associated with the user-impersonation logon request is performed) after the STS 102 receives the user-impersonation logon request.
Regarding Claim 15,
G discloses the following limitations:
A system for performing operations on storage endpoints, the system comprising: a heterogeneous storage endpoint environment (Fig. 1); and a endpoint manager (STS 102, Fig. 1), comprising a processor and memory comprising computer instructions (¶¶0014; 0053), which when executed by the processor causes the processor to perform a method, wherein the method comprises:
obtaining (¶0055) a first operation request (“an initial logon request” [0055]) associated with a storage endpoint from a user (“In 202, STS 102 retrieves a CUID … in response to receiving an initial logon request from server 104 to a cloud data provider 110. For example, the initial logon request from server 104 may be from user 114” [0055] // Fig. 2 // ¶0001) – As described in ¶0055 (see also Fig. 2), an STS 102 receives “an initial logon request” (i.e., “a first operation request”) from a user 114 (via server 104) so the user can access (i.e., “perform an operation on”) data stored to a particular cloud service provider 110--,
wherein the storage endpoint is one of a plurality of storage endpoints included in the heterogeneous storage endpoint environment (“multiple cloud data providers” [0009] // Fig. 1 // ¶0032) – As shown in Fig. 1 and taught in ¶0009, a system 100 includes multiple “cloud data providers” (i.e., “a plurality of storage endpoints”) of varying types (see ¶0032). Examiner accordingly considers system 100 as “a heterogeneous storage endpoint environment”--;
identifying (Fig. 2, steps 202-206) that the user is associated with the operation request (“In 202, STS 102 retrieves a CUID … in response to receiving an initial logon request … from user 114 … In 204, STS 102 sends the initial logon request to server 104 based on the CUID in order to perform a first logon to the cloud data provider 110 using a first user identity” [0055-57] // Fig. 2) – As shown in Fig. 2, during steps 202 - 206, STS 102 uses “a first user identity” of the user making the initial logon request to 1) identify a CUID corresponding to the cloud provider 110 being accessed in response to the initial logon request (step 202); 2) provide the CUID to server 104 so the first user identity can be authenticated by the cloud service provider (step 204); and 3) receives an authorization code from the cloud service provider after the server performs a logon to the cloud service provider using the first user identity (step 206). Examiner considers any of steps 202 - 206 as STS 102 generally “identifying” that user 114 is “associated with” the initial logon request--;
making (Fig. 2, step 202), after the identifying, a first determination that the user is not already verified (“In 202, STS retrieves a CUID from database 106 in response to receiving an initial logon request” [0055] // Fig. 3, step 302 // ¶¶0055; 0070) – As shown in Fig. 2, STS 102 retrieves a CUID from a database 106 in response to an “initial” logon request received from a user 114. As shown in Fig. 3 and clarified in ¶0070, STS 102 performs step 202 (i.e., retrieves a CUID from a database) in response to an “initial” (i.e., the first) logon of a user to a cloud data provider; and otherwise performs step 302 (i.e., retrieves a refresh token from the database) in response to “subsequent” logon requests. Examiner accordingly considers the STS performing step 202 of Fig. 2 (e.g., instead of performing step 302 of Fig. 3) as “a first determination” that a given user 114 has not yet transmit an initial logon request (i.e., “is not already verified”)--,
wherein the user is verified if: a user entry associated with the user is identified in a user information repository (Database 106, Fig. 1); and the identified user entry includes a proof of legitimacy (“a corresponding refresh token” [0035]) specific to the storage endpoint (“database 106 may receive a refresh token from STS 102 in order to store it” [0029] // ¶¶0017; 0031; 0035; 0041; 0066; 0078) – As taught in ¶0029, a database 106 stores “refresh tokens” which enable access of particular users to particular cloud data providers (¶¶0017;0031). Each refresh token in the database is associated with “configuration information” used to identify and retrieve the token from the database (¶0035); the configuration information including both a CUID identifying a particular cloud data provider and a client identifier identifying a particular client (¶0041). After an identity of a client is validated, a corresponding refresh token for the client is stored in database 106 (¶0066). Database 106 stores refresh tokens corresponding to each cloud data provider in the system (¶0078). Examiner accordingly considers database 106 storing a plurality of refresh tokens as “a user information repository” storing a plurality of “user entr[ies] associated with the user”; whereby an individual refresh token stored in the database corresponds to an individual entry of the database. Each refresh token corresponds to “a proof of legitimacy” for the associated user (e.g., a refresh token is only stored after the user identity is validated) and is associated with a CUID identifying a particular cloud data provider (i.e., “specific to the storage endpoint”)--;
in response to the first determination: performing endpoint specific user verification (Fig. 2, steps 206-212 // ¶¶0059-66) … to verify an identity of the user (“authorize the first user identity to access the cloud data provider 110” [0059]) – Examiner considers steps 208-212 of Fig. 2 as “endpoint specific user verification” which enables a particular user to access a particular cloud data provider--, wherein performing the endpoint specific user verification comprises:
obtaining (Fig. 2, step 208), from the storage endpoint, the proof of legitimacy specific to the storage endpoint (“In 208, the STS 102 exchanges the authorization code for an identifier token and a refresh token issued by the cloud data provider 110” [0059]) – As shown in Fig. 2, during step 208, STS 102 receives a refresh token (i.e., “the proof of legitimacy specific to the storage endpoint”) and an “identifier token” from the cloud provider 110 being accessed--;
associating (Fig. 2, step 210) the proof of legitimacy specific to the storage endpoint with the user (“In 210, STS 102 validates the identifier token and the refresh token based on the CUID” [0063] // ¶¶0060; 0035) – As shown in Fig. 2, during step 210, STS 102 uses the CUID of the particular cloud data provider being accessed (see also ¶0035) to validate both of the refresh token and the identifier token received from cloud data provider 110. The identifier token identifies a particular user (¶0060). In this context, examiner considers STS 102 validating both the refresh token and the identifier token received from the cloud data provider 110 as the STS generally “associating” the received refresh token with user 114 (e.g., via validation of the identifier token received with the refresh token)--; and
updating (Fig. 2, step 212) the user information repository to include the user entry with the proof of legitimacy specific to the storage endpoint (“In step 212, STS 102 stores the refresh token in database 106 based on the CUID in response to validating the identifier token and the refresh token” [0066]) – As shown in Fig. 2, STS 102 stores the validated refresh token into database 106 using the CUID of the cloud data provider being accessed--; and
performing (Fig. 3, step 304), in response to verifying the identity of the user, the operation associated with the first operation request on the storage endpoint (“Method 300 may be used when a cloud data provider 110 has been configured, and where method 200 has been applied to provide initial authentication and authorization … In 302, the STS retrieves the refresh token from database 106 based on the CUID … In 304, STS 102 exchanges the refresh token for an access token issued by the cloud data provider 110” [0070-73] // ¶0031) – As shown in Fig. 3, after a refresh token is stored to database 106, the refresh token is subsequently exchanged for an access token so that data can be accessed (i.e., “the operation” is performed).
G is silent regarding the following limitations:
performing endpoint specific user verification using a verification API specific to the storage endpoint
However, Procopio discloses the following limitations:
performing endpoint specific user verification using a verification API specific to the storage endpoint (“An authentication flow is supported in which authentication is performed when the archive file comes from a cloud-based storage provider, thereby requiring that the user must first be authenticated (user account verified) according to the authorization and account APIs and standards exposed by the specific cloud storage provider.” [Col. 11, 25-35th lines] // “Whatever the type or provider of the cloud storage … The cloud storage APIs shown in this figure include user account permissions and authentication APIs 160, 175, and 190 … respectively.” [Col. 13, 15-30th lines] // Fig. 1) – Examiner considers the storage environment depicted in Procopio Fig. 1 as analogous to the storage environment depicted in G Fig. 1. As taught in Procopio, “user account permissions and authentication APIs” which are exposed by specific cloud storage providers (i.e., “a verification API specific to the storage endpoint”) are employed to perform user verification.
G and Procopio are considered analogous to the claimed invention because they all relate to the same field of performing user identity verification in a heterogeneous cloud storage environment distributed across multiple cloud storage service providers. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified G with the teachings of Procopio and realize a method for performing user verification using verification APIs specific to a storage endpoint. Doing so enables a centralized browser application to invoke any necessary API to communicate with any cloud storage endpoint upon request by a user, as disclosed in Procopio Cols. 11 + 14: “An authentication flow is supported in which authentication is performed when the archive file comes from a cloud-based storage provider, thereby requiring that the user must first be authenticated (user account verified) according to the authorization and account APIs and standards exposed by the specific cloud storage provider” [Col. 11, 25-40th lines] // “the main in-browser application 130 includes API modules for calling cloud storage APIs. In this way, the main in-browser application 130 can access any of the cloud storage providers upon user-specified command” [Col. 14, 25-35th lines].
Regarding Claim 16,
The same motivation to combine provided in Claim 15 is equally applicable to Claim 16. The combined teachings of G and Procopio disclose the following limitations:
The system of claim 15, wherein the heterogeneous storage endpoint environment comprises a first storage endpoint type (G, Cloud Data Provider 110-1, Fig. 1 // ¶0032) and a second storage endpoint type (G, Cloud Data Provider 110-2, Fig. 1 // ¶0032).
Regarding Claim 17,
The same motivation to combine provided in Claim 15 is equally applicable to Claim 17. The combined teachings of G and Procopio disclose the following limitations:
The system of claim 16, wherein the first storage endpoint type comprises a first user verification application programming interface (API) (Procopio, User Account Permissions and Authentication API 160, Fig. 1) and the second storage endpoint type comprises a second user verification API (Procopio, User Account Permissions and Authentication API 175, Fig. 1)
Regarding Claim 20,
The same motivation to combine provided in Claim 15 is equally applicable to Claim 20. The combined teachings of G and Procopio disclose the following limitations:
The system of claim 15, wherein the method further comprises:
obtaining (G, Fig. 3, step 302), by the endpoint manager, a second operation request (G, “a user-impersonation logon request” [0071]) associated with the storage endpoint from a second user (G, User-impersonator 116, Fig. 1 // “In 302, STS 102 retrieves the refresh token from database 106 based on the CUID in response to receiving a user-impersonation logon request … from user-impersonator 116” [0071]) – As shown in Fig. 3, a user-impersonator 116 (i.e., “a second user’”) transmits a “user-impersonation logon request” to the cloud data provider 110--;
identifying that the second user is associated with the second operation request (G, “In 306, the STS 102 sends the user-impersonation logon request and the access token to server 104 in order to perform a second logon to the cloud data provider using a second user identity” [0074]) – As previously discussed (see Claim 15 limitation mappings above) and as evidenced by G ¶0074, STS 102 is aware of the user identity associated with any logon request--;
making a second determination that the second user is already verified (G, “A user-impersonator can seamlessly access the cloud data provider without directly needing to logon” [0013] // ¶0011; 0051; 0070) – As taught in G ¶0013, a user-impersonator 116 (e.g., an administrator or automation/scheduling software) is automatically provided with access to the cloud data provider once user 114 has been validated. Accordingly, once STS 102 receives a user-impersonation logon request during step 302 (i.e., after user 114 has been validated; see ¶0070), STS 102 performs the method of Fig. 3 to provide an access token for the user-impersonator 116 to access the cloud data storage. In the context of Fig. 3, user-impersonator 116 is “already verified” because STS 102 does not require any additional action from user 114 to provide user-impersonator 116 with an access token (e.g., unlike the method of Fig. 2 whereby STS 102 must first receive an “authorization code” prior to receiving an access token for user 114; see step 206); and
in response to the second determination: performing a second operation (G, Fig. 3, step 306) associated with the second operation request on the storage endpoint. (G, “In 306, STS 102 sends the user-impersonation logon request and the access token to server 104 in order to perform a second logon to the cloud data provider 110 using a second user identity” [0074]) – As taught in G Fig. 3, an access token for user-impersonator 116 is provided to server 104 (i.e., “a second operation” associated with the user-impersonation logon request is performed) after the STS 102 receives the user-impersonation logon request.
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over G further in view of Procopio and a 2015 IEEE publication authored by Graupner et al. (cited “H. Graupner, K. Torkura, P. Berger, C. Meinel and M. Schnjakin, "Secure access control for multi-cloud resources," 2015 IEEE 40th Local Computer Networks Conference Workshops (LCN Workshops), Clearwater Beach, FL, USA, 2015, pp. 722-729”)(hereafter referred to as Graupner).
Regarding Claim 4,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 4. The combined teachings of G and Procopio disclose the following limitations:
The method of claim 2 (see Claim 2 limitation mappings above), wherein the first storage endpoint type comprises a first proof of legitimacy type (G, “refresh token”) – As previously discussed (see Claim 1 limitation mappings above) and as taught in G, cloud data providers 110 use “refresh tokens” (i.e., “a first proof of legitimacy type”) to validate users.
The combined teachings of G and Procopio do not explicitly disclose the following limitations:
and the second storage endpoint type comprises a second proof of legitimacy type
However, Graupner discloses that cloud service providers each use various methods of performing access control. Graupner discloses the following limitations:
and the second storage endpoint type comprises a second proof of legitimacy type (“a survey of selected cloud storage providers (summarized at Table I) in order to highlight state-of-the-art cloud access control techniques. The first set of providers are completely independent while the next set follow a common cloud strategy … there are two major options available for accessing objects and containers: Access Control Lists (ACLs) and Signed URLs (Query String Authentication). Both approaches are not mutually exclusive, both can be used at the same time.” [Section III; pgs. 723-724 // Table 1]) – As taught in Graupner and as shown in Table 1, cloud storage providers each use diverse methods of access control, including techniques such as ACLs and signed URLs. Examiner considers the “signed URL” technique of access control as “a second proof of legitimacy type” enabled by a cloud provider (i.e., in addition to an access control technique involving access control lists).
G, Procopio, and Graupner are considered analogous to the claimed invention because they all relate to the same field of performing access control techniques in heterogeneous storage environments comprising different cloud storage providers. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified G and Procopio with the teachings of Graupner and realize a method of operating a heterogeneous storage environment including a first endpoint type using a first proof of legitimacy type and a second endpoint type using a second proof of legitimacy type. Doing so allow precise access control over distributed data resources in environments which do not employ uniform access control mechanisms, as taught in Graupner [Abstract, Section I]: “Multi-cloud architectures however suffer several challenges including inadequate cross-provider APIs, insufficient support from cloud service providers, and especially non-unified access control mechanisms.” [Abstract] // “Our solution allows precise access control over distributed data resources by providing an additional Access Control Management (ACM) service” [Section I, pg. 722]
Regarding Claim 11,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 11. The combined teachings of G and Procopio disclose the following limitations:
The non-transitory computer readable medium of claim 9 (see Claim 9 limitation mappings above), wherein the first storage endpoint type comprises a first proof of legitimacy type (G, “refresh token”) – As previously discussed (see Claim 8 limitation mappings above) and as taught in G, cloud data providers 110 use “refresh tokens” (i.e., “a first proof of legitimacy type”) to validate users.
The combined teachings of G and Procopio do not explicitly disclose the following limitations:
and the second storage endpoint type comprises a second proof of legitimacy type
However, Graupner discloses that cloud service providers each use various methods of performing access control. Graupner discloses the following limitations:
and the second storage endpoint type comprises a second proof of legitimacy type (“a survey of selected cloud storage providers (summarized at Table I) in order to highlight state-of-the-art cloud access control techniques. The first set of providers are completely independent while the next set follow a common cloud strategy … there are two major options available for accessing objects and containers: Access Control Lists (ACLs) and Signed URLs (Query String Authentication). Both approaches are not mutually exclusive, both can be used at the same time.” [Section III; pgs. 723-724 // Table 1]) – As taught in Graupner and as shown in Table 1, cloud storage providers each use diverse methods of access control, including techniques such as ACLs and signed URLs. Examiner considers the “signed URL” technique of access control as “a second proof of legitimacy type” enabled by a cloud provider (i.e., in addition to an access control technique involving access control lists).
G, Procopio, and Graupner are considered analogous to the claimed invention because they all relate to the same field of performing access control techniques in heterogeneous storage environments comprising different cloud storage providers. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified G and Procopio with the teachings of Graupner and realize a method of operating a heterogeneous storage environment including a first endpoint type using a first proof of legitimacy type and a second endpoint type using a second proof of legitimacy type. Doing so allow precise access control over distributed data resources in environments which do not employ uniform access control mechanisms, as taught in Graupner [Abstract, Section I]: “Multi-cloud architectures however suffer several challenges including inadequate cross-provider APIs, insufficient support from cloud service providers, and especially non-unified access control mechanisms.” [Abstract] // “Our solution allows precise access control over distributed data resources by providing an additional Access Control Management (ACM) service” [Section I, pg. 722]
Regarding Claim 18,
The same motivation to combine provided in Claim 15 is equally applicable to Claim 18. The combined teachings of G and Procopio disclose the following limitations:
The system of claim 16 (see Claim 16 limitation mappings above), wherein the first storage endpoint type comprises a first proof of legitimacy type (G, “refresh token”) – As previously discussed (see Claim 15 limitation mappings above) and as taught in G, cloud data providers 110 use “refresh tokens” (i.e., “a first proof of legitimacy type”) to validate users.
The combined teachings of G and Procopio do not explicitly disclose the following limitations:
and the second storage endpoint type comprises a second proof of legitimacy type
However, Graupner discloses that cloud service providers each use various methods of performing access control. Graupner discloses the following limitations:
and the second storage endpoint type comprises a second proof of legitimacy type (“a survey of selected cloud storage providers (summarized at Table I) in order to highlight state-of-the-art cloud access control techniques. The first set of providers are completely independent while the next set follow a common cloud strategy … there are two major options available for accessing objects and containers: Access Control Lists (ACLs) and Signed URLs (Query String Authentication). Both approaches are not mutually exclusive, both can be used at the same time.” [Section III; pgs. 723-724 // Table 1]) – As taught in Graupner and as shown in Table 1, cloud storage providers each use diverse methods of access control, including techniques such as ACLs and signed URLs. Examiner considers the “signed URL” technique of access control as “a second proof of legitimacy type” enabled by a cloud provider (i.e., in addition to an access control technique involving access control lists).
G, Procopio, and Graupner are considered analogous to the claimed invention because they all relate to the same field of performing access control techniques in heterogeneous storage environments comprising different cloud storage providers. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified G and Procopio with the teachings of Graupner and realize a method of operating a heterogeneous storage environment including a first endpoint type using a first proof of legitimacy type and a second endpoint type using a second proof of legitimacy type. Doing so allow precise access control over distributed data resources in environments which do not employ uniform access control mechanisms, as taught in Graupner [Abstract, Section I]: “Multi-cloud architectures however suffer several challenges including inadequate cross-provider APIs, insufficient support from cloud service providers, and especially non-unified access control mechanisms.” [Abstract] // “Our solution allows precise access control over distributed data resources by providing an additional Access Control Management (ACM) service” [Section I, pg. 722]
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over G further in view of Procopio and N et al. (US 20220141213 A1)(cited by examiner in previous action)(hereafter referred to as N).
Regarding Claim 7,
The same motivation to combine provided in Claim 1 is equally applicable to Claim 7. The combined teaching of G and Procopio disclose the following limitations:
The method of claim 6 (see Claim 6 limitation mappings above),
Although G ¶0001 discloses a large number of users interface with cloud data providers, G does not disclose a user verification process for a second user (e.g., other than user 114) in the same manner as performed for user 114. Specifically, the combined teachings of G and Procopio do not explicitly disclose the following limitations:
wherein making the second determination that the second user is already verified comprises identifying a second proof of legitimacy associated with the second user and the storage endpoint in the user information repository.
However, N discloses the following limitations:
wherein making the second determination that the second user is already verified comprises identifying a second proof of legitimacy associated with the second user and the storage endpoint in the user information repository (“User authentication for cloud networks typically relies on the use of tokens … In an embodiment, system 100 may implement one or more tokens for each client including … a refresh token” [0027] // Fig. 1) – Examiner considers the storage environment depicted in N Fig. 1B as analogous to the storage environment depicted in G Fig. 1. As taught in N ¶0027, each client in a storage environment is provided with a respective refresh token to access a respective REST server. Applying the concept of respective refresh tokens to respective REST servers for each client in a storage environment to G, one of ordinary skill in the art would accordingly understand that two clients (i.e., a first user and “a second user”) operating in the storage environment of G Fig. 1 (e.g., User 114 and User-Impersonator 116) would each be validated by STS 102 using respective refresh tokens (i.e., a first and “a second proof of legitimacy”) stored in Server 104 (i.e., “in the user information repository”).
G, Procopio, and N are considered analogous to the claimed invention because they all relate to the same field of user identity verification in heterogeneous cloud storage environments. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified G and Procopio with the teachings of N and realize a method of verifying first and second users of a heterogeneous storage endpoint environment using first and second proofs of legitimacy stored in a repository. Verifying the identity of users of a heterogeneous storage endpoint environment using a token mechanism would be expected to improve the security of the storage environment by providing a mechanism through which each user of the storage environment can be provided limited scope of access to data for a limited amount of time, as disclosed in N ¶¶0027-28: “User authentication for cloud networks typically relies on the use of tokens … in which a piece of data, embodied in a signed token accompanies each request that is verified by the server for authenticity before it responds to the request … Such a token can be checked at any time independently of the user by the requestor for validation and can be used over time with strictly limited scope and age of validity.” [0027-28]
Regarding Claim 14,
The same motivation to combine provided in Claim 8 is equally applicable to Claim 14. The combined teaching of G and Procopio disclose the following limitations:
The non-transitory computer readable medium of claim 13 (see Claim 13 limitation mappings above),
Although G ¶0001 discloses a large number of users interface with cloud data providers, G does not disclose a user verification process for a second user (e.g., other than user 114) in the same manner as performed for user 114. Specifically, the combined teachings of G and Procopio do not explicitly disclose the following limitations:
wherein making the second determination that the second user is already verified comprises identifying a second proof of legitimacy associated with the second user and the storage endpoint in the user information repository.
However, N discloses the following limitations:
wherein making the second determination that the second user is already verified comprises identifying a second proof of legitimacy associated with the second user and the storage endpoint in the user information repository (“User authentication for cloud networks typically relies on the use of tokens … In an embodiment, system 100 may implement one or more tokens for each client including … a refresh token” [0027] // Fig. 1) – Examiner considers the storage environment depicted in N Fig. 1B as analogous to the storage environment depicted in G Fig. 1. As taught in N ¶0027, each client in a storage environment is provided with a respective refresh token to access a respective REST server. Applying the concept of respective refresh tokens to respective REST servers for each client in a storage environment to G, one of ordinary skill in the art would accordingly understand that two clients (i.e., a first user and “a second user”) operating in the storage environment of G Fig. 1 (e.g., User 114 and User-Impersonator 116) would each be validated by STS 102 using respective refresh tokens (i.e., a first and “a second proof of legitimacy”) stored in Server 104 (i.e., “in the user information repository”).
G, Procopio, and N are considered analogous to the claimed invention because they all relate to the same field of user identity verification in heterogeneous cloud storage environments. Therefore, it would have been obvious for someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified G and Procopio with the teachings of N and realize a method of verifying first and second users of a heterogeneous storage endpoint environment using first and second proofs of legitimacy stored in a repository. Verifying the identity of users of a heterogeneous storage endpoint environment using a token mechanism would be expected to improve the security of the storage environment by providing a mechanism through which each user of the storage environment can be provided limited scope of access to data for a limited amount of time, as disclosed in N ¶¶0027-28: “User authentication for cloud networks typically relies on the use of tokens … in which a piece of data, embodied in a signed token accompanies each request that is verified by the server for authenticity before it responds to the request … Such a token can be checked at any time independently of the user by the requestor for validation and can be used over time with strictly limited scope and age of validity.” [0027-28]
Response to Arguments
The previous objections of Claims 1 and 8 are withdrawn in view of the instant claim amendments.
The previous objection of Claim 15 is maintained.
The previous 35 U.S.C. 112(b) rejections of Claims 1-20 are withdrawn in view of the instant claim amendments.
Applicant’s arguments with respect to claims 1-4,6-11,13-18 and 20 have been considered but are moot in view of the newly-identified G and Graupner references because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
With respect to applicant’s arguments located within the 3rd paragraph of the 3rd page of remarks (numbered as page 9) continuing to the 5th page of remarks (numbered as page 12), which recites:
“Claims 1, 2, 4, 8, 9, 11, 15, 16, and 18 stand rejected under 35 U.S.C. § 103 as being unpatentable over U.S. Publication No. 2023/0030333 (hereinafter "Narayanam") in view of U.S. Publication No. 2022/0141213 (hereinafter "N '213"). To the extent that the rejection applies to the amended claims, for the reasons set forth below, this rejection is respectfully traversed. …
Moreover, Narayanam fails to cure the deficiencies of N '213. Accordingly, Narayanam, and N '213, whether viewed separately or in combination, fail to disclose or render obvious each and every limitation of the independent claims 1, 8, and 15. Further, because the Examiner has failed to establish a prima facie case of obviousness, the Applicant is under no obligation to submit evidence of non-obviousness. See MPEP § 2142. …
For the reasons stated above, Applicant submits that claims 1, 8, and 15 (from which claims 3, 5-7, 10, 12-14, 17, 19, and 20 depend) are allowable over the cited references. Moreover, Procopio fails to cure the deficiencies of Narayanam and N '213. Accordingly, Narayanam, N '213, and Procopio, whether viewed separately or in combination, fail to disclose or render obvious each and every limitation of the independent claims 1, 8, and 15. Further, because the Examiner has failed to establish a prima facie case of obviousness, the Applicant is under no obligation to submit evidence of non-obviousness”
Examiner has fully considered the aforementioned argument but finds it moot in view of the newly-identified G and Graupner references. See 35 U.S.C. 103 rejections above for additional details.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Gilpin (US 20180295126 A1) – Discloses a user verification method using tokens in a cloud resource environment (see Figs. 1 + 3)
Grube et al. (US 20120324293 A1) – Discloses a user verification method in a dispersed storage environment (see Figs. 1 + 7C)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JULIAN SCOTT MENDEL whose telephone number is (703)756-1608. The examiner can normally be reached M-F 10am - 4pm EST.
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, Rocío del Mar Pérez-Vélez can be reached at 571-270-5935. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.S.M./Examiner, Art Unit 2133
/SEAN D ROSSITER/Primary Examiner, Art Unit 2133