DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 14-16 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Robinson et al. US 20140157349.
Regarding claim 14, Robinson et al. disclose A method for ensuring display of a sensor indicator on a user device, comprising: receiving, via sensor exclave software running in a trusted execution environment, a request to access a sensor of an electronic device; based on the request to access the sensor, requesting, via the sensor exclave software, that the sensor indicator be displayed; (Robinson et al. US 20140157349 abstract; paragraphs [0011]-[0018]; [0020]-[0024]; [0028]-[0035]; [0037]; [0049]-[0051]; [0058]-[0065]; figures 1-8;)
In some embodiments, sensor data may be pulled from or pushed to the environment via these connections. In some embodiments, the sensor data itself contains sensitive information such as a picture or image of an individual (Robinson et al. par. 13). In an embodiment, the trusted light may feature symbols conveying status. In an embodiment the trusted light may be a lighted or backlight personalized or company trademark symbol. In an embodiment, when the light is on, the protections are on; and when the light is off, protections are off. In an embodiment, the light may change color depending on the current policies, red to indicate an untrusted environment, green to mean trusted, orange to indicate an intermediate state. In an embodiment, the indicator may be something other than a light such as a textual based display or a haptic interface that allows touch or feel to indicate system status (Robinson et al par. 32). Similarly, referring to FIG. 3, another graphical user interface display may ask the user to enable a camera-based trusted gesture mode. Filter mode changes (i.e. policy changes) for the camera data may require user consent, in some embodiments. Here, the gesture recognition mode agent attests to the camera subsystem, including software stack, that it has the user's blessing to process raw data (Robinson et al. par. 36). In an embodiment, multiple agents may concurrently request data from a single sensor or multiple sensors. Trusted agents may run in separate trusted execution environments (Robinson et al. par. 37).
According to the cited passages and figures, examiner interprets the camera as the sensor, therefore the camera is enable upon received the gesture from the user and displaying image and trust indicator.
including, via display exclave software, the sensor indicator in image data for display on an electronic display of the user device; periodically checking, via the display exclave software, if the sensor indicator is being displayed; in response to the sensor indicator being displayed, generating, via the display exclave software, a message to the sensor exclave software that the sensor indicator is being displayed; and in response to receiving the message, providing access, via the sensor exclave software, to sensor data.
Referring to FIG. 2, a trustworthy graphical user interface screen display 20 may be provided to prevent software which is unverified (untrusted) from connecting to the system and potentially gaining access to sensor data. In the filtering mode, changes to the filter policy settings may require user consent or at least user notification, for example, through the trusted (secure) light indicator 18. In an embodiment, policy mode changes are implemented to resist phishing attacks and other user interface spoofing. The user may allow or disallow untrusted software to connect by clicking one of the buttons labeled "ok" or "cancel." The user can also set the level of security by sliding the lock icon using a mouse cursor, for example. This has utility, for example, when using legacy applications which do not control potential sensor data leakage (Robinson et al. par. 35). Similarly, referring to FIG. 3, another graphical user interface display may ask the user to enable a camera-based trusted gesture mode. Filter mode changes (i.e. policy changes) for the camera data may require user consent, in some embodiments. Here, the gesture recognition mode agent attests to the camera subsystem, including software stack, that it has the user's blessing to process raw data (Robinson et al. par. 36). In an embodiment, multiple agents may concurrently request data from a single sensor or multiple sensors. Trusted agents may run in separate trusted execution environments (Robinson et al. par. 37).
According to the cite passages and figure, examiner interprets the user click on cancel in the figure 2 and the untrusted software will not running within the trust environment. According to the figures 2 and 3, examiner interprets the system continuously checking whether the system is running in the trusted environment or not. Based on the display, the user can selecting whether the system is running in the trusted environment or not.
Regarding claim 15, Robinson et al. disclose The method of claim 14, wherein the request is from non-trusted software.
Referring to FIG. 2, a trustworthy graphical user interface screen display 20 may be provided to prevent software which is unverified (untrusted) from connecting to the system and potentially gaining access to sensor data. In the filtering mode, changes to the filter policy settings may require user consent or at least user notification, for example, through the trusted (secure) light indicator 18. In an embodiment, policy mode changes are implemented to resist phishing attacks and other user interface spoofing. The user may allow or disallow untrusted software to connect by clicking one of the buttons labeled "ok" or "cancel." The user can also set the level of security by sliding the lock icon using a mouse cursor, for example. This has utility, for example, when using legacy applications which do not control potential sensor data leakage (Robinson et al. par. 35).
According to the cite passages and figure, examiner interprets the figure 2 present the prompt for user to select whether allow untrusted software to connect or not.
Regarding claim 16, Robinson et al. disclose The method of claim 14, wherein the request to display the sensor indicator is sent to the display exclave software, and wherein the display exclave software controls image processing circuitry of the user device.
Similarly, referring to FIG. 3, another graphical user interface display may ask the user to enable a camera-based trusted gesture mode. Filter mode changes (i.e. policy changes) for the camera data may require user consent, in some embodiments. Here, the gesture recognition mode agent attests to the camera subsystem, including software stack, that it has the user's blessing to process raw data (Robinson et al. par. 36). In an embodiment, multiple agents may concurrently request data from a single sensor or multiple sensors. Trusted agents may run in separate trusted execution environments (Robinson et al. par. 37).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 6, 8-11, 13 and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Robinson et al. US 20140157349 in view of Mosher et al. US 20150358455.
Regarding claim 1, Robinson et al. teach A method comprising: receiving a request to access a sensor of an electronic device; based on the request to access the sensor, displaying an indicator on an electronic display of the electronic device indicating that the sensor is in use; periodically generating a message indicating that the indicator is being displayed; (Robinson et al. US 20140157349 abstract; paragraphs [0011]-[0018]; [0020]-[0024]; [0028]-[0035]; [0037]; [0049]-[0051]; [0058]-[0065]; figures 1-8;)
]Referring to FIG. 1, a computer system 10 may be coupled to a sensor 16, such as a video camera. The sensor could also be a microphone, location or global positioning system device, biometric sensor, DNA strand sequencer, blood glucose monitor, brain waves or thought signal sensor (e.g. Emotiv's EPOC), accelerometer, compass, barometer, touch sensor, etc, to give a few examples. Some sensors may have limited use lifetime (e.g. use only one time) while others can be used repeatedly. Some sensors may be integrated directly into the platform or system-on-chip (SoC) or connected through I/O or network communication ports which may be cabled or wireless such as Universal Serial Bus (USB), WiFi, BlueTooth, etc. In some embodiments, sensor data may be pulled from or pushed to the environment via these connections. In some embodiments, the sensor data itself contains sensitive information such as a picture or image of an individual (Robinson et al. par. 13). The policy controls distribution by using sensor data filtering, data access control or cryptographic mechanisms. The selection of controls to be used is determined by the threat models that need to be guarded against and are understood by those skilled in the art. These include specific means to protect information confidentiality, integrity and availability, and depend on the security and privacy objectives. For instance, a home personal computer system might be relatively safe from physical hardware attacks, but open to down-the-wire network or software attacks. In such systems, communication over dedicated links between trusted subsystems may be sufficient to prevent sensor data leakage. In other embodiments, encryption of the sensor data may be required. For sensor data that is released into uncontrolled environments, data may require encryption with securely managed key distribution to remain protected (Robinson et al. par. 17). In some embodiments, a trusted light indicator 18 (FIG. 1) may show the status of the system. The trusted light indicator is designed so that it can only be controlled (e.g. toggled) by system entities within the trusted computing base (TCB) so that malicious agents cannot modify the policy status indication. In an embodiment, the trusted light may feature symbols conveying status. In an embodiment the trusted light may be a lighted or backlight personalized or company trademark symbol. In an embodiment, when the light is on, the protections are on; and when the light is off, protections are off. In an embodiment, the light may change color depending on the current policies, red to indicate an untrusted environment, green to mean trusted, orange to indicate an intermediate state. In an embodiment, the indicator may be something other than a light such as a textual based display or a haptic interface that allows touch or feel to indicate system status. In an embodiment, the indicator may signal policy changes and status by vibrations or sequences of vibrations. For instance, a short vibration followed by a short, interstitial pause followed by a long vibration may indicate a movement from an unsecure mode to a secure policy mode. The reverse sequence of vibrations (long vibration, pause, short vibration) may signal a secure-to-unsecure policy transition. Similarly, in an embodiment, different patterns may indicate different policies or policy security levels. In an embodiment the indicator may be a transmission signal to another device which can provide detailed information about the status of sensors in a user's immediate physical environment (Robinson et al. par. 32).
enabling access to the sensor for a defined period of time upon receipt of the message indicating that the indicator is being displayed;
In some embodiments, sensor data may be pulled from or pushed to the environment via these connections. In some embodiments, the sensor data itself contains sensitive information such as a picture or image of an individual (Robinson et al. par. 13). In an embodiment, the trusted light may feature symbols conveying status. In an embodiment the trusted light may be a lighted or backlight personalized or company trademark symbol. In an embodiment, when the light is on, the protections are on; and when the light is off, protections are off. In an embodiment, the light may change color depending on the current policies, red to indicate an untrusted environment, green to mean trusted, orange to indicate an intermediate state. In an embodiment, the indicator may be something other than a light such as a textual based display or a haptic interface that allows touch or feel to indicate system status (Robinson et al par. 32) Similarly, referring to FIG. 3, another graphical user interface display may ask the user to enable a camera-based trusted gesture mode. Filter mode changes (i.e. policy changes) for the camera data may require user consent, in some embodiments. Here, the gesture recognition mode agent attests to the camera subsystem, including software stack, that it has the user's blessing to process raw data (Robinson et al. par. 36). In an embodiment, multiple agents may concurrently request data from a single sensor or multiple sensors. Trusted agents may run in separate trusted execution environments (Robinson et al. par. 37).
According to the cited passages and figures, examiner interprets the camera as the sensor, therefore the camera is enable upon received the gesture from the user and displaying image and trust indicator.
Robinson et al. do not explicitly teach disabling access to the sensor after the defined period of time if a subsequent message indicating that the indicator is being displayed is not received.
Mosher et al. teach disabling access to the sensor after the defined period of time if a subsequent message indicating that the indicator is being displayed is not received. (Mosher et al. US 20150358455 abstract; paragraphs [0007]-[0012]; [0019]; [0033]-[0038]; [0040]-[0047]; figures 1-3)
FIG. 1 illustrates an overview of a telecommunication device determining that a threshold amount of time has passed since a heartbeat communication and, in response, preventing access to telecommunication device service(s) or deleting user data. As illustrated, a telecommunication device 102 may fail to receive a heartbeat communication 104 from a remote telecommunication server 106. The telecommunication device 102 may then determine 108 that it has not received a heartbeat communication 104 for a threshold amount of time. In response to the determining 108, the telecommunication device 102 may perform 110 at least one of preventing access to one or more telecommunication device services 112 or deleting user data 114 (Mosher et al. par. 12).
Therefore, it would have been obviously to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Robinson et al. reference by apply preventing access to one or more telecommunication device service in response to not received a heartbeat communication for a threshold amount of time as taught by Mosher et al. reference in order to improve security against theft.
Regarding claim 2, the combination of Robinson et al. and Mosher et al. disclose The method of claim 1, wherein the request to access the sensor is received into sensor exclave software running in a trusted execution environment,
A camera and microphone can gather all raw audio and video data, but the filtering component running in the trusted execution environment of the embodiment may use facial recognition to find user gaze or gesture information and selectively pass only that information on to other components in the system (Robinson et al. par. 31).
and wherein the request is from second software running outside of the trusted execution environment.
If the device supports unfiltered output to untrusted software, a trusted indicator light 18 may be provided to signal or attest to the user which mode the system is in. Like other embodiments discussed above, the user knows when he or she is not protected and the user can believe the results because the policy mode and integrity indicators are trustworthy; that is, they resist spoofing attacks. In an embodiment trusted indicators, also referred to as attestations to the user here, are implemented using secure input/output (I/O) methods (Robinson et al. par. 33). Referring to FIG. 2, a trustworthy graphical user interface screen display 20 may be provided to prevent software which is unverified (untrusted) from connecting to the system and potentially gaining access to sensor data. In the filtering mode, changes to the filter policy settings may require user consent or at least user notification, for example, through the trusted (secure) light indicator 18. In an embodiment, policy mode changes are implemented to resist phishing attacks and other user interface spoofing. The user may allow or disallow untrusted software to connect by clicking one of the buttons labeled "ok" or "cancel." The user can also set the level of security by sliding the lock icon using a mouse cursor, for example. This has utility, for example, when using legacy applications which do not control potential sensor data leakage (Robinson et al. par. 35).
Regarding claim 3, the combination of Robinson et al. and Mosher et al. disclose The method of claim 2, wherein displaying the indicator is controlled by display exclave software controlling image processing circuitry in the trusted execution environment.
Similarly, referring to FIG. 3, another graphical user interface display may ask the user to enable a camera-based trusted gesture mode. Filter mode changes (i.e. policy changes) for the camera data may require user consent, in some embodiments. Here, the gesture recognition mode agent attests to the camera subsystem, including software stack, that it has the user's blessing to process raw data (Robinson et al. par. 36). In an embodiment, multiple agents may concurrently request data from a single sensor or multiple sensors. Trusted agents may run in separate trusted execution environments (Robinson et al. par. 37).
Regarding claim 4, the combination of Robinson et al. and Mosher et al. disclose The method of claim 2, wherein the second software comprises untrusted software not running in the trusted execution environment.
Referring to FIG. 2, a trustworthy graphical user interface screen display 20 may be provided to prevent software which is unverified (untrusted) from connecting to the system and potentially gaining access to sensor data. In the filtering mode, changes to the filter policy settings may require user consent or at least user notification, for example, through the trusted (secure) light indicator 18. In an embodiment, policy mode changes are implemented to resist phishing attacks and other user interface spoofing. The user may allow or disallow untrusted software to connect by clicking one of the buttons labeled "ok" or "cancel." The user can also set the level of security by sliding the lock icon using a mouse cursor, for example. This has utility, for example, when using legacy applications which do not control potential sensor data leakage (Robinson et al. par. 35).
According to the cite passages and figure, examiner interprets the user click on cancel in the figure 2 and the untrusted software will not running within the trust environment.
Regarding claim 6, the combination of Robinson et al. and Mosher et al. disclose The method of claim 1, wherein the message comprises a heartbeat message occurring at a regular cadence, and wherein the subsequent message comprises a subsequent heartbeat message occurring at the regular cadence.
In various embodiments, the remote telecommunication server 106 or another device of the telecommunication service provider may remotely configure the telecommunication device 102, setting or updating any sort of configurations, settings, parameters, etc. For example, the remote telecommunication server 106 may provide instructions setting a threshold amount of time (also referred to herein as a “time threshold”) that the secure component of the telecommunication device 102 is to wait following a most recent heartbeat communication 104 before performing 110 at least one of preventing access to service(s) 112 or deleting user data 114. The remote telecommunication server 106 may also provide instructions specifying which telecommunication device service(s) 112 should be blocked and what user data 112 should be deleted. Instructions provided by the remote telecommunication server 106 may, in a number of embodiments, be provided in a heartbeat communication 104, such as a heartbeat message or response. In some embodiments, the instructions may specify a plurality of time thresholds, with different telecommunication device service(s) 112 blocked and different user data 114 deleted at each threshold. Such multiple thresholds may enable the remote telecommunication server 106 to specify a more gradual approach to preventing use of the telecommunication device 102 (Mosher et al. par. 19). At 330, subsequent to preventing access to the one or more telecommunication device services or to the additional telecommunication device services, the secure component may receive instructions from the remote telecommunication server enabling access to the one or more telecommunication device services. Such instructions may be provided following reception of a subsequent heartbeat communication or instructions from the remote telecommunication server (Mosher et al. par. 47).
According to the cited passages and figures, examiner interprets the heartbeat message provide a specify time as the heartbeat messages occurring at the regular cadence.
Regarding claim 8, Robinson et al. teach An electronic device comprising: an electronic display comprising display pixels configured to display an image and one or more indicators associated with one or more sensors; image processing circuitry communicatively coupled to the electronic display and configured to process image data corresponding to the image and the one or more indicators; (Robinson et al. US 20140157349 abstract; paragraphs [0011]-[0018]; [0020]-[0024]; [0028]-[0035]; [0037]; [0049]-[0051]; [0058]-[0065]; figures 1-8;)
]Referring to FIG. 1, a computer system 10 may be coupled to a sensor 16, such as a video camera. The sensor could also be a microphone, location or global positioning system device, biometric sensor, DNA strand sequencer, blood glucose monitor, brain waves or thought signal sensor (e.g. Emotiv's EPOC), accelerometer, compass, barometer, touch sensor, etc, to give a few examples. Some sensors may have limited use lifetime (e.g. use only one time) while others can be used repeatedly. Some sensors may be integrated directly into the platform or system-on-chip (SoC) or connected through I/O or network communication ports which may be cabled or wireless such as Universal Serial Bus (USB), WiFi, BlueTooth, etc. In some embodiments, sensor data may be pulled from or pushed to the environment via these connections. In some embodiments, the sensor data itself contains sensitive information such as a picture or image of an individual (Robinson et al. par. 13). The policy controls distribution by using sensor data filtering, data access control or cryptographic mechanisms. The selection of controls to be used is determined by the threat models that need to be guarded against and are understood by those skilled in the art. These include specific means to protect information confidentiality, integrity and availability, and depend on the security and privacy objectives. For instance, a home personal computer system might be relatively safe from physical hardware attacks, but open to down-the-wire network or software attacks. In such systems, communication over dedicated links between trusted subsystems may be sufficient to prevent sensor data leakage. In other embodiments, encryption of the sensor data may be required. For sensor data that is released into uncontrolled environments, data may require encryption with securely managed key distribution to remain protected (Robinson et al. par. 17). In some embodiments, a trusted light indicator 18 (FIG. 1) may show the status of the system. The trusted light indicator is designed so that it can only be controlled (e.g. toggled) by system entities within the trusted computing base (TCB) so that malicious agents cannot modify the policy status indication. In an embodiment, the trusted light may feature symbols conveying status. In an embodiment the trusted light may be a lighted or backlight personalized or company trademark symbol. In an embodiment, when the light is on, the protections are on; and when the light is off, protections are off. In an embodiment, the light may change color depending on the current policies, red to indicate an untrusted environment, green to mean trusted, orange to indicate an intermediate state. In an embodiment, the indicator may be something other than a light such as a textual based display or a haptic interface that allows touch or feel to indicate system status. In an embodiment, the indicator may signal policy changes and status by vibrations or sequences of vibrations. For instance, a short vibration followed by a short, interstitial pause followed by a long vibration may indicate a movement from an unsecure mode to a secure policy mode. The reverse sequence of vibrations (long vibration, pause, short vibration) may signal a secure-to-unsecure policy transition. Similarly, in an embodiment, different patterns may indicate different policies or policy security levels. In an embodiment the indicator may be a transmission signal to another device which can provide detailed information about the status of sensors in a user's immediate physical environment (Robinson et al. par. 32).
According to the cited passages and figures, examiner interprets the sensor data itself contains sensitive information such as a picture or image of an individual that contain pixels that present on the display screen of the electronic device like show in the figures 1 and 2 (display screen).
and the one or more sensors, wherein the one or more sensors correspond to the one or more indicators and are controlled according to sensor exclave software running in a trusted execution environment, wherein the sensor exclave software is configured to: enable access to the one or more sensors for a defined period of time in response to receiving a message indicating that the one or more indicators are being displayed;
In some embodiments, sensor data may be pulled from or pushed to the environment via these connections. In some embodiments, the sensor data itself contains sensitive information such as a picture or image of an individual (Robinson et al. par. 13). In an embodiment, the trusted light may feature symbols conveying status. In an embodiment the trusted light may be a lighted or backlight personalized or company trademark symbol. In an embodiment, when the light is on, the protections are on; and when the light is off, protections are off. In an embodiment, the light may change color depending on the current policies, red to indicate an untrusted environment, green to mean trusted, orange to indicate an intermediate state. In an embodiment, the indicator may be something other than a light such as a textual based display or a haptic interface that allows touch or feel to indicate system status (Robinson et al par. 32). Similarly, referring to FIG. 3, another graphical user interface display may ask the user to enable a camera-based trusted gesture mode. Filter mode changes (i.e. policy changes) for the camera data may require user consent, in some embodiments. Here, the gesture recognition mode agent attests to the camera subsystem, including software stack, that it has the user's blessing to process raw data (Robinson et al. par. 36). In an embodiment, multiple agents may concurrently request data from a single sensor or multiple sensors. Trusted agents may run in separate trusted execution environments (Robinson et al. par. 37).
According to the cited passages and figures, examiner interprets the camera as the sensor, therefore the camera is enable upon received the gesture from the user and displaying image and trust indicator.
Robinson et al. do not explicitly teach disable access to the one or more sensors after the defined period of time if a subsequent message indicating that the one or more indicators are being displayed is not received.
Mosher et al. teach disable access to the one or more sensors after the defined period of time if a subsequent message indicating that the one or more indicators are being displayed is not received. (Mosher et al. US 20150358455 abstract; paragraphs [0007]-[0012]; [0033]-[0038]; [0040]-[0047]; figures 1-3)
FIG. 1 illustrates an overview of a telecommunication device determining that a threshold amount of time has passed since a heartbeat communication and, in response, preventing access to telecommunication device service(s) or deleting user data. As illustrated, a telecommunication device 102 may fail to receive a heartbeat communication 104 from a remote telecommunication server 106. The telecommunication device 102 may then determine 108 that it has not received a heartbeat communication 104 for a threshold amount of time. In response to the determining 108, the telecommunication device 102 may perform 110 at least one of preventing access to one or more telecommunication device services 112 or deleting user data 114 (Mosher et al. par. 12).
Therefore, it would have been obviously to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Robinson et al. reference by apply preventing access to one or more telecommunication device service in response to not received a heartbeat communication for a threshold amount of time as taught by Mosher et al. reference in order to improve security against theft.
Regarding claim 9, the combination of Robinson et al. and Mosher et al. disclose The electronic device of claim 8, wherein the message comprises a heartbeat message occurring at a regular cadence, and wherein the subsequent message comprises a subsequent heartbeat message occurring at the regular cadence.
In various embodiments, the remote telecommunication server 106 or another device of the telecommunication service provider may remotely configure the telecommunication device 102, setting or updating any sort of configurations, settings, parameters, etc. For example, the remote telecommunication server 106 may provide instructions setting a threshold amount of time (also referred to herein as a “time threshold”) that the secure component of the telecommunication device 102 is to wait following a most recent heartbeat communication 104 before performing 110 at least one of preventing access to service(s) 112 or deleting user data 114. The remote telecommunication server 106 may also provide instructions specifying which telecommunication device service(s) 112 should be blocked and what user data 112 should be deleted. Instructions provided by the remote telecommunication server 106 may, in a number of embodiments, be provided in a heartbeat communication 104, such as a heartbeat message or response. In some embodiments, the instructions may specify a plurality of time thresholds, with different telecommunication device service(s) 112 blocked and different user data 114 deleted at each threshold. Such multiple thresholds may enable the remote telecommunication server 106 to specify a more gradual approach to preventing use of the telecommunication device 102 (Mosher et al. par. 19). At 330, subsequent to preventing access to the one or more telecommunication device services or to the additional telecommunication device services, the secure component may receive instructions from the remote telecommunication server enabling access to the one or more telecommunication device services. Such instructions may be provided following reception of a subsequent heartbeat communication or instructions from the remote telecommunication server (Mosher et al. par. 47).
According to the cited passages and figures, examiner interprets the heartbeat message provide a specify time as the heartbeat messages occurring at the regular cadence.
Regarding claim 10, the combination of Robinson et al. and Mosher et al. disclose The electronic device of claim 9, wherein the heartbeat message and the subsequent heartbeat message are generated by monitoring software configured to run in the trusted execution environment controlling the image processing circuitry.
The disclosure describes herein a secure component of a telecommunication device. The secure component may be located entirely or in part in a boot loader of the telecommunication device, in a trusted execution environment (TEE) of the telecommunication device, or in an embedded subscriber identity module (eSIM) of the telecommunication device. The secure component may be configured to determine that a threshold amount of time has passed since a heartbeat communication from a remote telecommunication server and to, in response, perform at least one of preventing access to one or more telecommunication device services or deleting user data from the telecommunication device. The heartbeat communication may be a heartbeat message from the remote telecommunication server or a response from the remote telecommunication server to a heartbeat message from the telecommunication device (Mosher et al. par. 7). In various embodiments, the remote telecommunication server 106 or another device of the telecommunication service provider may remotely configure the telecommunication device 102, setting or updating any sort of configurations, settings, parameters, etc. For example, the remote telecommunication server 106 may provide instructions setting a threshold amount of time (also referred to herein as a “time threshold”) that the secure component of the telecommunication device 102 is to wait following a most recent heartbeat communication 104 before performing 110 at least one of preventing access to service(s) 112 or deleting user data 114. The remote telecommunication server 106 may also provide instructions specifying which telecommunication device service(s) 112 should be blocked and what user data 112 should be deleted. Instructions provided by the remote telecommunication server 106 may, in a number of embodiments, be provided in a heartbeat communication 104, such as a heartbeat message or response. In some embodiments, the instructions may specify a plurality of time thresholds, with different telecommunication device service(s) 112 blocked and different user data 114 deleted at each threshold. Such multiple thresholds may enable the remote telecommunication server 106 to specify a more gradual approach to preventing use of the telecommunication device 102 (Mosher et al. par. 19). At 330, subsequent to preventing access to the one or more telecommunication device services or to the additional telecommunication device services, the secure component may receive instructions from the remote telecommunication server enabling access to the one or more telecommunication device services. Such instructions may be provided following reception of a subsequent heartbeat communication or instructions from the remote telecommunication server (Mosher et al. par. 47).
According to the cited passages and figures, examiner interprets the heartbeat message provide a specify time as the heartbeat messages occurring at the regular cadence.
Regarding claim 13, the combination of Robinson et al. and Mosher et al. disclose The electronic device of claim 8, wherein the sensor exclave software is configured to run in the trusted execution environment.
Similarly, referring to FIG. 3, another graphical user interface display may ask the user to enable a camera-based trusted gesture mode. Filter mode changes (i.e. policy changes) for the camera data may require user consent, in some embodiments. Here, the gesture recognition mode agent attests to the camera subsystem, including software stack, that it has the user's blessing to process raw data (Robinson et al. par. 36). In an embodiment, multiple agents may concurrently request data from a single sensor or multiple sensors. Trusted agents may run in separate trusted execution environments (Robinson et al. par. 37).
Regarding claim 17, the combination of Robinson et al. and Mosher et al. disclose The method of claim 14, comprising, in response to not receiving the message, preventing access, via the sensor exclave software, to the sensor data.
FIG. 1 illustrates an overview of a telecommunication device determining that a threshold amount of time has passed since a heartbeat communication and, in response, preventing access to telecommunication device service(s) or deleting user data. As illustrated, a telecommunication device 102 may fail to receive a heartbeat communication 104 from a remote telecommunication server 106. The telecommunication device 102 may then determine 108 that it has not received a heartbeat communication 104 for a threshold amount of time. In response to the determining 108, the telecommunication device 102 may perform 110 at least one of preventing access to one or more telecommunication device services 112 or deleting user data 114 (Mosher et al. par. 12).
Regarding claim 18, the combination of Robinson et al. and Mosher et al. disclose The method of claim 14, wherein the message comprises a heartbeat message.
The disclosure describes herein a secure component of a telecommunication device. The secure component may be located entirely or in part in a boot loader of the telecommunication device, in a trusted execution environment (TEE) of the telecommunication device, or in an embedded subscriber identity module (eSIM) of the telecommunication device. The secure component may be configured to determine that a threshold amount of time has passed since a heartbeat communication from a remote telecommunication server and to, in response, perform at least one of preventing access to one or more telecommunication device services or deleting user data from the telecommunication device. The heartbeat communication may be a heartbeat message from the remote telecommunication server or a response from the remote telecommunication server to a heartbeat message from the telecommunication device (Mosher et al. par. 7).
Regarding claim 19, the combination of Robinson et al. and Mosher et al. disclose The method of claim 14, comprising discontinuing access, via the sensor exclave software, to the sensor data after a defined period of time if a subsequent message is not received.
FIG. 1 illustrates an overview of a telecommunication device determining that a threshold amount of time has passed since a heartbeat communication and, in response, preventing access to telecommunication device service(s) or deleting user data. As illustrated, a telecommunication device 102 may fail to receive a heartbeat communication 104 from a remote telecommunication server 106. The telecommunication device 102 may then determine 108 that it has not received a heartbeat communication 104 for a threshold amount of time. In response to the determining 108, the telecommunication device 102 may perform 110 at least one of preventing access to one or more telecommunication device services 112 or deleting user data 114 (Mosher et al. par. 12).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Robinson et al. US 20140157349 in view of Mosher et al. US 20150358455 and further in view of Prodan et al. US 20110302663.
Regarding claim 5, the combination of Robinson et al. and Mosher et al. teach all the limitation in the claim 4.
The combination of Robinson et al. and Mosher et al. do not explicitly teach The method of claim 4, wherein the untrusted software comprises a third-party application.
Prodan et al. teach The method of claim 4, wherein the untrusted software comprises a third-party application. (Prodan et al. US 20110302663 paragraph [0111]; figures 1-6)
The processor 410 may be operable to run or execute programs or applications received from unknown or untrusted third-party sources as a result of a request from, for example, the software agent 300 described above with respect to FIG. 3. The processor 410 and the memory 330 may be configured to operate as a contained processing environment 400 that is dedicated to handle content, including programs or applications, which is received from unknown or untrusted third-party sources and that may pose a threat to the data contained in the broadband gateway 102 and/or to the operation of the broadband gateway 102. In this regard, verification of the content received from unknown or untrusted third-party sources may not be required since the content and any application that is executed from such content is contained or isolated within the contained processing environment 400. Moreover, because of the contained nature of the processing environment, portions of the memory 340 may not need to be disabled when an application from an unknown or untrusted third-party source is executed on the processor 410 (Prodan et al. par. 111).
Therefore, it would have been obviously to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Robinson et al. and Mosher et al. reference by provide an untrusted third-party source as taught by Prodan et al. reference in order to present a threat to a data so user can be aware of the threat.
Claims 7, 12 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Robinson et al. US 20140157349 in view of Mosher et al. US 20150358455 and further in view of Chavanna, Jr. et al. US 20110214686.
Regarding claim 7, the combination of Robinson et al. and Mosher et al. teach all the limitation in the claim 1.
The combination of Robinson et al. and Mosher et al. do not explicitly teach The method of claim 1, wherein the defined period of time is less than 5 seconds and greater than 1 millisecond.
Chavanna, Jr. et al. teach The method of claim 1, wherein the defined period of time is less than 5 seconds and greater than 1 millisecond. (Chavanna, Jr. et al. US 20110214686 paragraph [0032];)
In another embodiment, the predetermined time period is less than or equal to about one second, less than or equal to about five seconds, or less than or equal to about ten seconds. In a preferred embodiment, the predetermined time period is greater than zero, for example, about 10 milliseconds (ms), about 100 ms, about 200 ms (Chavanna, Jr. et al. par. 32).
According to cited passage, examiner interprets the predetermined time period is greater than zero and less than 5 seconds.
Therefore, it would have been obviously to one of ordinary skill in the art before the effective filing date of the claim invention by substitute a predetermine time period as taught by Chavanna, Jr. et al. reference into the defined period of time of Robinson et al. and Mosher et al. reference and the result of substitution would be predictable.
Regarding claim 12, the combination of Robinson et al., Mosher et al. and Chavanna, Jr. et al. disclose The electronic device of claim 8, wherein the defined period of time is less than 5 seconds and greater than 1 millisecond. (Chavanna, Jr. et al. US 20110214686 paragraph [0032];)
In another embodiment, the predetermined time period is less than or equal to about one second, less than or equal to about five seconds, or less than or equal to about ten seconds. In a preferred embodiment, the predetermined time period is greater than zero, for example, about 10 milliseconds (ms), about 100 ms, about 200 ms (Chavanna, Jr. et al. par. 32).
According to cited passage, examiner interprets the predetermined time period is greater than zero and less than 5 seconds.
Regarding claim 20, the combination of Robinson et al., Mosher et al. and Chavanna, Jr. et al. disclose The method of claim 19, wherein the defined period of time is less than 5 seconds and greater than 1 millisecond.
In another embodiment, the predetermined time period is less than or equal to about one second, less than or equal to about five seconds, or less than or equal to about ten seconds. In a preferred embodiment, the predetermined time period is greater than zero, for example, about 10 milliseconds (ms), about 100 ms, about 200 ms (Chavanna, Jr. et al. par. 32).
According to cited passage, examiner interprets the predetermined time period is greater than zero and less than 5 seconds.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THANG D TRAN whose telephone number is (408)918-7546. The examiner can normally be reached Monday - Friday 8:00 am - 5:30 pm (pacific time).
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, Brian A Zimmerman can be reached at 571-272-3059. 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.
/THANG D TRAN/Examiner, Art Unit 2686
/BRIAN A ZIMMERMAN/Supervisory Patent Examiner, Art Unit 2686
Prosecution Insights