DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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.
The claim objections have been withdrawn in view of the claim amendments.
Claims 1-3, 5, 7-13, and 15-20 are pending.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/29/25 has been entered.
Response to Arguments
Applicant's arguments filed on 12/29/25 have been fully considered.
In response to Applicant’s arguments regarding the newly amended limitations (pages 7-9 of Remarks), Examiner acknowledged Applicant’s perspective but these arguments are moot in view of the new grounds of rejection presented below in view of newly found prior art Zhu.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-3, 5, 7-13, and 15-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 1 recites “the service” in last three lines. However, it’s unclear whether this refers to “each service accessed” in line 5 from bottom of claim 1, one of “services” in line 4 from bottom of claim 1 or one of “services” in line 12 from bottom of claim 1 or some other service. Claims 2-3, 5, 7-10 depend from claim 1 and thus also have this issue. Similar issue also exists in claim 11 and its dependent claims 12-13 and 15-20. For examination purposes, “the service” in last three lines of claim 1 (and similarly claim 11) has been interpreted as any service.
Claims 2-3 and 8-10 recite “the workflow”. However, it’s unclear whether this refers to “workflow” in line 2 from bottom of claim 1 or “workflow” in line 2 from top of claim 1. Similar issue also exists in claims 12-13 and 18-20. For examination purposes, “the workflow” in claims 2-3 and 8-10 has been interpreted as referring to “workflow” in line 2 from top of claim 1 and “the workflow” in claims 12-13 and 18-20 has been interpreted as referring to “workflow” in line 4 from top of claim 11.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-3, 5, 7-13, and 15-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 1 recites receiving a request to perform a workflow from a requestor; determining whether the requestor has authorizations required to perform an instance of the workflow in advance of performing the instance of the workflow; generating an access token that is associated with the instance of the workflow only after determining that the requestor has all authorizations required to perform the instance of the workflow, wherein the access token is configured for token-based authentication, wherein the access token informs services used by the instance of the workflow that the requestor is authorized to access the services; generating a security context for the instance of the workflow, wherein the security context places limits on the instance of the workflow by defining a permitted service, wherein the security context is configured to limit a type of work requested for the instance of the workflow, or scope a capacity of the work requested for the instance of the workflow, or define a call path of the instance of the workflow; and executing the workflow, wherein each service accessed during the execution of the instance of the workflow determines whether to perform services based on the access token and the security context, including verifying that the service is within a permitted service, workflow, or call path defined by the security context prior to performing the service.
The limitation of receiving a request to perform a workflow from a requestor as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, “receiving” in the context of this claim encompasses the user manually receiving a request to perform a workflow from a requestor.
The limitation of determining whether the requestor has authorizations required to perform an instance of the workflow in advance of performing the instance of the workflow as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, “determining” in the context of this claim encompasses the user checking whether the requestor has authorizations required to perform an instance of the workflow in advance of performing the instance of the workflow.
The limitation of generating an access token that is associated with the instance of the workflow only after determining that the requestor has all authorizations required to perform the instance of the workflow, wherein the access token is configured for token-based authentication, wherein the access token informs services used by the instance of the workflow that the requestor is authorized to access the services as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, “generating” in the context of this claim encompasses the user manually creating an access token that is associated with the instance of the workflow only after determining that the requestor has all authorizations required to perform the instance of the workflow, wherein the access token is configured for token-based authentication, wherein the access token informs services used by the instance of the workflow that the requestor is authorized to access the services.
The limitation of generating a security context for the instance of the workflow, wherein the security context places limits on the instance of the workflow by defining a permitted service, wherein the security context is configured to limit a type of work requested for the instance of the workflow, or scope a capacity of the work requested for the instance of the workflow, or define a call path of the instance of the workflow as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, “generating” in the context of this claim encompasses the user creating a security context for the instance of the workflow, wherein the security context places limits on the instance of the workflow by defining a permitted service, wherein the security context is configured to limit a type of work requested for the instance of the workflow, or scope a capacity of the work requested for the instance of the workflow, or define a call path of the instance of the workflow.
The limitation of executing the workflow, wherein each service accessed during the execution of the instance of the workflow determines whether to perform services based on the access token and the security context, including verifying that the service is within a permitted service, workflow, or call path defined by the security context prior to performing the service as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind. For example, “executing” in the context of this claim encompasses the user performing the workflow, wherein each service accessed during the execution of the instance of the workflow determines whether to perform services based on the access token and the security context, including verifying that the service is within a permitted service, workflow, or call path defined by the security context prior to performing the service.
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application because the claim does not recite additional elements that integrate the judicial exception into a practical application. Moreover, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. The claim is not patent eligible.
Dependent claims 2-3, 5, and 7-10 further clarify the concept recited in claim 1 however this clarification still falls under the concept recited in claim 1 and does not amount to significantly more than the judicial exception. Dependent claims 2-3, 5, and 7-10 are rejected for at least the reason stated above with respect to claim 1.
Claim 11 although not using the exact claim language, contains similar elements as recited in claim 1 and is also rejected for similar reasons. Claim 11 recites an additional element of a storage medium having stored therein instructions that are executable by one or more hardware processor to perform the operations. However, the additional elements are recited at a high level of generality and amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer cannot provide an inventive concept. Accordingly, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements are recited at a high level of generality and amount to no more than mere instructions to apply the exception using generic computer components. Thus, the claimed elements, either individually, or in the ordered combination do not add significantly more to the abstract idea. The claim is not patent eligible.
Dependent claims 12-13 and 15-20 further clarify the concept recited in claim 11 however this clarification still falls under the concept recited in claim 11 and does not amount to significantly more than the judicial exception. Dependent claims 12-13 and 15-20 are rejected for at least the reason stated above with respect to claim 11.
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.
Claims 1, 5, 7-11, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Wang (US 20250106221) in view of Zhu (US 20160182525).
Claim 1, Wang discloses A method comprising:
receiving a request to perform a workflow from a requestor; (e.g. figs. 1, 2A-2B, 4, ¶25, 34: FIG. 1 is a flow diagram of a process for fine granularity data access control, in accordance with one or more embodiments. Process flow 100 first begins when a user 102, e.g., a Data Scientist (Jenie), wants to work on an external cloud, e.g., AWS, and so makes a request to gain access to certain data for a particular purpose…FIG. 2B is a diagram showing an example data structure of a data access request, such as data access request 206 in FIG. 2A, in accordance with one or more embodiments. In some embodiments, the data access request data structure 220 includes four fields: an application 222, a project 224, a data source 226, and an environment 228…FIG. 4 illustrates a detailed example architecture for fine granularity data access control, in accordance with one or more embodiments. In some embodiments, a data scientist 402 submits a data access request for a specific purpose (for example, improving a ML feature) by creating a notebook project via a “Data Access Approval Process” 406 and “Project Management” 408 in a “Notebooking Management Service” 404. In some embodiments, the request includes what data, which customer (e.g., data owner), and usage scope (e.g., specific usage purpose).)
determining whether the requestor has authorizations required to perform an instance of the workflow in advance of performing the instance of the workflow; (e.g. figs. 1, 2A, 2C, ¶25, 29, 31-32, 41-42, 56-57: In order to do so, user 102 must be authorized for access. In some embodiments, the authorization process involves a 3-phase context-based authorization process 104, described in further detail with respect to FIG. 2A…In FIG. 2A, a high level workflow for the three-phase authorization process 200 is depicted. In this way, the system can precisely control what data a data scientist can access, per client, per application, per data type, and per data table, at a very fine-grained level. In addition, this approach is flexible and time-efficient, as the user can acquire a variety of data access at run-time, as soon as the user receives approval from the team's data administrator. In some embodiments, the underlying notebook (NB) system will ensure all of the data scientist activities are restricted under the scope the user is permitted…a team manager or supervisor 208 checks to verify whether the verification is correct as a quality check. After the user verification step, the system then proceeds to check 210 whether the owner of the data even authorized the data to be accessed for such a purpose. In some embodiments, this step is accomplished using a data consent process 212. In data consent process 212, the owner of the data or an external customer admin 214 provides data consent for a specific purpose…FIG. 2C illustrates an example data consent workflow, in accordance with embodiments. In some embodiments, the data consent process 230 includes first selecting (232) an application to consent. Next, a list of entities is selected (234). Then, the entities get added (236) to the permission set. Last, the data consent is stored (238) in a database. FIG. 2C also shows an example of a data consent table data structure 240. In addition, FIG. 2C also shows an example of a context-based token 250, written in JWT form. In some embodiments, data consent process 230 includes the customer (the data owner) first selecting 232 which application (which is a ML feature) to grant data access to the data scientists. In some embodiments, the data access is only granted for improving this selected feature. Next, the customer selects 234 the list of entities (for example, a database table or a data file) to share data access. Then, the underlying system will encode 236 this granted permission to a permission set, which will be used later for data access authorizing. Last, the permission will be saved 238 to a database, such as data consent table 240 for tracking/auditing purposes… data owner 410 (e.g., a Salesforce customer) grants their permission (data consent) for data scientists 402 to access the requested set of their data with certain usage scope. The data consent record will be saved in a database, such as data consent tool 412. In some embodiments, data access will be enabled in a perm set, and the perm set will be updated to a remote data storage, such as data cloud 414 (e.g., Salesforce DataCloud) and/or core database 416 (e.g., Core Database). In some embodiments, a product manager or engineering manager 418 of an application (e.g., ML feature) will review the access request (e.g., notebook project) from data scientists 402, and approve it if the access request is appropriate.)
generating an access token that is associated with the instance of the workflow only after determining that the requestor has all authorizations required to perform the instance of the workflow, wherein the access token is configured for token-based authentication, wherein the access token informs services used by the instance of the workflow that the requestor is authorized to access the services; (e.g. figs. 1, 2A, ¶25-26, 32, 45-46, 52-54, 57: After user 102 (the data scientist) passes the 3-phase authorization 104, she will have a context-based access token 106, which in some embodiments is assigned by a notebook (NB) system. In some embodiments, the context-based access token includes information on what data source is being requested, what set of data is being requested, and for what purpose the data is to be used…the cloud specific access control policy 114 is created using the cloud specific token (not shown). This access control policy takes the information from the cloud specific token and then creates a temporary role for user 102 to access the data, but within the confines of restrictions and limitations specified in the cloud specific token. In some embodiments, user 102 will then assume a specific role assigned for her in the context of her current work. In some embodiments, Jenie uses this role to use AWS services for doing her work, and she would also follow the same process for using other cloud platforms, such as Azure and GCP…Assuming the data access and the purpose of the data access is verified, then a context-based token 216 is generated. In some embodiments, the context-based token includes restricted data and operation scope…context-based token 250 is a signed JWT token, which declares the context of a data request. For example, “iss” 252 describes who issued JWT token 250. As another example, “aud” 254 defines the list of web services the token can access. In yet another example, “scp” 256 is a list of data spaces and permissions for token 250. For example, “mllake.namespace.language.READ” 258 lists token 250 as having read access to the “language” namespace in “mllake” service. In yet another example, “hw.ctx” 260 declares the token's application (ML feature). In some embodiments, context-based token 250 represents an approved (by Internal data admin or manager) data access request from data scientists, after evaluating with the customer data consent permission…Then, a temporary IAM role and a temporary IAM policy that allows restricted access to the set of data by the user according to the cloud specific token parameters and restrictions are created (312). In some embodiments, the temporary IAM role and policy are associated with a time to live value. Last, the temporary IAM role and temporary IAM policy are deleted (314) after the time to live value expires. In some embodiments, processing of the cloud specific token involves several steps. First, the system creates an IAM role in a particular cloud platform. In some embodiments, the IAM role (a principal user management system) is specific to the cloud platform and to a specific data access request. Second, the system creates a set of IAM policies to restrict the IAM role on what cloud services (e.g., feature store, data buckets, training service) it can access, according to the operation scope defined in the cloud neutral token. Third, the system creates a set of IAM policies to restrict the IAM role on what data (e.g. data store, table, files) it can access. In some embodiments, the set of IAM policies also includes where it can save the output data. Fourth, the system attaches the IAM role to the compute resource in the specific cloud where the user is asking to use…the fine granularity control is governed by temporary resource tags created in addition to the IAM roles. In such embodiments, the specific resources requested are tagged with the appropriate “application context” (or purpose for using the data). If the resource tag and the tags in the IAM role do not match up, then the access is denied…As a result, a context-based access token will be created by a component of “Data Access Approval Process” 406 to represent the requested data access scope)
generating a security context for the instance of the workflow, wherein the security context places limits on the instance of the workflow, wherein the security context is configured to limit a type of work requested for the instance of the workflow, or scope a capacity of the work requested for the instance of the workflow, or define a call path of the instance of the workflow; and (e.g. figs. 1, 2A, 2D, ¶26, 33, 48, 52, 60: Next, an access token converter 108 will convert context-based token 106 to a cloud neutral token 110, which is cloud agnostic, but defines data & operation scope in a general structure. This cloud neutral token 110 is then converted into a cloud specific token for use in a remote cloud system. This remote system is the destination for user 102 to access the data. In this example, since user 102 requested to work on AWS, an AWS access token is created using AWS token converter 112…After context-based token 216 is created, it is then converted into a cloud neutral token, which contains information regarding data scope and operation scope. The cloud neutral token is then converted into a cloud specific access token. The cloud specific access token is then verified with backend services 218 at the remote cloud system. In some embodiments, the cloud specific access token is verified to ensure security scope for data and operations are applied. The cloud specific token will list the data scope and the operation scope (from the cloud neutral token) which will be translated into access and permission boundaries…Next, the cloud neutral token is converted (310) into a cloud specific token. In some embodiments, the cloud specific token includes parameters and restrictions from the cloud neutral token)
executing the workflow, wherein each service accessed during the execution of the instance of the workflow determines whether to perform services based on the access token and the security context. (e.g. figs. 1, 2A, ¶26, 33, 53-54, 60: an access token converter 108 will convert context-based token 106 to a cloud neutral token 110, which is cloud agnostic, but defines data & operation scope in a general structure. This cloud neutral token 110 is then converted into a cloud specific token for use in a remote cloud system. This remote system is the destination for user 102 to access the data. In this example, since user 102 requested to work on AWS, an AWS access token is created using AWS token converter 112. Next, the access token converter 112 will dynamically create a set of rules and policy 114 for the selected system, which is AWS in this example. In some embodiments, the cloud specific access control policy 114 is created using the cloud specific token (not shown). This access control policy takes the information from the cloud specific token and then creates a temporary role for user 102 to access the data, but within the confines of restrictions and limitations specified in the cloud specific token. In some embodiments, user 102 will then assume a specific role assigned for her in the context of her current work. In some embodiments, Jenie uses this role to use AWS services for doing her work, and she would also follow the same process for using other cloud platforms, such as Azure and GCP…After context-based token 216 is created, it is then converted into a cloud neutral token, which contains information regarding data scope and operation scope. The cloud neutral token is then converted into a cloud specific access token. The cloud specific access token is then verified with backend services 218 at the remote cloud system. In some embodiments, the cloud specific access token is verified to ensure security scope for data and operations are applied. The cloud specific token will list the data scope and the operation scope (from the cloud neutral token) which will be translated into access and permission boundaries… Fourth, the system attaches the IAM role to the compute resource in the specific cloud where the user is asking to use. Fifth, when the user accesses the specific cloud, the system will grant the IAM role created in first step by evaluating the cloud neutral token. Sixth, a time to live (TTL) value is submitted with the request in the first step. In some embodiments, the TTL is defined in the cloud neutral token, since the system has to tie the role to a specific purpose, the system needs to make sure that the role is short lived and not recycled for different purpose. Last, the system deletes the IAM role, and everything created for this role including resource tags, once the work is done…the fine granularity control is governed by temporary resource tags created in addition to the IAM roles. In such embodiments, the specific resources requested are tagged with the appropriate “application context” (or purpose for using the data). If the resource tag and the tags in the IAM role do not match up, then the access is denied)
Wang does not appear to explicitly disclose but Zhu discloses by defining a permitted service and including verifying that the service is within a permitted service, workflow, or call path defined by the security context prior to performing the service. (e.g. figs. 5-6, ¶84, 88-90, 92: FIG. 5 is a flow diagram illustrating one example of the operation of authentication worker component 122 in more detail. In one example, the various workflows that are to be performed on the target machine 118 are stored in a queue, and are executed in order…Component 122 then unpacks the workflow to identify the various tasks and corresponding scopes (or parameters) for those tasks. This is indicated by block 466. For instance, a given workflow may comprise multiple lower level commands or tasks and may imply execution across different machines and different roles. Each task may be applicable on only some of the machine roles in the specified scope. A scope, for instance, may be a combination of one or more parameters that define a system, a tenant, a site, etc., for which a command request is being submitted. Local validation component 368 then accesses a local authorization policy and verifies that the workflow is authorized by the local policy. This is indicated by blocks 468 and 470. As one example, the authorization policy may map different scopes to different machines. Therefore, local validation component 368 may verify that the scopes are for the present target machine. This is indicated by block 472. Component 368 can also perform task-based access validation (which is described in greater detail below with respect to FIG. 6). This is indicated by block 474. Further, it can verify that the workflow is authorized by the local policy in other ways as well, and this is indicated by block 476… Therefore, authorization worker component 122, on the target machine, performs the authorization of each of the tasks prior to its execution. Authentication worker component 122 can do this because when it receives a work item from CRQS 128, system 128 has broken the workflow down into the required tasks and parameters (or scopes) for those tasks. The local validation component 368 on authentication worker component 122 authorizes the tasks. This can be verifying that the task and scope are part of the workflow, and that the scope authorized by AP system 104 corresponds to the target machine. To do this, local validation component 368 in authentication worker component 122 checks each task against the local authorization policy 123, which includes a mapping of each workflow to the corresponding tasks…When verifying the scope of the task, authentication worker component 122 verifies that the scope provided by CRQS 128 matches that of the claim approved by AP system 104, and also verifies that the specified scope actually includes the local machine (or target machine) 118. FIGS. 6A and 6B (collectively referred to herein as FIG. 6) illustrate this operation in more detail…Local validation component 368 then determines whether the selected task is mapped to the identified workflow indicated at 496. This determination is indicated by block 508 in FIG. 6. If not, an appropriate error message is generated as indicated by block 510. However, if so, then local validation component 368 determines whether the scope corresponding to the selected task matches the scope authorized by the capability token service 182. This is indicated by block 512. If so, local validation component 368 then determines whether the scope corresponding to the selected task applies to this particular local machine (e.g., machine 118). This is indicated by block 514.)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by Zhu into the invention of Wang for the purpose of ensuring only verified workflows are executed on target machines thereby further increasing security and integrity of the system.
Claim 5, Wang-Zhu discloses The method of claim 1, wherein the security context is valid only to work uniquely identified in the security context. (Wang, e.g. figs. 1, 2A, 2D, ¶26, 33, 48, 52 and/or Zhu, e.g. ¶84, 89-90, 92)
Claim 7, Wang-Zhu discloses The method of claim 1, further comprising managing a lifecycle of the access token and the security context. (Wang, e.g. figs. 1, 2A, 2D, ¶25-26, 32-33, 52-53)
Claim 8, Wang-Zhu discloses The method of claim 7, further comprising revoking the access token and/or the security context when the instance of the workflow finishes. (Wang, e.g. ¶52-53)
Claim 9, Wang-Zhu discloses The method of claim 1, wherein the security context is bound to the instance of the workflow. (Wang, e.g. figs. 1, 2A, 2D, ¶26, 33, 48, 52, 60 and/or Zhu, e.g. ¶84, 89-90, 92)
Claim 10, Wang-Zhu discloses The method of claim 1, wherein the security context places the limits on the instance of the workflow even when the requestor is otherwise authorized. (Wang, e.g. figs. 1, 2A, 2D, ¶26, 33, 48, 52, 60 and/or Zhu, e.g. ¶84, 89-90, 92)
Claims 11, 15, 17-20, these claims are rejected for similar reasons as in claims 1, 5, 7-10.
Claim 16, Wang-Zhu discloses The non-transitory storage medium of claim 11, wherein the security context identifies service/workflow/call paths that the request is allowed to be processed through. (Wang, e.g. figs. 1, 2A, 2D, ¶26, 33, 48, 52 and/or Zhu, e.g. ¶84, 89-90, 92)
Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Wang (US 20250106221) in view of Zhu (US 20160182525) in view of Vaishnav (US 20220292167).
Claim 2, Wang-Zhu discloses The method of claim 1, (see above) and does not appear to explicitly disclose but Vaishnav discloses scanning a workflow definition of the workflow to identify maximum authorizations associated with the workflow and storing the maximum authorizations in a database. (e.g. ¶8-9, 50, 52)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by Vaishnav into the invention of Wang-Zhu for the purpose of identifying and consenting to permissions for workflow and code execution (Vaishnav, ¶8).
Claim 12, this claim is rejected for similar reasons as in claim 2.
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Wang (US 20250106221) in view of Zhu (US 20160182525) in view of Vaishnav (US 20220292167) and further in view of Werner (US 10891569).
Claim 3, Wang-Zhu-Vaishnav discloses The method of claim 2, (see above) and does not appear to explicitly disclose but Werner discloses comparing the authorizations of the requestor to the maximum authorizations to determine whether the requestor is able to execute the workflow, wherein the requestor is able to execute the workflow when the authorizations of the requestor includes the maximum authorizations. (e.g. col. 10, ll. 62 – col. 11, ll. 15).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by Werner into the invention of Wang-Zhu-Vaishnav for the purpose of implementing user authentication and access control procedures (Werner, col. 10, ll. 62-63).
Claim 13, this claim is rejected for similar reasons as in claim 3.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Korus (US 20210103649) discloses receiving a job associated with a project, wherein the project is associated with one or more data sources; identifying a plurality of inputs and a plurality of outputs associated with the job; determining a plurality of required permissions associated with the job, wherein each of the required permissions comprises an operation on a required data source, the operation corresponding to at least one of the inputs or the outputs; verifying that the one or more data sources associated with the project comprise the required data source associated with each of the required permissions; and generating a token associated with the job, the token encoding the required permissions associated with the job, wherein the token is required for execution of the job.
Marcotte (US 20140123312) discloses systems and methods for enabling token-based access control to data are provided. In particular, some embodiments use a token-based access management system to allow or restrict an individual's ability to access data. The access management system uses tokens to define rules (e.g., a Boolean matching rule or algorithm that results in a true/false output indicating the decision) within the access management system to determine if the token is valid and if the individual should be granted access to the requested data. Tokens may further have tool constraints for controlling access. In some cases, the tokens may expire upon completion of a task or after a pre-set amount of time. A generic workflow utilizing tokens and at least one specific workflow showing employees utilizing tokens as part of performing a task responsive to a user.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRONG NGUYEN whose telephone number is (571)270-7312. The examiner can normally be reached on Monday through Thursday 9:00 AM - 5:00 PM EST.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, GELAGAY SHEWAYE can be reached on (571)272-4219. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/TRONG H NGUYEN/Primary Examiner, Art Unit 2436