DETAILED ACTION
This Action is a response to the filing received 27 June 2024. Claims 1-28 were originally presented for examination. In a Preliminary Amendment filed 27 June 2024, claims 4-7, 13-18 and 20 were amended, claims 21-28 were canceled, and no claims were newly added. Claims 1-20 remain pending for examination.
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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 29 July 2025 is being considered by the examiner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. §§ 102 and 103 (or as subject to pre-AIA 35 U.S.C. §§ 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-7, 13 and 17-20 are rejected under 35 U.S.C. § 103 as being unpatentable over Wang et al., U.S. 2024/0045788 A1 (“Wang”) in view of Munafo et al., U.S. 2019/0227908 A1 (“Munafo”).
Regarding claim 1, Wang teaches: receiving a watchpoint configuration command …, wherein the watchpoint configuration command is used to configure a watchpoint, and wherein the watchpoint configuration command at least comprises an address of the watchpoint to be configured and a debugging action to be executed once the watchpoint is triggered (Wang, e.g., ¶58, “a dynamic command and a debugging mode enable instruction are sent … to a target terminal … debugging mode enable instruction containing an address of the main function entry of the User program is sent …” and ¶61, “BIOS guides the User program to start to execute the function pointed by the reset vector … original reset vector points to a newly written reset function in the dynamic command …”);
parsing the watchpoint configuration command to identify the address and the corresponding debugging action (Wang, e.g., ¶59, “User program interrupt vector table is modified. A dynamic command function is called in the BIOS program; in the User program interrupt vector table, a 12 #debug monitoring exception vector is modified to point to a debug monitoring exception service routine compiled in the dynamic command … an address where a breakpoint is to be set is stored in an idle 8 #vector …”); and
setting the watchpoint at a location corresponding to the address, so as to execute the corresponding debugging action once the set watchpoint is triggered during running of the firmware on the IoT device (Wang, e.g., ¶67, “When the user program runs to the set breakpoint and triggers a hardware interrupt, the debug monitoring exception interrupt service routine will be started …”).
Wang does not more particularly teach that the debugging method is implemented by an IoT device being an MCU-based device with firmware running thereon, and receiving the debugging command sent by a debugging server. However, Munafo does teach: A debugging method implemented by an IoT device, the IoT device being an MCU-based device with firmware running thereon (Munafo, e.g., ¶19, “solutions provide various debugging abilities … useful in various debugging use cases, including … manufacturing equipment, embedded devices, and ‘internet of things’ (IoT) devices …” See also, e.g., ¶36, “debugging topology 400 … includes a device 405, such as a … IoT device … Data gathering 410 may include collecting device state data … firmware status … stack trace dump may include logged tracing data information about the execution of one or more executing programs, such as firmware …”), the method comprising the steps of:
[receiving a debug command] sent by a debugging server (Munafo, e.g., ¶32, “debug console 220 and debug server 235 devices …” and ¶34, “various computing platforms are supported … include networked device (IoT) platforms, where remote debugging management and control is possible on such platforms …”) for the purpose of providing a variety of debugging options to a developer of firmware or software in distributed networking environments, to include IoT environments (Munafo, e.g., ¶¶19-30).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for remote software debugging of embedded terminals as taught by Wang to provide that the debugging method is implemented by an IoT device being an MCU-based device with firmware running thereon, and receiving the debugging command sent by a debugging server because the disclosure of Munafo shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for remote debugging and management to provide that the debugging method is implemented by an IoT device being an MCU-based device with firmware running thereon, and receiving the debugging command sent by a debugging server for the purpose of providing a variety of debugging options to a developer of firmware or software in distributed networking environments, to include IoT environments (Munafo, Id.).
Regarding claim 2, the rejection of claim 1 is incorporated, and Wang further teaches: wherein after parsing the watchpoint configuration command to identify the address and the corresponding debugging action, the method further comprises: creating a data structure for identifying a correspondence between the address and the debugging action (Wang, e.g., ¶59, “User program interrupt vector table is modified. A dynamic command function is called in the BIOS program; in the User program interrupt vector table, a 12 #debug monitoring exception vector is modified to point to a debug monitoring exception service routine compiled in the dynamic command … an address where a breakpoint is to be set is stored in an idle 8 #vector …”).
Regarding claim 3, the rejection of claim 2 is incorporated, and Wang further teaches: wherein the step of executing the corresponding debugging action once the set watchpoint is triggered comprises: once the set watchpoint is triggered, identifying the address corresponding to the watchpoint; and looking up the data structure for the debugging action corresponding to the address, and executing the corresponding debugging action (Wang, e.g., ¶59, “User program interrupt vector table is modified. A dynamic command function is called in the BIOS program; in the User program interrupt vector table, a 12 #debug monitoring exception vector is modified to point to a debug monitoring exception service routine compiled in the dynamic command … an address where a breakpoint is to be set is stored in an idle 8 #vector …” See also, e.g., ¶67, “When the user program runs to the set breakpoint and triggers a hardware interrupt, the debug monitoring exception interrupt service routine will be started …”).
Regarding claim 4, the rejection of claim 1 is incorporated, and Wang further teaches: wherein the debugging action is represented by a predefined action function, wherein the action function includes an action descriptor describing one or more actions to be executed (Wang, e.g., ¶59, “User program interrupt vector table is modified. A dynamic command function is called in the BIOS program; in the User program interrupt vector table, a 12 #debug monitoring exception vector is modified to point to a debug monitoring exception service routine compiled in the dynamic command … an address where a breakpoint is to be set is stored in an idle 8 #vector …”).
Regarding claim 5, the rejection of claim 1 is incorporated, and Munafo further teaches: wherein the debugging action is defined by an application executing in the debugging server (Munafo, e.g., ¶36, “debugging topology 400 … includes a device 405, such as a … IoT device … Data gathering 410 may include collecting device state data … firmware status … stack trace dump may include logged tracing data information about the execution of one or more executing programs, such as firmware …”).
Regarding claim 6, the rejection of claim 1 is incorporated, but Wang does not more particularly teach that the debugging action further comprises a parameter that the debugging server is used to pass. However, Munafo does teach: wherein the debugging action further comprises a parameter that the debugging server is used to pass (Munafo, e.g., ¶28, “debug console user may perform debugging procedures by entering plaintext commands … these are encrypted into plaintext network packets and communicated through the debug server 125 to the device under test …” see also, e.g., TABLE 1) for the purpose of providing a variety of debugging options to a developer of firmware or software in distributed networking environments, to include IoT environments (Munafo, e.g., ¶¶19-30).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for remote software debugging of embedded terminals as taught by Wang to provide that the debugging action further comprises a parameter that the debugging server is used to pass because the disclosure of Munafo shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for remote debugging and management to provide that the debugging action further comprises a parameter that the debugging server is used to pass for the purpose of providing a variety of debugging options to a developer of firmware or software in distributed networking environments, to include IoT environments (Munafo, Id.).
Regarding claim 7, the rejection of claim 1 is incorporated, and Wang further teaches: wherein the debugging action further comprises a debugging instruction that changes behavior of the firmware (Wang, e.g., ¶59, “User program interrupt vector table is modified. A dynamic command function is called in the BIOS program; in the User program interrupt vector table, a 12 #debug monitoring exception vector is modified to point to a debug monitoring exception service routine compiled in the dynamic command … an address where a breakpoint is to be set is stored in an idle 8 #vector …” See also, e.g., ¶67, “When the user program runs to the set breakpoint and triggers a hardware interrupt, the debug monitoring exception interrupt service routine will be started …”).
Regarding claim 13, the rejection of claim 1 is incorporated, and Wang further teaches: wherein the watchpoint is an instruction watchpoint or a data watchpoint; wherein the corresponding instruction watchpoint is triggered when an instruction at the address is executed; and the corresponding data watchpoint is triggered when data at the address is accessed (Wang, e.g., ¶59, “User program interrupt vector table is modified. A dynamic command function is called in the BIOS program; in the User program interrupt vector table, a 12 #debug monitoring exception vector is modified to point to a debug monitoring exception service routine compiled in the dynamic command … an address where a breakpoint is to be set is stored in an idle 8 #vector …” See also, e.g., ¶67, “When the user program runs to the set breakpoint and triggers a hardware interrupt, the debug monitoring exception interrupt service routine will be started …”).
Regarding claim 17, the rejection of claim 1 is incorporated, but Wang does not more particularly teach that after executing the debugging action, diagnostic data obtained after executing the debugging action is reported to the debugging server. However, Munafo does teach: wherein after executing the corresponding debugging action, the method further comprises: reporting diagnostic data obtained after executing the corresponding debugging action to the debugging server (Munafo, e.g., ¶29, “debug console may … execute a debugging procedure, such as by sending a request for a memory read and dump through the debug server 125 to the device under test 130. The output of the debugging process or procedure may be communicated back through the debug server 125 to the debug console …”) for the purpose of providing a variety of debugging options to a developer of firmware or software in distributed networking environments, to include IoT environments (Munafo, e.g., ¶¶19-30).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for remote software debugging of embedded terminals as taught by Wang to provide that after executing the debugging action, diagnostic data obtained after executing the debugging action is reported to the debugging server because the disclosure of Munafo shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for remote debugging and management to provide that after executing the debugging action, diagnostic data obtained after executing the debugging action is reported to the debugging server for the purpose of providing a variety of debugging options to a developer of firmware or software in distributed networking environments, to include IoT environments (Munafo, Id.).
Regarding claim 18, the rejection of claim 1 is incorporated, but Wang does not more particularly teach that the step of reporting the diagnostic data to the debugging server is performed asynchronously. However, Munafo does teach: wherein the step of reporting the diagnostic data to the debugging server is performed asynchronously (Munafo, e.g., ¶29, “debug console may … execute a debugging procedure, such as by sending a request for a memory read and dump through the debug server 125 to the device under test 130. The output of the debugging process or procedure may be communicated back through the debug server 125 to the debug console …” See also, e.g., ¶34, “platform include IoT devices 325 running a debug server 330 that allows a debugging engineer to interact with the IoT device 325 …”) for the purpose of providing a variety of debugging options to a developer of firmware or software in distributed networking environments, to include IoT environments (Munafo, e.g., ¶¶19-30).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for remote software debugging of embedded terminals as taught by Wang to provide that the step of reporting the diagnostic data to the debugging server is performed asynchronously because the disclosure of Munafo shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for remote debugging and management to provide that the step of reporting the diagnostic data to the debugging server is performed asynchronously for the purpose of providing a variety of debugging options to a developer of firmware or software in distributed networking environments, to include IoT environments (Munafo, Id.).
Regarding claim 19, Wang teaches: [the debug configuration command is a] watchpoint configuration command … wherein the watchpoint configuration command at least comprises an address of the watchpoint to be configured and a debugging action to be executed once the watchpoint is triggered (Wang, e.g., ¶58, “a dynamic command and a debugging mode enable instruction are sent … to a target terminal … debugging mode enable instruction containing an address of the main function entry of the User program is sent …” and ¶61, “BIOS guides the User program to start to execute the function pointed by the reset vector … original reset vector points to a newly written reset function in the dynamic command …”); and …
parses the watchpoint configuration command to identify the address and the corresponding debugging action (Wang, e.g., ¶59, “User program interrupt vector table is modified. A dynamic command function is called in the BIOS program; in the User program interrupt vector table, a 12 #debug monitoring exception vector is modified to point to a debug monitoring exception service routine compiled in the dynamic command … an address where a breakpoint is to be set is stored in an idle 8 #vector …”),
sets the corresponding watchpoint at the address, and once the set watchpoint is triggered during running of the firmware on the IoT device, executes the corresponding debugging action (Wang, e.g., ¶67, “When the user program runs to the set breakpoint and triggers a hardware interrupt, the debug monitoring exception interrupt service routine will be started …”).
Wang does not more particularly teach that the debugging method is implemented by an IoT device being an MCU-based device with firmware running thereon, and receiving the debugging command generated based on a developer configuration request and sent by a debugging server. However, Munafo does teach: A debugging method for an IoT device, implemented by a debugging server, the IoT device being an MCU-based device with firmware running thereon (Munafo, e.g., ¶19, “solutions provide various debugging abilities … useful in various debugging use cases, including … manufacturing equipment, embedded devices, and ‘internet of things’ (IoT) devices …” See also, e.g., ¶36, “debugging topology 400 … includes a device 405, such as a … IoT device … Data gathering 410 may include collecting device state data … firmware status … stack trace dump may include logged tracing data information about the execution of one or more executing programs, such as firmware …”), wherein the method comprises:
receiving, from a developer, a configuration request for debugging the firmware of the IoT device; generating a [debug] configuration command based on the configuration request, wherein the [debug] configuration command is used to configure a watchpoint (Munafo, e.g., ¶28, “debug console user may perform debugging procedures by entering plaintext commands … these are encrypted into plaintext network packets and communicated through the debug server 125 to the device under test …” see also, e.g., TABLE 1), …
sending the [debug] configuration command to an IoT device, so that after the IoT device receives the [debug] configuration command (Munafo, e.g., ¶28, “debug console user may perform debugging procedures by entering plaintext commands … these are encrypted into plaintext network packets and communicated through the debug server 125 to the device under test …” see also, e.g., TABLE 1) for the purpose of providing a variety of debugging options to a developer of firmware or software in distributed networking environments, to include IoT environments (Munafo, e.g., ¶¶19-30).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for remote software debugging of embedded terminals as taught by Wang to provide that the debugging method is implemented by an IoT device being an MCU-based device with firmware running thereon, and receiving the debugging command generated based on a developer configuration request and sent by a debugging server because the disclosure of Munafo shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for remote debugging and management to provide that the debugging method is implemented by an IoT device being an MCU-based device with firmware running thereon, and receiving the debugging command generated based on a developer configuration request and sent by a debugging server for the purpose of providing a variety of debugging options to a developer of firmware or software in distributed networking environments, to include IoT environments (Munafo, Id.).
Claim 20 is rejected for the reasons given in the rejection of claim 1 above. Examiner notes that with respect to claim 20, Munafo further teaches: An IoT device, comprising a memory and a processor, wherein the memory is configured to store instructions, and the instructions, when executed by the processor (Munafo, e.g., ¶19, “solutions provide various debugging abilities … useful in various debugging use cases, including … manufacturing equipment, embedded devices, and ‘internet of things’ (IoT) devices …” See also, e.g., ¶36, “debugging topology 400 … includes a device 405, such as a … IoT device … Data gathering 410 may include collecting device state data … firmware status … stack trace dump may include logged tracing data information about the execution of one or more executing programs, such as firmware …” See also, e.g., FIG. 12, including IoT device including memory storing instructions), implement steps of: [[[the method of claim 1]]].
Claim 8 is rejected under 35 U.S.C. § 103 as being unpatentable over Wang in view of Munafo, and in further view of Gounares et al., U.S. 2013/0074055 A1 (“Gounares”).
Regarding claim 8, the rejection of claim 7 is incorporated, but Wang in view of Munafo does not more particularly teach that the debugging instruction is a side-effect function. However, Gounares does teach: wherein the debugging instruction is a side-effect function (Gounares, e.g., ¶¶156-157, “static analysis component 628 may analyze the function 610 … classify the function as pure or not pure … Impure functions may have side effects … purity of a function may be determined based on static analysis … through observations of the behavior of the function …”) for the purpose of applying various static and dynamic analysis techniques to determine function behavior, including a determination that a function has side effects impacting function behavior (Gounares, e.g., ¶¶149-162).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for remote software debugging of embedded terminals as taught by Wang in view of Munafo to provide that the debugging instruction is a side-effect function because the disclosure of Gounares shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for static and dynamic code analysis to provide that the debugging instruction is a side-effect function for the purpose of applying various static and dynamic analysis techniques to determine function behavior, including a determination that a function has side effects impacting function behavior (Gounares, Id.).
Claim 9 is rejected under 35 U.S.C. § 103 as being unpatentable over Wang in view of Munafo, and in further view of Gounares and Liu, Haihong, U.S. 2024/0061611 A1 (“Liu”).
Regarding claim 9, the rejection of claim 8 is incorporated, but Wang in view of Munafo and Gounares does not more particularly teach that the side-effect function is persistent and retained across power-cycles of the firmware. However, Liu does teach: wherein the side-effect function is a persistent side-effect function that is retained across power-cycles of the firmware (Liu, e.g., ¶61, “debug logging information may be transferred to persistent storage … to increase available memory resources at the debug log 275-a, persist the debug logging information if the memory system 21 powers down …”) for the purpose of enhancing the efficiency of memory space usage and debug data persistence (Liu, e.g., ¶¶59-66 et seq.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for remote software debugging of embedded terminals as taught by Wang in view of Munafo and Gounares to provide that the side-effect function is persistent and retained across power-cycles of the firmware because the disclosure of Liu shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for remote memory system hardware debugging to provide that the side-effect function is persistent and retained across power-cycles of the firmware for the purpose of enhancing the efficiency of memory space usage and debug data persistence (Liu, Id.).
Claim 10 is rejected under 35 U.S.C. § 103 as being unpatentable over Wang in view of Munafo, and in further view of Case et al., U.S. 2010/0199077 A1 (“Case”).
Regarding claim 10, the rejection of claim 7 is incorporated, but Wang in view of Munafo does not more particularly teach that the debugging action is configured persistently and is retained across reboots. However, Case does teach: wherein the debugging action is configured persistently which is retained across reboots (Case, e.g., ¶46, “access to the debug interface 116 can persist across soft resets, the customer can configure the IC device 116 for temporary access to the debug interface 116 and then institute a soft reset to allow the customer to monitor an entire ‘normal’ boot sequence …”) for the purpose of persisting debug data and access validation information across one or more soft resets, facilitating the debugging and monitoring of boot processes among others (Case, e.g., ¶¶43-49).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for remote software debugging of embedded terminals as taught by Wang in view of Munafo to provide that the debugging action is configured persistently and is retained across reboots because the disclosure of Case shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for IC device debugging and authentication to provide that the debugging action is configured persistently and is retained across reboots for the purpose of persisting debug data and access validation information across one or more soft resets, facilitating the debugging and monitoring of boot processes among others (Case, Id.).
Claims 11-12 and 14 are rejected under 35 U.S.C. § 103 as being unpatentable over Wang in view of Munafo, and in further view of Smiljanic et al., U.S. 2019/0138430 A1 (“Smiljanic”).
Regarding claim 11, the rejection of claim 4 is incorporated, but Wang in view of Munafo does not more particularly teach that the watchpoint command is in a predetermined JSON or CBOR format. However, Smiljanic does teach: wherein the watchpoint configuration command is a command in a predetermined JSON or CBOR format (Smiljanic, e.g., ¶68, “REST API 163 requests that the debugger client 164 create a new UUID to represent the debugging session … provides the UUID to the debugger UI 161, for example, in a JSON payload …” See also, e.g., ¶73, “Operation 523 from REST API 163 to the debugger client 164 sets the break points … break points were set for instructions 1, 2, and 4 …”) for the purpose of creating and configuring debugging sessions via which a user can configure and initialize various debugging commands for execution (Smiljanic, e.g., ¶¶65-76).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for remote software debugging of embedded terminals as taught by Wang in view of Munafo to provide that the watchpoint command is in a predetermined JSON or CBOR format because the disclosure of Smiljanic shows that it was known to those of ordinary skill in the pertinent art to improve a system and method of remote stateless debugging to provide that the watchpoint command is in a predetermined JSON or CBOR format for the purpose of creating and configuring debugging sessions via which a user can configure and initialize various debugging commands for execution (Smiljanic, Id.).
Regarding claim 12, the rejection of claim 11 is incorporated, and Wang further teaches: wherein after parsing the watchpoint configuration command to identify the address, the method further comprises: based on the address of the watchpoint, determining whether a previously set watchpoint exists at the address which the watchpoint is to be set, and if so, clearing the previously set watchpoint at the corresponding address (Wang, e.g., ¶82, “When receiving the address, where a breakpoint is to be set, from the upper computer, the terminal will first determine whether a breakpoint already exists at this address … whether the instruction address compare register has a vacant space is determined; if not, the information that no more breakpoint can be set until some existing breakpoints are cleared will be fed back to the upper computer …”).
Regarding claim 14, the rejection of claim 1 is incorporated, but Wang in view of Munafo does not more particularly teach that the IoT device receives commands sent by the debugging server through a runtime library with a single thread of execution. However, Smiljanic does teach: wherein the IoT device receives commands sent by the debugging server through a runtime library with a single thread of execution (Smiljanic, e.g., ¶68, “REST API 163 requests that the debugger client 164 create a new UUID to represent the debugging session … provides the UUID to the debugger UI 161, for example, in a JSON payload …” See also, e.g., ¶73, “Operation 523 from REST API 163 to the debugger client 164 sets the break points … break points were set for instructions 1, 2, and 4 …”) for the purpose of creating and configuring debugging sessions via which a user can configure and initialize various debugging commands for execution (Smiljanic, e.g., ¶¶65-76).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for remote software debugging of embedded terminals as taught by Wang in view of Munafo to provide that the IoT device receives commands sent by the debugging server through a runtime library with a single thread of execution because the disclosure of Smiljanic shows that it was known to those of ordinary skill in the pertinent art to improve a system and method of remote stateless debugging to provide that the IoT device receives commands sent by the debugging server through a runtime library with a single thread of execution for the purpose of creating and configuring debugging sessions via which a user can configure and initialize various debugging commands for execution (Smiljanic, Id.).
Claims 15-16 are rejected under 35 U.S.C. § 103 as being unpatentable over Wang in view of Munafo, and in further view of Deng et al., U.S. 6,915,416 B2 (“Deng”).
Regarding claim 15, the rejection of claim 1 is incorporated, but Wang in view of Munafo does not more particularly teach that after the set watchpoint is triggered during running of IoT device firmware, the watchpoint is set to a disabled state. However, Deng does teach: wherein after the set watchpoint is triggered during running of the firmware on the IoT device, the method further comprises: setting the set watchpoint to a disabled state (Deng, e.g., FIG. 7, wherein if the application resumes after the debug command is executed, the debugger active flag is cleared and the interrupt enable mask is released, that is, the debugging action corresponding to the set watch point is cleared (disabled)) for the purpose of selecting, configuring and executing various breakpoint options, as well as clearing the breakpoints after execution in at least some embodiments (Deng, e.g., 7:54-8:24).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for remote software debugging of embedded terminals as taught by Wang in view of Munafo to provide that after the set watchpoint is triggered during running of IoT device firmware, the watchpoint is set to a disabled state because the disclosure of Deng shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for remote microcontroller debugging to provide that after the set watchpoint is triggered during running of IoT device firmware, the watchpoint is set to a disabled state for the purpose of selecting, configuring and executing various breakpoint options, as well as clearing the breakpoints after execution in at least some embodiments (Deng, Id.).
Regarding claim 16, the rejection of claim 1 is incorporated, but Wang in view of Munafo does not more particularly teach that after executing the debugging action, it is determined whether the set watchpoint is a sticky watchpoint, and if not, clearing the debugging action corresponding to the set watchpoint. However, Deng does teach: wherein after executing the corresponding debugging action, the method further comprises: determining whether the set watchpoint is a sticky watchpoint (Deng, e.g., FIG. 7, wherein if the application resumes after the debug command is executed, the debugger active flag is cleared and the interrupt enable mask is released, that is, the debugging action corresponding to the set watch point is cleared);
if yes, and if the IoT device supports hardware single stepping, enabling hardware single stepping and returning, so as to return to resume execution from the set watchpoint and generating a single step interrupt; and inside the single step interrupt, re-enabling the set watchpoint and disabling further single stepping; and if the IoT device does not support hardware single stepping, setting a provisional breakpoint at an instruction next to an instruction corresponding to the set watchpoint, so as to return to resume execution from the set watchpoint until the provisional breakpoint is triggered, thereby executing a same debugging action as the set watchpoint is triggered; and if not, clearing the debugging action corresponding to the set watchpoint (Deng, e.g., FIG. 7, wherein if the application resumes after the debug command is executed, the debugger active flag is cleared and the interrupt enable mask is released, that is, the debugging action corresponding to the set watch point is cleared) for the purpose of selecting, configuring and executing various breakpoint options, as well as clearing the breakpoints after execution in at least some embodiments (Deng, e.g., 7:54-8:24).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for remote software debugging of embedded terminals as taught by Wang in view of Munafo to provide that after executing the debugging action, it is determined whether the set watchpoint is a sticky watchpoint, and if not, clearing the debugging action corresponding to the set watchpoint because the disclosure of Deng shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for remote microcontroller debugging to provide that after executing the debugging action, it is determined whether the set watchpoint is a sticky watchpoint, and if not, clearing the debugging action corresponding to the set watchpoint for the purpose of selecting, configuring and executing various breakpoint options, as well as clearing the breakpoints after execution in at least some embodiments (Deng, Id.).
Conclusion
Examiner has identified particular references contained in the prior art of record within the body of this action for the convenience of Applicant. Although the citations made are representative of the teachings in the art and are applied to the specific limitations within the enumerated claims, the teaching of the cited art as a whole is not limited to the cited passages. Other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art and/or disclosed by Examiner.
Examiner respectfully requests that, in response to this Office Action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 C.F.R. 1.111(c).
Examiner interviews are available via telephone and video conferencing using a USPTO-supplied web-based collaboration tool. Applicant is encouraged to submit an Automated Interview Request (AIR) which may be done via https://www.uspto.gov/patent/uspto-automated-interview-request-air-form, or may contact Examiner directly via the methods below.
Any inquiry concerning this communication or earlier communication from Examiner should be directed to Andrew M. Lyons, whose telephone number is (571) 270-3529, and whose fax number is (571) 270-4529. The examiner can normally be reached Monday to Friday from 10:00 AM to 6:00 PM ET. If attempts to reach Examiner by telephone are unsuccessful, Examiner’s supervisor, Wei Mui, can be reached at (571) 272-3708. Information regarding the status of an application may be obtained from the Patent Center system. For more information about the Patent Center system, see https://www.uspto.gov/patents/apply/patent-center. If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call (800) 786-9199 (in USA or Canada) or (571) 272-1000.
/Andrew M. Lyons/Primary Examiner, Art Unit 2191
