The present invention relates generally to portable mass storage devices such as the memory cards and portable universal serial bus (“USB”) flash memory drives used to store and transfer large files to and from digital devices, and more specifically to security and access control mechanisms implemented within the devices to access the devices and also other institutions.
Remembering passwords is a hassle. The computer at the office requires a user name and password. Each email account requires a user name and password, as does each online account. If security were not an issue, a person would likely have only one username and password for all accounts.
However, security is a serious issue, and therefore password management and access to accounts is also a serious issue. A number of current approaches address this serious issue in an attempt to either make passwords easier to remember or more robust and resistant to being compromised.
One approach is the one time password (“OTP”). A one time password is, generally speaking, a value that can be used to access a system once before it is changed. In other words, it is regularly updated (at a certain defined frequency) without the user having to change it. This means that the user submits a unique (password) value that is used only once and the system that he wishes to access verifies that the value is what it should be. Typically this is accomplished with a small device or “token” that generates the password for the user based upon a predictable algorithm. The same predictable algorithm is utilized by a validating entity in the system, and when the algorithms are given the same seed value, the system therefore “knows” what the user's ever changing one time password value should be at any instant (or count). The most common form of the tokens to date requires that the user read the value from a screen and enter it into a computer. Another recently developed form allows the token to transmit the value directly to the computer. Both of these implementations, and the one time password concept generally, provide a high level of security, but require that the user carry around a token for generation of the one time password values. The tokens are a form of two factor authentication, the user's secret (password or pin) being one factor, and the OTP value and the hardware (token) necessary to produce it being the second factor.
Another approach utilizes a password management device. Such a device can keep track of a user's various passwords and account numbers and submit the proper password(s) for each user account. For example, the user may have a master password for accessing the device, and after the device has verified the user's master password, it can then submit the actual password for a given account when it is connected to a host computer. The user can either enter his various passwords or passwords can be pushed to the password management device. One such device from SafeNet® (formerly thought to be Rainbow Technologies) is known as the iKey™ and is also capable of encryption and the associated key generation.
Each of these approaches lacks something and has therefore not achieved a high level of acceptance with the general public. OTP tokens are primarily used today for controlling access to corporate networks and have not been widely accepted for use with systems widely available to the general public, e.g. email providers or on-line auctioneers etc. Currently available password management devices lack the level of security of OTP tokens and systems.
Each of these approaches requires usage of a dedicated device, or alternatively lacks the ability to generate one time passwords for different institutions while keeping the passwords and associated algorithms and seeds secure. For example, many involve a single purpose keychain token or USB device. Carrying such a device everywhere is an inconvenience and limits user acceptance, especially given that the tech savvy user may already be toting around a cell phone, music player, PDA or Blackberry, digital camera, and other assorted electronic gadgets.
Therefore, there is a need for a convenient multi-purpose device that integrates one time password generation as part of a robust security and password management system.
The present invention integrates robust security and the convenience of password management into a portable mass storage device. Since a user typically already has a portable mass storage device for use with his digital camera, music player, PDA, or the like, the added security and convenience impose little burden on the user. This facilitates greater penetration of very secure one time password schemes, and results in significantly less risk for sensitive applications such as on-line banking. Because a secure portable mass storage device can store programs and other secure data, OTP generation and password management can be integrated into one convenient platform.
One of the barriers to adoption of such two-factor authentication systems in the consumer space is the need for a user to carry a token specifically for the purpose of performing the authentication operation. One way to eliminate this burden of having to carry multiple dedicated devices is to integrate such functionality into a device that a person may possess and/or carry with them for other reasons. An example of such a mass storage device is a USB flash storage device or a mass storage flash memory card such as a compact flash “CF” card, SD card, MMC card, XD card, Memory Stick, TransFlash card, or the like, which is commonly used to store data, and more recently to store and carry applications. Such a device, according to the present invention, performs the basic OTP functionality and carries a client application that could be launched from the mass storage device and executed on the host computer. The client application is responsible for interacting with the device to perform the OTP operation, and to get the OTP value from the device. In another embodiment, the client itself performs the OTP functionality and stores and retrieves information such as the count to and from the device as needed. In either case, the information would be stored in a secure manner, and protected appropriately by some means such as encryption.
In one embodiment, a single mass storage device may be used to authenticate to a number of independent institutions by maintaining a number of independent seed and count pairs on the device, each one to authenticate independently to a given institution. The authentication with multiple institutions may alternately be achieved with a single seed and count by employing a central location of verifying the authentication information. In either case, the seed or seeds may be loaded into the device or to the client securely either during manufacture of the device, or remotely, preferentially through a secure channel. Secure channels are well known in the art and generally involve a communication protocol whereby communication between two entities is encrypted with a key known only to those two entities. Generally the key is a type of session key that is established with a predefined key exchange protocol between the two entities.
One of the concerns surrounding authentication systems for consumer use is the ease of use and simplicity of the system. Typically, security adds a level of complexity that is a barrier to adoption. One goal in the design of such systems is to achieve a level of simplicity that makes the security aspects of the user interaction almost transparent to the user. To this end, in the present invention, the security is handled in the background as a part of the normal user activities.
This invention involves the integration of the OTP functionality directly into the user log on operation such that the user preferably has no involvement in performing the OTP authentication after some initial enrollment and/or activation. In particular, in the preferred embodiments, the OTP functionality is integrated into a USB flash storage device or other common removable storage device, and a client application is also stored on the device itself. The client application is launched from the storage device and executes on the host computer. The application may be launched either manually by the user or the system may be set up to automatically launch the application upon insertion of the device into a host computer. Once launched, the client application performs the tasks of obtaining an OTP value from the mass storage device, and providing the user identity, credentials, and OTP value to the server to which the user is authenticating. Ideally, this is performed either automatically if the client application is dedicated to operate with a single institution, or with a one-click operation using a human interface device such as a mouse or a keyboard to select either an institution icon (corporate logo) or name from a list.
In another embodiment, the client may be active on the host computer and detect when the user accesses a web page within the list of enrolled institutions in order to activate the log on sequence. The Institution list may be displayed on a graphical user interface (“GUI”) as a list, a drop-down list, a group of icons, a group of corporate logos, or other such representations. The user identity and credentials, and the institution Uniform Resource Locator (“URL”) or other form of web address are also ideally already stored on the removable storage authentication mass storage device, and are retrieved for the authentication. If the device supports a number of independent OTP seeds, or even if it supports a number of independent institutions using the same OTP seeds, then the user identity, credentials, and URL are ideally selected from a list stored on the device according to the particular institution to which the person is authenticating. This system combines the functions of a traditional password manager and an OTP authentication system seamlessly, and performs the log on and authentication operation all with a single click of a button. Although performing all these actions with a single click is preferable in some scenarios, multiple clicks or other user input may be utilized and preferable in other scenarios.
To ensure that no other person can use the device to authenticate in case of loss or theft, the mass storage device of the present invention is such that it will not work without the user inputting some information that uniquely identifies the person, such as a PIN or password, at least once upon launch of the client application. There are a number of other methods of user identification, such as biometrics, answering questions, etc. In one embodiment, the system may be employed to provide user information for more general two-factor authentication and/or password management operations, some of which information may be more sensitive than other information. The system may be designed to segregate such sensitive information and request user verification, additional entry of a PIN/password, or other action to ensure the user is aware of and authorizes such information to be provided by the system. One example of this may be for credit card authorization and payment.
In one embodiment, the client may provide the user and authentication information to a web server that will upon receiving valid user credentials and authentication information, will automatically fill out the traditional log-in web page entries that are normally used to log on without the two-factor authentication. This embodiment would enable a given institution to maintain a single web log-on page, while adding a separate system component to handle the two factor authentication. In this case, the two-factor authentication may consist of forms of authentication that do not easily lend themselves to form-filling, as OTP does, but instead may be authentication schemes, such as the public key infrastructure (“PKI”), which typically involve challenge-responses operations.
As an enhancement to the system, the device may contain a list of institutions to which the user may enroll for authentication. This list may be updated remotely, either by user request, or automatically, by means of the client application. The list may be organized in such a way as to provide preferential placement for paying institutions, or placement on the list itself may be reserved for only paying institutions. The system may also fill in the user's credentials for him when it detects that a particular web page, for which it has stored credentials, has been opened. This can be done with a program or routine that monitors the port used to communicate with the Internet or WWW. The program monitors the browser installed on the host, and configures the browsers to carry out all data communications with the Internet/WWW through a specific port that it monitors. Monitoring would automatically take place any time the host device is utilized, and would maintain a file of all web sites being visited. If a visited web site is one for which the system maintains the users credentials, it will then log the user on.
One common method of hacking, commonly referred to as ‘phishing’, is one in which a user is tricked into providing confidential information to a web site disguised as a valid web site. There are a number of ways to counter this form of hacking. The list of participating institutions may be used as a means to provide additional information to the system, such as the valid URLs pertaining to a given institution, the form of authentication or specific protocols employed for authentication, and so on. In one embodiment, the URL embedded in the list of participating institutions may be used to limit the URLs to which a user may enroll with the system. In such an implementation, the list would be preferentially downloaded to the device from a remote server via a secure channel to avoid snooping by third parties. In another implementation, the client may request validation of a URL by establishing a link to a remote server and, preferentially through a secure channel, requesting validation of the URL. The remote server may in one embodiment be an authority server or validation entity such as those seen in
All of the above systems include a simple mechanism for transferring the authentication rights from one device to another, as well as the user information and credentials from one device to another. The transferal of authentication rights, which may in one embodiment consist of a device ID and seed, and in others a certificate, key, or other form of information, may be performed by adding the information to a list of inactive devices on the server, a removal of said information from the device via a secure protocol, and a re-provisioning via a secure protocol to a new device upon successful identification of the user, and removal from the list of inactive devices. A similar method may be employed in case of loss of the device by the user, which would entail invalidation of the old device ID and seed at the server, and re-provisioning of the same or new device ID and seed to a new device.
Portable mass storage devices are widely used to store digital content such as photographs, music, videos, and documents. They are also sufficiently large to store large software applications. Typically, the portable mass storage devices now use flash memory for storage purposes, and have a form factor of a memory card or portable USB drive. These mass storage devices are distinct from other portable devices that are intended to store very little information such as that required for transaction or identification purposes. Mass storage devices are also distinct from other dedicated purpose devices such as key cards and the tokens used for authentication, because while the dedicated devices may have small amounts of memory to store pertinent user identification information, they are not designed to frequently store and transfer what are comparatively massive and often encrypted files in a rapid, reliable, and repeatable manner.
For example, a memory card, one embodiment of a portable mass storage device, must be capable of rapidly storing pictures on the order of 5-20 megabytes or more. One single picture from a digital camera may require orders of magnitude more storage than is present in a dedicated purpose device such as a smart card, key card, or token. Furthermore, such a dedicated purpose device is generally not capable of quickly reading and writing files, let alone the relatively large files used with cameras and music players etc. Portable mass storage devices have controllers and firmware with routines that are optimized to read and write to the memory banks very quickly. Furthermore, many of the portable mass storage devices have security and encryption routines to thwart unauthorized copying of the frequently updated content. While dedicated tokens may have some form of security (to protect the seed and/or algorithm), the data on the token is generally static and the security is not designed to protect against unauthorized copying of frequently updated user files. The mass storage device of the present invention may also store the seeds and other information needed for validation and authentication in an area of the mass storage memory that is not subject to logical to physical mapping, in order for the information to be more reliably and quickly retrieved. For more information on this, please refer to application Ser. No. 11/317,341, filed Dec. 22, 2005, entitled “Methods Used in a Secure Yet Flexible System Architecture for Secure Devices With Flash Mass Storage Memory” to M. Holtzman et al., application Ser. No. 11/317,339, filed Dec. 22, 2005, entitled “Secure Yet Flexible System Architecture for Secure Devices With Flash Mass Storage Memory” to M. Holtzman et al., which are hereby incorporated by this reference in their entireties. The seeds may also be loaded into hidden partitions of the device. Loading of the seeds, wherever they are stored, may also only be possible if the entity wishing to load the seeds has adequate permission and/or credentials to do so. In certain embodiments, this permission is contained in an access control record, which will be discussed later.
The present invention utilizes a portable mass storage device for security purposes. The device has security features built into the device that i) limit access to information stored on the device, and ii) make the device function as a type of “key” that allows access to other secure systems and data. The present invention also includes a system that uses a portable mass storage device to verify the credentials of a user. Once verified the user will be allowed access to information he would otherwise not be able to access.
Typically static passwords have been used to verify the credentials of a user. However, a static password is easy to pilfer and affords little protection, especially given the widespread “phishing” for passwords and other personal information today. As discussed previously in the Background, dedicated OTP token systems have also been implemented. These dedicated tokens are a burden to carry, are costly, and have not been widely accepted in the marketplace. These tokens also do not have the mass storage functionality of a memory card or USB drive.
Today, almost everybody who has a digital camera, video recorder, PDA, portable music player, or personal computer has a memory card or a pocket sized USB drive, sometimes referred to as a “thumb” drive. The present invention removes the barrier to entry of requiring a separate dedicated token (or other dedicated device) for implementing an OTP. If a user need not carry multiple devices, but can instead utilize something he already has, the acceptance and usage of OTP and two factor authentication should grow substantially. This results in better security measures and less risk of fraud in electronic commerce and other areas.
Embodiments of this invention comprise a portable storage device such as a USB flash storage device with OTP functionality and a client in the device that upon selection by the user will automatically link to the appropriate institution web page, enter user credentials, perform the OTP transaction with the device, and enter the OTP value to the web page, thus seamlessly performing the entire operation with a single user click.
Increased security measures are of the utmost importance because identify theft and fraud are becoming ever greater threats to the growth of online financial activity. Banks, brokerages, and other financial institutions are seeking solutions that will enable them to drive more activity online, where the costs can be as little as 0.5% per transaction as compared to the same transaction performed in a branch office. Likewise there are other programs that are being developed around online merchant transaction, safe browsing for children, and so on. The fundamental need of each of these is a means to provide stronger authentication of the individual that overcomes the most common forms of identify theft, which are phishing and hacking to obtain user identity and credentials, and physical theft or copying of credit card information.
One solution to the problem, and one aspect of the present invention is to provide consumers with a means, or system, of performing two-factor authentication in order to log on or perform transactions online. Two-factor authentication, as implied by the name, requires that a person be in possession of two system components, one of which is typically a physical device uniquely identifying the person, and the other is a piece of information (a secret) that is known only to that person and the entity to which the person would like to authenticate.
The authenticating or validating entity will typically have a database containing the person's credentials as well as a means of verifying that the person is in possession of both components of the two-factor authentication system. The person is only authenticated if able to prove possession of both components, and so the most common form of fraud, in which a hacker is able to determine the person's identity and secret, is thwarted, because the hacker, who typically is never physically near the person, will not have possession of the physical component. Likewise, if the person happens to lose the device, or it is stolen, no one can use the physical component to falsely authenticate without knowledge of the secret.
The present invention includes cryptographic functionality. In a preferred embodiment it includes a hardware-based cryptographic engine, although the cryptographic functionality can alternatively be primarily firmware based. It is advantageous to include some form of cryptography to increase the effort that would be required to hack the system. An advantage of using a hardware based cryptographic engine is that the firmware can be tied to the cryptographic engine in such a way that the firmware won't be executed unless singed by the hardware. This means that both the authentic firmware and hardware need to be present for the device to work. One or the other cannot be replaced with pieces designed to compromise the security of the device and allow unauthorized copying of the contents. For more information please refer to U.S. patent application Ser. No. 11/285,600, filed Nov. 21, 2005, entitled “Hardware Driver Integrity Check of Memory Card Controller Firmware” to Holtzman et al, which is hereby incorporated by this reference in its entirety.
A PC or cell phone has an open architecture which is vulnerable to all forms of hacking. An advantage of the present invention is that by placing the cryptographic capabilities within the mass storage device, a very secure and limited API can be utilized as compared to what would be present on a typical personal computer (“PC”) or electronic device such as a cellular telephone. The secure API of the mass storage device is such that there is no way for hackers to use a normal logical interface to attempt to discern the cryptographic secrets contained within the mass storage device. In essence the mass storage device of the present invention is made to be much more secure than the host to which it is coupled.
The secure mass storage device works in tandem with a remotely located server or servers, using the host device essentially as a pass-through. Although in certain embodiments the processor of the host device executes a client that is stored on the mass storage device, in the preferred embodiments the cryptographic and OTP operations are contained exclusively in the mass storage device, which can be constructed, both physically and logically, in a much more protected manner. The secure mass storage device works in conjunction with a remotely located secure entity or entities to form a secure system. Connections between the mass storage device and the secure entities are also secure. The remotely located secure entity is or comprises one or more remote servers, which are typically physically protected from access, and have secure countermeasures that limit the types of interactions that can be performed though the external interface.
Reference will now be made to the figures.
Host computing device 110 can be any type of smart electronic device, and will for convenience be simply referred to as the host. Some examples of host 110 would include a personal computer, cellular telephone, or handheld organizer/email device (“PDA”). In fact, the host can be any electronic device that can be used to access a user's accounts and/or sites of interest. Host 110 is connected to a network that is in turn connected with various institutions 118 and other entities. Only one institution 118 is shown for simplicity. The network may comprise any type of wide area network such as the Internet, and various types of cellular telephone networks. Certain networks may also utilize satellite communications. One type of entity connected to the network is a validating or authenticating entity 124. Entity 124 comprises one or more servers. In the case where host 110 is a PC, a virtual private network (“VPN”) connection may be established if desired. In addition to network connection 114 that connects the host to the institution 118, and network connection 116, that connects the host to the validating entity 124, there may also exist a separate, non-network connection 122 between institution 118 and validating entity 124. Certainly institutions 118 can also communicate with entities 124 over the network as well.
Host 110 and the components that interact with it will now be described with reference to their currently preferred embodiments, but such a description should in no way limit the scope of the invention, which will be defined by the appended claims. In a preferred embodiment, host 110 is a PC and MSD 100 is a USB thumb drive. As mentioned previously, the host computer may also be a handheld computer, commonly referred to as a PDA, or a cellular phone, or digital camera, or a hybrid device having all of these functions, which may accept a removable storage device. In one embodiment, the storage device or subsystem may be embedded in the host computer. When a user wishes to access a particular institution, say his online bank for example, he plugs MSD 100 into a USB port, a client that resides on MSD is launched by the PC, and the client then signs the user into his bank account or accounts. The validating entity 124 works in conjunction with the institution, the client, the PC, and the MSD, to validate/authorize the user and his MSD before the user will be allowed access to the institution and logged on or signed into the institution. Of course, each institution 118 maintains various databases of its users and their account numbers and secrets (e.g. passwords or PIN numbers). Likewise, the validating entities maintain databases needed to validate/authorize the users and their devices. These processes will be discussed in greater detail later. Also, the client application that resides on MSD 100 can be executed by a processor of host 110 or MSD 100, and this will depend on the level of security required and the configurations of both host 110 and MSD 100, as well as the connection 102 between them. In the case where host 110 is a PC, at the moment it is currently preferred that the PC execute the client application.
As seen in
Logical slots 310A, 310B . . . 310x. are located in the secure area 308A. These slots can also be in the file storage area 308B. A slot is a protected logical memory area that is used to store the information necessary to log a user into an institution. The information is encrypted as one security measure. This can include the user's identifying information such as his name address account number etc . . . , the user's secret such as a password or PIN, and the information necessary to generate OTP values, including the algorithms and seed values for each institution. Each institution will have its own slot. In certain embodiments, each account within an institution may have its own slot. Login and the use of slots will be explained in more detail later. In an embodiment of the invention, the slots of the MSD may be located in a system area of the mass storage memory that is not subject to logical to physical mapping, in order for the information to be more reliably and quickly retrieved. The seeds used for OTP generation may also be stored in an area of memory 308 that is hidden from a computer that has access to the files in file storage area 308B. This may be done within a hidden partition located anywhere in memory 308.
As mentioned previously, seeds can be loaded into MSD 100 at different times. It is important that an entity wishing to load seeds into the card be verified before loading takes place. In one embodiment, this is managed with a secure storage application (“SSA”), which is a security module of the mass storage device. This can interact with the client application 320 or through a management layer within the device. The SSA and other related information is described in patent application Ser. No. 11/313,536, entitled “Control Structure for Versatile Content Control,” to Fabrice Jogand-Coulomb et al, which is hereby incorporated by this reference in its entirety. The SSA system sits atop the storage system of the MSD and adds a security layer for stored files and other data, including, in one embodiment, the seeds.
SSA partitions are hidden (from the host operating system or OS and all other entities) partitions that can be accessed only through the SSA. The SSA system will preferably not allow the host device or other entity to access an SSA partition, other than through a session established by logging onto an access control record (“ACR”). Similarly, preferably the SSA will not provide information regarding the existence, size and access permission of an SSA partition, unless this request is coming through an established session by an appropriate authority or entity.
Access rights to partitions are derived from a list of permissions contained within the ACR. An ACR also may contain the login algorithm, credentials, and authentication method of or to be used with an entity. When a partition is created, the host provides a reference name or ID for the partition. This reference is used in further read and write commands to the partition. Therefore, in such an embodiment, in order for an entity wishing to load a seed in the MSD, it would have to have the proper permission and/or the proper login algorithm, credentials, and authentication method.
Client 320 also comprises the device interface 320A, user interface 320B, authentication manager 320C, and provisioning manager 320D. Client 320 seamlessly logs a user onto his chosen institutions based on user interaction with the user interface 320A. The user interface triggers the device interface, authentication manager, and provisioning manager without the knowledge or intervention of the user.
The intricacies of the processes will now be described in detail with regard to
In step 712, MSD 100 generates an OTP value for each of the selected institutions. Each institution may have a unique seed and algorithm for OTP generation. In step 716, the client connects to the selected institutions. Once connected, the client then presents the information necessary to log the user into the selected institutions. This information comprises the user's identifying information such as his name, account number, or user ID, the user's secret information such as his password or PIN, and the OTP value for the particular institution if the institution is of the type that requires an OTP value for log in. The information can be gathered from a page of the client user interface that the user fills in, or can be gathered by monitoring the actions of a user as he enters his information in the web page of an institution. In one embodiment, the client may provide the user and authentication information to a web server that will upon receiving valid user credentials and authentication information, will automatically fill out the traditional log-in web page entries that are normally used to log on without the two-factor authentication. This embodiment would enable a given institution to maintain a single web log-on page, while adding a separate system component to handle the two factor authentication. In certain embodiments, the device ID of MSD 100 may also be necessary to log in. In step 724, user 99 and device 100 are authenticated/validated and the user/device are logged into each selected institution. Finally, once the user is logged in, he can access the institution. In the case where the user is accessing a web site of an institution, the institution web pages are presented to the user in step 728. Of course, institution interfaces are not limited to web pages, and access of other interfaces are within the scope of the present invention. This is especially relevant when host 110 is something other than a PC.
As mentioned previously, before MSD 100 can be used to log a user into his selected sites, slots within the device should be bound and activated. The user and device must also be authenticated before login is completed, as seen in
As mentioned, in one embodiment, the client may provide the user and authentication information to a web server that will upon receiving valid user credentials and authentication information, will automatically fill out the traditional log-in web page entries that are normally used to log on without the two-factor authentication. This embodiment would enable a given institution to maintain a single web log-on page, while adding a separate system component to handle the two factor authentication. In this case, the two-factor authentication may consist of forms of authentication that do not easily lend themselves to form-filling, as OTP does, but instead may be authentication schemes, such as PKI, which typically involve challenge-responses operations.
PKI is an authentication technology. Using a combination of secret key and public key cryptography, PKI enables a number of other security services including data confidentiality, data integrity, and key management. The foundation or framework for PKI is defined in the ITU-TX.509 Recommendation [X.509] which is incorporated by this reference it is entirety.
End Entities are sometimes thought of as end-users. Although this is often the case, the term End Entity is meant to be much more generic. An End Entity can be an end-user, a device such as a router or a server, a process, or anything that can be identified in the subject name of a public key certificate. End Entities can also be thought of as consumers of the PKI-related services. In the present invention, as seen in the embodiment shown in
Public keys are distributed in the form of public key certificates by CA 550. A certificate could be required from MSD 100 so that an institution 118 or validating entity would allow a user of MSD 100 to sign on. A certificate from an institution 118 could also be utilized to prove that the institution is authentic before the MSD would sign the user into the institution. Public key certificates are digitally signed by the issuing CA 520 (which effectively binds the subject name to the public key). CAs are also responsible for issuing certificate revocation lists (“CRLs”) unless this has been delegated to a separate CRL Issuer. CAs may also be involved in a number of administrative tasks such as end-user registration, but these are often delegated to a separate registration authority (“RA”) which is optional and not shown in
In a preferred embodiment, once all the accounts shown have been configured, the user would only have to enter his master password for the MSD, and could then simply click on the icon corresponding to the institution he wishes to log into. In other embodiments, individual passwords and/or user ID's would also need to be entered for added security.
The operations described in detail earlier in the application that facilitate sign on would then take place seamlessly behind the scenes. This would simultaneously make dealing with logon and password management very convenient for the user, while at the same time providing for a very high level of security that would benefit users and institutions alike. All of this convenience and security are incorporated into a device a user most likely already owns. This is possible, because, unlike in dedicated tokens, the client can be added to the mass storage memory of a pocket sized mass storage device. The portable mass storage device has security, both physical and logical, that are more robust than in an open environment such as a PC, and hacking or “phishing” for information is therefore much more difficult. Also, unlike some mass storage devices that may correlate different passwords or other information, the present invention utilizes algorithms and processes that can generate unique password values that are constantly changing yet instantly verifiable.
While embodiments of the invention have been described, it should be understood that the present invention is not limited to these illustrative embodiments but is defined by the appended claims. For example, MSD 100 may utilize magnetic disk rather than flash type solid state memory for mass storage purposes, and any manner of symmetric or asymmetric authentication can be implemented for authentication purposes to enhance the traditional security of user selected passwords.
This application is related to and claims priority from Provisional Application No. 60/697,906, filed on Jul. 8, 2005 entitled “Mass Storage Device With Automated Credentials Loading” to Carlos J. Gonzalez et al. This application is also related to: application Ser. No. 11/319,385, filed Dec. 27, 2005, entitled “Mass Storage Device With Automated Credentials Loading” to Carlos J. Gonzalez et al., application Ser. No. 11/285,600, filed Nov. 21, 2005, entitled “Hardware Driver Integrity Check of Memory Card Controller Firmware” to M. Holtzman et al., application Ser. No. 11/317,390, filed Dec. 22, 2005, entitled “Methods Used in a Secure Memory Card With Life Cycle Phases” to M. Holtzman et al., application Ser. No. 11/317,862, filed Dec, 22, 2005, entitled “Secure Memory Card with Life Cycle Phases” to M. Holtzman et al., application Ser. No. 11/317,341, filed Dec. 22, 2005, entitled “Methods Used in a Secure Yet Flexible System Architecture for Secure Devices With Flash Mass Storage Memory” to M. Holtzman et al., application Ser. No. 11/317,339, filed Dec. 22, 2005, entitled “Secure Yet Flexible System Architecture for Secure Devices With Flash Mass Storage Memory” to M. Holtzman et al., All of the aforementioned applications and each application referred to in this application are hereby incorporated by this reference in their entireties.
Number | Name | Date | Kind |
---|---|---|---|
4549896 | Streicher et al. | Oct 1985 | A |
4590552 | Guttag et al. | May 1986 | A |
4697072 | Kawana | Sep 1987 | A |
4713753 | Boebert et al. | Dec 1987 | A |
4780905 | Cruts et al. | Oct 1988 | A |
4797853 | Savage et al. | Jan 1989 | A |
4907268 | Bosen et al. | Mar 1990 | A |
5006823 | Baril et al. | Apr 1991 | A |
5052040 | Preston et al. | Sep 1991 | A |
5065429 | Lang | Nov 1991 | A |
5129074 | Kikuchi et al. | Jul 1992 | A |
5235641 | Nozawa et al. | Aug 1993 | A |
5237609 | Kimura | Aug 1993 | A |
5268870 | Harari | Dec 1993 | A |
5293424 | Holtey et al. | Mar 1994 | A |
5311595 | Bjerrum et al. | May 1994 | A |
5319765 | Kimura | Jun 1994 | A |
5327563 | Singh | Jul 1994 | A |
5404485 | Ban | Apr 1995 | A |
5438575 | Bertrand | Aug 1995 | A |
5442704 | Hotley | Aug 1995 | A |
5455862 | Hoskinson | Oct 1995 | A |
5473692 | Davis | Dec 1995 | A |
5477039 | Lisimaque et al. | Dec 1995 | A |
5509120 | Merkin et al. | Apr 1996 | A |
5530862 | Wadsworth et al. | Jun 1996 | A |
5596738 | Pope | Jan 1997 | A |
5604801 | Dolan et al. | Feb 1997 | A |
5606660 | Estakhri et al. | Feb 1997 | A |
5629513 | Geronimi et al. | May 1997 | A |
5684742 | Bublitz et al. | Nov 1997 | A |
5687235 | Perlman et al. | Nov 1997 | A |
5710639 | Kuznicki et al. | Jan 1998 | A |
5742616 | Torreiter et al. | Apr 1998 | A |
5825880 | Sudia et al. | Oct 1998 | A |
5825882 | Kowalski et al. | Oct 1998 | A |
5841871 | Pinkas | Nov 1998 | A |
5857020 | Peterson, Jr. | Jan 1999 | A |
5860082 | Smith et al. | Jan 1999 | A |
5886926 | Marquot | Mar 1999 | A |
RE36181 | Koopman, Jr. et al. | Apr 1999 | E |
5896398 | Sekine | Apr 1999 | A |
5903651 | Kocher | May 1999 | A |
5917909 | Lamla | Jun 1999 | A |
5930167 | Lee et al. | Jul 1999 | A |
5933854 | Yoshimura | Aug 1999 | A |
5937425 | Ban | Aug 1999 | A |
5943423 | Muftic | Aug 1999 | A |
5949877 | Traw et al. | Sep 1999 | A |
5956405 | Yuval | Sep 1999 | A |
5987134 | Shin et al. | Nov 1999 | A |
5995623 | Kawano et al. | Nov 1999 | A |
5995965 | Experton | Nov 1999 | A |
6026402 | Vossen et al. | Feb 2000 | A |
6028933 | Heer et al. | Feb 2000 | A |
6067621 | Yu et al. | May 2000 | A |
6073234 | Kigo et al. | Jun 2000 | A |
6094724 | Benhammou et al. | Jul 2000 | A |
6101588 | Farley | Aug 2000 | A |
6134550 | Van Oorschot et al. | Oct 2000 | A |
6148354 | Ban et al. | Nov 2000 | A |
6154544 | Farris et al. | Nov 2000 | A |
6158004 | Mason et al. | Dec 2000 | A |
6181252 | Nakano | Jan 2001 | B1 |
6182229 | Nielsen | Jan 2001 | B1 |
6189097 | Tycksen, Jr. et al. | Feb 2001 | B1 |
6209099 | Saunders | Mar 2001 | B1 |
6223271 | Cepulis | Apr 2001 | B1 |
6230223 | Olarig | May 2001 | B1 |
6230233 | Lofgren et al. | May 2001 | B1 |
6236280 | Allee | May 2001 | B1 |
6243816 | Fang et al. | Jun 2001 | B1 |
6253328 | Smith, Jr. | Jun 2001 | B1 |
6343291 | Goldman | Jan 2002 | B1 |
6353888 | Kakehi et al. | Mar 2002 | B1 |
6356941 | Cohen | Mar 2002 | B1 |
6370251 | Hardy et al. | Apr 2002 | B1 |
6371377 | Asoh et al. | Apr 2002 | B2 |
6385729 | DiGiorgio et al. | May 2002 | B1 |
6389542 | Flyntz | May 2002 | B1 |
6393565 | Lockhart et al. | May 2002 | B1 |
6422460 | Boesch | Jul 2002 | B1 |
6434700 | Alonso et al. | Aug 2002 | B1 |
6445794 | Shefi | Sep 2002 | B1 |
6456528 | Chen | Sep 2002 | B1 |
6457126 | Nakamura et al. | Sep 2002 | B1 |
6481632 | Wentker et al. | Nov 2002 | B2 |
6490680 | Scheidt et al. | Dec 2002 | B1 |
6510501 | Ho | Jan 2003 | B1 |
6513116 | Valente | Jan 2003 | B1 |
6522655 | Laiho | Feb 2003 | B1 |
6571335 | O'Donnell et al. | May 2003 | B1 |
6577734 | Etzel et al. | Jun 2003 | B1 |
6615347 | De Silva et al. | Sep 2003 | B1 |
6615352 | Terao et al. | Sep 2003 | B2 |
6629192 | Schaefer et al. | Sep 2003 | B1 |
6671808 | Abbott et al. | Dec 2003 | B1 |
6678741 | Northcutt et al. | Jan 2004 | B1 |
6678828 | Pham et al. | Jan 2004 | B1 |
6694436 | Audebert | Feb 2004 | B1 |
6714921 | Stefik et al. | Mar 2004 | B2 |
6742117 | Hikita et al. | May 2004 | B1 |
6754765 | Chang et al. | Jun 2004 | B1 |
6763399 | Margalit et al. | Jul 2004 | B2 |
6779113 | Guthery | Aug 2004 | B1 |
6783078 | Leaming | Aug 2004 | B1 |
6788575 | Kozakai et al. | Sep 2004 | B2 |
6804786 | Chamley et al. | Oct 2004 | B1 |
6810123 | Farris et al. | Oct 2004 | B2 |
6816900 | Vogel et al. | Nov 2004 | B1 |
6829676 | Maeda et al. | Dec 2004 | B2 |
6832731 | Kaneko | Dec 2004 | B2 |
6845908 | Mority et al. | Jan 2005 | B2 |
6848045 | Long et al. | Jan 2005 | B2 |
6865555 | Novak | Mar 2005 | B2 |
6880079 | Kefford et al. | Apr 2005 | B2 |
6880084 | Brittenham et al. | Apr 2005 | B1 |
6892304 | Galsso et al. | May 2005 | B1 |
6901499 | Aasheim et al. | May 2005 | B2 |
6912633 | De Jong | Jun 2005 | B2 |
6928547 | Brown et al. | Aug 2005 | B2 |
6938162 | Nagai et al. | Aug 2005 | B1 |
6988175 | Lasser | Jan 2006 | B2 |
7023996 | Stephenson et al. | Apr 2006 | B2 |
7036020 | Thibadeau | Apr 2006 | B2 |
7051157 | James | May 2006 | B2 |
7058818 | Dariel | Jun 2006 | B2 |
7062616 | Sadhasivan et al. | Jun 2006 | B2 |
7073063 | Peinado | Jul 2006 | B2 |
7073073 | Nonaka et al. | Jul 2006 | B1 |
7095585 | Payne et al. | Aug 2006 | B2 |
7120729 | Gonzalez et al. | Oct 2006 | B2 |
7124301 | Uchida | Oct 2006 | B1 |
7127550 | Lin | Oct 2006 | B1 |
7193899 | Eggleston et al. | Mar 2007 | B2 |
7215771 | Hamlin | May 2007 | B1 |
7225341 | Yoshino et al. | May 2007 | B2 |
7246266 | Sneed et al. | Jul 2007 | B2 |
7269741 | Matsui et al. | Sep 2007 | B2 |
7299358 | Chateau et al. | Nov 2007 | B2 |
7322042 | Srinivasan et al. | Jan 2008 | B2 |
7364087 | Zimmer et al. | Apr 2008 | B2 |
7370192 | Sumner | May 2008 | B2 |
7380275 | Srinivasan et al. | May 2008 | B2 |
7409705 | Ueda et al. | Aug 2008 | B2 |
7412053 | Lyle | Aug 2008 | B1 |
7426747 | Thibadeau | Sep 2008 | B2 |
7478248 | Ziv et al. | Jan 2009 | B2 |
7493656 | Goodwill et al. | Feb 2009 | B2 |
7506128 | Deo et al. | Mar 2009 | B2 |
7519989 | Lin et al. | Apr 2009 | B2 |
7523072 | Stefik et al. | Apr 2009 | B2 |
7594135 | Gonzalez et al. | Sep 2009 | B2 |
20010019614 | Madoukh | Sep 2001 | A1 |
20010025355 | Palm et al. | Sep 2001 | A1 |
20010037435 | Van Doren | Nov 2001 | A1 |
20010047335 | Arndt et al. | Nov 2001 | A1 |
20020023219 | Treffers et al. | Feb 2002 | A1 |
20020029340 | Pensak et al. | Mar 2002 | A1 |
20020029343 | Kurita | Mar 2002 | A1 |
20020034303 | Farris et al. | Mar 2002 | A1 |
20020065730 | Nii | May 2002 | A1 |
20020099666 | Dryer et al. | Jul 2002 | A1 |
20020141588 | Rollins | Oct 2002 | A1 |
20020145632 | Shmueli et al. | Oct 2002 | A1 |
20020166023 | Nolan et al. | Nov 2002 | A1 |
20020174337 | Aihara | Nov 2002 | A1 |
20020176575 | Qawami et al. | Nov 2002 | A1 |
20020178370 | Gurevich et al. | Nov 2002 | A1 |
20020186842 | Sabet-Sharghi et al. | Dec 2002 | A1 |
20020191794 | Farris et al. | Dec 2002 | A1 |
20020199001 | Wenocur et al. | Dec 2002 | A1 |
20030018889 | Burnett et al. | Jan 2003 | A1 |
20030028514 | Lord et al. | Feb 2003 | A1 |
20030028797 | Long et al. | Feb 2003 | A1 |
20030061504 | Sprigg et al. | Mar 2003 | A1 |
20030065876 | Lasser | Apr 2003 | A1 |
20030070083 | Nessler | Apr 2003 | A1 |
20030101327 | Beck | May 2003 | A1 |
20030110169 | Zuili et al. | Jun 2003 | A1 |
20030120938 | Mullor | Jun 2003 | A1 |
20030131210 | Mueller | Jul 2003 | A1 |
20030135739 | Talton | Jul 2003 | A1 |
20030149854 | Yoshino et al. | Aug 2003 | A1 |
20030149886 | Ito et al. | Aug 2003 | A1 |
20030156473 | Sinclair et al. | Aug 2003 | A1 |
20030172280 | Scheidt et al. | Sep 2003 | A1 |
20030177319 | De Jong | Sep 2003 | A1 |
20030188117 | Yoshino et al. | Oct 2003 | A1 |
20030196028 | Maeda et al. | Oct 2003 | A1 |
20030204726 | Kefford et al. | Oct 2003 | A1 |
20030212894 | Buck et al. | Nov 2003 | A1 |
20030212895 | Kisliakov | Nov 2003 | A1 |
20030217011 | Peinado et al. | Nov 2003 | A1 |
20030221117 | Teglia | Nov 2003 | A1 |
20040024917 | Kennedy et al. | Feb 2004 | A1 |
20040025010 | Azema et al. | Feb 2004 | A1 |
20040025011 | Azema et al. | Feb 2004 | A1 |
20040025027 | Balard et al. | Feb 2004 | A1 |
20040025036 | Balard et al. | Feb 2004 | A1 |
20040026496 | Zuili | Feb 2004 | A1 |
20040039911 | Oka et al. | Feb 2004 | A1 |
20040044625 | Sakamura et al. | Mar 2004 | A1 |
20040054907 | Chateau et al. | Mar 2004 | A1 |
20040059916 | Mizushima et al. | Mar 2004 | A1 |
20040063495 | LeMay et al. | Apr 2004 | A1 |
20040066936 | Farris et al. | Apr 2004 | A1 |
20040068631 | Ukeda et al. | Apr 2004 | A1 |
20040083335 | Gonzalez et al. | Apr 2004 | A1 |
20040083370 | De Jong | Apr 2004 | A1 |
20040093592 | Rao | May 2004 | A1 |
20040098585 | Grove et al. | May 2004 | A1 |
20040103288 | Ziv et al. | May 2004 | A1 |
20040117653 | Shapira et al. | Jun 2004 | A1 |
20040123127 | Teicher et al. | Jun 2004 | A1 |
20040128523 | Fukjioka | Jul 2004 | A1 |
20040132437 | Ohmori et al. | Jul 2004 | A1 |
20040139021 | Reed et al. | Jul 2004 | A1 |
20040148536 | Zimmer et al. | Jul 2004 | A1 |
20040153642 | Plotkin et al. | Aug 2004 | A1 |
20040168081 | Ladas et al. | Aug 2004 | A1 |
20040186994 | Herbert et al. | Sep 2004 | A1 |
20040193925 | Safriel | Sep 2004 | A1 |
20040230963 | Rothman et al. | Nov 2004 | A1 |
20040247129 | Patariu et al. | Dec 2004 | A1 |
20040264254 | Eggleston et al. | Dec 2004 | A1 |
20040268339 | Van Someren et al. | Dec 2004 | A1 |
20050010758 | Landrock et al. | Jan 2005 | A1 |
20050010783 | Libin et al. | Jan 2005 | A1 |
20050015588 | Lin et al. | Jan 2005 | A1 |
20050033968 | Dupouy et al. | Feb 2005 | A1 |
20050049931 | Wisnudel et al. | Mar 2005 | A1 |
20050050330 | Agam et al. | Mar 2005 | A1 |
20050091496 | Hyser | Apr 2005 | A1 |
20050108564 | Freeman et al. | May 2005 | A1 |
20050109841 | Ryan et al. | May 2005 | A1 |
20050114620 | Justen | May 2005 | A1 |
20050120205 | Umezawa et al. | Jun 2005 | A1 |
20050123132 | Sumner | Jun 2005 | A1 |
20050132186 | Khan et al. | Jun 2005 | A1 |
20050137997 | Bussert et al. | Jun 2005 | A1 |
20050138393 | Challener et al. | Jun 2005 | A1 |
20050160217 | Gonzalez et al. | Jul 2005 | A1 |
20050180209 | Lasser | Aug 2005 | A1 |
20050185493 | Fujioka et al. | Aug 2005 | A1 |
20050190599 | Eggleston et al. | Sep 2005 | A1 |
20050193025 | Mosek | Sep 2005 | A1 |
20050193161 | Lee et al. | Sep 2005 | A1 |
20050193206 | Kunisa et al. | Sep 2005 | A1 |
20050209716 | Buhr et al. | Sep 2005 | A1 |
20050256838 | Lasser | Nov 2005 | A1 |
20060036873 | Ho et al. | Feb 2006 | A1 |
20060083228 | Ong et al. | Apr 2006 | A1 |
20060106606 | Labaton | May 2006 | A1 |
20060107047 | Bar-El | May 2006 | A1 |
20060107063 | Fiske | May 2006 | A1 |
20060107064 | Fiske | May 2006 | A1 |
20060107312 | Fiske | May 2006 | A1 |
20060107316 | Fiske | May 2006 | A1 |
20060112241 | Weiss et al. | May 2006 | A1 |
20060126422 | Takagi et al. | Jun 2006 | A1 |
20060129844 | Oshikiri | Jun 2006 | A1 |
20060143600 | Cottrell et al. | Jun 2006 | A1 |
20060161725 | Lee et al. | Jul 2006 | A1 |
20060176068 | Holtzman et al. | Aug 2006 | A1 |
20060177064 | Holtzman et al. | Aug 2006 | A1 |
20060232826 | Bar-El | Oct 2006 | A1 |
20060239449 | Holtzman et al. | Oct 2006 | A1 |
20060242064 | Jogand-Coulomb et al. | Oct 2006 | A1 |
20060242065 | Jogand-Coulomb et al. | Oct 2006 | A1 |
20060242066 | Jogand-Coulomb et al. | Oct 2006 | A1 |
20060242067 | Jogand-Coulomb et al. | Oct 2006 | A1 |
20060242068 | Jogand-Coulomb et al. | Oct 2006 | A1 |
20060242150 | Jogand-Coulomb et al. | Oct 2006 | A1 |
20060242151 | Jogand-Coulomb et al. | Oct 2006 | A1 |
20060262928 | Bar-El et al. | Nov 2006 | A1 |
20070011724 | Gonzalez et al. | Jan 2007 | A1 |
20070061502 | Lasser et al. | Mar 2007 | A1 |
20070061570 | Holtzman et al. | Mar 2007 | A1 |
20070061581 | Holtzman et al. | Mar 2007 | A1 |
20070061597 | Holtzman et al. | Mar 2007 | A1 |
20070061897 | Holtzman et al. | Mar 2007 | A1 |
20070067828 | Bychkov | Mar 2007 | A1 |
20070113294 | Field et al. | May 2007 | A1 |
20070130472 | Buer et al. | Jun 2007 | A1 |
20070143555 | Nemiroff et al. | Jun 2007 | A1 |
20070168292 | Jogand-Coulomb et al. | Jul 2007 | A1 |
20070180210 | Thibadeau | Aug 2007 | A1 |
20070188183 | Holtzman et al. | Aug 2007 | A1 |
20070234064 | Nihei | Oct 2007 | A1 |
20070250920 | Lindsay | Oct 2007 | A1 |
20080010449 | Holtzman et al. | Jan 2008 | A1 |
20080010450 | Holtzman et al. | Jan 2008 | A1 |
20080010451 | Holtzman et al. | Jan 2008 | A1 |
20080010455 | Holtzman et al. | Jan 2008 | A1 |
20080010458 | Holtzman et al. | Jan 2008 | A1 |
20080010685 | Holtzman et al. | Jan 2008 | A1 |
20080022395 | Holtzman et al. | Jan 2008 | A1 |
20080022413 | Holtzman et al. | Jan 2008 | A1 |
20080034440 | Holtzman et al. | Feb 2008 | A1 |
20080072060 | Cannon et al. | Mar 2008 | A1 |
20080077799 | Labaton | Mar 2008 | A1 |
20080082447 | Jogand-Coulomb et al. | Apr 2008 | A1 |
20080215847 | Holtzman et al. | Sep 2008 | A1 |
20080276098 | Florencio et al. | Nov 2008 | A1 |
20080313719 | Kaliski et al. | Dec 2008 | A1 |
20090055655 | Ziv et al. | Feb 2009 | A1 |
20090119501 | Petersen | May 2009 | A1 |
20090119517 | Ziv et al. | May 2009 | A1 |
20090125997 | Cook | May 2009 | A1 |
20090205036 | Slaton et al. | Aug 2009 | A1 |
20090249076 | Reed et al. | Oct 2009 | A1 |
20090259588 | Lindsay | Oct 2009 | A1 |
Number | Date | Country |
---|---|---|
1466060 | Jan 2004 | CN |
87143 | Feb 1983 | EP |
0 330 404 | Aug 1989 | EP |
461983 | Jun 1991 | EP |
461983 | Apr 1995 | EP |
0 919 904 | Aug 1998 | EP |
0 919 904 | Jun 1999 | EP |
1 004 992 | May 2000 | EP |
1 074 906 | Aug 2000 | EP |
1 209 657 | Aug 2000 | EP |
1 117 206 | Jul 2001 | EP |
1 273 996 | Jan 2003 | EP |
1 351 151 | Oct 2003 | EP |
1 361 527 | Nov 2003 | EP |
1 467 312 | Apr 2004 | EP |
0 849 657 | Jun 2004 | EP |
1 429 224 | Jun 2004 | EP |
1 487 170 | Jun 2004 | EP |
1 457 922 | Sep 2004 | EP |
1 467 312 | Oct 2004 | EP |
1487170 | Dec 2004 | EP |
1487170 | Dec 2004 | EP |
1 496 419 | Jan 2005 | EP |
1 594 250 | Nov 2005 | EP |
1 933 252 | Jun 2008 | EP |
1933252 | Jun 2008 | EP |
2 391 082 | Jul 2002 | GB |
2 391 082 | Jan 2004 | GB |
2002-288453 | Apr 2002 | JP |
2002288453 | Oct 2002 | JP |
2004-0063071 | Jul 2004 | KR |
WO 9807255 | Feb 1998 | WO |
WO 9947989 | Sep 1999 | WO |
WO 9964996 | Dec 1999 | WO |
WO 0042491 | Jul 2000 | WO |
WO 0048063 | Aug 2000 | WO |
WO 0201368 | Jan 2002 | WO |
WO 0225415 | Mar 2002 | WO |
WO 0242912 | May 2002 | WO |
WO 0248846 | Jun 2002 | WO |
WO 0248846 | Jun 2002 | WO |
WO 02063847 | Aug 2002 | WO |
WO 02096016 | Nov 2002 | WO |
WO 02103495 | Dec 2002 | WO |
WO 03081544 | Oct 2003 | WO |
WO 03096287 | Nov 2003 | WO |
WO 03096287 | Nov 2003 | WO |
WO 2004034202 | Apr 2004 | WO |
WO 2004040578 | May 2004 | WO |
WO 2004040586 | May 2004 | WO |
WO 2004086228 | Oct 2004 | WO |
WO 2004092886 | Oct 2004 | WO |
WO 2004112036 | Dec 2004 | WO |
WO2005001653 | Jan 2005 | WO |
WO 2005013125 | Feb 2005 | WO |
WO 2005010686 | Feb 2005 | WO |
WO 2005010688 | Feb 2005 | WO |
WO 2006069194 | Jun 2006 | WO |
WO 2006069274 | Jun 2006 | WO |
WO 2006069311 | Jun 2006 | WO |
WO 2006069312 | Jun 2006 | WO |
WO 2006086232 | Aug 2006 | WO |
WO 2007008540 | Jan 2007 | WO |
WO 2007033321 | Mar 2007 | WO |
WO 2007033322 | Mar 2007 | WO |
WO 2008008243 | Jan 2008 | WO |
WO 2008008244 | Jan 2008 | WO |
WO 2008008245 | Jan 2008 | WO |
WO 2008013655 | Jan 2008 | WO |
WO 2008013656 | Jan 2008 | WO |
Number | Date | Country | |
---|---|---|---|
20070016941 A1 | Jan 2007 | US |
Number | Date | Country | |
---|---|---|---|
60697906 | Jul 2005 | US |