請求項の「広さ」の推定

[この記事](https://github.com/google/patents-public-data/blob/master/models/claim_breadth/README.md)を読んで。

・Googleの公開データセットの中に世界中の特許データをBigQueryで取得できる[もの](https://cloud.google.com/blog/products/gcp/google-patents-public-datasets-connecting-public-paid-and-private-patent-data)があります。

・で、BigQueryなので非常に大きなデータ（特許全文データなど）を扱えますが、普通は時系列の出願件数集計するくらいであまり使い道がなく。テキスト情報なら機械学習でもしない限り使わないだろうな、と思ってましたが、上記の記事が面白かったので紹介しようと思います。
ちなみに対象はUSの特許でした。


#１．背景
特許の権利範囲は文章で画されます。そのため、特許の請求項の単語数を数えれば、単語数が多い請求項より、単語数が少ない請求項のほうが権利範囲が広いと仮定ができます。が、この仮定は単純すぎて本当にそうなのか疑わしい、権利範囲の広さをよりよく推定したい、というのが背景。
2021/1/4：[格成分](https://minorutokkyo.com/service/create/diagram.html)というものを知ったので、これでデータを更新してみたいと思います。

#２．仮説
下記２つの[仮定](https://cloud.google.com/blog/products/ai-machine-learning/measuring-patent-claim-breadth-using-google-patents-public-datasets)をおいています。

>1.Claims in patent applications tend to be broader than claims in issued patents. 
    Typically, the patent examination process results in one or more amendments to the patent 
    claims filed in the initial application that narrow the scope of the final version of the 
    claims in the issued patent. Therefore, the final issued patent generally includes  
    narrower claims than the initial application.

（説明）：特許は出願した（「特許出願」）の後に審査官が審査して「特許」になる。
　　　　　特許の権利範囲は文章で表されるが、上記のプロセスにより、「特許出願」の時点での
　　　　　権利範囲（文章で画される）は、「特許」の時点での権利範囲よりも広いはず。

>2.Although this statement does not hold absolutely, claims in patents that are “early” in a technology space tend to be broader than patents that appear later.
（説明）：時系列で早い時期に出された出願の権利範囲は、後で出された出願の権利範囲よりも広い。
　　　　　※必ずしもそうならない場合もあると思いますが。




#３．分析  
  上記仮定を前提として、下記のように権利範囲が広い／狭いの２値を正解データとする。

>    Positive Observations (i.e., “1’s”)—The first claim in patent applications which were earlier than other applications and patents in a similar technology space.
    Negative Observations (i.e., “0’s”)—The first claim in issued patents which were later than other patents in a similar technology space.

広い＝同様の技術分野において、一方の特許出願が、他方の特許出願よりも先に出願された場合の、第１請求項
狭い＝同様の技術分野において、一方の特許が、他方の特許よりも後に特許された場合の、第１請求項

以下の流れで分析。
（１）BigQueryで母集団をとってくる。
（２）Cloud Dataflowでデータ取得までを定型化　※ここは本質的でないので省略
（３）特徴量抽出、test,trainデータに分割
（４）Cloud ML Engineで学習
（５）モデル保存、ハイパーパラメータチューニング
（６）結果：AUC＝0.802


##（１）BigQueryで母集団をとってくる。

    #standardSQL
    SELECT
      cpc4,
      APPROX_QUANTILES(priority_yr,4)[offset(2)] AS median_priority_yr
    FROM (
      SELECT
        DISTINCT family_id,
        FLOOR(priority_date / 10000) AS priority_yr,
        SUBSTR(cpc.code, 1, 4) cpc4 # Trim CPC Code to first 4 digits.
      FROM
        `patents-public-data.patents.publications`,
        UNNEST(cpc) AS cpc
      WHERE
        country_code = 'US'
        AND FLOOR(priority_date / 10000) > 1995
        AND SUBSTR(cpc.code, 1,1) IN ('E','F')
        )
      GROUP BY 1

＜説明＞
・cpc4というのは、CPC(Cooperative Patent Classification)という最近EUとUSで使われ始めた技術分野のこと。大区分⇒小区分へと細分化される「技術分野の住所」のようなもの。USの特許出願には必ずCPCが付与される。同じCPCがついている＝同様の技術分野といえる。
・priority_yr　は「優先日」（の年）のこと、優先日＝出願日とざっくリ考えると出願した年のこと。
・SUBSTR(cpc.code, 1,1) IN ('E','F')　はA~HであるCPCのうち、E(固定構造物分野)とF（機械工学；照明；加熱；武器などの分野）を取得したいため。なぜEとFなのかは不明。


##（２）Cloud Dataflowでデータ取得までを定型化　※ここは本質的でないので省略
よくわからなかったので省略。beamというのを勉強しないとダメと思われる。

##（３）特徴量抽出、test,trainデータに分割
>we must avoid using features which capture semantic meaning, since these could be used by the model to learn to separate early patents from late patents without learning anything about claim breadth. Therefore, we’ll focus on capturing features in two categories:
>1.Features related to claim structure and syntactic complexity.
>2.Features which count the appearance of words and phrases that tend to narrow or broaden a patent’s claims

＜説明＞
時系列の区切りのみで権利範囲が広い／狭い　と決めているため、それ以外のsemantic meaning（意味のこと？＝文章の単語）は使えない。そのため、①請求項の構造に関するもの、②権利範囲を広く／狭くする意味を持つ記号やワード　のみを使いたい。そこで、（英文であることに注意）

・セミコロンの出現頻度
・“exclude”, “include”, “without”, “with”, etc..の出現頻度
・“ second”や“ third”の出現頻度
などを計測。
具体的にはレポジトリの[preprocess.py](https://github.com/google/patents-public-data/blob/master/models/claim_breadth/preprocess.py)を見ると

    PATTERNS = {
        'element_cnt': ';',
        'atleastoneofand_cnt': r'(at\sleast\sone\sof).+(and)',
        'atleastoneofor_cnt': r'(at\sleast\sone\sof).+(or)',
        'adding_words_cnt': '(after|subsequent|\band\b|including|next)',
        'excluding_words_cnt': r'\b(or\b|not\b|only|exclu|except|without)',
        'limiting_words_cnt': '(wherein|consist|limit|never)',
        'counting_cnt': r'\b(second|third|fourth|fifth)\b',
        'groupconsistingof_cnt': r'group\sconsisting\sof',
        'digits_or_decimal_cnt': r'(\d+\.\d+|\.\d+|\d+)',
    }

で頻度をカウント。日本語なら「、」の数とか「少なくとも」、「さらに」とか「第１の～～」
とかでしょうか。

train, test, eval への分割はbeamを使っていて省略。

##（４）Cloud ML Engineで学習
tensorflowに慣れてるなら自作でもいいよ、と言いつつもCloud ML Engineで学習。
上記のcpc4＝CPCの上４ケタでデータを分けて学習させています。
文字列をembedding層にするための加工などは[おなじみ。](https://www.tensorflow.org/guide/feature_columns#indicator_and_embedding_columns)
データはGCPのストレージに出力しといて、

    gcloud ml-engine jobs submit training $JOB_NAME \
      --scale-tier STANDARD_1 \
      --runtime-version 1.6 \
      --job-dir $GCS_JOB_DIR \
      --module-name trainer.task \
      --package-path trainer/ \
      --region us-central1 \
      -- --train-steps 30000 \
         --train-files $GCS_TRAIN_FILES \
         --eval-files $GCS_EVAL_FILES \
         --cpc-embedding-vocab-file $CPC_EMBEDDING_VOCAB_FILE


##（５）モデル保存、ハイパーパラメータチューニング


##（６）結果：AUC＝0.802
バッチサイズ512で30000回の結果。
![結果](https://storage.googleapis.com/gweb-cloudblog-publish/images/image2_4Yc0yut.max-2000x2000.png)


##（７）バッチ処理で予測
データ取得、前処理、予測までコマンドラインから実行可能なのでらくちん、とのこと。
たしかに・・・

# ４．その他
　権利範囲の広さでは安彦弁理士の[格成分](http://minorutokkyo.com/analysis/component.html)が有名ですが、こんな方法で広さを定量化するのも面白いですね。
・すべてコマンドラインで処理するのは確かに楽なので、習得しようと思います。