Blockchain Mandates 2.0: Legal Issues

Usman: The next exciting panel, which everyone has been waiting for is on the law, of course. The law of Blockchain. Wish us is four terrific speakers. We have Kathleen Ritchie who's a partner at Gowling WLG. She's the head of our business law group. We also have Jim Longwell. One of our partners in the IP group and then we have Patricia Romanovici. Is that correct?

Patricia: Yes it is.

Usman: It is. Okay. She's the Assistant Vice-President and senior counsel at Sunlife. Then, none other than Mark Hines, one of our former colleagues here at Gowlings, who's now senior counsel at the Royal Bank of Canada. So over to you Kathleen.

Kathleen: Thank you very much, Usman. Can everybody hear me? Okay, great. So this panel today, we put it together obviously with lawyers, but we wanted to make sure that we had really good in-house counsel representation. Thank you Mark and Patricia for joining us today. We wanted to talk about what are the key legal issues that business leaders need to consider when they're employing Blockchain technology. Tried to get some tips from some of the lawyers. We're going to talk a bit more about the lawyers being involved in these projects. We're going to cover smart contracts, jurisdictional issues, privacy and IP and in each case we're going to talk a little bit about what's the potential liability. That's why you usually involve lawyers. What's the liability for something? Just building on the use case panel, and they were sort of talking about the idea of how to go about operationalizing Blockchain in enterprise. You've decided that you have a use case. That it's a good situation where you can have collaboration. You don't need the middle man. You can maybe save some costs and it can be co-enabled. They did talk about getting the lawyers involved, earlier, rather than later, but panel, what do you guys find in terms of when the lawyers actually do get involved? Could you speak to that for each of you?

Patricia: To echo Marc and Parna on the previous panel the sooner the lawyers get involved the better. From the Sunlife experience our lawyer's mission is really to provide proactive and strategic legal advice, legal solutions, to the business units we support. In line with being proactive, we got involved with Blockchain, actually prior to Sunlife's first Blockchain use case. We wanted to get ahead of Blockchain issues and we created a center of excellence, in house, to do really three things. To educate ourselves about what Blockchain is, to understand the technology, the business models, and to create legal tools to help us out. Now lawyers work really closely with our business partners, and in the company, so typically they would reach out directly to the lawyers. We don't have assigned Blockchain legal experts at Sunlife. Eventually everyone in the legal department will be expected to be able to deal with Blockchain legal issues as they come up. This is why we're working on developing tools to help us out.

Kathleen: Mark, what about you?

Mark: Yes, so, I would come at it from two perspectives. One, would be sort of an ongoing process prospective so we have Blockchain expertise from a technical and business standpoint. Largely federated across the bank and as a law group there are a couple of lawyers who have some experience and expertise in this stuff. We follow with them on a monthly check-in basis to see, not only what they're doing, but what they're looking to do. Major trip wires are triggered before you get to major development already happened. You get to things that could have been avoided. Which really helps. It helps just as much, you have already heard from Karim, we have some major expertise at the bank and we learn just as much from our partners as they do from us. Then from a project prospective it would come to my team and we would deal with it like any other digital project. That's starting very early and then developing with them iteratively as they get to the whatever it is, their end state goal is. The questions I would sort of ask myself at the beginning is what is the product you want to build? What does it look like? Who are your end users? I think we're going to get to it a little bit later so I won't get too much into it. What type of chain is it? Where's data coming from? That kind of stuff.

Kathleen: Right. And, Jim, you're external counsel, IP counsel, when do you get the call?

Jim: Making maybe a small plug for how to get an early call. That's to be a legal service provider who has two main goals in mind. That's building value for their company, their client, and minimizing risk. If we keep those both in mind, and minimizing risk not as a gate keeper of saying no, but as a facilitator of how to get something done. If you are able to provide those services to your client they don't hesitate to pick up the phone and say, "We have this issue. May development, may not. What do you think about X or Y?" and then you do get those early calls and it goes a lot more smoothly, I think.

Kathleen: That's great. So Mark started to touch on this but what do you really need to know from the business people? You're now approached with a potential use case. As a lawyer what do you need to know.

Mark: Everything. No. The big ones I've already touched on. One would be what type of chain is it? When I say what type of chain is it, a public chain? Is it a private chain, permission non-permissioned?

Kathleen: Can you just explain for the audience?

Mark: Yes. So a public chain would be one that everybody can access including downloading a copy of the ledger, can post transactions to Bitcoin, Ethereum, would be probably the two best examples of those. Then a private chain, a permission chain, they're not exactly the same thing although they are used interchangeably. A private chain is really a private data base is how
I think about it. It's a data base that is shared amongst the participants of a particular business network. Then permissioned is controlling access to right onto that chain or not. With the public chain, and the reason why that's important is really the commissioned, non-permissioned private chain, those are really, not to denigrate them, but they're really a data base and so when I look at them I think of it is a database enabling whatever product is that you're building. The former, if you're talking about those public chains, more often than not, at least the two examples I gave, those chains carry tokens. At least from a bank perspective you're looking at it much more aucune to this as a financial product so how do I have to deal with it from sort of a financial regulatory. Securities would be a perfect example. That is a big divider right at the beginning. Then the next thing I would ask them to do is, people have different names for them, privacy impact statement, data management impact statement, but map out for me how the data flows through the system, who the users are, who's going to get access, who's going to get writing, all of those kinds of things because the difference in those details will, a lot of the times, reverse engineer the difference in the legal risk. Those are the biggies.

Kathleen: Patricia, do you have anything to add.

Patricia: Yes. So, we're talking about Blockchain legal issues but we shouldn't forget that Blockchain technology really just adds another layer of issues to whatever subject matter, area of the law, applies to that specific use case we're trying to implement. Blockchain may also bring about maybe a different way of looking at legal issues as well. What we found is that there is tremendous, tremendous value in working with knowledgeable experts. We have invited a lot of people to talk to us, this … at Sunlife, including Usman, and that has helped us identify new legal issues, think about them because it's not easy to identify them and it's even less easy to resolve them.

Kathleen: Great. So before we get into further detail on the legal side, each of you here, you're top three legal issues that you see in this area.

Patricia: Liability. Reputational issues. As an insurance company what happens to data that we have and it's security would be really top of mind.

Mark: Mine would be reputational, would be number one. Privacy would be number two and relates, Patricia said it perfectly, and then number three would be product specific regulation. Especially if you're talking about a public chain securities, commodities, depending on what you're looking at, those would be my big three. But reputational is a big one. As soon as you throw the adjective crypto into something, executives tend to do this a bit more.

Kathleen: So why don't we turn then to smart contracts. They've been referred to in a couple of the panels but I don't think we really spent any time talking about them. Mark do you want to take it from here and talk a little bit about them. How are they supposed to work? Just give us a bit of a primer.

Mark: Sure. So, I like to think of smart contracts on a spectrum and on my left, so your right, I would include smart contracts which I will define as a snippet of code that exists on a chain and essentially ultimate business logic, and at the other end of the spectrum, I would have what are called smart legal contracts, which the two terms are often I think fudged, which really clouds your analysis. Smart legal contracts, contracts as a lawyer you understand to be the offer of goods or services and the acceptance of those and the accompanying terms, purely written only in computer code. In between you'll have different variations of them. You'll have one where you'll have a natural language version of the contract and you'll have a smart code executed version. You could have some terms only in code, some terms only in English. Depending on where you are on that spectrum you will have different issues that will arise. I'll give you one example on the extreme smart legal contract side, how do you have a meeting of the minds if everything is in code? You would have to two people who were equally versed in the law and computer coding. That right now is a bit of theoretical state. Although with AI and convergence, which I don't want to get into, you may get there sooner rather than later. In that end of the realm too you'll have issues with agency because an agent, in most theories of law, has to be a natural person. So if it's not a natural person you're going to have enforceability issues. Then down the other end of the chain it's really the translation process from the natural language to the code. Which can be tricky. I meant this and I thought you meant that too and we agreed to it. Those are the big ones.

Kathleen: Are they even contracts?

Mark: Depends where the spectrum you are. I'd say right now, no. I've never seen a true legal fully coded contract that only exists in code. The closest I've seen is a natural language contract where you'll have a section that says this part will be reflected in the code on a particular chain, an extent to which it conflicts with these broad principals, it's not enforceable.

Kathleen: Is that a hybrid smart contract?

Mark: Yeah. I guess you could

Kathleen: Okay. Okay. What are oracles and how do they come into life?

Mark: Well, Usman's one. An oracle, this is very good point from a legal perspective but also from a security data perspective. An oracle is essentially a third party thing to a Blockchain that triggers the action of a smart contract. It's an input from a technical perspective. You hear about them in insurance cases. The Ministry of Agriculture website that says temperature dropped below this level for a period of time trigger policy. From a technical perspective, anytime you have systems interaction you have a cyber and a fraud threat. In particular, if you're oracle is a public thing like a public website, the fraud risk in particular is higher. When you have an immutable chain that becomes a bigger problem because it becomes an immutable fraud. You have to think a bit laterally around how you either stop it or how you deal with it, back end.

Kathleen: Okay. So, Patricia where do you see smart contracts being used in your space?

Patricia: I want to take a step back and add something to what Mark said. It's funny because you said you see them as a spectrum, right? And I see them as juxtaposed. You could have a legal contract that contains terms and conditions, that really reflects a human relationship, that includes assurances that gives people predictability, that contains clauses like dispute resolution mechanisms and choices of jurisdiction. Maybe good faith obligations and a bunch of other things. That's sort of a long think. If you take part of it only, only the transactional side of that contract, and you make it into a smart contract, that smart contract is going to reflect just a part of your real legal contract between parties. Despite their name, I don't think smart contracts are really that smart, because they can't really know anything about the parties conduct outside of that Blockchain. Outside of the mathematical algorithms that they contain.

Kathleen: Just to that point that was made by the last panel that putting data on the chain is very expensive. Somebody's made a choice of what it is that would be on the chain and what you're saying is there's a lot that wouldn't be.

Patricia: Yes. Absolutely. Where do I see them going? Any area where you have transfers of data, or transfers of assets, could be potentially be areas where Blockchain use cases can come up. From an insurance perspective, in our world claims administration is one such area. Another area is fraud prevention. Sunlife is trying hard to create an industry consortium to coordinate benefits and to detect fraud. To give an example, really quickly of what that means, imagine you're an insurance company, you pay claims. Your client, Joe, goes to the dentist. They have the right to be reimbursed 80%25 of that cost. They submit a claim to you. But Joe also submits a claim to his spouse's insurance company. He also claims 80%25 there. If we had an industry consortium we could find out from the Blockchain if Joe submitted two claims for the same event. That would help us prevent fraud. Somebody on another panel, I think, mentioned the question of timing. How fast are these things evolving? I thought about this question and I couldn't really find a good answer. But I came across an article published on Willis, I think Towers Watson now Willis Towers Watson, website, on their global site, and it said there that these kinds of applications, operational improvements, automation, distributed relational data bases, would see the light of day within the next 2 to 5 years. I don't know how accurate that is. That prediction doesn't take into account regional differences. For example, the Canadian environment versus the US environment, or Asian environment, but I still thought it was an interesting timeline to share.

Kathleen: Mark, what about you?

Mark: Yeah, so the only other thing I would, that touches on a couple of very good points. One is you need to think, one of the things I'm very concerned about as a lawyer, what goes on chain and what goes either in an existing database or in what's called a side chain. A lot of actual sort of products, part of which is a Blockchain, they're actually very centralized instance, but because usually you can design these things. You don't have to put too much information actually on the chain itself. Just a pointer to a place and authorization for a particular person like the claims example. The best one that I've seen that sort of really helped make this point, there is a project out of MIT called MedRec, where they're trying to create access to medical records using a Blockchain. None of the records are on the chain. They still exist in the various controllers but the chain basically tracks metadata and access rights to the various places. When you're looking at the chain you don't have to worry about is it PII, is it not PII, what happens if somebody 51%25 attacks my chain? Whatever it is. The second point I was going to make I've entirely forgotten I'm afraid. Hopefully it will come to me in a second.

Kathleen: Maybe just to sort of finish up on smart contracts, and I think this question was sort of asked in the last panel but I'm going to ask the lawyers, who has liability for these? Where's the liability?

Mark: That's a very good question. It depends on a couple of things. One, public chain liability is a much trickier question to answer because you don't have control over the chain. It would still, ultimately, as you being the service provider, if Royal Banks logo is on something, we're at least initially liable. That's why reputation is such a big thing. I should say that up front. With a private one you basically control it through your collaboration agreement. If it's with the other members of the network. The other aspect of this is the extent to which you use, or do not use, third party service providers. Because this tech, as I'm sure you're all aware, is very specialized and very good production ready versions of various parts of tech. There are not a whole bunch of them out there. Even the really good ones are still, relatively speaking, new companies and they get very squirrelly about carving out of your liability cap. A breach of confidential information. You essentially, in many ways, just have to accept, this is coming from a big FI. If you're brand is on it you've got to accept you're getting the bag. Up front. You just have to be honest with your business partners about that. You can mitigate it legally using in various forms of contract but you have to understand, at least up front, you're going to be the one on the page of the Globe & Mail.

Patricia: Yup. That is so accurate and true for us too. The only thing I would add is how do you ensure the quality of the code? How do you ensure that that code really translates what the parties mean to accomplish? So then who do you exercise recourse against, if it doesn't? You can think of the coder, the rights the coder to open source code that comes with no guarantees, then what do you do? You can think about the platform but that doesn't have anything to do with the content of the code. You could think of the lawyer who drafted your initial contract. But then the lawyer didn't code it. We don't hear much about, I find that unfortunate, but how does the translation happen? From your legal contract to your smart contract. The question comes, who will do that translation and what their liability is going to be and how do we mitigate that or work with that?

Mark: I actually remembered my previous point and it actually relates to this. I'll say it now. A few things. The first one is you can use oracles going out as well as coming in to the chain. And one of the clever ways I've heard of oracles being used is essentially ultimated arbitration. If you have a dispute over a transaction it will get kicked out to somebody who will make a decision. Who will then input their decision back into the chain and things will keep going. That is not going to happen on Bitcoin. Might happen on Ethereum depending on the application. But that's a clever way to keep it going because the sort of technical difficulty sometime with a chain will affect the operation of your product. If you're looking at it from a user perspective, if I make a transaction, nothing happens for 24 hours because of Blockchainy stuff, all's I see is it took 24 hours to use an RBC app to move something from here to here. The other thing I was going to say about standards is there is, at least I'm aware of one international initiative called the Accord Project, where they are developing smart contract standards similar to internet protocols so that translation process becomes more ubiquitous and becomes agreed to amongst developers. But Patricia is right. That is the rub when you have a smart contract model where you have a copy of one or you have one only existing in one place.

Patricia: Just may I add one little things. One of the other sources of a potential liability is really also the accuracy of the data that you have. We've touched upon this just a bit before but if you're going to have physical world events that you need to consign somehow, or enter into the code, what happens if when they're entered into the code they're entered erroneously? It's honest mistakes. That gets stuck, on an immutable chain, that'll be there forever. How do you correct it? Who's liable for any losses?

Kathleen: That's great. Then why don't we turn to the next subject. You mentioned this a little bit, Patricia, but jurisdiction. You talked about in the contracts, to the contract there'd be jurisdiction, but what are sort of the jurisdictional issues in the Blockchain context and how do we deal with them and liability?

Patricia: Good questions and no clear answers but when you mentioned jurisdictions, there are two things that come to mind. One is which countries laws apply? Then which courts would be able to hear a dispute? If we compare legal contracts, our traditional contracts, to the smart contracts well legal contracts are pretty easy to enforce. They're rooted in a country's, or in specific jurisdictions, legal ecosystem. Composed of laws and case law and courts and regulators but if you think of the smart contracts where blocks travel between nodes all over the world, how do you know in which jurisdiction, which legal jurisdiction, a breach occurred? What if it happens in multiple jurisdictions? I think there may be some confusion there, and high costs, if you're going to engage in cross border litigation. I think it's just best to avoid the whole question and contractually agree in a legal contract on jurisdiction. We can think about, I think Mark you mentioned this before, the difference between private Blockchains and public ones, it's a lot easier to avoid the question and agree on a jurisdiction when you're in engaged in a private Blockchain as opposed to a public one. I think that's what I had to say.

Mark: Yeah. I agree 100%25. I look at it from the application of regulation which you have no control over and the application of contract which you do in a private chain. I should start with in a public chain the answer is nobody knows. The extent to which you try to give a definitive answer you're going to be guessing, to a certain degree. In a private chain you can have much more certainty. With respect to regulation, and if it's a private chain you can control if it's a consortium, or you can join a system where you know the jurisdictions in which the nodes will be. If it's a theoretical collaboration with the FI's in Canada all the nodes have to be in Canada. It's not dissimilar to a cloud analysis that I'm sure a few of you are familiar with. There you know the application of at least pipada will apply. With contracting, Patricia really said it all, that you just divvy up the liability in your participation contract. You can also code some of these things into smart contracts. I haven't seen the use case that we can talk about that really fleshes that out, truly, but in theory you could trigger the application of a particular set of legal principals. Whether that's a particular country's legal principals. Whether that's something that the parties have agreed to but you could also build that into your automated execution.

Kathleen: Jim, did you want to add anything?

Jim: Yeah. I think, echoing the comments again, the private chain and private approach is easier to do with IP, so my perspective would be from IP infringement, more than other issues. People often will choose to operate in jurisdictions that have a different regulatory or IP enforcement regime, when they're infringing, because that reduces their risk. Part of someone's IP protection strategy will be to evaluate what it is that I can protect and where I can enforce it. The jurisdictional issue is a big one there and spending your money accordingly.

Patricia: I had a thought. I wanted to mention, actually to echo one of Hilary's slides from this morning, where she said, "What if?" and she was able to project us into the future of Blockchain. The legal equivalent of that slide would be a world where regardless of the support of your transaction, whether it's on paper, or online, or on Blockchain, you wouldn't really distinguish between cases. You would apply the same legislation in all the same areas of the law. But we are very, very, very far away from that world today given that today the law operates by jurisdiction.

Kathleen: Let's now turn to privacy and data protection. We talked about there being data on the chain. Patricia, and Mark, do you want to give us a bit of a high level review of the privacy issues.

Mark: Sure. I'll actually give an unprovoked plug. Gowlings has, I think from Gowling UK, a paper on data and protectionism and a lot of the concepts today discuss in that paper would apply to these types of discussions. It's really important to understand what type of user is at first. Is it a commercial user or is it a personal user? If it's commercial user is it still a client relationship or is it a partner relationship? All of those will set the stage for how you look at it. Let's use personal because it's sort of the one where you get into a lot of this stuff. First of all you have to identify what's going to go on chain because you have to assume in a Blockchain scenario that, notwithstanding the fact it may be pseudo-anonymized, not entirely anonymous, it's shared with all the participants. That then reverse engineers into what consents do I have in place? Are they sufficient and can I just use that data without getting another form of consent? Then we look at it really about security of what's on the chain and what has to be on the chain and what can we keep off chain. Within our fire walls, where we're very comfortable with them, that tends to be the model that's used. Like the MedRec one that I gave because you avoid a whole bunch of stuff. There are some really interesting discussions, largely driven by GDPR, if you're talking in a public chain world around, "Is my public key personally identify information?" There is another paper written by another law firm that looks at this quite closely and, I think, there's a lot of, for example, jurisprudence out of the EU that talks about dynamic IP addresses that can be applied in this world, and I think you can't just assume that because it's a hash that you're not in the world of PII. I think having to seriously look at that problem is a bit far away but you need to understand sort of how these things interact with each other. Looking at it from a user perspective, not from my perspective.

Kathleen: You mentioned GDPR. So obviously jurisdiction comes into play. How does somebody come up with, they take a use case, their now in development, how do they go about making sure that they've addressed privacy issues?

Mark: How I would look at it is what are the users that you want, as a first standpoint. Do I want users in the EU? If I don't particularly want users in the EU why would I bring in all the legal issues unless there's a huge value add to. That's sort of the first thing. Let's assume for now we have Canadian users, US users and EU users. The UK could be included, yeah. Then you basically have to look at it from each perspective. One way of looking at it is just having a high water mark approach to it. So you cut it off. At Royal, from a general perspective, even though it's more burdensome, like we see the GDPR type approach is one that best protects our clients, so conceptually is how we look at a lot of stuff even though it's obviously not applicable to our Canadian users. That's one way of doing it. Or if there are real problems in how it operates you could treat different types of users differently. That can get a bit dicey. You're really looking at sufficiency of consent, security and then the big thing about, at the back end, if you write something that's erroneous on an immutable record, how do you fix it? Then the other one that's rights to access and rights to deletion. Is the other biggie. Basically there you have to think about deletion a bit more broadly then pressing a button on your keypad.

Patricia: I don't think we can actually delete everything.

Mark: No.

Patricia: That right is not absolute.

Mark: Exactly. Yeah. But you can make things inaccessible. So though it exists but the chain, you know, … the chain won't be able to trigger anything with them. So then that sort of leaves you, does that mean delete in the world of a Blockchain use case? I'm not going to venture a guess whether or not it's a yes or a no.

Kathleen: Do you have anything to add just on the liability around this?

Mark: No. The main point I would leave is that if you're a big institution like ours, and it's got your name on it, assume that you're carrying the bag. That's my in-house lawyer. We can get strategic on legal issues and we can put mechanisms in place to control, we're going to do all of that stuff, and sophisticated business planners will know this already, that you've just go to play it back to them. We're on the hook. For it all.

Kathleen: Why don't we turn to IP matters. Jim, this is your area. Can you maybe give us some background on how external counsel get involved in these types of projects?

Jim: Yeah. Thank you. I think we get involved on a variety of fronts. Some of our clients are investors. A lot of due diligence inquiries and transactional basis. That has sort of one area of focus. Then the agreement work to support that which is always fun for us. But the majority of work, I think what we do, is in the area of either protection and/or licencing which is a bit of protecting as well as sort of a business exploitation. Then less frequently would be enforcement. I think at this stage there's a lot less enforcement out there. It's just not as developed an area. Those are the main areas we work in. With my background in computer science, and as a patent agent as well, I do a lot of work in the protection side as do a number of my colleagues in the firm. We have a really solid information technology patent process here.

Kathleen: You mentioned licencing and development, Mark and Patricia, which do you see as being more relevant from your perspectives?

Patricia: Definitely licencing for us. Us meaning insurance companies, established insurance companies, with legacy systems. Not the new startups in the area. Licencing, definitely traditional licencing agreements, sometimes partnerships with third parties who develop IP.

Kathleen: And, Mark?

Mark: Our perspective is we tend to be innovation driven. So it will be much more design it and build it ourselves. One, because we can control it about how we design it. Two, we think we have the people who are good enough to do it. That's not legal people. That's technical people, I should be clear. But it is both. Because there are things like if you're looking at an AML solution on something related to a chain. We don't have the time or resources or expertise to get best in market at that. There are people out there who do best in market in that, as an example. It would be a combination. It would really, again, is driven from what are we trying to build? It may be we apply some form of chain to a part of our existing product and the end user has no idea. But it just makes something further down the chain, no pun intended, more efficient. Or it may be a whole new product available because of the network impacts of a chain. Or it may be am I building an ETF on the basis of a token? That's a totally different discussion.

Kathleen: Maybe, Jim, can you sort of focus in on development projects and talk about some of the legal issues that you see in the Blockchain context and maybe some tips for dealing with them?

Jim: Okay. Absolutely. So the make or buy decision is always a big tough one, right? Are we going to develop or are we going to buy development? There's some issues around that as well that we can look at. But I think generally these big projects they resolve to typically large software projects. In that context you have a variety of scenarios that can play out. Depending on how that happens, and what's undertaken, a lot of different types of intellectual property will come into play. Even just to give one example. You might be an internal in a financial institution, insurance company, and you are looking to the future so you're looking to do something interesting and new, and you have some great people who technically, as well as with the business group, they are mapping out what the process will look like over the next whatever. In terms of how it's going to work. But you don't necessarily want to develop that internally. You don't have the coding resources. You're hiring a contractor. Either an individual who's going to come on or another company, lots of bodies, they're going to be developing new code. You have a trade secret that you started with which is this new process. You want to share that with them. There may be some patentable aspects in that trade secret. The code that they develop will have copyright impact. They're wanting to be authors, and first authors are owners unless it's their employer, in which case the employer will own that. You're going to want to use that code. How do you get a right to use. You may want to address how, or what, do I own in that piece of computer code. The coding people may come up with some very interesting new approaches to solving a computer problem. You have mapped out a broad process of what you want but to get it done, to achieve that, may itself require inventing. That might be a patentable thing that they have. And at the end of the day they make come up with something and now they have to teach you what to do, how to use it, how to implement it. There's no more trade secrets that are being generated out of that. Also you have to look at your entire business model. How are you hosting this? Who's going to use it? You have to distinguish, as Mark said from start to finish, the client side, the eternal sides, so there's different perspectives you must put on this type of intellectual property. Then you have to decide, are you someone like RBC, who takes the protection of its intellectual property very seriously and to the point of having its own patent portfolio. Or are you a company that maybe has never stepped into this realm before and you don't know if you have the appetite and the time and the budget, you don't even have the internal resources to deal with those things. You have to look at what is it that we have to protect? How we might protect it? Including the costs and the time and effort that's going to take. Then how do we enforce it? It's all part of a larger strategy. Where is it going happen? A private chain much easier, maybe, to think of the issues. When you're looking at the public side, and there's operational issues throughout the world, and you're not really able to impose a lot of intellectual property restraints on a private side. You're going to, again, have to be very strategic. I have a client feature or focus on using the public side. I'm not going to be able to change that but either on an interface perspective, or in my dealings with my own clients, I may be able to impose intellectual property requirements. So as I say it's all about varying strategic. That's just on the development side itself. There's also other issues of ownership, as I kind of mentioned, when you're dealing with contractors, they tend to be the first owners. If I ask someone to develop new code for me I will not automatically own that unless we put that into our agreement, and we take the necessary steps to do a written assignment, for example, of that intellectual property. Otherwise it's left in the contractor's hands and I think I may own something when I really don't. Then there are of course a lot of other issues. When you're doing a development often companies are coming together. They all have backgrounds. Everyone comes with some baggage. For companies it's typically legacy intellectual property. How do you put old together with new? Do you engage in a licencing arrangement? On that basis that's typically what happens. Maybe it's a cross licencing arrangement. If the development you're doing is with another party and a larger consortium and you're all getting together now to implement a private chain you may each have background IP that needs to be licenced to another. These are, as I say, the main issues to look at.

Kathleen: In terms we talked a little bit about protecting with different types of contracts. What about patents? Are we seeing patents filed in the Blockchain space?

Jim: Absolutely. There are a lot of patents in this area and it's a growing area. Each year more and more. I wouldn't say it's hyper exponential but it's fairly exponential growth. Lot of larger players. Increasingly seeing some more activity from non-practicing entities. Or trolls is the name you might hear for those groups, as well, who are looking to find an advantage into the future. I think what we're also seeing, and one of the things we have to deal with in terms of both licencing or development arrangements, is there's still a lot of uncertainty in the technology and the business cases, but there's also uncertainty in the intellectual property area. We often, in these software deals, we look at the market place. We come with our knowledge of the market place. Our partners come with knowledge and say, "We're comfortable doing this or that." Now we take the necessary steps to apportion liability and risk but we have some comfort level, including what we do with our due diligence, but we have some knowledge of the market. In terms of who has patents or who's enforcing in a particular area. With Blockchain, and because it's so new and because it takes a period of time to prosecute patents to issuance, we don't really know who owns aspects of the various chains at the moment and who has proprietary rights to specific applications. There's more uncertainty and doubt in the air then there may be in lots of other areas of technology. I think that's one of the key differentiators with Blockchain versus, as I say, a lot of other business processing related projects.

Kathleen: I may be just in the last question, sort of around potential legal liability, IP is really about protection of IP. Do you see ways to mitigate it? There's the contracts, the patents, is there anything else we should know from a liability perspective?

Jim: I think the due diligence part. It's keeping a watch if you can on the developments in the patenting area. There are a lot of good services and service providers who can assist you with that by engaging in a review in specific technology areas. Looking at the patents that are being filed and maintaining basically strategic information about your competitors. Then determining and analyzing when those patents are issued. Does this have impact to me? And if so what steps do we take after that?

Kathleen: Okay. Great. We have about 10 minutes left for this panel. If we have questions from the audience we'd be happy to take them. I can also speak a little bit about securities law, if people are interested, that's quite specific to token type uses on the Blockchain. But do we have any questions from the audience?

Audience: Patricia was talking about people dealing with codifying contracts and smart contracts … but she mentioned that I know in insurance companies there must be some process during which you take a policy, an insurance policy, and codify that according to a set of rules which probably have to be written by an … at some point to determine whether or not someone is eligible to make a claim … policy. So, how is it different when it comes to evaluating liability for a developer versus a policy writer?

Patricia: Well, I think conceptually that the difference comes because you will code the transactional side of it. But you will not code exclusions, for example, and maybe those exclusions will be interpreted based on different facts. You can't really code that. What I meant to say is that you will code something, you will not code everything, and if in the part that you do code there is an element of interpretation based on somebody's factual reality. That's where things can get tricky. I think that really summarizes the point.

Mark: Most coding is yes requirement, no. When you have any subjective element to it, which is like interpretation, a coder will code one way that may not be, if you're looking at from a responsibility perspective, a coder will code one thing one way and do nothing wrong. It's really about that translation process which may move you up the chain. I don't want to go too down it but if you look at AI supply chains they're equally now long and confusing with room for liability all the way up and down.

Jim: If I can just add a couple of things. I think one of the other big differences is most of it's work flow. It's internal to an organization. Smart contracts often are between two different legal entities. So you need to have two groups of people who are finding agreement with a smart contract as well as you're implemented on something else. For the issues you mentioned before the ability to unwind or undo or to move forward when there's an issue. Those issues don't come typically in internal coding of the policy because you can unilaterally make some of your own decisions. In terms of how to do that, well, you can't. If something's locked on a Blockchain you just can't phone them up and say

Mark: Imagine building a website without … basically. Sort of the analogy I would give. It would be tough.

Kathleen: Other questions? We've got the lawyers here. We're free. Well maybe I'll spend just a couple of minutes talking about securities laws which is an area that I practice in and in the context of tokens on the Blockchain. Many of you will be familiar. As this whole technology has emerged tokens sort of led the charge and so this area is one that people spend a fair bit of time worrying about over the last year and a half or so. And really what it comes down to is the question about whether the token is in fact a security. There is an established case law going back decades as to the various elements of a security and how to determine what one is. But the point is that if your token is a security, or could be a security, then you have to think about securities laws as well as privacy, IP and other areas. The issue with securities laws is that we're focused on protection of what we would call investors. So we're assuming the people who would receive the tokens are effectively like an investor. There's laws around distributing securities, dealing securities, advising with respect to securities, and so in particular with the dealing and the advising you can get into situations where you as the party who is providing the tokens may need to be registered. And meet certain standards with a securities regulator. The issue then when you've got your use case, what we as the securities lawyers would tell you, is that we're one of the areas where you need to come and talk to us about what it is that you're trying to develop and how it's going to work. What we need to look at is whether there could be securities laws involved. I think one thing that's kind of different in this area, maybe compared to some of the others so far, is that because it was emerging and it had a lot to do with financing and getting technology off the ground, while the laws exist the regulators were fairly open to having a dialogue. You'll maybe have heard of the concept of a sandbox, working with a regulator, the securities regulators across Canada have got a joint team in Ontario. It's called the launch pad. In BC it's called the Tech Team. When you've got that use case ready to go, and there may be securities law implications, the idea is that you can go in and actually talk to the regulator and have a dialogue with them about whether there are potential securities law issues. This is highly unique, right? You don't normally get to go and get advice from regulators. The fact that they've opened their doors is very helpful. But it will raise potential issues and then to the extent there are concerns you can work it out with the regulator to try and get some temporary relief. Some kind of an order that allows you to try out what it is that you want to do. Which you otherwise wouldn't be permitted to do without meeting certain higher standards. There are some examples of where people have been successfully able to go and get orders with the regulators. The risk is that if you don't go down this road and you develop something, first of it all it may just not be feasible for it to work in this context, and you've spent a lot of time and effort with it. And this is the case with dealing with the lawyers, in any event, and why you bring them in. But I think the other thing too is that what we've seen, and sort of that next phase in the securities law area, has been enforcement. Now what we've seen is the regulators are actually calling companies in, looking at exactly what they did in the terms of the distributions of their tokens. Asking the question as to whether they were securities. Whether they complied with securities laws. You see situations where the regulators are potentially going to come down on people. Usman is sort of our expert in that space in as well. But I just thought I would raise securities laws as another area to consider. There are, I'm sure, many others. I think that's all we have time for today. Unless we have any final questions. Any final thoughts for our panel? Is there a question? Yes.

Audience: Hi. Just a little question on securities law because what I see as … it's not black and white. It's not … security .. does security fall into the security regulations. Sometimes it's a mix or sometimes it really depends on how they develop a platform. Do you think your client … and asking are they concerned about, let's say, now I'm security tokened … approve but then … get treated in the centralized exchange which could be traded to whoever, in Asia, wherever around the world. Are we concerned about the next step when they are security and now they get traded globally 24/7 how does the enforcement side, or regulator, handle those issues?

Kathleen: Yeah. This is the issue. It becomes a jurisdictional issue. One of the things that we have to understand is while the regulators here are intending to protect investors here, their other mandate is to protect the integrity of their markets. If something originates here, and it can be nothing is actually happening here but the people who are sort of setting it up are here then the regulator cares because that affects the integrity of Canadian capital markets. That's why they get interested in this. That's why they can sort of go after somebody. It started here then goes it elsewhere. I think there's another little point that you had in your question which I would point out because there is this concept of a security token versus a utility token. One of the things that I think people have talked a bit about is that things can change their character over time. So it could start off as a security but then maybe it could become a utility or, frankly, the other way around and so there's challenges around that as well. But I think because it may be a security initially but you don't want it to be forever. I think the last thing I would make a point of was your concept of exchanges. That's another very tricky area and an area that the regulators are really looking into because you can't operate an exchange to trade a security in this country without regulatory approval to do so. Because exchanges, by their nature, are a sort of a self-regulatory organization, or they are, so the result is that you need to be approved by the regulators. We've got these exchanges working sort of, if I can put it, up in the cloud above these jurisdictions. But the fact is that if Canadians are involved in trading on those exchanges then the regulators are going to care about who's running them and how they're being run.

Yes?

Audience: One of the other … …. Has there been much … meeting those obligations and having that come to the forefront?

Kathleen: In terms of a company that is thinking of getting involved in the Blockchain or using it?

Audience: Token issuers.

Kathleen: Oh. Token issuers. So that's the question. If they're a token issuer and it's a security then really they should be a reporting issuer. So that's the first point. Should they have had a prospectus? Did they rely on a private place exemption for the distribution of the tokens? If they actually do effectively become a reporting issuer, then yes, they'd have to fulfill the regular securities law disclosure obligations. You see this when people are dealing with tokens that are securities, and they are trying to do a private placement properly with them, that they do what we call an offering memorandum and they try to sort of meet all of the disclosure requirements. That's what people talk about turning through the white paper into something that looks a lot more like something that a public company would have. Any final questions. I think we've run out of time. Thank you very much to our panel. You did a great job. Really appreciate it.