特許文書を読みやすくする技術、登場

Yggdra曰く、"難解な特許文書に日々頭を悩ませている人に朗報かも。ITmediaの記事によると、NTTデータが、特許文書を分析し、視覚的に表示し、また類似特許の検索のためのキーワードを抽出する技術を開発したそうだ。（参考：ニュースリリース）
形態素解析を用いてパターン化するというのは昨今ありふれた手法だが、この技術は高度に構造化されている特許文書に特化したのが特徴。それによって、より精度の高い解析が可能になると期待される。特許文書は読みづらい上に、技術者にとっては嫌々読まなければならない文書の一つであり、その面倒さが軽減されるのは歓迎できる。

タレコミ者としては、その元の文書をどうにか読みやすいものにして欲しい、というのが本音なのだけれど(^^;"

手前味噌ですが……

[etsav (7596)]

つまり、 これ [srad.jp] を自動化したのですね。

当然この技術も

[ribbon (11750)]

特許で固めてあるんだろうが、その特許をこの技術を使って
読みやすくするとどうなるんだろう?

逆変換

[Anonymous Coward]

自分は特許文書とは全く関わりのない作業員なのですが、たまにネットで特許文書読むと、あまりの難解さに「やっぱり特許取る人は頭がいいんだね」と感心していたものです。
そこで特許文書を書かれる方に質問なのですが、もしかして、普通の文書からあの文書に変換したり、グラフを書くとあの文書が生成されるようなツールを使ってたりするんでしょうか？
＃ツール使ってるのなら、その元データも提供すればいいじゃんと思ったりして。

Re:逆変換

[Maxie (28799)]

一時、特許文書を書く側の立場にいましたが、特許文書（正確には請求項）はツールなどを使って生成するのではなく、特許部や弁理士事務所の方が、発明の内容を少しでも広い権利範囲でとれるように、より広い概念の言葉、表現を駆使して書きます。

しかも、それを一文で書かなくてはいけないので、かなり四苦八苦して書いてました。

特許は、土地と同じような排他的な財産です。そして、請求項は、それを明確にするため、論理的な構成であり、論理的な言葉である必要があります。

メカ系のものなど見た目で分かるものはやり易いのですが、制御系などの無形なものを、上記のことを踏まえて、請求項という形にするのですから、慣れてる人間だって、難しいものです。

ちなみに、私が頭がいいと思うのは、特許を出す人でも、書く人でもなく、自分の関わる製品の仕様を理解し、問題になりそうな他社の特許を理解し、侵害しないという論点を見出せる開発者です。

（こういう人が味方のうちはいいのですが、反対に立場に回られると．．．何度も泣かされました）

Re:逆変換

[gnaka (17369)]

　吉藤翁曰く

従来、特許請求の範囲を一連の文章で記載することが一般的に行われているが、そのようにしなければならない必要性は全然ない。特に内容の複雑な発明にあっては、文章を区切り、行を改めて記載すること(個条書式)が望ましい。
(「特許法概説[第13版]」吉藤幸朔著、熊谷健一補訂、有斐閣 p.299)

とのことですよ。

Re:逆変換

[Yggdra (14017)]

すみません、法律は全然わからないので素人な質問なんですが……

amazon によると、その本が出たのは1998年ということですが、そういう主張があってなお、今のように一文で書かれるのが大半ですよね。ということは、

(1) その主張は主流派ではないので黙殺されている
(2) その主張は主流派であって、今後はそうなっていくが現状はまだ途上段階である
(3) その主張は主流派であって、法論理からすればその通りだけど実務上の問題から変化がない

のどれなんでしょうか？

Re:逆変換

[sunow (19805)]

頭がいいのは「特許を取る人」ではなく「特許の申請書？を書いた人」なんでは。
いやそういうのを頭がいいと言うかは別問題ですが。

Re:逆変換

[ktxg7 (21705)]

私も自分が書いた普通の日本語の文章が、どうやればあのように特許語にコンパイルされるのか疑問に思ったことが多々あります。
問題はコンパイルされた文書のデバッグの必要があることなんですが…読めません。

Re:逆変換

[Anonymous Coward]

書くのはそんなに大変なことではありませんよ。
本当に大変なのは、競合他社のワケワカメな文章を読まなければ
ならないときの方です。（会社のノルマで出したような内容のない
特許だと分かったときの脱力感と言ったら…）

基本的に請求項の書き方は決まっています。
AとかBとか、特許にしたいシステムの構成要素をずらずら並べ、
「これがああなったときにどうなる」ことを特徴とするナニナニ、
で請求項１。
後は「請求項１において、ナントカがカントカであることを特徴と
するナニナニ、で請求項２。
以下、繰返し。

後ろに続く背景とか実施例はそのまま読めます。
図で示したものの

Re:逆変換

[Anonymous Coward]

ある程度はマクロで自動生成するようになっています
明細書の中には同じ文章をコピペするような部分があるので、そこを自動的に処理する感じです

でも基本は人力ですね。プログラムと同じだと思います。

宣言的プログラミング

[chu-chu (7456)]

特許の文書ってさあ、ある意味、宣言的なプログラミングだよね。
ただ、記述言語が自然言語（日本語）だから、あんなことになってるけど。
ほんでもって、実行or検証用の処理系が無いから、記述にバグだらけ。

Re:宣言的プログラミング

[Elbereth (17793)]

それはある意味トレーディングカードゲームに似ていますね。

Re:宣言的プログラミング

[Anonymous Coward]

無理やり単文に詰め込もうとするから・・・。

--

挿入されるICカードを誘導しかつ位置決めする誘導手段をAとする。

ICカードの導電領域に対して電気的に接続させられる複数の接触子を保持した接触フレームをBとする。

BによってICカード挿入方向に離間した休止位置と作動位置との間で移動可能に支持され、かつ挿入されたICカードによって作動位置に押し

Re:宣言的プログラミング

[s-tomo (2841)]

日本流だとちょっと違ったような

--

挿入されるICカードを誘導しかつ位置決めする誘導手段を甲とする。

ICカードの導電領域に対して電気的に接続させられる複数の接触子を保持した接触フレームを乙とする。

乙によってICカード挿入方向に離間した休止位置と作動位置との間で移動可能に支持され、かつ挿入されたICカードによって作動位置に押し動かされるキャリッジを丙とする。

（中略）

本件は、甲と乙とを具備し、これら接触子を介してICカード読取り機を内包した装置との間に回路が形成されるようになっているICカード読取り機であって、...

Re:宣言的プログラミング

[Anonymous Coward]

そうですそれそれ。トンクス。

ところで、甲乙丙丁っていくつまであるんだろ？

Re:宣言的プログラミング

[s-tomo (2841)]

ぐぐった [google.co.jp]ところ「甲乙丙丁戊己庚辛壬癸」のようです。

Re:宣言的プログラミング

[yasuchiyo (11756)]

11個以上ある時は、
　・甲甲、甲乙、甲丙、…、乙甲、乙乙、…
とするのでしょうか。

初めから、
　・甲子、乙丑、丙寅、…
で、60個確保しておく手もありますが。

Re:宣言的プログラミング

[Anonymous Coward]

詰まらん茶々ですが。

「～であって」の箇所には発明特定事項に関する文章は入れません。

本件は、甲と乙とを具備し、これら接触子を介して
ICカード読取り機を内包した装置との間に回路が
形成されるようになっているICカード読取り機であって、...
 
回路を構成していることに発明の特徴がないなら、
回路は請求項の発明特定事項には

もっと人間的な言い回しにしてくれたら便利

[hohehohe (11394)]

差し込むICカードを正しい位置まで運ぶ方法をAとする。

ICカードについてるあの金ピカの部分とくっつく相方（複数）が ついてるフレームをBとする。

ICカードを載せる台みたいなのがあって（台じゃなくてもいいけど :-）、その台が何もしてないときに休んでる位置とカードを読み書きしてる時の位置の間をICカード載せながら動くようになっててBで固定されるようになっている（ここちょっと自信ない）。

（中略）

この特許はAとBがあって、この金ピカの相方を使ってICカード読取り機が入ってる装置との間に回路が形成されるようになっているICカード読取り機であって（面倒くさいので適当）、...

あんまり意味ないかも

--
AVG anti-virus data base out of date

Re:宣言的プログラミング

[Youth (28154)]

いっそのことXMLで特許文書のフォーマットを作るというのは？

--
Youthの半分はバファリンでできています。

公報なら既にXMLですよね

[dama4slash (785)]

>いっそのことXMLで特許文書のフォーマットを作るというのは？
特許庁発行のDVD-ROM公報のフォーマットはXMLなので、
申請する文書も最初からXMLにできなくもない気はしますね。

しかし、昨年はCD-ROMのSGMLからDVD-ROMのXMLへ切り替わるので大変でした。

そしてH18年1月には、IPCが8版に。
特許庁の実務者説明会、福岡は満員と盛況ですね。

でも

[Anonymous Coward]

結局本文を読みなおさないとダメですよね。

本文から変換された文章は伝聞にしか過ぎませんから
法的にどうかという解釈の場合もう一度読む必要があります。
結局、成れたほうが手っ取り早い気がするんですよね

#難解な文章より
#わかりやすい文章の書き方を具体的に決めたほうがいいと思うのですが。

Re:でも

[Yggdra (14017)]

> #わかりやすい文章の書き方を具体的に決めたほうがいいと思うのですが。

弁理士の資格を持つ客員教授の台詞ですけど、特許文書というのは「難解に見えるけど構造がだいたい決まっているので、慣れれば わかりやすい」んだそうです。問題は、一般人は慣れないところにあるんですけどね。あれは日本語じゃないと思った方がいい、と、その教授は言っておりました。

ただ、だからこそこんな機械的な解析が効果を上げやすいんだな、と思うと、功罪あるかな、という気がします。難しいところだなぁ。

Re:でも

[Anonymous Coward]

事実、慣れれば読みやすいです。特許の文書は、少なくとも日本の弁理士が書いた文書であれば、形式も文章表現もほぼ同じに固められています。ですのでそれに親しんでしまえば、どこを読めば要点がつかめるのかも、なにを主張したいのかも、かなり迅速に把握できるようになると思います。膨大な数の審査請求をこなさなければならない特許庁内部ではそんな風に文書を読み飛ばしながらばっさばっさと……げふげふ。

というわけなので、今回の技術も、結構的確に実現できているのではないかと思っています。特に特許文書に慣れていない人に対して効果的でしょうね。そういえば自分も、相関が複雑な請求項群をツリー形式に書き直したことがあったなぁ～

特許庁の中のお仕事をお手伝いしたことがあるのでACで……

Re:でも

[xan (25964)]

正直言って、素人が書いたかのような文章からなる請求項の方が遥かに読みづらいっす。何を請求してるのか良くわかりません。

>膨大な数の審査請求をこなさなければならない特許庁内部ではそんな風に文書を読み飛ばしながらばっさばっさと……げふげふ。

慣れればバッサバッサと読めるんですよね。図面見て、技術分野見て、従来の技術と課題みて、課題の解決法見て…で、請求項読まなくても内容は大体わかります。請求項も、ほとんどのものは従属クレーム読み飛ばし。

Re:でも

[Anonymous Coward]

> あれは日本語じゃないと思った方がいい

特許制度を欧米から持ってきたときに、向こうの特許を直訳したのが
始まりじゃないかと思っています。

米国特許は請求項（claim）の位置が一番後ろだったりして、ちょっと
形が違いますが

ありがとうございます

[Anonymous Coward]

- 特定アジア技術者一同より

#おまえらいいかげんにせーよ

無効性判定

[Anonymous Coward]

特許文書が読みやすくなったお陰で無効な特許を見つけやすくなったりすると良いですね。

でも、もしかすると「特許文書を読みやすくする技術」の特許の無効が判明っていうオチが待ってるかも…

いや、本当に欲しいのは

[Anonymous Coward]

ふつ～の文章に直してくれる変換プログラムだ。
普通に読むだけで頭に入っていくような、多重参照などの
ない文章に直して、「～するところである装置」を「する装置」
などにしてくれるもの。

それで気になった箇所をマウスで選択して反転させると、
原文のどの箇所かを示してくれるようだと便利。

Re:いや、本当に欲しいのは

[ginga (20279)]

文章自体は変換しなくてもいいから(誤変換が入る可能性もあるし)， 最低限，インデントしてブロックが見える文章にして欲しい．

ついでに，インデントだけなら，特に従来との互換性に問題がないはずなので， そもそもの元の特許文書の段階からインデントして書いておいて欲しい…

ちっちっ、分かってないな。

[Anonymous Coward]

いまどき読みやすくするなら「萌えマンガ」化ですよ。

特許文書を読み込んで、
「萌える画像符号化装置」とか
「萌える！オンライン購入システム」
とかに変換してくれるソフトｷﾎﾞﾝﾇ！

H.264符号化装置がメイド服着て出てきたりしたら、やだなぁ。

Re:ちっちっ、分かってないな。

[welchman (25784)]

それでは、職場で読みにくいものになってしまいます。

これと似てる

[Anonymous Coward]

jcorrect を利用した技術文章校正のヒント [www.ispl.jp]。 ソース [www.ispl.jp]もどうぞ。

しかしね

[Anonymous Coward]

2ページも3ページも、「、」ばかりが続き、忘れた頃に「.」がある、っていうあの文書の形式には歴史がある。でも、なんとかしてほしい、と思うものの１つだよね。

製品化の目標が半年後というけれど

[Anonymous Coward]

やっぱりその暁には
「このシステムを利用した結果により生じたいかなる損害も補償するものではございません」とか、
そういう文言は健在なのだろうなぁ。
とは思うけれど、このテのシステムでその免責だと、なんだかとても複雑な気がする。