Prosecution Insights
Last updated: July 17, 2026
Application No. 18/153,244

INFORMATION PROCESSING APPARATUS, PROCESSING METHOD FOR INFORMATION PROCESSING APPARATUS, AND STORAGE MEDIUM

Final Rejection §103§112
Filed
Jan 11, 2023
Priority
Jan 18, 2022 — JP 2022-005831
Examiner
BOURZIK, BRAHIM
Art Unit
2191
Tech Center
2100 — Computer Architecture & Software
Assignee
Canon Inc.
OA Round
4 (Final)
64%
Grant Probability
Moderate
5-6
OA Rounds
0m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 64% of resolved cases
64%
Career Allowance Rate
248 granted / 385 resolved
+9.4% vs TC avg
Strong +44% interview lift
Without
With
+44.0%
Interview Lift
resolved cases with interview
Typical timeline
3y 6m
Avg Prosecution
26 currently pending
Career history
417
Total Applications
across all art units

Statute-Specific Performance

§101
0.6%
-39.4% vs TC avg
§103
94.1%
+54.1% vs TC avg
§102
1.9%
-38.1% vs TC avg
§112
3.0%
-37.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 385 resolved cases

Office Action

§103 §112
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Claims 1, 3-6, 8-10 and 12-19 are pending in this office action. Claim 2, 7, and 11 are cancelled. Response to Arguments Applicant's arguments filed 03/02/2026 have been fully considered but they are not persuasive. Applicant’s argument: Applicant submits the following features of amended claim 1 are not taught in the references of Raviv and Baddourah. Specifically, claim 1 recites distinguishable features such as: "a debugged code checking unit configured to check, when the source code is debugged, whether the debugged source code has a security risk, and notify the debugger in a case where the debugged source code has a security risk as a result of checking by the debugged code checking unit, wherein the code execution unit executes the debugged source code in a case where the debugged source code has no security risk as a result of the checking by the debugged code checking unit, and wherein the resource opening unit updates a range of the first resources to be opened based on the result of execution of the debugged source code", as recited in amended claim 1. Applicant submits the references of Raviv and Baddourah, alone or in combination, fail to teach or suggest every feature of the current listing of claims and therefore is not obvious to one of ordinary skill in the art. Examiner response: The issue in the argument is that Raviv and Baddourah do not discloses the amended claim 1. Raviv discloses: a debugged code checking unit configured to check, when the source code is debugged, whether the debugged source code has a security risk: [0214] “The debugger instruments and visualizes the execution of the code fragment from the current execution point until the end of the current scope, thereby allowing time travel debugging to the ‘future’. Note, however, that the debugger cannot execute any arbitrary code fragment in the debuggee as the execution may introduce unwanted side effects either (1) within the program or virtual machine memory, such as changing a static variable or an object's field; or (2) outside the program or virtual machine memory, such as deleting a file on disk, communicating with a database or network server, etc”; and notify the debugger in a case where the debugged source code has a security risk as a result of checking by the debugged code checking unit [0245] A diagram illustrating an example compare tool for comparing a variable at different points of execution is shown in FIG. 28. Using the compare tool, the developer selects two or more occurrences of the same variable at different points of execution. For example, the user selects the starting order.ID 670 and the ending order.ID 672. By selecting these two (or more) comparison candidates, they are highlighted in the code editor and appear in the compare tool 668. The comparison, therefore, enables a “code side effect visualization,” where any mutation to the object's state over time can be examined and analyzed by comparing the “before” and “after” states of the object”; wherein the code execution unit executes the debugged source code in a case where the debugged source code has no security risk as a result of the checking by the debugged code checking unit: [0220] “In this manner, the system provides prediction of code execution without causing any side effects whatsoever to the debuggee process. When the user changes the code of the debugged method, the memory delta buffer and the nested data structure are simply cleared and a new virtual execution is performed based on the code change, thus enabling an experience of live coding”. wherein the resource opening unit updates a range of the first resources to be opened based on the result of execution of the debugged source code: [0333] “Occasionally in the course of debugging in a production environment, a problem arises when reported bug correlates with specific personally identifiable customer information”. [0334] To overcome this problem, the cloud debugger of the present invention provides a service that permits the developer to request and obtain a customer's consent for accessing their sensitive data. When the developer issues such a request, the customer receives a message via email or any other suitable communications channel. When the customer gives the authorization to view the sensitive information, the cloud debugger modifies the value replacement algorithm for this specific customer. All other customers' sensitive information is not affected”; NB: applicant’s representative is encouraged for an examiner interview using the information at the bottom of this office action. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: 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. Claims 1, 3-6 and 8-10 and 12-19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claims 1, 18 and 19 recites : “Whether the debugged source code has a security risk, and notify the debugger in a case where the debugged source code has a security risk as a result of checking”; in lines 13-15,11-13 and 12-14 respectively. It is not clear if a security risk is the same as recited in this limitations or they are different security risk. The claims are ambiguous. claim 8 recites at line 4 : “ a security risk” it is not clear if it is referring to the security risk defined in independent claim 1 or a different security risk. The claim is also ambiguous. dependents claims 3-6 and 8-10 and 12-17 depends upon independent claim 1 and inherits the deficiencies and also rejected under the same rationale. 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. Claims 1, 3-6, 8-9, 14 and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Raviv et al US20190213355A1 in view of Baddourah et al US20170123873A1. Raviv discloses an information processing apparatus comprising: at least one memory that stores a set of instructions; and at least one processor by executing the set of instructions: [0125]’The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks”; function as: a code execution unit configured to execute a source code: [0179]“The source code, once obtained is instrumented via the source code instrumentation module 566 (step 802). This is achieved by inserting statement or hooks into the source code which call diagnostic functions provided by the debugger. The code execution and simulation module 564 then simulates execution of the instrumented code using the isolated execution environment 562 (step 804)”; a debugged code checking unit configured to check, when the source code is debugged, whether the debugged source code has a security risk: [0214] “The debugger instruments and visualizes the execution of the code fragment from the current execution point until the end of the current scope, thereby allowing time travel debugging to the ‘future’. Note, however, that the debugger cannot execute any arbitrary code fragment in the debuggee as the execution may introduce unwanted side effects either (1) within the program or virtual machine memory, such as changing a static variable or an object's field; or (2) outside the program or virtual machine memory, such as deleting a file on disk, communicating with a database or network server, etc”; and notify the debugger in a case where the debugged source code has a security risk as a result of checking by the debugged code checking unit [0245] A diagram illustrating an example compare tool for comparing a variable at different points of execution is shown in FIG. 28. Using the compare tool, the developer selects two or more occurrences of the same variable at different points of execution. For example, the user selects the starting order.ID 670 and the ending order.ID 672. By selecting these two (or more) comparison candidates, they are highlighted in the code editor and appear in the compare tool 668. The comparison, therefore, enables a “code side effect visualization,” where any mutation to the object's state over time can be examined and analyzed by comparing the “before” and “after” states of the object”; wherein the code execution unit executes the debugged source code in a case where the debugged source code has no security risk as a result of the checking by the debugged code checking unit: [0220] “In this manner, the system provides prediction of code execution without causing any side effects whatsoever to the debuggee process. When the user changes the code of the debugged method, the memory delta buffer and the nested data structure are simply cleared and a new virtual execution is performed based on the code change, thus enabling an experience of live coding”. wherein the resource opening unit updates a range of the first resources to be opened based on the result of execution of the debugged source code: [0333] “Occasionally in the course of debugging in a production environment, a problem arises when reported bug correlates with specific personally identifiable customer information”. [0334] To overcome this problem, the cloud debugger of the present invention provides a service that permits the developer to request and obtain a customer's consent for accessing their sensitive data. When the developer issues such a request, the customer receives a message via email or any other suitable communications channel. When the customer gives the authorization to view the sensitive information, the cloud debugger modifies the value replacement algorithm for this specific customer. All other customers' sensitive information is not affected”; But not explicitly: a resource opening unit configured to open first resources to a debugger and not to open second resources to the debugger, wherein the first resources are used from a start of the source code execution to an end of the source code execution by an execution error and included in an open resource list, and the second resources are not used from the start of the source code execution to the end of the source code execution by the execution error and are included in the open resource list; Baddourah discloses: a resource opening unit configured to open first resources to a debugger and not to open second resources to the debugger: [0007] “A first aspect, combinable with the general implementation, further comprising determining whether the first set of computing nodes are not all healthy; in response to determining that the first set of computing nodes are not all healthy, identifying one or more bad computing nodes from the first set of computing nodes; and prior to executing the job, allocating a second set of computing nodes from a healthy computing node pool to the job”. [0037] Workflow A 200a can be performed to maintain and manage a resource pool (for example, the resource pool 130 in FIG. 1). The resource pool can include or be divided into a healthy computing node pool 210 and a bad computing node pool 230. Examiner interpretation: healthy nodes will be used to execute the job by the debugger while bad nodes will not be used. wherein the first resources are used from a start of the source code execution to an end of the source code execution by an execution error and included in an open resource list: : [0074]”At 760, in response to determining that the first set of computing nodes are healthy, the job has started executing. From 760, the example process 700 proceeds to 770” [0077] At 780, whether the job fails or succeeds is determined, for example, according to the example techniques described with respect to 214. If the job is successfully executed, the example process 700 proceeds to 785 where the computing resources (for example, the second set of computing nodes allocated to the job) can be released, for example, by putting them back into the resource pool of the computer system. From 785, the example process 700 can go back to 710 to perform a routine health check. On the other hand, if the job fails, the example process 700 proceeds to 790. and the second resources are not used from the start of the source code execution to the end of the source code execution by the execution error and are included in the open resource list: [0071] At 750, whether the first set of computing nodes are all healthy is determined. In some implementations, the determination can be made in a similar manner to the determination 208 in FIG. 2A. If all the first set of computing nodes are healthy, the example process 700 proceeds from 750 to 760. If the first set of computing nodes are not all healthy, the example process 700 proceeds from 750 to 755. [0072] At 755, a second set of computing nodes is allocated to the job prior to executing the job. From 755, the example process 700 can go back to 740 to perform a prior-job-execution diagnosis on the second set of computing nodes to make sure the second set of computing nodes are all healthy before executing the job. It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Baddourah into teachings of Raviv to have multiple dumps from multiple production debugging sources of the same logical flow in one place. Each cloud service has its own associated host environment. Typically, applications include call chains from hop from service to service. The debugger of the present invention combines all the services into a single collaborative debugging session. In addition, the debugger provides the developer the ability to add a point-in-time link that spans all of these moments in time, even if they span multiple services.[Raviv 0284]. As per claim 3, the rejection of claim 1 is incorporated and furthermore Raviv discloses: wherein the resource opening unit opens the first resources to the debugger in a case where a result of the execution of the source code is a result obtained when the source code contains a bug: [0017] “The dump capture process can be controlled, so the memory dump will hold evidence for the problem that needs to be solved. For example, taking a dump when the process throws a software exception or when a memory consumption reaches a certain level”; [0230]“Point-in-time-links capture this state and enable restoring the state at a later time when a user that takes part in a collaborative debugging session chooses to activate the link. For example, user Jim can create a point in time link and pass it as part of a chat message while user Joan receives this message and activates the point-in-time link in her own development environment or web-based production debugger. A user can also restore a previously stored debugging session such as from the bug tracking system or other persistent storage and activate the point-in-time link in the development environment.”; As per claim 4, the rejection of claim 3 is incorporated and furthermore Raviv does not explicitly disclose: Wherein at least one processor executes the set of instructions to function as a resource opening ending unit configured to end opening the first resource in a case where the result of the execution of the source code is a result of the execution of the source code when the source code does not contain a bug. Baddourah discloses: Wherein at least one processor executes the set of instructions to function as a resource opening ending unit configured to end opening the first resource in a case where the result of the execution of the source code is a result of the execution of the source code when the source code does not contain a bug. [0077]“At 780, whether the job fails or succeeds is determined, for example, according to the example techniques described with respect to 214. If the job is successfully executed, the example process 700 proceeds to 785 where the computing resources (for example, the second set of computing nodes allocated to the job) can be released, for example, by putting them back into the resource pool of the computer system.”; It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Baddourah into teachings of Raviv to have multiple dumps from multiple production debugging sources of the same logical flow in one place. Each cloud service has its own associated host environment. Typically, applications include call chains from hop from service to service. The debugger of the present invention combines all the services into a single collaborative debugging session. In addition, the debugger provides the developer the ability to add a point-in-time link that spans all of these moments in time, even if they span multiple services.[Raviv 0284]. As per claim 5, the rejection of claim 1 is incorporated and furthermore Raviv discloses: and wherein the resource opening unit opens the first resources to the debugger in a case where the first resources are used in a last execution by the code execution unit and the first resources are used in a present execution by the code execution unit: [0232]“When the user activates a point-in-time-link, the debugger gets the data structure instance that represents the specific point-in-time link (step 730). It then checks whether the point in time link state was previously cached (step 732). If it was, then the cached information is used to focus on the source location and to present variable and expression values (step 734). If a cached version does not exist, then the version of the point-in-time link is checked whether it can be handled (step 736). If there is a match between the version of the point-in-time link and the version of the debugger or if the version of the point-in-time link data structure was created by an older version of the debugger and the debugger knows how to handle it, it continues with the method. Otherwise, the method informs the user that there is a version mismatch.”; But not explicitly: wherein, in a case where the source code is debugged, the code execution unit executes the debugged source code, Baddourah discloses: wherein, in a case where the source code is debugged, the code execution unit executes the debugged source code: [0060] “In some implementations, the applications can be identified by debugging, which includes reproducing the error, identifying the module and code revisions, and testing”; [0070] “At 740, a prior-job-execution diagnosis is performed on the first set of computing nodes”; It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Baddourah into teachings of Raviv to have multiple dumps from multiple production debugging sources of the same logical flow in one place. Each cloud service has its own associated host environment. Typically, applications include call chains from hop from service to service. The debugger of the present invention combines all the services into a single collaborative debugging session. In addition, the debugger provides the developer the ability to add a point-in-time link that spans all of these moments in time, even if they span multiple services.[Raviv 0284]. As per claim 6, the rejection of claim 5 is incorporated and furthermore Raviv discloses: wherein the resource opening unit changes a range of the first resources to be opened depending on a type of debugger used to debug the source code: 0232] “If there is a match between the version of the point-in-time link and the version of the debugger or if the version of the point-in-time link data structure was created by an older version of the debugger and the debugger knows how to handle it, it continues with the method.”; [0233] The debugger then checks if the current dump file matches the dump file identity that is stored in the point-in-time link data structure (step 738). If there is no match, the debugger uses the stored identity to fetch the dump file from the cloud or the on-premise debugger server, the IDE of the user that initiates the debugging session, the bug tracking system, or any persistent storage that holds dump file images (step 740). As per claim 8, the rejection of claim 1 is incorporated and furthermore Raviv discloses: wherein the at least one processor executes the set of instructions to function as the debugged code checking unit to check whether a difference between the source code before debugging and the source code after debugging contains a code having a security risk: [0226] The mechanism for viewing objects in a future-time-travel system with time travel fidelity described herein can be used to allow for a Side Effect Visualization and for comparing the same object across different points in time in program execution”; [0245] “By selecting these two (or more) comparison candidates, they are highlighted in the code editor and appear in the compare tool 668. The comparison, therefore, enables a “code side effect visualization,” where any mutation to the object's state over time can be examined and analyzed by comparing the “before” and “after” states of the object.”; As per claim 9, the rejection of claim 8 is incorporated and furthermore Raviv discloses: wherein the code having the security risk is a code for connecting with an external network or a code for deleting a file: [0214] “that the debugger cannot execute any arbitrary code fragment in the debuggee as the execution may introduce unwanted side effects either (1) within the program or virtual machine memory, such as changing a static variable or an object's field; or (2) outside the program or virtual machine memory, such as deleting a file on disk, communicating with a database or network server, etc.” As per claim 14, the rejection of claim 1 is incorporated and furthermore Raviv discloses: wherein the code execution unit executes a test code for testing the source code. [0184] “Other artifacts are concerned with the process of development itself such as project plans, business cases, and risk assessments. Build tools often refer to source code compiled for testing as an artifact, because the executable is necessary to carrying out the testing plan”; As per claim 17, the rejection of claim 1 is incorporated and furthermore Raviv discloses: wherein the resource opening unit opens the resources in a state where the resources included in the open resource list are partly hidden: 0029]”Sensitive private information originating in the production environment can be redacted while preserving the production debugging experience. In particular, the debugger provides for (1) obscuring sensitive information; (2) replacing sensitive information with meaningful fake information; or (3) requesting authorization to access sensitive personal information directly from the customer. The private data is obscured or replaced with fake data without effecting the execution of the code. Code execution analysis is performed to ensure that candidate replacement data will not affect the original code execution path. The invention can be used, for example, to protect the privacy and security of sensitive user information and personally identifiable information, and to adhere to the European Union's General Data Protection Regulation (GDPR).”; As per claim 18, Raviv discloses a method for an information processing apparatus, the method comprising: executing a source code: [0179]“The source code, once obtained is instrumented via the source code instrumentation module 566 (step 802). This is achieved by inserting statement or hooks into the source code which call diagnostic functions provided by the debugger. The code execution and simulation module 564 then simulates execution of the instrumented code using the isolated execution environment 562 (step 804)”; And checking, when the source code is debugged, whether the debugged source code has a security risk, and notify the debugger in a case where the debugged source code has a security risk as a result of checking: [0214] “The debugger instruments and visualizes the execution of the code fragment from the current execution point until the end of the current scope, thereby allowing time travel debugging to the ‘future’. Note, however, that the debugger cannot execute any arbitrary code fragment in the debuggee as the execution may introduce unwanted side effects either (1) within the program or virtual machine memory, such as changing a static variable or an object's field; or (2) outside the program or virtual machine memory, such as deleting a file on disk, communicating with a database or network server, etc”; wherein executing the debugged source code in a case where the debugged source code has no security risk as a result of the checking: [0220] “In this manner, the system provides prediction of code execution without causing any side effects whatsoever to the debuggee process. When the user changes the code of the debugged method, the memory delta buffer and the nested data structure are simply cleared and a new virtual execution is performed based on the code change, thus enabling an experience of live coding”. and wherein updating a range of the first resources to be opened based on the result of execution of the debugged source code: [0333] “Occasionally in the course of debugging in a production environment, a problem arises when reported bug correlates with specific personally identifiable customer information”. [0334] To overcome this problem, the cloud debugger of the present invention provides a service that permits the developer to request and obtain a customer's consent for accessing their sensitive data. When the developer issues such a request, the customer receives a message via email or any other suitable communications channel. When the customer gives the authorization to view the sensitive information, the cloud debugger modifies the value replacement algorithm for this specific customer. All other customers' sensitive information is not affected”; But not explicitly: and opening first resources to a debugger and not to open second resources to the debugger, wherein the first resources are used from a start of the source code executing to an end of the source code execution by an execution error and included in open resource list, and the second resources are not used from the start of executing the source code execution to the end of the source code execution by the execution error and included in the open resource list. Baddourah discloses: and opening first resources to a debugger and not to open second resources to the debugger: [0007] “A first aspect, combinable with the general implementation, further comprising determining whether the first set of computing nodes are not all healthy; in response to determining that the first set of computing nodes are not all healthy, identifying one or more bad computing nodes from the first set of computing nodes; and prior to executing the job, allocating a second set of computing nodes from a healthy computing node pool to the job”. [0037] Workflow A 200a can be performed to maintain and manage a resource pool (for example, the resource pool 130 in FIG. 1). The resource pool can include or be divided into a healthy computing node pool 210 and a bad computing node pool 230. Examiner interpretation: healthy nodes will be used to execute the job by the debugger while bad nodes will not be used. wherein the first resources are used from a start of the source code executing to an end of the source code execution by an execution error and included in open resource list: [0074]”At 760, in response to determining that the first set of computing nodes are healthy, the job has started executing. From 760, the example process 700 proceeds to 770. [0077] At 780, whether the job fails or succeeds is determined, for example, according to the example techniques described with respect to 214. If the job is successfully executed, the example process 700 proceeds to 785 where the computing resources (for example, the second set of computing nodes allocated to the job) can be released, for example, by putting them back into the resource pool of the computer system. From 785, the example process 700 can go back to 710 to perform a routine health check. On the other hand, if the job fails, the example process 700 proceeds to 790. and the second resources are not used from the start of executing the source code execution to the end of the source code execution by the execution error and included in the open resource list. [0071] At 750, whether the first set of computing nodes are all healthy is determined. In some implementations, the determination can be made in a similar manner to the determination 208 in FIG. 2A. If all the first set of computing nodes are healthy, the example process 700 proceeds from 750 to 760. If the first set of computing nodes are not all healthy, the example process 700 proceeds from 750 to 755. [0072] At 755, a second set of computing nodes is allocated to the job prior to executing the job. From 755, the example process 700 can go back to 740 to perform a prior-job-execution diagnosis on the second set of computing nodes to make sure the second set of computing nodes are all healthy before executing the job. It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Baddourah into teachings of Raviv to have multiple dumps from multiple production debugging sources of the same logical flow in one place. Each cloud service has its own associated host environment. Typically, applications include call chains from hop from service to service. The debugger of the present invention combines all the services into a single collaborative debugging session. In addition, the debugger provides the developer the ability to add a point-in-time link that spans all of these moments in time, even if they span multiple services.[Raviv 0284]. As per claim 19, Raviv discloses a non-transitory storage medium storing a program causing an information processing apparatus to execute a method, the method comprising: executing a source code: [0179]“The source code, once obtained is instrumented via the source code instrumentation module 566 (step 802). This is achieved by inserting statement or hooks into the source code which call diagnostic functions provided by the debugger. The code execution and simulation module 564 then simulates execution of the instrumented code using the isolated execution environment 562 (step 804)”; And checking, when the source code is debugged, whether the debugged source code has a security risk, and notify the debugger in a case where the debugged source code has a security risk as a result of checking: [0214] “The debugger instruments and visualizes the execution of the code fragment from the current execution point until the end of the current scope, thereby allowing time travel debugging to the ‘future’. Note, however, that the debugger cannot execute any arbitrary code fragment in the debuggee as the execution may introduce unwanted side effects either (1) within the program or virtual machine memory, such as changing a static variable or an object's field; or (2) outside the program or virtual machine memory, such as deleting a file on disk, communicating with a database or network server, etc”; wherein executing the debugged source code in a case where the debugged source code has no security risk as a result of the checking: [0220] “In this manner, the system provides prediction of code execution without causing any side effects whatsoever to the debuggee process. When the user changes the code of the debugged method, the memory delta buffer and the nested data structure are simply cleared and a new virtual execution is performed based on the code change, thus enabling an experience of live coding”. and wherein updating a range of the first resources to be opened based on the result of execution of the debugged source code: [0333] “Occasionally in the course of debugging in a production environment, a problem arises when reported bug correlates with specific personally identifiable customer information”. [0334] To overcome this problem, the cloud debugger of the present invention provides a service that permits the developer to request and obtain a customer's consent for accessing their sensitive data. When the developer issues such a request, the customer receives a message via email or any other suitable communications channel. When the customer gives the authorization to view the sensitive information, the cloud debugger modifies the value replacement algorithm for this specific customer. All other customers' sensitive information is not affected”; But not explicitly: and opening first resources to a debugger and not to open second resources to the debugger, wherein the first resources are used from a start of the source code executing to an end of the source code execution by an execution error and included in open resource list, and the second resources are not used from the start of executing the source code execution to the end of the source code execution by the execution error and included in the open resource list. Baddourah discloses: and opening first resources to a debugger and not to open second resources to the debugger: [0007] “A first aspect, combinable with the general implementation, further comprising determining whether the first set of computing nodes are not all healthy; in response to determining that the first set of computing nodes are not all healthy, identifying one or more bad computing nodes from the first set of computing nodes; and prior to executing the job, allocating a second set of computing nodes from a healthy computing node pool to the job”. [0037] Workflow A 200a can be performed to maintain and manage a resource pool (for example, the resource pool 130 in FIG. 1). The resource pool can include or be divided into a healthy computing node pool 210 and a bad computing node pool 230. Examiner interpretation: healthy nodes will be used to execute the job by the debugger while bad nodes will not be used. wherein the first resources are used from a start of the source code executing to an end of the source code execution by an execution error and included in open resource list: [0074]”At 760, in response to determining that the first set of computing nodes are healthy, the job has started executing. From 760, the example process 700 proceeds to 770. [0077] At 780, whether the job fails or succeeds is determined, for example, according to the example techniques described with respect to 214. If the job is successfully executed, the example process 700 proceeds to 785 where the computing resources (for example, the second set of computing nodes allocated to the job) can be released, for example, by putting them back into the resource pool of the computer system. From 785, the example process 700 can go back to 710 to perform a routine health check. On the other hand, if the job fails, the example process 700 proceeds to 790. and the second resources are not used from the start of executing the source code execution to the end of the source code execution by the execution error and included in the open resource list: [0071] At 750, whether the first set of computing nodes are all healthy is determined. In some implementations, the determination can be made in a similar manner to the determination 208 in FIG. 2A. If all the first set of computing nodes are healthy, the example process 700 proceeds from 750 to 760. If the first set of computing nodes are not all healthy, the example process 700 proceeds from 750 to 755. [0072] At 755, a second set of computing nodes is allocated to the job prior to executing the job. From 755, the example process 700 can go back to 740 to perform a prior-job-execution diagnosis on the second set of computing nodes to make sure the second set of computing nodes are all healthy before executing the job. It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Baddourah into teachings of Raviv to have multiple dumps from multiple production debugging sources of the same logical flow in one place. Each cloud service has its own associated host environment. Typically, applications include call chains from hop from service to service. The debugger of the present invention combines all the services into a single collaborative debugging session. In addition, the debugger provides the developer the ability to add a point-in-time link that spans all of these moments in time, even if they span multiple services.[Raviv 0284]. Claims 10, 12, 13, 15, 16 are rejected under 35 U.S.C. 103 as being unpatentable over Raviv et al US20190213355A1 in view of Baddourah et al US20170123873A1 and Brooker et al US10,061,613B1. As per claim 10, the rejection of claim 8 is incorporated and furthermore Raviv does not explicitly disclose: wherein the code having a security risk is a code for adding a resource other than predetermined resources: Brooker discloses: wherein the code having a security risk is a code for adding a resource other than predetermined resources: Col 24 lines 63-67 “According, at (5), the idempotency service 160 compares the dependency state information included in past execution records with current dependency state information, in order to detect that state information for current dependencies does not match that of a prior execution. Illustratively, this may indicate that a resource referenced by a parameter passed to the task has changed, that the code of the task has changed, that an external resource referenced within the task has changed, or that other dependencies of the task have changed such that execution of the code might result in a different outcome than a prior execution. It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Brooker into teachings of Raviv and Baddourah to executing idempotent code in an on-demand code execution system in a manner that increases the efficiency and reduces execution redundancy between multiple requests to execute idempotent code, for example, by implementing “memorization” for executions of the code on the on-demand code execution system. [Brooker col lines 1-10]. As per claim 12, the rejection of claim 5 is incorporated and furthermore Raviv does not explicitly disclose: wherein the code execution unit re-executes the debugged source code in a case where there is a difference between the first resources used in the last execution and the first resources used in the present execution; Brooker discloses: wherein the code execution unit re-executes the debugged source code in a case where there is a difference between the first resources used in the last execution and the first resources used in the present execution: Col 24 lines 1-5“For example, state may be indicated by content of a dependency (e.g., a file itself), a hash value of that content, a version identifier for the dependency, a “last modified” record for the dependency, etc.”; Col 24 lines 61-67 “ In the scenario of FIG. 3A, it is assumed that the state of at least on dependency of a task has changed since a prior execution. According, at (5), the idempotency service 160 compares the dependency state information included in past execution records with current dependency state information, in order to detect that state information for current dependencies does not match that of a prior execution. Illustratively, this may indicate that a resource referenced by a parameter passed to the task has change …. Col 25 lines 22-25” Thus, after detecting that state change, the idempotency server 160, at (8), returns instructions to the frontend 120 to execute the task”. It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Brooker into teachings of Raviv and Baddourah to executing idempotent code in an on-demand code execution system in a manner that increases the efficiency and reduces execution redundancy between multiple requests to execute idempotent code, for example, by implementing “memorization” for executions of the code on the on-demand code execution system. [Brooker col lines 1-10]. As per claim 13, the rejection of claim 5 is incorporated and furthermore Raviv does not explicitly disclose: wherein first resources usable by the code execution unit are a resources included in the open resource list, and wherein, in a case where the code execution unit attempts to use a resource not included in the open resource list, the resource attempted to be used is added to the open resource list. Brooker discloses: wherein the first resources usable by the code execution unit are a resources included in the open resource list: Col 5 lines 53-58” The on-demand code execution system may provide a user interface (e.g., a command line interface, graphical user interface, etc.) by which users can specify dependencies directly, such as by specifying a resource, or variably, such as by reference to a parameter or other metadata value associated with a call to execute a task.”; and wherein, in a case where the code execution unit attempts to use a resource not included in the open resource list: Col 24 lines 61-67 “In the scenario of FIG. 3A, it is assumed that the state of at least on dependency of a task has changed since a prior execution. According, at (5), the idempotency service 160 compares the dependency state information included in past execution records with current dependency state information, in order to detect that state information for current dependencies does not match that of a prior execution. Illustratively, this may indicate that a resource referenced by a parameter passed to the task has changed, that the code of the task has changed, that an external resource referenced within the task has changed, or that other dependencies of the task have changed such that execution of the code might result in a different outcome than a prior execution.”; the resource attempted to be used is added to the open resource list. Col 25 lines 58-63 “At (11), the worker manager 140 transmits to the idempotency server 160 a record of dependency states for the task during execution, such that these states can be stored by the idempotency service 160 (e.g., in an execution record for the task), and compared against dependency states during future calls.”; It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Brooker into teachings of Raviv and Baddourah to executing idempotent code in an on-demand code execution system in a manner that increases the efficiency and reduces execution redundancy between multiple requests to execute idempotent code, for example, by implementing “memorization” for executions of the code on the on-demand code execution system. [Brooker col lines 1-10]. As per claim 15, the rejection of claim 1 is incorporated and furthermore Raviv does not explicitly disclose: wherein the resource opening unit opens the first resources by providing the right to reference the first resources: Brooker discloses: wherein the resource opening unit opens the first resources by providing the right to reference the first resources: Col 12 lines 15-24 “ In such cases, the on-demand code execution system 110 may have access to such resource-level constraints before each individual call is received, and the individual call may not specify such resource-level constraints. In some embodiments, the call may specify other constraints such as permission data that indicates what kind of permissions or authorities that the call invokes to execute the task. Such permission data may be used by the on-demand code execution system 110 to access private resources (e.g., on a private network).”; It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Brooker into teachings of Raviv and Baddourah to executing idempotent code in an on-demand code execution system in a manner that increases the efficiency and reduces execution redundancy between multiple requests to execute idempotent code, for example, by implementing “memorization” for executions of the code on the on-demand code execution system. [Brooker col lines 1-10]. As per claim 16, the rejection of claim 1 is incorporated and furthermore Raviv does not explicitly disclose: wherein the resource opening unit opens the first resources by duplicating the first resources in another environment. Brooker discloses: wherein the resource opening unit opens the first resources by duplicating the first resources in another environment: Col 18 lines 1-10 “In such a case, the worker manager 140 may load the particular library and the user code onto the container and use the container to execute the task. If the active pool 140A does not contain any instances currently assigned to the user, the worker manager 140 pulls a new virtual machine instance from the warming pool 130A, assigns the instance to the user associated with the request, creates a new container on the instance, assigns the container to the request, and causes the user code to be downloaded and executed on the container”; It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Brooker into teachings of Raviv and Baddourah to executing idempotent code in an on-demand code execution system in a manner that increases the efficiency and reduces execution redundancy between multiple requests to execute idempotent code, for example, by implementing “memorization” for executions of the code on the on-demand code execution system. [Brooker col lines 1-10]. Pertinent arts: US11748236B2: The multi-user debugging environment described herein provides for developers with different components to debug a function sequentially while also providing for local visibility of code between components based on authority control. US20180129584A1: A described technique includes a collaborative debugging, by generating a session for an application executing on a remote debugging system. During the session, one or more application inputs for the application can be received from one or more remote users. Outputs that are generated by the application can be provided for presentation to the one or more remote users. US20100057865A1: Transferring debug session between different developer using different target machine. Conclusion THIS ACTION IS MADE FINAL. 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. Contact Information Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRAHIM BOURZIK whose telephone number is (571)270-7155. The examiner can normally be reached Monday-Friday (8-4:30). Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Y Mui can be reached at 571-270-2738. 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. /BRAHIM BOURZIK/ Examiner, Art Unit 2191 /WEI Y MUI/ Supervisory Patent Examiner, Art Unit 2191
Read full office action

Prosecution Timeline

Show 1 earlier event
Nov 07, 2024
Non-Final Rejection mailed — §103, §112
Feb 07, 2025
Response Filed
May 05, 2025
Final Rejection mailed — §103, §112
Sep 05, 2025
Request for Continued Examination
Sep 19, 2025
Response after Non-Final Action
Dec 01, 2025
Non-Final Rejection mailed — §103, §112
Mar 02, 2026
Response Filed
May 08, 2026
Final Rejection mailed — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12669988
SYSTEMS AND METHODS FOR UPDATING INFORMATION HANDLING SYSTEMS AT A REMOTE NETWORK LOCATION FROM THE UPDATE REPOSITORY
3y 6m to grant Granted Jun 30, 2026
Patent 12669994
PHYSICAL NODE OPTIMIZER IN A CONTAINERIZED APPLICATION MANAGEMENT SYSTEM
3y 0m to grant Granted Jun 30, 2026
Patent 12657112
INTEGRATED SYSTEM FOR ASSESSING APPLICATION FITNESS
3y 2m to grant Granted Jun 16, 2026
Patent 12645570
METHOD AND SYSTEM FOR OPTIMIZING TESTING AND DEPLOYMENT OF AN APPLICATION
3y 4m to grant Granted Jun 02, 2026
Patent 12619520
Software Engineering with Machine-Readable Feature Specifications
3y 0m to grant Granted May 05, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

5-6
Expected OA Rounds
64%
Grant Probability
99%
With Interview (+44.0%)
3y 6m (~0m remaining)
Median Time to Grant
High
PTA Risk
Based on 385 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month