DETAILED ACTION
Statement of claims
The present application includes:
Independent Claims 1 , 8-11, 17-20, 26-28 are pending independent claims and claims 2-7, 12-16, 21-25 are pending dependent claims in this application.
Claims 1-28 are being considered on the merits.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/06/2025 and 04/17/2026 . The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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, 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(s) 1-28 are rejected under 35 U.S.C. 103 as being unpatentable over Blue et al. (US 2021/0389983, Blue hereinafter) in view of Li et al. (US 2020/0012531, Li hereinafter).
As claim 1, Blue teaches a computer system for handling multi-processes (e.g., see FIG. 1, para 34, “ multitenant service platform” for “ the operation of a task handler that utilizes the fork or exec model for creating new processes in the operating system of a services platform to handle incoming workload. and “ multi-processor systems”, “ data processors” in para 81), comprising:
a processor (e.g., one of the data processors), configured to: create a server socket to listen for incoming connection requests (e.g., para [0042] socket created during acceptance of the incoming socket request”, [0052] The parent process 202a may then create three sockets (e.g., socket servers), para 0025] While running, the parent process can receive incoming socket requests. These socket requests may include, for example, socket requests associated with service requests received over a network. When such a socket is received the parent process does not read from the socket. Instead the parent process may accept the socket request and fork a child process, handing off the unread socket to the forked child process. The parent process can then close any socket created during acceptance of the incoming socket request.);
in response to a connection request associated with a first process sent from a client terminal being accepted by the server socket (e.g., para “[0035] Client devices may access services platform 102 over a network 140” and “requests may come from different client applications 120 associated with different tenants 124 of the services platform 102 it is desirable to isolate the data and processes involved in the servicing of such service requests from one another.” In para), fork a first child process to handle tasks of the first process received from the client terminal (e.g., para [0044] When a forked child process starts (e.g., a child task handler instance 160b), the forked child process 160b may start executing the child code of the task handler 160).
However, Blue does not teach a graphic processor , in response to a first graphic task of the first process being received from the client terminal by the first child process, control the graphic processor to perform the first graphic task by the first child process.
Li teaches a graphic processor(e.g., see FIG. 3A, FIG. 26A and 26B) , in response to a first graphic task of the first process being received from the client terminal by the first child process (e.g., para 311, “ client 2602 specifies the client unit of the graphics device that processes the command data”, “a graphics processor command parser examines the client field of each command to condition the further processing of the command and route the command data to the appropriate client unit”, “Each client unit has a corresponding processing pipeline that processes the commands”), control the graphic processor to perform the first graphic task by the first child process (e.g.,para [0309]-[0312] “FIG. 26A illustrate the components that are generally included in a graphics command”, “ a sub-set of the graphics commands” , “ graphics processor command format 2600 of FIG. 26A includes data fields to identify a target client 2602 of the command”, “ Each client unit has a corresponding processing pipeline that processes the commands. Once the command is received by the client unit,”, “commands are aligned via multiples of a double word”, “a graphics processor uses a version of the command sequence shown to set up, execute, and terminate a set of graphics operation” .
Thus, the “commands are aligned” include the first graphic task).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Blue with those of Li because both references are directed to related systems addressing similar technical problems within the same field and seek to improve system performance, reliability, and efficiency.
Blue et al. discloses A computer system for handling multi-processes comprising: a processor, configured to: create a server socket to listen for incoming connection request while Li et al. teaches in response to a first graphic task of the first process being received from the client terminal by the first child process, control the graphic processor to perform the first graphic task by the first child process.
Incorporating the teachings of Li et al. into the system of Blue et al. would have been a predictable and logical modification, yielding improved operational robustness and efficiency without requiring undue experimentation.
Such a combination would merely involve the substitution or integration of known elements performing their established functions, as taught by Li et al., into the system of Blue et al., consistent with design incentives and market demands for improved performance and scalability. Moreover, Li et al. explicitly recognize benefits to “ increase processing efficiency” (see Li, in para 4) . —that would naturally be desirable in the system of Blue et al.
Accordingly, to one of ordinary skill in the art would have had a reasonable expectation of success in combining Blue et al. with Li et al., and the combination represents no more than the predictable use of prior art elements according to their known functions.
As to claim 2, Blue teaches wherein the processor is configured to: create a first child socket for the first child process to receive and handle the tasks of the first process sent from a first client socket of the client terminal (e.g., para 52, [0052] The parent process 202a may then create three sockets (e.g., socket servers). The first may be a work socket (server) which may be a (e.g., Transmission Control Protocol (TCP)) listening socket for the primary workload for servicing requests for the platform server. A second created socket may be an administrative socket (server) that is a socket utilized for system management tasks and a third socket (server) that will be an inter-process communication channel for receiving communications. This inter-process socket may be, for example, a User Datagram Protocol (UDP) socket.).
As to claim 3, Blue teaches wherein the first client socket is created in response to the first process being activated by the client terminal (e.g., para [0037] As the user interacts with a client application 120 (or more generally as the client application 120 operates), requests for various services 162 provided by the services platform 102 may be sent by the client application 120, received through the interface 112, and the service platform 102 may take appropriate actions.” And “ socket created during acceptance of the incoming socket request” in para 7).
As to claim 4 Blue does not teach wherein the first graphic task of the first process being received from the client terminal is a command corresponding to a graphic library of the graphic processor. However, Li teaches wherein the first graphic task of the first process being received from the client terminal is a command corresponding to a graphic library of the graphic processor ( e.g., para 281, “graphics libraries (e.g., Direct 3D and OpenGL) are executed”) .
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Blue by adopting the teachings of Li to “ increase processing efficiency” (see Li, in para 4).
As to claim 5, Blue teaches further wherein the processor is further configured to: in response to another connection request associated with a second process sent from the client terminal being accepted by the server socket, fork a second child process to handle tasks of the second process received from the client terminal (e.g., para 6, “a computing system may therefore comprise three parts 1) a parent (e.g., process)—responsible for startup, initialization, triggering the creation of child processes (children), and administering those children; 2) tasks—units of code to execute work for various purposes (e.g., the servicing of a request for a service received at the services platform); and 3) one or more child processes—a process created by forking the parent process with the intent of performing requested work (e.g. one or more tasks) and then exiting.”). However, Blue does not teach in response to a second graphic task of the second process being received from the client terminal by the second child process, control the graphic processor to perform the second graphic task by the second child process. Li teaches in response to a second graphic task of the second process being received from the client terminal by the second child process, control the graphic processor to perform the second graphic task by the second child process (e.g., see FIG. 26A and 26B, para [0309] Graphics Pipeline Programming”, [0311] In some embodiments, client 2602 specifies the client unit of the graphics device that processes the command data. In some embodiments, a graphics processor command parser examines the client field of each command to condition the further processing of the command and route the command data to the appropriate client unit. In some embodiments, the graphics processor client units include a memory interface unit, a render unit, a 2D unit, a 3D unit, and a media unit. Each client unit has a corresponding processing pipeline that processes the commands. Once the command is received by the client unit, the client unit reads the opcode 2604 and, if present, sub-opcode 2605 to determine the operation to perform. The client unit performs the command using information in data field 2606. For some commands an explicit command size 2608 is expected to specify the size of the command. In some embodiments, the command parser automatically determines the size of at least some of the commands based on the command opcode. In some embodiments, commands are aligned via multiples of a double word.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Blue by adopting the teachings of Li to “ increase processing efficiency” (see Li, in para 4).
As to claim 6, Blue teaches wherein the processor is configured to: create a first child socket for the first child process to receive and handle the tasks of the first process sent from a first client socket of the client terminal; and create a second child socket for the second child process to receive and handle the tasks of the second process sent from a second client socket of the client terminal, wherein the second child socket is different from the first child socket, and wherein the second client socket is different from the first client socket (e.g., para 52, [0052] The parent process 202a may then create three sockets (e.g., socket servers). The first may be a work socket (server) which may be a (e.g., Transmission Control Protocol (TCP)) listening socket for the primary workload for servicing requests for the platform server. A second created socket may be an administrative socket (server) that is a socket utilized for system management tasks and a third socket (server) that will be an inter-process communication channel for receiving communications. This inter-process socket may be, for example, a User Datagram Protocol (UDP) socket.).
As to claim 7, Blue teaches wherein the processor is further configured to: in response to the first process being inactivated by the client terminal, close the first child socket and terminate the first child process (e.g., para 23, “ child processes—a process created by forking the parent process with the intent of performing requested work (e.g. tasks) and then exiting”).
As to claim 8, see rejection of claim 1 above . Blue teaches further a computer system for handling multi-processes comprising: a processor, configured to: create a server socket to listen for incoming connection requests ( 0023] Embodiments as disclosed herein may thus provide a task handler that serves to isolate processes in a service (or other type of) platform by using the fork or exec model for creating new processes in an operating system to handle incoming workload (e.g., requests for services). The structure of embodiments may therefore comprise three parts 1) a parent (e.g., process)—responsible for startup, initialization, triggering the creation of child processes (children), and administering those children; 2) tasks—units of code to execute work created for various purposes (e.g., the servicing of a request for a service received at the services platform); and 3) one or more child processes—a process created by forking the parent process with the intent of performing requested work (e.g. tasks) and then exiting.).
As to claim 9, see rejection of claim 1 above.
As to claim 10, see rejection of claims 1 above.
As to claim 11, see rejection of claim 1 above . Blue teaches further A computer system for handling multi-threads (e.g., para 20, “ in a multi-threaded mode. By using a parent process that forks, and manages, child process ” and [0055] The parent process 202a can then determine if there is only one thread executing or if the parent process 202a is executing in multi-threaded environment (STEP 206)) comprising: a processor, configured to: receive a first message sent from a client terminal by a first child process forked from a parent process of the computer system (e.g., para( 0009] The parent process can receive messages from the children. For example, the parent process can receive such messages via an out-of-process communication (e.g., a UDP socket sent from a child process to the parent process).; determine whether a first thread identification (ID) included in the first message is known (e.g., see para 44, “incoming request (e.g., from the read socket) to identify the requested task 166 “. [0059] If the number of currently executing child processes exceeds the maximum allowable number of child process (e.g., 100), the fork entry point for a child may be set as a too busy entry point (Yes branch of STEP 226 and STEP 228). The parent process 202a can then fork a child process for the too busy task, handing the accepted socket for the work request to the forked child process and closing the accepted socket (STEP 230). This too busy task handling child process (not shown) can then handle sending a too busy response in response to that work request. Once the parent process 202a forks the child process for the request, a child tracking object 294 for the child process 202b may be added to the process map 290 using a corresponding child process identifier 292 (STEP 238). Such a child process identifier may be, for example, a unique identifier associated with the child process such as a process identifier (e.g., pid), a globally unique identifier (GUID) or another assigned or obtained identifier for the child process. Any data known on the process, such as a process identifier (e.g., pid), a socket accept time or any other data that may be obtained or determined about the child process can be updated in the child tracking object 294 associated with that child process in the process map 290.). However, Blue does not teach control the graphic processor to perform a first graphic task assigned in the first message by the first child process according to the first thread ID. Li teaches control the graphic processor to perform a first graphic task assigned in the first message by the first child process according to the first thread ID ( para [0065] During operation, the processing cluster array 212 can receive processing tasks to be executed via the scheduler 210, which receives commands defining processing tasks from front end 208. For graphics processing operations, processing tasks can include indices of data to be processed, e.g., surface (patch) data, primitive data, vertex data, and/or pixel data, as well as state parameters and commands defining how the data is to be processed (e.g., what program is to be executed). The scheduler 210 may be configured to fetch the indices corresponding to the tasks or may receive the indices from the front end 208. The front end 208 can be configured to ensure the processing cluster array 212 is configured to a valid state before the workload specified by incoming command buffers (e.g., batch-buffers, push buffers, etc.) is initiated.” and para 320, wherein “command in the command sequence. In one embodiment command execution is triggered using a pipeline synchronization command to flush the command sequence through the graphics pipeline. “ .
Thus, control the graphic processor to perform a first graphic task by the first child process according to the first thread ID).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Blue by adopting the teachings of Li to “ increase processing efficiency” (see Li, in para 4).
As to claim 12, Blue does not teach wherein the processor is configured to: push the first message into a first message queue corresponding to the first thread ID by the first child process; and pop out the first message from the message queue by a first server thread corresponding to the first thread ID to analyze the first message by the first child process. However, Li teaches wherein the processor is configured to: push the first message into a first message queue corresponding to the first thread ID by the first child process; and pop out the first message from the message queue by a first server thread corresponding to the first thread ID to analyze the first message by the first child process (e.g., wherein “para [0065] During operation, the processing cluster array 212 can receive processing tasks to be executed via the scheduler 210, which receives commands defining processing tasks from front end 208. For graphics processing operations, processing tasks can include indices of data to be processed” for “incoming command buffers (e.g., batch-buffers, push buffers, etc.). Thus, the buffer representing the message queue for the commands/messages , therefore, wherein the processor is configured to: push the first message into a first message queue corresponding to the first thread ID by the first child process; and pop out the first message from the message queue by a first server thread corresponding to the first thread ID to analyze the first message by the first child process).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Blue by adopting the teachings of Li to “ increase processing efficiency” (see Li, in para 4).
As to claim 13, Blue teaches further in response to the first thread ID being unknown, create a new server thread (e.g., see rejection of claim 1 above, para [0059] Once the parent process 202a forks the child process for the request, a child tracking object 294 for the child process 202b may be added to the process map 290 using a corresponding child process identifier 292 (STEP 238). Such a child process identifier may be, for example, a unique identifier associated with the child process such as a process identifier (e.g., pid), a globally unique identifier (GUID) or another assigned or obtained identifier for the child process. Any data known on the process, such as a process identifier (e.g., pid), a socket accept time or any other data that may be obtained or determined about the child process can be updated in the child tracking object 294 associated with that child process in the process map 290.. However, Blue does not teach a new message queue by the first child process, and map a correspondence among the new server thread, the new message queue, and the first thread ID by the first child process. Li teaches a new message queue by the first child process, and map a correspondence among the new server thread, the new message queue, and the first thread ID by the first child process (e.g., para [0065] During operation, the processing cluster array 212 can receive processing tasks to be executed via the scheduler 210, which receives commands defining processing tasks from front end 208. For graphics processing operations, processing tasks can include indices of data to be processed, e.g., surface (patch) data, primitive data, vertex data, and/or pixel data, as well as state parameters and commands defining how the data is to be processed (e.g., what program is to be executed). The scheduler 210 may be configured to fetch the indices corresponding to the tasks or may receive the indices from the front end 208. The front end 208 can be configured to ensure the processing cluster array 212 is configured to a valid state before the workload specified by incoming command buffers (e.g., batch-buffers, push buffers, etc.) is initiated. Thus, a new message queue by the first child process, and map a correspondence among the new server thread, the new message queue, and the first thread ID by the first child process) .
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Blue by adopting the teachings of Li to “ increase processing efficiency” (see Li, in para 4).
As to claim 14, Blue does not teach wherein the first thread ID is inserted in the first message in which the first graphic task is assigned by the client terminal . However, Li teaches wherein the first thread ID is inserted in the first message in which the first graphic task is assigned by the client terminal (e.g., para 64, wherein “the parallel processing unit 202 is used to perform graphics processing”, “a first portion may be configured to perform vertex shading and topology generation, a second portion may be configured to perform tessellation and geometry shading, and a third portion may be configured to perform pixel shading or other screen space operations, to produce a rendered image for display”. Thus, wherein the first thread ID is inserted in the first message in which the first graphic task is assigned by the client terminal).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Blue by adopting the teachings of Li to “ increase processing efficiency” (see Li, in para 4).
As to claim 15, Blue does not teach wherein the first graphic task of the first process being received from the client terminal is a command corresponding to a graphic library of the graphic processor. However, Li teaches teach wherein the first graphic task of the first process being received from the client terminal is a command corresponding to a graphic library of the graphic processor (e.g., para 281, “ graphics libraries (e.g., Direct 3D and OpenGL) are executed” and “graphics pipeline 2520 and media pipeline 2530 are configurable to perform operations based on multiple graphics and media programming interfaces and are not specific to any one application programming interface (API). In some embodiments, driver software for the graphics processor translates API calls that are specific to a particular graphics or media library into commands that can be processed by the graphics processor. “ in para 308).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Blue by adopting the teachings of Li to “ increase processing efficiency” (see Li, in para 4).
As to claim 16, Blue teaches further wherein the processor is further configured to: receive a second message sent from the client terminal by the first child process of the computer system; determine whether a second thread ID included in the second message is known (e.g., para 9, [0009] The parent process can receive messages from the children. For example, the parent process can receive such messages via an out-of-process communication (e.g., a UDP socket sent from a child process to the parent process). Such a communication from a child process may include data regarding the child and the associated task such as, for example, an execution state of a child, the resources used by the child during execution of the child, or statistics about the child process. ” for “a process identifier associated with the child process”, “Such a process map 290 may be, for example, a dictionary or array structure having an index comprising an identifier 292 for a child process associated with a corresponding tracking object 294 (child tracker object) for the associated child process” in para 24 and 54. Thus, “receive messages” include a second message ) . However, Blue does not teach in response to the second thread ID being known, control the graphic processor to perform the second graphic task assigned in the second message by the first child process according to the second thread ID. Li teaches teach control the graphic processor to perform the second graphic task assigned in the second message by the first child process according to the second thread ID (para [0064] In one embodiment, when the parallel processing unit 202 is used to perform graphics processing, the scheduler 210 can be configured to divide the processing workload into approximately equal sized tasks, to better enable distribution of the graphics processing operations to multiple clusters 214A-214N of the processing cluster array 212.
[0065] During operation, the processing cluster array 212 can receive processing tasks to be executed via the scheduler 210, which receives commands defining processing tasks from front end 208. For graphics processing operations, processing tasks can include indices of data to be processed, e.g., surface (patch) data, primitive data, vertex data, and/or pixel data, as well as state parameters and commands defining how the data is to be processed (e.g., what program is to be executed). The scheduler 210 may be configured to fetch the indices corresponding to the tasks or may receive the indices from the front end 208. The front end 208 can be configured to ensure the processing cluster array 212 is configured to a valid state before the workload specified by incoming command buffers (e.g., batch-buffers, push buffers, etc.) is initiated. ).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Blue by adopting the teachings of Li to “ increase processing efficiency” (see Li, in para 4).
As to claim 17. See rejection of claim 11 above. Blue teaches further a computer system for handling multi-threads (para [0055] The parent process 202a can then determine if there is only one thread executing or if the parent process 202a is executing in multi-threaded environment (STEP 206).
As to claims 18-20, see rejection of claim 11 above.
As to claim 21, Blue teaches wherein the processor is configured to: in response to the first process ID being known, designate an existing child process corresponding to the first process ID to handle the first message (e.g., para 24, “a process identifier associated with the child process,” and “the parent process may accept the socket request and fork a child process, handing off the unread socket to the forked child process. The parent process can then close any socket created during acceptance of the incoming socket request” in para 25)..
As to claim 22, Blue teaches in response to the first process ID being unknown, create a new child process and further map a correspondence the new child process and the first process ID (e.g., para [0041] Moreover, during initialization the parent process 160a creates a tracking structure 164 (e.g., such as a process map or the like) for observing and managing child processes 160b. These tracking structures 164 may include, or utilize, for example, tracking objects for child process that may be used to track data associated with those child processes 160b.” and “a process map 290 may be, for example, a dictionary or array structure having an index comprising an identifier 292 for a child process associated with a corresponding tracking object 294 (child tracker object) for the associated child process” in para 54).
As to claim 23, Blue does not teach wherein the first process ID is inserted in the first message in which the first graphic task is assigned by the client terminal. However, Li teaches the first process ID is inserted in the first message in which the first graphic task is assigned by the client terminal (para [0064] “to perform graphics processing”, [(0065] During operation, the processing cluster array 212 can receive processing tasks to be executed via the scheduler 210, which receives commands defining processing tasks from front end 208. For graphics processing operations, processing tasks can include indices of data to be processed, e.g., surface (patch) data, primitive data, vertex data, and/or pixel data, as well as state parameters and commands defining how the data is to be processed (e.g., what program is to be executed). The scheduler 210 may be configured to fetch the indices corresponding to the tasks or may receive the indices from the front end 208. The front end 208 can be configured to ensure the processing cluster array 212 is configured to a valid state before the workload specified by incoming command buffers (e.g., batch-buffers, push buffers, etc.) is initiated.).
As to claim 24, Blue does not teach wherein the first graphic task of the first process being received from the client terminal is a command corresponding to a graphic library of the graphic processor. However, Li teaches wherein the first graphic task of the first process being received from the client terminal is a command corresponding to a graphic library of the graphic processor ([0310] FIG. 26A is a block diagram illustrating a graphics processor command format 2600 according to some embodiments. FIG. 26B is a block diagram illustrating a graphics processor command sequence 2610 according to an embodiment. ).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Blue by adopting the teachings of Li to “ increase processing efficiency” (see Li, in para 4).
As to claim 25. , Blue teaches further wherein the processor is further configured to: receive a second message sent from the client terminal; determine whether a second process identification (ID) included in the second message is known; and in response to the second process ID being known ( para [0044] When a forked child process starts (e.g., a child task handler instance 160b), the forked child process 160b may start executing the child code of the task handler 160. Thus, the child 160b may read from the socket handed off by the parent task handler instance 160a and parse the incoming request (e.g., from the read socket) to identify the requested task 166 (e.g. implementing service 162) by means of a route to accomplish the incoming request (e.g., a request for a service 162 offered by the service platform 102). The child 160b can then invoke the task 166 using the identified route. The child task handler process 160b thus can serve as “wrapper” for the executed task 166 (e.g. implementing service 162), providing error handling and communication to the parent task handler instance 160a, route identification data to the parent task handler instance 160a and performance and resource telemetry to the parent task handler instance 160a (e.g., through the aforementioned out-of-process communication, such as a UDP socket sent from a child process to the parent process). However, Blue does not teach control the graphic processor to perform a second graphic task of a second process assigned in the second message according to the second process ID. Li teaches control the graphic processor to perform a second graphic task of a second process assigned in the second message according to the second process ID (para [0310] FIG. 26A is a block diagram illustrating a graphics processor command format 2600 according to some embodiments. FIG. 26B is a block diagram illustrating a graphics processor command sequence 2610 according to an embodiment. The solid lined boxes in FIG. 26A illustrate the components that are generally included in a graphics command while the dashed lines include components that are optional or that are only included in a sub-set of the graphics commands. The exemplary graphics processor command format 2600 of FIG. 26A includes data fields to identify a target client 2602 of the command, a command operation code (opcode) 2604, and the relevant data 2606 for the command. A sub-opcode 2605 and a command size 2608 are also included in some commands.) .
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Blue by adopting the teachings of Li to “ increase processing efficiency” (see Li, in para 4).
As to claim 26, see rejection of claims 1 and 11 above.
As to claim 27, see rejection of claims 1 and 11 above.
As to claim 28, see rejection of claims 1 and 11 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Malviya et al. (US 2022/0147893) discloses Various methods, apparatuses/systems, and media for automatic orchestration and scheduling of task processing are disclosed. A receiver receives user input from a user onto a user interface (UI). A processor accesses a database to verify role-based access control parameters corresponding to the user's access right; authenticates and authorizes access to the application based on a positive verification; translates the task processing request displayed on the UI of a user computing device into a corresponding action to be executed for completing the task; automatically schedules the action to be completed based on receiving scheduling data inputted onto the UI of the user computing device; automatically triggers a process to complete the task based on the scheduling data corresponding to the action; and automatically notifies a result of task completion data to the client computing device. The processor provides a command line interface to generate base orchestrator template with required dependencies and core functionality.
Rajic et al (US 2003/0187983) discloses 0036] The communication server, for example a socket server, of the local proxy listens for the remote proxy socket connection and handles the incoming socket data including the transfer of the remote proxy child application process ID. The outgoing socket data connection is used to encode the signal and to transfer data from the distributed application 502. Typically, the remote application 508 uses standard input and output (e.g., stdin, stdout, or stderr) to transfer data back and forth with its parent distributed application. The data are intercepted and retransmitted by the local and remote proxies.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDOU K SEYE whose telephone number is (571)270-1062. The examiner can normally be reached M-F 9-5:30.
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, Pierre Vital can be reached at 5712724215. 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.
/ABDOU K SEYE/Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights