アカウント名:
パスワード:
しかも、それを一文で書かなくてはいけないので、かなり四苦八苦して書いてました。
特許は、土地と同じような排他的な財産です。そして、請求項は、それを明確にするため、論理的な構成であり、論理的な言葉である必要があります。
メカ系のものなど見た目で分かるものはやり易いのですが、制御系などの無形なものを、上記のことを踏まえて、請求項という形にするのですから、慣れてる人間だって、難しいものです。
ちなみに、私が頭がいいと思うのは、特許を出す人でも、書く人でもなく、自分の関わる製品の仕様を理解し、問題になりそうな他社の特許を理解し、侵害しないという論点を見出せる開発者です。
（こういう人が味方のうちはいいのですが、反対に立場に回られると．．．何度も泣かされました）
従来、特許請求の範囲を一連の文章で記載することが一般的に行われているが、そのようにしなければならない必要性は全然ない。特に内容の複雑な発明にあっては、文章を区切り、行を改めて記載すること(個条書式)が望ましい。 (「特許法概説[第13版]」吉藤幸朔著、熊谷健一補訂、有斐閣 p.299)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
逆変換 (スコア:1, おもしろおかしい)
そこで特許文書を書かれる方に質問なのですが、もしかして、普通の文書からあの文書に変換したり、グラフを書くとあの文書が生成されるようなツールを使ってたりするんでしょうか？
＃ツール使ってるのなら、その元データも提供すればいいじゃんと思ったりして。
Re:逆変換 (スコア:2, 参考になる)
しかも、それを一文で書かなくてはいけないので、かなり四苦八苦して書いてました。
特許は、土地と同じような排他的な財産です。そして、請求項は、それを明確にするため、論理的な構成であり、論理的な言葉である必要があります。
メカ系のものなど見た目で分かるものはやり易いのですが、制御系などの無形なものを、上記のことを踏まえて、請求項という形にするのですから、慣れてる人間だって、難しいものです。
ちなみに、私が頭がいいと思うのは、特許を出す人でも、書く人でもなく、自分の関わる製品の仕様を理解し、問題になりそうな他社の特許を理解し、侵害しないという論点を見出せる開発者です。
（こういう人が味方のうちはいいのですが、反対に立場に回られると．．．何度も泣かされました）
Re:逆変換 (スコア:2, 興味深い)
Re:逆変換 (スコア:1)
amazon によると、その本が出たのは1998年ということですが、そういう主張があってなお、今のように一文で書かれるのが大半ですよね。ということは、
(1) その主張は主流派ではないので黙殺されている
(2) その主張は主流派であって、今後はそうなっていくが現状はまだ途上段階である
(3) その主張は主流派であって、法論理からすればその通りだけど実務上の問題から変化がない
のどれなんでしょうか？
Re:逆変換 (スコア:1)
いやそういうのを頭がいいと言うかは別問題ですが。
Re:逆変換 (スコア:1)
問題はコンパイルされた文書のデバッグの必要があることなんですが…読めません。
Re:逆変換 (スコア:0)
本当に大変なのは、競合他社のワケワカメな文章を読まなければ
ならないときの方です。（会社のノルマで出したような内容のない
特許だと分かったときの脱力感と言ったら…）
基本的に請求項の書き方は決まっています。
AとかBとか、特許にしたいシステムの構成要素をずらずら並べ、
「これがああなったときにどうなる」ことを特徴とするナニナニ、
で請求項１。
後は「請求項１において、ナントカがカントカであることを特徴と
するナニナニ、で請求項２。
以下、繰返し。
後ろに続く背景とか実施例はそのまま読めます。
図で示したものの
Re:逆変換 (スコア:0)
明細書の中には同じ文章をコピペするような部分があるので、そこを自動的に処理する感じです
でも基本は人力ですね。プログラムと同じだと思います。