problem with POST request for DOCDB (that was fixed in November) is back in the current version

This space is made available to users of Open Patent Services (OPS) web-service and now also to users of EPO’s raw data subscription products such as 14.7 DOCDB - worldwide bibliographic master database, 14.11 Worldwide legal status (INPADOC), 14.12 EP full text in XML, 14.1 EBD and more.

Users can ask each other questions, exchange experiences and solutions, post ideas. The moderator will use this space to announce changes or other relevant information.
Post Reply

jalipert
Posts: 13
Joined: Wed Nov 15, 2017 5:16 am

problem with POST request for DOCDB (that was fixed in November) is back in the current version

Post by jalipert » Sat May 05, 2018 11:16 pm

EDIT: see correction below.

Hello,

There used to be an issue querying multiple patents at once in docdb, where if any one of the input patent numbers were not found, the entire response to the API call returns SERVER.EntityNotFound - No results found.

That problem was fixed in an update back in November, 2017.

But now the problem is happening again. I'm not sure at what point it was reintroduced. To reproduce, try the following input to docdb biblio:

EP1000000,EP1000001

It correctly returns 2 results. Then try sending the following input:

EP999999999,EP1000001

The entire response fails, when it should at least return the correct results for EP1000001.
This makes it so that docdb can not be reliably used for biblio requests in batch. I hope this issue can be fixed.

Best,
Joe

-------------------------

EDIT: actually, I seem to be affected by a different issue, after looking into the problem more deeply. I thought this problem had recurred, but in fact docdb no longer has biblio data for EP1000001 at all which led to the correct response of "no results found" in my case. (EP1000001 used to have biblio data, and in fact, it used to be the sample patent used in the API client for batch requests along with EP1000000).

But the issue I'm facing now is I'm getting an Ambiguous input response, which also kills the entire batch call, when it would be more useful if correct results were returned for the good inputs, and ambiguous resolution responses for the bad inputs. I'll write this up separately as another post once I have the time.


EPO / OPS Support
Posts: 942
Joined: Thu Feb 22, 2007 5:32 pm

Re: problem with POST request for DOCDB (that was fixed in November) is back in the current version

Post by EPO / OPS Support » Mon May 07, 2018 8:45 am

Hi,

Thank you for letting us know about this issue - it turns out that two document (EP1000001 and EP1000002) were removed in December and by mistake. We have already contacted colleagues in charge and ask them to re-trigger those two documents back into the database

As far as ambiguous seed, it appear if you don't use kind codes. If you do you will not get any. This is the future and its very important especially because some jurisdictions keep publication numbers same for all publication steps and some change numbers with every new publication. We cannot remove this function, it’s very valuable to us internally as well as to many other users. You just have to add kind codes with your requests to avoid the seed.

Regards,
Vesna for OPS support


Post Reply