 Hello, everybody, and welcome to our next EDW session called Joining Law and Data and You, which is presented by William Tannenbaum, who is a partner at Moses and Singer LLP. All audience members are muted during these sessions, so please submit your questions in the Q&A window on the right-hand side of the screen, and our speaker will respond to as many of them as possible at the end of our talk. We also want to note that there is a linked form at the bottom of the page where audience members are able to leave evaluations for the session, and we really encourage you to do that. It's very useful. So let's go ahead and get started. Thank you and welcome, William. Well, thank you very much for the introduction, and it's a pleasure to be here. I've been at both virtual and live conferences, and I think this one has gone quite well so far, virtually. I'm a lawyer as the LLP in my company name indicates, and our firm has a dedicated data practice where we do everything from privacy and cybersecurity and data agreements up to securing rights and building data centers. And the presentation I'm going to have is not a legal presentation, but it's a presentation about law and a presentation about where certain steps should be followed in order to achieve compliance. So I'm going to go to the next slide, and we've all heard of privacy by design and security by design. And as you all know, that is to build in privacy and security rather than to try and retrofit them. And one of the things I'm going to address is regulatory compliance by design. And that follows the same model, that it needs to be done upfront. There are some steps about doing it both legally and practically, which I'm going to address. And as with the other two items, it's very, very difficult to retrofit it. And it's definitely a budget buster if you try and do it that way. And it'll create, let's just say, controversy with the IT department and all kinds of things, which in the end reflect poorly on a lot of people who are involved. So in addition to talking about regulatory compliance, I'm going to illustrate some of these issues by using examples from health care, which is a very data heavy industry. And I'm also going to address some of the hidden data management and data management requirements behind a new privacy law in California called the California Privacy Rights Act. If you remember GDPR and loved it, you will love the new California law. And I'll get into that later. And then I'm going to address a question which always comes up, which is what is the IP status and ownership issues with respect to data? And what do we do about them both offensively and defensively? So let me start on this slide by discussing the business context that I see and provide this is kind of a window into how law departments look at the problem. Because I'm sometimes retained by the data professionals and sometimes by the law departments who don't understand the role of data professionals or the role of data or all kinds of things because this is not something you learn in law school and it's not something you learn as a baby lawyer. So we go back to kind of the basics as to why data is important. And I think if you heard John Levy's presentation yesterday when he said the definition of data is something that happened. And I found that a very kind of clarifying statement. And to the extent that it's a corporate asset, it is taking that knowledge. And I'm not going to debate the difference between data and information and knowledge and all that kind of stuff. If you have data, then you want to use it to generate a competitive advantage, perform business intelligence, have high quality data so you can trust machine learning models. And then as I said before, you have to allocate IP ownership, license rights, and use rights. The law department with the help of data professionals is responsible for regulatory compliance. It is often out of the loop because things don't get brought to its attention until late in the game. Its goal is to protect the company against fines, the regulatory sanctions, private lawsuits, such as class actions, and other legal penalties. And one of the ways it does this is by confirming that even if something went wrong, the company took the proper steps at the proper time and that there were good internal corporate practices. And that will help withstand an investigation by a regulatory body or a lawsuit. It's also an intra-company, multi-party problem in that there are different company divisions having different expectations and themselves being different sources of data. And the repository entity might not have any familiarity with the regulatory requirements. But the data that it collects is being repurposed for another purpose. And that's where a lot of problems come up. I'm gonna focus on data flow charts because I often see this in my practice is how the problem gets presented internally and how it gets presented to the law department. And then with the law department is looking at these things and trying to decide what to do. So as I go through the presentation, I think you'll understand why this is a good way to approach how the problem is done. I'm speaking to you as data professionals who ultimately are going to have to work with or have your work worked on by the general counsel's office and I wanna give you a sense of how they see the world so that you can help the company by helping meet that perspective. So here are some common problems that I've seen. Someone in the company, often the engineers who are in charge of product development prepare flow charts. And these are often focused on whether certain documents should be put in corporate applications when approvals are needed, escalation steps and all kinds of things like that. And a common problem is when you look at these charts, there's no real step after determining what regulations apply. And the regulations can apply either to the product itself that's developed or steps that have to be followed so that the product development complies with the regulatory steps. And to put some meat on that bone, that's very apparent in healthcare and financial services and other data-driven products where the end result might be, a pretty plain vanilla product or service, but how it was built depends on regulatory compliance. Another issue that I see when working with these charts is if they include this step, it is often too far down the chain and that's not timely and it has some aspects of retrofitting rather than building it in from the beginning. Another thing that I see is in the next bullet point, which is that there is no time to set realistic expectations, to negotiate with the outside company or for the internal lawyers to get the advice they need either from within the company or from their external lawyers. And law just sometimes it goes really quickly, sometimes it takes a long time and to set expectations, you have to build in a block of time there and there you should be guided by company practices, but the most important part is to make sure you understand that there is time for the other side to disagree with your contract or your company's contract and what to do about it. And then as I said before, but it's worth repeating the department that is collecting and using the data, which is in turn going to be shared with another part of the company is just sharing data without knowing what the regulatory requirements are for the downstream use. And that's precisely the problem that we're addressing. So what are the solutions here? You need to identify the regulatory requirements and put the branches for action in the chart depending on the requirements that are proper. Put them in early, allow time to commit to a realistic timeline and check to make sure that the timing makes sense because lawyers have their own pressures and you just have to know what they're going to do to give them time to line up the resources they need to do. As I said before, it might be internal or external legal counsel that are involved with this and we have to indicate where legal needs to be involved which is usually at the beginning with regulatory compliance. And in addition to legal, there are other departments. There's usually the regulatory sometimes called the compliance department and there's usually a privacy officer in the privacy department that may or may not be implicated depending on the data that's being used. So now let's turn to healthcare as an example. And as I said, the problems that healthcare faces are that there is a strong need to use data and data quickly and actually COVID has accelerated all this because what I've seen is hospitals who were slow to update their data management processes or slow to roll out and deploy mobile applications and things like that move very quickly to free up doctors so that they could be providing care to COVID patients and using technology and data more quickly to free up the doctors to do that. And that applies I think to a lot of companies and is another parenthetical on the parenthetical. I think one of the effects of COVID will be to increase automation whether it's robotic process automation or other similar things. That in turn, whether it's a smart chat bot or something else like that requires good data practices. So as I've said before, these are the same problems that I've just mentioned and they're just more time sensitive because HIPAA has very severe requirements on what you can and cannot do with data. And the reason that I'm pointing this out is if you wanna have complete freedom of use of data and healthcare at the end of the day you wanna have de-identified data. And one of the problems that comes up that I'll mention because it applies here in other industries is that if you're using data for research purposes, it takes the form of a safe harbor where the regulatory requirements are less strict. However, if you have designed your program for meeting the research requirement and the research exceptions actually, then when you expand beyond that product development or product deployment, you've gone way beyond what the regulations allow and that is a problem for everyone up and down the chain. So at this point, I'd like to kind of show in addition to a flow chart, I've done my best but I realized this may be hard to read on a screen in a virtual presentation but it basically shows the steps that should be included in the process chart that I mentioned. So I'll just read this very quickly in case you can't. On the left side we say is personal information associated with material to be received and the answer is usually yes. So then the question is whether the site and site usually is a hospital or a research institution will de-identify the materials before they transfer them. And if the site won't de-identify them, then who will? And then to figure out how to answer these questions is very useful to have a personal information questionnaire filled out that non-lawyers can look at and generate the information the lawyers need to know. And then over on the right side, we have a column and the top box says when you've answered the questions about de-identification, then you proceed to contracting. And then that goes down to the bottom when you've done all your investigations. The question is, do you have the right level of consents? And it's all that hippo forms that we all sign when we go to the hospital. And then if you have the consents, do you go to de-identification? Without getting into the weeds in HIPAA too much, HIPAA obviously protects identifiable information. And if you take away the identifiable information, then you no longer have identifiable information and there is nothing for HIPAA to protect because there's no information being transferred. So in most kind of industrial uses of healthcare data, the golden standard is to have it not subject to regulatory limitations. And since this is not a healthcare presentation, I'm not going to go into how you do get it de-identified, but there are steps to do it. And the reason for outwinding this is that complicated and you have to build in those steps in order to get to that end result. Now let me turn to the California Privacy Law. And this was enacted as part of the election that took place by proposition. And it's called the California Privacy Rights and Enforcement Act of 2020. It has its own acronym and it expands on and in many ways attempts to close some of the loopholes and fix up what was in CCPA. It is a little bit unclear right now as to what is going to exactly be required. So I want to be upfront about that. It's going to be effective in 2023. And during that time we expect that the state will issue some regulations and provide some guidance, particularly as to the rights to individual consumers. So we want to focus on that. But we're finding clients very interested in beginning their planning now because they've had the GDPR experience of finding out that it was very hard to build the underlying technology infrastructure to support GDPR. It was hard to put the processes into place and it was hard to use the data, I'm going to say structure in a very loose sense, but to be able to retrieve from databases information that consumers were either able to request or request that the company apt upon. So at a high level this legislation does fortify and enhance consumer rights to their own data. It expands the obligations that companies have with respect to the data they collect in the ordinary course of business. And most significantly this legislation establishes the first state privacy protection agency in the US. So for those of you who are familiar with GDPR this is like a data authority. And since it doesn't exist and hasn't done anything yet I can't give you more guidance but its purpose is to promulgate the regulations and protect consumer privacy rights. So it will act in a way similar to the GDPR. At this point I want to take a break and tell you that there are other similar state laws that are on the books or in the process of being reviewed and analyzed and there's one in Virginia. You may be familiar with the one in Illinois that restricts the use of biometric information. There's one in Massachusetts. So we're in the problem now of having different states have different requirements that overlap. So from a data management point of view the issue is really kind of what's the common highest denominator and how are you able to build that in? And my cautionary note today is to let you know that there will be more of these coming. And it's your job to figure out how to be flexible enough to allow the access and sorting of data that's necessary. But this is something that because it's a regulation company, companies can't avoid it and they need to comply with it. I'll state that the requirement is that the company does business in California. So there are very few companies in the United States that don't do business in California. So in effect, it has national implications and imposes requirements on companies doing business nationwide. So what does the law give consumers that implicate data practices? One, they have the right to get information about how their personal information is collected, how it's used and what the company's disclosure practices are. There are special rules and rights on sensitive personal information which has must the same definition that it does under GDPR. And the consumer has the right to know and the company has an obligation to inform the purposes for which personal information is used and the particular purposes for which sensitive personal information is used. And that includes how it's collected and used whether it's going to be sold or shared with third parties how long it's going to be retained. And I just mentioned this to have a flavor of the scope of what people are going to be dealing with. You have to disclose if there's some financial incentive to get your data and that will be a very interesting aspect of this law. Okay, so this sets the scene now for what companies have to do to change their practice and what customers have the right to get from the company with respect to their personal information. And from my point of view as a lawyer this means you have to have the right technology infrastructure in place and you have to have the right practices in place so that the data is assembled in a way that can be responsive to these consumer rights that can be exercised. Let's talk about sensitive personal information. A consumer has a right to limit the company's collection of the sensitive personal information. Since it's law there's always a qualifier here it's but only sensitive personal information that's collected or processed for the purpose of inferring characteristics about a consumer. As a lawyer I can tell you we sort of know what that means, right? You wanna know gender, socioeconomic status, things like that. But what's a characteristic about a consumer that will be the subject of a lot of law going forward. And then the consumer has the right to limit the company's collection such that it's used only when it's necessary to perform services or provide the goods and services that an average consumer would expect when signing up to receive the average goods and services. So that's kind of a new layer and a new category for the use of personal information. And there'll be regulations that will automate, I'm sorry, that will address the fact that automated decision making is here. And the law says that there'll be new regulations governing how you access and opt out with respect to a company's use of automated decision making technology, including profiling. So the reason I'm discussing this is precisely because if someone wants to opt out there has to be a mechanism that allows that to take place. And there has to be a good mechanism because automated decision making technology, it's probably hard to find some step that is an automated decision making technology. Who knows if a smart chatbot is going to be considered to be an automated decision making technology function. It's certainly directed to whether certain people qualify for certain credit cards or certain mortgage rates and things like that. So now we have this problem of consumers having the right to opt out of something that doesn't have any definition to it yet. And again, I wanna emphasize that you have to anticipate this to the extent that you can make sure that you can opt out from whatever automated decision making turns out to be. And probably the easiest way to view that is you have the right to just enable an opt out kind of without respect to exactly triggers that opt outright. So what do we need to do at this stage? We all have data. It's all situated in certain repositories and organized for certain purposes. So now is the time to take steps to minimize effort and cost and not do this as a huge fire drill in 2022. So now is the time to kind of audit and make some decisions on categorizing data to review databases and probably remove sensitive personal information that's not needed that was collected in the ordinary course back before the statute was enabled. I always say the thing that helps is to add less data which is to take away data that presents risk greater than it prevents benefit. So this is also kind of data minimization which can lead to cost savings. Now we look kind of upstream where you have to coordinate with the rest of the business on the marketing and business to business contracts. There's a concept here of sharing data under the new legislation versus the old legislation selling data. So that means selling data was in exchange for value sharing data is not necessarily in exchange for a payment but it's probably in exchange for some other benefit. So we're gonna have to see what that is. There is a huge impact on digital advertising which again is outside the scope of this presentation but it's hard to find advertising programs do not have digital advertising components to it. What do I think needs to be done that's not directly part of data management? I think it's important to update contracts with your service providers and this may be more of an IT function than a data function. So to the extent that it's an IT function you wanna make sure that two things are happening. One that third party IT service providers support the IT necessary to take the actions required to respond to consumer rights under the new statute. And if they are data aggregators or sources of data then you have the sensitive data problem and you need to know what is in there that you're acquiring. And finally people will probably call on you from your company to help you update their websites because a lot of this information that I've dealt with at a high level has to be disclosed on a website. And here is where you can contribute because how you describe that functionality will have legal importance and this should be done by people who, I'm sorry, this should be done with people who have a knowledge of data and how it is used and how it's collected and shared. Another point is that covered businesses and covered businesses is the statutory term for basically companies that are subject to the registration to the legislation and they have to implement what are called reasonable security procedures and practices that are appropriate to protecting the personal information from unauthorized access use modification, et cetera. So here again, knowing that there's an IT practice that has to be in place to protect unauthorized use and access is unauthorized use and access of what and the what is the data and how it's set up is what enables the IT to do the IT functionality. So to summarize the new statute, it's important to think of it and how it fits into the context of digitization and digital transformation and how it fits into corporate initiatives for data mining and business intelligence and to bring better data science and better data management to the data that the company has. And as I've mentioned several times, but want to emphasize building in regulatory compliance upfront is better than retrofitting. And if you do this, then the activities of a marketing function, whether it's direct mail or chat bots or any other kind of business customer in a relationship will avoid having someone stray into an area that violates what the statute requires in the form of customer protection. And other points to mention are, as I said, reducing the amount of data so that you are not having data that's not useful but does present risk and liability and then making a hard dive into how long you keep data given the data lifecycle and its utility is important. And there's a protection here against data breach liability. Children's data is subject to different rules and there's other liability that attaches to sensitive data. You may be called on to help when there is a regulatory investigation to be, I think, practically, to practically address this. Some of these investigations generate good headlines but there is smoke without fire. But in any event, these are corporate activities. They're gonna require showing that the company tried to do the right thing for the right reasons. And even if it was a little bit off and it's achieving those goals, it was trying to do the right thing. And usually that works with regulators. Now, let me turn to intellectual property. And this is an issue that comes up all the time and I'm sure with other data lawyers as well. Because people ask, can I own the data? And if I own the data, what offensive rights do I have in it and what defensive rights do I have in it? And there are three basic intellectual property regimes that are relevant to this point. The first is copyright, the second is patent, and the third is trade secrets. The other intellectual property regime is trademarked but that really doesn't really apply. So this is really important in two contexts. One is in the context of machine learning and what is proprietary and what can be shared. And the other is in the context of if you're trying to treat data as a monetizable commercial asset, how do you turn it into something with proprietary status so that you can in fact be able to use it for that purpose. So let's start with a data element. An individual data like today is April 21st is not something that standing alone is protectable by copyright. So now we move on to databases. So a database is a collection of data, at least as the copyright sees it and the copyright law causes a compilation. And how do you protect the database? This is a deceptively difficult question. The law requires that the database have something special in the way that the data is organized. There's a Supreme Court case that says taking names and alphabetizing them, however beneficial that is to making a phone book doesn't have the necessary requirements of a special effort to warrant copyright protection. So that means if you have a database and it doesn't have any special structure to it, it's just kind of an obvious way in which to load the data, then you don't have copyrightable subject matter. And if you don't have copyrightable subject matter, you don't have a protectable database. So you now basically have an open source database. If you then sort the data in a certain way, then to the extent that you're introducing more originality, more structure and sequence and more specificity into the organization of the database, then you start to approach copyright status. And copyright status gives you the right to protect it and copyright gives you the right to control copying of it, distributing it, using it, making derivative works of it, publishing it and things of that nature that you can probably draw in your experience and you're already familiar with that. So if you can get the copyright status, then you have a legal basis to protect the database. Trade secret is the other regime that applies and trade secret doesn't require the special organizational qualities in the database that copyright requires. It requires that you keep the database a secret. So that's good if you are using it for internal purposes only or at least using the database for internal purposes only. When you get to big data and data analytics, I think the point of both of those is to generate an actionable insight and the insight is separate from the database. So having an insight and doing something with the insight whether it turns into a business practice or not is a good thing in and of itself but it doesn't affect the underlying database. So that's a way to keep it a secret even if it's not copyrightable. And then the insight itself can't be protectable and I'll come back to that in a moment. The big issue we're starting to face now is in machine learning where machines, whether in pure machine learning or in deep learning are starting to create their own databases. So now the machine really the algorithm is starting to reorganize the data into different formats and different forms of organization. So that's a good thing because it increases the copyrightable attributes of it. And let me stop for a second and mention something I should have mentioned earlier which is if you have a database and you meet the threshold for copyrightability through those attributes, the more you refine it and the more you make derivative works of it, the more likely they are to have that specialized quality to it and therefore the more likely the derivative works are to be copyrightable even if the initial work was not. So now let me turn back to the point I was making about databases created by machines. So we run into the copyright law question which is does a copyrightable work and work is a term of art in copyright, does the work have to be created by a human being in order to be eligible for copyright protection? And the black and white answer is yes. So now we have a question of well, what happens when the machine creates the database? And in the early phases of this, you can say that a human being created the algorithm and the software created by the algorithm did certain functions. So you can trace back those machine derived derivative works to the software that was created by a human being and therefore probably meets the qualification of having a human created copyrightable work. At a certain point, however, the connection between the algorithm created by the human being and the algorithm refined through machine learning and deep learning is gonna be too attenuated and you're not gonna be able to establish with the legal certainty where the human creation fits within this. So this will be an issue to put it mildly. I think the inclination of the copyright office will say, well, this just can't be free. There has to be some connection that we can use to protect it. And then there's going to be all the end users of this data who say no human creation, no copyrightable authorship, therefore it's open and I can use it without infringing copyrights. And the irony of this is that the databases that will be subject to this analysis are precisely those that have these, specialized organizational schemes that are the result of a very, very good data science. So that takes care of the copyright analysis. Let me now turn and I've addressed the trade secret analysis. Let me now turn to patents just to cover that up. So the way to view a patent in layman's terms is that a patent is a contract with the government and the contract is as follows. The government gives the patent owner a 20 year right of a monopoly in exchange for the following bargain. At the end of the 20 year period, the patentable invention is now open for use by anyone. And you can't get a patent unless the patent provides enough instruction for somebody in year 21 to be able to do what the patent covers. Where do patents fit into the machine learning world? Well, software can be both copyrighted and patented. And there are very tricky legal questions that I think are, I'm glad to answer offline if you would like, but they're not really data professional questions. So the answer is, is that the algorithms can be protected by patents and also by copyright and at the same time. And patent is very strong protection but it requires government examination and issuance. Copyright is weaker protection but it doesn't require that the government examine and issue the copyright. If your second grader creates, when artwork by finger painting, that's probably enough to be copyrightable and you just can file it and get a copyright registration with the copyright office. So we're in this land right now whether you have to decide whether the software is patentable and or copyrightable and just to add one more layer to this, the copyrightable elements may be different from the patentable elements and the patent inventor may be a different person than the patent inventor may be different than the author for copyright purposes. And this is relevant when you have joint works developed by different companies. And I'm just mentioning this because this is going to hit you when databases start being subject to intellectual property protection and more importantly, disputes. So I have a question come in I'm just gonna scan it and read it and address it. It says, can a database collected from data collected through a copyrighted instrument, test, et cetera, be copyrighted? The answer is yes, depending on whether the instrument that is referred to in the question is itself copyrightable, in which case creating a database from a copyrighted database would be a derivative and infringing work. So if the questioner would like to elaborate on that, I'll address that. And then it goes, what if the instrument is trademarked? I don't know what instrument means, but it doesn't matter. Trademark is a name that associates a product or service with a source of origin and it has nothing to do with whether something is copyrightable or not. So the short answer to that is you can have a database and you can trademark it even if it's not copyright protected. So please feel free to amplify that question so I can address it more. I've come now to what I think is the key issue in today's world, which is it's very difficult as a lawyer to negotiate an agreement over who owns what data. And the reason for that is no one knows exactly what the scope of ownership of data is. Many people who are involved in this on both the legal and the business side are afraid to give up ownership because they don't know what ownership is and they don't know what they're giving up and having a fight over whether they own it or not tends to go in circles because people are not willing to take the position that they don't own it for the same reason. They don't know if they're waiving a right that they already have. So if we take one step back, what are we really talking about in most terms? We're talking mostly about data use rights and the right to share data. I had a situation once where I was recommending, I'm sorry, I was advising a company that had turned a charter aircraft into a network, into a hub and I collected all the data and then sent all the data back to the charter operator. So the charter operator could decide when to schedule maintenance and how to coordinate the logistics of getting a plane to the base to perform the maintenance at the right time. And the issue that we faced was all parties involved in all components of the aircraft were claiming ownership in all the data. Because the data contained information about hours of flight. So that's the airframe people and hours of engine operation. So that's the engine owner or the engine we saw. And then you have all the telemetry and all that stuff. So for those reasons I said, we couldn't really solve the problem of ownership because everybody claimed they own what everybody else claimed they own. The solution that I use was to say, okay, we are not gonna have a fight about who owns what. We are just gonna say whatever you own, you are now granting me a license. And I can use the license to take this data, combine it with other data, send it to the charter operator and the charter operator can repair the plane before it crashes. And that was a way to kind of avoid the problem. But that has a certain limitation because that fits only within kind of a one snapshot in time set of use. So I have been working with Gwen Thomas from the International Finance Corporation which is the private arm of the World Bank and she's a member of the diversity to develop this new paradigm that we're calling decision rights. And decision rights I think is a very interesting solution and Gwen deserves a lot of credit for kind of thinking about it in this way. So taking the data professional's view of decision rights and put it into a legal paradigm, you end up with the following. You end up saying, okay, we have a bunch of data. We're going to share it. The person who wants to be the recipient of the sharing is the person who wants to be able to do something to make the data operational. And to make the data operational, they need to take it, gain some insights from it and make a decision. So now we go right to the end point which is let's make a decision based on the data that we have and then the decision will lead to an action and then we have accomplished a business result. So as a lawyer, if we take this concept of decision rights, then we're refining the concept of licensing and saying you have the right to use the data to make certain decision rights. So let's be absurd about this. Let's say you can take the decision rights and in my airplane hypothetical, you can decide how many times the plane can take off and land before it has routine maintenance on the landing gear. And that's all you can do with the data. You can use the data to make that decision. And it therefore says you can't use this data for any other purpose and you can't do onward sales of the data to third parties who can do it with other purposes. An advantage to this paradigm that I see is it allows a company to control its data rights by putting them in what lawyers or at least what patent lawyers call a field of use. So in that example, the field of use is number of landings and takeoffs. And that means that the same data can be licensed for a different field of use to a different entity without having there be a fight about the data was already licensed and no one really knew the scope of lights because I just granted a license to use it. Now the benefit of decision rights is the people making the decisions can also be limited so that you're kind of protecting the dissemination of the data. And you deal with the onward problem of, okay, the license was granted, the decision makers made the decision within their scope of authority. And now that data is gonna be given to someone else for them to make another decision. So from a legal point of view, it is easier to structure this chain of rights as a set of rights because rights, it sounds like and it is a legal construct and that's what contracts do. They give people rights to do something else. So I think the virtue of this paradigm now is that we're being able to look at data as a set of actionable activities. And we are defining its use in terms of what can be done with it and in advance deciding how to narrowly define that. Now, of course, no one has to be as narrow as the examples I've just given. But I think it's important to realize that as a lawyer looking at this problem, where ownership is both a messy legal concept and practically very hard to get a deal done when you're sitting across the table or even within a company trying to decide who has control over what databases. Dividing it into this more bite-sized piece with something that the law deals with very well, I think is a good way to accomplish what we're trying to do in most business circumstances, which is to share data and to use it. And to go back to healthcare, which is an example where I started, this would be a very important thing, right? You would like to be able to know what are some leading indicators of COVID and you're gonna have all kinds of information and you can go to Finland. Finland has this huge database of digital health information going back to 1953 on everyone. I'm not sure how or why they got there, but they have all this data and it is a very, very rich data set. And you can imagine that if, forget your Finland for a minute, just pretend you're a large company with this huge set of data that could be monetized in a billion different ways. Decision rights says you can use it for certain particular purposes and in healthcare, we're gonna do it for research. We don't quite know the outcome yet because the whole point of research is to do research and develop it, develop things we don't know we're developing, but this is a paradigm that would enable that. So with that, I have come to the end of my time and I'm glad to take some more questions. Actually, William, I think we are a little bit out of time here. However, once the video of today's session is posted, that chat over on the side will be open. I have a comment here that says super good and I'm grateful to receive it. I'd still like to answer some questions. Of course. And we encourage all attendees to keep networking and chatting in the chat. So one of the issues in healthcare in particular is that now that healthcare has come to grips with the cloud and decided that it's a secure enough IT environment to rely on, we've discovered there's a problem with the cloud. And if you're doing a very tightly controlled internet of medical things or you're doing robotic surgery and you're relying on the cloud, the latency is actually significant enough to create a problem for the practice of medicine. So as short as that time period is, it's not short enough. So two things I think result from that. One is we're gonna see more edge computing, which is putting computing at the edge of the network. We can debate on the definition of that, but certainly it's the devices that are collecting the data that are being used to make decisions. And secondly, I think there's going to be an overlap between the problems that healthcare faces and the problems that autonomous vehicles face. And what overlap do I see? Well, in an operating room, you need specific information very quickly to decide what your next move at the scalpel is going to be. An autonomous vehicle needs to decide very quickly, whether that's a shadow or a pedestrian before it runs it over. And in both cases, the cloud is too slow and you need some form of mesh networking to do this. So then a couple of issues arise in both circumstances. One is cybersecurity. And if this gets hacked, then bad things will happen. Another is that bad things will happen just because accidents do happen. People do get hurt by cars right now, whether they're autonomous or not. And people do have unfortunate outcomes in medicine, whether or not there's digital health or fancy cloud services behind that. But because the attitude of the outcome, which is physical injury is the same, I think we're going to see a convergence of data practices in autonomous vehicles and healthcare. And my final comment will be this, that I've spent a lot of time discussing how it's very difficult to decide what ownership really is and how you decide that. As a lawyer, I predict that we are going to figure this out through litigation because there is going to be a lawsuit. It is going to be full of depositions and interrogatories and all kinds of pretrial stuff. But at the end of the day, the liability phase may be the phase that determines who owns the data. Because in order to find somebody liable for a wrong, they have to have some ownership interest or at least some proprietary interest in the thing that went wrong. Hey, Bill! While we are debating this as technologies are deployed, throughout the modern world, lawsuit to arise, liability will be allocated and ownership may be decided in kind of a retrospective way, which I have an opinion about, which you can probably guess. Hey, Bill, we're five minutes over and we've got to jump off to the next session. Do you understand your own data? Natalie, can you hear me? I can, yes. Okay. But expectations as to how it can be organized and so forth. I don't think you can hear me. The topics are going to be solved at the contraption level while we wait for legislation to catch up with that. So, Natalie, I am at the end of the live time. Well, five minutes over, Bill. I'm afraid that we have to... Yeah, he can't hear us. ...up there. And for those of you who didn't have time to send in the question or have something you'd like to follow up, I'd be more than glad to receive an email and respond to your question. I will tell you, this is a lawyer. This is just a super exciting field and data professionals are super smart and it's...