発明提案書の書き方（特許出願業務）
前回記事では、ソフトウェアエンジニアに特許出願業務が降ってきたときの、出願までの全体の流れをまとめました。
今回はその最初の関門である発明提案書と図面について、書くときに気を付けたこと、覚えた言い回しなどを残しておきます。弁理士ではなく、あくまでタネを提供する側のエンジニア視点のメモです。
発明の詳細
書く粒度としては、特許文書を読んだ人（同一分野の技術者レベル）が発明を再現できるくらいを目指します。
そのうえで図面が重要です。事務所の方への説明も図面中心になるはずで、本文でも図面を参照しながら説明を進めることになるため（論文と同じ）、先に図面を作ってから本文を書くほうがやりやすいです。
先行技術調査
先願特許はもちろん、先に公知になっている情報があると特許にできないので、先願特許、関連研究、関連サービスを調べます（非特許文献も対象）。出願を通すという面では、発明そのものの妥当性よりも、むしろこちらのほうが大事かもしれません。
このとき、J-PlatPat での検索ワードをメモしておくと良かったです。あとで調べ直すときの手がかりになりますし、社内の担当者から聞かれることもあります。
図面
まずは他の特許の図面を見て、雰囲気を掴むのが早いです。
慣習的に使われる記号があり、たとえば楕円にクロスを描いた記号はネットワークを表します。
図の清書や修正は事務所がやってくれるので、細かい美観は気にしなくて大丈夫です。
使いそうな表現
明細書や請求項でよく見かける、あるいは自分で書くときに使った表現です。
- A は〜するためのシステムであって、前記システムの B が〜するとともに、〜する。
- 上記課題を解決する A は〜する B であって、〜するとともに、〜する。
- サーバー 10 は A を備える。
- 上記構成によれば〜ことができる。
- 〜する手段として機能させる
- 好適には〜
- 好ましくは〜
- 〜でもよい（副次的な効果を述べるとき）
- 〜してもよい（構成のバリエーションを述べるとき）
- 公知の A
- 制御部 A は〜を出力部 B に表示させる。
- 本実施形態及び以下の変更例は、技術的に矛盾しない範囲で互いに組み合わせて実施することができる。
「〜することができる」は、一見冗長ですが効果を述べる定型表現なので頻出します。
ソフトウェアの特許
特許はハードウェアとしての実現アイデアに対して発生するので、アルゴリズムだけでは特許にできません（正確には、特許庁はソフトウェアによる情報処理がハードウェア資源を用いて具体的に実現されている構成を要求している）。
なので、どのような装置構成とデータ処理を通して技術的効果を得るのかを示す必要があります。
AI 作成を伴う発明
AI の学習時の動作も構成に含めることで、出願しやすくなる場合があるようです。
AI 作成時と AI 使用時の実施方法に、それぞれ差別化点があるとよさそうです。ただしこれは、出願準備を進めながら決めていく形でも構いません（特に AI 利用時のアプリケーション構成なんて全然決まってねえよ、ということもあり得るので）。
請求項案
請求項 1 は重要です。審査官の第一印象を良くすべきとのことでした。
権利を広く取りすぎると、かえって内容が不明瞭になる可能性があります。ただし、審査官の指摘後でも明細書に書かれている範囲であれば補正できるので、まずは広めに取って提出する戦略が一般的なようです。従属項を複数用意しておいて、拒絶理由からどこまで絞れば許されるかを探って再提出するというのは、稀によくあるやり方らしいです。
従属項の関係を図に起こすと、主張範囲の関係性が分かりやすくなります。また、情報処理方法、プログラム、情報処理装置（、機械学習モデル）の並列セットもよく見られます。
--- title: 請求項の従属関係の例 --- graph TD subgraph M["情報処理方法"] c1["1"] c2["2"] c3["3"] c4["4"] c5["5"] c2 --> c1 c3 --> c1 c3 --> c2 c4 --> c3 c4 --> c2 c4 --> c1 c5 --> c1 c5 --> c2 c5 --> c3 c5 --> c4 end subgraph P["プログラム"] c6["6"] end subgraph D["情報処理装置"] c7["7"] end
なお、この例は複数の請求項に従属する請求項へさらに従属する、いわゆるマルチマルチクレームになっています。日本では 2022 年 4 月以降の出願で認められなくなったので、実際には使えません。
