Systems and methods to synchronize data to a mobile device based on a device usage context

- OPTIO LABS, INC.

A method, system, and computer-readable medium for synchronizing policy data on a device based on device usage context. By synchronizing policy data on the device based on device usage context, security, bandwidth and energy efficiency concerns associated with the current data synchronization art by intelligently organizing and prioritizing the updating of policy data in compliance with policy data.

Skip to: Description  ·  Claims  ·  References Cited  · Patent History  ·  Patent History
Description
CROSS-REFERENCE TO RELATED APPLICATIONS

Some of the aspects of the methods and systems described herein have been described in U.S. Provisional Application Nos. 61/780,408 entitled “Systems And Methods To Synchronize Data To A Mobile Device Based On A Device Usage Context”, filed Mar. 13, 2013; 61/781,252 entitled “Systems And Methods To Secure Short-Range Proximity Signals”, filed Mar. 14, 2013; 61/785,109 entitled “Systems And Methods For Securing And Locating Computing Devices”, filed Mar. 14, 2013; 61/779,931 entitled “Systems And Methods For Securing The Boot Process Of A Device Using Credentials Stored On An Authentication Token”, filed Mar. 13, 2013; 61/790,728 entitled “Systems And Methods For Enforcing Security In Mobile Computing”, filed Mar. 15, 2013; and U.S. Non-Provisional application Ser. No. 13/735,885 entitled “Systems and Methods for Enforcing Security in Mobile Computing”, filed Jan. 7, 2013, each of which is hereby incorporated by reference herein in its entirety.

BACKGROUND OF THE INVENTION

The present invention is in the technical field of communications security. More particularly, the present invention is in the technical field of policy enforcement related to administrative access in mobile communications devices in a manner that, among other things, provides significant improvements in energy efficiency.

SUMMARY OF THE INVENTION

The present invention includes a method for synchronizing data to a mobile device based on device usage context.

Modern mobile devices often store data that is synchronized with a remote system, such as a server. Because of its finite resources compared to the remote system, usually only a partial image of the data stored on the remote system is replicated on the mobile device. This is often accomplished by passing incremental updates between the two systems. For example, a user's email inbox, sent folder and other saved folders may be all be stored on a remote email server, and only the most recent 25 emails in the inbox may be stored on the user's mobile device. The emails residing on the mobile device may be updated as the user drafts additional emails from the device or as new emails received at the mail server are pushed to the mobile device. Changes made at the mobile device may be recorded at the mail server as the user, for example, sends emails via the mail server.

In many modern devices, a polling-based communication approach is used to synchronize data between the device and the server. In a polling approach, the device periodically initiates communication with the server when it determines that data needs to be synchronized. For example, data can be synchronized by polling using the hyper-text transfer protocol where the device periodically issues a hyper-text transfer protocol request to receive data from the server via a hyper-text transfer protocol response. A problem with common polling approaches is that they used fixed intervals or rely on indications sent from the server and may not be resource efficient. The present invention uses a device context that indicates the cyber or physical state of the device to determine the most appropriate times to poll the server and synchronize data. The cyber state can be any software associated state or event, such as specific data in memory. The physical state can be elements regarding the physical world surrounding the device or hardware elements on the device, such as wireless signals in proximity to the device.

The present invention may address security, bandwidth and energy efficiency concerns associated with the current art for synchronizing data on mobile device by intelligently organizing and prioritizing the synchronization of higher priority data. In a system where data is synchronized between two computing systems, such as a server and a mobile device, it may be more secure and more efficient (both with respect to bandwidth and energy usage) to only synchronize said data when it will be of use to one of the computing systems. For example, when synchronizing data to a mobile device from a central server, the mobile device only needs the data when the user is actively using the data or when the data will be immediately usable, not when the mobile device is sitting idle.

These security and efficiency concerns may be addressed by defining multiple classes of data with different synchronization priorities, by defining and monitoring the device's context (e.g. whether the device is idle, whether the user is attempting to unlock the device, whether the user is starting the email client, etc.) and synchronizing one or more classes of data based on the existing classes and the system context.

The present invention may benefit applications, including but not limited to, communications applications, such as enhanced features of chat, sharing, social networking, contact management, messaging, email, web browsing and the like; games and entertainment content applications (video games, music, video content, online content, etc.); command and control applications and features (operating system control, phone control, restricted/secured data access control, etc.); enterprise IT management applications, such as device imaging and device wiping; automotive applications, such as navigation, driver support and safety systems; and advanced security tools, such as anti-virus, firmware integrity, operating system integrity, boot loader integrity, firewalls, intrusion detection systems, and intrusion prevention systems, and the like.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 provides a schematic view of components of a system for synchronization as described in certain preferred embodiments.

FIG. 2 illustrates one method of synchronizing data between a device and a server.

FIG. 3 illustrates the process of one embodiment of the invention.

 DETAILED DESCRIPTION

Referring to the invention in FIG. 1, a device 102 may include one or more of a processor 103, a memory 105, a communication facility 112, and a synchronization facility 114. Communication facility 112 may provide an input and/or output mechanism to communicate with other network devices such as router 105 or server 104. The communication facility 112 may also provide communication with, for example, other gateways 109, wireless access nodes 111, and application servers 113 to send and receive data such as packets and messages. The communication facility 112 may provide connectivity to 3G, 4G, WiFi, or other network types. Processor 103 runs software which uses the communication facility 112 and the memory 105. Memory 105 comprises storage media such as a tangible, non-transitory computer readable medium, a programmable read only memory (PROM), or flash memory. Processor 103 may be any computer chip that is capable of executing program instruction streams that are part of a software program. Processor 103 may have multiple cores for executing multiple streams of program instructions simultaneously. The processor 103 may also have multiple sub-processors which are optimized for executing particular categories of program instructions and are controlled by the processor. The memory 105 is capable of storing and retrieving program instructions, program data, or any other data that is used by the processor. The processor 103 may store and retrieve data from the memory as a software program is executed. Memory 105 may include or store the synchronization facility 114. Memory 105 may also include associated polies and configurations. The processor may access and update the synchronization facility 114 and associated policies and configurations. Synchronization facility 114 may communicate, through communication facility 112, to a server 104 via a network 106, to synchronize data 108A, 110A, 122A on the device 102 with data 108B, 110B, 122B on the server 104. In some embodiments, the data may be separated into a plurality of classes, such as high priority data 108 A and B and low priority data 110 A and B. The synchronization facility 114 may initiate data synchronization of one or more classes of data based upon an input, such as a change of state from one or more resources on the device 102. For example, the synchronization facility 114 may initiate data synchronization of the high priority data based upon an input from the power management facility 118 indicating that the device 102 is being powered on. In another example, the synchronization facility 114 may initiate data synchronization of the low priority data based upon an input from the device user interface (UI) 116 indicating that the user of the device 102 has started an application that utilizes the low priority data. In still another example, the synchronization facility 114 may initiate data synchronization of policy data 122 for use by a policy engine 124.

A trusted code zone 126 may exist on the system as a zone of processor 103. One or more encryption elements 128 may be are placed within the trusted code zone 126. A trusted code zone of a processor may ensure through a cryptographic chain of trust that code executing within it has not been tampered with. Once an element is placed within the trusted processor zone for execution, the output from operations performed on it may be considered tamper-free, correct, and trusted. An example of commercial software providing trusted zone functionality is TRUSTZONE by ARM Limited. The one or more encryption elements 128 may be used to perform cryptographic operations to improve the security of the device 102. For example, the encryption element 128 may encrypt some or all of the device's communications over communication facility 112.

The trusted code zone 126 may also include an encryption element 128 or verification element 130 that is used to securely validate one or more elements of the context or context determination. The trusted code zone 126 protects the integrity of the encryption element 128 or verification element 130 to ensure that the context is correctly determined and/or that any communication between the device and the server is properly encrypted and/or authenticated.

In other embodiments, an external security device 132 may be used to verify elements of the context and/or encryption or authentication of the synchronization process with the server. The external security device may be a smartcard reader, such as a Bluetooth enabled reader of a government common authentication card. The external security device may also be a sleeve that is attached to the device and plugged into one or more ports on the device, such as the universal serial bus port. The external security device may also be used to verify the integrity or authenticity of data received from the server. The external security device may also be used to decrypt data received from the server. The external security device may be used instead of or in combination with the encryption element 128 and verification element 130 to perform verification, authentication, and encryption functions. For example, the external security device may encrypt a request to the server, authenticate the device or request to the server, authenticate the server or response to the device, verify the integrity and/or origin of the data received from the server, or verify the context of the device.

The device (e.g., mobile device, handheld device, laptop, or other computing device) described above can be a smart phone offering advanced capabilities including, but not limited to word processing, web browsing, gaming, e-book capabilities, an operating system, a user interface, and a full keyboard. The device may run an operating system such as SYMBIAN OS, APPLE IOS, RIM'S BLACKBERRY, WINDOWS MOBILE, Linux, PALM WEBOS, and ANDROID. The screen may be a touch screen that can be used to input data to the mobile device and the screen can be used instead of a full keyboard. The device may have the capability to run applications or communicate with applications that are provided by other network devices. The device can receive updates and other information from these applications via the communication facility.

We now describe some embodiments of a method of adaptive synchronization that may include adapting a synchronization facility 114 on a device 102 to determine when to synchronize a plurality of classes of data 108 A and B, 110 A and B, 122 A and B with data on a server 104. FIG. 2 displays one such embodiment. At step 200, a device context is determined based on a device state or event. At step 201, a time is determined to synchronize data with the server based on the device context. At step 203, data is synchronized with the server at the determined time. Further details of the operation of at least some embodiments of the invention are discussed below. In a system where data is synchronized between two computing systems, such as a server 104 and a device 102, it may be advantageous to only synchronize said data when it will be of use to one of the computing systems. For example, when synchronizing data to a mobile device from a central server, the device may only need the data when the device user is actively using the data or when the data will be immediately usable, not when the mobile device is sitting idle. Alternately, it may be advantageous to synchronize certain data when the user stops using the mobile device so that the data will be present when the device user next begins to actively use the device. It is also advantageous to adjust the data synchronization process based on current usage state because it may allow the device to realize the full power consumption benefits in low-power states, such as when the device display is turned off, and perform more power-intensive tasks, such as network operations, when the device is in already in use.

The context determination may be used to aid in identifying an appropriate time to synchronize a device with data on a server in order to ensure that the data is up to date immediately before a user begins using the device. For example, the cyber context may be determined from one or more events indicating that the lock screen of the device is being unlocked, indicating that the user is about to begin using the device and its data should be synchronized with the server. In another embodiment, the launch of an application, such as a sensitive corporate application, may indicate that the user is about to begin using it and that the device should synchronize data specifying allowed usage of that application. In another embodiment, the device context may indicate that the device is being turned on and that the device should synchronize data before the user begins using the device. In another embodiment, the context may be the connection or disconnection from a network, indicating that data related to the network is or is not needed.

In some embodiments, a device context is determined in order to synchronize data at an advantageous time. In at least some embodiments, the context may be determined based on a device state. In some embodiments, the context may be determined based on a device event.

In at least some embodiments, the device event is an event that is related to a cyber-state of the device. Such events may include the device being locked or unlocked, the device screen turning on or off, an application launching on the device, the device connecting to or disconnecting from a network or from a specific network, or a financial transaction being in progress. For example, the device might determine the device context when the device is unlocked in order to synchronize data when a user begins engaging in use of the device. Device context can also be determined based on combinations of such events or the states the events are related to. For example, the device context might be determined when the device is unlocked while connected to a specific network. In that circumstance, synchronization might be triggered. As an example of the advantages of such a circumstance, synchronization of confidential information could be limited to when the device is connected to a secure network. Synchronization might also be triggered when the device disconnects from the secure network in order to remove the confidential data from the device when the device is not connected to the secure network.

In at least some embodiments, the device state is a physical state of the device. Such states may include the current velocity or speed of the device, the location of the device within a building as determined by an indoor navigation or trilateration system, or the presence or absence of short range data signals (e.g., BLUETOOTH, BLUETOOTH LOW ENERGY BEACON, or Near Field Communication Tag signals) in the environment around the device. For example, the location of the device within a building as determined by an indoor navigation system, consisting of proximity signaling beacons, such as Bluetooth Low Energy Beacons, may indicate that the device needs to synchronize information relevant to policies for using computing resources within that physical location. Alternately, the device might determine the device context when the device is located near a point of interest in a building. In that circumstance, synchronization of data related to the point of interest might be triggered. As an example of the advantages of such a circumstance, a user might receive information about the point of interest without having to wait for such information to be transferred to their device. In another example, the physical context may indicate the speed or velocity of the device and the device may need to synchronize data regarding the policies regarding sending text messages while in motion. The physical context may also include a quick response code or near field communication tag indicating a tagged object, such as a product, that related information should be synchronized for between the device and server. Device context can also be determined based on combinations of physical states. For example, synchronization might be triggered when the device is located near a point of interest and the current speed of the device is near zero. This is further advantageous because information is only transferred when a user is dwelling near a point of interest, minimizing data transfers when a user simply passes by a point of interest.

The physical context in place of or in addition to the cyber context can be used to determine when to poll the server. Device contexts can also be determined based on various combinations of one or more of device cyber-states, device physical states, device events related to device cyber-states, device events related to device physical states. While the above embodiments are described in relation to immediately triggering synchronization, synchronization may also be triggered at a delayed interval or canceled based on the device context. Further, an already scheduled synchronization may have its scheduled time accelerated or decelerated based on the device context. In other embodiments, other changes to synchronization patterns may also occur in response to the determination of a device context.

Once a synchronization has been scheduled or triggered, the synchronization proceeds at the time determined by the device context. Other aspects of the synchronization may also be affected by the device context. For example, in addition to determining when to synchronize data, the context may also be used to aid in determining what data to synchronize with the device. For example, the context may indicate that data relevant to a specific physical location needs to be synchronized with the device.

The device context can thus help to selectively determine what data should be synchronized or what types of data should be synchronized. In some embodiments, the device context can trigger synchronization of high priority data. In other embodiments, the device context can bar synchronization of high priority data. As an example of the advantages of such features, device context could trigger or bar the synchronization of confidential data when a user is on a secure network or not on a secure network.

In one embodiment, a user interaction with the device 102 may initiate a synchronization event. The user interaction with the device 102 may be, for example, an input to the device UI 116. The input to the device UI 116 may one or more of locking the device 102, unlocking the device 102, starting an application, stopping an application, using an application, booting the device 102, shutting down the device 102, sending information to a remote computer, requesting information from a remote computer, or some other input, and the like. The synchronization event may be syncing files, syncing contacts, syncing mail, syncing encryption keys, syncing financial data, or other synchronizations.

In other embodiments, the synchronization event may be initiated by the device 102 or software executing on the device 102. For example, the power management facility 118 may initiate a synchronization event when the device 102 battery reaches a certain charge.

In one example, the user may provide an input to the device UI 116 to lock the screen, and, based on that input, the synchronization facility 114 may indicate determine the device's state (i.e. the user is not intending to use the device for a period of time) and, based on the state, begin synchronizing data on the device. As a result, the device synchronizes data when the network connection is likely to be unoccupied and synchronization data does not compete for bandwidth with user data when the user is using the device.

In some embodiments, multiple classes of data are defined for synchronization between the computing systems. One class may be low priority data 110 A and B. In some embodiments, the low priority data 110 A and B may be synchronized only when the device is active. Types of data that may be in the class of low priority data may include, for example, personal emails, tweets, contact information, music files, and image files.

Another class of data may be high priority data 108 A and B. In some embodiments, the high priority data may be synchronized regardless of the current usage state of the device. Types of data that may be in the class of high priority data may include, for example, confidential business emails, text messages, voicemail notifications, instructions to wipe data on the device, and classified data. In some embodiments, there may be additional classes of data, such as medium priority data, medium-low priority data, highest priority data, and other classes of data. These classes of data may include, for example, (insert list of types of data).

In embodiments, the data being synchronized may be policy data 122 for a policy engine 124, which may use the policy data 122 to control aspects or features of the device 102. The policy engine 124 may generate a device-specific context, which may include one or more of the current date and time, the device location, the identity of the device user, and other context-related data. In some embodiments, the policy engine may be connected to a server 104, such as a policy server, which may push one or more policies as policy data 122 to the policy engine 124.

The policy engine 124 may be used to enforce one or more security policies on the device 102. In some embodiments, the policy data 122 may include a policy for the policy engine 124 to cause the device 102 to disable functionality. For example, the policy may include a rule for disabling the camera 120 when the policy engine 124 determines that the device 102 is located in a building that prohibits the use of cameras, like a research lab. In other embodiments, the policy data 122 may include a policy for the policy engine 124 to cause the device 102 to perform operations like erasing the stored content on the device 102. For example, the policy may include a rule for wiping all memory on the device 102 when the device user is not an authorized user or in response to an instruction from an authorized user who lost the device 102. In embodiments, a policy that disables the camera 120, for instance, may need only be synchronized when the device 102 is in a high-power state, as the camera 120 cannot be used in a low-power state regardless. However, in the case of a stolen or compromised device 102, it would be necessary to erase any sensitive data stored on the device 102 immediately rather than when the device 102 is going to be interacted with.

In another embodiment, the data synchronization strategy could depend on the context of the receiving computing system. For example, the synchronization facility 114 may initiate data synchronization when events occur on the device 102 such as, when an application is started or stopped. In the policy synchronization example, a synchronization of policies between the computing systems may be triggered when an untrusted application is launched on the device 102. In embodiments, data may be synchronized between a device and a server based on the power usage state of the device and/or based on other considerations. In embodiments, synchronization may be based on various considerations described herein separately or together.

The synchronization system could be made more or less complicated by adjusting the synchronization conditions. For example, the synchronization facility 114 may only use the network 106 while the device 102 is active and the network 106 connection is idle. In another example, the synchronization facility 114 may only use the network 106 while the device 102 is active and in a particular geo-location. In still another example, the synchronization facility 114 may only use the network 106 while the device 102 is active and the user has permitted synchronization.

In some embodiments, the data synchronized with the device may be financial data, such as a credit card number that is needed to purchase an item in the current context. The context may be, but is not limited to, a retail business, a bank, or a financial trading floor. The device may synchronize a preferred credit card processor, pin code, or other information to complete transactions in the context. The device may synchronize data related to transactions or trades currently occurring in a trading context. The synchronization of financial data ensures that financial transactions can be completed in a timely matter by having as much data needed to complete the transaction as possible already stored on the device.

In an example embodiment, the method is performed according to the algorithm shown in FIG. 3. In state 300, the device checks whether an unlocking event has been detected or a synchronization time has been reached. If an unlocking event has not been detected and a synchronization time has not been reached, the device remains in state 300. If an unlocking event has been detected, the device proceeds to state 301 where it determines a time for synchronization. If a synchronization time has been reached, the device proceeds to state 302. In state 301, the device determines the additional device context of whether the user is connected to an encrypted network. If it is, synchronization is scheduled to occur immediately and the device proceeds to state 302; otherwise, synchronization is scheduled to occur later and the device returns to state 300. In state 302, a synchronization type is determined according to a device context. In state 302 of this embodiment, the device checks whether the device is located within a retail bank associated with the user. If the device is located within a retail bank associated with the user, then synchronization data includes transaction data. If the device is not located within a retail bank associated with the user, then synchronization data does not include transaction data. In either case, the device proceeds to state 303. In state 303, the device performs synchronization.

One possible device state or event suitable for use in determining a device context is a determination that a user is authorized according to the invention of U.S. Provisional Patent Application No. 61/779,931. Another possible device state or event suitable for use in determining a device context is the location-based authorization described in the invention of U.S. Provisional Patent Application No. 61/785,109. Reading of the authentication token and credential processing may be performed in a trusted zone of a processor in some embodiments in accordance with the invention of U.S. Provisional Patent Application No. 61/790,728. Inter-process communications triggered by the invention of U.S. Provisional Patent Application No. 61/781,252 may also be suitable for use in determining a device context.

While the foregoing written description of the invention describes a method of implementing the invention, those of ordinary skill will understand and appreciate that it could equally be implemented by an apparatus containing some or all of the components shown in FIG. 1, by a non-transitory computer readable medium executed on a processor to perform the steps described, or other implementations within the scope and spirit of the invention. Further, while the foregoing written description of the invention enables one of ordinary skill to make and use what is considered presently to be the best mode thereof, those of ordinary skill will understand and appreciate the existence of variations, combinations, and equivalents of the specific embodiment, method, and examples herein. The invention should therefore not be limited by the above described embodiment, method, and examples, but by all embodiments and methods within the scope and spirit of the invention.

Claims

1. A method for selectively synchronizing data to a device by polling a server, comprising:

applying initial policy data to the device via a policy engine;
determining applicable device contexts based on the policy data;
detecting the presence of an applicable device context based on at least one of a device state or event;
determining a time to synchronize policy data with the server based on the detected device context;
synchronizing policy data with the server at the determined time to generate updated policy data, wherein one or more aspects of synchronizing the policy data is secured via an external security module connected to the device, and wherein securing the one or more aspects of synchronizing the policy data comprises one or more of encrypting a request to the server, authenticating the device to the server, authenticating the server to the device, verifying the integrity of data received from the server, or verifying the context of the device;
applying updated policy data to the device via the policy engine; and
determining updated applicable device contexts based on the updated policy data,
wherein communications with the server are encrypted by an encryption element within a trusted code zone of the device, and one or more aspects of the device context are verified by a verification element within the trusted code zone of the device.

2. The method of claim 1, wherein the device event is an event regarding the cyber-state of the device.

3. The method of claim 2, wherein the device event comprises at least one of device locking, device unlocking, the screen of the device turning on, the screen of the device turning off, the launch of an application, the connection to a specific network, or the disconnection from a specific network.

4. The method of claim 1, wherein the device state is a physical state of the device.

5. The method of claim 4, wherein the physical state comprises at least one of the location of the device within a building as determined by an indoor navigation system, the current velocity or speed of the device, or the presence or absence of short range data signals in a device environment.

6. The method of claim 1, wherein the device context is determined based on the device state and a GPS coordinate of the device.

7. The method of claim 1, wherein determining a time comprises accelerating synchronization with the server already scheduled to occur.

8. The method of claim 1, wherein the device context is determined by an external short range signal.

9. The method of claim 1, further comprising determining what data to selectively synchronize with the server based on the device context.

10. The method of claim 1, wherein the device context includes information on an in-process financial transaction and the data synchronized with the server includes one or more pieces of information relevant to the financial transaction.

11. A non-transitory computer-readable storage medium comprising: instructions executable by one or more processors to cause the one or more processors to:

apply initial policy data to a device via a policy engine;
determine applicable device contexts based on the policy data;
detect the presence of an applicable device context based on at least one of a device state or event;
determine a time to synchronize policy data with a server based on the detected device context;
synchronize policy data with the server at the determined time to generate updated policy data, wherein one or more aspects of synchronizing the policy data is secured via an external security module connected to the device, and wherein securing the one or more aspects of synchronizing the policy data comprises one or more of encrypting a request to the server, authenticating the device to the server, authenticating the server to the device, verifying the integrity of data received from the server, or verifying the context of the device;
apply updated policy data to the device via the policy engine; and
determine updated applicable device contexts based on the updated policy data, wherein communications with the server are encrypted by an encryption element within a trusted code zone of the device, and one or more aspects of the device context are verified by a verification element within the trusted code zone of the device.

12. The non-transitory computer-readable storage medium of claim 11, wherein the device event comprises at least one of device locking, device unlocking, the screen of the device turning on, the screen of the device turning off, the launch of an application, the connection to a specific network, or the disconnection from a specific network.

13. The non-transitory computer-readable storage medium of claim 11, wherein the device state comprises at least one of the location of the device within a building as determined by an indoor navigation system, the current velocity or speed of the device, or the presence or absence of short range data signals in a device environment.

14. A system for accessing a file system, comprising: one or more hardware processors communicatively coupled to a file system, wherein the hardware processors are additionally communicatively coupled to a server via a network, wherein the one or more hardware processors are configured to:

apply initial policy data to a device via a policy engine;
determine applicable device contexts based on the policy data;
detect the presence of an applicable device context based on at least one of a device state or event;
determine a time to synchronize policy data with the server based on the detected device context;
synchronize policy data with the server at the determined time to generate updated policy data, wherein one or more aspects of synchronizing the policy data is secured via an external security module connected to the device, and wherein securing the one or more aspects of synchronizing the policy data comprises one or more of encrypting a request to the server, authenticating the device to the server, authenticating the server to the device, verifying the integrity of data received from the server, or verifying the context of the device;
apply updated policy data to the device via the policy engine; and
determine updated applicable device contexts based on the updated policy data, wherein communications with the server are encrypted by an encryption element within a trusted code zone of the device, and one or more aspects of the device context are verified by a verification element within the trusted code zone of the device.

15. The system of claim 14, wherein the one or more hardware processors further comprise the encryption element within a trusted code zone of the one or more hardware processors.

Referenced Cited
U.S. Patent Documents
6317868 November 13, 2001 Grimm et al.
6467086 October 15, 2002 Kiczales et al.
7207041 April 17, 2007 Elson et al.
7461144 December 2, 2008 Beloussov et al.
7681226 March 16, 2010 Kraemer et al.
7966599 June 21, 2011 Malasky et al.
8099596 January 17, 2012 Rusakov et al.
8225329 July 17, 2012 Lynn
8387048 February 26, 2013 Grechishkin et al.
8490191 July 16, 2013 Kuegler et al.
8505029 August 6, 2013 Chanda et al.
8516095 August 20, 2013 Eisener
8533860 September 10, 2013 Grecia
8584229 November 12, 2013 Brutch et al.
8595832 November 26, 2013 Yee et al.
8613052 December 17, 2013 Weiss
8655307 February 18, 2014 Walker
8874891 October 28, 2014 Gattegno
8887308 November 11, 2014 Grecia
9191382 November 17, 2015 Hornung et al.
20020052965 May 2, 2002 Dowling
20030115291 June 19, 2003 Kendall et al.
20030140088 July 24, 2003 Robinson
20030149874 August 7, 2003 Balfanz et al.
20030194094 October 16, 2003 Lampson et al.
20040199763 October 7, 2004 Freund
20040255145 December 16, 2004 Chow
20050060365 March 17, 2005 Robinson
20050071643 March 31, 2005 Moghe
20050136845 June 23, 2005 Masuoka et al.
20050138416 June 23, 2005 Qian et al.
20050240396 October 27, 2005 Childs et al.
20050240985 October 27, 2005 Alkove et al.
20050246453 November 3, 2005 Erlingsson et al.
20050246522 November 3, 2005 Samuelsson et al.
20050246718 November 3, 2005 Erlingsson et al.
20060048226 March 2, 2006 Rits et al.
20060092037 May 4, 2006 Neogi et al.
20060224742 October 5, 2006 Shahbazi
20070088792 April 19, 2007 Piper et al.
20070186274 August 9, 2007 Thrysoe et al.
20070271594 November 22, 2007 Wobber et al.
20080115011 May 15, 2008 Codrescu et al.
20080126800 May 29, 2008 Guo et al.
20080134347 June 5, 2008 Goyal et al.
20080235587 September 25, 2008 Heie et al.
20080278408 November 13, 2008 Strickland et al.
20090025011 January 22, 2009 Neil et al.
20090030974 January 29, 2009 Boudreau
20090138547 May 28, 2009 Boudreau
20090204815 August 13, 2009 Dennis et al.
20090282477 November 12, 2009 Chen et al.
20090319782 December 24, 2009 Lee
20100023582 January 28, 2010 Pedersen et al.
20100031252 February 4, 2010 Horwitz
20100031325 February 4, 2010 Maigne et al.
20100037311 February 11, 2010 He
20100121567 May 13, 2010 Mendelson
20100121597 May 13, 2010 Steffens et al.
20100153697 June 17, 2010 Ford et al.
20100306759 December 2, 2010 Kohler et al.
20110055890 March 3, 2011 Gaulin et al.
20110067107 March 17, 2011 Weeks et al.
20110151955 June 23, 2011 Nave
20110197201 August 11, 2011 Yoo et al.
20110225624 September 15, 2011 Sawhney et al.
20120033678 February 9, 2012 Page et al.
20120084381 April 5, 2012 Alladi et al.
20120084792 April 5, 2012 Benedek et al.
20120116602 May 10, 2012 Vaswani et al.
20120129503 May 24, 2012 Lindeman et al.
20120191677 July 26, 2012 Lim
20120197988 August 2, 2012 Leppanen
20120210417 August 16, 2012 Shieh
20120215637 August 23, 2012 Hermann
20120254602 October 4, 2012 Bhansali et al.
20120255014 October 4, 2012 Sallam
20120258730 October 11, 2012 Tinnakornsrisuphap et al.
20120304310 November 29, 2012 Blaisdell
20130007873 January 3, 2013 Prakash et al.
20130054812 February 28, 2013 DeCoteau
20130067488 March 14, 2013 Kumar et al.
20130083722 April 4, 2013 Bhargava et al.
20130086202 April 4, 2013 Connelly et al.
20130091543 April 11, 2013 Wade et al.
20130111039 May 2, 2013 Gomes
20130124840 May 16, 2013 Diluoffo et al.
20130145362 June 6, 2013 Dawson et al.
20130179991 July 11, 2013 White et al.
20130227641 August 29, 2013 White et al.
20130232573 September 5, 2013 Saidi et al.
20130268997 October 10, 2013 Clancy, III et al.
20130291056 October 31, 2013 Gaudet et al.
20130312058 November 21, 2013 Thompson et al.
20140059357 February 27, 2014 Andersson et al.
20140075451 March 13, 2014 Anderson et al.
20140201807 July 17, 2014 White et al.
20140256251 September 11, 2014 Caceres et al.
20140273857 September 18, 2014 White et al.
20140282992 September 18, 2014 Clancy, III et al.
20140283136 September 18, 2014 Dougherty et al.
Other references
  • Bertino, E., et al., “Location-Based Access Control Systems for Mobile Users—Concepts and Research Directions,” SPRINGL '11 ACM, Chicago, IL, Nov. 1, 2011 (pp. 49-52) (4 pages).
  • Cogen, D. “Android 101: Rooting, Jailbreaking, and Unlocking,” http://theunlockr.com/2010/08/27/android-101-rooting-jailbreaking-and-unlocking Accessed Dec. 15, 2014 (8 pages).
  • Extended European Search Report issued by the European Patent Office for European Patent Application No. 13733798.6 dated May 6, 2015 (6 pages).
  • Fenzi, K. “Tuning Your SELinux Policy with Audit2allow,” http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/SA/v14/i08/a1.htm Accessed Dec. 15, 2014 (6 pages).
  • Garfinkel, T. “Traps and Pitfalls: Practical Problems in System Call Interposition Based Security Tools,” The 10th Annual Network and Distributed System Security Symposium, Feb. 2003 (14 pages).
  • International Search Report and Written Opinion issued by the U. S. Patent and Trademark Office as International Searching Authority for International Application No. PCT/US14/47826 dated Apr. 1, 2015 (8 pages).
  • International Search Report and Written Opinion issued by the United States Patent and Trademark Office as International Searching Authority for International Application No. PCT/US2015/020492 mailed Jun. 25, 2015 (7 pages).
  • International Search Report and Written Opinion issued by the United States Patent Office as International Searching Authority for Application No. PCT/US14/33344 mailed on Sep. 11, 2014 (12 pages).
  • Kotrappa, S., et al., “Multilevel Security Using Aspect Oriented Programming AspectJ,” 2010 International Conference on Advances in Recent Technologies in Communication and Computing, IEEE Computer Society, No Month 2010, (pp. 369-373) (5 pages).
  • Schreiber, T. “Android Binder: Android Interprocess Communication,” Ruhr-Universitat Bochum, Seminarthesis Oct. 5, 2011 (34 pages).
  • Shimko, S., et al., “Securing Inter-process Communications in SELinux,” Tresys Technology, LLC, Mar. 12, 2007 (10 pages).
Patent History
Patent number: 9578445
Type: Grant
Filed: Mar 13, 2014
Date of Patent: Feb 21, 2017
Patent Publication Number: 20140282857
Assignee: OPTIO LABS, INC. (Boston, MA)
Inventors: Christopher Jules White (Nashville, TN), Brian Dougherty (Nashville, TN), Thomas Charles Clancy, III (Washington, DC), David Alexander Hamrick (Nashville, TN), Grayson Gates Sharpe (Louisville, KY), Robert Austin Hanlin (Nashville, TN), Krzysztof Kamil Zienkiewicz (Nashville, TN), Christopher Michael Thompson (Nashville, TN)
Primary Examiner: Mahfuzur Rahman
Application Number: 14/210,376
Classifications
Current U.S. Class: Client/server (709/203)
International Classification: H04L 29/06 (20060101); H04W 4/00 (20090101); H04W 4/02 (20090101); G06F 21/62 (20130101); G01S 5/00 (20060101); H04W 64/00 (20090101); G06F 21/44 (20130101); G01S 5/02 (20100101);