DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to the Amendment filed on 04/09/2026.
In the instant Amendment, claims 1, 8, and 15 have been amended; and claims 1, 8, and 15 are independent claims. Claims 1-20 have been examined and are pending. This Action is made FINAL.
Response to Arguments
Applicants’ arguments in the instant Amendment, filed on 04/09/2026, with respect to limitations listed below, have been fully considered but they are not persuasive.
Applicant’s arguments: “Goetz, Fynaardt, and Blakesley do not disclose or suggest “receiving, at a datastore service, from a tenant service, data identifying the tenant service and data identifying a first security certificate,” as recite in claims 1, 8 and 15.”
The Examiner disagrees with the Applicants. The Examiner respectfully submits that Goetz discloses receiving, at a data store service, from a tenant service, data (Goetz: par. 0151 an object is received from the user 502 by the proxy 504). More specifically, Goetz discloses a particular user 502 interacts with the storage service 500 via the API to store and receive data objects. User 502 may create a plurality of containers 702 in the user account 700 and store a plurality of data objects 704 in each of the containers 702 for retrieval [] the terms "account," "container" and "object" are generic forms of data naming that are used to direct the object storage service 500 to a specific data object [par. 0141]. In same analogous art, Fynaardt discloses data identifying the tenant service and data identifying a first security certificate (Fynaardt: par. 0019 Provider Service Identifier (PSID) values [] may be centrally managed by the SCMS on a per-tenant and/or per-device basis and applied by the SCMS to the certificates it issues to the tenant and that tenant's computerized devices that need certificates). More specifically, Fynaardt discloses different manufacturing factories and tenants (e.g., clients, customers, and subscribers) require different SCMS configurations [] a tenant can be an entity such as a company or manufacturer, a client of an SCMS, or a subscriber to a SCMS [par. 0040] and the enhanced SCMS can verify whether the device type is approved by an authorizing body (e.g., the DOT). For example, the SCMS can transmit the identifier and/or security asset to a server associated with the authorizing body to request verification and/or can compare the identifier and/or security asset to a list of approved device types stored in the SMS database [par. 0068]. Therefore, the claim is directed to non-statutory subject matter.
Applicant’s arguments: “Goetz, Fynaardt, and Blakesley do not disclose or suggest “determining, by the data store service, that the first security certificate is the first security certificate that was identified by the data received from the tenant service by matching the data identifying the first security certificate against a field of the first security certificate received from the tenant service,” as recite in claims 1, 8 and 15.”
The Examiner disagrees with the Applicants. The Examiner respectfully submits that Goetz discloses determining, by the data store service, that the first security certificate is the first security certificate that was identified by the data received from the tenant service by matching the data identifying the first security certificate against a field of the first security certificate received from the tenant service (Fynaardt: par. 0012 the system includes an SCMS host [] receive provisioning requests from respective ones of the plurality of computerized devices needing certificates, each provisioning request indicating a tenant identifier (ID) uniquely identifying a tenant of the plurality of tenants; par. 0053 when the device identifier is received, the enhanced SCMS can store the device identifier that was received and associate the device identifier with the enrollment certificates that were provisioned for the device and/or with the end entity that provisioned the device; par. 0071 for all other REST service calls, an SCMS host of the enhanced SCMS can perform a lookup to verify that a specific enrollment certificate for a device is owned by or associated with a certain tenant. That is, a cryptographic validation can be made for these service calls to ensure they are allowed). More specifically, Fynaardt discloses the enhanced SCMS can return a public key bundle, an LPF, and an LCCF to the device [] the information returned to the device can be determined based on identifying the device in 220. For example, the LPF that is returned can correspond to an LPF for the device type selected and/or customized by the end entity associated with the V2X device. Based on returning the information to the V2X device, the enhanced SCMS can set a state of the device to provisioned or partially provisioned. In various implementations, a device state of provisioned indicates that the device has its enrollment certificate pseudonym/application certificates, and other files, such as, for example, an LPF and an LCCF [par. 0082] and the validation performed in operation 809 may involve the SCMS host 808 decrypting and verifying the provisioning request, including signature verification, checking for revocation status of the device 810 that is the destination of the certificates (e.g., a computerized device) using a list of unapproved devices (e.g., a blacklist)) [par. 0126]. Therefore, the claim is directed to non-statutory subject matter.
The amended claims 1, 10 and 15 have been addressed in rejection below.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 of this title, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Goetz et al. (“Goetz,” US 2015/0220561) in view of Fynaardt et al. (“Fynaardt,” US 2019/0149342) and Blakesley et al. (“Blakesley,” US 2021/0295280).
Regarding claim 1: Goetz discloses a computer-implemented method comprising:
receiving, at a data store service, from a tenant service, data (Goetz: par. 0151 an object is received from the user 502 by the proxy 504);
generating, by the data store service, on a public server, a data storage container that stores data on a physical storage of the public server (Goetz: par. 0151 the method 800 then proceeds to block 804 where a partition identification is generated; par. 0040 a memory device 216 (e.g., FLASH memory, a random access memory (RAM) device or a read-only memory (ROM) device for storing information));
generating, by the data store service, on the public server, a security role that is associated with the tenant service and comprises a set of permissions for accessing data in the data storage container (Goetz: par. 0065 role-based strategies have been used to form a security model called Role-Based Access Control (RBAC). RBAC associates special rules, called "permissions," with roles);
receiving, at the data store service, from the tenant service, a request to access the data storage container on the public server, the request comprising an identification of the tenant service and the first security certificate (Goetz: par. 0074 the authn/authz service 400 confirms that incoming requests are being made by the user who claims to be making the call by validating a set of claims provided by the user [] the claims are initially in the form of a set of credentials (username & password, or login and API key));
sending, by the data store service, to an identity provider, credentials that prove the identity of the data store service and a request to assume the security role (Goetz: par. 0079 the authz/authn service 400 immediately authenticates and authorizes a request arriving to the cloud computing system and creates and return a token credential that can be used internally to authorize and authenticate the services; par. 0103-0112 the API calls are secured via access and secret keys, which are used to sign API calls [] the APIs can be logically grouped into sets that align with the following typical roles; pars. 0104-0112);
receiving, by the data store service, from the public server, a temporary security token that allows access to the data storage container based on the set of permissions of the security role (Goetz: par. 0074 the authn/authz service 400 issues a token that can serve as a credential; par. 0075 a token can contain or refer to a set of authorization permissions; par. 0076 token is a data [] that corresponds to an identity [] each token has a scope and a timeframe that describe the resources that can be accessed using the token).
Goetz does not explicitly disclose data identifying the tenant service and data identifying a first security certificate and determining, by the data store service, that the first security certificate is the first security certificate that was identified by the data received from the tenant service by matching the data identifying the first security certificate against a field of the first security certificate received from the tenant service.
However, Fynaardt discloses data identifying the tenant service and data identifying a first security certificate (Fynaardt: par. 0019 Provider Service Identifier (PSID) values [] may be centrally managed by the SCMS on a per-tenant and/or per-device basis and applied by the SCMS to the certificates it issues to the tenant and that tenant's computerized devices that need certificates); and
determining, by the data store service, that the first security certificate is the first security certificate that was identified by the data received from the tenant service by matching the data identifying the first security certificate against a field of the first security certificate received from the tenant service (Fynaardt: par. 0012 the system includes an SCMS host [] receive provisioning requests from respective ones of the plurality of computerized devices needing certificates, each provisioning request indicating a tenant identifier (ID) uniquely identifying a tenant of the plurality of tenants; par. 0053 when the device identifier is received, the enhanced SCMS can store the device identifier that was received and associate the device identifier with the enrollment certificates that were provisioned for the device and/or with the end entity that provisioned the device; par. 0071 for all other REST service calls, an SCMS host of the enhanced SCMS can perform a lookup to verify that a specific enrollment certificate for a device is owned by or associated with a certain tenant. That is, a cryptographic validation can be made for these service calls to ensure they are allowed).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Fynaardt with the system/method of Goetz to include determines that the first security certificate that was identified by the data received from the tenant service by matching the data identifying the first security certificate against a field of the first security certificate. One would have been motivated to providing multi-tenant operations while securely provisioning digital assets in computerized devices in order to improve efficiency in provisioning the digital assets in the computerized devices that are associated with multiple tenants (Fynaardt: par. 0002).
Goetz in view of Fynaardt does not explicitly disclose sending, by the data store service, the temporary security token to the tenant service.
However, Blakesley discloses sending, by the data store service, the temporary security token to the tenant service (Blakesley: par. 0043 the account server 104 may transmit the authorization token to the wallet application 102, where the authorization token may be utilized to determine whether the wallet application 102 is authorized to access the optimized digital receipt).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Blakesley with the system/method of Goetz and Fynaardt to include sending the temporary security token to the tenant service. One would have been motivated to providing an account server that be configured to facilitate optimized digital receipts to be provided to an application of a user device (Blakesley: par. 0015).
Regarding claim 2: Goetz in view of Fynaardt and Blakesley discloses the computer-implemented method of claim 1.
Goetz further discloses generating, by the data store service, on the public server, a second security role that is associated with the tenant service and comprises a second set of permissions for accessing data in the data storage container (Goetz: par. 0065 role-based strategies have been used to form a security model called Role-Based Access Control (RBAC). RBAC associates special rules, called "permissions," with roles);
receiving, at the data store service, from a second tenant service, a request to access the data storage container on the public server, the request comprising the identification of the tenant service and the second security certificate (Goetz: par. 0074 the authn/authz service 400 confirms that incoming requests are being made by the user who claims to be making the call by validating a set of claims provided by the user [] the claims are initially in the form of a set of credentials (username & password, or login and API key) [NOTE: If reference teaches one, then the same process can be repeated; see also abstract]);
sending, by the data store service, to the identity provider, the credentials and a request to assume the second security role (Goetz: par. 0103-0112 the API calls are secured via access and secret keys, which are used to sign API calls [] the APIs can be logically grouped into sets that align with the following typical roles; pars. 0104-0112);
receiving, by the data store service, from the public server, a second temporary security token that allows access to the data storage container based on the second set of permissions of the second security role (Goetz: par. 0074 the authn/authz service 400 issues a token that can serve as a credential; par. 0075 a token can contain or refer to a set of authorization permissions; par. 0076 token is a data [] that corresponds to an identity [] each token has a scope and a timeframe that describe the resources that can be accessed using the token).
Blakesley further discloses wherein the data received from the tenant service identifies a second security certificate (Blakesley: par. 0110 obtain a TLS certificate with embedded service provider ID, obtain an authorization token validation URL); and
sending, by the data store service, the second temporary security token to the second tenant service (Blakesley: par. 0043 the account server 104 may transmit the authorization token to the wallet application 102, where the authorization token may be utilized to determine whether the wallet application 102 is authorized to access the optimized digital receipt [NOTE: If reference teaches one, then the same process can be repeated; see also abstract]).
The motivation is the same that of claim 1 above.
Regarding claim 3: Goetz in view of Fynaardt and Blakesley discloses the computer-implemented method of claim 2.
Goetz further discloses wherein the second set of permissions comprises permissions different from the permissions in the set of permissions (Goetz: par. 0095 a user or machine may have multiple keypairs associated with different roles, projects, groups, or permissions).
Regarding claim 4: Goetz in view of Fynaardt and Blakesley discloses the computer-implemented method of claim 1.
Goetz further discloses receiving, at the data store service, from a second tenant service, a request to access the data storage container on the public server (Goetz: par. 0251 method 1400 for exposing data to a CDN provider [] the method begins at step 1402 where a request for data is received from a CDN provider);
sending, by the data store service, to the identity provider, the credentials and a request to assume the security role (Goetz: par. 0103-0112 the API calls are secured via access and secret keys, which are used to sign API calls [] the APIs can be logically grouped into sets that align with the following typical roles; pars. 0104-0112);
receiving, by the data store service, from the public server, a second temporary security token that allows access to the data storage container based on the set of permissions of the security role (Goetz: par. 0074 the authn/authz service 400 issues a token that can serve as a credential; par. 0075 a token can contain or refer to a set of authorization permissions; par. 0076 token is a data [] that corresponds to an identity [] each token has a scope and a timeframe that describe the resources that can be accessed using the token).
Blakesley further discloses the request comprising the identification of the tenant service and the first security certificate or a second security certificate, and wherein the data identifying both the tenant service and the first security certificate further identified the second security certificate (Blakesley: par. 0110 obtain a TLS certificate with embedded service provider ID, obtain an authorization token validation URL); and
sending, by the data store service, the second temporary security token to the second tenant service (Blakesley: par. 0043 the account server 104 may transmit the authorization token to the wallet application 102, where the authorization token may be utilized to determine whether the wallet application 102 is authorized to access the optimized digital receipt [NOTE: If reference teaches one, then the same process can be repeated; see also abstract]; par. 0023 multiple devices having multiple different user accounts).
The motivation is the same that of claim 1 above.
Regarding claim 5: Goetz in view of Fynaardt and Blakesley discloses the computer-implemented method of claim 1.
Goetz further discloses wherein data stored in the data storage container using temporary security tokens that allow access to the data storage container based on permissions in any security role associated with the tenant service comprises a key prefix associated with the security role and further comprising:
generating, by the data store service, on the public server, a second security role comprising a second set of permissions for accessing data in the data storage container (Goetz: par. 0065 role-based strategies have been used to form a security model called Role-Based Access Control (RBAC). RBAC associates special rules, called "permissions," with roles; each role is granted only the minimum permissions necessary for the performance of the functions associated with that role. Identities are assigned to roles, giving the users and other entities the permissions necessary to accomplish job functions), wherein the second set of permissions permits access to data in the data storage container that comprises a second key prefix and does not permit access to data in the data storage container that comprises the key prefix associated with the tenant service (Goetz: par. 0203 REST operations can be performed on containers. All operations are valid HTTP request methods [] the following list are optional query parameters that are supported with this request; par. 0207 prefix: For a string value x, causes the results to be limited to object names beginning with the substring x; par. 0223 it is possible to use directory markers with prefix and delimiter, as they will be listed as regular files but with Content-Type of application/directory);
receiving, at the data store service, from the second tenant service, a request to access the data storage container on the public server (Goetz: par. 0251 method 1400 for exposing data to a CDN provider [] the method begins at step 1402 where a request for data is received from a CDN provider);
sending, by the data store service, to the identity provider, the credentials and a request to assume the second security role (Goetz: par. 0103-0112 the API calls are secured via access and secret keys, which are used to sign API calls [] the APIs can be logically grouped into sets that align with the following typical roles; pars. 0104-0112);
receiving, by the data store service, from the public server, a second temporary security token that allows access to the data storage container based on the second set of permissions of the security role (Goetz: par. 0074 the authn/authz service 400 issues a token that can serve as a credential; par. 0075 a token can contain or refer to a set of authorization permissions; par. 0076 token is a data [] that corresponds to an identity [] each token has a scope and a timeframe that describe the resources that can be accessed using the token).
Blakesley further discloses receiving, at the data store service, from a second tenant service, data identifying both the second tenant service and a second security certificate (Blakesley: par. 0110 obtain a TLS certificate with embedded service provider ID, obtain an authorization token validation URL; par. 0023 multiple devices having multiple different user accounts);
the request comprising the second security certificate (Blakesley: par. 0110 obtain a TLS certificate with embedded service provider ID, obtain an authorization token validation URL); and
sending, by the data store service, the second temporary security token to the second tenant service (Blakesley: par. 0043 the account server 104 may transmit the authorization token to the wallet application 102, where the authorization token may be utilized to determine whether the wallet application 102 is authorized to access the optimized digital receipt; par. 0023 multiple devices having multiple different user accounts).
The motivation is the same that of claim 1 above.
Regarding claim 6: Goetz in view of Fynaardt and Blakesley discloses the computer-implemented method of claim 5.
Goetz further discloses wherein the set of permissions does not permit access to data in the data storage container that comprises the second key prefix and does permit access to data in the data storage container that comprises the key prefix associated with the tenant service (Goetz: par. 0221 the container storage uses paths or delimiters to represent different portions of the hierarchy [] supporting virtual hierarchies, the following objects are uploaded to the storage system with names representing their full filesystem path; par. 0223 it is possible to use directory markers with prefix and delimiter, as they will be listed as regular files but with Content-Type of application/directory).
Regarding claim 7: Goetz in view of Fynaardt and Blakesley discloses the computer-implemented method of claim 1.
Goetz further discloses wherein the temporary security token has an expiration time (Goetz: par. 0091 a "TTL" (time-to-live) value can be imposed on the cached values so as to force periodic reauthorization [] can be used to revoke particular tokens).
Regarding claim 8: Goetz discloses a computer-implemented system comprising:
a storage (Goetz: par. 0040 a memory device 216 (e.g., FLASH memory, a random access memory (RAM) device or a read-only memory (ROM) device for storing information); and
a processor (Goetz: par. 0040 a processor 212 for executing and otherwise processing instructions),
generates, on a public server, a data storage container that stores data on a physical storage of the public server (Goetz: par. 0151 the method 800 then proceeds to block 804 where a partition identification is generated; par. 0040 a memory device 216 (e.g., FLASH memory, a random access memory (RAM) device or a read-only memory (ROM) device for storing information)),
generates, on the public server, a security role that is associated with the tenant service and comprises a set of permissions for accessing data in the data storage container (Goetz: par. 0065 role-based strategies have been used to form a security model called Role-Based Access Control (RBAC). RBAC associates special rules, called "permissions," with roles),
receives, from the tenant service, a request to access the data storage container on the public server, the request comprising an identification of the tenant service and the first security certificate (Goetz: par. 0074 the authn/authz service 400 confirms that incoming requests are being made by the user who claims to be making the call by validating a set of claims provided by the user [] the claims are initially in the form of a set of credentials (username & password, or login and API key)),
send, to an identity provider, credentials that prove the identity of the data store service and a request to assume the security role (Goetz: par. 0079 the authz/authn service 400 immediately authenticates and authorizes a request arriving to the cloud computing system and creates and return a token credential that can be used internally to authorize and authenticate the services; par. 0103-0112 the API calls are secured via access and secret keys, which are used to sign API calls [] the APIs can be logically grouped into sets that align with the following typical roles; pars. 0104-0112);
receives, from the public server, a temporary security token that allows access to the data storage container based on the set of permissions of the security role (Goetz: par. 0074 the authn/authz service 400 issues a token that can serve as a credential; par. 0075 a token can contain or refer to a set of authorization permissions; par. 0076 token is a data [] that corresponds to an identity [] each token has a scope and a timeframe that describe the resources that can be accessed using the token).
Goetz does not explicitly disclose receives, from a tenant service, data identifying the tenant service and data identifying a first security certificate and determines that the first security certificate is the first security certificate that was identified by the data received from the tenant service by matching the data identifying the first security certificate against a field of the first security certificate.
However, Fynaardt discloses receives, from a tenant service, data identifying the tenant service and data identifying a first security certificate (Fynaardt: par. 0019 Provider Service Identifier (PSID) values [] may be centrally managed by the SCMS on a per-tenant and/or per-device basis and applied by the SCMS to the certificates it issues to the tenant and that tenant's computerized devices that need certificates); and
determines that the first security certificate is the first security certificate that was identified by the data received from the tenant service by matching the data identifying the first security certificate against a field of the first security certificate (Fynaardt: par. 0012 the system includes an SCMS host [] receive provisioning requests from respective ones of the plurality of computerized devices needing certificates, each provisioning request indicating a tenant identifier (ID) uniquely identifying a tenant of the plurality of tenants; par. 0053 when the device identifier is received, the enhanced SCMS can store the device identifier that was received and associate the device identifier with the enrollment certificates that were provisioned for the device and/or with the end entity that provisioned the device; par. 0071 for all other REST service calls, an SCMS host of the enhanced SCMS can perform a lookup to verify that a specific enrollment certificate for a device is owned by or associated with a certain tenant. That is, a cryptographic validation can be made for these service calls to ensure they are allowed).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Fynaardt with the system/method of Goetz to include determines that the first security certificate that was identified by the data received from the tenant service by matching the data identifying the first security certificate against a field of the first security certificate. One would have been motivated to providing multi-tenant operations while securely provisioning digital assets in computerized devices in order to improve efficiency in provisioning the digital assets in the computerized devices that are associated with multiple tenants (Fynaardt: par. 0002).
Goetz in view of Fynaardt does not explicitly disclose sends the temporary security token to the tenant service.
However, Blakesley discloses sends the temporary security token to the tenant service (Blakesley: par. 0043 the account server 104 may transmit the authorization token to the wallet application 102, where the authorization token may be utilized to determine whether the wallet application 102 is authorized to access the optimized digital receipt).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Blakesley with the system/method of Goetz and Fynaardt to include sending the temporary security token to the tenant service. One would have been motivated to providing an account server that be configured to facilitate optimized digital receipts to be provided to an application of a user device (Blakesley: par. 0015).
Regarding claims 9-14: Claims 9-14 are similar in scope to claims 2-7, respectively, and are therefore rejected under similar rationale.
Regarding claim 15: Goetz discloses a system comprising:
one or more computers (Goetz: par. 0033 one or more [] processing devices 118) and one or more non-transitory storage devices (Goetz: par. 0043 the information processing system 210 includes at least one type of computer-readable media that is non-transitory) storing instructions which are operable, when executed by the one or more computers, to cause the one or more computers to perform operations comprising:
receiving, at a data store service, from a tenant service, data (Goetz: par. 0151 an object is received from the user 502 by the proxy 504);
generating, by the data store service, on a public server, a data storage container that stores data on a physical storage of the public server (Goetz: par. 0151 the method 800 then proceeds to block 804 where a partition identification is generated; par. 0040 a memory device 216 (e.g., FLASH memory, a random access memory (RAM) device or a read-only memory (ROM) device for storing information));
generating, by the data store service, on the public server, a security role that is associated with the tenant service and comprises a set of permissions for accessing data in the data storage container (Goetz: par. 0065 role-based strategies have been used to form a security model called Role-Based Access Control (RBAC). RBAC associates special rules, called "permissions," with roles);
receiving, at the data store service, from the tenant service, a request to access the data storage container on the public server, the request comprising an identification of the tenant service and the first security certificate (Goetz: par. 0074 the authn/authz service 400 confirms that incoming requests are being made by the user who claims to be making the call by validating a set of claims provided by the user [] the claims are initially in the form of a set of credentials (username & password, or login and API key));
sending, by the data store service, to an identity provider, credentials that prove the identity of the data store service and a request to assume the security role (Goetz: par. 0079 the authz/authn service 400 immediately authenticates and authorizes a request arriving to the cloud computing system and creates and return a token credential that can be used internally to authorize and authenticate the services; par. 0103-0112 the API calls are secured via access and secret keys, which are used to sign API calls [] the APIs can be logically grouped into sets that align with the following typical roles; pars. 0104-0112); and
receiving, by the data store service, from the public server, a temporary security token that allows access to the data storage container based on the set of permissions of the security role (Goetz: par. 0074 the authn/authz service 400 issues a token that can serve as a credential; par. 0075 a token can contain or refer to a set of authorization permissions; par. 0076 token is a data [] that corresponds to an identity [] each token has a scope and a timeframe that describe the resources that can be accessed using the token).
Goetz does not explicitly disclose data identifying the tenant service and data identifying a first security certificate and determining, by the data store service, that the first security certificate is the first security certificate that was identified by the data received from the tenant service by matching the data identifying the first security certificate against a field of the first security certificate received from the tenant service.
However, Fynaardt discloses data identifying the tenant service and data identifying a first security certificate (Fynaardt: par. 0019 Provider Service Identifier (PSID) values [] may be centrally managed by the SCMS on a per-tenant and/or per-device basis and applied by the SCMS to the certificates it issues to the tenant and that tenant's computerized devices that need certificates); and
determining, by the data store service, that the first security certificate is the first security certificate that was identified by the data received from the tenant service by matching the data identifying the first security certificate against a field of the first security certificate received from the tenant service (Fynaardt: par. 0012 the system includes an SCMS host [] receive provisioning requests from respective ones of the plurality of computerized devices needing certificates, each provisioning request indicating a tenant identifier (ID) uniquely identifying a tenant of the plurality of tenants; par. 0024 parsing, by the SCMS host, the tenant ID from the provisioning request [] routing, by the SCMS host, based at least in part on the tenant ID, the provisioning request to at least one virtual registration authority that is communicatively connected to the SCMS host and is operable to transmit requests to a set of SCMS backend components).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Fynaardt with the system/method of Goetz to include determines that the first security certificate that was identified by the data received from the tenant service by matching the data identifying the first security certificate against a field of the first security certificate. One would have been motivated to providing multi-tenant operations while securely provisioning digital assets in computerized devices in order to improve efficiency in provisioning the digital assets in the computerized devices that are associated with multiple tenants (Fynaardt: par. 0002).
Goetz in view of Fynaardt does not explicitly disclose sending, by the data store service, the temporary security token to the tenant service.
However, Blakesley discloses sending, by the data store service, the temporary security token to the tenant service (Blakesley: par. 0043 the account server 104 may transmit the authorization token to the wallet application 102, where the authorization token may be utilized to determine whether the wallet application 102 is authorized to access the optimized digital receipt).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Blakesley with the system/method of Goetz and Fynaardt to include sending the temporary security token to the tenant service. One would have been motivated to providing an account server that be configured to facilitate optimized digital receipts to be provided to an application of a user device (Blakesley: par. 0015).
Regarding claims 16-20: Claims 16-20 are similar in scope to claims 2-6, respectively, and are therefore rejected under similar rationale.
Conclusion
THIS ACTION IS MADE FINAL. 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Fahimeh Mohammadi whose telephone number is (571)270-7857. The examiner can normally be reached Monday - Friday 9:00 - 5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham can be reached at 5712705002. 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.
/FAHIMEH MOHAMMADI/ Examiner, Art Unit 2439
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights