【事件の表示】
　平成　５年特許願第２８６４４４号「ネットワークインターフェース装置、マルチタスク処理装置及び対話型ネットワーク基板並びにマルチプログラム処理方法」拒絶査定不服審判事件〔平成　６年　８月　５日出願公開、特開平　６−２１４８１０〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯と本願発明 
　本願は、平成５年１１月１６日（パリ条約による優先権主張１９９２年１１月１８日、米国）の出願であって、平成１６年７月７日付けで拒絶理由通知がなされ、同年９月１０日付けで手続補正がなされたが、同年９月３０日付けで拒絶査定がなされ、これに対し、同年１１月４日に審判請求がなされたものである。
　そして、その請求項１１に係る発明（以下「本願発明」という。）は、平成１６年９月１０日付け手続補正書により補正された特許請求の範囲の請求項１１に記載された次のとおりのものと認める。
　
　「周辺機器とネットワークとを接続し、独立に実行可能な第１プログラムと第２プログラムとを実行するネットワークインターフェース装置におけるマルチプログラム処理方法であって、
　前記第１プログラムが所定のコマンドに達するまで、当該第１プログラムを実行し、前記第１プログラムが制御を放棄するのに応じて、第３プログラムを実行して当該第３プログラムに当該第１プログラムの実行状態を示す情報をメモリに格納させ、前記第２プログラムの実行を開始する実行ステップを有することを特徴とするマルチプログラム処理方法。」
　
２．引用文献
Ａ．原査定の拒絶の理由に引用された、「西田明宏，外１名，”周辺機器インターフェースとしてのネットワーク”，情報処理学会研究報告，第９１巻，第５４号，第１−８頁，社団法人情報処理学会，１９９１年７月５日」（以下、「引用文献１」という。）には、図面とともに以下の事項が記載されている。
　
（ア）「本論文では，周辺機器とのインターフェースとしてネットワークを採用した周辺機器の事例を紹介し，その利点について論じる。」（２頁左欄１３行目〜１５行目。）
　
（イ）「我々は，インターフェースとしてＥｔｈｅｒｎｅｔを用い，ＴＣＰ／ＩＰプロトコルを利用してデータの送受信を行なう周辺機器を開発し，発表している。ここでは，ネットワークを周辺機器インターフェースとしてみた場合の特微を示し，周辺機器をネットワータ直結型にすることのメリットについて述べる。」（４頁左欄６行目〜１２行目。）
　
（ウ）「ネットワークからの処理要求は非同期に発生する。これらの処理要求は，できるだけ周辺機器内でスプーリングし，ホストを待たせないことが望ましい。そのためには，周辺機器のコントローラに以下の機能が必要である。
　・スプーリングを行なうための２次記憶
　・マルチタスク可能なコントローラ」（５頁右欄１９行目〜２５行目。）
　
（エ）「本節では，リコーで開発・発表しているネットワーク直結型周辺機器の例をあげ，その特徴について述べる。
　・・・（中略）・・・
５．２　メッセージゲートウェイ
　・・・（中略）・・・
　本システムはネットワークに直結可能なＧ３／Ｇ４ファックスアダプタであり，１ｐｒコマンドを利用して計算機上から特定の相手にファックスを送ることができる。さらにリコーのファクシミリに搭載されている独自モードを利用することにより，受信したファックスのメールによる受信通知を可能としたシステムである。
　・・・（中略）・・・
５．３　ネットワークジュークボックス
　本システムは片面２５０ＭＢ，両面５００ＭＢの光磁気ディスクを最大５６枚収納可能なＭＯジュークボックスにコントローラをつけ，ネットワークに直結して利用できるようにしたものである。
　・・・（中略）・・・　コントローラ上に搭載するアプリケーションを検討している。このアプリケーションの候補としては
・２８ＧＢの巨大な一つのディスクとして扱うことのできるＮＦＳサーバ
・ＦＴＰプロトコルを実装した大容量ＦＴＰサーバ
・ファイル単位でデータの格納を行なうファイルサーバ
などを考えている。」（６頁左欄７行目〜７頁左欄１０行目。）
　
　ここで、（ア）〜（ウ）の記載からすると、引用文献１には、周辺機器とネットワークとを接続し、処理を実行する周辺機器のコントローラにおけるマルチタスク処理方法が記載されている。
　そして、（エ）における記載「１ｐｒコマンドを利用して計算機上から特定の相手にファックスを送ることができる。」及び「リコーのファクシミリに搭載されている独自モードを利用することにより，受信したファックスのメールによる受信通知を可能」と記載されていることからすると、引用文献１記載の周辺機器のコントローラにおいては、複数のプログラム（上記の例では、ファックスを送信するプログラムと受信したファックスのメールによる受信通知を行うプログラム）を独立に実行可能としていると解される。
　してみると、引用文献１記載の発明においては、少なくとも２つのプログラム（以下、簡単のため、２つのプログラムをそれぞれ「第１のプログラム」及び「第２のプログラム」と言う。）が独立に実行可能であると解され、このような複数のプログラム（すなわち、タスク）を実行させていると解される。
　
　以上から、引用文献１には、次の発明（以下、「引用発明」という。）が記載されているものと認められる。
　
　周辺機器とネットワークとを接続し、独立に実行可能な第１のプログラムと第２のプログラムとを実行する周辺機器のコントローラにおけるマルチタスク処理方法。
　
３．対比
　ここで、本願発明と引用発明とを比較すると、引用発明の「第１のプログラム」、「第２のプログラム」、「周辺機器のコントローラ」及び「マルチタスク処理方法」は、それぞれ本願発明の「第１プログラム」、「第２プログラム」、「ネットワークインターフェース装置」及び「マルチプログラム処理方法」に相当する。
　よって、本願発明と引用発明とは、以下の点で一致し、また、相違している。
　
（一致点）
　周辺機器とネットワークとを接続し、独立に実行可能な第１プログラムと第２プログラムとを実行するネットワークインタフェース装置におけるマルチプログラム処理方法。
　
（相違点）
　本願発明の「マルチプログラム処理方法」は、「第１プログラムが所定のコマンドに達するまで、当該第１プログラムを実行」し、「前記第１プログラムが制御を放棄するのに応じて、第３プログラムを実行して当該第３プログラムに当該第１プログラムの実行状態を示す情報をメモリに格納させ」、「第２プログラムの実行を開始する」実行ステップを有するものであるのに対して、
　引用発明の「マルチタスク処理方法」（「マルチプログラム処理方法」に対応）は、第１のプログラムが所定のコマンドに達するまで、当該第１のプログラムを実行し、前記第１のプログラムが制御を放棄するのに応じて、第３のプログラムを実行して当該第３のプログラムに当該第１のプログラムの実行状態を示す情報をメモリに格納させ、第２のプログラムの実行を開始する実行ステップを有するかどうか、明らかでない点。
　
　そこで前記相違点について検討する。
　本願の優先権主張日前である、１９９１年３月１日に頒布された「クレイグ・バートン，”プロテクションとプリエンプション”，インターフェース，第１７巻，第３号，第１５９−１６１頁，ＣＱ出版株式会社，１９９１年３月１日」に
　「ノンプリエンプティブなモードでは，スケジューラによって優先キュー中の先頭のタスクが実行するのを許されている．スケジューラはタスクが“放棄”のコールを発行するまでプロセッサを使い続けることを認めている．“放棄”のコールが発行されると，つぎのタスクが実行できるようになる．いったんプロセッサを手放すと，タスクは待ち行列に戻りつぎの順番がくるまで待つことになる．」（１５９頁右欄６行目〜１４行目。）と記載されているように、
　ノンプリエンプティブなマルチタスク処理方法は、実行中の第１のタスクが“放棄”のコール（「所定のコマンド」に対応）に達するまで、当該タスクを実行し、前記タスクが制御を放棄するのに応じて、スケジューラ（「第３プログラム」に対応）を実行して、つぎの第２のタスクの実行を開始する実行ステップを有することは、当業者にとって周知の事項であること、
　そして、本願の優先権主張日前である、昭和６３年３月１１日に頒布された特開昭６３−５６７３７号公報に
「従来、複数のタスクを円滑に同時に実行（以下、マルチタスク処理）させるために、リアルタイムＯＳは管理ソフトウェアとして必要不可欠なものとなっており、タスク管理、タスク間同期・通信機能、割込管理等の機能が、マルチタスク処理装置上のリアルタイムＯＳには必要となっている。リアルタイムＯＳは、タスクが前述の機能の実現をリアルタイムＯＳに対して要求するための手段（以下、システムコールと呼ぶ）を提供し、１つのシステムコール処理は第６図のようにタスク退避処理、内部処理、ディスパッチ処理に大きく分けることができ、タスク退避処理部では、システムコール処理のためにリアルタイムＯＳがレジスタ類を使用するため、システムコールを発行したタスクのその時点でのレジスタ情報等のタスクの実行環境（以下、コンテキストと呼ぶ）をタスク固有の領域タスク・コントロール・ブロック（以下、ＴＣＢ）に退避し、内部処理ではシステムコ−ルの目的とする機能を実現する処理を行ない、ディスパッチ処理部では、実行可能状態のタスクの内で最高の優先項位を持つ次に実行すべきタスクを選択し、選択したタスクのＴＣＢに退避されている中断した時点のコンテキストをレジスタ等に復帰してリアルタイムＯＳからタスクへ制御を移すという形で行なわれていた。」（１頁右下欄３行目〜２頁左上欄７行目。）と記載されているように、
　実行中の第１のタスクがシステムコール（「所定のコマンド」に対応）に達するまで当該タスクを実行し、前記タスクが制御を放棄するのに応じて、管理ソフトウェア（「第３プログラム」に対応）を実行して次に実行すべきタスクの実行を開始する方式（すなわち、ノンプリエンプティブ方式に相当）のマルチタスク処理方法が、前記管理ソフトウェアに前記実行中の第１のタスクの実行状態を示す情報をメモリに退避（すなわち格納）させ、次に実行すべき第２のタスクの実行を開始するステップを有することは、当業者にとって周知の常套手段であることを勘案すれば、
　引用発明の「マルチタスク処理方法」を、本願発明のように、「実行中の第１のタスク（すなわち、第１のプログラム）が“放棄”のコール（「所定のコマンド」に対応）に達するまで、当該タスクを実行し、前記タスクが制御を放棄するのに応じて、スケジューラ（「第３プログラム」に対応）を実行して当該スケジューラに前記タスクの実行状態を示す情報をメモリに格納させ、次の第２のタスク（すなわち第２のプログラム）の実行を開始する実行ステップを有する」ものとして構成することは、当業者であれば適宜なし得たことに過ぎない。
　よって、前記相違点は、格別のものではない。
　
　また、上記で検討したごとく、前記相違点は格別のものではなく、そして、本願発明の構成によってもたらされる効果も、当業者であれば当然に予測可能なものに過ぎず格別なものとは認められない。
　
５．結び
　以上のとおり、本願発明は、引用発明及び周知技術に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、上記結論のとおり、審決する。