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.
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:
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.
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...
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%
|
No comments:
Post a Comment