Authorization based on access token

FIELD

0001The present invention relates generally to user authentication on a mobile device to request access from various servers in a network environment.

BACKGROUND

0002As mobile solutions and mobile applications become increasingly complex, so do security protocols and user authentication protocols. As mobile devices are increasingly shared via schemes as “bring your own device” or BYOD in the work environment, users with different security access levels may wish to access work data on their own mobile devices, using many different non-secure applications/programs, or 3^rdparty apps. To provide such accesses from many different users on different mobile devices with different 3^rdparty apps, the user authentication system may become burdensome, and access request schemes may be too complex and difficult to use for portability with most 3^rdparty apps.

0003Thus, there is a need to have devices or systems that can handle authentication with different users on different mobile devices with different 3^rdparty apps efficiently without significant complexity to programs/applications on the mobile device.

BRIEF DESCRIPTION OF THE DRAWINGS

0004<figref idref="DRAWINGS">FIG. 1</figref> illustrates an exemplary mobile device in a communication network according to an embodiment.

0005<figref idref="DRAWINGS">FIG. 2</figref> illustrates an exemplary process according to an embodiment.

0006<figref idref="DRAWINGS">FIG. 3</figref> illustrates an exemplary process according to an embodiment.

0007<figref idref="DRAWINGS">FIGS. 4A and 4B</figref> illustrate an exemplary user interface and process for defining client usage scope according to an embodiment.

0008<figref idref="DRAWINGS">FIG. 5</figref> illustrates an exemplary system according to an embodiment.

DETAILED DESCRIPTION

0009<figref idref="DRAWINGS">FIG. 1</figref> illustrates an exemplary mobile device <b>110</b> in a communication network <b>100</b> according to an embodiment.

0010According to an embodiment, in a network <b>100</b>, a client/mobile device <b>110</b> on the client side may include an authenticator <b>112</b>, which may generate and/or store a secure token <b>114</b> (e.g., a segment of data or alpha-numerical sequence), and a processor <b>116</b> configured to execute one or more programs/applications (third party applications, or 3^rdparty apps) that requests access from the servers <b>130</b>. On the back end side, servers <b>130</b> may include a register <b>132</b> storing profiles of mobile clients with respective secure tokens in a database <b>134</b>, the plurality of tokens associated with a plurality of profiles, and a server processor <b>136</b> for processing data requests from the mobile device <b>110</b> and other server functions.

0011The servers <b>130</b> may be a cluster of servers in the same local network, or in different local networks. The client <b>110</b> may communicate with the servers <b>130</b> via a connection <b>190</b>. The authenticator <b>112</b> may store profiles with tokens each corresponding to specific tokens and/or profiles stored in the register <b>132</b> on the servers <b>130</b>.

0012On the mobile device <b>110</b>, the authenticator <b>112</b> may register individual programs and applications that are specifically allowed to interface with the authenticator <b>112</b> to receive keys/tokens to be used for requesting access by the programs and applications from the servers <b>130</b>. The authenticator <b>112</b> on the mobile device <b>110</b> may create user profiles for different individual users, and/or different profiles for specific data repositories or servers that the user registered access authentication for. In doing so, different authentication register <b>132</b> may be handled by the authenticator <b>112</b> for different users.

0013<figref idref="DRAWINGS">FIG. 1</figref> illustrates an exemplary user authentication for the mobile device <b>110</b> to request access from the servers <b>130</b>.

0014During authentication, the user may initiate the authenticator <b>112</b> by logging in on the mobile device <b>110</b>. The mobile device <b>110</b> and/or the authenticator <b>112</b> may request the user for initial authentication via a password or a pin as a first step. The user may select a program or application to be executed in the processor <b>116</b> on the mobile device <b>110</b>, to request access to at least one of the data repositories associated with the register <b>132</b> the servers <b>130</b>.

0015The authenticator <b>112</b> may generate an authorization request with a secure token <b>114</b> to access the server <b>130</b>. The authenticator <b>112</b> may embed the authorization request with a plurality of parameters to allow the server <b>130</b> to determine, based upon at least one of the plurality of parameters, if the authorization token should be given to the mobile device <b>110</b>. The processor <b>116</b> may access the server <b>130</b> using an authorization token, if the authenticator <b>112</b> receives the authorization token in response to the authorization request.

0016Based upon the user's own login identification information (such as a username, or an email address, etc.), as well as other parameter information (such as which 3^rdparty app is selected, data repository, requested data portion, requested data function, etc.) on the mobile device <b>110</b>, the authenticator <b>112</b> may form the authorization request by embedding the authorization request with the secure token <b>114</b> (for the appropriate server <b>130</b>) and a plurality of parameters. The parameters may include information generated by the user's selections in the program or application executing in the processor <b>116</b>. Some of the parameters may be collectively associated with “scope” of usage.

0017In this fashion, the secure token <b>114</b> used by the mobile device <b>110</b> need not be modified to include additional complex data structure.

0018The tokens (secure or authorization) may be generated based partly on the secret, and partly on a temporary number that's common to the mobile device <b>110</b> and the server <b>130</b>, for example, the web session ID number or a time-stamp associated with the request for access. The key/token may be generated using a predetermined algorithm using the secret, such as a symmetric key algorithm, a RSA algorithm, a AES algorithm, a DES algorithm, etc. . . .

0019The register <b>132</b> in the server <b>130</b> may handle the authorization request from the mobile device <b>110</b>. The register <b>132</b> may parse out the authorization request into the secure token and the parameters for verification.

0020The register <b>132</b> may compare or match the secure token and the parameters in the authorization request to the profile information stored in the database <b>134</b>. This comparing or matching may be done by for example, (1) checking if the specific mobile client device <b>110</b> and the 3^rdparty application are registered in any of the profiles in the database <b>134</b>, (2) checking if the secure token corresponds to the requesting mobile client device <b>110</b> and the 3^rdparty application in the profile information, (3) checking if the secure token received is still valid, (4) checking to see if the requested “scope” of usage from the mobile device <b>110</b> is within the defined security level for the specific requesting mobile client device <b>110</b> and the 3^rdparty application. If any of the conditions (1)-(4) fails the checking by the register <b>132</b>, the register <b>132</b> may decline to send an authorization token back to the mobile device <b>110</b>, and/or send notification to the mobile device <b>110</b> as appropriate.

0021The authorization token may be a temporary (or one-time) token generated by the register <b>132</b>, specific for the mobile client <b>110</b> and the 3^rdparty application requesting the authorization. The authorization token may be sent to the mobile device <b>110</b> with a renewal token. Additionally, another authorization token for a different 3^rdparty application may be sent to the mobile device <b>110</b>, based upon validation of the secure token and the requested scope, if the requested scope is for access authorization of the different 3^rdparty application. The renewal token may be later used by the mobile device <b>110</b> to renew its authorization token, such that a previously authorized mobile device <b>110</b> and the 3^rdparty application (with the same usage “scope”) combination would not require another authentication through the authenticator, and the 3^rdparty application under such circumstances would only need to request a renewal of the authorization token by sending a request directly to the register <b>132</b> with the renewal token to obtain a new authorization token.

0022If a mobile device is stolen or lost then it only has to be unregistered from the backend system. This step may be sufficient because it does not contain the actual password of the user for the backend system. Shared mobile devices can be supported by having user profiles in the authenticator app.

0023<figref idref="DRAWINGS">FIG. 2</figref> illustrates an exemplary process <b>200</b> for authenticating the client device <b>110</b>, according to an embodiment.

0024<figref idref="DRAWINGS">FIG. 3</figref> illustrates a similar exemplary process <b>300</b> for authenticating the client device <b>110</b>, illustrated in hardware data flow format, according to an embodiment.

0025According to an embodiment, at <b>210</b>, the process <b>200</b> may begin with the user logging onto the mobile device <b>110</b>, select a 3^rdparty app to be executed in the processor <b>116</b>, and select other parameters for the request to the server. The parameters may also include the user's login identification information. The 3^rdparty app may send relevant information as request for authorization to the authenticator <b>112</b>.

0026At <b>220</b>, the authenticator <b>112</b> may generate a request for authorization, embedded with an appropriately selected secure token that corresponds to the 3^rdparty app, and also embedded with parameter information.

0027At <b>230</b>, the register <b>132</b> may receive and parse the request for authorization from the authenticator <b>112</b>, and then compare with profile information stored in the database <b>134</b>.

0028At <b>240</b>, the register <b>132</b> may check if the specific mobile client device <b>110</b> and the 3^rdparty application are registered in any of the profiles in the database <b>134</b>. If not, the authorization fails at <b>270</b>.

0029At <b>250</b>, the register <b>132</b> may check if the secure token corresponds to the requesting mobile client device <b>110</b> and the 3^rdparty application in the profile information, and/or if the secure token received is still valid. If not, the authorization fails at <b>270</b>.

0030At <b>260</b>, the register <b>132</b> may check if the requested “scope” of usage from the mobile device <b>110</b> is within the defined security level for the specific requesting mobile client device <b>110</b> and the 3^rdparty application. If not, the authorization fails at <b>270</b>.

0031At <b>270</b>, the authorization fails.

0032At <b>280</b>, if the authentication is successful in <b>240</b>-<b>260</b>, then the register <b>132</b> may generate an authorization token (and the renewal token) to be sent to the authenticator <b>112</b>, which then may pass the authorization token (and the renewal token) to the processor <b>116</b> and the 3^rdparty app to allow access to the server <b>130</b>.

0033Having the previous step completed, the 3rd party app on mobile device <b>110</b> may have a valid authorization token, which could be used for reaching protected resources/data within the “scope” of usage from server <b>130</b>.

0034The server <b>130</b> may be in communication with configured Clients (SSO Client, Client<b>1</b>, Client<b>2</b>, . . . , ClientN), and configured scopes (Scope<b>1</b>, Scope<b>2</b>, . . . , ScopeM). The various scopes may include data deletion, data modification, data read, data write, data query, etc., as well as specific functions, or specific webpages.

0035A scope may be assigned/associated to a specific 3^rdparty app on a specific mobile device, and the scope may be configured and stored in association to a specific profile associated with the specific 3^rdparty app of a specific mobile device. An authorization token may be issued if a valid pair of (3^rdparty app-Scope) is provided as parameters embedded in a request for authorization.

0036<figref idref="DRAWINGS">FIGS. 4A and 4B</figref> illustrate an exemplary user interface and process for defining client usage scope according to an embodiment.

0037An user with authorized access, such as a system administrator, may register and configure mobile devices and 3^rdparty apps via the register <b>132</b>, by for example, using an user interface (UI) <b>401</b> as illustrated in <figref idref="DRAWINGS">FIG. 4A</figref>.

0038According to an embodiment of <figref idref="DRAWINGS">FIG. 4B</figref>, at <b>410</b>, the process <b>400</b> may begin with the user may specify a scope name.

0039At <b>420</b>, the user may specify a scope's description.

0040At <b>430</b>, the user may specify a scope's usage type.

0041At <b>440</b>, the register <b>132</b> may determine whether the scope usage type is general or specific.

0042At <b>450</b>, if the scope usage type is specific, then the user may select specific 3^rdparty apps on specific mobile devices allowed for the specific scope. The specific scope may be configured or created by the user, and then associated with specific 3^rdparty apps on specific mobile devices allowed for the specific scope.

0043At <b>460</b>, if the scope usage type is general, or the scope usage type is specific and associated with specific 3^rdparty apps and devices, then the scope usage is defined and the scope usage information may be stored as scope configuration, for example, as part of the profile information in database <b>136</b>.

0044As part of authentication/authorization, the register <b>132</b> may retrieves all details from database <b>134</b> related to the parameters in the request for authorization. This may include expiration details, scopes that were requested when previous authorization were issued. Based on the previous requested scopes, the register <b>132</b> may extract the authorized scopes. This calculated list of scopes may be compared against the list of scopes that are part of the new Authorization request. If all requested scopes are within the Calculated Scopes list, then the register <b>132</b> may allow new authorization, otherwise the authorization may fail.

0045Some embodiments may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They maybe linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.

0046Aspects of the above may be implemented by software, firmware, hardware, or any combination thereof. <figref idref="DRAWINGS">FIG. 5</figref> illustrates an example computer system <b>500</b> in which the above, or portions thereof, may be implemented as computer-readable code. Various embodiments of the above are described in terms of this example computer system <b>500</b>. The client device <b>110</b> and the server <b>130</b> may each be a computer system <b>500</b>.

0047Computer system <b>500</b> includes one or more processors, such as processor <b>504</b>. Processor <b>504</b> can be a special purpose processor or a general purpose processor. Processor <b>504</b> is connected to a communication infrastructure <b>502</b> (for example, a bus or a network).

0048Computer system <b>500</b> also includes a main memory <b>506</b>, preferably Random Access Memory (RAM), containing possibly inter alia computer software and/or data <b>508</b>.

0049Computer system <b>500</b> may also include a secondary memory <b>510</b>. Secondary memory <b>510</b> may include, for example, a hard disk drive <b>512</b>, a removable storage drive <b>514</b>, a memory stick, etc. A removable storage drive <b>514</b> may comprise a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, or the like. A removable storage drive <b>514</b> reads from and/or writes to a removable storage unit <b>516</b> in a well-known manner. A removable storage unit <b>516</b> may comprise a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive <b>514</b>. As will be appreciated by persons skilled in the relevant art(s) removable storage unit <b>516</b> includes a computer usable storage medium <b>518</b> having stored therein possibly inter alia computer software and/or data <b>520</b>.

0050In alternative implementations, secondary memory <b>510</b> may include other similar means for allowing computer programs or other instructions to be loaded into computer system <b>500</b>. Such means may include, for example, a removable storage unit <b>524</b> and an interface <b>522</b>. Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an Erasable Programmable Read-Only Memory (EPROM), or Programmable Read-Only Memory (PROM)) and associated socket, and other removable storage units <b>524</b> and interfaces <b>522</b> which allow software and data to be transferred from the removable storage unit <b>524</b> to computer system <b>500</b>.

0051Computer system <b>500</b> may also include an input interface <b>526</b> and a range of input devices <b>528</b> such as, possibly inter alia, a keyboard, a mouse, etc.

0052Computer system <b>500</b> may also include an output interface <b>530</b> and a range of output devices <b>532</b> such as, possibly inter alia, a display, one or more speakers, etc.

0053Computer system <b>500</b> may also include a communications interface <b>534</b>. Communications interface <b>534</b> allows software and/or data <b>538</b> to be transferred between computer system <b>500</b> and external devices. Communications interface <b>534</b> may include a modem, a network interface (such as an Ethernet card), a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, or the like. Software and/or data <b>538</b> transferred via communications interface <b>534</b> are in the form of signals <b>536</b> which may be electronic, electromagnetic, optical, or other signals capable of being received by communications interface <b>534</b>. These signals <b>536</b> are provided to communications interface <b>534</b> via a communications path <b>540</b>. Communications path <b>540</b> carries signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, a Radio Frequency (RF) link or other communications channels.

0054As used in this document, the terms “computer program medium,” “computer usable medium,” and “computer readable medium” generally refer to media such as removable storage unit <b>516</b>, removable storage unit <b>524</b>, and a hard disk installed in hard disk drive <b>512</b>. Signals carried over communications path <b>540</b> can also embody the logic described herein. Computer program medium and computer usable medium can also refer to memories, such as main memory <b>506</b> and secondary memory <b>510</b>, which can be memory semiconductors (e.g. Dynamic Random Access Memory (DRAM) elements, etc.). These computer program products are means for providing software to computer system <b>500</b>.

0055Computer programs (also called computer control logic) are stored in main memory <b>506</b> and/or secondary memory <b>510</b>. Computer programs may also be received via communications interface <b>534</b>. Such computer programs, when executed, enable computer system <b>500</b> to implement the present invention as discussed herein. In particular, the computer programs, when executed, enable processor <b>504</b> to implement the processes of aspects of the above. Accordingly, such computer programs represent controllers of the computer system <b>500</b>. Where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system <b>500</b> using removable storage drive <b>514</b>, interface <b>522</b>, hard drive <b>512</b> or communications interface <b>534</b>.

0056The invention is also directed to computer program products comprising software stored on any computer useable medium. Such software, when executed in one or more data processing devices, causes data processing device(s) to operate as described herein. Embodiments of the invention employ any computer useable or readable medium, known now or in the future. Examples of computer useable mediums include, but are not limited to, primary storage devices (e.g., any type of random access memory), secondary storage devices (e.g., hard drives, floppy disks, Compact Disc Read-Only Memory (CD-ROM) disks, Zip disks, tapes, magnetic storage devices, optical storage devices, Microelectromechanical Systems (MEMS), nanotechnological storage device, etc.), and communication mediums (e.g., wired and wireless communications networks, local area networks, wide area networks, intranets, etc.).

0057It is important to note that the particulars of <figref idref="DRAWINGS">FIG. 5</figref> (such as for example the specific components that are presented, the component arrangement that is depicted, etc.) are illustrative only and it will be readily apparent to one of ordinary skill in the relevant art that numerous alternatives (including inter alia other or different components, alternative arrangements, etc.) are easily possible.

0058The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. Examples of computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment of the disclosure may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment of the disclosure may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.

0059A data provider may be an information resource. Data provider may include sources of data that enable data storage and retrieval. Data provider may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., Online Analytic Processing—OLAP), object oriented databases, and the like. Further data provider may include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open DataBase Connectivity (ODBC), produced by an underlying software system (e.g., Enterprise resource planning system), and the like. These data providers can include associated data foundations, semantic layers, management systems, security systems and so on.

0060A semantic layer is an abstraction overlying one or more data sources. It removes the need for a user to master the various subtleties of existing query languages when writing queries. The provided abstraction includes metadata description of the data sources. The metadata can include terms meaningful for a user in place of the logical or physical descriptions used by the data source. For example, common business terms in place of table and column names. These terms can be localized and or domain specific. The semantic layer may include logic associated with the underlying data allowing it to automatically formulate queries for execution against the underlying data sources. The logic includes connection to, structure for, and aspects of the data sources. Some semantic layers can be published, so that it can be shared by many clients and users. Some semantic layers implement security at a granularity corresponding to the underlying data sources' structure or at the semantic layer. The specific forms of semantic layers includes data model objects that describe the underlying data source and define dimensions, attributes and measures with the underlying data. The objects can represent relationships between dimension members, and can provide calculations associated with the underlying data.

0061It is appreciated that the disclosure is not limited to the described embodiments, and that any number of scenarios and embodiments in which conflicting appointments exist may be resolved.

0062Although the disclosure has been described with reference to several exemplary embodiments, it is understood that the words that have been used are words of description and illustration, rather than words of limitation. Changes may be made within the purview of the appended claims, as presently stated and as amended, without departing from the scope and spirit of the disclosure in its aspects. Although the disclosure has been described with reference to particular means, materials and embodiments, the disclosure is not intended to be limited to the particulars disclosed; rather the disclosure extends to all functionally equivalent structures, methods, and uses such as are within the scope of the appended claims.

0063While the computer-readable medium may be described as a single medium, the term “computer-readable medium” includes a single medium or multiple media, such as a centralized or distributed database, and/or associated caches and servers that store one or more sets of instructions. The term “computer-readable medium” shall also include any medium that is capable of storing, encoding or carrying a set of instructions for execution by a processor or that cause a computer system to perform any one or more of the embodiments disclosed herein.

0064The computer-readable medium may comprise a non-transitory computer-readable medium or media and/or comprise a transitory computer-readable medium or media. In a particular non-limiting, exemplary embodiment, the computer-readable medium may include a solid-state memory such as a memory card or other package that houses one or more non-volatile read-only memories. Further, the computer-readable medium may be a random access memory or other volatile re-writable memory. Additionally, the computer-readable medium may include a magneto-optical or optical medium, such as a disk or tapes or other storage device to capture carrier wave signals such as a signal communicated over a transmission medium. Accordingly, the disclosure is considered to include any computer-readable medium or other equivalents and successor media, in which data or instructions may be stored.

0065Although the present application describes specific embodiments which may be implemented as code segments in computer-readable media, it is to be understood that dedicated hardware implementations, such as application specific integrated circuits, programmable logic arrays and other hardware devices, may be constructed to implement one or more of the embodiments described herein. Applications that may include the various embodiments set forth herein may broadly include a variety of electronic and computer systems. Accordingly, the present application may encompass software, firmware, and hardware implementations, or combinations thereof.

0066The present specification describes components and functions that may be implemented in particular embodiments with reference to particular standards and protocols, the disclosure is not limited to such standards and protocols. Such standards are periodically superseded by faster or more efficient equivalents having essentially the same functions. Accordingly, replacement standards and protocols having the same or similar functions are considered equivalents thereof.

0067The illustrations of the embodiments described herein are intended to provide a general understanding of the various embodiments. The illustrations are not intended to serve as a complete description of all of the elements and features of apparatus and systems that utilize the structures or methods described herein. Many other embodiments may be apparent to those of skill in the art upon reviewing the disclosure. Other embodiments may be utilized and derived from the disclosure, such that structural and logical substitutions and changes may be made without departing from the scope of the disclosure. Additionally, the illustrations are merely representational and may not be drawn to scale. Certain proportions within the illustrations may be exaggerated, while other proportions may be minimized. Accordingly, the disclosure and the figures are to be regarded as illustrative rather than restrictive.

0068One or more embodiments of the disclosure may be referred to herein, individually and/or collectively, by the term “disclosure” merely for convenience and without intending to voluntarily limit the scope of this application to any particular disclosure or inventive concept. Moreover, although specific embodiments have been illustrated and described herein, it should be appreciated that any subsequent arrangement designed to achieve the same or similar purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all subsequent adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the description.

0069For simplicity of exposition, the term ‘database’ was employed in aspects of the above discussion. It will be readily apparent to one of ordinary skill in the art that in the context of the above discussion the scope of that term is not limited just to for example a database management system but rather encompasses inter alia any data source, data model, etc.

0070In addition, in the foregoing Detailed Description, various features may be grouped together or described in a single embodiment for the purpose of streamlining the disclosure. This disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter may be directed to less than all of the features of any of the disclosed embodiments. Thus, the following claims are incorporated into the Detailed Description, with each claim standing on its own as defining separately claimed subject matter.

0071The above disclosed subject matter is to be considered illustrative, and not restrictive, and the appended claims are intended to cover all such modifications, enhancements, and other embodiments which fall within the true spirit and scope of the present disclosure. Thus, to the maximum extent allowed by law, the scope of the present disclosure is to be determined by the broadest permissible interpretation of the following claims and their equivalents, and shall not be restricted or limited by the foregoing detailed description.