T 2055/08 13-02-2014

I. This is an appeal against the refusal of European patent application No. 03 775 360 for lack of an inventive step (Article 56 EPC 1973).

II. At oral proceedings before the board the appellant requested that the decision under appeal be set aside and that a patent be granted with the following documents:

Description

pages 1, 1a, 2, 2a, 22 as filed during the oral proceedings before the Board,

pages 3-21 of the application as published;

Claims

1-7 as filed during the oral proceedings before the Board, titled final version;

Drawings

Figures 1-20, sheets 1/15-15/15 as published.

III. Claims 1, 3 and 4 of the sole request read as follows:

"1. A method for use in an electronic learning system that manages versioned learning objects in a master repository (130) storing the learning objects that are valid throughout the electronic learning system to be accessed by any user of the electronic learning system and in a local repository (132) for storing a local version of the object to create and edit new learning object versions which can be checked-in to the master repository (130) by storing,

wherein the learning objects comprise at least one referencing learning object and at least one referenced learning object which is referenced by the referencing learning object,

wherein the referencing learning object has metadata which stores a reference to the referenced learning object;

the method comprising:

defining two conflict rules as follows:

- according to a first conflict rule, each learning object version within the master repository (130) must not reference, directly or indirectly, any other learning object in more than one version; and

- according to a second conflict rule, each local repository (132) must not contain any learning object in more than one version;

detecting a version conflict associated with a learning object by checking for compliance with both of the two conflict rules during each creation of a version of the learning object and each deletion of a version of the learning object; and

resolving the version conflict by ensuring compliance with the two conflict rules, comprising:

- when a checked-in version of a learning object is edited in a local repository (132):

-- creating a new version of the learning object,

-- replacing the checked-in version with the new version, and

-- updating metadata of each object referring to the learning object with version information for the new version of the learning object;

- when reverting to an earlier version of a learning object:

-- deleting the most recent version of the learning object;

-- revising metadata of all objects in the local repository (132) that refer to the most recent version of the learning object to refer to the earlier version of the learning object;

- when checking-in edited versions of existing learning objects from the local repository (132) to the master repository (130), requiring each learning object version to be checked in with all recursively referenced learning objects of the learning object version."

"3. A computer program product for use in an electronic learning system, wherein the computer program product manages versioned learning objects in a master repository (130) and in a local repository (132) according to the method of claim 1 or 2."

"4. An electronic learning system (59), comprising:

a master repository (130) which stores existing versions of learning objects being valid throughout the electronic learning system to be accessed by any user of the electronic learning system;

a local repository (132) which stores alternate versions of the learning objects stored in the master repository (130), wherein the local repository (132) allows creation and editing of new learning object versions which can be checked-in to the master repository (130) by storing; and

a processor that executes instructions to perform the steps of the method according to claims 1 or 2."

IV. The following documents are mentioned in this decision:

D1 = US 6 430 563 B

D2 = US 5 675 802 A

D5 = GB 2 373 625 A

V. The examining division essentially argued that:

- The claim had technical character in so far as the subject-matter of the claim was directed to a method for use in an electronic learning system. The claim, however, comprised the steps of an administrative method which was being implemented in the electronic learning system. The claim was thus prima facie made up of technical and non-technical features.

- The terms used in the method steps of claim 1, ie "learning object", "local repository", "master repository", "cascading conflict resolution", "propagating metadata" did not confer any technical meaning to these method steps. These method steps did not go beyond an abstract concept for managing objects and references between them. The method thus defined an administrative concept as such. Administrative methods as such fell under the list of exclusions from patentability under Article 52(2) and (3) EPC.

- The technical character of the claim resided in a general purpose networked computer system and a database used for data processing and data exchange.

- The non-technical features of the method did not interact with the technical features to alter the technical character of the claimed subject-matter from that of a generic commonplace networked computer system and a database. Hence the non-technical features of the method could be used for defining the problem to be solved and presented a non-technical requirements specification which requested the skilled person to automate the method in some way. The objective technical problem to be solved could therefore be considered as the translation of the non-technical method into a general purpose networked computer system. Implementing non-technical functions through standard programming techniques into a general purpose networked computer system was a typical task carried out by the person skilled in the art of data processing which did not involve an inventive step.

VI. The appellant applicant essentially argued as follows:

- The technical problem to be solved by the present invention could be defined as to hold a learning system clear from any learning objects referring to different versions of learning objects in the master repository, ie to avoid that inconsistent data be supplied. To solve the above technical problem the invention provided a method for managing versioned learning objects in a master repository and in a local repository wherein upon detecting a version conflict, the version conflict was resolved by means of a cascading conflict resolution. The cascading conflict resolution was achieved by propagating metadata from a referencing learning object to the referenced learning object in the master repository wherein existing references in the referenced learning object were overwritten by the metadata from the referencing learning object. This was carried out so that each learning object in the master repository did not reference directly or indirectly any other learning object in more than one version and each local repository did not contain any learning object in more than one version.

- Moreover, the specific way of resolving conflicts, namely by propagating metadata from a referencing learning object to the referenced learning object, could not be regarded as a simple administrative concept, but rather implied technical considerations on how the required versioning was achieved and implemented. Basically, "overwriting" in the meaning of "overriding" referred to a method step which could not be denied to be of technical character. Thus, technical considerations, at least the one leading to the use of the method step "overwriting", were made to achieve the subject-matter of the present invention so that the respective features had to be taken into account when assessing inventive step.

- In order to ensure that when editing a previously checked-in object version the local repository did not contain any learning object in more than one version, conflict resolution was performed according to the steps defined in the claim. This was an example of cascading conflict resolution, since metadata that defined references between objects was propagated to each object referring to the learning object with version information for the new version of the learning object. This propagation started from a referencing object and continued (cascaded) through references to referenced objects. The version conflict was resolved in the sense that the checked-in version of the object was replaced with the new version, so that the checked-in version of the object was no longer present in the local repository.

- To ensure that the local repository did not contain any learning object in more than one version when reverting to an earlier version of a learning object, the most recent version of the learning object was deleted from the local repository. This was also an example of cascading conflict resolution, since metadata of all objects in the local repository referring to the most recent version of the learning object was revised, i.e. overridden. The propagation of metadata started from a referencing object and continued (cascaded) through references to referenced objects.

- Finally, the last step of claim 1 described how to ensure compliance (i.e. resolve conflicts) with the first conflict rule. Without this requirement, any conflict checks might be incomplete since locally referenced objects could still be changed after check-in.

- When applying the problem-and-solution approach, the skilled person could consider document D2 to be the closest prior art. However, D2 did not disclose the compliance with the two conflict rules defined in the claim. These rules assured that the consistency of the electronic learning system was maintained and that learning objects could be easily and flexibly reused. It further allowed the separation of version conflict checking into two parts, making the version conflict detection step easy and efficient. Accordingly, the skilled person was confronted with the objective technical problem of how to maintain the consistency of an electronic learning system in an easy and efficient way. In order to solve this problem, the skilled person could start from D2. However, D2 disclosed that consistency could be maintained by ensuring that only a single user at a time modified a given branch, thereby avoiding version conflicts. In contrast to D2, claim 1 provided the skilled person with a different approach for solving the problem above. According to claim 1, version conflicts were detected by checking for compliance with two conflict rules and the conflict detection was performed at specific times, i.e. during creation and deletion of a version of a learning object. Any conflicts were thus resolved by ensuring compliance with the two conflict rules. Compliance with the second conflict rule was ensured at object check-in and when reverting to an earlier version of an object. Compliance with the first conflict rule was ensured by making sure that all referenced objects were checked-in with their referencing object. This ensured that all the dependencies of an object were present in the repository when the object itself was checked-in, so that the dependent objects were not changed after their referencing object had been checked-in. Such an approach was neither taught nor indicated by D2. In order to solve the objective technical problem the skilled person could also consult Dl. However, Dl did not provide any suggestions how to resolve version conflicts.