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.
Claims 1-20 are pending.
Claims 1-20 are rejected, grounds follow.
THIS OFFICE ACTION IS FINAL, see additional information at the conclusion of this action.
Response to Arguments
Applicant’s arguments, see Remarks Page 7, filed 25 February 2025, with respect to the rejection(s) of claim(s) 1, 17, and 19 (Claim 1 representative) under 35 USC 102(a)(1)/35 USC 103 have been fully considered and are persuasive. As stated in the interview, Examiner agrees that the Amendment overcomes the rejection set forth in the non-final rejection mailed 30 December 2025. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made further in view of Bilal et al., US Pg-Pub 2020/0034141; please see below for detailed rejection.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, this action is made Final.
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 discloses:
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 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 receiving from the host OS a policy corresponding to lighting settings of an HIS component;
However, 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 2, Kim in view of 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 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 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 Bilal, alternatively further in view of Dadu, teaches all of the limitations of parent claim 1,
Kim further teaches:
wherein the IHS component comprises at least one of: a display, a keyboard, a touch bar, a touchpad, a trackpad, a totem, or a mouse. ([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 may include an integrated touchpad, see [0326] discussing integrated touch sheets in the first and second displays.)
Regarding Claim 6, Kim in view of 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”)
Regarding Claim 7, Kim in view of 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 Bilal, alternatively further in view of Dadu, teaches all of the limitations of parent claim 1,
Kim further discloses:
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”;)
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 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 orchestrator receives a policy corresponding to lighting settings of an HIS component from the host OS.
However, 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 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, ([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 wherein the IHS component comprises at least one of: a keyboard, a touch bar, a touchpad, a totem, or a mouse. ([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.)
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 of at least one of: a keyboard, a touch bar, a touchpad, a totem, or a mouse ([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 orchestrator receives a policy corresponding to lighting settings of an HIS component from the host OS.
However, 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 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 wherein the IHS component comprises at least one of: a keyboard, a touch bar, a touchpad, a totem, or a mouse. ([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.)
Claim(s) 9-12 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 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 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 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 12, Kim in view of 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 an Ambient Light Sensor (ALS) reading. ([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).”)
Regarding Claim 14, Kim in view of 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 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 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 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 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 intensity, 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
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 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