WO2015088322A1

WO2015088322A1 - System and method for managing multiple presentation sessions

Info

Publication number: WO2015088322A1
Application number: PCT/MY2014/000193
Authority: WO
Inventors: Khong Neng Choong; Naghshbandi Danial; Sazali Bin Hisham Muhammad
Original assignee: Mimos Bhd
Current assignee: Mimos Bhd
Priority date: 2013-12-10
Filing date: 2014-06-26
Publication date: 2015-06-18
Anticipated expiration: 2016-06-10
Also published as: MY165471A

Abstract

The present invention relates to a system and method for managing multiple presentation sessions. The system (1000) comprises of a Wireless Screen Controller (WSC) (100) that is connected to a Wireless Screen Administrator (WSA) (200), a Wireless Screen Sender (WSS) (300) and a Wireless Screen Receiver (WSR) (400). Initially, WSS (300) nodes and WSR (400) nodes are connected to the WSC (100) to participate in a presentation session. By connecting these nodes to the WSC (100), the WSS (300) and the WSR (400) automatically submit basic registration information such as the Internet Protocol (IP) address and host name. Next, the WSA (200) connects to the WSC (100) and accesses the presentation management web page. Thereon, the WSA (200) initialises and assigns presentation sessions. Finally, once the session assignment has finished, the WSA (200) activates and manages the presentation sessions.

Description

SYSTEM AND METHOD FOR MANAGING MULTIPLE PRESENTATION

SESSIONS

FIELD OF INVENTION

The present invention relates to a system and method for managing multiple presentation sessions.

BACKGROUND OF THE INVENTION

Presentation is a very common activity in exhibitions, showcases, seminars, conferences, meetings, lectures and many other interactive forums. For a presentation, a presenter normally has their laptop connected to a projector or display screen either by a wire or wirelessly connected. Connecting one laptop to the projector one at a time is manageable if the presentation session only involves one single laptop and one single screen output for each presentation. This situation is widely seen in meetings and lectures.

However, it is a challenge for presentations in large scale such as at the exhibitions, showcases or conferences which involve multiple laptops and multiple display screens. For this kind of events, one screen is usually used for displaying slide materials, two or more screens are for used for product demonstration or visualisation purposes, and one other screen is to display the general agenda of the overall presentation. Due to the technical complicacies, these types of presentations require great coordination and rehearsal between the session moderator and the presenters.

The coordination involves generally 2 parts. The first part is to set up the connectivity of each laptop to each display screen and the second part is to make sure that there are no mistakes while switching between different presentations. For a typical set up, multiple laptops that are used for a single session are connected to a set of different Video Graphics Array (VGA) switches. Additionally, each VGA is linked to different display screens.

It is always a problem for the moderator to switch instructions to all VGA switches almost at the same time in order to change the screens form a current presentation to a next presentation. The other issue is the physical connection of each laptop to the display screens as it is often restricted by the length of the VGA cable from the laptop to the display screen. Hence, there is a need to provide a system and method to address the above mentioned drawbacks. SUMMARY OF INVENTION

The present invention relates to a system and method for managing multiple presentation sessions. The system (1000) for managing multiple presentation sessions comprises of a Wireless Screen Controller (WSC) (100); a Wireless Screen Administrator (WSA) (200) to perform session assignment and management on graphical user interface received from the WSC (100); a Wireless Screen Sender (WSS) (300) to perform screen capturing, data encoding and data transmission to the WSC (100); and a Wireless Screen Receiver (WSR) (400) to receive, decode and display contents received from the WSS (300) via the WSC (100). Additionally, the WSC (100) includes a Registry Module (120) to enable coordination and management of presentation sessions; the WSA (200) includes a Session Management Module (220) to provide end-users a graphical user interface that manages a list of presenters; the WSS (300) includes a Screen Manager (320) to coordinate screen capturing, encoding and transmission of screen content to WSR (400); and the WSR (400) includes a Screen Player (420) to coordinate data receiving, data decoding and displaying of screen content from the WSS (300).

Preferably, the Registry Module (120) comprises of a Session Proxy (121) as a gateway of communication between the WSA (200) and the WSC (100), a Registry Storage (122) to store registration and status information of the WSS (300) and the WSR (400); and a Registry Manager (123) to handle commands of WSA (200) as well as the registration process for the WSS (300) and the WSR (400).

Preferably, the Session Management Module (220) comprises of a Web User Interface (Ul) (221) for a session administrator to set up, assign and manage presentation sessions; a User Interface (Ul) Controller (222) for the Web Ul (221) to translate user's action from the Web Ul (221) into underlying command to be executed; and a Session Agent (223) to execute commands from the Ul Controller (222) to the WSC (100) and to receive status information and updates from the WSC (100). Preferably, the Screen Manager (320) comprises of a Registry Client (321) to perform registration to the WSC (100) and retrieve required information from the WSC (100); and a Session Manager (322) to coordinate screen capturing, encoding and transmission of screen content to WSR (400).

Preferably, the Screen Player (420) comprises of a Register Client (421) to retrieve basic required information of the WSR (400) and to perform registration to the WSC (100); and a Session Manager (422) to coordinate receiving, decoding and displaying of screen content from the WSS (300) and to perform registration to the WSC (100).

The method for managing multiple presentation sessions comprises the steps of connecting Wireless Screen Sender (WSS) (300) and Wireless Screen Receiver (WSR) (400) nodes to a Wireless Screen Controller (WSC) (100); connecting a Wireless Screen Administrator (WSA) (200) to the WSC (100); accessing presentation management webpage by the WSA (200); initialising and assigning presentation sessions by the WSA (200); and activating and managing the presentation sessions by the WSA (200). Preferably, the step of connecting WSS (300) and WSR (400) node to a WSC

(100) includes associating WSS (300) and WSR (400) to the WSC (100); broadcasting location information to the network by the WSC (100), wherein the location information includes Internet Protocol address and port number; receiving the information by a Registry Client (321) of a Screen Manager (320) and a Registry Client (421) of a Screen Player (420); submitting basic information to a Registry Manager (123) of the WSC (100) by the WSS (300) nodes and WSR (400) nodes, wherein the basic information includes Internet Protocol address, media access control address, hostname and role type; saving the received registration information in a Registry Storage (122) by the Registry Manager (123); submitting extra information for session management purposes by the WSS (300), wherein the extra information includes group names and operating system of the WSS (300); submitting the content type to be presented on the WSR (400) by the WSS (300); and saving the information in the Registry Storage (122) by the WSC (100). Preferably, the step of initialising and assigning presentation sessions by the WSA (200) includes retrieving WSS (300) nodes and WSR (400) nodes list information from a Registry Manager (123) by the WSA (200) via a Web User Interface (Ul) (221); receiving commands and requests for node information from a Registry Storage by the Registry Manager (123); forwarding the information to the WSA (200) via a Session Proxy (121); receiving a message event by a User Interface (Ul) Controller (222); populating registered nodes on the Web Ul (221) by the Ul Controller (222); performing a Queue Assignment process if a WSS (300) node is shifted into a WSR (400) queue by a session administrator; performing a Client Grouping process if a grouping button provided at the Web Ul (221) is pressed; and performing a WSR Queue Swapping process if the session administrator wants to swap positions of two WSR (400) queues.

Preferably, the step of performing a Queue Assignment process if a WSS (300) node is shifted into a WSR (400) queue by a session administrator includes searching for a first unoccupied position index within the WSR (400) by the Ul Controller (222); shifting the WSS (300) into the first unoccupied position index position if the unoccupied position index is found; expanding the queue size to accommodate the shifted WSS (300) node into the queue if the queue is full; updating the status of the shifted WSS (300) node to "queuing" by the Ul Controller (222); positioning a selected WSS (300) node at a desired position index within an assigned WSR (400) queue by the session administrator if the node needs to be moved; verifying whether the new position is occupied by another WSS (300) node or not by the Ul Controller (222); and swapping the position of the target nodes involved by the Ul Controller (222) if the new position is occupied.

Preferably, the Client Grouping process includes displaying grouping criteria selection window by the Ul Controller (222) for the selection of session administrator; selecting one of the grouping criteria by the session administrator, wherein the grouping criteria includes operation system type, content type and group name of the WSS (300) node; reading the selected criteria and requesting the value of the criteria of each node from the Registry Manager (123) by the Ul Controller (222); and sorting the WSS (300) nodes based on the criteria and the values by the Ul Controller (222). Preferably, performing WSR Queue Swapping process includes shifting a specific WSR (400) queue over another WSR (400) queue that has been populated by other WSS (300) by the session administrator; detecting overlapping event by the Ul Controller (222); exchanging queue ID of the involved WSR (400) queues by the Ul Controller (222); verifying whether there is at least one active WSR (400) node in both of the overlapping queues by the Ul Controller (222); searching for at least one active WSS (300) in both overlapping queues if at least one active WSR (400) is found by the Ul Controller (222); and sending out commands to display any active WSS (300) to the newly assigned WSR (400) if there is at least one active WSS (300) found by the Ul Controller (222).

Preferably, the step of activating and managing the presentation sessions by the WSA (200) includes distinguishing the type of play button by a Ul Controller (222); informing the specific WSS (300) node to transmit to the selected WSR (400) by the Ul Controller (222) if a Play-Single button is pressed; selecting a queue advancement mode by the session administrator if a Play-Batch button is pressed, wherein the queue advancement mode is either an automatic or manual mode; collecting all the WSS (300) nodes in a specific session; forming a list by the Ul Controller (222), wherein the list stores nodes that are in a same session; informing each node in the list to transmit a desktop screen to the specific WSR (400) through a Registry Manager (123); verifying whether the selected queue advancement mode is an automatic or manual mode by the Ul Controller (222); collecting the nodes that are in the next session by the Ul Controller (222) once a defined time expires; and informing each of the node to transmit to a specific WSR (400).

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention.

FIG. 1 illustrates a block diagram of a system (1000) for managing multiple presentation sessions according to an embodiment of the present invention.

FIG. 2 illustrates a detailed block diagram of the system (1000) of FIG. 1. FIG. 3 illustrates a flow chart of an overall method for managing multiple concurrent presentation sessions according to an embodiment of the present invention.

FIG. 4 illustrates a flow chart of node registration process according to the method shown in FIG. 3.

FIG. 5 illustrates a flow chart of session initialisation and assignment process according to the method shown in FIG. 3. FIG. 6 illustrates a flow chart of the substeps of Queue Assignment process according to the method shown in FIG. 5.

FIG. 7 illustrates a flow chart of the substeps of Client Grouping process according to the method shown in FIG. 5.

FIG. 8 illustrates a flow chart of the substeps of Queue Swapping process according to the method shown in FIG. 5.

FIG. 9 illustrates a flow chart of the presentation session activation process according to the method shown in FIG. 3.

DESCRIPTION OF THE PREFFERED EMBODIMENT

A preferred embodiment of the present invention will be described herein below with reference to the accompanying drawings. In the following description, well known functions or constructions are not described in detail since they would obscure the description with unnecessary detail.

Reference is made initially to FIG. 1 and FIG. 2 which illustrate block diagrams of a system (1000) for managing multiple presentation sessions according to an embodiment of the present invention, wherein the presentation sessions are concurrent. The system (1000) comprises of a Wireless Screen Controller (WSC) (100) that is connected to a Wireless Screen Administrator (WSA) (200), a Wireless Screen Sender (WSS) (300) and a Wireless Screen Receiver (WSR) (400). The WSC (100) is a webserver that serves webpages or contents. It is also a session controller that stores and manages registration and status of the WSA (200), the WSS (300) and the WSR (400). The WSC (100) further comprises a Web Server (110) and a Registry Module (120). The Web Server (110) delivers Session Management Module (220) of the WSA (200) to a web browser (210). Once the Session Management Module (220) is delivered and loaded on the web browser (210), a session administrator manages the presentation sessions which is a function of the WSA (200). The Registry Module (120) is used to enable coordination and management of presentation sessions. It comprises of a Session Proxy (121), a Registry Storage (122) and a Registry Manager (123). The Session Proxy (121) is connected to the Registry Manager (123), while the Registry Manager is also connected to the Registry Storage (122). The Session Proxy (121) is a gateway of communication between Session Agent (223) of the WSA (200) and the Registry Manager (123), wherein the commands received from the WSA (200) is parsed and translated into a form of message that is recognised by the Registry Manager (123) and vice versa. The Registry Storage (122) is to store the registration and status information of the WSS (300) and the WSR (400), while the Registry Manager (123) is to handle the commands of WSA (200) as well as the registration process for the WSS (300) and the WSR (400).

The WSA (200) is used to perform session assignment and management on web-based user interface that is received from the WSC (100). The WSA (200) works within a web browser (210) and runs the Session Management Module (220). The Session Management Module (220) is used to provide its end-users a graphical user interface (GUI) that manages a list of presenters which are displayed in a form of nodes or icons on the GUI, wherein these WSS (300) nodes can be queued and swapped among themselves to manage the sequence of the presentation sessions by the Session Management Module (220) using drag and drop approach for the purpose of displaying remote screen contents on Screen Player (320) of the WSR (300). A remote screen is the screen of the presenter's device, wherein the contents may comprise of video, slide, text document or anything that the presenter is opening at that time. The Session Management Module (220), which is stored within the Web Server (110) of the WSC (100), comprises of a Web User Interface (Ul) (221), a Ul Controller (222) and a Session Agent (223). The Web Ul (221) is connected to the Ul Controller (222), while the Ul Controller is also connected to the Session Agent (223). The Web Ul (221) is a user interface for the session administrator to set up, assign and manage the presentation sessions. The session administrator is the person who uses the WSA (200) to manage the presentation session through the Web Ul (221). The Ul Controller (222) is an event handler for the Web Ul (221) to translate user's action from the Web Ul (221) into underlying command to be executed by the Session Agent (223), wherein the actions may include pressing play buttons and pressing stop buttons which are provided at the Web Ul (222). Besides to execute or forward the commands from the Ul Controller (222) to the WSC (100), the Session Agent (223) is also used to receive status information and updates from the WSC (100).

The WSS (300) performs screen capturing, data encoding and data transmission to the WSC (100) and provides secure connection. The WSS (300) further comprises an Application GUI (310), a Screen Manager (320) and a Core (330). The Application GUI (310), which is an interface for an initial configuration input such as the presentation content type and group names, is connected to the Screen Manager (320) and the Core (330). The Screen Manager (320) which is used to coordinate the screen capturing, encoding and transmission process, as well as the initial registration to the WSC (100), further comprises of a Registry Client (321) that is connected to a Session Manager (322). The Registry Client (321) is used to perform registration to the WSC (100) and retrieve required information from the WSC (100), while the Session Manager (322) is used to interact with the Core (330) in order to coordinate the screen capturing, encoding and the transmission of screen content to WSR (400). To enable the WSS (300) serves as a sender, the Screen Manager (320) works in pair with the support of the Core (330) by having the Session Manager (322) connected to the Core (330). The Core (330) is the one that provides the main functionalities such as performing screen capturing, data encoding and transmission to the WSC (100). Additionally, the Core (330) also provides a secure connection.

The WSR (400) is used to receive, decode and display contents that are received from the WSS (300) via the WSC (100). The WSR (400) further comprises an Application GUI (410), a Screen Player (420) and a Core (430). The Application GUI (410), which is an interface for a user to enter configuration options such as entering the name of the device that runs the WSS (300) which is the WSS (300) node and the device that runs the WSR (400) which is the WSR (400) node for identity purpose, is connected to the Screen Player (420) and the Core (430). The examples of these devices are a laptop or a personal computer. The Screen Player (420), which is used to coordinate the receiving, decoding and displaying of screen content from the Screen Manager (320) as well as the initial registration to the WSC (100), further comprises of a Registry Client (421) that is connected to a Session Manager (422). The Registry Client (421) is used to retrieve basic required information of the WSR (400) and to perform registration to the WSC (100), while the Session Manager (422) is used to interact with the Core (430) in order to coordinate the receiving, decoding and displaying of screen content from the WSS (300) and to perform registration to the WSC (100). To enable the WSR (400) serves as a receiver, the Screen Player (420) works in pair with the support of the Core (330) by having the Session Manager (422) connected to the Core (430). The Core (430) is the one that provides the main functionalities such as performing data receiving from the WSC (100), data decoding and screen displaying besides providing a secure connection.

Moving on to FIG. 3, it illustrates a flow chart of an overall method for managing multiple concurrent presentation sessions according to an embodiment of the present invention. Initially, WSS (300) nodes and WSR (400) nodes are connected manually to the WSC (100) through an operating system (OS) network manager as in step 2000 to participate in a presentation session. For example in Windows, the connection can be made by selecting the access point's name to be displayed in the network manager that is provided at the taskbar. By connecting these nodes to the WSC (100), the WSS (300) and the WSR (400) automatically submit basic registration information such as the Internet Protocol (IP) address and host name to the Registry Manager (123) within the Registry Module (120) of the WSC (100). Next, the WSA (200) connects to the WSC (100) and accesses the Session Management Module (220) that is stored within the Web Server (110) of WSC (100) as in step 3000, wherein once the WSA (200) has accessed this module from WSC (100), the WSC (100) then delivers it to the WSA (200). Thereon, the WSA (200) initialises and assigns presentation sessions via the Web Ul (221) that appears in the web browser (210) as in step 4000. Finally, once the session assignment has finished, the WSA (200) activates and manages the presentation sessions as in step 5000. Referring now to FIG. 4, it illustrates a flow chart of WSS (300) nodes and WSR (400) nodes registration process according to the method shown in FIG. 3. The WSS (300) nodes and the WSR (400) nodes are initially associated to the WSC (100) wirelessly as in step 2100 before registration. Once the association process is established, the WSC (100) announces its presence by broadcasting or multicasting location information such as its IP address and port number to the network. After the Registry Client (321) of the Screen Manager (320) and the Registry Client (421) of the Screen Player (420) receive the information, both WSS (300) nodes and WSR (400) nodes submit the basic information to the Registry Manager (123) of the WSC (100) as in step 2200. The basic information includes the IP address, media access control (MAC) address, hostname and role type, wherein the role type is either a sender which is the WSS (300) or a display which is the WSR (400). The Registry Manager (123) that receives the registration information then saves it in the Registry Storage (122) as in step 2300. After the basic registration, the WSS (300) nodes as senders, submit extra information for session management purposes as in decision 2400 and step 2500, wherein the first basic information is the group names which are defined by the WSS (300) nodes before they connect to the WSC (100), and wherein the second basic information is the operating system (OS) of the WSS (300) nodes which are received by the Registry Client (321). The group names are entered by users who run the WSS (300) nodes through the Application GUI (410), wherein the Application GUI (410) provides an interface to enter the naming configuration. The group names are mainly used for grouping purposes when there are many registered WSS (300) nodes in the presentation session. The WSS (300) nodes then also submit the content type that they will present on the WSR (400) nodes via the WSC (100) as in step 2600. The content type can be an office-based application or a non- office based application. Finally, the WSC (100) saves this information in the Registry Storage (122) to complete the WSS (300) nodes and WSR (400) nodes registration process.

Moving on to FIG. 5, it illustrates a flow chart of session initialisation and assignment process according to the method shown in FIG. 3. Initially, the WSA (200) retrieves the WSS (300) nodes and WSR (400) nodes list with information such as their IP addresses and the group names from the Registry Manager (123) as in step 4010 via the Web Ul (221). Once the Session Management Module (220) is loaded on the web browser (210) of the WSA (200), the Session Management Module (220) sends a request to the Registry Manager (123) that contains a command to retrieve the nodes list as an initialisation. At the same time, the request also includes a command to retrieve the information of each node in the list. Once the Registry Manager (123) receives this command and requests for node information from the Registry Storage (122), it then forwards the information to the WSA (200) via the Session Proxy (121). The Ul Controller (222) receives a message event before it populates the received registered nodes on the Web Ul (221) as in step 4020. The message event is the listener to the incoming message received by the Session Agent (223). When the Session Agent (223) receives a message about the nodes list with the information from the Session Proxy (121), the message event is triggered. The Ul Controller (222) receives that message from the Session Agent (223) and the Ul Controller (222) then populates the received node list on the Web Ul

(221) . The Web Ul (221) has two specific pre-defined containers for the WSS (300) nodes and WSR (400) nodes that enable the Ul Controller (222) to populate the received node list directly into the containers.

After populating the received node list on the Web Ul (221), the Ul Controller

(222) waits for the session administrator's input command as in step 4030, wherein the input command refers to the interactions made by the session administrator to the Web Ul (221). The examples of the input command are pressing the play buttons, pressing the stop buttons and dragging and dropping the WSS (300) nodes into a queue. If the session administrator wants to shift a WSS (300) node into a WSR (400) queue as in decision 4040, a Queue Assignment process takes place as in step 4100. A queue refers to a line-up container which is visible next to each populated WSR (400) node in order for the session administrator to set up the sequence of the presentation screen that is to be displayed on the respective WSR (400). When more than one WSS (300) nodes are dragged and dropped into this line-up container, these nodes are automatically queued horizontally from left to right emulating a queue. Shifting a WSS (300) node into the WSR (400) queue refers to the act of dragging and dropping the WSS (300) node into the selected queue. The detailed explanation of the Queue Assignment process is shown in FIG. 6.

However, if the session administrator does not shift a WSS (300) node into the WSR (400) queue, the process proceeds by checking whether or not a grouping button provided at the Web Ul (221) is pressed as in decision 4050. If the grouping button is pressed, a Client Grouping process takes place as in step 4300. The Client Grouping process is shown in detail in FIG. 7. On the other hand, if the grouping button is not pressed as in decision 4050, the process proceeds by checking if the session administrator wants to swap the position of two WSR (400) queues as in decision 4060. If the session administrator wants to swap the position of the WSR (400) queues, the process continues with a WSR Queue Swapping process as in step 4500. The WSR Queue Swapping process is shown in detail in FIG. 8. If the session administrator does not want to swap the position of the WSR (400) queues, the process repeats from step 4030, wherein the Ul Controller (222) waits for the session administrator input command.

The session initialisation and assignment process ends as in decision 4600 if the session administrator is done with all the assignments and proceeds to step 5000 of FIG. 3 However, if the session administrator needs to change the position of a WSS (300) node in the queue and has to re-drag and drop the WSS (300) node into a new position inside the queue as in decision 4600, the assignment is incomplete and the process repeats from step 4030.

Referring now to FIG. 6, it illustrates a flow chart of the substeps of Queue Assignment process according to the method shown in FIG. 5. Once the session administrator shifts a WSS (300) node into the WSR (400) queue as in decision 4040, the Ul Controller (222) searches for a first unoccupied position index within the WSR (400) queue as in step 4110. A position index refers to the position within the queue which is numbered in sequence. If position index 1 refers to the first position in the queue, an unoccupied position index refers to a position that is still available within the queue due to no WSS (300) node placed in that position at that time. If the unoccupied position index is found as in decision 4120, the Ul Controller (222) assigns the shifted WSS (300) into the first unoccupied position index position as in step 4140. However, if the queue is full, the Ul Controller (222) expands the queue size to accommodate the shifted WSS (300) node into the queue as in step 4130. The queue initially has a default length, but the queue size can be expanded by programmatically redraw the queue with a new default length when the queue is full, wherein the new default length is the old default length plus 1. Next, the Ul Controller (222) updates the status of the shifted WSS (300) node to "queuing" and saves it as in step 4150.

The session administrator can also move any node if the position of the node needs to be changed since each node is drag and drop enabled. For example, if the session administrator realises that a node is assigned in a wrong position, the session administrator has to re-drag and drop the selected node to a new position in the queue. If a WSS (300) node needs to be moved to a new position as in decision 4160, the session administrator positions the selected WSS (300) node at a desired position index within an assigned WSR (400) queue as in step 4170. The Ul Controller (222) then verifies whether the new position is currently occupied by another WSS (300) node or not as in decision 4180. If the new position is occupied, the Ul Controller (222) swaps the position of the target nodes involved as in step 4190. When the session administrator wants to re-drag and drop a WSS (300) node from an original position to a target position while that target position is already occupied by another WSS (300) node, both WSS (300) nodes exchange positions. In other words, the nodes are swapped. However, if the new position is not occupied as in decision 4180, the Ul Controller (222) just assigns the WSS (300) node to the new position.

Reference is now made to FIG. 7 which illustrates a flow chart of the substeps of Client Grouping process according to the method shown in FIG. 5. Initially, the Ul Controller (222) displays the grouping criteria selection window for the selection of session administrator as in step 4310. Next, the session administrator selects one of the grouping criteria as in step 4320, wherein the grouping criteria can either be based on the operation system (OS) type, content type or group name of the WSS (300) node. Thereon, the Ul Controller (222) reads the selected criteria and requests the value of the criteria of each node from the Registry Manager (123) as in step 4330. Once the Ul Controller (222) receives the values, it sorts the WSS (300) nodes based on the criteria and the values as in step 4340. The nodes that share the same criteria values are arranged in the same group.

Moving on to FIG. 8, it illustrates a flow chart of the substeps of Queue Swapping process according to the method shown in FIG. 5. Initially the session administrator shifts a specific WSR (400) queue over another WSR (400) queue that has been populated by other WSS (300) nodes as in step 4510. After the Ul Controller (222) detects this overlapping event, it then exchanges the queue ID of the involved WSR (400) queues as in step 4520. Next, the Ul Controller (222) verifies whether there is at least one active WSR (400) node in both of the overlapping queues as in decision 4530. If there is no active WSR (400) node available as in decision 4530, the Ul Controller (222) sets the WSR (400) status to "idle" as in step 4540 and terminates the Queue Swapping process.

However, if at least one active WSR (400) is found as in decision 4530, the Ul Controller (222) searches for at least one active WSS (300) in both overlapping queues as in step 4550. If there is at least one active WSS (300) found as in decision 4560, the Ul Controller (222) finally sends out the command to display any active WSS (300) to the newly assigned WSR (400) as in step 4570 and terminates the Queue Swapping process. When two queues are swapped, these queues belong to a new WSR (400). For example, if WSR1 has a queue Q1 and WSR2 has a queue Q2, and Q1 is swapped with Q2; Q1 now becomes the queue of its newly assigned WSR (400) which is the WSR2 while Q2 becomes the queue of its newly assigned WSR (400) which is the WSR1. The Ul Controller (222) displays it via the Session Agent (223) of the WSA (200). On the other hand, if no active WSS (300) is found in decision 4560, the Ul Controller (222) just sets WSR (400) status to "idle" as in step 4540.

Referring now to FIG. 9, it illustrates a flow chart of the presentation session activation process according to the method shown in FIG. 3. Initially, the Ul Controller (222) waits for a play button provided at the Web Ul (221) to be pressed as in decision 5010. Once the play button is pressed, the Ul Controller (222) distinguishes the type of the play button. If it is a Play-Single button as in decision 5020, the Ul Controller (222) informs the specific WSS (300) node to transmit to the selected WSR (400) as in step 5030 and it waits for a stop signal. When a stop button provided at the Web Ul (221) is pressed by the session administrator, the Ul Controller (222) will detect the event and interprets it as a stop signal. Stop signal means stopping an active WSS (300) node or a group of active WSS (300) nodes from sending the presentation screen. If the Ul Controller (222) receives the stop signal, the presentation session ends as in step 5050, wherein the presentation session refers to the whole presentations for that day. On the other hand, if the Ul Controller (222) receives the stop signal but the session administrator does not want to end the presentation session, the session administrator can select the play button so that the WSS (300) nodes in the queue can be sent to the presentation screen as in decision 5050 and step 5010.

However, if the play button pressed is not a Play-Single button as in decision 5020 but it is a Play-Batch button, the session administrator is given an option to further select the queue advancement mode which can either be automatic or manual as in step 5060. Thereon, the Ul Controller (222) collects all the WSS (300) nodes in the specific session and forms a list as in step 5070, wherein the list is an array to store nodes that are in the same session, and wherein the same session refers to the same position index in each queue. For example, if there are 3 WSR (400) nodes having 3 queues, each WSS (300) node that is assigned to the position index 1 in each queue is considered as the WSS (300) nodes that are in the same session. Next, the Ul Controller (222) informs each node in the list to transmit a desktop screen to the specific WSR (400) through the Registry Manager (123) as in step 5080. The Ul Controller (222) then verifies whether the selected queue advancement mode is an automatic mode or manual mode as in decision 5090. If it is an automatic mode, the Ul Controller (222) waits for the user defined timer to expire as in decision 5100 and once it expires, the Ul Controller (222) automatically collects the nodes that are in the next session and informs each of the node to transmit to the specific WSR (400). The automatic advancement function continues until the session administrator decides to stop it as in decision 5110 or until the queue is exhausted which is when the automatic advancement reached the end of the queue. For example, if the queue length is 5 and all position indexes are occupied by the assigned WSS (300) nodes, then we can say that there are 5 presentation sessions. When an automatic queue advancement mode is selected, the session starts with all WSS (300) nodes at position index 1 and the session advances to the next position index each time the user-defined timer has ended. Since the length is 5, the automatic advancement will stop after the fifth session.

On the other hand, if the selected queue advancement mode is a manual mode as in decision 5090, the Ul Controller (222) collects all WSS (300) nodes at current selected position index and forms a list in order to start that session by commanding the selected WSS (300) nodes to transmit the presentation screen before it waits for the stop signal as in decision 5040. Once the stop signal is triggered, the session stops and the system (1000) waits for the next action from the session administer. Finally, the Ul Controller (222) waits for the stop signal from the queue advancement more as in decision 5040 before it decides to terminate the presentation session as in decision 5050.

While embodiments of the invention have been illustrated and described, it is not intended that these embodiments illustrate and describe all possible forms of the invention. Rather, the words used in the specifications are words of description rather than limitation and various changes may be made without departing from the scope of the invention.

Claims

1. A system (1000) for managing multiple presentation sessions comprises of: a) a Wireless Screen Controller (WSC) (100);

b) a Wireless Screen Administrator (WSA) (200) to perform session assignment and management on graphical user interface received from the WSC (100);

c) a Wireless Screen Sender (WSS) (300) to perform screen capturing, data encoding and data transmission to the WSC (100); and d) a Wireless Screen Receiver (WSR) (400) to receive, decode and display contents received from the WSS (300) via the WSC (100), characterised in that:

i. the WSC (100) includes a Registry Module (120) to enable coordination and management of presentation sessions; ii. the WSA (200) includes a Session Management Module (220) to provide end-users a graphical user interface that manages a list of presenters;

iii. the WSS (300) includes a Screen Manager (320) to coordinate screen capturing, encoding and transmission of screen content to WSR (400); and

iv. the WSR (400) includes a Screen Player (420) to coordinate data receiving, data decoding and displaying of screen content from the WSS (300).

The system (1000) as claimed in claim 1 , wherein the Registry Module (120) comprises of:

a) a Session Proxy (121) as a gateway of communication between the WSA (200) and the WSC (100);

b) a Registry Storage (122) to store registration and status information of the WSS (300) and the WSR (400); and

c) a Registry Manager (123) to handle commands of WSA (200) as well as the registration process for the WSS (300) and the WSR (400).

3. The system (1000) as claimed in claim 1 , wherein the Session Management Module (220) comprises of: a) a Web User Interface (Ul) (221) for a session administrator to set up, assign and manage presentation sessions;

b) a User Interface (Ul) Controller (222) for the Web Ul (221) to translate user's action from the Web Ul (221) into underlying command to be executed; and

c) a Session Agent (223) to execute commands from the Ul Controller (222) to the WSC (100) and to receive status information and updates from the WSC (100).

The system (1000) as claimed in claim 1 , wherein the Screen Manager (320) comprises of:

a) a Registry Client (321) to perform registration to the WSC (100) and retrieve required information from the WSC (100); and

b) a Session Manager (322) to coordinate screen capturing, encoding and transmission of screen content to WSR (400).

The system (1000) as claimed in claim 1 , wherein the Screen Player (420) comprises of:

a) a Register Client (421) to retrieve basic required information of the WSR (400) and to perform registration to the WSC (100); and b) a Session Manager (422) to coordinate receiving, decoding and displaying of screen content from the WSS (300) and to perform registration to the WSC (100).

A method for managing multiple presentation sessions comprises the steps of:

a) connecting Wireless Screen Sender (WSS) (300) and Wireless Screen Receiver (WSR) (400) nodes to a Wireless Screen Controller (WSC) (100);

b) connecting a Wireless Screen Administrator (WSA) (200) to the WSC (100);

c) accessing presentation management webpage by the WSA (200); d) initialising and assigning presentation sessions by the WSA (200); and e) activating and managing the presentation sessions by the WSA (200). The method as claimed in claim 6, wherein the step of connecting WSS (300) and WSR (400) node to a WSC (100) includes:

a) associating WSS (300) and WSR (400) to the WSC (100);

b) broadcasting location information to the network by the WSC (100), wherein the location information includes Internet Protocol address and port number;

c) receiving the information by a Registry Client (321) of a Screen Manager (320) and a Registry Client (421) of a Screen Player (420); d) submitting basic information to a Registry Manager (123) of the WSC (100) by the WSS (300) nodes and WSR (400) nodes, wherein the basic information includes Internet Protocol address, media access control address, hostname and role type;

e) saving the received registration information in a Registry Storage (122) by the Registry Manager (123);

f) submitting extra information for session management purposes by the WSS (300), wherein the extra information includes group names and operating system of the WSS (300);

g) submitting the content type to be presented on the WSR (400) by the WSS (300); and

h) saving the information in the Registry Storage (122) by the WSC (100).

The method as claimed in claim 6, wherein the step of initialising and assigning presentation sessions by the WSA (200) includes:

a) retrieving WSS (300) nodes and WSR (400) nodes list information from a Registry Manager (123) by the WSA (200) via a Web User Interface (Ul) (221);

b) receiving commands and requests for node information from a Registry Storage by the Registry Manager (123);

c) forwarding the information to the WSA (200) via a Session Proxy (121);

d) receiving a message event by a User Interface (Ul) Controller (222); e) populating registered nodes on the Web Ul (221) by the Ul Controller (222); f) performing a Queue Assignment process if a WSS (300) node is shifted into a WSR (400) queue by a session administrator; g) performing a Client Grouping process if a grouping button provided at the Web Ul (221) is pressed; and

h) performing a WSR Queue Swapping process if the session administrator wants to swap positions of two WSR (400) queues.

The method as claimed in claim 8, wherein the step of performing a Queue Assignment process if a WSS (300) node is shifted into a WSR (400) queue by a session administrator includes:

a) searching for a first unoccupied position index within the WSR (400) by the Ul Controller (222);

b) shifting the WSS (300) into the first unoccupied position index position if the unoccupied position index is found;

c) expanding the queue size to accommodate the shifted WSS (300) node into the queue if the queue is full;

d) updating the status of the shifted WSS (300) node to "queuing" by the Ul Controller (222);

e) positioning a selected WSS (300) node at a desired position index within an assigned WSR (400) queue by the session administrator if the node needs to be moved;

f) verifying whether the new position is occupied by another WSS (300) node or not by the Ul Controller (222); and

g) swapping the position of the target nodes involved by the Ul Controller (222) if the new position is occupied.

10. The method as claimed in claim 9, wherein the Client Grouping process includes:

a) displaying grouping criteria selection window by the Ul Controller (222) for the selection of session administrator;

b) selecting one of the grouping criteria by the session administrator, wherein the grouping criteria includes operation system type, content type and group name of the WSS (300) node; c) reading the selected criteria and requesting the value of the criteria of each node from the Registry Manager (123) by the Ul Controller (222); and

d) sorting the WSS (300) nodes based on the criteria and the values by the Ul Controller (222).

1 1. The method as claimed in claim 10, wherein performing WSR Queue Swapping process includes:

a) shifting a specific WSR (400) queue over another WSR (400) queue that has been populated by other WSS (300) by the session administrator;

b) detecting overlapping event by the Ul Controller (222);

c) exchanging queue ID of the involved WSR (400) queues by the Ul Controller (222);

d) verifying whether there is at least one active WSR (400) node in both of the overlapping queues by the Ul Controller (222);

e) searching for at least one active WSS (300) in both overlapping queues if at least one active WSR (400) is found by the Ul Controller (222); and

f) sending out commands to display any active WSS (300) to the newly assigned WSR (400) if there is at least one active WSS (300) found by the Ul Controller (222).

12. The method as claimed in claim 6, wherein the step of activating and managing the presentation sessions by the WSA (200) includes:

a) distinguishing the type of play button by a Ul Controller (222);

b) informing the specific WSS (300) node to transmit to the selected WSR (400) by the Ul Controller (222) if a Play-Single button is pressed;

c) selecting a queue advancement mode by the session administrator if a Play-Batch button is pressed, wherein the queue advancement mode is either an automatic or manual mode;

d) collecting all the WSS (300) nodes in a specific session;

e) forming a list by the Ul Controller (222), wherein the list stores nodes that are in a same session; f) informing each node in the list to transmit a desktop screen to the specific WSR (400) through a Registry Manager (123);

g) verifying whether the selected queue advancement mode is an automatic or manual mode by the Ul Controller (222);

h) collecting the nodes that are in the next session by the Ul Controller

(222) once a defined time expires; and

i) informing each of the node to transmit to a specific WSR (400).