【事件の表示】
　特願２０００−５１９５２４「分散を意識させない態様で分散ソフトウェア開発を容易にするための方法およびシステム」拒絶査定不服審判事件〔平成１１年　５月１４日国際公開、ＷＯ９９／２３７８５、平成１３年１１月１３日国内公表、特表２００１−５２２１１４〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１．手続の経緯
　本願は、
　１９９８年１０月２８日（パリ条約による優先権主張外国庁受理１９９７年１０月３１日、アメリカ合衆国）の出願であって、
　平成１２年４月２８日付けで特許法第１８４条の４第１項の規定による千九百七十年六月十九日にワシントンで作成された特許協力条約（以下、単に「条約」という。）第３条（２）に規定する明細書、請求の範囲、図面及び要約の日本語による翻訳文（以下、「当初翻訳文」という。）が提出されるとともに、特許法第１８４条の８第１項の規定による条約第３４条（２）（ｂ）の規定に基づき提出された補正書の日本語による翻訳文が提出され、
　平成１３年４月１６日付けで手続補正がなされ、
　平成１７年１月２７日付けで最初の拒絶理由通知（同年２月１日発送）がなされ、
　同年７月２９日付けで意見書が提出され、
　同年９月２６日付けで最初の拒絶理由通知（同年１１月２２日発送）がなされ、
　平成１８年５月１９日付けで意見書が提出されるとともに、手続補正がなされ、
　同年８月１７日付けで拒絶査定（同年同月２９日発送）がなされ、
　同年１１月２４日付けで審判請求がなされ、
　同年１２月２２日付けで手続補正がなされ、
　平成１９年３月７日付けで審査官より特許法第１６４条第３項の規定による前置報告がなされ、
　平成２０年１１月２５日付けで当審より審尋（同年１２月２日発送）がなされ、
　この審尋に対して、平成２１年５月２７日付けで回答書が提出され、
　同年７月２９日付けで当審より平成１８年１２月２２日付けの手続補正を却下する旨の補正の却下の決定（平成２１年８月１８日発送）がなされるとともに、同年７月２９日付けで当審より最初の拒絶理由通知（同年８月４日発送）がなされ、
　平成２２年２月１日付けで意見書が提出されるとともに、手続補正がなされ、
　同年３月４日付けで当審より最後の拒絶理由通知（同年同月９日発送）がなされ、
　同年９月９日付けで意見書が提出されるとともに、手続補正がなされたものである。
　
第２．補正却下の決定
　［補正却下の決定の結論］
　平成２２年９月９日付けの手続補正を却下する。
　
　［理由］
２の１．本件補正
　平成２２年９月９日付けの手続補正（以下、「本件補正」という。）の内容は、
　同年２月１日付けの手続補正により補正された特許請求の範囲の記載
「　【請求項１】　分散システムにおいてオペレーションを実行するための方法であって、前記分散システムは、第１のマシンと第２のマシンとを含み、前記第１のマシンと前記第２のマシンとは異なるものであり、
　ディスパッチャを前記第１のマシン上で実行するステップを含み、前記ディスパッチャはリクエストを受信し、前記リクエストに対応する処理を実行するカートリッジに対する経路を選択し、前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり、
　前記リクエストはユニフォーム・リソース・ロケータ（ＵＲＬ）を含み、前記ディスパッチャは、ＵＲＬをカートリッジにマッピングするメタデータを調べる仮想パスマネージャに対して、当該ＵＲＬを送信することにより、前記経路を選択し、
　前記仮想パスマネージャが、前記メタデータに基づいて、前記カートリッジが前記ＵＲＬにマッピングされることを判断して、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより、前記ディスパッチャに応答するステップと、
　カートリッジ実行エンジンを第２のマシン上で実行するステップを含み、前記カートリッジ実行エンジンは前記カートリッジの実行を制御し、
　前記ディスパッチャが、前記第１のマシンにおいて実現されるウェブリスナから、前記オペレーションの実行をリクエストする第１のメッセージを受取るステップを含み、前記第１のメッセージは、前記ウェブリスナがブラウザからブラウザリクエストを受取ったことに応答して前記ディスパッチャに送られたものであり、前記ブラウザは前記分散システムと通信するクライアント装置において実現され、
　前記第１のメッセージに応答して、前記ディスパッチャが第２のメッセージを前記カートリッジ実行エンジンへマシン間通信機構を介して送るステップと、
　前記第２のメッセージに応答して、前記カートリッジ実行エンジンが第３のメッセージを標準カートリッジインターフェイスを介して、前記第２のマシン上で実行されているカートリッジに渡すステップとを含み、前記カートリッジは、各々が前記標準カートリッジインターフェイスを介して呼出されるルーチンを含む複数のカートリッジのうちの１つであり、さらに
　前記第３のメッセージを受取ったことに応答して、前記カートリッジが前記オペレーションを実行するステップを含み、
　各前記ステップは、１つ以上のコンピュータプロセッサで実行される、方法。
　　【請求項２】　前記オペレーションを実行した後に、前記カートリッジが第４のメッセージを前記カートリッジ実行エンジンに渡すステップと、
　前記第４のメッセージに応答して、前記カートリッジ実行エンジンが第５のメッセージを前記ディスパッチャに送るステップと、
　前記第５のメッセージに応答して、前記ディスパッチャが第６のメッセージを前記ウェブリスナに送り、前記ウェブリスナがこれを前記ブラウザに転送するステップとをさらに含む、請求項１に記載の方法。
　　【請求項３】　前記ディスパッチャが第２のメッセージをカートリッジ実行エンジンへ送る前記ステップは、前記ディスパッチャが第２のメッセージをオブジェクトリクエストブローカを介してカートリッジ実行エンジンに送ることによって実行される、請求項２に記載の方法。
　　【請求項４】　前記カートリッジ実行エンジンが第５のメッセージを前記ディスパッチャに送る前記ステップは、前記カートリッジ実行エンジンが第５のメッセージを前記オブジェクトリクエストブローカを介して前記ディスパッチャに送ることによって実行される、請求項３に記載の方法。
　　【請求項５】　前記カートリッジ実行エンジンが第３のメッセージをカートリッジに渡す前記ステップは前記カートリッジ実行エンジンが前記カートリッジ内のルーチンを呼出すことによって行なわれ、
　前記カートリッジが第４のメッセージを前記カートリッジ実行エンジンに渡す前記ステップは、前記カートリッジ内で呼出された前記ルーチンから戻ることによって行なわれる、請求項２に記載の方法。
　　【請求項６】　前記カートリッジは共用ライブラリであり、
　前記カートリッジ実行エンジンが第３のメッセージを前記カートリッジに渡す前記ステップは前記カートリッジが前記共用ライブラリ内のルーチンを呼出すステップを含む、請求項１に記載の方法。
　　【請求項７】　前記カートリッジ実行エンジンを実行時に前記カートリッジに動的にリンクするステップをさらに含む、請求項６に記載の方法。
　　【請求項８】　ブラウザリクエストに関連するオペレーションを行なうためのシステムであって、
　複数のウェブリスナに結合される複数のディスパッチャを含み、前記複数のディスパッチャの各ディスパッチャはリクエストを受信し、前記リクエストに対応する処理を実行するカートリッジへの経路を選択し、前記カートリッジは前記システムにおいて１つ以上のプロセッサによって実行されるコードのモジュールであり、
　マシン間通信機構と、
　複数のカートリッジとを含み、前記カートリッジの各々は標準カートリッジインターフェイスを介して呼出される「exec()」ルーチンを含み、前記標準カートリッジインターフェイスを介して受取った呼出に応答して別々のカートリッジが別々のオペレーションを行ない、さらに
　前記マシン間通信機構を介して前記複数のディスパッチャと通信し、かつ前記標準カートリッジインターフェイスを介して前記複数のカートリッジ内の前記「exec()」ルーチンを呼出すことによって、前記複数のカートリッジと通信する複数のカートリッジ実行エンジンを含み、
　前記リクエストに含まれるユニフォーム・リソース・ロケータ（ＵＲＬ）に前記カートリッジがマッピングされることを、メタデータに基づいて判断し、かつ、前記カートリッジを識別するデータを前記ディスパッチャに送信することによって、前記ディスパッチャに応答する仮想パスマネージャを含み、
　前記複数のディスパッチャの各ディスパッチャは、オペレーションを行なうのにある特定のカートリッジを必要とするブラウザリクエストをウェブリスナが受取ったことに応答して、前記複数のカートリッジ実行エンジンのある特定のカートリッジ実行エンジンへ第１のメッセージを前記マシン間通信機構を介して送るよう構成されており、
　前記ある特定のカートリッジ実行エンジンは、前記第１のメッセージに応答して、前記ある特定のカートリッジ内のexec()ルーチンを前記標準カートリッジインターフェイスを介して呼出すよう構成されており、
　前記ディスパッチャは、前記ＵＲＬを前記仮想パスマネージャに送信することにより、前記経路を選択し、
　前記メタデータは、ＵＲＬをカートリッジに対応付ける、システム。
　　【請求項９】　前記マシン間通信機構はオブジェクトリクエストブローカである、請求項８に記載のシステム。
　　【請求項１０】　分散システムのカートリッジに分散を意識させない態様でオペレーションを行なわせるための方法であって、前記分散システムは、第１のマシンと第２のマシンとを含み、前記第１のマシンと前記第２のマシンとは異なるものであり、前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり、
　ある特定のマシン上で前記カートリッジを実行するステップと、
　前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内のディスパッチャから前記カートリッジに複数のリクエストを渡すステップとを含み、前記カートリッジ実行エンジンは前記カートリッジの実行を制御し、前記リクエストは標準カートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され、
　前記カートリッジに関連付けられる前記カートリッジ実行エンジンを介して返答を前記カートリッジから前記ディスパッチャに渡すステップとを含み、
　前記複数のリクエストの各リクエストは、ユニフォーム・リソース・ロケータ（ＵＲＬ）を含み、前記ディスパッチャは、ＵＲＬをカートリッジにマッピングするメタデータを調べる仮想パスマネージャに対して、当該ＵＲＬを送信することにより、前記経路を選択し、
　前記仮想パスマネージャが、前記メタデータに基づいて、前記カートリッジが前記ＵＲＬにマッピングされることを判断して、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより、前記ディスパッチャに応答するステップと、
　前記カートリッジは、前記分散システムにおける複数のカートリッジの１つであり、
　前記複数のカートリッジの各々特定のカートリッジは、前記標準通信インターフェイスを介してリクエストを受信し、
　前記カートリッジ実行エンジンおよび前記カートリッジは前記第１のマシン上で実行しており、
　前記ディスパッチャは前記第２のマシン上で実行しており、
　各前記ステップは、１つ以上のコンピュータプロセッサで実行される、方法。
　　【請求項１１】　前記カートリッジに関連付けられるカートリッジ実行エンジンを介して前記カートリッジへ前記ディスパッチャから複数のリクエストを渡す前記ステップは、
　　特定のリクエストをマシン間通信機構を介して前記カートリッジ実行エンジンへ送るステップと、
　　前記特定のリクエストを前記カートリッジに送るために、前記カートリッジ実行エンジンに前記カートリッジ内のexec()ルーチンを呼出させるステップとを含む、請求項１０に記載の方法。
　　【請求項１２】　前記特定のリクエストを前記カートリッジ実行エンジンへマシン間通信機構を介して送る前記ステップは、前記特定のリクエストを前記カートリッジ実行エンジンへオブジェクトリクエストブローカを介して送ることによって行なわれる、請求項１１に記載の方法。
　　【請求項１３】　ブラウザリクエストに関連するオペレーションを行なうための方法であって、
　複数のウェブリスナに結合される複数のディスパッチャを実行するステップと、
　複数のカートリッジを実行するステップとを含み、標準カートリッジインターフェイスを介して受取られた呼出に応答してカートリッジがオペレーションを行ない、さらに
　マシン間通信機構を介して前記複数のディスパッチャと通信し、かつ前記標準カートリッジインターフェイスを介して前記複数のカートリッジを呼出すことによって前記複数のカートリッジと通信する複数のカートリッジ実行エンジンを実行するステップを含み、
　前記複数のディスパッチャの各ディスパッチャは、オペレーションを行なうのにある特定のカートリッジを必要とするブラウザリクエストをウェブリスナが受取ったことに応答して、前記マシン間通信機構を介して第１のメッセージを前記複数のカートリッジ実行エンジンのある特定のカートリッジ実行エンジンへ送るよう構成されており、
　前記ある特定のカートリッジ実行エンジンは前記第１のメッセージに応答して、前記オペレーションを行なう前記ある特定のカートリッジ内のルーチンを前記標準カートリッジインターフェイスを介して呼出すよう構成されており、
　前記ブラウザリクエストは、ユニフォーム・リソース・ロケータ（ＵＲＬ）を含み、前記複数のディスパッチャの各ディスパッチャは、ＵＲＬをカートリッジにマッピングするメタデータを調べる仮想パスマネージャに対して、当該ＵＲＬを送信することにより、前記複数のカートリッジのうちのカートリッジへの経路を選択し、
　前記仮想パスマネージャは、前記複数のカートリッジのうちの特定のカートリッジが前記ＵＲＬにマッピングされることを、前記メタデータに基づいて判断し、かつ、前記ＵＲＬが受け取られた特定のディスパッチャに、前記特定のカートリッジを識別するデータを当該特定のディスパッチャに送信することにより応答し、
　各前記ステップは、１つ以上のコンピュータプロセッサによって実行される、方法。
　　【請求項１４】　前記マシン間通信機構はオブジェクトリクエストブローカとして構成される、請求項１３に記載の方法。
　　【請求項１５】　分散システムのカートリッジに分散を意識させない態様でオペレーションを行なわせるための１つ以上の命令シーケンスを担持するコンピュータ可読媒体であって、前記分散システムは、第１のマシンと第２のマシンとを含み、前記第１のマシンと前記第２のマシンとは異なるものであり、前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり、１つ以上のプロセッサによる１つ以上の命令シーケンスの実行は、１つ以上のプロセッサに以下のステップ、すなわち
　ある特定のマシン上で前記カートリッジを実行するステップと、
　前記カートリッジに関連付けられるカートリッジ実行エンジンを介して前記分散システム内のディスパッチャから前記カートリッジに複数のリクエストを渡すステップと、
　前記カートリッジに関連付けられる前記カートリッジ実行エンジンを介して前記カートリッジからディスパッチャに返答を渡すステップとを行なわせ、
　前記複数のリクエストの各リクエストは、ユニフォーム・リソース・ロケータ（ＵＲＬ）を含み、前記ディスパッチャは、ＵＲＬをカートリッジにマッピングするメタデータを調べる仮想パスマネージャに対して、当該ＵＲＬを送信することにより、前記経路を選択し、
　前記仮想パスマネージャが、前記カートリッジが前記ＵＲＬにマッピングされることを前記メタデータに基づいて判断し、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより前記ディスパッチャに応答するステップと、
　前記カートリッジは、前記分散システムにおける複数のカートリッジの１つであり、
　前記複数のカートリッジの各々特定のカートリッジは、標準通信インターフェイスを介してリクエストを受信し、
　前記カートリッジ実行エンジンおよび前記カートリッジは前記第１のマシン上で実行しており、
　前記ディスパッチャは前記第２のマシン上で実行している、コンピュータ可読媒体。
　　【請求項１６】　前記カートリッジに関連付けられるカートリッジ実行エンジンを介してリクエストを前記ディスパッチャから前記カートリッジに渡す前記ステップは
　特定のリクエストをマシン間通信機構を介して前記カートリッジ実行エンジンへ送るステップと、
　前記特定のリクエストを前記カートリッジに送るために、前記カートリッジ実行エンジンに前記カートリッジ内のexec()ルーチンを呼出させるステップとを含む、請求項１５に記載のコンピュータ可読媒体。
　　【請求項１７】　前記特定のリクエストをマシン間通信機構を介して前記カートリッジ実行エンジンへ送る前記ステップは、前記特定のリクエストをオブジェクトリクエストブローカを介して前記カートリッジ実行エンジンに送ることによって行なわれる、請求項１６に記載のコンピュータ可読媒体。」
（以下、この特許請求の範囲を「補正前の請求項」という。）を、
「　【請求項１】　分散システムにおいてオペレーションを実行するための方法であって、前記分散システムは複数のマシンを含み、前記方法は、
　前記複数のマシンの一部のコンピュータプロセッサが、複数のディスパッチャを前記複数のマシンの一部で実行するステップを含み、前記複数のマシンのうちの第１のマシンで実行されている一つの特定のディスパッチャはリクエストを受信し、
　前記特定のディスパッチャはリソースマネージャに問い合わせ、前記リソースマネージャは、前記リクエストに対応する処理を実行する、前記複数のディスパッチャによって使用されていないカートリッジに対する経路を選択し、前記カートリッジが見つかった場合に当該特定のディスパッチャのために当該カートリッジを予約し、前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり、
　前記複数のマシンのうちの第２のマシンのコンピュータプロセッサが、カートリッジ実行エンジンを前記第２のマシン上で実行するステップを含み、前記カートリッジ実行エンジンは前記カートリッジの実行を制御し、
　前記第１のマシンのコンピュータプロセッサによって実行される前記特定のディスパッチャが、前記第１のマシンにおいて実現されるウェブリスナから、前記オペレーションの実行をリクエストする第１のメッセージを受取るステップを含み、前記第１のメッセージは、前記ウェブリスナがブラウザからブラウザリクエストを受取ったことに応答して前記特定のディスパッチャに送られたものであり、前記ブラウザは前記分散システムと通信するクライアント装置において実現され、
　前記第１のメッセージに応答して、前記特定のディスパッチャが第２のメッセージを前記カートリッジ実行エンジンへマシン間通信機構を介して送るステップと、
　前記第２のメッセージに応答して、前記第２のマシンのコンピュータプロセッサによって実現される前記カートリッジ実行エンジンが第３のメッセージを標準カートリッジインターフェイスを介して、前記第２のマシン上で実行されているカートリッジに渡すステップとを含み、前記カートリッジは、各々が前記標準カートリッジインターフェイスを介して呼出されるルーチンを含む複数のカートリッジのうちの１つであり、さらに
　前記第３のメッセージを受取ったことに応答して、前記第２のマシンのコンピュータプロセッサによって実現される前記カートリッジが前記オペレーションを実行するステップを含む、方法。
　　【請求項２】　前記オペレーションを実行した後に、前記カートリッジが第４のメッセージを前記カートリッジ実行エンジンに渡すステップと、
　前記第４のメッセージに応答して、前記カートリッジ実行エンジンが第５のメッセージを前記特定のディスパッチャに送るステップと、
　前記第５のメッセージに応答して、前記特定のディスパッチャが第６のメッセージを前記ウェブリスナに送り、前記ウェブリスナがこれを前記ブラウザに転送するステップとをさらに含む、請求項１に記載の方法。
　　【請求項３】　前記特定のディスパッチャが第２のメッセージをカートリッジ実行エンジンへ送る前記ステップは、前記特定のディスパッチャが第２のメッセージをオブジェクトリクエストブローカを介してカートリッジ実行エンジンに送ることによって実行される、請求項２に記載の方法。
　　【請求項４】　前記カートリッジ実行エンジンが第５のメッセージを前記特定のディスパッチャに送る前記ステップは、前記カートリッジ実行エンジンが第５のメッセージを前記オブジェクトリクエストブローカを介して前記特定のディスパッチャに送ることによって実行される、請求項３に記載の方法。
　　【請求項５】　前記カートリッジ実行エンジンが第３のメッセージをカートリッジに渡す前記ステップは前記カートリッジ実行エンジンが前記カートリッジ内のルーチンを呼出すことによって行なわれ、
　前記カートリッジが第４のメッセージを前記カートリッジ実行エンジンに渡す前記ステップは、前記カートリッジ内で呼出された前記ルーチンから戻ることによって行なわれる、請求項２に記載の方法。
　　【請求項６】　前記カートリッジは共用ライブラリであり、
　前記カートリッジ実行エンジンが第３のメッセージを前記カートリッジに渡す前記ステップは前記カートリッジが前記共用ライブラリ内のルーチンを呼出すステップを含む、請求項１に記載の方法。
　　【請求項７】　前記第２のマシンのコンピュータプロセッサが前記カートリッジ実行エンジンを実行時に前記カートリッジに動的にリンクするステップをさらに含む、請求項６に記載の方法。
　　【請求項８】　ブラウザリクエストに関連するオペレーションを行なうためのシステムであって、
　複数のウェブリスナに結合される複数のディスパッチャを含み、前記複数のディスパッチャの各ディスパッチャはリクエストを受信し、
　リソースマネージャを含み、前記リソースマネージャは、前記複数のディスパッチャからカートリッジのための複数のリクエストを受信し、前記複数のディスパッチャのうちの一つの特定のディスパッチャから、前記複数のリクエストのうちの一つの特定のリクエストに応じて、前記特定のリクエストに対応する処理を実行する前記複数のディスパッチャによって使用されていないカートリッジへの経路を選択し、前記カートリッジが見つかった場合に前記特定のディスパッチャのために当該カートリッジを予約し、前記カートリッジは前記システムにおいて１つ以上のプロセッサによって実行されるコードのモジュールであり、
　マシン間通信機構と、
　複数のカートリッジとを含み、前記カートリッジの各々は標準カートリッジインターフェイスを介して呼出され、前記標準カートリッジインターフェイスを介して受取った呼出に応答して別々のカートリッジが別々のオペレーションを行ない、さらに
　前記マシン間通信機構を介して前記複数のディスパッチャと通信し、かつ前記標準カートリッジインターフェイスを介して呼出すことによって、前記複数のカートリッジと通信する複数のカートリッジ実行エンジンを含み、
　前記複数のディスパッチャの各ディスパッチャは、オペレーションを行なうのにある特定のカートリッジを必要とするブラウザリクエストをウェブリスナが受取ったことに応答して、前記複数のカートリッジ実行エンジンのある特定のカートリッジ実行エンジンへ第１のメッセージを前記マシン間通信機構を介して送るよう構成されており、
　前記ある特定のカートリッジ実行エンジンは、前記標準カートリッジインターフェイスを介して前記第１のメッセージに応答する、システム。
　　【請求項９】　前記マシン間通信機構はオブジェクトリクエストブローカである、請求項８に記載のシステム。
　　【請求項１０】　分散システムのカートリッジに分散を意識させない態様でオペレーションを行なわせるための方法であって、前記分散システムは、複数のマシンを含み、前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり、
　前記複数のマシンのうちの第１のマシンのコンピュータプロセッサが、前記第１のマシン上で前記カートリッジを実行するステップと、
　前記第１のマシンのコンピュータプロセッサが、前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内の、前記複数のマシンのプロセッサのうちの一部で実行される複数のディスパッチャのうちの一つの特定のディスパッチャから、前記カートリッジに複数のサービスリクエストを渡すステップとを含み、前記カートリッジ実行エンジンは前記カートリッジの実行を制御し、前記複数のサービスリクエストは標準カートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され、
　前記第１のマシンのコンピュータプロセッサが、前記カートリッジに関連付けられる前記カートリッジ実行エンジンを介して返答を前記カートリッジから前記特定のディスパッチャに渡すステップを含み、
　前記複数のディスパッチャは、リソースマネージャにリクエストを送信し、前記リソースマネージャは、一つの特定のディスパッチャからの特定のリクエストに応じて、前記特定のリクエストに対応する処理を実行する、前記複数のディスパッチャによって使用されていないカートリッジへの経路を選択し、前記カートリッジが見つかった場合に、前記特定のディスパッチャのための当該カートリッジを予約し、
　前記カートリッジは、前記分散システムにおける複数のカートリッジの１つであり、
　前記複数のカートリッジの各々特定のカートリッジは、前記標準カートリッジインターフェイスを介してサービスリクエストを受信し、
　前記カートリッジ実行エンジンおよび前記カートリッジは前記第１のマシン上で実行しており、
　前記複数のディスパッチャは前記複数のマシンの一部で実行している、方法。
　　【請求項１１】　前記カートリッジに関連付けられるカートリッジ実行エンジンを介して前記カートリッジへ前記ディスパッチャから複数のサービスリクエストを渡す前記ステップは、
　　特定のサービスリクエストをマシン間通信機構を介して前記カートリッジ実行エンジンへ送るステップと、
　　前記特定のサービスリクエストを前記カートリッジに送るために、前記カートリッジ実行エンジンに前記カートリッジの標準カートリッジインターフェイスを呼出させるステップとを含む、請求項１０に記載の方法。
　　【請求項１２】　前記特定のサービスリクエストを前記カートリッジ実行エンジンへマシン間通信機構を介して送る前記ステップは、前記特定のサービスリクエストを前記カートリッジ実行エンジンへオブジェクトリクエストブローカを介して送ることによって行なわれる、請求項１１に記載の方法。
　　【請求項１３】　ブラウザリクエストに関連するオペレーションを行なうための方法であって、
　複数のウェブリスナに結合される複数のディスパッチャを実行するステップと、
　複数のカートリッジを実行するステップとを含み、標準カートリッジインターフェイスを介して受取られた呼出に応答してカートリッジがオペレーションを行ない、さらに
　マシン間通信機構を介して前記複数のディスパッチャと通信し、かつ前記標準カートリッジインターフェイスを介して前記複数のカートリッジを呼出すことによって前記複数のカートリッジと通信する複数のカートリッジ実行エンジンを実行するステップと、
　リソースマネージャを実行するステップとを含み、前記リソースマネージャは、前記複数のディスパッチャから、カートリッジのための複数のリクエストを受信し、前記複数のディスパッチャのうちの一つの特定のディスパッチャからの、複数のリクエストのうちの特定のリクエストに応じて、前記特定のリクエストに対応する処理を実行する、前記複数のディスパッチャによって使用されていないカートリッジへの経路を選択し、かつ、前記カートリッジが見つかった場合に前記特定のディスパッチャのために当該カートリッジを予約し、
　前記複数のディスパッチャの各ディスパッチャは、オペレーションを行なうのにある特定のカートリッジを必要とするブラウザリクエストをウェブリスナが受取ったことに応答して、前記マシン間通信機構を介して第１のメッセージを前記複数のカートリッジ実行エンジンのある特定のカートリッジ実行エンジンへ送るよう構成されており、
　前記ある特定のカートリッジ実行エンジンは前記第１のメッセージに応答して、前記オペレーションを行なう前記ある特定のカートリッジ内のルーチンを前記標準カートリッジインターフェイスを介して呼出すよう構成されており、
　各前記ステップは、１つ以上のコンピュータプロセッサによって実行される、方法。
　　【請求項１４】　前記マシン間通信機構はオブジェクトリクエストブローカとして構成される、請求項１３に記載の方法。
　　【請求項１５】　分散システムのカートリッジに分散を意識させない態様でオペレーションを行なわせるための１つ以上の命令シーケンスを担持するコンピュータ可読媒体であって、前記分散システムは複数のマシンを含み、前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり、１つ以上のプロセッサによる１つ以上の命令シーケンスの実行は、前記複数のマシンの複数のプロセッサに以下のステップ、すなわち
　前記複数のマシンのうちの第１のマシンのプロセッサが、前記第１のマシン上で前記カートリッジを実行するステップと、
　前記カートリッジに関連付けられるカートリッジ実行エンジンを介して前記分散システム内で前記複数のマシンの一部のプロセッサによって実現される複数のディスパッチャから、前記カートリッジに複数のサービスリクエストを渡すステップと、
　前記カートリッジに関連付けられる前記カートリッジ実行エンジンを介して、前記第１のマシンのプロセッサによって実行される前記カートリッジから前記複数のディスパッチャに返答を渡すステップとを行なわせ、
　前記カートリッジは、前記分散システムにおける複数のカートリッジの１つであり、
　前記複数のカートリッジの各々特定のカートリッジは、標準カートリッジインターフェイスを介してサービスリクエストを受信し、
　前記複数のディスパッチャは、リソースマネージャにリクエストを送信し、前記リソースマネージャは、一つの特定のディスパッチャからの特定のリクエストに応じて、前記特定のリクエストに対応する処理を実行する、前記複数のディスパッチャによって使用されていないカートリッジへの経路を選択し、前記カートリッジが見つかった場合に、前記特定のディスパッチャのための当該カートリッジを予約し、
　前記カートリッジ実行エンジンおよび前記カートリッジは前記第１のマシン上で実行しており、
　前記複数のディスパッチャは前記複数のマシンの一部で実行している、コンピュータ可読媒体。
　　【請求項１６】　前記カートリッジに関連付けられるカートリッジ実行エンジンを介して前記分散システム内で複数のサービスリクエストを複数のディスパッチャから前記カートリッジに渡す前記ステップは
　特定のサービスリクエストをマシン間通信機構を介して前記カートリッジ実行エンジンへ送るステップと、
　前記特定のサービスリクエストを前記カートリッジに送るために、標準カートリッジインターフェイスを介して前記カートリッジ実行エンジンに前記カートリッジを呼出させるステップとを含む、請求項１５に記載のコンピュータ可読媒体。
　　【請求項１７】　前記特定のサービスリクエストをマシン間通信機構を介して前記カートリッジ実行エンジンへ送る前記ステップは、前記特定のサービスリクエストをオブジェクトリクエストブローカを介して前記カートリッジ実行エンジンに送ることによって行なわれる、請求項１６に記載のコンピュータ可読媒体。」
（以下、この特許請求の範囲を「補正後の請求項」という。）
と補正するものである。
　
２の２．本件補正が特許法第１７条の２第４項の規定を満たすか否かの検討
　本件補正は、少なくとも、（Ａ）補正前の請求項１０にあった「前記複数のリクエストの各リクエストは、ユニフォーム・リソース・ロケータ（ＵＲＬ）を含み、前記ディスパッチャは、ＵＲＬをカートリッジにマッピングするメタデータを調べる仮想パスマネージャに対して、当該ＵＲＬを送信することにより、前記経路を選択し、…（改行）…前記仮想パスマネージャが、前記メタデータに基づいて、前記カートリッジが前記ＵＲＬにマッピングされることを判断して、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより、前記ディスパッチャに応答するステップと、」という記載を削除することと、（Ｂ）補正前の請求項１０にはなかった「前記複数のディスパッチャは、リソースマネージャにリクエストを送信し、前記リソースマネージャは、一つの特定のディスパッチャからの特定のリクエストに応じて、前記特定のリクエストに対応する処理を実行する、前記複数のディスパッチャによって使用されていないカートリッジへの経路を選択し、前記カートリッジが見つかった場合に、前記特定のディスパッチャのための当該カートリッジを予約し、」という記載を追加すること、を含む。つまり、上記（Ａ）で示される補正は、補正前の請求項１０における発明特定事項である「仮想パスマネージャ」に関係するステップを削除するものであり、上記（Ｂ）で示される補正は、補正前の請求項１０にはなかった発明特定事項である「リソースマネージャ」に関係するステップを新たに追加するものである。
　ところで、平成１４年法律第２４号改正附則第２条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項には、最後の拒絶理由通知を受けた場合において特許請求の範囲についてする補正の目的を限定列挙している。同条同項第２号にはその目的のひとつとして「特許請求の範囲の減縮（第３６条第５項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであつて、その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。）」が示されている（以下、この目的を「限定的減縮の目的」という。）。この同条同項第２号の限定的減縮の規定に照らしてみると、上記（Ａ）で示される補正は、補正前の請求項１０にあった発明特定事項を削除するものであって、この削除の限りにおいては特許請求の範囲の減縮ではなくて特許請求の範囲の拡張にあたり、同条同項第２号の限定的減縮を目的とするものであるとはいえない。また、上記（Ｂ）で示される補正は、補正前の請求項１０にあったいずれの発明特定事項を限定するものでもないので、同条同項第２号でいう「請求項に記載した発明を特定するために必要な事項を限定するもの」であるとはいえず、同条同項第２号の限定的減縮を目的とするものであるとはいえない。さらに、上記（Ｂ）で示される補正により追加された「リソースマネージャ」に関係するステップは少なくとも、特定のディスパッチャによる特定のリクエストに対応する処理を実行するためのカートリッジのうち、いずれのディスパッチャによっても使用されていないものを選択して、特定のディスパッチャに当該選択されたカートリッジを割り当てるという制御を行うという、リソースマネージャにより解決する課題を有するのに対し、補正前の請求項１０の発明特定事項に対応する解決しようとする課題には上記したようなリソースマネージャにより解決する課題に相当するものは含まれない。そのため、上記（Ｂ）で示される補正は、同条同項第２号でいう「その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。」との規定に合致するものではなく、同条同項第２号の限定的減縮を目的とするものであるとはいえない。
　また、上記（Ａ）で示される補正と上記（Ｂ）で示される補正は、同条同項第１号に規定される「第３６条第５項に規定する請求項の削除」、同条同項第３号に規定される「誤記の訂正」、同条同項第４号に規定される「明りようでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。）」のいずれを目的とするものであるともいえない。
　なお、平成２２年９月９日付け意見書において請求人は、上記（Ａ）で示される補正と上記（Ｂ）で示される補正の目的について下記のように主張している。
　
「（ｃ）　「前記複数のリクエストの各リクエストは、ユニフォーム・リソース・ロケータ（ＵＲＬ）を含み、前記ディスパッチャは、ＵＲＬをカートリッジにマッピングするメタデータを調べる仮想パスマネージャに対して、当該ＵＲＬを送信することにより、前記経路を選択し、　前記仮想パスマネージャが、前記メタデータに基づいて、前記カートリッジが前記ＵＲＬにマッピングされることを判断して、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより、前記ディスパッチャに応答するステップと」との記載を、「
前記複数のディスパッチャは、リソースマネージャにリクエストを送信し、前記リソースマネージャは、一つの特定のディスパッチャからの特定のリクエストに応じて、前記特定のリクエストに対応する処理を実行する、前記複数のディスパッチャによって使用されていないカートリッジへの経路を選択し、前記カートリッジが見つかった場合に、前記特定のディスパッチャのための当該カートリッジを予約し
　
　上記主張において引用されている、平成２２年３月９日付け最後の拒絶理由通知の【理由Ｃ】の（３）には、「請求項１〜１７には、前記【理由Ｂ】の（３）で指摘した趣旨Ｆ及び趣旨Ｇが記載されているが、そのようなことは発明の詳細な説明には記載されていない。したがって、請求項１〜１７として記載されている特許を受けようとする発明が、発明の詳細な説明に記載したものではない。」と記載されており、さらに同拒絶理由通知の【理由Ｂ】の（３）には「…（前略）…、「ユニフォーム・リソース・ロケータ（ＵＲＬ）」そのものが「ディスパッチャ」から「カートリッジ実行エンジン」を介して「カートリッジ」に渡されるという趣旨（以下、便宜的に「趣旨Ｆ」という。）を、請求項１０は含むことになる。…（中略）…「ユニフォーム・リソース・ロケータ（ＵＲＬ）」そのものが「標準カートリッジインターフェイス」を介して「カートリッジ実行エンジン」から「カートリッジ」に渡されるという趣旨（以下、便宜的に「趣旨Ｇ」という。）を、請求項１０は含むことになる。…（改行）…しかしながら、前記趣旨Ｆ及び趣旨Ｇは、当初翻訳文にも当初翻訳図面にも記載されておらず、当初翻訳文及び当初翻訳図面の記載から自明でもない。…（後略）…」と記載されている。このような拒絶理由に対して、平成１４年法律第２４号改正附則第２条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第４号で規定される「明りようでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。）」を目的とした補正を行うのであれば、ここでいう「明りようでない記載の釈明」における「釈明」とは、その記載本来の意味内容を明らかにすることであるから（審判便覧の５４−１０の４．（１）や特許・実用新案審査基準の第３部第３節５．２を参照のこと。）、当該補正においては、「ユニフォーム・リソース・ロケータ（ＵＲＬ）」、「ディスパッチャ」、「カートリッジ実行エンジン」、「カートリッジ」、「標準カートリッジインターフェイス」のそれぞれの記載の本来の意味内容を明らかにして、これらの記載の間の関係も適切に示すようにすることにより、請求項において上記された趣旨Ｆ及び趣旨Ｇのような解釈がなされないようにすることが妥当である。しかしながら、本件補正における、上記（Ａ）で示される補正と上記（Ｂ）で示される補正は、このような同条同項第４号で規定される「明りようでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。）」を目的とする補正の範疇を超えて、ユニフォーム・リソース・ロケータ（ＵＲＬ）が関わる全ての発明特定事項を削除し、「仮想パスマネージャ」に関連するステップを削除し、さらに新たに「リソースマネージャ」に関連するステップを追加するものであるから、上記（Ａ）で示される補正と上記（Ｂ）で示される補正は請求人が同意見書で主張するような「明りようでない記載の釈明（拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。）」を目的とするものであるとはいえない。
　以上で示したように、本件補正により、請求項１０について行われた補正は、平成１４年法律第２４号改正附則第２条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項のいずれの号に掲げられる事項を目的としたものでもない。また、本件補正により、上記（Ａ）で示される補正と上記（Ｂ）で示される補正と同様な補正が、請求項１、請求項８、請求項１３、請求項１５においても行われており、これらの請求項についても、同様に、同条同項のいずれの号に掲げられている事項を目的としたものでもない。
　このように、本件補正は、平成１４年法律第２４号改正附則第２条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反する。
　
２の３．独立特許要件の検討
　上記２の２で示したように、本件補正は平成１４年法律第２４号改正附則第２条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反するものであるが、仮に、本件補正が同条同項第２号に規定される限定的減縮の目的を有するものとして、本件補正が、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定（以下、「独立特許要件」という。）を満たすか否かを検討する。
　
２の３の１．特許法第３６条第４項の規定を満たすか否かの検討
　補正後の請求項１０に「前記複数のサービスリクエストは標準カートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され、」及び「前記複数のカートリッジの各々特定のカートリッジは、前記標準カートリッジインターフェイスを介してサービスリクエストを受信し、」と記載されている。
　ところで、補正後の請求項１０の上記で指摘した箇所における「標準カートリッジインターフェイス」に関連して、特許法第１８４条の６第２項でみなされるところの明細書（以下、単に「明細書」という。）の発明の詳細な説明に以下に示す記載がある。
　
「【００３８】
  この発明の一実施例によれば、各カートリッジはすべてのカートリッジに対して共通の全体構造をもたらす標準インターフェイスを有する。この標準インターフェイスは、特定の条件の下でウェブアプリケーションサーバ２８０により呼出されるルーチンのインターフェイスを規定する。この発明の一実施例によれば、抽象カートリッジインターフェイスは以下のとおりである。
【００３９】
【表１】
　
interface Cartridge
{
boolean int();
boolean authenticate(in Principal user_passwd);
boolean exec(in Request req_obj, out Response resp_obj);
boolean shutdown();
}
【００４０】
  init()ルーチンはカートリッジインスタンスを初期化する役割を果たす。このことには、いくつかのサブオブジェクトのコンストラクタを呼出すことと、スレッドを予め分岐させることと、他のすべての必要となる共用リソースを獲得することとが含まれ得る。
【００４１】
  shutdown()ルーチンはすべてのリソースを片付けカートリッジインスタンスをシャットダウンする役割を果たす。カートリッジインスタンスに対して一度shutdown()ルーチンが呼出されると、直ちにカートリッジインスタンスは後続のリクエストを処理するのに利用不可能となる。
【００４２】
  authenticate()ルーチンではカートリッジのサービスをリクエストしているクライアントがそのサービスを用いることを許可されているかどうかを検証する。
【００４３】
  exec()ルーチンはカートリッジに対してすべてのサービスリクエストをディスパッチする包括的なやり方である。
【００４４】
                          例示的カートリッジ
  各カートリッジは、明確に定義された機能を行なうカートリッジとして構成されるか、またはあるアプリケーションのためのインタプリタまたはルーチン環境として作用するプログラム可能なカートリッジとして構成される。プログラム可能なカートリッジの一例はＰＬ／ＳＱＬランタイムであり、これは構造的問合せ言語（Structured Query Language）を用いるオラクルベースのプログラム言語（Oracle-based Programming Language）（ＰＬ／ＳＱＬ）に従ってデータベースクエリーを処理するよう構成される。ＰＬ／ＳＱＬランタイムはデータベースクエリーを有するブラウザリクエストを実行する。ＰＬ／ＳＱＬランタイムは、たとえば、データリンクを介してカートリッジインスタンスと通信しているデータベースサーバにアクセスすることによってリクエストを処理する。
【００４５】
  プログラム可能なカートリッジの別の例はＪＡＶＡランタイムインタプリタである。ＪＡＶＡランタイムインタプリタカートリッジのおかげで、ウェブアプリケーション開発者らはブラウザリクエストを処理するためのサーバ側のＪＡＶＡアプリケーションを書くことができる。同様に、たとえば第三者のサーバによって実行されるプロセスにアクセスするなどの動的オペレーションをもたらすために、カスタムサーバをカートリッジとして構成してもよい。」
　
「【００９１】
  カートリッジは、関数テーブルにカートリッジ関数に対するポインタを蔵置することによってカートリッジ実行エンジンに利用可能となる。一実施例によれば、すべてのカートリッジが、上述の例示のカートリッジインターフェイスにおいて特定された関数を提供する。すべてのカートリッジが同じインターフェイスをサポートするようにさせることにより、単一の標準カートリッジ実行エンジンをすべてのカートリッジに対して用いることができる。
【００９２】
  図２に示されるように、ウェブアプリケーションサーバ２８０はカートリッジ２３０、２３４および２３８の各々に対しカートリッジ実行エンジン２２８、２３２および２３６を含む。カートリッジ実行エンジンは標準のカートリッジインターフェイスを介してカートリッジへの呼出を行なうことにより対応するカートリッジの実行を制御する。カートリッジ実行エンジンとカートリッジとの間で基本的なコールバック機能を確立することにより、そのカートリッジをコールバック機能に応答するよう構成し、次にそのカートリッジをコンフィギュレーションプロバイダ２５６に登録することによってどんなカートリッジもウェブアプリケーションサーバ２８０に統合することができる。
【００９３】
  この発明の一実施例によれば、カートリッジは共用ライブラリとして実装され、カートリッジ実行エンジンは標準カートリッジインターフェイスを用いて共用ライブラリ内のルーチンを呼出す実行可能なプログラムである。カートリッジ実行エンジンはカートリッジとディスパッチャとの間でインターフェイスをもたらし、カートリッジの制御のフローを指示し、カートリッジが用いるサービスを提供する。」
　
　しかしながら、上記した明細書の【００３８】〜【００４５】及び【００９１】〜【００９３】を考慮しても、補正後の請求項１０でいう「標準カートリッジインターフェイス」をいかに実現するのかが不明である。
　特に、明細書の上記で指摘した箇所においては、「抽象カートリッジインターフェイス」として「exec(in Request req_obj, out Response resp_obj)」ルーチンが示され、「exec()ルーチンはカートリッジに対してすべてのサービスリクエストをディスパッチする包括的なやり方である。」と記載されている。しかしながら、ここでいう「包括的なやり方」がいかなるものであるのかが明細書の発明の詳細な説明からは不明である。また、execルーチンの引数として示されている「in Request req_obj」と「out Response resp_obj」が具体的にどのような引数であるのかも不明である。
　明細書の【００４４】〜【００４５】の「各カートリッジは、明確に定義された機能を行なうカートリッジとして構成されるか、またはあるアプリケーションのためのインタプリタまたはルーチン環境として作用するプログラム可能なカートリッジとして構成される。プログラム可能なカートリッジの一例はＰＬ／ＳＱＬランタイムであり、…（中略）…プログラム可能なカートリッジの別の例はＪＡＶＡランタイムインタプリタである。…（中略）…同様に、たとえば第三者のサーバによって実行されるプロセスにアクセスするなどの動的オペレーションをもたらすために、カスタムサーバをカートリッジとして構成してもよい。」という記載から明らかなように、本願においては、互いに異なる処理を行うための複数の種類のカートリッジが存在することが前提となっており、そのような異なる処理を行う複数のカートリッジのそれぞれが用いる引数は、一般的には各カートリッジ毎に異なっていて共通ではない。その一方で、明細書の【００４３】に「exec()ルーチンはカートリッジに対してすべてのサービスリクエストをディスパッチする包括的なやり方である。」と記載され、【００９１】に「すべてのカートリッジが同じインターフェイスをサポートするようにさせることにより、単一の標準カートリッジ実行エンジンをすべてのカートリッジに対して用いることができる。」と記載されていることから、単一の標準カートリッジ実行エンジンをあらゆる種類のカートリッジに対して用いるために、包括的なやり方である同じ「標準カートリッジインターフェース」をサポートしようとするものであると解されるところである。しかしながら、明細書の発明の詳細な説明からは、カートリッジごとに異なる引数をカートリッジ実行エンジンとカートリッジの間で授受することを、包括的なやり方である同じ「標準カートリッジインターフェース」を用いていかに実現するのかが不明である。
　したがって、「標準カートリッジインターフェース」に関して、明細書の発明の詳細な説明は、当業者が補正後の請求項１０に係る発明を実施することができる程度に明確かつ十分に記載したものではない。つまり、補正後の請求項１０に関して、本願は平成１４年法律第２４号改正附則第２条第１項によりなお従前の例によるとされる同法による改正前の特許法第３６条第４項の規定を満たさない。「標準カートリッジインターフェース」という発明特定事項は、補正後の請求項１乃至９に係る発明、及び、補正後の請求項１１乃至１７に係る発明にも含まれるから、補正後の請求項１乃至９に係る発明、及び、補正後の請求項１１乃至１７に係る発明についても同様である。
　
　なお、上記で指摘した点は、平成２２年３月９日付け最後の拒絶理由通知における【理由Ｄ】の（３）でも指摘されているものであるところ、当該【理由Ｄ】の（３）に対して、平成２２年９月９日付け意見書において、請求人は下記の主張を行っている。
　
「　（６−３）　記（３）について
　審判官殿は、段落００４３に記載されている「包括的なやり方」とは、具体的にどのような手法であるのか不明である旨の見解、段落００３９のexecというルーチンの引数として使用されている「Request req_obj」、「Response resp_obj」というのが、具体的にどのような引数であるのかも不明である旨の見解、段落００４３の「包括的なやり方」という記載と矛盾せずにカートリッジごとに異なる引数を授受する手法が不明である旨の見解を示されました。
　この点、まず、段落００３９に示されたカートリッジインターフェイスは、段落０３８に記載のとおり「抽象」的なカートリッジインターフェイスです。本願実施例では、当該カートリッジに関して言語が限定されておらず、一実施例として、抽象カートリッジインターフェイスが規定されているものです。段落００３８〜００４３のような擬似的なコードは、当該カートリッジインターフェイスをどのように構築するかについての考え方をもたらすものであって、実現化のための詳細は、当該技術の分野におけるコンピュータ言語のための周知のプログラミング技術に委ねられるものです。よって、段落００３８〜００４３に記載された「抽象カートリッジインターフェイス」に係る開示は、所謂当業者がその実施をできる程度に明確かつ十分に記載されたものであると思料致します。」
　
　しかしながら、上記主張は、明細書の詳細な説明には抽象的なカートリッジインターフェースが示されているとする主張にとどまるものである。明細書の発明の詳細な説明における抽象的なカートリッジインターフェースの記載からは、カートリッジごとに異なる引数をカートリッジ実行エンジンとカートリッジの間で授受することを、包括的なやり方である同じ「標準カートリッジインターフェース」を用いていかに具体的に実現するのかが不明であり、「周知のプログラミング技術」では実現できず、実現には「周知のプログラミング技術」の程度を超えた試行錯誤を要するものであるから、同意見書による請求人の上記主張を採用することはできない。
　
２の３の２．特許法第３６条第６項第１号の規定を満たすか否かの検討
２の３の２の１．サービスリクエストについて
　補正後の請求項１０に「前記第１のマシンのコンピュータプロセッサが、前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内の、前記複数のマシンのプロセッサのうちの一部で実行される複数のディスパッチャのうちの一つの特定のディスパッチャから、前記カートリッジに複数のサービスリクエストを渡すステップとを含み、前記カートリッジ実行エンジンは前記カートリッジの実行を制御し、前記複数のサービスリクエストは標準カートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され、」と記載されている。
　ところで、明細書の発明の詳細な説明において「サービスリクエスト」という語は【００４３】の「exec()ルーチンはカートリッジに対してすべてのサービスリクエストをディスパッチする包括的なやり方である。」という文にのみ記載されているものである。この【００４３】はカートリッジ実行エンジンとカートリッジとの間のインタフェースについて記載されている箇所であるから、明細書の発明の詳細な説明においては「サービスリクエスト」という語はカートリッジ実行エンジンとカートリッジとの間で渡されるリクエストにのみ用いられているといえる。その一方で、ディスパッチャとカートリッジ実行エンジンとの間で渡されるリクエストについて、明細書の発明の詳細な説明では「変更されたリクエスト」または「変更されたブラウザリクエスト」という語が用いられている。例えば、明細書の【０１０８】に「ディスパッチャ２１４はそこで、変更されたブラウザリクエストを作りステップ３６８においてインスタンス２６０のカートリッジ実行エンジン２２８にその変更されたブラウザリクエストを送って、以下に説明するように利用可能なインスタンス２６０にそのリクエストを処理させる。」と記載されている。つまり、明細書の発明の詳細な説明では、ディスパッチャからカートリッジ実行エンジンに渡されるリクエストは「変更されたリクエスト」または「変更されたブラウザリクエスト」であり、カートリッジ実行エンジンからカートリッジに渡されるリクエストは「サービスリクエスト」である。
　これに対し、補正後の請求項１０の上記で指摘した箇所においては、「…（前略）…カートリッジ実行エンジンを介して、…（中略）…ディスパッチャから、前記カートリッジに複数のサービスリクエストを渡すステップとを含み、…（後略）…」と記載されていることから、ディスパッチャからカートリッジ実行エンジンに渡されるリクエストと、カートリッジ実行エンジンからカートリッジに渡されるリクエストの両方が「サービスリクエスト」ということになる。このように、補正後の請求項１０の上記で指摘した箇所の記載は、明細書の発明の詳細な説明の記載と合致しない。
　したがって、「サービスリクエスト」に関して、補正後の請求項１０に係る発明は明細書の発明の詳細な説明に記載したものであるとはいえない。つまり、補正後の請求項１０に関して、本願は平成１４年法律第２４号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第３６条第６項第１号の規定を満たさない。
　補正後の請求項１１、請求項１２、請求項１５、請求項１６、及び請求項１７にも「サービスリクエスト」について補正後の請求項１０と同趣旨の記載があるので、補正後の請求項１１、請求項１２、請求項１５、請求項１６、及び請求項１７についても同様である。
　
２の３の２の２．リソースマネージャと経路について
　補正後の請求項１０に「前記複数のディスパッチャは、リソースマネージャにリクエストを送信し、前記リソースマネージャは、一つの特定のディスパッチャからの特定のリクエストに応じて、前記特定のリクエストに対応する処理を実行する、前記複数のディスパッチャによって使用されていないカートリッジへの経路を選択し、前記カートリッジが見つかった場合に、前記特定のディスパッチャのための当該カートリッジを予約し、」と記載されている。
　ところで、明細書の発明の詳細な説明において「経路」という語は【００４６】、【００４７】、【００５６】にのみ下記のように記載されている。
　
「【００４６】
                            ディスパッチャ
  ディスパッチャは、リスナが受取ったリクエストを適当なカートリッジへ経路選択するよう構成されるソフトウェアモジュールである。この発明の一実施例によれば、ディスパッチャはサーバ側のプログラム拡張（すなわち、「プラグイン」）として実現される。そのため、ディスパッチャはそれらが属するリスナと同じアドレス空間にロードされそこで実行される。ディスパッチャはコンパイル時にリスナコードとリンクされてもよいし、実行時に動的にロードされてもよい。
【００４７】
  例示される実施例では、ディスパッチャ２１４、２２０および２２６はそれぞれ、リスナ２１０、２１６および２２２に関連付けられる。ディスパッチャ２１４、２２０および２２６は、リスナ２１０、２１６および２２２が受取ったブラウザリクエストをカートリッジへ選択的に経路制御する。」
　
「【００５６】
                          仮想パスマネージャ
  上に述べたように、ディスパッチャは仮想パスマネージャ２５０と通信して各々の変更されたブラウザリクエストをどこに経路選択するかを定める。特定的には、各ブラウザリクエストは典型的にＵＲＬを含む。ブラウザリクエストを受取ると、ディスパッチャはそのリクエスト内のＵＲＬを仮想パスマネージャ２５０に送る。仮想パスマネージャ２５０はこれに応答して、もしあれば、ＵＲＬに関連付けられるカートリッジを識別するデータをディスパッチャに送る。」
　
　上記で示した箇所の記載から、明細書の発明の詳細な説明においては、「経路」という語は、ディスパッチャと仮想パスマネージャが協働して、ブラウザリクエストに含まれるＵＲＬに関連付けられるカートリッジを識別するデータを特定して、ブラウザリクエストを処理すべきカートリッジを判定することについて用いられているといえる。
　その一方、明細書の発明の詳細な説明において「リソースマネージャ」について下記のように記載されている。
　
「【００６０】
                          リソースマネージャ
  ウェブアプリケーションサーバ２８０のリソースマネージャ２５４は、カートリッジに対して予め定められた最小数のインスタンスをイニシエートし、各カートリッジのインスタンスの間で負荷の最適配分を行ない、所与のカートリッジの予め定められた最大数のインスタンスまで必要に応じてカートリッジの新しいインスタンスをイニシエートすることによってカートリッジの各々の実行を管理する。
【００６１】
  たとえば、ある特定のカートリッジ（Ｃ１）のためのメタデータが以下の情報を含んでいると仮定する。
【００６２】
  名称＝Ｃ１
  最小インスタンス＝１０
  最大インスタンス＝５０
  ホストマシン＝Ｍ１、Ｍ３、Ｍ８
  アイドルタイム＝３０秒
  このメタデータに基づいて、カートリッジＣ１が初めに登録される際に、リソースマネージャ２５４はＣ１の１０のインスタンスをイニシエートさせる。リソースマネージャ２５４はラベルＭ１、Ｍ３およびＭ８に関連付けられるマシン上の１０のインスタンスをイニシエートすることになる。
【００６３】
  Ｃ１をアクセスするリクエストをディスパッチャから受取った際、リソースマネージャ２５４はＣ１のいずれかの既存のインスタンスが利用可能であるかどうかを判定する。リクエストを受取った際にＣ１のどのインスタンスも利用可能でない場合、リソースマネージャ２５４はＣ１の最大数のインスタンスが既に実行されているかどうかを判定する。Ｃ１の最大数のインスタンスが既に実行されていない場合、リソースマネージャ２５４は可能なホストマシンの１つの上でＣ１の新しいインスタンスをイニシエートし、リクエストを発行したディスパッチャにこの新しいインスタンスを識別するメッセージを送信する。Ｃ１の最大数のインスタンスが既に実行されている場合、リソースマネージャ２５４はリクエストを発行したディスパッチャに対し、その時点でそのリクエストを取扱うことができないことを示すメッセージを送る。」
　
「【００７３】
            ディスパッチャとリソースマネージャとの相互作用
  上述のように、ディスパッチャは特定のカートリッジに変更されたブラウザリクエストを送る必要がある際にリソースマネージャ２５４と通信する。この発明の一実施例によれば、ディスパッチャはまず、適当なカートリッジのインスタンスが（１）これに既に割当てられているかどうか、また（２）新しい変更されたブラウザリクエストを処理するのに利用可能であるかどうかを判定する。適当なカートリッジインスタンスがディスパッチャに既に割当てられており新しい変更されたブラウザリクエストを処理するのに現在利用可能である場合、ディスパッチャはリソースマネージャ２５４とさらに通信することなく、変更されたブラウザリクエストをカートリッジインスタンスへ転送する。
【００７４】
  たとえば、仮想パスマネージャ２５０によればカートリッジＣ１が処理しなければならないブラウザリクエストをリスナ２１０が受取ったと仮定する。また、表４００がリスナ２１０に割当てられたカートリッジインスタンスの現在のリストおよびステータスを反映すると仮定する。リスナ２１０からブラウザリクエストを受取ると、ディスパッチャ２１４は表４００を調べてカートリッジＣ１のＦＲＥＥインスタンスがあるか探す。例示される表４００では、行４１０がカートリッジＣ１のインスタンス３が現在ＦＲＥＥであることを示している。したがって、ディスパッチャ２１４はさらにリソースマネージャ２５４と通信することなく変更されたブラウザリクエストを直接カートリッジＣ１のインスタンス３に転送する。変更されたブラウザリクエストを送ることに応答してディスパッチャ２１４は行４１０のステータス列４０６のステータス値をＢＵＳＹに変える。
【００７５】
  リスナに現在利用可能である適当なカートリッジインスタンスが既に割当てられていない場合、カートリッジに関連づけられるディスパッチャはリソースマネージャ２５４からのカートリッジインスタンスをリクエストする。必要とされるカートリッジのインスタンスが利用可能でなく、かつ必要とされるカートリッジの既存のインスタンスの数が最大数より下であることをリソースマネージャ２５４が判定した場合、リソースマネージャ２５４は新しいカートリッジをイニシエートする。新しいカートリッジをイニシエートする際に、リソースマネージャ２５４は表５００に新しいカートリッジインスタンスのためのエントリを挿入する。
【００７６】
  たとえば、カートリッジＣ３が処理しなければならないブラウザリクエストをリスナ２１０が受取ったと仮定する。また、カートリッジＣ３のインスタンス３がまだイニシエートされていないものと仮定する。こうした条件の下では、ディスパッチャ２１４はリソースマネージャ２５４にカートリッジＣ３のインスタンスに対するハンドルを求めるリクエストを送る。このリクエストに応答して、リソースマネージャ２５４はマシンＭ３上でカートリッジＣ３のインスタンス３をイニシエートする。さらに、リソースマネージャ２５４は行５１２に見られるエントリを表５００に挿入する。
【００７７】
  表５００にカートリッジＣ３のインスタンス３のための行５１２を挿入した後、リソースマネージャ２５４はディスパッチャ２１４に新しく作られたインスタンスに対するハンドルを送り返す。このハンドルを受取ったことに応答して、ディスパッチャ２１４はそのステータス表４００に新しいインスタンスのためのエントリ（行４１２）を挿入する。ディスパッチャ２１４はそこで、変更されたブラウザリクエストをカートリッジＣ３のインスタンス３に送信する。」
　
　上記で示した箇所の記載から、明細書の発明の詳細な説明においては、「リソースマネージャ」は、ディスパッチャからカートリッジのインスタンスの割り当てを要求するリクエストを受け取ったときに、割り当てるインスタンスを定め、その割り当てるインスタンスを識別するデータ（ハンドル）をディスパッチャに送るものであるといえる。そして、明細書の発明の詳細な説明には、「リソースマネージャ」の動作に関連して「経路」という語を用いた箇所はない。つまり、明細書の発明の詳細な説明においては、「リソースマネージャ」は、カートリッジのインスタンスを選択して、ディスパッチャに当該インスタンスを割り当てるものではあるが、補正後の請求項１０に記載されているような「カートリッジへの経路を選択」するものであるとはいえない。
　したがって、「リソースマネージャ」と「カートリッジへの経路を選択」することの関係に関して、補正後の請求項１０に係る発明は明細書の発明の詳細な説明に記載したものであるとはいえない。つまり、補正後の請求項１０に関して、本願は平成１４年法律第２４号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第３６条第６項第１号の規定を満たさない。
　「リソースマネージャ」と「カートリッジへの経路を選択」することの関係について、補正後の請求項１、請求項８、請求項１３、及び、請求項１５にも同趣旨の記載があるので、結局のところ、補正後の全ての請求項についても同様である。
　
２の３の２の３．リソースマネージャと予約について
　補正後の請求項１０に「前記複数のディスパッチャは、リソースマネージャにリクエストを送信し、前記リソースマネージャは、一つの特定のディスパッチャからの特定のリクエストに応じて、前記特定のリクエストに対応する処理を実行する、前記複数のディスパッチャによって使用されていないカートリッジへの経路を選択し、前記カートリッジが見つかった場合に、前記特定のディスパッチャのための当該カートリッジを予約し、」と記載されている。
　ところで、「２の３の２の２．リソースマネージャと経路について」の項で指摘したように、明細書の発明の詳細な説明においては、「リソースマネージャ」は、カートリッジのインスタンスを選択して、ディスパッチャに当該インスタンスを割り当てるものである。しかしながら、明細書の発明の詳細な説明には、「リソースマネージャ」に関連して「割当」という語は記載されているものの、「予約」という語は一切記載されていない。そして、「予約」と「割当」が同じ意味を有するわけでなく、「予約」という語は、「割当」という語が有する意味を超えて、事前に、または、あらかじめ、という意味をも含むものである。つまり、明細書の発明の詳細な説明においては、「リソースマネージャ」は、カートリッジのインスタンスの割当を行うものであるが、補正後の請求項１０に記載されているような、ディスパッチャからのリクエストに応じて「予約」を行うものであるとはいえない。
　したがって、「リソースマネージャ」と「予約」の関係に関して、補正後の請求項１０に係る発明は明細書の発明の詳細な説明に記載したものであるとはいえない。つまり、補正後の請求項１０に関して、本願は平成１４年法律第２４号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第３６条第６項第１号の規定を満たさない。
　「リソースマネージャ」と「予約」の関係について、補正後の請求項１、請求項８、請求項１３、及び、請求項１５にも同趣旨の記載があるので、結局のところ、補正後の全ての請求項についても同様である。
　
２の３の３．独立特許要件の小括
　このように、本件補正が仮に平成１４年法律第２４号改正附則第２条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第２号で規定される限定的減縮の目的を有するものであるとしても、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反する。
　
２の４．特許法第１７条の２第３項の規定の検討
　「２の３の２．特許法第３６条第６項第１号の規定を満たすか否かの検討」において、補正後の各請求項に係る発明は明細書の発明の詳細な説明に記載したものではないことを指摘した。本件補正により、このような指摘に該当するようになったのであるから、本件補正は、当初翻訳文に記載した事項の範囲内においてしたものとはいえない。
　このように、本件補正は、平成１４年法律第２４号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１８４条の１２第２項で読み替える同法第１７条の２第３項の規定に違反する。
　
２の５．補正却下の決定のむすび
　したがって、本件補正は、平成１４年法律第２４号改正附則第２条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　また、本件補正が仮に平成１４年法律第２４号改正附則第２条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第４項第２号で規定される限定的減縮の目的を有するものであるとしても、本件補正は、平成１８年法律第５５号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。
　さらに、本件補正は、平成１４年法律第２４号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１８４条の１２第２項で読み替える同法第１７条の２第３項の規定に違反するので、同法第１５９条第１項において読み替えて準用する同法第５３条第１項の規定により却下すべきものである。 
　
　よって、上記補正却下の決定の結論のとおり決定する。
　
第３．本願発明の認定
　平成２２年９月９日付けの手続補正は「第２．補正却下の決定」のとおり却下された。
　平成２２年２月１日付けの手続補正により補正された、本願の特許請求の範囲の請求項１０には下記のとおり記載されている。
　
「分散システムのカートリッジに分散を意識させない態様でオペレーションを行なわせるための方法であって、前記分散システムは、第１のマシンと第２のマシンとを含み、前記第１のマシンと前記第２のマシンとは異なるものであり、前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり、
　ある特定のマシン上で前記カートリッジを実行するステップと、
　前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内のディスパッチャから前記カートリッジに複数のリクエストを渡すステップとを含み、前記カートリッジ実行エンジンは前記カートリッジの実行を制御し、前記リクエストは標準カートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され、
　前記カートリッジに関連付けられる前記カートリッジ実行エンジンを介して返答を前記カートリッジから前記ディスパッチャに渡すステップとを含み、
　前記複数のリクエストの各リクエストは、ユニフォーム・リソース・ロケータ（ＵＲＬ）を含み、前記ディスパッチャは、ＵＲＬをカートリッジにマッピングするメタデータを調べる仮想パスマネージャに対して、当該ＵＲＬを送信することにより、前記経路を選択し、
　前記仮想パスマネージャが、前記メタデータに基づいて、前記カートリッジが前記ＵＲＬにマッピングされることを判断して、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより、前記ディスパッチャに応答するステップと、
　前記カートリッジは、前記分散システムにおける複数のカートリッジの１つであり、
　前記複数のカートリッジの各々特定のカートリッジは、前記標準通信インターフェイスを介してリクエストを受信し、
　前記カートリッジ実行エンジンおよび前記カートリッジは前記第１のマシン上で実行しており、
　前記ディスパッチャは前記第２のマシン上で実行しており、
　各前記ステップは、１つ以上のコンピュータプロセッサで実行される、方法。」
　
　平成２２年３月４日付け最後の拒絶理由通知における、【理由Ａ】の（２）と（３）、【理由Ｂ】の（１）と（２）、【理由Ｃ】の（１）と（２）に示されるように、上記した請求項１０の記載において「前記標準通信インターフェイス」の部分は適切なものではなく、上記した請求項１０の記載ぶりや当初翻訳文から考慮すれば、上記した請求項１０の記載における「前記標準通信インターフェイス」の部分は誤記であり、正しくは「前記標準カートリッジインターフェイス」である。（同拒絶理由通知を受けた請求人が、平成２２年９月９日付け手続補正において、請求項１０の「前記標準通信インターフェイス」の部分を「前記標準カートリッジインターフェイス」と補正しようとしたことからも、上記した誤記に関する検討は妥当なものであるといえる。）
　また、同拒絶理由通知における、【理由Ａ】の（４）と（５）に示されるように、上記した請求項１０の記載において「前記経路」の部分は適切なものではなく、「前記経路」の部分のうち、少なくとも「前記」という語を付すのは適切でない。
　さらに、上記した請求項１０の記載において「前記仮想パスマネージャが、前記メタデータに基づいて、前記カートリッジが前記ＵＲＬにマッピングされることを判断して、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより、前記ディスパッチャに応答するステップと、」という部分の末尾における「ステップと、」は誤記であり、正しくは「ステップとを含み、」である。
　これらのことを考慮して、本願の請求項１０に係る発明（以下、「本願発明」という。）は、上記した請求項１０の記載において、「前記標準通信インターフェイス」の部分を「前記標準カートリッジインターフェイス」とし、「前記経路」の部分を「経路」とし、「前記仮想パスマネージャが、前記メタデータに基づいて、前記カートリッジが前記ＵＲＬにマッピングされることを判断して、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより、前記ディスパッチャに応答するステップと、」の末尾における「ステップと、」を「ステップとを含み、」とした、以下のとおりのものと認められる。
　
「分散システムのカートリッジに分散を意識させない態様でオペレーションを行なわせるための方法であって、前記分散システムは、第１のマシンと第２のマシンとを含み、前記第１のマシンと前記第２のマシンとは異なるものであり、前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり、
　ある特定のマシン上で前記カートリッジを実行するステップと、
　前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内のディスパッチャから前記カートリッジに複数のリクエストを渡すステップとを含み、前記カートリッジ実行エンジンは前記カートリッジの実行を制御し、前記リクエストは標準カートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され、
　前記カートリッジに関連付けられる前記カートリッジ実行エンジンを介して返答を前記カートリッジから前記ディスパッチャに渡すステップとを含み、
　前記複数のリクエストの各リクエストは、ユニフォーム・リソース・ロケータ（ＵＲＬ）を含み、前記ディスパッチャは、ＵＲＬをカートリッジにマッピングするメタデータを調べる仮想パスマネージャに対して、当該ＵＲＬを送信することにより、経路を選択し、
　前記仮想パスマネージャが、前記メタデータに基づいて、前記カートリッジが前記ＵＲＬにマッピングされることを判断して、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより、前記ディスパッチャに応答するステップとを含み、
　前記カートリッジは、前記分散システムにおける複数のカートリッジの１つであり、
　前記複数のカートリッジの各々特定のカートリッジは、前記標準カートリッジインターフェイスを介してリクエストを受信し、
　前記カートリッジ実行エンジンおよび前記カートリッジは前記第１のマシン上で実行しており、
　前記ディスパッチャは前記第２のマシン上で実行しており、
　各前記ステップは、１つ以上のコンピュータプロセッサで実行される、方法。」
　
　この本願発明は、同拒絶理由通知の【理由Ｅ】における「本願請求項１０記載の発明」に相当する。
　
第４．平成２２年３月４日付け最後の拒絶理由通知で通知した拒絶理由
　平成２２年９月９日付けの手続補正は「第２．補正却下の決定」のとおり却下された。これを踏まえて、平成２２年３月４日付け最後の拒絶理由通知で通知した拒絶理由を以下の項目にて検討する。
　平成２２年３月４日付け最後の拒絶理由通知で通知した拒絶理由は下記のとおりである。
　
「【理由Ａ】この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第２号に規定する要件を満たしていない。 
 　 
 　　　　　　　　　　　　　　　　　記 
 　 
 　（１）請求項１に記載されている「第１のマシン」、「第２のマシン」と、請求項１に記載されている「１つ以上のコンピュータプロセッサ」の関係が不明であり、請求項１の記載は明確ではない。前記「１つ以上のコンピュータプロセッサ」とは、前記「第１のマシン」、「第２のマシン」が有しているコンピュータプロセッサであるのか、或いは、前記「第１のマシン」、「第２のマシン」の外部に存在するコンピュータプロセッサであるのか、どちらであるのか不明である。外部に存在するコンピュータプロセッサであるとすると、該コンピュータプロセッサと、前記「第１のマシン」、「第２のマシン」とはどのような接続関係にあるのかも、請求項１の記載からは不明である。同様の記載を有する請求項１０にも、同様の記載不備がある。同様の記載を有する請求項１５にも、同様の記載不備がある（請求項１５は、「コンピュータプロセッサ」ではなく「プロセッサ」という表記になっている点を除けば、請求項１について上述した記載不備と同様の記載不備を有している）。請求項１、１０、１５を引用して記載されているその他の請求項についても、同様の記載不備がある。 
 　 
 　（２）請求項１０には「前記標準通信インターフェイス」という記載が存在するが、この記載よりも前には「標準通信インターフェイス」は記載されていない（すなわち、「前記」されていない）ので、請求項１０の「前記標準通信インターフェイス」という記載は矛盾しており、請求項１０の記載は明確ではない。請求項１０を引用して記載されているその他の請求項についても、同様の記載不備がある。 
 　 
 　（３）請求項１０の「標準通信インターフェイス」と、請求項１０の「標準カートリッジインターフェイス」の関係が不明であり、請求項１０の記載は明確ではない（同じものであるならば用語を統一すべきであるし、別のものであるならば両者の関係が明確になるように請求項１０を記載されたい）。同様の記載を有する請求項１５にも、同様の記載不備がある。請求項１０、１５を引用して記載されているその他の請求項についても、同様の記載不備がある。 
 　 
 　（４）請求項１０には「前記経路」という記載が存在するが、この記載よりも前には「経路」は記載されていない（すなわち、「前記」されていない）ので、請求項１０の「前記経路」という記載は矛盾しており、請求項１０の記載は明確ではない。同様の記載を有する請求項１５にも、同様の記載不備がある。請求項１０、１５を引用して記載されているその他の請求項についても、同様の記載不備がある。 
 　 
 　（５）請求項１０には「前記経路」という記載が存在するが、何の経路であるのか不明であり、したがって請求項１０の記載は明確ではない。同様の記載を有する請求項１５にも、同様の記載不備がある。請求項１０、１５を引用して記載されているその他の請求項についても、同様の記載不備がある。 
 　 
 　（６）請求項８には「前記カートリッジの各々は標準カートリッジインターフェイスを介して呼出される「exec()」ルーチンを含み」、「前記複数のカートリッジ内の前記「exec()」ルーチン」、「特定のカートリッジ内のexec()ルーチン」という記載が存在し、これらの記載は、「カートリッジ」の中に「exec()ルーチン」が含まれているという趣旨の記載である。しかしながら、これらの記載は、「カートリッジ」の中に含まれているルーチンの名前が「exec()」という名前であるに過ぎないという趣旨であるのか、或いは、特定の性質や特徴を備えたルーチンを意味する用語として「exec()ルーチン」という用語を用いているのか、どちらであるのか不明である。また、仮に、特定の性質や特徴を備えたルーチンを意味する用語として「exec()ルーチン」という用語を請求項８において用いていると仮定すると、当該「特定の性質や特徴」とは何であるのかも不明である。したがって、請求項８の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。 
 　　　　　　　　　　　　　　　　　　　　　　　　　（以上、理由Ａ） 
 　 
 【理由Ｂ】特許法第１８４条の４第１項の規定により、平成１２年４月２８日付けで明細書の翻訳文（以下、「当初翻訳文」という。）及び翻訳図面（以下、「当初翻訳図面」という。）が提出されており、これら当初翻訳文及び当初翻訳図面は、特許法第１８４条の６第２項の規定により、願書に最初に添付された明細書及び図面とみなされるものであるが、平成２２年２月１日付けでした手続補正は、下記の点で当初翻訳文又は当初翻訳図面に記載した事項の範囲内においてしたものではないから、特許法第１７条の２第３項に規定する要件を満たしていない。 
 　 
 　　　　　　　　　　　　　　　　　記 
 　 
 　（１）請求項１０、１５の「標準通信インターフェイス」は、当初翻訳文にも当初翻訳図面にも記載されておらず、当初翻訳文又は当初翻訳図面の記載から自明でもない。請求項１０、１５を引用して記載されているその他の請求項についても同様。 
 　 
 　（２）請求項１０、１５には、「標準カートリッジインターフェイス」とは別に「標準通信インターフェイス」が存在し、該「標準通信インターフェイス」を用いて「カートリッジ」が「リクエスト」を「受信」する旨の記載が存在するが、そのようなことは当初翻訳文にも当初翻訳図面にも記載されておらず、当初翻訳文又は当初翻訳図面の記載から自明でもない。請求項１０、１５を引用して記載されているその他の請求項についても同様。 
 　 
 　（３）請求項１０には、「
前記複数のリクエスト
 　一方、請求項１０には、「前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内のディスパッチャから前記カートリッジに
複数のリクエスト
 　そして、請求項１０において、前記記載Ａよりも前に「複数のリクエスト」という記述が出現するのは前記記載Ｃ内のみであることから、前記記載Ａに含まれる「前記複数のリクエスト」は、前記記載Ｃに含まれる「複数のリクエスト」を指すという解釈しかできない。 
 　すると、前記記載Ａが含む前記趣旨Ｂと、前記記載Ｃが含む前記趣旨Ｄとを総合することで得られる、「ユニフォーム・リソース・ロケータ（ＵＲＬ）」を「含」んでいる「リクエスト」が、「ディスパッチャ」から「カートリッジ実行エンジン」を介して「カートリッジ」に渡されるという趣旨、すなわち、「ユニフォーム・リソース・ロケータ（ＵＲＬ）」そのものが「ディスパッチャ」から「カートリッジ実行エンジン」を介して「カートリッジ」に渡されるという趣旨（以下、便宜的に「趣旨Ｆ」という。）を、請求項１０は含むことになる。 
 　同様に、前記記載Ａが含む前記趣旨Ｂと、前記記載Ｃが含む前記趣旨Ｅとを総合することで得られる、「ユニフォーム・リソース・ロケータ（ＵＲＬ）」を「含」んでいる「リクエスト」が、「標準カートリッジインターフェイス」を介して「カートリッジ実行エンジン」から「カートリッジ」に渡されるという趣旨、すなわち、「ユニフォーム・リソース・ロケータ（ＵＲＬ）」そのものが「標準カートリッジインターフェイス」を介して「カートリッジ実行エンジン」から「カートリッジ」に渡されるという趣旨（以下、便宜的に「趣旨Ｇ」という。）を、請求項１０は含むことになる。 
 　しかしながら、前記趣旨Ｆ及び趣旨Ｇは、当初翻訳文にも当初翻訳図面にも記載されておらず、当初翻訳文及び当初翻訳図面の記載から自明でもない。 
 　当初翻訳文の段落【０００３】、【００３７】、【００４８】、【００５３】、【００５６】〜【００５９】には、 
 　 
 「【０００３】 
 　ワールド・ワイド・ウェブのユーザはブラウザと呼ばれるクライアントプログラムを用いてリスナから情報をリクエストし、デコードし、表示する。ブラウザのユーザがあるＨＴＭＬページ上のリンクを選択すると、そのページを表示している
ブラウザは
ＵＲＬ
と関連付けられるリスナに
リクエストを送る
 　 
 「【００３７】 
 　　　　　　　　　　　　　　カートリッジ 
 　カートリッジは特定のアプリケーションまたはシステム機能を行なうためのコードのモジュールである。カートリッジはシステム２００における分散の基本単位を形成する。この発明の一実施例によれば、
カートリッジは
ＵＲＬ）を用いて名付けられる
すなわち、カートリッジ名には２つの部分
カートリッジが存在するサーバのＩＰアドレスと
サーバディレクトリ構造における仮想パスとがある
 　 
 「【００４８】 
 　たとえば、
リスナ２１０が
ＵＲＬ
の形態で運ばれるブラウザリクエストを
受取る
リスナ２１０はそのブラウザリクエストの解釈を全く試みることなくディスパッチャ２１４に受渡す。ブラウザリクエストを受取ると、ディスパッチャ２１４は
 　（１）
仮想パスマネージャ２５０と通信してブラウザリクエストによって選択されるカートリッジを識別し
 　（２）そのカートリッジが認証を必要とする場合、認証サーバ２５２と通信してブラウザがその選択されたカートリッジにアクセスすることが許されるかどうかを判定し、 
 　（３）
アクセスが許可された場合に、リソースマネージャと通信してブラウザリクエストを送るべき選択されたカートリッジの特定のインスタンスを定め
 　（４）カートリッジの特定されたインスタンスによる実行のため、変更されたブラウザリクエストを作りかつディスパッチする。」、 
 　 
 「【００５３】 
 　オブジェクト識別子は、対応するカートリッジによるオペレーションの実行をリクエストするためにブラウザリクエストが供給しなければならないデータを特定する。オブジェクトタイプは特定のワードまたはＵＲＬであってもよく、または「/java」などの仮想パスを含んでいてもよい。」、 
 　 
 「【００５６】 
 　　　　　　　　　　　　　　仮想パスマネージャ 
 　上に述べたように、ディスパッチャは仮想パスマネージャ２５０と通信して各々の変更されたブラウザリクエストをどこに経路選択するかを定める。特定的には、
各ブラウザリクエストは典型的にＵＲＬを含む
ディスパッチャはそのリクエスト内のＵＲＬを仮想パスマネージャ２５０に送る
 　【００５７】 
 　必要とされる情報をディスパッチャに供給するため、仮想パスマネージャ２５０はＵＲＬをカートリッジにマッピングするメタデータ２５８を調べる。ブラウザリクエストを受取ったことに応答して、仮想パスマネージャ２５０はマッピングデータを用いて、もしあれば、ブラウザリクエストに含まれるＵＲＬに対応するカートリッジを判定する。 
 　【００５８】 
 　たとえば、ブラウザリクエストが仮想パス「/java」で始まるＵＲＬリクエストである場合、マッピングにより、ＪＡＶＡインタプリタカートリッジが仮想パス「/java」を有するリクエストを取扱うよう構成されていることが示されるかもしれない。 
 　【００５９】 
 　この発明の一実施例によれば、仮想パスマネージャ２５０はまた、ＵＲＬに関連付けられたカートリッジが認証を必要とするかどうかを判定する。カートリッジが認証を要する場合、仮想パスマネージャ２５０はディスパッチャに送る応答において、認証が必要であることを示す。認証が必要でない場合、ディスパッチャは認証サーバ２５２を呼出すことなく、カートリッジのインスタンスに対する変更されたブラウザリクエストを作って送る。認証が必要である場合、変更されたリクエストをカートリッジのインスタンスに送出してもよいことを認証サーバが示した後に初めてディスパッチャはそのカートリッジのインスタンスに変更されたリクエストを送る。」 
 　 
 という記載が存在するが、前記趣旨Ｆのように「ユニフォーム・リソース・ロケータ（ＵＲＬ）」そのものが「ディスパッチャ」から「カートリッジ実行エンジン」を介して「カートリッジ」に渡されることや、前記趣旨Ｇのように、「ユニフォーム・リソース・ロケータ（ＵＲＬ）」そのものが「標準カートリッジインターフェイス」を介して「カートリッジ実行エンジン」から「カートリッジ」に渡されることは、当初翻訳文にも当初翻訳図面にも記載されておらず、当初翻訳文又は当初翻訳図面に記載した事項から自明でもない。 
 　したがって、請求項１０についてした補正は、当初翻訳文又は当初翻訳図面に記載した事項の範囲内で行われていない。 
 　請求項１０と同様の記載を有する請求項１〜９、１１〜１７についても、同様に、当初翻訳文又は当初翻訳図面に記載した事項の範囲内で補正が行われていない。 
 　　　　　　　　　　　　　　　　　　　　　　　　　（以上、理由Ｂ） 
 　 
 【理由Ｃ】この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第１号に規定する要件を満たしていない。 
 　 
 　　　　　　　　　　　　　　　　　記 
 　 
 　（１）請求項１０、１５の「標準通信インターフェイス」に対応する記載は、発明の詳細な説明に記載されていない。したがって、請求項１０、１５として記載されている特許を受けようとする発明が、発明の詳細な説明に記載したものではない。請求項１０、１５を引用して記載されているその他の請求項についても同様の記載不備がある。 
 　 
 　（２）請求項１０、１５には、「標準カートリッジインターフェイス」とは別に「標準通信インターフェイス」が存在し、該「標準通信インターフェイス」を用いて「カートリッジ」が「リクエスト」を「受信」する旨の記載が存在するが、これに対応する記載は、発明の詳細な説明に記載されていない。したがって、請求項１０、１５として記載されている特許を受けようとする発明が、発明の詳細な説明に記載したものではない。請求項１０、１５を引用して記載されているその他の請求項についても同様の記載不備がある。 
 　 
 　（３）請求項１〜１７には、前記【理由Ｂ】の（３）で指摘した趣旨Ｆ及び趣旨Ｇが記載されているが、そのようなことは発明の詳細な説明には記載されていない。したがって、請求項１〜１７として記載されている特許を受けようとする発明が、発明の詳細な説明に記載したものではない。 
 　　　　　　　　　　　　　　　　　　　　　　　　　（以上、理由Ｃ） 
 　 
 【理由Ｄ】この出願は、発明の詳細な説明の記載が下記の点で、特許法第３６条第４項に規定する要件を満たしていない。 
 　 
 　　　　　　　　　　　　　　　　　記 
 　 
 　（１）請求項１０、１５、並びに、請求項１０、１５をそれぞれ引用して記載されているその他の請求項には、「標準通信インターフェイス」が記載されているが、この「標準通信インターフェイス」の具体的な実現手法が、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。 
 　 
 　（２）請求項１０、１５、並びに、請求項１０、１５をそれぞれ引用して記載されているその他の請求項には、「標準カートリッジインターフェイス」とは別に「標準通信インターフェイス」が存在し、該「標準通信インターフェイス」を用いて「カートリッジ」が「リクエスト」を「受信」する旨の記載が存在するが、この記載の具体的な実現手法が、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。 
 　 
 　（３）当初翻訳文の段落【００３８】〜【００４３】には、 
 　 
 「【００３８】 
 　この発明の一実施例によれば、各カートリッジはすべてのカートリッジに対して共通の全体構造をもたらす標準インターフェイスを有する。この標準インターフェイスは、特定の条件の下でウェブアプリケーションサーバ２８０により呼出されるルーチンのインターフェイスを規定する。この発明の一実施例によれば、抽象カートリッジインターフェイスは以下のとおりである。 
 【００３９】 
 【表１】 
 　interface Cartridge 
 　{ 
 　boolean init(); 
 　boolean authenticate(in Principal user_passwd); 
 　boolean exec(
in Request req_obj, out Response resp_obj
 　boolean shutdown(); 
 　} 
 　 
 【００４０】 
 　init()ルーチンはカートリッジインスタンスを初期化する役割を果たす。このことには、いくつかのサブオブジェクトのコンストラクタを呼出すことと、スレッドを予め分岐させることと、他のすべての必要となる共用リソースを獲得することとが含まれ得る。 
 【００４１】 
 　shutdown()ルーチンはすべてのリソースを片付けカートリッジインスタンスをシャットダウンする役割を果たす。カートリッジインスタンスに対して一度shutdown()ルーチンが呼出されると、直ちにカートリッジインスタンスは後続のリクエストを処理するのに利用不可能となる。 
 【００４２】 
 　authenticate()ルーチンではカートリッジのサービスをリクエストしているクライアントがそのサービスを用いることを許可されているかどうかを検証する。 
 【００４３】 
 　exec()ルーチンはカートリッジに対してすべてのサービスリクエストをディスパッチする
包括的なやり方
 　 
 という記載が存在するが、前記段落【００４３】に記載されている「包括的なやり方」とは、具体的にどのような手法であるのか不明である。また、前記段落【００３９】のexecというルーチンの引数として使用されている「Request req_obj」、「Response resp_obj」というのが、具体的にどのような引数であるのかも不明である。当初翻訳文の段落【００４４】〜【００４５】には「各カートリッジは、明確に定義された機能を行なうカートリッジとして構成されるか、またはあるアプリケーションのためのインタプリタまたはルーチン環境として作用するプログラム可能なカートリッジとして構成される。プログラム可能なカートリッジの一例はＰＬ／ＳＱＬランタイムであり、（中略）プログラム可能なカートリッジの別の例はＪＡＶＡランタイムインタプリタである。（中略）同様に、たとえば第三者のサーバによって実行されるプロセスにアクセスするなどの動的オペレーションをもたらすために、カスタムサーバをカートリッジとして構成してもよい」と記載されているように、本願発明では、異なる処理を行う複数の種類のカートリッジが存在することが前提となっており、そのような異なる処理を行う複数のカートリッジのそれぞれが使用する引数（前記「Request req_obj」と前記「Response resp_obj」）は、当然ながら各カートリッジごとに異なる筈であって共通ではない筈であるから、前記段落【００４３】の「包括的なやり方」という記載と矛盾せずにカートリッジごとに異なる引数を授受する手法が不明である。したがって、発明の詳細な説明は、当業者が実施できる程度に明確かつ十分に記載されていない。 
 　　　　　　　　　　　　　　　　　　　　　　　　　（以上、理由Ｄ）
　 
 【理由Ｅ】この出願の下記の請求項に係る発明は、その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 
 　 
 　　　　　　　　　　　　　　　　　記 
 　 
 ・請求項１〜１７ 
 引用文献： 
 １．斎藤圭、「Ｏｒａｃｌｅ　ＷｅｂＳｅｒｖｅｒ　２．０」、月刊Ｏｒａｃｌｅ　ＬＩＦＥ（月刊オラクルライフ）、株式会社ビー・エヌ・エヌ、１９９６年１２月１３日、第１巻第７号（通巻第７号）、第４０〜４３頁 
 　 
 ２．斎藤淳（外１名），「OPOアプリケーションがブラウザ上で快適に動作　Oracle Web Server2.0とPower Objects2.0」，日経オープンシステム，日経ＢＰ社，１９９６年１２月１５日，第４５号，第１９７〜２０６頁，ISSN:0918-581X 
 　 
 備考： 
 　（１）請求項１０について 
 　引用文献１には、図面とともに以下の（1-1）〜（1-7）の記載が存在する（なお、下線部は便宜的に当審において付与したもの。以下同じ。）。 
 　 
 　（1-1）「次に、Oracle WebServer2.0の主要な３つのコンポーネントである、Web Listener、Web Request Broker、そしてWebServer SDKについて、くわしく解説する。 
 　■Oracle Web Listener 
 　
Web Listener
リクエスト
Web Request Broker
 　オラクルの
HTTP Server
エンジン
標準HTTP
リクエスト
HTTP Server
入ってくるHTTPリクエスト
WRB）にまかせてしまい、WRBで
リクエストを処理する
 　 
 　（1-2）「このような問題に対して、Oracle WebServer 2.0では、２つの基礎的なコンポーネントから成り立つものと考え、それを効果的に重ねるというアーキテクチャを採用している。基礎的な２つの層とは、
HTTPエンジン
Web Listener
 　 
 　（1-3）「■Web Request Broker 
 　
WRB（Web Request Broker）
WRB Dispatcher
WRB Service
 　 
 　（1-4）「・WRB Dispatcher 
 　
WRB Dispatcher
要求
仮想ディレクトリの設定とURLを比べる
WRB Execution（WRBX）
ディスパッチ
 　WRB Dispatcherは必要な数のWRB Serviceのインスタンスを動的に立ち上げるダイナミック・ロード・バランシングという機能を持っており、サーバ側は常に最適数のインスタンスを持つ仕組みになっている（インスタンスとはUNIXでいうプロセスに相当するものである）。また、サーバ管理者はWRB Serviceのインスタンスの最小値と最大値を決定することできる。これにより、従来のCGIのようにクライアントからの要求の数だけプロセスがサーバに上がりパフォーマンスを落とすというようなこともなく、サーバ側の負荷を管理者の意図するとおり、自動的かつ継続的に、最小に抑えることが可能となっている。 
 　
サーバ内でのプロセス間通信
CORBA2.0
複数ノードにわたって
 　 
 　（1-5）「・WRB Execution Engine 
 　
それぞれのWRB Service
共通の
WRBX
共有ライブラリ
オープンなWRBXのAPI
カスタマー
WRB API
コールバック関数をWRBXに登録する
 　 
 　（1-6）「・WRB API 
 　Oracle Web Server2.0では独自の拡張を行いたい開発者のため
WRBのオープンなAPI（WRB API）
カスタムカートリッジ
 　 
 　（1-7）「WebServer SDK 
 　Oracle WebServer 2.0の
カートリッジ
システム・カートリッジ
プログラム式カートリッジ
プログラム式カートリッジには、PL/SQL Agent、Java Interpreter、LiveHTMLがある
 　 
 　引用文献１の上記（1-1）に「次に、Oracle Web Server2.0の主要な３つのコンポーネントである、Web Listener、Web Request Broker、そしてWebServer SDKについて、くわしく解説する」と記載されているように、引用文献１にはOracle Web Server2.0の構成が記載されている。 
 　引用文献１の上記（1-6）には、「WRBのオープンなAPI（WRB API）」を用いて開発者は「カスタムカートリッジ」を作成するという趣旨の記載が存在する。前記「WRBのオープンなAPI（WRB API）」とは、上記（1-5）の「WRB API」、「オープンなWRBXのAPI」と同じものを指すと解され、上記（1-5）には、前記「WRB API」によって、開発者は基本的なコールバック関数を「WRB Execution Engine（WRBX）」に登録でき、また、前記「オープンなWRBXのAPI」を用いることで、カスタマーが各自の拡張機能を統合できるという趣旨の記載が存在し、また、上記（1-5）には、前記「WRB Execution Engine（WRBX）」と「実行時に動的にロードされる共有ライブラリ」とで「
それぞれの
共通の
 　次に、引用文献１の上記（1-4）には、「サーバ内でのプロセス間通信」が、CORBA2.0に準拠したプロトコルで複数ノードに渡って行われる旨の記載が存在し、前記記載に含まれる「サーバ」とは、前記「Oracle Web Server2.0」であると解され、このように前記「Oracle Web Server2.0」は複数のノードを有しているから、前記「WRB Execution Engine（WRBX）」及び前記「カスタムカートリッジ」並びに後述の「WRB Dispatcher」は、それら複数のノードのいずれかの上で実行されるものと解される。 
 　次に、引用文献１の図１には、４つの「WRBX」が図示され、それぞれの「WRBX」に対応付けて「ＰＬ／ＳＱＬ　Ａｇｅｎｔ」、「Ｊａｖａインタープリタ」、「Ｌｉｖｅ　ＨＴＭＬ　Ａｇｅｎｔ」、「カスタムカートリッジ」が図示されていることから、前記「カスタムカートリッジ」は、「ＰＬ／ＳＱＬ　Ａｇｅｎｔ」、「Ｊａｖａインタープリタ」、「Ｌｉｖｅ　ＨＴＭＬ　Ａｇｅｎｔ」と併存するものと解される。 
 　次に、引用文献１の上記（1-4）には、「WRB Dispatcher」が「要求」の種類に応じて相当する「WRB Execution（WRBX）」にその「要求」をディスパッチする旨の記載が存在し、前記「WRB Execution（WRBX）」と、前記「WRB Execution Engine（WRBX）」は、同じものを指すと解される。このように、前記「WRB Execution Engine（WRBX）」は前記「WRB Dispatcher」から要求を受け取るが、前記「WRB Execution Engine（WRBX）」自体は上述のように構造が共通であると解されるから、受け取った要求（この要求には、上述のように複数の種類がある）を処理するための要求の種類に応じた異なる処理アルゴリズムを前記「WRB Execution Engine（WRBX）」自体がその内部に有しているのではなく、該「WRB Execution Engine（WRBX）」は、上述のように該「WRB Execution Engine（WRBX）」に登録されているコールバック関数であるところの前記「カスタムカートリッジ」に、前記WRB APIを介して前記要求を送って処理させるもの（逆の言い方をすると、前記「カスタムカートリッジ」は、前記WRB APIを介して前記要求を受信するもの）と解される。 
 　次に、引用文献１のOracle Web Server2.0は、上記（1-4）に記載されているように、「WRB Serviceのインスタンスを動的に立ち上げ」るようになっている。前記「WRB Service」のそれぞれは、上述のように、WRB Execution Engine（WRBX）と、該WRB Execution Engine（WRBX）からWRB APIを用いて呼び出されるコールバック関数であるところの「カスタムカートリッジ」とが対になって１つの「WRB Service」を構成するものである。 
 　また、上記（1-4）には、「
WRB Dispatcher
要求
仮想ディレクトリの設定とURLを比べる
相当するWRB Execution（WRBX）
ディスパッチ
 　上記（1-4）の「
WRB Dispatcher
要求
仮想ディレクトリの設定とURLを比べる
Web Listener
リクエスト
Web Request Broker
HTTPエンジン
 Web Listener
HTTP Server
エンジン
標準HTTP
リクエスト
HTTP Server
入ってくるHTTPリクエスト
WRB）にまかせてしまい、WRBで
リクエストを処理する
WRB Dispatcher
要求
仮想ディレクトリの設定とURLを比べる
 　 
 　したがって、引用文献１には次の発明（以下、「引用発明」という。）が記載されているものと認められる。 
 　 
 　（引用発明） 
 　Oracle Web Server2.0のカスタムカートリッジにWRB APIによって呼び出されることにより処理を行わせるための方法であって、 
 　前記Oracle Web Server2.0内のプロセス間通信は、CORBA2.0に準拠したプロトコルで複数ノードに渡って行われるものであり、 
 　前記カスタムカートリッジは前記Oracle Web Server2.0において実行されるソフトウェアであってＰＬ／ＳＱＬ　Ａｇｅｎｔ、Ｊａｖａインタープリタ、Ｌｉｖｅ　ＨＴＭＬ　Ａｇｅｎｔと併存するものであり、 
 　前記Oracle Web Server2.0内の複数のノードのうちの少なくとも１つのノード上で前記カスタムカートリッジを実行するステップと、 
 　前記カスタムカートリッジと対をなしてWRB Serviceを構成するWRB Execution Engine（WRBX）を介して、前記Oracle Web Server2.0のWRB Dispatcherから前記カスタムカートリッジに要求を渡すステップとを含み、 
 　前記WRB Execution Engine（WRBX）と前記カスタムカートリッジとから成る前記WRB Serviceのインスタンスは動的に立ち上げられ、 
 　前記要求は、オープンな前記WRB APIを介して前記WRB Execution Engine（WRBX）から前記カスタムカートリッジに渡され、 
 　前記カスタムカートリッジと対をなしてWRB Serviceを構成するWRB Execution Engine（WRBX）に前記カスタムカートリッジから処理結果を渡すステップとを含み、 
 　前記要求はURLを含み、前記WRB Dispatcherは、URLを相当するWRB Execution （WRBX）と対応付ける仮想ディレクトリと当該URLとを比べ、 
 　前記仮想ディレクトリに基づいて、前記相当するWRB Execution（WRBX）が前記URLに対応付けられることを判断して、前記相当するWRB Execution（WRBX）を識別するデータを知るステップと、 
 　前記カスタムカートリッジは、前記Oracle Web Server2.0におけるカスタムカートリッジであり、該カスタムカートリッジは前記WRB APIを介して要求を受け取り、 
 　前記WRB Execution Engine（WRBX）および前記カスタムカートリッジ並びに前記WRB Dispatcherは、前記複数のノードのうちのいずれかの上で実行している、方法。 
 　 
 　次に、本願請求項１０記載の発明と、引用発明とを対比する。 
 　 
 　引用発明の「Oracle Web Server2.0」を上位概念化して把握すると、本願請求項１０記載の発明の「分散システム」に相当する。 
 　引用発明の「カスタムカートリッジ」を上位概念化して把握すると、本願請求項１０記載の発明の「カートリッジ」に相当する。 
 　次に、APIを用いて呼び出されたプログラムは、該APIにおいて取り決められているデータ受け渡し用の記憶領域（例えば、事前に決められたメモリ内のデータ領域又はスタック領域などにおける所定の記憶位置）から、該APIにおいて取り決められているデータ型（例えば１バイトの整数型など）で引数を受け取り、受け取った引数を、事前にプログラマによってプログラミングされたとおりのロジックに基づいて処理し、その処理の結果を前記APIにおいて取り決められているデータ型を用いて前記APIにおいて取り決められているデータ受け渡し用の記憶領域に書き込むことで処理結果を返すようになっており、該APIを用いて呼び出される側のプログラムは、前記データ受け渡し用の記憶領域から読み取った引数に基づいて計算した処理結果を前記データ受け渡し用の記憶領域に書き込むだけであり、呼び出し側のプログラム（前記データ受け渡し用の記憶領域に呼び出し前に引数を書き込み、前記データ受け渡し用の記憶領域から処理結果を読み出す側のプログラム）が、呼ばれる側のプログラムと同じ計算機で動作しているか否かには無関係に、前記事前にプログラマによってプログラミングされたとおりのロジックに基づいて処理を行うだけである（すなわち、分散を意識しない態様で処理を行う）ことは、当業者にとっての技術常識であるから、引用発明の「カスタムカートリッジにWRB APIによって呼び出されることにより処理を行わせる」が、本願請求項１０記載の発明の「カートリッジに分散を意識させない態様でオペレーションを行なわせる」に相当する。 
 　次に、引用発明の「ノード」が本願請求項１０記載の発明の「マシン」に相当するから、引用発明の「前記Oracle Web Server2.0内のプロセス間通信は、CORBA2.0に準拠したプロトコルで複数ノードに渡って行われるものであり」と、本願請求項１０記載の発明の「前記分散システムは、第１のマシンと第２のマシンとを含み、前記第１のマシンと前記第２のマシンとは異なるものであり」とは、ともに、「前記分散システムは、異なる複数のマシンを含み」という点において共通する。 
 　引用発明の「前記カスタムカートリッジは前記Oracle Web Server2.0において実行されるソフトウェアであってＰＬ／ＳＱＬ　Ａｇｅｎｔ、Ｊａｖａインタープリタ、Ｌｉｖｅ　ＨＴＭＬ　Ａｇｅｎｔと併存するものであり」を上位概念化して把握すると、本願請求項１０記載の発明の「前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり」に相当する。 
 　引用発明の「前記Oracle Web Server2.0内の複数のノードのうちの少なくとも１つのノード上で前記カスタムカートリッジを実行するステップ」を上位概念化して把握すると、本願請求項１０記載の発明の「ある特定のマシン上で前記カートリッジを実行するステップ」に相当する。 
 　引用発明の「前記カスタムカートリッジと対をなしてWRB Serviceを構成するWRB Execution Engine（WRBX）」を上位概念化して把握すると、本願請求項１０記載の発明の「前記カートリッジに関連付けられるカートリッジ実行エンジン」に相当する。 
 　引用発明の「前記Oracle Web Server2.0のWRB Dispatcher」を上位概念化して把握すると、本願請求項１０記載の発明の「前記分散システム内のディスパッチャ」に相当する。 
 　したがって、引用発明の「前記カスタムカートリッジと対をなしてWRB Serviceを構成するWRB Execution Engine（WRBX）を介して、前記Oracle Web Server2.0のWRB Dispatcherから前記カスタムカートリッジに要求を渡すステップ」と、本願請求項１０記載の発明の「前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内のディスパッチャから前記カートリッジに複数のリクエストを渡すステップ」とは、ともに、「前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内のディスパッチャから前記カートリッジにリクエストを渡すステップ」である点において共通する。 
 　次に、引用発明の「前記WRB Execution Engine（WRBX）と前記カスタムカートリッジとから成る前記WRB Serviceのインスタンスは動的に立ち上げられ」は、「動的に立ち上げ」を上位概念化して把握すると「制御する」と言えることから、本願請求項１０記載の発明の「前記カートリッジ実行エンジンは前記カートリッジの実行を制御し」に相当する。 
 　次に、引用発明の「前記要求は、オープンな前記WRB APIを介して前記WRB Execution Engine（WRBX）から前記カスタムカートリッジに渡され」と、本願請求項１０記載の発明の「前記リクエストは標準カートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され」とは、ともに、「前記リクエストはカートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され」である点において共通する。 
 　上述のように、引用発明の「前記カスタムカートリッジと対をなしてWRB Serviceを構成するWRB Execution Engine（WRBX）」を上位概念化して把握すると、本願請求項１０記載の発明の「前記カートリッジに関連付けられるカートリッジ実行エンジン」に相当するから、引用発明の「前記カスタムカートリッジと対をなしてWRB Serviceを構成するWRB Execution Engine（WRBX）に前記カスタムカートリッジから処理結果を渡すステップ」と、本願請求項１０記載の発明の「前記カートリッジに関連付けられる前記カートリッジ実行エンジンを介して返答を前記カートリッジから前記ディスパッチャに渡すステップ」とは、ともに、「前記カートリッジに関連付けられる前記カートリッジ実行エンジンに返答を前記カートリッジから渡すステップ」である点において共通する。 
 　本願の当初翻訳文の段落【００５７】には「必要とされる情報をディスパッチャに供給するため、仮想パスマネージャ２５０はＵＲＬをカートリッジにマッピングするメタデータ２５８を調べる」と記載されているように、「メタデータ」とはＵＲＬに対する対応付けを行うためのデータであるから、引用発明の「仮想ディレクトリ」も「メタデータ」の一種であるということができ、したがって、引用発明の「前記要求はURLを含み、前記WRB Dispatcherは、URLを相当するWRB Execution （WRBX）と対応付ける仮想ディレクトリと当該URLとを比べ、前記仮想ディレクトリに基づいて、前記相当するWRB Execution（WRBX）が前記URLに対応付けられることを判断して、前記相当するWRB Execution（WRBX）を識別するデータを知るステップ」と、本願請求項１０記載の発明の「前記複数のリクエストの各リクエストは、ユニフォーム・リソース・ロケータ（ＵＲＬ）を含み、前記ディスパッチャは、ＵＲＬをカートリッジにマッピングするメタデータを調べる仮想パスマネージャに対して、当該ＵＲＬを送信することにより、前記経路を選択し、前記仮想パスマネージャが、前記メタデータに基づいて、前記カートリッジが前記ＵＲＬにマッピングされることを判断して、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより、前記ディスパッチャに応答するステップ」とは、ともに、「前記リクエストは、ユニフォーム・リソース・ロケータ（ＵＲＬ）を含み、前記ディスパッチャは、ＵＲＬをマッピングするメタデータを調べることにより、前記経路を選択し、前記メタデータに基づいて、前記ＵＲＬにマッピングされることを判断して、マッピングされている対象を識別するデータを前記ディスパッチャが知るステップ」である点において共通する。 
 　引用発明の「前記カスタムカートリッジは、前記Oracle Web Server2.0におけるカスタムカートリッジであり、該カスタムカートリッジは前記WRB APIを介して要求を受け取り」と、本願請求項１０記載の発明の「前記カートリッジは、前記分散システムにおける複数のカートリッジの１つであり、前記複数のカートリッジの各々特定のカートリッジは、前記標準通信インターフェイスを介してリクエストを受信し」とは、ともに、「前記カートリッジは、前記分散システムにおけるカートリッジであり、前記カートリッジは、前記カートリッジインターフェイスを介してリクエストを受信し」である点において共通する（なお、本願請求項１０には、上記【理由Ａ】の（２）及び（３）並びに上記【理由Ｂ】の（１）及び（２）並びに上記【理由Ｃ】の（１）及び（２）において指摘した記載不備が存在しているので、現時点では本願請求項１０の「前記標準通信インターフェイス」は、正しくは「前記標準カートリッジインターフェイス」とすべき誤記と解釈して検討を行う。）。 
 　引用発明の「前記WRB Execution Engine（WRBX）および前記カスタムカートリッジ並びに前記WRB Dispatcherは、前記複数のノードのうちのいずれかの上で実行している」と、本願請求項１０記載の発明の「前記カートリッジ実行エンジンおよび前記カートリッジは前記第１のマシン上で実行しており、前記ディスパッチャは前記第２のマシン上で実行しており」とは、ともに、「前記カートリッジ実行エンジンおよび前記カートリッジ並びに前記ディスパッチャは、前記複数のマシンのいずれかの上で実行している」という点において共通する。 
 　 
 　したがって、引用発明と本願請求項１０記載の発明は、以下の点で一致し、また、相違する。 
 　 
 　（一致点） 
 　分散システムのカートリッジに分散を意識させない態様でオペレーションを行なわせるための方法であって、前記分散システムは、異なる複数のマシンを含み、前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり、 
 　ある特定のマシン上で前記カートリッジを実行するステップと、 
 　前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内のディスパッチャから前記カートリッジにリクエストを渡すステップとを含み、前記カートリッジ実行エンジンは、前記カートリッジの実行を制御し、前記リクエストはカートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され、 
 　前記カートリッジに関連付けられる前記カートリッジ実行エンジンに返答を前記カートリッジから渡すステップとを含み、 
 　　前記リクエストは、ユニフォーム・リソース・ロケータ（ＵＲＬ）を含み、前記ディスパッチャは、ＵＲＬをマッピングするメタデータを調べることにより、前記経路を選択し、 
 　前記メタデータに基づいて、前記ＵＲＬにマッピングされることを判断して、マッピングされている対象を識別するデータを前記ディスパッチャが知るステップと、 
 　前記カートリッジは、前記分散システムにおけるカートリッジであり、前記カートリッジは、前記カートリッジインターフェイスを介してリクエストを受信し、 
 　前記カートリッジ実行エンジンおよび前記カートリッジ並びに前記ディスパッチャは、前記複数のマシンのいずれかの上で実行している、方法。 
 　 
 　（相違点１） 
 　前記一致点における「異なる複数のマシン」が、本願請求項１０記載の発明では第１のマシンと第２のマシンであるのに対し、引用発明では「複数ノード」ではあるが、「第１のノードと第２のノード」ではない点。 
 　 
 　（相違点２） 
 　本願請求項１０記載の発明では、カートリッジに渡されるリクエストが複数であるのに対し、引用発明ではカスタムカートリッジに渡される要求が複数であるか否かは不明である点。 
 　 
 　（相違点３） 
 　前記一致点における「カートリッジインターフェイス」が、本願請求項１０記載の発明では「標準カートリッジインターフェイス」であるのに対し、引用発明のWRB APIは「標準」的なＡＰＩであるか否かは不明である点。 
 　 
 　（相違点４） 
 　前記一致点において前記カートリッジから前記カートリッジ実行エンジンに渡されている返答が、本願請求項１０記載の発明では前記カートリッジ実行エンジンを介して前記分散システムの前記ディスパッチャに渡されているのに対し、引用発明では、カスタムカートリッジからWRB Execution Engine（WRBX）に渡された処理結果は、前記WRB Dispatcherに渡されているか否かは不明である点。 
 　 
 　（相違点５） 
 　本願請求項１０記載の発明では、「メタデータ」はＵＲＬをカートリッジにマッピングするためのものであり、ディスパッチャがメタデータを調べる仮想パスマネージャにＵＲＬを送信し、仮想パスマネージャがメタデータに基づいてカートリッジがＵＲＬにマッピングされることを判断して、カートリッジを識別するデータをディスパッチャに送信することによりディスパッチャに応答するのに対し、引用発明では、仮想ディレクトリはＵＲＬを相当するWRB Execution（WRBX）と対応付けるためのものであり、WRB DispatcherがURLを仮想ディレクトリと比べることで、仮想ディレクトリに基づいて、前記相当するWRB Execution（WRBX）が前記URLに対応付けられることを判断して、前記相当するWRB Execution（WRBX）を識別するデータを知る点。 
 　 
 　（相違点６） 
 　本願請求項１０記載の発明ではカートリッジが複数存在するのに対し、引用発明ではカスタムカートリッジが複数存在するか否かは不明である点。 
 　 
 　（相違点７） 
 　本願請求項１０記載の発明では、前記カートリッジ実行エンジンおよび前記カートリッジは前記第１のマシン上で実行しており、前記ディスパッチャは前記第２のマシン上で実行しているのに対し、引用発明では、前記WRB Execution Engine（WRBX）および前記カスタムカートリッジ並びに前記WRB Dispatcherの三者は、前記複数のノードのうちのいずれかの上で実行しているものの、それら三者のうち、どれとどれが同じノードで実行されていて、どれとどれが異なるノードで実行されているのかは不明である点。 
 　 
 　（相違点８） 
 　本願請求項１０記載の発明では、各ステップが１つ以上のコンピュータプロセッサで実行されるのに対し、引用発明では各ステップが１つ以上のコンピュータプロセッサで実行されるか否かが不明である点。 
 　 
 　次に、上記相違点の各々について検討する。 
 　 
 　まず、上記相違点１及び７について検討する。 
 　引用発明は、「前記Oracle Web Server2.0内のプロセス間通信は、CORBA2.0に準拠したプロトコルで複数ノードに渡って行われるもの」である。したがって、引用発明のWRB DispatcherとWRB Execution Engine（WRBX）とを、異なるノードで実行させることは、当業者が必要に応じて適宜行えばよい事項に過ぎず、格別の困難性は認められない。 
 　また、引用発明のカスタムカートリッジはWRB Execution Engine（WRBX）と対をなしてWRB Serviceを構成するものであり、かつ、WRB Execution Engine（WRBX）はWRB APIを介してカスタムカートリッジに要求を渡す関係にあり、このような密接な関係にあるプログラム同士を同じ計算機で実行することは当該技術分野において慣用される手法であるから、引用発明のカスタムカートリッジとWRB Execution Engine（WRBX）とを同じノードで実行させることは、当業者が容易に想到し得た事項に過ぎない。 
 　したがって、上記相違点１及び７は、格別のものではない。 
 　 
 　次に、上記相違点２について検討する。 
 　要求を受け取って処理を行うものに対して複数の要求を渡すことは、周知技術であり、引用発明のカスタムカートリッジに渡す要求を複数とすることは、当業者が容易に想到し得た事項に過ぎない。 
 　したがって、上記相違点２は、格別のものではない。 
 　 
 　次に、上記相違点３について検討する。 
 　APIを標準化することは周知技術であるから、引用発明のWRB APIを標準化されたAPIとすることは、当業者が容易に想到し得た事項に過ぎない。 
 　したがって、上記相違点３は、格別のものではない。 
 　 
 　次に、上記相違点４について検討する。 
 　第１のプログラムからの処理要求を、第２のプログラムが中継して第３のプログラムに渡す場合に、第３の処理プログラムの処理結果を第２のプログラムが中継して第１のプログラムに返すことは周知技術であり、第１のプログラムが処理結果を利用するためには当然採用すべき構成に過ぎず、引用発明ではWRB Execution Engine（WRBX）を介してWRB Dispatcherからカスタムカートリッジに要求を渡しており、また、前記カスタムカートリッジから処理結果をWRB Execution Engine（WRBX）に渡しているから、その処理結果を更にWRB Execution Engine（WRBX）からWRB Dispatcherへ渡すことは、当業者が容易に想到し得た事項に過ぎない。 
 　したがって、上記相違点４は格別のものではない。 
 　 
 　次に、上記相違点５について検討する。 
 　引用発明では、WRB Execution Engine（WRBX）はカスタムカートリッジと対をなしているから、引用発明において仮想ディレクトリに基づいて、ＵＲＬに対応付けられた相当するWRB Execution（WRBX）を識別するデータを知ることは、間接的に、該WRB Execution（WRBX）と対をなすカスタムカートリッジを識別するデータを知ることに他ならない。 
 　第１のデータと第２のデータが対応するという対応関係と、第２のデータが第３のデータと対応するという対応関係が判明している場合に、それら２つの対応関係に基づいて第１のデータが第３のデータに対応するという対応関係を間接的に得る代わりに、第１のデータが第３のデータに対応するという対応関係を直接的に表現するデータを設けるようにすることは周知技術であるから、引用発明の仮想ディレクトリにおいて、ＵＲＬに対応付けてWRB Execution（WRBX）を識別するデータを格納する代わりに、該WRB Execution（WRBX）と対をなすカスタムカートリッジを識別するデータをＵＲＬに対応付けて格納するようにすることは、当業者が容易に想到し得た事項に過ぎない。 
 　また、一般に、第１のプログラムが第１の情報に基づいて第２の情報を調べて第３の情報を知る手法として、第１のプログラムが第２のプログラムに第１の情報を送り、第２のプログラムが受け取った第１の情報に基づいて第２の情報を調べて第３の情報を得て、得られた第３の情報を第２のプログラムが第１のプログラムに送り返す手法（例えば、ディレクトリサーバや、検索エンジンなど）は周知技術であり、この周知技術に基づいて、引用発明においてWRB DispatcherがURLを仮想ディレクトリと比べる代わりに、WRB DispatcherがURLを別のプログラムへ送り、前記別のプログラムが受け取ったURLに基づいて仮想ディレクトリを調べてＵＲＬに対応付けられているデータを得て、得られたデータを前記別のプログラムがWRB Dispatcherへ送り返す構成とすることは、当業者が容易に想到し得た事項に過ぎない。そして、前記別のプログラムをどのような名前で呼ぶかは当業者が必要に応じて適宜決定すればよい事項に過ぎず、引用発明の「仮想ディレクトリ」が、実際にはＵＲＬに含まれる仮想的なパスを管理するためのものであることは、後述の【補足説明】に記載するように引用文献２の記載から明らかであるから、そのような仮想的なパスを管理するための引用発明の仮想ディレクトリを調べる前記「別のプログラム」の名称を「仮想パスマネージャ」とすることも、当業者が容易に想到し得た事項に過ぎない。 
 　 
 　　【補足説明】 
 　引用発明の「仮想ディレクトリ」とは、引用文献１の「Oracle WebServer 2.0」という製品を説明する記事の中に登場する用語であるが、同じ「Oracle WebServer 2.0」という製品を説明する記事が掲載されている引用文献２の第２０１頁には、「仮想ディレクトリ名で処理を呼ぶ」という題名がついた節（その一部を、（2-1）及び（2-2）として後で挙げる。）が存在し、引用文献２の「仮想ディレクトリ」と引用発明（引用文献１）の「仮想ディレクトリ」は同じものを指すと解される。 
 　引用文献２には、 
 　（2-1）「
仮想ディレクトリ
 　OWSは、WWWブラウザから送られてきた
URL
パス名
バーチャル・ディレクトリ
図２
URL
/books/owa/
パス名
WRB経由でカートリッジを起動し
 　 
 　（2-2）「登録したPL/SQLプログラムをWWWブラウザ側から実行させるには、PL/SQLカートリッジの起動用の
バーチャル・ディレクトリ
プロシージャ名
プロシージャ「main」を起動するには
books/owa/main
 　 
 と記載され、引用文献２の第２０１頁の図２には「バーチャル・ディレクトリ設定」として「/books/owa/　→　エージェントOWA」と図示されているように、「Oracle WebServer 2.0」における「仮想ディレクトリ」とは、ＵＲＬ内のパス名（例えば「/books/owa/」というパス名）と、起動すべきカートリッジとを対応付けるものであり、前記「/books/owa/」というパス名はファイルシステム内のファイルと対応付けられているのではなく、プログラムと対応付けられている点において、前記「/books/owa/」というパス名は仮想的なパス名であるということができ、仮想ディレクトリとは、そのような仮想的なパス名を管理するための情報である。 
 　　　　　　　　　　　　　　　　　　　　　　　　（以上、補足説明） 
 　 
 　したがって、上記相違点５も格別のものではない。 
 　 
 　次に、上記相違点６について検討する。 
 　呼び出されて処理を行うプログラムを複数設けることは周知技術であるから、引用発明に存在するカスタムカートリッジを複数とすることは、当業者が容易に想到し得た事項に過ぎない。 
 　したがって、上記相違点６は、格別のものではない。 
 　 
 　次に、上記相違点８について検討する。 
 　「ノード」が、１つ以上のコンピュータプロセッサを有する計算機で実現され、該１つ以上のコンピュータプロセッサによって処理ステップを実行することは周知技術であり、この周知技術を用いて引用発明のノードを１つ以上のコンピュータプロセッサを有する計算機で実現し、該１つ以上のコンピュータプロセッサによって引用発明の各ステップを実行するようにすることは、当業者が容易に想到し得た事項に過ぎない。 
 　したがって、上記相違点８は、格別のものではない。 
 　 
 　以上述べたように、相違点１乃至８はいずれも格別のものではなく、本願請求項１０記載の発明は引用文献１記載の引用発明に上述の周知技術の各々を適用することによって、当業者が容易に想到し得たものである。 
 　そして、当該構成の採用によって奏される作用効果も、当業者であれば当然に予測し得る程度のものであって、格別顕著なものではない。 
 　よって、本願請求項１０記載の発明は、引用文献１記載の引用発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許を受けることができない。 
…（中略）… 　 
 　　　　　　　　　　　　　　　　　　　　　　　　（以上、理由Ｅ） 」
　
第５．平成２２年３月４日付け最後の拒絶理由通知のうち、【理由Ａ】〜【理由Ｄ】（２）の検討
　「第４．平成２２年３月４日付け最後の拒絶理由通知で通知した拒絶理由」にて示した拒絶理由のうち、【理由Ａ】の（１）〜（６）、【理由Ｂ】の（１）〜（３）、【理由Ｃ】の（１）〜（３）、【理由Ｄ】の（１）〜（２）は、いずれも妥当である。そして、「第２．補正却下の決定」にて示したように、平成２２年９月９日付け手続補正（本件補正）は却下された。そのため、拒絶理由は解消していない。
　
　なお、同拒絶理由通知で通知した拒絶理由のうち、【理由Ａ】の（１）〜（６）、【理由Ｂ】の（１）〜（３）、【理由Ｃ】の（１）〜（３）、【理由Ｄ】の（１）〜（２）に対応して、請求人は平成２２年９月９日付けで手続補正（本件補正）を行い、請求項の記載のうち、拒絶理由として指摘された箇所を削除することまたは異なる記載に変更することを内容とした補正を行うことにより拒絶理由を解消することを意図している。その意図は同日付けで提出された意見書においても下記のとおり言明されている。
　
「第３　拒絶の理由Ａ（特許法第３６条第６項第２号）が解消していることについて
　　（３−１）　記（１）について
　審判官殿は、請求項１に記載されている「第１のマシン」、「第２のマシン」と、請求項１に記載されている「１つ以上のコンピュータプロセッサ」の関係が不明であり、請求項１の記載は明確ではない旨の見解、および、同様の記載を有する請求項１０，１５の記載も明確でない旨の見解、これらの請求項を引用する他の請求項についても、同様の記載不備がある旨の見解を示されました。
　これに対して出願人は、当該記載を、「
複数のマシンのコンピュータプロセッサの一部
複数のマシンのうちの第１のマシン
前記複数のマシンのうちの第２のマシンのコンピュータプロセッサ
　　（３−２）　記（２）について
　審判官殿は、請求項１０における「前記標準通信インターフェイス」との記載が不備である旨の見解を示されました。
　これに対して出願人は、当該記載を、「前記標準カートリッジインターフェイス」との記載に補正致しました。補正後の当該記載は、請求項１０において既に記載されているものでありますので、ご指摘の不備は解消したものと思料致します。
　　（３−３）　記（３）について
　審判官殿は、請求項１０における「標準通信インターフェイス」と、同請求項の「標準カートリッジインターフェイス」との関係が不明であり、請求項１０の記載は明確ではない旨の見解を示されました。
　これに対して出願人は、「標準通信インターフェイス」との記載を「標準カートリッジインターフェイス」との記載に補正致しましたので、ご指摘の不備は解消したものと思料致します。
　　（３−４）　記（４）について
　審判官殿は、請求項１０における「前記経路」との記載が不備である旨の見解を示されました。
　これに対して出願人は、「前記」との記載を削除しましたので、ご指摘の不備は解消したものと思料致します。
　　（３−５）　記（５）について
　審判官殿は、請求項１０における「前記経路」との記載について、何の経路であるのか不明である旨の見解を示されました。
　これに対して出願人は、当該記載を、「
前記特定のリクエストに対応する処理を実行するカートリッジへの経路
　　（３−６）　記（６）について
　審判官殿は、請求項８における「前記カートリッジの各々は標準カートリッジインターフェイスを介して呼出される「exec()」ルーチンを含み」、「前記複数のカートリッジ内の前記「exec()」ルーチン」、「特定のカートリッジ内のexec()ルーチン」との記載が明確でない旨の見解、および、同様の記載を有するその他の請求項についても、同様の見解を示されました。
　これに対して出願人は、当該記載を削除しましたので、ご指摘の不備は解消したものと思料致します。
　
第４　拒絶の理由Ｂ（特許法第１７条の２第３項）が解消していることについて
　　（４−１）　記（１）について
　審判官殿は、請求項１０、１５の「標準通信インターフェイス」との記載が、当初翻訳文にも当初翻訳図面にも記載されておらず、当初翻訳文又は当初翻訳図面の記載から自明でもない旨の見解、請求項１０、１５を引用して記載されているその他の請求項についても同様の見解を示されました。
　これに対して出願人は、当該記載を「標準
カートリッジ
　　（４−２）　記（２）について
　審判官殿は、請求項１０、１５について、「標準カートリッジインターフェイス」とは別に「標準通信インターフェイス」が存在し、該「標準通信インターフェイス」を用いて「カートリッジ」が「リクエスト」を「受信」する旨の記載が存在するが、そのようなことは当初翻訳文にも当初翻訳図面にも記載されておらず、当初翻訳文又は当初翻訳図面の記載から自明でもない旨の見解を示されました。
　これに対して出願人は、当該「標準通信インターフェイス」との記載を、「標準カートリッジインターフェイス」との記載に補正致しましたので、ご指摘の不備は解消したものと思料致します。
　　（４−３）　記（３）について
　審判官殿は、請求項１０における「前記複数のリクエストの各リクエストは、ユニフォーム・リソース・ロケータ（ＵＲＬ）を含み」という記載、および、「前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内のディスパッチャから前記カートリッジに複数のリクエストを渡すステップとを含み、前記カートリッジ実行エンジンは前記カートリッジの実行を制御し、前記リクエストは標準カートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され」という記載について、「ユニフォーム・リソース・ロケータ（ＵＲＬ）」そのものが「ディスパッチャ」から「カートリッジ実行エンジン」を介して「カートリッジ」に渡されるという趣旨と、「ユニフォーム・リソース・ロケータ（ＵＲＬ）」そのものが「標準カートリッジインターフェイス」を介して「カートリッジ実行エンジン」から「カートリッジ」に渡されるという趣旨とは、当初翻訳文にも当初翻訳図面にも記載されておらず、当初翻訳文及び当初翻訳図面の記載から自明でもないため、請求項１０についてした補正、および、同様の記載を有する請求項１〜９，１１〜１７の補正が、当初翻訳文又は当初翻訳図面に記載した事項の範囲内で行われていない旨の見解を示されました。
　これに対して出願人は、当該記載を削除しましたので、ご指摘の不備は解消したものと思料致します。
　
第５　拒絶の理由Ｃ（特許法第３６条第６項第１号）が解消していることについて
　　（５−１）　記（１）について
　審判官殿は、請求項１０、１５の「標準通信インターフェイス」に対応する記載が発明の詳細な説明に記載されていない旨の見解を示されました。
　これに対して出願人は、当該記載を「標準カートリッジインターフェイス」との記載に補正致しました。補正後の記載は、発明の詳細な説明に記載されていますので、ご指摘の不備は解消したものと思料致します。
　　（５−２）　記（２）について
　審判官殿は、請求項１０、１５における、「標準カートリッジインターフェイス」とは別に「標準通信インターフェイス」が存在し、該「標準通信インターフェイス」を用いて「カートリッジ」が「リクエスト」を「受信」する旨の記載について、これに対応する記載が発明の詳細な説明に記載されていない旨の見解を示されました。
　これに対して出願人は、「標準通信インターフェイス」との記載を「標準カートリッジインターフェイス」との記載に補正致しました。補正後の記載内容に対応する記載は、発明の詳細な説明に記載されておりますので、ご指摘の不備は解消したものと思料致します。
　　（５−３）　記（３）について
　審判官殿は、請求項１〜１７について、［理由Ｂ］の（３）で指摘された趣旨の記載が発明の詳細な説明には記載されていない旨の見解を示されました。
　これに対して出願人は、「前記複数のリクエストの各リクエストは、ユニフォーム・リソース・ロケータ（ＵＲＬ）を含み」に係る記載を削除しましたので、各請求項は、ご指摘の趣旨を含まなくなります。これにより、ご指摘の不備は解消したものと思料致します。
　
第６　拒絶の理由Ｄ（特許法第３６条第４項）が解消していることについて
　　（６−１）　記（１）について
　審判官殿は、請求項１０等における「標準通信インターフェイス」との記載について、「標準通信インターフェイス」の具体的な実現手法が、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない旨の見解を示されました。
　これに対して出願人は、当該記載を削除しましたので、ご指摘の不備は解消したものと思料致します。
　　（６−２）　記（２）について
　審判官殿は、請求項１０等について、「標準カートリッジインターフェイス」とは別に「標準通信インターフェイス」が存在し、該「標準通信インターフェイス」を用いて「カートリッジ」が「リクエスト」を「受信」する旨の記載が存在するが、この記載の具体的な実現手法が、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない旨の見解を示されました。
　これに対して出願人は、当該記載を削除しましたので、ご指摘の不備は解消したものと思料致します。」
　
　つまり、平成２２年３月４日付け最後の拒絶理由通知で通知した拒絶理由のうち、【理由Ａ】の（１）〜（６）、【理由Ｂ】の（１）〜（３）、【理由Ｃ】の（１）〜（３）、【理由Ｄ】の（１）〜（２）については、請求人は同意見書において、平成２２年９月９日付け手続補正（本件補正）を前提とした主張をするのにとどまるものであり、拒絶理由の妥当性については反論していない。そして、平成２２年９月９日付け手続補正（本件補正）は却下されたのであるから、請求人の同意見書による上記主張は採用することができない。
　
　よって、【理由Ａ】の（１）〜（６）で示されるように、本願は、平成１４年法律第２４号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第３６条第６項第２号の規定を満たさない。また、【理由Ｂ】の（１）〜（３）で示されるように、平成２２年２月１日付け手続補正は、平成１４年法律第２４号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１８４条の１２第２項で読み替える同法第１７条の２第３項の規定に違反する。さらに、【理由Ｃ】の（１）〜（３）で示されるように、本願は、平成１４年法律第２４号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第３６条第６項第１号の規定を満たさない。加えて、【理由Ｄ】の（１）〜（２）で示されるように、本願は平成１４年法律第２４号改正附則第２条第１項によりなお従前の例によるとされる同法による改正前の特許法第３６条第４項の規定を満たさない。
　
第６．平成２２年３月４日付け最後の拒絶理由通知のうち、【理由Ｄ】（３）の検討
　「第２．補正却下の決定」の「２の３の１．特許法第３６条第４項の規定を満たすか否かの検討」の項目にて検討したことと、「第４．平成２２年３月４日付け最後の拒絶理由通知で通知した拒絶理由」にて示した拒絶理由のうち、【理由Ｄ】の（３）は同様のものである。また、この拒絶理由に対して、請求人は平成２２年９月９日付け意見書において主張しているが、当該主張は採用できないことも「第２．補正却下の決定」の「２の３の１．特許法第３６条第４項の規定を満たすか否かの検討」の項目にて示したとおりである。そのため、【理由Ｄ】の（３）の拒絶理由は妥当である。
　よって、【理由Ｄ】の（３）で示されるように、本願は平成１４年法律第２４号改正附則第２条第１項によりなお従前の例によるとされる同法による改正前の特許法第３６条第４項の規定を満たさない。
　
第７．平成２２年３月４日付け最後の拒絶理由通知のうち、【理由Ｅ】の検討
　平成２２年３月４日付け最後の拒絶理由通知のうち、【理由Ｅ】にて、斎藤圭，”Oracle WebServer 2.0”，Oracle LIFE，株式会社ビー・エヌ・エヌ，１９９６年１２月１３日，第１巻，第７号，Pages：４０−４３（以下、「引用文献１」という。）と、斎藤淳，外１名，”OPOアプリケーションがブラウザ上で快適に動作　Oracle Web Server2.0とPower Objects2.0”，日経オープンシステム，日経ＢＰ社，１９９６年１２月１５日，第４５号，Pages：１９７−２０６（以下、「引用文献２」という。）を引用文献として取り上げている。
　引用文献１には、同拒絶理由通知の【理由Ｅ】の「（１）請求項１０について」における（１−１）乃至（１−７）のとおりの記載があり、引用文献１には、同【理由Ｅ】の「（１）請求項１０について」において引用発明として認定されたとおりの発明が記載されていると認められる。本願発明と引用発明とを対比すると、同【理由Ｅ】の「（１）請求項１０について」において（一致点）として記載されたとおりの点で両者は一致し、同【理由Ｅ】の「（１）請求項１０について」において（相違点１）乃至（相違点８）と記載されたとおりの点で両者は相違する。そして、本願発明と引用発明の相違点について検討すると、同【理由Ｅ】の「（１）請求項１０について」において相違点１乃至相違点８について検討したとおり、いずれの相違点も格別のものではない。
　したがって、本願発明は、引用文献１記載の引用発明と周知技術に基いて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により、特許を受けることができない。
　
　なお、本願発明は、平成２２年３月４日付け最後の拒絶理由通知における「本願請求項１０記載の発明」に相当するものであるところ、同拒絶理由通知に応答する平成２２年９月９日付け意見書において、「本願請求項１０記載の発明」に対する同拒絶理由通知の【理由Ｅ】に対する意見として、請求人は下記のように主張している。
　
「第７　拒絶の理由Ｅ（特許法第２９条第２項）が解消していることについて
　　（７−１）　オラクル・ウェブサーバ（Oracle WebServer）2.0のディスパッチャ
　引用文献１は、ウェブサーバを開示しており、そこには、一つのWRBディスパッチャがあります。このWRBディスパッチャは、入来する各リクエストのタイプを判断して、対応するWRBExecution（WRBX）に対してＩＰＣメカニズムを介して当該リクエストを送信します（引用文献１の第４２ページ左欄「Web Request Broker」〜右第４行目）。加えて、WRBディスパッチャは、WRBサービスインスタンスの数を制御し維持します（第４２ページ中欄第８〜２１行）。
　しかしながら、Oracle WebServer 2.0で記述されるシステムは、複数のディスパッチャを取り入れるように構成を変更することができません。引用文献１に開示された各ディスパッチャは、カートリッジインスタンスの数を個別に管理しますので、あるカートリッジが、他のディスパッチャによって現在用いられているカートリッジを削除したり、二つのカートリッジが同時に同じカートリッジを用いようとするような問題が生じます。それゆえに、単一のディスパッチャを用いるOracle WebServer 2.0で記述されたシステムによって必要とされず、また予期すらされない複数のディスパッチャを用いるときに、中央制御のためのマネージャが必要となります。
　　（７−２）　本願発明と引用文献との対比
…（中略）…
　　　　（７−２−３）　請求項１０
　（ａ）　補正後の独立の請求項１０に係る発明は、「
前記複数のディスパッチャは、リソースマネージャにリクエストを送信し、前記リソースマネージャは、一つの特定のディスパッチャからの特定のリクエストに応じて、前記特定のリクエストに対応する処理を実行する、前記複数のディスパッチャによって使用されていないカートリッジへの経路を選択し、前記カートリッジが見つかった場合に、前記特定のディスパッチャのための当該カートリッジを予約
　（ｂ）　これに対して、引用文献１，２のいずれも、当該構成に相当する技術的特徴を開示も示唆もしておりません。当該示唆がないことは、たとえば、引用文献１の上記開示内容からも明らかです。また、当該技術的特徴は、周知慣用技術でもありません。そのため、当業者といえども、引用文献１，２に基づいて、個別的にも又は組み合わせによっても、さらには周知慣用技術を付加しても、当該構成を導くことはできません。したがいまして、補正後の請求項１０に係る発明は、当業者が引用文献１，２に基づいて容易に想到し得ない発明であると思料致します。」
　
　しかしながら、請求人の同意見書における上記主張は、平成２２年９月９日付け手続補正（本件補正）による補正後の請求項１０の記載を根拠としたものである。「第２．補正却下の決定」にて平成２２年９月９日付け手続補正（本件補正）は却下されたのであるから、上記主張には請求項１０の記載における根拠がない。特に、上記主張にあるような、ディスパッチャを複数備えること、及び、リソースマネージャを備えることは、本願発明における発明特定事項には含まれない。よって、上記主張を採用することはできない。
　
第８．むすび
　「第５．平成２２年３月４日付け最後の拒絶理由通知のうち、【理由Ａ】〜【理由Ｄ】（２）の検討」の項目で示したように、本願は、平成１４年法律第２４号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第３６条第６項第２号の規定を満たさないから、本願は特許を受けることができない。
　同様に、平成２２年２月１日付け手続補正は、平成１４年法律第２４号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第１８４条の１２第２項で読み替える同法第１７条の２第３項の規定に違反するから、本願は特許を受けることができない。
　同様に、本願は、平成１４年法律第２４号改正附則第３条第１項によりなお従前の例によるとされる同法による改正前の特許法第３６条第６項第１号の規定を満たさないから、本願は特許を受けることができない。
　同様に、本願は平成１４年法律第２４号改正附則第２条第１項によりなお従前の例によるとされる同法による改正前の特許法第３６条第４項の規定を満たさないから、本願は特許を受けることができない。
　また、「第６．平成２２年３月４日付け最後の拒絶理由通知のうち、【理由Ｄ】（３）の検討」の項目で示したように、本願は平成１４年法律第２４号改正附則第２条第１項によりなお従前の例によるとされる同法による改正前の特許法第３６条第４項の規定を満たさないから、本願は特許を受けることができない。
　さらに、「第７．平成２２年３月４日付け最後の拒絶理由通知のうち、【理由Ｅ】の検討」の項目で示したように、本願の請求項１０に係る発明は、その優先日前に日本国内又は外国において頒布された刊行物に記載された発明に基いて、当業者が容易に発明をすることができたものであるから、他の請求項について検討をするまでもなく、本願は特許法第２９条第２項の規定により特許を受けることができない。
　　
　よって、結論のとおり審決する。