【事件の表示】
　平成　８年特許願第　６９５０３号「戸籍届書入力方法，そのシステム及び戸籍情報届書作成装置」拒絶査定不服審判事件〔平成　９年１０月　３日出願公開，特開平　９−２５９１８３〕について，次のとおり審決する。
【結　論】
　本件審判の請求は，成り立たない。
【理　由】
１　手続の経緯・本願発明
　本願は，平成８年３月２６日の出願であって，その請求項１に係る発明（以下「本願発明」という。）は，平成１６年８月２７日付け手続補正書により補正された明細書及び図面の記載からみて，その特許請求の範囲の請求項１に記載された次の事項により特定されるものである。
　「戸籍届書のデータによって戸籍データベースに戸籍情報を登録するときの情報処理部によって実行される戸籍届書入力方法であって，端末部を介して入力された検索キーに基づいて前記情報処理部によって戸籍データベースを検索して該当する戸籍構成員についてのデータを取得し，前記戸籍データベースに該検索キーに対応するデータがないとき前記情報処理部によって住民情報を格納する住民記録データベースを検索して該当する住民票構成員についてのデータを取得し，取得したデータのうち前記戸籍届書のデータ項目と一致するデータ項目のデータ値を，当該戸籍届書の一部として前記端末部を介するデータ入力に代えて前記情報処理部の処理対象とし，入力済の前記届書から戸籍情報を作成して前記戸籍データベースに登録することを特徴とする戸籍届書入力方法。」
　
２　引用例
　これに対して，当審の拒絶の理由に引用された，本願の出願日前に頒布された刊行物である「SX/G　MINDCITY戸籍説明書（日本語住民情報システム）」富士通株式会社，平成７年８月，P.1〜13，203〜208（以下「引用例１」という。），特開平７−２７１７８３号公報（以下「引用例２」という。）には，それぞれ，図面とともに次の事項が記載されている。
　
２−１　引用例１（「SX/G　MINDCITY戸籍説明書（日本語住民情報システム）」）の記載事項
(ア)「本章ではパッケージについて記述する。MINDCITY戸籍は戸籍業務パッケージの総称であり，機能面から３つに分けて提供する。主業務は戸籍事務をシステム化したMINDCITY戸籍である。その他，一部処理から機能を引き継いだMINDCITY除籍，住記業務と媒介項である附票業務をシステム化したMINDCITY附票から構成されている。
　図1.1にパッケージ機能外観図を示す。」（１頁３〜８行）
(イ)「1.1.1　戸籍
　1.1.1.1　システムの特長
　　・・・（略）
　(1)　戸籍業務の全面的システム化（＝戸籍原本の磁気記録化）
　　　戸籍業務は届書の届出から開始する。届書内容の把握から決裁迄の流れ，証明書の発行，届出内容に基づく関連業務帳票の発行，統計管理を全てシステム上で実現している。
　　　これによるメリットとして以下の３点がある。
　　　　・証明書発行事務の簡易化
　　　　・オンラインによる異動処理が可能になる。
　　　　・関連事務帳票出力事務の簡易化
　(2)　住記，附票連携の実現（個人番号によるリンク）
　　　戸籍附票は戸籍原本と項目を共有しているため，今回の原本磁気記録化により初めて戸籍業務と連携した処理が可能になる。戸籍附票ＤＢ上に戸籍番号，住記個人番号（住民の場合）の両者を持ち住記連携を容易に行うことができる。」（２頁２〜１７行）
(ウ)「1.1.1.3　システム機能からみた戸籍事務
　　MINDCITY戸籍をシステム的な視点からみると図1.2の機能概要図になる。ここではさらに詳しく説明する。
　・入力機能
　　入力機能とは戸籍及び関連事務を取り扱う上で必要な情報を収集する機能をいう。
　　入力機能の流れを以下に示す。
　　MINDCITY戸籍では届出及び送付に関する戸籍異動を処理の契機として開発している。事件本人が本籍人の場合は本人を特定する，及び届書入力の補助の２つを目的として原本，附票を検索する。
　　この結果，原本を保管庫から抽出して内容を移記する必要が無くなるため大幅な省力化を可能とする。」（４頁下から３行〜５頁下から９行）
(エ)「1.1.2　戸籍附票
　1.1.2.1　システムの特長
　　戸籍附票は本籍人に対して個人単位で住所情報を管理するものである。従って，戸籍データベースの個人特定情報を戸籍対戸籍附票間で共有している（具体的には本籍，筆頭者氏名，個人氏名，生年月日を指す）。
　　戸籍附票をシステム化するにあたって上記共有項目については一元管理することを前提にしているため戸籍附票は戸籍原本に一部住所情報を追加したものになっている。附票の単独運用はありえず，戸籍とペアでセットアップを行って運用することが大前提である。
　(1)　戸籍との完全連動
　　　戸籍異動に伴う附票情報の異動を戸籍の決済処理と同期を取った形で完全連動で行う。但し，住基個人カード，仮附票からの確定入力が場合によって必要になる。
　(2)　住基とのリンク
　　　戸籍附票は住民記録システムと個人番号を共有することが可能であり，検索ＫＥＹとしても活用出来る。戸籍原本とも戸籍番号でリンクしているため附票の媒介機能によって住民情報の活性化を目指す拠り所になる。」（９頁１〜１６行）
(オ)「3.1.2　データ入力機能
　　データ入力機能とは，戸籍事務を取り扱う上で必要とされる情報を収集し，その目的に応じてデータ編集する機能をいう。
　　MINDCITY戸籍は，データの一元的管理を基調にシステム設計が施されているため，事務上必要とされる情報は一度の入力操作によって収集される（図3.2参照）。
　　MINDCITY戸籍は，届書及び送付に関する戸籍異動を処理の契機と想定して開発されている。従って，届書内容を入力することが，即ち戸籍情報の収集を意味している。また，届書のみで当該事件に関する情報の収集が不完全な場合には，既存の原本や各種証明書（死亡診断書や出生証明書等）による情報の入力も行うことになる。
　　尚，戸籍原本・受附帳以外の帳簿については，届書とこれに添付される書類（前掲の死亡診断書等）によっても情報の収集が完了しない場合がある。この場合には該当する帳簿について，届書処理と別個の処理機能を用意しているため，別の窓口から必要とされる情報を入力することもできる（図3.3参照）。」（２０４頁下から５行〜２０５頁末行）
　図3.2には，戸籍届書，既存戸籍原本，各種証明の帳票から戸籍情報が収集され，戸籍データベースに登録されることが記載されている。
　図3.3には，通常の届出入力のほかに，住民票入力，附票入力からの補足的固有情報を入力することが記載されている。
(カ)「3.1.3　補助入力機能
　　補助入力機能とは，先に述べたデータ入力機能（3.1.2　データ入力機能参照）を利用して戸籍関連情報を収集する場合に，その操作性や情報の正確性を向上させるために設けられた付加機能である。
　(1)　変換機能
　　　・・・（略）
　(2)　複写機能
　　　届書入力に際し，氏名情報，住所情報の入力軽減を目的とした項目間複写機能を有している。
　　　届書入力画面にて複写可能な項目にはＳＥＱ番号が付与してあり，複写先項目に当該番号を入力し，「複写」を指示することで処理が行われる。名のみ，または番地のみを修正するような場合に有効な機能である。」（２０６頁１〜１９行）
(キ)「3.1.5　連動機能
　　　連動機能とは，データ入力機能によって収集された戸籍異動情報を，戸籍業務以外の関連業務に活用することをいう（図3.5参照）。
　　　当機能は，システムの将来的な発展性を考慮し，次の業務分野との連動を実現している。
　(1)　戸籍附票
　　　本来は住民基本台帳事務であるが，戸籍との関連性が極めて強いため,MINDCITY戸籍で作成・編集された戸籍情報を戸籍附票事務に活用できるように考慮している。新戸籍編製時に，戸籍附票を作成する機能は標準で装備しているが，住民票・戸籍附票事務への直接的な連動は，現行戸籍法に基づく事務では認容されていないため，将来的な拡張機能としてその基本部分が開発されている。
　(2)　人口動態調査事務
　　　・・・（略）
　(3)　住所人検索
　　　届書入力時におけるデータ入力の正確性向上を目的に行われる処理で，異動者本人が住民登録されている場合に届書入力画面上に事件本人情報を反映する。各届書毎に異なる事件本人区分を極細かく選択することが可能であり，入力軽減にも貢献している。」（２０７頁下から３行〜２０８頁末行）
　図3.5には，戸籍システムと戸籍附票，人口動態調査，住民記録（住所人検索）が連動し，住民記録から戸籍システムへデータ連動することが記載されている。
　
２−２　引用例２（特開平７−２７１７８３号公報）の記載事項
(ク)「所定の前処理により作成された準マスタデータを表示し，オペレータの操作によりこれを修正して最終的なマスタデータを作成するデータ入力装置において，
　前処理において派生する少なくとも１つ以上の補助的なデータを修正すべき準マスタデータとともに表示し，
　補助的なデータと修正すべき準マスタデータ双方を相互に参照，あるいは双方の間でのデータ複写するオペレータの操作を許容し，
　補助的なデータと修正すべき準マスタデータ双方の修正を行なうことを特徴とするデータ入力装置。」（特許請求の範囲）
(ケ)「さらに，「検索」キーを利用して，詳細データ部３６，戸籍・身分事項内容部３７，あるいはデータ部３８の各部分でデータを検索できるようにしてもよい（ステップＳ１６）。たとえば，詳細データ部３６中の個人番号を参照して対応する戸籍データ，つまり詳細データ部３６，戸籍・身分事項内容部３７，あるいはデータ部３８の組を表示させ，これを編集したり，また，この内容を複写バッファに切り取って別の戸籍データで利用したりすることができる。この検索機能は，有用と思われる詳細データ部３６，戸籍・身分事項内容部３７，あるいはデータ部３８中の全てのフィールドについて実装することができる。」（段落【００３９】）
　
２−３　引用例記載発明
(1)　上記２−１の記載事項を検討するに，引用例１の戸籍システムは，戸籍届書に記載された届出内容により戸籍データベースに戸籍情報を入力するものである（記載(ア)，(オ)，図3.2）から，引用例１には，戸籍届書のデータによって戸籍データベースに戸籍情報を登録するシステムにおける戸籍届書入力方法が記載されているといえる。
　また，引用例１の戸籍システムが各処理を実行する情報処理部を備えることは明らかである。
　そして，引用例１では，項目間複写機能により氏名情報，住所情報の入力軽減を図ることができるところ（記載(カ)），この複写機能は，戸籍届書に記載された届出内容と同じデータが届出入力画面上に存在する場合に，ユーザが複写を指示することにより，戸籍システムが該データを複写して入力し，ユーザがキーボードから入力する負担を軽減するものであるから，引用例１の戸籍届出入力方法は，戸籍届書のデータ項目と一致するデータ項目のデータ値を複写により入力しているといえる。
　そして，引用例１の戸籍届出入力方法においても，戸籍情報を戸籍データベースに登録していることは，明らかである。
(2)　してみると，引用例１には，
「戸籍届書のデータによって戸籍データベースに戸籍情報を登録するシステムにおける情報処理部によって実行される戸籍届書入力方法であって，前記戸籍届書のデータ項目と一致するデータ項目のデータ値を複写により入力し，戸籍情報を前記戸籍データベースに登録する戸籍届書入力方法。」
の発明（以下「引用例記載発明」という。）が記載されていると認められる。
　
３　対比
(1)　そこで，本願発明（以下「前者」という。）と引用例記載発明（以下「後者」という。）とを対比するに，後者において，全ての戸籍届書のデータが複写によって入力される訳ではなく，複写元となるデータがない場合には，キーボードから入力されることは明らかであるから，後者においても，複写により入力されるデータ値は，戸籍届書のデータの一部であるといえる。
　そして，後者において，データ項目を複写により入力しているのは，戸籍届書のデータをキーボードから入力する代わりに，既に存在するデータを利用することにより，キーボードからの入力を不要にするためであるから，後者の「複写により入力し」は，複写元のデータが何から得られるかという点と，複写するデータの選択と複写の指示をユーザがする点は別として，前者の「戸籍届書の一部として端末部を介するデータ入力に代えて処理対象とし」に相当する。
　そして，後者においても，戸籍情報は，戸籍届書のデータがシステムに入力されると得られるのであり，入力済みの届書から作成されるといえるから，後者の「戸籍情報を前記戸籍データベースに登録する」は，前者の「入力済の前記届書から戸籍情報を作成して前記戸籍データベースに登録する」に相当する。
(2)　そうすると，本願発明と引用例記載発明は，
　「戸籍届書のデータによって戸籍データベースに戸籍情報を登録するときの情報処理部によって実行される戸籍届書入力方法であって，前記戸籍届書のデータ項目と一致するデータ項目のデータ値を，当該戸籍届書の一部として前記端末部を介するデータ入力に代えて前記情報処理部の処理対象とし，入力済の前記届書から戸籍情報を作成して前記戸籍データベースに登録することを特徴とする戸籍届書入力方法。」
である点で一致し，下記の点で相違する。
〔相違点１〕前者は，「端末部を介して入力された検索キーに基づいて前記情報処理部によって戸籍データベースを検索して該当する戸籍構成員についてのデータを取得」するステップを有するのに対し，後者はそうでない点。
〔相違点２〕前者は，「前記戸籍データベースに該検索キーに対応するデータがないとき前記情報処理部によって住民情報を格納する住民記録データベースを検索して該当する住民票構成員についてのデータを取得」するステップを有するのに対し，後者はそうでない点。
〔相違点３〕前者のデータ値は，「取得したデータのうち」であるのに対し，後者はそうでない点。
〔相違点４〕前者の全ステップは，「情報処理部によって実行される」のに対し，後者は，「前記戸籍届書のデータ項目と一致するデータ項目のデータ値を，当該戸籍届書の一部として前記端末部を介するデータ入力に代えて前記情報処理部の処理対象と」するステップにおいて，「前記戸籍届書のデータ項目と一致するデータ項目のデータ値」の選択と複写の指示をユーザが行っている点。
　
４　判断
(1)　相違点１について
　引用例２には，戸籍データを検索して得たデータを表示し，該表示されたデータを複写し，別の戸籍データで利用することが記載されており，ここにおいて，戸籍データを検索するために，キーボード等から検索キーを入力し，該検索キーに基づいて検索がなされ，該検索キーに該当する戸籍構成員についてのデータを得ていることは，当業者が容易に理解することである。
　そして，引用例１のシステムは，事件本人が本籍人の場合は，届書入力の補助を目的として戸籍データベースを検索している（記載(ウ)）から，後者において，端末部を介するデータ入力に代えて情報処理部の処理対象とするデータ値を得るために，キーボード等から検索キーを入力し，該検索キーに基づいて情報処理部によって戸籍データベースを検索し，該検索キーに該当する戸籍構成員についてのデータを得ることは，当業者が容易に想到し得ることである。
　してみると，後者において，相違点１に係る構成を付加することは，当業者が容易になし得ることである。
(2)　相違点２について
　引用例１には，個人番号によるリンクによって，住民記録システムと戸籍附票との連携を実現すること（記載(イ)），戸籍附票は戸籍番号で戸籍原本ともリンクしているため，附票の媒介機能によって住民情報の活性化が可能であること（記載(エ)），戸籍システムと住民記録をデータ連動させ，届書入力時に，異動者本人が住民登録されている場合，届書入力画面上に事件本人情報を反映し，入力軽減に貢献すること（記載(キ)）が記載されている。
　これらの記載に接した当業者であれば，後者において，端末部を介するデータ入力に代えて情報処理部の処理対象とするデータ値を得る際，戸籍データベースだけでなく，住民記録システムのデータも利用しようとすることは，ごく自然に着想することである。
　してみると，後者において，戸籍データベースに検索キーに対応するデータがないとき住民情報を格納する住民記録データベースを検索して該当する住民票構成員についてのデータを取得することは，当業者が容易に想到し得ることである。
　したがって，後者において，相違点２に係る構成を付加することは，当業者が容易になし得ることである。
(3)　相違点３について
　後者において，相違点１，２に係る構成を付加すれば，端末部を介するデータ入力に代えて情報処理部の処理対象とするデータ値を，戸籍データベースや住民記録データベースを検索して取得したデータから得ることは，自然に導出される事項である。
　そして，後者において，相違点１，２に係る構成を得ることは，上記のとおり容易であるから，相違点３に係る構成を得ることもまた容易である。
(4)　相違点４について
　引用例１では，戸籍届書のデータ項目と一致するデータ項目のデータ値を，ユーザが選択し，複写を指示しているが，戸籍届書のデータ項目と戸籍データベースや住民記録データベースのデータ項目は，戸籍附票を媒介にして１対１に対応するデータ構造とするのが通常である（本願明細書に従来技術として記載される特開平７−２１９９９８号公報参照。）から，対応するデータ項目を自動的に複写するようにすることは，当業者が必要に応じて適宜なし得ることである。
　してみると，後者の「前記戸籍届書のデータ項目と一致するデータ項目のデータ値を，当該戸籍届書の一部として前記端末部を介するデータ入力に代えて前記情報処理部の処理対象と」するステップを，全て情報処理部によって実行するようにすることは，当業者が容易に想到し得ることである。
(5)　作用効果について
　本願発明の作用効果についてみても，引用例１，２及び周知事項から当業者が予測し得る程度のものであり，格別のものとはいえない。
　
５　むすび
　したがって，本願発明は，引用例記載発明，引用例１，２に記載された事項及び周知事項に基づいて，当業者が容易に発明をすることができたものであるので，特許法第２９条第２項の規定により特許を受けることができない。
　よって，結論のとおり審決する。