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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on 11/11/2025 has been entered.
As per instant Amendment, Claims 1, 8 and 15 are independent claims. Claims 1-20 have been examined and are pending. This Action is made Non-FINAL.
Response to Arguments
Applicants’ arguments in the instant Amendment, filed on 0/04/2025, with respect to limitations listed below, have been fully considered but they are not persuasive.
Applicant’s arguments: “Goetz in view of Blakesley do not disclose or suggest “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” as recite in claims 1, 8 and 15.”
The Examiner disagrees with the Applicants. The Examiner respectfully submits that Goetz discloses 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). More specifically, Goetz further discloses authorization is the act of confirming the capability of a user to perform some action. The authn/authz service 400 confirms that the user is authorized to perform the actions corresponding to the user's incoming requests. An individual authorization is called a "permission." [] A token can contain or refer to a set of authorization permissions [par. 0075], a token is a data (such as a string) that corresponds to an identity [] each token has a scope and a timeframe that describe the resources that can be accessed using the token [par. 0076], an endpoint is a network-accessible address, usually described by URL or URI, where a service may be accessed [par. 0077] and these different pieces can be used to collectively authenticate and authorize a user [par. 0078]. [NOTE: Goetz describe a service using credentials to prove identity to an authentication system, which then grant/fail access through a role or token. Role assumption and token issuance are equivalent outcomes.] Therefore, the examiner finds this argument not persuasive.
Applicant’s arguments with respect to amended limitation of claims 1, 8 and 15 have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection. The new reference Fynaardt et al. (US 2019/0149342) used to address the new limitations.
The amended claims 1, 8 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 both the tenant service and 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 checking the name of the first security certificate.
However, Fynaardt discloses data identifying both the tenant service and 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 checking the name 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. 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 the first security certificate is the first security certificate that was identified by the data received from the tenant service by checking the name 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 both the tenant service and 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 checking the name of the first security certificate.
However, Fynaardt discloses receives, from a tenant service, data identifying both the tenant service and 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 checking the name 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. 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 is the first security certificate that was identified by the data received from the tenant service by checking the name 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 both the tenant service and 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 checking the name of the first security certificate.
However, Fynaardt discloses data identifying both the tenant service and 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 checking the name 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. 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 the first security certificate is the first security certificate that was identified by the data received from the tenant service by checking the name 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
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