【事件の表示】
　平成　６年特許願第２７０８４２号「トランザクション処理方法、記録媒体および分散処理システム」拒絶査定不服審判事件〔平成　８年　５月３１日出願公開、特開平　８−１３７８０８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成６年１１月４日の出願であって、平成１５年４月７日付で手続補正がなされ、同年１１月１７日付で拒絶査定がなされ、これに対し、同年１２月２５日に拒絶査定に対する審判請求がなされるとともに、平成１６年１月２６日付で手続補正がなされたものである。
　
２．平成１６年１月２６日付の手続補正についての補正却下の決定
　
［補正却下の決定の結論］
　平成１６年１月２６日付の手続補正を却下する。
　
［理由］
（１）補正後の本願発明
　平成１６年１月２６日付の手続補正（以下、「本件補正」という。）により、特許請求の範囲は次のとおり補正された。
　
「　【請求項１】　複数の計算機をネットワーク接続し、クライアント計算機で稼動するプログラムからサーバ計算機で稼動するプログラムを呼び出して処理を実行するクライアント・サーバ型の分散処理システムにおけるトランザクション処理方法であって、
　前記クライアント計算機は、該クライアント計算機上のプログラムからの処理要求をサーバ計算機に転送し、
　前記サーバ計算機は、該サーバ計算機で稼動する受け付けプロセスが前記クライアント計算機からの最初の処理要求を受け付けてスケジュールキューに登録して、クライアント計算機からの処理要求を代行的に処理する代行プロセスを起動し、該起動された代行プロセスは、前記スケジュールキューから処理要求を取り出して、前記クライアント計算機からの処理要求を代行処理して、処理結果を前記クライアント計算機に通知し、
　前記クライアント計算機は、同じトランザクションの２回目以降の処理要求については、前記サーバ計算機の前記代行プロセスへ該処理要求を送信し、
　前記サーバ計算機の前記代行プロセスは、前記クライアント計算機からの２回目以降の処理要求を、前記受け付けプロセスを介することなく、直接、受信し、代行処理して、処理結果を前記クライアント計算機に通知し、前記代行処理した処理要求が前記クライアント計算機からの同じトランザクションの最後の処理要求であれば、前記スケジュールキューから新たな処理要求の取り出しを行う、
ことを特徴とするトランザクション処理方法。」
　
　本件補正は、請求項１と請求項３を削除し、請求項２を請求項１に繰り上げるとともに、請求項２に係る発明を特定するために必要な事項である「分散処理システム」、「第１の計算機」、「第２の計算機」、「第１のプロセス」及び「第２のプロセス」を、それぞれ「クライアント・サーバ型の分散処理システム」、「クライアント計算機」、「サーバ計算機」、「受け付けプロセス」及び「代行プロセス」に限定し、さらに、「第２のプロセス」（本件補正後における「代行プロセス」）がスケジュールキューから処理要求を取り出す動作について「前記代行処理した処理要求が前記クライアント計算機からの同じトランザクションの最後の処理要求であれば、前記スケジュールキューから新たな処理要求の取り出しを行う」との限定を付加するものである。
　これらの限定により解決しようとする課題は、本件補正前の請求項１または請求項２に係る発明が解決しようとする課題である、「第２の計算機」（本件補正後における「サーバ計算機」）の「第２のプロセス」（本件補正後における「代行プロセス」）に処理要求群（最初の処理要求、２回目の処理要求、・・・、最後の処理要求からなる「第１の計算機」（本件補正後における「クライアント計算機」）から「第２の計算機」（本件補正後における「サーバ計算機」）への同じトランザクション内の一連の処理要求の集合のこと。）単位に割り当てを行う課題、及び、「第２の計算機」（本件補正後における「サーバ計算機」）の「第１のプロセス」（本件補正後における「受け付けプロセス」）に処理が集中しないようにする課題と同一のものである。よって、平成６年１２月１４日法律第１１６号施行前の特許法第１７条の２第３項第２号の特許請求の範囲の減縮を目的とするものに該当する。
　そこで、本件補正後の請求項１に係る発明が特許出願の際独立して特許を受けることができるものであるか（平成６年１２月１４日法律第１１６号施行前の特許法第１７条の２第４項で読み替えて準用する同法第１２６条第３項の規定に適合するのか）について以下に検討する。
　
（２）判断
　本件補正後の請求項１には、「該サーバ計算機で稼動する受け付けプロセスが前記クライアント計算機からの最初の処理要求を受け付けてスケジュールキューに登録して、クライアント計算機からの処理要求を代行的に処理する代行プロセスを起動し、」と記載されていることから、本件補正後の請求項１に係る発明は、受け付けプロセスがクライアント計算機からの最初の処理要求を受け付けてスケジュールキューに当該最初の処理要求を登録するたびに、代行プロセスを起動するものである。
　ところで、スケジュールキューから処理要求を取り出して代行処理を行う代行プロセスについて、本件補正後の請求項１には「該起動された代行プロセスは、前記スケジュールキューから処理要求を取り出して、前記クライアント計算機からの処理要求を代行処理し」と記載される一方、本件補正後の請求項１には「前記代行処理した処理要求が前記クライアント計算機からの同じトランザクションの最後の処理要求であれば、前記スケジュールキューから新たな処理要求の取り出しを行う」とも記載されている。これらの記載によれば、本件補正後の請求項１に係る発明では、スケジュールキューに格納された１つの最初の処理要求を取り出す主体となる代行プロセスとして、当該最初の処理要求をスケジュールキューに格納する際に受け付けプロセスが起動した代行プロセスと、当該最初の処理要求とは直接の関係はない最後の処理要求の代行処理を済ませた代行プロセスという２種類の代行プロセスが存在することになる。このように、本件補正後の請求項１の記載は、受け付けプロセスの動作、代行プロセスの起動と動作、及び、処理要求の代行プロセスへの割当について明確なものとはいえない。
　したがって、本件補正後の請求項１に係る発明は、平成６年１２月１４日法律第１１６号施行前の特許法第３６条第５項第２号及び第６項に規定する要件を満たさないので、特許出願の際独立して特許を受けることができないものである。
　
（３）むすび
　以上のとおり、本件補正は、平成６年１２月１４日法律第１１６号施行前の特許法第１７条の２第４項で読み替えて準用する同法第１２６条第３項の規定に違反するものであり、同法第１５９条第１項で読み替えて準用する同法第５３条第１項の規定により却下されるべきものである。
　
３．本願発明
　平成１６年１月２６日付の手続補正は上記のとおり却下されたので、本願の請求項１に係る発明（以下、「本願発明」という。）は、平成１５年４月７日付手続補正書の特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものである。
　
「複数の計算機を有し、第１の計算機からの処理要求を第２の計算機で処理する分散処理システムにおけるトランザクション処理方法であって、
　前記第２の計算機は、前記第１の計算機からのトランザクションの処理要求を受信して第１のプロセスを動作し、前記第１のプロセスが前記処理要求を処理する第２のプロセスを起動し、前記第２のプロセスが前記処理要求を処理して処理結果を前記第１の計算機へ通知し、
　前記第１の計算機は、同じトランザクションの２回目以降の処理要求については、前記第２の計算機の前記第２のプロセスへ処理要求を送信し、前記第２のプロセスが前記処理要求を処理して処理結果を前記第１の計算機へ通知することを特徴とするトランザクション処理方法。」
　
４．引用例
　これに対し、原査定の拒絶の理由に引用された特開平６−２４３０７７号公報（平成６年９月２日公開。以下、引用例１という。）には、以下の事項が図面とともに記載されている。
　
（ア）「【産業上の利用分野】本発明は、クライアント・サーバ型の分散トランザクション処理方式に関し、特に複数の処理プロセスを有するサーバシステムの処理プロセスの割り当て方式に関するものである。」（公報第【０００１】段落）
　
（イ）「【課題を解決するための手段】上記目的を達成するために、本発明は、１つのグローバルトランザクション内で複数の処理プロセスを有するサーバシステムが１回目に呼び出されていずれかの処理プロセスを割り当てた時点で当該グローバルトランザクションと当該処理プロセスとを対応付ける手段を設け、同一グローバルトランザクション内での当該サーバシステムの２回目以降の呼出し時には１回目の呼出し時に割り当てた処理プロセスを再度割り当てるようにしたものである。」（公報第【０００８】段落）
　
（ウ）「図において、複数のクライアントコンピュータ１０ａ〜１０ｄと、サーバコンピュータ１１とは、ネットワーク１２で接続されており、クライアントコンピュータ１０ａ〜１０ｄにはクライアントシステム制御プログラム１３とクライアントプログラム１４とが、またサーバコンピュータ１１にはサーバシステム制御プログラム１５と複数のサービス処理プロセス１６ａ〜１６ｄがそれぞれ設けられている。」（公報第【００１３】段落）
　
（エ）「図２は分散トランザクション処理の手順を示すフローチャートであり、クライアントプログラム１４からのサービス要求を受けたクライアントシステム制御プログラム１３は要求されたサービス名称からサーバシステム１１を決定する（ステップ２１，２１）。
　その後、当該サーバシステム１１へのサービス要求が当該グローバルトランザクション内で初めてか否かを判定し（ステップ２２）、初めてでなければ、初回要求時に当該サーバシステム１１のサーバシステム制御プログラム１５から通知されたサービス処理プロセスのＩＤ（例えば１６ａのＩＤ）を送信メッセージ中の特定のフィールドにセットする（ステップ２３）。
　初めての要求ならば、当該フィールドはヌル値のままとする。
　クライアントシステム制御プログラム１３は送信メッセージを組み立てた後、それを該当するサーバシステム制御プログラム１５に送信する（ステップ２４）。」（公報第【００１８】段落〜第【００２１】段落）
　
（オ）「サーバシステム制御プログラム１５は、クライアントシステム制御プログラム１３からのメッセージを受信すると（ステップ２８）、受信メッセージ中に処理プロセスＩＤがセット済か否かを判定する（ステップ２９）。
　もしセット済ならば、それは同一グローバルトランザクション内での２回目以降のサービス要求であり、次のサービス処理要求か同期点処理要求に対し待機中の当該処理プロセスＩＤを持つサービス処理プロセス１６ａを選択する（ステップ３０）。
　もしセット済でなければ、それはグローバルトランザクション内での当該サーバシステム１１に対する最初のサービス処理要求であり、任意の空きサービス処理プロセス、例えば１６ｂを選択する（ステップ３１）。
　サーバシステム制御プログラム１５は選択したサービス処理プロセス１６ａをスケジュールする（ステップ３２）。」（公報第【００２２】段落〜第【００２５】段落）
　
（カ）「スケジュールされたサービス処理プロセス１６ａはサービス実行後（ステップ３５）、結果をサーバシステム制御プログラム１５に送信し（ステップ３６）、同一グローバルトランザクション内からの次のサービス処理要求または同期点処理要求を待つ（ステップ３４，３７）。」（公報第【００２６】段落）
　
（キ）「サービス実行結果を受けたサーバシステム制御プログラム１５は、サービスを実行したサービス処理プロセス１６ａの処理プロセスＩＤを送信メッセージ中の特定のフィールドにセットし（ステップ３８）、サービス実行結果メッセージをクライアントシステム制御プログラム１３に返却する（ステップ３９）。」（公報第【００２７】段落）
　
（ク）「クライアントシステム制御プログラム１３は、同一グローバルトランザクション内からの同一サーバシステムへの次のサービス要求に備え、サーバシステム制御プログラム１５が結果送信メッセージ中にセットした処理プロセスＩＤを記憶し、サービス実行結果をクライアントプログラム１４に返す（ステップ２６，２７）。」（公報第【００２８】段落）
　
（ケ）「図３はクライアントシステム制御プログラム１３とサーバシステム制御プログラム１５の間でやり取りされる送受信メッセージ４０の一例を示すもので、サービス名称フィールド４１、処理プロセスＩＤフィールド４２、デ−タフィールド４３が設けられ、サービスを実行すべき、または実行したサービス処理プロセス１６の処理プロセスＩＤがメッセージ４０中の特定フィールド４２にセットされる。」（公報第【００２９】段落）
　
　以上の記載において、クライアントコンピュータ１０ａ〜１０ｄからサーバコンピュータ１１への同一グローバルトランザクション内における複数の要求について、「サービス処理要求」、「サービス要求」及び「呼出し」という用語を用いられているが、これらは同種のものを示すものであることは明らかである。
　
　これらの（ア）〜（ケ）の記載及び考察によれば、引用例１には、次の発明が記載されているものと認められる（以下「引用例１発明」という。）。
　
　複数のコンピュータを有し、クライアントコンピュータ１０ａ〜１０ｄからのサービス処理要求をサーバコンピュータ１１で処理する分散処理システムにおけるグローバルトランザクション処理方法であって、
　前記サーバコンピュータ１１は、前記クライアントコンピュータ１０ａ〜１０ｄからのグローバルトランザクション内のサービス処理要求を受信してサーバシステム制御プログラム１５を動作し、前記サーバシステム制御プログラム１５が、前記サービス処理要求がグローバルトランザクション内の最初のサービス処理要求である場合には、当該サービス処理要求を処理するサービス処理プロセス１６ａ〜１６ｄを選択してスケジュールし、前記サービス処理プロセス１６ａ〜１６ｄが前記サービス処理要求を処理して、処理結果を、前記サーバシステム制御プログラム１５を介して、前記クライアントコンピュータ１０ａ〜１０ｄへ通知し、
　前記クライアントコンピュータ１０ａ〜１０ｄは、同じグローバルトランザクション内の２回目以降のサービス処理要求については、前記サーバコンピュータ１１の前記サービス処理プロセス１６ａ〜１６ｄを、サービス処理要求に伴う送受信メッセージ４０内の処理プロセスＩＤフィールド４２にて指定して、前記サーバシステム制御プログラム１５を介して、サービス処理要求を送信し、前記サービス処理プロセス１６ａ〜１６ｄが前記サービス処理要求を処理して、処理結果を、前記サーバシステム制御プログラム１５を介して、前記クライアントコンピュータ１０ａ〜１０ｄへ通知することを特徴とするグローバルトランザクション処理方法　　
　
　同じく、原査定の拒絶の理由に引用されたW. Richard Stevens，UNIX Network Programming，Prentice-Hall, Inc.，1991年，p.692-719（以下、引用例２という。）には、特に第７１３頁−第７１５頁に、以下の事項が記載されている。
　
（コ）引用例２の第７１４頁の図１８．６（Figure 18.6）に、ローカルシステム（local system）とリモートシステム（remote system）があり、ローカルシステム内にrdate(client)というプロセスが図示され、リモートシステム内にxnscourierd(child)というプロセスとdateserver(server)というプロセスが図示され、rdate(client)プロセスからxnscourierd(child)プロセスへの情報伝達やxnscourierd(child)プロセスからdateserver(server)プロセスへの情報伝達が行われるのみならず、rdate(client)プロセスとdateserver(server)プロセスの間の双方向の情報伝達が行われることが図示されている。
　
（サ）「3. When the client calls the BinDate function, the client stub writes the desired program number, version number and procedure number to the connection.」（引用例２の第７１４頁第３行目−第４行目（訳）クライアント（client）はBinDate機能を呼び出し、クライアントスタブはプログラム番号、バージョン番号、プロシジャー番号を通信回線に出力する。）
　
（シ）「4.（略）The child then does an exec of the appropriate sever program. （略）」（引用例２の第７１４頁第５行目−第１２行目（訳）チャイルド（child）は適切なサーバプログラム（server program）を実行する。）
　
（ス）「5. Our datesearver program is started（略）. It then calls our BinDate function. When our function returns, the server stub converts the results into the Courier standard format and sends them back to the client.」（引用例２の第７１４頁第１３行目−第１７行目（訳）デートサーバ（datesearver）プログラムの処理が開始される。（略）BinDateが実行される。BinDateの実行が済んだ時、サーバスタブは結果をCourierの基準フォーマットに変換しクライアントに通知する。）
　
（セ）「6.Our client then calls the StrDate function. The client stub sends the corresponding program, version, and procedure numbers across the connection where they are read by the server stub. The server stub in our dateserver process recognizes that the program and version haven't changed, so it calls our StrDate function. （略）　If the server stub receives a request for a different program or a different version, it has to exec the appropriate program to handle the new request. As long as the program and version don't change, a single process on the remote system handles the client requests.」（引用例２の第７１４頁第１８行目−第７１５頁第８行目（訳）クライアントは次にStrDate機能を呼び出す。クライアントスタブは対応するプログラム番号、バージョン番号及びプロシジャー番号を通信回線に出力する。デートサーバ（dateserver）プロセス内のサーバスタブはそれらの番号を読み取り、プログラム番号とバージョン番号が変更されていないことを判定し、StrDateを実行する。（略）もしサーバスタブが異なるプログラム番号または異なるバージョン番号を持つ要求を受け取る場合には、その新たな要求を処理するために適切なプログラムを実行しなければならない。プログラム番号とバージョン番号が変わらない限り、クライアントからの要求を、リモートシステム内のひとつのプロセスが処理する。）
　
（ソ）「7. When our function returns to the server stub, the stub converts the return value and sends it back to the client.」（第７１５頁第９行目−第１０行目（訳）実行が済んだ後、サーバスタブは返り値を変換し、クライアントに通知する。）
　
　以上の（サ）〜（ソ）の記載におけるクライアントは（コ）の記載におけるrdate(client)プロセスのことであり、以下同様に、チャイルドはxnscourierd(child)プロセスのことであり、サーバプログラム、デートサーバプログラム、デートサーバプロセスはいずれもdateserver(server)プロセスのことである。
　
　これらの（コ）〜（ソ）の記載及び考察によれば、要するに、引用例２には、複数のシステムを有し、ローカルシステムからの処理要求をリモートシステムで処理する分散処理システムにおける処理方法であって、前記リモートシステムは、前記ローカルシステムからの最初の処理要求を受信してチャイルドプロセスを動作し、前記チャイルドプロセスが前記最初の処理要求を処理するデートサーバプロセスを起動し、前記デートサーバプロセスが前記最初の処理要求を処理して処理結果を、チャイルドプロセスを介さずに、前記ローカルシステムへ通知し、前記ローカルシステムは、プログラム番号とバージョン番号が同じでプロシジャー番号が異なるだけの２回目の処理要求については、チャイルドプロセスを介さずに、前記リモートシステムの前記デートサーバプロセスへ、２回目の処理要求を送信し、前記デートサーバプロセスが前記２回目の処理要求を処理して処理結果を、チャイルドプロセスを介さずに、前記ローカルシステムへ通知することを特徴とする処理方法が記載されている。
　
５．対比
　本願発明と引用例１発明とを比較する。
　
　引用例１発明の「コンピュータ」は本願発明の「計算機」に相当し、以下同様に、「クライアントコンピュータ１０ａ〜１０ｄ」は「第１の計算機」に、「サービス処理要求」は「処理要求」に、「サーバコンピュータ１１」は「第２の計算機」に、「グローバルトランザクション」は「トランザクション」に、「サービス処理プロセス１６ａ〜１６ｄ」は「第２のプロセス」に、それぞれ相当する。
　また、引用例１発明における「前記サービス処理要求がグローバルトランザクション内の最初のサービス処理要求である場合には、当該サービス処理要求を処理するサービス処理プロセス１６ａ〜１６ｄを選択してスケジュールし、」における「選択してスケジュール」することは、技術常識を考慮すると、プロセスを休眠状態ではない状態すなわち起動状態におくことであるから、本願発明における「前記第１のプロセスが前記処理要求を処理する第２のプロセスを起動し、」における「起動」することに相当する。
　引用例１発明における「サーバシステム制御プログラム１５」は、処理要求受信時に動作し第２のプロセスを起動する点で、本願発明の「第１のプロセス」に対応している。
　引用例１発明においては最初の処理要求と２回目以降の処理要求とで場合分けをするものであるが、本願発明においては、２回目以降の処理要求については「前記第１の計算機は、同じトランザクションの２回目以降の処理要求については、前記第２の計算機の前記第２のプロセスへ処理要求を送信し、前記第２のプロセスが前記処理要求を処理して処理結果を前記第１の計算機へ通知する」としているものの、「前記第２の計算機は、前記第１の計算機からのトランザクションの処理要求を受信して第１のプロセスを動作し、前記第１のプロセスが前記処理要求を処理する第２のプロセスを起動し、前記第２のプロセスが前記処理要求を処理して処理結果を前記第１の計算機へ通知」することがどのような処理要求についてのものなのか文言上明示されていない。しかしながら、２回目以降の処理要求についての処理との対比上、本願発明において「前記第２の計算機は、前記第１の計算機からのトランザクションの処理要求を受信して第１のプロセスを動作し、前記第１のプロセスが前記処理要求を処理する第２のプロセスを起動し、前記第２のプロセスが前記処理要求を処理して処理結果を前記第１の計算機へ通知」することは第２回目以降の処理要求ではない処理要求すなわち最初の処理要求についてのものであることは明らかであるから、結局のところ、本願発明と引用例１発明は、最初の処理要求と２回目以降の処理要求とで場合分けをするものである点で同様である。
　
　したがって、両者は、
　
　複数の計算機を有し、第１の計算機からの処理要求を第２の計算機で処理する分散処理システムにおけるトランザクション処理方法であって、
　前記第２の計算機は、前記第１の計算機からのトランザクションの処理要求を受信して第１のプロセスを動作し、前記第１のプロセスが前記処理要求を処理する第２のプロセスを起動し、前記第２のプロセスが前記処理要求を処理し、
　前記第１の計算機は、同じトランザクションの２回目以降の処理要求については、前記第２のプロセスが前記処理要求を処理することを特徴とするトランザクション処理方法
　
である点で一致する。
一方、両者は、以下の点で相違している。
　
[相違点１]本願発明は、第２のプロセスが処理結果を第１の計算機に通知するのに対し、引用例１発明は、第２のプロセスが第１の計算機に通知する際に第１のプロセスを介する点。
　
[相違点２]同じトランザクションの２回目以降の処理要求に関し、本願発明は、第１の計算機から第２のプロセスに送信するのに対し、引用例１発明は、第１の計算機が処理要求を発信する際に、その処理要求の送受信メッセージにて第２のプロセスを明示的に指定するものではあるものの、第１のプロセスを介する点。
　
６．当審の判断
[相違点１]について
　引用例２には、複数のシステムを有し、ローカルシステムからの処理要求をリモートシステムで処理する分散処理システムにおいて、前記リモートシステムは、前記ローカルシステムからの処理要求を受信してチャイルドプロセスを動作し、前記チャイルドプロセスが前記処理要求を処理するデートサーバプロセスを起動し、前記デートサーバプロセスが前記処理要求を処理する処理方法であって、処理結果を、前記チャイルドプロセスを介さずに、前記ローカルシステムへ通知する発明が記載されている。
　引用例１発明と引用例２に記載された発明は、複数の計算機を有し、第１の計算機からの処理要求を第２の計算機で処理する分散処理システムにおいて、前記第２の計算機は、前記第１の計算機からの処理要求を受信して第１のプロセスを動作し、前記第１のプロセスが前記処理要求を処理する第２のプロセスを起動し、前記第２のプロセスが前記処理要求を処理する処理方法に関するものであり、かつ、前記第２のプロセスが処理結果を前記第１の計算機に通知するものである点で共通するうえ、あるプロセス等から別のプロセス等にデータ等を通信するに際しその通信を仲介するプロセスの数を減らすことは当業者であれば当然検討することであるから、引用例２に記載された発明における、処理結果を、処理要求を受け付けるプロセスを介さずに通知することを、引用例１発明に適用することは、当業者が想到し得たことである。
　
[相違点２]について
　引用例２には、複数のシステムを有し、ローカルシステムからの処理要求をリモートシステムで処理する分散処理システムにおいて、前記リモートシステムは、前記ローカルシステムからの処理要求を受信してチャイルドプロセスを動作し、前記チャイルドプロセスが前記処理要求を処理するデートサーバプロセスを起動し、前記デートサーバプロセスが前記処理要求を処理する処理方法であって、前記ローカルシステムは、２回目の処理要求については、前記リモートシステムの前記チャイルドプロセスを介さずに、前記リモートシステムの前記デートサーバプロセスへ処理要求を送信する発明が記載されている。
　引用例１発明と引用例２に記載された発明は、複数の計算機を有し、第１の計算機からの処理要求を第２の計算機で処理する分散処理システムにおいて、前記第２の計算機は、前記第１の計算機からの処理要求を受信して第１のプロセスを動作し、前記第１のプロセスが前記処理要求を処理する第２のプロセスを起動し、前記第２のプロセスが前記処理要求を処理する処理方法に関するものであり、かつ、２回目の処理要求の処理を行うプロセスが最初の処理要求の際に既に定まっているものである点で共通するうえ、あるプロセス等から別のプロセス等にデータ等を通信するに際しその通信を仲介するプロセスの数を減らすことは当業者であれば当然検討することであるから、引用例２に記載された発明における、既に実行するプロセスが定まっている２回目の処理要求を、処理要求を受け付けるプロセスを介さずに送信することを、引用例１発明に適用することは、当業者が想到し得たことである。
　
　そして、本願発明の作用効果も、引用例１発明及び引用例２に記載された発明から当業者が予測できる範囲のものである。
　
　したがって、本願発明は、引用例１発明、及び、引用例２に記載された発明に基いて、当業者が容易に発明をすることができたものである。
　
７．むすび
　以上のとおり、本願の請求項１に係る発明は、引用例１に記載された発明及び引用例２に記載された発明に基いて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論の通り審決する。