阅读说明：本技术 跨文档的数据重用 (Cross-document data reuse ) 是由 R·希门尼斯萨尔加多 D·莫瓦特 A·巴尔策 M·沃尔夫 J·S·坎贝尔 S·奥德里斯科尔 于 2019-06-25 设计创作，主要内容包括：一种用于管理数据的技术包括：在数据存储库处接收由源应用生成的持久性数据对象,所述对象被配置为与多个应用和文档类型相兼容。所述对象与独有的标识符相关联。响应于对对象的请求,基于所述对象的独有的标识符来访问所述对象,并且将其发送给执行目的地应用的计算设备。所述对象被由目的地应用编辑的目的地文档合并并且与之相兼容。接收对所述对象的更新,所述更新是由编辑用户文档的用户应用生成的。响应于接收到所述对象已经被插入在所述目的地文档中的指示,由数据存储库向所述目的地计算设备发送更新,所述更新可以被用于更新被合并在所述目的地文档中的对象。(A technique for managing data includes: persistent data objects generated by a source application are received at a data store, the objects configured to be compatible with a plurality of applications and document types. The object is associated with a unique identifier. In response to a request for an object, the object is accessed based on the object's unique identifier and transmitted to a computing device executing a destination application. The object is merged and compatible with a destination document edited by a destination application. Receiving an update to the object, the update generated by a user application editing a user document. In response to receiving an indication that the object has been inserted in the destination document, sending, by a data store, an update to the destination computing device, the update usable to update the object incorporated in the destination document.)

1. A method for managing shared data, the method comprising:

receiving, at a data store, data generated by a source application;

storing the data as a persistent data object configured to be compatible with a plurality of applications and document types, wherein the persistent data object is associated with a unique identifier;

in response to a request for the persistent data object, accessing the persistent data object based on the unique identifier of the persistent data object;

sending the persistent data object to a computing device executing a destination application, wherein the persistent data object is merged by and compatible with a destination document edited by the destination application;

receiving an update to the persistent data object from a user computing device, the update generated by a user application editing a user document on the user computing device; and

in response to receiving an indication that the persistent data object has been inserted in the destination document by the destination computing device, sending, by the data store to the destination computing device, data indicating the update to the persistent data object, the data usable to update the persistent data object incorporated in the destination document.

2. The method of claim 1, wherein the persistent data object is associated with a category associated with logic operable to enable the destination computing device to present the data independent of a presentation capability of the destination application.

3. The method of claim 1, wherein the subset of persistent data objects is operable for insertion in the destination document.

4. The method of claim 1, further comprising: sending data indicative of the updated persistent data object to a plurality of devices, applications or documents that have merged or used the persistent data object prior to the update.

5. The method of claim 1, wherein the persistent data object is associated with a permission to enable access to the persistent data object.

6. The method of claim 1, wherein the update to the persistent data object is selectively sent to the destination computing device based at least in part on a property associated with the persistent data object.

7. The method of claim 1, wherein the persistent data object is further associated with metadata indicating a user authorized to view or edit the persistent data object.

8. The method of claim 1, further comprising providing the persistent data object in a flattened format.

9. The method of claim 1, wherein the destination document is automatically updated based on a user option when the persistent data object is updated.

10. The method of claim 1, wherein the destination document is prevented from being updated based on user options when the persistent data object is updated.

11. The method of claim 1, wherein the persistent data object is associated with a grouping mechanism, and wherein the persistent data object is associated with a shared attribute value that indicates to which group the persistent data object belongs.

12. A computing device, comprising:

one or more processors;

a memory in communication with the one or more processors, the memory having computer-readable instructions stored thereon that, when executed by the one or more processors, cause the computing device to:

inserting, by a destination application executing on the computing device, a persistent data object in a destination document edited by the destination application, wherein the persistent data object is configured to be compatible with a plurality of applications and document types;

receiving an update to the persistent data object, the update generated by a user application editing a user document on a user computing device; and

updating, by the destination application, the persistent data object inserted in the destination document in response to receiving the update to the persistent data object.

13. The computing device of claim 12, further comprising: allowing the destination application to lock on a particular time frame of an instance of information in the persistent data object, wherein the destination document does not receive an external update to the persistent data object.

14. The computing device of claim 12, wherein the destination application is configured to process the persistent data object to present a representation of the persistent data object, wherein the representation includes one or more of an author, a data/timestamp, a version, and a title, wherein the version includes multiple versions of the persistent data object, and wherein an option is provided to select one of the versions for incorporation into the destination document.

15. A computer-implemented method, comprising:

sending, by a source computing device executing a source application, a persistent data object edited by the source application to a data store, wherein the persistent data object is configured to be compatible with a plurality of applications and document types;

generating an update to the persistent data object; and

sending the update to the data store to the persistent data object, wherein the persistent data object is compatible with a document that has merged the persistent data object.

Background

Today's staff uses a variety of devices, software applications, and web-based services to accomplish many tasks. For example, a user may use a phone to capture data and record notes, and share information with colleagues using one or more applications and services. Users may use the same or different applications and services to process information and develop other work products during the course of a project using a telephone or another computing device.

Multiple documents may be generated and developed during the course of a project. Various versions of these documents may be generated. Finding past or present documents about a certain topic can be time consuming and difficult, if not impossible. In addition, certain portions of a document may be copied or cut and pasted into other documents for the same or different applications. If the original source of the copy is incorrect or updated later, all downstream users that copy the original source will have incorrect or outdated information.

Some systems provide the ability to insert or embed information into documents. However, such systems do not support the sharing of information or provide any way of updating the embedded information in a dynamic way that controls changes and in a way that enables easy sharing of information. Furthermore, users often use a variety of applications and devices, and some pieces of information must be modified or translated to be able to be presented or otherwise consumed by different applications and devices.

These drawbacks can be inconvenient for the user and result in serious inefficiencies in the utilization of computing resources. For example, opening and interacting with multiple applications to view and share relevant information about a particular context or topic may result in inefficient utilization of processor cycles, memory, battery power, and network bandwidth. Similarly, distributing outdated information can result in significant rework and delays due to manual updates, not to mention the cost of capturing erroneous pieces of information in the document. Furthermore, the inability to dynamically update pieces of information across devices and applications without human intervention can result in ineffective computer interaction, thereby increasing the frequency of inadvertent or erroneous user inputs, which in turn results in further inefficiency in the utilization of computing resources and loss of time and effort to achieve compatibility between users. Given these and other shortcomings, there remains a need for tools that can efficiently share, reuse, and update information in a dynamic manner.

The disclosure herein is presented with respect to these and other technical challenges.

Disclosure of Invention

The present disclosure describes various embodiments that enable the use of pieces or chunks of information (chunk) that can be shared and reused between users and documents, and that can evolve in form and content (e.g., via their metadata) as information evolves and perfects. As used herein, an information block may generally be defined as a collection of modifiable and reusable data that has associated metadata and that may be uniquely identified. The information blocks may be referred to herein as modular units of information or alternatively as Modern Units of Information (MUIs). The information blocks may also be referred to herein as persistent data objects. These terms may be used interchangeably.

Blocks of information can be used and reused because many relevant or branching documents, such as proposals, specifications, contracts, reports, presentations, media files (such as video/audio), etc., are generated and developed around the block. For example, a chunk can include Musical Instrument Digital Interface (MIDI) instructions, song lyrics, or a video title, and can be combined with other chunks to form a media file, such as a video file including lyrics. In various embodiments, methods and techniques are described that allow a branching document of consolidated information blocks to include references to underlying information blocks, where the blocks are automatically updated within the document as the underlying blocks evolve and change. By providing such a mechanism, more efficient and effective information authoring and sharing may be achieved. For example, such a mechanism may allow one author to perform financial analysis on a piece of information in a spreadsheet while another author may only wish to insert a summary of the analysis. The documents for each user may be automatically updated as the underlying information blocks change. As another example, while in some cases it may be desirable to dynamically update data, in some cases an author may wish to freeze data, for example, when generating an already published report in which the table that extracts data from the base block must be kept in sync with comments on the data that may reside only in the branch document. Various embodiments described herein enable such scenarios. Furthermore, since the same block reference can be embedded within each branching document, even if the actual information itself evolves over time, the branching document can be searched and found more efficiently.

In one embodiment, a local or web-based application may be implemented as a block management function. The block management functions may be incorporated into an application, operated as a stand-alone application, operated as a plug-in to an existing application, operated as remote (e.g., cloud-based) functions, or operated using a combination. The application itself may be a locally executed application or a web-based application.

In one embodiment, any portion of any document may be saved as a block. The block management function may be configured to receive input and write/read one or more data blocks to/from the shared storage device. The block management function may also be configured to automatically generate text, data, audio, and/or images based on block information and/or document information (such as from user input). A document file may be created or updated that contains references to instances of information stored in blocks in storage and contains other document information.

The block management function may also be configured to enable a user to update the content of the instances of the blocks. In addition, the block management function may be configured to allow a user to reopen a document containing references to one or more blocks of information maintained in the storage device. When the document is reopened, the latest updates to the chunk of information may be obtained and inserted in the relevant location in the document.

The tile function may automatically scan and monitor tile information when a document is opened, and provide the ability to define new tiles when requested by a user. An interface may be provided that indicates blocks in use in the document and also allows a user to identify and submit new blocks.

In some embodiments, the blocks may be accessible based on conditions. For example, a given chunk may be unconditionally available to authorized colleagues of the originator of the chunk, may be provided to some users for a fee, and may be provided to other users at a discounted price. In addition, different conditions may be applied to different versions of the block, for example, a paid version may be updated with some information, or some details may not be available for a free version (e.g., HD video with low resolution data). Blocks may also be provided with different update frequencies or times to publish information based on various payment or subscription plans.

In some embodiments, block references in a document file may be saved by generating a unique identifier for each information block. The block may be stored in a data store for storing block information and identifying the block. The block management function may identify the location in the document file where the block should be inserted, either implicitly by placing the block in a sequence after other identified content, or explicitly by specification of the document location of the block.

In some embodiments, access requirements for blocks may be implemented. The access requirements may be implemented by individual users or by groups. For example, the access requirements may be implemented for members of an organization, subscribers to a service, users having an identified relationship with authorized users, and so forth. In some embodiments, the chunk creator, rather than the document author, can publish updates to the chunk. For example, a block author may license a block and provide a different payment or subscription plan to receive updates, such as updates received by some documents being updated more frequently or earlier based on the license than other documents. The content of the block can be verified to establish trust, for example, by having an organization, company, community verify the block information and add a trusted source. The block or the entire block may be encrypted and include security features, such as DRM.

In some embodiments, the block management function may provide the ability to detect that additional items within a block are available. For example, new items in the reference list may be added and updated. The block management function may provide the user with the ability to view, select, and insert items from a list. The chunk management function may provide additional services, such as translating chunks and optionally storing translations in chunk metadata.

In some embodiments, the block management function may provide an Application Programming Interface (API) configured to receive requests for block information and document information and to respond to the requests. For example, the API may receive a request to retrieve all documents that contain a particular block. The block management function may search for documents having unique identifiers for the blocks and return a list of documents.

The techniques disclosed herein can improve user interaction with a computing device, which can increase productivity of the user and help reduce the number of inadvertent, outdated, or otherwise incorrect inputs. As such, by providing more accurate and more context-relevant information, the system is able to operate more efficiently with respect to memory usage, processing resources, network resources, and the like. Having more accurate and more contextually relevant data can reduce the number of emails and other forms of communication that can be used to clarify and correct incorrect information. Other technical effects besides those mentioned herein can also be achieved from the implementation of the techniques disclosed herein.

Drawings

The detailed description is described with reference to the accompanying drawings. The use of the same reference symbols in different drawings indicates similar or identical items. References to individual items of the plurality of items can use reference numbers with letters in a letter sequence to reference each individual item. A general reference to an item may use specific reference numerals without a letter sequence.

FIG. 1 illustrates a diagram illustrating the generation and use of blocks in accordance with various embodiments.

FIG. 2 illustrates an example table showing the contents of a block.

FIG. 3 illustrates an example table showing the contents of a block.

FIG. 4 illustrates an example table showing the contents of a block.

FIG. 5 illustrates an example table showing the contents of a block.

FIG. 6 illustrates a block diagram for identifying blocks and providing them to an application.

FIG. 7 illustrates a block diagram for identifying blocks and providing them to an organization.

FIG. 8 illustrates a block diagram for updating blocks.

FIG. 9 illustrates a block diagram for updating blocks.

FIG. 10 illustrates aspects of a routine for enabling aspects of the technology disclosed herein as shown and described below.

FIG. 11 illustrates aspects of a routine for enabling aspects of the technology disclosed herein as shown and described below.

FIG. 12 illustrates aspects of a routine for enabling aspects of the technology disclosed herein as shown and described below.

Fig. 13 is a computer architecture diagram illustrating an illustrative computer hardware and software architecture for a computing system capable of implementing aspects of the techniques and technologies presented herein.

Detailed Description

Systems and methods are described herein for generating and using blocks of data, causes, and information in formats and patterns that allow information to be reused or expanded in a variety of document types and applications. As used herein, an information block or block may be generally defined as a collection of modifiable and reusable data that has associated metadata and that may be uniquely identified. The blocks may also include other blocks. The information blocks may be referred to herein as persistent data objects. These terms may be used interchangeably. A block may include any type of data, such as text, graphics, tables, or any other type of information that may be inserted in any type of document (such as a word processing document, spreadsheet, presentation, etc.).

The information blocks disclosed herein may be configured to be created, stored, updated, sent and received as separate objects and inserted into a document. When inserted into a document, the information blocks are incorporated into the document because other information may be inserted into the document, such as in cut and paste or copy and paste operations. However, the inserted information blocks may continue to be identified and tracked independently. In other words, the information block exists independently of the document in which it is incorporated. In one embodiment, when the block of information is updated, whether within an inserted document or independently in another document that may be updated by an application executing in the same or a different computer, the update may be provided to all documents that have incorporated the block of information, regardless of document type and application. By providing such a mechanism, blocks of information can be used consistently without becoming obsolete or containing stale or erroneous information. Additionally, because the information block may be compatible with a variety of document types and applications, the block and its updates may be provided without regard to the particular type of document in which it resides. Furthermore, the identity of the information block can be tracked even if the content has been updated.

As an example, the user may generate a note in a to-do list application. The notes can then evolve into survey questions in an Excel spreadsheet, real-time surveys running in an application on an iPhone, and finally into survey results in a PowerPoint presentation. A portion of the note may be defined as a block, which may then be incorporated into an Excel spreadsheet, survey, and PowerPoint presentation. Various embodiments include mechanisms for tracking changes to blocks so that individual changes made to a particular block in an application can be applied anywhere the block is merged. In addition, changes may be made to other documents based on the corresponding document type and its respective applied attributes. In some embodiments, the blocks may optionally include or be associated with functionality/logic for intelligently responding to and/or securing edits. For example, the survey block can be configured to erase results when a question changes. The block may communicate with the display application to ensure that the application prompts the user whether to update the question and delete the result, or to retain the result and abandon the edit. Alternatively, the block may access or turn on the block management function to perform user prompts.

Thus, the disclosed embodiments provide a way for a user to make updates in one document or application that can be selectively reflected in the location of the blocks used in other documents or applications. Additionally, in some embodiments, the blocks may be associated with metadata such as data history and pattern history. This information can be used to track the history of the block and its revisions. In some embodiments, each application can have its supported schema, which can be declared or inferred from the context of the block.

For example, a to-do list application that can support a single text field in each block may present as a note "what the business opportunity size is, but may not be able to show" what the business opportunity size is: Small/Medium/Large "is correctly presented as a note, while a survey question list in Excel, which can support complex patterns and multiple fields, can show" what the business opportunity size is "in one column, and" Small/Medium/Large "in the next column. The survey application may also recognize that the "small/medium/large" field is actually a multi-response field, and a drop down menu may be presented to allow selection by the user.

In various embodiments, versioned data may be added to a block when the data in the block is updated or added, for example, by changing questions or by responding to surveys. Each application and document using the block may determine whether to incorporate new data and whether the application is capable of rendering the new data or older versions of data and, if so, aspects of the schema it is capable of supporting.

Additionally, the information blocks may be presented in a variety of ways independent of the particular presentation format, so long as the type of data can be presented. In some embodiments, a visualization platform may be implemented that provides various presentation capabilities, such as graphics and charts, that are capable of presenting information in chunks without requiring any particular application to naturally present the information.

In embodiments, the computing environment implementing the blocks may be implemented using one or more components. In one embodiment, the components may execute on the same physical computing device. In other embodiments, they may be distributed, for example, in a client-server architecture.

FIG. 1 illustrates a system 100 for enabling the generation, storage, and updating of blocks from multiple applications 141, and performing this operation while enabling a user to work within the context of each application 141. In this example, a user can interact with individual application 141 to create and edit documents, and view and add or edit block content inserted in a particular type of file (e.g., word processing document, spreadsheet document, etc.). The applications 141 may each be configured to display an authoring pane 191 and a tiles pane 192. The contents of each file are displayed in an authoring pane 191. The user can select the portion of the content displayed in the authoring pane 191. The selected portion can be selected as a block in block pane 192 for any application to create and save a new block. The block pane 192 may also be used to view available blocks for selection and insertion into an application. The tiles pane 192 for each application 141 may be synchronized to enable a user to work within each application 141 and view a current version of a document (e.g., a presentation) that is being edited while also viewing tile content that is specific to or available to each application.

The content in the block pane 192 can be used to generate block data 151 with content and metadata. In some configurations, block data 151 can be in the form of a table, a file, a multi-frame image file, a video file, or any other suitable format. In some embodiments, the block pane may display tabs or similar mechanisms for each revision so that the user can revert to an older or newer version. The block pane may also provide a mechanism for easily viewing differences between revisions.

In some embodiments, system 100 is capable of identifying or generating chunk data for use by multiple users and applications. For example, the computing device 106A or the storage service 110 and the management service 120 can identify chunk content and store the chunk content.

Block data 151 can include text, images, media, or any other form of data. Block data 151 can include data stored within storage service 110 including data store 136 and managed by management service 120 including management module 138. In some embodiments, tile data 152 can include visualization logic integrated or linked to tile data 151.

Block data 151 can be communicated from first computing device 106A or service 110 to any number of computing devices 106, referred to herein as computing devices 106B-106N, via network 108. Each computing device 106B-106N associated with a recipient is able to display block data 151 on user interface 195(195A-195N) through use of viewing application 142. The viewing application 142 can be any suitable application, such as a presentation program, a web browser, a media player, and the like. The viewing application 142 may also be a web-based application. In one embodiment, the viewing application 142 may be a virtual assistant that uses speech rather than visual representations to convey block content, e.g., to facilitate text-to-speech (TTS). In some embodiments, the viewing application 142 may be an augmented reality, mixed reality, or virtual reality device, and the blocks can be presented within a virtual reality display. For example, the blocks may represent sensor data that can be updated in the background. The blocks may represent, for example, virtual cars configured in a shopping scenario that are updated on the fly and displayed in a virtual city.

It should be appreciated that the subject matter described herein may be implemented as a computer-controlled apparatus, a computer process, a computing system, or as an article of manufacture such as a computer-readable storage medium. The techniques illustrated herein improve efficiency for various computing resources, as well as many other benefits. For example, human-machine interaction with a device may be improved because use of the techniques disclosed herein enables a user to view and edit data from multiple file types while operating in one application to compose blocks that include data from the files. In addition, the improved human-computer interaction improves other computing resources, such as processors and network resources, e.g., the user can work in a reduced number of applications, and reduces the user's computer interaction, reduces the chance of inadvertent input, reduces network traffic, and reduces computing cycles. The techniques disclosed herein reduce the need to download, launch, maintain updates to multiple applications (including dedicated presentation programs) and switch between multiple applications. As such, instead of requiring the user to copy and paste selected content into a specialized publishing or presentation program, existing computer designs are improved because all applications are synchronized and ultimately configured to increase the efficiency of the user's interaction. Other technical effects besides those mentioned herein can also be achieved from the implementation of the techniques disclosed herein.

In one embodiment, a storage service may be provided that is configured to manage and store blocks. In some embodiments, the blocks may be implemented using a data table. In one implementation, the data may have columns such as ID, title, author, and time date (TimeDate). Each row of the table may be an instance of an information block. For example, if Bob Smith makes a mental picture to get feedback about his sales and operations team, he can create three blocks, "confirm receipt", "is satisfied with the sales flow? "and" want to buy more? ". The three blocks may be associated with a name Bob Smith, a timestamp of the time and date the block was created, and each block may have a different unique ID. Fig. 2 illustrates an example table showing information about two blocks, each having: an ID, which may conform to a Globally Unique Identifier (GUID) scheme; a title for the block, which may be a text string; the author of the block, which may be a text string or some other identifier for the user; and the date/time the block was modified, which can be in date and time format.

In some embodiments, additional or different columns may be included. Examples of columns may include location, type, or purpose. Additionally, a column may contain files, such as images, videos, document fragments, or XML/HTML files. In some embodiments, the information block may contain multidimensional data. For example, a rank column may be included, which in turn may include sub-columns for counts of 1 star, 2 stars, and so on.

Multiple applications or services may read or write data in blocks and allow for modifications to the schema of the data. The term "application" may refer to any application, website, plug-in, SaaS service, and the like. The storage service may receive information from one or more applications configured to receive user or system input related to a chunk. For example, input may be received via sketchy notes, photographs, automated insights from data analytics, insights generated from IoT sensors, and so forth.

The storage service may be implemented remotely, such as on a server, or may be implemented on one or more devices. In some embodiments, the device providing the storage service may be separate from the device executing the application. The application may read and/or write data to the storage service over the network. In some implementations, the schema of the data can include a column containing a list of who has access rights. For example, the access rights may indicate that only authenticated users (such as bob smith @ content.com and fred jacoby @ content.com) may access the data. An API may also be exposed to allow users to request or retrieve relevant blocks, such as those that users may access or participate in due to sharing tasks or projects.

The blocks may be created and edited using any application capable of receiving user input and processing the input to generate or modify information related to units of information, such as files. In one example, a text editor, such as a note taking application on a smart phone, may be used to edit the blocks. Any number of more complex applications, such as Microsoft Excel, may also be used to edit the tiles. In an embodiment, the blocks may be saved in the storage service in a relatively simple form, even when modified using a more complex editing application.

In an embodiment, the application may be configured to allow a user to insert one of the blocks into the document file. For example, if Bob wishes to create a PowerPoint presentation titled "measure customer satisfaction," then Bob may open a slide with the title, and a second slide called a "suggested customer survey. Bob may then indicate to the application that he wishes to reuse the information blocks that Bob may access, for example by clicking a button in a user interface. In one embodiment, the application may provide a list of blocks that can be used for insertion. In some embodiments, the list may be ordered by a parameter (such as time, recency), or the list may provide an option to filter the list of tiles based on search query terms, date filtering, type, or other parameters.

Some embodiments may address the case where not all block types may work in all document types. For example, a relatively simple text editor may support block and basic text editing, and in such scenarios, no chart or picture may be provided as an option for insertion. In some embodiments, the application may filter those block types supported by the application. For example, if a tile supports multiple visualizations (e.g., text or graphics), the tile may be allowed to be inserted, but the available visualizations may be limited to those supported. In some embodiments, a block may be accessed for users who have subscribed to one or more blocks or who have paid to access the block. For example, the online store may pay to provide blocks and/or associated visualization logic. In some embodiments, an internal online store or repository may be provided for users within an organization or other entity. In a scenario inside an organization that is capable of mixing inner and outer blocks, the blocks may be constrained by administrative controls provided by the organization. In some embodiments, a block may have a permission mechanism associated with the block. For example, the application may check for permission requirements when attempting to refresh the document. The application may also check for permission-based access restrictions and other constraints.

In one embodiment, a column for blocks may be included that specifies the type of content supported, such as text, images, vector graphics, and so forth. In some embodiments, an alternative view of the same data block may be provided. For example, a block in an image format may be described by words or sounds in addition to being presented as an image. In some embodiments, the type of data block may be strictly defined. For example, "plain text" may be a simple type, and "average rating" may be a more complex type. A "pie chart" may be a subtype of a "chart". By providing strictly defined types, the visualization can be specialized. For example, a complex type of chart, such as an annotated 3D chart, may be presented highlighting statistically significant deviations, but may allow the application to fall back to simpler visualization (e.g., a pure bar graph), enabled by defining the "3D deviation chart" as a subtype of the "chart". Thus, when a user wants to change the visualization, the user can first be shown the relevant sub-type, parent type, or other relevant types.

Continuing with the example, Bob may choose to "be satisfied with the sales flow" two blocks? "and" want to buy more? "insert into customer survey slide. In further embodiments, the application may allow the user to update a given block, and the storage service may record a snapshot of the data as it changes. In the example shown in fig. 3, a column is included to indicate version control and access rights. In some embodiments, version control may be implemented in a non-linear manner. For example, different entities (such as users, hotspots, companies, and organizations) may require different versions of a block. In some embodiments, a block may be versioned using a tree or graph-like structure, where the block may generate multiple versions in parallel. Different branches/edges may represent different edits in parallel, resulting in versions or nodes of the same block being disconnected. Each version or node may be considered "up-to-date" in its representative sub-tree/sub-graph. For example, when determining the permission information, administrative tools may be provided to update only the blocks on individual sub-trees/sub-graphs. The management tool may also allow information to be fused into two different sub-trees/sub-graphs and new nodes to be created with the fused content. In addition, the management tool may allow a node to be overwritten with content from a previous node. When a block is composed of other blocks, the administrative tool may be used to replace a block within the block with a different block or remove the block. Each edit of a block may be a new version. Each block version may be uniquely identified with an ID. In one embodiment, the differences between blocks may be stored instead of, or in addition to, the blocks themselves. This may facilitate efficient tracking and checking of differences between versions, as well as saving storage space. In other embodiments, multiple full copies of various block versions may be stored. In one embodiment, a version may have a pointer to a previous version.

In some embodiments, a mechanism may be provided to resolve conflicts or simultaneous editing of blocks by different authors. In one embodiment, the dominant edit may be determined to be the last modified edit. In other embodiments, each of the conflicts or concurrent edits may be recorded, tracked, and made available. For example, if a user of a marketing function and a user of a research department each modify a column, each edit may have potential usability by a different end user. Thus, a mechanism may be provided in which a user may specify attributes that can determine which edits are to be provided to the user. For example, the user may wish to view the last edit by a marketer, or he or she may wish to view the last edit by a group of named individuals, or a central administrator may define rules for selecting edits that cannot be changed by the end user. Other ways may be provided to determine how conflicts or simultaneous edits may be selected.

In some embodiments, a mechanism may be provided that allows end users to associate attributes that determine which updates and updated versions are accessible to a given end user and/or a given application.

Information may be saved in the document file to link it to the information blocks. For example, the document file may include the following information:

in the example illustrated above, the second slide now contains a reference to the chunk store service. For example, the label "< information _ chunk id 1273893chunk _ version l.0> Happy with salts Process? </information chunk > "indicates the chunk identifier and version. Additionally, the tag references two older data chunks (version 1.0), which are then retrieved from the chunk store service and inserted into the document. In one embodiment, it may be assumed that the location of the storage service is known to the application attempting to open the document. For example, a Microsoft Office application may have built-in knowledge of URLs or other links to storage services of blocks available to the Microsoft Office application. Additionally, Microsoft Office applications may have built-in knowledge of the authentication method used to access the storage service. In other embodiments, the source may be explicitly declared as an attribute within the document file.

In some embodiments, the storage service may store a set of items that were originally authored as part of a coherent list. Examples may include an ordered set of photos, a set of tasks all placed on the same board, and a set of bullets (bullets) from a presentation slide. When information is used as a collection, the ability to group items in the collection is beneficial when reusing information in a block. Additionally, it may benefit by notifying the user of the collection of blocks when new items are added to the collection or when existing items in the collection are deleted.

In one embodiment, the grouping mechanism may be implemented in the storage service by having each row of information include a shared attribute value. For example, the shared attribute may be a parent location URL as shown in the example table in FIG. 4. The sharing attribute may also indicate an order, e.g., which item in the list is part of a given chunk.

In some embodiments, the granularity level of the blocks may vary. For example, each row of a list of blocks in a storage service may be a complete list or table, and an author (or other user) may be provided with a way to retrieve certain items from each block. Although blocks may be retrieved, references in the document in which the blocks are inserted may refer to block entries, rather than the blocks themselves, as shown in the following example.

<body>

<format bullets＝true>

<information_chunk id＝1273893chunk_version＝1.0items＝all>

<p>Happy with Sales Process？</p>

<p>Likely to buy more？</information chunk></p>

</information_chunk>

</format>

</body>

In an embodiment, an application capable of processing a document file is capable of performing an operation when the document is reopened. For example, an application may be running on a computer device that is unable to connect to a storage service (which may be referred to as "offline support") over a network. In this case, the application is still able to read a static copy of the information from the document file, so that the application can display the version of the block saved in the document. In one example, the reason storage services are not available is: a different user who has not been authorized to access the storage service has opened the application. In some embodiments, the application may display "the document contains real-time information blocks, for example, by rendering. To view the latest version, please click on the notification bar here to request access "to provide notification to the user. In response to clicking on the request, the user may be taken to a different application or web page where they can request access control to a storage service.

In one embodiment, if a user does not have access to online data, restrictions may be implemented to restrict the unauthorized user from being allowed to view the data also offline. In some embodiments, access rights to the data may be included as one of the items optionally stored with the block. If access is insufficient, access rights may be implemented to prevent display of the content. In some implementations, IRM or DRM may be applied to the inline content of a block to ensure that the user does not otherwise intrude into the document to access the content. In some embodiments, the block content may be encrypted. Additionally, the IRM or DRM mechanism may be inherited or transferred when a block or portion of a block is shared or forwarded. When printing or copying (e.g., screen-capturing) blocks, other methods, such as watermarking, may be implemented for visual or audio files. In some embodiments, block content may not be included in the document, such that missing block content would result in the content in the document being lost without online access. For example, if access to data is a concern, ensuring that access control is satisfied by an authenticated user retrieving data from a server can be ensured. Additionally, a record of the access can be captured and stored.

When an application user does have access to the storage service or at least the required blocks, the application may send a request to the storage service to query whether a newer version of the block is available, or whether an item from the same location has been added or removed. In some embodiments, the application may provide a prompt to the user asking if he wishes to update his document so that it contains all the latest versions of any inserted blocks. In other embodiments, the document may be refreshed automatically. In some embodiments, the device or application may continuously or periodically poll the remote data store for any updates. In one embodiment, the device or application may notify the storage service when it opens and closes the document, and which blocks it contains, so that the storage service can send updates when they occur if the document is opened. In still other embodiments, the user may explicitly set the properties so that the document is not automatically refreshed for other users or based on other conditions. For example, if a published report references demographic data for a given quarter, a user may not wish to open a document after one year in which the demographic data has changed significantly. The findings in the report, which may be a multi-page text publication, may falsely reference observations about demographic data that was valid a year ago but is no longer valid for the latest (latest version) demographic data. In still other embodiments, textual analysis may be performed on the document to identify where the document references blocks of older versions so that those portions of the document may be highlighted for user revision.

In embodiments, the application may be configured to allow a user to directly edit a block within the application. Even in cases where the context of the usage information may be different, blocks edited within one application may be used across multiple applications and in multiple documents. In some embodiments, edits made to a block using one application may be applied to other applications and documents. Where a change is not applicable, a feature may be implemented to limit or prevent the propagation of the change. For example, if the block is a presentation slide that outlines sales for a quarter (and is used in multiple presentations across an organization), the block may have meaning within that context, and updates may be propagated. In another example, if the block is a table containing survey results, such as a percentage of visitors who agree on a set of questions, the table is also meaningful for reuse. If the differences between versions of the block are a small number of recitations of sentences, it makes sense to apply edits across the document using the block.

When a block is edited, additional properties may be added to the columns associated with the block. For example, as shown in the example of FIG. 5, Fred may translate the notion of a customer service bulletin into a customer survey (note that the author, modified, access rights, and parent location are removed for brevity).

In some cases, older documents may have blocks that are locked to a particular version, so that some data is not updated in the document having the locked blocks. The example in fig. 5 shows that "sales process satisfaction" includes two versions 1.0 and 1.1. This may be useful when the document is historical and is intended to include information from some point in time that is not being updated. When the latest changes are made to the block, the changes may not be applied to the locked data in older or historic documents. In one embodiment, a mechanism may be implemented that is configured to receive updates to the blocks and bypass documents that have merged blocks but are "frozen". In one embodiment, only data from external sources may be frozen. In another embodiment, a mechanism may be implemented to access previous versions for updates. In further embodiments, a mechanism may be provided to save updates to all old copies.

In one embodiment, a mechanism may be implemented that determines whether an update is important based on one or more factors that can be defined by a user of the block. Unimportant updates can be bypassed or otherwise considered unnecessary updates for a particular instance of the block. For example, the user may be prompted to select whether the update should be propagated. Additionally, a mechanism may be implemented to allow updates to be disabled, for example, where changes to historical legal documents may be prohibited. In one embodiment, the application may show all usage of blocks in any version thereof and allow approval to update every "version/document" pair used in the document.

In the example above, additional columns may be added to capture how the user responds to the survey. The type of information can evolve from a simpler or linear representation to a more complex representation. In some implementations, sub-types may be generated and included in the chunk, such as "survey/customer satisfaction" (as opposed to "survey/lunch options" or "survey/perfect vote"). Thus, semantic annotations may be used to provide visualization.

In some examples detailed herein, the original content of the block is the "topic" and the new content may be directed to the problem. In other examples, the original content may be context neutral, but the new list content may be context specific. In this way, the application or survey may use various heuristics to determine whether explicit input from the user is requested before applying the update, or whether the update should be applied automatically. For example, heuristics may include, but are not limited to: the previous and subsequent character edit distances, whether the type of block has changed, the number of items added, whether the block is purely numeric, whether the change is an updated photo file, whether the block is a presentation slide, whether the block introduces a large number of new columns, whether the semantic type of the block is considered similar to what has been used in the document, whether a converter exists to modify the latest block type (e.g., survey) to the type present in the document (e.g., simplex), whether the block includes only data retrieved from a connection with an external source (e.g., SQL database or website, etc.). In an embodiment, a mechanism may be provided in which a third party is able to sign and lock a block and thus prevent others (possibly including the owner of the block) from making changes to it. Additionally, the metadata may be modified to indicate that the block or its particular content has been changed.

In one embodiment, the following sequence for updating a block may be implemented: when a user updates a block in the context of a document (or an application), the data may always be saved in storage. When a second document referencing blocks is launched or a second application reading data from blocks is launched, or in the case of a coauthored document, when an update is detected, it may be determined whether (1) to update a block in the document to automatically use the latest version of the block, or (2) to notify the user that a change that the user may wish to accept has been made, and whether to accept or ignore the change.

Not all applications may support providing notification to the user that the block is updated. For example, a simple phone application that includes note taking functionality may not be configured to provide a notification platform. Additionally, not all applications may contain logic that can determine which version of a block to use. In such a case, the computational logic to determine which version of the block to provide to a particular device or application may be executed on a server, which may be network connected to or co-located with the storage. This may allow the phone application and its interface with the storage service to remain relatively simple. For example, the application may simply perform the task of reading/writing the list. The complex tasks of converting and processing updates may be performed on the server. The server may be configured to perform the update process in a variety of scenarios not limited to telephony applications.

Where blocks are stored in a storage service separate from individual user devices, the blocks may be exposed to a wider range of applications and users. In some embodiments, users and applications can query the storage service for relevant blocks. For example, blocks created in the same parent location or blocks created by the same author in a given time frame may be queried and retrieved. In such a case, the input parameters may be provided by the application or user, and the results may be filtered for direct matching. As the use of blocks increases, a block retrieval mechanism may be implemented that may incorporate search engine technology, where queries such as "show me all recently authored or updated blocks containing the keyword ' customer" may rely on standard Information Retrieval (IR) practices to find those blocks containing a large number of references to the keyword ' customer '. In this way, the query may return the results of the ranking by assigning a sub-score for how recent the authored block was, and another sub-score for the number of times the block contains "clients". The two sub-scores may be combined (e.g., summed) to calculate how relevant a given block is. For example, other scenarios (such as the frequency with which a given chunk is reused, and whether the chunk is reused by a known contact or within an organization or team) may be additional factors for ranking query results for chunks. More generally, the chunk store and management service may be integrated with a query engine (e.g., a search crawler for enterprise search scenarios, or a database-like query for programmatic queries). In some embodiments, visualization logic associated with a block or other function can be configured to convert any type of rich metadata into plain text to facilitate free text searches. Additionally, in conjunction with a search for tiles, the user may be provided with the ability to select tiles and a list of similar tiles. In some embodiments, the list may be biased using a determined relevance based on social networking data, previous searches, current applications, and other factors. Blocks may be indexed to facilitate searching.

In various embodiments, a mechanism may be provided to present the information blocks. The blocks may be presented in the context of an application or independent of an application. For example, chunks from a chunk store service may be queried and presented for inspection, or chunks may be inspected within an application.

In some embodiments, the application may be configured to present the information block. A block may be presented based on the type of information it contains and the properties of the block indicated by its metadata, which can be used to determine how to present the information. Some metadata associated with the chunk (e.g., author, time date, version, parent location, item, etc.) may not affect the manner in which the information is presented in the document. Other attributes, such as title or associated image file, may be used for presentation. For example, regardless of where in the document the user inserted the block, the application may render the text as plain text or may render the image within the document. If the original application (e.g., a phone note taking application) is restarted, the original application may use the block(s) directly and there is no document content around the block. The application may also present the blocks as text with metadata. In some embodiments, a mechanism or interface for changing between versions may be provided.

In some embodiments, visualization mechanisms for viewing, editing, and otherwise accessing tiles may be incorporated into the application. Alternatively or additionally, the visualization mechanism may be implemented as a standalone application or process. In some embodiments, the chunk may include or be linked to logic that enables an application to present chunk information without requiring pre-existing functionality locally in the application or on the user device. In some embodiments, the logic may be configured to allow visualization of the content of the chunk. In one embodiment, the logic can provide a basic visualization for an application that is not configured to otherwise visualize the content of the chunk.

The associated chunk visualization logic may be implemented as code capable of running at the user device or storage service when visualization is needed. For example, if the data in the chunk is a table and the local device is attempting to visualize the table using a notepad, the table may be presented using the logic provided for the chunk. The logic may be co-located with the blocks at a storage service or available for download to a user device. Otherwise, the notepad application may use its limited presentation functionality to present the table. For example, the contents of the table may be presented as a list with delimiters.

To facilitate implementation of blocks in various applications, the applications may conform to standard interfaces for implementing various techniques described herein. The standard interfaces may include a set of rules and interfaces that each application must adhere to in order to be able to use the block regardless of its original application and context. In some embodiments, a plug-in may be implemented that incorporates visualization and tile management functionality, and is enabled for use in enabling applications to use tiles within their documents.

In some embodiments, an application may overlay a base representation provided by associated logic for a block. For example, the application may invoke another application to render the block data, such as a browser. The chunk information may then be presented using a browser according to the functionality of the browser. Thus, the application that is using the tile may rely on a browser or other application to render the tile for visualization by the user.

The logic may provide various functions such as version control and support for editing blocks. Further, the logic may provide visualization capabilities to the user and provide input regarding the use of tiles. For example, when the originator of a chunk changes the data in the chunk, a notification of the change may be provided to the current user, and a choice of whether to merge the change may also be provided. Additionally, a notification of changes in the visualization logic may be provided to the current user, and an option of whether to update the visualization logic may also be provided.

In some embodiments, the logic may be associated with a category to which the block belongs. For example, various categories of chunks may be defined, such as a "table _ chunk" category for chunks in documents that have information in tabular form and are intended for use in including tables. The categories and their associated logic may define core representations for the categories. In some embodiments, the logic may be stored with the blocks at a storage service. The logic may be sent with the block when requested by an application. In other embodiments, the logic for the various categories may be stored at another location, such as at a primary storage location for the chunk visualization logic. In some embodiments, logic for various block categories may be obtained via a URL. In one embodiment, a user may define and submit their own chunk types through, for example, an online store or other centralized repository.

When the logic for the various chunk categories is predefined and available for download and use, the logic need not be generated when the chunks are generated. The originating application only needs to generate metadata for the instance, such as title, type of information in the chunk, who can access the chunk, author, time/date stamp, category, and how the category is presented (e.g., from where to fetch the logic). In some embodiments, in addition to the category-specific logic, block-specific logic may be available. For example, category-specific logic for a table may be overridden for a particular table. In one embodiment, this can be accomplished by applying basic display logic and layering on the custom logic, or just applying custom logic. There may be some applications that do not support the custom logic, in which case the logic can fall back to the default logic for that block type or category. The customization logic may also provide other visualization options, such as those described herein. In some embodiments, multiple sets of logic may be associated with tiles that specify different visualizations or different ways to edit the tiles.

In some embodiments, the user may be presented with a variety of available visualization options. Each visualization option may have its own logic and is capable of processing data for a chunk and generating a presentation. The type of presentation can be plain text, plain graphics, and any other type or combination of presentations. In some embodiments, a purely graphics-oriented application may be capable of rendering various block types. For example, a drawing application may be able to graphically present a form even though editing functionality may not be provided. In some embodiments, the visualization logic may define how tiles are presented if other tiles are also present in the document.

In some embodiments, a ranked list of visualizations may be provided, e.g., a list of the most popular visualization options. The list may be provided as a text presentation. In another example, a graphical output may be generated that shows an animation depicting a carousel with the most popular visualizations. In one embodiment, each visualization in the list may have a preview of the type of presentation to be provided with that visualization, which the user may select.

In an embodiment, the list may be selected or prioritized based on one or more factors, including:

which visualization was last used to render the tile

What is the strong type of the block

Which visualizations are related to the type (in whole or in part)

Which visualizations a user has permitted

In some embodiments, the user may be provided with the ability to filter visualizations based on capabilities (e.g., editing versus read-only, black-and-white versus color themes).

In some scenarios, only visualizations available in an application (e.g., notepad) can facilitate presentation of information, but not editing of information. For example, a star rating can be shown, but since its data includes a list of all previously submitted ratings, and its total is averaged, the user may not be able to edit the data in the notepad without losing the underlying rating data. In such a scenario, the application may notify the user that a given block of data cannot be edited by the user, or that editing will result in data loss. Alternatively, the application may disallow editing of the block without explicit notification (e.g., editing functionality may be disabled). FIG. 6 illustrates a block diagram 600 for identifying blocks, storing the blocks, and providing the blocks to an application. In some embodiments, chunk source 601 may include documents, emails, spreadsheets, presentations, graphic files, and the like. These documents may be accessed by block recognition engine 602 via a network. Chunk identifying engine 602 may receive chunks that include metadata associated with the chunks to associate the chunks with the metadata and related rendering logic. In some embodiments, the blocks may be stored in a block store 604, which block store 604 may be implemented by a storage service as discussed herein.

In some embodiments, the blocks stored in block store 604 may be retrieved by a software application, such as presentation software 606 or word processor 608. These applications may be configured to include authoring panes 610 and 614 in which the main document content is displayed. Applications 606 and 608 may also include block plug-ins 612 and 616. In some embodiments, the chunk plug-in may receive the chunk and insert portions of the chunk information in the document edited by applications 606 and 608 and displayed in authoring panes 610 and 614. In other embodiments, the functionality provided by the plug-in may be included in the functionality of the application.

FIG. 7 illustrates a block diagram 700 for generating, storing, and reusing blocks in connection with a team or organization 706. In some embodiments, chunk identification engine 602 receives pending chunks from collaboration server 716, email server 714, cloud document server 716, and so on. In some embodiments, the blocks stored on these servers are associated with an organization 706. This enables identification of blocks that are unique to the organization 706.

For example, collaboration server 716 may store slide presentations, spreadsheets, word processing documents, emails, calendar appointments, and the like. In some embodiments, chunk identifying engine 602 may access to retrieve documents stored in collaboration server 716. Additionally or alternatively, collaboration server 716 may provide the stored documents to chunk identifying engine 602. Chunk identifying engine 602 may also be implemented as a plug-in executing within collaboration server 716.

The block identification engine 602 may similarly receive an article from the email server 714. These articles may include emails, attachments, or any other type of document.

In some embodiments, although cloud document server 716 physically exists outside of organization 706, documents contained thereon may still be considered part of the organization.

FIG. 8 illustrates a block diagram 800 showing how various users update blocks and provide the updates to the users. In some embodiments, chunk identifying engine 602 is configured to track chunks 850 inserted into documents 801, 802, 804, and 807. These documents have associated users 808, 810, 812, and 816.

In some embodiments, as document 802, document 804, and document 806 are updated, the updates may be received by chunk recognition engine 602 as their respective inserted chunks 850 are updated, and document 802, document 804, and document 806 may each be notified of any updates to the chunks and/or their associated visualization logic. In this example, the document 804 associated with the user 810 may not be currently in use. However, block identification engine 602 may track updates to block 850, and when document 804 is later opened, block identification engine 602 may send the accumulated updates to document 804.

Fig. 9 illustrates a document-based application 900 that includes a tile visualization pane 940 for tiles inserted in the document. In one embodiment, applications 900 execute on computing device 902 and include document-based applications including menu 910, document authoring pane 990, and tile visualization pane 940.

Block visualization pane 940 lists three blocks found in the document: block 1942, block 2949, and block 3952, where the arrows associate the blocks with one or more instances of the blocks being used in the document.

FIG. 10 illustrates aspects of a routine 1000 for implementing aspects of the technology disclosed herein as shown and described below. It should be understood that the operations of the methods disclosed herein are not presented in any particular order, and that performing some or all of the operations in an alternative order(s) is possible and contemplated. Operations have been presented in a presentation order for ease of description and illustration. Operations may be added, omitted, and/or performed simultaneously without departing from the scope of the appended claims.

It should also be understood that the illustrated method can end at any time and need not be performed in its entirety. Some or all operations of a method and/or substantially equivalent operations can be performed by execution of computer readable instructions included on a computer storage medium, as defined below. The term "computer readable instructions," and variants thereof, as used in the description and claims, is used broadly herein to include routines, applications, application modules, program modules, programs, components, data structures, algorithms, and the like. Computer-readable instructions can be implemented on various system configurations, including single-processor or multiprocessor systems, minicomputers, mainframe computers, personal computers, hand-held computing devices, microprocessor-based, programmable consumer electronics, combinations thereof, and the like.

Thus, it should be understood that the logical operations described herein are implemented as: (1) as a series of computer implemented acts or program modules running on a computing system, and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance and other requirements of the computing system. Accordingly, the logical operations described herein are referred to variously as states, operations, structural devices, acts, or modules. These operations, structural devices, acts and modules may be implemented in software, in firmware, in special purpose digital logic, and any combination thereof.

For example, the operations of routine 1000 are described herein as being implemented at least in part by a module running features disclosed herein, and can be a Dynamically Linked Library (DLL), a statically linked library, a function produced by an Application Programming Interface (API), a compiled program, an interpreted program, a script, or any other set of executable instructions. The data can be stored in data structures in one or more memory components. Data can be retrieved from a data structure by addressing a link or reference to the data structure.

Although the following illustration refers to components of the drawings, it can be appreciated that the operations of the routine 1000 may be implemented in many other ways. For example, the routine 1000 may be implemented at least in part by a processor of another remote computer or local circuitry. Additionally, one or more of the operations of the routine 1000 may alternatively or additionally be implemented at least in part by a chipset that operates alone or in combination with other software modules. In the examples described below, one or more modules of a computing system are capable of receiving and/or processing the data disclosed herein. Any service, circuit, or application suitable for providing the techniques disclosed herein can be used for the operations described herein.

For example, the operations in fig. 10 can be performed by the computing device 1300 of fig. 13, as described above with reference to any of fig. 1-9.

At operation 1001, data generated by a source application is received at a data store.

At operation 1003, the data is stored as a persistent data object configured to be compatible with a plurality of applications and document types. In an embodiment, the persistent data object is associated with a unique identifier.

At operation 1005, in response to the request for the persistent data object, the persistent data object is accessed based on the unique identifier of the persistent data object.

At operation 1007, the persistent data object is sent to a computing device executing the destination application. In an embodiment, the persistent data object is merged and compatible with a destination document edited by a destination application.

At operation 1009, an update to the persistent data object is received from the user computing device. In an embodiment, the update is generated by a user application editing a user document on the user computing device.

At operation 1011, in response to receiving an indication that the persistent data object has been inserted in the destination document by the destination computing device, the data store sends data representing the update to the persistent data object to the destination computing device. In an embodiment, the data can be used to update the persistent data object as incorporated in the destination document. In some embodiments, at least the data of the updated persistent data object may be sent to multiple devices, applications, or documents that have merged or used the persistent data object prior to the update.

In some embodiments, the persistent data object is associated with a category. The categories may be associated with logic operable to enable the destination computing device to present data independent of a presentation capability of a destination application.

In some embodiments, the subset of persistent data objects is operable to be inserted in the destination document.

In some embodiments, data indicative of an updated persistent data object is sent to a plurality of devices, applications, or documents that have merged or used the persistent data object prior to the update.

In some embodiments, the persistent data object is associated with a permission to enable access to the persistent data object.

In some embodiments, the data store may be configured to store persistent data objects from multiple sources.

In some embodiments, the persistent data object may also be associated with metadata indicating one or more of an author, a data/timestamp, a version, and a title. The persistent data object may also be associated with metadata indicating users authorized to view or edit the persistent data object. In embodiments, the persistent data objects may be stored as a table, each row of the table corresponding to one of the persistent data objects.

In some embodiments, updates to the persistent data object are selectively sent to the destination computing device based at least in part on attributes associated with the persistent data object.

In some embodiments, the destination document may be automatically updated when the persistent data object is updated. The destination document may be automatically updated based on user options. In some embodiments, a notification may be provided when the persistent data object is updated.

In some embodiments, the persistent data object may be associated with a grouping mechanism. Additionally, the persistent data object may be associated with a shared attribute value that indicates which group the persistent data object belongs to.

In some embodiments, the persistent data object is provided for an application in a flattened format. For example, the application may not support complex data formats.

In some embodiments, when the persistent data object is updated, updating the destination document based on a user selection is prevented.

In some embodiments, the persistent data object is further associated with metadata indicating users authorized to view or edit the persistent data object.

FIG. 11 illustrates aspects of a routine 1100 for implementing aspects of the technology disclosed herein as shown and described below. For example, the operations of fig. 11 can be performed by the computing device 1300 of fig. 13, as described above with respect to any of fig. 1-9.

At operation 1101, a persistent data object may be inserted by a destination application executing on a computing device in a destination document edited by the destination application. In an embodiment, the persistent data object may be configured to be compatible with a plurality of applications and document types.

At operation 1103, an update to the persistent data object is received. In an embodiment, the update may be generated by a user application editing a user document on a user computing device.

At operation 1105, the persistent data object inserted in the destination document may be updated by the destination application in response to receiving the update to the persistent data object.

In some embodiments, the persistent data object may be received from a data store configured to store persistent data objects from a plurality of sources. The persistent data object may be initially generated by a source application running on a source computing device. Additionally, the generated persistent data object may be sent to a remote data store configured to store a plurality of persistent data objects.

In some embodiments, the destination application may be configured to process the persistent data object to present a representation of the persistent data object. The representation may include one or more of an author, a data/time stamp, a version, and a title. Additionally, the versions may include multiple versions of the persistent data object, and wherein an option is provided to select one of the versions for incorporation into the destination document.

In some embodiments, the destination application is allowed to lock a particular time frame of an instance of information in the persistent data object. Additionally, the destination document may not receive external updates to the persistent data object.

FIG. 12 illustrates aspects of a routine 1200 for implementing aspects of the technology disclosed herein as shown and described below. For example, the operations in fig. 12 may be performed by computing device 1300 of fig. 13, as described above with respect to any of fig. 1-9.

At operation 1201, a persistent data object edited by a source application is sent to a data store by a source computing device executing the source application. In embodiments, the persistent data object may be configured to be compatible with a variety of applications and document types.

At operation 1203, an update to the persistent data object is generated.

At operation 1205, the update to the persistent data object may be sent to the data store. In an embodiment, the persistent data object may be compatible with a document that has merged the persistent data object.

In an embodiment, the update may be maintained as a version of the persistent data object and access rights to the version of the persistent data object may be applied.

Fig. 13 illustrates additional details of an exemplary computer architecture 1300 for a computer, such as a computing device capable of executing the execution block management functions 1380 and block visualization logic 1390 (fig. 13) of the program components described herein. Thus, the computer architecture 1300 illustrated in fig. 13 illustrates an architecture for a server computer, mobile phone, PDA, smartphone, desktop computer, netbook computer, tablet computer, and/or laptop computer. Any aspect of the software components presented herein may be performed with computer architecture 1300.

The computer architecture 1300 illustrated in FIG. 13 includes a central processing unit 1302 ("CPU"), a system memory 1304 (including a random access memory 13013 ("RAM") and a read-only memory ("ROM") 13013), and a system bus 1310 that couples the memory 1304 to the CPU 1302. A basic input/output system containing the basic routines that help to transfer information between elements within the computer architecture 1300, such as during start-up, is stored in the ROM 1306. The computer architecture 1300 also includes a mass storage device 1312 for storing an operating system 1307. The mass storage device 1312 may also include tile visualization logic 1390 and tile management functionality 1380, which includes some or all aspects of tile visualization functionality as disclosed herein and tile management functionality as disclosed herein.

The mass storage device 1312 is connected to the CPU 1302 through a mass storage controller (not shown) connected to the bus 1310. The mass storage device 1312 and its associated computer-readable media provide non-volatile storage for the computer architecture 1300. Although the description of computer-readable media contained herein refers to a mass storage device, such as a solid state drive, hard disk, or CD-ROM drive, it should be appreciated by those skilled in the art that computer-readable media can be any available computer storage media or communication media that can be accessed by the computer architecture 1300.

Communication media includes 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 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.

By way of example, and not limitation, computer storage media 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. For example, computer media include, but are not limited to: computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, digital versatile disks ("DVD"), HD-DVD, BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer architecture 1300. For the purposes of the claims, the phrases "computer storage medium," "computer-readable storage medium," and variations thereof, do not include waves, signals, and/or other transitory and/or intangible communication media, per se.

According to various configurations, the computer architecture 1300 may operate in a networked environment using logical connections to remote computers through the network 1310 and/or another network (not shown). The computer architecture 1300 may connect to the network 1310 through a network interface unit 1314 connected to the bus 1310. It should be appreciated that the network interface unit 1314 may also be utilized to connect to other types of networks and remote computer systems. The computer architecture 1300 may also include an input/output controller 1313 for receiving and processing input from a number of other devices, including a keyboard, mouse, or electronic stylus (not shown in FIG. 13). Similarly, the input/output controller 1313 may provide output to a display screen, a printer, or other type of output device (also not shown in FIG. 13).

It should be appreciated that the software components described herein may, when loaded into CPU 1302 and executed, transform CPU 1302 and overall computer architecture 1300 from a general-purpose computing system into a special-purpose computing system customized to facilitate the functionality presented herein. CPU 1302 may be comprised of any number of transistors or other discrete circuit elements that may individually or collectively assume any number of states. More specifically, CPU 1302 may operate as a finite state machine in response to executable instructions contained within the software modules disclosed herein. These computer-executable instructions may transform CPU 1302 by specifying how CPU 1302 transitions between states, thereby transforming the transistors or other discrete hardware elements that make up CPU 1302.

Encoding the software modules presented herein may also transform the physical structure of the computer-readable media presented herein. The particular transformation of physical structure may depend on various factors, in different implementations of this description. Examples of such factors may include, but are not limited to, the technology used to implement the computer-readable medium, whether the computer-readable medium is characterized as primary or secondary storage, and so forth. For example, if the computer-readable medium is implemented as semiconductor-based memory, the software disclosed herein may be encoded on the computer-readable medium by transforming the physical state of the semiconductor memory. For example, the software may transform the state of transistors, capacitors, and/or other discrete circuit elements that make up the semiconductor memory. The software may also transform the physical state of such components in order to store data thereon.

As another example, the computer-readable media disclosed herein may be implemented using magnetic or optical technology. In such implementations, the software presented herein may transform the physical state of magnetic or optical media when the software is encoded therein. These transformations may include altering the magnetic properties of particular locations within a given magnetic medium. These transformations may also include altering the physical features or characteristics of particular locations within a given optical medium to change the optical characteristics of those locations. Other transformations of physical media are possible without departing from the scope and spirit of the present description, with the foregoing examples provided only to facilitate this discussion.

In view of the foregoing, it should be appreciated that many types of physical transformations take place in the computer architecture 1300 in order to store and execute the software components presented herein. It should also be appreciated that the computer architecture 1300 may include other types of computing devices, including handheld computers, embedded computer systems, personal digital assistants, and other types of computing devices known to those skilled in the art. It is also contemplated that computer architecture 1300 may not include all of the components shown in fig. 13, may include other components not explicitly shown in fig. 13, or may utilize an architecture completely different from that shown in fig. 13.

The disclosure set forth herein may be considered in view of the following exemplary clauses.

Exemplary clause a, a method for managing shared data, the method comprising:

receiving, at a data store, data generated by a source application;

storing the data as a persistent data object configured to be compatible with a plurality of applications and document types, wherein the persistent data object is associated with a unique identifier;

in response to a request for the persistent data object, accessing the persistent data object based on the unique identifier of the persistent data object;

sending the persistent data object to a computing device executing a destination application, wherein the persistent data object is merged by and compatible with a destination document edited by the destination application;

receiving an update to the persistent data object from a user computing device, the update generated by a user application editing a user document on the user computing device; and

in response to receiving an indication that the persistent data object has been inserted in the destination document by the destination computing device, sending, by the data store to the destination computing device, data indicating the update to the persistent data object, the data usable to update the persistent data object incorporated in the destination document.

Exemplary clause B, the method of exemplary clause a, wherein the persistent data object is associated with a category associated with logic operable to enable the destination computing device to present the data independent of a presentation capability of the destination application.

Exemplary clause C, the method of exemplary clause B, wherein the subset of persistent data objects is operable to be inserted in the destination document.

Exemplary clause D, the method of any one of exemplary clauses a-C, further comprising: sending data indicative of the updated persistent data object to a plurality of devices, applications, or documents that have merged or used the persistent data object prior to the update.

Example clause E, the method of any of example clauses a-D, wherein the persistent data object is associated with a permission to enable access to the persistent data object.

Example clause F, the method of any of example clauses a-D, wherein the update to the persistent data object is selectively sent to the destination computing device based at least in part on the attribute associated with the persistent data object.

The method of any of example clauses G, example clauses a-F, wherein the persistent data object is further associated with metadata indicating users authorized to view or edit the persistent data object.

Example clause H, the method of any one of example clauses a-G, further comprising providing the persistent data object in a flattened format.

Example clause I, the method of any one of example clauses a-G, wherein the destination document is automatically updated based on a user option when the persistent data object is updated.

Example clause J, the method of any of example clauses a-I, wherein the destination document is prevented from being updated based on user options when the persistent data object is updated.

Example clause K, the method of any of example clauses a-J, wherein the persistent data object is associated with a grouping mechanism, and wherein the persistent data object is associated with a shared attribute value indicating which group the persistent data object belongs to.

Although the exemplary clauses a-K are described above with respect to methods, it should be understood that the subject matter of the exemplary clauses a-L can additionally or alternatively be implemented as an apparatus, system, or via a computer-readable storage medium in the context of the present disclosure.

Exemplary clause L, a computing device, comprising:

one or more processors;

a memory in communication with the one or more processors, the memory having computer-readable instructions stored thereon that, when executed by the one or more processors, cause the computing device to:

inserting, by a destination application executing on the computing device, a persistent data object in a destination document edited by the destination application, wherein the persistent data object is configured to be compatible with a plurality of applications and document types;

receiving an update to the persistent data object, the update generated by a user application editing a user document on a user computing device; and

updating, by the destination application, the persistent data object inserted in the destination document in response to receiving the update to the persistent data object.

Example clause M, the computing device of example clause L, wherein the persistent data object was initially generated by a source application running on the source computing device.

The computing device of example clause N, example clause L, or example clause M, wherein the persistent data object is initially generated by the destination application and the generated persistent data object is sent to a remote data store configured to store a plurality of persistent data objects.

Example clause O, example clause L through example clause N, wherein the destination application is configured to process the persistent data object to present a representation of the persistent data object.

Example clause P, example clause L, to example clause O, wherein the representation includes one or more of an author, a data/timestamp, a version, and a title.

Example clause Q, example clause L, to example clause P, wherein the versions comprise a plurality of versions of the persistent data object, and wherein an option is provided to select one of the versions for incorporation into the destination document.

Example clause R, example clause L, to example clause Q, wherein the versions comprise a plurality of versions of the persistent data object, and wherein an option is provided to select one of the versions for incorporation into the destination document.

Although the exemplary clauses L-R are described above with respect to a computing device, it should be understood that the subject matter of the exemplary clauses L-R can additionally or alternatively be implemented by a method or via a computer-readable storage medium in the context of the present disclosure.

Exemplary clause S, a computer-implemented method, comprising:

sending, by a source computing device executing a source application, a persistent data object edited by the source application to a data store, wherein the persistent data object is configured to be compatible with a plurality of applications and document types;

generating an update to the persistent data object; and

sending the update to the data store to the persistent data object, wherein the persistent data object is compatible with a document that has incorporated the persistent data object.

Exemplary clause T, the apparatus of exemplary clause S, wherein the update is maintained as a version of the persistent data object and access rights to the version of the persistent data object are applied.

Although the exemplary clauses S to T are described above with respect to a method, it should be understood that the subject matter of the exemplary clauses S to T can additionally or alternatively be implemented as an apparatus or via a computer-readable storage medium in the context of the present disclosure.

Although the techniques have been described in language specific to structural features and/or methodological acts, it is to be understood that the appended claims are not necessarily limited to the described features or acts. Rather, the features and acts are described as exemplary implementations of such techniques.

The operations of an exemplary process are illustrated in various blocks and are described with reference to those blocks for an overview. The processes are illustrated as logical flows of blocks, each of which can represent one or more operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the operations represent computer-executable instructions stored on one or more computer-readable media, which when executed by one or more processors, enable the one or more processors to perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, modules, components, data structures, and so forth that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be performed in any order, combined in any order, subdivided into multiple sub-operations, and/or performed in parallel to implement the described processes. The described processes can be performed by resources associated with one or more devices (such as one or more internal or external CPUs or GPUs) and/or one or more hardware logic (such as FPGAs, DSPs, or other types of accelerators).

All of the methods and processes described above may be embodied and fully automated via software code modules executed by one or more general-purpose computers or processors. The code modules may be stored in any type of computer-readable storage medium or other computer storage device. Some or all of the methods may alternatively be embodied in dedicated computer hardware.

Conditional language such as "can," "may," "might," or "may" should be understood in the context to mean that some examples include but other examples do not include certain features, elements, and/or steps, unless the context clearly dictates otherwise. Thus, such conditional language is not generally intended to imply that certain features, elements, and/or steps are in any way required for one or more examples or that one or more examples must include logic for deciding, with or without user input or prompting, whether certain features, elements, and/or steps are included or are to be performed in any particular example. Unless expressly stated otherwise, an element such as the phrase "X, Y or at least one of Z" should be understood to mean that an item, term, etc. can be X, Y or Z or a combination thereof.

Any routine descriptions, elements, or blocks in the flow diagrams described herein and/or depicted in the figures should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or elements in the routine. Alternative implementations are included within the scope of the examples described herein in which elements or functions may be deleted from those shown or discussed or performed out of order, including substantially concurrently or in reverse order, depending on the functionality involved, as understood by those skilled in the art. It should be emphasized that many variations and modifications may be made to the above-described examples, and the elements thereof should be understood to be other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.