FIELD OF THE INVENTION
Remote online support services over the internet to the end customer. Online services system that allows implementation of remote services to any internet enabled network appliance in the world without being aware of its exact internet location.
BACKGROUND OF THE INVENTION AND PRIOR ART
Online support service traditionally is a process driven model and it is very difficult to enable this to work remotely. Though the internet has evolved rapidly the end users have not and the result is that a lot of support is manually executed and personal contact is considered absolutely essential. In today s information world, a wide variety of services that can be deployed remotely are essential to keep our customer s business secure. Our revolutionary services model is designed to keep all our small and medium customers adequately supported.
In order for the desired behavior to be achieved with the current internet setup, the server needs to be executed within the client network. Web servers need static internet (IP) addresses to be effective otherwise they would not be visible to the outside world. Client networks very rarely have static IP addresses because it is not cost effective nor is it scalable for their ISP. Almost all clients would use NAT thus making it impossible for the outside world to connect to them effectively. This server needs to be accessible all the time which is not possible considering that most offices run their internet connections temporarily like broadband, dialup, cable modems, etc. The firewall on the client side will stop all incoming requests irrespective of its nature because of the type of information security required
The present technology provides solution to overcome the aforesaid obstacles by online support channel.

OBJECTS OF THE INVENTION
The primary object of the present invention is an online services system that allows
implementation of remote services to any internet enabled network appliance in the world
without being aware of its exact internet location.
Yet another object of the present invention is to provide a solution to overcome the
aforesaid obstacles by online support channel.
Still another object of the present invention is to provide the process to remove the need
for support personnel on site at all possible times irrespective of the geographical location
of the appliance.
Still another object of the present invention wherein service connection between the
UniVault appliance and our support servers is made independent of the IP address,
Internet Service Provider in use by the customer, geographical location, internet proxy,
type of connection (be it broadband, dialup, DSL, etc) or any firewall deployed by our
customer to protect his network.
Still another object of the present invention wherein service connection does not depend
on the operating system or any other operating component between the service and the
target.
Still another object of the present invention is to provide controlled lifecycle management
system for appliances all the way from manufacturing to deployment and eventually to
obsoletion irrespective of its geographical location by using internet enabled technology.
STATEMENT OF THE INVENTION
A method for remote online support services over the internet to the end customer, said method comprises steps of; configuring network appliance with network elements at customer; connecting support server with configured appliance; Initiating a service connection or a logical control/data session by the connected server and thereby sending command/request for complete network element administration; and saving and indexing the sessions for accurate audits to provide online support services, and also A system for remote online support services over the internet to the end customer, said system comprises; network appliance for instantiating a service connection; support

server for sending commands/requests; means for connecting customer, Network appliance and support server; and means for saving and indexing the sessions.
BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS
Figure 1 shows online support service process paradigm.
Figure 2 shows typical HTTP client-server paradigm.
Figure 3 shows online support service model using reversed HTTP.
Figure 4 shows understanding online support service transport.
Figure 5 shows Inst-Session Sequence Diagram.
Figure 6 shows Inst-Session Transport Interface.
Figure 7 shows Remote Application Control.
Figure 8 shows Inst-Session State Transition & Recovery.
Figure 9 shows Inst-Session Relationship with Trouble Tickets.
DETAILED DESCRIPTION OF THE INVENTION
The primary embodiment of the present invention is a method for remote online support services over the internet to the end customer, said method comprises steps of; configuring network appliance with network elements at customer; connecting support server with configured appliance; Initiating a service connection and/or a logical control/data session by the connected server and thereby sending command/request for complete network element administration; and saving and indexing the initiated sessions for accurate audits to provide online support services.
In yet another embodiment of the present invention is the service connection between the network appliance and the support server is made independent of the IP address, internet service provider in use by the customer, geographical location, internet proxy, type of connection or any firewall deployed by customer to protect the network.
In still another embodiment of the present invention wherein no prior configuration is required from network appliance or any other network is housed in.

n still another embodiment of the present invention is independent of any network hanges once the network appliance has been plugged in.
ti still another embodiment of the present invention wherein the service connection does ot depend on the operating system or any other operating component between the ervice and the target.
i still another embodiment of the present invention wherein the other operating component includes servers, desktops, network switches, routers and other internet connectivity components.
In still another embodiment of the present invention is the method provides passive remote CLI access into the network appliance.
In still another embodiment of the present invention wherein Patches and upgrades are pushed from the support server to all network appliances at any time.
In still another embodiment of the present invention is the method provides automatic registration to the appliance with customer database at the time of installation.
In still another embodiment of the present invention wherein the method constantly checks the validity of the appliance registered and make periodic checks for license violations.
In still another embodiment of the present invention wherein the method provides remote fault analysis and troubleshooting.
In still another embodiment of the present invention wherein the remote online support services are selected from a group comprising Data migration services, Upgrade services, Network Remote Manufacturing services, Integrated text/voice chat to connect people at either end, and Remote Data Access Services.

In still another embodiment of the present invention is the method performs payload manipulation, remote passive access, remote graphical user application control, service session management, error handling, application data security and process view.
In still another embodiment of the present invention wherein the sessions are HTTP sessions.
In still another embodiment of the present invention is the method allows Asynchronous/at will connection to the customer for execution of dynamic processes.
In still another embodiment of the present invention wherein the server retrieves data and pushes the data into the Customer.
In still another embodiment of the present invention a system for remote online support services over the internet to the end customer, said system comprises; network appliance for instantiating a service connection; network appliance signature scanner is a signature recognition layer to bind the online support service technology to the network appliance, support server for sending commands/requests; means for connecting customer, Network appliance and support server; and means for saving and indexing the sessions.
In still another embodiment of the present invention is connecting Network appliance and support server is independent of the IP address, internet service provider in use by the customer, geographical location, internet proxy, type of connection or any firewall deployed by customer to protect the network.
In still another embodiment of the present invention wherein no prior configuration is required from Network appliance or any other network is housed in.
In still another embodiment of the present invention is independent of any network changes once the Network appliance has been plugged in.

In still another embodiment of the present invention wherein the operation of system is independent of operating system or any other operating component between the service and the target.
In still another embodiment of the present invention wherein other operating component includes servers, desktops, network switches, routers and other internet connectivity components.
In still another embodiment of the present invention wherein Patches and upgrades are pushed from the support server to all network appliances at any time.
In still another embodiment of the present invention wherein the remote online support services are selected from a group comprising Data migration services, Upgrade services, Network Remote Manufacturing services, Integrated text/voice chat to connect people at either end, and Remote Data Access Services.
In still another embodiment of the present invention is the network appliance is configured with the network settings that will allow it internet access.
In still another embodiment of the present invention wherein the system offers remote administration services suitable for service providers.
In still another embodiment of the present invention wherein the signature scanner ensures that the support technology only be executed on an authorized manufactured appliance.
In still another embodiment of the present invention wherein the signature is a digital signature is created using hardware/software components, manufacturing agent, license and authenticated customer.

Inst@Web is a complete process of online appliance management complemented by
suitable services at every step of its lifecycle. The intention of the process is to remove
the need for support personnel on site at all possible times irrespective of the
geographical location of the appliance.
Univault Appliance is a network appliance developed for the instant technology
which is used to connect all the network elements and alsq helps in initiating the service
connection.
We have listed some common terminology used throughout this document which will
make it possible for the reader to have a clearer understanding of what is being
illustrated:
Server: This term is used to refer to a standard server appliance/application which implements the HTTP server side protocol. This is essentially a linux platform but there are no restrictions and it could be any other platform as well.
Client: It denotes a standard appliance or application that implements the HTTP client side protocol. This is essentially a Linux platform but there are no restrictions and it could be any other platform as well.
Session: We denote all HTTP sessions between the server and the client by just using this term
It is important to view the entire lnst@Web system as a series of services with underlying technology implementations. Given this interpretation we shall present the entire system as a set of conceptual representations with affiliated technical refinements or restrictions. During the individual commentaries we will define the existing system and our deviation from each thus emboldening a clear stand on the differentiators that make our system unique. In order to assist external affiliates we shall clearly denote the claims or claimable material by highlighting them within the running text.

System Concept
InstjvWeb is a comprehensive online services system that allows implementation of remote services to any internet enabled UniVault appliance in the world without being aware of its exact internet location. This is made possible by a logical umbilical cord that exists between the support servers at TidalData and its UniVault appliances that are so enabled. At any point of time a service connection can be instantiated from the UniVault appliance which will alert our service personnel to establish contact and implement our advanced services. However the only caveat is that internet connection is a must for any of the online services to be up and the UniVault appliance must be properly configured with the network settings that will allow it internet access.
Univault signature scanner (USS) is the hardware/software signature recognition layer that binds the technology to the UniVault appliance. This ensures that the support technology can only be executed on an authorized manufactured appliance at the TidalData manufacturing facilities. The USS is a digital signature that is created using hardware/software components, manufacturing agent licensee and authenticated customer. This means that the technology will be successfully executed only on tidaldata manufactured platforms that support USS.
The following observations can be made:
1. The service connection between the UniVault appliance and our support servers can be made independent of the IP address, Internet Service Provider in use by the customer, geographical location, internet proxy, type of connection (be it broadband, dialup, DSL, etc) or any firewall deployed by our customer to protect his network.
2. No prior configuration is required from the UniVault appliance or any network that it is housed in and is independent of any network changes that may occur once the UniVault appliance has been plugged in.
3. The service connection does not depend on the operating system or any other operating component between the service and the target. This includes servers, desktops, network switches, routers and other internet connectivity components

As the figure 1 suggests the support services personnel on TidalData's intranet can reach
out and delivery scheduled services upon request from the customers using the appliance.
This omnipresent logical channel allows TidalData to enable the following process
paradigm:
"Inst(aWeb is the first controlled lifecycle management system for appliances all the way
from manufacturing to deployment and eventually to obsoletion irrespective of its
geographical location by using internet enabled technology*'
With the online support channel, the following web enabled services can easily be delivered from our support server:
? Passive remote CLI access into the UniVault appliance with which we can check the status of the appliance and also change configuration.
? Any web application running on our UniVault appliance can be taken over from the support server resulting in complete remote administration at any time.
? Patches and upgrades can be pushed from the support server to all UniVault appliances at any time
? Automatically register the appliance with our customer database at the time of installation
? Constantly check the validity of the appliance registered and make periodic checks for license violations
? Offer remote administration services suitable for service providers
? Remote fault analysis and troubleshooting with 99.5% success. Loss of power and failure of the core board are the only two issues that cannot be dealt with from our remote center.
? Data migration services
? Upgrade services
? UniVault Remote Manufacturing services
? Integrated text/voice chat to connect people at either end
? Remote Data Access Services
? Invalidate licenses, effect remote system lockdown and proactively monitor status

Instto/Web Technology
The online support channel works on top of standard HTTP protocol but in a completely opposite manner to what HTTP is intended for. The existing protocol is a simple client server exchange with a HTTP server running on one end and a HTTP client executing on the other as shown in figure 2.
The advantages of the HTTP protocol need not be explained here considering that it has opened up the internet universe for millions of people around the globe. But there are a few disadvantages or shall we say restrictions that need to be expounded upon:
1. The client has to initiate all actions.
2. Asynchronous (at will) connection to the client is not possible thus severely limiting execution of dynamic processes
3. All data has to be retrieved by the client and the server cannot push the data into the Client.
The diagram below illustrates the existing implementation of standard HTTP client server
technologies.
Our online support channel implementation uses the exact same methodology used in all
web based client/servers today with a few slight modifications in order to achieve the
effect of server controlling the client (instead of the other way around):
1. Once connected the server sets up a generic conduit with the client
2. The web server can send commands/requests to the client
3. Clients can function in normal HTTP mode as and when required
4. Server can use the conduit to relay any kind of request or command to the client. The type and nature of the commands will be explained as each service is explained further
As can be seen in figure 3, we have reversed the flow of control from the server to the client instead of the other way around. It merits a set of observations on the obstacles that are overcome by instaweb online support channel.
*l In order for the desired behavior to be achieved with the current internet setup, the server needs to be executed within the client network

4- Web servers need static internet (IP) addresses to be effective otherwise they would not be visible to the outside world. Client networks very rarely have static IP addresses because it is not cost effective nor is it scalable for their ISP
4 Almost all clients would use NAT thus making it impossible for the outside world to connect to them effectively
4 This server needs to be accessible all the time which is not possible considering that most offices run their internet connections temporarily like broadband, dialup, cable modems, etc.
4> The firewall on the client side will stop all incoming requests irrespective of its nature because of the type of information security required
Technology View
The Inst(a)Web system is built using standard HTTP modules and is independent of the operating system that it executes upon. In essence it has a server as well as a client at opposite ends of the spectrum. Each HTTP session has a logical control/data session that starts at the server and terminates at the client. This session is initiated by the server and maintained by the client unlike the standard client server relationship. One can view the solution as a client server architecture that has been turned inside out, without changing the underlying components.
The inst-server executes on the client and the inst-client executes on the server. The two components execute as part of the standard HTTP server context itself which means they do not require any additional memory or computing power. The inst-session between the inst-server and the inst-client is setup only after a standard HTTP session is established between the server and the client. This logical session is independent of the type of http protocol used (HTTP or HTTPS).
All instsessions are managed internally by the inst-server which has a per session database to track all InstfaWeb activities. The session management would involve validating the per session credentials of the client, check for active/inactive sessions, resume interrupted sessions, schedule session services per client and is also the de-facto human interface specialist for all inst-sessions.

As shown in figure 4, the entire system sits atop HTTP and completely changes the flow of control as well as that of data between the server and the client. This allows us to be totally transparent to the server as well as the client and also permits us to be positioned for any kind of appliance in the future. Secure transactions are easy with HTTPS support built into both the server and the client. All inst-sessions are state full and need careful handling both at inception as well as termination
As soon as the client connects to the server, the inst-session is kicked off and the inst-server gains control. Each inst-session is identified by a globally unique label stored on the inst-server. Every inst-client however is denoted by a unique identifier that tracks all appliances ever to leave the TidalData manufacturing facility and this has no relation to the inst-session.
A brief discussion on the merits of each module within the system outlined by the figure above is given here:
> inst-session error recovery: All error recovery within the system in terms of timeout handling, data transfer errors, transient HTTP errors, session resumption and application specific errors are facilitated. Not all sessions are resumed automatically and this depends on a variety of factors including the interruption itself
> Inst-Session Termination: Session termination can be done at either end but requires extensive transaction handling because of the human element involved at either end. Terminations can be asynchronous due to user input, scheduled because of time constraints, abortive due to protocol errors, etc.
> HIP Request Generator: The human interface request module is responsible for all interactions with human beings (if any) on either side of the inst-session. This includes online support, chat, retrieval of certain application data and data presentation
> Intranet Relay: This module makes it possible for all requests to be relayed on the intranet to other inst-servers that can actually service the request. This is also used in other parts of the framework to implement truly remote control by support personnel from different parts of the globe to connect to TidalData appliances

> InsUClient Request Handler: All specific requests from the support server will be treated as inst-client commands to the inst-server. These commands are executed on the client and responded back within the same session. All request-response pairs are single threaded meaning that every inst-session can have only one outstanding instsession request at any point of time
> Transport Session Manager; Every inst-session is managed centrally by the transport session manager that executes on the server. The inst-sessions are part of a centralized database that tracks all inst-sessions birth to death.
> Transport Alert Messaging Unit (TAMU): The inst-session transport layer is responsible for all alerts or events that are raised during and after the exchange. This allows both sides to monitor and react to emergency situations. These alerts are carried by out of band mechanisms on either side.
> inst-session Data Transport Unit (IDUT): The core module which actually ferries the data across the inst-session from server to client and vice-versa. There is no difference between control data and application data at any point of time. This module also handles all compression and data mangling operations that may be required during the interchange.
In order to understand the technical aspect of the solution a bit better we shall illustrate each component module independently in subsequent sections based on their role and position within the framework.
Reversing the Conduit
This is the core component of the Inst(q)Web framework and forms the main conduit within which the inst-session can transfer control/data back and forth. We use encapsulated data frames within the HTTP context to make this happen. The entire HTTP protocol is predicated on the fact that the client can push and pull data from the server at any time. Naturally the protocol does not provide for any feature wherein the server can access the client for security reasons. Though the security reasons are valid there is no scope for a trusted server in this case.
Our online framework works in terms of standard HTTP payloads and does not attempt to change the handoff between the server and the client in any way. Each payload consists

of an encrypted control block which instructs the inst-client to respond back to the control frame. Once the inst-server gets the control payload, it processes and responds back to the inst-server in the same interchange sequence. Thus in reality whenever the client is sending a standard HTTP command to the server, it is in fact transmitting the response to a request raised by the inst-server. The entire sequence is established by using a vanilla HTTP client to establish a conversation with the server on the basis of standard GET, POST and PUT commands.
The sequence diagram shown in figure 5 illustrates the transport session: The payload can be encapsulated to insert any protocol or command in it but it needs to have the correct HTML header and footers to make it work. Most commercial firewalls or proxies will prevent the packet from being shipped out to the internet if content is not a well formed HTML document. In our case the payload could be an actual HTTP request as well!!
The inst-session request and response exchanges are actually fragments of standard HTTP requests themselves which means that the inst-client could issue multiple such requests for a single session request. It is important to note that the inst-session is actually executing within the context of a session.
One of the aims of this model has been to never maintain continuous inst-sessions with the client because it is impractical over the internet and probably not appreciated by the administrators within the client network. Hence all state information is maintained by the inst-server and the inst-client never needs to know the current context except in the case of resumption of an aborted exchange.
Inst-Session Transport
How does the inst-session really work? It uses a standard HTTP server that employs CGI scripts to handle all client related URI access as referred in figure 5. These scripts allow the client to start the session and in essence to kick start the inst-session. Once the HTTP session is established between the server and the client, the inst-session is established with the back-end components on the client as well as the server. The HIP modules are the end points for the inst-session on either end.

Following are the sequence of events that occur on the server as soon an inst-session register command is received:
> A new inst-session ID is requested from the inst-session manager with the credentials of the client. There are only a finite number of inst-sessions that can be outstanding with respect to a client.
> Credential validation is done by looking up the inst-session database and verifying the privileges Once a new ID has been granted based on the credentials received, the inst-client is instantiated on the server
> The new inst-client replies back to the inst-server on the other end of the session assuming that a connection has been established. There is no other confirmation from the inst-server
> At this point of time, the inst-client can issue request commands to the inst-server
> The resources granted to the inst-session depend upon their availability as well as the requirements of the corresponding inst-server
The figure 6 explains the actual components that are involved in the transport layer:
Pa> load Manipulation
One has to remember that in our model, the HTTP payload limit is nearly infinite. But the way we manipulate payloads is that for the sake of simpler error correction, traffic is split up into chunks of 2MB each. Anything beyond 2MB is broken up, transferred separately and assembled at the destination. The following rules are used for the transport:
? If there is a broken transfer then restart the transfer at the nearest possible chunk alignment window (get the most recent chunk again if incomplete)
? All chunks are compressed unless specifically ignored via inst-session protocol handshake
? Encryption happens at the session level via HTTPS if so desired


Remote Passive Access
This is the most basic application of the HIP interface. It allows personnel on the inst-client side to execute remote commands on the inst-server. Normally with most tunneling applications we need to keep a session alive in the context in order to mimic a human beings repetitive nature of task execution. But in our application, we achieve the same behaviour without maintaining state or keeping the access continuously alive In this case we do the following:
4 Both the HIPs on either end of the inst-session are linked to an identical command
line shell. They are identical with respect to binary compatibility and operating
environment

4> The HIP on the inst-server end is a simple shell program
4 The HIP program on the inst-client end is either a HTTP based shell or a
command line TCL shell «i The two HIPs are kicked off on either end simultaneously 4 The communication between the HIP and the rest of the system is always
synchronous in one direction only. This means that in our case the system behaves
just like the HTTP session but in the opposite direction. The inst-client always
initiates all requests and is responded to within the context of that request 4> In cases where a direct response is not possible, the inst-server will re-register and
then resume the conversation 4> An event redirector is used on either side of the inst-session to generate and field
exceptional events and relay it to the HIPs. All HIPs are enabled with a parallel
relay module that informs the human user of exceptions.
The access session as far as the HIPs are concerned is always synchronous. In reality at the transport layer, it is always passive. The fact that the access is never continuous means that there is no security risk nor is there any state associated with the operation. But this does not mean that the HIPs are not continuously executing and in fact the entire inst-session with respect to the user is totally interactive. A discussion on the core workings of the Tel shell is too tedious at this juncture but it suffices to say that the exact same methodology is used when the interactive HTTP based shell is used as a HIP. The state is actually maintained by the HIPs and not by the inst-session itself!
Every command issued by the HIP is transmitted to the IDUT using the NST_EXEC_CLI operation code. Each response is waited for by the inst-client HIP before the next one is issued. Though this seems constraining there is no IDUT requirement to do so. Every command is logged and sequenced using an inst-session identifier prefix.
Please refer to the figure 7 as there is a common flow between the HIPs used in this section and the next.

Remote Graphical User Application Control
Remote application control is one of the more complicated examples of the HIP interface. It involves both session relaying as well as HTTP takeover from the remote appliance. The remote application control basically evolves a superior HIP interface that is developed to interface with the remote appliance and control its user interface program. The core principle is to provide a way for the HIP residing in the server network to administer/manage the control application that is executing on the end appliance within a client network without any changes to the client infrastructure. Any management application can be controlled this way irrespective of its deployment provided a few basic rules are followed during their implementation:
4* The remote application has to have a clear and well designed insulation between
the front end (rendering engine) and the back end 4> The rendering engine should not have any state maintained that affects the flow of
control between itself and the back end 4> The remote application should be based on industry standard specification such as
JAVA, HTML, .NET, etc 4 A set of well designed back-end interfaces should be specified. This can exist in forms such as CLI commands, cgi scripts, programming API, etc.
The rules that are defined above are pretty uniform across most well designed applications and should be widely acceptable. The diagram below depicts the complete flow of control over the inst-session link.
The figure 7 merits a few clarifications:
1. A standard CLI command will be transported to the remote inst-server as is
2. A HTTP command is broken into two portions: a rendering portion that is executed on the client and a back end portion that is relayed to the inst-server
3. The relays are primarily used to transform the request appropriately
4. a relay agent per application may be required based on the type of application

Service Session Management
All services are built on top of active inst-sessions. Inst-sessions are managed via a
centrally located Transport Sessions Manager (TSM). The TSM is a module that
organizes inst-sessions into different pockets of operation based on their activity profile.
All inst-sessions are proof of active entities managed by the Inst(a)Web process. The
TSM can be run in any standard web server context and works off of 3 main service
databases:
Scheduled Services: These are inst-sessions that are scheduled at specific intervals or
upon customer requests. They are basically used for installation, data migration,
appliance upgrades, manufacturing and other time induced services.
Emergency Services: Inst-Sessions that are launched by a HIP based on situations that
require immediate service. Some examples are troubleshooting, licensing resolution,
hardware diagnosis, etc.
Automatic Services: These address scenarios which are seamless and do not require any
HIP interaction at all. They are used for security audits, automatic product registration,
patch updates, fault reporting, etc.
All inst-sessions are integrated with an external trouble ticket system that can be accessible to both the service personnel as well as the end user who is the recipient of the service. These trouble tickets are automatically assigned and tracked for all inst-sessions that they are used for. Once used, these trouble tickets can never be reused and this is done for purposes of continuous auditing.
Inst-Sessions are tracked by the following operational states:
> New: When the inst-session is first created, it will be processed by the TSM to set up the receiving credentials and identification information. At this point there will be no HIP invocation yet
> Active: All inst-sessions that are connected either to a HIP on either side or to the automatic service request parser.

> Suspended: this state signifies a cessation in HIP activity and can only be reinstantiated by the personnel on either end of the exchange
> Interrupted: This signifies a process service that been interrupted either due to error condition within the transport or in the execution modules at either end
> ShutDown: The process shutdown state which is exclusively used to terminate an
active or suspended inst-session
> Obsolete: This process has been shutdown and is dormant.


Error Handling
As in any internet protocol, recovering from errors is extremely tenuous and involves a very complex exchange of retries, reassignments and re-establishment of process activities. There are three types of errors that we handle in this system:
1. HTTP Errors: The base protocol itself results in errors. Obviously since HTTP is quite a mature protocol, it is one of the easier errors to recover from. This recovery has to be initiated from the client side and the server has to go into reconnecting mode waiting for resumption. Recovery state is managed by the client
2. Inst-Session Errors: There are errors in the inst-session transport layer or within the TSM. Such errors are independent of the HTTP transport layer and are handled within the inst-session state machine. Recovery state is managed by the inst-client.
3. HIP Errors: The HIP layer at either end can have user errors or relay errors. These do not make the inst-session void but may make them unusable at times. Recovery state is managed by the offending HIP.
The figure 8 illustrates the different error points within the inst-session life cycle. Please note that the error state recovery can be manual (user driven) or automatic as the situation dictates and there is no difference as far as the state machine is concerned.
Application Data Security
This a topic that is not directly concerned with Inst(aWeb but we still feel the need to just point out that the remote access over internet will open a few issues that need to be sorted out when remote service personnel are accessing the data on the appliance. This is really a matter that is not within the purview of this document but implementations need to deploy the corresponding security configuration for data that might either be transport or application specific.

Process View
InstifibWeb is a complete process of online appliance management complemented by
suitable services at every step of its lifecycle. The intention of the process is to remove
the need for support personnel on site at all possible times irrespective of the
geographical location of the appliance. All processes are tracked by trouble tickets that
form the external backbone to facilitate management and administration. The figure 9
illustrates the relationship between the trouble tickets and the Inst-SessionsIn this section we do not enumerate the details of every process but we attempt to give
the reader a skeletal overview of where they fit in and how they integrate into the process
model. Quality control is at the heart of the entire Inst@Web model.

Inst@web and Univault are subjected to trademark.
Glossary
CGI: The Common Gateway Interface {CGI) IS a standard for interfacing external
applications with information servers, such as HTTP or Web servers. A plain HTML
document that the Web daemon retrieves is static, which means it exists in a constant
state: a text file that doesn't change. A CGI program, on the other hand, is executed in
real-time, so that it can output dynamic Information
HIP: Human Interface Program that allows typed or audio responses to be used as
commands to the remote client
HTML: In computing, Hyper Text Markup Language (HTML) IS a predominant markup
language for the creation of web pages. It provides a means to describe the structure of
text-based Information in a document by denoting certain text as headings, paragraphs,
lists, and so on and to supplement that text with interactive forms, embedded images, and
other objects
HTTP: The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
distributed, collaborative, hypermedia information systems. It is a generic, stateless,
protocol which can be used for many tasks beyond its use for hypertext, such as name
servers and distributed object management systems, through extension of its request
methods, error codes and headers
HTTPS: This is a URI scheme which is syntactically identical to the http: scheme
normally used for accessing resources using HTTP. Using an https: URL indicates that
HTTP is to be used, but with a different default port (443) and an additional
encryption/authentication layer between HTTP and TCP
ISP: Internet Service Provider who connects client networks to the internet via a host of
technologies Via media like dialup, cable modems, leased lines, broadband, etc.

LAN: A computer network that spans a relatively small area. Most LANs are confined to
a single building or group of buildings.
MAN: Short for Metropolitan Area Network, a data network designed for a town or city.
In terms of geographic breadth MANs are larger than local Area networks (LANs), but
smaller than wide-area networks (WANs).
NAT: Network address translation is an interface technology that is used to separate the
internal IP addresses within a network from the ones publicly available on the internet
NOC: Network operations center is the core monitoring operations cell over the internet

We claim;
1. A method for remote online support services over the internet to the end customer,
said method comprises steps of;
i. configuring network appliance with network elements at customer; ii. connecting support server with configured appliance; iii. Initiating a service connection and/or a logical control/data session by the
connected server and thereby sending command/request for complete
network element administration; and iv. Saving and indexing the initiated sessions for accurate audits to provide
online support services.
2. The method as claimed in claim 1, wherein the service connection between the network appliance and the support server is made independent of the IP address, internet service provider in use by the customer, geographical location, internet proxy, type of connection or any firewall deployed by customer to protect the network.
3. The method as claimed in claim 1, wherein no prior configuration is required from network appliance or any other network is housed in.
4. The method as claimed in claim 1 is independent of any network changes once the network appliance has been plugged in.
5. The method as claimed in claim 1, wherein the service connection does not depend on the operating system or any other operating component between the service and the target.
6. The method as claimed in claim 5, wherein the other operating component includes servers, desktops, network switches, routers and other internet connectivity components.

7. The method as claimed in claim 1, wherein the method provides passive remote CLI access into the network appliance.
8. The method as claimed in claim 1, wherein Patches and upgrades are pushed from the support server to all network appliances at any time.
9. The method as claimed in claim 1, wherein the method provides automatic registration to the appliance with customer database at the time of installation.
10. The methods as claimed in claim 1, wherein the method constantly checks the validity of the appliance registered and make periodic checks for license violations.
11. The method as claimed in claim 1, wherein the method provides remote fault analysis and troubleshooting.
12. The method as claimed in claim 1, wherein the remote online support services are selected from a group comprising Data migration services, Upgrade services, Network Remote Manufacturing services, Integrated text/voice chat to connect people at either end, and Remote Data Access Services.
13. The method as claimed in claim 1, wherein the method performs payload manipulation, remote passive access, remote graphical user application control, service session management, error handling, application data security and process view.
14. The method as claimed in claim 1, wherein the sessions are HTTP sessions.
15. The method as claimed in claim 1, wherein the method allows Asynchronous/at will connection to the customer for execution of dynamic processes.
16. The method as claimed in claim 1, wherein the server retrieves data and pushes the data into the Customer.

17. A system for remote online support services over the internet to the end customer,
said system comprises;
a. network appliance for instantiating a service connection;
b. network appliance signature scanner is a signature recognition layer to bind
the online support service technology to the network appliance;
c. support server for sending commands/requests;
d. means for connecting customer, Network appliance and support server; and
e. means for saving and indexing the sessions.
18. The system as claimed in claim 17, wherein connecting Network appliance and support server is independent of the IP address, internet service provider in use by the customer, geographical location, internet proxy, type of connection or any firewall deployed by customer to protect the network.
19. The system as claimed in claim 17, wherein no prior configuration is required from Network appliance or any other network is housed in.
20. The system as claimed in claim 17 is independent of any network changes once the Network appliance has been plugged in.
21. The system as claimed in claim 17, wherein the operation of system is independent of operating system or any other operating component between the service and the target.
22. The system as claimed in claim 21, wherein other operating component includes servers, desktops, network switches, routers and other internet connectivity components.
23. The system as claimed in claim 17, wherein Patches and upgrades are pushed from the support server to all network appliances at any time.

24. The system as claimed in claim 17, wherein the remote online support services are
selected from a group comprising Data migration services, Upgrade services,
Network Remote Manufacturing services, Integrated text/voice chat to connect people
at either end, and Remote Data Access Services.
25. The system as claimed in claim 17, wherein the network appliance is configured with
the network settings that will allow it internet access.
26. The system as claimed in claim 17, wherein the system offers remote administration services suitable for service providers.
27. The system as claimed in claim 17, wherein the signature scanner ensures that the support technology only be executed on an authorized manufactured appliance.

28. The system as claimed in claim 17, wherein the signature is a digital signature is created using hardware/software components, manufacturing agent, license and authenticated customer.
29. The method and system for remote online support services over the internet to the end customer substantially as herein above described with reference to the accompanying drawings.
Dated this 2nd day of February, 2006