The subject matter disclosed herein relates to trusted vendor access, a system to provide trusted vendor access and a method of providing trusted vendor access.
Traditionally, access control systems are managed centrally and both the means of access to secure resources and the persons who are allowed access to the secure resources is managed by the same organization. That is, when separate organizations are interacting within an access control system, it is often the case that only one of the organizations is involved in the management of the system. For example, many universities own and manage both the locks on campus doors and the cards that can access those locks. If a vendor organization requires access prevented by those locks, each vendor of the vendor organization must get a credential card from the university and be setup in the university system to gain the required access.
Over time this may lead to an unwieldy and cumbersome process if many vendor organizations, many sites, large geographical areas and other factors are involved. Additionally, adding and/or removing to and/or from the system a vendor organization or an individual vendor becomes a key management chore where the university (in this example) would need to make access control management tasks over time as vendor organizations and their associated vendors change.
Moreover, if a vendor organization intends to have access to secure resources of multiple universities, each of their associated vendors needs to be given access via the various universities respective systems. This means that each vendor needs to have multiple cards, one for each university the vendor organization intends to have access to. In a similar vein, if each vendor intends to be associated with multiple vendor organizations, he will, again, be required to carry multiple cards for the university (or universities) the multiple vendor organizations intend to have access to.
In addition, vendor access systems may be networked where a centralized database is used to manage the access control rights. When a card is presented to the lock, the lock communicates to the central database to verify access control rights before permitting access. However, some systems are ‘offline’ and therefore the cards that are permitted access must be prior programmed into the lock. If a card is to be added or removed, a programming step must be done to the lock to allow the card in.
In some improvements, a single-card programmed in the lock is replaced by a ‘system code’ that would allow any card from a particular organization to access the offline lock. However, this still has the limitation that if the vendors that may access the lock are to be changed, then the lock must be reprogrammed in order for the change to take effect.
Also, in patent application US 2006/0208852 A1, Wenzlik, et al., offer access delegated in code-based systems. In Wenzlik, a license is provided to an authorized person that allows them to generate codes based on their own schedule to gain access to a trusted resource but the access control managing organization must still manage individuals as opposed to organizations as a whole. They must still issue licenses to ‘authorized persons’ on an individual basis even though that authorized person can manage their own codes to a secure resource and, if new authorized persons require access, then the managing organization must still be involved to provide additional licenses.
Moreover, most current vendor access systems provide for first or at most second level access control. First level access control is characterized by the authorized person gaining access through something he/she knows (i.e., a code/PIN). Second level access control is characterized in that the authorized person gains access through something he/she carries (i.e., a credential). By contrast, third level access control is characterized in that the authorized person gain access through the use of a combination of something he/she knows and something he/she carries (i.e., a code/PIN associated with a credential). This level of access control is rarely offered with the current vendor access systems, however, due to the high level of programming demand that must be managed and memory requirements that must be provided to the various locking devices.
USPTO Backgrounds
USPTO Backgrounds