【事件の表示】
　平成　９年特許願第３４１６５４号「情報処理装置、情報処理方法及び情報処理プログラムを記録したコンピュータ読み取り可能な記録媒体」拒絶査定不服審判事件〔平成１１年　７月　２日出願公開、特開平１１−１７５３２７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　本願は、平成９年１２月１１日の出願であって、平成１６年１月２７日付けで拒絶査定がなされ、これに対し、同年３月３日に審判請求がなされ、同年４月２日に手続補正がなされたが、平成１８年１月１７日付けで当審より拒絶理由の通知がなされ、これに対し、同年３月２７日に手続補正がなされたものであり、その請求項１に係る発明は、特許請求の範囲の請求項１に記載された事項により特定される次のとおりのものと認める。（以下、「本願発明」という。）
　
　「オブジェクト指向技術を応用したクラスを用いて情報処理を行う装置であって、
　入力データを記憶する入力データ保持部と、
　入力クラス部、変換クラス部、及び出力クラス部の処理の流れを定義するスケジュールのパラメータを記憶するバッチ情報インスタンス保持部と、
　前記記憶されたスケジュールのパラメータを入力し、前記スケジュールのパラメータに基づいて開始メッセージを前記各クラス部へパッシングし、前記各クラス部からの終了メッセージを受信した場合には、前記スケジュールのパラメータに基づいて次のクラス部をスケジュールするバッチコントロールクラス部と、
　前記バッチコントロールクラス部から開始メッセージを受け取った場合に、入力するデータ及びそのデータへの入力処理内容を定義するパラメータにより入力処理が定義され、前記パラメータに従って前記入力データ保持部に記憶された入力データを入力し、前記パラメータに従って前記入力データの入力処理を行い、前記入力処理が完了した入力ファイルを出力し、前記バッチコントロールクラス部へ終了メッセージを出力する入力クラス部と、
　前記バッチコントロールクラス部から開始メッセージを受け取った場合に、入力するデータ及びそのデータへの変換処理内容を定義するパラメータにより変換処理が定義され、前記パラメータに従って前記入力クラス部が出力した入力ファイルを入力し、前記パラメータに従って前記入力ファイルの変換処理を行い、前記変換処理が完了した変換ワークを出力し、前記バッチコントロールクラス部へ終了メッセージを出力する変換クラス部と、
　前記バッチコントロールクラス部から開始メッセージを受け取った場合に、入力するデータ及びそのデータへの出力処理内容を定義するパラメータにより出力処理が定義され、前記パラメータに従って前記変換クラス部が出力した変換ワークを入力し、前記パラメータに従って前記変換ワークの出力処理を行い、前記出力処理が完了した出力ファイルを出力し、前記バッチコントロールクラス部へ終了メッセージを出力する出力クラス部と、
　前記出力クラス部が出力した前記出力ファイルを記憶する出力データ保持部と、
　を備え、
　前記バッチコントロールクラス部は、前記バッチ情報インスタンス保持部から前記スケジュールのパラメータを参照して前記入力クラス部、前記変換クラス部、及び、前記出力クラス部のスケジューリングを行い、前記変換クラス部は、前記バッチコントロールクラス部の開始メッセージを受け取り、メソッドを１回若しくは複数回繰り返すことにより、データ処理を施すことを特徴とする情報処理装置。」
　
２．当審の拒絶理由
　当審より通知された、平成１８年１月１７日付けの拒絶理由（以下、「当審拒絶理由」という。）には、以下のものが含まれている。
（１）本願の各請求項に係る発明は、引用文献１及び２に記載された発明に基いて当業者が容易に発明することができたものであるから、特許法第２９条第２９条の規定により特許を受けることができない。（Ｂ−４）
（２）本願は、明細書及び図面の記載が不備のため、特許法第３６条第４項並びに第６項第１号及び第２号に規定する要件を満たしていない。（Ｄ−１）
　
　以下、上記各拒絶理由が解消したか否かについて検討する。
　
３．特許法第２９条第２項についての検討
３−１．引用発明１
　当審拒絶理由に引用された、本願の出願日前である平成９年７月２５日に頒布された刊行物である、戒田・高知尾著、”オブジェクト指向バッチ処理システム”、三菱電機技報、三菱電機技報社、第７１巻、第７号、第５６−６１頁（以下「引用文献１」という。）には、次の事項が記載されている。
　
（ア）「そこで，オブジェクト指向によるシステム開発に独自の考え方でチャレンジし，ビジネスシステムにおけるオブジェクト指向によるバッチ処理システムの実現方式を導き出し，生産性・運用性向上のための仕組みを開発した。
　その中心となるのが独自に開発した”ＯＣＯ”（Object Control Object）であり，本稿では，このＯＣＯを中心としたオブジェクト指向バッチ処理システムの実現方法，ＯＣＯの概要とその特長について述べる。」
（第５６頁左欄第５−１２行）
　
（イ）「（３）ＯＣＯの機能と特長
　独自に開発したＯＣＯにより，オブジェクトの起動，排他，履歴を一括管理することができ，運用性を向上させることができる。」
（第５６頁右欄第９−１２行）
　
（ウ）「２．１　現状方式
　オブジェクト以降開発について述べる前に，従来行われてきたバッチ処理方式とその問題点について考察する。…（中略）…
　例えば，
（１）ｊｏｂＡの中でプログラムＸによってファイル１を作成する。
（２）ｊｏｂＣの中でプログラムＹによってファイル２を作成する。
（３）ｊｏｂＡとｊｏｂＣによって作成されたファイル１とファイル２を利用して，ｊｏｂＤのプログラムＺでファイル３を作成する。
といった形である。」
（第５７頁左欄第２１行−右欄第７行）
　
（エ）「今回オブジェクト指向への取組方針として，個々のオブジェクトについて，従来のようなオブジェクト間の関係は全く意識させない作りを目指し，データとそれを扱う処理機能（メソッド）はカプセル化し，独立した部品（オブジェクト）としている。そのために設定したオブジェクト作成規則が次の定義である。
（１）　オブジェクトは，必ずＯＣＯからのメッセージによって起動され，ＯＣＯへメッセージを介して終了する。
（２）　ＯＣＯは，オブジェクトから受けたメッセージにより，次に起動するオブジェクトを判断し，メッセージとともに該当するオブジェクトを起動する．
　即ちオブジェクトは，ＯＣＯを介したメッセージの受け渡しによって必ず起動され，終了する。」
（第５８頁左欄第１０−２２行）
（審判注：引用中「（１）」と「（２）」は、実際は丸囲み数字。）
　
（オ）「　ＯＣＯの持つ主な機能は次のとおりである。
（１）　オブジェクトの起動制御
　各オブジェクトから受けたメッセージ（出力テーブル名）を基に，起動オブジェクト関連マスタテーブル（メッセージと後続のオブジェクトとの関係を持ったマスタテーブル）を参照し，起動オブジェクトを選択して起動をかける。オブジェクト終了時には再びメッセージを受け取る。」
（第５８頁右欄第１８−２４行）
　
（カ）「メッセージ受付ルーチン
各オブジェクトからメッセージを受けて起動され，後続オブジェクトが存在するかどうかを起動オブジェクト関連マスタを検索して判断する。
後続オブジェクトが存在した場合は，その検索して得た後続オブジェクト名を待ち行列テーブルに格納する。」
（第５９頁表１中）
　
（キ）「オブジェクト起動ルーチン
待ち行列テーブルを検索し，テーブル内のオブジェクトの起動可／不可の判断を行う。
起動可の条件を満足したオブジェクトについて起動を行う。
　起動不可の条件は次のとおり。
（ａ）　起動禁止状態オブジェクトである。
　　　起動禁止オブジェクトテーブルに該当オブジェクトが存在するかどうかで判断する。
（ｂ）　該当オブジェクトが現在稼働中である。
　　　稼働中オブジェクトテーブルに該当オブジェクトが存在するかどうかで判断する。
（ｃ）　前回分の出力テーブルが存在する場合。
　　　前回処理が完結していないために前回分出力テーブルが存在すると判断。
このルーチンは，あらかじめ設定された時間間隔で自動起動されるルーチンである。」
（第５９頁表１中）
　
（ク）「テーブル情報テーブル
各オブジェクトが実行された際に各オブジェクトで作成するテーブル。オブジェクトが作成するテーブル名を保持する。」
（第５９頁表２中）
　
（ケ）「起動オブジェクト関連マスタテーブル
出力テーブル名とその後続オブジェクトとの関係を保持するマスタテーブル。また，各オブジェクトの稼働制限時間を持つ。」
（第５９頁表２中）
　
（コ）「オブジェクト出力テーブル関連マスタテーブル
オブジェクトとそのオブジェクトが出力するテーブル名の関係を保持しているマスタテーブル」
（第５９頁表２中）
　
（サ）第６０頁の図５には、ＯＣＯの内部ロジックについて記載されており、その記載からして、以下の事項が見て取れる。
　
　メッセージ受付ルーチン（一般の各オブジェクトで起動される）の処理として、
（１）オブジェクト１１からのメッセージ受付によるメッセージ受付ルーチンの起動
（２）稼働中オブジェクトテーブルからオブジェクト１１削除
（３）ログテーブルにオブジェクト１１のＥＮＤメッセージ出力
（４）テーブル情報テーブルの読込み
（５）起動オブジェクト関連マスタを利用し，後続オブジェクト検索
（６）待ち行列テーブルに後続オブジェクト出力
（７）テーブル情報テーブルの削除
を行うこと、及び、
オブジェクト起動ルーチン
（常駐オブジェクトで設定したインターバル時間ごとに起動される）の処理として、
（８）待ち行列テーブルの読込み
（９）起動禁止オブジェクトテーブルを検索して，該当オブジェクトが起動禁止かどうかチェック
（１０）稼働中オブジェクトテーブルを検索して，該当オブジェクトが稼働中かどうかチェック
（１１）オブジェクト出力テーブル関連マスタを検索して，出力テーブルが残っていないか（前回処理分が未処理でないか）をチェック
（１２）起動させるオブジェクトを待ち行列テーブルから削除
（１３）ログテーブルにオブジェクト２１のＳＴＡＲＴメッセージ出力
（１４）稼働中オブジェクトテーブルに該当オブジェクト出力
（１５）該当オブジェクトの起動
を行うこと。
（審判注：引用中「（１）」等の括弧付き数字は、実際は丸囲み数字。）
　
（シ）「図３に示すとおり，オブジェクトからＯＣＯへのメッセージとなるインタフェースパラメータは次の三つである。
（１）　オブジェクト名
　オブジェクト自分自身の名前である。
（２）　テーブル情報テーブル名
　オブジェクトが作成した出力テーブル名を保持したテーブルを示す。
（３）　エラーコード
　オブジェクトの実行結果を示すコードで，エラー発生時には，ＩＳＶソフトウェアから返されたエラーコードを独自のエラーコードに読み替えたコードを返す。」
（第６１頁左欄第４−１５行）
　
　上記（ウ）の記載からして、バッチ処理とは、別のジョブが作成したファイルを入力して、処理を行い、別のファイルを生成し他のジョブへ出力するものであるから、引用文献１に記載のオブジェクト指向バッチ処理システムにおいても、各オブジェクトは、別のオブジェクトが作成したファイルを入力して処理を行い、別のファイルを生成して他のオブジェクトへ出力していると認められる。
　上記（エ）からして、オブジェクトはメッセージを受信すると、メソッドを実行することによりデータ処理を施している。
　上記（ケ）、（コ）及び（サ）からして、ＯＣＯは、メッセージを受信すると、起動オブジェクト関連マスタテーブルを参照して後続オブジェクトを決定し、一方、オブジェクト出力テーブル関連マスタテーブルを参照して、オブジェクトを起動すべきか否かを決定しているから、ＯＣＯは、次のオブジェクトをスケジュールする機能を有しており、かつ、起動オブジェクト関連マスタテーブル及びオブジェクト出力テーブル関連マスタテーブルは、処理の流れを定義するスケジュールのパラメータを記憶したものである。
　
　よって、上記（ア）乃至（シ）からして、引用文献１には次の発明（以下「引用発明１」という。）が記載されている。
　
　オブジェクト指向バッチ処理システムであって、
　処理の流れを定義するスケジュールのパラメータを記憶する起動オブジェクト関連マスタテーブル及びオブジェクト出力テーブル関連マスタテーブルと、
　前記スケジュールのパラメータを入力し、前記スケジュールのパラメータに基づいてメッセージを各オブジェクトへ送信し、前記各オブジェクトからのメッセージを受信した場合には、前記スケジュールのパラメータに基づいて次のオブジェクトをスケジュールするＯＣＯ（Object Control Object）と、
　前記ＯＣＯからメッセージを受け取った場合に、ファイルを入力し、処理を実行し、処理結果としてファイルを出力する複数のオブジェクトと、
　を備え、
　前記ＯＣＯは、起動オブジェクト関連マスタテーブル及びオブジェクト出力テーブル関連マスタテーブルを参照して前記各オブジェクトのスケジューリングを行い、前記各オブジェクトは、メソッドを実行することにより、データ処理を施すことを特徴とするオブジェクト指向バッチ処理システム。
　
３−２．引用発明２
　当審拒絶理由に引用された、本願の出願日前である平成８年１２月１３日に頒布された刊行物である特開平８−３２８８４０号公報（以下「引用文献２」という。）には、次の事項が記載されている。
　
（ス）【０００９】
【課題を解決するための手段】本発明のプログラム合成方法では、オブジェクト指向プログラミング技術を用い、大きく分けて次の３種類のオブジェクトを組み合わせることによってプログラムを合成する。
【００１０】(1)データ項目オブジェクト
特定の種別のデータを抽象化したオブジェクト。データ種別により異なる種類のデータ項目オブジェクトが存在する。データ値を属性として持ち、データ値に対する基本的な操作(大小比較や文字列変換等)をインターフェースの統一されたメソッドとして持つ。
【００１１】(2)データ入出力オブジェクト
磁気ディスク装置、プリンタ等のデータ入出力装置を介して、データ項目オブジェクトとの間でデータ入出力を行うオブジェクト。装置の種別や、装置で用いられるデータ書式等によって、それぞれ異なる種類のデータ入出力オブジェクトが存在する。データ取得およびデータ書き込みの手続きをインターフェースの統一されたメソッドとして持つ。
【００１２】(3)データ処理オブジェクト
データ項目オブジェクトのメソッドを定型的な順序で呼び出すことにより、データ項目オブジェクトに対して特定の定型的処理を行うオブジェクト。定型的処理の内容によりそれぞれ異なる種類のデータ処理オブジェクトが存在する。データ取得およびデータ書き込みの手続きをインターフェースの統一されたメソッドとして持つ。
【００１３】データ入出力オブジェクトおよびデータ処理オブジェクトの、データ取得メソッドおよびデータ書き込みメソッドは、同一のインターフェースによって統一されている。従って、これら２つのメソッドのみを使用する限りは、データ入出力オブジェクトおよびデータ処理オブジェクトは、同一の種類のオブジェクトとして扱う事ができる。以後、データ入出力オブジェクトとデータ処理オブジェクトを包括するオブジェクトの種別として、データ受け渡しオブジェクトという用語を定義し、説明を続ける。
【００１４】データ処理オブジェクトは、データ取得用のデータ受け渡しインスタンスと、データ書き込み用のデータ受け渡しインスタンスを、属性として持つ。データ取得メソッド又はデータ書き込みメソッドが呼び出されると、データ取得用のデータ受け渡しインスタンスのデータ取得メソッドを呼び出して、データ項目インスタンスを取得する。次に、取得したデータ項目インスタンスのメソッドを定型的な順序で呼び出し、その結果として得られたデータ項目インスタンスを、データ書き込み用のデータ受け渡しインスタンスの、データ書き込みメソッドに渡す。ここでメソッド呼び出しが行われたデータ受け渡しオブジェクトがデータ処理オブジェクトである場合には、上記と同様の動作が再帰的に繰り返される。」
　
（セ）【００４７】次に、図１１に示すオブジェクト接続情報入力画面によって、オブジェクト接続情報104を作成する。入力画面では、オブジェクトの組み合わせと、個々のオブジェクトの詳細情報を入力する。まず、1101に示すネットワーク図により、完成プログラムにおけるオブジェクト間のデータの流れを定義する。1102〜1106に示すアイコンは、完成プログラムで使用されるオブジェクトを表現しており、１つのアイコンが一つのインスタンスに対応する。アイコン間を結ぶ矢印は、インスタンス間のデータの流れを表現する。以後、ネットワーク図をシステムフロー図と呼ぶ。システムフロー図1101では、次のようなデータの流れが定義されている。
【００４８】(1)総務部人事マスタファイル1102は、マージ部品1104からの要求を受けるとファイルからデータを読みだし、結果として得られたレコードインスタンスを返す。
【００４９】(2)経理部人事マスタファイル1103は、マージ部品1104からの要求を受けるとファイルからデータを読みだし、結果として得られたレコードインスタンスを返す。
【００５０】(3)マージ部品1104は、総務部人事マスタファイル1102と、経理部人事マスタファイル1103からレコードインスタンスを取得し、該レコードインスタンスの大小比較メソッドを呼び出す。大小比較した結果、より(キー項目が)小さいと判断されたレコードインスタンスを出力する。出力したレコードインスタンスが総務部人事マスタファイル1102のものならば、総務部人事マスタファイル1102から1レコード取得し、経理部人事マスタファイル1103のものならば、経理部人事マスタファイル1103から1レコード取得する。該操作を繰り返すことにより総務部人事マスタファイル1102、経理部人事マスタファイル1103双方のレコードが、キー項目がソートされた状態で順次出力される。
【００５１】(4)選択部品1105は、マージ部品から入力したレコードの特定フィールドが特定の値である場合のみ得られたレコードを研修員一覧票1106に出力する。(5)研修員一覧票1106は、渡されたレコードを帳票に出力する。
【００５２】次に、1107〜1111に示す表により、個々のプログラム部品インスタンスの詳細定義を行う。全ての詳細定義1102から1111において、個々のインスタンスの所属クラスおよびインスタンス名を定義するが、その他の付加情報を定義しなければならないインスタンスも存在する。総務人事マスタファイル1102及び、経理部人事マスタファイル1103の詳細定義1107、1108では、使用するファイルのファイル名を定義する。選択部品1105の詳細定義1110では、レコードの中の、最初から何番目のフィールドを検査するのかを定義する検査フィールド番号と、監査したフィールドがどのような値である場合にレコードを出力するかを定義する適合値の、２つの付加情報を定義する。」
　
　上記（セ）には、総務部人事マスタファイル及び経理部人事マスタファイル（データ入出力オブジェクト）は、ファイルからデータを読みだし、結果として得られたレコードインスタンスをマージ部品（マージオブジェクト）に出力し、マージ部品は、総務部人事マスタファイル及び経理部人事マスタファイルから取得したレコードをキー項目がソートされた状態で順次選択部品（選択オブジェクト）に出力し、選択部品は、入力したレコードの特定フィールドが特定の値である場合のみ得られたレコードを研修員一覧表（データ入出力オブジェクト）に出力し、研修員一覧表は、渡されたレコードを帳票に出力する事例が記載されているが、この事例において、上記（ス）を考慮すると、総務部人事マスタファイル及び経理部人事マスタファイルは、データ入出力オブジェクトであり、マージ部品及び選択部品はデータ処理オブジェクトであり、研修員一覧表は、データ入出力オブジェクトである。また、総務部人事マスタファイル及び経理部人事マスタファイルは実質的にはファイルからの入力処理を専用に行っているから、データ入力オブジェクトといえ、研修員一覧表は、帳票への出力処理を専用に行っているから、データ出力オブジェクトといえる。
　また、マージ部品及び選択部品が行うデータ処理は、入力したデータとは異なる出力を形成しているから、実質的に変換処理を行っているといえる。
　
　よって、上記（ス）及び（セ）からして、引用文献２には次の発明（以下「引用発明２」という。）が記載されている。
　
　データ入力オブジェクトが、ファイルからデータを入力して入力処理を行いレコードインスタンスを出力し、データ処理オブジェクトが、データ入力オブジェクトが出力したレコードインスタンスを入力して変換処理を行い、処理結果のレコードを出力し、データ出力オブジェクトが、データ処理オブジェクトが出力した処理結果のレコードを入力し、帳票に出力する出力処理を行う、オブジェクト指向プログラミング技術。
　
３−３．本願発明と引用発明との対比
　本願発明と引用発明１とを対比すると、引用発明１の「起動オブジェクト関連マスタテーブル及びオブジェクト出力テーブル関連マスタテーブル」は、本願発明の「バッチ情報インスタンス保持部」に対応している。
　Ｃ＋＋等の周知のプログラミング言語の仕様からして、オブジェクト指向プログラミングにおいては、クラスにインスタンス値を埋め込むことによりオブジェクトをインスタンス生成し、当該オブジェクトが実行の対象となることは技術常識であるから、引用文献１に記載のシステムにおいて、各「オブジェクト」（ＯＣＯを含む）は、クラスにインスタンス値を埋め込んでインスタンス生成されたものと推認できる。
　一方、請求人は、平成１８年３月２７日付けの意見書の「Ｂ−２（４）について」の項目において、「「クラス」自身は、「オブジェクトのテンプレート」ですので、それ自体は機能致しません。しかしながら、例えば請求項１にも記載しました通り、処理の手順及びその内容が示されたパラメータをインスタンス値として埋め込む事により、その振る舞いが決定されるのであります。ここで、例えば、請求項１に記載された「入力クラス部」、「変換クラス部」、及び、「出力クラス部」は、バッチ情報インスタンス保持部に記憶されたパラメータを受け取りことにより処理内容が定義されたものであります。」と主張している。（ここで、「パラメータを受け取りことにより」は「パラメータを受け取ることにより」の誤記であると認められる。また、請求項１の記載において、「バッチ情報インスタンス保持部」に記憶されているのは、「スケジュールのパラメータ」であり、これは、各「クラス部」の処理内容を定義するものではないから、各「クラス部」が、「バッチ情報インスタンス保持部に記憶されたパラメータを受け取ることにより処理内容が定義されたもの」であるという主張は、請求項１の記載に基づいたものではない。）
　そうすると、処理の実行時において、各「クラス部」は、すでにインスタンス値（パラメータ）が埋め込まれた後の状態であるから、前記技術常識及び請求人の主張からして、その実体は「オブジェクト」である。
　すると、引用発明１の「ＯＣＯ（Object Control Object）」は、スケジュールのパラメータに基づいてオブジェクトをスケジュールするオブジェクトであるから、本願発明の「バッチコントロールクラス部」に対応している。
　また、引用発明１の各「オブジェクト」は、スケジュール対象のオブジェクトであり、クラスにパラメータ（インスタンス値）を埋め込むことによりインスタンス生成され、かつ、ファイル等のデータを入力し、データ処理を施し、処理が完了したデータを出力している点で、本願発明の各「クラス部」と共通している。
　また、引用発明１の「オブジェクト指向バッチ処理システム」は、オブジェクト指向を応用したクラスを用いて情報処理を行う装置であることは自明であるから、本願発明の「オブジェクト指向を応用したクラスを用いて情報処理を行う装置」に対応している。
　さらに、引用発明１において、ＯＣＯから各オブジェクトに対して送信（パッシング）されるメッセージは、本願発明の「開始メッセージ」に対応し、各オブジェクトからＯＣＯに対して送信されるメッセージは、本願発明の「終了メッセージ」に対応している。
　また、本願発明において、「変換クラス部」は、どのような場合にメソッドを１回行い、どのような場合にメソッドを複数回繰り返すのか特定しておらず、かつ、「変換クラス部」以外のクラス部（「入力クラス部」及び「出力クラス部」）が、メソッドを実行することなくデータ処理を行うものとは特定されていない（実際、本願の図２の記載からして、本願発明において、「入力クラス部」及び「出力クラス部」は、開始メッセージを受け取るとメソッドを実行することによりデータ処理を行っている。）から、本願発明は、引用発明１において、各オブジェクトが、「メソッドを実行することにより、データ処理を施す」という態様を実質的に含んでいる。
　
　よって、両者は、
　
　「オブジェクト指向技術を応用したクラスを用いて情報処理を行う装置であって、
　入力データを記憶する入力データ保持部と、
　スケジュールの対象オブジェクトの処理の流れを定義するスケジュールのパラメータを記憶するバッチ情報インスタンス保持部と、
　前記記憶されたスケジュールのパラメータを入力し、前記スケジュールのパラメータに基づいて開始メッセージを前記各スケジュールの対象オブジェクトへパッシングし、前記各スケジュールの対象オブジェクトからの終了メッセージを受信した場合には、前記スケジュールのパラメータに基づいて次のスケジュールの対象オブジェクトをスケジュールするバッチコントロールクラス部と、
　前記バッチコントロールクラス部から開始メッセージを受け取った場合に、パラメータによりインスタンス生成され、前記パラメータに従ってデータを入力し、前記パラメータに従って前記データの処理を行い、前記処理が完了したデータを出力し、前記バッチコントロールクラス部へ終了メッセージを出力する複数のスケジュールの対象オブジェクトと、
　を備え、
　前記バッチコントロールクラス部は、前記バッチ情報インスタンス保持部から前記スケジュールのパラメータを参照して前記スケジュールの対象オブジェクトのスケジューリングを行い、前記スケジュールの対象オブジェクトは、前記バッチコントロールクラス部の開始メッセージを受け取り、メソッドを１回若しくは複数回繰り返すことにより、データ処理を施すことを特徴とする情報処理装置。」
　
　の点で一致し、以下の点で相違している。
　
［相違点１］
　本願発明は、複数のスケジュール対象オブジェクトとして、「入力クラス部」、「変換クラス部」、及び「出力クラス部」を有し、「入力クラス部」は、「入力データ保持部」に記憶された入力データに対して入力処理を行い、入力ファイルを出力し、「変換クラス部」は、入力ファイルに対して変換処理を行い、変換ワークを出力し、「出力クラス部」は、変換ワークに対して出力処理を行い、出力ファイルを「出力データ保持部」へ出力するのに対し、引用発明１では、スケジュール対象オブジェクトは、データを入力し、データ処理（変換処理）を施し、処理が完了したデータを出力する点において本願発明の「変換クラス部」と類似しているものの、入力処理専用及び出力処理専用のオブジェクトを有していない点。
　
［相違点２］
　本願発明は、スケジュール対象オブジェクトが入出力するデータが「ファイル」のみならず、ファイル形式でないもの（「変換ワーク」）を含んでいるが、引用発明１では、基本的に、データの入出力はファイル形式で行っている点。
　
［相違点３について］
　本願発明では、各クラス部は、入力データ及びその入力データへの処理内容を定義するパラメータにより処理が定義されているのに対し、引用発明１では、各オブジェクトは、クラスにパラメータ（インスタンス値）を埋め込むことにより生成されるものであるが、当該パラメータが、入力データや処理内容を定義するものとまではいえない点。
　
３−４．判断
　上記相違点について、以下検討する。
　
［相違点１について］
　引用発明２のように、入力専用のオブジェクトによりファイルからの入力処理を行うこと、及び、出力専用のオブジェクトにより帳票への出力処理を行うことは周知である。また、引用発明２に限らず、入力処理と、変換処理と、出力処理を行うプログラムモジュールを独立して設けてなるプログラミングは、例えば、特開平６−１７５９０７号公報にも記載されているように、当業者にとって技術常識の一つである。
　よって、引用発明１において、スケジュール対象オブジェクトとして、入力専用のオブジェクト（クラス部）及び出力専用のオブジェクト（クラス部）を付加すること、並びに、入力データ保持部及び出力データ保持部を不可することは、当業者が容易に想到し得たものである。
　
［相違点２について］
　引用発明２にあるように、ファイル形式でないものを入出力対象とすることは周知である。また、入力又は出力をファイル形式とするかそうでない形式とするかは、目的に応じて当業者が適宜選択すべき事項にすぎない。
　よって、引用発明１において、スケジュール対象オブジェクトが入力又は出力するデータの形式をファイル形式とするか又はそうでない形式のデータとするかは、当業者が適宜選択できる事項であり、上記相違点１を克服した構成においても、変換処理の結果を「変換ワーク」すなわち、ファイル形式でないデータとすることに格別な困難性はない。
　
［相違点３について］
　実行されるプログラムであるオブジェクトのテンプレート（クラス）にデータを設定することにより入力データ及びその入力データに対する処理内容を設定してオブジェクトの挙動を形成することは、例えば、特開平９−１１４８９５号公報（特に、段落【００５８】〜【００６４】、図１７、図２１参照）、特開平８−２９２８８０号公報（特に、段落【００３０】〜【００４９】、図４〜図１４参照）に記載されているように周知技術にすぎない。
　よって、引用発明１において、各オブジェクトの入力データ及び処理内容を、インスタンス値（パラメータ）により定義するよう構成することに格別な困難性はない。
　また、上記相違点１を克服した構成においても、入力クラス部、変換クラス部、及び、出力クラス部のそれぞれにおいて、その入力データ及び処理内容を、インスタンス値（パラメータ）により定義できるようにすることに技術的な阻害要因はない。
　
　そして、本願発明の作用効果も、引用発明及び周知技術から当業者が容易に予測できる範囲内のものである。
　
３−５．請求人の主張
　請求人は、上記意見書において、主として以下の点を相違点として主張している。
　
［主張１］
　本願発明に係る情報処理装置においては、バッチ情報インスタンス保持部に入力クラス部、変換クラス部、及び出力クラス部の処理の流れを定義するスケジュールのパラメータが記憶され、そのスケジュールのパラメータに情報処理装置の全体の処理内容（シナリオ）が定義されて、そのシナリオ通りにバッチコントロールクラス部が各クラス部を起動するようしたものであります。このようにすることで、作成若しくは生成したプログラムの変更を容易に行うことができるため、再利用性が高く、保守性の高いシステムを提供することができるのであります（段落番号００６４）。
　
［主張２］
　本願発明に係る情報処理装置において、入力クラス部、変換クラス部、及び出力クラス部がパラメータにて定義された入力データで関係がなされておりますが、引用文献１にはその点の記載が全くありません。ここで、審判官殿は、インスタンス値を入力データ及び処理内容を定義するパラメータとする事も当業者が当然想到する範囲のものであると認定なされましたが、出願当時の技術水準から見て、必ずしもその認定は正しいとは言えず、また、請求項３のように、ウィザードを用いてユーザに入力させ、その入力からパラメータをインスタンス値としてクラスに埋め込むことで処理内容を定義させる点については所謂当業者と言えども本願発明に係る情報処理装置を想到するのは非常に困難であると考えます。
　
［主張３］
引用文献２は、複数のプログラム部品を組合せ、計算機によって自動的に応用プログラムを合成する方法において、複数のプログラム部品を任意に組み合わせてプログラムを合成することを可能とするものであります。この先行技術文献２では、データ入出力オブジェクト及びデータ処理オブジェクトが開示されておりますが、これらデータ入出力オブジェクト及びデータ処理オブジェクトを合成するための技術であり、これらのオブジェクトは、結局一つのプログラムになりますので、本願発明に係る情報処理のようなパッシングが起こり得ません。
　
　以下、上記各主張について検討する。
　［主張１について］
　請求項１には、「入力クラス部、変換クラス部、及び出力クラス部の処理の流れを定義するスケジュールのパラメータ」、及び、「前記各クラス部からの終了メッセージを受信した場合には、前記スケジュールのパラメータに基づいて次のクラス部をスケジュールする」としか記載がないから、本願発明において、「スケジュールのパラメータ」は、「次のクラス部」をスケジュールできるだけの情報があれば十分である。よって、スケジュールのパラメータに「情報処理装置全体の処理内容（シナリオ）」が定義されている、という請求人の主張は、請求項１の記載に基づいたものではない。
　また、引用文献１の図５において、「オブジェクト出力テーブル関連マスタ」には、オブジェクトが出力するテーブル名が定義されており、引用発明１では、処理が終了したオブジェクトが出力するテーブル名に基づいて後続のオブジェクトが決定されるから、「オブジェクト出力テーブル関連マスタ」には、実質的に、全体の処理内容が定義されていると言える。（例えば、図５において、テーブル名「Ｔａｂｌ１」により「Ｏｂｊｅｃｔ２１」が起動され、当該「Ｏｂｊｅｃｔ２１」が出力するテーブル名は「Ｔａｂ２０」であり、該「Ｔａｂ２０」により起動されるオブジェクトは「Ｏｂｊｅｃｔ２３」であるとわかる。）
　よって、仮に、本願発明の「スケジュールのパラメータ」が、請求人が主張するように「全体の処理内容」が定義されたものだとしても、この点において、引用発明１の「起動オブジェクト関連マスタ」及び「オブジェクト出力テーブル関連マスタ」において定義された情報と何ら差異はない。
　よって、主張１は採用しない。
　
［主張２について］
　請求人は、本願発明では、「入力クラス部、変換クラス部、及び出力クラス部がパラメータにて定義された入力データで関係がなされており」と主張する。しかしながら、この点は、請求項１には記載がない。請求項１には「入力するデータ及びそのデータへの入力処理（変換処理又は出力処理）内容を定義するパラメータ」などと記載されているだけであり、各クラス部が、「入力データ」で「関係」がなされているということは、請求項１の記載から把握することはできない。
　また、請求人は、「インスタンス値」を「パラメータ」とすることが、当業者が当然想到する範囲のものではないと主張する。しかしながら、本願発明において、「パラメータ」がどのようなデータ又は情報であるのか何ら特定されていないから、本願発明において、「パラメータ」は、単なる値（データ）と何ら差異はなく、よって、例えば前記［相違点３について］で挙げた周知技術と何ら差異はない。
　さらに、請求人は、ウィザードを用いてユーザに入力させ、その入力からパラメータをインスタンス値としてクラスに埋め込むことで処理内容を定義させる点は容易に想到できたものではないとも主張している。しかしながら、「ウィザード」に関する構成は、本願発明の発明特定事項でない。また、ビジュアルな設定画面を通じてパラメータを設定することは、前記［相違点３について］で挙げた周知技術からしても容易である。
　よって、主張２は採用しない。
　
［主張３について］
　引用文献２から抽出したものは、オブジェクト指向プログラミングにおいて、データ入力オブジェクト、データ処理（変換）オブジェクト、及び、データ出力オブジェクトを用いて一連の処理を実現するというプログラムの処理内容に係る技術思想であって、これらのオブジェクトを合成して一つのプログラムとして実行するというプログラム生成に係る技術思想ではない。また、引用発明１は、メッセージパッシングをベースとしたオブジェクト指向システムであり、引用発明２が、オブジェクト指向プログラミング技術に関するものである点で引用発明１と共通しているから、引用発明１に、引用発明２に記載した技術思想を適用することは当業者が容易に想到し得たものであって、引用発明２のものが、複数のオブジェクトを合成して実行するという前提があるからといって、引用発明１に適用する際に技術的な阻害要因が発生するとはいえない。
　よって、主張３は採用しない。
　
　したがって、請求人の各主張は採用しない。
　
３−５．小括
　上述のとおり、本願発明は、引用発明１及び２並びに周知技術に基いて当業者が容易に発明することができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　
４．特許法第３６条についての検討
４−１．当審拒絶理由
　当審拒絶理由の理由Ｄ−１．（３）及び（４）は、次のとおりである。
「（３）請求項１乃至４及び７乃至９に係る発明は、入力クラス部、変換クラス部、及び、出力クラス部を任意の順番でスケジューリングする態様を含んでいるが、発明の詳細な説明（特に、段落【００２５】を参照）には、入力クラス、変換クラス、出力クラスの順でスケジューリングする態様しか記載がない。
　また、発明の詳細な説明には、「スケジュールのパラメータ」がどのようなデータであるのか具体的に記載されていないから、入力クラス、変換クラス及び出力クラスを任意の順番でスケジューリングすることを、どのように実現しているのか不明である。
　よって、この点において、請求項１乃至４及び７乃至９に係る発明は、発明の詳細な説明に記載した技術的な範囲を超えて記載したものであり、逆に、発明の詳細な説明は、請求項１乃至４及び７乃至９に係る発明を、当業者が実施できる程度に十分かつ明確に記載していない。
（４）上記（３）にも関係するが、「バッチ情報インスタンス保持部」に保持される「スケジュールのパラメータ」とは具体的にはどのようなデータであるのか不明であるが、請求項５及び６に係る発明並びに明細書の段落【００２５】の記載によると、クラスのスケジュールは、入力クラス、変換クラス、及び、出力クラスの順で行われることが明らかであるのに、わざわざ、「バッチコントロールクラス」とは別に、「バッチ情報インスタンス保持部」に「スケジュールのパラメータ」を保持しておかなければならない技術的な根拠が不明である。」
　
４−２．判断
　上記当審拒絶理由が解消したか否かについて検討する。
　請求人は、上記意見書において、次のとおり述べている。
　
「Ｄ−１（３）について請求項１乃至４及び７乃至９に係る発明は入力クラス部、変換クラス部、及び、出力クラス部を任意の順番でスケジューリングする態様を含んでいるが、発明の詳細な説明（特に段落番号００２５）には、入力クラス、変換クラス、出力クラスの順でスケジューリングする態様しか記載がない。従って、これら請求項は発明の詳細な説明に記載した技術的な範囲を超えて記載したものである旨をご認定なされました。また、Ｄ−１（４）において、「バッチ情報インスタンス保持部」にスケジュールのパラメータを保持する技術的な根拠が不明である旨のご認定をなされました。
　そこで、出願人は、特許請求の範囲を精査し補正を行い、入力クラス部の出力は入力ファイルとし、変換クラス部は入力ファイルを入力して変換するようにしました。そして変換クラス部は変換ワークを出力し、その変換ワークを出力クラスが入力するようにしました。このようにして、事実上、入力クラス、変換クラス、そして出力クラスの順でスケジュールがなされるようにいたしました。また、これらクラスでの処理は１回若しくは複数回繰り返すことによりデータの処理を施します（段落番号００２９）。この場合には、複数回実行する必要があることからも実行を行うタイミングを管理する必要があります、そこで、バッチ情報インスタンス保持部によりスケジュールのパラメータを保持するようにしたのであります。」
　
　当該主張によると、「バッチコントロールクラス部」は、「入力クラス」、「変換クラス」、「出力クラス」の順番ではなく、タイミングを管理するものである。
　しかしながら、発明の詳細な説明には、タイミングを管理するための「スケジュールのパラメータ」がどのような情報であるのか全く記載されていない。また、請求項１の記載からも明らかなように、本願発明は、終了メッセージの受信により次のクラス部をスケジュールしているから、わざわざタイミングをパラメータにより定義する必要はないから、技術常識を参酌したとしても、タイミングを管理するための「スケジュールのパラメータ」がどのような情報であるのかを具体的に想定することができない。
　請求人が参照している段落【００２９】には、「ここで、主なメソッドは大きく分けて、変換メソッド、チェックメソッド、サービスメソッドがあり、それぞれのメソッドを１回若しくは複数回繰り返すことにより、データの処理を施す。処理が終了したデータは変換ワークとして出力される。」と記載されているが、メソッドを複数回繰り返す際に、「スケジュールのパラメータ」がどのように用いられているのか全く記載されてない。請求項１の記載からも明らかのように、本願発明において、「バッチコントロールクラス部」から各「クラス部」に送信されているメッセージは、「開始メッセージ」と「終了メッセージ」のみであり、メソッドを複数回繰り返すためのメッセージは存在しないから、技術常識を参酌したとしても、段落【００２９】の記載から、「バッチコントロールクラス部」が、「スケジュールのパラメータ」に基づいて、メソッドを複数回繰り返すためのメッセージを送信しているということを導き出すことはできず、かつ、そのための「スケジュールのパラメータ」がどのような情報であるのかを具体的に想定することもできない。
　よって、発明の詳細な説明及び図面には、「「バッチ情報インスタンス保持部」に保持される「スケジュールのパラメータ」がどのような情報であるのか依然として不明確である。
　
４−３．小括
　上述のとおり、本願明細書及び図面の記載は、本願発明を当業者が実施できる程度に明確かつ十分に記載していないから、本願は、特許法第３６条第４項に規定する要件を満たしていないので特許を受けることができない。
　
５．むすび
　したがって、本願は、特許法第２９条第２項及び特許法第３６条第４項の規定により特許を受けることができない。
　よって、結論のとおり審決する。