DETAILED ACTION
Remarks
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office action is filed in response to Applicant’s arguments and amendment dated June 4, 2026. Claims 1, 2, 4-6, 8-10, 14-17, and 20-22 are currently amended and claims 1-6, 8-11, 13-18, and 20-22 remain pending in the application and have been fully considered by Examiner.
In view of Applicant’s amendments, the 35 USC 112(b) rejections presented in the Non-Final Office action mailed on September 24, 2025, have been withdrawn.
Applicant's arguments with respect to the prior art rejections have been considered but are not persuasive, as detailed below in the Prior Art Argument - Rejections section.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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, 3, 5, 6, 8, 9, 11, 14, 15, 16, 18, 21, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Bates (US 20120084758, hereinafter Bates) in view of Garcia (US 9471466, hereinafter Garcia), and Zinkovsky et al. (US 20120151452, hereinafter Zinkovsky).
With respect to claim 1, Bates discloses A system (e.g., Fig. 1) comprising:
one or more processors; and a memory coupled to the one or more processors (e.g. Fig. 1, particularly, Processor 156 and RAM 168.) and comprising:
a computer program (e.g., Fig. 1 and associated text, e.g., [0030], back-end debugger (118) is an application that controls operation of another application -- the debuggee (120) -- for the purpose of testing execution of the debuggee [a computer program].);
; and
a configured to manage a plurality of multiplayer debugger sessions , the configured to (e.g., Fig. 1 and associated text, e.g., [0024], A debug session is a semi-permanent interactive information interchange between at least one debug client and a debug server for the purposes of a debugging a particular debuggee; [0028], listening agent (129) may … begin execution of a particular collaborative debug server application (130) upon request … The server (102) in the example of FIG. 1, may support simultaneous execution of several different debug server applications, each of which may debug separate debuggees [a plurality of multiplayer debugger sessions]; [0030] The debug administrator (114) is a module … that administers a collaborative debug session.):
create, , a first multiplayer debugger session and a second multiplayer debugger session (e.g., Fig. 1 and associated text, e.g., [0024], A debug session [multiplayer debugger session] is a semi-permanent interactive information interchange between at least one debug client and a debug server for the purposes of debugging a particular debuggee; [0028], listening agent (129) may … begin execution of a particular collaborative debug server application (130) upon request … The server (102) in the example of FIG. 1, may support simultaneous execution of several different debug server applications, each of which may debug separate debuggees [a first multiplayer debugger session and a second multiplayer debugger session].),
wherein the first multiplayer debugger session comprises a first debugger multiplexer instance and a first debugger , and supports a first plurality of client devices in accordance with the first plurality of client devices having subscribed to the first multiplayer debugger session (e.g., Figs. 1, 4, and 9 and associated text, e.g., [0030], registering [subscribed] and unregistering clients in a debug session; [0031], From the perspective of the back-end debugger (118) [first debugger], the debugger is controlled by a single source, the message router (116) [first debugger multiplexer instance]; [0032], receiving, by the debug server (102) from the debug clients (104) [first plurality of client devices] asynchronously during a debug session of the debuggee (120), a plurality of application-level messages (126); routing, by the message router (116) … the application-level messages (126) among the debug clients, the debug administrator, and the back-end debugger … the message router (116) provides distributed control of the back-end debugger (118) to the debug clients (104) with the application-level messages (126) routed to the back-end debugger (118).), and
wherein the second multiplayer debugger session comprises a second debugger multiplexer instance and a second debugger , and supports a second plurality of client devices in accordance with the second plurality of client devices having subscribed to the second multiplayer debugger session (Id., particularly, [0030], registering [subscribed] and unregistering clients in a debug session; [0028], The server (102) in the example of FIG. 1, may support simultaneous execution of several different [first and second] debug server applications, each of which may debug separate debuggees; [0029], collaborative debug server application (130) also includes a debug administrator (114), a message router (116), a back-end debugger (118), and a debuggee (120); [0032], the message router (116) provides distributed control of the back-end debugger (118) to the debug clients (104) with the application-level messages (126) routed to the back-end debugger (118).);
receive, from a first client device of the first plurality of client devices, a debugger operation for the first multiplayer debugger session (e.g., Figs. 1-3, 7, and 9 along with associated text, e.g., [0071], generating, by a requesting debug client (702), a request (706) to issue a command (718) [debugger operation] to the back-end debugger (118), sending the request (706) to the debug server (102), and receiving the request (722) by the message router (116); [0073], executing the command (718) causes the back-end debugger (118) to initiate execution (719) of the debuggee, for debugging purposes, monitor the execution of the debuggee, and gather results (720).),
transmit the debugger operation to the first debugger (e.g., Figs. 1-3, 7, and 9 and associated text, e.g., [0073], The method of FIG. 7 also includes routing the request (706) to the back-end debugger (118) by issuing the command (718) to the back-end debugger (118) by the message router (116).),
determine, by the first debugger multiplexer instance, an updated program state in accordance with the debugger operation (e.g., Figs. 1-3, 7, and 9 along with associated text, e.g., [0074], After executing the issued command in the example of FIG. 7, the back-end debugger (118) returns to the message router (116) results (720) of the execution of the issued command, the message router [debugger multiplexer instance] receives the results (718) [updated program state in accordance with the debugger operation]. The nature of the results (720) of the execution depend upon the type of command (718) executed by the back-end debugger. A command to evaluate a variable for example, may return as little as an integer, while a command to step into execution of the debuggee may return significantly more information--variable values, register values, memory values, line number, source code file name, and thread number and so on. The results (720), once received by the requesting client (702) may be used to control the client-specific GUI, changing the information displayed on the GUI.),
transmit, by the first debugger multiplexer instance, the updated program state to a remainder of the first plurality of client devices (e.g., Figs. 1-3, 6, 7, 9, and 11-12 along with associated text, e.g., [0040], `Public` evaluation by contrast means that the results of the evaluation [updated program state] may be presented to other clients -- a predefined group, one or more clients selected in real-time during the selection of the variable to evaluation, or all clients registered in the debug session [remainder of the plurality of client devices]; [0067], generating, by a requesting debug client (602), a request (606) to distribute data (613) to debug clients registered in the debug session; [0069], sending, by the message router (116) [first debugger multiplexer instance] to debug clients identified as intended recipients (602) in the request (606) to distribute data, a reply (622) … and receiving, by the debug clients identified as intended recipients (602), the reply (622) … having … a payload (632) included in the request (606) to distribute data; [0099], payload that includes the results of the evaluation of the variable; see also [0097-99].),
wherein the updated program state is isolated from the second plurality of client devices in accordance with the first plurality of client devices having subscribed to the first multiplayer debugger session failing to include the second plurality of client devices (Id., particularly, [0040], `Public` evaluation by contrast means that the results of the evaluation [updated program state] may be presented to … all clients registered [subscribed] in the debug session, and [0067], generating, by a requesting debug client (602), a request (606) to distribute data (613) to debug clients registered in the debug session; [0024], A debug session is a semi-permanent interactive information interchange between at least one debug client and a debug server for the purposes of a debugging a particular debuggee; [0028], The server (102) in the example of FIG. 1, may support simultaneous execution of several different debug server applications [first and second multiplayer debugger sessions]; [0058], The debug administrator (114) then registers the requesting debug client (402) in the debug session and assigns the requesting debug client (402) a client identifier (420) unique to the debug session. After assignment a client identifier may be used in message passing among the debug clients, debug server, and debug administrator to identify a recipient of a message, to identify a sender of a message, and so on; see also [0034]; Examiner note: as illustrated in the portions quoted above, Bates discloses distributing evaluation results [updated program state] only to clients registered [subscribed] to that specific debug session and not to any other debug clients, i.e., wherein the updated program state is isolated from the second plurality of client devices in accordance with the first plurality of client devices having subscribed to the first multiplayer debugger session failing to include the second plurality of client devices, as claimed.), and
wherein the first multiplayer debugger session and the second multiplayer debugger session are active at a same time (e.g., Fig. 1 and associated text, e.g., [0028], simultaneous execution of several different debug server applications, each of which may debug separate debuggees.).
Although Bates discloses multiple debug server modules that cooperatively perform the functionality of a debugger session manager (see above), it does not appear to disclose a singular debugger session manager. However, this is taught in analogous art, Garcia (e.g., Fig. 1, particularly, Debug Manager 108 [debugger session manager] along with associated text, e.g., col. 3:33-49, The debug manager 108 provides two distinct services (among other functionality): a connection service 130 and a debug-request service 132 … their functionality is provided in an integrated single module.).
Although Bates discloses first and second debugger sessions for debugging separate computer programs (see above), it does not appear to disclose that the debugger sessions are both for the computer program. However, this is further taught in Garcia (e.g., Fig. 1, particularly, e.g., col. 3:33-49, the back-end server may run … multiple instances of the same application, in multiple sessions for one or more clients.).
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 debugging invention of Bates with the debugger manager invention of Garcia, such that debugging sessions are for an instance of the same program and are managed by an integrated debug manager, because integrating multiple management modules into one would simplify implementation and simultaneously debugging instances of the same program would speed up debugging efforts for that program.
Although Bates discloses a first debugger and a second debugger (see above), it does not appear to disclose a debugger module … instance of the debugger module … instance of the debugger module … instance. However, this is taught in analogous art, Zinkovsky (e.g., Fig. 1, particularly, Non-invasive Debugger 115 [debugger module] and Non-Invasive Debugger 116 [debugger instances of the debug module] along with associated text, e.g., [0020], server process 118 executing on the server computer 102 can include one or more … sessions such as user session 1 104, user session 2 106. . . user session n 108 in which an instance of the cooperative, non-invasive, non-blocking debugger (e.g., debugger instance 116) is executing. Each user session … supports or cooperates with the cooperative, non-invasive, non-blocking debugger [debugger module] and an instance of the cooperative, non-invasive, non-blocking debugger 116 [instances of the debugger module].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Bates with the debugger invention of Zinkovsky, such that debuggers are provided in sessions as an instance of a debugger module, because “Users need to be able to debug their code instances without having any impact on each other or on anyone else being served by the process in any way,” as suggested by Zinkovsky (see [0011]).
With respect to claim 8, Bates discloses A non-transitory computer readable medium comprising computer readable code executable by one or more processors to (e.g., Fig. 1 and associated text, e.g., [0101], aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.):
create a first multiplayer debugger session and a second multiplayer debugger session for ,
wherein the first multiplayer debugger session comprises a first debugger multiplexer instance and a first debugger , and supports a first plurality of client devices in accordance with the first plurality of client devices having subscribed to the first multiplayer debugger session (e.g., Figs. 1, 4, and 9 and associated text, e.g., [0030], registering [subscribed] and unregistering clients in a debug session; [0031], From the perspective of the back-end debugger (118), the debugger is controlled by a single source, the message router (116) [first debugger multiplexer instance]; [0032], receiving, by the debug server (102) from the debug clients (104) [first plurality of client devices] asynchronously during a debug session of the debuggee (120), a plurality of application-level messages (126); routing, by the message router (116) … the application-level messages (126) among the debug clients, the debug administrator, and the back-end debugger [first debugger] … the message router (116) provides distributed control of the back-end debugger (118) to the debug clients (104) with the application-level messages (126) routed to the back-end debugger (118).), and
wherein the second multiplayer debugger session comprises a second debugger multiplexer instance and a second debugger , and supports a second plurality of client devices in accordance with the second plurality of client devices having subscribed to the second multiplayer debugger session (Id., particularly, [0030], registering [subscribed] and unregistering clients in a debug session; [0028], The server (102) in the example of FIG. 1, may support simultaneous execution of several different [first and second] debug server applications, each of which may debug separate debuggees; [0029], collaborative debug server application (130) also includes a debug administrator (114), a message router (116), a back-end debugger (118), and a debuggee (120); [0032], the message router (116) provides distributed control of the back-end debugger (118) to the debug clients (104) with the application-level messages (126) routed to the back-end debugger (118).);
receive, from a first client device of the first plurality of client devices, a debugger operation for the first multiplayer debugger session (e.g., Figs. 1-3, 7, and 9 along with associated text, e.g., [0071], generating, by a requesting debug client (702), a request (706) to issue a command (718) [debugger operation] to the back-end debugger (118), sending the request (706) to the debug server (102), and receiving the request (722) by the message router (116); [0073], executing the command (718) causes the back-end debugger (118) to initiate execution (719) of the debuggee, for debugging purposes, monitor the execution of the debuggee, and gather results (720).);
transmit the debugger operation to the first debugger (e.g., Figs. 1-3, 7, and 9 and associated text, e.g., [0073], The method of FIG. 7 also includes routing the request (706) to the back-end debugger (118) by issuing the command (718) to the back-end debugger (118) by the message router (116).);
determine, by the first debugger multiplexer instance, an updated program state in accordance with the debugger operation (e.g., Figs. 1-3, 7, and 9 along with associated text, e.g., [0074], After executing the issued command in the example of FIG. 7, the back-end debugger (118) returns to the message router (116) results (720) of the execution of the issued command, the message router [debugger multiplexer instance] receives the results (718) [updated program state in accordance with the debugger operation]. The nature of the results (720) of the execution depend upon the type of command (718) executed by the back-end debugger. A command to evaluate a variable for example, may return as little as an integer, while a command to step into execution of the debuggee may return significantly more information--variable values, register values, memory values, line number, source code file name, and thread number and so on. The results (720), once received by the requesting client (702) may be used to control the client-specific GUI, changing the information displayed on the GUI.); and
transmit, by the first debugger multiplexer instance, the updated program state to a remainder of the first plurality of client devices (e.g., Figs. 1-3, 6, 7, 9, and 11-12 along with associated text, e.g., [0040], `Public` evaluation by contrast means that the results of the evaluation [updated program state] may be presented to other clients -- a predefined group, one or more clients selected in real-time during the selection of the variable to evaluation, or all clients registered in the debug session [remainder of the plurality of client devices]; [0067], generating, by a requesting debug client (602), a request (606) to distribute data (613) to debug clients registered in the debug session; [0069], sending, by the message router (116) [first debugger multiplexer instance] to debug clients identified as intended recipients (602) in the request (606) to distribute data, a reply (622) … and receiving, by the debug clients identified as intended recipients (602), the reply (622) … having … a payload (632) included in the request (606) to distribute data; [0099], payload that includes the results of the evaluation of the variable.),
wherein the updated program state is isolated from the second plurality of client devices in accordance with the first plurality of client devices having subscribed to the first multiplayer debugger session failing to include the second plurality of client devices (Id., particularly, [0040], `Public` evaluation by contrast means that the results of the evaluation [updated program state] may be presented to … all clients registered [subscribed] in the debug session, and [0067], generating, by a requesting debug client (602), a request (606) to distribute data (613) to debug clients registered in the debug session; [0024], A debug session is a semi-permanent interactive information interchange between at least one debug client and a debug server for the purposes of a debugging a particular debuggee; [0028], The server (102) in the example of FIG. 1, may support simultaneous execution of several different debug server applications [first and second multiplayer debugger sessions]; [0058], The debug administrator (114) then registers the requesting debug client (402) in the debug session and assigns the requesting debug client (402) a client identifier (420) unique to the debug session. After assignment a client identifier may be used in message passing among the debug clients, debug server, and debug administrator to identify a recipient of a message, to identify a sender of a message, and so on; see also [0034]; Examiner note: as illustrated in the portions quoted above, Bates discloses distributing evaluation results [updated program state] only to clients registered [subscribed] to that specific debug session and not to any other debug clients, i.e., wherein the updated program state is isolated from the second plurality of client devices in accordance with the first plurality of client devices having subscribed to the first multiplayer debugger session failing to include the second plurality of client devices, as claimed.), and
wherein the first multiplayer debugger session and the second multiplayer debugger session are active at a same time (e.g., Fig. 1 and associated text, e.g., [0028], simultaneous execution of several different debug server applications, each of which may debug separate debuggees.).
Although Bates discloses first and second debugger sessions for debugging separate computer programs (see above), it does not appear to disclose that the debug sessions are both for a computer program. However, this is taught in analogous art, Garcia (e.g., Fig. 1, particularly, e.g., col. 3:33-49, the back-end server may run … multiple instances of the same application, in multiple sessions for one or more clients.).
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 debugging invention of Bates with the debugger manager invention of Garcia, such that debugging sessions are for an instance of the same program, because simultaneously debugging instances of the same program would speed up debugging efforts for that program.
Although Bates discloses a first debugger and a second debugger (see above), it does not appear to disclose instance of a debugger module … instance of the debugger module … instance. However, this is taught in analogous art, Zinkovsky (e.g., Fig. 1, particularly, Non-invasive Debugger 115 [debugger module] and Non-Invasive Debugger 116 [debugger instances of the debug module] along with associated text, e.g., [0020], server process 118 executing on the server computer 102 can include one or more … sessions such as user session 1 104, user session 2 106. . . user session n 108 in which an instance of the cooperative, non-invasive, non-blocking debugger (e.g., debugger instance 116) is executing. Each user session … supports or cooperates with the cooperative, non-invasive, non-blocking debugger [debugger module] and an instance of the cooperative, non-invasive, non-blocking debugger 116 [instances of the debugger module].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Bates with the debugger invention of Zinkovsky, such that debuggers are provided in sessions as an instance of a debugger module, because “Users need to be able to debug their code instances without having any impact on each other or on anyone else being served by the process in any way,” as suggested by Zinkovsky (see [0011]).
With respect to claim 15, Bates discloses A method (e.g., [0005], Methods … for collaborative software debugging) comprising:
creating a first multiplayer debugger session and a second multiplayer debugger session ,
wherein the first multiplayer debugger session comprises a first debugger multiplexer instance and a first debugger , and supports a first plurality of client devices in accordance with the first plurality of client devices having subscribed to the first multiplayer debugger session (e.g., Figs. 1, 4, and 9 and associated text, e.g., [0030], registering [subscribed] and unregistering clients in a debug session; [0031], From the perspective of the back-end debugger (118), the debugger is controlled by a single source, the message router (116) [first debugger multiplexer instance]; [0032], receiving, by the debug server (102) from the debug clients (104) [first plurality of client devices] asynchronously during a debug session of the debuggee (120), a plurality of application-level messages (126); routing, by the message router (116) … the application-level messages (126) among the debug clients, the debug administrator, and the back-end debugger [first debugger] … the message router (116) provides distributed control of the back-end debugger (118) to the debug clients (104) with the application-level messages (126) routed to the back-end debugger (118).), and
wherein the second multiplayer debugger session comprises a second debugger multiplexer instance and a second debugger , and supports a second plurality of client devices in accordance with the second plurality of client devices having subscribed to the second multiplayer debugger session (Id., particularly, [0030], registering [subscribed] and unregistering clients in a debug session; [0028], The server (102) in the example of FIG. 1, may support simultaneous execution of several different [first and second] debug server applications, each of which may debug separate debuggees; [0029], collaborative debug server application (130) also includes a debug administrator (114), a message router (116), a back-end debugger (118), and a debuggee (120); [0032], the message router (116) provides distributed control of the back-end debugger (118) to the debug clients (104) with the application-level messages (126) routed to the back-end debugger (118).);
receiving, from a first client device of the first plurality of client devices, a debugger operation for the first multiplayer debugger session (e.g., Figs. 1-3, 7, and 9 along with associated text, e.g., [0071], generating, by a requesting debug client (702), a request (706) to issue a command (718) [debugger operation] to the back-end debugger (118), sending the request (706) to the debug server (102), and receiving the request (722) by the message router (116); [0073], executing the command (718) causes the back-end debugger (118) to initiate execution (719) of the debuggee, for debugging purposes, monitor the execution of the debuggee, and gather results (720).);
transmitting the debugger operation to the first debugger (e.g., Figs. 1-3, 7, and 9 and associated text, e.g., [0073], The method of FIG. 7 also includes routing the request (706) to the back-end debugger (118) by issuing the command (718) to the back-end debugger (118) by the message router (116).);
determining, by the first debugger multiplexer instance, an updated program state in accordance with the debugger operation (e.g., Figs. 1-3, 7, and 9 along with associated text, e.g., [0074], After executing the issued command in the example of FIG. 7, the back-end debugger (118) returns to the message router (116) results (720) of the execution of the issued command, the message router [debugger multiplexer instance] receives the results (718) [updated program state in accordance with the debugger operation]. The nature of the results (720) of the execution depend upon the type of command (718) executed by the back-end debugger. A command to evaluate a variable for example, may return as little as an integer, while a command to step into execution of the debuggee may return significantly more information--variable values, register values, memory values, line number, source code file name, and thread number and so on. The results (720), once received by the requesting client (702) may be used to control the client-specific GUI, changing the information displayed on the GUI.); and
transmitting, by the first debugger multiplexer instance, the updated program state to a remainder of the first plurality of client devices (e.g., Figs. 1-3, 6, 7, 9, and 11-12 along with associated text, e.g., [0040], `Public` evaluation by contrast means that the results of the evaluation [updated program state] may be presented to other clients -- a predefined group, one or more clients selected in real-time during the selection of the variable to evaluation, or all clients registered in the debug session [remainder of the plurality of client devices]; [0067], generating, by a requesting debug client (602), a request (606) to distribute data (613) to debug clients registered in the debug session; [0069], sending, by the message router (116) [first debugger multiplexer instance] to debug clients identified as intended recipients (602) in the request (606) to distribute data, a reply (622) … and receiving, by the debug clients identified as intended recipients (602), the reply (622) … having … a payload (632) included in the request (606) to distribute data; [0099], payload that includes the results of the evaluation of the variable.),
wherein the updated program state is isolated from the second plurality of client devices in accordance with the first plurality of client devices having subscribed to the first multiplayer debugger session failing to include the second plurality of client devices (Id., particularly, [0040], `Public` evaluation by contrast means that the results of the evaluation [updated program state] may be presented to … all clients registered [subscribed] in the debug session, and [0067], generating, by a requesting debug client (602), a request (606) to distribute data (613) to debug clients registered in the debug session; [0024], A debug session is a semi-permanent interactive information interchange between at least one debug client and a debug server for the purposes of a debugging a particular debuggee; [0028], The server (102) in the example of FIG. 1, may support simultaneous execution of several different debug server applications [first and second multiplayer debugger sessions]; [0058], The debug administrator (114) then registers the requesting debug client (402) in the debug session and assigns the requesting debug client (402) a client identifier (420) unique to the debug session. After assignment a client identifier may be used in message passing among the debug clients, debug server, and debug administrator to identify a recipient of a message, to identify a sender of a message, and so on; see also [0034]; Examiner note: as illustrated in the portions quoted above, Bates discloses distributing evaluation results [updated program state] only to clients registered [subscribed] to that specific debug session and not to any other debug clients, i.e., wherein the updated program state is isolated from the second plurality of client devices in accordance with the first plurality of client devices having subscribed to the first multiplayer debugger session failing to include the second plurality of client devices, as claimed.), and
wherein the first multiplayer debugger session and the second multiplayer debugger session are active at a same time (e.g., Fig. 1 and associated text, e.g., [0028], simultaneous execution of several different debug server applications, each of which may debug separate debuggees.).
Although Bates discloses first and second debugger sessions for debugging separate computer programs (see above), it does not appear to disclose that the debug sessions are both for a computer program. However, this is taught in analogous art, Garcia (e.g., Fig. 1, particularly, e.g., col. 3:33-49, the back-end server may run … multiple instances of the same application, in multiple sessions for one or more clients.).
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 debugging invention of Bates with the debugger manager invention of Garcia, such that debugging sessions are for an instance of the same program, because simultaneously debugging instances of the same program would speed up debugging efforts for that program.
Although Bates discloses a first debugger and a second debugger (see above), it does not appear to disclose instance of a debugger module … instance of the debugger module … instance. However, this is taught in analogous art, Zinkovsky (e.g., Fig. 1, particularly, Non-invasive Debugger 115 [debugger module] and Non-Invasive Debugger 116 [debugger instances of the debug module] along with associated text, e.g., [0020], server process 118 executing on the server computer 102 can include one or more … sessions such as user session 1 104, user session 2 106. . . user session n 108 in which an instance of the cooperative, non-invasive, non-blocking debugger (e.g., debugger instance 116) is executing. Each user session … supports or cooperates with the cooperative, non-invasive, non-blocking debugger [debugger module] and an instance of the cooperative, non-invasive, non-blocking debugger 116 [instances of the debugger module].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Bates with the debugger invention of Zinkovsky, such that debuggers are provided in sessions as an instance of a debugger module, because “Users need to be able to debug their code instances without having any impact on each other or on anyone else being served by the process in any way,” as suggested by Zinkovsky (see [0011]).
With respect to claims 2, 9, and 16, Bates also discloses wherein the first debugger multiplexer instance is further configured to cause a presentation of a user interface corresponding to the first multiplayer debugger session to update in accordance with the updated program state (e.g., Figs. 1-3 and associated text, e.g., [0024], In the example of FIG. 1, the client-specific GUI (124) is a client-specific display of a debug session of the debuggee; [0031], the back-end debugger (118) is controlled indirectly by multiple clients through use of an intermediary--the message router (116) [first debugger multiplexer instance]. From the perspective of the back-end debugger (118), the debugger is controlled by a single source, the message router (116); [0033], The back-end debugger (118), responsive to the issued command, may then evaluate the variable and provide the results of the evaluation to the message router (116) [first debugger multiplexer instance]. Returning client-specific debug results in such embodiments may include returning the results of the evaluation to the requesting debug client (106); [0042], upon a mouse-over of the variable named `argument,` a request is sent, by the debug client presenting the GUI (124) of FIG. 2, to a debug server to issue a command to a back-end debugger to evaluate the variable, the debug client receives results of the evaluation, and a pop-up text box (228) is displayed that includes the results [update in accordance with the updated program state]; [0053], displaying (326), by each debug client in the client-specific GUI (124) on a display device (180), the client-specific debug results (322).).
With respect to claim 3, Garcia also discloses a debugger adapter configured to abstract the debugger operation, wherein the debugger adapter provides multilanguage functionality based on an abstraction of the debugger operation (e.g., Figs. 1-2 and associated text, e.g., col. 3:5-32, The system 100 may include a front-end adapter 120 that translates browser-specific representations of debug requests and associated data into a generic representation [abstract the debugger operation] … The front-end plugin 126 may process the received debug requests, e.g., to enter them in a generic format; col. 3:65-col. 4:18, converting the request into a language and format that is understandable by the back-end debugger … rendering the debug-request service 132 suitable for use with multiple back-end debuggers 106 for which back-end plugins 134 are available … Further plugins 134 may be provided for applications written, for example, in Java, C, or any other suitable programming language.).
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 debugging invention of Bates with the debugger manager invention of Garcia, such that multilanguage functionality is provided, for the same reasons set forth above and also because it addresses the problem that debugging web applications “is often cumbersome and takes up valuable developer time” by “allowing an application developer to debug web applications without leaving the browser,” as suggested by Garcia (see col. 1:32-32 and col. 2:15-16.).
With respect to claim 5, Bates also discloses wherein the first debugger multiplexer instance is further configured to transmit the updated program state in accordance with a determination that the debugger operation satisfies a share criteria (e.g., Figs. 1-4, 6-7, and 11-12 along with associated text, e.g., [0032], routing, by the message router (116) [the first debugger multiplexer instance] in accordance with an application-level message passing protocol, the application-level messages (126) among the debug clients; [0097], presenting (1204), to the user of the particular debug client through the client-specific GUI, an option to publish the results of the evaluation of the variable to other debug clients; [0098], receiving (1204) … an indication to publish the results of the evaluation of the variable to other debug clients [in accordance with a determination that the debugger operation satisfies a share criteria]; [0099], The reply to the distribute request may be implemented as an application-level message having a REQUEST REPLY message type and a payload that includes the results of the evaluation of the variable [transmit the updated program state].).
With respect to claim 6, Bates also discloses wherein the first debugger multiplexer is further configured to: receive, from the first client device, a second debugger operation, transmit the second debugger operation to , determine that the second debugger operation does not satisfy a share criterion, and in accordance with a determination that the second debugger operation does not satisfy the share criterion, cause a debugger view to be updated at the first client device in accordance with the second debugger operation (e.g., Figs. 1-4, 6-7, and 11-12 along with associated text, e.g., [0040], In the GUI (124) of FIG. 2, the Collaborate menu may, for example, include a menu item for private or public variable evaluation. Selecting the private menu item may invoke a popup or other GUI window from which a variable or variables may be selected for private evaluation by a user [determine that the second debugger operation does not satisfy a share criterion]. `Private` as the term is used here means that the results of the evaluation are returned only to the client requesting the evaluation; [0042], debug client receives results of the evaluation, and a pop-up text box (228) is displayed that includes the results.) and Zinkovsky teaches the debugger module (e.g., Fig. 1, particularly, Non-invasive Debugger 115 [debugger module] and Non-Invasive Debugger 116 [debugger instances of the debug module] along with associated text, e.g., [0020], server process 118 executing on the server computer 102 can include one or more … sessions such as user session 1 104, user session 2 106. . . user session n 108 in which an instance of the cooperative, non-invasive, non-blocking debugger (e.g., debugger instance 116) is executing. Each user session … supports or cooperates with the cooperative, non-invasive, non-blocking debugger [debugger module] and an instance of the cooperative, non-invasive, non-blocking debugger 116.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the debugger invention of Zinkovsky for the same reason set forth above.
With respect to claim 11, Bates also discloses receive, from the first client device, a second debugger operation, transmit the second debugger operation to , determine that the second debugger operation does not satisfy a share criterion, and in accordance with a determination that the second debugger operation does not satisfy the share criterion, cause a debugger view to be updated at the first client device in accordance with the second debugger operation (e.g., Figs. 1-4, 6-7, and 11-12 along with associated text, e.g., [0040], In the GUI (124) of FIG. 2, the Collaborate menu may, for example, include a menu item for private or public variable evaluation. Selecting the private menu item may invoke a popup or other GUI window from which a variable or variables may be selected for private evaluation by a user [determine that the second debugger operation does not satisfy a share criterion]. `Private` as the term is used here means that the results of the evaluation are returned only to the client requesting the evaluation; [0042], debug client receives results of the evaluation, and a pop-up text box (228) is displayed that includes the results.) and Zinkovsky teaches the debugger module (e.g., Fig. 1, particularly, Non-invasive Debugger 115 [debugger module] and Non-Invasive Debugger 116 [debugger instances of the debug module] along with associated text, e.g., [0020], server process 118 executing on the server computer 102 can include one or more … sessions such as user session 1 104, user session 2 106. . . user session n 108 in which an instance of the cooperative, non-invasive, non-blocking debugger (e.g., debugger instance 116) is executing. Each user session … supports or cooperates with the cooperative, non-invasive, non-blocking debugger [debugger module] and an instance of the cooperative, non-invasive, non-blocking debugger 116.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the debugger invention of Zinkovsky for the same reason set forth above.
With respect to claim 14, Bates also discloses provide a user selectable option to a new client device to join the first multiplayer debugger session or the second multiplayer debugger session for the computer program (e.g., Figs. 1-3, 4, and 11-12 along with associated text, e.g., [0048], detecting (304), by each debug client (104), user (101 on FIG. 1) input (306) through the client-specific GUI (124). Detecting (304), user input (306) through the client-specific GUI (124) may be carried out in various ways including … detecting selection of drop-down menu items, detecting mouse-clicks on GUI items, such as GUI buttons, and so on; [0049], generating (308), by each debug client (104) in dependence upon the detected user input (306) [user selectable option], one or more application-level messages (310); [0055], FIG. 4 depicts a debug client [new client] -- the requesting client (402) of FIG. 4 -- generating (308 on FIG. 3) one or more application-level messages (310 on FIG. 3). In the example of FIG. 4, the requesting client (402) generates a request (406) to join the debug session [join the first multiplayer debugger session].).
With respect to claim 18, Bates also discloses receiving, from the first client device, a second debugger operation, transmitting the second debugger operation to the first debugger , determining that the second debugger operation does not satisfy a share criterion, and in accordance with the determination that the second debugger operation does not satisfy the share criterion, causing a debugger view to be updated at the first client device in accordance with the second debugger operation (e.g., Figs. 1-4, 6-7, and 11-12 along with associated text, e.g., [0040], In the GUI (124) of FIG. 2, the Collaborate menu may, for example, include a menu item for private or public variable evaluation. Selecting the private menu item may invoke a popup or other GUI window from which a variable or variables may be selected for private evaluation by a user [determine that the second debugger operation does not satisfy a share criterion]. `Private` as the term is used here means that the results of the evaluation are returned only to the client requesting the evaluation; [0042], debug client receives results of the evaluation, and a pop-up text box (228) is displayed that includes the results.) and Zinkovsky teaches instance of the debugger module (e.g., Fig. 1, particularly, Non-invasive Debugger 115 [debugger module] and Non-Invasive Debugger 116 [debugger instances of the debug module] along with associated text, e.g., [0020], server process 118 executing on the server computer 102 can include one or more … sessions such as user session 1 104, user session 2 106. . . user session n 108 in which an instance of the cooperative, non-invasive, non-blocking debugger (e.g., debugger instance 116) is executing. Each user session … supports or cooperates with the cooperative, non-invasive, non-blocking debugger [debugger module] and an instance of the cooperative, non-invasive, non-blocking debugger 116.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the debugger invention of Zinkovsky for the same reason set forth above.
With respect to claims 21 and 22, Bates also discloses transmit the updated program state in accordance with a determination that the debugger operation satisfies a share criterion (e.g., Figs. 1-4, 6-7, and 11-12 along with associated text, e.g., [0040], In the GUI (124) of FIG. 2, the Collaborate menu may, for example, include a menu item for private or public variable evaluation … ‘Public’ evaluation [debugger operation satisfies a share criterion] by contrast means that the results of the evaluation may be presented to other clients -- a predefined group, one or more clients selected in real-time during the selection of the variable to evaluation, or all clients registered in the debug session.).
Claims 4, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Bates in view of Garcia, and Zinkovsky, as applied to claims 1, 8, and 15 above, and further in view of Chandran et al. (US 20120317443, hereinafter Chandran).
With respect to claim 4, Bates also discloses wherein the first debugger multiplexer instance is further configured to: transmit the updated program state to the remainder of the first plurality of client devices based on an identification the first multiplayer debugger session among the plurality of multiplayer debugger sessions (e.g., Figs. 1-4, 6, 7, 9, and 11-12 along with associated text, e.g., [0028], simultaneous execution of several different debug server applications [plurality of multiplayer debugger sessions], each of which may debug separate debuggees; [0040], `Public` evaluation by contrast means that the results of the evaluation [updated program state] may be presented to other clients -- a predefined group, one or more clients selected in real-time during the selection of the variable to evaluation, or all clients registered in the debug session [remainder of the first plurality of client devices]; [0069], sending, by the message router (116) [first debugger multiplexer instance] to debug clients identified as intended recipients (602) in the request (606) to distribute data, a reply (622); [0058], a client identifier (420) unique to the debug session. After assignment a client identifier may be used in message passing among the debug clients, debug server, and debug administrator to identify a recipient of a message [based on an identification].).
Although Bates discloses transmitting the updated program state to the remainder of the clients of the first multiplayer debugger session based on an identification (see above), it does not appear to disclose that the identification is of the first multiplayer debugger session. However, in analogous art, Chandran teaches transmitting based on an identification of a debugger session (e.g., Figs. 1-2 and 6 along with associated text, e.g., [0071], The method 600 may further involve associating 606 the first debugging session 220 with a unique identifier that allows the first debugging session 220 to be distinguished from other debugging sessions. The method 600 may also involve associating 608 commands issued by the first debugging session 220 with the unique identifier. This may allow the debugging session apparatus 106 to ensure that the results of the commands are provided to the correct debugging session.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Bates with the invention of Chandran, such that the updated program state is transmitted to all session clients based on a single debugger session ID, because using one session identifier would be simpler and more efficient than using the multiple client identifiers disclosed in Bates.
With respect to claim 10, Bates also discloses transmit the updated program state to the remainder of the first plurality of client devices based on an identification the first multiplayer debugger session (e.g., Figs. 1-4, 6, 7, 9, and 11-12 along with associated text, e.g., [0040], `Public` evaluation by contrast means that the results of the evaluation [updated program state] may be presented to other clients -- a predefined group, one or more clients selected in real-time during the selection of the variable to evaluation, or all clients registered in the debug session [remainder of the first plurality of client devices]; [0069], sending, by the message router (116) [first debugger multiplexer instance] to debug clients identified as intended recipients (602) in the request (606) to distribute data, a reply (622); [0058], a client identifier (420) unique to the debug session. After assignment a client identifier may be used in message passing among the debug clients, debug server, and debug administrator to identify a recipient of a message [based on an identification].).
Although Bates discloses the first multiplayer debugger session and transmitting the updated program state to the remainder of the clients of the first multiplayer debugger session based on an identification (see above), it does not appear to disclose that the identification is of the first multiplayer debugger session. However, in analogous art, Chandran teaches transmitting based on an identification of a debugger session (e.g., Figs. 1-2 and 6 along with associated text, e.g., [0071], The method 600 may further involve associating 606 the first debugging session 220 with a unique identifier that allows the first debugging session 220 to be distinguished from other debugging sessions. The method 600 may also involve associating 608 commands issued by the first debugging session 220 with the unique identifier. This may allow the debugging session apparatus 106 to ensure that the results of the commands are provided to the correct debugging session.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Bates with the invention of Chandran, such that the updated program state is transmitted to all session clients based on a single debugger session ID, because using one session identifier would be simpler and more efficient than using the multiple client identifiers disclosed in Bates.
With respect to claim 17, Bates also discloses transmitting the updated program state to the remainder of the first plurality of client devices based on the updated program state being associated with an identification the first multiplayer debugger session (e.g., Figs. 1-4, 6, 7, 9, and 11-12 along with associated text, e.g., [0040], `Public` evaluation by contrast means that the results of the evaluation [updated program state] may be presented to other clients -- a predefined group, one or more clients selected in real-time during the selection of the variable to evaluation, or all clients registered in the debug session [remainder of the first plurality of client devices]; [0069], sending, by the message router (116) [first debugger multiplexer instance] to debug clients identified as intended recipients (602) in the request (606) to distribute data, a reply (622); [0058], a client identifier (420) unique to the debug session. After assignment a client identifier may be used in message passing among the debug clients, debug server, and debug administrator to identify a recipient of a message [based on the updated program state being associated with an identification].).
Although Bates discloses the first multiplayer debugger session and transmitting the updated program state to the remainder of the clients of the first multiplayer debugger session based on the updated program state being associated with an identification (see above), it does not appear to disclose that the identification is of the first multiplayer debugger session. However, in analogous art, Chandran teaches transmitting based on an identification of a debugger session (e.g., Figs. 1-2 and 6 along with associated text, e.g., [0071], The method 600 may further involve associating 606 the first debugging session 220 with a unique identifier that allows the first debugging session 220 to be distinguished from other debugging sessions. The method 600 may also involve associating 608 commands issued by the first debugging session 220 with the unique identifier. This may allow the debugging session apparatus 106 to ensure that the results of the commands are provided to the correct debugging session.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Bates with the invention of Chandran, such that the updated program state is transmitted to all session clients based on the updated program state being associated with a single debugger session ID, because using one session identifier would be simpler and more efficient than using the multiple client identifiers disclosed in Bates.
Claims 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Bates in view of Garcia, and Zinkovsky, as applied to claims 8 and 15 above, and further in view of Somasundaram et al. (US 20180129584, hereinafter Somasundaram).
With respect to claim 13, Bates also discloses wherein the computer readable code to create the second multiplayer debugger session comprises computer readable code to: the first multiplayer debugger session a third multiplayer debugger session (e.g., Fig. 1 and associated text, e.g., [0024], A debug session is a semi-permanent interactive information interchange between at least one debug client and a debug server for the purposes of a debugging a particular debuggee; [0028], The server (102) in the example of FIG. 1, may support simultaneous execution of several different debug server applications, each of which may debug separate debuggees.); and
synchronize state information for the third multiplayer debugger session to one or more additional client devices associated with the third multiplayer debugger session (e.g., Figs. 1-3, 6, 7, 9, and 11-12 along with associated text, e.g., [0040], `Public` evaluation by contrast means that the results of the evaluation may be presented to other clients -- a predefined group, one or more clients selected in real-time during the selection of the variable to evaluation, or all clients registered in the debug session.).
Although Bates discloses a first and third debugger sessions (see above), it does not appear to disclose clone … to generate. However, this is taught by Somasundaram (e.g., Figs. 1 and 4 along with associated text, e.g., [0026], the debugging system 150 can save the ending application state 160 and the corresponding application inputs 120. Additionally, the debugging system 150 can … fork the ending application state 160 and the corresponding application inputs 120; [0054], At step 440, the debugging system resubmits the application inputs corresponding to the debugging session at a web server layer to generate a first restarted session [clone … to generate]. In certain aspects, the debugging system resubmits the application inputs in response to receiving a first request to fork the debugging session. As such, the first request to fork the debugging session enables the first restarted session to be modified without changing the context of the initial debugging session or affecting other instances of the debugging session.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Bates with the debug session forking invention of Somasundaram because it allows users to “access the debugging session after the initial user has killed the debugging session” and “enables the first restarted session to be modified without changing the context of the initial debugging session or affecting other instances of the debugging session,” as suggested by Somasundaram (see [0053]-[0054]).
With respect to claim 20, Bates also discloses the first multiplayer debugger session a third multiplayer debugger session (e.g., Fig. 1 and associated text, e.g., [0024], A debug session is a semi-permanent interactive information interchange between at least one debug client and a debug server for the purposes of a debugging a particular debuggee; [0028], The server (102) in the example of FIG. 1, may support simultaneous execution of several different debug server applications, each of which may debug separate debuggees.); and
synchronize state information for the third multiplayer debugger session to one or more additional client devices associated with the third multiplayer debugger session (e.g., Figs. 1-3, 6, 7, 9, and 11-12 along with associated text, e.g., [0040], `Public` evaluation by contrast means that the results of the evaluation may be presented to other clients -- a predefined group, one or more clients selected in real-time during the selection of the variable to evaluation, or all clients registered in the debug session.).
Although Bates discloses a first and third debugger sessions (see above), it does not appear to disclose cloning … to generate. However, this is taught by Somasundaram (e.g., Figs. 1 and 4 along with associated text, e.g., [0026], the debugging system 150 can save the ending application state 160 and the corresponding application inputs 120. Additionally, the debugging system 150 can … fork the ending application state 160 and the corresponding application inputs 120; [0054], At step 440, the debugging system resubmits the application inputs corresponding to the debugging session at a web server layer to generate a first restarted session [cloning … to generate]. In certain aspects, the debugging system resubmits the application inputs in response to receiving a first request to fork the debugging session. As such, the first request to fork the debugging session enables the first restarted session to be modified without changing the context of the initial debugging session or affecting other instances of the debugging session.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Bates with the debug session forking invention of Somasundaram because it allows users to “access the debugging session after the initial user has killed the debugging session” and “enables the first restarted session to be modified without changing the context of the initial debugging session or affecting other instances of the debugging session,” as suggested by Somasundaram (see [0053]-[0054]).
Prior Art Arguments – Rejections
Applicant’s arguments filed on June 4, 2026, with respect to the prior art rejections have been fully considered by Examiner, but they are not persuasive, as follows:
With respect to claims 1, 8, and 15, Applicant first argues, with emphasis added,
“With respect to the debugger session manager, the Examiner concedes the feature is not disclosed by Bates and instead relies on Garcia … Garcia does not disclose, or even suggest, running two independent debug session constructs, each with its own multiplexer instance and debugger instance, concurrently on the same program while enforcing subscription-based state isolation. Said another way, simply because a user can open multiple instances of a web app on different browser pages, the fact that the connection service 130 manages routing debugger requests so that two open browser-based debugging sessions remain independent, the debug manager 108 still falls short of the claimed debugger session manager because Garcia fails to disclose instantiating an entire debugging session architecture for each session. That is, the debug manager 108 is merely routing communications between one or more front-end debuggers and one or more back-end debugger instances, but Garcia fails to disclose or otherwise render obvious that the debug manager instantiates two independent session constructs, each with its own multiplexer instance and debugger instance, concurrently on the same program, as in the claims, and as shown in example FIG. 3 here, as session A 330A and session B 330B for clarity.”1
However, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). As indicated in the Non-Final Office action at p. 10, Bates discloses multiple debug server modules that cooperatively manage sessions for debugging applications but does not disclose a singular “debugger session manager” or that the applications being debugged in the different sessions are the same computer program. Accordingly, Examiner cited Garcia only for its teaching of (1) implementing the debugger session management functionality as a singular “a debugger session manager” component and (2) multiple debug sessions debugging the same program and not for any of the other features that Applicant argues here, such as “independent debug session constructs, each with its own multiplexer instance”, which is disclosed in Bates, or debugger “instance”, which is taught by Zinkovsky. Examiner further directs Applicant’s attention to the portions of Garcia cited in the Non-Final Office action as teaching a singular debugger sessions manager and multiple sessions for debugging instances of the same program. Specifically, Fig. 1, which depicts “Debug Manager 108” consisting of “Connection Service 130” and “Debug-Request Service 132”, col. 3:33-49, “The debug manager 108 provides two distinct services (among other functionality): a connection service 130 and a debug-request service 132 … their functionality is provided in an integrated single module”, and col. 3:33-49, “the back-end server may run … multiple instances of the same application, in multiple sessions for one or more clients”.
Applicant next describes the claim term “updated program state” and does not argue that Bates fails to disclose an “updated program state”2. Rather Applicant proceeds to argue that “Examiner fails to show isolating the updated program state from the second plurality of client devices, as Bates is not concerned with multiple sessions”.3 Examiner disagrees with this characterization of Bates, which states “A debug session is a semi-permanent interactive information interchange between at least one debug client and a debug server for the purposes of a debugging a particular debuggee”4 (emphasis added) and “The server (102) in the example of FIG. 1, may support simultaneous execution of several different debug server applications, each of which may debug separate debuggees”5 (emphasis added). In other words, Bates discloses simultaneous debug sessions, each session for debugging a separate debuggee. Thus, contrary to the assertion of Applicant, Bates is “concerned with multiple debug sessions”.
Applicant further argues that “Bates is silent regarding any isolation of state
information from other client devices in a different session managed by the debugger session
manager”6. In response, Examiner first notes that, as indicated above, it was Garcia that discloses a singular “debugger session manager. Examiner further notes that “During patent examination, the pending claims must be ‘given their broadest reasonable interpretation consistent with the specification’” (see MPEP § 2111) and “Under a broadest reasonable interpretation (BRI), words of the claim must be given their plain meaning, unless such meaning is inconsistent with the specification … the best source for determining the meaning of a claim term is the specification - the greatest clarity is obtained when the specification serves as a glossary for the claim terms” (see MPEP § 2111.01(I)) (emphasis added). The most relevant portions of Applicant’s specification state “the new state information is synchronized to other clients in the debug session”7 (emphasis added), “a user can cooperatively debug the program within whichever session the user is subscribed to”8, and “a visual indication may be presented in a consistent manner on each client in the session to indicate a processing state of the program. The visual indication may be presented in a consistent manner to indicate state information for the program”9. Thus, in light of Applicant’s specification, the broadest reasonable interpretation of “the program state is isolated from the second plurality of client devices in accordance with the first plurality of client devices having subscribed to the first multiplayer debugger session failing to include the second plurality of client devices” is that the updated state information is distributed to clients subscribed to the debug session and not to clients who are not subscribed to the session. This is precisely how Bates operates, which Applicant appears to acknowledge by stating in the Remarks that Bates discloses “the information being transmitted to members who are registered in the debugging session”10.
More specifically, Bates states that (1) “A debug session is a semi-permanent interactive information interchange between at least one debug client and a debug server for the purposes of a debugging a particular debuggee”11 and that there is “simultaneous execution of several different debug server applications, each of which may debug separate debuggees”12; (2) “A command to evaluate a variable for example, may return as little as an integer, while a command to step into execution of the debuggee may return significantly more information--variable values, register values, memory values, line number, source code file name, and thread number and so on”13; and (3) “the results of the evaluation may be presented to … all clients registered in the debug session”14 and that data is distributed “to debug clients registered in the debug session”15. In other words, Bates discloses (1) multiple debug sessions, each with multiple debug clients collaboratively debugging a specific debuggee [program] and (2) distributing evaluation information, which includes debuggee values after executing a command [updated program state information], only to debug clients registered [subscribed] to the session and not to any other debug clients. The invention of Bates therefore falls within the argued claim limitation’s broadest reasonable interpretation, namely that the updated state information is distributed to clients subscribed to the debug session and not to clients who are not subscribed to the session16.
Applicant further argues “The references, both separately and in combination, fail to disclose or suggest two debugging sessions managed by a single debugger manager, each including a multiplexer instance, debugger instance, and set of subscribers, where both sessions are performing operations on a same program.”17 In response, Examiner directs Applicant’s attention to the preceding paragraphs in this section, which demonstrate that Bates discloses managing multiple debugging sessions with a debugger and subscribers, and that Garcia discloses a single debugger manager that manages sessions for debugging the same program. Furthermore, Bates also discloses that each session has a message router, i.e., multiplexer instance.18 Regarding a debugger “instance”, Examiner notes that Zinkovsky was cited as teaching “instance” and not Bates or Garcia.
Lastly, Applicant argues “Zinkovsky fails to cure the deficiencies of Bates and Garcia. The Examiner relies on Zinkovsky as disclosing the instances of the debugger module ... Zinkovsky does not disclose multiple debugging sessions for a same program. Zinkovsky also fails to disclose multiple sessions each hosting a plurality of client devices. Accordingly, the combination of Bates, Garacia, and Zinkovsky still fail to disclose, at least, the claimed debugger session manager because even the combination of the references fail to disclose a debugger session manager that creates multiple sessions, each session including a debugger multiplexer, and each session supporting a plurality of client devices.”19 In response, Examiner again notes that one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. Zinkovsky was only cited as teaching “debugger module”, “instance of the debugger module”, and debugger “instance”. Zinkovsky was not cited as teaching “multiple debugging sessions for a same program”, “multiple sessions each hosting a plurality of client devices”, or “a debugger session manager that creates multiple sessions, each session including a debugger multiplexer, and each session supporting a plurality of client devices” as argued here by Applicant. As detailed at length above, these features are disclosed by Bates and Garcia.
For the reasons set forth above, Applicant’s arguments are not persuasive.
With respect to claims 13 and 20, Applicant asserts that “Claim 13 recites, in part: clone the first multiplayer debugger session to generate a third multiplayer debugger session. With respect to the feature identified above the Examiner relies on Somasundaram … When multiple users request access to a single instance of the initial debugging session, the application inputs of the initial debugging session can be resubmitted to achieve the ending application state without necessarily multiplexing application inputs … Thus, the multiplexer [of Somasundaram] is used for managing non-shared debugging requests”20 (emphasis added). However, as noted above, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Here, Examiner only relied on Somasundaram for its teaching of “clone” a debug session “to generate” another debug session. Furthermore, the portion cited by Applicant recites “without necessarily multiplexing application inputs” and thus does not preclude multiplexing. In fact, the earlier portion of the same paragraph, which directly relates to the portion cited in the Non-Final Office acction, recites “The application inputs can be multiplexed by the debugging system at the web server to be provided to a first software container that corresponds to the first restarted session.” However, even assuming that the requests of Somasundaram are “non-shared”, it would not be relevant because Somasundaram was only cited for its teaching of “clone” a debug session “to generate” another debug session, as indicated above.
Applicant further asserts “Somasundaram further describes with respect to block 450, generating a second restarted session based on a request to fork the debugging session. This allows further debugging of the forked version, while maintaining the state of the original version. Accordingly, in Somasundaram the purpose of forking is explicitly to preserve the original session's state unchanged. This is architecturally contrary to the claimed scenario in which a third session is created concurrently alongside the first and second sessions, all potentially active at the same time, each supporting its own subscriber set”21 (emphasis added). In response, it is noted that the feature upon which Applicant relies (“a third session is created concurrently alongside the first and second sessions, all potentially active at the same time, each supporting its own subscriber set”) is not recited in the rejected claims 13 and 20. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Thus, even assuming that the invention of Somasundaram is “architecturally contrary” to “a third session is created concurrently alongside the first and second sessions, all potentially active at the same time, each supporting its own subscriber set”, which Examiner does not concede, it would be irrelevant because the claim does not require that “a third session is created concurrently alongside the first and second sessions, all potentially active at the same time, each supporting its own subscriber set”. Examiner further notes that it is not entirely clear what Applicant means by “architecturally contrary” or what significance this would have even if accurate. However, such considerations are ultimately immaterial as the claim does not require that “a third session is created concurrently alongside the first and second sessions, all potentially active at the same time, each supporting its own subscriber set”.
For the reasons set forth above, Applicant’s arguments are unpersuasive.
With respect to all remaining dependent claims, Applicant references the arguments made with respect to claims 1, 8, and 15, which are unpersuasive for the reasons set forth above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Specifically, Bani-Salameh et al. “Integrating Collaborative Program Development and Debugging within a Virtual Environment” discloses a real-time collaborative debugging session that can be started by any developer as a private IDE activity and subsequently shared when it is determined that assistance is needed.
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 STEPHEN DAVID BERMAN whose telephone number is (571) 272-7206. The examiner can normally be reached M-F, 9-6 Eastern.
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, Hyung S. Sough can be reached on 571-272-6799. 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.
/STEPHEN D BERMAN/Examiner, Art Unit 2192
1 See Remarks at pp. 12-13.
2 See Remarks at p. 13.
3 See Remarks at p. 13.
4 See Bates at para. [0024].
5 See Bates at para. [0030].
6 See Remarks at p. 14.
7 See Applicant’s specification at [0023].
8 See Applicant’s specification at [0033].
9 See Applicant’s specification at [0036]
10 See Remarks at p. 13.
11 See Bates at [0024].
12 See Bates at [0028].
13 See Bates at [0074].
14 See Bates at [0040].
15 See Bates at [0067].
16 See the previous paragraph for the determination of the broadest reasonable interpretation of the limitation as issue.
17 See Remarks at p. 13.
18 See Bates at [0031] and the Claim Rejections – 35 USC § 103 section above for details.
19 See Remarks at p. 14.
20 See Remarks at p. 15.
21 See Remarks at p. 16.
Prosecution Insights