DETAILED ACTION
Election/Restrictions
Applicant's election with traverse of Group I (Claims 1-9), in the reply filed on 6/1/2026 is acknowledged.
The traversal is on the ground(s) that the restriction requirement on the grounds that the inventions of Group I and Group II are not patentably distinct, and that examination of all pending claims together would not impose a serious search and examination burden on the Examiner.
First, the Examiner's own restriction requirement establishes that Group I and Group II share the same classification, which contradicts the Examiner's basis for finding a serious search burden. The Office Action expressly classifies both Group I and Group II in the same CPC subclass, GO5B 15/00. Yet the only basis the Examiner identifies for the asserted search burden is that the inventions allegedly "require a different field of search (for example, searching different classes/subclasses or electronic resources, or employing different search queries)." Because both Groups are classified in the same CPC subclass, the Examiner has not shown that the two Groups in fact require searching different classes or subclasses. The Examiner's reliance on "different search queries" is conclusory and unsupported.
The two Groups in this application are not merely usable together; they are two halves of the same client-server transaction expressly disclosed in the specification. The specification expressly describes these two sides of the same transaction as performed cooperatively. Paragraph [0092] describes that the automation start permission "can be requested 406 ... by an Application Programming Interface (API) call ... to an automation server," while paragraph [00100]-[00102] describes how the automation management server receives that same API request, parses the SR identifier, queries the status database, determines the automation start permission, and returns the response. The execution management process of FIG. 4 (performed by the client/automation platform) and the execution status process of FIG. 6 (performed by the automation management server) are expressly described as cooperating halves of a single permission-handling transaction. (See Spec., [0090]-[0094], [00100]-[00103].) Because the Group I claims require a request to a remote service and a response from that remote service - i.e., they require the very server-side counterpart recited in Group II – the Groups are not "separately usable" in the sense required by MPEP § 806.05(d). Restriction between subcombinations that are functionally interdependent is improper.
Third, the Examiner has not established the requisite serious search and examination burden under MPEP § 803. A prior art search directed to the client-side method of Group I - which expressly recites requesting an automation start permission from a remote service via an API call, receiving a response indicating an availability status of a dependent application program, and determining whether the software robot has permission to execute - will necessarily encompass references disclosing the server-side counterpart of that same transaction. The Examiner cannot search Group I without encountering, and considering, the server-side automation management functionality recited in Group II, because the Group I claims themselves recite that server-side interaction as a required limitation. Conversely, a search for the cross- platform automation management server of Group II will inherently encompass the client-side requests it is configured to service. The Examiner's assertion that the two Groups "employ different search queries" is therefore conclusory and is not supported by the claim language. This is not found persuasive.
As an initial point, as Applicant is likely aware, groups being classified in the same CPC designation in no way precludes the claims from being restricted. As discussed in the restriction requirement, employing different search queries indeed qualifies as a serious search and examination burden, if restriction were not required. Contrary to Applicant’s assertion, here, a mere review of the claim language of the two Groups (claims 1-9 and claims 24-34), would result in a conclusion that employing different search queries is required.
Additionally, as described in paragraph 0069, “Typically, the automation management server 208 is a separate server from an RPA system, such that the automation management server 208 is able to provide services to various different automation platforms or to various software robots therefrom.” Further, paragraphs 0070 and 0071 recite that “The automation management server 208 can determine whether a software robot is presently able to execute. In doing so, the automation management server 208 can couple to a status database 210. The status database 210 can store status data relevant to execution of software robots…The automation management server 208 can access the status data stored in the status database 210 and use a relevant portion of such status data in determining whether a software robot is presently permitted to execute. In one implementation, the automation management server 208 can operate to monitor resources and/or approvals potentially utilized by computing device(s) in their execution of corresponding software robots.” As such, and contrary to Applicant’s assertion, the subcombinations are indeed distinct from each other, since they are shown to be separately usable.
Lastly, and contrary to Applicant’s assertion, the Examiner has indeed established the requisite serious search and examination burden under MPEP § 803. As discussed above, the separately usable Groups require employing different search queries, thus indeed qualifying as a serious search and examination burden. A simple review of the claim language of the two Groups (claims 1-9 and claims 24-34), would result in a conclusion that employing different search queries would be required.
The requirement is still deemed proper and is therefore made FINAL.
Claims 1-9 and 24-34 are pending, while claims 24-34 have been withdrawn. Claims 1-9 have been examined.
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-9 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims are directed to an abstract idea without significantly more.
Here, under step 1 of the Alice analysis, method claims 1-9 are directed to a series of steps. Thus the claims are directed to a process.
Under step 2A Prong One of the analysis, the claimed invention is directed to an abstract idea without significantly more. The claims recite controlling execution of software robots, including identifying, requesting, receiving, determining, and permitting steps.
The limitations of identifying, requesting, receiving, determining, and permitting, are a process that, under its broadest reasonable interpretation, covers organizing human activity concepts, but for the recitation of generic computer components.
Specifically, the claim elements recite identifying a software robot to be executed; requesting, from a remote service, execution permission for execution of the software robot; receiving a response from the remote service; determining whether the software robot has permission to execute based on the response from the remote service; and permitting execution of at least a portion of the software robot if the determining determines that the software robot has permission to execute.
That is, the claim limitations merely cover managing interactions, including following rules, thus falling within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
Under Step 2A Prong Two, the eligibility analysis evaluates whether the claim as a whole integrates the recited judicial exception into a practical application of the exception. This judicial exception is not integrated into a practical application. The claims fail to include any additional elements implementing the method steps (e.g., a processor, server, computer, etc.). As a result, the claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
None of the dependent claims recite additional limitations that are sufficient to amount to significantly more than the abstract idea. Claims 2 and 3 further describe the remote service and identifying of the software robot. Claims 4 and 5 recite additional registering steps, while claims 6-9 further describe the dependency data, the response, and the determining whether the software robot has permission to execute. A more detailed abstract idea remains an abstract idea.
Under step 2B of the analysis, there isn’t any improvement to another technology or technical field, or the functioning of the computer itself. Moreover, individually, there are not any meaningful limitations beyond generally linking the abstract idea to a particular technological environment, i.e., implementation via a computer system. Further, taken as a combination, the limitations add nothing more than what is present when the limitations are considered individually. There is no indication that the combination provides any effect regarding the functioning of the computer or any improvement to another technology.
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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 and 2 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Krishnamurthy et al (US 20200348960 A1).
As per claim 1, Krishnamurthy et al disclose a method for controlling execution of software robots (i.e., “bot runner” refers to a device (virtual or physical), having the necessary software capability (such as bot player 126), on which a bot will execute or is executing, ¶ 0021), comprising:
identifying a software robot to be executed (i.e., “bot runner” refers to a device (virtual or physical), having the necessary software capability (such as bot player 126), on which a bot will execute or is executing, ¶ 0021);
requesting, from a remote service, execution permission for execution of the software robot (i.e., RPA system 10 to respond to a request from a client device 110 that is issued by a user 112.1 to act as a server to provide to the client device 110 the capability to perform an automation task…, ¶ 0021);
receiving a response from the remote service (i.e., The control room 108 responds by retrieving the requested bot, Bot 1 and providing it to user session manager 124.1 which is executing on device 110, ¶ 0032);
determining whether the software robot has permission to execute based on the response from the remote service (i.e., The context includes security, permissions, audit trails, etc. to define the permissions and roles for bots operating under the user session 118, ¶ 0021); and
permitting execution of at least a portion of the software robot if the determining determines that the software robot has permission to execute (i.e., RPA system 10 preferably is able to support multiple client devices 110 concurrently, each of which will have one or more corresponding user session(s) 118, which provides a context. The context includes security, permissions, audit trails, etc. to define the permissions and roles for bots operating under the user session 118, ¶ 0021).
As per claim 2, Krishnamurthy et al disclose the response from the remote service includes an automation start permission, and wherein the determining whether the software robot has permission to execute is based on the automation start permission included in the response from the remote service (i.e., RPA system 10 preferably is able to support multiple client devices 110 concurrently, each of which will have one or more corresponding user session(s) 118, which provides a context. The context includes security, permissions, audit trails, etc. to define the permissions and roles for bots operating under the user session 118, ¶ 0021).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Krishnamurthy et al (US 20200348960 A1), in view of Kalsi et al (US 20230063724 A1).
As per claim 3, Krishnamurthy et al disclose the identifying of the software robot to be executed includes at least identifying a software robot (SR) identifier for the software robot to be executed (i.e., the bot launcher 144, upon receiving an identifier for a bot 104 requested by user 112 (such as for example Bot 1) and an identifier for a device requested by user 112, accesses at 330 the requested bot to identify at 332 requirements, ¶ 0034),
Krishnamurthy et al does not disclose wherein the requesting execution permission for execution of the software robot issues at least an Application Programming Interface (API) call to the remote service, the API call at least identifying the software robot for which execution permission is sought by the SR identifier.
Kalsi et al disclose, in a more advanced approach, bots could be implemented as permanent running processes which subscribe to events of the access management tool and to the target systems to react to changes. Thus, a software bot may comprise a periodically scheduled job executing a script interacting with APIs or a probot implementation (¶ 0048).
Krishnamurthy et al and Kalsi et al are concerned with effective software bot management. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include wherein the requesting execution permission for execution of the software robot issues at least an Application Programming Interface (API) call to the remote service, the API call at least identifying the software robot for which execution permission is sought by the SR identifier in Krishnamurthy et al, as seen in Kalsi et al, since 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 art made of record and not relied upon, listed in the PTO-892, considered pertinent to applicant's disclosure, discloses software bot management.
With respect to dependent claim 4, including the dependency on intervening claim 2, none of the prior art of record, taken individually or in any combination, teach inter alia, wherein the response from the remote service includes an automation start permission, and wherein the determining whether the software robot has permission to execute is based on the automation start permission included in the response from the remote service, and registering the software robot with the remote service, the registering providing descriptive data pertaining to the software robot and assigning the software robot a software robot (SR) identifier, the registering being prior to the requesting execution permission for execution of the software robot.
With respect to dependent claim 5, including the dependency on intervening claim 2, none of the prior art of record, taken individually or in any combination, teach inter alia, wherein the response from the remote service includes an automation start permission, and wherein the determining whether the software robot has permission to execute is based on the automation start permission included in the response from the remote service, and registering the software robot with the remote service, the registering providing descriptive data and dependency data pertaining to the software robot and assigning the software robot a software robot (SR) identifier, the registering being prior to the requesting execution permission for execution of the software robot.
Additionally, dependent claims 6-9 depend from dependent claim 5, including the respective intervening claims.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDRE D BOYCE whose telephone number is (571)272-6726. The examiner can normally be reached M-F 10a-6:30p.
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 (Rob) 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.
/ANDRE D BOYCE/Primary Examiner, Art Unit 3623 June 22, 2026
Prosecution Insights