TAKEAWAY: Software companies are increasingly implementing beta testing on a more flexible and rolling basis. Even though such betas do not always trigger patent-limiting public uses, companies should consider filing at least a provisional patent application before any new features are pushed to an ongoing beta release.
Many software companies initially test new and experimental features as part of a beta release. Lately, beta releases are less structured and in some cases have continuously changing features over time. In some cases, certain customers are given access to the newest software features while development is still ongoing, while others are given access to still other test features. While this practice often generates valuable feedback and customer satisfaction, it may also inadvertently limit patent rights for the new features, both in the U.S. and abroad.
U.S. law requires that an invention to be patented not have been published, on sale, or in public use more than one year prior to filing in the United States. While each of “published, on sale, or in public use” constitute three separate potential one-year pitfalls, it’s the public use bar that is often most relevant for software beta programs. “Public use” may occur when others are allowed to use the invention without limitation, restriction or obligation of secrecy. See In re Smith, 714 F.2d 1127 (Fed. Cir. 1983).
To avoid triggering public use, many companies restrict the availability of the beta release, implement a beta agreement listing restrictions, and/or impose a confidentiality agreement. These would seem to constitute a “limitation, restriction, or obligation of secrecy.” So is the problem solved? Not necessarily.
Courts typically implement a multi-factor test to evaluate whether a public use has occurred through a beta program, including:
- the presence or lack of a confidentiality agreement, see Moleculon Research Corp. v. CBS, Inc., 793 F.2d 1261 (Fed. Cir. 1986);
- whether the experimental nature of the product was communicated to the beta testers;
- whether the beta testers are charged any fees;
- whether there is an acknowledged value and necessity of involving members of the public; and
- whether (and how) the company harvests and utilizes the results of the beta testing program.
Since “public use” analysis involves a multi-factor test, and may change over time, there is no “silver bullet” for protecting features launched in betas. Moreover, even if a beta program is carefully administered to avoid the public use bar, the risk of publication and on-sale bars remains. Courts have held that the on-sale clock begins ticking when (1) the product is the subject of a non-experimental offer for sale, and (2) the invention is ready for patenting. See Pfaff v. Wells Elecs., Inc., 525 U.S. 55 (1998). Thus, the on-sale bar might be inadvertently triggered if, for example, beta test users are given a coupon offering a discount on the soon-to-be released version. Conditional, confidential, or even rejected offers for sale may also trigger the on-sale bar. See Strong v. General Elec. Co., 434 F.2d 1042 (5th Cir. 1970); Hobbs v. United States, 451 F.2d 849 (5th Cir. 1971); UMC Elecs. v. United States, 816 F.2d 647 (Fed. Cir. 1987). In addition, most countries outside of the U.S. do not have a one-year grace period, so even a properly administered, confidential beta program may nevertheless limit available patent rights in many foreign jurisdictions.
While it is possible to administer a beta testing program without limiting patent rights in the United States, software companies should consider filing at least a provisional patent application on potentially patentable features prior to beta release. Provisional patent filings may be prepared and filed quickly and inexpensively, usually within a few hours to a day, to avoid delaying important software rollouts. Given this solution, involved parties should regularly communicate with development teams about upcoming releases, beta or otherwise, to ensure that innovative features are protected.