How To Draft a Software Application

I. TIPS ON DRAFTING THE CLAIMS

Draft the claims first. That is what many experienced patent attorneys advise. There is good reason for this. The claims define the metes and bounds of the invention. The claims put the invention into with the . The claims are the words that the patent examiner spends most time review- ing, and the claims are the instrument construed by the court in litigation. The claims are important and should therefore be given primary attention. Starting with the claims helps you focus on the invention. There are those who prefer to draft the specification first, and then draft the claims. They will tell you that writing the specification first helps them figure out what the invention is. There is nothing fundamentally wrong with this approach, but it can be considerably less efficient. Consider this analogy: Before painting his famous mural on the ceiling of the Sistine Chapel, Michelangelo undoubtedly made sketches. Edgar Degas did this also, before he rendered his impressionistic pastels for which he is famous. Indeed, most artists make sketches and studies before undertaking a major work. (There are always exceptions, like artist Jackson Pollock, who exploited chaos and randomness in his swirling drip paintings. Pollock spread his canvas on the floor and spilled paint on it. He then selected and framed the good parts.) drafting is an art form, more constrained than painting, but nevertheless an art form. It is quite natural to make sketches or studies of important inventive aspects before undertaking the patent application in earn- est. Those who draft the specification first are actually making written sketches or studies in an effort to find the invention. Thus, whether you draft the claims first, as advocated here, or draft the specification first, treat early efforts as sketches or studies and be prepared to throw them away, just as the artist makes a sketch, learns from it and then discards it. That is why it is more efficient to draft the claims first. Claims comprise

SPW (November 2007) 2 – HOW TO DRAFT Software Worldwide fewer words; it is easy to draft a claim, study it and discard it in favour of a better claim. It is much harder to draft a complete specification and then discard it, after learning that you missed the invention. So many pages of effort go into drafting the specification, that many drafters are strongly tempted to keep the specification that has been drafted, even though it may not focus precisely on the claimed invention. There is no one proper way to express the metes and bounds of an inven- tion. An invention is not one-dimensional. It is a multidimensional-like sculp- ture. There is no one vantage point from which to look at an invention. There are many. Claims should be drafted to describe the invention from several different vantage points, thereby capturing a better image of the multidimen- sional nature of the invention.

A. LEGAL REQUIREMENTS FOR CLAIMS

Patent claims are the most focused upon part of the patent, because the patent claims define the metes and bounds of the patent grant. In both patent pro- secution in the Patent Office and patent litigation in the courts, the claims are of paramount importance. Therefore, as a patent practitioner, give a great deal of thought to the drafting of claims.

1. United States

Patent claims were not always this important. In the United States, for example, one hundred years ago the metes and bounds of the patent grant were defined by the specification. In those days, the might simply state omnibus claim language such as: ‘I claim the invention as sub- stantially shown and described.’ Do not try to get an omnibus claim like the above allowed today. United States patent examiners are trained to reject the omnibus claim as nonstatutory under 35 U.S.C. § 112.1 The exception to this prohibition is design patents. Design patent claims are directed to the orna- mental appearance of a design as shown in the patent drawings. Thus claims in design patents can and should state: ‘The ornamental design, as shown and described.’

2. Japan

In Japan, since claims determine the scope of protection for the patent owner, the patent practitioner must draft claims very carefully. Omnibus claims are not allowed in Japan. Under Article 36(5) of the , a claim

1. US Dep’t of Commerce, Manual of Pat. Examining Proc. § 706.03(h) (5th edn, March 1994).

SPW (November 2007) Software Patents Worldwide HOW TO DRAFT – 3 must recite all matter necessary for specifying the invention for which the patent applicant intends to receive a patent. The patent applicant must decide what type of invention he or she wishes to receive a patent for. In addition, the patent applicant is responsible for deciding what matter is described in order to specify the invention.

3. Europe

In Europe, due to the fact that computer programs, as such, are not patentable, a claim may be refused if the sole subject matter is a computer program. This is so even where the programme is claimed in the form of a record on a computer-readable medium, or even where the claim is to a machine, such as a computer, characterized solely by the computer program. Nevertheless, there are ways to address this difficulty. The French Patent Office, for example, will permit software inventions if claimed thusly: Computer programme product, comprising programme code instruc- tions recorded on a medium readable by a computer, comprising computer readable programmatic means for performing the steps of ... when said programme is running on a computer. Moreover, the following types of claims are generally permitted in Europe: – claims relating to machines controlled by a computer program, to the extent that such claims relate to the technical characteristics of the machine; – claims relating to the software-controlled internal functioning of a known computer, if it produces a technical effect (such as expanding the virtual working memory); – claims relating to processes used for industrial purposes, which include states controlled by computer programs. The corresponding provision for claims in the European Patent Convention (EPC) is that the claims shall define the matter for which protection is sought in terms of the technical features of the invention. Wherever appropriate, claims shall contain a statement indicating the designation of the subject- matter of the invention and those technical features which are necessary for the definition of the claimed subject-matter but which, in combination, are part of the prior art, a characterizing portion preceded by the expression ‘characterized in that’ or ‘characterized by’ – stating the technical features which, in combination with the pre characterizing features it is desired to protect. Whilst UK national practice does not require two part form for the claims, in the majority of cases, European (UK) patents arising out of the European patent convention will have two part form, and both types of claim are acceptable under UK practice.

SPW (November 2007) 4 – HOW TO DRAFT Software Patents Worldwide

Claims in European format which specify the features found in the prior art alone or in combination in a ‘pre-characterizing’ portion followed by the words ‘characterized in that’ or ‘characterized by’, and then followed by technical features which are not found in the prior art, are allowable, but not obligatory. Under EPC rules, an application may contain more than one independent claim in the same category (product, process, apparatus or use) only if the subject-matter of the application involves a plurality of inter-related pro- ducts, different uses of a product or apparatus, or alternative solutions to a particular problem, where it is not appropriate to cover these alternatives by a single claim. Dependent claims are permitted. Any claim stating the essential features of an invention may be followed by one or more claims concerning particular embodiments of that invention. Any claim which includes all the features of any other claim (dependent claim) shall contain, if possible at the beginning, a reference to the other claim and then state the additional features which it is desired to protect. A dependent claim shall also be admissible where the claim it directly refers to is itself a dependent claim. All dependent claims referring back to a single previous claim, and all dependent claims referring back to several previous claims, shall be grouped together to the extent and in the most appropriate way possible. The number of the claims shall be reasonable in consideration of the nature of the invention claimed. Claims shall not, except where absolutely necessary, rely, in respect of the technical features of the invention, on references to the description or draw- ings. In particular, they shall not rely on such references as: ‘as described in part ... of the description’, or ‘as illustrated in figure ... of the drawings’. For patents originating before the European Office, these already contain reference numerals and the UK office will not raise an objection to them remaining in the granted patent. Reference signs shall not be construed as limiting the claim in any subsequent proceedings. For applications processed via the UK national office, reference numerals in the claims may be objected to and require deletion. Different categories of claims within the same inventive concept are allow- able, such as product claims, process claims, product of process, and appa- ratus for performing a process; however, if the technical features of the independent claims do not mirror each other closely, then objection may be raised based on lack of . This is particularly common where US-style claims are filed without amendment on entry into the UK. The deficiencies can often be remedied during prosecution by consolidation into a single claims set for product/ apparatus and process. For system inventions having ‘send’ and ‘receive’ elements such as a transmitter and receiver, independent claims to these components can

SPW (November 2007) Software Patents Worldwide HOW TO DRAFT – 5 often be included in addition to an overall system claim without violating unity of invention, provided each independent claim contains the inventive step, and has a major proportion of technical features in common. Similarly, for computer program inventions, if the basic invention is found patentable, then the inclusion of carrier claims, of the form ‘A data carrier comprising programme code instructions for ... [features as for main independent process or product claim]’ will not be allowed as part of the same inventive concept. The same thing often applies for data transmission claims of the form ‘Electronic signals comprising programme code instructions for [technical features of the main independent product or process claim]’. Claims of the ‘omnibus’ type according to traditional UK practice in the form ‘The [product/ process] as hereinbefore described (with reference to the accompanying drawings)’, the latter phrase applying where the specification contains drawings, will generally not be objected to, and although adding little to the document, have few if any disadvantages to their inclusion. There are no specific claims fees, although when presented with large num- bers of claims, often the examiners will find objections, such as clarity or unity of invention, the latter objection being raised where there are multiple independent claims of similar or overlapping scope in the same category. There is no specific requirement for physical features in the claims, although claims lacking any physical aspects are more likely to draw objec- tions as being ‘non technical’ features, and require amendment before grant. The specified minimum number of claims is one, according to Section 14(5). Applications having no claims at all will fail the basic requirement under Section 14(5), and will be rejected. However, above one, there is no statutory minimum number of claims. In practice, however, most applications will have at least ten claims at the time of filing, and many applications will have in excess of 20 claims at the point of filing. The maximum number of claims is dictated by the requirement that the claims are concise, but this is a relative requirement, and varies depending on the subject matter at the dis- cretion of the examiner. Typically, applications containing over 100 claims may attract objections that the claims are not concise and require either a divisional application being filed, dividing the claims between more than one application, or some consolidation of claims being carried out.

B. FINDING THE INVENTION

How do you go about finding the invention? Begin by assessing what are the commercially important features. What are the features that will motivate purchasers of a product to select the invention over the prior art? Having these features in mind while drafting will help keep the claim focused on what the wants his or her patent to cover.

SPW (November 2007) 6 – HOW TO DRAFT Software Patents Worldwide

Next, identify the essential claim elements that are required to make the invention. Often you can identify the essential claim elements by studying the component parts (or subassemblies of component parts) found in the inven- tor’s preferred embodiment. Then identify those parts that are essential to the operation of the invention. In this endeavor, software inventions and hard- ware inventions are no different. Each can be broken down into component parts or modules or into subassemblies or submodules. The objective is to identify the essential component parts. Sifting through all the component parts, the essential ones are often those that make the commercially important features possible, or those that a competitor must employ to compete. Having identified the essential component parts, devise claim element abstractions to represent the essential component parts. These abstractions are the essential claim elements that are required to make the invention, and that will ultimately become the elements of the claim you are drafting. An essential component part and an essential claim element seem quite similar. Is there a difference? The answer is yes. The component part iden- tifies part of the inventor’s implementation or physical embodiment of the invention. The claim element more broadly identifies a class of component parts capable of making the invention. Object-oriented software developers use a similar notion to write software. They model a solution to the problem to be solved, first by identifying classes of objects they believe are needed to solve the problem, and second by selecting specific objects from these classes to build the actual software embodiment. The specific objects selected are called ‘instances’ of the class and the act of selecting such objects is called ‘instantiation’. Knowing this terminology and the analogy between claim drafting and object-oriented software development may help if you are working with an inventor who is familiar with object-oriented programming. If you are fortunate, you may find that the software invention was developed using object-oriented techniques, in which case, there may be good design docu- mentation that will virtually track the claim drafting process, step by step. Having identified the essential claim elements, or at least those which at this stage you believe are essential, the next step is to identify the relation- ships between these elements. Often one element will be functionally ‘connected’ to one or more other elements. The connection may be a direct or indirect physical attachment connection, for example, element A may be ‘coupled to’ element B. The connection may be an information flow con- nection, such as, element A may ‘supply data (numbers, values, and so forth) to’ element B; or element A may ‘supply a physical signal’ to B. There are no doubt many other types of connections. No element exists without some relationship to at least one other element. In your analysis, if an element floats alone, unconnected by any relationship with the other elements, chances are the floating element is not essential and should

SPW (November 2007) Software Patents Worldwide HOW TO DRAFT – 7 be discarded. If discarding the floating element destroys your perception of the essence of the invention, then put the element back in, and work harder at a deeper understanding of how that element is related to the other elements. A deeper understanding of the elusive relationship will often reward you with new insights and a new vantage point from which to see the invention.

C. WORKING WITH CLAIM

In identifying the essential claim elements and the relationship between those elements, it is helpful to make diagrams. These diagrams are similar to the diagrams that patent examiners make from the claims in preparation for searching the prior art. System engineers use a known as the entity relationship diagram (ERD), which can be employed to diagram claims. The diagramming technique is quite simple. Draw a circle (or any preferred shape) for each essential element. Label the inside of the circle with a broad or generic term that aptly describes that element. Next, draw connect- ing lines between elements that are related in a way that is important to the invention. Place labels adjacent or on the lines to describe the nature of the particular relationship. That is essentially it, although there is a little extra detail that you may want to add to the diagram, if desired. When appropriate, add arrowheads to the relationship lines, to show the direction of data flow or to show a dominant-subservient relationship. A claim element modifier (such as an adjective or a participle phrase), not important enough to be represented as an element itself, can be shown as an unterminated, cat whisker line originating from the element it modifies. Figure 1, on page 8, shows a sample claim diagram. The claim corresponding to this diagram is taken from claim 1 of US Patent 5,233,685, originally assigned to WordPerfect Corporation. The diagram does several things. First, it serves as a shorthand notation for your thoughts. It is quicker to draw a diagram than it is to draft prototype claim language. The diagram allows you to think about claim elements and relationships, without worrying about what words to use. Second, the dia- gram helps identify nonessential elements and limitations, and elements that are floating – unrelated to the rest of the claim. Finally, the diagram is easy to comprehend at a glance, hence you can set it aside and forget about it, and then later pick it up and be instantly reminded of your claim drafting thoughts.

D. WORKING WITH INVENTOR’S DRAWINGS

Many times a claim diagram can be extracted from one of the inventor’s drawings or from one of the patent drawings. This stands to reason, a drawing

SPW (November 2007) O ODRAFT TO HOW – 8 P Nvme 2007) (November SPW

Operator

Input iue1 apeCamDiagram Claim Sample 1: Figure

Characters Text Mode Selected

Font Coupled Graphics Selection Processor to Printer Mode Rules

Associated with

First Data otaePtnsWorldwide Patents Software Storage Memory stores text mode font definitions

Identifying characters having text mode font definitions in... Software Patents Worldwide HOW TO DRAFT – 9 of a preferred embodiment of the invention would be expected to show all of the essential claim elements. However, drafting a claim to show every component of the preferred embodiment usually yields a narrow ‘picture claim’. Thus the inventor’s drawing or the patent drawing should not be thoughtlessly used as a claim diagram. Rather, starting with the inventor’s drawing or the patent drawing, try to group together certain component parts that provide a common function. Draw a box around these component parts and label the box to denote the common function. Do this for the other component parts as well. For example, if the software embodiment has several data structures and processes pertaining to data acquisition, group these data structures and processes together under the heading ‘data acquisition system’, for example. Similarly, if there are several data structures and processes for supplying input and output to the user, these may be grouped together under the heading ‘user interface’. In grouping together functionally related component parts, keep in mind that not all groupings necessarily represent essential claim elements. In the above examples, it may well be that the ‘data acquisition mechanism’ and the ‘user interface’, while required for a working product, are not essential ele- ments of the invention.

E. WORKING WITH SOURCE CODE

With software inventions, sometimes the inventor will have no drawings, only source code. When confronted with this situation, you may have to ‘reverse engineer’ the source code to produce the claim diagram. Ideally you should do this with the inventor’s help, because deciphering someone else’s source code is a very time-consuming task. In reverse engineering the source code, do essentially the same thing you would do if supplied with drawings. Identify the data structures, processes, subroutines, procedures, and modules that have a common purpose or function and then draw an appropriately labelled box to represent these component parts. Often it can be helpful to start by identifying all component parts that make up the user interface (that through which the user supplies input to the programme and through which the programme replies to the user), and by identifying all component parts that make up the operating system interface (that through which the programme attaches to and invokes services of the operating system, for example, disk storage, file management, keyboard, and mouse support). These two interfaces are frequently not essential elements of the invention, yet they are nearly always present in a working software product. By identifying and separating out these two inter- faces, it is easier to examine what remains for elements that are essential to the invention.

SPW (November 2007) 10 – HOW TO DRAFT Software Patents Worldwide

F. TESTING CLAIMS FOR PROPER SCOPE

Having identified the essential elements, and having found the relationships between these elements, the next step is to test the model claim to see if it is of proper scope. Do this by testing the claim to determine if there are any undue limitations, and also to make sure the model claim does not read on the prior art. At this stage, it is not necessary to reduce the model claim to writing. The claim diagram alone will suffice. Begin by identifying which claim elements are themselves new. Also identify if any of the relationships between elements are new. Often, none of the elements alone will be new, but the combination of elements and their relationship is new. By identifying which elements and relationships are new, you begin to focus on the essence of the invention. If you find that you have included several elements that are not new, then possibly these old elements should be lumped together under a collective or generic name. Doing this helps avoid unnecessary limitations. What if none of the elements themselves are new, and none of the relation- ships are new either? This means you have not yet found the invention; it is hiding. In identifying the essential elements at the outset, you may have chosen element names that are now hiding the invention. Try to determine which element or elements contain the new or inventive matter. Then, break these elements into two or more component elements, and define the relation- ships between them, so that the invention is no longer hidden. The model testing process takes an iterative hierarchical approach. Combine multiple related old elements into a more generic single element; break apart new and inventive matter into more specific, separate elements. In the end you have a model claim, in diagram form, which shows quite clearly what is new.

G. CHECKING CLAIMS AGAINST PRIOR ART

It is usually a good idea to further test the model by attempting to read the model, as a whole, upon the known prior art. Take the known prior art, such as the inventor’s own prior art product, or a competitor’s prior art product, or the prior art patents developed during a search, and see if each and every element of your model claim is found in a single prior art device or reference. If so, then an assumption made while preparing the model claim is incorrect. The elements identified as new are not new. Do not despair. It is better to know that the claim is not of proper scope now, (before you file the application) while it can be corrected without a costly amendment responding to a Patent Office rejection. Try to identify how the invention differs from the prior art and add at least one claim element or limitation that will highlight the difference.

SPW (November 2007) Software Patents Worldwide HOW TO DRAFT – 11

If it is not apparent what element to add, try to determine what makes the invention better than the prior art. For example, the invention may operate more efficiently than the prior art; the invention may have features that the prior art does not have; the invention may be easier and less expensive to manufacture; or the invention may be easier to use. Once you have deter- mined how the invention differs from or improves upon the prior art, devise a claim element or combination of elements that are necessary to affect this difference or improvement.

H. DESIGNING AROUND CLAIMS

Claim drafting is an iterative art. Therefore, after adding the necessary claim elements to distinguish the invention from the prior art, go back and test the remaining elements to see if there are any that are unnecessary. One good way to test for unnecessary limitations is to pretend to be a competitor trying to design around the claim. Are there any elements that can be eliminated? If so, revise the claim model and eliminate those elements that a competitor can eliminate. Are there any elements that can be replaced with substantially nonequivalent elements? For these, try to devise different claim elements that are more generic and therefore cover both the originally contemplated element and the nonequivalent substitute. The objective is to make the claim devilishly difficult to design around.

I. CONSIDERING FALL-BACK POSITIONS

Once you have constructed a claim model that highlights what is new about the invention, distinguishes the invention from all prior art of which you are aware, and is devilishly difficult to design around, there is one more thing to do. Think about your fallback position. How will you revise the claim if it is rejected by the Patent Office over art of which you are not aware? Naturally, until you know about the prior art, you cannot possibly predict with certainty how to revise the claim to avoid the art. However, since most claims are rejected in the first office action, expect this one will be too. It is therefore wise to have some subject matter in the specification that can be later added to the independent claims.

J. DRAFTING AND REFINING CLAIMS

There are several ways of drafting actual claim language, once you have the claim model worked out. If you are fairly skilled using a word processor, you

SPW (November 2007) 12 – HOW TO DRAFT Software Patents Worldwide may want to draft the claim language directly on the screen using your word processor. This can be a fairly efficient way to work, even if you are not a fluent typist, because drafting the claim language involves a great deal more thinking than it does typing. Decidefirstonthe form oftheclaim, for example,apparatus andmethod.This will dictate how the claim preamble should be worded. However, do not con- sider initially what to put in the claim preamble. It is usually easiest to build the claim preamble after the claim element language has been drafted. Using the claim model diagram as a , start by drafting language to describe each of the elements and the relationships between elements. Be sure to organize the elements so that elements supplying an antecedent basis for other elements appear first in the claim. To illustrate, see Figure 1, on page 8, which shows a claim model diagram. A rough draft claim might be something like this:

A computer system for word-processing, comprising: – input means responsive to operator-input characters; – a printer capable of printing in text mode and in graphics mode; – a memory associated with said printer for storing text mode font definitions; – a data storage means for identifying characters having text mode font definitions in said memory; – a processing means coupled to said input means and to said data storage means and to said printer for comparing operator-input characters with said characters in said data storage means and for causing said printer to print the operator-input characters according to a predetermined set of font selection rules. Note in the above rough draft example, the preamble is nothing more than a place holder. The antecedent basis details have not been added in the pre- amble at this point. Similarly, the individual claim elements are also lacking details. Integration of the claim elements is not yet tight, and the claim does not yet distinctly represent the invention. Work with the rough draft claim language, tightening the phraseology and supplying missing antecedent bases, until the claim reads, start to finish, without ambiguity. Having done this, the finished claim might be something like this: 1. A computer system for performing word-processing operations, the computer system comprising: a. input means responsive to operator commands enabling an operator to specify any of a plurality of characters for inclusion in a document being created or edited;

SPW (November 2007) Software Patents Worldwide HOW TO DRAFT – 13

b. printing means having the capability of printing characters in either text or graphics mode; c. memory means associated with the printing means for storing a text mode definition for each of a subset of the plurality of characters that may be specified by the operator using the input means; d. a first data storage means identifying each character having a text mode definition in the memory means; e. processing means coupled to the input means, the first data storage means and the printing means for comparing each character selected by the operator with information stored in the first data storage means to determine whether, for each specified character, a text mode definition exits in the memory means and,

i. if said definition exists, sending data to the printing means iden- tifying the character; or ii. if said definition does not exist, taking alternative action compris- ing sending data identifying an alternative character to the print- ing means for printing in graphics mode or sending data identifying said alternative character in a substitute font to the printing means for printing in text mode.

K. NARROW CLAIMS

There is more to claim drafting strategy than drafting a single independent claim. A patent with only one claim qualifies under the old adage as ‘putting all your eggs in one basket’. While having at least one broad claim is certainly desirable, it is far better to cover the spectrum with broad, interme- diate, and narrow claims. This may entail having different sets of independent claims, each of different scope. It may also entail having claims of different types, for example, apparatus claims, method claims, Jepson claims, Markush claims, means plus function claims, and so forth. Nearly without exception, this will entail having dependent claims. Why have intermediate and narrow claims, and specifically, why have dependent claims? Simply, these claims serve as insurance against broad claim invalidity. All claims issued by the Patent Office are presumed valid over all prior art considered by the patent examiner. However, when there is a great deal of money at stake, defendants in litigation go to great lengths to find closer prior art than the patent examiner considered – to prove that the claims in litigation should never have been granted. Because broad claims cover more intellectual territory, they are easier to invalidate. While the precise details may vary from country to country, gen- erally speaking, to invalidate any claim you must show that the claim reads on (covers, element by element) a prior art device or reference. Broader claims

SPW (November 2007) 14 – HOW TO DRAFT Software Patents Worldwide read on more, and they are therefore more vulnerable to being invalidated. Therefore, while most attorneys strive for the broadest claim allowable, most patent litigation attorneys prefer the narrowest claim that covers the accused. Litigation attorneys prefer a narrow claim, because a narrow claim is harder to invalidate and because a narrow claim, read on the accused, demonstrates how closely the accused has ‘copied’ the invention.

L. DEPENDENT CLAIMS

A good way to a draft claim of narrower scope is to draft a dependent claim. A dependent claim is one that incorporates by reference or ‘depends’ from an independent claim. Object-oriented computer programmers will recognize the dependent claim as a child claim that ‘inherits’ all of the elements and limitations of the parent claim – just as rowboat inherits all properties of the class, watercraft. Incorporating all of the limitations of the independent claim parent, the dependent claim is, by definition, narrower than the independent claim parent. This narrowing inheritance relationship can cascade through several generations; hence, one dependent claim can be based on another dependent claim, which in turn can be based on still another claim, perhaps an independent claim. The one dependent claim at the bottom of the cascade would be said to incorporate all of the elements and limitations of the independent base claim and any intervening claims. There are typically two ways to draft dependent claims. You can amplify, by adding an additional limitation to an existing claim element of the parent claim; or you can augment, by adding a new claim element to the parent claim. The mechanics for each of these is quite simple. To amplify, use a ‘wherein’ phrase: 2. the invention of claim 1 wherein said balloon is blue. To augment, use a ‘further comprising’ phrase: 3. the invention of claim 1 further comprising a second balloon. It is also proper to cascade one dependent claim from another. Thus, you could add the following additional dependent claims, based on the ones presented above: 4. the invention of claim 2 further comprising a second balloon. 5. the invention of claim 3 wherein said second balloon is blue. By the time you are done, you can have all permutations of one and two (blue and nonblue) balloon embodiments covered, as illustrated.

SPW (November 2007) Software Patents Worldwide HOW TO DRAFT – 15

Dependent claims can get quite narrow quickly, when cascaded. This is usually not good practice. It is better practice to base most dependent claims directly upon an independent base claim. In that way each dependent claim can amplify or augment a single feature or aspect of the invention, in a narrower sense, without bringing in unnecessary limitations.

M. CLAIM-DRAFTING TEMPLATES

Every invention is different. That is the claim drafter’s starting point. More precisely, every patentable invention represents a novel, non-obvious improvement over what existed before it. Thus, rarely does study of a claim of a particular prior art patent shed much light on how to draft a claim for a new invention. Indeed, the patent claim for the new invention must represent something different than the prior art claim represents. In this context, it seems clear that one should not draft a patent claim for a new software invention by starting with the claim of the closest prior art reference and then modifying it. Doing that is one sure way to increase the likelihood that your new claim will be rejected by the Patent Office. Patents are not granted merely for making obvious modifications to the existing art. Yet, when dealing with unfamiliar territory, many attorneys feel the temp- tation to start with the claim of someone else (presumably someone more experienced) and then modify it. This will almost always lead to problems. By analogy, it is far simpler to revise an existing contract than it is to draft a new contract from scratch. However, as contract lawyers know, always draft your own agreement; do not merely modify the other party’s agreement. That way you remain in control of all the countless subtleties. A patent claim is a contract with the government. It makes sense, then, to follow the contract lawyer’s adage: always draft the contract yourself. Always draft the claim yourself. Do not modify the claim of someone else, who may indeed represent your client’s present or future adversary. Does this mean that you can learn nothing by studying the claims of others? Certainly not. Issued patents provide an excellent source of knowledge – not only technological knowledge, but claim-drafting knowledge as well. Simply understand that no single patent claim should be used as a starting point in drafting a new claim. Instead, use issued patent claims to discover claim- drafting techniques or solutions to claim-drafting problems you may be struggling with. You will find that, like technological problems, the same claim-drafting problems recur over and over, each time in a different inven- tive context. Recognizing that the same problems seem to crop up again and again, software developers now use ‘design patterns’, a concept borrowed from architecture, to group together problems that share a common solution.

SPW (November 2007) 16 – HOW TO DRAFT Software Patents Worldwide

To understand the power of design patterns, look around for the many different uses of the arch, or the tiled roof, in building architecture. Although the appearance may differ widely from use to use, the functions of these well-chosen patterns remain the same. Claim-drafting patterns work the same way. The claim-drafting templates below present several claim-drafting patterns in the form of claim-drafting templates. These templates show how to solve some recurring claim-drafting problems.

1. Claim-Drafting Template for Real-Time Processes

Speed and storage capacity are two scarce computer commodities. At the metaphysical level these commodities represent the very essence of the uni- verse: time and space. It is not surprising, then, that software developers will spend substantial resources exploiting these commodities. Simply stated, in the computer industry faster is better, and you never have enough memory. When it comes to speed, nearly every software developer must, from time to time, play beat-the-clock. However, some software developers do it for a living, earning them the moniker of real-time programmers. Real-time programming is a term that defies definition. You will encoun- ter some software inventors who use the term in a precise way to refer to processes that must fully execute, start to finish, between hardware interrupt cycles. You will encounter other software inventors who use the term in a more general way to refer to processes that occur interactively, as opposed to in batch. Patent examiners will often reject a claim in which hinges on the term ‘real-time’, simply because the term ‘real-time’ may have no precise meaning set forth in the claim or explained in the specification. To include a ‘real-time’ recitation in a claim, you may want to define a time frame, preferably one that ties to a physical condition within the system. You may then recite any real-time process as one that executes within that pre- scribed time frame. Think of a stopwatch whose hand makes one complete revolution in one second. If that one-second revolution defines the time frame for this system, then a real-time process might be one that starts and finishes before the hand makes one complete revolution. Although the stopwatch here is simply an example to make the point, try to find something akin to the stopwatch in every real-time process and use it to define the time frame. The following claim template demonstrates how the real-time process may be recited. Both apparatus and method claim templates are provided. The phrases in brackets are optional or intended to show how you might incor- porate the template into your existing claim. Remember, these templates contain concepts, not magic words. In using these concepts, choose words that best fit the particular invention at hand.

SPW (November 2007) Software Patents Worldwide HOW TO DRAFT – 17

1. An apparatus, comprising: – [Element A]; – [Element B]; – a timing element that defines a predetermined time interval [based on some physical condition or demonstrable state of the system being claimed or its environment]; – a real-time element [processor, engine, etc.] that performs XYZ [the real-time process] fully within said predetermined time interval; – [Element C]. 2. A method, comprising: – [Step A]; – [Step B]; – establishing a predetermined time interval [based on some physical condition or demonstrable state of the system being claimed or its environment]; – performing XYZ [the real-time process] fully within said predeter- mined time interval; – [Step C]. As noted in these templates, you may wish to express the predetermined time interval in terms of some physical condition or demonstrable state of the system being claimed or its environment. The physical condition or state may be tied to one of the other elements or steps recited in the claim. If so, then that element or step should be recited first, to provide proper antecedent basis for the time interval recitation. Often, the physical condition or state may be tied to some entity in the environment in which the invention is intended to operate. In such case, you may want to recite that environmental entity. For example, say the invention controls the rotational speed of a motor. You might use the real-time template this way: 1. A computer-implemented apparatus for controlling the speed of a motor, comprising: – apowersupplycoupledtosaidmotorforsupplyingenergytosaidmotor; – a sensor optically coupled to said motor for generating pulses indicative of motor speed, said pulses defining a plurality of time intervals between successive pulses; – a fuzzy logic processor coupled to said power supply for delivering a control parameter to said power supply, said control parameter in turn causing said power supply to alter the supply of energy to said motor; – wherein said processor updates said control parameter using a fuzzy XYZ relationship and delivers the updated control parameter to said power supply, all within a single one of said time intervals.

SPW (November 2007) 18 – HOW TO DRAFT Software Patents Worldwide

2. Claim-Drafting Template for Iterative Processes

Computers excel at repetition. Unlike its human creators, a computer makes little distinction between the command, ‘Do this once’, and the command, ‘Do this a thousand times’. The process by which computers will so readily loop through the same operation a thousand times is called iteration. Software developers express iteration in several ways. Here is one simple example: Let X ¼ 0 Repeat the following steps until X is 1000: Begin Y ¼ m*X þ b X ¼ X þ 1 End Actually, there are several different kinds of iteration that are worth recog- nizing. Each has its own purpose. You will encounter all types in practice. Nicholas Wirth, a world-famous computer scientist and educator, developed the computer language Pascal to teach his students basic programming con- cepts such as iteration. Although the Pascal language is no longer in wide- spread use, its syntax is easily understood, making it still one of the best languages for expressing basic computer software concepts. The Pascal language defines at least three different kinds of iteration, each with its own unique twist. In the following discussion, keywords printed in boldface are terms defined by the Pascal language. Other computer languages may use different syntax. The first iteration type uses the while statement. The form of this statement is while condition do statement. To illustrate this form of iteration, consider this example. while daylight do begin read temperature sensor; look up correction factor in ; update processor input; end The while statement causes this process to loop repeatedly or iterate until the condition (daylight) becomes false. What distinguishes this first iteration type is its ability to skip the process entirely if the condition is never true. If it is not daytime when this while procedure is invoked, none of the steps between begin and end ever get performed.

SPW (November 2007) Software Patents Worldwide HOW TO DRAFT – 19

The second iteration type uses the repeat statement. The form of this statement is repeat statement 1; statement 2; ... statement n; until condition. To illustrate this form of iteration, consider this example. repeat read temperature sensor; look up correction factor in table; update processor input; until night time. Unlike the while statement, the repeat statement executes its included state- ments at least once, even if the until condition turns out not to be true. Thus, in the preceding example, the read, look up, and update steps are performed once (the first pass through) even if it is already night time. The third kind of iteration uses the for statement. The form of this state- ment is for control variable: ¼ a to n do begin statement 1; statement 2; ... statement n; end To illustrate this form of iteration, consider this example. for n: ¼ 1 to 1000 do begin read temperature sensor; look up correction factor in table; update processor input; end This programme will execute for a pre-specified number of iterations and the number of iterations does not depend on the effect of statements within the loop. In this example, the variable n serves as a counter that the programme automatically increments each time the begin-end loop is performed.

SPW (November 2007) 20 – HOW TO DRAFT Software Patents Worldwide

You may encounter each of these iteration kinds in claiming a software invention. The following claim templates demonstrate how each of these forms of iteration may be recited. Both apparatus and method claim templates are provided. The phrases in brackets are optional or intended to show how you might incorporate the template into your existing claim. Remember, these templates contain concepts, not magic words. In using these concepts, choose words that best fit the particular invention at hand.

3. The While Loop Template

1. A method, comprising: – [Step A]; – [Step B]; – while X is true [or false] iteratively performing: – [Step C]; – [Step D]; – [Step E]; – [Step F]. 2. An apparatus, comprising: – [Element A]; – [Element B]; – [iterator] element that iteratively performs CDE while X is true [or false]; – [Element F]. To illustrate use of the template, consider the following claim for a method of accessing information over the Internet. 1. A method of accessing information from Internet web pages having hypertext links to other web pages for off-line viewing, comprising: – connecting a computer to a service provider; – running a browser on said computer; – prompting the user to terminate the running of said browser to end an information-accessing session; – while said browser is running, iteratively performing the following steps a–c: a. accessing a web page and storing the information content of said web page in said computer; b. identifying on said web page at least one hypertext link to a different web page;

SPW (November 2007) Software Patents Worldwide HOW TO DRAFT – 21

c. accessing said different web page and storing the information content of said different web page in said computer; – disconnecting said computer from said service provider; and dis- playing said stored information content.

4. The Repeat-Until Loop Template

1. A method, comprising: – [Step A]; – [Step B]; – [Step C]; – [Step D]; – iteratively repeating steps B, C, and D until X is true [or false]; – [Step F]. 2. An apparatus, comprising: – [Element A]; – [Element B]; – [iterator] element that performs CDE and iteratively repeats CDE while X is true [or false]; – [Element F]. To illustrate use of this template, consider the following claim for a method of accessing information over the Internet. 1. A method of accessing information from Internet web pages having hypertext links to other web pages for off-line viewing, comprising: a. connecting a computer to a service provider; b. running a browser on said computer; c. prompting the user to terminate the running of said browser to end an information-accessing session; d. accessing a web page and storing the information content of said web page in said computer; e. identifying on said web page at least one hypertext link to a different web page; f. accessing said different web page and storing the information content of said different web page in said computer; g. iteratively repeating above steps d–f until the running of said brow- ser is terminated; h. disconnecting said computer from said service provider; and i. displaying said stored information content.

SPW (November 2007) 22 – HOW TO DRAFT Software Patents Worldwide

Comparing this Repeat-Until loop example with the preceding While loop example, note that steps d–f in the Repeat-Until example are required to be performed at least once. In contrast, the comparable steps a–c in the preced- ing While example may never be performed, if the browser is terminated before the iterative steps commence.

5. The For Loop Template

The For loop can also be equivalently expressed using If-Then terminology discussed in Sections I.M.6 and 7 below. You may find the If-Then terminol- ogy more natural. 1. A method comprising: – [Step A]; – [Step B]; – setting X [a counter] to an initial condition; – for X less than [not equal to] Y [the terminating condition], performing the following: – [Step C]; – [Step D]; – [Step E]; – incrementing X; – [Step F]. 2. An apparatus comprising: – [Element A]; – [Element B]; – [iterator] element having a data structure for storing a counter initi- alized to a predetermined value, said [iterator] element being operable to iteratively increment said counter and to perform CDE for counter values less than [not equal to] Y [the terminating condition]; – [Element F]. To illustrate this template, consider the following example. 1. A method of accessing information from Internet web pages having hypertext links to other web pages for off-line viewing, comprising: – connecting a computer to a service provider; – running a browser on said computer; – establishing a counter for storing values used in performing iteration; – setting said counter to an initial value and prompting the user to input a terminal value;

SPW (November 2007) Software Patents Worldwide HOW TO DRAFT – 23

– for counter values not equal to said terminal value, iteratively performing the following steps a–d: a. accessing a web page and storing the information content of said web page in said computer; b. identifying on said web page at least one hypertext link to a different web page; c. accessing said different web page and storing the information content of said different web page in said computer; d. incrementing said counter; – disconnecting said computer from said service provider; and dis- playing said stored information content. This For Loop example is quite similar to the While loop example presented in Section I.M.5. The For loop differs in that the initial and terminal condi- tions are more explicitly set forth. Also note that by specifying details about the terminal value, you can make the claim dictate whether the iterated steps must be performed at least once, or whether they may be skipped entirely. Do this by specifying the relationship of the terminal condition to the initial condition, as follows. If the claim recites that the terminal condition is greater than the initial condition, then the iterative steps are performed at least once. In contrast, if the claim recites that the terminal condition is greater than or equal to the initial condition, then the iterative steps could be skipped (if the user selects a terminal condition equal to the initial condition).

6. The If Statement Iterator

Another useful variation on the iteration theme is the if statement. The keyword if in Pascal (and also in other computer languages) means much the same thing as in a standard English sentence. ‘If it is sunny, play golf, otherwise stay inside and work’, would be coded in Pascal something like this: if sunny then golf else work. As in preceding sections, the keywords in italic are defined terms in the Pascal language. Important to note about the if statement is how the stated condition (in this case, ‘sunny’) alters the flow of the programme logic. The condition operates like a switch. If the condition is true, do one thing; if false, do another thing. Software developers sometimes refer to this feature of the if statement as performing ‘flow control’ because the statement alters the logical flow of the programme as railroad yard switches alter the flow of an approaching train.

SPW (November 2007) 24 – HOW TO DRAFT Software Patents Worldwide

When the switch is thrown defines an essential difference between the if state- ment and the other iteration forms discussed next. The if statement tests the condition before either succeeding option is performed. Thus it is possible that in a given situation the if statement will do nothing at all. Consider this example: if Saturday then begin mow lawn; go shopping; wash car; end else do nothing. In this example nothing gets done, except on Saturday. After testing the condition, Saturday, programme flow branches to the else do nothing statement for every day except Saturday. Although the else branch is shown here for clarity, most computer languages permit this ‘do nothing’ statement to be omitted because ‘do nothing’ is implied where no instruction is given. 7. The If-Then Loop Template

The If-Then loop can also be equivalently expressed using For loop termi- nology discussed in Section I.M.7. You may find the If-Then terminology more natural. If-Then statements can be used for many purposes besides iteration. These include many examples of flow control, where programme control follows different tracks depending on some switching condition. The template presented here demonstrates iteration. 1. A method comprising: – [Step A]; – [Step B]; – setting X [a counter] to an initial condition; – if X is less than [not equal to] Y [the terminating condition], then performing the following: – [Step C]; – [Step D]; – [Step E]; and – incrementing X; – [Step F]. 2. An apparatus comprising: – [Element A];

SPW (November 2007) Software Patents Worldwide HOW TO DRAFT – 25

– [Element B]; – [iterator] element having a data structure for storing a counter initia- lized to a predetermined value, said [iterator] element being operable to iteratively increment said counter and to perform CDE if said counter value is less than [not equal to] Y [the terminating condition]; – [Element F]. To illustrate this template, consider the following example: 1. A method of accessing information from Internet web pages having hypertext links to other web pages for off-line viewing, comprising: – connecting a computer to a service provider; – running a browser on said computer; – establishing a counter for storing values used in performing iteration; – setting said counter to an initial value and prompting the user to input a terminal value; – if the counter value is not equal to said terminal value then iteratively performing the following steps a.-d.: a. accessing a web page and storing the information content of said web page in said computer; b. identifying on said web page at least one hypertext link to a different web page; c. accessing said different web page and storing the information content of said different web page in said computer; d. incrementing said counter; – disconnecting said computer from said service provider and display- ing said stored information content.

8. Recursive Processes

Iteration, which involves repetition of a sequence, is not the only way to exploit the power of a computer. Indeed, software developers discovered long ago that some problems are very tedious to solve using iteration. Another approach, called recursion, exploits a different, divide-and-conquer strategy. Recursion involves subdividing a difficult problem into smaller, easier-to-solve problems that structurally resemble the big problem. If the smaller problems are still too difficult to solve, they may be subdivided into still smaller problems, ad infinitum, until the solution becomes easy. Not all problems can be solved by recursion. Recursion requires that the problem meet these three criteria: 1. It must be possible to decompose the original problem into simpler instances of the same problem.

SPW (November 2007) 26 – HOW TO DRAFT Software Patents Worldwide

2. Once each of these simpler subproblems has been solved, it must be possible to combine these solutions to produce a solution to the original problem. 3. As the large problem is broken down into successively less complex ones, those subproblems must eventually become so simple that they can be solved without further subdivision.2 To better understand recursion, consider the task of looking up a word in the dictionary. Say the word is ‘sphinx’. Clearly, using an iterative approach, starting at the beginning of the dictionary with the letter A and checking every entry seriatim, will be far too slow. A recursive approach is much faster. Deciding to proceed recursively, you open the dictionary to the very middle and determine if ‘sphinx’ is in the first half or the last half of the book. In this case, ‘sphinx’ is in the last half, so you forgo further browsing of the first half and concentrate on the last half. Applying the very same divide- and-conquer technique, you subdivide the last half of the dictionary into halves, thereby opening the dictionary to the page beginning with the word ‘rumpy’. From ‘rumpy’, you determine that ‘sphinx’ is in the latter half, so you forgo browsing the first half and proceed as before. Subdividing again takes you to the page beginning with ‘Themis’. The word you seek, ‘sphinx’, is now in the first half of this latest subdivision. You continue in this same fashion. After only a few more recursions you find your ‘sphinx’. In Pascal-like pseudocode, a recursive process might look like the following. (Keywords printed in boldface are terms defined by the Pascal language. Other computer languages may use different syntax.) procedure solve (problem); begin if problem is easy then solve problem directly else begin break problem into subproblems (P_1, P_2 ...) solve(P_1); solve(P_2); ... reassemble solutions end end. In this example, note that the steps ‘solve(P_1); solve(P_2); ...’are themselves performed using the procedure solve (problem) defined by the pseudocode. It may seem strange that a procedure may call itself, but that is what occurs. The resulting code nests within itself like Russian

2. E.S. Roberts, Thinking Recursively 8 (1986).

SPW (November 2007) Software Patents Worldwide HOW TO DRAFT – 27 matryoshka dolls, sometimes many levels deep. The computer has no problem handling such requests because it has something called a control stack where it keeps a list of all unfinished tasks. Thus, when the innermost task is completed, the computer simply consults the control stack to get the numbers it needs to resume where it left off on the next outermost problem.

9. Recursion Template

1. A method comprising: – [Step A]; – [Step B]; – defining a recursive procedure that includes steps a–d: a. [Step C]; b. [Step D]; c. using said recursive procedure; d. [Step E]; – performing said recursive procedure. 2. An apparatus comprising: – [Element A]; – [Element B]; – recursive processing element that performs ABC at least in part by recursively using said recursive processing element; – [Element D]. Claiming a recursive algorithm can be tricky, particularly with the method claim, because you may encounter the antecedent basis difficulties. The following example shows how a recursive method claim may be constructed. As with the preceding examples, these templates are intended to show con- cepts, not magic words. In using these concepts, choose words that best fit the particular invention at hand. 1. A method of generating a word list for a text containing a plurality of words, comprising: – storing said plurality of words as a binary tree having a root node and a plurality of offspring nodes that define left and right subtrees, said root node and said offspring nodes each being associated with one of said words; – defining a traverse procedure that includes the steps of: a. visiting a node and printing its associated word; b. recursively using said traverse procedure upon the left subtree of said visited node;

SPW (November 2007) 28 – HOW TO DRAFT Software Patents Worldwide

c. recursively using said traverse procedure upon the right subtree of said visited node; – applying said traverse procedure upon said root node such that said root node is the first visited node.

SPW (November 2007)