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 to 20 are presented for examination.
Priority
Receipt is acknowledged of papers submitted under 35 U.S.C. 119, which papers have been placed of record in the file.
Information Disclosure Statement
The references listed in the information disclosure statement submitted on 10-08-2024 have been considered by the examiner (see attached PTO-1449).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 to 2, 5 to 9, 11 to 12, and 15 to 19 are rejected under 35 U.S.C. 103 as being unpatentable over Krishnaswamy et al. (USPAP 2004/0225459).
Claim 1:
Krishnaswamy substantially teaches the claimed invention. Krishnaswamy teaches a method and a structure to develop test programs for semiconductor integrated circuits, the method comprising: a system controller (106) that serves as the overall system manager, coupled to a site controller (104) and manages system-level parallel test strategies (see par. 0034). Krishnaswamy teaches that a site controller (104) executes a test plan flow based on a test plan server sending instructions to start testing a device under test (DUT) (see par. 0494 to 0499).
Krishnaswamy teaches that the device test data is DUT-dependent i.e., power supply conditions, signal voltage conditions, timing conditions, etc. and device-specific data or device-test-specific data are specified in the test plan (see par. 0057 et seq.). Krishnaswamy teaches that a functional test for DUTs is performed executing the test plan and determining the status of the test based of failed strobes (see par. 0058).
Krishnaswamy teaches that each test site (110) is dedicated to testing one or more DUTs and their functions through a configurable collection of test modules (112) and the test module could be a DUT power supply (“unit under test”) (see par. 0062). Krishnaswamy teaches that each hardware module provides one or more types of hardware resources for use by the test system (see par. 0084). Krishnaswamy teaches that Dps (device power supply) pin resources have special parameters such as pre_wait and post_wait and specifies the time that needs to elapse from the time the power pin has reached its destination voltage. Which reads on “determining, by the device under test, whether a system time of the device under test corresponds to the test time” (see par. 0034 and 0084).
Krishnaswamy teaches that the principal component of the programming environment is the test plan, and the test plan is written directly by a user using C++ (see par. 0176-0177). Krishnaswamy teaches that a test program generator produces C++ code that is compiled into executable test program wherein the test program contains a set of user written files that specify details for running a test on a device (see par. 0178). Krishnaswamy teaches that the test program comprises a set of files including timing (files *.tim), test plan (files *.tpl) (“test instruction”) (see par 0179 to 0189).
Krishnaswamy fails to specifically teach the limitation of “when the system time corresponds to the test time, controlling the unit under test according to the test instructions and recording a test result of the unit under test executing the test instructions;” however, these teachings are obvious to the teachings of Krishnaswamy because Krishnaswamy teaches that a system controller manages the test system by providing controls through a site controller to perform testing of connected DUTs (see par. 0034 et seq.). Krishnaswamy also teaches that during the course of testing a DUT, the DUT can be set to any bin to indicate the result of a particular test (see par. 0393). Krishnaswamy further teaches that a pattern generator (1002) generates a timing set which is common for all the pins in the module, this timing is called global timing set (GTS) and is used to get the results of a test (see par. 1017 et al.).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of developing a test program to test the DUT to include the claimed limitation of: “when the system time corresponds to the test time, controlling the unit under test according to the test instructions and recording a test result of the unit under test executing the test instructions” because Krishnaswamy teaches a method and a structure for easy development of test programs for an open architecture test system comprises a generalized architecture using timing data to test DUTs and using a global timing set to get the test result. This modification would have been obvious because a person of ordinary skill in the art would have been motivated to employ a method and a structure for easy development of test programs and specifying a test plan for testing DUTs using timing data as taught by Krishnaswamy (see par. 1017).
As per claim 2, Krishnaswamy teaches that the test program comprises test conditions (see par. 0013 and 0056). Krishnaswamy fails to specifically teach the limitation of “when the system time corresponds to the test time, determining whether an operating status of the device under test satisfies the test condition, wherein when the operating status satisfies the test condition, the unit under test executes the test instruction.” However, this teaching is obvious to the teachings of Krishnaswamy because Krishnaswamy teaches that the device test data is DUT-dependent and the test code consists of methods to load the specified device conditions on the ATE hardware (see par. 0056). Krishnaswamy teaches that the test environment comprises a set of files that specify the necessary conditions for bringing up the tester, and for preparing it to run a set of tests (see par. 0073).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of developing a test program to test the DUT to include the claimed limitation of: “when the system time corresponds to the test time, determining whether an operating status of the device under test satisfies the test condition, wherein when the operating status satisfies the test condition, the unit under test executes the test instruction” because Krishnaswamy teaches that a method and a structure for easy development of test programs for an open architecture test system comprises determining the status of the test based on the presence of failed strobes also when the test is executed, it sends status message back to all connected applications. This modification would have been obvious because a person of ordinary skill in the art would have been motivated to employ a method and a structure for easy development of test programs that provides status messages to all connected application on the execution of the test plan as taught by Krishnaswamy (see par. 1095).
As per claims 5 and 6, Krishnaswamy teaches that the test plan is provided through a test plan server (TPS) located in the site controller and executes a test plan event following a flow control (see par. 0494). Krishnaswamy teaches under the test plan start/end flow, the site controller executes through the test plan server instruction to start executing the current test flow and when that flow finishes its execution (see par. 0499). Krishnaswamy teaches that the test plan server on each site controller is ultimately responsible for containing and executing the user’s test plan (see par. 1053).
As per claim 7, Krishnaswamy teaches that each test site (110) is dedicated to testing one or more DUTs (106) and its functions through a configurable collection of test modules (112) and wherein a test module could be a DUT power supply, a pin card, an analog card, etc. (see par. 0062). Krishnaswamy teaches that vendor specific module software uses a backplane driver (250) to communicate with corresponding hardware modules (see par. 0064). Krishnaswamy teaches that the test environment comprises a set of files (“trigger program”) that specify the necessary conditions for bringing up the tester (see par. 0073). Krishnaswamy teaches that a test program contains a set of user written files that specify details for running a test on a device (see par. 0178 et seq.).
As per claim 8, Krishnaswamy teaches that the test system comprises a selector for specifying a test condition (see par. 0013 and 0299). Krishnaswamy teaches that a test plan (242) is written by a user using C++ code and a compiler links the code into executable test program (see par. 0051 and 0176). Krishnaswamy teaches that the program code is data for the device test and the test code consists of methods to load the specified device conditions no to ATE hardware (see par. 0554). Krishnaswamy teaches that each test site is dedicated to testing one or more DUTs and functions through a configurable collection of test modules (see par. 0062). Krishnaswamy teaches that a user can customize a test with custom functions (see par. 0593 et seq.).
As per claim 9, Krishnaswamy teaches that functional testing for the DUT’s is handled by the site controller and a standard functional test interface (see par. 0049 and 0058). Krishnaswamy teaches that a user-developed test class incorporate additional functionality into their test classes (see par. 0061).
Claim 11:
Krishnaswamy substantially teaches the claimed invention. Krishnaswamy teaches a method and a structure to develop test program for semiconductor integrated circuits, the structure comprising: a system controller (106) coupled to a site controller (104) that is coupled to DUT’s via of test site (110) (see par. 0034). Krishnaswamy teaches that each site controller can be deployed on its own dedicated CPU (see par. 0034). Krishnaswamy teaches that a site controller (104) executes a test plan flow based on a test plan server that sends instruction to start testing a device under test (DUT) (see par. 0494 to 0499).
Krishnaswamy teaches that a predefined flow defines a sequence of tests as a result of an event occurring in a test plan server (TPS) and executes the test plan event (“test event is triggered”) (see par. 0494). Krishnaswamy teaches that a test plan developer defines actions that originate from the system controller (see par. 0495). Krishnaswamy teaches that the test environment comprises a set of files (“trigger program”) that specify the necessary conditions for bringing up the tester (see par. 0073). Krishnaswamy teaches that the pattern generator generates a timing set which is common for all the pins in the module and the timing set is called global timing set (see par. 1017). Krishnaswamy teaches that a capture flag is used in the pattern file to instruct the tester to capture or mask the results (see par. 1017).
Krishnaswamy fails to specifically teach a device under test comprising a processing unit, a unit under test, and a memory unit; however, this teaching is obvious to the teachings of Krishnaswamy since, Krishnaswamy teaches that a method and a structure for developing testing programs written in a general purpose language, tests an IC (integrated circuit) chip (DUT) on a semiconductor test system and utilizes files containing the test plans that are stored in memory that is accessible to the test system.
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the structure of developing a test program to test the DUT to include the claimed limitation of: “a device under test comprising a processing unit, a unit under test, and a memory unit,” because Krishnaswamy teaches that a method and a structure for easy development of test programs for an open architecture test system comprises developing test plans for an IC chip on a semiconductor and storing the files containing the testing plans in a memory that is accessed by the testing system. This modification would have been obvious because a person of ordinary skill in the art would have been motivated to employ a method and a structure for easy development of test programs that can customize the DUT as taught by Krishnaswamy (see par. 0008).
As per claim 12, Krishnaswamy teaches that the test program comprises test conditions (see par. 0013 and 0056). Krishnaswamy fails to specifically teach the limitation of “when the system time corresponds to the test time, determining whether an operating status of the device under test satisfies the test condition, wherein when the operating status satisfies the test condition, the unit under test executes the test instruction.” However, this teaching is obvious to the teachings of Krishnaswamy because Krishnaswamy teaches that the device test data is DUT-dependent and the test code consists of methods to load the specified device conditions on the ATE hardware (see par. 0056). Krishnaswamy teaches that the test environment comprises a set of files that specify the necessary conditions for bringing up the tester, and for preparing it to run a set of tests (see par. 0073).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of developing a test program to test the DUT to include the claimed limitation of: “when the system time corresponds to the test time, determining whether an operating status of the device under test satisfies the test condition, wherein when the operating status satisfies the test condition, the unit under test executes the test instruction” because Krishnaswamy teaches that a method and a structure for easy development of test programs for an open architecture test system comprises determining the status of the test based on the presence of failed strobes also when the test is executed, it sends status message back to all connected applications. This modification would have been obvious because a person of ordinary skill in the art would have been motivated to employ a method and a structure for easy development of test programs that provides status messages to all connected application on the execution of the test plan as taught by Krishnaswamy (see par. 1095).
As per claims 15 and 16, Krishnaswamy teaches that the test plan is provided through a test plan server (TPS) located in the site controller and executes a test plan event following a flow control (see par. 0494). Krishnaswamy teaches under the test plan start/end flow, the site controller executes through the test plan server instruction to start executing the current test flow and when that flow finishes its execution (see par. 0499). Krishnaswamy teaches that the test plan server on each site controller is ultimately responsible for containing and executing the user’s test plan (see par. 1053).
As per claim 17, Krishnaswamy teaches that each test site (110) is dedicated to testing one or more DUTs (106) and its functions through a configurable collection of test modules (112) and wherein a test module could be a DUT power supply, a pin card, an analog card, etc. (see par. 0062). Krishnaswamy teaches that vendor specific module software uses a backplane driver (250) to communicate with corresponding hardware modules (see par. 0064). Krishnaswamy teaches that the test environment comprises a set of files (“trigger program”) that specify the necessary conditions for bringing up the tester (see par. 0073). Krishnaswamy teaches that a test program contains a set of user written files that specify details for running a test on a device (see par. 0178 et seq.).
As per claim 18, Krishnaswamy teaches that the test system comprises a selector for specifying a test condition (see par. 0013 and 0299). Krishnaswamy teaches that a test plan (242) is written by a user using C++ code and a compiler links the code into executable test program (see par. 0051 and 0176). Krishnaswamy teaches that the program code is data for the device test and the test code consists of methods to load the specified device conditions no to ATE hardware (see par. 0554). Krishnaswamy teaches that each test site is dedicated to testing one or more DUTs and functions through a configurable collection of test modules (see par. 0062). Krishnaswamy teaches that a user can customize a test with custom functions (see par. 0593 et seq.).
As per claim 19, Krishnaswamy teaches that functional testing for the DUT’s is handled by the site controller and a standard functional test interface (see par. 0049 and 0058). Krishnaswamy teaches that a user-developed test class incorporate additional functionality into their test classes (see par. 0061).
Allowable Subject Matter
Claims 3 to 4, 10, 13 to 14 and 20 are objected to as being dependent upon a rejected base claim, 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.
Richter et al. (USPAP 2012/0010857) discloses a method and an apparatus for complex time measurements in automatic test equipment.
Logisch (USPAP 2003/0030427) teaches testing apparatus for testing device under test.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHELLY A CHASE whose telephone number is (571)272-3816. The examiner can normally be reached Mon-Thu 8:00-5:30, 2nd Friday 8:00-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, Albert Decady can be reached at 571-272 3819. 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.
/Shelly A Chase/ Primary Examiner, Art Unit 2112