HK1156761B - Systems and methods for remoting multimedia plugin calls - Google Patents

Description

Method and system for remote processing multimedia plug-in call

RELATED APPLICATIONS

This patent application claims priority from U.S. provisional patent application No. 61/054325, filed on 19.5.2008, the disclosure of which is to be considered part of the disclosure of this application and is incorporated herein by reference in its entirety.

Technical Field

The present invention relates generally to providing remote access to computing resources. In particular, the present application relates to systems and methods for providing remote access to or enabling remote execution of multimedia plug-ins.

Background

Some remote presentation systems execute applications on a centrally located host server and send graphical or audio outputs of those applications to remotely located client devices. For many applications, such as word processors, the consumption of server resources is relatively low. This can result in a relatively small load on the CPU of the server and a low level of network traffic generated by the application. Such applications may be hosted on a single server, since they do not incur significant performance degradation by requiring a large amount of network bandwidth or server processing performance (such as a large number of server CPU cycles). However, applications that handle large media files (such as video, animation, or audio applications) consume significantly more resources and bandwidth, resulting in delays and degradation of the user experience.

Some systems provide remote access to a graphics plug-in between a server and a client by reducing graphics output. Other remote presentation systems relocate the rendering of the video from the server machine to the client machine. However, these systems cannot be used to provide remote access to graphical plug-ins and applications that share complex interfaces. Such systems also cannot be used to enable remote execution of plug-ins that execute graphical content. Other systems provide remote access to applications that are streamed or shared between machines, but do not remotely access applications that are designed to execute entirely on a single machine.

There is a need to enable users of remote access systems that are not designed to be remotely accessed or controlled on a centrally located hosting server and that do not impair the user experience, the quality of the graphical output, or severely impair the scalability of the server to run resource demanding applications.

Disclosure of Invention

Broadly speaking, the methods and systems described herein are embodiments of methods and systems for remotely processing multimedia plugins. There are many applications or plug-ins that are resource intensive and therefore use a significant amount of computing resources when they are executed. Servers hosting applications that users remotely access through clients may have to execute many examples of these resource-intensive applications that impair the performance of the servers and consume large amounts of bandwidth when remotely provided to the client machines. There is a need for a method and system to remotely provide access to these resource-intensive applications without using the resources of a large number of servers. The methods and systems described herein provide for remotely providing multimedia plugin calls to a substantially similar multimedia plugin executing on a client. Remote processing of calls to plug-ins executing on clients eliminates the need for plug-ins to execute on servers, thereby providing plug-in content to clients while reducing stress on server resources.

In one example, an embodiment of a method for remotely handling multimedia plugin calls from a server to a client is described herein. A proxy multimedia plugin executing on the server and corresponding to the multimedia plugin executing on the client intercepts a call issued by a container application executing on the server. The published call requests content from the multimedia plugin. The proxy multimedia plugin determines whether the proxy multimedia plugin is capable of responding to the call, and in response to a determination that the proxy multimedia plugin is not capable of responding to the call, communicates the call to a multimedia plugin executing on the client. The multimedia plugin on the client responds to the call by generating and displaying graphical content.

In one embodiment, the method includes a delivery application executing on the server communicating the call from the server to the client. In another embodiment, the call is transmitted from the server to a proxy container application executing on the client. The proxy container application, upon receiving the call, may publish the call to a multimedia plugin executing on the client.

In some embodiments, displaying the graphical content may include displaying the graphical content in a plug-in window on the client.

In some embodiments, requesting content from a multimedia plugin may include requesting access to a multimedia plugin interface in the multimedia plugin.

In some embodiments, the method includes transmitting the call or any request over a virtual channel between the server and the client via a presentation layer protocol. In other embodiments, determining that the proxy multimedia plugin is capable of responding to the call may result in the proxy multimedia plugin responding to the container application call with the requested content. In some embodiments, the requested content may include content stored in a cache on the server.

In other embodiments, the proxy container application may intercept a call issued by the multimedia plugin, where the call requests content from the container application. The proxy container application may determine that the proxy container application is capable of responding to the published call, and the proxy container application may respond to the multimedia plugin call with the requested content. In some embodiments, the requested content includes content stored in a cache on the client.

In some embodiments, the multimedia plug-in may generate multimedia content. In other embodiments, the multimedia plugin displays multimedia content. In some embodiments, the multimedia plugin may be a control, while in other embodiments, the proxy multimedia plugin is a proxy control.

In one embodiment, a proxy multimedia plugin obtains window data associated with the proxy multimedia plugin and transmits the window data to the multimedia plugin on the client. The multimedia plugin then receives the transmitted window data and changes at least one interface between the multimedia plugin and the proxy container based on the received window data.

In some embodiments, the proxy multimedia plugin obtains a script interface generated by a script in the container application and transmits the script interface to the proxy container application. In other embodiments, the proxy container application obtains a script interface generated by a script in the multimedia plugin and communicates the script interface to the proxy multimedia plugin. In some embodiments, intercepting the call includes intercepting the call for the scripting interface.

In one embodiment, the multimedia plugin accesses the network resource via a browser application executing on the client and downloads the accessed network resource to the multimedia plugin.

In other embodiments, a request for a network resource generated by a multimedia plugin is intercepted and redirected to a server over a virtual channel between a client and the server via a presentation layer protocol. The requested resource from the server is received and forwarded to the multimedia plugin.

In some aspects, the processes and methods described above may be performed by a computer readable medium having instructions executable by a processor to perform the above-described methods.

In other aspects, a system for remotely handling multimedia plugin calls from a server to a client is described herein. The system includes a server executing a container application and a proxy multimedia plugin corresponding to a multimedia plugin executing on a client. The proxy multimedia plugin may: intercepting a call issued by a container application, the call requesting content from a multimedia plugin; determining whether the proxy multimedia plugin is capable of responding to the call; the call is communicated to the multimedia plugin in response to a determination that the proxy multimedia plugin cannot respond to the call. The multimedia plugin may receive the call and generate graphical content in response to receiving the call. The multimedia plugin can also display graphical content.

Drawings

The following figures depict certain exemplary embodiments of the methods and systems described herein, wherein like reference numerals refer to like parts. These described embodiments are to be understood as illustrative illustrations of the described methods and systems and are not intended to be limiting in any way.

FIG. 1A depicts an embodiment of a network environment that provides remote access to computing devices that may execute applications;

FIGS. 1B and 1C depict embodiments of a computing device;

FIG. 1D shows a block diagram depicting an embodiment of a server farm;

FIG. 2 shows a block diagram depicting an embodiment of a system for remotely processing multimedia plugin calls;

FIG. 3A shows a flow chart describing an embodiment of a process for remotely invoking a multimedia plugin;

FIG. 3B depicts a flow chart describing an embodiment of a process for responding to a remote call for a multimedia plugin;

FIG. 4 shows a flow chart describing an embodiment of a process for responding to a call;

FIG. 5 depicts a flow diagram that describes an embodiment of a process that allows calls to plug-ins to be processed remotely;

FIG. 6 depicts a flow chart describing an embodiment of a process for obtaining and remotely providing add-in window data;

FIG. 7 depicts a flow chart describing an embodiment of a process for remotely providing a scripting interface;

figure 8 shows a flow chart describing an embodiment of a process for acquiring network resources.

Detailed Description

FIG. 1A illustrates one embodiment of a computing environment 101 that includes one or more client machines 102A-102N in communication with servers 106A-106N, and a network 104 installed between the client machines 102A-102N and the servers 106A-106N. In some embodiments, the client machines 102A-102N may be referred to as a single client machine 102 or a single group of client machines 102, while the servers may be referred to as a single server 106 or a single group of servers 106. One embodiment includes a single client machine 102 in communication with more than one server 106, another embodiment includes a single server 106 in communication with more than one client machine 102, and another embodiment includes a single client machine 102 in communication with a single server 106.

In some embodiments, the client machine 102 in the computing environment refers to any of the following terminology: a client machine 102, a client computer, a client device, a client computing device, a local machine, a remote machine, a client node, an endpoint node, or a second machine. In some embodiments, the server 106 may be referred to by any of the following terminology: a server, a local machine, a remote machine, a server farm, a host computing device, or a first machine.

In some embodiments, the client machine 102 may execute, operate, or otherwise provide an application, which may be any of the following: software; carrying out a procedure; executable instructions; a web browser, web-based client; a client-server application; a computing client of the thin-client; an ActiveX control; or a Java applet; software related to voice over internet protocol (VoIP) communications, such as soft IP phones; applications that stream video and/or audio; facilitating applications of real-time data communications; an HTTP client; an FTP client; an Oscar client; a Telnet client; or any other type and/or form of executable instructions that may be executed on the client machine 102. In other embodiments, a computing environment 101 may be included having server-based or remote-based applications and applications executing on the server 106 on behalf of the client machine 102. Further, additional embodiments of the computing environment 101 include a server 106 configured to display output graphics data to the client machine 102 using a thin-client or remote display protocol, wherein the protocol used may be any of the following: independent Computing Architecture (ICA) protocol, available from Citrix Systems, located in ft, lauderdale, Florida, or Remote Desktop Protocol (RDP), available from microsoft, located in Redmond, Washington.

In one embodiment, the client machine 102 may be a virtual machine 102C, such as those available from Xensoluutions, Citrix systems, IBM, VMware, or any other virtual machine that can perform the methods and systems described herein.

In some embodiments, the computing environment 101 may include more than one server 106A-106N, where the servers 106A-106N: grouped together as a single server 106 entity; logically combined together in the server farm 106; geographically dispersed and logically combined together in the server farm 106; located close to each other in the server farm 106 and logically combined together. In some embodiments, the geographically dispersed servers 106A-106N in the server farm 106 may communicate using a WAN, MAN, or LAN, where the different geographic regions are characterized by: different continents, different areas of the same continent, different countries, different states, different cities, different campuses, different rooms, or any combination of the foregoing geographic locations. In some embodiments, the server farm 106 may be managed as a single entity or in other embodiments may include multiple server farms 106. The computing environment 101 may include more than one server 106A-106N grouped together in a single server farm 106, where the server farms 106 are heterogeneous such that one server 106A-106N may operate according to a first type of operating system platform (e.g., WINDOWS NT, available from MICROSOFT CORPORATION of Redmond, Washington), while one or more other servers 106A-106N may operate according to a second type of operating system platform (e.g., Unix or Linux); more than one server 106A-106N may be configured to operate according to a first type of operating system platform (e.g., WINDOWSNT), while another server 106A-106N is configured to operate according to a second type of operating system platform (e.g., Unix or Linux); or more than one server 106A-106N may be configured to operate according to a first type of operating system platform (e.g., WINDOWS NT), while more than one other server 106A-106N is configured to operate according to a second type of operating system platform (e.g., Unix or Linux).

In some embodiments, the computing environment 101 may include one server 106 or multiple servers 106 to provide functionality for any of the following server types: a file server, an application server, a web server, a proxy server, a device, a network device, a gateway, an application gateway, a gateway server, a virtual server, a deployment server, an SSL VPN server, a firewall, a web server, an application server, or as a master application server; a server 106 configured to act as an active directory; a server 106 configured to function as an application acceleration application that provides firewall functionality, application functionality, or load balancing functionality; or other type of computing machine configured to function as a server 106. In some embodiments, the server 106 may include a remote authentication dial-in user service such that the server 106 is a RADIUS server. In embodiments of the computing environment 101 in which the server 106 comprises a device, the server 106 may be a device manufactured by any one of the following companies: citrix applied networks, Silver Peak System, Riverbed technologies, F5 networks or Juniper networks. Some embodiments include a server 106 with the following functionality: the first server 106A receives the request from the client machine 102, forwards the request to the second server 106B, and responds to the client machine-generated request with a response from the second server 106B; obtaining an enumeration of applications available to the client machine 102 and address information associated with the server 106, the server 106 hosting the applications identified by the enumeration of applications; presenting the response to the client request using the web interface; communicate directly with the client 102 to provide the client 102 with access to the identified application; output data, such as display data, is received, the output data being generated by executing the application identified on the server 106.

The server 106 may be configured to execute any of the following applications: an application providing a thin-client computer or a remote display PRESENTATION application, any part of Citrix ACCESS SUITE from Citrix Systems, such as METAFRAME or Citrix PRESENTATION SERVER, MICROSOFT WINDOWS end services from MICROSOFT, or an ICA client developed by Citrix Systems. Another embodiment includes a server 106 configured to run an application such that the server can function as an application server of any application server type, such as: an email server providing an email service such as MICROSOFT EXCHANGE available from MICROSOFT corporation, a web or Internet server, a desktop sharing server, or a collaboration server. Other embodiments include a server 106 executing any of the following types of hosted server applications: GOTOMEETING available from CitrixOnline Division, WebEx corporation located in santa clara, California, or Microsoft Office LIVE MEETING available from Microsoft corporation.

In one embodiment, the server 106 may be a virtual machine 106B, such as those available from Citrix systems, IBM, VMware, or any other virtual machine that may perform the methods and systems described herein.

In some embodiments, a client machine 102 may function as a client node seeking access to a resource provided by a server 106, or as a server 106 providing access to hosted resources by other clients 102A-102N. One embodiment of the computing environment 101 includes a server 106 that provides the functionality of a master node. Communication between the client machine 102 and the server 106 or servers 106A-106N may be established via the following methods: direct communication between the client machine 102 and the servers 106A-106N in the server farm 106; the client machine 102 uses the program neighborhood application to communicate with the servers 106a-106n in the server farm 106; or the client machine 102 communicates with the servers 106A-106N in the server farm 106 using the network 104. One embodiment of the computing environment 101 includes a client machine 102 that uses a network 104 to request execution of an application hosted by a server 106A-106N in a server farm 106, and uses the network 104 to receive graphical display output from the server 106A-106N that represents the execution of the application. In other embodiments, the master node provides the required functionality to identify and provide address information associated with the server 106 hosting the requested application. Other embodiments include a master node that may be any of the following: servers 106A-106N in the server farm 106 connected to the server farm 106 but not including remote computing machines in the server farm 106; a remote computing machine connected to the client machine 102 but not included in the group of client machines 102, or the client machine 102.

The network 104 between the client machine 102 and the server 106 is the connection over which data is transferred between the client machine 102 and the server 106. Although a network 104 connecting client machines 102 to a server 106 is depicted in FIG. 1A, other embodiments include a computing environment 101 having client machines 102 installed on the same network as the server 106. Other embodiments include a computing environment 101 having a network 104 that may be any of: local Area Networks (LANs), Metropolitan Area Networks (MANs), Wide Area Networks (WANs); a primary network 104 comprising a plurality of sub-networks 104' located between the client machine 102 and the server 106; a primary public network 104 having a private subnet 104'; a primary private network 104 having a public subnet 104'; or a primary private network 104 with a private subnet 104'. Other embodiments include network 104 which may be any of the following types of networks: a point-to-point network, a broadcast network, a telecommunications network, a data communications network, a computer network, an ATM (asynchronous transfer mode) network, a SONET (synchronous optical network) network, an SDH (synchronous digital hierarchy) network, a wireless network, a wired network, a network 104 comprising wireless links, which may be infrared channels or satellite frequency bands, or any other network type that can transport data from a client machine 102 to a server 106 or back to implement the methods and systems described herein. The network topology may be different in various embodiments, and possible network topologies include: a bus type network topology, a star network topology, a ring network topology, a repeater-based network topology, a hierarchical star network topology, or any other network topology in which data may be transferred from a client machine 102 to a server 106 or back to implement the methods and systems described herein. Additional embodiments may include a network 104 of mobile phone networks that communicate between mobile devices using any of the following protocols: AMPS, TDMA, CDMA, GSM, GPRS UMTS, or any other protocol capable of transferring data between mobile devices to implement the methods and systems described herein.

An embodiment of a computing device 100 is shown in FIG. 1B, wherein the client machine 102 and server 106 shown in FIG. 1A may be arranged as, and/or execute on, any of the embodiments of the computing device 100 illustrated and described herein. Included in the computing device 100 is a system bus 150 that communicates with the following components: a central processing unit 121; a main memory 122; a storage device 128; an input/output (I/O) controller 123; display devices 124A-124N; a mounting device 116; and a network interface 118. In one embodiment, the storage 128 includes an operating system, software routines, and a client agent 120. In some embodiments, the I/O controller 123 also connects a keyboard 126 and a pointing device 127. Other embodiments may include an I/O controller 123, the I/O controller 123 coupled to a plurality of input/output devices 130A-130N.

One embodiment of a computing device 100 is shown in FIG. 1C, wherein the client machine 102 and server 106 shown in FIG. 1A may be arranged and/or executed on any of the embodiments of the computing device 100 illustrated and described herein. Included in the computing device 100 is a system bus 150 that communicates with the following components: a bridge 170 and a first I/O device 130A. In another embodiment, the bridge 170 is also in communication with the central processing unit 121, wherein the central processing unit 121 is also in communication with the second I/O device 130B, the main memory 122, and the cache 140. The central processing unit 121 includes I/O ports, a memory port 103, and a main processor.

Embodiments of the computing machine 100 may include a central processing unit 121 characterized by any of the following configurations of components: logic circuitry to respond to and process instructions fetched from main memory unit 122; such as those available from Intel corporation, Motorola corporation, and Transmeta corporation, Santa Clara, California; such as RS/6000 processors available from International Business machines corporation; such as processors available from Advanced Micro Devices, Inc.; or any other combination of logic circuits capable of executing the methods and systems described herein. Other embodiments of the central processing unit 122 may include any combination of the following: a microprocessor, a microcontroller, a central processing unit with a single processing core, a central processing unit with dual processing cores, or a central processing unit with multiple processing cores.

One embodiment of the computing machine 100 includes a central processing unit 121 that communicates with the cache memory 140 via a secondary bus, referred to as a back side bus, while other embodiments of the computing machine 100 include a central processing unit 121 that communicates with the cache memory via a system bus 150. In some embodiments, the central processing unit may also use the local system bus 150 to communicate with multiple types of I/O devices 130A-130N. In some embodiments, the local system bus 150 may be any of the following types of buses: VESA VL bus, ISA bus, EISA bus, Micro Channel Architecture (MCA) bus, PCI-X bus, PCI-Express bus, or NuBus. Other embodiments of the computing machine 100 include I/O devices 130A-130N, which are video displays 124, that can communicate with the central processing unit 121 via an Advanced Graphics Port (AGP). Other versions of the computing machine 100 include a processor 121 connected to the I/O devices 130A-130N via any of the following connections: HyperTransport, Rapid I/O, or InfiniBand. Other embodiments of the computing machine 100 include communication connections in which the processor 121 communicates with one I/O device 130A using a local interconnect bus and communicates with a second I/O device 130B over a direct connection.

Some embodiments of the computing device 100 include each of the main storage unit 122 and the cache 140. In some embodiments, cache 140 may be any type of memory: SRAM, BSRAM, or EDRAM. Other embodiments include cache 140 and main memory unit 122, which may be any type of memory: static Random Access Memory (SRAM), burst SRAM, or synchronous burst SRAM (bsram), Dynamic Random Access Memory (DRAM), fast page mode DRAM (fpm DRAM), enhanced DRAM (edram), extended data output ram (edo ram), extended data output DRAM (edo DRAM), burst extended data output DRAM (bedo DRAM), enhanced DRAM (edram), Synchronous DRAM (SDRAM), JEDEC SRAM, PC100 SDRAM, double data rate SDRAM (ddr SDRAM), enhanced SDRAM (esdram), synclink DRAM (sldram), Diff Rambus DRAM (DRDRAM), or ferroelectric ram (fram), or any other type of memory device capable of performing the methods and systems described herein. In some embodiments, main memory unit 122 and/or cache 140 may include one or more memory devices that may hold data and allow central processing unit 121 direct access to any memory location. Further embodiments include a central processing unit 121 that can access main memory 122 via any of the following: a system bus 150, a memory port 103, or any other connection, bus, or port that allows the processor 121 to access the memory 122.

One embodiment of the computing device 100 provides support for any of the following installation devices 116: floppy disk drive for receiving floppy disks such as 3.5 inch, 5.25 inch disks or ZIP disks, CD-ROM drive, CD-R/RW drive, DVD-ROM drive, tape drives of various formats, USB device, bootable media, bootable CDs, devices such as CD-ROM drive, USB device, CD-ROM driveGNU/Linux distribution of bootable CDs, hard drives, or any other device suitable for installing applications or software. In some embodiments, the application may include the client agent 120 or any portion of the client agent 120. The computing device 100 may also include a storage device 128, which may be, for example, one or more hard disk drives or a redundant array of independent disks, wherein the storage device is configured to hold an operating system, software, program applications, or at least a portion of the client agent 120. Other embodiments of the computing device 100 include a mounting device 116 that functions as a storage device 128.

Further, computing device 100 may include a network interface 118 to interface to a Local Area Network (LAN), Wide Area Network (WAN) or the Internet through a variety of connections, including, but not limited to, standard telephone lines, LAN or WAN links (e.g., 802.11, T1, T3, 56kb, X.25, SNA, DECNET), broadband connections (e.g., ISDN, frame Relay, ATM, gigabit Ethernet, Ethernet over SONET), wireless connections, or some combination of any or all of the above. Connections may also be established using a variety of communication protocols (e.g., TCP/IP, IPX, SPX, NetBIOS, Ethernet, ARCNET, SONET, SDH, Fiber Distributed Data Interface (FDDI), RS232, RS485, IEEE802.11a, IEEE802.11b, IEEE802.11g, CDMA, GSM, WiMax, and direct asynchronous connections). One version of the computing device 100 includes a network interface 118 that can communicate with additional computing devices 100' via any type and/or form of gateway or tunneling protocol: such as Secure Sockets Layer (SSL) or transport layer security protocol (TLS) or Citrix gateway protocol available from Citrix Systems, inc. Versions of the network interface 118 may include any of the following: a built-in network adapter, network interface card, PCMCIA network card, card bus network adapter, wireless network adapter, USB network adapter, modem, or any other device suitable for interfacing the computing device 100 to a network that can communicate and perform the methods and systems described herein.

Embodiments of the computing device 100 include any of the following I/O devices 130A-130N: a keyboard 126, a pointing device 127, a mouse, a track pad, an optical pen, a track ball, a microphone, a drawing board, a video display, a speaker, an inkjet printer, a laser printer, and a dye-sublimation printer, or any other input/output device that can perform the methods and systems described herein. In some embodiments, I/O controller 123 is coupled to a plurality of I/O devices 130A-130N to control one or more I/O devices. Some embodiments of the I/O devices 130A-130N may be configured to provide a storage device or mounting medium 116, while other embodiments may provide a Universal Serial Bus (USB) interface to receive USB storage devices such as the USB flash drive family of devices available from Twintech Industry, Inc. Other embodiments of the I/O device 130 may be a bridge between the system bus 150 and an external communication bus such as: USB bus, Apple Desktop bus, RS-232 serial connection, SCSI bus, FireWire 800 bus, Ethernet bus, AppleTalk bus, gigabit Ethernet bus, asynchronous transfer mode bus, HIPPI bus, super HIPPI bus, SerialPlus bus, SCI/LAMP bus, FibreChanel bus, or Serial attached SCSI bus.

In some embodiments, the computing device 100 may be connected to multiple display devices 124A-124N, in other embodiments the computing device 100 may be connected to a single display device 124, but in other embodiments the computing device 100 is connected to the same or different types or forms of displayed display devices 124A-124N. Embodiments of display devices 124A-124N may be supported and enabled by: one or more of the I/O devices 130A-130N, the I/O controller 123, a combination of the I/O devices 130A-130N and the I/O controller 123, a combination of hardware and software that may support the display devices 124A-124N, any type and/or form of video adapter, video card, driver and/or library to interface, communicate, connect or otherwise utilize the display devices 124A-124N. In some embodiments, computing device 100 may be configured to use one or more display devices 124A-124N, including: includes a plurality of connectors to interface with a plurality of display devices 124a-124 n; includes a plurality of video adapters, each video adapter connected to one or more display devices 124A-124N; includes an operating system configured to support multiple displays 124A-124N; using circuitry and software included in the computing device 100 to connect and use the plurality of display devices 124A-124N; and executes software on the primary computing device 100 and the plurality of secondary computing devices to cause the primary computing device 100 to use the secondary computing device's display as the display devices 124A-124N of the primary computing device 100. Other embodiments of the computing device 100 may include multiple display devices 124A-124N provided by multiple secondary computing devices and connected to the primary computing device 100 via a network.

In some embodiments of the computing machine 100, an operating system may be included to control task scheduling and access to system resources. Embodiments of the computing device 100 may run any of the following operating systems: any one version of the Microsoft WINDOWS operating systems, such as WINDOWS 3.x, WINDOWS95, WINDOWS 98, WINDOWS 2000, WINDOWS NT 3.51, WINDOWS NT 4.0, WINDOWS CE, WINDOWS XP, and WINDOWS VISTA, different versions of the Unix and Linux operating systems, any version of the MAC OS of apple computer products, OS/2 of International Business machines corporation products, any embedded operating system, any real-time operating system, any open source operating system, any special purpose operating system, any operating system for mobile computing devices, or any other operating system that can run on a computing device and perform the operations described herein. One embodiment of the computing machine 100 has multiple operating systems installed thereon.

The computing machine 100 may be embedded in any of the following computing devices: a computing workstation, a desktop computer, a laptop or notebook computer, a server, a portable computer, a mobile phone, a portable communication device, a media playing device, a gaming system, a mobile computing device, any of the IPOD family of products available from apple, any of the PLAYSTATION family of products available from sony, any of the Nintendo family of products available from Nintendo, or any of the XBOX family of products available from microsoft, or any other type and/or form of computing, communication, or media device that can communicate and have sufficient processor power and storage capacity to perform the methods and systems described herein. In other embodiments, the computing machine 100 may be a mobile device such as any of the following: a JAVA-enabled cellular phone or Personal Digital Assistant (PDA), such as i55sr, i58sr, i85s, i88s, i90c, i95cl, or im1100 from motorola, 6035 or 7135 from Kyocera, i300 or i330 from samsung electronics, a TREO180, 270, 600, 650, 680, 700p, 700w, or 750 smart phone from Palm, any computing device with input devices, different processors, and operating systems consistent therewith, or any other mobile computing device that can perform the methods and systems described herein. Other embodiments of the computing environment 101 include the mobile computing device 100, which may be any of the following: any series of blackberry phones, or other portable devices available from Reserch Inmotion Limited, iPhone available from Apple computer, any portable or smart phone, Pocket PC phone, or other portable mobile device that supports Microsoft Windows mobile software.

Referring now to FIG. 1D, the servers 106 together comprise a farm 38 or server farm, wherein each server 106 may include a network-side interface 202 and a farm-side interface 204. The network-side interface 202 may be in communication with one or more clients 102 or networks 104. The network 104 may be a WAN, LAN, or a network of any other embodiment such as those described above.

Each server 106 has a cluster-side interface 204 that is connected to one or more cluster-side interfaces 204 of other servers 106 in the cluster 38. In one embodiment, each group-side interface 204 is interconnected to other group-side interfaces 204 so that the servers 106 in the group 38 can communicate with each other. On each server 106, the group-side interface 204 communicates with the network-side interface 202. The group-side interface 204 may also be in communication with persistent memory 230 (as indicated by arrow 220) and, in some embodiments, dynamic memory 240. When this is present, the combination of server 106, persistent storage 230, and dynamic storage 240 is collectively referred to as a farm 38. In some embodiments, server 106 communicates with persistent storage 230, while other servers 106' communicate with server 106 to access information stored in persistent storage.

Persistent storage 230 may be physically implemented on a disk, a group of disks, a Redundant Array of Independent Disks (RAID), a rewritable compact disk, or any other device that allows data to be read from and written to and that retains written data when the storage device is powered down. A single physical device may provide storage for multiple persistent memories, i.e., a single physical device may be used to provide persistent memory 230 for more than one group 38. Persistent storage 230 holds static data associated with each server 106 in farm 38 and global data used by all servers 106 in farm 38. In one embodiment, persistent storage 230 may maintain server data in a Lightweight Directory Access Protocol (LDAP) data model. In other embodiments, persistent storage 230 stores the server data in an ODBC compatible database. For ease of description, the term "static data" refers to data that changes infrequently, i.e., data changes only on an hourly, daily, or weekly basis, or data never changes. Each server uses the persistent storage subsystem to read data from persistent storage 230 or to write data to persistent storage 230.

Data held by persistent storage 230 may be physically or logically replicated for reliability reasons. For example, physical redundancy may be provided using a set of redundant, mirrored disks, each providing a copy of the data. In other embodiments, the database itself may be replicated using standard database techniques to provide multiple backups of the database. In further embodiments, both physical and logical replication may be used.

Dynamic memory 240 (i.e., the collection of all record tables) may be embedded in a variety of ways. In one embodiment, the dynamic memory 240 is centralized, i.e., all runtime data is stored in the memory of one server 106 in the farm 38. The server operates as a master network node with which all other servers 106 in the farm 38 communicate when seeking access to runtime data. In another embodiment, each server 106 in the farm 38 maintains a full backup of the dynamic memory 240. Here, each server 106 communicates with each other server 106 to maintain a recent copy of its dynamic memory 240.

In another embodiment, each server 106 maintains its own runtime data and communicates with other servers 106 when seeking to obtain runtime data from that other server 106. Thus, for example, a server 106 attempting to find an application requested by a client 102 may communicate directly with each other server 106 in the farm 38 to find one or more servers hosting the requested application.

For a farm 38 with a large number of servers 106, the network traffic generated by these embodiments may become significant. In one embodiment, the tremendous network traffic is mitigated by designating a subset of the servers 106 in the farm 38 (typically two or more servers) as "collector points. In general, a collector point is a server that collects runtime data. Each collector point holds runtime data collected from some other server 106 in the farm 38. Each server 106 in the farm 38 may operate as a collector point and may then be designated as a collector point. In one embodiment, each collector point holds a copy of the entire dynamic memory 240. In another embodiment, each collector point holds a portion of the dynamic memory 240, i.e., it holds runtime data of a particular data type. The type of data maintained by the server 106 may be predetermined according to one or more criteria. For example, the server 106 may save different types of data based on their boot order. In addition, the types of data maintained by the server 106 may be configured by an administrator using an administration tool (not shown). In these embodiments, dynamic memory 240 is distributed among two or more servers 106 in farm 38.

Servers 106 not designated as collector points are aware of the servers 106 in the farm 38 designated as collector points. Servers 180 not designated as collector points may communicate with a particular collector point when delivering and requesting runtime data. In turn, when a collector point seeks access to runtime data, the collector point mitigates network traffic because each server 106 in the farm 38 communicates with a single collector point server 106, rather than communicating with every other server 106.

For more than one type of data, each server 106 may operate as a collector point. For example, the server 106 "may operate as a collector point for licensing information and for carrying information. In these embodiments, each collector point may accumulate different types of runtime data. For example, to illustrate this scenario, server 106' "may collect authorization information while server 106" collects bearer information.

In some embodiments, each collector point holds data shared among all servers 106 in the farm 38. In these embodiments, each collector point of a particular type of data exchanges data collected by the collector point with each other collector point in the cluster 38 for that type of data. Thus, after such exchange of data is completed, each collector point 106 "and 106 processes the same data. In these embodiments, each collector point 106 and 106 "also maintains any parallel updates of runtime data for each other collector point.

Browsing may cause client 102 to view groups 38, servers 106, and applications in groups 38 and access available information, such as sessions through groups 38. Each server 106 includes an ICA browsing subsystem 260 to provide browsing capabilities to the client 102. After the client 102 establishes a connection with the ICA browser subsystem 260 of any of the servers 106, the browser subsystem supports various client requests. Such client requests include: (1) enumerating the names of the servers in the group, (2) enumerating the names of the applications published in the group, (3) resolving the server names and/or application names to server addresses that are useful to the client 102. The ICA browser subsystem 260 also supports requests made by clients 102 running program neighbor applications that, when requested, provide the clients 102 with a view of those applications in the group 38 of authorized users. The ICA browser subsystem 260 forwards all of the above client requests to the appropriate subsystem in the server 106.

In one embodiment, each server 106 in the farm 38 having a program neighbor subsystem 270 may provide a view of the applications in the farm 38 to a user of the client 102. For those applications that the user of the client 102 has authorized access to, the program neighbor subsystem 270 may restrict the view of those applications. Typically, the program neighborhood service presents the applications to the user as a list or group of icons.

The functionality provided by the program neighbor subsystem 270 may be applicable to two types of clients, (1) program neighbor enabled clients that may access functionality directly from the client desktop, and (2) non-program neighbor enabled clients (e.g., legacy clients) that may access functionality through the program neighbor enabled desktop on the running server.

Communication between the program neighbor enabled client and the program neighbor subsystem 270 may occur over a dedicated virtual channel established on top of the ICA virtual channel. In other embodiments, the communications are generated using XML services. In one such embodiment, the program neighbor enabled client communicates with an XML subsystem, such as XML service 516 described below in conjunction with FIG. 6, providing program neighbor functionality on server 106.

In one embodiment, there is no connection between the program neighbor enabled client and the server with the program neighbor subsystem 270. For this embodiment, the client 102 sends a request to the ICA browser subsystem 260 to establish an ICA connection to the server 106 to identify applications available to the client 102. The client 102 then runs a client-side dialog that obtains the user's credentials. The ICA browser subsystem 260 receives the certificate and sends it to the program neighbor subsystem 270. In one embodiment, the program neighbor subsystem 270 sends the certificate to the user management subsystem for verification. The user management subsystem may return a different set of names representing a list of accounts to which the user belongs. Upon verification, the program neighbor subsystem 270 establishes a program neighbor virtual channel. The channel remains open until the application filtering is complete.

The program neighbor subsystem 270 then requests program neighbor information from the general application subsystems 524 associated with those accounts. The general application subsystem 524 retrieves program neighbor information from persistent storage 230. Upon receiving the program neighbor information, the program neighbor subsystem 270 formats and returns the program neighbor information to the client via the program neighbor virtual channel. Then part of the ICA connection is closed.

In another example of a program neighbor enabled client and server establishing a partial ICA connection, consider a user selecting a client 102 of the group 38. Selection of a farm 38 sends a request from the client 102 to the ICA browser subsystem 260 to establish an ICA connection with one of the servers 106 in the selected farm 38. The ICA browser subsystem 260 sends a request to the program neighbor subsystem 270, which selects a server 106 in the farm 38. Address information associated with the server 106 is identified and returned to the client 102 via the ICA browser subsystem 260. The client 102 may then connect to the server 106 corresponding to the received address information.

In another embodiment, the program neighbor enabled client 102 establishes an ICA connection when establishing a program neighbor virtual channel and remains open as long as the ICA connection exists. Through this program neighbor virtual channel, the program neighbor subsystem 270 pushes program neighbor information updates to the client 102. To obtain this update, the program neighbor subsystem 270 subscribes to events from the general application subsystem 524 to allow the program neighbor subsystem 270 to detect changes to the published application.

Shown in fig. 2 is a block diagram depicting an embodiment of a system for remotely processing multimedia plugins. The system may include a local computing machine 106 in communication with a remote computing machine 102 via a presentation layer protocol over a virtual communication channel 255. Executing on the local computing machine 106 are a container application 205, a plug-in 215, and a proxy plug-in 210, where the plug-in 215 and the proxy plug-in 210 may communicate with the container application 205. An application/desktop delivery system 220 communicates with the container application 205 and the proxy plugin 210, the application/desktop delivery system 220 may communicate with a client proxy 230 executing on the remote computing machine 102 over a virtual communication channel. The application display window 250 and the proxy container application 235 are in communication with the client agent 230. The proxy container application 235 is also in communication with the application display window 250 and the plug-in 240. Cache memories 225 and 245 are included on both the local computing machine 106 and the remote computing machine 102.

With further reference to FIG. 2 and in more detail, in one embodiment, the local computing machine 106 may be any of the computing machines described above. In one embodiment, the local computing machine 106 is a server. In other embodiments, the local computing machine 106 may be referred to as the first computing machine or the second computing machine. In some embodiments, the local computing machine 106 may be a server 106, and the server 106 may be any one of an application server, a server in a server farm, or any other type of server capable of providing content to a client to which the server 106 is connected. In most embodiments, the local computing machine 106 may communicate with the remote computing machine 102 over a network 104, such as any of the networks described herein.

In some embodiments, the remote computing machine 102 may be any of the computing machines described above. In one embodiment, the remote computing machine 102 is a client machine 102, while in other embodiments, the remote computing machine 102 may be a first computing machine or a second computing machine. In some embodiments, the client 102 may be a portable computing device, such as any of the portable devices described herein. The remote computing machine 102 may communicate with the local computing machine 106 over a network 104, such as any of the networks described herein.

In some embodiments, virtual communication channel 255 is an ICA channel. Thus, in these embodiments, communication between the local computing machine 106 and the remote computing machine 102 over the virtual communication channel 255 occurs using a presentation layer protocol such as the ICA protocol available from CITRIX SYSTEMS. In some embodiments, the local computing machine 106 and the remote computing machine 102 may communicate through RDP, PCAnywhere, or any other presentation layer protocol. In some embodiments, the virtual communication channel 255 is established over a network 104 such as any of the networks described herein. The communication channel 255 may be a virtual channel, a virtual communication channel, a virtual communication connection, or any other communication connection between the remote computing machine 102 and the local computing machine 106.

The application/desktop delivery system 220 and the client agent 230 may facilitate communication over a virtual communication channel 255. The application/desktop delivery system 220 executes on the local computing machine 106 and operates to send information from the local computing machine 106 to the remote computing machine 102 over the communication channel 255. More specifically, the application/desktop delivery system 220 may receive graphical application output from the container application 205 and send the graphical application output to a client agent 230 executing on the remote computing machine 102. The client agent 230 may then display the received graphical application output in an application display window 250 executing on the remote computing machine 102. In some embodiments, the application/desktop delivery system 220 may receive calls, requests, and other information from the proxy plugin 210 on the local computing machine 106 and send the calls, requests, and other information to the client proxy 230, which the client proxy 230 forwards to the proxy container application 235.

Although an application/desktop delivery system 220 is shown in FIG. 2 in communication with container application 205, other embodiments include an application/desktop delivery system 220 that receives graphical application output from any number of applications executing on local computing machine 106. The application/desktop delivery system 220 receives the graphical application output and sends the output to the client agent 230, and the client agent 230 then forwards the output to the appropriate application display window 250, where it is displayed.

In some embodiments, the application/desktop delivery system 220 communicates with other applications or storage repositories on the local computing machines 106. In one embodiment, the proxy plugin 210 may forward any of the following to the application/desktop delivery system 220: calls issued by the plug-in 216, requests for media and multimedia content issued by the container application 205, window information acquired by the proxy plug-in 210, scripting interfaces acquired by the proxy plug-in 210, graphical output stored in the cache 225, graphical commands or window information stored in the cache 225, and any other stored information or requests issued by objects executing on the local computing machine 106. The application/desktop delivery system 220 may send any received save information, received commands, or requests to a client agent 230 executing on the remote computing machine 102. In one embodiment, the remote computing machine 102 may receive the information and forward the information to an object executing on the remote computing machine 102 or display a graphical output on the application display window 250.

In one embodiment, the container application 205 executes on the local computing machine 106. The container application 205 may be any application described herein. More specifically, the container application 205 may be: a browser application, a MICROSOFT OFFICE application, an ADOBE application, a GOOGLE application, a web application, a cloud application, an application executing on a computing machine remote from the local computing machine 106 (i.e., a third or fourth computing machine), or any other application that can execute a plug-in and display the results of the plug-in execution. For example, the plug-in may be an INTERNET EXPLORER browser application executing a FLASH player.

In some embodiments, plug-in 215 may be an ACTIVEX control such as a FALSH player. The insert 215 may also be any of the following: ACTIVEX applications or controls, JAVA applets, ACTIVEX DATA OBJECT, DIRECT SHOW OBJECTs, ACTIVE scripts, and any other embedded or linked controls or sub-applications that may be executed in the methods and systems described herein. In one embodiment, the plug-in 215 executes in the context of the container application 205. In other embodiments, the plug-in 215 is linked to the container application 205 such that the plug-in 215 executes as if it were included in the container application 205. Although FIG. 2 depicts local computing machine 106 with plug-in 215, in some embodiments local computing machine 106 does not execute or otherwise have plug-in 215.

Plug-in 240 on remote computing machine 102, like plug-in 215, may be an ACTIVEX control, such as a FLASH player. The plug-in 240 may also be any of the following: ACTIVEX applications or controls, JAVA applets, ACTIVEX DATA OBJECT, DIRECT SHOW OBJECTs, ACTIVE scripts, and any other embedded or linked controls or sub-applications that may be executed in the methods and systems described herein. In one embodiment, the plug-in 240 is associated or linked with the proxy container application 235. In other embodiments, the plug-in 240 executes as if it were included in the proxy container application 235.

In some embodiments, proxy plugin 210 responds to plugin 215. In other embodiments, the proxy plugin 210 is responsive to a plugin 240 executing on the remote computing machine 102. The proxy plugin 210 can install itself on the local computing machine 106 in much the same way that a plugin would install itself on a computing machine. By so doing, the proxy plugin 210 is handled by the operating system on the local computing machine 106 and more importantly by the container application 205 as a fully installed plugin application. Whenever the container application 205 issues a request or call to a plug-in corresponding to the proxy plug-in 210, the proxy plug-in 210 may intercept the request or call and either respond to the request or call or forward the request or call to the plug-in 240 executing on the remote computing machine 102. The proxy plugin 210 can respond to the plugin 240 such that the proxy plugin 210 can represent any of: ACTIVEX applications or controls, JAVA applets, ACTIVEX DATAOBJECT, DIRECT SHOW objects, ACTIVE scripts, and any other embedded or linked controls or sub-applications that may be executed in the methods and systems described herein.

In some embodiments, the proxy plugin 210 is a plugin binary file (i.e., a COM server x.d 11 file) installed on the local computing machine 106. By installing the plug-in binary on the local computing machine 106, the proxy plug-in 210 is displayed to the container application 205 as if the proxy plug-in 210 were the actual plug-in application. Thus, all calls to the plug-in are resent, passed, or otherwise proxied to the proxy plug-in 210. For example, the container application 205 may be an INTERNET EXPLORER browser application executing a proxy plug-in 210, the proxy plug-in 210 being a FLASH player. The FLASH player proxy plug-in 210 intercepts calls to the FLASH player issued by pages executing in the INTERNET EXPLORER browser and forwards the calls to the proxy container application 235 executing on the remote computing machine 102. The proxy container application 235, corresponding to the INTERNET EXPLORER browser container application 205 executing on the local computing machine 106, issues a call to the plug-in 240 on the remote computing machine 102. The plug-in 240, the FLASH player on the remote machine 102, generates multimedia content based on the call and displays the content on the remote computing machine 102 or in a plug-in window in the application display window 250. The generated page is an HTML page that displays FLASH content in an HTML page that is displayed on the remote computing machine 102, where the HTML page is generated on the local computing machine 106 and the FLASH content is generated on the remote computing machine 102.

In one embodiment, the proxy plug-in 210 may collect and retrieve window data related to the container application 205 and the plug-in 215 on the local computing machine 106. In one embodiment, the container application 205 executes in a container window on the local computing machine 106. The container window (not shown) may be associated with window data such as: the position of the container window on the desktop, the size of the window, whether the container window is maximized or minimized, and any other window data related to the display of the container application 205. Similarly, there may be add-on window data in the container application 205 and thus in the container window that is relevant to the display of add-on content. In some embodiments, the plug-in window data may include: the location of the plug-in graphics area in the container window (i.e., the location in the container window where the plug-in output is displayed), the size of the graphics area where the plug-in output is displayed, the clipping area associated with the plug-in graphics output area, and any other window data associated with displaying the plug-in output in the container window.

In some embodiments, the proxy plugin 210 may query the container application 205 for information about the plugin window data. In one embodiment, the query may be an interface call issued by the broker plug-in 210 to the container application 205. Similarly, in some embodiments, the query may be for information about the plug-in window data to an operating system executing on the local computing machine 106. In response to the query, the container application 205 can send the plug-in window data to the proxy plug-in 210, and the proxy plug-in 210 sends the plug-in window data to the plug-in 240 on the remote computing machine 102. Once the remote plug-in 240 receives the plug-in window data, the plug-in 240 may configure or construct itself according to the container application 205 on the local computing machine 106. In some embodiments, this plug-in window data may be transmitted to the remote plug-in 240 via the remote presentation protocol, in other embodiments additional protocol commands are included in the window data so that the remote plug-in 240 can receive and interpret the plug-in window data.

In some embodiments, the proxy plugin 210 may be responsive to a plugin 240 executing on the remote computing machine 102. Each of the proxy plug-in 210 and the plug-in 240 may be referred to as a graphics plug-in, a media plug-in, a multimedia plug-in, a remote plug-in, or a local plug-in. The plug-ins 210, 240 may generate any of the following types of content: graphics, multimedia, audio, video, media, or any other type of content that may be generated by a plug-in application. The plug-ins 210, 240 may communicate with the caches 225, 245 to obtain graphics or multimedia content, or to obtain other information requested by the container application 205. The plug-ins 210, 240 may communicate with other parts of the computing machine, including an operating system, desktop applications, and any other applications executing on the computing machine.

In one embodiment, the caches 225, 245 are included on the local computing machine 106 and the remote computing machine 102. Caches 225 and 245 may comprise any storage repository capable of storing: graphics content, multimedia content, window data, graphics commands, and any other information or content used by the methods and systems described herein. In some embodiments, the contents of cache 225 on local computing machine 106 and cache 245 on remote computing machine 106 are the same. In other embodiments, graphics or multimedia content, window data, or script information may be stored in each cache 225, 245 that invokes a response or repeat request. The proxy plugin 210 or proxy container application 235 may retrieve the content from the cache 225, 245 and respond to calls issued by the container application 205 and/or plugin 240 by retrieving the requested content from the cache 225, 245.

In one embodiment, the application display window 250 executes on the remote computing machine 102. The application display window 250 may display graphical application output generated by an application executing on the local computing machine 106 and sent to the application display window 250 over a virtual channel 255. In one embodiment, the proxy container application 235 and the application display window 250 communicate such that the proxy container application 235 forwards the plug-in 240 output to the application display window 250 for display.

The proxy container application 235 may be responsive to the container application 205 executing on the local computing machine 106 such that the proxy container application 235 represents substantially the same application as the container application 205. In one embodiment, the proxy container application 235 may register with an operating system executing on the remote computing machine 102 such that the proxy container application 235 appears as if it is a fully installed container application. In such embodiments, the proxy container application 235 may be an executable binary executing on the remote computing machine 102, as a separate process controlled by the client agent 230, or as part of the client agent 230. Installing the proxy container application 235 as if it were a full installation of the container application allows the plug-in 240 on the remote computing machine 102 and the proxy container application 235 to interact as if the proxy container application 235 were the container application 205.

In some embodiments, the proxy container application 235 and the proxy plugin 210 contain the same COM and DCOM interfaces as the container application 205 and plugin 240. Thus, calls issued by the container application 205 to the COM and DCOM interfaces on the plug-in 240 may likewise be issued to the COM and DCOM interfaces on the proxy plug-in 210. In contrast, calls issued by the plug-in 240 to the COM and DCOM interfaces on the container application 205 may likewise be issued to the COM and DCOM interfaces on the proxy container application 235.

In most embodiments, the proxy container application 235, the container application 205, the plug-in 240, and the proxy plug-in 210 may issue and receive calls using MICROSOFT COM and DCOM technologies. In other embodiments, the proxy container application 235, the container application 205, the plug-in 240, and the proxy plug-in 210 may use another internal process or internal application communication standard that is capable of forwarding messages from one object to another.

An embodiment of a process 300 for remotely providing a call to a plug-in published by a container application is shown in FIG. 3A. The proxy plug-in 210 executing on the local computing machine 106 may intercept the call issued by the container application 205 executing on the local computing machine 106 (step 302). Once the call is intercepted, the proxy plugin 210 then determines whether the proxy plugin 210 can respond to the issued call (step 304). If the proxy plugin 210 can respond to the issued call, the proxy plugin 210 responds to the call with the requested content (step 306). Otherwise, if the proxy plugin 210 cannot respond to the call, the proxy plugin 210 sends the call to the proxy container application 235 executing on the remote computing machine 102 (step 308).

Referring now to FIG. 3A and in more detail, in one embodiment, the proxy plugin 210 can intercept a call issued by the container application 205 to the plugin 240 (step 302). The calls issued by the container application 205 may include any of the following: a request to access plug-in 240, a request to access a particular interface on plug-in 240, a request for graphical or multimedia content generated by plug-in 240, a request to access a script executed in plug-in 240, or any other call or request to request plug-in 240 to generate content or a response to the call. In some embodiments, the proxy plugin 210 may intercept calls issued by the container application 205, while in other embodiments, the container application 205 may issue calls to a plugin 215 executing on the local computing machine 106. In this embodiment, the plug-in 215 may then forward all calls to the proxy plug-in 210. In other embodiments, the proxy plugin 210 may intercept calls or requests issued by the container application 205 before they are received by the plugin 215. In this embodiment, the proxy plug-in 210 may hook an application program interface on the container application 205 so that the proxy plug-in 210 may intercept any calls issued by the container application 205.

Once the proxy plugin 210 intercepts the call issued by the container application 205, the proxy plugin 210 then determines whether the proxy plugin 210 can respond to the call (step 304). Determining whether the proxy plug-in 210 can respond to the call may include examining the contents of a cache 225 on the local computing machine 106 to determine whether the cached response has been saved on the local computing machine 106. In some embodiments, the proxy plugin 210 may query a table to determine whether the proxy plugin 210 can respond. In such an embodiment, each time a response is saved in the cache, an entry is inserted in a table indicating the particular call (i.e., request, plug-in interface of the request, metadata accompanying the request) and memory location of the response. Examining the table may indicate to the proxy plugin 210 whether the proxy plugin 210 can respond to the call, and may inform the proxy plugin 210 where the response is located in the cache (i.e., the memory location of the response in the cache). Using the retrieved memory location, the proxy plugin 210 may retrieve the response from the cache 225 and respond to the container application 205 with the retrieved response (step 306). In other embodiments, the proxy plugin 210 determines whether the proxy plugin 210 can respond by searching the cache 225 and retrieving the response once it is found. If a response is found, the proxy plugin 210 can respond. Conversely, if the response is not found, the proxy plugin 210 cannot respond.

When the proxy plugin 210 determines that the proxy plugin 210 is not able to respond, then the proxy plugin 210 may send the call to the proxy container application 235 executing on the remote computing machine 102 (step 308). In some embodiments, communicating the call to the proxy container application 235 may include communicating the call to the client proxy 230 over a virtual channel 255. The client agent 230 may then relay or otherwise forward the call to the proxy container application 235, or in some embodiments, may forward the call to a plug-in 240 executing on the remote computing machine 102. In some embodiments, forwarding the call to the proxy container application 235 includes compressing, encoding, and/or encrypting the call before transmitting the call over the virtual channel 255.

FIG. 3B illustrates one embodiment of a process 350 for receiving a published call to a plug-in 240. The proxy container application 235 executing on the remote computing machine 102 may receive the call issued by the container application 205 (step 352). The proxy container application 235 forwards the call to the graphics or multimedia plugin 240 executing on the remote computing machine 102 (step 354). The graphics plug-in responds to the call by generating media or multimedia content (step 356) and the generated media or multimedia content is displayed on a display device connected to the remote computing machine 102 (step 358).

With further reference to FIG. 3B and in more detail, in one embodiment, the proxy container application 235 executing on the remote computing machine 102 receives the call issued by the container application 205 (step 352). In other embodiments, the client agent 230 receives calls issued by the container application 205. Once the client agent 230 receives the call, the client agent 230 forwards the call to the plug-in 240 (step 354). In some embodiments, the proxy container application 235 receives calls from the proxy plugin 210, while in other embodiments, the proxy container application 235 receives calls from the client agent 230. The client agent 230 may receive calls from the application/desktop delivery system 220 or the agent plug-in 210. Receiving the call may include receiving metadata associated with the call. In some embodiments, the proxy container application 235 forwards the call and metadata to the plug-in 240. In other embodiments, receiving the call may include receiving a first call issued by the container application 205, and subsequently receiving a call may be referred to as a second call issued by the container application 205.

Once the proxy container application 235 receives the call, the proxy container application 235 forwards or issues the call to the graphics plug-in 240 executing on the remote computing machine 102 (step 354). When the client agent 230 receives the call, the client agent 230 may forward or post the call to the plug-in 240 or forward the call to the proxy container application 235. In most embodiments, the proxy container application 235 forwards or issues the call to the plug-in 240. In some embodiments, the client agent 230 decodes, decrypts, and/or decompresses the call and any associated metadata before forwarding the call to the proxy container application 235 or the plug-in 240.

After the call is issued to plug-in 240, plug-in 240 processes the call and any associated metadata to generate a response or content (step 356). The content may include media content, graphical content, multimedia content, audio content, or any other content requested by the container application 205. Generating the response may include responding with configuration information, security information, script output, or window data specific to the plug-in 240. In most embodiments, the plug-in 240 generates a response or content in response to receiving the call.

The content generated by the plug-in 240 may be displayed on a display device connected to the remote computing machine 102 (step 360). In some embodiments, the plug-in 240 displays the media or multimedia content in a plug-in window or a graphical output portion or canvas located in the container application window. The container application window is also displayed on a display device coupled to the remote computing machine 102. Thus, when the container application window containing the plug-in window is displayed on a display device, the plug-in window and the generated media or multimedia content are also displayed on the display device connected to the remote computing machine 102. When the generated content is audio content, the content may be played by the remote computing machine 102 such that it may be played through speakers connected to the remote computing machine 102.

One embodiment of a method or process 400 for responding to calls issued by the container application 205 or the plug-in 240 is shown in FIG. 4. In one embodiment, the method 400 includes intercepting a call issued by the container application 205 or the plug-in 240 (step 402). It is then determined whether the proxy container application 235 or the proxy plugin 210 can respond to the intercepted call (step 404). When neither the proxy container application 235 nor the proxy plugin 210 can respond to the call, the call is forwarded to the appropriate proxy (step 410). When the proxy container application 235 or the proxy plugin 210 can respond to the call, the requested content is retrieved from the cache 225, 245 (step 406) and forwarded to the container application 205 or plugin 240 (step 408).

With further reference to FIG. 4 and in more detail, in one embodiment, a call issued by the container application 205 or the plug-in 240 is intercepted (step 402). When the call is issued by the container application 205, the proxy plugin 210 intercepts the call. On the other hand, when the call is issued by the plug-in 240, then the proxy container application 235 intercepts the call. In some embodiments, a separate application executing on local computing machine 105, remote computing machine 102, or a third computing machine may intercept calls issued by container application 205 or plug-in 240. When the individual application intercepts the call, the individual application may forward the call to the proxy plugin 210 or proxy container application 235.

Once the issued call is intercepted, a determination is made as to whether the proxy container application 235 or the proxy plugin 210 can respond to the call (step 404). This determination may be made by consulting a table to determine whether a response to the issued call is stored in the cache 225, 245. In instances where the response to the call issued by the plug-in 240 is stored in cache 245 on the remote computing machine 102, the response may be returned to the proxy container application 235 to indicate that the response resides in cache 245, and in some embodiments, also provide the location of the response in cache 245. Also, in instances where the response to the call issued by the container application 205 is saved in the cache 225 on the local computing machine 106, the response may be returned to the proxy plugin 210 to indicate that the response resides in the cache 225, and in some embodiments, also provide the location of the response in the cache 225. In one embodiment, the proxy plugin 210 may determine that a response to a call appears in the cache 225 after searching for the response in the cache 225. Similarly, in some embodiments, the proxy container application 235 may determine that a response to the call is present in the cache 245 after searching for the response in the cache 245. In each of these embodiments, the proxy plugin 210 and proxy container application 235 may respond to the call after determining that they locate a response in the cache 225, 245.

If the response is found, or if it is determined that neither the proxy container application 235 nor the proxy plugin 210 can respond to the issued call, the call is forwarded to the other of the proxy container application 235 or the proxy plugin 210 (step 410). If it is determined that the proxy plugin 210 cannot respond to the call, the call is forwarded to the client agent 230, and in some embodiments the client agent 230 forwards the call to the proxy container application 235. When it is determined that the proxy container application 235 cannot respond to the call, the call is forwarded to the proxy plugin 210 in some embodiments.

If it is determined that the proxy plugin 210 or proxy container application 235 can respond to the call, the proxy plugin 210 or proxy container application 235 retrieves the requested content from the cache 225, 245 (step 406). When it is determined that the proxy plugin 210 can respond to a call issued by the container application 205, then the proxy plugin 210 retrieves the response to the container application 205 issuing the call from the cache 225. Similarly, when it is determined that the proxy container application 235 can respond to a call issued by the plug-in 240, then the proxy container application 235 retrieves a response from the cache 245 to the call issued by the plug-in 240. In some embodiments, the container application 205 or the plug-in 240 issues calls, while in other embodiments they issue requests for information, or for access to an interface on the plug-in 240 or the container application 205. In other embodiments, the proxy plugin 210 and/or proxy container application 235 can retrieve the requested content from the cache 225, 245 by searching for a particular memory location in the cache or searching for the desired content in the cache 225, 245.

Once the requested content is retrieved from the cache 225, 245 (step 406), the requested content is forwarded to the container application 205 or the plug-in 240 (step 408). Thus, if the proxy plugin 210 intercepts the call, it is determined that the proxy plugin 210 can respond to the call and retrieve the requested content from the cache 225; the proxy plug-in 210 may respond to the call issued by the container application 205 with content retrieved from the cache 225 (step 408). Similarly, if the proxy container application 235 intercepts the call, determines that the proxy container application 235 can respond to the call, and retrieves the requested content from the cache 245, the proxy container application 235 responds to the call issued by the plug-in 240 with the content retrieved from the cache 245 (step 408).

In some embodiments, the method 400 described in FIG. 4 may be referred to as shorting the interface. This tag is an attribute of method 400 that allows the local agent to respond to the call, rather than sending the call to a remote computer that can respond to it. Thus, rather than sending the call issued by the container application 205 to the plug-in 240 on the remote computing machine 102, the proxy plug-in 210 can respond to the call by retrieving a response from the cache 225 on the local computing machine 106. Similarly, the proxy container application 235 may respond to calls issued by the plug-in 240 by obtaining responses from the cache 245 on the remote computing machine 102. By executing process 400, the execution path taken by the interface call is shortened, thereby reducing traffic on network 104, and thus virtual channel 225, and reducing response time. Thus, the performance of the container application 205 and the plug-in 240 is improved because each time the response path is shortened, the resulting functionality is substantially similar to that provided when the container application 205 and the plug-in 240 are executed on the same computer.

In some embodiments, those responses stored in the caches 225, 245 are responses to frequently made calls. Thus, the proxy plugin 210, proxy container application 235, delivery system 220, or client agent 230 may select a response to the cache for a call that is repeated over a particular time period. Similarly, a particular call may be determined to be dropped when it is determined that a response to a subsequent call can clear the impact obtained by responding to the initial call. Such a determination may be made by examining the type of call or the type of interface requested by the call.

A method 500 for allowing response to a call is shown in fig. 5. The proxy plugin 210 or proxy container application 235 may intercept the call issued by the container application 205 or plugin 240 and also determine the content of the call (step 502). If the interface requested by the agent is permissible (step 504), the call is allowed (step 506). If the requested interface is not allowable (step 504), the call is rejected (step 508).

With continuing reference to FIG. 5 and in more detail, in one embodiment, the proxy plugin 210 intercepts calls generated and issued by the container application 205 (step 502). Similarly, the proxy container application 235 may intercept calls generated and issued by the plug-in 240 (step 502). Once the proxy plugin 210 or proxy container application 235 intercepts the call, the proxy can examine the call and determine the type of interface or content requested. In some embodiments, the type of requested interface may include determining functionality associated with the requested interface. For example, the interface request may include requesting the FLASH player to execute a particular movie file or display a particular type of graphics. In some embodiments, the initial check of the call may specify the type of functionality requested by the call. In other embodiments, the examination of the call may include determining the content of the call, such as metadata included in the call.

Once the proxy identifies the content of the call or calls the requested functionality, the proxy 210, 240 may determine whether the requested interface is permitted (step 504). Determining the permission level associated with a particular container application 205, plug-in 240, computing machine, or user may include examining a list or table of approved content or functionality. The table or list may identify the content or functionality allowed for a particular user, computer, IP address, application, plug-in, domain, or any other identifier used to identify a particular machine, user, or application. If the requested functionality or content is permitted or allowed via the permission table or list, the call is allowed (step 506). If the call is not permitted, the call is rejected (step 508).

In one embodiment, the system includes a security agent (not shown) in the agent plug-in 210 or agent container 235, or an agent executing on the local computing machine 106, the remote computing machine 102, or a third machine executing on the network 104 and in communication with the local computing machine 106 and/or the remote computing machine 102. In some embodiments, the security agent may intercept all calls issued by the container application 205 and/or the plug-in 240 to determine whether the call is permitted or allowed. In some embodiments, the security agent communicates with an allowed form or list held in memory on the local computing machine 106, the remote computing machine 102, or a third computing machine. When the security agent determines that the call is not allowed, the security agent may reject the call by disallowing it to be forwarded and responding to the call by using an error message indicating that the requested functionality or content is not allowed (step 508). In other embodiments, the security proxy responds to the licensed functionality and content by forwarding a call to the proxy plugin 210 or proxy container application 235.

In some embodiments, security precautions are also employed by allowing the proxy plug-in 210 and the plug-in 240 to execute at the same granularity or security level. Similarly, the proxy container application 235 may execute at the same granularity or security level as the container application 205.

Illustrated in FIG. 6 is a method 600 for obtaining window data specific to a plug-in window. The proxy plug-in 210 may query the container application 205 or an operating system executing on the local computing machine 106 for window data related to the plug-in 240 (step 602). Upon receiving the widget data from the container application 205 or operating system, the proxy plugin 210 transmits the widget data to the plugin 240 executing on the client (i.e., remote computing machine 102) (step 604). The plug-in 240 then uses the window data to build itself and the container application 205 together (step 606).

With further reference to FIG. 6 and in more detail, in one embodiment, the proxy plugin 210 can query or request window data related to the plugin 240 from the container application 205 (step 602). In some embodiments, the window data includes information about where to display the graphics or multimedia content of the plug-in the container application 205. When the container application 205 and the plug-in 240 execute on the same machine, the container application 205 and the plug-in 240 combine together such that the generated graphics appear to be from the same source. For example, a web page displaying a FLASH player playing a video may appear to the user to display the video as if the web page itself displayed the video. In fact, the web page may simply draw an area in the web page for the graphics output of the FLASH player. The multimedia content generated by the FLASH player is displayed in a display area drawn or set aside from the web page. The information related to the graphical output regions in the container application 205 may include the size of the graphical output regions, the layout of the graphical output regions, the clipping regions of the graphical output regions, and any other information that may be used to define the graphical output regions in the container application 205.

In some embodiments, the proxy plugin 210 queries the container application 205 for information, while in other embodiments, the proxy plugin 210 queries an operating system executing on the local computing machine 106. In some embodiments, when the proxy plugin 210 receives window data from the operating system, the proxy plugin 210 can utilize additional protocol commands to transmit the window data to the client or plugin 240 on the remote computing machine 102. One example of an application program interface call to the operating system on the local computing machine 106 includes issuing a GetWindowPosition () call that, in most embodiments, may result in receiving the location of a plug-in window on the screen. The application program interface call is issued to the operating system and not to the container application 205.

In response to the proxy plugin 210 query, the proxy plugin 210 may receive window data from the container application 205 or operating system and may transmit the received window data to the plugin 240 (step 604). In some embodiments, the proxy plug-in 210 saves the window data in the cache 225 before transferring the window data to the plug-in 240. In other embodiments, plug-in 240 saves the window data in cache 245 as it is received. In some embodiments, the proxy plugin 210 may use a presentation layer protocol to transmit the window data over the virtual channel 255. In some embodiments, the agent plug-in 210 forwards the window data to the application/desktop delivery system 220, which delivery system 220 then transmits the window data to the client agent 230. In some embodiments, when client agent 230 receives window data, it may save the window data in cache 245. In other embodiments, the client agent 230 may forward the window data to the agent container application 235, which may then forward the window data to the plug-in 240. Other embodiments include the client agent 230 forwarding the window data directly to the plug-in 240.

In one embodiment, once the plug-in 240 receives the window data, the plug-in 240 may then build itself and the container application 205 executing on the local computing machine 106 together (step 606). In other embodiments, the plug-in 240 may build itself and the proxy container application 235 together. Combining the plug-ins into the container application 205 may include configuring the plug-ins such that the graphical content is formatted for display in an output area defined in the container application 205. Formatting may include changing the resolution of the graphical content so that it can be displayed in the output area and so that it cannot be cropped when displayed in the output area.

An embodiment of a process 700 for obtaining a scripting interface is shown in FIG. 7. The proxy plug-in 210 or the proxy container application 235 obtains a script interface generated by a script executed in the container application 205 or the plug-in 240 (step 702). Once the scripting interface is obtained, the scripting interface is transferred to the plug-in 240 or the container application 205 (step 704). Once the scripting interface is installed, the proxy plugin 210 and/or proxy container application 235 may intercept the call to the scripting interface and also proxy the call (step 706).

With further reference to FIG. 7 and in more detail, in one embodiment, the proxy plugin 210 obtains a scripting interface from the container application 205 (step 702). When the scripting interface is obtained, the proxy plugin 210 transmits the scripting interface to the proxy container application 235 (step 704), which receives the scripting interface and installs it in its framework. By installing a scripting interface at the interface of the proxy container application 235, the proxy container application 235 may provide the plug-in 240 with the ability to request access to the installed scripting interface. Installing the scripting interface may include changing the structure of the proxy container application 235 binary file so that the binary file may provide the plug-in 240 with the ability to invoke a particular scripting interface. Once the scripting interface is installed in the proxy container application 235 structure, the proxy container application 235 may intercept the call to the scripting interface and pass the call to the scripting interface on the container application 205 (step 706).

Similarly, the proxy container application 235 may obtain a scripting interface from the plug-in 240 (step 702). When the scripting interface is obtained, the proxy container application 235 transmits the scripting interface to the proxy plugin 210 (step 704), which receives the scripting interface and installs it in its structure. By installing a scripting interface in an interface of the proxy plugin 210, the proxy plugin 210 may provide the container application 205 with the ability to request access to the installed scripting interface. Installing the scripting interface may include changing the structure of the proxy plug-in 210 binary file such that the binary file provides the container application 205 with the ability to call a particular scripting interface. Once the scripting interface is installed in the structure of the proxy plug-in 210, the proxy plug-in 210 may intercept calls to the scripting interface and also pass the calls to the scripting interface on the plug-in 240 (step 706).

In one embodiment, the scripting interface is generated by a script executed in the container application 205 or the plug-in 240. For example, Java script code in an HTML page may invoke methods and properties on the ACTIVEX widget hosted in the same HTML page by requesting access to an interface associated with the ACTIVEX widget. The example shows a script executing in the container application 205 issuing a call from a script interface in the container application 205 to an interface on the plug-in 240. Thus, while the above illustrates proxy calls to the scripting interface, in other embodiments calls issued by the scripting interface may be intercepted and passed to the container application 205 or the plug-in 240. Thus, calls issued by the scripting interface may be proxied to the container application 205 or the plug-in 240.

One embodiment of a method 800 for dynamically retrieving network content is illustrated in FIG. 8. In one embodiment, a request for a network resource generated and issued by the plug-in 240 is intercepted (step 802). Once the request has been intercepted, a determination is made as to whether the resource should be retrieved from the server 106 (step 812). When it is determined that the requested network resource should not be retrieved from server 106, then the network resource is obtained or retrieved from network 104 (step 810). When it is determined that the requested network resource should be obtained or retrieved from the server 106, then the request is redirected to the server or local computing machine 106 over the virtual channel 255 (step 804). Once the request is redirected to the local computing machine 106, the requested resources are assembled together from the local computing machine 106 (step 806) and the assembled resources are transferred to the plug-in 240 (step 808).

With further reference to FIG. 8 and in more detail, in one embodiment, the plug-in 240 may request access to resources dedicated to the network on which the local computing machine 106 is located. In these embodiments, and in embodiments where the plug-in 240 requests download of resources indirectly through the virtual channel 255, the plug-in 240 may generate and issue a request for network resources (step 802). In one embodiment, the request may be intercepted by the proxy container application 235, while in other embodiments, the request may be intercepted by the client agent 230. Other embodiments may include another client, agent, or module executing on the remote computing machine 102 that may be stand alone or as a process or subroutine in the client agent 230 or agent container application 235 to intercept network resource requests issued by the plug-in 240. When the additional client, agent, or module intercepts the resource request, the client, agent, or module may determine whether to obtain the resource directly from the network or through a call to the local computing machine 106. Intercepting the request for the resource may include hooking an application interface call to an operating system on the remote computing machine 102. Hooking the application interface call may result in intercepting any requests made to access network 104. In embodiments where it is determined that resources should be acquired from the local computing machine 106 via the virtual channel 255, the request is redirected to the local computing machine 106 over the virtual channel 255 (step 804).

Once the request for the network resource has been intercepted, a determination is made as to whether the requested resource should be obtained from the server 106 (step 812). In many embodiments, this determination may be dynamic such that the module performing method 800 may determine whether to retrieve the requested resource from server 106 by first attempting to retrieve the network resource from client 102. In such embodiments, the module may attempt and access the desired network 104 for downloading or streaming the requested network resource. If the module does not have access to the network and/or cannot download or stream the requested content, the module may determine that a network resource should be downloaded or streamed from server 106 (step 812). In other embodiments, the module may determine that the network resource should be downloaded from the server 106 based in part on the check for the type of resource requested. In some embodiments, the modules may access a database or table (not shown) on the client 102, where the database or table may enumerate whether a particular network resource should be downloaded via the server 106 or directly from the network 104. For example, in some embodiments, the list may indicate that any resources to be streamed should be streamed directly from the network 104. In this embodiment, the module may determine that the resource should not be retrieved from the server 106 (step 812) and the module retrieves or streams the network resource directly from the network 104 (step 810). In other embodiments, a configuration file accessible to the module may be used to determine that a particular request or set of resources should be obtained from the server 106. Upon examining the configuration file, the module may determine whether the network resource should be downloaded to the client 102 from the server 106 or directly from the network 104. In other embodiments, it may be determined whether the network resource should be acquired from the server 106 by examining: the type of plug-in 240 requesting the network resource, the type of resource requested, the user requesting the resource, the client 102 from which the user requested the resource, the amount of bandwidth available on the network, the transfer time associated with the amount of time required to transfer the request and receive the response over the virtual channel 255, the number of user sessions performed on the server 106, whether the requested network resource is on a private network, whether the user and/or client 102 is accessing the network on which the network resource is located, any other factor or parameter that can be used to dynamically determine whether to access the network resource via the virtual channel 255 and server 106 or directly via the network 104. In some embodiments, the determination may be based in part on a check for any of the foregoing factors or parameters. (step 812).

When it is determined that the resource is not to be accessed via the server 106, the network resource is obtained directly from the network 104 via the client 102 (step 810). In this embodiment, the client 102 may obtain the network resource directly from the network 104, download or stream the network resource to the client 102, and forward the requested resource to the plug-in 240. In embodiments where the plug-in 240 may obtain network resources directly from the network 104, the plug-in 240 issues the request and the client agent 230 or another module such as a module, client, agent, subroutine, and processes described herein may access the network and download or stream the requested resources to the plug-in 240. In some embodiments, the requested resource comprises a FLASH movie, and in another embodiment, the requested resource comprises a FLASH video stream.

When it is determined to access the resource via the server 106, the request is redirected to the local computing machine 106 (step 804), which may be received by any of the following: a process or subroutine executed in the agent plug-in 210, the application/desktop delivery system 220, the agent plug-in 210 or the application/desktop delivery system 220, a client, agent or module executing independently on the local computing machine 106 or a third machine remote from the local computing machine 106 but in communication with the local computing machine 106, any other agent that may receive a request. Upon receiving the request, the network resource is retrieved from cache 225, a storage repository on network 104, a third computing machine on network 104, a storage repository on local computing machine 106, or any other location that may hold the requested resource. In some embodiments, network resources are obtained, but in other embodiments, network resources are aggregated or obtained (step 806).

Once the network resources are aggregated together (step 806), they are communicated to the plug-in 240. In some embodiments, the client agent 230 receives the network resource and transmits it to the plug-in 240.

Although specific example embodiments have been described and illustrated in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that the methods and systems described herein are not restricted to the specific architectures and arrangements shown and described. Furthermore, the methods and systems described herein, and portions of their features, may be implemented in hardware, programmable devices, firmware, software, or a combination thereof. The methods and systems described herein, or portions thereof, may also be embodied in a processor-readable storage medium or machine-readable medium, such as a magnet (e.g., hard drive, floppy drive), optical disk (e.g., compact disk, digital versatile disk, etc.), or semiconductor storage medium (volatile and non-volatile).

Claims (38)

1. A method for enabling remote execution of a multimedia plugin call hosted on a server and made by an application remotely accessed by a user via a client, the method comprising:

intercepting, by a proxy multimedia plugin executing on a server, a call issued by a container application executing on the server, the call requesting content from the multimedia plugin executing on the server;

determining, by the proxy multimedia plugin, whether the proxy multimedia plugin is capable of responding to the call;

in response to a determination that the proxy multimedia plugin cannot respond to the call, communicating the call to a proxy container application executing on the client,

transmitting, by the proxy container application, the call to a multimedia plugin executing on the client that corresponds to the proxy multimedia plugin;

the corresponding multimedia plugin generates graphical content in response to the transferred call, and

and displaying the graphical content.

2. The method of claim 1, wherein communicating the call further comprises communicating the call through a delivery application executing on the server.

3. The method of claim 1, wherein displaying the graphical content further comprises displaying the graphical content in a plug-in window on the client.

4. The method of claim 1, wherein requesting content from the multimedia plugin further comprises requesting access to a multimedia plugin interface in the multimedia plugin.

5. The method of claim 1, wherein transmitting further comprises transmitting via a presentation layer protocol over a virtual channel between the server and the client.

6. The method of claim 1, further comprising:

determining that the proxy multimedia plugin is capable of responding to the call; and is

Responding, by the proxy multimedia plugin, to the container application call with the requested content.

7. The method of claim 6, wherein responding with the requested content further comprises responding to the call with content stored in a cache on the server.

8. The method of claim 1, further comprising:

intercepting, by the proxy container application, a call issued by the multimedia plugin, the call requesting content from the container application;

determining, by the proxy container application, that the proxy container application is capable of responding to the issued call; and is

Responding, by the proxy container application, to the multimedia plugin call with the requested content.

9. The method of claim 8, wherein responding to the call with the requested content further comprises responding to the call with content stored in a cache on the client.

10. The method of claim 1, wherein generating graphical content further comprises generating multimedia content.

11. The method of claim 1, wherein displaying graphical content further comprises displaying multimedia content.

12. The method of claim 1, wherein the multimedia plugin is a control and the proxy multimedia plugin is a proxy control.

13. The method of claim 1, further comprising:

obtaining, by the proxy multimedia plugin, window data associated with the proxy multimedia plugin; and is

The window data is transmitted to the multimedia plugin on the client through the proxy multimedia plugin.

14. The method of claim 13, further comprising:

receiving the transmitted window data through the multimedia plugin; and is

Changing, by the multimedia plugin, at least one interface between the multimedia plugin and the proxy container based on the received window data.

15. The method of claim 1, further comprising:

obtaining, by the proxy multimedia plugin, a script interface generated by a script in the container application; and is

And transmitting the script interface to the proxy container application through the proxy multimedia plugin.

16. The method of claim 1, further comprising:

obtaining, by the proxy container application, a script interface generated by a script in the multimedia plugin; and is

The script interface is transmitted to the proxy multimedia plugin through the proxy container application.

17. The method of claim 1, wherein intercepting a call further comprises intercepting a call for a scripting interface.

18. The method of claim 1, further comprising:

accessing, by the multimedia plugin, a network resource via a browser application executing on a client; and is

Downloading the accessed network resource to the multimedia plugin.

19. The method of claim 1, further comprising:

intercepting a request for a network resource generated by the multimedia plugin;

redirecting the request to the server over a virtual channel between the client and the server via a presentation layer protocol;

receiving the requested resource from the server; and is

Forwarding the received resource to the multimedia plugin.

20. A system for enabling remote execution of a multimedia plugin call hosted on a server and made by an application remotely accessed by a user via a client, the system comprising:

a server executing the container application and the proxy multimedia plugin,

a client, executing the multimedia plug-in,

the proxy multimedia plugin corresponds to a multimedia plugin executed on the client;

the proxy multimedia plugin is configured to:

intercepting a call issued by the container application, the call requesting content from the multimedia plugin;

determining whether the proxy multimedia plugin is capable of responding to the call; and is

In response to a determination that the proxy multimedia plugin cannot respond to the call, communicating the call to a proxy container application executing on the client, the proxy container application configured to communicate the call to the multimedia plugin corresponding to the proxy multimedia plugin; and

the multimedia plugin is configured to receive the call, and generate graphical content in response to the received call, and display the graphical content.

21. The system of claim 20, wherein the server further executes a delivery application that communicates the call to the multimedia plugin.

22. The system of claim 20, wherein the multimedia plugin displays the graphical content in a plugin window on the client.

23. The system of claim 20, wherein the container application requests access to a multimedia plugin interface in the multimedia plugin.

24. The system of claim 20, wherein the proxy multimedia plugin transmits the call over a virtual channel between the server and the client via a presentation layer protocol.

25. The system of claim 20, wherein the proxy multimedia plugin:

determining that the proxy multimedia plugin is capable of responding to the call; and is

Responding to the container application call with the requested content.

26. The system of claim 25, wherein the proxy multimedia plugin responds to the call with content stored in a cache on the server.

27. The system of claim 21, wherein the proxy container application:

intercepting a call issued by the multimedia plugin requesting content from the container application;

determining that the proxy container application is capable of responding to the issued call; and is

Responding to the multimedia plugin call with the requested content.

28. The system of claim 27, wherein the proxy container application responds to the call with content stored in a cache on the client.

29. The system of claim 20, wherein the multimedia plugin generates multimedia content.

30. The system of claim 20, wherein the multimedia plugin displays multimedia content.

31. The system of claim 20, wherein the multimedia plugin is a control and the proxy multimedia plugin is a proxy control.

32. The system of claim 20, wherein the proxy multimedia plugin:

obtaining window data associated with the proxy multimedia plugin; and is

The window data is transmitted to a multimedia plugin on the client.

33. The system of claim 32, wherein the multimedia plugin:

receiving the transmitted window data; and is

Changing at least one interface between the multimedia plugin and proxy container based on the received window data.

34. The system of claim 20, wherein the proxy multimedia plugin:

obtaining a script interface generated by a script in the container application; and is

Transmitting the script interface to the proxy container application.

35. The system of claim 20, wherein the proxy container application:

obtaining a script interface generated by a script in the multimedia plugin; and is

The script interface is transmitted to the proxy multimedia plugin.

36. The system of claim 20, wherein the proxy multimedia plugin intercepts a call to a scripting interface.

37. The system of claim 20, wherein the multimedia plugin:

accessing a network resource via a browser application executing on the client; and is

Downloading the accessed network resource to the multimedia plugin.

38. The system of claim 20, wherein the client executes a client agent configured to:

intercepting a request for a network resource generated by the multimedia plugin;

redirecting the request to the server over a virtual channel between the client and the server via a presentation layer protocol;

receiving the requested resource from the server; and is

Forwarding the received resource to the multimedia plugin.