Metadata for remotely accessing collaborative documents

By separating the collaborative metadata and file synchronization process of files in the content management system, the problems of time delay and high resource consumption in the content item synchronization process of cloud storage accounts are solved, and more efficient data synchronization and resource utilization are achieved.

CN113261023BActive Publication Date: 2025-06-13MICROSOFT TECHNOLOGY LICENSING LLC
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
CN201980087267.X
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Priority Date
2018-12-30
Filing Date
2019-12-23
Publication Date
2025-06-13
Estimated Expiration
2039-12-23

AI Technical Summary

Technical Problem

Existing cloud storage accounts have problems with time delay and high resource consumption during content item synchronization, especially when dealing with large amounts of collaborative metadata.

Method used

By separating the collaborative metadata of files from the synchronization process of the file itself in the content management system, the collaborative metadata is retained in a remote location, and users can access the metadata in the cloud through local devices, reducing the metadata transmission needs for client devices.

Benefits of technology

This method reduces time delay during data synchronization, saves computing resources, improves system efficiency and scalability, and reduces synchronization delay between device and file transfer.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN113261023B_ABST
    Figure CN113261023B_ABST
Patent Text Reader

Abstract

A system and method for managing remote metadata-based activities while accessing electronic content via a local application. The system is configured to receive user input that triggers a signal for communicating with a remote server. The remote server can provide options to the client system that are related to or based on the metadata of the currently viewed electronic content. The disclosed system and method significantly improve the efficiency and usability of document development and synchronization systems.
Need to check novelty before this filing date? Find Prior Art

Description

Background Art

[0001] Cloud storage accounts allow users to store their electronic content items or files in an online storage account that can be accessed from any computing device having a network connection. Examples of some better-known cloud storage service providers include Microsoft Google and With these types of services, users can upload content items such as pictures, songs, documents, and other electronic content from a computing device to an online storage account. These items can later be accessed from different computing devices. In some cases, for example, the service provides methods for storing, synchronizing, and sharing various file types with other people and across multiple computing devices, as well as the possibility of synchronizing system settings, visual customizations, themes, application settings, and browser tabs, history, and saved passwords for different devices.

[0002] Once the content is stored in the online storage account, the user is able to access their content items. However, synchronizing the content items themselves can be time-consuming. As an example, many content items can include a large amount of data sets regarding the content item itself (e.g., metadata). Traditional content item synchronization methods are designed to transfer the entire content item (including metadata), which can result in longer synchronization sessions and local memory storage. Therefore, there remains an important area for new and improved ideas in reducing the latency during data synchronization and improving the user experience of interacting with data regarding a given document. Summary of the Invention

[0003] According to a first aspect of the present disclosure, a content management system for accessing collaborative document actions includes a processor and a computer-readable medium. The computer-readable medium includes instructions that, when executed by the processor, cause the processor to: receive, at a first client system, a first uniform resource identifier (URI) associated with a first collaborative document synchronized with the first client system, and receive a first user input via a native application executed on the first client system related to a local instance of the first collaborative document to display a first menu of actions for the local instance. Additionally, the instructions further cause the processor to, in response to the first user input, retrieve, via a network, a first list of available actions corresponding to the first URI, wherein the first list of available actions includes a first action specification that identifies a first collaborative document action obtainable via a remote system, and, in response to retrieving the first list of available actions, dynamically generate menu items for the first collaborative document action and display the menu items together with the first menu. Further, the instructions cause the processor to receive a second user input that indicates a user selection of the menu item, and then, in response to the second user input and based on the first action specification, retrieve a first instruction from the remote system for rendering a user interface to perform the first collaborative document action for the first collaborative document. The instructions also cause the processor to execute the first instruction to display an action user interface on the first client system for the first collaborative document, receive a third user input via the action user interface, and, in response to the third user input, send a command from the first client system to the remote system to perform the first collaborative document action on the first collaborative document.

[0004] According to a second aspect of the present disclosure, a method for accessing collaborative document actions includes: receiving, at a first client system, a first uniform resource identifier (URI) associated with a first collaborative document synchronized with the first client system, and receiving, via a native application executed on the first client system in relation to a local instance of the first collaborative document, a first user input to display a first menu of actions for the local instance. Additionally, the method includes retrieving, via a network and in response to the first user input, a first list of available actions corresponding to the first URI, wherein the first list of available actions includes a first action specification that identifies a first collaborative document action obtainable via a remote system, and then, in response to retrieving the first list of available actions, dynamically generating menu items for the first collaborative document action and displaying the menu items together with the first menu. Further, the method includes receiving a second user input indicating a user selection of the menu item, and then, in response to the second user input and based on the first action specification, retrieving a first instruction from the remote system for rendering a user interface to perform the first collaborative document action for the first collaborative document, and then, executing the first instruction to display an action user interface for the first collaborative document on the first client system. The method also includes receiving a third user input via the action user interface, and in response to the third user input, sending a command from the first client system to the remote system to perform the first collaborative document action on the first collaborative document.

[0005] The present invention content is provided to introduce, in a simplified form, a selection of design concepts further described below in the detailed description. The present invention content is not intended to identify key features or essential features of the claimed invention subject matter, nor is it intended to be used to limit the scope of the claimed invention subject matter. Additionally, the claimed invention subject matter is not limited to implementations that solve any or all of the disadvantages noted in any part of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The drawings depict, by way of example and not limitation, one or more implementations in accordance with the present teachings. In the drawings, like reference numerals refer to the same or similar elements. Additionally, it should be understood that the drawings are not necessarily drawn to scale.

[0007] Figure 1A and Figure 1B is a conceptual diagram of an implementation of a content synchronization environment;

[0008] Figure 2A and Figure 2B is a conceptual diagram showing an implementation of a distributed computing environment architecture for managing content synchronization and metadata;

[0009] Figure 3 Is a representation of a device display having an implementation of a document that opens on a client device after being accessed via a synchronization client application;

[0010] Figure 4 Is a representation of a device display having an implementation of a native application that provides access to a document file and a main options menu;

[0011] Figure 5 Is a representation of a device display having an implementation of a native application that provides access to a document file and a secondary options menu;

[0012] Figure 6 Is a representation of a device display having an implementation of a web-based interface that provides access to metadata for a document accessed by a native application;

[0013] Figure 7 Is a representation of a device display having an implementation of a client folder that provides access to metadata options for a document;

[0014] Figure 8 Is having provided for Figure 7 Is a representation of a device display having an implementation of a web-based interface that provides access to metadata for a document selected in

[0015] Figure 9 Is a process flow diagram of an implementation of a method for accessing remote metadata for an electronic content item;

[0016] Figure 10 Is a flow diagram showing an implementation of a process for providing a client device with access to remote metadata;

[0017] Figure 11 Is a block diagram of an example computing device that can be used to provide an implementation of the mechanisms described herein; and

[0018] Figure 12 Is a block diagram showing components of an example machine configured to read instructions from a machine-readable medium. Detailed Description

[0019] In the following detailed description, numerous specific details are set forth by way of example in order to provide a thorough understanding of the relevant teachings. However, it will be apparent that the teachings herein can be practiced without these details. In other instances, well-known methods, procedures, components, and / or circuits have been described at a relatively high level without detailed elaboration in order to avoid unnecessarily obscuring aspects of the teachings herein.

[0020] Generally speaking, computing systems often share and access information from a cloud computing (or other remote server) environment. For example, some computing systems store files on a cloud computing data storage system. However, during the creation and editing of a document, these same files can also be stored locally on the disk by an application. Similarly, as discussed further below in detail, some systems have applications that support document collaboration (such as merging, sharing, co - authoring, and other functions or capabilities). In some cases, these systems can rely on a synchronization engine (or "sync engine") that is responsible for detecting and synchronizing changes to files and folders between the local disk and the cloud storage system. To achieve this, the sync engine can track the status of files stored on the disk and files stored in the cloud and coordinate these statuses when it receives information that something has changed. For example, if a file is edited on the local disk, the sync engine may detect the change, realize that the change needs to be sent to the cloud, transmit the change, wait for a response from the cloud, and then update its local status information to indicate that the change has been made. In cases where a file is the product of or subject to collaboration, additional and evolving metadata can be associated with the file. In some embodiments, the system can be configured to maintain and convey a set of collaboration metadata for each file. In other words, each file can have or be linked to metadata about the file. This "collaboration metadata" for each file can be used in part to help maintain various versions of the file and to provide important information about the status, workflow tasks, or other aspects of the file. However, keeping the file and its associated collaboration metadata up - to - date in sync results in latency during synchronization and consumes a large amount of computing resources. To help minimize the impact of the synchronization process on system and network resources, the following disclosure presents a paradigm in which the collaboration metadata for a file is substantially separated from the file during the synchronization of the file and subsequent user access on a client device. In other words, when a user downloads and / or accesses files via a client device application and these files continue to be synchronized with the cloud storage system, the collaboration metadata remains at a remote location (e.g., outside the local device). In the event that the user initiates an action in the file that requires access to the collaboration metadata, the proposed content management system (CMS) can respond by providing a portal or other network interface on the local device through which the user can directly access the collaboration metadata stored in the cloud. Thus, the synchronization process for the file can occur without transferring large amounts of expensive collaboration metadata to the client device. By enabling the user to "reach out" to the cloud for file metadata as needed, the system as a whole can operate more smoothly and efficiently.

[0021] Generally, a content management system (CMS) refers to a system through which users can store content items and perform various content management tasks (such as retrieving, modifying, browsing, and / or sharing content items, and enabling users to access content from multiple client devices). Generally, users can interact with the CMS through one or more client devices connected to a network. The CMS can support connections from a variety of different client devices (such as desktop computers, mobile computers, mobile communication devices (such as mobile phones, smartphones, tablets, etc.), smart TVs, gaming devices, set-top boxes, and / or any other network-enabled computing device). The CMS can be configured to accept connections from multiple client devices and interact with them simultaneously. Generally, users interact with the CMS by interacting with a client application installed on the client device or via a third-party application (such as a web browser application) and are configured to communicate with the CMS.

[0022] In addition, by way of example, the term "electronic content item" or "content item" can include any digital data that can be presented (e.g., visually or auditorily), including but not limited to electronic documents, media streams, web pages, hypertext documents, images, digital video or video recordings, digital audio or audio recordings, animations, digital messages, markup language documents (such as hypertext markup language (HTML) or extensible markup language (XML) documents), forms with blank components to accept input data, or data describing an application of a GUI, and other digital data. In addition, an "item" can include any folder, file, directory, or data object on an electronic device. As an example, an item can refer to a directory "folder" that can include documents, photos, music files, and video files.

[0023] In addition, the terms "software application", "software", or "application" generally refer to a computer program that performs useful work and is generally independent of the computer itself. Some non-limiting examples of software applications include word processors, spreadsheets, accounting systems, and telecommunications programs, as well as gaming software, utility tools, and productivity tools, mobile applications, presentation graphics, and other productivity software. These are non-limiting examples, and any other electronic content editing or collaboration application can benefit from the disclosed embodiments. Therefore, specific references to software applications by name throughout the specification should not be construed as limiting the use of the proposed systems and methods.

[0024] In addition, the following disclosure will refer to the document "Workflow". A workflow can generally be described as a series of tasks that produce a result. In the context of the following disclosure, a workflow can refer, for example, to the automated or substantially automated movement of a document or project through a sequence of actions or tasks related to a business or other collaborative process. By enabling an organization to attach business logic to a document or project in a shared content management system, workflows are often used to manage common business processes within an organization. Generally, business logic refers to a set of instructions used to specify and control the actions that occur on a document or project.

[0025] Workflows typically simplify the costs and time required to coordinate common business processes (such as project approvals or document reviews) by managing and tracking the manual tasks involved in these processes. For example, in a Microsoft site, a workflow can be added to a document library that routes documents to a set of people for approval. When a document author starts the workflow on a document in the library, the workflow creates document approval tasks, assigns these tasks to workflow participants, and then sends an email alert to the participants with the task instructions and a link to the document to be approved. While the workflow is in progress, the workflow owner (in this case, the document author) or workflow participants can view the "Workflow Status" panel to identify which participants have completed their workflow tasks. When workflow participants complete their workflow tasks, the workflow ends, and the workflow owner is automatically notified that the workflow has been completed. In other words, workflows are typically used to drive processes and manage the lifecycle of files in a document repository. Thus, workflows can facilitate the management process around collaborative documents.

[0026] Generally, it can be understood that such workflows rely heavily on the metadata associated with the file. Since many users continue to open and access documents on client devices rather than web-based applications, the following implementation describes a mechanism by which collaborative metadata about the workflow status or history of a document can be retained in a cloud storage system. The following systems and methods enable users to quickly access this remote collaborative metadata while working locally. In other words, work that occurs on a client device for a document (e.g., as a local instance) can remain coupled to the collaborative metadata for the document via a link available during document access, allowing the user to continue managing the workflow and other resultant information about the document. In some embodiments, depending on its configuration, a form can be generated that contains some or all of the metadata determined to be relevant to the document. For example, the form can contain one or more fields, each mapped to a piece of metadata, as will be discussed in more detail below.

[0027] To better introduce these systems and methods to the reader,Figure 1A and Figure 1B presents a high-level example of a representative computing environment (“environment”) 150 for implementing an electronic content synchronization management system (schematically shown in Figure 2A and 2B ). In various embodiments, environment 150 may include one or more computing device end-users, or simply “users”. One or more users may interact with or operate on data presented via a user device. Further details and examples are presented in connection with the figures that follow, generally describing the Figure 1A and Figure 1B various features and activities shown therein.

[0028] As an example, Figure 1A a first user 110 is shown. In this case, the first user 110 is accessing a synchronization client application (“synchronization client”) 100 on a first device 120. The first device 120 may be a personal computer, such as a desktop or laptop computer, a mobile device, or any other computer system having a file system. The first device 120 executes an operating system such as Microsoft or other operating systems, and includes a memory, storage, a network interface, and other computer hardware not shown for simplicity in Figure 1A . The first device 120 creates, modifies, and / or deletes files on its storage system via its operating system. Additionally, as further described below, the first device 120 includes one or more synchronization folders. In Figure 1A , only one device is shown, but any number of devices may be folders shared synchronously via a synchronization service. For example, the first device 120 may be connected to a server, other devices, and / or an online or cloud-based computing document repository (“cloud repository”) 190. When the first user 110 adds or modifies electronic content via the first device 120, various content or files may be updated or saved in cloud storage via a network connection.

[0029] In various embodiments, the client computing device can include traditional client type devices, as well as desktop computer type devices, mobile type devices, dedicated type devices, embedded type devices, and / or wearable type devices. For example, the client computing device can include a client computing device of the computer navigation type, such as a satellite-based navigation system, including a Global Positioning System (GPS) device and other satellite-based navigation system devices; telecommunications devices, such as mobile phones, tablet computers, hybrid mobile phone / tablet computers, personal digital assistants (PDAs), laptop computers, other mobile computers, wearable computers, implanted computing devices, desktop computers, personal computers, in-vehicle computers, Internet Protocol (IP) TVs, thin clients, terminals, game consoles, gaming devices, workstations, media players, personal video recorders (PVRs), set-top boxes, digital video recorders (DVRs), cameras, and integrated components for inclusion in a computing device, an appliance, or any other type of computing device configured to receive user input.

[0030] In this example, the first device 120 allows the first user 110 to create, modify, and delete files on the local file system of the client, and synchronizes these actions with the versions of the same files on the host system and / or one or more other client computers. In some embodiments, the user can create folders and designate them for synchronization. The content of the files is managed in part by the synchronization client 100 to maintain the desired synchronization frequency or level. Generally, the user can create a shared synchronization folder through the native controls for the synchronization client 100 or via a web server.

[0031] In Figure 1A , the synchronization client 100 can be understood to provide a user interface (UI) that is configured to allow the first user 110 to select folders or content to access or share. Thus, the first user 110 is using the first device 120 to receive or synchronize one or more electronic content items available in the cloud repository 190. For the purposes of this particular example, the set of electronic content includes a first electronic content item ("first item") 102 associated with first collaborative metadata content ("first metadata") 104. The first item 102 includes the main content of the document itself, while the first metadata 104 includes information about the document.

[0032] In Figure 1A , the first user 110 adds or updates the file corresponding to the first item 102 to the local synchronization folder on the first device 120 via the synchronization client 100. The operating system can send a message indicating that the synchronization folder has changed, as well as the location (path) of the folder or file within the folder that has changed. As the folder is synchronized, the data associated with each item is sent to and / or received from the cloud repository 190.

[0033] In many cases, the average user will remain unaware of the separation of data and metadata during the synchronization process. As Figure 1B shown, the first user 110 continues to access the document (the first item 102) via the computing resources 122 located at the first device 120 or otherwise associated with the computing resources 122 of the first device 120 by means of a local application 140. In different implementations, the architecture may include at least one network, including but not limited to a public network such as the Internet, a private network such as an institutional and / or personal intranet, and / or some combination of private and public networks.

[0034] The first user 110 may perform work or make changes to the document. At some point during the access to the native application 140, the first user 110 may initiate an action associated with the first item 102 that requires access to the metadata for the document. Since the metadata is not available locally, in some embodiments, when the first user 110 provides some input (shown here as trigger 130) to initiate a request to access the metadata, the native application 140 may generate a signal 142 that is sent to the CMS 170 or other cloud-based service. The service may retrieve the metadata (the second item 104) from the cloud repository 190 and present a web-based interface 160 on the first device 120 for the first user 110 to view and / or interact with. In other embodiments, the native application 140 may send a signal to some other application of the client system to initiate a communication session with the remote metadata. The first user 110 can then easily access the metadata-based content regardless of the synchronization state of the content on the first device 120.

[0035] Accordingly, the present disclosure provides several technical advantages, including but not limited to: the implementation of a synchronization process that can interface with multiple local applications, the ability to separate the synchronization of document content data from the metadata for the document, more efficient operation of a processing device that performs cross-application data transfer (e.g., saving computing cycles / computing resources), more effective communication between devices during file synchronization (e.g., less renegotiation between devices to synchronize file data), the ability to work with devices having various form factors, scalability when working with file data synchronization (including the ability to modify the metadata associated with a file being synchronized without downloading or transmitting the metadata content), and reduced latency in synchronizing between devices and file transfers, among other examples.

[0036] To provide a clearer illustration of the disclosed embodiments, reference is made to Figure 2A and Figure 2BThe sequence presents an example of a content management system (“the system”), which includes a first client system 210 (associated with a first user 202), a second client system 238 (associated with a second user 204), and a synchronization service 230. Note that all features and functions described elsewhere in this specification can be implemented by at least the Figure 2A and Figure 2B systems described in.

[0037] In Figure 2A , an implementation of the synchronization service 230 for managing document synchronization and collaborative metadata content is depicted. In some implementations, the synchronization service 230 can communicate with various modules, such as other services and repositories, including a metadata service 240, an inventory service 234, and / or a collaborative document repository 250. Although in the Figure 2A implementation these modules are shown as separate from the synchronization service 230, it should be understood that in other implementations, one or more of these modules can be part of or incorporated within the synchronization service 230 itself.

[0038] In different implementations, various components of the system 200 can receive and / or share information via at least one wired or wireless network interface that can communicate with other modules and web-based applications over a network 232. Examples of network interfaces include IEEE 802.11 Wireless LAN (WLAN) wireless interfaces, Worldwide Interoperability for Microwave Access (Wi-MAX) interfaces, Ethernet interfaces, Universal Serial Bus (USB) interfaces, cellular network interfaces, Bluetooth TM interfaces, Near Field Communication (NFC) interfaces, etc. Additional examples of network interfaces are described elsewhere herein. Some examples of the network 232 include a Local Area Network (LAN), a Wide Area Network (WAN) (such as the Internet), a Personal Area Network (PAN), and / or a combination of communication networks.

[0039] To provide greater clarity to the reader, the second client system 238 is included to illustrate a mechanism by which document workflows and collaboration can occur. In Figure 2AIn this context, the second user 204 can access and / or interact with a shared instance of the collaborative document 252 via the network 232 (e.g., on an online authoring or other web-based application 236). The online authoring application 236 represents an example of a web-based application which, in some instances, may also be referred to as a "cloud" application or service. Web-based applications are generally accessible by computing devices via the network 232, can be configured to perform data processing and / or data hosting operations, and can provide data for metadata-based activities and tasks (e.g., workflows). In different implementations, such web-based applications can include any type of network-accessible application or service, such as database applications, social networking applications, messaging applications, financial services applications, news applications, search applications, productivity applications, cloud storage applications, file hosting applications, etc. Some non-limiting examples of such applications include network-accessible SQL (Structured Query Language) databases, Salesforce.com TM , Finance, The New York (with the URL www.nytimes.com), Google Search, Bing, Google Docs TM , Office 365, Dropbox TM , and so on. Although Figure 2A one web-based application is shown, any number of web-based applications can be accessed via the network 232.

[0040] The collaborative document 252 stored in the collaborative document repository 250 can include electronic content for the document itself. In some embodiments, the metadata for the collaborative document 252 and the corresponding metadata-based action options can be stored in a separate module (here, the metadata service 240). The metadata service 240 can provide an online metadata interface 246 to the second user 204 via the second client system 238 for participating in various workflow options or other metadata-based activities for a selected document. In some embodiments, changes in the metadata-based activity parallax or other information can be recorded in the collaborative document metadata store 248.

[0041] In different implementations, the collaborators of a document can choose to access the document as a local (native application) instance or a remote or shared (web-based) instance. As an example, the first user 202 can be understood to access the collaborative document 252 as a local instance 222 from the file storage 220 after a synchronization session. The first client system 210 can include for the above Figure 1A and Figure 1BAny features described for the synchronization client application 100 and the first device 120 in. The local instance 222 can be generated via communication between the synchronization service 230 and the synchronization client 212 associated with the client operating system 214 of the first client system 210, which can synchronize the shared instance of the collaborative document 252 with the local instance 222 at different times. In some embodiments, the first user 202 can choose to access or interact with the local instance 222 via the native application 216 running on the client operating system 214. The native application 216 is an example of an application that can be accessed by the client system without communicating over a network. For example, the native application 216 can be configured to perform data processing and / or data hosting operations when executed by a processor and can be configured to provide data to a workflow developed with reference to metadata content. As some examples, the native application 216 can be any type of local application or service, such as a database application (e.g., spreadsheet), an email application (e.g., ), a productivity application (e.g., etc.) or other types of applications. Although Figure 2A shows a single native application, any number of native applications can exist in the client system.

[0042] Generally, electronic content file data or content includes file content (data stream), and corresponding file metadata that can include file name, timestamp, attributes, etc. In some embodiments, the first client system 210 can receive, modify, or otherwise access this information about the collaborative document via the manifest service 234. The manifest service 234 can communicate with the uniform resource identifier (URI) or metadata identifier store 224 of the metadata service 240 to determine the appropriate identifier to include in each collaborative document. One or more URIs can be linked to the synchronized document via the manifest service 234 such that the synchronization session of the collaborative document with other client systems will include the appropriate and up-to-date metadata identifier. In the case where the first user 202 provides input of reference document metadata or otherwise initiates a call for an action for a metadata-based activity, the URI associated with the local document can be triggered, activated, or executed to request information and / or actions from the metadata service 240. The metadata service 240 can receive a request from the first client system 210 via the metadata API 244, which is configured to receive and / or share information with the client system. In response, the metadata API 244 can transmit or otherwise display the local metadata interface module 242 to the first user 202 on the first client system 210 via the network 232. In some embodiments, the metadata API 244 can also be understood to include a REST API.

[0043] In addition, in some embodiments, the local metadata interface module 242 may generate and / or send a user interface for display on the client system, through which the user may view and interact with metadata-based activities for a selected document. In some embodiments, the metadata API 244 may be configured to be operated / interacted with to create additional applications in the form of workflows, as described above. For example, the user may access the metadata API 244 by interacting with the local instance 222 through a native application 216 capable of accessing a web-based application. By selecting a task or option in a document linked to a URI, the user may be provided with a browser to traverse a network address (e.g., a Uniform Resource Locator) that may access the metadata API 244 and in turn may invoke one or more workflow designer GUIs (e.g., a web page) in a browser window or a workflow review / manager, or any other metadata-based option. The user may then be enabled to interact with the workflow designer GUI or manager to develop a workflow or respond to a previously developed workflow.

[0044] In some embodiments, the metadata API 244 may include or be connected to a UI generator and / or a workflow logic generator. The UI generator may be configured to send workflow GUI information (e.g., one or more web pages, image content, etc.) to a browser for display as a workflow designer GUI within a browser window on the display screen of the client system. The user may then interact with the workflow designer GUI to select workflow steps and configure them into a workflow. For example, the user may insert and arrange multiple workflow steps in the workflow designer GUI, where one or more steps are associated with local or web-based applications. The browser may be configured to store the selected workflow steps, corresponding configuration information, and / or workflow step sequence information as constructed workflow information. In one embodiment, any input made via the interface may be processed by the metadata API 244 and recorded in the collaborative document metadata store 248.

[0045] Next, referring to Figure 2B , a simplified example of a process for implementing a Figure 2A system is schematically presented. Some system modules are shown near the top of the figure, and a series of events are arranged below. Generally, it can be seen that the events shown in the lower half of the figure are connected by dashed lines to the modules associated with the initiation of the specified events. It should be understood that the steps described are for simplicity and may also include other steps, or some of the steps may be omitted.

[0046] In a first step 260, the metadata service 240 can register a URI and provide the URI to the collaborative document repository 250. The manifest service 234 can obtain URI information from the collaborative document repository 250 and submit the information to the synchronization service 230 in a second step 262. The synchronization client 212 can be configured to synchronize data on the first client system 210 with data associated with the synchronization service 230 (including the URI for the electronic content) in a third step 264. In some embodiments, the URI can be synchronized with the electronic content (e.g., both are synchronized as data encapsulation), while in other embodiments, the electronic content can be synchronized with its corresponding URI in a separate process or at a separate time.

[0047] When a user interacts with the native application 216 on the first client system 210, a first user input that can trigger the presentation of a menu or other actuable options can be received in a fourth step 266. The menu provides the user with one or more options that can be recognized or configured by invoking a menu processor, as in an optional fifth step 268. In a sixth step 270, in response to a second user input requesting a task associated with the document metadata, the synchronization client 212 can request manifest data from the manifest service 234 based on the URI associated with the selected document. In a seventh step 272, the manifest service 234 can send the data, which is received by the synchronization client 212. In an eighth step 274, the synchronization client 212 can present new options (action menu items) for the user to participate in tasks leveraging the collaborative metadata for the document in conjunction with the menu processor.

[0048] Then, in a ninth step 276, the user can select an option, and in a tenth step 278, this third input can trigger a request from the synchronization client 212 to the metadata service 240 for deploying a local interface. In an eleventh step 280, the metadata service 240 can respond to the request by providing the necessary data to generate a local interface on the first client system 210. In a twelfth step 282, when the user now continues to interact with the metadata options via the local metadata interface module 242 presented on the client device, various actions can be performed in conjunction with the remotely stored metadata and the metadata API 244.

[0049] For the sake of clarity for the reader, Figures 3 - 6 some examples of user interfaces are presented through which metadata content can be accessed and / or presented. In Figure 3 a second user 310 is shown accessing a second electronic content item ("document") 302 via a second computing device ("second device") 300. When the second user 310 opens the document 302 via the native application 340, the document content 304 can be presented on the display 306.

[0050] In various embodiments, the display 306 may be configured to present various icons, interfaces, graphics, applications, or other device status information. As an example, the display 306 includes an implementation of an interface for opening or accessing a file associated with the native application 340. For simplicity, Figure 3 the native application 340 in is a word processing program that is part of the display document content 304. In one embodiment, the native application 340 may be understood to represent a certain version of Microsoft or other word processing programs, such as Apple Corel Google IBM Lotus Word and other word editing programs. However, in other embodiments, the native application 340 may include Microsoft Office or any other software application within the product array, as well as any non -

[0051] Generally speaking, an "interface" can be understood to refer to a mechanism for delivering content to an application user through the native application. For example, the interface may include pop - up windows, controls, actuatable interfaces, interactive buttons, or other objects that can be presented to the user via the native application user interface (UI), and the native mechanisms of the specific application for presenting the content associated with these native controls. In addition, an "actuation" or "actuation event" may refer to an event (or a specific sequence of events) associated with a specific input or use of the application via the interface, which may trigger a change in the display of the application.

[0052] In addition, a "native control" generally refers to a mechanism for delivering content to an application user through the native application. For example, native controls may include actuatable or selectable options or "buttons" that can be accessed via the native application UI, touch - screen access points, menu items, or other objects that can be presented to the user through the native application UI, fragments of a larger interface, and the native mechanisms of the specific application for presenting the content associated with these native controls. The term "asset" as an example refers to content that can be presented in association with native controls in the native application. Thus, as a non - limiting example, an asset may include text in an actuatable pop - up window, audio associated with an interactive click on a button or other native application object, video associated with a teaching user interface, or other such information presentations.

[0053] Once users access the native application 340, they can view available documents, basic information about these documents, and / or options or tools that can be used in association with these documents or the application. In some embodiments, with reference to Figure 4 , the system can receive user input that triggers a response in the form of a menu interface, which can provide the user with the ability to invoke options related to or associated with the document metadata. In Figure 4 , the user access in connection with the second item 302 presents a simplified view of the implementation of the display 306, in this case identified by a file named "Research Paper". The file name and content are presented within the document content interface ("document interface") 400 of the application included in the display window. In some embodiments, the user can submit a first input (represented by the mouse cursor 420), and in response, a new window or menu interface 410 (or "menu item") can be presented. The scope of the first input can be broad and can include clicking, hovering, or otherwise issuing commands or instructions via the document interface 400.

[0054] In some embodiments, the menu interface 410 can be positioned or located adjacent to, "above", or outside the document interface 400, or can extend outward from the document interface 400. The menu interface 410 can be configured to display or present various options through which the user can navigate within the application and / or identify tools for facilitating document interaction. In different embodiments, Figure 4 , the menu interface 410 shown can be different and can include various additional or alternative options for the currently viewed document and / or details about the currently viewed document. In Figure 4 's example, the menu interface 410 provides a list of actuatable options or tools through which the user can select to print, save, share, close the application, and / or the currently accessed document, etc. In one embodiment, the menu interface can include a cascading menu interface that is configured to display or otherwise provide submenus or additional options when selected. As an example, these additional options can be presented on one side of the first "main" menu or elsewhere on the display. In some embodiments, such a cascading menu interface can be configured to display different submenus or options in response to an item selected in the interface.

[0055] As described above, in various embodiments, the system can include provisions for facilitating access (e.g., via a locally running native application) to metadata content of documents stored remotely (e.g., not on the client device). In this example, the menu interface 410 presents a plurality of options, including menu option 412, shown here near the bottom of the menu interface 410. In other embodiments, this menu option 412 can be presented alone (i.e., without the remaining menu options), can be provided as a drop-down menu option, and / or can be viewed via an initial native application launch pane. Additionally, while menu option 412 is labeled "Workflow Options" in Figure 4 it should be understood that in other embodiments, the metadata content access option can be associated with any other label, including icons, symbols, alphanumeric characters, or other indicators, and / or a number of metadata-related options may be provided.

[0056] As Figure 5 shown next, selection of menu option 412 can cause a response from the system. In some embodiments, the system can respond to selection of menu option 412 by presenting an (optional) metadata options interface 510, which can provide the user with a more specific range of actions that can be performed in conjunction with the available metadata content. Thus, in some embodiments, the metadata options interface 510 can provide a plurality of actuatable options for initiating various tasks that in some way employ or rely on the metadata content in order to be performed while remaining "within" the context or environment of the native application 340. For example, the metadata options interface 510 includes a first option 512, a second option 514, and a third option 516. The first option 512 provides the ability to "Add Action" to a document (or document workflow), the second option 514 ("View Workflow Tasks") provides the ability to view actions previously added to the document and / or added to the document by other collaborators of the document, and the third option 516 provides the ability to view or access additional options related to or using the document metadata for the document workflow. The metadata options interface 510 is shown for illustrative purposes only, and any other type of interface or options can be provided or presented to the user in response to a triggering event. In some embodiments, the metadata options interface 510 may not be displayed, and selection of menu option 412 can directly result in an arrangement similar to that described with reference to Figure 6 As described.

[0057] In some other embodiments, menu option 412 can be linked to or otherwise associated with a Uniform Resource Identifier (URI) that the native application can use to access file data, as described above with reference to Figure 2A and Figure 2BAs discussed. In one example, the URI can be a Uniform Resource Locator (URL). In some embodiments, the native application can be configured to contact the URL to obtain or otherwise access the metadata content of the current file that can be hosted in a separate service. The native application 340 can also be configured to automatically determine which data transfer mechanism to use, at least in part, based on the protocol associated with the option and the document. In other words, the native application 340 and / or the synchronization document protocol can provide instructions on how to correctly use the URL.

[0058] In different implementations, in response to the selection of an option associated with the document metadata, the native application in combination with the CMS can trigger the execution of a "routing action" or other navigation process. In other words, in response to user input, the system can route the recipient to a predefined destination to receive, store, and / or share the metadata-based information generated by the selection of the actionable option, and / or guide the recipient to execute a workflow process.

[0059] In Figure 6 it, the metadata content interface 600 is rendered and displayed for a second user, at least in part via a resource associated with the CMS. Thus, it can be seen that in addition to the original document content "layer" for the electronic content item itself (viewed via the native application 340), a second metadata content layer (presented here as the metadata content interface 600) is also displayed. The metadata content interface 600 can include any content that has any type of relationship with the metadata for the currently viewed or selected document. In this case, the metadata content interface 600 is presented to the user in the form of a plurality of native controls or actionable options 620, which are displayed in the general context associated with the previously selected option ("view workflow tasks"). The metadata content interface 600 in this example includes a main viewing pane 610, in which the tasks, actions, or processes triggered by the previous user input can be indicated. Thus, in some implementations, access to remotely stored metadata content includes the rendering of a new layer of content outside or external to the native application (e.g., a web browser called using a URL or a map application called using an address, or other new interface window).

[0060] It should be noted that in some other embodiments, the client device resources can be configured to interpret the URL such that the rendering occurs within the native application itself. In one embodiment, the metadata content layer can be generated or displayed in various modes, such as overlay (floating over the electronic content), replacement (floating over a specific part of the electronic content, thus "hiding" that content), side panel (present in a side panel adjacent to the electronic content, possibly in the form of a small preview that can be interacted with), and marginal note (present in the marginal note area of the electronic content, possibly in the form of a very limited preview).

[0061] If the user clicks or otherwise selects one of the actionable options 620, various processes can be initiated in conjunction with a CMS and / or a native application that can access or modify the metadata content. For example, referring to Figure 6 , a first task 630 indicating that the current document requires approval, along with information about the approval task, is displayed in the main viewing pane 610. Additionally, a first action 612 (“Approve”) and a second action 614 (“Deny”) are provided, thereby allowing the user to respond to the requested task quickly and efficiently. In some embodiments, additional tasks can be associated with the document and can also or alternatively be displayed. In one embodiment, the user can select, for example, the “Show More Tasks” button 622 to view other workflow options or events that have occurred for the document. In another embodiment, the metadata content interface 600 can provide additional features, as indicated by the “Options” button 624. As the user continues to provide input to the system, additional or alternative actions may occur. In some embodiments, in response to the user's selection of an actionable option, an additional interface or web page can be opened on the same computing device for managing the user interaction with the metadata content and the corresponding process. Thus, it can be seen that in some embodiments, the system can be configured to initiate or execute processes involving multiple steps and / or applications, receive and process input from various local and remote sources, and / or integrate information that occurs at different points in time to provide a seamless user experience. When the user interacts with the metadata content layer and participates in any subsequent steps, in different embodiments, the system can optionally be configured to update the metadata for the document and / or, in some cases, update the document content itself. Additionally, in some embodiments, the CMS can present an automated message that guides the user through the required tasks.

[0062] For illustrative purposes, referring to Figure 7 and Figure 8 shows another implementation by which the system can facilitate access to remote metadata content for an electronic content item. In Figure 7 , the device display 306 presents an interface for the synchronization client application 702. For simplicity, Figure 7 the synchronization client application 702 in

[0063] In some cases, the synchronization client application 702 can be configured to synchronize any changes to the content in its specified folder and its subfolders, such as new, deleted, modified, copied, or moved files or folders. In different embodiments, the synchronization client application 702 can be a separate software application and / or can be integrated with an existing content management application in the operating system. Figure 7 An example of client software integrated with an existing content management application is presented, enabling a user to directly manipulate the content in a local folder (synchronization folder 750), while a background process monitors the local folder for changes and synchronizes those changes to cloud storage. In other implementations, the background process can also identify updated content and synchronize those changes to the local folder. In some embodiments, the synchronization client application 702 can be configured to provide notifications of synchronization operations.

[0064] In other embodiments, users can store content items in a location on their client device rather than within the specified synchronization folder of the synchronization client application 702. For example, users can access a content management application, such as a music or photo library, that stores content items in a location outside the specified synchronization folder. The client device can be configured to identify the location of these content items by searching the memory of the client device for files associated with a specified file extension that indicates the file is a content item to be synchronized. In some other implementations, the client device can perform a full or partial search of the accessible storage of the client device (such as a local hard drive or memory stick) to identify the location of the content items.

[0065] After identifying a content item in the memory, the client device can be configured to import the content item into the content management system. In some embodiments, this can include creating a copy of the content item and then storing the copy of the content item in the specified synchronization folder, thereby synchronizing the content item with the content management system. In some other embodiments, the content item can alternatively be uploaded directly from the identified location to the content management system without storing a copy of the content item in the specified synchronization folder.

[0066] As Figure 7As shown, during various user interactions with the synchronization client application 702, the user can choose to interact with items in the synchronization folder 750. As an example, the user can use a first input to select or otherwise specify an electronic content item 752 (here, "Research Paper.docx"), such as via a touchscreen input or a left or right mouse click. In response, a new window or menu interface 708 can be presented. The range of user inputs can be wide and can include clicking, hovering, or otherwise issuing commands or instructions via the synchronization folder 750 or other aspects of the synchronization client application 702.

[0067] In some embodiments, the menu interface 708 can be positioned or located adjacent to, "above," or outside the synchronization folder 750, or can extend outward from the synchronization folder 750. The menu interface 708 can be configured to display or present various options by which the user can review and / or identify tools for facilitating folder and file interactions. In different embodiments, Figure 7 the menu interface 708 shown in can be different and can include various additional or alternative options for the currently viewed document and / or details about the currently viewed document. In Figure 7 the example, the menu interface 708 provides a list of actuatable options or tools by which the user can select to open, share, move, delete, rename the currently selected file, etc.

[0068] In some embodiments, the menu interface 708 includes multiple options, including menu option 760, shown here near the bottom of the menu interface 708. In other embodiments, the menu option 760 can be presented alone (i.e., without the remaining menu options), can be provided as a drop-down menu option, and / or can be viewed via an initial native application launch pane. Additionally, although the menu option 760 is labeled "Workflow Tasks" in Figure 7 it should be understood that in other embodiments, the metadata content access option can be associated with any other label, including icons, symbols, alphanumeric characters, or other indicators.

[0069] As Figure 7 shown, the menu option 760 can cause a response from the system when selected by a second user input (see mouse cursor 420). In some embodiments, the menu option 760 can be linked or otherwise associated with a uniform resource identifier (URI) that the client system can use to access the file data, as described above with reference to Figure 2A and 2BAs discussed. In one example, the URI can be a Uniform Resource Locator (URL). The native application can be configured to contact the URL to obtain metadata content for the current file that can be hosted in a separate service.

[0070] In addition, in some embodiments, the system can respond to the selection of menu option 760 by presenting an (optional) metadata options interface 710, which can provide the user with a more specific range of actions that can be performed in conjunction with the available metadata content. Thus, in some embodiments, the metadata options interface 710 can provide multiple actuatable options for initiating various tasks that in some way employ or rely on the metadata content in order to be performed while maintaining the context or environment of the client system "in". As an example, the metadata options interface 710 includes a first option 712, a second option 714, and a third option 716, similar to those discussed above for Figure 5 The metadata options interface 710 is shown for illustrative purposes only, and any other type of interface or option can be provided or presented to the user in response to a triggering event. In some embodiments, the metadata options interface 710 may not be displayed, and the selection of menu option 760 can directly result in an arrangement similar to that described with reference to Figure 8 As described.

[0071] In different implementations, in response to the selection of an option associated with the document metadata, the native application in combination with the CMS can trigger the execution of a "routing action" or other navigation process. In other words, in response to user input, the system can route the recipient to a predefined destination in order to receive, store, and / or share the metadata-based information generated by the selection of the actionable option, and / or guide the recipient to perform the corresponding process.

[0072] In Figure 8 At least in part via resources associated with the CMS, the metadata content interface 800 is rendered and displayed for a second user. Thus, it can be seen that in addition to the previous folder content associated with the electronic content item itself, a metadata content layer (presented here as the metadata content interface 800) is also exhibited. In other words, the user can access metadata-based options for the file without opening the file itself via the native application. The metadata content interface 800 can include the display of any content having any type of relationship with the metadata of the currently viewed or selected document. In this case, the metadata content interface 800 presented to the user can be understood to be similar to that described with reference to Figure 6 As described.

[0073] For clarity, Figure 9Illustrated is an implementation of process 900 for providing remote metadata content for a document to a local client device (e.g., via a content management system). In this example, the first phase 910 includes synchronization and / or access of a collaborative document, for example, from a cloud storage document repository 902. As previously described, in some implementations, the repository may include various modules for identifying and routing different types of data. In this example, the repository includes a document data store and a corresponding document metadata store. The collaborative document may be synchronized with a client synchronization application in a second phase 920, and a local copy of the document may be accessed by a user in a third phase 930.

[0074] In addition, in some implementations, a native application may receive user input that corresponds to a request for some action or process that requires or references metadata for a document (fourth phase 940). The request may trigger the activation or execution of an identifier (e.g., a URI) in a fifth phase 950. The URI may route the request to a remote location that is configured to interact and communicate with the client device. For example, an interactive browser or other interface may be displayed on the client device in a sixth phase 960, and one or more options for navigating through the selected process or task may be provided to the user in a seventh phase 970. In response to a selection, the CMS may provide or otherwise continue to provide additional options for working with the document metadata in an eighth phase 980. In some implementations, as a ninth phase 990, the user may provide input or make other changes that will be recorded in the system.

[0075] Figure 10 is a flowchart showing an implementation of a method 1000 for accessing collaborative document actions. In Figure 10In this method, the first step 1010 includes: receiving, at a first client system, a first Uniform Resource Identifier (URI) associated with a first collaborative document synchronized with the first client system, and the second step 1020 includes: receiving, via a native application executed on the first client system in relation to a local instance of the first collaborative document, a first user input to display a first menu of actions for the local instance. In the third step 1030, the method includes: retrieving, via a network and in response to the first user input, a first list of available actions corresponding to the first URI, wherein the first list of available actions includes a first action specification that identifies a first collaborative document action obtainable via a remote system. The fourth step 1040 involves dynamically generating, in response to retrieving the first list of available actions, menu items (cascading or otherwise) for the first collaborative document action and displaying the menu items together with the first menu, and the fifth step 1050 includes: receiving a second user input indicating a user selection of the menu item. Additionally, the method includes a sixth step 1060: retrieving, in response to the second user input and based on the first action specification, a first instruction from the remote system for rendering a user interface to perform the first collaborative document action for the first collaborative document; and a seventh step 1070: executing the first instruction to display an action user interface for the first collaborative document on the first client system. Further, the method includes an eighth step 1080: receiving a third user input via the action user interface, and a ninth step 1090: sending, in response to the third user input, a command from the first client system to the remote system to perform the first collaborative document action on the first collaborative document.

[0076] In other embodiments, the method may include additional or alternative steps or aspects. For example, the local instance of the first collaborative document may be stored at the first client system in a file system, the native application is a file browser application configured to render a user interface for navigating files stored in the file system and selecting files stored in the file system, and the first user input is received with respect to a user interface element representing the local instance of the first collaborative document. In some cases, the first user input includes a right-click action performed on the user interface element. In another example, the native application is a creation application configured to: render electronic content items stored in the local instance of the first collaborative document in a creation user interface at the first client system, and the first user input is received via the creation user interface. In some other implementations, the action user interface may present a workflow task form. In these cases, the workflow task form includes a plurality of actuatable options for modifying metadata associated with the first collaborative document. Thus, in response to a user's selection or other user input, the system may be configured to: display one or more predefined / designed / created or preselected forms or interfaces that serve as templates for the user to interact with various workflows or other metadata options.

[0077] As another example, the action user interface is configured to display metadata items associated with the first collaborative document, and the command specifies an edit to be performed on the metadata items by the remote system. Additionally, in different embodiments, the method further includes the step of: receiving, at a second client system, a second URI associated with the first collaborative document that is synchronized with the second client system, wherein the second URI is different from the first URI. In another example, the method may include: retrieving, via a network, a second available action list corresponding to the second URI, wherein the second available action list is different from the first available action list. In some embodiments, the method further includes: modifying a first action specification in response to a third user input to include a second collaborative document action obtainable via the remote system. In some cases, the method further includes: updating the first available action list in response to any edit to the metadata items.

[0078] Previously, local copies of enterprise content would be synchronized with their metadata and a local delivery interface for accessing the document metadata. However, the scale and complexity of enterprise content made this process cumbersome and often resulted in the local copies of files "losing" their connection to the enterprise metadata repository. Users found context viewing and editing impossible and needed to conduct these experiences via a direct portal interface while temporarily disconnecting from the local editing session. In the implementation described herein, documents that have been synchronized to a local machine can "discover" content management capabilities associated with the document, which can significantly improve the efficient use of computing resources. Additionally, the process works in cooperation with the client system so that native applications that open the synchronized files can help ensure that metadata-guided behavior remains enforced. When a synchronization session occurs, the synchronized documents can be bundled with the URLs described herein to access content management capabilities services when the files are opened on the local machine. Thus, an authoring application can retrieve content management capabilities from the URL, such as metadata, the template of the document, the expiration date of the document, information about any ongoing workflows on the project, whether the document has been marked for review or flagged as violating one of the data policies of the parent organization, or other such information about the document. By using the system, users can continue to reliably access and maintain synchronized copies of files that are also marked with URLs that can easily connect the client system to a cloud delivery interface for displaying and editing document metadata. By registering with the local system operating system and making a user request for more information about a local copy of a file that has opened a context menu (e.g., clicking the right mouse button), the user can view and edit enterprise metadata about the document, where the file interface is streamed to the local operating system at runtime.

[0079] The detailed examples of the systems, devices, and techniques presented herein in conjunction with FIGS. 1- Figure 10 are used to illustrate the present disclosure and its benefits. Such usage examples should not be construed as limiting the implementation of the logical processes of the present disclosure, nor should variations in user interface methods relative to those described herein be considered outside the scope of the present disclosure. In some embodiments, the various features described in FIGS. 1- Figure 10 are implemented in corresponding modules, which may also be referred to as and / or include logic, components, units, and / or mechanisms. Modules can constitute software modules (e.g., code contained on a machine-readable medium) or hardware modules.

[0080] In some examples, a hardware module may be implemented mechanically, electronically, or in any suitable combination thereof. For example, a hardware module may include dedicated circuitry or logic units configured to perform certain operations. For example, a hardware module may include a dedicated processor, such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC). A hardware module may also include programmable logic or circuitry temporarily configured by software to perform certain operations, and may include a portion of machine-readable media data and / or instructions for such configuration. For example, a hardware module may include software contained within a programmable processor configured to execute a set of software instructions. It will be appreciated that the decision to implement a hardware module mechanically, either in dedicated and permanently configured circuitry or in temporarily configured circuitry (e.g., configured by software), may be driven by cost, time, support, and engineering considerations.

[0081] Accordingly, the term "hardware module" should be understood to include a tangible entity capable of performing certain operations and that can be configured or arranged in some physical manner, which is physically constructed, permanently configured (e.g., hardwired), and / or temporarily configured (e.g., programmed) to perform in a particular manner, or to perform certain operations described herein. As used herein, "hardware-implemented module" refers to a hardware module. Considering an example where a hardware module is temporarily configured (e.g., programmed), it is not necessary to configure or instantiate every hardware module at any given time. For example, in the case where a hardware module includes a programmable processor configured by software to be a dedicated processor, the programmable processor may be configured at different times to be respectively different dedicated processors (e.g., including different hardware modules). Software may accordingly configure a particular processor or some processors, e.g., to constitute a particular hardware module at one moment and another hardware module at another moment. A hardware module implemented using one or more processors may be referred to as "processor-implemented" or "computer-implemented".

[0082] Hardware modules may provide information to, and receive information from, other hardware modules. Accordingly, the described hardware modules may be considered to be communicatively coupled. In cases where multiple hardware modules are present simultaneously, communication may be achieved via signal transmission between or among two or more hardware modules (e.g., via appropriate circuitry and buses). In embodiments where multiple hardware modules are configured or instantiated at different times, communication between these hardware modules may be achieved, for example, by storing and retrieving information in a memory device accessible to the multiple hardware modules. For example, one hardware module may perform an operation and store the output in a memory device, and then another hardware module may access the memory device to retrieve and process the stored output.

[0083] In some examples, at least some operations of the method may be performed by one or more processors or modules implemented by a processor. Additionally, one or more processors may also operate to support the performance of related operations in a "cloud computing" environment or as "software as a service" (SaaS). For example, at least some operations may be performed by multiple computers (as an example of machines including processors) and / or executed between multiple computers, and these operations may be accessed via a network (e.g., the Internet) and / or via one or more software interfaces (e.g., application programming interface (API)). The performance of certain operations may be distributed among processors, not only residing within a single machine but also deployed on multiple machines. The processor or the module implemented by the processor may be located in a single geographical location (e.g., in a home or office environment, or in a server farm), or may be distributed across multiple geographical locations.

[0084] Figure 11 FIG. 1100 is a block diagram showing an example software architecture 1102, various parts of which may be used in conjunction with various hardware architectures described herein, which may implement any of the above-described features. Figure 11 This is a non-limiting example of a software architecture, and it will be appreciated that many other architectures may be implemented to facilitate the functions described herein. The software architecture 1102 may be executed on hardware such as Figure 1A a device 120 including a document storage 1070, a processor, a memory, and input / output (I / O) components, etc. A representative hardware layer 1104 is illustrated and it may represent, for example, the device 120 of FIG. 1. The representative hardware layer 1104 includes a processing unit 1106 and associated executable instructions 1108. The executable instructions 1108 represent the executable instructions of the software architecture 1102, including the implementation of the methods, modules, etc. described herein. The hardware layer 1104 also includes a memory / storage 1110, which also includes the executable instructions 1108 and accompanying data. The hardware layer 1104 may also include other hardware modules 1112. The executable instructions 1108 held by the processing unit 1106 may be some parts of the executable instructions 1108 held by the memory / storage 1110.

[0085] The example software architecture 1102 may be conceptualized as layers, each layer providing various functions. For example, the software architecture 1102 may include layers and components such as an operating system (OS) 1114, libraries 1116, frameworks 1118, applications 1120, and a presentation layer 1144. In operation, the applications 1120 and / or other components within the layers may make API calls 1124 to other layers and receive corresponding results 1126. The illustrated layers are representative in nature, and other software architectures may include additional or different layers. For example, certain mobile or dedicated operating systems may not provide a framework / middleware 1118.

[0086] The OS 1114 can manage hardware resources and provide common services. The OS 1114 can include, for example, a kernel 1128, services 1130, and drivers 1132. The kernel 1128 can act as an abstraction layer between the hardware layer 1104 and other software layers. For example, the kernel 1128 can be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, etc. The services 1130 can provide other common services for other software layers. The drivers 1132 can be responsible for controlling or interfacing with the underlying hardware layer 1104. For example, the drivers 1132 can include a display driver, a camera driver, a memory / storage driver, a peripheral driver (e.g., via Universal Serial Bus (USB)), a network and / or wireless communication driver, an audio driver, etc., depending on the hardware and / or software configuration.

[0087] The library 1116 can provide a common infrastructure that can be used by the application 1120 and / or other components and / or layers. The library 1116 generally provides functions used by other software modules to perform tasks, rather than directly interacting with the OS 1114. The library 1116 can include a system library 1134 (e.g., the C standard library), which can provide functions such as memory allocation, string handling, file operations, etc. In addition, the library 1116 can include an API library 1136, such as a media library (e.g., supporting the rendering and manipulation of image, sound, and / or video data formats), a graphics library (e.g., the OpenGL library for rendering 2D and 3D graphics on a display), a database library (e.g., SQLite or other relational database functions), and a web library (e.g., WebKit, which can provide web browsing functionality). The library 1116 can also include various other libraries 1138 for providing many functions for the application 1120 and other software modules.

[0088] The framework 1118 (sometimes also referred to as middleware) provides a higher-level common infrastructure that can be used by the application 1120 and / or other software modules. For example, the framework 1118 can provide various Graphical User Interface (GUI) functions, advanced resource management, or advanced location services. The framework 1118 can provide a wide range of other APIs for the application 1120 and / or other software modules.

[0089] The application 1120 includes built-in applications 1140 and / or third-party applications 1142. Examples of built-in applications 1140 can include, but are not limited to, a contacts application, a browser application, a location application, a media application, a messaging application, and / or a gaming application. Third-party applications 1142 can include any application developed by an entity other than the vendor of a particular platform. The application 1120 can use the functions available via the OS 1114, the library 1116, the framework 1118, and the presentation layer 1144 to create a user interface for interacting with the user.

[0090] Some software architectures use virtual machines, as shown by virtual machine 1148. The virtual machine 1148 provides an execution environment in which applications / modules can execute as if they were executing on a hardware machine (e.g., Figure 10 machine 1000). The virtual machine 1148 can be hosted by a host OS (e.g., OS 1114) or a hypervisor and can have a virtual machine monitor 1146 that manages the operation of the virtual machine 1148 and its interoperability with the host operating system. A software architecture different from the software architecture 1102 outside the virtual machine can execute within the virtual machine 1148, such as OS 1150, libraries 1152, frameworks 1154, applications 1156, and / or presentation layer 1158.

[0091] Figure 12 is a block diagram showing the components of an example machine 1200 that is configured to read instructions from a machine-readable medium (e.g., a machine-readable storage medium) and perform any of the features described herein. The example machine 1200 is in the form of a computer system in which instructions 1216 (e.g., in the form of software components) can be executed to cause the machine 1200 to perform any of the features described herein. Thus, the instructions 1216 can be used to implement the modules or components described herein. The instructions 1216 cause the unprogrammed and / or unconfigured machine 1200 to operate as a particular machine configured to perform the described features. The machine 1200 can be configured to operate as a stand-alone device or can be coupled (e.g., networked) to other machines. In a networked deployment, the machine 1200 can operate in the capacity of a server machine or a client machine in a server-client network environment, or as a node in a peer-to-peer or distributed network environment. The machine 1200 can be embodied as, for example, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a gaming and / or entertainment system, a smartphone, a mobile device, a wearable device (e.g., a smartwatch), and an Internet of Things (IoT) device. Additionally, although only a single machine 1200 is shown, the term "machine" includes a collection of machines that execute the instructions 1216, either individually or jointly.

[0092] Machine 1200 may include a processor 1210, a memory 1230, and I / O components 1250, which may be communicatively coupled via, for example, a bus 1202. The bus 1202 may include multiple buses that couple the various elements of machine 1200 via various bus technologies and protocols. In an example, the processor 1210 (including, for example, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), an ASIC, or a suitable combination thereof) may include one or more processors 1212a through 1212n that may execute instructions 1216 and process data. In some examples, one or more processors 1210 may execute instructions provided or identified by one or more other processors 1210. The term "processor" includes multi-core processors, which include cores that may execute instructions simultaneously. Although Figure 12 multiple processors are shown, machine 1200 may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors each with a single core, multiple processors each with multiple cores, or any combination thereof. In some examples, machine 1200 may include multiple processors distributed across multiple machines.

[0093] Memory / storage 1230 may include a main memory 1232, a static memory 1234, or other memories, as well as a storage unit 1236, both of which may be accessed by the processor 1210, for example, via the bus 1202. The storage unit 1236 and the memories 1232, 1234 store instructions 1216 that embody any one or more of the functions described herein. Memory / storage 1230 may also store temporary, intermediate, and / or long-term data for the processor 1210. The instructions 1216 may also reside, in whole or in part, within the memories 1232, 1234, within the storage unit 1236, within at least one of the processors 1210 (e.g., in a command buffer or cache memory), within the memory of at least one of the I / O components 1250, or in any suitable combination thereof. Accordingly, the memories 1232, 1234, the storage unit 1236, the memories within the processors 1210, and the memories within the I / O components 1250 are examples of machine-readable media.

[0094] As used herein, a "machine-readable medium" refers to a device that can store instructions and data that cause a machine 1200 to operate in a specific manner, either temporarily or permanently. The term "machine-readable medium" as used herein does not include transient electrical or electromagnetic signals per se (such as on a carrier wave propagating through a medium); thus, the term "machine-readable medium" can be considered tangible and non-transitory. Non-limiting examples of non-transitory tangible machine-readable media can include, but are not limited to, non-volatile memory (such as flash memory or read-only memory (ROM)), volatile memory (such as static random access memory (RAM) or dynamic RAM), buffer memory, cache memory, optical storage media, magnetic storage media and devices, network-accessible or cloud storage, other types of storage, and / or any suitable combination thereof. The term "machine-readable medium" applies to a single medium or a combination of multiple media used to store instructions (e.g., instructions 1216) executable by a machine 1200 such that when the instructions are executed by one or more processors 1210 of the machine 1200, the machine 1200 performs one or more of the features described herein. Thus, a "machine-readable medium" can refer to a single storage device, as well as a "cloud-based" storage system or storage network that includes multiple storage devices or apparatuses.

[0095] The I / O components 1250 can include a variety of hardware components suitable for receiving input, providing output, generating output, transmitting information, exchanging information, capturing measurements, and the like. The specific I / O components 1250 included in a particular machine will depend on the type and / or function of the machine. For example, a mobile device such as a mobile phone may include a touch input device, while a headless server or an Internet of Things device may not include such a touch input device. Figure 12 The specific examples of I / O components shown are in no way limiting, and other types of components may be included in the machine 1200. The grouping of the I / O components 1250 is for simplicity of discussion only, and the grouping is in no way limiting. In various examples, the I / O components 1250 can include a user output component 1252 and a user input component 1254. The user output component 1252 can include, for example, a display component for displaying information (such as a liquid crystal display (LCD) or a projector), an acoustic component (such as a speaker), a haptic component (such as a vibration motor or a force feedback device), and / or other signal generators. The user input component 1254 can include, for example, an alphanumeric input component (such as a keyboard or a touch screen), a pointing component (such as a mouse device, a touchpad, or another pointing tool), and / or a haptic input component (such as a physical button or a touch screen that provides position and / or touch force or touch gestures) configured to receive various user inputs, such as user commands and / or selections.

[0096] In some examples, the I / O component 1250 may include a biometric component 1256 and / or a location component 1262, as well as a wide array of other environmental sensor components. The biometric component 1256 may include, for example, components for detecting body expressions (e.g., facial expressions, vocal expressions, hand or body gestures, or eye tracking), measuring biometric signals (e.g., heart rate or brain waves), and identifying a person (e.g., via voice-based, retina, and / or facial recognition). The location component 1262 may include, for example, a location sensor (e.g., a Global Positioning System (GPS) receiver), an altitude sensor (e.g., a barometric pressure sensor from which altitude can be derived), and / or an orientation sensor (e.g., a magnetometer).

[0097] The I / O component 1250 may include a communication component 1264 that implements a variety of techniques that are operable to couple the machine 1200 to the network 1270 and / or the device 1280 via corresponding communication couplings 1272 and 1282. The communication component 1264 may include one or more network interface components or other suitable devices for interfacing with the network 1270. The communication component 1264 may include, for example, components adapted to provide wired communication, wireless communication, cellular communication, near field communication (NFC), Bluetooth communication, Wi-Fi, and / or communication via other modalities. The device 1280 may include other machines or various peripheral devices (e.g., coupled via USB).

[0098] In some examples, the communication component 1264 may detect an identifier or include components adapted to detect an identifier. For example, the communication component 1264 may include a radio frequency identification (RFID) tag reader, an NFC detector, an optical sensor (e.g., a one-dimensional or multi-dimensional barcode, or other optical code), and / or an acoustic detector (e.g., a microphone for identifying an audio signal of a tag). In some examples, location information may be determined based on information from the communication component 1262, such as, but not limited to, a geographical location via an Internet Protocol (IP) address, a location via Wi-Fi, cellular, NFC, Bluetooth, or other wireless station identification and / or signal triangulation.

[0099] Although various embodiments have been described, the description is intended to be exemplary, not limiting, and it should be understood that more embodiments and implementations within the scope of these embodiments are possible. Although many possible combinations of features are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are also possible. Unless specifically restricted, any feature of any embodiment can be used in combination with or substituted for any other feature or element in any other embodiment. Thus, it will be understood that any feature shown and / or discussed in the present disclosure can be implemented together in any suitable combination. Thus, these implementations are not restricted except as considered in the appended claims and their equivalents. Additionally, various modifications and changes can be made within the scope of the appended claims.

[0100] Although the examples and / or other examples considered to be the best mode have been described above, it should be understood that various modifications can be made therein, and the inventive subject matter disclosed herein can be implemented in various forms and examples, and these teachings can be applied to a large number of applications, only some of which are described herein. The appended claims are intended to claim any and all applications, modifications, and variations that fall within the true scope of this teaching.

[0101] Unless otherwise specified, all measurements, values, ratings, positions, sizes, dimensions, and other specifications set forth in this specification, including those set forth in the appended claims, are approximate and not exact. They are intended to have a reasonable range consistent with the functions they relate to and the customs in the fields they are associated with.

[0102] The scope of protection is limited only by the appended claims. When interpreted in accordance with this specification and the subsequent prosecution history, this scope is intended to and should be interpreted as a scope consistent with the ordinary meaning of the language used in the claims and covering all structural and functional equivalents. Nevertheless, all claims are not intended to cover subject matter that fails to meet the requirements of Sections 101, 102, or 103 of the Patent Act, nor should they be interpreted in such a way. No protection is hereby sought for any unintended inclusion of such inventive subject matter.

[0103] Except as described above, nothing set forth or shown is intended or should be interpreted to result in the dedication of any component, step, feature, object, benefit, advantage, or equivalent to the public, whether or not it is recited in the claims.

[0104] It will be understood that, unless a specific meaning is otherwise set forth herein, the terms and expressions used herein have a plain meaning consistent with such terms and expressions in their respective fields of search and study. Relational terms such as first and second may be used solely to distinguish one entity or action from another entity or action, and do not necessarily require or imply any actual such relationship or order between these entities or actions. The term "comprises", "comprising", or any other variation is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element preceded by "a" or "an" does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0105] A summary of the present disclosure is provided to enable the reader to quickly ascertain the nature of the technical disclosure. The summary is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Additionally, in the foregoing detailed description, it can be seen that for purposes of streamlining the present disclosure, various features are combined in each example. The methods of the present disclosure should not be construed as reflecting an intention that the claims require more features than are expressly recited in each claim. Rather, as reflected in the following claims, the inventive subject matter lies in less than all of the features of a single disclosed example. Thus, under the premise that each claim itself is a separately claimed inventive subject matter, the following claims are hereby incorporated into the detailed description.

Claims

1. A content management system for accessing content management actions of a collaborative document, comprising: a processor; and a computer-readable medium including instructions that, when executed by the processor, cause the processor to: receive, at a first client system, a first uniform resource identifier (URI) associated with a first collaborative document synchronized with the first client system, wherein: a local instance of the first collaborative document is downloaded to the first client system, the first collaborative document is associated with first collaboration metadata, and the first collaboration metadata is maintained on a remote system associated with the content management system, wherein the first collaboration metadata includes version information for the first collaborative document and information identifying content management actions that can be performed on the first collaborative document; receive, via a native application executed on the first client system in relation to the local instance of the first collaborative document, a first user input to display a first menu of actions for the local instance; in response to the first user input, retrieve, via a network, a first list of available actions corresponding to the first URI, wherein the first list of available actions includes a first action specification that identifies a first content management action available via the remote system, wherein the first content management action is specified in the first collaboration metadata; dynamically generate menu items for the first content management action in response to retrieving the first list of available actions, and display the menu items together with the first menu; receive a second user input that indicates a user selection of one of the menu items; in response to the second user input and based on the first action specification, retrieve a first instruction from the remote system for rendering a user interface to perform the first content management action on the first collaborative document; execute the first instruction to display an action user interface on the first client system for the first collaborative document; receive a third user input via the action user interface; and in response to the third user input, send a command from the first client system to the remote system to perform the first content management action on the first collaborative document.

2. The system according to claim 1, wherein, the local instance of the first collaborative document is stored at the first client system in a file system; the native application is a file browser application configured to render a user interface for navigating files stored in the file system and selecting files stored in the file system; and the first user input is received in relation to a user interface element representing the local instance of the first collaborative document.

3. The system according to claim 2, wherein, the first user input is a click action performed on the user interface element.

4. The system according to claim 1, wherein: The native application is a creation application configured to render, in a creation user interface at the first client system, an electronic content item stored in a local instance of the first collaborative document; and the first user input is received via the creation user interface.

5. The system according to claim 1, wherein, the action user interface presents a workflow task form.

6. The system according to claim 1, wherein: the action user interface is configured to display metadata items associated with the first collaborative document; and the command specifies an edit to the metadata items to be performed by the remote system.

7. The system according to claim 1, wherein, the instruction further causes the processor to receive, at a second client system, a second URI associated with a first collaborative document synchronized with the second client system, and wherein the second URI is different from the first URI.

8. The system according to claim 7, wherein, the instruction further causes the processor to retrieve, via the network, a second available action list corresponding to the second URI, wherein the second available action list is different from the first available action list.

9. The system according to claim 6, further comprising: updating the first available action list in response to the edit to the metadata items.

10. The system according to claim 5, wherein, the workflow task form includes a plurality of actuatable options for modifying metadata associated with the first collaborative document.

11. A method for accessing collaborative document actions, the method comprising: receiving, at a first client system, a first uniform resource identifier (URI) associated with a first collaborative document synchronized with the first client system, wherein: a local instance of the first collaborative document is downloaded to the first client system, the first collaborative document is associated with first collaborative metadata, and the first collaborative metadata is maintained on a remote system associated with a content management system, wherein the first collaborative metadata includes version information for the first collaborative document and information identifying collaborative document actions that can be performed on the first collaborative document; receiving, via a native application executed on the first client system in relation to the local instance of the first collaborative document, a first user input to display a first menu of actions for the local instance; retrieving, via a network and in response to the first user input, a first available action list corresponding to the first URI, wherein the first available action list includes first action specifications that identify first collaborative document actions obtainable via the remote system, wherein the first collaborative document actions are specified in the first collaborative metadata; dynamically generating menu items for the first collaborative document actions in response to retrieving the first available action list and displaying the menu items together with the first menu; receiving a second user input indicating a user selection of the menu item; In response to the second user input and based on the first action specification, retrieve a first instruction from the remote system for rendering a user interface to perform a first collaborative document action on the first collaborative document; Execute the first instruction to display an action user interface on the first client system for the first collaborative document; Receive a third user input via the action user interface; and In response to the third user input, send a command from the first client system to the remote system to perform the first collaborative document action on the first collaborative document.

12. The method according to claim 11, wherein, a local instance of the first collaborative document is stored at the first client system in the file system; the native application is a file browser application configured to render a user interface for navigating files stored in the file system and selecting files stored in the file system; and the first user input is received with respect to a user interface element representing the local instance of the first collaborative document.

13. The method according to claim 12, wherein, the first user input is a click action performed on the user interface element.

14. The method according to claim 11, wherein, the native application is a creation application configured to: render an electronic content item stored in the local instance of the first collaborative document in a creation user interface on the first client system; and the first user input is received via the creation user interface.

15. The method according to claim 11, wherein, the action user interface presents a workflow task form.

Citation Information

Patent Citations

  • Synchronized organization directory with team member folders

    US10037339B1

  • Enhanced Client And Server Systems for Operating Collaboratively Within Shared Workspaces

    US20090327405A1

  • Hybrid workflow synchronization between cloud and on-premise systems in a content management system

    US20150100547A1

  • Shared Workspaces with Selective Content Item Synchronization

    US20180267989A1