ＳＭＩＰＳ 特許戦略工学分科会 ２００４年１月１７日 の会合での発表資料＋ＭＬでのＱ＆Ａ ＳＭＩＰＳ　特許戦略工学分科会 http://www.egroups.co.jp/group/Patent_Strategy_Engineering ２００４年１月１７日　の会合での発表資料＋ＭＬでのＱ＆Ａ ●　請求項記述言語の概念と仕様案、将来展開構想およびＱ＆Ａ （五十音順） 本分科会プロモータ　谷川　英和 本分科会オーガナイザ　久野　敦司 本分科会プロモータ　吉田　大

請求項記述言語とは： 　人間にとってもコンピュータにとっても明瞭で理解しやすい構造を持つように請求項を記述するために用いる言語である。 英語表記 PCML: Patent Claim Markup Language 本分科会では、ＸＭＬによって言語定義することで、拡張性 と汎用性の高い請求項記述言語PCMLの標準を構築しよう としていますので、皆さんの標準化作業への参加を歓迎い たします。

請求項における問題点 請求項では、複雑な技術を公知技術と区別しながら、できるだけ権利範囲が広くなるようにしつつ、発明の技術構造を正確に表現する必要がある。 権利範囲を広くするために抽象的な用語を使用しがちになる。 複雑な技術構造を、あいまいな自然言語での修飾記述で表現するので技術構造が様々に解釈される可能性と、理解困難性が発生する。 請求項は読みにくいし、わかりにくいものとなる。 権利範囲の解釈に争いが発生するようになる。 内容がわかりにくいので、事業企画、営業、技術開発の部門での特許の活用が阻害される。 特許調査、審査、評価、鑑定などの処理の効率が低下する。 権利行使のコストと時間が増大するとともに、特許権が不安定になる。 明瞭で理解しやすい構造を持つように請求項を記述する事が必要。 特許の存在価値が大きく低下する。

請求項は職人技で請求項を作成する優れた人がいたとしても、出願後には、請求項を作成した人の手を離れて、さまざまな人の解釈や判断にさらされます。その時、請求項が用語の意味が明確であるだけでなく、請求項の技術的な構造も明確に表現されていなければ、技術開発者、事業企画者、営業担当者などの多くの関係者からみると、請求項とは意味のわからない呪文のようなものとなります。 請求項が呪文のようなものということになると、知財部員という者は呪文を唱えて、競合企業を倒す呪術師のような別世界の人間ということになります。これでは、事業に特許を活かすということは困難になります。 かといって、すべての特許出願について請求項をわかりやすく説明する図を作成することは多項制での多くの請求項の存在と、請求項が補正されて変化することを考えると無理があります。 そこで、請求項を自動的にわかりやすい図に変換することが必要となります。 自動的に請求項を図に変換するためには、コンピュータが請求項の構造を理解することが必要です。そのためには、請求項をコンピュータでも人間でも理解しやすく表現するための基盤である請求項記述言語が必要となると考えます。

人間にとってもコンピュータにとっても明瞭で理解しやすい構造を持つように請求項を記述するために用いる言語である請求項記述言語が必要。 請求項記述言語を必要とする背景 明瞭で理解しやすい構造を持つように請求項を記述する事が必要。 特許情報に関する便利で高度なサービスを提供するためには、請求項をコンピュータが処理しやすくする必要がある。 明瞭で理解しやすい構造の請求項を記述する事は、これまでも努力されていたが、自然言語を用いていたのでは限界がある。 人間にとってもコンピュータにとっても明瞭で理解しやすい構造を持つように請求項を記述するために用いる言語である請求項記述言語が必要。

請求項記述言語の機能 １． 請求項の構造の標準的な型を１つまたは複数個提供します。 １．　請求項の構造の標準的な型を１つまたは複数個提供します。 ２．　請求項を構成する要素と要素間リンクの種類の標準を提供します。 ３．　請求項で示される発明のカテゴリーを明示する符号を与えます。 ４．　請求項を表現するために用いる用語の概念を示す符号を提供します。（将来機能） ５．　請求項と実施の形態の間の対応関係を明示します。（将来機能） 請求項の構造のイメージ Ａ Ｂ Ｄ Ｃ Ｃ１ Ｃ２ Ｃ３ Ｋ 構成要素やリンクの意味を定義した情報 概念展開リンク 階層構造 入力 出力 リンク 請求項の理解可能性を支えている。 請求項を理解する主体である人間またはコンピュータが保持している。

１．特許請求の範囲の構造 「構造」「属性」「関係」を定義することにより特許請求の範囲を記載する →広範囲の発明に対応できる構造 →特化した技術範囲に属する発明に、さらに精度良く対応するのは今後 請求項（発明の名称，属性値・・・，他の請求項との関係） 特許請求の範囲 請求項（発明の名称、属性値・・・,他の請求項との関係） 構成要素（名称，属性値・・・，他の構成要素との関係）

ＸＭＬによって請求項記述言語PCMLを規定すると拡張性と汎用性 の高い言語が実現できる。 請求項記述言語の構文規則のイメージ ＸＭＬによって請求項記述言語PCMLを規定すると拡張性と汎用性 の高い言語が実現できる。 <!DOCTYPE 請求項 [ <!ELEMENT 請求項　(前提要件?,構成要件+,後続要件?,発明名称,発明カテゴリー符号)> ]> PCMLは上記のものをさらに洗練し、精緻にしたものとなる。 これの意味は、次のとおりです。 請求項は、０個以上の前提要件の後に、１個以上の構成要件が続き、その後に０個以上の後続要件が続き、その後に請求項末尾となる発明名称が続き、最後に発明カテゴリー符号で終わるというものです。 ここで、前提要件とは、「〇〇において、」とか「〇〇と〇〇からなる〇〇であって」というような記載です。また、後続要件とは、「を備えることを特徴とする」とか「とからなる」などのつなぎの言葉です。 発明カテゴリー符号とは、「物」、「方法」、「生産方法」というような発明の種別を示す符号です。

２．請求項記述言語（PCML）案① １．請求項の構造記述 請求項は、発明の名称および１以上の構成要素を有する。 ２．請求項の属性記述 　　請求項は、発明の名称および１以上の構成要素を有する。 ２．請求項の属性記述 　　１）装置｜方法（生産方法、単純方法）｜プログラム｜媒体　のうちのいずれかの属性値 　　　　を採り得る ３．請求項間の関係記述 　　(関係の例) 　　１）従属関係 　　２）カテゴリー展開関係（装置と方法とプログラムと媒体） 　　３）サブコンビネーション、コンビネーション関係 　　４）別態様関係（サーバ・クライアント、スタンドアロン、中継装置有り　など） 　　　　別態様関係とは、全体として同じ機能・効果を有するが、構成が違う、という関係。 ４．構成要素の構造記述 　　構成要素は、名称および１以上の定義情報を有する。 ５．構成要素の属性記述 　　１）必須｜必要｜else(通常の実施態様)　のうちのいずれかの属性値を採り得る ６．構成要素間の関係記述 　　１）リンク関係（同一請求項内の構成要素間の関係） 　　２）外的付加、内的付加（異請求項間の構成要素間の関係） ７．定義情報の属性記述 　　１）絶対的定義｜相対的定義　のうちのいずれかの属性値を採り得る 　　２）必須｜必要｜else(通常の実施態様)　のうちのいずれかの属性値を採り得る

２．請求項記述言語（PCML）案② ～ DTD ～ <!DOCTYPE　特許請求の範囲　[ <!ELEMENT　特許請求の範囲　（請求項+）> <!ELEMENT　請求項　（発明の名称，構成要素+，link）> <!ELEMENT　構成要素 （構成要素名，定義情報+，link）> <!ELEMENT　定義情報　（内容＊）> <!ELEMENT　発明の名称　（#PCDATA）> <!ELEMENT　構成要素名　（#PCDATA）> <!ELEMENT　定義情報　（#PCDATA）> <!ELEMENT　内容（#PCDATA）> <!ATTLIST　請求項　id　ID　#REQUIRED> <!ATTLIST　請求項　請求項Type　（装置｜生産方法｜単純方法｜プログラム｜媒体） 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　“装置”> <!ELEMENT　link　（#PCDATA）> <!ATTLIST　link　xml:link　？？？> <!ATTLIST　構成要素　構成要素Type　（必須｜必要｜その他）　“必須”> <!ATTLIST　定義情報　種別　（絶対的定義｜相対的定義）　“絶対的定義”> <!ATTLIST　定義情報　定義情報Type　（必須｜必要｜その他）　“必須”> ]>

２．請求項記述言語（PCML）案③ ～ ＰＣＭＬデータ ～ <特許請求の範囲> <請求項　id＝“１”　請求項Type =”装置”> 　　<発明の名称>情報処理装置</発明の名称> 　　<構成要素> 　　　<構成要素名　構成要素Type ＝“必要”>受信部</構成要素名> 　　　<定義情報　種別＝“絶対的定義”　定義情報Type ＝“必須”> <内容＞A情報</内容>を受信する 　　　</定義情報> 　　</構成要素> 　　　<構成要素名　構成要素Type ＝“必須”> A情報処理部</構成要素名> 　　　<定義情報　種別＝“絶対的定義”　定義情報Type ＝“必須”>前記A情報を処理する 　　　<構成要素名　構成要素Type ＝“必要”>出力部</構成要素名> 　　　<定義情報　種別＝“絶対的定義”　定義情報Type ＝“必須”>前記A情報処理部の処理結果を出力する </請求項> 【請求項１】 A情報を受信する受信部と、 前記A情報を処理するA情報処理部と、 前記A情報処理部の処理結果を出力する出力部を具備する情報処理装置。 【請求項２】 前記A情報は、動画情報と音声情報を含み、 前記出力部は、動画情報はディスプレイに表示し、音声情報は音声出力する請求項１記載の情報処理装置。

３．今後の展開① ～ 品質評価ツール ～ 権利特性 発明本質抽出性 発明展開性 強靭性 実施可能担保性 文献特性 明瞭性 論理性 ３．今後の展開① ～　品質評価ツール　～ ①評価困難な対象を特性に分けて評価する ②評価結果を明細書品質評価だけでなく、特許評価に利用できないか？ 権利特性 発明本質抽出性 発明展開性 明細書記述言語 までの拡張も重要 強靭性 実施可能担保性 文献特性 明瞭性 論理性

３．今後の展開② ～ 品質評価ツールの出力例 ～ ３．今後の展開② ～　品質評価ツールの出力例　～ 特許明細書を形態素解析し、品質特性を算出

３．今後の展開③ ～ 品質評価ツールの出力例 ～ ３．今後の展開③ ～　品質評価ツールの出力例　～ 品質特性の元となる数値をグラフ化

請求項記述言語(PCML)を支えるソフトウェア環境 ブロック図表現表示 請求項エディタ PCMLで記述された 請求項 請求項 ブラウザ ブロック図 エディタ PCML: 請求項の構造を 規定したDTD 請求項評価 ソフトウェア 請求項の特性値 ・構成要素数 ・未定義用語数 ・関連文件数 請求項利用の検索ソフトウェア 用語チェッカー 各種文書 データベース 用語辞書

請求項記述言語(PCML)で可能となる事柄 請求項をわかりやすく示す図の生成 請求項の上位概念化および下位概念化 請求項の間の比較に基づいた特許系統図の生成 請求項の構成要素と実施例の関係データの設定 請求項の記述に基づいた自動的な公知技術検索

請求項記述言語ができて、これを用いた請求項をもった特許出願がされていくと、次のようなことが可能となると思います。（具体的なイメージです） １．　請求項の包含関係の自動解析に基づいたパテントマップの作成 審査過程における引用関係を用いて、特許の系統図を自動生成するものが製品化されていますが、請求項の包含関係に基づいたパテントマップの方が信頼性は抜群に高くなると思います。 ２．　請求項を表現するブロック図やフローチャートの自動生成 請求項記述言語は、請求項の構成要素および構成要素間のリンクを明示した記述ですので、請求項を表現する図は簡単に作成できるはずです。図で請求項を表現することで、権利範囲の理解可能性が高まりますので、事業企画、営業、技術開発、知財の特許情報共有基盤が強化されます。 ３．　審査や特許調査の効率アップ 請求項記述言語を用いた請求項では、技術構造を明確に表現していますので、公知文献との比較や他の出願の請求項との比較も技術構造レベルの比較ができます。その結果、自動的に技術構造レベルで比較して絞り込んだ文献が、技術構造レベルの比較結果付きで審査官などに提示されますので、審査の効率は格段に向上すると思います。 ４．　請求項の品質のリアルタイムフィードバック付きの出願明細書作成支援ツールの実現 請求項記述言語で請求項を作成している瞬間に並行して、その請求項の特性値を計測して、出願明細書の作成者にリアルタイムでフィードバックします。例えば、請求項を構成する用語の概念として、さらに上位概念を使用してはどうですかと、上位概念を提示し、その上位概念に請求項を入れ替えた場合に、請求項の範囲に含まれると思われる公知文献をその場で検索して提示します。その公知文献が問題なければ、提示された上位概念を請求項の用語として受け入れます。実施例の部分と請求項を比較して、実施例で使用した用語と請求項で使用した用語の対応関係の確認を求めてきます。対応関係を承認すると、その対応関係を明細書に自動的に記載します。

請求項記述言語(PCML)の実用化のシナリオ 第１段階 請求項作成支援ソフトウェアで請求項を設計： 請求項記述言語を用いて、請求項作成支援ソフトウェアが使用される。特許出願における請求項は請求項記述言語では記述されていない。しかし、請求項の作成の過程で請求項記述言語を用いるので、わかりやすく権利範囲の広い請求項を作成しやすい。 第２段階 請求項記述言語による請求項の解説を明細書に記載： 請求項記述言語を用いた請求項の説明の欄を明細書中に記載することで権利解釈上の争いを避け、厳密な権利範囲を獲得しようとする。また、請求項をわかりやすく示す図を、請求項の説明の欄の記述から自動生成するブラウザも現われる。 第３段階 請求項記述言語による請求項が特許請求の範囲に記載可能となる： 請求項記述言語を用いた請求項の記述を特許庁が受け入れるようになり、請求項記述言語を用いた請求項が次第に一般的になっていく。

Ｑ＆Ａ集 Ｑ１：請求項の包含関係の自動解析に基づいたパテントマップの作成について 包含関係をどうやって解析するのか、イメージがわきません。 シソーラス解析済みの出現用語の一致度合いから 類似度を解析するというのであれば、わかるのですが。 包含関係を解析するとなると、 各構成要素の有機的な関係（無限通りの関係があるように思えます）を 解析しなければならないように思えるのです。（吉田大さん） Ａ１：　グラフマッチングの技術を用いて解析します。構成要素と、構成要素間のリンクから成り立つグラフ構造で請求項は表現できます。このグラフ間のマッチングで包含関係を検出します。下図の例では、Claim2,Claim3はClaim1に包含されます。 外的付加 内的限定 Claim1 Claim2 Claim3

Ｑ２： （１）ＰＣＭＬによる表現の可否を質疑応答するためのクレーム実例 以下はコンピュータ関連発明のクレーム実例（出典：審査基準と公開公報）である。 ・構成要素を追加・削除・変更せず、構成要素の定義内容を実質的に変更せずに、構成要素間のリンク関係を変えずに、ＰＣＭＬで表現できないものはあるか。 ・あるとすれば、その型のクレームをＰＣＭＬで表現した場合に生ずる権利強度と権利範囲と理解容易性のそれぞれの変動はどのようなものか。 （吉田大さん）

●標準型 プログラムされたコンピュータによって自動車エンジンの燃料噴射量を制御する装置であって、 エンジンの回転数を検出する第一の検出手段と、 エンジンの回転数の変化を検出する第二の検出手段と、 該第一の検出手段の検出値と該第二の検出手段の検出値とに応じて燃料噴射量を決定する燃料噴射量決定手段と、 を備えたことを特徴とする自動車エンジン用燃料噴射量制御装置。 ●入れ子型 【請求項１】 コンピュータを利用したカードゲーム装置において、 複数枚のカードの組み合わせに対して所定の役データが対応させられている役データテーブルと、役データに対して得点データが対応させられている得点データテーブルとを記憶する記憶手段と、 選択された複数枚のカードの組み合わせを基に前記役データテーブルを検索して対応する役データを抽出し、該役データを基に前記得点データテーブルを検索して対応する得点データを抽出し、抽出された前記役データの全て及び前記得点データの合計得点を出力する手段と、 を有するカードゲーム装置。 【請求項２】 　前記役データテーブルは、…である請求項１に記載のカードゲーム装置。

●追記定義型 第１画像および第２画像に係る電気的な画像信号が入力される画像信号入力部と、 上記画像信号入力部に入力された第１画像信号を印刷媒体に印刷記録する第１記録ヘッドと、 上記画像信号入力部に入力された第２画像信号を印刷媒体に印刷記録する第２記録ヘッドとを備え、 上記第１記録ヘッドが光定着型直接感熱記録方式の記録ヘッドであり、 上記第２記録ヘッドが顔料インクが展着された顔料インクフィルムの上記顔料インクを印刷媒体に付着させるものであることを特徴とするプリンタ装置。 ●べた書き型 カラープリンタを備えた自動画像合成装置において、 グラフィックアプリケーションで作成した画像データ、またはデジタルカメラで撮影した画像データに、文字原稿、ロゴ、および人物のいずれかを自動的に合成してプリントアウトすることを特徴とする自動画像合成装置。

●無定義型 撮像部と、 メモリを装着する装着部と、 前記装着部に装着されたメモリに前記撮像部により撮像した画像データの記録を指示する記録手段と、 前記装着部に装着されたメモリが書換え制限メモリであるか判別する判別手段と、 前記装着部に装着されたメモリに応じてメモリに記録された画像データに対して異なる画像編集を施す画像編集処理手段と、 を備えることを特徴とするデジタルカメラ。

（２）請求項記述言語を用いることで実現できると思われる特許業務用ツールについて（吉田大さん） ●請求項を分かり易く示す図の説明 定義情報に記載された記述について言葉の修飾関係を示せるか？ 構文解析技術を用いることで、示せます。 ●請求項の上位概念化、下位概念化 シソーラス辞書を使って単語の置換候補を表示して上位概念化、下位概念化を支援するということか？ そのとおりです。置換候補に取り替えつつ請求項の範囲内の公知文献数を示せれば面白いです。 ●請求項の間の比較に基づいた特許系統図の生成 １出願内でクレームの従属関係を示す系統図か？ 多出願について構成要素の定義情報やリンク関係を解析して得られる系統図か？ １出願内および別出願をまたがってのどちらも可能です。別出願をまたがっての特許系統図の作成では、請求項の比較に加えて出願日の比較が必要となります。

●請求項の構成要素と実施例の関係データの設定 ハイパーリンクで実施例内の記載箇所にジャンプできるようなイメージか？ （吉田大さん） イメージとしてはそうです。ただし、ハイパーリンクとは異なり、双方向のリンクとしての 性質や上位概念と下位概念の関係を示すリンクという性質を兼ね備えたリンクとすべきと思います。 請求項と効果の関係データの設定をしてはどうか？→パテントマップに有効利用できる。 （吉田大さん） そのとおりだと思います。さらには、請求項を自動的に図に変換してパテントマップに 利用できれば良いと思います。

●請求項の記述に基づいた自動的な公知技術検索 構成要素の一致度の解析だけでなく、構成要素間のリンク関係を解析した結果に基づく検索か？ 請求項記述言語で作成された請求項を持った公開公報が高知文献として蓄積されてきた段階では、そうなります。 その前の段階では、構成要素の一致度の解析だけを使うと思います。 ●請求項エディタ 構成要素、それらのリンク関係、それらの属性等を対話形式で入力するインタフェースか？リンク関係の欠陥をアラートするか？言葉の修飾関係が明瞭になるように入力支援できないか？ 初心者用は対話形式で入力するものをイメージしています。上級者用は、タグの選定を含めてユーザが自由に行なえるものをイメージしています。また、請求項記述言語の文法書としてのＤＴＤのもとで動作させ、リンク関係の欠陥を含めて、文法エラーチェックを自動的に行なうようにできると思います。言葉の修飾関係の明瞭性のチェックや構成要素間のリンク関係の明瞭性のチェックも請求項記述言語の文法書としてのＤＴＤを用いて行なうべきだと思います。

●請求項評価ソフトウェア 構成要素数：権利範囲の広さの説明変数？ 未定義用語数：権利の強さの説明変数？未定義とは明細書にも定義がないということか？ 関連文献数：権利の強さの説明変数？ ●「構成要素間の関係記述」について リンク関係は具体的にはどのような記述になるのでしょうか。 各構成要素の内容（定義情報）を記述するときに他の構成要素が登場することに よって リンク関係が明らかになると思いますが、 それとは別にリンク関係を宣言すると いうことでしょうか？ 現在の考察のレベルにおいて、請求項内の文言に登場する情報のみから 判断できるリンクを抽出（または記載）できれば良いと考えています。 その構成要素間のリンク関係には、同一請求項内の複数構成要素間のリンクと、 異請求項間の構成要素間のリンクがあると考えています。 ただ、さらに考察を深めて、他のリンク関係を記述すれば、もっと良いことが できる、ということであれば、それも仕様に入れていけば良いと考えます。

●例えば ＜構成要素名　構成要素Type="必須"＞Ａ情報処理部</構成要素名> <定義情報　種別＝”絶対的定義”定義情報Type ＝"必須">前記A情報を処理する > という例がありますが、この場合、Ａ情報処理部及びＡ情報と、他の構成要素と の関係を別途宣言するいうことでしょうか。 いえ、そうは考えていません。 別の請求項で、例えば、「Ａ情報処理部」の下位概念（内的付加）で限定する 記述がある場合に、リンクが張られる、ということで考えています。 ●各項性要素の内容（定義情報）の記載のしかたについて これについての言語仕様はあるでしょうか？ 例えば、入れ子構造になっている複数の構成要素を １つの定義情報で定義する ことが禁止されているとか？　 また、タグ等で宣言してで表現しうる事項が、 そのように表現されずに定義情報内で普通の日本語で表現されていると、 不明確なクレームとしてアラートを出す機能を提供するツールが想定されていると か？ まだ、そこまで考察は及んでいません。 良い御指摘、有難うございます。

●「相対的定義」について どういう場合に、定義情報が相対的なのでしょうか。 「高い」とか、「低い」とかいう相対的な用語が登場するという場合でしょうか？ これは、確か、山崎さんのＨＰの記載からとってきた情報です。 相対的定義とは、一の構成要素を定義する際に、他の構成要素との位置的な 関係などを記述する（これを相対的な定義と呼ばれていたかと思います）ことに より定義される構成要素に付加する属性値です。 ●「必須」と「必要」、「外的付加」と「内的付加」 これらを記載するのは、どういう効果をねらっているのでしょうか。 前方の組については、発明のポイントを短時間で把握できるようにするためでしょ うか？ 「必須」「必要」は、吉田さんのおっしゃるとおり、発明のポイントを把握するためです。 したがって、このような属性値を付加すれば、特許調査システムにおいても、ゴミの 少ないヒット率の高い調査が可能である、と考えます。 また、特許明細書を書く際に、筋の通った良い明細書を記載することができると考え ます。また、「外的付加」と「内的付加」という属性値を記載すれば、請求項間の関係 や、記載した請求項の意義がわかりやすくなるかと思います。 したがって、明細書に記載した発明の展開度(アイデアの広がり）が把握しやすくなる と考えます。