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 .
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 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.
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 13 July 2026 has been entered.
Claims 1-20 are pending.
Claims 1-20 are rejected, grounds follow.
Claim Objections
Claim 12 is objected to because of the following informalities:
Apparent typo “user input devices” (antecedent basis in claim 1 is “a user input device”)
Appropriate correction is required.
Response to Arguments
Applicant’s arguments, see Remarks Page 8, filed 25 February 2025, with respect to the rejection(s) of claim(s) 1, 17, and 19 (Claim 1 representative) under 35 USC 103 have been fully considered and are persuasive. Applicant argues that none of the references applied in the Final Rejection mailed 13 July 2025 teach or fairly suggest all of the limitations of the amended claims, particularly features regarding an ambient light sensor and modification of a lighting setting for a backlight of a user input device, as now required by the claim. Examiner agrees that these features do not appear to be reasonably taught or fairly suggested by Kim or Bilal. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made further in view of Matsuoka, US Pg-Pub 2014/0035818; see below for detailed rejection.
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-8 and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kim, et al., US Pg-Pub 2015/0220299 in view of Bilal et al., US Pg-Pub 2020/0034141 or, in the alternative, further in view of Dadu et al., US Pg-Pub 2015/0070184.
Regarding Claim 1, Kim teaches:
An Information Handling System (IHS), (Kim “[0071] An electronic device according to various embodiments of the present disclosure may have a communication function. For instance, electronic devices may include at least one of smartphones, tablet personal computers (PCs), mobile phones, video phones, electronic book (e-book) readers, desktop PCs, laptop PCs” such as a mobile computing device / smart phone, see e.g. fig. 2a) comprising: a heterogeneous computing platform; (see fig. 18, depicting a system on chip for a mobile computing device; e.g. [0432] “the AP 1810 may be implemented with a system on chip (SoC), for example. … the processor 1810 may further include a graphic processing unit (GPU) (not shown).)
Executing a host Operating System (OS); ([0432] “The AP 1810 may … perform various data processing and operations with multimedia data by executing an operating system”)
and a memory coupled to the heterogeneous computing platform, (fig. 18, Memory 1830; see also fig. 1A; [0430] “The electronic device 1801, for example, may configure all or part of the above-mentioned electronic device 101 shown in FIG. 1.”)
wherein the memory comprises a plurality of sets of firmware instructions, ([0080] “The memory 130, for example, may include programming modules, for example, a kernel 131, a middleware 132, an application programming interface (API) 133, and an application 134. Each of the above-mentioned programming modules may be configured with software, firmware, hardware, or a combination thereof.”) wherein each of the sets of firmware instructions, upon execution by a respective device among a plurality of devices (e.g. display control module 170, see fig. 1b, fig. 18; camera module 1891, power management module 1895, etc.) of the heterogeneous computing platform, ((see fig. 18, depicting a system on chip for a mobile computing device; e.g. [0432] “the AP 1810 may be implemented with a system on chip (SoC), for example. … the processor 1810 may further include a graphic processing unit (GPU) (not shown). enables the respective device to provide a corresponding firmware service, ([0081] “The kernel 131 may control or manage system resources (for example, the bus 110, the processor 120, or the memory 130) used for performing operation or functions implemented by the remaining other programming modules, for example, the middleware 132, the API 133, or the application 134.”)
and wherein at least one of the plurality of devices operates as an orchestrator configured to: receive, from one or more of the plurality of devices (e.g. display control module 170, see [0342], and independently of the host OS ((inasmuch as the display module 170 is depicted in fig. 1a as separate from the general purpose processor 120 and no mention is made in [0342] of a host OS intermediary between the camera sensor and the control module, Kim discloses independent operation) user presence or engagement information; ([0342] “According to an embodiment, the display control module 170 may determine a user's position or gaze direction through at least one sensor 1004 (for example, a front camera sensor an ambient light sensor, or a motion recognition sensor”)
and in response to the user presence or engagement information, communicating independently of the host OS (inasmuch as the display module 170 is depicted in fig. 1a as separate from the general purpose processor 120 and no mention is made in [0342] of a host OS intermediary between the camera sensor and the control module, Kim discloses independent operation) to trigger modification of a lighting setting for the backlight of [an IHS component.] ([0404] “operation may include recognizing a user's face or gaze of the electronic device and adjusting at least one of the transparency, luminance, brightness, or reflectivity of the first display”)
Kim differs from the claimed invention in that:
Kim does not appear to clearly articulate the controlled component is a backlight of a user input device of the IHS.
Nor does Kim appear to clearly articulate triggering the modification responsive to a light intensity indication from an ambient light sensor of the IHS;
Nor does Kim appear to clearly articulate receiving from the host OS a policy corresponding to lighting settings [for the component];
However, Matsuoka teaches a user input device (keyboard, see figs. 1, 3) for a computer (see background) which includes a backlight ([0029] “Illuminated keyboard 200 may further include a backlight layer 240. Backlight layer 240 may include an array of light sources (e.g., LEDs 242) that are configured to backlight and illuminate one or more keys 212.” ) which may be adjusted (e.g. off/on, see [0005] “light source controller that configured to place light sources ("backlights") that illuminate the keyboard in an on-state or an off-state”) responsive to both gaze ([0040] “direction of the user’s eyesight”) and a signal from an ambient light sensor ([0040] “Light source controller 306 may, for example, turn on the light sources in backlight layer 303 when an ambient light sensor (not shown) indicates poor or failing light conditions. Light source controller 306 may be further configured to limit power consumption by the light sources by maintaining the light sources in an on-state or an off-state according to the status of the direction of the user's eyesight, which it may receive from eyeball tracker unit 305.”)
Matsuoka is analogous art because it is from the same field of user activity aware information handling systems.
One of ordinary skill in the art before the effective filing date of the application could have modified the teachings of Kim by using an illuminated keyboard with a backlight configured to operate responsive to user gaze and ambient lighting conditions, as suggested by Matsuoka.
One of ordinary skill in the art before the effective filing date of the application could have made this modification in order to assist the user in operating the device in poor lighting conditions (Matsuoka [0028] “The user may have difficulty in visually locating individual keys on the keyboard in the poor lighting conditions… To assist the user with visually locating individual keys on the keyboard, the keyboard may be illuminated or lighted.”) while also minimizing power consumption by only illuminating the keys when the user is actually looking at them (Matsuoka [0040] “ light source controller 306 may reduce power consumption… by keeping light sources in an illuminated keyboard 302 in an on-state only when needed to help the user to visually confirm key locations on a keyboard… [0042] “determining if the user’s eyesight is directed toward or away from the illuminated keyboard (440) and accordingly placing light sources… in an on-state (460) or an off-state (450)”)
And, Bilal teaches a client device (see fig. 1, Client device(s) 106) which may be a general purpose desktop or laptop ([0026] “Examples of client devices 106 include processor-based systems, such as desktop computers, a laptop computers, a personal digital assistant, a cellular telephone, a smartphone, a tablet computer system”) running an operating system ([0028] “[0028] A client device 106 can include an operating system 143 configured to execute various client applications. Examples of operating systems 143 include MICROSOFT WINDOWS”) where the OS maintains a mobile-device-management (MDM) policy received by an MDM framework from a management service ([0029] “the management agent 146 includes a mobile device management (MDM) framework provided by or included in the operating system 143 installed on the client device 106.”) which controls access to configuration settings of the device (see e.g. [0030] “the API exposed by the firmware agent 149 may allow the management agent 146 to update the installed version of the firmware 139, modify a configuration setting for the firmware 139 to match a value specified by a firmware attribute 133 of a firmware profile 126, or check a value for a particular firmware property 129 of the installed firmware 139 or configuration setting of the installed firmware 139.”). [nb. as is known in the art, MDM policy settings may include limits on backlight lighting configurations, see e.g. Hexnode Help Desk Website Question “Activate Android/Kiosk/Allow Changing Brightness” (2017)).
Bilal is analogous art because it is from the same field of user activity aware information handling systems.
Accordingly, Examiner finds 1) the prior art contained a ‘base’ device (method, or product) upon which the claimed invention can be seen as an “improvement” – the teachings of Kim, upon which the inclusion of receiving a management policy from the host OS may be seen as an improvement; 2) the prior art contained a known technique that is applicable to the base device (method, or product); - the technique taught by Bilal where a central policy service promulgates MDM policies to an MDM framework in the host OS for standardization of component configuration settings across a fleet of devices; 3) one of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique would have yielded predictable results and resulted in an improved system at least because it would enable monitoring to ensure that configuration settings match attributes specified in the MDM profile thereby improving the security of the device ([0014] “By using an EMM system to enforce policies for an enrolled device's firmware, the security of client devices under the control of the EMM system can be increased.”) and accordingly the improvement would have been obvious to one having ordinary skill in the art (See MPEP 2143.I.D).
Alternatively, Should Applicant feel that Kim does not adequately disclose the negative limitation ‘without any involvement by any host operation system (OS)’, Dadu teaches a smart phone (fig. 1, [0011] “mobile device 10 such as, for example, a wireless smart phone, tablet, … PDA, etc.”) including an embedded controller (fig. 3b, “Low power audio processor”) which receives sensor data for detecting user activity ([0022] “The illustrated low power audio processor 60 includes a monitor module 60a that monitors an input audio signal from an onboard microphone 34 of the mobile device while the host processor is in the standby mode.”) which does not use the host OS ([0016] “[0016] Block 26 may trigger a device location session with respect to the mobile device based on the predetermined audio pattern. For example, if the predetermined audio pattern is a command such as "Help me locate you", the device location session might involve generating an output audio signal (e.g., tone, beacon) that may be audibly followed by the originator/source (e.g., user) of the predetermined audio pattern in order to locate the mobile device. Such an approach may be conducted without activating the host processor or OS.”; c.f. fig. 3a; [0022] “FIG. 3B shows a mobile device architecture 58 in which a low power audio processor 60 (60a-60e) functions as a firmware solution that enables low power operation while a host processor (not shown) remains in a standby mode.”) in order to reduce potential impact on battery life ([0015] “ Monitoring the input audio signal may involve implementing a low power solution that minimizes the potential impact on battery life. For example, a low power processor (e.g., digital signal processor/DSP operating at a relatively low frequency) might sample the input audio signal on an intermittent basis and reduce the power consumption of one or more audio front end components in between samples in order to reduce power consumption.”)
Dadu is analogous art because it is from the same field of endeavor of user activity aware information handling systems.
Accordingly, Examiner finds 1) the prior art contained a ‘base’ device (method, or product) upon which the claimed invention can be seen as an “improvement” – the teachings of Kim, upon which the exclusion of the host OS from the transmission path of the sensor data to the controller can be seen as an “improvement”; 2) the prior art contained a known technique that is applicable to the base device (method, or product); - the technique taught by Dadu in which a separate embedded controller operates in a low power mode independently of the central processing unit and host OS run thereon to identify user activity; 3) one of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique would have yielded predictable results and resulted in an improved system at least because Dadu teaches that processing sensor signals for user activity detection in this way will minimize impact on battery consumption (Dadu [0015]); and accordingly the improvement would have been obvious to one having ordinary skill in the art (See MPEP 2143.I.D).
Regarding Claim 2, Kim in view of Matsuoka and Bilal, alternatively further in view of Dadu, teaches all of the limitations of parent claim 1,
Kim further teaches:
wherein the heterogeneous computing platform comprises at least one of: a System-On-Chip (SoC), a Field-Programmable Gate Array (FPGA), or an Application-Specific Integrated Circuit (ASIC). (see fig. 18, depicting a system on chip for a mobile computing device; e.g. [0432] “the AP 1810 may be implemented with a system on chip (SoC), for example. … the processor 1810 may further include a graphic processing unit (GPU) (not shown).)
Regarding Claim 3, Kim in view of Matsuoka and Bilal, alternatively further in view of Dadu, teaches all of the limitations of parent claim 1,
Kim further teaches:
wherein the orchestrator comprises at least one of: a sensing hub, an Embedded Controller (EC), or a Baseboard Management Controller (BMC). (see fig. 1a, display control module 170 is a separate bus connected control circuit in the mobile device performing a control function for hardware (e.g. the display), i.e. an embedded controller. See e.g. [0079] “the display control module 170) through the bus 110, interprets the received instruction, and performs operations and data processing in response to the interpreted instruction.”)
Regarding Claim 4, Kim in view of Matsuoka and Bilal, alternatively further in view of Dadu, teaches all of the limitations of parent claim 1,
Kim further teaches:
wherein the user presence or engagement information indicates at least one of: whether a user of the IHS is present in front of the IHS, a distance between the user and the IHS, whether the user is engaged with the IHS, or a user engagement score. ([0342] “the display control module 170 may determine a user's position or gaze direction through at least one sensor 1004 (for example, a front camera sensor an ambient light sensor, or a motion recognition sensor”) i.e. at least presence and attention of the user based on detected gaze.)
Regarding Claim 5, Kim in view of Matsuoka and Bilal, alternatively further in view of Dadu, teaches all of the limitations of parent claim 1,
Matsuoka further teaches:
wherein the user input device of the IHS comprises at least one of: a keyboard, a touch bar, a trackpad, a totem, or a mouse. (Matsuoka [0028] “The user may have difficulty in visually locating individual keys on the keyboard in the poor lighting conditions. The user may attempt to locate or operate individual keys on the keyboard blindly without visual confirmation of their locations. However, such use of the keyboard without visual confirmation of the individual keys' locations is prone to error. To assist the user with visually locating individual keys on the keyboard, the keyboard may be illuminated or lighted.”)
Regarding Claim 6, Kim in view of Matsuoka and Bilal, alternatively further in view of Dadu, teaches all of the limitations of parent claim 1,
Kim further teaches:
wherein to receive the user presence or engagement information, the orchestrator is configured to receive a message from at least one of: a time-of-flight sensor, a camera controller, ([0342] “the display control module 170 may determine a user's position or gaze direction through at least one sensor 1004 (for example, a front camera sensor)”) an Image Signal Processor (ISP), or an audio Digital Signal Processor (aDSP) via an Application Programming Interface (API) ([0083] “The API 133 … may include at least one interface or function… for… image processing”)
(in the interest of compact prosecution, examiner notes that Matsuoka also teaches receiving user presence or engagement information from a camera, see Matsuoka [0036]).
Regarding Claim 7, Kim in view of Matsuoka and Bilal, alternatively further in view of Dadu, teaches all of the features of parent claim 1,
Kim further teaches:
wherein to trigger the modification, the orchestrator is configured to send a message to a controller within an Embedded Controller (EC) (see fig. 1a, display control module 170 is a separate bus connected control circuit in the mobile device performing a control function for hardware (e.g. the display), i.e. an embedded controller. See e.g. [0079] “the display control module 170) through the bus 110, interprets the received instruction, and performs operations and data processing in response to the interpreted instruction.”) or a Baseboard Management Controller (BMC), wherein the controller is associated with the IHS component via an Application Programming Interface (API) ([0083] “The API 133” [0081] “Additionally, the kernel 131 may provide an interface for accessing an individual component of the electronic device 101 from the middleware 132, the API 133, or the application 134 and controlling or managing the individual component.”)
Regarding Claim 8, Kim in view of Matsuoka and Bilal, alternatively further in view of Dadu, teaches all of the limitations of parent claim 1,
Kim further teaches:
wherein the lighting setting comprises at least one of: an on/off setting, a brightness level, or a color setting. ([0404] “operation may include recognizing a user's face or gaze of the electronic device and adjusting at least one of the transparency, luminance, brightness, or reflectivity of the first display”;)
(In the interest of compact prosecution examiner notes that Matsuoka also teaches the lighting setting comprising an ‘on/off setting’, see Matsuoka [0042]).
Regarding Claim 12, Kim in view of Matsuoka and Bilal, alternatively further in view of Dadu, teaches all of the limitations of parent claim 1,
Matsuoka further teaches:
wherein the modification of the first lighting setting comprises activating the backlight of the user input devices[sic] in response to the HIS detecting that a user is present and while the light intensity is below a threshold level. ([0040] “Light source controller 306 may be configured to operate light sources in backlight layer 303 according to inputs from one or more sensors (e.g., an ambient light sensor) or user-operated switches. Light source controller 306 may, for example, turn on the light sources in backlight layer 303 when an ambient light sensor (not shown) indicates poor or failing light conditions. Light source controller 306 may be further configured to limit power consumption by the light sources by maintaining the light sources in an on-state or an off-state according to the status of the direction of the user's eyesight, which it may receive from eyeball tracker unit 305. Light source controller 306 may, for example, maintain the light sources in an off-state when the user's eyes are directed away from the keyboard, and place the light sources in an on-state only when the user's eyes are directed or are about to be directed toward the keyboard.”)
Regarding Claim 17, Kim teaches:
A memory device (fig. 18, Memory 1830; see also fig. 1A; [0430] “The electronic device 1801, for example, may configure all or part of the above-mentioned electronic device 101 shown in FIG. 1.”) having a plurality of sets of firmware instructions, ([0080] “The memory 130, for example, may include programming modules, for example, a kernel 131, a middleware 132, an application programming interface (API) 133, and an application 134. Each of the above-mentioned programming modules may be configured with software, firmware, hardware, or a combination thereof.”) wherein each of the sets of firmware instructions is executable by a respective device among a plurality of devices (e.g. display control module 170, see fig. 1b, fig. 18; camera module 1891, power management module 1895, etc.) of a heterogeneous computing platform in an Information Handling System (IHS) ((see fig. 18, depicting a system on chip for a mobile computing device; e.g. [0432] “the AP 1810 may be implemented with a system on chip (SoC), for example. … the processor 1810 may further include a graphic processing unit (GPU) (not shown) to enable the respective device to provide a corresponding firmware service, ([0081] “The kernel 131 may control or manage system resources (for example, the bus 110, the processor 120, or the memory 130) used for performing operation or functions implemented by the remaining other programming modules, for example, the middleware 132, the API 133, or the application 134.”) and wherein a given one of the plurality of sets of firmware instructions, upon execution by an Embedded Controller (EC) (see fig. 1a, display control module 170 is a separate bus connected control circuit in the mobile device performing a control function for hardware (e.g. the display), i.e. an embedded controller. See e.g. [0079] “the display control module 170) through the bus 110, interprets the received instruction, and performs operations and data processing in response to the interpreted instruction.”) or Baseboard Management Controller (BMC), cause the EC or BMC to: receive, from an orchestrator and independently of a host operating system (OS), (inasmuch as the display module 170 is depicted in fig. 1a as separate from the general purpose processor 120 and no mention is made in [0342] of a host OS intermediary between the camera sensor and the control module, Kim teaches independent operation.) user presence or engagement information; ([0342] “According to an embodiment, the display control module 170 may determine a user's position or gaze direction through at least one sensor 1004 (for example, a front camera sensor an ambient light sensor, or a motion recognition sensor”)
and in response to the user presence or engagement information, modify a lighting setting for the backlight of [an IHS component] ([0404] “operation may include recognizing a user's face or gaze of the electronic device and adjusting at least one of the transparency, luminance, brightness, or reflectivity of the first display”) without any involvement by the host OS. (inasmuch as the display module 170 is depicted in fig. 1a as separate from the general purpose processor 120 and no mention is made in [0342] of a host OS intermediary between the camera sensor and the control module, Kim discloses this negative limitation.)
Kim differs from the claimed invention in that:
Kim does not appear to clearly articulate the controlled component is a backlight of a user input device of the IHS.
Nor does Kim appear to clearly articulate triggering the modification responsive to a light intensity indication from an ambient light sensor of the IHS;
Kim does not appear to clearly articulate the orchestrator receives a policy corresponding to lighting settings [for the component] from the host OS.
However, Matsuoka teaches a user input device (keyboard, see figs. 1, 3) for a computer (see background) which includes a backlight ([0029] “Illuminated keyboard 200 may further include a backlight layer 240. Backlight layer 240 may include an array of light sources (e.g., LEDs 242) that are configured to backlight and illuminate one or more keys 212.” ) which may be adjusted (e.g. off/on, see [0005] “light source controller that configured to place light sources ("backlights") that illuminate the keyboard in an on-state or an off-state”) responsive to both gaze ([0040] “direction of the user’s eyesight”) and a signal from an ambient light sensor ([0040] “Light source controller 306 may, for example, turn on the light sources in backlight layer 303 when an ambient light sensor (not shown) indicates poor or failing light conditions. Light source controller 306 may be further configured to limit power consumption by the light sources by maintaining the light sources in an on-state or an off-state according to the status of the direction of the user's eyesight, which it may receive from eyeball tracker unit 305.”)
Matsuoka is analogous art because it is from the same field of user activity aware information handling systems.
One of ordinary skill in the art before the effective filing date of the application could have modified the teachings of Kim by using an illuminated keyboard with a backlight configured to operate responsive to user gaze and ambient lighting conditions, as suggested by Matsuoka.
One of ordinary skill in the art before the effective filing date of the application could have made this modification in order to assist the user in operating the device in poor lighting conditions (Matsuoka [0028] “The user may have difficulty in visually locating individual keys on the keyboard in the poor lighting conditions… To assist the user with visually locating individual keys on the keyboard, the keyboard may be illuminated or lighted.”) while also minimizing power consumption by only illuminating the keys when the user is actually looking at them (Matsuoka [0040] “ light source controller 306 may reduce power consumption… by keeping light sources in an illuminated keyboard 302 in an on-state only when needed to help the user to visually confirm key locations on a keyboard… [0042] “determining if the user’s eyesight is directed toward or away from the illuminated keyboard (440) and accordingly placing light sources… in an on-state (460) or an off-state (450)”)
And, Bilal teaches a client device (see fig. 1, Client device(s) 106) which may be a general purpose desktop or laptop ([0026] “Examples of client devices 106 include processor-based systems, such as desktop computers, a laptop computers, a personal digital assistant, a cellular telephone, a smartphone, a tablet computer system”) running an operating system ([0028] “[0028] A client device 106 can include an operating system 143 configured to execute various client applications. Examples of operating systems 143 include MICROSOFT WINDOWS”) where the OS maintains a mobile-device-management (MDM) policy received by an MDM framework from a management service ([0029] “the management agent 146 includes a mobile device management (MDM) framework provided by or included in the operating system 143 installed on the client device 106.”) which controls access to configuration settings of the device (see e.g. [0030] “the API exposed by the firmware agent 149 may allow the management agent 146 to update the installed version of the firmware 139, modify a configuration setting for the firmware 139 to match a value specified by a firmware attribute 133 of a firmware profile 126, or check a value for a particular firmware property 129 of the installed firmware 139 or configuration setting of the installed firmware 139.”). [nb. as is known in the art, MDM policy settings may include limits on display lighting configurations, see e.g. Hexnode Help Desk Website Question “Activate Android/Kiosk/Allow Changing Brightness” (2017)).
Bilal is analogous art because it is from the same field of user activity aware information handling systems.
Accordingly, Examiner finds 1) the prior art contained a ‘base’ device (method, or product) upon which the claimed invention can be seen as an “improvement” – the teachings of Kim, upon which the inclusion of receiving a management policy from the host OS may be seen as an improvement; 2) the prior art contained a known technique that is applicable to the base device (method, or product); - the technique taught by Bilal where a central policy service promulgates MDM policies to an MDM framework in the host OS for standardization of component configuration settings across a fleet of devices; 3) one of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique would have yielded predictable results and resulted in an improved system at least because it would enable monitoring to ensure that configuration settings match attributes specified in the MDM profile thereby improving the security of the device ([0014] “By using an EMM system to enforce policies for an enrolled device's firmware, the security of client devices under the control of the EMM system can be increased.”) and accordingly the improvement would have been obvious to one having ordinary skill in the art (See MPEP 2143.I.D).
Alternatively, Should Applicant feel that Kim does not adequately disclose the negative limitation ‘without any involvement by any host operation system (OS)’, Dadu teaches a smart phone (fig. 1, [0011] “mobile device 10 such as, for example, a wireless smart phone, tablet, … PDA, etc.”) including an embedded controller (fig. 3b, “Low power audio processor”) which receives sensor data for detecting user activity ([0022] “The illustrated low power audio processor 60 includes a monitor module 60a that monitors an input audio signal from an onboard microphone 34 of the mobile device while the host processor is in the standby mode.”) which does not use the host OS ([0016] “[0016] Block 26 may trigger a device location session with respect to the mobile device based on the predetermined audio pattern. For example, if the predetermined audio pattern is a command such as "Help me locate you", the device location session might involve generating an output audio signal (e.g., tone, beacon) that may be audibly followed by the originator/source (e.g., user) of the predetermined audio pattern in order to locate the mobile device. Such an approach may be conducted without activating the host processor or OS.”; c.f. fig. 3a; [0022] “FIG. 3B shows a mobile device architecture 58 in which a low power audio processor 60 (60a-60e) functions as a firmware solution that enables low power operation while a host processor (not shown) remains in a standby mode.”) in order to reduce potential impact on battery life ([0015] “ Monitoring the input audio signal may involve implementing a low power solution that minimizes the potential impact on battery life. For example, a low power processor (e.g., digital signal processor/DSP operating at a relatively low frequency) might sample the input audio signal on an intermittent basis and reduce the power consumption of one or more audio front end components in between samples in order to reduce power consumption.”)
Dadu is analogous art because it is from the same field of endeavor of user activity aware information handling systems.
Accordingly, Examiner finds 1) the prior art contained a ‘base’ device (method, or product) upon which the claimed invention can be seen as an “improvement” – the teachings of Kim, upon which the exclusion of the host OS from the transmission path of the sensor data to the controller can be seen as an “improvement”; 2) the prior art contained a known technique that is applicable to the base device (method, or product); - the technique taught by Dadu in which a separate embedded controller operates in a low power mode independently of the central processing unit and host OS run thereon to identify user activity; 3) one of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique would have yielded predictable results and resulted in an improved system at least because Dadu teaches that processing sensor signals for user activity detection in this way will minimize impact on battery consumption (Dadu [0015]); and accordingly the improvement would have been obvious to one having ordinary skill in the art (See MPEP 2143.I.D).
Regarding Claim 18, Kim in view of Matsuoka and Bilal, alternatively further in view of Dadu, teaches all of the limitations of parent claim 17,
Kim further teaches:
wherein the first lighting setting comprises at least one of: an on/off setting, a brightness or intensity level, or a color setting, (Kim [0404] “operation may include recognizing a user's face or gaze of the electronic device and adjusting at least one of the transparency, luminance, brightness, or reflectivity of the first display”;)
And Matsuoka further teaches:
and wherein the IHS component comprises at least one of: a keyboard, a touch bar, a totem, or a mouse. (Matsuoka [0028] “The user may have difficulty in visually locating individual keys on the keyboard in the poor lighting conditions. The user may attempt to locate or operate individual keys on the keyboard blindly without visual confirmation of their locations. However, such use of the keyboard without visual confirmation of the individual keys' locations is prone to error. To assist the user with visually locating individual keys on the keyboard, the keyboard may be illuminated or lighted.”)
Regarding Claim 19, Kim teaches:
A method, comprising: receiving, from an orchestrator of a heterogeneous computing platform ((see fig. 18, depicting a system on chip for a mobile computing device; e.g. [0432] “the AP 1810 may be implemented with a system on chip (SoC), for example. … the processor 1810 may further include a graphic processing unit (GPU) (not shown). in an Information Handling System (IHS), (Kim “[0071] An electronic device according to various embodiments of the present disclosure may have a communication function. For instance, electronic devices may include at least one of smartphones, tablet personal computers (PCs), mobile phones, video phones, electronic book (e-book) readers, desktop PCs, laptop PCs” such as a mobile computing device / smart phone, see e.g. fig. 2a) context or telemetry data collected by one or more of a plurality of devices integrated into the heterogeneous computing platform; ([0342] “According to an embodiment, the display control module 170 may determine a user's position or gaze direction through at least one sensor 1004 (for example, a front camera sensor an ambient light sensor, or a motion recognition sensor”)
Wherein the receiving the context or telemetry data is independent of a host operating system (OS) that is executing on the heterogenous platform (inasmuch as the display module 170 is depicted in fig. 1a as separate from the general purpose processor 120 and no mention is made in 0342 of a host OS intermediary between the camera sensor and the control module, Kim discloses this negative limitation.)
and in response to the context or telemetry data […] modifying a lighting setting for a backlight [of an HIS component] ([0404] “operation may include recognizing a user's face or gaze of the electronic device and adjusting at least one of the transparency, luminance, brightness, or reflectivity of the first display”; examiner notes the display is also a touchpad, see [0326] discussing integrated touch sheets in the first and second displays.) without any involvement by the host OS. (inasmuch as the display module 170 is depicted in fig. 1a as separate from the general purpose processor 120 and no mention is made in 0342 of a host OS intermediary between the camera sensor and the control module, Kim discloses this negative limitation.)
Kim differs from the claimed invention in that:
Kim does not appear to clearly articulate the controlled component is a backlight of a user input device of the IHS.
Nor does Kim appear to clearly articulate triggering the modification responsive to [context or telemetry data] and a light intensity indication from an ambient light sensor of the IHS;
Kim does not appear to clearly articulate the orchestrator receives a policy corresponding to lighting settings [for the component] from the host OS.
However, Matsuoka teaches a user input device (keyboard, see figs. 1, 3) for a computer (see background) which includes a backlight ([0029] “Illuminated keyboard 200 may further include a backlight layer 240. Backlight layer 240 may include an array of light sources (e.g., LEDs 242) that are configured to backlight and illuminate one or more keys 212.” ) which may be adjusted (e.g. off/on, see [0005] “light source controller that configured to place light sources ("backlights") that illuminate the keyboard in an on-state or an off-state”) responsive to both gaze ([0040] “direction of the user’s eyesight”) and a signal from an ambient light sensor ([0040] “Light source controller 306 may, for example, turn on the light sources in backlight layer 303 when an ambient light sensor (not shown) indicates poor or failing light conditions. Light source controller 306 may be further configured to limit power consumption by the light sources by maintaining the light sources in an on-state or an off-state according to the status of the direction of the user's eyesight, which it may receive from eyeball tracker unit 305.”)
Matsuoka is analogous art because it is from the same field of user activity aware information handling systems.
One of ordinary skill in the art before the effective filing date of the application could have modified the teachings of Kim by using an illuminated keyboard with a backlight configured to operate responsive to user gaze and ambient lighting conditions, as suggested by Matsuoka.
One of ordinary skill in the art before the effective filing date of the application could have made this modification in order to assist the user in operating the device in poor lighting conditions (Matsuoka [0028] “The user may have difficulty in visually locating individual keys on the keyboard in the poor lighting conditions… To assist the user with visually locating individual keys on the keyboard, the keyboard may be illuminated or lighted.”) while also minimizing power consumption by only illuminating the keys when the user is actually looking at them (Matsuoka [0040] “ light source controller 306 may reduce power consumption… by keeping light sources in an illuminated keyboard 302 in an on-state only when needed to help the user to visually confirm key locations on a keyboard… [0042] “determining if the user’s eyesight is directed toward or away from the illuminated keyboard (440) and accordingly placing light sources… in an on-state (460) or an off-state (450)”)
And, Bilal teaches a client device (see fig. 1, Client device(s) 106) which may be a general purpose desktop or laptop ([0026] “Examples of client devices 106 include processor-based systems, such as desktop computers, a laptop computers, a personal digital assistant, a cellular telephone, a smartphone, a tablet computer system”) running an operating system ([0028] “[0028] A client device 106 can include an operating system 143 configured to execute various client applications. Examples of operating systems 143 include MICROSOFT WINDOWS”) where the OS maintains a mobile-device-management (MDM) policy received by an MDM framework from a management service ([0029] “the management agent 146 includes a mobile device management (MDM) framework provided by or included in the operating system 143 installed on the client device 106.”) which controls access to configuration settings of the device (see e.g. [0030] “the API exposed by the firmware agent 149 may allow the management agent 146 to update the installed version of the firmware 139, modify a configuration setting for the firmware 139 to match a value specified by a firmware attribute 133 of a firmware profile 126, or check a value for a particular firmware property 129 of the installed firmware 139 or configuration setting of the installed firmware 139.”). [nb. as is known in the art, MDM policy settings may include limits on display lighting configurations, see e.g. Hexnode Help Desk Website Question “Activate Android/Kiosk/Allow Changing Brightness” (2017)).
Bilal is analogous art because it is from the same field of user activity aware information handling systems.
Accordingly, Examiner finds 1) the prior art contained a ‘base’ device (method, or product) upon which the claimed invention can be seen as an “improvement” – the teachings of Kim, upon which the inclusion of receiving a management policy from the host OS may be seen as an improvement; 2) the prior art contained a known technique that is applicable to the base device (method, or product); - the technique taught by Bilal where a central policy service promulgates MDM policies to an MDM framework in the host OS for standardization of component configuration settings across a fleet of devices; 3) one of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique would have yielded predictable results and resulted in an improved system at least because it would enable monitoring to ensure that configuration settings match attributes specified in the MDM profile thereby improving the security of the device ([0014] “By using an EMM system to enforce policies for an enrolled device's firmware, the security of client devices under the control of the EMM system can be increased.”) and accordingly the improvement would have been obvious to one having ordinary skill in the art (See MPEP 2143.I.D).
Alternatively, Should Applicant feel that Kim does not adequately disclose the negative limitation ‘without any involvement by any host operation system (OS)’, Dadu teaches a smart phone (fig. 1, [0011] “mobile device 10 such as, for example, a wireless smart phone, tablet, … PDA, etc.”) including an embedded controller (fig. 3b, “Low power audio processor”) which receives sensor data for detecting user activity ([0022] “The illustrated low power audio processor 60 includes a monitor module 60a that monitors an input audio signal from an onboard microphone 34 of the mobile device while the host processor is in the standby mode.”) which does not use the host OS ([0016] “[0016] Block 26 may trigger a device location session with respect to the mobile device based on the predetermined audio pattern. For example, if the predetermined audio pattern is a command such as "Help me locate you", the device location session might involve generating an output audio signal (e.g., tone, beacon) that may be audibly followed by the originator/source (e.g., user) of the predetermined audio pattern in order to locate the mobile device. Such an approach may be conducted without activating the host processor or OS.”; c.f. fig. 3a; [0022] “FIG. 3B shows a mobile device architecture 58 in which a low power audio processor 60 (60a-60e) functions as a firmware solution that enables low power operation while a host processor (not shown) remains in a standby mode.”) in order to reduce potential impact on battery life ([0015] “ Monitoring the input audio signal may involve implementing a low power solution that minimizes the potential impact on battery life. For example, a low power processor (e.g., digital signal processor/DSP operating at a relatively low frequency) might sample the input audio signal on an intermittent basis and reduce the power consumption of one or more audio front end components in between samples in order to reduce power consumption.”)
Dadu is analogous art because it is from the same field of endeavor of user activity aware information handling systems.
Accordingly, Examiner finds 1) the prior art contained a ‘base’ device (method, or product) upon which the claimed invention can be seen as an “improvement” – the teachings of Kim, upon which the exclusion of the host OS from the transmission path of the sensor data to the controller can be seen as an “improvement”; 2) the prior art contained a known technique that is applicable to the base device (method, or product); - the technique taught by Dadu in which a separate embedded controller operates in a low power mode independently of the central processing unit and host OS run thereon to identify user activity; 3) one of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique would have yielded predictable results and resulted in an improved system at least because Dadu teaches that processing sensor signals for user activity detection in this way will minimize impact on battery consumption (Dadu [0015]); and accordingly the improvement would have been obvious to one having ordinary skill in the art (See MPEP 2143.I.D).
Regarding Claim 20, Kim in view of Matsuoka and Bilal, alternatively further in view of Dadu, teaches all of the limitations of parent claim 19,
Kim further teaches:
wherein the context or telemetry data comprises at least one of: user presence or engagement data, ([0342] “the display control module 170 may determine a user's position or gaze direction through at least one sensor 1004 (for example, a front camera sensor an ambient light sensor, or a motion recognition sensor”) i.e. at least presence and attention of the user based on detected gaze.)
wherein the lighting setting comprises at least one of: an on/off setting, a brightness or intensity level, or a color setting, ([0404] “operation may include recognizing a user's face or gaze of the electronic device and adjusting at least one of the transparency, luminance, brightness, or reflectivity of the first display”;)
And Matsuoka further teaches:
and wherein the IHS component comprises at least one of: a keyboard, a touch bar, a totem, or a mouse. (Matsuoka [0028] “The user may have difficulty in visually locating individual keys on the keyboard in the poor lighting conditions. The user may attempt to locate or operate individual keys on the keyboard blindly without visual confirmation of their locations. However, such use of the keyboard without visual confirmation of the individual keys' locations is prone to error. To assist the user with visually locating individual keys on the keyboard, the keyboard may be illuminated or lighted.”)
Claim(s) 9-11 and 14-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kim, in view of Bilal, in view of Hexnode Help Desk Website Question “Activate Android/Kiosk/Allow Changing Brightness” (2017); alternatively further in view of Dadu.
Regarding Claim 9, Kim in view of Matsuoka and Bilal alternatively further in view of Dadu teaches all of the limitations of parent claim 1,
Kim differs from the claimed invention in that:
Kim does not clearly articulate: wherein the orchestrator is configured to trigger the modification in accordance with a policy received from an Information Technology Decision Maker (ITDM) or Original Equipment Manufacturer (OEM).
However, device control policies from IT decision makers that restrict operation of brightness settings on mobile devices are known in the art (see e.g. the Hexnode reference, page 1, regarding the disabling of user brightness controls in a mobile device by the MDM policy manager).
Accordingly, Examiner finds 1) the prior art included each element claimed, although not necessarily in a single prior art reference, with the only difference between the claimed invention and the prior art being the lack of actual combination of the elements in a single prior art reference; 2) one of ordinary skill in the art could have combined the elements as claimed by known methods, i.e. by applying a commercially available mobile device management policy suite to the mobile phone device of Kim, and that in combination, each element merely performs the same function as it does separately; and 3) one of ordinary skill in the art would have recognized that the results of the combination were predictable at least because operation of the endpoint mobile device in compliance with the device management policy suite issued by the IT decision maker is the normal expected resulting operation of applying such an MDM to a mobile device; and accordingly the combination would have been obvious to one of ordinary skill in the art prior to the effective filing date of the application (See MPEP 2143.I.A).
Regarding Claim 10, Kim in view of Matsuoka and Bilal alternatively further Dadu, in view of Hexnode teaches all of the limitations of parent claim 9,
Hexnode further teaches:
wherein the policy associates a plurality of lighting settings with a corresponding one of a plurality of user presence states or user engagement status. (see page 1, the MDM policy may be modified to permit or disallow specific lighting settings, such as brightness adjustment by permission controls set by IT Decision maker interacting with the policy configuration.)
Regarding Claim 11, Kim in view of Matsuoka and Bilal alternatively further Dadu, in view of Hexnode teaches all of the limitations of parent claim 9,
Kim further teaches:
wherein the orchestrator is configured to receive context or telemetry data, ([0270] “an electronic device 801 may include a camera sensor for recognizing a use's[sic] face (for example, a front camera sensor 804 and a dynamic vision sensor (DVS)) or a motion recognition sensor (for example, an ambient light sensor, a 3D depth sensor, a gesture sensor, an acceleration sensor, a gyro sensor, and an earth magnetic sensor).”)
Hexnode further teaches:
and wherein the policy associates at least one of: the lighting settings, or the modification to the first lighting setting (e.g. brightness), with the context or telemetry data. (see page 1, the MDM policy may be modified to permit or disallow specific lighting settings, such as brightness adjustment by permission controls set by IT Decision maker interacting with the policy configuration.)
Regarding Claim 14, Kim in view of Matsuoka and Bilal alternatively further Dadu, in view of Hexnode teaches all of the limitations of parent claim 11,
Hexnode further teaches:
wherein the context or telemetry data comprises a metric indicative of at least one of: a core utilization, a memory utilization, a network utilization, a battery utilization, a peripheral device utilization, or an application in execution. (see page 1, the MDM policy may be modified to permit or disallow specific lighting settings, such as brightness adjustment by application-specific permission controls set by IT Decision maker interacting with the policy configuration.)
Regarding Claim 15, Kim in view of Matsuoka and Bilal, alternatively further Dadu, in view of Hexnode teaches all of the limitations of parent claim 11,
Kim further teaches:
wherein the context or telemetry data comprises a metric indicative of at least one of: an IHS location, or an IHS posture. (Kim varies the color of the display based on detected location, see e.g. [0187] “For example, if it is determined that the user's position is in the forest, the color of additional image information may change into green and if it is determined that the user's position is in the beach, the color of additional image information may change into blue” Kim also detects posture in some cases, see e.g. [0296])
Regarding Claim 16, Kim in view of Matsuoka and Bilal, alternatively in view of Dadu, further in view of Hexnode teaches all of the limitations of parent claim 11,
Kim further teaches:
wherein to receive the context or telemetry data, the orchestrator is configured to receive a message ([0342] “the display control module 170 may determine a user's position or gaze direction through at least one sensor 1004 (for example, a front camera sensor an ambient light sensor, or a motion recognition sensor”) from a firmware service executed by a given one of the plurality of devices (i.e. the ambient light sensor) via an Application Programming Interface (API) ([0081] “The kernel 131 may control or manage system resources (for example, the bus 110, the processor 120, or the memory 130) used for performing operation or functions implemented by the remaining other programming modules, for example, the middleware 132, the API 133, or the application 134.”)
without any involvement by any host Operating System (OS). (inasmuch as the display module 170 is depicted in fig. 1a as separate from the general purpose processor 120 and no mention is made in 0342 of a host OS intermediary between the camera sensor and the control module, Kim discloses this negative limitation.)
Alternatively, Should Applicant feel that Kim does not adequately disclose the negative limitation ‘without any involvement by any host operation system (OS)’, Dadu teaches a smart phone (fig. 1, [0011] “mobile device 10 such as, for example, a wireless smart phone, tablet, … PDA, etc.”) including an embedded controller (fig. 3b, “Low power audio processor”) which receives sensor data for detecting user activity ([0022] “The illustrated low power audio processor 60 includes a monitor module 60a that monitors an input audio signal from an onboard microphone 34 of the mobile device while the host processor is in the standby mode.”) which does not use the host OS ([0016] “[0016] Block 26 may trigger a device location session with respect to the mobile device based on the predetermined audio pattern. For example, if the predetermined audio pattern is a command such as "Help me locate you", the device location session might involve generating an output audio signal (e.g., tone, beacon) that may be audibly followed by the originator/source (e.g., user) of the predetermined audio pattern in order to locate the mobile device. Such an approach may be conducted without activating the host processor or OS.”; c.f. fig. 3a; [0022] “FIG. 3B shows a mobile device architecture 58 in which a low power audio processor 60 (60a-60e) functions as a firmware solution that enables low power operation while a host processor (not shown) remains in a standby mode.”) in order to reduce potential impact on battery life ([0015] “ Monitoring the input audio signal may involve implementing a low power solution that minimizes the potential impact on battery life. For example, a low power processor (e.g., digital signal processor/DSP operating at a relatively low frequency) might sample the input audio signal on an intermittent basis and reduce the power consumption of one or more audio front end components in between samples in order to reduce power consumption.”)
Dadu is analogous art because it is from the same field of endeavor of user activity aware information handling systems.
Accordingly, Examiner finds 1) the prior art contained a ‘base’ device (method, or product) upon which the claimed invention can be seen as an “improvement” – the teachings of Kim, upon which the exclusion of the host OS from the transmission path of the sensor data to the controller can be seen as an “improvement”; 2) the prior art contained a known technique that is applicable to the base device (method, or product); - the technique taught by Dadu in which a separate embedded controller operates in a low power mode independently of the central processing unit and host OS run thereon to identify user activity; 3) one of ordinary skill in the art before the effective filing date of the application would have recognized that applying the known technique would have yielded predictable results and resulted in an improved system at least because Dadu teaches that processing sensor signals for user activity detection in this way will minimize impact on battery consumption (Dadu [0015]); and accordingly the improvement would have been obvious to one having ordinary skill in the art (See MPEP 2143.I.D).
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kim in view of Matsuoka and Bilal, in view of Hexnode, in view of Norgaard, US Pg-Pub 2010/0194288, alternatively further in view of Dadu.
Regarding Claim 13, Kim in view of Matsuoka and Bilal alternatively further Dadu, in view of Hexnode teaches all of the limitations of parent claim 11,
The combination differs from the claimed invention in that:
Neither reference clearly articulates wherein the ALS reading comprises at least one of: a light frequency, wavelength, or spectral band.
However, Norgaard teaches that ALS sensors (see fig. 1, [0130] “A sensor element 10 performs a measurement on the ambient light”) may detect any or all of spectra, intensity, frequency, or wavelength ([0058] “the light characteristics may correspond to the spectral distribution of the ambient light, e.g. to a multitude of parameter pairs, where each pair represents an intensity value and a frequency or wavelength value.”) as appropriate.
Accordingly Examiner finds 1) the prior art contained a device (method, or product, etc.) which differed from the claimed device by the substitution of some components (step, element, etc.) with the other components; - the device taught by Kim, which differs by the substitution of an ALS sensor which reads at least one of intensity, frequency, wavelength, or spectra for the generically disclosed ALS of Kim. 2) the substituted components and their functions were known in the art – as exemplified by the teachings of Norgaard, which describes an Ambient light sensor which may measure at least one of intensity, frequency, wavelength, or spectra; 3) one of ordinary skill in the art could have substituted one known element for another, and the results of the substitution would have been predictable at least because both components are ALS sensors used to detect properties of ambient light near a device; and accordingly the substitution would have been obvious to one having ordinary skill in the art before the effective filing date of the application (see MPEP 2143.I.B).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Johnson et al., US Pg-Pub 2019/0051267 – for using a color ambient light sensor to adjust the color and/or color temperature of the backlight of an illuminated keyboard according to ambient lighting color temperature.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSHUA T SANDERS whose telephone number is (571)272-5591. The examiner can normally be reached Generally Monday through Friday.
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, Mohammad Ali can be reached at 571-272-4105. 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.T.S./Examiner, Art Unit 2119
/MOHAMMAD ALI/Supervisory Patent Examiner, Art Unit 2119
Prosecution Insights