Abstract:
Methods and associated systems for enterprise-wide issuance of identification cards. A single enterprise server component and a plurality of card issuance machine controller components are distributed over an enterprise network. Each card machine controller component controls one or more devices for the production of identification cards including, for example, embossed and/or digitally encoded information. The single enterprise server component acts as a server to route the card issuance requests to the proper card machine controller component on behalf of client programs at each location used to request the production of an identification card. The enterprise server component further provides enhanced security and encryption to provide requisite security in the exchange of sensitive information in the production of such identification cards. An administrative component, which can be used anywhere on the network, provides centralized management of common data used by the server, card machine controllers and client programs in the production of identification cards. The administrative component also provides for centralized administration of the plurality of PCs, card issuance machines and software components to permit easy re-assignment of future production requests for purposes of management and/or for end user convenience.

Description:
BACKGROUND OF THE INVENTION  
         [0001]    1. Field of the Invention  
           [0002]    The invention relates to production and issuance of embossed and/or encoded identification cards and more specifically relates to an enterprise-wide system for providing centralized control and management for issuance of such identification cards.  
           [0003]    2. Discussion of Related Art  
           [0004]    Issuance of identification cards is a critical task in many commercial and other endeavors. Exemplary of such endeavors are credit card issuance, debit card issuance, frequent customer identification card issuance, security card issuance, etc. Such identification cards often include embossed identification information and or digitally encoded identification information. Such digitally encoded identification information may be recorded on the identification card in a magnetic stripe or other storage medium as well as in so-called “smartcard” chips embedded within the identification card.  
           [0005]    Generation of such identification cards has long been the exclusive domain of complex, costly, large devices capable of both embossing the cards as well as programming digital identification information. In more recent years, devices for issuance of such identification cards have dramatically fallen in price as well as shrunken in physical size (“footprint”). For example, the model 150i embossing and encoding machine produced by DataCard Corp. of Minneapolis is a relatively low-cost device having a relatively small footprint (i.e., tabletop or desktop configuration). The DataCard 150i embossing and encoding machine is capable of producing such cards under control of an externally attached computing system such as a personal computer (“PC”).  
           [0006]    Although older, larger devices were capable of producing much higher volumes of identification cards, the low-cost and small footprint of the DataCard 150i makes it possible to distribute such functions into more convenient localized facilities. Localized issuance of such identification cards is often referred to in the industry as “instant issuance.” The paradigm of instant issuance allows for an identification card to be made while the user or customer waits rather than waiting days or weeks for a centralized facility to produce such card and ship the produced card to the end user.  
           [0007]    Although devices such as the DataCard 150i enable the decentralized issuance of identification cards, computing systems to permit such decentralized issuance of cards while maintaining centralized control of the information embossed and/or encoded on such cards were not available.  
           [0008]    The computing system called CardWizard® was produced and marketed by Dynamic Solutions International of Colorado in 1997. This computing system is comprised of a collection of interrelated software components designed to work in a distributed client/server model within a single location. Although designed in accordance with a single location client/server software model, when applied to a broader multi-location enterprise environment, a number of problems arise in this and other current solutions.  
           [0009]    1. Financial identification cards require usage of highly sensitive data used for encryption calculations that produce values that are embossed and encoded on identification cards. This data is referred to as “encryption keys.” To simplify software installation and provide greater security, large banking and other large financial enterprises prefer these encryption keys be stored at a single secured location within the network rather than at each location that has a card issuance machine. The original version of CardWizard®, like other present solutions, required these encryption keys to be stored at each location that had a card issuance machine.  
           [0010]    2. Administration and management problems arise where an enterprise may have different capabilities at each of several decentralized locations. For example, a large financial institution may issue ATM cards in one location and debit cards in a different location. It is therefore important for enterprise solutions to be easily configured, administered and managed to permit production of identification cards to be performed at a most appropriate location.  
           [0011]    3. Problems arise when decentralized locations, which cannot afford the cost of an issuance machine, wish to issue cards on an issuance machine located at another location within the network.  
           [0012]    4. Problems arise when locations want card production requests stored in a queue that allows cards to be produced at a later time at either their location or another location within the enterprise.  
           [0013]    5. Only a single card issuance machine is supported on a single PC.  
           [0014]    6. Support of external software processes in lieu of card issuance machines was not available. For example, rather than producing the card immediately at a card machine, it may be desired to route the card information to another computer system on the network for some other type of processing.  
           [0015]    7. Administration of card issuance machines, users, system access and production reporting and management of system options had to be done at each location rather than centrally.  
           [0016]    8. There are duplicate databases throughout the network, which increases exposure to fraudulent activities and required more systems administration activities to synchronize or replicate updated information.  
           [0017]    9. Having “self contained” card issuance systems at a single location presents the risk of someone stealing the equipment and potentially using it to make illegal financial cards.  
           [0018]    It is evident from the above discussion that a need exists for improved enterprise coordination in the production and issuance of embossed and/or encoded identification cards in a decentralized manner.  
         SUMMARY OF THE INVENTION  
         [0019]    The present invention solves the above and other problems, thereby advancing the state of the useful arts, by providing improved administration and management of decentralized identification card issuance in an enterprise-wide environment. In particular, the present invention includes features for using and managing multiple identification card production machines distributed throughout the enterprise and for routing of production requests for identification cards anywhere in the enterprise network.  
           [0020]    More specifically, a card machine controller component (“CMC”) resides within a PC on the enterprise network and acts as a server at its physical location for connecting various configurations of card issuance machines and/or external software processes. Card issuance machines include devices such as the DataCard 150i while external software processes include tasks such as writing card information to a disk file or sending card information to another software application within the enterprise network. Multiple such card machine controller server components may reside in PCs dispersed throughout the enterprise network. The card issuance machine controller component communicates with client processes within the enterprise for purposes of producing identification cards at that location.  
           [0021]    As used herein, card issuance components includes card issuance machines such as DataCard products as well as other devices for creating identification cards and further includes external software processes for application specific custom software modules to create identification cards outside the scope of a particular machine. Further, as used herein, card issuance controller and CMC refer to a control module of the present invention that controls low level operations of one or more card issuance components.  
           [0022]    An administration component of the present invention interfaces with the single enterprise server component to coordinate access to centralized information required in production of cards and to permit enhanced management of the distribution of card production requests to appropriate card issuance machines in the enterprise.  
           [0023]    An aspect of the present invention enables a user-friendly graphical user interface to manage the definition of the entire enterprise&#39;s card production network. This definition includes configuration of each decentralized location including, but not limited to, the users, PCs, card issuance machines, which types of cards are allowed to be produced by a location and/or user and where each type of card will be produced. The graphical user interface (“GUI”) allows an administrator to change the configuration as needed. For example, if it is desired to have future production of a type of card at a different card issuance machine, the administrator can use a simple drag and drop operation to effectuate this change.  
           [0024]    Another aspect of the present invention enables a user-friendly graphical user interface to manage the assignment and re-assignment of pending card production requests to appropriate card issuance machines distributed in the enterprise. The GUI allows an administrator to drag and drop card issuance requests presently assigned to a first card issuance machine to a different machine. This feature simplifies the management of the enterprise-wide production of identification cards by permitting the administrator to re-assign a production request to another issuance machine. For example, if a first issuance machine becomes inaccessible due to failure or is otherwise overloaded with requests, another machine at the same location or at another convenient location may be assigned the task of producing a queue of such requested cards.  
           [0025]    A still further aspect of the present invention lies in centralized security for the decentralized card issuance machines of the enterprise. A central administration component provides a central point of control for security including user ID&#39;s and related password protection for use of the card issuance machines and encryption of sensitive information exchanged between the enterprise server component and the distributed card machine controller components.  
           [0026]    The above, and other features, aspects and advantages of the present invention will become apparent from the following descriptions and attached drawings. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0027]    [0027]FIG. 1 is a network diagram showing a sample enterprise configuration of the present invention. The diagram shows physical devices such as PCs and card issuance machines in addition to the various software components installed within each PC.  
         [0028]    [0028]FIG. 2 is block diagram showing the various software components in an enterprise card issuance environment using the present invention. The diagram shows communication paths between the various components.  
         [0029]    [0029]FIG. 3 is a software flowchart of the operation for the enterprise server component for the present invention.  
         [0030]    [0030]FIG. 4 is a software flowchart showing the enterprise server component&#39;s initialization logic.  
         [0031]    [0031]FIGS. 5 through 10 are exemplary graphical user interface display screens used in conjunction with the methods and structures of the present invention. 
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0032]    While the invention is susceptible to various modifications and alternative forms, specific embodiment thereof has been shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that it is not intended to limit the invention to the particular form disclosed, but on the contrary, the invention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.  
         [0033]    [0033]FIG. 1 is a block diagram of a system  100  in accordance with the present invention. System  100  depicts a number of exemplary elements of the enterprise card issuance system of the present invention. Those skilled in the art will recognize a wide variety of equivalent configurations and topologies in which the present invention may be advantageously applied. Specifically, the present invention accommodates a scaleable enterprise network utilizing client/server programming techniques well known to those skilled in the art. In such client/server programming paradigms, client processes and associated server processes may be co-resident within particular computing devices or may be widely distributed among a variety of computing devices of the enterprise communicating via a network communications medium and protocol. As shown in FIG. 1, all elements preferably communicate via TCP/IP communications network  150 .  
         [0034]    Within the present invention PCs are defined as members of “PC Groups”. Normally a PC group consists of PCs residing at the same physical location. However, a PC group may consist of PCs located at different physical locations. In FIG. 1, there are three PC groups defined—“Central Operations”  162 , “Location A”  160  and “Location B”  164 .  
         [0035]    Enterprise server software component  130  residing in PC  110  at Central Operations location  162  provides centralized management and control for administration of system  100  in accordance with the present invention. The management and administration services provided by enterprise server  130  are accessed by administrative client  132  operable in PC  106 , PC  110  and PC  112  in the various locations  160 ,  162  and  164 , respectively. More specifically, administrator software component  132  provides a graphical user interface client process for an administrative user to centrally control, configure, and manage system  100 .  
         [0036]    PCs  102  through  108  and PCs  112  through  116  generally provide a client process interface  134  for on-site requests for issuance of identification cards. PCs  106 ,  108  and  116  further provide a direct interface to card issuance machines  120  through  126 . The interface to such card issuance machines  120  through  126  is provided by card machine controller component  136  operable within PCs  106 ,  108  and  116 .  
         [0037]    As noted above, those skilled in the art will recognize that the specific topology and configuration of system  100  in FIG. 1 is intended merely as exemplary of any number of similar enterprise configurations. In particular, any number of PCs may be assigned to a particular PC group and any number of PC groups may be defined in the enterprise. The preferred physical locations of PCs is simply that which is convenient and beneficial for the enterprise and its customers. Similarly, the physical locations of card issuance machines  120  through  126  is that which is convenient for issuance of cards by the enterprise organization and further convenient for the enterprise customers.  
         [0038]    [0038]FIG. 1 also indicates that each of card machines  120  through  126  may be designated for production of a particular type of identification card. For example, in a financial or banking enterprise application, particular card issuance machines may be designated for issuance of ATM cards while other card issuance machines may be designated for issuance of ATM or debit cards. Card issuance machine  120  is designated in the exemplary enterprise of FIG. 1 as primarily a debit card issuance machine while card issuance machines  122 ,  124  and  126  are designated as primarily ATM card issuance machines. As above, the particular designation of each machine and its physical locations in the enterprise is that which is convenient and useful for the enterprise and its customers. Administrative, management and configuration functions provided by enterprise server software component  130  on PC  110  permit such flexibility in the location and designation of devices distributed in the enterprise.  
         [0039]    Where FIG. 1 shows the overall architecture of an exemplary topology of an enterprise, FIG. 2 is a block diagram showing the functional relationship among all elements and processes operable within an enterprise exemplified in FIG. 1. An optional custom interface software component  152  is generally operable in conjunction with host system  202  and is preferably physically co-resident with enterprise server software component  130  in a physical location  200  designated as the central operations location. Remote locations are shown an exemplary single remote location  220  on FIG. 2.  
         [0040]    Optional security processor hardware element  208  operates in conjunction with enterprise server software component  130  to provide requisite storage of a financial institution&#39;s encryption keys and the encryption/decryption processes required by the enterprise server  130 . Encryption keys and related encryption rules can be maintained by an administrative user using the key manager element  138 . These encryption keys and encryption rules are stored in either the optional security processor  208  or the card format database  214 .  
         [0041]    The network configuration database  210  contains information used by the enterprise server software component  130  for management of the network and routing of card production requests to the proper card issuance device  236  at a remote location  220  in the network.  
         [0042]    The card format database  214  contains definitions of various types of identification cards (also referred to herein as “card type” or “card type information” or “card format”) available for production within the enterprise. Each production request includes a corresponding card type indicating the type of card for which the information is to be produced. Each definition provides the rules and specifications for embossing and encoding the card. These rules are created and maintained by the designer component  154  and utilized by the enterprise server component  130  during the fulfillment of production requests submitted by client components  134 ,  140 ,  142  and  150 . In particular, standard client component  134  submits requests to produce a particular format of card. Such requests are produced by a user filling in a form on a PC in a remote location. Batch input client  140  generates a batch of card requests from a prepared file or database. Repin component  142  generates requests to change a personal identification number (“PIN”) on a previously issued identification card. Such requests are typically processed at a special terminal device designed for the purpose of changing the PIN encoding on the card.  
         [0043]    The CMC device “request queues” database  216  contains a collection of queues for each defined device assigned to the card machine controllers in the enterprise. These queues provide temporary storage of card production requests received from client components  134 ,  140 ,  142  and  150  that are directed to a specific card issuance machine  236  or external software process  238 .  
         [0044]    Optional production queue database  212  contains information used by the enterprise server software component  130  for temporary storage of card production requests received from client components  134 ,  140 ,  142  and  150  that are directed to a specific production queue. Requests held in this production queue database  212  are not produced until requested by a user using the Administrator software component  224  at a remote location  220 . At that time, the card will be produced at a card issuance device  236  attached to a CMC software component  136  located at a remote location  220  specified in the network configuration database  210 .  
         [0045]    These centralized host based elements communicate via standard TCP/IP communications media and protocols with elements physically resident at each location  220 . A typical location  220  optionally may include a number of custom client user interface elements  150  and/or standard client user interface elements  134 ,  140  and  142 . Client user interface elements  150 ,  134 ,  140  and  142  provide the graphical user interface for customers and or enterprise customer service representatives to generate and enter requests for production or repinning of identification cards. Such requests by client user interface elements  150 ,  134 ,  140  and  142  are directed via the network to enterprise server  130  typically resident in the central operations location  200 .  
         [0046]    In addition to client user interface elements  150 ,  134 ,  140  and  142 , elements  224 ,  226  and  154  represent other standard interface elements provided at a remote location  220 . Such standard elements may include components for administrative functions such as user maintenance, reporting and card stock inventory management (element  224 ); administration of a financial encryption keys (element  226 ); and design of specific card formats to be produced by the system (element  154 ).  
         [0047]    For example, a particular location may design a new style or format of identification card, may issue requests for batches of identification cards to be produced, and may administer particular aspects of identification information and security information useful to service representatives at the particular remote location  220  as well as useful to particular customers at that location. Such local management requests are also directed to enterprise server  130  through standard network communications.  
         [0048]    Though not required, a particular remote location  220  may provide a number of local card issuance machines  226  or external software processes  238 . Such card issuance machines and external software processes are interfaced by a card machine controller (CMC) software component  136 . Each CMC software component interfaces one or more appropriate card issuance devices or external software processes.  
         [0049]    A client user interface element  134 ,  140 ,  142  or  150  generates a request at a remote location  220  for issuance of a particular type of identification card. The request is forwarded to the enterprise server  130  located at a physical central operations location  200 . The request is communicated via standard network communication media and protocols, preferably TCP/IP network protocols and associated network communication media. Information required for production of the requested identification card may be obtained locally by the client user interface element  134 ,  140 ,  142  or  150  as well as centrally provided by operation of the enterprise server  130 . For example, details of the particular customer or account information for the particular customer is preferably centrally stored at the central operations location and accessed in a controlled manner through the optional Custom Interface software component  152 . Any sensitive or confidential information transferred between the enterprise server  130  and client user interface elements  134 ,  140 ,  142  and  150  and card machine controller element  136  is preferably encrypted to maintain security through the network. If the card is to be issued, the information necessary to emboss and/or encode the card is generated using the card format database  214 .  
         [0050]    Card format database  214  contains definitions for each type of card known to the enterprise for production. This definition includes placement of information on a card, style of production of the information (i.e., encoded and/or embossing), application specific information (i.e., financial calculations relating to banking etc.), type of card stock/media (i.e., plastic embossed cards, magnetic stripes, “smart” cards, etc.) and other information required to generate any particular type of card used in the enterprise.  
         [0051]    Using the network configuration database  210  the enterprise server determines which card machine controller component and which card issuance device or external software process to use for the request. The information is then encrypted and transferred from the enterprise server  130  to the appropriate CMC software component  136  in the enterprise. The card machine controller component  136  then communicates with the appropriate card issuance device  236  or external software process  238  to produce the card. Optionally, the information communicated to the card issuance device or external software process may also be encrypted for additional security.  
         [0052]    The server interface element  144  allows custom client user interfaces  150  to easily communicate with the enterprise server component  130  by providing a standard programming interface. The PIN pad interface OCX element  146  provides a standard programming interface between client components  134  and  150  and PIN entry machines  147 . These PIN entry machines allow a customer to select their current PIN and optionally select a new PIN. The host interface OCX component  148  provides a standard programming interface between the custom client user interface  150  and the host system  202 . This interface allows simplified transmission of information between the two elements.  
         [0053]    As noted above, those skilled in the art will recognize that the functional decomposition of elements and the physical locations of such elements as shown in FIG. 2 is intended merely as exemplary of one preferred embodiment. The client/server programming paradigm permits the various client processes and server processes to be distributed anywhere in the enterprise network. Further, the specific breakdown of components may differ depending on specific design choices in implementing the features of the present invention.  
         [0054]    [0054]FIG. 3 is a flowchart describing the operation of the enterprise server element depicted above FIGS. 1 and 2. In general, the enterprise server process initializes when it commences operation and then awaits receipt of an event message indicative of an operation requested by a client process within the enterprise or from the enterprise server&#39;s internal clock timer. Requests are directed to the enterprise server from client user interface processes for production of cards and card machine controller elements as well as from the client administrative user interface for reconfiguration or other management operations of the present invention.  
         [0055]    Element  300  represents processing to initialize operation of the enterprise server. Among other functions, the initialization processing includes discovery and initialization of card machine controller components in the network. Asynchronously, each card machine controller initializes each of the issuance machines or external software processes it is designated to control. Further details of such initialization processing are provided herein below with respect to FIG. 4.  
         [0056]    In the preferred embodiment, the server process awaits receipt of event messages from card machine controller processes with card production completion notifications and client processes requesting services from the enterprise server process. In addition, every two seconds, or other time interval so established, a timer event occurs and the server process checks each issuance machine queue to see if a card request needs to be processed. Element  302  therefore represents processing by the enterprise server process to await receipt of a supported timer event or a client initiated event message. Upon receipt of such an event, the method then continues by processing the received event in accordance with a type indicated therein. Exemplary of such client event messages in the preferred embodiment are: a client request to produce an identification card, an indication that production of a requested identification card has completed, an administrative user client request to associate a newly designed card format with a particular issuance machine or its associated queue, and a request to administer, configure or manage the card issuance enterprise system of the present invention.  
         [0057]    Those skilled in the art will recognize that the particular events to be processed by the enterprise server are a matter of design choice in the implementation of the present invention. The particular events depicted in FIG. 3 are therefore intended merely as exemplary of typical events that may be processed by enterprise server operable in accordance with the present invention. Furthermore, those skilled in the art will recognize a variety of other programming paradigms useful in implementing features of the enterprise server. An event driven model as described herein with respect to FIG. 3 is therefore intended as representative of all such solutions.  
         [0058]    In response to a request to produce an identification card, elements  304  through  314  are operable to process the request. Element  304  first checks the request to make sure all required information is provided (i.e., the request is valid). If the request is not valid element  306  is operable to notify the originating client of the problem and processing loops back to element  302  to await a next event. If the request is valid, element  308  next performs any requisite processing to calculate or reformat information for the card to be produced. For example, in financial applications of the present invention, ATM or credit cards have calculations involving customer PIN selection or assignment. Element  310  is next operable to determine whether the request is to be placed on a production queue for later processing or is to be routed to a queue associated with a card machine or external software process for processing. If routed to a production queue, element  312  is operable to queue the request on an identified production queue for later processing. If the request is to be processed now, element  314  routes the request to the queue of the identified card machine or external software process. In both cases, processing loops back to element  302  to await a next event.  
         [0059]    Every two seconds, element  320  checks to see if more issuance machine queues need be checked. If all issuance machine queues have been checked processing completes for this timed event and continues at element  302  (label A) to await occurrence of another event. If more queues remain to be checked, element  322  gets information for the next card issuance machine queue. Element  324  then determines whether the card issuance machine or external software process associated with the queue or otherwise identified by the request is presently busy servicing other requests. If the machine or process is busy, processing continues by looping back to element  320  to check additional issuance machine queues. If the machine or process is not busy, processing continues with element  326  to unqueue the next request queued for the identified card issuance machine and transmit the unqueued request to an appropriate card machine controller responsible for controlling operation of the identified card issuance machine. Processing then continues by looping back to element  320  to determine if more queues remain to be processed.  
         [0060]    Processing by the card issuance machine proceeds asynchronously with respect to the enterprise server. Completion of the card production request will be signaled to the enterprise server by a subsequent event message as discussed below.  
         [0061]    In response to receipt of an event message signifying completion of an identification card production request, element  330  is operable to determine if the card was completed or an error occurred. If completed without errors, the client process that submitted the original request is notified of the completion with element  336  and then element  338  is operable to determine whether additional requests remain queued for the card issuance machine identified in the completion event message. If so, processing continues at element  340  to unqueue a next production request and transmit the request to the identified card machine controller and then loop back to element  302  (label A) to await receipt of the next event. If no further requests are presently queued for the identified card machine, processing continues by looping back to element  302  (label A).  
         [0062]    If element  330  determines that an error occurred in processing a request, element  332  is operable to notify the originating client process of the error. Element  334  then suspends processing of further requests for this queue until the problem is corrected by an operator. Processing then continue by looping back to element  302  (label A) to await receipt of another event.  
         [0063]    In response to receipt of an administrative reconfiguration or management event message, element  360  is operable to reconfigure the enterprise card issuance system in accordance with parameters supplied in event message. As noted elsewhere herein, an administrative user of the enterprise server may reconfigure the system to associate particular PCs with particular PC Groups, to associate particular card issuance machines with particular PC Groups and PCs, to associate particular card formats with particular card issuance machines, etc. Processing then continues by looping back to element to  302  (label A) to await receipt of another event message.  
         [0064]    In response to receipt of an event message requesting a change in the routing of future card requests from one card issuance machine to another, element  370  is operable to so make this change. Element  372  then notifies the appropriate affected clients of the routing change. Processing then continues at element  302  (label A) as described above. Such a request may be initiated by an administrative client process in response to graphical input to “drag and drop” of selected routing definitions.  
         [0065]    [0065]FIG. 4 is a flowchart describing additional details of the processing of element  300  to initialize the enterprise card issuance system of the present invention. Element  400  is first operable to open all system databases. Element  401  then identifies all card issuance machine controller elements present in the enterprise as defined in the system database ( 210  of FIG. 2). As noted above, a card issuance machine controller element is operable within a PC in locations that physically include card issuance machines. The card issuance machine controller element is a module operable in a PC at such a location to manage the production operations of one or more card issuance machines. The identity and location of all such card issuance machine controllers is used by the enterprise server to prepare its initial configuration information.  
         [0066]    Element  402  then creates a queue associated with each card issuance machine present in the enterprise system. Element  404  then determines whether all CMC components in the enterprise have been processed by elements  406  through  412 . If no further CMC components remain to be processed, processing of element  300  is complete. If more CMC components are to be processed, element  406  is operable with respect to the next CMC component to attempt to establish a connection therewith. Element  408  then determines whether the attempted connection was successful. If not, processing of this CMC component is complete and processing loops back to element  404  to process additional CMCs. If the connection attempt succeeds, element  412  transmits configuration information from the network configuration database ( 210  on FIG. 2) to the CMC component ( 136  on FIG. 1). This configuration information informs the CMC component of the types of card issuance machines attached to, or external software processes associated with the CMC component and the interfaces to be used (i.e., the physical and logical configuration of the CMC component and its card issuance machines and external software processes, elements  236  and  238  respectively.) Processing then loops back to element  404  to process remaining CMC components.  
         [0067]    Those skilled in the art will recognize that the flowcharts of FIGS. 3 and 4 are intended merely as representative of one exemplary embodiment of the enterprise server system of the present invention. A number of equivalent alternate embodiments will be readily apparent to those skilled in the art. Such design choices in implementation are well known to those of ordinary skill in the art.  
         [0068]    [0068]FIGS. 5 through 10 are exemplary screen images depicting typical user interface techniques for implementation of the enterprise card issuance system of the present invention. In particular, these screen images are representative of screens typically used by an administrative user to configure and manage the enterprise card issuance system of the present invention.  
         [0069]    [0069]FIG. 5 depicts elements and resources available in a typical enterprise system in accordance with the present invention. In FIG. 5, the first two elements  502  and  504  identify production queues in which requests for associated types of cards are queued awaiting production by an assigned card issuance machine. In particular, the first queue  502  named “ATM Cards” is assigned to a card issuance machine named “Main Office\PC100\DataCard 28x/295.” A second queue  504  named “Visa Debit Cards” is assigned to the same card issuance machine named “MainOffice\PC100\DataCard 28x/295.” A PC group  506  named “Branch 1” has two PCs  508  and  510  associated therewith and named “PC200” and “PC202.” The PC group  506  does not have a card issuance machine. Two card formats  512  and  514  named “ATM Card” and “Visa Debit Card”, are associated (“linked”) with requests generated by clients operating on all PCs of “Branch 1.” All requests submitted for production of “ATM Card” card formats will be stored in the system production queue  502  named “ATM Cards.” Similarly, all requests submitted for production of “Visa Debit Cards” will be stored in the system production queue  504  named “Visa Debit Cards.” At some future time, an administrative user can instruct the system to produce the cards being stored in these production queues. In this example, both types of cards will be produced at the DataCard 28x/295 card issuance machine located in the Main Office as discussed below (i.e., the card issuance machine to which the production queue is currently linked).  
         [0070]    [0070]FIG. 5 also identifies resources in a Main Office  516  including two PCs: element  520 , named “PC100” and element  518  named “COMPAQ_NT.” Operable within PC  520  (“PC100”) is a card machine controller  522  for controlling two card issuance machines, a DataCard 150i card issuance machine element  524  and a DataCard 28x/295 card issuance machine, element  526 . Two card formats  528  and  530 , named “ATM Card” and “Visa Debit Card”, respectively, are associated with PC Group  516  named “Main Office” for production on the attached DataCard 150i card issuance machine  524 .  
         [0071]    The various elements of the enterprise are shown in a “tree” structure to reflect the physical and logical relationships among the elements. The physical relationships are the physical proximity of the elements. In other words, PCs that are members of the PC group “Main Office” are shown under the branches of the tree display rooted at element  516  “Main Office”. In addition to PCs defined within each PC group are routing directives (“links”) for the various card formats at either the PC group or PC level. These links specify either a particular card issuance machine or a specific production queue.  
         [0072]    Production queues, elements  502  and  504 , are available for the entire enterprise and are linked, similar to how card formats are linked, to specific card issuance machines. However, card requests in the production queues are not produced until so directed by an administrative user at a later time. At that time, all card requests in the specified production queue will be produced at the currently linked card issuance machine.  
         [0073]    Card format and production queue links are logical relationships that the administrative user can create and modify using simple drag and drop manipulations on the displayed graphical tree structure. For example, in order to create a new card format link and associate it with a card issuance machine queue an administrative user would perform the following exemplary steps on the graphical user interface shown in the following figures.  
         [0074]    1. As shown in FIG. 6, right click on element  602  which defines a PC group named “Main Office”.  
         [0075]    2. A popup menu appears as shown in FIG. 7.  
         [0076]    3. Click on the popup menu choice “New Card Format Link . . . ” element  702  on FIG. 7.  
         [0077]    4. A window appears as shown in FIG. 8.  
         [0078]    5. Select the card format to create a link. In this example we select “Visa Credit Card”, element  802  and then click on the OK button element  804 .  
         [0079]    6. The card format link appears in FIG. 9 as element  904  with a link definition  906  as “Needs to be linked”.  
         [0080]    7. The user clicks on the icon for the link, element  904 , and drags the icon to the icon element  902  that represents the card issuance queue for a particular card issuance machine.  
         [0081]    8. When the icon being dragged is released, the card format is linked to this queue as indicated by the link definition  1006  “Main Office\PC100\DataCard 28x/295)” in FIG. 10.  
         [0082]    While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description is to be considered as exemplary and not restrictive in character, it being understood that only the preferred embodiment and minor variants thereof have been shown and described and that all changes and modifications that come within the spirit of the invention are desired to be protected.