Thursday, October 13, 2011

About chained patent priorities

The priority date, sometimes called the "effective filing date", is the date used to establish the novelty and/or obviousness of a particular invention relative to other art.(cit)
In patstat patent priorities are contained into table TLS204, and linked to applications via appln_id.

Anyway a certain percentage of applications have a link to an application in TLS204 that is not the 'ultimate' priority.
For such cases, in order to calculate priority date or families or equivalents, we need to set up a nested procedure allowing us to recollect all the priorities of a given application.


By setting up a simple procedure that recursively looks into TLS204 we would have these results all over patstat 201009, where # of chains indicates the max number of further priorities of the given application.

# chains
# apps
%
0
22135982
93,95%
1
1310961
5,56%
2
35096
0,15%
3
2489
0,01%
4
412
0,00%
5
70
0,00%
6
20
0,00%
7
2
0,00%
8
2
0,00%
9
2
0,00%
10+
76012
0,32%

The line 10+ indicates nested priorities where the recursion would go in overflow, since we would have cases like A has priority B that has priority A...

One example is US3740273 whose priorities (CH512809 and CH502677) are priorities one to the other...

We can get rid of latter case by stopping recursion when filing date of nested priority is greater than filing date of the given priority.
In this case the counts come out like this:


# chains
# apps
%
0
22239328
94,39%
1
1284631
5,45%
2
32649
0,14%
3
3546
0,02%
4
660
0,00%
5
197
0,00%
6
31
0,00%
7
2
0,00%
8
2
0,00%
9
2
0,00%

 

Obviously such algorithm works fine for calculating older priority date of application, is not fine for calculating full chains of  priorities that are needed for calculating families and equivalents.

We may furthermore want to see how such algorithms performs by application authority, getting such data and graph below (cutted on authorities with more than 100.000 applications).
We may comment that, apart from AT, all patent authorities have 10-5 % applications with 1 or more chains and <<1% with more than 1 chains.



Application authority
# chains
# apps
%
'AT'
0
675024
84,45%
'AT'
1
122103
15,28%
'AT'
2
1975
0,25%
'AT'
3
171
0,02%
'AT'
4
19
0,00%
'AT'
5
3
0,00%
'AU'
0
1213127
92,52%
'AU'
1
95617
7,29%
'AU'
2
2188
0,17%
'AU'
3
208
0,02%
'AU'
4
34
0,00%
'AU'
5
1
0,00%
'BE'
0
313636
96,37%
'BE'
1
10814
3,32%
'BE'
2
835
0,26%
'BE'
3
129
0,04%
'BE'
4
30
0,01%
'BE'
5
13
0,00%
'BE'
6
2
0,00%
'BR'
0
284927
94,40%
'BR'
1
16469
5,46%
'BR'
2
417
0,14%
'BR'
3
24
0,01%
'BR'
4
4
0,00%
'BR'
5
1
0,00%
'CA'
0
1683211
95,75%
'CA'
1
72449
4,12%
'CA'
2
1953
0,11%
'CA'
3
205
0,01%
'CA'
4
34
0,00%
'CA'
5
3
0,00%
'CH'
0
511624
97,63%
'CH'
1
11337
2,16%
'CH'
2
950
0,18%
'CH'
3
93
0,02%
'CH'
4
26
0,00%
'CH'
5
11
0,00%
'CH'
6
4
0,00%
'CN'
0
804791
95,70%
'CN'
1
35797
4,26%
'CN'
2
303
0,04%
'CN'
3
21
0,00%
'CN'
4
1
0,00%
'DE'
0
2354154
94,24%
'DE'
1
139503
5,58%
'DE'
2
3799
0,15%
'DE'
3
398
0,02%
'DE'
4
87
0,00%
'DE'
5
27
0,00%
'DE'
6
12
0,00%
'DK'
0
298345
94,00%
'DK'
1
18464
5,82%
'DK'
2
528
0,17%
'DK'
3
32
0,01%
'DK'
4
4
0,00%
'DK'
5
1
0,00%
'EP'
0
2192201
94,30%
'EP'
1
130418
5,61%
'EP'
2
1865
0,08%
'EP'
3
167
0,01%
'EP'
4
28
0,00%
'EP'
5
1
0,00%
'ES'
0
537197
96,40%
'ES'
1
19413
3,48%
'ES'
2
599
0,11%
'ES'
3
45
0,01%
'ES'
4
14
0,00%
'ES'
5
2
0,00%
'FI'
0
143551
94,74%
'FI'
1
7630
5,04%
'FI'
2
324
0,21%
'FI'
3
19
0,01%
'FI'
4
5
0,00%
'FR'
0
711638
96,11%
'FR'
1
26628
3,60%
'FR'
2
1808
0,24%
'FR'
3
264
0,04%
'FR'
4
51
0,01%
'FR'
5
25
0,00%
'FR'
6
2
0,00%
'GB'
0
1156897
96,14%
'GB'
1
43464
3,61%
'GB'
2
2554
0,21%
'GB'
3
337
0,03%
'GB'
4
80
0,01%
'GB'
5
26
0,00%
'GB'
6
4
0,00%
'IL'
0
135708
92,34%
'IL'
1
10896
7,41%
'IL'
2
322
0,22%
'IL'
3
35
0,02%
'IL'
4
3
0,00%
'IL'
5
4
0,00%
'IT'
0
224289
96,89%
'IT'
1
6898
2,98%
'IT'
2
260
0,11%
'IT'
3
28
0,01%
'IT'
4
10
0,00%
'JP'
0
1944570
95,61%
'JP'
1
87220
4,29%
'JP'
2
1817
0,09%
'JP'
3
164
0,01%
'JP'
4
27
0,00%
'JP'
5
2
0,00%
'KR'
0
416998
90,69%
'KR'
1
42350
9,21%
'KR'
2
387
0,08%
'KR'
3
36
0,01%
'KR'
4
8
0,00%
'KR'
5
3
0,00%
'KR'
6
2
0,00%
'KR'
7
2
0,00%
'KR'
8
2
0,00%
'KR'
9
2
0,00%
'MX'
0
155216
91,72%
'MX'
1
13764
8,13%
'MX'
2
220
0,13%
'MX'
3
20
0,01%
'NL'
0
304872
94,88%
'NL'
1
15200
4,73%
'NL'
2
1068
0,33%
'NL'
3
142
0,04%
'NL'
4
30
0,01%
'NL'
5
19
0,01%
'NO'
0
159572
90,04%
'NO'
1
17104
9,65%
'NO'
2
500
0,28%
'NO'
3
33
0,02%
'NO'
4
3
0,00%
'NO'
5
7
0,00%
'SE'
0
573942
98,20%
'SE'
1
9942
1,70%
'SE'
2
486
0,08%
'SE'
3
50
0,01%
'SE'
4
10
0,00%
'SE'
5
4
0,00%
'TW'
0
109687
91,14%
'TW'
1
10637
8,84%
'TW'
2
26
0,02%
'TW'
3
4
0,00%
'US'
0
3964197
94,06%
'US'
1
243859
5,79%
'US'
2
5419
0,13%
'US'
3
730
0,02%
'US'
4
131
0,00%
'US'
5
39
0,00%
'US'
6
5
0,00%
'ZA'
0
210075
98,67%
'ZA'
1
2612
1,23%
'ZA'
2
193
0,09%
'ZA'
3
16
0,01%
'ZA'
4
1
0,00%










Posted by at No comments:
Labels: , ,

Monday, October 10, 2011

Person ids concordance table

A lot of problems arise when you need to attach to your patstat version DB, data coming from other sources updated asincornally with yours.

Most problems come from appln_id and person_id.

Since from 201104 appln_id will be stabilized @ source, I produced a first concordance table for person_id.

@this link (thanks to EPO for guesting this big file on their servers) you may download a first version of a concordance table among differnet versions of person ids.

After un-raring the file you will have a txt tab separated table contains 4 fields:
personid1   first patstat version personid
personid2   second patstat version personid
pversion1   patstat version of personid1 (format YYYYMM)
pversion2    patstat version of personid2 (format YYYYMM)

This first version of the file contains only concordance among 200909 and 201009 versions.

The file succeds in  matching 34250823, out of 37428113, 201009 persons against 200909 ids.


In reality matches are a little less since about 38.000 matches are duplicated (12000 2010 ids match to more than one 2009 id and 26000 2009 ids match more than one 2010 ids), but this less than 1/1000 error is due to some data repetitions in the main db and is a very small error.



If you are willing to do the same exercise you may run this SQL after renaming to tls206_person_200909 the TLS206 table, version 200909.

Be aware you will need to use a collation that distinguish among upper and lower case (in mysql utf8_bin would do the job).


create table person_id_his
Select
  T10.PERSON_ID As person_id1,
  T9.PERSON_ID As person_id2,
  "201009" as pediction1,
  "200909" as pediction2
From
  tls206_person_200909 T9 Inner Join
  tls206_person T10 On
  T10.PERSON_CTRY_CODE  = T9.PERSON_CTRY_CODE
  And T10.PERSON_NAME  = T9.PERSON_NAME
  And T10.PERSON_ADDRESS  = T9.PERSON_ADDRESS ;

Posted by at No comments:
Labels: ,
Subscribe to: Posts (Atom)