これが「機能ブロック図」です。
機能ブロック図については、「何を基準にしてブロックを分ければいいのか」「機能ブロック図がなぜ必要なのか」「ハードウェア構成図とは何が違うのか」「そもそもこれは何を表しているのか」という疑問をもっている人が多いのではないかと思います。
私も、機能ブロック図の書き方をきちんと教わった記憶はありません。
多くの弁理士も、先輩の書いた特許明細書を参考にしながら、我流で機能ブロック図を書いているのではないかと思います。
※特許明細書や図面の役割については、こちらの記事で解説しています。
機能ブロック図とは「モノ」ではなく「機能」を描いた図
機能ブロック図を理解するうえで重要なのは、「機能ブロック図にある四角い箱は、＜モノ＞ではなく＜機能＞を表している」ということです。
たとえば、あるコンピュータシステムについて「イベント判定部」という機能ブロックを描いたとします。
「イベント判定部」は、あるイベントが発生したかどうかを判定するという「機能」を表しています。
コンピュータを分解しても、「イベント判定部」という部品が出てくるわけではありません。
コンピュータは、プロセッサ、メモリ、レジスタ、バス、ストレージ、通信インタフェースなど、さまざまなハードウェアを含んでいます。
これらのハードウェアの上でソフトウェアが動きます。
ソフトウェアはハードウェアに対する命令書のようなものですが、その中にはOS、デバイスドライバ、アプリケーションプログラム、仮想マシン、推論エンジンなど、さまざまなものがあります。
「イベント判定部」という機能は、ハードウェアおよびソフトウェアという計算資源の組み合わせによって実現されます。
すなわち、物理的にはさまざまなものが混然として動いているコンピュータを、「何をするものなのか」という機能の観点から切り分け直したものが機能ブロック図です。
機能ブロック図は、オブジェクト指向のソフトウェアを設計するときに作成するクラス図に似ています。
クラス図を書いたことがある人なら、機能ブロック図に抵抗感はないと思います。
ただし、機能ブロック図はプログラムの設計図ではなく、あくまでも発明を実現する上で必要な機能群およびその関係性を整理するための図です。
機能ブロック図は、本質的には抽象度の高い図です。
機能ブロック図の書き方――「認知・記憶・判断・出力」で考える
では、システムの機能をどのように分けるべきなのか。
これについて絶対的なルールはありませんが、人間の「認知・記憶・判断・出力」の4つの機能をイメージすると整理しやすくなります。
「認知」機能とは、人間でいえば目で見る、耳で聞くといった外部から情報を取得する機能（入力機能）です。
コンピュータであれば、ユーザインタフェース部、通信部、センサ、カメラなどが相当します。
「記憶」機能は、認知した情報や、過去の処理の結果を記憶する機能です。
データベースやメモリ、ストレージなどが相当します。
「判断」機能は、認知した情報と、記憶している情報とを利用して、判定、演算、選択などの制御を行います。判断結果は記憶されます。
処理機能あるいは制御機能としてとらえることもできます。
「出力」機能は、判断結果を画面に表示したり、通信によって外部へ送信する機能です。
データ処理の多くは、
・外界からの情報を認知する。
・情報を記憶する。
・認知した情報や記憶している情報に基づいて判断する。
・外界に新たな情報を伝える。
という流れで捉えることができます。
たとえば、カメラで人を撮影し、あらかじめ登録されている人物情報と照合して人物を特定し、その結果を画面に表示するシステムであれば、「撮像部（認知）」「人物情報記憶部（記憶）」「人物特定部（判断）」「表示部（出力）」といった機能ブロックに分けることができます。
人物特定部は、撮像部によって取得された画像と、人物情報記憶部に記憶されている人物情報とに基づいて人物を特定します。
これが唯一の正解ではありません。
たとえば、人物特定部を、撮像画像から人物を抽出する「人物抽出部」と、抽出された人物が誰なのかを特定する「人物特定部」とに分けてもいいかもしれません。
どこまで細かく機能を分けるかについてもルールはありません。
機能ブロックの数についても、何個が適切という基準はありません。細かく分けすぎると全体像がわかりにくくなり、大きくまとめすぎると各機能の役割が見えにくくなります。
請求項との対応関係や、発明の特徴となる処理が理解しやすい粒度で分けるのが一つの目安です。
重要なのは、発明の内容に応じて適切な機能単位に分け、発明の構成を理解しやすく整理することです。
すべてのソフトウェア発明が4つの機能を備えているわけではありませんが、4つの機能を基準として整理すれば機能ブロック図らしくなります。
より詳細な機能についても、認知・記憶・判断・出力のどこに位置づけられるのかを考えていけば、機能ブロックが多くなってもきれいに整理できます。
逆に、ハードウェア的な発想が強すぎると、プロセッサ、メモリ、通信インタフェース……というように、機能ではなく「モノ」を並べた機能ブロック図になりがちです。
モノっぽさが強くなりすぎると、発明を「機能」で整理するという機能ブロック図の目的から離れてしまいます。
特許明細書になぜ機能ブロック図を書くのか
機能ブロック図は、すべての特許明細書に必要なものではありません。
機械系の発明では、機能ブロック図を使うことはあまりありません。
ソフトウェア特許ではよく使われますが、単純なソフトウェア発明の場合には機能ブロック図を描く必要がないこともあります。
機能ブロック図を書く理由のひとつは、請求項に記載される「・・・部」という構成要件と実施形態との対応関係を明確にし、その内容を説明しやすくするためです。
たとえば、請求項に「イベント判定部」「プレイヤ登録部」「画像編集部」が登場するのであれば、実施形態の機能ブロック図にも「イベント判定部」「プレイヤ登録部」「画像編集部」を示して、それぞれがどのような機能を実行するのかを説明します。
こうしておけば、請求項に記載された各構成要件と、実施形態との対応関係がわかりやすくなります。
機能ブロック図には、発明を読者に理解してもらうためというよりも、特許明細書として必要な記載を整えるための図という側面もあります。
機能ブロック図は「このシステムには、このような機能の組み合わせによって実現されています」という全体像を簡単に示す程度でいいと思います。
機能ブロック図だけで発明を詳細説明しようとすると読みづらくなるので、フローチャートや画面図などを利用しながら、各機能ブロックの具体的な役割を説明します。
機能ブロック図に関する記載は読まなくても発明が理解できるように書く、というくらいでいいと思います。
機能ブロック図とハードウェア構成図は何が違うのか
機能ブロック図と似て非なるものとして、下記のような「ハードウェア構成図」があります。
機能ブロック図とハードウェア構成図では、見ているものが違います。
機能ブロック図が「イベント判定部」「プレイヤ登録部」「画像編集部」など、発明を機能の側から見た図です。
ハードウェア構成図は、プロセッサ、メモリ、ストレージ、通信インタフェース、バスなど、その機能を実現する物理的な土台を示す図です。
ソフトウェア発明の特許明細書では、機能ブロック図とは別にハードウェア構成図を付けることがあります。
汎用コンピュータのハードウェア構成には特徴がありませんので、汎用コンピュータを前提とした発明の場合にはハードウェア構成図はいらないのではないかと思います。
ハードウェア構成図がなくても、ソフトウェア特許は取得できます。
とはいえ、ハードウェア構成図の要否について米国や欧州の弁理士に相談すると「なくてもよい」という人には会ったことがありません。あってもデメリットはないし、あったら権利化や権利行使のときに役立つかもしれない、という消極的理由ではないかと思います。
その結果として、本当はいらないのではないかと思いつつも、安全のためにつけておく、という対応になっています。
まとめると、
・機能ブロック図：発明を機能から見る図
・ハードウェア構成図：機能実現の前提となる物理的な構成図
といえます。
機能ブロック図の書き方に、絶対的ルールはありません。
適当に四角いブロックを作ったり並べたりするのではなく「このブロックは機能なのか、モノなのか」を意識し、認知・判断・記憶・出力という大きな枠組みの中で整理すれば、機能ブロック図は描きやすくなります。
※ソフトウェア発明とハードウェアとの関係については、こちらの記事でも解説しています。