The purpose of this month's newsletter is to provide guidance to clients for whom I have been engaged to file a software patent application. Because a software patent application must explain not only what the software does but also how it works, we need to have a technical write-up from the client that addresses not only the software functionality from a user perspective but also what is going on on the back end (the part that the user does not see).
Set forth below are guidelines I have developed over years of working with clients on software patent applications. Some of these guidelines are substantive, but many relate to format. The less time our office has to spend on formatting issues, the more time we can spend on the substantive issues that will increase your chances of patentability.
1. Draw up your figure list before you start writing. The figures need to tell the story of your invention, and the write-up should address each figure in order. We usually start with an overall system architecture drawing and then have several flow diagrams. The flow diagrams should illustrate both how the software works from a user perspective and how the software works from an engineering perspective. You may include however many flow diagrams you feel are necessary to fully explain how the software works. If the software has been built (I recommend that you at least have a beta version of your software before you consider filing a patent application), then the flow diagrams are usually followed by a series of screen shots. The screen shots should elaborate on the steps that were shown in the flow diagrams.
2. Address all figures in order. The figures should be labeled "Figure 1," "Figure 2," etc. (these are the figure numbers) and addressed in order in the write-up.
3. Provide a figure list. Please provide a brief description of each figure. For example, "Figure 4 is a flow chart that shows the major components of the interactive monitor of the present invention," and "Figure 8 is a screen shot of the object view tree with the test set editor displayed."
4. All figures must be black-and-white line drawings. This applies equally to the screen shots; there can be no color or grayscale in any of the drawings.
5. Follow protocols for figure numbers and figure page numbers. Each figure should be on a separate page, and each flow diagram needs to fit on a single page. The figure number should be centered directly underneath the figure. All figure pages should be numbered in the top center of the figure, approximately one inch down from the top of the page. For example, if there are ten figures, the first figure page number would be "1/10." The second figure page number would be "2/10," and the last figure page number would be "10/10."
6. Make sure we have copies of all of the figures. Please make sure that when you provide the write-up and figures to use, we have copies of all of the figures.
7. The write-up should be in paragraph format and not in outline or bullet-point format. Technical writers are used to providing documents in outline or bullet-point format, but a patent write-up must be in paragraph format. For examples, please visit the patents and published applications page of our website, click on a title that sounds like it is a software invention, and scroll down to the "Detailed Description of Invention" section.
8. Use reference numbers. Each block in a system architecture drawing, each box (or step) in a flow diagram, and every component (field, button, etc.) on a screen shot should have a reference number associated with it. You should use the same reference number for the same component or step in all figures.
For blocks in system architecture drawings or boxes on flow charts, the reference number can be in the block or box. For screen shots, the reference number should be on the end of a line drawn to the component with which it is associated. Each reference number should be addressed in the discussion of that figure in the write-up. This means, for example, that every step in a flow diagram must be explained. Do not include parentheses around the reference numbers in the text. For examples of the use of reference numbers in the text, please visit the patents and published applications page of our website, click on a title that sounds like it is a software invention, and scroll down to the "Detailed Description of Invention" section.
9. Do not include any funky fonts or automatic formatting in your document. Please do not use color, bold, underlining, italics, or any other alternate fonts in the write-up. Similarly, please do not include any automatic formatting, such as automatic paragraph formatting or automatic numbering. Do not put any text in brackets. These things make it more difficult for us to edit the document.
10. Please provide the text and figures in the requisite font type and size. The write-up should be in Times New Roman 12-point font, and the font on the figures should be Arial. In addition, all letters and numbers appearing on a figure must be at least 1/8-inch font size. The figure number ("Figure 1," "Figure 2," etc.) should be in a slightly larger font than the font on the rest of the page.
11. Do not use initial capital letters for common nouns. Technical writers also like to define terms and then use initial capital letters throughout the document to refer to those terms; however, the use of capital letters may actually limit the scope of your patent application by limiting the definition of a particular term. For that reason, I advise clients not to use initial capital letters with respect to generic terms. For example, it should be "user website" and not "User Website."
12. Do not include references to trademarks unless absolutely necessary. Whenever possible, use the generic name for something (for example, "hook-and-loop fastener") as opposed to "Velcro®." Your invention should be referred to as "the present invention" or "the system." You should not use the brand name (for example, "TeaseLawTM software") in referring to your invention.
13. Define all acronyms and abbreviations. Technical writers also like to use acronyms and/or abbreviations, which is fine as long as you provide a definition of every acronym or abbreviation that you use.
14. Eliminate redundant text. Examiners do not like long documents. Software patent applications tend to be the longest patent applications because of the necessity to explain in detail how the software works. For that reason, it is important to eliminate redundancy wherever possible. If we have explained once how a particular button works on a particular screen, we do not need to explain again how that same button works on another screen; we can simply refer to our previous explanation.
15. Do not attempt to draft claims. I will use your write-up in the Detailed Description of Invention section of the patent application. I do not need you to draft the claims, summary or abstract. I may ask you for a separate write-up of the problem you were trying to solve, which will be used in the Background section of the application.
16. Avoid use of the phrase "consists of." This phrase has a special connotation under patent law, and it means "consists of these things and nothing more."
17. Please proofread. Please proofread your work--including the figures--before they are provided to us. Our time (and your money) is best spent having us focus on the substantive issues.
Preparing a software patent write-up is a time-consuming effort, and the best software engineer is not always the best technical writer. If you do not have a technical writer in-house, you may want to consider hiring one to assist with the patent write-up.
