Patenting computer programme algorithms


Products in the field of information technologies (hereinafter - IT) generally contain several components, the legal protection of which is realised in different ways.

Architecture, algorithmic solution, hardware part of an IT product and graphical part of the user interface are protected as objects of patent law.

The peculiarities of patenting architectural and hardware solutions are worthy of a separate discussion and therefore are not considered here.

The code of computer programmes implementing the algorithm and user interface is registered as an object of copyright (i.e. as a literary work); accordingly, only the textual form is protected, not the algorithm. The graphical part of the user interface may be patented as an industrial design. At the same time, registration of computer programme code and patenting of the graphical part of the user interface may be considered rather as an auxiliary tool to ensure legal protection in the IT industry.

The most reliable and therefore the main mechanism for protecting the interests of a software developer is patenting algorithms of computer programmes as inventions.


Patentability in principle

There are fundamental restrictions on the patentability of inventions. They are generally similar in different jurisdictions, although there may be differences, which, in most cases, are cosmetic in nature.

According to Clause 1 of Article 1350 of the Civil Code of the Russian Federation, a technical solution in any field relating to a process characterised as a process of performing actions on a material object with the help of material means shall be protected as an invention among other objects.

According to Article 1350(5) of the Civil Code of the Russian Federation, mathematical methods, rules and methods of games, intellectual or economic activities, as well as solutions consisting only in the presentation of information are not inventions, while the possibility of classifying these objects as inventions is excluded only when the application for a patent relates to these objects as such.

In Russia, for example, the role-playing part of a computer game algorithm (gameplay), the mathematical part of an algorithm for processing information without reference to tangible objects, or a new method of accounting are not patentable as inventions.

In the US, some of these solutions may be patentable as covered-business-methods, but the practice of patenting such solutions is unstable.
Nevertheless, any jurisdiction may recognise as inventions algorithms for compressing or encrypting information for storage on a storage medium or for transmission in a communication channel, multi-factor authorisation algorithms, server load balancing algorithms, image recognition algorithms, etc.


Algorithm descriptions

In order to ensure adequate scope of protection of the invention and sufficient resistance of the patent to invalidation, it is important to properly draft the description of the algorithm in order, on the one hand, to fulfil the requirement to have in the application a description of the invention disclosing its essence with completeness sufficient for a person skilled in the art to carry out the invention (Article 1375(2) of the Civil Code of the Russian Federation in Russia; Article 83 EPC in Europe; 35 U.S.C. 112(a) in the United States) and, on the other hand, not to suggest to potential competitors ways of circumventing the patent.

In addition, where necessary, the description should provide a basis for adding features to the claims during examination or patent litigation.

The description of the invention should clearly follow the logical chain "purpose of the invention - features of the invention - technical result", i.e. the relationship of the technical result to the features of the invention (at least those features contained in the claims) should be demonstrated.

In contrast to mechanical constructions, in "computer-implemented methods" this relationship may not be obvious in itself, and it should be explicitly stated in the description.

The technical result must be of a technical nature and must be formulated in a form that can be measured or directly observed.

The concept of "advantageous effect" of an invention (advantageous effect), which is characteristic of some jurisdictions, does not quite coincide with the concept of "technical result". In particular, a reduction in the price of a product (good or service), an increase in usability, an improvement in appearance, etc., may constitute an "advantageous effect" but would not be recognised as a technical result.

Where the claims use a "broad" formulation, for example, a means plus function, the description should contain sufficient examples of practical realisation of the function to justify the use of such a formulation. Lack of specificity can lead both to complications at the examination stage and to a reduced chance of the patent surviving an attempt to invalidate it (Bilski vs. Kappos, 2010; Alice Corp. vs. CLS Bank International, 2014, etc.) [1].

If a range of numerical values of parameters is used in the claims, the description should contain a sufficient number of examples or theoretical justifications confirming the achievement of the claimed technical result in the entire range.

At the same time, often all that can be obtained from the developer of a programme as a source material for drafting a patent application is an incomplete block diagram of the algorithm, a listing of the code of this programme and confusing explanations like "read here, don't read here, here is a stub, and here and there are crutches, don't look at them either".

That is why it is important for the drafter of a patent application for an algorithm to penetrate into the essence of the algorithmic solution being patented and to present it competently, translating functions and operators of the programming language into technical and mathematical language and supplementing the description of the invention with possible variants of its practical implementation, which developers usually do not have time to think over or consider this work beneath their dignity.

Example: a fragment of real code in the C++ programming language and a fragment of the description of the invention based on it


https://habrastorage.org/r/w1560/webt/xm/7i/al/xm7ialt0ca1oxcrjkwtl-rd79qm.png


Graphical illustrations of algorithms

Algorithm flowcharts are most often used as graphical illustrations of computer programme algorithms.

When preparing figures containing algorithm flowcharts, it is advisable to follow one of the most common systems of graphic symbols - GOST 19.701-90 (ISO 5807:1985) [2] or the unified modelling language UML [3].

Alternative ways of algorithms visualisation, e.g. visual language DRAGON, pseudocode, Nassy-Schneiderman diagrams, etc., are also applicable, but they are less convenient for this purpose due to their limited familiarity.

Example of a block diagram of an algorithm according to GOST 19.701-90


https://habrastorage.org/r/w1560/webt/pw/9i/6c/pw9i6cz3yj-xgd1ehgubhf7vege.png


Complex algorithms with a high level of detail usually cannot fit on one A4 sheet in compliance with the requirements for patent application drawings. Therefore, they are presented on several sheets - either using the principle of cascading decomposition, when the first sheet contains the top-level block diagram, and the subsequent sheets contain block diagrams that reveal the composition of blocks from the first sheet, or immediately in a detailed form with the use of connectors, allowing the scheme, started on one sheet, to continue on subsequent sheets. It is possible to combine these two methods.

Example of the use of connectors

https://habrastorage.org/webt/a5/y-/pr/a5y-priuy2actc_oaomgkp6oy-e.gif


Some types of algorithms, mainly related to telecommunications, can be successfully visualised using message flow diagrams.

Example of a message flow diagram

https://habrastorage.org/r/w1560/webt/et/4y/88/et4y88aiyabsf6jjp2jney0ugvq.png


Other types of algorithms, such as those related to so-called "business methods", are conveniently illustrated using diagrams of the IDEF family.

Example of an IDEF0 diagram

https://habrastorage.org/r/w1560/webt/eq/he/4q/eqhe4qtapeokl3qn7sae6whzrmo.png


Claims for algorithms

It is appropriate to select a method as the generic term for claims relating to computer programme algorithms. The selection of a device (a computing device that executes a program or a memory device that stores a program) as the generic term is only applicable in additional independent claims, and not in all jurisdictions.

In particular, in the USA, characterisation of a device by process features may lead to patent revocation (HTC Corp. vs. IPCom GMBH & Co., KG, 2010) [4].

An independent claim should contain a characterisation of the purpose of the invention and the features of the invention that ensure the achievement of the technical result indicated in the description. At the same time, the use of a "broad" formulation of means plus function for a single distinctive feature in the claims may also lead to the cancellation of the patent in the USA (In re Hyatt, 1983) [5].

Usually, "computer methods" are patented in several countries which are the target markets for the products protected by the patent. When drafting the claims of such patent applications, it is advisable to be guided not by the Russian criteria of unity of invention, but by the unity criteria adopted in these countries, or by the unity criteria under the PCT (Patent Cooperation Treaty), if patenting is planned on the basis of an international application.

The claim shall be drafted using speech constructions traditional for patenting methods: in Russian - elliptical verbal turns in the third person plural (transmitting, receiving, processing, calculating, comparing, deciding), in English - impersonal gerundial turns (transmitting, receiving, processing, comparing, judging).


Example of wording of a dependent claim

The method according to claim 27, characterised in that the refining of the value of at least one of pitch, roll and yaw angles comprises the following steps:

(b1) initialise a numerical array and a variable;
(b2) read the magnetometer, accelerometer, and gyroscope;
(b3) calculate the pitch, roll and yaw angles and rotational velocity of the first terminator;
(b4) calculate a difference between a value of at least one of the pitch, roll and yaw angles calculated from the magnetometer readings and a value of the same angle calculated from the gyroscope readings; ....

IT invention claims sometimes include media containing programme code implementing an algorithm according to the invention. The popularity of such claims has been declining in recent years, but if an applicant insists on including such a claim, it should be borne in mind that in some jurisdictions (most notably the US) the medium must be represented in the application as a non-transitory computer readable medium, as opposed to electrical and electromagnetic signals in communication channels, acoustic signals and other wave effects.

The appearance of this term is connected with the so-called "35 U.S.C. §101 rejection problem" - frequent rejections in the USA of applications containing the "computer readable medium" feature in the claims without specifying its physical nature.


Disclaimers and spellings

In patent applications for computer programme algorithms, it is reasonable to use remarks (disclaimers) regarding the sequence of steps of the algorithm, for example, of the form:
...the sequence of steps in the description of the method is illustrative and in various embodiments of the invention this sequence may differ from that described, provided that the function performed and the result achieved are preserved.

In software and hardware patent applications, it is also possible to use disclaimers regarding the combination of features relating to software and to hardware solutions, for example of the kind:
...the devices and parts thereof referred to in the description constitute hardware and software, wherein the hardware parts of some devices may differ from, partially overlap with, or completely coincide with the hardware parts of other devices, unless otherwise expressly stated;
...hardware parts of devices may be located in different parts of other devices, unless explicitly stated otherwise;
...software modules may be implemented as programme code contained in a memory device.


In addition, in patent applications intended for foreign patenting, primarily in the countries of the British or American patent tradition, it is advisable to apply specific wording of disclaimers and other legal incantations, which often look bizarre or meaningless in the Russian legal field with its directive effect of patent law norms, but are traditionally used in these countries. This applies, for example, to remarks of the type:
...document so-and-so, the entire contents of which are incorporated herein by reference;
...the examples given do not limit the scope of the claimed invention;
... a reference in the description to a prior art publication does not constitute an admission that the publication is part of the common knowledge of the art.

Despite advances in the harmonisation of patent laws in leading industrial countries, a number of jurisdictions continue to have rudimentary traditions inherited from the eighteenth and nineteenth centuries.

In addition, some of these traditions may be related to the case law of the jurisdictions concerned, while others may be due to local law enforcement practices and should be taken into account when drafting patent applications.


Conclusion

Patenting computer software algorithms requires special qualifications and thoroughness from the drafter of the application. In addition, with respect to applications intended for foreign patenting, it is necessary to take into account patent traditions and law enforcement trends in the jurisdictions of the main markets for high-tech products, primarily the United States and Europe.

Since foreign court practice in relation to "computer methods" changes frequently and sometimes radically, the main trends should be constantly monitored and, if possible, taken into account when drafting applications.

For the USA, for example, it is convenient to use a regularly updated encyclopaedia on patent claims drafting [5], for European countries - a periodic review of patent litigation practice [6].



Literature

1. P. Andrew Riley, Jonathan R.K. Stroud, and Jeffrey Totten. The Surprising Breadth of Post-Grant Review for Covered-Business-Method Patents: A New Way to Challenge Patent. - The Columbia Science & Technology Law Review, Vol. XV, Spring 2014, pages 235-292.
2. GOST 19.701-90 Unified System of Programme Documentation. Schemes of algorithms, programmes, data and systems. Conventional designations and rules of execution. - Moscow: Standards Publishing House, 1991.
3. Grady Buch, James Rambo, Ivar Jacobson. The UML language. User's Guide. Second edition. - Moscow: DMK Press, 2007.
4. Bradley C. Wright. Functional Claiming and Functional Disclosure. Presented: 6th Annual Advanced Patent Law Institute, January 20-21, 2011, Alexandria, VA.
5. Robert C. Faber. Faber on Mechanics of Patent Claim Drafting - Seventh Edition (Release #3, November 2016). - New York: Practising Law Institute, 2016.
6. Patent Litigation in Europe. An overview of national law and practice in the EPC contracting states - Fourth Edition. - European Patent Academy, EPO, 2016.

This publication uses the materials of the presentation made by the author at the patent conference "St. Petersburg Peer Readings - 2018" 27 June 2018. The report was addressed to patent specialists, most of them far from IT technologies, so some information from the publication may seem common knowledge and obvious to the readers of Habra. The author encourages readers to take it with understanding.

@ https://habr.com/ru/articles/415789/