構造化プログラミングとは
コンピュータの草創期、プログラム設計者は、コンピュータ１台の動作を一気呵成に書いていました。しかし、プログラムが長くなると条件分岐が多岐にわたるなど複雑化し、メンテナンスが大変になりました。そこで、新たに登場したのが、構造化プログラミングという技法です。
構造化プログラミングとは、処理を小さな単位に分解し、階層的な構造にしてプログラミングすること。
引用元：https://kotobank.jp/word/構造化プログラミング-3287
小さな単位に分解するのは誰？
ネット上には構造化プログラミングについて詳しい解説が沢山ありますが、まず構造化プログラミングの初歩の初歩である「処理を小さな単位に分解」する点に注目します。小さな単位に分解するとは、例えば・・
（１）対象物の状況をセンサで検出する機能 （２）センサの検出結果により異常を判定する機能 （３）異常を判定すると遠隔地に対象物の映像を送信する機能・・・
前回述べたコンピュータの視点では、このような機能単位の処理の分解は困難です。コンピュータは個々の命令を逐次実行するだけ。蟻の視点です。コンピュータにとっては、自分が何のために命令を逐次実行しているか分かりません。
構造化プログラミングは、ブログラム設計者の視点に立って初めて、「処理を小さな単位に分解」できるようになります。
具体的には・・・
（１）まず、プログラム設計者の最終目的ありきから。
（２）続いて、プログラム設計者はその最終目的の達成に必要な個々の機能（function）を構想します。
（３）そして、これら個々の機能を実現する手段（means)としてコーディングを行います。
このように、機能実現手段（means plus function）の単位に分解してから組み立てることで、シンプルで正しくかつ美しい構造化プログラミングができるのです。
機能分解式の請求項
これに近い請求項の書き方は、機能分解式の請求項です。英語で言えば、means plus function Claim です。ただし「～～手段」という手段（means）を連ねて書くだけの書き方ではありません。大切なことは、機能（function)の分解です。
発明を機能に分解する・・・前回の携帯電話の例で言えば、例えばこんな感じです。
【請求項１】
音声を音声情報に変換して通信先に送信する送信部と、
前記通信先から音声情報を受信して再生する受信部と
を備えた携帯可能な電話機。
これはざっくりとした機能分解です。さらに細かく機能分解するとこんな感じです。
【請求項１】
音声を音声情報に変換する音声変換部と、
前記音声変換部で変換した音声情報を通信先に送信する音声送信部と、
前記通信先から音声情報を受信する音声受信部と、
前記音声受信部で受信した音声情報を再生する音声再生部と
を備えた携帯可能な電話機。
分解した機能を階層化してみる
構造化プログラミングに『階層化』があるように、発明を階層化することも可能です。
『Ａ，Ｂを備え、Ａは～～することを特徴とする～～装置』のようにすれば、Ａについて階層化ができます。
発明の特徴が、特にＡにある場合、Ａを階層化する表現は便利です。Ａについて更に詳しく掘り下げできます。
例えば、上記２つのクレームを組み合わせて送信部を階層化すると、こんな感じになります。
【請求項１】
音声を通信先に送信する送信部と、
前記通信先から音声情報を受信して再生する受信部とを備え、
前記送信部は、
前記音声を音声情報に変換する音声変換部と、
前記音声変換部で変換した音声情報を前記通信先に送信する音声送信部とを有する
ことを特徴とする携帯可能な電話機。
このような３パターンの請求項から分かるように機能分解と階層化は一通りでないというのがポイントです。発明の特徴をどのように捉えるかにより機能分解と階層化はかなり変化します。
そして、機能分解は出願で完了するわけではありません。審査段階や裁判にも影響が及びます。機能分解がどのように影響するかを予め考えておくことが大切です。
審査段階での機能分解
審査／審判段階は概ねこんな流れになります。
（１）審査官／審判官は、先行する引用発明１（主引例）に対して本願発明と同様の機能分解を試みる。
（２）分解された機能単位（構成要件）ごとに本願発明との一致点／相違点を判断する。
（３）そして、相違点を埋める副引例を探す。
（４）副引例を主引例に組み合わせる論理付けが本願出願時にあったかを考える。
このようにしても審査官／審判官（当業者の代表）が相違点を埋めることができなければ進歩性があると推認されます。
したがって、発明の特徴（セールスポイント）が相違点となり得るようにしっかり機能分解しておくといいですね。
裁判の場での機能分解
一方、侵害系の裁判では、係争中の対象（イ号物件）に対して特許発明と同様の機能分解を試み、分解された機能単位（構成要件）ごとに特許発明との一致（均等）を判断します。
このとき、一致せず（均等でもない）となれば、侵害ではなくなります。
出願に際しては、発明の特徴以外で不一致とならないよう機能分解しておくといいですね。
機能分解された請求項の利点
つまり、発明の特徴を捉えた上で、過不足のない機能分解が肝要となります。
発明の特徴を捉えた機能分解は、特許になりやすく、かつ侵害の立証もしやすいです。つまり強い特許といえます。
また、複雑な発明も、機能単位に表現できますから、メンテナンスも容易です。
次は、オブジェクト指向型のプログラミング技法と、多数請求項との意外な関係を見ていくことになりますが、それはまだ先です。