Speaker 1  0:00  
Good morning. Good afternoon, everyone. Welcome to software licensing, not your traditional university deal presented by Autumn. My name is Holly Lundgren. I'm autumns online professional development manager. And I'll be your staff host for today. All lines have been muted in order to ensure high quality audio, and today's session is being recorded. If you have a question for Bob Garcin, you We encourage you to use the q&a feature to ask that question rather than the chat feature. If you have a technical question or a comment, please do feel free to use the chat box for that. I would like to take a brief moment to acknowledge and thank autumns 2020. Online Professional Development sponsors, their logos are up on your screen right now. We really appreciate the ongoing support. And now I'll introduce today's speaker. For clients in a wide range of industries. Robert Gerstein prepares negotiates and resolves disputes relating to patent trademark development and other intellectual property agreements, counsels on all aspects of intellectual property and provides legal opinions. In addition to his client counseling and work on transactions and licenses. He's involved in patent, trademark copyright, unfair competition and contract arbitrations, mediations, and litigation. He has prepared numerous legal opinions for clients primarily involved in contract interpretation, patent validity, patent infringement, or patentability. He also conducts due diligence for intellectual property transactions, as well as the intellectual property aspects of mergers, acquisitions and public offerings. Robert has also served as an expert witness on intellectual property transactions. Robert graduated from the University of Michigan Law School Coombe latte, and received his BSC with honors in nuclear engineering from the College of Engineering at the University of Michigan. He has been with Marshall Gerstein since 1988, and a partner since 1995. At this time, I'll turn it over to our distinguished presenter. Welcome, Bob.

Speaker 2  2:14  
Thanks, Holly. Um, let me get my presentation up here.

Speaker 2  2:24  
So we're going to talk about software licensing today. And contrast that with some other types of deals that may be more prevalent in universities. Obviously, there's a wide variation in terms really for every type of licensing. So certainly provisions that you might see in a pharma or biotech license, you may see some of those and in software as well. But there are some significant differences. In our experiences, university licensing is generally more on patented technology. And so the deal terms are skewed towards patented technology as well. A lot of those are, for us anyway, bio and pharma deals, but certainly medical devices and all all types of engineering. And then they can be obviously much different than software licenses as well. And, in general, you know, software licenses have different terms for several different reasons. There are different or at least overlapping types of intellectual property rights as far as patents, trademarks, copyrights, trade secrets, and we'll talk about those. The scope of of exclusivity for software is generally narrower. And that's in part because of the differences in copyright law versus patent law. But even where software is patented, we tend to see narrower ranges of exclusivity or scope. And we'll talk about why that is. There's certainly different risks that are inherent in software businesses than there are, for instance, in biotechnology, and pharmaceuticals, and there are different risks related to the IP as well. Another important factor is that software is constantly evolving, you're not dealing with something static, you are, you know, the software is always being updated, being ported to different types of hardware, there are variety of changes, which you know, other other products have changes as well, but they tend to be more static. So, you really have to plan on on the evolving nature of software. So certainly assumption As for for this presentation, types of software deals we're talking about because they even within software, there's quite a variety we're going to be talking about the university is the licensor, here, it's it's software developed at the University. And we're going to be talking about software that's probably not been fully developed into a commercial product, which is also common for university licensing. It's usually not a completely finished product, but something that's pretty early in the development cycle. We're not talking about mass market software, either when Microsoft or Apple licenses software, those are much more one sided agreements, you're probably going to be negotiating for terms that are more even than, you know, the big mass market software usually has. Probably not going to be dealing with software that the university is going to update and maintain, which is usually very important in software deals. Were in the university context, what we usually see are licenses where there's the university has some software, and it's kind of licensed that but there's not going to be any continuing work, or at least not required to be continuing work by the university. We're going to say that the license is going to want an exclusive license or at least partly exclusive exclusive for a particular field. There, there are certainly many non exclusive licenses in software and other technology. But we're going to assume that they're going to want something that's at least partly exclusive. Talk about the fact that source code is probably going to be included in more commercial software licenses, particularly the more mass market, once source code is usually not included, it's just the object code. So the licensee doesn't have the option to make changes. In most of the cases, that's not going to be the case for a university deal. There's also often going to be data or other libraries that are included, it's it's more than just executable executable code. So one of the reasons that software is different is that it's highly predictable. For those of you who spend time working on licenses licenses in the bio or pharma area, you know that, you know, whatever development you've done on a on a product or the university is done, there's still a lot of uncertainty. You know, the overwhelming majority of therapeutic compounds fail and don't make it to market. In software, that's a little different, when when somebody undertakes a software project, they have something that they want to do, they pretty much know that they're going to be able to get there, they may not have a marketable product that anybody wants to buy, but they should be able to make the software do what they want it to do if they put in enough effort. So that's a that's a significant difference than from a lot of other products. Certainly the biopharma products are at one end of the scale on not being very predictable and you know, more mechanical items or you know, can be but software is certainly on the relatively predictable and can usually be to perform pretty consistently, regardless of the hardware, other products are going to you know often have a very narrow type of use, where software can be can be broad. So significantly more success than with biopharma projects. And, you know, once once something is developed, because it's predictable, it's it's more likely the product is actually going to make it to market what that can mean is that no, where, you know, biopharma deal, there can be a lot on the milestones up front before marketing. That's not as necessary for a university to make something because they're, in most cases the product will be brought to market so patents are not as important in software deals and there's a variety of reasons for that. Most of you know that, you know, without a patent, there's almost no business model in in the therapeutic area. It's just too expensive to bring products to market and some of that is you know, the the failure rate. There's got to be a big investment in many, many products to get one to market and That's that's not the case with software. Copyright and trade secrets usually dominate the valuation and content of a software license. Copyright and trade secrets are, are narrow, as we'll talk about in a minute. But that's a lot of what the value is. And the reason for that is because the the law has always been, or almost always been fairly hostile to software patents. Originally, there was some question whether software could be patented at all. And then the pendulum swung the other way. And it was much easier to patent software. And really, there was us certainly had the bars of whether something was new, and whether it was not obvious. But there were no other real bars to patenting software, then the Supreme Court came down with its Alice decision, and it significantly limited software patent eligibility, and made it much much harder to get a software patents, especially certain kinds of them. Many patents have been and are continuing to be held invalid, because they're, they're not patent eligible. They're they're considered abstract ideas, we spend a lot of time talking about why abstract ideas fits for software. But in any case, that's what the Supreme Court has said. And it's had a dramatic effect on the the validity of software and business method patents, which are related, at least in this type of case law. Until the allowance rates at the patent office have dropped significantly, by more than 50%. Once again, that depends on the actual art unit at the patent office, it's easier to get some inventions through that others. And there is,

Speaker 2  12:10  
at least for many types of software inventions, there is work that that attorneys can do to sort of recraft or reframe the way in which software patent applications are created or the way the claims are stated. But the allowance rate has dropped significantly. And there are some estimates that there are, you know, a million patents that were granted before the Alice decision that would be found invalid today. Many of those just don't get enforced. So they obviously there aren't gonna be cases on all of them. But we see much higher rates of that than we have in the past. So because patents are important, we're relying more on copyrights for software. Copy copyright law is narrower in the sense that it only prohibits copy, you know, with with patents, even if you're not aware of the patent, you're not aware of the patented product, and you've completely independently developed it, you can still be infringing with copyright law, you know, one of the elements you need to prove is that there was copying. So if you have a team that is unaware of the copyrighted work, whether that's software or something else, and they come up with it on their own, that, you know, that is something new. So when you're if you don't have a patent, and you're just licensing the copyrights, the licensee is looking at this from the perspective of well, we don't really have exclusivity here, somebody else can always come up with this themselves. The issue on patents. Alice, when you in the cases where you can get patents, you are you're getting a much narrower, much narrower set of claims on the invention in software. Whereas in the past, you could sort of patent what you were trying to do with the software. And you could talk about it in the sort of functional language, or what the end result was analysis made that harder, you really need to tie the invention to something technological as as opposed to sort of what the software does, and that has had a narrowing effect as well. Therefore, when when a licensee is looking at the value of a software invention, they often think, you know, we can do that ourselves if there isn't a patent on it, and they will take that into to consideration in coming up with the valuation and and think about the effort, they would have to put in what the cost would be for them to independently develop it themselves. But the important thing to think about is that the data rights, which often go along with software can be as valuable or more valuable than the code itself. We see that a lot with artificial intelligence type inventions. Universities also often have datasets that can be used for a variety of purposes, but one of them is for training an artificial intelligence system. And the data, of course, can also be generated independently. That can be more complicated, it depends on the data set. But data may not be truly exclusive either in the sense that it can be independently developed, there's there's not going to be a patent on the on the data itself. So trade secrets are also often important. But independent development is possible their source code is usually a trade secret. If it's confidential, which mostly is so it's the licensee is also going to look at that, yes, you may have come up with some interesting ways of developing the software. And those are secrets. But most of the time, they they'll figure they can do that themselves. So the cost to independent, independently developed is an important factor in what they're willing to pay.

Speaker 2  16:48  
So as far as the content of the license agreement and the license terms, there are going to be some differences in the grant, we're going to have some copyright language. And that includes terms like reproduce, prepare derivative works, distribute copies, rather than the traditional patent language, which is make use so offer for sale import, you may have both, depending on on the situation, and what the licensee wants to do. Derivative Works for those of you who don't know that, that's copyright statute language, not only does a copyright holder control the work that they created, but they also control works that are based upon it, and those are derivative works. So it's, it's not just copying the entire work, but sections of it are also something that can be controlled by the copyright holder holder. So if the source code is confidential, the grant may include trade secret type of language, and which can which can look or overlap quite a bit with with patent language as well. So deliverables, for those of you working, you know, in the biotech and pharma area, there are often material transfer agreements, or aspects of that in the license. In software, the deliverable is usually more about just providing a copy of the software. But in some situations, that can be a little more complicated. And if there's going to be updating that that can be an important term and the deliverable is as well. With copyrights, the term is really effectively unlimited. They depending on whether it's a work for hire, or individual, and you can be expecting that a software copyright is going to live for much, much longer than the usefulness of the software software, you know, turns over every five years, 10 years at the most. So even that is shorter than the term of a patent, which is going to be 20 years from filing with potential extensions for in some cases. So the term of the agreement is usually much shorter than the term of the rights in a software deal. Or the term may be unlimited, but the payment term is going to be shorter. collateral materials, if there are manuals, if there are related documents that are going to help the licensee take the software and build upon it, then those are often included. Not quite the same as tangible materials that you'll see with material transfer agreements, but certainly in the ball apart. Another important thing to remember is that the licensees business model almost certainly will be to license the software not to sell it. It's very rare for software to actually be sold, it's licensed, and there are with limited rights on the end user to use that software. Back can be important when thinking about your next sales definition in the license agreement, and certainly what sub licensing terms are, there will be sub licensing, though, not, not the sub licensing that we usually see in other contexts. So something to think about depending on what the licensee is going to do. So another important area where we we see some differences, where software is in sort of a liability warranty and indemnity sections of the agreement. Now, because the university, you know, doesn't control the ultimate product, whether that is for software or an A biopharma deal, you know, they don't have control. So they really shouldn't have any of the liability for the product. And so, as with other contexts, it would be highly unusual for the university to take on any products liability, or anything like that in in connection with a software invention. It's also unusual for the university to take on non infringement liability. And there are similar reasons. But for one additional reason was software, there are so many aspects of it, that there could be it could be hundreds and hundreds, at least if it's a complex system, hundreds and hundreds of patents, and it's difficult to search or even find all. So you know, it's it's highly unlikely that there's there's really any way to, to provide an indemnity on non infringement is certainly not something that universities want to do anyway. We'll say, however, that because of the nature nature of software patents, the infringement risks are lower, as already talked about, the claims are narrower than we used to see them. So that that helps. And because there are so many potential patents, the the case law has moved in a direction that makes it so that a patent owner isn't able to get damages on the entire product, but only that aspect of the product that would be covered by the patent. So damages tend to be lower than they used to.

Speaker 2  23:19  
Why while patent infringement indemnity is highly unlikely, it's not unreasonable for the licensee to say, Okay, we understand that you don't know all the patents that are out there. But we do want to make sure that this is your work this, this is the work, you know, coming from the university, that the software was actually written there, and that they didn't steal any trade secrets. And, you know, once again, with patents, you can do something entirely into, you know, independently and still be an infringer with copyright and trade secrets. You know, it requires copying of some sort. trade secret misappropriation is in a sense, copying as well. And it is not unfair for a licensee to say, Well, fine, we, we understand the patent issue, but we want to make sure this is actually your original work. There is one big caveat to all that. And that's open source software. In almost every area of software these days, it's pretty common for developers to use the open source software that's, that's out in the world already. And so it's not always the original work or not entirely their original work. And so open source source software creates complications in all areas of software licensing. But the degree to which it's a problem depends on what the specific use of the open source software is. And that's something that university might not know what the, what the ultimate use is. The license type, they're quite, they're really up to hundreds of open source licenses that are out there. And anyone who has a some software that they want to put out into the world as open source can create their own. So you're constantly looking at new licenses, though there are some usual suspects, ones that are more common than others. And then another important factor with open source software is whether it's going to be modified. If you're usually if you're just taking a piece of software, and open source software and using it and not modifying it in any way, open source restrictions aren't aren't very important to companies anyway, those who are actually selling software in the marketplace for licensing software in the marketplace. Usually with open source licenses, it's when you actually transfer or deliver the software that some of the important restrictions or limitations or concerns that a a for profit company will have come into play. So it's, it's less of a concern for universities when the work is staying internally, however, that transfer out of the software to a licensee could trigger some of these open source restrictions. So they can be important. But certainly the most of the business models for software involve transferring or delivering the software to an end user. So they will, the licensee will be concerned about open source software and whether it's included. Not only are there these risks of sort of losing the control, of or ownership, actually not ownership, but control of the software with open source licenses. But there are also disclosure and disclaimer requirements that many open source licenses have. And so the licensees are going to need to know those, even if they don't provide some of the important restrictions on the licensees intellectual property, they they can require more minor obligations like disclosure and disclaimer. And, say open source software is is pervasive in many areas. In some areas, it's it's really impossible to have a product without that, if you're looking to do an iPhone or an Android app, it's pretty difficult to do that without using some open source software. Fortunately, most of the software in those areas is licensed, under under open source licenses that are not very restrictive, not very problematic. But you have to go through them to figure that out. So just a little chart here, you know, you can really think about open source licenses on a scale of very permissive to very restrictive, some of you may be familiar with the MIT license, which is just a paragraph and really has essentially no restrictions. Others have much, you know, much greater restrictions, and they require quite a bit of analysis. Here's a simple chart that you may see in your licensees may have and the way they think about open source software. You know, though the list out we've only got five of them listed here. But to say there, there really are hundreds of them now, and they'll think about you know whether the software first is for internal use, and if if it is, many of the licenses are not problematic. But if they're external, and that means they're going to actually transfer a copy of it, then they have, they may or may not be willing to use those because it touches on their intellectual property. Just briefly, not going to go into all the details on open source licensing terms, but the federal license and there's a few like it is one to watch out for as far as internal use goes. And the federal license doesn't actually require In a transfer the software to create some of these obligations on the part of using it. But if you with a pharaoh if you have a business model of providing software as a service, or maybe just using the software on your website where third parties can interact with it, that allowing the third party to be involved in some way, is enough to create some of these obligations. So once again, mostly internal use is is okay for open source. But not always. And for most university licenses, the business model for the licensee is going to be to provide the software, they're not just going to use it internally. That's not always the case there, there are certainly some deals that we've done where the use is going to be entirely turned internal. But if it if it's a more traditional business model, than they're going to be concerned about any of the external use ones that haven't known.

Speaker 2  31:22  
So far, the liability and warranty and indemnity when you're you're doing a software deal, open source software definitely complicates the picture. And it's not just open source software to it, it is possible it was uploaded to third party software that's used, that they actually paid for. And that can complicate things even more. So there can be quite a bit to do. In sorting that out, what open source software, it provides great cost savings, and often better reliability, because there's a whole community out there that is looking at the software, testing it, updating it, closing off security, vulnerable vulnerabilities. So it's, you know, 10 years ago, and, and even five years ago, I think a lot of companies were more skeptical about open source software, that's really not the case anymore, because of the cost savings and reliability. Many more companies are are willing to look at using open source software, but they're, they're gonna want to do it with their eyes open. And they will, they will dig into the licenses to make sure that they don't cause problems for the business. It's not always possible to know exactly where open source software originated. Or even whether there is open source software, you know, in a broader product, there are services out there that will scan your software, your source code to see if they can find open source software in it. And that's not something that's usually used in a university. But certainly many of the licensees may be doing that.

Speaker 2  33:20  
As noted, not always going to know at the stage, the university is at with a software what the ultimate business model is whether there's going to be a transfer of it. So when doing due diligence, you need to think about the possibilities of the business models. And you know, really dig into these. And there are many custom agreement provisions that may be needed, depending on what the licensee is planning to do.

Speaker 2  34:04  
Software, as we talked about, was a little different issue on liability warranty, indemnity, unlike the BioPharm area, you will see some warranties that the software will work, at least for certain purposes. Because it's a predictable technology that makes that possible. Universities are less likely to include those warranties. It may be just that they provide the software to the potential licensee and they check it out to get comfortable. And that's that's all there is. But if there is some type of warranty in software, it's usually limited. The the remedies are limited to fixing the software return of some of the payments, nothing more than that. And there are usually very short time limits on warranties if they're included at all, because the technology environment is changing. all the time. And it's really not possible. Even if something's working at a certain period of time, even if it's secure in a certain period of time, it may not stay that way.

Speaker 2  35:20  
So ownership is a is another issue. Ownership, many of you are familiar with the ownership issues on patents. They're different for copyrights. And the university intellectual property policies may also differ. We do a lot of work on university IP policies, some of them don't really address copyright issues. Or if they do address them, there, they address them in the ways that are of concern to more traditional academic pursuits, writing scholarly articles, books, papers, the copyright issues there are certainly important, but are different than the copyright issues when we're talking about software. And so the software isn't isn't always included. Or if it isn't included, there are there are different rules, I may be treated more along patent rules, even if there's no patent than the the other types of copyrighted works like books and papers. Some of the policies will indirect address non employees like students, but others may not. And that can be important. Overall, though, universities and other other employers should own the copyrights of their employees, at least for work that is being performed as part of their employment obligations. They're doing something on its on their own time. And as I say, scholarly publications and articles are often carved out of that ownership and are kept by the professor or other employee at the university. The rules for contractors, non non employees like students are really different. under copyright. You will see, in many cases, there's there's language in employment agreements, or in contractor agreements that say that whatever the copyrighted work is, it's it's a work for hire. But under US copyright law, there's really only a limited number of types of works, that can be considered a work for hire. And software is not one of them. That's that's not that's not one of the types of copyrighted works, that can be a work for hire. Now, there are works that are joint and in many cases, software is going to be created by a number of employees, whether it be versity, context or other. And those can be works for hire. So there are exceptions. But it's important, not in the software context, not to just think that Well, we've got work for hire language in our policy or in an agreement. And that's good enough. In many cases, for software copyrights, you need to have an explicit assignment of the copyrighted work. Just as you're you're used to doing in the patent context, although most of the time and in most pop policies today, the more modern phrasing of the policy policies, that ownership in a patented work attaches immediately with the creation of it. That's not the way it's going to be with a copyrighted work. And so you really do need to get an explicit assignment in many cases, particularly if you if one or more of those contributing to the software was not an employee.

Speaker 2  39:20  
So just a couple of other areas to keep in mind about commercial software. Most of these are not issues for universities. But if you want to understand your licensee, you need to think about some of these these issues. There's new most software's traditionally, or today is licensed with a sort of a large upfront payment and then smaller payments of something around, you know, five to 20% for maintenance payments, because the software company is going to be maintaining that software. universities don't usually have maintenance obligations. But you, you may want to think about that in your net sales definition that it's not just going to be sort of one time fee, but there may be payments over time and, and whether those are going to be included as part of your royalty base. Normally, licensee of software gets improvements, they get bug fixes, security patches, and whatever, you know, changes to accommodate new versions. You know, new versions of hardware or other software that it works with. Universities might include improvements to software, but generally they don't have other obligations like updating or bug fixes. But that's an important part of what the licensee will do. In commercial software, licensees are often often not ready for for new versions. And so that's something to think about too, just because a software company that's your licensee puts out additional software doesn't mean that their licensees, their users are going to be ready for it. And VAT can be an important part in many of those fields.

Speaker 2  41:25  
Few other software issues to mention Software as a Service talked about that briefly, regarding the feral license, where your software is a service is where the owner of the software isn't actually providing a copy. They're actually they're running it on their own servers. And the customer, which is sometimes called the licensee is interacting with that software, but they're not actually running it, they don't have a copy. Service Level Agreements are often very important there. And those are basically the licensor or the software companies saying, we're going to have this up 99% of the time, or we're going to have it up, you know, 95% of the time, we're going to have maintenance days on Sundays, or whatever they're going to do. And if we're down more than that, you get some of your money back. So that's an important part of the business model for for many types of software, and can be important to think through when looking at your royalty base and net sales definition. There are disputes under license agreements that you're whether whether this is the license agreement you're going to have with a company where the license agreements they're going to have with their customers. But a lot of that is about the direction and pace of the development. Not the sights of things we normally see disputes of art with university deals like what the licensees diligent scope of the license rights, field definitions, etc. So there are our disputes, but they come up in a little different context and can be important for you to understand when thinking about your licensees business. Security is very important. I think we're used to confidentiality restrictions and a lot of agreements. But the privacy and security issues that you have in sophomore are different and not usually obligations that the university takes on. But it's something to understand, for many software businesses. Contractors are often used for development. So as I talked about, in the context of students and universities, ownership can be less certain. Just mentioned source code escrow in case that that ever comes up. That's not usually part of university deals. Where a company is licensing its software in object code form only. There are often provisions that say, Well, if that company goes out of business, and the licensee, you know, wants to update it there they were, in the past relying on the company to do that. The source code has been put in escrow by a third party is holding on to it. And we'll release that if the if the company goes out of business, or is no longer doing the updating, so escrow not usually a part of university deals because they're usually sharing the source code to start with, but it is something to keep in mind. Just want to talk briefly, because patents aren't as important in this area to talk about trade secrets and other forms of intellectual property that that can be important. universities are not very good at keeping things secret, it's really not part of their mission. They're there to spread knowledge and to publish. So they're, they're often not very good at keeping things a secret. But that'll that's can be very important in a lot of software businesses. Not going to spend a lot of time on this slide. But just to know that there is an analysis that goes on, of comparing patents and trade secrets. And in in some situations, even where the, there is something patentable, companies will, will often make the decision not to patent the software, because they'd rather keep it as a trade secret that's less likely in the university world, if you can get a patent on it. If that's what you're you're going to want to do. It definitely has advantages for the type of licensing that universities do, as opposed to the type of licensing that a software company does, which is just providing object code. So just, you know, search, some of the questions that are asked in determining whether you want to keep something as a trade secret versus a patent in the in the software area, is that a technological invention, once again, that comes from the Alice case, if it's not, then you may not have much that you can patent anyway, if you're really trying to patent sort of what the the out put of the software is, as opposed to actually how it works? Is it possible to keep it something a secret, some inventions and software, by their nature, there is something that the the end user is going to have and see very much on the front end. And those are things you want to patent. If it's on the back end, something that is really sort of on a server side isn't isn't really going to be seen by the user. Those are things that maybe are best to be be kept as a trade secret. Another thing to think about is how easy is it to to reverse engineer, whatever the invention is, as noted earlier, you know, if you have an idea about what the software is supposed to do, most companies in that area will say, Yes, we can create it. And so they can, even if they don't reverse engineer it, they can do it independently. But if they can get your software commercially and take a look at it, they can get a big head start. So if it's if it's easy to reverse engineer and develop independently, then you're more likely to want to try and get a patent on it. And then another issue is, is it really possible to keep it as a trade secret, as noted, universities don't generally do that they publish. And so in many cases, even though there isn't much that it's going to be patentable, some universities decide they're going to file a patent application anyway, because they know there just won't be keeping it secret. I also want to talk a little bit about design patents. And design patents are generally not something that universities spend a lot of time doing. And you may think the appearance of an article now really wouldn't apply all that well, the software. But that's actually not the case, we do see many, many software companies filing design patents. So utility patents, really protect the way an article is used or how it works. Or its method of manufacture even and design patents are purely about appearance. And they're really supposed to be about the ornamental aspect of the appearance. Obviously know if you if you look at a tire, something's about the way a tire appears are really functional. In nature, I mean, it has to be sort of have that round shape to it or it's not going to work as a tire. So, when when looking at something, you're you're really in determining whether or not you want to file for a design patent, you have to sort of isolate out the functional aspects. So in the software area design patents are mostly used for graphic user interfaces, the way that the user interacts with the software on the screen, and what that appearance is, and reason to really look Get that is because design patents can provide additional protection and damages arguments.

Speaker 2  50:08  
So the important thing here is, is that there are infringers profits. Here's a verdict form from an Apple versus Samsung case, which many of you may have seen. And they wrote in over a billion dollars there. And that's because you can really get the profits made using that infringing article. So much more than a reasonable royalty, and you don't have to, and even if you are a patent owner, who has their own profits, and you so you're making a lost profits argument, those are those are hard to do. But getting the infringers profits can often be much more valuable. So in those rare instances, you know, where the university has come up with something, there can be a lot of money, something that's ornamental, there can be a lot of money at stake. So here's an example of a design patent are actually two different ones, the one on the left, only has one embodiment. And the appearance there is with that middle tile sort of off at an angle, but you could also patent along the lines on the on the other side, where that that tile is angled, you know, from very similar to what you see on the left side to one that's at a sharper angle, and then one, it's one that straight on. And those different embodiments can provide different scope of protection. So if you do have a graphic user interface, if there is something slick, that has been come up with, you need to think very carefully about how to pass on that. Here's another one that has been patented. And should note that the dashed lines here are are not considered part of the design. So it's only the part that is in a hard outline. So this was this is one that was actually patented by Mark Zuckerberg. And when you look at this, what's what's really left is essentially looks pretty close to a blank sheet of paper. But that's what they got a design patent on. And and that's, you know, that's the basic screen for for Facebook, but it looks it's quite broad. And if it's new, then it's patentable. So it is something to consider, in I'll say, a rare number of cases. But it is, it is certainly there. And we'll go through these screens since Holly already talked about us. But I guess we can open it up for questions. Now, Holly, I don't know if we have any questions. But we do.

Speaker 1  53:05  
We've got several questions, actually. So that is good news. Okay, let's start here. Would I be correct in assuming that if you owned and used Matlab to develop a product that if you wanted to use kimono components of MATLAB, when you sell the product, that you would have to pay a fee to MathWorks, the company that sells MATLAB?

Speaker 2  53:30  
So I'm not I'm not familiar with MATLAB specifically. But yes, that sounds like that's probably the case. It may be. So when we talk about products like that, it's often useful to think about tools and components. So tools, they're often toolkits that help you build software. And then, and it's your not. And then there are components, which are sort of chunks of software that you can put in. And it really depends on, you know, the product that you've created using something like MATLAB, whether you actually are putting the components in there, or you're just using the tool to help design the product yourself. And then for the components that you're putting in there. The next analysis is well, is that a MATLAB own component? Or is it an open source component? Because it very well may be, but assuming you have components that are actually going in there, then yes, you're the I'm sure the MATLAB license agreement, you know, talks about that, and whether they are, in some cases, people who put out products that are that are designed to help you create software, they already have some licensing provisions in them for moving it down the line. So it may be in the agreement, but in any event, it's likely that you'd have to pay something

Speaker 1  54:58  
great. Thank you. Um, okay, next question, have software copyrights been useful for protecting IP as opposed to patents, because software can pretty easily be rewritten to provide the same benefit but not infringe a copyright?

Speaker 2  55:15  
Yes, I mean, once again, it depends on how easy it is for someone to, to do it themselves. If you're looking at, you know, a product like Windows, which is got, you know, many, you know, tons and tons of code that's written on it, it would take somebody years and years of time to recreate that. And so, just the putting aside any patents that Microsoft would have on Windows, just the the copyright alone, so that somebody can't just, you know, grab a copy, used to come on discs, but not, you know, get a downloaded copy and, and make that and put it onto another machine. That's something that's protected by copyright. And so it is quite valuable. It has, it has its limitations as well. But no, copyright is still valuable, just not as valuable is if you can get a nice broad patent on it.

Speaker 1  56:21  
Thank you. Okay, um, next up we have for academic institutions licensing software, we typically don't represent that it is entirely original. If we wanted to be able to do that with the OSS caveat, could you recommend programs that we can run it through to catch incorporation of any non OSS that was incorporated?

Speaker 2  56:43  
Any any non Oss? I don't know about that. I mean, I know there, there are products like black dock, that you can run your software through to find out whether there is open source software. I don't know if there are products out there that are looking for proprietary software as well. I have I haven't heard of that. But I could, I could see how it could be done. But the No, I'm not aware of that.

Speaker 1  57:16  
Okay, thank you. Um, let's see, this may be just something to comment on. But when you apply for software patent, if the patent is not granted, it will be published the idea so it becomes public. With high odds, it will not be allowed trade secret is much more viable. It's more of a common. Do you have any? Yeah,

Speaker 2  57:39  
I would, I would. I would agree with that. But once again, it depends on the invention. I mean, you know, we are seeing, we're still seeing quite a bit of success getting software patents, even if they're, even if it's down 50%, that still means 50% are are being allowed. And there, there are ways to craft it. So I would say that, like all these decisions, there is a risk. If you're just going to apply for a US patent, you're not you're not going to file a PCT you're not going to find a file, and you think there is a substantial chance that you're not going to be able to get it you can file a non publication request with the patent office. So it won't become public unless it issues. So that is another way to work around some of that problem anyway.

Speaker 1  58:35  
Great, thank you. Could you comment on whether improvements in OSS are patentable?

Speaker 2  58:44  
Yes, they definitely can be no question about that. The the issue there is that if you many open source licenses, if you if you are using the software to create that improvement, you might be licensing your, your patents to anybody who wants to use your improvement. So that's a complicated question. And it depends very much on the license. So you really want to do make a very careful analysis of that. But yes, in general, you know, just as making improvement on any other kind of software that's out of the public can be patentable, you can certainly get a patent on an improvement open source software as well.

Speaker 1  59:34  
Thank you. Um, you mentioned that some companies have software that they run through, they run their new code through, but usually academics don't. Could you name some of those? Yeah,

Speaker 2  59:47  
so black duck, I think is one I mentioned before that's, that's the most popular one. There are some other ones that I understand are out there too.

Speaker 1  59:56  
Yep. Let's see can Anyone read a published manuscript which describes the steps, algorithm algorithms, but without access to the code of the software and didn't independently recreate the same software? Would that be an infringement?

Speaker 2  1:00:15  
It would not be an infringement of copyright. It might be if there is a patent on on that software. And in many cases, a patent sort of looks like that it's an explanation of the algorithm and the flowchart then, you know, it gets patented, would not be able to do that. But if there's no patent, then that probably would not be copyright infringement.

Speaker 1  1:00:42  
Great, thank you. Um, let's see. Looks like we just have one last question. Um, let's see, are you seeing many AI related licenses? And how do they differ from other kinds of deals?

Speaker 2  1:00:57  
We are seeing some and talked about a little bit, you know, the, there are certainly, there's patents out there. And, and, and certainly copyrights on code for AI. But what we see with a lot of universities, while we do see some that are doing that, what we see more often is that they have a dataset that they want to license, and they, you know, they it's, it's a dataset involving, you know, 1000s of patients with a particular disease, and they want to run that through, or a biotech or pharma company wants those datasets to do to mine it for potential information, and or for training, their software. And we do see some of those, I think the question on that is, many of the owners of that data are trying to license it. Thinking of it as a think of it as they wouldn't invention. And that the outcome of using that set using that data set, they try and reach through to whatever the product is. And I think a lot of licensees on the other hand, think of it more as a tool, you know, they think of it is well, this is this is a think of this data set, like I would think of a microscope, and I don't pay a royalty on my end product to the microscope manufacturer, I just buy the microscope. So I think a lot of what you're seeing now shaking out in in the AI world, particularly where universities are participating in it is what what's the actual model for the license? And your it hasn't really been worked out yet. And it depends very much on the type of data as well. So we are we are seeing so.

Speaker 1  1:02:54  
Great, thank you. Looks like that's all the questions we have right now. Did you have any parting thoughts or comments? Oh,

Speaker 2  1:03:03  
no, not really. But I'm easy to find if if anyone has any follow up questions and the happy to help if I can. Great.

Speaker 1  1:03:10  
Thank you so much. I'm on behalf of autumn. I want to thank you, Bob for this great discussion. And I want to thank everybody who attended today, we hope you got some really good information out of this. Just a reminder, a recording of this webinar will be available for viewing within just a few days, you can access that either in the autumn Learning Center, or in the my Autumn section of the website. That'll be posted. Probably by tomorrow, but definitely by Monday morning. If you have any trouble accessing that, please feel free to reach out to me and I'll make sure you get that access. You can also visit the autumn website to view a record any past webinars that you might have missed. When you close out of this window, a webinar evaluation is going to pop up. Please take the time to fill that out. That really helps us out. And with that I'm going to go ahead and conclude our program for today. Thanks for joining us. Thanks for your time, Bob and everyone have a wonderful afternoon. Thank you

Transcribed by https://otter.ai