DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are pending.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 12-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Bartscherer et al. (US 20240202147).
Regarding claim 12, Bartscherer teaches
An operation method of a notebook computer, comprising: (Fig. 1)
declaring an embedded controller (EC) (Figs 3, 8, and 11), (message converter microcontroller – 840/1140) and/or touch controller (), which is a chip package, ([0121-122], “The MCU may include a processor 1147 and memory 1149. In at least one example, message passthrough MCU 1140 may be configured in the same or similar manner as message passthrough MCU 840. In this example, 2 to 6 pins, in addition to reset/interrupt and power/ground pins from the touch controller 1124 feed into the MCU 1122. The MCU 1122 converts the signals to high-speed signals and transmits them over a USB connection having only four (4) pins to SOC 1110.” Where the MCU has pins and therefore a package (i.e. a package chip)), as an I2C human interface device (I2C HID) by an advanced configuration and power interface (ACPI); and ([0088], “a message passthrough system for messages from a human interface device (e.g., a touch screen) in a lid panel using various communication protocols, enables messages from a human interface device (HID) using certain low-speed communication protocols to use a high-speed communication protocol (e.g., universal serial bus (USB) or “HID over USB”) to passthrough to a CPU in another panel of the computing device. One or more embodiments generates packets based on the that are sent to a processor in the base panel of the computing device. The remote HID device in the lid panel may use a certain communication protocol such as, for example, HID over inter-integrated circuit (I2C) (also referred to herein as “HID over I2C”)”, [0060], “The basic/input output (BIOS) software 330 may be configured to support operating system software 310. In BIOS configuration 332, the supported virtual I/O drivers 315A-315C in operating system software 310 are each defined in an advanced configuration and power interface (ACPI) table(s) 334. Thus, the SPI, I2C, and GPIO virtual resources can be registered in the ACPI table(s) 334.” [0104], “The lid panel side 922 includes message passthrough firmware 920 and the base panel side 912 includes operating system software (OS SW) 910. In one example, software and firmware stack 900 may be implemented in a computing device, such as computing device 800 illustrated in FIG. 8. For example, message passthrough firmware 920 may be configured to run on a processor of message passthrough MCU 840, which is disposed in lid panel 820 of computing device 800. In this example, operating system software 910 may be configured to run on CPU 812 in motherboard 814, which is disposed in base panel 810 of computing device 800.”, and [0109], “The HID over USB inbox driver 916 can identify the MCU 840 as a HID class device.”)
defining a communication method between the embedded controller and an operating system by the embedded controller. ([0099], “In the HID over USB protocol, a transfer may include one or more transactions that create a set of data that meaningful to the USB device (e.g., message passthrough MCU 840). For example, input reports, output reports, and feature reports may be different types of transfers in the HID over USB communication protocol.” And [0101], “ In the HID over USB protocol, the USB host (e.g., CPU 812) can receive data from the USB device (e.g., MCU 840), by sending a Get_Report request to allow the USB host to receive data (e.g., input report) from the USB device. In one or more embodiments, the USB device can send data to the USB host that is obtained from a HID device. For example, the USB device determines whether an interrupt signal is asserted by the HID device (e.g., touch controller 824 of touch screen 826) according to the appropriate communication protocol (e.g., HID over I2C or HID over SPI), and if so, requests the data from the HID device.”)
As to claim 13, Bartscherer teaches these claims according to the reasoning provided in claim 4.
As to claim 14, Bartscherer teaches these claims according to the reasoning provided in claim 5.
As to claim 15, Bartscherer teaches these claims according to the reasoning provided in claim 6.
As to claim 16, Bartscherer teaches these claims according to the reasoning provided in claim 7.
As to claim 17, Bartscherer teaches these claims according to the reasoning provided in claim 8.
As to claim 18, Bartscherer teaches these claims according to the reasoning provided in claim 9.
As to claim 19, Bartscherer teaches these claims according to the reasoning provided in claim 10.
As to claim 20, Bartscherer teaches these claims according to the reasoning provided in claim 5 and 9.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-3 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Hu et al. (US 20190087382).
Claim(s) 1-3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Meza Arellano et al. (US 20240370078) in view of Hu et al. (US 20190087382).
Regarding claim 1, Meza Arellano teaches
A notebook computer, comprising:
a platform controller hub (PCH), comprising: (Fig. 1, [0026], “The CPU may execute the BIOS code when powering up and subsequently execute the code in the NVM 108 to provide an operating system. One possible example of the microprocessor is the Intel® PCH.”)
an embedded controller (EC), comprising: (Fig. 1-3, (Embedded controller -150,250))
a second inter-integrated (I2C) controller (Fig. 3, (316/328 – I2C), [0045], “The EC can further communicate with a CPU 332 via a path 328 using SMbus/I2C”);
a data wiring, connected to the first I2C controller and the second I2C controller; (Fig. 3, (316/328-I2C SDA))
a clock signal wiring, connected to the first I2C controller and the second I2C controller ; and (Fig. 3, (316/328-I2C SCL))
Meza Arellano does not teach but Hu teaches
a first inter-integrated circuit (I2C) controller; and (Fig. 3, (I2C-328) ))
a general-purpose input/output (GPIO) controller; (Fig. 2, GPIO controller – 218))
an interrupt signal wiring (Fig. 2, (GPIO INT)), connected to the GPIO controller and the second I2C controller. ([0042], “The ISR handler 210 may handle interrupts triggered by the external sensor module 130 (interrupt GPIO pin)”)
Meza Arellano and Hu are analogous art. Hu is cited to teach a similar concept of an electronic device with many input/output devices and buses which are communicating human interface device information. Hu teaches communicating via human interface devices to the host device in an efficient way by using a PCH connected to a controller (i.e. Meza Arellano’s embedded controller) control human interface devices. Since these electronic devices are similar in structure there would be a reasonable expectation of yielding predictable results. Based on Hu and the KSR rationale of combining prior art elements according to known methods to yield predictable results, it would have been obvious before the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Hu to use a PCH to communicate interrupts with the EC of Meza Arellano via an interrupt controller.
Regarding claim 2, Hu teaches further comprising: a processor, wherein the processor and the platform controller hub are integrated in a system on chip (SoC). ([0022],” The processor 122 may include, for example, one or more processors situated in separate components, or alternatively one or more processing cores embodied in a component (e.g., in an System-on-a-Chip (SoC) configuration), and any processor-related support circuitry (e.g., bridging interfaces, etc.).”)
Regarding claim 3, Hu teaches further comprising: a processor, connected to the platform controller hub, wherein the processor and the platform controller hub are two independent chips. ([0022], “Examples of support circuitry may include host side or input/output (I/O) side chipsets (also known as northbridge and southbridge chipsets/components) to provide an interface through which the processor 122 may interact with other system components that may be operating at different speeds, on different buses, etc. in apparatus 100.”)
Claim(s) 4-11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Meza Arellano and Hu in view of Bartscherer.
Regarding claim 4, Meza Arellano and Hu do not teach but Bartscherer teaches wherein the embedded controller communicates with an operating system using a feature report. ([0099], “A feature report may be a bi-directional report that can be sent from the USB host to the USB device or from the USB device to the USB host.” And [0097], “The message passthrough MCU 840 can send the HID over USB message to CPU 812 via a USB bus (e.g., high-speed bus 842). If an operating system has a message (e.g., command, read/write request, etc.) to communicate to touch screen 826, then a HID over USB message is sent to MCU 840 via the USB bus, and the firmware in MCU 840 converts the HID over USB message to a HID over I2C message or a HID over SPI message, depending on which protocol is used by touch screen 826. The generated HID over SPI or HID over I2C message can be sent to touch screen 826 via an SPI or I2C interface to the SPI or I2C bus 827, depending on which communication protocol is used by touch screen 826.”)
Bartscherer is cited to teach a similar concept of an electronic device with many input/output devices and buses. Bartscherer teaches communicating via human interface devices to the host device in an efficient way. Bartscherer teaches using a feature report to communicate information to the operating system. Since these electronic devices are similar in structure there would be a reasonable expectation of yielding predictable results. Based on Bartscherer and the KSR rationale of combining prior art elements according to known methods to yield predictable results, it would have been obvious before the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Meza Arellano and Hu to use a feature report to communicate information to the operating system from a controller.
Regarding claim 5, Meza Arellano and Hu do not teach but Bartscherer teaches further comprising: an HID class driver unit, wherein the embedded controller uploads data to the HID class driver unit using the feature report. ([0099], “A feature report may be a bi-directional report that can be sent from the USB host to the USB device or from the USB device to the USB host. A feature report may be a bi-directional report that can be sent from the USB host to the USB device or from the USB device to the USB host. The USB host can use a Set_Report request to allow the USB host to send a report to the USB device.”)
Bartscherer is cited to teach a similar concept of an electronic device with many input/output devices and buses. Bartscherer teaches communicating via human interface devices to the host device in an efficient way. Bartscherer teaches uploading data to an HID class driver using a feature report. Since these electronic devices are similar in structure there would be a reasonable expectation of yielding predictable results. Based on Bartscherer and the KSR rationale of combining prior art elements according to known methods to yield predictable results, it would have been obvious before the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Meza Arellano and Hu to upload data to an HID class driver using a feature report.
Regarding claim 6, Meza Arellano and Hu do not teach but Bartscherer teaches further comprising: an application unit, wherein the HID class driver unit communicates with the application unit through an application interface. ([0109], “The HID over USB inbox driver 916 supports a HID over USB device (e.g., message passthrough MCU 840). The HID over USB inbox driver 916 can identify the MCU 840 as a HID class device.” And [0055], “operating system software 310 also includes other drivers to convert USB messages received by operating system software 310 back to the original I/O messages, according to the appropriate communication protocol such as SPI, I2C, or GPIO, for example. These other drivers can also convert output messages (e.g., from an application layer) intended for remote I/O devices that use various protocols (e.g., SPI, I2C, and GPIO) into output messages based on the USB protocol or another high-speed protocol in alternative implementations.” And claim 34, “ provide the first message to a virtual input/output (I/O) driver corresponding to the first I/O communication protocol to enable a software application running on the second processor to access the first message.”)
Bartscherer is cited to teach a similar concept of an electronic device with many input/output devices and buses. Bartscherer teaches communicating via human interface devices to the host device in an efficient way. Bartscherer teaches the HID driver communicating with an application. Since these electronic devices are similar in structure there would be a reasonable expectation of yielding predictable results. Based on Bartscherer and the KSR rationale of combining prior art elements according to known methods to yield predictable results, it would have been obvious before the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Meza Arellano and Hu to communicate information between the HID driver and an application.
Regarding claim 7, Meza Arellano and Hu do not teach but Bartscherer teaches wherein the HID class driver unit downloads data to the embedded controller using the feature report. ([0101], “ In the HID over USB protocol, the USB host (e.g., CPU 812) can receive data from the USB device (e.g., MCU 840), by sending a Get_Report request to allow the USB host to receive data (e.g., input report) from the USB device. In one or more embodiments, the USB device can send data to the USB host that is obtained from a HID device. For example, the USB device determines whether an interrupt signal is asserted by the HID device (e.g., touch controller 824 of touch screen 826) according to the appropriate communication protocol (e.g., HID over I2C or HID over SPI), and if so, requests the data from the HID device.”)
Bartscherer is cited to teach a similar concept of an electronic device with many input/output devices and buses. Bartscherer teaches communicating via human interface devices to the host device in an efficient way. Bartscherer teaches uploading data to an HID class driver using a feature report. Since these electronic devices are similar in structure there would be a reasonable expectation of yielding predictable results. Based on Bartscherer and the KSR rationale of combining prior art elements according to known methods to yield predictable results, it would have been obvious before the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Meza Arellano and Hu to upload data to an HID class driver using a feature report.
Regarding claim 8, Meza Arellano and Hu do not teach but Bartscherer teaches wherein the feature report has a two-way communication mode. ([0099], “A feature report may be a bi-directional report that can be sent from the USB host to the USB device or from the USB device to the USB host.”)
Bartscherer is cited to teach a similar concept of an electronic device with many input/output devices and buses. Bartscherer teaches communicating via human interface devices to the host device in an efficient way. Bartscherer teaches using two way feature reports to communicate information. Since these electronic devices are similar in structure there would be a reasonable expectation of yielding predictable results. Based on Bartscherer and the KSR rationale of combining prior art elements according to known methods to yield predictable results, it would have been obvious before the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Hu to use two way feature reports to communicate information.
Regarding claim 9, Meza Arellano and Hu do not teach but Bartscherer teaches wherein the embedded controller communicates with an operating system using an input report and an output report. ([0099], “For example, input reports, output reports, and feature reports may be different types of transfers in the HID over USB communication protocol. An input report (or input data) may be a uni-directional report that is sent from the USB device (e.g., message passthrough MCU 840) to the USB host (e.g., CPU 812).” And [0097], “The message passthrough MCU 840 can send the HID over USB message to CPU 812 via a USB bus (e.g., high-speed bus 842). If an operating system has a message (e.g., command, read/write request, etc.) to communicate to touch screen 826, then a HID over USB message is sent to MCU 840 via the USB bus, and the firmware in MCU 840 converts the HID over USB message to a HID over I2C message or a HID over SPI message, depending on which protocol is used by touch screen 826. The generated HID over SPI or HID over I2C message can be sent to touch screen 826 via an SPI or I2C interface to the SPI or I2C bus 827, depending on which communication protocol is used by touch screen 826.”)
Bartscherer is cited to teach a similar concept of an electronic device with many input/output devices and buses. Bartscherer teaches communicating via human interface devices to the host device in an efficient way. Bartscherer teaches using one way input and output reports to communicate information between the controller and the operating system. Since these electronic devices are similar in structure there would be a reasonable expectation of yielding predictable results. Based on Bartscherer and the KSR rationale of combining prior art elements according to known methods to yield predictable results, it would have been obvious before the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Meza Arellano and Hu to upload data using the embedded controller to communicate information in one way input and output reports to the operating system.
Regarding claim 10, Meza Arellano and Hu do not teach but Bartscherer teaches wherein the input report and the output report have a one-way communication mode. ([0099], “input reports, output reports, and feature reports may be different types of transfers in the HID over USB communication protocol. An input report (or input data) may be a uni-directional report that is sent from the USB device (e.g., message passthrough MCU 840) to the USB host (e.g., CPU 812). An output report (or output data) may be a uni-directional report that is sent from the USB host to the USB device.”)
Bartscherer is cited to teach a similar concept of an electronic device with many input/output devices and buses. Bartscherer teaches communicating via human interface devices to the host device in an efficient way. Bartscherer teaches using one way input and output reports to communicate information. Since these electronic devices are similar in structure there would be a reasonable expectation of yielding predictable results. Based on Bartscherer and the KSR rationale of combining prior art elements according to known methods to yield predictable results, it would have been obvious before the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Meza Arellano and Hu to use one way input and output reports to communicate information.
Regarding claim 11, Meza Arellano and Hu do not teach but Bartscherer teaches wherein an advanced configuration and power interface (ACPI) declares the embedded controller as an I2C human interface device (I2C HID). ([0098], “high-speed bus 842 may be configured as the USB bus that connects CPU 812 to message passthrough MCU 840 to enable communication therebetween. As previously described herein, one version of a USB bus can include two wires for power (e.g., VCC and ground) and a pair of wires to carry the data. Generally, any number wires to carry data that is supported by the USB specification and is less than the number of wires needed for the touch screen using another protocol (e.g., HID over I2C, HID over SPI, etc.)” and [0060], “the supported virtual I/O drivers 315A-315C in operating system software 310 are each defined in an advanced configuration and power interface (ACPI) table(s) 334. Thus, the SPI, I2C, and GPIO virtual resources can be registered in the ACPI table(s) 334. Virtual I/O drivers 315A-315C can have dependency on the USB enumeration of the message converter MCU 240 in ACPI table(s) 334. This allows the virtual I/O drivers to run after the message converter MCU 240 is detected and USB bridge driver 316 is running. Also, each client device in the ACPI table using any of the virtual I/Os (e.g., electric shutter, camera, microphone, etc.) lists the resources to be used and lists the virtual I/O drivers as a dependency.”)
Bartscherer is cited to teach a similar concept of an electronic device with many input/output devices and buses. Bartscherer teaches communicating via human interface devices to the host device in an efficient way. Bartscherer teaches the ACPI declares the controller a human device interface. Since these electronic devices are similar in structure there would be a reasonable expectation of yielding predictable results. Based on Bartscherer and the KSR rationale of combining prior art elements according to known methods to yield predictable results, it would have been obvious before the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Meza Arellano and Hu to declare the controller an HID.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant's arguments filed 02/26/2026 have been fully considered but they are not persuasive. The Applicant’s representative argues that a “chip package” in claim 12 is not disclosed by Bartscherer. The Examiner respectfully disagrees with this assertion. In Fig. 11, the number of pins of a package are described for the Message Passthrough MCU (i.e. the embedded controller) and are additionally described in the U.S.C. 102 rejection. Therefore, the applicant’s arguments are not persuasive and the rejection is maintained.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., the structural differences, the functional differences, and the system roll of the package chip vs. the remote I/O device) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Additionally, currently remote I/O devices are not used in the rejection of claim 12 and therefore, those arguments are moot and not persuasive.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 CHERI L. HARRINGTON whose telephone number is (571)270-0468. The examiner can normally be reached Generally, M-F, 7:30a-4p.
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, Jaweed Abbaszadeh can be reached at 571-270-1640. 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.
/CHERI L HARRINGTON/Examiner, Art Unit 2176 August 31, 2026
/JAWEED A ABBASZADEH/Supervisory Patent Examiner, Art Unit 2176
Prosecution Insights