Posts Tagged ‘Coding’
Claimed Subject Matter:
Detection of files that do not contain executable code (Microsoft).
The claim was found to differ from the prior art by the fact that:
a. parsing comprises the step of parsing said input file with all the component parsers, said parsing continuing even if a component parser has already recognized said file format;
b. the compound parser is configured to allow extension by addition of a new component parser to the compound parser, the new component parser recognizing a further file format and recognizing executable code within the further file format and
c. the input file is stored only if no executable code has been found.
The Board of Appeal debated whether a step of “parsing” per se had technical character. They concluded that it did not necessarily rely on technical considerations or have technical effects – i.e. it may lack a technical character in certain cases.
In the case in question the appellant added a concrete step of “storing” based on the output of the “parsing” step. The Board of Appeal concluded that the storage of a file was a technical step that provided a further technical effect. This could then lend technical character to the preceding “parsing” step.
This article is a brief summary of the European Patent Office position on patenting inventions associated with computer programming.
It may be easier to obtain a granted patent for computer programming inventions when an application is made via the European Patent Office rather than the UK Patent Office.
However, the European Patent Office may be more likely to raise clarity objections and find relevant prior art.
Defining Case: COMVIK
The defining case in Europe is COMVIK.
Following this case, the claims of a patent application are assessed for “technical” and “non-technical” features. Only “technical” features may be used to demonstrate an improvement over previous publications.
The term “technical” is necessarily fuzzy; it has been defined in a piece-meal manner by European case law. However, it is generally taken to mean clearly relating to a field of science or engineering. Features relating to “administration” or “business” are considered “non-technical”.
Useful Case Law
The cases below provide examples of the thinking of the UK Patent Office.
- T_0505/09: in this case, an invention related to a method for identifying defective program code. At an abstract level, certain testing techniques were agreed to form part of the common general knowledge. However, there was no objection that the invention related to “non-technical” features. Instead, emphasis was put on what written evidence relating to the invention was published before the application was filed.
- T_1893/08: in this case, information on data definitions was provided in the form of a common language file represented in a different language to first and second languages for compilation. The first language had an “import” statement that imported the common language file. The board concluded that compiler features provided a solution to a “technical” problem and did provide an inventive step when compared to the cited art.
- T_1216/08: this case featured authentication of software in a dynamic loading environment. A validator generated a digital signature based on a portion of a program image, wherein pointers in the image that required “fixing up” by a program loader were excluded from the portion. Implicitly, these features were considered “technical” and an inventive step was found.
- T_0702/08: in this case, a patent claim referred generally to “process objects” and “task objects”. These terms were considered to have a broad meaning encompassing the general concept of a “goal” or “objective” at an administrative management level. It was concluded that there was no unambiguous correlation between the described “objects” and object-oriented programming. Hence, a specific technical mapping between abstract concepts and their technical implementation needs to be set out in any patent application.
- T_0077/08: here the main difference between a patent claim and a previous publication was that a business logic rule was expected as an expression rather than a statement in a programming language. It was considered obvious that both formulations would be considered. It was questioned whether making a system more “flexible” was a “technical” problem.
- T_2078/07: in this case the invention, using metadata to describe data types, was found not to provide “a further technical effect” over fundamental programming conventions. It was “simply an advice on how to write a program”.
- T_1928/07: this case referred generally to “event processes”, “tasks”, “inclusion” and “execution” in a programming context. These terms were not defined in terms of concrete, rather than abstract, features. The case was thus rejected for lacking clarity.
Claimed Subject Matter:
System, method, and computer program product for identifying code development errors.
The invention related to a method for identifying defective program code. In this case, the board considered the extent of the common general knowledge. While certain testing techniques were agreed to form part of the common general knowledge, the board directed that further, and preferably written, evidence was required to demonstrate that certain knowledge was also well known in the specific field of software testing and debugging.
Claimed Subject Matter:
A compiler system.
The subject-matter of claim 1 differs from the disclosure of the prior art in the following features:
- information on data definitions is in the form of a common language file represented in a different language to first and second source code languages;
- the first source language has an import statement that imports a common language file; and
- as part of said examination, determining if the statement is an import statement related to the common language file and, if so, reading the common language file into a symbol table by parsing the common language file and adding type and method information in metadata in the common language file to the symbol table.
This case demonstrates that features of a compiler system may be seen as technical features. Information on data definitions was provided in the form of a common language file represented in a different language to first and second languages for compilation. The first language had an “import” statement that imported the common language file.
The board concluded that these features did provide an inventive step when compared to the cited art. In particular, the board considered that the cited art suggested a particular solution that differed from the claimed solution; as such the skilled person had no motivation to introduce the novel compiler features.
Claimed Subject Matter:
Matching items with items in a table.
This case confirms that one indication of technical character is that the method has an overall technical effect, such as controlling some physical process. On the facts, the claimed invention was found to provide either an abstract data-processing effect or, taking into account the specific embodiment of matching books and compact discs, an effect in the field of business. Neither of these effects was deemed to indicate technical character.
The board did indicate though that that, based on T 424/03 or T 1351/04, a technical effect may arise from “functional data structures”. For example, an index may have technical character as it controls a computer by directing it to a certain memory location. However on the facts of the present case, the indexes in the claim were well-known or “generic”.