Self-adding smart card reader system

Abstract

To provide a system, a device, and a method for adding support to an unsupported card reader and / or an access card.SOLUTION: An application downloaded from a computer server controls a device to recognize whether a connected card reader is an unsupported card reader or whether an unsupported card is supplied to the connected card reader. The application automatically generates support for the unsupported card reader or the unsupported card by reading identifying information from the unsupported card reader or the unsupported card, modifying an existing driver support file by adding the identifying information to the existing driver support file to create a modified driver support file, and testing the unsupported card reader or the unsupported card by using the modified driver support file. If the tests are successful, the application then supplies the modified driver support file to other devices separate from the printer.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] TECHNICAL FIELD The systems and methods herein relate generally to card readers and access cards such as smart card readers, and more specifically to systems that add support to unsupported card readers and / or access cards. Summary of the Invention [Problem to be solved by the invention]

[0002] Access to various devices can be restricted to authorized users in a variety of ways. For example, a user may be required to enter a password or a valid username into a user interface in order to gain access to various devices. However, these access restrictions sometimes lack security, resulting in unauthorized use of such devices.

[0003] Physical access cards (such as smart cards) offer a high level of user access control because a user must physically present a valid physical access card to a card reader to gain access to a device. In some situations, the access card may be the only item needed to gain access to a restricted device, eliminating the need for a user to remember a password or username. In other situations, multi-factor authentication techniques may be used in combination with the access card (and / or password, etc.).

[0004] Many manufacturers produce access cards and card readers, and many vendors modify such elements in their own ways. Although standards bodies attempt to govern such differences between smart cards and card readers, the differences between different smart card products and vendors make adding an unsupported card reader or card to an existing system a time-consuming and costly task.

[0005] To address the above situation, the system herein includes an access control device (a printer is used as an example device below) with an attached card reader, any computer that communicates with the printer over a computer network, and a computer application (app) maintained by a computer server.

[0006] The computer server is configured to provide an app to the printer. The app is configured to control the printer to recognize whether the connected card reader is an unsupported card reader or whether an unsupported card has been provided to the connected card reader. In one embodiment, the printer or other access control device can only operate using supported access cards and card readers. Supported access cards and card readers are access cards and card readers identified in at least one driver support file stored in the printer, and unsupported access cards and unsupported card readers are access cards and card readers not identified in one driver support file stored in the printer.

[0007] The app is configured to automatically modify the driver support file to communicate with the unsupported cards and unsupported card readers by reading identifying information from the unsupported cards and unsupported card readers, modifying at least one driver support file by adding the identifying information to the driver support file, testing the unsupported cards and unsupported card readers with the modified driver support file, and providing the modified driver support file(s) to another device separate from the printer. This identifying information from the unsupported cards and unsupported card readers may be, for example, a vendor ID, a product ID, an ATR string for reset of the unsupported cards, etc.

[0008] The app facilitates the testing process by first storing backups of existing driver support files for supported access cards and card readers. The app then adds identifying information for unsupported cards and unsupported card readers to the existing driver support files to generate modified driver support files, and uses the modified driver support files to facilitate a series of communications and operational tests on the unsupported cards or unsupported card readers (e.g., through a system administrator). If the tests fail, the app deactivates the modified driver support files and reactivates the backups of the existing driver support files. However, if the tests pass, the app leaves the backups of the existing driver support files inactive, and the existing driver support files are replaced with the modified driver support files.

[0009] The app performs a process of providing the modified driver support file(s) to other devices separate from the printer by creating a downloadable clone file from the modified driver support file(s) and sharing the downloadable clone file with the other devices separate from the printer over a computer network, so that all future presented access cards and card readers (having the same identification information as the unsupported cards and unsupported card readers) can become supported access cards and card readers on all other devices that share the clone file.

[0010] Various methods herein also provide an app to an access control device (such as, again, an exemplary printer). These methods then use the downloaded or resident app to control the printer to recognize whether the connected card reader is an unsupported card reader or whether an unsupported card has been provided to the connected card reader. Once this is done, the app can automatically, manually, or semi-automatically initiate the process of generating support for the unsupported card or card reader.

[0011] More specifically, the app automatically (or manually by a system administrator) modifies driver support files for unsupported cards and unsupported card readers by reading identification information from the unsupported cards and unsupported card readers, verifying one or more modified driver support files that include the identification information of the unsupported cards and unsupported card readers, and testing the unsupported cards and unsupported card readers with the modified driver support file(s). If the testing is successful, the app provides the modified driver support file(s) to other devices separate from the printer, so that the unsupported cards and unsupported card readers are recognized on all external devices for which the modified driver support files have been provided.

[0012] The testing process is facilitated by the app first storing a backup of the existing driver support file before any changes are made to the existing driver support file. The app then adds identifying information from the unsupported card or unsupported card reader to the existing driver support file to generate a modified driver support file, and uses the modified driver support file to facilitate a series of communications and operational tests of the unsupported card and unsupported card reader. If the test fails, the modified driver support file is deactivated and the backup of the existing driver support file is reactivated. However, if the test passes, the backup of the existing driver support file remains deactivated.

[0013] The process of providing the modified driver support file(s) to the other device separate from the printer is performed by the app providing a clone file over a computer network. This clone file is then shared over the computer network with the other device separate from the printer. The access cards and card readers having the identification information of the unsupported cards and unsupported card readers then become supported access cards and card readers on the other device separate from the printer through the operation of sharing the clone file.

[0014] These and other features are described in or are apparent from the following detailed description. [Brief description of the drawings]

[0015] Various example systems and methods are described in detail below with reference to the accompanying drawings.

[0016] [Figure 1] FIG. 1 is a schematic diagram illustrating a device herein.

[0017] [Diagram 2] FIG. 2 is a schematic diagram showing a display screen provided by the device herein. [Diagram 3] FIG. 3 is a schematic diagram showing a display screen provided by the device herein.

[0018] [Figure 4] FIG. 4 is a flow diagram of various methods herein.

[0019] [Figure 5A] FIG. 5A shows two parts of the same flow diagram for various methods herein. [Figure 5B] FIG. 5B shows two parts of the same flow diagram for various methods herein.

[0020] [Figure 6] FIG. 6 is a schematic diagram illustrating the system herein.

[0021] [Figure 7] FIG. 7 is a schematic diagram illustrating a device herein.

[0022] [Figure 8] FIG. 8 is a schematic diagram showing a device of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0023] As mentioned above, due to the differences between different smart card products and vendors, adding unsupported card readers and unsupported access cards (sometimes referred to herein as smart card products for simplicity) to an existing system is a time-consuming and costly task. Because a technical expert must manually modify the driver support files to communicate with the unsupported smart card product, the time spent obtaining the necessary vendor and product information, as well as the time spent testing and installing the driver support files for the new smart card product, results in significant time delays and costs for the introduction of the new smart card product.

[0024] In one simplified example, a card reader manufacturer may want to add one of its accessories (e.g., an access card or card reader) to a list of supported accessories as an item that can be connected to a product device (e.g., a multifunction printer, etc.). Traditionally, the accessory manufacturer contacts a representative at the product device manufacturer and manually provides the product device manufacturer with the communication and operation data of the new accessory. The product device manager then embarks on a lengthy and expensive manual process (statement of work, assignment agreements, confidentiality disclosure agreements, license transfers, etc.) to create, test, install, and document modified driver support files, firmware, etc. so that the new accessory functions smoothly when used with the product device. This process can take, for example, 3-9 months, or even years, and is very costly if new drivers or middleware are required.

[0025] In consideration of such problems, the present disclosure presents a system and method that fully or partially automates the process of adding support for unsupported access cards and unsupported card readers that occur in an access control device when they are first presented to the access control device. Specifically, a resident firmware or a downloadable app can be used in the access control device to capture card reader or card information, allow a user to supplement such information, and create a modified driver support file that includes the new device data set. The modified driver support file is then activated and the user is stepped through a validation process. Once validation is complete, the application converts the driver support file into an installation file for distribution to other devices. Finally, the application automatically reports the newly added device information to a repository for use in documents or other applications. This dramatically reduces the time delay and expense of manually modifying driver support files for such access cards.

[0026] The systems and methods herein provide user-driven new technology that improves the process of adding new card readers and access to existing products (e.g., available at the point of need by a customer, analyst, vendor, or accessory partner). This allows for dramatically faster and more responsive delivery times (minutes) to get access cards and card readers ready for use compared to the current remote manual customization process (3-9 months), as well as lower costs than current customization processes. Additionally, these methods and systems can use machine learning to discover which card readers and card vendors and device models are being or have been used with existing devices, something that may not be easily tracked for large multinational manufacturers with many diverse devices. Additionally, the systems and methods herein reduce the need for customization personnel, allowing freedom to do more profitable customization, and potential sales revenue based on the sale of apps used to create modified driver support files.

[0027] As shown in Figure 1, for example, the systems and methods herein are used with an access control device 120. Although a printer is used in many respects herein as an exemplary access control device 120, any device having access control therein may be used with the systems and methods herein, including scanners, facsimile machines, Internet portals, self-service kiosks, shared computers, secure computers, vehicles, robotic devices, secure physical storage devices, gaming systems, home appliances, entertainment systems, and the like, as well as multifunction devices (MFDs) having one or more of the foregoing components. The access control device 120 shown in Figure 1 is intended to represent all such devices and similar devices.

[0028] Further, in the systems herein, the computer 100 may be arranged to communicate with the access control device 120 via a computer network 202. At least one computer application (app 110) and an access card / card reader database 102 are maintained by the computer server 100. For example, the app may be one maintained in an app gallery, the computer may be a service engineer's computer that remotely distributes software updates to devices that include the app, or a computer / server that distributes software updates to devices, etc.

[0029] Regardless of the function, type, or nature of the access control devices 120, for access control, these devices use a card reader 122 to read an access card 124, and in most circumstances, access to the access control device 120 is granted only if a valid (supported) card 124 is presented to a valid (supported) card reader 122. The embodiments herein allow new, previously unsupported, unsupported card readers 122 and unsupported cards 124 to be easily added to such devices 120, and these systems / methods help modify the driver support files to communicate with the new cards 124 and card readers 122.

[0030] More specifically, the app 110 may be resident on the access control device 120 in firmware or pre-installed programs or software (e.g., apps, etc.), or the computer server 100 may download the app 110 to the access control device 120. In one embodiment, the app may be provided upon request (possibly for a fee) by support personnel or other users, and once downloaded, the app 110 may be automatically installed on the access control device 120. Thus, the app 110 may be a purchased app or a feature included in the device firmware / software, and all such sets of computer instructions are referred to herein as "apps" for ease of explanation.

[0031] The functionality of the app 110 may be accessible, for example, on a device web user interface (UI) where a system administrator can remotely log into the device, navigate to an authentication configuration web page, and select that they wish to modify one of the app's auxiliary files (e.g., the smartcard.xml file). This allows the system administrator to download a smartcard package that may include, for example, 1) a smartcard.xml file, 2) a file listing the ATRs that have been attempted on the device (including unsupported cards), and 3) a schema file used to edit the .xml file.

[0032] More specifically, drivers are used to allow a device to communicate with peripherals, but drivers require driver support files 126 to operate properly. One example of a driver support file 126 is the smartcard.xml file, which is a "whitelist" file that contains 1) a list of approved card ATRs, 2) driver support files that must be loaded to communicate with the card, 3) a description of the card, etc.

[0033] The app 110 is configured to assist the access control device 120 when an unsupported (unknown) card reader 122 is connected to the access control device 120 or when an unsupported (unknown) card 124 is provided to a supported existing connected card reader 122. Supported card readers 122 and cards 124 are those identified in at least one existing driver support file stored in the driver support file 126 of the access control device 120, and unsupported card readers 122 or cards 124 are those not identified in at least one driver support file stored in the driver support file 126 of the access control device 120. Representative examples of the driver support file 126 in this specification include all support files and driver support file execution / communication files, installation files, etc., even if not separately illustrated or described in this specification.

[0034] Thus, when a new card reader 122 is physically added or attached (e.g., newly wired or newly plugged into a standardized port such as a Universal Serial Bus (USB) port) or when a new card 124 is provided to an existing supported card reader 122, the card reader 122 and / or card 124 is queried by the access control device 120 and the identity of the card reader 122 or card 124 is read (e.g., using a standard protocol such as Standardized Chip Card Interface Device (CCID)). If the card reader 122 and / or card 124 is identified in any of the existing driver support files 126 of the access control device 120, at least one of the driver support files 126 already contains details of the communication protocol and other communication settings, allowing data to be passed between the access control device and the card 124 via the card reader 122 without any other user action being required.

[0035] In other words, the driver support file 126 of the access control device 120 is preloaded (or updated in some manner) to include software (e.g., communication instructions and protocols, etc.) that allows the access control device 120 to communicate with products (e.g., card readers, cards, etc.) manufactured by a first device manufacturer. However, the existing driver support file 126 may not allow communication with products (e.g., card readers, cards, etc.) manufactured by a different manufacturer. Alternatively, the driver support file 126 may be able to hold communication information for a first class or type of device, but may not be able to hold communication information for another class or type of device. As mentioned above, traditionally, technical experts must manually address such situations, which can be expensive and take months.

[0036] Thus, if the type, brand, model, etc. of the card reader 122 and / or card 124 is not identified by any of the existing driver support files 126, the access control device 120 cannot communicate with the new card reader 122 or new card 124. With this in mind, the systems and methods herein facilitate a process of automatically adding information to the existing driver support file 126 so that the access control device 120 supports the card reader 122 and card 124, thereby avoiding the traditional need for technical experts to modify the driver support file and the associated costs and time delays. In fact, the app 110 can be free or low cost, and the card reader 122 or card 124 can support new devices and new cards in minutes rather than months.

[0037] In general overview, the app 110 is configured to automatically modify an existing driver support file to communicate with the unsupported card reader 122 or unsupported card 124 by reading identifying information from the unsupported card reader 122 or unsupported card 122, modifying the driver support file 126 by adding the identifying information read from the unsupported card reader 122 or unsupported card 124 to the driver support file 126, testing the unsupported card reader 122 or unsupported card 124 using the modified driver support file 126, and if the modified driver support file 126 passes the testing process, providing the modified driver support file 126 to other devices 130, 132 separate from the access control device 120.

[0038] More specifically, the app 110 can discover identifying information from the card reader 122 or card 124, such as the vendor ID (VID), product ID (PID), card reset response (ATR) string, device type, device manufacturer or family, etc., to reveal detailed identifying information of the card reader 122 or card 124. Once this identifying information is detected by the app 110, it can be optionally presented to the user so that the user can verify if the discovered information is correct. The user can manually complete the identifying information, or the identifying information can be automatically completed with matching information from an external database. This can also be useful when the app 110 cannot automatically detect all the necessary identifying information that the user may possess through product documentation or other knowledge bases.

[0039] 2 shows an example of a display screen 150 that may be provided to confirm, modify, or add information to assist the app 110 in adding support for a new card reader 122 or card 124. Specifically, FIG. 2 shows captured data 152 and data 154 that the user is requested to confirm or supplement. Specifically, the user may simply accept the data 158 that is automatically found in the remote database, or the user may modify / complement the requested data 154 in a manual mode 156.

[0040] For example, in automatic mode 158, the app can connect to a card reader database (e.g., item 102 in FIG. 1, or another database maintained separately from the access control device 120) and the app can search database 102 for card type and description data 154 based on the captured data 152. In response to the search, the app receives such data and automatically populates the card type and description data fields shown under 158 in FIG. 2. This automatically obtained data can be manually supplemented / corrected by the user in the fields under 156 in FIG. 2.

[0041] 2 to one or more files (e.g., extensible markup language (XML) files) of the driver support files 126. If multiple driver support files 126 are modified, each modified driver support file 126 is individually and multiple tested to determine which modified driver support file 126, if any, works better with the new card reader 122 or card 124.

[0042] Before actually testing the modified driver support file(s) 126, the app 110 stores a backup of the existing driver support file (e.g., a backup of the existing driver support file). The app 110 then uses the modified driver support file to facilitate a series of communication and operation tests on the new card reader or new card. The app 110 either automatically executes the test routines or outputs a message to the user (e.g., a system administrator) to do so, indicating to the user the tests required. For example, the connection to the new card reader 122 can be tested automatically or manually by determining whether it can send and receive commands and data. The new card can be tested by determining whether an authentication string can be read, whether a scan to email can be performed, whether a scan to home can be performed, etc. The results of the tests can be reported to the user using the exemplary display screen 160 shown in FIG. 3, where the different tests 162 facilitated are shown along with the test results 164 (pass or fail).

[0043] If the test of the modified driver support file 126 fails, then if multiple driver support files 126 have been modified, then the next modified driver support file 126 can be tested. If none of the modified driver support files 126 pass a sufficient number of tests (all or less than all tests may be considered acceptable), then the app 110 must revert to the existing driver support file(s) 126, and thus the app 110 deactivates the modified driver support file(s) 126 and reactivates the backup of the existing driver support file(s) 126.

[0044] However, if the minimum number of tests are passed (again, in some cases all tests must be passed), then the tests for the particular modified driver support file 126 may be considered to have passed, which allows the app 110 to approve the modified driver support file 126. If the modified driver support file 126 passes the tests, then the app 110 deactivates the backup of the existing driver support file 126, as the backup is replaced with the modified driver support file 126.

[0045] The app 110 executes a process of providing the modified driver support file to other devices 130, 132 separate from the access control device 120 by creating a clone file from the test-approved modified driver support file 126. The app 110 can share the clone file with other devices 130, 132 separate from the access control device 120 over the computer network 202 by peer-to-peer communication or server-based download during regular updates or through push interactions. In another alternative, the app 110 can provide the test-approved modified driver file 126 to the module manufacturer 104 over the computer network 202. In these implementations, the app 110 instructs the module manufacturer 104 to create a downloadable module (DLM) with the test-approved modified driver file 126 and instructs the module manufacturer 104 to share the DLM with other devices 130, 132 during regular updates or through push interactions. A clone file or DLM differs from a modified driver support file 126 because the clone file further includes instructions that cause the modified driver support file 126 to be automatically installed on the device to which it is downloaded, as well as other necessary instructions that cause various devices to utilize the modified driver file 126.

[0046] The fact that all devices 120, 130, 132 are connected over the network 202 allows for distribution of modified drivers (e.g., using fleet orchestrator). Thus, the network 202 shown in Fig. 1 allows for manual distribution of modified driver clone files or DLMs as well as automatic distribution of clone files or DLMs. Thus, any card reader presented in the future (with the same identification as the unsupported card reader 122 or unsupported card 124) can become a supported card reader 122 on all other devices 130, 132 with which the module manufacturer 104 shares the DLM (or clone file).

[0047] FIG. 4 is a flow diagram illustrating an exemplary method herein. At item 300, the methods maintain an app on a computer server. At item 302, the methods provide the app from the computer server to an access control device (e.g., a printer, a scanner, a kiosk, an MFP, etc.). Then, at item 304, the methods use the downloaded app to check whether an unsupported card reader is connected to the access control device or whether an unsupported card is provided to a connected card reader. Specifically, the app is configured at item 304 to check whether any of the existing driver support files contain information about the connected card reader or the provided card. If they do not, the app automatically initiates a process to generate support for the unsupported card reader or the unsupported card, as shown at items 306-328 below. In other alternatives, a system administrator may be given the choice of whether to run the process to generate support, and thus the decision to generate support may be fully manual, fully automatic, or a mixture of the two.

[0048] More specifically, as shown in item 306, the app reads identification information from the unsupported card reader or card. This allows the app to discover identification information such as product ID, vendor ID, and reset response (ATR) string of the unsupported card. Then, in item 308, the app uses the identification information discovered in item 306 to determine whether any of the existing drivers on the access control device can handle the unsupported card reader or card. In one embodiment, the app can determine whether to perform a process to modify the existing driver support file for a particular driver based on the similarity between the identification information from the unsupported card reader or card and the identification information of the card reader and card handled by the existing driver support file before modification.

[0049] More specifically, in item 308, the existing driver support files of the access control device are known to handle card readers and cards of a particular type or family, or are known to handle card readers or cards of a particular manufacturer or industry segment. If an unsupported device or card is found to be of the same type, family, or manufacturer / industry segment origin in item 306, the driver is considered to be potentially useful for the unknown card reader or card in item 308. Thus, for example, an existing driver support file that is more consistent with information about the type, family, manufacturer, or industry of the unsupported card reader or card has a higher degree of similarity compared to an existing driver support file that is less consistent with information about the unsupported card reader or card. In addition, external databases that contain driver support files that are not present in the access control device can also be checked in item 308 to determine whether they contain potentially useful drivers and associated driver support files for the unsupported device or card. If so, such potentially useful drivers and driver support files are downloaded by the app to the access control device in item 308 and made available for automatic correction.

[0050] If, at item 308, no potentially useful driver support files are found in the access control device or external database (not having sufficient similarity), processing continues to item 310, where a request to create a custom driver support file can be automatically or manually generated, and such a custom driver support file can be created using conventional methods, some of which are described above.

[0051] However, if at least one potentially useful driver support file having sufficient similarity is found in the access control device or external database in item 308, a backup of the existing driver support file(s) is created in item 312. The identifying information from the unsupported card reader or unsupported card generated in item 306 is then added to the existing driver support file in item 314 to generate one or more modified driver support files.

[0052] The modified driver support file is then tested in item 316. More specifically, in item 316, the methods automatically or manually test the unsupported card reader or card by facilitating a series of communication and operational tests of the unsupported card reader or card using the modified driver support file. Item 318 is a decision box for whether the test passed (e.g., the unsupported card reader or card was approved / verified using the modified driver support file) (whether the test passed or failed).

[0053] If the tests fail in item 318 (the modified driver support file(s) fail one or more tests), processing continues to item 320, where the modified driver support file(s) are deactivated and the backup of the existing driver support file is reactivated, after which a request for a custom driver support file can be generated automatically or manually in item 310.

[0054] However, if the test passes, processing continues from item 318 to item 322, where the backup of the existing driver support file is deactivated but retained, and the modified driver support file remains activated in place. Further, based on passing the test, processing continues, and the app then provides the modified driver support file to other devices separate from the access control device (as shown in items 324-328), such that the unsupported card reader or unsupported card is supported on all external devices for which the modified driver support file is provided.

[0055] The process of providing the modified driver support file to other devices separate from the access control device can be performed in a number of ways. In one embodiment, the app can provide the modified driver support file to the module manufacturer over a computer network, as shown in item 324. In item 324, the module manufacturer creates a downloadable module (DLM) having the modified driver support file. In an alternative embodiment, in item 326, the app can create a clone file of the modified driver support file. The clone file can be an exact copy of the modified driver support file or can be a copy that also includes additional instructions for use, installation, extraction, etc.

[0056] As shown in item 328, the DLM and / or clone file are then provided (downloaded or peer shared and installed) via a computer network to other devices separate from the access control device (e.g., other printers, other access control devices, etc.). Specifically, the DLM can be downloaded on demand, during an update, through a push process, etc., and / or the clone file can be shared through a peer-to-peer sharing process in item 328. Thus, all unsupported card readers or card readers having identification information for unsupported cards are supported by card readers on other devices that have downloaded and installed the DLM and / or clone file.

[0057] Figures 5A-5B show a narrower example of one embodiment of the methods and systems herein. As shown in Figures 5A-5B, at item 350, an analyst can license, download, and install a self-add card / card reader application onto an MFD. At item 352, an analyst can open the self-add card / card reader application, log in, and insert an unsupported card into an existing card reader or connect to a new unsupported card reader.

[0058] At item 354, the app can capture new card or card reader data and prompt for analysis of the requested data. As shown at item 356 (and FIG. 2 above), the analyst can select manual mode 156 and manually enter the requested data, or as shown at item 358, the analyst can select automatic mode 158 (FIG. 2), which causes the app to connect to the appropriate database from which it searches and receives the requested data (e.g., device type, device description, etc.) as shown in the fields below 158 in FIG. 2.

[0059] Item 360 is a decision box that determines whether the manually or automatically generated device type, device description, etc. may be supported by any driver support files (e.g., XML files) that may reside on the access control device 120 or be provided to the access control device 120 by the computer server 100. The driver support files may be of the same type, family, or manufacturer, and therefore may be usable with the new card reader or card. However, testing (as described below) is facilitated to ensure that a potentially useful driver support file is actually useful with the new card reader / card.

[0060] As shown in item 362, if a driver support file that may support the type or description found in items 356 or 358 is not found in the access control device 120 or in the computer server 100, a new driver support file is required and a message is displayed that the device type and / or description is not supported and customization should be requested.

[0061] On the other hand, if a driver support file exists in the access control device 120 (or a driver support file exists in the computer server 100 that can be downloaded to the access control device) that may support the type or description found in item 356 or 358, processing continues to item 364. In item 364, the potentially usable driver support file is downloaded and, if necessary, a backup of the existing copy of the downloaded or existing driver support file is created. Also in item 364, the downloaded or existing driver support file is modified by adding appropriate data (e.g., ATR string, PID, VID, etc.) to create a modified driver support file, and the modified driver support file is activated and ready for testing while the existing driver support file is deactivated.

[0062] In item 366, the app prompts the analyst to run a validation test, at which point the new card reader or card is tested with the modified driver support file. A series of communication and operation tests are also performed. Item 368 is a decision box regarding whether a minimum number (possibly all) of the tests have passed. If there are additional driver support file candidates that may be used with the new card reader or card, the subsequent steps may be delayed while the additional driver support file candidates are modified and tested. Thus, there may be many modified driver support files that pass the tests. However, if all of the driver support file candidates have failed the tests in item 368, the process proceeds to item 370, where the backup of the existing driver support file is restored as the active file, and the modified driver support file(s) that failed the tests are deactivated. Additionally, if none of the driver support files pass the tests in item 368, the process proceeds from item 370 to item 362, where a customized driver support file may be created.

[0063] However, if at least one of the modified driver support files passes testing, processing continues to item 372 (FIG. 5A continues to bubble B in FIG. 5B). In item 372 of FIG. 5B, any necessary driver support file modifications are finalized and the app sends all modified driver support files that passed testing to the module manufacturer, which creates a DLM for each modified driver support file that passed testing. In item 374, all DLMs are provided to the access control device, enabling the access control device to be fully operational with the card reader / card. Additionally or alternatively, clone files can be generated and peer shared, as shown in item 376.

[0064] In item 378, either the administrator or the app configures file distribution of the modified driver support file that has passed testing. The app then sends the modified driver support file and the user's contact information to the joint repository, as shown in item 380. In item 382, ​​the administrator or the app also configures distribution of the modified driver support file(s) to other access control devices using various fleet-wide distribution software and other selectable methods. As shown in item 384, the modified driver support file(s) and user data can be analyzed (possibly using an artificial intelligence (AI) process) in the joint repository that is used to automatically create a driver support file document or other application, for example, to discover which card readers and card vendors and device models are actively used with existing devices. Also, as shown in item 386, the modified driver support file(s) can be distributed to the access control devices as part of a future update release.

[0065] 6, the example systems and methods herein include various computing devices 200, 204 located at different physical locations 206. The computing devices 200, 204 may include print servers, printing devices, personal computers, etc., and communicate (operably connected to each other) via a local or wide area (wired or wireless) network 202.

[0066] 7 illustrates a computing device 200 that may be used with the systems and methods herein and may include, for example, a print server, a personal computer, a portable computing device, etc. The computing device 200 includes a controller / tangible processor 216 and a wired and / or wireless communication port (input / output) 214 operably connected to the tangible processor 216 and to a computer network 202 external to the computing device 200. The computing device 200 may also include at least one accessory functional component, such as a user interface (UI) assembly 212. A user may receive messages, commands, and menu options from and input commands via the user interface or control panel 212.

[0067] The input / output devices 214 are used for communication to and from the computing device 200 and include wired or wireless devices (of any form, whether now known or developed in the future). The tangible processor 216 controls various operations of the computing device. The non-transitory and tangible computer storage media device 210 (which may be optical, magnetic, capacitor-based, etc., as distinct from a transitory signal) is readable by the tangible processor 216 and stores instructions that the tangible processor 216 executes to enable the computing device to perform various functions, such as those described herein. Thus, as shown in FIG. 7, the body housing has one or more functional components that operate on power provided by a power supply 218 from an alternating current (AC) source 220. The power supply 218 may include a common power conversion unit, a power storage element (e.g., a battery, etc.), and the like.

[0068] 8 illustrates a computing device that is a printing device 204, which may be one of the access control devices described above and may include, for example, a printer, a copier, a multifunction machine, a multifunction device (MFD), etc. The printing device 204 includes many of the components described above, as well as at least one marking device (print engine(s)) 240 operably connected to a dedicated image processor 224 (which differs from a general purpose computer because it is specialized for processing image data), a media path 236 arranged to feed continuous or sheet media from a sheet supply 230 to the marking device(s) 240, etc. After receiving various markings from the print engine(s) 240, the sheet media may optionally pass through a finisher 234 that may fold, staple, sort, etc. the various printed sheets. Printing device 204 may also include at least one accessory functional component (e.g., scanner / document handler 232 (automatic document feeder, ADF)), which also operates on power supplied from external power source 220 (via power supply 218).

[0069] The one or more print engines 240 are intended to illustrate any marking device, whether now known or developed in the future, that applies marking material (toner, ink, etc.) to a continuous media or sheet of media, and may include, for example, devices that use a photoreceptor belt or an intermediate transfer belt, or devices that print directly to the print media (e.g., inkjet printers, ribbon-based contact printers, etc.).

[0070] Although some example structures are shown in the accompanying drawings, those skilled in the art will appreciate that the drawings are simplified schematic diagrams and that the claims presented below encompass many more (potentially less) features not shown but commonly utilized with such devices and systems. Accordingly, applicants do not intend that the claims presented below be limited by the accompanying drawings, which are instead provided merely to illustrate some ways in which the claimed features may be implemented.

[0071] Many computing devices have been discussed above. Computing devices including chip-based central processing units (CPUs), input / output devices (including graphic user interfaces (GUIs), memory, comparators, tangible processors, etc.) are well-known and readily available devices manufactured by manufacturers such as Dell Computers (Round Rock TX, USA) and Apple Computer Co. (Cupertino CA, USA). Such computing devices generally include input / output devices, power supplies, tangible processors, electronic storage memories, wiring, etc., the details of which are omitted here in order to focus on the salient aspects of the systems and methods described herein of card readers. Similarly, printers, copiers, scanners, and other similar peripherals are available from Xerox Corporation (Norwalk, CT, USA), the details of such devices are not described here in order to focus on brevity and the card readers.

[0072] As used herein, the term "printer" or "printing device" encompasses any device, such as a digital copier, bookbinding machine, facsimile machine, multifunction machine, etc., that performs a print output function for any purpose. Details of printers, print engines, etc. are well known and are not described in detail herein in order to keep this disclosure focused on the salient features presented. The systems and methods herein can encompass systems and methods that print in color, monochrome, or handle color or monochrome image data. All of the aforementioned systems and methods are particularly applicable to electrostatographic and / or xerographic machines and / or processes.

[0073] Further, the terms "automated" or "automatically" mean that once a process is initiated (by a machine or a user), one or more machines perform the process without further input from any user. In addition, terms such as "configured to" mean that a device is specifically designed to have specialized internal or external components that automatically perform specific operations or functions at particular points in the processes described herein, and such specialized components are physically shaped and positioned to perform the operations / functions specified at the process points shown herein (in some cases without any operator input or action). In the drawings herein, the same identification numbers identify the same or similar items.

[0074] It will be understood that the above-disclosed and other features and functions, or alternatives thereof, may be desirably combined into other different systems or applications. Various presently unanticipated or unprecedented alternatives, modifications, variations, or improvements may be subsequently made by those skilled in the art, which are also intended to be encompassed by the following claims. Unless specifically defined in the particular claim itself, the steps or components of the systems and methods herein cannot be implied or derived from any of the above examples to be limited to any particular order, number, position, size, shape, angle, color, or material.

Claims

1. A device, comprising: Processor and a functional component operatively connected to the processor; a user interface operatively connected to the processor; a connected card reader operably connected to said processor; a computer storage device operably connected to the processor; Equipped with the processor is configured to recognize whether the connected card reader is an unsupported card reader or whether an unsupported card is provided to the connected card reader; The processor, reading identification information from the unsupported card reader or the unsupported card; modifying an existing driver support file by adding said identifying information to said existing driver support file to create a modified driver support file; testing the unsupported card reader or the unsupported card with the modified driver support file; storing a backup of the existing driver support file prior to creating the modified driver support file; deactivating the backup of the existing driver support file and activating the modified driver support file; using the modified driver support file to facilitate a series of communications and operational tests on the unsupported card reader or the unsupported card; based on the test failing, deactivating the modified driver support file and reactivating the backup of the existing driver support file; maintaining the backup of the existing driver support file inactive based on the test being successful; providing the modified driver support file to another device separate from the device based on the modified driver support file passing the test; a device configured to automatically modify driver support files in the computer storage device to communicate with the unsupported card reader or the unsupported card by

2. The processor provides the modified driver support file to the other device, separate from the device. creating a clone file from the modified driver support file; Sharing the clone file with the other device, the other device being separate from the device, via a computer network; The device of claim 1 .

3. 2. The device of claim 1, wherein the processor is configured to determine whether to perform the modification of the existing driver support file based on a similarity between the identification information from the unsupported card reader or the unsupported card and identification information of card readers and cards that were handled by the existing driver support file before the existing driver support file was modified.

4. 2. The device of claim 1, wherein a supported card reader is a card reader identified in at least one driver support file stored on the device, and an unsupported card reader is a card reader not identified in at least one driver support file stored on the device.

5. The device of claim 1 , wherein the device can only operate using supported card readers and supported cards.

6. The device of claim 1 , wherein the identification information includes a vendor ID, a product ID, and an response to reset (ATR) string for the unsupported card.

7. 1. A system comprising: a printer having an attached card reader and including a computer storage device; a computer server in communication with the printer over a computer network; a computer application (app) maintained by the computer server; and Equipped with the computer server is configured to provide the app to the printer; The app is configured to control the printer to recognize whether the connected card reader is an unsupported card reader or whether an unsupported card is provided to the connected card reader; The application automatically controls the printer, reading identification information from the unsupported card reader or the unsupported card; modifying an existing driver support file by adding said identifying information to said existing driver support file to create a modified driver support file; testing the unsupported card reader or the unsupported card with the modified driver support file; storing a backup of the existing driver support file prior to creating the modified driver support file; deactivating the backup of the existing driver support file and activating the modified driver support file; using the modified driver support file to facilitate a series of communications and operational tests on the unsupported card reader or the unsupported card; based on the test failing, deactivating the modified driver support file and reactivating the backup of the existing driver support file; maintaining the backup of the existing driver support file inactive based on the test being successful; providing the modified driver support file to a device separate from the printer based on the modified driver support file passing the test; modifying driver support files in the computer storage device to communicate with the unsupported card reader or the unsupported card.

8. The app controls the printer to provide the modified driver support file to the other device separate from the printer. creating a clone file from the modified driver support file; sharing the clone file with the other device, separate from the printer, over a computer network; The system of claim 7 , configured to execute by:

9. 8. The system of claim 7, wherein the app is configured to control the printer to determine whether to perform the modification of the existing driver support file based on a similarity between the identification information from the unsupported card reader or the unsupported card and identification information of card readers and cards handled before the existing driver support file was modified.

10. 8. The system of claim 7, wherein a supported card reader is a card reader identified in at least one driver support file stored in the printer, and an unsupported card reader is a card reader not identified in at least one driver support file stored in the printer.

11. 8. The system of claim 7, wherein the printer can only operate using a supported card reader and a supported card.

12. The system of claim 7 , wherein the identification information includes a vendor ID, a product ID, and an response to reset (ATR) string for the unsupported card.

13. 1. A method comprising: Providing the app from a computer server to a device including a computer storage device; controlling the device by the app to detect an unsupported card reader or to detect an unsupported card provided to a connected card reader of the device; By the app, reading identification information from the unsupported card reader or the unsupported card; modifying an existing driver support file in the computer storage device by adding the identifying information to the existing driver support file to create a modified driver support file; testing the unsupported card reader or the unsupported card with the modified driver support file; storing a backup of the existing driver support file prior to creating the modified driver support file; deactivating the backup of the existing driver support file and activating the modified driver support file; using the modified driver support file to facilitate a series of communications and operational tests on the unsupported card reader or the unsupported card; based on the test failing, deactivating the modified driver support file and reactivating the backup of the existing driver support file; maintaining the backup of the existing driver support file inactive based on the test being successful; providing the modified driver support file to another device separate from the device based on the modified driver support file passing the test; and automatically generating support for the unsupported card reader or the unsupported card by

14. Providing the modified driver support file to the other device separate from the device includes: creating a clone file from the modified driver support file; Sharing the clone file with the other device, the other device being separate from the device, via a computer network; The method of claim 13 , wherein the method is performed by:

15. 14. The method of claim 13, further comprising determining whether to perform the modification of the existing driver support file based on a similarity between the identification information from the unsupported card reader or the unsupported card and identification information of card readers and cards handled before the existing driver support file was modified.

16. 14. The method of claim 13, wherein a supported card reader is a card reader identified in at least one driver support file stored on the device, and an unsupported card reader is a card reader not identified in at least one driver support file stored on the device.

17. The method of claim 13, wherein the device can only operate with supported card readers and supported cards.

Images