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 .
DETAILED ACTION
This is the initial office action based on the application filed on October 15th, 2024, which claims 1-19 are presented for examination.
Examiner Notes
Examiner cites particular columns 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 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.
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 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.
Status of Claims
Claims 1-19 are pending in the application and have been examined below, of which, claims 1 and 10 are presented in independent form.
Internet E-mail
A written authorization by Applicant is required for the Examiner to respond via
internet e-mail to any Internet correspondence which contains information subject to the
confidentiality requirement as set forth in 35 U3.0. 122, such as proposed Examiner’s
Amendments or interview agenda items (MPEP 502.03; See Internet Usage Policy, 64
PR 33056 (June 21, 1999)). To authorize e-mail communications from the Examiner
(e.g. proposed Examiner’s Amendments), the Applicant must place a written
authorization in the record. Applicant may authorize electronic and email communication
by the Examiner via PTO Automated Interview Request web service. To schedule an
interview, applicant is encouraged to use the USPTO Automated Interview Request
(AER) at http://www.uspto.gov/interviewpractice.
Information Disclosure Statement
The information disclosure statement filed on October 15th, 2024 complies with the provisions of 37 CFR 1.97, 1.98. The complied IDS has been placed in the application file and the information referred to therein has been considered as to the merits.
Claim Objections
Claims 1-9 are objected to because of the following informalities:
Claims 1 and 14 recite the limitation “servicing of the interrupt” in lines 11 and 4, respectively. They should be -- the servicing of the interrupt --.
Claims 1, 2, 13, and 16 recite the limitation “service of the interrupt” in lines 13, 5, 2, and 4, respectively. They should be -- the servicing of the interrupt -- and -- the service of the interrupt --.
Claims 2-9: are dependent on claim 1 but not cure the deficiencies of that claim. Accordingly, they are objected to for the same reasons
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the second paragraph of 35 U.S.C. 112:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 2 is rejected under 35 U.S.C. 112, second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention.
Claim 2 recites the limitation “servicing the debug access request” in line 5. It is unclear if servicing “the debug access request” in claim 1 (See line 9) or “second debug access request” in claim 2 (See line 3). Clarification and appropriate correction are required.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claim 1 is rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim 12 of U.S. Patent No. 10,769,050. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 12 of U.S. Patent No. 10,69,050 recites the elements of claim 1 of the instant application. Both claim features of the instant application and U.S. Patent No. 10,769,050 can be compared as follows:
INSTANT APPLICATION
18/915572
PATENT NO.
10,769,050
Claim 1:
A method comprising:
executing, by a processor, a first code section having a first priority;
encountering, by the processor, during the executing of the first code section, a breakpoint;
receiving, by the processor, while at the breakpoint, an interrupt associated with a second code section, the interrupt having a second priority that is higher than the first priority;
servicing, by the processor, the interrupt including executing the second code section;
receiving a debug access request associated with the breakpoint during the servicing of the interrupt;
blocking servicing of the debug access request until servicing of the interrupt is completed; and
servicing, by the processor, the debug access request after completing service of the interrupt.
Claim 1:
A method comprising:
executing, using a processor, a first code section having a first priority and having a first breakpoint;
upon the processor reaching the first breakpoint: establishing a first debug context for the first breakpoint; and
halting execution of the processor at the first breakpoint; while the processor is halted at the first breakpoint, receiving an indication associated with a second code section, wherein the second code section has a second priority that is greater than the first priority;
in response to the indication: resuming the processor; and executing, using the processor, the second code section, wherein at least one information access request is held while executing the second code section; and
Claim 13: The method of claim 12 further comprising, during execution of the second code section, receiving a debug request for data associated with the first debug context.
upon completion of execution of the second code section: returning to the first debug context; and
halting execution of the processor at the first breakpoint.
Claim 1 is rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim 1 of U.S. Patent No. 12,153,509. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 1 of U.S. Patent No. 12,153,509 recites the elements of claim 1 of the instant application. Both claim features of the instant application and U.S. Patent No. 12,153,509 can be compared as follows:
INSTANT APPLICATION
18/915572
PATENT NO.
12,153,509
Claim 1:
A method comprising:
executing, by a processor, a first code section having a first priority;
encountering, by the processor, during the executing of the first code section, a breakpoint;
receiving, by the processor, while at the breakpoint, an interrupt associated with a second code section, the interrupt having a second priority that is higher than the first priority;
servicing, by the processor, the interrupt including executing the second code section;
receiving a debug access request associated with the breakpoint during the servicing of the interrupt;
blocking servicing of the debug access request until servicing of the interrupt is completed; and
servicing, by the processor, the debug access request after completing service of the interrupt
Claim 1:
A method comprising:
executing, by a processor, a first code section, wherein the first code section is associated with a context of the processor;
receiving, during the executing of the first code section, a debug event;
based on the debug event, causing the processor to suspend the executing of the first code section; while the executing of the first code section is suspended, receiving an interrupt;
in response to receiving the interrupt, causing the processor to execute a second code section associated with the interrupt;
receiving a debug access request during the executing of the second code section;
causing the processor to delay servicing the debug access request until completion of the second code section; and
after completion of the second code section, causing the processor to service the debug access request based on the context associated with the first code section.
Claim 1 is rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim 19 of U.S. Patent No. 11,307,965. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 19 of U.S. Patent No. 11,307,965recites the elements of claim 1 of the instant application. Both claim features of the instant application and U.S. Patent No. 11,307,965can be compared as follows:
INSTANT APPLICATION
18/915572
PATENT NO.
11,307,965
Claim 1:
A method comprising:
executing, by a processor, a first code section having a first priority;
encountering, by the processor, during the executing of the first code section, a breakpoint;
receiving, by the processor, while at the breakpoint, an interrupt associated with a second code section, the interrupt having a second priority that is higher than the first priority;
servicing, by the processor, the interrupt including executing the second code section;
receiving a debug access request associated with the breakpoint during the servicing of the interrupt;
blocking servicing of the debug access request until servicing of the interrupt is completed; and
servicing, by the processor, the debug access request after completing service of the interrupt.
Claim 19:
A method comprising:
executing, by a processing unit, a first code section having a first execution priority;
pausing, by the processing unit, in response to a first debug event associated with the first code section;
in response to pausing in response to the first debug event, retrieving, by the processing unit, a first debug context;
receiving, by the processing unit, an indication that a second code section of a higher execution priority than the first execution priority requires servicing while the processing unit is paused at the first debug event;
in response to a second debug event, resuming, by the processing unit, execution to service the second code section while maintaining the first debug context, wherein at least one information access request is held while executing the second code section; and
pausing the processing unit in the first code section upon completion of servicing the second code section to return to an execution state consistent with the first debug context.
Claim Rejections - 35 U.S.C § 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, 15, and 16 are rejected under 35 U.S.C. § 103 as being unpatentable Tucker et al. (US Publication No. 2018/0121323 – hereinafter, Tucker – IDS filed 10/15/2024) in view of Warkentin et al. (U.S. Publication No. 2016/0378699 – hereinafter, Warkentin – IDS filed 10/15/2024).
Regarding claim 1:
Tucker discloses a method comprising:
executing, by a processor, a first code section (FIG. 3 and associated text, such as, “the application module 330 may identify a set of instructions (e.g., a server-side script) that will be executed in a debug mode in response to the request. The application module 330 may initiate execution of the set of instructions, for example, by passing an identified script to the script module 340 and using a debug API provided by the debug controller 344 to control the execution of the script on a line-by-line basis.” (Emphasis added – See para [0067]). FIG. 4 and associated text, such as, “Execution of the set of instructions may be initiated (at operation 432)” (See para [0082])) [[having a first priority]];
encountering, by the processor, during the executing of the first code section, a breakpoint (FIG. 3 and associated text, such as, “Execution of the script may continue until the application module 330 determines that a line or instruction of a script corresponding to a first breakpoint has been reached.” (Emphasis added – See para [0067]). FIG. 4 and associated text, such as, “For example, a command (e.g., step or resume) may be passed through a debug API to the script module 340 to initiate (at operation 432) execution of a script previously passed to the script module 340” (See para [0082]));
receiving, by the processor, while at the breakpoint, an interrupt associated with a second code section (FIG. 3 and associated text, such as, “Subsequent requests 360 may be transmitted from the client device 312 to the server device 302 to continue the debugging of the script. For example, the requests 360 may be sent to step into, step over the next line of the script, or resume execution of the script until the next breakpoint is reached” (Emphasis added – See para [0070]). FIG. 4 and associated text, such as, “A next instruction in the identified (at operation 424) set of instructions may then be checked (at operation 435) to determine whether there is a breakpoint that should be enforced for the next instruction” (See para [0083]). “If (at operation 435) there is an applicable breakpoint for the next instruction, a pause marker may be checked (at operation 445) to determine, based on the pause marker, whether pausing execution of the identified (at operation 424) set of instructions using the data structure is permitted” (See para [0086])), [[the interrupt having a second priority that is higher than the first priority]];
servicing, by the processor, the interrupt including executing the second code section (FIG. 8 and associated text, such as, “The technique 800 may include determining (at operation 820) whether a user is permitted to access a subset of instructions (e.g., a function or method) from a set of instructions being executed in a debug mode.” (Emphasis added – See para [0129]));
receiving a debug access request associated with the breakpoint during the servicing of the interrupt (FIG. 8 and associated text, such as, “If (at operation 825) the user has permission to access the subset of instructions (e.g., a function) implicated by the request, then a debugger instance may step into (at operation 730) the subset of instructions (e.g., a function) implicated by the request.” (Emphasis added – See para [0130]));
blocking servicing of the debug access request until servicing of the interrupt is completed (FIG. 8 and associated text, such as, “If (at operation 825) the user has permission to access the subset of instructions (e.g., a function) implicated by the request, then a debugger instance may step into (at operation 730) the subset of instructions (e.g., a function) implicated by the request. For example, execution of the set of instructions may be paused at a first instruction of the subset of instructions to provide an opportunity for the user to read the file in which the subset of instructions is stored, examine the debugger state (e.g., variables used by the set of instructions), and/or input commands for continued execution in a debug mode. For example, a copy of the file storing the subset of instructions (e.g., a function) may be sent to a client device (e.g., the client device 312) after the execution is paused (at operation 830) to allow the user to review instructions in the file” (Emphasis added – See para [0130)); and
servicing, by the processor, the debug access request after completing service of the interrupt FIG. 8 and associated text, such as, “If (at operation 825) the user has permission to access the subset of instructions (e.g., a function) implicated by the request, then a debugger instance may step into (at operation 730) the subset of instructions (e.g., a function) implicated by the request. For example, execution of the set of instructions may be paused at a first instruction of the subset of instructions to provide an opportunity for the user to read the file in which the subset of instructions is stored, examine the debugger state (e.g., variables used by the set of instructions), and/or input commands for continued execution in a debug mode. For example, a copy of the file storing the subset of instructions (e.g., a function) may be sent to a client device (e.g., the client device 312) after the execution is paused (at operation 830) to allow the user to review instructions in the file” (Emphasis added – See para [0130)).
But Tucker does not explicitly teach:
the interrupt having a second priority that is higher than the first priority.
However, Warkentin discloses:
the interrupt having a second priority that is higher than the first priority (FIG. 5B and associated text, such as, “when processor core 206 receives an interrupt, it will automatically clear the enable bit 226 in the processor core 206 so that it can handle the received interrupt without being interrupted again. The exception control flow of the first embodiment begins in step 552, where system software reads the interrupt vector from IAR 304. In step 554, system software determines whether the interrupt vector is a PNMI or not based on the integer number of the vector. For example, in one embodiment, if the integer number of the vector is 1022, then the interrupt vector is considered a PNMI, but if the integer number is less than 1022, the interrupt is considered a regular interrupt. In other embodiments, a different integer vector may be assigned as the PNMI vector. If the interrupt vector is a PNMI, then system software executes the PNMI handler function in step 556,” (See par. [0030]). FIG. 6C and associated text, such as, “FIG. 6C depicts a control flow for handling an exception in the second embodiment. When processor core 206 receives an asserted IRQ, processor core 206 internally processes the received interrupt, which includes disabling interrupts in processor core 206 by turning off enable bit 226… if it is determined in step 654 that interrupts are enabled in GIC 214, the pending interrupt can be either a PNMI or a regular interrupt. If the pending interrupt is a PNMI as determined in step 672, system software processes the pending interrupt as a PNMI in steps 664 and 668.” (See pars. [0035] – [0036])).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Warkentin into the teachings of Tucker because that would have handled a higher priority interrupt even though a regular interrupt being in a process as suggested by Warkentin (See para [0027]).
Regarding claim 2:
The rejection of claim 1 is incorporated, Tucker further discloses wherein the debug access request is a first debug access request, the method further comprising:
receiving a second debug access request associated with the breakpoint during the servicing of the interrupt (FIG. 8 and associated text, such as “In some implementations, execution of the identified set of instructions is paused (at operation 830) by issuing or withholding a command to a script engine through a debug API. For example, the application module 330 may pause (at operation 830) execution of a script by issuing a command to the script module 340 through its debug API provided by the debug controller 344, where the command may cause the script module 340 to enter a pause state.” (See para [0130])); and
servicing the debug access request prior to completing service of the interrupt (FIG. 8 and associated text, such as “In some implementations, execution of the identified set of instructions is paused (at operation 830) by issuing or withholding a command to a script engine through a debug API. For example, the application module 330 may pause (at operation 830) execution of a script by issuing a command to the script module 340 through its debug API provided by the debug controller 344, where the command may cause the script module 340 to enter a pause state.” (See para [0130])).
Regarding claim 3:
The rejection of claim 1 is incorporated, Tucker further comprising, based on the interrupt, storing a context associated with breakpoint (“The presence of debug configuration information (e.g., a breakpoint or a debug mode enable flag) associated with (e.g., stored in a database or file with a reference to or in the same location as the set of instructions) the set of instructions to be executed in providing the requested service may automatically trigger a debugger instance that is not explicitly called for in the request message that is received (at operation 410).” (See para [0080])).
Regarding claim 4:
The rejection of claim 3 is incorporated, Tucker further discloses wherein the context includes at least one of a flag value, [[a register value, a control signal value, and a memory content]] (“The presence of debug configuration information (e.g., a breakpoint or a debug mode enable flag) associated with (e.g., stored in a database or file with a reference to or in the same location as the set of instructions) the set of instructions to be executed in providing the requested service may automatically trigger a debugger instance that is not explicitly called for in the request message that is received (at operation 410).” (See para [0080])).
Regarding claim 5:
The rejection of claim 4 is incorporated, Tucker further discloses further comprising, after completing service of the interrupt, restoring the context (FIG. 4 and associated text, such as, “For example, a command (e.g., step or resume) may be passed through a debug API to the script module 340 to initiate (at operation 432) execution of a script previously passed to the script module 340” (See para [0082])).
Regarding claim 8:
The rejection of claim 1 is incorporated, Tucker further discloses wherein the breakpoint is triggered by preprogrammed software or preconfigured hardware (“If an applicable breakpoint is detected, but it is determined that the breakpoint should be skipped, the callback function may issue a command through the debug API to execute this next line of the script. If an applicable breakpoint is detected and it is determined that execution should be paused at the breakpoint, the callback function may issue a command through the debug API to pause execution at this next line of the script or withhold (for the time being) a command to execute this next line of the script. In some implementations, the application module 330 may use this callback function to determine that a breakpoint will be skipped if, for example, a limit on the number of concurrent debug instances using resources (e.g., a session data structure or a processor) would be exceeded or a user of a debug instance lacks permission to access the instruction (e.g., a line of code) associated with the breakpoint.” (See para [0065])).
Regarding claim 9:
The rejection of claim 6 is incorporated, Tucker further discloses wherein the second breakpoint is triggered by a user command (FIG. 3 and associated text, such as, “For example, a debugger interface running on a client device may provide user interface (e.g., including the display region 910 of FIG. 9) to the user and enable the user to control (e.g., by setting breakpoints and/or issuing step commands) execution of the identified set of instructions and to examine the state (e.g., including the values of variables used by the identified set of instructions) when execution on the server is paused.” (See para [0027])).
Regarding claim 10:
This is a computing device version of the rejected method claim 1 above, wherein all the limitations of this claim have been noted in the rejection of claim 1 and is therefore rejected under similar rationale.
Regarding claim 11:
The rejection of base claim 10 is incorporated. All the limitations of this claim have been noted in the rejection of claim 3 and is therefore rejected under similar rationale.
Regarding claim 12:
The rejection of base claim 10 is incorporated. All the limitations of this claim have been noted in the rejection of claim 4 and is therefore rejected under similar rationale.
Regarding claim 13:
The rejection of base claim 10 is incorporated. All the limitations of this claim have been noted in the rejection of claim 5 and is therefore rejected under similar rationale.
Regarding claim 17:
The rejection of claim 10 is incorporated, Tucker further discloses wherein the debug controller includes a debug monitor (FIG. 9).
Regarding claim 18:
The rejection of claim 10 is incorporated, Tucker further discloses wherein the debug controller has an input/output terminal configured to interface with a debug host (FIG. 9).
Regarding claim 19:
The rejection of claim 10 is incorporated, Tucker further comprising:
a set of processors that includes the processor (FIG. 1 – 202); and
a set of debug controllers that includes the debug controller, a respective one of the debug controllers associated with a respective one of the processors (FIG. 3 – 344).
Allowable Subject Matter
The combination of claims 6+7 and 14+15+16 are objected to as being dependent upon a rejected base claims 1 and 10, respectively, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Barsness et al. (Pub. No.: US 2018/0210813) discloses a method for debugging an executable at runtime. The method begins by receiving one or more breakpoints related to a call stack in the executable. The processor receives an executable in a debug environment. The processor executes an executable until one or more breakpoints are hit. Upon detecting a breakpoint, the processor temporarily halts executing by transferring control to an analysis tool to gather information related to execution of the executable up to the breakpoint. The analysis tool gathers one or more predefined outliers. The processor receives control back from the analysis tool to continue execution in response to the analysis tool collecting relevant information in the executable.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HANH THI MINH BUI whose telephone number is (571)270-1976. The examiner can normally be reached Monday - Friday: 7-3.
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 at 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.
/HANH THI-MINH BUI/Primary Examiner, Art Unit 2192 September 18th, 2026
Prosecution Insights