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 .
Claims 1-18, 21, and 24 are pending in this application.
Information Disclosure Statement
The IDS filed on 12/14/23 has been considered.
Specification
The disclosure is objected to because of the following informalities: On Pg. 4, lines 6-23, the specification makes reference to the figures with the “processing circuitry 14” in several spots. However, on Pg. 4, lines 25-33, the specification makes reference to the figures with the “control circuitry 14” and continues to refer to item 14 of the drawings as control circuitry throughout the rest of the specification. “Processing circuitry 14” is not even a item in the drawings; thus, any mention of “processing circuitry 14” in the specification should be changed to “control circuitry 14.”
Appropriate correction is required.
Claim Objections
Claim 1 is objected to because of the following informalities: Claim 1 recites "...the computer system comprising processing circuitry (105)..." Applicant forgot to strikethrough the reference number "(105)" in the claim. Claim 1 also recites “…provide access to the one or more processing functionalities for application programs being executed in the operation system…” Examiner believes claim 1 should recite “…provide access to the one or more processing functionalities for application programs being executed in the operating system…” Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 24 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Currently, claim 24 is a dependent claim of claim 19. However, claim 19 has been canceled. Claim 24 should be amended to be a dependent claim of claim 21 rather than cancelled claim 19. For prior art rejections, Examiner will interpret claim 24 as being dependent on claim 21.
Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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.
Claim(s) 1-6, 14-17, 21, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Righi (US Patent No. 9,727,390 B1) in view of Cooper et al. (US Pub. No. 2018/0203705 A1 hereinafter Cooper).
As per claim 1, Righi teaches a firmware apparatus for a computer system, the computer system comprising processing circuitry (Col. 3, lines 11-35, “FIG. 1 shows an illustrative computer architecture for a computer 100 that is operative to enable the execution of a firmware function for enabling the exchange of data between an application or operating system program and a computer firmware. In order to provide the functionality described herein, the computer 100 includes a baseboard, or “motherboard”, which is a printed circuit board to which a multitude of components or devices may be connected by way of a system bus or other electrical communication path. In one illustrative embodiment, a central processing unit (“CPU”) 102 operates in conjunction with a chipset 104. The CPU 102 is a standard central processor that performs arithmetic and logical operations necessary for the operation of the computer. As will be described in greater detail below, the computer 100 may include a multitude of CPUs.), the firmware apparatus comprising: an interface for accessing functionality of the firmware apparatus from an operating system of the computer system (Col. 5, lines 1-26, “The EFI specification describes an interface between an operating system 202 and the firmware 136. Additionally, the EFI specification defines the interface that platform firmware must implement and the interface that the operating system 202 may use in booting. How the firmware 136 implements the interface is left up to the manufacturer of the firmware. An EFI core provides services for allocation of memory, creating events, setting a real-time clock, and for performing other functions. According to one implementation of EFI on INTEL CORPORATION IA-32 platforms, both the EFI 206 and a BIOS 208 may be present in the firmware 136. This allows users and system integrators to support both firmware interfaces. In order to provide this functionality, an interface 212 may be provided for use by legacy operating systems and applications.”); and control circuitry to: identify one or more processing functionalities being supported by the processing circuitry of the computer system (Col. 3, lines 27-39, “As shown in FIG. 3, the system includes platform hardware 316 and platform specific firmware 308. The platform specific firmware 308 may retrieve an O/S image from the EFI system partition 318 using an EFI O/S loader 302.” Col. 3, lines 49-61, “EFI runtime services 306 are provided to the O/S loader 302 during the runtime phase, which may be presented to ensure appropriate abstraction of base platform hardware resources that may be needed by the operating system 202 during its normal operation.”), provide information on the one or more processing functionalities via the interface to a user mode interface of the operating system of the computer system (Col. 5 & 6, lines 49-67 & 1-18, “EFI runtime services 306 are provided to the O/S loader 302 during the runtime phase, which may be presented to ensure appropriate abstraction of base platform hardware resources that may be needed by the operating system 202 during its normal operation. For instance, an EFI “Get” variable runtime function may be provided that allows an application or an operating system to retrieve a specific firmware variable.” Col. 6, lines 19-30, “In one embodiment, a setup utility application 322 executes on top of the operating system 202. The setup utility application 322 is configured to receive user input and set values in the firmware 136 to configure the operation of the computer 100. In order to perform this process, the setup utility application 322 may utilize the mechanism described above to obtain information regarding the configuration and utilization of firmware variables that would not otherwise be available to it.”), and provide access to the one or more processing functionalities for application programs being executed in the operation system (Col. 5 & 6, lines 49-67 & 1-18, “As described briefly above, the platform specific firmware 308 might provide a number of runtime services for use by an application program and/or an operating system, such as the Get and Set services. These services are very limited, however. As will be described in greater detail below, the embodiments disclosed herein allow the execution of firmware modules through the use of the runtime Get and Set services. In particular, firmware functions can be defined that correspond to the Get and/or set services and assigned to a unique variable name. When Get or Set requests are received by the firmware 136, the firmware determines whether the requests correspond to the uniquely assigned names. If so, the firmware executes the corresponding firmware functions rather than performing a Get or Set operation. In this manner, applications and operating systems can access other types of functionality not directly provided or defined by UEFI specification or provided by the firmware 136.”).
Righi fails to explicitly teach the above limitations being implemented in circuitry.
However, Cooper teaches the firmware apparatus comprising: an interface and control circuitry (¶ [0019]-[0020], “The mainboard 102 is the primary logic circuit board of the computing device 100, which includes electrical components and electrical connections, such as traces, interconnecting permanently attached (such as soldered) hardware of the device 100 and/or physical connectors like sockets to which hardware of the computing device 100 is attached. For instance, as depicted in FIG. 1, a processor 104 is physically connected to the mainboard 102. The processor 104 is the CPU of the computing device 100. Non-volatile memory 106, such as an EEROM or a PROM, is also physically connected to the mainboard 102. The non-volatile memory 106 stores a firmware interface 108 of the computing device 100, which is computer-executable code. As has been described, the firmware interface 108 may be a BIOS or a UEFI.”).
Righi and Cooper are considered to be analogous to the claimed invention because they are in the same field of resource/hardware allocation. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the functionality of Righi within the firmware apparatus and circuitry of Cooper to arrive at the claimed invention. This combination would have been reasonable and yielded predictable results under MPEP § 2143 as both references teach invoking hardware components via a firmware interface.
As per claim 2, Righi and Cooper teach the apparatus of claim 1. Cooper teaches wherein the control circuitry is to host a driver for accessing the one or more processing functionalities (¶ [0036]-[0037], “The operating system 206 includes drivers 216 for the hardware components 114 by which the operating system 206 accesses the components 114. The drivers are specific to the operating system 206, however, and are not part of the firmware 116 of the hardware components 114. The drivers 216 permit the operating system 206 and computer programs running on the operating system 206 to access the hardware components of the computing device 100. More specifically, and in actuality, the drivers 216 access the hardware components 114 through runtime services 212 of the firmware interface 108…As such, the runtime services 212 are a (firmware) interface 108 between a driver 216 of the operating system 206 and a hardware component 114 that provides access control 214 to its hardware functionality at post-boot 204 of the computing device 100.”).
As per claim 3, Righi and Cooper teach the apparatus of claim 1. Righi teaches wherein the control circuitry is to provide access to the one or more processing functionalities via one or more advanced configuration and power interface methods exposed towards the operating system (Col. 5, lines 40-48, “Thus, interfaces 314 defined by other specifications may also be present on the system. For example, ACPI and the System Management BIOS (“SMBIOS”) specifications may be supported.” See Col. 1, lines 12-20, which indicates that ACPI stands for Advanced Power and Configuration Interface.).
As per claim 4, Righi and Cooper teach the apparatus of claim 1. Righi teaches wherein the access to the one or more processing functionalities is provided via a processing functionality-agnostic driver hosted by the operating system (¶ [0036]-[0037], “The operating system 206 includes drivers 216 for the hardware components 114 by which the operating system 206 accesses the components 114. The drivers are specific to the operating system 206, however, and are not part of the firmware 116 of the hardware components 114. The drivers 216 permit the operating system 206 and computer programs running on the operating system 206 to access the hardware components of the computing device 100. More specifically, and in actuality, the drivers 216 access the hardware components 114 through runtime services 212 of the firmware interface 108…As such, the runtime services 212 are a (firmware) interface 108 between a driver 216 of the operating system 206 and a hardware component 114 that provides access control 214 to its hardware functionality at post-boot 204 of the computing device 100.”).
As per claim 5, Righi and Cooper teach the apparatus of claim 1. Cooper teaches wherein the control circuitry is to yield control to the operating system while waiting for the execution of a processing functionality to complete (¶ [0013], “Once the hardware components have been initiated, the firmware interface then turns control over to the operating system, by loading or otherwise starting the operating system. The firmware interface still is operational, insofar as the interface provides runtime services (as compared to the boot services performed prior to starting the operating system) by which the operating system accesses the hardware components through firmware of these components. However, control of the computing device effectively transfers from the firmware interface to the operating system.” ¶ [0045], “Therefore, the processor 104 executes the firmware interface 108 to load the operating system 206 (314) and then to start the operating system 206 (316). As described, active control of the computing device 100 (i.e., control of the processor 104) transfers from the firmware interface 108 to the operating system 206 at this time.”).
As per claim 6, Righi and Cooper teach the apparatus of claim 1. Righi teaches wherein the control circuitry is to expose one or more services towards the operating system via the interface (Col. 5, lines 1-26, “The EFI specification describes an interface between an operating system 202 and the firmware 136. Additionally, the EFI specification defines the interface that platform firmware must implement and the interface that the operating system 202 may use in booting. How the firmware 136 implements the interface is left up to the manufacturer of the firmware. An EFI core provides services for allocation of memory, creating events, setting a real-time clock, and for performing other functions. According to one implementation of EFI on INTEL CORPORATION IA-32 platforms, both the EFI 206 and a BIOS 208 may be present in the firmware 136. This allows users and system integrators to support both firmware interfaces. In order to provide this functionality, an interface 212 may be provided for use by legacy operating systems and applications.”). Cooper also teaches wherein the control circuitry is configured to expose one or more services towards the operating system via the interface (¶ [0037], “Therefore, even at post-boot 204, the firmware interface 108 is still considered active in that the interface 108 provides the runtime services 212 for access of the hardware components 114. Similarly, the firmware 116 of each hardware component 114 provides access control 214 to its underlying hardware functionality as can be selectively enabled in accordance with the configuration 218 of the component 114. As such, the runtime services 212 are a (firmware) interface 108 between a driver 216 of the operating system 206 and a hardware component 114 that provides access control 214 to its hardware functionality at post-boot 204 of the computing device 100.”).
As per claim 14, Righi and Cooper teach the apparatus of claim 1. Righi teaches wherein the processing circuitry comprises one or more central processing units and/or one or more graphics processing units (Col. 3, lines 22-35, “The CPU 102 is a standard central processor that performs arithmetic and logical operations necessary for the operation of the computer. As will be described in greater detail below, the computer 100 may include a multitude of CPUs.”). Cooper also teaches wherein the processing circuitry comprises one or more central processing units and/or one or more graphics processing units (¶ [0012], “Examples of firmware interfaces including the basic input/output system (BIOS) and the unified extensible firmware interface (UEFI). In common usage it is said that the BIOS or UEFI, for instance, performs functions, but in actuality the primary processor of the computing—e.g., its central processing unit (CPU)—executes the firmware interface to perform them.”).
As per claim 15, Righi and Cooper teach the apparatus of claim 1. Righi teaches wherein the firmware apparatus is implemented as component of a basic input output system or unified extensible firmware interface of the computer system (Col. 5, lines 1-26, “As described above, the firmware 136 comprises a firmware compatible with EFI specification from INTEL CORPORATION or from the UEFI FORUM in one embodiment. The EFI specification describes an interface between an operating system 202 and the firmware 136. Additionally, the EFI specification defines the interface that platform firmware must implement and the interface that the operating system 202 may use in booting. How the firmware 136 implements the interface is left up to the manufacturer of the firmware. An EFI core provides services for allocation of memory, creating events, setting a real-time clock, and for performing other functions. According to one implementation of EFI on INTEL CORPORATION IA-32 platforms, both the EFI 206 and a BIOS 208 may be present in the firmware 136. This allows users and system integrators to support both firmware interfaces. In order to provide this functionality, an interface 212 may be provided for use by legacy operating systems and applications.”). Cooper also teaches wherein the firmware apparatus is implemented as component of a basic input output system or unified extensible firmware interface of the computer system (¶ [0012], “Examples of firmware interfaces including the basic input/output system (BIOS) and the unified extensible firmware interface (UEFI). In common usage it is said that the BIOS or UEFI, for instance, performs functions, but in actuality the primary processor of the computing—e.g., its central processing unit (CPU)—executes the firmware interface to perform them.”).
As per claim 16, Righi and Cooper teach the apparatus of claim 1. Righi teaches a computer system comprising the firmware apparatus (Col. 3, lines 11-21, “FIG. 1 shows an illustrative computer architecture for a computer 100 that is operative to enable the execution of a firmware function for enabling the exchange of data between an application or operating system program and a computer firmware.”). Cooper also teaches a computer system comprising the firmware apparatus (¶ [0019]-[0020], “The mainboard 102 is the primary logic circuit board of the computing device 100, which includes electrical components and electrical connections, such as traces, interconnecting permanently attached (such as soldered) hardware of the device 100 and/or physical connectors like sockets to which hardware of the computing device 100 is attached. For instance, as depicted in FIG. 1, a processor 104 is physically connected to the mainboard 102. The processor 104 is the CPU of the computing device 100. Non-volatile memory 106, such as an EEROM or a PROM, is also physically connected to the mainboard 102. The non-volatile memory 106 stores a firmware interface 108 of the computing device 100, which is computer-executable code. As has been described, the firmware interface 108 may be a BIOS or a UEFI.”).
As per claim 17, Righi and Cooper teach the apparatus of claim 16. Righi teaches wherein the user mode interface is provided to the application programs in user mode (Col. 6, lines 19-31, “In one embodiment, a setup utility application 322 executes on top of the operating system 202. The setup utility application 322 is configured to receive user input and set values in the firmware 136 to configure the operation of the computer 100. In order to perform this process, the setup utility application 322 may utilize the mechanism described above to obtain information regarding the configuration and utilization of firmware variables that would not otherwise be available to it.”).
As per claim 21, it is a method claim comprising similar limitations to claim 1, so it is rejected for similar reasons.
As per claim 24, Righi and Cooper teach the method of claim 21. Righi teaches a machine-readable storage medium including program code (Col. 2, lines 14-19, “The subject matter described herein may also be implemented in a computing system, as an apparatus, or as an article of manufacture such as a computer-readable storage medium.”). Cooper also teaches a machine-readable storage medium including program code (¶ [0064], “Examples of non-transitory computer-readable media include both volatile such media, like volatile semiconductor memories, as well as non-volatile such media, like non-volatile semiconductor memories and magnetic storage drives.”).
Claim(s) 7 and 8 are rejected under 35 U.S.C. 103 as being unpatentable over Righi and Cooper as applied to claim 6 above, and further in view of Lewis (US Pub. No. 2013/0061242 A1).
As per claim 7, Righi and Cooper teach the apparatus of claim 6. Righi teaches wherein the control circuitry is to expose services towards the operating system (Col. 5, lines 1-14, “The EFI specification describes an interface between an operating system 202 and the firmware 136. Additionally, the EFI specification defines the interface that platform firmware must implement and the interface that the operating system 202 may use in booting. How the firmware 136 implements the interface is left up to the manufacturer of the firmware. An EFI core provides services for allocation of memory, creating events, setting a real-time clock, and for performing other functions.” Col. 5 & 6, lines 49-67 & 1-18, “EFI runtime services 306 are provided to the O/S loader 302 during the runtime phase, which may be presented to ensure appropriate abstraction of base platform hardware resources that may be needed by the operating system 202 during its normal operation. For instance, an EFI “Get” variable runtime function may be provided that allows an application or an operating system to retrieve a specific firmware variable.”).
Righi and Cooper fail to explicitly teach that one of the services exposed to the operating system is a handler for timer events.
However, Lewis teaches wherein the control circuitry is to expose at least one handler for timer events towards the operating system, wherein the at least one handler for timer events set to trigger at least one processing functionality (¶ [0032], “FIG. 1 is an illustration of the Secure Application Firmware Environment (SAFE) 100 according to an embodiment of the invention. SAFE 100 may be used by embodiments to provide a secure environment to firmware to provide firmware services in non-x86 platforms. Advantageously, SAFE 100 may support both x86 and non-86 platforms in embodiments of the invention.” ¶ [0035], “OS application 182 represents a native operating systems application that uses the runtime services provided by SAFE 100.” ¶ [0057], “FIG. 2B is a table that illustrates size, offset, and description information for certain exemplary SAFE timer services provided by SAFE 100 according to an embodiment. The SAFE timer services are designed to report and configure the expiration of a timer managed by OS interface driver 186.”).
Righi, Cooper, and Lewis are all considered to be analogous to the claimed invention because they are all in the same field of resource/hardware allocation. Therefore, it would have been obvious to one of ordinary skill in the art to modify the firmware functionality of Righi and Cooper with the timer handling functionality of Lewis to arrive at the claimed invention. This modification would have yielded predictable results and been reasonable under MPEP § 2143 as all references teach invoking hardware components via a firmware interface.
As per claim 8, Righi and Cooper teach the apparatus of claim 6. Righi teaches wherein the control circuitry is to expose services towards the operating system (Col. 5, lines 1-14, “The EFI specification describes an interface between an operating system 202 and the firmware 136. Additionally, the EFI specification defines the interface that platform firmware must implement and the interface that the operating system 202 may use in booting. How the firmware 136 implements the interface is left up to the manufacturer of the firmware. An EFI core provides services for allocation of memory, creating events, setting a real-time clock, and for performing other functions.” Col. 5 & 6, lines 49-67 & 1-18, “EFI runtime services 306 are provided to the O/S loader 302 during the runtime phase, which may be presented to ensure appropriate abstraction of base platform hardware resources that may be needed by the operating system 202 during its normal operation. For instance, an EFI “Get” variable runtime function may be provided that allows an application or an operating system to retrieve a specific firmware variable.”).
Righi and Cooper fail to explicitly teach that one of the services exposed to the operating system is a handler for interrupt events.
However, Lewis teaches wherein the control circuitry is to expose at least one interrupt handler towards the operating system, wherein the at least one interrupt handler is set to trigger at least one processing functionality (¶ [0044], “SAFE service handlers 150, 152, 154, and 156 are registered by drivers to handle certain classes of SAFE service calls. Each SAFE service handler is one or more software components design to perform a particular service. For example, SAFE service handler 150 is responsible for performing timing functionality, SAFE service handler 152 is responsible for performing Sx sleep state functionality, SAFE service handler 154 is responsible for processing system management interrupts (SMIs), and SAFE service handler 156 is responsible for performing OEM specific SAFE commands, such as functions related to SAFE child dispatch, period timer child dispatch, SMI child dispatch, and Sx child dispatch.”).
Righi, Cooper, and Lewis are all considered to be analogous to the claimed invention because they are all in the same field of resource/hardware allocation. Therefore, it would have been obvious to one of ordinary skill in the art to modify the firmware functionality of Righi and Cooper with the interrupt handling functionality of Lewis to arrive at the claimed invention. This modification would have yielded predictable results and been reasonable under MPEP § 2143 as all references teach invoking hardware components via a firmware interface.
Claim(s) 9 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Righi and Cooper as applied to claim 6 above, and further in view of Banik et al. (US Pub. No. 2021/0089296 A1 hereinafter Banik).
As per claim 9, Righi and Cooper teach the apparatus of claim 6. Righi teaches wherein the control circuitry is to expose services towards the operating system (Col. 5, lines 1-14, “The EFI specification describes an interface between an operating system 202 and the firmware 136. Additionally, the EFI specification defines the interface that platform firmware must implement and the interface that the operating system 202 may use in booting. How the firmware 136 implements the interface is left up to the manufacturer of the firmware. An EFI core provides services for allocation of memory, creating events, setting a real-time clock, and for performing other functions.” Col. 5 & 6, lines 49-67 & 1-18, “EFI runtime services 306 are provided to the O/S loader 302 during the runtime phase, which may be presented to ensure appropriate abstraction of base platform hardware resources that may be needed by the operating system 202 during its normal operation. For instance, an EFI “Get” variable runtime function may be provided that allows an application or an operating system to retrieve a specific firmware variable.”).
Righi and Cooper fail to teach that the services exposed to the operating system includes a service for multi-processing synchronization.
However, Banik teaches wherein the control circuitry is to expose at least one service for multi-processing synchronization to the operating system (¶ [0079]-[0080], “For example, some embodiments may provide options for bootloader and firmware to execute tasks in parallel in a thread safe mechanism (e.g., without excessive resources for core synchronization between bootloader and firmware) using dedicated data structures such as a UPD. For example, some embodiments as described herein implement a high level synchronization construct as “monitor” type inside firmware to allocate tasks inside the firmware by multiple cores that remain in synchronization to avoid any duplicate access. The monitor construct ensures that only one processor at a time may be given access to a task. Some embodiments as described herein use a special instruction (e.g., MONITOR/MWAIT instruction) to reduce latency between core operational and wake time from idle…Some embodiments relate to an underlying mechanism for core synchronization. Firmware (e.g., BIOS) may split a single task like device initializations or updates into multiple subtasks and assign the subtasks over multiple cores for running in parallel.”).
Righi, Cooper, and Banik are all considered to be analogous to the claimed invention because they are all in the same field of resource/hardware allocation. Therefore, it would have been obvious to one of ordinary skill in the art to modify the firmware functionality of Righi and Cooper with the multi-processing synchronization service of Banik to arrive at the claimed invention. This modification would have yielded predictable results and been reasonable under MPEP § 2143 as all references teach invoking hardware components via a firmware interface.
As per claim 11, Righi, Cooper, and Banik teach the apparatus of claim 9. Righi teaches wherein the control circuitry is to expose services towards the operating system (Col. 5, lines 1-14, “The EFI specification describes an interface between an operating system 202 and the firmware 136. Additionally, the EFI specification defines the interface that platform firmware must implement and the interface that the operating system 202 may use in booting. How the firmware 136 implements the interface is left up to the manufacturer of the firmware. An EFI core provides services for allocation of memory, creating events, setting a real-time clock, and for performing other functions.” Col. 5 & 6, lines 49-67 & 1-18, “EFI runtime services 306 are provided to the O/S loader 302 during the runtime phase, which may be presented to ensure appropriate abstraction of base platform hardware resources that may be needed by the operating system 202 during its normal operation. For instance, an EFI “Get” variable runtime function may be provided that allows an application or an operating system to retrieve a specific firmware variable.”). Banik teaches wherein the control circuitry is to expose at least one semaphore service for synchronizing access to the one or more processing functionalities to the operating system (¶ [0079]-[0080], “Some embodiments of the firmware as described herein use semaphore to access potential shared resources inside FSP and/or bootloader. Some embodiments relate to an underlying mechanism for core synchronization. Firmware (e.g., BIOS) may split a single task like device initializations or updates into multiple subtasks and assign the subtasks over multiple cores for running in parallel. Thus, some embodiments may employ a semaphore for providing a low latency, efficient and effective mechanism for core synchronization. Some embodiments may “monitor” synchronization construct for core synchronization inside the firmware 504 (e.g., a FSP) to ensure a task is only attempted and executed by one core at a time.”).
Refer to claim 9 for reason to combine.
Claim(s) 10 is rejected under 35 U.S.C. 103 as being unpatentable over Righi, Cooper, and Banik as applied to claim 9 above, and further in view of Wang et al. (US Pub. No. 2013/0305259 A1 hereinafter Wang).
As per claim 10, Righi, Cooper, and Banik teach the apparatus of claim 10. Righi teaches wherein the control circuitry is to expose services towards the operating system (Col. 5, lines 1-14, “The EFI specification describes an interface between an operating system 202 and the firmware 136. Additionally, the EFI specification defines the interface that platform firmware must implement and the interface that the operating system 202 may use in booting. How the firmware 136 implements the interface is left up to the manufacturer of the firmware. An EFI core provides services for allocation of memory, creating events, setting a real-time clock, and for performing other functions.” Col. 5 & 6, lines 49-67 & 1-18, “EFI runtime services 306 are provided to the O/S loader 302 during the runtime phase, which may be presented to ensure appropriate abstraction of base platform hardware resources that may be needed by the operating system 202 during its normal operation. For instance, an EFI “Get” variable runtime function may be provided that allows an application or an operating system to retrieve a specific firmware variable.”).
Righi, Cooper, and Banik fail to teach the service being a service for handling mutually exclusive access to the processing functionalities.
However, Wang teaches wherein the control circuitry is to expose at least one service for handling mutually exclusive access to the one or more processing functionalities to the operating system (¶ [0064]-[0067], “A mutually exclusive operation is a synchronization mechanism for controlling multitasking in performing serial access on shared data. In a multitasking application, data damage may be caused by two or more tasks simultaneously accessing shared data. The mutually exclusive operation allows multiple tasks to sequentially access the shared data to achieve data protection and avoid damage or corruption to the shared data…Step S102 of determining whether the process requiring access to the hardware device has obtained the mutex of the hardware device further includes: 1) when the process requiring access to the hardware device has obtained the mutex of the hardware device, determining whether an identification of a thread requiring the hardware device and an identification of a thread having obtained the mutex are the same; and 2) when the identification of the thread requiring access to the hardware device and the identification of the thread having obtained the mutex are the same, adding the value of the mutex counter by 1 and allowing the thread requiring access to the hardware device to continue utilizing the hardware device; when the identification of the thread requiring access to the hardware device and the identification of the thread having obtained the mutex are different, the thread requiring access to the hardware device waiting until the mutex is obtained.” ¶ [0079], “By modularizing hardware functions, in order to implement a function module, an application needs to utilize one or multiple APIs of corresponding drivers, e.g., a first API Driver API1 of the first driver, a second API Driver API2 of the second driver, and a third Driver API3 of the third driver. Thus, each API is protected under the mutually exclusive access mechanism of the operating system to ensure the mutually exclusive access to hardware devices in a multitasking environment.”).
Righi, Cooper, Banik, and Wang are all considered to be analogous to the claimed invention because they are all in the same field of resource/hardware allocation. Therefore, it would have been obvious to one of ordinary skill in the art to modify the firmware functionality of Righi, Cooper, and Banik with the service for handling mutually exclusive access to hardware as taught by Wang to arrive at the claimed invention. This modification would have yielded predictable results and been reasonable under MPEP § 2143 as all references teach invoking hardware components via a firmware interface.
Claim(s) 12 are rejected under 35 U.S.C. 103 as being unpatentable over Righi, Cooper, and Banik as applied to claim 11 above, and further in view of Hanson (US Patent No. 6,148,346 A).
As per claim 12, Righi, Cooper, and Banik teach the apparatus of claim 11.
Righi, Cooper, and Banik fail to teach the services being implemented in an operating system-agnostic manner which includes translating calls from operating system-specific calls to operating system-agnostic calls.
However, Hanson teaches wherein the one or more services are implemented in an operating system-agnostic manner, wherein the control circuitry is to provide an operating system-specific translation functionality to translate native operating system-specific service calls to operating system-agnostic service calls (Col. 4 & 5, lines 35-67 & 1-12, “The OS specific device driver portion 33 is the two-way translating communication layer between the OS of the host computer system 10 and the OS independent device driver portion 34… The OS specific device driver portion 33 provides for communication between the OS of host computer system 10 and the executing OS independent device driver portion 34. It can be appreciated by one of ordinary skill that an object oriented language with similar characteristics as Java may be used in the present invention provided the object oriented language includes OS independent code with the device driver information required for the peripheral device for multi-network access and OS specific code for translating between the OS and the OS independent code.”).
Righi, Cooper, Wang, and Hanson are all considered to be analogous to the claimed invention because they are all in the same field of resource/hardware allocation. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the circuitry of Righi, Cooper, and Wang with the OS call translation functionality of Hanson to arrive at the claimed invention. The motivation to modify Righi, Cooper, and Wang with the teachings of Hanson is that having functionality to translate OS-specific calls into OS-agnostic calls allows any OS to communicate with any hardware regardless of the type of OS loaded on the computer system.
Claim(s) 13 are rejected under 35 U.S.C. 103 as being unpatentable over Righi and Cooper as applied to claim 1 above, and further in view of Hanson.
As per claim 13, Righi and Cooper teach the apparatus of claim 1.
Righi and Cooper fail to teach compilation of device-independent code to device-specific code.
However, Hanson teaches wherein the control circuitry is to perform online compilation of a device-independent intermediate binary code of the application programs to device-specific code for accessing the one or more processing functionalities (Col. 4 & 5, lines 58-67 & 1-12, “The OS specific device driver portion 33 provides for communication between the OS of host computer system 10 and the executing OS independent device driver portion 34. It can be appreciated by one of ordinary skill that an object oriented language with similar characteristics as Java may be used in the present invention provided the object oriented language includes OS independent code with the device driver information required for the peripheral device for multi-network access and OS specific code for translating between the OS and the OS independent code. It can also be appreciated that a just-in-time compiler could replace the interpreter 19 to compile interpreted code into machine specific code.”).
Righi, Cooper, and Hanson are all considered to be analogous to the claimed invention because they are all in the same field of resource/hardware allocation. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the circuitry of Righi and Cooper with the device code translation functionality of Hanson to arrive at the claimed invention. The motivation to modify Righi, Cooper, and Wang with the teachings of Hanson is that having functionality to translate device-independent code into device-specific code allows any device code submitted by the operating system to be executed without specific knowledge of the device the code is being executed on.
Claim(s) 18 is rejected under 35 U.S.C. 103 as being unpatentable over Righi and Cooper as applied to claim 16 above, and further in view of Vintzel et al. (US Pub. No. 2019/0370015 A1 hereinafter Vintzel).
As per claim 18, Righi and Cooper teach the computer system of claim 16. Righi teaches the user mode interface (Col. 6, lines 19-30, “In one embodiment, a setup utility application 322 executes on top of the operating system 202. The setup utility application 322 is configured to receive user input and set values in the firmware 136 to configure the operation of the computer 100. In order to perform this process, the setup utility application 322 may utilize the mechanism described above to obtain information regarding the configuration and utilization of firmware variables that would not otherwise be available to it.”).
Righi and Cooper fail to teach the user mode interface being implemented as a library that is accessible to programs in the user space.
However, Vintzel teaches the well-known technique of wherein the user mode interface is implemented as a library that is accessible to the application programs in user space (¶ [0028], “In some examples, a graphical user interface of a program is implemented using one or more operating system software libraries (e.g., a library for launching graphical applications in a graphical user environment, and/or a library for integrating a graphical program with a window manager program). Accordingly, at least some methods of terminating the program may be implemented via such operating system libraries. For example, a typical graphical user interface program is configured to provide one or more graphical user interface affordances (e.g., buttons, menus, hotkeys, etc.), for interacting with the operating system, which may be implemented via operating system libraries. Operating system service 110 and runtime service 112 may detect such interaction via the operating system libraries. Accordingly, in the event that a user requests termination of a persistent program via a graphical user interface affordance, runtime service 112 is configured to intercept such request and to prevent termination.”).
Righi, Cooper, and Vintzel are all considered to be analogous to the claimed invention because they are all in the same field of resource/hardware allocation. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Righi and Cooper with the well-known technique of a user interface being implemented as a library as taught by Vintzel to arrive at the claimed invention. This modification would have yielded predictable results and been reasonable under MPEP § 2143 as all references teach invoking underlying hardware via an operating system of a computer.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN ROBERT DAKITA EWALD whose telephone number is (703)756-1845. The examiner can normally be reached Monday-Friday: 9:00-5:30 ET.
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, Lewis Bullock can be reached at (571)272-3759. 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.
/J.D.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199