【事件の表示】
　特願２００２−２４４０００「画像形成装置」拒絶査定不服審判事件〔平成１５年　６月２７日出願公開、特開２００３−１７７９３１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯　
　本願は、平成１４年８月２３日（優先権主張平成１３年８月２７日）の出願であって、平成１７年８月１８日付けで拒絶の理由が通知され、同年１０月３１日付けで手続補正がなされたものの、平成１８年４月２０日付けで拒絶の査定がなされた。その後、平成１８年５月２５日に拒絶査定不服審判請求がなされ、同年６月２６日付けで手続補正がなされたものである
　
　
２．平成１８年６月２６日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成１８年６月２６日付けの手続補正を却下する。
　
［理　由］
（１）補正後の本願の発明
　上記平成１８年６月２６日付けの手続補正（以下、「本件補正」という。）により、特許請求の範囲の請求項１は、
「【請求項１】　画像形成処理で使用されるハードウェア資源と、画像形成に係るユーザサービスおよびコントロールサービスの処理を行う一または複数のプログラムとを有する画像形成装置であって、
　前記ユーザサービスおよびコントロールサービスのそれぞれは、サーバプロセスまたはクライアントプロセスとして動作する一または複数のスレッドを含むプロセスであり、
　前記サーバプロセスのスレッドは、前記クライアントプロセスのスレッドに提供する一または複数のサービスを定義した関数を有しており、
　前記クライアントプロセスのスレッドは、前記サーバプロセスのスレッドにサービスの提供を要求する際に関数呼び出しを行うことを特徴とする画像形成装置。」
　
から、
　
「【請求項１】　プリンタ部またはスキャナ部の少なくとも一方を含む画像処理ハードウェア資源と、画像形成に係るユーザサービスおよびコントロールサービスの処理を行う一または複数のプログラムとを有する画像形成装置であって、
　前記ユーザサービスおよびコントロールサービスのそれぞれは、サーバプロセスまたはクライアントプロセスとして動作する一または複数のスレッドを含むプロセスであり、
　前記サーバプロセスのスレッドは、前記クライアントプロセスのスレッドに提供する一または複数のサービスを定義した関数を有しており、
　前記クライアントプロセスのスレッドは通信の動作主体であり、前記サーバプロセスのスレッドに対して個別にクライアントとしてサービスの提供を要求する際に関数呼び出しを行うことを特徴とする画像形成装置。」
と補正された。
　
　上記請求項１についての補正は、発明を特定する事項である「画像形成処理で使用されるハードウェア資源」を「プリンタ部またはスキャナ部の少なくとも一方を含む画像処理ハードウェア資源」に限定し、「クライアントプロセスのスレッド」が「通信の動作主体」として「サーバプロセスのスレッドに対して個別にクライアントとして」動作するものであることを限定するものであり、特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的とするものに該当する。また、上記補正は、出願当初の明細書に記載された事項の範囲内でなされており、特許法第１７条の２第３項の規定する要件を満たすものである。
　そこで、本件補正後の前記請求項１に係る発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（平成１８年改正前特許法第１７条の２第５項の規定において準用する特許法第１２６条第５項の規定に適合するか否か）について以下に検討する。
　
　
（２）引用例
　原査定の拒絶の理由に引用された特開平８−１１５２２４号公報（以下、「引用文献１」という。）には、図面と共に以下の事項が記載されている。（注：下線は当審にて便宜上付与したもの。）
　
（ア）「【０００６】この発明は、このような背景の下になされたもので、業務タスクの数が多い場合など全てのタスクの起動に時間がかかる場合においても、処理可能なタスクからジョブの処理実行を進めることができ、
装置全体を速やかに起動することができる画像処理装置
システムの拡張に対して容易に対応可能
　
（イ）「【００１１】
【実施例】以下、図面を参照して、この発明の実施例について説明する。
（１）ハードウェア構成
図１はこの発明の一実施例のハードウェア構成を示すブロック図である。図１において、１は本発明を適用した印刷装置であり、ＣＰＵ１ａ、ＲＡＭ１ｂ、ＲＯＭ１ｃ、ハードディスク１ｄ、パラレルインタフェース１ｅ、ネットワークインタフェース１ｆ、ＩＣカードインタフェース１ｇ、ディスクインタフェース１ｈ、図示しない
印刷処理部およびファクシミリ送信部か
　
（ウ）「【００１５】（２）ソフトウェア構成
次に、図２は本実施例のソフトウェア構成を示す概念図である。図２において、オペレーティング・システム（以下、ＯＳという）１０は、その核をなすカーネル１１とデバイスドライバ１２ａ〜１２ｃ、ＯＳ１０上で動作する業務タスク（後述する）とカーネル１１とのインタフェースであるシステムコール１３、および
業務タスクが使用する関数パッケージであるライブラリ１４から構成されている。
【００１６】ＯＳ１０上で動作する個々の業務タスクには、この
印刷装置１が実装するデバイスの機能を基本的な要素に分解した基本機能が割り当てられ
　
（エ）「【００２１】これら業務タスク１５ａ〜１５ｉは上述した機能によって以下のように分類される。
丸１（以下、丸付き数字を便宜上表すものとする。）  ホストであるワークステーションからのデータ受信および要求に対する応答を行う入力タスク群（ＬＡＮ受信タスク１５ｂ、拡張ＬＡＮ受信タスク１５ｃおよびパラレル受信タスク１５ｄが含まれる。）
丸２  印刷処理部、ファクシミリ送信部等にデータの出力を行う出力タスク群（印刷部管理タスク１５ｆが含まれる。）
丸３  印刷ジョブの解析やビットマップデータへの変換を行うデータ処理タスク群（ジョブ解析／展開タスク１５ｅが含まれる。）
丸４  各業務タスクの調停、ジョブの実行処理過程の管理を行う管理タスク群（プロトコル振分タスク１５ａ、業務タスク管理タスク１５ｇおよびジョブ管理タスク１５ｈが含まれる。）
【００２２】また、上述した業務タスク１５ａ〜１５ｉは、メッセージ駆動型プログラミング方式によって各々のプログラムが記述されている。ここで、メッセージ駆動型プログラミングとは、一般にあるタスクが他のタスクからのメッセージに応じた処理を行うようにプログラミングする方式をいう。
【００２３】（３）タスク間通信の方法
次に、本実施例の業務タスクの間で行われるタスク間通信の方法について説明する。各業務タスクは、互いに協調して動作するために、タスク間通信の一形態であるメッセージ交換を行う。タスク間のメッセージ交換は、ＯＳ１０が提供するライブラリの１つであるメッセージキューライブラリを使用して行う。
【００２４】ここで、図３は、ある２つの業務タスクＡ，Ｂ間でメッセージ交換を行うための処理内容をＣ言語のプログラムコードによって記述した例を示している。同図において、メッセージキューは名前ｎａｍｅで識別され、ＯＳ１０のタスク空間において一意に決定される。ここで、ＯＳ１０のタスク空間とは、ＯＳ１０上で動作するアプリケーションが存在するメモリ空間を抽象的に表現したものである。
【００２５】まず、メッセージキューを利用する業務タスクＡ，Ｂは、
メッセージキューライブラリの関数ｏｐｅｎ＿ｍｅｓｓａｇｅ＿ｑｕｅｕｅ（）
【００２６】一方、メッセージ受信側の業務タスクＢは、関数ｒｅｃｅｉｖｅ＿ｍｅｓｓａｇｅ（）を発行することにより、識別子ｑｄで指定されるメッセージキューの内容をポインタｍｓｇで指定されるメッセージ格納用のバッファへ転送する。これにより、メッセージ受信が行われる。こうしてメッセージ交換が終了すると、業務タスクＡ，Ｂの双方で、
関数ｃｌｏｓｅ＿ｍｅｓｓ
　
　ここで、業務タスクが使用する関数パッケージとは、（エ）の記載にあるように業務タスクのプログラムに対して、機能サービスを提供するものであるから、サービスの要求元とサービスの提供元との関係としてみると、業務タスク、関数パッケージであるライブラリのプログラムはそれぞれ、クライアント、サーバとみなす事ができるものである。
　そして、（エ）の「業務タスク１５ａ〜１５ｉは、メッセージ駆動型プログラミング方式によって各々のプログラムが記述されている。ここで、メッセージ駆動型プログラミングとは、一般にあるタスクが他のタスクからのメッセージに応じた処理を行うようにプログラミングする方式をいう。」、「メッセージキューを利用する業務タスクＡ，Ｂは、
メッセージキューライブラリの関数ｏｐｅｎ＿ｍｅｓｓａｇｅ＿ｑｕｅｕｅ（）
　よって、（ア）〜（エ）、の記載および図面から引用文献１には、次の発明が記載されている。（以下、引用発明１という。）
　
　印刷処理部およびファクシミリ送信部を含む画像処理ハードウェア資源と、印刷装置が実装するデバイスの機能を基本的な要素に分解した基本機能が割り当てられた業務タスクおよび該業務タスクが使用する関数パッケージであるライブラリとを有する画像処理装置において、
　前記業務タスクおよび関数パッケージであるライブラリのそれぞれは、サーバまたはクライアントとして動作するプログラムであり、
　前記関数パッケージであるライブラリは、クライアントに提供する１または複数のサービスを定義した関数を有しており、
　前記業務タスクは、通信の動作主体であり、前記サーバとして動作する関数パッケージであるライブラリに対して個別にクライアントとしてサービスの提供を要求する際に関数呼び出しを行うことを特徴とする画像処理装置。
　
　
（３）対比
　そこで、本願補正発明と引用発明１とを対比すると、
　本願補正発明における、ユーザサービス、コントロールサービスとは、明細書において「【０００８】なお、ユーザサービスとはユーザに提供する画像形成に係るサービスをいう。また、コントロールサービスとはアプリケーションに画像形成に係るハードウェア資源を提供するサービスをいう。」と定義されており、
　引用発明１の業務タスクは、図２およびその説明である上記（ウ）の「ＯＳ１０上で動作する個々の業務タスクには、この
印刷装置１が実装するデバイスの機能を基本的な要素に分解した基本機能
業務タスクが使用する関数パッケージであるライブラリ１４から構成されている。
　
　したがって、引用発明１における「印刷処理部およびファクシミリ送信部を含む画像処理ハードウェア資源」、「印刷装置が実装するデバイスの機能を基本的な要素に分解した基本機能が割り当てられた業務タスク」、「業務タスクが使用する関数パッケージであるライブラリ」、「画像処理装置」は、それぞれ、本願補正発明における「プリンタ部またはスキャナ部の少なくとも一方を含む画像処理ハードウェア資源」、「画像形成に係るユーザサービスの処理を行う一または複数のプログラム」、「コントロールサービスの処理を行う一または複数のプログラム」、「画像形成装置」に相当する。
　そして、引用発明１における「業務タスク」および「関数パッケージであるライブラリ」のそれぞれは、本願補正発明の「ユーザサービス」および「コントロールサービス」とは、サーバまたはクライアントとして動作するプログラムである点で共通し、
　引用発明１における「関数パッケージであるライブラリ」と本願補正発明の「サーバプロセスのスレッド」とは、サーバとして動作するプログラムであり、クライアントに提供する１または複数のサービスを定義した関数を有している点で共通し、
　引用発明１における「業務タスク」と、本願補正発明の「クライアントプロセスのスレッド」とは、クライアントとして動作するプログラムであって、通信の動作主体であり、サーバとして動作するプログラムに対して個別にクライアントとしてサービスの提供を要求する際に関数呼び出しを行う点で共通する。
　よって、本願補正発明と引用発明１とは、
　
　プリンタ部またはスキャナ部の少なくとも一方を含む画像処理ハードウェア資源と、画像形成に係るユーザサービスおよびコントロールサービスの処理を行う一または複数のプログラムとを有する画像形成装置であって、
　前記ユーザサービスおよびコントロールサービスのそれぞれは、サーバまたはクライアントとして動作するプログラムであり、
　前記サーバとして動作するプログラムは、前記クライアントとして動作するプログラムに提供する１または複数のサービスを定義した関数を有しており、
　前記クライアントとして動作するプログラムは、通信の動作主体であり、前記サーバとして動作するプログラムに対して個別にクライアントとしてサービスの提供を要求する際に関数呼び出しを行うことを特徴とする画像形成装置。
　
である点で一致し、次の点で相違する。
　
（相違点１）
　サーバまたはクライアントとして動作するプログラムが、本願補正発明では、サーバプロセスまたはクライアントプロセスとして動作する一または複数のスレッドを含むプロセスであるのに対して、引用発明１では、スレッドを含むプロセスとして動作するか否か不明である点。
　
　
（４）判断
（相違点１）について
　プログラミング手法として複数のプログラムを同時に動かすのと同じように、プログラム内で複数の処理を同時に動かしてユーザに提供する複数のサービスを同時に動作するように見せるマルチスレッドプログラミングの手法は、例えば、阿部　隆、”Ｄｅｌｐｈｉマルチスレッドプログラミング”、Ｄｅｌｐｈｉマガジン  第３号、ＰＳネットワーク、1999年03月01日、p.85〜101、（以下、「周知文献１」という。）や、森　誠、”ランタイムエラーをツブせ！セーフティプログラミング”、Ｃ  ＭＡＧＡＺＩＮＥ  第１２巻  第６号、ソフトバンクパブリッシング株式会社、2000年06月01日、p.13〜26（以下、「周知文献２」という。）のように周知慣用技術である。
　そして、プロセスとは、プログラムの動作中のインスタンスを意味し、マルチスレッドプログラミングにおいてプログラムがプロセスとして動作する際に、プロセスが複数のスレッドを含む構成であること（周知文献１のＦｉｇ．２参照）、スレッドとは関数としてコーディングされ、呼び出しが関数呼び出しであること（周知文献１の第８６ページ右欄、周知文献２の第１５ページのＬｉｓｔ１５のスレッドｆｏｏ１、ｆｏｏ２がｖｏｉｄ型の関数である事参照）は、技術常識である。
　してみると、印刷処理やファクシミリ等の複数の機能を有する画像処理装置である引用発明１において、複数のサービスを同時に動作するようにするために、業務タスクおよび関数パッケージであるライブラリ等のプログラミング手法として、周知のマルチスレッドプログラミングを用いる事は格別のものではなく、その際には、業務タスクの動作単位であるスレッドが、動作主体であり、クライアントとして前記サーバプロセスのスレッドに対してサービスの提供を要求する際に関数呼び出しを行うように動作する事や、関数パッケージであるライブラリがその動作単位であるスレッドがクライアントプロセスのスレッドに提供する一または複数のサービスを定義した関数として動作する事は自明な事項である。　
　そして、本願補正発明の全体構成により奏される作用効果も引用発明１及び上記周知慣用技術から当業者が予測し得る範囲内のものにすぎない。　
　
　したがって、本願補正発明は、引用発明１及び上記周知慣用技術に基づいて、当業者が容易に発明をすることができたものと認められるから、特許法第２９条第２項の規定により特許を受けることができない。　
　
（５）むすび
　したがって、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　
３．本願発明について
　本件補正は、上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１７年１０月３１日付け手続補正書の特許請求の範囲の請求項１に記載された事項により特定される以下のとおりのものと認められる。
　
「【請求項１】　画像形成処理で使用されるハードウェア資源と、画像形成に係るユーザサービスおよびコントロールサービスの処理を行う一または複数のプログラムとを有する画像形成装置であって、
　前記ユーザサービスおよびコントロールサービスのそれぞれは、サーバプロセスまたはクライアントプロセスとして動作する一または複数のスレッドを含むプロセスであり、
　前記サーバプロセスのスレッドは、前記クライアントプロセスのスレッドに提供する一または複数のサービスを定義した関数を有しており、
　前記クライアントプロセスのスレッドは、前記サーバプロセスのスレッドにサービスの提供を要求する際に関数呼び出しを行うことを特徴とする画像形成装置。」
　
　
４．引用例
　これに対して、原査定の拒絶の理由に引用された引用例、及び、その記載内容は、上記「２．（２）」に記載したとおりである。
　
５．対比・検討
　本願発明は、平成１８年６月２６日付けの手続補正による補正前の請求項１に記載された発明であり、前記本願補正発明は、同手続補正による補正後の請求項１に記載された発明である。そして、前記２．（２）で検討したように、平成１８年６月２６日付けの手続補正による請求項１に係る補正は特許請求の範囲の減縮を目的としたものであるから、本願補正発明は、本願発明の発明特定事項を更に限定したものである。
　そうすると、本願発明を構成する事項の全てを含み、更に他の事項を付加したものに相当する本願補正発明が前記「２．（４）」に記載したとおり、引用発明及び上記周知慣用技術に基づいて当業者が容易に発明をすることができたものであるから、本願発明も同様の理由により引用発明及び上記周知慣用技術に基づいて当業者が容易に発明をすることができたものである。　
　
６．むすび
　以上のとおりであって、本願発明は特許法第２９条第２項の規定により特許を受けることができない。　
　よって、結論のとおり審決する。