Patent ID: 12199967

DETAILED DESCRIPTION

The invention and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known starting materials, processing techniques, components, and equipment are omitted so as not to unnecessarily obscure the invention in detail. It should be understood, however, that the detailed description and the specific examples, while indicating some embodiments of the invention, are given by way of illustration only and not by way of limitation. Various substitutions, modifications, additions, and/or rearrangements within the spirit and/or scope of the underlying inventive concept will become apparent to those skilled in the art from this disclosure.

Embodiments disclosed herein address the issue of how to isolate data while allowing colleagues to share data in a multitenant platform. For example, a particular cooperative organization may have member organizations that are each involved in a collaborative project. In the course of the collaborative project, each of the member organizations may utilize both shared data which is accessible to multiple member organizations and proprietary data which the respective member organizations may not wish to share with other member organizations. Thus, each member organization may need to be able to invite particular users who may be associated with other member organizations to access particular proprietary resources while preventing access to other proprietary resources. Thus, collaborators may access the resources as allowed by the owners of the resources, while maintaining the owners' control of the resources.

This issue is addressed by providing means to secure data by implementing data isolation with two-factor access control and user partitioning at the site level within a tenant. Embodiments may meet several needs that are not served by current systems. For example, it is desirable to enable one person with a single corresponding email address to access to different sites as two different users, each of which is under the control of a separate organization, where data is isolated between the two organizations. It is further desirable to enable developers to build applications that can share data within a single organization. It is also desirable to enable two different organizations that can access a particular application to share data across the organizations.

Embodiments disclosed herein therefore implement data isolation within a subscription with two-factor access control for data associated with an application that includes elements both internal to the application and external to the application. External control is implemented through a user entry point which is directly controlled by an application subscriber that is the owner of the data. By requiring that a user access the subscriber-owner's data through the entry point, the subscriber-owner can control (e.g., deny or revoke) the user's access to the data directly, without having to change the access controls implemented in the application. The subscriber-owner can also avoid the administrative burden of having to reconfigure access permissions with the application.

Embodiments disclosed herein further implement isolation of users within a tenant's subscription by enabling user partitioning within the tenant. This enables the control of users at the site level, rather than at the organizational level. User partitions are associated with individual sites, and the individual sites determine the access that associated users are granted to data for the corresponding sites. The user partitioning enables the sites to control the authentication required for users accessing data through the corresponding sites in order to maintain the desired level of security.

Referring toFIG.1, a diagrammatical representation of the two-factor access control implemented in embodiments of the present invention is shown. As depicted in the figure, a user gains access to data130via a user partition100, an entry point110and application120. Application120is implemented on a cloud-based multitenant application platform. Application120is a SaaS (software as a service) application which is available to tenants who subscribe to the application. The application implements access controls in order to secure the data of each tenant and to prevent unauthorized access to a tenant's data by other, unauthorized tenants. These access controls are commonly configurable within the application by an administrator of each tenant.

As noted above, however, it is desirable in some situations for a tenant to be able to have more direct control of user access to its data. Present embodiments therefore implement an additional layer of access control at an entry point. This additional access control is enabled by requiring the user to access the data through a designated entry point that is owned and controlled by the tenant. The tenant may, for example, maintain a login page, and may provide the URL for the login page to users to whom it wishes to grant data access. The tenant may maintain a list of authorized users which is associated with this login page, and may modify the list to directly control the users who can access the application and the tenants data through the login page. The tenant may therefore enable or deny the users access at the entry point, and may thereby control access external to the application itself. This may allow the tenant to control (e.g., revoke) the users access more quickly and easily than if it is necessary for an administrator of the tenant to reconfigure access permissions within the application.

Still another layer of access control is implemented through user partitions. Embodiments disclosed herein enable tenants to define user partitions which group together sets of users, where the different sets of users are subject to authentication requirements that are site-specific for that user. Thus, when a person logs in to a particular site, the site can control the authentication of the user, even if the user is external to the tenant that owns the site. The tenant/site therefore does not have to rely on the authentication of the external user's domain to ensure that the authentication meets the tenant's security requirements. The user partitions may also provide finer-grained access control by enabling tenants to define different sets of data that are accessible by different sets of users, even if the users access the data through the same application. Thus, for example, one set of users (e.g., internal users) may be allowed to access to all of the tenant's data that is available through an application, while another set of users (e.g., external users) may be allowed access to a more limited set of data that is related to a particular project on which the external user is collaborating which internal users of the tenant.

Referring toFIG.2, a diagrammatic representation of the structure of a multitenant application environment is shown. As depicted in this figure, a virtualization platform runs on a hardware layer202. The virtual machines of the virtualization layer204support an IaaS (infrastructure as a service) layer206. There may be several infrastructure tenants210that utilize the provided infrastructure for the cloud-based multitenant application platform208. At this level, deep isolation between the tenants may be provided by implementing separate tables and services for the different tenants. The separate isolation segments may be useful to allow developers to work without disrupting production, and may provide a level of isolation required by highly risk-adverse customers. Various services212may be built within container boundaries that are provisioned on the cloud-based platform. Multitenant applications that use these services can then be provided to tenants216of the cloud-based platform. The tenants have subscription-based access to the applications.

Each tenant may have subscriptions214to one or more applications that are executing on the multitenant platform. The tenant can provision in its own users who are associated with the tenant (e.g., employees or agents of the tenant organization). Each tenant manages its own users and allows these users to access the application through its subscription.

In prior art systems, tenants of applications (subscribers to the applications) are typically the only ones who can access their respective data in the applications. In other words, a first tenant can access its own data, but it cannot access the data of other tenants, nor can the other tenants access the first tenants data. Embodiments disclosed herein can enable tenants to access data across subscriptions, where authorized users of an application may use a designated entry point to access the data of tenants (subscribers) other than the tenant with which the user is associated. Thus, collaboration may be facilitated between users associated with a tenant and users that are external to the tenant, with respect to the tenant's data.

For example, a first tenant220may have subscriptions230and234to a first production application250and may store its own data on the multitenant platform through the application. Users internal to tenant220would normally have access to this data, but tenant220may also choose to enable access to this data by users of a different tenant (e.g., tenant222). In some embodiments, second tenant222may be required to have its own subscription232to the application in order to access data through the application, although this may not be required in some alternative embodiments. Tenants220and222may likewise have subscriptions236,238to other applications, such as beta application252, and may choose to enable access by internal and external users to the data of the respective tenants in application252. Application254is an example of an application that is dedicated to a single tenant224through a corresponding subscription240.

As noted above, user partitions can be implemented to facilitate control of access to a tenant's data. Before describing user partitioning as implemented in embodiments of the present invention, it may be helpful to describe user access in conventional systems. Referring toFIGS.3A-3C, a set of tables is shown to illustrate user access in a system in which there is no user partitioning and the primary tenant owns the user record. As shown inFIG.3A, the system enables tenant partitions, so that the data of each tenant is isolated from the date of the other tenants. Thus, the data of tenant Acme (acme com) is isolated from the data of tenants Midstate (midstate.com) and Zenith (zenith.com). For each of these tenants, the users associated with that tenant (as determined by the domains of the users' respective email addresses) fall within the partition of that tenant. In this example, users albert@acme.com and bob@acme.com are within the Acme partition, while users charles@midstate.com and david@midstate.com are within the Midstate partition, and user ed@zenith.com is within the Zenith partition.

Referring toFIG.3B, the association of each user with the corresponding tenant (and tenant domain) is graphically illustrated by the arrows. Because the system only provides partitioning of the tenant level, the users' access to the system is controlled at the tenant level. Thus, the authentication of a particular user is determined by the corresponding tenant, and the user's access to data is determined by the tenant. For example, user Charles (charles@midstate.com) falls within the Midstate tenant partition, so Midstate controls the authentication of this user. While this may not be problematic as long as each user only needs to access the resources of its own tenant, problems may arise when users attempt to collaborate across tenants.

Referring toFIG.3C, an example of the interaction between different users and different tenants is illustrated. In this example, a tenant may have one or more subscriptions to applications and may wish to allow users who are external to the tenant to access its resources through its subscribed applications. For example, tenant Acme may have subscriptions Acme-CFS F1, Acme-CFSF2, and Acme-CC1, and may allow access to users albert@acme.com, david@midstate.com and ed@zenith.com.

In the case of albert@acme.com, the user falls within the tenant partition of Acme, so Acme determines the authentication that is required for this user to access its subscriptions and its data. In the case of david@midstate.com, this user is associated with the Midstate tenant, so Midstate controls the authentication of the user. If Midstate's authentication requirements are more stringent than those of Acme, the authentication may not be cause for concern in allowing this user to access Acme's subscriptions and/or data. If, however, Midstate's authentication requirements are less stringent than those of Acme, the authentication of user david@midstate.com may not meet Acme's security requirements. For instance, if Acme requires two-factor authentication, but Midstate requires only single-factor authentication, it may be easier for a person to gain unauthorized access to Acme's resources through this user email address than through an email address associated with the acme.com domain.

Referring toFIGS.4A-4B, a set of tables illustrating the partitioning of users in accordance with some embodiments is shown.FIG.4Aillustrates the partitioning of users at the site level, rather than the tenant level.FIG.4Billustrates the access to application subscriptions granted by each tenant to different users.

Referring toFIG.4A, it can be seen that each tenant can configure one or more child partitions within the corresponding tenant partition. In this example, to tenants are indicated: Orange; and ABC. Each of the tenants have a native partition which is essentially equivalent to the conventional tenant partition. Each tenant also has several child partitions that correspond to different sites which are owned by the respective tenants. The tenants can specify for each of the sites a corresponding domain and a corresponding identity provider (IDP) or authentication service. Thus, for example, tenant Orange can configure a child partition for a first site which is identified as Orange-SAML1, which has the domain orange.com and specifies orange.com as the identity provider for authentication of users.

Each tenant can also specify users that are associated with their respective child partitions. The users may include users that are associated with the tenant (which owns the corresponding site), as well as users that are external to the tenant. In the example ofFIG.4A, the native partition of tenant Orange and the partitions for sites Orange-SAML1 and Orange-SAML2 include only internal users that are associated with the tenant (as identified by the orange.com domain in the users' email addresses). The partition for site Orange-SAML3, on the other hand, only includes external users that are associated with the XYZ.com domain. Tenant ABC has partitions that include users associated with multiple, different domains. The native partition of ABC includes both internal (john@ABC.com) and external (srini@orange.com) users. The partition for site ABC-SAML2 includes users from multiple domains that are external to tenant ABC.

Referring toFIG.4B, a table illustrating users' access to the various subscriptions of different tenants is shown. This table identifies sites owned by the tenants, the sites' subscriptions, the users that are allowed access to the subscriptions, and the partitions associated with the users. The left side of the table shows the associations between the sites and their subscriptions. For example, site orange (at domain orange.com), which has three subscriptions: Orange-CFSF1, Orange-CFSF2, and Orange-CC1. site ABC (at domain abc.com) has subscriptions to the same three applications. The ownership of the subscriptions is indicated by the “Orange-” or “ABC-” in the subscription names.

Each site determines the users that are allowed to access each of its subscriptions. In the example ofFIG.4B, access to subscription orange-CFSF1 is given to users srini@orange.com, nick@orange.com and ross@orange.eu. Access to subscription orange-CFSF2 is given to users srini@orange.com and ted@xyz.com, and access to Orange-CC1 is given to users ravi@orange.com and john@xyz.com.

As noted above in connection withFIG.4A, each site can configure user partitions that allow different users to be segregated into groups that are handled differently, particularly with respect to authentication. Thus, although users srini@orange.com, nick@orange.com and ross@orange.eu each have access to a common subscription (Orange-CFSF1), each of these users is assigned by the site to a different user partition. Specifically, srini@orange.com is assigned to the native partition of the site, nick@orange.com is assigned to partition Orange-SAML1, and ross@orange.eu is assigned to partition Orange-SAML2.

Each of the users is authenticated by the authentication service (identity provider) associated with the corresponding partition. Thus, srini@orange.com is authenticated by the default identity provider associated with the Orange site, nick@orange.com is authenticated by orange.com (which is defined for partition Orange-SAML1), and ross@orange.eu is authenticated by orange.eu (which is the defined identity provider for partition Orange-SAML2). Each of these three users must therefore be authenticated by a different identity provider prior to accessing subscribed application Orange-CFSF1.

Because each of the users that accesses a particular application is authenticated according to the user partition corresponding to the particular user, the owner of the subscription does not have to rely on the authentication requirements of the domain with which the user is associated. Instead, the subscription owner (the site) can control the authentication requirements by specifying the identity provider that must be used by users in a given user partition in order to access the subscription. Thus, if a user is granted access to multiple, different applications through different sites, the user may be authenticated using different authentication services at different times, providing different levels of security, depending upon which application (and corresponding data) is being accessed.

Effectively, a single person with a single corresponding email address may be considered to be two or more different users that are accessing applications through two or more different sites. Each of these users will have the same email address, but there is no conflict because each user exists only within the context of the corresponding site. When the user logs into a particular site through a designated entry point, the corresponding user partition is determined, the user is authenticated according to the user partition, and the authenticated user is given access to the site's subscription(s) according to the partition.

Consider, in the example ofFIGS.4A and4B, user srini@orange.com. This user is included in the native partitions of each of the orange and ABC sites. Thus, when srini@orange.com accesses subscription Orange-CFSF1, the user must be authenticated according to the requirements of the orange.com site, but when the user accesses subscription ABC-CFSF1, the user must be authenticated according to the requirements of the ABC.com site. Similarly, ted@xyz.com is included in the orange-SAML3 user partition of the orange site and the ABC-SAML2 partition of the ABC site, so when this user accesses the Orange-CFSF2 subscription, it must be authenticated according to orange.okta.com, but when the user accesses the ABC-CFSF1 subscription, the user must be authenticated according to abc.ping.com.

The use of the security mechanisms to enable a person to access different websites as two different users is illustrated inFIG.5. In this example, a person502has a single corresponding email address (email-address@example.com). In a conventional system, this person could only be a single user having this email address, and this user would be authenticated according to the authentication service used by the corresponding domain. In the present embodiments, person502can log on to two or more different sites, and will be treated as a different user in each of these sites. The user in each site will fall within a corresponding user partition and will be authenticated by the authentication service designated for the respective one of the sites.

In the example ofFIG.5, person502can sign in to a first (blue) site510as a first user504. Site510determines the user partition of user504and identifies the corresponding one of the authentication systems (522-524) which is designated for the user partition. Person502then interacts with the identified one of the authentication systems to authenticate the person as user504. The authentication system may use any of a variety of authentication methods, such as single-factor, two-factor or multi-factor authentication, and the designated authentication system will have previously been selected by the owner of site510based on the sufficiency of the employed authentication methods. Person502will also interact with authorization system520, which will determine whether or not the person is authorized to access the resources of site510as user504.

When person502has been authenticated and authorized to access the resources of site510as user504, the user may access one of the application subscriptions of the site through an available entry point. In this case, user504may access application A through a first entry point530or application B through a second entry point532when user504accesses the applications through one of these entry points, and access list for the corresponding entry point is checked to ensure that the user is allowed to access the corresponding application. If user504is allowed to access the application, access is allowed to the resources on server540. The user may then proceed to use the application and access data as needed to perform the desired tasks/functions.

While person502is logged into the first site (510) as user504, the person may also log into a second (green) site512as a second user506. User506will have the same identifying email address as user504, but is treated as a separate user. User506will login to site512in a manner similar to that of user504. Site512will determine a user partition associated with person502, but the user partitions in this case may be different from those used by site510. Site512may have a different owner than site510, or may have the same owner, but distinct purposes and requirements which require the use of different user partitions. When site512has identified the user partition of user506, it can identify the designated authentication system (e.g., one of a plurality of authentication systems526-528), and person502will proceed to authenticate user506with the designated authentication system. Person502will further interact with authorization system520, and this system will determine whether or not the person is authorized to access the resources of site512as user506.

When user506has been authenticated and it has been determined that the user is authorized to access the resources of site512, the user may attempt to access the resources through an application having a corresponding entry .534. In this example, only a single entry point is available to allow user506two access the resources of site512. When user506attempts to access this entry point, a corresponding access list is examined to determine whether or not the user has been granted access to the application via the entry point. If user506is included on the access list for the entry point, the user is allowed to proceed to access the resources on server542.

As noted above, users504and506, although having a common email address, are treated as different users. Consequently, although a single person having a single email address is accessing the resources of both site510and512, the system does not share data across the site boundaries.

Referring toFIG.6, an entity relationship diagram illustrating one embodiment of a system that implements access control as described herein is shown. As noted above, there may be one or more applications executing on the multitenant platform. Each of these applications is accessible through a subscription to the application. The subscription is associated with a specific tenant which may have multiple users associated with it. The users associated with the tenant are associated with the application through the tenant's subscription and may therefore be considered subscription users who are authorized to access the application. The subscription users may each be included in one or more user partitions that may be associated with the subscription and/or the application. These user partitions may be associated with corresponding authentication services and levels of access, so that when a tenant subscriber assigns a particular user to a specific user partition, the user will be authenticated according to the authentication service designated in the user partition and given the levels of access that are associated with the user partition.

In the embodiment ofFIG.6, the tenants subscription to the application is associated with a unique DNS domain. This unique domain is used as an entry point for a user to obtain service from the application and thereby access the tenants data. The user's access through the designated entry point may be subject to various access constraints. For example, one constraint is that the user must access the data through the designated entry point. The application may require that the user be included in a subscription list that is associated with the entry point. Additionally, in this embodiment, the user must have been authenticated by the authentication service designated by the tenant in the user partition for the user, and must have acquired appropriate tokens for accessing the application. Further, the permission of the user to access data may be application specific and may particularly specify the user's ability to access data across subscriptions and/or across tenants.

A subscriber tenant's delegation of access to its data through the use of role assignments or the direct provisioning of access is normally accomplished through the application and is limited to the users who are associated with the subscriber tenant (e.g., the tenant's employees). There may be circumstances, however, in which the subscriber tenant wishes to share access to its data with other users who are external to the tenant. Embodiments disclosed herein enable this type of access using a form of multi-factor access control. In these embodiments, the factors required for a user to access a first subscriber tenant's data associated with an application include the user being authenticated according to the identity provider (authentication service) identified in the corresponding user partition. The user must have subscription access to the application, though not necessarily through the subscriber tenant. The user must also access the data through an entry point which is designated by the subscriber tenant.

This provides the ability to control access to the data at several different levels. First, because the user must have subscription access to the application, control may be exercised through the application itself—the users access level may be controlled through normal management of access control lists, access levels associated with roles, direct delegation of access levels, etc. Second, because the user must access the data through a designated entry point (e.g., a URL controlled by the tenant subscriber), control may be exercised by the tenant subscriber (the owner of the data) external to the application through the management of the designated entry point. The tenant subscriber may thereby control access to the data external to the application itself by managing user access at the entry point. Allowing the tenant subscriber to control access at the entry point may provide a faster, simpler, and more convenient means to control access to its data (for example, by revoking a user's access at the entry point).

In one embodiment, a user logs into an application on a multitenant platform. The application is a subscription-based application and the user may be associated with a tenant that has a subscription to the application. When the user logs into the application, the user is authenticated and acquires a token having subscription scope (i.e., the token identifies the user as a known tenant-user with access to the application through the subscription of an associated tenant. The user can then attempt to access a URL that is an entry point for access to the data of another tenant subscriber (i.e., a tenant subscriber other than the one with which the user is associated). The entry point will then determine whether the user is identified as being authorized to access the data. If the user is authorized to access the data through the entry point, the user's access to the data will be allowed. Otherwise, the user will be prevented from accessing the data.

In some embodiments, the user attempting to access a first tenant subscriber's data must be authenticated through the first tenant subscriber. Users who have been authenticated and have obtained a token to access a first subscription may attempt to access a different subscription. If the user is in subscription lists for both subscriptions, the user may not be required to re-authenticate in order to access the second subscription (a single sign-on, or SSO, experience), unless the user has access to the different subscriptions through different user partitions that require different authentications. If the user attempting to access the second subscription is not on the subscription list for the second application, the user may be required to acquire a separate token to access the second subscription. The same data may, in some cases, be accessible from different subscriptions, depending upon the application. This may be determined by the application itself, while other applications may allow policies to be configured to allow or disallow access to the same data from different subscriptions.

Embodiments disclosed herein can provide a customer with control of a user's experience on the application when it is used to access the customers data. The user's experience may be through a web interface, a mobile device, or a desktop device. In the web-based experience, the user accesses the application through a domain name controlled by the customer and the customer performs the authentication of the user. The application is presented with the customer's “skin”. When the application is accessed through a mobile or desktop device, API access will be through the customer domain name and authentication will be performed by the customer. Again, the application will use the customer's skin for the user's experience.

The customer has control over the users who are allowed to access their data. This may be accomplished by, for example, the customer explicitly listing the names of individuals in both internal and external organizations who are allowed to access the data. The customer may remove individuals from the list or otherwise update the list in order to immediately change the ability of individual users to access the data. The user may be able to push the access list up from their Active Directory and may be able to manage it in the Active Directory.

The customer in this embodiment has control over the authentication rules that govern access by users to the customers data. This may include, for example, controlling the rules for authentication (e.g., two-factor authentication, password strength, etc.).

Embodiments disclosed herein provide technical solutions and benefits to the problems noted above, such as by implementing two-factor access control in applications executing on a multitenant platform so that data owners can exercise direct control over access to their data through the applications, and by partitioning users at the site level so that user access to data and applications can be differentiated between groups of users and so that user authentication can be controlled for both internal and external users of the system. Data owners can exercise this control both through the applications, and external to the applications. External control (via the entry point to the application, such as a login page) can be exercised without having to go through the application itself and may provide faster and more convenient means to control access.

Those skilled in the relevant art will appreciate that the invention can be implemented or practiced with other computer system configurations, including without limitation multi-processor systems, network devices, mini-computers, mainframe computers, data processors, and the like. The invention can be embodied in a computer, or a special purpose computer or data processor that is specifically programmed, configured, or constructed to perform the functions described in detail herein. The invention can also be employed in distributed computing environments, where tasks or modules are performed by remote processing devices, which are linked through a communications network such as a local area network (LAN), wide area network (WAN), and/or the Internet. In a distributed computing environment, program modules or subroutines may be located in both local and remote memory storage devices. These program modules or subroutines may, for example, be stored or distributed on computer-readable media, including magnetic and optically readable and removable computer discs, stored as firmware in chips, as well as distributed electronically over the Internet or over other networks (including wireless networks). Example chips may include Electrically Erasable Programmable Read-Only Memory (EEPROM) chips. Embodiments discussed herein can be implemented in suitable instructions that may reside on a non-transitory computer readable medium, hardware circuitry or the like, or any combination and that may be translatable by one or more server machines. Examples of a non-transitory computer readable medium are provided below in this disclosure.

As is known to those skilled in the art, a suitable computer system can include a central processing unit (“CPU”), at least one read-only memory (“ROM”), at least one random access memory (“RAM”), at least one hard drive (“HD”), and one or more input/output (“I/O”) device(s). The I/O devices can include a keyboard, monitor, printer, electronic pointing device (for example, mouse, trackball, stylus, touch pad, etc.), or the like. ROM, RAM, and HD are non-transitory computer memories for storing computer-executable instructions executable by the CPU or capable of being compiled or interpreted to be executable by the CPU.

Suitable computer-executable instructions may reside on a non-transitory computer readable medium (e.g., ROM, RAM, and/or HD), hardware circuitry or the like, or any combination thereof. Within this disclosure, the term “non-transitory computer readable medium” is not limited to ROM, RAM, and HD and can include any type of data storage medium that can be read by a processor. Examples of non-transitory computer-readable storage media can include, but are not limited to, volatile and non-volatile computer memories and storage devices such as random access memories, read-only memories, hard drives, data cartridges, direct access storage device arrays, magnetic tapes, floppy diskettes, flash memory drives, optical data storage devices, compact-disc read-only memories, and other appropriate computer memories and data storage devices. Thus, a computer-readable medium may refer to a data cartridge, a data backup magnetic tape, a floppy diskette, a flash memory drive, an optical data storage drive, a CD-ROM, ROM, RAM, HD, or the like.

The processes described herein may be implemented in suitable computer-executable instructions that may reside on a computer readable medium (for example, a disk, CD-ROM, a memory, etc.). Alternatively, the computer-executable instructions may be stored as software code components on a direct access storage device array, magnetic tape, floppy diskette, optical storage device, or other appropriate computer-readable medium or storage device.

Any suitable programming language can be used to implement the routines, methods or programs of embodiments of the invention described herein, including C, C++, Java, JavaScript, HTML, or any other programming or scripting code, etc. Other software/hardware/network architectures may be used. For example, the functions of the disclosed embodiments may be implemented on one computer or shared/distributed among two or more computers in or across a network. Communications between computers implementing embodiments can be accomplished using any electronic, optical, radio frequency signals, or other suitable methods and tools of communication in compliance with known network protocols.

Different programming techniques can be employed such as procedural or object oriented. Any particular routine can execute on a single computer processing device or multiple computer processing devices, a single computer processor or multiple computer processors. Data may be stored in a single storage medium or distributed through multiple storage media, and may reside in a single database or multiple databases (or other data storage techniques). Although the steps, operations, or computations may be presented in a specific order, this order may be changed in different embodiments. In some embodiments, to the extent multiple steps are shown as sequential in this specification, some combination of such steps in alternative embodiments may be performed at the same time. The sequence of operations described herein can be interrupted, suspended, or otherwise controlled by another process, such as an operating system, kernel, etc. The routines can operate in an operating system environment or as stand-alone routines. Functions, routines, methods, steps, and operations described herein can be performed in hardware, software, firmware or any combination thereof.

Embodiments described herein can be implemented in the form of control logic in software or hardware or a combination of both. The control logic may be stored in an information storage medium, such as a computer-readable medium, as a plurality of instructions adapted to direct an information processing device to perform a set of steps disclosed in the various embodiments. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the invention.

It is also within the spirit and scope of the invention to implement in software programming or code an of the steps, operations, methods, routines or portions thereof described herein, where such software programming or code can be stored in a computer-readable medium and can be operated on by a processor to permit a computer to perform any of the steps, operations, methods, routines or portions thereof described herein. The invention may be implemented by using software programming or code in one or more digital computers, by using application specific integrated circuits, programmable logic devices, field programmable gate arrays, optical, chemical, biological, quantum or nano-engineered systems, components, and mechanisms may be used. In general, the functions of the invention can be achieved by any means as is known in the art. For example, distributed, or networked systems, components, and circuits can be used. In another example, communication or transfer (or otherwise moving from one place to another) of data may be wired, wireless, or by any other means.

A “computer-readable medium” may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, system, or device. The computer readable medium can be, by way of example only but not by limitation, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, system, device, propagation medium, or computer memory. Such computer-readable medium shall generally be machine readable and include software programming or code that can be human readable (e.g., source code) or machine readable (e.g., object code). Examples of non-transitory computer-readable media can include random access memories, read-only memories, hard drives, data cartridges, magnetic tapes, floppy diskettes, flash memory drives, optical data storage devices, compact-disc read-only memories, and other appropriate computer memories and data storage devices. In an illustrative embodiment, some or all of the software components may reside on a single server computer or on any combination of separate server computers. As one skilled in the art can appreciate, a computer program product implementing an embodiment disclosed herein may comprise one or more non-transitory computer readable media storing computer instructions translatable by one or more processors in a computing environment.

A “processor” includes any, hardware system, mechanism or component that processes data, signals or other information. A processor can include a system with a central processing unit, multiple processing units, dedicated circuitry for achieving functionality, or other systems. Processing need not be limited to a geographic location, or have temporal limitations. For example, a processor can perform its functions in “real-time,” “offline,” in a “batch mode,” etc. Portions of processing can be performed at different times and at different locations, by different (or the same) processing systems.

As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, product, article, or apparatus that comprises a list of elements is not necessarily limited only those elements but may include other elements not expressly listed or inherent to such process, product, article, or apparatus.

Furthermore, the term “or” as used herein is generally intended to mean “and/or” unless otherwise indicated. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present). As used herein, including the accompanying appendices, a term preceded by “a” or “an” (and “the” when antecedent basis is “a” or “an”) includes both singular and plural of such term, unless clearly indicated otherwise (i.e., that the reference “a” or “an” clearly indicates only the singular or only the plural). Also, as used in the description herein and in the accompanying appendices, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.

Although the foregoing specification describes specific embodiments, numerous changes in the details of the embodiments disclosed herein and additional embodiments will be apparent to, and may be made by, persons of ordinary skill in the art having reference to this disclosure. In this context, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of this disclosure. The scope of the present disclosure should be determined by the following claims and their legal equivalents.