Software methods

Software can be protected with patents.  The source code of the software is not protectable with patents (though it may be protectable with copyright), and neither is the object code or the machine language instructions.  The software methods – the functions and methods that the software carries out – and the computer system that is designed to operate the software and carry out those software methods, may be protectable with patents.  As with any invention, you must describe the functions of the invention – the uses of the invention are helpful and should be described, but it is the functions that can be patentable.  How do you write a patent application that will protect your innovations and help you to profit from your investment of time and money in developing your invention?

Disclosure of software methods

To protect software methods, you must describe the system and the software methods in enough detail, so that another person or company who knows what they’re doing in that field (in patent-speak, one who is “skilled in the art”) can read your patent application and build a computer program that carries out the methods you’ve described.  (See my blog post on the information needed for a patent application.)  This is the fundamental goal of the patent system: in order to “promote the progress of science and useful arts,” inventors are encouraged to disclose their inventions to the public (from the US Constitution patent and copyright clause).  In return, inventors get a limited monopoly, for a period of time (currently, 20 years) in which they control the right to use their invention – and with our first-to-file system, inventors should file as promptly as they can (when you apply, be sure to get inventorship correct).  Bear in mind that the strategies outlined here are subject to change, as the law and practices around protection of inventions changes.

How to protect software methods

In the context of software methods, this does not require writing or disclosing any computer code – if you’ve written it, you can disclose it in the patent application, and it can strengthen your patent application, but it is not required.  The required disclosure does not necessarily include a user’s experience of using the software, such as seeing or benefiting from certain functions of the software.  Instead, the patent applicant must disclose the software methods that are carried out by a system built to carry out the methods, and must describe this from the perspective of the computer system.  But that is not the only perspective on the software methods that one should include in a patent application to protect a computer-implemented invention.

Describe a software method from three perspectives

A software method should be described in a patent application from at least three perspectives: as the computer system carrying out the method sees it, as a user – or the user’s computer device – sees the method, and as a third party sees the method.  There are three main reasons to do this.

The perspectives are different

First, the methods are different from each perspective, as each of those perspectives presents different views of the functions of the invention – of what is happening.  The system’s perspective is where most of the data processing and manipulation will take place.  The user device’s perspective is helpful for reference and to give context to the invention, and in some cases will involve inventive elements that we can try to protect.  The third-party perspective can capture the sum total of data flows and interaction, but cannot see the processing that is happening in either the system or the user device.  Each of those perspectives on the software methods can have patentable elements.

The relevant claims cover different implementations of the invention

Second, patenting different perspectives on the software methods gives you the chance to protect your innovations and investment – by blocking different ways that future competitors may try to work around your patent protection.  The goal in any patent application is to protect your invention and investment of time and money, as well as the opportunity cost represented by your research and development.  Describing and protecting multiple perspectives is part of this strategy.

Future-proof your patent application

Third, the standards and requirements for computer-implemented inventions, and for other types of inventions, can change.  When they change, any patent application (that is still being examined) or issued patent is judged by the new standards, not by the standards that existed when the patent application was written, filed, and prosecuted (see my post on patent prosecution).  No strategy can fully future-proof a patent application.  But, by describing these perspectives on the methods carried out by the invention, you describe the functions in different ways and improve your ability to maintain patent protection into the future.

Describe the system that implements the software methods

You must also describe the system that is built to carry out the functions of the software methods.  The system has tangible components: what are they?  Describe the processors, data storage units, databases, memory modules, input/output ports, radio communications modules, interfaces, displays, and more, that comprise the physical system that carries out the functions of your invention.  Our description of the invention will tie the physical system together with the software methods.

Describe instructions for the software methods

The software methods are encoded by computer-readable instructions.  We describe these too, to try to protect your invention in another way, and to try to block competitors from working around your patent claims.  As described above, the computer code you write is not patentable as code – copyright may be able to offer effective protection, though of course you’d need to pursue that in each programming language that is important to your business, or to your competitors – and to do that, you’d need to write the program in each language, which is a daunting task.  But a description of the code, and claims to it, offer you some protection for the way the instructions for carrying out the methods are used in the inventive system.

Present patent illustrations of the software methods and system

Of course, we must present patent illustrations.  For software methods, this means flow-charts: a high-level chart presenting software “modules” and detailed charts of each module, and each method, from as many perspectives as necessary.  We also present patent illustrations to show the system that carries out the invention.

Please note that the staged provisional patent application strategy I’ve described in a post is difficult to implement with the multiple perspectives for a patent on software methods. The additional complexity and length required to describe a software invention from multiple perspectives increases the cost of preparing a patent application.

Write claims to the method perspectives, system, and instructions

When we write claims to a computer-implemented software method invention, we write claims for the system (the computer and computer components), possibly to the apparatus (the system plus software), the software methods (from three perspectives), and the instructions for the methods.  This can quickly drive up the number of claims in a patent application for a software invention.  A sample outline of claims may look like this:

• I1: A method for [function of invention], from the perspective of the system, where the method is A, B, C, …
  • D1: I1, plus method is step D
  • D2: I1, plus method is step E
  • D3: D1, plus method is step F
• I2: A method for [function of invention], from the perspective of [a user device interacting with the system], where the method is B’, C’, D’, …
  • D1: I2, plus method is step E’
  • D2: I2, plus method is step F’
• I3: A method for [function of invention], from the perspective of a third party observing the system and [a user device], where the method is A”, B”, C” …
  • D1: I1, plus method is step D”
  • D2: I1, plus method is step E”
  • D3: D1, plus method is step F”
• I4: A system configured to [carry out function of invention], comprising a server, processors, memory, databases, I/O, etc.
  • D1: System, plus…
• I5: Non-transitory computer readable memory medium and computer controlling instructions stored on the non-transitory computer readable memory medium, [for function of invention]

Lawyerly disclaimer: be aware that this is provided as an example of an outline of claims; it is greatly abbreviated, and not in a form to be used in a patent application.  All of the discussion above sets out a possible strategy, which may not be warranted in a particular case.  Laws change, as do patent examination guidelines, and strategies may change at any time.  As with any invention, be cautious and aware of any public disclosures of the content of the invention.

Do you have questions?

Ready to start protecting your software invention?  Call me at 617-340-9295 or email me at my Contact Me page.  Or, find me on Facebook, Twitter, Google+, LinkedIn, Google Local, or Avvo.  Wondering why the image with this post is a toy elephant from US D356350S?  The description of software methods from multiple perspectives reminds me of the parable of blind men encountering an elephant for the first time, and describing it to each other.  While the analogy is not perfect for the perspectives in a patent, the way that each person’s perspective correctly describes a view of the whole, and that all the perspectives are necessary to fully describe the whole, strike me as a good analogy for the need to describe a software method from multiple perspectives.