Blog

Entities such as Patent and Trademark Office, LLC, and Patent and Trademark Bureau, LLC give a false impression that they are the United States Patent and Trademark Office (USPTO), scamming more than 2,900 U.S. trademark registrants out of millions of dollars for inflated, and often fake, renewal fees. If you receive suspicious correspondence, check the USPTO scam alert webpage, contact the Trademark Assistance Center, and contact one of the attorneys at our firm to help evaluate the validity of the correspondence. Remember, the USPTO will never ask you for social security numbers or credit card numbers in general correspondence.

For more information and to learn more about the steps the USPTO is taking to combat scams, visit: USPTO

The Supreme Court published its decision in United States v. Arthrex on June 21, 2021, granting the Director of the USPTO final review in decisions made by Administrative Patent Judges in proceedings in front of the Patent Trial and Appeal Board. The USPTO has provided guidance as to the near term effects of this decision in a series of questions and answers that were recently updated on July 20, 2021.

The guidance provided by the USPTO includes a discussion of the mechanisms to request review by the Director and clarifies that a party cannot request both review by the director and rehearing by the original PTAB panel. For more, visit: IBA IP Section

The USPTO is seeking comment on the current state of patent eligibility jurisprudence since the Alice and Mayo decisions by the Supreme Court in 2016, and the effect that these decision and subsequent decision by the Federal Circuit have had on investment and innovation. The USPTO is asking for comments not just from attorneys, but also from inventors, patent owners, licensees, academic institutions and other groups or individuals who are impacted by the United States patent system. For more, visit: IBA IP Section

Monday, April 26 is World Intellectual Property Day, a day to celebrate and learn about the role that intellectual property rights play to encourage and facilitate innovation and creativity.  Originally created by the World Intellectual Property Organization (WIPO) in 2000, World IP Day is celebrated on April 26 to mark the anniversary of the WIPO Convention becoming law in 1970.

The theme for this year’s World IP Day is IP & SMEs: Taking your ideas to market, celebrating the many small and medium-sized enterprises (SMEs) across the world.  There are over 30 million SMEs in the United States alone, and each of these businesses starts with an idea.  Intellectual property is a useful tool that SMEs can use to spur business development and to provide protection to the ideas and innovations that they have worked so hard to develop.  Patents, trademarks, and copyrights may serve as an important source of value for SMEs; however, many SME owners may be unaware that IP protection is available to them or lack the time and resources to address these issues.  The celebration of World Intellectual Property Day seeks to bring attention to the importance of intellectual property and provides an opportunity to raise awareness to how the different tools of the IP system may be used to the advantages of SMEs and all business owners.  For more information from the World Intellectual Property Organization, click here.

If you are interested in learning more about how intellectual property can protect your innovations, please contact one of our attorneys.

The Supreme Court has decided in favor of Google in a copyright case that pitted the software company against Oracle, the owner of the popular Java programming language.  When creating its Android platform for smartphones, Google copied about 11,500 of declaring code from the Java SE application programming interface (API) that allows programmers to use prewritten computing tasks to write their own programs.  The Federal Circuit had found Google guilty of copyright infringement, but the Supreme Court reversed, holding that Google’s copying of the code was fair use.

Declaring code acts as an organizational structure for the programs of the API and serves as a sort of dictionary that gives names to each of these programs.  Underlying implementation code is then used to instruct the computer how to actually execute the task that is called for by the declaring code.  Google wrote its own implementation code, but copied a portion of the Java SE declaring code. Therefore, programmers who were already familiar with the language used for Java would not have to learn a new language for at least some of the programs offered in the Android platform.

Although Google asked for the Supreme Court to decide whether declaring code was even copyrightable, the Court declined to answer this question.  Instead, the Court based its decision on the doctrine of fair use.  Because computer programs always serve a functional purpose, the Court stated that fair use is an important consideration for determining the scope of copyright protection for computer programs.  The declaring code in particular has a functional purpose that is inherently bound together with uncopyrightable ideas and new creative expression.  For this reason, declaring code is further from the core of copyright than other types of computer code, such as the implementing code.

In finding for fair use, the Supreme Court stated that Google’s use of the copied declaring code was transformative, as Android was built for smartphones while Java is typically used for laptops and desktops.  The Court also found that Google’s use was a reimplementation of the Java declaring code.  Google took only what was necessary to allow programmers to use their existing knowledge of Java and to use their talents in a new and transformative platform.

This decision suggests that courts should grant a generous view on fair use to developers of APIs and interoperable computer programs.  To read the entire opinion, click here.

Software is enormously valuable. Of the top 10 largest companies today, only Saudi Aramco and Berkshire Hathaway are not in the software business, but even they could not survive without it. The others – Apple, Microsoft, Amazon, Google, Tencent, Facebook, Tesla, and Alibaba – not only rely on it, but also specialize in it. As the digital revolution continues into the era of expanding data science, machine learning, and artificial intelligence, the value of software continues to increase exponentially. Whether you are a small startup, or one of the tech giants listed above, your software is worth protecting, and giving some thought to the possible pitfalls involved is important.

Copyright protection is enough: It is true that copyright protection for software is a powerful deterrent. A copyright registration is cheap, easy to obtain, does not require a long examination process, and lasts about a century. Best of all, the damages are baked right into the statute meaning you don’t have to show monetary harm to recover up to $150,000 for each unauthorized copy. This is helpful if your source code, training materials, forms, graphics, videos, or other artistic works might be copied by others without your permission. However, copyright protection does not stop competitors from creating their own system that copies what your system does or copies how it works. In other words, others are still free to reverse engineer your system or create a clone that mimics its behavior using their own graphics and source code.

Patent protection isn’t available for my software: Maybe. Software systems that merely solve business problems or replicate common activities that can be performed by a person with a paper and pencil face a tough battle in the Patent Office – in the US or abroad. Software that solves a technical problem, performs a new process that has no manual analog, or controls an existing machine in a novel way has a much better chance of success. It is true that patent protection is relatively expensive to obtain, and is only limited to a 20 year term, and you will have to tell the world how your system works. More detail is better than less, particularly when it comes to describing not only what the system does, but more importantly, how it achieves those results. The value in having an issued patent is that it gives you the option to push back against competitors who have created a system that works like yours. Just having an application on file can be enough to scare off potential competitors.

I’ll just keep it as a trade secret: This is an excellent choice in those situations where the innovation is occurring in house and is never released into the public in any form. For example, if your business model is provided online using a “Software-as-a-Service” (SAAS) model, trade secret protection is a good option. Google enjoys market dominance in the search engine arena because the “secret sauce” in the Google search engine has never been made public, and never will be. The secret never leaves a Google server farm, so the risk of losing it is low. But for any products shipped out the door, the danger of losing control of the secret is very real, because to maintain trade secret protection, the secret has to be kept, well, secret. If the secret is released to the public, is reverse engineered, or is independently developed by others, then you have no recourse. To be effective, trade secret protection must be a central aspect of the corporate cultural. Access to the documents, source code, formulas, manufacturing processes, client lists, or other aspects of the “secret sauce” must be kept secret from the public, and all employees must understand and agree in writing that they have a duty to keep the proprietary information in-house, and that it cannot be disclosed if they leave. Any breach of these protocols can mean the secret is lost, and with it valuable market share.

Many companies use open source software to produce goods and services, and many also actively develop software using open source libraries and modules. Open source software is commonly used for online software services, smart phone apps, downloadable executables, or embedded in the memory chips of physical products. Its use has grown because open source software is easy to obtain, actively maintained by a strong user base, performs well, and best of all, it is free. This makes it an easy choice, especially for young start-up companies trying to preserve precious capital. However, open source software relies on copyright law and built in license agreements to keep it “open”. Confusion about the legal issues involved tends to give rise to a number of misconceptions about open source software.

It’s free – so there are no restrictions to worry about. “Free” in the open source context means free to use within the confines of copyright law and according to the terms of the open source license. Open source license agreements are self-executing which means that a user does not have to click “I accept” when downloading open source code – but the terms of the open source agreement are still binding on the organization. Also, different open source software packages may be subject to different terms. There are currently at least 80 different open source licenses in play, and using multiple open source packages in a large system may mean agreeing to licenses that have conflicting terms. Failure to consider these issues in advance may be crippling. A long development effort could be wasted if the combined product includes open source modules with conflicting license terms that make it impossible to distribute the end product.

Our legal department will handle the licensing issues. Open source licenses are self-executing. That means a software developer who uses the software has already entered into a binding software license regardless of whether the organization has granted that individual the authority to do so. This is true whether the open source modules are used in-house or distributed as part of a product or service. The corporation would likely be required to abide by the license terms, whether or not management was aware of the license. Also, once the open source material is part of the end product or service, the corporation is vulnerable to the threat of termination of the license if the terms of the license are not met. On termination of the license, any later use of the software would infringe the copyright.

It’s a minor software thing, and not that big of a deal. Not true. Discovery that open source software is in use may come at the most inopportune times during a merger or acquisition, when an IPO or venture capital financing deal is in the works, or in litigation. This can leave the organization scrambling to resolve critical issues at the worst times. Finding this out at critical times may cast a negative light on the entire organization and can dramatically change the outcome. For example, when IBM was negotiating to acquire Think Dynamics in 2003, the discovery of open source software that was previously unaccounted for resulted in a reduction in the final offer from $67 million to $46 million.

We didn’t change the open source code, so we have no issues. Maybe. It is true that open source licenses usually require that modifications to the open source software itself must be licensed according to the terms of the original license – meaning they must be freely distributed to anyone who uses the software. Thus, modifying your copy of the open source code to include your proprietary algorithms is generally a bad idea if you want to keep them under wraps. But what if the open source code is unchanged, but it is compiled into a single executable with the proprietary code? What if the open source code and proprietary code are compiled separately and dynamically linked at run time? Does a mere reference to a simple sort routine or hash table algorithm in an open source library put the entire code base under the open source license? The answer is “probably not”, but no one can say for sure, and other specific details about the software could change that outcome. This area is especially gray because the courts have not decided what constitutes a derivative work in the open source context. Some open source licenses clarify things a little, but generally speaking, the full legal ramifications of using open source software alongside proprietary code are still unclear.

The demand for improvements in autonomous technology is accelerating. Memory and processing power has continued to grow exponentially cheaper, but the volume of data to process has exploded making it nearly impossible for traditional data analysis techniques to provide timely and cost effective guidance. Whether the data arrives in real time, or is acquired and stored for later analysis, the need for systems that can generate valuable insights from mountains of raw information will only increase. Consequently, neural network technology is increasingly valuable to organizations large and small making it a prime target for intellectual property protection. However, a number of misconceptions have arisen regarding the patentability of neural network technology.

Software isn’t patentable, so neural nets aren’t either: Software inventions are patentable, but the Patent Office and the Courts have narrowed the scope of what is patentable by requiring that the patent claims must be directed to something more than a well-known or abstract concept implemented on a computer. This is especially interesting where neural networks are involved because in some cases, the network itself is not new. The network topology (i.e. number of nodes, number of layers, the connections between them, etc.) may not be new, and perhaps the activation functions or backpropagation techniques used by the network are also not new. The training data sets or data preprocessing techniques may not be new either, but the outcome of using such a neural network may be truly revolutionary. Thus it is important to plan ahead in the drafting process to include aspects like tangible data sources and physical sensor input/output, control of physical objects or machines, and information about what technical problems are being overcome and how.

I didn’t invent a neural network so this is probably not patentable: Keeping the right focus on the invention is a fundamental issue that sometimes hampers patentability for software inventions, and it can be particularly problematic where neural networks are involved. Is the “magic” in the neural network or is the magic in how that network is used? For example, is the concept a new topology for a neural net that is more efficient, yields better results, or solves a particular problem? Is it a new activation function, or a new type of backpropagation scheme? Is the invention a new gradient descent algorithm that is optimized for a particular problem space? If any of these are the case, then the claims and disclosure should focus more on the network itself and how it is configured. On the other hand, is the invention a system that works better because it uses a neural network? If the invention is an improvement on neural networks, then more details about the network itself will be needed to show the technical problem and solution. If the invention is an improvement in some other field of endeavor that happens to involve a neural network, then more information about the inputs, outputs, and operation of the device will be needed, and perhaps less information about the neural network itself. Determining what the invention is will drive what kind of disclosure is needed in order to obtain a patent.

I’ll file the application but keep the real invention secret: The patent system grants the right to stop others from making, using, or selling patented inventions. In return, inventors are required to teach the world how to make the invention. In the case of neural networks, this can be tricky because many of the details about how a neural net reaches a given result are unknown until it is put to use, or they may be different from one execution to the next, or in some cases they are simply unknowable without extreme effort. In some cases, billions of permutations of inputs, outputs, and the corresponding weights for each node in the network could exist, but only after the network is put to use. That said, trying to patent a concept while keeping it secret is not permitted. The invention must be disclosed in such a way that a person of ordinary skill in the field could make and use the invention. The claims may be allowed to describe inputs and outputs at a high level, but at least some explanation is required as to how the system uses them and how they interact with other components of the system. Usually, more disclosure is better than less because failure to adequately explain the workings of a neural network, or the use of it, may cost both the opportunity to patent the concept, and the opportunity to protect the invention some other way, such as by trying to keep it a trade secret. With a little careful planning, both of these negative outcomes can usually be avoided.

Many times Businesses form and thrive because of a revolutionary product like the smart phone, or because of a new service model like ride sharing. These products and services often include novel processes for solving old problems, or new and useful combinations of existing products. Sometimes no one thought to try it, or perhaps for many years everyone believed it couldn’t be done. Common misconceptions about the patent system can result in missed opportunities to jump-start growth, secure market share, and give a superior business model the chance to dominate the marketplace in the face of strong competition. Following are some “gotchas” related to the patent process that result in missed opportunities.

If I Patent It, I Can Build It: Not necessarily. It is possible to make the product you claim in your patent, and still infringe someone else’s patent. That’s because patents do not grant you the right to make and sell your product or service. Patents only grant you the right to stop others from making or selling your product. For example, Kerri has a patent on a cup, and Joe patents an improvement on the cup by adding a handle. Now Kerri has a patent on cups and Joe has a patent on cups with handles. Before Joe can make and sell cups with handles, he must obtain Kerri’s permission because he cannot make a cup with a handle without first making a cup. Kerri’s patent gives her the right to stop anyone from making cups of any kind, with or without handles.

I’ll Sell It First, Then Patent It Later: The first impulse for many entrepreneurs is to see if the product has market acceptance before proceeding with a patent process that may cost precious startup capital. The U.S. patent system still provides a year to file for patent protection after the first disclosure or offer for sale, but the U.S. system is unique in this regard. Rights can be lost when details are mentioned in public and then left out of the patent application by mistake. Also, any public disclosure means you will not be able to pursue patent protection on the concept anywhere else in the world. While this may be less of a concern to some businesses, it can become a serious obstacle to growth as the business takes off in other countries. With a little careful planning before that first disclosure, entrepreneurs and inventors should establish a road map through the patent system that fits their budget and gives them the best chance of retaining patent rights now that may soon become very valuable.

I’ll Keep My Patent a Secret: The patent system gives inventors the exclusive right to stop others from making, using, or selling their patented invention. In return, inventors are required to teach the world how to make the invention. This way others can study the drawings and description in the issued patent to quickly learn from the inventor and make improvements on the concept sooner, rather than later and thereby advance the overall state of the art more efficiently. Conversely, inventors that try to obtain a patent without disclosing the most important aspects of the invention may cripple their opportunities for obtaining viable patent protection in the U.S. and abroad. Furthermore, this approach may also destroy options for securing IP rights that might otherwise be available such as trade secret protection. Here again, there are several ways to address this issue, all of which are ideally considered early on as part of a cohesive IP strategy – preferably long before valuable IP rights are potentially lost.