DETAILED ACTION
This is a non-final, first office action on the merits. 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 .
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; 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; and outputting an indication of the approval”.
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 § 102
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 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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-4, 6-12, and 14-19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Khan et al. (US Pub No. 2012/0060163) (hereinafter Khan et al.), hereinafter Khan.
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……);
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 (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 approval, wherein the method is performed by one or more processors (Fig. 1, paras [0024], [0028], and [0065], wherein... 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).
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]).
Regarding claims 7 and 15, Khan discloses the method of claim 1, 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).
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.
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 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 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 the 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. fails 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. 2021/0406831; US Pat No. 6,101,481; US Pub No. 2011/0282829; US Pub No. 2005/0021384; US Pat No. 7,155,720; US Pub No. 2009/0320088; US Pat No. 9,250,955, and B Dobrzyński, J Sosnowski (Tracing project development in Scrum model) - Photonics Applications in …, 2018 - spiedigitallibrary.org.
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 04/21/2026
Prosecution Insights