Patent Application
20120254320
Mechanisms are available that enable a user to share personal information that is native to one network-accessible service with one or more data consumers. A data consumer refers to any endpoint (such as another service) that receives and uses the personal information for any reason. For example, suppose that a user maintains personal information at plural social networking services. In certain cases, a user can set up two or more social networking services to make their information available to any data consumer. To do so, the user separately accesses and configures the social networking services, e.g., by instructing each social networking service to make its personal information available to the data consumer. In general, the sharing of information in the above-described environment is managed in a fractured and local manner. Further, each service uses a different identifier (such as a login ID) to refer to a particular user.
Healthcare-related services operate in a similar manner. Consider the case of a healthcare-related service that allows a user to maintain a repository of personal healthcare records. Different applications may work in conjunction with this type of healthcare-related service. Some of these applications may allow a user to share his or her personal healthcare records with healthcare professionals. But, again, this manner of sharing is fractured and application-specific. As such, if the user wishes to enable two applications to share personal information with health professionals, the user is expected to separately configure both applications in an appropriate manner.
While useful, the above-described approach to sharing information is not without its shortcomings, to be set forth in the Detailed Discussion below.
An information management system is described herein which maintains collected information that pertains to users, received from one or more data sources. The information management system also maintains a store of consent information. The consent information describes, for each user, at least one permission rule (established by the user) which enables at least one data consumer to access at least part of the collected information. Upon the occurrence of a triggering event, an information distribution module operates by distributing identified part(s) of the collected information to appropriate data consumer(s), as governed by the consent information. In this manner of operation, the consent information functions as global metadata which, from a centralized platform, governs the dissemination of the collected information to any data consumer in application-agnostic manner.
According to one illustrative implementation, the collected information corresponds to healthcare-related information. An illustrative data consumer may correspond to a doctor, clinic, hospital, etc.
According to another illustrative aspect, the information management system includes an administrative module which establishes a master identifier for each user. That master identifier may be associated with one or more subordinate identifiers. Further, in some implementations, the master identifier may pertain to an identifier that has already been established by a service other than the information management system.
According to another illustrative aspect, the consent information defines one or more of: a nature of the collected information which a data consumer is entitled to access; a data source from which a data consumer is entitled to access the collected information; the identities of the data consumer(s) that are entitled to access the collected information; a temporal condition pertaining to when a data consumer is permitted to receive the collected information; an indication of whether one or more providers of respective services are permitted to send messages to a user; and an indication of whether one or more other users are permitted to send messages to the user, etc.
According to one illustrative case, the triggering event that invokes the distribution of information corresponds to a request, by a data consumer, to access at least part of the collected information. According to another illustrative case, the triggering event is a decision to push at least part of the collected information to the data consumer, independent of a request by the data consumer.
According to another illustrative aspect, the information management system can include searching functionality that allows inquiring entities to contact users without revealing sensitive information pertaining to the users to the inquiring entities. In one implementation, the search functionality operates by: receiving a search request from an inquiring entity to locate users who meet a specified search condition; performing a search within user-related information in response to the search request, to provide original search results that identify at least one candidate user; obfuscating sensitive information in the original search results that identifies said at least one candidate user, to provide obfuscated search results; and sending the obfuscated search results to the inquiring entity. The inquiring entity may analyze the obfuscated search results and identify at least one target user to send a message to (without gaining knowledge of the actual identities of the target user(s)). At this juncture, the searching functionality operates by receiving a request from the inquiring entity to send a message to the target user(s), and then sending a message to the target user(s).
The above approach can be manifested in various types of systems, components, methods, computer readable media, data structures, articles of manufacture, and so on.
This Summary is provided to introduce a selection of concepts in a simplified form; these concepts are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
The same numbers are used throughout the disclosure and figures to reference like components and features. Series 100 numbers refer to features originally found in
This disclosure is organized as follows. Section A describes an illustrative information management system for disseminating information to data consumers, as governed by global consent information. Section B describes illustrative methods which explain the operation of the information management system of Section A. Section C describes illustrative processing functionality that can be used to implement any aspect of the features described in Sections A and B.
As a preliminary matter, some of the figures describe concepts in the context of one or more structural components, variously referred to as functionality, modules, features, elements, etc. The various components shown in the figures can be implemented in any manner by any physical and tangible mechanisms (for instance, by software, hardware, firmware, etc., and/or any combination thereof). In one case, the illustrated separation of various components in the figures into distinct units may reflect the use of corresponding distinct physical and tangible components in an actual implementation. Alternatively, or in addition, any single component illustrated in the figures may be implemented by plural actual physical components. Alternatively, or in addition, the depiction of any two or more separate components in the figures may reflect different functions performed by a single actual physical component.
Other figures describe the concepts in flowchart form. In this form, certain operations are described as constituting distinct blocks performed in a certain order. Such implementations are illustrative and non-limiting. Certain blocks described herein can be grouped together and performed in a single operation, certain blocks can be broken apart into plural component blocks, and certain blocks can be performed in an order that differs from that which is illustrated herein (including a parallel manner of performing the blocks). The blocks shown in the flowcharts can be implemented in any manner by any physical and tangible mechanisms (for instance, by software, hardware, firmware, etc., and/or any combination thereof).
As to terminology, the phrase “configured to” encompasses any way that any kind of physical and tangible functionality can be constructed to perform an identified operation. The functionality can be configured to perform an operation using, for instance, software, hardware, firmware, etc., and/or any combination thereof.
The term “logic” encompasses any physical and tangible functionality for performing a task. For instance, each operation illustrated in the flowcharts corresponds to a logic component for performing that operation. An operation can be performed using, for instance, software, hardware, firmware, etc., and/or any combination thereof. When implemented by a computing system, a logic component represents an electrical component that is a physical part of the computing system, however implemented.
The following explanation may identify one or more features as “optional.” This type of statement is not to be interpreted as an exhaustive indication of features that may be considered optional; that is, other features can be considered as optional, although not expressly identified in the text. Similarly, the explanation may indicate that one or more features can be implemented in the plural (that is, by providing more than one of the features). This statement is not be interpreted as an exhaustive indication of features that can be duplicated. Finally, the terms “exemplary” or “illustrative” refer to one implementation among potentially many implementations.
A. Illustrative Systems
In the healthcare-related environment, the data sources 104 can pertain to any entities which provide healthcare-related information pertaining to users. For example, the data sources 104 can represent information entered by any individual (e.g., doctors, nurses, administrative personnel, laboratory personnel, imaging specialists, etc.) in any environment (e.g., hospital settings, doctor office settings, clinic settings, laboratory settings, etc.). Or users may themselves enter the information. The data consumers 106 can pertain to any entities which make use of the healthcare-related information for any reason. For example, the data consumers 106 can include any individual (e.g., doctors, nurses, administrative personnel, laboratory personnel, imaging specialists, fellow-users, etc.) in any environment (e.g., hospital settings, doctor office settings, clinic settings, laboratory settings, etc.). Further, any data consumer may also function in the role of a data source, and vice versa. In some cases, a data consumer may be associated with a local data consumer system, such a computer system that serves a hospital.
The information management system 102 itself can include (or can be conceptualized as including) a number of modules that serve different functional roles. These modules can be provided at a single central site or can be distributed among plural sites at different respective locations. In one case, the information management system 102 is administered by a single entity. In another case, the information management system 102 is administered by two or more entities.
The information management system 102 can include one or more interfaces, i.e., interface(s) 108. The interface(s) 108 include functionality which allows external entities to interact with the information management system 102. Such external entities include the data sources 104, the data consumers 106, and one or more user devices 110 that are operated by users. The users may represent the individuals who are associated with the healthcare-related information maintained and distributed by the information management system 102. For instance, in a hospital setting, the users correspond to respective patients or former patients.
The information management system 102 further includes a data collection module 112. The data collection module 112 includes functionality for receiving healthcare-related information from the data sources 104 and storing the information in one or more data stores, referred to in the singular as data store 114. The information that is collected is referred to herein as collected information. The data collection module 112 can use any technique to collect healthcare-related information from the data sources 104, including a push technique (in which a data source independently forwards healthcare-related information to the information management system 102), a pull technique (in which the data collection module 112 actively requests the healthcare-related information from a data source), or any combination thereof. In the pull technique, the data collection module 112 can perform its polling on a periodic basis and/or in response to any triggering event or events.
The information management system 102 also includes a consent management module 116. The consent management module 116 includes functionality for receiving and storing consent information in one or more data stores, referred to in the singular as data store 118. For each user, the consent information describes one or more permission rules, which may be established by the user and/or some other source, which govern the dissemination of that user's collected information to particular data consumers 106.
The information management system 102 also includes an information distribution module 120. The information distribution module 120 distributes parts of the collected information (maintained in the data store 114) to the data consumers 106, as governed by the consent information (maintained in the data store 118).
Consider the operation of the information distribution module 120 for the case of a representative user. When a triggering event is received, the information distribution module 120 consults the consent information for that user to determine whether one or more data consumers 106 are entitled to receive a part of the user's collected information. In one case, the triggering event may correspond to an express request by one of the data consumers 106 to receive part of the collected information. In that case, the information distribution module 120 can consult the consent information for the user to determine whether it is appropriate to honor the request of the data consumer. In another case, the triggering event may correspond to an express instruction by a user to provide part of the collected information to one or more data consumers.
In another case, the triggering event may correspond to an independent decision by the information management system 102 to forward part of the collected information to one or more data consumers. For example, in one scenario, the user may have established a permission rule, as part of the consent information, which instructs the information management system 102 to automatically forward part of the collected information to the data consumer(s) upon the occurrence of certain triggering events. One such triggering event may correspond to receipt of a new item of collected information in the data store 114. In another case, a user may establish a permission rule which instructs the information distribution module 120 to determine, on a periodic basis or otherwise, whether there is any new collected information in the data store 114; if so, the permission rule can instruct the information distribution module 120 to forward that information to the data consumer(s).
Generally, the types of triggering events described above are representative, not exhaustive; that is, other implementations can incorporate the use of other types of triggering events. In any case, the information distribution module 120 can perform the above-described decision process on an ongoing basis with respect to the accounts of all users.
The information distribution module 120 can employ various mechanisms to demonstrate the authenticity of the collected information that it sends to the data consumers 106. For example, the information distribution module 120 can append a signature-bearing certificate to each message that it sends to a data consumer. That certificate, signed by a trusted authority, provides some measure of assurance to the data consumer that the received information originates from the information management system 102, and not some malicious entity which is masquerading as the information management system 102.
The information management system 102 can also include an administration module 122. Among other tasks, the administration module 122 can maintain user information regarding users who have accounts with the information management system 102. The administration module 122 can store this user information in one or more data stores, referred to in the singular below as data store 124. The user information can include user identifiers associated with the accounts. Further information regarding the user identifiers will be set forth below in the context of
In one implementation, the components of the information management system 102 shown in
To cite one example, the data consumer 128 may correspond to a computer system of a hospital which serves a population of patients. The provisioning module 126 can transfer a sub-corpus of the collected information maintained in the data store 114 to the data consumer 128 that pertains to the patients. The provisioning module 126 can also transfer code that implements a subset of services to the data consumer 128. Those services allow healthcare professionals at the hospital to access the sub-corpus of collected information without accessing the remote instance of the information management system 102. For example, the local services can implement any aspect of the interfaces 108, the information distribution module 120, the consent management module 116, the administration module 122, and so on. For example, a local instance of the information distribution module 120 can receive a request for patient data by a local healthcare professional. A local instance of the consent management module 116 can then determine whether the healthcare professional is entitled to receive the patient data. If so, the local instance of the information distribution module 120 can allow the healthcare professional to access the patient data. The remote instance of the information management system 102 can periodically send updated collected information to the local instance of the information management system 102 so that the local instance of this information remains current.
To facilitate and simplify explanation, it will henceforth be assumed that the services and collected information provided by the information management system 102 are provided at a centralized platform. However, any operations that can be performed by the centralized platform can alternatively, or in addition, be performed by a local instance of the information management system 102. The general term “information management system” 102 encompasses any instance(s) of the functionality described herein, whether implemented at a remote centralized platform, a localized instance, or both.
In addition, the functions performed by the consent management module 116 can be performed in different ways. In one case, the consent management module 116 comprises a centralized platform which determines whether a data consumer is entitled to receive the information that it has requested. In this scenario, a data consumer which makes a request is expected to provide sufficient information which identifies it to the consent management module 116.
In another case, the consent management module 116 can implement its functions using a claims-based authentication paradigm. In this approach, when the data consumer makes a request, a verifier module (not shown) can evaluate whether the data consumer is entitled to receive the requested information. For example, the verifier module can receive identifying information from the data consumer to determine whether the data consumer is who they claim to be; in addition, the verifier module can consult the rules in the consent information to determine whether the data consumer is entitled to receive the collected information that it has requested. If the data consumer passes these tests, the verifier module can issue a security token to the data consumer which indicates that the data consumer is entitled to receive the requested information. A separate consent management application module (not shown) can then authorize the data consumer to access the requested information on the basis of the security token.
One potential advantage of the claims-based approach is that it can reduce the amount of private information that a data consumer is expected to provide to the consent management application module. This is because another entity, the verifier module, performs the verification. The security token provided to the consent management application module indicates whether the data consumer is entitled to receive the requested information, without otherwise revealing additional information regarding the data consumer. This approach also provides flexibility in the verification of requests by data consumers. For instance, a consent management application module can potentially outsource verification tasks to plural verifier modules that provide security tokens using different respective authentication paradigms.
In another implementation, the verifier module can also issue security tokens that confer rights to particular types of entities. This may be referred to as entity-based authentication. In this approach, for instance, the verifier module can issue a security token to a data consumer which indicates that the data consumer is a particular type of entity, such as a researcher, or a surgeon within a hospital, etc. The consent management application module can then grant the data consumer certain rights based that are commensurate with the information specified in the security token.
To facilitate and simplify explanation, it will henceforth be assumed that the consent management module 116 is implemented by a unified platform that performs all security checking. However, any operations that can be performed by the unified platform can alternatively, or in addition, be performed by in the above-described distributed claims-based manner (e.g., using one or more verifier modules in conjunction with a consent management application module), or in any other manner. In other words, reference to the general term “consent management module” 116 is considered to encompass at least the implementations described above, including the distributed claims-based implementation.
Advancing to
(a) What can be accessed? A permission rule can describe the nature of the collected information that the data consumer(s) are entitled to access. For example, a permission rule can describe the general type of collected information that the data consumer(s) are authorized to access. For instance, such a permission rule can specify that the data consumer(s) are permitted to access all lab records, or all lab records pertaining to diabetes tests, and so on. Other implementations can use any criterion or criteria to specify the subject matter to which the data consumer(s) are entitled, such as by specifying keywords that pertain to the subject matter, etc.
(b) From where can it be accessed? In addition, or alternatively, a permission rule can describe one or more data sources from which the data consumer(s) are entitled to access collected information. For instance, such a permission rule can specify that the data consumer(s) are entitled to access all lab results received from lab XYZ.
(c) Who can access it? A permission rule can describe the particular data consumer(s) who are entitled to access the collected information. This permission component can be expressed in any level of specificity based on any filtering factor or factors. For instance, a broad permission rule may specify that all data consumers that have been previously registered by the user are entitled to receive the user's collected information or some part thereof. Another permission rule can more selectively identify certain data consumers who are entitled to access some parts of the collected information, but not other parts. These data consumers can be identified by general class (e.g., by identifying all doctors associated with hospital XYZ), or individually (e.g., by identifying individual doctors).
As a preliminary to writing such permission rules, in one implementation, each user may specify a group of data consumers that are entitled to access at least some of the collected information. The user can provide any identifying information for this purpose, such as the addresses of the data consumers 106 (e.g., the IP addresses), etc. In addition, the registration process can involve exchanging appropriate keys between the information management system 102 and the data consumers 106. The keys enable the information management system 102 and the data consumers 106 to exchange data in encrypted form.
(d) When can it be accessed? A permission rule can describe when the data consumer(s) are entitled to access the collected information. In other words, this type of permission rule specifies the triggering event which prompts the information distribution module 120 to send the collected information to the data consumer(s), or otherwise makes the collected information available to the data consumer(s). For example, one permission rule can instruct the information distribution module 120 to send at least part of the collected information to the data consumer(s) when it is newly added to the data store 114. Another permission rule can instruct the information distribution module 120 to send the collected information to the data consumer(s) when they expressly request that information, and so on.
(e) What kinds of searches are authorized? As will be described below in the context of
The above-described types of permission rules and components are illustrative, not exhaustive; other implementations can adopt the use of other types of permission rules and components. For example, another implementation can accommodate a permission rule which places restrictions on the data sources 104 which are permitted to forward information to the information management system 102. In the implementation described above, by contrast, the information management system 102 can receive information in unrestricted fashion from any registered entity (and/or, potentially, any unregistered entity) that is able to add information to a user's account.
The consent management module 116 can solicit the consent information from a user in different ways. In one case, the consent management module 116 can provide a structured user interface presentation by which the user can express the various permission components described above. Alternatively, or in addition, the consent management module 116 can permit the user to enter permission rules in a more freeform manner. The consent management module 116 can then parse the permission rules to extract the permission components described above.
In the example of
From a higher level standpoint, the consent information constitutes metadata that is associated with the collected information in the data store 114. The metadata is considered global metadata because it transcends and is agnostic to the particulars of any data source and any data consuming environment. For example, a rule, established by a user, may indicate that any dermatologist can access the user's medical records. This permission rule applies regardless of the system that any individual dermatologist uses to receive the medical records. And this permission rule is defined in the context of the platform provided by the information management system 102, not the functionality provided by originating data sources or downstream consumers.
While this description is framed primarily in the representative context of a healthcare-related domain, as said above, the information management system 102 can be applied to any data collection and dissemination environment. More generally stated, the information management system 102 can be used to collect information from diverse sources connected to a wide area network, such as the Internet. The information management system 102 uses the global consent metadata to control the manner in which data consumers of any type are permitted to access this information, rather than allowing data sources and data consumers to dictate the permissions in a separate and fractured manner. This aspect of the information management system 102 makes it easier for users to control the flow of personal information across diverse systems and platforms. It is also potentially more robust than a fractured approach, as the user is less apt to make errors in generating permission rules when that task is consolidated and generalized in the manner described.
Advancing to
As will be set forth more fully in Section B, in one case, the message that the information distribution module 120 sends to a particular data consumer can specify the master identifier of a particular user, or at least one subordinate identifier, or a combination of the master identifier and at least one subordinate identifier. If only the master identifier is provided, the recipient data consumer can translate the master identifier to its own local subordinate identifier for the user (if it, in fact, uses such a local identifier). A data consumer can request a user's collected information from the information management system 102 by specifying the master identifier, or at least one subordinate identifier, or a combination of at least one subordinate identifier and the master identifier.
In a similar fashion, the data collection module 112 can receive information that is accompanied by a master identifier, or at least one subordinate identifier, or a combination of at least one subordinate identifier and the master identifier. In the case in which only a subordinate identifier is provided, the data collection module 112 can translate any local subordinate identifier to its corresponding master identifier so that the data collection module 112 can store the received information in the appropriate account.
A particular data consumer (or data source) may wish to use a subordinate identifier, either alone or in combination with a master identifier, for auditing purposes (as well as other possible purposes). For example, in the above-described multi-department clinic, the use of the subordinate identifiers allows the data consumer to maintain appropriate records regarding the requests that originate from different departments.
In one case, the administration module 122 can assign a new master identifier to each user. In another case, the administration module 122 can allow a user to choose his or her own master identifier. In this situation, a user can opt to use a pre-existing identifier that has already been assigned by another system, such as a social networking service. In this manner, the user can use the same master identifier to interact with two or more services, including the information management system 102.
The searching functionality 402 includes an interface module 404 for interacting with one or more inquiring entities. For example, an inquiring entity can correspond to a researcher which seeks access to user-related information for a research-related purpose. In another case, an inquiring entity can correspond to a provider. The provider may correspond to an individual or organization or some other entity that wishes to provide a message to one or more target users with the intent of providing any kind of service to the target users. For example, a company that provides diabetes management products may wish to sell such products to users who have diabetes. In another case, a drug manufacturer or government agency may wish to provide an alert to those users to who take a certain medication, and so on. In another case, an inquiring entity can correspond to another user who maintains an account with the information management system 102. For example, another user may wish to find other users who share the same condition, with the possible intent of establishing a conversation regarding the condition. Still other types of inquiring entities can interact with the searching functionality 402.
As a first step, the interface module 404 receives a search request from an inquiring entity. The search request can include a search condition (e.g., one or more search terms), specified in any manner. These search conditions are chosen to target particular users. For example, a provider who wishes to identify patients that suffer from high blood pressure might specify the search term “high blood pressure.” The interface module 404 forwards the search request to a search module 406. In another case, the provider may specify “Connecticut” to identify patients in that state, and so on.
The search module 406 includes functionality for searching through any user-related information to identify users who match the search condition. In the case specified above, the search module 406 can identify users that suffer from high blood pressure. Such a fact can be expressed, for instance, in the collected information pertaining to the users (e.g., in the medical records of those users) and/or in the user profile information of those users, etc. The search module 406 can use any search functionality for performing this search, such as by using an index that identifies the correlation between search terms and users. The outcome of the searching process is referred to herein as original search results. In one implementation, the search module 406 forwards the original search results to an obfuscation module 408.
The obfuscation module 408 removes or otherwise obscures sensitive information within the search results. The obfuscation process makes it impossible or unlikely that a recipient can discover the sensitive information. One field of the sensitive information that is obfuscated is any information that expresses the identities of the users identified in the original search results. In one case, the obfuscation module 408 can obfuscate the sensitive information by replacing it with random or seemingly random information, e.g., by taking a hash of the sensitive information to produce random-looking information. As a result of its processing, the obfuscation module 408 produces obfuscated search results. The obfuscated search results identify one or more candidate users, but in concealed form.
In one implementation, the interface module 404 sends the obfuscated search results to the inquiring entity. The inquiring entity can examine the obfuscated search results and then optionally decide to send a message to any one or more target users selected from among the candidate users. For example, demographic information in the obfuscated search results may reveal that a subset of the users who suffer from high blood pressure are located in the Northeast part of the United States. If a provider is interested in sending a promotional offer to these users, the provider can select these users as the target users. The inquiring entity can then send a request to the interface module 404, which instructs the searching functionality 402 to send a message to the target user(s). The inquiring entity can also specify the message to be sent.
Finally, a user contact module 410 performs the task of forwarding a message to the target users. If the target users do not wish to receive such messages in the future, they can change appropriate preference rules in their consent information. The user contact module 410 can send messages to the target users in any manner, such as by posting messages to the accounts of the users (which they can access when logged onto the information management system 102), by sending Email messages to the target users, by sending instant messages to the target users, etc.
In another manner of operation, the inquiring entity can instruct the searching functionality 402 to send a message to any target user who meets the search request, without first receiving obfuscated search results. For example, a provider can instruct the searching functionality 402 to send a message to all users who have high blood pressure, without being given the opportunity to examine and select from the list of candidate users that meet this criterion.
In contrast, a researcher can receive the obfuscated search results and perform analysis on the obfuscated search results. The researcher will typically forego the step of contacting the users who are associated with the obfuscated search results.
Advancing to
A user can operate a user device 506 to interact with the remote computing functionality 504 via a communication conduit 508. The user device 506 can comprise any type of computing device, such as a personal computer, a computer workstation, a laptop computer, a game console device, a set-top box device, a personal digital assistant, a mobile telephone device, an electronic book reader device, and so on. In one case, the user can interact with the remote computing functionality 504 using browsing functionality 510 which is installed on the user device 506.
The communication conduit 508 can comprise any type of coupling mechanism, including a local area network, a wide area network (e.g., the Internet), a point-to-point connection, and so on. The communication conduit 508 can be physically implemented using any combination of hardwired links, wireless links, routers, gateways, name servers, etc., as governed by any protocol or combination of protocols.
Other entities can also communicate with the remote computing functionality 504 via the communication conduit 508, including the data sources 104, the data consumers 106, and service providers 512. Each of these entities can be implemented by any type of computing functionality, such as any type of computing functionality described above with respect to the remote computing functionality 504 and/or the user device 506. As described above, any data consumer can optionally implement a local instance of any sub-corpus of collected information and/or services provided by the remote information management system 102.
B. Illustrative Processes
Starting with
Assume that the information that is provided specifies only a subordinate identifier. If so, in block 704, the data collection module 112 can access the user information in store 124, using the administration module 122, to thereby determine a master identifier that corresponds to the provided subordinate identifier.
In block 706, the data collection module 112 stores the collected information in the data store 114. The data collection module 112 can store the collected information in association with the master identifier, or at least one subordinate identifier, or a combination of the master identifier and at least one subordinate identifier.
Assume that the request that is received specifies only a subordinate identifier. If so, in block 1004, the information distribution module 120 can access the user information in store 124, using the administration module 122, to thereby determine a master identifier that corresponds to the provided subordinate identifier.
In block 1006, the information distribution module 120 consults the consent information for the user to determine whether it is appropriate to send the collected information to the data consumer, e.g., by using the master identifier as at least part of a key to identify the appropriate consent information. If so, in block 1008, the information distribution module 120 accesses the collected information (again using the master identifier as at least part of a key) and sends the collected information to the data consumer. As explained above, the information distribution module 120 can identify the collected information that it sends to the data consumer using a master identifier, or a subordinate identifier, or a combination of the master identifier and the subordinate identifier.
In block 1110, the searching functionality 402 optionally receives a request from the inquiring entity to send a message to one or more target users. The inquiring entity can select the target user(s) from the candidate users identified in the obfuscated search results. In block 1112, the searching functionality 402 can send a message to the target user(s). The dashed line in
As a general point, the information management system 102 can provide appropriate safeguards to maintain the privacy of the users' personal information. Such safeguards can include (but are not limited to) encrypting the collected information that is maintained in the data store 114, encrypting the messages that are sent to the data consumers 106, removing sensitive information from the search results provided to providers and other users, and so on. In addition, the users may create permission rules that expressly define what information is shared with external entities. In the extreme, any user may, for any reason, completely disable information sharing, so that the information distribution module 120 will not send any information to any data consumer.
C. Representative Processing Functionality
The processing functionality 1300 can include volatile and non-volatile memory, such as RAM 1302 and ROM 1304, as well as one or more processing devices 1306 (e.g., one or more CPUs, and/or one or more GPUs, etc.). The processing functionality 1300 also optionally includes various media devices 1308, such as a hard disk module, an optical disk module, and so forth. The processing functionality 1300 can perform various operations identified above when the processing device(s) 1306 executes instructions that are maintained by memory (e.g., RAM 1302, ROM 1304, or elsewhere).
More generally, instructions and other information can be stored on any computer readable medium 1310, including, but not limited to, static memory storage devices, magnetic storage devices, optical storage devices, and so on. The term computer readable medium also encompasses plural storage devices. In all cases, the computer readable medium 1310 represents some form of physical and tangible entity.
The processing functionality 1300 also includes an input/output module 1312 for receiving various inputs (via input modules 1314), and for providing various outputs (via output modules). One particular output mechanism may include a presentation module 1316 and an associated graphical user interface (GUI) 1318. The processing functionality 1300 can also include one or more network interfaces 1320 for exchanging data with other devices via one or more communication conduits 1322. One or more communication buses 1324 communicatively couple the above-described components together.
The communication conduit(s) 1322 can be implemented in any manner, e.g., by a local area network, a wide area network (e.g., the Internet), etc., or any combination thereof. The communication conduit(s) 1322 can include any combination of hardwired links, wireless links, routers, gateway functionality, name servers, etc., governed by any protocol or combination of protocols.
In closing, the description may have described various concepts in the context of illustrative challenges or problems. This manner of explication does not constitute an admission that others have appreciated and/or articulated the challenges or problems in the manner specified herein.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
