So, rather than trying to get the directive to resolve all the issues, they suggest resolving patent reform issues and then swing back around later, when such arguments can't be made presumably by opponents of the directive. Frankly, it sounds like they are afraid there will be a no-software-patents decision, and they'd prefer the status quo to that.

I think 5 years off is a grand idea, since the EU suggests giving Microsoft a gift, 5-year breather on allowing FOSS to interoperate with them in the server space. It makes the playing field a little more even, don't you think? Let's all have 5 years off. Just kidding. Sort of. Actually, I think software and patents need to get a divorce. And stay away from each other.

You can read the Dutch message here or read FFII's English translation, which I reproduce. They naturally disagree with the Dutch government, because they want a clear statement now of no software patentability.

Here's the Dutch government's report, in English:

**************************************

Advice to the State Secretary of Economic Affairs on the stance to be adopted by the Netherlands in the second reading on the Directive on the Patentability of Computer-implemented Inventions.

Introduction:

For the purpose of the Netherlands’ stance in the second reading on the Directive on the Patentability of Computer-implemented Inventions, the State Secretary of Economic Affairs has set up an Advisory Committee to advise her on the stance she is to adopt.

This Advisory Committee consists of:

• Francine Giskes (Chairman, former member of Dutch Parliament for D’66)
• Joop Sistermans (Chairman Advisory Council for Science and Technology Policy)
• Reinier Bakels (expert on software patents and researcher at Maastricht University)
• Michiel van Genuchten (product marketing director of Philips Software and parttime

professor of Software management at Eindhoven University of Technology).

The request put to the Advisory Committee was for its advice on the stance to be adopted by the Netherlands in the second reading. The Netherlands’s declaration of voting upon acceptance of the common stance is an important issue in this respect. This declaration of voting says that the Netherlands will only vote in favour of a final Directive if it provides clarity on what is and what is not patentable and also discourages the granting of trivial patents. A balance must also be found between the interests of companies that do and companies that do not want to make use of patents on computer-implemented inventions.

The Advisory Committee has met four times to consider this issue. It has also considered the work of the Working Group on Software Patents and has participated in the round table session on 12 May.

The Advisory Committee has drawn up the following advice:

Basic principles:

1. In the Advisory Committee’s opinion, the Directive wrongly persists in the view that the Directive concerns solely the patenting of ‘computer implemented inventions’. This gives rise to the suggestion that there is a distinction between such inventions and patents on software inventions or computer programmes. However, in practice this distinction cannot be (properly) made and will become more and more blurred in the future as well.

It is important to acknowledge in the discussion that patents on computer programmes do indeed exist. One could think in this respect of inventions for improving (the sharpness of) images, which could be implemented in both hardware and software. The Advisory Committee believes that it is illogical for such an invention to be patentable in hardware but for a patent not to be permitted if a software implementation is chosen for. At the same time it is evident that software implementations will increasingly be chosen for in the future. New versions can then be downloaded and subsequently loaded in products in order to implement the improved versions of the invention. As a result, the invention corresponds to a large extent with the computer programme. The Advisory Committee feels in this example that the argument for distinguishing between computer implemented inventions and patents on computer programmes is untenable. Other examples can be found in many business sectors: automotive, medical electronics, chip design and oil exploration.

The Advisory Committee takes the view that software and computer programmes form part of technology, and in that sense there are no proper grounds to justify the exclusion of software or computer programmes from patentability or to treat them differently to any other areas of technology. Secondary arguments for this too, such as low reproduction costs of software or the availability of the protective regime of the Copyright Act, are not decisive in the view of the Advisory Committee.

The Advisory Committee also believes that a stricter definition of the term ‘technology’ would not be effective. Attempts to define ‘technology’ in legal terms will not provide a convincing solution for demarcating software patents.

2. The aim of the Directive is to harmonise the practice of assessing patents on computer-implemented inventions and to codify practices that have developed at the European Patent Office and in case law. This aim is legitimate and still deserves to be pursued. At the same time it must be noted that the Advisory Committee has not been aware of any problems for the Dutch business sector as a result of non-harmonised practices in the various member states; in any event no cases have been brought before the Board of Appeal of the (former) Patents Council (Octrooiraad) since 1987.

To date, genuine court cases on the admissibility of software patents have never taken place in the Netherlands.

The discussion about the Directive, however, has become far removed from the original purpose and now concerns in particular the question whether patents may be granted on computer implemented inventions or on software and/or computer programmes. This discussion sometimes takes on a dogmatic character. The Advisory Committee believes that the Directive should not be used to pursue this discussion. The Advisory Committee is of the opinion that software should essentially not be treated differently to other forms of technology. At the most, the Directive may serve to clarify practice, but not to create a separate regime (sui generis) for software patents. This risk arises when the Directive incorporates too many elements that are alien to the general system of patenting.

Article 52 of the European Patent Convention (EPC) states that computer programmes are not patentable, but that this only applies to computer programmes as such. There is much discussion on the exact meaning of the term ‘computer programme as such’. The Directive attempts to clarify this distinction and to make a clear division between inventions that are patentable and those that are not on the basis of this distinction. The discussions in the European Parliament too usually concern the drawing of such a ‘red line’.

The Advisory Committee takes the view that it will not be possible to create such a dividing line between patentable and non-patentable computer programmes; and even if it were possible, the Advisory Committee does not feel it is desirable. As the examples under 1 show, an invention can often be implemented in both hardware and software. Inventions are also conceivable that in practice can only be implemented in software. The exclusion of these patents too would not seem to be opportune, if we consider the German ‘Logikverifikation’ decision.

The only conceivable clear boundary is either a full exclusion of computer programmes from patentability or allowing them all to be patented. The Advisory Committee is in favour of the latter approach. In that case the ‘normal’ criteria under patent law should be used to determine whether the invention is patentable.

This does not mean, however, that the Advisory Committee is in favour of unrestrained patenting of software inventions. The contrary is true! The Advisory Committee agrees with many of the criticisms of the current practice of granting software patents. The legitimacy of granting a patentable exclusive right is threatened when the quality and massiveness of patenting gets out of step too much with what is generally considered acceptable by society. Actually, this issue does not apply exclusively to the software domain, but does indeed play a particularly large role in this sector because (i) the effect of poor (trivial) patents affects large groups of users in the business community and society, (ii) developments in software are usually incremental and (iii) with software there is a very real risk that such patents will be unintentionally infringed upon.

The Advisory Committee shares the concerns raised by many parties in relation to the problem of software patents. However, many of these concerns, the Advisory Committee believes, are not directly related to the Directive, nor could they be solved in the Directive itself. Incidentally, for some of these problems it is not always clear whether they do actually occur to a large degree, or only exist in the perception of a large group of parties involved.

It has become clear to the Advisory Committee during its consultations that the major problems in current practice are:

• The fact that too many patents are granted on software inventions that, in the view of those in practice, make no or only a very limited contribution to the state of the art. The fact that many patents granted are not actually for new inventions, but that those assessing the patents lack sufficient knowledge of the ’prior art’ in order to determine this.

• The fact that patents on software and/or computer programmes do not properly meet the requirement under patent law of the scope for further development of the disclosure, as a result of which the contribution to the state of the art remains hidden, even to an expert, and compromises the principle of ‘quid pro quo’ that underlies patent law.

• The fact that patents are nevertheless granted on business methods.

• The fact that the trivial patents are misused and act as a deterrent and brake on innovation for many software designers.

• The fact that many standards used for interfaces are patented, which causes interoperability problems [#1].

• The fact that using existing opposition proceedings against dubious patents (patents that can be legally challenged) is costly, time-consuming and risky, as a result of which the small and medium-sized enterprises (SMEs) in particular are often forced to go along with such patents.

The Advisory Committee believes that these problems will be difficult to solve in the Directive.

Every attempt to define a desired quality level (the standard against which the level of invention is tested) in the Directive will lead to much discussion, and almost certainly generate dissatisfaction among proponents or opponents of software patents.

Safeguarding interoperability is extremely important for the information society [#2].

However, the interoperability problem is technically so complex that a scheme in the Directive will not be able to do justice to it, so that much discussion will persist in the future. Furthermore, interoperability involves many more aspects than merely those to do with patent law.

The Advisory Committee believes that the problems identified can indeed be tackled but must be properly addressed. The problem of the overly poor quality of patenting can better be solved in the context of the EPO or national patent offices. The problems of patent abuse and the interoperability problem can best be solved through competition or a policy for granting compulsory licences.

Lastly, the problem of the ‘business methods’ is difficult to pin down, because technical business methods do indeed exist. The Advisory Committee believes that, rationally speaking, there is no reason for a separate exclusion of business methods in a Directive in addition to the existing statutory exclusion of methods of doing business as such. If, in view of the broad objections to it, it is decided nevertheless to go down this route, naturally it must be made unequivocally clear what is meant by business methods.

In Appendix 1 to this advice, we set out a number of concrete proposals that may contribute to solving the various problems we have outlined above.

3. There then remains only a limited role for the Directive. In the Advisory Committee’s view, it is doubtful whether bringing about such a limited Directive does indeed have any added value. This feeling is reinforced if we consider the substantial amount of discussion generated by the Directive. Even the compromise between the Council and the European Parliament made necessary as a result of the co-decision procedure will not, in the Advisory Committee’s view, lead to a Directive that provides the desired clarity and balance which the Netherlands is aiming for.

The Advisory Committee therefore takes the view that in these circumstances the preferred option must be not to draw up a Directive. Although the argument for not continuing the process of drawing up the Directive would appear contrary to the Dutch view that has been pursued up to now, the Advisory Committee feels this not to be the case. In the declaration of voting at the time of developing the common opinion of the Council in March 2005, the Netherlands said that it would not agree to a Directive that did not find the right balance between that which is patentable and that which is not, bearing in mind a reasonable weighing up of the interests of companies that do and those that do not wish to make use of patents on software inventions. In the Advisory Committee’s opinion, the Directive will not be able to do this, reason why a rejection of the principle of a Directive can be justified.

We believe that such an approach will meet the approval of a significant number of both the proponents and opponents of the patentability of software-related inventions. If no Directive were to be drawn up, the current practice of patenting by the EPO will remain. The options for obtaining patent protection will not be abolished when no Directive is created. However, the current situation in practice, as already argued above, will have to be thoroughly analysed and offer a solution to the problems described.

Advice

The Advisory Committee advises the Netherlands to argue in Brussels for the (provisional) cessation of negotiations on the Directive. It will not be possible to formulate more workable definitions and lay down boundaries in the Directive that will lead to a reasonable definition of what is patentable and what is not in the area of computer-implemented inventions and computer programmes. No Directive text whatsoever is expected to do justice to the starting points contained in the Dutch declaration of voting.

The situation must be avoided where a Directive creates an independent patent regime for software inventions. The solutions must be found within the limits of current patent law. In combination with this, however, the Netherlands must work towards solving the triviality problem. The (perception of an) overly poor patent quality undermines the legitimacy of the patent system. Safeguarding and restoring patent quality is more important that aiming for harmonisation. In order to do this, the suggestions as contained in the appendix to this advice can be used.

The Netherlands must also work on solving problems of competition law in relation to patents on software, such as the interoperability problem. A separate solution at EU level to this complex issue needs to be found in the near future.

Only then, when a supporting policy (within a period anticipated to be between 3 and 5 years) such as the one proposed by us in Appendix 1 has led to a substantial improvement in the quality of patents on software-related inventions, should it be reviewed whether it is still necessary after all to formulate a Directive.

If this advice were to be unsuccessful within Europe, we nevertheless advise you to adopt a line that corresponds as much as possible with the advice. We set out some suggestions for this in Appendix 2.

Appendix 1

Proposals for a supporting policy

A. Proposals for improving patent quality

1) Involving the field better in seeking the state of the art

A frequently-voiced criticism of patenting practice for software patents is that patent organisations do not have a proper overview of the state of the art. This knowledge is usually available among the many software designers and academics, but is poorly documented and not readily accessible to the patent assessors. Some thought could be given to the procedures for using the knowledge potential in the field when establishing the state of the art, in order to prevent patents being granted for inventions that are not new (see also point 3).

2) Reviewing the standard for inventiveness

During its consultations the Advisory Committee has become aware that there is considerable public dissatisfaction on the quality of patents in general, and in the area of software in particular, in the sense that patents are felt to be granted on trivial or marginal inventions. The Advisory Committee recommends that the Netherlands uses its influence in the Administrative Council of the EPO in order to address this quality problem and to work towards increasing the quality of the patents granted, particularly in the case of software. This could be done by tightening up the standard for inventiveness.

3) Adding to and amending Article 115 on the EPC Procedure

Article 115 of the European Patent Convention (EPC) contains a procedure that allows third parties, after publication of a patent application but before the patent is granted, to submit comments to the EPO opposing the granting of the patent (e.g. by putting forward ‘prior art’). Limited use is made of this option in practice. Access to this procedure could be made easier and more attractive so that it would be used more often. An idea in this respect would be to oblige the patenting body (the EPO) to say what has been done with the information provided. The party submitting the information should also automatically be a party to potential appeal proceedings at no charge.

4) Setting up an (independent) opposition body at the EPO

The EPO has an appeals procedure which allows an appeal to be lodged against a patent that has been granted. This procedure, however, is hardly accessible to small entrepreneurs. Often they will not even know that a certain patent has been granted. Consideration must be given to the option of an independent opposition body in the proximity of the EPO, whose job it would be to ‘test’ patents in appeal proceedings.

B. Proposals for preventing interoperability obstacles produced by patents

5) Study into the use of competition law/compulsory licence policy to combat the misuse of power by patents on standards

Proper access to important standards for interfaces is extremely important for users and writers of software. The use of standards can, in practice, be limited by patents. The Advisory Committee believes that it is the task of the government to encourage the application of ‘open’ standards (e.g. through the government purchasing policy). If patents nevertheless do rest on standards, limiting access to them in an undesirable way, it must be examined whether competition law or a specific compulsory licence policy can offer a solution to this.

Appendix 2

Important points for the Netherlands if a Directive is implemented after all

If it proves impossible to have the Directive proposal withdrawn, efforts must be made to create a Directive that introduces as little as possible a separate patent regime for computer-implemented inventions, computer programmes and/or software inventions.

If the Directive still attempts to clarify such unclear concepts as ‘technical contribution’ or ‘computer programme as such’, the situation must be avoided where different definitions for them that are just as unclear in practice replace them. However, the Directive must refer to the problems in patenting practice that have been mentioned earlier in this advice, and also make clear that the member states will take action on this issue.

1. Patentability of ‘business methods’

Many patents that are considered trivial are related to business methods. Unlike American practice, we in Europe do not want business methods to be patentable. A frequently-heard criticism is that the Directive does not make clear what business methods are, and that it is not sufficiently clear that these cannot be patented. In addition, business methods are too often implemented after all through the back door (namely through computer implementation). If the Directive is to express a view on business methods, it must be clear what is meant by this and also that they are not patentable. The Directive should therefore contain an article that makes clear that business, administrative and government methods and procedures are not patentable.

2. The term ‘computer programme as such’

We have already mentioned in our advice that the confusion about the term ‘computer programme as such’ can best be removed by not referring to it at all from now on. The Directive should only make clear that computer programmes are only patentable if they constitute an invention.

3. An explanation of the limits of patentability of such things as business methods and algorithms

There is confusion about the scope of patents on things such as business methods and algorithms. It could therefore be considered adding an article to the Directive to make clear that business methods and algorithms are freely usable in applications other than those that have been patented.

4. Quality of the patenting procedure

The Directive must draw specific attention to the much-cited quality problem to do with granting patents.

5. Improved compliance with the requirement of scope for further development

In exchange for a temporary exclusive licence, a patent holder must publicise his invention so that third parties may build on his knowledge and ideas. It is therefore important for patent applications to make sufficiently clear what their contribution is to the state of the art. No patents may be granted for only half-developed ideas where a professional obtains insufficient insight into the technical contribution that has been made. This is a normal requirement in patent law.

Make sure in the Directive that if software is essential to the invention, this is publicised sufficiently [#3] (such as formal specification, design or source code) so that this can be developed further by an expert in the field. The Advisory Committee has become aware that this is often lacking in practice. Extreme examples are the ‘wish-list’ patents, which only specify the problem without providing any contribution to its potential realisation.

1 Contrary to other software, with standards for interfaces it is virtually impossible to develop alternative solutions with the same level of acceptance. At the same time, it is very tempting for the software industry to control standards (through patents or secrecy).

2 Hal L. Varian & Carl Shapiro, Information Rules, Harvard Business School Press, 1998

3 Comparable with the ‘best mode disclosure’ in Section 112 of the American Patents Act