CROSS-REFERENCE TO RELATED APPLICATIONS

[0001 ] This application claims the benefit of U.S. Provisional Application No.

62/694,771 , filed July 6, 2018, the content of which is expressly incorporated herein by reference in its entirety.

TECHNICAL FIELD

[0002] This disclosure generally relates to data privacy and the management of data privacy on devices, such as techniques for enabling shared portable and/or embedded systems to comply with data privacy regulations.

BACKGROUND

[0003] Data privacy relates to the access, control, and use of private user data, which can include any of a variety of data that is generated by or related to users. For example, private user data can include data that users actively provide, such as name, address, images, search queries the user enters into a search engine, and/or other information. Private user data can also include data that is passively generated in association with users, such as a log of geographic locations a user has visited that is generated by a user’s mobile device (e.g., smartphone, wearable device), audio that is passively captured by a user’s smart speaker device, and/or other passive information. Both actively and passively generated user data poses privacy concerns around what data is collected, how it is used, who it is shared with, and whether the user maintains control over the data, including the deletion of the data. [0004] Some government agencies have taken steps to create rules to protect user privacy. For example, the European Union’s (EU) General Data Protection Regulation (GDPR) replaces the Data Protection Directive 95/46/EC and was designed to harmonize data privacy laws across Europe, to protect and empower all EU citizens’ data privacy and to reshape the way organizations that operate with the EU approach data privacy. The aim of the GDPR is to protect all EU citizens from privacy and data breaches in an increasingly data-driven world.

[0005] GDPR defines a number of“data subject rights.” One such right is“right to be forgotten,” also known as Data Erasure. The right to be forgotten entitles the data subject to have the data controller erase his/her personal data, cease further

dissemination of the data, and potentially have third parties halt processing of the data. GDPR also introduces a requirement for data portability. Data subjects have a right to receive the personal data that they have previously provided back in a commonly used and machine-readable format.

[0006] GDPR also requires“privacy by design,” which calls for the inclusion of data protection from the onset of the designing of systems, rather than an addition. More specifically, controllers are required to implement appropriate technical and

organizational measures in an effective way in order to meet the requirements of this Regulation and protect the rights of data subjects. Controllers are also required to hold and process only the data that is absolutely necessary for the completion of its duties (data minimization), as well as limit access to personal data to those needing to act out the processing. SUMMARY

[0007] In general, this document describes systems and techniques for better protecting and managing data privacy, which can permit users to maintain better control over their private data and can also assist device manufacturers in complying with data privacy regulations. Data privacy and new regulations pose a variety of challenges to both individuals and device/service providers, including how to comply with government regulations on data privacy. The disclosed technology can assist both groups in better managing data privacy and complying with data privacy regulations, including on devices and in systems that are shared across multiple different users.

[0008] In one implementation, a system for managing private user data includes a processing system, a data storage system configured to store instructions for the processing system, and a shadow file system configured to store private user data that is generated or used by the processing system, wherein the shadow file system is positioned between the processing system and the data storage system. The system can further include a non-transitory computer-readable medium coupled to the processing system and having instructions stored thereon that, when executed by the processing system, cause the shadow file system to perform operations including:

storing the private user data in the shadow file system; receiving instructions to delete or make available for download the private user data stored in the shadow file system; and performing operations to delete or make available for download all of the private user data stored in the shadow file system.

[0009] Such a system can optionally include one or more of the following features. The shadow file system can be configured to store a plurality of collections of private user data for a plurality of users, wherein each collection of private user data comprises all of the data associated with corresponding ones of the plurality of users. The operations can further include receiving an identifier that identifies a user; receiving a request to perform a data interaction to add, read, write, modify, or delete a collection of data; identifying the request as a request to perform operations upon data associated with the identified user; identifying a collection of data associated with the identified user; and performing the requested interaction upon the identified collection of data in the shadow file system. Performing the requested interaction upon the identified collection of data can further include performing the requested interaction upon only the identified collection of data. The data interaction can be a request to delete the collection of data associated with the identified user. Performing the requested interaction can include deleting the collection of data associated with the identified user such that all of the identified user's data stored by the system is deleted from the system. The operations can further include rendering the deleted collection of data substantially unrecoverable. The data interaction can be a request for a copy of the collection of data associated with the identified user. Performing the requested interaction can include providing another collection of data that comprises copies of the data within the collection of data associated with the identified user, such that all of the identified user's data stored by the system is exported from the system.

[0010] The systems and techniques described here may provide one or more of the following advantages. For example, the disclosed technology can provide enhanced and improved data privacy management, including for devices and systems that are used and accessed by multiple different users. This can aid users in more effectively controlling and managing their private user data, and can also assist companies in complying with data privacy regulations. In another example, the disclosed technology can provide mechanisms for companies to comply with regional data privacy regulations without having to revamp or reengineer their systems. Without the disclosed

technology, companies would need to reconfigure the way they store data on a device, which may be a non-trivial task. With the disclosed technology, an additional layer can be added between the operating system and the file system to create a data privacy layer that can provide automatic compliance with government data privacy regulations without having to reconfigure or reengineer the system. In another example, the disclosed technology can enable systems to keep multiple users’ data separated and private, even though their data is being stored on the same file system and the same devices.

[0011 ] The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims.

BRIEF DESCRIPTION OF DRAWINGS

[0012] FIG. 1 is a schematic diagram that shows an example of a system for providing data privacy.

[0013] FIG. 2 is a block diagram that shows additional details of a system for providing data privacy.

[0014] FIG. 3 is schematic diagram of users and data enabled devices.

[0015] FIG. 4 is a schematic diagram of an example data enabled device.

[0016] FIG. 5 is a flow diagram of a process for providing data privacy. [0017] FIG. 6 is a block diagram of computing devices.

DESCRIPTION OF THE EMBODIMENTS

[0018] This document describes systems and techniques for enabling shared portable and embedded systems to comply with data privacy regulations, such as the European Union’s (EU) General Data Protection Regulation (GDPR). GDPR presents a number of challenges for vendors who traditionally handle private user data; vendors such as online websites that use user accounts, database providers who store user data, application developers and providers who handle data that could be considered as being private. Such systems and vendors are challenged by the requirements of GDPR, but the solutions to such challenges can be built upon capabilities that generally already exist in their underlying systems. For example, it is more of a logistical challenge than a technical one to add a function to a website user account to export or erase all the data pertaining to a particular user.

[0019] There is, however, an entire spectrum of other systems, vendors, and users that provide and use technologies that handle private user data, but were not necessarily“designed for privacy.” For example, smartphones generally store and use private data, but their primary use case is for a single user, and as such, the phones may not have effective ways to ensure data privacy compliance when they are used outside of the assumed use case (e.g.,“loaner” phones). In another example, automotive infotainment systems can store and use personal data (e.g., phone contacts, navigation addresses, radio presets, comfort settings). Such systems are generally designed for use by one or a small number of people that does not change often (e.g., a family who owns the car). However, complications arise when the vehicle is used in other scenarios, such as a shared commercial truck or a rental car, where the users change on a regular basis and personal data (e.g., phone contacts, navigation logs) may be stored for each. A person who returns a rental car generally would not want the next renter to have access to the copy of their phonebook that was

downloaded to the car’s hands-free system, or to their history of recent destinations that the onboard navigation system guided them to, or to a log of on-board vehicle diagnostic data that may reveal their driving habits.

[0020] Generally speaking, the systems and techniques described below provide ways for shared data devices to keep user data private, exportable, and removable (e.g., forgettable) by utilizing a shadow file system for private user data. In general, all the data that is stored for a particular user is stored in its own separate store (e.g., file, folder, partition, volume). When a user wants a copy of their data, the contents of the store can be exported. When a user wants their data to be forgotten, the store can simply be deleted or reformatted, and in some cases, anonymized (e.g., overwritten to thwart recovery of the deleted data, modified to remove user identifiers from data).

Such operations can take place locally, such as through a user interface provided by the device (e.g., a touchscreen of a car infotainment system), and/or the operations can be performed remotely (e.g., remote administration console of a car rental company in wireless communication with the rental vehicle, another ECU in the vehicle, etc.).

[0021 ] FIG. 1 is a schematic diagram that shows an example of a system 100 for providing data privacy. The system 100 includes a server 102, a collection of client devices 104, and a client device 110 in communication over a network 106 (e.g., the Internet, cellular data network). The server 102, the client devices 104, and the client device 110 can be configured to collect and/or store private user data. For example, the server 102 can be a database or web application server that makes use of user accounts. In another example, the client devices 104 and 110 can be computers (e.g., PCs), smart phones, tablet computers, embedded infotainment systems (e.g., car onboard navigation and communication systems),“smart” televisions, video game consoles, smart home controllers, or any other appropriate system that can store data that might be considered as being private for a particular user.

[0022] In the illustrated example, the client device 110 is shown in additional detail. The client device 110 includes an operating system 115 that is accessible by one or more applications 120 (e.g., apps, software programs). The applications 120 process data, including private user data, for storage in a file system 125. The client device 110 includes a shadow file system 130 for the storage of private user data. The shadow file system 130 sits on top of the file system 125 and is configured to determine whether a file will be stored in the file system 125 (non-user data) or the shadow file system 130 (private user data).

[0023] FIG. 2 is a block diagram that shows additional details of an example of a system 200 for providing data privacy. In some implementations, the system 200 can be all or part of the example shadow file system 130 of FIG. 1.

[0024] The system 200 includes a shadow file system coordinator 210. The coordinator 210 acts as a middleware layer between one or more software applications 220 and a file system 230. The file system 230 is a data storage system (e.g., hard drive, flash memory, RAM, ROM) that stores various kinds of data. The file system 230 stores data that is user-agnostic, such as an operating system 232 and application data 234. The file system 230 also stores sets of user-specific data 236a-236n. Each set of user-specific data 236a-236n represents data stored by the operating system 232 and/or applications 220 for a specific user or user account. For example, one of the applications 220 can be a contact database application, where the user-specific data 236a can store the contacts of User A, and the user-specific data 236b can store the contacts of User B.

[0025] The coordinator 210 is configured to receive a user identifier 240. The user identifier 240 is information that can uniquely identify a user among many such users.

In the illustrated example, the user identifier 240 uniquely identifies“User B” from, e.g., User A, and User C through User N. Based on the user identifier 240, the coordinator directs file system operations to a specific one of the sets of user-specific data 236a- 236n. In the illustrated example, since the user identifier 240 identifies User B, the coordinator directs file system operations to the user-specific data 236b, effectively isolating the user-specific data 236b from being accessed by the operating system 232 and the applications 220 while User B is active, and effectively prevents User B from accessing the user-specific data 236a and 236c-236n.

[0026] Each of the sets of user-specific data 236a-236n is effectively independent and separable from each of the other sets. For example, each of the sets of user- specific data 236a-236n can be stored as a separate volume or partition of the file system 230. In such an example, the user identifier 240 can be used to help determine which volume or partition to mount for use by the operating system 232 and the applications 220 while a particular identified user is using the system 200. In another example, the user identifier 240 can be used as part of a middleware process performed by the shadow file system coordinator 210, in which file system operations (e.g., from the operating system 232 and/or applications 220) are intercepted and redirected to a specific one of the sets of user-specific data 236a-236n. As such, user-agnostic and/or privacy-unaware data storage operations performed by the operating system 232 and/or the applications 220 may be in a data-isolated manner without requiring modification of the operating system 232 or application data 234, due to the operational modifications provided by the shadow file system coordinator 210.

[0027] The shadow file system coordinator 210 can be also configured to receive one or more user data requests 250 from a user 260 (e.g., User B). The user data requests 250 can be requests for a variety of operations, particularly those related to data privacy and compliance with various regulatory requirements. For example, under GDRP, the user 260 has a right to export his/her private data. The coordinator 210 can be configured to comply with this requirement by permitting the user 260 (e.g., User B) to identify himself/herself (e.g., by logging in and providing the user identifier 240) and submit a data export request as the data request 250. In response, the coordinator 210 can access the user-specific data 236b for User B and transmit or otherwise provide (e.g., as an archive file) the user-specific data 236b to the user 260. In another example, under GDRP, the user 260 has a right to be“forgotten”. The coordinator 210 can be configured to comply with this requirement by permitting the user 260 (e.g., User B) to identify himself/herself (e.g., by logging in to provide the user identifier 240) and submit a data deletion request as the data request 250. In response, the coordinator 210 can delete, overwrite, reformat, or otherwise remove the user-specific data 236b from the file system 230. [0028] The coordinator 210 can be also configured to prevent recovery or reconstruction of private data. For example, the coordinator 210 can be configured to encrypt each of the sets of user-specific data 236a-236n separately based on the user identifier 240 or some other data that can be used as an encryption key, without which the user-specific data 236a-236n would be useless even if copied, discovered, or stolen. In another example, the coordinator 210 can be configured to obfuscate the locations where user-specific data was stored. For example, the coordinator 210 can delete the user-specific data 236b in response to the user data request 250. However, in some file systems, simple deletion of stored data merely removes directory

information to mark the space as being available for future storage operations but without actually removing the previously stored data itself, leaving the deleted data in a state that is potentially recoverable by special software and/or hardware forensic tools.

In some cases, even overwritten data may be recovered, as long as the physical location has not been overwritten too many times. The coordinator 210 can be configured to thwart discovery and recovery of private data by, for example, overwriting the storage locations within the file system 230 that were used to store deleted data with one or multiple passes of predetermined or randomized data.

[0029] The user data requests 250 can come from the user 260 in several different ways. In some implementations, the requests 250 can be performed locally. For example, a car infotainment system or a smart phone can be configured to provide a user interface (e.g., touch screen, mechanical buttons, voice commands) that provide the user 260 with ways to request, delete, or perform other appropriate privacy actions on the sets of user-specific data to which the user 260 has the appropriate rights. In some implementations, the requests 250 can be made automatically. For example, coordinator 210 and the file system 230 can be part of a rental car. When the rental car is checked back in by the user 260, the coordinator 210 may be configured to detect the check-in process and automatically export and/or delete the user-specific data 326a- 236n belonging to the user 260. In some implementations, the requests 250 can be made remotely. In another example with the coordinator 210 and the file system 230 being part of a rental car, the user 260 can choose an action to be performed with his/her private data (e.g., export, delete, opt-out of storing user data - permit temporary storage during runtime but automatic deletion when car shuts down) during the rental car contract signing and before using the rental car, which can be recorded and used to automatically perform the user’s requested actions when the user returns the rental car. In another example, the user 260 can be an employee of a company, and the

coordinator 210 can be part of a company-owned smartphone. The coordinator 210 can be configured to receive the data requests 250 wirelessly (e.g., over the Internet or other network) from a remote administration console. An operator of the administration console can issue a command to have the user’s 260 private data wiped from all company-owned smartphones. The coordinator 210 can receive such a command and respond accordingly.

[0030] FIG. 3 is schematic diagram of users and data enabled devices. A collection of users 301 a-301d can use a collection of client devices, such as a client device 310 (e.g., a server computer system), a client device 320 (e.g., a vehicle infotainment or guidance system), and a client device 330 (e.g., a personal computing device such as a smartphone, PC, or tablet). Any of the client devices 310-330 may be used by one or more of the users 301a-301 d, thus allowing or even requiring the client devices to store or otherwise interact with data that is specific (and potentially private and/or sensitive) to one or more of the users 301 a-301 d. Each of the client devices 310-330 can include an appropriate implementation of example shadow file coordinator system 210 of FIG. 2 to provide data privacy functions for the users 301 a-301 d.

[0031 ] FIG. 4 is a conceptual diagram of an example system 100 providing robust end-to-end communication security that is able to establish and maintain data privacy between example electronic control units (ECUs) 406a-n that are part of a client device 408, which in this example is a vehicle. The example system 400 is an example implementation in a specific Internet of Things (loT) context (vehicle) and can be implemented on a variety of other loT devices and systems, such as security systems, smart home systems, and others.

[0032] In this example, the ECUs 406a-406n are depicted as being communicatively connected to each other via a communication network 402, which in the depicted example is a CAN bus within the vehicle 408. The system 400 can be implemented with other communication networks, as well as with other loT devices. Messages between the ECUs 406a-n are broadcast over the CAN bus 402 with message identifiers. Each of the ECUs 406a-n can be configured to transmit and listen for particular message identifiers broadcast over the CAN bus 402. In other network environments, messages may be transmitted additionally and/or alternatively with sender and recipient information that directs the delivery of messages to the correct ECUs. Any of the ECUs 406a-n can read or store user-specific data transmitted in the contents of the messages. Furthermore, without any sort of data privacy enforcement, any one of the ECUs 406a-n may contain information of which a user would want to have control. For example, an ECU that is configured to handle hands-free telephone calls may store a user’s call history or a copy of his/her contact database, while an ECU that is configured for vehicle control may store a history of the user’s accelerations, speeds, braking, and other behavior while operating the vehicle. Thus, without end-to- end data privacy, the messages over the CAN bus 402 are susceptible privacy threats, such as unwanted copying and retrieval.

[0033] Using the end-to-end data privacy layers, each of the ECUs 406a-n is programmed to operate based on user data provided and/or maintained by a central privacy provider. For example, the ECU 406a can be an ECU that is in communication with a user interface (e.g., infotainment system, RFID receiver) that can identify a specific user (e.g., User B) from among a number of such users (e.g., User A and User B). The ECU 406a includes a user interface 460 that interfaces with a shadow file coordinator system 470a (e.g., the example coordinator 210 of FIG. 2). The shadow file coordinator 470a includes one or more sets of user-specific data 462a-462b for one or more drivers. For example, the ECU 406a can be a controller for an infotainment system on the vehicle 408, which can include a user interface 460 through which the user can direct and/or provide instructions to the shadow file coordinator 470a, such as providing instructions to export personal user data, delete personal user data, opt-out of persistently storing personal user data (e.g., temporarily store personal user data so that applications can operate appropriately, but then delete the data when the vehicle 408 shuts down), and/or other instructions. [0034] Each of the ECUs 406a-n can have a corresponding shadow file coordinator 470a-n, which can also store personal user data that is associated with specific users (e.g.,“User A” personal data,“User B” personal data). However, not all of the ECUs 406a-n may have a corresponding user interface through which a user can provide instructions to the shadow file system. Accordingly, the shadow file coordinators 470a-n can echo and provide user directions/instructions to each other regarding the

management of personal user data. For example, user instructions to delete private user data received by the shadow file coordinator 470a via the user interface 460 can be transmitted over the CAN bus 402 to the other shadow file coordinators 470b-n, and can cause each of the shadow file coordinators 470a-n to delete their respective private user data.

[0035] Upon identification of the current driver, the shadow file coordinators 470a-n can select user-specific data for the identified driver, e.g., user-specific data 462b for User B. Again, since not all ECUs 406a-n have a user interface through which a user can identify himself/herself, such user identification receive via one of the ECUs 406a-n can be transmitted to the other ECUs (e.g., user identification to the shadow file coordinator 470a via the interface 460 can be transmitted to the other shadow file coordinators 470b-n). The shadow file coordinator 470a can then provide the user identification and user-specific data 462b, or appropriate sub-portions thereof, over the CAN bus 402 to the other ECUs 406a-n. For example, a climate control system may receive only the identified user’s temperature preferences, while a radio may receive only the identified user’s station presets. [0036] When the driver is done with the vehicle 408 (e.g., end of rental, selling the car, end of borrowing the car), the ECU 406a and the shadow file coordinator system 470a can request the settings of the other ECUs 406b-406n, and store the settings as the user-specific data 462b. The shadow file coordinator system 470a can also request that the other ECUs 406b-406n wipe their respective data storage systems 470b-n, thus removing user-specific data from their memories. This data can be restored by the ECU 406a and the coordinator 470a the next time the same driver returns to the vehicle, or it can be replaced by the user-specific data of another driver when that driver is identified. The driver can also interact with the ECU 406a to request a copy and/or a complete deletion of their user-specific data, such as through the user interface 460.

[0037] The example system 400 is also depicted as including a gateway 404 between the CAN bus 402 and one or more remote computer systems 412

(management computer system), which can communicate remotely with the ECUs 406a-n for any of a variety of purposes. For example, the remote computer systems 412 can manage and monitor the privacy status of the ECUs 406a-n in the vehicle 408, as well as the privacy status of ECUs in other vehicles and loT devices. For example, the car 408 can be a rental vehicle, and when the driver (e.g., User B) checks the car back in at a rental return kiosk, the kiosk can trigger a process in which one or more data requests are sent to the ECUs 406a-n and their shadow file coordinators 470a-n via the gateway 404 to request an export and/or deletion of the user-specific data 462b in order to wipe the car 408 of the previous driver’s information and make the car 408 ready for the next driver while rendering the data 462b inaccessible to the next driver. [0038] FIG. 5 is a flow diagram of a process 500 for providing data privacy. In some implementations, the process 500 can be performed by all or parts of the example systems 100, 200, and 400 of FIGs. 1 , 2, and 4.

[0039] At 510, an identifier that identifies a user is received. For example, the shadow file coordinator system 210 can receive user login information as the user identifier 240.

[0040] At 520, a request to perform a data interaction to add, read, write, modify, or delete a collection of data is received. For example, the coordinator 210 can receive the data request 250.

[0041 ] At 530, a determination is made. If the request is identified as a request to perform operations upon data not associated with a specific user, then at 540 the request is performed on the non-user-specific data. If the request is identified as a request to perform operations upon data that is associated with the specific user, then at 550 a collection of data associated with the identified user is identified. For example, the set of user-specific data 236b is identified based on the user identifier 240 of the User B.

[0042] At 560, the requested interaction is performed upon the identified collection of data. For example, a“delete data” request from User B can cause the coordinator 210 to delete the user-specific data 236b, but not the user-specific data 236a or 236c-236n.

[0043] In some implementations, performing the requested interaction upon the identified collection of data can also include performing the requested interaction upon only the identified collection of data. For example, the coordinator 210 can effectively isolate the data of other users from operations being performed by the identified user (e.g., User B cannot export User A’s user-specific data 236a).

[0044] The data interaction can be a request to delete the collection of data associated with the identified user and/or to copy the collection of data associated with the identified user. When performing a delete operation, which can be performed alone or in combination with a copy operation, the requested interaction can include deleting the collection of data associated with the identified user such that all of the identified user’s data stored by the system is deleted from the system. In some implementations, the process 500 can also include rendering the deleted collection of data substantially unrecoverable (e.g., overwriting the storage locations with new information that is not private). When performing a copy operation, which can be performed alone or in combination with a delete operation, the requested interaction can include providing another collection of data that comprises copies of the data within the collection of data associated with the identified user, such that all of the identified user’s data stored by the system is exported from the system.

[0045] FIG. 6 is a block diagram of computing devices 600, 650 that may be used to implement the systems and methods described in this document, either as a client or as a server or plurality of servers. Computing device 600 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers.

Computing device 650 is intended to represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smartphones, and other similar computing devices. The components shown here, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the inventions described and/or claimed in this document.

[0046] Computing device 600 includes a processor 602, memory 604, a storage device 606, a high-speed interface 608 connecting to memory 604 and high-speed expansion ports 610, and a low speed interface 612 connecting to low speed bus 614 and storage device 606. Each of the components 602, 604, 606, 608, 610, and 612, are interconnected using various busses, and may be mounted on a common

motherboard or in other manners as appropriate. The processor 602 can process instructions for execution within the computing device 600, including instructions stored in the memory 604 or on the storage device 606 to display graphical information for a GUI on an external input/output device, such as display 616 coupled to high-speed interface 608. In other implementations, multiple processors and/or multiple buses may be used, as appropriate, along with multiple memories and types of memory. Also, multiple computing devices 600 may be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a multi- processor system).

[0047] The memory 604 stores information within the computing device 600. In one implementation, the memory 604 is a computer-readable medium. In one

implementation, the memory 604 is a volatile memory unit or units. In another implementation, the memory 604 is a non-volatile memory unit or units.

[0048] The storage device 606 is capable of providing mass storage for the computing device 600. In one implementation, the storage device 606 is a

computer-readable medium. In various different implementations, the storage device 606 may be a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid state memory device, or an array of devices, including devices in a storage area network or other configurations. In one implementation, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier can be a computer- or machine-readable medium, such as the memory 604, the storage device 606, or memory on processor 602.

[0049] The high-speed controller 608 manages bandwidth-intensive operations for the computing device 600, while the low speed controller 612 manages lower bandwidth-intensive operations. Such allocation of duties is exemplary only. In one implementation, the high-speed controller 608 is coupled to memory 604, display 616 (e.g., through a graphics processor or accelerator), and to high-speed expansion ports 610, which may accept various expansion cards (not shown). In the implementation, low-speed controller 612 is coupled to storage device 606 and low-speed expansion port 614. The low-speed expansion port, which may include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet) may be coupled to one or more input/output devices, such as a keyboard, a pointing device, a scanner, or a networking device such as a switch or router, e.g., through a network adapter.

[0050] The computing device 600 may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a standard server 620, or multiple times in a group of such servers. It may also be implemented as part of a rack server system 624. In addition, it may be implemented in a personal computer such as a laptop computer 622. Alternatively, components from computing device 600 may be combined with other components in a mobile device (not shown), such as device 650. Each of such devices may contain one or more of computing device 600, 650, and an entire system may be made up of multiple computing devices 600, 650 communicating with each other.

[0051 ] Computing device 650 includes a processor 652, memory 664, an

input/output device such as a display 654, a communication interface 666, and a transceiver 668, among other components. The device 650 may also be provided with a storage device, such as a microdrive or other device, to provide additional storage. Each of the components 650, 652, 664, 654, 666, and 668, are interconnected using various buses, and several of the components may be mounted on a common

motherboard or in other manners as appropriate.

[0052] The processor 652 can process instructions for execution within the

computing device 650, including instructions stored in the memory 664. The processor may also include separate analog and digital processors. The processor may provide, for example, for coordination of the other components of the device 650, such as control of user interfaces, applications run by device 650, and wireless communication by device 650.

[0053] Processor 652 may communicate with a user through control interface 658 and display interface 656 coupled to a display 654. The display 654 may be, for example, a TFT LCD display or an OLED display, or other appropriate display

technology. The display interface 656 may comprise appropriate circuitry for driving the display 654 to present graphical and other information to a user. The control interface 658 may receive commands from a user and convert them for submission to the processor 652. In addition, an external interface 662 may be provide in communication with processor 652, so as to enable near area communication of device 650 with other devices. External interface 662 may provide, for example, for wired communication (e.g., via a docking procedure) or for wireless communication (e.g., via Bluetooth or other such technologies).

[0054] The memory 664 stores information within the computing device 650. In one implementation, the memory 664 is a computer-readable medium. In one

implementation, the memory 664 is a volatile memory unit or units. In another implementation, the memory 664 is a non-volatile memory unit or units. Expansion memory 674 may also be provided and connected to device 650 through expansion interface 672, which may include, for example, a SIMM card interface. Such expansion memory 674 may provide extra storage space for device 650, or may also store applications or other information for device 650. Specifically, expansion memory 674 may include instructions to carry out or supplement the processes described above, and may include secure information also. Thus, for example, expansion memory 674 may be provide as a security module for device 650, and may be programmed with instructions that permit secure use of device 650. In addition, secure applications may be provided via the SIMM cards, along with additional information, such as placing identifying information on the SIMM card in a non-hackable manner.

[0055] The memory may include for example, flash memory and/or MRAM memory, as discussed below. In one implementation, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier can be a computer- or machine-readable medium, such as the memory 664, expansion memory 674, or memory on processor 652.

[0056] Device 650 may communicate wirelessly through communication interface 666, which may include digital signal processing circuitry where necessary.

Communication interface 666 may provide for communications under various modes or protocols, such as GSM voice calls, Voice Over LTE (VOLTE) calls, SMS, EMS, or MMS messaging, CDMA, TDMA, PDC, WCDMA, CDMA2000, GPRS, WiMAX, LTE, among others. Such communication may occur, for example, through radio-frequency transceiver 668. In addition, short-range communication may occur, such as using a Bluetooth, WiFi, or other such transceiver (not shown). In addition, GPS receiver module 670 may provide additional wireless data to device 650, which may be used as appropriate by applications running on device 650.

[0057] Device 650 may also communication audibly using audio codec 660, which may receive spoken information from a user and convert it to usable digital information. Audio codex 660 may likewise generate audible sound for a user, such as through a speaker, e.g., in a handset of device 650. Such sound may include sound from voice telephone calls, may include recorded sound (e.g., voice messages, music files, etc.) and may also include sound generated by applications operating on device 650.

[0058] The computing device 650 may be implemented in a number of different forms, as shown in the figure. For example, it may be implemented as a cellular telephone 680. It may also be implemented as part of a smartphone 682, personal digital assistant, or other similar mobile device.

[0059] It is to be understood that the disclosed embodiments are not necessarily limited in their application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or the examples. The disclosed embodiments are capable of variations, or of being practiced or carried out in various ways.

[0060] The disclosed embodiments may be implemented in a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present disclosure.

[0061 ] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an

electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves,

electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0062] Computer readable program instructions described herein can be

downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each

computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

[0063] Computer readable program instructions for carrying out operations of the present disclosure may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the“C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user’s computer, partly on the user’s computer, as a stand-alone software package, partly on the user’s computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user’s computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example,

programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

[0064] Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions. These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

[0065] The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

[0066] The flowcharts and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowcharts or block diagrams may represent a software program, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in

succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0067] The descriptions of the various embodiments of the present disclosure have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

[0068] It is expected that during the life of a patent maturing from this application many relevant virtualization platforms, virtualization platform environments, trusted cloud platform resources, cloud-based assets, protocols, communication networks, security tokens and authentication credentials will be developed and the scope of the these terms is intended to include all such new technologies a priori.

[0069] It is appreciated that certain features of the disclosure, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the disclosure, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment of the disclosure. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements.

[0070] Although the disclosure has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims.