“It is important to keep in mind that courts have found that the mere intent to keep the document confidential is insufficient.”
Recently, I met with a potential client to discuss key points that developers and management should keep in mind in taking the first steps to begin developing a patent portfolio. One aspect of the presentation was public disclosures that began the one-year grace period for filing for patent protection. As I was preparing examples, a practical concern emerged; specifically, whether storing source code in a third-party code repository amounted to a public disclosure or a printed publication. My research revealed that there are certain instances where uploading source code to a third-party repository amounted to a public disclosure or a printed publication, but there were precautions that developers and companies could take to prevent the inadvertent public disclosure of their code.
Third-Party Code Repositories: The Basics
Before examining the circumstances under which code stored in a third-party code repository constitutes a public disclosure, it helps to have a basic understanding of how code repositories work. Third-party code repositories are workflow management tools for managing software development. This workflow includes, among other tasks, hosting code, supporting code review, providing wiki pages, and compiling code. Hosting codes includes storing source code in either a self-hosted solution, a cloud-based solution, or a hybrid solution. Each of these solutions catalogs code in repositories, which often includes a brief description of the functionality of the code. These repositories may be either private or public. Private repositories only allow the owner and collaborators to view or contribute to the code. Public repositories, on the other hand, are visible to anyone. That is, public repositories are indexed and searchable for other developers to find the code. Depending on the license under which the code is available, these other developers may incorporate the publicly available code into their own projects. Alternatively, other developers may themselves contribute to the publicly available code. For example, these contributions may be part of an open-source project that seek to improve the code with the help of willing and able volunteers. In this regard, public repositories present the potential to turn private code into a printed publication as of the date that it is uploaded to the third-party code repository.
A Question of Accessibility
The touchstone of whether a reference is a printed publication is determined in the context of public accessibility. In re Wyer, 655 F.2d 221, 226 (CCPA 1981). “The question to be examined . . . is the accessibility to at least the pertinent part of the public, of a perceptible description of the invention, in whatever form it may have been recorded. Access involves such factual inquiries as classification and indexing.” Id. “[I]ntent to make public, activity in disseminating information, production of a certain number of copies, and production by a method allowing production of a large number of copies [are factors] in determining whether an item may be termed a ‘printed publication[.]’” While these factors are comprehensive, no individual factor is considered to be dispositive. Id. at 227. Moreover, it is important to note that the Federal Circuit has indicated that the form of the information was irrelevant to the inquiry of whether a reference constituted a printed publication. Id. (“Whether information is printed, handwritten, or on microfilm or a magnetic disc or tape, etc., the one who wishes to characterize the information, in whatever form it may be, as a ‘printed publication.’”).
At least one district court has found an instance where software constitutes a printed publication. In Dow Jones & Co., Inc. v. Alblaise, Ltd., the D.C. District Court addressed the issue of whether source code constitutes a printed publication. See Dow Jones & Co., Inc. v. Ablaise Ltd., 632 F.Supp.2d 23, 36-37(D. Ct. D.C. 2009). Alblaise accused Dow Jones of infringing two of its patents. Id. at 27-29. Dow Jones challenged the validity of both patents using, in part, two different programs. Id. at 30-32, 36-38. Dow Jones argued that one of the programs constituted a printed publication. Id. at 36-37. In evaluating whether the program constituted a printed publication, the court weighed several factors, including “the length of time the display was exhibited, the expertise of the target audience, the existence (or lack thereof) of reasonable expectations that the material displayed would not be copied, and the simplicity or case with which the material displayed could have been copied.” Id. (internal citations omitted). The court found that the program constituted a printed publication because the program was posted for over a year before the priority date of the challenged patent, at least two newsgroups posted the link for computer scientists, and web programmers, and the developer of the program encouraged others to copy and use his code. Id. On appeal, the Federal Circuit reversed the decision for lack of subject matter jurisdiction and did not address the question of whether the program constituted prior art. Dow Jones & Co. v. Ablaise Ltd., 606 F.3d 1338, 1353 (Fed. Cir. 2010). In the framework of the Wyer factors and the analysis set forth in Dow Jones, a court would most likely find that code published to public repositories, along with its applicable description (i.e. Read Me file or wiki page), would constitute a printed publication as of its upload date since public repositories provide a publicly accessible location where skilled artisans (i.e. developers, programmers, etc.) can discover the code. Accordingly, the date the code was uploaded to the public repository would begin the one-year grace period for which an applicant may file for patent protection.
Private repositories, on the other hand, are not publicly accessible. They are only limited to the owner and whoever the owner authorizes to access the content of the private repository. In this regard, developers searching third-party code repositories will not be able to discover private repositories.
Take Steps to Avoid Disclosure
In conclusion, the best practice would be to store source code in a private, onsite repository. That is, store the code on corporate servers with safeguards in place to ensure the confidentiality and integrity of the code. However, if a third-party code repository is used, developers should take steps to protect the source code from public disclosure. For example, repositories should be private, only allowing authorized personnel to access the data stored therein. Additionally, companies should implement data governance policies that define that the source code should be stored in private repositories and that the code should be marked as either “Confidential,” “Do Not Disseminate,” or have some other comparable markings. Moreover, invention disclosure forms should be updated to inquire where source code is stored, and, if stored in a public repository, when the source code was uploaded to the public repository. Taking these precautions would weigh against a finding that the source code and any applicable descriptive material stored on a third-party code repository constituted a printed publication that could be used as prior art against any subsequently filed patent application.
Image Source: Deposit Photos
Photo by spaxiax
Join the Discussion
One comment so far.
H CantuMay 2, 2019 08:49 am
This only spreads fear to ignorant executives about using private repositories on GitHub and equivalents. Which usually results in a development workflow that stifles speed and collaboration. Been there, done that. It’s better to have your codebase free of access tokens and security credentials, so in case your code is compromised, (it could happen in many ways, not just by having it in the cloud) you could be sure your data and the data of your customers is safe.