TW200809593A - Media card with command pass through mechanism - Google Patents

Abstract

The present invention presents techniques for transmitting application specific instruction between a host and a memory card. The commands for the application specific protocol are embedded along with a signature in the data portion of a transmission protocol that is used to communicate between the host the memory card. The allows for the transmission of application specific commands that lack a corresponding command in the transmission protocol to still be transmitted in that protocol. The method can be implemented on the host side either at the device driver level or the file level. In order to implement a read command in the application specific protocol, a write command in the first protocol with an embedded read command is first sent to a logical address, followed by a second read command to the same logical address.

Description

200809593 IX. INSTRUCTIONS: TECHNICAL FIELD OF THE INVENTION The present invention relates generally to the use and structure of removable electronic circuit cards, and more particularly to allowing a personal computer or other host to support a particular computer by The reader of the media card command and/or the host software use these commands. [Prior Art] Recently, small flash memories such as C0mpact Flash Card, Secure Digital (SD) card, MultiMediaCard (MMC), and Sony Memory Stick/Memory Stick ΡΓ0 Cards have been widely accepted by consumers. These devices are primarily designed for consumer electronic devices such as digital cameras and flash memory music players. However, it is also necessary to have a convenient connection to a personal computer for uploading and downloading data. Different cards have different electrical interfaces and typically have commands specific to the media that can be used by the host for the card. In addition, since these cards are activated to overload the additional functions between the cards and the cards, the card agreement may differ not only between card form factors, but also between cards of the same form factor. These commands typically have unique features such as specific input-output (I/O) and safe operation. Because the use of such cards becomes more diverse and they continue to be used for more types of applications, such new applications will typically involve features or commands that are not available in existing agreements. Examples of commercially available non-volatile memory cards having different mechanical and/or electrical interfaces include related multimedia cards available from Corporation of Sunnyvale, Sunnyvale, California, the assignee of the present application. 116844.doc 200809593 (" MMC") and Secure Digital ("SD") memory card. There are other cards that comply with the standards of the International Organization for Standardization ("ISO") and the International Electrotechnical Commission ("IEC"). The widely implemented examples are known as the IS0/IEC 7816 standard. The physical and electrical specifications of MMC are given in the "The MultiMediaCard System Specification"1, which is continuously updated and published by the MultiMediaCard Association ("MMCA") of Cupertino, California. Versions 2.11, 2.2, 3.1, and 4.0 of this specification dated June 1999, January 2000, June 2001, and February 2004 are expressly incorporated herein by reference. MMC products with varying storage capacities of up to 128 megabytes in a single card are currently available from SanDisk Corporation. These products are described in the MultiMediaCard Product Manual" Revision 2, published by SanDisk Corporation in April 2000, the disclosure of which is incorporated herein by reference in its entirety. U.S. Patent No. 6,279,144 and in Some aspects of the electrical operation of the MMC product are also described in the application Serial No. 09/186,064, filed on Nov. 4, the disclosure of which is incorporated herein by reference in its entire entire entire entire entire entire entire entire entire entire entire entire entire entire entire all Such applications and patents to SanDisk Corporation are expressly incorporated herein by reference. A newer SD card is similar to an MMC card, except that it has the same thickness to accommodate the additional thickness of the additional memory wafer. The main difference between them is that the SD card includes additional data contacts to enable faster transfer of data between the card and the host. (The version of the MMC card with additional data contacts is also available, see above The MMC specification version 4.0 is described in the text. The other contacts of the SD card are the same as those of the MMC card, so that the slot designed to accept the 116844.doc 200809593 SD card will also accept MMC. The slot designed to accept the SD card can also be further manufactured between the SD card and the MMC card as described in US Pat. No. 6,820,148, which is incorporated herein by reference. An electrical interface and a functional interface are described in U.S. Patent Application Serial No. 09/641,023, filed on Aug. (The specifications of the SD card can be used by members of the SD Association (SDA).) Cards manufactured according to the ISO/IEC 7816 standard have different shapes, have surface contacts in different positions, and are different from MMC and SD cards. Electrical interface. The ISO/IEC 7816 standard has the overall title "Identification cards-Integrated Circuit(s) Cards with Contacts" and consists of parts 1 through 1 of individual periods from 1994 to 2000. This standard (a copy of which is available from Geneva, Switzerland, ISO/IEC) is expressly incorporated herein by reference. The ISO/IEC 7816 card is particularly suitable for use in a safe manner (which makes data extremely difficult or impossible) An application that stores data in an unauthorized manner. Small ISO/IEC 7816 cards are commonly used in cellular phones and other applications. As mentioned above, when these cards are used for new In the application, it may require features or commands that are not available in the existing version of the agreement. This can be illustrated with reference to Figure 1. As shown in the upper part of Figure 1, the goal is to exchange commands and data between the host side and a particular application on the card side (e. g., in a secure data transfer or e-commerce application). In order to implement this goal, the commands will need to be transferred between the host and the card, with the lower part of Figure i showing some of the soft layer on the host side and some of the firmware layers on the card side. 116844.doc 200809593 The instructions from the application layer of the host will be passed through the operating system, the file layer and the device (card) driver, terminating in the protocol by which they can be transferred to the card. Within the card, the instructions are then processed by the device layer firmware (which handles standard card operations) and passed to the application layer of the firmware. Depending on the configuration being used, the instructions in the transport protocol will be exchanged directly from the host to the card or via a mated reader or hardware to the card, which may have its own use. A software/firmware layer that translates from one agreement to another. One of the problems with this is that a certain stage of the translation between these layers' application expectation of the application may lack the corresponding command at some point along the path. As an example, a card is typically connected to a Pc host by using a hardware adapter that accepts commands from the host system (e.g., for USB). However, many specific media commands cannot be used in a protocol whereby the host and the hardware adapter communicate, even if the host application of the host computer wishes to transfer such commands to the card application. 2 shows a system of a first host and a card, wherein the card 101 can be connected to the host 151 either directly (e.g., by being inserted into the slot 153) or via some sort of adapter. The card tough system is indicated by FW105. (Refer to the card firmware 1〇5 and the reader firmware 335 in Fig. 3, it is understood that these functions can be implemented in hardware, software, or some combination of such hardware and software in general). An example of this host 151 can be a digital camera or a telephone. Several types of such cards are currently in progress and under development. Cards and hosts may pass through a number of specific protocols, many of which are specific to a particular medium and which may include various specific media commands. Can be specific to the media (4), so 116844.doc 200809593 The following situation occurs: When this command is to be exchanged between the host and the media, the command will need to be translated somewhere along the line to another one that may not support the specific media command. agreement. If this other agreement does not have a corresponding command, the host will not be able to successfully issue the command. For example, in addition to its use for a host computer, it is also typically used by a user to access a card on a personal computer. For example, it is typically used for a card that has been used, for example, in a digital camera and that wishes to access a card stored on a personal computer. This is illustrated by the box plot of Figure 3. The card 101 is typically in communication with the personal computer PC 351 via a card reader 331 having a socket 333 for the card 101, although in other cases the card can be attached directly to the PC 351. Reader 331 and PC 351 will typically communicate via a protocol that differs at least to some extent from the protocol used by card 101 to communicate with host 151. The reader 331 translates commands from the PC 351 into a form suitable for the card 101 based on the body 335 (or hardware, software, or some combination of such hardware and software), wherein it is generally understood that the visual implementation This function is performed by any combination of software and hardware. This process is schematically illustrated in Figure 4. To give a concrete example, in FIG. 4, the reader 331 is regarded as a USB device that communicates with the PC 351 using the SCSI command set and regards the card 1〇1 as an SD card. Since the PC 351 and the reader 331 use the SCSI protocol, when the host wishes to issue a command to the card via the reader, it issues a command 401 in the SCSI command set. To transfer the command 401 to the reader, the command 4〇1 is placed in the uSB package 403, transferred to the reader along the USB connection, and the uSB package is removed there. The card picker 331 will then translate the command 4〇1 from the SCSI command set into a corresponding command or multiple commands 4〇5 in the SD set, thereby allowing it to be passed to the card 116844.doc 200809593

Therefore, it is not possible to pass this media card specific command from the host to the card, adapter or reader without changing the adapter or reading the sorrow: 3⁄4 itemizer firmware The Bosch Control (hGSt) media card introduces its corresponding commands for communication with the host. A similar situation can occur even when there is no stand-alone card reader when it is known that there is a need for a change in the agreement or when the operating system of the host does not know the card features. In order for the reader to switch between the coffee command set and the call set..." requires equal commands in both sets. Therefore, if the host wishes to execute by issuing a secure read command in the agreement (for example) The reading of the security zone is called, because there is no such equal-order command, so the buyer cannot enter the light because it is not found in the SCSI command set# and the read request will be regarded as its towel (four). An area with insufficient access rights. The same will occur for other specific media commands of the card type, where equal SCSI for the host is sent to the green extractor in the agreement understood by the reader. Command or multiple ^csi commands / In the prior art, the method of this problem would be to change the adapter firmware to support specific commands for transmitting such instructions via the adapter or in a reader-host protocol New commands are created, each of which is customized to suit a particular media command, such as a particular media command corresponding to a send query command, a receive response command, etc. in an agreement such as an SD card. due to For many reasons, it tends to be impractical. For example, such agreements are usually based on a standard (which needs to be widely accepted in order to be a useful standard and tends to prefer a less complex set of commands; therefore, when bowing When entering new media and existing media development, it is difficult to introduce various new specific media commands into the command 116844.doc -11- 200809593. If instead, change the adapter body to allow specific commands to pass _ body itself does not support With their specific media commands, each software vendor of these adapters will need to accept and make appropriate firmware changes. Therefore, the introduction of personal computers can take advantage of various specific media commands without having to change the reader. Or the method used by the host-reader protocol would be of great benefit. More generally, even when the card is directly connected to the host, the protocol will need to be updated because the '# specific application command is introduced. Even if it is correct ❿ 5 See the agreement to expand and standardize to have new features, which still introduces the compatibility of the old version or the problems of other vendors. This greatly undermines the utility of the 'standardization agreement.' In addition, although these agreements can be adapted to new applications, this may only be a temporary solution because of the increased use of the application to extend the use of the card. Therefore, it is similarly necessary to adapt to a situation in which the operating system of the host does not support a specific media command. [Invention] Therefore, in summary, and in general, the present invention provides a device such as a memory card or other integrated circuit. Card) A method and technique for exchanging applications or specific media commands with a host. The host and card can communicate directly or via a reader or hardware adapter, the reader or hardware adapter The specific application command is transmitted via a protocol in which the specific medium has an equal command. For example, in an embodiment, even if the card reader does not support the command, the pc can also pass the card reader. And read 81) (safe digital) memory card security data area. More specifically, the host forms a twisted command with an order in the agreement supported by the communication between the host and the card 116844.doc -12 · 200809593, while the actual media or specific application commands are within the command Embedded in the instruction φ ^ ^ Τ. In the exemplary embodiment, the specific media command is embedded in the data section of the instruction VIII + ^ 竹 邵 >. Then the card receiving agreement card communicates with the host via the protocol) The private order and translate it into an application agreement. The command is transmitted in transparent form. For example, when the transfer agreement can actually contain a specific media command, the transfer protocol just passes To the card where it is considered to be the information. A slap in the face ^ in the card, it will identify the actual life

々 is embedded in the instruction and continues to extract the finger phase 7. This straw is included in the data portion of the decision command - the signature money line: if the signature 1 is extracted and executed, the command is not found, the command is executed (4) (4). In the exemplary embodiment, the signature and the embedded command P 7 are set. Placed in the first section of the lean section. The actual command is extracted in the implementation of the conversion on the device side, and in the host side, the device drives the pure level _ (four) layer command. The device driver hierarchy implementation addresses commands to specific logical block addresses while any logical block address is available at the file level. Although the device driver hierarchy implementation requires less additional use, h + A β , and f is used, in many operating systems it may require access rights that are not available to the user. The various aspects of the invention are not limited to the condition that the card agreement has an order without an equal command in the agreement between the host and the hardware card reader, and is limited to the other in which the intermediate agreement needs to carry the command it lacks. situation. The first set of embodiments considers a situation in which a card can communicate directly with the host by its own agreement, but the card (or other device) has an application that has an additional feature set that requires the use of an additional command set. These commands are not part of the standard agreement used by the host to communicate with the card, or are not supported by the standard operating system on the mainframe 116844.doc -13 - 200809593. Because & requires specific components to pass these commands back and forth between the application on the card (which can be implemented at the Leiter level) and the application on the host (which can be implemented at the software level). In the principle aspect of the invention, the application command is embedded in the data portion of the instruction in the intermediate agreement, in which case the intermediate agreement is a card agreement. In another example of the invention, this is accomplished by having a set of commands associated with opening, closing, and managing the path from the host application to the device. The second exemplary embodiment is implemented at the device (card) driver level and uses an instruction that specifies a specific logical block address (LB A), card transfer (cpT) mode LBA, and the card transfer (CPT) mode LBA. There is a specific signature to inform the card that a particular command is embedded in the segment. This can be implemented as a change in the card firmware so that it supports the CPT mode. This eliminates the need to change the firmware of the adapter according to each particular media command so that the card can be executed at any (eg) USB reader or adapter without having to perform specific media adaptations (or changing the host's operations) System (〇s) 'Enables the card to be used under any 〇s. The card firmware continues to perform a normal read command/write command. In the case of a read command/write command to a particular LB A offset, a signature is checked to determine if the material contains an embedded media card specific command. The agreement can be implemented in the firmware of any media card. Therefore, the firmware of the adapter or USB or other reader or host 〇s is not required without changing the reader firmware. A third set of exemplary embodiments is implemented at the file level on the host side. Specific media commands are once again embedded in the intermediate agreement, but instead of relying on hardware details and reference to specific agreements, the embedded commands and any accompanying materials are placed in the archives. In the data section, the file is then transferred to the media, where the firmware extracts the actual command again. In these embodiments, the host only informs the file system to write the audit file to the memory device, where the device specific command is again embedded in the data portion. In the case of a read command/write command to any LB A, in contrast to a particular logical address, the device checks a signature to determine if the data contains an internal media card specific command. The illustrative embodiment places this signature in a first data section in any of the archives associated with the write command. If an appropriate signature is found, the embedded command is extracted; if no signature is found, the command is interpreted as a standard command of the intermediate agreement. In this manner, the file level embodiment of the present invention allows for the circumstance of privilege issues that arise with the use of specific logical addresses in device level applications, as files are typically allowed to be written to the device in the operating system. In all of the illustrative embodiments, the embedded command is placed in the data portion of the write command in the intermediate contract. For example, a write command for, for example, N segments in a device or a specific application agreement will consist of a write command in an intermediate contract with (Ν+ι) resource segments, the first segment Contains the actual embedded write command and the remaining sections contain the actual to be written. 'The command (and signature) can be placed on the device along with any data to be sent by the embedded command to the device. In any of the commands associated with the data section. To implement a read command or other command in a device or application-specific protocol that requires data to be transferred from the device to the host, an exemplary implementation - using - for τ τ. The first command will again be in an intermediate contract with a data segment. Write command, which corresponds to the embedded read command (and does not have real data associated with the embedded read); the actual data transfer from the device to the host is followed by the first command 116844.doc -15- 200809593 ( Implemented by a host that is addressed to the same logical address as the first command. Additional details, features, and advantages of the invention will be apparent from the description of the appended claims. [Embodiment] In the main case, the present invention allows an application on a host (usually a software that uses an application on a card) and an application on the card (usually implementing these additional features as a card) Commands that are not part of the standard card (or are not supported by the standard 〇s on the host) are passed back and forth between the application-specific Bobs. The exemplary embodiment accomplishes this by embedding a particular command in a standard command (such as a writer) supported by any host. This allows a memory card such as that described in the [Prior Art] segment to be used on all standard host devices and PCs, and to allow unsupported additional non-standard features to be used as standards in the system. . As a specific example, see the feature described in the prior art with respect to Figures 2 through 4'. These methods allow commands dedicated to the SD card (such as secure reading) to be transmitted via a protocol lacking an equal command. In general, this is accomplished by forming an instruction consisting of a portion of the command that exists in the transport protocol and an "embedded: data portion of the particular media command. By way of example, because the writer command is a basic command for the memory card system, it = exists in the transmission protocol and has an associated data portion. Place the actual application command with the signature in the data section to indicate that the special U body command will be executed. Any information associated with the actual money-specific media order to be transmitted to the device is also placed in the information of the order of the transmission agreement 116844.doc •16- 200809593. For the SD/USB instance, in order to send the read and read of the ten segments to the SD card in the USB protocol, the command is issued in the Cong Agreement containing a command and ten data segments. The section contains the actual compromised write command and a signature and related information, and is then the ten sections of the data to be written. When received in the card, the blade extracts the actual security write command, checks the signature, and performs the reading of the data. " For the read (and other commands to transfer data from the device to the host), the write command in the EM's intermediate protocol can be used again to carry the embedded read command, but since this is not provided back to the host The information, so it is now paired with the second read command in the intermediate agreement. More specifically, the first command in the pair will be a write from the host with an inline read command to the logical block address lba = xyZ2 (in an intermediate contract). In a device driver level implementation, the logical block address LBA = XYZ will be a specific address, and for a broadcast level implementation, this can be any address. The second command in the pair is then read by the standard host with the same address LBA==XYZ. The specific data is then transferred to the host. More generally, the present invention allows for the exchange of programming or specific media instructions between a host and a card by severing the desired command with any accompanying information in an intermediate or transport protocol that can be used by the system. A specific command is resolved between a particular application on the host executing on the . side and a corresponding application on a particular card on the other side. At the intermediate point along the transmission path, the instruction is presented as a normal command with an intermediate protocol, transparently passing the actual specific application command. In an exemplary embodiment, this is done by using a command in a transport protocol that accepts a data portion (such as writing 116844.doc -17. 200809593 P 7) and by using λ inter-application private or specific media commands. This data section is carried out in the knife. (In some respects' this is an extension of the invention described in U.S. Patent Application Serial No. 89, the commonly assigned application in the same application. In this article.) When the instruction (in the transport protocol) arrives at the cut, the data portion is checked to see if it contains the appropriate signature' and if the appropriate signature is included, the (four) command is extracted. This is shown schematically in Figure 5. Figure 5 is a schematic representation of how a specific application command is in accordance with a particular embodiment of the present invention, which is used to pass the agreement from the host application to the card side of the application. Consider the condition of the towel application or specific media instructions - the command part, cmd, and a corresponding piece of data. For example, CMD can be written for special applications. To transmit this command, the host side will use the command in the transport protocol, which is called CMD, such as a write command, which has a corresponding data portion. Any commands placed in the data section of this directive will simply be passed; therefore, if the actual expected specific application command CMD (along with its corresponding material) is embedded in this data, then even in the transport protocol The command cMD is not recognized and will be transmitted to the card. Once in the card, the command CMD will need to be extracted from the data section. This is also done by placing the card with a signature (cpT signature) in the data portion: when the incoming instruction arrives on the card, checking the signature in the data portion, and if the signature is found, then extracting the actual command . In Figure 5, the instructions in the transport protocol containing the embedded commands are shown at 510. The command portion 511 has a command CMD and can be regarded as a "dummy" 116844.doc -18-200809593 order that will not actually be executed but is used to transfer the data portion 513 to the card side. The data portion 513 can be divided into a first portion 513a having a signature and an actual command cmd and a second portion 513b corresponding to any material of the CMD. For example, if CMD is a type of write command, then 513b will be the data to be written, and if it is, for example, a status check, there will be no 5 13b. (As further described below, it is more likely to be an inline read command because (in this embodiment) it involves the write command CMDI in the section 511 of the transmit transport protocol and the inline in the section 513a of the data portion. The command 〇1^1) and the non-real data portion 513b are read. On the card side, the signature of 513a is then checked and if no signature is found, all of the commands CMD' and 513 are executed as material. If a signature is found, the actual command 53 具有 having the command portion 531 containing the command CMD and any corresponding data in the data portion 533 is extracted. (In the command part, there is enough space such as scs; [in the agreement, the CPT signature, the command CMD, or both of them can be embedded in the command part of the transmission agreement instead of the data part.) In a more abstract description of the invention, the present invention allows the host side of the application to communicate with the card side even if it needs to communicate with each other using a protocol that is not applicable to the application somewhere along the path. This can be the case when the adapter does not understand the card features (as described in the prior art) and the host operating system does not understand the card features. This resolves the issuance of media or specific application commands for systems with or without host adapters between the host and the card. In addition, it allows for situations in which the card agreement can differ not only between card form factors but also between various cards of the same form factor, since there may be additional differences between the card and the card as these cards are becoming overloaded Features. This configuration allows a system in which the card adapter and host 〇s are independent of a particular card agreement 116S44.doc -19- 200809593, where a particular application on the host executing on the - side is specific to the particular card on the other side Analyze specific commands between applications. On the host side, the present invention can be implemented at the file system level (where the application is using the host file system and writing to the file in the file mode) or can be implemented at the device driver level (in a device driver mode) . Specific examples of the two versions are given below. Which type of embodiment is preferred will generally depend on details such as the specific application and details of the operating system. For example, implementation at the device driver level is generally simpler and requires less software/firmware extra consumption, but uses direct writes to logical addresses; however, this direct write requires management that the user will lack. Permissions. By using the file system hierarchy instead, this complexity can be avoided, but at the expense of additional overhead. The invention will be illustrated by a more detailed description of three specific embodiments. All such embodiments allow for the use of specific non-standard features to be implemented in the card without changing the host card agreement to support the new feature or by using the intermediate software/hardware that does not support the additional protocol. On the host. The second and third sets of embodiments describe two methods implemented on the host side (at the device driver level and the file system level, respectively) while the first embodiment describes the card side implementation. This first embodiment supplements the second and third embodiments and describes how the card side operates and will also be used to provide a more general detail of all embodiments. As described more below, this is done using standard available commands to envelop non-standard commands. For each of these isoforms, the exemplary embodiment is selected to be supported by standard read writes. It should be noted that in these particular embodiments, the card does not need to recognize the concept of a file, as 116844.doc -20-200809593 is a write to a particular logical block address (10) A) in all of these embodiments. This LBA can be specifically configured (or reconfigured) for this purpose (as in device driver mode) or can be any address (in file driver mode). The main difference is that on the host side (where the application is using the host file system and writing the file to the file in the broadcast mode, and in the '弋 it is using the device driver and writing directly to the lba. In the following The various embodiments of the present invention are presented in the context of a particular embodiment of the invention, and the embodiments have intercepted a particular media command into the data portion of the write command. 'The media or specific application commands can be succumbed to other commands. Similarly, the discussion in [Prior Art] is based on a specific hardware configuration with a specific protocol domain; that is, where pc, the host uses one in the host and reads The agreement between the devices and the second agreement between the reader and the card communicates with the card via the hardware reader. These embodiments can be generalized and extended in several ways. [Prior Art] Focusing on instances in which a card communicates with a pc via a reader. More generally, 'when (in somewhere in the path between the host (eg, pc) and the final destination) use does not have one or more of the required transmissions Order The various aspects of the invention are applicable when the agreement of the order is applied. As mentioned, except that the hardware card reader does not have an equal command in the card agreement that does not have a particular media command that the host wishes to send to the card (eg In addition to the problems that occur when communicating with the host (for example, USB/SCSI), the problem can also occur when the card is directly attached to the host. In more complicated situations, There are several intrinsic layers that can be used in this situation, as will be seen in the second example. 116844.doc -21. 200809593 as when there is no need to have a separate card read For a specific example of the device, there are cards with two sets of contacts... the groups are used for the serial use and the other groups are used for the card contacts of the standard group (MMC, SD, CF, etc.) (both in 2 (10) 4 years in April Examples of such dual contact cards are described in U.S. Patent Application Serial No. 4, the entire disclosure of which is incorporated herein by reference. In the case of using "normal" card contacts, the card can be = specific media life Having the card specific agreement communicate with the host. In the case of using the second set of contacts (here 'consent'), the card can communicate with another host, such as a pc, in a different agreement that lacks an equal command for a particular media command. In this case, the second host communicates with the card in other protocols in which specific media commands are embedded in accordance with the present invention: for example, using a delete point, the card can be directly connected at the smart (4), thereby using (d) In the case of any of the SD specific commands in the SCSI protocol as described above, it communicates in the scsi protocol. As mentioned, in a particularly relevant set of embodiments, the host communicates with the card in a card agreement, but the host application The program may wish to exchange commands and data with the application on the card, where the card's "normal" memory function is not known at one level of the card. For example, an SD memory card can be segmented by a device application layer hidden from an SD specific firmware layer. The host and card will communicate using the standard 8]0 protocol, but the hidden device application can communicate with the corresponding host application by embedding specific application commands in the SD protocol. The first exemplary embodiment is of this type. The illustrative embodiments embed specific media (or application specific) commands within a write command. The write command is used to embed the command in the intermediate agreement. 116844.doc -22- 200809593

The instance within the material portion and the write command inherently have a data portion. More generally, not only can the write command be utilized similarly, but any command in the data portion can be similarly utilized. Since the write is a basic instruction in the protocol for transferring data, the following exemplary embodiments will continue to be based on the write-description description. In addition, although for the sake of simplicity, media or application-specific commands are lost in all instances for simplicity. At the beginning of the data section, but more generally 5' it can be placed elsewhere in the data section and identified by the signature. (As mentioned above, more generally the 'signature, application command, or both, can also be embedded in the command portion of the transport protocol (such as the SCSI protocol) in the agreement (with sufficient space in its command portion) The problems involved in the present invention can be presented at a more abstract level. Consider the host application in the basin needs to have a combination of command sets (α, β, γ, ...): communicate with the device should be 'but' need to use the wide p 7 set somewhere in the communication path ,...) another agreement. In the example of [Prior Art], (0", ...) will be the agreement and the intermediate command set (8, 3, ...) will be the agreement. In the following discussion, (α, ρ, γ,·..) will be the command set for the specific application private (blocking such as hidden segmentation) and (A, B, ..) will be replaced by the card command set. As long as there is a corresponding relationship A~, p, etc. There is no problem. When there is a medium or a specific application that does not have an equal command in the intermediate agreement: γ (for example, a secure read in the SD protocol), there is a difficulty. Under the prior art, Need for each - this γ ~ equal command (for example, C (one) γ). Paste or, according to the priest & " eight meat invention, the specific media command is defeated in the existing command in the intermediate agreement (Α (γ) ^, shows a write (for example) command with γ embedded in it, instead of introducing a new command. 116844.doc •23· 200809593 In general, 'introducing a command (called it as ?) (α, p, 丫, ...) in the agreement to open the pipeline between the host side and the device side of the application. Once the pipeline is open, it can be sent Particular application as a lance or command type. This is expressed as BU continued ⑺ gamma]. In the first example, the development of this technology. This allows processing and other nuances of command failure. Failure of the command in question has

Yu: As far as the agreement is concerned, it is sending a simple write command, so the intermediate agreement does not understand the nature of the embedded command. If the internal command is, for example, read, the pc will not know what has happened in the event of a read failure. In an intermediate agreement, it is considered a writer failure and is not interpreted as an inline read = failure; therefore, the host will not (4) resolve the appropriate recovery steps to be performed. By opening the pipeline between the host side and the card side of the application, it is easier to track down and handle these difficulties. First Exemplary Embodiment The first exemplary embodiment is implemented in the (four) hierarchy of the main system and will be used for the various aspects of the present invention, 4; on the card side, whether the host side is implemented at the level of the Tan or the implementation At the device driver level, the real purity is largely the same. When referring to the particular application of this embodiment, it will be given in the content of the hidden partition on the memory card, where the memory is divided into a publicly accessible portion and a private (or "hidden") portion. This configuration is described in the U.S. Provisional Patent Accessory Application No. 6g/63M() 4 filed on December 21, 2004 (which is incorporated herein by reference). Most of the details are not so limited. Hundreds of first: Describe the host side part (in detail, the device driver), then describe the card, and - Tian. Other examples of the use of hidden segmentation are described in the following patents, and Wangkou P is incorporated herein by reference: in the second secret year of February 116, 116844.doc -24-200809593, application ll/067,298; I〇/7〇3,471 applied for on ι〇日 in November 2003; i〇/899,260 applied on July 26, 2004; and 11/050,013 applied on February 2, 2005. Fig. 6 is a schematic block diagram showing an exemplary structure of the device side. On the card 1〇〇1 side, the device application or the plurality of applications 1〇23 respectively provide a host application or a plurality of applications 1主机53 for the host side 1051 to non-standard card features for this particular form factor ( Here is the gateway or ''official line' of the hidden partition). The case of the host side layer is more described below in Fig. 7. On the card side, the device application 1023 supplies split access (read and write) , status and other device application information. The device application 023 can communicate with the host application program 153 via the exemplary protocol described below and use the card system and memory resources via the media layer 1025. 1〇11 indicates the memory itself and it will typically be a NOR or NAND type of flash memory, although it may be other non-volatile memory, including US Patent Application May 7, 2004 Their memory is described in 1 〇 / 841, 379 (hereby incorporated by reference). FE (front) layer 1 〇 21 is a firmware layer that processes commands from the host side (in such as CF) Card types such as SD, MMC, etc. The BE ("Backend") layer 1027 is a firmware layer that handles management of the memory loii, including reading and writing to the memory. The media layer 1025 will device the application firmware 1023 and BE. Layer 1027 is connected and also interfaces to the RAM resources of the application and the controller. The controller is not specifically shown in this figure. When the command is sent from the host 1051, it is initially on the device 1001 at the front end (FE). The instruction is received at layer 1021. The command will be in the host and device 116844.doc -25- 200809593

In the intermediate agreement used (for example, the SD Agreement). When the command arrives at the FE layer 1021, the 'check command passes the signature: if the signature is not found, the instruction is treated as a standard instruction from the intermediate agreement and the instruction can access the memory or execute the instruction in a standard manner; if the signature is found , extracts the embedded specific application command and passes it to the appropriate device application 1〇23 for execution. When implemented at the device driver level (host side) (as in the second example embodiment below), the command is addressed to a specific logical address while being implemented at the file level (as in this example and below) In the third instance, the command can be addressed to any logical address; as understood from the device side, the two implementations are largely the same. Once the signature is found and the inline command is extracted, the hidden partition (in this example) is made available to the host application 1053 via the corresponding device application 1〇23 located on the card 101. The host and device application will communicate using a protocol that will override the read and write between the host side and the card side and report the split status. In this illustrative embodiment, the device controls permissions to the application. The device grants such access (read, write) when the device confirms the credentials of the host application (read, write), and upon approval, the device application grants read and write access to the partition via the host/device agreement. Once the host application has been confirmed, it is then assumed that the device is operating in a trusted environment. As mentioned, the first exemplary embodiment will be implemented at the slot level, and the command will be placed in the first data section of the write file. Implementing and; relying on references to any particular logical address, but relying on checking the specific pattern or signature of the first segment. The file in the split is managed by the host, which means that in the hidden split instance, the host application is the owner of the file (distribution). Once the host application obtains the corresponding private type, Permissions, which fully control the content. ~: The problem of the access rights of the nozzle in the operating system (os) is usually not able to capture the FAT of the partition, so the host application 1 〇 5 3 will implement the file system as any access to the hidden partition - only FAT is available after the official line to the application is opened. (The command transmission by the host application/type will be defined and explained below.) The main mechanism program will be located on the non-hidden or public segmentation of the card, as understood by the mass storage device or the removable I-level Qs. . A number of such host applications can be located in this area and the user will know which host application to execute and which host application will be executed on the host side. The host side software layer is described in more detail with reference to FIG. The device driver 1055 has two tasks which act as a bus driver and perform the (1) operation of the standard client application supported by the (intermediate) protocol and the standard system 1〇57. In addition, it also implements applications and devices or specific application agreements. Standard I〇 APIs and implementations are common to all card families (eg, standard SD card operations). An application or a specific device is essentially a specific agreement. Figure 7 shows an example of a hierarchical structure that enables common sharing of code and common portability between different application-specific protocols. In addition to the host application layer i 053 and the file system layer 1〇57, the host structure is now also dedicated to the layer of device applications! kiss. For "standard" device operations (not specifically for specific application operations), layer 1059 is not used and layers 1053, 1057, and 1〇55 will be used to be substantially the same as in the prior art. And the operation. When a specific private quotation is to be used, the device application layer 1〇59 116844.doc -27- 200809593 will be inserted between the file system 1〇57 and the host layer 1053 to Format and embed specific application commands. Device driver 1055 can include interface and pipeline sublayers to provide common functionality and can be used with minimal changes to all specific application protocols. The host application should match the protocol layer for a specific application. The interface sublayer will present a set of standard device functions. For example, these features will include: hardware initialization and configuration; driver startup and shutdown routines; read and write operations; and erase. It will also include functionality for performing the appropriate method and thus initializing the pipeline. When an instruction such as 5 10 of Fig. 5 is transmitted, in some cases, the operating system (OS) may divide it into slices, possibly even inserting slices of other instructions. In such a situation, file system 1057 and device driver 1055 can decompose instruction 510' such that command portion 511 is in any of the cases that are not attached to data portion 513 until attached to all data portions 5 13 with the remaining data portion continuing Transmitted in one or more subsequent transfers. Under these conditions, the subsequent transmission of the remaining data portion will have no signature portion of the segment 5 13& and will appear as a standard command. This segmentation can also occur for data that is transferred from the card to the host during a read operation. The procedure can be simplified in situations where it is known that the 〇8 will not split the instruction or 〇s can be sufficiently controlled so that it can be instructed not to do so. This is first discussed with reference to the flow of Figure 10A and the corresponding state diagram of Figure 12. A more general situation will be discussed later with reference to Figures 1 and B. Moreover, for the sake of simplicity of discussion, the discussion of Figures 1A will generally be based on the situation of only a single application, although there will typically be several different such applications in effect. A more general situation of Figure 10B will make this clearer. 116844.doc -28- 200809593 For the first exemplary embodiment, a simple hidden partitioning agreement is used for illustration. The memory 1〇11 is divided into two segments. The first division is the product standard division. The standard host only knows about this split. The second split is a hidden split that can only be accessed via a specific application command. The standard host does not understand this split and there is no way to access the split. The hidden partitioning protocol of this example defines five functions used by the device to communicate with the application: 1. Open hidden segmentation: used to authenticate the user and enable read and write operations. ', 2· Close hidden segmentation: to read and write operations. 3. Obtain the hidden segmentation state: return the data shown in Figure 8. 4. Hidden split read: If the split is on, the self-hidden split is read. If the split is off, an error is returned. 5. Hidden split write: If split is on, write to hidden split. If the split is off, an error is returned. The agreement layer provides the additional ApI needed to implement a security agreement. In the specific instance of hidden partitioning, in addition to reading and writing, the agreement requires three services. · Turn on splitting, turn off splitting, and get split state. These prints are shown below in Tables, which are further discussed in conjunction with Figure 8. The pipeline sublayer is responsible for communication with the card based on the media command delivery principle. As previously described, the primary idea in media command delivery protocols is to embed feature commands (commands that are not part of the standard product specification) into standard entry and write operations. Embedding these commands in standard read and write operations allows them to work with standard hosts and drivers. In the exemplary embodiment, all commands will be initiated by sending a write command 116844.doc -29-200809593 to a certain LB A of the media card. The specific application write command will include multiple section transfers, where the first section holds the arguments of the command and the remaining extents hold the associated material, if any. The read command will be executed in two parts: 1. Initialize the read command by first sending a write command to a selected LBA having the appropriate material describing the nature of the read command. 2. After the write command sets the card application to the correct transfer state, the self-write command sends a read command to the selected LBA to perform the actual data transfer from the card to the host. All commands first send a write command with the extent format shown in Figure 9. When the host application decides to send a write command, the first segment transmitted will have the above format. A data block sent from the host will have the actual data of the card. If the host application decides to initialize the read command, it first sends a write command to the selected LB A (LB A = LB A - XYZ) having the single segment format described above and then sends a read to the same LB A . This is illustrated in the flow charts of Figures 10A and 10B, discussed further below. Several possible implementations are available for media command delivery agreements. An example of this paragraph uses a file system, such as a Windows standard system operation. An example of the next segment communicates directly with the device at the device driver level and does not have additional overhead for the file system. Another implementation can be used for a pocket PC (PPC). In this last condition, the read and write operations can directly access the PPC storage driver. Since there is no standard storage device driver for a pocket PC device, there is no guarantee that this method will be applicable to all PPC devices. Client Application Factory 116844.doc -30- 200809593 The vendor should test this method using the PPC device group that it intends to work with. Returning to the file system implementation of this example, the pipeline sublayer reads and writes from the same file location (as indicated by LBA_XYZ in Figure 10A) for the condition in which the OS will transmit the complete instruction in a single transfer. The reading and writing operations of the command LB A are initialized to the same file location. This does not require a predetermined address in the example of the following paragraph, but can be any logical block address. For this example, the standard file systems API-CreateFile, ReadFile, WriteFile, and SetFilePointer using Windows are implemented. The implementation set can be divided into four or five parts: pre-requirements; communication pipeline establishment; file length verification; application write command; and read if data is read or sent back to the host Take the command. In file level implementations, the file system is used to unknowingly transfer embedded application-specific commands. Since the actual embedded command can be different from the nature of the command in the intermediate agreement that the file system believes it is being sent, a conflict can occur if no appropriate steps are taken. For example, if an error occurs, the file system will treat this as an error in the carriage command (write command) in the intermediate agreement when the actual error can be with the embedded command (for example, a read command). Therefore, error recovery can be complicated. Similarly, if the file system uses a cache, it can lead to inconsistencies. Another problem can arise from file segmentation: since the exemplary implementation relies on reading and writing to the same file location from the same file location (LBA_XYZ of Figure 10A), the entire file should be stored in memory. 116844.doc -31- 200809593 Section of the renewed group. If the data to be stored at the LBA χ ζ is larger than the available segment, the file system will separate it. Therefore, the maximum data length for a particular application command should be no larger than the minimum 档案8 file configuration 丛 (cluster) so that the logical address used (LBA_χγζ) is associated with a logical block address with sufficient space. In the Windows instance, the pre-required implementation of the file system requires a standard file containing at least 128 consecutive segments. To ensure the existence of this file, create it on a formatted drive. Therefore, if the host application vendor chooses this method, it should deploy the communication file with the application. In this example, the design assumes that the file named "FilePipe" (with some of the genities specified below) exists in the device user area. If the file does not exist, the driver will attempt to create the file. If it fails, the application can ask the user to format the drive and reinstall the application on the format drive. To build the communication pipeline, the device driver 1055 preferably opens the communication file with the following attributes: The shared unbuffered, hidden, unshared state ensures that only the host application can access the file to prevent other applications from accessing the command to pass LB A. The unbuffered status indicates that the system has no intermediate buffer or cached file. / Any write or read from this file results in a read/write command to/from the card that is different from the cached version. (In some cases, to ensure that the file will be flushed to the card, it may be 116844. Doc -32- 200809593 procedure βΓ "flag and "write delivery"flag.) Because the actual application = or a specific media command is lost in another agreement, So when there is a write error, for example, the host interprets this as an error with the write::! in the middle, not the error associated with the embedded command. Unbuffered state...Beibu delivery and expected inline Command related. The hidden state implies that the end user views this as a system file. The next implementation step is to verify that the file contains at least 128 consecutive segments.

For application write commands (hidden writes in hidden split instances) = say, write write buffers along the lines described above. The file is then privately sighed to ensure that the read and write operations are the same. The buffer is then sent to the device by calling the FilePipe"name's "WriteFUe," command. For the application's read command (hidden read in the split instance), the file metric is reset first. Then execute the "WriteFile" command to send the command buffer. Then reset the file metrics again to ensure that the same Lb a is written and read. Then execute "ReadFile" to get the security data from the device. Returning to the card side, the device application 1023 will manage the hidden partitioning (in this example), allowing for reading and writing to be placed upon confirmation by the host application. For the hidden segmentation phase, resource and memory accesses are made via media layer 1025. Media layer 1 〇 25 directs all device application data transfers to the hidden partition on memory 1011. As described above, the device application 1023 receives its specific command from the host application 1053 via the rules card agreement read command/write command. For example, in the case where the SD card protocol is regarded as an exemplary embodiment, each command index and arguments are passed in the command section via the SD write command. When a read command from the device application is pending, the host application will first send a write command (via the SD write command) followed by the actual read command (SD read command). During the write command to pass the command segment, the contents of the read command are stored, for example, in the RAM space dedicated to the device application. When the command is subsequently read, the device application will then load the stored read content and transfer the requested data. The stored read content will remain as it is until it is replaced by another read. This will enable the host to perform a read retry without sending another write command + command block. Because most protocol commands act as read commands/write commands, new commands can be transmitted as specific application commands by reading and writing to certain LB As. In the exemplary embodiment, all commands are initiated by sending a write command to an LBA of the media card. A particular application write command will include multiple section transfers, where the first section holds the argument's argument and the remaining chunks hold the associated material, if any. As mentioned above, the read command is executed in two parts: 1 - The read command is initiated by first sending a write command to the selected LB A, where the nature of the read command is described in the appropriate data. 2. After the write command sets the card application to the correct transfer state, the read command from the write command to the selected LB A is sent to perform the actual data transfer from the card to the host. Returning to Figure 9, all commands must first send a write command, where Figure 116844.doc -34 - 200809593 9 shows an exemplary format of the argument data section herein. As shown in FIG. 9, bytes 0 through 31 hold the application pass signature (eg, "pass Through Mode Supported"), byte 32 holds the application hill, and byte 33 holds the application of the dead command The program commands the opcode index and the application commands the self-variable data to fill the remaining segments. When the host application 1053 decides to send a write command in this embodiment, the transmitted first segment will have the format of Figure 9. The next data sent from the host 1 〇 51 will have the embedded command actual data for the card. If the host application decides to initialize the read command, it first sends the write command to the selected LB A with the single segment style described above and then sends the read command to the same LBA for reading. The host application 1053 is responsible for initializing the command based on the communication flow seen by the device (as shown in Figure 10A). To do this, the host application controls the target LBa of the card protocol read and write operations, which will carry the embedded commands as described above. Although only a single command at a single LBA is described 'but for multiple LBAs, the process shown in Figure iA (and Figures ha to η., Figure 12, etc.) can occur because these lb a can be relied upon Pass the pattern signature. (This situation is described in more detail below with reference to Figure 10B, where different LBAs are indicated by subscripts, LBAJ. Because the device is capable of continuously processing the evening files', the particular LB A depends only on the state machine of the device (see Figure 12 below) When the write to the selected LBA is received, the process begins at step 1101, where LBA = LBA - XYZ is considered. Then check (1) 〇 3) the signature to see if it passes the signature for the application: If the application does not pass the signature 116844.doc -35- 200809593, then the card performs the standard IG operation (10) 5); if the signature is passed for the program, the CMD delivery mode is entered. Step 11〇9 determines whether the command direction (as seen by the device) is OUT (OUT). If the direction is out (for example, writing to the memory of the device), then the command is executed (11 11). If the right ^ direction is not ', then at 1113, the memory device waits to read the first command (application read request). If the write arrives at '(), it goes to the standard 1〇 operation φ (1123) before returning to the wait state (1113). ☆ If the item fetch command is received, check (1117) the LBA and if it is connected to the LBA 'There is its $Read command and execute ((1) force read; if the LBA does not match, then instead, go to 1123. There is more than one possible implementation and the implementation details change according to the target platform. A common way (The application is based on the Windows NT-based desktop computer and described above on the host side) to use the virtual slot and the standard Windows file system API. Another way is to initialize directly using the Jia...% magic transfer API. Card protocol (eg, sd) read and write operations, as described in the following example. This method is also based on the application

A Windows NT desktop computer, but it requires administrative rights as discussed above with respect to the implementation of the card driver hierarchy. Regarding the command interface between the card firmware and the application firmware, in the first step, the card FW receives a specific application command. After the verification card transfer mode supports the signature, the FE layer 1021 of the card will parse the argument data section along with the write command to the selected LBA of the application 1 and the command OP-Code. The application-specific command interpreter will invoke an application interface routine with metrics pointing to the host data buffer. In the second step I16844.doc -36 - 200809593 when starting a specific continent command phase, the application: FW must set its own complaint machine to process the application command sequence and also set a flag to indicate to the selected LBA. A read command/write command is used for the application FW. Whenever a read command is sent to the card (to the selected lba), the card will first check this flag to distinguish this particular application read command from the rule read command up to this LB A.

An example of a protocol for hiding a split application will now be described. Figures 11A through 11C φ illustrate some of the same processes as those of Figure 1A, but are illustrated in terms of activity on the system busbar between the host and the mounting. Figure UA shows the process of identification and secure segmentation of FAT reads. First, the host sends the username + password to the card for authentication. Once authenticated, the card allows the application to read the FAT from a secure and hidden partition. The split continues until the host terminates the session or the device experiences a power cycle. As long as the split is on, it is allowed to be read and written by the host application to the hidden split. Figure 11B illustrates a host read of a file in a secure partition. As described above, the "specific application read command" appears in two card agreement commands. - specifies the nature of the read command and the write command of the argument; and the subsequent actual read command. Figure 11c illustrates the host write to the hidden partition. In the case of authentication, the host can access the split FAT and now has the right to transfer the new file to the host. The host sends a write command to a secure partition with a write start address and a sector count. Figure 8 shows an embodiment of the device application state mentioned above and an exemplary value of a hidden segmentation example. Because several different splits are allowed, 116844. Doc -37- 200809593 In the example, the byte 1 in the device application split ID is given as "1". The next four bytes give the split size, shown here as the ten megabyte of the segment The value of byte 3. indicates whether the split is currently on and gives the next four bytes to indicate the version of the device application. The byte 10 provides the operational status. The bytes 10 to 5 are padded with zeros. Thus forming a segment. In the variant, the byte 11 can be used to record the number of segments written in the last transaction. Table 1 describes the application private protocol command sent to the device application of the hidden segmentation instance. An example. The CMD index is placed in the byte 33 of the command section, and the command self-variables are placed from the byte 34 and placed in the specified order written in the table. CMD Main CMD Name The number of CMD independent variable bytes 1.  OPEN-PARTITION User name length in bytes 1 User name Specified in the first argument. User password length in bytes 1 - User password Described in the third argument.  CLOSE PARTITION User name length in bytes 1 ____ User name Specify in the first argument _ User password length in bytes 1 ___ User password is specified in the third argument _ 3.  READ-PARTITION Number of LBAs 4 Read sector count 4 4.  WRITE—PARTITION Number of LBAs 4 Write Segment Count 4 5.  READ_PARTITION_STATUS Split ID 1 Table 1 When the embedded hidden split command is transmitted by the device's write protocol (such as the SD protocol), the device application actually used for partitioning is not built. Doc -38 - 200809593 For SD rule operations "After writing or reading a command, the split command interpreter will be called by, for example, the sd command interpreter. After parsing the command section, the command interpreter will call the appropriate routine. In a particular embodiment, the application command may have a parameter as a first argument indicating whether the MD command is a read command or a write command. The second parameter passes the indicator to the location of the command segment in the configured RAM. Since the information about the split device application begins at that point in the segment, the indicator will point to byte 33 (command opcode index). The buffer size pointed to by this second parameter can be specified in the third parameter. As already mentioned, since the write command of the device application is executed in the same sequence as the sequence of the card agreement immediately after parsing the command section, the write commands are simple. For example, under SD conditions: 1. Receive SD write command (1 or more segments): In the exemplary embodiment, the first segment is always a command segment. 2. The card layer parses the first 32 bytes of the first segment and identifies the signature of the command segment. The device application command parser (interpreter) is invoked with an indicator pointing to the command section. 3. After executing the command interpreter to identify the embedded application command, the command interpreter invokes the appropriate routine that will execute the embedded command and begin the application's command process. 4. Execute the command procedure for the hidden split application and pass the status back to the card layer, where the sequence will go to the end where the SD write command process will terminate. The SD card goes to the idle (IDLE) state. As already mentioned, the read command in the hidden split application protocol is 116844. Doc -39- 200809593 is a two-step process that includes (again in the SD embodiment) an SD write command followed by an SD read command. The first step is an SD write command. 1. A § 〇 write command with a data block (512 bytes) sent by the host. In the exemplary embodiment, the first segment is always a command segment. . 2. The card layer parses the first 32 bytes of the first segment and identifies the signature of the command segment. The command parser (interpreter) of the device application is invoked with a pointer to the command section. 3. After executing the command interpreter to identify the embedded application command, the command solution # identifies the internal read command that will be executed (in the next SD read command) and stores the command identifier. The command interpreter then sets the card layer to read the command flag. 4. Execute the application's command procedure and pass the status back to the card layer, where the sequence will go to the end where the SD write command process will terminate. The sd card can be turned to idle. The first step is to read the command for S D: 1 · S D read command. 2. The SD card layer checks the application card layer to read the command flag and finds that it is set: it invokes the device application command interpretation with the read command indication instead of calling the rule SD read command. 3. The device application command interpreter recognizes the split read command flag and re-invokes the split read command identifier stored in the previous write command. This identifier points to the corresponding split read routine and initializes the split read sequence. 4. Perform a split read sequence and pass the return status to the card layer. 116844. Doc 200809593 5· The card layer terminates the SD reading process and the card enters the interlaced state. The reading and writing process is illustrated by a command state machine of the card side application shown in Fig. 12 of the SD embodiment. Since these embedded commands are passed by the SD write command, and the host cannot transmit the command section on the SD read command when the hidden split read command needs to be executed, the command solution of the device application (1023) The translator needs to maintain a state machine that will manage and understand which read commands are being executed by host application 1〇53. In this figure, a circle refers to a device-specific application command executed at the device application layer (Fig. 6, 1〇23), and an additional comment means that? The command in the middle (here, SD) agreement seen at the £ layer (Fig. 6, ι〇2ι). The right side of Figure 12 is the process of writing, where any process that transfers data to the device or no data is transmitted will follow a similar process. The left side of Figure 12 is a read or other process that transfers data from the device to the host. The read flow consists of reading the B path of the first command of the pair and the c path of the second command of the pair. The write process begins with the read process in the same manner, and receives a write command 'discussing the embedded command from the write command after the signature is detected. For the writer process, the 'writer' flag remains open (. The write process is performed. However, for the first stage of the read process, the read flag will be set. The illusion is read from the host. Overfeed (10) 3) (4) This cut (SD) reads the target. Material target: The read command from the host (on the SD bus) is not a regular card read = and should be directed to the device application (10) 3) for the second phase of the process of sending the item I Wherein in response to the second command of the pair, the device is 116844. Doc -41 - 200809593 Transfer information. The flag is reset when the card layer is initialized. Referring to the commands listed in Table 1, the 〇PEN_PARTm〇N command (OP-Code 0x01) receives the username and password and verifies them. If it matches the stored name and password of the device application, the split is turned on for host access (read, write). At this time, there is an authentication phrase that is to be transmitted and verified against the phrase in the code of the device application. This process is illustrated in Figure 13A. The split will remain on until CLOSE ^PARTITION turns it off or until the next power cycle. The use of the CLOSE-PARTITION command (OP-Code 0x02) is used to close the application working session and prevent splitting from being turned on. An embodiment is shown in Figure 13B. The use of the READ-PARTITION command (OP-Code 〇χ〇3) is shown in Figure 13C. If splitting is enabled (Yes path from 1633 to 1635), this command will enable the host application to read the data stored in the split (1639, 1641). In an exemplary embodiment, the routine will invoke the "FlashRead" API routine, which directs the data transfer to the hidden partition. The WRITE-PARTITION command (OP-Code 0x04) directs the data from the host to the host. The hidden partition on the card. As shown in Figure 13D, this command is executed by the device application only when the (SET) split flag (1653) is set. This routine will call "FlashWrite" (1659, 1661) An API routine that directs data transfer to a hidden partition. The READ-PARTITION-STATUS command (OP-Code 0x05) supplies the information shown in Figure 8. This is an application having the structure described above with reference to Figure 8 116844. Doc -42- 200809593 Read command. When the command comes in, the routine will gather all the information and place it in the above structure and send it to the host. As mentioned above, some operating systems will divide the instructions from time to time so that not all of the data portions will be attached to their respective command portions. Under this circumstance, the written instruction of the oblique 邱 八 八 — pl pl 贝 贝 贝 贝 贝 贝 贝 贝 贝 贝 贝 贝 贝 贝 贝 贝 贝 pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl pl The command to attach a standard command in the signed transport agreement may actually be the remaining specific application command. As a specific example, considering the condition of the instruction 51 of Fig. 5, the instruction 51 has (10), for example, the data portion 513 of ten blocks. When this command is transmitted to the card, the host's operating system can only transmit the remaining five blocks later in the preferred five blocks attached to the (4) portion of the command. When the last block of data blocks is sent, it will lack the initial data block 5Ua containing the signature of the application agreement and the actual command, and will appear as part of the standard command from the transport protocol. This segmentation can also occur when the internal application command is a read command, causing the data to be sent from the card to the host in a partial manner. Figure 10B illustrates the flow of Figure i〇a by replacing the single-logic block address lba=lba_xyz with the logical address lbAr for the read and write process and LBAWi to illustrate the read and write in a particular application. This segment in the command. By defining the LBA-fetch and write LBAwi, the device can handle interrupts for application data transfers in either direction. Subscripts are used to take into account the simultaneous implementation of multiple application-specific commands from multiple applications and multi-user host devices. The process of Figure 10B is again based on an instance of the sd card that uses the SD protocol as a transport protocol and is opened by means of the SD idle state and receiving commands at 12〇116. Doc -43 - 200809593 Start. It then determines if the received command is an SD write (1203), and if it is not an SD write, determines if it is an SD read (1205). If it is neither SD nor SD read, the SD command (1207) is executed and the device returns to the idle state (1209). If the instruction received at step 1203 is an SD write, then the transfer signature is checked (1214). If a signature is found at 1214, this indicates the beginning of a new embedded command, which can then be extracted. At 1231, for all read and write logical block addresses LB ARi;wi-, if the logical block address LBACMD of the incoming command is the same as the logical block address assigned to the current write process (LBAcmd=LBAwi ) 'Clear the corresponding LBA^j; wi. Typically, the assigned LBACMD should not be used, but if it has been assigned to another process, it will abort and clear the address. Then determine the data direction of the specific application command (1233). If no data transfer is involved, then the specific application command (1245) is executed and the device returns to the idle state (1249). If the application command is a write, the corresponding logical address is set to LBAWi=LBACMD + data blockeoimt (1251) and the application data (1253) is written. As discussed above, the host's OS can separate the instructions so that the command does not ship with all the corresponding data. When extracting and parsing embedded commands, the card knows how many data blocks should be included. At 1255, a check is made to see if all data is included and written. If so, LBAWi (1257) can be cleared; otherwise, it is not cleared because the remaining data will (unless interrupted by an error or shutdown) eventually follow and will appear to be the address calculated above. The serial SD of the continuous (relative to this command) card address is written to 116844. Doc -44- 200809593 Command. The device will then return to the idle state (1259) to wait for another life 0 to return to 1231. If the application command is read, the device sets LBALi = LBACMD and sets datatypeRi = datatypeCMD (1235) to be the second read at 1263. Subsequent data transfer in the phase is prepared. The device then goes to the SD idle mode to wait for the second phase of the read process. Different changes to this solution will not use LBACMD but instead use the different address LB Aread explicitly defined in the parameters of the write command. This method will work around the OS's caching mechanism. In several systems, the host OS will not attempt to read back the card address that was just written. Instead, it will return the data buffer to the host application's host cache buffer, assuming that the data is the data the card has, since it has just been written to it. In this case, the data buffer will include specific application commands instead of card responses. Returning to 1214, if the command (in the transport protocol) is a write (from 1203 to the yes path), but lacks a signature (from 1214 to the no (no) path), the command can actually be a transfer (this The write command in the SD) agreement, or may be additional material for writing in an application contract. This is determined at 1215: if for any of the LBAwis, LBACMD#LBAwi, then it is the standard SD write that is then performed at 1217, after which the card transitions to the SD idle state (1219). If LBACMD matches one of the LBAwis, the command is actually the more data portion of the corresponding application command and the flow goes to 125 1 to write the additional application data. Returning to step 1205, if the command is an SD read, it is determined to be actually I16844. Doc -45- 200809593 SD reads or reads the second stage of the application. This is determined at 1226 by comparing LB ACMd with LB ARi: if for any of LB ARi, LBACMD#LBARi, then it is a standard 80 read that is then performed at 1227, followed by a card Go to the SD idle state (1229). Alternatively, for any of LBARI, LBACMD matches one of LBARI, which is the second stage of application reading. When LBAcMD = LBARR, the corresponding logical address is set to LBARi = LBACMD + data blockcoimt (1261) and the application data (1263) is read. The device then transitions to the SD idle state (1269). For the application read process, the exemplary process lacks the equal steps of steps 1255 and 1257 on the application write side. Continue to set the corresponding read flag even if all the corresponding data has been accessed. By keeping the LB ARi turned on, the data can be re-read under error conditions. Under this configuration, for an instance, such as in step 123 1 , if the address is reassigned for another purpose, only LB ARi is cleared. Such additions relative to Figure 10A of Figure 10B allow for an interruption in the transfer of application data. It also eliminates the need to read and write to the same logical address. Such permissive techniques are used in situations where there may be insufficient control of the operating system, as the type of control required by the embodiment of Figure 10A may require a known controllable platform. Again, it should be noted again that Figure 10B more specifically incorporates the existence of multiple host applications, each of which is in independent communication with the card, and that the interruption of data transfer can be inserted between the portions from an agreed instruction from another agreement. Part of the instruction. In addition, the independent LB A of the read process and the write process allows any read or write cache in the device driver layer to be bypassed. I16844. Doc -46- 200809593 The second exemplary embodiment - the example is implemented at the file level. Various aspects of the present invention can also be implemented at the device driver level to initiate read and write operations by sending a request to the device driver, such as when the host uses the wind system, and the device is driven first. The program can store drivers for the WindGws standard. This implementation of the life delivery method communicates directly with the device and does not have the cost of the broadcast system. However, this method may require administrative privileges. The host application can try this method and use this method as the first choice and if it fails, it will be transferred to the file system operation. The interface function can be used to select between these methods and initialize the communication pipeline accordingly. The user will use this command with the application before any other operations. If the application lacks proper administrator rights, working in this way will result in an exception, which can be handled based on the exception handling code. The case is based on the discussion of the problem in the [Prior Art] section above. Although [the discussion of the first technique raises the problem in the case where the memory card is connected to the pc via the hardware card reader, it will be seen below (as in the other examples given here)] For the general. The memory device may have this protocol translated 'or more precisely' even when it is directly connected to the second host, there is no translation problem. This can be the case when the memory device is connected to a host with an incomplete agreement (as seen from the memory device). - The situation in which this can occur is where the card has two sets of contacts' - the set is used by the USB port and is used by the card contacts of the " (U.S. Patent Application Serial No. 29/2,3,693, filed on Apr. 16, 2004, US Serial No. 26,8,1, and still No. 0/826,796, the example of such a two-contact card.) As for the third group 116844. Doc-47-200809593 As discussed in the embodiments, the protocol translation can be completely contained within the memory device itself, not known to the host. Further, in the following, although the embodiment is described with respect to the detachable memory card, the discussion is also applicable to the embedded memory device. In a first set of embodiments of the second exemplary embodiment, the present invention uses a particular logic block to allow media card specific commands to be passed from the host to the card without changing the firmware of the adapter or reader that controls the media card. A Address (LBA) (Card Transfer Mode LBA) that has a specific signature in the data section to notify the card specific command to be embedded in the section. This can be implemented by firmware changes to support command delivery (CPT) mode. Since this does not require firmware changes to the adapter, the card can be executed at any USB reader or adapter. As discussed in the [Prior Art] section, various compact flash memory cards (compact flash cards, secure digital (SD) cards, multimedia cards (MMC), xD, and Sony memory sticks/high-speed memory sticks) have Different electrical interfaces and specific media commands typically used by the host (digital camera, flash memory music player), such commands are not used between the PC and the hardware adapter that allows the pc to read the card. Focus on discovery. In the main sadness, the present invention uses a card firmware change to perform a normal item fetch command/write command. However, when a read command/write command offset to a particular LBA is made, the signature is checked to determine if the data portion of the command contains an embedded media card specific command. The agreement can be implemented in the firmware of any media card. Therefore, there is no need for adapters, USB readers, or any variants of other readers used by pcs (or other hosts that are inaccessible, specific media command sets). In fact, for the card manufacturer, this is simpler than implementing a read jamming change for all card commands in all readers. 116844. Doc •48- 200809593 although various aspects of the invention will generally be described in terms of a particular card (such as Secure Digital (SD) or Compact Flash (CF)) and a specific agreement (such as scsi or ΑΤΑ), but when discussing examples, It will be appreciated that the various aspects are applicable to a variety of other 5 recalls and systems. Various details regarding the structure and operation of the card are further described in the following patents and applications incorporated by reference herein in its entirety. Figure 14 shows the process used by a card to communicate with a personal computer (or more generally, any host that requires a hardware adapter to take a "black card") using a reader. Figure 14 is omitted except under certain conditions. In addition to the explicit description of the USB package or similar structure, which will also be limited in the following discussion, it is similar to Figure 4. As mentioned in [Prior Art], the card and reader use the card protocol. The V々 is communicated with instructions (such as indicated at 201.) The host and the reader typically use an instruction from another command set (such as indicated at 2〇3). The reader uses its firmware. Translating between two command sets. (Although the firmware is mentioned here and below, in general this can be implemented in hardware, software or some combination of hardware and software.) The difficulty lies in Command 201 is a command from a command set of cards that do not have an equal command in the protocol used by the PC to communicate with the reader. In this case, since there is no such equal instruction 203, the reader cannot 201 is translated into the corresponding command 203, and for the phase The direction is also similar. Therefore, if the host wants to use the specific media command of the card, there is no way in the prior art in the case of the set of the hardware adapter agreement. This instruction is passed via the reader. This particular instance will use the SCSI protocol from the host to the reader, the SD protocol from the reader to the card, and will not exist as an embedded command in the SCSI protocol 116844. An example of an SD command (for example, secure write) of doc -49· 200809593. So although this command can be transmitted directly to the SD card, it requires the use of the present invention on the host side of the application to be able to transfer instructions in the intermediate SCSI protocol that carries commands between the host and the reader. At the reader, the dummy commands have a version in each contract and can be translated between the agreements, with the actual embedded commands being treated as data. For example, a dummy command is again considered a write. Therefore, between the host and the adapter, it will behave as a SCSI write command and between the adapter and the card it will behave as an SD command, while in both cases the actual command is embedded in the data portion. in. So although the embedded command now exists in the second protocol in this example, it is still inline because at some point along the path it passes a protocol lacking this particular application command. Thus, this results in the order of the first agreement being followed by an order of the same agreement, thereby allowing translation between it and another second agreement lacking an equal order of the embedded command. This is shown in Figure 15. Although this discussion is primarily based on SC SI and SD embodiments, it will be appreciated that in general it applies to other agreements. Figure 15 is a schematic diagram of the present invention when a command from a card command set that does not have an equal command in the PC reader command set is embedded in an instruction 203 of a PC reader protocol having representations in two command sets. A schematic representation. In an exemplary embodiment, the particular media command is again embedded in the data portion of the PC reader protocol. The PC and reader can then exchange command 203, which can translate the command 203 into a corresponding command 201. However, another specific media command 6 is embedded within the command (Π. The reader then passes the command and translates the command in a manner that is transparent to its operation. The machine of the illustrative embodiment 116844. Doc -50- 200809593 is a predetermined logical address in the memory of the instruction 201/203 accessible card with the representation in the two command sets. When, for example, the card receives a read command to a particular logical address, the card is warned that the read command can be a particular media command 601. (As described below, the embodiments below are not dependent on this particular logical address, and more generally, not only can a write command be used but any command with a data portion can be used.) The card then checks the signature of the command to Validating this and then extracting the command 60. In the exemplary embodiment, since there is usually no convenient space for embedding a particular media command in the command portion of the command in SCSI and other protocols, the command 601 is placed in In the information section of the Directive. For example, if the PC wishes to write to the secure area of the SD card, it will form an instruction 203 consisting of a write command to a specific logical block address (LBA) containing a command pass (CPT) signature. It also contains the actual secure write command 601 embedded in the data section. The PC then sends this instruction 203 to the reader, which interprets it as a standard write command in the SCSI protocol. This is then translated by the reader into a standard write instruction 201 in the SD protocol. The reader happens to pass the secure write command 601, assuming it is part of the data attached to the write command. When the instruction 201 arrives at the card, the firmware allows the card decision instruction to be a specific media command based on the LB A specified for writing. The controller then extracts the command 601 (identifying it as a secure write) and continues to execute the life map 16 by performing a secure write of the actual data portion of the instruction. The N data sectors executed to the SD card are described in more detail. A specific embodiment of one of the examples of security data writing. The top column display is formed by the host 116844. Doc -51- 200809593 Directive. Because the security material is written to an SCSI protocol that does not have an instance, the command portion consists of the command CMD in the SCSI protocol, cMD, here written, which exists in both command sets. Write to the specific command pass logic block address CPTLBA. (The other details of the command are not shown to simplify the narrative.) The poor portion (to the right of the dashed line) consists of the initial segment, which contains a specific media command followed by N actual data segments. The initial data section will include the command delivery signature, the actual specific media command, and the actual address where the following data will be written. The logical block address CPTLB A corresponds to the logical block address LBA-XYZ used in the discussion of the example embodiment discussed above (see, for example, FIG. 1A.) Different tags are used to indicate implementation on the host. In this example of the side device driver hierarchy, the logical block address being used is a specially designated logical block address, and in the previous instance implemented in the file hierarchy, it can be treated as any address. Figure 16 is similar to Figure 5 previously discussed, but with instructions 510 repeated for each of the transport protocols (host to reader, reader to device) explicitly shown in this example. The instruction 510 of FIG. 5 embeds the command CMD inline for somewhere along the transmission path between the host side and the device side of the application, while the instruction 530 presents the extracted form as the application to be used by the application. Used on the side of the device. Figure 16 illustrates that there may be several intermediate agreements and that the actual command (CMD) will remain embedded in a number of such intermediate agreements, even in situations where the embedded commands have analogs in a particular intermediate agreement. As seen by the reader, the first data segment happens to be the first of the N+i segments of the data to be written to the special logical block address. Again, this delivery has not changed. The command part of the instruction is taken by the reader from pC/ 116844. Doc -52- 200809593 The representation in the reader protocol (CMDf) is translated into its representation (CMD) in the card agreement. At this point, the instruction can be passed to the card and the instruction still has (for example) writes to CPTLAB. The command is then in the form of N+1 data sections. Once in the card, the firmware can unlock the actual command. When it decides that the command uses a particular address, it then goes to the first data section, checks the CPT signature and extracts the actual specific media command. This then forms the actual command of the command, which will be followed by N actual data segments. Thus, as described with reference to Figure 16, the particular media write command with N data sectors becomes embedded as N+1 data segments in the transport protocol used between the PC and the reader. In order to read N data sections, a particular media read command is embedded as one of the data sections in the transport protocol used to read (or receive other data) or between the PC and the reader. Thus, a particular media read command can be implemented as a write command with a particular media read command embedded in only the data section. Again based on the specific logical address (CPTLBA) and signature, the card will extract the specific media command and respond with data from the requested logical block address specified in the particular media read. The method of reading the details of the implementation and handling complex problems such as write or read failures is further developed with reference to the first exemplary embodiment. A particular logical address (CPTLBA) is preferably a segment that is not commonly used in a file system because it avoids conflicts with standard read commands or write commands that can be sent to this segment. For example, in DOS, after the master initiates a record, there are typically some hidden sections that are not normally accessed. (In some operating systems, access to this area may require administrator privileges, which is a potentially complex issue that can be bypassed in the next file-based implementation.) By 116844. Doc -53- 200809593 Treat this logical address as a specific logical address. If it is not for the purpose of checking the actual command to embed a specific media command, access to this address will not actually be read or written here. Enter the information. The reader will only pass this command as normal data access and the card will sort everything. Figures 17A through 17L show an embodiment of how various examples of commands can be embedded in a data section. As described above, when performing a write to a media card, the first section of the data portion contains a CPT (Card Transfer) command. It indicates the CPT function to be executed. Therefore, in order to write 10 sectors, 11 segments are actually written because the first sector is a CPT header. To read 10 segments, the user needs to send one of the CPT commands to write and then read 10 segments. The actual application is a specific command that cannot be reached by a normal read command or a write command. For example, the CPT mode can be used for specific media commands, such as AKE (Authenticated Key Exchange) or SD card application commands. Figure 17A shows an embodiment of an embedded command format. The CPT signature in bytes 0 through 31 is a string depending on the command used to check that the signature matches the command. The commands in the byte 32 may include: 0 - CPT mode check: CPT mode support signature for checking the media card "card transfer mode check" '1 - data output: data will be written to the media card signature" card delivery output command 2 - Data input: The data will be read from the media card. The card is passed to the input command '' 3 - Command signature without data transmission. The card passes no I/O command" 116844. Doc -54- 200809593 4 · CPT command aborted signature "card delivery abort command, 5 - CPT mode reset signature ''card pass reset command'' 6 - CPT state capture * signature " card delivery status read Take - Data Transfer Length (bytes 33 to 35) specifies φ the amount of data to be transferred (such as the number of bytes); since the data is transmitted in segments, the incomplete section Filled by 〇. Data (byte 36, bit 1) is the flag of the data transfer and if there is no data transfer on the next command, it is "i" if there is data transfer on the next command. Similarly, Dir (byte 36, bit 0) is the flag of the direction of data transfer and if the data transfer is for the input on the next command, it is, 〇", if the data is transmitted For the output on the next command, it is "Γ,. The media card specific command area (bytes 48_511) is the actual command that the media card will execute when it is extracted. The media card specific flag area (bytes 36, bit 〇) is used for media related flags. If the media card support card passes the command agreement before the actual command is sent, • the media card must be checked. As described above, LBA (cpTLBA_Card Pass LBA) is specified for this protocol. The LBA can be any number from the low to the last segment of the card. In the example, this would be LB A 2, which is the second hidden segment after the master boot record in the FAT file system and is typically not used to hold the bedding. Note that this agreement will retain its value even if the LB A contains valid data. There are two options for checking mode support. I16844. Doc •55- 200809593 The first choice for query protocol support is when the media card places the CPT mode support signature in the CPTLBA section. However, this is not preferable if CPTLBA is a section with valid information; for example, a section in the FAT/directory or user profile area. If the CPT mode is supported, the card may return to the CPTLBA section having the signature as shown in FIG. 17B, where the byte 0-31 is ''support card delivery mode (filled with blanks)" and the byte 32-5 11 is 0. If the CPTLB A section does not contain a signature that supports the CPT mode, then the second option supported by the query protocol can be used. In this case, the following agreement is used to check mode support: a) Read the CPTLBA section and store it in the host memory area. (Signature not supported) b) Write to CPTLAB with a section containing the signature used to query CPT mode support. c) Read the CPTLBA section to check the response of the CPT mode support. d) Write a CPTLAB with an original segment from the stored memory region. When the host reads the CPTLBA segment and stores it in memory, step a) allows a specific logical address (CPTLBA) to be checked for support while still retaining any data that can be contained therein. This is used to restore a zone when the media card does not support card transfer mode. This write does not use the CPT mode command. Figure 17C shows step b) with a CPTLBA write containing a section for the signature of the query. The host writes the byte 0-31 of the CPTLBA section as "card transfer mode check π (filled with blanks), and then writes 116844 in bytes 32-47. Doc -56- 200809593 Order and flag. Bits 48-511 are zero. In step c), the host reads the CPTLBA section to respond. If the response has a bit 〇_31 for the "support card transfer mode" (filled with blanks) and a byte 32_511 for the 如图 as shown in Fig. 17D, the card transfer mode is supported; otherwise, the card is not Support for the CPT Agreement. Note that this agreement is different from the first option used to query the agreement support. The signature is responded when a CPT mode check command is issued. In step d), the host writes the original data in the cpTLBA section from the stored memory area. Note that even if the card supports the card delivery mode, this write will not be interpreted as a specific cpT command because there is no proper signature. The input/output protocol is described with reference to FIGS. 17E to 17G. To output the data to the media card, the CpTLBA is first written with the signature for output, and then the data is written based on the length of the data transfer. In order to write to the CPTLBA' host with a signature for output, a write command is sent to the media card, where the material has a CPT command format with embedded media card specific commands. The length is a section of "data transfer length" plus the CPT command format. This is shown in Figure 17E, where 1 of the bytes 32 corresponds to "data to be written to the media card," Figure 17F The actual write based on the length of the data transfer is shown, wherein how the media card processes the data depends on the media card specific command. As mentioned in Figure 17a, the "data transfer length" in this example is based on the byte. It is represented in bytes 33-35 (MSB, LMSB, LSB). However, since the read/write data is transferred in sections between the card and the picker, the incomplete section can be filled with 0 as needed. For example, in an SD card, the authentication key exchange (AKE) process uses 8 bytes for inquiry and response. Therefore, the host 116844. Doc -57- 200809593 Fill the data section with 0 04 bytes of 0 to query 1 and respond to 2 data, where the card similarly fills the query 2 and response 1 data. In order to input data from the media card, the host writes the CPTLBA with the signature for the input and then reads the data based on the length of the data transfer. Figure 17G shows a CPT command to be sent to indicate that the material will be read, where 2 of the bytes 32 correspond to "data to be read from the media card". In order to read data based on the length of the data transfer, after the host sends a read command to the media card, the number of extents to be read is [(data transfer length) / 512]. (This assumes 5 12 bytes per segment; more generally, if it is a different segment, the actual segment length will replace 512.) The starting segment is CPTLBA. Since the previous command entered a command for the CPT, the card will send the data to the host based on the media card specific command. Examples of commands that do not have input or output include "commands without data transfer,"CPT command aborts, and "CPT mode reset". Figure 17H shows "Command without data transfer" as indicated by 3 at byte 32. Figure 171 shows the "Status Read' command (indicated by 6 at byte 32), which Allows the host to read the CPT status. For example, in an SD card, the status can be implemented as a response data. This status will be the first few bytes of the read back data. Although the SD card is referenced when a specific instance is needed, 17A-171 are not limited to any particular media protocol and are not limited to a particular media command. To give an example of a particular media command, Figure 17J shows an inline command dedicated to an SD or MMC card and Figure 17L shows a dedicated fast Flash card embedded command. In Figure 17J, the command format of the SD/MMC instance is shown. Bits 0-35 116844. Doc -58- 200809593 is as described above. The SD/MMC command populates the media card specific command field. Bytes 48-53 are SD commands, such as for secure reading. Certain flags are required and defined in the media card specific flag block. BLKH indicates whether the command is for a single zone or for multiple zones: 使用 if a single zone command is used, and 丨 if multiple zone commands are used. For application commands, APPM. The response type is §1> response type depending on the command index. Each of the bytes 48_52 is the actual element of the SD command, wherein the CRC7 of the byte illusion can be set to 〇 〇 In order to obtain the response data of the SD command, the user can send a status _ to obtain a response. This is shown in Figure 17K. # The response data will be returned when the most (four) bytes of the segment are read. Figure 17L shows the Compact Flash (CF) command format for embedded commands. In this case, the commands are in bytes 48-54 and provide the elements needed to contain the CF commands. In Figure 17L, the media card specific flag (bit 2 to byte 37 of the bitstream) is reserved for additional commands specific to the various card formats. Third Exemplary Embodiment The third exemplary embodiment is implemented at a file level, as in the first exemplary embodiment: The discussion here will focus more on the details placed in the host side file. Since device-specific commands are embedded in the audit file, there is no way to compromise specific data such as files in the FAT area. From the point of view of the card, the exemplary embodiment will look similar, with the difference being more about how to load information on the host (4). When it is desired to refer to the (4) program, the third exemplary embodiment will be a secure connection to a secure bus such as the US Provisional Patent Application No. 116844 filed on December 21, 2004. Doc-59-200809593 60/638, 804, which is called illusion, is incorporated herein by reference. In the case of using the file level level of the main 1 and the private, in addition to overcoming the use of the device driver level implementation, there may be a problem of "class permissions", but also overcome the need to send specific commands. The specific needs of a particular hardware. For example, in some cases, there is a need to send a specific designation to access the security card of the SD card in the 'installer 1 driver level', but in In the case of file level implementation, because the Teng Sun & Begong is packaged in the file, it no longer exists.

need. Therefore, as long as it is appropriate to "^ j into and master the file, you can use this implementation to send and receive any command set. The first 刖 & κ & example is the card driver implementation, which operates on the device input / output Hierarchy. The host system or the Pc application and the device or card driver are the operating system and the washing (OS) 4 filing system. The third group of embodiments is the standard implementation, which operates the OS broadcast system. In the example, the host only tells the slot system to write a file to the memory device, and the device specific command is embedded again. More details about writing the file to the flash memory are described in 2005. U.S. Patent Application Serial No. 11/6,249, No. 11/G6G, No. 174, and U.S. Serial No. U.S. Other embodiments may require additional firmware overhead than device level embodiments, but may have several advantages. For example, at the device level, when developing an application, it is necessary to understand some hardware. Using the file system, this becomes hard Irrelevant and independent of many details of the bottom level agreement. As with device level embodiments, the slot level embodiment can be used to send vendor specific commands to individual waste product products, such as at wind〇ws 116844.doc 200809593 98/ME/ The Advanced Logic Program Interface (ASPI) built in 95/DOS and similar examples. In the device level embodiment described above, writes to a specific logical address (CPTLBA) are used. However, in many jobs In the system, some access rights are required to access this logical address. For example, if the user does not have administrator rights, a SCSI command cannot be sent to the vendor's product because the operating system usually allows writing to the file. Thus, the file level embodiment of the present invention prevents permission issues by embedding specific media commands in files, writing files to devices, and unembedding actual commands on the device. Many versions of the Windows operating system In the card level embodiment using the exemplary CPTLBA, the administrator (4) will be required to simultaneously write a file without any such specific access rights. An example; the embodiment embeds a specific media command in the data portion of the instruction. The implementation at the file system level of the operating system can be implemented again by the card card body, and the card body of the card is adapted to comply with Identification protocol. Use the read/write command to any LBA to check the final name to determine if the data contains an embedded media card (4) command. This is different from the device driver in which a specific address is used. In other respects, > As seen from the card, there is a discrepancy between the device driver level dancers, and the file system level instance of the κ% instance and the first segment. The order involves any data transfer, in order to maintain the data associated with the 'order', based on the exemplary embodiment of the implementation of the slot case, the agreement is divided into ''instructions" part (Nongzhong meat% female knives, zhongzhong 肷Specific media commands) In/Out " section. When the Α丰社仏^ receives the agreement command, the initial check is performed during the read or write operation to determine whether the given LBA is the instruction part 116844.doc -61 - 200809593, this only It is necessary to perform a first-data section of an agreement command in which the signature is always embedded in the first data section. From the perspective of the host side programmer, δ, the client application issues a simple file or a logical sector (lba) write operation with a command knife and (perhaps with) a greedy input/output portion. If the order involves reading data or writing data to the media, then Bosch (4) compiles to the entity mapping. The _body will receive the debt test API command part during the self-transmission instruction as a write • or Ί buy. φ In the exemplary implementation, the command portion of the agreement order will contain signatures, query commands, vendor-specific commands, and updatable blocks. The size here will be limited to a multiple of 512 bytes, which is the size of the data block used by the most f. The format of the instruction page in the exemplary embodiment is shown in Fig. 18A, which is very similar to Fig. 17 except that it has additional details. The first 36 bytes are unencrypted, with the remainder being encrypted/decrypted based on the encryption/decryption information stating the existence of the supported encryption algorithm. With respect to the various blocks shown in Figure 18A, the byte is a signature byte used to indicate an LBA that can be a candidate for an API command page. If these two bit groups match, the firmware will check the Αρι signature. In the following example, byte 0 is 19 and the bit group is 乃. The Αρι signature is located in byte 2_34 and is a single string. In the following example, the signature is treated as a "advanced program interface". The bit το group 35 is an encryption/decryption (E/D) message that informs the firmware whether the page and the data page are subsequently encrypted. If it is not encrypted, this block should be set to API-ENCRYPTI(10); otherwise, it should be set to the encrypted name: Enable the firmware to decrypt and encrypt the instruction page or multiple instruction pages starting from byte 36 And a profile page. Byte 36_39 is the firmware operational status block 116844.doc • 62 - 200809593 (Operation Status Field) The block is updated and will be updated based on the success or failure of the operation. If everything is fine, it will be set to API_〇P_SUCCESS; otherwise it will be set to the error value or API-OP-NO-SUCCESS. It is recommended to set the preset value to 〇xFFFFFFFF when issuing a command. After writing, the caller can read the instruction page to verify that the requested operation was successful. The Vendor Identifier field (Bytes 40-43) can be used as a unique vendor identifier. If the firmware also requires a valid vendor ID, this field can be used by the calling environment to identify the firmware itself.

The number of page fields (bytes 44) tells the firmware the total number of pages in the command, where the button is bounded by 5 12 bytes. Similarly, the number of data page fields (bytes 45-46) will be communicated to the firmware by the total number of data entry/output pages attached to the command portion. The data page size does not have to mean that the data in the byte group is in the strongest. In some cases, the padding may have been added to the end of the data byte. For example, the data size of the DESf to be in the byte must be ^ multiple. The S group field (Bytes is (4) (bit core 47, the size of the data in the shelf will inform the mobile number of the number of the bytes in the data page containing the valid data. In the case of reading from the media, this block The bit should be updated by (4) the size of the byte actually processed in the page area. When writing data to the media, this is the length of the byte of the data size. If the data is encrypted, the rider first decrypts the entire data page. The content is then extracted. , : The bit 0 in the tuple 51 is the flag of the data transmission. If the current command data is transmitted, it is set to "〇U, and if it is prepared, it is set as the data transmission. Bits 1 and 2 in byte 51 are the flags of the direction of data transmission

116844.doc -63- 200809593 "〇〇" indicates that the data transfer is for the input of Α ^ λ ^ , and the firmware will process the command in the write time — invalid. Value, indicating data transmission, J will be written to the media will make the data page... Ke Chuan, in the input of the current command and the filial blade will process the command in the write time of the black box that does not exist . The value "10" refers to the data transmission system for the current command is not p v < The reserved value "11 ". Bits, and the bit x 3 to the byte 51 in 51 are media card specific flags and depend on the type of media card. The groups of bits (4) are reserved for future use. Bit.

A media card query command block (bytes 64) will be used to query the status and performance of the media card. Known support includes: support for E/D algorithms that support ι ι 协, and support for support. Media Card Query Command The Return Status Bar (Bytes 65_68) can be used to maintain the rollback value of the Media Card Query command. The media card specific command length (bytes 69 and 7) specifies the total number of command bytes stored in the command block, where the media card will execute the actual command on the media card specific command (bytes 71-5 11 )in. The page attached to the (multiple) instruction page will be any data input/output page. The caller environment and firmware will be encrypted/resolved based on the built-in cryptosystem algorithm. In some cases, there is no need to write a data page to the media, in which case the body must process the command before writing and then only write the command page to the media so that the user can read back the command and see To the state of operation. Figures 18B through 18F show several examples of specific media query commands, such as queries for checking API protocol support for whether the media card supports API protocols before the actual command is sent. A specific procedure will be described with reference to Figs. 18B and 18C. When the file system is used to access the media, an archive with only one instruction 116844.doc -64 - 200809593 is written. The examples of Figures 18B and 18C illustrate how the protocol can be queried via the file system. The calling environment opens a file (eg "myAPi.bin"). In order to query the support of the protocol, the caller can write 512 bytes (shown in Figure i8B) to the file and issue a write file command. After issuing the write file command, the media will take appropriate action during the writing of the file to the media or during the reading of the file. For this example, it is assumed that the media card processes the instruction page before writing. In this case, the following actions will be taken: a) Verify the signature byte b) If it matches, verify the API signature c) If it matches, double check (g〇 thr〇ugh) the specific media flag (if it exists). d) Check the media card inquiry command request, which is 1 e) When there is no data transmission, the verification data field and direction block are 〇. f) Process the command, update the block and write the file to the media. When the user reads the file (myAPI.file) from the media, the caller needs to check two fields: (1) Operational status: If the command operation is successfully completed, the field will be API-OP-SUCCESS. Update or update with some error value on failure 'and (2) Check the media card query command return status only when the command operation is successfully completed. If the support agreement is updated, the field is updated by 1 or if the agreement is not supported, it is updated with 0. See Figure 18C. If the agreement is not supported, or if the card has been disabled for this agreement, then these two updateable fields will retain their initial presets 〇xFFFFFFFF. A second example of a particular media query command is a query to determine which of the 116844.doc -65-200809593 secret/decryption algorithms are supported, wherein if the API agreement is supported and the API agreement is valid prior to the query, then Check the media card. This will be explained using Figs. 18D and 18E. Similar to the API-supported queries (discussed with reference to Figures 18B and 18C), when a file-type system is used to access media, an archive having only one instruction page content is written. The calling environment will write to a file (eg myAPLbin) to use the same instance as above. The calling environment will be written to a file; for example, myAPI.bin. To query support for this command, the user will include 512 bytes as shown in Figure 18D and issue a write file command. Assuming that the media card processes the instruction page before writing, the action of an exemplary group is as follows: a) verify the signature byte; b) verify the API signature if it matches, c) check the specific media flag if it matches ' (if present); d) Check the media card query command request, which is 2; e) When there is no data transfer, the verification data field and direction field are 0; and f) process the command, update the field and archive Write to the media. When the user reads the file myAPI.bin from the media, the caller will check two fields: (1) firmware operation status: if the command operation is successfully completed, the field will be updated with API-OP-SUCCESS. Or if it fails, Bay 1 is updated with some error value, and (2) The Check Media Card Query command is returned to the state only when the command operation is successfully completed. This block will return a 32-bit integer, which means no encryption/decryption algorithm is supported. Otherwise each bit of each predetermined encryption/decryption algorithm will be set. For example, suppose DES is in bit 1, 3DES is in bit 3 and AES is in bit 32, and the value of ij back should be: 116844.doc -66- 200809593 MSB 10000000 000〇〇〇〇〇〇 〇〇〇〇〇〇〇0〇〇〇1〇1〇Lsb This result is shown in Figure 18E. Note that in the exemplary embodiment, the maximum number of algorithms is 32. Based on the rollback value, the type of supported E/D algorithm can be determined such that the instruction page (starting from byte 36) and the data page can be encrypted by setting the same predetermined algorithm name in byte 35. . Note: A byte should have only one bit set at any given time. If it is set to exceed i bits, it will fail. Another example of a particular media query command is a query that determines if the media card supports the API protocol and, if so, can negotiate the agreement. Similar to the query used to determine which encryption/decryption algorithms are supported, a file will be opened in which the contents of the file will have only one page of instructions. The calling environment will open a file, such as turning on myAPI.bin again. To query the support of this command, the user can include the 512 bytes shown in Figure 18F in a file and issue a write file command. After writing the file, the user can read the block and verify whether the operation is successfully completed by first checking: (1) firmware operation status. · If the command operation is successfully completed, the block will be updated with 0. , or if it fails, it is updated with j, and (2) the media card check will be checked back to the state only if the command operation is successfully completed. If it can be agreed, it will be 〗, or If it fails, it will be 0. Figures 18G and 18H show specific examples of specific media read commands and write commands based on the file system. Before issuing the firmware command to the media card, check the card to see if it supports Αρι Agreement. As previously agreed, if the system of the case is used to access the media, then a content with one or more pages 116844.doc -67 - 200809593 and any associated joint rough beta _ bedding pages will be opened. Archive. Figure 8G shows an example of a specific media write command. More sigma, suppose the caller wants to issue a command (for example, D5 in SD card life) to get the data page and write it to a hidden area. Calling the morning The slot is opened and the user will prepare the profile as shown in Figure! The bits 00-34 are as in Figures 18A-18F, where the bit 7G group 35 of the instruction in this example indicates that no encryption is being used. The byte 36_39 again shows the operational malaria of the firmware, where the italicized words (the italicized font and the oblique body above) refer to the non-blocking firmware updateable, and the manufacturer or media identifier ( This example uses the vendor identifier as "SNDK") in the byte 4〇_43. The inline commander will be dedicated to this media/wei. The byte 44_5〇 indicates the number of command pages (here only The page shown (NIP drink), the number of data pages (also in the example (NDP=1)) and the size of the data specified as the number of bytes (here used as the 512-bit group of the segment ( 〇 816 = 512)). The bytes of the instruction 51-68 provide the previously described instruction information as needed for the particular command. The length of the actual embedded command (in bytes) is indicated by the byte 69_7〇 , in this case, a single bit containing an example of a caseless "D5" instruction indicating a write to a reserved area or a secure area 71. The remaining area (bytes 72_511) configured for the particular media instruction is then padded with zeros to form a π-segment. The (here) 512-bits of the actual command-specific data are used as the next section. In Figure 18G, note that the data field (DATA=1) indicates that the command contains an input and the direction field (Direction=〇〇) tells the body to process the data and write the page to the media. Since the file system will have the data The page is written to the media (such as the 1024 bytes seen by the file 116844.doc • 68 _ 200809593 system, first 5 12 bits for the embedded command), so the firmware will be 0 or FF as needed To populate the data page. The caller can verify that the operation was successful by reading the file from the media card and checking the firmware operation status check. If the operation has been successfully completed, the block will be updated with API-OP-SUCCESS or, if unsuccessful, it will be updated with some error value or API-OP-NO-SUCCESS. Note: Since the direction is 00, the data page should be 〇 or FF. The hypothesis is written in the media card processing instruction page', and the action of the exemplary group is as follows: a) verify the signature byte; b) verify the API signature if the signature matches; c) check the instruction page (from the bit Group 36) is encrypted; d) if encrypted 'recrypts the instruction page (from byte 36) and the data page; e) verifies the vendor ID signature; f) carefully checks the specific media flag if the vendor ID matches ( g) check direction and data block; h) process the actual embedded specific media command; and 1) update the firmware operation status field of the command page, encrypt (if requested) the instruction after byte 36 Page and write it to the media. Since the direction is 〇〇, the data page is written as 〇 or FF as needed. Specific media read commands are implemented in a number of ways, some of which are discussed in more detail in the following paragraphs. Referring to FIG. 18H, an implementation of a specific media master command based on a file system is described, which is similar in structure to the write structure of FIG. 8g. 116844.doc 200809593. When a specific media command is being read from the media, the specific media command is D6 and the direction is 10. In addition, you can flexibly modify the inner valley based on the commands used and the associations you build. For example, the card can be informed to write to the file and the file/, a specific command that is useful to encrypt the content prior to writing. Therefore, the 'written in' can be converted to another form before writing. The same applies to the read operation. Figure 18H shows where the caller wishes to issue a - command (for example, an SD card command)

Concentrated D6) reads a data section from the hidden area and places it under the greedy page. The calling environment will open the file and the user will prepare the data page as shown in Figure 18H, where the vendor identifier will be used again, and the SNDKn 〇 data shed will be *this is the " The update and direction block tells Wei blade that the data is processed during the reading. Another possibility for Bodhidharma is to process commands, update material pages, and write them to the media. Because of A, the firmware will write 1 to 24 bytes to the media. When the mobile reads the file, it will extract this as the heartbeat page' and then it will read the command and update the data block appropriately. Then, by reading the file from the media card (4) to verify whether the operation has been successful, the caller can check the firmware operation status field. If the print 7 successfully completes the operation, the block will be updated with Αρι 〇p-succEss, and if it is not successful, it will be updated with some error values such as some. The number of data reads can also be verified by examining the brain level to see if it has been updated to 512. Various aspects of the invention have been described with reference to the specific embodiments thereof, but it is understood that the invention is in the scope of the appended claims. 116844.doc 200809593 [Simple Description of the Drawings] Figure 1 is a schematic representation 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 in which a card or hardware adapter is used to communicate a card to another host. 4 is a schematic representation of the prior art of transmitting data and commands in the system of FIG. Figure 5 shows how a particular application command can be embedded in accordance with an illustrative embodiment of the present invention. '' Figure 6 is a block diagram showing an exemplary structure of the relationship of the firmware layers. Figure 7 is a schematic representation of the device driver layer. Figure 8 shows the information contained in response to the split state command. Figure 9 shows an exemplary format of an argument data section. 10A, 10B-1 and 10B-2 show the host side communication flow. Figures 11A through 11C illustrate a host application-device application agreement. Figure 12 is a state machine diagram of the command to hide the split application. Figures 13A through 13D show the processing flow of a group of commands in a hidden partitioning agreement. Figure 14 is a simplified version of Figure 4. Figure 15 is a schematic representation of a technique for transmitting data and commands in the system of Figure 3 in accordance with aspects of the present invention. Figure 16 provides details of Figure 15 in accordance with a particular embodiment. Figures 17A through 17L show a detailed description of the structure of the embodiment of Figure 16 for a number of commands. 116844.doc -71- 200809593 Figures 18A through 18H are similar to Figures 17A through 17L of the file level embodiment. [Main component symbol description]

101 card 105 firmware 151 host 153 slot 201, 203 command 331 reader 333 socket 335 firmware 351 PC 401 command 403 USB package 405 command 510 instruction 511 command part 513a first part of the data part 513b second part of the data part 530 Actual command 531 Command part 533 Data part 601 Command 1001 Card/device 1011 Memory 116844.doc -72- 200809593 1021 FE layer 1023 Device application 1025 Media layer 1027 BE layer 1051 Host 1053 Host application 1055 Device driver 1057 File system 1059 device application layer 116844.doc -73-

Claims (1)

200809593 X. The scope of application for patents: 1 · A method of operating a system, at the meeting place - Ling's system contains a memory card and a host that can exchange information and commands with the card parent, jrA, Ganju 卩7, among which The data and command exchange between the host and the card uses a first command set in a first phase of the transmission process and wherein the host and the card include-use-second agreement a second command set application, the method comprising: embedding: a command from the second command set embedded in a first instruction from the first agreement, the command not having the first command set a corresponding command; transmitting the first instruction from the host to the memory card; and extracting the embedded command in the card. 2. The method of claim 1, wherein the application using the second command set in the second protocol is one of a plurality of applications and the second agreement is in a plurality of corresponding second agreements Each of the plurality of second programs, and wherein the plurality of applications of the plurality of thorn programs are simultaneously operated. 3. As in the method of the requester, the host implements the embedding at the level of the system. The method of claim 3, wherein the command is for transmitting data from the host to the card, the data being placed in a poor portion corresponding to the file of the first instruction, the method The step-by-step includes determining that one of the cards is sufficient to accommodate the logical address of the file in the case of a segment. 5. The method of claim 1, further comprising: Α Λ 々疋 is used to transfer data from the card to the host; in response to determining that the command is for transmitting data from the card to the primary 116844. Doc 200809593 Machine, set - the flag used for this transfer; the data associated with the command is transmitted from the card. 6. The method of claim 5, wherein the transmitted data is less than all of the information associated with the data. And the method of claim 5, wherein the method of claim 5 further comprises: %, the data re-transmitted from the card in the second command. The new transport is associated with the command. 8. If the request item 1 ‧ 锬 锬 锬 由 由 由 由 由 由 由 由 由 由 由 由 由 由 由 由 由 由 由 由 由 由 由 ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' ' 其中 其中Exchanging the data with the card via the hardware adapter and wherein the host and the hardware adapter are by the first agreement: and wherein the first command is transmitted from the host to Transmitting, by the memory card, the first instruction from the host to the hardware adapter; translating the first instruction into a corresponding one of the second protocols in the hardware adapter; and the corresponding instruction Transfer from the hardware adapter to the memory card. 1. The method of claim 1, wherein the instruction from the first agreement includes a command portion including a command from the first agreement and a data portion, wherein the embedded command is embedded in the command In the data section. 11. The method of claim 1, wherein the data portion further comprises data associated with the fish embedded command. 12. The method of claim 11, the method further comprising determining whether the material associated with the embedded command included in the object 116844.doc 200809593 is associated with the embedded command All information. 3. The method of claim 12, the method further comprising, in response to determining that the material associated with the embedded command included in the bedding component is not all data associated with the internal defeat command, setting one The flag is used for the receipt of additional material associated with the embedded command. The method of claim 1, wherein the extracting the internal command in the card comprises: determining that the data portion includes a signature; and extracting from the data portion in response to confirming the signature in the instruction The inline command. 15. The method of claim 10, wherein the corresponding instruction comprises a command portion including a command from the second agreement and a data portion, wherein the internal print order is embedded in the data portion. 16. The method of claim 1, wherein the command from the first agreement is to a predetermined logical address. The method of claim 16, further comprising: after receiving the corresponding instruction transmitted in the card and extracting the embedded command in the card: determining that the corresponding command is to the predetermined logical address; and responding to the Determining that the corresponding command is to the predetermined logical address, confirming the food name in the instruction, wherein the embedded command is extracted in response to confirming the signature. The method of claim 17, wherein the determining that the corresponding command is to the predetermined ambiguous address, the confirming one of the signatures of the instruction, and the extracting the embedded life 116844.doc 200809593 is performed by the firmware of the card . 19. If the method of begging is requested, the further step involves executing the internal enemy command. 2〇·如:: Method of claim 1 wherein the second agreement is an SD agreement. A method of requesting a user, wherein the embedded command is a secure data access. 22. In the case of the ancient government of a request for a ^, ^, law, the second agreement is an MMC agreement. 23. The method of claim 1, wherein the second agreement is a -ΑΤΑ agreement. J. The method of claim 1 wherein the first agreement is a SCSI protocol. The method of the term 1 of the month, wherein the command is used to send data to the host and the card (4), and the towel woven material is not cached in the host. 26. A method of operating a system, the system comprising a memory card and a host for exchanging data and commands, wherein the host and the: the beaker and the command exchange use a first stage at a certain stage of the transmission process The first command set, and wherein the host and the card include an application of the second command set in the protocol, the method includes eight commands - a command from the second command set and a signature Embedded in the first instruction of the first-agreement, wherein the first instruction includes a "combination" portion and a data portion, and wherein the material name and the command from the second life 2 are embedded in the data portion 7; the city transmits the first instruction from the host to the memory card; determines whether the data portion of the first instruction contains the signature; and responds to the first instruction containing the signature, from the first instruction The material portion extracts the command from the second command set. ~贲27. The method of claim 26, wherein one of the second eight sets of the second agreement is used as one of the plurality of applications and the diagnosis is 咔116844.doc -4- 200809593 The agreement is a second of the plurality of respective second agreements, and wherein the plurality of applications of the plurality of applications can be simultaneously operated. The method of claim 26 wherein the portion of the data also includes information associated with the order from the first set of orders. The method of claim 28, the method further comprising determining whether the asset associated with the command from the second command set included in the data=knife is associated with the command from the second command set All information 0 30. The method of claim 29, the method further comprising, shouting that the poor material associated with the command from the second command set included in the data portion is not from the second command set All of the data associated with the command is set-flagged for receipt of additional material associated with the command from the second set of commands. 31. The method of claim 26, further comprising: determining whether the command is for transmitting data from the card to the host; in response to determining that the command is for transmitting data from the card to the host, setting one The flag used for the transmission, · 32. The material associated with the order is transmitted from the card. As with the method of claim 31, all the information associated. Wherein the transmitted data is less than the method of the command 33, such as the method of claim 31, which further comprises: the =: the second command is retransmitted from the card associated with the command. 34. The method of claim 26 The first instruction is a write. The method of claim 26, wherein the command from the second set of commands is a read. 36. The method of claim 26, wherein the signature is included in a predetermined section of the data portion. 37. The method of claim 26, wherein the instruction is used to access a data at a logical address address and wherein the data portion of the instruction determines whether the file has a name of A logical address corresponds to a predetermined 38. As in the method of claim 26, the host is implemented by the host at the file driver level. 9 39. The method of claim 38, wherein the command is used to transfer data from the host to the card, and the data is placed in a tribute portion corresponding to the first instruction, , the earth, the warehouse JK > , A. The method further comprises determining that one of the cards is sufficient to accommodate the logical address of the file in the case of a segment. Real 2:: The second party goes, wherein the host is at the card driver level 41. The method of claim 26, wherein the system further includes a hardware adapter, the host and the card via the hard The body adapter exchanges the data and the commands 'where the host and the hardware adapter communicate: and wherein the first instruction is transmitted from the host to the IS include · the first instruction from the Transmitting the host to the hardware adapter; translating the first instruction into a corresponding one of the second protocol in the hardware adapter; and 116844.doc 200809593 assigning the corresponding instruction from the hardware The connector is transferred to the memory card. 42. The method of claim 26, wherein the instruction from the first agreement comprises a command portion including a command from the first agreement and a data portion, wherein the embedded command is embedded in the data portion . 43. The method of claim 26, wherein the command from the first agreement is to a predetermined logical address. 44. The method of claim 26, further comprising executing the post-inner command. 45. The method of claim 26, wherein the second agreement is an SD agreement. The method of claim 45, wherein the embedded command is a secure data access. 47. The method of claim 26, wherein the second agreement is an MMC agreement. 48. The method of claim 26, wherein the second agreement is a one-by-one agreement. 49. The method of claim 26, wherein the first agreement is a SCSI protocol. 50. The method of claim 26, wherein the command is for transferring data between the host and the card, wherein the data is not cached in the host. 5 1. A method for operating a non-volatile memory card, comprising: 0 receiving an instruction, wherein the instruction comprises a command portion and a data portion; determining whether the data portion of the command contains a signature; and The instruction contains the signature and a command is taken from the data portion of the instruction. 52. The method of claim 51, further comprising: determining whether the command is for transmitting data from the card; and in response to determining that the command is for transmitting data from the card, setting a flag for the transmission; 116844.doc 200809593 The material associated with the order is transmitted from the card. 53. The method of claim 52, wherein the transmitted data is less than all of the material associated with the command. P 7 54. The method of claim 53, further comprising: responding to the first data. The second command is retransmitted from the card associated with the command. 55. The method of claim 51 wherein the data portion further includes material associated with the extracted command. The method of claim 55, wherein the method further comprises determining whether the material associated with the extracted command included in the portion of the material is all of the material associated with the extracted command. η Μ 57. The method of claim 56, wherein the method further comprises, in response to determining that the data associated with the extracted command included in the data portion is not all of the data associated with the extracted command, setting one The flag is used for receipt of additional material associated with the extracted command. 58. The method of claim 51, wherein the (d) is included in a predetermined section of the data portion. 59. The method of claim 51, wherein the instruction is in a first agreement set having a first command set and wherein the extracted command is from a second command set in a second agreement And does not have a corresponding command in the first command set. 60. The method of claim 59, the Ganshidou #, , , the middle two agreement is used in a plurality of applications and the second agreement is a respective application agreement in a plurality of corresponding application agreements, + _ μ 士 仏 疋, 疋 疋, and can be used to operate multiple applications in the application 116844.doc 200809593 program. The method of claim 5, wherein the instruction is used to access a logical address: and wherein the data portion of the instruction determines whether the signature portion corresponds to the first logical address - Pre-determined logical address. The method of claim 51, wherein the determining that the instruction includes a signature and the extracting - the command from the data portion of the instruction is performed by the blade of the card. 63. The method of claim 51, further comprising executing the extracted command. 64. The method of claim 51, wherein the instruction is in a sd agreement. 65. The method of claim 51, wherein the extracted command is a secure data access. 66. The method of claim 51, wherein the instruction is in an agreement. 67. The method of claim 51, wherein the instruction is in a seaming agreement. 68. A method of transmitting - from - an order of a first agreement, comprising: - % into an instruction from a second agreement, the instruction comprising an order accepting an associated data portion; from the first agreement The command and a signature indicating that the instruction contains a command to be swallowed in the associated data portion of the instruction; and transmitting the instruction. • The method of claim 68, wherein the first agreement is used in a plurality of applications and the first agreement is a respective application agreement in a plurality of corresponding application agreements, and wherein Operate the multiple applications in the program 116844.doc 200809593. 70. The method of claim 68, further comprising placing information associated with the command from the first agreement in the associated data portion. The method of claim 70, the method further comprising determining that the day of the non-inflammation of the order associated with the command from the first agreement is included in the data file. All the information of the association. The method of claim 71, the method further comprising: in response to determining that the data contained in the data portion is associated with the command from the first agreement: the mussel material is not associated with the command from the first agreement All of the poor materials are set a flag for receipt of additional information associated with commands from the first agreement. 73. The method of claim 68, wherein the instruction from the second agreement is ~ write. 74. The method of claim 68, wherein the command from the first agreement is - read. The method of claim 68, wherein the signature is placed in a predetermined section of the associated portion. 76. The method of claim 68, wherein the embedding is performed by the host at the file driver level. The method of claim 68, wherein the associated data portion is formed as part of a file. 78. The method of claim 68, wherein the instruction from the second agreement is transmitted to a predetermined logical address. 79. The method of claim 68, wherein the command from the first agreement is transmitted at 116844.doc 200809593 and wherein the data is not cached in the transmission device. 80. A method of operating a system, the system comprising a memory card and a host for exchanging data and commands with the card, wherein the data and command exchange between the host and the card are in the process of transmission The stage uses a first command set of a first agreement and wherein the host and the card include an application that uses a second command set of one of the second protocols, the method comprising Passing a command from the second command set to the first instruction from the first protocol; transmitting the first instruction from the host to a first logical address of the memory card; determining the inner Whether the embedded command is used to transfer data from the card to the stand-alone machine, and Ik transmits a second command from the host to the memory card; in response to determining that the embedded command is used to transfer data from the card to the card The money host determines whether the second instruction is to the first address in the memory card; and the mouth is to transmit the data from the card to the first address in the memory card The host. 81. The method of claim 80, wherein the first instruction is a write. 82. The method of claim 8 wherein the command from the second instruction is a 83. (4), if the request (10) is (4), the signature is included in the (4) predetermined section. 84. The method of claim 80, wherein the embedding is performed by the host at the slot level. To the layer 85. The method of requesting Liu, wherein the command is used to transfer data between the files, wherein the data is not cached on the host card 8 6. A memory card structure, which includes: Volatile memory; - the end layer 'is used to exchange instructions according to the -_ agreement with the host of the _, the first sound brake is connected, and the first layer determines the data portion of the incoming instruction in the first agreement Whether or not a sign of Wenshiwu is used to access the body according to the instruction in the first agreement in response to determining that the signature is absent; and the application layer is in response to determining that the first agreement is passed The incoming command contains a signature, and the incoming command is transmitted from the front end layer to the application 'where the information in the second protocol is extracted from the data portion of the relay instruction and according to the instruction in the second protocol Access this memory. 87. The memory card structure of claim 86 wherein the signature is included in a predetermined section of the data portion. 88. The memory card structure of claim 86, wherein the instruction is in a first agreement having a first set of commands, and wherein the extracted command is from a second command in a second agreement The set does not have a corresponding command in one of the first command sets. 89. The memory card structure of claim 86, wherein the instruction is to access data at a first logical address and wherein the determining whether the data portion of the instruction contains a signature system is responsive to the first logic The address corresponds to a pre-116844.doc -12· 200809593 logical address. 90. If the request item 86 is structured by a ^ structure, the front end layer and the application layer are implemented by your U firmware. In the case of item 86, the card structure is recalled, wherein the memory manages a plurality of such instructions. Weighed 92. m: The memory card structure of 91, wherein the application layer comprises a plurality of and wherein the plurality of instructions processed simultaneously are from more than one of the applications. 93. The memory card structure of claim 86, wherein in response to determining that the incoming command is for data transfer from the card, the application layer sets _ with a flag to convey and transmits from the stomach card The data associated with the incoming instruction/the memory card structure of claim 93, wherein the data associated with the incoming instruction is retransmitted from the card in response to a second incoming instruction. The memory card structure of claim 86, wherein the application layer determines whether the data portion further includes information relating to the instruction in the second agreement: 96. The memory card structure of claim 95, wherein the application layer determines whether the greed associated with the instruction in the second agreement included in the data portion is the same as the instruction in the second agreement All relevant information. 97. The memory card structure of claim 96, wherein the information associated with the instruction in the second agreement that is included in the data portion is not associated with the instruction in the second agreement For all data, the application layer sets a flag for receipt of additional material associated with the instruction in the second agreement. 116844.doc •13-