Patent Application
20060053478
The present invention relates to the field of remote product service. In particular, to a system, method and computer program product for controlling a service request.
An approach commonly used by service organizations (a.k.a. service providers) to service software and hardware products at customer locations is through the use of remote service sessions. A remote service session typically includes a network connection between the product to be serviced and a service platform used by the service provider. Interaction between the service platform and the product to be serviced takes the form of requests for actions to be executed on the product.
There are a number of challenges involved with remotely servicing a software or hardware product. These can include: the lack of automated data transfer back to the service organization; lack of a secure remote connection; lack of control over the remote connection; inability for the customer or the product to establish an interactive service session; susceptibility to session hi-jacking; inability to create permanent, periodical or temporary service sessions; inability to enforce time limits for sessions; inability for a customer to watch or monitor the remote session; lack of ability to increase or reduce the level of interaction; lack of ability for customers to electronically communicate in real time with the service provider; and the lack of ability to apply similar control and monitoring over automated service sessions.
What is needed is a system and method for overcoming the above mentioned limitations of remote product service.
In accordance with one aspect of the present invention, there is provided a data processing system for controlling, based on a policy, a service request containing an action to be executed on a product to be serviced, the data processing system including a service module for receiving the service request, a policy manager for applying the policy to determine whether the service request is one of accepted and rejected, and a product interface for executing, on the product, the action contained in the accepted service request.
In accordance with another aspect of the present invention, there is provided a data processing system implemented method for controlling, based on a policy, a service request containing an action to be executed on a product to be serviced, the data processing implemented method including receiving the service request, applying the policy to determine whether the service request is one of accepted and rejected, and executing, on the product, the action contained in the accepted service request.
In accordance with still another aspect of the present invention, there is provided a article of manufacture for controlling, based on a policy, a service request containing an action to be executed on a product to be serviced, the article of manufacture including data processing system usable medium tangibly embodying data processing executable code, the data processing executable code including data processing executable code receiving the service request, data processing executable code applying the policy to determine whether the service request is one of accepted and rejected, and data processing executable code executing, on the product, the action contained in the accepted service request.
Other aspects and features of the present invention will become apparent to those ordinarily skilled in the art to which it pertains upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures.
The present invention will be described in conjunction with the drawings in which:
An embodiment provides a system, a method and a computer program product for control of a service request in a remote service session operated by a service provider for a product. The product can be, for example, at a customer's location. The product can be comprised of software, hardware or a combination thereof. The present invention comprises a service module that can access the product to be serviced and a service gateway connected to the service module and to a session end-point used by the service provider. The service module can be co-located with the product. The service gateway and session end-point can be co-located at the service organization's service delivery location. The present invention provides the customer control of a remote service session by providing the customer the ability to set policies to be applied by the service module to service requests received from the service gateway. Each policy is comprised of a set of rules. Each rule can approve or reject a service action request based on: the specific action requested, the scope of impact, the product component to be acted on, the time and date of interaction and combinations thereof.
Interactions between the serviced module 210 and the service gateway 220 occur in the context of a service session in which service action requests, information and messages are exchange. Session initiation and administration is provided for by the session managers 212, 222. The session can be commenced manually, for example, by the customer or it can be commenced by an automated process. The service session can be one that occurs periodically on a scheduled basis or one that occurs in reaction to a specific event or fault in the product. A session may operate in an unattended or in an interactive mode. In interactive mode the customer participates in the session.
Communication in a service session between the service module 210 and the service gateway 220 is provided for by a network connection 130 (see
Once the network connection 130 has been established, service action requests can be sent from the service gateway 220 to the service module 210. A service action request can be initiated by a human operator (e.g. a service provider agent) or an automatic system connected to the service gateway 220 via the session end-point 140. The service action request is received at the service module 210.
The service action request is validated using policies administered by the policy manager 215. The policy manager 215 provides for creation, administrations, management and storage of policies. Policies can be created by the customer by interaction with the policy manager 215 via the user interface 211. The customer can subsequently edit or delete policies via the user interface 211. Individual policies can be general and apply to all service sessions or they can be specific to a service session involving a specific service provider or service provider agent. For service provider or service provider agent specific policies, the identity of the service provider or service provider agent can be established and authenticated by the session manager 212.
Each policy takes the form of a set of rules. Table 1 presents a set of rules according to an exemplary embodiment of a policy according to the present invention. Each rule comprises fields representing: result, action, object, qualifier and time/date. The result field can take on values such as APPROVE and DENY which signify that an action request that matches the other fields of the rule will be approved or rejected respectively. The result field can also take on the value INTERACTIVE signifying that approval or rejection of the action request is deferred to the customer. In addition the result field value can be augmented with NOTIFY to signify that a notification will be sent if the other fields of the rule are matched. The action field takes on values such as QUERY, ACTION, CMD and ALL which signify that the rule applies to an action request that is a data query, an action on a component identified by the object field, a product command and any action request respectively. The object field describes an object of the action specified in the action field. The object can be, for example, a product component, DATA or a specific product command. The qualifier field specifies a qualifier for the scope of action on the object such as, for example, the type of data or source of data. The time/date field specifies a time and/or date range in which the rule applies.
The first rule in the exemplary embodiment shown in Table 1 will approve queries (information only) for the buffer pool services (BPS) configuration between 8 μm and 1 pm each day. The second rule will approve actions (changes) for the transaction logging (LOGGER) configuration. The third rule will approve data queries for a database known as ‘SAMPLE’ during a four day span from Jan. 17, 2003 to Jan. 20, 2003. The forth rule will deny (i.e. reject) all access to data (from the product) and notify the customer of any attempts to access the data. The fifth rule will ask the customer in an interactive session to approve or reject an action for a specific command known as “vmstat 10”. The sixth rule will deny every other action.
The logging module 217 provides for recording logs associated with requested actions. The log information can be inspected by the customer via the user interface 211. Log information can also be requested by a service action and be returned to the service gateway 220.
The notification module 218 provides for a notification to be sent to the customer based on an action request. The notification can be sent when an action request is approved or rejected. Also, the notification can be sent when a session is interactive or non-interactive. When a service action request is rejected according to a policy in an interactive session, notification can be sent to the customer and the customer can choose to allow or not allow the rejected action. The notification can take the form of a user interface 211 prompt, an e-mail message, a pager message and other similar forms of notification.
Product interface 214 provides for the interaction between the service module 210 and the product 120 required to carry-out a policy or customer approved service action request.
The chat and messaging modules 216, 224 provide for the customer to exchange messages with a service provider agent at the session end-point 140 connected to the service gateway 220.
User interface 211 provides for the customer to interact with the service module 210. Interactions can include, for example, creating and administering polices, initiating and administering a network connection, initiating and administering a service session, receiving and reviewing logs, sending and receiving messages, receiving notifications, approving of policy rejected service action requests and other similar interactions.
An embodiment of the present invention can be implemented as a computer program product for execution on a computing platform.
It will be apparent to one skilled in the art that numerous modifications and departures from the specific embodiments described herein may be made without departing from the spirit and scope of the present invention.
