Abstract:
A storage system having a storage device in communication with a host and including one or more function devices for communicating with application software modules, in accordance with an embodiment of the present invention. Said application software modules issuing vendor specific commands to access said function devices, said function devices remaining unknown to said host and recognizing said vendor specific commands for acting thereupon, wherein said storage device causing said application software modules to access said function devices to increase the security of said storage device.

Description:
REFERENCE TO PRIOR APPLICATION 
     This application claims the benefit of a previously filed U.S. Provisional Patent Application No. 60/564,125 filed on Apr. 20, 2004, and entitled “DIRECT SECONDARY DEVICE INTERFACE BY A HOST”. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates generally to the field of storage systems and particularly to a method and apparatus for providing direct interface between secondary function devices and application software modules included in the host of a storage system. 
     2. Description of the Prior Art 
     With the advent of nonvolatile or flash memory, consumer electronic devices have come to enjoy a wide variety of applications, such as a memory drive removably connectable to a Personal Computer (PC) or other such host devices. 
       FIG. 1  shows a prior art PC storage system  10  to include a host  12  coupled to a storage device  14 , which may or may not be removably connected to the host  12 . The device  14  is removably connectable to the host  12  through the interface  28 , which in one example, is a Universal Standard Bus (USB) connector. The host  12  is shown to include application software module  16  coupled to a controller driver module  18 . The controller device  20  is shown coupled to a sensor  22  and a flash memory unit  24 . The flash memory unit  24  includes flash or nonvolatile memory for storing various types of electronic information even when no power is provided to the system  10 . Example of the type of information stored in the unit  24  is based on the application of the system  10  and can be digital photographs, passwords, personal settings and the like. 
     The sensor  22  is shown connected to the device  20  through a connector  26 , which in one example is an Serial Peripheral Interface (SPI) interface. The sensor  22  is a fingerprint sensor for detecting a human fingerprint when the tip of a finger is swiped thereover. The sensor  22 , after noting a particular fingerprint, upon the completion of a finger swipe, causes storage of the fingerprint information in the flash memory unit  24  through the application software module  16 , again through the controller device  20 . In this manner, the sensor  22  is intended to add a level of security to the system  10  so that only the person whose fingerprint is recognized or matched to previously stored fingerprint information is given access to information stored in the flash memory unit  24 . 
     An example of the application software module  16  includes ‘Smartgenie’, which is a software program for operating fingerprint information, causing storage of passwords and directing encryption information and other security-related information. The driver module  18  allows the module  16  to communicate with the controller device  20  by converting high-level software language to a lower-level comprehendible to hardware such as the controller device  20 . Thus, the driver module  18  issues commands that are transmitted through the interface  28  to the controller device  20  that may or may not be followed by data through the same interface. As earlier stated, the host  12  may be a PC including an operating system, such as Windows by Microsoft, Inc. of Seattle, for directing system functions and mapping memory and recognizing entry points for various devices connected to the host  12 . 
     The problem with the system  10  is that the sensor  22  remains unknown to the operating system of the host  12  due to a lack of entry point into the sensor  22 . Stated differently, the operating system has no way of directly accessing the sensor  22 , as the standard driver module, or driver module  18 , does not have an actual entry point for the sensor  22 . The driver module  18  generally directs the controller device  20 , which, in turn, controls the flash memory unit  24  and the sensor  22 . 
     In the prior art system  10 , the application software module  16  communicates to the flash memory unit  24  because the controller device  20  is only allowed to communicate with the flash memory unit  24  and not the sensor  22 , in accordance with the USB standard, which dictates the communication occurring through the interface  28 . A need arises for the application software module  16  to communicate with the sensor  22 . 
       FIG. 2  shows the prior art system  10  of  FIG. 1  including some of the functions and devices depicted in  FIG. 1  in addition to others. For example, in  FIG. 2 , the host  12  is shown to include three driver modules, the controller driver module  18 , a sensor driver module  32  and a hub driver module  34 . The storage device  14  is shown to include a hub  30  in addition to the controller device  20  and the sensor  22 . 
     The driver module  32  communicates with the sensor  22  is shown coupled to the storage device  14  through the driver module  34  and the driver module  18  is also coupled to the storage device  14  through the driver module  34 . Particularly, the driver module  34  causes coupling of the driver modules  18  and  32  to the hub  30  of the storage device  14 . The hub  30  is shown coupled to the sensor  22  and to the controller device  20 .  FIG. 2  shows that the way in which the system  10  works in order for the operating system (Windows for example) of the host  12  to load the driver module  32  to allow the application software module  16  to communicate with the sensor  22 . There needs to be a system removing the driver module  34  and the hub  30  from the system  10 . Also, there needs to be a system such that the driver module  32  is moved into the application software module  16  so that other applications of the host  12  are unaware of the sensor  22  through standard discovery mechanisms (querying the host&#39;s operating system). 
     The driver module  18  is for causing communication to flash memory via the controller device  20 , whereas, the driver module  32  is for causing communication to the sensor  22 . At any given time, the hub  30  determines a communication path either with the controller device  20  or the sensor  22 , thus, the driver modules  32 ,  18  and  34  cannot directly and upon their wish communicate with the controller device  20  or sensor  22 . The problem with such prior art systems is that all of the devices, i.e. the sensor  22 , the flash memory and any other device connected in this manner (through the use of drivers within the host) are known to everyone and can thus be accessed, manipulated and/or deleted, which presents security issues. Additionally, the hub  30  and the driver modules  32  and  34  of  FIG. 2  add unnecessary real estate to the system  10  resulting in increased manufacturing costs associated therewith. Even if the hub  30  is implemented in another device so that it appears that the system real estate is less than having the individual presence of a hub, the security concerns still remain and there are, nevertheless, unnecessary manufacturing costs. 
     In the case of the desire to have a device be un-temperable by third parties, there is a need for secondary devices to be accessible only to a select and predetermined number of parties while unknown to others so as to preserve security and at the same time, decrease the number of electronic devices so as to decrease system manufacturing costs. 
     The need also arises to allow the system to operate with less current thus helping to use devices that qualify under low power devices in the USB specification (for example) and to preserve battery power in wireless devices that include their own power source. 
     SUMMARY OF THE INVENTION 
     Briefly, an embodiment of the present invention includes a storage system having a storage device in communication with a host and including one or more function devices for communicating with application software modules, said application software modules issuing vendor specific commands to access said function devices, said function devices remaining unknown to said host and recognizing said vendor specific commands for acting thereupon, wherein said storage device causing said application software modules to access said function devices to increase the security of said storage device. 
     The foregoing and other objects, features and advantages of the present invention will be apparent from the following detailed description of the preferred embodiments which make reference to several figures of the drawing. 
    
    
     
       IN THE DRAWINGS 
         FIG. 1  shows a prior art PC storage system  10 ; 
         FIG. 2  shows a the prior art system  10  of  FIG. 1  including some of the functions and devices depicted in  FIG. 1  in addition to others; 
         FIG. 3  shows a storage system  40  to include a host  42  coupled to a removable storage device  44  in accordance with an embodiment of the present invention; 
         FIG. 4  illustrates the storage system  40  including the driver module  48 , which causes communication between the host  42  and the controller device  50 , which, in turn, causes communication between the host  42  and the sensor  52 ; 
         FIG. 5  shows a storage system  80  in accordance with another embodiment of the present invention; 
         FIG. 6  shows a flow chart  100  as an example of the steps performed in  FIG. 5 ; and 
         FIG. 7  shows another alternative embodiment of the present invention to include a storage system  200  including the host  82  coupled to a storage device  202 . 
         FIG. 8  shows, in block diagram and conceptual form, an example of a vendor specific command, i.e. 0xC9 (in hexadecimal notation), and its flow through the system  80  of  FIG. 5  where the secondary function device  94  is a fingerprint sensor. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     Referring now to  FIG. 3 , a storage system  40  is shown to include a host  42  coupled to a storage device  44  in accordance with an embodiment of the present invention. The device  44  may be removably connectable to the host  42  through the interface  41 , which in one example, is a Universal Standard Bus (USB) connector although the interface  41  may be of any other kind. Alternatively, the device  44  is permanently connected to the host  42 . The host  42  is shown to include application software module  46  coupled to a driver module  48 . The controller device  50  is shown coupled to a sensor  52  and a flash memory unit  54 . The flash memory unit  54  includes flash or nonvolatile memory for storing various types of electronic information even when no power is provided to the system  40 . Example of the type of information stored in the unit  54  is based on the application of the system  40  and can be digital photographs, passwords, personal settings and the like. 
     The sensor  52  is shown connected to the device  50  through a connector  56 , which in one example is a Serial Peripheral Interface (SPI) interface but may be of any other kind of interface. The sensor  52  is a fingerprint sensor for detecting a human fingerprint when the tip of a finger is swiped thereover. The sensor  52 , after noting a particular fingerprint, upon the completion of a finger swipe, causes storage of the fingerprint information in the flash memory unit  54  through the application software module  46 , again through the controller device  50 . In this manner, the sensor  52  is intended to add a level of security to the system  40  so that only the person whose fingerprint is recognized or matched to previously stored fingerprint information is given access to information stored in the flash memory unit  54 . 
     An example of the application software module  46  includes ‘Smartgenie’, which is a software program for operating fingerprint information, causing storage of passwords and directing encryption information and other security-related information. The driver module  48  allows the module  46  to communicate with the controller device  50  by converting high-level software language to a lower-level comprehendible to hardware such as the controller device  50 . Thus, the driver module  48  issues commands that are transmitted through the interface  41  to the controller device  50  that may or may not be followed by data through the same interface. As earlier stated, the host  42  may be a PC including an operating system, such as Windows by Microsoft, Inc. of Seattle, for directing system functions and mapping memory and recognizing entry points for various devices connected to the host  42 . 
     In  FIG. 3 , the sensor  52  is shown to be transparantly coupled to the driver module  48  through an interface  49 , which goes through the controller device  50  and onto the interface  47  and the controller device  50  is shown coupled to the driver module  48  through the interface  47 . While the interface  41  is dictated by USB standard, other types of interfaces may be employed without departing from the scope and spirit of the present invention. It should be understood however, that during the use of a USB interface, the inventors of the present invention have found a way communicating with the sensor  52  even though the latter is obviously not a flash memory device and while such communication is formally not documented or allowed by the USB standard, as noted earlier. Briefly, the way in which this is performed is that vendor-specific commands are used to and incorporated into the driver module  48 , from the controller device  50 , that are recognized by the sensor  52  and that therefore allow the sensor  52  to act or react to commands issued through the driver module  48 . The way in which this is performed will be discussed, in greater detail, shortly. 
       FIG. 4  shows the storage system  40  including the driver module  48 , which causes communication between the host  42  and the controller device  50 , which, in turn, causes communication between the host  42  and the sensor  52 . In one embodiment of the present invention, the controller device  50  is physically located internally to the host  42  and in another embodiment of the present invention; it is physically located externally to the host  42 , as shown in  FIG. 4 . In one embodiment of the present invention, the sensor  52  is located physically externally to the controller device  50  and the host  42 , as shown in  FIG. 4  and in another embodiment of the present invention, the sensor  52  is physically connectably removable to and from the host  42  through the connector  56  although other types of connectors may be employed. The controller device  50  communicates to the driver  48  through the interface  41 , as described hereinabove. 
     It should be noted that the sensor  52  remains unknown to the host  42 , yet, the controller device  50  is known to the host  42 . The way in which this is done is by identifying an endpoint, known to the host  42 , for the controller device  50 , whereas, no endpoint is defined for the sensor  52 . That is, the controller device  50  is mapped in the memory map of the host  42 , whereas, the sensor is not mapped and thus remains invisible to the host  42 . 
       FIG. 5  shows a storage system  80  in accordance with another embodiment of the present invention. The system  80  is shown to include a host  82  coupled to a storage device  84 . The host  82  is shown to include an application software module  86  coupled to a driver module  88 . While one application software module  86  is shown in  FIG. 5 , many such application software modules may be employed without departing from the scope and spirit of the present invention. The number of software modules is independent to the number of additional functions or function devices. Two or more applications can use the same additional function devices. 
     The storage device  84  is shown to include a controller device  90  coupled to a flash unit  92 . The controller device  90  is also shown coupled to a secondary function device  94 , which is shown coupled to a third function device  96 , which is shown coupled to an n function device  98 . The third device  96  may be coupled to another function device, which may be coupled to yet another function device and the n function device  98  is intended to show the last function device in the chain of coupled function devices with ‘n’ being an integer number. 
     The application software module  86 , the driver module  88 , the host  82 , the controller device  90  and the flash unit  92  are that of similar modules and devices shown and discussed with respect to previous figures. The flash unit includes one or more flash or nonvolatile memory for storing information received from the controller device  90 . In an alternative embodiment, the flash unit  92  need not employ nonvolatile memory and rather includes volatile memory. 
     The controller device  90  is shown coupled to the secondary function device  94 , which may be one of many different types of devices according to the application of the system  80 . As examples, the secondary function device  94  may be another controller device, a Light Emission Diode (LED), a fingerprint sensor, a processor, a camera, an MP3 or MPEG4 decoder or encoder or other types of devices, as can the third function device  96  and the n function device  98 . In fact, the more function devices, the more functionality the system  80  is likely to include. 
     In one embodiment of the present invention, the host  82  is a personal computer (PC) and the driver module  88  is a USB mass storage driver and the controller device  90  is a USB controller and the application software module  86  is a ‘Smartgenie’ application software module with fingerprint matching and authentication programs. 
     In yet another embodiment of the present invention, the application software module  86  is a Windows moviemaker application software module and the controller device  90  is an Advanced Technology Attachment (ATA) controller known to those of ordinary skill in the art. 
     In still another application of the present invention, the driver module  88  is a wireless mass storage driver and the controller device is a wireless USB controller device. 
     In another embodiment of the present invention, the host  82  is embedded in an embedded system application. 
     In any of the foregoing applications or even other applications thought of or known to those of ordinary skill in the art, the configuration of the system, as noted above with respect to different applications may be mixed in a variety of ways without departing from the scope and spirit of the present invention. 
     In another embodiment of the present invention, the storage device  84  is physically a part of the host  82 . 
     In  FIG. 5 , the application software module  86  is shown coupled to the secondary function device  94 , the third function device  96  and the n function device  98 . 
     It should be noted that while the devices  94 - 98  exist in the system  80 , they remain unknown to the host  82  and to the driver module  88 , as only the application software module  86  and the controller device  90  are aware of the devices  94 - 98 . The application software module  86  accesses the secondary function device  94  though the controller device  90  using pass-through vendor specific commands, i.e. commands only known to the controller device  90  and the devices  94 - 98 . 
     Referring now to  FIG. 6 , a flow chart  100  is shown as an example of the steps performed in  FIG. 5  when a read operation takes place for reading information from the secondary device  94  when the application software module  86  is a ‘Smartgenie’ application. Thus, the steps outlined in flow chart  100  are merely an example and many other applications, commands and functionality can be employed without departing from the scope and spirit of the present invention. The steps of  FIG. 6  refer to structures shown in  FIG. 5 . 
     In  FIG. 6 , at step  102 , the storage device  84  is inserted into the host  82  through a USB port (not shown in  FIG. 5 ). It should be understood that the port connecting the host  82  to the device  84  need not be a USB port and can be any type of connection known to those of ordinary skill in the art. 
     It should be noted that when the term host is used herein and referred to as performing an operation or a task, it is actually the operating system installed in the host, such as a Windows operating system although other operating systems may be employed, is causing the performance of such operation or task. 
     Next, at step  104 , the program that is to be used as by the driver module  88  is transferred from the controller device  90  and loaded onto the host  82  and particularly within the driver module  88 . While in the example of  FIG. 6 , the system  80  of  FIG. 5  is to be employed as a fingerprint storage system where a fingerprint sensor serves as the secondary function device  94 , the host  82 , while recognizing the drive module  88 , will not recognize the fingerprint sensor, i.e. the secondary function device  94 . 
     When the storage device  84  is inserted into the host  82 , the host  82  basically performs an accounting of what may be trying to communicate with it and it recognizes only the controller device  90  and not the devices  94 - 98 . Accordingly, the host  82  creates what is referred to in the industry as an ‘instance’ of the device driver for the controller device  90 . 
     It should be noted that in prior art systems, when an application software, such as ‘Smartgenie’ is used, a manufacturer provides a driver module that is loaded into the host  82  for communicating to the sensor or a secondary function module  94 . However, in the method and apparatus of the present invention, no such driver exists and the secondary function module or sensor is actually unknown to the host  82  and thus, must be communicated thereto through the controller device  90  by the use of vendor specific commands. In fact, the driver module  88  does not know of the communication with the secondary function module  94  either. 
     Next, at step  106 , the application software is executed from the application software module  86 . In this example, the application software is ‘Smartgenie’. As noted earlier, the ‘Smartgenie’ application software causes performance of such tasks as saving of passwords, using fingerprint as password, encrypting and decrypting files and other tasks. 
     Next, at step  108 , the application software module  86 , i.e. ‘Smartgenie’, transmits a vendor specific command, through the driver module  88 , to the controller device  90  requesting fingerprint data. The transmitted vendor specific command includes an embedded command intended for the fingerprint sensor, i.e. the secondary function device  94 . Optionally, the controller device  90  can restrict access to the flash unit  92  to allow standard read/write commands to be issued through the driver module  88 . 
     Next, at step  110 , the controller device  90 , upon receipt of the vendor specific command, strips the data intended for the secondary function device  94  from the vendor specific command and sends the stripped data to the secondary function device  94 , i.e. the fingerprint sensor, through an SPI interface. Upon receiving the stripped data from the controller device  90 , the fingerprint sensor is activated at step  112 . 
     Next, at step  114 , the application software module  86 , i.e. the Smartgenie application software, sends a read command to the controller device  90 , through the driver module  88 , to read the fingerprint sensor. In the read command, some parameters may be specified, such as the size of the data to be returned. For example, there may be a request to have the sensor send back two kilobytes of data and upon receiving the command, the sensor waits until it has two kilobytes of data before sending it to the controller device. The application software module  86  may ask for additional data and continue to do so until it is satisfied. That is, the controller device  90  has no way of knowing how much data to return back to the application software module  86  while such information is obviously known to the application. 
     Next, at step  116 , in response to the read command of step  114 , the sensor transmits information gathered from a fingerprint mechanism which sweeps a user&#39;s finger to the controller device  90  and the device  90 , in turn, transmits the same to the application software module  86  through the driver module  88 . The data includes fingerprint information of the user&#39;s fingerprint, which is clearly unique to the user and can basically be used as a password by the user to access and/or store information. 
     Next, at  118 , a determination is made as to whether or not all of the data of step  116 , i.e. the fingerprint data, has been sent to the application software module  86  and if not, the process continues to step  116  and continues to do so until all of the fingerprint data is sent to the application software module  86 . If, at  118 , it is determined that all of the data has been sent to the application software module  86 , the process continues to step  120 . 
     At step  120 , the application software module  86  or the ‘Smartgenie’ software causes transmission of another vendor unique command to the controller device  90  informing the latter that the sensor is no longer needed. Optionally, if access to the flash unit  92  is restricted in step  108 , it needs to be unrestricted at this step to allow read/write commands to work as intended through the driver module  88 . 
     Next, at step  122 , the sensor is inactivated, as it is no longer necessary to read any further fingerprint data. 
     In the example of  FIG. 6 , all communication originates from the host  82  and particularly the application software module  86 . Also, while only a vendor specific read command is discussed relative to  FIG. 6 , data may be saved to the secondary function device  94  though the use of a vendor specific write command issued by the application software module  86  to the controller device  90  through the driver module  88 . Optionally, during read and/or write commands, access to the flash unit  92  may be prohibited either by the host  82  or the controller device  90 . While not discussed in the example of  FIG. 6 , in another embodiment of the present invention, the secondary function device  94  may be a master to the third function device  96  and is connected to the controller device  90  through a Universal Asynchronous Read Transmit (UART)/SPI interface or other serial or parallel interfaces. 
     As stated earlier, the secondary and third and so on function devices  94 - 98  may be any combination of devices, such as one or more controller devices or processors or sensors or cameras and any other digital device. 
     By way of example, the following is source code showing how an application software module sends commands to a secondary function device, through the controller device. Particularly, this is an example of how the application software module  86  would communicate with a sensor (or secondary function device  94 ) through the controller device  90  using the driver module  88 . 
     
       
         
               
             
               
               
             
               
             
           
               
                   
               
             
             
               
                   #include &lt;ntddscsi.h&gt; // this header file is used for definitions of SCSI functions 
               
               
                 and structures 
               
               
                                     // this header file is provided with the 
               
               
                 Microsoft device driver kit for 
               
               
                                     // Visual Studio 6.0 
               
               
                                     // specifically used in this example: 
               
               
                                     // 
               
               
                 SCSI_PASS_THROUGH_WITH_BUFFERS -- structure used to setup CDB 
               
               
                                      // SCSI_PASS_THROUGH -- 
               
               
                 structure used for size definitions 
               
               
                                     // DeviceIoControl -- function to 
               
               
                 send scsi structure to the flash controller 
               
               
                   /* 
               
               
                    *  int main(int argc, char **argv) 
               
               
                    * 
               
               
                    *  Description: 
               
               
                    *    This is the main function. The entry point for program execution. 
               
               
                    * 
               
               
                    *  Inputs: 
               
               
                    *    argc - the number of command line arguments. 
               
               
                    * 
               
               
                    */ 
               
               
                   int main(int argc, char **argv) 
               
               
                   { 
               
               
                     HANDLE controllerHandle = NULL; 
               
               
                   // a file handle for talking to the USB controller 
               
               
                     SCSI_PASS_THROUGH_WITH_BUFFERS sptwb; 
               
               
                   // a data structure that contains all the information I intend to send to the 
               
               
                 controller 
               
               
                     char deviceString[25] = “\\\\.\\PhysicalDrive0”;   // example address to 
               
               
                 the USB controller 
               
               
                     unsigned long returned = 0; 
               
               
                   // value that is returned from the controller on status of the operation 
               
               
                     // open a control pipe to the flash controller through the mass storage 
               
               
                 driver. 
               
               
                     controllerHandle = CreateFile(deviceString,   // name of the 
               
               
                 “file” to open 
               
               
                       GENERIC_WRITE|GENERIC_READ, 
               
               
                     // access granted 
               
               
                       FILE_SHARE_READ | FILE_SHARE_WRITE, 
               
               
                   // share mode 
               
               
                       NULL, 
               
               
                     // security parameters - default is NULL 
               
               
                       OPEN_EXISTING, 
               
               
                     // do not create this, only open if the device is there 
               
               
                       0, 
               
               
                       // file attributes 
               
               
                       NULL); 
               
               
                       // a handle to another file with atributes I want to use 
               
               
                     // setup the standard part of the SCSI header and CDB 
               
               
                     ZeroMemory(&amp;sptwb, 
               
               
                 sizeof(SCSI_PASS_THROUGH_WITH_BUFFERS)); 
               
               
                     sptwb.spt.Length = sizeof(SCSI_PASS_THROUGH); 
               
               
                     sptwb.spt.PathId = 0; 
               
               
                     sptwb.spt.TargetId = 1; 
               
               
                     sptwb.spt.Lin = 0; 
               
               
                     sptwb.spt.CbdLength = CD10GENERIC_LENGTH; 
               
               
                     sptwb.spt.SenseInfoLength = 24; 
               
               
                     sptwb.spt.DataIn = SCSI_IOCTL_DATA_IN; 
               
               
                     sptwb.spt.DataTransferLength = INQUIRYDATALEN; //512; 
               
               
                   sptwb.spt.TimeOutValue = 2; 
               
               
                     sptwb.spt.DataBufferOffset 
               
               
                 =offsetof(SCSI_PASS_THROUGH_WITH_BUFFERS,ucDataBuf); 
               
               
                     sptwb.spt.DataBufferOffset = (ULONG)( 
               
               
                 offsetof(SCSI_PASS_THROUGH_WITH_BUFFERS,ucDataBuf) ) ; 
               
               
                     sptwb.spt.SenseInfoOffset = 
               
               
                 offsetof(SCSI_PASS_THROUGH_WITH_BUFFERS,ucSenseBuf); 
               
               
                     // setup the 16 byte CDB with the vendor specific command 
               
               
                     // this example could be to tell the bio-metric sensor to starting reading 
               
               
                 data from the sensor and 
               
               
                     // buffer it for the application to read later for matching purposes. 
               
               
                     // the values are created artifically and do not exist in any documentation - 
               
               
                 used purely for explaination purposes. 
               
             
          
           
               
                     sptwb.spt.Cdb[0] = 0x00c9; 
                 // this tells the controller that the command 
               
               
                 is pass through to the bio sensor 
               
               
                     sptwb.spt.Cdb[1] = 0x0033; 
                 // vendor specific command saying that I am 
               
               
                 writing a register 
               
               
                     sptwb.spt.Cdb[2] = 0x0000; 
                 // vendor specific null character 
               
               
                     sptwb.spt.Cdb[3] = 0x0001; 
                 // vendor specific register identifier 
               
               
                     sptwb.spt.Cdb[4] = 0x006e; 
                 // vendor specific value for the register 
               
               
                     sptwb.spt.Cdb[5] = 0x0000; 
                 // the rest are left 0&#39;s as they are unneeded by 
               
             
          
           
               
                 the vendor 
               
               
                     sptwb.spt.Cdb[6] = 0x0000; 
               
               
                     sptwb.spt.Cdb[7] = 0x0000; 
               
               
                     sptwb.spt.Cdb[8] = 0x0000; 
               
               
                     sptwb.spt.Cdb[9] = 0x0000; 
               
               
                     sptwb.spt.Cdb[10] = 0x0000; 
               
               
                     sptwb.spt.Cdb[11] = 0x0000; 
               
               
                     sptwb.spt.Cdb[12] = 0x0000; 
               
               
                     sptwb.spt.Cdb[13] = 0x0000; 
               
               
                     sptwb.spt.Cdb[14] = 0x0000; 
               
               
                     sptwb.spt.Cdb[15] = 0x0000; 
               
               
                     // this function call is used to send the SCSI CDB to the flash controller 
               
               
                 through the USB mass 
               
               
                     // storage driver. 
               
               
                     DeviceIoControl(controllerHandle, 
               
               
                       IOCTL_SCSI_PASS_THROUGH, 
               
               
                       &amp;sptwb, 
               
               
                       sizeof(SCSI_PASS_THROUGH), 
               
               
                       &amp;sptwb, 
               
               
                       length, 
               
               
                       &amp;returned, 
               
               
                       FALSE); 
               
               
                     /* 
               
               
                      *  now that I have told the sensor to get data, I need to read the data 
               
               
                 from the sensor 
               
               
                      *  the process is very similar to the above and is not repeated to keep 
               
               
                 the example brief. 
               
               
                      * 
               
               
                      */ 
               
               
                     CloseHandle(fileHandle); 
               
               
                     return 0; 
               
               
                   } 
               
               
                   
               
             
          
         
       
     
     In  FIG. 7 , another alternative embodiment is shown to include a storage system  200  including the host  82  coupled to a storage device  202 . The storage system  200  of  FIG. 7  is similar to that of the system  80  of  FIG. 5  except that the controller device  90  is coupled to a plurality of secondary function devices in parallel. In  FIG. 7 , the host  82  is shown to include the application software module  86  coupled to the driver module  88 , which causes communication to the controller device  90  of the storage device  202 . The structures, connection and coupling of the system  200  of  FIG. 7  is similar to that of system  80  in  FIG. 5  and thus, will not be discussed as to those similar structures, connection and coupling to avoid redundancy. 
     Unlike  FIG. 5 , the controller device  90  of  FIG. 7  is shown coupled to a plurality of secondary function devices  94 ,  204  and  208 . It should be noted that any number of secondary function devices may be coupled, in parallel, to the controller device  90 . An example of an application of such a system is to have the secondary function device  94  be a sensor while the secondary function device  204  is an LED. The sensor as well as the LED are controlled by the application software module  86  rather than the controller device  90 , as done by the prior art. 
     One of the advantages of the present invention is that the secondary, third and so on function devices, such as  94 - 98  of  FIGS. 5 and 94 ,  204  and  208  of  FIG. 7 , remain unknown to the operating system of the host and thus are not accessed or used in any way by third parties, which greatly increases the security of the latter devices. Thus, if a fingerprint sensor is used as a secondary function device, its information will never be known, accessed or manipulated by others. This is accomplished, as stated above, by the use of vendor specific commands, which remain unknown to third parties. 
     Yet another advantage of the present invention is avoiding driver certification (WHQL, for example—by Microsoft) by the manufacturer of the operating system used by the host. That is, when a device, such as a sensor is to be added to a PC, the manufacturer of the operating system, such as Microsoft, Inc., will have to certify the device by adding a device driver to the next version of the operating system it releases, which is a painstaking and perhaps prolonged process to both Microsoft and particularly to those in need of the device. The present invention avoids such a certification by modifying the application software of the application software module to cause communication with the device or sensor through the use of vendor unique commands facilitated by the controller device. There is no additional software to certify. 
     The present invention allows for a driver module, the driver module  88  of  FIG. 5 , to communicate to a standard device, i.e. the controller device  90  of  FIG. 5 , but actually controlling a third or more devices, i.e. the secondary function device  94  of  FIGS. 5 and 7 , by embedding commands directed to the third or more devices. A practical example is if in  FIG. 5 , the secondary function device  94  is a Liquid Crystal Display (LCD) monitor and the driver module  88  controls a keyboard. Accordingly, the application software module  86  sends an image to the keyboard and by doing so, the controller device  90  would know to send the image to the monitor for display. 
     As stated earlier, the device  84  of  FIG. 5  may be physically located with the host  82 , i.e. an embedded system. 
     The storage systems of the present invention, as presented in the foregoing figures, operate with less current than that of prior art systems, thus, helping to use devices that qualify under low power devices in the USB specification (for example) and to preserve battery power in wireless devices that include their own power source. 
     The storage systems shown in  FIGS. 3 ,  5  and  7 , include a processor (not shown), or computer medium, some type of storage area and a computer readable medium, for storing the software/firmware described in  FIGS. 3 ,  5  and  7 . The processor executes codes from the computer readable medium for effectuating the functions outlined in  FIGS. 3 ,  5  and  7 . 
       FIG. 8  shows, in block diagram and conceptual form, an example of a vendor unique command, i.e. 0xC9 (in hexadecimal notation), and its flow through the system  80  of  FIG. 5  where the secondary function device  94  is a fingerprint sensor. 
     Particularly, the controller device  90  receives the command, in hexadecimal code notation, 0xC9 from the application module  86  and then passes it on to the secondary function device or sensor  94 . The command is followed by bytes needed for the registers of the sensor (not shown). The controller device  90  then passes these bytes onto the sensor. 
     It should be noted that in the example of  FIG. 8 , there is no data involved with the command. The controller device  90  sends a status to the host regarding whether or not the command is successful, in which case a status of ‘good’ is returned to the host, otherwise, a status of ‘check condition’ is sent to the host. 
     Although the present invention has been described in terms of specific embodiment, it is anticipated that alterations and modifications thereof will no doubt become apparent to those more skilled in the art. It is therefore intended that the following claims be interpreted as covering all such alterations and modification as fall within the true spirit and scope of the invention.