Source: https://patents.google.com/patent/US9507965B2/en
Timestamp: 2019-04-20 01:34:26+00:00

Document:
2012-04-03 Assigned to INTEL CORPORATION reassignment INTEL CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BERGER, MICHAEL, RESCH, Joshua M.
A system comprising a platform protected by an always-on always-available security system is described. The system, in one embodiment, includes a core logic component to provide logic to move the platform to an armed mode upon receipt of an arming command, a battery access controller to prevent access to a battery of the platform, when the platform is in the armed mode, a disarming logic to receive a disarming command from a user, the disarming command causing the battery access controller to provide the access to the battery, such that when the platform is disarmed the battery can be accessed, whereby the system prevents removal of the battery when the platform is in the armed mode to ensure that the platform remains powered to perform a security action when needed.
This patent application is a U.S. National Phase Application under 35 U.S.C. §371 of International Application No. PCT/US2011/067056, filed Dec. 22, 2011, entitled ALWAYS-AVAILABLE EMBEDDED THEFT REACTION SUBSYSTEM.
Full disk encryption (FDE) technologies are designed to protect the data in case the platform is stolen. Such technologies can be either software-based or hardware-based. These technologies rely on the end-user providing a password on boots from certain states in order to unlock the access to data stored on device. However, FDE protects a computer's data-at-rest only when it is not decrypted yet, e.g. when it is being booted.
Another theft protections system is a software-based alerting mechanism. Software-based alerting mechanisms provide an immediate alert capability in order to protect against theft. The problem is that these mechanisms are susceptible to software-based attacks by thieves (e.g., turning off the WIFI radio), simple hardware-based attacks by thieves (e.g., pressing the platform's power button for 4 seconds).
Another theft protection system relies on discrete hardware components containing trigger-based alerting mechanisms. An example for this is a disk-on-key like component that gets plugged into the PC. However, this requires an additional plug-in device, and only works when the computer system is already active. In addition, a thief can easily destroy such components while keeping the platform intact, e.g. drown it in a glass of water, or bring down a hammer on it.
FIG. 1 is a diagram of one embodiment of a platform in an environment.
FIG. 2A is a block diagram of one embodiment of a platform implementing the security features of the invention.
FIG. 2B is a block diagram of one embodiment of additional systems that may be associated with the platform.
FIG. 3 is a diagram showing one embodiment of separately powered subsystems within the platform.
FIG. 4 is a diagram of one embodiment of the platform.
FIG. 5 is a diagram of another embodiment of the platform.
FIG. 6A is a diagram of one embodiment of the battery-removal protection system.
FIG. 6B is a diagram of another embodiment of the battery-removal protection system.
FIG. 7 is a state diagram of one embodiment of the states of the platform.
FIG. 8 is a second state diagram, shown another embodiment of the states.
FIG. 9 is one embodiment of a table of actions at each of the states shown.
FIG. 10 is a power state diagram, showing one embodiment of the power states of the system.
FIG. 11A is an overview flowchart of one embodiment of using the protection system in the always on, always available environment.
FIG. 11B is a table of one embodiment of the various situations that may be encountered by the system, and the reaction at the platform, server, and user-carried device.
FIG. 12 is a flowchart of one embodiment of arming the system.
FIG. 13 lists exemplary manual or automatic arming mechanisms.
FIG. 14 is a flowchart of one embodiment of disarming the protection system.
FIG. 15 lists exemplary manual or automatic disarming mechanisms.
FIG. 16 is a flowchart of one embodiment of using a user-carried device, for automatic network-based arming and disarming.
FIG. 17 is a flowchart of one embodiment of using two-way Bluetooth enabled devices for arming/disarming and notification services.
FIG. 18 is a flowchart of one embodiment of proximity-based arming and disarming, when proximity is further coupled with motion data.
FIG. 19 is a flowchart of one embodiment of using Near Field Communications for arming and disarming the system.
FIG. 20 is a flowchart of one embodiment of power operations used to protect the system's data-at-rest.
FIG. 21 is a flowchart of one embodiment of transparent boot/resume to the user, which is secure in face of a thief or unauthorized user.
FIG. 22 is a diagram of one embodiment of a multi-kill pill system.
FIG. 23 is a flowchart of one embodiment of power management of the anti-theft mechanism's components.
FIG. 24 shows an exemplary list of arming modes and associated types of input that would be recognized.
FIG. 25 is a flowchart of one embodiment of a protective override mechanism.
FIG. 26 compares the anti-theft mechanism's override mechanism with other possible override mechanisms.
FIGS. 27A and 27B are a flowchart of one embodiment of corporate provisioning of a platform and its co-existence with user configuration.
FIG. 28 is a flowchart of one embodiment of platform security in a monitored environment.
FIG. 29 is a block diagram of one embodiment of a computer system that may be used as the platform, and/or the paired device.
FIG. 30 is a block diagram of an exemplary system in accordance with an embodiment of the present invention.
FIG. 1 is a diagram of one embodiment of a platform in an environment. The platform 110 in one embodiment may be a laptop computer. The platform 110 may be another type of computing device, such as a netbook, a tablet computer, a mobile device, or another type of computing device. The platform 110 in one embodiment includes network connection, enabling the platform to connect to a network 130.
In one embodiment, platform 110 may be in communication with a security server 140, or another of device via network 130. Network 130 in one embodiment is accessed through a network interface, such as a WiFi network, a wired network, or another type of network.
In one embodiment, the platform 110 is directly coupled to a personal area network (PAN) device 170. The personal area network may be a Bluetooth network. Thus, Bluetooth device 160 can be connected to the platform 110.
In one embodiment, the platform 110 is paired with a near field communications (NFC) device 180. The NFC device may be a badge, an RFID, a chip or sticker in a mobile telephone, or other system carried by the authorized user which includes an NFC chip. Similarly, a wireless/WiFi device may be coupled to platform 110 either directly or through network 130.
In one embodiment, the platform 110 may be able to receive location data through GPS 120A, 120B, as is known in the art. In one embodiment, the platform 110 may obtain its data from a network connection, using wireless hub data, from cellular network triangulation, from accelerometer data (not shown), or from a combination of these and/or other location-data indicators.
This would prompt a rational thief to take out all visible electrical sources—AC and main battery—thus suppressing the alert. The action of taking out the electrical sources will place the platform in G3 state (Mechanical Off). Since the HDD/SSD loses power, its data is now protected. On next booting up of the platform, the full disk encryption will be active, and the data will only be accessible by successfully entering the password at a password prompt. Note that in the case of false positive, when the platform suspects there is a thief but it is actually the authorized user, no power transition occurs, and hence there is no issue of disrupting processes or losing data. This solution can be especially relevant to market segments in which the cost of a breach of on-platform data can reach many times that of the cost of platform asset replacement.
FIG. 2A is a block diagram of one embodiment of a platform implementing the security features of the invention, while FIG. 2B are block diagrams of one embodiment of related devices. The security system 210 in one embodiment includes a mode logic 212. State logic 212 manages the modes of the mechanism. In one embodiment, the modes of the mechanism include unarmed (no protection), armed (protected), arming-in-progress (transition phase between unarmed and armed), and suspecting (armed, and suspecting theft). In one embodiment, mode indicator UI feature 215 indicates visually the current mode of the platform. In one embodiment, the mode indicator UI feature 215 is an LED, which indicates mode by a flashing pattern. In one embodiment, the mode indicator UI feature 215 is a multi-color LED, which indicates mode by a color. Alternative methods of visually indicating the current mode may be used.
In one embodiment, security system 210 includes power management logic 216. The power management logic 216 controls power to the various elements which maybe associated with security system 210. In one embodiment, in order to reduce power consumption in lower power states (e.g. sleep and hibernation) the system may selectively power a subset of the elements of the security system 210. This will be described in more detail below. In one embodiment, power transition logic 246 controls the platform through a plurality of power states. The power states, in one embodiment include S0 (ON) through S5 (OFF). Power transition logic 246 moves the system between the power states, waking up, as well as one or more sleep states, hibernation, and off.
Security action logic 250 takes a security action, when the core logic component 218 determines, based on information from risk behavior logic 232, that the device is in a risk situation. In one embodiment, security action logic 250 may take advantage of communication logic 252 to send a message to a user carried device 270, a security server 280, or another device. In one embodiment, the network communication to the user carried device 270 or the security server 280 takes the form of reporting presence or proximity. In one embodiment, a lack of that reporting constitutes a suspicion of theft. Security action logic 250 may also include audio output 254 to sound an audio alarm. In one embodiment, security action logic 250 may also include a kill pill 256. A kill pill 256 renders the platform inoperable. In one embodiment, it also destroys data on the platform. In one embodiment, kill pill 256 is a self-kill pill automatically implemented within the platform. Kill pill 256 in one embodiment is authorized by the user, as will be described below. The kill pill 256 in one embodiment is authorized by a service. In one embodiment, storage/encryption 242 deletes the data when the kill pill 256 is invoked. In one embodiment, security action logic 250 may trigger power transition logic 246 to transition the system to a different power state.
Configuration logic 238 configures the settings of the security system 210. In one embodiment, configuration logic 238 has a user-modifiable and an administrator—modifiable portion.
Network connection 236 is used to send data to security server 280 and/or user-carried device 270.
FIG. 2B is a block diagram of one embodiment of additional systems that may be associated with the platform. In one embodiment, user-carried device 270 is paired with the security system 210. Pairing logic 272 handles the pairing for the user-carried device 270. Alerting logic 274 enables the platform to send alerts to the user via SMS, MMS, Bluetooth, personal area network (PAN), or another alerting mechanism. In one embodiment, Alerting logic 274 will provide an alert to the end-user based on lack of communication from the platform. Proximity logic 276 monitors proximity of the platform, in a two-way-monitoring situation, in one embodiment.
Security server 280 is a server to which the security system 210 may send data. Security server 280 includes, in one embodiment, a monitor 282 to receive data from the platform. In one embodiment, monitor 282 receives alerts from the platform. Server 280 includes a ping receiver/timer 286, which monitors subsequent messages from the platform, once the initial message indicating that the platform is suspecting theft is received. This ensures that a response is carried out, if a thief successfully disables the platform and keeps it form sending out subsequent messages. In one embodiment, the Security server 280 contains or has access to a Wireless AP database 292 which can help translate raw information received regarding Wireless Access Points (e.g., BSSIDs and RSSI) to location information. In one embodiment, the Security server 280 contains or has access to a platform ID database 294 which maps the platform ID of the platform reporting its mechanism mode to user-specific information. The platform ID database can be used to take user-specific policy decisions or to alert specific users. In one embodiment, the Security server 280 contains an Alerting log 296 which can help IT determine whether the data on a platform that was stolen is protected, based on previous communications with the platform. This information may be used to trigger a remote kill pill.
FIG. 3 is a diagram showing one embodiment of separately powered subsystems within the platform. In one embodiment, the security system is implemented in an OEM (original equipment manufacturer) board 310. The OEM board 310, in one embodiment, is built into a platform. In one embodiment, the OEM board 310 is part of a circuit board, not otherwise shown. By having the security system implemented in the OEM board 310, the system ensures that standard hardware and software attacks cannot work, by building defenses into the original hardware.
In one embodiment, the OEM board 310 provides a secure path from the core subsystem 330 to each peripheral used for disarming or security actions, such as WiFi/Bluetooth 340, accelerometer 380, NFC 390, and others. The path from the core logic 330 to the peripherals 340, 380, 390, in one embodiment, uses dedicated busses. This means it is not possible for another entity to spoof traffic, monitor secrets, or cause a denial of service. In one embodiment, the controllers are themselves secure, such that no one can hack into them. This ensures that no one can perform a firmware update on these controllers to an unauthorized or blacklisted image, no one can hang these controllers, etc.
In one embodiment, the connection type between each peripheral and the core system may depend on the type of processing and data exchange between that peripheral and the core subsystem. For example, in one embodiment, the NFC reader 390 reads the tag, and the core subsystem 330 performs the comparison to ensure the NFC device is authorized. In such a case, the connection between the core system 330 and NFC reader 390 should be authenticated and encrypted, when not dedicated. On the other hand, if the NFC reader 390 did the processing on its side and only sent the core subsystem 330 an OK/Not OK message, the connection should be authenticated, but need not be encrypted since no secret data is passed. The accelerometer 380, for example, is at risk for a denial of service attack. If a thief manages to cause denial of service (or to spoof message), then the system cannot successfully detect that the platform has been moved by the thief. Therefore, the connection between the core system 330 and the accelerometer 380 should be dedicated.
FIG. 5 is a diagram of another embodiment of the platform. The embodiment uses an efficient power design. The OEM embedded controller 550 controls the power rails to the FETs 585, 595, 545.
In one embodiment, the arm/disarm mechanism 520 is a mechanical switch, and thus does not need to reside on a power rail controlled by the OEM embedded controller 550.
FIG. 6A is a diagram of one embodiment of the battery-removal protection system. By preventing the battery removal, the system eliminates the opportunity for the thief to remove all major power sources to the platform, so that the platform can complete its protective activities.
The anti-theft core logic subsystem 610, in one embodiment, passes its data to a mode decoding logic 620. The battery 640 is protected by solenoid 630. When the device mode is in the Armed or Suspecting modes, the solenoid 630 keeps the battery compartment closed, forcing the battery 640 to remain attached. Even when external power is removed, the solenoid 630 remains closed. In this way, when a thief attempts to remove the battery 640, it is locked and cannot be removed. However, the authorized user or administrator, who can disarm the platform, can remove the battery 640 without difficulty.
In one embodiment, in order to reduce solenoid power consumption to a minimum, a battery mechanical latch 645 can exist as well, such that the battery 640 cannot be removed if either the mechanical latch 645 is closed or the solenoids 630 are activated, and the solenoids 630 do not get activated as long as the mechanical latch is closed.
FIG. 6B is a diagram of another embodiment of the battery-removal protection system. The core subsystem 650 provides mode messages to the OEM controller 670. The OEM controller 670 provides signals to the solenoid 680 to lock in the compartment to protect battery 690, when the device is in the armed or suspecting mode. In one embodiment, in order to reduce solenoid power consumption to a minimum, a battery mechanical latch 695 can exist as well, such that the battery 690 cannot be removed if either the mechanical latch 695 is closed or the solenoids 680 are activated, and the solenoids 680 do not get activated as long as the mechanical latch 695 is closed.
FIG. 7 is a mode diagram of one embodiment of the modes of the platform. The modes, in one embodiment, including Unarmed 710, Arming in Progress 730, Armed 750, and Suspecting 770 modes.
The Arming-in-progress 730 mode is an intermediate stage, while the system completes the arming. In one embodiment, the platform remains in the Arming in Progress mode 730 until the arming is complete. Generally, arming cannot complete due to an inability to complete one or more steps that the protection policy dictates—for example, inability to connect to the alerting server when the protection policy requests an alert to the server. In either case, the system may alert the authorized user/administrator that arming could not be completed. In one embodiment, the user may disarm the platform while it is in the Arming in Progress mode 730 without authentication, to return to the Unarmed mode 710. Once the arming is complete, the platform is in the Armed mode 750.
FIG. 8 is a second mode diagram, shown another embodiment of the modes. As can be seen, the same four modes are present. However, in this example, the proximity information from a linked Personal Area Network (PAN) device is used to activate the system. In one embodiment, the PAN device is a mobile phone including Bluetooth pairing ability.
As shown, when platform is stationary and the authorized user is near the platform, it does not suspect theft, and remains in the Unarmed mode 810. In one embodiment, the user initiates the “Arming in Progress” mode, which starts monitoring the proximity of the authorized user to the platform.
In one embodiment, when platform is mobile (in-transit) with proximity to the paired device (e.g. with the authorized user) it does not suspect theft, regardless of whether the end-user is moving it or not. In one embodiment, the mode then remains in the Arming in Progress mode 830.
As noted above with respect to FIG. 7, the system may provide override, as well as disarming capabilities and trigger releases.
In one embodiment, the system is in the Armed mode 830, rather than the Arming-in-Progress mode 850, when the paired Bluetooth device is in proximity. The trigger to move from Armed mode 850 to Suspecting mode 870 is movement of the platform away from the stationary paired device (via detection of proximity loss), or movement of the paired device from the stationary platform.
FIG. 9 is one embodiment of a table of actions at each of the modes shown. In one embodiment, there is an LED (light emitting diode) or similar visual mode indicator. In one embodiment, the LED shows the modes (e.g. unarmed, arming, armed, suspecting). The LED may have different colors, or blinking/shining patterns or intensities for the various modes.
The system sends various packets, as it enters the various modes. As it enters the Unarmed mode, in one embodiment, it sends a disarm packet, to a server which may have been alerted that the platform was armed. When the system is in the arming-in-progress mode, an initial connection is sent to the server, in one embodiment. In the armed mode, in one embodiment, the armed pings are sent to the server. If the system enters the Suspecting mode, the information regarding the suspicion is sent. In one embodiment, the information may include the platform's status and environment indicators, such as RSSI of wireless access points in the vicinity, accelerometer data, Bluetooth proximity data, data protection policy, etc.
FIG. 10 is a power state diagram, showing one embodiment of the power states of the system. The platform has three states, active with the data unprotected (state 1, 1010), the platform on standby or connected standby, with the data unprotected (state 2, 1030), and the data protected (state 3, 1050) with the platform neither in standby, connected standby, or active. Connected Standby refers to a state in which the platform maintains network connectivity and/or updates its data without the user perceiving the platform to be ON.
Although not shown, the system can move from the standby state to hibernation or off, when further idle time is observed. In one embodiment, when the platform moves to the hibernation state, it automatically protects the platform data. In one embodiment, this is simply the default requirement of a password to allow OS boot. In one embodiment, this includes encrypting the data on the platform, prior to entering hibernation. In one embodiment, this includes a self-encrypting drive, which requires decryption on any power-on of the drive, which is an event that occurs when leaving hibernation or OFF states. These may be an aspect of full disk encryption, which may be implemented with the security system.
FIG. 11A is an overview flowchart of one embodiment of using the protection system in the always on, always available environment. The process starts at block 1110. In one embodiment, this process is active whenever the system is armed. How the system is armed and disarmed is discussed in more detail below.
The process then continues to block 1160, to determine whether the platform has been disarmed. The authorized user may disarm the platform at any time. For example, it may happen that the authorized user accidentally triggered the platform's suspicion of a software-based attempt. The user may disarm the platform to end the addressing of the attack. This may be done by demonstrating that the authorized user has control of the platform in various ways. If the platform is disarmed, at block 1170 the process determines whether an action addressing an attack is in progress. If so, the actions are terminated, and the user/server are notified if needed, at block 1175. The process then ends at block 1180, since the platform is disarmed. The process restarts when the user next arms the platform. If the platform has not been disarmed, as determined at block 1160, the process continues to block 1130 to continue monitoring for attacks.
If there is no software-based attack, as determined at block 1130, the process at block 1140 determines whether there is a hardware-based attack. A hardware-based attack may be an attempt to remove the battery, an attempt to turn off the WiFi, undocking the device, etc. If a hardware-based attack is detected, the process continues to block 1145.
At block 1145, the hardware-based attack is addressed. In general, hardware-based attacks cannot be physically prevented (e.g. the platform cannot resist the AC cord being pulled). However, a notification will be sent, whenever possible prior completion of the hardware-based attack.
In one embodiment, certain hardware attacks may be prevented by the system. For example, in one embodiment, as described above, a battery mechanical latch or solenoid-based protection system prevents removal of the battery. In one embodiment, the hardware kill switch for the WiFi is overridden by the embedded controller, thus enabling the platform to send out a notification message. The process then continues to block 1160 to determine whether the platform has been disarmed.
If no hardware-based attack is detected, at block 1150 the process determines whether there is a theft attempt. A theft attempt may be detected when the platform moves, while it is armed. If there is a theft attempt, at block 1155 the theft attempt is addressed. The theft attempt is addressed, in one embodiment, by sending notification to the user and/or security server. In one embodiment, the notification may include current location and/or movement data. In one embodiment, the system sets up a ping, to send location/motion information to the user/server periodically. In one embodiment, the system protects its data by moving into a Hibernate power state. The process then continues to block 1160, to determine whether the platform is disarmed.
In this way, the system, when armed, addresses multiple forms of potential attacks. Note that these defenses are available regardless of the power state of the platform, as long as a large enough power source is provided. Note that although FIG. 11A, and other figures, are shown as flowcharts, the organization of the flowchart is simply to group together related actions. The ordering of the actions need not be in the order shown. Furthermore, the process may separately monitor each of the settings discussed in the flowchart. For example, in the above flowchart, there may be multiple sensors monitoring for attacks. If any sensor indicates an attack, the processes associated with that attack is performed. Similarly, for the below flowcharts, it should not be read to require each step, nor the performance of the steps in the order presented.
FIG. 11B is a table of one embodiment of the various situations that may be encountered by the system, and the reaction at the platform, server, and user-carried device. As can be seen, if the user is with the platform, the platform is generally unarmed, or in the arming-in-progress mode. No server action or user-carried device action is taken, if the user is present, and the device is not armed.
FIG. 12 is a flowchart of one embodiment of arming the system. The process starts at block 1210. In one embodiment, the system always monitors for arming indications, when it is powered. In one embodiment, the process therefore starts whenever the system is powered, and not yet armed.
At block 1220, the process determines whether the automatic arming policy has been met. Automatic arming sets certain policies that cause the device to be armed. FIG. 13 shows some of the possible automatic arming policies. They may include loss of Bluetooth proximity, loss of user via camera, closing of the lid, device movement, device idleness, location, time of day, or other preset automatic triggers to arming. In one embodiment, the system may have no automatic arming policies in place. In that instance, the automatic arming policy cannot be met.
Returning to FIG. 12, if the system determines that the automatic arming policy has been met, at block 1225, the platform is armed. The process then continues to block 1270. At block 1270, the process confirms whether the platform is armed. If so, the monitoring for arming is ended, at block 1280. In one embodiment, this includes turning off sensors or other devices that are powered in order to enable detection of an arming action. Once the platform is armed, only those elements that are needed for disarming and detecting suspicion triggers remain powered.
If the automatic arming rule was missing, or was not met, the process continues to block 1230. At block 1230, the process determines whether a semi-automatic arming has been initiated. Semi-automatic arming uses a first manual initiation, and then an automatic arming rule. For example, semi-automatic arming may occur if the user initiates pairing with a Bluetooth device, sets a switch, or otherwise initializes the arming system. Once the initialization takes place, the platform is automatically armed when a certain condition occurs. These conditions may be the ones listed in FIG. 13. The initial manual switch may be one of those listed under manual arming in FIG. 13, or another. If semi-automatic arming is initiated at block 1230, the process continues to block 1235.
If the semi-automatic arming is not initiated, or not enabled in the system, the process continues to block 1250. At block 1250, the process determines whether a manual arming command is received. The manual arming command may be one of the forms listed in FIG. 13, or another action by the user to initiate arming. If the manual arming action was received, at block 1265 the platform is armed. The process then continues to block 1270, to determine whether the platform is armed, and exit the arming loop, if it is. If no manual arming action is received, at block 1270 the process determines whether the platform is armed. If the platform is armed, the process ends at block 1280. If the platform is not armed, the process returns to block 1220, to continue monitoring for an arming.
FIG. 14 is a flowchart of one embodiment of disarming the protection system. The process starts at block 1410. In one embodiment, this process is active whenever the platform is armed. In one embodiment, this is active in multiple power states, e.g. when the platform is in the ON or Sleep states. In one embodiment, this includes powering one or more sensors, detectors, or devices that may receive a disarming command.
At block 1420, the process determines whether an automatic disarming signal has been received. Some examples of automatic disarming signals are listed in FIG. 15. In one embodiment, the user may disable the automatic disarming. If the automatic disarming is disabled, there would be no conditions that would automatically disarm the platform. In one embodiment, the system powers those elements that are associated with an automatic disarming command. For example, if there is a paired Bluetooth device, and the Bluetooth automatic disarming is enabled, the system would power the Bluetooth pairing when the platform was armed, even in a reduced power state.
The process then continues to block 1440, where the process verifies that the platform is disarmed. If so, the process ends at block 1450. At this point, the system switches over to enable the sensors associated with arming the platform, as discussed above with respect to FIG. 12.
If no automatic disarming was received, at block 1430 the process determines whether a manual disarming command was received. Some examples of manual disarming indicators are shown in FIG. 15. In general, disarming requires the demonstration that the authorized user has control of the platform. Therefore, tapping by a Near Field Communication device (e.g., user's badge or phone), or biometrics such as the user's image, fingerprint, voice, etc. may be used, as well as passwords/movements, which would only be known by the authorized user.
FIG. 16 is a flowchart of one embodiment of pairing a device, for network-based arming and disarming. The process starts at block 1610. At block 1615, a user acquires a platform including a Bluetooth or other local area network connection ability. In one embodiment, the network connection format is a Bluetooth Pairing.
At block 1625, the automatic or semi-automatic arming/disarming is set up with the paired user device. In one embodiment, the user may set the specifics of the pairing during this set-up. The specifics may include timing, and other limitations. For example, in an extremely secure environment the user may set that the platform should be armed immediately when connection with the paired device is lost. In a less secure environment, the user may prefer to set a short period prior to arming the platform, to remove the potential time delays of having the platform arm and disarm, for momentary loss of connectivity.
FIG. 17 is a flowchart of one embodiment of using two-way Bluetooth enabled devices for arming/disarming and notification services. In addition to the one-way notification described above with respect to FIG. 16, two-way communication may also be set up. The process starts at block 1710. This process starts when there is an active two-way Bluetooth system set up, with a paired device.
If it is not yet time to send a ping to the platform, the process, at block 1760, determines whether the platform should have received a ping from the device. If it is not yet time, the process loops back to continue testing whether it is time to send, or receive a ping, at block 1730.
If it is time to have received a ping, at block 1770 the process determines whether a ping indicating continued proximity has been received from the device. If a proximity signal been received, the process continues to block 1750, to reset the receiving timer.
FIG. 18 is a flowchart of one embodiment of proximity-based arming and disarming, when proximity is further coupled with motion data. In one embodiment, the system reacts differently when the platform is moving, and when the platform is not moving. The process starts at block 1810.
If the user is not moving out of range, as determined at block 1845, the process at block 1850 determines whether the user has disarmed the platform. If the user has not disarmed the platform, the process continues to block 1825 to continue monitoring the platform's movement and whether the user device is in range. If the user has disarmed the platform, the process returns to block 1815, leaving the anti-theft technology unarmed.
FIG. 19 is a flowchart of one embodiment of using Near Field Communications for arming and disarming the system. The process starts at block 1910. In one embodiment, the process starts with a platform including a Near Field Communications reader.
At block 1915, the system is initially set up to establish an NFC chip-containing device for arming/disarming. In one embodiment, the NFC chip may be in the user's badge, in the user's mobile telephone, a tag that may be attached to a keychain, on a sticker that may be attached to something the user habitually carries such as a badge or telephone.
At block 1920, the process determines whether the platform is armed. If the platform is not armed, at block 1925, the process determines whether NFC arming is activated. In one embodiment, when the arming process is semi-automatic, the user needs to initialize the NFC-based arming process. If the NFC arming is not activated, the platform remains unarmed, at block 1930. The process then returns to block 1920, to continue looping through this process.
If the NFC arming is activated, the process continues to block 1935. At block 1935, the process determines whether the activating tap with the NFC-enabled device has been received, and authenticated. In one embodiment, the system uses a pattern of taps (e.g. tap-tap-tap in a particular cadence). In another embodiment, a plurality of timed proximities (e.g. tapping or waving the NFC chip-enabled object, may be the activating tap. In another embodiment, holding the NFC-chip-enabled object in proximity is sufficient. Authentication includes checking credentials passed by the NFC device. The credentials must be those registered during the initial set-up, to enable the use of the NFC device for arming and disarming. If the activating tap was not received or not successfully authenticated, the process continues to block 1930, and the platform remains unprotected.
If, at block 1920, the process found that the platform was armed, it continues to block 1945. At block 1945, the process determines whether a disarming tap was received and authenticated. If a disarming tap was received and authenticated, at block 1955 the platform is disarmed. If no disarming tap was received, or the authentication failed, the platform remains armed, at block 1950. The process then returns to block 1920. For disarming, there may be a preset pattern of taps. In one embodiment, the NFC reader “identifies” the taps as a plurality of proximity detections within a preset period. For example, the pattern may be proximity—no proximity—proximity within a one second period. In this way, merely taking the NFC-chip enabled device is insufficient.
Note that although this process describes only NFC-based arming and disarming, one of skill in the art understands that the methods of manual, and various automatic and semi-automatic methods of arming may co-exist.
FIG. 20 is a flowchart of one embodiment of power management including triggers data protection of the system. The example here describes four power states: ON, standby/connected standby, hibernate, and OFF. One of skill in the art would understand that these are merely four exemplary power consumption levels, regardless of their naming scheme. ON is fully powered (though not all aspects of a platform need to be powered for it to be ON), standby or connected standby is a lower power state, and hibernate a lower power state yet, but above OFF. In one embodiment, although four separate states are described, fewer states may be implemented on a platform. The process starts at block 2010.
At block 2020, the process determines whether the user has armed the system. In one embodiment, the user may manually arm the system. If the user has not armed the system, the process at block 2025 determines whether the criteria for automatic arming are met. If the criteria are not met, the process ends at 2030.
If the automatic arming criteria are met, the process continues to block 2035. If at block 2020 the user armed the system, the process continues to block 2035 as well.
FIG. 21 is a flowchart of one embodiment of transparent boot/resume. In general, computer systems do not require the entry of a password, when a mobile system is resumed from a Standby or Connected Standby state. This process, in one embodiment, allows the system to force a non-authorized user to enter a password on resume, even if the user himself is never prompted for that password (assuming the user is away when the non-authorized user attempts access). This process, in one embodiment, also allows the system to boot from a state normally requiring manual entry of a password, without prompting the authorized user for the password. The process starts at block 2110. In one embodiment, this process starts when a user turns on a computer, or initiates the booting process. For simplicity, the term “booting” here refers to moving from a reduced power state to an ON state, regardless of whether BIOS boot is required.
If the user's presence is not verified, the process continues to block 2140. At block 2140, the process finishes booting to the password screen. In one embodiment, the password requirement may be modified to enable the use of an NFC, biometric, or other authentication mechanism.
At block 2150, after the identification/password is received the system verifies whether it is accurate. If so, the process continues to block 2180 to provide a usable screen, since an authorized user's presence has been validated.
FIG. 22 is a diagram of one embodiment of a multi-kill pill system. The diagram shows three possible kill-pill implementations. A kill-pill is a method of making a computer-system platform unusable, or its data inaccessible or erased. It is designed to be applied when the platform is stolen or lost, and the value of the data on the platform is higher than the value of the platform itself.
The first example has a client platform 2210, and a self-kill pill 2215. The self-kill pill is invoked when there is a suspicion of theft, and no user action has occurred in time. In general, the time before invoking the self-kill pill may be a few hours to a few days. This means that the thief may have a chance to use or sell the platform prior to the kill pill being invoked.
In one embodiment, when the client platform 2250 identifies a theft suspicion, an alert is sent out to the owner 2260, and the service 2265. If the owner 2260 responds, indicating there is no theft, the process ends. But if the alert is unsuccessful (not properly received by the owner, or no response received), the system initiates the self-kill pill. Alternatively, the service 2265 may send the kill pill notice, in response to user 2260 authorization.
FIG. 23 is a flowchart of one embodiment of power management of the anti-theft mechanism's components. The process starts at block 2310. At block 2320, the system enters a reduced power consumption status. In one embodiment, this occurs whenever the platform is disconnected from AC power. In one embodiment, this occurs when the platform is in a reduced power state, e.g. standby, connected standby, hibernate, or OFF mode. In one embodiment, all platform states may be considered as applicable for reduced power consumption mode (e.g., even ON and connected to AC power).
At block 2350, the process determines whether any interfaces are relevant to the current mode. The current mode shows which, if any, actions may be received via an interface. FIG. 24 shows an exemplary list of modes and associated types of input that would be recognized. One or more interface types may be associated with each of these types of input.
The process then continues to block 2380.
At block 2380, the process determines whether the lowered consumption requirement has ended. In one embodiment, the lowered consumption requirement may end when the system is placed in the ON state and/or when the platform is plugged into an AC outlet or docked, thus removing the need to conserve power. In one embodiment, the lowered consumption requirement may be considered applicable for all platform power states. If the lowered power consumption need is ended, the process ends at block 2385. The process would restart again, at block 2310, when the system once again would need to reduce its power consumption.
FIG. 25 is a flowchart of one embodiment of a protective override mechanism. An override may be invoked to the anti-theft mechanism due to various reasons. Reasons may include: The end-user left his disarming device (e.g., phone or badge) elsewhere, the disarming device malfunctioned or lost power, the platform is being returned from the end-user to IT and repurposed to another end-user, the platform is being recalled from the end-user to the OEM, and other reasons. The process starts at block 2510.
If the disarming request is not successful, the process continues to block 2570. In one embodiment, this occurs only after a set number of failed attempts.
At block 2570, the process determines whether override has been requested. If no override is requested, the process returns to block 2520, and the platform remains in the armed mode.
After all soft responses have been performed, in the suspecting mode, the process continues to block 2550, and transitions to the unarmed mode. In one embodiment, in the unarmed mode the platform is usable. However, the system does not decrypt the data on the platform. Thus, while the platform is not “unusable” the data remains protected. The process then ends.
FIG. 26 compares between various options of override scenarios. The option described above is the last one, in which the thief cannot steal data and asset, but the owner will not end up with an unusable system when an override is requested. In this way, the data remains protected and a theft suspicion alert is sent in order to protect against possible theft in case the thief attempted to invoke the override. However, the platform remains accessible, in case it was the end-user who invoked the override.
FIGS. 27A and 27B are a flowchart of one embodiment of corporate provisioning of a platform. The process starts at block 2710. At block 2715, a configuration alteration request is received. The configuration alteration may change alerting mechanisms, pair a device with the platform, remove a device from pairing, change timing of alerts, add or remove a kill pill, or perform other alterations to the system.
At block 2720, the process determines whether the request is a direct user request. If so, at block 2725, the process determines whether the user has been identified as being away from the platform. As noted above, the user's proximity to the platform may be monitored based on a paired device, or an arming mode of the device.
If the user had not been identified as away at block 2725, the process continued to block 2735. At block 2735, the process verifies the physical presence of the user, to verify that the configuration was performed by a physical user operating the configuration software, as opposed to by malicious software. In one embodiment, this can be verified by aggregating the user's requests for policy changes and then displaying them on some part of the screen which is not readable to software (e.g., “sprite” screen), but which the user can see. In one embodiment, this is accomplished by providing the anti-theft mechanism direct side-band access to the graphics controller. This part of the screen would also contain some means of confirmation. For example, it may display a confirmation code which only the user can see, or request an action from the user. The user would then type in the code, perform the requested action, or otherwise attest that the configuration request was made by an actual user. If attestation of physical user presence is not properly received, the process continues to block 2730 to reject the request as a rogue request. Otherwise, the process continues to block 2737.
At block 2740, the process determines whether the prior authenticated setting for this configuration element was “null” (e.g. blank). If so, the latest value entered by the user is applied as the mechanism's active policy in block 2745. In any case, the value entered by the user is recorded as the user's desired policy. The process then ends at block 2733. If the configuration element was not null prior to the user's entry, the latest recorded and authenticated value is applied as the mechanism's active policy, at block 2750. The process then ends at block 2733.
FIG. 28 is a flowchart of one embodiment of platform security in a monitored environment. A monitored environment is one in which there are controlled exit points. A controlled exit point may be an exit point that can be locked remotely, an exit point with one or more guards, or an exit point which can be otherwise made inaccessible. The process starts at block 2810. In one embodiment, the process starts when a platform is being used in the monitored environment. The flowchart is from the perspective of a security server, which receives information from the platform, and sends information to the controlled access points. In one embodiment, the system may be configured to enable a platform to directly send control signals to the controlled exit points.
At block 2815, the security server receives a notification that the platform is armed. The server assumes that the platform is not stolen.
At block 2820, the process determines whether a “suspecting” status update has been received from the platform. If no such mode has been received, the process returns to block 2815, to continue monitoring the armed platform. In one embodiment, when the platform is disarmed, the security server's monitoring is turned off. In one embodiment, the platform sends a notification that it has been disarmed, which ends monitoring.
If a “suspecting” status update is received from the platform, at block 2820, the process continues to block 2825. At block 2825, the process determines whether the suspecting mode was entered because of an attempt to override the disarming in the armed or suspecting modes. If so, at block 2830 the system alerts the controlled exit point. This may include alerting a guard, locking a gate, sounding an audio alarm at the exit point or throughout the building, or other actions. In one embodiment, some of these actions may take place with a time delay. For example, before alerting guards, the system may provide sufficient time for a user to disarm his platform, in case this was a false positive. In one embodiment, in order to further reduce false positives, the platform may locally provide an indicator to the user, so that he is aware that the platform is in suspecting mode and that further significant movement with it will cause the guards to be alerted. This indicator may be a visual indicator, an audio indicator, or another type of indicator.
FIG. 29 is a block diagram of an exemplary system 2900 in accordance with an embodiment of the present invention. The system 2900 may be coupled to the OEM board, described above, which implements the always-available anti-theft system described herein. As shown in FIG. 29, multiprocessor system 2900 is a point-to-point interconnect system, and includes a first processor 2970 and a second processor 2980 coupled via a point-to-point interconnect 2950.
Processors 2970 and 2980 are shown including integrated memory controller (IMC) units 2972 and 2982, respectively. Processor 2970 also includes as part of its bus controller units point-to-point (P-P) interfaces 2976 and 2978; similarly, second processor 2980 includes P-P interfaces 2986 and 2988. Processors 2970, 2980 may exchange information via a point-to-point (P-P) interface 2950 using P-P interface circuits 2978, 2988. As shown in FIG. 29, IMCs 2972 and 2982 couple the processors to respective memories, namely a memory 2932 and a memory 2934, which may be portions of main memory locally attached to the respective processors.
Processors 2970, 2980 may each exchange information with a chipset 2990 via individual P-P interfaces 2952, 2954 using point to point interface circuits 2976, 2994, 2986, 2998. Chipset 2990 may optionally exchange information with the coprocessor 2938 via a high-performance interface 2939. In one embodiment, the coprocessor 2938 is a special-purpose processor, such as, for example, a high-throughput MIC processor, a network or communication processor, compression engine, graphics processor, GPGPU, embedded processor, or the like. In one embodiment, chipset 2990 may implement the OEM board providing the always-available security system. In one embodiment, the chipset 2990 may be separately powered, as described above.
Chipset 2990 may be coupled to a first bus 2916 via an interface 2996. In one embodiment, first bus 2916 may be a Peripheral Component Interconnect (PCI) bus, or a bus such as a PCI Express bus or another third generation I/O interconnect bus, although the scope of the present invention is not so limited.
As shown in FIG. 29, various I/O devices 2914 may be coupled to first bus 2916, along with a bus bridge 2918, which couples first bus 2916 to a second bus 2920. In one embodiment, one or more additional processor(s) 2915, such as coprocessors, high-throughput MIC processors, GPGPU's, accelerators (such as, e.g., graphics accelerators or digital signal processing (DSP) units), field programmable gate arrays, or any other processor, are coupled to first bus 2916. In one embodiment, second bus 2920 may be a low pin count (LPC) bus. Various devices may be coupled to a second bus 2920 including, for example, a keyboard and/or mouse 2922, communication devices 2927 and a storage unit 2928 such as a disk drive or other mass storage device which may include instructions/code and data 2930, in one embodiment. Further, an audio I/O 2924 may be coupled to the second bus 2920. Note that other architectures are possible. For example, instead of the point-to-point architecture of FIG. 29, a system may implement a multi-drop bus or other such architecture. In one embodiment, the OEM board implementing the always-available anti-theft system (not shown) may be coupled to bus 2916 or second bus 2920.
Referring now to FIG. 30, shown is a block diagram of a second more specific exemplary system 3000 in accordance with an embodiment of the present invention. Like elements in FIGS. 29 and 30 bear like reference numerals, and certain aspects of FIG. 29 have been omitted from FIG. 30 in order to avoid obscuring other aspects of FIG. 30.
FIG. 30 illustrates that the processors 2970, 2980 may include integrated memory and I/O control logic (“CL”) 2972 and 2982, respectively. Thus, the CL 2972, 2982 include integrated memory controller units and include I/O control logic. FIG. 30 illustrates that not only are the memories 2932, 2934 coupled to the CL 2972, 2982, but also that I/O devices 3014 are also coupled to the control logic 2972, 2982. Legacy I/O devices 3015 are coupled to the chipset 2990.
disarming logic to receive a disarming command from a user, the disarming command to cause the battery access controller to provide access to the battery when the platform is disarmed wherein the disarming logic to receive an override command, the override command to enable access to the platform without disarming the platform; and a security action logic to perform a security action in response to receiving the override command, prior to causing the battery access controller to provide the access to the battery and a logic to minimize activation of the magnetic field used to drive the solenoid, by not activating the magnetic field when the battery mechanical latch is closed.
2. The system of claim 1, wherein the battery access controller is an original equipment manufacturer (OEM) embedded controller.
3. The system of claim 2, wherein the battery access controller is to be controlled by a messaging mechanism from the core logic to the OEM embedded controller.
4. The system of claim 3, wherein the messaging mechanism comprises one of: a general purpose input/output (GPIO), SMBus, or I2C.
5. The system of claim 1, wherein the security action comprises one or more of: sending a message via a network, sounding an alarm, and transitioning the system to another power state for data protection.
upon receiving a disarming command from a user, moving the platform from the armed mode and allowing access to the battery; upon receiving an override command, performing a security action in response to receiving the override command, prior to causing the battery access controller to provide the access to the battery and a logic to minimize activation of the magnetic field used to drive the solenoid, by not activating the magnetic field when the battery mechanical latch is closed wherein one of the method steps is implemented by a hardware processor.
7. The method of claim 6, wherein the battery access controller is an original equipment manufacturer (OEM) embedded controller.
8. The method of claim 6, wherein the battery access controller is controlled by a messaging mechanism from the core logic to the OEM embedded controller.
9. The method of claim 7, wherein the messaging mechanism comprises one of: a general purpose input/output (GPIO), SMBus, or 12C.
10. The method of claim 6 wherein the security action comprises one or more of: sending a message via a network, sounding an alarm, and transitioning the system to another power state for data protection.
"Extended European Search Report from European Patent Application No. 11877815.8, mailed Dec. 9, 2015, 11 pages."
"Partial Supplementary European Search Report from European Patent Application No. 11877815.8, mailed Aug. 21, 2015, 6 pages."
Decision of Rejection with English translation from Japanese Patent Application No. 2013-551974, mailed Jan. 13, 2015, 2 pages.
Extended European Search Report from European Patent Application No. 11877647.5, mailed Aug. 5, 2015, 6 pages.
Extended European Search Report from European Patent Application No. 11877652.5, mailed Jul. 9, 2015, 7 pages.
Extended European Search Report from European Patent Application No. 11877684.8, mailed Aug. 28, 2015, 5 pages.
Extended European Search Report from European Patent Application No. 11877701.0, mailed Aug. 5, 2015, 6 pages.
Extended European Search Report from European Patent Application No. 11877890.1, mailed Dec. 1, 2015, 11 pages.
Extended European Search Report from European Patent Application No. 1187798.2, mailed Aug. 5, 2015, 7 pages.
Extended European Search Report from European Patent Application No. 11877982.6, mailed Aug. 5, 2015, 6 pages.
Extended European Search Report from European Patent Application No. 11878026.1, mailed Aug. 5, 2015, 6 pages.
Extended European Search Report from European Patent Application No. 11878149.1, mailed Aug. 5, 2015, 5 pages.
Extended European Search Report from European Patent Application No. 11878212.7, mailed Aug. 5, 2015, 7 pages.
Extended European Search Report from European Patent Application No. 11878252.3, mailed Aug. 8, 2015, 6 pages.
Final Office action from U.S. Appl. No. 13/922,413, mailed Oct. 26, 2015, 7 pages.
Final Office action from U.S. Appl. No. 13/991,888, mailed Sep. 15, 2015, 14 pages.
Final Office action from U.S. Appl. No. 13/992,238, mailed May 20, 2015, 15 pages.
Final Office action from U.S. Appl. No. 13/992,238, mailed Nov. 5, 2015, 17 pages.
Final Office action from U.S. Appl. No. 13/992,413, mailed Feb. 18, 2015, 7 pages.
Final Office action from U.S. Appl. No. 13/992,690, mailed Jun. 18, 2015, 15 pages.
Final Office action from U.S. Appl. No. 13/992,705, mailed Apr. 6, 2016, 22 pages.
Final Office action from U.S. Appl. No. 13/992,705, mailed Apr. 9, 2015, 14 pages.
Final Office action from U.S. Appl. No. 13/992,725, mailed Oct. 8, 2015, 21 pages.
Final Office action from U.S. Appl. No. 13/993,051, mailed May 6, 2015, 8 pages.
Final Office action from U.S. Appl. No. 13/993,055, mailed May 27, 2016, 10 pages.
Final Office action from U.S. Appl. No. 13/993,055, mailed May 7, 2015, 9 pages.
Final Office action from U.S. Appl. No. 13/993,064, mailed Feb. 26, 2015, 19 pages.
Final Office action from U.S. Appl. No. 13/993,064, mailed Jan. 15, 2016, 25 pages.
Final Office action from U.S. Appl. No. 13/993,435 mailed Apr. 26, 2016, 11 pages.
Final Office action from U.S. Appl. No. 13/993,435, mailed Aug. 25, 2015, 11 pages.
Japanese Application No. 2013-551974, Notice of Reasons for Rejection, 4 pgs. (Jul. 1, 2014).
Notice of Allowance and Search Report with English translation for Taiwan Patent Application No. 101146693, mailed Oct. 22, 2014, 4 pages.
Notice of Allowance and Search Report with English translation of Search Report from Taiwan Patent Application No. 101146191, mailed Aug. 25, 2014, 5 pages.
Notice of Allowance from Japanese Patent Application No. 2013-551974, mailed Jun. 24, 2015, 1 page.
Notice of Allowance from Taiwan Patent Application No. 101144319, mailed Jul. 27, 2015, 2 pages.
Notice of Allowance from Taiwan Patent Application No. 101144320, mailed Apr. 29, 2016, 2 pages.
Notice of Allowance from Taiwan Patent Application No. 101144321, mailed Nov. 27, 2015, 2 pages.
Notice of Allowance from Taiwan Patent Application No. 101144508, mailed Jun. 26, 2015, 2 pages.
Notice of Allowance from Taiwan Patent Application No. 101144509, mailed Aug. 25, 2015, 2 pages.
Notice of Allowance from Taiwan Patent Application No. 101146185, mailed Sep. 22, 2015, 2 pages.
Notice of Allowance from Taiwan Patent Application No. 101146192, mailed Aug. 11, 2015, 2 pages.
Notice of Allowance from Taiwan Patent Application No. 101146687, mailed Nov. 26, 2015, 2 pages.
Notice of Allowance from Taiwan Patent Application No. 101149040, mailed Oct. 7, 2015, 2 pages.
Notice of Allowance from U.S. Appl. No. 13/991,888, mailed Mar. 2, 2016, 13 pages.
Notice of Allowance from U.S. Appl. No. 13/992,238, mailed Mar. 14, 2016, 16 pages.
Notice of Allowance from U.S. Appl. No. 13/992,413, mailed Mar. 16, 2016, 10 pages.
Notice of Allowance from U.S. Appl. No. 13/992,690, mailed Mar. 16, 2016, 15 pages.
Notice of Allowance from U.S. Appl. No. 13/993,048, mailed Apr. 3, 2015, 12 pages.
Notice of Allowance from U.S. Appl. No. 13/993,048, mailed Jul. 31, 2015, 9 pages.
Notice of Allowance from U.S. Appl. No. 13/993,051, mailed May 24, 2016, 7 pages.
Notice of Allowance from U.S. Appl. No. 13/993,536, mailed Mar. 19, 2015, 8 pages.
Notice of Allowance with English translation from Korean Patent Application No. 2013-7020375, mailed Jan. 20, 2016, 3 pages.
Notice of Final Rejection English translation from Korean Patent Application No. 2013-7020375, mailed Jan. 29, 2015, 5 pages.
Notice of Final Rejection with summarized English translation from Korean Patent Application No. 2013-7020375, mailed Jul. 6, 2015, 11 pages.
Notice of Preliminary Rejection with English translation from Korean Patent Application No. 2013-7020375, mailed Jul. 21, 2014, 12 pages.
Notification of Transmittal of the International Search Report and the Written Opinion or the International Searching Authority, or the Declaration for PCT Counterpart Application No. PCT/US2011/067051, 9 pgs., (Aug. 22, 2012).
Notification of Transmittal of the International Search Report and the Written Opinion or the International Searching Authority, or the Declaration for PCT Counterpart Application No. PCT/US2011/067052, 9 pgs., (Aug. 27, 2012).
Notification of Transmittal of the International Search Report and the Written Opinion or the International Searching Authority, or the Declaration for PCT Counterpart Application No. PCT/US2011/067053, 9 pgs., (Aug. 3, 2012).
Notification of Transmittal of the International Search Report and the Written Opinion or the International Searching Authority, or the Declaration for PCT Counterpart Application No. PCT/US2011/067054, 9 pgs., (May 7, 2012).
Notification of Transmittal of the International Search Report and the Written Opinion or the International Searching Authority, or the Declaration for PCT Counterpart Application No. PCT/US2011/067056, 11 pgs., (May 7, 2012).
Notification of Transmittal of the International Search Report and the Written Opinion or the International Searching Authority, or the Declaration for PCT Counterpart Application No. PCT/US2011/067057, 9 pgs., (Aug. 24, 2012).
Notification of Transmittal of the International Search Report and the Written Opinion or the International Searching Authority, or the Declaration for PCT Counterpart Application No. PCT/US2011/067059, 10 pgs., (Jul. 27, 2012).
Notification of Transmittal of the International Search Report and the Written Opinion or the International Searching Authority, or the Declaration for PCT Counterpart Application No. PCT/US2011/067060, 12 pgs., (Sep. 18, 2012).
Notification of Transmittal of the International Search Report and the Written Opinion or the International Searching Authority, or the Declaration for PCT Counterpart Application No. PCT/US2011/067061, 10 pgs., (Sep. 17, 2012).
Notification of Transmittal of the International Search Report and the Written Opinion or the International Searching Authority, or the Declaration for PCT Counterpart Application No. PCT/US2011/067063, 11 pgs., (Sep. 17, 2012).
Notification of Transmittal of the International Search Report and the Written Opinion or the International Searching Authority, or the Declaration for PCT Counterpart Application No. PCT/US2011/067064, 10 pgs., (Jul. 27, 2012).
Notification of Transmittal of the International Search Report and the Written Opinion or the International Searching Authority, or the Declaration for PCT Counterpart Application No. PCT/US2011/067065, 10 pgs., (Aug. 3, 2012).
Notification of Transmittal of the International Search Report and the Written Opinion or the International Searching Authority, or the Declaration for PCT Counterpart Application No. PCT/US2011/067066, 8 pgs., (Jul. 18, 2012).
Office action and Search Report from Taiwan Patent Application No. 101149040, mailed Mar. 17, 2015, 10 pages.
Office action and Search Report with English translation from Chinese Patent Application No. 201180068132.2, mailed Apr. 29, 2016, 4 pages.
Office action and Search Report with English translation from Chinese Patent Application No. 201180068132.2, mailed Jun. 12, 2015, 17 pages.
Office action and Search Report with English translation from Taiwan Patent Application 101144506, mailed Dec. 12, 2014, 15 pages.
Office action and Search Report with English translation from Taiwan Patent Application No. 101144320, mailed Jun. 29, 2015, 8 pages.
Office action and Search Report with English translation from Taiwan Patent Application No. 101144320, mailed Nov. 11, 2014, 9 pages.
Office action and Search Report with English translation from Taiwan Patent Application No. 101144508, mailed Oct. 17, 2014, 13 pages.
Office action and Search Report with English translation from Taiwan Patent Application No. 101144509, mailed Dec. 12, 2014, 17 pages.
Office action and Search Report with English translation from Taiwan Patent Application No. 101146185, mailed Dec. 22, 2014, 14 pages.
Office action and Search Report with English translation from Taiwan Patent Application No. 101146192, mailed Dec. 2, 2014, 14 pages.
Office action and Search Report with summarize English Translation from Taiwan Patent Application No. 101144321, mailed Apr. 28, 2015, 11 pages.
Office action and Search Report with summarized English translation from Taiwan Patent Application No. 101144319, mailed Dec. 9, 2014, 9 pages.
Office action and Search Report with summarized English translation from Taiwan Patent Application No. 101144321, mailed Aug. 26, 2014, 6 pages.
Office action and Search Report with summarized English translation from Taiwan Patent Application No. 101146684, mailed Oct. 21, 2014, 10 pages.
Office action from U.S. Appl. No. 13/922,705, mailed Sep. 17, 2015, 24 pages.
Office action from U.S. Appl. No. 13/991,888, mailed Jan. 8, 2015, 21 pages.
Office action from U.S. Appl. No. 13/991,888, mailed Oct. 29, 2015, 17 pages.
Office action from U.S. Appl. No. 13/992,238, mailed Dec. 8, 2014, 20 pages.
Office action from U.S. Appl. No. 13/992,413, mailed Jun. 11, 2015, 7 pages.
Office action from U.S. Appl. No. 13/992,413, mailed Sep. 30, 2014, 12 pages.
Office action from U.S. Appl. No. 13/992,480, mailed Feb. 3, 2016, 14 pages.
Office action from U.S. Appl. No. 13/992,480, mailed Mar. 31, 2015, 17 pages.
Office action from U.S. Appl. No. 13/992,690, mailed Nov. 20, 2014, 15 pages.
Office action from U.S. Appl. No. 13/992,705, mailed Nov. 4, 2014, 22 pages.
Office action from U.S. Appl. No. 13/992,725, mailed Apr. 7, 2015, 21 pages.
Office action from U.S. Appl. No. 13/992,725, mailed Mar. 24, 2016, 22 pages.
Office action from U.S. Appl. No. 13/992,725, mailed Oct. 27, 2014, 18 pages.
Office action from U.S. Appl. No. 13/993,048, mailed Sep. 25, 2015, 10 pages.
Office action from U.S. Appl. No. 13/993,051, mailed Oct. 22, 2014, 13 pages.
Office action from U.S. Appl. No. 13/993,051, mailed Sep. 25, 2015, 9 pages.
Office action from U.S. Appl. No. 13/993,055, mailed Nov. 30, 2015, 34 pages.
Office action from U.S. Appl. No. 13/993,055, mailed Oct. 21, 2014, 13 pages.
Office action from U.S. Appl. No. 13/993,064, mailed Jul. 6, 2015, 19 pages.
Office action from U.S. Appl. No. 13/993,064, mailed Jun. 16, 2016, 28 pages.
Office action from U.S. Appl. No. 13/993,064, mailed Nov. 4, 2014, 23 pages.
Office action from U.S. Appl. No. 13/993,435, mailed Dec. 31, 2015, 11 pages.
Office action from U.S. Appl. No. 13/993,435, mailed May 11, 2015, 13 pages.
Office action from U.S. Appl. No. 13/993,536, mailed Dec. 3, 2014, 15 pages.
Office action with English translation from Japanese Patent Application No. 2013-551974, mailed Jul. 1, 2014, 4 pages.
Office action with English translation from Taiwan Patent Application 101144506, mailed Aug. 25, 2015, 10 pages.
Office action with English translation from Taiwan Patent Application No. 101146684, mailed Jun. 29, 2015, 8 pages.
Office action with Search Report from Taiwan Patent Application No. 101146687, mailed May 8, 2015, 13 pages.
Partial Supplementary European Search Report from European Patent Application No. 11877890.1, mailed Aug. 12, 2015, 6 pages.
PCT Notification concerning Transmittal of International Preliminary Report on Patentability (Chapter I of the Patent Cooperation Treaty) for PCT Counterpart Application No. PCT/US2011/067051, 5 pgs., (Jun. 24, 2014).
PCT Notification concerning Transmittal of International Preliminary Report on Patentability (Chapter I of the Patent Cooperation Treaty) for PCT Counterpart Application No. PCT/US2011/067052, 5 pgs., (Jun. 24, 2014).
PCT Notification concerning Transmittal of International Preliminary Report on Patentability (Chapter I of the Patent Cooperation Treaty) for PCT Counterpart Application No. PCT/US2011/067053, 5 pgs., (Jun. 24, 2014).
PCT Notification concerning Transmittal of International Preliminary Report on Patentability (Chapter I of the Patent Cooperation Treaty) for PCT Counterpart Application No. PCT/US2011/067054, 5 pgs., (Jun. 24, 2014).
PCT Notification concerning Transmittal of International Preliminary Report on Patentability (Chapter I of the Patent Cooperation Treaty) for PCT Counterpart Application No. PCT/US2011/067056, 5 pgs., (Jun. 24, 2014).
PCT Notification concerning Transmittal of International Preliminary Report on Patentability (Chapter I of the Patent Cooperation Treaty) for PCT Counterpart Application No. PCT/US2011/067057, 5 pgs., (Jun. 24, 2014).
PCT Notification concerning Transmittal of International Preliminary Report on Patentability (Chapter I of the Patent Cooperation Treaty) for PCT Counterpart Application No. PCT/US2011/067059, 6 pgs., (Jun. 24, 2014).
PCT Notification concerning Transmittal of International Preliminary Report on Patentability (Chapter I of the Patent Cooperation Treaty) for PCT Counterpart Application No. PCT/US2011/067060, 7 pgs., (Jun. 24, 2014).
PCT Notification concerning Transmittal of International Preliminary Report on Patentability (Chapter I of the Patent Cooperation Treaty) for PCT Counterpart Application No. PCT/US2011/067061, 6 pgs., (Jun. 24, 2014).
PCT Notification concerning Transmittal of International Preliminary Report on Patentability (Chapter I of the Patent Cooperation Treaty) for PCT Counterpart Application No. PCT/US2011/067063, 6 pgs., (Jun. 24, 2014).
PCT Notification concerning Transmittal of International Preliminary Report on Patentability (Chapter I of the Patent Cooperation Treaty) for PCT Counterpart Application No. PCT/US2011/067064, 6 pgs., (Jun. 24, 2014).
PCT Notification concerning Transmittal of International Preliminary Report on Patentability (Chapter I of the Patent Cooperation Treaty) for PCT Counterpart Application No. PCT/US2011/067065, 6 pgs., (Jun. 24, 2014).
PCT Notification concerning Transmittal of International Preliminary Report on Patentability (Chapter I of the Patent Cooperation Treaty) for PCT Counterpart Application No. PCT/US2011/067066, 5 pgs., (Jun. 24, 2014).
PCT/US2011/067051 Notification Concerning Transmittal of International Preliminary Report on Patentabiliy, mailed Jul. 3, 2014.
PCT/US2011/067051 Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, mailed Aug. 22, 2012, 9 pages.
PCT/US2011/067052 Notification Concerning Transmittal of International Preliminary Report on Patentabiliy, mailed Jul. 3, 2014, 6 pages.
PCT/US2011/067052 Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, mailed Aug. 27, 2012, 9 pages.
PCT/US2011/067053 Notification Concerning Transmittal of International Preliminary Report on Patentabiliy, mailed Jul. 3, 2014, 6pages.
PCT/US2011/067053 Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, mailed Aug. 3, 2012, 9 pages.
PCT/US2011/067054 Notification Concerning Transmittal of International Preliminary Report on Patentability, mailed Jul. 3, 2014, 6pages.
PCT/US2011/067054 Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, mailed May 7, 2012, 9 pages.
PCT/US2011/067056 Notification Concerning Transmittal of International Preliminary Report on Patentability, mailed Jul. 3, 2014, 6pages.
PCT/US2011/067057 Notification Concerning Transmittal of International Preliminary Report on Patentability, mailed Jul. 3, 2014, 6pages.
PCT/US2011/067057 Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, mailed Aug. 24, 2012, 9 pages.
PCT/US2011/067059 Notification Concerning Transmittal of International Preliminary Report on Patentability, mailed Jul. 3, 2014, 7 pages.
PCT/US2011/067059 Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, mailed Jul. 27, 2012, 10 pages.
PCT/US2011/067060 Notification Concerning Transmittal of International Preliminary Report on Patentabiliy, mailed Jul. 3, 2014, 8 pages.
PCT/US2011/067060 Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, mailed Sep. 18, 2012, 11 pages.
PCT/US2011/067061 Notification Concerning Transmittal of International Preliminary Report on Patentabiliy, mailed Jul. 3, 2014, 7pages.
PCT/US2011/067061 Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, mailed Sep. 17, 2012, 10 pages.
PCT/US2011/067063 Notification Concerning Transmittal of International Preliminary Report on Patentabiliy, mailed Jul. 3, 2014, 7pages.
PCT/US2011/067063 Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, mailed Sep. 17, 2012, 10 pages.
PCT/US2011/067064 Notification Concerning Transmittal of International Preliminary Report on Patentabiliy, mailed Jul. 3, 2014, 7pages.
PCT/US2011/067064 Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, mailed Jul. 27, 2012, 10 pages.
PCT/US2011/067065 Notification Concerning Transmittal of International Preliminary Report on Patentabiliy, mailed Jul. 3, 2014, 7pages.
PCT/US2011/067065 Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, mailed Aug. 3, 2012, 10 pages.
PCT/US2011/0670656 Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, mailed May 7, 2012, 9 pages.
PCT/US2011/067066 Notification concerning transmittal of International Preliminary Report on Patentabiliy, mailed Jul. 3, 2014, 6 pages.
PCT/US2011/067066 Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, mailed Jul. 18, 2012, 8 pages.
U.S. Appl. No. 13/992,480, filed Aug. 7, 2015, 15 pages.

References: §371
 Application No. 11877815
 Application No. 11877815
 Application No. 2013
 Application No. 11877647
 Application No. 11877652
 Application No. 11877684
 Application No. 11877701
 Application No. 11877890
 Application No. 1187798
 Application No. 11877982
 Application No. 11878026
 Application No. 11878149
 Application No. 11878212
 Application No. 11878252
 Application No. 2013
 Application No. 101146693
 Application No. 101146191
 Application No. 2013
 Application No. 101144319
 Application No. 101144320
 Application No. 101144321
 Application No. 101144508
 Application No. 101144509
 Application No. 101146185
 Application No. 101146192
 Application No. 101146687
 Application No. 101149040
 Application No. 2013
 Application No. 2013
 Application No. 2013
 Application No. 2013
 Application No. 101149040
 Application No. 201180068132
 Application No. 201180068132
 Application No. 101144320
 Application No. 101144320
 Application No. 101144508
 Application No. 101144509
 Application No. 101146185
 Application No. 101146192
 Application No. 101144321
 Application No. 101144319
 Application No. 101144321
 Application No. 101146684
 Application No. 2013
 Application No. 101146684
 Application No. 101146687
 Application No. 11877890