Patent Publication Number: US-2015089633-A1

Title: System and method for asset assignment and replacement

Description:
FIELD 
     The claimed invention generally relates to methods and systems for secure asset management. More particularly, the claimed invention relates to methods and systems for asset assignment and replacement. 
     BACKGROUND 
     There is a need to store and track valuable assets, such as, but not limited to keys, identification cards, and passes. It is desirable to have a system and method to track and manage access to those assets, such that certain assets may be accountably assigned to a user in a streamlined, accountable fashion. Furthermore, it is also desirable to provide a reliable and efficient way to replace a previously assigned asset with a matching asset in the event that the previously assigned asset is lost. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIGS. 1-4  illustrate different embodiments of a method for asset assignment. 
         FIGS. 5-6C  schematically illustrate embodiments of a system for asset assignment. 
         FIG. 7  schematically illustrates another embodiment of a system for asset assignment. 
         FIG. 8  illustrates one embodiment of an initial asset storage for use in a system for asset assignment. 
         FIG. 9A  illustrates one embodiment of an asset panel for use in a system for asset assignment. 
         FIG. 9B  illustrates one embodiment of an asset having the identification tag from  FIG. 9A  for use in a system for asset assignment. 
         FIG. 10A  illustrates a second embodiment of an asset panel for use in a system for asset assignment. 
         FIG. 10B  illustrates one embodiment of an asset having an identification tag from  FIG. 10A  for use in a system for asset management. 
         FIG. 11A  illustrates a third embodiment of an asset panel for use in a system for asset management. 
         FIG. 11B  illustrates one embodiment of an asset having an identification tag from  FIG. 11A  for use in a system for asset management. 
         FIG. 12A  illustrates a fourth embodiment of an asset panel for use in a system for asset management. 
         FIG. 12B  illustrates one embodiment of an asset having an identification tag from  FIG. 12A  for use in a system for asset management. 
         FIG. 13A  illustrates a fifth embodiment of an asset panel for use in a system for asset management. 
         FIG. 13B  illustrates one embodiment of an asset having an identification tag from  FIG. 13A  for use in a system for asset management. 
         FIGS. 14A-14F  illustrate one embodiment of a method for asset assignment using one embodiment of a system for asset management. 
         FIGS. 15A-1  to  15 B illustrate one embodiment of a method for asset replacement. 
         FIG. 16  illustrates one embodiment of an asset panel having a plurality of coiled spring mounts for receiving a memory button. 
         FIG. 17  is a partially schematic plan view of a coil spring mount showing a gripped memory button in broken lines. 
         FIG. 18  is a partially cut-away and partially schematic view of a coil spring holder for a memory button attached to a key tag. 
         FIG. 19  is a side elevational view of the coil spring, memory button, and key tag of  FIG. 18 . 
         FIG. 20  is a side elevational view of the key tag of  FIGS. 18 and 19 . 
         FIG. 21  is a partially perspective view of a key hanging on a wire loop of the key tag of  FIGS. 18 ,  19 , and  20 . 
         FIG. 22  is a side elevational view of the combination of a key, key tag, gripping spring, and circuit board to show how compactly a key can be mounted. 
         FIGS. 23-26  illustrate different embodiments of an asset panel for use with a system for asset management. 
     
    
    
     It will be appreciated that for purposes of clarity and where deemed appropriate, reference numerals have been repeated in the figures to indicate corresponding features, and that the various elements in the drawings have not necessarily been drawn to scale in order to better show the features. 
     DETAILED DESCRIPTION 
       FIG. 1  illustrates one embodiment of a method of asset assignment. In step  30 , a user interface is used to authenticate a recipient. The recipient can be someone to whom it is desired to assign an asset, such as, but not limited to a student who needs dormitory keys, a police officer who needs to be assigned keys to a cruiser, an office worker who needs filing cabinet keys, a lessee who needs apartment keys, or a worker who needs office keys. It should be understood that the asset is not limited to keys, however, keys are often used as examples throughout this specification for convenience. Examples of a suitable user interface for authenticating the recipient include, but are not limited to a keypad (for entering a personal identification number or other password or authentication information), a bar code scanner (for scanning one or more identification bar codes), a proximity card reader (for detecting one or more proximity cards having authentication information), a magnetic card reader (for detecting one or more magnetic cards having authentication information, a biometric device (for detecting one or more biometric identifiers), or any combination and/or plurality thereof. Suitable non-limiting examples of a biometric device may include a fingerprint reader, a hand shape reader, an iris pattern reader, and a retina scanner. 
     In step  32 , the user interface is also used to identify an asset. If the asset has an identification tag which can be scanned, for example, but not limited to, by reading a bar code, a magnetic identification, a radio frequency identification (RFID) tag, or a proximity tag, then identifying the asset may comprise scanning  34  the identification tag coupled to the asset. As one alternative to scanning an identification tag, an identification code associated with the asset may be entered  36  to identify the asset. 
     In step  38 , the identified asset is assigned to the authenticated recipient, and in step  40  a data record linking the assigned asset to the authenticated recipient is stored. This method, especially when used with an identification tag which can be scanned is a very efficient way to assign assets to a recipient while maintaining a record of the transaction. Non-limiting embodiments of suitable systems for implementing the methods described herein will be covered later in the specification. 
       FIG. 2  illustrates a further method of asset assignment. Often times, when assets are being assigned, it may be useful to have someone in charge of the asset assignment process. In step  42 , using a user interface, a first administrator is authenticated. Suitable embodiments of a user interface have been discussed above. This first administrator, who may be in charge of the asset assignment process, will sometimes be able to manage assignment of the assets directly from where they happen to be stored. Other times, it may be more practical for the administrator to move one or more of the assets to another location for distribution and assignment. For example, in the case where assets are keys at a college, a resident advisor (first administrator) may want to take a group of keys for his/her floor from a locked storage area to a table in a common room for distribution. Therefore, in optional step  44 , one or more assets are temporarily assigned to the authenticated first administrator. In step  46 , using the user interface, a recipient is authenticated, as has been discussed above. Using the user interface, the asset is identified in step  48  as has been discussed above. Optionally, the asset is identified  50  from the one or more temporarily assigned assets. In the case where the asset was one of the one or more temporarily assigned assets, the identified asset is unassigned from the authenticated first administrator in step  52 . 
     In step  54 , the identified asset is assigned to the authenticated recipient. Since an administrator is involved, this assignment  54  to the authenticated recipient occurs  56  with an authority of the authenticated first administrator. In such embodiments, the asset will not be properly assigned to the recipient without the first administrator being involved in the transaction, and the first administrator remains responsible for the assets temporarily assigned to him/her until they are properly assigned to a recipient or returned (as will be described shortly hereafter). In step  58 , a data record linking the assigned asset to the authenticated recipient is stored, for example in a database, as has been discussed above. Optionally, a reference to the authenticated first administrator can be included  60  with the data record. 
     In step,  62 , optionally, if the first administrator still has a remaining number of temporarily assigned assets assigned to them, the assets may be returned to an asset storage. In step  64 , the returned assets may be unassigned from the authenticated first administrator. In optional step  66 , the returned remaining number of assets are audited versus the temporarily assigned one or more assets and any assets assigned to one or more identified users. As such, it may be determined if any assets are unaccounted for, and in optional step  68 , any missing assets identified in the audit may be reported. Reports may include, but are not limited to text message notifications, email notifications, web dashboard status updates, and visual, and/or audible alarms. 
     Once assets have been assigned to a recipient, it is often the case that a recipient may misplace the asset and require a replacement.  FIG. 3  illustrates another embodiment of a method of asset assignment to address this situation. In step  70 , the recipient is reauthenticated with a user interface. In step  72 , an asset previously assigned to the recipient is ascertained from the stored data record. If multiple assets have been assigned to the recipient, then a secondary selection of the missing previously assigned asset may be performed. In step  74 , a duplicate asset of the previously assigned asset is located. Again, non-limiting embodiments of suitable systems for implementing the methods described herein will be covered later in the specification. In step  76 , the duplicate asset is reassigned to the reauthenticated recipient. This can include storing a new data record linking the assigned duplicate asset to the reauthenticated recipient. 
     As with previous methods, it may be desirable to have an administrator be responsible for the asset replacement.  FIG. 4  illustrates a further method of asset assignment. In step  78 , a second administrator is authenticated with a user interface. It should be noted that in some cases, the person acting as administrator for this step may be the same person who authenticated as the first administrator or it may be a different person. In step  80 , the recipient is reauthenticated with the user interface in a similar fashion to the original authentication. In step  82 , the asset previously assigned to the recipient from the stored data record is ascertained as has been described above. In step  84 , a duplicate asset of the previously assigned asset is located. As a non-limiting example, this may be done by electronically unlocking  86  a storage unit where the duplicate asset is stored, and/or activating  88  at least one indicator showing a location of the asset. The storage unit may include, but is not limited to, a file cabinet, a file cabinet drawer, and a locker. Examples of indicators may include, but are not limited to light emitting diodes (LEDs), incandescent lights, or even displays such as liquid crystal displays (LCDs) which can indicate the location of the asset. Some examples include lighting an LED on a file cabinet and/or a specific file cabinet drawer. Alternately, or additionally, an LED on a panel within a drawer could be lit to focus attention on the panel where the asset could be located, or even at a specific location on the asset panel (as will be discussed in more detail further in this patent application). 
     In step  90 , the duplicate asset is assigned to the reauthenticated recipient. As with the assignments discussed above, this assignment  90 , in this embodiment, occurs  92  with an authority of the authenticated second administrator. 
       FIG. 5  schematically illustrates an embodiment of a system  94  for asset assignment. The system  94  has a user interface  96 , a database  98 , and a controller  100  coupled to the user interface  96  and the database  98 . Examples of a suitable user interface  96  for authenticating the recipient include, but are not limited to a keypad, a bar code scanner, a proximity card reader, a magnetic card reader, a biometric device, or any combination and/or plurality thereof. Suitable non-limiting examples of a biometric device may include a fingerprint reader, a hand shape reader, an iris pattern reader, and a retinal scanner. The database  98  may be any type of machine readable memory or data storage where one or more data records may be stored. Non-limiting examples of a database  98  may include, a volatile memory, a non-volatile memory, randomly accessible memory (RAM), a magnetic storage media, an optical storage media, flash memory, phase change storage media, and any combination and/or plurality thereof, whether local or distributed. 
     The controller  100  is configured to authenticate a recipient via the user interface  96 . As just a few examples, this could include authenticating a recipient by receiving and verifying an access code from a keypad of the user interface  96 , receiving and verifying a magnetic code from a magnetic card reader of the user interface  96 , or receiving and verifying a fingerprint from a fingerprint scanner of the user interface  96 . Through the authentication process, the recipient provides some form of identification to the controller  100  via the user interface  96  that can be used to authenticate the recipient. 
     The controller  100  is further configured to identify an asset via the user interface  96 . If the asset has an identification tag which can be scanned, for example, but not limited to, by reading a bar code, a magnetic identification, a radio frequency identification (RFID) tag, or a proximity tag, then identifying the asset may comprise scanning (with the user interface  96 ) the identification tag coupled to the asset. As one alternative to scanning an identification tag, an identification code associated with the asset may be entered via the user interface  96  to identify the asset. The asset identifier is thus provided to the controller  100  for identification of the asset. 
     The controller  100  is also configured to assign the identified asset to the authenticated recipient, for example by storing a data record in the database  98  linking the assigned asset to the authenticated recipient as has been discussed previously. The controller  100  may be a computer, a microprocessor, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), digital circuitry, analog circuitry, or any combination and/or plurality thereof, whether local or distributed. 
     The controller  100  may further be configured to authenticate a first administrator via the user interface  96 , and the assignment of the identified asset to the authenticated recipient occurs with an authority of the authenticated first administrator. As mentioned previously, the stored data record linking the assigned asset to the authenticated recipient may also comprise a reference to the first administrator for purposes of an audit trail. 
     As shown in  FIGS. 6A-6C , some embodiments of the system  102 ,  104 ,  106  may also have an initial asset storage  108 . The initial asset storage  108  can house the assets while they are not assigned to anyone. In some embodiments, the initial asset storage  108  may be a secured storage lockable, for example with mechanical or electronic locks. The initial asset storage  108  may be decoupled from the controller  100  as shown in the embodiment of  FIG. 6A . In other embodiments, the initial asset storage  108  may be coupled to the controller  100  as shown in the embodiment of  FIGS. 6B and 6C . Embodiments where the initial asset storage  108  is coupled to the controller  100  have the potential advantage of being able to inform the controller  100  automatically when one or more assets are removed from the initial asset storage  108  by an authorized administrator. Such embodiments streamline the process of temporarily assigning one or more assets from the initial asset storage  108  to the first administrator as discussed above. 
     One way for the assets removed from the initial asset storage  108  to be temporarily assigned to the first administrator is for each asset to be tagged with an identifier which is monitored. In some embodiments, when the asset is removed from the initial asset storage  108 , the system can recognize a disconnection from the monitored asset tag (for example in the case of a disconnection of a touch memory button from a Dallas semiconductor 1-Wire bus). The initial asset storage  108  may also be configured only to allow access to the assets after receiving an authentication from the first administrator. Thus, the system can know who accessed the initial asset storage  108  and which of the one or more assets were removed from the initial asset storage  108 . Accordingly, the removed assets may automatically and temporarily be assigned to the administrator. 
     In other embodiments, the assets may be tagged with an identifier which can be scanned, but which is not monitored by the initial asset storage  108 . The initial asset storage  108  may still be configured to allow access to the assets following an authentication from the administrator. The administrator could then remove assets, but would be responsible for scanning or entering the asset identifier into a user interface  96  in order to temporarily assign the assets to the administrator. 
     When the administrator is finished assigning one or more of the assets to others, if there are still one or more assets temporarily assigned to the administrator, then the system is configured to facilitate the return of the temporarily assigned assets. One way for the assets removed from the initial asset storage  108  to be returned is for each asset to be tagged with an identifier which is monitored. In some embodiments, when the asset is returned to the initial asset storage  108 , the system can recognize a connection with the monitored asset tag (for example in the case of a connection of a touch memory button to a Dallas semiconductor 1-Wire bus). The initial asset storage  108  may also be configured only to allow access to the storage area after receiving an authentication from the first administrator. Thus, the system can know who accessed the initial asset storage  108  and which of the one or more assets were returned to the initial asset storage  108 . Accordingly, the returned assets may automatically be unassigned from the administrator. 
     In other embodiments, the assets may be tagged with an identifier which can be scanned, but which is not monitored by the initial asset storage. The initial asset storage  108  may still be configured to allow return of the assets following an authentication from the administrator. The administrator could then return assets, but would be responsible for scanning or entering the asset identifier into a user interface  96  in order to unassign the assets from the administrator. 
     In the embodiment of  FIG. 6B , the initial asset storage  108  is coupled directly to the controller  100 . In the embodiment of  FIG. 6C , the initial asset storage  108  is coupled to the controller  100  by a network  110 . The network  110  may be, but is not limited to, a local area network (LAN), a wide area network (WAN), a wireless LAN, or a wireless WAN. 
     As illustrated in  FIG. 6C , the system  106  may also include a replacement asset storage  112  configured to store duplicate assets of previously assigned assets. Although the replacement asset storage  112  is shown coupled to the controller  100  via a network  110  in this embodiment, it should be understood that the replacement asset storage  112  may be coupled to the controller in other ways, including a direct wired or wireless connection. In some embodiments, the duplicate assets may be tagged with an identifier which is monitored, for example, using a touch memory button on a 1-Wire communication bus (embodiments of which will be described in more detail later in this specification). As a result, the system can be configured to know the location of a particular duplicate asset and can activate an indicator to show the location of the duplicate asset within the replacement asset storage  112 . While duplicate assets do not have to have tags which can communicate with the controller  100 , such embodiments have the advantage that duplicate assets may be placed in any available location in the replacement asset storage  112 , and the controller will know exactly where they are located in certain embodiments (to be discussed). 
     In a system having a replacement asset storage  112 , such as the system  106  of  FIG. 6C , the controller  100  may further be configured to reauthenticate the recipient via the user interface  96  as described previously. The controller  100  may also be configured to ascertain an asset previously assigned to the recipient from the stored data record. With a table showing what duplicate assets are located where, the controller  100  may also be configured to locate a duplicate asset of the previously assigned asset and assign the duplicate asset to the reauthenticated recipient. As before, logs may be kept of the transaction. The replacement asset storage  112  may be built into a variety of devices, including, but not limited to, a file cabinet, a file cabinet drawer, and a locker. 
       FIG. 7  schematically illustrates another embodiment of a system  114  for asset assignment. The system  114  has a user interface which is distributed among several devices, embodied here as a reader  116 , keypads  118 ,  120 , keyboard  122 , and liquid crystal displays  124 ,  126 , and  128 . Other embodiments may have additional or fewer user interface options. In this embodiment, the reader  116  has two input devices, including a proximity card reader  130  and a fingerprint reader  132 . The controller in this system is distributed among several locations, including in the laptop  134  and inside the control boxes  136 ,  138  attached to the file cabinets  140 ,  142 , respectively. The file cabinets  140 ,  142  may be used for an initial asset storage and/or a replacement asset storage as discussed previously. The controllers communicate via a network  144 . The controllers may be configured to operate independently of the other controllers and/or in conjunction with each other. The system  114  also has a database, as discussed previously, which can be stored in one or more memories coupled to any one or more of the controllers. 
     The controller (in this embodiment a distributed set of controllers) is configured to authenticate a recipient via the user interface (could be any of the one or more input devices), identify an asset via the user interface (for example by entering information via a keypad or by scanning a tag coupled to the asset), assign the identified asset to the authenticated recipient, and store a data record in the database linking the assigned asset to the authenticated recipient. The controller can also be configured to carry out the additional methods for asset assignment and asset replacement as discussed previously. 
       FIG. 8  illustrates one embodiment of an initial asset storage  146  for use in a system for asset assignment. In this embodiment, the initial asset storage  146  is made from a file cabinet  148  having a controller  150 , a keypad  152 , and an LCD screen  154 . The file cabinet  148  may also be fitted with one or more electromechanical locks (not shown) which may be coupled to the controller  150  so that one or more file drawers may be selectively unlocked for authorized users upon proper authentication. Authentication may be determined via entry of a code at the keypad  152 . Other embodiments may utilize one or more other or additional input devices, so, for example, authentication could be determined by the swiping of a magnetic pass card or a proximity badge. In this embodiment of an initial asset storage  146 , a plurality of asset panels  156  are hung from the file cabinet rails. Each asset panel  156  may be configured to hold one or more assets (here shown as keys). 
       FIG. 9A  illustrates one embodiment of an asset panel  156 A for use in a system for asset assignment. In this embodiment, the asset panel  156 A has hooks  158  configured to engage file folder rails in the file cabinet drawer, enabling the asset panel  156 A to hang from the file folder rails like a hanging file folder. The asset panel  156 A has multiple hooks  160  from which assets  162  (a key ring and key combination in this case) may be hung.  FIG. 9B  illustrates one embodiment of an asset  162  having an identification tag  164  coupled to it. In this embodiment, the identification tag  164  is a proximity tag having an identification that can be read by a proximity reader to identify the asset  162 . 
       FIG. 10A  illustrates another embodiment of an asset panel  156 B for use in a system for asset assignment. In this embodiment, the asset panel  156 B has hooks  158  configured to engage file folder rails in the file cabinet drawer, enabling the asset panel  156 B to hang from the file folder rails like a hanging file folder. The asset panel  156 B has multiple memory button mounts  166  (to be discussed in greater detail later) from which assets  162  coupled to a tag  168  having a memory button  170  may be attached.  FIG. 10B  illustrates one embodiment of the asset  162  having the tag  168  and memory button  170  coupled to it. In this embodiment, the memory button  170  has an identification number which can be electronically read by a controller coupled to the asset panel  156 B. Therefore, the system may be configured to tell which assets (coupled to the memory buttons) are present and which assets have been removed. Asset removal/return information may be coupled with a user&#39;s name/identification as authenticated when opening the file cabinet drawer. 
       FIG. 11A  illustrates another embodiment of an asset panel  156 C for use in a system for asset assignment. In this embodiment, the asset panel  156 C has hooks  158  configured to engage file folder rails in the file cabinet drawer, enabling the asset panel  156 C to hang from the file folder rails like a hanging file folder. The asset panel  156 C has multiple memory button mounts (not visible from this angle, but will be discussed in greater detail later) from which an asset  162  combined with a memory button  170  (not visible in  FIG. 11A ) may be attached. A suitable key combination with an electronic identifier (such as a memory button) is disclosed in U.S. patent application Ser. No. 13/589,472, which is hereby incorporated by reference in its entirety.  FIG. 11B  illustrates one embodiment of the asset  162  having the memory button  170  coupled to it. In this embodiment, the memory button  170  has an identification number which can be read by a controller coupled to the asset panel  156 C. Therefore, the system may be configured to tell which assets (coupled to the memory buttons) are present and which assets have been removed. Asset removal/return information may be coupled with a user&#39;s name/identification as authenticated when opening the file cabinet drawer. 
       FIG. 12A  illustrates one embodiment of an asset panel  156 D for use in a system for asset assignment. In this embodiment, the asset panel  156 D has hooks  158  configured to engage file folder rails in the file cabinet drawer, enabling the asset panel  156 D to hang from the file folder rails like a hanging file folder. The asset panel  156 D has multiple hooks  160  from which assets  162  (a key ring and key combination in this case) may be hung. As shown more clearly in  FIG. 12B , the asset  162  may have an identification bar code  172  coupled to it. In this embodiment, the identification bar code  172  can be read by a bar code scanner to identify the asset  162 . 
       FIG. 13A  illustrates one embodiment of an asset panel  156 E for use in a system for asset assignment. In this embodiment, the asset panel  156 E has hooks  158  configured to engage file folder rails in the file cabinet drawer, enabling the asset panel  156 E to hang from the file folder rails like a hanging file folder. The asset panel  156 E may be covered in a velcro type loop material, and the assets  162  may be coupled to a tag  174  having a velcro type hook material (or visa versa) so that the assets  162  may be hung from the asset panel  156 E. As shown more clearly in  FIG. 13B , the asset  162  may have an identification code  176  coupled to it. In this embodiment, the identification code  176  can be entered by a user into a keypad or keyboard to identify the asset  162 . 
     Although the embodiments for asset panels  156 A- 156 E all were shown with file folder hooks  158 , other embodiments may not utilize hooks to store the panels  156 A- 156 E in the file cabinet or storage drawer. In other embodiments, panels could be stored on racks or otherwise stacked and stored together. In further embodiments, the panels could be integral with the inside of a drawer so that only the assets could be removed, rather than also having the option of removing an entire asset panel. 
       FIGS. 14A-14F  illustrate one embodiment of a method for asset assignment using one embodiment of a system for asset management. As illustrated in  FIG. 14A , using a user interface (here a card reader  178 ) a first administrator is authenticated by swiping an administrator identification card  180  by the card reader  178  coupled to an initial asset storage  182 . As shown in  FIG. 14B , the first administrator may then remove one or more assets from the asset storage  182 . If the assets are coupled to a controller by an electronic identifier such as a touch memory button (such as, but not limited to the iButton from Dallas Semiconductor), then the system can automatically identify which assets were removed and can optionally be configured to temporarily assign the assets to the first administrator. Optionally, in other embodiments, the assets may have identification tags which may be scanned or entered into the system to identify which assets have been removed by the administrator. Some embodiments may not track which assets have been removed by the administrator, but there can at least be a record of who accessed the asset storage, if desired, when using authentication to gain access to the initial asset storage. 
     In the example here, an asset panel  184  is removed, the assets being sets of keys coupled to an RFID tag (proximity tag) by a key ring. Some initial enrollment and setup is recommended for the system so that known assets (keys in this example) are associated with known identification tags in the system database. For example, a key for a dormitory room number 520 in Finsbury Hall on the City University Campus can be pre-associated with a particular and unique identification tag. 
     One or more assets are now in the possession of the first administrator, and the administrator may wish to distribute the assets to one or more persons. As just one example, a resident advisor at a university may have a set of keys for the dormitory rooms on their floor in a campus residence. The resident advisor may wish to distribute the dorm room keys to students assigned to various rooms. The assets (in this example, keys) may be labeled to facilitate the administrator (here a resident advisor) handing the appropriate key to a student. However, it is desirable to track this transaction, so, as illustrated in  FIG. 14C , the first administrator and the recipient each are authenticated via a user interface  186 . In this example, the administrator is authenticated by placing a proximity ID  188  near a proximity reader  190 . Similarly, a recipient is authenticated by placing their own proximity ID  192  near the proximity reader  190 . Other embodiments may use other forms of identification for authentication, including, but not limited to using a fingerprint reader  194 . In some embodiments, the administrator may not need to authenticate, and only the recipient will be authenticated. In still others, the administrator may only need to authenticate once for a session where several recipients will be then be authenticated. Authentication methods for administrators and recipients do not need to be the same, but can be. 
     As shown in  FIG. 14D-1  an asset  196  may be identified via the user interface  186  by scanning an identification tag  198  coupled to the asset  196 . In this example, the identification tag  198  is an RFID tag which can be read by the proximity reader  190  of the user interface  186 . Since the association between the identification tag and the asset is known, the asset  196  may be assigned to the authenticated recipient (a relationship is created), and a data record linking the assigned asset to the authenticated recipient may be stored. Similarly (and alternately), as shown in  FIG. 14D-2 , an asset  200  may be identified via another portion of the user interface, here by entering an identification code  202  for the asset  200  into the system by keyboard  122 . 
     When the administrator is finished handing out assets and assigning them to recipients, he/she may still have assets left over which were not assigned. The unassigned assets may be returned to the asset storage. As shown in  FIG. 14E , it may be necessary for the administrator to identify themselves  204  to the storage  182  in order to gain entry. As shown in  FIG. 14F , any remaining assets may be returned, and the asset storage  182  closed. If, in the process of returning the assets to the asset storage  182 , the assets are recoupled to the controller by an electronic identifier such as a touch memory button (such as, but not limited to the iButton from Dallas Semiconductor), then the system can automatically identify which assets were returned and can optionally be configured to unassign the assets from the first administrator. Optionally, in other embodiments, the assets may have identification tags which can be scanned into the system to identify which assets have been returned by the administrator. 
     The systems and methods described herein, and their equivalents, provide a knowledge of which assets have been assigned to which recipients. This information can be used with further embodiments of the system to facilitate asset replacement in the event of a lost asset.  FIGS. 15A-1  to  15 B illustrate one embodiment of a method for asset replacement. As illustrated in  FIG. 15A-1 , using a user interface  206  (here, having a card reader  208 ) a second administrator is authenticated by swiping an administrator identification card  210  by the card reader  208  coupled to one or more replacement asset storages  212 . In this example, the one or more replacement asset storages are coupled to the system by one or more distributed controllers  214  and a network  216 . A recipient (in this case a person who has lost his/her asset or otherwise needs a replacement of the asset) is authenticated by swiping a recipient identification card  218  by the card reader  208 . One or more of the controllers may ascertain what asset was previously assigned to the recipient. In the case where multiple assets have been assigned to the recipient, the recipient may need to provide additional input to the system so that the desired asset for replacement may be ascertained. One or more of the stored data records from the previous asset assignment may be used to ascertain the asset previously assigned to the recipient. 
     As illustrated in  FIG. 15A-2 , the method for asset replacement may alternately be initiated using a smaller type of system. For example, using a user interface, here a card reader  220  coupled to a replacement asset storage  212 , a second administrator is authenticated by swiping an administrator identification card  210  by the card reader  220 . A recipient (in this case a person who has lost his/her asset or otherwise needs a replacement of the asset) is authenticated by swiping a recipient identification card  218  by the card reader  220 . A controller (not shown) may ascertain what asset was previously assigned to the recipient. In the case where multiple assets have been assigned to the recipient, the recipient may need to provide additional input to the system (for example, via keypad  222 ) so that the desired asset for replacement may be ascertained. One or more of the stored data records from the previous asset assignment may be used to ascertain the asset previously assigned to the recipient. The system shown in  FIG. 15A-2  would need to be connected to a database of the previously assigned assets or have a copy of the database stored locally. 
     Since time has passed since the initial asset assignment, the administrator in the replacement process is referred to as a second administrator because it is possible that a different person is acting in an administrative capacity. However, it should be understood that the first administrator and the second administrator could be the same person in some scenarios. 
     The replacement asset storage may be configured to house replacement assets in an organized and preferably known fashion. For example, replacement keys (identical to those having been previously assigned) may be catalogued by drawer/asset panel location. Such a catalog of locations may be stored by the system for reference. In some embodiments, the replacement assets may have their own unique electronic identification tags that the system can query, such as a touch memory button. The system may be configured to take an inventory of the touch memory buttons, noting their position within the one or more replacement asset storage locations. An example of this process and a system for accomplishing it will be discussed later in more detail. In either type of scenario, after the asset previously assigned to the recipient is ascertained, the system can be configured to locate a duplicate asset of the previously assigned asset. The location of the replacement (duplicate) asset may be looked up in a database that was populated manually or automatically. In some embodiments, an indicator may be activated to help a user obtain the replacement asset that was located. As just a few examples: a) an LCD screen could display a file cabinet number, a file cabinet drawer, an asset panel number, and/or a specific location on an asset panel to help the user locate the replacement asset; b) a LED could be lit on a particular file cabinet, file cabinet drawer, an asset panel, and/or a specific location on an asset panel to help the user locate the replacement asset. In the example illustrated in  FIG. 15B , the replacement asset storage  212  has the replacement assets stored on an asset panel  224  with memory buttons attached to each asset. An LED  226  on the file drawer and an LED  228  next to the replacement asset position can be activated by the controller during the location of the duplicate asset. The recipient can take the duplicate asset and the system can assign the duplicate asset to the recipient. Such a system and method can save administrators a lot of time and headache in locating replacement keys, especially in large settings such as within universities, apartment buildings, government buildings, and corporate buildings where there may be thousands of keys to manage and track. 
       FIG. 16  illustrates one embodiment of an asset panel  230  having a plurality of coiled spring mounts  232  for receiving a memory button. Previous views of such an asset panel have had assets blocking the view of the memory button mounts, but embodiments of such mounts  232  will be discussed here in detail. The illustrated embodiments involve a coil spring gripper that releasably holds a memory button, and therefore an asset secured to the memory button. Such a configuration is especially suitable for keys as the objects to be secured, although it should be understood that this can be used for assets which are not keys. The memory button mount  232  is further illustrated in  FIGS. 17-19  and an embodiment of a key tag is illustrated in  FIGS. 18-22 . Many variations are possible for mounting memory buttons directly on the heads of keys or on other assets to be secured. 
     This embodiment of a memory button mount  232  has a coil gripping spring  234 . The coil gripping spring  234  preferably has a conical shape as illustrated, with a base coil  236  having a larger diameter than a gripping coil  238  arranged at a top of spring  234 . Top coil  238  can then grip memory button  240  as illustrated in broken lines in  FIG. 17 . Spring  234  is preferably made of a conductive metal, such as music wire so that it electrically communicates with a cylindrical periphery  242  of memory button  240 . It can be made in many configurations, including cylindrical, but the illustrated conical shape is preferred for stability. 
     The ends  244  of spring  234  can be cut off square, as shown in  FIG. 17 , or can be machined to tapers that more closely fit a plane surface. Experience has shown that this is not necessary, however. Even cut off square, as shown in  FIG. 17 , gripping coil  234  surrounds about ¼ or about 270 degrees of the cylindrical surface  242  of memory button  240 . This affords a grip strong enough to releasably support both memory button  240  and tags or objects secured to memory button  240 . The grip of spring  234  on memory button  240  is aided by the fact that memory button  240  does not need to be disposed parallel with a support surface  246  to which base coil  236  is secured. Spring  234 , in the simple illustrated configuration, can be made on a fourslide machine, which is preferred for keeping the manufacturing expense low. 
     A support surface  246  is preferably a circuit board having established conductive paths  248  and  250 . There are countless ways that electrically conductive paths can be designed on a circuit board  246  or other support to read identities from an array of memory buttons  240 . They all require a single signal line, paired with a neutral line. Those of ordinary skill in the art are readily familiar with the 1-wire communication protocol from Dallas Semiconductor, for example, for their touch memory iButtons, and such a protocol can be used to communicate with the touch memory buttons in these embodiments and their equivalents. 
     A contact spring  252 , of much lighter gauge than gripping spring  234 , is preferably mounted on circuit board  246  within base coil  236  to extend up to a region within gripping coil  238  to electrically contact a plane face surface  254  of memory button  240 . Contact spring  252  thus contacts an electrode of memory button  240  while gripping spring  234  contacts another electrode of memory button  240  so that identification numbers of memory button  240  can be accessed simply. 
     Spring  234 , in addition to providing electrical contact with a cylindrical perimeter  242  of memory button  240 , also grips and releasably holds memory button  240  by the frictional grip of upper coil  238 . The springiness of the wire of spring  234  allows upper coil  238  to expand slightly when memory button  240  is pressed into place within the wrap of coil  238 . This wrap extends around more than half of the cylindrical surface of memory button  240 , and preferably about 270 degrees, to hold memory button  240  securely. Coils of spring  234  preferably contact each other in an unflexed state so that pushing button  240  into gripping coil  238  is resisted by the underlying coils to force gripping coil  238  to expand slightly in diameter to receive button  240 . This assures a secure and reliable grip on button  240  that remains releasable for removing a secured object. 
     For security of keys, memory button  240  is preferably secured to a tag  256  that holds a wire  258  on which a key  260  can hang. Tag  256  has slits  262  at an upper end to receive barbed ends of wire  258 . A key  260 , mounted on wire  258  is secured to tag  256  once the barbed ends of wire  258  are inserted into slits  262  from which the wire cannot be extracted. Memory button  240  is secured to one face of tag  256 , and wire  258  is bent to extend into a space on a side of tag  256  opposite button  240 . 
     With circuit board  246  oriented vertically and coil spring  234  oriented horizontally, tag  256  can hang vertically from the grip afforded by memory button  240  in the gripping coil  238  of spring  234 . This disposes hanging wire  258  near the top of tag  256  with a loop  264  disposed on a side of tag  256  opposite button  240  where the head  266  of key  260  is disposed above a bottom end  268  of tag  256 . This is shown in  FIGS. 20-22 . This arrangement makes compact storage for an array of keys so that many more keys and tags can be mounted in a security box than if the tags were hung with the wire end downward. This would extend the hanging wire  258  below the bottom of tag  256 , with key  260  extending even farther below tag  256  where it would require much more hanging space. 
       FIGS. 23-26  schematically illustrate different embodiments of an asset panel for use with a system for asset management. The system shown in  FIG. 23  has a controller  270  coupled to a user interface  272  and a database  274  as has been discussed above. The controller  270  is also coupled to an asset panel  276  via a 1-wire communication bus  278 . The 1-wire communication bus refers to the fact that only one signal wire is needed (in addition to a ground connection) for communication. A suitable 1-wire communication bus may be implemented using the Dallas Semiconductor 1-wire protocol developed for their touch memory iButton devices and is familiar to those skilled in the art. 
     A connector  280  may be provided on the asset panel  276  to have a 1-wire signal connection  282  and a ground connection  284 . A plurality of memory button mounts  286  may be present on the asset panel  276 , each memory button mount  286  having a gripping coil  288  and a contact coil  290 . The contact coils  290  are all coupled to the 1-wire signal connection  282  by circuit traces and/or other conductive paths, such as, but not limited to wires. Similarly, the gripping coils  288  are all coupled to the ground connection  284  by circuit traces and/or other conductive paths, such as, but not limited to wires. 
     Using a 1-wire protocol, the controller  270  may query the asset panel  276  coupled to the 1-wire bus  278  to see what, if any, iButton identification tags are plugged into memory button mounts  286 . If a memory button is present, it will respond to a query from the controller  270 , letting the controller know the memory button (and therefore the asset associated with the memory button) is present. Depending on the embodiment, a greater or fewer number of memory button mounts may be present on an asset panel, and more than one asset panel could be coupled to the 1-wire communication bus  278  at the same time. 
       FIG. 24  schematically illustrates another embodiment of an asset panel for use with a system for asset management. The system shown in  FIG. 24  has a controller  270  coupled to a user interface  272  and a database  274  as has been discussed above. The controller  270  is also coupled to an asset panel  292  via a 1-wire communication bus  278  in a manner as has been discussed previously. A connector  280  may be provided on the asset panel  292  to have a 1-wire signal connection  282  and a ground connection  284 . A plurality of memory button mounts  286  may be present on the asset panel  292 , each memory button mount  286  having a gripping coil  288  and a contact coil  290 . 
     Location circuitry  294  may be provided for each memory button mount  286  in order to enable the controller  270  to know not only if a memory button is present, but in which specific memory button mount it is located. In this embodiment, location circuitry  294  is placed between the contact coil  290  of each memory button mount  286  and the 1-wire signal connection  282 . The gripping coils  288  are all coupled to the ground connection  284  by circuit traces and/or other conductive paths, such as, but not limited to wires. 
       FIG. 25  illustrates one possible embodiment of location circuitry  294  suitable for use with a memory button mount  286 . A 1-wire addressable switch  296  is coupled to the 1-wire bus  278 . The 1-wire addressable switch  296  has a unique touch-memory-compatible identification that is known (programmatically or in a database) by the controller to be associated with the specific memory button mount  286  coupled to the location circuitry  294 . One example of a suitable 1-wire addressable switch  296  is the 1-wire 8 Channel Addressable switch, model DS2408 from Maxim Integrated. The 1-wire addressable switch has at least one output line  298  which a controller (not shown in  FIG. 25 ) coupled to the 1-wire bus  278  can set to a digital high voltage or a digital low voltage by properly addressing the 1-wire addressable switch  296  in a manner known to those skilled in the art. In this embodiment, the output line  298  is coupled to a digital control input  300  of an analog switch  302 . One example of a suitable analog switch  302  is the Analog Switch Model TS5A3160 from Texas Instruments. In the embodiment of  FIG. 25 , the digital control input  300  enables the switch  302  when the control input  300  set to digital low, and disables it when set to digital high. The contact coil  290  of the memory button mount  286  is coupled to a normally closed pin  304  of the analog switch  302 . A COM pin  306  of the analog switch  302  is coupled to the 1-wire bus  278 . 
     In operation, when the controller (not shown) instructs the 1-wire addressable switch  296  to set the output line  298  to digital low, the analog switch  302  will be enabled, allowing the contact spring  290  to be coupled to the 1-wire bus  278  via the normally closed connection between pins  304  and  306  of the analog switch. When the controller instructs the 1-wire addressable switch  296  to set the output line  298  to digital high, the analog switch  302  will be disabled, preventing the contact spring  290  from being coupled to the 1-wire bus  278 . An indicator, such as LED  308  may be coupled between a voltage source  310  and the digital control input  300 . When the digital control input  300  is set low, enabling the connection of the contact spring  290  to the 1-wire bus  278  as described above, the LED  308  will be lit. Likewise, when the digital control input  300  is set high, disabling the connection between the contact spring  290  and the 1-wire bus  278  as described above, the LED will not be lit, since a pull-up resistor  312  ensures that current does not flow through the LED  308 . 
     In a system, there can be multiple memory button mounts, each having their own location circuitry  294 . The controller may be configured to periodically run an algorithm to take an inventory of the iButton addresses (for any iButtons installed in a memory button mount) and correlate them with the 1-Wire switch addresses. One non-limiting way to do this is to enable all of the 1-wire addressable switch output ports (set them to high), and then, 1-by-1, disable a single switchable output port (thereby enabling the associated possible iButton connection), and check to see if a new 1-wire device appears. If it does, then the appearing 1-wire device (attached to a key, for example) is mapped to the 1-wire addressable switch/output port which was disabled. This can then be repeated for all positions. Another non-limiting way to do this is to do the opposite by disabling all of the 1-wire addressable switch output ports (set them to low), and take an inventory of the available iButton devices (since all will be coupled to the 1-wire bus). Then, 1-by-1 enable a single switchable output port (thereby disabling the associated possible iButton connection) and check to see if a 1-wire device disappears from the list of all iButton devices. If it does, then the disappearing 1-wire device is mapped to the 1-wire addressable switch/output port which was enabled. 
     Being able to inventory the available iButton devices lets the system check to see if an authorized administrator or other user has removed or returned an asset. Furthermore, when each addressable switch is mapped to a known asset, the location circuitry can be used to locate the asset for a user. As one example, when an authorized user opens the file cabinet looking for a particular key, the key position can be highlighted by setting the associated 1-wire addressable switch output port low, thereby turning on the associated LED. This also couples the indicated iButton to the 1-wire bus so the controller can monitor for the moment of asset removal if desired. It is worth noting with such an embodiment that any iButtons in positions which are not lit (because the associated 1-wire addressable switch output port is set high) will not show up on the 1-wire bus during this time. Thus it is advisable for the controller to perform an inventory at the end of a transaction or period of time to check to see exactly what assets were removed by the user. 
       FIG. 26  schematically illustrates another embodiment of an asset panel  314  for use with a system for asset management. The system shown in  FIG. 26  has a controller  270  coupled to a user interface  272  and a database  274  as has been discussed above. The controller  270  is also coupled to the asset panel  314  via a 1-wire communication bus  278 . The features of the 1-wire communication bus  278  have been discussed previously. In this embodiment, rather than using a connector to couple to the 1-wire communication bus  278  as discussed with previous embodiments, two hanging hooks  316  and  318  (made from conductive material) are provided to couple a ground  320  and a 1-wire signal  322 , respectively to the asset panel  314 . The ground  320  can be coupled to one hanging file rail in a file drawer and the 1-wire signal  322  can be coupled to the other hanging file rail in the file drawer, provided the file rails are properly electrically isolated from each other as is known to those skilled in the art. In such an embodiment, the simple act of hanging the conductive hooks  316 ,  318  from the file rails will provide the necessary electrical connections to the asset panel. This can provide added convenience if it is desirable to remove the asset panels without having to disconnect a cable connector from the asset panel. 
     As with previous embodiments, a plurality of memory button mounts  286  may be present on the asset panel  314 , each memory button mount  314  having a gripping coil  288  and a contact coil  290 . The contact coils  290  are all coupled to the 1-wire signal connection  318  by circuit traces and/or other conductive paths, such as, but not limited to wires. Similarly, the gripping coils  288  are all coupled to the ground connection  316  by circuit traces and/or other conductive paths, such as, but not limited to wires. 
     Using a 1-wire protocol, the controller  270  may query the asset panel  314  coupled to the 1-wire bus  278  to see what, if any, iButton identification tags are plugged into memory button mounts  286 . If a memory button is present, it will respond to a query from the controller  270 , letting the controller know the asset associated with the memory button is present. Depending on the embodiment, a greater or fewer number of memory button mounts may be present on an asset panel, and more than one asset panel could be coupled to the 1-wire communication bus  278  at the same time. Furthermore, similar embodiments having location circuitry may be used as described above. 
     Having thus described several embodiments of the claimed invention, it will be rather apparent to those skilled in the art that the foregoing detailed disclosure is intended to be presented by way of example only, and is not limiting. Many advantages for the systems and methods for asset assignment have been discussed. Various alterations, improvements, and modifications will occur and are intended to those skilled in the art, though not expressly stated herein. These alterations, improvements, and modifications are intended to be suggested hereby, and are within the spirit and the scope of the claimed invention. Additionally, the recited order of the processing elements or sequences, or the use of numbers, letters, or other designations therefore, is not intended to limit the claimed processes to any order except as may be specified in the claims. Accordingly, the claimed invention is limited only by the following claims and equivalents thereto.