ソフトウェアの特許の取り方

ヌーラボのTATSURUです。

今回は私の得意分野？の一つである特許の話をしたいと思います。研究開発や商品企画などに関わる方には特許出願になじみはあるかもしれませんが、多くの方はあまり関わった事が無いかもしれませんね。

特にソフトウェアの特許は少し特殊な事があるように思います。そもそも特許の出願自体は会社に知財関係の部署があって弁理士さんと相談して進められる環境でないと難しいですよね。

私も複数の特許出願に関わった事がある程度ですので、ものすごく詳しいという事ではないのですが、繰り返し出願することでコツみたいなものがあるように感じたので紹介したいと思いました。

間違っていることもあるかもしれませんが、私の事例が何かの参考になればと思います。

はじめての特許出願

私がはじめて特許を出願したのは2004年になります。当時携わっていた研究開発のプロジェクトで文書管理システムをXML技術を応用するプロジェクトに関わっていました。

もう２０年前になりますね・・・。

たしかWikiのエンジンを元にXMLDBにデータを保存し、上位の文書から下位の文書のテンプレートを導出する仕組みで特許を出願しました。

このときWIkiの実装で参考にさせてもらったのが、「MobWiki」でヌーラボ創立メンバーの一人である縣俊貴さんの所属していたプロジェクトのOSSだったと思います。時系列がちょっと怪しいですが、当時よく勉強させてもらいました。

一応、今でも「コチラ」に特許情報は公開されているようです。

私は当時は派遣社員でしたので、プロジェクトリーダーと連名で出願したのですが、弁理士さんにも相談しながらどうすれば特許性を持たせられそうかを相談したように思います。

たしかこの特許を出願するタイミングではある程度の仕組みはできていたものの構想の段階でしたので、特許性を出すために統計的なアプローチを盛り込んで過去文書の傾向からテンプレートを作るというアイデアになったかと思います。

今では大したことのないアイデアかもしれませんが、当時は機械学習やディープラーニングという言葉は出てきてなかったと思うので新規性があったのかもしれません。

このアイデアは、過去のプロジェクトのドキュメントの傾向や、マネージャーは必要と感じている内容が自然とドキュメントに記載できるという仕組みを狙っていました。

このときに、ぼんやりとですがソフトウェアで特許を出願する流れのようなものを学びました。

以降は、特許を伴う開発からは遠ざかっていましたが、私が特許に関わるきっかけはこのプロジェクトからでした。

特許出願を意識した、仕事の進め方

特許による製品の保護などを目的に積極的に特許を出願する文化が会社によってはあると思いますが、私もそういった制度などを利用していくつか特許を出願をしました。

さっと見つかるのが、以下の２つです。もう１つ２つ出願した記憶がありますが、すぐには出てきませんでした。

1. 施設内監視システムの特許

これは、温度・湿度センサーを使って室温と湿度を計測し、病院施設の地図上にヒートマップで色分けして感染症対策が必要な場所を特定しアラートを出す仕組みです。

想定していた感染症はインフルエンザなどだったので、もう少し捻ればコロナにも適応できたかもしれません。

1. 遺伝子パネル検査における情報管理システムの特許

私が開発に関わったがん遺伝子パネル検査のWEB上で管理するための仕組みで特許を出願しました。

要配慮情報にいかに安全にアクセスさせるかというような内容だったかと思います、もう記憶が薄れてしまっていますが・・・。

これらの特許は、どのようにして生み出されたかというと、一つ目は「①シーズベースの特許」で、２つ目は「②ニーズベースの特許」に区別できるかと思います。ではそれぞれ説明します。

①シーズベースの特許

先に仕組みとして何か特定の技術を用いる事を前提とした特許出願を、ここではシーズベースの特許と呼ぶこととします。

私の例では、センサーを用いる事を前提としていました。それは私の狙いがIoT技術をきかっけにクラウド技術を取り入れる事だったからです。まだIoT技術も出てきたばかりで、分野によってはそれほど活用されていないため新規開拓の余地があると考えました。

私が仕事をしていく中で、顧客の環境とIoTにはきっと親和性があると感じていましたしIoTをやるにはクラウドが必須だと考えていましたので、この特許を取っておけば、IoTとクラウドに本格的に取り組むきっかけがつかめるだろうという打算です。

当時、SONYがMESHという製品を販売しており、私はこれを購入してIoTの実験をしていましたので、ここがアイデアの出発点でした。これを使って当時の役員にプレゼンしたところうまく行きました。やはり動くものがあるのは強いですね。

シーズベースの特許の場合は、まず何ができるのかという事実の積み重ねと、何に困っているかという事実の積み重ねを行って、これらが重なる点からアイデアをまとめます。

いわゆる演繹法によって、「温度と湿度が計測できる」→「インフルエンザウィルスは一定以上の温度と湿度に弱い」→「温度と湿度を計測して一定以上に保てば、インフルエンザを予防できる」という感じで考えた、のではないかと当時の自分の思考をトレースしてみました。

②ニーズベースの特許

既にある用途・目的のシステムが作られており、このシステムに何か特許性が無いか考える事をニーズベースの特許とここでは呼びます。

なぜ、このパターンがニーズベースなのかというと、先にシステムの要件としてどういう事をしたいのかは決まっており、それをシステム化したわけなので、どういった技術を使うなどは一切関係ないからです。

私の例では、クラウド上のWEBシステムで重要な情報を受け渡す事は決まっていましたので、受け渡しを行うために必要な要素を考えていきました。

システムを作るうえで、工夫することはそのシステム特有の前提条件や他のシステムには無い特殊な事情をクリアする部分になりますので、そこにフォーカスすれば特許性を見出しやすいと思います。

この特殊な事情をどのように工夫したかという部分に、あとは範囲を付け加えれば特許出願はそれほど難しくありません。

範囲というのは、この特許が有効な範囲としてどこまでを含めるかという意味です。

具体的には、「ある重要な情報のアクセス制御に関する特許」が、「特定用途以外にも応用可能で、どのようなユーザ、業態にも適応可能なもの」だとすると、かなり範囲が広く他の特許を侵害する可能性が高まります。

範囲を限定し、「特定用途に限定していて、特定施設が、特定の目的にのみ適応可能なもの」とすると、他の特許を侵害する可能性は低くなります。

適応範囲を狭くすれば特許を取得しやすくなりますが、狭すぎると取得する意味が薄くなるので、なるべく広く取る方が価値が高くなります。

この方法の場合、範囲によっては似たような特許や近い特許も見つかる事が多いため、特許侵害しないように注意しながら、工夫したポイントと範囲を検討していきます。

既に似たような特許を探す事は特許性を見出すヒントにもなるため、他の特許がどういった観点でどの程度の範囲で特許を出願しているかを調査し、ケーススタディとする手法もお勧めです。

特許の取り方

シーズベース、ニーズベース、その両方をうまく使って特許化できそうなアイデアに仕上げていくのですが、最後に重要なポイントを紹介しておきます。

それは、「できれば目に見えるものが良い」という事です。例えば、表示の仕方や表現方法に絡められる方が、仮に他社が特許を侵害した場合に、クレームを入れやすくなります。

逆に言うと、目に見えないものはクレームが入れ難いため、製品の独自性の保護などには有効では無いという事です。

このときの表現方法は、一般的な方法・手法でもかまいません。大事なのはその表現方法とアイデアの特殊性が必然的に結びついているのかが重要だと思います。

具体的にはどのタイミングで、どこに、どのように表現するかです。（非常に汎用性が高く利便性の高い表現方法には、その表現自体に特許がある場合があるのでご注意ください）

このあたりは、こんなアイデアで特許が取れるのかなというものでも知財担当者や弁理士さんに相談してみると意外に広い範囲で有効な特許が取れる事もあるので相談してみましょう。

注意事項

特許を取得する事は、特許事務所などに相談すればそれほど難しい事ではありません。私のような専門的な知識が無くても、ちょっとしたコツが解っていれば出願できそうなアイデアをひねり出す事はできるのではないかと思います。

難しいのは、有効に活用することです。そのためには競合他社が特許を侵害してきたときにどう対応するのか決めておくこと、逆にその特許が無効であるとクレームを受けたらどうするか、など知的財産を保護するための活動の方が何倍も難しいと思います。

もう一つ大事な事として、特許出願可能なアイデアは関係者以外に見せてはいけません。知的財産の取り扱いについて取り決めの無い第3者に見せてしまうとそれは公知となり特許性を失います。

もし、第3者に見せる必要がある場合は、先にＮＤＡ（秘密保持契約）などを締結し知的財産権を守るようにしましょう。

さらに、アイデアの盗用を疑われたり、逆に盗用されるリスクを軽減させるためには、一般的には研究ノートに時系列で検討過程を残しておくと良いでしょう。ソフトウェアの場合そういったものは作っていないと思いますので、特許に該当する設計書などの電子データに公的なタイムスタンプを付与しておけば証拠になると思います。

また、特許を取る手間と維持を考えるとあえて特許は取らないという戦略もあると思います。ソフトウェアの会社はこのような戦略が一般的かと思います。（ハード寄りの会社や研究開発に熱心な会社は特許を積極的に取得する傾向があるかもしれません。）

そして最低限、他社の特許を侵害しないように知財チェックは製品リリース前にしっかりやっておきましょう。（著作権やライセンス違反なども同様です。）

まとめ

今回は、特許の取り方について簡単に紹介させて頂きました。

会社から「特許出願できそうなアイデア無い？」と言われて困っている方の参考になればと思います。

会社によっては戦略的に特許を取得するケースもありますので、せっかくやるのでれば発明者として名前も残りますので、頑張ってアイデアを出してみるのも面白いと思います。

あまり自分のアイデアを出したがらない人も居ますが、アイデアは鮮度が命なので、思いついたらなんらかの形で出した方が良いです。

そうしないと同じアイデアをきっと世界のどこかで誰かが思いついているはずなので、先を越されてしまいますので出し惜しみはもったいないです。

そのアイデアがいつかどこかで誰かの役に立つのかもしれないのですから。