Patent Application
20240072999
At least some embodiments disclosed herein relate generally to network storage devices and, in particular, to improvements in ensuring data privacy of user data in such devices.
In existing network storage devices (used, for example, in providing cloud services), user data is frequently encrypted prior to writing the data to persistent storage. In such systems, only the user who holds the appropriate key to decrypt the data can thus access data stored by these cloud services.
Due to the use of user encryption in cloud services, such encrypted data cannot be accessed by other users (e.g., cloud administrators) to perform operations on the data. For example, administrators or automated processes cannot access the data to perform maintenance and other operations on encrypted data. As another example, a user cannot authorize a third-party program to access their data (e.g., via an OAuth or similar flow) since the user would necessarily be required to provide their private key. Further, encrypted data can still be modified and corrupted, even if modified in encrypted form.
In some aspects, the techniques described herein relate to a method including: generating a digital certificate using a public key of a secure environment; storing the digital certificate in a storage device of a cloud service; generating, by the secure environment, a signed command to access the storage device, the signed command signed using a private key corresponding to the public key of the secure environment; and issuing the signed command to the storage device to access data stored by the storage device.
In some aspects, the techniques described herein relate to a method, wherein generating a digital certificate using a public key of a secure environment includes: transmitting the public key of the secure environment to a key management server (KMS); and generating, by the KMS, the digital certificate by using the public key of the secure environment as a Subject Public Key and signing the digital certificate using a KMS private key.
In some aspects, the techniques described herein relate to a method, wherein storing the digital certificate in a storage device of a cloud service includes: reading, by the storage device, a KMS public key stored in a write-protected region of the storage device; validating, by the storage device, the digital certificate using the KMS public key; and writing the public key of the secure environment to the write-protected region.
In some aspects, the techniques described herein relate to a method, wherein storing the digital certificate in a storage device of a cloud service further includes setting at least one access permission based on the digital certificate.
In some aspects, the techniques described herein relate to a method, wherein the digital certificate includes a validity period and the method further includes removing the digital certificate when the validity period expires.
In some aspects, the techniques described herein relate to a method, further including receiving, by the storage device, the signed command and validating the signed command by validating a digital signature included in the signed command using the public key included in the digital certificate.
In some aspects, the techniques described herein relate to a method, further including: returning, by the storage device, data responsive to the signed command; and processing, by the secure environment, the data.
In some aspects, the techniques described herein relate to a non-transitory computer-readable storage medium for tangibly storing computer program instructions capable of being executed by a computer processor, the computer program instructions defining steps of: generating a digital certificate using a public key of a secure environment; storing the digital certificate in a storage device of a cloud service; generating, by the secure environment, a signed command to access the storage device, the signed command signed using a private key corresponding to the public key of the secure environment; and issuing the signed command to the storage device to access data stored by the storage device.
In some aspects, the techniques described herein relate to a non-transitory computer-readable storage medium, wherein generating a digital certificate using a public key of a secure environment includes: transmitting the public key of the secure environment to a key management server (KMS); and generating, by the KMS, the digital certificate by using the public key of the secure environment as a Subject Public Key and signing the digital certificate using a KMS private key.
In some aspects, the techniques described herein relate to a non-transitory computer-readable storage medium, wherein storing the digital certificate in a storage device of a cloud service includes: reading, by the storage device, a KMS public key stored in a write-protected region of the storage device; validating, by the storage device, the digital certificate using the KMS public key; and writing the public key of the secure environment to the write-protected region.
In some aspects, the techniques described herein relate to a non-transitory computer-readable storage medium, wherein storing the digital certificate in a storage device of a cloud service further includes setting at least one access permission based on the digital certificate.
In some aspects, the techniques described herein relate to a non-transitory computer-readable storage medium, wherein the digital certificate includes a validity period and the steps further include removing the digital certificate when the validity period expires.
In some aspects, the techniques described herein relate to a non-transitory computer-readable storage medium, further including receiving, by the storage device, the signed command and validating the signed command by validating a digital signature included in the signed command using the public key included in the digital certificate.
In some aspects, the techniques described herein relate to a non-transitory computer-readable storage medium, the steps further including: returning, by the storage device, data responsive to the signed command; and processing, by the secure environment, the data.
In some aspects, the techniques described herein relate to a system including: a secure environment communicatively coupled to a storage device; and a key management server (KMS) configured to generate a digital certificate using a public key of a secure environment, wherein the secure environment is configured to: store the digital certificate in the storage device, generate a signed command to access the storage device, the signed command signed using a private key corresponding to the public key of the secure environment, and issue the signed command to the storage device to access data stored by the storage device.
In some aspects, the techniques described herein relate to a system, wherein generating a digital certificate using a public key of a secure environment includes: transmitting the public key of the secure environment to the KMS; and generating, by the KMS, the digital certificate by using the public key of the secure environment as a Subject Public Key and signing the digital certificate using a KMS private key.
In some aspects, the techniques described herein relate to a system, wherein storing the digital certificate in a storage device includes: reading, by the storage device, a KMS public key stored in a write-protected region of the storage device; validating, by the storage device, the digital certificate using the KMS public key; and writing the public key of the secure environment to the write-protected region.
In some aspects, the techniques described herein relate to a system, wherein storing the digital certificate in a storage device further includes setting at least one access permission based on the digital certificate.
In some aspects, the techniques described herein relate to a system, wherein the digital certificate includes a validity period and the storage device is further configured to remove the digital certificate when the validity period expires.
In some aspects, the techniques described herein relate to a system, the storage device further configured to receive the signed command and validating the signed command by validating a digital signature included in the signed command using the public key included in the digital certificate.
In an implementation, the user device 102 can comprise a general-purpose computing device such as that depicted in
In some implementations, the KMS 104 may comprise a server or network of servers that provides key management operations for user device 102, secure environment 106 and storage device 108. In some implementations, the KMS 104 can perform various key management operations not described herein for the sake of clarity. As illustrated, the KMS 104 can include authentication logic 112. In some implementations, the authentication logic 112 can authenticate requests from the user device 102. In some implementations, the authentication logic 112 can perform a user identifier (e.g., username, email, etc.) and password authentication to authenticate the user device 102. Alternatively, or in conjunction with the foregoing, the authentication logic 112 can implement a mutual transport layer security (mTLS) protocol to authenticate the user device 102. In general, any technique that can match a user device 102 to a known user (or user account) may be used. As illustrated, the KMS 104 includes a KMS private key 110. Certainly, the KMS 104 may own multiple such private keys. The KMS private key 110 may be a private key portion of an asymmetric key pair such as a Rivest—Shamir—Adleman (RSA) or Elliptic Curve Digital Signature Algorithm (ECDSA) key pair. The public key of such a key pair is not illustrated as being held by KMS 104 but may in fact be held by the KMS 104. In some implementations, the KMS private key 110 can be stored in a secure storage location such as a trusted execution environment (TEE), hardware security module (HSM), Secure Enclave, or similar type of secure storage mechanism. In some implementations, the KMS 104 can include multiple such KMS private keys for security purposes, although only one is illustrated for the sake of clarity. The KMS 104 also includes a certificate generator 114. In an implementation, the certificate generator 114 can generate a digital certificate such as an X.509-formatted digital certificate. In some implementations, the certificate generated by certificate generator 114 can include a public key provided by the user device 102 as the Subject Public Key in the Subject Public Key Info field of an X.509 certificate. In some implementations, the user device 102 may request and receive the public key 118 from secure environment 106 and provide this public key 118 to the KMS 104 (and certificate generator 114) to generate a digital certificate for the public key 118. In some implementations, the digital certificate generated by certificate generator 114 may also include a set of permissions for accessing storage area 126 as well as the public key 118. In some implementations, this set of permissions may be defined by the user device 102 when the user device 102 requests the digital certificate. Details of how KMS 104 generates a digital certificate are described more fully in the description of
The user device 102 is communicatively coupled to a secure environment 106. In an implementation, the secure environment 106 and storage device 108 may be part of the same computing device (e.g., a storage device) operated by a cloud operator. In other implementations, the secure environment 106 and storage device 108 may be physically separate. In some implementations, the secure environment 106 may be operated by the user device 102 while the storage device 108 may be operated by the cloud operator.
Secure environment 106 further includes an asymmetric key pair including a public key 118 and a private key 120. In some implementations, these keys can be generated locally by the secure environment 106. For example, in an implementation, the secure environment 106 includes a physically unclonable function 122 (PUF). The physically unclonable function 122 may comprise a physical hardware circuit that exploits inherent randomness introduced during manufacturing to give a physical entity a unique “fingerprint” or trust anchor. In the illustrated embodiment, the physically unclonable function 122 produces a consistent and repeatable value. In some embodiments, the physically unclonable function 122 may comprise a static random-access memory (SRAM), Delay PUF, or any other PUF technology implemented by secure environment 106. In an implementation, the secure environment 106 can read a PUF value from physically unclonable function 122 and use the PUF value as a seed value during key generation. In some implementations, the private key 120 and public key 118 may be an asymmetric key pair such as an RSA or ECDSA key pair. In some implementations, the private key 120 and public key 118 may be persistently stored. In other implementations, the private key 120 and public key 118 may not be persistently stored and may be regenerated as needed from the physically unclonable function 122 value. As will be illustrated, the private key 120 and public key 118 represent the cryptographic identity of secure environment 106.
In some implementations, the controller 116 can provide the secure environment public key 118 to the user device 102 in response to a request. In some implementations, this request can be authenticated by the cloud operator prior to the secure environment 106 receiving the request, thus ensuring that only an authorized user of user device 102 can access the secure environment 106. For example, the user may have a cloud storage account with the cloud operator and this account may associate a user account with storage device 108 (and thus secure environment 106). The controller 116 may also receive a digital certificate from the 102 (generated by certificate generator 114) for provisioning storage device 108. The controller 116 may receive commands to access data in storage area 126. In one implementation, controller 116 can sign these commands using private key 120 while in others the command may be signed using KMS private key 110. The controller 116 may also perform secure operations on data returned by storage device 108. In some implementations, the secure environment 106 can comprise a TEE, HSM, Secure Enclave, or similar environment. As such, operates on the data can be protected from outside devices. Details of these operations are provided in more detail herein and, in particular, the description of
Storage device 108 is communicatively coupled to secure environment 106. In some implementations, secure environment 106 and storage device 108 may communicate over a network or an internal bus (e.g., peripheral component interconnect express). Secure environment 106 includes a controller 124 that handles incoming commands including validation and execution thereon. The secure environment 106 includes a KMS public key 128 that corresponds to KMS private key 110. In some implementations, KMS public key 128 may be written to storage device 108 during manufacturing of the storage device 108. In some implementations, KMS public key 128 can be stored in a write-protected region of the storage device 108. The storage device 108 can also store one or more public keys 130 and digital certificates 132 that are associated with trusted devices. Details on how these keys and digital certificates are written are described further herein. Finally, the storage device 108 may store a set of permissions 134. In an implementation, the set of permissions 134 can include sets of permission associated with each public key and digital certificate. In an implementation, the controller 124 can receive a digital certificate that includes a public key and set of permissions and can update the set of permissions 134, one or more public keys 130, and digital certificates 132 after validating the digital certificate using the KMS public key 128. Then, when receiving a command to access data stored in storage area 126, the controller 124 can validate the command using one or more of the KMS public key 128 and one of the one or more public keys 130 to determine that the command is valid before returning data or otherwise operating on storage area 126. Details of the operations of storage device 108 are provided in more detail in the description of
As illustrated, the secure environment 106 includes a controller 116 that can receive and process commands. In some implementations, these commands can be received from the user device 102 (via the cloud infrastructure).
In step 202, method 200 can include a user device authenticating to a key management server.
In some implementations, the KMS may store a set of user accounts or credentials. In such implementations, a user may provide their identifying data (e.g., username, user ID, email address, etc.) and a password which the KMS can validate and authenticate the user. In other implementations, mutual transport layer security (mTLS) can be used to authenticate with a KMS. As discussed in
In step 204, method 200 can include retrieving a secure environment public key.
In some implementations, the secure environment public key can be managed by a cloud service. Thus, in some implementations, a user device can issue a request to the cloud service for the secure environment public key. In some implementations, a user may first authenticate with the cloud service (similar to KMS, with a user identifier and password or via mTLS). The user can then issue a request to the cloud service to obtain a secure environment public key for one or more secure environments associated with cloud storage devices. In some implementations, a user can be associated with a cloud storage device (which includes or is otherwise associated with a secure environment). In some implementations, a user device can select a given secure environment using a user interface that lists all available secure environments. In response, the cloud service can retrieve public key(s) of the selected secure environment(s) and return the public key(s) to the user. Although one public key is discussed in method 200, method 200 can be extended to operate on multiple public keys simultaneously. In another implementation, the user device may already hold the secure environment public key and may thus not need to request the secure environment public key from the cloud service. For example, the user device may cache the secure environment public key as part of other operations. As discussed previously, the secure environment public key may be a public key portion of an asymmetric key such as an RSA or ECDSA key pair generated by the secure environment. In some implementations, this asymmetric key pair can be derived from a PUF and thus unique to the secure environment.
In step 206, method 200 can include providing the secure environment public key to the KMS.
In some implementations, method 200 can include issuing a network request to the KMS that includes the secure environment public key. As discussed in step 202, the user device may authenticate with the KMS in advance and thus a session can be created to allow the user device to simply upload the public key to a designated endpoint. As will be discussed in
In step 208, method 200 can include receiving a digital certificate for the secure environment public key from the KMS.
In some implementations, the digital certificate can be an X.509 digital certificate. In some implementations, the digital certificate can include the secure environment public key as the Subject Key in the Subject Public Key Info field of the X.509 digital certificate. Any well-known digital certificate format or generation process may be used and X.509 is not intended to be limiting. To secure the digital certificate, the KMS may sign the digital certificate using its own KMS private key and include the digital signature in the digital certificate. Finally, the KMS returns the digital certificate as a response to the network request and the user device can receive this digital certificate to use in later processes (described herein).
In step 210, method 200 can include providing the digital certificate to the secure environment for later use. Details of this step are described in more detail, from the perspective of the secure environment and the storage device, in
In step 302, method 300 can include authenticating a user. Specific details on a KMS authenticating a user device were provided in the description of step 202 and are not repeated herein for the sake of brevity.
In step 304, after method 300 authenticates the user, method 300 can include receiving the secure environment public key. In general, this secure environment public key corresponds to the secure environment public key transmitted in steps 204 and 206 of
In step 306, method 300 can include generating a digital certificate for the secure environment public key and, in step 308, method 300 can include signing the digital certificate with a KMS private key.
As discussed, in some implementations, the digital certificate can be an X.509-formatted digital certificate. In some implementations, the digital certificate can include the secure environment public key as the Subject Public Key in the Subject Public Key Info field of an X.509 certificate. In some implementations, as part of step 304 (or as a separate step), method 300 may receive a set of permissions. For example, the set of permissions can specify whether an owner of the secure environment public key can read, write, read and write, erase, etc. data stored by a storage device. In some implementations, these permissions can be included in the X.509 certificate. In some implementations, these permissions can be stored as, for example, a bitstring either in a common field or in an extension of the X.509 certificate. Finally, after generating the digital certificate, step 306 can include signing the digital certificate using a KMS private key held by method 300. Since the secure environment public key and permissions are signed by the KMS private key they are tamper-proof and can reliably set permissions for a specific device as will be discussed.
In step 310, method 300 can include returning the digital certificate to the user device that sent the secure environment public key. As discussed, the digital certificate may be returned as a response to a network request.
In the illustrated methods (method 200 and method 300), a KMS and a user device establish trust as to the identity of the user device (e.g., via user identifiers or mTLS). Then, the user device provides a public key (of a secure environment) to the KMS and a set of permissions. The KMS can then act as an authority and generate digital certificate that allows an owner of the public key to access any storage device that includes the KMS public key. As will be discussed, the user device can then provision one or more storage devices with this digital certificate and then issue commands to the storage device.
In step 402, method 400 can include receiving a digital certificate from a user device. The digital certificate received in step 402 corresponds to that transmitted in step 210 of
In step 404, method 400 can include transmitting the digital certificate to a storage device. As discussed more in
As illustrated by the broken line, at a later point in time, method 400 can include signing a command using its private key in step 406. In some implementations, this private key can be the private key portion of an asymmetric key pair where the public key portion corresponds to the public key in the digital certificate received in step 402. The specific type of command is not limiting and may be any command that a storage device is capable of processing. As one example, the command can include a read command. As another example, the command can include a write command. The specific form is not limiting, however in some embodiments, the command includes a signature parameter that the storage device uses to validate commands. As such, step 406 can include generating a digital signature (e.g., using an ECDSA algorithm) and inserting the digital signature in this parameter field.
In step 408, method 400 can include issuing the command to the storage device. In some implementations, step 408 can include transmitting the signed command to the storage device over an interface such as a network or a bus. After transmitting the command, the secure environment will await a response from the storage device.
In step 410, method 400 can include receiving a response to the command. The response to the command may necessarily depend on the type of command. For example, a read command will return data stored by the storage device while a write command may return a return status of the command. In response to the response from the storage device, the secure environment may perform operations on the returned data. Specifically, the secure environment may execute any operations within a secure environment, thus ensuring data privacy during such operations. Ultimately, method 400 can then further include returning the results of its processing to the user device that issued the transmitted the signed command in step 406. In some implementations, this return result can be the data itself returned from the storage device or can be the results of further processing performed by the secure environment.
In step 502, method 500 can include receiving a digital certificate from a secure environment. The digital certificate received in step 502 corresponds to that transmitted in step 402 of
In step 504, method 500 can include validating the digital certificate and in step 506, method 500 can branch depending on the validation result. In some implementations, this validation procedure can include reading a KMS public key from a secure storage area (e.g., write-protected area) of the storage device. The procedure can then include hashing the command to generate a first hash and decrypting a digital signature of the digital certificate using the KMS public key to generate a second hash. If the first hash and the second hash match, method 500 can validate the digital certificate and proceed to step 508. Otherwise, method 500 can discard the digital certificate and ignore future commands in step 510. In some implementations, step 510 can further include returning an error result to the secure environment.
If method 500 can validate the digital certificate, method 500 can be certain that the digital certificate was generated by a KMS. Further, since the KMS authenticates a user device prior to issuing the digital certificate, method 500 can assume that a valid user has transmitted the digital certificate. Next, in step 508, method 500 can include storing the secure environment public key in the digital certificate and any permissions in the digital certificate. As discussed above, the digital certificate may comprise an X.509 certificate. This certificate includes the secure environment public key as the Subject Public Key Info field and may include a set of permissions in a common or extension field. Method 500 can extract both these values from the digital certificate and store these values for use when processing future commands.
After a period of time (indicated by the broken line), in step 512, method 500 can receive a signed command and in step 514 can validate this signed command. In some implementations, the signature of the command can be generated using the private key of the secure environment. In some implementations, this private key must correspond to the public key stored in step 508 for method 500 to continue. Thus, only the secure environment (the holder of the public key) can issue commands to method 500. As discussed previously, the command can include any command accessing data managed by the storage device. Alternatively, or in conjunction with the foregoing, the signed command can also include a second signature generated by the KMS. In this implementation, the KMS first signs the command with its KMS private key. Then, the secure environment can sign the once-signed command with its own private key. Method 500 can then first validate the second signature (using the secure environment public key) and then validate the second signature using the KMS public key. If any digital signature validations fail, method 500 can ignore the command in step 510 and return an error.
In some implementations, step 514 can also include checking one or more permissions of the command. As discussed in step 508, method 500 can store a set of permissions associated with a public key. In step 514, method 500 can load these permissions by using the public key used to decrypt the digital signature and comparing the requested operation in the command to a set of allowed operations (i.e., permissions). If the operation is not allowed based on the set of permissions, method 500 proceeds to step 510 to ignore the command. Alternatively, if the operation is permitted, method 500 proceeds to step 516.
By contrast, if the digital signature validations pass, method 500 can proceed to step 516 and process the command. As discussed, the command may be a read, write, erase, etc. command that modifies or otherwise accesses data stored in a storage array of the storage device. The specific type of command is not limiting and any command that can be issued to a storage device can be used. After executing the command, method 500 can include returning the results of the operation to the secure environment that issued the command (as discussed in
In some implementations, method 500 can also include continuously checking the validity of the digital certificate. In some implementations, the digital certificate can include a validity period that defines how long the digital certificate is valid. Method 500 can monitor this validity period and remove the digital certificate (and corresponding public key and permissions) when the digital certificate expires. Since the digital certificate usually has a short valid period, a malicious party cannot replay the data handling after the user finishes the data handling because the digital certificate will already expire, and the access will be denied by storage when the digital certificate is removed after expiration.
In the foregoing methods, a KMS and user device operate to authorize a secure environment to operate on data stored by a storage device. Further, by relying on digital certificates of individual secure environment, a user can authorize multiple secure environments to access a storage device. As such, a user device can delegate authority to multiple secure environments.
As illustrated in
In the illustrated embodiment, host processor 620 can comprise any type of computer processors, such as a central processing unit (CPU), graphics processing unit (GPU), or other types of general-purpose or special-purpose computing devices. The host processor 620 includes one or more output ports that allow for the transmission of address, user, and control data between the host processor 620 and the memory device 602. In the illustrated embodiment, this communication is performed over bus 604. In one embodiment, the bus 604 comprises an input/output (I/O) bus or a similar type of bus.
The memory device 602 is responsible for managing one or more memory banks (e.g., bank 608A, bank 608B, bank 608C, bank 608D, bank 608N, etc.). In one embodiment, the memory banks (e.g., bank 608A, bank 608B, bank 608C, bank 608D, bank 608N, etc.) comprise NAND Flash dies or other configurations of non-volatile memory. In one embodiment, the memory banks (e.g., bank 608A, bank 608B, bank 608C, bank 608D, bank 608N, etc.) comprise a memory array.
The memory banks (e.g., bank 608A, bank 608B, bank 608C, bank 608D, bank 608N, etc.) are managed by the controller 606. In some embodiments, the controller 606 comprises a computing device configured to mediate access to and from banks (e.g., bank 608A, bank 608B, bank 608C, bank 608D, bank 608N, etc.). In one embodiment, the controller 606 comprises an ASIC or other circuitry installed on a printed circuit board housing the memory banks (e.g., bank 608A, bank 608B, bank 608C, bank 608D, bank 608N, etc.). In some embodiments, the controller 606 may be physically separate from the memory banks (e.g., bank 608A, bank 608B, bank 608C, bank 608D, bank 608N, etc.). The controller 606 communicates with the memory banks (e.g., bank 608A, bank 608B, bank 608C, bank 608D, bank 608N, etc.) over the interface 612. In some embodiments, this interface 612 comprises a physically wired (e.g., traced) interface. In other embodiments, interface 612 comprises a standard bus for communicating with memory banks (e.g., bank 608A, bank 608B, bank 608C, bank 608D, bank 608N, etc.).
The controller 606 comprises various modules, including local cache 614, firmware 616, and ECC module 618. In one embodiment, the various modules (e.g., local cache 614, firmware 616, and ECC module 618) comprise various physically distinct modules or circuits. In other embodiments, the modules (e.g., local cache 614, firmware 616, and ECC module 618) may completely (or partially) be implemented in software or firmware.
As illustrated, firmware 616 comprises the core of the controller and manages all operations of the controller 606. The firmware 616 may implement some or all of the methods described above. Specifically, firmware 616 may implement the methods described in the foregoing figures.
As illustrated, the device 700 includes a processor or central processing unit (CPU) such as CPU 702 in communication with a memory 704 via a bus 714. The device also includes one or more input/output (I/O) or peripheral devices 712. Examples of peripheral devices include, but are not limited to, network interfaces, audio interfaces, display devices, keypads, mice, keyboards, touch screens, illuminators, haptic interfaces, global positioning system (GPS) receivers, cameras, or other optical, thermal, or electromagnetic sensors.
In some embodiments, the CPU 702 may comprise a general-purpose CPU. The CPU 702 may comprise a single-core or multiple-core CPU. The CPU 702 may comprise a system-on-a-chip (SoC) or a similar embedded system. In some embodiments, a graphics processing unit (GPU) may be used in place of, or in combination with, a CPU 702. Memory 704 may comprise a memory system including a dynamic random-access memory (DRAM), static random-access memory (SRAM), Flash (e.g., NAND Flash), or combinations thereof. In one embodiment, the bus 714 may comprise a Peripheral Component Interconnect Express (PCIe) bus. In some embodiments, bus 714 may comprise multiple busses instead of a single bus.
Memory 704 illustrates an example of a non-transitory computer storage media for the storage of information such as computer-readable instructions, data structures, program modules, or other data. Memory 704 can store a basic input/output system (BIOS) in read-only memory (ROM), such as ROM 708, for controlling the low-level operation of the device. The memory can also store an operating system in random-access memory (RAM) for controlling the operation of the device.
Applications 710 may include computer-executable instructions that, when executed by the device, perform any of the methods (or portions of the methods) described previously in the description of the preceding figures. In some embodiments, the software or programs implementing the method embodiments can be read from a hard disk drive (not illustrated) and temporarily stored in RAM 706 by CPU 702. CPU 702 may then read the software or data from RAM 706, process them, and store them in RAM 706 again.
The device may optionally communicate with a base station (not shown) or directly with another computing device. One or more network interfaces in peripheral devices 712 are sometimes referred to as a transceiver, transceiving device, or network interface card (NIC).
An audio interface in peripheral devices 712 produces and receives audio signals such as the sound of a human voice. For example, an audio interface may be coupled to a speaker and microphone (not shown) to enable telecommunication with others or generate an audio acknowledgment for some action. Displays in peripheral devices 712 may comprise liquid crystal display (LCD), gas plasma, light-emitting diode (LED), or any other type of display device used with a computing device. A display may also include a touch-sensitive screen arranged to receive input from an object such as a stylus or a digit from a human hand.
A keypad in peripheral devices 712 may comprise any input device arranged to receive input from a user. An illuminator in peripheral devices 712 may provide a status indication or provide light. The device can also comprise an input/output interface in peripheral devices 712 for communication with external devices, using communication technologies, such as USB, infrared, Bluetooth®, or the like. A haptic interface in peripheral devices 712 provides tactile feedback to a user of the client device.
A GPS receiver in peripheral devices 712 can determine the physical coordinates of the device on the surface of the Earth, which typically outputs a location as latitude and longitude values. A GPS receiver can also employ other geo-positioning mechanisms, including, but not limited to, triangulation, assisted GPS (AGPS), E-OTD, CI, SAI, ETA, BSS, or the like, to further determine the physical location of the device on the surface of the Earth. In one embodiment, however, the device may communicate through other components, providing other information that may be employed to determine the physical location of the device, including, for example, a media access control (MAC) address, Internet Protocol (IP) address, or the like.
The device may include more or fewer components than those shown in
The subject matter disclosed above may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein; example embodiments are provided merely to be illustrative. Likewise, reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, the subject matter may be embodied as methods, devices, components, or systems. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, or any combination thereof (other than software per se). The preceding detailed description is, therefore, not intended to be taken in a limiting sense.
Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in an embodiment” as used herein does not necessarily refer to the same embodiment, and the phrase “in another embodiment” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part.
In general, terminology may be understood at least in part from usage in context. For example, terms such as “and,” “or,” or “and/or,” as used herein may include a variety of meanings that may depend at least in part upon the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B, or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B, or C, here used in the exclusive sense. In addition, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures, or characteristics in a plural sense. Similarly, terms, such as “a,” “an,” or “the,” again, may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for the existence of additional factors not necessarily expressly described, again, depending at least in part on the context.
The present disclosure is described with reference to block diagrams and operational illustrations of methods and devices. It is understood that each block of the block diagrams or operational illustrations, and combinations of blocks in the block diagrams or operational illustrations, can be implemented by means of analog or digital hardware and computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer to alter its function as detailed herein, a special purpose computer, application-specific integrated circuit (ASIC), or other programmable data processing apparatus, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, implement the functions/acts specified in the block diagrams or operational block or blocks. In some alternate implementations, the functions or acts noted in the blocks can occur out of order. For example, two blocks shown in succession can, in fact, be executed substantially concurrently, or the blocks can sometimes be executed in the reverse order, depending upon the functionality or acts involved.
These computer program instructions can be provided to a processor of a general purpose computer to alter its function to a special purpose; a special purpose computer; ASIC; or other programmable digital data processing apparatus, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, implement the functions or acts specified in the block diagrams or operational block or blocks, thereby transforming their functionality in accordance with embodiments herein.
For the purposes of this disclosure, a computer-readable medium (or computer-readable storage medium) stores computer data, which data can include computer program code or instructions that are executable by a computer, in machine-readable form. By way of example and not limitation, a computer-readable medium may comprise computer-readable storage media for tangible or fixed storage of data or communication media for transient interpretation of code-containing signals. Computer-readable storage media, as used herein, refers to physical or tangible storage (as opposed to signals) and includes without limitation volatile and non-volatile, removable, and non-removable media implemented in any method or technology for the tangible storage of information such as computer-readable instructions, data structures, program modules or other data. Computer-readable storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid-state memory technology, CD-ROM, DVD, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage devices, or any other physical or material medium which can be used to tangibly store the desired information or data or instructions and which can be accessed by a computer or processor.
For the purposes of this disclosure, a module is a software, hardware, or firmware (or combinations thereof) system, process or functionality, or component thereof that performs or facilitates the processes, features, and/or functions described herein (with or without human interaction or augmentation). A module can include sub-modules. Software components of a module may be stored on a computer-readable medium for execution by a processor. Modules may be integral to one or more servers or be loaded and executed by one or more servers. One or more modules may be grouped into an engine or an application.
Those skilled in the art will recognize that the methods and systems of the present disclosure may be implemented in many manners and, as such, are not to be limited by the foregoing exemplary embodiments and examples. In other words, functional elements being performed by single or multiple components, in various combinations of hardware and software or firmware, and individual functions, may be distributed among software applications at either the client level or server level, or both. In this regard, any number of the features of the different embodiments described herein may be combined into single or multiple embodiments, and alternate embodiments having fewer than or more than all the features described herein are possible.
Functionality may also be, in whole or in part, distributed among multiple components, in manners now known or to become known. Thus, a myriad of software, hardware, and firmware combinations are possible in achieving the functions, features, interfaces, and preferences described herein. Moreover, the scope of the present disclosure covers conventionally known manners for carrying out the described features and functions, and interfaces, as well as those variations and modifications that may be made to the hardware, software, or firmware components described herein as would be understood by those skilled in the art now and hereafter.
Furthermore, the embodiments of methods presented and described as flowcharts in this disclosure are provided by way of example to provide a complete understanding of the technology. The disclosed methods are not limited to the operations and logical flow presented herein. Alternative embodiments are contemplated in which the order of the various operations is altered and in which sub-operations described as being part of a larger operation are performed independently.
While various embodiments have been described for purposes of this disclosure, such embodiments should not be deemed to limit the teaching of this disclosure to those embodiments. Various changes and modifications may be made to the elements and operations described above to obtain a result that remains within the scope of the systems and processes described in this disclosure.
