RELATED APPLICATIONSThis application claims the benefit of the earlier filing date under 35 U.S.C. §119(e) of U.S. Provisional Application Ser. No. 61/166,962 filed Apr. 6, 2009, entitled “Method and Apparatus for Providing Vendor Remote Support and Management”; the entirety of which is incorporated by reference.
BACKGROUND OF THE INVENTIONInformation Technology (IT) companies and departments who support their customers' computer systems are constantly challenged with the need to provide timely and cost-effective support to their customers. Remote support provides the means for IT professionals to remotely access and to control customers' computer systems. This eliminates the need for the IT professionals to travel on-site to fix a problem and the delays in response time.
Enterprises (or organizations) have many challenges when receiving support from a technology vendor via remote control or remote access technologies. When a system or application requires support and maintenance from a vendor, the vendor must be granted access in order to service the system or application effectively. Often, each technology vendor uses a different product, leaving the organization receiving support with little or no control over what remote access or remote control technologies are used. Most remote access and remote control tools support only “all or nothing” access, resulting in the vendor having much greater access than is required. Because of this, the organization receiving support does not have the ability to granularly control the permissions, access, and privileges granted to the technology vendor. Moreover, existing approaches do not record the activity of the technology vendor in the process of supporting the organization that is receiving support. In other words, support incidents do not have audit trails. This lack of control and lack of audit-ability undermines the compliance posture of the organization receiving support, thereby increasing the liability associated with receiving technology support from a vendor.
Based on the foregoing, there is a clear need for approaches that provide remote support and management involving multiple vendors.
BRIEF DESCRIPTION OF THE DRAWINGSFIGS. 1A and 1B are, respectively, diagrams of a system and associated process for providing vendor remote support and management, according to certain embodiments;
FIGS. 2A and 2B are, respectively, diagrams of a system and associated process for providing vendor presence on a customer appliance, according to certain embodiments;
FIGS. 3A and 3B are, respectively, diagrams of a system and associated process for providing vendor presence on a customer appliance via a vendor's appliance, according to certain embodiments;
FIG. 4 is a diagram of a network of appliances with vendor presence, according to an exemplary embodiment;
FIGS. 5A and 5B are flowcharts of processes for establishing relationships between vendor and customer remote support systems, according to an exemplary embodiment;
FIGS. 6A-6C are diagrams of a system and associated processes for providing a vendor portal as an agent or a proxy, according to certain embodiments;
FIG. 7 is a diagram of a system capable of providing Push and Start technology within local area network (LAN) as well as remote networks, according to an exemplary embodiment;
FIG. 8 is a diagram of the software architecture of the communication system ofFIG. 1, according to an exemplary embodiment;
FIG. 9 is an exemplary hardware architecture of a remote access and control appliance, according to an exemplary embodiment;
FIG. 10 is a diagram of a computer system that can be used to implement various embodiments of the invention; and
FIG. 11 is a diagram of a chip set that can be used to implement various exemplary embodiments
DESCRIPTION OF THE PREFERRED EMBODIMENTAn apparatus, method, and software for providing a vendor remote support and management system are described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the invention. It is apparent, however, to one skilled in the art that the embodiments of the invention may be practiced without these specific details or with an equivalent arrangement. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the embodiments of the invention.
Although the various embodiments of the invention are described with respect to a wired network, it is contemplated that these embodiments have applicability to other networks including wireless systems.
FIGS. 1A and 1B are, respectively, diagrams of a system and associated process for providing vendor remote support and management, according to certain embodiments. As shown in thesystem100 ofFIG. 1A, a remote access andcontrol appliance101 provides, in certain embodiments, a remote support mechanism that is secure and implemented in a turn-key fashion. For the purposes of illustration, theappliance101 can be deployed by a customer or a vendor and accessed by a vendor or various vendors, and is referred to as a “support appliance”101. The deployedappliance101 can serve as a remote support and management system for the organization that is receiving support from the vendor. In one embodiment, theappliance101 is implemented according to an onsite deployment model. A hosted Software-as-a-Service (Saas) model can also be an offering of this approach where the customers' as well as the vendors' self administered solutions can be in a hosted infrastructure. In addition, theappliance101 can be further defined as a physical or virtual computing system. This can include but not limited to a server rack-mountable server, non-rack-mountable server, desktop computer, laptop computer, and virtual machines.
In one exemplary embodiment, theappliance101 is a rack-mountable (e.g., 1U) network appliance that can be installed and deployed at customers' site; in this manner, data security is in the customers' full control. Additionally, the remote access andcontrol appliance101 has the capability of allowing on demand product use from anywhere in the world. For example, as long as thenetwork appliance101 is deployed accessible via a public Internet Protocol (IP) address, a support user can log in his/her account via aweb interface103 hosted on thenetwork appliance101.
A Representative Client or Application (local client)105 and a Vendor Representative Client orApplication107 can be downloaded from aweb interface103 to provide remote access or support. Also, a Customer Client or Application (remote client)109 can be downloaded by submitting an incident by visiting a vendor/support portal111 of theweb interface103—which can also be hosted on thenetwork appliance101.
Thenetwork appliance101, in various embodiments, execute software applications that can receive, handle, manage, and dispatch system or data messages to and from the RepresentativeClient105, theCustomer Client109, and/orVendor Client107 via a secure connection (e.g., 256-bit Advance Encryption Standard (AES) Secure Sockets Layer (SSL)).
As seen inFIG. 1A, a representative (Rep) at a Representative System113 (i.e., local system) provides support to a customer at a Remote System115 (i.e., Remote Customer System). Additionally, a vendorrepresentative system117 communicates with theappliance101. The traffic between thelocal system113, theremote system115, and thevendor system117 is handled and managed at thenetwork appliance101. Due to the fact that thesystem100 is designed such that all session initiations are outbound towards thenetwork appliance101, the product works through firewalls119-123 and proxy servers.
In this example, therepresentative system113 provides, in certain embodiments, a remote vendor support mechanism that is secure and implemented in a turnkey fashion to one or moreremote customers systems115 via one ormore vendor systems117 over adata network125 using thenetwork appliance101. By way of example, thedata network125 can be an internetwork, such as the global Internet, or a private network. The traffic between therepresentative system113, the vendorrepresentative system117, and anycustomer system115 is handled and managed at thenetwork appliance101. In an exemplary embodiment, thenetwork appliance101 is managed by anadministrator127, who can access thenetwork appliance101 using a graphical user interface (GUI), such as aweb interface111.
The remote access andcontrol appliance101 also enables theadministrator127 to change settings (configuration parameters) on theappliance101 itself, in addition to the software it contains. Theappliance101 also provides management functions including the management of one or morerepresentative systems113 and/orvendor systems117 via theweb interface111. After physical installation of theappliance101, theadministrator127 may log on to the appliance via theweb interface111 by using the appliance's public Uniform Resource Locator (URL) address.
In an exemplary embodiment, therepresentative system113 can communicate with thecustomer system115 and/or thevendor system117 using thenetwork appliance101 via theweb interface111 through one or more firewalls119-123 over respective secure links129-133. These firewalls119-123 may be implemented at the representative's site, the remote customer's site, the vendor's remote site, or a combination thereof. Alternatively, no firewall exists at any of the sites.FIG. 1A illustrates thefirewall119 at the representative's site, thefirewall121 at the remote customer's site, and thefirewall123 at the vendor representative's site. According to one embodiment, therepresentative system113, thecustomer system115, and thevendor representative system117 connect outbound to theappliance101, thereby eliminating firewall incompatibilities. As such, theappliance101 can operate through the firewalls119-123 as well as through proxy servers (not shown).
In certain embodiments,vendor portals111 are created for providing remote access and remote control by theremote vendor system117 tointernal customer systems115 andcustomer applications109. For example, vendor agents' security policies can then be administered to control access rights, remote control permissions, and other parameters and guidelines. Consequently, the vendor support agents are provided with only the level of access to therespective systems113,115, and/or117 that is required to service the systems effectively. In one embodiment, all activities relating to vendor remote access and remote control through one ormore vendor portals111 are recorded and can be audited to ensure compliance with the predetermined regulations. Under this arrangement, support can be received from one or more technical vendors (e.g., via the vendor representative system117), while maintaining complete control over the vendor's level of access as well as a complete audit trail of the vendor's activity within thesystem100. This decreases the potential liability associated with receiving technology support from an external vendor.
In addition to providing a secure means to receive support from a technology vendor, the vendor remote support and management system provided via theappliance101 can be extended to enable the technology or technology services vendor to support their customers more securely and efficiently through establishing a connection between the vendor's remote support system (e.g., facilitated via anetwork appliance101 operated by the vendor) and their customers' remote supportsystem vendor portals111. For example, the customers can themselves utilize or operate a remote support and management system through anothernetwork appliance101; accordingly, the customers' remote support and management systems (e.g., executing on acommon network appliance101 or respective other network appliances101) can be accessed via theirrespective vendor portals111. In this manner, the vendor can create and administer support agent accounts for their own remote support and management system. The vendor's support agents can then log into their own secure and self-administered system, and then, through an established connection (e.g., secure connections129-133) to their customer's secure and self-administered system'svendor portal111, the reps can gain access to the customer'ssystems115 andapplications109. In this way, both the organization receiving support and the technology vendor can administer their own approaches orrespective appliances101. However, even though the Support Solutions are connected, the organization (e.g., the customer) receiving support has complete control over the permissions of the vendor's support agents when those agents are accessing the organization'ssystems117 andapplications107. Similarly, with connected vendor remote support and management systems, the vendor organization can administer its own support agents and easily remotely access its customers'systems115 andapplications109, while at the same time giving its customers complete control over vendor's access permissions and complete visibility into the vendor's activity. Additionally, connectedappliances101 provide both the vendor and the organization receiving support auditable reports on support agent activity and reports of support agent performance.
A standardized, secure vendor remote support and management system via theappliance101 such as described herein will provide a means not only for giving support to users and customers but also a means of receiving support from their vendors.
In one embodiment, thevendor portal111 can also be extended to serve as a proxy for all attended (when an end user is present) as well as unattended (when an end user is not present) support. In an unattended scenario, thevendor portal111 can be used as a mechanism to push a remote support executable to anend system115 and/or used as a mechanism to initiate apre-installed client109 to establish a remote support session back to the support agent. Forpreinstalled clients109, thisvendor portal111 can also serve as an agent to collect data and statuses related to theremote systems115. The data can be later synched with a connected vendor remote support and management system. Forremote systems115 that are not connected to the internet, thisvendor portal111 can also serve as a proxy for all remote access and remote control data, enabling a technology vendor to support systems over the internet even if the supportedsystems115 are not directly connected to the internet.
Thevendor portal111 can also be used to conduct training.
Furthermore, it is noted that the self administered customer's vendor remote support andmanagement system101 can serve as a vendor's vendor remote support andmanagement system101. Hence, a customer can be a vendor, and vice versa.
By way of illustration, the following scenarios are described for deployment of the vendor remote support and management appliance101: (1) ad-hoc vendor remote support; (2) unmediated vendor remote support and management; and (3)vendor portal111 as an agent and a proxy.
With respect to ad-hoc vendor remote support, it is recognized that an internal support agent sometimes requires third-party assistance in providing support to an internal or external end-user orsystem115. In this scenario (as shown in theprocess140 ofFIG. 1B), a request for assistance is sent to the vendor support agent and access privileges to the end system are granted ad-hoc (step141). The vendor or third party support agent downloads the remote support application used for providing support, logs on with provided valid credentials or without requiring credentials (step143), and joins or views the remote support session to assist the internal support agent in troubleshooting or supporting the end system (step145). The internal support agent may be present throughout the remote support session or leave the remote support session after the vendor support agent joins the session (step147).
FIGS. 2A and 2B are, respectively, diagrams of a system and associated process for providing vendor presence on a customer appliance, according to certain embodiments. Theprocess220 ofFIG. 2B is described with respect to the diagram ofFIG. 2A. For this scenario, a vendor support agent requires unmediated access to an organization'ssystems115 andapplications109. This level of access can be enabled by creating avendor portal111 that controls access privileges and permissions. With thisvendor portal111, the vendor support agent (e.g., via the vendor representative system117) can provide attended or unattended remote support for the customer'ssystems115 andapplications109 via remote access and remote control. A customer's vendor remote support and management system provided by thesupport appliance101 can havemultiple vendor portals111.
By way of example, two approaches are described. One approach provides vendor presence in a customer environment201 that includes the customer remote support system (e.g., facilitated by the customer's own network appliance101). In this scenario (depicted inFIG. 2A and described with respect to process220 ofFIG. 2B), the vendor support agent accounts and restrictions are managed and provisioned on the customer's appliance101 (step221 ofFIG. 2B). The customer administers a team of vendor support agent accounts that are used only by a specific vendor within the customer environment201. The customer can create and administer multiple such teams for multiple vendors. The vendor support agents in this scenario must use access credentials, privileges, and security policies set forth by the customer (step223 ofFIG. 2B). This team created for vendor support agents serves as a component of the vendor presence on the customer system orappliance101. The combination of team, restrictions, and access interfaces are components that make up thevendor portal111 in this scenario.
In another approach, vendor presence is on the customer system through relationship with the vendor system.
FIGS. 3A and 3B are, respectively, diagrams of a system and associated process for providing vendor presence on a customer appliance via a vendor's appliance, according to certain embodiments. Theprocess320 ofFIG. 3B is described with respect to the diagram ofFIG. 3A. As seen inFIG. 3A, the vendor support agent accounts are managed and provisioned on the vendor's self-administered system of thevendor support appliance101a(step321 ofFIG. 3B). Thevendor portal111 on thecustomer appliance101benables the customer to further manage, provision, and restrict the vendor support agents as a whole unit or entity which is connected to the vendor portal through thevendor appliance101aover the data network125 (step323 ofFIG. 3B).
FIG. 4 shows a network of remote support systems with vendor presences through connections with vendor systems, according to one embodiment. In one embodimentmultiple network appliances101a-101dmay have connectivity and establish relationships over thedata network125 to form a support system. For example, a customer system can act as a vendor system; and a vendor system can act as a customer system if configured to do so (for example: a technology vendor may also be a customer to other technology vendors). As shown inFIG. 4, aremote customer system115 and vendorrepresentative systems117a-117 have interrelated support systems via theirrespective support appliances101a-101d.In this example, thesupport appliance101aof thecustomer system115 includesweb portals111 a for remote support from vendorrepresentative systems117a(e.g., Vendor A) and117b(e.g., Vendor B).
Vendor A, in turn, includes aninternal system401awhich has connectivity to asupport appliance101bthat includesweb portals101bfor vendorrepresentative systems117a(e.g., Vendor B) and117c(e.g., Vendor C). In other words, Vendor A provides support to theremote computer system115 via the Vendor Arepresentative system117awhile also receiving support for itsinternal system401afrom Vendors B and C. Similarly, Vendor B and Vendor C also both provide and receive support from the various depicted vendors. In this case, theinternal system401bof Vendor B has connectivity to asupport appliance101cwith web portals for Vendor A'srepresentative system117aand Vendor C'srepresentative system117c,and theinternal system401cof Vendor C has connectivity to asupport appliance101dwith web portals for Vendor A'srepresentative system117aand Vendor B'srepresentative system117b.
FIGS. 5A-5B show the configuration methods of establishing a relationship between a Vendor's remote support appliance and the organization receiving the vendor's support portal on the organization's remote support appliance, according to various embodiments. As seen in theprocess500 ofFIG. 5A, thevendor portal111 on the customer'ssupport appliance101ais configured as to establish a relationship with the vendor'ssupport appliance101b(step501) Subsequently, vendor presence is provided on the customer system (step503). In another embodiment (shown in theprocess520 ofFIG. 5B), an entity of the vendor agents on the vendor system orappliance101bis configured to be responsible for supporting a specific customer (step521). Thus, a relationship is established with thecorresponding vendor portal111 on thecustomer appliance101a(step523).
FIGS. 6A-6C are diagrams of a system and associated processes for providing a vendor portal as an agent or a proxy, according to certain embodiments. Theprocess600 ofFIG. 6B and theprocess620 ofFIG. 6C are described with respect to the diagram ofFIG. 6A. As shown inFIG. 6A,remote customer systems115a-115eare connected over a local area network (LAN)601 at a customer site. Each of theremote customer systems115a-115emay have no direct connectivity, limited direct connectivity, or full connectivity to thedata network125. In other words, all or a portion of thesystems115a-115emay have varying levels of connectivity to the Internet and, therefore, varying levels of connectivity to Vendor Arepresentative system117 for remote support. In this example, theLAN601 includes asupport appliance101awith connectivity viavendor portals111aover thedata network125 to anothersupport appliance101boperated by Vendor A. Further, each of theremote customer systems115a-115ehas connectivity to thesupport appliance101a.By way of example, thesupport appliance101bhas connectivity to the Vendor Arepresentative system117 and a Vendor Ainternal system603.
Given the connectivity and configuration of the components described inFIG. 6A, the vendor portal on the customer appliance can serve as an agent for both attended and unattended support scenarios as described in the processes ofFIGS. 6B and 6C. As shown in theprocess600 ofFIG. 6B, one such support scenario is through enabling a remote support application to be pushed to a remote system, executed, and connected back to the vendor support agent via the vendor appliance (step601). For unattended systems that have been configured with a preinstalled remote support client, the vendor portal agent can serve as the collection agent for updates and statuses from the remote support client (step603). The vendor portal agent can send these collective updates and statuses to the vendor appliance in a batched manner periodically (step605).
As shown in theprocess620 ofFIG. 6C, for attended and unattended support scenarios in which the end systems do not have access to a public data network (e.g., Internet) (step621), the vendor portal can serve as a proxy (step623), enabling the vendor support agent to access end systems through the internet indirectly through the vendor portal even though the end systems do not have direct internet access (step625).
FIG. 7 is an illustration of a system capable of providing Push technology within a local area network (LAN) as well as within a remote network, according to an exemplary embodiment. Traditional remote support approaches using remote control and visualization application tool is one of the means to efficiently provide assistance to remote users. In addition to attended remote support, a means to remotely access or control unattended systems further improves the efficiency of support organizations. Without the need for pre-installed clients on a system, a Push and Start System can be used by the representatives of a support organization to transfer an application to an attended or unattended remote system and execute the application to establish a session connection back to the representative. The Push functionality provides reach to systems which are visible from within the network that the support representative's computer is connected to via a Local Push method and reach to systems within remote networks through a Push via a Push Agent mechanism.
Within an exemplary context of remote support by remote controlling or accessing another computer, “Push” is a feature that allows a support representative to transfer an application to a remote computer in need of support and have the application executed whereby enabling the support representative to then remotely control or access the remote computer. No interaction is required at the remote computer for the process to complete, but interaction may optionally be enabled that allows any user present at the remote computer to refuse access for whatever reason. The support representative may or may not be required to have or to enter authentication/authorization credentials to gain access to the computer in need of support. The requirement of credentials would depend on the transfer and/or execution method used in the Push process. Furthermore, this process, unlike conventional approaches, requires no existing piece of the support product to have been previously installed on the remote computer.
In one embodiment, the actual Push of software to the remote computer and its execution can be accomplished via SMB (System Management Bus), Windows RPC (Remote Procedure Calls)/IPC (Inter Process Communication), Unix/Posix RPC, FTP (File Transfer Protocol), SSH (Secure Shell), HTTP (Hypertext Transfer Protocol) or other means.
The system, according to various embodiments, utilizes the following components (not shown): (1) a representative client application; (2) a Push Server—which is what handles the operations in within the appliance; (3) an optional Push Agent; and (4) a customer client application. It is contemplated that the Push Agent (e.g., Push Agent701) can be an application that is installed on a system or alternatively can be a stand alone piece of hardware. The Push Server can be an application installed on anappliance101 or a system (e.g.,representative system703,remote system705, orremote system707 of the data network709) or alternatively can also be a stand alone piece of hardware. The Push Server can also be a piece of software integrated into the representative client application (e.g., executing on the representative system703) where it serves its purpose within the application in the background.
Furthermore, thisPush Agent701 can be used as an agent for other purposes, such as a connection agent to another server (not shown) in its network (e.g., the network711) or a second network (e.g.,networks709 or713); that is, providing a connection to and forwarding of operations via aPush Agent701, from thefirst network709 to a device of a second network (e.g., devices717-721 of thenetwork711 or devices723-727 of the network713) via, for instance, athird network715.
In this example, a customer client application resident within a remote access andcontrol appliance101 or a Push server (not shown) can be accessed by aservice representative system703 which is running a representative client application. The customer client application can be transferred to a remote system in this network (Local Push) (e.g.,remote systems705 and707 of the network709) by utilizing a ‘Push Agent’ system or theservice representative system703's representative client application. In this manner, an IT service representative, for instance, can perform problem resolution, maintenance, and infrastructure development tasks quickly and easily from a single point.
The network visibility of the support representative'scomputer703 is limited to the networks to which it is connected. Therefore, with no extra means provided, the reach of the Push feature from the support representative's computer is limited to only those computers to which network traffic is routable. To extend this range, aPush Agent701 is introduced; for example, one such an agent is known as Jumpoint™ by Bomgar™. ThePush Agent701, in an exemplary embodiment, is an application installed on a computer that can perform the push-and-execute operation on behalf of authorized support representatives. Alternatively, thePush Agent701 can be a standalone piece of hardware. The support representatives may be in contact with thePush Agent701 by their mutual participation on anoverlay network715, by HTTP (Hypertext Transfer Protocol), VPN (Virtual Private Network), by programmatic email, or by any other means devised for the support representative's computer to communicate with thePush Agent701. The ‘Push Agent’ supports a fully integrated software distribution mechanism for ease of installation of the remote access and control Push Agent on a managed system (e.g., remote access andcontrol appliance101 or computer) over thenetwork715.
It is contemplated that thePush Agent701 can be an application that is installed on a system or alternatively can be a stand alone piece of hardware. The Push Server can be an application installed on an appliance or a system or alternatively can also be a stand alone piece of hardware. The Push Server can also be a piece of software integrated into the representative client application where it serves its purpose in within the application in the background.
Furthermore, thisPush Agent701 can be used as an agent for other purposes, such as a connection agent to another server (not shown) in the second network; that is, providing a connection to and forwarding of operations via aPush Agent701, from a first network to a device of a second network.
After the support representative system is connected to the remote Push Agent701 (which resides within anappliance101 or a computer) via the Push Server, theservice representative system703 prompts theremote Push Agent701 to transfer an application to a remote computer (e.g., remote systems723-725), which resides outside of the network. In an exemplary embodiment, a Web browser based remote control is available and can perform a push instruction from a remote site to a targetedPush Agent701. Upon receiving a request, theremote Push Agent701 transfers the application to a client remote system. In this manner, integrated remote access and control tools enable both efficient remote problem resolution and critical visibility limitation when deploying application to a targeted client remote system. This also enables a service representative to efficiently implement application tools and maintain security throughout the enterprise right from the representative's desk.
In an exemplary embodiment, theappliance101 uses certificate-based authentication to establish a persistent connection to thePush Agent701. When requesting a remote control session on a remote system via the Push functionality, theappliance101 ensures that the representative703 has the right to push the customer client application to a targeted remote client system (e.g., remote systems717-721). The customer client application then can be transferred from thePush Agent701 to the remote client system. The remote client system can then establish a session connection to the service representative's system. In some cases, the session connection traverses one or more firewalls727-731 as previously described.
FIG. 8 is a diagram of the software architecture of the communication system ofFIG. 1, according to an exemplary embodiment. The product data transfer architecture, in one embodiment, is formed based on a message handling and routing system—denoted as a Message Router System (MRS) which includes a collection of MRS modules (i.e.,MRSm801a). The MRSm's801a,803d,and805dprovide a message routing system that enables the routing of data within envelopes among theappliance801,representative system803 andremote customer system805 with, for example, mailboxes as data endpoints. The mailboxes, which can be used for sending and receiving data, are also responsible for all handling of encoding (creation) and decoding of message envelopes with appropriately designed read and write methods. By way of example, the message envelope can include the following fields: a fromRouterID field specifying an identifier associated with theMRS801a,a toRouterAddress field specifying addressing information of the destination routing module.
In addition, theMRS801acan communicate with other modules in a manner similar to that described above. By way of example, theMRSm801acan communicate with theweb interface811, amessage manager801b,amessage processor module801c(includes chat, permission, logging, etc.), a present/training801d,asecure layer module801f(e.g., SSL wrapper module), and arecorder module801g.Theweb interface811 can communicate with other application modules via theMRS801a.
In an exemplary embodiment, theweb interface811 includes the following: (1) a network configuration web interface; (2) a User/Admin web interface which includes but not limited to user profile configuration, log reporting interface, and administrative user interface; (3) a support portal that provides, in an exemplary embodiment, front end survey and session key submission components; and (4) a customer satisfaction (exit) survey. According to one embodiment, the web interface provides functions for configuring theappliance801 to be deployed and integrated into the network infrastructure of the installer. In one embodiment, all other interfaces can communicate through theMRSm801aor to astorage module801edirectly.
For ensuring proper dispatching of system messages received at theMRSm801a,amessage manager801bcan be used in this exemplary embodiment. These messages can include such data as chat data, session system data logging, system message posting, and system message queries, etc.
Themessage processor module801creceives system messages fromMRSm801avia themessage manager module801b.These messages can include such date as chat, session system data logging, system message posting, system message queries, permissions queries, and storage data retrievals.
The present-training module801dis configured to reduce the amount of screen update data transmitted from the client-side. In an exemplary embodiment, the present-training module801dincludes the following components (not shown): a viewer component, and one or more remote screen image servers. These servers collect RSI change updates and send them on to the RSI viewer via theMRSm801a.The viewer component receives RSI update data from a client-side (remote-side in this case) server via theMRSm801aand then sends the data off to the active servers to be transmitted to the appropriate destination. The main stream of RSI update data can be transmitted to the appropriate client via theMRSm801a.Another stream of screen update data is transmitted to therecorder module801gto be written into thestorage module801e.
TheSSL module801fensures that the data transfer between theappliance801 and the representative and customer system (803 and805) is encrypted, e.g., 256-bit AES SSL encryption overlinks817 and819.
In one embodiment, the remote access andcontrol appliance801 utilizes an operating system (OS)801hthat supports a variety of applications. For example, a web server application can run on top of theOS801hto provide web hosting capabilities. TheOS801hcan also support SSL. TheSSL wrapper module801fprovides SSL over Transmission Control Protocol (TCP) or other network protocols.
As described, in one embodiment, the network appliance utilizes anOS801hwith a web server for providing web hosting capabilities. The routing and handling module (e.g., MRSm)801a,which is a transport layer atop theOS801h,provides various network facilities. Accordingly,MRSm801aprovides the generic means of transporting data from one system to another.
TheMRSm801aof thenetwork appliance801 can communicate with the customer application ofcustomer system805, and the representative application of therepresentative system803 or another appliance.
Under this example, therepresentative system803 andcustomer system805 includeoperating systems803a,805a;backend components803b,805b;andGUIs803c,805c.Thebackend components803bof therepresentative system803 can include aMRSm803d,amessage manager module803e,and a filetransfer manager module803f.Themodule803finterfaces with a storage module803g,which is configured to store retrieved content stemming from the operation of the filetransfer manager module803f.Thebackend components803balso include aRSI manager module803h.Yet another module803i(i.e., OS interface module), which is integral to thebackend components803b,provides communication interfaces to theOS803a.As shown, thebackend components805bof thecustomer system805 resemble that of thebackend components803bof the representative system803: aMRSm805d,amessage manager module805e,and a file transfer manager module805f,a storage module805g,aRSI manager module805h,anOS interface module805i.
As for theGUI803c,therepresentative system803 can provide a number of interfaces depending on the applications. For instance, theGUI803ccan include achat interface803j,afile transfer interface803k,a queue interface803l,and aviewer803m.In this example, thecustomer system805 utilizes achat interface805jand aviewer805k.TheGUI803ccan include other interfaces such as remote command shell, system diagnostics, and system information to name a few. TheGUI805ccan include application specific chooser interface to only allow specific application viewing.
As explained with respect to the operation of thenetwork appliance801, theMRSm803dis the medium for handling all messages coming to the representative application821 and all messages sent from the representative application821. TheMRSm803dcommunicates with themessage manager803e,aRSI manager803h,and the file-transfer manager modules803f.The system messages, session data, and chat data are delivered to themessage manager module803e.TheMRSm803dsends, as well as receives, system/control messages and RSI update data to and from theRSI manager module803h.TheMRSm803dinteracts with the file-transfer manager803fin sending and receiving system messages and file-transfer data.
The file-transfer manager803fhandles all remote-to-local and local-to-remote (i.e. between the representative system and the customer system) reading and writing of files. The system messages and file-transfer data are received and sent through theMRSm803d.Notably, the file-transfer interface module803kon theGUI component803creceives data from theMRSm803dand sends all data directly to theMRSm803d.Assuming the permissions to the customer file system access have been granted, the processes and steps involved in transferring a file from representative storage803gto the customer storage805ginclude an initiation of a file transfer from the file-transfer GUI, a system command message sent to theMRSm803d.MRSm803ddelivers the command to the file-transfer manager module803fto execute on constructing the data to be sent toMRSm805dof thecustomer system805 via theMRSm803d.A system notification message is delivered to themessage manager803eviaMRSm803dto be displayed in thechat GUI803jafter being delivered there by themessage manager803e.The processes and steps involved in transferring a file from the customer to the representative include an initiation from the file-transfer GUI805k,a system command message sent to the file-transfer manager805fvia thecustomer MRSm805d.The file-transfer manager805fconstructs a proper remote file transfer request, which is then sent through thecustomer MRSm805dto therepresentative MRSm803dthrough theMRSm801aon the appliance. Therepresentative MRSm803dreceives the request command, delivering it to the remote file-transfer manager803f,which in turn, receives the file system data requested to be transmitted back to thecustomer MRSm805dby therepresentative MRSm803dthrough theMRSm801aon the appliance. Therepresentative MRS803ddelivers the file system data received from thecustomer MRS805dto the file-transfer manager803ffor processing and storing in the local file system storage803g.Also, a system notification message as well as a file-transfer GUI refresh command is delivered to the file-transfer GUI803kvia thedispatcher803efrom theMRS803d.
TheRSI manager modules803hand805h,in one embodiment, includes the following components: a RSI updater, which “paints” theRSI viewer GUIs803mand805kwith RSI screen update data; RSI server, which utilizes the OSCommunication Interface modules803iand805i.The OScommunication interface modules803iand805iinterfaces with theOS system803aand805afor detecting and listening for screen and system updates, collecting these updates, and packaging and encoding these updates into data to be then sent to the viewing system via the respective MRSm's.
TheRSI manager modules803hand805hcan also provide the capability of reverse viewing. In this mode, the viewing of the remote system is reversed to being viewed by the remote system.
Thenetwork appliance801 also permit support representatives to predict and lower the total cost of ownership (TCO) vis-à-vis the ASP model, in which the support representatives are typically charged a monthly fee. With thenetwork appliance801, representatives can predict their budget without monthly fees, surcharges or overages.
FIG. 9 is an exemplary hardware architecture of a remote access and control appliance, according to an exemplary embodiment. Thenetwork appliance101, in one embodiment, comprises various component interfaces, including serial andparallel ports901 and903, a display interface (e.g., an RGB (Red, Green and Blue) port905), local area network (LAN) ports (e.g., Ethernet ports)907 and909, and input device ports (e.g., PS2)911 and913. Thenetwork appliance101 also contains apower regulator915, internal memory in the form of RAM (Random Access Memory)917, one ormore processors919, each which may be a multi-core processor, LEDs (Light Emitting Diodes)937, resetcontrol935 and a SATA (Serial Advanced Technology Attachment)storage drive933.
As mentioned, thenetwork appliance101, in an exemplary embodiment, can be a 1U rack-mountable server hardware. However, it is contemplated that configurations other than those illustrated inFIG. 9 can be constructed, depending on the particular applications. For example, different types of appliances can be designed for different uptime requirements. With uptime-critical customers, thenetwork appliance101 provides for fail-over redundancies; e.g., use of multiple disk drives927-931, for Fail-over and Hot-Swap capabilities via a RAID (Redundant Array of Independent Disks)controller921. This configuration of theappliance101 can also be equipped with a backup AC-DC (Alternating Current-Direct Current)regulator923, which can be triggered when themain regulator915 is detected as non-functional. Alternatively, for non-uptime-critical customers, thenetwork appliance101 can be configured without the additional hardware and/or software required for providing redundancies.
Thenetwork appliance101 is configured to communicate with therepresentative system113, thecustomer system115, and thevendor representative system117 and can be collocated within any of these systems113-117. Thenetwork appliance101, in various embodiments, execute software applications that can receive, handle, manage, and dispatch system or data messages to and from the representative, vendor, and customer applications105-109 within the respective systems113-117 via secure links129-133. In one embodiment, the security on these links is achieved using the 256-bit Advance Encryption Standard (AES) Secure Sockets Layer (SSL).
As earlier described, thenetwork appliance101, in an exemplary embodiment, can be a virtual appliance. Such software appliance can be run in a virtual environment. For instance, an image of the operating system and base software application can be installed on a virtual machine. Virtualization provides an abstraction layer that separates the operating system from the hardware, as to permit resource sharing. In this matter, different virtual machines (using heterogeneous operating systems) can co-exist on the same hardware platform.
On the customer side, thecustomer application109 is installed temporarily (in one embodiment). Thecustomer application109, in an exemplary embodiment, can be a native application, as to achieve a reduced executable size for quick download by the remote customer from thenetwork appliance101. Architecturally, thisapplication109 can be identical to therepresentative application105 and or thevendor application107. One difference with thisapplication107 is the use of an uninstaller component, in which theapplication107 is capable of uninstalling itself when, for example, a session is completed with proper termination, a session is ended by the user of thiscustomer application109, or a session connection timed out. In the alternative, thecustomer application109 can be permanently installed.
With the above arrangement, therepresentative application105 and/or thevendor application107 via thenetwork appliance101 can securely communicate with thecustomer application109 to access and control thecustomer system115.
The processes described herein for providing vendor remote support and management via software, hardware (e.g., general processor, Digital Signal Processing (DSP) chip, an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Arrays (FPGAs), etc.), firmware or a combination thereof. Such exemplary hardware for performing the described functions is detailed below.
FIG. 10 illustrates computing hardware (e.g., computer system) upon which an embodiment according to the invention can be implemented. Thecomputer system1000 includes abus1001 or other communication mechanism for communicating information and aprocessor1003 coupled to thebus1001 for processing information. Thecomputer system1000 also includesmain memory1005, such as random access memory (RAM) or other dynamic storage device, coupled to thebus1001 for storing information and instructions to be executed by theprocessor1003.Main memory1005 also can be used for storing temporary variables or other intermediate information during execution of instructions by theprocessor1003. Thecomputer system1000 may further include a read only memory (ROM)1007 or other static storage device coupled to thebus1001 for storing static information and instructions for theprocessor1003. Astorage device1009, such as a magnetic disk or optical disk, is coupled to thebus1001 for persistently storing information and instructions.
Thecomputer system1000 may be coupled via thebus1001 to adisplay1011, such as a cathode ray tube (CRT), liquid crystal display, active matrix display, or plasma display, for displaying information to a computer user. Aninput device1013, such as a keyboard including alphanumeric and other keys, is coupled to thebus1001 for communicating information and command selections to theprocessor1003. Another type of user input device is acursor control1015, such as a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to theprocessor1003 and for controlling cursor movement on thedisplay1011.
According to an embodiment of the invention, the processes described herein are performed by thecomputer system1000, in response to theprocessor1003 executing an arrangement of instructions contained inmain memory1005. Such instructions can be read intomain memory1005 from another computer-readable medium, such as thestorage device1009. Execution of the arrangement of instructions contained inmain memory1005 causes theprocessor1003 to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the instructions contained inmain memory1005. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the embodiment of the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
Thecomputer system1000 also includes acommunication interface1017 coupled tobus1001. Thecommunication interface1017 provides a two-way data communication coupling to anetwork link1019 connected to alocal network1021. For example, thecommunication interface1017 may be a digital subscriber line (DSL) card or modem, an integrated services digital network (ISDN) card, a cable modem, a telephone modem, or any other communication interface to provide a data communication connection to a corresponding type of communication line. As another example,communication interface1017 may be a local area network (LAN) card (e.g. for Ethernet™ or an Asynchronous Transfer Model (ATM) network) to provide a data communication connection to a compatible LAN. Wireless links can also be implemented. In any such implementation,communication interface1017 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information. Further, thecommunication interface1017 can include peripheral interface devices, such as a Universal Serial Bus (USB) interface, a PCMCIA (Personal Computer Memory Card International Association) interface, etc. Although asingle communication interface1017 is depicted inFIG. 10, multiple communication interfaces can also be employed.
Thenetwork link1019 typically provides data communication through one or more networks to other data devices. For example, thenetwork link1019 may provide a connection throughlocal network1021 to ahost computer1023, which has connectivity to a network1025 (e.g. a wide area network (WAN) or the global packet data communication network now commonly referred to as the “Internet”) or to data equipment operated by a service provider. Thelocal network1021 and thenetwork1025 both use electrical, electromagnetic, or optical signals to convey information and instructions. The signals through the various networks and the signals on thenetwork link1019 and through thecommunication interface1017, which communicate digital data with thecomputer system1000, are exemplary forms of carrier waves bearing the information and instructions.
Thecomputer system1000 can send messages and receive data, including program code, through the network(s), thenetwork link1019, and thecommunication interface1017. In the Internet example, a server (not shown) might transmit requested code belonging to an application program for implementing an embodiment of the invention through thenetwork1025, thelocal network1021 and thecommunication interface1017. Theprocessor1003 may execute the transmitted code while being received and/or store the code in thestorage device1009, or other non-volatile storage for later execution. In this manner, thecomputer system1000 may obtain application code in the form of a carrier wave.
The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to theprocessor1003 for execution. Such a medium may take many forms, including but not limited to non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as thestorage device1009. Volatile media include dynamic memory, such asmain memory1005. Transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise thebus1001. Transmission media can also take the form of acoustic, optical, or electromagnetic waves, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, CDRW, DVD, any other optical medium, punch cards, paper tape, optical mark sheets, any other physical medium with patterns of holes or other optically recognizable indicia, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave, or any other medium from which a computer can read.
Various forms of computer-readable media may be involved in providing instructions to a processor for execution. For example, the instructions for carrying out at least part of the embodiments of the invention may initially be borne on a magnetic disk of a remote computer. In such a scenario, the remote computer loads the instructions into main memory and sends the instructions over a telephone line using a modem. A modem of a local computer system receives the data on the telephone line and uses an infrared transmitter to convert the data to an infrared signal and transmit the infrared signal to a portable computing device, such as a personal digital assistant (PDA) or a laptop. An infrared detector on the portable computing device receives the information and instructions borne by the infrared signal and places the data on a bus. The bus conveys the data to main memory, from which a processor retrieves and executes the instructions. The instructions received by main memory can optionally be stored on storage device either before or after execution by processor.
FIG. 11 illustrates a chip set1100 upon which an embodiment of the invention may be implemented. Chip set1100 is programmed to present a slideshow as described herein and includes, for instance, the processor and memory components described with respect toFIG. 10 incorporated in one or more physical packages (e.g., chips). By way of example, a physical package includes an arrangement of one or more materials, components, and/or wires on a structural assembly (e.g., a baseboard) to provide one or more characteristics such as physical strength, conservation of size, and/or limitation of electrical interaction. It is contemplated that in certain embodiments the chip set can be implemented in a single chip. Chip set1100, or a portion thereof, constitutes a means for performing one or more steps ofFIGS. 2B,3B,5A,5B,6B, and6C.
In one embodiment, the chip set1100 includes a communication mechanism such as a bus1101 for passing information among the components of the chip set1100. Aprocessor1103 has connectivity to the bus1101 to execute instructions and process information stored in, for example, amemory1105. Theprocessor1103 may include one or more processing cores with each core configured to perform independently. A multi-core processor enables multiprocessing within a single physical package. Examples of a multi-core processor include two, four, eight, or greater numbers of processing cores. Alternatively or in addition, theprocessor1103 may include one or more microprocessors configured in tandem via the bus1101 to enable independent execution of instructions, pipelining, and multithreading. Theprocessor1103 may also be accompanied with one or more specialized components to perform certain processing functions and tasks such as one or more digital signal processors (DSP)1107, or one or more application-specific integrated circuits (ASIC)1109. ADSP1107 typically is configured to process real-world signals (e.g., sound) in real time independently of theprocessor1103. Similarly, anASIC1109 can be configured to performed specialized functions not easily performed by a general purposed processor. Other specialized components to aid in performing the inventive functions described herein include one or more field programmable gate arrays (FPGA) (not shown), one or more controllers (not shown), or one or more other special-purpose computer chips.
Theprocessor1103 and accompanying components have connectivity to thememory1105 via the bus1101. Thememory1105 includes both dynamic memory (e.g., RAM, magnetic disk, writable optical disk, etc.) and static memory (e.g., ROM, CD-ROM, etc.) for storing executable instructions that when executed perform the inventive steps described herein to presenting a slideshow via a set-top box. Thememory1105 also stores the data associated with or generated by the execution of the inventive steps.
While the invention has been described in connection with a number of embodiments and implementations, the invention is not so limited but covers various obvious modifications and equivalent arrangements, which fall within the purview of the appended claims.