Trusted status transfer between associated devices

The embodiments set forth systems and techniques to authenticate a user device for device services, such as by transferring or extending a trusted device status from a separate and trusted associated user device, which can be paired with the user device. This can be done automatically without requiring the user to sign in at or on behalf of the user device, and the automated process can include verifying a trusted status for the associated user device, receiving data items from both devices, evaluating the data items, and facilitating an authentication of the user device when the evaluating returns a favorable result. Data items can include provisioned machine identifiers, temporally limited one-time user passwords, and a provisioned password reset key. Authentication or trusted device status transfer can be achieved by way of an authentication token that is given to the user device.

FIELD

The described embodiments relate generally to managing services for electronic devices. More particularly, the described embodiments relate to authenticating electronic devices for providing device services.

BACKGROUND

Users are often required to sign in or otherwise register when they desire to access various services by way of their electronic devices. Such services can include, for example, cloud storage, downloadable media or content, subscription programming, e-mail, and the like. Because it can be important to identify or confirm an actual user when providing these and other device based services, a sign in, registration, or other authentication of a user attempting to access such services can be required or preferable. Accordingly, a particular user device that is owned or often used by a given user can be authenticated for a device service at some initial point in time so that the user can access that device service thereafter at that user device.

When a user attempts to access that device service from a different or additional user device, it may be necessary to sign in again or otherwise confirm the user at the added user device, which may then provide an authentication for that device service at that added user device. This might be understandable where the user is borrowing or otherwise temporarily using a different user device. Where the user is using their own new or additional user device, however, it can be inconvenient or annoying to have to sign in or manually authenticate again from or on behalf of this separate user device to access the same device services for which the user has already registered and been using. This can be particularly true where the added user device is being used simultaneously and/or in conjunction with an existing user device that has already been authenticated for the device services, such as in the case of paired user devices.

While current user device authentication approaches have worked well in the past, improvements in providing this function are usually welcome. Accordingly, there is a need for systems and techniques that authenticate added user devices in a more convenient manner.

SUMMARY

Representative embodiments set forth herein disclose various systems and techniques for authenticating added user devices for device services. In particular, these embodiments set forth various systems and techniques for authenticating an added user device by transferring a trusted device status from a separate trusted user device to the added user device in a way such that the user is not required to sign in and authenticate manually on the added user device. This can be accomplished by (1) verifying an existing authentication for the separate trusted user device, (2) evaluating data items received from the trusted user device with data items received from the added user device, and (3) facilitating an authentication of the added user device when the evaluation is favorable. According to some embodiments, a token is provided to the trusted user device when the evaluation is favorable, whereby use of the token by the added user device extends a trusted status from the trusted user device to the added user device when this token is provided to the added user device. Received data items can include one-time passwords and machine identifiers for both of the trusted user device and the added user device, as well as a unique password reset key for the trusted user device. Each one-time password may be valid only for a set amount of time after it is formed, and the evaluation can include verifying that one of the passwords was formed while the other one was still valid.

This Summary is provided merely for purposes of summarizing some exemplary embodiments so as to provide a basic understanding of some aspects of the subject matter described herein. Accordingly, it will be appreciated that the above-described features are merely examples and should not be construed to narrow the scope or spirit of the subject matter described herein in any way. Other features, aspects, and advantages of the subject matter described will become apparent from the following Detailed Description, Figures, and Claims.

DETAILED DESCRIPTION

When a user attempts to access an existing subscribed device service from an added user device, it may be necessary to sign in again or otherwise confirm the user at the added user device. It can be inconvenient or annoying, however, to have to sign in or manually authenticate again from an added user device to access the same device services for which the user has already registered and been using. This can be particularly true where the added user device is being used simultaneously and/or in conjunction with an existing user device that has already been authenticated for the device service, such as in the case of paired user devices.

Accordingly, the embodiments set forth herein provide various systems and techniques for authenticating user devices for device services. In particular, these embodiments set forth various systems and techniques for authenticating an added user device by transferring a trusted device status from a separate trusted user device to the added user device in a way such that the user is not required to sign in and authenticate manually on the added user device. This can be accomplished by (1) verifying an existing authentication for the separate trusted user device, (2) evaluating data items received from the trusted user device with data items received from the added user device, and (3) facilitating an authentication of the added user device when the evaluation is favorable. According to some embodiments, a token is provided to the trusted user device when the evaluation is favorable, whereby use of the token by the added user device extends a trusted status from the trusted user device to the added user device when this token is provided to the added user device. Received data items can include one-time passwords and machine identifiers for both of the trusted user device and the added user device, as well as a unique password reset key for the trusted user device. Each one-time password may be valid only for a set amount of time after it is formed, and the evaluation can include verifying that one of the passwords was formed while the other one was still valid.

Accordingly, the foregoing approaches provide systems and techniques for authenticating added user devices for device services. A more detailed discussion of these systems and techniques is set forth below and described in conjunction withFIGS. 1-8, which illustrate detailed diagrams of systems, components, and methods that can be used to implement these systems and techniques.

Turning first toFIG. 1, various exemplary components of a system adapted to authenticate an added user device for device services are illustrated in block diagram format. Specifically,FIG. 1illustrates a high-level overview of the system100, which can include a user device110, an associated user device120, and a remote device service130with which the initial user device110and added user device120can communicate, such as via a network105. The device service130can include and/or have access to a separate system of records (SOR)140, which can contain information and identifiers used to authenticate and verify various user devices for the device service130.

The associated user device120can represent an electronic device that is already authenticated for the device service130, and thus can be considered a trusted device. Associated user device120can be, for example, a mobile device (e.g., an iPhone®) or a tablet device (e.g., an iPad®). Associated user device120can also represent any other electronic device for which a user accesses certain device services such as, for example, a laptop computer, or a desktop computer, among other possible electronic user devices. Network105can include one or more of the Internet, an intranet, a PAN (Personal Area. Network), a LAN (Local Area Network), a WAN (Wide Area Network), a MAN (Metropolitan Area Network), a wireless communication network, and the like. Device service130can include, for example, an IDMS (Integrated. Database Management System) server that is adapted to provide or facilitate the provision of one or more services to user devices (for example, iCloud™ by Apple®).

The user device110can represent an electronic device for which authentication is desired for the device service130. In various embodiments, user device110can be in communication with and be associated with the associated user device120. This can take the form of a pairing arrangement or other suitable device to device association. Accordingly, user device110can be, for example, a standalone user device or an accessory device for associated user device120. In various embodiments, user device110and associated user device120can be peer user devices to each other. User device110can be, for example, a smart watch, a digital media playback device, or a digital media extender. User device110can also be any other electronic device suitable for associating with associated user device120and receiving device services from device service130. Since associated user device120is already authenticated for the device service130, and use of this existing authenticated status is to be leveraged to authenticate user device110, the user device110can be considered an added user device for purposes of the existing authenticated status of associated user device120.

According to the illustration ofFIG. 1, the user device110can include a processor112, a memory114, a device services manager116, and a data component118having data for the user device110. The processor112, in conjunction with the memory114, can be configured to execute the device services manager116, among other components and applications (not shown) on the user device110, such as to carry out various functions, techniques, or portions thereof as set forth herein. Similarly, the associated user device120can include a processor122, a memory124, a device services manager126, and a data component128having data for the associated user device120. The processor122, in conjunction with the memory124, can be configured to execute the device services manager126, among other components and applications (not shown) on the associated user device120, such as to carry out various functions, techniques, or portions thereof as set forth herein. A separate device services manager136or component can also be located remotely at the device service130or elsewhere on the server side, as shown inFIG. 1, which separate server side device services manager136can perform various functions, techniques, or portions thereof as set forth herein.

Continuing withFIG. 2A, an initial state of exemplary components that can be used to transfer a trusted device status from one user device to another user device are provided in block diagram format. As shown inFIG. 2A, arrangement200depicts a user device110, an associated user device120, a device service130, and a SUR.140, such as those which are set forth and described above withFIG. 1. Again, user device110and associated user device120can be in communication with and associated with each other, such as by way of a paired arrangement or other device association. In various embodiments, user device110and associated user device120can be owned or otherwise operated by the same specific user. Both of user device110and associated user device120can be adapted for communication with device service130, such as to sign in, become authenticated, and/or access device services provided by device service130.

User device110and associated user device120can each have data components118,128containing various data items that are accessible for their respective device services managers. For user device110, data component118can include a unique MID (machine identifier)250, and a unique OTP (one-time password)252. A unique PRK (password reset key) for user device110is not provided at this initial state inFIG. 2A. For associated user device120, data component128can include a unique MID260, a unique OTP262, and a unique PRK264. Each of MID250, OTP252, MID260, OTP262, and/or PRK264can be provisioned to and stored at its respective device. Such provisioning can be done at a previous time by the device service130or a similar service associated with device service130. This can be done at, for example, the first time that the user device110and/or the associated user device120ever communicates with the device service130, or when the associated user device120is initially authenticated at the device service130. Such provisioning or reprovisioning of one or more of these items can also be done at later times, if desired, such as on a recurring basis. Accordingly, MID250and MID260can both be provisioned identifiers rather than hardware based identifiers. In some embodiments, MID250and MID260can remain constant for their respective devices, such as where a given MID is provisioned at an install of an operating system on the device. In other embodiments, MID250and MID260can be reprovisioned or changed regularly, as may be desired.

OTP252and OTP262can both be one-time passwords that change after each use thereof and/or at periodic time intervals. As such, OTP252and OTP262represent dynamic items that do not remain constant, but rather are formed anew as different values on a regular basis. Formation of a new OTP can take place any time the OTP is actually used, and can also happen on an automated recurring basis, such as every minute or every 30 seconds, for example. Accordingly, a given OTP may be considered valid only when it has not yet been used and/or for a set period of time after it has been created or formed. Upon a first use and/or an expiration of the set time period, a given OTP may then be considered expired or invalid. In various embodiments, a given OTP can be generated or formed on the device itself. For example, each OTP262can be generated at the associated user device120. This can take place at the device every time a new OTP262is needed. In some alternative embodiments, an OTP can be formed and provisioned at another location, such as at the device service130or another server. This can occur as a reprovisioning on a regular basis and/or when a given OTP is used. In some embodiments, a corresponding MID may also be reprovisioned and sent to the respective device at or about the same time. In some embodiments, a given MID can instead remain constant and can be used to form and provision a new OTP corresponding to that constant MID. An OTP can also be referred to as a temporary credential set or second credential set. In various embodiments, an OTP can be used to change a primary password or a first credential set without requiring the presence of the primary password or first credential set. Such a change may involve the presence of the relevant PRK.

PRK264can be provisioned to the associated user device120by the device service130or a similar associated device service at a previous time, such as when a constant or an initial MID260is provisioned. PRK264is not an actual password, but can be an equivalent in some regards. PRK264can be a token identifier in some embodiments. PRK264can be used to reset the specific password of the user on the associated user device120, which can be done according to various rules or management settings. In such instances, a given PRK can be used as an identifier for its respective device, such as during a user password reset or recovery process. A PRK can also be referred to as an access recovery parameter.

Various records210,220can exist on SOR140or a similar server side component for use by the device service130. For example, a first record210can correspond to the user device110, and can include one or more data items relevant to user device110, such as, for example, the MID250and the OTP252. A second record220can correspond to the associated user device120, and can include one or more data items relevant to the associated user device120, such as, for example, the MID260, the OTP262, and/or the PRK264. These values or data items can be stored at SOR140at the time that they are provisioned to their respective user devices, for example. Additional records can exist on SOR140for other user devices, as will be readily appreciated. A device services manager136or other similar component or module at the device service130can be adapted to utilize various data items to determine or evaluate whether a currently provided. OTP is reasonable or favorable. For example, the device service130can be adapted to use at least one or more known MAN and one or more known PRKs to determine whether a currently provided OTP makes sense. This determination can also include other data items, such as a current time and/or date, and also another currently provided OTP.

FIG. 2Billustrates in block diagram format a final state of the exemplary components ofFIG. 2Aafter transfer of a trusted device status from one user device to another user device according to various embodiments of the present disclosure. As shown for arrangement201inFIG. 2B, one difference between the initial state and the final state is that the user device110now has its own PRK254, and this PRK254is recorded at the SOR140to Record1210for the specific user device110, This PRK254is provided to the user device110upon a transfer of trusted device status from the associated user device120to the user device110, as set forth in greater detail below. By having its own PRK254, the user device110is then able to access device service130on its own and perform various other functions only available to a signed in or otherwise trusted device. In various embodiments, a provisioned MID250may also not be present at user device110until after a trusted device status is transferred or another provisioning takes place with respect to user device110.

In various embodiments, a comparison or evaluation can be made between a currently provided OTP252and a currently provided OTP262, which comparison or evaluation can also make use of MID250, MID260, and PRK264, for example. Given that which is known about these various data items and the nature of how DTPs are formed, it can at least be determined whether both of OTP252and OTP262are currently valid, and/or whether OTP252and OTP262were formed at or about the same time. In various embodiments, this can mean that one of OTP252and OTP262was formed while the other was already formed and was still valid. Such a determination, as part of an overall comparison or evaluation of MID250, MID260, PRK264, OTP252, and OTP262, can be sufficient in some embodiments to provide a favorable result or reasonable conclusion that the user device110is a device where a trusted status or authentication of the associated user device120can be transferred. In this context, a “transfer” of a trusted status can mean that the trusted status is extended to another device and is not lost or surrendered by the original device.

In some embodiments, verification of a specific PRK itself can also provide or tend toward a favorable result. In various embodiments, each PRK is a specific key or token that is not available to be sent from a device unless that device is locally unlocked and accessible, such as through the entry on the device of a user password, access code, a fingerprint, another biometric identifier, or any other suitable convention that locally unlocks a device. Accordingly, the existence of a currently provided unique and verifiable PRK is an indication on its own that the device for that PRK was locally unlocked at the time the PRK was sent. Such a locally unlocked state for a device can carry a presumption that the actual user or a trusted user was operating the device at the time that the PRK was sent.

An overall evaluation of all of the provided data items, which can include one or more determinations such as that set forth above, can be performed at the device service130or a device services manager thereof, for example. When the overall evaluation returns a favorable result, then the device service130can generate a token, such as an authentication token, and provide the token to the associated user device120, which can in turn provide the token to the user device110. This authentication token can then be used by the user device110to assert and enjoy the same trusted status and/or existing authentication as that which is done by the associated user device120, such as by being able to access the same user account with the same privileges on the device service130. Accordingly, the user device110can be considered an added user device with respect to the existing authentication of the associated user device. Importantly, this is accomplished without requiring the user to sign in and authenticate manually on the user device110.

In various embodiments, the authentication token can be a master token. This master token can be used to request and receive additional specialized tokens for use with different device services, for example. In each such instance, a returned specialized token can allow the user device110to appear or project as if it were actually the associated user device120when used as an authenticating item for the specific device service(s) that corresponds to the specialized token.

FIG. 3illustrates a basic flowchart of an exemplary method for transferring a trusted device status from one user device to another user device according to various embodiments of the present disclosure. Again, this can involve an associated user device having a trusted status that is being transferred (i.e., extended) to an added user device. Method300can be performed by, for example, a device services manager, which can be located on a server for providing device services or another suitable server side processing component. Method300begins at step302, where a trusted status for an associated user device can be verified. This trusted status can include an existing authentication for the associated user device, which device can be signed in to the server and therefore have a cryptographically verifiable state. This verifiable state can be, for example, an “authorized” state with respect to the device service at issue (e.g., iCloud).

At step304, data from both of the added user device and the associated user device can be received. The various data items received can include those set forth above in earlier details, for example. Data items for each device can be sent by the respective device, or, alternatively, the associated user device can collect data items from the added user device and forward those along with its own data items. Again, these data items can include: (1) an MID and OTP from the added user device, (2) an MID and OTP from the associated user device, and (3) a PRK from the associated user device, among other possible data items.

At step306, the received data can then be compared or evaluated. In particular, this comparison or evaluation can aim to determine whether the data items from the added user device reflect a suitable level of association or trust with respect to the data items from the associated user device. Such a determination can focus on, for example, whether the (i)TP received from the added user device contains or reflects certain properties. This can include indicators as to whether the added user device (i)TP is still valid and not expired, whether the added user device OTP was valid and not expired at the same time the associated user device OTP was valid and not expired (e.g., both OTPs were formed at or about the same time), and/or which data or items were used to form the added user device OTP (e.g., data specific to the associated user device), for example. In addition, the existence of a PRK can reflect that its device was unlocked at the time that its data items were sent, which can reflect that a proper person was using that device.

At decision step308, an inquiry can be made as to whether the evaluation has returned a favorable result. Again, such a favorable result can be a determination that the added user device is one that is closely associated with or trusted by the associated user device, such as where both devices are apparently being used by the same user, in the same vicinity and/or at the same time. If the result is favorable at decision step308, then the added user device can be authenticated at step310. If the result is not favorable at decision step308, however, then the added user device can be denied authentication at step312. The authentication can be the same as for the associated user device (e.g., signed in on same user account), such that the trusted status of the associated user device is thus transferred to the added user device at step310. In particular, the entire method can be accomplished in automate fashion, such as by a device services manager. Thus, the user for the added user device and the associated user device is not required to sign in and authenticate manually on the added user device.

FIG. 4illustrates a sequence diagram for authenticating an added user device by transferring a trusted device status using the added user device, an associated user device, and a server that provides device services according to various embodiments of the present disclosure. Sequence diagram400can involve various events, items, and stages that take place between an added user device410and an associated user device420on a device side, and a device service430on a server side. The various states for sequence diagram400can generally include an original authentication of the associated user device stage, which can happen much earlier in time than the rest of the states, a device pairing stage, a provisioning of the added user device stage, and a transferring of trusted status to the added user device stage.

At a first sequence event440, the associated user device420can sign in and authenticate on the device service430. Accordingly, a request441to sign in and authenticate can be sent from the associated user device to the device service430. Upon a proper registration and sign in, the device service430can authenticate the associated user device420and can provision a unique MID(1) and a unique PRK(1) for the associated user device420at sequence event445. A unique OTP(1) might also be sent in some embodiments. Accordingly, these items can be sent to the associated user device420at return assignment446. These items can then be stored on the now authenticated associated user device120for later use, as noted above.

At a later sequence event450, an added user device410can become active and seek a pairing, such as by sending a pairing request451to the associated user device420. At sequence event455, the associated user device can receive and act on the pairing request451by performing its own confirming pairing functions456back to added user device410.

At sequence event460, which can be a later time or contemporaneously with the pairing activities, the added user device410can make its own call for provisions, such as by request461to the device service430. At sequence event465, the device service430can response to request461by provisioning a unique MID(2) for the added user device410, which is then sent to the added user device410at return assignment466. This item can then be stored on the added user device410for later use. Again, a unique OTP(2) might also be sent in some embodiments.

In various embodiments, each OTP(1) and OTP(2) can be formed or generated at each respective device separately according to generating or updating rules or conventions, as may be desired. For example, associated user device420can generate its own OTP(1), and added user device410can generate its own OTP(2). As such, the OTP(1) and OTP(2) values may change upon such formation or generation, which can happen at regular intervals and/or upon use of a given OTP.

At sequence event470, which can be a later time or contemporaneously with the pairing and provisioning the added user device activities, the added user device410can send a request for a transfer of trusted status to the associated user device420, to which the added user device410is now paired. Again, such a device pairing can be in the form of an accessory device, or as a peer device. This request to the associated user device420from the added user device410can attach and send data items471therewith, which can include the MID(2) and an UTP(2) for the added user device410. At sequence event475, the associated user device420can receive the request and data items from added user device410and then forward or send its own request for a transfer of trusted status to the device service430. This request to the device service430from the associated user device420can attach and send data items476therewith, which can include the MID(1), an OTP(1), and the PRK(1) for the associated user device420, as well as the MID(2) and the OTP(2) for the added user device410.

At sequence event480, the device service430can receive the request for a transfer of trusted status and data items from the associated user device420, and can then compare or evaluate the data items to determine whether the trusted status transfer request (e.g., authenticated state extension) is to be granted. If the evaluation fails or is unfavorable, then the request is not granted. If the evaluation returns a favorable result though, then the device service can provide an authentication token and a PRK(2) for the added user device410at sequence event490. This authentication token and PRK(2) can be provided from the device service430to the associated user device420via assign reponse491. At a following sequence event495, the associated user device420can provide the authentication token and PRK(2) to the added user device410via assign response496. The added user device410can then store this authentication token and PRK(2) and use one or both of these items as needed to assert and enjoy the same extended trusted status enjoyed by the associated user device420. Again, the entirety of at least the transfer trusted status stage can be performed in automated fashion, such that the user is not required to sign in and authenticate manually on the added user device410. In various embodiments, a PRK(2) may not be sent to the added user device410, such that only an authentication token is provided.

FIG. 5illustrates a flowchart of an exemplary method for transferring a trusted device status performed by a device services manager at a server according to various embodiments of the present disclosure. Method500can correspond to that which is performed by device service430in the foregoing sequence diagram, for example. Method500begins at step502, where an associated user device can be provisioned. This can include, for example, providing a unique MID and a unique PRK to the associated user device. At step504, the associated user device can be authenticated, which can take place contemporaneously with the provisioning of step502in some instances. At step506, an added user device can be provisioned, which can take place at some time later than steps502and504in some instances. Step506can involve providing a unique MID to the added user device.

At step508, the device services manager at the server can receive data items from both of the added user device and the associated user device. As detailed above, this can include, for example, an MID for both devices, an OTP for both devices, and a PRK for the associated user device, among other possible data items. Again, each device can generate and provide its own OTP as needed. At step510, the device services manager at the server can verify a trusted status for the associated user device. In some embodiments, this can be done using the received data items. At step512, the data items received from the user device and the associated user device can be compared or evaluated, such as by way of that which is described in greater detail above at step306, for example.

At decision step514, an inquiry can be made as to whether the evaluation has returned a favorable result. If the result is favorable at decision step514, then the method can continue to step516, but if the result is not favorable then the added user device can be denied authentication at step520. At step516, if favorable, then the device services manager at the server can generate an authentication token, and possibly also a PRK for the added user device. This authentication token (and possibly PRK) can then be sent to the associated user device at step518. From the point of view of the server, the process is then finished. Future use of the authentication token, new PRK, or any derivatives thereof by the added user device can appear to be identical to ordinary authentication usage by the associated user device in some embodiments.

FIG. 6illustrates a flowchart of an exemplary method for transferring a trusted device status performed by a device services manager at an associated user device according to various embodiments of the present disclosure. Method600can correspond to that which is performed by associated user device420in the foregoing sequence diagram, for example. Method600begins at step602, where the associated user device is provisioned and authenticated by a server that provides device services. Various values or data items that reflect or confirm this can be stored on the associated user device, such as a unique MID and unique PRK. At step604, the associated user device pairs with an added user device. At step606, the associated user device receives a request from the added user device to transfer a trusted status to the added user deuce, which request can be accompanied by one or more data items from the added user device.

At step608, in response to the request from the added user device to which it can be paired, the associated user device sends a request to transfer a trusted status to the added user device to the server. This request can also be accompanied by one or more data items, which can include the data items sent by the added user device, as well as further data items from the associated user device. At a following step610, which can take place when the server grants the request, the associated user device receives an authentication token and possibly a unique PRK for the added user device from the server. At step612, the associated user device sends the authentication token and possibly the unique PRK to the added user device. From the point of view of the associated user device, the process is then finished.

FIG. 7illustrates a flowchart of an exemplary method for transferring a trusted device status performed by a device services manager at an added user device according to various embodiments of the present disclosure. Method700can correspond to that which is performed by added user device410in the foregoing sequence diagram, for example. Method700begins at step702, where the added user device pairs with an associated user device. As will be readily appreciated, the associated user device can already be authenticated by a server that provides device services at this point. At step704, the added user device is provisioned by the server. Various values or data items that reflect or confirm this can be stored on the added user device, which can include a unique MID, for example.

At step706, the added user device requests a transfer of a trusted status from the associated user device. The added user device sends data items for itself to the associated user device to facilitate this request at step708, which can be performed at the same time as step706, such as where the request and the data items are sent together. At step710, which can take place when the request is granted, the added user device receives an authentication token, and possibly a unique PRK, and the added user device can store this authentication token (and possible unique PRK) on itself for future use at step712. Again, future use of the authentication token, new PRK, or any derivatives thereof by the added user device can appear to be identical to ordinary authentication usage by the associated user device in some embodiments.

FIG. 8illustrates in block diagram format an exemplary computing device800that can be used to implement the various components and techniques described herein according to various embodiments of the present disclosure. In particular, the detailed view illustrates various components that can be included in the user device110illustrated inFIG. 1, among other possible user devices. As shown inFIG. 8, the computing device800can include a processor802that represents a microprocessor or controller for controlling the overall operation of computing device800. The computing device800can also include a user input device808that allows a user of the computing device to interact with the computing device800. For example, the user input device808can take a variety of forms, such as a button, keypad, dial, touch screen, audio input interface, visual/image capture input interface, input in the form of sensor data, etc. Still further, the computing device800can include a display810(screen display) that can be controlled by the processor802to display information to the user (for example, a movie or other AV or media content). A data bus816can facilitate data transfer between at least a storage device840, the processor802, and a controller813. The controller813can be used to interface with and control different equipment through and equipment control bus814. The computing device800can also include a network/bus interface811that couples to a data link812. In the case of a wireless connection, the network/bus interface811can include a wireless transceiver.

The computing device800can also include a storage device840, which can comprise a single disk or a plurality of disks (e.g., hard drives), and can include a storage management module that manages one or more partitions within the storage device840. In some embodiments, storage device840can include flash memory, semiconductor (solid state) memory or the like. The computing device800can also include a Random Access Memory (RAM)820and a Read-Only Memory (ROM)822. The ROM822can store programs, utilities or processes to be executed in a non-volatile manner. The RAM820can provide volatile data storage, and stores instructions related to the operation of computing device800.