BlackBerry Limited (BB) Earnings Call Transcript & Summary

Good morning, everyone, and thank you for joining the call today. I really appreciate you taking the time. With me today is Mattias Eriksson, President of BlackBerry's IoT business unit. And we're coming to you live from our BlackBerry booth here at CES in Las Vegas. So when I've been speaking to you guys, I know a lot of you would love to have been here with us today. And we're really excited because what we're demonstrating here at the booth is our IVY product, which we are codeveloping with AWS, of course. So I know a lot of you were unable to travel and we're disappointed about that. So what we wanted to do was as best we can, bring the booth to you. So we're going to be running a demo later. So first of all, Mattias is going to give some comments -- Mattias is going to give some comments to set the scene for the demonstration, just say now exactly what you're seeing. And then we'll obviously play the video, play the demonstration. And then we really want to make this as real as if you were here with us at the booth as possible by having around about 20 minutes of interactive live Q&A. So what we really like you to do, and if we can just move to the instructions for that, we'd like you to actually come on and ask your questions live. So rather than typing them in, we'd love you to come on and ask them live. So how you go about doing that is at the bottom of your screen, you'll see a little Smiley Face. So if you click on that, you then have the option to raise your hand. Once you've raised your hand and you're selected to Ask a Question, we'll prompt for you to unmute your line. So please click on the unmute your line, so that you can ask your question. And if you're really feeling comfortable and we'd love to see your face -- smiling faces too, so please would you switch on your camera as the icon shows alone. Okay. So that's enough for me, I'm going to hand over to Mattias to set the scene.

Thank you, Tim, and welcome to BlackBerry CES 2022. We just need to confirm that we don't have a flick on a screen to participants because we have a problem here with connectivity.

The best thing is it's live.

So I think we are fine in this room, but as long as it goes out correctly, we can manage.

Okay. We're all good.

We're all good. Okay. Good. So as Tim said, it would have been fantastic to have you here face-to-face, but yes, a little bit particular this year. I have to say though that although attendance is way down overall and the event feels a little bit empty, I've been positively surprised by the number of customers that actually show up face-to-face. And on top of that, we have obviously shifted to a virtual meeting set up that have worked out pretty well for us so far. So really an exciting show for us this year. If we just start out here a little bit to frame the demo. On the slide here, you should see -- on the left-hand side, the way we have set up the IVY demo in our exhibit for this year. And one of the challenges we're going to have in this call is, when we stream the demo for you guys now, it's difficult on a smaller screen to capture the complexity of the flow. So the way this is set up, and you can see it on the left-hand side there in the screen is we have 4 screens showcasing various aspects of the integrated solutions. So we have a cluster for a modern car, a large screen that showcases a number of details for the passenger in the car. We have 3 screens on top of that, and you will see all 3 of these in the video that captures certain aspects of the demo. And typically, as we go through this face-to-face in the booth, we stop and we discuss some of those aspects to make sure that all the points are captured. That said, I'm really excited to show you this demo. If you look on the right-hand side of the slide here, I just want to put down a couple of reminders here as you look at the stream. So first of all, believe me, this is not an animation. And I would love for you to be here and see it running just next to you instead of streamed over WebEx link here. If you just go through quickly the bullet points here. It's fully integrated code, BlackBerry and AWS. This is based on our release 0.5. So we released that code to early participants back in October. We already have a new release that is out, 0.7. And the release that we have been talking about, which is going to be made available for a broader group of potential customers for proof of concept, et cetera, is on track for February. This runs on automotive grade hardware. In this particular case, we have the NXP iMX8. And for another's domain, we have the Qualcomm 8155. And obviously, that is very important for our customers to see this running in the real environment. This is multi-domain, multicomputer main, multi-OS. We have Linux running on top of this hardware. We have Android running on top of this hardware and we have QNX running on top of this or including the hypervisor virtualizing the environment underneath. This is a multi-partner. We have for this particular scenario that we're playing out for you, we have Electra for the battery management domain with their AI-based solution. We have CarIQ for vehicle identity and payment. And we have HERE Technologies for the location data that you will see in the flow here. This is real data. So although you are looking at a screen, the route that we are driving here is a real route. It is based on collection done in Italy. The facial recognition that you will see is based on real people. It's not just a mockup. And obviously, if you were here, you actually see and touch the things. Okay. I think many of you on the call already know the second bullet point here, but I'll just recap briefly anyway. What is different about IVY in this space. we really have described it as 2 major cluster of things. The first 1 is this notion of features, IP and capabilities. So with IVY, we are putting together the experience and expertise of BlackBerry in the embedded space and in the automotive domain, together with the experience and capabilities and expertise of AWS for cloud developers and ecosystem. And we, again, believe that combination is a very special combination. It's sort of reflected in the demo and the things that we do here. The second thing that is important, and I -- we have talked about it many, many times, but based on the experience for the last couple of days here, people are still asking about this. So I'm going to reinforce it anyway because there are so many models. The positioning of IVY is unique. And the first one is really, really important. This notion that the OEM is in control. We are not taking this data, we are not in any way trying to monetize this data ourselves. We're building a solution that keeps the OEM in control, it cannot be emphasized enough. The second thing is also unique and you have that in this live demo, it is always and cloud agnostic. So we are running now basically to prove a point, the IVY edge component runs on the Linux stack and not in the QNX stack in this setup. And that is important because it makes it vendor-independent and all the OEMs obviously want to have that and so forth. And then obviously, it's cloud agnostic to the extent that the data can be sent to any type of cloud, regardless of which is AWS or Microsoft or Google. And that is also very important. And I thought it was crystal clear after all the times we have talked about it, but we're still getting questions about it, so I want to emphasize that. The third thing I want to say to you before we start the video here is remember, when you look at the scenarios here, it's obviously framed in the context of a consumer journey. We are not a consumer company. We build the foundation for other people's consumer journeys. But that's a good way of framing the use cases. This is a very particular scenario. Obviously, just one of many, many scenarios that the IVY capability enables. So think of that you have a generic edge cloud platform for dynamic deployment of sensor data processing at the edge. This particular scenario processing processes certain types of data from certain compute domains. But this is not the solution. The solution have many, many use cases that can be applied. Based on experience, there's also some questions around terminology. I think we've maybe shot ourselves in the foot here a little bit with the names that we have started using and so forth. Remember, we have 3 components. We have the IVY edge. We set the code that is running in the car at the edge, potentially multiple compute domains. We have a console that allows you to deploy code to the engine, manage that code and so forth. And then we have the developer tools themselves. The most important one that people get hung up on is the terminology of synthetic sensor. And I actually put it in writing in the slide just because we're getting so many questions about this. So what is a synthetic sensor. A synthetic sensor is nothing else than the deployable updatable code that we deploy to the edge. And it runs in that edge framework that we have in the compute domains in the car. So it -- as a piece of code, it could be a machine learning algorithm. It could be something else that as input takes data from different domains in the car, processes that data and deliver some kind of insight. And this insight can go into other applications that is running in some of the compute domains in the car, it can go to the cloud, you can do many things with it. But when you hear a synthetic sensor, think edge deployed, updatable deployable code in the car. Okay. Next slide, please. Okay. So I'm going to jump into the video. And here, I have a picture just to reemphasize what the video will look like. So you have 4 screens here in the booth in order to explain all the various dimensions of the solution. The bottom screen here is sort of the consumer experience. Think of a large screen in a car, we have lots of data being fed to consumer in different types of context and so forth. On top of that, in the booth, we have 3 large screens. And these screens are showing contextually relevant information for where the demo is at. So sometimes it shows architecture. Sometimes it shows something that the consumer is doing in this scenario. Sometimes it shows some text describing a technological aspect. And the thing that's going to be most difficult about doing this in a streaming fashion instead of face-to-face is that typically, we run this through, we stop people, ask questions and they explain in the interest of time and running this report, you're going to see a video that goes straight through. But focus on the main consumer screen and maybe the highlight in the middle, don't worry about the side screens. I think for many people, unless you have a large screen at home, it is going to be impossible to read for you. Okay. That was a slightly longer into than I was thinking of making. But let's get started. Let's go to the video and let's run through the video. [Presentation]

Okay. Let's go to the next slide, please. Okay. So again, virtually difficult to capture all the things that are going on here. But just to -- and many of you might already understand exactly how it works. But if you think about this notion of using synthetic sensors to process data at the edge, what is an example here. So you have, for example, for the battery management solution that Electra provides, code running in the battery management domain. Now with IVY, they can deploy code, execute on a call that in real-time, collects data and feeds that data insights into the battery compute domain to optimize the battery. And that's something that is happening continuously here based on a number of parameters throughout this journey. And obviously, it doesn't come through in the consumer description of the journey. Similar for CarIQ, which is focused on this notion of vehicle identity and being absolutely sure that the vehicle is its own identity, paying by itself. You need to be sure that the vehicle is the vehicle a machine and so forth, as you was talking about. And they can now go beyond the VIN number and the component numbers and some of the telematics data and really continuously based on sensor data, authenticate the vehicle throughout the journey, and that makes the solution so much more secure. So a little bit difficult to get all of it through in a video like this, but I hope you captured some of the essence here. And as I put in the slide here, the most important thing here, and what I'm really excited about is that this is now real. Again, it's live. It's fully integrated code from BlackBerry and AWS. It's running on automotive grade hardware. It's multi-domain, multi-OS, we have partners integrated and so forth. So really, really proud of the team for that. The second bullet point here is, as we have said multiple times, we are now on track for broader access to partners and potential customers in this February release. And then we are in final stages for multiple formal POCs. And we haven't made many announcements about this yet. There is obviously quite a lot of sensitivity around this. It's a strategic move. We did announce PATEO this week. For those of you who are not active in the Chinese market, PATEO is a leading supplier of smart vehicle and cloud services in the Chinese mobility market. They have a lot of models, different car models already deployed. It's an existing partner of us. They've used QNX Hypervisor and so forth for some of these deployments and they are now in a commitment with an OEM in China, which we're not allowed to announce yet for a deployment where they believe IVY should go in. And it's very exciting that conference call last night with Chairman Ken, and we're really looking forward to getting to work on that together with them. Let me stop there, and let's take some questions.

Yes, absolutely. Okay. So now short term, if we can just flip back to the slide about instructions. So if you do want to ask a question, click the Smiley Face and raise your hand. We'd love you to come on and speak and give you a question. So Tania, do we have any questions yet?

Not yet.

No questions? Really, wow.

I think you had some pre-submissions or...

Yes, we do have some pre-submissions. So Mattias, what does the monetization model look like for IVY?

Yes, yes. And we have touched upon that a couple of times. I would say on the following: So we are obviously, at this point, in negotiations and discussions with customers, we are flexible on the monetization model, but we have some principles. So we are looking for a recurring monetization model. There are different ways of doing recurring. It could be by car on a time base. It could be usage based. It could be a couple of other dimensions. Different OEMs have different preference here depending on how we have structured the software stack. And before we have actually locked with someone and signed, we will probably keep it at that conceptual level, but recurring and flexibility, I would say.

Okay. Very good. Do you have any questions here Tania?

Yes. Your first question is from Todd Coupland from CIBC. Your line is open. [Technical Difficulty]

Todd, can you hear us? We can't hear you, Todd.

Can you hear me okay?

Got you now.

Okay, great. My video doesn't seem to be coming through, so I Just turned that off. Happy New Year. Yes, I had the monetization question as well. Is there any way for you to give us an idea on what the range of, let's say, a vehicle sale or OEM might be worth in terms of IVY, any ballpark or ranges? Just give us an idea beyond the recurring statement.

[Technical Difficulty] So I fully understand the need for it. I just would like to say, have a little bit of patience with us. We are in negotiations. And I really do not want to lock us into public statements around this. We have signal that it's material for us. I think the best way of modeling this is that there are a couple of benchmarks out there that you can look for. We have looked at the revenue side of benefits for the OEM. We looked at the cost side, we looked at time to market and things like that. Actually, one of the analyst houses had a white paper out that we help them on, not so long ago. I think it's published and available on the Internet SPD. They looked at the cost side, total cost for an OEM of sort of maintaining an IVY-like solution. That gives you just 1 dimension of it, but that can start sort of honing in on what the levels are. I really don't want to publicly preempt the discussions at this point, I'm sorry.

That's fine. I understand that. So conceptually, if it was an Italian OEM, the consumer would be paying for that feature set that you described. Is that the idea?

Our customer in this case is not necessarily the consumer. So we are selling this to the OEM. We're selling to the OEM's partner depending on how they discuss how they have decided to integrate the stack. How the OEM, then in their situation decides to monetize this towards the consumer is really up to them. And that's back to this positioning. We don't want to impose in any way, shape or form our view of how data should be monetized. We're here to support the OEM, the OEM owns the data, the OEM owns the solution. And how they monetize that towards the consumer, we leave up to them. Our contract is with the OEM and their software partners.

Do we have some more questions, Tania?

No, continue with your predetermined questions.

Okay. Okay. So thinking about this in the context of QNX. So in QNX, we got this kind of design phase where the OEM or the Tier 1 is kind of designing the software into the vehicle. And then we move into production with live TVs open -- move into production and we get this onetime royalty. Now obviously, we're saying now. The model is not a onetime, but it's a recurring royalty stream for the lifetime in the vehicle. But is it a similar kind of concept that you still have this design type phase and then a production phase?

Yes, I think it will probably turn out to be slightly less involved than some of the really advanced integrations we do for QNX. But we look at it in the same way. We have a generic platform. That generic platform needs to be adapted to the evolving software architecture of the OEMs. So there will be service and integration work needed on our side to adapt to their environment. But as of now, I think it might actually be slightly less involved if we have a multi -- compared to a multidomain, multilayer deployment for QNX.

Yes. Okay. Fair enough. Any questions, Tania?

Our next question comes from [ Georgina Russell ] from Chicane ] Management.

My question is, I guess, in the demo you showed sort of multiple applications rolled into 1 journey. What is the -- Sorry, I have some background noise. What is the perspective, I guess, of the OEMs with respect to integrating or standardizing on the technology at this stage.

Yes. So it varies across OEMs. So if we take a step back and we just think about the software-defined car first, and data monetization and what you do with that in the context of the software-defined car, is a topic in itself. But the software-defined car, and you go OEM by OEM, they are at very different stages. And depending on where they're at, they are addressing different problems. If you don't have that architectural vision yet, you haven't locked in how you're going to layer the stack and how the compute environment is going to evolve and so forth, you're not quite thinking about everything associated with data monetization yet. I think more and more of the OEMs, this is going back to what we have said already from the beginning, we are not trying to solve a problem that people have not realized is a problem for many, many years. I mean the progressive OEMs have worked on data monetization and getting access -- giving access to developers -- giving data access to developers for many, many years. The reality is that most of them have a lot of work left. And if you think about the range of things that is hitting an OEM, have been hitting them for the last several years, whether it's how to deal with electrification, the software-defined power itself, how to deal with the connectivity aspect and the consumer experience and ADAS and autonomy. There's a smorgasbord of things that they need to deal with. So more and more of them, although they might have 5 years ago, said, "I'm definitely going to do all of this myself." They are realizing that there are significant benefits of working with an external partner that allows them control. What they're most terrified of is losing control of the entire consumer experience associated with data and the data itself. And that's why the positioning of IVY is so important. So long one and as it really varies. And the OEMs, the reality is that they are at very different maturity level at this stage.

Okay. Next question, please.

Next question is from Dan Chan at TD Securities.

Just related to that last question. For those investors that aren't very familiar with what's involved in designing or enabling some of these capabilities, what's the path like for an OEM that's going through this decision of whether to adopt IVY versus doing it themselves. It seems like some of these features may be possible with some of the IVY manufacturers out there right now. So what are you doing now that's really helping these OEMs versus them doing it themselves?

That's an excellent question. And again, the answer is it varies by OEM. So as you rightly pointed out, if you talk to the OEMs that have been all over this, they have built large software teams themselves that have worked on data monetization for many years and so forth. They already have many of the -- if you think about this use case, without going into the integrated details of how it's actually implemented, you can do -- if you have an existing software architecture that is progressive, you can do many of these things today. It might not be as real time, it might not be as dynamic, but you can sort of get sort of the basics in place around this use case without having something like IVY running. That said, and many OEMs tell developers, when you go down at the organization, tell us the same story that because of how the hardware is churning as the electrical architecture is evolving, because of how the various layers in the stack are churning as you evolve the architecture. You go from that, many, many ECUs to multi-domains and multi-domains to the high-performance compute and so forth. Every time you make a transition here in the architecture, you need to re-churn the application layer and the things that you're trying to do for consumer experiences. And that's a painful process. And many of them are stepwise realizing that, that is not what we should be doing. We should be focused on the consumer experience. We should be focused on differentiating at the top layers of the stack instead of figuring out how to constantly be churning for different releases of hardware and different releases on middleware and so forth. So Unfortunately, the answer is the same. It varies by OEM, but we're getting a lot -- if you have done what we are trying to do now with IVY 4 years ago or 3 years ago, I think the responsible to go away. We are going to do this ourselves, this is strategic. We really do not want to have this discussion. Even progressive ones are becoming much, much more open to this discussion as we speak. And this is a multiyear journey. Make no mistake, even if you have done a lot of work on data monetization, and you have multiple compute domains where you can pull the data that you want, it doesn't mean that you can cover all the things you want to do over the next 3, 5, 7 years. So they realize that this is not going to end as the architecture evolves, it's going to continue. And having someone abstracting that for them, I think, is becoming more and more attractive.

Okay. Thanks for that question. So another pre-submitted one, Mattias. Timing, I think John might have touched on this yesterday at the JPMorgan. What's your thoughts on timing for revenue?

Yes, I think. Yes. So I think it's important. This is embedded software. This follows the existing embedded software deployment. So you have something that is available for POCs that is running cold like we have now fully executable in different environments and so forth, that goes into some kind of testing with the OEM, targeting a certain platform, then that gets locked and you will have to get into production. So as I've said many times, even though we have code now that is available, getting that into cars that is on the street generating revenue for us. I think I've said before, we're looking at 24 . I think John said in that range.

Model year [ 24 ], yes.

Yes.

Okay. That's cool. Any more questions?

Our next call is from Tio Charbaghi from FIFTHDELTA.

Great to see you again at CES us, and thanks, Tim, for this session. I would have loved to have been there in person, obviously, but this was quite productive. Just trying to visualize how an OEM today would get this into a test vehicle, forget being on the road, right? So if I think about the minimum hardware requirement in the vehicles. So let's imagine, I'm a premium manufacturer of Germany and Mattias touches your previous experience, right? I already have cars on the road that may not have domain controllers, but they have some app like Mercedes me app, right, connect to the vehicle already. Is that the minimum type of hardware required to now implement IVY. I mean, can you put that into a current generation distributed ECU stack in a car today?

Yes. So it's a great question. And just to be clear, and I know you know, but I'm just going to say it anyway because we get these questions. So you don't retrofit IVY to something that is on the road today. That is not how it works. This goes into a new stack. And for the car manufacturers, as you know, they lock the hardware that they need for the new platforms well in advance. We are deeply embedded, as you know, with NVIDIA, the guys that are really dominating the performance compute here. All the others we're working with, too. And IVY does not require in any way, shape or form, hardware that is different from what's in this road maps today. So we do not impose a large compute requirements, a large memory requirement. Actually, we are doing the opposite. So if you think about the cloud discussion, one of the things that IVY allows because of the edge processing capability and the way you can dynamically deploy it, is that you actually need to extract less data because you can process it at the edge and your cloud plans and so forth, becomes more efficient because of what we are doing. So if the question is, do we impose new requirements on hardware for the road map for the next 7 years, we do not. We are fine. And so we are now running here this demo on iMX8 and on 8155. We do not need anything exceptional.

That's clear. And just so, again, sticking maybe with the like Mercedes example, in that case Mercedes me app, which already has some basic functionality. I think if you looked at an EQC today, Tier 1 has a battery management system. It gives you some stats, it points you to chargers. What would be the angle with -- again, not picking Mercedes for any particular reason, right? Why would they then choose to evolve with you rather than continue with what they already have?

Yes. So that's an excellent question. It's at the heart of what the discussion should be. So someone like the Germans, some like Daimler and BMW, they have been working on this for many, many years. And you referenced before our -- my experience with the -- I mean we deployed very, very early on several years ago, we deployed things like hazard warnings that were picking up sensor data, processing at the edge and sending it back for warnings and all of that stuff. So they already have a framework. But if you really look at how the stack is evolving and how compute is evolving, they are not done. It's not like the stack they have in the cars they are shipping now that is the end all, be all for the future. They are evolving both the electrical architecture and the software stack. And as they do that, they obviously don't want to be locked into hardware commitments with a single chip vendors and so forth. They do not want to be locked in to certain layers in the software stack. And every time they make a change, that application layer you have on top that feeds their cloud services and the mobile app and so forth, it needs to be replumbed, someone needs to fix the plumbing, someone needs to put all the connections together. So this constant churn, even if you have a good set of solutions today, there's this constant churn of moving this forward in the architecture as you deploy next-generation vehicles. And then on top of that, an interesting exercise is if you look at a modern car and particularly if you look at the high-end cars, there is so much data being collected that simply is not used. I mean because it's complex and extracting the data from all the different sensors sending it to the cloud for processing as opposed to being able to do that at the edge and do it dynamically. So you can change and update that edge capability, that is very difficult. And that's the crux of the matter. And many of them, as I said before, they have spent a lot of effort. They realize it's costly. It doesn't necessarily add a lot of value to the consumer. So getting someone else to take care of the plumbing is becoming more and more attractive in that proposition.

And if I can just fit in 1 -- maybe 2 more quick questions. One is on the U.S. side -- Just very quickly, Tim. Yesterday Stellantis NV announced with AWS that are helping them obviously build all their software features. Does AWS lead with IVY when it comes to connecting the vehicle? Or are there competing products at AWS with IVY?

It's a great pleasant deal. And I would be ecstatic if AWS given all the types of business, I think if they said, "Oh, IVY is the most important thing." But the reality is that AWS is a big business, orders of magnitude bigger than what we are doing with them on the IVY side. We are really, really happy about AWS signing this kind of strategic deal with someone like Stellantis. But if you look at what has been announced here, I don't want to -- I have nothing else to announce, but I'm not going to go beyond. But if you think about that, I mean it's AWS, it's collaboration on digital cockpit. You have many components under your cockpit. We're going to buy some vehicles, and we're going to train some engineers. These are big ticket items. And I would love for IVY to be a big ticket item for Amazon overall. The reality is that in the context of these big deals, there are many, many, many components on it.

But IVY would be a complement to that software stack, right?

They haven't announced any of the components. They have announced they're going to use AWS. They're going to collaborate on digital cockpit, and then you realize how many things you have under that, that is roadmap.

Your next call is from Todd Coupland at CIBC.

Great. You talked about battery management and trip optimization in the demo. Is there any way for you to make a comment benchmarking this to probably Tesla would be thought to be the best battery management system out there in the market now. Have you made any comparisons? Can you share those with us.

It's an interesting question. But -- so first of all, we are not selling battery optimization or any solution associated with that. We are selling this cloud edge platform that can do many, many things. We happen to -- we have made an investment in the start-up company that is really advanced in their AI modeling of how batteries evolve and planning failure rates and so forth. But we're not sort of -- we're not selling a package here, take our battery management and compare that to some of it. That is simply not what this is about. If you want to understand where various battery optimization solutions are, so Electra is a company that they do that. They deploy code at the edge. They have a cloud solution, they model battery and failure rates. I am the wrong person to talk about that. It is not what -- it's not really what we're selling. So what is interesting here is that we enable now a small startup that is very small, highly focused on a very particular niche. They complement the static model that you typically get with battery management by having software deployed in the battery management domain that can now via IVY, they get access to real-time data and not just static modeling of how the battery is performing and using sensor data in real time to do that. That is a cutting-edge technique. But I do not know how it compares with any of the others because we are sort of deploying the generic capability of getting access in real time to the sensor data here.

One final question, then we'll wrap up the pre-submitted ones. So it's -- so you mentioned, Mattias, around about the POCs and the multiple POCs, very close or -- What about design win? When -- put you on the spot here. When do you think we'll be able to hear about a design win?

We will hear about the design wins this year, this calendar year.

This calendar year, okay. Well, that was a really good session. I thought. I hope you enjoyed it. Have you found it useful. I would love to have you here, but clearly, we couldn't. But hopefully, this is a decent constellation to us. So thank you very much, and we'll speak to you again soon.

Thank you.