Identification of memory cards by host

Abstract

A host connected to two or more memory cards includes an interface manager that assigns card identifiers to memory cards according to the types of memory cards present. The interface manager also assigns volume identifiers to partitions within memory cards. Applications use a pathname that includes a card identifier and a volume identifier to access a partition and files.

Description

BACKGROUND OF THE INVENTION

This invention relates to memory cards and systems containing memory cards, including host systems that interface with two or more memory cards.

Nonvolatile memory systems are used in various applications. Some nonvolatile memory systems are embedded in a larger system such as a personal computer. Other nonvolatile memory systems are removably connected to a host system and may be interchanged between different host systems. Examples of such removable memory systems include memory cards and USB flash drives. Electronic circuit cards, including non-volatile memory cards, have been commercially implemented according to a number of well-known standards. Memory cards are used with personal computers, cellular telephones, personal digital assistants (PDAs), digital still cameras, digital movie cameras, portable audio players and other host electronic devices for the storage of large amounts of data. Such cards usually contain a re-programmable non-volatile semiconductor memory cell array along with a controller that controls and supports operation of the memory cell array and interfaces with a host to which the card is connected. Several of the same type of card may be interchanged in a host card slot designed to accept that type of card. However, the development of the many electronic card standards has created different types of cards that are incompatible with each other in various degrees. A card made according to one standard is usually not useable with a host designed to operate with a card of another standard. In some cases, cards may support the same standard, but have different form factors, e.g. SD, MiniSD, and MicroSD cards follow the SD standard but have different form factors. Memory card standards and/or form factors include PC Card, CompactFlash™ card (CF™ card), SmartMedia™ card, MultiMediaCard (MMC™), Secure Digital (SD) card, a miniSD™ card, Subscriber Identity Module (SIM), Memory Stick™, Memory Stick Duo card and microSD/TransFlash™ memory module standards. There are several USB flash drive products commercially available from SanDisk Corporation under its trademark “Cruzer®.” USB flash drives are typically larger and shaped differently than the memory cards described above. One type of SIM card contains a large amount of memory capacity, so that the SIM card may be used for mass data storage applications in addition to SIM functions. An example of such a memory card is a MegaSIM™ card from SanDisk.

A host system may be connected to two or more memory cards at the same time. However, where two or more memory cards are connected to a host, data may be stored in different memory cards, so keeping track of where particular data is stored can become a burden. Failure to keep track of the location of data may result in loss of data or failure of the host system.

SUMMARY OF THE INVENTION

In order to keep track of data in different memory cards, card identifiers may be assigned to individual cards. A card identifier may be assigned according to the type of memory card, so that for example, a MegaSIM card is assigned an identifier “M” while a Secure Digital card is assigned an “S” according to a predetermined mapping. Partitions within such cards may then be assigned volume identifiers. For example, volume identifiers may be assigned sequentially in each card. The combination of card identifier and volume identifier may then be used in a pathname when accessing data in a partition. Such a pathname clearly indicates the type of card being accessed, providing a convenient way to access different memory cards. Various method and system embodiments implement this approach examples of which are provided herein.

According to one embodiment, a method of generating identifiers for memory cards and for volumes within memory cards, when two or more memory cards are connected to a host, may comprise: maintaining a recorded relationship that maps memory card types to card identifiers, in a one-to-one mapping scheme; determining that a first memory card of a first type is connected to the host and in response assigning a first card identifier to the first memory card, the first card identifier assigned according to the recorded relationship; and determining that the first memory card contains at least a first partition and a second partition and in response assigning a first volume identifier to the first partition and assigning a second volume identifier to the second partition. Other method embodiments are possible and can be implemented as exemplified here.

In one instance, an application may refer to a file stored in the first partition using a pathname that includes the first drive identifier and the first volume identifier. Also, as implemented, the first partition may be a public partition that can be accessed without authentication, and the second partition may be a hidden partition that requires authentication for gaining access to data stored therein. Moreover, a recorded relationship may be maintained in a table that includes a unique identifier for each of a plurality of memory card types, including the first memory card type, a second memory card type, and additional memory card types. The first and second memory card types may each be any one of MegaSIM, Secure Digital, Trusted Flash or like card. Furthermore, a host may be connected to a wireless network and the first memory card may include Subscriber Identity Module information that identifies the host to the wireless network.

According to another embodiment, a host device with capacity for two or more memory cards may comprise: a first physical interface that connects the host device to a first memory card of a first type; a second physical interface that connects the host device to a second memory card of a second type; and a storage medium in the host device, the storage medium storing software that associates a first card identifier with the first memory card in response to a determination that the first memory card is of the first type and associates a second card identifier with the second memory card in response to a determination that the second memory card is of the second type. Different embodiments of a host device are possible and can be implemented as exemplified here.

In one instance, a host device may comprise additional software stored in the storage medium that associates a first partition of the first memory card with a first volume identifier and associates a second partition of the first memory card with a second volume identifier. A host device may comprise an application that accesses data in the first portion of the first memory card using the first card identifier and the first volume identifier in a pathname. A host device software may be generated using a software toolkit that specifies the first identifier for any card of the first type and specifies the second identifier for any card of the second type. The software toolkit may include routines that are incorporated in the software stored in a storage medium. As used with the method embodiments, the first and second memory card types may each be any one of MegaSIM, Secure Digital, Trusted Flash or like card. A first memory card, such as a SIM card, can be used by the host to connect to a wireless network.

According to yet another embodiment, a toolkit for developing software that manages a host interface to two or more memory cards may comprise: a data recording medium; a mapping recorded in the data recording medium, the mapping including a one-to-one relationship between types of memory card and card identifiers; and software program recorded in the data recording medium, the software program including a routine for mapping two or more memory cards to card identifiers according to the mapping recorded in the data recording medium.

With such a tool kit, mapping may be recorded as a table that includes identifiers for memory card types including the MegaSIM, Secure Digital, and Trusted Flash and any other like card. A routine is typically stored in a dynamic-linked library or statically-linked library that contains additional routines. Then, a toolkit may comprise additional routines for managing interactions between a host and two or more memory cards.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an example of a host connected to two memory cards.

FIG. 2 shows an example of a host connected to two memory cards, the host assigning card identifiers to each of the memory cards according to their memory card type.

FIG. 3A shows an example of a host having interfaces to two memory cards, and having an interface manager.

FIG. 3B shows an example of a host having interfaces to two memory cards, and having a host Operating System that includes an interface manager.

FIG. 3C shows an example of a host having interfaces to two memory cards, and having an application that includes an interface manager.

FIG. 4 shows a table that provides a one-to-one mapping between different types of memory cards and card identifiers.

FIG. 5 shows a flowchart for a scheme that assigns card identifiers to memory cards.

FIG. 6 shows an example of using a pathname that includes a card identifier, a volume identifier, and a filename.

FIG. 7 shows a Software Development Kit used in a software development process.

DETAILED DESCRIPTION OF ILLUSTRATED EMBODIMENTS

Where two or more memory cards are connected to a host, the host may store data in different memory cards, so some system must be used to distinguish between memory cards. For some applications it is critical that data be stored in a particular type of memory card (e.g. for security purposes). With memory cards that are removable and interchangeable, keeping track of data stored in different memory cards is not always straight-forward. Assigning identifiers allows cards, or partitions within cards, to be conveniently managed.

One possible scheme for assigning identifiers to memory cards, and to partitions within memory cards, assigns identifiers on a dynamic basis, so that the same card or partition may be assigned a different identifier depending on when it is connected to the host. FIG. 1 shows a host 101 which uses dynamic assignment of identifiers for each partition within two memory cards. Identifiers 0, 1, and 2 are assigned to partitions in card A, while identifiers 3, 4, and 5 are assigned to partitions in card B. Identifiers are assigned sequentially (generally during a power-up routine) to card A, then further identifiers are assigned to card B. When a new card is inserted, additional identifiers are assigned. This is similar to a dynamic system of assignment used by some PC operating systems that assigns drive letters to partitions in memory. The same partition may be assigned different drive letters at different times, which may be confusing, and may require applications, or the operating system, to perform additional functions to track stored data. Because the configuration of removable memory cards may change between one session and another, an application cannot simply use such a drive letter to refer to a partition during two or more sessions.

Memory card identifiers may be assigned in a predetermined manner based on the type of memory card. For example, a Trusted Flash card is assigned a particular identifier that is reserved exclusively for Trusted Flash cards, while a MegaSIM card is assigned a different identifier that is reserved exclusively for MegaSIM cards. Thus, rather than dynamically assigning identifiers to cards, identifiers are mapped to card types in a one-to-one mapping, and this mapping is used to assign the appropriate identifier to a particular memory card according to its card type.

In addition to identifying each card by a card identifier, a volume identifier may be assigned to each partition within a card. The same volume identifiers may be used in different cards, because the different card identifiers clearly identify each card and thus the combination of card identifier and volume identifier provides a unique identification of each partition, even if the same volume identifier is used in two or more cards.

FIG. 2 shows an example of a host 211 that is connected to two memory cards, each of a different card type. A Trusted Flash Card 213 is assigned a card identifier by the host. In this case, the card identifier for Trusted Flash Card 213 is “T.” Each partition within Trusted Flash card 213 is then assigned a volume identifier in a sequential manner from “0” to “2.” Thus, partitions of Trusted Flash card 213 are identified as T0, T1, and T2. A MegaSIM card 215 is also assigned a card identifier by the host. In this case, the card identifier for the MegaSIM card is “M.” Each partition within MegaSIM card 215 is then assigned a volume identifier in a sequential manner from “0” to “2.” Thus, partitions of the MegaSIM card 215 are identified as M0, M1, and M2.

FIG. 3A shows an example of a host 321 that is connected to two memory cards 323, 325. Host 321 includes an Operating System (OS) 327 and applications 329-331. Host 321 also includes interfaces 333, 335 to memory cards 323, 325, an interface manager 337 connected to the interfaces 333, 335, and a table 339. Interface manager 337 is responsible for assigning identifiers to memory cards and to partitions within the memory cards. Interface manager 337 provides these identifiers to OS 327 so that OS 327 and any applications running on OS 327 (or other applications in communication with OS 327) may use the identifiers when accessing data stored in the memory cards. Interface manager 337 may consist of dedicated hardware, a combination of dedicated hardware and software, or may be implemented in software that does not require dedicated hardware. In one example, interface manager 337 is developed using a Software Development Toolkit (SDK), which may contain some, or all of the routines necessary to implement the interface manager. In the example of FIG. 3A, interface manager 337 is a module that is separate from OS 327, but in communication with OS 327 and with interfaces 333, 335. This may be a physically separate hardware module, or a separate software module on shared hardware. Interface manager 337 is connected to a table 339, and interface manager 337 uses table 339 to determine which identifier to assign to a particular memory card.

FIG. 3B shows another example of a host 341 in which an interface manager 343 and a table 345 are part of an OS 347. As in FIG. 3A, there are applications 349-351 running on OS 347, which may access data within memory cards 353, 355. In this example, access to memory cards 353, 355 is managed by interface manager 343 in OS 347. Interface manager 343 assigns memory card identifiers and volume identifiers, which are then used by OS 347 and the applications 349-351 to access memory cards 353, 355. Such an OS, with an integrated interface manager, may be developed using an SDK that contains routines for the interface manager, and a table containing card identifiers.

FIG. 3C shows another example of a host 361 in which an interface manager 363 and table 365 are included in an application 367. In this example, assignment of memory card identifiers and volume identifiers is performed by interface manager 363 within application 367. The assignment of identifiers by interface manager 363 may be instead of assignment by an OS 369, or may be in addition to some assignment by OS 369, with translation performed between identifiers. In addition, other applications 371, 373 may include additional interface managers and tables, each performing assignment of identifiers for cards 375, 377. Alternatively, all applications may use the same identifiers provided by the first interface manager. In this case, the host application that includes an interface manager uses certain functionalities to carry out the operation. One such functionality could be access to low-level driver Input/Output (I/O) functions. Then, the interface manager in the application may bypass other host OS services and use only host OS services that are needed. Such an application, which has an integrated interface manager, may be developed using an SDK that includes routines for the interface manager, and a table containing card identifiers.

FIG. 4 shows the contents of a table 481 such as the tables of FIGS. 3A-C. The table shows a recorded relationship between different memory card types and card identifiers. Thus, table 481 provides a one-to-one mapping between card types and card identifiers. Each memory card type is mapped to a card identifier that is exclusively used for cards of that type. Table 481 shows entries for cards including MegaSIM, Secure Digital, Compact Flash, and Trusted Flash. Other memory card types may also be recorded in the table, including any of the earlier listed types and any other memory card types. Table 481 shows single letters being used as card identifiers, specifically the first letter of the name of the card type (e.g. “M” for MegaSIM). This provides a compact and efficient system of identification. In other examples, different letters may be used, or different characters (e.g. numerals or symbols). In yet other examples, more than one letter or character may be used. While a table provides a simple arrangement for recording relationships between card types and identifiers, other structures may also be used to record such a relationship. The table, or other recorded relationship, is generally recorded within a data storage medium in the host system. Such a table may be updated as new types of memory card become available to allow legacy hosts to interface with newer types of cards.

In order to assign an identifier from a table such as table 481, an interface manager determines the type of memory card that is present. In some cases, this is determined by the physical interface to which it is connected. Certain memory card slots are exclusively used with one type of memory card, so that any card detected in such a memory card slot must be of the corresponding card type. However, some memory card slots may be used with more than one type of memory card. In this case, an interface manager may perform a detection routine to determine the type of card that is present. For example, the interface manager may interrogate the card to obtain identifying information, or may obtain the card type from another part of the host system that obtains this information from the memory card.

FIG. 5 provides a flowchart illustrating the operation of an interface manager. First, the type of card is identified 585, i.e. it is determined if the card is a MegaSIM card, SD card, Trusted Flash card, or some other type of card. Next, the appropriate card identifier is found 587 by looking up a table that contains a one-to-one mapping scheme between card types and card identifier. The appropriate card identifier from the table then becomes the identifier for the card. Next, a first volume identifier is assigned 589 to the first partition of the card. For example, the first volume identifier for the first partition of a card may be “0.” Next, if there are any other partitions found on the card, subsequent volume identifiers are assigned to them 591. For example, volume identifiers 1, 2, 3 . . . may be used. In other examples, different numerals may be used, or other characters such as letters may be used as volume identifiers. If there are any other cards 593, this sequence is then performed for any other cards that are under the control of the interface manager so that each partition found by the interface manager is assigned an identifier.

FIG. 6 shows a host 602 connected to three memory cards 604-606, each assigned a different card identifier according to memory card type. In other examples, four or more memory cards may be connected to a host and assigned card identifiers in this way. Host 602 of FIG. 6 includes an application 608 that accesses data in a memory card connected to host 602. In particular, application 608 accesses a file 610, called “testfile,” that is stored in a first partition 612 of a Trusted Flash card 604. Because card 604 is Trusted Flash, it is assigned “T” as a card identifier, and because partition 612 is the first partition, it is assigned “0” as the volume identifier. Therefore, partition 602 can be identified by a combination of card identifier and volume identifier. Application 608 identifies file 610 by providing a pathname “T0:\testfile” that is used to access file 610 in Trusted Flash card 602. The pathname is provided to an interface manager 614 in this example, though in other examples, an OS (not shown in FIG. 6) or other components may manage such access. In other examples, a pathname may include additional portions that identify, for example, folders or other groupings within a partition.

In one example, the first partition of a card is a public access partition, which an application can access without providing any authentication. The second partition is a secure partition, or hidden partition, which an application can only access after providing some authentication. In this way, secure content may be kept in the second partition and may only be accessed by users having permission. For example, music or other content that is subject to restricted use may be stored in the second partition.

In one example, a host is a mobile device such as a cell phone or Personal Digital Assistant (PDA) that is in communication with a wireless network. A SIM card (MegaSIM card or other type of SIM card) is connected to the host to identify the host to the network and allow the host to communicate over the network. Where a MegaSIM card is used, additional content may be stored in the MegaSIM card. If a regular SIM card (not a MegaSIM card) is used, then it may not have storage capacity for a large volume of content. In this case, such content may be stored within a memory card, such as an SD card, Trusted Flash card or in the host's internal memory. Additional network-specific content may be stored in the MegaSIM card or in the TrustedFlash card. For example Mobile Network Operators (MNOs) may provide content in such cards that is accessible to their customers. Another memory card, such as an SD card, may be connected to the host and may store content that is unrelated to the network to which the host is connected. For example, the second memory card may store a user's music files or other content. Such content is specific to the user, and may be accessed by other hosts when the card is moved, but is unrelated to the network. Using identifiers that are specific to the type of memory card, the division between network-specific storage and user-specific storage is clear. An OS, and applications can easily direct access to one or the other by using appropriate identifiers

An interface manager, such as those discussed above, may be implemented by software that is created using a Software Development Toolkit (SDK). For example, a memory card manufacturer may provide an SDK to assist host manufacturers in integrating memory cards into their devices. SDKs may include software routines and data that are incorporated into host software as part of the OS, within applications, or in software that is separate from the OS and applications. For example, software routines from the SDK may be incorporated into an interface manager, such as interface managers described above, thus facilitating the integration of different memory cards with a host.

FIG. 7 shows an example of an SDK 720 that contains various components that can be used in a host, including a table 722 and a Dynamic Linked Library (DLL) 724. DLL 724 includes routines that can be used in larger software structures including applications or a host OS. SDK 720 is provided to a software developer (e.g. development of host software for a particular host) who then uses the SDK in a software development process 726 to produce host software 728. Host software 728 in this example includes table 722 provided by SDK 720 and also includes an interface manager 730 that includes DLL 724 from SDK 720. That is, certain routines used by interface manager 720 were provided in DLL 724 in SDK 720 (such routines may also be shared by other host software). Routines may also be provided in an SDK in a statically-linked library, or in any other convenient form. In some cases, an interface manager may consist entirely of routines provided by the SDK. In other examples, additional routines are provided to customize software (for a particular hardware, for example). The host software produced in this way may be a host OS, an application, or other software unit. For example, any of the host software arrangements of FIGS. 3A-C may be developed using SDKs as described.

Although the foregoing describes various aspects of these embodiments, it is understood that modifications thereto and other embodiments with similar or different aspects are possible. Accordingly, the claims should not be limited to the embodiments described herein.

Claims

1. A method of generating identifiers for a memory card and for volumes within a memory card, when a memory cards is connected to a host, comprising: maintaining a recorded relationship that maps memory card types to card identifiers in a one-to-one mapping scheme;determining that a first memory card of a first type is connected to the host and in response assigning a first card identifier to the first memory card, the first card identifier assigned according to the recorded relationship; anddetermining that the first memory card contains at least a first partition and a second partition and in response assigning a first volume identifier to the first partition and assigning a second volume identifier to the second partition.

2. The method of claim 1 further comprising: an application in the host referring to a file stored in the first partition using a pathname that includes the first drive identifier and the first volume identifier.

3. The method of claim 1 wherein the first partition is a public partition that can be accessed without authentication, and the second partition is a hidden partition that requires authentication for gaining access to data stored therein.

4. The method of claim 1 wherein the recorded relationship is maintained in a table that includes a unique identifier for each of a plurality of memory card types, including the first, second and any other memory card types.

5. The method of claim 4 wherein the first and second memory card types are each ones of: MegaSIM, Secure Digital, and Trusted Flash.

6. The method of claim 1 wherein the host is connected to a wireless network and the first memory card includes Subscriber Identity Module information that identifies the host to the wireless network.

7. A host device with capacity for two or more memory cards, comprising: a first physical interface that connects the host device to a first memory card of a first type;a second physical interface that connects the host device to a second memory card of a second type; anda storage medium in the host device, the storage medium storing software that associates a first card identifier with the first memory card in response to a determination that the first memory card is of the first type and associates a second card identifier with the second memory card in response to a determination that the second memory card is of the second type.

8. The host device of claim 7 further comprising additional software stored in the storage medium that associates a first partition of the first memory card with a first volume identifier and associates a second partition of the first memory card with a second volume identifier.

9. The host device of claim 7 further comprising an application that accesses data in the first partition of the first memory card using the first card identifier and the first volume identifier in a pathname.

10. The host device of claim 7 wherein the software is generated using a software toolkit that specifies the first identifier for any card of the first type and specifies the second identifier for any card of the second type.

11. The host device of claim 7 wherein the software toolkit includes routines that are incorporated in the software stored in the storage medium.

12. The host device of claim 7 wherein the first and second memory card types are each ones of: MegaSIM, Secure Digital, and Trusted Flash.

13. The host device of claim 7 wherein the first memory card is a SIM card, which is used by the host to connect to a wireless network.

14. A toolkit for developing software that manages a host interface to two or more memory cards comprising: a data recording medium;a mapping recorded in the data recording medium, the mapping including a one-to-one relationship between types of memory card and card identifiers; andsoftware program recorded in the data recording medium, the software program including a routine for mapping two or more memory cards to card identifiers according to the mapping recorded in the data recording medium.

15. The toolkit of claim 14 wherein the mapping is recorded as a table that includes identifiers for memory card types including: MegaSIM, Secure Digital, and Trusted Flash.

16. The toolkit of claim 14 wherein the routine is stored in a dynamic-linked library or statically-linked library that contains additional routines.

17. The toolkit of claim 14 further comprising additional routines for managing interactions between the host and the two or more memory cards.