Concept of "priority" in OPS
Posted: Tue Oct 29, 2019 1:24 pm
I have observed that the concept of "priority" as used in OPS deviates fundamentally from what was meant by "priority founding application" in the Paris Convention. Namely, virtually any filings, whether priority founding or not (even divisional or continuation filings which by law cannot be priority-founding) become "priority claims" in the OPS concept. The consequence is an excessive number of priority claims for many patent publications. I have observed in one US publication nearly 500 such purported "priority claims".
OPS seemingly provides a field "priority-linkage-type" which should allow to determine which of those "priority claims" are priorities in the sense of the Paris Convention. This field should apparently contain codes from Annex III of the Docdb User Manual. However it emerges that for most queries to OPS that return "priority claims" this field is simply "null" (not populated at all).
I have been told by OPS support in my other post "Retrieving publications for given application number using CQL code "sap"" that I should use
.../rest-services/family/priority/docdb (with docdb number format)
to obtain "priority-linkage-type" information. I do however not want to obtain artificially inflated families according to the inpadoc "extended family" concept. Furthermore I have experienced from my earlier searches in inpadocdb errors (such as mix-up between families or omitted publications) in inpadoc "extended families".
It appears to me that OPS should populate ANY responses (not only responses to "family" requests) that provide "priority-claim" data also with the corresponding "priority-linkage-type" information. Otherwise the provided "priority claim" data will be useless - it will be impossible to decide which "priority claims" are true priorities in the sense of the Paris Convention. "Priority claims" should in my view only be those applications the priority of which is actually claimed, as indicated on the front page of patent publications under INID codes (31)/(32).
Preferably OPS should also provide a search criterion that allows to retrieve only those publications that have the priority number indicated in the query AND wherein that priority number is of given "priority-linkage-type". This could be implemented like a "proximity operator" in inpadocdb.
mike_k43
OPS seemingly provides a field "priority-linkage-type" which should allow to determine which of those "priority claims" are priorities in the sense of the Paris Convention. This field should apparently contain codes from Annex III of the Docdb User Manual. However it emerges that for most queries to OPS that return "priority claims" this field is simply "null" (not populated at all).
I have been told by OPS support in my other post "Retrieving publications for given application number using CQL code "sap"" that I should use
.../rest-services/family/priority/docdb (with docdb number format)
to obtain "priority-linkage-type" information. I do however not want to obtain artificially inflated families according to the inpadoc "extended family" concept. Furthermore I have experienced from my earlier searches in inpadocdb errors (such as mix-up between families or omitted publications) in inpadoc "extended families".
It appears to me that OPS should populate ANY responses (not only responses to "family" requests) that provide "priority-claim" data also with the corresponding "priority-linkage-type" information. Otherwise the provided "priority claim" data will be useless - it will be impossible to decide which "priority claims" are true priorities in the sense of the Paris Convention. "Priority claims" should in my view only be those applications the priority of which is actually claimed, as indicated on the front page of patent publications under INID codes (31)/(32).
Preferably OPS should also provide a search criterion that allows to retrieve only those publications that have the priority number indicated in the query AND wherein that priority number is of given "priority-linkage-type". This could be implemented like a "proximity operator" in inpadocdb.
mike_k43