DETAILED ACTION
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.
Claims 1-2, 9-10, 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Doyle (US Patent 6,009,455; hereinafter “Doyle”) in view of Sehgal et al. (US PGPUB 2014/0358482; hereinafter “Sehgal”) and Fitzer et al. (US PGPUB 2020/0186616; hereinafter “Fitzer”).
Claim 1: (Currently Amended)
Doyle teaches a distributed application processing method applied to a first device, comprising:
listening to a first task processing request used to request to process a first task (Col. 9 Ln. 10-24: “A job is submitted by a submitter sending a GetJobNumber message… the submitter sends a Submit message, i.e., a job request signal 40. The form of the message is as depicted in FIG. 7… The submitter will then initiate a file transfer to the master computer 5. This process will continue until all specified files are uploaded,” wherein the “master computer 5” is the “first device”.);
determining, from at least one subordinate device based on the first task processing request, a target device that processes the first task (Col. 4 Ln. 20-25: “A qualification algorithm 45 in the master control program determines if an available client is a candidate to participate in a distributed computation. The bases for such determination include the existence on the client of resources required by the particular job request.” Col. 6 Ln. 17-21: “FIG. 2d depicts the invention when two available clients 17 have been qualified by the master control program's qualification algorithm 45 and assigned segment group packages 19 by the assignment algorithm 46. The available clients then become selected clients 20,” wherein the “clients” comprise the “at least one subordinate device”.);
sending a task processing command to the target device (Col. 6 Ln. 21-24: “Each selected client is controlled by sending commands and files 21 from the master control program to the client control program over the network.”); and
receiving a result of processing the first task by the target device, wherein the result is obtained by using a second type of function module (Col. 6 Ln. 56-60: “FIG. 2e depicts the invention when the two selected clients have asynchronously completed the compute algorithm 23. Each signals the master control program that the group result 22 is computed, whereupon the output files are uploaded to the master computer.” Col. 5 Ln. 21-25: “When the job computation module 14 is invoked with a compute parameter list 31, the compute algorithm 25 reads the in-file list 36, reads any required input files named in the in-file list, and computes a segment result 26 for each segment in the sequence.” Col. 6 Ln. 30-31: “There are several variants in the makeup of a segment group package 19. FIGS. 8a-c depict three possibilities.” Col. 6 Ln. 43-45: “FIG. 8c shows the case where the executable file is a unique executable file 54, while the parameter list 51 and the data files 53 may or may not be unique,” wherein the “unique executable file 54” is the “second type of function module”.),
wherein the first device comprises a distributed application comprising a plurality of function modules (Col. 3 Ln. 8-17: “an application-specific master program 6 running in a master computer 5... The application-specific master program is designed to partition the calculation indicated in the job request signal into multiple segments. These can then be computed by an application-specific slave program 9 running on slave computers 8 that are connected to the master computer by a network 7,” wherein the “application-specific master program” is the “distributed application”.),
wherein a first type of function module in the plurality of function modules is installed on the first device used to perform at least part of the above operations (Col. 3 Ln. 17-19: “The results generated for each segment are combined by the application-specific master program into a final result,” wherein the functionality within the “application-specific master program” which combines the generated results is the “first type of function module”.),
wherein the second type of function module in the plurality of function modules is installed on a subordinate device (Col. 3 Ln. 8-17: “an application-specific master program 6 running in a master computer 5... The application-specific master program is designed to partition the calculation indicated in the job request signal into multiple segments. These can then be computed by an application-specific slave program 9 running on slave computers 8 that are connected to the master computer by a network 7.” Col. 9 Ln. 54-56: “the client computer is treated as a slave to the master control program,” wherein the “client computer” is the “subordinate device”. Col. 6 Ln. 43-45: “FIG. 8c shows the case where the executable file is a unique executable file 54, while the parameter list 51 and the data files 53 may or may not be unique,” wherein the “unique executable file 54”, i.e. which implements the “application-specific slave program”, is the “second type of function module”.), and
wherein the first device communicates with the at least one subordinate device by using a distributed operating system (OS) (Col. 3 Ln. 52-54: “The client control program may be activated by a screen-saver timer function in the operating system.” Col. 3 Ln. 57-61: “When the client control program is initially activated or is in the idle state, it executes an availability algorithm. The primary function of the availability algorithm is to notify the master computer that the client is available.”).
With further regard to Claim 1, Doyle does not teach the following, however, Sehgal teaches:
wherein the first device downloads an installation file of the distributed application ([0056] “FIG. 7 is a flowchart which illustrates an example flow of operations 700 that may be performed by a first computing resource, such as utility application store 102, to facilitate installation and/or activation of an application on one or more utility meters or other smart sensors,” wherein the “one or more utility meters or other smart sensors” are the claimed “at least one subordinate device”, as taught above by Doyle. [0057] “The flow of operations 700 may begin, at block 702, with the first computing resource serving an interface displaying multiple applications that are available for download by a second computing resource… the second computing resource comprises a personal computer, a mobile device, a utility meter reading device, or other computing device (e.g., other computing device 114),” wherein the “second computing resource” in Sehgal is the claimed “first device”. [0062] “at 718, transmitting the application… to the second computing resource (e.g., computing device 114)… for distribution to the one or more smart sensors.”).
Therefore, 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 method as disclosed by Doyle with the downloading as taught by Sehgal in order to “allow the user to purchase and install the application quickly and easily” (Sehgal [0075]).
With further regard to Claim 1, Doyle in view of Sehgal does not teach the following, however, Fitzer teaches:
wherein the distributed application is jointly implemented by a plurality of devices including the first device and the at least one subordinate device, and wherein the distributed application runs on the plurality of devices on which the distributed OS is installed ([0002] “Kubernetes is a system for automating deployment, scaling, and management of containerized applications. Application containerization is a virtualization method used by operating systems to deploy and run distributed applications.” [0038] “FIG. 5 is a block diagram 500 of Kubernetes nodes 520A, 520B, and 520C in a Kubernetes cluster 510 acting as a distributed operating system that provides a multitenancy/multiuser environment, according to some example embodiments. A Kubernetes master 580 of the Kubernetes cluster 510 receives communication requests from client devices to connect to applications hosted on the Kubernetes nodes 520A-520C.” [0062] “the URL received in the three connection requests may be associated with application A in FIG. 4,” and [0065] “two application requests from two different clients of the same tenant are routed to the same instance of the application,” wherein “Application A” is “jointly implemented” by both the “Kubernetes master,” i.e. “the first device”, and the “two different clients,” i.e. comprising “the at least one subordinate device,” see also Fig. 1 showing these “plurality of devices”.).
Therefore, 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 method as disclosed by Doyle in view of Sehgal with the implementation by a plurality of devices as taught by Fitzer in order to “improve the ease of deployment and leverage Kubernetes' ability to deploy applications across multiple nodes” (Fitzer [0021]).
Claim 2:
Doyle in view of Sehgal and Fitzer teaches the method of claim 1. Doyle in view of Fitzer does not teach the following, however Sehgal teaches wherein the determining the target device that processes the first task comprises:
displaying a first interface when at least two subordinate devices in the at least one subordinate device can process the first task, wherein the first interface comprises options of the at least two subordinate devices ([0040] “an application store interface module 508 may be configured to generate a graphical user interface (e.g., interface 116) presenting the applications that are available in the application repository 104. The application store interface module 508 may make the interface available to one or more users by, for example, publishing the interface to a website accessible by a browser of a client computing device.”); and
receiving a first selection operation performed by a user on the options of the at least two subordinate devices, and determining a subordinate device corresponding to the first selection operation as the target device (See Fig. 2, wherein [0032] “the purchase interface 200 includes… a ‘No. of Devices’ field to allow the user to specify the number of devices (in this case 100,000 devices) on which to install the application, and a ‘Device Type(s)’ control to allow the user to specify the type(s) of device(s) on which the application is to be installed. The Device Type(s) control is shown as a drop down menu, but could be a series of radio buttons, check boxes, free text entry fields, or any other control usable to specify one or more device types on which the application is to be installed.”).
Therefore, 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 method as disclosed by Doyle in view of Fitzer with the interface as taught by Sehgal in order “to allow the user to specify the type(s) of device(s) on which the application is to be installed” (Sehgal [0032]).
Claim 9:
Doyle in view of Sehgal and Fitzer teaches the method of claim 1. Doyle teaches further comprising:
receiving a task state query request entered by the user, wherein the task state query request is used to request to query a state of a task currently processed in the distributed application; determining, from the at least one subordinate device based on the task state query request, a second device having a task processing function; requesting, from the second device, a state of a task processed by the second device; and displaying the state of the task processed by the second device (Col. 7 Ln. 8-14: “If the master control program does not receive timely status messages from a selected client, it will deem that selected client off-line and reassign the associated segment group package to another available computer. This provides a simple but robust tolerance of network failures or unexpected client computer terminations.” Col. 10 Ln. 4-8: “the availability algorithm 13 in routine CheckAvailability, which checks to see if the spreadsheet program Excel is installed on the computer. If so, this will be reported to the master computer.”).
Claim 10:
Doyle in view of Sehgal and Fitzer teaches the method of claim 9. Doyle teaches further comprising:
receiving a task delete request entered by the user based on the state of the task processed by the second device; and sending the task delete request to the second device (Col. 7 Ln. 4-8: “In addition, the client control program may include algorithms to detect local user activity or other predetermined grounds for terminating computation. In this case, all files are deleted and the client control program returns to an idle state.”).
Claims 17-18:
With regard to Claims 17-18, these claims are equivalent in scope to Claim 1 rejected above, merely having a different independent claim type, and as such Claims 17-18 are rejected under the same grounds and for the same reasons as discussed above with regard to Claim 1.
Claim 19: (Currently Amended)
With regard to Claim 19, this claim is equivalent in scope to Claim 1 rejected above, merely having a different independent claim type, and as such Claim 19 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 1.
With further regard to Claim 19, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Sehgal reference also anticipates these additional elements of Claim 19, for example, wherein the first device associated with a distributed application comprises:
a processor; and a memory coupled with the processor to store instructions, which when executed by the processor, cause the first device to perform operations (Fig. 5: Processor(s) 500 and Memory 502).
Claim 20: (Currently Amended)
With regard to Claim 20, this claim is equivalent in scope to Claims 1 and 17 rejected above, merely having a different independent claim type, and as such Claim 20 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 1.
With further regard to Claim 20, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Sehgal reference also anticipates these additional elements of Claim 20, for example, wherein the subordinate device comprises:
a processor; and a memory coupled with the processor to store instructions, which when executed by the processor, cause the subordinate device to perform operations (Fig. 5: Processor(s) 500 and Memory 502).
Claims 3-4 are rejected under 35 U.S.C. 103 as being unpatentable over Doyle in view of Sehgal and Fitzer as applied to Claim 1 above, and further in view of Waffner (US PGPUB 2019/0190987; hereinafter “Waffner”).
Claim 3:
Doyle in view of Sehgal and Fitzer teaches all the limitations of claim 1 as described above. Doyle in view of Sehgal and Fitzer does not teach the following, however, Waffner teaches further comprising:
determining to perform distributed installation on the distributed application; determining a subordinate device on which the distributed application is installed and a function module of the distributed application installed on the subordinate device; and sending an installation file corresponding to the function module of the distributed application to a corresponding subordinate device ([0103] “the peer-to-peer network 102 comprises a plurality of nodes 106.1, 106.2, 106.3 and computers 106.1, 106.2, 106.3, respectively. Preferably, each of the nodes 106.1, 106.2, 106.3 comprises the (same) peer-to-peer application 104.” [0109] “The peer-to-peer processing apparatus 108 may comprise a peer-to-peer module 130 configured to communicate with the peer-to-peer network 102 and peer-to-peer application 104, respectively. For instance, a DAPP to be transferred and, in particular, to be installed onto the peer-to-peer processing apparatus 108 may be received via the peer-to-peer module 130 from the peer-to-peer application 104,” wherein the “peers” are the “subordinate devices”.).
Therefore, 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 method as disclosed by Doyle in view of Sehgal and Fitzer with the distributed application sending as taught by Waffner in order “to provide a communication system which enables to use available (processing) resources more efficient” (Waffner [0007]).
Claim 4:
Doyle in view of Sehgal, Fitzer and Waffner teaches all the limitations of claim 3 as described above. Doyle in view of Sehgal and Fitzer does not teach the following, however, Waffner teaches wherein the determining to perform distributed installation on the distributed application comprises:
detecting that the installation file of the distributed application comprises first indication information, wherein the first indication information indicates that the distributed application supports a distributed function; and determining, based on the first indication information, to perform distributed installation on the distributed application ([0043] “Transmission of the part of the distributed peer-to-peer application includes, in particular, the transmission of one or more messages comprising portions of the at least one part of the distributed peer-to-peer application to the peer-to-peer processing apparatus and/or the provision of the part of the distributed peer-to-peer application by the peer-to-peer application such that the peer-to-peer processing apparatus can read out (e.g. download) the respective data by its peer-to-peer module. For instance, based on an identifier and/or key transmitted to the peer-to-peer module, the peer-to-peer module is capable of accessing the correct data package in order to download the correct part of the distributed peer-to-peer application (in particular, in accordance with the stored distributed application transaction agreement).”).
Therefore, 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 method as disclosed by Doyle in view of Sehgal and Fitzer with the indication information as taught by Waffner in order “to provide a communication system which enables to use available (processing) resources more efficient and, at the same time, with high security” (Waffner [0007]).
Claims 5-7 and 12-16 are rejected under 35 U.S.C. 103 as being unpatentable over Doyle in view of Sehgal, Fitzer and Waffner as applied to Claims 1 and 3 above, and further in view of Lewis et al. (US Patent 5,761,380; hereinafter “Lewis”).
Claim 5:
Doyle in view of Sehgal, Fitzer and Waffner teaches all the limitations of claim 3 as described above. Doyle in view of Sehgal and Fitzer does not teach the following, however, Waffner teaches wherein the determining to perform distributed installation on the distributed application comprises:
detecting that the installation file of the distributed application comprises first indication information, indicating that the distributed application supports a distributed function ([0043] “For instance, based on an identifier and/or key transmitted to the peer-to-peer module, the peer-to-peer module is capable of accessing the correct data package in order to download the correct part of the distributed peer-to-peer application (in particular, in accordance with the stored distributed application transaction agreement).”).
Therefore, 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 method as disclosed by Doyle in view of Sehgal and Fitzer with the indication information as taught by Waffner in order “to provide a communication system which enables to use available (processing) resources more efficient and, at the same time, with high security” (Waffner [0007]).
With further regard to Claim 5, Doyle in view of Sehgal, Fitzer and Waffner does not teach the following, however, Lewis teaches wherein the determining to perform distributed installation on the distributed application comprises:
displaying a second interface based on the first indication information, wherein the second interface comprises a distributed installation option; and receiving a confirmation operation performed by the user on the distributed installation option, and determining, based on the confirmation operation, to perform distributed installation on the distributed application (See Fig. 4, wherein, Col. 7 Ln. 52-62: “In step 207, the expected performance for hardware similar to the local machine and a recommendation of a number of machines to distribute the components of the distributed application are calculated. These are presented to the user in step 209 which may begin an iterative process as described above and summarized as step 211, wherein the administrator uses the planning tool to evaluate various hardware and performance trade-offs to arrive at an installation plan which is acceptable. In step 213, the installation tool begins the execution of the accepted install plan.”).
Therefore, 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 method as disclosed by Doyle in view of Sehgal, Fitzer and Waffner with the installation interface as taught by Lewis in order “to relieve the network administrator from performing lengthy and detailed analysis for a successful installation and distribution of software components in a network” (Lewis Col. 1 Ln. 56-59).
Claim 6:
Doyle in view of Sehgal, Fitzer and Waffner teaches all the limitations of claim 3 as described above. Doyle in view of Sehgal, Fitzer and Waffner does not teach the following, however, Lewis teaches wherein the determining the subordinate device on which the distributed application is installed and the function module of the distributed application installed on the subordinate device comprises:
displaying a third interface comprising a candidate device on which the distributed application is installed and an option of a function module installed on each candidate device; receiving a second selection operation performed by the user on a function module installed on the candidate device; and determining, based on the second selection operation, the subordinate device on which the distributed application is installed and the function module installed on the subordinate device (See Fig. 4, wherein, Col. 7 Ln. 52-62: “In step 207, the expected performance for hardware similar to the local machine and a recommendation of a number of machines to distribute the components of the distributed application are calculated. These are presented to the user in step 209 which may begin an iterative process as described above and summarized as step 211, wherein the administrator uses the planning tool to evaluate various hardware and performance trade-offs to arrive at an installation plan which is acceptable. In step 213, the installation tool begins the execution of the accepted install plan.”).
Therefore, 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 method as disclosed by Doyle in view of Sehgal, Fitzer and Waffner with the installation interface as taught by Lewis in order “to relieve the network administrator from performing lengthy and detailed analysis for a successful installation and distribution of software components in a network” (Lewis Col. 1 Ln. 56-59).
Claim 7:
Doyle in view of Sehgal, Fitzer and Waffner teaches all the limitations of claim 3 as described above. Doyle in view of Sehgal, Fitzer and Waffner does not teach the following, however, Lewis teaches wherein the determining the subordinate device on which the distributed application is installed and the function module of the distributed application installed on the subordinate device comprises:
displaying a fourth interface comprising an option of a candidate device on which the distributed application is installed; receiving a third selection operation performed by the user on the candidate device, and determining, based on the third selection operation, the subordinate device on which the distributed application is installed; displaying a fifth interface, wherein an option of a function module installed on the 58 subordinate device is displayed in the fifth interface; and receiving a fourth selection operation performed by the user on the function module installed on the subordinate device, and determining, based on the fourth operation, the function module installed on the subordinate device (See Fig. 4, wherein, Col. 7 Ln. 52-62: “In step 207, the expected performance for hardware similar to the local machine and a recommendation of a number of machines to distribute the components of the distributed application are calculated. These are presented to the user in step 209 which may begin an iterative process as described above and summarized as step 211, wherein the administrator uses the planning tool to evaluate various hardware and performance trade-offs to arrive at an installation plan which is acceptable. In step 213, the installation tool begins the execution of the accepted install plan.”).
Therefore, 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 method as disclosed by Doyle in view of Sehgal, Fitzer and Waffner with the installation interface as taught by Lewis in order “to relieve the network administrator from performing lengthy and detailed analysis for a successful installation and distribution of software components in a network” (Lewis Col. 1 Ln. 56-59).
Claim 12:
Doyle in view of Sehgal, Fitzer and Waffner teaches all the limitations of claim 1 as described above. Doyle in view of Sehgal, Fitzer and Waffner does not teach the following, however, Lewis teaches further comprising:
receiving a management request entered by the user; and displaying, based on the management request, the subordinate device on which the distributed application is installed and a function module installed on the first device (See Fig. 4, wherein, Col. 7 Ln. 52-62: “In step 207, the expected performance for hardware similar to the local machine and a recommendation of a number of machines to distribute the components of the distributed application are calculated. These are presented to the user in step 209 which may begin an iterative process as described above and summarized as step 211, wherein the administrator uses the planning tool to evaluate various hardware and performance trade-offs to arrive at an installation plan which is acceptable. In step 213, the installation tool begins the execution of the accepted install plan.” See also Claim 12 of Lewis, “ wherein the user interface comprises: a plurality of user modifiable graphical objects for presenting and modifying hardware capability data of at least one computer system in the network.”).
Therefore, 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 method as disclosed by Doyle in view of Sehgal, Fitzer and Waffner with the installation interface as taught by Lewis in order “to relieve the network administrator from performing lengthy and detailed analysis for a successful installation and distribution of software components in a network” (Lewis Col. 1 Ln. 56-59).
Claim 13: (Currently Amended)
Doyle in view of Sehgal, Fitzer, Waffner and Lewis teaches all the limitations of claim 12 as described above. Doyle teaches further comprising:
receiving a function module addition request entered by the user; and when the function module addition request is used to add a function module to the first device, installing the added function module on the first device based on the function module addition request; or when the function module addition request is used to add a function module to a subordinate device, sending the function module addition request to the subordinate device to which the function module needs to be added (Col. 9 Ln. 10-24: “A job is submitted by a submitter sending a GetJobNumber message… the submitter sends a Submit message, i.e., a job request signal 40. The form of the message is as depicted in FIG. 7… The submitter will then initiate a file transfer to the master computer 5. This process will continue until all specified files are uploaded.” Col. 6 Ln. 21-24: “Each selected client is controlled by sending commands and files 21 from the master control program to the client control program over the network.” Col. 5 Ln. 21-25: “When the job computation module 14 is invoked with a compute parameter list 31, the compute algorithm 25 reads the in-file list 36, reads any required input files named in the in-file list, and computes a segment result 26 for each segment in the sequence.).
Claim 14:
Doyle in view of Sehgal, Fitzer, Waffner and Lewis teaches all the limitations of claim 13 as described above. Doyle further teaches wherein after the sending the function module addition request to the subordinate device to which the function module needs to be added, the method further comprises:
receiving a function module addition response sent by the subordinate device; and based on the function module addition response, updating information stored in the first device of the function module installed on the subordinate device (Col. 4 Ln. 16-25: “Each available client sends an availability signal 16 via the network to the master control program. The availability signal indicates the availability of the available client 17 as well as any resource information gathered by the availability algorithm. A qualification algorithm 45 in the master control program determines if an available client is a candidate to participate in a distributed computation. The bases for such determination include the existence on the client of resources required by the particular job request.” Col. 8 Ln. 58-65: “The first source file, isapijfd.cpp, is the master control program. The persistent state information is gathered in a single structure ‘State’ to facilitate an easy snapshot of system state to disk. ‘State’ comprises three arrays of data structures: ‘Submitters’ correspond to job request means 1 and job output means 3, ‘Contributors’ correspond to available client computers 17, and ‘Jobs’ corresponds to job request signals 40.”).
Claim 15: (Currently Amended)
Doyle in view of Sehgal and Fitzer, Waffner and Lewis teaches all the limitations of claim 12 as described above. Doyle teaches further comprising:
receiving a function module delete request entered by the user; and when the function module delete request is used to delete a function module from the first device, deleting, based on the function module delete request, the corresponding function module from the first device; or when the function module delete request is used to delete a function module from a subordinate device, sending the function module delete request to the subordinate device from which the function module needs to be deleted (Col. 7 Ln. 4-8: “In addition, the client control program may include algorithms to detect local user activity or other predetermined grounds for terminating computation. In this case, all files are deleted and the client control program returns to an idle state.”).
Claim 16:
Doyle in view of Sehgal and Fitzer, Waffner and Lewis teaches all the limitations of claim 15 as described above. Doyle teaches wherein after the sending the function module delete request to the subordinate device from which the function module needs to be deleted, the method further comprises:
receiving a function module delete response sent by the subordinate device; and
based on the function module delete response, updating information stored in the first device of the function module installed on the subordinate device (Col. 7 Ln. 4-8: “In addition, the client control program may include algorithms to detect local user activity or other predetermined grounds for terminating computation. In this case, all files are deleted and the client control program returns to an idle state.” Col. 3 Ln. 58-61: “When the client control program is initially activated or is in the idle state, it executes an availability algorithm. The primary function of the availability algorithm is to notify the master computer that the client is available.”).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Doyle in view of Sehgal, Fitzer and Waffner as applied to Claim 3 above, and further in view of Saner (US PGPUB 2012/0290530; hereinafter “Saner”).
Claim 8:
Doyle in view of Sehgal, Fitzer and Waffner teaches all the limitations of claim 3 as described above. Doyle in view of Sehgal, Fitzer and Waffner does not teach the following, however, Saner teaches wherein after the sending an installation file corresponding to the function module of the distributed application to the corresponding subordinate device, the method further comprises:
when receiving installation completion response messages returned by all subordinate devices, confirming that the distributed application is successfully installed; and displaying a fifth interface used to notify that installation of the distributed application is completed ([0099] “When the user cleaning module has been successfully deployed to all the computers of the group, the user interface of the administrator cleaning module can display a notification to the administrator.” [0100] “When the user cleaning module has been successfully deployed to all the computers of the network, the user interface of the administrator cleaning module can display a notification to the administrator.”).
Therefore, 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 method as disclosed by Doyle in view of Sehgal, Fitzer and Waffner with the installation completion notification as taught by Saner since this type of notification is well-known in the art to inform the user of a successful operation so that further operations can be carried out with the knowledge that the first operation has been successfully completed, thereby reducing the burden on the user to individually confirm the outcome of each installation operation.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Doyle in view of Sehgal and Fitzer as applied to Claim 9 above, and further in view of Saner.
Claim 11:
Doyle in view of Sehgal and Fitzer teaches all the limitations of claim 9 as described above. Doyle in view of Sehgal and Fitzer does not teach the following, however, Saner teaches further comprising:
receiving a task suspension request entered by the user based on the state of the task processed by the second device; and sending the task suspension request to the second device ([0074] “At step 620, the administrator cleaning module determines whether a user cleaning module has already been deployed onto the second computer using the user cleaning helper service. According to the embodiment, an older version of the user cleaning module may have already been deployed onto the second computer. In this embodiment, the older version of the user cleaning module may need to be stopped and deleted before a new version of the user cleaning module can be deployed. Therefore, a determination can be made regarding whether the user cleaning module has already been deployed... If a user cleaning module has already been deployed onto the second computer, the flow proceeds to step 630. ” [0075] “The user cleaning helper service can uninstall the user cleaning module that is already deployed by stopping any service associated with the user cleaning module, if such a service is running, and deleting the user cleaning module from the second computer.”).
Therefore, 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 method as disclosed by Doyle in view of Sehgal and Fitzer with the task suspension as taught by Saner in order “to avoid multiple versions of the user cleaning module being deployed onto a single computer” (Saner [0074]).
Response to Arguments
Applicant's arguments, see Pages 9-16 of the Remarks filed March 25, 2026, with respect to the rejections under 35 U.S.C. 103 of Claims 1-20 have been fully considered but they are not persuasive.
With respect to the Applicant’s arguments, Pages 9-14 of the Remarks, that the previously claimed unamended limitations are not taught by the previously cited prior art, i.e. the Doyle and Sehgal references, these arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. The Office notes that the Applicant’s arguments appear to be primarily directed at the newly amended limitations, i.e. the Applicant argues in Page 10 Paragraph 2, “However, Sehgal did not disclose the amended limitations,” and then goes on to restate the entirety of the final limitation of Claim 1, including both the unamended and amended portions. The Applicant does not specifically point out how the previously claimed unamended language of the claims is patentably distinguished from the Doyle and Sehgal references.
With further respect to the Applicant’s argument that the newly amended language of Claims 1, 17, 19 and 20 is not taught by the previously cited prior art, this argument has been fully considered but is moot in view of the newly cited Fitzer et al. (US PGPUB 2020/0186616) reference as discussed above in the respective rejections.
With respect to the Applicant’s further arguments, Pages 15-16 of the Remarks, that the features of the remaining claims are not taught by the cited prior art, the Office respectfully disagrees. These arguments rely upon the arguments as presented in relation to claims discussed above, and as such the Office directs the Applicant to the responses above regarding these arguments.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Rivard et al. (US PGPUB 2006/0059287) discloses a method and system for interconnecting various processor nodes and devices to a network to produce a network bus providing OS functionality, wherein the method and system execution of distributed applications on the network via master and slave device configurations.
Shorter (US Patent 4,969,092) discloses a method for scheduling time-initiated tasks from an Intelligent Work Station (IWS), wherein a network of loosely coupled logical units are used as a distributed operating system able to host a plurality of distributed application programs.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Joanne G. Macasiano whose telephone number is (571)270-7749. The examiner can normally be reached Monday to Thursday, 10:30 AM to 6:00 PM Eastern Standard Time.
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, Bradley Teets can be reached at (571) 272-3338. 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.
/JOANNE G MACASIANO/ Examiner, Art Unit 2197
Prosecution Insights