Embedded Tasks in the Co - productivity Suite

Abstract

In some implementations, the method includes receiving user input indicating a request to create a task and presenting a visual representation of the task. The method may also include receiving user input indicating an assignment of the task to an assignee and sending a first notification to a second application indicating the task and the assignment of the task to the assignee. The method may further include receiving a second notification from the second application indicating a change in status of the task and modifying the visual representation of the task to graphically indicate the change in status of the task in a user interface of the first application.

Description

Technical Field

[0001] Aspects and embodiments of the present disclosure generally relate to sharing data among co - applications, and more particularly to embedding sharing instances of task - related data among different applications.

Background Art

[0002] Productivity applications are often grouped into a suite of interactive applications used for creating documents, presentations, worksheets, databases, charts, graphs, and other materials, and have become a widespread work environment. Depending on the situation, applications may allow multiple users to access and modify files in order to facilitate collaboration and speed up the completion of work products. Particularly in web applications and cloud - based applications, it is becoming increasingly important to provide flexibility in data access and sharing between instances of applications and between files shared among different users. The distributed nature of application platforms has enabled collaborators located geographically far apart to collaborate on various tasks and projects that previously required them to be in close proximity. As a result, various storage, access, retention, change policies, and progress management functions have been implemented.

Summary of the Invention

[0003] The following summary is a simplified overview of the disclosure to provide a basic understanding of some aspects of the disclosure. This summary is not an extensive overview of the disclosure. It is not intended to identify key or critical elements of the disclosure or to define the scope of any particular embodiment of the disclosure or any claims. Its sole purpose is to present some concepts of the disclosure in a simplified form as a prelude to the more detailed description that follows.

[0004] In some embodiments, a system and method are disclosed. In some embodiments, the system includes a memory device and a processing device coupled to the memory device. The processing device can receive user input indicating a request to create a task via a user interface of a first application and can be configured to present a visual representation of the task to the user interface of the first application. This can include generating a data object that defines a plurality of properties of the task based on the user input indicating the request to create the task and generating a visual representation of the task based on the plurality of properties defined by the data object. The processing device can also receive user input indicating that the processing device, on behalf of an assigner user, assigns the task to an assignee and can be configured to send a first notification indicating the task and the assignment of the task to the assignee to a second application. The processing device can further receive a second notification from the second application indicating a change in the status of the task and can be configured to modify the visual representation of the task to graphically indicate the change in the status of the task to the user interface of the first application. The processing device can also be configured to add an assignee indicated by user input to the data object. Further, the processing device can receive user input indicating a second assignee of the task and can be configured to send the second assignee to the data object of the task.

[0005] In some embodiments, the method includes receiving user input indicating a request to create a task via a user interface of a first application, and presenting a visual representation of the task in the user interface of the first application. Presenting the visual representation may include generating a data object that defines a plurality of properties of the task based on the user input indicating the request to create the task, and storing the data object in a data store and generating a visual representation of the task based on the plurality of properties defined by the data object. The method may also include receiving user input indicating that the task has been assigned to an assignee, and sending a first notification indicating the task and the assignee to whom the task has been assigned to a second application. The method may further include receiving a second notification from the second application indicating a change in the status of the task, and modifying the visual representation of the task to graphically indicate the change in the status of the task in the user interface of the first application. In some embodiments, the method includes adding an assignee indicated by the user input to the data object, receiving user input indicating a second assignee of the task, and adding the second assignee to the data object of the task, and sending an email notifying the assignee of the assigned task to the assignee.

[0006] In other embodiments, the method includes the first application receiving, from a second application, a notification indicating an assignment of a task to an assignee, and presenting, in a graphical user interface (GUI) of the first application, a visual representation of the task, the visual representation including one or more interactive graphical elements, where one of the one or more interactive graphical elements corresponds to the completion status of the task. The method also includes modifying the completion status of the task based on user input associated with one of the one or more interactive graphical elements, and sending a notification indicating the modified completion status of the task to the second application. The method may also include receiving a second user input indicating a change to a property of the task, modifying an interactive graphical element corresponding to the property based on the second user input, and preventing notification of the second application of the change to the property of the task. One of the interactive graphical elements corresponding to the property may include a setting to prevent the change of the property from being communicated to the second application. The method may also include sending an email indicating the modified completion status of the task to the assigner of the task.

[0007] The foregoing summary of the invention according to preferred embodiments should not be construed as limiting the scope of the invention. It should be understood and apparent to those skilled in the art that the embodiments of the invention thus described may be further modified without departing from the spirit and scope of the invention.

[0008] Aspects and embodiments of the present disclosure will be more fully understood from the following detailed description, as well as the accompanying drawings of various aspects and embodiments of the present disclosure, but these drawings are not intended to limit the present disclosure to specific aspects or embodiments, but are for illustrative and understanding purposes only.

Brief Description of the Drawings

[0009]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5A

Figure 5B

Figure 6

Mode for Carrying Out the Invention

[0010] Aspects of the present disclosure relate to sharing embedded instances of task-related data between different applications. To support productivity, content creation, scheduling, project management, and other general work-related activities, various application platforms have become available to users. Accordingly, various productivity suites, including applications for creating and editing documents, presentations, worksheets, databases, graphs, etc., have become a widespread work environment. Furthermore, such applications can be implemented on a distributed cloud-based platform that enables collaborative work between user teams over the web.

[0011] Given such possibilities, in many cases, the number of users leveraging the features provided by many web applications (e.g., email applications, document processing applications, calendar applications, spreadsheet applications, project management applications, etc.) that form part of a cloud-based productivity suite continues to increase, and collaboration increasingly includes the ongoing progression of activities across such diverse applications and the mutual interaction among more people.

[0012] When a user's activities extend to the use of information available in various applications, the user often needs to switch between applications, contexts, windows, or interfaces to access the relevant information and plan actions related to that information. For example, a user may use a word processing application to work on an electronic document containing information associated with a task defined in a task management application and may want to assign that task to another user. Currently, the user has to switch to the task management application to assign the task to another user and then return to the word processing application to continue working on the electronic document. As another example, a team of collaborators may need to assign tasks related to a project and track whether the assigned tasks have been completed. Additionally, the individual to whom a task is assigned may need to have a tracker for the task specifically assigned to them where they can add details meaningful to themselves.

[0013] However, traditional team task lists and individual task trackers have an independent structure and are not integrated or interconnected with each other. This lack of integration hinders productivity and leads to frequent switching between various applications, interfaces, etc. Such switching is inconvenient for users and may require a significant amount of time and computing resources. Furthermore, additional time and computing resources are consumed to enable users to track and adjust the assignment and execution of various tasks. The existence of separate instances of the same task-related information in different applications makes it difficult to synchronize all instances of the information and keep it up-to-date. Moreover, the presence of information representing the same task in different unsynchronized applications may cause team members to rely on inconsistent task-related information, resulting in a discontinuous workflow and potential delays in progress. On the other hand, in some cases, synchronizing and updating all information related to a task may undesirably impede the productivity of the individual performing the task or provide unnecessary information to other team members. For example, a task assignee may need to change the deadline for completing a task assigned to them because they also need to perform other tasks. If this information is synchronized with the task-related information accessible to the team and the task assigner, there may be a discrepancy in the task-related information between the application used by the assigner and the application used by the assignee.

[0014] The embodiments disclosed herein address the foregoing and other problems by providing a mechanism that allows a user to access or modify task-related data from a task management application within the interface of another application, thereby reducing the number of times the user needs to switch applications or interfaces. Specifically, a framework is provided that allows individual tasks represented by data objects derived from or defined by an application (e.g., a task management application) to be embedded within a data container or file of another application (e.g., a word processing application) such as within a planning document. This addresses the problem of maintaining a separate list of tasks since the data object representing the task is associated with both the source application (e.g., the task management application) and the host application (e.g., the word processing application) in which it is embedded. Further, the user can view all tasks assigned to themselves in their personal task list and annotate them with personal notes, descriptions, deadlines, and other contextual information through the graphical user interface of the task management application. The user can also modify the tasks and indicate whether a task is complete. This display of the task's completion status can be synchronized between the assignee version of the task (e.g., the data object representing the task in the task management source application) and the team / assignee version of the task (e.g., the embedded data object in the word processor host application representing the task). In this way, task-related information that is important and relevant to both the assigner and the assignee is synchronized and kept up-to-date, while personal notes and other personal task-related information can be freely created and modified by the assignee without burdening the assigner.

[0015] As one example scenario showing the advantages of having embedded data in an application, a user may be working on a document using a word processing application and may want to assign a task to another user without leaving the context (e.g., interface) of the document. According to the disclosed aspects herein, the user can embed the "task" into the document associated with the "task" within the task management application, thereby eliminating the need for the user to switch to the task management application to assign the task to another user. In some embodiments, to embed the "task", it includes creating a data object representing the task in the graphical user interface (GUI) of the word processing application, and associating the task data with the visual representation of the task within the GUI of the word processing application, or fixing the task data to the visual representation of the task. This embedded task can then be accessed and updated from the GUI of the task management application as well. Similar functionality can be implemented in various other application types where it is necessary to maintain the sharing rights of data by embedding information from one application to another (e.g., a spreadsheet application and a task management application where tasks can be embedded into cells or rows of a worksheet).

[0016] Data shared and stored by each of two applications can be subject to different data policies (e.g., data location, sharing, retention, etc.). For example, if a task is embedded in a document, the data policy applied to the document may require storing the document data in the European Union (EU), while the data policy applied to the task may require storing the task data in the United States (US). In some embodiments, to ensure compliance with different data policies, when data of one application (e.g., a source application) is embedded in or generated by another application (e.g., a host application), each application maintains separate copies of the data in their respective locations so that each copy can comply with the compliance needs and requirements of its respective application or location. This separated data ownership approach can create a data ownership model that clearly distinguishes data ownership between applications and avoids conflicts between policies.

[0017] Embedded data can be modified from both the host application (the application in which the data is embedded) and the source application (the parent application from which the data type originated). Aspects of the present disclosure provide a mechanism for handling data changes that maintain data consistency between applications associated with the data, thereby facilitating the co-utilization of applications and improving the user experience. For example, if data embedded in a host application is deleted from the source application, that data is also deleted from the host application via a notification queue system. Conversely, if source application data embedded in a host application is deleted from the host application, that data is also deleted from the source application via a notification queue system. In some embodiments, a database function that can deliver reliable notifications between different systems (e.g., applications) can be used. For example, when a task data object is deleted in a task management application, the notification queue system can be used to notify the word processing application in which the corresponding task data object is embedded of the deletion. In one embodiment, the data associated with the task is deleted from an index table accessible from both applications and ultimately from the document of the word processing application in which the corresponding task data object is embedded. In another example of an embodiment, when a task is deleted in a task management application, a queue message containing a notification of the deletion is transactionally scheduled and then asynchronously invoked (e.g., later) by the database system and retried until the normal transmission / reception of the notification is confirmed.

[0018] In some embodiments, each source application data object may have data associated with a record of each application in which it is embedded, in order to notify each application in which a particular source application data object is embedded of changes (e.g., updates, deletions, modifications) to the source application data object that occur at the source application interface. As used herein, the terms "modification" and "change" with respect to a data object shall include "deletion". Thus, when a data object is edited or updated in its respective source application, a notification may be sent to the host application to update the corresponding embedded copy (e.g., the source application data object embedded in the host application file), also referred to herein as the "embedded data object". Conversely, when an embedded source application data object (e.g., an embedded data object) is edited or updated from within the host application (e.g., through the host application interface), a notification may be sent to the source application to update the source copy of the data object (e.g., the source application data object), also referred to herein as the "source data object". In some embodiments, to ensure reliable delivery of the notification, the notification may be resent by the application in which the change occurred until confirmation or approval of receipt of the notification is received from another application (e.g., the application to which the update notification is sent). These notifications allow a team of collaborators to assign tasks related to a project and track whether the assigned tasks have been completed. Embedding the data object in the host application provides a single place where tasks, the individuals to whom tasks are assigned, and the completion status of tasks can be viewed, eliminating the need to search other places to obtain that information.

[0019] Depending on the situation, different access rules (e.g., permitting data display or editing) may be applied to host application files and embedded data. Aspects of the present disclosure provide a mechanism for handling conflicts between permissions so that data can be updated without violating the access rules applied to the host application files or embedded data. For example, modifications to embedded data objects within a host application may comply with the access rules of the host application. This means that only users with the permission to edit or modify the host application can edit or modify the embedded data, in accordance with the access permissions of the host application. Thus, the source application can permit access to modify the data objects (e.g., source application data objects) of the source application to any user who has the access permission to modify the corresponding embedded data objects of the host application.

[0020] Conversely, changes or updates made to a data object of a source application (e.g., a source application data object) can be reflected in the embedded data object of the host application only if the update is issued on behalf of a user who has the access right to make changes to the host application file in which the data object is embedded (e.g., when the change is made by a user). If the user who makes changes to the data object of the source application does not have the access right to make changes to the host application file in which the data object is embedded, the change can be kept pending until another user who has the access right to make changes to the host application file accepts the change and updates the host application file. For example, changes to a data object made in a source application are recorded in a location accessible from both the source application and the host application, but due to lack of access rights, they may not be committed to the host application file in which the data is embedded. In this case, a notification can be presented to the user of the host application who has the access right to make changes to the host application file regarding the pending change, and a prompt can be displayed to accept or reject the change.

[0021] In some embodiments, access checks (e.g., determining whether a user has the access rights necessary to make changes to a particular data object) can occur in both the source application and the host application. In one example, the source application always sends a notification regarding the change to the host application, so that the host application can always perform an access check regardless of whether it can commit the change to the host application file in which the data object with the change is embedded. In this case, as described in more detail below, the host application can obtain the changes made to the data object from either the source application or the host application and record them in another location (e.g., a third location different from where the host application data is recorded and where the source application data is recorded). In another example, the task management application can check whether a user attempting to make changes to a particular data object has the access rights to edit the host application file in which the data object is embedded, and if so, grant the user the right to edit the data in the source application and propagate the changes to the host application.

[0022] In some embodiments, another storage area (e.g., a data store) is maintained to record data associated with source application data objects embedded in a host application file in order to minimize conflicts caused by changes to corresponding data objects within each host and source application and to ensure that up-to-date data objects exist in both the host application and the source application. As described above, if the access rules of the source application and the host application are different (e.g., different sets of access rights for each user), and the user who made the changes does not have access rights to make changes to the host application file, changes made to the data objects of the source application may not be synchronized to the host application (e.g., the corresponding embedded data objects may not be updated with the changes). To ensure that such changes are not lost, they can be recorded in another storage that can serve as the ultimate "trusted source of information" regarding the data objects. In some embodiments, each pair of applications can have the data recorded in their respective data stores. This third location can be a third data store in which all changes and their history related to data objects (including, for example, source application data objects and corresponding embedded data objects) are recorded from both the host application and the source application. In one embodiment, this third storage location can be exclusively managed by the host application (e.g., records of changes to the data are created by the host application regardless of whether the changes were made in the source application or the host application). The third storage location can include all source application data objects embedded in the host application file and all changes made to those data objects.For example, a word processing application can record all task data objects embedded in a document from a task management application, along with all changes previously made to those data objects, in a separate data store. By having a third storage location separate from the storage locations of the data of the host application and the source application respectively, if the third location is fully managed by the host application, the computing cost can be reduced and the data transfer load can be alleviated. This is because such an arrangement can reduce the number of queries and data transfers between the application and each data store, along with the associated computing costs and network bandwidth, especially when they are located geographically apart.

[0023] This third storage area can function as a reliable source of information (e.g., a reliable source of information regarding data objects) because host application files (also referred to herein as "embedded data containers") may be changed such that the embedded data becomes old. For example, in a scenario of a word processing application file having an embedded task data object marked as completed, the word processing application file can be reverted to a previous version in which the embedded task data object was not marked as completed, resulting in the generation of old (e.g., obsolete, inaccurate) embedded task data objects. In another example, an update notification due to a change in an embedded data object that occurred in the host application may not be permanently delivered to the source application (e.g., because the account has been deactivated), and an undesirable inconsistency may occur between the source copy of the data object and the embedded data object. By having a third location that includes a record of the embedded data objects, a user of a host application file having the embedded data objects may not need to prevent the host application file from being reverted to a previous version when it is desired to maintain the most recent representation of the embedded data objects.

[0024] In some embodiments, the third storage location can be an index table within a data store having records of data objects associated with each of the pairs of applications. In some embodiments, the host application maintains a separate storage location for all embedded data that is successfully synchronized with the source application, and can update the storage location according to notifications of data changes received from the source application even if changes cannot be committed to the host application's embedded data container (e.g., the host application file having the corresponding embedded data object) due to access restrictions. In some embodiments, this storage location can be implemented as an embedded data index table, and access (e.g., change authority) to this table can be granted to all users having the authority to change data objects in either the source application or the host application. To ensure data consistency between the source application and the third storage location (e.g., the embedded data index table), periodic consistency check validations can be performed between the storage location of the source application data and the third storage location. Similarly, periodic consistency check validations can be performed between the storage location of the host application data and the third storage location. If a data mismatch is identified between the two locations, a warning or notification is issued or generated. Notifications regarding mismatches between the third storage location and the storage locations of the respective host or source application data can be presented to the users of the respective applications. For example, the host application can use the embedded index table as a reliable source of information for all embedded data and can display a warning to the user if the embedded data within the host application's embedded data container is not synchronized with the index table.

[0025] As described above, in some embodiments, the task management application can function as the source application, and the word processing application can function as the host application. Accordingly, data objects representing tasks can be associated with or obtained from, or generated by, the task management application and embedded in the word processing application. In some embodiments, a list of items such as a checklist can be created within a file of a word processing file (e.g., a shared cloud-based planning document), and the checklist items can become tasks. The text elements and visual elements that make up the checklist items can be visual representations of data objects associated with the tasks. In some embodiments, these data objects can be understood to be embedded data objects associated with corresponding data objects within the task management application. As used herein, a data object that is related to a task and embedded in a host application data container (e.g., a file) is referred to as an "embedded task data object" or an "assigner task object", and a data object related to the same (e.g., corresponding) task in the source application (e.g., the task management application) can be referred to as a "source task data object" or an "assignee task object". It should be understood that the task and its related information can be associated with and anchored to other data and visual elements of the host application's data container, and that the items in the checklist are used as examples for convenience of explanation. Other data and visual elements may be suitable for associating with task-related data objects of other host applications. For example, in other embodiments, the task and its related information (along with the association to the source task data object) can be associated with and anchored to checkboxes, rows or cells, bullet points, words, and ranges of text or symbols in a spreadsheet.

[0026] In some embodiments, an assigner user (the "assigner") can request the creation of a list via the interface of a word processing application (e.g., the host application), create the requested list, and the elements of the list can be data objects associated with tasks. The assigner user can also request and assign a task to another user (the "assignee") via the interface of the word processing application (e.g., the host application). The assigner requests the assignment of a task by selecting or specifying the user who will perform the task and can specify a deadline for completing the task. In some embodiments, the assigner can assign a task to an assignee by entering the assignee's username or address into a text input field or by selecting the assignee user from a list of users. In other embodiments, the assigner can select a user by clicking on a visual representation of the assignee user (e.g., an image, icon, avatar of the assignee user) or by clicking on a series of other interactive graphical elements (e.g., buttons). The assignee user can view the assigned task and information related to that task in a task management application (e.g., the source application). Information related to the task can be included in data objects that define the properties of the task, including the task name, description, due date, and the project or file to which the task is related or in which the task is embedded. In some embodiments, the assigner can reassign a task to a different assignee user by changing the indication of which user the task should be assigned to in the graphical user interface of the host application. This can be done in a manner similar to how the task was assigned to the first assignee. When a task is reassigned, the task is removed from the personal task list of the first assignee (e.g., the task list within the user interface of the task management application), and the task can be added to the personal task list of the new assignee along with its associated information.

[0027] In the graphical user interface of the task management application, the assignee can make various changes to the properties of the task defined by the data object, such as changes to the completion status, task name, due date, memo related to the task, and comments. In some embodiments, some of these changes can be used to update the embedded task data object of the word processing application according to the methods described herein regarding updating the data object of an application based on changes made to the related data object of another application. For example, the change made by the assignee to the completion status of the task in the task management application can be used to update the task completion status (e.g., completed / uncompleted) of the task in the word processing application. When the display of the task completion state of the assignee task object is modified, the modification can be propagated, and corresponding changes are made to the assignee task object of the host application reflecting the updated task completion state. In contrast, in some embodiments, when the assignee makes changes to the task name, due date, memo, or other related information, those changes may remain only visible and accessible to the assignee of the source application (e.g., via the graphical user interface of the task management application) and may not be synchronized with the host application (e.g., by making corresponding updates to the assignee task object in the word processing application). Therefore, even if the assignee changes the task in the source application, the assignee task object may not be affected and may not be modified unless the assignee changes the completion status of the task.

[0028] In other embodiments, when a task is assigned to an assignee, an email notifying the assignee about the assigned task is sent to the assignee. The email may include one or more tasks assigned to the assignee. The assignee can indicate or change the completion status of the task(s) through the graphical user interface of the email application. Changes to the task completion status made in the email can be propagated to the corresponding embedded task data object of the host application and the source data object of the source application. Thus, in one embodiment, when a user indicates that a task is completed via email, the change in the completion status can be used to update the assigner task object of the word processing application and the assignee task object of the task management application.

[0029] If the assignee does not have the permission to change or modify the host application data container (e.g., file) in which the data object associated with the task assigned to the assignee is embedded, when the completion status of the task is changed via the graphical user interface of the source application, a notification may be generated to other users of the host application. The notification or warning is presented to one or more users of the host application who are permitted to make changes to the host application file according to the access permissions of the host application, and may prompt the users to accept the changes made to the completion status of the task associated with the assigner task object. Details regarding the structure of the elements of the systems and methods described herein and the operations performed by the elements are described below with reference to FIGS. 1-6.

[0030] Accordingly, aspects of the present disclosure provide a number of technical advantages, including, for example, a mechanism that can easily embed data from one application into another, thereby creating more advanced integration between applications and reducing the time and computing resources typically consumed by repeated context switching (e.g., switching between applications or interfaces) performed by a user. Other technical advantages include, but are not limited to, providing an automated solution that ensures compliance with potentially competing policies regarding data shared and stored by applications, implementing data consistency between applications, and addressing conflicts between data access permissions between applications, thereby further promoting application interoperability, further improving the user experience, and further reducing the time and computing resources typically spent on manually addressing competing data policies, manually ensuring data consistency, or manually addressing conflicts between data access permissions between applications.

[0031] Further, through selective updates between a host application and a source application, aspects of the present disclosure provide a tracker for tasks specifically assigned to a user that can add meaningful details to improve productivity without affecting the content displayed in the host application. Thus, the mechanisms disclosed herein enable adding personal modifications to task-related data that do not interfere with task-related data associated with the same task displayed to other collaborators, thereby reducing the amount of time and computing resources typically spent by a user to store such personal modifications in another location and switch between this other location and the above applications.

[0032] The examples and embodiments described herein may focus on specific types of applications such as document / word processing applications and task management applications, but it should be understood that the systems and methods disclosed herein can be implemented equally well in various applications and operating environments.

[0033] FIG. 1 shows an example of a system architecture 100 according to an embodiment of the present disclosure. The system architecture 100 (also referred to herein as the “system”) includes at least one client device 110 that can be connected to a server such as a data management platform 120 (e.g., one or more servers) via a network 130. For simplicity, one client device 110 and one data management platform 120 are shown as being connected to the network 130. In reality, there may be additional clients and / or servers. Also, in some cases, a client may perform one or more functions of a server, and a server may perform one or more functions of a client. The client device 110 can access or receive information from the data management platform 120. The system architecture 100 can represent a cloud-based environment, which enables communication between the server(s) hosting the document platform 120 and the client device 110 via the network 130 and allows for the storage and sharing of electronic documents. Alternatively, the system architecture 100 can also be applied to a locally interconnected system. Further, although some aspects of the present disclosure are described with reference to spreadsheets and document applications that manage spreadsheets, those skilled in the art will understand that the systems, methods, functions, and embodiments of the present disclosure can be applied to any type of electronic document and any type of program or service provided by any type of host application.

[0034] In an embodiment, network 130 may include a public network (e.g., the Internet), a private network (e.g., a local area network (LAN) or a wide area network (WAN)), a wired network (e.g., an Ethernet network), a wireless network (e.g., an 802.11 network or a Wi-Fi network), a cellular network (e.g., a long term evolution (LTE) network), routers, hubs, switches, server computers, and / or combinations thereof. Client device 110 may include computing devices such as a personal computer (PC), a laptop, a mobile phone, a smartphone, a tablet computer, a netbook computer, a network-connected television, etc. Client device 110 may be associated with one or more users, and client device 110 may also be referred to as a "user device".

[0035] In the illustrated embodiment, the data management platform 120 can interact with the client device 110 such that the client device 110 cooperates with the data management platform 120 to execute one or more data management applications and manage various documents. For example, the data management application can be an online data management application, a web application, a cloud-based application, a client-based data management application, etc. In some embodiments, the data management application is a cloud-based or web-based productivity suite application that can interact with the web browser 115 (rather than a specified document application) to, for example, present a document, receive user input related to the document, etc. Alternatively, the data management application can be a client-based application (hosted by the client device 110) that provides the functions described herein regardless of the use of the document platform 120. The data management application can include, for example, an email application, a document processing application, a calendar application, a spreadsheet application, a project management application, an online word processing application, an online task management application, and the data management application can function as a host application 150a or a source application 150b. It should be understood that the host application 150a can include an embedded data object from the source application 150b. Alternatively, the data management application can also be executed locally on the client device 110.

[0036] The data management structure created by the client device 110 can be stored by the data management platform 120 in, for example, the data store 140, the host application data store 142, and the source application data store 143, and can include application data objects, embedded data containers, and application graphical user interfaces associated with one or more host applications 150a or source applications 150b. In some cases, the host application 150a can have exclusive access to the host application data store 142, the source application 150b can have exclusive access to the source application data store 143, and both applications can access the data store 140 that can function as a common data store. Although shown as a single device in FIG. 1, the data management platform 120 can be implemented, for example, as a single computing device or as a plurality of distributed computing devices. It should be understood and recognized that whether a device functions as a server or as a client device can depend on the particular application being implemented. That is, whether a computing device is operating as a client or as a server can depend on the context of the role of the computing device within the application. The client-server relationship is created by programs executed on respective devices that have a client-server relationship with each other.

[0037] As discussed above, the interaction between the client device 110 and the data management platform 120 can be implemented through the web browser 115 executed on the client device 110. For example, a data management application such as one of the host applications 150a or the source applications 150b can be a web application executed within the browser program 115. The term browser program is intended to refer to any program that enables a user to view markup documents (e.g., web documents), regardless of whether the browser program is a stand-alone program or an embedded program such as a browser program included as part of an operating system. In some embodiments, the data management applications described herein are implemented as distributed web applications, with portions of each data management application being executed on one or more client devices 110 and the data management platform 120. More specifically, the client device 110 may request a data management application from the data management platform 120. In response, the data management platform 120 may send a portion of the data management application for local execution on the client 110. Thus, the data management application may execute as respective distributed applications across the data management platform 120 and one or more client devices 110. In this way, the client device 110 may not need to locally install any data management applications in order to use the data management platform hosted by the data management platform 120.

[0038] Generally, the functions described in embodiments as being performed by the data management platform 120, or by the host application 150a or source application 150b, can, where appropriate, be performed on the client device 110 in other embodiments. Further, the functions assigned to a particular component can be performed by different components or by multiple components operating in cooperation. The data management platform 120 can also be accessed as a service provided to other systems or devices through an appropriate application programming interface.

[0039] In some embodiments, the data management platform 120 can include an integrated application manager 160 that manages communications and functions as an intermediary between the host application 150a and the source application 150b. In other embodiments, the integrated application manager 160 can reside, in part or in whole, on the client device 110. In still other embodiments, the host application 150a and the source application 150b can reside on the client device 110 and communicate with each other without using the integrated application manager 160 (e.g., via inter-process communication, using a shared data store, etc.).

[0040] In embodiments of the present disclosure, a "user" can be represented as a single individual. However, in other embodiments of the present disclosure, a "user" is an entity controlled by a set of users and / or an automated source. For example, a set of individual users integrated as a community within a social network can be considered a "user". In another example, an automated consumer can be an automated ingestion pipeline such as a topic channel of the content sharing platform 120.

[0041] As described herein, a document can be implemented as a distributed web application where portions of an application are executed on a plurality of client devices 110 and a document platform 120, providing collaboration among multiple users working on a single document. For example, multiple users can edit such a collaborative document simultaneously or in parallel, and the edits of each user can be displayed in real time or near real time (e.g., within a few milliseconds or seconds). When a user edits a document, the edit is sent to the document platform 120 and can then be transferred to other collaborating users who are editing or viewing the spreadsheet. For this purpose, the document platform 120 can handle conflicts among collaborating users, such as when two users attempt to edit a portion of the document simultaneously. For example, the document platform 120 can accept the first edit received or, in some way, prioritize the edits of higher-priority users over those of lower-priority users. If a user's edit is rejected by the document platform 120, the document platform 120 can send a message back to the user notifying the user that the edit was rejected. Thus, multiple users can potentially collaborate on a single document in real time (or near real time). In some embodiments, the parties who can view and collaborate on a particular document can be specified by the original creator of the document. For example, the original creator of the document can be given "administrator" rights that allow the creator to specify permissions for each of the other potential collaborators. The original creator can specify that other collaborators have the right to perform one or more of editing the document, viewing only the document, editing a specified portion of the document, or adding additional users to the list of potential collaborators. For example, a particular user may be able to edit a particular portion of a document, while other specified portions of the document can be "locked" to that user, such that the user can view but not edit the locked portions. In some embodiments, a document can be designated as a "public" document that can be viewed and / or edited by anyone.

[0042] Referring to FIG. 2, which shows the sharing of data between instances of different applications in the data management platform 200, and further elaborating, according to embodiments of the present disclosure, the functions and operations described can be executed using the system 100 described above. The data management platform 200 may include one or more applications such as a host application 150a (e.g., a word processing application) and a source application 150b (e.g., a task management application).

[0043] In some embodiments, the host application 150a can provide one or more host application graphical user interfaces 201a and 201b, through which a user can access one or more host application files 202a and 202b, respectively. The host application files 202a and 202b can include various data types and formats and can include embedded data objects, and thus can be understood as data containers. For example, as shown in FIG. 2, the host application file 202a is associated with the source application and can have data objects that are embedded by anchoring or logical association with visual elements of the host application's graphical user interface 201a and function as embedded source application data objects 210a and 211a. Similarly, the host application file 202b can have three embedded data objects such as embedded source application data objects 212a, 213a, and 214a. Each of the embedded data objects 210a - 214a (also referred to herein as "embedded data objects") can correspond to source application data objects 210b - 214b (also referred to herein as "source copies of the data objects"). Each data object of a pair of corresponding data objects (e.g., 212a and 212b) can be updated based on changes made to other objects within the pair.

[0044] In the illustrated embodiment, source application data objects 210b-214b can be visually displayed, accessed, and modified through their respective source application graphical user interfaces 203a-203c so that a user can, for example, interact with source application 150b. For example, source application graphical user interface 203b can include visual representations of source application data object 211b and source application data object 213b, along with their respective data and information associated with each object.

[0045] In some embodiments, data access policies or permissions can control which users are permitted to view or modify data included in an application through their respective user interfaces. For example, as represented by a one-way arrow, user 220a may have permission to view host application file 202a through host application interface 201a, but may not have permission to edit data included in the host application's file (e.g., permission to make any changes). On the other hand, user 220b may have both viewing and editing permissions with respect to host application file 202a and host application file 202b, as indicated by the two-way arrow. Similarly, user 220c has viewing permission for host application file 202a and both viewing and editing permissions for host application file 202b. In some embodiments, if a user has the necessary permissions to edit data in a host application file, the user can thereby also edit data objects embedded in that file, including, for example, embedded source application data objects 210a-214a.

[0046] The graphical user interfaces 203a - 203c of the source application may be exclusively accessible to a particular user. For example, in the illustrated embodiment, the graphical user interface 203a of the source application may be exclusively accessible to user 220d, along with the source application data objects 210b and 212b contained therein. Similarly, the graphical user interface 203b of the source application may be exclusively accessible to user 220e, along with the presented source application data objects 211b and 213b, and the graphical user interface 203c of the source application may be exclusively accessible to user 220f, along with the presented source application data object 214b. Instances or respective copies of the data objects can be updated by changes made via the graphical user interface (GUI) of either the host application or the source application. As can be understood in more detail with reference to FIG. 3, which will be described below, the latest copies of the data objects of each application are maintained through updates and change notifications to the data of the data objects.

[0047] In addition to the above description, controls may be provided to the user that enable the user to make selections regarding whether, and when, the systems, programs, or functions described herein enable the collection of user information (e.g., information regarding the user's social network, social actions, or activities, occupation, user preferences, or user location), and whether content or communications are sent from the server to the user. Further, certain data may be processed in one or more ways such that information that can identify an individual is removed before the data is stored or used. For example, a user's identity may be processed so as not to identify information that can identify the individual user, or, if location information is obtained (such as at the city, zip code, or state level), the user's geographical location may be generalized so as not to identify the user's specific location. Accordingly, the user may control what information is collected about the user, how that information is used, and what information is provided to the user.

[0048] FIG. 3 is a block diagram showing data synchronization and storage in system 300 between instances of different applications, such as host application 302 and source application 304, according to some embodiments. Data objects can be generated in host application 302 via host application GUI 310 or in source application 304 via source application GUI 311. However, unlike source application GUI 311, host application GUI 310 can include embedded data objects 320a, 320b. Embedded data objects can be associated with corresponding source application data objects. It should be understood that the terms "embedded data object" and "embedded source application data object" can be used interchangeably herein. Further, it should be understood that the terms "source data object", "source application data object", and "source copy of a data object" can be used interchangeably herein. For example, embedded source application data object 320a can be associated with a corresponding source copy of data object 321a, and embedded data object 320b can be associated with source data object 321b. Each of the corresponding data objects can represent the same conceptual element (e.g., a task), but can have associated data or metadata depending on the application in which it is included.

[0049] In some embodiments, each application may have its own exclusive data store for recording the data of that respective application. For example, host application 302 can access host application data store 342 to record the data necessary for its operation. For example, host application 302 can record, as records 350a and 350b respectively, the files of host application 310 and the data representing the embedded data objects 320a and 320b contained in those files in host application data store 342. Similarly, source application 304 can access source application data store 343 to record the data necessary for its operation. For example, source application 304 can record, as records 351a and 351b respectively, the source application GUI 311 and the data representing the source data objects 321a and 321b contained in the source application GUI 311 in source application data store 343. The records contained in the data store may include the data defining the data object and the history of changes applied to the data object. For example, record 350b may include the data related to embedded data object 320b and all the changes that have been applied to that data so far. In some embodiments, host application data store 342 is exclusively accessible by host application 302, and source application data store 343 is exclusively accessible by source application 303. By having a separate data store for each application, each application may be able to operate according to its respective compliance policy with respect to the data. Further, both applications can access a shared or common data storage location in order to maintain a common source of up-to-date information on corresponding data objects between a pair of applications.

[0050] Thus, in some embodiments, both the host application 302 and the source application 304 can access a common data store 340. Each application can access the common data store 340 either directly or through another application. The common data store 340 can store records 322a, 322b corresponding to the data objects of the host application 302 and the source application 304. For example, the embedded data object 320a from the host application 302 associated with the source application data object 321 can have a corresponding record 322a stored in the common data store 340. The record 322a can include the data of the latest version of the corresponding data object and the record of all changes that have been made to that data so far. In some embodiments, each time a data object is generated or embedded in a host application file (e.g., via the GUI 310), a corresponding record is created in the common data store. Thereafter, each time a change is made to a data object, either by changing the embedded data object of the host application 302 or by changing the source data object of the source application 304, the change can be recorded in the common data store. Thus, as described above, the host application 302 and the source application 304 can have different access permissions and rules for different users, but whenever a change is made to a data object in either application, regardless of which application the change originated from, the change can be propagated to the corresponding record in the common data store 340.

[0051] In some embodiments, the common data store may include an embedded data index table that can be managed by the host application 302. For example, after the source data object 321b is generated and embedded in the host application 302 as the embedded source application data object 320b, if the source data object 321b is modified through the source application GUI 311, a notification is sent from the source application to the host application 302, and the corresponding embedded data object 320b is updated according to the added changes. Then, if the update is permitted by the access permission, the update can be executed in the host application 302, or, if the access permission does not permit the host application 302 to make changes by the user who made the changes to the source data object, a notification regarding the update can be generated. However, regardless of whether the user who made the changes to the source application data object had the necessary permissions, the host application (or, alternatively, the source application) can record the changes in the embedded data index table of the common data store 340 so that the changes made to the data object are not lost.

[0052] This common data store 340, or in some embodiments, an embedded data index table included within the common data store 340 can be used to perform periodic data inconsistency checks. For example, at regular time intervals, data associated with a data object can be compared between the host application data store 342 and the common data store 340. Similarly, at regular time intervals, data associated with a data object can be compared between the source application data store 343 and the common data store 340. If the data associated with a data object contained in one data store does not match the data associated with the data object contained in the other data store, a notification of that inconsistency is generated and presented to the user of either application. Alternatively, if an inconsistency is detected, the data associated with the data object common data store 340 can be used to replace the data associated with the data object in the other data stores and, accordingly, update the respective application GUI data objects. Embodiments of how tasks and associated data objects are created and assigned will be described in more detail below with reference to FIGS. 5A-5B.

[0053] FIGS. 4A and 4B show examples of graphical user interfaces (GUIs) provided by a productivity application and a task management application, respectively, according to some embodiments. In some embodiments, the productivity application GUI 402 can be a GUI provided by a cloud-based or client-based word processing application composed of embedded data objects from the task management application.

[0054] The productivity application can function as a host application 150a and have an associated graphical user interface (GUI) 402 that enables a user to interact with and work on files of the productivity application (e.g., host application data containers). The productivity application GUI 402 can be configured to present a list, such as a checklist of items that can be defined as embedded data objects 416 associated with one or more tasks 412a, 412b. In the illustrated example, the “Todo” list includes two tasks, namely, the task 412b of “completing the research plan,” and each task can be defined as an embedded task data object (e.g., assignee task object) 416 associated with a source task data object (e.g., assignee task object) 422 that will be described in more detail below.

[0055] In some embodiments, the visual representation of the embedded task data object 416 may have information related to each associated task that is displayed to the user of the productivity application GUI 402. For example, the name or title of task 412 may be displayed along with a completion status indicator 418 indicating that the title “Completion of Research Plan” has been completed. The user can assign tasks to another user through interface 410. For example, in the illustrated embodiment, the assigner user can assign task 412a by modifying the embedded task data object, specifying the assignee user's email in field 414, or selecting the assignee user's avatar 419. In some embodiments, assigning a task to a user may include generating a graphical representation of the assignee user (a “graphical assignee user representation”), such as an avatar placed next to the task or the embedded task object 416, to indicate that the task has been assigned to the assignee user. In the illustrated embodiment, the productivity application 402 sends a notification to the task management application 404 indicating that task 412a, entitled “Recruitment for Future Research,” has been assigned to the assignee user by the assigner user.

[0056] The task management application can present a GUI 404 that includes a graphical representation 420 of a data container associated with a task, having one or more interactive graphical elements 424a - 424d that include information associated with the task. The graphical representation 420 can be based on one or more data objects associated with each task. For example, the graphical elements 424a - 424d are based on task properties 422 associated with the embedded task data object 416 and can include information 414 related to the task. In some embodiments, the graphical element 424a can represent a completion indicator, can include information regarding the completion status of the task, and can be toggled to indicate whether the task is completed. The graphical element 424b can be a text field, can include information 414 regarding the title of the task, and can be modified by the assignee user to change the name of the task in the task management application GUI 404. The graphical element 424c can represent information 414 including notes or comments related to the task, can be modified by the assignee user, and can have text content related to the task added or deleted that is only viewable by the assignee user. The graphical element 424d can represent a date field, can include information 414 regarding the due date of the task, and can be modified by the assignee user to change a personal due date that may not be synchronized with the due date assigned by the assigner user.

[0057] In some embodiments, when an assignee modifies information related to a task (e.g., by toggling the completion indicator 424a) to indicate a change in the completion status of the task, the task management application can send a notification to the productivity application to perform a corresponding update. The productivity application can update the embedded task data object with a modification corresponding to the modification made by the assignee user in the task management application GUI 404. The productivity application GUI 402 can function as a checkbox that is checked or a strikethrough of the task title as an indicator 418 of the changed (e.g., completed) completion status of the corresponding embedded task data object, and can be displayed to the assigner, who is the user of the productivity application file in which the data object is embedded. In particular, changes made in the task management application to information not related to the completion status of the task are not synchronized with the productivity application. A more detailed description of how tasks are assigned and modified among users of different applications is provided below with reference to FIGS. 5A and 5B. The corresponding methods 500a and 500b can be executed by processing logic that can include hardware (circuits, dedicated logic, etc.), software (e.g., instructions executed on a processing device), or a combination thereof. In some embodiments, some or all of the operations of methods 500a and 500b can be executed by the host application 150a, the source application 150b, or the integrated application manager 160 of FIG. 1.

[0058] FIGS. 5A and 5B respectively show flow diagrams of methods 500a and 500b for assigning and editing tasks among different applications from the perspective of users of the host application and the source application. Method 500a is related to a task being assigned and tracked from the perspective of the source application (e.g., the productivity application 402), and method 500b is related to a task being assigned and modified from the perspective of the source application (e.g., the task management application 404).

[0059] In block 502a, the processing logic can generate data objects associated with tasks displayed in the user interface of the productivity application. In some embodiments, the data object can be an embedded task data object of the host application. In block 502, to create a task and generate a data object for the task, the processing logic receives user input from an assigner user indicating a request to create a task (e.g., via the interface of the productivity application 402) and can present a visual representation of the task to the assigner user (e.g., via the interface of the productivity application 402). In block 504a, the processing logic can receive user input indicating that the task is to be assigned to an assignee and, in response, assign the task to the assignee. Assigning the task to the assignee can include, in block 505a, selecting the assignee user from a user list based on the assigner user's input or identifying the assignee user according to the method described with reference to FIG. 4 above. In some cases, the processing logic can reassign the task to another assignee in block 506a in a manner similar to how the task was initially assigned. For example, in block 506a, the processing logic can receive input from the assigner user indicating another assignee for the task and can add another assignee user instead of or in addition to the assignee user to whom the task was previously assigned.

[0060] In block 508a, the processing logic can send a notification indicating the task and its assignment to the assignee to the source application, and present a visual representation of the task (e.g., via the user interface of the source application) so that the assignee can confirm it. The visual representation of the task can have one or more interactive graphical elements 424a - 424d, for example, in the interface of the source application. The processing logic can also, in block 510a, send an email notifying the assignee of the assigned task to the assignee. At this point, the assignee can view the assigned task within the source application. For example, when a task is assigned by the assigner in a productivity application, the assignee can view and edit the properties of the task in the GUI of the task management application. In block 512a, the processing logic can receive a notification from the source application having an update indicating a change in the completion status of the task. For example, in block 512a, the processing logic can receive user input from the assignee user regarding one of the interactive graphical elements related to the completion status of the task indicating a change in the completion status of the task. In this way, the productivity application can receive an update indicating that the task has been completed from the task management application. As a result, the processing logic can, in block 514a, send a notification indicating the modified completion status of the task to the host application. In this way, the host application can modify the data object associated with the task within the user interface of the host application and visually display the change in the status of the task (e.g., a change applied to the appearance of the visual representation) to update the visual representation of the task. For example, it can turn on a checkbox in an embedded data object of the host productivity application or strike through the title of the task. It can be understood that the mirrored method 500b executed on the source application side operates in conjunction with the elements of the method 500a described above.

[0061] In some embodiments, the processing logic can receive a notification indicating that a task has been assigned to an assignee at block 508b. This notification corresponds to the notification sent from the host application to the source application at block 508a. In other embodiments, the processing logic can receive an email containing a notification of the assigned task at block 510b. This email can correspond to the email sent at block 510a.

[0062] In block 509b, the processing logic can present a graphical representation 420 of a data container associated with a task and a visual representation 422 of the task to the graphical user interface (GUI) of the source application. The graphical representation can include one or more interactive graphical elements 424a-424d (e.g., text fields or completion status indicators) that contain information associated with the task. One of the interactive graphical elements can correspond to the completion status of the task based on input from the user and can indicate a change thereto. In some embodiments, the interactive graphical elements can include a display of the completion status of the task, the title of the task, the deadline, and notes and comments related to the task. The information of the interactive graphical elements can be changed in block 513. The processing logic can modify the completion status of the task in block 511 based on user input related to the graphical elements associated with the display of the task status. An assignee user can provide such input, for example, by modifying the information of one of the graphical elements such as the completion status indicator 424a. In block 512, the processing logic can send a notification indicating the modified completion status of the task from the source application to the host application. This indication of the change in the completion status can correspond to the update of the task status received in block 512. In particular, some of the changes made in block 513 can be exclusively included within the user interface of the source application and thus not be displayed or accessible to the task assigner. The processing logic can receive user input indicating a change to a property of the task (e.g., the title of the task, the deadline of the task, the comment / memo of the task, etc.) and can modify the interactive graphical element corresponding to the property based on the user input. In some embodiments, the processing logic can prevent notification to the host application about a change to a property of the task occurring via the source application based on the settings of the interactive graphical element corresponding to the property.Thus, due to the access permission rules, the source application cannot access the assignee user of the host application. Therefore, in some embodiments, changes related to tasks within the source application (e.g., assignee task objects) by the assignee can be made invisible to the assignee user, provided that the change is not related to the completion status of the task.

[0063] FIG. 6 is a block diagram illustrating an exemplary computer system according to an embodiment of the present disclosure. The computer system 600 can be the server machine 130 or the client device 110 of FIG. 1. The machine can operate as a server or an endpoint machine in an endpoint server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine can be a television, a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile phone, a web appliance, a server, a network router, a switch or bridge, or any machine that can execute (sequentially or otherwise) a set of instructions that specify operations to be performed by that machine. Further, although only a single machine is illustrated, the term "machine" shall also include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0064] The exemplary computer system 600 includes a processing device (processor) 602, a main memory (memory device) 604 (e.g., dynamic random access memory (DRAM) such as read-only memory (ROM), flash memory, synchronous DRAM (SDRAM), double data rate (DDR SDRAM), or DRAM (RDRAM)), a static memory 606 (e.g., flash memory, static random access memory (SRAM)), and a data storage device 618, which communicate with each other via a bus 640.

[0065] The processor (processing device) 602 represents one or more general-purpose processing devices such as a microprocessor, a central processing unit, etc. More specifically, the processor 602 can be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets, or a processor implementing a combination of instruction sets. The processor 602 can also be one or more dedicated processing devices such as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), a network processor, etc. The processor 602 is configured to execute instructions 605 for performing the operations discussed herein (e.g., for generating, embedding, updating data objects, and for assigning and modifying tasks in various applications).

[0066] The computer system 600 may further include a network interface device 608. The computer system 600 may also include a video display unit 610 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an input device 612 (e.g., a keyboard, an alphanumeric keyboard, a motion sensor input device, a touch screen), a cursor control device 614 (e.g., a mouse), and a signal generation device 620 (e.g., a speaker).

[0067] The data storage device 618 may include a non-transitory machine-readable storage medium 624 (which is also a computer-readable storage medium) storing one or more sets of instructions 605 that embody one or more of the methodologies or functions described herein (e.g., generation, embedding, updating of data objects, and assignment and change of tasks in various applications). The instructions may be present, in whole or at least in part, within the main memory 604 and / or within the processor 602 while being executed by the computer system 600, and the main memory 604 and the processor 602 also constitute a machine-readable storage medium. The instructions may be further transmitted or received via the network 630 through the network interface device 608.

[0068] In one embodiment, the instructions 605 include instructions for generating, embedding, holding, and updating data objects among different applications. The computer-readable storage medium 624 (machine-readable storage medium) is shown as a single medium in the exemplary embodiment, but the terms "computer-readable storage medium" and "machine-readable storage medium" should be construed to include a single medium or multiple media (e.g., centralized or distributed databases, and / or associated caches and servers) storing one or more sets of instructions. The terms "computer-readable storage medium" and "machine-readable storage medium" should be construed to include any medium that can store, encode, or carry a set of instructions executable by a machine and cause the machine to execute one or more of the methodologies of the present disclosure. Thus, the terms "computer-readable storage medium" and "machine-readable storage medium" shall include, but not be limited to, solid-state memory, optical media, and magnetic media.

[0069] References to "one implementation" or "an implementation" throughout this specification mean that a particular feature, structure, or characteristic described in connection with the implementation is included in at least one implementation. Thus, the phrases "in one implementation" or "in an implementation" that appear in various places in this specification may, but do not necessarily, refer to the same implementation. Further, the particular features, structures, or characteristics may be combined in any suitable manner in one or more implementations.

[0070] As used in any detailed description or claims, the terms "includes", "including", "has", "contains", their variants, and other similar words are intended to be as inclusive as the term "comprising" as an open transitional word without excluding additional elements or other elements.

[0071] As used herein, terms such as "component", "module", "system", etc. are generally intended to refer to entities related to computer-related entities, hardware (e.g., circuits), software, combinations of hardware and software, or entities related to an operating machine with one or more specific functions. For example, a component can be, but is not limited to, a process executed on a processor (e.g., a digital signal processor), a processor, an object, an executable file, an execution thread, a program, and / or a computer. By way of illustration, both an application executed on a controller and the controller can be components. One or more components can exist within a process and / or an execution thread, and a component can be localized on one computer and / or distributed between two or more computers. Further, a "device" can be provided in the form of specially designed hardware, general-purpose hardware specialized by the execution of software that enables the hardware to execute a specific function (e.g., generation of a point of interest and / or a descriptor), software on a computer-readable medium, or a combination thereof.

[0072] The foregoing systems, circuits, modules, etc. have been described in terms of the interactions between a plurality of components and / or blocks. Such systems, circuits, components, blocks, etc. may include those components or designated sub-components, a part of the designated components or sub-components, and / or additional components, and it will be understood that they follow the various permutations and combinations described above. Sub-components may not be included in the parent component (hierarchical type), but may also be implemented as components communicatively coupled to other components. Further, it should be noted that one or more components may be combined into a single component providing an integrated function, or may be divided into several separate sub-components, and that any one or more intermediate layers, such as a management layer, may be provided to communicatively couple with such sub-components to provide an integrated function. Any component described herein may also interact with one or more other components not specifically described herein but known to those skilled in the art.

[0073] Furthermore, the words "example" or "exemplary" are used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as "exemplary" should not necessarily be construed as more preferred or advantageous than other aspects or designs. Rather, the use of the words "example" or "exemplary" is intended to present concepts in a concrete manner. As used in this application, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless otherwise specified or clear from the context, "X uses A or B" is intended to mean a natural inclusive substitution. That is, "X uses A or B" is satisfied in any of the following cases: when X uses A, when X uses B, or when X uses both A and B. Further, the articles "a" and "an" used in this application and the appended claims should generally be construed to mean "one or more" unless otherwise specified or it is clear from the context that the singular form is being referred to.

[0074] Finally, the embodiments described herein include the collection of data that describes a user and / or the user's activities. In one embodiment, such data is collected only if the user consents to the collection of this data. In some embodiments, the user is asked to explicitly permit the data collection. Further, the user may opt-in or opt-out of participating in such data collection activities. In one embodiment, the collected data is anonymized before any analysis is performed to obtain any statistical patterns so that the user's identity cannot be identified from the collected data.

Claims

1. A memory device, coupled to the memory device, receives user input indicating a request to create a task via a user interface of a first application, presents a visual representation of the task to the user interface of the first application, receives user input indicating an assignment of the task to an assignee on behalf of an assigner user, sends a first notification indicating the task and the assignment of the task to the assignee to a second application different from the first application, receives a second notification from the second application indicating a change in the status of the task, and a processing device that modifies the visual representation of the task to graphically show the change in the status of the task to the user interface of the first application. A system comprising:

2. The system according to claim 1, wherein the processing device further sends an email notifying the assignee of the assigned task to the assignee.

3. To present the visual representation of the task to the user interface of the first application, the processing device further: generates a data object defining a plurality of properties of the task based on the user input indicating the request to create the task, and generates the visual representation of the task based on the plurality of properties defined by the data object. The system according to claim 1.

4. The system according to claim 3, wherein the processing device further adds the assignee indicated by the user input to the data object.

5. The processing device further: receives a user indicating a second assignee of the task, and adds the second assignee to the data object of the task. The system according to claim 3.

6. The system according to claim 1, wherein the first application is a productivity suite application.

7. The system according to claim 1, wherein the second application is a task management application.

8. Receiving user input indicating a request to create a task via a user interface of a first application, Presenting a visual representation of the task in the user interface of the first application; Receiving user input indicating an assignment of the task to an assignee; Sending a first notification indicating the task and the assignment of the task to the assignee to a second application different from the first application; Receiving a second notification from the second application indicating a change in the status of the task; Modifying the visual representation of the task to graphically show the change in the status of the task in the user interface of the first application. A method comprising the steps of:

9. Presenting the visual representation of the task in the user interface of the first application comprises: Generating a data object defining a plurality of properties of the task based on the user input indicating the request to create the task; Storing the data object in a data store; Generating the visual representation of the task based on the plurality of properties defined by the data object. The method according to claim 8, further comprising the steps of:

10. The method according to claim 9, further comprising adding the assignee indicated by the user input to the data object.

11. Receiving user input indicating a second assignee of the task; The method according to claim 10, further comprising adding the second assignee to the data object of the task.

12. The method according to claim 8, wherein the first application is a productivity suite application.

13. The method according to claim 8, wherein the second application is a task management application.

14. The method according to claim 8, further comprising sending an email notifying the assignee of the assigned task to the assignee.

15. Receiving, by a first application, a notification indicating an assignment of a task to an assignee from a second application different from the first application; Presenting a visual representation of the task on the graphical user interface (GUI) of the first application, the visual representation including one or more interactive graphical elements, wherein one of the one or more interactive graphical elements corresponds to the completion status of the task, and the presenting; Modifying the completion status of the task based on user input related to the one of the one or more interactive graphical elements; A method comprising: sending a notification indicating the modified completion status of the task to the second application.

16. Receiving a second user input indicating a change in a property of the task; Modifying an interactive graphical element corresponding to the property based on the second user input; The method according to claim 15, further comprising preventing notification of the second application about the change in the property of the task.

17. The method according to claim 16, wherein the interactive graphical element corresponding to the property has a setting for preventing the change in the property from being communicated to the second application.

18. The method according to claim 15, wherein the first application is a task management application.

19. The method according to claim 15, wherein the second application is a productivity suite application.

20. The method according to claim 15, further comprising sending an email indicating the modified completion status of the task to the assignee of the task.

Images