WO2010054351A2

WO2010054351A2 - Methods and apparatus related to transmission of confidential information to a relying entity

Info

Publication number: WO2010054351A2
Application number: PCT/US2009/063801
Authority: WO
Inventors: Jeff Stollman
Original assignee: Jeff Stollman
Priority date: 2008-11-10
Filing date: 2009-11-10
Publication date: 2010-05-14
Also published as: WO2010054351A8; WO2010054351A3

Abstract

In one embodiment, a method includes defining a request for confidential information from a domain of confidential information based on an input from a relying entity. The domain of confidential information can be associated with a subject entity. A response to the request can be defined at an information provider. The method can also include sending the response to the relying entity when the response has been approved by the subject entity.

Description

METHODS AND APPARATUS RELATED TO TRANSMISSION OF CONFIDENTIAL INFORMATION TO A RELYING ENTITY

Related Applications

[1001] This application is a continuation of and claims priority to and the benefit of U. S . Patent Application No. 12/268,065, filed on November 10, 2008, entitled "Methods and Apparatus Related to Transmission of Confidential Information to a Relying Entity," and is also a continuation of and claims priority to and the benefit of U.S. Patent Application No. 12/268,069, filed on November 10, 2008, entitled "Methods and Apparatus for Transacting with Multiple Domains based on a Credential," both of which are incorporated herein by reference in their entireties.

Background

[1002] Embodiments relate generally to management of confidential information, and, in particular, to methods and apparatus related to transmission of confidential associated with a subject entity to a relying entity.

[1003] In societies with electronic-enabled economies, relatively large numbers of transactions take place among parties who have limited knowledge about one another. When parties engage in a transaction, a party (also referred to as a relying party) may hope to acquire specified information (e.g., confidential information, personally identifiable information) about another party (also referred to as a subject party) to facilitate and/or enable the transaction. A relying party may wish to acquire information such as:

(1) Will the bank or credit card account of the subject party cover the purchase of goods and/or services by the subject party?

(2) Is the subject party a reasonable credit risk for a proposed mortgage or new line of credit?

(3) Is there anything in the medical history of the subject entity that may change a diagnosis?

Answers to these types of questions can be obtained by the relying party through, for example, electronic records of previous transactions and/or through a third-party information provider such as a credit bureau. In some cases, answers to these questions can be obtained with relative ease by a party with payment of a fee. Often, the information collected by, for example, information providers can be collected without the assent of the subject party and/or can include errors which can have a detrimental impact on the subject party and/or the relying party. Additionally, breaches of information repositories maintained by relying parties and/or information providers can result in information being undesirably exposed. [1004] Among the unintended consequences of the widespread availability of information, such as personally identifiable information, either through purchase, accidental exposure, and/or theft has led to, for example, the undesirable exploitation of such information for criminal purposes (e.g., identity theft). This type of exploitation can be a financial and/or an emotional burden on the subject of the exposed information. Although certain organizations, such as government agencies, are beginning to enact rules and/or regulations to protect information and/or promote the availability of information so that information can be readily transferred between parties, these efforts have many short-comings. Thus, a need exists for methods and apparatus related to transmission of confidential information associated with a subject party to a relying party.

Summary

[1005] In one embodiment, a method includes defining a request for confidential information from a domain of confidential information based on an input from a relying entity. The domain of confidential information can be associated with a subject entity. A response to the request can be defined at an information provider. The method can also include sending the response to the relying entity when the response has been approved by the subject entity.

Brief Description of the Drawings

[1006] FIG. 1 is a schematic block diagram that illustrates an information provider configured to send at least a portion of confidential information associated with a subject entity to a relying entity, according to an embodiment.

[1007] FIG. 2 is a schematic block diagram that illustrates signaling related to transfer of at least a portion of confidential information associated with a subject entity to a relying entity, according to an embodiment.

[1008] FIG. 3 is a schematic block diagram that illustrates predefined queries within a request template, according to an embodiment.

[1009] FIG. 4 is a schematic diagram that illustrates a domain of confidential information defined based on a trust-level value and a relying-entity-type value, according to an embodiment.

[1010] FIG. 5 is a diagram that illustrates a database that can be used to determine a domain of confidential information, according to an embodiment. [1011] FIG. 6 is a schematic block diagram that illustrates portions of confidential information that are associated with hierarchically related confidential information categories, according to an embodiment.

[1012] FIG. 7 is a flowchart that illustrates a method for defining a domain of confidential information, according to an embodiment.

[1013] FIG. 8 is a flowchart that illustrates a method for receiving a response to a request for confidential information from a subject entity, according to an embodiment.

[1014] FIG. 9 is a flowchart that illustrates a method for negotiating a response related to a confidential information request, according to an embodiment.

[1015] FIG. 10 is a schematic diagram that illustrates sources associated with an information provider, according to an embodiment.

[1016] FIG. 11 is a schematic block diagram that illustrates a terminal device configured to receive credential data from a credential, according to an embodiment.

[1017] FIG. 12 is a schematic block diagram that illustrates multiple terminal devices associated with multiple domains, according to an embodiment.

[1018] FIG. 13 is a schematic block diagram that illustrates multiple terminal devices associated with multiple domains, according to an embodiment.

[1019] FIG. 14 is a diagram that illustrates a privilege data database, according to an embodiment.

[1020] FIG. 15 is a schematic block diagram that illustrates a terminal device, according to an embodiment.

[1021] FIG. 16 is a schematic block diagram that illustrates multiple gateway devices associated with multiple domains, according to an embodiment.

[1022] FIG. 17 is a flow chart that illustrates a method for authenticating an individual and a credential, according to an embodiment.

[1023] FIG. 18 is a schematic block diagram that illustrates a relying entity and a terminal device that are configured to communicate with an information provider, according to an embodiment.

[1024] FIG. 19 is a schematic block diagram that illustrates an information provider in communication with multiple information sources, according to an embodiment. Detailed Description

[1025] An information management module can be configured to manage processing (e.g., handling, transmission, updating) of confidential information associated with one or more entities (e.g., individuals, businesses, organizations, an agent (e.g., a human agent, an electronic agent) of an individual/business/organization). Specifically, the information management module can be configured to manage transfer of confidential information associated with a subject entity to a relying entity. In some embodiments, the subject entity can be referred to as subject entity because the confidential information can be related to (e.g., owned by, about, created by) the subject entity. In some embodiments, the subject entity can be referred to as a subject party. The relying entity can be any entity that is attempting to obtain confidential information associated with the subject entity. In some embodiments, the relying entity can be referred to as a relying party.

[1026] The confidential information can be requested by the relying entity via the information management module. A request for the confidential information and/or a response (e.g., a proposed response) to the confidential information can be reviewed by the subject entity before the response is sent to the relying entity. Moreover, the subject entity can have the opportunity to assess the accuracy/appropriateness of the request and/or the confidential information included in the response to the request. In some embodiments, the request can be defined based on one or more predefined queries and the request can be a request for confidential information from a domain of confidential information.

[1027] In some embodiments, the information management module can be configured so that the subject entity can modify, approve, and/or disapprove one or more portions of a request and/or a response to the request for confidential information via the information management module. In some embodiments, the subject entity and/or the relying entity can negotiate transfer of confidential information via the information management module. In some embodiments, a request for confidential information can be defined (e.g., automatically defined) based on a request policy defined by the subject entity and/or defined by the relying entity. The request policy defined by the subject entity can be configured to trigger updates (e.g., automatic updates) of confidential information associated with the subject entity. The request policy defined by the relying entity can be used by, for example, an information management module to define (e.g., automatically define) a request for confidential information. In some embodiments, a response to the confidential information can be defined based on a response policy defined by the subject entity and/or the relying entity. In some embodiments, the response policy can be defined so that a desirable level of confidential information (e.g., a minimal level, a specified level) is shared with a relying entity. In some embodiments, transactions related to the information management module, the relying entity, and/or the subject entity can be tracked (e.g., collected, stored) by the information management module. [1028] In some embodiments, the confidential information associated with an entity (e.g., a subject entity) can include, for example, personal identifiable information (e.g., a social security number, a birth date, a marriage date, residential information), medical information (e.g., a health history, diagnostic information), financial information (e.g., credit information, bank account information), account information (e.g., e-mail account information, membership information), behavioral information (e.g., habit information), characteristics related to an individual (e.g., biometric information), transactional information (e.g., transaction dates), location information (e.g., current location information), employee information (e.g., salary information, employment history), criminal information (e.g., a criminal history), license information (e.g., information related to a vehicle/hunting/medical license or building permit), security clearance information (e.g., information about a level of security clearance), citizenship information (e.g., an immigration status), and so forth. In some embodiments, the confidential information can be textual information (e.g., a document), graphical information (e.g., a chart/table), audible information (e.g., a sound byte), visual information (e.g., an image, a video), and so forth. In some embodiments, the confidential information can include secret information and/or publicly available information.

[1029] It is noted that, as used in this written description and the appended claims, the singular forms "a," "an" and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, the term "a request" is intended to mean a single request or multiple requests.

[1030] FIG. 1 is a schematic block diagram that illustrates an information provider 130 configured to send at least a portion of confidential information 136 associated with a subject entity 120 to a relying entity 100, according to an embodiment. As shown in FIG. 1, the information provider 130 includes an information management module 132 configured to manage processing of the confidential information 136.

[1031] The information management module 132 can be configured to send (or trigger sending of) a portion of confidential information 136 in response to a request defined by the relying entity 100. In some embodiments, one or more portions of a request for at least a portion of the confidential information 136 can be processed by (e.g., approved by, modified by, disapproved by) the subject entity 120 and/or the relying entity 100 via the information management module. In some embodiments, the request for at least a portion of the confidential information 136 can be referred to as a confidential information request or as an information request.

[1032] In some embodiments, the portion of the confidential information 136 can be sent in response to request being processed by (e.g., approved by, modified by, disapproved by) the subject entity 120 via the information management module. For example, the information management module 132 can be configured to send the portion of confidential information 136 in response to at least a portion of the confidential information request and/or responses (e.g., proposed responses) to the confidential information request being approved by the subject entity 120. In some embodiments, the information management module 132 can also be configured to only send the portion of the confidential information 136 when the sending of the portion of the confidential information 136 is approved by the subject entity 120.

[1033] For example, a request for a first portion of the confidential information 136 and a second portion of the confidential information 136 can be sent from the relying entity 100 to the subject entity 120. The information management module 132 can be configured to send the first portion of the confidential information 136 when the subject entity 120 only authorizes a response to a portion of the request related to the first portion of the confidential information 136 (or prohibits a response to a portion of the request related to the second portion of the confidential information 136).

[1034] In some embodiments, the information management module 132 can be configured to send the first portion of the confidential information 136 in a form that is authorized by the subject entity 120. In some embodiments, the information management module 132 can be configured to send the first portion of the confidential information 136, for example, in a format, via a protocol, with specified language, and so forth, that is authorized by the subject entity 120. [1035] In some embodiments, the confidential information request can be defined based on one or more predefined queries that can be selected by the relying entity 200. The predefined queries can be provided to the relying entity 200 based on one or more preferences (included in a request policy) defined by the subject entity 220. A predefined query can be a predefined question related to confidential information about the subject entity 220. More details related to predefined queries are described in connection with FIG. 3.

[1036] The relying entity 100 can be any entity that can define a request for at least a portion of the confidential information 136 and/or trigger the information management module 132 to define such a request. For example, the relying entity 100 can be, or can be associated with, a computing device such as a mobile device, a personal digital assistant (PDA), a server, a personal computer, and so forth. In some embodiments, for example, the relying entity 100 can be, or can be associated with, an organization (e.g., a corporation), an individual, a group of individuals, and so forth.

[1037] The subject entity 120 can be any entity that can be configured to process (e.g., respond to, approve, modify, disapprove) a request for at least a portion of the confidential information 136. For example, the subject entity 120 can be or can be associated with a computing device such as a mobile device, a PDA, a server, a personal computer, and so forth. In some embodiments, for example, the subject entity 120 can be or can be associated with an organization (e.g., a corporation), an individual, a group of individuals, and so forth. [1038] As shown in FIG. 1, the confidential information 136 can be stored in a memory 134 that can be accessed by the information provider 130. In some embodiments, the confidential information 136 can be stored in any storage medium that can be accessed by the information provider 130. For example, although not shown, the confidential information 136 can be stored in a database, a remote database, a local database, a distributed database, and so forth. The memory 134 can be a location (e.g., a repository) where any of the information described herein (e.g., trust-level information) can be stored and/or processed.

[1039] Although not shown, the confidential information 136 can be associated with one or more subject entities in addition to subject entity 120. In some embodiments, the confidential information 136 can define, can include, and/or can be from a domain of confidential information that can be defined by the relying entity 100, the information management module 132, and/or the subject entity 120. In some embodiments, the domain of confidential information 136 can be defined based on one or more preferences (e.g., preferences included in a request policy and/or a response policy) of the relying entity 100 and/or the subject entity 120. [1040] In some embodiments, a domain of confidential information can be a subset of a group of confidential information associated with a subject entity. In some embodiments, a domain of confidential information can be a subset of confidential information that a relying entity may be permitted to access or request. In some embodiments, a relying entity may be permitted to request only confidential information from a specified domain of confidential information. In some embodiments, a domain of confidential information can include all confidential information associated with a subject entity or set of subject entities. More details related to defining a domain of confidential information are described in connection with FIGS. 4-8.

[1041] In some embodiments, an identity of the subject entity 120 and/or an identity of the relying entity 100 can be authenticated at the information management module 132 of the information provider 130. The identity of the subject entity 120 and/or the identity of the relying entity 100 can be authenticated based on one or more digital certificates, username/password combinations, possession of a credential(s) (e.g., token(s)), characteristic information (e.g., biometric information), and/or so forth. More details related to authentication based on a credential are described in connection with FIGS. 12-19 below. [1042] In some embodiments, the identity of the relying entity 100 can be authenticated at the information management module 132 before a request is received at the information management module 132 from the relying entity 100. In some embodiments, the relying entity 100 can be prevented from making a request for a portion of the confidential information 136 unless the identity of the relying entity 100 has been authenticated. In some embodiments, the relying entity 100 can be prevented from making a request for a portion of the confidential information 136 unless the identity of the relying entity 100 has been authenticated based on a specified level of authentication (e.g., authentication using a username/password combination as well as biometric verification). In some embodiments, this can be referred to as satisfying an authentication level.

[1043] In some embodiments, the identity of the subject entity 120 can be authenticated at the information management module 132 before the subject entity 120 can have access to a request for a portion of the confidential information 136. In some embodiments, the identity of the subject entity 120 can be authenticated at the information management module 132 before the subject entity 120 can be allowed to approve, disapprove, and/or modify a request (or proposed response to the request) for a portion of the confidential information 136. In some embodiments, the subject entity 120 can be prevented from, for example, reviewing a request unless the identity of the subject entity 120 has been authenticated based on a specified level of authentication (e.g., authentication using a username/password combination as well as biometric verification). In some embodiments, this can be referred to as satisfying an authentication level. [1044] In some embodiments, a request for at least a portion of the confidential information 136 can be defined based on a request policy. Although not shown, the request policy can be stored at the memory 134. The request policy can be configured to trigger the information management module 132 to request and/or send at least a portion of the confidential information 136 to the relying entity 100. In some embodiments, the request policy can be configured to trigger one or more portions of the confidential information 136 to be sent (e.g., sent by the information management module 132) to the relying entity 100 at specified times, at regular times, and/or at random times. In some embodiments, the request policy can be configured to trigger the information management module 132 to send one or more portions of the confidential information 136 in response to the confidential information 136 (e.g., the portion of the confidential information 136) being changed (e.g., updated, modified). [1045] In some embodiments, one or more portions of the confidential information 136 queued for sending to the relying entity 100 based on a request policy cannot be sent to the relying entity 100 until approved by the subject entity 120. In some embodiments, only portions of the confidential information 136 approved (e.g., authorized) for sending by the subject entity 120 will be sent to the relying entity 100 (or not approved for sending by the subject entity 120 will not be sent to the relying entity 100).

[1046] In some embodiments, one or more portions of a request policy can be invoked by the information management module 132 and/or the relying entity 100. For example, the relying entity 100 can be configured to trigger the information management module 132 to send at least a portion of the confidential information 136 based on one or more portions of a request policy stored at, for example, the memory 134. In some embodiments, one or more portions of a request policy can be manually invoked by the information management module 132 and/or the relying entity 100.

[1047] In some embodiments, one or more portions of a request from a relying entity 100 can be automatically approved, disapproved, and/or modified based on response policy. The response policy can be defined by the subject entity 120 (also can be referred to as a subject entity response policy) and can be stored at, for example, the memory 134. The response policy can be configured so that specific types of requests for the confidential information 136 are handled in a particular fashion. For example, a response policy can be defined so that a specified type of request for confidential information 136 (e.g., a request for birth date information) is automatically rejected based on the response policy. In some embodiments, a response policy can be defined so that a response to a specified type of request for confidential information 136 is always (or under specified conditions) authorized based on the response policy. In some embodiments, a response policy can be defined so that one or more portions of a request is modified based on the response policy when specified conditions within the response policy are satisfied.

[1048] In some embodiments, the response policy can be defined so that one or more portions of the confidential information 136 are not shared (or are shared) with a particular party based on a privacy level associated with the portion(s) of confidential information 136. For example, transmission to the relying entity 100 of a particular portion of the confidential information 136 that has a specified privacy level may not permitted based on a response policy defined by the subject entity 120. In some embodiments, the transmission may (or may not) be permitted based on, for example, a trust-level value (e.g., an assurance level value, a security clearance level) and/or an identity of the relying entity 100.

[1049] In some embodiments, a response policy can be defined by the relying entity 100 (also can be referred to as a relying entity response policy). The response policy can be configured to trigger the information management module 132 to define a response to a request from the relying entity 100 in a particular fashion when specified conditions are met. For example, the information management module 132 can be configured to send a response to a request in a particular form (e.g., via e-mail) based on a response policy defined by the relying entity 100 and/or based on a particular type of request (e.g., a request for a specified type of confidential information).

[1050] In some embodiments, a response policy can be defined based on an identity of the relying entity 100. Moreover, a response policy can be applied to more than one relying entity. For example, a response policy can be configured to authorize, modify, and/or deny one or more portions of a specified set (or type) of confidential information requests from a specified relying entity such as relying entity 100.

[1051] In some embodiments, transactions related to the information management module 132, the relying entity 100, and/or the subject entity 120 can be tracked (e.g., collected, stored) by the information management module 132. For example, request made by the relying entity 100, approvals by the subject entity 120, confidential information sent by the information management module, etc. can be tracked. In some embodiments, the tracked transactions can be stored at, for example, the memory 134. In some embodiments, the tracked transactions can collectively (or individually) define an audit trail that can be accessed and/or analyzed. In some embodiments, the tracked data can be automatically transferred (e.g., transferred at specified times, transferred in a specified format) to the relying entity 100, the subject entity 120, and/or the information provider 130 based on one or more tracking policies defined by the relying entity 100, the subject entity 120, and/or the information provider 130.

[1052] In some embodiments, the tracked data can be accessed by the relying entity 100 so that the relying entity 100 can verify (e.g., prove) that one or more portions of the confidential information 136 received by the relying entity 100 was transferred from a reliable source and with proper approval from the subject entity 120. For example, a digital signature stamp associated with approval by the subject entity 120 of transfer of confidential information 136 can be stored in a memory (not shown) that can be accessed by the relying entity 100. [1053] In some embodiments, tracked data can be accessed by the information provider 130 so that the information provider 130 can verify (e.g., prove) the information provider 130 properly released the confidential information 136 to the relying entity 100. For example, when the information provider 130 transfers at least a portion of the confidential information 136 to the relying entity 100, one or more portions of tracked data (e.g., tracked data values) representing the type, quantity, and/or date/time of the transfer of the portion of the confidential information 136 can be stored in a memory (not shown). The tracked data can be retrieved by the information provider 130 to verify the proper release of the portion of the confidential information 136 to the relying entity 100 in accordance with, for example, a preference established by, for example, the subject entity 120 and/or the relying entity 100. [1054] In some embodiments, tracked data can be accessed by the subject entity 120 so that the subject entity 120 can verify (e.g., prove) that one or more portions of the confidential information 136 were properly released by, for example, the information provider 130 to the relying entity 100. For example, when the information provider 130 transfers at least a portion of the confidential information 136 to the relying entity 100, one or more portions of tracked data (e.g., tracked data values) representing the transaction related to the transfer of the portion of the confidential information 136 can be stored in a memory (not shown). The tracked data can be retrieved by the subject entity 120 to verify the proper release of the portion of the confidential information 136 to the relying entity 100 in accordance with, for example, a preference established by, for example, the subject entity 120 and/or the relying entity 100. [1055] In some embodiments, any portion of the information provider 130 (e.g., the information management module 132) can be a hardware-based module (e.g., a digital signal processor (DSP), a field programmable gate array (FPGA)) and/or a software-based module (e.g., a module of computer code, a set of processor-readable instructions that can be executed at a processor). In some embodiments, one or more of the functions associated with the information provider 130 can be included in different modules and/or combined into one or more modules (that can be associated with one or more entities).

[1056] Although not shown, the information management module 132 can be accessed by the subject entity 120 and/or the relying entity 100, for example, via a user interface (e.g., a graphical user interface) at, for example, a terminal device (e.g., a kiosk, a computing device).. In some embodiments, the user interface can be included in, for example, a terminal device associated with the information provider 130. In some embodiments, any portion of the information provider 130 (e.g., the information management module 132) can be, for example, a distributed application and/or a web-based application. In some embodiments, for example, the information management module 132 can be a distributed web-based application that can have one or more portions served from, for example, one or more servers (not shown). In some embodiments, the server(s) can be associated with the subject entity 120, the relying entity 100, and/or a third party (not shown). In some embodiments, for example, the information management module 132 can be accessed via an application programming interface (API). In some embodiments, the relying entity 100 and/or the subject entity 120 can have one or more applications that can be used to access and/or communicate with the information management module 132.

[1057] In some embodiments, the network 150 can be, for example, a local area network (LAN), a wide area network (WAN), a virtual network. In some embodiments, the network 150 can be wired network and/or wireless network. The relying entity 100 and/or the subject entity 120 can be configured to communicate with the information provider 130 via one or more protocols (e.g., Internet Protocol, wireless protocol, session control protocol) [1058] FIG. 2 is a schematic block diagram that illustrates signaling related to transfer of at least a portion of confidential information 236 associated with a subject entity 220 to a relying entity 200, according to an embodiment. As shown in FIG. 2, an information provider 230 includes an information management module 232 configured to manage signaling associated with the transfer of the portion of the confidential information 236. In some embodiments, the confidential information 236 can include, can define, and/or can be from a domain of confidential information.

[1059] As shown in FIG. 2, the information management module 232 is configured to receive from the relying entity 200 one or more signals (line Tl) configured to trigger the information management module 232 to define a request for at least a portion of the confidential information 236. In some embodiments, one or more portions of the request can be automatically defined based on a request policy. In some embodiments, the request can be automatically defined based on a request policy after the subject entity 220 and the specific confidential information desired have been determined by the relying entity 200. [1060] After the confidential information request has been defined, the confidential information request and/or one or more proposed responses to the confidential information request as defined by the information management module 232 based on the confidential information 236 can be sent (line T2) to the subject entity 220. For example, queries within the confidential information request and proposed responses to the queries can be sent to the subject entity 220.

[1061] Although not shown, in some embodiments, the confidential information request can be defined by the relying entity 200 based on one or more predefined queries. In some embodiments, the predefined queries can be defined based on one or more preferences (e.g., preferences included in a request policy) defined by the subject entity 220. For example, the subject entity 220 can be configured to allow, based on a set of preferences, the relying entity 200 to select only a subset of possible predefined queries related to the confidential information 236. The preferences can be stored at, for example, the memory 234 and accessed by the information management module 232.

[1062] The subject entity can respond (line T3) to one or more portions of the confidential information request and/or one or more proposed responses to the confidential information request. In some embodiments, the subject entity 220 can be configured to process (e.g., approve, deny, and/or modify) any combination of one or more portions of the confidential information request and one or more portions of a proposed responses to the confidential information request. In some embodiments, the processing can be automatically performed based on a response policy.

[1063] The information management module 232 can be configured to trigger (line T4) sending of the portion of the confidential information 236 (or proposed response(s) to the confidential information request) to the relying entity (line T5) if at least a portion of the confidential information request has been approved (line T3). Although not shown, in some embodiments, the relying entity 200 can be notified that one or more portions of the confidential information request has been approved, denied and/or modified by the subject entity 220. [1064] In some embodiments, the relying entity 200 and/or subject entity 220 can engage in a negotiation process (e.g., iterative negotiation process) with respect to the confidential information request and/or proposed responses to the confidential information request. For example, the subject entity 220 can receive a query and associated proposed response to the query within a confidential information request. The query and the associated proposed response to the query can be defined, in part, by the information management module 232. If the subject entity 220 denies the query and disallows sending of the proposed response to the query, the information management module 232 can be configured to notify the relying entity 200 of the denial. In response, the relying entity 200 can trigger defining and sending of a modified confidential information request to the subject entity 220. The information management module 232 can be configured to send the modified confidential information request and proposed response to the modified confidential information request to the subject entity 220 for further processing (e.g., approval).

[1065] FIG. 3 is a schematic block diagram that illustrates predefined queries within a request template 322, according to an embodiment. As shown in FIG. 3, the request template 322 includes predefined query set 22 that includes predefined queries QAi through QA_N and predefined query set 24 that includes predefined queries QBi through QB_M. A predefined query can be a predefined question (e.g., a true/false question, an open-ended question, a query for specific information) related to confidential information about a subject entity. In some embodiments, the predefined query can include a checklist of items or issues. In some embodiments, the predefined query sets can include one or more predefined queries. In some embodiments, one or more of the predefined queries can be defined by a subject entity (not shown), the relying entity 340, and/or an information provider (not shown). In some embodiments, one or more of the predefined queries can be a standard query from a pool or library of predefined queries.

[1066] As shown in FIG. 3, a confidential information request 330 that includes predefined query QA₂, predefined query QA_N, and predefined query QB_{M I} is defined in response to a signal from a relying entity 340. Specifically, the relying entity 340 can select the predefined queries from the sets of predefined queries to define the confidential information request 330. Although not shown, the confidential information request 330 can be sent to a subject entity for processing (e.g., approval, disapproval). Although not shown, in some embodiments, the request template 322 can have more or less predefined query sets than those shown in FIG. 3. The predefined query set 22 and the predefined query set 24 can be selected by the relying entity 340 from a library of predefined query sets (not shown).

[1067] In some embodiments, each set of predefined queries can be related to a specific type of confidential information. For example, predefined query set 22 can be related to an age of a person and predefined query set 24 can be related to a medical condition of a person. In some embodiments, one or more predefined queries from predefined query set 22 and one or more predefined queries from predefined query set 24 can be related to similar or the same type of confidential information.

[1068] In some embodiments, each set of predefined queries can have queries related to different privacy levels and/or levels of specificity. For example, predefined query QAi and predefined query QA₂ can be associated with different privacy levels. In some embodiments, for example, the predefined queries within predefined query set 22 can increase in privacy level from predefined query QAi (most invasive) to predefined query QA_N (least invasive). In some embodiments, for example, predefined query QAi can be a question asking for information about whether or not an individual is greater than 21 years old, while predefined query QA₂ can be a question asking for a birth date of the individual. In this case, predefined query QAi is a less specific predefined query (less invasive) than predefined query QA₂ (more invasive). [1069] In some embodiments, the confidential information request 330 can be defined based on a request policy (not shown) defined by the relying entity 340 (also can be referred to as a relying entity request policy). For example, the request policy can be configured to trigger the information management module 320 to automatically define the confidential information request based on only predefined query set 22 and/or based only predefined queries associated with, for example, a particular privacy level.

[1070] In some embodiments, a request policy can be configured to trigger the information management module 320 to request updates of confidential information based on specified predefined queries at specified times, at regular times, and/or at random times. In some embodiments, this type of request policy can be referred to as an update policy. The update requests can be defined by the information management module 320 based on the request policy and can be update requests targeted to the relying entity 340, a subject entity (not shown) and/or a third party (not shown). In some embodiments, an update policy can be defined by the relying entity 340 and/or a subject entity (not shown).

[1071] As shown in FIG. 3, the request template 322 is included in an information management module 320. In some embodiments, the request template 322 can be included in a memory (not shown) at or separate from the information management module 320 that can be accessed by the information management module 320.

[1072] In some embodiments, a request policy associated with (e.g., defined by) a subject entity can be configured to prevent specified predefined queries from being selected by the relying entity 340 (or a request policy associated with the relying entity 340). A request policy associated with a subject entity can be referred to as a subject entity request policy and a request policy associated with the relying entity can be referred to as a relying entity request policy. For example, the information management module 320 can be configured to provide only specified predefined queries (e.g., predefined query sets and/or predefined queries) to a relying entity 340 for possible selection based on a request policy. In some embodiments, for example, the request policy can be defined so that specified predefined queries are provided to the relying entity 340 based on a trust level (e.g., a specified assurance level, a specified level of authentication, a high security access level) associated with the relying entity 340 and/or based an entity type (e.g., hospital, government agency, trusted partner, acquaintance, private unknown individual, internet vendor) associated with the relying entity 340.

[1073] In some embodiments, the information management module 320 can be configured to notify the relying entity 340 that specified predefined queries cannot be selected based on a specified trust-level value (e.g., assurance level value). In some embodiments, the trust-level value can be determined based on an authentication process (e.g., based on authentication of the relying entity 340 with a specified security level attested by a digital certificate). In some embodiments, for example, if the relying entity 340 selects (or attempts to select) a particular predefined query for inclusion in the confidential information request 330, the information management module 320 can be configured to notify the relying entity 340 that the particular predefined query cannot be selected (or may be ignored by the subject entity) based on a request policy associated with the subject entity.

[1074] In some embodiments, the predefined queries provided to the relying entity 340 for possible selection can be determined (e.g., defined) based on a domain of confidential information. For example, only those predefined queries (e.g., predefined query sets and/or predefined queries from a predefined query set) that are related to a specified domain of confidential information can be provided to the relying entity 340 for selection in defining a confidential information request 330. In some embodiments, the predefined queries can be provided to the relying entity 340 for selection via a user interface such as a graphical user interface (not shown).

[1075] In some embodiments, the confidential information request 330 can include customized queries (not shown) in addition to predefined queries. The customized queries can be queries defined based on a module (e.g., a function) provided by the information management module 320. In some embodiments, a request for confidential information (not shown) can be defined by the relying entity 340 based entirely on customized queries that are not predefined. [1076] FIG. 4 is a schematic diagram that illustrates a domain of confidential information 36 defined based on a trust-level value 400 and a relying-entity-type value 410, according to an embodiment. The domain of confidential information 36 defines a subset of confidential information 30 that can be requested by a relying entity via a confidential information request 420. The trust-level value 400 and/or the relying-entity-type value 410 can be determined based on an identity of a relying entity. In some embodiments, the trust-level value 400 and/or the relying-entity-type value 410 can be received in and/or stored at a memory (not shown). These values can be retrieved from the memory and/or processed at the memory. [1077] As shown in FIG. 4, the domain of confidential information 36 is a subset of confidential information 30 that can be defined based on an intersection of a portion 32 of confidential information 30 associated with the trust-level value 400 and based on a portion 34 of the confidential information 30 associated with the relying-entity-type value 410. As shown in FIG. 4, a confidential information request 420 can be defined based on the domain of confidential information 36. [1078] In some embodiments, for example, the portion 32 of the confidential information 30 can be associated with a first set of predefined queries and the portion 34 of the confidential information 30 can be associated with a second set of predefined queries. The intersection of the portion 32 of the confidential information 30 and the portion 34 of the confidential information 30 can be used to determine a third set of predefined queries. The third set of predefined queries can be provided (e.g., presented) to a relying entity and used by the relying entity to define the confidential information request 420.

[1079] In some embodiments, the confidential information 30 can be associated with one or more subject entities. In some embodiments, if associated with multiple subject entities, the domain of confidential information 36 can be further limited based on an identity of the subject entity.

[1080] In some embodiments, a domain of confidential information (not shown) can be determined based on a relying entity value alone or based on a trust-level value alone. In some embodiments, the domain of confidential information 36 can be determined based on a parameter value (e.g., a confidential information category value) in addition to the trust-level value 400 and the relying-entity-type value 410 shown in FIG. 4. More details related to confidential information category values are discussed in connection with FIG. 6. In some embodiments, the trust-level value 400 and/or the relying-entity-type value 410 can be predefined values that can be determined from a database (e.g., a look-up table) based on an identity (e.g., a name) of a relying entity. An example of such a database is shown in FIG. 5. [1081] FIG. 5 is a diagram that illustrates a database 500 that can be used to determine a domain of confidential information, according to an embodiment. As shown in FIG. 5, a relying entity that has a specified relying-entity-type value (shown in column 520) and a specified trust- level value (shown in column 530) can be permitted to define a domain of confidential information related to one or more of the data types 450. Specifically, a relying entity that has a relying-entity-type value of A-2 (column 520) and a trust-level value of R (column 530) can be permitted to define a domain of confidential information 42 related to data type U2 and data type U3. The data type U2 and the data type U3, in this case, collectively define a domain of confidential information 42 for which the relying entity can define a confidential information request. In some embodiments, one or more of the data types 450 can be, for example a medical data type (related to medical information), a personal information data type, a financial data type (related to financial information), and so forth.

[1082] In some embodiments, the relying-entity-type value 520 and the trust-level value 530 can be determined based on an identity (e.g., a name) of the relying entity. The identity can be determined based on, for example, a digital signature, a username, an identifier, and so forth associated with the relying entity.

[1083] As shown in FIG. 5, the portion of confidential information can be defined based on relying-entity-type values 520 and trust-level values 530 associated with a specified subject entity 510. For example, a domain of confidential information associated with subject entity Y (column 510) when a relying entity has the relying-entity-type value of A-I (column 520) and the trust-level value of Q (column 530) is different than a domain of confidential information associated with subject entity Y when the relying entity (or different relying entity) has the relying-entity-type value of A-2 (column 520) and the trust-level value of R (column 530). [1084] As shown in FIG. 5, the domain of confidential information associated with subject entity X is the same no matter what the relying-entity-type value 520 or trust-level value 530 which are both shown with the wildcard value "*". In this case, all data types associated with subject entity X are eligible to be requested in a confidential information request by a relying entity.

[1085] FIG. 6 is a schematic block diagram that illustrates portions of confidential information 50 that are associated with hierarchically related confidential information categories, according to an embodiment. As shown in FIG. 6, confidential information categories CAT-El, CAT-E2, and CAT-E3 are hierarchically (e.g., ancestrally) related to CAT- D2. Specifically, confidential information category CAT-D2 is a parent category of confidential information categories CAT-El, CAT-E2, and CAT-E3 (which can be referred to as child categories or as child confidential information categories). Also, as shown in FIG. 6, confidential information category CAT-C 1 is hierarchically related to confidential information categories CAT-D2 and CAT-Dl.

[1086] Relationships between at least some of the confidential information categories 600 and portions of the confidential information 50 are shown in FIG. 6. Specifically, confidential information category CAT-Dl is associated with portion 52 of confidential information 50, confidential information category CAT-El is associated with portion 53 of confidential information 50, and confidential information category CAT-E2 is associated with portion 56 of confidential information 50.

[1087] If the confidential information 50 is associated with a subject entity, the confidential information categories 600 can be navigated via, for example, a user interface (e.g., a user interface of a device such as a terminal device, a kiosk, and/or a processing device) by a relying entity to select a portion of confidential information associated with the subject entity. The portion of confidential information 50 can correspond with a domain of confidential information from which a confidential information request 630 can be defined. For example, confidential information request 630 can be defined based on one or more predefined queries associated with portion 56 of confidential information 50 (which can be associated with a subject entity) when confidential information category CAT-E2 is selected by, for example, a relying entity. [1088] One or more of the confidential information categories can be, for example, a medical information category, a financial information category, and so forth. In some embodiments, the child categories can be subsets (e.g., species) of the parent categories. In some embodiments, confidential information categories that can be used to select a portion of confidential information (e.g., define a domain of a confidential information) may not be hierarchically related. In some embodiments, the confidential information 50 can be related to more than one subject entity. Accordingly, the confidential information categories 600 can be used to define a domain of confidential information associated with more than one subject entity. In some embodiments, multiple confidential information categories can be selected and the intersection of portions of confidential information can define a domain of confidential information.

[1089] In some embodiments, the hierarchical structure of the confidential information categories 600 can be defined based on an identity of a subject entity. For example, a set of confidential information categories associated with a first subject entity can be different than a set of confidential information categories associated with a second subject entity because the confidential information available in, for example, a database for the first subject entity can be different than the confidential information available for the second subject entity. [1090] In some embodiments, a domain of confidential information can be determined based on a parameter value in addition to one or more of the confidential information categories 600. For example, a domain of confidential information can be defined based on one or more of the confidential information categories as well as based a trust-level value and/or a relying-entity- type value.

[1091] FIG. 7 is a flowchart that illustrates a method for defining a domain of confidential information, according to an embodiment. As shown in FIG. 7, an identity of a relying entity is authenticated at an information management module at 710. The identity of the relying entity can be authenticated based on, for example, one or more digital certificates and/or a username/password combination. In some embodiments, the relying entity can be authenticated based on a credential associated with the relying entity. More details related to authentication based on a credential are described in connection with FIGS. 12-19 below. In some embodiments, the information management module can be, for example, associated with a network-based (e.g., web-based) application. In some embodiments, the information management module can be associated with an information provider.

[1092] An identifier associated with a subject entity is received based on a selection of the subject by the relying entity at 720. The relying entity can select the specified subject entity because the relying entity is interested in requesting confidential information related to the subject entity. In some embodiments, the selection of the subject entity can be performed via a processing device (e.g., a kiosk, a computing device) associated with the information management module. In some embodiments, the subject entity can be automatically selected based on a request policy defined by the relying entity. In response to the selection of the subject entity, the identifier can be received at the information management module. [1093] A trust-level value and/or an entity-type value associated with the relying entity is received at 730. In some embodiments, the trust-level value and/or the entity-type value can be determined based on an identity associated with the relying entity. In some embodiments, the identity of the relying entity can be determined (e.g., acquired, ascertained) when the relying entity is authenticated at 710. In some embodiments, the trust-level value and/or the entity-type value can be determined based on entries included in a database.

[ 1094] An indicator of a confidential information category that has been selected by the relying entity is received at 740. The confidential information category can be selected by the relying entity via a processing device associated with, for example, the information management module. In some embodiments, the confidential information category can be automatically selected based on a request policy defined by the relying entity. In some embodiments, the automatic selection of the confidential information category can be determined based on the identity of the subject entity. In some embodiments, more than one confidential information category can be selected.

[1095] A domain of confidential information associated with the subject entity is defined based on the identifier associated with the subject entity, the trust-level value, the entity-type value, and/or the confidential information category at 750. The domain of confidential information, from which a confidential information request can be defined, can be determined based on one or more of the identifier associated with the subject entity, the trust-level value, the entity-type value, and/or the confidential information category. In some embodiments, the domain of confidential information can be partially defined by the identifier associated with the subject entity and based on the trust-level value, and not based on the entity-type value or the confidential information category. In some embodiments, the domain of confidential information can be defined based on a request policy defined by the subject entity and/or a request policy defined by the relying entity.

[1096] FIG. 8 is a flowchart that illustrates a method for receiving a response to a request for confidential information from a subject entity, according to an embodiment. As shown in FIG. 8, a set of predefined queries associated with a domain of confidential information is provided to a relying entity at 810. The predefined queries can be provided to the relying entity via a processing device (e.g., a kiosk, a computing device) associated with an information management module such that one or more of the predefined queries can be selected. In some embodiments, the information management module can be associated with an information provider.

[1097] In some embodiments, the domain of confidential information can be defined based on a method such as that described in connection with FIG. 7. In some embodiments, the predefined queries can be defined based on a request policy defined by the subject entity and/or the relying entity. In some embodiments, the predefined queries can be defined based on a trust- level value, an entity-type value, and/or an identity of the relying entity. For example, one or more predefined queries can be provided to the relying entity for selection based on a trust-level value associated with the relying entity.

[1098] A request for confidential information from the domain of confidential information is defined based on a predefined query selected by the relying entity from the set of predefined queries at 820. In some embodiments, the predefined query can be selected based on a request policy defined by the relying entity. For example, the predefined query can be selected based on an identity of the subject entity and/or based on a preference (of the relying entity) related to a privacy level associated with the predefined query.

[1099] The request can be sent to the subject entity at 830. In some embodiments, the request can be sent to the subject entity via, for example, an e-mail or an alert to a client module (e.g., a software module). In some embodiments, the subject entity can be notified that a request has been defined by the relying entity. In some embodiments, the subject entity can be provided with the details of the request via, for example, a computing device. In some embodiments, the subject entity can be authenticated (e.g., authenticated via one or more a digital certificates, authenticated based on a username/password combination) before being permitted to access details related to a request at, for example, an information management module. In some embodiments, the subject entity can be authenticated based on a credential associated with the subject entity. More details related to authentication based on a credential are described in connection with FIGS. 12-19 below. [1100] A response to the request is received from the subject entity at 840. In some embodiments, the response can be a modification of at least a portion of the request. In some embodiments, the response can include a denial of at least a portion of the request (e.g., one or more portions of one or more predefined queries). In some embodiments, the response can include an approval of at least a portion of the request (e.g., one or more portions of one or more predefined queries).

[1101] Although not shown, in some embodiments, a proposed response to the request can be defined and sent to the subject entity for a response (e.g., approval, modification, denial). In some embodiments, the response (of the subject entity) to the proposed response (defined by the information management module) can be defined based on a response policy defined by the subject entity. For example, the response policy can be defined such that only specified types of confidential information can be accessed by the relying entity based on, for example, a trust- level value associated with the relying entity or an identity of the relying entity. In some embodiments, the response policy can include a default option for allowing a relying entity to access confidential information associated with a subject entity.

[1102] FIG. 9 is a flowchart that illustrates a method for negotiating a response related to a confidential information request, according to an embodiment. As shown in FIG. 9, a request for confidential information from a domain of confidential information is defined based on an input from a relying entity at 900. In some embodiments, the input can be a selection of a predefined query. In some embodiments, the input can be a customized query. [1103] A response to the request is defined at an information management module of an information provider at 910. In some embodiments, the response can be defined based on a response policy defined by a subject entity. In some embodiments, the response can be referred to as a proposed response.

[1104] The response to the request is sent to the subject entity for approval at 920. In some embodiments, the response to the request can be sent to the subject entity for approval before, after, or along with the request for the confidential information from the domain of confidential information.

[1105] If the response is approved at 930, the response to the request is sent to the relying party at 950. If the response is not approved, the response to the request can be negotiated at 940. In some embodiments, the negotiation can take place between the subject entity with the relying entity via the information management module. In some embodiments, if the request is defined based on predefined queries, one or more predefined queries can be removed, added, and/or modified during a negotiation process. Also, in some embodiments, one or more proposed responses can be removed, added, and/or modified during a negotiation process. In some embodiments, both the subject entity and the relying entity can be informed that negotiation of the response to the request will take place off-line (e.g., between the parties without the assistance of the information management module).

[1106] Although not shown, in some embodiments, one or more queries within the request can be negotiated instead of the response to the request. In such cases, the response can also be modified based on the change(s) to the queries within the request. In some embodiments, both the request and response to the request can be negotiated.

[1107] FIG. 10 is a schematic diagram that illustrates sources 1050 associated with an information provider 1010, according to an embodiment. The sources 1050 include sources IPi through IP_Q. The sources can be configured to share confidential information such as account information, personal information, and so forth to a relying entity 1000 via the information provider 1010 when the sharing of the confidential information is approved by the subject entity 1020. As shown in FIG. 10, the information provider 1010 can have an information management module 1032. The information management module 1032 can have a source database 1042.

[1108] The subject entity 1020 can be configured to select one or more of the sources 1050 for sharing confidential information with the relying entity 1000 via the information management module 1032. Specifically, the information management module 1032 can be configured to provide a subject entity 1020 with one or more options so that the subject entity 1020 can select one or more of the sources 1050 to respond to a request for confidential information. The options can be determined based on entries included in the source database 1042. For example, the subject entity 1020 can select source IPi rather than any of the other sources 1050 (which could also provide an appropriate response) as a source of confidential information defined within a response to a request for confidential information from the relying entity 1000. Source IPi can be provided as a potential source of confidential information based on an entry included in the source database 1042.

[1109] In some embodiments, the source can be determined based on a response policy defined by the subject entity 1020. In some embodiments, one or more of the sources 1050 can be associated with different reliability values. For example, source IPi can be considered a more reliable source than source IP₂ based reliability values that are respectively associated with each. In some embodiments, the relying entity 1000 can define a request policy that specified that only responses to requests for confidential information will be accepted from only one or more of the sources 1050. [1110] FIG. 11 is a schematic block diagram that illustrates a terminal device 1110 configured to receive credential data from a credential 90, according to an embodiment. The credential data can be used by the terminal device 1110 to, for example, authenticate an identity of an individual 92 (also can be referred to as credential owner) and/or determine an authenticity of the credential 90. In some embodiments, the identity of the individual 92 can be authenticated based on credential data such as credential-owner authentication information (e.g., a personal identification number (PIN), information related to a characteristic of the individual 92 (e.g., biometric information)). The credential data from the credential 90 can be processed during an authentication process. In some embodiments, the authenticity of the credential 90 can be determined based on credential data such as credential-issuer validation information (e.g., a digital certificate associated with an issuer of the credential 90). [1111] As shown in FIG. 11 , the terminal device 1110 is in communication with an information provider 1130 associated with domain 1140. A request for confidential information, defined by the relying entity 1100, from the information provider 1130 can be accessed by the individual 92 at the terminal device 1110 after an authentication process performed at the terminal device 1110. The confidential information can be associated with the individual 92. In some embodiments, the individual 92 can be referred to as a subject individual or as a subject entity.

[1112] In some embodiments, the individual 92 can be denied access to process the request (e.g., approve, deny, modify, and/or negotiate the request) for confidential information unless access has been granted to the individual 92 via the authentication process. In some embodiments, the individual 92 can be permitted to access confidential information maintained by the information provider 1130 via the terminal device 1110 after access has been granted to the individual 92 via the authentication process. In some embodiments, one or more policies (e.g., update policy, response policy) can be accessed (e.g., modified) only after successfully completing the authentication process.

[1113] In some embodiments, the relying entity 1100 can have a credential (not shown) that can be used during an authentication process. In some embodiments, for example, the relying entity 1100 can be permitted to make a request for confidential information based on an authentication process at terminal device 1110 or a different terminal device (not shown). More details related to authentication based on a credential and terminal devices are described in connection with FIGS. 12-19 below.

[1114] Although not shown, in some embodiments, the terminal device 1110 can be configured to communicate (e.g., communicate via a network) with an identity database associated with the individual 92. The individual 92 can access and select an identity (e.g., an alias) from the identity database via the terminal device 1110. The individual 92 can also trigger sending of the selected identity to the relying entity 1100 from the identity database via the terminal device 1110. In other words, the individual 92 can assert an identity to the relying entity 1100 via the terminal device 1110. The individual 92 can maintain several aliases in the identity database. This type of architecture can enable the individual 92 to use, for example, a specified alias (e.g., an alias associated with a specified e-mail address and/or mailing address) when transacting with an unknown vendor (e.g., an unknown relying entity) and another alias (e.g., an alias with a different email address and/or different mailing address) when transacting with a trusted vendor (e.g., a trusted/known relying entity). In this way, for example, the individual can prevent, or substantially prevent, possible spam from the unknown vendor from reaching, for example, a specified (e.g., a preferred) email address, which may be shared only with trusted vendors.

[1115] A domain associated with an entity (e.g., an individual, a business, an organization, an agent (e.g., a human agent, an electronic agent) of an individual/business/organization) can be accessed by an individual using a credential via a terminal device. Specifically, the credential can include credential data, such as credential-owner authentication information associated with the individual and/or credential-issuer validation information associated with the issuer of the credential. The credential-owner authentication information and the credential-issuer validation information can be used in an authentication operation. The terminal device can be configured to receive credential data from the credential and to use the credential data as part of an authentication operation. In some embodiments, the credential can be a token. [1116] In some embodiments, privilege data representing privileges associated with the individual can be received (e.g., retrieved) from a privilege database based on credential data from a credential. In some embodiments, the privilege data can be associated with a particular domain or multiple domains. Accordingly, the credential data from the credential can be used to access one or more domains. In some embodiments, the domains can be independent (e.g., mutually exclusive) domains. In some embodiments, the privilege data can be distributed and accessed via one or more domain based on credential data from a credential. In some embodiments, the credential can be referred to as a universal credential because it can be used to access multiple domains.

[1117] In some embodiments, the terminal device can be configured to display to the individual one or more transaction options associated with one or more domains and/or one or more information sources. In some embodiments, the terminal device can be configured to communicate with (e.g., exchange information with) an information provider associated with one or more domains and/or one or more information sources.

[1118] In some embodiments, the terminal device can be configured to authorize the release of confidential information (e.g., personal information) associated with the individual to a relying party (such as a retailer) after the relying party and/or the individual has been authenticated. In some embodiments, the identity validation process can be based in part on supplemental authentication information (e.g., personal identification information) received from the individual. In some embodiments, the terminal device can be configured to compare the received supplemental authentication information with a portion of the credential-owner authentication information to authorize transmission of personal information associated with the individual to the relying party. In some embodiments, the individual can be referred to as a credential holder or as a token holder.

[1119] FIG. 12 is a schematic block diagram that illustrates multiple terminal devices associated with multiple domains, according to an embodiment. Specifically, FIG. 12 illustrates terminal devices TDi through TD_N associated with domains Di through D_N, respectively. The terminal devices TDi through TD_N can collectively be referred to as terminal devices 1250. [1120] As shown in FIG. 12, one or more of the terminal devices 1250 can be configured to receive credential data from a credential 1210 associated with an individual 1212. In some embodiments, the credential 1210 can include credential-issuer validation information that can be used to determine an authenticity of the credential and/or credential-owner authentication information that can be used to authenticate (e.g., validate) an identity of the individual 1212. In some embodiments, the credential-issuer validation information can include information that can be used to determine (e.g., verify, authenticate) the pedigree of the credential such as the name of the issuer (e.g., credential service provider), the date of issuance of the credential, certification level of the issuer of the credential, and/or various other information about the process or level of trust associated with the process used by the issuer to issue the specified credential.

[1121] In some embodiments, the credential 1210 can be an object (e.g., a physical object) that has one or more modules configured to send information to at least one of the terminal devices 1250. In some embodiments, the credential 1210 can be a card that includes, for example, a module configured to emit a wireless data signal, a magnetic strip, and/or a barcode. In some embodiments, the credential 1210 can be or can include one or more radio frequency modules (e.g., a microchip) associated with (e.g., included in, on, embedded within, coupled to, disposed within) an object such as a mobile electronic device (e.g., a mobile telephone), a watch, a piece of jewelry, an item of clothing, a key chain, and/or other portable item. [1122] The terminal device TDi can be configured to perform at least a portion of an authentication operation based on the credential data received from the credential 1210 associated with the individual 1212. Specifically, the credential data received from the credential 1210 can be used to determine the authenticity of the credential 1210 and/or to authenticate the identity of the individual 1212 at one or more of the terminal devices 1250 and/or at one or more of the domains 1260. For example, credential data can be received at terminal device TDi. Terminal device TDi can be configured to send the credential data to a domain Di where the credential data can be used to determine the authenticity of the credential 1210 and/or to authenticate the identity of the individual 1212.

[1123] In some embodiments, the terminal device TDi can be configured to display information to and/or receive secondary personal identification information from the individual 1212. In some embodiments, the personal identification information can be used to authenticate the identity of the individual 1212 in addition to the credential-owner authentication information. In some embodiments, the terminal device TDi can be included in (e.g., a component part of) the domain D₁. In some embodiments, at least a portion of the credential- owner authentication information can be (or can include) a personal identification number (PIN), a digital certificate, and/or information related to a characteristic of the individual 1212 (e.g., biometric information).

[1124] In some embodiments, the terminal device TDi can be any type of device (e.g., physical device) configured to receive information (such as credential data) from the credential 1210. For example, the terminal device TDi can be and/or can include a computer kiosk, a contact reader (e.g., a magnetic card reader), a wireless card reader, and/or a contactless card reader (e.g., an Radio-Frequency Identification (RFID) card reader). In some embodiments, the terminal device TDi can be configured to receive information from the credential 1210 via a card swipe (if the credential 1210 is a card), a bar code scan (if the credential 1210 includes a bar code), and so forth. In some embodiments, the terminal device TDi can be configured to communicate (e.g., exchange information) with the credential 1210 via an RFID signal, a wireless transfer protocol such as Bluetooth, a wireless USB protocol, an Ultrawide Band (UWB) signal, a signal encoded using optical or infrared radiation, a cellular telephone network, a wireless computer network, and so forth. In some embodiments, the terminal device TDi can be configured to receive data input from the individual 1212 via an input device such as a touch screen, a computer keyboard, a computer mouse, or other data input device. [1125] In some embodiments, the terminal device TDi can be further configured to grant and/or deny one or more portions of the request of the individual 1212 associated with the credential 1210 based on success/fail result information associated with an authentication operation. In some embodiments, the terminal device TDi can be configured to send credential data received from the credential 1210 to the domain Di during performance of a portion of the authentication operation of the credential 1210 associated with the individual 1212. In some embodiments, the terminal device TDi can be further configured to receive authentication operation success/fail result information from the domain Di when the authentication operation is performed at the domain Di. In some embodiments, the terminal device TDi can be configured to grant and/or deny one or more portions of the request of the individual 1212 based on the received authentication operation results.

[1126] After an authentication process has been performed based on the credential 1210, the individual 1212 can trigger a transaction associated with one or more of the terminal devices 1250 and/or one or more of the domains 1260. In some embodiments, the terminal device TDi, for example, can be configured to execute one or more operations related to a transaction that can be initiated by the individual 1212. The terminal device TDi can be configured to grant the individual 1212 associated with the credential 1210 access to initiate an operation at the terminal device TDi as part of a transaction.

[1127] Examples of transaction types that can be initiated by the individual 1212 include financial transactions, confidential information access transactions, location access transactions (to a protected location or resource), and so forth. In some embodiments, for example, the terminal device TDi can be configured to provide a user interface (e.g., a graphical user interface) that can be used by the individual 1212 during one or more portions of a transaction. In some embodiments, one or more of the functions associated with the transaction can be disposed within the domain D₁.

[1128] In some embodiments, one or more of the domains 1260 can be configured to exchange credential data and/or information associated with the execution of a transaction with at least one of the terminal devices 1250. In some embodiments, the information associated with the execution of a transaction can be referred to as transaction-related information. In some embodiments, the domain Di can be configured to execute at least a portion of an operation associated with the credential 1210 and the individual 1212, such as an operation associated with the transactions mentioned above.

[1129] In some embodiments, the domain Di can include one or more processing devices (not shown) that can be in communication such that they define a network. The one or more processing devices can be associated with a single entity or group of affiliated entities. For example, the domain Di can include one or more computerized devices such as a networked computer server. In some embodiments, the domain Di can be in communication with a terminal device TDi via a wired link and/or a wireless link. In some embodiments, the domain Di can include personal identification information used to authenticate the individual 1212 using the credential 1210. In some embodiments, the domain Di can include, for example, terminal device TDi as part of the domain D₁.

[1130] In some embodiments, the individual 1212 can be a human being (e.g., a unique human being). In some embodiments, the individual can be a group of human beings associated with one another through, for example, a common level of access, a group affiliation, or another shared characteristic (e.g., common ownership of an account by an individual and/or institution). [1131] In some embodiments, the credential 1210 can be configured to send credential data to the terminal device TDi during an authentication operation. In some embodiments, the credential 1210 can be configured to send credential data to the terminal device TDi such that the individual 1212 and/or the credential 1210 can be authenticated based on an authentication operation. In some embodiments, the credential 1210 can be configured to send credential data to the terminal device TDi during execution of at least a portion of a transaction. It should be understood that although many of the above examples relate to terminal device TDi and domain D₁, the examples could be applied to any of the terminal devices 1250 and/or to any of the domains 1260_.

[1132] FIG. 13 is a schematic block diagram that illustrates multiple terminal devices associated with multiple domains, according to an embodiment. Specifically, FIG. 13 illustrates terminal device 1310 and terminal device 1320 in communication with a privilege database 1322, terminal device 1310 in communication with domain E₁, and terminal device 1320 in communication with domains Ei through E_N, according to an embodiment. The domains Ei through E_N can collectively be referred to as domains 1350. As shown in FIG. 13, the credential 1360, which is associated with individual 1352, includes credential-issuer validation information 1364 and credential-owner authentication information 1366. The credential-issuer validation information 1364 and the credential-owner authentication information 1366 can be referred to as credential data.

[1133] In some embodiments, the credential 1360 can be an object used by the individual 1352 to authenticate its identity and the identity of the individual 1352 so that the individual 1352 can initiate a transaction of a particular transaction type (e.g., a financial transaction, a request for access to a physical location, a request to access information, a transmission of proof of age, a transmission of proof of identity, etc.). In some embodiments, the credential-issuer validation information 1364 can be a digital certificate included (e.g., on, embedded within, coupled to, disposed within) in a memory (not shown) such as a read-only memory (ROM) and/or a flash memory. In some embodiments, the credential-owner authentication information 1366 can include a digital certificate included (e.g., on, embedded within, coupled to, disposed within) in the memory (or in a different memory (not shown)).

[1134] In some embodiments, the credential-owner authentication information 1366 can include supplemental authentication information (e.g., biometric data, thumbprint data, a PIN) associated with the individual 1352 and/or the credential issuer. In some embodiments, supplemental authentication information can be used to, for example, verify the identity of the individual 1352. In some embodiments, the supplemental authentication information can be compared by the terminal device 1310 with information received at the terminal device 1310 from the individual 1352 (e.g., a username and/or password, a PIN, biometric information) as part of an authentication operation.

[1135] In some embodiments, the credential 1360 can include a credential module 1368 that includes hardware and/or software configured to send credential data such as credential-owner authentication information 1364 and/or credential-issuer validation information 1366 to the terminal device 1310. In some embodiments, the credential module 1368 can be configured to determine whether or not the credential data should be transmitted from the credential 1360 to, for example, terminal device 1320.

[1136] As shown in FIG. 13, terminal device 1310 is in communication with domain E₁. Although not shown, in some embodiments, terminal device 1310 can be associated with one or more of the domains 1350 (e.g., a company, a government entity, a living quarters, etc.). In some embodiments, the terminal device 1310 can be configured to receive the credential data (e.g., credential-issuer validation information 1364 and/or credential-owner authentication information 1366) from the credential 1360 associated with the individual 1352. [1137] In some embodiments, the terminal device 1310 can be configured to send the credential data to the privilege database 1322 (or a processor (not shown) associated with the privileged database 1322) as part of a request for privilege data associated with (e.g., pertaining to) the individual 1352. In some embodiments, the terminal device 1310 can be configured to receive privilege data associated with the individual 1352 from the privilege database 1322. The privilege data can include, for example, a list of privileges granted to the individual 1352 associated with access to a resource (e.g., a physical location, an object, confidential information, etc.) or authorization (e.g., rights) to initiate a transaction (e.g., a financial transaction).

[1138] In some embodiments, the terminal device 1320 can be configured to define and send an authentication status signal (e.g., an authentication success indicator, an authentication failure indicator) to the credential 1360. In some embodiments, the terminal device 1320 can be configured to display an authentication status indicator. For example, the terminal device 1320 can be configured to display an authentication status indicator at a user interface such as a graphical user interface, by illuminating a colored indicator light, producing an audible indicator, and so forth. In some embodiments, the terminal device 1320 can be configured to send an authentication status signal to one or more of the domains 1350 and/or a signal configured to cause one or more of the domains 1350 to execute a task in response to the status signal. The task can be, for example, to unlock a door, execute a withdrawal from a bank account associated with the domain, open or close a turnstile, or return requested information. [1139] As shown in FIG. 13, the privilege database 1322 is associated with terminal device 1310 and terminal device 1320. In some embodiments, for example, the privilege database 1322 can be configured to receive a signal from the terminal device 1310 that includes a request for privilege data associated with the individual 1352. In some embodiments, the request for privilege data can include credential data associated with the individual 1352 and/or the issuer of the credential. In some embodiments, the privilege database 1322 can be configured to send privilege data associated with the individual 1352 and/or the credential issuer to the terminal device 1310.

[1140] In some embodiments, the privilege database 1322 can include entries (e.g., one or more digital records) that represent privilege data and/or authentication information. In some embodiments, the privilege database 1322 can include entries that represent personal information associated with the individual 1352 (e.g., mailing address, physical characteristics, etc.) in addition to privilege data and/or authentication information. The privilege data, authentication information, and/or personal information can be changed by a system administrator or other individual associated with the privilege database 1322, when necessary. Thus, the need for issuance of a new credential to the individual 1352 can be avoided. This physical separation (from the credential 1360) of privilege data, authentication information, and/or personal information associated with the individual 1352 can result in greater efficiency than models where this type of information associated with a credential-bearer is included on, for example, a paper credential itself. [1141] In some embodiments, the privilege database 1322 can be a relational database (e.g., a relational database system) configured to communicate based on a query language such as structured query language (SQL), another relational database system, a series of digital files, a series of digital tables, and/or another digital record which represents information associated with one or more individuals, one or more credentials, one or more domains, and/or one or more privileges. In some embodiments, the privilege database 1322 can be a computer server including a set of digital records as described above and hardware and/or software for executing at least a portion of an authentication operation.

[1142] FIG. 14 is a diagram that illustrates a privilege data database 1400, according to an embodiment. In some embodiments, the privilege database 1400 includes data entries stored in column entries and row entries. In some embodiments, the privilege database 1400 includes columns individual 1410, credential 1420, domain 1430, and privileges 1440. [1143] In some embodiments, the privilege database 1400 can be defined based on a set of digital records representing privilege and authentication information. For example, in some embodiments, the privilege database 1400 can be a relational database system based on a query language such as Structured Query Language (SQL), another relational database system, one or more digital files, one or more spreadsheet files, or another data storage repository. [1144] In some embodiments, the column individual 1410 includes row entries containing text associated with the identity an individual (e.g., an employee name, a customer ID number). In some embodiments, the column credential 1420 can include row entries containing text associated with one or more credentials (e.g., a credential description, a credential serial number, a credential ID number). In some embodiments, the database can be configured to include one or more row entries in the column domain 1430 containing text associated with the identity of a domain (e.g., a company name, an employer name, a building name). In some embodiments, the database can be configured to include one or more row entries in the column privileges 1440 containing text associated with a privilege (e.g., a privilege allowing access to a particular door or physical location, a privilege allowing access to information associated with a bank account, a privilege granting authority to release funds associated with a bank account, a privilege allowing check-out of materials from a library, etc.).

[1145] In some embodiments, the privilege database 1400 can be included in a computerized device (not shown). In some embodiments, the privilege database 1400 can configured to receive and process privilege data requests based at least in part on a specified value for one or more of the columns individual 1410, credential 1420, domain 1430, and/or privileges 1440. For example, a processing device such as a terminal device can determine that individual A (column 1410) can have privileges Q2 (column 1440) associated with domain Y (column 1430) based on an authentication process related to credential Q (column 1420). The authentication process can be based on credential data received from credential Q.

[1146] FIG. 15 is a schematic block diagram that illustrates a terminal device 1500, according to an embodiment. As shown in FIG. 15, a terminal device 1500 (e.g., a computerized device, a computer kiosk) can include a display 1520 (e.g., a monitor, a touch-screen display). The display 1520 can be configured to display several transaction options 1525 (shown as transaction options Bi through B₅). In some embodiments, the transaction options 1525 can be associated with (e.g., can define) an interface (e.g., a graphical user interface). [1147] In some embodiments, the transaction options 1525 can be, for example, virtual buttons or actual buttons included in the terminal device 1500. Although not shown, in some embodiments, the terminal device 1500 can be configured to provide one or more transaction options to, for example, an individual via a mechanism (e.g., a light indicator) other than, or in addition to the display 1520.

[1148] As shown in FIG. 15, each of the transaction options Bi through B₅ is associated with at least one of domains Gi through G₄ (collectively can be referred to as domains 1535). For example, transaction option B₂ and transaction option B₄ are associated with domain G₂ as illustrated by the dashed arrows. Also, transaction option Bi is associated with domain G₁. [1149] The transaction options 1525 shown in FIG. 15 can be configured to trigger execution of a transaction (or an application associated with a transaction) related to one or more of the domains 1535 when selected (e.g., actuated). For example, transaction option B₁, which is associated with domain G₁, can be configured to trigger execution of an application associated with transfer of funds associated with domain Gi when transaction option Bi is selected by an individual. In some embodiments, one or more of the transaction options 1525 can be configured to trigger a transaction related to an account balance, a purchase of an item, access to a building, access to a government record, etc.

[1150] In some embodiments, an individual can be permitted to access one or more of the transaction options 1525 only after an authenticity of a credential possessed by the individual has been determined and/or the identity of the individual has been authenticated (during an authentication process). Accordingly only certain transaction may be triggered by the individual based on the authentication process. Although not shown, in some embodiments, only a subset of the transaction options 1525 may be displayed on the display 1520 based on a credential and/or an identity of an individual. [1151] Although not shown, in some embodiments, the terminal device 1500 can be configured to communicate (e.g., exchange data) with any number of one or more of the domains 1535, for example, via a wired network and/or a wireless network. In some embodiments, an individual (not shown) can select, for example, transaction option Bi via an input device (e.g., a touch screen display, a computer mouse, a computer keyboard, a keypad) associated with (e.g., in communication with via wired or wireless link to) the terminal device 1500.

[1152] In some embodiments, the terminal device 1500 can be configured to send and/or receive various type of transaction-related information associated with a transaction initiated by an individual via one or more of the transaction options 1525. In some embodiments, the transaction-related information can be transferred between the terminal device 1500 and one or more of the domains 1525. The transaction-related information can be received by the terminal device 1500 before a transaction, during a transaction, and/or after the transaction has been initiated.

[1153] In some embodiments, the transaction-related information can be used to trigger the transaction and/or enable the transaction to be initiated. In some embodiments, credential data received from a credential and/or supplemental authentication information can be used as transaction-related information. For example, credential data that is received from a credential before a transaction is initiated can be used during a transaction to facilitate the transaction. In some embodiments, transaction-related information can be configured to facilitate execution or completion of a transaction. In some embodiments, transaction-related information can be retrieved and communicated to an individual after a transaction has been completed. [1154] In some embodiments, input data solicited from an individual by the terminal device 1500 can be used as transaction-related information. In other words, input data from an individual can be in connection with a transaction. In some embodiments, one or more devices (not shown) associated with (e.g., included within) one or more of the domains 1535 can be configured to solicit input data from the individual during a transaction. For example, a transaction (or an application associated with a transaction) related to domain G₃ can be initiated in response to transaction option B₃ being selected by an individual. A request for input data (e.g., transaction-related information such as an account number or a date range) can be defined at the domain G₃ and communicated to the individual via the terminal device 1500. In other words, the individual can be prompted to enter input data. In response, the individual can enter information at the terminal device 1500 that can then be communicated to the domain G₃ via the terminal device 1500. In some embodiments, transaction-related information can be displayed on the display 1520 of the terminal device 1500.

[1155] FIG. 16 is a schematic block diagram that illustrates multiple gateway devices associated with multiple domains, according to an embodiment. Specifically, FIG. 16 illustrates gateway device 1620 in communication with domain F₁, and gateway device in communication with domain F₂ and domain F₃. In some embodiments, the gateway device 1620 and/or gateway device 1630 can be configured to communicate via a wireless link and/or a wired link. The gate way device 1620 and/or the gateway device 1630 are configured to communicate with the terminal device 1610.

[1156] As shown in FIG. 16, the gateway device 1630 includes a privilege database 1632. The privilege database 1632 can be stored in a local memory (not shown) of the gateway device 1630. As shown in FIG. 16, the gateway device 1620 is in communication with a privilege database 1622 that is not disposed within the gateway device 1620. In other words, the privilege database 1622 can be remote database. Gateway device 1620 and gateway device 1630 can be collectively referred to as gateway devices 1640. For example, the gateway device 1630 can be configured to retrieve privilege data associated with an individual 1652 from the privilege database 1622 based on credential data from the credential 1650.

[1157] In some embodiments, the gateway devices 1640 can be associated with (e.g., controlled by, pertains to, is owned by) a third party (not shown) such as an information provider or data clearinghouse. In some embodiments, the terminal device 1610 can be also be associated with (e.g., controlled by) the third party. Although not shown, in some embodiments, multiple gateway devices can be configured to communicate with a single domain. [1158] As shown in FIG. 16, one or more of the gateway devices 1640 can be configured to receive credential data from a credential 1650. For example, gateway device 1630 can be configured to receive credential data from the credential 1650 via the terminal device 1610 and/or can be configured to communicate transaction-related information with the terminal device 1610. The gateway device 1630 can be configured to exchange transaction-related information (e.g., an account number, a bank account balance, etc.) with, for example, domain Fi. In some embodiments, the gateway device 1630 can be configured to initiate a transaction at least in part by sending the credential data and/or transaction execution information to the domain Fi.

[1159] FIG. 17 is a flow chart that illustrates a method for authenticating an individual and a credential, according to an embodiment. As shown in FIG. 17, credential-owner authentication information associated with an identity of an individual is received from a credential at 1700. In some embodiments, the credential-owner authentication information can be a digital certificate. In some embodiments, the credential can be a card including, for example, an RFID microchip. In some embodiments, the credential-owner authentication information can be received at a terminal device, such as a contactless card reader. In some embodiments, the credential can be configured to transmit credential-owner authentication information associated with the identity of the individual to the terminal device (e.g., the contactless card reader) via an emitted radio signal.

[1160] In some embodiments, an individual can be authenticated for purposes of allowing access to a plurality of financial transactions at a computerized bank kiosk equipped with a touch screen display based on the credential-owner authentication information. A contactless card reader can be coupled to and configured to transmit information to the computerized kiosk over a wired connection. The credential-owner authentication information can be received at the contactless card reader when the credential is positioned within a specified physical proximity of the contactless card reader terminal device.

[1161] Credential-issuer validation information associated with an issuer of the credential is received at 1710. In some embodiments, the credential-issuer validation information can be a digital certificate. The credential-issuer validation information can be received at, for example, a contactless card reader when the individual swipes the credential at a terminal device. In some embodiments, the credential can be configured to transmit the credential-issuer validation information associated with an issuer of the credential by emitting a radio frequency signal. [ 1162] A plurality of transaction options including a first transaction option associated with a first domain and a second transaction option associated with a second domain can be provided at 1720. In some embodiments, the transaction options can be provided to an individual. In some embodiments, the first transaction option can be a financial transaction option (such as a balance inquiry) associated with a first bank account associated with a first financial institution. The second transaction option can be a financial transaction option (such as a cash withdrawal) associated with a second bank account associated with a second financial institution. The first financial institution and the second financial institution can be independent institutions. In some embodiments, the first transaction option and the second transaction option can be provided to the individual via a display included in a terminal device.

[1163] An indicator that the first transaction option has been selected is received at 1730. In some embodiments, a terminal device can be configured to receive the indicator that the first transaction option has been selected by the individual. [1164] The credential-owner authentication information associated with the identity and the issuer validation information associated with the issuer is sent to a portion of the first domain in response to the indicator at 1740. The credential-owner authentication information and the credential-issuer validation information can collectively be referred to as credential data. The credential data can be sent from a terminal device (where this information is received) to a processing device within the first domain. In some embodiments, the credential data can be sent in response to a request from the first domain. In some embodiments, the credential data can be sent in response to a portion of a transaction being executed at the terminal device. [1165] The identity of the individual is authenticated and the authenticity of the credential is determined at the portion of the first domain at 1750. In some embodiments, the authenticity can be determined based on the credential data. In some embodiments, a remote computer network associated with the first domain can be configured to receive the credential data. The remote computer network can be configured to execute a comparison between the credential-owner authentication information associated with the identity of the individual and stored identity information (either on the credential or within the first domain, or both) associated with the individual to determine the authenticity of the individual. The remote computer network can also be configured to execute a comparison between the credential-issuer validation information associated with the issuer of the credential and stored valid credential-issuer information to determine the authenticity of the credential.

[1166] FIG. 18 is a schematic block diagram that illustrates a relying entity 1800 and a terminal device 1810 that are configured to communicate with an information provider 1830, according to an embodiment. In some embodiments, the relying entity 1800 can be a retail store, an age-restricted establishment, etc.. In some embodiments, information provider 1830 can be, for example, a data warehouse. Additionally, FIG. 18 illustrates an information provider 1830 configured to communicate with a domain 1840. In some embodiments, the relying entity 1800, the terminal device 1810, the information provider 1830, and the domain 1840 can be configured to communicate via a wired or wireless link. In some embodiments, the information provider 1830 can be included in (e.g., can be a component part of) the domain 1840. Although not shown, in some embodiments, the relying entity 1800 can be configured to communicate with the information provider 1830 through the terminal device 1810. In some embodiments, the terminal device can be owned by (e.g., controlled by) the information provider 1830. [1167] In this embodiment, authentication based on a credential 60 is required before transmission of confidential information (e.g., personally identifiable information) associated with an individual 62 to the relying entity 1800 is permitted. For example, a terminal device 1810 can be configured to require authentication of an identity of the individual 62 and/or determination of an authenticity of the credential 60 before confidential information associated with the individual 62 (e.g., a date of birth) is sent by an information provider 1830 to the relying entity 1800. In some embodiments, explicit approval by the individual 62 must be acquired before sending of the confidential information to the relying entity 1800 is permitted. More details related to authorization of data transmissions related to confidential information are described in connection with FIGS. 1-11 above. Although not shown, in some embodiments the individual 62 can be a referred to as a subject entity and/or as a subject individual. [1168] In addition, in some embodiments, the relying entity 1800 can be a credential owner (similar to the individual 62) and can be, for example, granted access to the information provider 1830 (e.g., access to confidential information maintained by the information provider 1830 and associated with the individual 62) based on an authentication process (based on the credential associated with the relying entity 1800).

[ 1169] In some embodiments, the terminal device 1810, which can be associated with the relying entity 1800 can be configured to define and send a request for confidential information associated with the individual 62 (e.g., age of the individual 62) to the information provider 1830. For example, in some embodiments, the relying entity 1810 can be a vendor and the terminal device 1810 can be a kiosk at the vendor. After the information provider 1830 receives the request for the confidential information from the terminal device 1810, the information provider 1830 can be configured to send to the terminal device 1810 an authentication-triggering signal (also known as an initiation signal). The authentication-triggering signal can be configured to trigger (based on an instruction) the terminal device 1810 to initiate an authentication operation based on credential data from the credential 60. In some embodiments, the terminal device 1810 can be configured to receive the authentication-triggering signal from the information provider 1830. In some embodiments, the request for confidential information can be defined based on a predefined query and/or a standard query. More details related to predefined queries and/or standard queries are described in connection with FIGS. 1-12 above. [1170] In some embodiments, the terminal device 1810 can be configured to display a prompt (e.g., via a display included in the terminal device 1810, not shown) that requests input of supplemental authentication information (e.g., a PIN, biometric information) associated with the individual 62. In some embodiments, the terminal device 1810 can be configured to receive a signal containing the requested supplemental authentication information via an input device (e.g., a touch screen, a computer mouse and/or keyboard, a keypad, a thumbprint scanner, a retina scanner, etc.) associated with (e.g. in communication with, included in) the terminal device 1810. In some embodiments, the terminal device 1810 can be configured to compare the supplemental authentication information to credential-owner authentication information (such as a PIN number and/or biometric information) from the credential 60 to authenticate the identity of the individual 62.

[1171] In some embodiments, the terminal device 1810 can be configured to send a signal indicating the success or failure of the authentication operation to the information provider 1830. In some embodiments, the signal can be referred to as a success/failure signal. In some embodiments, the information provider 1830 can be configured to receive the success/failure signal. If the value of the received success/failure signal includes information associated with a successful identity validation, the information provider 1830 can be configured to send the confidential information to the relying entity 1800 for use in the transaction. In some embodiments, the information provider 1830 can be configured to transfer confidential information in response to a successful authentication process and approval of the transfer of the confidential information by the individual 62. In some embodiments, the terminal device 1810 can be configured to display a message indicating the success or failure of the authentication operation.

[1172] Although not shown, in some embodiments, the terminal device 1810 can be configured to communicate (e.g., communicate via a network) with an identity database associated with the individual 62. The individual 62 can access and select an identity (e.g., an alias) from the identity database via the terminal device 1810. The individual 62 can also trigger sending of the selected identity to the relying entity 1800 from the identity database via the terminal device 1810. In other words, the individual 62 can assert an identity to the relying entity 1800 via the terminal device 1810. The individual 62 can maintain several aliases in the identity database. This type of architecture can enable the individual 62 to use, for example, a specified alias (e.g., an alias associated with a specified e-mail address and/or mailing address) when transacting with an unknown vendor (e.g., an unknown relying entity) and another alias (e.g., an alias with a different email address and/or different mailing address) when transacting with a trusted vendor (e.g., a trusted/known relying entity). In this way, for example, the individual can prevent, or substantially prevent, possible spam from the unknown vendor from reaching, for example, a specified (e.g., a preferred) email address, which may be shared only with trusted vendors.

[1173] FIG. 19 is a schematic block diagram that illustrates an information provider 1930 in communication with multiple information sources 1950, according to an embodiment. The information sources 1950 include information sources SEi through SEw- The information sources 1950 can include information associated with (e.g., pertaining to) an individual 72. The information sources 1950 can be, for example, a credit card company database, a government public records database, etc.

[1174] In some embodiments, the information provider 1930 can be configured to receive a request for confidential information associated with the individual 72. The request can be defined by, for example, a relying entity 1900. If one or more of the information sources 1950 can fulfill the request for the confidential information (referred to as potential information sources 1950), the information provider 1930 can be configured to present the potential information sources 1950 to the individual 72 via the terminal device 1910. The eligible information sources 1950 can be provided in response to the request for the confidential information. The terminal device 1910 can be configured so that the individual 72 can select one or more of the potential information sources 1950 via the terminal device 1910 only after an authentication operation based on a credential 70. In response to the selection, the request for the confidential information can be forwarded by the information provider 1930 to the selected information source 1950. This request may contain authentication information sufficient to demonstrate the authorization of the individual to release the information. The selected information source 1950 can be configured to fulfill the request for the confidential information by sending the confidential information directly to the relying entity 1900. In some embodiments, the confidential information can be sent to the relying entity 1900 via the information provider 1930. More details related to selection of an information provider are described in connection with FIGS. 1-12 above.

[1175] Some embodiments described herein relate to a computer storage product with a computer-readable medium (also can be referred to as a processor-readable medium) having instructions or computer code thereon for performing various computer-implemented operations. The media and computer code (also can be referred to as code) may be those designed and constructed for a specific purpose or purposes. Examples of computer-readable media include, but are not limited to: magnetic storage media such as hard disks, floppy disks, and magnetic tape; optical storage media such as Compact Disc/Digital Video Discs (CD/DVDs), Compact Disc-Read Only Memories (CD-ROMs), and holographic devices; magneto-optical storage media such as optical disks; carrier wave processing systems; and hardware devices that are specially configured to store and execute program code, such as Application-Specific Integrated Circuits (ASICs), Programmable Logic Devices (PLDs), and Read-Only Memory (ROM) and Random- Access Memory devices. Examples of computer code include, but are not limited to, micro-code or micro-instructions, machine instructions, such as produced by a compiler, code used to produce a web service, and files containing higher-level instructions that are executed by a computer using an interpreter. For example, embodiments may be implemented using Java, C++, or other programming languages (e.g., object-oriented programming languages) and development tools. Additional examples of computer code include, but are not limited to, control signals, encrypted code, and compressed code.

[1176] While various embodiments have been described above, it should be understood that they have been presented by way of example only, not limitation, and various changes in form and details may be made. Any portion of the apparatus and/or methods described herein may be combined in any combination, except mutually exclusive combinations. The embodiments described herein can include various combinations and/or sub-combinations of the functions, components and/or features of the different embodiments described. For example, in some embodiments, a request can be approved (or can require approval) by multiple subject entities. In some embodiments, a portion of confidential information can be sent to multiple relying entities in response to a request for confidential information.

Claims

What is claimed is:

1. A processor-readable medium storing code representing instructions that when executed by a processor cause the processor to: define a domain of confidential information associated with a subject entity based on a confidential information category selected from a plurality of confidential information categories by a relying entity; provide to the relying entity a set of predefined queries associated with the domain of confidential information; and define at least a portion of a request for confidential information from the domain of confidential information based on at least one predefined query selected from the set of predefined queries by the relying entity.

2. The processor-readable medium of claim 1 , wherein at least a portion of the plurality of confidential information categories are hierarchically related.

3. The processor-readable medium of claim 1 , wherein the at least one predefined query includes a first predefined query associated with a first privacy level, the request is defined based on a second predefined query associated with a second privacy level different than the first privacy level.

4. The processor-readable medium of claim 1, further storing code representing instructions that when executed by a processor cause the processor to: define a response to the request based on a preference defined by the subject entity.

5. The processor-readable medium of claim 1, further storing code representing instructions that when executed by a processor cause the processor to: define a response to the request; and send the response to the request to the subject entity; and receive approval of the response from the subject entity.

6. The processor-readable medium of claim 1, further storing code representing instructions that when executed by a processor cause the processor to: define a response to the request; and send the response to the request to the subject entity; and trigger a negotiation of the response based on at least a portion of the response being disapproved by the subject entity.

7. The processor-readable medium of claim 1, wherein at least a portion of the domain of confidential information has been updated based on an update policy defined by the subject entity.

8. The processor-readable medium of claim 1, wherein the at least one predefined query is associated with a privacy level, the processor-readable medium further storing code representing instructions that when executed by a processor cause the processor to: define a response to the request based on a comparison of the privacy level with a privacy level threshold defined by the subject entity.

9. The processor-readable medium of claim 1, further storing code representing instructions that when executed by a processor cause the processor to: receive a response to the request from the subject entity; and send at least a portion of the confidential information from the domain of confidential information to the relying entity based on the response.

10. The processor-readable medium of claim 1, wherein the set of predefined queries is selected from a plurality of predefined queries based on at least one of a trust-level value or an entity-type value associated with the relying entity.

11. The processor-readable medium of claim 1, further storing code representing instructions that when executed by a processor cause the processor to: authenticate an identity of the subject entity; and authenticate an identity of the relying entity.

12. The processor-readable medium of claim 1 , wherein the request is defined based on a customized query defined by the relying entity.

13. The processor-readable medium of claim 1 , wherein the confidential information includes at least one of financial information, medical information, or personal information.

14. An apparatus, comprising: a memory configured to store a trust-level value and an entity-type value associated with a relying entity; and a processor configured to determine, based on the trust-level value and the entity-type value, that the relying entity has authorization to request confidential information from a domain of confidential information, the domain of confidential information being associated with a subject entity, the processor configured to define at least a portion of a request for the confidential information based on a predefined query selected by the relying entity from a set of predefined queries, the set of predefined queries being related to the domain of confidential information.

15. The apparatus of claim 14, wherein the predefined query is included in the set of predefined queries based on content included in the domain of confidential information.

16. The apparatus of claim 14, wherein the processor is configured to send the request to the subject entity and configured to receive an indicator from the subject entity that the predefined query has been denied.

17. The apparatus of claim 14, wherein the predefined query is a first predefined query, the defining includes defining the request based on a second predefined query selected by the relying entity from the set of predefined queries, the memory is configured to store an indicator from the subject entity that the second predefined query has been denied; and the processor is configured to send to the relying entity a response to the first predefined queiy based on the confidential information.

18. The apparatus of claim 14, wherein the predefined query is a first predefined query, the defining includes defining the request based on a second predefined query selected by the relying entity from the set of predefined queries, the second predefined query is associated with the domain of confidential information.

19. The apparatus of claim 14, wherein the processor is configured to send the request to the subject entity and configured to send an indicator to the relying entity in response to the predefined query being denied by the subject entity.

20. The apparatus of claim 14, wherein the determining includes determining based on a confidential information category selected by the relying entity.

21. The apparatus of claim 14, wherein each predefined query from the set of predefined queries is ordered based on a privacy level.

22. The apparatus of claim 14, wherein the defining is based on an identity of the subject entity.

23. The apparatus of claim 14, wherein the set of predefined queries are included in a request template.

24. A method, comprising: receiving a response policy from a subject entity; providing a plurality of predefined queries associated with a domain of confidential information to a relying entity based on the response policy, the domain of confidential information being associated with the subject entity; and defining at least a portion of a request for confidential information from the domain of confidential information based on a predefined query when the predefined query is selected from the plurality of predefined queries by the relying entity.

25. The method of claim 24, further comprising: triggering an information provider to send at least a portion of the confidential information from the domain of confidential information, the information provider being selected by the subject entity.

26. The method of claim 24, wherein the providing includes providing based on at least one of a trust-level value or an entity-type value associated with the relying entity.

27. A method, comprising: defining a request for confidential information from a domain of confidential information based on an input from a relying entity, the domain of confidential information being associated with a subject entity; defining a response to the request at an information provider; and sending the response to the relying entity when the response has been approved by the subject entity.

28. The method of claim 27, further comprising: receiving an indicator that the subject entity has disapproved of at least a portion of the response; and modifying the response in response to the indicator.

29. The method of claim 27, wherein the domain of confidential information is defined based on a selection by the relying entity.

30. The method of claim 27, wherein the response is a first response, the method further comprising: receiving an update policy defined by the subject entity; sending an update request to at least one of the subject entity or the relying party based on the update policy; receiving a second response different from the first response in response to the update policy; and modifying at least a portion of the domain of confidential information based on the second response.

31. The method of claim 27, wherein the response is a first response, the method further comprising: receiving an update policy defined by the subject entity; and sending to a subject entity a request for authorization to transmit an update request to the relying party based on the update policy.

32. A method, comprising: defining a proposed response to a predefined query selected by a relying entity, the proposed response being defined based on confidential information associated with an individual; authenticating an identity of the individual; and sending the proposed response to the relying entity in response to the proposed response being approved by the individual and based on the authenticating.

33. The method of claim 32, wherein the proposed response is defined based on a response policy associated with the individual.

34. The method of claim 32, wherein the authenticating includes authenticating based on a credential-owner authentication information associated with the individual

35. The method of claim 32, further comprising: authenticating a credential associated with the individual based on credential-issuer validation information associated with the credential.