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 .
Response to Amendments
Applicant’s arguments have been fully considered. However, upon further consideration, a new ground(s) of rejection is made in view of Roth (2) (US 20160352753 A1) based on the new amendments to the claims 1, 11, 20.
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, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1,3-8 ,11, 13-18, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lu (US20140020051A1) in view of Roth (1) (US 9083749 B1) in view of Roth (2) (US 20160352753 A1).
Regarding claim 1, Lu teaches a system for providing secure delegated access to a digital resource, comprising:
an access control module (Para [0037]. Para [0047]: Identity Provider (IdP), where the IdP generates an authentication assertion for the delegatee with a delegation attribute statement specifying delegator, privileges, and other constraints.);
a delegation services module (Para [0047]: Identity Provider (IdP): the IdP also acts as the delegation authority that manages delegations.); and
a user interface (Para [0093]- [0094]: the user interface is the interface of the IdP.);
wherein the delegation services module (Para [0047]: Identity Provider (IdP)) is configured to:
receive, from the user interface, a delegation request (Para [0070]: for the delegation assignment, a delegator wants to delegate some tasks to a delegatee, to be done at a SP. The delegation service is advantageously applicable to any access control models that SPs use. Most access control models, except some implementations of DAC, require both delegator and delegatee have accounts with the system.);
present the list of delegable resources via a user interface (Para [0093], the IdP presents a list containing privileges i.e., resources and actions to the delegator A.);
receive from the user interface, a user selection of a delegable resource from the list (Para [0094], the delegator A selects privileges to delegate to the delegate B from the list.);
generate a delegate identifier as a technology system user (Para [0073]: the IdP generates an authentication assertion/delegate identifier for the delegatee with a delegation attribute statement specifying delegator, privileges, and other constraints.); and
wherein the access control module is configured to:
associate an access permission to the delegate identifier (Para [0003]. Para [0073]: a delegation assertion is an assertion of the correctness and authority for a delegation. The IdP generates an authentication assertion for the delegatee with a delegation attribute statement. The IdP then sends the authentication assertion to the SP. The SP verifies the authentication assertion and the delegation statement and consults with its access control engine for both the delegator and delegatee. If all is well, the SP presents services to let the delegatee to perform the delegated tasks. Para [0101]: the SP is able to store the delegation assertion/delegate identifier.), wherein the access permission provides access to the delegable resource (Para [0073], the IdP generates an authentication assertion for the delegatee with a delegation attribute statement specifying delegator, privileges, and other constraints. The IdP then sends the authentication assertion to the SP. The SP verifies the authentication assertion and the delegation statement and consults with its access control engine for both the delegator and delegatee. If all is well, the SP presents services to let the delegatee to perform the delegated tasks.).
Lu does not explicitly disclose an authentication module;
invoke the access control module to determine a list of a subset of the plurality of delegable resources offered by a technology system for which the user account has permission to delegate access based on access control permissions associated with the user account;
communicate the delegate identifier to the delegated user;
wherein the authentication module is configured to:
receive a received delegate identifier from the delegated user; and
wherein the access control module is further configured to provide access to the delegable resource based on the access permission in response to the received delegate identifier matching the delegate identifier.
Roth (1) does disclose an authentication module (Fig. 2: The policy evaluation engine);
invoke the access control module to determine a list of a subset of the plurality of delegable resources offered by a technology system for which the user account has permission to delegate access based on access control permissions associated with the user account (Col 3 lines 1-6 Col 7 lines 51-67 and Col 8 lines 1-37 Col 5 lines 17-48: the customer will have a delegation profile with the provider of the multi-tenant environment that indicates which resources or types of resources the customer can access, an amount of that access, types of tasks that can be performed with that access. The access management service 206 can receive the access policy from the customer, determine the resources and/or services associated with that customer, or an account of the customer with the provider. When a request is received from the client device 202 or from a user device 226 associated with a user having access rights to resources under the customer account, information for that request can be directed to the policy evaluation engine for the respective environment, which controls access to resources 214, 222 of the respective environments. If the request is received to the first environment 210, the policy evaluation engine 212 can determine the appropriate security policy using data stored in the at least one data store 216, and can evaluate the request using that policy to determine whether to allow or deny the request, among other possible options.);
communicate the delegate identifier to the delegated user (Col 4 lines 1-11: a communication can be sent to the user (or associated customer) to enable the user utilize the allocated resource(s) for the specified capacity, amount of data transfer, period of time, or other such metric after the request get authenticated.);
wherein the authentication module (Fig. 2: the policy evaluation engine) is configured to:
receive a received delegate identifier from the delegated user (Col 7 lines 59-67 and Col 8 lines 1-8, a request is received 404 to an interface of the distributed environment and information (e.g., an identifier of a user associated with the request, information about the customer account tied to the resources for the request, or other such information) for the request is directed to the policy engine for evaluation.);
wherein the access control module is further configured to provide access to the delegable resource based on the access permission in response to the received delegate identifier matching the delegate identifier (Col 5 lines 17-48 Col 7 lines 59-67 and Col 8 lines 1-37: the policy evaluation engine can determine 406 a version or representation of the policy language associated with the request and determine whether a policy representation matches the request. The representations can be stored in any appropriate location that is accessible to the policy evaluation engine in such a delegation profile. the request can be allowed 418 if at least one representation is determined to explicitly allow access.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Lu with the teachings of Roth (1) to include an authentication module; invoke the access control module to determine a list of a subset of the plurality of delegable resources offered by a technology system for which the user account has permission to delegate access based on access control permissions associated with the user account; communicate the delegate identifier to the delegated user; wherein the authentication module is configured to: receive a received delegate identifier from the delegated user; and wherein the access control module is further configured to provide access to the delegable resource based on the access permission in response to the received delegate identifier matching the delegate identifier in order to help ensure that resources allocated to the customer perform tasks only under direction of that customer, customer or provider can utilize one or more security policies that can be used to indicate which requests requiring access to those resources should be allowed, and which should be denied (Roth (1) Col 1 lines 22-27).
Lu and Roth (1) does not explicitly disclose a user directory comprising a database of a plurality of users, each user associated with a user account, wherein the user directory comprises contact details for each user, and ownership information for a plurality of delegable resources; and wherein the delegation request is associated one of the user account stored in the user directory and comprises user credential information for a delegated user; store the delegate identifier as an object in the user directory; verify the received delegate identifier by comparing the received delegate identifier by comparing the received delegate identifier to the delegate identifier in the user directory; authenticate the delegated user by comparing a challenge to the user information in the user directory.
Roth (2) teaches a user directory comprising a database of a plurality of users, each user associated with a user account, wherein the user directory comprises contact details for each user, and ownership information for a plurality of delegable resources (Para [0015]-[0017]: a resource provider system can utilize a set of delegation profiles that can be created, selected, or applied for one or more accounts of at least one customer, where each customer has at least some level of access to one or more resources managed and/or offered by the system. In accordance with an embodiment, a delegation profile can include information such as (a) a name (or other identifier), (b) a validation policy that specifies one or more security principals (e.g., end users), or types of security principals, which may be external to the account and which are permitted to assume the delegation profile, and (c) an authorization policy specifying the permitted actions within the account for principals which are acting within the delegation profile. In some situations, a customer of the resource provider system might specify one or more policies, rules, or other criteria that can be evaluated to determine which delegation profile to apply to a specific principal, or to a request from that principal, etc.);
and wherein the delegation request is associated one of the user account stored in the user directory (Para [0027])
store the delegate identifier as an object in the user directory (Para [0015]-[0017]: a resource provider system can utilize a set of delegation profiles that can be created, selected, or applied for one or more accounts of at least one customer, where each customer has at least some level of access to one or more resources managed and/or offered by the system. In accordance with an embodiment, a delegation profile can include information such as (a) a name (or other identifier), (b) a validation policy that specifies one or more security principals (e.g., end users), or types of security principals, which may be external to the account and which are permitted to assume the delegation profile, and (c) an authorization policy specifying the permitted actions within the account for principals which are acting within the delegation profile. In some situations, a customer of the resource provider system might specify one or more policies, rules, or other criteria that can be evaluated to determine which delegation profile to apply to a specific principal, or to a request from that principal, etc.),
and comprises user credential information for a delegated user (Para [0021]: it may be desirable to only provide event setting controls to authorized users, so the servers 102 may also prompt a user for access credentials. If a user is already logged into an account for the event software.);
verify the received delegate identifier by comparing the received delegate identifier by comparing the received delegate identifier to the delegate identifier in the user directory (Para [0025]-[0026]. Para [0056]. Fig. 4: credentials issued to a user by an identity service can enable the user to access resources under multiple accounts associated with different entities, as may be provided by multiple providers. When the user attempts to access the secure resources 212 associated with the user account, the resource provider environment 210 can analyze information for the request, such as the IP address, signature, or other such information, as well as the credentials provided with the request. The request can include at least one user credential associated with a user and issued by an identity service having a relationship with the customer and/or a provider of the resource(s) as discussed herein. Information for the request, such as the credential and other relevant information, can be analyzed 404 to attempt to determine at least one of a role or a delegation profile associated with the request. A determination can be made 406, based at least in part upon the role or delegation profile, as well as prior use data or other information, as to whether the access should be granted without additional funding. If so, the access can be granted 408 in response to the request. If additional funding is required, a determination can be made 410 as to whether funding is provided and/or specified by the request.);
authenticate the delegated user by comparing a challenge to the user information in the user directory (Para [0025]-[0026]. Para [0056]. Fig. 4: credentials issued to a user by an identity service can enable the user to access resources under multiple accounts associated with different entities, as may be provided by multiple providers. When the user attempts to access the secure resources 212 associated with the user account, the resource provider environment 210 can analyze information for the request, such as the IP address, signature, or other such information, as well as the credentials provided with the request. The request can include at least one user credential associated with a user and issued by an identity service having a relationship with the customer and/or a provider of the resource(s) as discussed herein. Information for the request, such as the credential and other relevant information, can be analyzed 404 to attempt to determine at least one of a role or a delegation profile associated with the request. A determination can be made 406, based at least in part upon the role or delegation profile, as well as prior use data or other information, as to whether the access should be granted without additional funding. If so, the access can be granted 408 in response to the request. If additional funding is required, a determination can be made 410 as to whether funding is provided and/or specified by the request.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Lu in view of Roth (1) with the teachings of Roth (2) to include a user directory comprising a database of a plurality of users, each user associated with a user account, wherein the user directory comprises contact details for each user, and ownership information for a plurality of delegable resources; and wherein the delegation request is associated one of the user account stored in the user directory and comprises user credential information for a delegated user; store the delegate identifier as an object in the user directory; verify the received delegate identifier by comparing the received delegate identifier by comparing the received delegate identifier to the delegate identifier in the user directory; authenticate the delegated user by comparing a challenge to the user information in the user directory in order to delegate access to resources in different users accounts
Regarding claim 3, Lu in view of Roth (1) in view of ROTH (2) teaches the system of claim 1, wherein the access permission is a default permission (Lu Para [0073]).
Regarding claim 4, Lu in view of Roth (1) in view of ROTH (2) teaches the system of claim 1, wherein the delegation request includes an electronic communication method (Lu Para [0089] - [0091], it would have been obvious to one of ordinary skill that the process integrates electronic communication and transactions between delegator and IdP.).
Regarding claim 5, Lu in view of Roth (1) in view of ROTH (2) teaches the system of claim 4, wherein the delegation services module sends a communication via the electronic communication method (Lu Para [0089] - [0099], it would have been obvious to one of ordinary skill that the process integrates electronic communication and transactions between delegator, delegatee, IdP, and SP.), and wherein the communication includes the delegate identifier. (Lu Para [0089] - [0099]. Para [0073]- [0074]. it would have been obvious to one of ordinary skill that the process integrates electronic communication and transactions between IdP and SP.).
Regarding claim 6, Lu in view of Roth (1) in view of ROTH (2) teaches the system of claim 1, wherein the access permission is a use-bound permission (Lu Para [0057], a delegation record includes the delegator, the service provider (SP), the delegatee, the resources that the delegatee is to access, the actions that the delegatee can do after obtaining the resource, and other things, such as assignment date and time, valid period, delegator's signature, and so on.).
Regarding claim 7, Lu in view of Roth (1) in view of ROTH (2) teaches the system of claim 1, wherein the access permission is a time-bound permission (Lu Para [0057], a delegation record includes the delegator, the service provider (SP), the delegatee, the resources that the delegatee is to access, the actions that the delegatee can do after obtaining the resource, and other things, such as assignment date and time, valid period, delegator's signature, and so on.).
Regarding claim 8, Lu in view of Roth (1) in view of ROTH (2) teaches the system of claim 1, wherein the access control module employs an attribute-based access control scheme (Lu Para [0067], the delegatee's information can be expressed in an attribute statement inside the assertion. Para [0074]).
As per claims 11,13-18, the claims claim a method essentially corresponding to the system claims 1, 3-8 above, and they are rejected, at least for the same reasons.
Regarding claim 20, Lu teaches a non-transitory computer readable storage medium (Para [0047] - [0049].), including instructions stored thereon for providing secure delegated access to a digital resource (Para [0034]- [0036]), which when read and executed by one or more computers cause the one or more computers to perform steps (Para [0047] - [0049]) comprising:
receiving a delegation request (Para [0070]: for the delegation assignment, a delegator wants to delegate some tasks to a delegatee, to be done at a SP. The delegation service is advantageously applicable to any access control models that SPs use. Most access control models, except some implementations of DAC, require both delegator and delegatee have accounts with the system.);
determining a list of delegable resources offered by a technology system for which the user account has permission to delegate access (Para [0093], the IdP presents a list containing privileges i.e., resources and actions to the delegator A.);
presenting the list of delegable resources via a user interface (Para [0093], the IdP presents a list containing privileges i.e., resources and actions to the delegator A.);
receiving from the user interface, a user selection of a delegable resource from the list (Para [0094], the delegator A selects privileges to delegate to the delegate B from the list.);
generating a delegate identifier as a technology system user (Para [0073]: the IdP generates an authentication assertion/delegate identifier for the delegatee with a delegation attribute statement specifying delegator, privileges, and other constraints.);
associating an access permission to the delegate identifier (Para [0003]. Para [0073]: a delegation assertion is an assertion of the correctness and authority for a delegation. The IdP generates an authentication assertion for the delegatee with a delegation attribute statement. The IdP then sends the authentication assertion to the SP. The SP verifies the authentication assertion and the delegation statement and consults with its access control engine for both the delegator and delegatee. If all is well, the SP presents services to let the delegatee to perform the delegated tasks. Para [0101]: the SP is able to store the delegation assertion/delegate identifier.), wherein the access permission provides access to the delegable resource (Para [0073], the IdP generates an authentication assertion for the delegatee with a delegation attribute statement specifying delegator, privileges, and other constraints. The IdP then sends the authentication assertion to the SP. The SP verifies the authentication assertion and the delegation statement and consults with its access control engine for both the delegator and delegatee. If all is well, the SP presents services to let the delegatee to perform the delegated tasks.);
Lu does not explicitly (perform an action) based on access control permissions associated with the user account; communicating the delegate identifier to the delegated user; receiving a received delegate identifier from the delegated user; and providing access to the delegable resource based on the access permission by comparing the received delegate identifier to the delegate identifier.
Roth (1) does disclose (perform an action) based on access control permissions associated with the user account (Col 3 lines 1-6 Col 7 lines 51-67 and Col 8 lines 1-37 Col 5 lines 17-48: the customer will have a delegation profile with the provider of the multi-tenant environment that indicates which resources or types of resources the customer can access, an amount of that access, types of tasks that can be performed with that access. The access management service 206 can receive the access policy from the customer, determine the resources and/or services associated with that customer, or an account of the customer with the provider. When a request is received from the client device 202 or from a user device 226 associated with a user having access rights to resources under the customer account, information for that request can be directed to the policy evaluation engine for the respective environment, which controls access to resources 214, 222 of the respective environments. If the request is received to the first environment 210, the policy evaluation engine 212 can determine the appropriate security policy using data stored in the at least one data store 216, and can evaluate the request using that policy to determine whether to allow or deny the request, among other possible options.);
communicating the delegate identifier to the delegated user (Col 4 lines 1-11: a communication can be sent to the user (or associated customer) to enable the user utilize the allocated resource(s) for the specified capacity, amount of data transfer, period of time, or other such metric after the request get authenticated.);
receiving a received delegate identifier from the delegated user (Col 7 lines 59-67 and Col 8 lines 1-8, a request is received 404 to an interface of the distributed environment and information (e.g., an identifier of a user associated with the request, information about the customer account tied to the resources for the request, or other such information) for the request is directed to the policy engine for evaluation.);
providing access to the delegable resource based on the access permission by comparing the received delegate identifier to the delegate identifier (Col 5 lines 17-48 Col 7 lines 59-67 and Col 8 lines 1-37: the policy evaluation engine can determine 406 a version or representation of the policy language associated with the request and determine whether a policy representation matches the request. The representations can be stored in any appropriate location that is accessible to the policy evaluation engine in such a delegation profile. the request can be allowed 418 if at least one representation is determined to explicitly allow access.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Lu with the teachings of Roth (1) to include (perform an action) based on access control permissions associated with the user account; communicating the delegate identifier to the delegated user; receiving a received delegate identifier from the delegated user; and providing access to the delegable resource based on the access permission by comparing the received delegate identifier to the delegate identifier in order to help ensure that resources allocated to the customer perform tasks only under direction of that customer, customer or provider can utilize one or more security policies that can be used to indicate which requests requiring access to those resources should be allowed, and which should be denied (Roth (1) Col 1 lines 22-27).
Lu and Roth (1) does not explicitly disclose wherein the delegation request is associated with a user account; storing the delegate identifier as an object in a user directory comprising a database of a plurality of users, each user associated with a user account, wherein the user directory comprises contact details for each user, and ownership information for a plurality of delegable resources a plurality of user accounts for a plurality of users, wherein the user account comprises user credential information for a delegated user; verifying the received delegate identifier by comparing the received delegate identifier by comparing the received delegate identifier to the delegate identifier in the user directory; authenticating the delegated user by comparing a challenge to the user information in the user directory.
Roth (2) teaches wherein the delegation request is associated with a user account (Para [0027]);
storing the delegate identifier as an object in a user directory comprising a database of a plurality of users, each user associated with a user account, wherein the user directory comprises contact details for each user, and ownership information for a plurality of delegable resources a plurality of user accounts for a plurality of users, wherein the user account comprises user credential information for a delegated user (Para [0015]-[0017]: a resource provider system can utilize a set of delegation profiles that can be created, selected, or applied for one or more accounts of at least one customer, where each customer has at least some level of access to one or more resources managed and/or offered by the system. In accordance with an embodiment, a delegation profile can include information such as (a) a name (or other identifier), (b) a validation policy that specifies one or more security principals (e.g., end users), or types of security principals, which may be external to the account and which are permitted to assume the delegation profile, and (c) an authorization policy specifying the permitted actions within the account for principals which are acting within the delegation profile. In some situations, a customer of the resource provider system might specify one or more policies, rules, or other criteria that can be evaluated to determine which delegation profile to apply to a specific principal, or to a request from that principal, etc.);
verifying the received delegate identifier by comparing the received delegate identifier by comparing the received delegate identifier to the delegate identifier in the user directory (Para [0025]-[0026]. Para [0056]. Fig. 4: credentials issued to a user by an identity service can enable the user to access resources under multiple accounts associated with different entities, as may be provided by multiple providers. When the user attempts to access the secure resources 212 associated with the user account, the resource provider environment 210 can analyze information for the request, such as the IP address, signature, or other such information, as well as the credentials provided with the request. The request can include at least one user credential associated with a user and issued by an identity service having a relationship with the customer and/or a provider of the resource(s) as discussed herein. Information for the request, such as the credential and other relevant information, can be analyzed 404 to attempt to determine at least one of a role or a delegation profile associated with the request. A determination can be made 406, based at least in part upon the role or delegation profile, as well as prior use data or other information, as to whether the access should be granted without additional funding. If so, the access can be granted 408 in response to the request. If additional funding is required, a determination can be made 410 as to whether funding is provided and/or specified by the request.);
authenticate the delegated user by comparing a challenge to the user information in the user directory (Para [0025]-[0026]. Para [0056]. Fig. 4: credentials issued to a user by an identity service can enable the user to access resources under multiple accounts associated with different entities, as may be provided by multiple providers. When the user attempts to access the secure resources 212 associated with the user account, the resource provider environment 210 can analyze information for the request, such as the IP address, signature, or other such information, as well as the credentials provided with the request. The request can include at least one user credential associated with a user and issued by an identity service having a relationship with the customer and/or a provider of the resource(s) as discussed herein. Information for the request, such as the credential and other relevant information, can be analyzed 404 to attempt to determine at least one of a role or a delegation profile associated with the request. A determination can be made 406, based at least in part upon the role or delegation profile, as well as prior use data or other information, as to whether the access should be granted without additional funding. If so, the access can be granted 408 in response to the request. If additional funding is required, a determination can be made 410 as to whether funding is provided and/or specified by the request.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Lu in view of Roth (1) with the teachings of Roth (2) to include wherein the delegation request is associated with a user account; storing the delegate identifier as an object in a user directory comprising a database of a plurality of users, each user associated with a user account, wherein the user directory comprises contact details for each user, and ownership information for a plurality of delegable resources a plurality of user accounts for a plurality of users, wherein the user account comprises user credential information for a delegated user; verifying the received delegate identifier by comparing the received delegate identifier by comparing the received delegate identifier to the delegate identifier in the user directory; authenticating the delegated user by comparing a challenge to the user information in the user directory in order to delegate access to resources in different users accounts.
Claims 2, 12 are rejected under 35 U.S.C. 103 as being unpatentable over Lu (US20140020051A1) in view of Roth (1) (US 9083749 B1) in view of Roth (2) (US 20160352753 A1), and in view of Steere (US 20040243644 A1).
Regarding claim 2, Lu in view of Roth (1) in view of ROTH (2) teaches the system of claim 1.
Lu in view of Roth (1) in view of ROTH (2) does not explicitly disclose wherein the delegation request includes the access permission.
Steere does disclose wherein the delegation request includes the access permission (Para [0049].).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Lu in view of Roth (1) in view of ROTH (2) with the teachings of Steere to include wherein the delegation request includes the access permission in order to specify the delegation that associated with the object.
As per claim 12, the claim claimed a method essentially corresponding to the system claim 2 above, and it is rejected, at least for the same reasons.
Claims 9, 19 are rejected under 35 U.S.C. 103 as being unpatentable over Lu (US20140020051A1) in view of Roth (1) (US 9083749 B1) in view of Roth (2) (US 20160352753 A1), and in view of Abou Mahmoud (US 20180099644 A1).
Regarding claim 9, Lu in view of Roth (1) in view of ROTH (2) teaches the system of claim 1.
Lu in view of Roth (1) in view of ROTH (2) does not explicitly disclose wherein the delegable resource is a vehicle operation resource for a vehicle.
Abou Mahmoud does disclose wherein the delegable resource is a vehicle operation resource for a vehicle (Para [0015]. Para [0030]. Para [0046] lines 1-3.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Lu in view of Roth (1) in view of ROTH (2) with the teachings of Abou Mahmoud to include wherein the delegable resource is a vehicle operation resource for a vehicle in order to utilizing a delegation process, as a way to, the owner of the vehicle may delegate his or her vehicle to a specific user, and notify delegation program of the access type for the user.
As per claim 19, the claim claimed a method essentially corresponding to the system claim 9 above, and it is rejected, at least for the same reasons.
Claims 10 is rejected under 35 U.S.C. 103 as being unpatentable over Lu (US20140020051A1) in view of Roth (1) (US 9083749 B1) in view of Roth (2) (US 20160352753 A1), and in view of Abou Mahmoud (US 20180099644 A1), in view of Singh (US 11875321 B1).
Regarding claim 10, Lu in view of Roth (1) in view of ROTH (2) in view of Abou Mahmoud teaches the system of claim 9.
Lu in view of Roth (1) in view of ROTH (2) in view of Abou Mahmoud does not explicitly disclose wherein the user interface is included as a physical interface of the vehicle.
Singh does disclose wherein the user interface is included as a physical interface of the vehicle (Col 5 lines 29-42).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Lu in view of Roth (1) in view of ROTH (2) in view Abou Mahmoud with the teachings of Singh to include wherein the user interface is included as a physical interface of the vehicle in order to allow the driver to perform integrated tasks of account management and bill payment on the screen of the smart car, which saves time and reduces errors.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUDY BAZNA whose telephone number is (703)756-1258. The examiner can normally be reached Monday - Friday 08:30 AM-05:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached on (571) 272-3739. 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.
/JUDY BAZNA/ Examiner, Art Unit 2495
/FARID HOMAYOUNMEHR/ Supervisory Patent Examiner, Art Unit 2495
Prosecution Insights