Patent Description:
As the functionality of host devices increases, and as users create more user data (e.g., downloaded apps, images, messages, etc.), the memory device is being tasked with storing more data. Thus, accurate reflection of the storage capacity and other characteristics of the memory device have an added importance to a user of a host device, and to the memory device itself (e.g., for optimal performance). For example, a user may want a memory device storing <NUM> gigabytes (GB) (e.g., a 64GB SDXC card for the user's mobile phone) instead of a memory device storing 16GB (e.g., a 16GB SDHC card).

Recently, counterfeiters have been modifying information stored in a memory device so the memory capacity is not accurately reflected when the information is accessed and read out from the memory device. Also, other information stored in a memory device may not match actual characteristics of the memory device preventing the memory device from operating in an optimum manner. For instance, partition information of a 16GB memory device may be modified so that it falsely appears as a 64GB memory device to a host. Consequently, this partition information can be modified information that is incorrect or inaccurate. That is, the memory device may actually be a lower density card (e.g., a 16GB SDHC card) that has been modified by a counterfeiter to look like higher density card (e.g., a 64GB SDXC card). In another example, a start of an actual data area of a partition may not be within a proper block boundary.

In some instances, a customer may pay a purchase price for a memory device that appears to be able to store a larger amount of data (e.g., 64GB) when the memory device actually is only able to store a smaller amount of data (e.g. 16GB). The customer is eventually disappointed in the performance of the memory device based on the inaccurate and false information. For instance, the customer may realize that the
memory device is unable to write data to an address which exceeds the actual density of the memory device. Or the customer may realize that the memory device is corrupted when data is written to an address which exceeds the actual density of the memory device.

<CIT> discloses a method for adaptively adjusting a user storage region in an entire storage region of a nonvolatile memory system. The method includes a host transmitting a user region information request command to the nonvolatile memory system, the nonvolatile memory system transmitting user region information to the host, the host changing the user region information, the host transmitting a user region information setting command to the nonvolatile memory system, and the nonvolatile memory system controlling a size of the user storage region in response to the user region information setting command.

<CIT> discloses a security system for a flash memory. The method of security system for a flash memory, includes the steps of a) providing a predetermined limit signal for a host system; b) defining a specific signal stored in the flash memory installed with a identification program for indicating a capacity of the flash memory; c) comparing the specific signal with the predetermined limit signal while the flash memory is connected to the host system; and d) inhibiting access to the identification program of the flash memory if the specific signal does not correspond to the predetermined limit signal.

<CIT> discloses a storage apparatus including a memory unit and a controller to set up a memory space of the memory unit as a user data space and a spare space according to a signal representing at least one of the user data space and spare space.

The Figures depict embodiments and/or examples of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative implementations and/or alternative examples of the structures and methods illustrated herein can be employed without departing from the principles described herein.

The following description is presented to enable a person of ordinary skill in the art to make and use the various implementations. Descriptions of specific devices, techniques, and applications are provided as examples. Various modifications to the examples described herein may be readily apparent to those of ordinary skill in the art, and the general principles defined herein may be applied to other examples without departing from the scope of the various implementations. Thus, the various implementations are not intended to be limited to the examples described herein, but are to be accorded the scope consistent with the claims.

The present disclosure describes techniques to ensure that an action (e.g., a read or a write by a host device, etc.) associated with an element of a memory device that stores a value is valid compared to a reference value (e.g., results in a valid outcome). The reference value is associated with an actual characteristic of the memory device (e.g., a size or an amount of a memory capacity, a size or an amount of a primary partition capacity, etc.). In at least one implementation, the element storing the value is stored in a region of the memory that is used for storing metadata (e.g., partitioning metadata, data related to system structures of the memory device, etc.). This region that includes the element is visible to the host device, and thus, the element can be read and re-programmed after the memory device is manufactured. Consequently, the value stored in the element can be modified by a host device (e.g., being controlled by a counterfeiter) so that it incorrectly or inaccurately reflects an actual characteristic of the memory device.

In contrast, the reference value is stored in a region of memory (e.g., associated with a register, a descriptor, an attribute, a flag, etc.) containing settings that may be read but (i) cannot be re-programmed after the memory device is manufactured (e.g., the setting is one-time programmable), (ii) can only be re-programmed or altered in control of the memory device and not in control of a host device (e.g., a dynamic capacity adjustment initiated and controlled by the memory device), or (iii) require authentication of a host device if reference values stored therein are to be modified. This region of the memory device that includes the reference values may or may not be visible to the host device. In various examples, the reference value can only be programmed by a manufacturer of the memory device during a manufacturing stage, and therefore, the reference value cannot be modified by a host device after the memory device is manufactured. Accordingly, the reference value is a true value that correctly and accurately reflects an actual characteristic of the memory device.

In various examples, a "write" action associated with an element that stores a value is valid if the value to be written to the element (e.g., by a host device), if the value eventually written to the element (e.g. by the memory controller), or if a value that remains stored in the element, is valid compared to a reference value. In various examples, a "read" action associated with an element that stores a value is valid if the value being read from the element is valid compared to a reference value or if a valid value is being delivered to the host device based on a reference value.

In one implementation, the reference value may be associated with a memory capacity of the memory device. For example, a secure digital (SD) card that comprises a set of CSD registers which can include a specific C_SIZE register that stores a reference value that reflects, or is useable to derive, the actual memory capacity of the SD card (e.g., a size of a Master Boot Record (MBR) primary partition within the single physical partition of the SD card). Accordingly, the SD card can use the reference value stored in the C_SIZE register to ensure that a capacity value written, by a host device, to an area of the SD card (e.g., the "element" further discussed herein that can be located in the partition metadata region) other than the C_SIZE register is valid (e.g., via a comparison of the written value to the reference value stored in the C_SIZE register). The SD card can also use the reference value stored in the C_SIZE register to derive (e.g., calculate) a derived reference value and to ensure that a capacity value read, by a host device, from an area of the SD card other than the C_SIZE register is valid. For instance, the derived reference value can be the reference value stored in the C_SIZE register (e.g., a size of the single physical partition of the SD card) minus a size of the partition metadata region. In this case regarding memory capacity, the written value or the read value, as well as an action associated therewith, is valid if it is less than or equal to the reference value or the derived reference value, but not if it exceeds the reference value or the derived reference value.

Consequently, the techniques discussed herein establish a link between (i) a reference value stored in one region of memory that cannot be re-programmed, that can only be re-programmed or altered in control of the memory device, or that requires authentication to be re-programmed and (ii) a relative value currently stored in another region of the memory that can be re-programmed (e.g., without authentication). The techniques use the established link to ensure that an action (e.g., a read or a write by a host device) related to the relative value is valid.

<FIG> illustrates an example environment <NUM> in which the present disclosure can be implemented. For instance, in the example environment <NUM>, a memory device <NUM> is configured to ensure that an action associated with an element storing a value is valid compared to a reference value. The action can be implemented by, or in accordance with, a host device <NUM>. For example, the action can be associated with a read or a write by the host device <NUM>.

A host device <NUM> can comprise a smartphone device, a wearable device (e.g., a watch, a pair of glasses, a heart rate monitoring device, etc.), a laptop computer, a tablet device, an image capture device (e.g., a camera, a video recording device, etc.), a netbook device, a gaming console device, a personal computing device (e.g., a desktop computer), a server device, a set top box device, a home device (e.g., an appliance device, a thermostat device, a garage door device, etc.), or any other electronic device that may require storage by a memory device that is connected, or coupled, to the host device. In some examples, the host device <NUM> can include a display (e.g., a touch display), a bus that connects the display to a processor, and/or a graphics subsystem that handles the display of graphics and text on the display. The host device <NUM> can also contain one or more of: host system memory such as dynamic random-access memory (DRAM), sensors (e.g., accelerometers, gyroscope, GPS, etc.), input/output components (I/O) (e.g., a speaker, a microphone, or a keyboard), and communications interface(s) (e.g., Cellular, USB, Wi-Fi, Bluetooth, or other wired or wireless interfaces).

In various implementations, the memory device <NUM> can be contained within a package, e.g., a ball grid array (BGA) package that is designed to be mounted on a printed circuit board. For instance, the memory device <NUM> can be an embedded MultiMediaCard (eMMC) or a Universal Flash Storage (UFS) module. Alternatively, the memory device <NUM> can be contained within a removable card (e.g., a SD card) that fits within a slot on the host device <NUM>, within a semi-removable device such as a solid-state device (SSD) module, or within a PC/server card/module (e.g., a Peripheral Component Interconnect Express (PCIe) card). Additionally, the memory device <NUM> can be one self-contained device or can be implemented as a collection of interconnected devices.

The memory device <NUM> includes a controller <NUM> (e.g., a memory controller). The controller <NUM> is configured to communicate, in accordance with a read and/or a write request, data between memory (e.g., storage) of the memory device <NUM> (e.g., often times referred to as mass storage, non-volatile memory, or mass memory) and the host device <NUM>. In various implementations, the controller <NUM> can include control circuit(s) for controlling the operation of the controller <NUM>, random access memory (RAM) for storing operating information and/or for providing temporary storage within the memory device <NUM>, clock generation circuit(s) for generating internal clocking signals, receiver circuit(s) for receiving data and/or commands from a host device <NUM> (e.g., a host controller or other processing unit of a host device), and/or transmitter circuit(s) for transmitting data and/or status information to the host device <NUM> (e.g., the host controller). Moreover, the controller <NUM> can be connected to the memory of the memory device <NUM> through at least one bus, which allows the controller <NUM> to communicate with the memory, such as read data from, and write data to, the memory. In various examples, storage can be implemented with a non-volatile memory such as a NAND flash memory having memory circuits and memory cells (e.g., NAND cells), each capable of storing one bit (single-level cell) or multiple bits (multi-level cell) of data. Other forms of non-volatile memory can also be used without departing from the present disclosure. For example, non-volatile memory can include phase change memory (PCM), magneto-resistive random-access memory (MRAM), resistive random-access memory (RRAM), ferroelectric random-access memory (FRAM), and so forth.

The memory of the memory device <NUM> can comprise address space that is visible to the host device <NUM>. The visible address space may be considered as physical address space (e.g., the host has access to physical addresses of the non-volatile memory like NAND flash) or it may be considered as logical address space (e.g., the flash management function of a Managed NAND memory device converts the addresses received from the host to physical addresses of the non-volatile memory by using a logical-to-physical mapping table). For example, the address space can include one or multiple portions of memory. In some examples, portion(s) of memory can include MBR primary partition(s), GUID Partition Table (GPT) partition(s), physical partition(s) (e.g., general purpose partitions as defined in the eMMC standard), or logical unit(s) (LUs) (e.g., as defined in UFS standard). As discussed above, the memory (e.g., storage) of the memory device <NUM> can be divided into regions, where a region can be: (i) a designated area within an individual portion of memory (e.g., part of an MBR primary partition, a GPT partition, a physical partition, or an LU), (ii) a portion of memory (e.g., a region comprises a MBR primary partition, a GPT partition, a physical partition, or an LU), or (iii) one or more registers, descriptors, attributes, flags, etc. For instance, the first region and the second region, as further discussed herein with respect to <FIG>, can be part of a single portion of a memory (e.g., an SD card with only a single physical partition that includes a first region for the Master Boot Record and a second region including the MBR primary partition). Or the first region and the second region can each comprise a separate portion of a memory (e.g., the metadata is stored in a first partition and the user data is stored in a second partition).

Accordingly, <FIG> illustrates a first region of memory <NUM> that is used to store metadata <NUM>. The metadata <NUM> includes data related to how the host device <NUM> has arranged data in the memory device <NUM>. Accordingly, the metadata <NUM> can be used (e.g., assessed) internally by the controller <NUM> of the memory device <NUM> (e.g., in accordance with a read or a write initiated by the host device <NUM>). In various implementations, the metadata <NUM> can include partitioning information for the memory device <NUM>, such as a Master Boot Record (MBR), a GUID Partition Table (GPT), or a Volume Boot Record (VBR). The MBR contains information regarding how an MBR primary partition is organized (e.g., located) on the memory of the memory device <NUM>. The MBR can also contain executable code to function as a loader for an operating system installed on the host device <NUM>. The GPT comprises a standard for the layout of a partition table using globally unique identifiers (GUID). The VBR contains code for bootstrapping programs (e.g., an operating system) stored in other parts of the memory device (e.g., the second region of memory discussed herein with respect to <FIG>).

The metadata <NUM> stored in the first region of memory <NUM> can include one or more elements <NUM>, where an individual element <NUM> is designated to store a value indicative of a characteristic <NUM> of the memory device <NUM>. A characteristic <NUM> can be associated with a portion of memory or a region of memory. An individual element <NUM> can be assigned a particular address so that it can be identified by the host device <NUM> in association with a read or a write request. In one example, an individual element <NUM> can comprise a field (e.g., a four-byte field) that is accessible by the host device <NUM> via a known address and that indicates: a first address of a portion or a region of memory in the memory device, a last address of a portion or a region of memory in the memory device, a size (or length) of a portion or a region of memory in the memory device. As discussed above, the value(s) indicative of characteristic(s) <NUM> that are stored in the element(s) <NUM> can be re-programmed, and thus, the element(s) <NUM> are susceptible to modification by counterfeiters who want the memory device <NUM> to incorrectly or inaccurately reflect its characteristics and/or capabilities (e.g., memory capacity). For instance, reflection of an incorrect or an inaccurate value of a characteristic <NUM> can be associated with an action by the host device, such as a read request or a write request.

A second region of memory <NUM> can store, for example, user data <NUM>. As discussed above, the second region of memory <NUM> can comprise, or be part of, one or more portions of memory (e.g., a primary partition, a physical partition, a LU, etc.) for storing user data <NUM> including downloaded apps, images (e.g., pictures, photos, videos, etc.), music, sensor data, etc. In various implementations, the second region of memory <NUM> can also store host data associated with, for example, an operating system. In some examples (e.g., an SD card), the second region of memory <NUM> can store file system architecture such as Partition Boot Sector, File Allocation Table(s) (FATs), and/or Root Directory. As illustrated in <FIG> by the dotted line and as further discussed herein, the value(s) indicative of characteristic(s) <NUM> can correspond to characteristics of the second region of memory <NUM>.

A third region of memory <NUM> maintains settings <NUM>, where an individual setting <NUM> stores a reference value associated with an actual characteristic <NUM> of the memory device <NUM>. As discussed above, a reference value stored in an individual setting <NUM> is a correct and an accurate (e.g., a true or an optimum) value because the third region of memory <NUM> is programmed by a manufacturer of the memory device <NUM> during a manufacturing stage. In various implementations, a setting <NUM> in the third region of memory <NUM> may be protected such that a reference value stored therein is prohibited from subsequently being re-programmed by the host device <NUM>. Thus, the third region of memory <NUM> can contain settings storing values that cannot be modified by the host device <NUM> after the memory device <NUM> is manufactured and deployed. In an alternative implementation, a setting <NUM> in the third region of memory <NUM> can be protected such that a reference value stored therein can be subsequently re-programmed by the host device <NUM>, but only if the host device <NUM> is authenticated (e.g., the host device is authorized to modify a reference value stored in the setting <NUM>). In yet another alternative implementation, the reference value can be re-programmed under control of the memory device (e.g., in association with mutual handshake with the host device).

Accordingly, the third region of memory <NUM> can comprise a set of hardware registers, descriptors, attributes, or flags (e.g., CSD registers in an SD card), that stores actual information about the capabilities of the memory device <NUM>. The actual characteristic(s) <NUM> represented by the reference value(s) can be associated with one or more of: a total capacity of the memory device, a capacity of a region of the memory (e.g., the second region of memory <NUM>), a capacity of the first region of memory <NUM> and the second region of memory <NUM> combined, a capacity of an individual portion of the memory (e.g., a primary partition, a physical partition, etc.), a start address of an individual portion or an individual region of the memory, an alignment of start addresses of individual portion(s) and/or individual region(s) of the memory (e.g., favorable address boundary), a size of an allocation unit of a portion of the memory, maximum and/or default latencies of the memory device, current consumption values of the memory device, etc. The techniques described herein ensure this information represented by the actual characteristics <NUM> is not distorted so that the memory device is prevented from conveying false information that is outside of its actual operational boundaries (e.g., prevented from conveying re-programmed information that pretends the memory device is something that it is not). The techniques can also ensure more optimized (e.g., higher performance, longer lifetime, etc.) operation of the memory device <NUM>.

Therefore, the techniques discussed herein create a link between the elements <NUM> of the first region of memory <NUM> and the settings <NUM> of the third region of memory <NUM> (e.g., a link between a relative value currently stored in an element and a reference value stored in a setting). As referenced by <NUM>, the controller <NUM> of the memory device <NUM> can assess (e.g., access, read, etc.) the reference value(s) associated with the actual characteristic <NUM>, as stored in a setting(s) <NUM> of the third region of memory <NUM>, to ensure that an action associated with an element <NUM> storing a relative value indicative of the same characteristic <NUM> is valid, or to ensure that the value that remains in the element is valid. The controller <NUM> of the memory device <NUM> can also and/or alternatively derive a derived reference value from a reference value stored in a setting <NUM>. As referenced by <NUM>, the action can be initiated by the host device <NUM>, such as a read or a write request. The action can be invalid if the value read from, or written to, an element <NUM> of the first region of memory <NUM> is an incorrect or an inaccurate value, as referenced by <NUM>. For instance, an action can be invalid if it reads or writes a value indicating that the capacity of a primary partition of an SD card is (close to) 64GB when the actual memory capacity of the SD card is 16GB. Consequently, the techniques described herein assess a reference value or a derived reference value to ensure that a correct or an accurate value is read from, or written to, an element <NUM>, as referenced by <NUM>. In such a case, the action can be considered valid.

In various implementations, a value read from, or written to, an element <NUM> does not necessarily have to match a reference value or a derived reference value in order to be correct and in order for the action to be valid. For example, the host device <NUM> can perform a valid action by writing a capacity (e.g., a primary partition capacity, a physical partition capacity, etc.) value to an element <NUM> that is less than a corresponding capacity stored in a setting <NUM> (e.g., the host device <NUM> programs a value to indicate a primary partition capacity of 12GB when the reference value or the derived reference value indicates a capacity of, or close to, 16GB). However, the host device <NUM> performs an invalid action by writing a primary partition capacity value to an element <NUM> that is more than a corresponding capacity stored in a setting <NUM> (e.g., the host device <NUM> programs a value to indicate a primary partition capacity of (close to) 64GB when the reference value indicates a capacity of (close to) 16GB).

In various implementations and due to different formats between information stored in the setting(s) <NUM> and information stored in the element(s) <NUM>, the controller <NUM> can implement a conversion between differing formats. For instance, the controller <NUM> can convert the reference value or the derived reference value from a first format to a second format in accordance with an assessment. In one example, the memory capacity of an SD card (in Bytes) is calculated by the formula as follows: <MAT> In the case that MBR information being stored in the element <NUM> includes a start address and a size of a primary partition, the size can be indicated as a number of <NUM> Byte sectors. Thus, the following conversion for proper comparison can be made - the access is valid if: <MAT>.

In at least one implementation, a file system area (e.g., FATs) of a primary partition can be part of the first region of memory <NUM>, and the file system area can contain an element <NUM> related to an actual characteristic of the actual data area of the primary partition, where the actual data area comprises, or is part of, the second region of memory <NUM>.

<FIG> illustrates additional details of the memory device <NUM> in which reference values are stored in one region of the memory (e.g., the third region of memory <NUM>) while the elements <NUM> storing the values that are visible (e.g., accessible by) the host device <NUM> are stored in a different region of the memory that can be re-programmed (e.g., the first region of the memory <NUM>). In alternative implementations, the third region of memory <NUM> can be located: in a flash memory (e.g., NAND) of the memory device <NUM>, in an embedded non-volatile memory of the controller <NUM> (e.g., MRAM, flash, etc.), in ROM of the controller <NUM>, in RAM embedded in or connected to the controller <NUM> (e.g., SRAM or DRAM), or in any combination of these (e.g., stored permanently in a flash memory but cached in RAM).

As illustrated in <FIG>, the first region of the memory <NUM> and the second region of the memory <NUM> may be associated with one or more memory portions <NUM>(<NUM>). <NUM>(N) (where N is an integer number). As discussed, a memory portion <NUM>(<NUM>). <NUM>(N) can comprise a primary partition, a physical partition, or a logical unit (LU). In various examples, a memory portion <NUM>(<NUM>). <NUM>(N) can be divided into blocks, which can further be divided into pages. Accordingly, a memory of the memory device <NUM> can include a plurality of addressable memory locations. An addressable memory location can comprise, and identify, at least part of a memory portion <NUM>(<NUM>). <NUM>(N), such as a memory block, a memory page, a sector, a byte of memory, and so forth. An address can be a logical address or a physical address.

<FIG> further illustrates examples of the actual characteristic(s) <NUM> represented by the reference value(s) stored in the settings <NUM> of <FIG>. As discussed above, to protect the integrity of the reference values so they correctly and accurately reflect operational parameters and/or boundaries of the memory device, a setting <NUM> can be a one-time programmable setting so that it cannot be re-programmed (e.g., modified) after a manufacturer of the memory device initially programs the reference value. Alternatively, programming of a setting <NUM> can be associated with authentication to ensure that modification of the reference value stored therein only occurs in appropriate situations. Even further, programming of a setting <NUM> can be implemented under control of the memory device, but not under control of a host device (e.g., a dynamic capacity adjustment initiated and controlled by the memory device in association with a handshake between the memory device and the host device). In some instances, the setting <NUM> can be configured so that it prohibits modification of a reference value that is outside the known operational boundaries of the memory device. For example, a setting storing a reference value representative of a memory capacity can allow the reference value to be reduced to allocate additional reserve memory, but the setting may prohibit the reference value from being increased. Here, a reduction of memory capacity is still within the operational boundaries of the memory device but there is a chance that an increase in memory capacity may cause the reference value to exceed an operational boundary, and thus, the increase will not be allowed (to prevent counterfeit acts).

In one example, an actual characteristic can represent a total capacity <NUM> of memory in the memory device <NUM>. In one implementation, the total capacity <NUM> can reflect a combination of the first region of memory <NUM> and the second region of memory <NUM>. In some instances, the total capacity <NUM> represents an effective density of a memory device (e.g., a 64GB SD card may have an effective density of 62GB, a 16GB SD card may have an effective density of 15GB, etc.). The effective density of a memory device may be less than an overall total amount of memory due to creation and management of reserve memory (e.g., replacement blocks that are called upon in response to a failed block), storage of memory controller firmware, storage of register space, etc. In some implementations, the total capacity <NUM> is a dynamically configurable setting, in which the reference value can be modified in response to handshaking between a host device <NUM> and the memory device <NUM>. Thus, the total capacity <NUM> can be reduced to allocate new reserve memory blocks if previously reserved memory blocks were called upon in response to failures or errors. In eMMC, the controller <NUM> can be configured to implement a "Dynamic Capacity" feature that enables a host device to dynamically reduce the density provided by the memory device (e.g., the memory device releases blocks of memory from the second region of memory).

In another example, an actual characteristic can represent a capacity of an individual portion <NUM> of the memory (e.g., a primary partition, a physical partition) or an individual region of the memory (e.g., one or more portions, a part of a portion, etc.). Therefore, each portion of the memory may be associated with one or more individual settings and one or more individual elements storing corresponding values.

In yet another example, an actual characteristic can represent a start address of an individual portion or an individual region <NUM> of the memory.

In a further example, an actual characteristic can represent an alignment of start addresses of individual portion(s) and/or individual region(s) <NUM> of the memory. Aligning with memory page sizes and/or memory block sizes improves performance of the memory device and extends a life of the memory device.

In even a further example, an actual characteristic can represent a size of an allocation unit of an individual portion <NUM> of the memory. Aligning the size the cluster used by the host file system with the allocation unit by the memory device improves the performance of the memory device.

The example processes described herein in <FIG> are illustrated as logical flow graphs, which represent a sequence of operations that can be implemented in hardware, software, or a combination thereof. The operations may represent executable instructions that, when executed by one or more processors, perform the recited operations. Executable instructions may include routines, programs, objects, components, modules, data structures, and the like that perform particular functions. The order in which the operations are depicted in <FIG> is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and/or in parallel to implement the process. The executable instructions may be stored on non-transitory computer storage media including volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a host device or by a memory device.

<FIG> illustrates an example process <NUM> that monitors for an occurrence of an action associated with an element storing a value and that ensures that the action is valid. The example process <NUM> can be implemented by a memory device <NUM> (e.g., the controller <NUM> of the memory device <NUM>) in the context of <FIG> and/or <FIG>.

At <NUM>, a memory device monitors for an occurrence of an action associated with an element (or elements) that individually store a value indicative of a characteristic related to the memory device, the memory of the memory device or operation of the memory device. As discussed above, the action can be a read request from a host device or a write request from the host device. In various implementations, the element that stores the value is stored in a region of the memory (e.g., the first region of memory <NUM> in <FIG> and <FIG>) that is used for storing metadata <NUM> (e.g., partitioning metadata, data related to system structures of the memory device, etc.). The element can be associated with a known address that is visible to the host device. Consequently, a value currently stored in the element can be modified by the host device (e.g., can be controlled by a counterfeiter) so that it incorrectly or inaccurately reflects an actual characteristic of the memory device.

At <NUM>, the memory device determines whether the action associated with the element is valid compared to a reference value associated with an actual characteristic. In various implementations, the reference value is stored in a setting located in a region of memory (e.g., the third region of memory <NUM> in <FIG> and <FIG>) that is separate from the region of memory in which the element is located. The setting located in this region of memory can comprise a register, a descriptor, an attribute, a flag, etc. In this region of memory, the reference value can be read but the reference value (i) cannot be re-programmed after the memory device is manufactured (e.g., the setting is one-time programmable), (ii) can only be re-programmed or altered in control of the memory device and not in control of a host device (e.g., a dynamic capacity adjustment initiated and controlled by the memory device), or (iii) can require authentication of a host device if the reference value is to be modified. Accordingly, the reference value is a true value that correctly and accurately reflects an actual characteristic of the memory device.

In various examples, an action associated with an element that stores a value is valid if the value to be written to the element (e.g., by a host device), if the value eventually written to the element (e.g. by the memory controller), or if a value that remains stored in the element, is valid compared to a reference value (e.g., is less than the reference value). In various examples, an action associated with an element that stores a value is valid if the value being read from the element is valid compared to a reference value or if a valid value is being delivered to the host device based on a reference value.

At <NUM>, the memory device implements a corrective action if the action associated with the element is determined to be invalid. For instance, the corrective action may prevent (i) a value currently stored in the element from being read out from the element or (ii) an updated value received from a host device from being written to the element if the updated value is an invalid value (e.g., the updated value represents a capacity that exceed a capacity represented by the reference value). Otherwise (if the action associated with the element is determined to be valid), the memory device completes the action. For instance, the memory device returns the current value stored in the element in response to a read request or the memory device writes the updated value to the element in response to a write request (e.g., the updated value written replaces the current value stored in the element).

<FIG> illustrates an example process <NUM> that assesses a reference value, or a derived reference value, to ensure that a write action associated with an element storing a value is valid. The example process <NUM> can be implemented by a memory device <NUM> (e.g., the controller <NUM> of the memory device <NUM>) in the context of <FIG> and/or <FIG>.

At <NUM>, the memory device determines an occurrence of a request to write an updated element value to an element that stores a current element value. For instance, the request may be initiated by a host device attempting to write, to the metadata <NUM> of the first region of memory <NUM>, a new value indicative of a capacity of the memory device.

At <NUM>, the memory device assesses a reference value. As discussed above, the reference value is stored in a setting that corresponds to the element in which the current element value is stored, and thus, the reference value is related to the current element value. The setting is located in a region of the memory that is separate from where the element is stored. Accordingly, the memory device can access the reference value in this separate region. The reference value can reflect a total capacity of the memory device, a capacity of an individual portion of memory, a start address of a portion or region of memory, etc..

In some implementations, at <NUM>, the memory device can determine a derived reference value. For example, to determine a capacity of a primary partition within a physical partition, the memory device subtracts the amount of memory used to store the metadata <NUM> within the physical partition (e.g., a size of the first region of memory <NUM>) from the capacity of the physical partition (e.g., as indicated by the reference value). Thus, the derived reference value can be derived (e.g., calculated) by subtracting a size of the first region of memory from a size of a capacity of a portion of memory in the memory device (e.g., a physical partition).

In another example, to determine a capacity of a particular primary partition of multiple primary partitions (e.g., at least two) within a physical partition, the memory device subtracts both (i) the amount of memory used to store the metadata <NUM> within the physical partition (e.g., a size of the first region of memory <NUM>) and (ii) the size of other primary partitions within the physical partition, from the capacity of the physical partition (e.g., as indicated by the reference value). Thus, the derived reference value for the particular primary partition can be derived (e.g., calculated) by subtracting both a size of the first region of memory and a size of other primary partitions within the physical partition, from a size of the capacity of the physical partition.

In various implementations, the physical partition described in either of the two preceding paragraphs may be one of multiple physical partitions that comprise the memory of the memory device. After deriving the derived reference value, the process moves to <NUM>.

Alternatively, the operation associated with <NUM> can be skipped (e.g., as illustrated by the arrow around <NUM>) in instances where the reference value does not need to be derived prior to a comparison (e.g., the reference value stored in a setting is already a result of a subtraction of a size of the first region of memory from the capacity of a portion of memory in the memory device).

At decision <NUM>, the memory device determines whether the updated element value from the request exceeds the reference value or the derived reference value (e.g., indicating that the host device is attempting to write a value that is outside the operational boundaries of the memory device or the host device is attempting to write a value that is not optimum for operation of the memory device). For instance, the determination can be made based on a comparison.

If the answer at decision <NUM> is "No", then the process moves to <NUM> where the memory device allows the updated element value to be written to the element in response to receiving the request to write from the host (e.g., the action is valid and/or the updated element value to be written is valid).

In a first example, if the answer at decision <NUM> is "Yes", then the process moves to <NUM> where the memory device prevents the updated element value from being written to the element (i.e., the action is invalid because, for example, the host device is trying to write a counterfeit value to the metadata - ~<NUM> GB for the capacity of a primary partition instead of the actual ~<NUM> GB of capacity of the primary partition). In some instances, at <NUM>, the memory device can optionally write the reference value or the derived reference value to the element instead of writing the updated element value received from the host device in association with the write request. In some instances, a valid value may pre-exist in the element, and thus, the valid value does not need to be updated at all.

In a second example, if the answer at decision <NUM> is "Yes", then the process moves to <NUM> where the memory device allows the updated element value to be written to the element even though the action has been determined to be invalid and/or the updated element value has been determined to be invalid. However, at <NUM>, the memory device may internally flag the element so that a corrective action is associated with any reading of the current value stored in the flagged element (e.g., the current value being a counterfeit value based on the updated element value written by the host device). For example, when an attempt to read from the flagged element occurs, the memory device does not provide the counterfeit value (e.g., the invalid value) currently stored in the flagged element, but rather, the memory device implements a corrective action to protect the integrity of the memory device (e.g., the memory device may access and provide a corresponding reference value or a derived reference value during a read phase).

<FIG> illustrates an example process <NUM> that assesses a reference value, or a derived reference value, to ensure that a read action associated with an element storing a value is valid. The example process <NUM> can be implemented by a memory device <NUM> (e.g., the controller <NUM> of the memory device <NUM>) in the context of <FIG> and/or <FIG>.

At <NUM>, the memory device determines an occurrence of a request to read a current element value (currently) stored in an element. For instance, the request may be initiated by a host device attempting to read information (e.g., a capacity of a primary partition of the memory device) from the metadata <NUM> of the first region of memory <NUM>.

In some implementations, at <NUM>, the memory device can determine a derived reference value. For example, to determine the capacity for a primary partition within a physical partition, the memory device subtracts the amount of memory used to store the metadata <NUM> within the physical partition (e.g., a size of the first region of memory <NUM>) from the capacity of the physical partition (e.g., as indicated by the reference value). Thus, the derived reference value can be derived (e.g., calculated) by subtracting a size of the first region of memory from a size of a capacity of a portion of memory in the memory device (e.g., a physical partition).

At decision <NUM>, the memory device determines whether the current element value already stored in the element exceeds the reference value or the derived reference value (e.g., indicating that the host device is attempting to read a value that is outside the operational boundaries of the memory device). For instance, the determination can be made based on a comparison.

If the answer at decision <NUM> is "No", then the process moves to <NUM> where the memory device provides the current element value to the host device in response to receiving the request to read from the host (e.g., the action is valid and/or the current element value is valid).

If the answer at decision <NUM> is "Yes", then the process moves to <NUM> where the memory device prevents the current element value from being read out to the host device (e.g., the action and/or the current element value is invalid because, for example, the host device is reading a counterfeit value from the metadata - ~<NUM> GB for the capacity of a primary partition instead of the actual ~<NUM> GB of capacity of the primary partition).

At <NUM>, the memory device provides the reference value or the derived reference value to the host device instead of the current element value.

<FIG> illustrates example interactions implemented between a host device <NUM> and a memory device <NUM> to ensure that (i) a write action by the host device is valid or (ii) that a current value already stored in an element is valid. The example interactions of <FIG> can be implemented in the context of <FIG> and/or <FIG>.

<FIG> illustrates the first region of memory <NUM> (from <FIG>). The first region of memory <NUM> includes a first element <NUM> that stores a value, a second element <NUM> that stores a value, and a third element <NUM> that stores a value. While <FIG> shows three different elements, it is understood that the metadata <NUM> can include any number of elements that store values indicative of characteristics of the memory device.

At interaction <NUM>, the host device <NUM> requests to write an updated element value to element <NUM> and the memory device <NUM> receives the request to write the updated element value to element <NUM>.

At decision <NUM>, the memory device <NUM> determines if validation for an action associated with element <NUM> is enabled. For example, the memory device <NUM> can access a setting (e.g., a register, an attribute, etc.) in the third region of the memory <NUM> that indicates that validation associated with element <NUM> is enabled or disabled. The setting that indicates that validation is enabled or disabled can be separate from the setting that stores a reference value used to determine if the action associated with element <NUM> is valid or invalid.

If the answer to decision <NUM> is "No" (e.g., validation is disabled), then at <NUM>, the memory device <NUM> writes the updated element value received from the host device <NUM> to element <NUM> without validating the write request and/or the updated element value, and at interaction <NUM>, the memory device <NUM> returns a successful update acknowledgement to the host device <NUM>.

If the answer to decision <NUM> is "Yes" (e.g., validation is enabled), then at decision <NUM>, the memory device <NUM> determines if the updated element value received from the host device <NUM> and that is to be written to element <NUM> is valid. For example, the memory device <NUM> can implement the comparison associated with <NUM> in the example process <NUM> of <FIG>.

If the answer to decision <NUM> is "Yes", then at <NUM>, the memory device <NUM> writes the updated element value received from the host device <NUM>, and determined to be valid, to element <NUM> because the action is valid, and at interaction <NUM>, the memory device <NUM> returns a successful update acknowledgement to the host device <NUM>.

If the answer to decision <NUM> is "No", then at decision <NUM>, the memory device <NUM> determines whether automatic correction for the write/update is enabled (e.g., to correct the invalid action and the invalid updated element value). For example, the memory device <NUM> can access another setting (e.g., a register, an attribute, etc.) in the third region of the memory <NUM> that indicates whether automatic correction of an invalid action associated with element <NUM> is enabled or disabled. The setting that indicates that automatic correction is enabled or disabled can also be separate from the setting that stores a reference value used to determine if the action associated with element <NUM> is valid or invalid.

If the answer to decision <NUM> is "No", then at interaction <NUM>, the memory device <NUM> returns an unsuccessful update acknowledgement to the host device <NUM>, and the current value stored in element <NUM> is not updated because the write action has been determined to be invalid.

If the answer to decision <NUM> is "Yes", then at <NUM>, the memory device <NUM> determines a valid update value (e.g., a reference value or a derived reference value as discussed above). Then, at <NUM>, the memory device <NUM> writes the valid update value to element <NUM> instead of the updated element value received from the host device <NUM>, and at interaction <NUM>, the memory device <NUM> returns a successful update acknowledgement to the host device <NUM>.

<FIG> illustrates an example memory device (e.g., an SD card) in which the techniques described herein can be implemented. <FIG> illustrates a single physical partition <NUM> (e.g., the "Single Initial Physical Partition") that implements Master Boot Record (MBR) partitioning and a File Allocation Table (FAT) file system. In this example, the single physical partition includes ~62GB of memory space (e.g., may also be referred to as "user data area" in association with an SD card) that is visible to a host device and/or a user of the host device, for example, via address space <NUM><NUM> through F7FF FFFFh. The single physical partition <NUM> comprises a portion of memory as described above.

<FIG> also illustrates memory region <NUM> for registers (e.g., CSD, CID, SCR, SD Status, C_Size, AU_Size, etc.) and memory region <NUM> for reserved blocks, firmware (FW), digital rights management (DRM), etc. The memory region <NUM> may be associated with the third region of memory <NUM>, as described above with respect to <FIG>. The SD card illustrated in the example of <FIG> comprises a 64GB SD card, and the ~62GB of the single physical partition <NUM> is the total capacity of the SD card that is visible to a host device after the memory region <NUM> and the memory region <NUM> is subtracted from 64GB.

<FIG> further illustrates the single physical partition <NUM> in greater detail. For instance, the single physical partition <NUM> includes a partition metadata region <NUM> and an MBR primary partition <NUM> that starts at address XXXX. The partition metadata region <NUM> may be associated with the first region of memory <NUM>, as described above with respect to <FIG>. Moreover, the MBR primary partition <NUM> may be associated with the second region of memory <NUM>, as described above with respect to <FIG>, and therefore, the MBR primary partition <NUM> is visible to a file system layer of a connected host device.

In various examples, the host device may implement a read or a write action associated with an element in the partition metadata region <NUM> that stores a value representative of a capacity (e.g., a size) of the MBR primary partition <NUM> (as represented by YYYY in <FIG>). The action may be an action implemented by a counterfeiter that targets the element in the partition metadata region <NUM> (e.g., attempts to write a false value). As described above, a register setting in the memory region <NUM> stores a reference value (e.g., a true value) that can be indicative of (i) a capacity of the initial physical partition <NUM> or (ii) a capacity of the MBR primary partition <NUM>. The memory device can then use the techniques described above to ensure that reading the value from, or writing the value to, the element in the partition metadata region <NUM> is valid compared to the reference value stored in the register setting in the memory region <NUM>. For example, the memory device can compare a value to be read or written directly to the reference value if the reference value is indicative of the capacity of the MBR primary partition <NUM>. In another example, the memory device can derive a derived reference value by subtracting a size of the partition metadata region <NUM> from the capacity of the single physical partition (e.g., as indicated by the reference value) so that the derived reference value indicates the true capacity of the MBR primary partition <NUM> (as represented by YYYY in <FIG>). In some instances, the memory device may have to further subtract a size of potential out-of-partition space (e.g., alignment overhead) to derive the true capacity of the MBR primary partition <NUM>. It may also be considered adequate enough to compare the value to be written to a reference value which indicates the size of the physical partition.

<FIG> provides even further details of the partition metadata region <NUM> and the MBR primary partition <NUM>. For example, the partition metadata region <NUM> may contain a Master Boot Record <NUM> (e.g., one or more "elements" as described above) storing information representing a start address (e.g., "XXXX") and a size (e.g., "YYYY") of the MBR primary partition <NUM>. In another example, the MBR primary partition <NUM> may contain a partition boot sector <NUM>, a first file allocation table (FAT) <NUM>, a second FAT <NUM>, a root directory <NUM>, and an actual data area of a primary partition <NUM> that is accessible to an application through the file system layer of a connected host device.

<FIG> illustrates an example memory device in which the techniques described herein can be implemented. <FIG> illustrates a single physical partition <NUM> (e.g., the "Single Initial Physical Partition") that implements that implements GUID Partition Table (GPT) partitioning and a FAT file system. Similar to <FIG>, in this example, the single physical partition <NUM> can include ~62GB of memory space (e.g., NAND memory) that is visible to a host device and/or a user of the host device. The single physical partition <NUM> comprises a portion of memory as described above.

<FIG> also illustrates memory region <NUM> for registers and memory region <NUM> for reserved blocks, firmware (FW), etc. The memory region <NUM> may be associated with the third region of memory <NUM>, as described above with respect to <FIG>.

<FIG> further illustrates the single physical partition <NUM> in greater detail. For instance, the single physical partition <NUM> includes a first partition metadata region <NUM>, a second partition metadata region <NUM> (for backup), and a GUID partition <NUM> that starts at address XX and ends at address YY (e.g., where XX and YY are a logical block address (LBA)). The first partition metadata region <NUM> and the second partition metadata region <NUM> may individually be associated with a first region of memory <NUM>, as described above with respect to <FIG>. Moreover, the GUID partition <NUM> may be associated with the second region of memory <NUM>, as described above with respect to <FIG>, and therefore, the GUID partition <NUM> is visible to a file system layer of a connected host device.

In various examples, the host device may implement a read or a write action associated with an element in the partition metadata region <NUM> that stores a value representative of a capacity (e.g., a size) of the GUID partition <NUM> (based on start address XX and end address YY in <FIG>). The action may be an action implemented by a counterfeiter that targets the element in the partition metadata region <NUM> (e.g., attempts to write a false value). As described above, a register setting in the memory region <NUM> stores a reference value (e.g., a true value) that can be indicative of (i) a capacity of the initial physical partition <NUM> or (ii) a capacity of the GUID partition <NUM>. The memory device can then use the techniques described above to ensure that reading the value from, or writing the value to, the element in the partition metadata region <NUM> is valid compared to the reference value stored in the register setting in the memory region <NUM>. For example, the memory device can compare a value to be read or written directly to the reference value if the reference value is indicative of the capacity of the GUID partition <NUM>. In another example, the memory device can derive a derived reference value by subtracting a size of the partition metadata region <NUM> and a size of the partition metadata region <NUM> from the capacity of the single physical partition <NUM> (e.g., as indicated by the reference value) so that the derived reference value indicates the true capacity of the GUID partition <NUM>. In some instances, the memory device may have to further subtract a size of potential out-of-partition space (e.g., alignment overhead) to derive the true capacity of the GUID partition <NUM>.

<FIG> provides even further details of the first partition metadata region <NUM>, the second partition metadata region <NUM>, and the GUID partition <NUM>. For example, the first partition metadata region <NUM> may contain a protective Master Boot Record (MBR) <NUM>, a primary GUID partition table header <NUM>, and primary GUID partition entries <NUM> (e.g., one or more "elements" as described above) storing information representing a start address (e.g., "XX") and a last address (e.g., "YY") of the GUID partition <NUM>. In another example, the GUID partition <NUM> may contain (i) a file system area <NUM> that contains a partition boot sector, allocation tables, a root directory entry, etc., and (ii) an actual data area <NUM> of the primary GUID partition <NUM> that is accessible to an application through the file system layer of a connected host device. In yet another example, the second partition metadata region <NUM> may contain a backup GUID partition table header <NUM> and backup GUID partition entries <NUM>.

<FIG> illustrates an example memory device (e.g., eMMC) in which the techniques described herein can be implemented. <FIG> illustrates multiple physical partitions and multiple primary partitions that can individually implement MBR partitioning and a FAT file system.

For example, the eMMC memory device in <FIG> includes a physical replay protected memory block (RPMB) partition <NUM>, a first physical boot partition <NUM>, a second physical boot partition <NUM>, and an initial physical partition <NUM>. In this example, the initial physical partition <NUM> includes ~60GB of memory space (e.g., may also be referred to as "user data area" in association with eMMC) that is visible to a host device and/or a user of the host device.

<FIG> also illustrates memory region <NUM> for registers (e.g., CSD, CID, EXT_CSD, SEC_Count, etc.) and memory region <NUM> for reserved blocks, firmware (FW), etc. The memory region <NUM> may be associated with the third region of memory <NUM>, as described above with respect to <FIG>.

In this example, the initial physical partition <NUM> can be divided into a number of physical general purpose partitions (GPPs). For instance, space can be allocated to each of a first physical GPP <NUM>, a second physical GPP <NUM>, a third physical GPP <NUM>, and a fourth physical GPP <NUM>, thereby creating five physical partitions that comprise the user data area - the remaining space of the initial physical partition <NUM>, as well as the first physical GPP <NUM>, the second physical GPP <NUM>, the third physical GPP <NUM>, and the fourth physical GPP <NUM>. A size of a physical GPP is configurable, and thus, may vary from one physical GPP to the next (e.g., the size of the first physical GPP <NUM> may be 2GB, the size of the second physical GPP <NUM> may be <NUM> GB, a size of the third physical GPP <NUM> may be <NUM> GB, etc.). To this end, an eMMC with 60GB of initial user data area may have the user data area reduced to ~40GB after the physical GPPs are configured, as referenced in <FIG>.

For ease of discussion, <FIG> illustrates the first physical GPP <NUM> in greater detail. For instance, the first physical GPP <NUM> includes a partition metadata region <NUM>, a first MBR primary partition <NUM> that starts at address XXX1, and a second MBR primary partition <NUM> that starts at address XXX2. The partition metadata region <NUM> may be associated with the first region of memory <NUM>, as described above with respect to <FIG>. Moreover, the first MBR primary partition <NUM> and the second MBR primary partition <NUM> may be associated with the second region of memory <NUM>, as described above with respect to <FIG>, and therefore, each of the first MBR primary partition <NUM> and the second MBR primary partition <NUM> is visible to a file system layer of a connected host device.

In various examples, the host device may implement a read or a write action associated with an element in the partition metadata region <NUM> that stores a value representative of a capacity (e.g., a size) of the first MBR primary partition <NUM> (as represented by YYY1 in <FIG>). The action may be an action implemented by a counterfeiter that targets the element in the partition metadata region <NUM> (e.g., attempts to write a false value). As described above, a register setting in the memory region <NUM> stores a reference value (e.g., a true value) that can be indicative of (i) a capacity of the first physical GPP <NUM> or (ii) a capacity of the first MBR primary partition <NUM>. The memory device can then use the techniques described above to ensure that reading the value from, or writing the value to, the element in the partition metadata region <NUM> is valid compared to the reference value stored in the register setting in the memory region <NUM>. For example, the memory device can compare a value to be read or written directly to the reference value if the reference value is indicative of the capacity of the first MBR primary partition <NUM>. In another example, the memory device can derive a derived reference value by first subtracting a size of the partition metadata region <NUM> from the capacity of the first physical GPP <NUM> (e.g., as indicated by the reference value) and then subtracting sizes of other primary partitions (e.g., the second MBR primary partition <NUM> as indicated by YYY2 in <FIG>) so that the derived reference value indicates the true capacity of the first MBR primary partition <NUM> (as represented by YYY1 in <FIG>). In some instances, the memory device may have to further subtract a size of potential out-of-partition space (e.g., alignment overhead) to derive the true capacity of the first MBR primary partition <NUM>.

<FIG> provides even further details of the partition metadata region <NUM> and the MBR primary partitions <NUM> and <NUM>. For example, the partition metadata region <NUM> may contain a Master Boot Record (e.g., one or more "elements" as described above) storing information representing start addresses (e.g., "XXX1" and "XXX2") and sizes (e.g., "YYY1" and "YYY2") of the MBR primary partitions <NUM> and <NUM>. In another example, each of MBR primary partitions <NUM> and <NUM> may contain a primary partition boot sector, a first file allocation table (FAT), a second FAT, a root directory, and an actual data area that is accessible to an application through the file system layer of a connected host device.

According to yet another alternative implementation, the memory device can compare an element value (or an updated element value which a host device attempts to write) not only to a reference or a derived reference value but also to another element value (or values). This can ensure that element values that are associated with, or that define, same characteristics of the memory device in different ways store converging values. As an example, a size of a primary partition may be represented in the MBR in two ways: by a cylinder, head sector (CHS) method or by a logical block address (LBA) method. In this case, the memory device can consider one of the methods (one or more elements) as a secondary reference (in addition to the reference in the third region) and the memory device can keep the values stored in, or indicated by, the elements (i.e. different methods) converged according to methods described in this application.

In some instances, a reference value may be a single value (e.g., 0Fh, 16d, <NUM>1111b), a set of values (e.g., <NUM>, 0Ah, 0Fh), a range of values (e.g., <NUM> - 0Ah), or any combination of these, as described herein. An action being valid may mean that the comparison to a reference value is one of equal to (e.g., read/written value to an element is equal to the reference value), different from, smaller than, greater to, within a range, out of range, one or more in the set of values, out of set of values, multiple of, or any combination of these actions, as described herein.

In some instances, a derived reference value may be result of, for example, a function of one or more reference values, a function of one of more updated element values, or a function of one or more current element values. For example, a derived value may include, but is not limited to, a reference value subtracted by a capacity of memory (e.g., a size of a region of memory), a reference value added by a second value, or an updated element value being masked with a reference value.

Claim 1:
A memory device (<NUM>) comprising:
a memory comprising:
at least one physical partition (<NUM>; <NUM>; <NUM>) comprising:
a first region of the memory (<NUM>) storing metadata (<NUM>) including one or more elements (<NUM>; <NUM>; <NUM>) to store one or more element values indicative of at least one characteristic (<NUM>) related to a portion of the at least one physical partition of the memory, the one or more element values comprises an element with a current element value already stored in the element; and
a second region of the memory (<NUM>) storing data at least partly in the portion of the memory; and
a controller (<NUM>), characterized in that the controller (<NUM>) is configured to:
receive a request, from a host device (<NUM>), to read the current element value from the element;
identify a reference value stored in a register setting (<NUM>) of the memory device, the reference value indicating a capacity of the at least one physical partition of the memory;
subtract at least a size of the first region of the memory from the capacity of the at least one physical partition to derive a derived reference value;
determine that the current element value already stored in the element exceeds the derived reference value;
prevent reading out of the current element value to the host device; and
provide the derived reference value instead of the current element value to the host device in response to receiving the request to read the current element value to ensure that the request to read the current element value is valid.