Patent Description:
A computing device may include multiple subsystems that communicate with one another via buses or other interconnects. Such a computing device may be, for example, a portable computing device ("PCD"), such as a laptop or palmtop computer, a cellular telephone or smartphone, portable digital assistant, portable game console, etc. The communicating subsystems may be included within the same integrated circuit chip or in different chips. A "system-on-a-chip" or "SoC" is an example of one such chip that integrates numerous components to provide system-level functionality.

For example, an SoC may include one or more types of processors, such as central processing units ("CPU"s), graphics processing units ("GPU"s), digital signal processors ("DSP"s), and neural processing units ("NPU"s). An SoC may include other subsystems, such as a transceiver or "modem" that provides wireless connectivity, a main or system memory, one or more cache memories, etc. Some subsystems may include processing engines that may perform memory transactions with a memory. The system memory in PCDs and other computing devices commonly comprises dynamic random access memory ("DRAM"). In addition to DRAM, or alternatively to DRAM, a computing device may include non-volatile memory, such as flash memory.

A computing device may "delete" data, such as when a user requests deletion of a file, when an application program deletes temporary data that it no longer requires, etc. Nevertheless, deleting data in this manner does not physically remove the data from storage in the memory. Rather, deleting data in such a manner only causes the memory controller to de-map logical addresses by which the host (e.g., a processing engine) identifies the data from physical addresses identifying locations at which the data is physically stored in the memory. Such de-mapping, in conjunction with a process known as "garbage collection," enables the physical locations to be re-used. Nevertheless, it may be possible for a hacker or other party to retrieve deleted or otherwise de-mapped data (e.g., during a window after deletion but before garbage collection).

As confidential or otherwise sensitive data is commonly stored in the memories of PCDs and other computing devices, it is desirable to prevent retrieval of de-mapped data. "Purging" is a term that is commonly used to refer to physically eliminating data from a memory in a way that prevents the data from being retrieved. Purging flash memory is challenging because features known as write-leveling and garbage collection commonly result in multiple copies of data being distributed about the various physical "blocks. " Flash memory may be purged by a host sending a purge command to a flash memory device. In response to the purge command, the flash memory device may purge all de-mapped blocks in the flash memory device. Flash memory also may be purged by performing a so-called "factory reset," in which all blocks of the memory are de-mapped, followed by a purge operation on the de-mapped blocks. Purging flash memory in this manner may take a substantial amount of time, which may inconvenience the user or otherwise be undesirable.

Attention is drawn to <CIT> describing method and apparatus for the nondestructive, selective purging of data from a non-volatile memory. Multiple copies of a selected set of confidential user data having a common logical address are stored to a confidential data portion of a non-volatile memory so that each copy is in a different location within the confidential data portion. A nondestructive purge of all said copies from the confidential data portion is carried out responsive to an externally supplied selective purge command so that all said copies are erased and other, non-purged confidential user data remain stored in the confidential data portion.

Systems, methods, computer-readable media, and other examples are disclosed for purging data from a memory device.

As illustrated in <FIG>, a memory map <NUM> represents storage space in a memory device (not shown). The memory map <NUM> may include partitions <NUM>, such as a first partition 102A, a second partition 102B, etc., through an Nth partition 102N. The terms "first," "second," etc., are used herein only as an aid for referencing distinct elements and should not be construed as implying any location, order, sequence, etc. There may be any number (N) of partitions <NUM>. The memory map <NUM> is depicted in a conceptual manner in <FIG> and is not intended to indicate actual memory addresses.

Data may be stored in the partitions <NUM> in locations that may be referred to herein as blocks <NUM>. That is, each block <NUM> has a physical block address ("PBA") that may be used to write data to (i.e., physically store data in) or read data from (i.e., physically retrieve data from) that block <NUM>. The illustrated blocks <NUM> are intended only as examples, and there may be any number of blocks <NUM> in any of the partitions <NUM>.

The memory map <NUM> may also include regions relating to management of the blocks <NUM> in the first through Nth partitions 102A-102N: a global used block list <NUM>, a global garbage block list <NUM>, and a global free block list <NUM>. Block "management" refers to processes by which blocks <NUM> may be made available for data storage, such as when data is stored in a block <NUM>, after data is deleted, etc. Block management also involves moving information identifying the blocks <NUM>, such as block addresses, from one of the lists <NUM>-<NUM> to another of the lists <NUM>-<NUM>. For reasons described below, used blocks may also be referred to as mapped blocks, and garbage blocks may also be referred to as de-mapped blocks.

In the exemplary embodiment illustrated in <FIG>, the memory map <NUM> may further include regions relating to management of the blocks <NUM> in the first partition 102A only: a local used block list <NUM> and a local garbage block list <NUM>. A local free block list <NUM> may also be included. That is, while the global used block list <NUM>, global garbage block list <NUM>, and global free block list <NUM> are associated with all of the partitions 102A-102N in the illustrated embodiment, the local used block list <NUM>, local garbage block list <NUM>, and local free block list <NUM> are associated with only the first partition 102A in the illustrated embodiment. Nevertheless, in other embodiments such a memory map may omit the local free block list <NUM> and instead use the global free block list <NUM>. A potential issue is that in embodiments utilizing the local free block list <NUM>, excessive use of the local purge function described below could prematurely wear the memory locations, whereas wear leveling may mitigate such wear in embodiments omitting the local free block list <NUM> and utilizing only the global free block list <NUM>.

As illustrated in <FIG>, in a system <NUM> a flash memory device <NUM> is coupled to a host system <NUM>. The host system <NUM> may be, for example, a computing device or portion thereof, such as a processor subsystem, processing engine, etc..

In the illustrated embodiment the flash memory device <NUM> has storage block management features and thus may be of a type commonly referred to as a "managed" memory device. Examples of managed memory devices include Universal Flash Storage ("UFS"), Embedded Multi-media Card ("eMMC"), Non-volatile Memory Express ("NVMe"), etc. Thus, in other embodiments of the system the memory device may be of any of the foregoing or other non-volatile, managed memory types. The flash memory device <NUM> may include a controller <NUM>. The controller <NUM> may provide functions associated with a memory controller of a solid-state storage (e.g., flash memory) drive, including, for example, storage block management. The controller <NUM> may be configured to perform conventional functions associated with a memory controller of a flash memory drive, such as aspects relating to writing and reading data, as well as functions described below relating to purging de-mapped blocks. Conventional aspects of the flash memory device <NUM> that are well understood by one of ordinary skill in the art are not described in detail herein.

The flash memory device <NUM> may also include a flash data storage medium <NUM>. As understood by one of ordinary skill in the art, the flash data storage medium <NUM> may comprise (not shown for purposes of clarity) one or more dies, each die having one or more planes, each plane having some number (commonly on the order of thousands but potentially any number) of blocks, and each block having some number (commonly on the order of dozens but potentially any number) of pages.

Data may be stored in the flash memory device <NUM> at the initiation of the host system <NUM>, i.e., in response to a write request (command) issued by the host system <NUM>. The write command may include one or more logical block addresses ("LBA"s) identifying locations in the host or "logical" address space at which the host system <NUM> requests the data be stored. When data is to be stored in the flash memory device <NUM>, the controller <NUM> generates a mapping between each LBA and one or more PBAs. This mapping (of a block <NUM>) may be stored in a mapping table <NUM> associated with a Flash Translation Layer ("FTL") <NUM> with which the controller <NUM> is configured (e.g., by software or firmware). A block <NUM> that has been mapped may also be referred to as a "used" block <NUM>, i.e., the block <NUM> is in use. The controller <NUM> may add the LBA of each mapped block <NUM> to the global used block list <NUM> (<FIG>).

The flash memory device <NUM> may also have a host interface <NUM> and a flash physical interface <NUM>, which may comprise portions of the controller <NUM>. Under control of the controller <NUM>, data that is the subject of the write request may be stored in the storage medium <NUM> at locations corresponding to the PBAs of the mapping. Details of the manner by which data may be conveyed from the host system <NUM> to the storage medium <NUM> and stored therein under control of the controller <NUM> (e.g., via the host interface <NUM> and flash physical interface <NUM>) are well understood by one of ordinary skill in the art and therefore not described herein.

The host system <NUM> may address the data that is the subject of read and write commands using LBAs. Although not shown for purposes of clarity, the portion of the host system <NUM> that allocates and de-allocates LBAs based on the operation of application programs or other software in operation is commonly referred to as a file system. The file system may be part of the operating system of the host system <NUM>.

Commonly, the flash storage medium <NUM> is not over-writeable. Rather, data can only be stored in a block <NUM> (<FIG>) that has been erased. An erased block may also be referred to as being in a "free" state. Blocks <NUM> that have been erased may be listed in the global free list <NUM> (<FIG>). In embodiments in which the flash storage medium is over-writable, blocks may be listed in the global free list <NUM> without first erasing them. In generating the above-described mapping in response to a write command, the controller <NUM> may select a PBA from the global free list <NUM>.

As understood by one of ordinary skill in the art, physical locations in the storage medium <NUM> have a limited lifespan. That is, after some number of accesses (e.g., Erase and Program flash memory commands), each location will be worn to an extent that it may no longer function properly. To mitigate this "wear" effect, a flash memory controller may run a process known as wear leveling. In accordance with wear leveling, the controller <NUM> may attempt to distribute data evenly over all blocks <NUM> to avoid wearing some blocks <NUM> more than others. Wear-leveling, like the above-described mapping, is another function of the FTL <NUM>.

Data stored in the flash memory device <NUM> may be deleted from the perspective of the host system <NUM>. To delete data in this manner, the host system <NUM> may issue a Write or Erase command to the flash memory device <NUM>. The Write or Erase command may include one or more LBAs identifying locations from which the host system <NUM> requests the data to be deleted. In response to a Write or Erase command, the controller <NUM> may remove the mappings between one or more PBAs and LBAs from the mapping table <NUM>. For clarity, a command issued by the host system <NUM> that causes the controller <NUM> to remove such mappings (e.g., a Write or Erase command) may be referred to in this disclosure as a "de-map" command. The controller <NUM> may also move the PBA of each de-mapped block <NUM> (<FIG>) from the global used block list <NUM> to the global garbage block list <NUM>.

In a process commonly referred to as garbage collection, the controller <NUM> may sometimes move data (pages) in blocks <NUM> listed in the global used block list <NUM> to other blocks <NUM> and update the mapping table <NUM> accordingly. The goal of such movement of data is to remove some of the blocks <NUM> from use, so that those blocks <NUM> no longer in use can be erased and then re-used to store new data. When a block <NUM> no longer contains data that is in use, the controller <NUM> may move the PBA of that block <NUM> from the global used block list <NUM> to the global garbage block list <NUM>. The controller <NUM> may erase the blocks <NUM> listed in the global garbage block list <NUM> and move the PBAs of the erased blocks <NUM> to the global free block list <NUM>. Garbage collection, like the above-described mapping, is another function of the FTL <NUM>. The controller <NUM> may perform garbage collection in the background, i.e., at times during which the host system <NUM> is not interacting with the flash memory device <NUM>.

For security reasons, it may be desirable to prevent retrieval of de-mapped data (i.e., data that is invalid or no longer in use) from the storage medium <NUM>. Although the above-described de-mapping prevents the host system <NUM> from accessing the data (addressed by LBAs), such de-mapping does not affect the physical state of the data in the storage medium <NUM>. Absent the purge-related features described below, it may be possible for a hacker or other party to retrieve de-mapped data from the storage medium <NUM> using, for example, a software tool (i.e., software other than the file system of the host system <NUM>).

Terms such as "sanitizing," "wiping," etc. commonly refer to eliminating physical manifestations of de-mapped data from a memory to prevent the data from being retrieved. Performing such operations on flash memory may be challenging because, among other reasons, operation of the above-described wear leveling, garbage collection, etc., features may result in multiple copies of the same data distributed about the storage medium <NUM>.

Managed flash devices, such as UFS devices, may implement a Purge command, which may be referred to herein as a global Purge command to distinguish it from a local purge command that is described below. In response to a global Purge command issued by the host system <NUM>, the controller <NUM> may erase all de-mapped blocks <NUM>. Managed flash devices also may implement a Format Unit command. In response to a Format Unit command issued by the host system <NUM>, the controller <NUM> may erase all de-mapped blocks <NUM> (e.g., in response to an Erase command) and then write various data values, such as all zeroes, all ones, random numbers, etc., to the erased blocks <NUM> to obscure any remaining physical manifestations of the originally stored data. The controller <NUM> may move the PBAs of purged blocks <NUM> from the global garbage block list <NUM> to the global free block list <NUM>.

When the global garbage block list <NUM> contains many de-mapped blocks <NUM>, purging them in the manner described above in response to a global Purge command or a Format Unit command may be time-consuming. A global purge operation as described above may take, for example, an amount of time on the order of hours. To provide a faster purge operation than the global purge operation, the device <NUM> may be provided with the following local purge feature in addition to, or alternatively to, the global purge feature described above.

At least one of the partitions <NUM>, which may be referred to as a "special" or "local" partition, may have one or more characteristics that are different from other partitions <NUM>. In the illustrated embodiment, the first partition 102A may be the special or local partition, as depicted in <FIG> by a border in bold line. In the illustrated embodiment, the special characteristics of the first partition 102A include the local used block list <NUM>, the local garbage block list <NUM>, and the local free block list <NUM>. As noted above, in some embodiments the local free block list <NUM> may be omitted. In the illustrated embodiment, partitions <NUM> other than the first partition 102A do not include such a local used block list, local garbage block list or local free block list.

The special or local partition, such as the first partition 102A in the illustrated embodiment, may be, for example, a Replay-Protected Memory Block ("RPMB"). An RPMB is a type of authenticated-access partition. An entity (e.g., host system <NUM>) may only be granted access to an authenticated-access partition, such as an RPMB, when authentication of the entity is successful. Nevertheless, in other embodiments the special partition may be any partition (sometimes also referred to as a Logical Unit) of the storage medium.

To provide the local purge feature, the controller <NUM> may be configured (e.g., by software or firmware) to respond to a local purge command received from the host system <NUM> in a manner similar to the above-described manner in which the controller <NUM> responds to a global purge command. However, in an exemplary embodiment, unlike the global purge operation, which purges all blocks <NUM> (<FIG>) listed in the global garbage block list <NUM>, the local purge operation purges only the blocks <NUM> listed in the local garbage block list <NUM>. Thus, in this exemplary embodiment, unlike the global purge operation, which may purge blocks <NUM> in any of the first through Nth partitions 102A-102N, the local purge operation may purge blocks <NUM> in only the first partition 102A and not purge any blocks in any of the second through Nth partitions 102B-102N. The local purge operation may comprise the controller <NUM> erasing all blocks <NUM> listed in the local garbage block list <NUM>. The local purge operation may also comprise the controller writing various data values, such as all zeroes, all ones, random numbers, etc., to those erased blocks <NUM> to obscure any remaining physical manifestations of the originally stored data. The controller <NUM> may move the PBAs of purged blocks <NUM> from the local garbage block list <NUM> to the global free block list <NUM> (or, in some embodiments, to the local free block list <NUM>). The local purge operation may be completed within a substantially shorter amount of time than a global purge operation because the local purge operation is confined to the special partition (e.g., the first partition 102A in this exemplary embodiment).

The controller <NUM> may be configured to perform garbage collection in the first partition 102A in a manner similar to the above-described manner in which the controller <NUM> may perform garbage collection in partitions <NUM> in general. That is, the controller <NUM> may sometimes move data (pages) in blocks <NUM> listed in the local used block list <NUM> to other blocks <NUM> in the first partition 102A and update the mapping table <NUM> accordingly, with the goal of removing some of the blocks <NUM> in the first partition 102A from use. When a block <NUM> listed in the local used block list <NUM> no longer contains data that is in use, the controller <NUM> may move the PBA of that block <NUM> from the local used block list <NUM> to the local garbage block list <NUM>. The controller <NUM> may erase the blocks <NUM> listed in the local garbage block list <NUM> and move the PBAs of those erased blocks <NUM> to the global free block list <NUM> (or, in some embodiments, to the local free block list <NUM>).

Note that while both garbage collection and purge operations involve erasing blocks <NUM>, garbage collection commonly results in only a fraction of the de-mapped blocks <NUM> being erased at a time. In contrast, a purge operation may erase all de-mapped blocks <NUM>: a global purge operation may erase all de-mapped blocks <NUM> listed in the global garbage block list <NUM>, and a local purge operation may erase only de-mapped blocks <NUM> listed in the local garbage block list <NUM>.

Write operations directed to the first partition 102A may be performed in a manner similar to the manner described above with regard to any of the partitions <NUM>, except that block management operations associated with the first partition 102A may use the local used block list <NUM> and local garbage block list <NUM> instead of the global used block list <NUM> and global garbage block list <NUM>, respectively. In some embodiments, the local free block list <NUM> may be used instead of, or in addition to, the global free block list <NUM>. Accordingly, in response to receiving a write request (command) from the host system <NUM>, the controller <NUM> may select one or more blocks <NUM> listed in the global free block list <NUM> (as identified by PBA), generate a mapping between each LBA and the one or more PBAs, store the one or more mappings in the mapping table <NUM>, store the data that is the subject of the write request in the storage medium <NUM>, and add the PBA of each mapped block <NUM> to the local used block list <NUM>. As noted above, in the exemplary embodiment a prerequisite or condition of completing a write operation or other access in the first partition 102A is successful authentication of the host system <NUM>. Nevertheless, in other embodiments, the special partition may not be an authenticated-access block, and authentication thus may not be required for a host system to access the special partition in such other embodiments.

In <FIG>, a method <NUM> for purging data from a memory device having two or more storage partitions is illustrated in flow diagram form. As indicated by block <NUM>, LBAs may be de-mapped from physical memory blocks of a storage partition of the memory device. This storage partition may be, for example, a special partition as described above with regard to <FIG> (e.g., the first partition 102A). As indicated by block <NUM>, de-mapped physical memory blocks of that storage partition may be listed in a local de-mapped block list uniquely associated with that storage partition. As indicated by block <NUM>, a local purge command may be received from a host device. As indicated by block <NUM>, in response to the local purge command, only the de-mapped physical memory blocks listed in the local de-mapped block list may be purged. That is, de-mapped physical memory blocks listed in any other de-mapped block list, such as a global de-mapped block list, may not be purged in response to this local type of purge command. In some embodiments, the method <NUM> may be provided in addition to a method (not shown) by which de-mapped physical memory blocks listed in a global de-mapped block list, covering all partitions of the memory device, may be purged. It should be understood that although blocks <NUM>-<NUM> are described above in an exemplary order conducive to guiding the reader through an example of the method <NUM>, the actions described above in association with blocks <NUM>-<NUM> may occur in any order that produces the same or similar results.

Conveniently, the local purge feature may be used to, in effect, purge encrypted data stored in the second through Nth partitions 102B-102N. This feature is sometimes referred to as a cryptographic purge. Although a local purge operation may only actually purge data blocks <NUM> in the first partition 102A, in an embodiment in which the data blocks <NUM> in the first partition 102A are used to store key information associated with encrypted data stored in data blocks <NUM> in any of the second through Nth partitions 102B-102N, purging the key information in effect purges data encrypted in association with the key information. In <FIG>, encryption of data in some exemplary data blocks <NUM> in the second through Nth partitions 102B-102N by key information in other exemplary data blocks <NUM> in the first partition 102A is conceptually indicated by broken-line arrows. The encryption keys may be stored in an encrypted form by a technique sometimes referred to as key wrapping.

As illustrated in <FIG>, a key wrapping scheme <NUM> may involve several types of keys and several operations or functions. The key wrapping scheme <NUM> may be provided in the host system <NUM> (<FIG>). A key derivation function <NUM> may operate upon inputs comprising a seed <NUM> (i.e., a randomly generated number), a unique hardware key <NUM> and user credentials (or context) to produce a key wrapping key <NUM>. A key generator <NUM> may produce a (random) storage encryption key <NUM>. A key wrapping function <NUM> may operate upon inputs comprising the key wrapping key <NUM> and the storage encryption key <NUM> to produce a wrapped storage encryption key <NUM>. The wrapped storage encryption key <NUM> and the seed <NUM> may be stored in a block <NUM> in a form sometimes referred to as a binary large object or "blob. " The above-referenced "key information" may include the wrapped storage encryption key <NUM>, the seed <NUM> to that key <NUM>, or other information that may enable recovery of the encrypted data. In an exemplary embodiment, all of the data stored in blocks <NUM> in the partitions 102B-102N may be encrypted by keys (in the form of key blobs, for example) stored in blocks <NUM> in the first partition 102A. In such an embodiment, purging the first partition 102A, containing the key information, in effect (or from a cryptographic perspective) purges all of the partitions 102A-102N because the data cannot be retrieved without the key information. As noted above, purging only the first partition 102A may be substantially faster than purging all of the partitions 102A-102N.

In <FIG>, a method <NUM> for purging data from a memory device having two or more storage partitions is illustrated in flow diagram form. As indicated by block <NUM>, data may be encrypted using corresponding keys to form encrypted data units. As indicated by block <NUM>, the key information may be stored in a first storage partition. This first storage partition may be, for example, a special partition as described above with regard to <FIG> (e.g., the first partition 102A), in contrast with some other (second, third, etc.) storage partition of the memory device. As indicated by block <NUM>, the encrypted data units may be stored in another (second) storage partition of the memory device.

As indicated by block <NUM>, logical memory blocks associated with the keys may be de-mapped from physical memory blocks in which the key information was stored (block <NUM>). As indicated by block <NUM>, de-mapped physical memory blocks of the first storage partition may be listed in a local de-mapped block list uniquely associated with the first storage partition. As indicated by block <NUM>, a local purge command may be received from a host device. As indicated by block <NUM>, in response to the local purge command, only the de-mapped physical memory blocks listed in the local de-mapped block list (and thus including de-mapped physical memory blocks in which the key information was stored) may be purged. That is, de-mapped physical memory blocks listed in any other de-mapped block list, such as a global de-mapped block list, may not be purged in response to the local purge command. In some embodiments, the method <NUM> may be provided in addition to a method (not shown) by which de-mapped physical memory blocks listed in a global de-mapped block list covering all partitions of the memory device may be purged. It should be understood that although blocks <NUM>-<NUM> are described above in an exemplary order conducive to guiding the reader through an example of the method <NUM>, the actions described above in association with blocks <NUM>-<NUM> may occur in any order that produces the same or similar results.

In <FIG>, a key hierarchy <NUM> illustrates that the above-referenced keys may be of any type. For example, the above-referenced keys may be any of: a user key <NUM> (e.g., a first user key 602A associated with a first user, a second user key 602B associated with a second user, etc.); an application-specific key <NUM> (e.g., a first application-specific key 604A associated with a first application program, a second application-specific key 604B associated with a second application program, etc.); or a folder key <NUM> (e.g., a first folder key 606A associated with a first folder of the first application program, a second folder key 606B associated with a second folder of the first application program, etc.).

The key hierarchy <NUM> may be maintained in the above-described special partition of the memory device by a key management system (not shown) of the host system <NUM> (<FIG>). Each user key <NUM> may be unique to a user of the application programs on the host system <NUM>. The key management system may use a user key <NUM> to wrap an application-specific key <NUM>, and may use an application-specific key <NUM> to wrap a folder key <NUM>. When an application program deletes a folder protected by a folder key <NUM>, the key management system may generate a new application-specific key <NUM> and re-wrap all the associated folder keys <NUM>. When a different user requires access to the application programs, the key management system may use that user's user key <NUM> to wrap the application-specific keys <NUM>. When a user no longer requires access to the application programs, the key management system may remove that user's user key <NUM> from the special partition in which keys are stored. Removing a key from the special partition may comprise de-mapping the block containing the key. The key management system may purge the special partition (thus purging all de-mapped keys) in the manner described above. The key management system may purge the special partition at any time, such as, for example, hourly, daily, etc., or when a block containing a key is de-mapped.

A purge count feature may be included in some embodiments, such as an embodiment in which a local free block list is utilized instead of the global free block list. Referring again to <FIG>, the key management system (not shown) of the host system <NUM> may determine how frequently to purge the special partition based on the number of lifetime erase cycles of which the flash storage medium <NUM> (<FIG>) is capable and the total number of purge operations that the special partition has undergone. The flash memory device <NUM> may include a purge counter <NUM>. The controller <NUM> may increment the purge counter <NUM> each time the controller <NUM> performs a purge operation on the special partition. In response to a local purge command received from the host system <NUM>, the controller <NUM> may not only perform the purge operation but also return the purge count or value in the purge counter <NUM> to the host system <NUM>. Based on that purge count (or the purge count in combination with other information, such as the number of lifetime erase cycles of which the flash memory device is capable) the key management system may determine when to initiate the next purge operation.

As illustrated in <FIG>, exemplary embodiments of systems and methods for purging data from a memory device may be provided in a portable computing device ("PCD") <NUM>. For purposes of clarity, data buses or other data communication interconnects are not shown in <FIG>. Some exemplary interconnections, some of which may represent communication via such buses or interconnects, are described for context. Nevertheless, it should be understood that, more generally, various elements described below may communicate with each other via one or more buses or system interconnects.

The PCD <NUM> may include an SoC <NUM>. The SoC <NUM> may include a CPU <NUM>, a GPU <NUM>, a DSP <NUM>, an analog signal processor <NUM>, or other processors. The CPU <NUM> may include multiple cores, such as a first core 704A, a second core 704B, etc., through an Nth core 704N.

A display controller <NUM> and a touch-screen controller <NUM> may be coupled to the CPU <NUM>. A touchscreen display <NUM> external to the SoC <NUM> may be coupled to the display controller <NUM> and the touch-screen controller <NUM>. The PCD <NUM> may further include a video decoder <NUM> coupled to the CPU <NUM>. A video amplifier <NUM> may be coupled to the video decoder <NUM> and the touchscreen display <NUM>. A video port <NUM> may be coupled to the video amplifier <NUM>. A universal serial bus ("USB") controller <NUM> may also be coupled to CPU <NUM>, and a USB port <NUM> may be coupled to the USB controller <NUM>. A subscriber identity module ("SIM") card <NUM> may also be coupled to the CPU <NUM>.

One or more memories may be coupled to the CPU <NUM>. The one or more memories may include both volatile and non-volatile memories. Examples of volatile memories include static random access memory ("SRAM") <NUM> and dynamic RAMs ("DRAM"s) <NUM> and <NUM>. Such memories may be external to the SoC <NUM>, such as the DRAM <NUM>, or internal to the SoC <NUM>, such as the DRAM <NUM>. A DRAM controller <NUM> coupled to the CPU <NUM> may control the writing of data to, and reading of data from, the DRAMs <NUM> and <NUM>. In other embodiments, such a DRAM controller may be included within a processor, such as the CPU <NUM>.

The PCD <NUM> may include a flash memory device <NUM>, such as a chip that is coupled to the SoC <NUM>. The flash memory device <NUM> may be coupled to the CPU <NUM> via, for example, an input/output ("I/O") interface <NUM>. The I/O interface <NUM> may comprise a bus, such as, for example, a peripheral component interconnect express ("PCIe") bus, or any other type of interconnection with the CPU <NUM>. The flash memory device <NUM> may be an example of the flash memory device <NUM> described above with regard to <FIG>. Although in this embodiment the flash memory device <NUM> includes the controller <NUM> (<FIG>), in other embodiments such a controller may be included in the SoC. The CPU <NUM> and related components may be configured to provide the host system functions described above.

A stereo audio CODEC <NUM> may be coupled to the analog signal processor <NUM>. Further, an audio amplifier <NUM> may be coupled to the stereo audio CODEC <NUM>. First and second stereo speakers <NUM> and <NUM>, respectively, may be coupled to the audio amplifier <NUM>. In addition, a microphone amplifier <NUM> may be coupled to the stereo audio CODEC <NUM>, and a microphone <NUM> may be coupled to the microphone amplifier <NUM>. A frequency modulation ("FM") radio tuner <NUM> may be coupled to the stereo audio CODEC <NUM>. An FM antenna <NUM> may be coupled to the FM radio tuner <NUM>. Further, stereo headphones <NUM> may be coupled to the stereo audio CODEC <NUM>. Other devices that may be coupled to the CPU <NUM> include one or more digital (e.g., CCD or CMOS) cameras <NUM>.

A modem or RF transceiver <NUM> may be coupled to the analog signal processor <NUM> and the CPU <NUM>. An RF switch <NUM> may be coupled to the RF transceiver <NUM> and an RF antenna <NUM>. In addition, a keypad <NUM>, a mono headset with a microphone <NUM>, and a vibrator device <NUM> may be coupled to the analog signal processor <NUM>.

The SoC <NUM> may have one or more internal or on-chip thermal sensors 770A and may be coupled to one or more external or off-chip thermal sensors 770B. An analog-to-digital converter ("ADC") controller <NUM> may convert voltage drops produced by the thermal sensors 770A and 770B to digital signals. A power supply <NUM> and a power management integrated circuit ("PMIC") <NUM> may supply power to the SoC <NUM>.

Firmware or software may be stored in any of the above-described memories, such as DRAM <NUM> or <NUM>, SRAM <NUM>, etc., or may be stored in a local memory directly accessible by the processor hardware on which the software or firmware executes. Execution of such firmware or software may control aspects of any of the above-described methods or configure aspects any of the above-described systems. Any such memory or other non-transitory storage medium having firmware or software stored therein in computer-readable form for execution by processor hardware may be an example of a "computer-readable medium," as the term is understood in the patent lexicon.

Claim 1:
A method (<NUM>) for purging data from a memory device, comprising:
de-mapping (<NUM>) logical memory blocks from physical memory blocks of a first storage partition of a plurality of storage partitions of the memory device;
listing (<NUM>) de-mapped physical memory blocks of the first storage partition in a local de-mapped block list uniquely associated with the first storage partition;
receiving (<NUM>) a local purge command from a host device;
purging (<NUM>) at least a portion of the de-mapped physical memory blocks listed only in the local de-mapped block list in response to the local purge command; and
further comprising:
forming a plurality of units of encrypted data using a corresponding plurality of keys;
storing key information associated with the plurality of keys in the first storage partition; and
storing the plurality of units of encrypted data in a second storage partition of the plurality of storage partitions;
wherein de-mapping logical memory blocks from physical memory blocks of the first storage partition comprises de-mapping logical memory blocks associated with the plurality of keys from physical memory blocks storing the key information;
wherein purging the de-mapped physical memory blocks listed in the local de-mapped block list comprises purging physical memory blocks storing the key information;
wherein a global de-mapped block list and a global free block list are associated with the plurality of storage partitions other than the first storage partition, and further comprising receiving a global purge command from the host device and purging all de-mapped physical memory blocks listed in the global-de-mapped block list in response to the global purge command; and
wherein purging refers to physically eliminating data from a memory in a way that prevents the data from being retrieved.