 So, thank you everyone for being here today. Can you see my screen already? Yes. Great. So, yes, as Marta said, I will talk about supplier onboarding, mainly in the context of the hyperledger product that we have been using to develop this solution, which is currently a productive pilot running here in Switzerland. And, right, so the agenda for today is, first of all, I will start describing the use case, so introducing the business problem that we are trying to solve. And then I will explain why we decided to use an SSI approach to try to solve from a technical perspective these particular problems. After that, I will deep dive a little bit into what Swisscom is doing with SSI and how we customized our solution for this particular use case. Finally, I will have an overview of the opportunity and challenges that we had during this project using Hyperledger Indy and Hyperledger Arias. So, let me start. At the end, I will review your question and we can discuss deeply about that, if any. So, first of all, the use case is quite straightforward. Every time a pharma company would like to start working with a new supplier, they need to run a due diligence related to various risk areas that the supplier is dealing with. But this is true every time a supplier needs to start a new business with a pharma company. So, this process is very repetitive and the supplier needs to go through this process over and over again many times. And it's quite time consuming. So, this particular use case, the solution that we developed is mostly focusing on a cost reduction goal. Now, the problem related to the current process is the fact that, as I already mentioned, every time a supplier needs to do that, it needs to go through the process and this is very costly, not just in terms of timing, but also on pharma side in terms of internal effort that they need to spend in order to do the due diligence to this particular supplier. Then every pharma company has its own onboarding process, despite they may look quite different in reality, most of them are very similar and the results are kept private. So, if me as a supplier, I need to go through the onboarding with pharma one and I spend maybe one or two days to fill up a questionnaire and to upload attachment, then it may be that I have to do the same and the same with every pharma I would like to work with. Plus, all the increasing regulation are slightly changing time to time this process. And so, even myself as a supplier, I can be asked by the pharma company to provide more and more information. So, we did a sort of business analysis to try to figure out how to improve this particular process. We realized that despite each pharma company has its own process, the process is very similar. It overlaps almost 80% of the time, but the question are not standardized. So, the mapping of the question, if I go through an onboarding with a pharma or with another pharma, sometimes is very fragmented. And so, we thought, why then don't we try to standardize this particular aspect? Why don't we try to have a clear mapping of the question that are part of this process? So, each pharma would be capable to easily map answers that are already provided to someone else. And that was more or less the idea behind. From a business perspective, the idea was to try to increase the overlap of this process between all the pharma in the industry. So, try to standardize this particular process. Secondly, to provide a clear mapping on how the data should be treated in order to avoid the supplier to fill up again and again the same form, but in a different order. And then finally, the last point that we wanted to tackle from a business perspective is to figure out how we could allow to transfer data not between the supplier and the pharma, but within pharma to pharma. So, this would allow every pharma to reuse the effort that they spend in order to validate a supplier and eventually onboard a new supplier with a lightweight process instead of doing the process from scratch every time. So, from a supplier perspective, adding those three capability, adding those three capability within a solution, the benefit are quite clear because it simply means that me as a supplier I don't have to fill up this data over and over again. But there's still one open question. How we can also save time and cost on pharma side. And the answer that we define it is this one that you can read in this slide. We want them to figure out a way to allow a secure exchange of data and trust between all the actors involved in this process while preserving privacy and authenticity. So, now to explain you a little bit better what I mean, we can see how this goal can be achieved with a classic software solution. So, let's go through this chart together. First of all, as I told you the process right now is quite easy what is happening is that step number one. The supplier needs to fill up a lot of questionnaire and provide a lot of attachment to the pharma in this case pharma one where he would like to start working with. The second step on the pharma side is to evaluate the data run the assessment and figure out the risk ratio associated to this particular supplier. And then finally, the data the outcome of this assessment may be stored in the data center of pharma one. And this is actually already happening. And let's imagine that the supplier would like also to start working with pharma to so he needs again to go through an onboarding process, which I said maybe very similar. So, first of all, what step number four, he would like to ask pharma to a I would like to be on board that we team with your company, but I would like to reuse my data. I would like to reuse also the result of the assessment that it has been already done by a similar company like yours. So, what is necessary to do for pharma to in this particular cases step number five is to figure out a way to assess the information that pharma one is currently storing in order to get those information and finally review those information. This is technically possible of course, but what this type of solution would require is a point to point integration between the IT infrastructure of pharma two and the infrastructure of pharma one. And those point on point if the integration are quite challenging from a security perspective, and also one of the main problem that we identified that they are not very scalable because right now in this particular example, we are just seeing an ecosystem format by three entities one supplier into farmers, but then imagine when this ecosystem is growing and then you have more and more pharma. This means that you will need a point to point integration among all the actors. And of course, this is is technically doable ma from a business perspective cost perspective or risk perspective is something very challenging. That's why we decided to try to tackle this problem and provide a different technical solution to the usage of SSI. So with SSI how the solution can look like is represented in this chart. Let's go through again step by step. First of all, step number one, similar to the previous one supplier needs to fill up the questionnaire to be on boarded by pharma one step number two, the pharma needs to run the diligence so they need to run the assessment. And now finally the first step which is completely different from before the step number three. So now through the solution that we provided within this pharma ecosystem. What is possible to do for the pharma is at the end of the assessment process is to issue a verifiable credential signed by pharma one that state. Hey, look, I have been doing this risk assessment for the supplier and the risk ratio that I evaluated based on this particular set of data is from one to five for right. So the pharma is really issuing a piece of digital information that is secure in nature, because it's based on the SSI verifiable credential cryptographic concept. And then this data is not stored and managed anymore by the pharma. The data itself is transferred back to the supplier. So is the supplier that now is capable to store this information and eventually will be capable to decide to share this information whenever he would like to with another party. So now let's see what is going to happen whenever the supplier would like to start working with pharma two at this point a step number four, the supplier request to apply with a previous assessment. Step number four, step number five, pharma to receiving this request will broadcast to the supplier as a precise request asking to assess the information that the supplier is storing in his own solution in his own it software solution. And then the supplier of course needs to give consent to allow the pharma to assess this data. And finally, once pharma to will receive this data, another very important advantages that is is enforced by SSI is the fact that pharma to will be capable to validate the content of this data without connecting directly with pharma one. So far mature will be capable to validate if the data has not been manipulated. If the data has not be revoked by pharma one and also if the data is consistent with the information that the supplier provided to pharma one at the moment of the assessment. So this is a very strong benefit because if we think again about the possibility of scaling this ecosystem adding more and more participant right now we will need that we want to need any more a point to point integration between each actor. What we will need we will need that each single participant should be capable to integrate just one, not with an proprietary solution, but with a standard in this case assessor event identity standard. And then later we will talk a little bit deeper about this. Meaning, you do one single integration, and then you can benefit from the fact that as more the ecosystem grow as the more you will be capable to talk in a secure way with all the participants of this ecosystem without having a point to point integration and also relying on the security of the data itself. Thanks to the format of the verifiable credential, which is secure in his nature. Yes, and so what we applied mainly this is if you are familiar with SSI this is the typical issue are all their verify your chart that SSI is let's say capable to support in terms of technical capability. And this is the concept that we applied in this use case in order to provide a technical solution that is trying to enforce a security privacy and authenticity of the information. Now, the benefit you can imagine in terms of a business perspective, pharma to whenever receive a very fabled credential from the supplier stating that the supplier has been on board and and the screened by another pharma. They can decide what what to do with this information they can decide if they would like to run a lightweight onboarding procedure for example, or for any specific reason they want to keep having the full onboarding. So this is still up to the pharma to to the very fire, but applying this model to these use case we identify this possibility to reduce cost, because now we are not just talking about of transporting data and the reusing data, but we are also talking about transporting trust and reusing trust to reduce cost. Right, and this is a little bit a quick overview of the use case. Let me check if there is any question already. So, what if the supply one question is what if the supplier doesn't want the pharma to knows that is also supplier for pharma one. So, this is a very good question actually related to antitrust aspect because it may be that these full visibility for some particular topic may not be compliant to antitrust requirement. So for this particular project we didn't implement yet a solution to cover this aspect. Nevertheless, we are looking on different solution for doing that. First of all, one, it's about having a sort of neutral entity, which is also in charge of standardizing the process being the entity capable to issue the final verifiable credential. So the process won't be any more based on just the two actors. So they issue or issue the credential to the older, but the pharma one would need to issue a temporary verifiable credential to this neutral auditor, and then it would be the neutral auditor issuing the final credential to the supplier. So, whenever the supplier will then share this verifiable credential with a third party, the third party will not be capable to see which was the original issuer, so pharma one. Anyway, they will be capable to keep having trust in this verifiable credential because they trust the neutral auditor that has been displaced from a business perspective into this ecosystem of participants. And this is one solution that we are looking into exactly to cover these antitrust aspect. Yeah, now I don't see any other question on this particular part. No, another question. So I also read this one before moving forward. Verifiable credential is only used for verify the credential, but for pharma two, whether this is only one reference for the rest. Sorry, I'm reading it in my mind and then I'll go to for everyone who are watching the webinar and can't see the question. Verifiable credential is only used to for verify the credential, but for pharma two, whether this is only one reference for their assessment, but could not be used as an assessment result directly, because they may have their own assessment somehow. So is this only reduce the retype effort for the supplier. Thank you, Marta for reading in through in the meantime, I was thinking about the answer. No, so as I was mentioning before, right now the idea would be for pharma two is up to them to decide how much importance to give to this particular verifiable credential. And the idea behind is that most of the pharma, based on the level of the risk ratio that they need to evaluate, they could decide to bring the supplier instead through a full onboarding just through a lightweight onboarding. So also on pharma side, they will reduce their effort because they may say, okay, these are the company that I trust did already disevaluation. So I'm not going to redo the whole evaluation on my side. I will just do a partial evaluation because I can trust that some aspect has been already taken care of by the original issuer. So pharma one. Yeah. And this is the answer right now. Don't see any other question. So I will move forward. This was an introduction about the business, the use case and the why we decided to apply SSI. And now we are entering a little bit more into details related to the technical solution and we are going to talk more about hyper ledger areas and hyper ledger in the But before doing that, I would like to give you a quick context of what we are doing in Swisscom and why we are deeply involved with hyper ledger. So is we come we are currently offering different services in blockchain space. Mainly I would say that they are divided into different layer. The layer is infrastructure layer. So we provide the managed and unmanaged infrastructure, supporting different blockchain protocol. A per ledger fabric is one of the most protocol that we have a lot of know how internally, but then of course we also support other protocols such for example hyper ledger indie. That's why in this particular case, our know how on infrastructure for my pleasure, lindi was important and then later we will deep dive into it. And then the second layer of the offer as we come is mostly related to building blocks. So on top of this infrastructure service, we provide also typical blockchain capabilities that can be easily consume at the tourist API, such as notarization digital asset. But of course we also provide SSI capability. And that's why you see the block of decentralized identity and very fable credential is green. Because this is the component that we have been using to provide a solution for this particular use case. While in the infrastructure side, the color is yellow because as I will explain you later for this particular project, we didn't use our own managed infrastructure, but we did use sovereign, which is a public hyper ledger indie network that is available worldwide. And later I will also talk a little bit more in deeply, but to enter also to finish the context setting. In terms of SSI is risk when we provide this product called SSI gate that is a digital wallet that is capable to provide SSI capability to rest API. So whenever you have a software solution you want to enable this capability to issue credential verify credentials to credential this tool is done exactly to do that. Now, let's have a look on how we customize this tool in order to fulfill the requirement of this particular use case. So, in this, in this light we see a picture divided in three layer those are if you are familiar with SSI those three layer are quite normal, but they represent also our solution is made. First of all, you have the base layer which is the, the, the blockchain layer where public information are stored. Currently we support a different protocol hyper ledger indie of course is one of them for this particular project we have been using sovereign later we will deep dive into it. The second layer is what we call cloud layer. So, SSI is providing SSI gate is providing a cloud agent that is capable to manage all the operation related to talking with the ledger but also to exchange data in peer to peer manner with other identity wallet. And finally, the third layer is what we call edge layer so mainly where the actually the user is going to use the software from it may be a front end it will be an integration. Or it may be even a software that is going to be run it on premise of our customer. Let's deep dive into each single layer. And then I would like to tell you the challenge that we face at using those technology in this particular project. So, layer number one, as I told you the blockchain layer, what we call the idea layer. I say that we have been using sovereign which is a network based on hyper ledger indie. Hyper ledger indie for us is quite a key project because we believe right now is one of the most complete solution if someone intended to use SSI with the ledger underneath. Secondly, we already had a previous experience on using this particular tool. And also because of the generic involvement with hyper ledger, we were already aware on how the open source community is interacting among the hyper ledger framework. So for us was easy to start dealing with the other tool, not just hyper ledger fabric, which was our first topic when we joined hyper ledger. Then, if I may say the challenge that we face at using hyper ledger indie for this particular project, a little bit complexity. Despite hyper ledger indies is one of the most complete solution from our perspective is still a little bit complex to, let's say, spin up an internal know how about it. Secondly, we face at the more I would say use case related problem, the limitation on the very fabled credential side. So, whenever you are planning to issue a very fabled credential with hyper ledger indie. Right now there are limitations. So if you are planning to issue a very fabled credential similar to a passport, where you have like 10 or 15 attributes like first name last name date of birth, this can be easily done. But for our particular use case, the, the, the questioner, they were about 150 200 the question and these number of attribute doesn't fit from a technological perspective with the current limitation of the very fabled credential provided on top of hyper ledger indie. So there we had to come up with a solution that we are aiming to propose as a hyper ledger RFC in order to see if the community will like what we did and maybe it could begin a standard. So this particular solution is how to attach to a very fabled credential, any type of attachment. So you can attach a JSON file with the question and answer, or you can attach generic attachment such as PDF, or whatever. And of course what we need to achieve is to try to enforce a security because we know that very fabled credential are secure because are natively based on a cryptographic proof. But what about attachment then we need a way to link a securely verifiable credential with a snapshot of that particular attachment. And so this is, we explored the different solution for that. And then we implemented the one that we thought would have more sense for this particular case. And I said the future we are aiming to propose it as a RFC in order to have this part standardized. Finally, another challenge that we are currently facing. It's the private key management. So right now, if you remember what I showed you before here. I would say the 80% of our solution is the second layer is the cloud agent. This means that our customer where the data of the supplier is stored where the private key of the supplier is stored right now this data is stored within our cloud solution. So we could say that technically we are a custodial software right now. But of course this is not compliant with many security aspect, because from a requirement perspective, our customer they need to make sure that they are capable to manage their own data and especially to manage the private key. So this is where the edge layer so the third layer is playing a role, but the current problem with Hyperledger Indy that you cannot separate the management of the private key from the container of the data itself. So this means that right now we are trying to figure out the solution on how this can be achieved because at enterprise level from a security perspective where we are talking about PKI infrastructure and all these aspects, usually private key needs to be managed by an HSM so such as an hardware security model, but right now, based on how the Hyperledger Indy tools are done, it's very difficult to separate the private key from the data storage. And so we are actually facing this challenge and try to come up with technical solution also for that. But as I told you before, we didn't use directly Hyperledger Indy because we have been using Sovereign, which is a public network that is not directly managed by us, despite we are a steward, so we run a node to also be part of the consensus of this network, I would say. And we decided together with our customer to use this network for the productive pilot, first of all, because it's an existing infrastructure with a global scale. But then also because we know that we can easily switch at some point, if we believe the sovereign won't be any more the right solution, we can easily spin up a permissioned network based on Hyperledger Indy or another technology in order to keep the case up and running, no matter the ledger below. And while using Sovereign, the challenge that we faced, we are more from a business perspective. First of all, the onboarding process. So as Sovereign is managed by, I would say an open source volunteer effort, there are business governance rules that are set. So if anyone that would like to be recognized as a valid issuer in this network needs to go through a very quick, but still legal onboarding process, and this may be a small entry barrier to grow the ecosystem. And secondly, another very small entry barrier is that anyway, when you have to send transaction in Sovereign, there is a very small payment involved. But this is also true if someone is planning to do the same, for example with Ethereum, based on the type of solution that they would like to have. So onboarding process and payment, we see that are creating a little bit an entry barrier to give a generic feedback of our experience. Yes, and this is about the first layer, the DID layer. Then the second layer, it's about exchanging data. So whenever the supplier wants to send the data to Pharma 2, or whenever Pharma 2 has to issue a credential to the supplier, there is a peer-to-peer exchange of digital information that needs to be done somehow. Very similarly to an email, if I have to send an email to my colleague, I just send an email, but in this particular case, the peer-to-peer exchange of data is done following different type of communication stream. Of course, it's still based on TCPIP, so on internet protocol, but the standardization below is slightly different. In fact, in order to implement this particular peer-to-peer communication layer, which is very important, we decided to stick with the hyperledger areas standard that are actually rising thanks to the community effort behind this very interesting project called hyperledger areas. If you are not aware of it, what is happening there, mainly it's a community-driven effort to try to standardize many of the problems that we are facing in the SSI world. And this particular slide is showing you an RFC, so a request for comment with the number 302, that is exactly about interoperability between wallet provider. So if you are planning to implement an SSI wallet, my suggestion would be to try to stick with this particular RFC, because it's listing a set of technical requirements that you would have to consider. But if you consider those requirements, then your wallet will be automatically interoperable with every other wallet. So you implement your solution and then you will be already interoperable with our wallet, for example. Meaning that if pharma 2 decided to use a Swisscom as a wallet, but another company as a supplier, in fact, for this particular project, there was also another SSI wallet provider involved called the Spherity. Our two wallets, they can already communicate together. And this is very important because it means that interoperability, as you may already know, is the basis to allow ecosystem to grow faster. And also a little bit to create more competition and to have a more interesting market for the final customer, I would say. So to recap, our second layer is based, of course, there are various type of technology that are proprietary by us, but generically when we are talking about peer to peer data exchange, hyperlegger areas is the way we implemented it. And then finally, the third layer, and then I'm almost done, is the presentation layer. So when the user, how the user is capable to interact with this model of managing data, the presentation layer for this particular project. As I told you, right now we are dealing with the problem of non custodial approach. So in the next few months, we are going to release a software component that can be executed by our customer in their infrastructure in form of a edge wallet. So they will be capable to manage their data on their frame on their infrastructure without being as managing their data. But right now is not like that. So how their user are currently capable to interact with our software, our software is a B2B enterprise grade architecture. So for us is very easy to integrate, for example, to federate with identity provider. In this particular case, we integrated with Azure Active Directory, meaning that the pharma company employee can log in in our system through their pharma account. So we don't deal with their username and password. Secondly, some of the pharma company involved in this project, they decided to integrate our API in service now. So the procurement user that today is dealing with the assessment information, they keep using the same tool that they were used to. But when they click on some button, some button is also triggering some operation on our side. And then for example, we show a credential to the supplier. And then eventually some of the participants that are not willing to integrate the solution through REST API, but they would like just to start using it in order to understand the benefit. We also provided a very simple front end. For example, for the supplier to easily interact with the platform. And this is a very simple screenshot of the front that we provided. This is a very basic version. We call it MVP 1.0. But as you can see, imagine to be logged in as a pharma one, there you can see all the interaction that you had with other participants in terms of issuing credential or requesting to assess credential. And then of course you can navigate through the details of the credential, review the attachment, check the status of the credential if it's still valid or not. So any operation, any technical operation that can be done through REST API can also be done through this very simple UI. And then finally, this confusing picture, it's representing the current solution. As I told you below, we have sovereign. Then every pharma company can have its own identity provider. Let's imagine that right now just pharma one and the supplier are using our solution while pharma two is using another solution. But all these actors, they can integrate, they can talk with each other in a peer-to-peer manner thanks to hyperlegger areas. And as I told you, the connection is peer-to-peer. So going back to the topic of point-to-point integration that is a problem for scaling the ecosystem. In this particular case, every company they will need to adopt the technology once and after that they will be capable to talk with all the participants involved in the ecosystem. And these we consider that quite a very nice benefit especially for this use case. Yeah, and this is it from a technical perspective. I hope I was clear. So now I think if there is any question, I would be very happy to answer those. Thank you, Luigi. This was really interesting. I actually didn't realize how much you've been doing and the information that you provided also about working with hyperlegger Indy, Aries, that's all very interesting. So maybe not directly about your solution, but something that I'm very curious about. How did you find the process of working on our RFCs, so requests for comments and submitting new features to the hyperlegger code base, you know. So Escom is a big company. Many big companies don't really like working with open source and contributing to open source. I'd love to hear your experiences there. Yeah, so well, I would say that our team, a small team, we are more into this open source approach. And luckily we have some sort of flexibility despite we are under the Eswisco umbrella. The particular topic of trying to push a standard within a per ledger areas framework, I would say that technically is quite easily, but it's more because there is so much going on today in the identity space that it takes a lot of time and discussion, technical discussion, more than business discussion to really get a consensus on top of technical suggestion. And I would say that this is a little, I feel this is maybe a little bit a challenge because I think that on our side, thanks to this project and other project, we may have a view coming a little bit more from a business perspective. So I would say that this view is quite important, but sometimes, because most of the people there is technical, it's a little bit difficult to, I glide to the importance of small business aspect during those discussion. So my personal feeling that somehow sometimes people give more attention to technical low level aspect. And that's why I feel a little bit tricky. Yeah, well I guess you could say that especially with building an SSI we want to, or community wants to do it very, the right way from the very beginning because I don't think you know, if a supply chain fails because someone made an architecture error then it's slightly better than if someone's very secret in healthcare information fails right. That gets revealed. In the meantime, two questions came in, and I'll read them to you together, and you can decide how to answer. You said one of the challenges with using Hyperledger Indy was how it deals with private key management. Can you explain the issue in more detail, and also which features do you wish Hyperledger could offer for your supplier solution, but are not currently available today. I feel like the anonymous attendee is part of the Indy team and wants to improve Indy. Cool, that's nice. So first, the first question related to the private key management. Right now, as I told you before, the requirements from our customer are to store the private key or the secret generating the wallet that we actually generated through the usage of Libindy. And this wallet right now may be in form of a SQLite file or a Postgre file. So Libindy itself right now, for us, is a black box piece of code that is managing how to generate and encrypt this wallet, but also how to manage the wallet itself. In order to separate the private key management, so to extract the private key and have the private key stored in some sort of HSM. Today, we will need to deep dive into the Libindy source code, which for us would be a big effort because Libindy for some aspect is quite complex, especially from a cryptographically perspective. This is a very interesting project, which is listed under the RFC, if I'm not wrong, from Mike Lodder, which is one of the lead of Hyperledger Ursa, which is called the LOX, that is trying exactly to decouple the private key management out of Libindy. And we are monitoring that, well, not closely, I would say, because last time I checked it was few months ago, but the solution that Mike is working on, maybe exactly what we are looking for to solve this issue. And to add to that, in the meantime, I did contact some friends in the Aries community and got information that Aries-Askar is the next generation Aries storage and that will be the next implementation in the next release of Aries. This will come and will decouple the key storage from other storage management. Ah, that's great. How is it called, you say? Aries-Askar, A-S-K-A-R, I'll just put it in the chat so that everybody can see. Okay, and then the second question was about what features do you wish, your wish list for Hyperledger? So, from the tool that we currently use, well, first of all, I'm really looking for, right now we don't use any Hyperledger Aries tool, we just implement the RFC on our side in our source code. Because we did, I would say, a technical evaluation of the current Aries available library, the Python one and the Go one and the .NET one. For cultural reason, we are not so much into .NET. We are really looking forward to see the Go version growing because this will really help us to abstract part of the work that we are currently developing on our side. While the Python part, which, if I remember correctly, is the one that has been created out of Libindi, I feel it is still a little bit too much related to Libindi. So, to the layer number one, the DID ledger stuff, which for some reason I have the feeling it creates some sort of limitation. So, the more those libraries are implemented, and the easier it would be for us as we come, improve our solution, but also for anyone that would like to spin up a similar wallet, SSI wallet, I would say. Great, thank you. Very good answer. Okay, well, just to wrap it up, I wanted to let you know that we have two coming webinars. The first one will be on October 21st, so next week. This will be on unsolicited commercial communication, which will be a webinar delivered by Tech Mahindra. And it's all about telecom use cases and preventing fraud and spamming. And then in November, first of November, we will hear Julie Esser from CEO ledger talking about how credit unions are using member pass to improve the member experience. This will be an update to various work that they have been doing or see ledger has been doing. And loads of interesting outcomes of their work. So even if you heard Julie talking about global at global forum, I am pretty sure that this will be new content. That's how we discussed it. Hyperledger Global Forum talks and all of the presentations are available online. So if you are not, you don't have enough video calls in your life, you can always watch some more presentations. But seriously, some of them have very good technical content. So it's worth watching to learn more about the projects about about different use cases. If you have not yet, please get involved. We love new community members. Email us, come to our chats, come to our meetings, all of them are public. And let's stay in touch. Thank you again. Thank you very much. And I'll see you next time. Thank you. Thank you for your time. Thank you, Martha. Bye.