Hi guys. Welcome to the first TDS Reference Group webinar of 2020. It's great to have you all along. We've got quite a few things to update you on today. Obviously, our last webinar was back in October of 2019, so we've gotten through quite a lot in terms of our API build, so I'll share the roadmap with you and go through a couple of demonstrations.
Just in terms of housekeeping, for regular participants you probably don't have to listen. It's like an emergency announcement for a flight, but it's just general housekeeping, so we're using GoToWebinar for today's session. It's best to leave any questions that you do have for our QA session at the end of today's session. We'll also have opportunity for questions after the technical demonstrations at that point.
The webinar will run for roughly 30 minutes or so. We don't want to keep you guys here too long over lunch. We want to be efficient. Please advise us if you cannot hear or view our screens throughout the webinar and we can try to fix that for you. The webinar will be recorded and available after today's session. There'll be an email with a link to the recorded session sent to you guys either this afternoon or probably tomorrow with those details.
So today's agenda, as I said, our last TDS webinar was held back in October. If you are new to the TDS Reference Group or a new participant in our webinar series, again you can catch up on all of our previous webinars by our website. So there is a link on our final slide as to how to get that, but also there'll be a link in the email following today's session.
Okay, so today's webinar, just in terms of an agenda, we'll kick off with some API demonstrations. So Cam, one of our lead delivery managers will run us through a technical demo of new patent application API's which we released into production in December, 2019. Cam's also going to briefly demonstrate some high volume trade mark amendment types just to show our new customer API, which went into prod back in October or September, October, 2019. We'll also run through I guess a high level demonstration of our new correspondence API. That went to production in November, 2019. The way Cam will run these is fairly high level and then fairly brief.
If there are any stakeholders participating that are interested in a deeper dive and a bit of a more detailed demonstration, please contact us by our inbox, and again the details will be on the final slide today. And we can arrange a session offline via conference to take you through the details of those APIs in a bit of a deeper dive. So we're always available to do that for interested parties.
After the API demonstrations, I'll give you a high level program update about what sort of progress we've made from October to now. We'll have a look at the delivery roadmap of where we're up to and we'll briefly speak about the commencement of our planning for a web offering using our API. So that'll be ultimately the replacement for our eservices platform.
I'll then provide an update to you guys about some improvements we are in the process of making to our API developer portal. So that's through a little bit of feedback, but also just an upgrade of a version and really uplifting the experience a little bit more for our API consumers. So we'll take you through some of the work there. We'll go through and as always we're keen to measure satisfaction and how are our engagement's going with this reference group, what people like, what people don't like and the frequency of communication. Then we'll talk about what's next in terms of a webinar. So we'll look at the next webinar session sometime in April and we can sort of talk about what that agenda might look like. And then we'll have a quick Q&A session for any questions that you guys may have throughout the webinar and we can answer those for you.
All right. So, API demonstrations. We'll lead off with Cam, but just before Cam gets started, I'll just give you some brief context about what we're going to show you. So as I mentioned, we deployed new patent application APIs into production in December of 2019, so that includes all of the new patent application types, provisionals, standards, and innovations. We released our correspondence API in November, 2019. The correspondence API provides consumers the ability to poll, regularly poll this API for more timely access to correspondence. So that's really going to improve the turnaround time for correspondence, getting back to your clients and shutting down that process as quick as possible. So rather than waiting overnight and well, in some instances, a few nights or a week, for our correspondence to be delivered in e-services or B2B. This way you can actually grab it as soon as it's ready, if that makes sense. But Cam will sort of unpack that a little bit in the demonstration.
As always, we strongly encourage customers who have registered to our API program to jump in and test some of these things. So everything that's in production is available in a test space. We can help you guys out with conducting those tests and giving you the appropriate data to do those things. Please reach out to us. For anyone new, so anyone who hasn't registered for the program, please get in touch. We're getting new customers each and every day integrating and testing and going to production. So customer uptake is increasing quite quickly now that we've got a lot more transactional coverage.
So that's probably not enough for me. I'll hand over to Cam who will sort of lead us through the demonstration. Again, I think it would be worth leaving the questions at the end of this, at the end of the demonstration session and Cam can sort of answer those as we go at the end. Again, Cam's going to take us through a high level demo and it's fairly brief. So if you're interested in a detailed demonstration, then please contact us. Cam, I'll hand over to you.
Yeah, thanks Josh. So as Josh said, pretty recently the TDS program has completed I would say 99% of service requests coverage now through the APIs. So, for patents and trademarks that is. So I'll just be giving a brief update on the patents new apps, API for starters, and the correspondence API. And I'll quickly delve into trademark customer amendments, which is reasonably simple.
So basically, I'll start with the patents, new apps API. And just for context for anyone else who hasn't seen one of these demos before, I'm just using Postman, which is essentially a testing harness or a mock for sending messages to the APIs. I'm sure most of you guys understand there's no UI or anything like that to see for machine API communication. So essentially I'll kick off the demo for patents new apps, and just for context, I think previously we have given demos of how we handle both attachments and customer transactions with IP Australia through the API.
And that is handled through a separate API endpoint respectively, both for any attachments that need to come in with requests and for customers when you're creating a new customer for your client that you may want to attach to a patent new app for example. So I'll just quickly touch on the customer API first, which will play into the patent new application. And that same thing goes for the attachments that need to come in with a patent new app or any other service request in terms of a request documents or claims or descriptions and things like that.
So essentially the customer API is a very simple API in which you can record or create customers in your own private address book. So obviously respectively for each customer, you guys would have your own client book and this is how you register those customers with us and then reference them in a service request. And again, if any of this kind of doesn't make sense or you're new to it, please reach out to us either at the end of this or through email and we're happy to take you through it in a bit more detail.
But essentially I'll just kick off with a regular individual contact. As you can see, the payload is fairly simple. It's just the relevant details for the contact or the person which you'd like to create. And that should come into IP Australia through the API and then you will get a... Oh, sorry, just bear with me while I deal with the mouse. Once you've sent a payload in to us, you will get a response with an identifier and that is what we call a customer identifier. That is the unique ID for that customer, which you can reference over and over again if you keep dealing with this customer. That way you've got one unique ID which should help for data control issues. You'll get obviously a message to say that it was created on our end and that was the ID. So to reference it and then I'll jump across to the new app, actual payload.
So this is the patent new application payload. And in that you can see throughout the payload there's reference to for example, the agent's customer identifier, which would be whoever's submitting it, and again for the contact. In the payload, you've obviously also got reference to the document's IDs for whatever the document may be, which is required. But I'll circle back to that in a second. But the relevant part for the customer creation and the customer ID is for the obviously for the applicants or the owners of the patent or whatever transaction you might be after. And you simply reference that customer ID which you just created into the payload and that will reflect in the application itself. So again, for patent's new applications in particular, they're quite complex in terms of the array of different service requests and satellite service requests, which you might be able to file with those.
Again, I'm not going to go through each and every one of those. For example, divisionals, additionals and all those types of things and exam requests. They are all covered and we have completed development for those. So again, if you jump into the developer portal, you'll see all of the different variations there. And again, if you want to see this in more detail we can take you through what some of those variations might look like or how to kind of get across those.
But again, this is a very simple patent new application demonstration, so it's merely just a standard application which you can see referenced as the patent type. It's just got the description and the claims and the indicator for a non patent literature, which might be a little bit kind of new, which is just to indicate that you have NPL inside the request and it will just flag on our end so we can pick it up immediately. You also list the technology category and the inventors. Something that may be worth noting is that inventors are handled not as true customers, so hence they don't need an ID to come in with them.
They don't need an ID to come in with them. They are just recorded as metadata on the application. And again, the inventor order is reflected here, so whichever order you send them to us in, we will reflect that on the patent application. And then, as you can see here, we have the documents. So just circling back to the document API, obviously there's a separate end point for creating all your documents. It works in a similar pattern to the customer API, and that is that you just attach whatever relevant document you may have and the IP right type line that goes with that document, and you will get a unique ID back, as you can see here, to say that we've received the file but we haven't filed it, it's not deemed filed. And that happens through the patent application or whatever service request it may be.
And the same attachment API works across the board for all service requests. So for example, if it was a trademark, attaching representations or something like that. I obviously uploaded the description document and I'll upload a claims document as well. Again, it's the exact same thing. It's just a different document that I'm attaching. And those documents are referenced here in my patent application. Now, that all the data's filled out and the documents are attached and I've listed the invention title, I'll send that to IP Australia, and hopefully, the live demo will work. Cool, it has.
You will then, in the response, be given your batch ID, which is this number here and you'll be passed back your patent application number and any other identifier that was passed back. For example, if it had a net phase entry number with it or something like that, that would also be sent back to you. And the other thing you'll get back is a fee, whichever relevant fee goes with the specific SR type you're doing. If it's an innovation or a provisional or something like that, the price is obviously different.
Yeah, in a nutshell, that's basically patent new application. Obviously, it’s much deeper in terms of showing all the different variations and the complexities that can come with it. But again, I'll probably won't go through that in detail today. I'll just keep it brief. I might dive into the correspondence API next, which is probably the next biggest thing for us to show. Again, it's a separate end point. So we have the correspondence end point, which you hit in the same way you do all the others, I guess. It has a number of functions. For example, you can just hit the correspondence endpoint and it will return every piece of correspondence you have and the metadata that's related to that.
However, you can filter that on things like document type, the status of the document, the IP right, for example, and then a current, new feature which we're trialling in UAT at the moment, and we're happy to have feedback on, is actually persisting the metadata out of some of these templates through a JSON payload instead of having to open the PDF document itself and screen scrape them or use whatever kind of mechanism you've got there. And I'll show you that in a second. Sorry, if you can't see, I'll try and get a better picture of it. I've just hit the correspondence endpoint and it's returned every document that's associated to my customer ID, and it lists, obviously, the identifier, the document batch identifier, the type of document it is, the IP right which it is associated to, and then the actual document itself is here as well.
So if we were to take this as an example, once I've got the metadata of the document, this end point, which is here, can be used to retrieve... Sorry, just bear with me for a second. This end point here can be used to retrieve the PDF itself, the actual document. Obviously, our postman doesn't love opening those but it has downloaded it, and I can just see that it's download this document here and I should be able to just open it if I can find it in a sec. Just bear with me for a second. And there you can see hopefully you can see my screen in terms of... Just bear with me for a second. Hopefully, you can see my screen to see the actual document itself that I've retrieved from the correspondence API.
Again, they don't look any different or anything like that. It's more just this is a better, faster way of retrieving those documents. And I'll just jump back to postman for a second. Okay. Yeah, just jumping back to the postman itself, the way the documents come back to you a little bit quicker, which might be a question you have, is that as soon as they're ready on our end, so as soon as our system has processed them or a user, if it might be a business user, has processed the service request and they become available, you'll receive them as opposed to a batch going out overnight or in a couple of days, as Josh said, which is the way our current MFT and eservices solution works. This is immediate. So as soon as they're available, you can look at them.
For example, that if I did a trademark new application, the correspondence on our end is probably spat out within about 10 minutes. So within 10 minutes of applying for your trademark through the API, you can have your filing receipt back and hopefully that helps you guys get back to your customers quicker and shut that transaction loop down a little bit, which should save you guys time hopefully. So those are some of the bonuses of the correspondence API. Just quickly, I'll jump into the way you can filter on the correspondence API.
There's a number of different ways to do it, but as an example, you can filter by IP right. So if you're already had a particular IP right, the correspondence you're looking for, it will just return any document related to this IP right, which is the one I'm searching for. And obviously, the metadata and whatnot you can check for and you can check by status. So if you, for example, wanted to poll the correspondence API every 10 minutes or every hour or whatever kind of interval you like, you can set it to check for any documents which you haven't retrieved already in a set amount of time.
And the last part of the correspondence API is probably worth showing is the correspondence metadata piece. Again, for any of our MFT customers, this is something which is embedded inside the PDF documents previously to help automate correspondence on the customer end there. All we've done is simply exposed that same correspondence metadata JSON payload so it can be retrieved via the API instead of having to physically open the PDF docs and retrieved them that way and the properties.
As you can see, for this particular correspondence which I retrieved, this is what metadata is available. Obviously, that depends on what type of correspondence, etc, and we are looking to improve and increase the scope of that in the coming months. Again, that's a dependency item on another project, but we are working through that and we are open to any kind of requests. We can see if we can facilitate any extra things which people might like. So that's pretty much all I've got in terms of the demo. And I'm just mindful of talking too much, which is probably already happened, so I might just quickly jump back to questions. If there's any, feel free to type them in there.
Or, there's a hand up functioning you can use if you want to speak verbally, so we've got a couple of questions here that we'll unpack. Which of the current APIs are considered production as opposed to beta and alpha?
Yeah, that's a good question. Everything which we've showed you and we have a large number of, I guess, a massive number of service requests which is available, I'd say 99% of the stuff is available in production. The only part I've showed which isn't is that correspondence metadata piece, which again, was something that we were trialling. But if people are keen to use it and it's something that's useful, we can productionize that probably within, I would say, a week or two. Again, it's not hard for us to turn these things around, especially once they're in a UAT environment.
We've got a list of what is available on our website, so we'll maybe include that in the email post session that goes out. That will have to be regularly updated because we've got three week sprints here that we develop these APIs in, so it moves quite quickly. But there is a list there, and also our developer portal, will have a clear list of what is in test, what is in production. So there's a couple of ways to do that. But really good question. The next question there is have you now fixed the correspondence created date time to match the date of the correspondence itself as these are currently often different?
Yeah, this is one we've been digging into a little bit and we are working on it. We are, again, constrained by the fact none of the TDS systems generate this correspondence. We're just able to retrieve it. So I guess we are working on it would be my answer. And look, this is obviously in respect to the fact that on the payloads you get back, the date the correspondence was created in this source system might be slightly different to the date we've dispatched it or something like that. So yeah, we're working on it would be my answer. And we can probably come back to that one offline and have a chat about that.
Yeah, definitely. I think that the new mechanism, the new API providing the correspondence generally should be the same date because of the quick turnaround. But there will be exceptions there, but we can take those offline.
Yeah, cool. A good pickup. We have also completed ITPs production, and that's something else that we've finished. As Josh said, probably more broadly, there's a list on any point obviously of what's in production and what's there. I don't have a demo set up check, sorry, to run through ITPs. But again, hit us up offline and I'm happy to take you through that. And maybe that's something we might talk about, which is if you guys want to see particular demonstrations or, now that we're close to the end of patents and trademarks, if there's stuff we haven't shown, which I'm sure there's hundreds of transactions we haven't demoed individually, please reach out to us and we can get back to you. And maybe that's a little bit of a better way for us to show you guys what you want to see as opposed to what we're guessing I guess what you'd like to see. So yeah, we have finished ITPs and they are available in production. If that's something you'd like to look at, actually we might contact you after this just to go through that one.
All right, we might move on, guys, to the next slide. Thanks Cam for those demonstrations are really valuable. The next slide we've got, which should come up for us now, is the TDS roadmap. Matt's just getting the slide up for us. On screen now you should say I'm delivering roadmap. Again, as I said, since October, 2019, our last session, we've come a fairly long way. Cam mentioned a couple of times, we've almost got parity in regards to patents and trademarks transaction coverage. So what I mean by parity is our API channels service close to a hundred percent of the transactions available in a services or current B2B. So we're edging closer to that in patents and trademarks.
As you can probably see on our roadmap, and as some of the registered customers would know, we have just commenced designs development. So we're quite ahead of our scheduled time in the API bill, which is great news. We've started on the designs new app process, and the first APIs that we're developing is obviously new applications, but also some of the satellite or additional requests to those, things like request to register a design, request for publication and request for examination.
Our request for publication and request for examination. At the moment in the current sprint we're looking at completing the remaining functionality for patents and trademarks, extension of times and some opposition in hearings transaction types that we've got going. So we'll update our available API list on our website with that information at the end of the sprint.
As I mentioned that at the start of the webinar and obviously there is significant interest in what our new web offering might look like. We have commenced the planning of the web offering that we're proposing to develop, so that's some time away from actually starting intensive development. But the planning, some service design pieces, some associated legal pieces of work are currently just commencing. So that that work in terms of development, will start prior to the end of this financial year, and a lot of you can expect to be involved in terms of consultation, testing, all sorts of participation will be required from the customer end.
Again, the MO of this program is to build for you the customers, so we're not doing things by assumption here. It's validating what is of value to the customer and what makes sense. So customers will be central to that development process.
Again, with the roadmap, if you're interested on some of the components on this roadmap or you want to be more detail. Again, like we keep saying, get in touch with us.
So we're in the process of optimizing that documentation as well. So not just the look and feel of the platform and its features, but also improving that documentation based on feedback. So that's something that's going to continue to happen and hopefully in the next webinar we'll have a good update and something in production by that point to show you guys.
Next slide. So again guys, as I said at the start of the webinar, we like to measure how our engagement's going within this webinar and they've been outside of, so we've just got a quick survey up which will take half a minute. Please complete, and we can sort of move on to the next slide. I'll give you guys just a minute and we'll continue. Okay.
Okay, we'll close that poll off. Thank you guys for that. It's good for us to measure this and form ways to improve where possible in terms of our engagement. As I said, these APIs, and the new web offering, it's all about building for our customers. So engagement is really important to us.
What's next? As I mentioned, the next webinar is slated for April. We haven't got a specific date at this stage, but we'll get an invite out to this reference group in the next probably week or two with a bit more detail about the agenda, that sort of thing. But we'll probably cover off, we'll cover off a couple of designs, new applications next session and we might even see if we can source from you guys what would be valuable for our demonstration. If there's particular things that you guys want to see, please let us know and we can actually prepare direct demonstrations based on what you see valuable.
So feel free to let us know at any point what you want to say, whether that be offline or during these webinars. We'd love to collaborate with you. All right, so finally we'll just open up for any questions. So we've gone through all of the information today, all of the updates. Feel free to type some questions in or raise your hand and we can answer those for a couple of minutes. And then we'll let you go.
So we've got a question about the website redevelopment. Some of the other IP offices internationally block multiple tabs, windows for search results. Is [inaudible 00:31:44] intending to retain that functionality in whatever is created?
I'll take that one. So as I say, we're not anywhere near that level of detail in terms of what we're delivering, especially around look and feel. We're really in the stages of planning.
Procurement or legal, all those sorts of things.
But it's good feedback.
It's good feedback, and definitely will, like Josh said before, one we get into the crux of that and the real nitty gritty, you guys will definitely be people we'll be relying on to get this feedback and touch base with. So we might circle back to that one probably when we know a little bit more about how it will look and how it will feel, but we'll definitely keep these things, definitely keep these things coming to us and we'll keep them in the back of our minds.
I think our plan at that moment, so again, Cam's spot on in terms of where we're at currently. We do plan to do some UX consultation and some mock ups about how the look and feel of the new web offering might or how the experience might actually be. So this feedback's really good and again please reach out with any other feedback about the web. We'd love to get it. We've got a whole heap through user research over the years, but you guys are the ones we're building it for, this is the type of feedback that we need to start developing that experience on top of these APIs. So really good question and we'll document it from this webinar and create a task in our build and our sprint program for the web build.
Any other questions guys before we let you go? Again, if you don't want to ask them here, definitely feel free to get in touch with us via email, phone. I might get Matt, just to put up our slide of how to contact us, just while we wait for any other questions and then we'll finish up. So that's a slide with the detail, our direct inbox, that's probably the best way to go about contacting us. Whether it be for feedback, whether it be for setting up a video conference session for a demonstration, whether you just want to chat. That's probably the best way to get us. We've got a whole dedicated team looking at inbox and a mixture of skills. So we've got development teams, we've got product owners, we've got BAs, we've got business SMEs. We cover the spectrum in that sense, so definitely let us know.
We've just got another question come through. Do you offer credit card payment functionality in the API system? Yes, we will offer credit card payment functionality in the API system. So currently Mark, just for your information in the current API channel, the only payment method we currently offer, online currently is direct debit, but we want to expand that to credit cards as well. That's not too far off. The web will definitely offer it, but we actually want to offer it through the direct APIs as well. We're also looking at other payment offerings such as PayPal and that sort of thing. So modernising the alternate payment options that we currently provide. There are limitations now in what payment options we offer, so we definitely want to expand on that. So any feedback on that would be great. But we will definitely offer credit card payments in the near future in the API space.
Okay. All right. We might wrap up, guys. So any other questions, feel free to shoot them through offline. I just want to thank you guys for participating today. It's always helpful to us that people are interested in hearing about this API program. And as I said at the start of the webinar, customer uptake is really increasing and interest is really increasing currently with the amount of transactions that we're offering. So if you want to know more, please jump in on the links that we've got on the slide, or get in contact with us at our email address, and we can chat directly to you. Thanks again guys, and have a good night.
Transcript: Transactional Digital Services Program: Sixth reference community webinar