Prosecution Insights
Last updated: October 02, 2026
Application No. 18/537,632

ELECTRONIC DEVICE, GENERATION METHOD FOR SOFTWARE CODE AND ANALYZATION METHOD FOR TEST COVERAGE

Non-Final OA §103
Filed
Dec 12, 2023
Priority
Mar 27, 2023 — RE 10-2023-0039580
Examiner
BERMAN, STEPHEN DAVID
Art Unit
2192
Tech Center
2100 — Computer Architecture & Software
Assignee
Samsung Electronics Co., Ltd.
OA Round
1 (Non-Final)
78%
Grant Probability
Favorable
1-2
OA Rounds
0m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 78% — above average
78%
Career Allowance Rate
269 granted / 343 resolved
+23.4% vs TC avg
Strong +58% interview lift
Without
With
+58.3%
Interview Lift
resolved cases with interview
Typical timeline
2y 8m
Avg Prosecution
21 currently pending
Career history
374
Total Applications
across all art units

Statute-Specific Performance

§101
13.2%
-26.8% vs TC avg
§103
48.4%
+8.4% vs TC avg
§102
14.3%
-25.7% vs TC avg
§112
17.5%
-22.5% vs TC avg
Black line = Tech Center average estimate • Based on career data from 343 resolved cases

Office Action

§103
DETAILED ACTION The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Election/Restrictions Applicant's election with traverse of claims 13-20 in the reply filed on August 4, 2026, is acknowledged. The traversal is on the ground(s) that there is no serious search burden because “Groups I, II and III are all classified in the same class (class G06F11), and that Groups II and III are both further classified in the same class (class G06F8)”.1 This is not found persuasive for two reasons. First, G06F11 covers a huge number of technological fields, and thus classification of applications is further broken down into narrower classifications to make searching practical. As seen in the Restriction Requirement, Examiner indicated at least one classification for each of the inventions that are not applicable to the other two groups (G06F11/3688 for Group I, G06F8/41 and G06F11/3604 for Group II, and G06F8/61 for group 1). Thus, the field of search for each of the inventions would be different, which presents a serious search burden. For the same reason, the fact that Groups II and III are in G06F8 does not mean that there is not a serious search burden. The requirement is still deemed proper and is therefore made FINAL. Examiner Notes Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner. Claim Objections Claims 1-12 objected to because of the following informalities: With respect to claim 1-12, pursuant to Applicants Response to Election/Restriction filed on August 4, 2026, claims 1-12 are withdrawn. However, the status of these claims as of August 4, 2026, incorrectly states “Original” rather than “Withdrawn”. Appropriate correction is required. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 13 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Chopra et al. (US 10146668 B1, hereinafter Chopra) in view of Oguara et al. (US 20230025441 A1, hereinafter Oguara) and Li et al. (US 20090249309 A1, hereinafter Li). With respect to claim 13, Chopra discloses An analyzation method for a test coverage (e.g., col. 3:5-7, There are at least two methodologies of running code coverage test cases through the intelligent code coverage tool; col. 5:41-42, FIG. 4 and FIG. 5 together show an operation sequence of the intelligent code coverage tool.), the method comprising: software code including a plurality of test positions and when a target test position among the plurality of test positions is executed, instructing to mark a memory position corresponding to the target test position in an allocated memory region, in an electronic device (e.g., Figs. 1-5 and associated text, e.g., col. 2:37-41, For code coverage testing of programs in the application code base 31, the code coverage tool 33 has intelligence for determining an appropriate test case scenario from predefined test cases in order to maximize the coverage; col. 3:19-23, During any code coverage run, a coverage bitmap 38 is maintained in the random access memory 27. The code coverage run sets a respective bit in the coverage bitmap 38 to record that a function, condition, or statement of interest has been executed or achieved during the code coverage run; col. 4:43-49, The modified compiler and linker 52 is used to compile and link executable files mapped to areas and functions upon which code coverage testing is to be applied. The modified compiler 52 inserts assembly or machine-level instructions that set the flags in the coverage bitmap (38 in FIG. 1) during application program execution of the code coverage run; Examiner notes that “when a target test position among the plurality of test positions is executed, instructing to mark a memory position corresponding to the target test position in an allocated memory region, in an electronic device” is a contingent limitation that need not occur and thus is not required under the broadest reasonable interpretation of the claim (see MPEP § 2111.04). However, for the purposes of compact prosecution only, Examiner has illustrated that the limitation is taught by the cited reference.); providing a command to the electronic device according to a test scenario (Id.; see also col. 3:33-34, executes the test case scenario.); obtaining test coverage data of the allocated memory region from the electronic device (e.g., Figs. 1-5 and associated text, e.g., col. 3:19-41, During any code coverage run, a coverage bitmap 38 is maintained in the random access memory 27. The code coverage run sets a respective bit in the coverage bitmap 38 to record that a function, condition, or statement of interest has been executed or achieved during the code coverage run … the coverage counter can be incremented at the end of the run (or when the run is temporarily suspended) while scanning the bits in the coverage bitmap 36 for the functions of interest.); and analyzing a test coverage using the test coverage data and metadata indicating a mapping information between a plurality of memory positions of the test coverage data and the plurality of test positions (Id.; col. 3:32-36, the percentage of code coverage is computed by dividing the code coverage count for the functions by the total number of the functions, and multiplying the quotient by one-hundred … the coverage counter can be incremented at the end of the run (or when the run is temporarily suspended) while scanning the bits in the coverage bitmap 36 for the functions of interest.). Chopra does not appear to disclose the following, which is taught in analogous art, Oguara: installing (e.g., Fig. 2 and associated text, e.g., [0062] In turn, code coverage analysis 202 comprises configure 204, instrument and install 206, run tests 208, and analyze and report 210.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Chopra with the invention of Oguara, because installing an executable is a well-known and effective means of preparing software for execution. Chopra does not appear to disclose the following, which is taught in analogous art, Li: determined based on control flow analysis (e.g., Figs. 8-9 and associated text, e.g., [0022] The illustrative embodiment employs a recursive method that identifies the set of super nested blocks while traversing a control-flow graph. The method can be performed on a control-flow graph that has already been derived from a program, or it can advantageously be performed while the control-flow graph is itself being constructed during parsing of the program. Once the super nested blocks of a program have been determined, a probe is inserted into each innermost layer of basic blocks. The outer-layer blocks' coverage information can be inferred from those probes. The resulting instrumentation enables execution coverage information to be obtained for every node and arc in the control-flow graph, with a minimum number of probes; see also [0023], [0040], [0061], [0071], [0080].). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chopra with the invention of Li because it “minimizes instrumentation overhead that can slow down program execution,” as suggested by Li (see [0020]). With respect to claim 18, Chopra also discloses wherein the analyzing a test coverage comprises: identifying tested positions and untested positions among the plurality of test positions (e.g., Figs. 1-5 and associated text, e.g., col. 3:31-46, At the end of the run, the percentage of code coverage is computed by dividing the code coverage count for the functions by the total number of the functions, and multiplying the quotient by one-hundred … the coverage counter is incremented at the end of the run while scanning the bits in the coverage bitmap 36 to count the number of bits that have been set for the functions of interest.); and determining a ratio of tested positions among the plurality of test positions as a test coverage value (Id., particular, the percentage of code coverage is computed by dividing the code coverage count for the functions by the total number of the functions.). With respect to claim 19, Chopra also teaches , and the analyzing a test coverage comprises: determining a ratio of tested positions among the plurality of test positions as a statement coverage value (e.g., Figs. 1-5 and associated text, e.g., col. 3:31-46, At the end of the run, the percentage of code coverage is computed by dividing the code coverage count for the functions by the total number of the functions, and multiplying the quotient by one-hundred.) and Li further teaches wherein each of a plurality of basic blocks determined according to the control flow analysis includes a test position (e.g., Fig. 8 and associated text, e.g., [0022], Once the super nested blocks of a program have been determined, a probe is inserted into each innermost layer of basic blocks; [0044], The second task of the method checks whether the current super nested block (at this point, SNB1) has any branching statements. If not (i.e., the super nested block comprises a single node of the control-flow graph, and is thus simply a basic block), the single node is marked "probe-needed"; see also [0045] and [0050].). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chopra with the invention of Li for the same reason set forth above. With respect to claim 20, Chopra also discloses wherein the test coverage data includes a bitmap, and the metadata includes a mapping information between the plurality of bits and the plurality of test positions (e.g., Figs. 1-5 and associated text, e.g., col. 3:19-41, During any code coverage run, a coverage bitmap 38 is maintained in the random access memory 27. The code coverage run sets a respective bit in the coverage bitmap 38 to record that a function, condition, or statement of interest has been executed or achieved during the code coverage run.). Claims 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Chopra in view of Oguara and Li, as applied to claim 13 above, and further in view of Yehia, “UCIS Applications: Improving Verification Productivity, Simulation Throughput, and Coverage Closure Process” (hereinafter Yehia). With respect to claim 14, Chopra also discloses wherein the obtaining test coverage data of the allocated memory region from the electronic device is performed of the electronic device, and the analyzation method for a test coverage further comprises: calculating a test coverage value based on the test coverage data obtained (e.g., Figs. 1-5 and associated text, e.g., col. 3:15:-41, For any particular code coverage run, the user may specify target percentages (e.g., 70%) of code coverage for functions, conditions, or statements, and the run terminates once the run achieves the specified target percentages. During any code coverage run, a coverage bitmap 38 is maintained in the random access memory 27. The code coverage run sets a respective bit in the coverage bitmap 38 to record that a function, condition, or statement of interest has been executed or achieved during the code coverage run … the coverage counter can be incremented at the end of the run (or when the run is temporarily suspended) while scanning the bits in the coverage bitmap 36 for the functions of interest.).). Chopra does not appear to disclose the following, which is taught in analogous art, Yehia: periodically during a runtime … during the runtime … periodically (e.g., pp. 10-11, 1. Guiding test behavior at runtime … On the fly change tests’ runtime behavior upon collected coverage analysis … Monitor achieved coverage … int checkCoverGoalMet … return(*scopecoverscore*100 >=scopecovergoal);} … //Coverage score monitor loop.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chopra with the technique of Yehia because it can provide “faster coverage closure”, “improve test efficiency”, and allow for “On the fly change [of] tests’ runtime behavior upon collected coverage analysis”, as suggested by Yehia (see p. 7, p. 8, and p. 10). With respect to claim 15, Chopra also discloses when the calculated test coverage value a threshold value, terminating a test according to the test scenario (e.g., Figs. 1-5 and associated text, e.g., col. 3:15:-41, For any particular code coverage run, the user may specify target percentages (e.g., 70%) of code coverage for functions, conditions, or statements, and the run terminates once the run achieves the specified target percentages.) and Yehia further teaches exceeds (e.g., pp. 10-11, 1. Guiding test behavior at runtime … On the fly change tests’ runtime behavior upon collected coverage analysis … Monitor achieved coverage … int checkCoverGoalMet … return(*scopecoverscore*100 >=scopecovergoal);} … //Coverage score monitor loop.) (Examiner notes that “when the calculated test coverage value exceeds a threshold value, terminating a test according to the test scenario” is a contingent limitation that need not occur and thus is not required under the broadest reasonable interpretation of the claim (see MPEP § 2111.04). However, for the purposes of compact prosecution only, Examiner has illustrated that the limitation is taught by the cited combination.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chopra with the technique of Yehia for the same reason set forth above. Claims 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Chopra in view of Oguara and Li, as applied to claim 13 above, and further in view of Clark et al. (US 20170192878 A1, hereinafter Clark). With respect to claim 16, Chopra does not appear to disclose the following, which is taught in analogous art, Clark: providing a clear command of instructing the test coverage data to be initialized, to the electronic device (e.g., Fig. 1 and associated text, e.g., [0043], between each test, the agent 140 reads out the data to other memory 160 and resets the counters 130. Because the agent 140 resets all of the coverage counters 130 to a default (uncovered) state at the end of each test; subsequent tests accumulate coverage from a ‘clean slate’.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chopra with the invention of Clark because it would allow for further testing that reuses the storage allocated for coverage information, which is an efficient use of storage. With respect to claim 17, Clark further teaches wherein the providing a clear command is performed whenever the analyzing a test coverage is terminated for one test scenario (e.g., Fig. 1 and associated text, e.g., [0043], between each test, the agent 140 reads out the data to other memory 160 and resets the counters 130. Because the agent 140 resets all of the coverage counters 130 to a default (uncovered) state at the end of each test; subsequent tests accumulate coverage from a ‘clean slate’.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Chopra with the invention of Clark for the same reason set forth above. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Specifically, Ahmed et al. “BigMap: Future-proofing Fuzzers with Efficient Large Maps” teaches executing a test case and recording the edge hit counts on the bitmap. Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEPHEN DAVID BERMAN whose telephone number is (571) 272-7206. The examiner can normally be reached M-F, 9-6 Eastern. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung S. Sough can be reached on 571-272-6799. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /STEPHEN D BERMAN/ Examiner, Art Unit 2192 1 See Applicant’s Remarks at p. 9,
Read full office action

Prosecution Timeline

Dec 12, 2023
Application Filed
Aug 25, 2026
Non-Final Rejection mailed — §103
Sep 18, 2026
Interview Requested

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12743274
CHAINED PULL REQUESTS IN A SOURCE CODE MANAGEMENT SYSTEM
3y 11m to grant Granted Sep 22, 2026
Patent 12724688
CHAOS EVENT TESTING USING SIMULATED TRAFFIC FEED AND CHAOS EVENTS SIMULTANEOUSLY
3y 2m to grant Granted Sep 01, 2026
Patent 12710959
EXTRACTING ENTITY RELATIONSHIP DIAGRAMS FROM SOURCE CODE
4y 8m to grant Granted Aug 18, 2026
Patent 12675269
CONTAINERIZED, DECENTRALIZED, AND DISTRIBUTED WEB APPLICATIONS WITH END-TO-END ENCRYPTION
2y 9m to grant Granted Jul 07, 2026
Patent 12664069
CODE CONCIERGE MODEL (CCM) FOR PREDICTING RUNTIME ERRORS OF SOURCE CODE
3y 1m to grant Granted Jun 23, 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

1-2
Expected OA Rounds
78%
Grant Probability
99%
With Interview (+58.3%)
2y 8m (~0m remaining)
Median Time to Grant
Low
PTA Risk
Based on 343 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