In this decision, one board of appeal confirmed that concepts for persisting database objects are technical. Here are the practical takeaways of the decision T 0731/17 (Object persistence/MICROSOFT TECHNOLOGY LICENSING) of 15.1.2020 of Technical Board of Appeal 3.5.07:
This European patent application relates to persisting objects in a data store. The background section explains that Microsoft SQL SERVER, which integrates the Microsoft Windows .NET Framework Common Language Runtime (CLR), allows creating a “user defined type” (UDT) class, instances of which can then be persisted in the database store.
UDTs extend the scalar type system of the database and can be used in the same contexts as a system type, such as in column definitions, variables, parameters, function results, cursors, triggers, and replication. The class that defines a UDT can include methods that implement specific behaviours on objects of that type.
An object of a UDT class is persisted in the database store by a process known as “object serialisation”, which transfers the values of the variables of the class to the database store’s physical storage.
When a database query which references a behaviour of a persisted UDT object is executed, the object has to be deserialised, memory for the full object has to be allocated in the CLR to receive the object’s stored values, and the method implementing the behaviour has to be invoked on the full object.
The invention aims to reduce the processing overhead associated with allocating memory for storing the full object at runtime, deserialising and populating all parts of the object, essentially by providing metadata that allows “direct structural access” to the field values in the serialised representation of the persisted object.
Here is how the invention is defined in claim 1:
Claim 1 (sole request)A method of executing a query on an object in a system in which the object is an instance of a user defined type that is persisted in a database store, wherein a definition of the user defined type comprises one or more fields and behaviors,
wherein at least one of the behaviors returns a value of one of the fields of the user defined type,
wherein each field of the user defined type is annotated with a first attribute that controls one or more storage facets of the field, wherein the first attribute in combination with an actual type of the field is used to control a storage layout of the value of the field, wherein the storage facets of the field comprise at least one of the maximum size of the field, whether or not the field is fixed length, the precision of the field, the scale of the field, and whether values of the field can be null,
wherein each of the at least one of the behaviors returning a value of the fields of the user defined type is annotated with a second attribute that denotes an equivalent structural access path, wherein the second attribute specifies a name of the field that is the subject of the behavior, wherein the name is used as the equivalent structural access path for the behavior,
wherein the object type is defined as a class in managed code, managed code being code running within a Common Language Runtime, CLR, environment, and
wherein the database store maintains information reflecting the storage layout as provided by the annotations to the type definition, the method comprising:
receiving (406), by a database server, a query that includes a predicate or an expression that references a behavior of the at least one of the behaviors returning a value of one of the fields of an object that is an instance of the user defined type;
accessing, by the database server, the information maintained by the database store to determine the storage layout of instances of the user defined type;
translating (408), by the database server, the query into the equivalent structural access path for a value of the field of the user defined type that is the subject of the referenced behavior;
structurally accessing (410), by the database server, the value in a table of the database store by parsing the object that is persisted in the database store without populating all parts of the object in the CLR environment and without invoking the referenced behavior of the object in the managed code; and
returning, by the database server, the value in response to the query.
Is it technical?
In the first instance decision, the examining division had argued that the only technical features of then claim 1 were “system”, “database store”, “server” and “persisted values” and that all other claim features, when taken in isolation, were non-technical because they were directed to a “non-technical rationale for providing ‘more efficient storage and retrieval of objects persisted in a database store'”.
The examining division then cited decision T 1954/08, arguiing that the non-technical features did not interact with the technical features to make a technical contribution because “effects stemming from the algorithmi[c] definition of a method do not define a technical character of the corresponding features”. Consequently, claim 1 was found to lack an inventive step over a “notoriously known distributed computing environment comprising general purpose computers and a network”.
The board, however, held that this reasoning is flawed:
According to decision T 1954/08 of 6 March 2013, reasons 6.2, “the sole processing speed” of a computer-implemented algorithm and “the sole amount of memory” it requires are not suitable criteria for determining whether a method step contributes to the solution of a technical problem.
However, these statements in decision T 1954/08 cannot be taken to mean that any effect resulting from the implementation of a non-technical feature or combination of features is non-technical. If non-technical features could never contribute to a technical effect just because they are non-technical, there would be no need to analyse whether non-technical features interact with the technical subject-matter of the claim to solve a technical problem or bring about a technical effect, which would be contrary to opinion G 1/04 (OJ EPO 2006, 334), reasons 5.3, and decision T 154/04 (OJ EPO 2008, 46), reasons 5, under (F), and 13 to 15.
The board also found that the inventive-step reasoning itself as provided by the examining division was not convincing:
In the present case, any attempt to properly formulate a problem that potentially would have led the skilled person from a network of general-purpose computers to the subject-matter claimed should have confronted the Examining Division with the fact that the claim, not analysed as a collection of disconnected terms but as a whole, contains various technical concepts.
For example, the claimed method involves the concept of accessing information contained in a database store via a database server. Such technical functionality is not disclosed by a network of general-purpose computers. The Board is aware that database management systems were well known at the priority date of the application (see document D1, column 1, lines 27 to 30), but that does not mean that an inventive-step reasoning can silently ignore the concept.
6.5 The separate section of the decision discussing documents D1 and D2 contains no detailed analysis. If the Examining Division was of the view that document D1, in column 3, lines 56 to 62, discloses direct access to object attributes “without de-serialization” because the cited passage does not positively state that serialisation takes place, the Board observes that no disclosure of serialisation is not a disclosure of no serialisation.
Since inventive step over documents D1 to D4 had not yet been assessed in detail, and since doing so by the board itself would have effectively replaced the examining division rather than reviewed the contested decision in a judicial manner, the board decided to remit the case back to the examining division for further prosecution.
You can read the whole decision here: T 0731/17 (Object persistence/MICROSOFT TECHNOLOGY LICENSING) of 15.1.2020