DETAILED ACTION
This office action is made final. Claims 1-20 are pending. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Applicant’s amendment date 07/29/2026, amended claims 1, 5-7, 9, 13-15, 17, and 20.
Response to Amendment
The previously pending rejection to claims 1-20, under 35 USC 101 (Alice), will be maintained.
Response to Arguments
Applicant’s arguments received on 07/29/2026 have been fully considered, but they are not persuasive. Moreover, any new grounds of rejection have been necessitated by Applicant's amendments to the claims. The art rejection has been updated to address these amendments.
Response to Arguments under 35 USC 101:
Applicant asserts that “amended claim 1 does not fall into the grouping of certain methods of organizing human activity.” Examiner respectfully disagrees.
Pursuant to 2019 Revised Patent Subject Matter Eligibility Guidance, in order to determine whether a claim is directed to an abstract idea, under Step 2A, we first (1) determine whether the claims recite limitations, individually or in combination, that fall within the enumerated subject matter groupings of abstract ideas (mathematical concepts, certain methods of organizing human activity, or mental processes), and (2) determine whether any additional elements beyond the recited abstract idea, individually and as an ordered combination, integrate the judicial exception into a practical application. 84 Fed. Reg. 52, 54-55. Next, if a claim (1) recites an abstract idea and (2) does not integrate that exception into a practical application, in order to determine whether the claim recites an “inventive concept,” under Step 2B, we then determine whether the claim recites any of the additional elements beyond the recited abstract idea, individually and in combination, are significantly more than the abstract idea itself. 84 Fed. Reg. 56.
Here, under the first prong of Step 2A, the claims (claim 1, and similarly claims 9 and 17) recite “receiving a task identifier for a task that is requested to be approved, and one or more subtasks decomposed from the task; generating a task request including a task request identifier, the task request being associated with the task, the task request identifier corresponding to the task identifier, and each subtask of the one or more subtasks of the task corresponding to one or more approval policies; determining, for each subtask of the one or more subtasks of the task, whether the one or more approval policies are satisfied including at least: determining whether a first approval policy for a first subtask of the one or more subtasks is satisfied; determining whether a second approval policy for a second subtask of the one or more subtasks is satisfied, the first subtask being different from the second subtask, the first policy being different from the second policy; in response to determining that the first approval policy or the second approval policy is unsatisfied, rejecting the task; and outputting an indication of the rejection.” Therefore, contrary to Applicant’s assertions, the claims are directed to mental processes and certain methods of organizing human activity.
Applicant asserts that “the independent claims as amended integrate any abstract idea into a practical application.” Examiner respectfully disagrees.
As discussed above, under the second prong of Step 2A, we determine whether any additional elements beyond the recited abstract idea, individually and as an ordered combination, integrate the judicial exception into a practical application. 84 Fed. Reg. 52, 54-55.
Here, under the second prong of Step 2A, the only additional elements beyond the recited abstract idea of claim 1, and similarly claims 9 and 17) recite “receiving a task identifier for a task that is requested to be approved, and one or more subtasks decomposed from the task; generating a task request including a task request identifier, the task request being associated with the task, the task request identifier corresponding to the task identifier, and each subtask of the one or more subtasks of the task corresponding to one or more approval policies; determining, for each subtask of the one or more subtasks of the task, whether the one or more approval policies are satisfied including at least: determining whether a first approval policy for a first subtask of the one or more subtasks is satisfied; determining whether a second approval policy for a second subtask of the one or more subtasks is satisfied, the first subtask being different from the second subtask, the first policy being different from the second policy; in response to determining that the first approval policy or the second approval policy is unsatisfied, rejecting the task; and outputting an indication of the rejection are carried out by at least one computing device,” and these additional elements, individually and in combination, are nothing more than computing elements recited at high level of generality implementing the abstract idea on a computer (i.e. apply it), and thus, are no more than applying the abstract idea with generic computer components. Accordingly, contrary to Applicant’s assertions, the judicial exception is not integrated into a practical application under the second prong of Step 2A.
Response to Arguments under 35 USC 103:
Applicant's arguments with respect to the claim rejections have been considered, but are moot in view of the new ground(s) of rejection set forth below in this Office action. The art rejection has been updated to address these amendments.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Specifically, claims 1-20 are directed to an abstract idea without additional elements amounting to significantly more than the abstract idea.
With respect to Step 2A Prong One of the framework, claims 1, 9, and 17 recite an abstract idea. Claims 1, 9, and 17 include “receiving a task identifier for a task that is requested to be approved, and one or more subtasks decomposed from the task; generating a task request including a task request identifier, the task request being associated with the task, the task request identifier corresponding to the task identifier, and each subtask of the one or more subtasks of the task corresponding to one or more approval policies; determining, for each subtask of the one or more subtasks of the task, whether the one or more approval policies are satisfied including at least: determining whether a first approval policy for a first subtask of the one or more subtasks is satisfied; determining whether a second approval policy for a second subtask of the one or more subtasks is satisfied, the first subtask being different from the second subtask, the first policy being different from the second policy; in response to determining that the first approval policy or the second approval policy is unsatisfied, rejecting the task; and outputting an indication of the rejection”.
The limitations above recite an abstract idea under Step 2A Prong One. More particularly, the elements above recite mental processes-concepts performed in the human mind (including an observation, evaluation, judgment, opinion) and certain methods of organizing human activity-managing personal behavior or relationships or interactions between people (following rules or instructions) because the elements describe a process for managing task approvals. As a result, claims 1, 9, and 17 recite an abstract idea under Step 2A Prong One.
Claims 2-8, 10-16, and 18-20 further describe the process for managing task approvals. As a result, claims 2-8, 10-16, and 18-20 recite an abstract idea under Step 2A Prong One for the same reasons as stated above with respect to claims 1, 9, and 17.
With respect to Step 2A Prong Two of the framework, claims 1, 9, and 17 do not include additional elements that integrate the abstract idea into a practical application. Claims 1, 9, and 17 include additional elements that do not recite an abstract idea under Step 2A Prong One. The additional elements of claims 1, 9, and 17 include one or more processors and one or more memories storing instructions. When considered in view of the claim as a whole, the additional elements do not integrate the abstract idea into a practical application because the additional computing elements are generic computing elements that are merely used as a tool to perform the recited abstract idea. As a result, claims 1, 9, and 17 do not include additional elements that integrate the abstract idea into a practical application under Step 2A Prong Two.
Claims 4-6, 8, 12-14, 16, and 19-20 do not include any additional elements beyond those recited with respect to claims 1, 9, and 17. As a result, claims 4-6, 8, 12-14, 16, and 19-20 do not include additional elements that integrate the abstract idea into a practical application under Step 2A Prong Two for the same reasons as stated above with respect to claims 1, 9, and 17.
Claims 2-3, 7, 10-11, 15, and 18 include additional elements that do not recite an abstract idea under Step 2A Prong One. The additional elements of claims 2-3, 7, 10-11, 15, and 18 include interfacing with a network, a service application, and an approvals application. When considered in view of the claims as a whole, the additional elements do not integrate the abstract idea into a practical application because the additional computing elements do no more than generally link the use of the recited abstract idea to a particular technological environment. As a result, claims 2-3, 7, 10-11, 15, and 18 do not include additional elements that integrate the abstract idea into a practical application under Step 2A Prong Two.
With respect to Step 2B of the framework, claims 1, 9, and 17 do not include additional elements amounting to significantly more than the abstract idea. As noted above, claims 1, 9, and 17 include additional elements that do not recite an abstract idea under Step 2A Prong One. The additional elements of claims 1, 9, and 17 include one or more processors and one or more memories storing instructions. The additional elements do not amount to significantly more than the abstract idea because the additional computing elements are generic computing elements that are merely used as a tool to perform the recited abstract idea. Further, looking at the additional elements as an ordered combination adds nothing that is not already present when considering the additional elements individually. As a result, independent claims 1, 9, and 17 do not include additional elements that amount to significantly more than the abstract idea under Step 2B.
Claims 4-6, 8, 12-14, 16, and 19-20 do not include any additional elements beyond those recited with respect to claims 1, 9, and 17. As a result, claims 4-6, 8, 12-14, 16, and 19-20 do not include additional elements that amount to significantly more than the abstract idea under Step 2B for the same reasons as stated above with respect to claims 1, 9, and 17.
Claims 2-3, 7, 10-11, 15, and 18 include additional elements that do not recite an abstract idea under Step 2A Prong One. The additional elements of claims 2-3, 7, 10-11, 15, and 18 include interfacing with a network, a service application, and an approvals application. The additional elements do not amount to significantly more than the abstract idea because the additional computing elements do no more than generally link the use of the recited abstract idea to a particular technological environment. Further, looking at the additional elements as an ordered combination adds nothing that is not already present when considering the additional elements individually. As a result, claims 2-3, 7, 10-11, 15, and 18 do not include additional elements that amount to significantly more than the abstract idea under Step 2B.
Therefore, the claims are directed to an abstract idea without additional elements amounting to significantly more than the abstract idea. Accordingly, claims 1-20 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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-4, 6-12, and 14-19 are rejected under 35 U.S.C. 103 as being unpatentable over Khan et al. (US Pub No. 2012/0060163) (hereinafter Khan et al.) in view of Banas et al. (US Pub No. 2008/0077530) (hereinafter Banas et al.).
Regarding claims 1 and 9, Khan discloses a method for managing task approvals, the method comprising:
receiving a task identifier for a task that is requested to be approved, and one or more subtasks decomposed from the task (para [0039], wherein receiving a task and/or subtask; para [0023], wherein server 140 can modify the permission database 142 such that an operator is granted appropriate access rights to complete a task (e.g., minimum level and/or type of access to complete the task); and paras [0043]-[0044], wherein the status database 154 can also include an identifier of an object ( e.g., device, account, user, policy, etc.) on which that task and/or subtask is to be performed……(subtasks decomposed from the task) represented in Fig. 3 shows a status database 300 structurally and functionally similar to the status database 154 of FIG. 1. The status database 300 includes a task column 302, an operator column 304, a status column 306 and an authentication column 308. Tasks and their associated subtasks are listed in the task column 302. For example, task T 1 includes subtask Si, S2 , S3 and S4 . In this example, the task T1 was divided into the four subtasks S1 , S2 , S3 , S4 by the task division module 204);
generating a task request including a task request identifier, the task request being associated with the task, the task request identifier corresponding to the task identifier, and each subtask of the one or more subtasks of the task corresponding to one or more approval policies (paras [0029]-[0031], wherein the task initiation module 212 receives a request associated with a task to be performed within the communication system 100 from the communication module 202 and initiate a task and/or trouble ticket based on the request; paras [0043]-[0044], wherein the status database 154 can store an indication or representation of the operator associated with a task and/or subtask, and can store authentication rights granted to that operator to complete the task and/or subtask. In some embodiments, the status database 154 can also include an identifier of an object (e.g., device, account, user, policy, etc.) on which that task and/or subtask is to be performed; and ….; and para [0065], wherein a first subtask and a second subtask associated with the system are identified, at 604);
determining, for each subtask of the one or more subtasks of the task, whether the one or more approval policies are satisfied (paras [0049]-[0050], wherein the status level "pending" can mean that the operator is not yet able to perform the task and/or subtask (i.e., dependencies where one task (dependent) relies on another predecessor to start or finish preventing subsequent work from starting—or finishing—until requirements, such as quality checks or regulatory approvals, are met to ensure compliance). For example, the operator might be waiting on a preceding subtask in an order of subtasks associated with a task to be completed. For example, to complete the task T1, the subtasks are performed in the order S1, S2, S3 and then S4. Accordingly, the subtask S3 of task T1 can be a prerequisite for performing subtask S4 of task T1. Thus, operator U2 can only perform the subtask S4 of task T1 after operator U3 completes and/or performs subtask S3 of task T1……)
including at least:
in response to determining that the first approval policy or the second approval policy is unsatisfied, rejecting the task (paras [0024] & [0049]-[0050], wherein the security of the communication system 100 is further increased and access to the communication system 100 is further limited as only those operators assigned a task and/or subtask ready to be performed have the appropriate access right to perform the task and/or subtask….. an operator is granted appropriate access rights to complete a task...); and
outputting an indication of the (deny), wherein the method is performed by one or more processors (Fig. 1, paras [0022], [0024], [0028], and [0065], wherein...authentication server 140 can deny the operator and/or user access to the communication system….an operator is granted appropriate access rights to complete a task.....send a request to the authentication server 140 to modify permissions of a specific operator based on the task to be performed within the communication system......A first access right is provided to a first operator, at a first time, based on the first subtask in response to the first operator being assigned the first subtask, at 606).
Khan et al. fails to explicitly disclose determining whether a first approval policy for a first subtask of the one or more subtasks is satisfied; determining whether a second approval policy for a second subtask of the one or more subtasks is satisfied, the first subtask being different from the second subtask, the first policy being different from the second policy; and outputting an indication of the rejection.
Analogous art Banas discloses determining whether a first approval policy for a first subtask of the one or more subtasks is satisfied (see Banas, para [0140], wherein custom tasks 1205, where these tasks may comprise subtasks. For example, the "Plan" task 1255 may comprise a subtask of "Define Objectives and Scope"1260 that includes the subtasks; para [0163], wherein validations and/or business rules; para [0145], wherein the completed task 1515 may be moved to the approval stage 1530. In another representative embodiment of the present invention, if the task does not pass the approval stage 1530, it may be returned (i.e., remediated) back to the assign stage 1520);
Analogous art Banas discloses determining whether a second approval policy for a second subtask of the one or more subtasks is satisfied, the first subtask being different from the second subtask, the first policy being different from the second policy (see Banas, para [0148], wherein referring now to Fig. 19 shows a task workflow where approval of tasks generally allows a project to move through one or more stages toward completion. A task workflow may comprise the following: assign, complete, approve, reject, and reassign….may comprise a project coordinator 1905, one or more task completers 1910, 1915, 1920, and one or more task approvers 1925, 1930, 1935, 1940. The project coordinator 1905 assigns one or more task completers 1910, 1915, 1920 to complete, and one or more task approvers 1925, 1930, 1935, 1940 to approve and/or reject. There are various series of approvals, reassignments and/or rejections that may take place prior to final approval by the project coordinator; and para [0145], wherein the completed task 1515 may be moved to the approval stage 1530. In another representative embodiment of the present invention, if the task does not pass the approval stage 1530, it may be returned (i.e., remediated) back to the assign stage 1520); and
outputting an indication of the rejection (see Banas, para [0380], wherein report may be configured to display additional information about the summary data provided in the original report. For example, the process of a particular business and its rejected tasks may be selected to show a display of each control and the tasks that have been rejected and what values have been entered).
Khan directed to a system for provide an access right to an operator from a set of operators assigned a subtask from the multiple subtasks. Banas directed to improve compliance and/or project workflow processing. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Khan, regarding the System for Dynamic Access Control based on a Task/Trouble Ticket, to have included determining whether a first approval policy for a first subtask of the one or more subtasks is satisfied; determining whether a second approval policy for a second subtask of the one or more subtasks is satisfied, the first subtask being different from the second subtask, the first policy being different from the second policy; and outputting an indication of the rejection because both inventions teach improving accuracy measurements. Further, the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claims 2, 10, and 18, Khan discloses the method of claim 1, wherein the task that is requested to be approved includes at least one selected from a group consisting of accessing a resource, creating a resource, interfacing with a network, and deploying a resource (paras [0019] & [0041]).
Regarding claims 3 and 11, Khan discloses the method of claim 1, further comprising:
receiving, by a service application, one or more task arguments for the task (paras [0020]-[0024], wherein a first operator of the communication system 100 can have credentials to access files and/or applications stored and/or executing on a first communication device 110…..The task management system 104 is operable to run a task management application to define and manage tasks associated with the communication system 100);
generating the task identifier for the task, the task identifier corresponding to the one or more task arguments (paras [0043]-[0044], wherein the status database 154 can store an indication or representation of the operator associated with a task and/or subtask, and can store authentication rights granted to that operator to complete the task and/or subtask. In some embodiments, the status database 154 can also include an identifier of an object (e.g., device, account, user, policy, etc.) on which that task and/or subtask is to be performed; and ….; and para [0065], wherein a first subtask and a second subtask associated with the system are identified, at 604);
decomposing the task into the one or more subtasks (paras [0043]-[0044], wherein the status database 154 can also include an identifier of an object ( e.g., device, account, user, policy, etc.) on which that task and/or subtask is to be performed……(subtasks decomposed from the task) represented in Fig. 3 shows a status database 300 structurally and functionally similar to the status database 154 of FIG. 1. The status database 300 includes a task column 302, an operator column 304, a status column 306 and an authentication column 308. Tasks and their associated subtasks are listed in the task column 302. For example, task T 1 includes subtask Si, S2 , S3 and S4 . In this example, the task T1 was divided into the four subtasks S1 , S2 , S3 , S4 by the task division module 204); and
providing the task identifier and the one or more subtasks to an approvals application (paras [0023] & [0043], wherein the authentication server 140 can modify the permission database 142 such that an operator is granted appropriate access rights to complete a task (e.g., minimum level and/or type of access to complete the task)……The status database 154 can store an indication or representation of the operator associated with a task and/or subtask, and can store authentication rights granted to that operator to complete the task and/or subtask. In some embodiments, the status database 154 can also include an identifier of an object (e.g., device, account, user, policy, etc.) on which that task and/or subtask is to be performed).
Regarding claims 4, 12, and 19, Khan discloses the method of claim 1, wherein the one or more approval policies are only applied at a subtask level (para [0039] & [0041], wherein…..the first operator might be assigned address-object creation rights associated with a particular device (e.g., Host A) but not other devices. Similarly, for example, the second operator might be provided access suitable to edit only the blacklisted network policy and not other network policies…… an operator is assigned a task and/or subtask, the access rights (e.g., type and/or level of access) associated with that operator's credentials can be automatically updated in the permission database 142 such that the operator has the appropriate access rights to accomplish, complete and/or perform the task and/or subtask).
Regarding claims 6 and 14, Khan discloses the method of claim 1, further comprising:
in response to the approval of the task, performing the task (paras [0039] & [0042]).
Khan et al. fails to explicitly disclose in response to determining that, for each subtask of the one or more subtasks of the task, the one or more approval requirements of each approval policy of the one or more approval policies are satisfied, approving the task.
Analogous art Banas discloses in response to determining that, for each subtask of the one or more subtasks of the task, the one or more approval requirements of each approval policy of the one or more approval policies are satisfied, approving the task (see Banas, para [0148], wherein referring now to Fig. 19 shows a task workflow where approval of tasks generally allows a project to move through one or more stages toward completion. A task workflow may comprise the following: assign, complete, approve, reject, and reassign….may comprise a project coordinator 1905, one or more task completers 1910, 1915, 1920, and one or more task approvers 1925, 1930, 1935, 1940. The project coordinator 1905 assigns one or more task completers 1910, 1915, 1920 to complete, and one or more task approvers 1925, 1930, 1935, 1940 to approve and/or reject. There are various series of approvals, reassignments and/or rejections that may take place prior to final approval by the project coordinator; para [0163], wherein validations and/or business rules; para [0156], wherein these milestone dates may be selected by an administrator in order to satisfy the project requirements and the objectives of the business. When a Complete task is generated, the user assigning the task will typically set the due date on the assignment popup; and para [0145], wherein the completed task 1515 may be moved to the approval stage 1530. In another representative embodiment of the present invention, if the task does not pass the approval stage 1530, it may be returned (i.e., remediated) back to the assign stage 1520).
One of ordinary skill in the art would have recognized that applying the known technique of Banas would have yielded predictable results and resulted in an improved system for the same reasons as stated above with respect to claim 1.
Regarding claims 7 and 15, Khan discloses the method of claim 6, further comprising:
in response to outputting the indication of the approval, receiving, from a service application, one or more results of performing the task (Fig. 1, paras [0024], [0028], and [0048], wherein the status level "closed" can mean that the operator has performed and/or completed the task and/or subtask. For example, operator U1 has completed the subtaskS1 of taskT1).
Khan et al. fails to explicitly disclose outputting an indication of the approval.
Analogous art Banas discloses outputting an indication of the approval (see Banas, para [0148], wherein referring now to Fig. 19 shows a task workflow where approval of tasks generally allows a project to move through one or more stages toward completion).
PNG
media_image1.png
126
314
media_image1.png
Greyscale
One of ordinary skill in the art would have recognized that applying the known technique of Banas would have yielded predictable results and resulted in an improved system for the same reasons as stated above with respect to claim 1.
Regarding claims 8 and 16, Khan discloses the method of claim 7, wherein the one or more results of performing the task include an indication of one or more created resources (Fig. 1, paras [0013] and [0048], wherein the status level "closed" can mean that the operator has performed and/or completed the task and/or subtask. For example, operator U1 has completed the subtaskS1 of taskT1……receive an indication that the first operator has completed the first subtask and to revoke the first
access right from the first operator based on the indication…….provide a second access right to a second operator based on the second subtask in response to the indication and the second operator being assigned the second subtask).
Regarding claim 17, Khan discloses a method for managing task approvals, the method comprising:
receiving, by a service application, one or more task arguments for a task that is requested to be approved, as set forth above with claims 1 and 3;
generating a task identifier for the task, the task identifier corresponding to the one or more task arguments, as set forth above with claim 3;
decomposing the task into one or more subtasks, as set forth above with claim 3; and
generating a task request including a task request identifier, the task request being associated with the task, the task request identifier corresponding to the task identifier, and each subtask of the one or more subtasks of the task corresponding to one or more approval policies, as set forth above with claim 1;
determining, for each subtask of the one or more subtasks of the task, whether the one or more approval policies are satisfied, as set forth above with claim 1;
in response to determining that, for each subtask of the one or more subtasks of the task, the one or more approval policies are satisfied, approving the task, as set forth above with claim 1; and
in response to the approving of the task, performing the task, wherein the method is performed by one or more processors, as set forth above with claims 1 and 6.
Claims 5, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Khan et al. (US Pub No. 2012/0060163) (hereinafter Khan et al.), in view of Banas et al. (US Pub No. 2008/0077530) (hereinafter Banas et al.), and further in view of Degenhardt et al. (US Pub No. 2007 /0283352) (hereinafter Degenhardt et al.).
Regarding claims 5, 13, and 20, Khan discloses the method of claim 1, wherein at least one subtask of the one or more subtasks includes an (edit) (see Khan, abstract and para [0041], wherein edit the network policy), and
wherein the method further includes:
invalidating an approval of the task, based on the version of the subtask of the task being changed (see Khan, para [0042], wherein authentication server 140 to revoke the access rights provided to the operator to complete the task and/or subtask).
Khan et al. and Banas et al. combined fail to explicitly disclose includes a version.
Analogous art Degenhardt discloses includes a version (see Degenhardt, para [0121], wherein each entry in the version map 908 refers to a version of a task/subtask definition 904);
Analogous art Degenhardt discloses changing the version of the subtask (see Degenhardt, para [0132], wherein the latest version activated before the task instance's invocation timestamp may be chosen).
Khan directed to a system for provide an access right to an operator from a set of operators assigned a subtask from the multiple subtasks. Degenhardt directed to providing a sub-task mechanism for development of user interfaces pertaining to a business task. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teachings of Khan, regarding the System for Dynamic Access Control based on a Task/Trouble Ticket, to have included a version; and changing the version of the subtask because both inventions teach improving accurate workload reporting. Further, the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Conclusion
The prior arts made of record and not relied upon is considered pertinent to applicant's disclosure. (US Pub No. 2013/0197954 and US Pub No. 2012/0060162).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAFIZ A KASSIM whose telephone number is (571)272-8534. The examiner can normally be reached 9:00 - 5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rutao Wu can be reached at 571-272-6045. 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.
/HAFIZ A KASSIM/Primary Examiner, Art Unit 3623 09/08/2026
Prosecution Insights