【事件の表示】
　特願２００１−３６５１６３「プロセス間通信履歴表示方法、その方法をコンピュータに実行させるプログラム、画像情報処理装置および画像情報処理システム」拒絶査定不服審判事件〔平成１５年　６月１３日出願公開、特開２００３−１６７７１５〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続きの経緯・本願発明
　
　本願は，平成１３年１１月２９日の出願であって，平成１７年１２月１５日付けで拒絶理由通知がなされ，平成１８年２月２０日付けで意見書及び手続補正書が提出されたが，同年４月１４日付けで拒絶査定がなされ，これに対して同年５月１８日に拒絶査定に対する審判請求がなされるとともに手続補正書が提出され，平成２１年２月１８日付けで審尋がなされ，同年４月２７日に回答書が提出され，同年８月１１日付けで当審により拒絶理由通知がなされ，これに対して同年１０月１９日付けで意見書及び手続補正書が提出されたものである。
　
　
２．本願発明について
　
　本願の請求項１に係る発明は，平成２１年１０月１９日付けの手続補正書によって補正された特許請求の範囲の請求項１に記載された次のとおりのものである（以下，「本願発明」という。）。
　
「　【請求項１】　印刷部または撮像部を有するハードウェア資源を利用して画像情報処理にかかるアプリケーションのプロセスを複数搭載可能とし，オペレーティングシステムと，前記オペレーティングシステム上で動作し，複数の前記アプリケーションからの処理要求を受けて前記ハードウェア資源の獲得制御を行う複数のプログラムのプロセスとを備えた画像情報処理装置で実行され，前記画像情報処理装置で行われるプロセス間通信の通信履歴情報を表示するプロセス間通信履歴表示方法であって，
　前記アプリケーションまたは前記プログラムの各プロセス間におけるプロセス間通信を解析して取得した通信情報と時刻情報とを記録した通信履歴情報を入力する通信履歴入力ステップと，
　前記プログラムもしくは前記アプリケーションの中の単一プロセスと前記単一プロセスの送受信対象のプロセスとを指定した抽出条件を利用者に入力させ，または，前記プログラムもしくは前記アプリケーションの中の複数のプロセスを指定した抽出条件を利用者に入力させる抽出条件入力ステップと，
　前記通信情報を前記時刻情報に基づいて時系列順にソートする解析ステップと，
　前記抽出条件が前記単一プロセスと前記送受信対象のプロセスとである場合に，前記ソートされた通信情報から，前記単一プロセスと前記送受信対象のプロセスとの間で送受信される通信情報を抽出し，前記抽出条件が前記複数のプロセスである場合に，前記ソートされた通信情報から，前記複数のプロセスの間で送受信される通信情報を抽出し，抽出した通信情報を含む通信履歴表示情報を生成する抽出ステップと，
　前記抽出ステップによって生成された通信履歴表示情報を前記画像情報処理装置の表示装置に表示する表示ステップと，
を含むことを特徴とするプロセス間通信履歴表示方法。」
　
　
３．引用例
　
（１）当審拒絶理由にて引用した，本願出願前に頒布された刊行物である特開２００１−３１８８１０号公報（以下，「引用例１」という。）には，図面とともに，次の事項が記載されている。
　
（ａ）「【特許請求の範囲】
【請求項１】  複数のプロセス間でプロセス間通信を行い，複数のタスクを並行して実行するマルチタスクシステムのプロセス間通信ログ方式において，
前記複数のプロセスがそれぞれアクセス可能な記憶手段を備え，前記各プロセス間の通信ログを当該記憶手段に記憶させることを特徴とするプロセス間通信ログ方式。
【請求項２】  記憶された通信ログを前記記憶手段から読み出す手段と，
この読み出す手段に対してネットワークを介してアクセスする手段と，
を備え，前記ネットワークを介して前記アクセスする手段により前記記憶手段にアクセスし，当該記憶手段に記憶された通信ログを読み出すことを特徴とする請求項１記載のプロセス間通信ログ方式。」
　
（ｂ）「【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は，複数のタスクを並行して実行することができるマルチタスク機能を有するマルチタスクシステムのプロセス間で行われる通信ログに係り，特に複写機，プリンタ，ファクシミリなどの各プロセス間通信におけるログの方式，装置，並びにログの手順を記録した記録媒体に関する。
【０００２】
【従来の技術】この種の通信ログに関する発明として，例えば特開平５−６１７３２号公報に開示された発明が知られている。この発明は，プロセス間のソケット通信の際，ソケット通信ログを採取しても，採取しない場合に比較して動作速度がほとんど遅くなることがないようにすることを目的として行われたもので，プロセスのそれぞれにリンクされてソケット通信を行うための通信用ライブラリ関数が収容されている通信用ライブラリと，ソケット通信ログを蓄積するソケット通信路具蓄積手段とを備え，通信用ライブラリはそれぞれ前記プロセス間でソケット通信が行われた場合に，そのソケット通信ログを前記ソケット通信ログ蓄積手段に蓄積するように制御することを特徴としている。
【０００３】
【発明が解決しようとする課題】しかし，この公知の発明では，ソケット通信ログを蓄積手段に蓄積するようになってはいるが，プロセス間通信に適用してネットワークを介してログを取出せるようには構成されていない。一方，プリンタなどの比較的規模が小さいマルチタスクシステムでも，近年の高機能化によりプロセスは数個あるいはそれ以上が，常に稼働している状態となっており，その機能は制御が主なため，プロセス間のインタラクションは頻度と量のいずれも多く，バグが入り込む余地が大きい。また，あるタイミングでしか発生しない不具合も多く，机上では簡単にデバッグできない。規模の小さなシステムについては，ログを記録しておく領域はあまり多くない場合が多く，順次取出しを行わないと，すべてのログを記録できない場合がある。また，一般的なコンピュータにはディスク等の記憶容量の極めて大きな記録装置が付加されているため，これに対して記録を行えば良いが，規模の小さいシステムでは，コストの問題からディスクなども装備されていない場合が多い。
【０００４】本発明は，このような従来技術の実情に鑑みてなされたもので，その目的は，プリンタや複写機など，マルチタスクシステムを採用する比較的規模の小さなものから，汎用システムなどの規模の大きなものに適用できるプロセス間通信ログ方式および装置を提供することにある。
【０００５】また，他の目的は，マルチタスクシステム上で稼働するプロセスとプロセスの間の通信をモニタし，そのログを記録することにより，机上デバッグが難しいタイミング依存のバグ等を容易にデバッグできるプロセス間通信ログ方式および装置を提供することにある。また，他の目的は，ネットワーク経由でログを取出すことにより，記録領域の小さなシステムにおいてもすべてのログを取得できるプロセス間通信ログ方式および装置を提供することにある。」
　
（ｃ）「【００１３】
【発明の実施の形態】以下，本発明の実施形態について図面を参照して説明する。
【００１４】図１は本発明の実施形態に係るシステム構成を示すブロック図で，マルチタスクシステムとＰＣクライアントとをネットワークで接続したシステム構成の概略を示している。すなわち，プリンタ１００とＰＣクライアント２００とからなる本実施形態に係るシステムでは，ネットワーク３００を介してＴＰＣ／ＩＰ（Transmission Control Protocol/Internet Protocol) の通信プロトコルに基づいてプリンタ１００とＰＣクライアント２００との通信が行われる。なお，この実施形態では，マルチタスクシステムとしてプリンタ１００を例示しているが，例えば，複写機でも同様であり，また，複写機能，ファクシミリ機能，プリンタ機能などを複合した複合機でも同様である。
【００１５】ＰＣクライアント２００は，このプリンタ１００から得られたプロセス間通信のログをネットワーク３００を経由して取り出し，ハードディスク２０１等に蓄積する機能を有する。一方，プリンタ（マルチタスクシステム）１００は，この実施形態では，第１プロセス（process-1）１０１，第２プロセス（process-2）１０２，共有メモリ１０３，およびログ読み出しプロセス１０４から基本的に構成されている。各プロセス１０１，１０２には，プロセス間通信を行うためのインターフェース（ＩＰＣ  Ｉ／Ｆ）１０５，１０６が設けられている。プロセス間通信（Inter Process Communication)は，一般には，動作中のプログラム間でデータのやり取りを行うことであるが，ここでは，同一のプリンタ１００内における各プロセス間における通信のことを指している。また，ここで利用しているＩＰＣはソフトウエア割り込みと称されているもので，パラメータなどを送ることはできないが，割り込みを種類を利用して通信の意味を伝えることができるようになっている。
【００１６】このように構成されたシステムでは，図２の処理シーケンスから分かるように，まず，ＰＣクライアント２００によってログの読み出しプロセス１０４を起動する（ステップＳ１）。すなわち，ＰＣクライアント２００とプリンタ（マルチタスクシステム）１００がＴＣＰ／ＩＰ３００の特定ポートで接続されると，ログ読み出しプロセス１０４が起動される。また，第１プロセス１０１及び第２プロセス１０２の起動に先立ってログの記録のための共有メモリ１０３の記憶領域を確保しておく（ステップＳ２）。次いで，マルチタスクシステム１００上で第１プロセス１０１と第２プロセス１０２が起動される（ステップＳ３）。両プロセス１０１，１０２の起動後，第１プロセス１０１と第２プロセス１０２はＩＰＣ  Ｉ／Ｆ１０５，１０６を介して通信をする際に，通信内容を共有メモリ１０３に同時に転送する（ステップＳ４）。なお，共有メモリ１０３は限られた領域しかないため，領域を使い切ったら，領域の最初に戻って書き込むようにする。
【００１７】また，通信内容を共有メモリ１０３に転送する際に，転送する量の空きが共有メモリ１０３上にあるかどうかをチェックし（ステップＳ５），空きがあれば通信内容を転送し，転送終了シグナルをログ読み出しプロセス１０４に送信する（ステップＳ６）。ログ読み出しプロセス１０４は共有メモリ１０３の内容を読み出して処理を終える（ステップＳ７）。
【００１８】これに対し，共有メモリ１０３に空きがなければログ読み出しプロセス１０４に読出要求シグナルを送信し，共有メモリ１０３が空になったという書込可能シグナルをログ読み出しプロセス１０４から受け取るまで，転送処理を中断する（ステップＳ８）。ログ読み出しプロセス１０４は，通信内容転送処理から読出要求シグナルを受け取ったときには，即座に共有メモリ１０３のすべてを読み出し，終了したら通信内容転送処理へ書込可能シグナルを送信する（ステップＳ９）。転送終了シグナルを受け取った場合には，転送が終了している通信内容を読み出す（ステップＳ７）。ログ読み出しプロセス１０４は，通信内容転送処理から読出要求シグナルあるいは転送終了シグナルを受け取ったら，共有メモリ１０３から通信内容を読み出し，ＴＣＰ／ＩＰ３００を介してＰＣクライアント２００に転送する。
【００１９】共有メモリ１０３へ書き出されるデータは，一般的なもので，データの最初にそのデータの長さを示すヘッダがあり，そのヘッダの後ろに，指定されたデータ長のデータが続くものである。そのデータの中には，タイムスタンプ，送信元プロセスＩＤ，送信先プロセスＩＤ，及び送信データなどがセットされている。」
　
（ｄ）「【００２２】
【発明の効果】以上のように，請求項１記載の発明によれば，複数のプロセス間でプロセス間通信を行い，複数のタスクを並行して実行するマルチタスク処理システムのプロセス間通信ログ方式において，前記複数のプロセスがそれぞれアクセス可能な記憶手段を備え，前記各プロセス間の通信ログを当該記憶手段に記憶させるので，この記憶手段に記憶されたプロセス間通信のログを取得することが可能になり，取得したログに基づいてタイミング依存等のバグを容易に発見することができ，デバックが容易になる。また，記憶手段にプロセス間通信のログが記憶されるので，プリンタや複写機など，マルチタスクシステムを採用する比較的規模の小さなものから，汎用システムなどの規模の大きなものについても適用できる。」
　
　よって，引用例１には次の発明（以下，「引用例１記載の発明」という。）が記載されている。
　
「複数のプロセス間でプロセス間通信を行い，複数のタスクを並列して実行するマルチタスクシステムを採用したプリンタ，複写機，複合機などにおいて，
　プロセス間通信の通信ログを記憶手段に記憶し，
　前記通信ログのデータの中には，タイムスタンプ，送信元プロセスＩＤ，送信先プロセスＩＤ，及び送信データなどがセットされており，
　前記記憶手段に記憶した通信ログを外部のＰＣクライアントに転送してデバッグするプロセス間通信ログ方式。」
　
　
（２）当審拒絶理由にて引用した，本願出願前に頒布された刊行物である，桑野秀之，次世代ディジタル複合機“ハイパーパピルス”，Ｍａｔｓｕｓｈｉｔａ　Ｔｅｃｈｎｉｃａｌ　Ｊｏｕｒｎａｌ，松下電器産業株式会社，２０００年４月１８日，第４６巻，第２号，ｐ．６５−７１（以下，「引用例２」という。）には，図面とともに次の記載がある。 
　
（ｅ）「３．１ハード構成
ハイパーパピルスの電気回路は第３図のように構成される。基本モジュールは，全体を制御するＣＰＵブロック，画像処理をつかさどる画像処理ブロック，原稿を読み込むスキャナエンジン，印刷するプリンタエンジン，そしてユーザインタフェースとなるオペレーションパネルから構成される。スキャナエンジンとプリンクエンジンは，１つのＣＰＵで制御される。」（第６７頁）
　
（ｆ）「３．２ソフト構成
　ソフト構成図を第４図に示す。なお，実際には，たとえばＦＡＸタスクだけでも９タスクあり，合計７０のタスクで構成されているが，ここでは主要な構成のみを示す。
　ソフトウェアとＯＳ（ＩＳＩ社ｐＳＯＳ）の間にはＯＳ隠蔽の層であるＩＩＰ （Ｉｎｔｅｌｌｉｇｅｎｔ Ｉｍａｇｅ Ｐｒｏｃｅｓｓｉｎｇ）コアライブラリ層を設けてＯＳに依存しない設計とした。また，ハード制御を行う基本的なタスクは再利用を前提としているので，ＩＩＰ規約に則って開発し，ＩＩＰ−ＡＰＩとしてアプリタスクと接続している。各タスクは，メッセージメール送受信またはイベント駆動で協調動作する。
　アプリタスクは，ユーザインタフェース（ＵＩ）タスクを介してオペレーションパネルから命令を受け取る。ＵＩタスクとオペレーションパネルはシリアル通信で接続される。この通信量が多いとパネル表示が遅れるため，表示フォントや表示画像の保持やズーム時の％計算など，表示にかかわる処理をオペレーションパネルブロックに独立させて通信量を減らしている。」（第６７頁）
　
（ｇ）「５．１資源管理
　資源管理タスクは，入力画像処理，出力画像処理，ビットマップ画像メモリ２バンク，ＤＤバッファ，Ｃｏｄｅｃ用ＬＳＩ−Ａ，Ｃｏｄｅｃ用ＬＳＩ−Ｂ，画像メモリコントローラＡ，画像メモリコントローラＢの各ハードウェア資源獲得の競合調停を行う。管理の方法は資源とタスクの間に立って直接資源を管理するのではなく，各資源の使用権を資源を使いたいタスクにハンドルで渡す。タスクは資源の有無をハンドルで確認して直接資源を使用する。
　この方法だけでは，資源が一度獲得されると他のタスクはプライオリティが高くても資源が開放されるまで待たされることになる。この問題を解決するため，プライオリティと予約という２つの考え方を導入した。
　プライオリティは各タスクに優先順位をつけ資源獲得待ちの際に自分のプライオリティを資源管理タスクに登録する仕組みである。当該資源を使用しているタスクは処理の区切りで獲得待ちの有無をチェックし，自分より上の順位の待ちがあると資源を譲る。
　予約は下位タスクには資源を使用させなくする仕組みである。タスクが自分のプライオリティで資源を予約すると，下位のタスクは資源が空いていても獲得できない。
　予約とプライオリティのイメージを第８図に示す。各タスクはプライオリティが決まっている。資源は通常，最下位のプライオリティである１０の位置にあり，どのタスクからの使用も許されているが，たとえば画像処理タスクによりメモリコントローラが予約されると，メモリコントローラはプライオリティ２０の位置に上がる。予約によりメモリコントローラは，プライオリティが１０のプリントタスク２は使用できないが，プライオリティ２０以上の画像処理タスクやスキャナタスクは使用できるという状態になる。」（第６９頁）
　
　上記（ｇ）を参照すると，各ハードウェア資源獲得の競合調停を行う資源管理タスクは，各資源の使用権を資源を使いたいタスクにハンドルで渡し，タスクは資源の有無をハンドルで確認して直接資源を使用するから，複数のタスク（資源管理タスク，資源を使いたいタスク）が協調してハードウェア資源の獲得制御を行っている。
　よって，引用例２には次の発明（以下，「引用例２記載の発明」という。）が記載されている。
　
「印刷部及び撮像部を有するハードウェア資源を利用して画像情報処理にかかるアプリタスクを複数搭載可能とし，オペレーティングシステム（ｐＳＯＳ）と，前記オペレーティングシステム上で動作し，複数の前記アプリタスクからの処理要求を受けて前記ハードウェア資源の獲得制御を行う複数のタスクを備えた複合機。」
　
　
４．対比
　
　本願発明と引用例１記載の発明とを対比する。
　
　本願請求項１に係る発明（以下，「本願発明」という。）と引用例１記載の発明とを対比すると，引用例１記載の発明の「プリンタ，複写機，複合機など」は，本願発明における「画像情報処理装置」に相当する。
　
　引用例１記載の発明の「タイムスタンプ」，「送信元プロセスＩＤ，送信先プロセスＩＤ，及び送信データなど」，「通信ログ」は，本願発明における「時刻情報」，「通信情報」，「通信履歴情報」にそれぞれ相当し，プロセス間通信を解析して取得した情報といえる。
　
　引用例１記載の発明の通信履歴情報（通信ログ）は，記憶手段あるいはＰＣクライアントへの入力となっているから，引用例１記載の発明は「各プロセス間におけるプロセス間通信を解析して取得した通信情報と時刻情報とを記録した通信履歴情報を入力する通信履歴入力ステップ」に相当する処理を含んでいる。
　
　引用例１記載の発明は，デバッグの際に，通信履歴情報（通信ログ）を表示情報としてＰＣクライアントに表示させることは自明であるから，引用例１記載の発明の「プロセス間通信ログ方式」は，通信履歴表示情報を表示する表示ステップを含むプロセス間通信履歴表示方法といえる。
　
　したがって，本願発明と引用例１記載の発明とは，以下の点で一致し，また，相違している。
　
［一致点］
「画像情報処理装置で行われるプロセス間通信の通信履歴情報を表示するプロセス間通信履歴表示方法であって，
　各プロセス間におけるプロセス間通信を解析して取得した通信情報と時刻情報とを記録した通信履歴情報を入力する通信履歴入力ステップと，
　通信履歴表示情報を表示する表示ステップと，
　を含んだことを特徴とするプロセス間通信履歴表示方法。」
　
［相違点１］
　本願発明における画像情報処理装置は，「印刷部または撮像部を有するハードウェア資源を利用して画像情報処理にかかるアプリケーションのプロセスを複数搭載可能とし，オペレーティングシステムと，前記オペレーティングシステム上で動作し，複数の前記アプリケーションからの処理要求を受けて前記ハードウェア資源の獲得制御を行う複数のプログラムのプロセスとを備え」た構成であり，したがって通信履歴情報における通信情報は，当該構成における「前記アプリケーションまたは前記プログラムの各プロセス間通信」を解析して取得したものであるのに対して，
　引用例１記載の発明における画像情報処理装置は，複数のプロセスが動作するマルチタスクシステムであるが，オペレーティングシステムについて記載がなく，どのようなアプリケーションまたはプログラムのプロセスを備えるのかも明示されていない点。
　
［相違点２］
　本願発明は，「前記プログラムもしくは前記アプリケーションの中の単一プロセスと前記単一プロセスの送受信対象のプロセスとを指定した抽出条件を利用者に入力させ，または，前記プログラムもしくは前記アプリケーションの中の複数のプロセスを指定した抽出条件を利用者に入力させる抽出条件入力ステップと，
　前記通信情報を前記時刻情報に基づいて時系列順にソートする解析ステップと，
　前記抽出条件が前記単一プロセスと前記送受信対象のプロセスとである場合に，前記ソートされた通信情報から，前記単一プロセスと前記送受信対象のプロセスとの間で送受信される通信情報を抽出し，前記抽出条件が前記複数のプロセスである場合に，前記ソートされた通信情報から，前記複数のプロセスの間で送受信される通信情報を抽出し，抽出した通信情報を含む通信履歴表示情報を生成する抽出ステップ」を含んでいるのに対して，
　引用例１記載の発明は，そのような処理については記載されていない点。
　
［相違点３］
　本願発明のプロセス間通信履歴表示方法は，画像情報処理装置で実行され，表示ステップにより「前記抽出ステップによって生成された通信履歴表示情報を前記画像情報処理装置の表示装置に表示する」のに対して，
　引用例１記載の発明のプロセス間通信ログ方式は，画像情報処理装置及びＰＣクライアントで実行され，通信履歴表示情報をＰＣクライアントで表示する点。
　
　
５．判断
　
　上記相違点について検討する。
　
［相違点１］について
　引用例２には，印刷部及び撮像部を有するハードウェア資源を利用して画像情報処理にかかるアプリタスク（本願発明における「アプリケーションのプロセス」に相当）を複数搭載可能とし，オペレーティングシステム（ｐＳＯＳ）と，前記オペレーティングシステム上で動作し，複数の前記アプリタスクからの処理要求を受けて前記ハードウェア資源の獲得制御を行う複数のタスク（本願発明における「プログラムのプロセス」に相当）を備えた複合機が記載されている。
　引用例１，２記載の発明はともに，マルチタスクシステムを採用した画像情報処理装置に関するから，引用例１記載の発明のプロセス間通信ログ方式を実行する画像情報処理装置に引用例２記載の発明のオペレーティングシステムと，前記オペレーティングシステム上で動作し，複数の前記アプリタスクからの処理要求を受けて前記ハードウェア資源の獲得制御を行う複数のタスクを備えた複合機の構成を適用し，当該構成におけるアプリケーションまたはプログラムの各プロセス間通信を解析して取得した通信情報を記録することで，上記相違点１に係る本願発明の構成とすることは当業者が容易に想到し得たことである。
　
［相違点２］について
　特開平５−２６５７７６号公報（段落【００２３】，及び関連する図面），特開平５−２２４９８４号公報（段落【００１３】，【００１６】〜【００１７】）に記載があるように，通信情報を時刻情報に基づいて時系列順にソートして表示することは本願出願前に周知の技術（以下，「周知技術１」という。）であるから，上記「［相違点１］について」において述べた引用例１記載の発明に引用例２記載の発明における複合機の構成を適用して取得，記録した通信情報を，周知技術１のように時系列順にソートすることで，「前記通信情報を前記時刻情報に基づいて時系列順にソートする解析ステップ」を設けることに格別の困難性はない。
　また，特開平７−２９５８５６号公報（【００４９】，【００５６】〜【００５７】，【００８７】），特開２０００−１０８１５号公報（【請求項１】），特開平１０−２４０５７８号公報（【００７７】〜【０１００】，及び関連する図面）に記載があるように，プログラムのデバッグの際に，履歴情報（ログ情報）から，ユーザが指定したプロセス（タスク）に関連する情報だけを抽出して表示させることは本願出願前に周知の技術（以下，「周知技術２」という。）であるから，周知技術２のように，デバッグの際に，ユーザにプロセスを指定させ，「前記ソートされた通信情報から」関連する情報だけを抽出して表示させることに格別の困難性はなく，その際に複数のプロセスが動作するマルチタスクシステムにおいて，バグ（障害）が発生し得る箇所として，「単一のプロセスと前記単一のプロセスの送受信対象のプロセス」の間，あるいは「複数のプロセス」の間は当然に考えられるから，それらのプロセスを抽出条件に指定できるように，「前記プログラムもしくは前記アプリケーションの中の単一プロセスと前記単一プロセスの送受信対象のプロセスとを指定した抽出条件を利用者に入力させ，または，前記プログラムもしくは前記アプリケーションの中の複数のプロセスを指定した抽出条件を利用者に入力させる抽出条件入力ステップ」を設け，当該抽出条件に基づいて「前記抽出条件が前記単一プロセスと前記送受信対象のプロセスとである場合に，前記ソートされた通信情報から，前記単一プロセスと前記送受信対象のプロセスとの間で送受信される通信情報を抽出し，前記抽出条件が前記複数のプロセスである場合に，前記ソートされた通信情報から，前記複数のプロセスの間で送受信される通信情報を抽出し，抽出した通信情報を含む通信履歴表示情報を生成する抽出ステップ」を設けることは当業者が適宜なし得たことである。
　
［相違点３］について
　特開平９−３００９１号公報（段落【０００６】，【０００９】，及び関連する図面），特開２０００−９４７８７号公報（段落【００３８】，及び関連する図面）に記載があるように，画像情報処理装置において，履歴情報等を画像情報処理装置の表示装置（操作パネル部）に表示することは，本願出願前に周知の技術（以下，「周知技術３」という。）であるから，上記「［相違点２］について」において述べた「抽出ステップ」で生成する「通信履歴表示情報」を，周知技術３のように画像情報処理装置の表示装置に表示することに格別の困難性はない。
　
　そして，本願発明のように構成したことによる効果も引用例１，２記載の発明，及び周知技術から予測できる程度のものであって，格別のものではない。
　したがって，本願発明は，引用例１，２記載の発明，及び周知技術に基づいて，当業者が容易に発明をすることができたものである。
　
　なお，本件審判請求人は当審からの拒絶理由通知に対する平成２１年１０月１９日付け提出の意見書において，
「また，拒絶理由通知書によれば，上記プロセスを指定する方法として，どのような条件を指定できるようにするのかは，当業者が適宜設計し得る事項であると判断されている。
　しかしながら，そもそも本願発明の画像情報処理装置は，複数のアプリケーションのプロセスやコントロールサービス（プログラム）のプロセスが動作して複数の異なる機能を有するものである。特に，本願発明では，画像情報処理装置（複合機）の出荷後にユーザもしくは第三者であるサードベンダーが新規なアプリケーションを開発して画像情報処理装置に搭載可能な構成となっているため，新規に開発したアプリケーションのプロセスが，既存のコントロールサービスのプロセスや他の既存のアプリケーションのプロセスと正常にプロセス間通信を行っているか否かを正確かつ容易に判断しなければならない（出願当初明細書の段落０００８参照）。すなわち，複数の異なる機能を有する画像情報処理装置において，既存のプロセスと新規なアプリケーションのプロセスとを区別しなければならず，またこれらの多数のプロセスが動作しているため（出願当初明細書の段落０００８参照），障害が生じていると予想されるプロセスを集中してデバッグする必要が生じてくるため，このような障害が生じていると予想されるプロセスを指定する必要があるのであり，当業者が適宜設計し得る事項ではないと思料する。
　また，このような解決課題から本願発明では，上記構成を採用することにより，デバッグ作業において，障害が生じていると予想されるプロセスにおけるプロセス間通信だけ，あるいは障害が生じていると予想される複数プロセス間のプロセス間通信だけを集中して検証することができ，デバッグ作業をより効率的に行うことができるものである。」
と主張している
　
　しかしながら，既存のプログラムが動作するシステムに新規のプログラムを開発して搭載する場合に，安定して動作する既存のプログラムに対し，新規のプログラムにはバグ（障害）があると予想するのは当然であるから，デバッグ作業において集中して検証すべき項目に，新規に開発したプログラムのプロセスが既存のプログラムのプロセスと正常にプロセス間通信を行っているか否かの検証が含まれることは明らかである。
　また，上記「［相違点２］について」で挙げた周知技術２において，既に記録済となった履歴情報（ログ情報）に含まれる何れの項目をキーに指定してデータを抽出するのかは当業者が適宜設計し得る事項といえ，また，複数のキーを同時に指定してデータを抽出することも普通に行われているから，新規に開発したプログラムのプロセスと既存のプログラムのプロセスとを指定して，検証すべきプロセス間通信の履歴情報を抽出することに格別の困難性はない。
　
　したがって，請求人の主張は採用できない。
　
　
６．結び
　以上のとおり，本願発明は，引用例１，２記載の発明，及び周知技術に基づいて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　よって，結論のとおり，審決する。