Description
Background of the Invention
In many companies but also in authorities, today in connection with the performance of
services, the establishment and performance of business relations or the performance of
State tasks, huge quantities of data occur. A structured and systematic technical definition,
production, processing, administration and presentation of the services performed,
relationships concluded or similar are required. Only in this way can the backgrounds and
details of the procedures connected with the data be reviewed at any time.
One example of a service provider are banks. In banking in recent years or even decades,
there has been increasing differentiation of services and prices offered. Formerly uniform
services (current account, deposit etc.) with few variants have been replaced by an ever
increasing number of different services and price alternatives. The range of financial
instruments offered becomes ever wider and the individual financing instruments are more
customer-orientated and complex.
At the same time, the customer/partners on one side and the internal auditors and official
authorities (supervisory authorities etc.) on the other, impose ever higher demands on the
service provider in relation to transparency, consistency and completeness of
data/information provided to the customer/partner by the service provider and which are
produced and archived in connection with the business relationship.
When for example in a bank a 'product' is sold to a customer/partner, a contract is
concluded. The contract establishes the agreements between bank and customer/partner,
i.e. which rights and obligations are incumbent firstly on the bank and secondly on the
customer/partner. As well as basic information, above all the individual features of the
product are included.
Problem on which the Invention is Based
One problem with the production, processing and administration of structured data sets,
such as for example those which form contracts between bank customers and a bank, lies
in that the bank firstly needs as many similarly structured products in its range as possible

but secondly wants/needs to meet customer/partner wishes. More and more, the
circumstance must be taken into account that customer advisors are not always informed of
all possibilities and also restrictions which could be important in connection with a
product. In addition, the bank's professional check of 'individually' agreed contracts can be
extremely costly.
A second problem is that with conventional definition, production, processing and
administration of products/contracts/services, the data maintenance cost incurred rises
substantially as the individual agreements are difficult to store in comprehensible but
simultaneously compact form.
Furthermore the typifying of products/contracts/services and their processing in
conventional procedures is very difficult, which is reflected in rising data traffic and
increased susceptibility to error with associated extra costs.
Finally the development of new products takes a relatively long time in conventional
procedures. This is due in particular to rising standards of compliance with legal
requirements, and the increased cost of implementation and testing in the complex IT
environment of such service providers today, for example the bank or other organisation.
WO 03/042861 A2 discloses a method and a device for computer-implemented production
and administration of contracts. In particular a method and a device are known for
computer-implemented administration of financing processes and in particular for
production and administration of contracts in connection with financial services. This
publication describes the computer-supported production and administration of contracts
between a supplier and a customer. The contracts comprise key data in a contract object
product and one or more contract modules. To structure a contract, a selection is made of
key data and contract modules, and a selection of contract modules. The contract is
produced on the basis of the selection made by generation and storage of pointers to the
selected key data and contract modules. First a selection of key data is made and then a
selection of contract modules. On the basis of these selected key data, which contain
information and rules on the product which is the object of the contract, the reliability of
the selection of individual contract modules is checked automatically. This document

explains only that a selection of key data and a selection of contract modules is made, and
that on the basis of the selection made the contract is generated by production and storage
of so-called pointers to the selected key data (= information and rules on the contract
object product) and contract modules. This document describes a set of rules only in
connection with the material provision of blocks and limits on associated payment
postings. These "Posting control rules" control the reaction of the system using preset
parameters in order, for example, to determine specific to customer group whether a
transaction should be arranged or paid directly.
Document EP 1 286 283 A2 describes interface modules for performance of document-
based electronic business processes on a transaction basis and a system for performance of
electronic business processes on a transaction basis. Thus the performance of document-
based electronic transactions between heterogenic systems is facilitated. An interface
module comprises a module for display and monitoring of the useful data flow. This
display and monitoring take place on a document basis. The transfer of the displayed
useful data to and from a terminal can take place manually or automatically. The document
templates can be entered into or modified in the file system of the interface module from a
master server in the data network. On a change in configuration of interface module,
parameters of processes concerned of work flows formed by means of document templates
can be adapted automatically. The document templates and/or a complete workflow can be
coupled by means of a mapping unit into a database with predetermined destinations in the
data network.
Object of the Invention
The object of the invention is to indicate a way of allowing, for a multiplicity of different
types of products of a service provider, for example a bank or other organisation, a
structured and systematic definition, production, processing and administration of
structured data sets such as those which describe the services and 'products' of a bank, at
the level of electronic data.
Solution According to the Invention
To achieve this object according to the invention a contract manager is provided in order to
retrieve from a product template directory containing the structures of the product
templates stored in a structured manner, a product template for individualisation and

specifically supplement this in that either at least one preset value is to be transferred or a
value selected within a permitted range in order to generate a individualised contract
document reflecting a contract, and trigger the storage of this contract in a database and its
technical processing, wherein the contract has a contract header and at least one basic
function derived from the product template, wherein the software program component
contract manager provides functionalities for managing the contract data and all customer-
/partner-relevant customer contracts are managed and administered, characterised in that at
product template level distribution rules are implemented, a distribution rule being an
independent object with its own identification and a descriptive text, the distribution rules
are provided by a rule base, and a distribution rule determines which conditions are to be
fulfilled in order for a customer/partner to be given access to a product with the basic
function concerned, a relationship is created between a distribution rule and its allocated
basic function, and distribution rules can also be used across several basic functions of a
product template.
In other words the invention provides that a contract is based on a product template which
the customer advisor specifically supplements in consultation with the customer/partner.
Here either the pre-set value (default) is used or a value within the permitted range is
selected individually for the customer/partner. Conclusion of the contract, i.e. the sale of a
product, triggers two main activities on the side of the service provider (bank). Firstly a
physical contract document is produced which is usually signed by both parties and given
to the customer/partner. Secondly storage of a contract in the (bank) internal data
processing and the technical processing of the contract are triggered.
According to the invention the contract consists of a contract header and at least one basic
function. The basis for the contract is the completed product template i.e. the product sold.
From the product template the contract header is derived and from each basic function
included in the contract, a basic function contract is produced. The basic functions can
have different origins. Depending on origin of the basic function i.e. depending on the
identity of the basic function producer, different basic function contract data are contained
in the contract. Basic functions from particular producers with their own data management
are shown in the contract merely as a key. The actual basic function contract is passed onto
the producer of the basic function.

Producers without their own data management simply store their basic function in a
separate database. This basic function contract data are stored in the contract. Information
on pricing, instructions and even interest do not appear in the contract. Storage and
retrieval take place directly via the corresponding software program component. An
extract from the most important contract data is. replicated in a contract directory which is
available as a reference directory.
The software program component contract manages and administers all customer-/partner-
relevant customer contracts. The software program component contract provides services
for definition of the contract data. In relation to third party software program components,
the contract-specific functionalities/services are always retrieved by a software program
component contract manager and never directly. One condition for opening a contract is
the presence of a partner or corresponding business relationship. Each contract must
consequently be able to be allocated directly to a business relationship or a partner. The
contracts are always defined by the software program component contract manager. The
basis for opening a contract is the product template. The product template specifies all
necessary information such as value ranges, defaults, compulsory and optional fields for
conclusion of a contract. The individual features of a sold product, defined on the basis of
the defaults in the product template, are depicted in the contract. The contract consequently
is based in structure and content on the product template i.e. each contract refers to a
corresponding product template.
The contract header is derived from the product template and forms the envelope for the
basic function contracts belonging to the contract. The contract header contains different
keys (product template ID and contract header ID). In addition further information such as
for example lifecycle information (status, opening date etc.) are contained in the contract
header.
The basic function contract is based on the basic functions defined in the product template.
On the basis of the different basic function types or producers, the basic function, contracts
differ in scope of information contained in the contract.

Basic function producers with their own data management, to process their transactions,
have their own physical data representation (i.e. table/data model) of their basic functions.
In this case the contract data of the basic function contract is fully contained in the data
records of the basic function producer.
On contract conclusion the complete basic function contract is transmitted via an interface
to the corresponding basic function producer who stores the data accordingly in his
database component.
The contract itself contains only references (keys) which point to the corresponding basic
function producer or holder of the basic function contract.
For basic function producers with separate data management, software program
components are used which do not contain their own physical representation of the basic
function but store this completely in the product. On contract conclusion the complete
basic function contract is stored in the contract; depending on origin of the basic function,
the basic function contract may be only partially depicted.
'References' are for example prices, instructions and interest. These are not stored in the
contract even as references (keys). The prices, instructions and interests belonging to a
contract must be determined by corresponding querying of the software program
component containing the data.
The invention furthermore concerns a computer program product which is designed to
implement a system defined in any of the preceding claims when processed by a computer
or computer network. The computer program product can for example be stored on a
computer-legible magnetic or optical information carrier (such as a CD ROM).
Brief Description of the Drawings
The invention is explained in more detail below with reference to the enclosed drawings.
Fig. 1 shows diagrammatically a computer system and the computer program components
present in the computer system and their interaction.

Fig. 2 shows diagrammatically the correlation between basic function, product template
and contract.
Fig. 3 shows diagrammatically the processing of rules by the software program component
contract manager.
Fig. 4 shows diagrammatically how a contract is produced from a product template.
Fig. 5 shows diagrammatically the structure of rules and their interaction with the basic
functions and product templates.
Fig. 6 shows diagrammatically the retrieval of rules by the software program component
contract manager.
Detailed Description of Embodiment Example
Fig. 1 shows a computer-implemented system for producing, processing and managing
structured data sets. This system has one or more servers for data and/or program
management and a multiplicity of workstations which are connected with the server for
data or program exchange. In this system a computer software program component basic
function configurator BLK is provided. The basic function configurator BLK serves to
define a generic basic function. A generic basic function depicts at least one function
performed or to be performed according to a hierarchical organised model. For this by
means of descriptive attributes and associated values or value ranges necessary for
processing the basic function, the generic basic function is structured and depicted on one
or more data sets, to each of which is allocated at least one distribution rule. The data sets
together with the allocated distribution rules each define a generic basic function.
Furthermore a basic function directory BL-D1CT is provided in which the data sets
defining the generic basic functions together with their associated distribution rules are
stored in a structured manner as a database for access by a computer software program
component product template configurator.
The product template configurator PVK is intended to combine one or more basic
functions from the database in the basic function directory and transfer these into a product

template POT, in that the generic basic functions are mutated into specific basic functions
for the product template concerned by transfer or restriction of values and/or value ranges
for the attributes. For this a product template POT comprises one or more basic functions
which compulsorily belong to a product. It can also comprise one or more basic functions
to be expressly added to or deselected from a product.
The product templates are stored in a product template directory. Here the complete
structure of the product templates is stored in a structured manner for access by a computer
software program component contract managerand depiction on a graphic or
alphanumeric user interface GUI.
In order to retrieve and specifically supplement a product template for individualisation
from the product template directory in which the structures of the product templates are
stored, by means of the contract manager either at least one preset value must be taken or a
value selected within a permitted range. In other words the permitted range is (further)
restricted. Thus an individualised contract document reflecting the contract is produced,
and the storage of this contract in a database and its technical processing are triggered.
The contract comprises a contract header and at least one basic function derived from the
product template. From each basic function included in the contract a basic function
contract is derived, from which predetermined basic function contract data are transmitted
to the respective basic function producer. For producers with their own data management,
in the contract the basic function contract data are kept as a key and for producers without
their own data management, these basic function contract data are stored in the contract.
The software program component contract manager provides functionalities for defining
the contract data available and manages and administers all customer-/partner-relevant
customer contracts.
Fig. 2 shows the correlation and relationships between basic function(s), rule(s), product
template(s) and contract in further detail.
A data structure of a basic function according to the invention can have the following
structure (see Fig. 3):

- Basic function not released and inactive for product configuration (no more
contracts may be issued).
The steps are described below with which a product is configured, in that a product
template (POT) is produced (or an existing product template (POT) re-used in the manner
of a template):
- Define product template (short text, long text, identifier, status etc) .
- Import one or more basic functions from the basic function directory (BL-DICT)
- Basic function must be released and active

• Basic function is instanced as a product template basic function
• On the product template basic function (POT-BL) the following actions are
performed:

■ Its status is changed to "in processing"
■ Rules are defined for the product template basic function
■ Define permitted business case types (a basic function can have
several business cases, for example basic function Account has
business case types Monthly statement, Intermediate statement or
Annual statement)
■ Establish or restrict attribute value ranges (within the permitted
values of the basic function)
■ Establish default values of the attributes.
When creating a product template from one or more basic functions, the status of the basic
functions included is set at that which is productive at the time of production of the
product template. This is irrespective of whether or not adaptations are made to the basic
functions in the product template. This referencing applies until the next explicit mutation
of the product template. Consequently there are no "sliding" or automatic updates of
product templates.
A check function is provided in order if necessary to detect those product templates which
use basic functions that are mutated after production or the last mutation of the product
template. On the basis of this it must be checked whether the product template concerned
can continue to be used sensibly. In particular individualisation of basic functions in a

product template and the allocation of rules to a product template must be checked. If a
product template is brought to the latest state of the basic functions contained therein, an
explicit mutation to the header data of the product template is required. For this an entry is
made on the existing product template ID with the current time stamp.
From a product template a contract is produced by the following actions being performed
(see Fig. 5):
• The master data of a customer/partner are read from the corresponding
database.
- Check for products suitable or permitted for the customer/partner
- Issue of the product list of all suitable/permitted products
• The associated product template is read.
- Input: product template ID and partner ID
- Checking of distribution rules
- Output of product or product template on the graphic/alphanumeric user
interface
• Individualisation of product template in that
- Attributes are adapted within the possible value ranges
• Open contract by
- Checking distribution rules
- Creating the business case "Open contract" in the database of the bank
- The contract is entered in the software program component "Contract" and
in the contract directory
- Any instructions and redemptions are applied
- Corresponding software program components are added
- The software program components "Price structure" and the attribute
derivation (for account products) receive messages with partial or complete
data on the contract

In the formation of a contract, the metadata of the basic functions and product templates
are accessed. On the basis of this information it is known which software program
components or business subsystems/solution areas can or must be involved in the contract
concerned. It is also known by means of which attributes/ interfaces data can be exchanged
by the corresponding components.
The metadata of the basic function, in particular the basic function contained in a product
template, contains in addition to the structural data also permitted value ranges of the basic
function attributes. These value ranges are usually established by the corresponding
software program components and describe the permitted values. The value ranges can be
quite complex even in basic function definition e.g. combinations from lists of individual
values and value ranges can be depicted. This also applies to references to other tables e.g.
reference data. From the aspect of the individual attribute they are static value ranges
which may not be adequate, for example if a value range is given for an attribute which is
defined by means of a data-dependent formula. For such certainly less common cases, the
rule basis can be used as a solution in that for the attribute of the basic function as a value
the key of the rule is given which performs the complex validation.
Also with regard to a basic function a value range definition per attribute may not be
adequate. A definition of value ranges across attributes is possible.
For example if attribute A assumes value Al, attribute B may only assume values Bl, B2
and B3; in all other cases the value range BIO to B100 is permissible for attribute B.
Also with regard to a product template the attribute-specific definition of value ranges may
not be sufficient. For the above cases i.e. for dynamic value ranges of individual attributes
and for all value range checks across attributes, corresponding rules are made available via
the rule basis. The rules contained therein are formulated for reusability so that as many
checks as possible on different attributes, basic functions and product templates can be
performed with as few rules as possible. To allow this reusability, a relationship is
explicitly created between a rule and its allocated object (attribute, basic function, product
template). Although a relationship can be created between each object and each rule, the
following precondition applies:

For rules there is no lifecycle in the rule base. Static and dynamic rules differ. In the rule
base for static rules, only the information Program name, Input/output copybook name is
contained. Content mutations of rules are therefore not included in the rule basis but in the
reference to program. Dynamic rules are functionally limited and only provided for
prototyping purposes. The relationship between rule and product template is provided in
the model as a relationship entity. Here it is possible to add or remove rules subsequently
during the lifecycle of a product template without the product template itself having to be
altered. To correctly depict a product template, a lifecycle is managed for this relationship
so that at each time in the contract the correct i.e. current valid rule is used and processed.
Dynamic rules usually consist of an SQL statement and are prepared and executed by a
driver program available for this. The convention is that for SQLCODE 0 (zero) the value
OK is used and for SQLCODE 100 the value NOK, and for all other SQLCODES the
value DB-ERROR (this is a special case for NOK) is returned. The rule base contains, as
well as the SQL statement text, also descriptive information on the variables which must
be provided for performance of the rule. In production because of the greater stability and
speed, only static rules are executed. As the rule base for a rule contains the program name
and input and output copybooks, for performance of static rules a general driver program
can also be provided.
For validation rules the dynamic value range of an attribute should not be structured across
attributes. Instead of the static value of an attribute the key of the rule is entered. This
means at the same time that in this case precisely one rule is allocated to the attribute. For
value range checking across attributes, for attributes of a basic function or a basic function
in a product template, an explicit (n:m) relationship is generated between a basic function
or a basic function in a product template and a rule of the rule base. Thus a basic function
can have relationships with several rules and a rule can be used in several basic functions.
Distribution rules can be used across several attributes of a product template i.e. also
across several basic functions of this product template. Thus rules can assume considerable
complexity.

All the above rule types are "hard" rules i.e. they indicate whether a particular data
combination can or cannot lead to a contract.
Thus it is recommended to implement distribution rules only at product template level. The
definition of distribution rules at the level of the basic function greatly restricts the
reusability of the basic function.
A rule is an independent object with its own identification (STID) and a descriptive text of
160 Bytes. The argument of a rule is a list of parameter values. The return values of a rule
are usually OK or NOK.
In processing types of a rule we distinguish between static (which integrates a program
with fixed input and output interface (copybook)) and dynamic (integrated statement text
of an SQL statement with parameter markers in which the WHERE condition result are
divided into SQLCODE 0 = OK, SQLCODE 100 = NOK and other codes = ERROR.
As Fig. 6 shows, a rule is retrieved such that the software program component contract
manager can receive the rule ID and the input values for the rule e.g. from the GUI. Thus a
generic rule driver is retrieved which reads the rule table. The rule is then executed
statically or dynamically (static for production mode, dynamic for prototyping in
development). The information on the rules in the rule table in the static case is the
program name and input/output interface (= copybooks) and in the dynamic case an SQL
statement text with parameter markers (spacers for variables) with for example around
twenty variables, information on name, format of variables.
In a static rule all copybooks of all static rules are known to the rule driver. The transferred
parameter values are transferred in the fields of the copybook. Then a retrieval takes place
of the type "CALL program USING copybook-in, copybook-out". An OK or NOK is
returned from the rule driver.
In a dynamic rule the parameter markers are replaced in the statement text by transmitted
values. The parameter formats are known from the rule table (numeric, character, date-

time, ...)• The rule is then processed by PREPARE and EXECUTE the statement text.
SQLCODE 0 gives OK, SQLCODE 100 gives NOK, otherwise DB-Error.
The distribution rules are retrieved for example if a customer/partner wishes to receive a
particular service. Based on a search function, the program component contract manager
has a list of POT's which contain relevant basic functions. The program component
contract manager for each of these POT's retrieves a rule driver which checks the
distribution suitability of the POT for the customer concerned. For this the rule driver
inputs the business relationship ID and the POT ID. The output from the rule driver is then
OK/NOK.
The rule driver executes the following activities: read data on business relationship ID and
read rule use with POT ID. Then each rule program is retrieved with the following
interface: attribute to business relationship ID, POT ID and return of rule program
OK/NOK.
On the first NOK the retrieve of the rule program is interrupted and the contract manager
receives NOK.
To ensure a static value range (including reference tables) no rules are required in the rule
base as these have already been provided by tables for the attribute values.
The data on basic functions (BL) and product templates (POT) are managed so that each
mutation of these objects can be clarified and reconstructed at any time. Mutations can
have ad hoc validity in online operation. Mutations are also permitted in the future. For
stability and handling considerations the current valid state of a basic function or product
template is defined by convention (recommendation) as the state valid for the current date
at zero hours.
As well as this principle there are the following-conventions and application processes
which are provided for managing basic functions and product templates:

We Claim :
1. Computer-implemented system for production, processing and management of
structured data sets, wherein in this system:
- a computer software program component contract manager is provided to
retrieve from a product template directory, in which the structures of the
product templates are stored in a structured manner, a product template for
individualisation and specific supplementing, in that either at least one preset
value is to be transferred or a value is to be selected within a permitted range,
wherein a product template comprises one or more basic functions which
compulsorily belong to a product, and can comprise one or more basic
functions to be expressly added to or deselected from a product, in order to
generate an individualised contract document reflecting a contract and trigger
the storage of this contract in a database and its technical processing, wherein
- the contract comprises a contract header and at least one basic function derived
from the product template, wherein
from each basic function included in the contract a basic function contract is
derived, from which preset basic function contract data are transmitted to the
respective basic function producer, and for producers with their own data
management in the contract the basic function contract data are shown as a key,
and for producers without their own data management these basic function
contract data are stored in the contract, and wherein
- the software program component contract manager provides functionalities for
implementing the contract data and managers and administers all customer-
/partner-relevant customer contracts, and wherein
distribution rules are implemented at the level of the product templates, which
indicate whether or not a particular data combination can lead to a contract,
- a distribution rule is an independent object with its own identification and a
descriptive text,
- the distribution rules are made available by a rule base, wherein
- a distribution rule determines which conditions are to be fulfilled so that a
customer/partner is given access to a product with the basic function concerned,

between a distribution rule and its allocated basic function a relationship is
created, and
distribution rules are used across several basic functions of a product template,
and
only static rules are executed in production, wherein
- on production of the contract from a product template, the distribution rules are
checked in that the contract manager retrieves a generic rule driver, and
wherein
the contract manager has a search function which for a particular desired
function provides a list of product templates, wherein the contract manager for
each of these product templates retrieves a rule driver which checks the
distribution ability of the product template for the customer concerned and
returns to the rule driver an OK or an NOK.
2. Computer-implemented system for production, processing and management of
structured data sets according to any of the preceding claims, in which an extract
from predetermined contract data is to be replicated in a contract directory.
3. Computer-implemented system for production, processing and management of
structured data sets according to any of the preceding claims, in which the contract
header derived from the product template forms an envelope for the basic function
contracts belonging to the contract, and the contract header contains various keys.
4. Computer-implemented system for production, processing and management of
structured data sets according to any of the preceding claims, in which each basic
function contract is based on the basic functions defined in the product template.
5. Computer-implemented system for production, processing and management of
structured data sets according to any of the preceding claims, in which the
distribution rules comprise age, domicile, customer segment and/or legal
restrictions.

6. Computer-implemented system for production, processing and management of
structured data sets according to any of the preceding claims, in which the
distribution rules in the contract cannot be overruled.
7. Computer-implemented system for production, processing and management of
structured data sets according to any of the preceding claims, in which the
distribution rules with legal restrictions must compulsorily be transferred to the
contract on product configuration.
8. Computer-implemented system for production, processing and management of
structured data sets according to any of the preceding claims, in which validation
rules are provided to check whether values or ranges of attributes are observed in
the contract or whether inputs in fields are correct in relation to the respective field
formats.
9. Computer-implemented system for production, processing and management of
structured data sets according to any of the preceding claims, in which the
validation rules, on checking whether values or ranges of attributes are observed or
inputs in fields are correct in relation to the respective field formats, return as a
result "OK/NOK".
10. Computer-implemented system for production, processing and management of
structured data sets according to any of the preceding claims, in which one or more
validation rules are provided which, to individualise a contract, perform a pre-
selection and checking of product templates, for which a contractual relation must
be opened/modified for a customer/partner, and which on checking return a result
set.
11. Computer-implemented system for production, processing and management of
structured data sets according to any of the preceding claims, in which to
individualise a contract one or more validation rules are provided to determine a
customer-/partner-specific preset (default) before or during representation on a
graphic or alphanumeric user interface.

12. Computer-implemented system for production, processing and management of
structured data sets according to any of the preceding claims, in which one or more
validation rules are provided for checking observation of a value or value range or
a data set to ensure processability of a basic function, wherein the values/value
ranges/data sets to be checked are pre-specified in the product template concerned.
13. Computer-implemented system for production, processing and management of
structured data sets according to any of the preceding claims, in which the data
belonging to a contract are managed so that each mutation of the data can be
clarified and reconstructed at any time and in which the storage duration of contract
data which are no longer valid is established as an attribute.
14. Computer-implemented system for production, processing and management of
structured data sets according to any of the preceding claims, in which a change of
an attribute of the contract header triggers the production of a new entry in the
contract header.
15. Computer-implemented system for production, processing and management of
structured data sets according to any of the preceding claims, in which at least one
derived attribute is stored in the contract header, wherein a change in a derived
attribute does not trigger production of a new entry in the contract header but an
update of this attribute is performed.
16. Computer-implemented system for production, processing and management of
structured data sets according to any of the preceding claims, in which a change of
an attribute of a basic function contract triggers production of a new entry in the
basic function contract and/or an update of this attribute in the contract header is
performed.
17. Computer-implemented system for production, processing and management of
structured data sets according to any of the preceding claims, in which on
production of an individualised contract header and/or basic function contract a

reference is generated to a product template or a specific basic function for the
product template concerned.
18. Computer-implemented method for production, processing and management of
structured data sets, wherein
a computer software program component contract manager retrieves from a
product template directory, in which the structures of the product templates are
stored in a structured manner, a product template for individualisation and
specific supplementing, in that either at least one preset value is to be
transferred or a value is to be selected within a permitted range, wherein a
product template comprises one or more basic functions which compulsorily
belong to a product, and can comprise one or more basic functions to be
expressly added to or deselected from a product, in order to generate an
individualised contract document reflecting a contract and trigger the storage of
this contract in a database and its technical processing, wherein
- the contract comprises a contract header and at least one basic function derived
from the product template, wherein
from each basic function included in the contract a basic function contract is
derived, from which preset basic function contract data are transmitted to the
respective basic function producer, and for producers with their own data
management in the contract the basic function contract data are shown as a key,
and for producers without their own data management these basic function
contract data are stored in the contract, and wherein
- the software program component contract manager provides functionalities for
managing the contract data and manages and administers all customer-/partner-
relevant customer contracts, and wherein
- distribution rules are implemented at the level of the product templates, which
indicate whether or not a particular data combination can lead to a contract,
- a distribution rule is an independent object with its own identification and a
descriptive text,
- the distribution rules are made available by a rule base, wherein

a distribution rule determines which conditions are to be fulfilled so that a
customer/partner is given access to a product with the basic function concerned,
and
between a distribution rule and its allocated basic function a relationship is
created,
distribution rules are used across several basic functions of a product template,
and
only static rules are executed in production, wherein
on production of the contract from a product template, the distribution rules are
checked in that the contract manager retrieves a generic rule driver, and
wherein
- the contract manager has a search function which for a particular desired
function provides a list of product templates, wherein the contract manager for
each of these product templates retrieves a rule driver which checks the
distribution ability of the product template for the customer concerned and
returns to the rule driver an OK or an NOK.
19. Computer-implemented method for production, processing and management of
structured data sets according to claim 18, in which an extract from preset contract
data is to be replicated in a contract directory in which the contract header derived
from the product template forms an envelope for the basic function contracts
belonging to the contract, and the contract header contains various keys.
20. Computer-implemented method for production, processing and management of
structured data sets according to any of the preceding claims 18 - 19, in which each
basic function contract is based on the basic functions defined in a product
template.
21. Computer-implemented method for production, processing and management of
structured data sets according to any of the preceding claims 18 - 20, in which at
least one distribution rule is allocated to each basic function, wherein preferably in
the contract distribution rules determine which conditions are to be fulfilled so that
a customer/partner has access to a product with the basic function concerned,

and/or in which the distribution rules comprise age, domicile, customer segment
and/or legal restrictions, and/or in which the distribution rules in the contract
cannot be overruled, and/or in which the distribution rules with legal restrictions
must compulsorily be included in the contract on product configuration.
22. Computer-implemented method for production, processing and management of
structured data sets according to any of the preceding claims 18 - 21, in which
validation rules are provided to check whether in the contract values or ranges of
attributes are observed, or whether inputs in fields are correct in relation to the field
format concerned, in which the validation rules, on checking whether in the
contract values or ranges of attributes are observed or whether inputs in fields are
correct in relation to the field format concerned, return as a result "OK/NOK",
and/or in which one or more validation rules are provided which to individualise a
contract perform a pre-selection and checking of product templates for which a
contract relationship is to be opened/modified for a customer/partner and which on
checking return a result set.
23. Computer-implemented method for production, processing and management of
structured data sets according to any of the preceding claims 18-22, in which to
individualise a contract one or more validation rules are provided to determine a
customer-/partner-specific preset (default) before or during representation on a
graphic or alphanumeric user interface, in which one or more validation rules are
provided to check observation of a value or value range or data set to secure the
processability of a basic function, wherein the values/value ranges/data sets to be
checked are pre-specified in the product template concerned.
24. Computer-implemented method for production, processing and management of
structured data sets according to any of the preceding claims 18 - 23, in which the
data belonging to a contract are managed so that each mutation of data can be
clarified and reconstructed at any time, and in which the storage period of contract
data which is no longer valid is established as an attribute.

25. Computer-implemented method for production, processing and management of
structured data sets according to any of the preceding claims 18 - 24, in which a
change of an attribute of the contract header triggers production of a new entry in
the contract header, in which at least one derived attribute is stored in the contract
header, wherein a change in a derived attribute does not trigger production of a new
entry in the contract header, but an updating of this attribute is performed, and/or in
which a change of an attribute of a basic function contract triggers a production of
a new entry in the basic function contract and/or an update of this attribute in the
contract header is performed.
26. Computer-implemented method for production, processing and management of
structured data sets according to any of the preceding claims 18-25, in which on
production of an individualised contract header and/or basic function contract, a
reference is generated to a product template or a specific basic function for the
product template concerned.

A data management system has a basic function configurator to define a generic basic
function, whereby the function to be performed is to be depicted in a basic function by
means of descriptive attributes and associated values or value ranges necessary for
processing the basic function. The function is to be depicted on a data set to which a
distribution rule is allocated. A data set, with its associated distribution rules, defines a
generic basic function. The data sets which define the generic basic functions, together
with their distribution rules for access by a product template configurator, are contained in
a basic function list. The product template configurator combines one or several basic
functions and transfers these to a product template, in that the generic basic functions are
mutated into specific basic functions for the product template concerned by transferring or
restricting the values. A product template comprises one or more basic functions belonging
to a product. A product template with specific basic functions serves as a basis for a
contractual relationship with a partner. The structure of the product template is stored in a
product template list for access by a contract manager.