Single sign-on system and method

[0001] This application includes subject matter related to U.S. patent application Ser. No. 10/960,535, filed Oct. 7, 2004, entitled “Call Center Dashboard”, by B. Balasubramanian, et al, which is incorporated herein by reference for all purposes.

[0002] Not applicable.

[0003] Not applicable.

[0004] The present invention relates to the authentication and authorization of users attempting to gain access to computer-based applications. More particularly, embodiments of the present invention provide for a single sign-on capability when authentication and authorization information is maintained in multiple disparate data stores.

[0005] An enterprise might have multiple web-based applications that can be accessed by internal users, external users, or both. The users might be required to sign in to the applications so that the users can be authenticated and authorized. That is, when attempting to access an application, a user typically provides a user ID and a password to the application. The application might then authenticate the user by confirming that the password is correct for the user ID. After authentication, an authorization process might determine whether the user is allowed to have access to the requested application.

[0006] Authentication and authorization information for the users is typically stored in a data store such as a relational database or a directory such as a directory compliant with the Lightweight Directory Access Protocol. For example, an authentication data store might maintain a list of user IDs and corresponding passwords. When a user attempts to sign on to an application, the password provided by the user is checked against the password stored in the authentication data store for the user's user ID. If the passwords match, the user is considered authentic.

[0007] An authorization data store might maintain a list of applications to which a user is allowed access. The application to which the user has requested access can be checked against the list of applications available to the user and, if the requested application is on the list, the user can be authorized to use the application. The authentication data store and the authorization data store might be separate or might be combined into a single data store.

[0008] In some cases, an application might perform its own authentication and authorization activities by interacting directly with the authentication and authorization data stores. In other cases, a policy server or other intermediary component might receive user ID and password information from one or more applications, pass the user ID and password information to the authentication and authorization data stores, receive one or more responses from the authentication and authorization data stores, and return the responses to the applications. In either case, each application might have its own data store for authentication and authorization information. Alternatively, authentication and authorization information for more than one application might be stored in a single data store. In some cases, there might be a single authentication and authorization data store for all internal users and a separate single authentication and authorization data store for all external users.

[0009] In one embodiment, a system for single sign-on for an enterprise application is provided. The system includes a plurality of enterprise applications, and a policy server operable to receive a user's single sign-on information regarding access to a first enterprise application. The policy server also promotes communication of authentication and authorization information for the first enterprise application to determine the user's access to the first enterprise application. The policy server is operable, regarding the user accessing a second enterprise application, to authenticate the user based on the user's single sign-on information and to use the single sign-on information to obtain authorization information for the second enterprise application to determine the user's access to the second enterprise application. The system includes an authentication data store to maintain the authentication information used by the policy server related to user authentication for at least some of the plurality of enterprise applications. The system includes internal and external authorization data stores. The internal authorization data store maintains internal authorization information related to internal user and the external authorization data store maintains external authorization information related to external user. A consolidated data store maintains consolidated authorization information including both internal and external user authorization information used by the policy server related to user authorization for at least some of the plurality of enterprise applications. The system also includes a synchronization component to synchronize the internal and external authorization information from the internal and external authorization data stores, respectively, to the consolidated data store.

[0010] In another embodiment, a method for providing a single sign-on capability for a plurality of computing applications is provided. The method includes providing a first data store containing information on a first user of a computing application and providing a second data store containing information on a second user of a computing application. The method includes extracting information from the first and second data stores, translating the information from a format of the first data store and a format of the second data store into a format of a third data store. When a duplication exists between an identifying attribute for a record from the first data store and an identifying attribute for a record from the second data store, the method includes assigning a new identifying attribute to the record from the first data store. The method also provides for loading the translated information into the third data store. The method includes a user providing identifying information when the user attempts to gain access to a first computing application. The method includes comparing the identifying information provided by the user with authorization information in the third data store and authentication information in a fourth data store regarding the user's authority to access the first computing application. The method includes authorizing the user for access to the first computing application. When a user attempts to gain access to a second computing application, retrieving, without further action from the user, the identifying information provided by the user and comparing the identifying information provided by the user with authorization information in the third data store regarding the user's authority to access the second computing application. The method also includes authorizing the user for access to the second computing application.

[0011] In yet another embodiment, a system for allowing access to a plurality of web applications through a single sign-on is provided. The system includes a first data store that contains authorization information on a first user of one or more of the computing applications, and a second data store operative to contain authorization information on a second user of the computing applications. The system includes a third data store that contains authorization information on the first and second users. A fourth data store maintains authentication information related to access to the computing applications. A synchronization component translates information from a format of the first data store and a format of the second data store into a format of a third data store. When a duplication exists between an identifying attribute for a record from the first data store and an identifying attribute for a record from the second data store, the synchronization component assigns a single identifying attribute to the record and loads the translated information into the third data store. A policy server component uses the identifying information provided by a user when signing on to a first computing application and compares the identifying information to authorization information in the third data store. The policy server uses authentication information in the fourth data store to determine the user's access to the first computing application. When the user attempts to gain access to a second computing application, the policy server compares the identifying information to authorization information in the third data store without further action from the user to determine the user's access to the second computing application.

[0012] These and other features and advantages will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.

[0017] It should be understood at the outset that although an exemplary implementation of one embodiment of the present disclosure is illustrated below, the present system may be implemented using any number of techniques, whether currently known or in existence. The present disclosure should in no way be limited to the exemplary implementations, drawings, and techniques illustrated below, including the exemplary design and implementation illustrated and described herein.

[0018] When a single user is allowed access to multiple applications, the user might have to sign on to each application separately. This could become tedious, time-consuming, and error prone when simultaneous access to multiple applications is needed. As an alternative to this, the concept of a single sign-on has been developed. With single sign-on, a user can sign on to one application and is thereafter automatically signed on to other applications to which he is allowed access.

[0019] A single sign-on system is typically not feasible when the authentication and authorization information is maintained in multiple disparate data stores. More specifically, for a single sign-on system to function properly, each user should have only one identifying attribute, such as a user ID number, and each identifying attribute should belong to only one user. In the case where authentication and authorization information is maintained in multiple disparate data stores, it is possible for a single user to appear in more than one data store under different user IDs. In that case, a single sign-on system might not be able to determine which authorization information should be used when the user attempts to sign in to an application. Also, it could happen that different users in different data stores have the same user ID simply by coincidence. In that case, a single sign-on system might not be able to determine which user is being referred to when that user ID is used.

[0020] Another complication with single sign-on is that a user might have different levels of authority in different applications. For example, a user who is authorized to have access to two applications might be allowed to perform a particular action in one application but might not be allowed to perform the same action in the other application. The set of actions that a user is authorized to perform within a particular application can be referred to as a role. Since a user can have different roles in different applications, an authorization policy based strictly on user ID might not properly capture role-based authorization levels. A user given the same level of authority for multiple applications might be given too much authority for his or her role in one application and not enough authority for his or her role in another application. In such a situation, a single sign-on system that takes into account roles, not simply user IDs, is needed.

[0021] Single sign-on would typically depend on the existence of a single authoritative data store containing a unique identifying attribute for each user who might use the single sign-on system. This single data store would typically need to contain role-based authorization information for each user for each application. When authentication, authorization, and role information is maintained in multiple data stores using disparate data formats, the creation of single data store containing the appropriate authentication, authorization, and role information can be problematical.

[0022] For example, replication of the disparate data stores into a single data store is typically not possible. Replication requires the establishment of an agreement between the data store from which data is to be replicated and the data store to which data is to be replicated. When the data stores use different data formats, establishing an agreement on how data should be replicated from one data store to another may pose difficulties that are not easily surmounted. For example, replicating data from a Microsoft Metadirectory Services LDAP directory to a Siemens DirX LDAP directory may be difficult. Similarly, replicating data from an Oracle relational database to a Siemens DirX LDAP directory may be difficult. Replicating data from both a Microsoft Metadirectory Services LDAP directory and an Oracle relational database to a Siemens DirX LDAP directory may be more difficult than it is worthwhile to attempt.

[0023] Another potential method for creating a single data store that contains the information needed to implement a single sign-on system is through file-based synchronization. In this approach, each disparate data store might generate a file with the information that needs to be migrated to the single data store and the generated file can then be uploaded into the single data store. This process can be repeated at regular intervals to ensure that the single data store remains up-to-date. The generated file might contain a complete dump of the data store and might be created at frequent intervals. Alternatively, a complete dump can be done at less frequent intervals with files detailing recent changes to the disparate data stores being generated and uploaded at more frequent intervals.

[0024] Uploading a complete dump of a data store at frequent intervals is a very resource intensive process. Since the majority of data in the data stores would typically not change frequently, uploading the same data on a frequent basis could be a waste of time and resources. Performing a complete dump at less frequent intervals and generating change files at more frequent intervals can be more efficient. However, the process of generating authoritative incremental change files can be difficult and might make this option less feasible.

[0025] In an embodiment, a single sign-on data store is created by transferring data from multiple individual data stores into the single sign-on data store. Since each of the individual data stores might use a different data format from the single sign-on data store, a different approach might be taken for translating data from each of the individual stores. When the single sign-on data store has been created, data related to multiple different users and applications can be retrieved from it and used to automatically authorize a user for access to any of the applications after the user has successfully signed on to any one of the applications.

[0026] FIG. 1 illustrates an embodiment of a system 10 that uses a single sign-on data store 60. A user 20 might have access to web applications 32, 34, and 36. While three web applications are shown, other numbers could be present. When the user 20 attempts to sign on to one of the applications 32, 34, or 36, user ID and password information is sent to a policy server 40. In an embodiment, the policy server 40 might be part of the Netegrity, Inc., SiteMinder authentication software package. The policy server 40 attempts to authenticate the user 20 by consulting with a set 50 of authentication data stores. The set 50 of authentication data stores contains user ID and password information for users 20 of the applications 32, 34, and 36.

[0027] In the embodiment of FIG. 1, the set 50 of authentication data stores includes a main internal data store 52, a main external data store 54, and another data store 56. The main internal data store 52 might contain the majority of the authentication information for users internal to an enterprise and the main external data store 54 might contain the majority of the authentication information for users external to an enterprise. The other data store 56 might contain other authentication information that might be used by either internal or external users. For example, the other data store 56 might contain application-specific authentication information that, for various reasons, cannot be placed in the main internal data store 52 or the main external data store 54. The other data store 56 might also contain authentication information for users 20 who use an alternate ID in addition to the ID stored in one of the main data stores 52 or 54.

[0028] While the set 50 of authentication data stores contains three data stores in the embodiment of FIG. 1, in other embodiments other numbers could be present. For example, the main internal data store 52, the main external data store 54, and the other data store 56 could be combined into a single data store. In another alternative, multiple other data stores 56 could be present.

[0029] The policy server 40 checks the user ID and password entered by the user 20 into an application 32, 34, or 36 against the user ID and password information stored in the set 50 of authentication data stores. If a match is found, the policy server 40 authenticates the user 20. In an embodiment, once the policy server 40 has authenticated a user 20, a token, such as a session cookie, is created confirming that the user has been authenticated and no further authentication is needed as long as the user remains signed on. Commercial, off-the-shelf policy servers 40 such as the SiteMinder policy server can typically authenticate large numbers of users 20 who might be using large numbers of applications and can typically search for authentication information in a large number of authentication data stores.

[0030] After the policy server 40 has authenticated a user 20, the policy server 40 seeks authorization information for the user 20 in the single sign-on data store 60. As described in greater detail below, the single sign-on data store 60 contains information regarding the authorization levels for multiple users 20 in the various roles they might hold in the applications 32, 34, and 36. The policy server 40 finds the appropriate authorization information in the single sign-on data store 60 for the role being sought by the user 20 in the application 32, 34, or 36. If the user 20 is authorized for the requested role, access to the role in the application 32, 34, or 36 is granted.

[0031] Thereafter, if the user 20 wishes to switch to another application 32, 34, or 36, the user does not need to manually enter user ID and password information. Instead, the policy server 40 might check whether a token exists indicating that the user 20 has already been authenticated. If a token exists, the appropriate authorization information is automatically retrieved from the single sign-on data store 60 and returned to the appropriate application 32, 34, or 36 without any further action needed from the user 20. In other embodiments, rather than the authorization information being retrieved from the single sign-on data store 60 every time the user 20 switches applications, the authorization information might be cached in and retrieved from the policy server 40, a web application 32, 34, or 36, or some other location, or the authorization information might be maintained in and retrieved from an internet browser cookie stored locally on the user's computer. In any case, the user 20 can easily switch from one application 32, 34, or 36 to another without additional sign-ons and is unaware of the authorization activities being carried out in the background.

[0032] Some applications 32, 34, or 36 might automatically log out a user 20 if the user 20 is inactive in the application 32, 34, or 36 for an extended period of time. For example, if a user 20 signs on to an application 32, 34, or 36 and then leaves his or her work station, an unauthorized user might be able to gain access to a secure application 32, 34, or 36 while the user 20 is away. To prevent this, an application 32, 34, 36, or the policy server 40 might automatically sign the user 20 out if no input is received over a specified period of time. The automatic sign-on capabilities of the system 10 would not override such security measures. A user 20 who is automatically logged out of an application 32, 34, or 36 would not be automatically logged in and would have to repeat the sign-on procedures described above.

[0033] In order for the single sign-on data store 60 to contain the appropriate role and authorization information, the information typically needs to be extracted from other data stores and then loaded into the single sign-on data store 60. The single sign-on data store 60 can then act as an authoritative data store that contains role and authorization information for each potential user 20 and a unique identifying attribute for each potential user 20.

[0034] In the embodiment of FIG. 1, a second set 80 of data stores contains the role and authorization information that is loaded into the single sign-on data store 60. In this embodiment, the second set 80 of authorization data stores includes a main internal data store 82, a main external data store 84, and another data store 86. The main internal data store 82 might contain the majority of the authorization information for internal users and the main external data store 84 might contain the majority of the authorization information for external users. The other data store 86 might contain other authorization information that might be used by either internal or external users. For example, the other data store 86 might contain application-specific authorization information that, for various reasons, cannot be placed in the main internal data store 82 or the main external data store 84. The other data store 86 might also contain authorization information for users 20 who use an alternate ID in addition to the ID stored in one of the main data stores 82 or 84.

[0035] While the second set 80 of authorization data stores contains three data stores in the embodiment of FIG. 1, in other embodiments other numbers could be present. For example, the main internal data store 82, the main external data store 84, and the other data store 86 could be combined into a single data store. In another alternative, multiple other data stores 86 could be present. In yet other alternatives, the set 50 of authentication data stores and the second set 80 of authorization data stores could be combined into a single data store, or the individual data stores 52, 54, 56, 82, 84, or 86 could be could be joined in various combinations.

[0036] Each of the data stores 82, 84, and 86 sends authorization and/or authentication data to a synchronization process 70 that converts data from the format of the data stores 82, 84, and 86 into a format usable by the single sign-on data store 60. The synchronization process 70 might use scripts or other software routines to assign unique identification attributes to each user and/or each user's role. Each user may have a unique number or identifier associated with each user, such as a user ID number, which is checked. When the user ID number is found in one or more of the data store 82, 84, and 86, the system determines whether the corresponding user names are also the same. Where the names are the same, then the additional attributes, such as additional roles, are added for that ID number. Where the names are different, a new ID number is generated and assigned to the user and the system administrator is notified. In an embodiment, the scripts might automatically notify the system administrator when the duplication is found.

[0037] Rules can be implemented regarding the priority of the identification numbers. For example, an enterprise might specify that internal users should be given preference in the assignment of ID numbers. That is, if an internal user and an external user are found to have the same ID number, the internal user might be allowed to keep his or her ID number and the external user might be assigned a new ID number.

[0038] This reassignment of duplicate ID numbers allows the single sign-on data store 60 to have a unique user ID number (or other identifying attribute) for each user 20 or each role for each user 20. Whenever authorization information is sought for a particular user or a particular role for a particular user, the unique user IDs ensure that the correct information is retrieved. Without the single sign-on data store 60, authorization information would be retrieved from the second set 80 of authorization data stores. If any ambiguity existed among the authorization information in the data stores 82, 84, and 86, it is possible that authorization information for an incorrect user 20 or for an incorrect role for a user 20 could be retrieved.

[0039] In an embodiment, the user IDs in the single sign-on data store 60 can be mapped to the user IDs in the set of authentication data stores 50 to ensure that the set of authentication data stores 50 uses the same user IDs as the single sign-on data store 60. This can provide further assurance that the authentication and authorization information used for a particular user 20 or a particular role is correct.

[0040] In an embodiment, the single sign-on data store 60 is implemented using a Siemens DirX LDAP server, the main internal authorization data store 82 is implemented using Microsoft Metadirectory Services (MMS), the main external authorization data store 84 is implemented using an Oracle database, and the other authorization data store 86 uses neither Siemens DirX, Microsoft Metadirectory Services, nor Oracle. The following discussion will focus on those types of data stores but one of skill in the art will recognize that a similar discussion would apply to other types of data stores.

[0041] Since each data store 82, 84, and 86 uses a different data storage protocol, a different approach to transferring data into the single sign-on data store 60 is needed for each of the individual data stores 82, 84, and 86. For the main internal data store 82, a method for transferring data from an MMS LDAP to a Siemens DirX LDAP is needed. In an embodiment, a script or software routine within the synchronization process 70 reads data from the MMS LDAP 82, converts the data into data compatible with the Siemens DirX LDAP 60, then writes the data to the Siemens DirX LDAP 60. As a first step, attribute names in the MMS LDAP 82 are converted into attribute names in the Siemens DirX LDAP 60. Data elements associated with each attribute in the MMS LDAP 82 are then converted into data elements that are associated with the converted attribute names in the Siemens DirX LDAP 60. In an embodiment, the Java Naming and Directory Interface (JNDI) application programming interface is used to connect the MMS LDAP 82 to the Siemens DirX LDAP 60. The JNDI can search for all user-related information in the MMS LDAP 82 and transfer the information to the Siemens DirX LDAP 60.

[0042] In an embodiment, intelligence can be built into the script or software routine within the synchronization process 70 so that the script or software routine transfers only the information in the MMS LDAP 82 that was modified since the previous time the routine was run. Whenever a record in the MMS LDAP 82 is modified, the date of the modification can be stored with the record in the MMS LDAP 82. Whenever a record is transferred into the Siemens DirX LDAP 60, the date of the transfer can be stored with the record in the Siemens DirX LDAP 60. When the synchronization process 70 is run, a record is transferred from the MMS LDAP 82 to the Siemens DirX LDAP 60 only if the modification date in the MMS LDAP 82 is later than the transfer date in the Siemens DirX LDAP 60. Thus, the first time the synchronization process 70 is run, all user records are transferred from the MMS LDAP 82 to the Siemens DirX LDAP 60. Thereafter, only the records that have been modified are transferred.

[0043] For the main external data store 84, a method for transferring data from an Oracle database to a Siemens DirX LDAP is needed. In an embodiment, a first step in accomplishing this is the creation by a script or other software routine within the synchronization process 70 of an attributes map that correlates the attributes of the user records in the Oracle database 84 into attributes in the Siemens DirX LDAP 60. Next, a connection is established between the Oracle database 84 and the Siemens DirX LDAP 60 by means of Java Database Connectivity. The synchronization process 70 then uses Structured Query Language to retrieve from the Oracle database 84 any user records that have been modified since the previous time the synchronization process 70 was run. These records are then converted, by means of the attributes map, into data that is compatible with the Siemens DirX LDAP 60. The converted records are stored in a file from which they can be read into the Siemens DirX LDAP 60 one at a time. If the Siemens DirX LDAP 60 does not contain any records for a particular user listed in the file, a new record is created. If a record already exists, it will be updated.

[0044] Other data stores 86 that do not use MMS LDAP or Oracle may each require a custom approach for transferring data to the Siemens DirX LDAP 60. In an embodiment, a single, repeatable transfer process within the synchronization process 70 is used for each such data store 86. A template is created with fields for the information that will be needed by the Siemens DirX LDAP 60. A script or other software routine within the synchronization process 70 retrieves the relevant data from each miscellaneous data store 86 and inserts the data into the template. The software routine then reads the data from the completed template and inserts the data into the Siemens DirX LDAP 60.

[0045] FIG. 2 illustrates a method for providing a single sign-on capability to multiple applications. In box 110, a first data store is provided. This data store might contain information on internal users within an enterprise such as employees and contractors. In box 120, a second data store is provided. This data store might contain information on users external to an enterprise such as customers. In another embodiment, contractors might be considered external, rather than internal, users. The information in the first and second data stores would typically include an identifying attribute for each user, such as a user ID number, as well as authorization information specifying the applications to which each user is allowed access and the roles each user is allowed to hold in each application.

[0046] In box 130, authorization information is extracted from the first and second data stores and, in box 140, the information is translated from the formats of the first and second data stores into the format of a third data store. In box 150, if an identifying attribute for a record in the first or second data stores is found to be a duplicate of an identifying attribute for another record in the first or second data stores, a new identifying attribute is assigned to one of the records. In another embodiment, the assignment of a new identifying attribute could occur before the translation process of box 140. The translated information, including any new identifying attributes, is loaded into the third data store in box 160. At this point, the third data store contains authorization information for all users in the first and second data stores and each user in the third data store has a unique identifying attribute.

[0047] In box 170, a user attempting to gain access to a first application provides identifying information, such as a user ID and a password, to the application. In an embodiment, the identifying information might be passed on to a policy server, such as the SiteMinder policy server, and the policy server might authenticate the user. A session cookie or some other type of token might be created at this point to indicate that the user has been authenticated. In box 180, the identifying information is compared to authorization information in the third data store to determine whether the user is authorized to gain access to the requested application. If the user is authorized, the user is given access to the application in box 190.

[0048] In box 200, the user attempts to gain access to a second application. In box 210, the policy server checks whether a token exists indicating that the user has been authenticated. In box 220, if the authentication token exists, the policy server determines whether the user is authorized to gain access to the second application. If the user is authorized, the user is given access to the second application in box 230.

[0049] A single sign-on database as described above may generally be implemented on a variety of different computer systems. FIG. 3 illustrates a typical, general-purpose computer system suitable for implementing the present invention. The computer system 1300 includes a processor 1332 (also referred to as a central processing unit or CPU) that is coupled to memory devices including primary storage devices 1336 (typically a read only memory, or ROM) and primary storage devices 1334 (typically a random access memory or RAM).

[0050] As is well known in the art, ROM acts to transfer data and instructions uni-directionally to CPU 1332, while RAM is used typically to transfer data and instructions in a bi-directional manner. Both storage devices 1334 and 1336 may include any suitable computer-readable media. A secondary storage medium 1338, which is typically a mass memory device, is also coupled bi-directionally to CPU 1332 and provides additional data storage capacity. The mass memory device 1338 is a computer-readable medium that may be used to store programs including computer code, data, and the like. Typically, mass memory device 1338 is a storage medium such as a non-volatile memory such as a hard disk or a tape which is generally slower than primary storage devices 1334 and 1336. Mass memory storage device 1338 may take the form of a magnetic or paper tape reader or some other well-known device. It will be appreciated that the information retained within the mass memory device 1338 may, in appropriate cases, be incorporated in standard fashion as part of RAM 1334 as virtual memory. A specific primary storage device 1334 such as a CD-ROM may also pass data uni-directionally to the CPU 1332.

[0051] CPU 1332 is also coupled to one or more input/output devices 1340 that may include, but are not limited to, devices such as video monitors, track balls, mice, keyboards, microphones, touch-sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting recognizers, or other well-known input devices such as, of course, other computers. Finally, CPU 1332 optionally may be coupled to a computer or telecommunications network, e.g., an internet network, or an intranet network, using a network connection as shown generally at 1312. With such a network connection, it is contemplated that CPU 1332 might receive information from the network, or might output information to the network in the course of performing the above-described method steps. Such information, which is often represented as a sequence of instructions to be executed using CPU 1332, may be received from and outputted to the network, for example, in the form of a computer data signal embodied in a carrier wave. The above-described devices and materials will be familiar to those of skill in the computer hardware and software arts.

[0052] In one embodiment, sequences of instructions may be executed substantially simultaneously on multiple CPUs, as for example a CPU in communication across network connections. Specifically, the above-described method steps may be performed across a computer network. Additionally, it will be recognized by one of skill in the art that the above method steps may be recognized as sets of computer codes and that such computer codes are typically stored in computer readable media such as RAM, ROM, hard discs, floppy discs, carrier waves, and the like.

[0053] While several embodiments have been provided in the present disclosure, it should be understood that the Single Sign-on Database may be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein, but may be modified within the scope of the appended claims along with their full scope of equivalents. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.

[0054] Also, techniques, systems, subsystems and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. Other items shown or discussed as directly coupled or communicating with each other may be coupled through some interface or device, such that the items may no longer be considered directly coupled to each but may still be indirectly coupled and in communication, whether electrically, mechanically, or otherwise, with one another. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made without departing from the spirit and scope disclosed herein.