FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See Section 10 and Rule 13)
Title of invention:
SYSTEM AND METHOD FOR BUNDLING OF MULTIPLE PRODUCT SLAs
INTO A COMPREHENSIVE SUPPORT SLA
APPLICANT:
TATA Consultancy Services Limited A company Incorporated in India under The Companies Act, 1956
Having address:
Nirmal Building, 9th Floor,
Nariman Point, Mumbai 400021,
Maharashtra, India
The following specification particularly describes the invention and the manner in which it is to be performed.

FIELD OF THE INVENTION:
The present invention generally relates to the field of open source computing. More particularly the invention relates to a system that enables automated bundling of support terms for multiple open source products and generation of single comprehensive support agreement and method thereof.
BACKGROUND OF THE INVENTION:
A service level agreement is a negotiated agreement generally between two parties where one is the customer and the other is the service provider. This can be a legally binding formal or informal "contract". Service Level Agreements (SLAs) are popular and used in companies in many fields including financials services, software services and software support etc.
Service providers benefit from Service Level Agreements (SLAs) with customers for determining quality of service to avoid disputes, allocate resources and manage costs. However, adoption of SLAs has been limited both in terms of the number of companies implementing service-based service level agreements and the percentage of services that companies govern by service level agreements.
On the other hand, Open source software is computer software that is available in source code form for which the source code is free of copyright of the author and the users are generally permitted under a software license to study, change improve such code.
Open source software are made available in public domain can be sold and used commercially. It is a part of the software industry. The financial return on open source software usually comes from selling services, such as training and support, rather than the software itself.

Conventionally, SLAs are created by using Service Level Management software that allows Information Technology (IT) to formally capture agreements between the customer and IT. The software manually records the service level criteria developed by service level manager working with a customer so that a substantial labor cost is incurred in creating SLAs. SLAs are created on a case by case basis so that realistic estimates of service quality and budgeting for individual service level agreements can be captured adequately.
Generally, in the present scenario, the users are dependent on multiple product sets available with multiple open source software product vendors and the business model of such Open source software vendors is centered on product support. The community version of open source software has no entity offering product support as the user is dependent on the community members to respond to any query posted to the community forum, with no guaranteed response time. The open source product vendor mitigate this potential risk in adoption of open source by offering a premium version of the community product that comes bundled with support. The premium product itself may or may not be identical to the community version in functionality but the code base is usually the same. Further, users of multiple open source software are dependent on multiple vendors for support.
However, some the problems with use of multiple open source software products are either the SLA is undefined and unstructured or there is ambiguity in the SLA with regard to the product enhancement requests over the products that are covered in the scope of SLA. Hence, the existing SLA might not work for such enhancement requests.
The most critical issue with open source products is the non-availability of Comprehensive Service Level Agreements (SLAs) in terms of support or issue resolution. If a company is willing to bet its business on the software then the company should have well defined SLAs so that if an issue arises in production there is someone accountable for resolving the problem. The SLAs force vendors to invest a lot of money in testing their products and having support staff that can work through product issues. With the open source community, there is no guarantee that anyone would look at the problem soon, and if someone does, there is no guarantee when it will be fixed. In most cases, the alternative is for someone

from IT to dig into the code and make the fix, which automatically creates a new branch of the code compared to the open community. Understandably, the fix can go into the main code branch maintained by the community, but involves intense efforts, time and resources. The conventional software's automatically create separate SLA for different products between service provider and a consumer of a service becomes difficult to understand, confusing and time consuming process. Hence, there is a "long felt need" to solve the vacuum of automatic bundling of support terms for multiple open source products with different SLAs into a single comprehensive SLA for covering all the clauses in one support agreement.
In order to solve the above mentioned problems, the current invention proposes an automated system and method for bundling of support terms for multiple open source products with different SLAs into a single integrated SLA with a guaranteed response time and a method thereof.
Other features and advantages of the present invention will be explained in the following description of the invention having reference to the appended drawings.
OBJECTS OF THE INVENTION:
The primary objective of the present invention is to provide a system that enables bundling of support terms for multiple open source products into a single support agreement.
Another significant objective of the invention is to provide a product support for the community version of the open source software product, with guaranteed response time for SLA based support.
Another significant objective of the invention is to provide a single window support for users of multiple open source software products.
One of the other objective of the invention is to provide a comprehensive service level,

instead of multiple, individual product based SLAs.
Yet another objective of the invention is to optimize the process of arriving at a manageable SLA for each customer, based on product set and resource availability. Still another objective of the invention is to provide the recommended integrated SLA and the recommended bundle that could form part of the agreement with the customer.
Another objective of the present invention is to efficiently assign resources for supporting multiple product sets in guaranteed response time.
Still another objective of the invention is to provide a system that enables storing and updating regeneratively the values stored in a repository to auto-learn subsequent updates divergent from the predefined values;
Still another objective of the invention is to provide a system that enables the customer is alternatively prompted to recommend one or more SLA by way of an input prior to the SLA bundling process.
SUMMARY OF THE INVENTION:
In accordance to one aspect of the invention, the proposed system provides a single window support for users of multiple open source software products which is a bundled premium support where a set of products used by a customer are bundled into a single comprehensive Service Level Agreement (SLA), instead of multiple, individual product based SLA.
In accordance with another aspect of the invention, a method for automatic bundling of support terms for multiple open source products with different Service Level Agreements (SLAs) into a single SLA characterized by having guaranteed response time is provided.
Another aspect of the present invention provides a method capable of generating comprehensive Service Level Agreements (SLAs) for various products and customers by

considering various determining factors like Resource master register, Resource loading information, Resource maturity, open source product register, Historical information etc.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
The foregoing summary, as well as the following detailed description of preferred embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there is shown in the drawings example constructions of the invention; however, the invention is not limited to the specific system and method disclosed in the drawings.
Figure 1 illustrates system flow diagram of automatic bundling of support terms for multiple open source products with different Service Level Agreements (SLAs) into a single SLA in accordance with the preferred embodiment of the present invention.
Figure 2A & 2B illustrate Control Flow diagram of overall product bundling system. DETAILED DESCRIPTION OF THE INVENTION
The invention will now be described with reference to the accompanying drawing which does not limit the scope and ambit of the invention. The description provided is purely by way of example and illustration.
Definitions:
SLA: A service level agreement (frequently abbreviated as SLA) is a part of a service contract where the terms of service and support are formally defined.
Open-source software: An Open-source software (OSS) is computer software that is available in source code form for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that permits users to

study, change, improve and at times also to distribute the software.
Referring now to Figure 1, is a system flow diagram illustrating the process of automatic bundling of support terms for multiple open source products with different Service Level Agreements (SLAs) into a single SLA characterized by having guaranteed response time that utilizes various input, output processing units and a database capable of interacting with process and control functions is presented.
The proposed system (100) of the present invention as shown in Figure 1 provides the user interface means (102) to capture open source product support requirements from a customer (101) by way of submitting data capture forms, hereafter called as Ticket request forms. After receiving the request, the Product Bundling component (105) of the system checks the Service Level Agreement (SLA) and available resources in the maintained database (111). If the number of resources is less than the desired number mentioned in SLA, the system (100) automatically assigns new resources based on availability or level of SLA for the product.
The system (100), in accordance with the embodiment of the present invention, also provides the input in the form of SLA baseline data as per support agreements & other inputs. The Product Bundling Component (105) considers the various determining factors reposited in different modules namely Resource master Register Module (106), Open Source Product Register Module (107), Resource Management Module (108), Resource Competency Management Module (109), and Help-Desk Module (110) which are further stored in the appropriate database (111) to generate a modified SLA. The modified SLA, so generated as an output for bundled product is configured with the Help desk module (110) for verification. Then, the Product Bundling Component (105) produces final recommended SLA in a guaranteed Response & Resolution time for bundled product for a particular Customer (101) by considering various factors discussed above.
One of the preferred embodiments of the present invention relates to a system (100) for bundling suppo rt for multiple products with different SLAs into a single SLA based offering needs to take into consideration the following determining factors contained in

different modules stored at a common repository site or database (111),, as discussed in detail below:
1. Resource master register module (106):
The register is the master list of resources allocated to the support group. This information is one of the inputs to the system (100) and each resource in the support group is tagged as:
a. Exclusive resource for a specific product; or
b. Shared resource for support of 'n' products, with a percentage of time
allocated for each product;
2. Open source product register module (107):
This register is a master list of all products supported by Organization. This register is used in conjunction with resource master register module (106) for tagging the resource, as mentioned in point 1.
3. Resource Management Module (108):
Current support assignments are handled by each resource in the group hence this information could be from a different sub-system. This input to the system (100) will set a baseline response time that will be further modified by the system (100) itself based on other inputs.
4. Resource Competency Management module (109):
At this point of time, the proficiency level of each resource can be determined on a pre-determined scale of, say, 1 to 5. This input to the system (100) will fine tune the output by building appropriate safety margin in the SLA.
5. Products used in the same integrated application used by the customer:
A customer/ user (101) may have requested for support of, say, 5 open source products, of which, say, 3 are integrated in a single application, and the rest 2 are either part of another independent application, or stand-alone applications. The

bundling, then, becomes more important for the 3 products used in the same application, and not for the other 2. This input to the system will generate a baseline SLA based on the SLA of the individual products that are bundled together, potentially by taking the lowest service level, and modified by the baseline response time determined earlier from point 2. Products / product sets that are not used in the same application would have different SLAs, in line with the same process.
6. Application complexity:
In cases where individual open source products have been integrated into a customer application, the complexity of the application plays a role in determining the manageable SLA. More the number of integration points between multiple open source products and with commercial products, more complex the application becomes, and consequently it becomes more difficult to pin-point the issue source. Hence this will be one of the inputs to the system, possibly as a factor of, say, 1 to 5. This classification of the complexity of the application on a scale of 1 to 5 has to follow either Organization standards or industry standards, if any.
7. SLAs: The system will have as one of its inputs, the SLAs of the individual products
under consideration. The output of the system (100) is the recommended integrated
SLA and the recommended bundle that could form part of the agreement with the
customer/user (101). In addition to the individual product SLAs, any recommended
SLAs for the bundled product set - either as suggested by the customer/user (101),
or as perceived by Organization - could also be an input, in which case the system
(100) will verify (based on the other inputs) that the SLA is achievable, and if not,
will also recommend an appropriate SLA. An SLA would have the following
components:
a. Response time: Response time is the time taken for initial interaction with the customer/user (101) after a call has been logged, and would depend on the problem severity. A matrix of response time and severity would form part of such agreement. A base-line figure could be one of the inputs to the system (100). The system (100) will provide, as one of its outputs, the

recommended response time that may be committed to the customer/user in an agreement.
b. Resolution time: Resolution time is the time taken to resolve the issue raised
by the customer/user (101) after a call has been logged, and again would
depend on the problem severity. A matrix of resolution time and severity
would form part of such agreement. A base-line figure could be one of the
inputs to the system (100). The system (100) will provide, as one of its
outputs, the recommended resolution time that may be committed to the
customer/user (101) in an agreement.
c. Severity: Severity is a four level issue classifier - low, medium, high and
critical. This classification is based on business impact. This will be one of
the inputs to the system (100), which will determine the response / resolution
time calculation.
d. Support hours: Standard hour support is 9X5. Extended hour support could
be 12x5, 12x7 or 24x7. This will form part of the agreement with the
customer/ user (101), but may not be needed by the system (100) for it
functioning, except as a record to complete the output,
8. Historical information on individual product support request frequency: This
may have to be normalized, or converted to a factor.
9. Historical information on individual product support complexity: The
complexity factor would be a number on a scale of, say, 1 to 5.
10. Historical information on individual product support request resolution time:
All these historical information inputs (points 8 to 10) will be used by the system (100) to verify that the SLA calculated is achievable, and possibly add a buffer to ensure a safety margin.
Figure 2 represented by 2A & 2B illustrate Control Flow diagram of overall product bundling component (105) of the system (100).

The system presents a method for automatic deriving of support terms for multiple open source products with different Service Level Agreements (SLAs) into a single bundled SLA characterized by having guaranteed response time, wherein the method comprising a processor implemented step of:
a. receiving at least one open source product support requirement from a
customer on a user interface means;
b. storing a plurality of predefined values associated with a plurality of open
source product into a repository, the repository is adapted to
regeneratively auto-learn subsequent updates divergent from the said
predefined values;
c. for each such open source product,
fetching a resource master data, open source product data, resource management data, competency management data, help desk data, application complexity information, resource loading information, historical information into corresponding modules; and
d. executing program instructions for bundling of SLA terms in response to
inputted customer requirements;
e. benchmarking an organizational response time determined based on
information corresponding to the selected product stored in the
repository.
The exemplary embodiment of the present system (100) poses a method wherein in the step 201, resource details are shared from resource master register module (106) and accordingly the system (100) allocates the resources as an input to calculate Baseline SLA response time in step 205. In step 202, the system provides Resource- product support mapping as per the information stored in the database (111). In step 203. the system receives the resource assignment information from resource management module (108) of the database (111) and assigns the no of support assignments as an input to calculate Baseline SLA Response time in step 205.
The output of step 205 is obtained after receiving the resource maturity and associated skill

proficiency level information from resource competency management module (109) in step 204 as well as information received from customer/user application and environment in step 206. This adds safety margins to the output of step 205 and enables the system (100) to calculate lowest level SLA, referred as modified SLA in step 207.
The modified baseline SLA obtained in step 207 is further processed to calculate achievable SLA and to add buffer. In another alternative embodiment of the present invention, the modified baseline SLA is suggested to output an alternate SLA in case of an already existing SLA with the customer/user (101). This is achieved by securing other relevant details from constituting component modules of the present system (100).
The additional details, if any, are received from the customer/user (101) or the organization in step 211. The information is further complemented by complex application information retrieved from Customer Application and Environment. This information refers to number of integration points between multiple open source products and with commercial products resulting in a complex application and consequently it becomes more difficult to pin-point the issue source. Hence this becomes one of the inputs to the system (100), possibly as a factor of, say, I to 5 in step (212). This classification of the complexity of the application on a scale of 1 to 5 has to follow either Organization standards or industry standards, if any. The historical ticket information and SLA related information is secured from the help desk module (110) in step 212 on individual product support request frequency; individual product support complexity wherein the complexity factor is estimated on a scale of 1-5; and individual product support request resolution time to verify the finally bundled product list with SLA.
While considerable emphasis has been placed herein on the particular features of this invention, it will be appreciated that various modifications can be made, and that many changes can be made in the preferred embodiments without departing from the principles of the invention. These and other modifications in the nature of the invention or the preferred embodiments will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted

merely as illustrative of the invention and not as a limitation.
BEST MODE / EXAMPLE OF WORKING OF THE INVENTION:
The invention is described in the example given below which is provided only to illustrate the invention and therefore should not be construed to limit the scope of the invention.
A customer ABC, a manufacturing company, wanted to implement an enterprise server and other IT infrastructure. ABC procures three open source software, Liferay, Apache & JBossAS, however while procuring them was not sure about the support services, which is generally the case with open source software. Subsequently, ABC approaches an open source software support vendor-XYZ for subscribing to support services to the three procured software.
Now, the vendor XYZ attempts to offers certain SLAs related to each product to ABC and as part of service agreement such SLA agreement needs to be concretized. However, the vendor-XYZ, needs to compute a response time for various levels of fault criticality. Computation of guaranteed response time is of critical significance in service offerings.
The vendor-XYZ, who offers technical support services for multiple products, will rely on a manual decision process while computing the response time for each product. Such task is cumbersome as such computations needs to be repeated each product separately and varies customer to customer implementation environment. In such scenario, both vendor-XYZ and customer-ABC would desire to have a comprehensive SLA creation system. Accordingly, an automated SLA management system that can take into consideration various variable parameters associated with the response time to generate comprehensive bundled SLA for each product aggregatively. This SLA Bundling system will have dependency on inputs information from various other systems. A set of algorithms will exploit this information to automate tasks for providing a bundled SLA.
As a part of the SLA Bundling system, the system will compute Vendor's benchmarked

response time for per product with a first dependency information. For example as below:
Severity Response Time Response Time Response Time
- Product 1 - Product 2 - Product 3
Severity 1 1 hour 1 hour 1 hour
Severity 2 4 business hours 4 business hours 4 business hours
Severity 3 1 business day 6 business hours 5 business hours
Severity 4 2 business days 1 business days 2 business days
The SLA bundling system will take a baseline response time from above benchmarked response time and will optimize this value by influencing with various real time and historical factors.
Based on above optimized SLA. a response time for Severity 1 issue for individual product will be available as reference.
i. Liferay - 1 hr
ii. Apache - 1 hr
iii. JBossAS -1 Hr
A more optimized SLA Response Time (SLA) for the bundled product will be calculated in a phase by phase manner where various factors (dependency information) will play a major role in affecting the SLA response time value for individual product and for the bundle of products at the end. The various such factors are explained as below in a sequential manner:
factorl: Percentage of shared resource % available of the overall strength (say
X)
factor2: Resource and Product mapping i.e. how many resources are available
for supporting the 3 products i.e. Liferay, Apache and JBossAS? (Say Y no in total to be mapped for all 3 products)

factor3: No of other Support assignments these resources are assigned to and
serving (say Z)
factor4: Skill proficiency level in each product which is a variable (a scale of
1-5)
Step A: Calculate the first baseline SLA based on the above information.
Baseline SLA Response Time per Product (in minutes/product name) = Functionl (factorl, factor2, factor3, factor4)
factor5: Adjustment Factor based on Business SLA expectation from
Customer/user per individual product
Step B: Calculate new SLA which is within customer/user expectation.
Modified Baseline SLA Response Time per Product (in minutes/product name) - Function2 (Output of Step A, factor5)
factor6: Organization Experience factor. This will be a certainty factor ex:-
0.7 out of total 1. This experience of certainty is based on SLA
compliance data and experience with other customers supported by
the organization earlier.
factor7: Customer Environment Influence Factor (1 to 5). It is calculated from
complexity of customer solution i.e. no of commercial products in
use, no of integration points between Open source product and
commercial ones.
factor8: Historical Factor (scale of 1 to 5). This will be calculated from
support frequency, no of tickets solved earlier in a particular duration,
individual product support complexity & historical resolution time.
factor9: Business SLA requirements from the very initial agreement between
customer/user and Vendor. This SLA can be set for business continuity purpose for mission critical applications. This will be considered for comparing with final optimized SLA and therefore any adjustments.

StepC Calculate final bundled SLA for all products
The above steps will be iterated for each product to be supported to arrive at optimized SLAs for each product. The outputs of the above steps will act as the dependency information for the final step where, a final Optimized SLA will be calculated by a bundling algorithm for supporting all the products in scope bundled together.

CLAIMS:
1. A system for bundling support terms for plurality of open source products with different Service Level Agreements (SLAs) into a single bundled comprehensive SLA, the SLA comprising a guaranteed response time, the system comprises:
a. a user interface means adapted to capture open source product support
requirements from a customer;
b. a repository for storing a plurality of predefined values associated with a
plurality of open source product, the repository is adapted to regeneratively
auto-learn subsequent updates divergent from the said predefined values;
c. a computer readable memory means having resource master module,
resource management module, competency management module, helpdesk
module on individual open source products in a database and a product
bundling component interacting with the said modules; and
d. a processor means adapted to execute program instructions for bundling of
SLA terms based on the customer requirements and an organizational
benchmarking determined based on information stored in the repository.
2. A system as claimed in Claim 1, wherein the resource master module classifies the
resources into:
a. an exclusive resource for a specific product, and
b. a shared resource for support of two or more products, the resource master
module configured to record a percentage of allocated time for each resource
for each such product.
3. A system as claimed in Claim 1, the resource management module adapted to evaluate response time for each product, wherein the said module is configured to receive first dependency information for an organizational benchmarking a response lime for each product.
4. A system as claimed in Claim 1 and 3, wherein the organizational benchmarking of

response time for each product is determined by evaluating a baseline response time based on the first dependency information.
5. A system as claimed in Claim 1 and 3, wherein the resource management module further comprises of an optimization engine configured to optimize the baseline response time by creating dependencies thereof with respect to at least one historical value or at least one real time value associated therewith the response time.
6. A system as claimed.in Claim 1, wherein the competency management module maps proficiency level of each resource on a pre-determined scale for building appropriate safety margin of response time in the SLA.
7. A system as claimed in Claim 1, wherein the help desk module stores historical information including but not limited to product support request frequency, complexity and resolution time.
8. A system as claimed in Claim 1, wherein the product bundling component comprising of a phase-by-phase calculator, the said calculator adapted to optimize the first optimized response time with plurality of dependencies associated therewith each product.
9. A system as claimed in Claim 1, wherein the product bundling component further comprising of an aggregator configured to aggregate the phased response time obtained for a bundle of plurality of products to generate comprehensive SLA with a guaranteed response & resolution time for the said bundled product.
10. A method for automatic deriving of support terms for multiple open source products with different Service Level Agreements (SLAs) into a single bundled SLA characterized by having guaranteed response time, wherein the method comprising a processor implemented step of:
a. receiving at least one open source product support requirement from a customer on a user interface means;

b. storing a plurality of predefined values associated with a plurality of open
source product into a repository, the repository is adapted to
regeneratively auto-learn subsequent updates divergent from the said
predefined values;
c. for each such open source product,
fetching a resource master data, open source product data, resource management data, competency management data, help desk data, application complexity information, resource loading information, historical information into corresponding modules; and
d. executing program instructions for bundling of SLA terms in response to
inputted customer requirements;
e. benchmarking an organizational response time determined based on
information corresponding to the selected product stored in the
repository.
11. A method as claimed in Claim 10, wherein the resource master data comprises of:
a. an exclusive resource for a specific product, and
b. a shared resource for support of two or more products, the resource master
module configured to record a percentage of allocated time for each
resource for each such product.
12. A method as claimed in Claim 10, wherein the resource management data comprises of plurality of resource parameters, each parameter contributing to evaluate a response time for each product, wherein the said data is configured to receive a first dependency information for an organizational benchmarking the response time for each product.
13. A method as claimed in Claim 10 and 12, wherein the organizational benchmarking of response time for each product is determined by evaluating a baseline response time based on the first dependency information.

14. A method as claimed in Claim 10 and 12, wherein the resource management data is configured through optimization engine to optimize the baseline response time by creating dependencies thereof with respect to at least one historical value or at least one real time value associated therewith the response time.
15. A method as claimed in Claim 10, wherein the competency management data comprises a proficiency level of each resource on a pre-determined scale for building appropriate safety margin of response time in the bundled SLA.
16. A method as claimed in Claim 10, wherein the help desk data comprises historical information including but not limited to product support request frequency, complexity and resolution time.
17. A method as claimed in Claim 10, wherein the application complexity information is based on number of integration points between open source products and commercial products.
18. A method as claimed in Claim 10, wherein the bundling of support terms for SLA depends on factors comprising: response time; resolution time; severity; support hours and a combination thereof.
19. A method as claimed in Claim 10, wherein the bundled SLA is generated with a guaranteed response & resolution time comprehensively for all selected products.
20. A method as claimed in Claim 10, wherein the customer is alternatively prompted to recommend one or more SLA by way of an input prior to the SLA bundling process.