EP1958049A2 - Carte media avec logique de mecanisme transfert direct d'instructions - Google Patents

Carte media avec logique de mecanisme transfert direct d'instructions

Info

Publication number
EP1958049A2
EP1958049A2 EP06848795A EP06848795A EP1958049A2 EP 1958049 A2 EP1958049 A2 EP 1958049A2 EP 06848795 A EP06848795 A EP 06848795A EP 06848795 A EP06848795 A EP 06848795A EP 1958049 A2 EP1958049 A2 EP 1958049A2
Authority
EP
European Patent Office
Prior art keywords
command
protocol
data
card
instruction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP06848795A
Other languages
German (de)
English (en)
Inventor
Robert C. Chang
Henry Ricardo Hutton
Farshid Sabet-Sharghi
Halut Kent Tanik
Ron Barzilai
Meytal Dam Ari
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SanDisk Corp
Original Assignee
SanDisk Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/298,349 external-priority patent/US20070136501A1/en
Priority claimed from US11/299,186 external-priority patent/US20070168668A1/en
Application filed by SanDisk Corp filed Critical SanDisk Corp
Publication of EP1958049A2 publication Critical patent/EP1958049A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604—Improving or facilitating administration, e.g. storage management
    • G06F3/0607—Improving or facilitating administration, e.g. storage management by facilitating the process of upgrading existing storage systems, e.g. for improving compatibility between host and storage device
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10—Program control for peripheral devices
    • G06F13/12—Program control for peripheral devices using hardware independent of the central processor, e.g. channel or peripheral processor
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0643—Management of files
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0673—Single storage device
    • G06F3/0679—Non-volatile semiconductor memory device, e.g. flash memory, one time programmable memory [OTP]

Definitions

  • This invention relates, generally, to the use and structure of removable electronic circuit cards and, more specifically, to allow personal computers or other hosts to use media specific card commands through a reader and/or host software that does not support these commands.
  • the small-format flash memory cards such as the Compact Flash Card, Secure Digital (SD) Card, the Multi-media Card (MMC), xD, and the Sony Memory Stick/Memory Stick Pro, have achieved wide consumer acceptance. These devices are primarily designed for consumer electronic devices such as digital cameras and flash-memory music players. However, it is desirable that they also have convenient connections to personal computers for uploading and downloading data.
  • SD Secure Digital
  • MMC Multi-media Card
  • xD Multi-media Card
  • Sony Memory Stick/Memory Stick Pro Sony Memory Stick/Memory Stick Pro
  • the different cards have different electrical interfaces and often commands specific to the media that can be used a host for the card.
  • card protocols may not only differ between card form factors, but also between various cards of the same form factor, since these cards are started to be overloaded with additional functions which may differ from one card to another.
  • the commands often have unique functions such as special input-output (I/O) and security operations. As the uses of such cards become more diverse and they are used in ever more types of applications, these new applications will often involve functions or commands that are lacking in existing protocols.
  • Examples of commercially available non-volatile memory cards that have different mechanical and/or electrical interfaces include the related MultiMediaCard (“MMC”) and Secure Digital (“SD”) memory cards that are available from SanDisk Corporation of Sunnyvale, California, assignee of the present application.
  • MMC MultiMediaCard
  • SD Secure Digital
  • ISO International Organization for Standardization
  • IEC International Electrotechnical Commission
  • MMC MultiMediaCard System Specification
  • MMCA MultiMediaCard Association
  • Versions 2.11 2.2, 3.1, and 4.0 of that Specification, dated June 1999, January 2000, June 2001, and February 2004 respectively, are expressly incorporated herein by this reference.
  • MMC products having varying storage capacity up to 128 megabytes in a single card are currently available from SanDisk Corporation. These products are described in a "MultiMediaCard Product Manual,” Revision 2, dated April 2000, published by SanDisk corporation, which Manual is expressly incorporated herein by this reference.
  • the newer SD Card is similar to the MMC card, having the same size except for an increased thickness that accommodates an additional memory chip. A primary difference between them is that the SD Card includes additional data contacts in order to enable faster data transfer between the card and a host. (A version of the MMC card with additional data contact is also available — see version 4.0 of the MMC specification cited above.)
  • the other contacts of the SD Card are the same as those of the MMC card in order that sockets designed to accept the SD Card will also accept the MMC card.
  • the electrical and functional interface with the SD card is further made in such a way that the sockets designed to accept the SD card can also be made to accept the MMC card, as is described in U.S. patent number 6,820,148, hereby incorporated by this reference.
  • ISO/IEC 7816 cards are particularly useful in applications where data must be stored in a secure manner that makes it extremely difficult or impossible for the data to be read in an unauthorized manner.
  • the small ISO/IEC 7816 cards are commonly used in cellular telephones, among other applications. As noted above, as such memory cards are used in new applications, they may have a need of functions or commands lacking in the existing version of a protocol. This situation can be illustrated with respect to Figure 1. As shown on the upper portion of Figure 1 , the goal is the exchange of commands and data between a particular application, say in a secure data transfer or e-commerce application, on the host side and on the card side.
  • the commands will need to be transmitted between the host and the card, where the lower portion of Figure 1 shows some of the software layers on the host side and some of the firmware layers on the card side.
  • An instruction from the host's application layer will be passed through the operating system, file layer and the device (card) driver, ending up in protocol in which it can be transmitted to the card.
  • the instruction will then be taken up by the device layer firmware, which handles standard card operations and passed on to the application layer of the firmware.
  • the instructions in the transmission protocol will wither be exchanged directly from the host to the card or through a reader or hardware adapted, which may have its own software/firmware layers used to translate from one protocol to another. Where problems can arise is that at some stage in the translation between these layers, the intended instruction of the application may lack a corresponding command at some point along the way.
  • a card is often connected with a PC host through use of a hardware adapter (e.g. for USB) that accepts commands from the host system.
  • a hardware adapter e.g. for USB
  • many of the media specific commands are not available in the protocol by which the host and the hardware adapter communicate, even though the host application of the PC host wants to transmit these commands to the card application.
  • Figure 2 shows a system of a first host and a card, where the card 101 is connectable to the host 151 either directly, for example by insertion into the slot 153, or through some sort of adapter.
  • the card firmware is indicated by FW 105.
  • FW 105 (Both with respect to card firmware 105 and reader firmware 335 in Figure 3, it will be understood that, more generally, these functions can be implemented in hardware, software, or some combination of these.)
  • An example of such a host 151 could be a digital camera or a telephone.
  • a number of types of such cards are in current use and being developed.
  • the card and host can communicate through a number of specific protocols, many of which are specific to particular media and which may include various media specific commands.
  • a user in addition to its use in a host, it is also common for a user to access a card on a personal computer.
  • a card that has been used in, say, a digital camera and want to access the photos stored in the card on a personal computer.
  • This situation is shown by the box diagram of Figure 3.
  • the card 101 is typically put into communication with the personal computer PC 351 through of a card reader 331 having a receptacle 333 for the card 101, although in other cases the card may be directly attached to PC 351.
  • the reader 331 and PC 351 will typically communicate through a protocol that, at least to some extent, differs from that used by the card 101 to communicate with the host 151.
  • the reader 331 translates a command from the PC 351 into a form suitable for the card 101 based on firmware 335 (or hardware, software or some combination of these), where it is generally understood that this function can be performed any combination of soft- and hardware, depending on the implementation.
  • firmware 335 or hardware, software or some combination of these
  • this function can be performed any combination of soft- and hardware, depending on the implementation.
  • This process is shown schematically in Figure 4.
  • the reader 331 will be taken as a USB device that communicates with the PC 351 using the SCSI command set and the card 101 will be taken as an SD card.
  • the PC 351 and reader 331 uses the SCSI protocol, when the host wants to issue a command to the card through the reader, it issues command 401 in the SCSI command set.
  • the command 401 To transfer the command 401 to the reader, it is placed in an USB wrapper 403, transmitted along the USB connection to the reader, and there the USB wrapper is removed.
  • the card reader 331 will then translate the command 401 from the SCSI command set into the corresponding command or commands 405 in the SD set, allowing it to be passed on to the card 101; however, for the reader to translate a given command between the SCSI command set and the SD command set, there needs to be an equivalent command in both sets.
  • the approach to this problem would be to either change the adapter firmware to support special commands for passing such instructions through the adapter or create new commands in the reader-host protocol, each tailored to the specific media command such as those corresponding, for example, to send challenge command, receive response command, etc. in the SD card's protocol.
  • These approaches tend to be impractical for a number of reasons.
  • the protocols are usually based on a standard which, to be useful, needs to be broadly accepted and usually tending to prefer less complicated command sets; consequently, it is difficult to introduce various new, media specific commands into the command set as new media are introduced and existing media evolve.
  • the present invention provides methods and techniques whereby a device (such as a memory card or other integrated circuit card) can exchange application or media specific commands with a host.
  • the host and card can either communicate directly or through a reader or hardware adapter, transmitting the application specific commands through a protocol that does not have an equivalent of the media specific command.
  • a PC can make a read of the secure data area of an SD (Secure Digital) memory card through a card reader even though the card reader does not support such a command.
  • SD Secure Digital
  • the host forms an instruction having a command in a protocol that is supported along the communication path between the host and the card, while the actual, media or application specific command is embedded in the instruction.
  • the media specific command is embedded in the data portion of the instruction.
  • the card receives the instruction in the protocol through which it communicates with the host and translates it into the application's protocol.
  • the embedded command is passed through in a transparent manner; for example, the transmission protocol just passes on to the card what it considers to be data, when it may actually contain the media specific command. Once in the card, it recognizes that the actual command is embedded within the instruction and proceeds to extract it.
  • the signature and embedded command are placed in the first sector of the data portion.
  • the conversion is implemented on the device side, where the actual command is extracted, and in the host side, where the command is embedded either at the device driver level or the file system level.
  • the device driver level implementation addresses commands to a specific logical block address, while at the file level any logical block address can be used. Although the device driver level implementation requires less overhead, in many operating system it may require access privileges that the user lacks.
  • a first set of embodiments considers the case where the card can communicate directly with the host in its own protocol, but the card (or other device) has an application with an additional set of features that require an additional set of commands to be used. These commands are not part of the standard protocol used by the host and card to communicate or are not supported by standard operating system on the host. Consequently, special means are required to pass these commands back and forth between the application on the card (implementable at firmware level) and the application on the host (implementable at software level).
  • the application commands are embedded in the data portion of an instruction in the intermediate protocol, which in this case is the card protocol.
  • this is achieved by having a set of commands related to opening, closing, and managing a path from the host application to the device.
  • a second exemplary embodiment is implemented at the device (card) driver level and uses an instruction that specifies a specific logical block address (LBA), a Card Pass Through (CPT) Mode LBA, with a special signature in the data sector to notify the card that a special command is embedded in the sector.
  • LBA logical block address
  • CPT Card Pass Through
  • This can be implemented as a change in the card's firmware so that it supports the CPT mode. This eliminates the need to change the firmware of the adapter according to each media specific command, so that the card can be run at any, say, USB reader or adapter without having to make media specific adaptations (or to change the host's operating system (OS) so that the card can be used under any OS).
  • the card firmware continues to honor the normal read/write command.
  • the protocol can be implemented in the firmware of any media card. Therefore, it does not require firmware change to the adapter or the USB or other reader or host OS, without the changes to reader firmware.
  • a third set of exemplary embodiments is implemented at the file level on the host side.
  • the media specific command is again embedded in the intermediate protocol, but rather than relying on the hardware specifics and referencing particular protocols, the embedded command and any accompanying data are all placed into the data portion of a file which is then transferred to the media, where the firmware again extracts the actual command.
  • the host simply tells the file system to write a file to memory device, where the device specific command is again embedded in the data portion.
  • the device With a read/write command to any LBA, as opposed to a specific logical address, the device checks for a signature to determine if the data contains embedded media card specific commands. An exemplary embodiment places this signature in the first sector of data in any file associated with a write command.
  • the file level embodiments of the present invention allows the circumvention of a privileges problem that arise to the use of a specific logical address in the device level applications, as writing a file to the device is generally allowed in operating systems.
  • the embedded command is placed in the data portion of a write command in the intermediate protocol.
  • write command of, say, N sectors in the device or application specific protocol would consist of a write command in the intermediate protocol having (N+ 1) sectors of data, the first sector containing the actual, embedded write command and the remaining N sectors the actual data to be written.
  • the command (and signature), along with any data to be transferred to the device by embedded command can be placed in any command that accepts an associated data portion.
  • the exemplary embodiment use a pair of commands: the first command will again be a write command in the intermediate protocol with one sector of data, corresponding to the embedded read command (and no real data associated with the embedded read); the actual transfer of data from the device to the host is then effected by a second command, a host read addressed to the same logical address as the first command.
  • Figure 1 is a schematic representation of the layers of a host-card system.
  • Figure 2 is a block diagram of a host-card system.
  • Figure 3 is a block diagram of a system where the card communicates with another host using a reader or hardware adapter.
  • Figure 4 is a schematic representation of the prior art techniques for the transfer of data and commands in the system of Figure 3.
  • Figure 5 shows how application specific commands can be embedded according to an exemplary embodiment of the present invention.
  • Figure 6 is a block diagram showing an exemplary structure for the relation of the firmware layers.
  • Figure 7 is a schematic representation of device driver layers.
  • Figure 8 shows the information contained in response to a partition status command.
  • Figure 9 shows an exemplary format for the argument data sector.
  • Figures 10A,10B-l and 10B-2 show host side communication flows.
  • Figures 1 IA-C illustrate the host application-device application protocol.
  • Figure 12 is a state machine diagram for the hidden partition application's commands.
  • Figures 13A-D show the process flows for a set of commands in the hidden partition protocol.
  • Figure 14 is a simplified version of Figure 4.
  • Figure 15 is a schematic representation of techniques for the transfer of data and commands in the system of Figure 3 according to aspects of the present invention.
  • Figure 16 provides details of Figure 15 according to particular embodiments.
  • Figures 17A-L give specifics of the structure of the embodiments for Figure 16 for a number of commands.
  • Figures 18A-H are similar to Figures 17A-L for a file level embodiment. DESCRIPTION OF SPECIFIC EMBODIMENTS
  • the present invention allows for commands that are not part of the standard card protocol (or are not supported by standard OS on the host) to passed back and forth between the application on the host (typically as the software that uses the application on the card) and the application on the card (typically as the card's firmware implementing these additional features as a specific application on the card).
  • the exemplary embodiment accomplishes this by embedding the special commands in a standard command, such as a write, that any host supports. This allows memory cards, such as described in the Background section, to be recognized, interfaced, and used, on all standard host devices and PCs while allowing additional, non-standard features that are not supported as a standard to be incorporated into the system.
  • any data associated with the actual, embedded media specific command that is to be transferred to the device is also placed in the data portion of the transmission protocol's command.
  • an instruction is issued in the USB protocol composed of a command and eleven sectors of data: the first data sector contains the actual SD secure write command, along with a signature and related information, and is followed by the ten sectors of data to be written.
  • the firmware extracts the actual secure write command, checks the signature, and executes the read of the data.
  • the present invention allows application or media specific instructions to be exchanged between host and card by embedding the desired command, along with any accompanying data, within an instruction of an intermediary or transmission protocol that is usable by the system.
  • the specific commands are resolved between the specific application running on the host on one side and corresponding application on the specific card on the other.
  • the instruction appears as normal command with the intermediate protocol, the actual application specific command being passed through in a transparent manner. In the exemplary embodiments, this is done by using a command in the transmission protocol that accepts a data portion, such as a write command, and embedding the actual application or media specific command in this data portion.
  • FIG. 5 is a schematic representation of how an application specific command is, according a particular embodiment of the present invention, embedded within the protocol used pass the protocol from the host application to the card side of the application.
  • the application or media specific instruction has a command portion, CMD, and some corresponding data.
  • CMD could be an application specific write.
  • the host side will take a command in the transmission protocol, call it CMD', that has a corresponding data portion, for example a write command. Whatever is placed into the data portion of this instruction will simply passed through; consequently, if the actual intended application specific command CMD (along with its corresponding data) is embedded in this data portion, it will be transmitted to the card even if the command CMD is not recognized in the transmission protocol.
  • the command CMD will need to extracted from the data portion. This is done by placing a card pass through signature (CPT signature) into the data portion as well: When an incoming instruction arrives on the card, the data portion is checked for the signature and, if found, the actual command is then extracted.
  • CPT signature card pass through signature
  • the command portion 511 has command CMD' and can be considered a sort of "dummy" command that will not actually be executed, but serves to pass the data portion 513 to the card side.
  • the data portion 513 can be broken down into a first part 513a with the signature and the actual command CMD and a second part 513b of the any data corresponding to CMD. For example, if CMD is a type of write command, 513b would be the data to be written, while if it were, say, a status check 513b would be absent.
  • an embedded read command is somewhat more involved as, in this embodiment, it involves sending a write command CMD' in section 511 of the transmission protocol with the embedded read command CMD in section 513a of the data portion and no real data portion 513b.) On the card side, 513a is then checked for a signature and if not found the command CMD' is executed with all of 513 as data. If the signature is found, the actual instruction 530, having command portion 531 with command CMD and any corresponding data in data portion 533, is extracted.
  • present invention allows the host side of the application to communicate with the card side even if they need to communicate with each other using, somewhere along the path, a protocol not adapted to the application. This can be the case when an adapter is unaware of card features, as described in the Background, but also when the host operating system is unaware of card features. This solves the issue of media or application specific commands both for systems with or without a host adapter that resides between the host and the card.
  • the card protocol may not only differ between card form factors, but also between various cards of the same form factor as these cards are becoming overloaded with additional functions which may differ from one card to another.
  • the presented arrangement allows for a system where the card adapter and the host OS are indifferent to the specific card protocol, with the specific commands being resolved between the specific application running on the host on one side and the specific card on the other.
  • the invention can be implemented either at the file system level, where in the file mode the application is using the host file system and writing to files, or at the device driver level, in a mode using the device driver.
  • the device driver level In a mode using the device driver.
  • Particular examples of both versions are given below.
  • Which type of embodiment is preferable will often depend on specifics such as the particular application and details of the operation system.
  • an implementation at the device driver level often is simpler and requires less software/firmware overhead, but uses writing directly to a logical address; however, such a directed write requires administrator privileges that a user will lack.
  • an implementation at the file system level can avoid these complications, but at the cost of additional overhead.
  • the present invention will be illustrated by a more detailed description of three specific embodiments. All of these allow special, nonstandard features to be implemented in the card to be used on the host without changing the host card protocol to support the new features or while using it through intermediate software/hardware that does not support the additional protocol.
  • the second and third sets of embodiments describe two methods implemented on the host side (at the device driver level and file system level, respectively) while the first describes the card side implementation. This first embodiment complements the second and third and describes how the card side operates and will also be used to provide more general detail for all of the embodiments. As described more in the following, this is done using standard available commands to envelop the nonstandard commands. For each of these cases, the exemplary embodiment chooses a standard read write, which is supported everywhere.
  • the card need not recognize the concept of files as in all of these embodiments the card sees a write to a particular logical block address (LBA).
  • LBA logical block address
  • This LBA can either be specifically allocated (or reallocated) for this purpose, as in the device driver mode, or any address, in the file driver mode.
  • the main difference is on the host side where, in the file mode, the application is using the host file system and writing to files, whereas in the first mode it is using the device driver and writing directly to an LBA.
  • the various aspects of the present invention are presented in examples of a number of specific embodiments.
  • the embodiments have embedded the media specific command in the data portion of a write command; more generally, the media or application specific commands can be embedded in other commands.
  • the discussion in the Background was based on a particular hardware arrangement with specific protocol domains; namely, where the PC/host communicates with the card through a hardware reader using one protocol between the host and the reader and a second protocol between the reader and the card.
  • the second host and the other protocol by embedding the media specific commands according to the present invention: for example, using the USB contacts the card can be connected directly to a PC at an USB port through which they communicate in the SCSI protocol, with any SD specific commands embedded in the SCSI protocol as described above.
  • the host and the card communicate in the protocol of the card, but a host application may want to exchange commands and data with an application on the card in a layer of which the "usual" memory functions of the card are unaware.
  • an SD memory card can be a device application layer partition hidden from the SD specific firmware layer.
  • the host and card will communicate using the standard SD protocol, but the hidden device application can communicate with the corresponding host application by embedding application specific commands within the SD protocol.
  • the first exemplary embodiment is of this nature.
  • the exemplary embodiments embed the media specific (or application specific) commands within a write command.
  • a write command is used as the examples embed the command within the data portion of the intermediate protocol and a write command inherently has a data portion. More generally, not just a write command but any command that accepts a data portion may similarly be utilized. Since a write is a basic instruction in a protocol to transfer data, the exemplary embodiments below will continue to be described in terms of a write.
  • the media or application specific commands are embedded at the beginning of the data portion for simplicity, more generally they may be placed elsewhere in the data portion and be identified by the signature. (As noted above, more generally, the signature, the application command, or both may also be embedded in the command portion of the transmission protocol in protocols, such as the SCSI protocol, that have sufficient room in their command portion.)
  • a command (call it F) is introduced into (a, ⁇ , ⁇ , ...) protocol to open a pipe for the host and device sides of the application to communicate. Once the pipe is opened, the media or application specific commands can then be sent. This can be represented as A[F(y)] ⁇ ⁇ .
  • This technique will be developed in the first example. This allows for handling command failures and other subtleties.
  • the problem with a command failure is that the intermediate protocol has no knowledge of the nature of the embedded command since, as far as the intermediate protocol knows, it is sending a simple write command. If the embedded command is a read, for example, the PC will not know what has occurred in the event that the read fails.
  • the first exemplary embodiment is implemented at the file level on the host side and will be used to illustrate various aspects of the present invention; on the card side, the implementation is largely the same whether host side is implemented at the file or device driver level.
  • host side is implemented at the file or device driver level.
  • it will be given in the context of a hidden partition on the memory card, where the memory is divided into publicly accessible portion and a private, or "hidden", portion.
  • hidden partition on the memory card, where the memory is divided into publicly accessible portion and a private, or "hidden", portion.
  • the host side portion, in particular, the device driver will be described first, followed by card details.
  • FIG 6 is a schematic block diagram showing an exemplary structure on the device side.
  • the Device Application or Applications 1023 each provide a gateway, or "pipe", for the Host Application or Applications 1053 on the host side 1051 to a non standard, for this specific form factor, card feature, here the hidden partition.
  • the host side layer's are described more in Figure 7 below.
  • a device application 1023 supplies partition access (Read & Write), status, and other device application information.
  • the device application 1023 can communicate with the host application 1053 via the exemplary protocol described in the following and use the card's systems and memory resources through the Media layer 1025.
  • the memory itself is indicated at Memory 1011 and will commonly be a Flash memory of the NOR or NAND variety, although other non-volatile memories, including those described in U.S. patent application 10/841,379, May 7, 2004, which is hereby incorporated by reference.
  • FE (Front End) Layer 1021 is the firmware layer that handles the commands (in the card type interface such as the CF, SD, MMC, etc. protocol) from the host side.
  • BE (“Back End") Layer 1027 is the firmware layer that handles the management of Memory 1011, including reads and writes to the memory.
  • the Media Layer 1025 connects the Device Application firmware 1023 with the BE Layer 1027 and will also interface the application firmware with the RAM resources of the controller, which is not specifically shown in this view.
  • an instruction When an instruction is sent from the host 1051, it is initially received on the device 1001 at the front end (FE) layer 1021.
  • the command will be in the intermediate protocol used between the host and device, for example the SD protocol.
  • the command arrives at the FE layer 1021, it is checked for a command pass through signature: if no signature is found, the instruction is treated as a standard instruction from the intermediate protocol and can access the memory or otherwise be executed in the standard manner; if the signature is found, the embedded application specific command is extracted and passed on to appropriate device application 1023 for execution.
  • the command When implemented (on the host side) at the device driver level, as in the second exemplary embodiment below, the command will be addressed to a specific logical address, while when implanted on the file level, as in both this example and the third example below, the command can be to any logical address; as seen from the device side, both implementations are largely the same.
  • the hidden partition (in this example) will be made available to a host application 1053 via the corresponding device application 1023 resident on the card 1001.
  • the host and device applications will communicate using a protocol that will cover the reads and writes between the host and card sides, as well as reporting on the partition status.
  • the device controls the rights to the application.
  • the rights (read, write) are given when the device confirms the host application's credentials and, upon approval, the device application will grant read and write privileges to the partition through the host/device protocol. Once the host application has been validated, then the assumption is that the device is operating within a trusted environment.
  • the first exemplary embodiment will be implemented at the file level, with the embedded commands placed in the first data sector of the write file.
  • the implementation does not rely upon reference to any specific logical address, but rather upon checking the first data sector for a particular pattern or signature.
  • the files in the partition are managed by the host, meaning that, in the hidden partition example, the host application is the owner of the file system in the hidden partition. Once the host application obtains rights to the application, it has full control over the content.
  • a host application 1053 will implement a file system layer since the FAT of the hidden partition often cannot be read due to access privilege problems with the operating system (OS). As with any access to the hidden partition, the FAT will be available only after the pipe to the application is open. (The command transfer by the host application will be defined and explained below.)
  • the host application will reside on the card's non-hidden, or public, partition, seen by the OS at the mass- storage device or removable drive level. Several such host applications can reside in this area and the user will know which one to execute, which will be executed on the host side.
  • the host side software layers are described in more detail with respect to Figure 7.
  • the device driver 1055 has two roles. It functions as bus driver and performs IO operations for the standard client applications supported by the (intermediate) protocol and the File System 1057. In addition, it also implements the application and the device or application specific protocol.
  • the standard IO API and implementation can be common to all of a card family, for example the standard SD card operations.
  • the application or device specific API and implementation are protocol specific by nature.
  • Figure 7 shows an example of a hierarchical structure that enables code sharing for the common part and simple portability between different applications specific protocols.
  • the host structure now also incorporates a layer 1059 specific to the device applications.
  • the layer 1059 is not used and the layers 1053, 1057, and 1055 will largely operate as in the prior art.
  • the device application layer 1059 will be interposed between the file system 1057 and the host layer 1053 in order to format and embed the application specific commands.
  • the device driver 1055 can include interface and pipe sub-layers to provide common functionality and can be used with minimal changes with all application specific protocols.
  • the host's application should match the protocol layer according to the particular application.
  • the interface sub-layer will expose a standard set of device functions. For example, these would include: hardware initialization and configuration; drive open and close routines; read and write operations; and erase. It will also include a function to the appropriate communication method and initialize the pipe accordingly.
  • an instruction such as 510 of Figure 5
  • the operating system may split it up into several pieces, possibly even interposing pieces of other instructions.
  • the file system 1057 and device driver 1055 can break up the instruction 510 so that the command portion 511 is attached to anywhere from none to all of the data portion 513, with the rest of the data portion following in one or more subsequent transfers.
  • the subsequent transfers for the remaining portion of the data will lack the signature portion of section 513a and appear as a standard command.
  • Such a division could also occur for data being transferred from the card to the host in a read operation.
  • a simple hidden partition protocol is used for demonstration.
  • the memory 1011 is divided into two partitions.
  • the first partition is the product standard partition.
  • a standard host is aware only of this partition.
  • the second partition is the hidden partition that is accessible only through application specific commands.
  • a standard host is unaware of this partition and has no way to access it.
  • the hidden partition protocol of the example defines five functions through which the device and application communicate:
  • Open Hidden Partition Used to authenticate the user and enable read and write operations.
  • the protocol layer provides the additional API that's required to implement the security protocol.
  • Hidden Partition the protocol requires three services in addition to read and write: Open Partition Close Partition Get Partition Status. These commands are shown below in Table 1, where along with Figure 8, they are discussed further.
  • the pipe sub-layer is responsible for the communication with the card according to media command pass through principles.
  • the main idea in the media command pass through protocol is that special commands (commands that are not part of the standard product specification) are embedded within standard Read and Write operations. Embedding the commands in standard Read and Write operations enables to work with standard hosts and drivers.
  • all commands will be initiated by sending a write command to a certain LBA of the media card.
  • Application specific write commands will include multiple sector transfer where the first sector holds the command's arguments and the rest of the data blocks hold the relevant data if any.
  • Read commands will be executed in two parts:
  • the read command to the chosen LBA from the write command will be sent to do the actual data transfer from the card to the host.
  • All commands first send a write command with the sector format shown in Figure 9.
  • the host application decides to send a write command
  • the first sector transferred will have the above format.
  • the next data blocks sent from the host will have the actual data for the card.
  • a number of possible implementations are possible for the media command pass protocol.
  • the example of this section uses a file system, for example Windows file system operations.
  • the example of the next section communicates directly with the device at the device driver level and does not have the file system overhead.
  • Another implementation can be for a pocket PC (PPC).
  • PPC pocket PC
  • read and write operations can directly access the PPC storage driver. Since there is no standard storage device driver for pocket PC devices at this point, there is no guarantee this method will work on all PPC devices.
  • the client application vendor should test it with the set of PPC devices it intends to work with.
  • the pipe sublayer initiates read and write operations to the Command Pass Through LBA by reading and writing from/to the same file location, indicated as LBA XYZ in Figure 1OA for the case where the OS will transfer the entire instruction in a single transfer.
  • the implementation uses Windows' standard file system API - CreateFile, ReadFile, WriteFile and SetFilePointer.
  • the implementation sets can be broke into four or five parts: the pre-requirements; the establishment of the communication pipe; the verification of the file length; the applications write command; and, if data is to be read or other information returned to the host, the read command.
  • the file system is used to unknowingly transmit the embedded, application specific commands. Since the actual, embedded command may be of a different nature from what the command in the intermediate protocol that file system thinks that it is sending, a conflict can arise if appropriate steps are not taken. For instance, if a error arises, error recovery can be complicated as the file system will see this as an error in the carrying command (a write) in the intermediate protocol, when the actual error may be with the embedded command (for example a read). Similarly, a dissonance can result if the file system employs caching.
  • the pre-requirements for the file system implementation require a standard file that contains at least 128 sequential sectors. To ensure the existence of such file, it is created on formatted drive. Therefore, if the host application vendor chooses this method, they should deploy the communication file with the application.
  • the design assumes that a file named "FilePipe" (with certain attributes specified below) exists in the device user area. If such file does not exist the driver will try to create it. If it fails, the application can ask the user to format the drive and re -install the application on formatted drive.
  • the device driver 1055 preferably opens the communication file with the following attributes: Not shared No Buffering
  • the Not shared status ensures that only the host application has access to the file in order to prevent other applications from accessing the Command Pass Through LBA.
  • the No Buffering status instructs the system to open the file with no intermediate buffering or caching. Thus, any write or read to/from this file results read/write commands to /from the card rather than a cached version. (In some cases, to ensure that the file will be flushed to the card, it may necessary to set both a "no buffering" flag and a "write through” flag.) Since the actual application or media specific commands are embedded within commands of another protocol, when there is, say, a write error, the host interprets this as an error with the write command in the intermediate protocol rather than an error with the embedded command.
  • the No Buffering status keeps the data transfer tied up to the intended, embedded command.
  • the Hidden status implies that the end user sees this as a system file.
  • the next implementation step is to verify that the file contains at least 128 sectors that are sequential.
  • the write buffer is prepared along the lines described above.
  • the buffer is then sent to the device by calling the "WriteFile" command with the "FilePipe" name.
  • the file pointer is first reset, followed by performing a "WriteFile” command to send the command buffer. The file pointer is then reset again to ensure that the Write and Read operations are done on the same LBA. The "ReadFile” is then performed to obtain the secured data from the device.
  • the Device Application 1023 will manage the hidden partition(in this example), allowing reads and writes pending on host application validation. Resource and memory access are through the Media Layer 1025 for the hidden partition phase. The Media Layer 1025 will direct all of the device application data transfer to the hidden partition on the memory 1011.
  • the Device Application 1023 receives its specific commands from Host Application 1053 through the regular card protocol read/write commands. For example, taking the SD card protocol as the exemplary embodiment, each command index and arguments are passed on in a command sector via SD write command.
  • SD read command When a read command is expected from the device application, then first the host application will send a write command (through SD write command) followed by the actual read command (SD read command).
  • the read command context is saved, for example in RAM space dedicated to the device application, during the write command that passed the command sector.
  • the device application will then load the saved read context and transfer the requested data.
  • the saved read context will remain as is until it is superceded by another read context. This will enable the host to perform read retries without sending another write command + command sector.
  • Figure 9 shows an exemplary format for the argument data sector here.
  • bytes 0-31 hold the application pass through signature (e.g., "Pass Through Mode Supported")
  • byte 32 the application's ID
  • byte 33 the application command operation code index for the embedded command
  • the application command argument data filling out the rest of the sector.
  • the first sector transferred will have the format of Figure 9.
  • the next data blocks sent from the host 1051 will have the embedded command's actual data for the card. If the host application chooses to initiate a read command, then it first sends a write command to the chosen LBA with the above single sector format and then a read to the same LBA to effect the read.
  • the host application 1053 is responsible on initiating the described commands according to the communication flow as seen from the device, shown in Figure 1OA. To do this, the host application controls the target LBA for the card protocol's read and write operations that will carry the embedded command as described above. Although described for only a single command at a single LBA, the process shown in Figure 1OA (and Figures 1 IA-C, Figures 12, and so on) may be occurring for multiple LBAs as they can all rely upon the pass through mode signature.
  • the signature is then checked (1103) to see whether it is the application pass through signature: if not, the card engages in standard IO operations (1105); if so, it enters the CMD pass through mode.
  • Step 1109 determines whether the command direction (as seen from the device) is OUT or not. If the direction is OUT (e.g., a write to the device's memory), the command is executed (1111).
  • the memory device waits for the second command of the read pair, an application read request, at 1113. If instead a write arrives (1121), it goes to standard IO operation (1123) before returning the wait state (1113). If a read command is received, the LBA is checked (1117) and if it is to the chosen LBA, it is the second command of the read pair and the read is executed (1119); if the LBA does not match, it instead goes to 1123.
  • the card-FW receives an application specific command. After verifying the Card Pass Through Mode Supported signature, the card's FE layer 1021, will pars the argument data sector that came with the write command to a chosen LBA for the Application ID and Command OP-Code. The Application Specific Command Interpreter will call the application interface routines with a pointer to the host data buffer.
  • the application FW In a second step, when starting an application specific command sequence, the application FW must set it's own state machine to handle the application command sequence and also set a flag to indicate that the next read/write command to a chosen LBA is intended for application FW. Each time a read command is sent to the card (to the chosen LBA), the card's FW will first check this flag to distinguish this application specific read command from a regular read command to this LBA.
  • FIG. HA-C illustrate some of the same processes as for Figure 1OA, but in terms of the activity on the system bus between the host and the device.
  • the process for an authentication and secure partition FAT read is shown in Figure 1 IA.
  • the host sends Username+Password to the card for authentication.
  • the card Upon authentication, the card will enable the application to read the FAT from the secure and hidden partition.
  • the partition stays open until the host ends the session or the device goes through a power cycle. As long as the partition is open, reads and writes to the hidden partition by the host application are allowed.
  • Figure 1 IB illustrates a host read of a file in the secure partition.
  • the application specific read command occurs within two card protocol commands: a write command that specifies the nature of the read command and arguments and then the actual read command.
  • Figure HC illustrates a host write to the hidden partition. Passing authentication, the host has access to the partition's FAT and now has the right to transfer a new file to the host. The host sends a write command to the secure partition with a write start address and sector count.
  • Figure 8 shows the embodiment of device application status, introduced above, along with exemplary values for the hidden partition example.
  • byte 1 in the device applications partition ID given as "1" in the example.
  • the next four bytes give the partition size, here shown as ten megabytes worth of sectors.
  • Byte 5 indicates if the partition is currently open or not and the next four bytes are given to indicating the version of the device application.
  • Byte 10 provides operation status. Bytes 10-511 are padded out with zeros to form a sector. In a variation, byte 11 may be used to record the number of sectors written in the last transaction.
  • Table 1 describes an example of application protocol commands that are sent to the device application for the hidden partition example.
  • the CMD Index is placed in byte 33 of the command sector, and Command Arguments are placed from byte 34 and on in the specified order written in the table.
  • the partition's command interpreter will be called by the, say, SD command interpreter after establishing that the write or read commands are actually meant for the partition's device application and not for the SD regular operations.
  • the command interpreter will call the appropriate routines after parsing the command sector.
  • the application's command can have as a first argument a parameter indicating whether the MD command is a Read command or Write command.
  • a second parameter can pass a pointer to a location in the allocated RAM where the command sector is placed. The pointer will point to byte 33, Command Operation Code Index, since the relevant information for the partition's device application begins at this point of the sector.
  • the buffer size that is pointed to by this second parameter can be specified in a third parameter.
  • write commands for the device application are simple because they are executed right after the command sector is parsed, in the same sequence as those of the card protocol.
  • SD case
  • SD-write command (1 or more sectors) is received - the first sector is always the command sector in the exemplary embodiment.
  • the card-layer parses the first 32 bytes of the first sector and recognizes the command sector's signature.
  • the Device Application command parser (interpreter) is called with a pointer to the command sector.
  • the command interpreter after it is done identifying the embedded application command, calls the corresponding routine that will execute the embedded command and begin the application's command process.
  • the command process is for the hidden partition's application is done and a status is returned to the card-layer, where the sequence is going to end as an SD-write command process would.
  • the SD card goes to IDLE state.
  • read commands in the hidden partition's application protocol are a two-step process that is comprised (again in an SD embodiment) from an SD-write command followed by an SD-read command.
  • the first step is the SD- write command:
  • SD-write command with one data block (512 bytes) sent by the host - the first sector is always the command sector in the exemplary embodiment.
  • the card-layer parses the first 32 bytes of the first sector and recognizes the command sector's signature.
  • the Device Application's command parser (interpreter) is called with a pointer to the command sector.
  • the command interpreter after it is done identifying the embedded application command, identifies the embedded read command that is about to be executed (in the next SD-read command), saves this command identifier. Then the command interpreter sets the card-layer read command flag 4. The application's command process is done and a status is returned to the card-layer where the sequence is going to end as an SD-write command process would end. The SD card goes to IDLE state.
  • the second step is an SD-read command:
  • the SD card-layer checks the application card-layer read command flag and finds that it is set - instead of calling a regular SD read command it calls the device application command interpreter with a read command indication.
  • the device application command interpreter identifies the partition read command flag and recalls the partition read command identifier that was saved in the previous write command. The identifier directs to the corresponding partition read routine and initiates the partition read sequence.
  • the partition read sequence is done and a return status is passed to the card layer.
  • the card layer ends the SD-read process and the card enters IDLE state.
  • the read and write processes are illustrated by the card side application's commands state machine, shown in Figure 12 for an SD-based embodiment. Since these embedded commands are passed by SD write commands, and when a hidden partition Read command needs to be executed the host cannot pass the command sector on an SD read command, the Device Application's (1023) command interpreter needs to maintain a state machine which will manage and know which read command is being executed by the Host Application 1053.
  • the bubbles refer to the device specific application commands that are executed at the device application layer (1023, Figure 6), while the attached comments refer to the commands as seen at the FE layer (1021, Figure 6) that are in the intermediate (here SD) protocol.
  • the right side (the A path) of Figure 12 is the process for a write process, where any process where either data is transferred to the device or no data is transferred will follow a similar flow.
  • the left side of Figure 12 corresponds to a read or other process where data is transferred from the device to the host.
  • the read flow consists of the B path for the first command of the pair needed for a read and the C path for the second command of the pair. [0099] Both the write flow and the read flow begin in the same way, receiving an SD write command from which, after the signature is detected, the embedded command is parsed. For the write flow, the write flag stays on and the write process is executed. For the first phase of the read flow, however, the read flag will be set.
  • This Card Layer (SD) Read Process Flag is set by the Device Application (1023) when a read process from the host is detected.
  • the flag indicates to the card layer that the next read command from the host (on the SD bus) is not a regular card read and should be directed to the Device Application (1023) for handling. This occurs in phase 2 of the read flow, in which, in response to the second command of the pair, the data is transferred from the device.
  • the flag gets reset when the card layer initializes.
  • the OPEN P ARTITION command (OP-Code 0x01) accepts a username and password and verifies them. If they match to the Device Application's stored name & password then the partition is opened for host access (Read, Write). At this point, there will be one authentication phrase that will be sent and verified against a phrase in the Device Application's code. This process is shown in Figure 13 A. The partition will stay open until the CLOSE P ARTITION closes it or until the next power cycle.
  • the WRITE P ARTITION command (OP-Code 0x04) directs data from the host to the hidden partition on the card. As shown in Figure 13D, this command will be executed by the device application only if the Partition Flag is SET (1653). This routine will call a "FlashWrite" (1659, 1661) API routine, which will direct the data transfer to the hidden partition space.
  • the READ PARTITION STATUS command (OP-Code 0x05) supplies the information shown in Figure 8. This is an application read command with the structure discussed above with respect to Figure 8. When the command comes in, the routine will gather all the information and place it in the structure above and send it to the host.
  • LBA R1 reads as well as an LBAwi for writes
  • the subscript i is to allow for the concurrent implementation of multiple application specific commands from multiple applications and multi-user host devices.
  • the received instruction is an SD write at step 1203, it is then checked for the pass through signature (1214). If the signature is found at 1214, this indicates the beginning of a new embedded command, which can then be extracted.
  • the data direction of the application specific command is then determined (1233). If involves no data transfer, the application-specific-command is then executed (1245) and the device returns to the idle state (1249).
  • the application's command is a write
  • the host's OS may split the instruction up so that the command is not accompanied by all of corresponding data.
  • the card will know how many blocks of data the command should include.
  • LBAwi can be cleared (1257); otherwise, it is not cleared as the rest of the data will, unless interrupted by an error or shutdown, eventually follow and will look like a standard SD write command to a consecutive (relative to this command) card address which is the address calculated above. The device will then return to the idle state (1259) to await further commands.
  • the device then goes into the SD idle mode to wait for the second phase of the read process.
  • LBA CMD LBA CMD
  • LBA READ explicitly defined in the parameter of the write command.
  • This method will work around cashing machnism of the OS. In several systems the host OS will not attempt to read back a card address which was just written to. Instead it will return to the host application the data buffer fro a host cash buffer, assuming that this data is what the card has, since it was just written to it. In this case the data buffer will include the application-specific-command rather then the card response.
  • the command in the transmission protocol
  • the command may actually be a write command in the transmission (here, SD) protocol, or may be additional data for a write in the application protocol.
  • SD transmission
  • step 1205 if the command is an SD read, it is determined whether it is actually an SD read or the second phase of an application read. This is determined at 1226 by comparing LBA CMD with the LBA R1 : if LBA CMD ⁇ LBA RJ for any of the LBA R1 , then it is a standard SD read which is then executed at 1227, after which the card goes into the SD idle state (1229). If LBA CMD instead matches one of the LBA R1 for any of the LBA R1 , it is the second phase of an application read.
  • LBA CMD LBA RI
  • LBA CMD LBA RI
  • the device then goes into the SD idle state (1269).
  • the exemplary flow lacks the equivalent of steps 1255 and 1257 on the application write side.
  • The keeps the corresponding read flag set even if all of the corresponding data has been accessed.
  • the data can be re-read in case of an error.
  • LBA R1 is only cleared if the address is reassigned for another purpose, such as in step 1231, for one example.
  • Figure 1OA allow for breaks in the transfer of application data. They also remove the need to read and write to same logical address. These allow the techniques to be used in cases where there may not be enough control over the operating system, as the sort of control needed for the embodiment of Figure 1OA may require a known controllable platform. Also, it should again be noted that Figure 1OB more explicitly incorporates that there may be multiple host applications, each communicating with card independently, and the breaks in data transfer may interpose part of an instruction from one protocol between portions of an instruction from another. Further, separate LBAs for both the read and write processes allow any read or write caching in the device driver layers to be bypassed.
  • the first example was implemented at the file level.
  • the various aspects of the present invention can also be implemented at the device driver level, initiating read and write operations by sending requests to the device driver, for example the Windows Standard Storage driver if the host uses the Windows operating system.
  • This implementation of the command pass through method communicates directly with the device and does not have the file system overhead. However, this method may require administration rights.
  • the host's application can try and use this method as first choice and move to file system operations if it fails.
  • An interface function can be used to select between the methods and to initialize the communication pipe accordingly.
  • the client application would call this command before any other operation. If the application lacks the proper administrator rights, working with this method will result an exception, which can be treated according to exception handling code.
  • the memory device may have such protocol translation-or, more accurately, non-translation-problems even when it connects directly to a second host. This situation may result when the memory device is connected to a host that has, as seen from the memory device, a less than complete protocol.
  • a card has two sets of contacts, one for use with an USB port and another for a standard set of card contacts. (Examples of such dual contact cards are described in U.S.
  • the present invention uses a specified logical block address (LBA), the Card Pass Through Mode LBA, with a special signature in the data sector to notify the card that a special command is embedded in the sector.
  • LBA logical block address
  • CPT command pass through
  • the various small-format flash memory cards (Compact Flash Card, Secure Digital (SD) Card, the Multimedia Card (MMC), xD, and the Sony Memory Stick/Memory Stick Pro, etc.), have different electrical interfaces and often media specific commands for use with a host (digital cameras, flash-memory music players) that are not found in the command set of used between a PC and a hardware adapter allowing the PC to read the card.
  • a host digital cameras, flash-memory music players
  • the present invention uses a card firmware change to honor the normal read/write command.
  • a signature is checked to determine if the data portion of the command contains embedded media card specific commands.
  • the protocol can be implemented in the firmware of any media card. Therefore, it does not require any firmware change to the adapter, USB reader, or other reader used by the PC (or other host without access to the full, media- specific command set). In practical terms, this is simpler for the card manufacturer than implementing the reader firmware changes for all of the card commands in all vendors of the readers.
  • Figure 14 shows the process whereby the card and a personal computer
  • Figure 14 is similar to Figure 4 except that it ignores the explicit introduction of a USB wrapper or similar structure in some cases, which will also be suppressed in the following discussion.
  • the card and reader communicate using an instruction, such as indicated at 201, from the command set of the card's protocol.
  • the host and reader typically communicate using an instruction, such as indicated at 203, from another command set.
  • the reader serves to translate between the two command sets using its firmware.
  • command 201 is a command from the card's command set which has no equivalent in the protocol used by the PC to communicate with the reader.
  • the reader is unable to translate 201 into a corresponding command 203 as there is no such equivalent instruction 203, and similarly for the other way around. Consequently, if the host wishes to use one of the card's media specific instructions, there is no way to pass this through the reader in the prior art without changing the command set of the PC-hardware adaptor protocol.
  • This particular example will use the SCSI protocol from host to reader, the SD protocol from reader to card, and an example of an SD command, say a secure write, that does not exist in the SCSI protocol as the embedded command. So although this command could be transmitted directly in the SD card, it needs to use aspects of the present invention for the host side of the application to be able to transmit the instruction in the intermediate SCSI protocol that carries the command between the host and reader.
  • the dummy command has a version in each protocol and can be translated between the protocols, with the actual embedded command being treated as data. For example, the dummy command is again taken as a write.
  • Figure 15 is a schematic representation of a principle aspect of the present invention when a command form the card's command set that has no equivalent in the PC-reader command set is embedded in an instruction 203 of the PC-reader protocol which has a representation in both command sets.
  • the media specific command is again embedded in the data portion of the PC-reader protocol.
  • the PC and reader can then exchange a command 203 which the reader can translate into a corresponding command 201.
  • Within this command is embedded another, media specific command 601.
  • the reader passes through and translates this command in a manner transparent to its operation.
  • the mechanism of the exemplary embodiment is that the instruction 201/203, which has a representation in both command sets, is an access to a predetermined logical address in the card's memory.
  • the card receives a read command to the specified logical address, the card is alerted that this may be a media specific command 601.
  • the card checks for the signature of such a command to verify this and then extracts the command 601.
  • the command 601 is placed inside the data portion of the instruction since, in SCSI and other protocols, there is often no convenient place to embed the media specific command in the command portion of the instruction.
  • instruction 203 that consists of a write command to the specified logical block address (LBA), contains the command pass through (CPT) signature, and contains the actual secure write command 601 embedded in the data portion.
  • the PC then sends this instruction 203 to the reader, which interprets it as a standard write instruction in the SCSI protocol. This is then translated by the reader into a standard write instruction 201 in the SD protocol.
  • the reader just passes through the secure write command 601 assuming it is part of the data attached to the write command.
  • the firmware allows the card to determine that the instruction is instead a media specific command.
  • the controller extracts the command 601, which it recognizes as a secure write, and proceeds to execute the command by performing a secure write of the actual data portion of the instruction.
  • Figure 16 describes a particular embodiment in more detail for the example of performing a secure data write of N sectors of data to an SD card.
  • the top row shows the instruction as formed by the host.
  • the command portion consists of a command CMD' in the SCSI protocol, here a write, that exists in both command sets.
  • the write is to the specified command pass through logical block address, CPTLBA. (The other details of the command are not shown in order to simplify the discussion.)
  • the data portion, to the right of the broken line consists of an initial sector, containing the media specific command, followed N sectors of the actual data.
  • the initial data sector will include the command pass through signature, the actual media specific command, and the actual address where the following data is going to be written.
  • the logical block address CPTLBA corresponds to the logical block address LBA XYZ used in the discussion of the first exemplary embodiments discussed above (see, for example Figure 10A).
  • the different labeling is used to indicate that in the present example, implemented on the host side at the device driver level, the logical block address being used is a particular, specified logical block address, whereas in the previous example, implemented at the file level, it can be taken as any address.
  • Figure 16 is similar to Figure 5 discussed previously, but with the instruction 510 repeated once for each of the transmission protocols (host to reader, reader to device) explicitly shown in this example.
  • Instruction 510 of Figure 5 shows the embedding of the command CMD as this will occur somewhere along the transmission path between the host and device sides of the application, while instruction 530 shows the extracted form as it will be used by the device side of the application.
  • Figure 16 illustrates that there may be several intermediate protocols and that the actual command (CMD) will stay embedded through several of these, even in cases where the embedded command has an analogue in a particular intermediate protocol.
  • CMD actual command
  • the first data sector is just the first of what it sees as N+l sectors of data to be written to the specified logical block address. As such these pass through unchanged in content.
  • the command portion of the instruction is translated by the reader from its representation in the PC/reader protocol (CMD') to its representation in the card's protocol (CMD). At this point, the instruction can be communicated to the card and still has the form of, say, a write command to CPTLBA followed by N+l sectors of data.
  • the command uses the specified address, it then goes to the first data sector, checks the CPT signature, and extracts the actual, media specific command. This then forms the actual command of the instruction, which is then followed by the N sectors of actual data.
  • a media specific write command with N sectors of data becomes embedded as N+l sectors of data in the transmission protocol used between the PC and the reader.
  • the media-specific read command is embedded as one sector of data in a read (or other command that accepts data) or the transmission protocol used between the PC and the reader.
  • media specific read command can be implemented as a write command with the media specific read command embedded in the only sector of data.
  • the card will extract the media specific command and respond with data from the requested logical block address specified in the media specific read. Details on read implementations and methods for dealing with complications such as a write or read failure were developed further above with respect to the first exemplary embodiments.
  • the specified logical address is preferably a sector not normally used in the file system, as this can avoid conflicts with standard read or write commands that may be sent to this sector. For example, in DOS, after the master boot record, there are usually some hidden sectors not usually accessed. (In some operating systems, accessing this area may require administrator privileges, a possible complication that can be bypassed in the file-based implementations of the next section.)
  • this logical address By taking this logical address as the specified logical address, an access to this address will not really be to read or write data there, but for the purpose of checking that the actual command is an embedded media specific command. The reader will just pass though this command as a normal data access and the card sorts everything out.
  • Figures 17A-17L show one embodiment of how various examples of commands can be embedded into a data sector.
  • the first sector of the data portion contains the CPT (card pass through) command. It indicates the CPT function to be executed. Consequently, to write 10 sectors, it actually writes 11 sectors because the first sector is a CPT header. To read 10 sectors, the user needs to send one write of CPT command then read 10 sectors.
  • the real application is to perform special commands that cannot be achieved by the normally read or write command.
  • the CPT mode can be used for media specific commands, such as AKE (Authentication Key Exchange) or application command for the SD card.
  • Figure 17A shows an embedded command format embodiment. The
  • CPT Signature in bytes 0-31 is string of characters that depends on the command to check that the signature matches the command.
  • Commands, in byte 32, can include:
  • Data Transfer Length (bytes 33-35) specifies the amount of data (as a number of bytes) to be transferred; since data is transferred in sectors, an incomplete sector is padded out by Os.
  • Data (byte 36, bit 1) is flag for data transfer and "0" if there is no data transfer on the next command, "1" there is data transfer on the next command.
  • Dir (byte 36, bit 0) is flag for the direction of data transfer and "0" if data transfer is for input on the next command, "1" - if data transfer is for output on the next command.
  • the Media Card Specific command area (bytes 48-511) is the real command that the media card will run when it is extracted.
  • the Media Card Specific Flags area (byte 36, bit 0) is for media dependent flags.
  • the media card must be checked if it supports the Card Pass
  • LBA CPTLBA - Card Pass Through LBA
  • the LBA can be any number from 0 to the last sector of the card. In the example, this will be the LBA 2, which is the second hidden sector after the master boot record in FAT file system and is typically not used to hold data. Note that even if that LBA contains valid data, this protocol will preserved its values. There are two options for checking the mode support.
  • the first option to query for support of the protocol is for when the media card puts the CPT mode support signature in the CPTLBA sector. However, this is not preferred if the CPTLBA is a sector that has valid information; e.g., the sector in the FAT/Directory or user data area. If the CPT mode is supported, optionally the card can return the CPTLBA sector with the signature as shown in Figure 17B, where Bytes 0-31 are "Card Pass Through Mode Supported (padded with blanks)" and bytes 32-511 are 0.
  • the second option to query for support of the protocol can be used if the CPTLBA sector does not contain the signature supporting CPT mode.
  • the following protocols are used to check the mode support: a) Read and save the CPTLBA sector in the host memory area. (No supporting signature) b) Write the CPTLBA with a sector containing signature for query the CPT mode support. c) Read the CPTLBA sector for checking the response of CPT mode support. d) Write the CPTLBA with an original sector from the saved memory area.
  • Step a) allows for the specified logical address (CPTLBA) to be checked for support while still maintaining any data that may be contained in it as the host reads the CPTLBA sector and save the save in the memory. This is to restore the sector in case the media card does not support the Card Pass Through mode. This write does not use CPT mode command.
  • CPTLBA specified logical address
  • FIG 17C shows step b), the writing of the CPTLBA with a sector containing signature for query.
  • Bytes 0-31 contain The host writes the CPTLBA sector with bytes 0-31 as "Card Pass Through Mode Check” (padded with blanks), followed by the command and flags in bytes 32-47. Bytes 48-511 are 0.
  • step c) the host reads the CPTLBA sector for the response. If the response is as in Figure 17D, with bytes 0-31 as "Card Pass Through Mode Supported” (padded with blanks) and bytes 32-511 as 0, The Card Pass Through mode is supported; otherwise, the card does not support CPT protocols. Note that this protocol is different from the first option to query for support of the protocol.
  • the signature is responded when a CPT mode check command is issued.
  • step d) the host writes the original data of the CPTLBA sector from the saved memory area. Note that even if the card supports the Card Pass Through mode, this write will not be interpreted as a special CPT command because there is no proper signature.
  • FIG. 17G shows a CPT command to be sent to indicate data are to be read, where the 2 in byte 32 corresponds to the "Data to be read from the media card".
  • the number of sector to be read are [(Data Transfer Length)/512]. (This is assuming 512 bytes per sector; more generally, the actual sector lengths would replace 512 if different.).
  • the starting sector is CPTLBA. Since the previous command is a CPT Input command, the card will send the data to the host based on the Media Card Specific command.
  • Examples of commands without input or output include “Command without data transfer”, “CPT Command abort”, and “CPT mode reset”.
  • Figure 17H shows "Command without data transfer”, as indicated by the 3 at byte 32.
  • Figure 171 shows a "status read” command, indicated by the 6 at byte
  • the status can be implemented as the response data.
  • the status will the first few bytes of the data read back.
  • Figures 17A- 171 are not restricted to any particular media protocol and are not media specific commands.
  • Figure 17J shows an embedded command specific to an SD or MMC card
  • Figure 17L shows an embedded command specific to a compact flash card.
  • Figure 17J shows the command format for the SD/MMC example.
  • the SD/MMC command fills the Media Card Specific command field.
  • the bytes 48-53 are the SD command, for example a secure read. Some of the flags are required and defined in the Media Card Specific flag field.
  • BLKH indicates whether the command is for a single sector or multiple sectors: 0 if single sector command is used and 1 if multi-sector command is used.
  • APP I for an application command.
  • Response Type is the SD response type depending on the command index.
  • the various entries in bytes 48-52 are the actual elements of the SD command, where CRC7 in byte 53 may be optionally set to 0.
  • the user can send status retrieve to get the response. This is shown in Figure 17K.
  • the response data will be returned as the first 6 bytes of the sector read.
  • Figure 17L shows the compact flash (CF) command format for an embedded command.
  • the command is in bytes 48-54 and provides the elements need to comprise a CF command.
  • Media Card Specific Flags byte 36-bit 2 to byte 37 are reserved for future commands specific to various card formats.
  • the third exemplary embodiment is implemented at the file level, as was the first exemplary embodiment.
  • the discussion will focus more on the details of what is placed in the file on the host side. Since device specific commands are embedded within file, there is no way to harm file system specific data such as FAT area. From the card's point of view, the different exemplary embodiments will appear similar, the difference more being with respect to how the information is packaged on the host side.
  • the third exemplary embodiment will be that of a secure link to a secure bus, such as that presented in U.S. provisional patent application 60/638,804, filed December 21, 2004, which is incorporated by above.
  • the file level implementation in addition to overcoming the sort of privilege problems that may arise with device driver level implementations, it is also possible to overcome a possible need to have special hardware to send special commands. For example, in some cases at the device driver level, there is a need to have to send special commands to access secure area of the SD card, but with file level implementation there is no longer a need for this as the information is packaged within file. So, as long as a file can be written and read, any command set can be sent and received with this implementation. [00151]
  • the embodiments of the preceding section are a card driver implementation, operating at the device input/output level. Between the host or PC application and the device or card driver is the operating system (OS) file system.
  • OS operating system
  • the third set of embodiments is a file I/O implementation, operating on the OS file system.
  • the host simply tells the file system to write a file to memory device, where the device specific command is again embedded. More details on the writing of files to a flash memory are described in U.S. patent applications numbers 11/060,249, 11/060,174, and 11/060,248, all filed February 16, 2005, and which are all hereby incorporated by reference.
  • these embodiments may require a little more firmware overhead than the device level embodiments, they can have a number of advantages. For example, at the device level, there is a need to have some knowledge of the hardware involved as an application is developed, whereas by using a file system this becomes independent of the hardware and independent of many details of the bottom level protocol
  • the file level embodiments can be used to send vendor specific command to respective vendor products, such as Advanced SCSI Programming Interface (ASPI) found in Windows 98/ME/95/DOS and similar examples.
  • ASPI Advanced SCSI Programming Interface
  • the device level embodiments described above use was made of a write to a specific logical address, the CPTLBA.
  • to access this logical address requires certain access privileges. For example, certain SCSI command cannot be sent to vendor products if the user has no administrator privileges.
  • the file level embodiments of the present invention circumvent this privilege problem by embedding the media specific commands in a file, writing the file to the device, and de-embedding the actual on the device.
  • the card level embodiment using the exemplary CPTLBA will require administrator privileges, while writing a file will not require any such special access privileges.
  • the exemplary embodiments embed the media specific commands in a data portion of an instruction.
  • the implementation at the operating system's file system level can again be implemented by the card's card firmware, which is adapted to comply and recognize the protocol. With a read/write command to any LBA, a signature is checked to determine if the data contains embedded media card specific commands. This differs form the device driver implementation where a specific address is used. In other ways, as seen from the card there is little difference between the device driver level embodiments of this section and the file system level embodiments of the preceding section.
  • the exemplary embodiment of a file-based implementation divides the protocol into an "instruction" part, in which the media specific command is embedded, and a "data in/out” part, if the command involves any data transfer, to hold the data associated with the command.
  • the firmware checks for a special signature during the read or write operation to determine if the given LBA is the instruction part, this need only be done for the first data sector of the protocol command for embodiments where the signature is always embedded in the first data sector.
  • the client application issues a simple file or logical sector (LBA) write operation having an instruction part and, maybe, a data in/out part.
  • the firmware performs the logical to physical mapping if the command involves either reading data or writing data to the media.
  • the firmware would detect API instruction part during what is received as a write or read from the transmission protocol.
  • the instruction portion of the protocol command will contains signatures, inquiry commands, vendor specific commands, and updateable fields.
  • the size will be restricted to a multiple of 512 bytes (which is the size of a most commonly used data block).
  • the format of the instruction page in the exemplary embodiment is shown in Figure 18 A, which is quite similar to Figure 17A but with additional detail.
  • the first 36 bytes are not encrypted, with the rest encrypted/decrypted according to the Encryption/Decryption information that states the presence of the supported encryption algorithm.
  • Bytes 0 and 1 are the signature bytes used to indicate an LBA that could be a candidate for API instruction pages.
  • the firmware will check the API signature if these two bytes match.
  • Byte 0 is 19, and Byte 1 is 73.
  • the API signature follows in bits 2-34 and is a string of single by characters. In the following example, the signature is taken as "Advanced Programming Interface".
  • Byte 35 is Encryption/Decryption (E/D) information that tells the firmware if the subsequent instruction pages and data pages are encrypted. If it is not encrypted, then this field should be set to API NO ENCRYPTION; otherwise, it should be set to encryption name so that the firmware can decrypt and encrypt the instruction page or pages starting from byte 36 and data pages.
  • Bytes 36-39 are the Firmware Operation Status Field field and will be updated based on the success or failure of the operation. It will be set to API OP SUCCESS if everything is OK; otherwise, it will be set to error values or API OP NO SUCCESS. It is suggested that its default value be set to OxFFFFFFFF when issuing command.
  • the caller can read instruction page to verify the whether or not the requested operation succeeded.
  • the Vendor Identifier field (Bytes 40-43) can be used as an unique vendor identifier. This field can be used by the calling environment to identify itself to the firmware if the firmware also requires a valid vendor ID.
  • the Number of Instruction Pages field (Byte 44) tells the firmware the total number of instruction pages, where the instruction pages are on the 512 bytes boundary.
  • the Number of Data Pages field (Bytes 45-46) tells the firmware total number of data in/out pages attached to the Instruction part.
  • Data page size does not necessarily mean the data size in bytes; in certain cases, padding may have been added to the end of the data bytes. For example, DES requires that the data size in bytes must be a multiple of eight.
  • the Data Size in Bytes field (Bytes 47-50) field tells the firmware total number of bytes within the data page than contain valid data. In the case of reading from the media, this field should be updated by the firmware with the actual processed byte size within the page area.
  • bits 1 and 2 are a flag for the direction of the data transfer.
  • the value "00" indicates that the data transfer is for input on the current command and the firmware will process commands during write time and will nullify the data pages once written to the media.
  • the value "01” indicates that the data transfer is for input on the current command and the firmware will process commands during write time with no nullification.
  • the value "10” indicates that the data transfer is for output on the current command.
  • the value "11” is reserved.
  • Byte 51, bit 3 to Byte 52 are Media Card Specific Flags and depend on the type of the media card.
  • Bytes 53-63 are f ⁇ eldsjeserved for future use.
  • the Media Card Inquiry commands field (Byte 64) will be used to inquire the current state and capabilities of the media card.
  • Known supports include: Is API protocol Supported; Get supported E/D algorithms; and Disable API Protocol Support.
  • the Media Card Inquiry Command Return Status field (Bytes 65-68) can be used to hold the return value of the Media Card Inquiry Commands.
  • Media Card Specific command length (Bytes 69 and 70) specifies the total number of command bytes that command field stores, where the real command that the media card will run is in Media Card Specific command (Bytes 71-511).
  • Appended to the instruction page(s) will be any data in/out pages.
  • the caller environment and the firmware based on established cryptosystem algorithm will encrypt/decrypt content.
  • the firmware must process the commands before writing and then write the instruction page only to the media so the user can read it back and see the status of the operation.
  • Figures 18B-F give several examples of media specific inquiry commands, such as a query for support of the API protocol used to check on whether the media card supports the API protocol before the real commands are sent.
  • a particular procedure is illustrated with respect to Figures 18B and 18C.
  • a file system When a file system is used to access the media, a file will be written having content of only one instruction page. The example of Figures 18B and 18C will demonstrate how to query the protocol through the file system.
  • Calling environment opens a file, say "myAPI.bin". To inquiry for support of the protocol, the caller can write 512 bytes, shown in Figure 18B, to the file and issues a write file command.
  • the media After issuing the write file command, the media will take appropriate actions, whether during the writing of the file to the media or during reading it. For the example, assume the media card processes the instruction page before writing. In this case, the following actions will be taken: a) Verify Signature Bytes b) If match, verify API signature c) If match, go through media specific flags if any. d) Check Media Card Inquiry Command request, which is 1 e) Verify that the data field and Direction field is 0 as there is no data transfer. f) Process commands, update the fields and write the file to the media. When the user reads the file, my API.
  • a second example of a media specific inquiry command is a query to determine which encryption/decryption algorithms are supported, where the media card must be checks if the API protocol is supported and active before this query. This is illustrated using Figures 18D and 18E.
  • a query for support of the API protocol discussed with respect to Figures 18B and 18C
  • Calling environment will write a file; say myAPI.bin.
  • the user will include 512 bytes as show in Figure 18D and issue a write file command.
  • an exemplary set of actions is as follows: a) Verify Signature Bytes; b) If match, verify API signature; c) If match, go through media specific flags if any; d) Check Media Card Inquiry Command request, which is 2; e) Verify that the Data field and Direction field is 0 as there is no data transfer; and f) Process commands, update the fields, and write the file to the media.
  • Another example of a media specific inquiry command is a query to determine if the media card supports the API protocol and if so, disable it. Similarly to the query to determine which encryption/decryption algorithms are supported, a file will be opened where the content of the file will have only one instruction page. Calling environment will open a file, say, again, myAPI.bin. To inquiry about the support for this command, a user could include the 512 bytes shown in Figure 18F in a file and issue a write file command.
  • Figures 18G and 18H show particular examples of file system based, media specific read and write commands.
  • the card Prior to issuing a firmware command to the media card, the card is checked to see whether or not it supports the API protocol. As with the previous protocol, if a file system is used to access the media, then a file will be opened with content of one or more instruction pages and any associated data pages.
  • An example of a media specific write command is shown in Figure 18G.
  • Bytes 51-68 of the instruction provide the previously described instruction information as needed for the specific command.
  • the actual embedded command has its length (in bytes) specified in bytes 69-70, which in this case is the single byte 71 contained the exemplary "D5" instruction indicating a write to a reserved or secure area.
  • the remaining area allocated for the media specific instruction (bytes 72-511) is then padded out with zeros to make a full sector.
  • the (here) 512 bytes of data for the actual specific command follow as the next sector.
  • the caller can verify if the operation has succeeded by reading the file from the media card and checking the Firmware Operation Status field. If the operation has been completed successfully, this field will be updated with API OP SUC CE S S or, if not successful, it will be updated with some error values or API OP NO SUCCESS. Note that since the direction was 00, the data pages should be Os or FFs.
  • an exemplary set of actions is as follows: a) Verify Signature Bytes; b) If the signature matches, verify the API signature; c) Check if the instruction page (from Byte 36) is encrypted; d) If encrypted, decrypt the Instruction page (from Byte 36) and data pages; e) Verify the Vendor ID signature; f) If the Vendor ID matches, go through media specific flags (if any); g) Check Direction and Data fields; h) Process the actual embedded, media specific commands; and i) Update the Instruction Page's Firmware Operation Status field, encrypt (if requested) the instruction page after byte 36, and write it to the media.
  • Media specific read commands can be implemented in a number of ways, some of which are discussed more in the following section. An implementation of a file system based, media specific read command, which is similar in structure to the write structure of Figure 18G, is described with respect to Figure 18H.
  • the media specific command is now D6 and Direction is 10, as it is reading from the media.
  • the flexibility to modify the content based on what command and established protocol are used. For example, the card can be told to write this file and the file has special command to tell firmware to encrypt the content before writing.
  • the written content may be transformed to another form before being written. The same can also be applied to read operation as well.
  • Figure 18H shows the case where the caller wants to issue a command (e.g. "D6" in the SD card command set) to read a sector of data from a hidden area and place it under the data page.
  • a command e.g. "D6" in the SD card command set
  • the calling environment will open a file and the user will prepare the data page as shown in Figure 18H, where the Vendor Identifier is again taken as "SNDK".
  • the Data field indicates that this is "output", so data page will be updated and Direction field tell the firmware to process the data during reading. Another possibility for firmware is to process the command, update the data page, and write it to the media. Consequently, the firmware will write the 1024 bytes to the media.
  • the firmware When the firmware reads the file, it will detect that this an instruction page, then it will read the command and update the data fields appropriately.
  • the caller can verify if the operation has succeeded by reading the file from the media card. Once file is read, the caller can check the Firmware Operation Status field. If the command results in a successfully completed operation, this field will be updated with API OP SUCCESS; if not, then it will be updated with some error values such as API OP NO SUCCESS.
  • the amount of data read can also be verified by checking the DSIB field to see whether it has been updated to 512.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Storage Device Security (AREA)
  • Communication Control (AREA)

Abstract

La présente invention concerne des techniques de transmission d'instructions spécifiques dune application entre un hôte et une carte mémoire. Les instructions pour le protocole spécifique de l'application sont intégrées conjointement avec une signature dans la partie données d'un protocole de transmission utilisé pour la communication entre l'hôte et la carte mémoire. Il est ainsi possible de transmettre des instructions spécifiques de l'application dans le protocole de transmission bien qu'une instruction correspondante manque dans ce dernier. Ce procédé peut être mis en oeuvre du côté hôte soit au niveau pilotage de dispositif, soit au niveau fichier. Pour l'exécution d'une instruction de lecture dans le protocole spécifique de l'application, une instruction d'écriture du premier protocole avec instruction de lecture incorporée est d'abord envoyée à une adresse logique, suivie d'une seconde instruction de lecture à cette même adresse.
EP06848795A 2005-12-08 2006-11-30 Carte media avec logique de mecanisme transfert direct d'instructions Withdrawn EP1958049A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US11/298,349 US20070136501A1 (en) 2005-12-08 2005-12-08 Media card command pass through methods
US11/299,186 US20070168668A1 (en) 2005-12-08 2005-12-08 Media card with command pass through mechanism
PCT/US2006/061416 WO2007076214A2 (fr) 2005-12-08 2006-11-30 Carte media avec logique de mecanisme transfert direct d'instructions

Publications (1)

Publication Number Publication Date
EP1958049A2 true EP1958049A2 (fr) 2008-08-20

Family

ID=38201318

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06848795A Withdrawn EP1958049A2 (fr) 2005-12-08 2006-11-30 Carte media avec logique de mecanisme transfert direct d'instructions

Country Status (5)

Country Link
EP (1) EP1958049A2 (fr)
JP (1) JP2009518759A (fr)
KR (1) KR20080089586A (fr)
TW (1) TW200809593A (fr)
WO (1) WO2007076214A2 (fr)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9032154B2 (en) * 2007-12-13 2015-05-12 Sandisk Technologies Inc. Integration of secure data transfer applications for generic IO devices
US8880483B2 (en) 2007-12-21 2014-11-04 Sandisk Technologies Inc. System and method for implementing extensions to intelligently manage resources of a mass storage system
DE102009019982A1 (de) 2009-05-05 2010-11-18 Giesecke & Devrient Gmbh Verfahren zum Zugriff auf einen tragbaren Speicherdatenträger mit Zusatzmodul und tragbarer Speicherdatenträger
USRE49682E1 (en) 2009-12-17 2023-10-03 Kioxia Corporation System, device, and method for initializing a plurality of electronic devices using a single packet
CN102014528B (zh) 2010-04-28 2012-04-18 华为终端有限公司 一种无线上网设备、系统及方法
TWI526838B (zh) 2013-02-27 2016-03-21 東芝股份有限公司 記憶體裝置
US9824004B2 (en) 2013-10-04 2017-11-21 Micron Technology, Inc. Methods and apparatuses for requesting ready status information from a memory
US10108372B2 (en) 2014-01-27 2018-10-23 Micron Technology, Inc. Methods and apparatuses for executing a plurality of queued tasks in a memory
US9454310B2 (en) 2014-02-14 2016-09-27 Micron Technology, Inc. Command queuing
JP2019191804A (ja) * 2018-04-23 2019-10-31 大日本印刷株式会社 セキュアエレメント発行システム，セキュアエレメント，発行データ生成装置および発行装置
JP2021163997A (ja) * 2020-03-30 2021-10-11 キヤノン株式会社 撮像装置、デバイス、通信方法、及びプログラム
JP2021163998A (ja) * 2020-03-30 2021-10-11 キヤノン株式会社 撮像装置、デバイス、制御方法、及びプログラム
CN114928377B (zh) * 2022-05-11 2023-04-21 威创集团股份有限公司 降低usb数据透传带宽的输出传输方法、装置及设备

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040064612A1 (en) * 2002-09-26 2004-04-01 Sandisk Corporation Method and system for using a memory card protocol inside a bus protocol
US7334077B2 (en) * 2003-10-17 2008-02-19 Renesas Technology America, Inc. Method and apparatus for smart memory pass-through communication

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2007076214A3 *

Also Published As

Publication number Publication date
TW200809593A (en) 2008-02-16
WO2007076214A2 (fr) 2007-07-05
WO2007076214A3 (fr) 2007-11-01
KR20080089586A (ko) 2008-10-07
JP2009518759A (ja) 2009-05-07

Similar Documents

Publication Publication Date Title
US8417866B2 (en) Media card command pass through methods
US20070136501A1 (en) Media card command pass through methods
US20070168668A1 (en) Media card with command pass through mechanism
US8806128B2 (en) System and method for information security device with compact flash interface
US8528096B2 (en) Secure universal serial bus (USB) storage device and method
US8375151B1 (en) Command portal for securely communicating and executing non-standard storage subsystem commands
US9026683B1 (en) Command portal for executing non-standard storage subsystem commands
TWI398792B (zh) 數位鑰匙方法及系統
WO2007076214A2 (fr) Carte media avec logique de mecanisme transfert direct d'instructions
EP2109842A2 (fr) Procédé et système pour une communication entre un dispositif usb et un hôte usb
US20120124380A1 (en) Usb composite device and method therefor
KR19980019162A (ko) 디스크 장치
JP2001512270A (ja) 小型制御装置とセキュリティ構成部品を備えたチップカード読取り装置
WO2007102901A9 (fr) Carte à puce grande vitesse pourvue d'une mémoire flash
US9250930B2 (en) Configuration method for an electronic entity
EP1997083B1 (fr) Carte à puce configurable automatiquement et procédé de configuration d'une telle carte
CN102422256A (zh) 用于访问具有附加模块的便携式存储数据载体的方法和便携式存储数据载体
US11914879B2 (en) Storage controller and storage system comprising the same
EP2849111B1 (fr) Génération des OTP sur un dispositif portable
CN1284090C (zh) 含指纹传感器的存储器储存装置及其储存数据的保护方法
CN119783175A (zh) 一种与外置安全加密芯片搭配nvme固态存储设备的嵌入式数据保护处理系统
WO2022068298A1 (fr) Procédé d'accès à un disque flash usb et disque flash usb
US20070022222A1 (en) Memory device and associated method
CN102223227A (zh) 安全智能密码存储芯片及其通信文件自动重建方法
KR101023100B1 (ko) 유에스비 뱅킹 장치

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20080505

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20090217

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20090603