見出し画像

ソフトウェア系の明細書作成(クレームの考え方)

 読んでくださってありがとうございます。特許業務法人IPXの代表弁理士COO/CTOの奥村です。先日TwitterのTLで以下のようなツイートを見かけました。なお、mio_matsuさんは懐疑的に思ってツイートをしているだけで、これが是と思っていないです(念のため、勘違い防止)。


 これに対して、こんな事務所はひどい!的な、結構、辛辣リプやリツイも目立ったんですが、そこはグッと堪えた上で、せっかくなのでソフトウェア発明の明細書を作成する上で、普段何を考えて、何を書いているかをまとめていきたいなぁと思いました。

 今回は、明細書というか、クレームの考え方について記載します。上記のツイートでの焦点は、明細書中にハードウェア構成を書く書かないということだと思いますが、これは後日別記事として書きたいと思います。

 なお、この記事に限らず、本noteの内容は初心者向けの情報発信なので、こんなの知ってるよ、という方は読み飛ばしてもらってもいいです。

1.顧客は何を実施するか?を理解する

 ソフトウェア系の発明だと、これを包含する装置やシステムが登場するかと思います。一装置で完結するものもあれば、ネットワークを介して、フロントエンド/バックエンドが登場するようなものもあるでしょう。

 特に後者に関して、顧客がどんなビジネスで何を実施するかを考える必要があります。これは発明のポイントとセットで抑えるべきところかなと思います。ちょっと例として、街中にたくさん設置されたカメラの映像を、自分のスマホで見れちゃうシステムについて考えたいと思います。こんなサービスを開発したA社が、どうにか特許をとりたいとします。現実の新規性進歩性や発明のポイントみたいなのは無視してください。

(一例)都市部に設置されたカメラの映像を各自スマホを介して見られるサービス

 このシステムの構成要素(物語の登場人物だと思ってください)は、ざっくりいうと
1.サーバ
2.カメラ
3.スマホ等の端末

 だと思います。ただ、A社が実施しているのは、実際はサーバの部分だけですね。でも「街中でカメラが映像をとらえて、その映像をサーバで処理したものが、スマホ等の端末で見られる」って考えると、どうやってもカメラやスマホ等が必要不可欠にも思います。

2.入力→処理→出力

 ソフトウェア発明で欠かせないのが、入力→処理→出力 という考え方です。もっと正確には、サブコンビネーションの考え方なんですが、分かり易いので業界的には「入力→処理→出力」という説明をする人が多いと思います。私は「サーバの気持ちになって、このサーバ君が何をするかを考えてください(笑)」と、よく言っています。

サーバは、カメラが捉えた画像データを受信して(入力)、なにか画像処理をした後に、リクエストのあった端末に、画像処理された映像を送信している(出力)。

 つまり、今回の例だと、カメラや端末は、登場させずに、「サーバは、カメラが捉えた画像データを受信して(入力)、なにか画像処理をした後に、リクエストのあった端末に、画像処理された映像を送信している(出力)」と、捉えることが大切です。

 かつて、SaaS型のサービスを提供している弊所の顧客の1つに、他社から特許侵害の警告状が来たことがあります。その警告状を見ると、侵害しているとされる特許の請求項には、顧客が実施していない端末側の処理が含まれていました。あくまでも原則は、対象製品がすべての構成要素を具備するか否かを見るべきであり、我々は端末を実施していないから、侵害ではないと反論したところ、その後相手方も諦めたのか、そのまま平和に終わりました。

 もちろんこれはあくまでも一例で、常にサーバの気持ちになって考えるというわけではないです。あくまでも顧客のビジネスと製品を理解することが重要です。

 サーバ以外の例ですと、例えばエンドユーザの端末にインストールしてもらうプログラムに特徴があるのであれば、そのプログラムが端末に何をさせるのか、を考えますよね。

3.顕現性

 入力→処理→出力の話には、もう一つ重要な観点があります。ソフトウェアの発明だと、処理(アルゴリズム)に凄い特徴があるものも出てくるかと思います。しかし、いくらその処理がすごくても、第三者がその処理を実施しているか(要は侵害品か否か)を立証できないと、そのような発明に特許をとっても権利行使をすることが難しくなります。

 そこで、なるべく見えやすい(顕現性が高い)特徴を権利化するように意識したいです。つまり入力や出力の部分です。すべての請求項に100%顕現性が担保される、ということは難しいパターンも多いのですが、少なくとも上位のクレームは顕現性を担保したいところです。

4.まとめ

 1~3を意識して、クレームを作成してみてください。クレーム作成の流派はいろいろあるので、自分がしっくりする書き方でいいと思います。

この記事が気に入ったらサポートをしてみませんか?