SYSTEMS AND METHODS FOR PROVIDING CLIENT-SIDE ENABLEMENT OF SERVER COMMUNICATIONS VIA A SINGLE COMMUNICATION SESSION FOR A PLURALITY OF BROWSER-BASED PRESENTATION INTERFACES

[0001] This application is a continuation of U.S. patent application Ser. No. 16/140,705, filed Sep. 25, 2018, the entire contents of which are incorporated herein by reference.

[0002] Embodiments of the subject matter described herein relate generally to client-server communications techniques established on the client side. More particularly, embodiments of the subject matter relate to a browser-based, client-side mechanism for enabling more than one presentation interface to communicate with a server using a single communication session.

[0003] During a web-browsing session, a user may navigate various websites using more than one browser application window and/or browser application tab. Users may wish to open certain webpages or sections of webpages and to keep them open, while continuing to browse other websites or sections using other open tabs or windows. In circumstances wherein a user has opened and is currently using a plurality of windows or tabs, servers communicating with the user's browser application are generally required to maintain a separate communication session for each open tab or window, thus requiring multi-threaded communications between the server and the client device. A server may not have the resources to maintain these multi-threaded communication sessions.

[0004] Accordingly, it is desirable to provide client-server communications solutions that are less resource-intensive on the server-side. Furthermore, other desirable features and characteristics will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and the foregoing technical field and background.

[0005] Some embodiments of the present disclosure provide a method for communicating with a server system, by a client device comprising a computer system configured to store, maintain, execute, and support a browser application. The method establishes a single communication session with a server system, by the client device, wherein the single communication session comprises one individual client-side, browser-based communication session; presents a plurality of browser-based presentation interfaces comprising at least one of browser-based tabs and browser-based windows, by the client device, wherein the browser-based presentation interfaces are associated with the browser application; enables communication between the plurality of browser-based presentation interfaces and the server system via the single communication session, wherein the communication comprises server system data transmissions received by the client device via the single communication session and client device data transmissions transmitted by the client device; and dynamically updates each of the plurality of browser-based presentation interfaces in real-time, by the client device, based on the server system data transmissions and the client device data transmissions.

[0006] Some embodiments of the present disclosure provide a client device configured to communicate with a server system, the client device configured to store, maintain, execute, and support a browser application. The client device includes a system memory element; a communication device, configured to establish communication connections to a server system and to transmit and receive data via the communication connections; at least one processor communicatively coupled to the system memory element and the communication device, the at least one processor configured to: establish a single communication session with the server system, wherein the single communication session comprises one individual client-side, browser-based communication session; present a plurality of browser-based presentation interfaces comprising at least one of browser-based tabs and browser-based windows, wherein the browser-based presentation interfaces are associated with the browser application; enabling communication between the plurality of browser-based presentation interfaces and the server system via the single communication session, wherein the communication comprises server system data transmissions received by the client device via the single communication session and client device data transmissions transmitted by the client device; and dynamically updating each of the plurality of browser-based presentation interfaces in real-time, based on the server system data transmissions and the client device data transmissions.

[0007] Some embodiments of the present disclosure provide a non-transitory, computer-readable medium containing instructions thereon, which, when executed by a processor, are capable of performing a method for communicating with a server system, by a client device comprising a computer system configured to store, maintain, execute, and support a browser application. The method receives a user input request to execute the browser application, via a user interface of the client device; and, in response to the user input request, executes the browser application; presents a first one of a plurality of browser-based presentation interfaces; and establishes a single communication session between the first one and the server system, by the client device, wherein the single communication session comprises one individual client-side, browser-based communication session; receives one or more additional user input requests to open additional browser-based presentation interfaces, via the user interface of the client device, wherein the plurality of browser-based presentation interfaces comprise the first one and the additional browser-based presentation interfaces; presents the plurality of browser-based presentation interfaces comprising at least one of browser-based tabs and browser-based windows, by the client device, wherein the browser-based presentation interfaces are associated with the browser application; enables communication between the plurality of browser-based presentation interfaces and the server system via the single communication session, wherein the communication comprises server system data transmissions received by the client device via the single communication session and client device data transmissions transmitted by the client device; and dynamically updates each of the plurality of browser-based presentation interfaces in real-time, by the client device, based on the server system data transmissions and the client device data transmissions.

[0008] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0019] The following detailed description is merely illustrative in nature and is not intended to limit the embodiments of the subject matter or the application and uses of such embodiments. As used herein, the word “exemplary” means “serving as an example, instance, or illustration.” Any implementation described herein as exemplary is not necessarily to be construed as preferred or advantageous over other implementations. Furthermore, there is no intention to be bound by any expressed or implied theory presented in the preceding technical field, background, brief summary or the following detailed description.

[0020] The subject matter presented herein relates to systems and methods for establishing a client-side, browser-based solution for communicating with one or more servers by a plurality of presentation interfaces provided by a client device. More specifically, the subject matter relates to establishing a master/slave model for the plurality of presentation interfaces, such that one particular “master” tab or window for the browser application establishes a communication session for exchanging data messages with the one or more servers and acts as an intermediary to facilitate the exchange of data transmissions between the one or more servers and at least one “slave” tab or window for the browser application.

[0021] Certain terminologies are used with regard to the various embodiments of the present disclosure. A browser is a software application used to locate and display web pages, which may be included as part of the internet and/or as part of a specified intranet. A presentation interface is a graphical user interface (GUI) associated with the browser application, the GUI configured to present a document or panel including web site data, text-based elements, graphical elements, user-selectable elements (e.g., menus, hyperlinks), and any other web-based, visually-presented graphic or text element configured to convey website data and/or to receive user input data. A communication session is a data transfer thread between the server system and a particular aspect of the client device which receives server-based data via the communication session. A master browser window or master browser tab (presented as part of the executed browser application) is an aspect of the client device capable of initiating and maintaining the communication session. Slave windows or tabs communicate with the one or more servers by broadcasting data to be received by the master presentation interface, and the master presentation interface is configured to transmit the received data to the one or more servers.

[0022] Turning now to the figures, FIG. 1 is a diagram of a system 100 for providing a client-side, browser-based, single communication session for a plurality of browser-based presentation interfaces associated with a client device 102, in accordance with the disclosed embodiments. As shown, the system 100 includes a client device 102 for operation by a user. The client device 102 may be implemented using a standalone personal computer, a portable computer (e.g., a laptop, a tablet computer, or a handheld computing device), a computer integrated into another device or system (e.g., a “smart” tv, a smartphone, or a smartwatch), or any other device or platform including at least one processor, some form of memory, and a user interface to allow a user to interact with the client device 102. The user interface may include various human-to-machine interfaces, e.g., a keypad, keys, a keyboard, buttons, switches, knobs, a touchpad, a joystick, a pointing device, a virtual writing tablet, a touch screen, a microphone, or any device, component, or function that enables the user to select options, input information, or otherwise control the operation of the client device 102.

[0023] The client device 102 is capable of communicating with a remote server system 106 via a data communication network 108. The data communication network 108 may be any digital or other communications network capable of transmitting messages or data between devices, systems, or components. In certain embodiments, the data communication network 108 includes a packet switched network that facilitates packet-based data communication, addressing, and data routing. The packet switched network could be, for example, a wide area network, the Internet, or the like. In various embodiments, the data communication network 108 includes any number of public or private data connections, links or network connections supporting any number of communications protocols. The data communication network 108 may include the Internet, for example, or any other network based upon TCP/IP or other conventional protocols. In various embodiments, the data communication network 108 could also incorporate a wireless and/or wired telephone network, such as a cellular communications network for communicating with mobile phones, personal digital assistants, and/or the like. The data communication network 108 may also incorporate any sort of wireless or wired local and/or personal area networks, such as one or more IEEE 802.3, IEEE 802.16, and/or IEEE 802.11 networks, and/or networks that implement a short range (e.g., Bluetooth) protocol. For the sake of brevity, conventional techniques related to data transmission, signaling, network control, and other functional aspects of the systems (and the individual operating components of the systems) may not be described in detail herein.

[0024] The server system 106 may include one or more remotely located servers, and the server system 106 provides any data for presentation via the browser application stored, maintained, executed, and supported by the client device 102. The server system 106 may provide internet-based data, intranet-based data, chat or messaging application data, communication session identifiers or other connection data, and any applicable data originating from a potential secondary computer system 104. The server system 106 may include any number of application servers, and each server may be implemented using any suitable computer. In some embodiments, the server system 106 includes one or more dedicated computers. In some embodiments, the server system 106 includes one or more computers carrying out other functionality in addition to server operations. In exemplary embodiments, the server system 106 operates within a client-server architecture, executing programs to serve the requests of other programs (i.e., a browser application executed by the client device 102). In this example, the client device 102 acts as the client, and the server system 106 performs some tasks on behalf of the client device 102, to include providing the browser application data.

[0025] One or more application servers of the server system 106 maintains and provides web-based data which enables users to interact over the Internet or an intranet. The client device 102 interacts with the server system 106 in such a way that the client device 102 provides data communications to the server system 106 and receives data communications from the server system 106. In certain embodiments, the server system 106 may act as an intermediary which receives data communications from the computer system 104 that are directed to the client device 102, wherein the server system 106 receives computer system 104 data communications and the server system 106 then forwards the computer system 104 data communications to the client device 102 as part of a particular functionality of a browser application that is maintained, executed, and utilized via the client device 102. For example, when the client device 102 initiates a chat application or messaging application via the browser application, the computer system 104 may be operated by a customer service agent, appointment secretary, or other agent communicating with the user of the client device 102 via the chat application. However, the computer system 104 does not communicate with the client device 102 directly. Instead, the server system 106 provides chat application or messaging application data, including functionality associated with the chat application itself, and also including transmitted messages from the agent using the computer system 104 which have been sent to the server system 106 first and then forwarded as part of the chat application data communications transmitted to the client device 102 throughout the duration of the chat or messaging session.

[0026] During typical operation, the client device 102 executes a browser application and opens a first presentation interface for the browser application, wherein the first presentation interface establishes a communication session with the server system 106 to exchange communications between the client device 102 and the server system 106. The client device 102 proceeds to open one or more additional presentation interfaces, and implements a master/slave model for the plurality of presentation interfaces such that only the one single, individual communication session is maintained by the master presentation interface to communicate with the server system 106, and each of the slave presentation interfaces transmits data to, and receives data from, the server system 106 via the established communication session of the master presentation interface. Thus, a browser-based, client-side solution is implemented to permit communications between the server system 106 and the plurality of presentation interfaces of the client device 102.

[0027] FIG. 2 is a functional block diagram of a computer system implemented as a client device 200 communicating with a server system using a client-side, browser-based, single communication session for a plurality of browser-based presentation interfaces, in accordance with the disclosed embodiments. It should be noted that the client device 200 corresponds to the client device 102 of FIG. 1. The client device 200 generally includes, without limitation: at least one processor 202; a system memory element 204; a user interface 206; a communication device 208; a browser module 210; a browser-based presentation interface module 212; a browser-based communication channel module 214; a real-time updating module 216; and a display device 218. These elements and features of the client device 200 may be operatively associated with one another, coupled to one another, or otherwise configured to cooperate with one another as needed to support the desired functionality, as described herein. For ease of illustration and clarity, the various physical, electrical, and logical couplings and interconnections for these elements and features are not depicted in FIG. 2. Moreover, it should be appreciated that embodiments of the client device 200 will include other elements, modules, and features that cooperate to support the desired functionality. For simplicity, FIG. 2 only depicts certain elements that relate to the techniques described in more detail below.

[0028] The at least one processor 202 may be implemented or performed with one or more general purpose processors, a content addressable memory, a digital signal processor, an application specific integrated circuit, a field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination designed to perform the functions described here. In particular, the at least one processor 202 may be realized as one or more microprocessors, controllers, microcontrollers, or state machines. Moreover, the at least one processor 202 may be implemented as a combination of computing devices, e.g., a combination of digital signal processors and microprocessors, a plurality of microprocessors, one or more microprocessors in conjunction with a digital signal processor core, or any other such configuration.

[0029] The at least one processor 202 communicates with system memory 204. The system memory 204 may be realized using any number of devices, components, or modules, as appropriate to the embodiment. In practice, the system memory 204 could be realized as RAM memory, flash memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, or any other form of storage medium known in the art. In certain embodiments, the system memory 204 includes a hard disk, which may also be used to support functions of the at least one processor 202. The system memory 204 can be coupled to the at least one processor 202 such that the at least one processor 202 can read information from, and write information to, the system memory 204. In the alternative, the system memory 204 may be integral to the at least one processor 202. As an example, the at least one processor 202 and the system memory 204 may reside in a suitably designed application-specific integrated circuit (ASIC).

[0030] The user interface 206 may include or cooperate with various features to allow a user to interact with the client device 200 via a browser software application connected to a server system (described previously with respect to FIG. 1). Accordingly, the user interface module 206 may initiate the creation and maintenance of presentation interfaces (e.g., browser windows and/or browser tabs) implemented as graphical user interfaces (GUIs), rendered on a display device 218. In certain embodiments, the display device 218 implements touch-sensitive technology for purposes of interacting with the GUI. Thus, a user can manipulate the GUI by moving a cursor symbol rendered on the display device 218, or by physically interacting with the display device 218 itself for recognition and interpretation. Using input keyboard commands and/or touch-screen commands (among other types of input commands), the user could manipulate the GUI to interact with a browser application to access and interact with various applications, widgets, or features associated with the browser application.

[0031] In particular, the user interface module 206 presents graphical elements associated with initiating and participating in a chat or messaging session, setting appointments, performing online shopping, and/or participating in any online activity as a guest user without the requirement of the user being logged in, but which permits the user to open additional browser windows or tabs and maintaining a chat session, an appointment-setting session, an online shopping session, or the like, and maintaining continuity between all open browser tabs and browser windows.

[0032] The communication device 208 is suitably configured to communicate data between the client device 200 and one or more remote servers (which may provide the client device 200 with server system data and/or potentially additional communication data from an optional second participant computer system, as shown in FIG. 1). The communication device 208 may transmit and receive communications over a wireless local area network (WLAN), the Internet, a satellite uplink/downlink, a cellular network, a broadband network, a wide area network, or the like. As described in more detail below, data received by the communication device 208 may include, without limitation: browser application data, chat/messaging session data, online shopping data, online appointment setting data, and other data compatible with the client device 200. Data provided by the communication device 208 may include, without limitation, user interactions with a chat/messaging session, online shopping session, online appointment setting session, and the like.

[0033] The browser module 210 is suitably configured to provide internet browser functionality for the client device 200, including the ability to locate, retrieve, and present websites requested by the client device 200 for user interaction via the client device 200. Further, the browser module 210 is configured to receive user input data to the browser application such that a user may make selections, navigate websites for the internet and/or an intranet, request server-based data, and participate in chat/messaging sessions, online shopping sessions, and/or online appointment-setting sessions.

[0034] The browser-based presentation interface module 212 is configured to provide a plurality of presentation interfaces, via the browser application, for user interaction with the browser application. A presentation interface is a graphical user interface (GUI) associated with the browser application, the GUI configured to present a document or panel including website data, text-based elements, graphical elements, user-selectable elements (e.g., menus, hyperlinks), and any other web-based, visually-presented graphic or text element configured to convey website data and/or to receive user input data.

[0035] The browser-based communication channel module 214 is configured to perform internal and external communication functions for the client device 200. The browser-based communication channel module 214 includes two separate and distinct aspects: (1) establishing and maintaining one single individual communication session between a master presentation interface and one or more remotely located servers, via the communication device 208; and (2) establishing and maintaining a broadcast pipeline for the plurality of presentation interfaces to communicate among themselves by broadcasting data transmissions to all open presentation interfaces of the browser application, which are received by those presentation interfaces that are configured to “listen” for applicable and relevant broadcasted data. As described herein, a single and individual communication session is a data transfer thread between the server system and a particular aspect of the client device which receives server-based data via the communication session. A master browser window or master browser tab (presented as part of the executed browser application) is an aspect of the client device capable of initiating and maintaining the communication session. Slave windows or tabs communicate with the one or more servers by broadcasting data to be received by the master presentation interface, and the master presentation interface is configured to transmit the received data to the one or more servers.

[0036] The real-time updating module 216 is configured to dynamically update all presentation interfaces of the browser application, in real-time, such that all open presentation interfaces present the same interactive data for a current chat/messaging session, a current online shopping session, and/or a current online appointment-setting session for a user that is not logged in to a particular online system. The real-time updating module 216 is configured to use the broadcast pipeline to provide updates to a master presentation interface from one or more slave presentation interfaces, and to provide updates to a set of slave interfaces from a master presentation interface.

[0037] The display device 218 is configured to display various icons, text, and/or graphical elements associated with a browser application and a plurality of presentation interfaces for the client device 200. In an exemplary embodiment, the display device 218 is communicatively coupled to the user interface 206 and the at least one processor 202. The at least one processor 202, the user interface 206, and the display device 218 are cooperatively configured to display, render, or otherwise convey one or more graphical representations or images associated with the browser application and a plurality of presentation interfaces on the display device 218, as described in greater detail below. In an exemplary embodiment, the display device 218 is realized as an electronic display configured to graphically display browser application data and presentation interface data, as described herein. In some embodiments, the display device 218 is implemented as a display screen of a standalone, personal computing device (e.g., laptop computer, tablet computer). It will be appreciated that although the display device 218 may be implemented using a single display, certain embodiments may use additional displays (i.e., a plurality of displays) to accomplish the functionality of the display device 218 described herein.

[0038] FIG. 3 is a flow chart that illustrates an embodiment of a process 300 for communicating with a server system, by a client device configured to store, maintain, execute, and support a browser application, in accordance with the disclosed embodiments. For ease of description and clarity, it is assumed that the process 300 begins by receiving a user input request to execute the browser application, via a user interface of the client device (step 302). As described herein, the client device is implemented as a computer system that is in communication with one or more servers (e.g., server system 106 of FIG. 1), and the user input request may be received via an applicable touchscreen or other hardware element communicatively coupled to the client device (e.g., user interface 206 of FIG. 2). The user input request to execute the browser application may be a user selection of a graphical element, a menu option, a data input field, or the like.

[0039] In response to the received user input request (step 302), the process 300 executes the browser application, by the client device (step 304); presents a first one of a plurality of browser-based presentation interfaces, by a display element of the client device (step 306); and establishes a single communication session between the first one and the server system, via a communication element or device of the client device (step 308). Generally, the user executes the browser by selecting a graphical element representing the browser, via a user interface of the client device, wherein the graphical element is presented by the client device. The process 300 presents a browser-based presentation interface comprising a graphical user interface (GUI) associated with the browser application, the GUI configured to present a document or panel that includes website data, text-based elements, graphical elements, user-selectable elements (e.g., menus, hyperlinks), and any other web-based, visually-presented graphic or text element configured to convey website data and/or to receive user input data.

[0040] As described herein, a browser-based presentation interface is generally implemented as a browser window or a browser tab. Browser windows and tabs are well-known and commonly-used presentation interfaces for user interaction with a computer system (e.g., the client device). Browser windows and browser tabs are two-dimensional graphical control elements that include a visual presentation area (i.e., document or panel) surrounded by a frame, wherein the frame generally includes one or more graphical elements for user manipulation to move and resize the window or tab. Browser windows and tabs are typically rectangular in shape, to accommodate a typically shaped display device (e.g., reference 218 of FIG. 2). Browser windows can be moved, expanded to fill an entire display area of a display device (e.g., reference 218 of FIG. 2), resized, hidden and restored, closed, and can overlap (partial overlap or complete overlap) with other browser windows presented by the display device. Browser tabs are similar in form and function to browser windows, but browser tabs provide functionality to allow multiple documents or panels to be included and presented as part of a single browser window, wherein each tab is used as a navigational widget for user-selection to switch between the documents or panels (i.e., switch between the tabs).

[0041] Here, the process 300 receives the user input command to execute the browser application (step 302), executes the browser application and presents a browser-based presentation interface, such as a browser window or a browser tab inside a browser window (steps 304, 306), and establishes a single communication session between the browser window or browser tab and the server system (step 308). As described herein, each browser window tab communicates with one or more servers (e.g., server system 106 of FIG. 1) via a communication session. A communication session is a data transfer thread between the server system and a particular aspect of the client device which receives server-based data via the communication session. Each browser window or browser tab (presented as part of the executed browser application) is an aspect of the client device capable of initiating, maintaining, and using an individually identifiable communication session for transmitting data messages to, and receiving data messages from, the server system. Here, each data message exchanged between the server system and the browser window or browser tab is associated with a session identifier (i.e., a session ID), which differentiates session communications for various communication sessions, thus enabling the server system to communicate with a plurality of aspects of various client devices simultaneously and to keep each communication session separate and distinct.

[0042] After establishing the single communication session between the first browser-based presentation interface (step 308), the process 300 receives one or more additional user input requests to open additional browser-based presentation interfaces, via the user interface of the client device (step 310), and presents the plurality of browser-based presentation interfaces associated with the browser application (step 312). The user input requests to open additional browser-based presentation interfaces may include requests to open additional browser windows, requests to open additional browser tabs in the same browser window, or requests to open a combination of both browser windows and browser tabs. Here, the process 300 receives a user request to present at least a second presentation interface, in addition to the first presentation interface associated with the single communication session, and simultaneously presents the first presentation interface and at least the second presentation interface via the display element (e.g., reference 218 of FIG. 2) of the client device (e.g., reference 102 of FIG. 1, reference 200 of FIG. 2).

[0043] The process 300 then enables communication between the plurality of browser-based presentation interfaces and the server system via the single communication session (step 314), wherein the communication comprises server system data transmissions received by the client device via the single communication session and client device data transmissions transmitted by the client device. Suitable methodologies for enabling communication between a plurality of browser-based presentation interfaces and the server system via the single communication session is described below with regard to FIGS. 4 and 6. Under typical circumstances in prior art solutions, each presentation interface (e.g., browser window or tab) initiates, maintains, and uses a unique communication session associated with a unique communication session identifier to communicate with the server system. However, here the process 300 establishes one and only one communication session between the first presentation interface of the executed browser application (step 308), the process 300 opens one or more secondary presentation interfaces (step 312), and then the process 300 enables the secondary presentation interfaces to use the first communication session to exchange data messages with the server system (step 314). Thus, the process 300 establishes a single, individual communication session between the client device and the server system, and permits the plurality of browser tabs and browser windows to use the same communication session for server communications. Further, the process 300 establishes the one single individual communication session as part of a browser-based, client-side solution that is stored, maintained, executed, and supported by the client device using the browser application. In this scenario, the client device provides the server the ability to support multiple browser windows and/or browser tabs using a single communication thread with the client device.

[0044] After enabling communication between the plurality of browser-based presentation interfaces and the server system via the single communication session (step 314), the process 300 dynamically updates each of the plurality of browser-based presentation interfaces in real-time, by the client device, based on the server system data transmissions and the client device data transmissions (step 316). Each presentation interface is typically updated or changed in some way when a user interacts with the presentation interface via the client device, or when a server communication is received by the client device. However, in the prior art situation where a plurality of browser windows or browser tabs are simultaneously open and each window or tab maintains a separate communication session, the browser window or browser tab in current use (i.e., the active window or tab currently in use by a user) is generally the only browser window or tab that is updated when user interactions or server data transmissions are received by the client device. Here, the process 300 does not limit updates to an active window or tab. Instead, the process 300 dynamically updates all of the open and displayed presentation interfaces when user input client device data and/or server system data transmissions are received. Thus, the process 300 permits all of the open and displayed presentation interfaces to present the same current and updated information.

[0045] FIG. 4 is a flow chart that illustrates an embodiment of a process 400 for communicating with the server system by the client device using a master/slave model for browser-based presentation interfaces, in accordance with the disclosed embodiments. The process 400 described in FIG. 4 represents one embodiment of step 314 described above in the discussion of FIG. 3, including additional detail. It should be noted that FIGS. 4 and 6 are related processes, and processes 400 and 600 detail the functionality of the master presentation interface when used as an “intermediary” to facilitate communications between a slave presentation interface and a server system. Here, FIG. 4 describes the functionality of the master presentation interface to receive slave-broadcasted communications and to provide the slave-broadcasted communications to a server system. FIG. 6 describes the functionality of the master presentation interface to receive server-transmitted communications and to provide the server-based communications to any applicable slave presentation interfaces.

[0046] First, the process 400 establishes an active connection between a master presentation interface and the server system (step 402). The active connection is one single, individual communication session using one single, individual session identifier, for use by more than one presentation interface (e.g., a plurality of browser windows and/or browser tabs presented by the browser application of the client device). The client device uses a master/slave model for browser-based presentation interfaces, wherein the plurality of browser-based presentation interfaces comprises a master presentation interface and a set of slave presentation interfaces. The process 400 establishes the active connection between the master presentation interface and the server system, such that the set of slave presentation interfaces can also communicate with the server system using the active connection, in an indirect way via the master presentation interface.

[0047] The process 400 then receives an update for one of the set of slave presentation interfaces, by the client device (step 404). In this scenario, the update is a user input data transmission to the browser application via the one of the set of slave presentation interfaces, and the update results in a change to the one of the set of slave presentation interfaces. In other words, a browser window or browser tab that is not the “master” (i.e., the browser window or tab does not have an active connection to the server system) receives a user input update. The user input update may be any form of user interaction with the browser window or tab, such as a user selection of a graphical element presented by the browser window or tab, user input text to a data field or messaging/chat interface presented by the browser window or tab, or the like.

[0048] After receiving the update (step 404), the process 400 provides the update from the one of the set of slave presentation interfaces to the master presentation interface via a broadcast pipeline for the browser application (step 406). One suitable methodology for providing an update from a slave presentation interface to a master presentation interface is described below with reference to FIG. 5. The broadcast pipeline is a browser-based, client-side solution enabling presentation interfaces of the browser application to communicate with other presentation interfaces of the browser application. For example, the above-described master presentation interface can communicate with any of the set of slave presentation interfaces using the broadcast pipeline. As another example, any one of the set of slave presentation interfaces can communicate with the master presentation interface using the broadcast pipeline.

[0049] After providing the update to the master presentation interface via the broadcast pipeline (step 406), the process 400 then transmits the update to the server system via the master presentation interface, by the client device (step 408). As described previously, the master presentation interface has established an active connection to the server system (step 402), and there exists only one single, individual communication session between the client device and the server system (see FIG. 3). Here, the slave presentation interface of the browser application has been updated, or in other words, a user has interacted with the browser and provided data input. The slave presentation interface does not have an established communication connection to the server system, because a second communication connection to the server system would be a separate and distinct communication thread associated with a different session identifier, which would require the server system to simultaneously establish and use multiple communication threads. However, instead of requiring the server system to accommodate more than one presentation interface by creating multiple communication threads on the server-side, the process 400 accommodates more than one presentation interface on the client-side by implementing and using the client-side, browser-based solution that includes the master/slave model, as described herein. Thus, using the broadcast pipeline, any one of the slave presentation interfaces is capable of communicating with the server system indirectly, by transmitting and receiving data messages via the master presentation interface that has an active connection to the server system.

[0050] FIG. 5 is a flow chart that illustrates an embodiment of a process 500 for providing an update from one set of slave presentation interfaces to a master presentation interface via a broadcast pipeline, in accordance with the disclosed embodiments. It should be appreciated that the process 500 described in FIG. 5 represents one embodiment of step 406 described above in the discussion of FIG. 4, including additional detail. First, the process 500 writes the update to local storage of a browser application, by the one of the set of slave presentation interfaces, wherein the local storage is accessible to the plurality of browser-based interfaces (step 502). The process 500 then broadcasts a storage change event to the plurality of browser-based presentation interfaces to generate a storage change broadcast, via the local storage by the client device, wherein the storage change event includes the update, and wherein the broadcast pipeline includes the storage change event (step 504). Typically, after a browser tab or browser window writes to local storage of the browser application, the local storage broadcasts a storage change event to all tabs or windows of the browser application. Thus, the process 500 uses the storage event mechanism of the browser application to create a broadcast channel or broadcast pipeline between the open browser-based presentation interfaces (e.g., browser windows, browser tabs).

[0051] The process 500 listens for the storage change broadcast via the master presentation interface, by the client device (step 506). When the presentation interface writes to the local storage, the storage change event is broadcast to all open tabs and windows (i.e., all open presentation interfaces). However, all open tabs and windows of the browser application do not necessarily receive the storage change event data. Instead, particular tabs or windows of the browser application are configured to listen for the storage change event, and to receive the storage change event data from the broadcasting presentation interface. In the example described with regard to FIG. 5, the broadcasting presentation interface is a slave presentation interface that has already received an update comprising a user input data transmission and the listening presentation interface is the master presentation interface. Thus, the process 500 receives a user input data update for the browser application via a slave tab/window, and then the slave tab/window communicates the data update to the master tab/window via the broadcast pipeline to which the master is listening for the data update. The master presentation interface is then able to transmit the update to the server system (see reference 408 of FIG. 4) via the active connection between the master presentation interface and the server system (see reference 402 of FIG. 4).

[0052] FIG. 6 is a flow chart that illustrates a second embodiment of a process 600 for communicating with the server system by the client device using a master/slave model for browser-based presentation interfaces, in accordance with the disclosed embodiments. The process 600 described in FIG. 6 represents one embodiment of step 314 described above in the discussion of FIG. 3, including additional detail. It should be noted that FIGS. 4 and 6 are related processes, and processes 400 and 600 detail the functionality of the master presentation interface when used as an “intermediary” to facilitate communications between a slave presentation interface and a server system. Here, FIG. 6 describes the functionality of the master presentation interface to receive server-transmitted communications and to provide the server-based communications to any applicable slave presentation interfaces. FIG. 4 describes the functionality of the master presentation interface to receive slave-broadcasted communications and to provide the slave-broadcasted communications to the server system.

[0053] First, the process 600 establishes an active connection between the master presentation interface and the server system (step 602). As described previously with regard to FIG. 4, the active connection is one single, individual communication session using one single, individual session identifier, for use by more than one presentation interface (e.g., a plurality of browser windows and/or browser tabs presented by the browser application of the client device). The client device uses a master/slave model for browser-based presentation interfaces, wherein the plurality of browser-based presentation interfaces comprises a master presentation interface and a set of slave presentation interfaces. The process 600 establishes the active connection between the master presentation interface and the server system, such that the set of slave presentation interfaces can also communicate with the server system using the active connection, in an indirect way via the master presentation interface.

[0054] The process 600 then receives an update for one of the set of slave presentation interfaces, by the client device, wherein the update comprises a server-initiated data transmission to the browser application via the master presentation interface, and wherein the update results in a change to the one of the set of slave presentation interfaces (step 604). In this scenario, the update is a server-initiated data transmission to the browser application, which has been provided by the server system, and the update results in a change to the one of the set of slave presentation interfaces. In other words, a “master” browser window or browser tab (i.e., the browser window or tab that has an active connection to the server system) receives a data transmission from the server system. The data transmission is an update for an active slave presentation interface that is currently in use by a user of the client device. The server-transmitted update may be a response to, or the result of, any form of user input interaction with the browser window or tab. For example, a user may select (via user interface of the client device) a graphical element presented by the browser window or tab. As another example, the client device user may provide user input text to a data field of the browser window or tab. As a third example, the client device user may provide input to a messaging or chat interface presented by the browser window or tab.

[0055] After receiving the update (step 604), the process 600 dynamically provides the update from the master presentation interface to the set of slave presentation interfaces via a broadcast pipeline for the browser application (step 606). One suitable methodology for dynamically providing an update from a master presentation interface to a set of slave presentation interfaces is described below with reference to FIG. 7. As described previously with regard to FIG. 4, the broadcast pipeline is a browser-based, client-side solution enabling presentation interfaces of the browser application to communicate with other presentation interfaces of the browser application. For example, the above-described master presentation interface can communicate with any of the set of slave presentation interfaces using the broadcast pipeline. As another example, any one of the set of slave presentation interfaces can communicate with the master presentation interface using the broadcast pipeline. Here, the master presentation interface communicates updates to the set of slave presentation interfaces dynamically and in real-time, as each update is received by the master presentation interface from the server system (described previously with regard to step 604).

[0056] FIG. 7 is a flow chart that illustrates an embodiment of a process 700 for dynamically providing an update from a master presentation interface to a set of slave presentation interfaces via a broadcast pipeline, in accordance with the disclosed embodiments. The process 700 described in FIG. 7 represents one embodiment of step 606 described above in the discussion of FIG. 6, including additional detail.

[0057] First, the process 700 writes the update to local storage of the browser application, by the master presentation interface, wherein the local storage is accessible to the plurality of browser-based interfaces (step 702). The process 700 then broadcasts a storage change event to the plurality of browser-based presentation interfaces to generate a storage change broadcast, via the local storage by the client device, wherein the storage change event includes the update, and wherein the broadcast pipeline includes the storage change event (step 704). As described previously with regard to FIG. 5, typically, after a browser tab or browser window writes to local storage of the browser application, the local storage broadcasts a storage change event to all tabs or windows of the browser application. Thus, the process 700 uses the storage event mechanism of the browser application to create a broadcast channel or broadcast pipeline between the open browser-based presentation interfaces (e.g., browser windows, browser tabs).

[0058] The process 700 listens for the storage change broadcast via the set of slave presentation interfaces, by the client device (step 706). When any of the presentation interfaces writes to the local storage, the storage change event is broadcast to all open tabs and windows (i.e., all open presentation interfaces). However, all open tabs and windows of the browser application do not necessarily receive the storage change event data. Instead, particular tabs or windows of the browser application are configured to listen for the storage change event, and to receive the storage change event data from the broadcasting presentation interface. In the example described with regard to FIG. 7, the broadcasting presentation interface is the master presentation interface that has already received an update comprising a server-initiated data transmission and the listening presentation interfaces are the set of slave presentation interfaces. The process 700 then updates each of the set of slave presentation interfaces, based on the storage change broadcast, via the set of slave presentation interfaces by the client device (step 708). Thus, the process 700 receives a server-initiated data update for the browser application via a master tab/window, and then the master tab/window communicates the data update to the set of slave tabs/windows via the broadcast pipeline to which the set of slave presentation interfaces are listening for the data update. The set of slave presentation interfaces are then updated to present the update via a display element of the client device (see reference 218 of FIG. 2).

[0059] It should be noted that FIGS. 5 and 7 are related processes, and processes 500 and 700 detail the use of the broadcast pipeline of the browser application to communicate between presentation interfaces (e.g., windows, tabs) of the browser application. As described herein, a presentation interface may be a “master” (i.e., a first browser window/tab opened by a user that establishes an active communication session with one or more remote servers) or a “slave” (i.e., a browser window/tab opened by a user after the master tab is opened, and which communicates with the one or more remote servers via the active communication session maintained by the master). Here, FIG. 7 describes the functionality of the master presentation interface that has already received a server-initiated and server-transmitted update for one particular, active slave presentation interface of the browser application, via the active communication session of the master presentation interface. The process 700 describes the steps taken by the master presentation interface to act as an intermediary facilitating communication exchange between the one or more servers, by providing the server communications (i.e., the updates) to the applicable slave presentation interface. Further, the master presentation interface not only provides server-transmitted updates and user input updates to the applicable slave presentation interface, but the master presentation interface also provides the updates (e.g., server-transmitted updates and user input updates) to all open presentation interfaces of the browser application (i.e., all of the slave interfaces associated with the active communication session maintained by the master), such that each of the slave presentation interfaces is dynamically updated in a duplicate manner. Thus, each of the presentation interfaces presents the same updated information, in real-time. FIG. 5 differs from FIG. 7 in the applicable presentation interface using the broadcast pipeline to transmit received data updates to other presentation interfaces of the browser application. FIG. 5 describes the functionality of a slave presentation interface communicating a user input update to the master presentation interface of the browser application, such that the master presentation interface is capable of transmitting the user input update to the one or more servers communicating with the master presentation interface via an active communication session maintained by the master presentation interface.

[0060] FIGS. 8A-8B are flow charts that illustrate an embodiment of a process 800 for exchanging client device communications with a server system, via a browser application configured to support a messaging or “chat” session. The process 800 is one particular embodiment of the process 300 described previously with regard to FIG. 3, wherein the presentation interfaces of the browser application are used by a client device user to participate in a chat session using a messaging widget, icon-based user interface, mini “app” (i.e., application), or other graphical element provided by presentation interfaces associated with the browser application.

[0061] First, the process 800 determines that the browser application has been executed and a first presentation interface has been opened for the browser application (step 802). As described herein a presentation interface is a browser tab or browser window, and during typical operation, the process 800 detects that a user has initiated execution of the browser application via a user interface of the client device and, in response, the client device has executed the browser application and opens and displays the first presentation interface for the browser application.

[0062] The process 800 then creates and stores a master label for the first presentation interface in session storage for the first presentation interface, to indicate status as a master presentation interface (step 804). The browser application provides one or more presentation interfaces for user viewing and interaction. A presentation interface is a graphical user interface (GUI) for user interaction with various websites and other web-based material (e.g., documents, panels, hyperlinks, graphical elements, text, images, data) presented by one or more remotely located servers via the internet and/or via an intranet. The browser application presents at least one presentation interface, but is also is generally configured to permit the user to open additional presentation interfaces (e.g., additional browser tabs and/or additional browser windows) during use. As described herein, the first presentation interface is designated as the “master” presentation interface which establishes an active communication session with the one or more remote servers, wherein the active communication session is associated with a particular identifier. Any additional presentation interfaces opened by the user via the client device, after and in addition to the first presentation interface, are referred to as “slave” presentation interfaces. As described herein, the slave presentation interfaces differ from the master presentation interface in that the slave presentation interfaces do not establish independent communication sessions with the one or more remote servers. Instead, the slave presentation interfaces communicate with the one or more remote servers via the active communication session associated with the master presentation interface. In this way, all presentation interfaces of the browser application communicate with the server using one single, individual browser-based communication session established on the client-side, thereby eliminating any need for multi-threading communications on the server-side.

[0063] The master label is stored in the session storage for the first presentation interface. Session storage is associated with one particular browser tab or browser window, and is accessible only to the one particular browser tab or browser window. Here, the process 800 creates a distinction for the master presentation interface, such that the master can be distinguished from any of the set of slave presentation interfaces associated with the browser application. The master label may be any indication that the first presentation interface is the master presentation interface for the browser application, including a tag, notation, label, flag, variable setting, and/or any other indication which may be stored and maintained in the session storage of the first presentation interface.

[0064] Next, the process 800 determines that an active chat session has been established via the first presentation interface of the browser application, by the client device (step 806). The active chat session may be any messaging-based application or website functionality displayed and provided by the first presentation interface. In this scenario, the active chat session is associated with a particular website currently being accessed by the client device via the first presentation interface.

[0065] The process 800 then determines that a second presentation interface has been opened for the browser application, in response to a user input request received via the first presentation interface (step 808). Here, the process 800 detects that the user has opened another browser tab or browser window, in addition to the currently-open first browser tab or first browser window (i.e., the first presentation interface).

[0066] The process 800 verifies that the second presentation interface is not the master presentation interface due to lack of the master label in second session storage for the second presentation interface (step 810). The process 800 evaluates the data stored in session storage for the second presentation interface, and determines whether a master label is included in the session storage. However, there is one and only one master presentation interface at a time for the browser application. In this scenario, the master label is stored in the session storage for the first presentation interface, indicating that the master presentation interface is the first presentation interface. Here, the process 800 determines that the session storage for the second presentation interface does not include the master label.

[0067] The process 800 also identifies existence of the active chat session for the browser application (step 812). When a chat session or other type of messaging application is activated by the client device (generally in response to a user input request), the process 800 stores an indicator of the active chat session in a local storage for the browser application. The local storage is accessible to all presentation interfaces of the browser application, and thus the active chat sessions indicator is accessible to the process 800 via the second presentation interface.

[0068] Due to the existence of the active chat session, the process 800 uses the broadcast pipeline to request session storage data for presentation interfaces of the browser application, via the second presentation interface, to identify the master presentation interface (step 814). Here, the second presentation interface is a new browser tab or new browser window that has been opened by the client device in response to a user input command. The process 800 is aware that the second presentation interface is not the master presentation interface, and thus, the second presentation interface must be a slave presentation interface that communicates with one or more servers using a master presentation interface as an intermediary. Here, the process 800 requests session storage data from any other presentation interface of the browser application, via the second presentation interface, such that the second presentation interface can identify the master presentation interface.

[0069] The process 800 uses the broadcast pipeline to transmit the session storage for the first presentation interface, via the first presentation interface (step 816). In this example, the process 800 identifies the first presentation interface as the master presentation interface by requesting and receiving the session storage for the first presentation interface, which includes the master label that indicates the status as the master presentation interface. Generally, requesting and receiving the session storage is performed using the broadcast pipeline, which is described previously with regard to FIGS. 4-7. The process 800 receives and copies the session storage for the first presentation interface into the second session storage for the second presentation interface, via the second presentation interface (step 818). The process 800 also identifies a current state of the active chat session (e.g., serialized chat data and communication data) from the received session storage for the first presentation interface (step 820). The session storage for the first presentation interface (i.e., the master presentation interface) includes a master label and a current state of the active chat session that includes serialized chat data and communication connection data for the active communication session with the remote servers. Here, the process 800 copies the session storage for the first presentation interface into the session storage for the second presentation interface, such that the second presentation interface may duplicate and present the same chat session that is currently being presented by the first presentation interface. In this way, both of the first presentation interface and the second presentation interface are capable of displaying the same chat window or messaging application, wherein both of the first presentation interface and the second presentation interface are dynamically updated in real-time.

[0070] Based on the current state of the active chat session and the lack of the master label (wherein the lack indicates that the second presentation interface is not the master) the process 800 skips loading scripts for server communication (step 822). Here, the process 800 configures the chat window or messaging application such that data communication messages are not transmitted to the server system, by intentionally failing to load scripts that enable direct server communication from the slave presentation interface.

[0071] The process 800 updates the second presentation interface to present the current state of the active chat session, based on the received session storage for the first presentation interface, wherein the current state does not include the scripts for server communication (step 824). The current state of the active chat session is the same as the current state of the active chat session displayed by the first presentation interface, and both of the first presentation interface and the second presentation interface are dynamically updated in real-time, such that both presentation interfaces present the same chat data at the same time.

[0072] The process 800 broadcasts any data communications directed to the server system from the active chat session, via the second presentation interface (step 826). The process 800 receives the broadcasted server communications (i.e., communications directed to the server from the second presentation interface) from the active chat session, via the master presentation interface (step 828). In this scenario, the first presentation interface is the master presentation interface, which is indicated by the existence of the master label in the session storage of the first presentation interface, as described previously with regard to step 804. The process 800 transmits the broadcasted server communications from the active chat session to the one or more servers with an active communication connection to the first presentation interface, via the master presentation interface (step 830). As described previously, in this scenario the first presentation interface is the master presentation interface, which is indicated by the existence of the master label in the session storage of the first presentation interface. During the active chat session, the process 800 receives data communications from the server system via the master presentation interface that has an active communication session with the one or more servers, and the process 800 provides the received data communications originating from the server system to the slave presentation interface that is active and in current use for the chat application. The received communications are provided by the master presentation interface using the broadcast pipeline. Further, during the active chat session, the process 800 transmits data communications from the active chat session to the server system by broadcasting the data communications to the master presentation interface, and the master presentation interface proceeds to transmit the data communications from the active chat session to the server system.

[0073] When the active chat session ends and the second presentation interface is closed, the process 800 clears the local storage (which is used to exchange communications between presentation interfaces of the browser application via the broadcast pipeline) and clears the master label in the session storage for the first presentation interface (step 832).

[0074] The various tasks performed in connection with processes 300-800 may be performed by software, hardware, firmware, or any combination thereof. For illustrative purposes, the preceding descriptions of processes 300-800 may refer to elements mentioned above in connection with FIGS. 1-2. In practice, portions of processes 300-800 may be performed by different elements of the described system. It should be appreciated that processes 300-800 may include any number of additional or alternative tasks, the tasks shown in FIGS. 3-8 need not be performed in the illustrated order, and processes 300-800 may be incorporated into a more comprehensive procedure or process having additional functionality not described in detail herein. Moreover, one or more of the tasks shown in FIGS. 3-8 could be omitted from embodiments of processes 300-800 as long as the intended overall functionality remains intact.

[0075] FIG. 9 is a block diagram of an exemplary multi-tenant database system 900 suitable for use with the system 100 of FIG. 1, in accordance with the disclosed embodiments. The illustrated multi-tenant database system 900 of FIG. 9 includes a server 902 (e.g., server system 106) that dynamically creates and supports virtual applications 928 based upon data 932 from a common database 930 that is shared between multiple tenants, alternatively referred to herein as a multi-tenant database. Data and services generated by the virtual applications 928 are provided via a network 945 (e.g., data communication network 108) to any number of client devices 940 (e.g., client device 102, or the like), as desired. Each virtual application 928 is suitably generated at run-time (or on-demand) using a common application platform 910 that securely provides access to the data 932 in the database 930 for each of the various tenants subscribing to the multi-tenant system 900. In accordance with one non-limiting example, the multi-tenant system 900 is implemented in the form of an on-demand multi-tenant customer relationship management (CRM) system that can support any number of authenticated users of multiple tenants.

[0076] As used herein, a “tenant” or an “organization” should be understood as referring to a group of one or more users that shares access to common subset of the data within the multi-tenant database 930. In this regard, each tenant includes one or more users associated with, assigned to, or otherwise belonging to that respective tenant. To put it another way, each respective user within the multi-tenant system 900 is associated with, assigned to, or otherwise belongs to a particular tenant of the plurality of tenants supported by the multi-tenant system 900. Tenants may represent customers, customer departments, business or legal organizations, and/or any other entities that maintain data for particular sets of users within the multi-tenant system 900 (i.e., in the multi-tenant database 930). For example, the application server 902 may be associated with one or more tenants supported by the multi-tenant system 900. Although multiple tenants may share access to the server 902 and the database 930, the particular data and services provided from the server 902 to each tenant can be securely isolated from those provided to other tenants (e.g., by restricting other tenants from accessing a particular tenant's data using that tenant's unique organization identifier as a filtering criterion). The multi-tenant architecture therefore allows different sets of users to share functionality and hardware resources without necessarily sharing any of the data 932 belonging to or otherwise associated with other tenants.

[0077] The multi-tenant database 930 is any sort of repository or other data storage system capable of storing and managing the data 932 associated with any number of tenants. The database 930 may be implemented using any type of conventional database server hardware. In various embodiments, the database 930 shares processing hardware 904 with the server 902. In other embodiments, the database 930 is implemented using separate physical and/or virtual database server hardware that communicates with the server 902 to perform the various functions described herein. In an exemplary embodiment, the database 930 includes a database management system or other equivalent software capable of determining an optimal query plan for retrieving and providing a particular subset of the data 932 to an instance of virtual application 928 in response to a query initiated or otherwise provided by a virtual application 928. The multi-tenant database 930 may alternatively be referred to herein as an on-demand database, in that the multi-tenant database 930 provides (or is available to provide) data at run-time to on-demand virtual applications 928 generated by the application platform 910.

[0078] In practice, the data 932 may be organized and formatted in any manner to support the application platform 910. In various embodiments, the data 932 is suitably organized into a relatively small number of large data tables to maintain a semi-amorphous “heap”-type format. The data 932 can then be organized as needed for a particular virtual application 928. In various embodiments, conventional data relationships are established using any number of pivot tables 934 that establish indexing, uniqueness, relationships between entities, and/or other aspects of conventional database organization as desired. Further data manipulation and report formatting is generally performed at run-time using a variety of metadata constructs. Metadata within a universal data directory (UDD) 936, for example, can be used to describe any number of forms, reports, workflows, user access privileges, business logic and other constructs that are common to multiple tenants. Tenant-specific formatting, functions and other constructs may be maintained as tenant-specific metadata 938 for each tenant, as desired. Rather than forcing the data 932 into an inflexible global structure that is common to all tenants and applications, the database 930 is organized to be relatively amorphous, with the pivot tables 934 and the metadata 938 providing additional structure on an as-needed basis. To that end, the application platform 910 suitably uses the pivot tables 934 and/or the metadata 938 to generate “virtual” components of the virtual applications 928 to logically obtain, process, and present the relatively amorphous data 932 from the database 930.

[0079] The server 902 is implemented using one or more actual and/or virtual computing systems that collectively provide the dynamic application platform 910 for generating the virtual applications 928. For example, the server 902 may be implemented using a cluster of actual and/or virtual servers operating in conjunction with each other, typically in association with conventional network communications, cluster management, load balancing and other features as appropriate. The server 902 operates with any sort of conventional processing hardware 904, such as a processor 905, memory 906, input/output features 907 and the like. The input/output features 907 generally represent the interface(s) to networks (e.g., to the network 945, or any other local area, wide area or other network), mass storage, display devices, data entry devices and/or the like. The processor 905 may be implemented using any suitable processing system, such as one or more processors, controllers, microprocessors, microcontrollers, processing cores and/or other computing resources spread across any number of distributed or integrated systems, including any number of “cloud-based” or other virtual systems. The memory 906 represents any non-transitory short or long term storage or other computer-readable media capable of storing programming instructions for execution on the processor 905, including any sort of random access memory (RAM), read only memory (ROM), flash memory, magnetic or optical mass storage, and/or the like. The computer-executable programming instructions, when read and executed by the server 902 and/or processor 905, cause the server 902 and/or processor 905 to create, generate, or otherwise facilitate the application platform 910 and/or virtual applications 928 and perform one or more additional tasks, operations, functions, and/or processes described herein. It should be noted that the memory 906 represents one suitable implementation of such computer-readable media, and alternatively or additionally, the server 902 could receive and cooperate with external computer-readable media that is realized as a portable or mobile component or application platform, e.g., a portable hard drive, a USB flash drive, an optical disc, or the like.

[0080] The application platform 910 is any sort of software application or other data processing engine that generates the virtual applications 928 that provide data and/or services to the client devices 940. In a typical embodiment, the application platform 910 gains access to processing resources, communications interfaces and other features of the processing hardware 904 using any sort of conventional or proprietary operating system 908. The virtual applications 928 are typically generated at run-time in response to input received from the client devices 940. For the illustrated embodiment, the application platform 910 includes a bulk data processing engine 912, a query generator 914, a search engine 916 that provides text indexing and other search functionality, and a runtime application generator 920. Each of these features may be implemented as a separate process or other module, and many equivalent embodiments could include different and/or additional features, components or other modules as desired.

[0081] The runtime application generator 920 dynamically builds and executes the virtual applications 928 in response to specific requests received from the client devices 940. The virtual applications 928 are typically constructed in accordance with the tenant-specific metadata 938, which describes the particular tables, reports, interfaces and/or other features of the particular application 928. In various embodiments, each virtual application 928 generates dynamic web content that can be served to a browser or other client program 942 associated with its client device 940, as appropriate.

[0082] The runtime application generator 920 suitably interacts with the query generator 914 to efficiently obtain multi-tenant data 932 from the database 930 as needed in response to input queries initiated or otherwise provided by users of the client devices 940. In a typical embodiment, the query generator 914 considers the identity of the user requesting a particular function (along with the user's associated tenant), and then builds and executes queries to the database 930 using system-wide metadata 936, tenant specific metadata 938, pivot tables 934, and/or any other available resources. The query generator 914 in this example therefore maintains security of the common database 930 by ensuring that queries are consistent with access privileges granted to the user and/or tenant that initiated the request. In this manner, the query generator 914 suitably obtains requested subsets of data 932 accessible to a user and/or tenant from the database 930 as needed to populate the tables, reports or other features of the particular virtual application 928 for that user and/or tenant.

[0083] Each database 930 can generally be viewed as a collection of objects, such as a set of logical tables, containing data fitted into predefined categories. A “table” is one representation of a data object, and may be used herein to simplify the conceptual description of objects and custom objects. It should be understood that “table” and “object” may be used interchangeably herein. Each table generally contains one or more data categories logically arranged as columns or fields in a viewable schema. Each row or record of a table contains an instance of data for each category defined by the fields. For example, a CRM database may include a table that describes a customer with fields for basic contact information such as name, address, phone number, fax number, etc. Another table might describe a purchase order, including fields for information such as customer, product, sale price, date, etc. In some multi-tenant database systems 900, standard entity tables might be provided for use by all tenants. For CRM database applications, such standard entities might include tables for Account, Contact, Lead, and Opportunity data, each containing pre-defined fields. It should be understood that the word “entity” may also be used interchangeably herein with “object” and “table.”

[0084] In some multi-tenant database systems 900, tenants may be allowed to create and store custom objects, or they may be allowed to customize standard entities or objects, for example by creating custom fields for standard objects, including custom index fields. U.S. Pat. No. 7,779,039, filed Apr. 2, 2004, entitled “Custom Entities and Fields in a Multi-Tenant Database System”, which is hereby incorporated herein by reference, teaches systems and methods for creating custom objects as well as customizing standard objects in a multi-tenant database system 900. In certain embodiments, for example, all custom entity data rows are stored in a single multi-tenant physical table, which may contain multiple logical tables per organization. It is transparent to customers that their multiple “tables” are in fact stored in one large table or that their data may be stored in the same table as the data of other customers.

[0085] Still referring to FIG. 9, the data processing engine 912 performs bulk processing operations on the data 932 such as uploads or downloads, updates, online transaction processing, and/or the like. In many embodiments, less urgent bulk processing of the data 932 can be scheduled to occur as processing resources become available, thereby giving priority to more urgent data processing by the query generator 914, the search engine 916, the virtual applications 928, etc.

[0086] In exemplary embodiments, the application platform 910 is utilized to create and/or generate data-driven virtual applications 928 for the tenants that they support. Such virtual applications 928 may make use of interface features such as custom (or tenant-specific) screens 924, standard (or universal) screens 922 or the like. Any number of custom and/or standard objects 926 may also be available for integration into tenant-developed virtual applications 928. As used herein, “custom” should be understood as meaning that a respective object or application is tenant-specific (e.g., only available to users associated with a particular tenant in the multi-tenant system) or user-specific (e.g., only available to a particular subset of users within the multi-tenant system), whereas “standard” or “universal” applications or objects are available across multiple tenants in the multi-tenant system. For example, a virtual CRM application may utilize standard objects 926 such as “account” objects, “opportunity” objects, “contact” objects, or the like. The data 932 associated with each virtual application 928 is provided to the database 930, as appropriate, and stored until it is requested or is otherwise needed, along with the metadata 938 that describes the particular features (e.g., reports, tables, functions, objects, fields, formulas, code, etc.) of that particular virtual application 928. For example, a virtual application 928 may include a number of objects 926 accessible to a tenant, wherein for each object 926 accessible to the tenant, information pertaining to its object type along with values for various fields associated with that respective object type are maintained as metadata 938 in the database 930. In this regard, the object type defines the structure (e.g., the formatting, functions and other constructs) of each respective object 926 and the various fields associated therewith.

[0087] Still referring to FIG. 9, the data and services provided by the server 902 can be retrieved using any sort of personal computer, mobile telephone, tablet or other network-enabled client device 940 on the network 945. In an exemplary embodiment, the client device 940 includes a display device, such as a monitor, screen, or another conventional electronic display capable of graphically presenting data and/or information retrieved from the multi-tenant database 930. Typically, the user operates a conventional browser application or other client program 942 executed by the client device 940 to contact the server 902 via the network 945 using a networking protocol, such as the hypertext transport protocol (HTTP) or the like. The user typically authenticates his or her identity to the server 902 to obtain a session identifier (“SessionID”) that identifies the user in subsequent communications with the server 902. When the identified user requests access to a virtual application 928, the runtime application generator 920 suitably creates the application at run time based upon the metadata 938, as appropriate. As noted above, the virtual application 928 may contain Java, ActiveX, or other content that can be presented using conventional client software running on the client device 940; other embodiments may simply provide dynamic web or other content that can be presented and viewed by the user, as desired.

[0088] Techniques and technologies may be described herein in terms of functional and/or logical block components, and with reference to symbolic representations of operations, processing tasks, and functions that may be performed by various computing components or devices. Such operations, tasks, and functions are sometimes referred to as being computer-executed, computerized, software-implemented, or computer-implemented. In practice, one or more processor devices can carry out the described operations, tasks, and functions by manipulating electrical signals representing data bits at memory locations in the system memory, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to the data bits. It should be appreciated that the various block components shown in the figures may be realized by any number of hardware, software, and/or firmware components configured to perform the specified functions. For example, an embodiment of a system or a component may employ various integrated circuit components, e.g., memory elements, digital signal processing elements, logic elements, look-up tables, or the like, which may carry out a variety of functions under the control of one or more microprocessors or other control devices.

[0089] When implemented in software or firmware, various elements of the systems described herein are essentially the code segments or instructions that perform the various tasks. The program or code segments can be stored in a processor-readable medium or transmitted by a computer data signal embodied in a carrier wave over a transmission medium or communication path. The “computer-readable medium”, “processor-readable medium”, or “machine-readable medium” may include any medium that can store or transfer information. Examples of the processor-readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory, an erasable ROM (EROM), a floppy diskette, a CD-ROM, an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, or the like. The computer data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic paths, or RF links. The code segments may be downloaded via computer networks such as the Internet, an intranet, a LAN, or the like.

[0090] The preceding description refers to elements or nodes or features being “connected” or “coupled” together. As used herein, unless expressly stated otherwise, “coupled” means that one element/node/feature is directly or indirectly joined to (or directly or indirectly communicates with) another element/node/feature, and not necessarily mechanically. Likewise, unless expressly stated otherwise, “connected” means that one element/node/feature is directly joined to (or directly communicates with) another element/node/feature, and not necessarily mechanically. Thus, although the schematic shown in FIG. 2 depicts one exemplary arrangement of elements, additional intervening elements, devices, features, or components may be present in an embodiment of the depicted subject matter.

[0091] For the sake of brevity, conventional techniques related to signal processing, data transmission, signaling, network control, and other functional aspects of the systems (and the individual operating components of the systems) may not be described in detail herein. Furthermore, the connecting lines shown in the various figures contained herein are intended to represent exemplary functional relationships and/or physical couplings between the various elements. It should be noted that many alternative or additional functional relationships or physical connections may be present in an embodiment of the subject matter.

[0092] Some of the functional units described in this specification have been referred to as “modules” in order to more particularly emphasize their implementation independence. For example, functionality referred to herein as a module may be implemented wholly, or partially, as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical modules of computer instructions that may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations that, when joined logically together, comprise the module and achieve the stated purpose for the module. A module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.

[0093] While at least one exemplary embodiment has been presented in the foregoing detailed description, it should be appreciated that a vast number of variations exist. It should also be appreciated that the exemplary embodiment or embodiments described herein are not intended to limit the scope, applicability, or configuration of the claimed subject matter in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing the described embodiment or embodiments. It should be understood that various changes can be made in the function and arrangement of elements without departing from the scope defined by the claims, which includes known equivalents and foreseeable equivalents at the time of filing this patent application.