Many commonly used devices, e.g., specialized data processing hosts, such as mobile telephones or DVD players, are characterized by two limitations: first, they support only a limited set of file types, and second, they have relatively low processing power (e.g. as compared to personal computers). Routinely, these host devices are used to access data files from peripheral storage devices that also contain files that the hosts cannot process. Since the host device must process the file system of the storage device to extract the files it supports, the presence on the storage device of files not processable by the host causes an excessive load on the processing power of the host, resulting in unwanted delays for users of the host device.
In the example of a DVD player accessing a USB flash drive for movie files, the USB flash drive may also contain files that the DVD player cannot support. Despite safeguards that might be in place to guard against destructive effects of non-supported files, the mere presence of the non-supported files decreases the DVD player's processing power available for desired tasks. For instance, if the DVD player is designed to display on the screen of an attached television the entire list of files stored on the USB flash drive, a portion of the limited processing power of the DVD player must be diverted to display information that is not of interest to many users. Even if non-supported files are not displayed, the DVD player must still devote resources to determine that they are not supported. As a result, a user must wait longer to see the desired information on the television screen and subsequently to play the desired program.
In addition to processing power, another resource that is limited for many hosts is the size of the associated display. For example, an MP3 player or a mobile telephone with MP3 capability may not have a large enough display area to conveniently display the entire names of the files that are stored on an attached transient storage device SD memory card. For example, for a list of filenames “Fifties Favorite: Elvis Presley's ‘All Shook Up,’” “Fifties Favorite: Elvis Presley's ‘Love Me Tender,’” “Fifties Favorite: Elvis Presley's ‘Jailhouse Rock,’” and so on, the MP3 player would not display distinguishing information if filenames were truncated before the thirty-fifth character, as may be done to save display space. If the MP3 player instead displayed the entire file names, the MP3 player could not display as many file names at one time.
Accordingly, it would be desirable to be able to filter the files stored in a peripheral storage device before the files are presented to a host. Thereby, limited resources of the host, such as processing power and display space, could be focused upon the data of interest.
The present inventors have developed devices and methods for filtering the data of a local storage device before they are provided to a host. Such filtering reduces the demand on host resources, such as processing power and display area. Embodiments of the invention include a filtering method, a filtering device, and a filtering device combined with the local storage device.
According to an example embodiment, a device for filtering a file system of a local storage device has a local storage device interface, a host interface, and a controller. The local storage device interface is for communicating with a local storage device, which has a native file system, and the host interface is for communicating with a host. The controller is also operationally connected to the local storage device interface and to the host interface, and it is operative to read the native file system of the local storage device, to establish access criteria for a host, and to create a logical structure of sectors in a volatile memory based on the access criteria to provide a filtered file system.
The device for filtering a file system may further include the volatile memory in which the logical structure of sectors is created. Also, the device for filtering a file system may further include a wireless receiver operative to provide signals to the controller.
In the device, the controller may create the filtered file system based on host attributes. The filtered file system may filter the native file system according to one or more file-level conditions.
The local storage device interface of the device for filtering a file system may comply with the USB standard. The host interface may be a wired or wireless interface. The wired or wireless interface may comply with the USB standard.
According to another example embodiment, a local storage assembly may have a local storage device and a device for filtering a file system as discussed above. The local storage device in this embodiment has a native file system.
Also disclosed herein is a method of filtering a file system to be provided by a local storage device to a host. The method includes reading sectors of a native file system of a local storage device, establishing access criteria for a host, and creating a logical structure of sectors in a volatile memory based on the access criteria to provide a filtered file system. The reading of the sectors of the native file system may include communicating in compliance with the USB standard. The access criteria for the host may be established according to a file-level condition.
The method may include determining attributes of a host, wherein the access criteria for the host are established in accordance with the attributes of the host. The determining of the attributes of the host may include receiving information about the attributes from the host. The information about the attributes from the host may be received in a message conforming to the IEEE 1667 Probe command. The determining of the attributes of the host may include detecting a type of host based on communication heuristics. Also, the determining of the attributes of the host may include receiving a signal external to the local storage device and the host.
The method may include pre-configuring the local storage device for at least one specific type of host. Also, the method may include providing the filtered file system to a host through a wired interface or wireless interface, and the interface may comply with the USB standard.
The method may include additional elements. For example, the method may include requiring authentication before allowing the host access to at least a portion of data stored in the native file system. Also, the method may include reading the sectors of the native file system again after creating the logical structure of sectors in the volatile memory, thereby detecting changes that have occurred in the native file system after creating the logical structure of sectors in the volatile memory, and updating the sectors in the volatile memory to produce an updated filtered file system. Further, the creating of a logical structure of sectors may include renaming files of the native file system stored in the local storage device. Additionally, the filtered file system may be a transformation of the native file system created by changing a hierarchy or organization of a file structure of the native file system.
Further disclosed herein is a method of filtering a file system to be provided by a local storage device to a host. The method includes operating a first host to read sectors of a native file system of a local storage device, establishing access criteria for a second host, and creating a logical structure of sectors in a volatile memory based on the access criteria a filtered file system. The method may include requiring authentication before allowing the first host access to at least a portion of data stored in the native file system and/or allowing the second host access to at least a portion of data stored in the native file system.
Example embodiments of the present invention are described in detail below with reference to the accompanying drawings, which are briefly described as follows:
The invention is described below in the appended claims, which are read in view of the accompanying description including the following drawings, wherein:
The claims below will be better understood by referring to the present detailed description of example embodiments. This description is not intended to limit the scope of claims but instead to provide examples. Described first is an example embodiment of a filter in accordance with the present invention. Described next are multiple example embodiments of methods of filtering in accordance with the present invention.
The local storage device interface 22 operationally connects a local storage device 28 to the filter 20. In the context of the present disclosure, the term “local storage device” refers to a storage device having a point-to-point connection and a master/slave relationship with a host (the host being the master and the local storage device being the slave). The term “peripheral storage device” is used herein interchangeably with the term “local storage device.” Local storage devices applicable to the instant disclosure include but are not limited to those that comply with any of the following formats: ATA, SCSI, IEEE 1394, USB (mass storage device class).
The preceding abbreviations are known in the art as follows. ATA refers to “Advanced Technology Attachment,” which is a disk drive interface standard. SCSI refers to “Small Computer System Interface,” which is a processor-independent standard for a parallel bus for interfacing between a computer and intelligent devices (for example, hard disks, CD-ROMs, and scanners). (IEEE refers to the Institute of Electrical and Electronics Engineers, a professional society focusing on electrical engineering interests.) “IEEE 1394” refers to a serial bus interface standard offering high-speed communications and isochronous real-time data services. USB refers to “Universal Serial Bus,” which is an external peripheral interface standard for communicating between a computer and external peripherals over cable using bi-serial transmission.
The local storage device 28 has a native file system (a “first” file system) stored in a non-volatile memory of local storage device 28. The term “native file system” references the physical storage of the storage device 28, that is, file system information (e.g. regarding format and organization), metadata, and file contents or data. The local storage device interface 22 selected for the filter 20 may be one that complies with the USB standard (e.g. to accommodate a USB local storage device), and the local storage device interface 22 may be a wired or a wireless interface.
The host interface 24 operationally connects a host 30 to the filter 20. The term “host” is used interchangeably with the term “host device.” Example hosts include a personal computer, a mobile phone, a camera, a DVD player, a television, and a network-attached storage server. The filter 20 thus serves as an interface between host 30 and local storage device 28. The host 30 and the local storage device 28 may be such as are conventionally connected directly to each other. The host interface 24 selected for the filter 20 may be one that complies with the USB standard, and the host interface 24 may be a wired or a wireless interface.
The controller 26 is operationally connected to the local storage device interface 22 and to the host interface 24. As discussed in more detail below, the controller 26 reads the sectors of the native file system of the local storage device 28, establishes access criteria for the host 30, and creates a logical structure of sectors in a volatile memory based on the access criteria to provide a second file system.
The second file system need not have any physical embodiment and is therefore distinct from the native file system. The second file system provides and/or organizes files differently than does the native file system, in order to permit or facilitate interaction between applications, devices, etc. that may have different or differently organized native file systems. For example, the second file system may “filter” the files of the native file system, showing only certain files of the native file system (selected based on certain criteria) as available or present in the local storage device. In the context of this disclosure, the second file system may hereafter be referred to as a filtered file system.
The second file system includes a specification of the relationship between the files (or representation/organization thereof) of the second file system and the files (or representation/organization thereof) of the native file system, e.g., a mapping between the logical addresses specified within structures of the second file system and the logical addresses specified within structures of the native file system.
The native file system and the second file system do not need to be of the same type. As a non-limiting example, one file system could be JFFS2 and the other could be FAT. Each of the native file system and the second file system may be another type of file system suitable for removable storage, as will be understood by one of ordinary skill in the art.
The volatile memory, in which controller 26 generates the logical structure of sectors, may be a RAM 32 embedded within the controller 26, as shown in
Optionally, the filter 20 may have a wireless receiver 34 to receive signals from an external source (e.g. host 30 or local storage device 28) for the controller 26. In a different example embodiment, the filter 20 would have a wired connection to the host 30 and the controller 26 may receive external signals through the wired connection mediated by the use of command buttons (not shown) located, e.g., on a casing of the filter 20. (The command buttons, when pressed, would send signals to the controller 26.) This arrangement may be used in place of (or in addition to) the arrangement in which the controller 26 includes a wireless receiver 34 to receive signals.
The various uses to which such external signals may be put, e.g., to provide information about the host type or host attributes (which is used to establish access criteria), or to authenticate a user, or to hide all files having specific metadata characteristics (i.e. to implement filtering according to a file-level condition) are discussed below in appropriate places throughout the application.
The local storage device 28 and the filter 20 together constitute a local storage assembly 36. In the context of the present disclosure, the term “local storage assembly” refers to the combination of a filter and a local storage device. The assembly 36 can function as portable storage for multiple hosts, wherein the filter 20 of the assembly 36 can be designed to create for each of the multiple hosts a second (filtered) file system appropriate for the respective host. (The filter 20 can effectively operate as multiple different filters, and can but need not be configured as multiple physical devices.) In this way, each of the multiple hosts can operate more efficiently than if the file system of the local storage assembly 36 were provided in the same way (e.g. providing the same filtered file system) for each host.
As will be appreciated by those of ordinary skill in the art, filter 20, local storage device interface 22, host interface 24, and controller 26 may be implemented by a suitable combination of hardware, software, and/or firmware, as will be understood by those of skill in the art.
Another example embodiment of the present invention, illustrated by flow chart 38 in
As for step S1, the sectors of the native file system of the local storage device may be read by any means known to one skilled in the art. For example, the reading could include communicating in compliance with the USB standard.
As for step S2, the access criteria for a host are established. The access criteria are established based on host attributes. Host attributes may be explained in terms of the following examples. (As mentioned above, example hosts include a personal computer, a mobile phone, a camera, a DVD player, a television, and a network-attached storage server, among others.) One example of a host attribute would be the ability to process only certain file types. For instance, the host could be a DVD player that is only able to process files in DVD format. By making use of filter 20 to provide to the host a filtered (second) file system showing only files in DVD format, the DVD player does not need to allocate any of its limited resources to process unsupported files. Another example of a host attribute would be the bit rate at which the host is able to render data. By creating a filtered (second) file system that presents to the host only files suitable for consumption (for example, playback) at bit rates supported by the host, the host does not need to allocate resources to process unsupported files. Still another example of a host attribute is the ability (restriction) of being able to read only those file systems that are based on (or compatible with) the host's native operating system. Such a host attribute could be possessed by a host such as a personal computer. Other examples of host attributes will be appreciated by those skilled in the art.
Now that it is understood what is meant by “host attributes,” the term “access criteria” can be understood, as particular access criteria may be deemed to be effectively defined in terms of corresponding host attributes. “Access criteria” are the criteria a file must satisfy (e.g. the characteristics that a file must possess) for the file to be compatible with given host attributes. For example, if the host has the attribute that it can only process files in DVD format, the corresponding access criterion is that a file must be in DVD format. Only files satisfying this criterion would be permitted to be presented by the storage device to the host.
The access criteria may be stored in a volatile memory, such as in a RAM of the filter or the storage device, for use when processing read requests. Alternatively, the access criteria may be stored in a non-volatile memory in either the filter or the storage device.
Returning to the flowchart 38 of
The processor determines, based on the access criteria, which files in the native file system may be represented to the host in their original form (discussed below with reference to
Directory table 40 includes the following exemplary fields, which are also known as “directory elements” (the number of bytes allotted for each field of directory table 40 is indicated in the second row 48): (1) “File name” (8 bytes), (2) file extension (i.e.,” Extension”, 3 bytes), (3) “Attributes” (1 byte), (4) “Reserved” (1 byte), (5) “Create Date/Time” (5 bytes), (6) “Last access date” (2 bytes), (7) “First cluster” (high word, 2 bytes), (8) “Last modified Date/Time” (4 bytes), (9) “First cluster” (low word, 2 bytes), and (10) file size (i.e., “Size”, 4 bytes). The numbers in the directory table 40 are illustrated in hexadecimal format. (For convenience, the illustrated directory entries are only a partial representation of the actual directory structure.) This entry structure is valid specifically for FAT32 format file systems as implemented in Windows XP and Vista. FAT16 and legacy DOS format file systems use a slightly different structure. For example, FAT16 file systems use a structure that does not include the high word of the first cluster number, and the legacy DOS structure (used by some DVD players for reading files) has a reserved block of 10 bytes instead of 1 byte, followed by the low word of the first cluster number. Embodiments discussed herein may employ file system formats, and implementations, other than those mentioned here, as will be appreciated by those of skill in the art.
Accordingly, the processor of the filter modifies the attribute “20” of the file RANDOM.EXE (i.e. the attribute of directory entry 44 shown in
Of course, the above discussion of
As the above examples show, the filtered file system may be created based on information about the host attributes. In addition to or as an alternative to creating a filtered file system based on the host's attributes, the filtered file system may be designed to filter the native file system according to one or more file-level conditions. An example of filtering according to a file-level condition would be omitting any file whose metadata (e.g. file name) includes certain information (e.g. a certain text string, e.g. the text string “confidential” or “adult”). Another example of file-level condition filtering would be translating all file names corresponding to a format unsupported by a given host (e.g. host 30) to filenames corresponding to a format supported by the given host, as shown above in the discussion of
Yet another example of file-level condition filtering would be removing from all file names a common prefix shared by all file names. In this case, the creating of a logical structure of sectors (step 3 of
The filtered file system could also be a transformation of the native file system created by flattening or otherwise changing the hierarchy or organization of the file structure of the native file system. For example, the filtered file system may provide files from different folders or directories in the native file system as being all in the same folder or directory, or the filtered file system may provide files that are unsorted in the native file system as being sorted into different folders (for example, according to their prefix or file type), or files that are sorted in the native file system as being sorted in a different fashion, or the like.
Remapping files to folders could be used to retain, in the names of the folders, information originally contained in the file names that might otherwise be lost due to truncation of the file names by the host. For example, if the files start with “my vacation Spain—week 1—”, “my vacation Spain—week 2—”, “my vacation Florida—”, and “kids baseball games—”, the generated file structure might be as below based on commonality of prefixes between files. Note that the user would not need to edit the file names or create the folder structure.
The filtered file system may be a transformation of the native file system created by converting the format of some or all of the files of the native file system. For example, all files of a given format unsupportable by the host 30 could be converted to files of a format supportable by the host 30. Other ways of creating the filtered file system, including other ways of filtering, and other file-level conditions will be appreciated by one of ordinary skill in the art. Thus, the filtered file system can be designed to present files in ways that are convenient to a user, e.g., according to which types of host device the user uses.
In a variation of the method shown in
External signals conveying host type or host attribute information may be received via a wireless receiver (e.g. wireless receiver 34 of
As for the controller 26 receiving the information about the host's type or attributes from the host, the host may send this information in a message that conforms to the IEEE 1667 Probe command.
Determining host attributes by detecting host type based on communication heuristics means analyzing the requests sent by the host, inferring the host type according to a conjecture based on this analysis, and deducing the host attributes from the inferred host type. In some example scenarios, as soon as the storage device is operatively connected to a host (e.g. a DVD player), the host will send approximately 25 to 30 initial commands (such as query commands to determine the device type) to the storage device before the host will begin attempting to read the file system of the storage device. The timing of the commands, their order, and similar variables serve as parameters of a pattern, known as a communication pattern or communication signature. This pattern varies, i.e. is correlated, with host type (for at least some hosts), and thus can be recognized by the controller 26 as indicative of a particular type of host. It is known, for at least some hosts, that a host of given type has at least certain attributes. Thus, once host type is known, host attributes may be deduced therefrom. (Indeed the recognition of the communication pattern by the controller can be performed before the filter 20 needs to begin the processes of providing a filtered file system.).
As mentioned, another way to determine the attributes of the host is to receive a signal originating from a source that is external to both the local storage device and the host. For example, such a signal might be transmitted from a remote control transmitter. Alternatively, the signal might be sent to the processor, such as controller 26 of filter 20 in
When the host attributes are determined, the access criteria for the host can be established in accordance with the determined host attributes, as explained above (
When the access criteria, corresponding to the host's attributes, have been established, the controller 26 can create the second (filtered) file system based thereon. Creating a second (filtered) file system, based on the host access criteria, has been described above, e.g. with reference to
As an alternative (or an addition) to determining host attributes on the fly, in another variation of the method shown in
In yet another variation of the method shown in
To accommodate the fact that the contents of a local storage device may change over time, another variation of the embodiment of
According to this method (flowchart 66 of
The flow chart 68 in
According to the method of
The first host is then operated to read sectors of a native file system of the local storage device (step S1), as in step S1 of
Then, access criteria are established (step S2). Unlike in step S2 of the example embodiment of
The next step is creating a logical structure of sectors based on the access criteria of the second host (step S3). This step may be performed in the same way as step S3 of the example embodiment of
In a variation of the method shown in
In another variation of the method shown in
It is also possible to combine the embodiments illustrated in
Having thus described exemplary embodiments, it will be apparent that various alterations, modifications, and improvements will readily occur to those skilled in the art. Alternations, modifications, and improvements of the disclosed embodiments, though not expressly described above, are nonetheless intended and implied to be within the spirit and scope of the claims. Accordingly, the foregoing discussion is intended to be illustrative only; the invention is limited and defined only by the following claims and equivalents thereto.
This patent application is related to and incorporates by reference the patent applications entitled “A STORAGE DEVICE MANAGING PLAYABLE CONTENT” (Attorney Docket No. MSA-1277-US); “METHOD AND APPARATUS FOR PROVIDING ACCESS TO FILES BASED ON USER IDENTITY” (Attorney Docket No. MSA-1278-US); and “A STORAGE DEVICE PRESENTING TO HOSTS ONLY FILES COMPATIBLE WITH A DEFINED HOST CAPABILITY” (Attorney Docket No. MSA-1235-US) in that each share a common inventor (Yehuda Hahn) and were all filed on the same day.