US20130214908A9 - Smart card session optimization - Google Patents

Abstract

A command destined for a smart card is received. If the command is of a state-altering type that places the smart card in a known state, it is relayed to a smart card reader unless the smart card is currently in the known state. If the command is a POWER OFF command, it is relayed to the smart card reader unless (i) the smart card is currently in the known state and (ii) within a predetermined time from receiving the command, a subsequent command of the state-altering type that places the smart card in the known state is received. If the command is not a POWER OFF command and is not of the state-altering type that places the smart card in the known state, it is relayed to the smart card reader. The command is discarded if not relayed to the smart card reader.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• The present application is a continuation of U.S. patent application Ser. No. 12/790,940, filed May 31, 2010, which in turn is a continuation of U.S. patent application Ser. No. 11/688,935, filed Mar. 21, 2007, and issued as U.S. Pat. No. 7,726,568 on Jun. 1, 2010, the contents of which are hereby incorporated herein by reference.
TECHNICAL FIELD
• The present application relates generally to smart card readers and, in particular, to communications between a smart card reader and a computer system.
BACKGROUND
• Smart card readers are used in a variety of applications, for example in combination with handheld devices and personal computers for security related purposes.
• Some operating systems (such as Microsoft® Windows®) installed in personal computers include a generic or multipurpose smart card resource manager. Third party vendors may also provide their own smart card readers, which may thus require their own smart card reader drivers to be installed for use with the operating system. In such instances, the smart card resource manager may communicate with the vendor specific smart card reader driver first in order to access or communicate with the smart card reader.
• Improved efficiencies in communications between smart card resource managers, smart card reader drivers and smart card readers is desirable.
BRIEF DESCRIPTION OF THE DRAWINGS
• Reference will now be made to the drawings, which show by way of example, embodiments of the invention, and in which:
• FIG. 1 shows in block diagram form a communication system suitable for a smart card reader and personal computer in accordance with one embodiment;
• FIG. 2 shows an operational block representation of a personal computing device according to one embodiment;
• FIG. 3 shows an operational block representation of an embodiment of a smart card reader for use with the personal computing device shown inFIG. 2;
• FIG. 4 shows in diagrammatic form a Microsoft® Windows® smart card environment;
• FIG. 5 shows in diagrammatic form the interaction between the smart card reader driver and the Windows® smart card driver library in the smart card reader environment as shown inFIG. 4;
• FIG. 6 shows in diagrammatic form a smart card reader environment;
• FIG. 7 shows a flow diagram of a conventional method carried out by a smart card reader service;
• FIG. 8 shows an example conversation between a smart card resource manager, a vendor supplied smart card reader driver, the smart card reader service and a smart card reader, for carrying out the method ofFIG. 7;
• FIG. 9 shows a flow diagram of a method carried out by a smart card reader service in accordance with one embodiment; and
• FIG. 10 shows an example conversation between a smart card resource manager, a vendor supplied smart card reader driver, the smart card reader service and a smart card reader, for carrying out the method ofFIG. 9 in accordance with one embodiment.
DETAILED DESCRIPTION
• According to one aspect described herein, there is provided a method of facilitating communications between a computer device and a smart card reader having an associated smart card, the computer device including a smart card resource manager and a smart card reader service, the smart card reader service acting as a relay for commands between the smart card resource manager and the smart card reader. The method comprising the smart card reader service: (a) receiving from the smart card resource manager a first command for placing the smart card in a first state and relaying the first command to the smart card reader; (b) receiving a second command from the smart card resource manager for placing the smart card into a second state and a third command from the smart card resource manager for placing the smart card into the first state; and (c) determining if the smart card was in the first state prior to receiving the second command, and (i) if the smart card is determined to have been in the first state then forgoing relaying the second command and the third command to the smart card reader, and (ii) if the smart card is not determined to have been in the first state, then relaying the second command and the third command to the smart card reader.
• According to another aspect there is provided a computer device for communicating over a wireless communications link with a smart card reader, the computer device comprising: a smart card resource manager for providing commands for the smart card reader; and a smart card reader service for selectively relaying and filtering commands received from the smartcard resource manager for the smart card reader, the smart card reader service being configured for: (a) receiving from the smart card resource manager a first command for placing the smart card in a first state and relaying the first command to the smart card reader; (b) receiving a second command from the smart card resource manager for placing the smart card into a second state and a third command from the smart card resource manager for placing the smart card into the first state; and (c) determining if the smart card was in the first state prior to receiving the second command, and (i) if the smart card is determined to have been in the first state then forgoing relaying the second command and the third command to the smart card reader, and (ii) if the smart card is not determined to have been in the first state, then relaying the second command and the third command to the smart card reader.
• As suggested above, some operating systems (such as Microsoft® Windows®) installed in personal computers include a generic or multipurpose smart card resource manager. Third party vendors may also provide their own smart card readers, which may thus require their own smart card reader drivers to be installed for use with the operating system. In such instances, the smart card resource manager may communicate with the vendor specific smart card reader driver first in order to access or communicate with the smart card reader. In other words, the vendor supplied smart card reader driver would merely act as a flow-through or relay of any instructions from the smart card resource manager to the smart card reader. A difficulty with such systems is that many commands from the smart card resource manager may be redundant or unnecessary, and relaying such commands to the smart card reader may be an inefficient use of time and computational resources. Thus, more efficient management of communications between a generic smart card resource manager and a smart card reader is desired.
• Reference is first made toFIG. 1, which shows anillustrative communication system10 to which embodiments described herein can be applied. Thesystem10 includes one or more mobile devices20 (only one of which is shown inFIG. 1) that are enabled to communicate with one or morewireless networks18. Thewireless network18 may be implemented as a packet-based cellular wide area wireless network that includes a number of base stations each providing wireless Radio Frequency (RF) coverage to a corresponding area or cell. In some embodiments, instead of or in addition to a wide area wireless network,network18 may include a local wireless area network, such as for example a wireless local area network that conforms to IEEE 802.11 standards such as 802.11b and/or 802.11g. In at least some example embodiments, thewireless network18 is connected throughintermediate communications links22, including for example the Internet, to one ormore enterprise networks30 each associated with respectivemobile devices20, such that themobile devices20 are each enabled to exchange electronic messages and other information with the enterprise networks that they are associated with. At least some of themobile devices20 have a further associated secondary mobile device in the form of asmart card reader110. Additionally, a user of themobile device20 and thesmart card reader110 will have access to apersonal computer100 that is connected to theenterprise network30 over acommunications link24. In one embodiment, thecommunications link24 is a local area network or wide area network providing organizational connectivity with theenterprise network30. Thesmart card reader110 may also be used with thepersonal computer100, through either a wired or wireless connection.
• Reference is next made toFIG. 2, which shows in greater detail an embodiment of thepersonal computer100. Thepersonal computer100 includes adisplay sub-system210 and anetwork communication subsystem212 for two-way communications with the enterprise network30 (FIG. 1). According to one embodiment, thecommunications subsystem212 may include a wireless communications subsystem including antennas (not shown), RF transceivers (not shown), and some signal processing capabilities, implemented, for example, by a digital signal processor (not shown). According to another embodiment, thecommunications subsystem212 may include a wired communications subsystem conforming to the well known Ethernet standard, including a 10 Mbps, 100 Mbps, or 1 Gbps Ethernet connection. Thepersonal computer100 also includes a controller in the form of at least onemicroprocessor216 which is suitably programmed to control the overall operation and functions of thepersonal computer100, which are described in more detail below. Thepersonal computer100 includes peripheral devices or subsystems such as arandom access memory218, astorage device220 such as a hard disk drive, an auxiliary input/output (I/O) subsystem222 (e.g., a mouse), a serial port224 (e.g., a USB port), an input device226 (e.g., a keyboard), aspeaker228, amicrophone230, a short-range communications subsystem232 (e.g., an infrared transceiver, wireless bus protocol such as a Bluetooth™ system, or any other means of local wireless communications), and any other device subsystems generally designated byreference234.
• Themicroprocessor216 operates under stored program control with code being stored in thestorage device220. As depicted inFIG. 2, while operational, theRAM218 includes programs including an operating system program orcode module236, such as the Microsoft® Windows® operating system. Operating systems such as Microsoft® Windows® typically divide theRAM space218 into two portions, namely a restricted access space such as akernel space238 and auser space240, or functional equivalents thereof. TheRAM218 further includes software applications indicated generally byreference242, which typically reside in theuser space240, anddrivers244, which typically reside in thekernel space238. The user space further includes various application programming interfaces (APIs)246 and various user interface (UT)components248. TheUI components248 are the existing functions or routines provided by theoperating system236 that may be called by programs such as thesoftware applications242 in order to display elements of the graphical user interface to the user of thepersonal computer100.
• Theoperating system code236, code forspecific software applications242, code for thedrivers244, code for the various application programming interfaces (APIs)246, or code for the various user interface (UI)components248 is permanently or semi-permanently stored on thestorage device220 and may be temporarily loaded into a volatile storage medium such as theRAM218 during operation of thepersonal computer100. Received communication signals and other data with information may also be stored in theRAM218. Code for thespecific device applications242 or other elements of theuser space240 may be swapped back out to thestorage device220 as needed during operation of thepersonal computer100, while code related to thekernel space238 such as many aspects of theoperating system code236 and/or thedrivers244 is typically loaded into theRAM218 upon boot-up of thepersonal computer100 and is retained in theRAM218 as long as thepersonal computer100 remains powered up.
• The stored program control (e.g. operating system236, software applications242) for themicroprocessor216 also includes a predetermined set of applications or code components or software modules that control basic device operations, for example, data and text communication applications which are normally installed on thepersonal computer100 as thesoftware applications242 when thepersonal computer100 is first configured. Further applications may also be loaded (i.e., downloaded) onto thepersonal computer100 through the operation of networks described above forFIG. 1, the auxiliary I/O subsystem222, theserial port224, or the short-range communications subsystem232. The downloaded code module or components are then installed by the user (or automatically) in theRAM218 or thestorage device220.
• Theserial port224 comprises a USB type interface port for interfacing or synchronizing with another device, such as themobile device20 or thesmart card reader110. In one embodiment, theserial port224 may be used to communicate with thesmart card reader110. The short-range communications subsystem232 provides an interface for communication between thepersonal computer100 and other devices, including thesmart card reader110, to be described in greater detail in connection withFIG. 3, below. For example, thesubsystem232 may comprise an infrared communication link or channel, a wireless bus protocol such as a Bluetooth™ communications subsystem, or any other localized wireless means of communication.
• Reference is next made toFIG. 3, which shows in greater detail an example embodiment of a secondary mobile device, namely thesmart card reader110. Thesmart card reader110 includes a controller including at least onemicroprocessor310, which is suitably programmed to control the overall operation and functions of thesmart card reader110, and an output device (e.g., a display module312). Thesmart card reader110 further includes peripheral devices or subsystems such as aflash memory314, a random access memory (RAM)316, a serial port318 (e.g., a USB port), a short-range communications subsystem320 (e.g., an infrared transceiver, wireless bus protocol such as a Bluetooth system, or any other means of local communications), a storage component interface322 (e.g., for a memory card or any other data storage device), a user input device324 (e.g., a push button), and a biometric input device325 (e.g., a fingerprint reader).
• Themicroprocessor310 operates under stored program control with code or firmware being stored in the flash memory314 (or other type of non-volatile memory device or devices). As depicted inFIG. 3, the stored programs include an operating system program orcode module326 and other programs or software applications indicated generally byreference328. Theoperating system326 of thesmart card reader110 further includes a memorycard driver component330. Thememory card driver330 is responsible for coordinating communications between thesmart card reader110 and amemory card334 and/or between thesmart card reader110 and related drivers of a device to be used in conjunction with thesmart card reader110, such as thedrivers244 of thepersonal computer100. Theoperating system code326, code forspecific software applications328, code for thememory card driver330, or code components thereof, may be temporarily loaded into a volatile storage medium such as theRAM316. Received communication signals and other data with information may also be stored in theRAM316. Additionally, thestorage component interface322 receives theremovable memory card334, providing additional storage space for thesmart card reader110. In one embodiment, thememory card334 may be a smart card similar to the smart cards known to those skilled in the art. Thememory card334 may include fingerprint authentication data, password or pin code related data, or other security related data. While operation of thesmart card reader110 is described using a smart card, it will be understood by those skilled in the art that thesmart card reader110 may be designed using any suitable form of removable media without departing from the intended scope of thesmart card reader110.
• The stored program control (e.g. operating system326, software applications328) for themicroprocessor310 also includes a predetermined set of applications or code components or software modules that control basic device operations, for example, management and security related control of the data of thesmart card reader110 and may be installed on thesmart card reader110 as a component of thesoftware applications328 during the manufacturing process. Further applications may also be loaded (i.e., downloaded) onto thesmart card reader110 through the operation of theserial port318, the short-range communications subsystem320, or from thesmart card334. The downloaded code module or components are then installed by the user (or automatically) in the non-volatile program memory (e.g., the flash memory314) or theRAM316.
• Theserial port318 comprises a USB type interface port for interfacing or synchronizing with another device, such as, the personal computer100 (FIG. 2), or the mobile device20 (FIG. 1). Theserial port318 is used to exchange data with a device such as thepersonal computer100 to be stored on thesmart card334 that is plugged into thestorage component interface322 of thesmart card reader110. Theserial port318 is also used to extend the capabilities of thesmart card reader110 by providing for information or software downloads, including any user interface information, to thesmart card reader110.
• In various example embodiments, the short-range communications subsystem320 provides an interface for communication between thesmart card reader110 and thepersonal computer100 or themobile device20. In one embodiment, the short-range communications subsystem320 includes an infrared communication link or channel. In another embodiment, thesubsystem320 comprises a wireless RF bus protocol such as a Bluetooth™ communications subsystem. However, the short-range communications subsystem320 may comprise any suitable local wireless means of communication, so long as the shortrange communications subsystem232 of the personal computer100 (FIG. 2) is chosen to operate using the same protocol, which may for example facilitate wireless communication between thepersonal computer100 and thesmart card reader110. Any suitable communications mechanism and/or protocol may be implemented for the shortrange communications subsystems320 and232.
• In order for thepersonal computer100 to be able to properly communicate with thesmart card reader110, a suitable driver (hereinafter referred to as a smart card reader driver) can be loaded onto the personal computer100 (e.g., as one of the drivers244). For example, anoperating system236 such as Microsoft® Windows® may be applied to or loaded onto thepersonal computer100 and may include its own system supplied smart card reader driver.
• Referring toFIG. 4, a diagram is shown illustrating a Microsoft® Windows®smart card environment400, for example as described by the Windows® Driver Development Kit (DDK). For purposes a facilitating an understanding of example embodiments of the invention that are described further below, a brief description will now be provided of the different components of the Microsoft® Windows®smart card environment400, for communications with a smart card reader through a wired connection such as a Universal Serial Bus (USB) interface. Thekernel space238 and theuser space240 are indicated as shown inFIG. 4, with the interface between thekernel space238 and theuser space240 referred to as an I/O control interface410. Applications communicate with a smartcard reader driver414 by means of a smartcard resource manager412. In one example embodiment, the smartcard reader driver414 is a vendor supplied smart card reader driver supplied by the vendor ofsmart card reader110 and resides in thekernel space238. In some embodiments, the smartcard reader driver414 may be provided by the source of the operating system236 (e.g. Microsoft), rather than the vendor of thesmart card reader110. The smartcard resource manager412 resides in theuser space240. As shown, the smartcard reader driver414 communicates with thesmart card reader110. Theresource manager412 communicates with the smartcard reader driver414 by means of an I/O control function (i.e., the IOCTL( ) function) across the I/O control interface410. The I/O control functions are dispatched using a DeviceIoControl system call. A smart cardaware application416 may send instructions to the smartcard reader driver414 by means of the system call DeviceIoControl, and the operating system forwards the indicated I/O control function to the smartcard reader driver414. I/O control functions initiated by the smart cardaware applications416 are passed to a smartcard service provider418, which passes the function to the smartcard resource manager412, which manages the resources related to thesmart card reader110 and may communicate with the smartcard reader driver414. The operating system forwards the request by means of an I/O request packet (IRP).
• In some example embodiments, the smartcard reader driver414 is designed to work with theresource manager412 and a smartcard driver library420 supplied withoperating system236. Thus, the smartcard reader driver414 may use the smartcard driver library420 to perform many of its key operations.
• FIG. 5 illustrates generally an interaction between the smartcard reader driver414 and the Windows® smartcard driver library420, for example as described by the DDK. With reference toFIG. 5, the steps that the smartcard reader driver414 must take together with the supplieddriver library420 to process an I/O control request (IOCTL( )) are described. As indicated byreference510, the smartcard reader driver414 receives an IOCTL( ) call from the smartcard resource manager412. The smartcard reader driver414 passes IOCTL control requests to a SmartcardDeviceControl driver library routine in the smart card driver library420 (e.g., a Windows® Driver Model (WDM) based driver), as indicated byreference512. If the parameters that the smartcard reader driver414 passes to SmartcardDeviceControl are incorrect, SmartcardDeviceControl returns with an error message, as indicated byreference514. In the WDM version of thedriver library420, SmartcardDeviceControl returns without completing the IRP if the parameters are incorrect. Typically, the parameters in the IRP are intended for a specific smart card action. The IRP is a structure for parameters associated with the specific action to be passed back and forth between the smartcard resource manager412, the smartcard reader driver414 and the smartcard driver library420. In the event that the parameters are incorrect, a status value inside the IRP indicates to the smartcard resource manager412 that the intended smart card action was not successfully completed.
• If the parameters are correct, SmartcardDeviceControl processes the IOCTL request if it can (step515). SmartcardDeviceControl then checks to see if the smartcard reader driver414 has a callback defined for the IOCTL( )request that it is processing (step516). If the callback exists, SmartcardDeviceControl calls the callback, as indicated byreference517. The smartcard reader driver414callback routine503 then calls all the driver library routines that are required to complete the processing of the IOCTL, as indicated byreference518. After processing the IOCTL( ) function, the callback routine returns to the SmartCardDeviceControl function, as indicated byreference518. In the WDM version of the library, SmartcardDeviceControl completes the IRP that carried the IOCTL( ) as indicated byreference519. SmartcardDeviceControl then returns control to the reader driver dispatch routine, as indicated byreference514. The smartcard reader driver414 then returns the IOCTL( ) call to the smartcard resource manager412, as indicated byreference522.
• The smartcard library driver420 synchronizes access to the smartcard reader driver414 so that no two callback functions are called at the same time. However, card insertion and removal event handling (e.g., when thesmart card reader110 indicates that thesmart card334 is either inserted into or removed from thestorage interface322, shown inFIG. 3) may be processed asynchronously.
• Referring now toFIG. 6, another smartcard reader environment900 is illustrated in accordance with example embodiments of the invention. Thesmart card environment900 is similar to theenvironment400 ofFIG. 4, described above, except that in environment900 a wireless air interface exists between thesmart card reader110 and thepersonal computer100, rather than a wired USB interface as shown inFIG. 4. AS indicated above user applications (e.g., such as Microsoft® Outlook® or Microsoft® Word) typically reside in theuser space240, and drivers (including smart card reader driver414) reside in thekernel space238. In at least some example embodiments, placing a driver such as the smartcard reader driver414 in thekernel space238, as required by Microsoft® Windows®, can raise two possible issues: (a) theuser interface components248 cannot be directly accessed and/or displayed by code residing in thekernel space238; and (b) the Bluetooth application programming interface (API), which is installed as one of theAPIs246 and is used to access the Bluetooth communications port (i.e., the short range communications subsystem232), cannot be directly accessed from thekernel space238. Since Bluetooth communications between thepersonal computer100 and thesmart card reader110 would have to occur via the Bluetooth API, the Bluetooth API must be accessible to a smart card reader driver to be installed on thepersonal computer100. The smart card reader driver to be used on thepersonal computer100 also needs access to theUI components248 so that a user of thepersonal computer100 can input Bluetooth secure pairing keys using theUI components248, as well as other information.
• To address the above two issues, the example embodiment shown inenvironment900 ofFIG. 6 includes auser space240 application, referred to as a smart card reader service (SCRS)910. TheSCRS910 is placed in theuser space240 and therefore has access to theBluetooth API914, as theAPIs246 also reside in theuser space240. Therefore, using theBluetooth API914, theSCRS910 is capable of opening a Bluetooth communication port. TheSCRS910 takes messages from the SmartCard Reader Driver414 and sends the messages to thesmart card reader110 through the Bluetooth communication port (e.g., using the shortrange communications subsystems232 and320). Since theSCRS910 resides in theuser space240, the SCRS can make display calls to the user interface at any time, using theuser interface components248.
• Turning again toenvironment400 ofFIG. 4 in which a wired interface (e.g. a USB connection) exists between thepersonal computer100 and thesmart card reader110, in such an environment messages or data destined for thesmart card reader110 are passed from the smartcard reader driver414 through the driver stack to the USB or serial driver, since all thedrivers244 are located in thekernel space238. The USB or serial driver then sends these messages to thesmart card reader110 over the serial connection. Turning back again toenvironment900 ofFIG. 6, in such an environment communication between thepersonal computer100 and thesmart card reader110 is achieved via an air interface (e.g. a Bluetooth connection between shortrange communications subsystems234 and320). As the smartcard reader driver414 is located in thekernel space238 and does not have access to Bluetooth drivers, messages are passed back into theuser space240 to the smartcard reader service910 and theavailable Bluetooth API914 is used. Communication between the smartcard reader driver414 and the smartcard reader service910 is facilitated by a smart cardreader service library912. The smart cardreader service library912 includes a set of function calls that the smartcard reader service910 uses to communicate with the smartcard reader driver414.
• Environment900 will now be further explained in the context the following example. A user who is currently using thedesktop computer100 may wish to login to hissmart card334, which is inserted into the storage component interface332 of thesmart card reader110, using the short range communications subsystems232 (FIGS. 2) and 320 (FIG. 3) as the means of connectivity between thepersonal computer100 and thesmart card reader110. In one example, a request may come from Microsoft® Outlook® (i.e., one of the smart card aware applications416) as a result of the user wishing to insert an encrypted digital signature that is stored on thesmart card334 into an email. In the current example, Microsoft® Outlook® first sends a message to the Windows® smartcard service provider418 requesting the login to the specificsmart card334. For example, the smartcard service provider418 may create a command Application Protocol Data Unit (APDU) to be sent to thesmart card334. An APDU is a standardized data structure for smart card systems, for example as defined by ISO 7816. The smartcard service provider418 then passes the APDU to the Windows® smartcard resource manager412, which passes the APDU across the I/O control interface410 to the smartcard reader driver414. The smartcard reader driver414 then passes the APDU on to the smartcard driver library420. The smartcard driver library420 uses a callback function to pass the APDU back to the smartcard reader driver414. This callback function notifies the smartcard reader driver414 that the smartcard reader driver414 is to send the APDU to thesmart card reader110 and wait for a response from thesmart card reader110. The smartcard reader driver414 then passes the APDU up to the smartcard reader service910 using commands and/or functions that are part of the smart cardreader service library912. The smartcard reader service910 sends the APDU over the Bluetooth connection (i.e., using the shortrange communications subsystem232 and320 shown inFIGS. 2 and 3) using theBluetooth API914 to thesmart card reader110. Thesmart card reader110 then processes the APDU and returns the appropriate response. This response from thesmart card reader110 follows the same path, in reverse fashion, back to Microsoft® Outlook® (or the applicable smart card aware application416).
• As indicated above, the smart cardreader service library912 includes a set of function calls that the smartcard reader service910 uses to communicate with the smartcard reader driver414. The smartcard reader service910 also uses the smart cardreader service library912 to communicate with thesmart card reader110, in order to perform certain functions or routines provided in the smart cardreader service library912.
• Referring briefly toFIG. 8, there are a number of commands that may be sent from a smart cardaware application416 to a smart card reader110 (e.g., via the path as described above in the context ofFIG. 6). A “cold reset” command may for example be used to reset thesmart card334. The “cold reset” command may also be used at any time the smart cardaware application416 is to start a new or clean session with thesmart card334. For example, the “cold reset” command may be used when thecomputer100 receives a message from thesmart card reader110 that thesmart card334 has just been inserted into thesmart card reader110, such that thesmart card334 is in a known (reset) state. In at least some example embodiments, the smart card334 (and its associated reader110) is in a known state when thesmart card reader110 is known to have recently come out of reset and no Application Protocol Data Units (APDU) have been sent or received by thesmart card reader110 since it came out of reset. As indicated above, an APDU is a standardized data structure for smart card systems, for example as defined by ISO 7816. A send Application Protocol Data Unit (“Send APDU”) command sends an APDU. A “power off” command disengages or turns off thesmart card334. In at least some example embodiments, thesmart card reader110 is used to provide user authentication information, digital certificate information and/or encryption key information to thepersonal computer100.
• Generally, example embodiments described herein are directed to reducing redundant or unnecessary commands being sent to thesmart card reader110. It is often the case where the manufacturer of a vendor supplied smart card reader driver is different than at least one of the other applications (such as theoperating system326 and/or smart card resource manager412). Certain operational characteristics of a vendor supplied smart card reader driver and an associated smart card reader service are thus described herein to facilitate such example embodiments.
• Reference is now made toFIGS. 7 and 8, which show examples of methods for sending commands to thesmart card reader110.FIG. 7 shows a method as carried out by the smartcard reader service910, whileFIG. 8 illustrates an example conversation between the smartcard resource manager412, the vendor supplied smartcard reader driver414, the smartcard reader service910, and thesmart card reader110. Generally, in the examples ofFIGS. 7 and 8, the smartcard reader service910 acts as a flow-through or relay for any instructions from the smartcard resource manager412. Thus, referring toFIG. 7, the smartcard reader service910 may perform theexample algorithm600, as shown. At afirst step610, the smartcard reader service910 receives, through the smartcard reader driver414, a command from the smartcard resource manager412. Atstep620, in response, the smartcard reader service910 sends the command, through theBluetooth API914, in an appropriate command format that may be understood by thesmart card reader110, for processing by the smart card reader110 (and subsequently the smart card334).
• Referring now toFIG. 8, an example of a message exchange between the smartcard resource manager412, the smartcard reader driver414, the smartcard reader service910, and thesmart card reader110 is illustrated. Passage of time is generally traversed from top to bottom of the conversation shown inFIG. 8. The illustrated conversation may for example start when thepersonal computer100 receives a message fromsmart card reader110 indicating that asmart card334 has been inserted into thesmart card reader110. Note that thesmart card reader110 may be configured in some embodiments to send a smart card insertion notification message to thepersonal computer100 even if thesmart card334 was not just inserted into thesmart card reader110. For example, in one embodiment, card insert/card removal messages are used not only in the conventional sense (i.e. when a smart card has been physically inserted into or removed from the smart card reader110), but also to share access to thesmart card reader110. For example, in an embodiment where the smart card reader can pair with or communicate with two different applications or devices (for example a personal computer and a mobile communications device), thesmart card reader110 will send a card removal message to one application/device, which forces that application or device to stop sending messages to thesmartcard reader110. At the same time, thesmart card reader110 will send a card insert message to another application/device thereby allowing the other application device to send messages to thesmart card reader110.
• When thepersonal computer100 receives a smart card insertion notification message, the smartcard resource manager412 may send a number of commands intended to be processed by thesmart card reader110. As shown, the smartcard resource manager412 may send the commands of “cold reset”650, “power off”660, “cold reset”670, “send APDU”680, etc. In response, the smartcard reader driver414 will relay or send the command in the appropriate command format to the smartcard reader service910, as shown in corresponding commands of “cold reset”651, “power off”661, “cold reset”671, “send APDU”681, etc. The smartcard reader service910 will relay or send the command in the appropriate command format, through theBluetooth API914, to thesmart card reader110, as shown in corresponding commands of “cold reset”652, “power off”662, “cold reset”672, “send APDU”682, etc. Each step, notably the power off660 andcold reset670, takes time of up to at least a few seconds for the system to implement.
• Inefficiencies may arise from the above method. For example, the first instance ofcold reset650 has caused thesmart card334 to be in a reset state. This reset state is known to the smartcard resource manager412. The subsequent steps of power off660 andcold reset670 may thus be redundant in view of the fact that the reset state is a known state, and as such may not be necessary to be sent to thesmart card reader110. It is also recognized herein that since no APDU is sent to thesmart card reader110 before the steps of power off660 andcold reset670, these steps are unnecessary as thesmart card334 would still be in the same known reset state.
• Accordingly, an example embodiment of an alternative method performed by a smartcard reader service910 will now be explained, with reference toFIGS. 9 and 10. The method shown inFIGS. 9 and 10 is similar to the method shown inFIGS. 6 and 7 subject to differences that will be apparent from the Figures and the present description.FIG. 9 shows a flow diagram of the alternative method carried out by the smartcard reader service910, whileFIG. 10 shows an example conversation using such alternative method as between the smartcard resource manager412, the smartcard reader driver414, the smartcard reader service910, and thesmart card reader110. Referring now toFIG. 9, the smartcard reader service910 processes received commands (from the smart card reader driver414) and determines whether certain commands should be sent to thesmart card reader110 and which commands should not be sent. Prior to the start of thealgorithm700, it is assumed that the system is in a known state, for example a reset state where no command APDUs have been received. Thus, initially, atstep702, a data indicator APDU may be set to FALSE. The data indicator APDU will be explained in further detail below. Atstep704, thealgorithm700 receives a command (i.e., COMMAND) from the smartcard resource manager412. Note that although the present method re-uses COMMAND as a single variable throughout thealgorithm700, it can be appreciated that any number of commands may be stored, queued, and/or processed as appropriate. Atstep706, thealgorithm700 determines whether COMMAND is an APDU. If so, the data indicator APDU is set to TRUE and the COMMAND is sent to the smart card reader110 (i.e., step710). If in step706 a determination is made that COMMAND is not an APDU, thealgorithm700 then determines whether COMMAND is power off, as indicated atstep712. If not, then as indicated atstep716, a determination is then made if COMMAND is a cold reset. If the COMMAND is a cold reset, then data indicator APDU is set to FALSE. The COMMAND is then sent to the smart card reader110 (i.e., step710). Considering again step712, if a determination was made atstep712 that the COMMAND is power off, and then atstep714, thealgorithm700 determines whether the data indicator APDU is TRUE. If so, COMMAND is sent through theBluetooth API914 to the smart card reader110 (i.e., step710). If atdetermination step714 the data indicator APDU is FALSE, thealgorithm700 proceeds to step718.
• Atstep718, a TIMER is initially set at zero seconds. Generally, the TIMER may be used to determine whether a predetermined time has elapsed between a power off and a cold reset. In the example shown, the predetermined time is 2 seconds. The determination or selection of the predetermined time may for example be slightly greater than the time that it would normally take for the service to receive a cold reset command immediately after receiving a power off command. This would facilitate the situations where these two commands arrive sequentially in relatively quick succession, so that thealgorithm700 may optimize the discarding of both commands. Note that there is no strict upper bound on what is selected as the predetermined time. However, in the case where the smartcard resource manager412 is only sending a power off and has no intention of sending a cold reset, and if the predetermined time is too high, the smartcard resource manager412 will be unnecessarily preventing other devices from accessing the smart card. If an excessive time or greater than the predetermined time has elapsed, then the power off command is sent to thesmart card reader110 and the method proceeds at theinitial step704. A reason for this is that after the predetermined time has elapsed, it is unlikely that the smartcard reader service910 will receive a “Cold Reset” command from the smartcard resource manager412. In this case thesmart card334 should be powered down by way of the power off command. Atstep720, thealgorithm700 is constantly polling within the predetermined time to determine whether the cold reset command is received by the smartcard reader service910. Thus, atstep722, thealgorithm700 determines whether 2 seconds has elapsed. If so, then the smartcard reader driver414 sends the power off command to thesmart card reader110 and the method proceeds at theinitial step704. If the cold reset is sent to thesmart card reader110 within 2 seconds, thealgorithm700 returns to theinitial step704, i.e., the power off command and cold reset command are not sent to thesmart card reader110.
• Referring now toFIG. 10, an example conversation using the above-described method may take place between the smartcard resource manager412, the smartcard reader driver414, smartcard reader service910, and thesmart card reader110. Passage of time is generally traversed from top to bottom of the conversation shown inFIG. 10. Communications between the smartcard resource manager412, the vendor suppliedsmart card driver414, and the smartcard reader service910 occur within thepersonal computer100, and communications between the smartcard reader service910 and thesmart card reader110 occur in at least some example embodiments over a wireless link such as a Bluetooth™ connection. Generally, the smartcard resource manager412 and the smartcard reader driver414 are sending the same commands to the smartcard reader service910 as in the example conversation ofFIG. 8. The illustrated conversation may for example start when thepersonal computer100 receives a smart card insertion notification message fromsmart card reader110 indicating that asmart card334 has been inserted into thesmart card reader110. In an embodiment, thesmart card reader110 would be unaware of which commands the smartcard resource manager412 is sending and which are being filtered by the smartcard reader service910. As illustrated, the commands being sent arecold reset800, power off810,cold reset820, and sendAPDU830, etc. As shown, the commands that are sent from thesmart card driver414 to the smartcard reader service910 arecold reset801, power off811,cold reset821, and sendAPDU831. Also shown are the commands that are sent from the smartcard reader service910 to thesmart card reader110, which arecold reset802 and sendAPDU832. The handling of each command by the smartcard reader service910 will now be explained with reference to the algorithm700 (FIG. 9).
• Using thealgorithm700 shown inFIG. 9, thecold reset801 command would be received as COMMAND atstep704. Atstep706, at the decision of whether COMMAND=APDU?, the answer would be NO, since cold reset is not an APDU, and thus thealgorithm700 proceeds to step712. Similarly, atstep712, at the decision of whether COMMAND=power off, the answer would be NO, and thus thealgorithm700 proceeds to step716. Atstep716, at the decision of whether COMMAND=cold reset, the answer would be YES, and the data indicator APDU is set to FALSE. Atstep710, the cold reset command is then sent to thesmart card reader110, i.e., by sending cold reset802 (FIG. 10).
• The power off811 command andcold reset821 command will now be explained with reference toFIG. 9. Using thealgorithm700 shown inFIG. 9, the power off811 command would be received as COMMAND atstep704. Atstep706, at the decision of whether COMMAND=APDU?, the answer would be NO, since power off is not an APDU, and thus thealgorithm700 proceeds to step712. Similarly, atstep712, at the decision of whether COMMAND=power off, the answer would be YES, and thus thealgorithm700 proceeds to step714. Atstep714, at the decision of whether APDU=TRUE, the answer would be NO (i.e., since no APDUs have been sent), and the algorithm proceeds to step718, Atstep718, a timer is reset to TIME=0 s. Atstep720 and722, thealgorithm700 continually waits for the predetermined time (e.g. 2 seconds) until a cold reset command is received. In the example conversation ofFIG. 10, acold reset821 has been received within the 2 seconds, and as such thealgorithm700 proceeds to theinitial step704, i.e., neither the power off command nor the cold reset command are sent to the smart card reader110 (as shown in the gap in the conversation inFIG. 10). By filtering out the power offcommand811 and thecold reset command821, a time savings can be achieved in some configurations for the method ofFIG. 10 relative to the method ofFIG. 8.
• Referring again to step722 ofFIG. 9, if no command is received within 2 seconds, then, referring to step726, a power off command would be sent to thesmart card reader110. In other words, it is as if the power off command was merely relayed through to thesmart card reader110 as in the typical or conventional case.
• Continuing with the example, atstep704, asend APDU831 command may be received by the smartcard reader service910. Atstep706, at the decision of whether COMMAND=APDU?, the answer would be YES, and the data indicator APDU is set to TRUE. Thealgorithm700 then proceeds to step710. Atstep710, the APDU command is then sent to thesmart card reader110, i.e., by send APDU832 (FIG. 10).
• Accordingly, in some example embodiments, referring again toFIG. 9, in the describedalgorithm700 if an APDU command was sent by the smartcard resource manager412 before the power off command, then data indicator APDU would be set to TRUE. In consequence, subsequent commands would be merely relayed through to thesmart card reader110. A reason for this feature is that most smartcard resource managers412 assume that after a cold reset, thesmart card334 will be in a fresh session state in which no APDUs have been received. The describedalgorithm700 assists in maintaining this assumption by permitting the power off and cold reset commands to go to thesmart card reader110 when an APDU has been previously sent.
• It is understood that there may be additional steps in the above described conversation shown inFIG. 10. For example, there are certain responses that are made by thesmart card reader110 back to the smartcard reader service910 and to the smartcard resource manager412, for example an answer to reset (ATR), which are not illustrated in order to simplify the workings of embodiments of the system.
• In the example embodiment described above in respect ofFIGS. 9 and 10, the power off command is sent to thesmart card reader110 if any APDU is sent to thesmart card reader110 after the cold reset, and no distinction is made between APDUs that change the state of the of smart card and APDUs that do not change the state of the smart card. Thus, in the embodiments ofFIGS. 9 and 10, an assumption is made that all ADPUs are potentially state altering, even though this may not reflect reality. One reason for making such an assumption is that some APDUs may be card dependent proprietary APDUs such that the smartcard reader service910 is unable to differentiate between state altering and non-state altering APDUs. In an alternative embodiment of the method shown inFIGS. 9 and 10, the response of the smartcard reader service910 can vary depending on the type of APDU command sent. For example, if APDU commands are received that would not alter the state of thesmart card334 from a known state (such as the reset state), then the smartcard reader service910 would refrain from sending the power off and reset commands to thesmart card reader110. In such an alternative embodiment,decision block706 is modified to set APDU=TRUE only when (i) the received command is known to be a state altering command (other than power off or cold rest); or (ii) the smartcard reader service910 does not know if the received command is a state altering command or not. Information about the state altering nature of various smart card commands can be stored, for example, in a look up table onpersonal computer100. Accordingly, in some example embodiments, the smart card is in a known state when, subsequent to a reset command being sent to the smart card reader, no state changing APDUs have been sent or received by the smart card.
• The above-described embodiments of the present application are intended to be examples only. Alterations, modifications and variations may be effected to the particular embodiments by those skilled in the art without departing from the scope of the application.

Claims (22)

What is claimed is:

1. A method of facilitating communication with a smart card via a smart card reader, the method comprising:

receiving a current command destined for a smart card;

if the current command is of a state-altering type that places the smart card in a known state, relaying the current command to the smart card reader unless the smart card is known to be currently in the known state;

if the current command is a POWER OFF command that disengages or turns off the smart card, relaying the current command to the smart card reader unless (i) the smart card is known to be currently in the known state and (ii) within a predetermined time from receiving the current command, a subsequent command of the state-altering type that places the smart card in the known state is subsequently received;

if the current command is not a POWER OFF command and the current command is not of the state-altering type that places the smart card in the known state, relaying the current command to the smart card reader; and

discarding the current command if the current command is not relayed to the smart card reader.

2. The method as recited inclaim 1, wherein the known state is a reset state.

3. The method as recited inclaim 1, wherein the smart card is known to be currently in the known state because a previous command most recently relayed to the smart card reader is also of the state-altering type that places the smart card in the known state.

4. The method as recited inclaim 1, wherein the smart card is known to be currently in the known state because after a previous relaying to the smart card reader of a previous command of the state-altering type that places the smart card in the known state, all subsequent commands relayed to the smart card reader prior to receiving the current command were known not to alter the state of the smart card reader.

5. The method as recited inclaim 4, wherein at least one of the subsequent commands relayed to the smart card reader prior to receiving the current command was a send Application Protocol Data Unit (APDU) command.

6. The method as recited inclaim 1, wherein the current command is a send Application Protocol Data Unit (APDU) command.

7. The method as recited inclaim 1, further comprising:

if relaying the current command to the smart card reader, employing a wireless communication protocol to relay the current command to the smart card reader.

8. The method as recited inclaim 7, wherein the wireless communication protocol comprises a wireless personal area network communication protocol.

9. A computer device for communicating with a smart card reader, the computer device comprising:

a smart card resource manager for providing commands for the smart card reader; and

a smart card reader service for selectively relaying and discarding commands received from the smart card resource manager for the smart card reader, the smart card reader service being configured for:

receiving a current command destined for a smart card;

if the current command is of a state-altering type that places the smart card in a known state, relaying the current command to the smart card reader unless the smart card is known to be currently in the known state;

if the current command is a POWER OFF command that disengages or turns off the smart card, relaying the current command to the smart card reader unless (i) the smart card is known to be currently in the known state and (ii) within a predetermined time from receiving the current command, a subsequent command of the state-altering type that places the smart card in the known state is subsequently received;

if the current command is not a POWER OFF command and the current command is not of the state-altering type that places the smart card in the known state, relaying the current command to the smart card reader; and

discarding the current command if the current command is not relayed to the smart card reader.

10. The computer device as recited inclaim 9, wherein the known state is a reset state.

11. The computer device as recited inclaim 9, wherein the smart card is known to be currently in the known state because a previous command most recently relayed to the smart card reader is also of the state-altering type that places the smart card in the known state.

12. The computer device as recited inclaim 9, wherein the smart card is known to be currently in the known state because after a previous relaying to the smart card reader of a previous command of the state-altering type that places the smart card in the known state, all subsequent commands relayed to the smart card reader prior to receiving the current command were known not to alter the state of the smart card reader.

13. The computer device as recited inclaim 12, wherein at least one of the subsequent commands relayed to the smart card reader prior to receiving the current command was a send Application Protocol Data Unit (APDU) command.

14. The computer device as recited inclaim 9, wherein the current command is a send Application Protocol Data Unit (APDU) command.

15. The computer device as recited inclaim 9, further comprising a wireless communication interface compatible with a wireless communication protocol, the smart card reader service being configured for:

if relaying the current command to the smart card reader, employing the wireless communication protocol to relay the current command to the smart card reader via the wireless communication interface.

16. The computer device as recited inclaim 15, wherein the wireless communication protocol comprises a wireless personal area network communication protocol.

17. A computer readable storage medium containing computer-executable instructions that, when performed by a microprocessor, cause the microprocessor:

to receive a current command destined for a smart card;

if the current command is of a state-altering type that places the smart card in a known state, to relay the current command to the smart card reader unless the smart card is known to be currently in the known state;

if the current command is a POWER OFF command that disengages or turns off the smart card, to relay the current command to the smart card reader unless (i) the smart card is known to be currently in the known state and (ii) within a predetermined time from receiving the current command, a subsequent command of the state-altering type that places the smart card in the known state is subsequently received;

if the current command is not a POWER OFF command and the current command is not of the state-altering type that places the smart card in the known state, to relay the current command to the smart card reader; and

to discard the current command if the current command is not relayed to the smart card reader.

18. The computer readable storage medium as recited inclaim 17, wherein the known state is a reset state.

19. The computer readable storage medium as recited inclaim 17, wherein the smart card is known to be currently in the known state because a previous command most recently relayed to the smart card reader is also of the state-altering type that places the smart card in the known state.

20. The computer readable storage medium as recited inclaim 17, wherein the smart card is known to be currently in the known state because after a previous relaying to the smart card reader of a previous command of the state-altering type that places the smart card in the known state, all subsequent commands relayed to the smart card reader prior to receiving the current command were known not to alter the state of the smart card reader.

21. The computer readable storage medium as recited inclaim 20, wherein at least one of the subsequent commands relayed to the smart card reader prior to receiving the current command was a send Application Protocol Data Unit (APDU) command.

22. The computer readable storage medium as recited inclaim 17, wherein the current command and is a send Application Protocol Data Unit (APDU) command.

Images