CN117099104A - Knowledge graph privacy management - Google Patents

Abstract

The techniques described herein protect the privacy of data stored in a knowledge graph ("graph") by enforcing a privacy policy when information is returned in response to a query or other attempt to extract information from the graph and/or extract information about the graph. In one aspect, unauthorized information is trimmed from the information output in response to a query. In other words, the privacy policy of the knowledge graph is implemented in the information extraction process. This is in contrast to other methods that attempt to enforce privacy policies during the information ingestion process or after the information is output from the graph through some other service level process. The privacy policy may be stored in a node of the graph.

Description

Knowledge graph privacy management

Background

Data privacy is an important issue for both users and organizations. Many business applications provide useful insight or services by analyzing information about actions taken by one or more users within an organization. For example, an application may help people prepare for a meeting by looking up documents or other objects that were recently used by the meeting participants. While the results may indeed help people prepare for the meeting, the results may also show which documents a small group of people (e.g., attendees) are using, even if the exact person using the document is not identified. Perceived privacy concerns caused by such services have led to many organizations not using these services. Users and organizations often lack the ability to control the use of personal and organizational information for the use of such services in a fine and efficient manner. Some challenges surrounding managing privacy controls are caused by how the organization information is stored in a graph.

For efficient retrieval and analysis, organization information may be stored in a knowledge graph (e.g., an information graph). The knowledge graph may contain multiple entities that have relationships to each other. An entity may be broadly defined as a named noun or named object. The entities may be organized by entity type. For exemplary purposes only, entity types may include personnel, locations, places, businesses, organizations, movie titles, books, songs, and so forth. There are many examples of entity types, and this list is intended as a non-exhaustive list of exemplary entity types. Relationships connect entities and form graph "edges". For example, an entity instance in a "document" entity type may be connected to a "people" entity type by a relationship "author". There may be multiple instances of an entity. For example, each person in a person entity type is an instance of a person entity. Entity types, relationships, and entity instances may be described as knowledge graph features. Current methods typically manage privacy issues in knowledge graphs during the input phase by first not adding private information to the knowledge graph. This approach may require the use of organization information to create a different graph for each application or to force all applications using the graph data to use the same privacy rules.

Disclosure of Invention

This summary is provided to introduce a selection of concepts in a simplified form that 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 as an aid in determining the scope of the claimed subject matter.

The techniques described herein protect the privacy of data stored in a knowledge graph ("graph") by enforcing a privacy policy when information is returned in response to a query or other attempt to extract information from the graph and/or extract information about the graph. The policy may be implemented for knowledge graph objects that include nodes and edges, as well as information about these objects (e.g., how many edges intersect the nodes). The privacy policy may manage the graph information itself as well as analysis of the graph information. An example of graph information may be the identity of one or more users accessing a document, which may be indicated by an edge or edge attribute in the graph. Analysis of the information about the graph may include how many users accessed the document, which may not be stored directly in the graph, but may be determined by analyzing the information in the graph (e.g., by counting edges). With the analysis information, a plurality of users can be provided without identifying the individual users themselves.

In one aspect, unauthorized information responsive to a query is pruned from the query response. In other words, the privacy policy of the knowledge graph is implemented in the information extraction process. This is in contrast to conventional approaches that attempt to implement privacy policies during the information ingestion process or through another service level process after the information is output from the graph.

The privacy policy may be stored in a node of the graph. The privacy policy may record privacy state information associated with one or more knowledge graph objects (e.g., edges, edge metadata, nodes, and node metadata). The privacy state may take the form of opt-in (i.e., access is allowed) or opt-out (i.e., access is denied). In one aspect, only opt-in information is stored and opt-out is selected as the default state. In another aspect, only opt-out information is stored and opt-in is the default state. Storing only one state or the other may save computer resources, including computer storage and lookup time (e.g., reduce latency).

The privacy policy may include a policy scope that identifies one or more knowledge graph objects to which the privacy state (e.g., opt-out) applies. The privacy policy collection system may allow a range of privacy states to be specified for an entire organization, a group of people within an organization, or individual users. The scope of the privacy policy specifies the users to which the policy applies. The privacy policy may be specified on a service-by-service basis. One service may have full access to the graph information while another service has limited access. Privacy policies may further differentiate the audience. This allows, for example, a user to access his or her own information while rejecting or restricting others from accessing the information. Similarly, information may be shared with members of a given group without giving access rights to outside group personnel.

The privacy policy enforcement system compares the information request and the context of the request with the applicable privacy policy. In one aspect, a query is submitted using a security token that can identify the audience of the query result as well as the service that initiated the query. Depending on the result of the comparison, all or a portion of the information responsive to the query may be provided. If a portion of the response information is protected by the privacy policy, that portion is omitted from the response and the portion of the information not protected by the privacy policy is output to the requesting entity.

Drawings

The technology described herein is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements, and in which:

FIG. 1 is a block diagram of an example operating environment suitable for embodiments of the present disclosure;

FIG. 2 is a diagram depicting an example computing architecture suitable for implementing aspects of the present disclosure;

FIG. 3 illustrates a knowledge graph in accordance with an aspect of the technology described herein;

FIG. 4 illustrates a knowledge graph with embedded privacy policies in accordance with an aspect of the technology described herein;

5-7 are flowcharts illustrating additional exemplary methods of managing privacy settings in accordance with one aspect of the technology described herein; and

FIG. 8 is a block diagram of an exemplary computing environment suitable for implementing aspects of the technology described herein.

Detailed Description

The various techniques described herein are set forth with sufficient specificity to meet statutory requirements. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors have contemplated that the claimed subject matter might also be embodied in other ways, to include different steps or combinations of steps similar to the ones described in this document, in conjunction with other present or future technologies. Furthermore, although the terms "step" and/or "block" may be used herein to connote different elements of methods employed, the terms should not be interpreted as implying any particular order among or between various steps herein disclosed unless and except when the order of individual steps is explicitly described.

The techniques described herein protect the privacy of data stored in a knowledge graph ("graph") by enforcing a privacy policy when information is returned in response to a query or other attempt to extract information from the graph and/or extract information about the graph. The policy may be implemented for knowledge graph objects that include nodes and edges, as well as information about these objects (e.g., how many edges intersect the nodes). The privacy policy may manage the graph information itself as well as analysis of the graph information. An example of graph information may be the identity of one or more users accessing a document, which may be indicated by an edge or edge attribute in the graph. Analysis of the information about the graph may include how many users accessed the document, which may not be stored directly in the graph, but may be determined by analyzing the information in the graph (e.g., by computing edges).

In one aspect, unauthorized information responsive to a query is pruned from the query response. In other words, the privacy policy of the knowledge graph is implemented in the information extraction process. This is in contrast to conventional approaches that attempt to implement privacy policies during the information ingestion process or through another service level process after the information is output from the graph.

Under conventional approaches, privacy policies may be enforced when information is entered (e.g., ingested) into a knowledge graph. In this case, information inconsistent with the privacy policy is not stored in the figure. Information considered private may be stored in a separate system but not in the graph itself. This approach has several drawbacks. First, each service accessing graph information associated with different privacy policies may require a different graph. In contrast, the techniques described herein allow different services to access a single knowledge graph while enforcing different privacy policies for different services. A single knowledge graph is used to represent a significant savings in computing resources.

A second advantage of the techniques described herein, compared to conventional approaches that implement privacy policies at the time of information ingestion, is the ability of a user to change privacy policies without loss of functionality. By storing all information in the knowledge graph, whether or not constrained by privacy policies, the information may later be used to provide access to services and/or functions that the user did not want or enable initially.

In some embodiments, the techniques described herein include three components. The first is a knowledge graph, which may be represented in any suitable architecture. The second is a privacy policy collection system. Third is a privacy policy enforcement system.

The privacy policy collection system provides an interface through which users can specify their privacy preferences. Preferences may be used to form a privacy profile for the user. The user profile may be stored outside the knowledge graph. Privacy preferences may be used to form user privacy policies. The privacy policy includes a scope to select an exit (or join) state and one or more objects (e.g., edges, edge metadata, nodes, and node metadata) to which the state applies. The privacy policy is stored for use by the privacy policy enforcement system. In one aspect, the privacy policy is stored in a managed knowledge graph. The privacy policy may be stored in a node of the graph as a user opts out of the record. In one aspect, only opt-in information is stored and opt-out is selected as the default state. In another aspect, only opt-out information is stored and opt-in is the default state. Storing only one state or the other may save computer resources, including computer storage and lookup time (e.g., reduce latency). As used herein, opt-out is any instruction that denies access to an object or information about an object. The use of the term "opt-out" does not necessarily mean that the system has a default opt-in state; however, the technique may be used with systems having default opt-in states. As used herein, opt-in is any instruction that allows access to an object or information about an object. The use of the term opt-in does not necessarily mean that the system has a default opt-out state.

The privacy policy collection system may allow a range of privacy states (e.g., opt-in or opt-out) to be specified for an entire organization, a group of people within an organization, or individual users. The scope of the privacy policy specifies the person to whom the policy applies. The privacy policy may be specified on a service-by-service basis. One service may have full access to the graph information while another service has limited access. Privacy policies may further differentiate between audience members. This allows, for example, a user to access his or her own information while rejecting or restricting others from accessing the information. Also, information may be shared with members of a given group without granting access to personnel outside the group.

The privacy policy enforcement system compares the information request and the context of the request with the applicable privacy policy. In one aspect, a query is submitted using a security token that can identify the audience of the query result as well as the service that initiated the query. Depending on the result of the comparison, all or a portion of the information responsive to the query may be provided. If a portion of the response information is protected by the privacy policy, that portion is omitted from the response and the portion of the information not protected by the privacy policy is output to the requesting entity.

Having briefly described an overview of aspects of the technology described herein, an exemplary operating environment in which aspects of the technology described herein may be implemented is described below in order to provide a general context for the various aspects.

Turning now to FIG. 1, a block diagram is provided that illustrates an example operating environment 100 in which aspects of the present disclosure may be employed. It should be understood that this and other arrangements described herein are presented by way of example only. Other arrangements and elements (e.g., machines, interfaces, functions, orders, and groupings of functions, etc.) can be used in addition to or instead of those shown, and some elements may be omitted entirely for clarity. Furthermore, many of the elements described herein are functional entities that may be implemented as discrete or distributed components or in combination with other components and in any suitable combination and location. The various functions described herein as being performed by one or more entities may be carried out by hardware, firmware, and/or software. For example, some functions may be performed by a processor executing instructions stored in a memory.

In addition to other components not shown, the example operating environment 100 includes a plurality of user devices, such as user devices 102a and 102 b-102 n; a plurality of data sources, such as data sources 104a and 104b through 104n; a server 106; and a network 110. Each of the components shown in fig. 1 may be implemented via any type of computing device, such as computing device 800 described in connection with fig. 8, for example. These components may communicate with each other via a network 110, which network 110 may include, but is not limited to, one or more Local Area Networks (LANs) and/or Wide Area Networks (WANs). In the exemplary embodiment, network 110 includes the Internet and/or a cellular network, as well as any of a variety of possible public and/or private networks.

The user devices 102a and 102 b-102 n may be client devices on the client side of the operating environment 100, while the server 106 may be on the server side of the operating environment 100. The user device may facilitate the generation of objects stored in the knowledge graph. For example, the user device may create and edit documents stored as nodes in the knowledge graph. Records of interactions, such as views, edits, may also be saved as edges in the knowledge graph. These devices may belong to many different users, and a single user may use multiple devices.

The server 106 may include server-side software designed to work in conjunction with client-side software on the user devices 102a and 102 b-102 n to implement any combination of features and functions discussed in this disclosure. For example, the server 106 may run an information management system 201, the information management system 201 managing access to and use of information in the knowledge graph. The server 106 may receive, from a number of user devices belonging to a number of users, received digital assets, such as document files, spreadsheets, emails, social media posts, and the like, for storage. This division of the operating environment 100 is provided to illustrate one example of a suitable environment and does not require that any combination of the server 106 and the user devices 102a and 102 b-102 n be maintained as separate entities for each implementation.

The user devices 102a and 102 b-102 n may comprise any type of computing device capable of being used by a user. For example, in one aspect, the user devices 102 a-102 n may be of the type of computing device described with respect to fig. 8 herein. By way of example and not limitation, a user device may be implemented as a Personal Computer (PC), a laptop computer, a mobile device, a smart phone, a tablet computer, a smart watch, a wearable computer, a fitness tracker, a virtual reality headset, augmented reality glasses, a Personal Digital Assistant (PDA), an MP3 player, a Global Positioning System (GPS) or device, a video player, a handheld communication device, a gaming device or system, an entertainment system, a vehicle computer system, an embedded system controller, a remote control, an appliance, a consumer electronic device, a workstation, or any combination of these described devices, or any other suitable device.

The data sources 104a and 104 b-104 n may include data sources and/or data systems configured to make data available to any of the various components of the operating environment 100 or system 200 described in connection with fig. 2. For example, the data sources may include email servers, social media servers, or other object sources that may be stored in knowledge graphs managed by the techniques described herein. The data sources 104a and 104 b-104 n may be separate from the user devices 102a and 102 b-102 n and the server 106, or may be incorporated and/or integrated into at least one of those components.

Operating environment 100 may be used to implement one or more components of system 200 depicted in FIG. 2, including components for collecting user data, identifying user interests, receiving user queries related to tasks, and responding to queries.

Referring now to FIG. 2, with combined reference to FIG. 1, a block diagram is provided that illustrates aspects of an example computing system architecture suitable for implementing aspects of the present disclosure and designated generally as system 200. System 200 represents just one example of a suitable computing system architecture. Other arrangements and elements may be used in addition to or in place of those shown, and some elements may be omitted entirely for clarity. Moreover, as with operating environment 100, many of the elements described herein are functional entities that may be implemented as discrete or distributed components or in combination with other components and in any suitable combination and location.

The example system 200 includes the network 110 described in connection with fig. 1, with the network 110 communicatively connecting the components of the system 200, including the user device 102, the analytics service 290, and the information management system 201. The information management system 201 includes a privacy policy collection system 210 (and its components 212 and 214), a knowledge graph 220 (and its components 222, 224, 226, and 228), a profile 230 (and an organization profile 231, a group profile 232, a user profile 234), a search engine 242, and a privacy policy enforcement component (and its components 252 and 254). These components may be embodied as, for example, a set of compiled computer instructions or functions, a program module, a computer software service, or an arrangement of processes executing on one or more computer systems, such as computing device 800 described in connection with fig. 8.

In one aspect, the functions performed by the components of system 200 are associated with one or more applications, services, or routines. In particular, such applications, services, or routines may operate on one or more user devices (e.g., user device 102 a), servers (e.g., server 106), may be distributed across one or more user devices and servers, or may be implemented in the cloud. Further, in some aspects, these components of system 200 may be distributed across a network, including one or more servers (e.g., server 106) and client devices (e.g., user device 102 a) in the cloud, or may reside on a user device, such as user device 102a. Further, these components, the functions performed by these components, or the services performed by these components may be implemented at an appropriate abstraction layer (e.g., operating system layer, application layer, hardware layer, etc.) of a computing system. Alternatively or additionally, the functionality of these components and/or aspects described herein may be performed, at least in part, by one or more hardware logic components. For example, but not limited to, illustrative types of hardware logic components that may be used include Field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), system-on-a-Chip Systems (SOCs), complex Programmable Logic Devices (CPLDs), and the like. Additionally, although functions are described herein with reference to particular components shown in the example system 200, it is contemplated that the functions of these components may be shared or distributed among other components in some aspects.

Continuing with FIG. 2, the information management system 201 is used to receive, track, manage, and store digital assets, such as document files, spreadsheet files, presentation files, email files, group chat, and the like. These digital assets may be entities represented by nodes in a knowledge graph. The information management system 201 may be provided to one or more organizations, such as a corporation or partnership. The information management system 201 can maintain records (e.g., history tracking) of various versions of digital assets created and modified by different users. The information management system may overlap somewhat with or be described alternatively as a content management system, an Enterprise Content Management (ECM) system, a digital asset management (ECM) system, a document imaging, a workflow system, and a record management system.

The information management system 201 may store information in one or more servers. The server may be a private server. The server may be provided by a service provider, in which case the organization and/or device may be described as a tenant. Communication between components of the system may be through a variety of suitable Application Program Interfaces (APIs), including Tenant APIs (TAPI) or Personal APIs (PAPI). Aspects of the technology described herein are not limited to the information management system 201 described herein.

The privacy policy collection system 210 is responsible for collecting privacy information from users, groups, and organizations. The collected information is processed and stored in a user opt-out record 228 or an organization opt-out record 226 within knowledge graph 220. The privacy policy collection system 210 may also store privacy information in a profile component 230, the profile component 230 including an organization profile 231, a group profile 232, or a user profile 234. Similarly, private information may be retrieved from the organization profile 231, the group profile 232, or the user profile 234.

The privacy policy manager 212 receives information from the privacy interface 214 and updates the user opt-out record 228 or the organization opt-out record 226 accordingly. The updating may include adding information to the user opt-out record 228 or the tissue opt-out record 226 or subtracting information from the user opt-out record 228 or the tissue opt-out record 226. In one aspect, the privacy policy manager 212 is responsible for synchronizing the data in the user opt-out record 228 and/or the organization opt-out record 226. The synchronization may follow a preference system to manage conflicts between inconsistent privacy instructions. In this sense, the synchronization process may coordinate instructions that are inconsistent between organizations, groups, and users. In one aspect, only the resulting states are stored within knowledge graph 220, while the inputs for determining the results are stored elsewhere, such as in a correlation profile.

A user, group, or organization may have inconsistent privacy policies that manage the same object, audience, and/or request service. In one aspect, the most stringent opt-out instruction dominates (govern). In other aspects, a hierarchy may be applied to reconcile inconsistencies. For example, privacy preferences expressed by the user may govern the results.

The privacy policy manager 212 may manage a multi-variable privacy policy. Variables may include the audience for the information, the service requesting the information, and detailed criteria defining the information to which the policy applies. The audience for the information may be designated as a list of users or predefined groups. If the audience is not specified in the privacy policy, it can be assumed that it applies to all users within the organization. The privacy policy manager 212 may be responsible for keeping the organization opt-out record 226 and/or the user opt-out record 228 up to date. The privacy policy manager 212 may operate in a push or pull environment. For example, the privacy policy manager 212 may receive an indication of a change to the privacy policy from the privacy interface 214 and, in response, change the organization opt-out record 226 and/or the user opt-out 228 record. In another example, the privacy policy manager 212 may monitor a profile or other source of privacy information and use this information to make changes to the organization opt-out record 226 and/or the user opt-out 228 record as needed.

The privacy interface 214 may present a list of groups for selection by a user or organization as allowed or restricted. The privacy interface 214 may be caused to be displayed via the user device 102. The privacy interface 214 may enable individual users to be located and selected. In various aspects, these users may be designated as allowed or restricted. In other words, the privacy interface 214 may provide the user with an opportunity to block access to a specified group or individual or to allow access to individuals and groups. The preformed groups may include temporary groups, such as project teams, or more permanent groups based on organizational structures (e.g., human resources, sales, law, manufacturing, travel). Examples of other pre-formed groups may include a manager and all direct reports to the manager. Groups may also be formed by nearest neighbor analysis of knowledge graph 220. In essence, nearest neighbor analysis can find groups of people that interact with the same object (e.g., document).

The privacy interface 214 may present a list of services for selection by a user or organization as allowed or restricted. For example, the analysis service 290 may be granted limited access to information while the search engine 242 is granted full access.

The privacy interface 214 may enable a user or organization to define what information is allowed or restricted under privacy policies. In aspects, the privacy interface 214 allows a user or organization to allow or restrict particular edges in the knowledge graph. Edges may include user actions or relationships within the knowledge graph. For example, a first user viewing a document may form a first edge between a node representing the user and a node representing the document. The same user that modified the document may form a second edge between the user node and the document node.

The privacy interface 214 may allow a user or organization to specify that information about edges (including aggregated information) is restricted in a privacy policy. The aggregated information may include the number of edges connected to the node without identifying other information about the edges. For example, the analysis service 290 may seek to learn which documents are trending within an organization or group within an organization. Trend documents refer to documents that have the most interactions within a specified time. For example, the trend document interface may display documents that are ranked according to the last week's view. If a user restricts access to his "viewing record" by other users, the requesting service will not receive information about the user's viewing record. Thus, if ten users, including those restricting access, view a document, the results provided in response to a query may be nine users, assuming that no other users have restricted access to their views. In this example, the information of the restrictions is trimmed from the results even though the information of the restrictions exists in the knowledge graph 220.

The privacy interface 214 may allow a user or organization to specify an edge type that is generally restricted, or do so on a node-by-node basis. For example, the user organization may restrict access of the analysis service to "view" or "modify" information about the sensitive document. This will prevent documents from being presented as trends in a group interface or an organization interface, for example.

This is in contrast to preventing access to the document itself, which may be a node in the knowledge graph. Blocking access to the document itself may prevent a user or program from accessing (e.g., opening, viewing, copying) the document content. In this example, the document is not an edge. Edges represent user actions on the document. The user may restrict access to the edges, but not to the node documents. Thus, when an edge representing the view of a document by a first user is restricted, a second user may be able to open the document, but not see that the first user viewed the document. As previously mentioned, access to the edges may depend on the program seeking access to the information. For example, the analysis program may not be granted access to edges representing views of the document by the user, but the document editing program may be granted access to edges (views) and view data displayed in the document editing program.

Knowledge graph 220 is a repository of information that may be organized into semantic graphs. The techniques described herein may work with a variety of knowledge graph architectures, including Graphs based on label-Property Graphs (LPG) and resource description frameworks (Resource Description Framework, RDF). For a label attribute map, both nodes and edges may have metadata (attributes) assigned to them in the form of key-value pairs. They can be used to query and analyze paths in the graph. RDF-based graph databases store data in the form of triple statements (subject-predicate-object). Predicates (relationships) connecting nodes together are given data semantics.

The knowledge graph may contain multiple entities that have relationships to each other. An entity may be broadly defined as a noun. The entities may be organized by entity type. For exemplary purposes only, entity types may include people, locations, places, businesses, digital assets, organizations, movie titles, books, songs, and so forth. There are many examples of entity types and this list is intended as a non-exhaustive list of exemplary entity types. The entity type may be a node in the graph. Relationships connect entities and form graph "edges". For example, an entity instance in a "document" entity type may be connected to a "people" entity type by a relationship "author". An entity type may be associated with multiple entity instances. For example, each person in a person entity type is an instance of a person entity.

The knowledge graph is defined by patterns and consists of nodes and edges connecting the nodes. Nodes represent entities, which may be of different types. Edges connecting nodes represent relationships between entities. These relationships may be referred to as graph attributes. For example, in a document domain, a node represents a core entity type of the document domain, such as a name of the document (Vlogging 101), a name of a user (e.g., vidar), and a date on which the document was created (e.g., 2017). Relationships in the document domain include examples of "view", "edit" and "author". Thus, the relationship "author" can connect the entity instance Vidar and the entity instance Vlogging 101.

The index 222 stores information that may be used to find or retrieve objects (e.g., nodes, edges) represented within the knowledge graph 220. For example, index 222 may store the location of retrievable files. The index 222 may store relationship information that forms edges within the knowledge graph, such as views. In one aspect, the index 222 can be used to find objects in the knowledge graph 220.

The digital assets 224 include files or other information represented in the knowledge graph 220. Digital assets 224 may be represented as nodes in knowledge graph 220. The map 220 itself may store information about the digital assets 224 as records, but the digital assets may be stored in and retrieved from separate computer storage. For example, digital asset 224 may include documents or other objects stored elsewhere.

The organization opt-out record 226 includes privacy policies applied to the entire organization. The tissue-selection exit record 226 may be stored as a node of the knowledge graph, as shown in FIG. 4. In one aspect, the opt-out record 226 specifies only knowledge graph objects that may be conditionally limited (e.g., limited to only specified requesting services or specified audiences). In this embodiment, all other objects not specified in the opt-out record 226 are assumed to be accessible under all conditions. Aspects of the technology described herein are not limited to use with opt-out implementations. For example, alternative implementations may include the status of each object within the knowledge base or each object class within the knowledge base. When most objects are not limiting, using the opt-out implementation may save computer resources by eliminating the need to assign a designation to most objects in the knowledge graph. Instead, the opt-in record may be used in an organization that opts-in to restrict access to most objects in the knowledge base.

It should be noted that an organization may assign different privacy states (e.g., opt-in, opt-out) to individual users or groups within the organization. For example, the organization may assign a choice to the director to exit the privacy state, and assign a choice to the receptionist to join the privacy state. If these privacy states apply only to the user or group of users and not to the entire organization, these privacy states may be recorded in the user opt-out record 228. In this example, the opt-out record 228 may be updated to include the supervisor. In other words, the description of "organize" opt-out records indicates that the policy is applied to the entire organization scope, rather than specifying the source of the instruction.

The user opt-out record 228 includes privacy policies of one or more individual users. These may be described as user privacy policies and apply to only a single user. As described herein, privacy policies for individual users may restrict access to different levels of detail based on the service making the request, the intended audience, and/or the particular content requested, as well as other possible variables. In one aspect, if the user does not specify an individual privacy policy, the user's record will not appear in the user opt-out record 228. In other embodiments, each user has a privacy policy and/or opts out of the record even though no restrictions are defined in the policy/record. The user opt-out record 228 may be stored as a node of the knowledge graph, as shown in FIG. 4.

The organization profile 231 stores information about the organization, including information about the privacy policy of the organization. The organization profile 231 may be stored separately from the knowledge graph 220. The privacy policy information from the organization profile 231 may be stored in the organization opt-out record 226 if the implementation is organization-wide, or the privacy policy information from the organization profile 231 may be stored in the user opt-out record 228 if the restrictions originate from the organization but apply to the user level. For example, an organization may choose to limit access rights to some or all of the actions taken by a particular class of employees (e.g., everyone or all of the authorities of the purchasing department). These types of restrictions originating from the organization may be stored in the user profile of the affected individual. In addition to privacy policy information, the organization profile 231 may also include an organization hierarchy. In some aspects, an organizational hierarchy may be used to form groups. These groups may have their own profile stored in the group profile 232 record. The organization profile 231 may also store information unrelated to private information, such as policies for adding and deleting information from the knowledge graph or otherwise managing the operation of the knowledge graph 220.

The group profile 232 defines a set of individual users and privacy policies applied to those individuals. In one aspect, the group privacy policy allows access to information when the audience is an entire group, an individual in a group, or a subset of individuals in a group. The group privacy policy may deny access when the target audience for the group privacy policy includes one or more users outside of the group. Although defined as group policies, these restrictions may be implemented by including the restrictions in individual user profiles and/or user opt-out records of group members. The group profile 232 may also store information unrelated to private information.

The user profile 234 stores privacy information for individual users. The user profile 234 may also store information unrelated to private information. Information from the user profile 234 may be used to populate privacy policy information in the user opt-out record 228.

The search engine 242 is capable of looking up information in knowledge graphs and is an example of a consumer of graph information. The search engine 242 may consume both information stored in the graph and analysis information about the stored information. For example, the search engine may rank documents stored in the graph according to view, edit date, author influence, and so forth.

The privacy policy enforcement component 250 enforces various privacy policies to ensure that information communicated from the knowledge graph complies with those policies. In one aspect, privacy policies may be checked sequentially to make decisions as to whether the information is restricted or allowed. In one aspect, the organization privacy policy is first checked. The organization opt-out record 226 may store the relevant privacy policy, as described herein. The request for information may be received by access request interface 252. In one aspect, the request takes the form of a query. The request may include specific information, such as a definition of the requested information. The request may also specify the intended audience and the service making the request. In one aspect, the request is submitted with a token that includes information such as the service making the request, search parameters, and the target audience.

In response to receiving the request, the organization privacy policy may be checked by the privacy policy enforcement component 250 to determine whether the requested information is managed by the privacy policy. For example, the privacy policy may be checked to determine whether the privacy policy applies to a particular requesting service. The requested information is evaluated to determine if any portion thereof is subject to the organization policy. The audience specified by the request may also be used to determine whether any portion of the requested information is restricted. Limited information may be identified and pruned from any results provided. An object that is restricted by an organization privacy policy may be described as an organization-restricted object. If there are at least some objects that are responsive to the query and are unrestricted, the user privacy policy may be evaluated. Otherwise, a response may be provided indicating that no object is responding to the query.

The user privacy policy may be evaluated in the same or similar manner as the organization policy. The response information may be first identified and then compared to the privacy policy to see if any user privacy policy limits the requested information. Any restricted information may be described as a user-restricted object. The result set may be generated to include objects that respond to the query but are not user-restricted objects or tissue-restricted objects. For example, in response to a query seeking a number of views of a plurality of documents, less than the actual total number of views may be provided. The number provided does not include views associated with users having privacy policies that limit the recording or organizing the privacy policies.

The data pruner 254 is responsible for pruning limited information from the result set prior to communicating information from the knowledge graph and/or information management system 201. Trimming can occur in a number of different ways. For example, pruning may be performed by first identifying unrestricted objects, and then merely ignoring restricted objects based on the results of these object generation.

The analysis service 290 is just one example of a service that may submit queries to knowledge graphs. As mentioned, these queries may be received by the access request interface 252. The analysis service may provide a variety of services to the user. These services may be specific to a single user or group. A single user or group may be indicated as the audience for a query. Different services may be provided according to different information from the graph. In some cases, the privacy policy may be applied to a specified service provided by the analytics service, or to the underlying requested data. For example, a user may specify a privacy policy based on one or more variables of how information is to be used. For example, a user may specify that his email view is available to identify trending emails, but not generate a report for a particular sender as to how many people read that sender's email.

Example services include generating reports indicating how many people open an email and the average time they take to read the email. An organization may specify which emails (e.g., qualified emails) are eligible to use the service. For example, a qualified email may be an email message sent to five or more qualified recipients. This may prevent the recipient from being individually picked up as not opening the email. This is an example of how an organization and personal privacy policy work in concert. The organization policy may specify that email reports be generated only for qualified emails. Thus, queries from the analytics service 290 may request "open" and "read" data of the user's email. In response, the service may receive information sent to emails of five or more people authorized to access its open and read information. That is, the user with limited access is not provided with or used to determine whether the email is eligible for reporting.

FIG. 3 is a schematic diagram of an example knowledge graph 300, according to some embodiments. A knowledge graph is a graphical representation or visualization of a set of objects in which pairs of nodes or "vertices" are connected by edges or "links. Each node represents a particular location in one, two, or three (or any other dimension) space. A node is a point at which one or more edges intersect. One edge connects two nodes. Specifically, knowledge graph 300 includes the following nodes: "user a 302", "user b 304", "file x 310", "user c 306", "application y 312", and "user e 308". The knowledge graph also includes edges K, I, H, J-1, J-2 and G-1, G-2, G-3, G-4.

Knowledge graph 300 shows the relationship between various users and digital assets (e.g., file x 310 and application y 312). It should be understood that these digital assets are merely representative. Thus, the digital assets may alternatively or additionally include calendars that the user has populated, groups to which the user belongs, chat sessions that the user has engaged in, text messages that the user has sent or received, and so forth. In some embodiments, edges represent or illustrate particular user interactions (e.g., downloads, shares, saves, modifies, or any other read/write operation) with particular digital assets.

Representing digital assets as nodes allows users to link in a more comprehensive manner than conventional techniques. For example, application y 312 may represent a group container (e.g., MICROSOFT TEAMS) in which electronic messages are exchanged between group members. Thus, knowledge graph 300 may show which users are members of the same group. In another illustrative example, knowledge graph 300 may instruct user 302 to download or otherwise access file x 310 at a first time (represented by edge G-1), a second time (represented by edge G-2), a third time (represented by edge G-3), and a fourth time (represented by edge G-4). The diagram 300 may also show that user b 304 also downloaded file x 310, as represented by edge J-1, and written to file x 310 at another time, as represented by edge J-2. Thus, knowledge graph 300 may show a stronger relationship between user a 302 and file x 310 relative to user b 304 based on the edge instances shown between the various nodes (e.g., user a 302 downloaded file x 310 more times relative to user b 304). Other factors related to edges (e.g., strength of relationship) may be considered in determining the analysis results. For example, the duration of the view instance represented by edge G-1 may be stored as an attribute of edge G-1 and used to generate an analysis result. Edges between a file and a user may represent any of a number of actions that may be taken with reference to the file. Non-exclusive lists of user actions that can create edges in knowledge graph 300 include access modification, approval, sign-on, replication, deletion of versions, transfer of secure links, designation of formal versions, download, editing (content)), edit profiles, email links, email copies, new versions, open, move, print, rename, signature, and view. Each of these actions may be associated with metadata describing the action. For example, the date of the action and/or the duration of the action may be stored as metadata associated with the edge, if applicable.

In general, knowledge graph 300 indicates that user a 302 interacted with file x 310 four times (edges G-1 through G-4), user b 304 interacted with file x 310 twice (J-1 and J-2), and user c 306 interacted with file x 310 once (H). Knowledge graph 300 also indicates that user c 306 interacted with application y 312. Knowledge graph 300 also indicates that user e 308 also interacted with application y 312.

In some embodiments, the "distance" corresponds to the number of edges in the shortest path between node U and node V. In some embodiments, if there is a multipole path connecting two nodes, the shortest path is considered the distance between the two nodes. Thus, the distance may be defined as d (U, V). For example, the distance between user a 302 and file x 310 is 1 (e.g., because there are only 1 sides (any of G-1 through G-4)), so the distance between user a 302 and user b 304 (and user c 306) is 2, and the distance between user a 302 and user e 308 is 4 (between user a 302 and user e 308). Thus, the two closest connections for user a 302 are user c 306 and user b 304. The distance may be used to define a group within the group profile 232.

Fig. 4 is similar to fig. 3, but includes a privacy policy node 314. The privacy policy node 314 may be a floating node that is not connected to any other node in the graph 300. Including privacy policy node 314 in graph 300 may divide the privacy information within the same system that manages the information in graph 300. In various aspects, the graph may be migrated to various systems for various reasons. If the privacy policy is stored separately from the graph, the migration process may create vulnerability. Integrating the privacy policy into the nodes of the graph may help reduce or mitigate this vulnerability. However, in other aspects, the privacy policy may be stored outside of knowledge graph 300.

Exemplary method

Referring now to fig. 5-7, each block of the methods 500, 600, and 700 described herein includes a computing process that may be performed using any combination of hardware, firmware, and/or software. For example, various functions may be performed by a processor executing instructions stored in a memory. The method may also be embodied as computer-usable instructions stored on a computer storage medium. The method may be provided by a stand-alone application, a service or hosted service (alone or in combination with another hosted service), or a plug-in to another product, to name a few. In addition, by way of example, the methods 500, 600, and 700 are described with respect to the information management system 200 of fig. 2 and additional features of fig. 3 and 4. However, the methods may additionally or alternatively be performed by any one or any combination of systems, including but not limited to those described herein.

Fig. 5 is a flow chart illustrating a method 500 for enforcing a privacy policy on data output from a knowledge graph, in accordance with some embodiments of the disclosure. The method 500 includes, at block 510, receiving a query from a service seeking information from a knowledge graph. A service may be specified as an application and/or a function performed by one or more applications. For example, the service may be an analysis program, a document management program, a file editing application program (e.g., word processing application program, spreadsheet application program). Thus, a service can be designated as analysis regardless of the program that performs the analysis. The query may include specific information, such as a definition of the requested information (e.g., how many users performed actions (e.g., view, open, edit) on each file in the knowledge graph). The request may also specify the intended audience that will see the results and the service making the request. In one aspect, the query is submitted with a token that includes information such as the requesting service, search parameters, and intended audience. The information specified in the token may correspond to information in the privacy policy. The information specified in the token may be used to determine what information responds to the query and whether the requested information is accessible to the audience or service.

The method 500 includes, at block 520, determining that a privacy policy associated with the knowledge graph applies to the service and restricting the service from accessing information about a first plurality of objects in the knowledge graph. The privacy policy may be an organization privacy policy and/or a group privacy policy. In one aspect, the privacy policy takes the form of an opt-out record, such as an organization opt-out record 226 or a user opt-out record 228. Determining that the privacy policy applies to the first plurality of objects may include analyzing privacy policies of the plurality of users.

The method 500 includes, at block 530, generating a preliminary result set that includes objects in the knowledge graph that respond to the query. The preliminary result set may be generated without reference to the privacy policy. For example, the query may seek all edges of the first type. In this example, all edges of the first type may be a preliminary result set. Each edge may be located between a user and a file. The first type may be a specific action, such as editing a document or sending a document via email.

The method 500 includes, at block 540, generating a final result set including the preliminary result set, wherein the first plurality of objects are removed. According to the above example, the first plurality of objects may be edges intersecting the user, wherein the privacy policy restricts access to the first type of edges. The first type may be specifically identified, or the privacy policy may prevent access to all edges intersecting the user node.

The method 500 includes, at block 550, outputting query results based on the final result set. The query results may be analysis data derived from the final result set, such as how many edges of the first type intersect each document. In this example, the result would be inaccurate because it is not based on all edges, but only on the edges that are not restricted. In one aspect, the requesting service knows that the data is incomplete due to privacy restrictions. The query results are not limited to analysis and may be data from edges or nodes, such as a list of users editing a particular document.

Fig. 6 is a flow chart illustrating a method 600 for enforcing a privacy policy on data output from a knowledge graph, in accordance with some embodiments of the disclosure. The method 600 includes, at block 610, receiving a query seeking information from a knowledge graph. The query may include specific information, such as a definition of the requested information (e.g., how many users performed actions (e.g., view, open, edit) on each file in the knowledge graph). The request may also specify the intended audience that will see the results and the service making the request. In one aspect, the query is submitted with a token that includes information such as the requesting service, search parameters, and intended audience. The information specified in the token may correspond to information in the privacy policy. The information specified in the token may be used to determine what information responds to the query and whether the requested information is accessible to the audience or service.

The method 600 includes identifying a target audience for information at block 620. In one aspect, the audience may be a single user or a group of users. The group may be identified by individual users in the group or by a group identity, such as legal group, purchasing group, technical support group.

The method 600 includes, at block 630, determining that a privacy policy associated with the knowledge graph restricts access by a target audience to information of a first plurality of objects stored in the knowledge graph. The audience for the information may be designated as a list of users or predefined groups. If the audience is not specified in the privacy policy, it can be assumed that it applies to all users within the organization. The referred (conducit) privacy policy may be an organization privacy policy or an individual user policy. The preliminary result set may be generated without reference to the privacy policy. For example, the query may seek all edges of the first type. In this example, all edges of the first type may be a preliminary result set. Each edge may be located between a user and a file. The first type may be a specific action, such as editing a document or sending a document via email.

Method 600 includes, at block 640, generating a final result set including objects responsive to the query, wherein the first plurality of objects are removed. According to the above example, the first plurality of objects may be edges intersecting the user, wherein the privacy policy restricts access by the intended audience to the first type of edges. The first type may be specifically identified, or the privacy policy may prevent access to all edges intersecting the user node. Similarly, the audience may be specifically identified.

Method 600 includes outputting a result based on the final result set at block 650. The query results may be analysis data derived from the final result set, such as how many edges of the first type intersect each document. In this example, the result would be inaccurate because it is not based on all edges, but only on unrestricted edges. In one aspect, the requesting service knows that the data is incomplete due to privacy restrictions. The query results are not limited to analysis and may be data from edges or nodes, such as a list of users editing a particular document.

Fig. 7 is a flow chart illustrating a method 700 for enforcing a privacy policy on data output from a knowledge graph, in accordance with some embodiments of the disclosure. The method 700 includes, at block 710, receiving a query seeking information about a relationship between a user node in a knowledge graph associated with a user and a second node. The query may include specific information, such as a definition of the requested information (e.g., how many users have performed actions (e.g., view, open, edit) on each file in the knowledge graph). The request may also specify the intended audience that will see the results and the service making the request. In one aspect, the query is submitted with a token that includes information such as the requesting service, search parameters, and intended audience. The information specified in the token may correspond to information in the privacy policy. The information specified in the token may be used to determine what information responds to the query and whether the requested information is accessible to the audience or service.

The method 700 includes, at block 720, determining that the organization privacy policy does not restrict access to information about the relationship. In response to receiving the request, the organization privacy policy may be checked by the privacy policy enforcement component 250 to determine whether the requested information is managed by the privacy policy. For example, the privacy policy may be checked to determine whether the privacy policy applies to a particular requested service. The requested information is evaluated to determine if any portion thereof is subject to the organization policy. The audience specified by the request may also be used to determine whether any portion of the requested information is restricted. The information of the restrictions may be identified and pruned from any results provided. An object that is restricted by an organization privacy policy may be described as an organization-restricted object. If there are at least some objects that respond to the query and are not limiting, the user privacy policy may be evaluated. Otherwise, a response may be provided indicating that no object is responding to the query.

The method 700 includes, at block 730, determining that a user privacy policy associated with a user node restricts access to information about a relationship. The user privacy policy may be evaluated in the same or similar manner as the organization policy. The response information may be first identified and then compared to the privacy policy to see if any user privacy policy limits the requested information. Any restricted information may be described as a user-restricted object. The result set may be generated to include objects that respond to the query but are not user-restricted objects or tissue-restricted objects. For example, in response to a query seeking a number of views of a plurality of documents, less than the actual total number of views may be provided. The number provided does not include views associated with users having privacy policies that limit the recording or organizing the privacy policies.

Method 700 includes, at block 740, outputting query results that respond to the query but are not based on information about the relationship. The query result may be analysis data such as how many edges of the first type intersect each file. In this example, the result would be inaccurate because it is not based on all edges, but only on unrestricted edges. In one aspect, the requesting service knows that the data is incomplete due to privacy restrictions. The query results are not limited to analysis and may be data from edges or nodes, such as a list of users editing a particular document.

Exemplary operating Environment

Referring to the drawings in general, and initially to FIG. 8 in particular, an exemplary operating environment for implementing aspects of the technology described herein is shown and designated generally as computing device 800. Computing device 800 is but one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use of the technology described herein. Neither should the computing device 800 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated.

The techniques described herein may be described in the general context of computer code or machine-useable instructions, including computer-executable instructions (e.g., program components) being executed by a computer or other machine (e.g., a personal data assistant or other handheld device). Generally, program components, including routines, programs, objects, components, data structures, etc., refer to code that perform particular tasks or implement particular abstract data types. The techniques described herein may be practiced in various system configurations, including hand-held devices, consumer electronics, general-purpose computers, special-purpose computing devices, etc. Aspects of the technology described herein may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.

With continued reference to fig. 8, computing device 800 includes a bus 810 that directly or indirectly couples the following devices: memory 812, one or more processors 814, one or more presentation components 816, input/output (I/O) ports 818, I/O components 820, and an exemplary power supply 822. Bus 810 represents what may be one or more busses (such as an address bus, data bus, or combination thereof). Although the various blocks of FIG. 8 are shown with lines for the sake of clarity, in reality, delineating various components is not so clear, and metaphorically, the lines would more accurately be grey and fuzzy. For example, one may consider a presentation component such as a display device to be an I/O component. In addition, the processor also has memory. The inventors herein have recognized that such is the nature of the art, and reiterate that the diagram of FIG. 8 is merely illustrative of an exemplary computing device that can be used in connection with one or more aspects of the technology described herein. No distinction is made between categories such as "workstation", "server", "laptop", "handheld", etc., as all categories are contemplated within the scope of fig. 8 and refer to "computers" or "computing devices".

Computing device 800 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computing device 800 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.

Computer storage media includes RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices. The computer storage medium does not include a propagated data signal.

Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

Memory 812 includes computer-storage media in the form of volatile and/or nonvolatile memory. The memory 812 may be removable, non-removable, or a combination thereof. Exemplary memory includes solid state memory, hard drives, optical drives, and the like. Computing device 800 includes one or more processors 814 that read data from various entities such as bus 810, memory 812, or I/O components 820. The presentation component 816 presents data indications to a user or other device. Exemplary presentation components 816 include display devices, speakers, printing components, vibration components, and the like. I/O ports 818 allow computing device 800 to be logically coupled to other devices, including I/O components 820, some of which may be built-in.

Exemplary I/O components include microphones, joysticks, game pads, satellite antennas, scanners, printers, display devices, wireless devices, controllers (e.g., stylus, keyboard and mouse), natural User Interfaces (NUI), and the like. In aspects, a pen digitizer (not shown) and accompanying input tool (also not shown, but which may include a pen or stylus, as examples only) are provided in order to digitally capture freehand user input. The connection between the pen digitizer and the processor 814 may be direct or via coupling utilizing a serial port, parallel port, and/or other interface and/or system bus as known in the art. Further, the digitizer input component may be a separate component from an output component such as a display device, or in some aspects, the available input area of the digitizer may coexist with, be integrated with, or may exist as a separate device that is overlaid or otherwise attached to the display device. Any and all such variations, and any combination thereof, are contemplated to be within the scope of aspects of the techniques described herein.

NUI processes air gestures, speech, or other physiological input generated by a user. Appropriate NUI inputs may be interpreted as ink strokes for presentation in association with computing device 800. These requests may be transmitted to the appropriate network element for further processing. NUI enables any combination of speech recognition, touch and stylus recognition, facial recognition, biometric recognition, on-screen and near-screen gesture recognition, air gestures, head and eye tracking, and touch recognition associated with a display on computing device 800. Computing device 800 may be equipped with depth cameras, such as stereoscopic camera systems, infrared camera systems, RGB camera systems, and combinations of these systems, for gesture detection and recognition. In addition, computing device 800 may be equipped with an accelerometer or gyroscope capable of detecting motion. The output of the accelerometer or gyroscope may be provided to a display of the computing device 800 to render immersive augmented reality or virtual reality.

The computing device may include a radio 824. Radio 824 sends and receives radio communications. The computing device may be a wireless terminal adapted to receive communications and media over various wireless networks. The computing device 800 may communicate with other devices via wireless policies, such as code division multiple access ("CDMA"), global system for mobile ("GSM"), or time division multiple access ("TDMA"), among other policies. The radio communication may be a short range connection, a long range connection, or a combination of short range and long range wireless telecommunication connections. When we refer to "short" and "long" connection types we do not refer to the spatial relationship between two devices. Instead, we will generally refer to short and long ranges as different classes or types of connections (i.e., primary and secondary connections). Short distance link The access may include access to a device providing access to a wireless communication network (e.g., a mobile hotspot)A connection, such as a WLAN connection using the 802.11 protocol. A bluetooth connection with another computing device is a second example of a short-range connection. The remote connection may include a connection using one or more of CDMA, GPRS, GSM, TDMA and 802.16 policies.

Examples

The techniques described herein have been described in connection with particular aspects, which are intended to be in all respects illustrative and not restrictive. While the technology described herein is susceptible to various modifications and alternative constructions, certain illustrated aspects thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the technology described herein to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the technology described herein.

Claims (15)

1. One or more computer storage media comprising computer-executable instructions that, when executed by a computing device, cause the computing device to perform a method of enforcing a privacy policy on information output from a knowledge graph, comprising:

Receiving a query from a service seeking information from a knowledge graph;

determining that a privacy policy associated with the knowledge graph applies to the service and restricting access by the service to information about a first plurality of objects in the knowledge graph;

generating a preliminary result set comprising objects in the knowledge graph that respond to the query;

generating a final result set comprising the preliminary result set with the first plurality of objects removed; and

and outputting a query result based on the final result set.

2. The medium of claim 1, wherein the query seeks a number of first relationship types between nodes representing first type objects and nodes representing users, wherein the query does not seek information identifying the users.

3. The medium of claim 2, wherein the privacy policy restricts access to the first relationship type but allows access to a second relationship type.

4. The medium of claim 2, wherein the first type of object is a document and the first relationship type is viewing the document.

5. The medium of claim 1, wherein the privacy policy is a group policy applied to a subset of users represented by nodes in the knowledge graph.

6. The medium of claim 1, wherein the privacy policy is stored in the knowledge graph.

7. The medium of claim 6, wherein the privacy policy is stored in a floating node that does not contain edges to other nodes in the knowledge graph.

8. A method of enforcing a privacy policy on information output from a knowledge graph, the method comprising:

receiving a query seeking information from a knowledge graph;

identifying a target audience for the information;

determining that a privacy policy associated with the knowledge graph restricts the target audience from accessing information of a first plurality of objects stored in the knowledge graph;

generating a final result set comprising objects responsive to the query, wherein the first plurality of objects are removed; and

outputting a result based on the final result set.

9. The method of claim 8, wherein the information is a number of objects in the knowledge graph that match criteria specified in the query.

10. The method of claim 9, wherein the first plurality of objects are not counted when calculating the number of objects provided in the result.

11. The method of claim 8, wherein the first plurality of objects is a first subset of edges intersecting a node representing a user, and wherein the result is based on a second subset of edges intersecting the node.

12. The method of claim 8, wherein the privacy policy is stored in the knowledge graph.

13. The method of claim 8, further comprising forming the result by deleting information about the first plurality of objects from a preliminary result.

14. The method of claim 8, further comprising synchronizing privacy policies of users by:

determining that an organization privacy state of an organization associated with the user allows access;

determining that a group privacy state of a group associated with the user allows access;

determining that a user privacy state in the user's profile allows access; and

the user is removed from the privacy policy.

15. The method of claim 8, wherein determining that the privacy policy associated with the knowledge graph limits access to information of the first plurality of objects stored in the knowledge graph comprises:

determining a first privacy state of a first user privacy policy associated with the knowledge graph restricts access to a first subset of the first plurality of objects;

determining a second privacy state of a second user privacy policy associated with the knowledge graph to restrict access to a second subset of the first plurality of objects; and

The first plurality of objects is determined by combining the first subset and the second subset.