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 .
Claim Objections
Claims 2 and 11 are objected to because of the following informalities:
The claims recite “wherein obtaining the configuration information includes obtaining the information from …”, which is appears to include a typographical error omitting “configuration” from the second mention of “the information”. For the purpose of examination this is being interpreted to read “wherein obtaining the configuration information includes obtaining the configuration information from …”. Appropriate correction is required.
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 6, 7, 15, and 16 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 6, 7, 15, and 16 contain the trademark/trade name “Redfish”. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe the source of the protocol for providing an interface, and, accordingly, the identification/description is indefinite.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-7 and 10-16 are rejected under 35 U.S.C. 103 as being unpatentable over Thomas (US 20180018189 A1) in view of Sharma (US 20220166669 A1).
Regarding Claim 1:
Thomas teaches:
wherein the configuration information includes one or more fixed elements and one or more corresponding variable elements; (¶64 The data store 152 is a database which stores configuration data of the computing device or the device connected to the computing device being simulated by the simulator module 150; ¶64 the configuration parameters of the devices may include device values, and each of the device values may be a static value or a random value within a range, a value obtained from one or more patterns, a value derived from a function of another set of variables, a value set by an administrator, a time-based value, or a value picked from a socket server.)
defining a simulation policy for the resource type, wherein the simulation policy is suitable to generate configuration information for a second instance of the resource type (¶65 the simulation of the simulator library sub-module 154 is performed based on the configuration data stored in the data store 152; ¶65 In response to generating the simulated data, the simulator library sub-module 154 sends the simulated data to the firmware module 140 through the library module 160 for BMC testing and developing. In certain embodiments, the simulator library sub-module 154 may simulate for intelligent devices such as satellite controllers, PSUs, NIC, RAID, CPLD by referring to the data library 152 or to the socket server. In certain embodiments, the simulator library sub-module 154 may simulate devices behind satellite controllers, which are accessed by bridging, by referring to the data library 152 for bridge command for the devices and execute the command. In certain embodiments, more than one simulator library sub-module 154 may co-exist to simulate the different intelligent devices.; ¶70)
providing a management server simulator configured to simulate the second instance in accordance with the user-specified values for the variable elements. (¶8 simulator module includes: a data store storing the configuration data of the computing device or the device connected to the computing device; and at least one simulator library sub-module, each configured to simulate one of the at least one device; Fig. 1 element 150)
Thomas does not teach in particular, but Sharma teaches:
obtaining configuration information for an information handling resource type by accessing a first instance of the resource type, (¶37 generating and/or implementing a hardware monitoring tool in the form of a software agent configured to run on a host OS and discover devices directly and/or via baseboard management controller (BMC) interfaces. Such devices can include, for example, remote access controllers, Redfish application programming interfaces (APIs), intelligent platform management interfaces (IPMIs), host OS; ¶42 perform discovery of server capabilities depending on BMC vendor and/or BMC type, or via direct interface to hardware to monitor and/or identify capabilities; ¶62 Step 500 includes identifying multiple hardware devices associated with at least one server.; ¶63 Step 502 includes determining one or more capabilities supported by at least a portion of the multiple identified hardware devices by processing data related to the at least one server and one or more of the multiple identified hardware devices)
generate configuration information … based on user-specified values for the variable elements of the configuration information; and (¶64 comparing the one or more determined capabilities supported by at least a portion of the multiple identified hardware devices to one or more parameters of a user-designated server configuration. In at least one embodiment, the one or more parameters of the user-designated server configuration include one or more user-provided hardware device configurations; see also Thomas ¶50, "the remote computing device 130 may allow an administrator/user to input data as part of the simulated data of the simulated devices and/or the simulated platforms to the management controller 110"; see also Thomas ¶64 the device values may be values set by administrators/users through the remote computing device 120; see also Thomas ¶72 and ¶74, "the basic modules can be configured by a user ... a simulated response for power consumption can be varied by simple logic, such as based on user-configured values inputted by remote computing device 120")
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to use the methodology of Sharma to populate the data store of device specific configuration parameter files of Thomas, in order to identify and/or discover device capabilities (Sharma ¶51) in an efficient manner, and also to combine the analysis and data values of Sharma with those of Thomas, in order to provide significant advantages relative to conventional server solution management techniques through automatically determining what capabilities are supported (Sharma, ¶4).
Regarding Claim 2:
Thomas does not teach in particular, but Sharma teaches:
obtaining the information from a baseboard management controller (BMC) communicatively coupled to the first instance of the information handling resource type. (¶37 generating and/or implementing a hardware monitoring tool in the form of a software agent configured to run on a host OS and discover devices directly and/or via baseboard management controller (BMC) interfaces; ¶56 drive. Once the new drive insertion event is received from the BMC, the cluster manager would add the drive back to the storage solution to restore storage capacity)
Regarding Claim 3:
Thomas teaches:
one of a plurality of information handling resource types, wherein the plurality of information handling resource types include a network interface card (NIC) type, a storage device type, and a central processing unit (CPU) type. (¶17 the at least one device connected to the computing device includes: a voltage sensor; a computer tachometer sensor; an I2C device; a PSU; a CPLD; a FRU; a RAID controller, a ROC; a NIC; a satellite management controller; an interface connected to the satellite management controller; a system interface; a USB interface; and a HECI; ¶78 the device being simulated may be one or more CPUs)
Regarding Claim 4:
Thomas does not teach in particular, but Sharma teaches:
one or more attribute-value pairs, wherein each attribute-value pair includes a name field indicative of a configuration parameter and a value field indicative of a configuration parameter value. (¶48 Configuration data can include, for example, a list of components, values and/or calculations to execute in order to determine whether a component meets minimum expectations for support; examiner notes that this is equivalent to a fixed element for name (the list of components) and the variable elements for values (the values and/or calculations for a component).; see also Thomas ¶59, the simulation files may include, without being limited to: (1) one or more platform data files, each providing the detailed information of the type of the platform device and an address; (2) one or more device data files (which may be used across projects for different platforms), each providing the detailed information of the type of the device and the types of commands and responses of the device; and (3) one or more device specific configuration parameter files, each providing the specific configuration applicable for the device, including the method of generating the response.; see also Thomas ¶60, the simulator module 150 may store platform data files providing platform details of the devices such as the type, the bus address and the device address of the devices, device data files correspondingly providing details of each device such as the type of command and responses of each device, and device specific configuration parameter files correspondingly providing specific configuration applicable for each of the devices)
Regarding Claim 5:
Thomas does not teach in particular, but Sharma teaches:
wherein the name field corresponds to the fixed element and the value field corresponds to the variable element. (¶48 Configuration data can include, for example, a list of components, values and/or calculations to execute in order to determine whether a component meets minimum expectations for support; examiner notes that this is equivalent to a fixed element for name (the list of components) and the variable elements for values (the values and/or calculations for a component).)
Regarding Claim 6:
Thomas does not teach in particular, but Sharma teaches:
wherein the management server simulator comprises a Redfish simulator configured to provide Redfish services. (¶38 server capabilities are determined using one or more Redfish APIs, one or more IPMIs, and/or one or more vendor-specific APIs. In such an embodiment, using a Redfish API can include attempting to access a third-party server BMC through investigation of Redfish API support by the BMC.)
Regarding Claim 7:
Thomas does not teach in particular, but Sharma teaches:
wherein the Redfish simulator includes one or more simulator application programming interfaces (APIs) configured to receive requests from a Redfish client and (¶38 server capabilities are determined using one or more Redfish APIs, one or more IPMIs, and/or one or more vendor-specific APIs. In such an embodiment, using a Redfish API can include attempting to access a third-party server BMC through investigation of Redfish API support by the BMC.)
inject user-specified values for the variable elements into responses provided to the Redfish client. (¶65 performing the at least one automated action includes automatically configuring one or more of the multiple identified hardware devices as part of the user-designated server configuration; Examiner notes that in the combination, the below cited functionality of Thomas would be used to execute the automatic configuration of Sharma (the configuration details of which are user-designated), and that as demonstrated in the previous claim limitation's citations to Sharma, the Sharma accessing a third-party server BMC via redfish API investigation (to discover its capabilities, which in the combination includes simulation); ¶66 As discussed above, the drivers of the driver module 160 are configured to receive and process data from the corresponding hardware, and send the processed data to the firmware 170. In certain embodiments, the library programs of the library module 160 may use the drivers of the driver module 170 to interact with the corresponding hardware. In certain embodiments, the simulator driver sub-module 156 may simulate data from part or all of the hardware controlled by the drivers, and send the simulated data to the corresponding driver in the driver module 160 for processing. For example, the driver module 170 may include one or more existing drivers for a certain device. In this case, the simulator driver sub-module 156 may simulate a driver, which can register one or more handlers with the existing drivers for the device, and the existing drivers may check for registration to determine whether the drivers should be handled by the simulator driver sub-module 156 (i.e., the simulated driver). This will allow for easier separation of the simulator codes for exclusion when a regular image of the management controller 110 is prepared.)
Regarding Claim 10:
Thomas teaches:
a central processing unit (CPU); one or more storage resources including processor-executable program instructions that, when executed by the CPU, cause the information handling system to perform platform development operations, wherein the operations include: (¶52 the management controller 110 includes a processor 112, a memory 114, and a storage device 116.; ¶53 the processor 112 may be a central processing unit (CPU). The processor 112 can execute any computer executable code or instructions)
wherein the configuration information includes one or more fixed elements and one or more corresponding variable elements; (¶64 The data store 152 is a database which stores configuration data of the computing device or the device connected to the computing device being simulated by the simulator module 150; ¶64 the configuration parameters of the devices may include device values, and each of the device values may be a static value or a random value within a range, a value obtained from one or more patterns, a value derived from a function of another set of variables, a value set by an administrator, a time-based value, or a value picked from a socket server.)
defining a simulation policy for the resource type, wherein the simulation policy is suitable to generate configuration information for a second instance of the resource type (¶65 the simulation of the simulator library sub-module 154 is performed based on the configuration data stored in the data store 152; ¶65 In response to generating the simulated data, the simulator library sub-module 154 sends the simulated data to the firmware module 140 through the library module 160 for BMC testing and developing. In certain embodiments, the simulator library sub-module 154 may simulate for intelligent devices such as satellite controllers, PSUs, NIC, RAID, CPLD by referring to the data library 152 or to the socket server. In certain embodiments, the simulator library sub-module 154 may simulate devices behind satellite controllers, which are accessed by bridging, by referring to the data library 152 for bridge command for the devices and execute the command. In certain embodiments, more than one simulator library sub-module 154 may co-exist to simulate the different intelligent devices.; ¶70)
providing a management server simulator configured to simulate the second instance in accordance with the user-specified values for the variable elements. (¶8 simulator module includes: a data store storing the configuration data of the computing device or the device connected to the computing device; and at least one simulator library sub-module, each configured to simulate one of the at least one device; Fig. 1 element 150)
Thomas does not teach in particular, but Sharma teaches:
obtaining configuration information for an information handling resource type by accessing a first instance of the resource type, (¶37 generating and/or implementing a hardware monitoring tool in the form of a software agent configured to run on a host OS and discover devices directly and/or via baseboard management controller (BMC) interfaces. Such devices can include, for example, remote access controllers, Redfish application programming interfaces (APIs), intelligent platform management interfaces (IPMIs), host OS; ¶42 perform discovery of server capabilities depending on BMC vendor and/or BMC type, or via direct interface to hardware to monitor and/or identify capabilities; ¶62 Step 500 includes identifying multiple hardware devices associated with at least one server.; ¶63 Step 502 includes determining one or more capabilities supported by at least a portion of the multiple identified hardware devices by processing data related to the at least one server and one or more of the multiple identified hardware devices)
generate configuration information … based on user-specified values for the variable elements of the configuration information; and (¶64 comparing the one or more determined capabilities supported by at least a portion of the multiple identified hardware devices to one or more parameters of a user-designated server configuration. In at least one embodiment, the one or more parameters of the user-designated server configuration include one or more user-provided hardware device configurations; see also Thomas ¶50, "the remote computing device 130 may allow an administrator/user to input data as part of the simulated data of the simulated devices and/or the simulated platforms to the management controller 110"; see also Thomas ¶64 the device values may be values set by administrators/users through the remote computing device 120; see also Thomas ¶72 and ¶74, "the basic modules can be configured by a user ... a simulated response for power consumption can be varied by simple logic, such as based on user-configured values inputted by remote computing device 120")
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to use the methodology of Sharma to populate the data store of device specific configuration parameter files of Thomas, in order to identify and/or discover device capabilities (Sharma ¶51) in an efficient manner, and also to combine the analysis and data values of Sharma with those of Thomas, in order to provide significant advantages relative to conventional server solution management techniques through automatically determining what capabilities are supported (Sharma, ¶4).
Regarding Claims 11-16:
Claims 11-16 are substantively similar to claims 2-7 respectively, and are rejected under the same grounds as those set forth for claims 2-7 above.
Claims 8, 9, 17, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Thomas (US 20180018189 A1) in view of Sharma (US 20220166669 A1), and further in view of Kuno (US 20220390999 A1)
Regarding Claim 8:
Thomas in view of Sharma does not teach in particular, but Kuno teaches:
wherein the management server simulator is implemented in a SmartNIC. (¶14 smart network components (e.g., a SmartNIC); ¶26 or a particular type of SmartNIC to model the power usage of a SmartNIC, taking into account the level and/or duration of computation performed by the SmartNIC. In one particular example, the model can be used to compute the amount of power consumed by the SmartNIC for performing a number of hardware tag-matching operations; note that while Thomas is silent regarding a smartNIC, it does disclose in ¶15 "the at least one device connected to the host computing device includes ... a network interface card (NIC)")
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to utilize the SmartNIC of Kuno as one of the NICs of Thomas (see e.g. ¶15 of Thomas) in the combination of Thomas and Sharma, in order to enable computations to be offloaded to the smart network components (Kuno ¶14), thereby by improving efficiency
Regarding Claim 9:
Thomas in view of Sharma does not teach in particular, but Kuno teaches:
wherein the SmartNIC is installed on a physical node and communicatively coupled to a baseboard management controller. (¶14 smart network components (e.g., a SmartNIC); ¶26 or a particular type of SmartNIC to model the power usage of a SmartNIC, taking into account the level and/or duration of computation performed by the SmartNIC. In one particular example, the model can be used to compute the amount of power consumed by the SmartNIC for performing a number of hardware tag-matching operations; note that while Thomas is silent regarding a smartNIC, it does disclose in ¶15 "the at least one device connected to the host computing device includes ... a network interface card (NIC)"; Examiner notes that Thomas also describes in ¶47 that "computer components may include physical hardware components" (the NIC would be one of these, and is connected, and when combined with Kuno, the NIC would be a SmartNIC that is connected, i.e. communicatively coupled, to the host computing device, which includes the management controller, which as noted by Thomas numerous times (e.g. ¶6), " is a baseboard management controller (BMC).")
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to utilize the SmartNIC of Kuno as one of the NICs of Thomas (see e.g. ¶15 of Thomas) in the combination of Thomas and Sharma, in order to enable computations to be offloaded to the smart network components (Kuno ¶14), thereby by improving efficiency
Regarding Claims 17 and 18:
Claims 17 and 18 are substantially similar to claims 8 and 9 respectively, and are rejected under the same grounds as those set forth for claims 8 and 9 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Maity (US 20180046485 A1) discusses network device simulation in the context of implementation on virtual machines (VMs) which are configured to execute the simulations, with other details similar to those of the above cited Thomas reference.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BIJAN MAPAR whose telephone number is (571)270-3674. The examiner can normally be reached Monday - Thursday, 11:00-8: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, Rehana Perveen can be reached at 571-272-3676. 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.
/BIJAN MAPAR/ Primary Examiner, Art Unit 2189