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 . In communications filed on 12/10/2025. Claims 1, 8, 11,18, and 20-23 are amended. Claims 2-3, 9, 12-13, and 19 are cancelled. Claims 1, 4-8, 10-11, 14-18, and 20-22 are pending in this examination.
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 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. This examination is in response to US Patent Application No. 17/120,330.
Examiner Note
Applicant’s amendment to claim 21 obviates previously raised claim 21, 35 U.S.C .112(a), first paragraph rejection.
Response to Arguments
Applicant's arguments filed 12/10/2025 have been fully considered but they are not persuasive:
First set of rejection:
Applicant submits on page 8 of remarks filed on 12/10/2025 regarding claim 1 that, Chhabra does not disclose the claimed operations related to "a one-time action according to a single type of access action" where a unique action tag is generated "including an identifier of the one-time action and a unique API access key for performing the one-time action on a first API."
Examiner respectfully disagrees with applicant argument for claim 1 filed on12/10/2025 on page 8 of remarks.
Chhabra discloses (Chhabra, [0034] “Upon receiving a user request to access the resource 114, the service 104 may identify the user tag 118 of the user 112, compare the user tag 118 to stored tags that are authorized to access the resource 114, and then fulfill the request by allowing the user 112 to access the resource 114 (or access, modify, and/or delete data/information associated with the resource 114).”; [0093] “As described herein, users may want to control access to various services and/or resources using tags. The tags may allow users to create, access, modify, delete, etc. services and/or resources.”) “, [0072] At 606, the service may receive a request for access by a principal to a resource. The request may come from the resource, that may communicate the request to the service for authorization. Some embodiments, all requests or certain requests may be routed to the service 104, and then to the resource, such as when the user is permitted. In various embodiments, the principal (e.g., the user, the role, etc.) may be given a token or other certificate to access the resource after determining that an access condition is satisfied. The access may expire after usage and/or a predetermined duration of time. In some embodiments, the predetermined duration of time may of any duration (e.g., 30 minutes, 24 hours, one week, one month, one year, etc.) be determined by the administrator or some other entity.”], and [0062] In some embodiments, provided that the principal is, or is associated with, a role, a time duration of the role or other conditions may be determined (e.g., expiration of the role, triggering event, etc.), which may determine a termination of the role. The role may be associated with predetermined tag(s)], and [0074] At 610, the service 104 may enable access to the resource by the principal. For example, the service 104 may communicate with the resource to cause the resource to provide access. In some embodiments, the service 104 may provide a token or other credentials to the principal and/or resource to permit access to the resource by the principal for a predetermined usage amount and/or a predetermined duration of time], and [0084] “The following section describes various use cases of tags. In some instances, sample application program interfaces (APIs) are provided to enable a particular use case. The use cases describe, among other things, Request-tags: Tags provided in the request. Customers may desire to specify which tags a user may apply to a resource, modify, or delete from a resource. For example, allow TagUser operation only if the request contains tag “Department=HR”, in this case, the tag “Department” is a request tag. Resource-tags: Tags on the resource that is being operated on. Customers may desire to control which tagged resources a user may access. For example, allow GetUser operation on the user only if the user has a department tag.”; [0093] “As described herein, users may want to control access to various services and/or resources using tags. The tags may allow users to create, access, modify, delete, etc. services and/or resources.”; [0095] “For APIs that may accept/tag tags as input, tags may be added to an action and/or a request in order to support authorization based on request tags.”], and [0019, 0031, 0062, 0074].
Applicant submits on page 9 of remarks filed on 12/10/2025 regarding claim 1 that, Chhabra does not disclose an operator account database as claimed
Examiner respectfully disagrees with applicant argument for claim 1 filed on12/10/2025 on page 9 of remarks.
[ Fig. 1 #102/104, [0023] “FIG. 1 is a block diagram of an illustrative environment 100 that includes an access management system (AMS) 102 configured to create and use access management tags for users (also referred to herein as “principal(s)”) and/or resources. The AMS 102 may deploy an access management service 104 (hereinafter “service”). The service 104 may create tags, modify tags, remove tags, and/or use tags to determine access privileges and/or other information. The service implements attribute-based access control based at least in part on tags of the users and/or the resources, rather than using identity access control that relies on access control lists for specific resources (e.g., a whitelist of user identifiers for a particular resource). By using tags, administrators and possibly other users can easily manage access to resources by creating or changing tags or tag conditions of the resources, and/or adding, removing, or changing tags of users.”; [0024] “The AMS( access management system) 102 may include or have access to user profiles 106 and/or resource profiles 108, which may include tags. A user profile 106 may store or otherwise be associated with information about a user, whereas a resource profile may store or otherwise be associated with information about a resource. Thus, tags may be assigned to users, to resources, or both...”; [0025] “The users 112(1) -(N) may be associated with tags and tag values, which may be stored and retrieved from the user profiles 106… In some embodiments, the resource profiles 106 may include access rules for accessing the resource, which may require certain tags to be associated with users to allow those users to access the resource. The tags required of a user to access a resource may be the same tags as the resource or different tags, depending on the access rules for a given resource, for example.”, and [0034] “Moreover, although a comparison of the user tags 118 and the resource tags 120 to determine whether a user 112 is authorized to access a resource 114 is discussed with respect to FIG. 1, other embodiments are contemplated herein. For instance, a user 112 that is associated with a particular user tag 118 may be authorized to access one or more resources 114 regardless of the resource tag(s) 120 associated with those resource(s) 114. That is, upon receiving a request for a user 112 to access a particular resource 114, the access management system 102 and/or the access management service 104 may determine whether access to the resource 114 by the user 112 is authorized based on just the user tag 118 of the user 112, and without considering the resource tag 120 associated with that resource 114. Upon receiving a user request to access the resource 114, the service 104 may identify the user tag 118 of the user 112, compare the user tag 118 to stored tags that are authorized to access the resource 114, and then fulfill the request by allowing the user 112 to access the resource 114 (or access, modify, and/or delete data/information associated with the resource 114). In some embodiments, all users 112 that have a particular user tag 118 are authorized to access a set of resources 114, which may include a single resource 114 or multiple resources 114. As an illustrative example, based on a request for user 112(1) to access resource 114(1), the access management system 102 and/or the access management service 104 may determine whether access is authorized based solely on the user tag 118 of that user 112(1) (project green and/or value 123), regardless of the resource tag 120 associated with resource 114(1) (project * and/or value 123).”], and [0019, 0031, 0062, 0071- 0072, 0074].
Applicant submits on page 9 of remarks filed on 12/10/2025 regarding claim 1 that, Chhabra does not maintain a dynamic access list, as claimed.
Examiner respectfully disagrees with applicant argument for claim 1 filed on12/10/2025 on page 9 of remarks.
Chhabra discloses [ Fig. 1 #102/104, [0023] “FIG. 1 is a block diagram of an illustrative environment 100 that includes an access management system (AMS) 102 configured to create and use access management tags for users (also referred to herein as “principal(s)”) and/or resources. The AMS 102 may deploy an access management service 104 (hereinafter “service”). The service 104 may create tags, modify tags, remove tags, and/or use tags to determine access privileges and/or other information. The service implements attribute-based access control based at least in part on tags of the users and/or the resources, rather than using identity access control that relies on access control lists for specific resources (e.g., a whitelist of user identifiers for a particular resource). By using tags, administrators and possibly other users can easily manage access to resources by creating or changing tags or tag conditions of the resources, and/or adding, removing, or changing tags of users.”; [0025] “In some embodiments, the resource profiles 106 may include access rules for accessing the resource, which may require certain tags to be associated with users to allow those users to access the resource. The tags required of a user to access a resource may be the same tags as the resource or different tags, depending on the access rules for a given resource, for example”].
Applicant submits on pages 9-10 of remarks filed on 12/10/2025 regarding claim 22 that, the claim 22 recites “ the group of API access actions resolves the potential error condition” The above-quoted claim language, in combination with the language of claim 1, from which claim 22 depends, is not taught or suggested by the Applied Art (whether considered individually or in any combination).
Examiner respectfully disagrees with applicant argument for claim 22 filed on12/10/2025 on pages 9-10 of remarks.
Mild, discloses [cl.6 ln.59-cl.7 ln.26], “In some embodiments of the present invention, upon recognizing an issue (e.g., receiving an indication of a failure), in the secured system 240, the one or more programs 215 notify a computing device 250 in the unsecured environment 220 of the issue. As illustrated in FIG. 1, the notification includes not only a report that an issue occurred in the secured system 240, but also, options to mitigate the issue, including but not limited to, options to reconfigure elements of the system 240. Thus, based on determining that a failure/issue has occurred in the system 240, the one or more programs 215 formulate options for mitigating the issue. Because the one or more programs 215 are transmitting a notification from a secured environment 210 to an unsecured environment 220, the one or more programs 215 include in the notification only information that can be transmitted safely over a public connection, such as a notification that there is an issue and options for mitigation. The one or more programs do not transmit secure data that they may have received when being notified of and/or diagnosing the initial issue in the system 240. Thus, the one or more programs 215 may retain data related to the issue in the secured environment 235, for example, on a memory resource of the computing resource 230, and transmit only the notification. In some embodiments of the present invention, the one or more programs 215 translate options to mitigate the issue into requests to issue calls to the system 240. Thus, if a given selection is made from the options to mitigate, the one or more programs 215 will make a call to the system 240 and/or the computing resource 230. Thus, although the options in the notifications do not include the data, if the data is required to mitigate the issue, the one or more programs generate an option that includes a request to access this data, so when the option is selected and the one or more programs 215 receive the selection, the one or more programs access the data for use in mitigating the issue.”).
Mild is directed to resolving issues in a secure system. Specifically, Mild teaches monitoring the secure system for errors and issuing a notification (i.e. a log) for a user to rectify the issue using specific API calls.
Second set of rejection:
Applicant submits on pages 10-11 of remarks filed on 12/10/2025 regarding claim 1 that, Applicant respectfully disagrees because this portion of EMI discloses relying upon "the customer ID and password" being recorded in a "customer information storage" to complete an authentication to a "control unit 41 of the bank server 40," but does not disclose "a required API action," "a group of API access actions of different types," and "a one-time action according to a single type of access action”.
Examiner respectfully disagrees with applicant argument for claim 1 filed on12/10/2025 on pages 10-11 of remarks.
EMI discloses [0002] Various information is being provided from the service providing site via API (Application Programming Interface). Disclosure of bank APIs for obtaining information from banking systems is also being considered. This bank API is used to individually service existing functions such as balance inquiry and fund transfer( equated to API actions of different type) and use them from external applications.
While EMI. Discloses the bank API is used to individually service existing functions such as balance inquiry and fund transfer and use them from external applications. However, does not explicitly discloses one-time action according to a single type of access action, and
Roesner discloses [Abstract, an access system is described herein which allows an application to access a system-level and/or application-specific user-owned resource based on a user's interaction with an intent-based access mechanism. For example, the intent-based access mechanism may correspond to a gadget that is embedded in an application user interface provided by the application, and/or logic for detecting a permission-granting input sequence. The access system accommodates different types of intent-based access mechanisms. One type is a scheduled intent-based access mechanism. Another type provides access to two or more user-owned resources. Further, the access system includes a mechanism for determining whether the application is permitted to use an intent-based access mechanism], and [0098] In a second case, the gadget or PG input sequence grants an application one-time access to a particular user-owned resource. To do this, the access management module 408 sends an InitContentTransfer call to the operating system 114. That transfer call instructs the operating system 114 to push or pull appropriate data to or from a destination location (dest) or source location (src), respectively].
Applicant submits on pages 10-11 of remarks filed on 12/10/2025 regarding claim 1 that, Applicant respectfully disagrees with this portion of EMI discloses "the API management unit 411 of the bank server 40 issues an APIID and generates an APIID management table 430 associated with a customer code and an application ID" where recording a "no-update flag" triggers allowing an API transaction, but does not disclose a dynamic access list in that the list is used to register "the unique action tag, including the identifier of the one-time action and the unique API access key, and mapping the unique API access key to the selected available operator account." The Current Office Action indicates that part of the APIID management table corresponds to the claimed "dynamic access list" and that the bank server corresponds to the "security-sensitive computing system," but does not indicate how EMI discloses "the unique action tag" and "the unique API access key." Applicant further amends the limitation herein to emphasize the nature of the identifier and the function of the dynamic access list. EMI does not disclose "registering, to the dynamic access list, the unique action tag, including the identifier of the one-time action and the unique API access key, and mapping the unique API access key to the selected available operator account.
Examiner respectfully disagrees with applicant argument for claim 1 filed on12/10/2025 on pages 10-11 of remarks.
EMI discloses [0026] (the ”service code” corresponds to the "identifier of the one-time action” of the present application, the ”APIID” corresponds to the "unique API access key” of the present application, and (a part of) the ”APIID management table” corresponds to the "unique action tag” of the present application), and the APIID management table records (maintains) customer IDs (corresponding to the "selected operator account” of the present application), application IDs, service codes, APIID, APIID update flags, approval cancellation dates and times, APIID update reasons, API transaction suspension flags, and suspension dates and times), and ( Fig. 3 and corresponding text for more details); and
[see FIG 4, [0045] (The ”(part of) the APIID management table” corresponds to the "dynamic access list” of the present application); the API management unit 411 of the bank server 40 (corresponding to the ”security-sensitive computing system” of the present application) issues an APIID and generates an APIID management table 430 associated with a customer code and an application ID; in the initial stage, a no-update flag is recorded in the APIID update flag data area ).
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
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 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.
First Office Action:
Claims 1, 4-8, 10-11, 14-18, and 20-21 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Chhabra et al., (US 2020/0007455 A1) hereinafter referred to as Chhabra.
(Currently Amended) A method for controlling application programming interface (API) access actions, the method comprising:
(Chhabra, Fig. 1-2; [0069], [0095] The systems and processes described herein generate, maintain, and/or update an infrastructure for the service 104 to facilitate the tagging of users and/or resources. In some embodiments, the service 104 may provide new APIs to tag and untag users and/or roles (e.g., TagUser, TagRole, UntagUser, UntagRole, ListUserTags, ListRoleTags, etc.). In order to facilitate authorization of access to various users, resources, etc. based on user tags and/or resource tags, the authorization techniques associated with the service 104 that treat user and/or role as a resource may be updated to include tags in the resource context. Moreover, in order to facilitate authorization based on the calling principal, Auth Runtime Service (ARS) may populate tags of the calling principal in the principal context. For APIs that may accept/tag tags as input, tags may be added to an action and/or a request in order to support authorization based on request tags.), and [0116] The policy management service 1100F, in one example, is a network service configured to manage policies on behalf of users or customers of the system, or a larger system of which the system is a part. The policy management service 1100F can include an interface (e.g. API or GUI) that enables customers to submit requests related to the management of policy, such as a security policy. Such requests can, for instance, be requests to add, delete, change or otherwise modify policy for a customer, service, or system, or for other administrative actions, such as providing an inventory of existing policies and the like]
[0084] The following section describes various use cases of tags. In some instances, sample application program interfaces (APIs) are provided to enable a particular use case. The use cases describe, among other things, Request-tags: Tags provided in the request. Customers may desire to specify which tags a user may apply to a resource, modify, or delete from a resource. For example, allow TagUser operation only if the request contains tag “Department=HR”, in this case, the tag “Department” is a request tag. Resource-tags: Tags on the resource that is being operated on. Customers may desire to control which tagged resources a user may access. For example, allow GetUser operation on the user only if the user has a department tag]; and
determining a required API access action to be performed on a security-sensitive computing system(Chhabra, [0034] “That is, upon receiving a request for a user 112 to access a particular resource 114, the access management system 102 and/or the access management service 104 may determine whether access to the resource 114 by the user 112 is authorized based on just the user tag 118 of the user 112, and without considering the resource tag 120 associated with that resource 114. Upon receiving a user request to access the resource 114, the service 104 may identify the user tag 118 of the user 112, compare the user tag 118 to stored tags that are authorized to access the resource 114, and then fulfill the request by allowing the user 112 to access the resource 114 (or access, modify, and/or delete data/information associated with the resource 114). In some embodiments, all users 112 that have a particular user tag 118 are authorized to access a set of resources 114, which may include a single resource 114 or multiple resources 114. As an illustrative example, based on a request for user 112(1) to access resource 114(1), the access management system 102 and/or the access management service 104 may determine whether access is authorized based solely on the user tag 118 of that user 112(1) (project green and/or value 123), regardless of the resource tag 120 associated with resource 114(1) (project * and/or value 123).”], and [0084] The following section describes various use cases of tags. In some instances, sample application program interfaces (APIs) are provided to enable a particular use case. The use cases describe, among other things, Request-tags: Tags provided in the request. Customers may desire to specify which tags a user may apply to a resource, modify, or delete from a resource. For example, allow TagUser operation only if the request contains tag “Department=HR”, in this case, the tag “Department” is a request tag. Resource-tags: Tags on the resource that is being operated on. Customers may desire to control which tagged resources a user may access. For example, allow GetUser operation on the user only if the user has a department tag]; and
the required API access action including a group of API access actions of different types [0034] … Upon receiving a user request to access the resource 114, the service 104 may identify the user tag 118 of the user 112, compare the user tag 118 to stored tags that are authorized to access the resource 114, and then fulfill the request by allowing the user 112 to access the resource 114 (or access, modify, and/or delete data/information associated with the resource 114)( equated to access action of different type). …], and [0041] The access module 208 may implement, at least in part, one or more of the access policies 214. For example, an access policy may allow or deny a user access to a resource based at least in part on tags of the user, tags of the resource, or both. For example, a policy may include tags required to access a particular resource, which must be held by a user to access that resource. Another policy may require the user and the resource to have certain matching tags in order for the user to access the resource. For example, only individuals having a particular role may be authorized to access a resource, and those individuals may be associated with one or more tags that allow the individuals to access the resource. The same or different tags may also allow individuals to modify or delete that resource, of a different resource. Other policies that are based on the tags of the user and/or the resource may be specified in the access policies 214 and implemented/enforced by the access module 208], and [0084] The following section describes various use cases of tags. In some instances, sample application program interfaces (APIs) are provided to enable a particular use case. The use cases describe, among other things, Request-tags: Tags provided in the request. Customers may desire to specify which tags a user may apply to a resource, modify, or delete from a resource. For example, allow TagUser operation only if the request contains tag “Department=HR”, in this case, the tag “Department” is a request tag. Resource-tags: Tags on the resource that is being operated on. Customers may desire to control which tagged resources a user may access. For example, allow GetUser operation on the user only if the user has a department tag]; and
the group of API access actions including a one-time action according to a single type of access action (Chhabra, [0034] “Upon receiving a user request to access the resource 114, the service 104 may identify the user tag 118 of the user 112, compare the user tag 118 to stored tags that are authorized to access the resource 114, and then fulfill the request by allowing the user 112 to access the resource 114 (or access, modify, and/or delete data/information associated with the resource 114).”; [0093] “As described herein, users may want to control access to various services and/or resources using tags. The tags may allow users to create, access, modify, delete, etc. services and/or resources.”) “, [0072] At 606, the service may receive a request for access by a principal to a resource. The request may come from the resource, that may communicate the request to the service for authorization. Some embodiments, all requests or certain requests may be routed to the service 104, and then to the resource, such as when the user is permitted. In various embodiments, the principal (e.g., the user, the role, etc.) may be given a token or other certificate to access the resource after determining that an access condition is satisfied. The access may expire after usage and/or a predetermined duration of time. In some embodiments, the predetermined duration of time may of any duration (e.g., 30 minutes, 24 hours, one week, one month, one year, etc.) be determined by the administrator or some other entity.”], and [0062] In some embodiments, provided that the principal is, or is associated with, a role, a time duration of the role or other conditions may be determined (e.g., expiration of the role, triggering event, etc.), which may determine a termination of the role. The role may be associated with predetermined tag(s)], and [0074] At 610, the service 104 may enable access to the resource by the principal. For example, the service 104 may communicate with the resource to cause the resource to provide access. In some embodiments, the service 104 may provide a token or other credentials to the principal and/or resource to permit access to the resource by the principal for a predetermined usage amount and/or a predetermined duration of time], and [0019]; and
selecting, from an operator account database, an available operator account listed in the operator account database, the operator account database indicating which operators are on duty to perform the one-time action on a first API, the available operator account indicated in the operator account database as on duty(Chhabra, [0071-72] “At 604, the service may specify a principal tag that permits access to the resource."; Fig. 1-2 #106/104, [0024] “The AMS( access management system) 102 may include or have access to user profiles 106 and/or resource profiles 108, which may include tags. A user profile 106 may store or otherwise be associated with information about a user, whereas a resource profile may store or otherwise be associated with information about a resource. Thus, tags may be assigned to users, to resources, or both... “At 606, the service may receive a request for access by a principal to a resource. The request may come from the resource, that may communicate the request to the service for authorization. Some embodiments, all requests or certain requests may be routed to the service 104, and then to the resource, such as when the user is permitted. In various embodiments, the principal (e.g., the user, the role, etc.) may be given a token or other certificate to access the resource after determining that an access condition is satisfied. The access may expire after usage and/or a predetermined duration of time. In some embodiments, the predetermined duration of time may of any duration (e.g., 30 minutes, 24 hours, one week, one month, one year, etc.) be determined by the administrator or some other entity.”; [0025] “The users 112(1) -(N) may be associated with tags and tag values, which may be stored and retrieved from the user profiles 106… In some embodiments, the resource profiles 106 may include access rules for accessing the resource, which may require certain tags to be associated with users to allow those users to access the resource. The tags required of a user to access a resource may be the same tags as the resource or different tags, depending on the access rules for a given resource, for example.”), and [0019, 0031, 0062, 0074]; and
generating a unique action tag including an identifier of the one-time action and a unique API access key for performing the one-time action on to the first API (Chhabra, [0072] “At 606, the service may receive a request for access by a principal to a resource. The request may come from the resource, that may communicate the request to the service for authorization. Some embodiments, all requests or certain requests may be routed to the service 104, and then to the resource, such as when the user is permitted. In various embodiments, the principal (e.g., the user, the role, etc.) may be given a token or other certificate to access the resource after determining that an access condition is satisfied. The access may expire after usage and/or a predetermined duration of time. In some embodiments, the predetermined duration of time may of any duration (e.g., 30 minutes, 24 hours, one week, one month, one year, etc.) be determined by the administrator or some other entity.”; Chhabra, [0084] “The following section describes various use cases of tags. In some instances, sample application program interfaces (APIs) are provided to enable a particular use case. The use cases describe, among other things, Request-tags: Tags provided in the request. Customers may desire to specify which tags a user may apply to a resource, modify, or delete from a resource. For example, allow TagUser operation only if the request contains tag “Department=HR”, in this case, the tag “Department” is a request tag. Resource-tags: Tags on the resource that is being operated on. Customers may desire to control which tagged resources a user may access. For example, allow GetUser operation on the user only if the user has a department tag.”; [0093] “As described herein, users may want to control access to various services and/or resources using tags. The tags may allow users to create, access, modify, delete, etc. services and/or resources.”; [0095] “For APIs that may accept/tag tags as input, tags may be added to an action and/or a request in order to support authorization based on request tags.”], and [0019, 0031, 0062, 0074]; and
maintaining a dynamic access list having identifiers of the group of API access actions and mapping of unique API access keys to selected operator accounts (Chhabra, Fig. 1 #102/104, [0023] “FIG. 1 is a block diagram of an illustrative environment 100 that includes an access management system (AMS) 102 configured to create and use access management tags for users (also referred to herein as “principal(s)”) and/or resources. The AMS 102 may deploy an access management service 104 (hereinafter “service”). The service 104 may create tags, modify tags, remove tags, and/or use tags to determine access privileges and/or other information. The service implements attribute-based access control based at least in part on tags of the users and/or the resources, rather than using identity access control that relies on access control lists for specific resources (e.g., a whitelist of user identifiers for a particular resource). By using tags, administrators and possibly other users can easily manage access to resources by creating or changing tags or tag conditions of the resources, and/or adding, removing, or changing tags of users.”; [0025] “In some embodiments, the resource profiles 106 may include access rules for accessing the resource, which may require certain tags to be associated with users to allow those users to access the resource. The tags required of a user to access a resource may be the same tags as the resource or different tags, depending on the access rules for a given resource, for example”]; and
registering, to the dynamic access list, the unique action tag, including the identifier of the one-time action and the unique API access key, and mapping the unique API access key to the selected available operator account (Chhabra, Fig. 1 #102/104, [0023] “FIG. 1 is a block diagram of an illustrative environment 100 that includes an access management system (AMS) 102 configured to create and use access management tags for users (also referred to herein as “principal(s)”) and/or resources. The AMS 102 may deploy an access management service 104 (hereinafter “service”). The service 104 may create tags, modify tags, remove tags, and/or use tags to determine access privileges and/or other information. The service implements attribute-based access control based at least in part on tags of the users and/or the resources, rather than using identity access control that relies on access control lists for specific resources (e.g., a whitelist of user identifiers for a particular resource). By using tags, administrators and possibly other users can easily manage access to resources by creating or changing tags or tag conditions of the resources, and/or adding, removing, or changing tags of users.”; [0025] “In some embodiments, the resource profiles 106 may include access rules for accessing the resource, which may require certain tags to be associated with users to allow those users to access the resource. The tags required of a user to access a resource may be the same tags as the resource or different tags, depending on the access rules for a given resource, for example”]; and[ 0072]; and
granting, for the selected operator account, an authorization via the dynamic access list and the unique action tag (Chhabra, [0034] “Moreover, although a comparison of the user tags 118 and the resource tags 120 to determine whether a user 112 is authorized to access a resource 114 is discussed with respect to FIG. 1, other embodiments are contemplated herein. For instance, a user 112 that is associated with a particular user tag 118 may be authorized to access one or more resources 114 regardless of the resource tag(s) 120 associated with those resource(s) 114. That is, upon receiving a request for a user 112 to access a particular resource 114, the access management system 102 and/or the access management service 104 may determine whether access to the resource 114 by the user 112 is authorized based on just the user tag 118 of the user 112, and without considering the resource tag 120 associated with that resource 114. Upon receiving a user request to access the resource 114, the service 104 may identify the user tag 118 of the user 112, compare the user tag 118 to stored tags that are authorized to access the resource 114, and then fulfill the request by allowing the user 112 to access the resource 114 (or access, modify, and/or delete data/information associated with the resource 114). In some embodiments, all users 112 that have a particular user tag 118 are authorized to access a set of resources 114, which may include a single resource 114 or multiple resources 114. As an illustrative example, based on a request for user 112(1) to access resource 114(1), the access management system 102 and/or the access management service 104 may determine whether access is authorized based solely on the user tag 118 of that user 112(1) (project green and/or value 123), regardless of the resource tag 120 associated with resource 114(1) (project * and/or value 123).”]; and
API access action privileges for the security-sensitive computing system, the authorization being limited to perform only the one-time action mapped to the selected operator account on the first API(Chhabra, [0034] “Moreover, although a comparison of the user tags 118 and the resource tags 120 to determine whether a user 112 is authorized to access a resource 114 is discussed with respect to FIG. 1, other embodiments are contemplated herein. For instance, a user 112 that is associated with a particular user tag 118 may be authorized to access one or more resources 114 regardless of the resource tag(s) 120 associated with those resource(s) 114. That is, upon receiving a request for a user 112 to access a particular resource 114, the access management system 102 and/or the access management service 104 may determine whether access to the resource 114 by the user 112 is authorized based on just the user tag 118 of the user 112, and without considering the resource tag 120 associated with that resource 114. Upon receiving a user request to access the resource 114, the service 104 may identify the user tag 118 of the user 112, compare the user tag 118 to stored tags that are authorized to access the resource 114, and then fulfill the request by allowing the user 112 to access the resource 114 (or access, modify, and/or delete data/information associated with the resource 114). In some embodiments, all users 112 that have a particular user tag 118 are authorized to access a set of resources 114, which may include a single resource 114 or multiple resources 114. As an illustrative example, based on a request for user 112(1) to access resource 114(1), the access management system 102 and/or the access management service 104 may determine whether access is authorized based solely on the user tag 118 of that user 112(1) (project green and/or value 123), regardless of the resource tag 120 associated with resource 114(1) (project * and/or value 123).”], and [0019, 0031, 0062, 0072, 0074]; and
responsive to the one-time action being completed by an operator using the unique action tag, cancelling further one-time actions based on the unique action tag, and revoking a further use of the unique API access key to perform additional types API access action action(Chhabra, [0072] “At 606, the service may receive a request for access by a principal to a resource. The request may come from the resource, that may communicate the request to the service for authorization. Some embodiments, all requests or certain requests may be routed to the service 104, and then to the resource, such as when the user is permitted. In various embodiments, the principal (e.g., the user, the role, etc.) may be given a token or other certificate to access the resource after determining that an access condition is satisfied. The access may expire after usage and/or a predetermined duration of time. In some embodiments, the predetermined duration of time may of any duration (e.g., 30 minutes, 24 hours, one week, one month, one year, etc.) be determined by the administrator or some other entity.”], and [0019, 0031, 0062, 0074].
Regarding claims 4, and 14, Chhabra discloses wherein the group of API access actions refers to different APIs [0084] The following section describes various use cases of tags. In some instances, sample application program interfaces (APIs) are provided to enable a particular use case. The use cases describe, among other things, Request-tags: Tags provided in the request. Customers may desire to specify which tags a user may apply to a resource, modify, or delete from a resource. For example, allow TagUser operation only if the request contains tag “Department=HR”, in this case, the tag “Department” is a request tag], and [ 0108] Each of the services shown in FIG. 11 can also expose web service interfaces that enable a caller to submit appropriately configured API calls to the various services through web service requests. The various web services can also expose GUIs, command line interfaces (“CLIs”), and/or other types of interfaces for accessing the functionality that they provide].
Regarding claims 5, and 15, Chhabra discloses wherein the security sensitive system [reads on an access management system 900 that can be configured to implement aspect of the functionality, see Chhabra para 0098] is implemented as a secure appliance in form of a secure enclave [reads on the system being part of a larger system that provides the additional computing resources that include, without limitation, data storage resources, data processing resources, such as virtual machine (VM) instances, networking resources, data communication resources, network services, and other types of resources, see Chhabra para 0098.], and [0116] The policy management service 1100F, in one example, is a network service configured to manage policies on behalf of users or customers of the system, or a larger system of which the system is a part. The policy management service 1100F can include an interface (e.g. API or GUI) that enables customers to submit requests related to the management of policy, such as a security policy. Such requests can, for instance, be requests to add, delete, change or otherwise modify policy for a customer, service, or system, or for other administrative actions, such as providing an inventory of existing policies and the like.
Regarding claims 6, and 16, Chhabra disclose monitoring and analyzing a system log file; wherein the determining the required API access action is based on the monitoring and analyzing [0063-0066] FIG. 5 is a flow diagram of an illustrative process 500 to fulfill access requests for resources using tags of a user and tag condition(s) of a resource. The process 500 is described with reference to the environment 100 and the computing architecture 200 and may be performed by the access management service 104. Of course, the process 500 may be performed in other similar and/or different environments. At 502, the service 104 may receive a request to access a resource. The request may be received from a principal (e.g., a user, a role, etc.) via a device (e.g., a user device). For example, a principal may desire to access a data in a storage device, or a file stored in a remote computing device (e.g., a server). At 504, the service 104 may determine tag condition(s) associated with the resource. For example, the tag condition or conditions may include certain tags that are required of the user to gain access. In some embodiments, the tag condition(s) may include the user having certain tags that are also held by the resource. For example, a resource may have a tag and value of “Project”:Green. Only users with this same tag could access the resource if a requirement were made/enforced to have matching tags between the user and resource. In some embodiments, the tag condition may be to have some tags match, but possibly not all. An example condition may be that the “Project” tag must match, but not a “CostCenter” tag, when the resource include both of these tags. In various embodiments, the resource may include a described tag condition (tag permission) that is different than the tags of the resource. Using the tag permission, the tags may include wildcards (allows all users having the tag regardless of the tag value held by the user) and/or tags with multiple different values (e.g., “Project”:Green and Red), or negative restrictions (e.g., Not “Project”:Pink, etc.). Of course, other tag condition(s) may be contemplated, including combining two or more different conditions discussed herein. At 506, the service 104 may determine tags of the principal and/or resource. The tags may be used to determine whether to allow or deny access per a decision operation 508].
Regarding claims 7, and 17, Chhabra discloses wherein the API access action is at least an action selected out of the group of actions comprising: a modification to a configuration of the security-sensitive computing system, [access to the resource] and is an enablement of a component of the security-sensitive computing system [reads on a request to create or deploy a new resource or existing resource, which are performed by the access management service, see Chhabra para 0079-0080. The Examiner creating or deploying a new resource or existing resource to be the same as an enablement of a component the security-sensitive computing system.], and (Chhabra, [0034] “That is, upon receiving a request for a user 112 to access a particular resource 114, the access management system 102 and/or the access management service 104 may determine whether access to the resource 114 by the user 112 is authorized based on just the user tag 118 of the user 112, and without considering the resource tag 120 associated with that resource 114. Upon receiving a user request to access the resource 114, the service 104 may identify the user tag 118 of the user 112, compare the user tag 118 to stored tags that are authorized to access the resource 114, and then fulfill the request by allowing the user 112 to access the resource 114 (or access, modify, and/or delete data/information associated with the resource 114). In some embodiments, all users 112 that have a particular user tag 118 are authorized to access a set of resources 114, which may include a single resource 114 or multiple resources 114. As an illustrative example, based on a request for user 112(1) to access resource 114(1), the access management system 102 and/or the access management service 104 may determine whether access is authorized based solely on the user tag 118 of that user 112(1) (project green and/or value 123), regardless of the resource tag 120 associated with resource 114(1) (project * and/or value 123).”), and [0116] The policy management service 1100F, in one example, is a network service configured to manage policies on behalf of users or customers of the system, or a larger system of which the system is a part. The policy management service 1100F can include an interface (e.g. API or GUI) that enables customers to submit requests related to the management of policy, such as a security policy. Such requests can, for instance, be requests to add, delete, change or otherwise modify policy for a customer, service, or system, or for other administrative actions, such as providing an inventory of existing policies and the like].
Regarding claims 8, and 18, Chhabra, discloses monitoring a completion of the API access action before cancelling further one-time actions includes: monitoring a completion of the one-time action (Chhabra, [0072] “At 606, the service may receive a request for access by a principal to a resource. The request may come from the resource, that may communicate the request to the service for authorization. Some embodiments, all requests or certain requests may be routed to the service 104, and then to the resource, such as when the user is permitted. In various embodiments, the principal (e.g., the user, the role, etc.) may be given a token or other certificate to access the resource after determining that an access condition is satisfied. The access may expire after usage and/or a predetermined duration of time. In some embodiments, the predetermined duration of time may of any duration (e.g., 30 minutes, 24 hours, one week, one month, one year, etc.) be determined by the administrator or some other entity.”), and [0031] As discussed above, user tags 118 may be granted to users by administrators or other authorized users. For example, an administrator may create a new user and add tags to that new user. An administrator may also remove tags, modify tags or tag values, and/or add tags to an existing user. In some embodiments, a user may assume a role and may be provided tags for the role on a temporary or permanent basis], and [0019, 0031, 0062, 0074].
Regarding claim 10, Chhabra discloses sending a notification to the selected operator account , wherein the notification comprises a detail about the API access action [ see FIG. 1 and corresponding text for more detail, [0027-0030] The AMS 102 may deploy the service 104 to determine which users may access which of the resources based on tags of the user and/or tags or tag conditions of the resources. A tag condition may be different than a tag. For example, a resource may have a tag “Project”:Green, but a tag condition of “Project”:“*”, which requires a user to have a project tag, but no specific tag value for that project tag. In the example shown in FIG. 1, the service 104 may allow the first user 112(1) to access the first resource 114(1) since the first user includes a “project” tag and includes a “CostCenter” tag having a tag value of 123, as shown in the tag conditions associated with the first resource 114(1). The service 104 may allow the first user 112(1) to also access the second resource 114(2) since the first user includes a “project” tag with the value “Green” and includes a “CostCenter” tag, as shown in the tag conditions associated with the second resource 114(2). The service may deny access by the first user to the last resource 114(M) since the first user 112(1) does not have the “Project” tag value of “Red”, but instead has a “Project” tag value of “Green”. Continuing with the example shown in FIG. 1, the service 104 may allow the second user 112(2) to access the second resource 114(2) since the second user includes a “project” tag value of “Green” and includes a “CostCenter” tag. The service may deny access by the second user to the first resource 114(1) and the last resource 114(M) since the second user 112(2) does not have the “CostCenter” tag value of “123”, and because the second user 112(2) does not have the “Project” tag value of “Red”, respectively. Continuing with the example shown in FIG. 1, the service 104 may allow the last user 112(3) to access the last resource 114(M) since the last user includes a “project” tag value of “Red” and includes a “CostCenter” tag value of 789. The service may deny access by the last user to the first resource 114(1) and the second resource 114(2) since the last user 112(N) does not have the “CostCenter” tag value of “123”, and because the last user 112(N) does not have the “Project” tag value of “Green”, respectively. Accordingly, and as illustrated in FIG. 1, a single user 112 or corresponding user device 110 may be authorized to access a single resource 114, a single user 112/user device 110 may be authorized to access multiple resources 114, and/or multiple users 112/user devices 110 may be authorized to access a single resource 114], and [0041] The access module 208 may implement, at least in part, one or more of the access policies 214. For example, an access policy may allow or deny a user access to a resource based at least in part on tags of the user, tags of the resource, or both. For example, a policy may include tags required to access a particular resource, which must be held by a user to access that resource. Another policy may require the user and the resource to have certain matching tags in order for the user to access the resource. For example, only individuals having a particular role may be authorized to access a resource, and those individuals may be associated with one or more tags that allow the individuals to access the resource. The same or different tags may also allow individuals to modify or delete that resource, of a different resource. Other policies that are based on the tags of the user and/or the resource may be specified in the access policies 214 and implemented/enforced by the access module 208.], and [see FIGs 3, and 5 and corresponding text for more detail].
Regarding claim 11, the claim is interpreted and rejected for the same rational set forth in claim 1.
Regarding claim 20, the claim is interpreted and rejected for the same rational set forth in claim 1.
Regarding claim 21, Chhabra discloses wherein determining the required API access action is based on a determination that a required maintenance task shall be performed, the required API access action completes a required maintenance task through the group of API access actions, including individual actions of a change access and a delete access (Chhabra, [0034] “Moreover, although a comparison of the user tags 118 and the resource tags 120 to determine whether a user 112 is authorized to access a resource 114 is discussed with respect to FIG. 1, other embodiments are contemplated herein. For instance, a user 112 that is associated with a particular user tag 118 may be authorized to access one or more resources 114 regardless of the resource tag(s) 120 associated with those resource(s) 114. That is, upon receiving a request for a user 112 to access a particular resource 114, the access management system 102 and/or the access management service 104 may determine whether access to the resource 114 by the user 112 is authorized based on just the user tag 118 of the user 112, and without considering the resource tag 120 associated with that resource 114. Upon receiving a user request to access the resource 114, the service 104 may identify the user tag 118 of the user 112, compare the user tag 118 to stored tags that are authorized to access the resource 114, and then fulfill the request by allowing the user 112 to access the resource 114 (or access, modify, and/or delete data/information associated with the resource 114). In some embodiments, all users 112 that have a particular user tag 118 are authorized to access a set of resources 114, which may include a single resource 114 or multiple resources 114. As an illustrative example, based on a request for user 112(1) to access resource 114(1), the access management system 102 and/or the access management service 104 may determine whether access is authorized based solely on the user tag 118 of that user 112(1) (project green and/or value 123), regardless of the resource tag 120 associated with resource 114(1) (project * and/or value 123).”), and [0034] … Upon receiving a user request to access the resource 114, the service 104 may identify the user tag 118 of the user 112, compare the user tag 118 to stored tags that are authorized to access the resource 114, and then fulfill the request by allowing the user 112 to access the resource 114 (or access, modify, and/or delete data/information associated with the resource 114)( equated to access action of different type). …], and [0041] The access module 208 may implement, at least in part, one or more of the access policies 214. For example, an access policy may allow or deny a user access to a resource based at least in part on tags of the user, tags of the resource, or both. For example, a policy may include tags required to access a particular resource, which must be held by a user to access that resource. Another policy may require the user and the resource to have certain matching tags in order for the user to access the resource. For example, only individuals having a particular role may be authorized to access a resource, and those individuals may be associated with one or more tags that allow the individuals to access the resource. The same or different tags may also allow individuals to modify or delete that resource, of a different resource. Other policies that are based on the tags of the user and/or the resource may be specified in the access policies 214 and implemented/enforced by the access module 208].
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Chhabra as applied to claim 1 above, and further in view of Mild et al. (US 10419564 B2) filed in IDS 12/14/2020.
Regarding claim 22 Chhabra discloses the method of claim 1, but fails to explicitly disclose further comprising:
monitoring and analyzing a system log file for an error condition.
wherein:
the API access actions resolve the error condition.
However, Mild teaches monitoring and analyzing a system log file for potential error conditions; (Mild, [cl.3 ln.38-ln.60] “The advantages of aspects of embodiments of the present invention are inextricably tied to computing at least because the one or more programs mitigate failures in secure computing system in a novel manner by providing information to a user outside of a restricted security realm (e.g., a systems administrator) in a manner that enables the user to handle the error from outside of the realm, without compromising the security of the systems within the realm, and without compromising sensitive information exposed by the failing system. To provide a user with the option to address failures in a secured system remotely and securely, one or more programs in some embodiments of the present invention that execute within the restricted realm, monitor the secured systems for failures. Based on detecting a failure/error, the one or more programs generate an inoculated alert and a set of potential operation options (e.g., reset, reboot, move, no action, etc.) and forward the alert and the options (i.e., a notification) to a user's mobile device, via a secure protocol, which is described herein. In this manner, the one or more programs have provided the operator of the mobile device outside of a secured system with a secure means to perform a selected operation on the secured system from the set of potential options.”)]; and
wherein: the group of API access actions resolves the potential error condition. (Mild, [cl.6 ln.59-cl.7 ln.26], “In some embodiments of the present invention, upon recognizing an issue (e.g., receiving an indication of a failure), in the secured system 240, the one or more programs 215 notify a computing device 250 in the unsecured environment 220 of the issue. As illustrated in FIG. 1, the notification includes not only a report that an issue occurred in the secured system 240, but also, options to mitigate the issue, including but not limited to, options to reconfigure elements of the system 240. Thus, based on determining that a failure/issue has occurred in the system 240, the one or more programs 215 formulate options for mitigating the issue. Because the one or more programs 215 are transmitting a notification from a secured environment 210 to an unsecured environment 220, the one or more programs 215 include in the notification only information that can be transmitted safely over a public connection, such as a notification that there is an issue and options for mitigation. The one or more programs do not transmit secure data that they may have received when being notified of and/or diagnosing the initial issue in the system 240. Thus, the one or more programs 215 may retain data related to the issue in the secured environment 235, for example, on a memory resource of the computing resource 230, and transmit only the notification. In some embodiments of the present invention, the one or more programs 215 translate options to mitigate the issue into requests to issue calls to the system 240. Thus, if a given selection is made from the options to mitigate, the one or more programs 215 will make a call to the system 240 and/or the computing resource 230. Thus, although the options in the notifications do not include the data, if the data is required to mitigate the issue, the one or more programs generate an option that includes a request to access this data, so when the option is selected and the one or more programs 215 receive the selection, the one or more programs access the data for use in mitigating the issue.”).
Mild is directed to resolving issues in a secure system. Specifically, Mild teaches monitoring the secure system for errors and issuing a notification (i.e. a log) for a user to rectify the issue using specific API calls.
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chhabra to incorporate the teachings of Mild to include the above limitations. Such modification(s) would be motivated to provide a remote user data about an error that has occurred and the set of operations to resolve the issue. (Mild, [cl.3 ln.19-ln.37]).
Second Office Action:
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 11, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over SOGAWA EMI ( JP2020166469A) filed in IDS 07/17/2025, hereinafter referred to as EMI, and in view of US Patent No. (US2013/0205385) issued to Roesner.
Claims 1, 11, and 20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by SOGAWA EMI ( JP2020166469A) filed in IDS 07/17/2025, hereinafter referred to as EMI.
Regarding claims 1, 11, and 20 EMI discloses A method for controlling application programming interface (API) access actions, the method comprising: [0001] The present invention relates to a service management system and a service management method for providing a service to a user by using an API.[0008] a service management system that provides an accurate service using an API], and [see FIG, 1]; and
determining a required API access action to be performed on a security-sensitive computing system, the required API access action including a group of API access actions of different types, the group of API access actions including a one-time action according to a single type of access action [0002] Various information is being provided from the service providing site via API (Application Programming Interface). Disclosure of bank APIs for obtaining information from banking systems is also being considered. This bank API is used to individually service existing functions such as balance inquiry and fund transfer and use them from external applications.], and [0042] Next, the control unit 41 of the bank server 40 (corresponding to security-sensitive computing system )executes the authentication process (step S1-8). Specifically, the user authentication unit 410 of the control unit 41 confirms whether or not the customer ID and password acquired from the user terminal 10 are recorded in the customer information storage unit 42(corresponding to the "operator account database” of the present application). If the customer ID and password are recorded, the authentication is completed], and [ 0065] when it is determined that the API can be used (when "YES" in step S4-9), the control unit 41 of the bank server 40 executes the normal response process (step S4-11). Specifically, the control unit 41 of the bank server 40 generates the API usage history information 440 and records it in the API usage information storage unit 44. Next, the service management unit 412 executes the service according to the service code. For example, in the case of the balance inquiry service, the service management unit 412 acquires the account balance of the account identifier associated with the customer ID. Then, the service management unit 412 returns the service result (for example, the account balance) to the service providing server 20 via the API gateway 30].
selecting, from an operator account database, an available operator account listed in the operator account database, the operator account database indicating which operators are on duty to perform the one-time action on a first API from the group API access actions, the first API access action being one type of action among the different types in the group of API access actions the available operator account indicated in the operator account database as on duty [0002] Various information is being provided from the service providing site via API (Application Programming Interface). Disclosure of bank APIs for obtaining information from banking systems is also being considered. This bank API is used to individually service existing functions such as balance inquiry and fund transfer and use them from external applications.]. and [0042] Next, the control unit 41 of the bank server 40 (corresponding to security-sensitive computing system )executes the authentication process (step S1-8). Specifically, the user authentication unit 410 of the control unit 41 confirms whether or not the customer ID and password acquired from the user terminal 10 are recorded in the customer information storage unit 42(corresponding to the "operator account database” of the present application). If the customer ID and password are recorded, the authentication is completed], and [ 0065] when it is determined that the API can be used (when "YES" in step S4-9), the control unit 41 of the bank server 40 executes the normal response process (step S4-11). Specifically, the control unit 41 of the bank server 40 generates the API usage history information 440 and records it in the API usage information storage unit 44. Next, the service management unit 412 executes the service according to the service code. For example, in the case of the balance inquiry service, the service management unit 412 acquires the account balance of the account identifier associated with the customer ID. Then, the service management unit 412 returns the service result (for example, the account balance) to the service providing server 20 via the API gateway 30], and [ see FIG. 4, [0045] the customer can be selected by authentication” corresponds to "selection of an available operator account” of the present application), and an API management unit 411 of the bank server 40 issues an APIID and generates an APIID management table 430 associated with the customer code and the application ID. Furthermore, the scope (service code) acquired from the user terminal 10 is recorded in the APIID management table 430 ]; and
generating a unique action tag including an identifier of the one-time action and a unique API access key for performing the one-time action on to the first API [0026] (the ”service code” corresponds to the "identifier of the one-time action” of the present application, the ”APIID” corresponds to the "unique API access key” of the present application, and (a part of) the ”APIID management table” corresponds to the "unique action tag” of the present application), and the APIID management table records (maintains) customer IDs (corresponding to the "selected operator account” of the present application), application IDs, service codes, APIID, APIID update flags, approval cancellation dates and times, APIID update reasons, API transaction suspension flags, and suspension dates and times), and ( Fig. 3 and corresponding text for more details); and
maintaining a dynamic access list having identifiers of the group of API access actions and mapping of unique API access keys to selected operator accounts
[0026] (the ”service code” corresponds to the "identifier of the one-time action” of the present application, the ”APIID” corresponds to the "unique API access key” of the present application, and (a part of) the ”APIID management table” corresponds to the "unique action tag” of the present application), and the APIID management table records (maintains) customer IDs (corresponding to the "selected operator account” of the present application), application IDs, service codes, APIID, APIID update flags, approval cancellation dates and times, APIID update reasons, API transaction suspension flags, and suspension dates and times), and ( Fig. 3 and corresponding text for more details); and
registering, to dynamic access list, the unique action tag, including the identifier of the one-time action and the unique API access key, and mapping the unique API access key to the selected available operator account [0026] (the ”service code” corresponds to the "identifier of the one-time action” of the present application, the ”APIID” corresponds to the "unique API access key” of the present application, and (a part of) the ”APIID management table” corresponds to the "unique action tag” of the present application), and the APIID management table records (maintains) customer IDs (corresponding to the "selected operator account” of the present application), application IDs, service codes, APIID, APIID update flags, approval cancellation dates and times, APIID update reasons, API transaction suspension flags, and suspension dates and times), and ( Fig. 3 and corresponding text for more details); and
[see FIG 4, [0045] (The ”(part of) the APIID management table” corresponds to the "dynamic access list” of the present application); the API management unit 411 of the bank server 40 (corresponding to the ”security-sensitive computing system” of the present application) issues an APIID and generates an APIID management table 430 associated with a customer code and an application ID; in the initial stage, a no-update flag is recorded in the APIID update flag data area ); and
granting, for the selected operator account, an authorization via the dynamic access list and the unique action tag, API access action privileges for the security-sensitive computing system, the authorization being limited to perform only the first API access one-time action mapped to the selected operator account on the first API; and
[0003] In addition, OAuth authentication may be used to authorize authority. This OAuth is an authentication protocol for granting access to a user's resources on the server on behalf of the user. OAuth allows end users to authorize third-party access to resources without giving the client a username or password. In OAuth, the customer ID and password required for login are replaced with OAuth tokens (access tokens) assigned to each user. This token for OAuth enables information sharing between systems without giving the password to external services], and [0029] (the "recording of the no-update flag” corresponds to the "authorization of the authority of the API access action” of the present application);and [0055] (the user terminal 10 executes an API use process ); and
responsive to the first API access one-time action being completed by an operator using the unique action tag,
([0063], [0065] Fig. 6) (the API management unit 411 of the bank server 40 confirms the APIID update flag and the API transaction use suspension flag in the APIID management table 430; and the API management unit 411 stores the update required flag and the application ID in the APIID management table 430. When the stop flag is not recorded, it is determined that the API can be used, and when it is determined that the API can be used, the service management unit 412 executes the service according to the service code); and
cancelling further one-time actions based on the unique action tag, and revoking a further use of the unique API access key to perform the first additional types API access actions [0030](The reasons for updating the API ID include a reason due to the API, a reason due to the customer side, and a reason due to the back office. Reasons caused by API include API revoke (invalidation) and the like. Reasons caused by the customer side include password change and password lock. Reasons caused by the back office include an instruction to release the suspension from the back office).
While EMI. Discloses the bank API is used to individually service existing functions such as balance inquiry and fund transfer and use them from external applications. However, does not explicitly discloses one-time action according to a single type of access action, and
Roesner discloses [Abstract, an access system is described herein which allows an application to access a system-level and/or application-specific user-owned resource based on a user's interaction with an intent-based access mechanism. For example, the intent-based access mechanism may correspond to a gadget that is embedded in an application user interface provided by the application, and/or logic for detecting a permission-granting input sequence. The access system accommodates different types of intent-based access mechanisms. One type is a scheduled intent-based access mechanism. Another type provides access to two or more user-owned resources. Further, the access system includes a mechanism for determining whether the application is permitted to use an intent-based access mechanism], and [0098] In a second case, the gadget or PG input sequence grants an application one-time access to a particular user-owned resource. To do this, the access management module 408 sends an InitContentTransfer call to the operating system 114. That transfer call instructs the operating system 114 to push or pull appropriate data to or from a destination location (dest) or source location (src), respectively].
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 teaching of EMI by incorporating “ access management module”, as taught by Roesner. One could have been motivated to do so in order to provide one-time access to a particular user-owned resource and prevent malicious applications to gain improper access to a user-owned resource [ Roesner, 0063,0098].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
See submitted 892 for more relevant references.
Dunjic et al. (US 20210006566 A1) – Regarding systems that are designed to perform user authentication and authorization for accessing protected data sources.
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 SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496
Prosecution Insights