WO2016145511A1

WO2016145511A1 - Methods, apparatus and computer-readable media for sharing of application resources

Info

Publication number: WO2016145511A1
Application number: PCT/CA2016/050102
Authority: WO
Inventors: Jean-Baptiste Martinoli; Albert DANG; Paul TOCATLIAN; Hon Cheong TANG; Chunxiong ZHOU; Shan AHDOOT; Kenneth Chen
Original assignee: Exo U Inc.
Priority date: 2015-03-19
Filing date: 2016-02-04
Publication date: 2016-09-22

Abstract

A method is executed by a communication device, which can be an originating entity or a destination entity. For an originating entity, the method may comprise executing a workspace application; executing a utility application within the workspace application; responsive to a user invoking a share function, obtaining resources for the utility application; and sharing the resources with the destination entity. For a destination entity, the method may comprise executing a workspace application; executing a utility application within the workspace application; the workspace application receiving resources for the utility application, the resources having been shared by the originating entity; and executing the utility application using the received resources. Also provided is a server that manages communication between the originating and destination entities, as well as related apparatus and computer-readable media.

Description

METHODS, APPARATUS AND COMPUTER-READABLE MEDIA FOR SHARING OF

APPLICATION RESOURCES

CROSS-REFERENCE TO RELATED APPLICATION

The present application claims the benefit of U.S. Provisional Application Serial No. 62/135,399, filed on March 19, 2015, which is hereby incorporated by reference herein.

FIELD

The present invention relates generally to communication amongst communication devices and, in particular, to methods, apparatus and computer-readable media for sharing application resources amongst communication devices. BACKGROUND

Mobile networked communication devices (e.g., smartphones and tablets) are an example of technology that facilitates the exchange of ideas amongst individuals. In the early days of the Blackberry handheld and other similar devices, the use of such devices was almost exclusively for business purposes. Companies would, and to a certain extent still do, subsidize their workers' usage of smartphones for business purposes. However, with the introduction of the iPhone device from Apple and its competitors from other manufacturers, non-business users became the norm, making personal smartphones ubiquitous in the workplace and the classroom. With the realization that the same device could now be used for both personal communication and for business, corporations and other technology-savvy institutions such as schools have attempted to harness the latent power of individual user's devices brought into the workplace or to class (BYOD - bring your own device). However, the transitioning of personal devices into a closed environment such as a workplace or school has had only limited success, due in part to the wide (and continuously widening) variety of operating systems that span the BYOD spectrum. Another aspect that has plagued management of BYOD devices in the workplace is the lack of message flow coordination when multiple devices attempt to communicate with one another to achieve a collaborative result. In view of the foregoing, it would appear beneficial to provide methods, systems and computer- readable media with improved sharing of information among devices, irrespective of their native platform.

SUMMARY OF THE INVENTION

Thus, according to a first broad aspect of the present invention, there is provided a method for execution by a communication device, comprising: executing a workspace application; executing a utility application within the workspace application; responsive to a user invoking a share function, obtaining resources for the utility application; sharing the resources with at least one destination entity.

According to another broad aspect of the present invention, there is provided computer-readable media storing instructions which, when executed by a processor of a communication device, cause the communication device to execute a method that comprises: executing a workspace application; executing a utility application within the workspace application; responsive to a user invoking a share function, obtaining resources for the utility application; sharing the resources with at least one destination entity.

According to another broad aspect of the present invention, there is provided a communication device, comprising: a user input/output interface for allowing a user to interact with the communication device; a network interface for connecting the device to a communications network; at least one processor configured to execute a workspace application and to execute a utility application within the workspace application and, responsive to a user invoking a share function via the user input/output interface, to obtain resources for the utility application, and to share the resources with at least one destination entity by transmitting at least one message to the destination entity over the communications network via the network interface.

According to another broad aspect of the present invention, there is provided a method for execution by a communication device, comprising: executing a workspace application; executing a utility application within the workspace application, the communication device producing an interactive graphical environment on a display of the communication device to allow a user of the communication device to interact with the utility application; receiving an instruction from the user of the communication device to lock a session that involves the user of the communication device; executing a session database to indicate that the session is locked. According to another broad aspect of the present invention, there is provided computer-readable media storing instructions which, when executed by a processor of a communication device, cause the communication device to execute a method that comprises: executing a workspace application; executing a utility application within the workspace application, the communication device producing an interactive graphical environment on a display of the communication device to allow a user of the communication device to interact with the utility application; receiving an instruction from the user of the communication device to lock a session that involves the user of the communication device; updating a session database to indicate that the session is locked.

According to another broad aspect of the present invention, there is provided a communication device, comprising: a user input/output interface for allowing a user to interact with the communication device; a network interface for connecting the device to a communications network; at least one processor configured to execute a workspace application; to execute a utility application within the workspace application, the processor causing the user input/output to produce an interactive graphical environment to allow a user of the communication device to interact with the utility application; to receive an instruction from the user of the communication device to lock a session that involves the user of the communication device; and to cause the network interface to communicate with a session database to update the session database to indicate that the session is locked.

According to another broad aspect of the present invention, there is provided a method for execution by a communication device, comprising: executing a workspace application; executing a utility application within the workspace application; the workspace application receiving resources for the utility application, the resources having been shared by an originating entity; executing the utility application using the received resources.

According to another broad aspect of the present invention, there is provided computer-readable media storing instructions which, when executed by a processor of a communication device, cause the communication device to execute a method that comprises: executing a workspace application; executing a utility application within the workspace application; the workspace application receiving resources for the utility application, the resources having been shared by an originating entity; executing the utility application using the received resources. According to another broad aspect of the present invention, there is provided a communication device, comprising: a user input/output interface for allowing a user to interact with the communication device; a network interface for connecting the device to a communications network; at least one processor configured to execute a workspace application; to execute a utility application within the workspace application, the workspace application receiving resources for the utility application, the resources having been shared by an originating entity; and to execute the utility application using the received resources.

According to another broad aspect of the present invention, there is provided a method for execution by a communication device, comprising: during execution of a workspace application on top of a native operating system of the communication device, receiving a sharing message sent by an originating entity, the sharing message comprising resources for a utility application; extracting from the sharing message the resources for the utility application; determining an action to be taken in respect of launching the utility application with the extracted resources; taking said action.

According to another broad aspect of the present invention, there is provided computer-readable media storing instructions which, when executed by a processor of a communication device, cause the communication device to execute a method that comprises: during execution of a workspace application on top of a native operating system of the communication device, receiving a sharing message sent by an originating entity, the sharing message comprising resources for a utility application; extracting from the sharing message the resources for the utility application; determining an action to be taken in respect of launching the utility application with the extracted resources; taking said action.

According to another broad aspect of the present invention, there is provided a communication device, comprising: a user input/output interface for allowing a user to interact with the communication device; a network interface for connecting the device to a communications network; at least one processor configured to execute a workspace application on top of a native operating system of the communication device so as to receive, during execution of the workspace application, a sharing message sent by an originating entity via the network interface, the sharing message comprising resources for a utility application; to extract from the sharing message the resources for the utility application; to determining an action to be taken in respect of launching the utility application with the extracted resources; and to take said action. According to another broad aspect of the present invention, there is provided a method for execution by a communication device, comprising: executing an activity feed that graphically advises a user of the communication device of messages received from other users that remain to be processed to completion; causing messages received from users that are in a session with the user of the communication device to be graphically displayed differently from messages received from users that are not in a session with the user of the communication device.

According to another broad aspect of the present invention, there is provided computer-readable media storing instructions which, when executed by a processor of a communication device, cause the communication device to execute a method that comprises: executing an activity feed that graphically advises a user of the communication device of messages received from other users that remain to be processed to completion; causing messages received from users that are in a session with the user of the communication device to be graphically displayed differently from messages received from users that are not in a session with the user of the communication device.

According to another broad aspect of the present invention, there is provided a communication device, comprising: a user input/output interface for allowing a user to interact with the communication device; a network interface for connecting the device to a communications network; at least one processor configured to execute an activity feed that graphically advises a user of the communication device via the user input/interface of messages received via the network interface from other users that remain to be processed to completion; and to cause messages received from users that are in a session with the user of the communication device to be graphically displayed differently from messages received from users that are not in a session with the user of the communication device.

According to another broad aspect of the present invention, there is provided a method for execution by a communication device, comprising: executing a workspace application; executing a second application within the workspace application, wherein the device is caused to produce an interactive graphical environment on a display of the device; consulting a session database to determine whether a session in which the device is involved has been locked by a leader of the session; in case the session has been locked, causing the interactive graphical environment on the destination device to replicate an interactive graphical environment being produced on a communication device associated with the leader. According to another broad aspect of the present invention, there is provided computer-readable media storing instructions which, when executed by a processor of a communication device, cause the communication device to execute a method that comprises: executing a workspace application; executing a second application within the workspace application, wherein the device is caused to produce an interactive graphical environment on a display of the device; consulting a session database to determine whether a session in which the device is involved has been locked by a leader of the session; in case the session has been locked, causing the interactive graphical environment on the destination device to replicate an interactive graphical environment being produced on a communication device associated with the leader.

According to another broad aspect of the present invention, there is provided a communication device, comprising: a user input/output interface for allowing a user to interact with the communication device; a network interface for connecting the device to a communications network; at least one processor configured to execute a workspace application; to execute a utility application within the workspace application; to produce an interactive graphical environment via the user input/interface; to consult via the network interface a session database to determine whether a session in which the device is involved has been locked by a leader of the session; and, in case the session has been locked, to cause the interactive graphical environment to replicate an interactive graphical environment being produced on a communication device associated with the leader.

According to another broad aspect of the present invention, there is provided a method implemented by a server, comprising: receiving from an originating user a sharing message and an indication of a destination user, the destination user and the originating user being members of a common group of members, the originating user having a role-based authority to send sharing messages to the destination user; consulting at least one database to determine whether the destination user is involved in a session that does not involve the originating user; in case the destination user is involved in a session that does not involve the originating user, withholding transmission of the sharing message at the server, otherwise causing the sharing message to be transmitted to the destination user.

According to another broad aspect of the present invention, there is provided computer-readable media storing instructions which, when executed by a processor of a communication device, cause the communication device to execute a method that comprises: receiving from an originating user a sharing message and an indication of a destination user, the destination user and the originating user being members of a common group of members, the originating user having a role-based authority to send sharing messages to the destination user; consulting at least one database to determine whether the destination user is involved in a session that does not involve the originating user; in case the destination user is involved in a session that does not involve the originating user, withholding transmission of the sharing message at the server, otherwise causing the sharing message to be transmitted to the destination user.

According to another broad aspect of the present invention, there is provided a server, comprising: a network interface for connecting the server to a communications network; at least one processor configured to receive, via the network interface, from an originating user, a sharing message and an indication of a destination user, the destination user and the originating user being members of a common group of members, the originating user having a role-based authority to send sharing messages to the destination user; to consult at least one database to determine whether the destination user is involved in a session that does not involve the originating user; and, in case the destination user is involved in a session that does not involve the originating user, to withhold transmission of the sharing message at the server, otherwise to cause the sharing message to be transmitted to the destination user via the network interface.

According to another broad aspect of the present invention, there is provided a method implemented by a server, comprising: receiving an indication of a particular user; consulting a database to identify a group of members to which the particular user belongs, each member having a role selected from a group that includes at least a first role and a second role, wherein a member having the first role has an ability to share messages with members having the second role and a member having the second role lacks an ability to share messages with members having the first role; in case the particular user has the first role, signaling to the particular user an indication of each member of the group having the second role.

According to another broad aspect of the present invention, there is provided computer-readable media storing instructions which, when executed by a processor of a communication device, cause the communication device to execute a method that comprises: receiving an indication of a particular user; consulting a database to identify a group of members to which the particular user belongs, each member having a role selected from a group that includes at least a first role and a second role, wherein a member having the first role has an ability to share messages with members having the second role and a member having the second role lacks an ability to share messages with members having the first role; in case the particular user has the first role, signaling to the particular user an indication of each member of the group having the second role.

According to another broad aspect of the present invention, there is provided a server, comprising: a network interface for connecting the server to a communications network; at least one processor configured to receive an indication of a particular user via the network interface; to consult a database to identify a group of members to which the particular user belongs, each member having a role selected from a group that includes at least a first role and a second role, wherein a member having the first role has an ability to share messages with members having the second role and a member having the second role lacks an ability to share messages with members having the first role; and, in case the particular user has the first role, to signal to the particular user via the network interface an indication of each member of the group having the second role.

BRIEF DESCRIPTION OF THE DRAWINGS

Having thus described example implementations of the disclosure in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein; Figs. 1A-1B depict diagrams illustrating a network of data processing systems in accordance with example implementations;

Fig. 2A is an illustration of a user-device association database in accordance with one example implementation;

Fig. 2B is an illustration of a group-user association database in accordance with one example implementation;

Fig. 2C is an illustration of a rules database in accordance with one example implementation;

Fig. 3 is an illustration of server memory in accordance with one example implementation;

Figs. 4-7 are example diagrams illustrating a graphical user interface (GUI) in accordance with example implementations; Fig. 8 is an illustration of a permissions database in accordance with one example implementation;

Figs. 9-12 are other example diagrams illustrating a graphical user interface (GUI) in accordance with example implementations;

Fig. 13 is an illustration of a rules database in accordance with one example implementation;

Fig. 14 illustrates diagrams of a SHARE message and ATTACH message in accordance with one example implementation;

Fig. 15 is a flowchart of a share process in accordance with one example implementation;

Figs. 16A-16B are flowcharts of the messaging processing function in accordance with example implementations;

Fig. 17 is an illustration of a workspace app installation process in accordance with one example implementation; Fig. 18 is a diagram illustrating execution of a workspace app in accordance with one example implementation;

Fig. 19 is an illustration of a share process in accordance with one example implementation; Fig. 20 is another example of a flowchart of the execution of the messaging processing function in accordance with one example implementation;

Figs. 21 is another example diagram illustrating a graphical user interface (GUI) in accordance with one example implementation;

Fig. 22 is a flowchart of the session creation process in accordance with one example implementation;

Fig. 23 is an illustration of a user availability database in accordance with one example implementation; and Fig. 24 is an illustration of a group-user association database in accordance with one example implementation. DETAILED DESCRIPTION

In accordance with certain non-limiting embodiments of the present invention, users form part of a "community" and are desirous of sharing information, resources and user experiences with one another. The community may have a strong or loose connection to a physical space. As such, in various non-limiting examples, a community could include the students and teachers of a particular school or university campus, medical staff working in connection with a health care facility, management and employees of an enterprise, etc. The community may have a strong or loose connection to a temporal period, such as a date and/or time. This would allow a community to be set up for a limited time such as a school year or semester, or for the duration of a medical operation or a corporate project. Other examples include a convention, a sports event, etc.

In some cases, it is desired to share information, resources and user experiences among a subset of users in the community. When all members of the subset are connected, sharing of application resources may be expected to occur in real time or near-real time. In other cases, not all users of the subset employ devices that happen to be connected at the time that sharing is initiated and therefore the system may also be designed to enable asynchronous sharing. This would allow users whose devices are not connected to each other at the time sharing is initiated to receive shared application resources (or to share application resources) once their devices' connection (to each other or to a central entity such as a server) is regained.

With reference to FIGS. 1A and IB, users employ communication devices 100 (hereinafter "user devices") such as portable or mobile devices, which may be laptops, smart phones, tablets, phablets, and the like. In other scenarios, one or more of the user devices 100 may be fixed workstations or large displays. In the non-limiting embodiment illustrated in FIGS. 1A and IB, there are six user devices Dl though D6, generally referred to as 100. In a non-limiting example, each user device 100 may include a processor, memory 181, a network interface (e.g., radio access technology including antennae, modulators, multiplexers, converters, etc.) and a user input/output interface (user I/O) such as a screen (e.g., a touch screen), a keyboard, a loudspeaker and/or microphone. In other embodiments, the user devices 100 may have fewer or more components. With the additional reference to FIG. 18, the processor runs an operating system 200 (or "platform") which could be different for different user devices 100. A non- limiting list of examples of operating systems includes iOS, Android, Windows, Mac OS X, Chrome OS and Blackberry. SERVER

The user devices 100 communicate with each other via a "server" 110. Each user device 100 may be associated with a single user (e.g., as in the case of a personal mobile device) or may allow use by numerous users via a login procedure (e.g., as in the case of a computer lab workstation). It should be understood that the term "user" is meant to encompass a user account that is registered with the server 110. In addition, each user may be associated with a single user device 100 or with more than one user device 100. Also, it is possible to associate sets of users and/or user devices 100 into "groups", such that a particular group may encompass one or more members (i.e., one or more users and/or one or more individual user devices 100 or a combination thereof).

As will be shown later on, the server 110 could reside on one of the user devices 100 itself, on a content access point device, on a local network (e.g., of a classroom, school, hospital, workplace, stadium, etc.) or remotely (e.g., a data center or cloud). The server 110 may also be distributed throughout multiple networked components or user devices 100. The server 110 acts as a hub for inter-device communication. In a non-limiting example, communication between the user devices 100 and the server 110 could involve a wireless communication link 114 that does not traverse the Internet (such as a WiFi connection to a local hotspot). In another non-limiting example, communication between the user devices 100 and the server 110 could be achieved using one or more wireless links 115 that traverse the Internet 112, as is the case with user devices Dl and D6. In the latter case, user devices Dl and D6 may establish an Internet connection in a conventional way (e.g., over a data link to a service provider), and then may reach the server 110 using web services exposed by the server 110. The user devices 100 may utilize a protocol such as HTTP/S, Web Sockets, etc., for communicating with the server 110. In a third non-limiting example, communication between the user devices 100 and the server 110 could be over a fixed wired link (not shown).

The server 110 may execute an authentication process 120 for authenticating users and/or user devices 100, which may involve further external components (e.g., Active Directory, LDAP, to name a few non-limiting examples). From the foregoing, it should be understood that embodiments exist for which Internet connectivity is not required in order for user devices 100 and users to communicate with the server 110 or with each other.

With continued reference to FIG. 1A, relationships between users and user devices 100 may be maintained in a "user-device association database" 130; relationships between groups and members may be maintained in a "group-user association database" 140; and rules associated with the capabilities (e.g., message sharing capabilities) of different roles may be maintained in a "rules database" 150. A further database, the "permissions database" 160, may store information about the availability of "community apps" 210 and "community content" (to be described later on) to users having various roles and/or belonging to various groups.

The user-device association database 130 indicates the relationship between users and user devices 100. Example contents for the user-device association database 130 are shown in FIG. 2 A. In this illustrative non-limiting example, user Ul is associated with user devices Dl and D2, user U2 is associated with user devices D3 and D5, and user U3 is associated with user devices D2, D3 and D5. Conversely, user device Dl is associated with user Ul, user device D2 is associated with users Ul and U3, user device D3 is associated with devices U2 and U3, user device D4 is associated with user U3, and user device D5 is associated with user U2. The user- device association database 130 may be fixed (e.g., in the case of personalized user devices 100 uniquely associated to individual users) or it may be updated as users sign in to (and sign out of) the server 110 from a shared user device 100.

The group-user association database 140 defines groups of users and indicates the role of each user within the group. Example contents for a specific group-user association database 140A are shown in FIG. 2B. In this illustrative non-limiting embodiment, group Gl, which refers to Ms. Jones' Tuesday 3^rd period English class, includes a plurality of members, including Ms. Jones herself (user U100, who has the role of a "teacher"), as well as users Ul, U2, U4, U9, U13, U15 and U20, all of which have the role of a "student". The membership of other groups G2, G3, G4 are similarly defined. It is noted that a given user may be a member of more than one group (e.g., user U2 is shown as being a member of groups Gl and G2) and may have the same role or different roles within each group of which that user is a member. For example, a user who has the role of "student" in one group yet may have the role of "teaching assistant" in another group.

Another example of possible contents for a specific group-association database 140B is shown in Fig. 2C. In this illustrative non-limiting embodiment, groups H1-H3 may refer to respective physicians (users V1-V3) and their respective sets of patients (that include users V4-V10 in various groupings). Here, the role of each of users VI -V3 is that of a physician, while the role of each of users V4-V10 is that of a patient. In addition, groups 11-13 may refer to respective patients (users Wl, W2 and VI) and their respective clinical teams (users W4-W9 in various groupings). The roles of each of users W4-W9 may be that of a "clinician", and may be further broken down into sub-roles (not shown) such as "cardiologist", "general practitioner", "obstetrician", "ophthalmologist", etc. Here it is seen that user VI is a member of both groups HI and 13, in other words this user is a physician who treats users V4, V5 and V6, yet is also a patient of clinicians W6 and W9.

The arrangement of users into groups, and the roles of those users within those groups, may be configurable by a system administrator. Changes to the group-user association database 140 may thus occur whenever there is a new group to be formed or a user is added to or removed from a group. For example, in a school environment, this may occur on a per-semester basis as new classes are formed. In a hospital environment, this may occur daily or even more often as patients, clinicians and staff migrate through the hospital system.

With reference to FIG. 13, the rules database 150 specifies rules that apply to actions performed by users having various roles. In this illustrative non-limiting embodiment, there are four possible roles, namely "teacher", "student", "administrator" and "auditor". Other possibilities according to other organizational arrangements may exist in other embodiments and other industry scenarios. In the present non-limiting embodiment, the capabilities and prohibitions of each role are indicated from the point of view of message transmission. Thus, for example, a given user having the "teacher" role can send messages (such as SHARE messages 460, described later) to a user having the "student" role and that is in the same group as the given user, as well as to any other user having the "teacher" role, but cannot send messages to other users having the "student" role (i.e., students in other teachers' groups). Also, for example, during class hours and if a given user having the "student" role is detected as being in a classroom, the given user can only send messages to a user having the "teacher" role and that is in the same group as the given user, and thus cannot send messages to other users having the "teacher" role (i.e., teachers in other groups) or other users having the "student" role, regardless of the group they may be in. If the given user was detected as being in the cafeteria, the user is now additionally allowed to send messages to any user having the "student" role that is in the same group as the given user. Finally, after class hours, the given user may send messages to any user having the "student" role or the "teacher" role. This effectively sets up rules for enabling / limiting student communication (or data sharing). The capabilities and prohibitions of other roles can be similarly ascertained from the contents of the rules database 150. It should be appreciated that the rules database 150 may be pre-configured by an administrator and, while it is possible for the contents of the server to change, such changes might not occur frequently.

Generally speaking, the rules codified in the rules database 150 may reflect an administrative policy for communication by users having the various listed roles and, in certain embodiments, may be context-dependent based on location (both geographic and logical), time of day, day of the week, time of the year, etc., and still other possibilities will occur to those of skill in the art. Also, there may be sub-roles (e.g., for the "teacher" role, sub-roles may include "math teacher", "geography teacher", "physed teacher", "substitute teacher", "part-time teacher", etc.). In this case, with the understanding that certain rules may be applicable to all sub-roles, it is envisaged that sub-roles may be associated with their individual rules as well. The user-device association database 130, the group-user association database (140A, 140B, collectively referred to as 140) and the rules database 150 (as well as the permissions database 160) may be maintained by the server 110, or they may be external but accessible thereto, for example over a network such as the Internet 112. Other information may be stored in any of the aforementioned databases or in a separate database, and may include information such as authentication information and financial information for various users, as well as information about the hardware, firmware and software versions of various user devices 100, to name a few non-limiting possibilities.

The hardware implementation of the server 110 is not particularly limiting. For example, the server 110 may be implemented as a dedicated server (e.g., in a classroom, hospital, enterprise, etc.), an access point (e.g., a content access point) or a cloud resource (e.g., web server). In another non-limiting embodiment, shown in FIG. IB, the server may be implemented as one of the user devices 100 itself, i.e., any one of the user devices 100 (in this case, user device D3) may have dual functionality. In either case, it is envisaged that the server 110 may include, inter alia, a processor, a memory and network communication hardware. The memory stores machine- readable instructions for execution by the processor. The machine-readable instructions may be the result of a software build, whereby human-readable instructions specifying a desired behavior of the processor (i.e., a computer program or source code) are converted (compiled) into machine-readable instructions (i.e., object code or executable code). One of the functions of the server 110 may be to support the community of users by providing message routing services, that is to say, controlled relaying of messages between different users of the community or between different user devices 100 associated with the same user. To this end, the server 110 may execute a process (referred to herein as a "message routing process" 170) for managing communication between user devices 100 based on control logic subject to data stored in one or more databases, including the aforementioned databases illustrated in FIG. 1A. Examples of factors that may influence the behavior of the server 110 when deciding whether or how to route a message in the context of a certain operation may include the nature of the operation, the groups that the originating and destination users are members of, and the roles of the users in those groups. Other factors may include the location of the users, the time of day, user device characteristics, whether certain users are "in session", etc. It should also be appreciated that relaying does not necessarily mean preserving the absolute integrity of the messages being routed, but rather could include adding, removing or modifying information in such messages.

WORKSPACE APP

With reference to FIGS. 17 and 18, the operating system of a representative one of the user devices 100 supports the execution of application program software (or "apps"). In accordance with a non-limiting embodiment, one example of such an app is a "workspace app" 180. The workspace app 180 includes a set of machine-readable instructions 182 stored in the memory 181 of the user device 100 and capable of being executed in response to a launching event that is either automatic or initiated by the user, depending on the embodiment. In various non-limiting embodiments, the workspace app 180 defined by instructions 182 may be launched by the user through physical manipulation of the user device 100 and/or by making hand/finger gestures and/or through voice commands. For example, the workspace app 180 may be launched by a user of the user device 100 through an icon, window, key or other such conduit. In other embodiments, the workspace app may be launched automatically by the user device 100. The machine-readable instructions corresponding to the workspace app 182 are the result of an installation process that first involves downloading (e.g., over the Internet) machine-readable workspace app installation instructions 183 from an application repository 184 to the user device 100. The application repository 184 may be a commercial application repository (accessible to the public) or a private application repository (with access being restricted to, e.g., employees or students or other users having a trust relationship with an administrator of the repository). In some cases, the application repository 184 may be a website. The application repository 184 may be accessible over the Internet or offline, e.g., over a local area network without the need for Internet access. The application repository 184 may even be a USB key, a CD-ROM, external hard drive or other physical mass storage device.

The machine-readable workspace app installation instructions 183 are a function of the native operating system 200 of the given user device 100 (iOS, Android, Windows, Mac OS X, Chrome OS, Blackberry, etc.). After download of the machine-readable workspace app installation instructions 183 is complete, they may be executed (either automatically or upon receipt of user input/confirmation). This triggers an installation process, which results in the creation and storage of the aforementioned set of machine-readable instructions corresponding to the workspace app 182. In one non-limiting embodiment, the machine-readable instructions corresponding to the workspace app 182 include platform-specific code 185 as well as platform- independent code 186. Platform-specific code 185 may refer to instructions that are designed to run on a specific operating system 200, whereas platform-independent code 186 refers to instructions that are interpretable by a plurality of disparate operating systems 200.

Execution of the workspace app 180 by the user device 100 causes the user device 100 to interact with the user and the server 110 and perform a variety of functions. With reference to FIG. 18, two non-limiting examples of such functions include a user- facing function 190 and a message processing function 192.

USER-FACING FUNCTION Execution of the user-facing function 190 of the workspace app 180 may include, at times, the user device 100 presenting the user with an interactive graphical environment 400 (which may be referred to as a "workspace UI"). The interactive graphical environment 400 can be characterized as having a certain "look and feel", including a visual aspect of which a non- limiting example is conceptually shown in FIG. 4. It should be mentioned that although the machine-readable workspace app installation instructions 183 are different for different operating system platforms, the look and feel of the interactive graphical environment 400 presented by the user device 100 as a result of executing the user-facing function 190 of the workspace app 180 can be made the same or very similar across multiple platforms. With the same look and feel on each user device 100 (even if the user devices 100 run differing operating systems), a consistent user experience can be delivered. It is envisaged that before allowing the user to fully access the interactive graphical environment 400, a sign-in procedure may be performed. That is to say, part of executing of the user-facing function 190 of the workspace app 180 involves the user device 100 contacting the server 110. This may trigger the server 110 to execute an authentication / authorization process. In one non- limiting embodiment of the authentication / authorization process, the server 110 requests credentials (e.g., username and password) from the user, who then inputs them into the user device 100 through the workspace UI 400. As execution of the user-facing function 190 of the workspace app 180 continues, the device 100 transmits the inputted credentials to the server 110, and the server 110, in accordance with the authentication / authorization process, validates the credentials (e.g., using Active Directory or other authentication tool). If the user is successfully authenticated / authorized, then the user device 100, as a continued result of executing the user- facing function 190 of the workspace app 180, permits the user to interact with the interactive graphical environment 400, otherwise access is denied.

With the user having signed in to the server 110 via the user device 100, the server 110 may create an entry in the user-device association database 130 to associate the user with the user device 100 that was used for sign-in purposes. Also, based on the group-user association database 140, the server 110 already knows to which groups the newly signed in user belongs to and also knows the role ascribed to that user when in a given group. As previously mentioned, the user may have different roles in different groups.

When a user initially attempts to sign in, his/her proffered credentials will be checked against the server 110 and (if successful) the user may be provided an authentication token so that he/she does not need to authenticate again with the server 110 unless the token has expired. The user can thus be assumed to remain signed in if the associated authentication token has not expired.

In accordance with a non-limiting embodiment, and with continued reference to FIG. 4, the visual aspect of the interactive graphical environment 400 may be divided into several regions, such as a "work area" 410 and a "reserved area" 420. The work area 410 may include selectable graphical links (e.g., icons or other graphical elements) 402 representing one or more "community apps" 210 (see also FIG. 18) and/or "system apps" . In the illustrated embodiments, icons Al through A4 represent community apps 210, while icons SI through S3 represent system apps . When one of the links to a system app 220 or to a community app 210 is selected by the user (e.g., by tapping, swiping, using a mouse, etc.), the user device 100 executes the selected system app 220 or community app 210 "within" the workspace app 180.

Both system apps and community apps 210 are executed under control of the workspace app 180. System apps may be viewed as subsets of machine-readable instructions among the machine-readable instructions corresponding to the workspace app 180. As for community apps 210, these apps are somewhat different. With reference to FIGS. 17 and 18, there is conceptually shown a set of machine-readable instructions 260 corresponding to a community app. The platform-independent code 186 of the workspace app, when executed, implements a platform- independent software interface for the workspace app 180 vis-a-vis the community app (which is stored in memory 181, elsewhere than the workspace app 180). When this occurs, the community app is said to be integrated with the workspace app 180. Such a platform- independent software interface is not needed for the system apps 220, as they are already part of the workspace app 180.

The community app 210 utilizes application resources. In this case and as shown in FIG. 17, the application resources include context information 212 and zero or more attachment files 214. In a non-limiting embodiment, the context information 212 for the community app 210 may include textual or other information that is specific to the current instantiation of the community app 210. The context information 212 used by the community app 210 may be stored in memory 181 in a context file, together with any attachment files 214 that may be used by the community app 210.

Execution of a selected system app or community app 210 may generate activity within the work area 410, which is used for interaction with the user during execution of the selected app. For its part, the reserved area 420 may include selectable graphical links (e.g., icons or other graphical elements) representing one or more "default features". In a non-limiting embodiment, the reserved area 420 may have the form of a task bar anchored to a part of the screen. The task bar may remain visible and accessible throughout execution of a selected system app 220 or community app 210 by the user device 100. See, for example, FIG. 5, where a web browser community app operates in a screen space in which a horizontal lower band 426 has been reserved for default features. However, in other embodiments, access to the default features may be gained by pressing a button, making a specialized gesture or uttering a voice command, so that none of the screen real estate need be dedicated to the default features, and the work area 410 effectively becomes the entire screen and there is no reserved area 420 as such. Default features can thus be invoked during execution of a particular system app or community app 210. That is to say, a link to a default feature can be selected while there is activity in the work area 410. A non-limiting example of a default feature is a "home screen" feature, which may be used for adjusting settings and parameters of the interactive graphical environment 400. Other examples of default features may include a "share" feature and an "access to running apps" feature. It is envisaged that there may be user-dependent variability as to which system apps and default features are accessible from the workspace UI 400.

The system apps and default features are integrated into the workspace app 180 by default, meaning that they are accessible form the workspace UI 400 when the workspace app 180 is originally launched. For their part, community apps 210 are integrated into the workspace app 180 after the workspace app 180 has been installed and launched for the first time. In some embodiments, integration of a community app 210 into the workspace app 180 can be "pushed" by the server 110 or by another user (such as an administrator). This could be done in the case of certain community apps 210 marked as "required". In other embodiments, integration of a community app 210 into the workspace can be triggered by receipt of a message from the server 110, such message potentially having been triggered by actions of another user (this embodiment will be discussed in greater detail later on). In still other embodiments, and as will now be described, integration of a previously unintegrated community app 210 into the workspace app 180 can be initiated by the user through accessing either one of the default features (e.g., in the task bar) and/or one of the system apps (e.g., icons SI through S3).

Specifically and with continued reference to FIG. 17, the user first selects one of the default features (e.g., in the task bar) and/or one of the system apps (e.g., icons SI through S3) in order to gain access to a "community library" 250. The community library 250 can be a collection of "community apps" 210 and "community content", which may be stored or otherwise accessed by the server 110. A community app 210 may refer to a set of machine-readable instructions 260 for execution by a processor of a user device 100, while community content may refer to a machine- readable data file. When the user device 100, while executing the user- facing function 190 of the workspace app 180, detects that the user has invoked the "community library" 250 feature, the user device 100 may establish a connection to the server 110 and trigger execution of a "search community library" process by the server 110. In accordance with the search community library process, the server 110 may provide the user of the user device 100 with an opportunity to search within the community library 250 and select from among a set of community apps 210 and community content. There may be a restriction on which community apps 210 and which community content is available to be searched by and/or downloaded to individual users. To this end, in some embodiments, the server 110 may consult the permissions database 160. Specifically, and with reference to FIG. 8, the permissions database 160 may indicate, for each community app 210, which groups and roles it is available to. That is to say, a given community app 210 may be made available to a limited number of groups and, moreover, it might not be available to all members of a group, and instead may be made available only to those users to which a particular role has been ascribed within that group. In the example permissions database of FIG. 8, community app Al is available to students in groups Gl and G2 (which, according to the group- user association database 140 in FIG. 2B, includes users Ul, U2, U4, U5, U7, U8, U9, U10, U13, U14, U20, ...). Similarly, community app A2 is available to teachers and students in group G3, while community app A3 is available to all users in groups Gl, G2 and G3. Additional conditions as to the availability of community apps 210 to individual users or groups of users may be based on contextual factors such as time and location.

Thus, with the user having logged in to the server 110, information about the group(s) to which the user belongs, as well as the role(s) of the user within that group (or those groups), are obtained from the group-user association database 140. Then, the server 110 consults the permissions database 160 in order to determine which community apps 210 (and community content) the user should be allowed to search for, which will be accessible depending on the group that the user belongs to and the user's role within that group. This set of available commumty apps 210 (and community content) is provided to the user via the workspace UI 400. Once a selection of a particular community app 210 has been made by the user, the server 110 sends a set of machine-readable instructions 260 corresponding to the selected community app to the user device 100. Upon receipt of these instructions 260, the user device 100, as a result of continued execution of the user- facing function 190 of the workspace app 180, integrates this set of machine-readable instructions 260 into the workspace app 180. Integration is done in such a way as to allow the selected community app 210 to be executed within the workspace app 180. In one non-limiting example, the workspace app 180 may implement a platform-independent software interface to the community app 210. This may allow the workspace app 180 to control execution of the community app 210. Also as a result of continued execution of the user- facing function 190 of the workspace app 180, the user device 100 may create an activatable / selectable graphical link corresponding to the selected community app 210 and may add this link to the work area 410 of the interactive graphical environment 400. In FIG. 4, this is shown as links Al through A4. This link allows the user to launch the community app 210 from within the interactive graphical environment 400. It is noted that once the community app 210 has been integrated with the workspace app 180, a communication connection between the user device 100 and the server 110 is not required in order to allow the community app 210 to be launched from within the workspace UI 400. Persons skilled in the art will appreciate that there is a significant difference between the community app 210 and a conventional mobile app due to the way in which the workspace app 180 is executed. Specifically, in the present case, a set of machine-readable instructions corresponding to the selected "community app" 210 is transferred to the user device 100 and can be securely stored (e.g., in encrypted form) in memory 181 and in the file system. Then, the community app 210 is controllably accessed by the user device 100 without ceasing execution of the workspace app 180. As such, the workspace app 180 can be envisaged as middleware between the community app 210 and the native operating system 200 of the user device 100 and offers access to services specific to the workspace (e.g., sharing, communication, etc.). A "community app" may also be referred to as a "utility app", since different community apps serve a variety of utilities, purposes or functions. Examples of community apps (or utility apps) 210 of general application may include Word Processor, Calculator, Browser, a Notepad, Messaging, Calendar, Photo Gallery. Examples of community apps 210 that are specific to an education community may include Lesson Planning, Classroom Management, Pop Quiz, Exam, etc. Other types of communities (e.g., hospital, enterprise, convention, stadium, etc.) may have their own specific community apps (or utility apps) 210. Each community app 210 executes "within" the workspace app 180, as will be understood to a person of skill in the art.

Multiple community apps 210 may be integrated with the workspace app 180 in this way, and as shown in FIG. 4 the work area 410 of the interactive graphical environment 400 can fill up with links to various community apps 210 that have been chosen by the user or pushed by the server 110 or by another user. By executing the workspace app 180, the user device 100 manages the various community apps 210 (which run within the workspace app 180) as they are launched, used, closed, and so on. Although the above discussion has focused on community apps 210, it is also envisaged that the community library 250 may also contain community content. Such content may include files (e.g., PDF files, images, videos, etc.) that are downloadable from the server 110 to a user's individual user device 100. The collection of community content available to a particular user may also be restricted based on the criteria already outlined above (namely, group membership and role within the group, to name a few non-limiting examples). Once downloaded to the user device 100, community content could appear within the workspace UI 400 as a link (similarly to the case of a community app 210) or the community content may be stored in a file system accessible by the workspace app 180 (the workspace file system) and accessible through an associated app (which could be a system app 220 or a community app 210). For example, a downloaded PDF file may be represented as a link on the workspace UI 400, or the downloaded PDF file can be stored in the PDF workspace file system without a direct link from the workspace UI 400, in which case the user may open a PDF app from the workspace UI 400 to see a list of PDF files in the workspace file system including the downloaded PDF file, from which a PDF file may be selected to be opened.

A non-limiting example of operation of the user device 100 when executing a community app 210 within the workspace app 180 is now described with reference to FIGS. 6 and 7. The community app 210 is in this case a lesson planner that may be activated from within the interactive graphical environment 400, e.g., by selecting a lesson planner icon (not shown, but conceptually could be one of the icons Al through A4) via a touch screen. Upon activation of the lesson planner community app 210 from within the interactive graphical environment 400, and as shown in FIG. 6, the user device 100 causes the work area 410 to become populated with graphical elements relevant to lesson planning, such as individual lesson folders 510, a word processing box 520 for inserting text, an "add attachments" button 530 for adding attachment files to a list and a "remove" button 540 for removing attachment files from the list. In response to selecting the add attachments button 530, the user device 100 responds by presenting a selection of possible attachment files to add, including quiz files, notes files, browser files, image files, etc. Each of these may be presented in the form of a graphically selectable option. In response to having added one or more attachment files, and as shown in FIG. 7, the user device 100 causes a list of attachment files 535 to be presented in the work area 410.

In accordance with non-limiting embodiments, the same community apps 210 are available for different user devices 100 irrespective of their native operating system or form factor. In fact, considering the functionality of a given community app 210, it may be possible for a single such community app 210 to be utilizable across all platforms. That is to say, the same community app 210 with the same set of machine-readable instructions is sent to each user device 100. This can be implemented in various ways. In one non-limiting embodiment, the workspace app 180 consists of platform-specific code 185 and well as platform-independent code 186, and the community apps 210 are written once in such a way as to interface with the platform- independent code 186 of the workspace app 180 (see FIG. 17). This allows the community apps 210 to execute within the workspace app 180 in a platform-independent way. In another non- limiting embodiment, a single community app 210 includes subsets of platform-specific code 185 for multiple platforms, so that the user device 100, being self-aware of the operating system 200 it uses, can access the appropriate subset of the machine-readable instructions that is specifically designed for that device's operating system 200.

As previously mentioned, one of the default features that can be invoked from within the interactive graphical environment 400 may be the "share" feature. The share feature is most usefully invoked while there is already a particular community app 210 in the process of being executed by the user device 100. The share feature allows a user of an originating user device 100 to share the "application resources" 211 (context information 212 and attachment files 214) relating to the particular community app 210 with destination groups, destination users or even individual destination user devices 100 of his/her choice. In some embodiments, the share feature allows destination groups, users or user devices 100 to follow or replicate the originating user device's activities within the particular community app 210 in real time or near-real time, irrespective of the operating system 200 being used. In other embodiments, sharing may occur asynchronously based on the availability of a connection to the server 110, bandwidth or other considerations.

Operation of a given originating user device 310 when executing the share feature is now described with reference to FIGS. 9 through 11 and also FIG. 15. It is assumed that a particular community app 210 is in the process of being executed by the originating user device 310 when the share feature is invoked. It should be appreciated that, depending on the embodiment, the share feature may be invoked by selecting a graphical element from a task bar, or by accessing a set of functions from within the particular community app 210 itself. In response to detecting that the user of the originating user device 100 has invoked the share feature (step 1510), the workspace app 180 presents a sharing GUI 370 on the screen through which the user is given the opportunity to select the user(s) and/or group(s) and/or user device(s) 100 with which sharing of resources is desired. A first tab 380 may allow the user to select from among sets of users (see FIG. 9) and a second tab 381 may allow the user to select from among a set of groups (see FIG. 10). A third tab 383 (see FIG. 11) brings the user to a list of his/her own user devices 100 for the purpose of sharing among them and/or for synchronization. In an alternative embodiment, a user can be provided with the opportunity to share application resources 211 with a specific user device 100 other than one of his/her own.

The available choice of destination users, groups or devices may depend on a variety of factors, notably the information in the permissions database 160 and in the rules database 150. For example, based on the roles of the originating user and a prospective destination user (as specified by the group-user association database 140), and based on the transmission rules (outlined in the rules database 150), then by consulting the permissions database 160 on the basis of the particular community app 210, it is possible to determine whether the originating user should be allowed to share application resources 211 with the prospective destination user. For instance, consider that the originating user has the role of a teacher and that the prospective destination user has the role of a student in the same group as the teacher. Then, consulting the rules database 150 will determine whether, for that community app 210, the teacher may or may not share the application resources 211 with the prospective destination user.

Returning now to the description of the share feature, after having obtained an indication of the destination user(s), destination group(s) and/or destination user device(s) (step 1520), the originating user device provides the originating user with an opportunity to confirm the originating user's intent to share the application resources 211 relating to the particular community app 210 with those destinations (step 1530). In a non-limiting example, this can be done by providing a "share" button 375 (or other activator) in the sharing GUI 370 (see FIGS. 9- 11) that can be selected / activated to indicate user confirmation. In response to receipt of user confirmation (step 1540), the originating user device 310 optionally displays a busy screen (step 1550, see also FIG. 12) and during this time (step 1560) obtains application resources 211 relating to the particular community app 210 which are to be shared. In a non-limiting embodiment, the "application resources" 211 relating to the particular community app 210 may refer to "context information" 212 for the particular community app 210 and "attachment files" 214 for the particular community app 210. "Context information" 212 for the particular community app 210 may refer to information that is specific to the current instantiation of the particular community app 210, i.e., what the particular community app 210 was doing at the time of invoking the share feature. This information may be stored in a context file for the particular community app 210.

For example, in the case of a browser wherein a user browses a web page or URL, the context information 212 for the browser may include the URL or the web page address. In another example, in the case of a PDF viewer wherein a user is viewing a PDF document, the context information 212 for the PDF viewer may include the page of the PDF document currently being displayed on-screen. In another example, in the case of a notes application that allows a user to work on a particular note file, the context information 212 for the notes application may include the name, path and/or file identifier (file ID) of the particular note file. The path may refer to the absolute or relative location of the note file within the workspace file system.

Additionally, in a non-limiting embodiment, the context information 212 for the particular community app 210 may further refer to one or more of:

- the identity of the particular community app 210 itself;

- the identity of the originating user device 310;

the identity of the originating user;

the identity of the user/device/group with which the user wants to share resources (i.e., the destination user/device/group);

the current time;

the current geographic location of the originating user device,

calendar/event;

- etc. (generally speaking: who, where and what)

The context information 212 for the particular community app 210 may be obtained by the workspace app 180 at least in part using a software interface between the workspace app 180 and the particular community app 210, through which the workspace app 180 may issue queries or otherwise access information from and pertaining to the particular community app 210. In a non- limiting embodiment, the workspace app 180 may obtain the context information 212 for the particular community app 210 by accessing the context file directly at a predetermined file location for the particular community app 210. By way of non-limiting example, the filename containing context information 212 for a particular community app 210 called "lesson" may be "lesson.txt" and the path for this file may be "workspace/community/lesson.txt". Continuing with the description of the share process, at step 1570, the originating user device packages the context information 212 for the particular community app 210 into one or more device-originated "SHARE" messages 460, which it sends to the server 110. With reference to FIGS. 14 and 19, a device-originated SHARE message 460 may include the aforementioned context information 212 for the particular community app 210. This may include not only information about the originating user, the destination group/use/device, the user device 100, the identity of the particular community app 210, etc., but also information regarding what data the particular community app 210 was handling when the share feature was invoked (such as URLs and attachment filenames/paths).

In addition, where the context information 212 refers to attachment files 214, the originating user device 320 packages the attachment files 214 into one or more device-originated "ATTACH" messages 470 (step 1580). In order for the attachment files 214 to get transferred from the originating user device 310 to a destination user device 320, they have to be temporarily stored in the server 110. Thus, the device-originated ATTACH messages 470 are sent to the server 110. With reference again to FIGS. 14 and 19, the device-originated ATTACH message 470 includes the file ID of the attachment files 214 as well as the attachment files 214 themselves.

Some operational aspects of the user-facing function 190 of the workspace app 180 have thus been described. It is recalled that the workspace app 180 executes other functions, including a message processing function 192. This function will be described after providing a discussion of the message routing process executed by the server 110 further to receipt of the device- originated SHARE and ATTACH messages 470 generated by the user-facing function 190 of the workspace app 180.

MESSAGE ROUTING PROCESS OF THE SERVER

Upon receipt at the server 110, the device-originated SHARE message 460 is handled by the message routing process 170. Specifically, the server 110 processes the device-originated SHARE message 460 to extract the context information contained therein. As such, the server 110 determines the identity of the user(s) for which the SHARE message 460 is destined (i.e., the destination user(s)). In the case of a SHARE message 460 destined for a group of users (i.e., multiple destination users), the server 110 determines the identity of the various users in the group. This may be determined by consulting the group-user association database 140 (see FIG. 2B). Also, as part of the message routing process, in case it was not already done by the originating user device 310, the server 110 checks the permissions database 160 to ensure that the originating user has the permission to send application resources 211 to the destination user, based on their respective roles and possibly other factors. Assuming that there is nothing to block the transmission of the device-originated SHARE message 460, the server 110 places the device- originated SHARE message 460 in a "message delivery queue" 270 for each destination user.

That is to say, to allow proper message delivery, and as shown in FIG. 3, the server 10 may implement message delivery queues 270 for individual users. Thus, for example, message delivery queues Q_U1, Q_U2, Q_U3, Q U4 may be provided for each of users Ul through U4, respectively. Messages destined for, say, user Ul are placed in the message delivery queue Q UI for user Ul, and so on. In a non-limiting embodiment, the message delivery queues 270 can be implemented in volatile memory 272 (e.g., RAM) for performance reasons and also replicated in non-volatile memory 274 (e.g., disk) for persistence reasons. As will be described later on, individual messages destined placed in the message delivery queue 270 for a particular user may be collected by the one or more user devices 100 associated with that user (such association being defined in the user-device association database 130). In a non-limiting embodiment, messages may be removed from the message delivery queues 270 after a certain time to live (TTL) has expired, or after it has been read by all destination users/devices. Also with reference to FIG. 3, the server memory 276 (e.g., disk or other non-volatile memory) may implement a file store 280 for attachment files 214, in this case the files in the file store 280 are denoted by their file IDs (Fl, F2, F3, etc.). Upon receipt of a device-originated ATTACH message 470 containing an attachment file 214 and a file ID, the server 110 stores the attachment file 214 in the file store 280, such that the attachment file 214 may be retrieved from the file store 280 at a later time by specifying the file ID. It is to be noted that if a particular attachment file 214 (e.g., a PDF, image, video, etc.) is to be shared with multiple destination users or destination user devices 320, it only needs to be stored once in the file store 280, and a reference to the same file (i.e., using the same file ID) is sent to all destination users or destination user devices 320. Each destination user device 320 thereafter downloads the same attachment file 214. File storage on the server 110 can be optimized using traditional methods, such as a cache. If the attachment file 214 is removed from the server 110 (e.g., after a certain amount of time to live (TTL)), it is removed for all destination users and user devices 100.

MESSAGE PROCESSING FUNCTION OF WORKSPACE APP Re rning to the description of the functions that may be performed by a user device 100 when executing the workspace app 180, there is now provided a description of the message processing function 192. It is this function that allows a destination user device 320 to obtain the application resources 211 (context information 212 and attachment file(s) 214) shared by the originating user device 310. The message processing function 192 may be executed independently of and/or concurrently with the aforementioned user-facing function 190. In other words, it is possible for a user device 100 to be both an originating entity (a sender of application resources 211 to be shared) and a destination entity (a recipient of application resources 211 being shared by others). It is also noted that although the originating user device 310 and the destination user device 320 are different, the destination user may in some cases be the same as the originating user, most notably in the case where a user wishes to synchronise the application resources 211 being used on his/her multiple user devices 100.

A non-limiting example of execution of the message processing function 192 of the workspace app 180 by a destination user device 310 will now be described with reference to FIGS. 16A and 19. It is assumed that the workspace app 180 has been launched and that a destination user 320 has signed in to the server 110 via the workspace UI 400 or otherwise.

The message processing function 192 may involve the destination user device 320 periodically checking with the server 110 for messages that may be destined for it. To this end, the destination user device 320 may send a polling request 330 (step 1610) and await a response message. The polling request 330 may be sent at any time or at any suitable interval, neither of which is particularly limited. In this way, the workspace app 180 may be continuously checking for messages (such as the SHARE message 460).

At the server 110, the received polling request 330 is handled by a process which determines, based on knowledge of the destination user (who has logged into the server 110 via the workspace UI 400 or otherwise), whether there is a message in the message delivery queue 270 (a queued message) for that destination user. If yes, then the server 110 sends the queued message to the destination user device 320. The queued message sent by the server 110 is thus received at the destination user device 320 as a response to the polling request 330 issued at step 1610, allowing the destination user device 320 to read the message. Once the queued message has been sent and/or delivered, it can be removed from the message delivery queue 270, Alternatively, the queued message is not removed but marked "processed" (or "read") by the destination user device 320; other destination user devices 320 associated with the same destination user will continue to see the queued message as unread.

In another embodiment, the server sends notifications 340 to the destination user device 320 to tell it that there is a queued message for it to read. When the destination user device 320 is ready, the destination user device 320 responds to the notification (step 1610) by checking in with the server 110 and reading the queued message, i.e., the message that is stored in the message delivery queue 270 for the destination user. When there is more than one queued message in the queue for the destination user, the destination user device 320 may obtain the most recent message or the oldest message, depending on the embodiment.

In any event, and as referred to specifically in step 1620, the message read by the destination user device 320 may be a SHARE message 460, the transmission and structure of which has been described above. Assuming that the message read by the destination user device 320 is indeed a SHARE message 460 sent by an originating user device 310 as described above, it will be recalled that a SHARE message 460 specifies a variety of context information 212 for a particular community app 210, including one or more of: various URLs, bookmarks, addresses and/or web pages in use by the particular community app 210 at the time of invoking the share feature;

names, paths and/or file IDs of files in use by the particular community app 210 at the time of invoking the share feature;

the identity of the particular community app 210;

- the identity of the originating user device 310;

- the identity of the originating user;

the current time;

- the current geographic location of the originating user device.

Having recognized the read message as being a SHARE message 460, the destination user device

320 extracts the aforementioned context information 212 (step 1630). The destination user device 320 then checks whether the particular community app 210 (whose identity has been learned from the received context information) is already integrated with (i.e., readied for execution within) the workspace app 180 (step 1640). At least two possibilities may now exist. Case 1 : The particular community app 210 is integrated with the workspace app 180. Proceed to step 1670.

Case 2: The particular community app 210 is not integrated with the workspace app 180 and the destination user device 320 has connectivity with the server 110.

The destination user device 320 proceeds to request from the server 110 a set of machine- readable instructions corresponding to the particular community app 210 (step 1650). Upon receipt of these instructions, the destination user device 320, which continues to execute the message processing function 192 of the workspace app 180, integrates this set of machine-readable instructions into the workspace app 180 (step 1660). Now proceed to step 1670.

At step 1670, still during execution of the message processing function 192 of the workspace app 180, the destination user device 320 places the context file at the appropriate location in its file system. Then, at step 1680, the message processing function 192 of the workspace app 180 launches the particular community app 210 from within the workspace app 180. In this way, the particular community app 210 will execute within the workspace app 180 and, by virtue of the actions undertaken at step 1670, the particular community app 210 will have the appropriate context when it is launched at step 1680. Thus, the particular community app 210, now executing on the destination user device 320, utilizes the same context information 212 as the particular community app 210 that is/was executing on the originating user device 310.

It will be noted that although the context information 212 includes the file IDs of attachment files 214, the attachment files 214 themselves remain on the server 110 and have yet to be transmitted to the destination user device 320. In order to retrieve the attachment files 214 (step 1690), the destination user device 320 may request them. Specifically, as part of the continued execution of the message processing function 192 of the workspace app 180, the destination user device 320 sends a request 350 to the server 110 identifying a particular attachment file 214 according to its file ID (specified by context information 212 originated by a given originating user device 310). The server 110 responds by locating the attachment file 214 in the file store 280, based on its file ID. The server 110 then proceeds to send the attachment file 214 to the destination user device 320. Upon receipt of the attachment file 214, the destination user device 320 stores it in its file system at a location (step 1692). In a non-limiting embodiment, the received attachment file 214 is given the same filename/path as was used within the file system of the originating user device 310. This may allow the particular community app 210 to seamlessly access the same attachment files 214 at the same locations as on the originating user device 310.

It should be noted that retrieval of the attachment files 214 (step 1690) can be carried out before, during or after the above described launching of the particular community app 210 (step 1680). For example, as shown in FIG. 16B, the attachment files 214 may be retrieved as soon as the content information 212 from the SHARE message 460 is extracted (at step 1630), or the attachment files 214 may be retrieved while the community app 210 is being launched (at step 1680), or at other points in time. Thus, it has been described how the message processing function 192, which is part of the workspace app 180, causes the community app 210 to run using the application resources 211 (context information 212 and zero or more attachment files 214) shared by the originating user device 310. It is noted that in some embodiments, the community app 210 executing on the destination user device 320 may be configured so as to retrieve / download the attachment files 214 from the server 110 at the time the community app 210 is notified of the SHARE message 460. In another non-limiting embodiment, the community app 210 executing on the destination user device 320 may wait until the user asks for the attachment before downloading / retrieval from the server 110.

As has been described, the user of the originating user device 310 will be able to share application resources 211 with other users and/or user devices 100, allowing destination users to partake in the originating user's experiences within the context of a particular community app 210. When all user devices 100 have a connection to the server 110, sharing may occur in real time or near-real time. Another way of looking at this is that recipients of application resources 211 that were shared by a sender can follow the senders' actions within the interactive graphical environment 400. Moreover, if the particular community app 210 had not previously been integrated with the destination user's workspace app 180, the community app 210 will be caused to be automatically integrated with the workspace app 180 (auto-install) and then it will be launched with the application resources 211 that were shared by the originating user. This assumes that the user has permission to download and integrate the community app 210 with their workspace UI 400. Variants:

In an alternative embodiment, rather than waiting in a message delivery queue 270 to be polled, messages can be pushed by the message routing process to the destination user device 320 so that they may be more immediately processed by the message processing function 192 of the respective workspace 180. Alternatively, a notification message 340 could be sent to the destination user device 320 to advise the destination user device 320 that there is a SHARE message 460 waiting for it in the message delivery queue 270.

In a variant of the message processing function 192, rather than autonomously launch the particular community app 210 from within the workspace app 180, as suggested by step 1680, certain messages retrieved from the server 110 may be provided to an "activity feed" of the destination user device 320. Specifically, with reference to Fig. 20, there is shown a flowchart that is a variant of Fig. 16A, and illustrates a non-limiting example of execution of the message processing function 192 of the workspace app 180 by a destination user device 320.

Steps 1610-1670 illustrated in Fig. 20 are identical to those from Fig. 16A. Thus, at the completion of step 1670, all the information that is necessary for launching of the particular community app 210 with the appropriate context is available and downloaded to the destination user device 320. However, instead of launching the community app 210, the message processing function 192 executes step 2010, whereby a message is placed into an "activity feed" for the destination user device 320. An activity feed may be viewed as a queued set of data sets associated with received messages that have not been fully processed and including data needed to cause the remaining processing of the message to be executed. For example, in the case of a received SHARE message 460 being "placed into the activity feed", this may involve storing in association with this SHARE message 460 a data set including the aforementioned information necessary for launching of the particular community app 210 with the appropriate context. Although retrieval and storage of the attachment are shown as steps subsequent to step 2010, it should be appreciated that they may be executed before or during execution of step 2010. Turning now to the user- facing function 190 of the workspace app 180, with reference to Fig. 21, there is shown a variant of FIG. 4, illustrating a non-limiting visual aspect of the interactive graphical environment 400 which includes an activity feed section 430. From the point of view of the destination user device 320, the activity feed section 430 can be viewed as a set of activity alerts 440 (e.g., graphical elements) representing data sets in the activity feed and linking thereto when activated. It is recalled that the data sets in the activity feed may represent messages (such as SHARE messages 460) that have been received by the message processing function 192 of the workspace app 180 but that have not yet been processed to completion by the destination user device 320. By way of non-limiting example, Fig. 21 shows an activity alert 440 assocated with a SHARE message 460 from user U4.

Individual activity alerts 440 that appear in the interactive graphical environment 400 of a given user's user device 100 may be selected and activated by the given user, e.g,. by clicking or touching or other form of selection. In response to a particular activity alert 440 being activated by a user, the user-facing function 190 of the workspace app 180 executes step 1680 that was described with reference to Fig. 16A as being executed by the message processing function 192 of the workspace app 180. That is to say, the workspace app 180 launches the particular community app 210 from within the workspace app 180, with the appropriate context. The particular community app 210 will now execute on the destination user device 320, and utilizes the same context information 212 as the particular community app 210 that is/was executing on the originating user device 310.

It should also be appreciated that in some embodiments, the message processing function 192 may autonomously launch the particular community app 210 from within the workspace app 180 when the corresponding SHARE message 460 is received within a certain context (e.g., from a certain user, or from a user having a certain role, or during a certain time period, or within a certain location, etc.), whereas SHARE messages 460 received within a different context may simply be provided to the "activity feed" of the destination user device 320 for later activation by the user.

It should further be appreciated that the mere fact that users belong to a certain group (as defined by the group-user association database 140) does not mean that all of these users are in active communication with one another. To define and keep track of sub-groups of users that are in active communication with one another, the user-facing function 190 may allow the creation of "sessions". A session can be viewed as a dynamically formed sub-group of users within a somewhat more static group of users, where the users in such a session are expected to be engaged in active communication with one another over a certain limited period of time. One of the users, the session creator, may designate himself/herself as a "leader" of the session and the others as "followers". This designation may last a certain amount of time, e.g., over the course of a lecture.

For example, consider the case where the group in question is group Gl in Fig. 2B, namely "Ms. Jones' English class, Tuesdays 3rd period". While users Ul, U2, U4, U8, U9, U13, U15, U20, ... are all members of the group (having the role of "student"), it is possible that user U100 (Ms. Jones herself) has the authority to be a session "leader" and may desire to create a session involving only users Ul, U2, U4, U8 and U9 (having the role of "student"), and only lasting during her class. There could be numerous reasons for the session to involve fewer than all members in a group. In specific non-limiting examples, it may be because the students in this sub-group are involved in a joint project, or missed the previous class, etc.

In order to help a particular user create a session, the workspace app 180 may present an actionable icon in the interactive graphical environment 400. This icon, when actioned (e.g., touched, clicked or otherwise selected) invokes a session creation process. The session creation process may be a default feature of the workspace app 180. The session creation process may then execute a set of steps that is now described with reference to Fig. 22. Firstly, at step 2210, the session creation process verifies whether the particular user has the authority to create a session in the first place (i.e., is an eligible session leader). This could be done by consulting the group-user association database 140 in order to determine what is the role of the particular user in each of the one or more groups to which the particular user belongs. Then, the session creation process cross-checks the role(s) of the particular user with a list of roles that are pre-definedly selected as being capable of creating a session. This information could be stored in a table. For example, in an educational environment, users having the role of "teacher" may be permitted to create sessions (i.e., they are eligible session leaders) whereas users have the role of "student" may not. If the particular user is permitted to create a session for at least one group, and the number of groups is greater than one, the session creation process may, at step 2220, present the particular user with a list (or other textual or graphical display) of these two or more groups and provide the particular user with an opportunity to select one of these groups. With the selection of a group having been made by the particular user at step 2220 (or in the default case where there is only one such group), the selection process may then, at step 2230, present the user with a list (or other textual or graphical display) of users that the particular user is allowed to involve in a session. For example, this could include the users in the selected group who are said to be "available", i.e., not already involved in a different session. To obtain this information, a user availability database 600 may be consulted. The user availability database 600 may be stored by the server 110 in memory 181. With reference to Fig. 23, the user availability database 600 may indicate, for each registered user, whether that user is involved in a session and, if so, an identifier of such session (this may be referred to as a "session identifier"). A user that is not involved in any session is said to be "available". A user that is already involved in a session is said to be "busy". Thus, the particular user (now the prospective leader of the about-to-be-created session) may select (via the interactive graphical environment 400) one or more "available" users in the selected group and this selection is received by the session creation process at step 2240. In a non-limiting example case of the particular user having the role of "teacher" and wishing to create a session, the list of available users may include one or more users in the same group and that have the role of "student", depending on whether these users are involved in other sessions or not. In addition, at step 2250, the user may be given the opportunity to specify a duration of the session, or the duration may be selected by default. At step 2260, the session creation process may then provide the particular user with the opportunity to confirm creation of the session. Thereafter, at step 2270, the user availability database 600 is updated to indicate that the particular user and the other, selected users are now in session. Specifically, the server 110 may allocate a new session identifier to the newly created session and may update the user availability database 600 to indicate that each of the users selected at step 2240, as well as the particular user, all of which had been "available" prior to the session's creation, are associated with this new session identifier and are now considered "busy", i.e., no longer "available".

In addition, at step 2280, the parameters of the newly created session may be stored in a session database 620, With reference to Fig. 24, the parameters of a given session that are stored in the session database 620 may include the identity of the "leader" (e.g., teacher, physician, boss, etc.), the identity of the "followers" (e.g., students, patients, employees, etc.), the duration of the session (or an expiry time) and the session identifier, amongst other possible parameters. The session database 620 may be located on the server 110 and/or on a content access point and/or one of the user devices 100. The session database 620 may be continuously monitored by the server 110 to ensure that sessions are deleted when they expire. It should be appreciated that the membership in a session may evolve over time. Thus, the session creation process may continually provide the leader of the session with the opportunity to add more users to, or remove users from, a session. Thus, for example, after a session has started, a leader of a session may be able to add as one of the followers of the session a user who had been busy at the time of session creation but has since become available. Similarly, the leader of a session may be able to drop an individual user from the session, thus causing the availability status of this individual user to change from busy back to available.

Various effects may be caused and/or enabled by the creation of a session. For example, in regards to a received SHARE message 460, immediate action (e.g., launching of the community app 210) may be taken by the workspace app 180, or the received SHARE message 460 may be placed into the activity feed for later processing, depending on a variety of session-related factors. For example, consider the workspace app 180 executing on a particular user's user device 100, and consider that the particular user is involved in a session. The workspace app 180 may be configured to immediately act upon a SHARE message 460 received from the leader of the session, whereas a message received from a follower of the session may be placed into the activity feed. Other factors that may influence how a received SHARE message 460 is dealt with by the workspace app 180 may include the time at which the SHARE message 460 was received, the location of the particular user, etc.

In still other embodiments, the SHARE message 460 may not actually be delivered by the server 110 to the intended recipient. For example, consider that a certain user A has the authority to send SHARE messages to a certain user B, e.g., as defined by the rules in the rules database 150. Nevertheless, delivery of a SHARE message 460 from user A to user B may be withheld by user A's workspace upon determining that the intended recipient (in this case, user B) is considered "busy" and is not involved in the same session as user A. This information can be obtained by user A's workspace from the user availability database 600, so as to determine the identity of the session, if any, that user B is involved in. This is then compared to the session that user A is involved in and, if it is the same session, the message is delivered and if it is not the same session, the message is withheld at the server 110.

In some embodiments, the workspace app 180 executing on the particular user's user device 100 may execute a filtering process to filter the activity feed in order to control which notifications 340 are displayed to the particular user via the interactive graphical environment 400. For example, in the case of a follower of a session, the workspace app 180 may filter the activity feed in such a way as to prevent the display of activity alerts 440 in the activity feed that are from users other than the leader of the session, until the session is terminated.

Another effect that may be caused by the creation of a session is that the leader may "lock" the workspace of the followers while the session is ongoing, e.g., during a lecture. Locking the workspace of a follower prevents the follower from manipulating his or her interactive graphical environment 400, and as a result the follower is forced to pay attention to what the leader is doing, because it is all that will be seen by the follower in his/her interactive graphical environment 400. To enable locking of a session, the session creation process that allowed the creation of a session may recognize that the user is a leader of a session and may further allow the user to lock the session. This may be achieved by providing a graphical element in the interactive graphical environment 400, the selection of which may indicate an instruction from the leader to lock the session. Thus, in response to selection of the graphical element, the session creation process updates the session database to indicate that the session is locked. In other embodiments, instead of locking the entire session, the leader of the session may specifically identify which followers of the session he or she wishes to lock.

Meanwhile, the workspace app 180 of a particular user may verify (e.g., periodically, e.g., by polling) the session database 620 in order to determine whether the particular user is a follower of a session that is locked. If so, then the workspace app 180 "locks" the workspace (or continues to keep it locked). From this point on (until the session expires or is unlocked), the workspace app 180 of the follower is only receptive to messages from the leader and replicates the interactive graphical environment on the leader's device. In an alternative embodiment, the share feature may be provided as a feature of the community app 210 rather than as a feature of the workspace app 180.

In an alternative embodiment, obtaining the resources relating to the community app 210 may be conditional upon receipt of user input.

In an alternative embodiment, a user can install multiple workspace apps 180 on the user device 100 and run multiple different workspaces in parallel, with only one of these being active at any given time. This is a possible way to manage the user's simultaneous membership in multiple groups. It should be appreciated that two or more originating user devices 310 may try to share application resources 211 relating to the same community app 210 with the same user. This could result in the context information 212 for the community app 210 being changed in rapid succession, before the user of the destination user device 320 has had a chance to consider them. As such, in accordance with an alternative embodiment, different sessions of the community app 210 may be opened and placed in the background so that the user may consider them at a later time. For example, in the case where the community app 210 is a browser, different browser tabs can be opened in response to multiple URLs being supplied from different originating users. While the above description and diagrams have provided a description and illustration of several example embodiments, it should be appreciated that variations are possible while remaining within the scope of the invention. For example, certain elements that are expected to be known or common to a person of ordinary skill in the art have not been described, while certain features that have been described may be omitted in some embodiments and included in others. Those skilled in the art will of course appreciate that the invention is only to be limited by the claims attached hereto.

Claims

1. A method for execution by a communication device, comprising:

executing a workspace application;

- executing a utility application within the workspace application;

responsive to a user invoking a share function, obtaining resources for the utility application;

sharing the resources with at least one destination entity. 2. The method defined in claim 1, the workspace application having been launched from a native operating system of the communication device.

3. The method defined in claim 1, wherein the resources for the utility application are obtained via the workspace application.

4. The method defined in claim 1, wherein the share function is a feature of the workspace application.

5. The method defined in claim 1, further comprising providing a user of the communication device with an opportunity to specify the at least one destination entity.

6. The method defined in claim 1, wherein the resources for the utility application include an application context. 7. The method defined in claim 1, wherein the resources for the utility application include at least one attachment.

8. The method defined in claim 1, wherein sharing the resources with the at least one destination entity comprises: packaging the resources for the utility application into at least one message, the at least one message identifying the utility application.

9. The method defined in claim 8, wherein sharing the resources with the at least one destination entity further comprises: causing the at least one message to be sent to the destination entity to allow the destination entity to launch the utility application with the resources contained in the at least one message.

10. The method defined in claim 1, further comprising:

consulting at least one database to determine whether the destination entity is available;

- in case the destination entity is not available, withholding transmission of the resources at the communication device, otherwise causing the resources to be transmitted towards the destination entity.

11. The method defined in claim 10, wherein consulting the at least one database to determine whether the destination entity is available comprises determining whether the destination entity is online.

12. The method defined in claim 10, wherein consulting at least one database to determine whether the destination entity is available comprises determining whether the destination entity is in a session with the user of the communication device.

13. The method defined in claim 1 , wherein execution of the workspace application includes execution of platform-specific code associated with the workspace application and platform- independent code associated with the workspace application, and wherein the utility application interfaces with the platform-independent code associated with the workspace application.

14. Computer-readable media storing instructions which, when executed by a processor of a communication device, cause the communication device to execute a method that comprises: executing a workspace application;

- executing a utility application within the workspace application;

- responsive to a user invoking a share function, obtaining resources for the utility application;

sharing the resources with at least one destination entity. 5. A communication device, comprising:

- a user input/output interface for allowing a user to interact with the communication device;

a network interface for connecting the device to a communications network;

at least one processor configured to execute a workspace application and to execute a utility application within the workspace application and, responsive to a user invoking a share function via the user input/output interface, to obtain resources for the utility application, and to share the resources with at least one destination entity by transmitting at least one message to the destination entity over the communications network via the network interface.

16. A method implemented by a communication device, comprising:

executing a workspace application;

executing a utility application within the workspace application, the communication device producing an interactive graphical environment on a display of the communication device to allow a user of the communication device to interact with the utility application;

receiving an instruction from the user of the communication device to lock a session that involves the user of the communication device;

executing a session database to indicate that the session is locked.

17. Computer-readable media storing instructions which, when executed by a processor of a communication device, cause the communication device to execute a method that comprises: executing a workspace application;

- updating a session database to indicate that the session is locked.

18. A communication device, comprising:

a user input/output interface for allowing a user to interact with the communication device;

- a network interface for connecting the device to a communications network;

at least one processor configured to execute a workspace application; to execute a utility application within the workspace application, the processor causing the user input/output to produce an interactive graphical environment to allow a user of the communication device to interact with the utility application; to receive an instruction from the user of the communication device to lock a session that involves the user of the communication device; and to cause the network interface to communicate with a session database to update the session database to indicate that the session is locked.

19. A method for execution by a communication device, comprising:

- executing a workspace application;

executing a utility application within the workspace application;

- the workspace application receiving resources for the utility application, the resources having been shared by an originating entity;

executing the utility application using the received resources.

20. The method defined in claim 19, further comprising:

- receiving a message identifying said utility application;

- in case said utility application is not integrated with the workspace application, retrieving computer-readable instructions for said utility application, integrating said utility application with the workspace application and launching said utility application within the workspace application.

21. Computer-readable media storing instructions which, when executed by a processor of a communication device, cause the communication device to execute a method that comprises: - executing a workspace application;

- executing a utility application within the workspace application;

the workspace application receiving resources for the utility application, the resources having been shared by an originating entity;

executing the utility application using the received resources.

22. A communication device, comprising:

- a network interface for connecting the device to a communications network;

- at least one processor configured to execute a workspace application; to execute a utility application within the workspace application, the workspace application receiving resources for the utility application, the resources having been shared by an originating entity; and to execute the utility application using the received resources. 23. A method for execution by a communication device, comprising: - during execution of a workspace application on top of a native operating system of the communication device, receiving a sharing message sent by an originating entity, the sharing message comprising resources for a utility application;

extracting from the sharing message the resources for the utility application;

- determining an action to be taken in respect of launching the utility application with the extracted resources;

- taking said action.

24. The method defined in claim 23, wherein determining an action to be taken is based on context.

25. The method defined in claim 23, wherein determining an action to be taken comprises determining that the action to be taken is to launch the utility application using the extracted resources if a set of conditions is met.

26. The method defined in claim 25, wherein the set of conditions comprises the communication device being or not being in a certain location.

27. The method defined in claim 25, wherein the set of conditions comprises a current time being or not being a certain time.

28. The method defined in claim 25, further comprising: in case the utility application is not already installed on the communication device, installing the utility application on the communication device prior to launch of the utility application.

29. The method defined in claim 28, further comprising retrieving computer-readable instructions corresponding to the utility application from a repository prior to said installing and wherein said installing comprises integrating said computer-readable instructions with the workspace application.

30. The method defined in claim 23, wherein determining an action to be taken comprises determining that the action to be taken is to place an actionable notification in an activity feed, the notification being actionable to launch the utility application using the extracted resources if a set of conditions is met

31. The method defined in claim 23, further comprising: extracting from the sharing message an identity of the utility application.

32. The method defined in claim 23, further comprising:

- receiving an indication that at least one attachment file is associated with the resources for the utility application;

- retrieving the at least one attachment file from a server.

33. The method defined in claim 23, wherein receiving the message comprises: polling a server to inquire as to whether the sharing message is present on the server and retrieving the sharing message from the server when it is present thereon.

34. The method defined in claim 23, wherein receiving the message comprises: receiving a notification that the sharing message is present on a server and retrieving the sharing message from the server in response to the notification message.

35. Computer-readable media storing instructions which, when executed by a processor of a communication device, cause the communication device to execute a method that comprises: during execution of a workspace application on top of a native operating system of the communication device, receiving a sharing message sent by an originating entity, the sharing message comprising resources for a utility application;

extracting from the sharing message the resources for the utility application;

- taking said action.

36. A communication device, comprising:

- a network interface for connecting the device to a communications network;

at least one processor configured to execute a workspace application on top of a native operating system of the communication device so as to receive, during execution of the workspace application, a sharing message sent by an originating entity via the network interface, the sharing message comprising resources for a utility application; to extract from the sharing message the resources for the utility application; to determining an action to be taken in respect of launching the utility application with the extracted resources; and to take said action.

37. A method implemented by a workspace application executing on a communication device, comprising:

executing an activity feed that graphically advises a user of the communication device of messages received from other users that remain to be processed to completion;

causing messages received from users that are in a session with the user of the communication device to be graphically displayed differently from messages received from users that are not in a session with the user of the communication device.

38. Computer-readable media storing instructions which, when executed by a processor of a communication device, cause the communication device to execute a method that comprises: executing an activity feed that graphically advises a user of the communication device of messages received from other users that remain to be processed to completion;

causing messages received from users that are in a session with the user of the communication device to be graphically displayed differently from messages received from users that are not in a session with the user of the communication device. 39. A communication device, comprising:

a network interface for connecting the device to a communications network;

at least one processor configured to execute an activity feed that graphically advises a user of the communication device via the user input/interface of messages received via the network interface from other users that remain to be processed to completion; and to cause messages received from users that are in a session with the user of the communication device to be graphically displayed differently from messages received from users that are not in a session with the user of the communication device.

40. A method implemented by a communication device, comprising:

- executing a workspace application;

- executing a second application within the workspace application, wherein the device is caused to produce an interactive graphical environment on a display of the device; consulting a session database to determine whether a session in which the device is involved has been locked by a leader of the session;

in case the session has been locked, causing the interactive graphical environment on the destination device to replicate an interactive graphical environment being produced on a communication device associated with the leader.

41. The method defined in claim 40, wherein replication of the leader's interactive graphical environment on the destination device occurs in real-time or near-real-time.

42. Computer-readable media storing instructions which, when executed by a processor of a communication device, cause the communication device to execute a method that comprises:

- executing a workspace application;

executing a second application within the workspace application, wherein the device is caused to produce an interactive graphical environment on a display of the device;

consulting a session database to determine whether a session in which the device is involved has been locked by a leader of the session;

43. A communication device, comprising:

a network interface for connecting the device to a communications network;

- at least one processor configured to execute a workspace application; to execute a utility application within the workspace application; to produce an interactive graphical environment via the user input/interface; to consult via the network interface a session database to determine whether a session in which the device is involved has been locked by a leader of the session; and, in case the session has been locked, to cause the interactive graphical environment to replicate an interactive graphical environment being produced on a communication device associated with the leader.

44. A method implemented by a server, comprising:

receiving from an originating user a sharing message and an indication of a destination user, the destination user and the originating user being members of a common group of members, the originating user having a role-based authority to send sharing messages to the destination user;

consulting at least one database to determine whether the destination user is involved in a session that does not involve the originating user;

- in case the destination user is involved in a session that does not involve the originating user, withholding transmission of the sharing message at the server, otherwise causing the sharing message to be transmitted to the destination user.

45. Computer-readable media storing instructions which, when executed by a processor of a communication device, cause the communication device to execute a method that comprises: receiving from an originating user a sharing message and an indication of a destination user, the destination user and the originating user being members of a common group of members, the originating user having a role-based authority to send sharing messages to the destination user;

- consulting at least one database to determine whether the destination user is involved in a session that does not involve the originating user;

46. A server, comprising:

a network interface for connecting the server to a communications network;

at least one processor configured to receive, via the network interface, from an originating user, a sharing message and an indication of a destination user, the destination user and the originating user being members of a common group of members, the originating user having a role-based authority to send sharing messages to the destination user; to consult at least one database to determine whether the destination user is involved in a session that does not involve the originating user; and, in case the destination user is involved in a session that does not involve the originating user, to withhold transmission of the sharing message at the server, otherwise to cause the sharing message to be transmitted to the destination user via the network interface.

47. A method implemented by a server, comprising:

- receiving an indication of a particular user; - consulting a database to identify a group of members to which the particular user belongs, each member having a role selected from a group that includes at least a first role and a second role, wherein a member having the first role has an ability to share messages with members having the second role and a member having the second role lacks an ability to share messages with members having the first role;

- in case the particular user has the first role, signaling to the particular user an indication of each member of the group having the second role.

48. Computer-readable media storing instructions which, when executed by a processor of a communication device, cause the communication device to execute a method that comprises:

- receiving an indication of a particular user;

- consulting a database to identify a group of members to which the particular user belongs, each member having a role selected from a group that includes at least a first role and a second role, wherein a member having the first role has an ability to share messages with members having the second role and a member having the second role lacks an ability to share messages with members having the first role;

- in case the particular user has the first role, signaling to the particular user an indication of each member of the group having the second role. 49. A server, comprising:

a network interface for connecting the server to a communications network;

- at least one processor configured to receive an indication of a particular user via the network interface; to consult a database to identify a group of members to which the particular user belongs, each member having a role selected from a group that includes at least a first role and a second role, wherein a member having the first role has an ability to share messages with members having the second role and a member having the second role lacks an ability to share messages with members having the first role; and, in case the particular user has the first role, to signal to the particular user via the network interface an indication of each member of the group having the second role.