WO2018073649A1 - Gestion de bureau et transfert de données dans un environnement multi-ordinateurs - Google Patents

Gestion de bureau et transfert de données dans un environnement multi-ordinateurs Download PDF

Info

Publication number
WO2018073649A1
WO2018073649A1 PCT/IB2017/001469 IB2017001469W WO2018073649A1 WO 2018073649 A1 WO2018073649 A1 WO 2018073649A1 IB 2017001469 W IB2017001469 W IB 2017001469W WO 2018073649 A1 WO2018073649 A1 WO 2018073649A1
Authority
WO
WIPO (PCT)
Prior art keywords
context
task
computing device
data
user
Prior art date
Application number
PCT/IB2017/001469
Other languages
English (en)
Inventor
Adam HORNYAK
Orsolya KASZA
Attila Kurucz
Adam MAKAI
Zoltan Mihaly
Laszlo Molnar
Csaba SALANKI
Levente SZILAGYI
Laszlo Vincze
Balint ZSIGA
Szilard BORTNYIK
Bela Kovacs
Gergo FODI
Andras Nemeth
Miklos PAL
Tamas TARJANYI
Arpad PUSZTAI
Marton ARNYASI
Original Assignee
Basewalk Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Basewalk Ltd. filed Critical Basewalk Ltd.
Publication of WO2018073649A1 publication Critical patent/WO2018073649A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/461—Saving or restoring of program or task context
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3438—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment monitoring of user actions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3476—Data logging
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/535—Tracking the activity of the user
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/86—Event-based monitoring

Definitions

  • the desktop displayed to the user while the user is working on a particular task may have a plurality of windows, applications, and/or resources open on the computer desktop that are specific to that task.
  • the system is shut down (e.g., at the end of the day), or the user switches to another task or device before a task is complete, reconfiguring the desktop to restart work on the task and can take considerable effort.
  • This effort imposes a cost on switching tasks that contributes significantly to the amount of time spent performing tasks. This cost is often incurred each time a person switches between computing devices or tasks. For example, when attempting to resume a task from a home computer after leaving the office.
  • a computer system includes one or more processors and a memory coupled to the one or more processors.
  • the memory stores program code that, when executed by at least one of the one or more processors, causes the computer system to receive first data defining an event in a first computing device, and determine, using the first data, if the event represents a context switch between a first context and a second context on the first computing device.
  • the program code further causes the system to store an end time for the first context in a first data object associated with the first context, store a start time for the second context in a second data object associated with the second context.
  • the program code further causes the computer system to determine an amount of time the first computing device operated in the first context based on the start time and the end time in the first data object.
  • a method of tracking computer usage includes receiving the first data defining the event in the first computing device, and determining, using the first data, if the event represents the context switch between the first context and the second context on the first computing device. In response to determining the event represents the context switch, the method further comprises storing the end time for the first context in the first data object associated with the first context, and storing the start time for the second context in the second data object associated with the second context. The method further includes determining the amount of time the first computing device operated in the first context based on the start time and the end time in the first data object.
  • a computer program product for tracking computer usage includes a non-transitory computer-readable storage medium and program code stored on the non-transitory computer- readable storage medium.
  • the program code When executed by one or more processors, the program code causes the processors to receive the first data defining the event in the first computing device and determine, using the first data, if the event represents the context switch between the first context and the second context on the first computing device. In response to determining the event represents the context switch, the program code further causes the one or more processors to store the end time for the first context in the first data object associated with the first context, and store the start time for the second context in the second data object associated with the second context. The program code further causes the one or more processors to determine the amount of time the first computing device operated in the first context based on the start time and the end time in the first data object.
  • the cost of switching between tasks may be driven by one or more of the following factors: total number of tasks, complexity of each task (number of related resources), how well all the resources belonging to tasks are organized, how much time was spent on a task previously (total sessions), how long it has been since the user spent time on the task, and how many mental state switches have occurred since the task was last focused on.
  • Embodiments of the invention solve the problems of working on and switching between tasks by collecting and organizing all necessary information about tasks in a virtual desktop that can be restored in a computer device upon request.
  • this may achieved by a computer system including at least one processor and a memory coupled to the processor.
  • the memory may include program code that, when executed by the one or more processors, causes the computer to automatically collect events and metadata about what is happening inside one or more electronic device(s) with which the user interacts to complete or uses to make progress on a task.
  • This data may be stored in a database indexed based on the user, task, or other suitable characteristics.
  • the program code may further cause the computer system to provide a user interface for user input to provide additional information with the least amount of interference with the actual task at hand.
  • the program code may further cause the computer system to organize the collected information into predefined objects and object classes, and label these objects. This labeling may be based on, for example, how the objects are organized in a database.
  • FIG. 1 is a diagrammatic view of an exemplary operating environment including a plurality of user devices in communication with a server over a network, and a database.
  • FIG. 2 is a diagrammatic view of an exemplary computer that may be used to provide the operating environment of FIG. 1.
  • FIG. 3 is a diagrammatic view of a client application that may reside on the user devices of FIG. 1.
  • FIG. 4 is a diagrammatic view of a plurality of modules that may reside on the server of FIG. 1.
  • FIGS. 5A-5G are diagrammatic views of data objects that may be used to store and organize data on the database of FIG. 1
  • FIGS. 6 and 7 are diagrammatic views illustrating communication between the user device 12 and server 14 of FIG. 1.
  • FIGS. 8 and 9 are diagrammatic views of applications that may reside on the server of FIG. 1.
  • FIGS. 10 and 11 are diagrammatic views illustrating communication between the user device 12 and server 14 of FIG. 1.
  • FIG. 12 is a diagrammatic view of a time line of activities, events, and context switches that may occur on a user device of FIG. 1.
  • FIGS. 13 and 14 are diagrammatic views of application window frames that may be displayed by the user device of FIG. 12
  • FIG. 15 is a diagrammatic view of the application window from FIGS. 13 and 14 including a visual element for decorating the application window.
  • FIGS. 16-18 are diagrammatic views of windows for displaying resources grouped by tasks.
  • FIG. 19 is a diagrammatic view of resources grouped by tasks on a chronological timeline.
  • FIG. 20 is a diagrammatic view illustrating a flow of data from event listeners on the user devices of FIG. 1
  • Desktop manager One or more applications and/or systems comprising a software suite and/or software defined process for implementing embodiments of the invention.
  • the desktop manager may include one or more client applications running on a user device, and one or more server applications running on a server.
  • User A person who has the desktop manager, or a portion thereof, installed and operating on one or more electronic devices.
  • Task A task may refer to an activity that needs to be accomplished within a defined period of time or by a deadline to work towards work-related goals. In the context of one or more embodiments of the present invention, this definition may specifically relate to tasks that are executed by users using a computer or any similar electronic device including, but not limited to, notebook computers, tablet computers, mobile phones, and/or smart watches.
  • Resource Resources are entities the user interacts with during the execution of a task.
  • this definition may include, for example, local files, folders, web pages and applications.
  • this definition can be extended to, for example, cloud based resources, geographical locations and people the users call, send text messages to, or chat with.
  • Task Context The task context may include the collection of all resources and their current states that belong to or are being used to complete a certain task. In practice, this can mean, for example, the window of an open document that the user is editing and a few open web pages in a browser window that the user needs for their work.
  • the task context may contain resources that belong to the task, but that are not currently open on the desktop.
  • Each user device may display a full up-to-date list of all resources that belong to a task.
  • the user may also be able to access the resources associated with the task context from the device. Users may move resources between contexts if they are not satisfied with the automatic allocation made by the desktop manager, e.g., by dragging an icon from one task context window to another. Moving a resource from one task to another may also cause the system to reallocate the time tracked to that task to the other task.
  • Embodiments of the invention may associate the task context with a virtual desktop.
  • Each virtual desktop may comprise an "image" of the desktop that includes the user data, icons, windows, web pages, files, folders, and/or applications (i.e., resources) displayed on or accessed by the computing device during a task context session.
  • the virtual desktop may define the state of all files and applications that are open on the computing device during the task context session.
  • the virtual desktops may facilitate switching between tasks by allowing the user to work on another task while leaving a previous task as it is, in any state, and allow the user to restore the desktop at a later time and/or on another device.
  • the virtual desktop may preserve resources as they were when the user left. This allows users to avoid searching for files and opening applications. Instead, the user can merely click back into the context as it existed when the task was interrupted.
  • Virtual desktops may also facilitate working on a task across multiple devices by enabling a task context to be invoked on a different user device than was last used to work on the task, e.g., when a user wants to work from home on a task that was started on an office desktop computer. Users may separate their open resources into virtual desktops, in which case the desktop manager may create as many virtual desktops as the number of tasks the user is actively working on.
  • embodiments of the invention may also allow users to open any resource on any virtual desktop, in which case there may be fewer virtual desktops than tasks, i.e., more than one task context may be included on a single virtual desktop.
  • the use of virtual desktops may thereby facilitate handing of task contexts extending over multiple devices.
  • Activity In the terminology of the desktop manager, one activity is one continuous, uninterrupted interval spent interacting with one single resource while executing a task. An example of this may be the time spent using an application without switching to another window or a phone call with a person.
  • Events An event is a short or zero duration occurrence that causes a change in the current activity. Most events are generated by the user during the normal execution of the tasks. Examples of events may include switching windows, starting or finishing a chat or a call, and/or locking/unlocking the device. An event, like clicking into another window, may normally cause a change in the current activity, and may also cause a task context switch. An activity may be started by an event (like opening a window) and finished by another event (like clicking into another window).
  • Task Session A task session is one continuous, uninterrupted interval between two context switches, spent using the resources that belong to the context of one task.
  • one task session covers the series of activities that the user executes without switching tasks, i.e. breaking the mental context associated with one task.
  • the execution of a complex task from start to completion may happen in several sessions, which may sometimes span several hours or days interspersed by sessions from other tasks.
  • Resource Association is a link between a resource and a task.
  • the association can be created manually by the user or dynamically by the computer when the user accesses a resource (e.g. opens a file) while working in the context of a task.
  • An association can be permanent like a file/document that is always associated with the same task or it can be temporary, like a running application where the association is lost when the resource is released (application closed). If a resource is not exclusively associated with a specific task, the resource can be shared among other tasks permanently or temporarily.
  • Embodiments of the invention may track the amount of time the user spends working in a particular task context (e.g., working in a virtual desktop associated with a task and/or using a resource associated with the task) and adds this time to the total time tracked for the task.
  • the time measured may be made up of the time of individual activities. Time measurement may be continuous, which means the user is always considered to be working on a task.
  • a context switch e.g., the user moves from one virtual desktop to another
  • the time tracking for the current task may be stopped, and time tracking may be initiated for the new task.
  • a default desktop i.e.
  • the system may be configured so that logged time cannot be deleted by the user. In this case, the system may allow users to reassign measured time to another task, such as the unassigned or default task, but the time spent using the computer may be permanently logged.
  • the user may not need to switch virtual desktops or explicitly express an intention to switch tasks in order for the desktop manager to track time spent on a task. For example, if the desktop manager detects a context switch to another task, the desktop manager may start tracking time for the other task. The user may be notified about the switch to provide the user with an opportunity to overrule the switch. In case the user intervenes and overrules the automatic switch decision made by the desktop manager, the time already measured to the new task after the automatic switch may be moved to the task the user creates or selects (e.g., the original task). This automatic switching between tasks may be referred to herein as implicit task switching.
  • Users may also use explicit task switching to notify the desktop manager that they have switched tasks, and/or add time to their tasks manually. This may be necessary to track time when a user device is not being used to work on a task. For example, attending a meeting that belonged to the task. This feature allows the user to add the exact amount of time worked on the task while not using the computer.
  • the desktop manager may query the user after a period of inactivity (e.g. returning from a locked state) whether the elapsed time should be added to the open task. Measured and manually added times may be flagged in the database so that they are distinguished from other types of tracked time.
  • the desktop manager may be configured to prevent the user from manually adding time that overlaps any other manual or measured time interval.
  • FIG. 1 depicts an exemplary operating environment 10 in accordance with an embodiment of the invention.
  • the operating environment 10 may include a plurality of user devices 12, and a server 14 that are in communication over a network 16.
  • the network 16 may include one or more private or public networks (e.g., the Internet, Local Access Networks (LANs), Wi-Fi hotspots, cellular carriers, etc.) that enable the exchange of data between the user devices 12 and the server 14.
  • the server 14 may be in communication with a server database 18.
  • Each user device 12 may include a client application 13 (FIG. 3) that runs in the background and provides desktop management, task context management, and time tracking features.
  • the client application 13 may be controlled by the user through a widget that is displayed by the user device 12.
  • the client application 13 may be a thick client that is resident on the user device 12. In the absence of a network connection, the client application 13 may operate autonomously without the server 14.
  • the client application 13 may collect, handle, and store data related to the tasks executed using the user device 12.
  • the client application 13 may persistently store data in a local database on the user device 12.
  • the client application 13 may synchronize its local data with data stored on the server database 18. This updating may occur at predetermined intervals while a connection is available.
  • the user devices 12 may be a desktop computer, a smart phone, tablet computer, or other suitable computing device. At different times, a given user may work on a task from different user devices 12, e.g., from a desktop computer at the office and from a laptop computer will commuting home on a train.
  • the server 14 may store at least a portion of the data received from the user devices 12 in the server database 18.
  • the client application 13 running on the user device 12 may also access the server 14 over the network 16.
  • the server 14 may be used by the user device 12, or any other computer system, to access data stored in records of the server database 18 in response to a query.
  • the query may be dynamically determined and executed by an operating system, an application, and/or one or more modules resident on the system querying the server 14.
  • the server 14 may manage storage and synchronization of data objects (task objects, device objects, device context objects, activity objects, resource objects, user objects, virtual desktop objects/images, etc.) that define the state of each user device 12 at various times across devices and users, and to provide both on-line and interface-based reporting capabilities.
  • the server 14 may be configured to send task data to the client applications 13, and collect, store and, process task data received from the client applications 13.
  • Tasks and task data updates originating from one client application 13 or an external task source may be sent to other client applications 13.
  • task execution data e.g., resource usage and working time
  • Internal synchronization logic of the server 14 may be configured to ensure that only relevant data is sent to each individual client application 13 and that all relevant data is stored in the server database 18.
  • the server 14 may be implemented, for example, as a web application in a Java EE server, and may be deployed as a local dedicated server that serves a defined group of users, or as cloud service shared by many clients.
  • An on-line reporting portal may be provided by the server 14 to allow users to configure their own textual (table- based) or graphical reports, and to view their own data. Users with sufficient permissions (e.g., assigned permission by a system administrator) may be able to view data of other users.
  • a typical scenario is a manager viewing reports of his/her team's performance.
  • the server database 18 may be used to collect and organize data used by the various systems and modules described herein.
  • the server database 18 may include data and supporting data structures that store and organize the data.
  • the server database 18 may be arranged with any database organization and/or structure including, but not limited to, a relational database, a hierarchical database, a network database, an object-oriented database, or combinations thereof.
  • the server database 18 may provide persistent storage for data objects and serve reporting queries.
  • the server database 18 may include a task record or other data object for each task defined in the system.
  • Each task record may include a plurality of task data fields.
  • Exemplary data fields may include a task identifier field, a task title/name field, a task description field, a deadline field, a start date (or start time) field, an end date (or end time) field, a closed date field, and a status field. Extra information may also be added as additional fields to customize the server database 18.
  • the system administrator may configure the server database 18 to use Additional Task Fields (ATFs) through a product portal.
  • ATFs may also be mapped to specific fields in external systems.
  • Server specific tables in the server database 18 may include: a user role class that connects the user to a given role; an administrator rights class that represents a privilege or right which a user has in a specific role; a company class that encapsulates the information of a company; and an ATF role class that connects an ATF to a role.
  • One difference between the client and the server data model may be an activity table, which may only exist on the client side. Activities may be the smallest unit of the working time registration process of the client. For accuracy, time may be measured on activity level by the desktop manager. However, this level of detail may not be needed to provide working time reports from the server, so clients may only synchronize time data aggregated to task sessions. By avoiding sending activity level data to the server 14, the desktop manager may reduce network traffic and storage requirements, and may improve privacy as activities could reveal the computer usage habits of the user.
  • the server 14 may access the server database 18 through direct JDBC Application Programming Interface (API) calls, a simple low level object mapping technology like Spring JDBC Template, or using any other suitable method.
  • the server 14 may use a distributed cache and a ring-buffer process to implement a write-behind pattern, which may change the timing of the write to the system-of-record (database).
  • the reads may be reduced by caching, the writes, which are typically much more expensive operations, may be reduced because multiple changes to the same object within the write-behind interval are "coalesced" and only written to the server database 18 once.
  • writes to multiple cache entries may be combined into a single database transaction.
  • the system may be insulated from temporary database outages. If a write to the database fails, the objects may be re-queued for write and the application can continue operation without the database being up.
  • All core objects may be identified by globally unique identifiers. This may enable the client application 13 to operate properly in off-line mode by enabling the client applications 13 to create new objects (e.g. tasks or resources) by themselves without having to request identifiers from the server 14. To this end, the desktop manager may use
  • UUIDs Universally Unique Identifiers
  • the UUIDs may enable distributed systems to uniquely identify information without significant central coordination.
  • each object sent to the server 14 through the synchronization process by the client application 13 may already have a unique identifier generated by the client application 13. This identifier may remain unchanged throughout the lifetime of the object.
  • core objects may not be physically deleted from the server database 18. Rather, the desktop manager may use a concept called logical deletion to mark records as deleted.
  • the client application 13 may transmit a message to the server 14 including data defining the event, e.g., data identifying the user action that triggered the event, a resource associated with the event, and a task associated with the event.
  • the server 14 may store the event as an event record in the server database 18.
  • Each event record may be indexed to the resource associated with the user, the user device, the type of event, and/or the task associated with the event, and may include a time stamp.
  • the server database 18 may maintain an index that associates each resource and/or event with one or more tasks.
  • the server database 18 may also maintain statistics about each task, such as times when a user started working on the task and stopped working on the task. This may enable the server 14 to determine an amount of time each user has worked on a particular task.
  • the client application 13 may cause the user interface to display a constantly visible object, such as status bar positioned at the top of the screen or a small colored bar positioned to the top of the active application window that allows the user to access one or more desktop manager windows.
  • the status object may be configured to provide information such as the identity and the status of the current task.
  • the client application 13 may cause the user interface to display an icon on the host environment' s menu bar/system tray. This may allow the desktop manager to work invisibly in the background and only interact with the user when certain events make it necessary. These interactions may include, for example, notifications from the desktop manager that the user can react to.
  • the desktop manager may determine if a newly opened resource belongs to the current task context or another task context, e.g., if the user has switched tasks. The user may be notified about the result of this guess in a notification. The notifications may also contain supplementary information about the task, such as a task identifier and/or an amount of time the user has spent working on the task.
  • the user device 12, server 14, network 16, and server database 18 of operating environment 10 may be implemented on one or more computer devices or systems, such as exemplary computer 30.
  • the computer 30 may include a processor 32, a memory 34, a mass storage memory device 36, an input/output (I O) interface 38, and a Human Machine Interface (HMI) 40.
  • the computer 30 may also be operatively coupled to one or more external resources 42 via the network 16 or I/O interface 38.
  • External resources may include, but are not limited to, servers, databases, mass storage devices, peripheral devices, cloud-based network services, third-party servers and/or applications, or any other suitable computer resource that may be used by the computer 30.
  • the processor 32 may include one or more devices selected from microprocessors, micro-controllers, digital signal processors, microcomputers, central processing units, field programmable gate arrays, programmable logic devices, state machines, logic circuits, analog circuits, digital circuits, or any other devices that manipulate signals (analog or digital) based on operational instructions that are stored in memory 34.
  • Memory 34 may include a single memory device or a plurality of memory devices including, but not limited to, read-only memory (ROM), random access memory (RAM), volatile memory, non- volatile memory, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, cache memory, or any other device capable of storing information.
  • the mass storage memory device 36 may include data storage devices such as a hard drive, optical drive, tape drive, volatile or non- volatile solid state device, or any other device capable of storing information.
  • the processor 32 may operate under the control of an operating system 44 that resides in memory 34.
  • the operating system 44 may manage computer resources so that computer program code embodied as one or more computer software applications, such as an application 46 residing in memory 34, may have instructions executed by the processor 32.
  • the processor 32 may also execute the application 46 directly, in which case the operating system 44 may be omitted.
  • the one or more computer software applications may include a running instance of an application comprising a server, which may accept requests from, and provide responses to, one or more corresponding client applications, such as client application 13.
  • One or more data structures 48 may also reside in memory 34, and may be used by the processor 32, operating system 44, or application 46 to store or manipulate data.
  • the I/O interface 38 may provide a machine interface that operatively couples the processor 32 to other devices and systems, such as the network 16 or external resource 42.
  • the application 46 may thereby work cooperatively with the network 16 or external resource 42 by communicating via the I/O interface 38 to provide the various features, functions, applications, processes, or modules comprising embodiments of the invention.
  • the application 46 may also have program code that is executed by one or more external resources 42, or otherwise rely on functions or signals provided by other system or network components external to the computer 30.
  • embodiments of the invention may include applications that are located externally to the computer 30, distributed among multiple computers or other external resources 42, or provided by computing resources (hardware and software) that are provided as a service over the network 16, such as a cloud computing service.
  • the HMI 40 may be operatively coupled to the processor 32 of computer 30 to enable a user to interact directly with the computer 30.
  • the HMI 40 may include video or alphanumeric displays, a touch screen, a speaker, and any other suitable audio and visual indicators capable of providing data to the user.
  • the HMI 40 may also include input devices and controls such as an alphanumeric keyboard, a pointing device, keypads, pushbuttons, control knobs, microphones, etc., capable of accepting commands or input from the user and transmitting the entered input to the processor 32.
  • a database 50 may reside on the mass storage memory device 36, and may be used to collect and organize data used by the various systems and modules described herein.
  • the database 50 may include data and supporting data structures that store and organize the data.
  • the database 50 may be arranged with any database organization or structure including, but not limited to, a relational database, a hierarchical database, a network database, an object-oriented database, or combinations thereof.
  • a server in the form of a computer software application executing as instructions on the processor 32 may be used to access the information or data stored in records of the database 50 in response to a query, where a query may be dynamically determined and executed by the operating system 44, other applications 46, or one or more modules.
  • FIG. 3 illustrates exemplary logic layers of the client application 13 in accordance with an embodiment of the invention.
  • the logic layers may include a Graphical User Interface (GUI) 300, a client core 302, and a low-level API 304.
  • the client core 302 may include a Platform Independent Service Provider (PISP) module 306 that implements functions of the client core 302, a local database 308, and internal modules that implement specific services, such as a scheduler module 310, update module 312, configuration module 314, and synchronization module 316.
  • PISP Platform Independent Service Provider
  • the GUI 300 may be built on an embedded browser. This may facilitate building the user interface of the desktop manager client using web-based technologies.
  • the GUI may be unified for similar platforms and devices, which may allow for one GUI implementation for all desktop platforms and one GUI for all mobile platforms. However, in some operating environments, there may differences between the services of target platforms, so there may be different GUI implementations for specific platforms.
  • the low-level API 304 may be responsible for forwarding low level events (like switching to another window or opening a document) to the higher layers and managing low level objects.
  • the low-level API 304 may provide access to window management, file system, process management, and notification features of the host platform.
  • One function of the low-level API 304 may be to control the visibility of windows that belong to a task context in accordance with the user's preferences.
  • Another function of the low-level API 304 may be registering events that are generated by the client application 13 when the user accesses resources (e.g. applications, files).
  • the low-level API 304 may be
  • the client core 302 may start the low-level API 304 process and connect to it. If the low-level API 304 fails for any reason, the client core 302 may re-start and re-connect to the low-level API 304. There may be a two-way connection between the client core 302 and the low-level API 304. Both the low level API 304 and the client core 302 may initiate communication, may act as the server for some functions and client for other functions, and may use QLocalServer class, which provides a local socket based server. This class may make it possible to accept incoming local socket connections.
  • the processes may connect to each other's local service using the QLocalSocket class, which may provide a local socket implementation.
  • the set of resource types that the system can handle may be also extend to certain application specific resources like source code files opened in integrated development environments, emails in exotic email clients, or special web-based resources.
  • the client application 13 may install integration plug-in modules and use IPC processes to communicate with the plug-in.
  • the PISP module 306 may provide services to manage the local database 308, and inter-process communications (IPC) with the low-level API 304 as well as an API used by the GUI 300.
  • the PISP module 306 may act as a communications hub between the GUI 300, the local database 308, the user device 12 and the server 14.
  • the PISP module 306 may be based on the Qt framework and may be implemented in Qt C++.
  • the PISP module 306 may use several Qt modules like QtCore, QtNetwork, QtWebkit Widgets and QtSql. For embodiments in which the whole GUI layer is implemented inside an embedded browser object, the PISP module 306 may logically provide the container in which the GUI 300 runs.
  • the PISP module 306 may provide a number of singleton objects and generic classes that are used in the operation of the client application 13. These classes may be implemented as QObjects, and may also be exposed as Javascript objects in the embedded browser invokable from the GUI 300.
  • the core objects may embody an internal business logic of the client application 13. Each entity in the object model may represents some fundamental element of the client terminology (task, resource, activity, etc.).
  • the core objects may logically belong to the client core 302, one or more of them may be implemented as JavaScript objects within the context of an embedded browser. Some of the core objects (e.g., Activity, Resource, DeviceContext) may also be actively used by lower layers. These core objects may be implemented as QObjects and made available to the Javascript layer.
  • the core object classes and their high level functional description may include: a device object that represents one of the user's physical devices that has the desktop manager client installed; a user object that encapsulates basic information about the user; an external user class that connects the user to another user in an external system, such as Wunderlist or JIRA; a device context class that connects a resource to a task context on a device; a task object that encapsulates the basic data of a task; and external system type that includes a list of external systems that the desktop manager system can interface with., e.g., a list of installed interface modules; an external system object that represents a live (configured and working) interface instance to an instance of one of the available external system types; a UI preferences class that encapsulates a key-value pair in which the GUI 300 can store values; a system notification class that encapsulates a notification which is sent by the server to the desktop manager client to notify the user of some event (for example: that a new client update is available); a role
  • the local database 308 may be used to persist the state of core objects used by the system, and may use SQLite as its database engine, for example.
  • the scheduler module 310 may be responsible for triggering timed events in the desktop manager.
  • the client application 13 may use the scheduler module 310 to execute timed functions. Exemplary uses of the scheduler module 310 may include the
  • the synchronization module 316 may execute the synchronization of the core objects between the client application 13 and the server 14.
  • a synchronization exchange may start from the server 14 and may be triggered by the scheduler module 310.
  • the synchronization module 316 may create a synchronization packet containing all objects that have changed (i.e., "become dirty") since the last successful synchronization.
  • the synchronization packet may be sent to the server 14 over any suitable connection, such as an HTTPS connection using the REST API.
  • the server 14 may respond with another synchronization packet that contains all objects that have changed on the server 14 and therefore need updating on the client application 13. Server-side changes may originate from other devices, users, and/or external systems.
  • the configuration module 314 may enable the client application 13 to remember settings (e.g., window sizes and positions, options, etc.) across sessions. This information may be stored, for example, in the system registry of the operating system, in XML preferences files, and/or in INI text files. To hide this platform dependence from the implementation of the client application 13, a module may be used that provides persistent platform-independent application settings on platform- specific technologies, that enables developers to save and restore application settings in a portable manner, and that supports custom storage formats.
  • the update module 312 may be responsible for keeping the client application 13 up-to-date with the latest available versions.
  • the update process may be automatic.
  • the server 14 may notify each running instance of a client application 13 when a new version is available. If a notification arrives, the update module 312 may download the update package from the server 14 in the background, then notify the user about the available update. The user may then choose to run the update immediately or at a later time.
  • Embodiments of the invention may include one or more computer-implemented methods for assigning one or more of: an application, application window, application tab, file stored on machine-readable media, web page, contact information, electronic communication (such as but not limited to: emails, phone calls, instant messages, and/or SMS messages), referred to herein as "resources", to one or more user or machine defined tasks, including reading events and runtime data of the computer operating system and windowing system directly or indirectly related to user initiated actions performed on an electronic device.
  • resources such as but not limited to: emails, phone calls, instant messages, and/or SMS messages
  • the computer/electronic device's application user interface may become active in the sense that the main information exchange happens between the user interface and the user.
  • this may be the active application's screen/canvas/window.
  • this can be a notification window which does not belong directly to the application but can be tied to the application.
  • Manual resource to task assignment may include methods of resource assignment as described above, where the assignment or reassignment of a resource that the user is currently using or working with is done by: the user manually selecting a task from a full or reduced set of previously defined tasks, the user manually selecting a task from an ordered list of previously defined tasks where the ordering of the list is based on the confidence level of the resource belonging to each of the tasks on the list, and/or the user manually creating a new ad-hoc task or impromptu task.
  • the task list may contain all tasks the user created or received. Task switching may result from an explicit action by the user (e.g., selecting a task from the task list) or may be implicit. An implicit task switch may occur when the user starts working on something new without selecting another task from the task list.
  • Automatic assignment refers to a method of assigning a resource for automatic assignment and reassignment of resources the user had been using or working with on previously defined tasks. Such an assignment may define a relation between resources and tasks where such relations define task contexts.
  • Automatic assignment decisions may be made by the program based on earlier manual decisions by the user, such as: automatic assignment of already known (previously used and assigned) resources by reopening the resource in the context of the previously assigned task, automatic assignment of an unknown (first used) resource by predicting the task assignment based on similarity with already known resources, and/or automatic assignment of sundry applications (e.g. a file manager) that follows one or more rules such as dynamically assigning applications to the last active task.
  • sundry applications e.g. a file manager
  • the default task list may only contain tasks that are still open and can be worked on any time.
  • the desktop manager may allow the user to apply specific filters to list tasks based on specific criteria, and may include several pre-defined filters for listing actionable tasks, overdue tasks, closed tasks, etc. These filters may facilitate navigation in the task list.
  • the task list may also provide a search process which can be used for searching based on one or more keywords or fragments.
  • the desktop manager may search in all available data fields of the tasks and their related objects like the task resources, which may facilitate finding an older task associated with an unknown file just by typing in a few letters from the file name.
  • FIG. 4 depicts the server 14 in accordance with an embodiment of the invention that includes a core services module 400, a reporting module 402 that generates an online report 404, an external system interface module 406 that communicates with an external system 408 and/or generates an external report 410, a web portal application 412 that communicates with a web client 414, and an administration console application 416 that communicates with an administration portal client 418.
  • the core services module 400 may comprise a central component of the server 14, and may provide services to other components through specialized APIs.
  • the core services module 400 may manage the server database 18 as well as a server side caching process, and may be responsible for maintaining the integrity of the database and cache. In an embodiment of the invention, only the core services module 400 can write directly into the server database 18.
  • the core services module 400 may be implemented, for example, as a Java web application package that can be deployed to any supported servlet container.
  • the client applications 13 may access the core services module 400, for example, through simple JAX- RS-based Rest APIs that communicate with JSON messages using HTTPS connections.
  • the server 14 may be under constant load from the client applications 13, so the server 14 may be optimized for high performance to serve all requests with acceptable response times.
  • the core services module 400 may be configured so that multiple instances can be deployed to run parallel in a distributed environment. This architecture may also protect against data loss and ensure high availability. The architecture may also follow the write- behind cache design pattern to limit the number of database write transactions by executing database writes in batches rather than as individual updates. In addition, a distributed memory cache may be used to speed up read transactions.
  • An authentication API may be used by all clients and server side modules to authenticate users. For example, user authentication may use an OAuth (2.0) protocol.
  • the core services module 400 may be configured to collect all changes to tasks, resources, and other core objects in the client applications 13 and other system components.
  • the core services module 400 may be further configured to send the changes collected from one user device 12 to all other user devices 12 that are affected by the change.
  • Client applications 13 may send their changes (objects modified by the user or resources and working time registered by the client application 13) to the server 14 at regular intervals.
  • the server 14 may update its copy of the received objects and respond with a list of changes that the client application 13 needs to know about.
  • Client applications 13 may use the
  • core objects may be constantly changing.
  • the client application 13 may collect all changed object and regularly send them to the server 14. The client my do this by marking all changed objects with a "dirty" flag.
  • the dirty flags may be cleared and the collection of changes may start again. If synchronization works at regular intervals, the list of changed objects to be synchronized may be relatively small. If synchronization is not possible for some time (e.g. due to the absence of a network connection between the client application 13 and the server 14), the number of dirty objects awaiting synchronization may become relatively large.
  • the server 14 may assign a unique identifier (sync ID) to each synchronization transaction and store all changed objects with this identifier.
  • the sync ID may be kept sequential to facilitate tracking the order of the changes.
  • the sync ID may also be sent back to the client application 13 in the synchronization response.
  • the client application 13 may send the sync ID it received in the previous synchronization back to the server 14 so that the server 14 knows which changes are new to the client application 13.
  • FIGS. 5A-5G depict an exemplary client data object model 420 that may be used by the desktop manager.
  • the data object model 420 may include an activity object 422, a device context object 424, a device object 426, a task object 428, a resource object 430, a session object 432, a user object 434, a User Interface (UI) preferences object 436, a system notification object 438, a role object 440, an external task object 442, an ATF value object 444, an ATF object 446, an ATF tree node object 448, an external user object 450, an external system object 452, and an external system type object 454.
  • UI User Interface
  • the activity object 422 may include data fields that define the identity of the activity, the identity of the device context, an identity of the task, a start date (or start time) for the task, an end date (or end time) for the task, and the type of activity.
  • the device context data field may link the activity object to the device context object 424.
  • the device context object 424 may include data fields that define the identity of the device context, the identity of the task, the identity of the device, an identity of a resource, an identity of an application, and a window title.
  • the device, task, resource, and application identity fields may link the device context object 424 to the device object 426, task object 428, resource object 430, and resource object 430, respectively.
  • the device object 426 may include data fields that define the device identity, a display name, a device internal identity, a device type, a system type, whether the device has location awareness, a device internal string, a user identity, a date when the device was last synced to the server database 18, and whether the device is active or inactive.
  • the device object 426 may be linked to the user object 434 by the user identity string, and to the device context object 424, session object 432, and UI preferences object 436 by respective data fields in those objects.
  • the task object 428 may include data fields that define the identity of the task, the user identity, a title of the task, a description of the task, the deadline of the task, the start date of the task, the closed date of the task, the state of the task, and a role identity.
  • the task object 428 may be linked to the user object 434 by the user identity string and the role object 440 by the role ID string, and to the device context object 424, session object 432, user object 434, UI preferences object 436, external task object 442, and ATF value object 444 by respective data fields in those objects.
  • the resource object 430 may include data fields that define the identity of the resource object, a URL of a resource, a type of the resource, a title of the resource, and a nice url.
  • the resource object 430 may be linked to the device context object 424 by the application identity and resource identity data fields in that object.
  • the session object 432 may include data fields that define a session identity, an identity of the user device being used for the session, a task identity, an end date for the task, and a start date for the task. This data may be entered by the user when the task is first initiated, or retrieved from the server database 18 when the user wants to restore the desktop (e.g., return to working on the task) on the user device 12.
  • the device ID string of session object 432 may link the session object 432 to the device object 426, and the task ID string may link the session object 432 to the task object 428.
  • the user object 434 may include data fields that define the identity of the user, the name of the user, an email address of the user, a password of the user, an encoded image of the user, and a default task ID associated with the user.
  • the user object 434 may be linked to the task object 428 by the default task string and the role object 440 by the role ID string, and to the device context object 424, session object 432, user object 434, UI preferences object 436, external task object 442, and ATF value object 444 by respective data fields in those objects.
  • the UI preferences object 436 may include data fields that define the identity of the user interface, the user ID, the task ID, the device ID, a key, and a value.
  • the UI preference object 436 may be linked to the device object by the device ID string, the task object 428 by the task ID string, and the user object by the user ID string.
  • the system notification object 438 may include data fields that define the identity of the system notification object,438, the user ID, a component ID, a notification code, and a notification text.
  • the system notification object 438 may be linked to the user object 434 by the user ID string.
  • the role object 440 may include data fields that define the identity of the role object 440, a boolen operator indicating whether the task has been deleted, and a name.
  • the role object 440 may be linked to the task object 430 by the role id string in that object.
  • the external task object 442 may include data fields that define the identify of the external task object, the identity of the task, the identity of the external system, and a URL of the external system.
  • the external task object 442 may be linked to the task object 428 by the task id string, and to the external system type object 454 by the external system ID string.
  • the ATF value object 444 may include data fields that define the identity of the ATF value object, whether the object has been deleted, the identity of the AFT, the task ID, a tree node ID, and a text of the object.
  • the ATF value object may be linked to the task object 428 by the task identity string, the ATF object 446 by the AFT identity string, and the ATF tree node object 448 by the tree node identity string.
  • the ATF object 446 may include data fields that define the identity of the ATF object 446, an ATF type, a name, a root node identity, and whether the object has been deleted.
  • the ATF object may be linked to the ATF tree node 448 object by the root node identity string, and may be linked to the ATF value object 444 a respective data field in that object.
  • the ATF tree node object 448 may include data fields that define the identity of the ATF tree node object 448, text, a parent node identity, and whether the object has been deleted.
  • the ATF tree node object 448 may be linked to the ATF value object 444 and ATF object by respective data fields in those objects.
  • the external user object 450 may include data fields that define the identity of the external user object 450, an external user identity, an external user password, the external URL, the (internal) user identity, and the external system identity.
  • the external user object 450 may be linked to the user object 434 by the user identity string, and to the external system object 452 by the external system identity string.
  • the external system object 452 may include data fields that define the identity of the external system object 452, the external system type identity, and the external URL.
  • the external system object 452 may be linked to the external system type object 454 object by the external system type string, and may be linked to the external user object by a respective data field in that object.
  • the external system type object 454 may include data fields that define the identity of the external system type object 454, and a display name.
  • the external system type object may be linked to the external task object 442 and external system object 452 by respective data fields in those objects.
  • FIG. 6 depicts client-server synchronization, and includes a user 500, a plurality of user devices 12A, 12B each synchronized by a periodic timer 502, 504, and the server 14 with a synchronization module 316, a cache module 508, and the server database 18.
  • the user 500 may create a new task 510 in the user device 12A, thereby causing a change in the local database 308 thereof.
  • the user device 12A may begin a synchronization process 514.
  • the synchronization process 514 may transmit a synchronization packet 516 to the server 14.
  • the synchronization module 316 may begin a synchronization process 518.
  • the synchronization process 518 may transmit an update cache request 520 to the cache module 508 indicating that a new task has been created on the user device 12A.
  • the cache module 508 may begin an update process 522.
  • the update process 522 may transmit an update database request 524 to the server database 18, which may trigger the server database 18 to begin an update process 526.
  • the synchronization module 316 may also transmit an update client request 528 to the cache module 508 requesting changes that have occurred in the relevant database records since the last update of the local database 308 of user device 12A.
  • the cache module 508 may start an update process 530 that identifies records in the cache that have been updated since the last update of the local database 308 of user device 12A.
  • the cache module 508 may transmit an update client response 532 including synchronization data (e.g., changed records) for updating the local database 308 of user device 12A. This data may be transmitted by the synchronization process 518 to the user device 12A in a synchronization packet 534.
  • the client application 13 may update the local database, thereby completing the synchronization process 514.
  • user device 12B may begin a synchronization process 538.
  • the synchronization process 538 may transmit a synchronization packet 540 to the server 14.
  • the synchronization module 316 may begin a synchronization process 542.
  • the synchronization process 542 may transmit an update cache request 544 to the cache module 508 defining any changes that have occurred in the local database 308 of user device 12B since the last synchronization.
  • the cache module 508 may begin an update process 546.
  • the update process 546 may transmit an update database request 548 to the server database 18, which may trigger the server database 18 to begin an update process 550.
  • the synchronization module 316 may also transmit an update client request 552 to the cache module 508 requesting changes that have occurred in the relevant database records since the last update of the local database 308 of user device 12B.
  • the cache module 508 may start an update process 554 that identifies records in the cache that have been updated since the last update of the local database 308 of user device 12B.
  • the cache module 508 may transmit an update client response 556 including synchronization data (e.g., changed records) for updating the local database 308 of user device 12B. This data may be transmitted by the synchronization process 538 to the user device 12B in a synchronization packet 558.
  • a client installation process 603 may send a synchronization packet 604 to the server 14 either without a sync ID or with a default sync ID.
  • the synchronization module 316 may begin a synchronization process 606.
  • the synchronization process 606 may determine, based on the lack of the sync ID (or the presence of the default sync ID), that all objects related to the user 600 need to be transmitted to the client application 13 of user device 12C, and not just the latest changes.
  • the synchronization process 606 may transmit an initial synchronization request 608 to the server database 18.
  • the server database 18 may begin an initial synchronization process 610.
  • the server 14 may prepare the changes that need to be provided to the client application 13 in a memory cache.
  • the process 610 may identify all the records that need to be transmitted to the client device, and transmit an update database request 612 to the synchronization process 606 running on synchronization module 316.
  • synchronization process 606 may transmit an update cache request 614 to the cache module 508 to keep the cache in sync with the server database 18, and a reply synchronization packet 616 to the user device 12C.
  • the initialization process 603 may use data carried by the synchronization packet 616 to initialize the local database 308 of user device 12C.
  • the server 14 may only use the server database 18 to prepare a synchronization packet for transmission to the client application 13 when the necessary data is not available in the cache 508. This may happen, for example, when a client application 13 is re-installed or the server 14 is restarted. In order to economize on memory that is used by the cache 508, the server 14 may remove a prepared synchronization packet from the cache 508 if the respective client application 13 is off-line for a period of time exceeding a predetermined threshold. If the prepared synchronization packet has been purged when the client application 13 comes on- line again, the server 14 may access the server database 18 and prepare a new synchronization packet.
  • Certain core objects may not be necessary during normal operation of the client applications 13. To reduce the amounts of data transmitted between client applications 13 and the server 14, these objects may only be synchronized on demand. Examples of core objects that may only be synchronized on demand may include session objects that hold a measured working time for each task and device. This information may only be needed by another client application 13 when the user explicitly wants to display working time data from all devices 12. In this case, the client application 13 may transmit a request to the server 14, and the server 14 may respond by transmitting the necessary session data.
  • client applications 13 may need to register with the server 14. Once registered and assigned to a user, the client application 13 can participate in the normal synchronization process provided by the server 14. Client applications 13 may use the same API to list all devices that belong to a user. This may facilitate managing extended contexts/virtual desktops spanning multiple devices. The list of a user's devices may also be used by the server 14 to send notifications from one user device 12 to another. When a new version of the client application 13 is available from the server 14, client applications 13 may use an update feature of a device administration API to download the new version and perform an automatic update.
  • the administration API may be used by the administration console application 416 and a web portal application 412 to access basic setting in the desktop manager.
  • the administration API may provide Create, Read, Update, and Delete (CRUD) functions to system objects, including, but not limited to, User, Company, ExternalUser, Role, User2Role, Role2ATF, ATF, and ATFTreeNode objects.
  • CRUD Create, Read, Update, and Delete
  • An Infrastructure API may be used by distributed server components (like instances of an integration mediator) to register their status with the core services. This may allow the core services to know what components are active so that the sever 14 can send push messages or signals.
  • FIG. 8 illustrates the internal architecture of the web portal application 412 and the administration console application. These applications may collectively include a user interface 700 and a backend 702.
  • the user interface 700 may include a router module 704, authentication module 706, a States-Model-View-Controller (MVC) module 708, a components module 710, cache module 712, third party libraries module 714, and REST backend client module 716.
  • the backend 702 may include static content (e.g., html, ess, images, etc.) 718, a REST backend server 720, a business layer 722, and a core service client 724 that communicates with an administrator API 726 in the core services module 400.
  • the web portal application 412 and administration console application 416 may comprise web applications that can be deployed to any servlet container.
  • the applications may consist of, for example, a JAX-RS-based backend service and a single-page client user interface built with HTML5, CSS3, Javascript technologies that run in the user's browser.
  • both the web portal application 412 and the administration console application 416 are prohibited from accessing the server database 18 directly. Rather, they use the administration API 726 provided by the core services module 400 to access data in the server database 18.
  • the following principles may be applied during the implementation of the web applications.
  • AngularJS HTML template pages may be placed in a Javascript templates cache, which may be preloaded at application startup.
  • CDD and Javascript resources may be compressed and minified.
  • FIG. 9 depicts a reporting web application architecture that may be implemented as a separate Java web application that can either be deployed into the server 14 or run in a separate environment.
  • the reporting application may act as a server for both on-line and external report requests.
  • the reporting application may be implemented similarly to the desktop manager server application.
  • the reporting web application may also include a JAX- RS-based backend service and a single-page client user interface that runs in the user's browser.
  • One difference may be that instead connecting to the core services module 400, the reporting web application may have direct read-only access to the server database 18 and may access the collected task and task execution data through pre-defined database views.
  • the desktop manager may be configured to accept tasks from external systems and/or device through a dedicated API with access to the server database 18 and that provides features, such as importing tasks from external task sources.
  • This API will be used internally by other system components, as well as to integrate third party applications.
  • the API may also enable integration of the desktop manager into third party systems.
  • the integration process may be split into application specific components and common functionalities.
  • the application specific components may provide for data exchange and authentication through an interface provided by the third-party application.
  • the common functionalities may transform the data exchange and authentication into desktop manager data exchange and authentication.
  • the above functions may be provided by a "task mediator" application that handles the desktop manager's internal and external users/tasks. This may be carried out by mapping the corresponding external user/task IDs with local IDs.
  • the task mediator 901 (FIG. 10) may create an internal task with a local ID and a database record in which the local IDs are associated with their respective external IDs.
  • the same process may be applied to users. That is, external users may be associated with local task manager users in the server database 18.
  • the desktop manager may also mark the external tasks and users with information identifying the external system from which they are imported to allow the task mediator 901 to know which external system it needs to communicate with for a respective task or user.
  • the server database 18 may include the following tables:
  • External System Table the external system from which users/tasks are imported
  • External System Class Table contains information about the external system.
  • External Task Table the representation of a task in an external system. The mapping with desktop manager tasks may be realized via this table.
  • External User Table The representation of a user in the external system. The mapping with internal users may be realized via this table.
  • User Table the representation of desktop manager users.
  • Task Table the representation of desktop manager tasks.
  • the task mediator 901 may be implemented as a standalone server component that can be configured to run on the server 14 or another dedicated server.
  • the task mediator 901 may be realized by a Java servlet component running on a server.
  • Task mediator 901 may have a plurality of interfaces (e.g., three interfaces) that connect with the server 14. These interfaces may include a synchronization interface, an infrastructure API, and an
  • the synchronization interface may send a synchronization packet via the synchronization process and API containing new or updated task data to the synchronization module. This may enable the task mediator 901 to perform task related database updates the same synchronized way as the internal clients do. In case of errors in the task mediator 901 (e.g., authentication or connection related issues), the task mediator 901 may send a synchronization packet containing the error information to synchronization module. In response to receiving the synchronization packet, the synchronization module 316 may update a system notification table in the server database 18 and notify the affected clients and/or other components.
  • An Infrastructure API may be defined between the task mediator 901 and the server 14 through which administrative and operational messages can be sent. For example, if the user triggers a task update from an external system, the server 14 may send a message to the task mediator 901 through this API to command the external system to perform the necessary update.
  • the task mediator 901 may access the server database 18 through the
  • the task mediator 901 may be prohibited from performing direct database queries (SQL). This may allow server database access to be transparent and less sensitive to changes in the database scheme.
  • the data needed from the server database 18 by the task mediator 901 may include configuration data, user information, and task information for accessing external systems.
  • the task mediator 901 may also maintain a local data cache in order to reduce the load on the server database 18. If up-to-date information is available in the cache, the server database 18 may not need to be queried for that information.
  • the task mediator 901 may perform the necessary data exchange between desktop manager and the other system.
  • Methods for obtaining tasks from external systems may include polling and event-based queries. With polling, the desktop manager may periodically query the external system for changes. With event based queries, the external system may send an
  • the event based method may be the default mode of operation due to performance reasons, such as less resource and code needed from the desktop manager side.
  • some third-party system may not support event-based notification.
  • the desktop manager may use the polling approach.
  • a polling process may query the external system periodically and creates notifications internally that are then handled by the same process that handles other external notifications.
  • the data of the tasks coming from an external system might be structured differently compared to the tasks used in the desktop manager.
  • the received, different data models may be transformed to the one applied by the desktop manager.
  • the following parameters may be adapted from the external systems: owner of the task/user who created the task; status of the task status: open/closed; deadline of the task; notes/comments/description; notification; attachment; and Additional Task Fields (ATFs).
  • ATFs Additional Task Fields
  • Due to the diversity of task states used by other systems, the desktop manager may only handle a limited number of states of external tasks, (e.g., two states - open and closed). If tasks are retrieved from external systems, the state of these tasks may not be modified in the external system by the desktop manager. Rather, modifications may be limited to time measurement related functions. In this case, a URL pointing to the task in the remote system may be provided.
  • users may be authenticated before accessing external systems. Authentication may be performed by the authentication layer that provides a common interface with the server 14 through which application specific authentication components may be connected.
  • Authentication may be performed by the authentication layer that provides a common interface with the server 14 through which application specific authentication components may be connected.
  • an access token may be stored in the server database 18.
  • the task mediator 901 may query the server database 18 for the access token.
  • the task mediator 901 may use the receive access token to exchange data with the external system. Acquiring the access token may be application specific.
  • the user 900 To acquire the access token, the user 900 must provide their credentials in order to be authenticated and gain access to resources in the external system.
  • An integration configuration page may be displayed by the client application 13 for the users where they can provide their credentials for a third-party application 902 running on the external system.
  • the server 14 may use an official log-in dialog for acquiring the access token from the third-party application 902, which may allow the user 900 to connect directly to the third-party server.
  • the server 14 may store the user's credentials, and the client application 13, server 14, and task mediator 901 may operate cooperatively to manage the authentication process and store the acquired access token for later data exchange.
  • the client application 904 may issues a request 904 (e.g., an HTTP request) to the server 14.
  • the server 14 may send a response 906 (e.g., an HTTP response) to the client application containing the result of the request.
  • the results may include an external system ID and client ID.
  • the client application 13 may transmit a log in request 910 to the third-part application 902.
  • the client application 13 In order for the client application 13 to access the third-party application 902, it may have to obtain permission from the owner of the third-party application 902. This permission may be expressed in the form of an access token and matching shared-secret.
  • the purpose of the access token may be to make it unnecessary for the resource owner to share their credentials with the client application 13.
  • access tokens can be issued with a restricted scope and a limited lifetime that may be revoked independently of the owner credentials.
  • the third-party application 902 may transmit an authentication request 914 to the task mediator 901.
  • the task mediator 901 may transmit a response 916 including a authentication code and client ID.
  • the third-party application 902 may transmit the access token 918 to the task mediator 901.
  • the task mediator 901 may transmit a response 920 to the server 14 that includes the access token and an external user ID.
  • the server 14 may transmit a response to the client application 13 authenticating the user 900.
  • client ID a unique client identifier
  • users may be able to authorize access to their account information from the third-party application by getting and using the access token.
  • This access token may be stored in the server and or local database in the External User table.
  • FIG. 11 depicts an exemplary user- initiated task import from a third-party application.
  • Authenticated and authorized users can exchange data with external systems.
  • the data exchange layer's duty may be to provide a common data interface between the server and the external system.
  • This process may be interconnected with the synchronization module 316 in order to insert data into the server database 18 by sending a synchronization packet that contains the data for the newly imported or updated task.
  • Each third-party system may have its own application-specific data exchange process implementation inside the data exchange layer.
  • the server 14 may request the data exchange layer through the common interface.
  • the data exchange layer may inspect the request, and retrieve the necessary information (e.g., the user's access token, the contact information of the external system, etc.) from the server database 18.
  • the data exchange layer may then pass the information to a corresponding third-party application process that performs the data exchange with the external system, converts the response into a unified format used internally by the server 14, and sends the result back the through the data exchange layer to the synchronization module 316 in a synchronization packet.
  • the synchronization module 316 may update the server database 18 and notify the client application 13.
  • Task imports from an external system may be triggered in multiple ways.
  • One way is by a user-initiated trigger in which the user connects to an external system for the first time or manually asks to make an update from the external system.
  • the request may reach the task mediator 901 via the server 14.
  • Another way the task import may be triggered is by a third-party initiated trigger in which the external system notifies the mediator (e.g., via a callback interface) that a task has been changed.
  • Yet another way the task import may be triggered is by a timer-initiated trigger in which the task mediator 901 uses a timer that can periodically trigger the task update the from external systems.
  • the task mediator 901 may include a data exchange module 1000 and an application specific data exchange module 1002.
  • the client application 13 may transmit an import request 1004 including the external system ID and user ID to the synchronization module 316.
  • the synchronization module 316 may transmit a common query 1006 including an external task ID and external user ID to the data exchange module 1000, which may forward the query 1008 to the application specific data exchange module 1002.
  • the application specific data exchange module 1002 may transmit a token query 1010 to the server database 18.
  • the server database 18 may transmit a response 1012 containing the token to the application specific data exchange module 1002.
  • the application specific data exchange module 1002 may then transmit a custom query 1014 containing the token and external task ID to the third- party application 902.
  • the third-party application may transmit a response 1016 including the task data to the application specific data exchange module 1002.
  • the application specific data exchange module 1002 may mediate the received task data 1018, and transmit the mediated task data in a response 1020 to the data exchange module 1000.
  • the data exchange module 1000 may generate a synchronization packet 1022 and transmit the synchronization packet 1024 to the synchronization module 316.
  • the synchronization module 316 may transmit an update 1026 to the cache 508 including the new task.
  • the cache 508 may in turn transmit an update 1028 to the server database 18.
  • the synchronization module 316 may request changes 1030 from the cache 508, which may transmit the changed records 1032 to the synchronization module 316.
  • the synchronization module 316 may transmit a synchronization packet 1034 to the client application 13.
  • External integrations may have a dedicated configuration interface both for the users and for system administrators.
  • the users may configure their external accounts and task sources from the server desktop clients and through the portal.
  • the following exemplary functionalities may be included: select external task sources, perform authentication towards external task sources.
  • System administrators may have the following configuration preferences on the administration console: select which external systems the users can use; each external system will have its own configuration as different systems may need different information for integration.
  • General configuration information known at this point may include the client ID: In case of some external systems, the desktop manager may need to be registered to obtain a unique client identifier to be able to connect to that system.
  • External systems will be connected over LAN or the Internet. This configuration may hold the information how these systems can be connected, e.g., using a URL or URL External systems may need to access the desktop manager in order to send back data. This configuration may hold the information how these systems can connect to the desktop manager e.g., using a URL or URL
  • reporting tool such as JasperReports
  • External systems may be able to compile queries from different pre-defined parameters such as UserlD, TaskID, users in a group, etc. This process may be implemented in the reporting module 402.
  • the reporting module 402 may be a standalone web application that has a direct connection with the server database 18.
  • the reporting module 402 may also provide a REST API interface through which external report consumers can query data in the form of an HTTP request.
  • the queried data may be sent back in JSON objects.
  • the data transfer may be scheduled, or may follow a "push-pull" process.
  • a suitable protocol e.g., HTTP(s) Basic Authentication
  • HTTP(s) Basic Authentication e.g., HTTP(s) Basic Authentication
  • a protocol that doesn't require cookies, session identifier and login pages may be used which employs static, standard fields in the HTTP header so that no handshakes have to be done in anticipation.
  • the external report consumers may provide a unique identifier that was obtained from the desktop manager in advance by which they will be authenticated and authorized.
  • HTTPS may be applied, which may prevent the report consumers' unique identifier from being intercepted.
  • External reporting may have a dedicated configuration so that it is possible to compile queries for external reports (per user, per task, per group, etc.), and to set reporting periodicity.
  • the client application 13 may be configured to allow users to share a post or achievement, for example, if a (non-confidential) task is completed, to a social media platform.
  • An exemplary post may be "Joan has successfully completed all her tasks scheduled for this week.”, or "It's lunchtime and I have only completed 3 tasks out of 10.
  • the desktop manager may communicate with a social media server through an application interface to get transmit data to, and receive data from the social media platform.
  • Client side integrations may use plug-in software components that add the feature of connecting to the desktop manager to specific user applications. These may include a browser plug-in that differentiates between private and work-related web sites, and collects only work-related website information. Other plug-ins may include plug-ins for calendar and email applications.
  • FIG. 12 depicts time line showing a series of events occurring on a user device 12 as the user switches between applications.
  • the desktop manager may store data to a database (e.g. the server database 18, the local database 308, and/or any other suitable database) that documents the context switch. This may include documenting an amount of time spent on the task associated with the context being switched from.
  • the desktop manager may further update all timers associated with the previous task to indicate the time spent thereon, and begin tracking time of the newly opened task.
  • the desktop manager may define a virtual desktop for the task context of the task being switched from, and may retrieve data from the server database 18 that defines the virtual desktop of the task context of the task being switched to.
  • FIGS. 13 and 14 a method of task assignment is illustrated wherein the manual assignment or reassignment is carried out by user via interacting with one or more visual elements that decorate or otherwise mark resources or application windows.
  • the decorating may comprise an addition/extension to the application's existing user interface elements, an addition/extension/modification to the visual presentation aspects of the windowing toolkit/window system, or any other suitable addition, extension or modification to the user interface of the resource.
  • the visual element may comprise a permanently visible floating control that re-positions itself to the window of the active (e.g., user focused) resource.
  • FIG. 15 illustrates a method as described above wherein the result of a manual or automatic assignment or reassignment is displayed to the user by decorating visible parts of resources or application windows with one or more visual elements that display or indicate which task is assigned to a resource.
  • the decorating may comprise, for example: an addition/extension to the application's existing user interface elements, and/or an
  • FIG. 13 shows a particular version of such a visual extension added to the application window frame.
  • a narrow stripe (2) is attached to the top of the application window (1).
  • the color of the stripe may provide information about the assignment status of the resource. For example, color 1 (e.g., green) may indicate the resource is not assigned, color 2 (e.g., red) may indicate the resource is already assigned to a task.
  • color 1 e.g., green
  • color 2 e.g., red
  • the stripe (2) may act as a dropdown element as shown in FIG. 14.
  • FIG. 14 shows a particular version of a task assignment control attached to the top of the application window frame.
  • the control contains: a search area (1) where the user can search for existing tasks or create new tasks, an assigned tasks area (2) that lists all tasks that the resource open in this window is assigned to (multiple assignment is possible but only one can be active at a time as shown here), and another tasks area (3) where the system displays other existing tasks in the order of relevance.
  • FIG. 15 shows a particular version of the visual representation of task assignment (manual or automatic) attached to the top of the application window frame.
  • the control contains: the name of the task (1) assigned to the resource open in this window, and a clickable icon or area (2) that can be used to open the full task assignment control to change the assignment of this resource.
  • Time measurement may be based on time spent in each window and the window's resource assignment and relation to the task. Thus, the user may not need to start or stop timers manually, or explicitly express their intention to switch tasks in any way. Activities (such as defined above) may be the basic unit of time measurement in the desktop manager. The total time measured for a task may be the sum of the time fragments that desktop manager has measured for individual activities.
  • tasks and resources may be grouped by users. These groups may be represented visually with the aim of reducing the cost of task switching in two ways. Firstly, by providing organized overview of these groups, secondly by offering a faster option for finding and switching between tasks and resources. Furthermore, these visual representations of task-resource groups provide an understanding of how the time tracking works and enable to verify if task-resource assignments are correct. In the following, three examples are introduced for possible implementations of these visualizations.
  • FIG. 16 illustrates an exemplary one-line overview of resources grouped by tasks in a recently used order.
  • tasks (2) are ordered in recently used order, with the current task on the right.
  • This is a scrollable view in which users can scroll to older tasks.
  • Tasks include resources (3) that are currently open. These resources (3) are organized in recently used order in the corresponding tasks (2).
  • a numberN of closed resources defined by the user are visualized in each task (2). Using this view, resources can also be re-assigned, open resources can be brought into focus and closed resources can be reopened.
  • FIG. 17 illustrates a possible implementation for a full screen overview of resources grouped by tasks. While in the view depicted in FIG. 16, tasks were only visualized in a line, the overview depicted in FIG. 17 uses the full screen for similar purposes. In the example, tasks are ordered in recently used order on the scrollable bottommost line without resources visualized in them. The first item (1) represents all tasks. If this item is chosen, tasks are listed on the lines above on a scrollable view.
  • FIG. 18 shows a different state of system than depicted in FIG. 17.
  • the rest of the items in the bottom line represent tasks in recently used order.
  • a task e.g., Task 1 as indicated by the highlighted graphical object
  • corresponding resources may be listed in the upper part of the screen.
  • resources can be re-assigned, open resources can be brought into focus, and closed resources can be reopened.
  • FIG. 19 illustrates a one-line overview of resources grouped by tasks on a chronological timeline.
  • resources may be visualized in a reverse chronological order based on the last time they have been used, starting from the right. Corresponding tasks may also be depicted.
  • the rightmost item on the line is the currently used resource, which is a.doc from Task 1.
  • two adjacent resources are from the same task, they may be visually grouped together such as d.doc and e.xls from Task 2 in the depicted example.
  • unassigned resources can be assigned to tasks or already assigned resources can be re-assigned to other tasks. This can also be done simultaneously for multiple resources by selecting more than one resource to be assigned/re-assigned
  • the assigning/reassigning of resources may affect time measured for a particular resource. If a re-assignment happens, time measured in the past for one task may be moved to another past task. All future measurement may be assigned to the newly selected task, unless further re-assignments occur.
  • Automatic webpage assignment may refer to a computer-implemented method of automatic assignment as described above under section 3) based on a longest matching partial URL.
  • the desktop manager may try to assign the webpage automatically to the most relevant task using the following steps: (1) already known pages of the domain at hand may be clustered into groups based on the tasks they were assigned to in the past, (2) within each group, the system may generate the longest common stem of the URLs using a simple stemming algorithm, (3) the common stems from each group may be compared with the stem of the new URL at hand and the new URL automatically assigned to the task of the group with the longest matching stem. Restoring Task Context
  • Restoring task context may include restoring the context of a task where the context is defined by a group of resources being available to the user. If the last time one or more resources were actively opened was in an application, these resources may be loaded into memory along with an application that can handle that resource.
  • the context of a task can extend beyond the boundaries of one device.
  • a user having the desktop manager installed on multiple devices might interact with such devices simultaneously or by switching between devices in a rapid succession.
  • Embodiments of the invention may consolidate the information coming from multiple devices into one joint task context if the activities happening on all devices are identified as belonging to the same task. Otherwise (in case the identified tasks are different), the user may be offered a choice to declare which task he or she is working on.
  • An example of the extended context is a user editing a document on a desktop and calling a colleague for assistance on their mobile phone while working on the same task.
  • the user can see the list of all resources on each device regardless of where the resource was originally used, but whether a particular resource can be accessed or not may depend on the capabilities of the given device.
  • a word processing document that was edited by the user on a notebook computer may be listed as part of the task context on a mobile phone, but the mobile phone user may not be able to work with the file unless, for example, the phone supports editing word processing documents of that type and the file is stored in the cloud.
  • the task shortlist solution is a method of assignment as described above in section 2 that is used to create an ordered list of tasks based on the likelihood/confidence of an unclassified or automatically classified resource belonging to one or more task.
  • the user may need to decide whether or not the given resource belongs to a task. To do this, the user may select a task from their complete task list.
  • a shortlist may be created containing the most likely possible tasks where the given resource belongs.
  • the shortlist may contain the tasks in an order base on probability, with the most likely task in the first place.
  • the algorithm for displaying the shortlist may contain more than one procedure to determine the shortlist elements. When more than one procedure is contained, the procedures may run in parallel or sequentially to determine the most relevant tasks or shortlist variants, and an aggregated decision made by the method to finalize the shortlist. The procedures may be ranked and weighted by how they are involved in the final decision.
  • the following procedures and rules may be used by the display algorithm: add last assigned tasks, list recently active task sessions in reverse chronological order, usage of tasks and resources aging in time, statistical data of resources and task within a given time period (such as but not limited to: number of resource access, number of task sessions by task, usage frequency of a resources), time spent in tasks, and/or task sessions within a given time period (such as but not limited to: shortest and longest task session, cumulative time spent on task).
  • the desktop manager may use a process for understanding what the user is working on. For example, the desktop manager may poll the state and contents of the focused window or subscribe to operating system or windowing subsystem level events using several methods. Events may be collected by one or more event listeners each assigned to a specific event source. State polling may also be done by the event listeners and polled information converted into logical events. One useful event listener may use the standard UI accessibility and UI automation APIs of the operating systems.
  • Individual event listeners may provide some partial information about the state of the operating system and the state of any active applications.
  • One event listener might provide the process identifier, system window identifier and window title information of the focused application window, and another might provide process identifier and path information for an opened file based on file system events.
  • Some applications may require specific event listeners to provide sufficiently detailed information about the state of the targeted application.
  • Embodiments of the invention may allow the extension of the list of event listeners should a new event listener be added to handle a previously unknown application.
  • the resource oracle component may collect data from the event listeners and put together pieces of information to generate a complete picture about the resource that is being used by the user. For example, resource oracle may merge process identifier and window title information coming from one event listener and process identifier and opened file path information coming from another event listener into a single meaningful event. By matching the process identifiers, the desktop manager may find the opened file's name in the window title, and thereby assume with a degree of certainty that the resource (file, web page, etc.) is open in a specific window. After matching the data, the resource oracle may pass the complete information (resource) to the task oracle.
  • resource oracle may pass the complete information (resource) to the task oracle.
  • the task oracle may be configured to determine which task the newest resource belongs to, and to provide indications (e.g., a task shortlist) about other tasks the resource might belong to.
  • the task oracle may use an Analytic Hierarchy Process (AHP) decision process based on various 'decision aspects' which look at the resource and the user's work session from various point of views.
  • AHP Analytic Hierarchy Process
  • Each aspect may use a specific evaluation function to assign a numeric probability value to the list of tasks that could be associated with the resource.
  • These evaluation functions may be different (linear, binary, step-wise, Gaussian curve) depending on the nature of the specific aspect.
  • the parameters of the functions may be tuned based on feedback from user decisions.
  • the results of these initial calculations in parallel in each aspect are lists of task-probability pairs which contain the best N tasks with the highest probabilities.
  • pairs within each aspect may be loaded into separate comparison matrices.
  • the final probability list within a single aspect may be defined by calculating the Eigen vector of the largest non-complex Eigen value of the comparison matrix.
  • Each aspect may have its own weight in the decision-making process.
  • Generic aspects may have a relatively low weight as compared to non-generic aspects so that they make minor changes in the result. In contrast, the results of the non-generic aspects may be weighted more heavily.
  • the task oracle may combine results from each aspect into a decision matrix, and multiply the decision matrix by a vector containing the weight of each aspect.
  • the result may be a vector containing the final list of tasks, where the first item is the task the newest resource is most likely to belong to, and the last item is the task the newest resource is least likely to belong to.
  • the highest probability task may be used for auto assignment, while the following n items in the probability list may be offered to the user as a task shortlist.
  • the task shortlist may facilitate quick selection by the user should a manual overriding of the automatic selection be necessary. Learning may be achieved by feeding the identifier of the manually selected task back into the system to re-calculate weights used during the calculation within the aspects (evaluation function parameters) and when combining the results from the aspects (aspect weights). This feedback mechanism may cause the calculation to become tuned to the user' s preferences over time.
  • Embodiments of the invention may be implemented on one or more computers each comprising one or more processors selected from microprocessors, micro-controllers, digital signal processors, microcomputers, central processing units, field programmable gate arrays, programmable logic devices, state machines, logic circuits, analog circuits, digital circuits, and/or any other devices that manipulate signals (analog and/or digital) based on operational instructions that are stored in a memory.
  • Memory may be a single memory device or a plurality of memory devices including but not limited to read-only memory (ROM), random access memory (RAM), volatile memory, non-volatile memory, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, cache memory, and/or any other device capable of storing digital information.
  • the memory may also include a mass storage device.
  • the mass storage device may be a single mass storage device or a plurality of mass storage devices including but not limited to hard drives, optical drives, tape drives, non-volatile solid state devices and/or any other device capable of storing information.
  • the computer may also include an Input/Output (I/O) interface that employs a suitable communication protocol for communicating with external devices and/or networks.
  • I/O Input/Output
  • the processor may operate under the control of an operating system, which may reside in the memory.
  • the operating system may manage the computer resources so that computer program code embodied as one or more computer software applications residing in memory may have instructions executed by the processor.
  • a human machine interface may be operatively coupled to the processor of the computer.
  • the HMI may include output devices, such as alphanumeric displays, a touch screen, and other visual indicators, and input devices and controls, such as an alphanumeric keyboard, a pointing device, keypads, pushbuttons, control knobs, etc., capable of accepting commands or input from the operator and transmitting the entered input to the processor.
  • routines executed to implement the embodiments of the invention may be referred to herein as "computer program code,” or simply "program code.”
  • Program code typically comprises computer-readable instructions that are resident at various times in various memory and storage devices in a computer and that, when read and executed by one or more processors in a computer, cause that computer to perform the operations necessary to execute operations and/or elements embodying the various aspects of the embodiments of the invention.
  • Computer-readable program instructions for carrying out operations of the embodiments of the invention may be, for example, assembly language or either source code or object code written in any combination of one or more programming languages.
  • the program code embodied in any of the applications/modules described herein is capable of being individually or collectively distributed as a program product in a variety of different forms.
  • the program code may be distributed using a computer-readable storage medium having computer-readable program instructions thereon for causing a processor to carry out aspects of the embodiments of the invention.
  • Computer-readable storage media which is inherently non-transitory, may include volatile and non-volatile, and removable and non-removable tangible media implemented in any method or technology for storage of information, such as computer- readable instructions, data structures, program modules, or other data.
  • Computer-readable storage media may further include RAM, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other solid state memory technology, portable compact disc read-only memory (CD-ROM), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and which can be read by a computer.
  • a computer-readable storage medium should not be construed as transitory signals per se (e.g., radio waves or other propagating electromagnetic waves, electromagnetic waves propagating through a transmission media such as a waveguide, or electrical signals transmitted through a wire).
  • Computer-readable program instructions may be downloaded to a computer, another type of programmable data processing apparatus, or another device from a computer-readable storage medium or to an external computer or external storage device via a network.
  • Computer-readable program instructions stored in a computer-readable medium may be used to direct a computer, other types of programmable data processing apparatuses, or other devices to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions that implement the functions, acts, and/or operations specified in the flow charts, sequence diagrams, and/or block diagrams.
  • the computer program instructions may be provided to one or more processors of a general purpose computer, a special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the one or more processors, cause a series of computations to be performed to implement the functions, acts, and/or operations specified in the flow charts, sequence diagrams, and/or block diagrams.
  • any of the flow charts, sequence diagrams, and/or block diagrams may include more or fewer blocks than those illustrated consistent with embodiments of the invention.
  • the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the embodiments of the invention. As used herein, the singular forms "a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise.

Abstract

L'invention concerne des systèmes, des procédés et des produits de programmes informatiques pour gérer des tâches à travers une pluralité de dispositifs informatiques (12). Des événements indiquant des changements depuis une activité vers une autre dans un ou plusieurs dispositif(s) informatique(s) (12) sont suivis par une application client (13) sur chaque dispositif (12). L'application client (13) transmet des données concernant les événements à un serveur d'application (14), qui stocke et organise les données dans une base de données (18). Des événements qui indiquent que le dispositif informatique (12) a subi un changement de contexte sont utilisés pour déterminer quelles tâches sont en cours de traitement par le dispositif informatique (12), et pour suivre une quantité de temps consacré à chaque tâche sur l'ensemble d'une pluralité dispositifs informatiques (12). La base de données (18) peut également être utilisée pour faciliter l'ouverture ou la restauration d'un contexte sur un ou plusieurs parmi les dispositifs informatiques (12), ou pour déplacer un contexte depuis un dispositif informatique (12) vers un autre.
PCT/IB2017/001469 2016-10-17 2017-10-17 Gestion de bureau et transfert de données dans un environnement multi-ordinateurs WO2018073649A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662409111P 2016-10-17 2016-10-17
US62/409,111 2016-10-17

Publications (1)

Publication Number Publication Date
WO2018073649A1 true WO2018073649A1 (fr) 2018-04-26

Family

ID=60782257

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2017/001469 WO2018073649A1 (fr) 2016-10-17 2017-10-17 Gestion de bureau et transfert de données dans un environnement multi-ordinateurs

Country Status (1)

Country Link
WO (1) WO2018073649A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109784015A (zh) * 2018-12-27 2019-05-21 腾讯科技（深圳）有限公司 一种身份鉴别方法及装置
WO2021077142A3 (fr) * 2021-02-25 2021-07-08 Innopeak Technology, Inc. Gestion de temps d'écran au niveau de multiples dispositifs répartis
US20220261300A1 (en) * 2020-08-25 2022-08-18 Citrix Systems, Inc. Context-based notification processing system
US11921592B2 (en) 2020-07-20 2024-03-05 Google Llc Restoration of a computing session

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050097506A1 (en) * 2003-10-31 2005-05-05 Hewlett-Packard Development Company, L.P. Virtual desktops and project-time tracking
WO2013074750A1 (fr) * 2011-11-15 2013-05-23 Traasdahl Are Helge Identification et pistage de l'activité d'un utilisateur lors de l'utilisation de dispositifs reliés en réseau, sur la base d'associations entre des identificateurs de dispositifs physiques ou des applications logicielles

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050097506A1 (en) * 2003-10-31 2005-05-05 Hewlett-Packard Development Company, L.P. Virtual desktops and project-time tracking
WO2013074750A1 (fr) * 2011-11-15 2013-05-23 Traasdahl Are Helge Identification et pistage de l'activité d'un utilisateur lors de l'utilisation de dispositifs reliés en réseau, sur la base d'associations entre des identificateurs de dispositifs physiques ou des applications logicielles

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109784015A (zh) * 2018-12-27 2019-05-21 腾讯科技（深圳）有限公司 一种身份鉴别方法及装置
CN109784015B (zh) * 2018-12-27 2023-05-12 腾讯科技（深圳）有限公司 一种身份鉴别方法及装置
US11921592B2 (en) 2020-07-20 2024-03-05 Google Llc Restoration of a computing session
US20220261300A1 (en) * 2020-08-25 2022-08-18 Citrix Systems, Inc. Context-based notification processing system
WO2021077142A3 (fr) * 2021-02-25 2021-07-08 Innopeak Technology, Inc. Gestion de temps d'écran au niveau de multiples dispositifs répartis

Similar Documents

Publication Publication Date Title
US20220188306A1 (en) Executing one query based on results of another query
US9647922B2 (en) Computer implemented methods and apparatus for trials onboarding
US11575772B2 (en) Systems and methods for initiating processing actions utilizing automatically generated data of a group-based communication system
US10592866B2 (en) Calendar application, system and method for creating records in a cloud computing platform from within the context of the calendar application
US11924289B2 (en) Multi-workspace shared communication channel
US10671283B2 (en) Systems, methods, and apparatuses for implementing intelligently suggested keyboard shortcuts for web console applications
US10713101B2 (en) Client-based control and experience of application programming interfaces in an on-demand environment
US11604799B1 (en) Performing panel-related actions based on user interaction with a graphical user interface
WO2018073649A1 (fr) Gestion de bureau et transfert de données dans un environnement multi-ordinateurs
US11644955B1 (en) Assigning a global parameter to queries in a graphical user interface
US20180246921A1 (en) Techniques and architectures for data field lifecycle management
US11847165B2 (en) Integration of video conferencing applications with on-demand database services
US20200042724A1 (en) Systems and methods for secure data transfer between entities in a multi-user on-demand computing environment
US11914744B2 (en) Intelligent contextual help chat in a multi-tenant database system
US20230351031A1 (en) Referencing a document in a virtual space
US11711330B2 (en) Out of office message configuration
US11599235B1 (en) Mobile-generated desktop reminders
US20220327097A1 (en) Repository for quick retrieval of object(s) of a communication platform
US11966770B2 (en) Collaboration across isolated virtual environments
US20230177064A1 (en) Cloud data consolidation and processing system
US20220345436A1 (en) Cross-platform message management system
US20230127356A1 (en) Converting private channels to public channels
WO2023048934A1 (fr) Rappels de bureau générés par mobile

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17818256

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17818256

Country of ref document: EP

Kind code of ref document: A1