【事件の表示】
　平成１０年特許願第１２８８０９号「コールバック関数呼び出し制御方法及びシステム」拒絶査定不服審判事件〔平成１１年１１月３０日出願公開、特開平１１−３２７８８５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続きの経緯・本願発明
　本願は、平成１０年５月１２日の出願であって、その請求項１に係る発明は、補正された明細書及び図面の記載からみて、次の事項により特定されるものと認める。（以下、「本願発明」という。）
「グラフィカルユーザインタフェース（ＧＵＩ）部品を格納し管理するＧＵＩ部品管理装置と、前記ＧＵＩを操作するためのコールバック関数を呼び出してイベント処理を行うイベント処理装置とを備えたコールバック関数呼び出し制御システムであって、
　前記ＧＵＩ部品管理装置に格納された前記ＧＵＩ部品は、前記ＧＵＩ部品が初期設定で持つ前記イベント処理に先立って実行される処理を記述した前処理用コールバック関数を記憶する前処理用コールバック関数記憶手段と、前記ＧＵＩ部品が初期設定で持つ前記イベント処理を実行した後に実行される処理を記述した後処理用コールバック関数を記憶する後処理用コールバック関数記憶手段とを備え、
　前記イベント処理装置は、前記前処理用コールバック関数記憶手段及び前記後処理用コールバック関数記憶手段にアクセスして前記イベント処理を行うものであって、前記前処理用コールバック関数を所定の入力に対して実行した場合、前記イベント処理の実行を中断させる旨を示すとき、前記イベント処理を中止することを特徴とするコールバック関数呼び出し制御システム。」
　なお、請求項１には「前記ＧＵＩ管理装置」との記載があるが、前記されているのは「ＧＵＩ管理装置」ではなく、「ＧＵＩ部品管理装置」であるため、この「前記ＧＵＩ管理装置」の記載は、「前記ＧＵＩ部品管理装置」の誤記と認め、上記のように認定した。
　
２．引用刊行物
　これに対して、当審が平成１８年１月２４日付で通知した拒絶の理由に引用した、本願出願日前に頒布された刊行物である、特開平５−２５７６６３号公報（以下「刊行物１」という。）には、次の事項が記載されている。 
 Ａ．「【０００４】 
 【発明が解決しようとする課題】上記従来技術は部品クラスの機能拡張や、新しいクラスの作成に関して配慮がされておらず、ユーザーインターフェース処理部の拡張が困難であるという問題点があった。 
 【０００５】本発明は部品クラスの機能拡張や新しい機能を持つ部品クラスの作成を容易にすることにより、拡張性の高いユーザーインターフェースを構築することを目的としている。」（【０００４】〜【０００５】段落） 
 Ｂ．「既定義のユーザーインターフェース部品のクラスを多重継承して新しいユーザーインタフェース部品のクラスを定義し、前記ユーザーインタフェース部品クラスをオブジェクト指向のクラスとして定義し、イベント送信処理をイベント送信総称関数の本体メソッドとして定義し、前記クラス毎に部品にイベントが与えられた場合に起動すべきイベント処理を周辺処理、前処理、後処理に分け、それぞれを当該クラスの周辺処理メソッド、前処理メソッド、後処理メソッドとして前記イベント送信総称関数に登録し、前記クラスのインスタンスを生成してユーザーインタフェース画面を構成するユーザーインタフェース構築方法。」（請求項３）
Ｃ．「【０００６】
【課題を解決するための手段】
上記目的を達成するための手段として、まずユーザーインタフェース部品のクラスを、オブジェクト指向のクラスとして実現する。また、イベント送信部103を総称関数で構成する。
【０００７】
【作用】
　上記手段を用いることにより、図１５に示すユーザーインタフェース構築処理が可能になる。まず、多重継承を用いて、新しい部品クラスを作成する(166)。
次にクラス毎のイベント処理メソッドをイベント送信総称関数に登録する(167)。次に部品クラスから部品インスタンスを生成し(168)、生成したインスタンスを組み合せて画面を構成する(169)。更に、インスタンス毎に、イベント処理を登録して(170)ユーザーインタフェースの構築が終了する。」（【０００６】〜【０００７】段落）
Ｄ．「【０００８】構築されたユーザーインタフェースがどのような処理を行うかについて、図１を用いて説明する。イベントが入力されると、イベント送信部108で送信先の部品のクラスに対応するイベント処理メソッド群を選び出し、それらをクラスの継承関係を反映した順序で実行する。メソッド群の中にイベント送信メソッド111が存在する場合は部品にイベントが送信され、部品内のイベント・処理対応関係に基づき部品毎イベント処理106が実行される。新しい機能を持つ部品クラスを作成する場合は、まず部品クラスを生成し、生成された部品クラスに対応するイベント処理メソッドをイベント送信部108に追加する。
【０００９】
【実施例】本発明の一実施例について図１を用いて説明する。本実施例はユーザーインターフェース処理プログラム101とそれを実行するオブジェクト指向言語処理プログラム114から構成される。
…（中略）…
【００１１】ユーザーインターフェース処理プログラム101において、イベント送信部108は総称関数で記述されており、実際に送信を行う部分を本体メソッド111とし、クラス毎のイベント処理のメソッドを周辺処理メソッド109、前処理メソッド110、後処理メソッド112として構成する。部品クラスの機能拡張や、新しい機能を持つ部品クラスを作成する場合には、このイベント送信部108に、追加する機能を実現するイベント処理メソッド113を追加する。」（【０００８】〜【００１１】段落から抜粋）
Ｅ．「【００１２】次に本実施例を用いた場合のユーザーインターフェース処理手順について図４を用いて説明する。
…（中略）…
【００１４】端末102に入力があると、イベントとしてユーザーインターフェース処理プログラムに取り込まれる(121)。イベント送信部では送信先の部品のクラスに適用可能なメソッド群を検索する(122)。検索したメソッド群をクラス階層を反映するように結合し、実行する(123)。123の処理は送信先の部品クラスに依存して動的に決定されるので、例を挙げて説明する。
【００１５】図５のようにクラスＣ125がクラスＡ126とクラスＢ127を継承しており、図のクラス定義128のようにＢの方がＡより優先されているとする．また、クラスＡ，Ｂ，Ｃの周辺処理、前処理、後処理メソッドがそれぞれ定義されているとすると、図４の処理123の部分の実行過程は、図６のようになる。図において右方向の矢線はサブルーチンコール、左方向の矢線はサブルーチンからの戻りを表す。図のように、クラスＡ→Ｂ→Ｃの順に周辺処理メソッド129,130,131が呼ばれ、次にＡ→Ｂ→Ｃと前処理メソッド132,133,134が実行され、次にイベント送信本体メソッド139により部品へイベントが送信される。部品側では従来どおりの処理として部品毎イベント処理135が行われる。実際にはイベント送信は関数呼び出しで行われるためサブルーチンコールの形で図に示してある。したがって部品側での部品毎イベント処理135が終了すると、イベント送信本体メソッド139に値が戻される。次にクラスＣ→Ｂ→Ａの後処理メソッド136,137,138が実行される。さらにC→Ｂ→Ａのと値が戻って各周辺処理131,130,129の残りの処理が実行される。【００１６】以上の様なメソッド結合に関する一般的ルールはCLOSの仕様により規定されている。 」（【００１２】〜【００１６】段落から抜粋） 
 Ｆ．図１には、オブジェクト指向言語処理プログラム114によってユーザインターフェース処理プログラム101が実行できるシステムが示されている。ユーザインターフェース処理プログラム101には、イベント取得部、前処理部110、本体部111、後処理部112、追加のユーザ定義のイベント処理部113を含むイベント処理部、本体部に接続された図形操作ウィンドウ入力処理部、ボタン入力処理部を含む部品毎イベント処理部106を備えるのが見て取れる。特に、部品毎イベント処理部106にはユーザ定義コールバックを追加できる様子が示されている。 
 　 
　刊行物１の図１に示されたユーザインターフェース処理プログラム101は、コンピュータにより実行されるものであるから、記憶手段や制御手段といったハードウェアがベースにあり、記憶手段に記憶されるプログラムやデータが、管理されることは自明の技術的事項である。
　図１の前処理や後処理は、Ｄ．の記載を参照すると前処理メソッドや後処理メソッドとして構成されている。
　図１の図形操作ウィンドウ入力処理やボタン入力処理などの部品毎イベント処理は、当該イベント処理を有する部品について、Ｃ．の記載を参照すると、部品クラスから部品インスタンスが生成される。このインスタンス生成で生成されたインスタンスは、初期設定されてインスタンスが生成されるのが通常であるから、前記部品のインスタンスがもつデフォルトのイベント処理は部品が初期設定でもつイベント処理にあたる。
　図形操作ウィンドウ入力処理などの部品毎イベント処理、さらには前処理、後処理は、イベントにより呼ばれるメソッド（関数）である。
　これらの点をふまえると、刊行物１には、部品クラスの機能拡張や新しい機能を持つ部品クラスの作成を容易にすることにより、拡張性の高いユーザーインターフェースを構築することを目的とし、図１に示された前記ユーザインターフェース処理プログラム101に示されたプログラムやデータが記憶手段に格納されて管理されるシステムであって、そのプログラムの実行や制御が、図４、図６に示されるとともに、Ｅ．に記載されたようなユーザインターフェース処理手順でなされる次のシステムの発明が記載されていると認められる。（以下、「刊行物１の発明」という。） 
「図形操作ウィンドウ入力処理やユーザ定義コールバックなどのユーザインターフェース部品（以下、「ＵＩ部品」と略す。）毎イベント処理を格納し管理するＵＩ部品毎イベント処理部（106）と、前記ＵＩ部品毎イベント処理を操作するための図形操作ウィンドウ入力処理やユーザ定義コールバックなどのＵＩ部品毎イベント処理を呼び出してイベント処理を行うイベント処理部とを備えたコールバック関数呼び出し制御システムであって、 
　前記ＵＩ部品毎イベント処理部は、前記図形操作ウィンドウ入力処理などのＵＩ部品が初期設定で持つ前記ＵＩ部品毎イベント処理を記述した処理メソッドを記憶する処理メソッド記憶手段を備え、
　前記イベント処理部（イベント送信部108）は、前記図形操作ウィンドウ入力処理などのＵＩ部品が初期設定で持つ前記ＵＩ部品毎イベント処理に先立って実行される処理を記述した前処理メソッドを記憶する前処理メソッド記憶手段と、前記図形操作ウィンドウ入力処理などのＵＩ部品が初期設定で持つ前記ＵＩ部品毎イベント処理を実行した後に実行される処理を記述した後処理メソッドを記憶する後処理メソッド記憶手段とを備え、前記前処理メソッド記憶手段及び前記後処理メソッド記憶手段にアクセスしてイベント処理を行うコールバック関数呼び出し制御システム。」 
　
　同じく、当審が前記拒絶の理由に引用した、本願出願日前に頒布された刊行物である、特開平９−１９０４５９号公報（以下「刊行物２」という。）には、次の事項が記載されている。 
 ａ．「【００９９】前処理ルーチン名入力フィールド１２４には、選択動作の前に起動されるルーチン名を入力する。このルーチンはある種の言語形式で記述され、別にテキストエディタを用いて作成される。 
 【０１００】この言語形式は、変数や構造文を持ち、エディタ内に生成された画面オブジェクトの種類、数、位置、大きさ、接続具合などを調べるためのルーチンを備えている。また、ダイヤログボックスを開いて利用者に値を入力させる機能も持つ。これらの機能を用いて、画面オブジェクトの選択時にまわりの条件により選択するオブジェクトの種類を制限したり、選択の方法を複数用意しそれを利用者に選ばせたりすることができる。後処理ルーチン１２５も同様である。 
 【０１０１】必要な属性や名称を入力した後に、終了ボタン１２６を押すと、今までの設定値が保存され、発電機が選択されるときのイベント動作としてイベント動作管理手段２１に蓄えられる。 
 【０１０２】この発電機オブジェクトの選択を実行する場合は、システムのモードを実行モードに戻す。画面上の発電機オブジェクトをピックすると、イベント認知手段１１がそれを捉えてイベント管理手段１２に伝える。 
 【０１０３】イベント管理手段１２は、イベント動作管理手段２１から先ほど蓄えた発電機オブジェクトの選択を行うイベント動作を取り出して実行する。このようにして、選択方法のカスタマイズを行える。」（【００９９】〜【０１０３】段落から抜粋） 
 ｂ．図１１〜図１２には、オブジェクト名称と前処理、後処理入力フィールドが示されている。 
　
３．対比 
　本願発明と刊行物１の発明とを対比する。
（１）刊行物１の発明の「ＵＩ部品」は、Ｂ．の記載を参照するとユーザーインタフェース画面の構成に用いられており、視覚的な部品と解することができるから、本願発明の「ＧＵＩ部品」に対応する。そして、刊行物１の発明の「ＵＩ部品毎イベント処理部」「イベント処理部」は、それぞれ、本願発明の「ＧＵＩ部品管理装置」「イベント処理装置」に対応させることができ、そうすると、刊行物１の発明の「図形操作ウィンドウ入力処理やユーザ定義コールバックなどのＵＩ部品毎イベント処理を格納し管理するＵＩ部品毎イベント処理部と、前記ＵＩ部品毎イベント処理を操作するための図形操作ウィンドウ入力処理やユーザ定義コールバックなどのＵＩ部品毎イベント処理を呼び出してイベント処理を行うイベント処理部とを備えたコールバック関数呼び出し制御システム」は、 
 　請求項１の発明の「グラフィカルユーザインタフェース（ＧＵＩ）部品を格納し管理するＧＵＩ部品管理装置と、前記ＧＵＩを操作するためのコールバック関数を呼び出してイベント処理を行うイベント処理装置とを備えたコールバック関数呼び出し制御システム」と実質的な差異はない。 
（２）刊行物１の発明の「ＵＩ部品毎イベント処理部は、前記図形操作ウィンドウ入力処理などのＵＩ部品が初期設定で持つ前記ＵＩ部品毎イベント処理を記述した処理メソッドを記憶する処理メソッド記憶手段を備え」は、該ＵＩ部品毎イベント処理を記述した処理メソッドはイベントにより呼び出される処理メソッドであるからコールバック関数と解され、また、該ＵＩ部品毎イベント処理部は、少なくとも図形操作ウィンドウ入力処理（イベント処理用コールバック関数）などを記憶する手段を備えており、一方、本願発明の「前処理用コールバック関数記憶手段」及び「後処理用コールバック関数記憶手段」は、上位概念では、コールバック関数記憶手段であるから、これらの点をふまえると、刊行物１の発明と本願発明とは「ＧＵＩ部品管理装置に格納された前記ＧＵＩ部品は、イベント処理用コールバック関数を記憶するイベント処理用コールバック関数記憶手段を備え」る点では共通している。
（３）刊行物１の発明の「前記イベント処理部は、前記図形操作ウィンドウ入力処理などのＵＩ部品が初期設定で持つ前記ＵＩ部品毎イベント処理に先立って実行される処理を記述した前処理メソッドを記憶する前処理メソッド記憶手段と、前記図形操作ウィンドウ入力処理などのＵＩ部品が初期設定で持つ前記ＵＩ部品毎イベント処理を実行した後に実行される処理を記述した後処理メソッドを記憶する後処理メソッド記憶手段とを備え、前記前処理メソッド記憶手段及び前記後処理メソッド記憶手段にアクセスしてイベント処理を行う」は、イベント処理部におけるものであって、部品毎イベント処理部におけるものではないが、上位概念ではシステム内におけるものであり、且つ、前処理メソッド及び後処理メソッドは、コールバック関数との明示はないものの、上位概念では関数であり、これらの点をふまえると、刊行物１の発明の前記事項は、本願発明の「前記ＧＵＩ部品が初期設定で持つ前記イベント処理に先立って実行される処理を記述した前処理用関数を記憶する前処理用関数記憶手段と、前記ＧＵＩ部品が初期設定で持つ前記イベント処理を実行した後に実行される処理を記述した後処理用関数を記憶する後処理用関数記憶手段とを備え」と共通している。
　また、刊行物１の発明の、「前記前処理メソッド記憶手段及び前記後処理メソッド記憶手段にアクセスしてイベント処理を行う」は、本願発明の「前記イベント処理装置は、前処理関数記憶手段及び後処理関数記憶手段にアクセスしてイベント処理を行う」と実質的な差異はない。 
　したがって、刊行物１の発明と、本願発明とは、次の構成を備えた発明である点で一致し、そして、本願発明が次の構成を備えた点で刊行物１の発明とは相違している。
　
〈一致点〉 
「グラフィカルユーザインタフェース（ＧＵＩ）部品を格納し管理するＧＵＩ部品管理装置と、前記ＧＵＩを操作するためのコールバック関数を呼び出してイベント処理を行うイベント処理装置とを備えたコールバック関数呼び出し制御システムであって、 
　前記ＧＵＩ部品管理装置に格納された前記ＧＵＩ部品は、イベント処理用コールバック関数を記憶するイベント処理用コールバック関数記憶手段を備え、
　システム内には、前記ＧＵＩ部品が初期設定で持つ前記イベント処理に先立って実行される処理を記述した前処理用関数を記憶する前処理用関数記憶手段と、前記ＧＵＩ部品が初期設定で持つ前記イベント処理を実行した後に実行される処理を記述した後処理用関数を記憶する後処理用関数記憶手段とを備え、
 前記イベント処理装置は、前記前処理関数記憶手段及び前記後処理関数記憶手段にアクセスしてイベント処理を行うことを特徴とするコールバック関数呼び出し制御システム」 
　
〈相違点１〉
　ＧＵＩ部品が初期設定で持つ前記イベント処理に先立って実行される処理を記述した前処理用関数を記憶する前処理用関数記憶手段と、前記ＧＵＩ部品が初期設定で持つ前記イベント処理を実行した後に実行される処理を記述した後処理用関数を記憶する後処理用関数記憶手段とを、本願発明では、ＧＵＩ部品管理装置に格納された前記ＧＵＩ部品が備えるとともに、前記関数がコールバック関数であるのに対し、刊行物１の発明は、システム内（イベント処理部）に備えるとともに、関数がコールバック関数であることは示されていない点。
〈相違点２〉
　イベント処理装置がアクセスするのが、本願発明では、ＧＵＩ部品管理装置に格納された前記ＧＵＩ部品が備えた前処理用コールバック関数記憶手段及び後処理用コールバック関数記憶手段であるのに対し、刊行物１の発明では、システム内（イベント処理部）が備えた前処理関数記憶手段及び後処理関数記憶手段である点。
〈相違点３〉
　前処理用関数の実行について、本願発明は、所定の入力に対して前処理用コールバック関数を実行し、所定の入力に対して実行した場合、イベント処理の実行を中断させる旨を示すとき、前記イベント処理を中止するものであるのに対し、刊行物１の発明は、前処理用コールバック関数を所定の入力に対して実行することや、イベント処理の実行を中断させる旨を示すときに、イベント処理を中止することは開示されていない点。
　
４．判断 
〈相違点１〉について
　刊行物１には、Ｄ．の記載を参照すると、ユーザーインターフェース処理プログラム101において、イベント送信部108は総称関数で記述されており、実際に送信を行う部分を本体メソッド111とし、クラス毎のイベント処理のメソッドを周辺処理メソッド109、前処理メソッド110、後処理メソッド112として構成すること、部品クラスの機能拡張や、新しい機能を持つ部品クラスを作成する場合には、このイベント送信部108に、追加する機能を実現するイベント処理メソッド113を追加する旨記載され、Ｅ．の記載を参照すると、端末102に入力があると、イベントとしてユーザーインターフェース処理プログラムに取り込まれ、イベント送信部では送信先の部品のクラスに適用可能なメソッド群を検索し、検索したメソッド群をクラス階層を反映するように結合し、送信先の部品クラスに依存して動的に決定されて123の処理は実行され、クラスの周辺処理、前処理、後処理メソッドがそれぞれ定義されているとすると、図４の処理123の部分の実行過程は、図６のようになる旨記載されている。また、実際にはイベント送信は関数呼び出しで行われるためサブルーチンコールの形で図に示してあり、部品側での部品毎イベント処理135が終了すると、イベント送信本体メソッド139に値が戻される旨記載されている。さらに、メソッド結合に関する一般的ルールはCLOSの仕様により規定されていると記載されている。
　特に、図１には、イベント処理部にユーザ定義のイベント処理(113）を追加する他に、部品毎イベント処理部（106）にユーザ定義コールバック関数を追加して格納する様子が示されており、これら追加されるユーザ定義のイベント処理(113）やユーザ定義コールバック関数は、いずれもユーザが任意に定義できるものであるため、前処理又は後処理の定義、記述であっても差し支えないと解され、部品毎イベント処理部（106）にユーザ定義コールバック関数として追加する場合には、イベントにより呼び出される仕組みによるが、これはコールバック関数に自明のことで本願出願前周知の技術（例えば、刊行物２【００９９】〜【０１０１】段落参照）と認められる。
　刊行物１の発明における、前処理、後処理をユーザ定義コールバックとすることに何ら阻害される理由はなく、当該前処理、後処理が部品毎イベント処理部の記憶手段に格納されるコールバック関数とすることは、前記部品毎イベント処理部（106）にユーザ定義コールバック関数を追加して格納する技術におけるユーザ定義からして格別なことではない。また、本願発明では、前処理用関数記憶手段と後処理用関数記憶手段とを、ＧＵＩ部品管理装置に格納されたＧＵＩ部品が備えるとしているが、刊行物１の発明において、個々のＧＵＩ部品毎にコールバック関数を記憶するイベント処理部の記憶手段の部分をまとめ、イベント処理部に格納されたＧＵＩ部品としてのまとまりの中に前処理用関数記憶手段、後処理用関数記憶手段を備えるよう管理するといったことは、当業者が必要に応じて適宜なし得る事項に過ぎない。
　したがって、刊行物１の発明において、ＧＵＩ部品が初期設定で持つ前記イベント処理に先立って実行される処理を記述した前処理用関数を記憶する前処理用関数記憶手段と、前記ＧＵＩ部品が初期設定で持つ前記イベント処理を実行した後に実行される処理を記述した後処理用関数を記憶する後処理用関数記憶手段とを、ＧＵＩ部品管理装置に格納された前記ＧＵＩ部品が備えるようにするとともに、当該格納された関数をコールバック関数とすることは、刊行物１の前記ユーザ定義コールバックの追加の技術及びイベントにより呼び出される前記周知のコールバック関数の技術を参酌することにより、当業者が容易になし得ることである。 
〈相違点２〉について
　〈相違点１〉で論じたように、前処理、後処理をユーザ定義コールバックとして、部品毎イベント処理部に格納されたＧＵＩ部品としてのまとまりの中の備えられた前処理用コールバック関数記憶手段及び前記後処理用コールバック関数記憶手段に格納した場合、イベント処理装置がアクセスするのが、ＧＵＩ部品が備えた前処理用コールバック関数記憶手段及び前記後処理用コールバック関数記憶手段であることはシステム設計から必然的な事項であって格別なことではない。
〈相違点３〉について
　前処理用関数をコールバック関数とすることが容易になし得ることであることについては、上記〈相違点１〉で論じたとおりである。
　また、例えば、酒井雄二郎他２名著「ＭＳ−ＤＯＳVer３．３ハンドブック」（株）ナツメ社（１９８８年１２月３０日）頁２１０〜２１１には、ＸＣＯＰＹコマンド、Ｃ言語のコンパイラ、ＭＡＳＭ、ＬＩＮＫなどの処理中にエラーが生じた場合は０以外のコードを、正常終了の場合には０コードを返すので、これをＥＲＲＯＲ　ＬＥＶＥＬで判定して、バッチ処理を中断させることができる旨記載されている。これによれば、何らかの処理において０以外のコードを返されたことで、バッチ処理が中断されるから、０以外のコードを返すことは、処理の実行を中断させる旨を示すものであるといえる。してみると、何らかの処理を実行した場合に、処理の実行を中断する旨を示すとき、以降の処理を中止することは、本願出願前周知のプログラムミング技術であると認められる。
　また、ＧＵＩのイベント処理において、「所定の入力」をイベントとすることは、例えば、刊行物１の上記Ｄ．内【００１４】段落にも見られるように、本願出願前周知の技術である。
　したがって、刊行物１の発明において、イベントとして所定の入力を取り上げ、該所定の入力に対して前処理用コールバック関数を実行し、所定の入力に対して実行した場合、イベント処理の実行を中断させる旨を示すとき、前記イベント処理を中止するものとなすことは、前記周知のプログラミング技術を参酌することにより当業者が容易になし得ることである。
  そして、本願発明によって得られる作用効果も、刊行物１の記載及び前記周知技術から当然予想される範囲内のものであり、格別顕著なものとは認められない。
　
５．請求項３に係る発明について
　併せて請求項３に係る発明についても検討する。
　
　本願請求項３に係る発明は、補正された明細書及び図面の記載からみて、特許請求の範囲の請求項３に記載された次の事項により特定されるものである。（以下、「本願第二発明」という。）
「グラフィカルユーザインタフェース（ＧＵＩ）部品を格納し管理するＧＵＩ部品管理装置と、イベント処理を行うイベント処理装置と、イベントを発生させるイベント発生装置とを用いるコールバック関数呼び出し制御方法であって、
　前記ＧＵＩ部品の操作により発生したイベントに対し、前記ＧＵＩ部品が初期設定で持つ前記イベント処理に先立って実行される処理を記述した前処理用コールバック関数を呼び出し、イベント処理を中断することを特徴とするコールバック関数呼び出し制御方法。」
　
５−１．引用刊行物
　当審が平成１８年１月２４日付で通知した拒絶の理由に引用した引用刊行物、およびその記載事項は、前記２．に記載したとおりである。
　
５−２．対比・判断
　本願第二発明は、本願発明における、「グラフィカルユーザインタフェース（ＧＵＩ）部品を格納し管理するＧＵＩ部品管理装置」、「イベント処理を行うイベント処理装置」の構成と、「前処理用コールバック関数を所定の入力に対して実行した場合、前記イベント処理の実行を中断させる旨を示すとき、前記イベント処理を中止する」という処理内容のみを取り上げ、さらに、前記「前処理用コールバック関数を所定の入力に対して実行した場合、前記イベント処理の実行を中断させる旨を示すとき、前記イベント処理を中止する」という処理内容について、「所定の入力」を「ＧＵＩ部品の操作により発生したイベント」に上位概念化し、さらに「イベント処理の実行を中断させる旨を示すとき」との条件設定を取り除いたものである。なお、本願第二発明では、本願発明に対し、「イベントを発生させるイベント発生装置」が構成として追加されているが、本願発明も発生したイベント処理を行う構成であるから、「イベントを発生させるイベント発生装置」の存在が当然前提となっていると解され、この点に本願第二発明と本願発明の実質的相違はない。
　してみると、本願第二発明の処理内容についての一部の限定を具体化するとともに、処理中断についての条件設定を付加し、さらにその他の構成を付加した本願発明が、前記３．に記載したとおり、刊行物１に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、本願第二発明も、同様の理由により、刊行物１に記載された発明及び周知技術に基づいて、当業者が容易に発明をすることができたものである。
　
６．むすび
　したがって、 本願請求項１，３に係る発明は、刊行物１に記載された発明及び前記周知技術に基いて、当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。