Patent Publication Number: US-2003236975-A1

Title: System and method for improved electronic security credentials

Description:
BACKGROUND OF THE INVENTION  
       [0001] 1. Technical Field  
       [0002] The present invention relates in general to a system and method for improved electronic security credentials. More particularly, the present invention relates to a system and method for improving security credentials to allow more interoperability between security mechanisms.  
       [0003] 2. Description of the Related Art  
       [0004] Businesses are increasingly dependent upon computer systems to support business activities. A computer system compromise either in terms of information loss, information inaccuracy, or competitor access to information may be costly to a business. Security breaches compromise computer systems and are becoming more frequent and varied. Security breaches may often be due to accidental misuse of the computer system, such as a user accidentally gaining unauthorized access to information. However, computer systems may also be subject to malicious attacks to gain access to sensitive information.  
       [0005] Distributed computer systems are more vulnerable to security breaches than more traditional computer systems since distributed computer systems include more places where the computer system may be attacked. A security system typically focuses on four main areas to protect computer systems from unauthorized access attempts. These four areas are confidentiality, integrity, accountability, and availability. Confidentiality ensures that information is disclosed only to authorized users. Integrity ensures that only authorized users are able to modify information using authorized ways. Accountability ensures that users are accountable for their security-relevant actions, such as non-repudiation. Availability ensures that users may not be maliciously denied access.  
       [0006] The Object Management Group (OMG) is an organization that establishes industry guidelines and object management specifications to provide a common framework for application development. OMG has developed specifications that particularly focus on network security. One such specification is the Common Security Interoperability version 2 (CSIv2) document which defines various levels of security architectures between computer systems. A developer follows CSIv2 security architecture definitions in order to ensure interoperability with other computer systems.  
       [0007] The CSIv2 document includes a definition for a security protocol called Security Attribute Service (SAS). The Security Attribute Service (SAS) protocol is designed to exchange protocol elements that are communicated over a connection-based transport. The SAS protocol is intended to be used in environments where transport layer security is used to provide message protection (i.e. integrity and/or confidentiality) and server-to-client authentication. The SAS protocol provides client authentication, delegation, and privilege functionality that may be applied to overcome corresponding deficiencies in an underlying transport. For example, the SSL/TLS protocol does not enforce client authentication and, in a given environment, certificate-based client authentication may not be feasible since clients often do not have a certificate. The SAS protocol facilitates interoperability by serving as the higher-level protocol under which secure transports may be unified.  
       [0008] In a computer system, message requests are often passed downstream from one server to another server. Many security verification mechanisms exist that a server may use to authenticate or authorize a user, such as LTPA (Lightweight Third Party Authentication), Kerberos, and LocalOS. A challenge found with passing messages downstream from one server to another server is that each server must have the same security mechanism in order to pass a particular authentication principal to a receiving server. Or, the sending server must send a user id/password combination to the receiving server so the receiving server can perform its own user authentication.  
       [0009] Another challenge found is that the OMG CSIv2 specification does not effectively specify a relationship between the SAS protocol and the Security programming model. Particularly, the CSIv2 specification describes how the Target Security Service (TSS) interprets information within the security context received in the message. However, the CSIv2 specification does not define the way in which this information is converted to credentials nor what is stored in the credentials. Much of how the credentials are formed is mechanism specific.  
       [0010] It is important to support existing OMG security service API&#39;s without the impact of the CSIv2 protocol. The semantics of application programs should be maintained regardless of the chosen security protocol. What is needed, therefore, is way to create credentials objects to represent authentication principles while supporting existing OMG security service API&#39;s.  
       SUMMARY  
       [0011] It has been discovered that adding an identity token attribute to a security context message and adding an identity assertion credential at a server allows a computer system to use different methods of security verification while still supporting existing OMG security service API&#39;s. The identity token includes a requestor&#39;s identity assertion (IA) value and an identity assertion (IA) type. The IA value identifies the requestor, such as a user id, and the IA type corresponds to the identity type included in the IA value. A downstream server stores the IA value and IA type in the same form as it receives them. This is useful in preserving the identity of the original requestor if the downstream server forwards the IA value and IA type to a second downstream server.  
       [0012] A user sends a request to a client. The client retrieves authentication information from the user, creates a basic credential, and stores the user&#39;s authentication information in an identity attribute located in the basic credential. For example, the user&#39;s authentication information may be a user id and a password. The client creates a first security context message which includes the user&#39;s authentication information and sends the first security context to a first downstream server. The first downstream server receives the security context message and proceeds to authenticate the user. The first downstream server may use a security service for authentication purposes if applicable, such as if the user&#39;s authentication information includes a user id and password.  
       [0013] When the user is authenticated, the first downstream server receives an authentication token corresponding to the user from the security service. The first downstream server creates an authentication credential which includes the user&#39;s authentication token and an identity assertion (IA) attribute. The IA attribute, or IA token, includes an IA value which may be a user id, a principal, a distinguished name, or a certificate chain from an SSL mutual authentication connection. The IA token also includes an IA type identifier which identifies the type of identification stored in IA value. The first downstream server stores the IA value and IA type in the same form as they were received. By storing the IA value and IA type in the same form as they were received, the user&#39;s integrity is preserved if the first downstream server forwards the IA token to a second downstream server.  
       [0014] The first downstream server determines that the user&#39;s request should be sent to a second downstream server. The first downstream server creates a second security context message which includes the IA token and an authentication token corresponding to the identity of the first downstream server. The second downstream server receives the second security context message and authenticates the first downstream server using the authentication token included in the second security context message.  
       [0015] Once the first downstream server is authenticated, the second downstream server retrieves the IA value and the IA type identifier from the identity token. The second downstream server creates an IA credential and stores the user&#39;s IA value and the IA type identifier in the IA credential. The second downstream server stores the IA value and IA type in the same form as they were received in order to preserve the user&#39;s integrity. The second downstream server uses information in the IA credential to send a security context message to a third downstream server if required.  
       [0016] The foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below.  
     
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
     [0017] The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings. The use of the same reference symbols in different drawings indicates similar or identical items.  
     [0018]FIG. 1 is a diagram showing a server sending a security context message to a downstream server based upon a client request;  
     [0019]FIG. 2 is a high-level flowchart showing steps taken in an upstream server sending a security context to a downstream server;  
     [0020]FIG. 3 is a flowchart showing steps taken in authenticating a client;  
     [0021]FIG. 4 is a flowchart showing steps taken in generating an authentication credential using client information;  
     [0022]FIG. 5 is a flowchart showing steps taken in building a security context using an authentication credential and a server&#39;s identity;  
     [0023]FIG. 6 is a flowchart showing steps taken in a downstream server processing a security context message which is sent from an upstream server;  
     [0024]FIG. 7 is a flowchart showing steps taken in creating an identity assertion (IA) credential; and  
     [0025]FIG. 8 is a block diagram of an information handling system capable of implementing the present invention.  
    
    
     DETAILED DESCRIPTION  
     [0026] The following is intended to provide a detailed description of an example of the invention and should not be taken to be limiting of the invention itself. Rather, any number of variations may fall within the scope of the invention which is defined in the claims following the description.  
     [0027]FIG. 1 is a diagram showing a server sending a security context message to a downstream server based upon a client request. User  100  sends a request to client  105 . Client  105  retrieves identification information from user  100  and authenticates user  100 . For example, user  100 &#39;s identification information may be a user id and a password. When user  100  is authenticated, client  105  creates basic credential  110  and stores user  100 &#39;s information in identity  115  which is located in basic credential  110 . Using the example described above, user  100 &#39;s user id and password are stored in identity  115 .  
     [0028] Client  105  determines that user  100 &#39;s request should be sent to server A  130 . Client  105  creates first security context  120 , retrieves user information from identity  115 , and stores the user information in authentication token  125  which is located in first security context  120 . Using the example described above, client  105  includes user  100 &#39;s user id and password in authentication token  125 . In one embodiment, authentication token  125  may include different mechanism-specific security information used by an authentication mechanism in common between a client and a server, such as a principal or distinguished name. Client  105  sends first security context  120  to server A  130  using a transport mechanism, such as SSL.  
     [0029] Server A  130  receives security context  120  and proceeds to authenticate user  100  using information in authentication token  125 . Server A  130  retrieves identity information from authentication token  125 . In one embodiment, server A  130  may retrieve user  100 &#39;s identity information by extracting a certificate chain from the transport mechanism, such as SSL. If server A determines that user  100 &#39;s identity information should be sent to security service  160  for authentication, server A  130  stores the identity information in authentication request  155  and sends authentication request  155  to security service  160 . Security service  160  may be a server which is responsible for authenticating users. Security service  160  authenticates user  100  and sends token  165  to server A  130 . Token  165  is an authentication token corresponding to user  100 &#39;s identity in a format known by a specific mechanism, such as Kerberos, LTPA, or LocalOS.  
     [0030] Server A  130  acknowledges authentication, and creates authentication credential  135 . Server A  130  retrieves information from token  165  and stores the information in token  140 . Server A  130  also retrieves identity assertion information from authentication token  125  or the transport mechanism and stores it in IA value  145  to be used in downstream requests. For example, server A  130  stores a principal, a distinguished name, or a certificate chain in IA value  145 . Server A stores user  100 &#39;s identity information in the same form as it was received. Server A  130  classifies which type of identity assertion is stored in IA value  140 , and stores an identity assertion type identifier in IA type  150  (see FIG. 4 and corresponding text for further details regarding identity assertion types).  
     [0031] Server A  130  determines that user  100 &#39;s request should be sent downstream to server B  185 . Server A  130  creates second security context  170  and stores server A  130 &#39;s identity information in authentication token  175 . Server A  130  retrieves user  100 &#39;s original identity information from IA value  145  and IA type  150  and stores both identity elements in identity token  180 . Server A  130  then sends second security context  170  to server B  185  for processing.  
     [0032] Server B  185  receives second security context  170 . Server B  185  authenticates server A  130  by analyzing information in authentication token  175  (see FIG. 6 and corresponding text further details for information regarding server authentication). Once server A  130  is authenticated, server B  185  retrieves the identity assertion value and the identity assertion type identifier from identity token  180 . Server B  185  creates IA credential  190  representing user  100 . Server B  185  stores user  100 &#39;s identity assertion value in IA value  195  and the IA type identifier in IA type  199 .  
     [0033] If server B  185  recognizes that user  100 &#39;s request should be sent to a downstream server, server B  185  uses information in IA value  195  and IA type  199  to create a security context to send to the downstream server. Or, if server B  185  determines that user  100  should be authorized, server B  185  uses IA value  195  and IA type  199  to perform authorization steps corresponding to user  100 . The continued propagation of the original identity information preserves the integrity of the user&#39;s identity on a server-by-server basis. Each server may map this information to a credential in a way that it chooses based upon the server&#39;s underlying authentication mechanism and mapping rules.  
     [0034]FIG. 2 is a high-level flowchart showing steps taken in an upstream server sending a security context to a downstream server. Server A processing commences at  200 , whereupon server A receives a request from client  210  and stores the request in server A temp store  215  (step  205 ). The request may be a security context message which includes a user id/password combination, a digital certificate, or some other means of identification. Server A temp store  215  may be stored in a non-volatile storage area, such as a computer hard drive, or a volatile storage area, such as random access memory (RAM). Server A performs authentication steps to authenticate client  210  (pre-defined process block  220 , see FIG. 3 and corresponding text for further details).  
     [0035] A determination is made as to whether client  210  was authenticated (decision  225 ). If client  210  was not authenticated, decision  225  branches to “No” branch  227  whereupon a return error is sent to client  210  (step  230 ) and processing ends at  235 . On the other hand, if client  210  is authenticated, decision  225  branches to “Yes” branch  229 . Processing generates an authentication credential corresponding to client  210  and stores the authentication credential in authentication store  245  (pre-defined process block  240 , see FIG. 4 and corresponding text for further details). The authentication credential includes information such as an authentication token, an identity assertion value corresponding to client  210 , and an identity assertion type identifier corresponding to the identity assertion value. Authentication credential store  245  may be stored in a non-volatile storage area, such as a computer hard drive, or a volatile storage area, such as random access memory (RAM).  
     [0036] Processing generates a security context message using information in authentication credential store and stores the security context in security context store  255  (pre-defined process block  250 , see FIG. 5 and corresponding text for further details). The security context includes information such as server A&#39;s identity information and an identity token which includes an IA value corresponding to client  210  and an IA type identifier corresponding to the IA value. The security context is typically stored in memory when a downstream request is about to be sent to a downstream server. Security context store  255  may be stored in a non-volatile storage area, such as a computer hard drive, or in a volatile storage area, such as random access memory (RAM).  
     [0037] Processing retrieves the security context from security context store  255  and sends security context  265  to downstream server B (step  260 ). Server B processing commences at  270 , whereupon server B receives security context  265  and stores it in server B temp store  278  (step  275 ). Server B processes security context  265  to trust server A and generate an IA credential (pre-defined process block  280 , see FIG. 6 and corresponding text for further details). Trusting server A entails checking that server A&#39;s identity is in a trusted list and authenticating or validating server A&#39;s authentication token. This is typically faster than authenticating the client&#39;s identity since the server&#39;s identity may be in a cache memory area.  
     [0038] Server B sends response  290  to server A. Response  290  may be an error message if server B is not able to trust server A, or response  290  may be an authentication approval message. Server A receives response  290  at step  295 . Server A processing ends at  299 .  
     [0039] If server B trusts server A, server B generates an IA credential and stores the IA credential in IA credential store  282  (see FIG. 7 and corresponding text for further details regarding IA credential generation). IA credential store  282  may be stored in a non-volatile storage area, such as a computer hard drive, or may be stored in a volatile storage area, such as random access memory (RAM). Server B processing ends at  285 .  
     [0040]FIG. 3 is a flowchart showing steps taken in authenticating a client. Client authentication processing commences at  300 , whereupon processing retrieves authentication information corresponding to a client from server A temp store  315 . Server A temp store  315  may be stored on a non-volatile storage area, such as a computer hard drive. For example, authentication information may include a user id and a password. A determination is made as to whether the authentication information is a context id indicating that the corresponding client has been previously authenticated (decision  320 ). If the authentication information includes a context id, decision  320  branches to “Yes” branch  322  whereupon processing compares the context id with a context id look-up table located in context id look-up store  335 . Context id look-up store  335  may be stored in a non-volatile storage area, such as a computer hard drive.  
     [0041] A determination is made as to whether processing matched the client&#39;s context id with a context id in the context id table (decision  340 ). If processing did not match the client&#39;s context id, decision  340  branches to “No” branch  342  whereupon processing returns an error message at  345 . On the other hand, if processing matched the client&#39;s context id, decision  340  branches to “Yes” branch  348  whereupon processing returns an authentication message at  350 .  
     [0042] If the client&#39;s authentication information is not a context id, decision  320  branches to “No” branch  328  whereupon the authentication information is sent to security service  370  (step  360 ). Using the example described above, the user id and password are sent to security service  370 . Security service  370  may be a server that is responsible for authenticating clients.  
     [0043] Processing receives a response from security service  370  at step  380 . If security service authenticated the client, the response may be an authentication token. If the security service did not authenticate the client, the response may be a “Not Authenticated” message. A determination is made as to whether the client is authenticated (decision  390 ). If the client is not authenticated, decision  390  branches to “No” branch  392  whereupon an error message is returned at  395 . On the other hand, if the client is authenticated, decision  390  branches to “Yes” branch  398  whereupon an authentication message is returned at  399 .  
     [0044]FIG. 4 is a flowchart showing steps taken in generating an authentication credential using client information. Authentication credential generation processing commences at  400 , whereupon a new authentication credential is initialized in authentication credential store  415  (step  410 ). Authentication credential store  410  may be stored in a non-volatile storage area, such as a computer hard drive, or in a volatile storage area, such as random access memory (RAM).  
     [0045] An authentication token is received from security service  430  at step  420 . In one embodiment, the authentication token may be retrieved from a non-volatile storage area such as a computer hard drive. For example, if a client sent a context id as authentication, processing may look-up the context id and retrieve a corresponding authentication token from a non-volatile storage area.  
     [0046] Processing stores the authentication token in the new credential located in authentication credential store  415 . Processing retrieves a client&#39;s identity from a client&#39;s request located in server A temp store  455 . For example, the client&#39;s request may include a user id and password whereupon processing retrieves the user id. The client&#39;s identity is stored in an identity assertion (IA) value located in the new credential which is stored in authentication credential store  415  (step  460 ).  
     [0047] Processing analyzes the IA value and assigns an identity assertion (IA) type identifier corresponding to the IA value (step  470 ). For example, the IA type identifier may be based upon identity token formats included in a Common Object Request Broker Architecture (COBRA) specification in which the Object Management Group (OMG) supports. The identity assertion type identifier is stored in an IA type located in the new credential which is stored in authentication credential store  415  (step  480 ). Processing returns at  490 .  
     [0048]FIG. 5 is a flowchart showing steps taken in building a security context using an authentication credential and a server&#39;s identity. A security context is an in-memory object for each request from a client to a server or from a first server to a second server. Security context building processing commences at  500 , whereupon a new security context is initialized in security context store  520 . Security context store  520  may be stored in a non-volatile storage area, such as a computer hard drive. The server&#39;s identity is retrieved from server configuration  540  (step  530 ). Server configuration  540  may be located on the server and the server&#39;s identity may be an authentication token in which a downstream server recognizes. The server&#39;s identity is stored in an authentication token located in the new security context which is stored in security context store  520  (step  550 ).  
     [0049] A client&#39;s identity is retrieved from an identity assertion (IA) value located in a corresponding authentication credential which is stored in authentication credential store  570 . For example, the client&#39;s identity may be a principal, distinguished name, or certificate chain. Authentication credential store  570  may be stored in a non-volatile storage area, such as a computer hard drive. An identity assertion (IA) type identifier corresponding to the IA value is retrieved from an IA Type located in the corresponding authentication credential which is stored in authentication credential store  570 . The IA type identifier corresponds to the type of identity assertion of the IA value (see FIG. 4 and corresponding text for further details regarding IA values and IA types).  
     [0050] The IA value and IA type are combined to generate an IA token which is stored in the new security context located in security context store  520 . Processing returns at  595 .  
     [0051]FIG. 6 is a flowchart showing steps taken in a downstream server processing a security context message which is sent from an upstream server. Server B security context processing commences at  600 , whereupon an authentication token is retrieved from a security context message located in server B temp store  610 . The security context message was previously sent from an upstream server A and the authentication token includes server A&#39;s identity. Server B temp store  610  may be stored on a non-volatile storage area, such as a computer hard drive. Processing compares server A&#39;s identity with a trusted list located in trusted list store  620 . The trusted list includes a list of servers which are trusted by the corresponding server (i.e. server B). Trusted list store  620  may be stored in a non-volatile storage area, such as a computer hard drive.  
     [0052] A determination is made as to whether processing matched server A&#39;s identity with an entry in the trusted list (decision  625 ). If processing did not match server A&#39;s identity with an entry in the trusted list, decision  625  branches to “No” branch  627  whereupon an error message is returned at  630 . On the other hand, if processing did match server A&#39;s identity with an entry in the trusted list, decision  625  branches to “Yes” branch  629 .  
     [0053] Processing sends server A&#39;s authentication information to security service  645  for a simple authentication. Security service  645  performs a simple authentication by checking the user id and password for validity. Security service  645  may not return a token or credential during a simple authentication. Processing receives a response form security service  645  at step  650 . A determination is made as to whether server A was authenticated (decision  660 ). If server A was not authenticated, decision  660  branches to “No” branch  662  whereupon an error message is returned at  670 . On the other hand, if server A was authenticated, decision  660  branches to “Yes” branch  664  whereupon processing creates an identity assertion (IA) credential (pre-defined process block  680 , see FIG. 7 and corresponding text for further details). Processing returns an authorization message at  690 .  
     [0054]FIG. 7 is a flowchart showing steps taken in creating an identity assertion (IA) credential. IA credential generation processing commences at  700 , whereupon a new IA credential is initialized in IA credential store  720  (step  710 ). IA credential store  720  may be stored in a non-volatile storage area, such as a computer hard drive.  
     [0055] Processing retrieves a client&#39;s identity from an identity token located in server B temp store  740  (step  730 ). For example, the client&#39;s identity may include a user id. Server B temp store  740  may be stored in non-volatile storage area, such as a computer hard drive. The client&#39;s identity is stored in an identity assertion (IA) value located in the new credential which is stored in IA credential store  720  (step  750 ).  
     [0056] Processing retrieves an IA type identifier from the identity token at step  760 . The IA type identifier corresponds to the format of the client&#39;s identity. For example, the IA type identifier may be based upon identity token formats included in a Common Object Request Broker Architecture (COBRA) specification in which the Object Management Group (OMG) supports. The identity assertion type identifier is stored in an IA type located in the new credential which is stored in IA credential store  720  (step  770 ). Processing returns at  780 .  
     [0057]FIG. 8 illustrates information handling system  801  which is a simplified example of a computer system capable of performing the server and client operations described herein. Computer system  801  includes processor  800  which is coupled to host bus  805 . A level two (L2) cache memory  810  is also coupled to the host bus  805 . Host-to-PCI bridge  815  is coupled to main memory  820 , includes cache memory and main memory control functions, and provides bus control to handle transfers among PCI bus  825 , processor  800 , L2 cache  810 , main memory  820 , and host bus  805 . PCI bus  825  provides an interface for a variety of devices including, for example, LAN card  830 . PCI-to-ISA bridge  835  provides bus control to handle transfers between PCI bus  825  and ISA bus  840 , universal serial bus (USB) functionality  845 , IDE device functionality  850 , power management functionality  855 , and can include other functional elements not shown, such as a real-time clock (RTC), DMA control, interrupt support, and system management bus support. Peripheral devices and input/output (I/O) devices can be attached to various interfaces  860  (e.g., parallel interface  862 , serial interface  864 , infrared (IR) interface  866 , keyboard interface  868 , mouse interface  870 , and fixed disk (HDD)  872 ) coupled to ISA bus  840 . Alternatively, many I/O devices can be accommodated by a super I/O controller (not shown) attached to ISA bus  840 .  
     [0058] BIOS  880  is coupled to ISA bus  840 , and incorporates the necessary processor executable code for a variety of low-level system functions and system boot functions. BIOS  880  can be stored in any computer readable medium, including magnetic storage media, optical storage media, flash memory, random access memory, read only memory, and communications media conveying signals encoding the instructions (e.g., signals from a network). In order to attach computer system  801  to another computer system to copy files over a network, LAN card  830  is coupled to PCI bus  825  and to PCI-to-ISA bridge  835 . Similarly, to connect computer system  801  to an ISP to connect to the Internet using a telephone line connection, modem  875  is connected to serial port  864  and PCI-to-ISA Bridge  835 .  
     [0059] While the computer system described in FIG. 8 is capable of executing the invention described herein, this computer system is simply one example of a computer system. Those skilled in the art will appreciate that many other computer system designs are capable of performing the invention described herein.  
     [0060] One of the preferred implementations of the invention is an application, namely, a set of instructions (program code) in a code module which may, for example, be resident in the random access memory of the computer. Until required by the computer, the set of instructions may be stored in another computer memory, for example, on a hard disk drive, or in removable storage such as an optical disk (for eventual use in a CD ROM) or floppy disk (for eventual use in a floppy disk drive), or downloaded via the Internet or other computer network. Thus, the present invention may be implemented as a computer program product for use in a computer. In addition, although the various methods described are conveniently implemented in a general purpose computer selectively activated or reconfigured by software, one of ordinary skill in the art would also recognize that such methods may be carried out in hardware, in firmware, or in more specialized apparatus constructed to perform the required method steps.  
     [0061] While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that, based upon the teachings herein, changes and modifications may be made without departing from this invention and its broader aspects and, therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of this invention. Furthermore, it is to be understood that the invention is solely defined by the appended claims. It will be understood by those with skill in the art that if a specific number of an introduced claim element is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such limitation is present. For a non-limiting example, as an aid to understanding, the following appended claims contain usage of the introductory phrases “at least one” and “one or more” to introduce claim elements. However, the use of such phrases should not be construed to imply that the introduction of a claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an”; the same holds true for the use in the claims of definite articles.