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 .
This Office Action is in response to amendment filed on March 26, 2026.
Claims 1, 3, 7, 8, 11, 17, 18, and 20 have been amended.
The objections and rejections from the prior correspondence that are not restated herein are withdrawn.
Response to Arguments
Applicant's arguments filed on March 26, 2026 with respect to claim(s) 1, 11, and 20 have been considered but are moot because the arguments allege that only the newly added limitations are not taught by the prior art of record. It should be noted that a new prior art reference to LAMBERT in combination with KARPAGAVINAYAGAM teaches the newly added limitations as shown in the rejections below. Additionally, the new limitations added to the independent claims constitute new matter and are rejected under 112(a) as outlined below.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claims 1, 11, and 20, the claim limitations determine that the information handling system is suitable for delivery to an end user when the first value is within the first range, and to determine that the information handling system is not suitable for delivery to the end user when the first value is not within the first range and during a user boot phase of operation of the information handling system to reinitialize the first parameter with a second value are not supported in the specification, and therefore, constitute new matter. If Applicant disagrees that the above limitations in claims 1, 11, and 20 are not supported in Applicant’s specification, Applicant must explicitly point to the exact location of Applicant’s specification and explain how it supports the claim limitation.
Dependent claims inherit the deficiencies of the respective parent claim.
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 1, 7, 8, 10, 11, 17, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over KARPAGAVINAYAGAM (Pub. No.: US 20190171507 A1), hereafter KARPAGA, in view of LAMBERT (Pub. No.: US 20200218613 A1), hereafter LAMBERT.
Regarding claim 1, KARPAGA teaches:
An information handling system comprising; a baseboard management controller (BMC) (see KARPAGA FIG 1. computing system 100 & BMC 102);
a first I/O device (KARPAGA FIG. 1, memory 184 on host 180);
and a Basic Input/Output System (BIOS) executed by a processor separately from the BMC (KARPAGA FIG. 1, CPU 182 on host 180, separate from BMC 102; [0026] teaches the host CPU 182 loads an initialization component 192 (e.g., a basic input/output system (BIOS)) from the storage devices 185 into the host memory 184),
and configured […] to initialize a first parameter of the first I/O device with a first value (KARPAGA [0026], [0031], and [0036] teach POST used to initialize the standard system components, and performs reliability test via SMI handlers and system management mode [i.e., health check, see [0031] "the host CPU 182 can be interrupted to enter a system management mode (SMM)… when the host CPU 182 enters the SMM, the host CPU 182 executes the SMI handler 202 stored at the pre-configured location. The SMI handler 202 can be considered as part of the initialization component 192.", i.e., SMI handler is part of the BIOS], generate error and trigger SMI; and [0026] teaches the POST initializes the standard system components and sets the default values [i.e., initializes first parameters] for a table of interrupt vectors, default values point to standard interrupt handlers in the memory 114 or a ROM),
wherein the BIOS includes an I/O health check module configured, [when] the BIOS initializes the first parameter, to receive the first value, to determine whether the first value is within a first range of first values (KARPAGA [0026], [0031], and [0036] teach POST used to initialize the standard system components, and performs reliability test [i.e., receive first values, see [0031], initialization component 192 can gather health status [i.e., first values] of those hardware components, also see [0037], severity of the errors may be used to reflect the hardware health status (e.g., “OK,” “Warning,” or Critical) [i.e., range of first values]], test may generate error, and trigger SMI)),
to determine that the information handling system is suitable for [use] when the first value is within the first range, and to determine that the information handling system is not suitable for [use] when the first value is not within the first range (KARPAGA [0037] teaches error information is used to determine severity of the errors (e.g., “OK,” “Warning,” or Critical) [i.e., range of first values]; [0040] teaches e.g., based on the warning, the defective hardware component can be removed and replaced by another working component [i.e., component within a first range of errors is suitable, but a different range of errors is unsuitable]),
and is further configured during a user boot phase of operation of the information handling system to reinitialize the first parameter with a second value, wherein the I/O health check module is further configured to receive the second value and to provide the second value to the BMC (KARPAGA [0026], [0031], and [0036] teach POST [i.e., during boot] used to initialize the standard system components, and performs reliability test via SMI handlers [i.e., refreshing health values for new instance of test, i.e., second value replaces first value] and system management mode [i.e., the health check is performed and values initialized and passed to BMC during boot]);
wherein the BMC is configured to log the second value each time the BIOS initializes the first parameter (KARPAGA [0040] teaches host health monitor 136 (which is a part of the BMC) can store the health data in a data store (e.g., a database) on the BMC 102 [i.e., logging]; and [0038] teaches health data includes the identity of the hardware component (e.g., the host CPU 182) for which the health data were generated, the type of health condition (e.g., thermal or power), the severity of the health condition (e.g., low, medium, or high), health condition data (e.g., the actual temperature of the host CPU 182), etc.; also see FIG. 3, step 328 store health data in data store),
to determine that the second value represents a first excursion from a third value received during a prior initialization of the first parameter (KARPAGA [0040] teaches the host health monitor 136 can further analyze the health data of a period of time stored in the data store [i.e., prior initializations (which may be a second value), see [0031], SMI handler 202 can be considered as part of the initialization component 192, and [0038] teaches SMI handler 202 can use a message defined by the management protocol to send the health data [i.e., first values] to the BMC 102, and [0040] teaches host health monitor 136 (on BMC 102) can store the health data in a data store after receiving health data, i.e., the data store contains health data from prior initializations, also see process at FIG. 3]; and [0047] teaches the service processor determines that a first hardware component of the at least one hardware components is defective based on the health data in the data store [i.e., prior initializations, see above]... in certain configurations, the first hardware component is determined to be defective based on a number of times the first hardware component has been in the one or more predetermined health conditions [i.e., determine excursions from a “healthy” initialization]),
to determine a health status for the information handling system based upon the first excursion (KARPAGA [0046] teaches the initialization component operates in the system management mode and obtains the health data, then [0047] teaches the service processor receives the message from the initialization component and analyzes the health data and determine if at least one hardware components is defective),
and to provide an indication of the health status (KARPAGA FIG. 3, step 320 and 322, initialization component sends message (i.e., indication) with included health data to the host (also see [0046]); and [0040] teaches the host health monitor 136 may determine that the particular hardware component is defective and generate a warning for that particular hardware component).
KARPAGA does not appear to explicitly teach: a Basic Input/Output System (BIOS)… configured during a manufacturing phase of operation of the information handling system to initialize a first parameter of the first I/O device with a first value; to determine that the information handling system is suitable for delivery to an end user when the first value is within the first range, and to determine that the information handling system is not suitable for delivery to the end user when the first value is not within the first range…; wherein the BMC is configured to log the first value each time the BIOS initializes the first parameter.
However, LAMBERT teaches a Basic Input/Output System (BIOS)… configured during a manufacturing phase of operation of the information handling system to initialize a first parameter of the first I/O device with a first value (LAMBERT [0004] teaches processor complex may provide boot status information in response to a system boot process… determine first boot status difference information, compare the first boot status difference information to baseline boot status difference information to determine that the information handling system experienced an anomaly, where [0028] teaches first-time boot of information handling system 200 (see [0012], IHS contains BIOS module for boot) can be supplemented by other boots of the information handling system in a characterization operation, such as during the manufacturing of the information handling system; and LAMBERT [0029] teaches status analysis engine 229 then compares the production differences with the baseline differences to identify if the particular system boot process has experienced any behaviors which can be characterized as anomalous behaviors (e.g., a particular boot task may take an unusually long time to perform, or a temperature rise associated with another boot task may be greater than usual, i.e., a first parameter is tracked));
to determine that the information handling system is suitable for delivery to an end user when the first value is within the first range, and to determine that the information handling system is not suitable for delivery to the end user when the first value is not within the first range… (LAMBERT [0029] teaches problems with information handling system 200 that are detectable through changing system boot process behaviors may be rapidly identified, and preventive or corrective actions can be taken [i.e., device is deemed unsuitable and a preventative action is taken]; and LAMBERT [0029] teaches e.g., a particular boot task may take an unusually long time to perform, or a temperature rise associated with another boot task may be greater than usual, i.e., a first parameter is not within an acceptable range]);
wherein the BMC is configured to log the first value each time the BIOS initializes the first parameter (LAMBERT [0029] teaches each time information handling system 200 is booted, status analysis engine 229 operates to analyze the boot status information for the particular system boot process).
Accordingly, it would have been obvious to a person having ordinary skill in the art at the time of the effective filing of the invention, having the teachings of A before them, to combine KARPAGA’s method for testing an information handling system with LAMBERT’s additional testing during manufacturing, the motivation being to more accurately determine device functionality (LAMBERT [0028] teaches obtain a baseline status for the IHS; LAMBERT [0029] teaches status analysis engine 229 operates to analyze the boot status information for the particular system boot process).
Regarding claim 11, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale.
Regarding claim 20, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale. KARPAGAVINAYAGAM also teaches:
A manufacturing system (KARPAGA [0029] teaches computer 180 may be a computer system in a data center), comprising; a management system (KARPAGA [0029-0030] teach host computer (i.e., management system) may exchange data with other computer systems in the data center or exchange data with machines on the Internet; and [0030] teaches BMC 102 may be in communication with the communication network 170);
a plurality of information handling systems (KARPAGA [0029] teaches the host computer 180 may be a computer system in a data center and the host computer 180 may exchange data with other computer systems in the data center),
wherein the management system is configured to receive the indications from the BMCs and to determine a manufacturing trend for the information handling systems based upon the indications (KARPAGA [0038] teaches health information includes original equipment manufacturer (OEM) system event log (SEL) and carry a Manufacturer ID, and the health data of the host computer; and [0029-0030] teach the remote device 175 may send IPMI messages to the BMC 102 over the communication network 170, also see [0040], health data can be stored in the communication network 170; and [0040], use data in the database to determine the overall health condition of each of the host CPU 182, the host memory 184, the storage devices 185, and the hardware components 186-1 to 186-N).
Regarding Claim 7, KARPAGA in view of LAMBERT teaches information handling system of claim 1. Claim 7 recites the limitations of claim 1 using an additional parameter.
KARPAGA and LAMBERT both discloses tracking multiple parameters to track overall health of system components (KARPAGA [0062] teaches, BMC 566 monitors health-related aspects associated with the computer system 502, such as, but not limited to, the temperature of one or more components of the computer system 502, speed of rotational components (e.g., spindle motor, CPU Fan, etc.) within the system, the voltage across or applied to one or more components within the system 502, and the available or used capacity of memory devices within the system 502 [also see KARPAGA [0026], POST is used to initialize the standard system components, such as system timers, system DMA (Direct Memory Access) controllers, system memory controllers, system I/O devices and video hardware]; and LAMBERT [0029] teaches status analysis engine 229 compares the production status with the baseline status, and generates production differences for that particular system boot process [i.e., checks multiple boot processes]).
Therefore, the method of claim 1 is carried out by KARPAGA in view of LAMBERT by initializing and monitoring an additional parameter (the second parameter).
The same motivation that was utilized for combining KARPAGA and LAMBERT as set forth in claim 1 is equally applicable to claim 10.
Regarding Claim 8, KARPAGA in view of LAMBERT teaches information handling system of claim 1. Claim 8 recites the limitations of claim 1 using a second I/O device.
KARPAGA discloses tracking multiple I/O devices to track overall health of the system (KARPAGA [0024] teaches system management components 206 monitors the health conditions of the host CPU 182, the host memory 184, the storage devices 185, and the hardware components 186-1 to 186-N).
Therefore, the method of claim 1 is carried out by KARPAGA in view of LAMBERT by initializing and monitoring an additional I/O device (the second I/O device).
The same motivation that was utilized for combining KARPAGA and LAMBERT as set forth in claim 1 is equally applicable to claim 10.
Regarding Claim 10, KARPAGA in view of LAMBERT teaches the elements of claim 1 as outlined above. KARPAGA in view of LAMBERT also teaches:
wherein the indication includes: an alert indication when the parameter value exhibits an excursion from a range that has a first value (LAMBERT [0029] teaches when status analysis engine 229 detects anomalous behaviors in a particular system boot process, the status analysis engine logs the anomalous behaviors and issues an alert [also see [0029], e.g., a particular boot task may take an unusually long time to perform, or a temperature rise associated with another boot task may be greater than usual, i.e., a first parameter is not within an acceptable range]),
a watch indication when the parameter value exhibits the excursion that has a second value greater than the first value, a warning indication when the parameter value exhibits the excursion that has a third value greater than the fourth value (KARPAGA [0038] teaches the severity of the health condition may be indicated (e.g., low, medium, or high) [i.e., severity of indications (alert, watch, warning)]; also see [0037] teaches severity of the errors may be used to reflect the hardware health status “OK,” “Warning,” or “Critical”),
a failure indication when the parameter value exhibits the excursion that has a fourth value greater than the third value (KARPAGA [0037] teaches SMI handler 202 will construct or frame a BMC SEL record that has information of the failed component) [also see [0040], thresholds for indicating health statuses, such as frequency and severity of errors generated by particular a hardware component, when frequency and severity meets predetermined thresholds (e.g., 5 severe errors in 12 hours), the host health monitor 136 may determine that the particular hardware component is defective and generate a warning; also see [0041], e.g., host CPU 182 has reached a critical high temperature based on the health data).
The same motivation that was utilized for combining KARPAGA and LAMBERT as set forth in claim 1 is equally applicable to claim 10.
Regarding Claim 17, the claim is similar in scope to claim 7 as addressed above and is thus rejected under the same rationale.
Regarding Claim 18, the claim is similar in scope to claim 8 as addressed above and is thus rejected under the same rationale.
Claims 2-6, 9, 12-16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over KARPAGA in view of LAMBERT as applied to claims 1 and 11 above, and further in view of CHAIKAN (US 11526411 B2), hereafter CHAIKAN.
Regarding Claim 2, KARPAGA in view of LAMBERT teaches the elements of claim 1 as outlined above. KARPAGA in view of LAMBERT also teaches:
wherein the first I/O device is a […] memory module (KARPAGA [0034] teaches health condition of memory 184 is monitored).
KARPAGA in view of LAMBERT does not explicitly teach: wherein the first I/O device is a dual in-line memory module (DIMM).
However, CHAIKAN teaches memory may be in the form of one or more DDR Dual In-Line Memory Modules (DIMMs) (CHAIKAN Col. 3 lines 5-17, memory channel and memory 120 represents one or more DDR Dual In-Line Memory Modules (DIMMs)).
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of KARPAGA, LAMBERT, and CHAIKAN before them, before the effective filing date of the claimed invention, to combine KARPAGA’s and LAMBERT’s system architecture and functionality with CHAIKAN’s memory form factor, the motivation being to be in accordance with a particular DDR standard (CHAIKAN Col. 3 lines 5-17).
Regarding Claim 3, KARPAGA in view of LAMBERT teaches the elements of claim 2 as outlined above. KARPAGA in view of LAMBERT also teaches:
wherein: the DIMM is a fifth generation double data rate (DDR5) DIMM (CHAIKAN Col. 3 lines 5-17, a DDR channel and the connected DDR DIMMs can be in accordance with a particular DDR standard, such as a DDR5 standard).
The same motivation that was utilized for combining KARPAGA, LAMBERT, and CHAIKAN as set forth in claim 2 is equally applicable to claim 3.
Regarding Claim 4, KARPAGA in view of LAMBERT teaches the elements of claim 3 as outlined above. KARPAGA in view of LAMBERT also teaches:
wherein the parameter includes one of a command/address bus write leveling (LAMBERT [0029] teaches an auxiliary processor (such as co-processor 218) in processor complex 210 can perform bus training during system boot),
a data bus read/write leveling, a timing margin (LAMBERT [0029] teaches timing parameters that may be captured and output on serial interface 214 will be recorded by BMC),
and a read/write voltage margin (KARPAGA [0062] teaches voltage applied).
The same motivation that was utilized for combining KARPAGA, LAMBERT, and CHAIKAN as set forth in claim 2 is equally applicable to claim 4.
Regarding Claim 5, KARPAGA in view of LAMBERT teaches information handling system of claim 1. KARPAGA in view of LAMBERT does not explicitly teach:
wherein the first I/O device is a PCIe device.
However, CHAIKAN teaches the limitaiton (CHAIKAN Col. 3 lines 38-48, I/O channel may link chipset 110 and memory (NV-RAM 140) using PCIe [i.e., first I/O device]).
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of KARPAGA, LAMBERT, and CHAIKAN before them, before the effective filing date of the claimed invention, to combine KARPAGA’s and LAMBERT’s system architecture and functionality with CHAIKAN’s I/O form factor, the motivation being to be in accordance with a particular I/O standards (CHAIKAN Col. 3 lines 42-48).
Regarding Claim 6, KARPAGA in view of LAMBERT teaches the elements of claim 1 as outlined above. KARPAGA in view of LAMBERT does not appear to explicitly teach:
wherein the first I/O device is a SATA device.
However, CHAIKAN teaches the limitation (CHAIKAN FIG. 2, SATA device 240; also see col. 3 lines 55-62, disk controller 150 [i.e., first I/O device] includes a disk interface 152 that connects the disc controller to a hard disk drive (HDD), example of disk interface 152 includes a serial ATA (SATA) interface).
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of KARPAGA, LAMBERT, and CHAIKAN before them, before the effective filing date of the claimed invention, to combine KARPAGA’s and LAMBERT’s system architecture and functionality with CHAIKAN’s I/O form factor, the motivation being to be in accordance with a particular I/O standards (CHAIKAN Col. 3 lines 42-48).
Regarding Claim 9, KARPAGA in view of LAMBERT teaches the elements of claim 8 as outlined above. KARPAGA in view of LAMBERT also teaches:
the first I/O device is a [memory module] (KARPAGA [0034] teaches health condition of memory 184 is monitored);
the second I/O device […] (KARPAGA [0024] teaches system management components 206 monitors the health conditions of the host CPU 182, the host memory 184, the storage devices 185, and the hardware components 186-1 to 186-N).
KARPAGA in view of LAMBERT does not explicitly teach wherein the first I/O device is a DIMM; and the second I/O device is a Peripheral Component Interconnect-Express (PCIe) device.
However, CHAIKAN teaches wherein the I/O devices may be a DIMM or a PCIe device, as addressed with claims 3 and 5 above respectively.
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of KARPAGA, LAMBERT, and CHAIKAN before them, before the effective filing date of the claimed invention, to combine KARPAGA’s and LAMBERT’s system architecture and functionality with CHAIKAN’s I/O form factors, the motivation being to be in accordance with particular I/O standards (CHAIKAN Col. 3 lines 42-48).
Regarding Claim 12, the claim is similar in scope to claim 2 as addressed above and is thus rejected under the same rationale.
Regarding Claim 13, the claim is similar in scope to claim 3 as addressed above and is thus rejected under the same rationale.
Regarding Claim 14, the claim is similar in scope to claim 4 as addressed above and is thus rejected under the same rationale.
Regarding Claim 15, the claim is similar in scope to claim 5 as addressed above and is thus rejected under the same rationale.
Regarding Claim 16, the claim is similar in scope to claim 6 as addressed above and is thus rejected under the same rationale.
Regarding Claim 19, the claim is similar in scope to claim 9 as addressed above and is thus rejected under the same rationale.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 extension fee 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREW J JUNG whose telephone number is 571-270-3779. The examiner can normally be reached on Monday through Friday from 9am to 5pm.
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, David Wiley can be reached on 571-272-4150. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ANDREW J JUNG/Supervisory Patent Examiner, Art Unit 2175
Prosecution Insights