Patent Description:
While creating and editing content within a productivity application, a user may start with a blank page document and may create new content. Additionally a user may borrow content from other sources and/or existing documents, and the user may use the borrowed content without modification or may update the content. As content is reused and modified in multiple different documents by multiple users, it may become cumbersome to trace a history of the original content and to determine who created, contributed, and/or changed the content. Finding relevant information from online, remote, or local sources can also be a challenge. With respect to responding to search queries for content, <CIT> discloses systems, methods, and software for facilitating enhanced search services. An enhanced search service receives a search query associated with a user and responsively identifies documents relevant to the search query. The enhanced search service also identifies a social label for each of the documents that is at least partly representative of how the document relates socially to the user. The enhanced search service replies to the search query with search results indicative of at least the documents and the social label for each of the documents. <CIT> relates to computer systems and methods used to generate and control standardized electronic documents.

Techniques and systems for facilitating content reuse are presented. As content is created, shared, modified and reused by multiple users in new and existing documents, a document graph is generated and updated to keep track of relationships between content (including identifiable components, such as a table, image, paragraph, and title), documents containing the content, users performing actions on the content and/or the documents, and the actions being performed (including creating, reading, updating, deleting, and the like). This document graph can be leveraged to identify relevant reusable content and track its reuse.

In certain embodiments, each reusable component of content within a document can be extracted and then stored, searched, and retrieved independently of the source document.

In certain embodiments, actions of a user with respect to a document or the content therein while working within a productivity application for a duration of a window of time can be aggregated, and the aggregated actions normalized to an action class. The normalized action can be written to a document graph, for example as an edge between a node representing a user and a node representing a document or a piece of content. In addition to being able to normalize actions a user may take upon content, a user's activity with respect to one or more pieces of content - whether part of a normalized action or not - can be mapped to actor classes. Through the normalized actions and connected users, a particular piece of content or document can also be classified a particular content class.

The various classification processes can be carried out by a labeler executed by a computing system or as part of a service. In some cases, the labeler can store an identified actor class on the document graph to indicate the relationship between the interacting user and the particular document and/or portion of content. Similarly, the labeler can store an identified content class on the graph to indicate the relationship between the particular content/document and how it is used or consumed by users. A timestamp can also be included to facilitate identification of how current the label is.

In some cases the labeler or a separate indexing service can extract out any content components (e.g., pictures, tables, slides, plots, outlines and the like) from the document to identify content components for reuse. The extracted content components can be identified on a document graph and assigned a component type (as part of an edge between a user node or a source document node and the extracted component node or as data associated with the extracted component node). The extraction may also include the activity history (e.g., normalized action or classification) of a piece of content forming the extracted component.

The actor class assigned to a user and/or a content class assigned to a piece of content (of a document or extracted content component) by a labeler, as well as the component types assigned to an extracted content component, can be leveraged to identify content for reuse as well as provide additional features for productivity applications and collaboration.

A productivity application can communicate with a service to request reusable content components and other content associated with a document. The productivity application can also request reusable content based on one or more labels assigned to actors associated with the content and the content itself.

Techniques and systems for facilitating content reuse are presented. For example, content reuse can be facilitated through the storage of information in a document graph. As content in new and existing documents is created, shared, modified and reused by various users of an application supporting these activities, a document graph can be generated and updated to keep track of the relationships between content, documents containing the content, users performing actions on the content and/or the documents, and the actions being performed (including creating, reading, updating, deleting, and the like).

It is expected that the content that a user is most likely to want to reuse is content that was created or interacted with by someone that has a particular relationship to them or an organization to which they belong. An enhanced document graph can be generated to store information indicating types of relationships between people and even between content. In addition, the documents represented in the document graph can have their reusable content components indexed and these content components can also be represented in the document graph.

<FIG> illustrate visual representations of document graphs that may be generated, and queried, for content reuse such as described herein. A document graph is a data structure that maps relationships between users, between a user and particular documents, and between documents. In some cases various granularity of content within a document can be mapped within the document graph. Granularity of content includes, but is not limited to, identifiable components such as a table, image, paragraph, title, slide, outline, and other application-defined objects that can contain content.

A document graph can include nodes representing an entity (a person or an object) and edges representing connections between nodes (e.g., the relationship or action associated with the two entities). Nodes may be identified in a document graph by a node identifier (ID). For example, a person, a document, or other object may have been assigned or can be assigned an identifier used to represent it in the document graph. Other types of identifiers are possible and may be considered within the scope of the present disclosure.

The edges may have various properties, such as the type of action that the edge represents, a target of the edge, a source of the edge (an email system or file storage system, for example, or a user or object), a date or time stamp, a relative importance of the action, and whether or not the action is private or public. Other edge properties in addition to or in place of those disclosed herein are possible. For example, an edge property assigned for reusable components can include 'contains' indicating that the reusable component is part of, and associated with, a particular document. The edge property may also include additional details regarding action or actor such as whether the reusable component was created/originated as part of that particular document, was inserted into that particular document, and by whom). Edges can also be given weights to indicate their relative importance. This may be useful in the context of two edges of the same type to indicate the importance of one relative to the other.

Referring to <FIG>, a plurality of connections are shown between users and users and between users and documents. For example, a first node <NUM> indicating User1 and a second node <NUM> indicating User2 are shown connected by first relationship edge <NUM> representing that there is a relationship between the two users. In addition, the first node <NUM> indicating User1 is shown connected by a first action edge <NUM> to a first document <NUM>. In this case, the first relationship edge <NUM> indicates that User1 and User2 are members of a same work group; and the first action edge <NUM> indicates that User1 created the first document <NUM>.

A document, such as the first document <NUM>, may include any item associated with a productivity application, such as for example, a word processing file, an email, a calendar item, a meeting request, a contact, or other similar item that includes content associated with the item.

Other users may interact with and/or collaborate on the same documents and this information stored in the document graph. For example a User3, who is not in the same work group as User1 and User2 may have collaborated with User1 on the first document <NUM>. The document graph can reflect this connection using a second action edge <NUM> connecting a fourth node <NUM> representing User3 to the first document <NUM>. According to various implementations, action edges include properties indicating an action or class of actions. Further implementations include a date and/or time information (e.g., in the form of a timestamp for the action, a session identifier, a particular time period captured by the system, or other suitable identifier or granularity). Some example actions may include edit, modify, read, share, copy and paste, present, or other similar action. In some further examples, metadata associated with specific edits and modifications to content may be saved but not visually represented on the document graph. In some cases, as an action is associated with a portion of content, or a content node, the action may be also automatically inherited by the document that contains the piece of content being acted on.

In some cases, connections between user nodes can also be established based on interactions with documents (and not just external indicators such as work teams). For example, User1 can be connected by a second relationship edge <NUM> to the fourth node <NUM> representing User3 to reflect that the two people may be relevant to each other in some manner. The relationship edges can include various properties that could be used to traverse the document graph and understand the relationships between the people. In some cases where such edges are included, the number of hops that may be undertaken during a search of the document graph can be minimized.

Referring to <FIG>, the document graph can store a finer granularity of detail. Here, the document graph indicates not just that User3 is connected to the first document <NUM> by second action edge <NUM> indicating that the User3 acted on the document, but also that User3 specifically performed an action with respect to a specific content <NUM> (e.g., paragraph of text) for the first document <NUM>. The third action edge <NUM> between the fourth node <NUM> representing User3 and the specific content <NUM> can indicate this finer granularity of action. The specific content <NUM> can be indicated as being connected to the first document by a first "contains" edge <NUM>.

Not only can the actions taken on a particular document be stored in the document graph, but the reuse of the particular document and/or content therein be stored as part of the document graph as well. For example, User2 may create a new document, reflected in the graph as fourth action edge <NUM> representing the action create that connects the second node <NUM> representing User2 to a second document <NUM>. In addition, User2 may have copied the specific content <NUM> into the second document <NUM>. This activity and corresponding relationships can then be reflected in the document graph as second 'contains' edge <NUM> between the specific content <NUM> and the second document <NUM>, indicating that the second document <NUM> contains the specific content <NUM>; a fifth action edge <NUM> between the specific content <NUM> and the second node <NUM> representing User2, which can indicate that the User2 performed an action of consumed/copied the specific content; and in some cases, an additional edge or property of an existing edge to indicate a relationship between users as a result of the reuse of specific content <NUM>. Regarding this last relationship, it may be reflected by an additional property and data on the first relationship edge between the first node <NUM> representing User1 and the second node <NUM> representing User2; and/or as a new edge (e.g., third relationship edge <NUM>) between the second node <NUM> representing User2 and the fourth node <NUM> representing User3.

<FIG> shows additional detail regarding reusable components of the first document <NUM>. In addition to specific content <NUM> that is added as a node to the graph because of an action taken on it by a user, reusable components of the first document <NUM> can be identified and at least indexed. A "document shredder" (a module or software application that deconstructs a document into reusable components) can identify the specific content components within a document that are likely to be reused in others. Examples of these specific content components include images, visualizations/charts (e.g., as available from certain spreadsheet applications), data tables, slides, and the like.

In one implementation, such as shown in <FIG>, the document shredder can include instructions <NUM> that direct a system to identify content component types (such as application specific, pre-defined content component types and other identified content components that may be content based) within a source document (<NUM>), replicate the content components associated with the identified content component types (<NUM>), and store the replicated content components associated with the source document (<NUM>). In some cases, the replicated content components are stored separately from the source document. As an alternative to replicating the content components and optionally storing the replicated content components separately from the source document, the content components can be identified using metadata or other markup on the source file. The metadata or other markup indicating the identified content components can be stored associated with the source document.

As part of, or subsequent to, the identifying of content component types within a source document, the identified components can be indexed and represented as nodes in a document graph that connected to the document by a 'contains' edge (which may also include other properties) (<NUM>).

In some cases where the content components are separately stored, the separately stored content components can be synced to their counterparts in the source document or at least connected in a manner that if not included in another document, the content component can be deleted when the source document is deleted. This can be accomplished by parameters or properties assigned to the edges connecting the content component nodes to their respective source documents. The 'contains' edge does not necessarily require that the reusable components be stored and indexed as a separate entity from the source document. Instead, for some implementations, metadata can be written in to or associated with the source document file to highlight specific reusable segments in-place in the document. A single file may be stored in storage, but multiple nodes in the graph can be represented in the document graph that all reference different chunks or pieces of the file. These nodes (representing the content components in the source document) may be connected to each other via an edge indicating that they are siblings (e.g., 'isSibling' edges - not shown in the Figures).

Returning to the example illustrated in <FIG>, the first document <NUM> can be a business report that includes a first table Table1, a second table Table2, an image, and headers. These identified components can be represented on the document graph as node Table1 <NUM> connected to the first document <NUM> by third contains edge <NUM>, node Table2 <NUM> connected to the first document <NUM> by fourth contains edge <NUM>, image node <NUM> connected to the first document <NUM> by fifth contains edge <NUM>, and headers node <NUM> connected to the first document <NUM> by sixth contains edge <NUM>.

Where the document shredder includes additional functionality for identifying portions of text using keywords, key phrase and/or topic detection to identify sections of the text that can relate to the context of the user's document, a portion of text can be extracted and identified as a subcomponent of a document. For example, a content node <NUM> representing a paragraph containing a topic of a product prediction can be connected to the first document <NUM> with a seventh contains edge <NUM>.

In some cases, text blocks can be extracted that provide definitions for terms. For example, a definition node <NUM> can be generated from an extracted text block indicating a definition of the term "robust" that was included in the first document <NUM>. The definition node <NUM> can be connected to the first document <NUM> with an eighth contains edge <NUM>. The additional functionality for identifying portions of text can be accomplished via any suitable content analysis algorithms.

For example, the content of a document can be analyzed to identify entities, topics, and key phrase extractions. The key phrase extraction may be trained on a public and/or private corpus. The content in the document may contain various entries, such as text, words, strings, numbers, symbols, images and the like. An entry may be recognizable as an entity based on various characteristics. The analysis of the document can include searching for recognizable entities and/or domains, for example by named entity recognizers and dictionary look-ups. A domain is a category for a series of entities (or items). For example, a domain may be books. An entity refers to a concept (person, organization, location, service, temporal, numeric, monetary etc.) that a document (or other file) is discussing or describing. In the book domain example, they entity may be a specific book. The aspects are the properties or attributes of the entity that are mentioned about the entity and which may be of interest to the user. In the case of a book as an entity, the genre or the premise/plot are examples of the aspects. It should be understood that the term "entity" should not be restricted to specific named entities and may refer to broad concepts such as "sales data" or "pitch deck".

A topic is a distribution of words and that can correspond to an aspect of an entity (and sometimes the entity itself). A topic serves as a subject or category of related information. The topic of an expression can be used for entity disambiguation (e.g., using Latent Dirichlet Allocation (LDA) and its hierarchical variants). Entity disambiguation refers to the identifying of entities from text and their labeling with one of several entity type labels. In some cases, Wikipedia may be used as a comprehensive reference catalog for large-scale entity disambiguation. In other cases, other public and/or private corpus can be used to facilitate the entity disambiguation.

The identification of portions of text as content components may be supplemented by identifying certain components or sub-components in the document such as paragraph or section or region with particular formatting (such as identified by a different style).

In certain embodiments, the identified content components can be copied and stored separately from the original document. In some cases, no tags or modifications to the original document are needed to indicate that components have been identified and indexed on a document graph.

A document graph such as illustrated in <FIG> may be implemented in any system with users that can be identified within the system and have the relationships between them identified. For example, a company may have employees that can be identified by unique user identifiers and may further include a company hierarchy where the employees are assigned groups and managers and/or are assigned roles. Contacts managed by a personal information management application at the enterprise or personal level may also provide identifiable relationships used by a document graph. Another example may include students who may be identified in a school system with unique identifiers and have information that can be used to group students and faculty together such as class schedules, majors, and departments. A graph of a social network, for instance, may include nodes that represent all of the people in a group of people and edges that represent how they are connected to each other.

To optimize and facilitate content reuse, processes are carried out on the document graph and, in some cases, the results of these processes are added to the graph as a node and/or an edge and/or a property thereof.

In various implementations, a document graph can indicate content (and the document(s) to which that content belongs), actions (e.g., create, read, update, delete), actors (e.g., the person or people performing the actions), and information indicating when an action is performed (e.g., a timestamp).

These edge properties can be enhanced and updated by a labeler, which can be implemented as software instructions stored on one or more computer-readable storage media and executed by a processing system. The labeler can, in some cases, be implemented as part of a service. The labeler can be used to perform at least one of normalizing actions into action classes, classifying users into actor classes (based on their interactions with one or more pieces of content and/or documents), and classifying content into content classes (based on the actions various users have taken on the content). Action classes classify a group of actions into a recognizable activity. For example, an author might make a series of edits where they delete comments from others in the document. These atomic actions ("delete comment") are aggregated and classified into a single action class, such as "finalize document". Helpful actor classes include, but are not limited to major reviewer, minor reviewer, commenter, and major contributor. Helpful content classes include, but are not limited to trending content, most influential, influenced by, and other indicators of reuse or consumption.

In some cases, the labeler can incorporate a document shredder so that reusable components - pieces of content - can be identified as being contained, or part of, a particular document by the labeler. The labeler can then classify the reusable components into content classes based on the actions various users have taken on them.

When searching the document graph, a query can be used to identify a "landing" location in the graph (e.g., a "hit" or initial result) and then the graph is "walked" to obtain a final result for the query (which can be returned). A walk is a sequence of graph nodes and graph edges, for example, n<NUM>, e<NUM>, n<NUM>, e<NUM>,. nk of graph nodes ni and graph edges ei such that for <NUM> ≤ i ≤ k, the edge ei has endpoints n(i-<NUM>) and ni. The length of a walk is its number of edges.

<FIG> illustrates an action classification process. Referring to the action classification process <NUM> shown in <FIG>, one or more actions carried out by a user are aggregated for a window of time (<NUM>). The window of time may be a day, an hour, a session, or any other suitable period of time. The aggregated actions can be stored, at least temporarily in a session log or other suitable data structure as described above. The actions that have been aggregated for the time window are then normalized to an action identified in an action model (<NUM>). That is, the actions may be normalized to an action class representative of a category of actions, which may be based on a predefined action model. For example, a predefined action model for the normalized action "edit" can include logged actions such as undo, type, copy, paste, and the like. The actor (user) and the normalized action can be stored associated with a particular document or content. In some cases, the normalized action can be written to a document graph (<NUM>), for example, as a property of an edge between a user node and a document node (and/or particular content node).

<FIG> illustrates a user classification process. Referring to the user classification process <NUM> as shown in <FIG>, users can be classified based on their actions with respect to one or more documents and/or content. These actions can be or include the normalized actions indicated at connecting edges between a user node and document or content node of the document graph.

The classification of the users can be carried out by mapping actions to actor classes (<NUM>); and then classifying a user as belonging to one of the actor classes according to the actions that user has taken on one or more documents or content (<NUM>). An actor class refers to a role or label that can be given to a user that represents their relationship to a document. For example, a user can be classified as having a particular role or label in general (e.g., based on the user's actions on multiple documents or pieces of content) or with respect to a particular document or piece of content (e.g., based on the various normalized actions that a user may have taken on the particular document or piece of content).

As an illustrative example, predefined actor classes indicating a user's role with respect to a particular document may include reviewer (someone who puts finishing touches on a document, spends a significant time in the document and makes only a minor change, or meets some other conditions for the label of reviewer), minor contributor (someone who meets the conditions set out for this label or does not meet the conditions of a major contributor based on their normalized actions), and major contributor (someone who meets the conditions set out for this label). In this illustrative example, it may be sufficient to base the actor class according to a predefined number of edit actions (as the condition for falling within a particular class).

As other illustrative examples, predefined actor classes may include creator/originator, commenter (someone who uses the comment field in a document), presenter (possibly identified by shares certain content in an online meeting or checking out of a particular content or document from a shared repository multiple times while moving through each slide), influencer (e.g., a user who's created work is reused by others), and propagator (e.g., a user who reuses or shares other people's work). The particular label assigned for an actor class can be obtained from a table or other data structure storing the information.

After the user is classified, the actor class information can be written back into document graph (<NUM>), for example as a label. A timestamp can also be included to facilitate identification of how current the label is. In some cases, this information can be indicated on an edge between the user node and one or more document or content nodes from which the actions used to classify the user were connected. In some cases, this information can be indicated as a property of the user node. The actor class for a particular user with respect to one or more documents or content may change over time. Accordingly, in some cases, when a user is classified, a timestamp or other temporal indicator can be stored as well.

<FIG> illustrates a content classification process. Referring to the user classification process <NUM> as shown in <FIG>, content can be classified based on the actions taken upon it. These actions can be or include the normalized actions indicated at connecting edges between a user node and document or content node of the document graph.

The classification of the content can be carried out by mapping actions to content classes (<NUM>); and then classifying a piece of content as belonging to one of the content classes according to the actions that users have taken on that piece of content (<NUM>). The content class indicates the relationship between the particular content/document and how it is used or consumed by users. Examples of content classes include, but are not limited to, trending content, most influential, and other indicators of reuse or consumption. As an example illustration, a piece of content with actions connected to it indicating a certain number of times that it has been copied into other documents can be classified with an "influential" label. The particular label assigned for a content class can be obtained from a table or other data structure storing the information.

The information about a content class of a particular piece of content can be provided for various uses (<NUM>). In some cases, the content class for the piece of content can be written to the document graph. A timestamp can also be included to facilitate identification of how current the label is. In some cases, the content class can be provided to a source of a request for the content class of a piece of content.

The enhanced document graph (and labeler processes <NUM>, <NUM>, and <NUM>) as described herein, may provide assistance for users of a productivity application with tracking a history of particular content portions including when and how it is created, shared, and modified and who has interacted with the content. Additionally, the enhanced document graph may also facilitate identification of content that may be most recently updated and best for reuse, and may indicate one or more users who may be helpful to contact with questions or feedback about a particular content portion. For example, a productivity application (or associated productivity tool) may request user information, document/content information, and/or label information from one or more services, which can then perform various processes in response to that request and provide appropriate results.

<FIG> illustrate example processes in which the described enhanced document graphs (and associated classifying processes) may be used to improve content reuse.

Referring to <FIG>, a process <NUM> for identifying users having a particular label can begin when a request is received for identifying users having a particular label (<NUM>). In some cases, process <NUM> is performed before the request is received. In one such case as illustrated in path A1-A2-A3, the service receiving the request can search the document graph for the particular label (<NUM>). For example, a service performing process <NUM> may search a document graph (such as document graph <NUM> of <FIG>). The results from the search of the document graph can be received (<NUM>) and a list of users having the particular label can be returned in response to the request (<NUM>). Receipt of the results may occur in stages or may be directed by additional parameters included with the original request for users having a particular label or in a query associated with the search. In some cases, after the request is received (<NUM>), process <NUM> is performed (<NUM>). In this case, process <NUM> may be performed even if process <NUM> had been performed prior to receiving the request (<NUM>).

In one implementation as illustrated in path B1-B2a-B3a-B4a, the service receiving the request can perform process <NUM> (<NUM>). Process <NUM> may be performed on all of the document graph or a subset of the document graph, and may be based on additional parameters of the request. Where the results of process <NUM> are written back to the document graph, the service queries the document graph for the particular label (<NUM>) and waits to receive the results from the search (<NUM>) before returning the list of users having the particular label in response to the request (<NUM>).

In another implementation as illustrated in path B1-B2b-B3b, the service receiving the request performs process <NUM> and identifies users having the particular label while performing process <NUM> (<NUM>) so that it is not necessary to search the document graph (or be concerned whether the actor class labels are written back to the graph). A list of the identified users having the particular label can then be returned in response to the request (<NUM>).

Process <NUM> can be carried out with additional parameters, for example, to identify the users that have the particular label for particular content and/or that are also connected in some manner to another particular user (e.g., by being in a same group or course as the another particular user or by being in a contacts list of that another particular user). In an example scenario, a document graph can be searched for a set of users having a connection to a particular user (who may be identified by a user ID); and it is from this set of users that the users having the particular label are identified. Similarly, a set of users may be established from those connected to a particular piece of content (e.g., having a content identifier); and it is from this set of users that the users having the particular label may be identified.

Referring to <FIG>, a process <NUM> for identifying labels of user(s) for a particular document or content can begin when a request is received for identifying labels for users of a particular document or content (<NUM>). This request may be sent by an application that includes such information in its graphical user interface (either as part of identifying contributors of a document or by indicating a source for a piece of content that was generated in a collaborative setting) or that enables this functionality for a user to request.

As with the process <NUM>, in process <NUM>, process <NUM> may have already been performed before the request is received. In one such case as illustrated in path C1-C2-C3, the service receiving the request can search the document graph for the labels of each user connected to the particular document or content (<NUM>). The results from the search of the document graph can be received (<NUM>) and the label for each user connected to the particular document or content can be returned in response to the request (<NUM>). Receipt of the results may occur in stages or may be directed by additional parameters included with the original request.

In some cases, after the request is received (<NUM>), process <NUM> is performed for each user connected to the particular document or content (<NUM>). In this case, process <NUM> may be performed even if process <NUM> had been performed prior to receiving the request (<NUM>).

Once the service receiving the request performs process <NUM> for each user connected to the particular document or content (<NUM>), in the case as illustrated in path D1-D2a-D3a-D4a, where the results of process <NUM> are written back to the document graph, the service queries the document graph for the labels of each user connected to the particular document or content (<NUM>), waits to receive the results from the search (<NUM>), and returns the labels for each user connected to the particular document or content in response to the request (<NUM>). However, in some cases, such as illustrated in path D1-D2b, the output of process <NUM>, as performed in operation <NUM>, can directly be returned in response to the request (<NUM>).

Referring to <FIG>, a process <NUM> for identifying content (or documents) based on a user's label can begin when a request is received (<NUM>). This type of search may be carried out where a user is identified as possibly being associated with content that may be relevant for reuse and that user may both author and review a considerable amount of content. By focusing on the content that the particular user is labeled as a major contributor as opposed to a reviewer, the content most likely relevant for reuse can be determined.

In implementation of process <NUM>, as illustrated in path E1-E2-E3, after receiving the request, the service can search the document graph for the documents or content connected to the particular user for which the particular user has the particular label (<NUM>). As in the other described methods, process <NUM> may have been performed before the request is received. The results from the search of the document graph can be received (<NUM>) and a list of documents or content (or the content/documents themselves in some form) may be returned in response to the request (<NUM>). Receipt of the results may occur in stages or may be directed by additional parameters included with the original request.

In another path for process <NUM>, as illustrated as path F1-F2a-F3a-F4a, after the request is received (<NUM>), process <NUM> is performed (<NUM>) even if process <NUM> had been performed prior to receiving the request (<NUM>). Here, process <NUM> may be performed on all of the document graph or a subset of the document graph, and may be based on additional parameters of the request. Where the results of process <NUM> are written back to the document graph, the service queries the document graph for the content or documents that meet the criteria for a particular user with a particular label (<NUM>) and waits to receive the results from the search (<NUM>) before returning the results in response to the request (<NUM>).

In another case, as illustrated in path F1-F2b-F3b, the service receiving the request performs process <NUM> and identifies content connected to a particular user if/when that user has the particular label while performing process <NUM> (<NUM>) so that it is not necessary to search the document graph in order to return the identified content (or list of content) in response to the request (<NUM>).

Process <NUM> can be carried out with additional parameters, for example, to identify documents having content relevant to a particular topic that are connected to a particular user when that particular user has a particular label. In this case, the results returned in response to the request only contain the content/documents that are relevant to the topic as well as to the user with the particular label with respect to those content/documents.

<FIG> and <FIG> illustrate example processes in which the described enhanced document graphs (and document shredding processes) may be used to improve content reuse.

Referring to <FIG>, a process <NUM> for identifying content components having a particular label can begin when a request is received for identifying content components of a particular component type (<NUM>). In some cases, process <NUM> is performed before the request is received. In one such case as illustrated in path G1-G2-G3, the service receiving the request can search the document graph for the particular component label (<NUM>). The results from the search of the document graph can be received (<NUM>) and a list of components having the particular component label can be returned in response to the request (<NUM>). For example, a request for graphs can return a list of content that is in the form of a graph. Receipt of the results may occur in stages or may be directed by additional parameters included with the original request for users having a particular label or in a query associated with the search. In some cases, after the request is received (<NUM>), process <NUM> is performed (<NUM>).

In one implementation as illustrated in path H1-H2a-H3a-H4a, the service receiving the request can perform process <NUM> (<NUM>). Process <NUM> may be performed on all documents identified in the document graph or a subset of the document graph, and may be based on additional parameters of the request (e.g., a particular document name, a particular user name, etc.). The results of process <NUM> can be written back to the document graph, and the service can then search the document graph for the particular label (<NUM>). After receiving the results from the search (<NUM>), the list of components having the particular component label can be returned in response to the request (<NUM>).

In another implementation as illustrated in path H1-H2b-H3b, the service receiving the request performs process <NUM> to shred document(s) into identifiable content components and those content components having the particular label (of component type) can be identified (<NUM>). The identification of content components having the particular label can be performed simultaneously with or before writing the labels onto the document graph. A list of the identified users having the particular label can then be returned in response to the request (<NUM>).

Process <NUM> can be carried out with additional parameters, for example, to identify the content components that have the particular label for particular content and/or subject matter and/or that are also connected in some manner to a particular user (who may be identified by a user ID).

Referring to <FIG>, process(es) <NUM> for identifying content components having a particular label (component type) and which are related to a particular topic (subject matter, title, term, theme, etc.) or actor (particular user or user label) can begin when a request is received for identifying content components of a particular component type that are related to a topic or actor (<NUM>). It should be understood that a variety of processes may be carried out to identify the "topic" and/or provide appropriate terms for use in searching the document graph.

As with the search of the document graph described in operations <NUM> and <NUM> of <FIG>, the document graph can be searched to identify the desired content components. Two example implementations are shown, which follow a query-hit-walk approach for searching a graph. It should be understood that other types of searches of a document graph can be implemented in different embodiments and the searching of the graph performed by the service described herein is not limited to the query-hit-walk approach described in detail herein.

In the implementation following path K1-K2-K3, the document graph can first be searched for a document (or documents) indicated as being related to the particular topic or actor (<NUM>). Then, from a document indicated as being related (the "hit"), the graph is walked to the sub-content (components) having the particular component type label requested (<NUM>). The results of this search can be returned in response to the request (<NUM>). In some cases, a copy of the content components themselves are provided along with the list.

In the implementation following path L1-L2-L3, the document graph can be searched for content components having the appropriate component type label (<NUM>) and then this subset of content components analyzed to identify whether the content component is related to the particular topic or actor (<NUM>). In many cases, the topic of (or even the actor associated with an action taken on) a content component may be stored as an attribute of the node or the edge for that content component. The results of the search can be returned in response to the request (<NUM>).

As an illustrative example, a request may be for component type of plots that show topic of QY13 sales. The graph search can begin by searching for documents having content identified with topic QY13 sales and then when a document is identified (the "hit"), the graph can be traversed (or "walked") to identify the component(s) or sub-component(s) with the appropriate component type label (e.g., of "plot"). In some cases, the results can also return other plots that not connected to the identified document but are connected to the user connected to the document identified with topic QY13 sales. This may in some cases occur when the user is labeled with QY13 to indicate a topic the user contributed to (and such information could be contained in the graph as part of or associated with the user node).

Although the described techniques are specifically described with respect to taking advantage of graph structures, the data may alternatively be stored in other structures. In such alternative embodiments, any suitable mechanism for searching may be used where the data about user relationships, documents associated with those users (by the users creating, modifying, or suitably interacting with those documents), and the dates/times the users created, modified, or suitably interacted with those documents may be available.

<FIG> illustrates an operating environment in which the described techniques may be carried out. As shown in <FIG>, users may create, modify, share, and collaborate on documents using a variety of productivity applications running at least in part as client application(s) <NUM> on computing device <NUM>.

Examples of computing device <NUM> include, but are not limited to, smart phones, laptop computers, tablet computers, desktop computers, hybrid computers, gaming machines, smart televisions, entertainment devices, Internet appliances, virtual machines, wearable computers (e.g., watch, glasses), as well as any variation or combination thereof, of which computing system <NUM> illustrated in <FIG> is representative.

In some cases, client application(s) <NUM> can implement a web application version of a productivity application through a web browser (e.g., a browser-based application that executes in the context of a browser application). In some cases, client application(s) <NUM> implement a locally installed and executed productivity application, a streamed productivity application, a mobile productivity application, or any combination or variation thereof.

A productivity application can include word processing applications, spreadsheet applications, presentation applications, web browsers, email applications, blogging and micro-blogging applications, social networking applications, and gaming applications. Examples of productivity applications include the Microsoft Office® suite of applications from Microsoft Corp. , including Microsoft Word®, Microsoft Excel®, Microsoft PowerPoint®, as well as the web application components thereof, all registered trademarks of Microsoft Corp. ; Google Docs (and Google Drive™); the Apache OpenOffice™ available from the Apache Software Foundation; the LibreOffice® suite of applications available from The Document Foundation, registered trademarks of The Document Foundation; and the Apple iWork® suite of applications from Apple Inc. , including Apple Pages®, Apple Keynote®, and Apple Numbers®, all registered trademarks of Apple Inc.

In some cases, data is collected while a user is interacting with and authoring (or editing content) within a productivity application <NUM>. The collected data can include the commands (available from the particular productivity application) and other interactions a user may have with portions of content while consuming or authoring the content. This data may be collected locally, for example, as part of a session (or instance) of the productivity application (and stored at the computing device <NUM>). In addition or as an alternative to local collection of data, a service <NUM> (running on a service platform <NUM>) that is associated with or that may communicate with the productivity application can, with user permission collect data from a local session (and store this data at or in connection to the service platform <NUM>).

Service platform <NUM> is representative of any physical or virtual computing system, device, or collection thereof capable of hosting all or a portion of service <NUM>. Examples of service platform <NUM> include, but are not limited to, web servers, application servers, rack servers, blade servers, virtual machine servers, or tower servers, as well as any other type of computing system, of which computing system <NUM> of <FIG> is representative. In some scenarios, service platform <NUM> may be implemented in a data center, a virtual data center, or some other suitable facility. In some cases, service platform <NUM> may be implemented similarly to computing system <NUM>. A document graph <NUM> may be stored in a resource that is part of or accessible by the service platform <NUM>. The document graph <NUM> may be generated and maintained by the service <NUM>.

In some cases, application <NUM> may be considered remote from service <NUM> in that each are implemented on separate computing platforms. In such situations, application <NUM> and service <NUM> may communicate by way of data and information exchanged between computing device <NUM> and service platform <NUM> over a suitable communication link or links (not shown). In other cases, the features and functionality provided by application <NUM> and service <NUM> can be co-located or even integrated as a single application.

The initial data collected from a user's interaction with a document and/or content within a productivity application <NUM> may be stored in any suitable data structure at the computing device <NUM> or service platform <NUM>. In some cases, the data is initially collected in a session log that may include a session identifier, a user identifier, an action identifier, and when available, a content identifier indicating a content component/subcomponent or location of the content component/sub-component for which a particular action identified by the action identifier was carried out. In some cases, at least some of the collected data is directly stored in a document graph (which may be a same or different graph than that referred to with reference number <NUM>).

A client or server application (or software module) associated with (and/or in communication with) the productivity application <NUM> can access this collected data and perform a variety of processes on the data, such as an action classification process <NUM> and/or a user classification process <NUM>. In addition to action and actor/user classification processes that can be carried out, the client or server application (or software module) can perform document shredding. For example, service <NUM> can represent the service that carries out one, two, or all of processes <NUM>, <NUM>, <NUM> and <NUM> as well has handles certain queries of a document graph on behalf of the productivity application <NUM> (see e.g., processes <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> described with respect to <FIG> and <FIG>).

In a case where the processes for a labeler (the software instructions directing the system to perform processes <NUM>, <NUM> and <NUM>) are all performed at the service platform <NUM>, the session log collected at the computing device <NUM> can be communicated, as an action log <NUM>, to the service <NUM> for processing and appropriately writing to the document graph <NUM>. The communication of this information can be performed at designated times (e.g., upon a save action within the productivity application <NUM>, at the end of a user's session, once a day, every hour, etc.) or upon request of the service <NUM> performing the process <NUM>.

In a case where at least part of the action classification process <NUM> is performed at the client (as part of the productivity application <NUM> or as an add-on or separate application that can communicate with the productivity application <NUM>), the resulting normalized action <NUM> (e.g., after step <NUM>) can be communicated to the service <NUM> for writing to the document graph. In another such implementation, but where a local document graph (or partial graph) is maintained, or a synchronization message <NUM> (e.g., providing changes or updates) can be communicated to the service <NUM> for updating the document graph stored at the server platform <NUM> based on updates to the local document graph stored at the computing device <NUM>.

The user classification process <NUM> (and/or content classification process <NUM>) can be carried out at certain instances of time and stored in a manner that can be later retrieved, for example, by being written to the document graph <NUM>. The user classification process <NUM> may be carried out or the stored results retrieved in response to a request to classify one or more users, for example as part of a request <NUM> from application <NUM> to the service <NUM>. The roles or labels identified by mapping the normalized actions taken by a user to an actor class can be returned in response to the request (as response <NUM>) and/or written back into the document graph <NUM>. Similarly, the content classification process <NUM> may be carried out or the stored results retrieved in response to a request to classify one or more pieces of content, for example as part of a request <NUM> from application <NUM> to the service <NUM>. The roles or labels identified by mapping the normalized actions taken by users on a piece of content can be returned in response to the request (as response <NUM>) and/or written back into the document graph <NUM>.

<FIG> illustrate an example scenario of reuse of content within documents. Referring to <FIG>, at a client system <NUM> (which may be implemented on a computing system <NUM>, a first user may be working on a document P1 <NUM> in a productivity application <NUM>. The user may be logged in to the client system <NUM> such that the productivity application <NUM> associates the user's activities with the user. The user may then publish <NUM> the document P1 <NUM>. This step of publishing may be a specific command (e.g., to publish, to share, or to save to a particular location for sharing) or may be a function of the productivity application (with permission but without explicit command of the user). At the server system <NUM>, a copy of the document P1 <NUM> can be stored in a storage system <NUM> associated with, or accessible by, the server system <NUM> and a document graph <NUM> can be updated with a document node <NUM> representing the document P1 <NUM> connected to a user node <NUM> representing the user by action edge <NUM>.

Process <NUM> may have been carried out and the action classes labeled/written into the document graph. In response to receiving an indication that the document P1 has published, as a result of a programmatic initiation, or as part of a crawl of published documents, the reusable content components can be extracted from the document P1 <NUM>, for example, processes such as described with respect to process <NUM>. In the illustrated example, extraction operation <NUM> can extract reusable content components Obj1 <NUM>, Obj2 <NUM>, and Obj3 <NUM> and separately store these content components from document P1 <NUM>. The reusable content components Obj1 <NUM>, Obj2 <NUM>, and Obj3 <NUM> can be stored on a same or different storage system as the first document P1 <NUM>.

In some cases, even though the content components are separately stored, they can be synced to their counterparts in the source document or at least connected in a manner that if not included in another document, the content component can be deleted when the source document (e.g., document P1 <NUM>) is deleted. The sub-components of the reusable content components Obj1 <NUM>, Obj2 <NUM>, and Obj3 <NUM> can be represented in the document graph <NUM> as component nodes <NUM>, <NUM>, and <NUM>, respectively. Attributes corresponding to the content components' relationships with the document P1 can be associated with the edges between each of the component nodes <NUM>, <NUM>, and <NUM> and the document node <NUM>.

Although not shown in the drawing, in some implementations, each component node can also be connected to the user node <NUM> via an action edge.

A second user (or even the same user) can, via for example a productivity application, communicate with a service (that performed the extraction/indexing and/or labeling) to request reusable content components associated with a document. The process may be carried out as described with respect to process <NUM> (e.g., path K1-K2-K3). For example, as illustrated in <FIG>, a productivity application <NUM> at a client system <NUM> can request (<NUM>) from the service (such as available at service system <NUM>) a particular component type from a particular document (either specifically named or identified as most likely relevant to the request).

As illustrated in A, from a query for the search of the document graph, the service can identify ("hit") the node <NUM> representing document P1 of the document graph since this node <NUM> would meet the conditions indicating that it corresponds to the particular document named in the request. In some cases, the criteria involves the document name. In some cases, the criteria involves terms in a document description. In some cases, the criteria involves any document connected to a particular user (or a user having a particular label). Once at the document node <NUM>, the graph can be walked as shown in B to identify the component nodes <NUM>, <NUM>, and <NUM> connected to the document node <NUM> and determine whether one of the component nodes satisfies the requested component type. As illustrated in C, the component type for content component Obj1 is determined to satisfy the requested component type and the location (e.g., for retrieval) and/or attributes of the content component Obj1 can be provided in a response <NUM> to the request.

Advantageously, just the extracted content components may be returned to the application <NUM> for display, without the need for the application to download the entire document.

Since the second user (via application <NUM>) performed an action with respect to the content component Obj1, an action edge <NUM> can be established between a user node <NUM> representing the second user and the component node <NUM>, such as illustrated in <FIG>. Here, the action may be "view". In the case where the second user, after having received an indication from the productivity application <NUM> that content component Obj1 <NUM> satisfies the desired criteria, decides to include content component Obj1 <NUM> as part of her own document P2 <NUM>, the attribute assigned to an action edge (which may be a same edge or a different edge as action edge <NUM>) can be "insert" (or other defined label). In addition, a 'contains' edge <NUM> can be generated between the component node <NUM> and the second document node <NUM>, which is itself connected by action edge <NUM> to the user node <NUM> representing that user. In addition, as described with respect to <FIG>, a connection (not shown) may, in some cases, be made between the two user nodes <NUM>, <NUM>.

In some cases, the activity history of a document or a component (or subcomponent) of a document can also be queried via the indexing service. In some implementations, the activity history can be obtained by reading the normalized action(s) written to a document graph during process <NUM>. In some implementations, the content class identified from process <NUM> can be obtained during a search of the activity history.

<FIG> illustrates components of a computing device that may be used in certain implementations described herein; and <FIG> illustrates components of a computing system that may be used to implement certain methods and services described herein.

Referring to <FIG>, system <NUM> may represent a computing device such as, but not limited to, a personal computer, a reader, a mobile device, a personal digital assistant, a wearable computer, a smart phone, a tablet, a laptop computer (notebook or netbook), a gaming device or console, an entertainment device, a hybrid computer, a desktop computer, or a smart television. Accordingly, more or fewer elements described with respect to system <NUM> may be incorporated to implement a particular computing device.

System <NUM> includes a processing system <NUM> of one or more processors to transform or manipulate data according to the instructions of software <NUM> stored on a storage system <NUM>. Examples of processors of the processing system <NUM> include general purpose central processing units, application specific processors, and logic devices, as well as any other type of processing device, combinations, or variations thereof. The processing system <NUM> may be, or is included in, a system-on-chip (SoC) along with one or more other components such as network connectivity components, sensors, video display components.

The software <NUM> can include an operating system (OS) and application programs such as a productivity application <NUM> that can take advantage of the document storage for reuse of content within documents such as described herein.

Device OS generally control and coordinate the functions of the various components in the computing device, providing an easier way for applications to connect with lower level interfaces like the networking interface. Non-limiting examples of operating systems include Windows® from Microsoft Corp. , Apple® iOS™ from Apple, Inc. , Android® OS from Google, Inc. , and the Ubuntu variety of the Linux OS from Canonical. It should be noted that the OS may be implemented natively on the computing device and/or on software virtualization layers running atop the native device OS. Virtualized OS layers, while not depicted in <FIG>, can be thought of as additional, nested groupings within the operating system space, each containing an OS, application programs, and application programming interfaces (APIs).

Storage system <NUM> may comprise any computer readable storage media readable by the processing system <NUM> and capable of storing software <NUM> including the productivity application <NUM>. Storage system <NUM> may include 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. Examples of storage media of storage system <NUM> include random access memory, read only memory, magnetic disks, optical disks, CDs, DVDs, flash memory, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other suitable storage media. In no case does storage media consist of a propagated signal or carrier wave.

Storage system <NUM> may include additional elements, such as a controller, capable of communicating with processing system <NUM>.

The system can further include user interface system <NUM>, which may include input/output (I/O) devices and components that enable communication between a user and the system <NUM>. User interface system <NUM> can include input devices such as a mouse <NUM>, track pad (not shown), keyboard <NUM>, a touch device <NUM> for receiving a touch gesture from a user, a motion input device <NUM> for detecting non-touch gestures and other motions by a user, a microphone for detecting speech (not shown), and other types of input devices and their associated processing elements capable of receiving user input.

The user interface system <NUM> may also include output devices such as display screen(s) <NUM>, speakers (not shown), haptic devices for tactile feedback (not shown), and other types of output devices. In certain cases, the input and output devices may be combined in a single device, such as a touchscreen display which both depicts images and receives touch gesture input from the user. A touchscreen (which may be associated with or form part of the display) is an input device configured to detect the presence and location of a touch. The touchscreen may be a resistive touchscreen, a capacitive touchscreen, a surface acoustic wave touchscreen, an infrared touchscreen, an optical imaging touchscreen, a dispersive signal touchscreen, an acoustic pulse recognition touchscreen, or may utilize any other touchscreen technology. In some embodiments, the touchscreen is incorporated on top of a display as a transparent layer to enable a user to use one or more touches to interact with graphics or other information presented on the display.

Visual output may be depicted on the display <NUM> in myriad ways, presenting graphical user interface elements, text, images, video, notifications, virtual buttons, virtual keyboards, or any other type of information capable of being depicted in visual form.

The user interface system <NUM> may also include user interface software and associated software (e.g., for graphics chips and input devices) executed by the OS in support of the various user input and output devices. The associated software assists the OS in communicating user interface hardware events to application programs using defined mechanisms. The user interface system <NUM> including user interface software may support a graphical user interface, a natural user interface, or any other type of user interface. For example, the interfaces for the productivity application and/or the productivity tool for assisted collaborative content authoring (and corresponding functionality) described herein may be presented through user interface system <NUM>.

Communications interface <NUM> may include communications connections and devices that allow for communication with other computing systems over one or more communication networks (not shown). Examples of connections and devices that together allow for inter-system communication may include network interface cards, antennas, power amplifiers, RF circuitry, transceivers, and other communication circuitry. The connections and devices may communicate over communication media (such as metal, glass, air, or any other suitable communication media) to exchange communications with other computing systems or networks of systems. Transmissions to and from the communications interface are controlled by the OS, which informs applications of communications events when necessary.

Certain aspects described herein, such as those carried out at service platform <NUM> may be performed on a system such as shown in <FIG>. Referring to <FIG>, system <NUM> may be implemented within a single computing device or distributed across multiple computing devices or sub-systems that cooperate in executing program instructions. The system <NUM> can include one or more blade server devices, standalone server devices, personal computers, routers, hubs, switches, bridges, firewall devices, intrusion detection devices, mainframe computers, network-attached storage devices, and other types of computing devices. The system hardware can be configured according to any suitable computer architectures such as a Symmetric Multi-Processing (SMP) architecture or a Non-Uniform Memory Access (NUMA) architecture.

<FIG> illustrates components of a computing system that may be used to implement certain methods and services described herein The system <NUM> can include a processing system <NUM>, which may include one or more processors and/or other circuitry that retrieves and executes software <NUM> from storage system <NUM>. Processing system <NUM> may be implemented within a single processing device but may also be distributed across multiple processing devices or sub-systems that cooperate in executing program instructions.

Storage system(s) <NUM> can include any computer readable storage media readable by processing system <NUM> and capable of storing software <NUM>. Storage system <NUM> may include additional elements, such as a controller, capable of communicating with processing system <NUM>. Storage system <NUM> may also include storage devices and/or sub-systems on which data such as entity-related information is stored. As with the storage media of storage system <NUM>, storage media of storage system <NUM> do not consist of propagating signals or carrier waves.

Software <NUM> may be implemented in program instructions and among other functions may, when executed by system <NUM> in general or processing system <NUM> in particular, direct the system <NUM> or processing system <NUM> to operate as described herein for service <NUM>, including performing one or more of a document shredding process such as described with respect to <FIG>, an action classification process such as described with respect to <FIG>, a user classification process such as described with respect to <FIG>, a content classification process such as described with respect to <FIG>, or search processes such as described with respect to <FIG> and <FIG>.

System <NUM> may represent any computing system on which software <NUM> may be staged and from where software <NUM> may be distributed, transported, downloaded, or otherwise provided to yet another computing system for deployment and execution, or yet additional distribution.

In embodiments where the system <NUM> includes multiple computing devices, the server can include one or more communications networks that facilitate communication among the computing devices. For example, the one or more communications networks can include a local or wide area network that facilitates communication among the computing devices. One or more direct communication links can be included between the computing devices. In addition, in some cases, the computing devices can be installed at geographically distributed locations. In other cases, the multiple computing devices can be installed at a single geographic location, such as a server farm or an office.

A communication interface <NUM> may be included, providing communication connections and devices that allow for communication between system <NUM> and other computing systems (not shown) over a communication network or collection of networks (not shown) or the air.

Certain techniques set forth herein may be described in the general context of computer-executable instructions, such as program modules or processing steps, executed by one or more computing devices. Generally, program modules include routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types.

Alternatively, or in addition, the functionality, methods and processes described herein can be implemented, at least in part, by one or more hardware modules (or logic components). For example, the hardware modules can include, but are not limited to, application-specific integrated circuit (ASIC) chips, field programmable gate arrays (FPGAs), system-on-a-chip (SoC) systems, complex programmable logic devices (CPLDs) and other programmable logic devices now known or later developed. When the hardware modules are activated, the hardware modules perform the functionality, methods and processes included within the hardware modules.

Embodiments may be implemented as a computer process, a computing system, or as an article of manufacture, such as a computer program product or computer-readable medium. Certain methods and processes described herein can be embodied as software, code and/or data, which may be stored on one or more storage media. Certain embodiments of the invention contemplate the use of a machine in the form of a computer system within which a set of instructions, when executed, can cause the system to perform any one or more of the methodologies discussed above. Certain computer program products may be one or more computer-readable storage media readable by a computer system and encoding a computer program of instructions for executing a computer process.

Computer-readable media can be any available computer-readable storage media or communication media that can be accessed by the computer system.

Communication media include the media by which a communication signal containing, for example, computer-readable instructions, data structures, program modules, or other data, is transmitted from one system to another system. The communication media can include guided transmission media, such as cables and wires (e.g., fiber optic, coaxial, and the like), and wireless (unguided transmission) media, such as acoustic, electromagnetic, RF, microwave and infrared, that can propagate energy waves. Although described with respect to communication media, carrier waves and other propagating signals that may contain data usable by a computer system are not considered computer-readable "storage media.

Claim 1:
A system for reuse of content within documents (<NUM>), the system comprising:
one or more computer readable storage media;
a document graph stored on at least one of the one or more computer readable storage media; and
a labeler configured to at least:
aggregate, for a window of time (<NUM>), a plurality of actions carried out by a user on content associated with a document within a productivity application;
normalize the plurality of actions into at least one predefined action class;
determine a label of the user in relation to the document or a portion of the content associated with the document based on the at least one predefined action class; and
store the label associated with the user and the document or the portion of the content in a document graph;
the system further comprising a document shredder that is a module of software application that can deconstruct a document into reusable components (<NUM>, <NUM>, <NUM>), wherein the system is adapted to identify content component types within a document and replicate content components associated with the identified content component types and store the content components (<NUM>, <NUM>, <NUM>) separate from the document;
wherein the system is further adapted to index the content components (<NUM>, <NUM>, <NUM>) and represent the identified components as nodes (<NUM>) in the document graph that are connected to the document by edges;
wherein the system is further adapted to return, in response to a request for reusable content, a content component (<NUM>, <NUM>, <NUM>) the content component type of which satisfies the request without downloading the entire document (<NUM>).