• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 特174条1項 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 4項4号特許請求の範囲における明りょうでない記載の釈明 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 4号2号請求項の限定的減縮 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 特36条4項詳細な説明の記載不備 特許、登録しない(前置又は当審拒絶理由) G06F
審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F
管理番号 1241220
審判番号 不服2006-26565  
総通号数 141 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2011-09-30 
種別 拒絶査定不服の審決 
審判請求日 2006-11-24 
確定日 2011-08-03 
事件の表示 特願2000-519524「分散を意識させない態様で分散ソフトウェア開発を容易にするための方法およびシステム」拒絶査定不服審判事件〔平成11年 5月14日国際公開、WO99/23785、平成13年11月13日国内公表、特表2001-522114〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1.手続の経緯
本願は、
1998年10月28日(パリ条約による優先権主張外国庁受理1997年10月31日、アメリカ合衆国)の出願であって、
平成12年4月28日付けで特許法第184条の4第1項の規定による千九百七十年六月十九日にワシントンで作成された特許協力条約(以下、単に「条約」という。)第3条(2)に規定する明細書、請求の範囲、図面及び要約の日本語による翻訳文(以下、「当初翻訳文」という。)が提出されるとともに、特許法第184条の8第1項の規定による条約第34条(2)(b)の規定に基づき提出された補正書の日本語による翻訳文が提出され、
平成13年4月16日付けで手続補正がなされ、
平成17年1月27日付けで最初の拒絶理由通知(同年2月1日発送)がなされ、
同年7月29日付けで意見書が提出され、
同年9月26日付けで最初の拒絶理由通知(同年11月22日発送)がなされ、
平成18年5月19日付けで意見書が提出されるとともに、手続補正がなされ、
同年8月17日付けで拒絶査定(同年同月29日発送)がなされ、
同年11月24日付けで審判請求がなされ、
同年12月22日付けで手続補正がなされ、
平成19年3月7日付けで審査官より特許法第164条第3項の規定による前置報告がなされ、
平成20年11月25日付けで当審より審尋(同年12月2日発送)がなされ、
この審尋に対して、平成21年5月27日付けで回答書が提出され、
同年7月29日付けで当審より平成18年12月22日付けの手続補正を却下する旨の補正の却下の決定(平成21年8月18日発送)がなされるとともに、同年7月29日付けで当審より最初の拒絶理由通知(同年8月4日発送)がなされ、
平成22年2月1日付けで意見書が提出されるとともに、手続補正がなされ、
同年3月4日付けで当審より最後の拒絶理由通知(同年同月9日発送)がなされ、
同年9月9日付けで意見書が提出されるとともに、手続補正がなされたものである。

第2.補正却下の決定
[補正却下の決定の結論]
平成22年9月9日付けの手続補正を却下する。

[理由]
2の1.本件補正
平成22年9月9日付けの手続補正(以下、「本件補正」という。)の内容は、
同年2月1日付けの手続補正により補正された特許請求の範囲の記載
「 【請求項1】 分散システムにおいてオペレーションを実行するための方法であって、前記分散システムは、第1のマシンと第2のマシンとを含み、前記第1のマシンと前記第2のマシンとは異なるものであり、
ディスパッチャを前記第1のマシン上で実行するステップを含み、前記ディスパッチャはリクエストを受信し、前記リクエストに対応する処理を実行するカートリッジに対する経路を選択し、前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり、
前記リクエストはユニフォーム・リソース・ロケータ(URL)を含み、前記ディスパッチャは、URLをカートリッジにマッピングするメタデータを調べる仮想パスマネージャに対して、当該URLを送信することにより、前記経路を選択し、
前記仮想パスマネージャが、前記メタデータに基づいて、前記カートリッジが前記URLにマッピングされることを判断して、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより、前記ディスパッチャに応答するステップと、
カートリッジ実行エンジンを第2のマシン上で実行するステップを含み、前記カートリッジ実行エンジンは前記カートリッジの実行を制御し、
前記ディスパッチャが、前記第1のマシンにおいて実現されるウェブリスナから、前記オペレーションの実行をリクエストする第1のメッセージを受取るステップを含み、前記第1のメッセージは、前記ウェブリスナがブラウザからブラウザリクエストを受取ったことに応答して前記ディスパッチャに送られたものであり、前記ブラウザは前記分散システムと通信するクライアント装置において実現され、
前記第1のメッセージに応答して、前記ディスパッチャが第2のメッセージを前記カートリッジ実行エンジンへマシン間通信機構を介して送るステップと、
前記第2のメッセージに応答して、前記カートリッジ実行エンジンが第3のメッセージを標準カートリッジインターフェイスを介して、前記第2のマシン上で実行されているカートリッジに渡すステップとを含み、前記カートリッジは、各々が前記標準カートリッジインターフェイスを介して呼出されるルーチンを含む複数のカートリッジのうちの1つであり、さらに
前記第3のメッセージを受取ったことに応答して、前記カートリッジが前記オペレーションを実行するステップを含み、
各前記ステップは、1つ以上のコンピュータプロセッサで実行される、方法。
【請求項2】 前記オペレーションを実行した後に、前記カートリッジが第4のメッセージを前記カートリッジ実行エンジンに渡すステップと、
前記第4のメッセージに応答して、前記カートリッジ実行エンジンが第5のメッセージを前記ディスパッチャに送るステップと、
前記第5のメッセージに応答して、前記ディスパッチャが第6のメッセージを前記ウェブリスナに送り、前記ウェブリスナがこれを前記ブラウザに転送するステップとをさらに含む、請求項1に記載の方法。
【請求項3】 前記ディスパッチャが第2のメッセージをカートリッジ実行エンジンへ送る前記ステップは、前記ディスパッチャが第2のメッセージをオブジェクトリクエストブローカを介してカートリッジ実行エンジンに送ることによって実行される、請求項2に記載の方法。
【請求項4】 前記カートリッジ実行エンジンが第5のメッセージを前記ディスパッチャに送る前記ステップは、前記カートリッジ実行エンジンが第5のメッセージを前記オブジェクトリクエストブローカを介して前記ディスパッチャに送ることによって実行される、請求項3に記載の方法。
【請求項5】 前記カートリッジ実行エンジンが第3のメッセージをカートリッジに渡す前記ステップは前記カートリッジ実行エンジンが前記カートリッジ内のルーチンを呼出すことによって行なわれ、
前記カートリッジが第4のメッセージを前記カートリッジ実行エンジンに渡す前記ステップは、前記カートリッジ内で呼出された前記ルーチンから戻ることによって行なわれる、請求項2に記載の方法。
【請求項6】 前記カートリッジは共用ライブラリであり、
前記カートリッジ実行エンジンが第3のメッセージを前記カートリッジに渡す前記ステップは前記カートリッジが前記共用ライブラリ内のルーチンを呼出すステップを含む、請求項1に記載の方法。
【請求項7】 前記カートリッジ実行エンジンを実行時に前記カートリッジに動的にリンクするステップをさらに含む、請求項6に記載の方法。
【請求項8】 ブラウザリクエストに関連するオペレーションを行なうためのシステムであって、
複数のウェブリスナに結合される複数のディスパッチャを含み、前記複数のディスパッチャの各ディスパッチャはリクエストを受信し、前記リクエストに対応する処理を実行するカートリッジへの経路を選択し、前記カートリッジは前記システムにおいて1つ以上のプロセッサによって実行されるコードのモジュールであり、
マシン間通信機構と、
複数のカートリッジとを含み、前記カートリッジの各々は標準カートリッジインターフェイスを介して呼出される「exec()」ルーチンを含み、前記標準カートリッジインターフェイスを介して受取った呼出に応答して別々のカートリッジが別々のオペレーションを行ない、さらに
前記マシン間通信機構を介して前記複数のディスパッチャと通信し、かつ前記標準カートリッジインターフェイスを介して前記複数のカートリッジ内の前記「exec()」ルーチンを呼出すことによって、前記複数のカートリッジと通信する複数のカートリッジ実行エンジンを含み、
前記リクエストに含まれるユニフォーム・リソース・ロケータ(URL)に前記カートリッジがマッピングされることを、メタデータに基づいて判断し、かつ、前記カートリッジを識別するデータを前記ディスパッチャに送信することによって、前記ディスパッチャに応答する仮想パスマネージャを含み、
前記複数のディスパッチャの各ディスパッチャは、オペレーションを行なうのにある特定のカートリッジを必要とするブラウザリクエストをウェブリスナが受取ったことに応答して、前記複数のカートリッジ実行エンジンのある特定のカートリッジ実行エンジンへ第1のメッセージを前記マシン間通信機構を介して送るよう構成されており、
前記ある特定のカートリッジ実行エンジンは、前記第1のメッセージに応答して、前記ある特定のカートリッジ内のexec()ルーチンを前記標準カートリッジインターフェイスを介して呼出すよう構成されており、
前記ディスパッチャは、前記URLを前記仮想パスマネージャに送信することにより、前記経路を選択し、
前記メタデータは、URLをカートリッジに対応付ける、システム。
【請求項9】 前記マシン間通信機構はオブジェクトリクエストブローカである、請求項8に記載のシステム。
【請求項10】 分散システムのカートリッジに分散を意識させない態様でオペレーションを行なわせるための方法であって、前記分散システムは、第1のマシンと第2のマシンとを含み、前記第1のマシンと前記第2のマシンとは異なるものであり、前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり、
ある特定のマシン上で前記カートリッジを実行するステップと、
前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内のディスパッチャから前記カートリッジに複数のリクエストを渡すステップとを含み、前記カートリッジ実行エンジンは前記カートリッジの実行を制御し、前記リクエストは標準カートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され、
前記カートリッジに関連付けられる前記カートリッジ実行エンジンを介して返答を前記カートリッジから前記ディスパッチャに渡すステップとを含み、
前記複数のリクエストの各リクエストは、ユニフォーム・リソース・ロケータ(URL)を含み、前記ディスパッチャは、URLをカートリッジにマッピングするメタデータを調べる仮想パスマネージャに対して、当該URLを送信することにより、前記経路を選択し、
前記仮想パスマネージャが、前記メタデータに基づいて、前記カートリッジが前記URLにマッピングされることを判断して、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより、前記ディスパッチャに応答するステップと、
前記カートリッジは、前記分散システムにおける複数のカートリッジの1つであり、
前記複数のカートリッジの各々特定のカートリッジは、前記標準通信インターフェイスを介してリクエストを受信し、
前記カートリッジ実行エンジンおよび前記カートリッジは前記第1のマシン上で実行しており、
前記ディスパッチャは前記第2のマシン上で実行しており、
各前記ステップは、1つ以上のコンピュータプロセッサで実行される、方法。
【請求項11】 前記カートリッジに関連付けられるカートリッジ実行エンジンを介して前記カートリッジへ前記ディスパッチャから複数のリクエストを渡す前記ステップは、
特定のリクエストをマシン間通信機構を介して前記カートリッジ実行エンジンへ送るステップと、
前記特定のリクエストを前記カートリッジに送るために、前記カートリッジ実行エンジンに前記カートリッジ内のexec()ルーチンを呼出させるステップとを含む、請求項10に記載の方法。
【請求項12】 前記特定のリクエストを前記カートリッジ実行エンジンへマシン間通信機構を介して送る前記ステップは、前記特定のリクエストを前記カートリッジ実行エンジンへオブジェクトリクエストブローカを介して送ることによって行なわれる、請求項11に記載の方法。
【請求項13】 ブラウザリクエストに関連するオペレーションを行なうための方法であって、
複数のウェブリスナに結合される複数のディスパッチャを実行するステップと、
複数のカートリッジを実行するステップとを含み、標準カートリッジインターフェイスを介して受取られた呼出に応答してカートリッジがオペレーションを行ない、さらに
マシン間通信機構を介して前記複数のディスパッチャと通信し、かつ前記標準カートリッジインターフェイスを介して前記複数のカートリッジを呼出すことによって前記複数のカートリッジと通信する複数のカートリッジ実行エンジンを実行するステップを含み、
前記複数のディスパッチャの各ディスパッチャは、オペレーションを行なうのにある特定のカートリッジを必要とするブラウザリクエストをウェブリスナが受取ったことに応答して、前記マシン間通信機構を介して第1のメッセージを前記複数のカートリッジ実行エンジンのある特定のカートリッジ実行エンジンへ送るよう構成されており、
前記ある特定のカートリッジ実行エンジンは前記第1のメッセージに応答して、前記オペレーションを行なう前記ある特定のカートリッジ内のルーチンを前記標準カートリッジインターフェイスを介して呼出すよう構成されており、
前記ブラウザリクエストは、ユニフォーム・リソース・ロケータ(URL)を含み、前記複数のディスパッチャの各ディスパッチャは、URLをカートリッジにマッピングするメタデータを調べる仮想パスマネージャに対して、当該URLを送信することにより、前記複数のカートリッジのうちのカートリッジへの経路を選択し、
前記仮想パスマネージャは、前記複数のカートリッジのうちの特定のカートリッジが前記URLにマッピングされることを、前記メタデータに基づいて判断し、かつ、前記URLが受け取られた特定のディスパッチャに、前記特定のカートリッジを識別するデータを当該特定のディスパッチャに送信することにより応答し、
各前記ステップは、1つ以上のコンピュータプロセッサによって実行される、方法。
【請求項14】 前記マシン間通信機構はオブジェクトリクエストブローカとして構成される、請求項13に記載の方法。
【請求項15】 分散システムのカートリッジに分散を意識させない態様でオペレーションを行なわせるための1つ以上の命令シーケンスを担持するコンピュータ可読媒体であって、前記分散システムは、第1のマシンと第2のマシンとを含み、前記第1のマシンと前記第2のマシンとは異なるものであり、前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり、1つ以上のプロセッサによる1つ以上の命令シーケンスの実行は、1つ以上のプロセッサに以下のステップ、すなわち
ある特定のマシン上で前記カートリッジを実行するステップと、
前記カートリッジに関連付けられるカートリッジ実行エンジンを介して前記分散システム内のディスパッチャから前記カートリッジに複数のリクエストを渡すステップと、
前記カートリッジに関連付けられる前記カートリッジ実行エンジンを介して前記カートリッジからディスパッチャに返答を渡すステップとを行なわせ、
前記複数のリクエストの各リクエストは、ユニフォーム・リソース・ロケータ(URL)を含み、前記ディスパッチャは、URLをカートリッジにマッピングするメタデータを調べる仮想パスマネージャに対して、当該URLを送信することにより、前記経路を選択し、
前記仮想パスマネージャが、前記カートリッジが前記URLにマッピングされることを前記メタデータに基づいて判断し、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより前記ディスパッチャに応答するステップと、
前記カートリッジは、前記分散システムにおける複数のカートリッジの1つであり、
前記複数のカートリッジの各々特定のカートリッジは、標準通信インターフェイスを介してリクエストを受信し、
前記カートリッジ実行エンジンおよび前記カートリッジは前記第1のマシン上で実行しており、
前記ディスパッチャは前記第2のマシン上で実行している、コンピュータ可読媒体。
【請求項16】 前記カートリッジに関連付けられるカートリッジ実行エンジンを介してリクエストを前記ディスパッチャから前記カートリッジに渡す前記ステップは
特定のリクエストをマシン間通信機構を介して前記カートリッジ実行エンジンへ送るステップと、
前記特定のリクエストを前記カートリッジに送るために、前記カートリッジ実行エンジンに前記カートリッジ内のexec()ルーチンを呼出させるステップとを含む、請求項15に記載のコンピュータ可読媒体。
【請求項17】 前記特定のリクエストをマシン間通信機構を介して前記カートリッジ実行エンジンへ送る前記ステップは、前記特定のリクエストをオブジェクトリクエストブローカを介して前記カートリッジ実行エンジンに送ることによって行なわれる、請求項16に記載のコンピュータ可読媒体。」
(以下、この特許請求の範囲を「補正前の請求項」という。)を、
「 【請求項1】 分散システムにおいてオペレーションを実行するための方法であって、前記分散システムは複数のマシンを含み、前記方法は、
前記複数のマシンの一部のコンピュータプロセッサが、複数のディスパッチャを前記複数のマシンの一部で実行するステップを含み、前記複数のマシンのうちの第1のマシンで実行されている一つの特定のディスパッチャはリクエストを受信し、
前記特定のディスパッチャはリソースマネージャに問い合わせ、前記リソースマネージャは、前記リクエストに対応する処理を実行する、前記複数のディスパッチャによって使用されていないカートリッジに対する経路を選択し、前記カートリッジが見つかった場合に当該特定のディスパッチャのために当該カートリッジを予約し、前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり、
前記複数のマシンのうちの第2のマシンのコンピュータプロセッサが、カートリッジ実行エンジンを前記第2のマシン上で実行するステップを含み、前記カートリッジ実行エンジンは前記カートリッジの実行を制御し、
前記第1のマシンのコンピュータプロセッサによって実行される前記特定のディスパッチャが、前記第1のマシンにおいて実現されるウェブリスナから、前記オペレーションの実行をリクエストする第1のメッセージを受取るステップを含み、前記第1のメッセージは、前記ウェブリスナがブラウザからブラウザリクエストを受取ったことに応答して前記特定のディスパッチャに送られたものであり、前記ブラウザは前記分散システムと通信するクライアント装置において実現され、
前記第1のメッセージに応答して、前記特定のディスパッチャが第2のメッセージを前記カートリッジ実行エンジンへマシン間通信機構を介して送るステップと、
前記第2のメッセージに応答して、前記第2のマシンのコンピュータプロセッサによって実現される前記カートリッジ実行エンジンが第3のメッセージを標準カートリッジインターフェイスを介して、前記第2のマシン上で実行されているカートリッジに渡すステップとを含み、前記カートリッジは、各々が前記標準カートリッジインターフェイスを介して呼出されるルーチンを含む複数のカートリッジのうちの1つであり、さらに
前記第3のメッセージを受取ったことに応答して、前記第2のマシンのコンピュータプロセッサによって実現される前記カートリッジが前記オペレーションを実行するステップを含む、方法。
【請求項2】 前記オペレーションを実行した後に、前記カートリッジが第4のメッセージを前記カートリッジ実行エンジンに渡すステップと、
前記第4のメッセージに応答して、前記カートリッジ実行エンジンが第5のメッセージを前記特定のディスパッチャに送るステップと、
前記第5のメッセージに応答して、前記特定のディスパッチャが第6のメッセージを前記ウェブリスナに送り、前記ウェブリスナがこれを前記ブラウザに転送するステップとをさらに含む、請求項1に記載の方法。
【請求項3】 前記特定のディスパッチャが第2のメッセージをカートリッジ実行エンジンへ送る前記ステップは、前記特定のディスパッチャが第2のメッセージをオブジェクトリクエストブローカを介してカートリッジ実行エンジンに送ることによって実行される、請求項2に記載の方法。
【請求項4】 前記カートリッジ実行エンジンが第5のメッセージを前記特定のディスパッチャに送る前記ステップは、前記カートリッジ実行エンジンが第5のメッセージを前記オブジェクトリクエストブローカを介して前記特定のディスパッチャに送ることによって実行される、請求項3に記載の方法。
【請求項5】 前記カートリッジ実行エンジンが第3のメッセージをカートリッジに渡す前記ステップは前記カートリッジ実行エンジンが前記カートリッジ内のルーチンを呼出すことによって行なわれ、
前記カートリッジが第4のメッセージを前記カートリッジ実行エンジンに渡す前記ステップは、前記カートリッジ内で呼出された前記ルーチンから戻ることによって行なわれる、請求項2に記載の方法。
【請求項6】 前記カートリッジは共用ライブラリであり、
前記カートリッジ実行エンジンが第3のメッセージを前記カートリッジに渡す前記ステップは前記カートリッジが前記共用ライブラリ内のルーチンを呼出すステップを含む、請求項1に記載の方法。
【請求項7】 前記第2のマシンのコンピュータプロセッサが前記カートリッジ実行エンジンを実行時に前記カートリッジに動的にリンクするステップをさらに含む、請求項6に記載の方法。
【請求項8】 ブラウザリクエストに関連するオペレーションを行なうためのシステムであって、
複数のウェブリスナに結合される複数のディスパッチャを含み、前記複数のディスパッチャの各ディスパッチャはリクエストを受信し、
リソースマネージャを含み、前記リソースマネージャは、前記複数のディスパッチャからカートリッジのための複数のリクエストを受信し、前記複数のディスパッチャのうちの一つの特定のディスパッチャから、前記複数のリクエストのうちの一つの特定のリクエストに応じて、前記特定のリクエストに対応する処理を実行する前記複数のディスパッチャによって使用されていないカートリッジへの経路を選択し、前記カートリッジが見つかった場合に前記特定のディスパッチャのために当該カートリッジを予約し、前記カートリッジは前記システムにおいて1つ以上のプロセッサによって実行されるコードのモジュールであり、
マシン間通信機構と、
複数のカートリッジとを含み、前記カートリッジの各々は標準カートリッジインターフェイスを介して呼出され、前記標準カートリッジインターフェイスを介して受取った呼出に応答して別々のカートリッジが別々のオペレーションを行ない、さらに
前記マシン間通信機構を介して前記複数のディスパッチャと通信し、かつ前記標準カートリッジインターフェイスを介して呼出すことによって、前記複数のカートリッジと通信する複数のカートリッジ実行エンジンを含み、
前記複数のディスパッチャの各ディスパッチャは、オペレーションを行なうのにある特定のカートリッジを必要とするブラウザリクエストをウェブリスナが受取ったことに応答して、前記複数のカートリッジ実行エンジンのある特定のカートリッジ実行エンジンへ第1のメッセージを前記マシン間通信機構を介して送るよう構成されており、
前記ある特定のカートリッジ実行エンジンは、前記標準カートリッジインターフェイスを介して前記第1のメッセージに応答する、システム。
【請求項9】 前記マシン間通信機構はオブジェクトリクエストブローカである、請求項8に記載のシステム。
【請求項10】 分散システムのカートリッジに分散を意識させない態様でオペレーションを行なわせるための方法であって、前記分散システムは、複数のマシンを含み、前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり、
前記複数のマシンのうちの第1のマシンのコンピュータプロセッサが、前記第1のマシン上で前記カートリッジを実行するステップと、
前記第1のマシンのコンピュータプロセッサが、前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内の、前記複数のマシンのプロセッサのうちの一部で実行される複数のディスパッチャのうちの一つの特定のディスパッチャから、前記カートリッジに複数のサービスリクエストを渡すステップとを含み、前記カートリッジ実行エンジンは前記カートリッジの実行を制御し、前記複数のサービスリクエストは標準カートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され、
前記第1のマシンのコンピュータプロセッサが、前記カートリッジに関連付けられる前記カートリッジ実行エンジンを介して返答を前記カートリッジから前記特定のディスパッチャに渡すステップを含み、
前記複数のディスパッチャは、リソースマネージャにリクエストを送信し、前記リソースマネージャは、一つの特定のディスパッチャからの特定のリクエストに応じて、前記特定のリクエストに対応する処理を実行する、前記複数のディスパッチャによって使用されていないカートリッジへの経路を選択し、前記カートリッジが見つかった場合に、前記特定のディスパッチャのための当該カートリッジを予約し、
前記カートリッジは、前記分散システムにおける複数のカートリッジの1つであり、
前記複数のカートリッジの各々特定のカートリッジは、前記標準カートリッジインターフェイスを介してサービスリクエストを受信し、
前記カートリッジ実行エンジンおよび前記カートリッジは前記第1のマシン上で実行しており、
前記複数のディスパッチャは前記複数のマシンの一部で実行している、方法。
【請求項11】 前記カートリッジに関連付けられるカートリッジ実行エンジンを介して前記カートリッジへ前記ディスパッチャから複数のサービスリクエストを渡す前記ステップは、
特定のサービスリクエストをマシン間通信機構を介して前記カートリッジ実行エンジンへ送るステップと、
前記特定のサービスリクエストを前記カートリッジに送るために、前記カートリッジ実行エンジンに前記カートリッジの標準カートリッジインターフェイスを呼出させるステップとを含む、請求項10に記載の方法。
【請求項12】 前記特定のサービスリクエストを前記カートリッジ実行エンジンへマシン間通信機構を介して送る前記ステップは、前記特定のサービスリクエストを前記カートリッジ実行エンジンへオブジェクトリクエストブローカを介して送ることによって行なわれる、請求項11に記載の方法。
【請求項13】 ブラウザリクエストに関連するオペレーションを行なうための方法であって、
複数のウェブリスナに結合される複数のディスパッチャを実行するステップと、
複数のカートリッジを実行するステップとを含み、標準カートリッジインターフェイスを介して受取られた呼出に応答してカートリッジがオペレーションを行ない、さらに
マシン間通信機構を介して前記複数のディスパッチャと通信し、かつ前記標準カートリッジインターフェイスを介して前記複数のカートリッジを呼出すことによって前記複数のカートリッジと通信する複数のカートリッジ実行エンジンを実行するステップと、
リソースマネージャを実行するステップとを含み、前記リソースマネージャは、前記複数のディスパッチャから、カートリッジのための複数のリクエストを受信し、前記複数のディスパッチャのうちの一つの特定のディスパッチャからの、複数のリクエストのうちの特定のリクエストに応じて、前記特定のリクエストに対応する処理を実行する、前記複数のディスパッチャによって使用されていないカートリッジへの経路を選択し、かつ、前記カートリッジが見つかった場合に前記特定のディスパッチャのために当該カートリッジを予約し、
前記複数のディスパッチャの各ディスパッチャは、オペレーションを行なうのにある特定のカートリッジを必要とするブラウザリクエストをウェブリスナが受取ったことに応答して、前記マシン間通信機構を介して第1のメッセージを前記複数のカートリッジ実行エンジンのある特定のカートリッジ実行エンジンへ送るよう構成されており、
前記ある特定のカートリッジ実行エンジンは前記第1のメッセージに応答して、前記オペレーションを行なう前記ある特定のカートリッジ内のルーチンを前記標準カートリッジインターフェイスを介して呼出すよう構成されており、
各前記ステップは、1つ以上のコンピュータプロセッサによって実行される、方法。
【請求項14】 前記マシン間通信機構はオブジェクトリクエストブローカとして構成される、請求項13に記載の方法。
【請求項15】 分散システムのカートリッジに分散を意識させない態様でオペレーションを行なわせるための1つ以上の命令シーケンスを担持するコンピュータ可読媒体であって、前記分散システムは複数のマシンを含み、前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり、1つ以上のプロセッサによる1つ以上の命令シーケンスの実行は、前記複数のマシンの複数のプロセッサに以下のステップ、すなわち
前記複数のマシンのうちの第1のマシンのプロセッサが、前記第1のマシン上で前記カートリッジを実行するステップと、
前記カートリッジに関連付けられるカートリッジ実行エンジンを介して前記分散システム内で前記複数のマシンの一部のプロセッサによって実現される複数のディスパッチャから、前記カートリッジに複数のサービスリクエストを渡すステップと、
前記カートリッジに関連付けられる前記カートリッジ実行エンジンを介して、前記第1のマシンのプロセッサによって実行される前記カートリッジから前記複数のディスパッチャに返答を渡すステップとを行なわせ、
前記カートリッジは、前記分散システムにおける複数のカートリッジの1つであり、
前記複数のカートリッジの各々特定のカートリッジは、標準カートリッジインターフェイスを介してサービスリクエストを受信し、
前記複数のディスパッチャは、リソースマネージャにリクエストを送信し、前記リソースマネージャは、一つの特定のディスパッチャからの特定のリクエストに応じて、前記特定のリクエストに対応する処理を実行する、前記複数のディスパッチャによって使用されていないカートリッジへの経路を選択し、前記カートリッジが見つかった場合に、前記特定のディスパッチャのための当該カートリッジを予約し、
前記カートリッジ実行エンジンおよび前記カートリッジは前記第1のマシン上で実行しており、
前記複数のディスパッチャは前記複数のマシンの一部で実行している、コンピュータ可読媒体。
【請求項16】 前記カートリッジに関連付けられるカートリッジ実行エンジンを介して前記分散システム内で複数のサービスリクエストを複数のディスパッチャから前記カートリッジに渡す前記ステップは
特定のサービスリクエストをマシン間通信機構を介して前記カートリッジ実行エンジンへ送るステップと、
前記特定のサービスリクエストを前記カートリッジに送るために、標準カートリッジインターフェイスを介して前記カートリッジ実行エンジンに前記カートリッジを呼出させるステップとを含む、請求項15に記載のコンピュータ可読媒体。
【請求項17】 前記特定のサービスリクエストをマシン間通信機構を介して前記カートリッジ実行エンジンへ送る前記ステップは、前記特定のサービスリクエストをオブジェクトリクエストブローカを介して前記カートリッジ実行エンジンに送ることによって行なわれる、請求項16に記載のコンピュータ可読媒体。」
(以下、この特許請求の範囲を「補正後の請求項」という。)
と補正するものである。

2の2.本件補正が特許法第17条の2第4項の規定を満たすか否かの検討
本件補正は、少なくとも、(A)補正前の請求項10にあった「前記複数のリクエストの各リクエストは、ユニフォーム・リソース・ロケータ(URL)を含み、前記ディスパッチャは、URLをカートリッジにマッピングするメタデータを調べる仮想パスマネージャに対して、当該URLを送信することにより、前記経路を選択し、…(改行)…前記仮想パスマネージャが、前記メタデータに基づいて、前記カートリッジが前記URLにマッピングされることを判断して、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより、前記ディスパッチャに応答するステップと、」という記載を削除することと、(B)補正前の請求項10にはなかった「前記複数のディスパッチャは、リソースマネージャにリクエストを送信し、前記リソースマネージャは、一つの特定のディスパッチャからの特定のリクエストに応じて、前記特定のリクエストに対応する処理を実行する、前記複数のディスパッチャによって使用されていないカートリッジへの経路を選択し、前記カートリッジが見つかった場合に、前記特定のディスパッチャのための当該カートリッジを予約し、」という記載を追加すること、を含む。つまり、上記(A)で示される補正は、補正前の請求項10における発明特定事項である「仮想パスマネージャ」に関係するステップを削除するものであり、上記(B)で示される補正は、補正前の請求項10にはなかった発明特定事項である「リソースマネージャ」に関係するステップを新たに追加するものである。
ところで、平成14年法律第24号改正附則第2条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項には、最後の拒絶理由通知を受けた場合において特許請求の範囲についてする補正の目的を限定列挙している。同条同項第2号にはその目的のひとつとして「特許請求の範囲の減縮(第36条第5項の規定により請求項に記載した発明を特定するために必要な事項を限定するものであつて、その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。)」が示されている(以下、この目的を「限定的減縮の目的」という。)。この同条同項第2号の限定的減縮の規定に照らしてみると、上記(A)で示される補正は、補正前の請求項10にあった発明特定事項を削除するものであって、この削除の限りにおいては特許請求の範囲の減縮ではなくて特許請求の範囲の拡張にあたり、同条同項第2号の限定的減縮を目的とするものであるとはいえない。また、上記(B)で示される補正は、補正前の請求項10にあったいずれの発明特定事項を限定するものでもないので、同条同項第2号でいう「請求項に記載した発明を特定するために必要な事項を限定するもの」であるとはいえず、同条同項第2号の限定的減縮を目的とするものであるとはいえない。さらに、上記(B)で示される補正により追加された「リソースマネージャ」に関係するステップは少なくとも、特定のディスパッチャによる特定のリクエストに対応する処理を実行するためのカートリッジのうち、いずれのディスパッチャによっても使用されていないものを選択して、特定のディスパッチャに当該選択されたカートリッジを割り当てるという制御を行うという、リソースマネージャにより解決する課題を有するのに対し、補正前の請求項10の発明特定事項に対応する解決しようとする課題には上記したようなリソースマネージャにより解決する課題に相当するものは含まれない。そのため、上記(B)で示される補正は、同条同項第2号でいう「その補正前の当該請求項に記載された発明とその補正後の当該請求項に記載される発明の産業上の利用分野及び解決しようとする課題が同一であるものに限る。」との規定に合致するものではなく、同条同項第2号の限定的減縮を目的とするものであるとはいえない。
また、上記(A)で示される補正と上記(B)で示される補正は、同条同項第1号に規定される「第36条第5項に規定する請求項の削除」、同条同項第3号に規定される「誤記の訂正」、同条同項第4号に規定される「明りようでない記載の釈明(拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。)」のいずれを目的とするものであるともいえない。
なお、平成22年9月9日付け意見書において請求人は、上記(A)で示される補正と上記(B)で示される補正の目的について下記のように主張している。

「(c) 「前記複数のリクエストの各リクエストは、ユニフォーム・リソース・ロケータ(URL)を含み、前記ディスパッチャは、URLをカートリッジにマッピングするメタデータを調べる仮想パスマネージャに対して、当該URLを送信することにより、前記経路を選択し、 前記仮想パスマネージャが、前記メタデータに基づいて、前記カートリッジが前記URLにマッピングされることを判断して、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより、前記ディスパッチャに応答するステップと」との記載を、「前記複数のディスパッチャは、リソースマネージャにリクエストを送信し、前記リソースマネージャは、一つの特定のディスパッチャからの特定のリクエストに応じて、前記特定のリクエストに対応する処理を実行する、前記複数のディスパッチャによって使用されていないカートリッジへの経路を選択し、前記カートリッジが見つかった場合に、前記特定のディスパッチャのための当該カートリッジを予約し」との記載にする補正は、請求項1についてのご指摘と同様に、拒絶の理由C(3)におきまして明瞭でない旨のご指摘を受けた記載、すなわち、上記趣旨Fの記載および趣旨Gの記載の釈明を目的とするものであって、同法第17条の2第4項第4号に掲げる事項に該当するものと思料致します。」

上記主張において引用されている、平成22年3月9日付け最後の拒絶理由通知の【理由C】の(3)には、「請求項1?17には、前記【理由B】の(3)で指摘した趣旨F及び趣旨Gが記載されているが、そのようなことは発明の詳細な説明には記載されていない。したがって、請求項1?17として記載されている特許を受けようとする発明が、発明の詳細な説明に記載したものではない。」と記載されており、さらに同拒絶理由通知の【理由B】の(3)には「…(前略)…、「ユニフォーム・リソース・ロケータ(URL)」そのものが「ディスパッチャ」から「カートリッジ実行エンジン」を介して「カートリッジ」に渡されるという趣旨(以下、便宜的に「趣旨F」という。)を、請求項10は含むことになる。…(中略)…「ユニフォーム・リソース・ロケータ(URL)」そのものが「標準カートリッジインターフェイス」を介して「カートリッジ実行エンジン」から「カートリッジ」に渡されるという趣旨(以下、便宜的に「趣旨G」という。)を、請求項10は含むことになる。…(改行)…しかしながら、前記趣旨F及び趣旨Gは、当初翻訳文にも当初翻訳図面にも記載されておらず、当初翻訳文及び当初翻訳図面の記載から自明でもない。…(後略)…」と記載されている。このような拒絶理由に対して、平成14年法律第24号改正附則第2条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項第4号で規定される「明りようでない記載の釈明(拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。)」を目的とした補正を行うのであれば、ここでいう「明りようでない記載の釈明」における「釈明」とは、その記載本来の意味内容を明らかにすることであるから(審判便覧の54-10の4.(1)や特許・実用新案審査基準の第3部第3節5.2を参照のこと。)、当該補正においては、「ユニフォーム・リソース・ロケータ(URL)」、「ディスパッチャ」、「カートリッジ実行エンジン」、「カートリッジ」、「標準カートリッジインターフェイス」のそれぞれの記載の本来の意味内容を明らかにして、これらの記載の間の関係も適切に示すようにすることにより、請求項において上記された趣旨F及び趣旨Gのような解釈がなされないようにすることが妥当である。しかしながら、本件補正における、上記(A)で示される補正と上記(B)で示される補正は、このような同条同項第4号で規定される「明りようでない記載の釈明(拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。)」を目的とする補正の範疇を超えて、ユニフォーム・リソース・ロケータ(URL)が関わる全ての発明特定事項を削除し、「仮想パスマネージャ」に関連するステップを削除し、さらに新たに「リソースマネージャ」に関連するステップを追加するものであるから、上記(A)で示される補正と上記(B)で示される補正は請求人が同意見書で主張するような「明りようでない記載の釈明(拒絶理由通知に係る拒絶の理由に示す事項についてするものに限る。)」を目的とするものであるとはいえない。
以上で示したように、本件補正により、請求項10について行われた補正は、平成14年法律第24号改正附則第2条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項のいずれの号に掲げられる事項を目的としたものでもない。また、本件補正により、上記(A)で示される補正と上記(B)で示される補正と同様な補正が、請求項1、請求項8、請求項13、請求項15においても行われており、これらの請求項についても、同様に、同条同項のいずれの号に掲げられている事項を目的としたものでもない。
このように、本件補正は、平成14年法律第24号改正附則第2条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項の規定に違反する。

2の3.独立特許要件の検討
上記2の2で示したように、本件補正は平成14年法律第24号改正附則第2条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項の規定に違反するものであるが、仮に、本件補正が同条同項第2号に規定される限定的減縮の目的を有するものとして、本件補正が、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定(以下、「独立特許要件」という。)を満たすか否かを検討する。

2の3の1.特許法第36条第4項の規定を満たすか否かの検討
補正後の請求項10に「前記複数のサービスリクエストは標準カートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され、」及び「前記複数のカートリッジの各々特定のカートリッジは、前記標準カートリッジインターフェイスを介してサービスリクエストを受信し、」と記載されている。
ところで、補正後の請求項10の上記で指摘した箇所における「標準カートリッジインターフェイス」に関連して、特許法第184条の6第2項でみなされるところの明細書(以下、単に「明細書」という。)の発明の詳細な説明に以下に示す記載がある。

「【0038】
この発明の一実施例によれば、各カートリッジはすべてのカートリッジに対して共通の全体構造をもたらす標準インターフェイスを有する。この標準インターフェイスは、特定の条件の下でウェブアプリケーションサーバ280により呼出されるルーチンのインターフェイスを規定する。この発明の一実施例によれば、抽象カートリッジインターフェイスは以下のとおりである。
【0039】
【表1】

interface Cartridge
{
boolean int();
boolean authenticate(in Principal user_passwd);
boolean exec(in Request req_obj, out Response resp_obj);
boolean shutdown();
}
【0040】
init()ルーチンはカートリッジインスタンスを初期化する役割を果たす。このことには、いくつかのサブオブジェクトのコンストラクタを呼出すことと、スレッドを予め分岐させることと、他のすべての必要となる共用リソースを獲得することとが含まれ得る。
【0041】
shutdown()ルーチンはすべてのリソースを片付けカートリッジインスタンスをシャットダウンする役割を果たす。カートリッジインスタンスに対して一度shutdown()ルーチンが呼出されると、直ちにカートリッジインスタンスは後続のリクエストを処理するのに利用不可能となる。
【0042】
authenticate()ルーチンではカートリッジのサービスをリクエストしているクライアントがそのサービスを用いることを許可されているかどうかを検証する。
【0043】
exec()ルーチンはカートリッジに対してすべてのサービスリクエストをディスパッチする包括的なやり方である。
【0044】
例示的カートリッジ
各カートリッジは、明確に定義された機能を行なうカートリッジとして構成されるか、またはあるアプリケーションのためのインタプリタまたはルーチン環境として作用するプログラム可能なカートリッジとして構成される。プログラム可能なカートリッジの一例はPL/SQLランタイムであり、これは構造的問合せ言語(Structured Query Language)を用いるオラクルベースのプログラム言語(Oracle-based Programming Language)(PL/SQL)に従ってデータベースクエリーを処理するよう構成される。PL/SQLランタイムはデータベースクエリーを有するブラウザリクエストを実行する。PL/SQLランタイムは、たとえば、データリンクを介してカートリッジインスタンスと通信しているデータベースサーバにアクセスすることによってリクエストを処理する。
【0045】
プログラム可能なカートリッジの別の例はJAVAランタイムインタプリタである。JAVAランタイムインタプリタカートリッジのおかげで、ウェブアプリケーション開発者らはブラウザリクエストを処理するためのサーバ側のJAVAアプリケーションを書くことができる。同様に、たとえば第三者のサーバによって実行されるプロセスにアクセスするなどの動的オペレーションをもたらすために、カスタムサーバをカートリッジとして構成してもよい。」

「【0091】
カートリッジは、関数テーブルにカートリッジ関数に対するポインタを蔵置することによってカートリッジ実行エンジンに利用可能となる。一実施例によれば、すべてのカートリッジが、上述の例示のカートリッジインターフェイスにおいて特定された関数を提供する。すべてのカートリッジが同じインターフェイスをサポートするようにさせることにより、単一の標準カートリッジ実行エンジンをすべてのカートリッジに対して用いることができる。
【0092】
図2に示されるように、ウェブアプリケーションサーバ280はカートリッジ230、234および238の各々に対しカートリッジ実行エンジン228、232および236を含む。カートリッジ実行エンジンは標準のカートリッジインターフェイスを介してカートリッジへの呼出を行なうことにより対応するカートリッジの実行を制御する。カートリッジ実行エンジンとカートリッジとの間で基本的なコールバック機能を確立することにより、そのカートリッジをコールバック機能に応答するよう構成し、次にそのカートリッジをコンフィギュレーションプロバイダ256に登録することによってどんなカートリッジもウェブアプリケーションサーバ280に統合することができる。
【0093】
この発明の一実施例によれば、カートリッジは共用ライブラリとして実装され、カートリッジ実行エンジンは標準カートリッジインターフェイスを用いて共用ライブラリ内のルーチンを呼出す実行可能なプログラムである。カートリッジ実行エンジンはカートリッジとディスパッチャとの間でインターフェイスをもたらし、カートリッジの制御のフローを指示し、カートリッジが用いるサービスを提供する。」

しかしながら、上記した明細書の【0038】?【0045】及び【0091】?【0093】を考慮しても、補正後の請求項10でいう「標準カートリッジインターフェイス」をいかに実現するのかが不明である。
特に、明細書の上記で指摘した箇所においては、「抽象カートリッジインターフェイス」として「exec(in Request req_obj, out Response resp_obj)」ルーチンが示され、「exec()ルーチンはカートリッジに対してすべてのサービスリクエストをディスパッチする包括的なやり方である。」と記載されている。しかしながら、ここでいう「包括的なやり方」がいかなるものであるのかが明細書の発明の詳細な説明からは不明である。また、execルーチンの引数として示されている「in Request req_obj」と「out Response resp_obj」が具体的にどのような引数であるのかも不明である。
明細書の【0044】?【0045】の「各カートリッジは、明確に定義された機能を行なうカートリッジとして構成されるか、またはあるアプリケーションのためのインタプリタまたはルーチン環境として作用するプログラム可能なカートリッジとして構成される。プログラム可能なカートリッジの一例はPL/SQLランタイムであり、…(中略)…プログラム可能なカートリッジの別の例はJAVAランタイムインタプリタである。…(中略)…同様に、たとえば第三者のサーバによって実行されるプロセスにアクセスするなどの動的オペレーションをもたらすために、カスタムサーバをカートリッジとして構成してもよい。」という記載から明らかなように、本願においては、互いに異なる処理を行うための複数の種類のカートリッジが存在することが前提となっており、そのような異なる処理を行う複数のカートリッジのそれぞれが用いる引数は、一般的には各カートリッジ毎に異なっていて共通ではない。その一方で、明細書の【0043】に「exec()ルーチンはカートリッジに対してすべてのサービスリクエストをディスパッチする包括的なやり方である。」と記載され、【0091】に「すべてのカートリッジが同じインターフェイスをサポートするようにさせることにより、単一の標準カートリッジ実行エンジンをすべてのカートリッジに対して用いることができる。」と記載されていることから、単一の標準カートリッジ実行エンジンをあらゆる種類のカートリッジに対して用いるために、包括的なやり方である同じ「標準カートリッジインターフェース」をサポートしようとするものであると解されるところである。しかしながら、明細書の発明の詳細な説明からは、カートリッジごとに異なる引数をカートリッジ実行エンジンとカートリッジの間で授受することを、包括的なやり方である同じ「標準カートリッジインターフェース」を用いていかに実現するのかが不明である。
したがって、「標準カートリッジインターフェース」に関して、明細書の発明の詳細な説明は、当業者が補正後の請求項10に係る発明を実施することができる程度に明確かつ十分に記載したものではない。つまり、補正後の請求項10に関して、本願は平成14年法律第24号改正附則第2条第1項によりなお従前の例によるとされる同法による改正前の特許法第36条第4項の規定を満たさない。「標準カートリッジインターフェース」という発明特定事項は、補正後の請求項1乃至9に係る発明、及び、補正後の請求項11乃至17に係る発明にも含まれるから、補正後の請求項1乃至9に係る発明、及び、補正後の請求項11乃至17に係る発明についても同様である。

なお、上記で指摘した点は、平成22年3月9日付け最後の拒絶理由通知における【理由D】の(3)でも指摘されているものであるところ、当該【理由D】の(3)に対して、平成22年9月9日付け意見書において、請求人は下記の主張を行っている。

「 (6-3) 記(3)について
審判官殿は、段落0043に記載されている「包括的なやり方」とは、具体的にどのような手法であるのか不明である旨の見解、段落0039のexecというルーチンの引数として使用されている「Request req_obj」、「Response resp_obj」というのが、具体的にどのような引数であるのかも不明である旨の見解、段落0043の「包括的なやり方」という記載と矛盾せずにカートリッジごとに異なる引数を授受する手法が不明である旨の見解を示されました。
この点、まず、段落0039に示されたカートリッジインターフェイスは、段落038に記載のとおり「抽象」的なカートリッジインターフェイスです。本願実施例では、当該カートリッジに関して言語が限定されておらず、一実施例として、抽象カートリッジインターフェイスが規定されているものです。段落0038?0043のような擬似的なコードは、当該カートリッジインターフェイスをどのように構築するかについての考え方をもたらすものであって、実現化のための詳細は、当該技術の分野におけるコンピュータ言語のための周知のプログラミング技術に委ねられるものです。よって、段落0038?0043に記載された「抽象カートリッジインターフェイス」に係る開示は、所謂当業者がその実施をできる程度に明確かつ十分に記載されたものであると思料致します。」

しかしながら、上記主張は、明細書の詳細な説明には抽象的なカートリッジインターフェースが示されているとする主張にとどまるものである。明細書の発明の詳細な説明における抽象的なカートリッジインターフェースの記載からは、カートリッジごとに異なる引数をカートリッジ実行エンジンとカートリッジの間で授受することを、包括的なやり方である同じ「標準カートリッジインターフェース」を用いていかに具体的に実現するのかが不明であり、「周知のプログラミング技術」では実現できず、実現には「周知のプログラミング技術」の程度を超えた試行錯誤を要するものであるから、同意見書による請求人の上記主張を採用することはできない。

2の3の2.特許法第36条第6項第1号の規定を満たすか否かの検討
2の3の2の1.サービスリクエストについて
補正後の請求項10に「前記第1のマシンのコンピュータプロセッサが、前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内の、前記複数のマシンのプロセッサのうちの一部で実行される複数のディスパッチャのうちの一つの特定のディスパッチャから、前記カートリッジに複数のサービスリクエストを渡すステップとを含み、前記カートリッジ実行エンジンは前記カートリッジの実行を制御し、前記複数のサービスリクエストは標準カートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され、」と記載されている。
ところで、明細書の発明の詳細な説明において「サービスリクエスト」という語は【0043】の「exec()ルーチンはカートリッジに対してすべてのサービスリクエストをディスパッチする包括的なやり方である。」という文にのみ記載されているものである。この【0043】はカートリッジ実行エンジンとカートリッジとの間のインタフェースについて記載されている箇所であるから、明細書の発明の詳細な説明においては「サービスリクエスト」という語はカートリッジ実行エンジンとカートリッジとの間で渡されるリクエストにのみ用いられているといえる。その一方で、ディスパッチャとカートリッジ実行エンジンとの間で渡されるリクエストについて、明細書の発明の詳細な説明では「変更されたリクエスト」または「変更されたブラウザリクエスト」という語が用いられている。例えば、明細書の【0108】に「ディスパッチャ214はそこで、変更されたブラウザリクエストを作りステップ368においてインスタンス260のカートリッジ実行エンジン228にその変更されたブラウザリクエストを送って、以下に説明するように利用可能なインスタンス260にそのリクエストを処理させる。」と記載されている。つまり、明細書の発明の詳細な説明では、ディスパッチャからカートリッジ実行エンジンに渡されるリクエストは「変更されたリクエスト」または「変更されたブラウザリクエスト」であり、カートリッジ実行エンジンからカートリッジに渡されるリクエストは「サービスリクエスト」である。
これに対し、補正後の請求項10の上記で指摘した箇所においては、「…(前略)…カートリッジ実行エンジンを介して、…(中略)…ディスパッチャから、前記カートリッジに複数のサービスリクエストを渡すステップとを含み、…(後略)…」と記載されていることから、ディスパッチャからカートリッジ実行エンジンに渡されるリクエストと、カートリッジ実行エンジンからカートリッジに渡されるリクエストの両方が「サービスリクエスト」ということになる。このように、補正後の請求項10の上記で指摘した箇所の記載は、明細書の発明の詳細な説明の記載と合致しない。
したがって、「サービスリクエスト」に関して、補正後の請求項10に係る発明は明細書の発明の詳細な説明に記載したものであるとはいえない。つまり、補正後の請求項10に関して、本願は平成14年法律第24号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第36条第6項第1号の規定を満たさない。
補正後の請求項11、請求項12、請求項15、請求項16、及び請求項17にも「サービスリクエスト」について補正後の請求項10と同趣旨の記載があるので、補正後の請求項11、請求項12、請求項15、請求項16、及び請求項17についても同様である。

2の3の2の2.リソースマネージャと経路について
補正後の請求項10に「前記複数のディスパッチャは、リソースマネージャにリクエストを送信し、前記リソースマネージャは、一つの特定のディスパッチャからの特定のリクエストに応じて、前記特定のリクエストに対応する処理を実行する、前記複数のディスパッチャによって使用されていないカートリッジへの経路を選択し、前記カートリッジが見つかった場合に、前記特定のディスパッチャのための当該カートリッジを予約し、」と記載されている。
ところで、明細書の発明の詳細な説明において「経路」という語は【0046】、【0047】、【0056】にのみ下記のように記載されている。

「【0046】
ディスパッチャ
ディスパッチャは、リスナが受取ったリクエストを適当なカートリッジへ経路選択するよう構成されるソフトウェアモジュールである。この発明の一実施例によれば、ディスパッチャはサーバ側のプログラム拡張(すなわち、「プラグイン」)として実現される。そのため、ディスパッチャはそれらが属するリスナと同じアドレス空間にロードされそこで実行される。ディスパッチャはコンパイル時にリスナコードとリンクされてもよいし、実行時に動的にロードされてもよい。
【0047】
例示される実施例では、ディスパッチャ214、220および226はそれぞれ、リスナ210、216および222に関連付けられる。ディスパッチャ214、220および226は、リスナ210、216および222が受取ったブラウザリクエストをカートリッジへ選択的に経路制御する。」

「【0056】
仮想パスマネージャ
上に述べたように、ディスパッチャは仮想パスマネージャ250と通信して各々の変更されたブラウザリクエストをどこに経路選択するかを定める。特定的には、各ブラウザリクエストは典型的にURLを含む。ブラウザリクエストを受取ると、ディスパッチャはそのリクエスト内のURLを仮想パスマネージャ250に送る。仮想パスマネージャ250はこれに応答して、もしあれば、URLに関連付けられるカートリッジを識別するデータをディスパッチャに送る。」

上記で示した箇所の記載から、明細書の発明の詳細な説明においては、「経路」という語は、ディスパッチャと仮想パスマネージャが協働して、ブラウザリクエストに含まれるURLに関連付けられるカートリッジを識別するデータを特定して、ブラウザリクエストを処理すべきカートリッジを判定することについて用いられているといえる。
その一方、明細書の発明の詳細な説明において「リソースマネージャ」について下記のように記載されている。

「【0060】
リソースマネージャ
ウェブアプリケーションサーバ280のリソースマネージャ254は、カートリッジに対して予め定められた最小数のインスタンスをイニシエートし、各カートリッジのインスタンスの間で負荷の最適配分を行ない、所与のカートリッジの予め定められた最大数のインスタンスまで必要に応じてカートリッジの新しいインスタンスをイニシエートすることによってカートリッジの各々の実行を管理する。
【0061】
たとえば、ある特定のカートリッジ(C1)のためのメタデータが以下の情報を含んでいると仮定する。
【0062】
名称=C1
最小インスタンス=10
最大インスタンス=50
ホストマシン=M1、M3、M8
アイドルタイム=30秒
このメタデータに基づいて、カートリッジC1が初めに登録される際に、リソースマネージャ254はC1の10のインスタンスをイニシエートさせる。リソースマネージャ254はラベルM1、M3およびM8に関連付けられるマシン上の10のインスタンスをイニシエートすることになる。
【0063】
C1をアクセスするリクエストをディスパッチャから受取った際、リソースマネージャ254はC1のいずれかの既存のインスタンスが利用可能であるかどうかを判定する。リクエストを受取った際にC1のどのインスタンスも利用可能でない場合、リソースマネージャ254はC1の最大数のインスタンスが既に実行されているかどうかを判定する。C1の最大数のインスタンスが既に実行されていない場合、リソースマネージャ254は可能なホストマシンの1つの上でC1の新しいインスタンスをイニシエートし、リクエストを発行したディスパッチャにこの新しいインスタンスを識別するメッセージを送信する。C1の最大数のインスタンスが既に実行されている場合、リソースマネージャ254はリクエストを発行したディスパッチャに対し、その時点でそのリクエストを取扱うことができないことを示すメッセージを送る。」

「【0073】
ディスパッチャとリソースマネージャとの相互作用
上述のように、ディスパッチャは特定のカートリッジに変更されたブラウザリクエストを送る必要がある際にリソースマネージャ254と通信する。この発明の一実施例によれば、ディスパッチャはまず、適当なカートリッジのインスタンスが(1)これに既に割当てられているかどうか、また(2)新しい変更されたブラウザリクエストを処理するのに利用可能であるかどうかを判定する。適当なカートリッジインスタンスがディスパッチャに既に割当てられており新しい変更されたブラウザリクエストを処理するのに現在利用可能である場合、ディスパッチャはリソースマネージャ254とさらに通信することなく、変更されたブラウザリクエストをカートリッジインスタンスへ転送する。
【0074】
たとえば、仮想パスマネージャ250によればカートリッジC1が処理しなければならないブラウザリクエストをリスナ210が受取ったと仮定する。また、表400がリスナ210に割当てられたカートリッジインスタンスの現在のリストおよびステータスを反映すると仮定する。リスナ210からブラウザリクエストを受取ると、ディスパッチャ214は表400を調べてカートリッジC1のFREEインスタンスがあるか探す。例示される表400では、行410がカートリッジC1のインスタンス3が現在FREEであることを示している。したがって、ディスパッチャ214はさらにリソースマネージャ254と通信することなく変更されたブラウザリクエストを直接カートリッジC1のインスタンス3に転送する。変更されたブラウザリクエストを送ることに応答してディスパッチャ214は行410のステータス列406のステータス値をBUSYに変える。
【0075】
リスナに現在利用可能である適当なカートリッジインスタンスが既に割当てられていない場合、カートリッジに関連づけられるディスパッチャはリソースマネージャ254からのカートリッジインスタンスをリクエストする。必要とされるカートリッジのインスタンスが利用可能でなく、かつ必要とされるカートリッジの既存のインスタンスの数が最大数より下であることをリソースマネージャ254が判定した場合、リソースマネージャ254は新しいカートリッジをイニシエートする。新しいカートリッジをイニシエートする際に、リソースマネージャ254は表500に新しいカートリッジインスタンスのためのエントリを挿入する。
【0076】
たとえば、カートリッジC3が処理しなければならないブラウザリクエストをリスナ210が受取ったと仮定する。また、カートリッジC3のインスタンス3がまだイニシエートされていないものと仮定する。こうした条件の下では、ディスパッチャ214はリソースマネージャ254にカートリッジC3のインスタンスに対するハンドルを求めるリクエストを送る。このリクエストに応答して、リソースマネージャ254はマシンM3上でカートリッジC3のインスタンス3をイニシエートする。さらに、リソースマネージャ254は行512に見られるエントリを表500に挿入する。
【0077】
表500にカートリッジC3のインスタンス3のための行512を挿入した後、リソースマネージャ254はディスパッチャ214に新しく作られたインスタンスに対するハンドルを送り返す。このハンドルを受取ったことに応答して、ディスパッチャ214はそのステータス表400に新しいインスタンスのためのエントリ(行412)を挿入する。ディスパッチャ214はそこで、変更されたブラウザリクエストをカートリッジC3のインスタンス3に送信する。」

上記で示した箇所の記載から、明細書の発明の詳細な説明においては、「リソースマネージャ」は、ディスパッチャからカートリッジのインスタンスの割り当てを要求するリクエストを受け取ったときに、割り当てるインスタンスを定め、その割り当てるインスタンスを識別するデータ(ハンドル)をディスパッチャに送るものであるといえる。そして、明細書の発明の詳細な説明には、「リソースマネージャ」の動作に関連して「経路」という語を用いた箇所はない。つまり、明細書の発明の詳細な説明においては、「リソースマネージャ」は、カートリッジのインスタンスを選択して、ディスパッチャに当該インスタンスを割り当てるものではあるが、補正後の請求項10に記載されているような「カートリッジへの経路を選択」するものであるとはいえない。
したがって、「リソースマネージャ」と「カートリッジへの経路を選択」することの関係に関して、補正後の請求項10に係る発明は明細書の発明の詳細な説明に記載したものであるとはいえない。つまり、補正後の請求項10に関して、本願は平成14年法律第24号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第36条第6項第1号の規定を満たさない。
「リソースマネージャ」と「カートリッジへの経路を選択」することの関係について、補正後の請求項1、請求項8、請求項13、及び、請求項15にも同趣旨の記載があるので、結局のところ、補正後の全ての請求項についても同様である。

2の3の2の3.リソースマネージャと予約について
補正後の請求項10に「前記複数のディスパッチャは、リソースマネージャにリクエストを送信し、前記リソースマネージャは、一つの特定のディスパッチャからの特定のリクエストに応じて、前記特定のリクエストに対応する処理を実行する、前記複数のディスパッチャによって使用されていないカートリッジへの経路を選択し、前記カートリッジが見つかった場合に、前記特定のディスパッチャのための当該カートリッジを予約し、」と記載されている。
ところで、「2の3の2の2.リソースマネージャと経路について」の項で指摘したように、明細書の発明の詳細な説明においては、「リソースマネージャ」は、カートリッジのインスタンスを選択して、ディスパッチャに当該インスタンスを割り当てるものである。しかしながら、明細書の発明の詳細な説明には、「リソースマネージャ」に関連して「割当」という語は記載されているものの、「予約」という語は一切記載されていない。そして、「予約」と「割当」が同じ意味を有するわけでなく、「予約」という語は、「割当」という語が有する意味を超えて、事前に、または、あらかじめ、という意味をも含むものである。つまり、明細書の発明の詳細な説明においては、「リソースマネージャ」は、カートリッジのインスタンスの割当を行うものであるが、補正後の請求項10に記載されているような、ディスパッチャからのリクエストに応じて「予約」を行うものであるとはいえない。
したがって、「リソースマネージャ」と「予約」の関係に関して、補正後の請求項10に係る発明は明細書の発明の詳細な説明に記載したものであるとはいえない。つまり、補正後の請求項10に関して、本願は平成14年法律第24号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第36条第6項第1号の規定を満たさない。
「リソースマネージャ」と「予約」の関係について、補正後の請求項1、請求項8、請求項13、及び、請求項15にも同趣旨の記載があるので、結局のところ、補正後の全ての請求項についても同様である。

2の3の3.独立特許要件の小括
このように、本件補正が仮に平成14年法律第24号改正附則第2条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項第2号で規定される限定的減縮の目的を有するものであるとしても、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に違反する。

2の4.特許法第17条の2第3項の規定の検討
「2の3の2.特許法第36条第6項第1号の規定を満たすか否かの検討」において、補正後の各請求項に係る発明は明細書の発明の詳細な説明に記載したものではないことを指摘した。本件補正により、このような指摘に該当するようになったのであるから、本件補正は、当初翻訳文に記載した事項の範囲内においてしたものとはいえない。
このように、本件補正は、平成14年法律第24号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第184条の12第2項で読み替える同法第17条の2第3項の規定に違反する。

2の5.補正却下の決定のむすび
したがって、本件補正は、平成14年法律第24号改正附則第2条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。
また、本件補正が仮に平成14年法律第24号改正附則第2条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第4項第2号で規定される限定的減縮の目的を有するものであるとしても、本件補正は、平成18年法律第55号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第17条の2第5項において準用する同法第126条第5項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。
さらに、本件補正は、平成14年法律第24号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第184条の12第2項で読み替える同法第17条の2第3項の規定に違反するので、同法第159条第1項において読み替えて準用する同法第53条第1項の規定により却下すべきものである。

よって、上記補正却下の決定の結論のとおり決定する。

第3.本願発明の認定
平成22年9月9日付けの手続補正は「第2.補正却下の決定」のとおり却下された。
平成22年2月1日付けの手続補正により補正された、本願の特許請求の範囲の請求項10には下記のとおり記載されている。

「分散システムのカートリッジに分散を意識させない態様でオペレーションを行なわせるための方法であって、前記分散システムは、第1のマシンと第2のマシンとを含み、前記第1のマシンと前記第2のマシンとは異なるものであり、前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり、
ある特定のマシン上で前記カートリッジを実行するステップと、
前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内のディスパッチャから前記カートリッジに複数のリクエストを渡すステップとを含み、前記カートリッジ実行エンジンは前記カートリッジの実行を制御し、前記リクエストは標準カートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され、
前記カートリッジに関連付けられる前記カートリッジ実行エンジンを介して返答を前記カートリッジから前記ディスパッチャに渡すステップとを含み、
前記複数のリクエストの各リクエストは、ユニフォーム・リソース・ロケータ(URL)を含み、前記ディスパッチャは、URLをカートリッジにマッピングするメタデータを調べる仮想パスマネージャに対して、当該URLを送信することにより、前記経路を選択し、
前記仮想パスマネージャが、前記メタデータに基づいて、前記カートリッジが前記URLにマッピングされることを判断して、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより、前記ディスパッチャに応答するステップと、
前記カートリッジは、前記分散システムにおける複数のカートリッジの1つであり、
前記複数のカートリッジの各々特定のカートリッジは、前記標準通信インターフェイスを介してリクエストを受信し、
前記カートリッジ実行エンジンおよび前記カートリッジは前記第1のマシン上で実行しており、
前記ディスパッチャは前記第2のマシン上で実行しており、
各前記ステップは、1つ以上のコンピュータプロセッサで実行される、方法。」

平成22年3月4日付け最後の拒絶理由通知における、【理由A】の(2)と(3)、【理由B】の(1)と(2)、【理由C】の(1)と(2)に示されるように、上記した請求項10の記載において「前記標準通信インターフェイス」の部分は適切なものではなく、上記した請求項10の記載ぶりや当初翻訳文から考慮すれば、上記した請求項10の記載における「前記標準通信インターフェイス」の部分は誤記であり、正しくは「前記標準カートリッジインターフェイス」である。(同拒絶理由通知を受けた請求人が、平成22年9月9日付け手続補正において、請求項10の「前記標準通信インターフェイス」の部分を「前記標準カートリッジインターフェイス」と補正しようとしたことからも、上記した誤記に関する検討は妥当なものであるといえる。)
また、同拒絶理由通知における、【理由A】の(4)と(5)に示されるように、上記した請求項10の記載において「前記経路」の部分は適切なものではなく、「前記経路」の部分のうち、少なくとも「前記」という語を付すのは適切でない。
さらに、上記した請求項10の記載において「前記仮想パスマネージャが、前記メタデータに基づいて、前記カートリッジが前記URLにマッピングされることを判断して、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより、前記ディスパッチャに応答するステップと、」という部分の末尾における「ステップと、」は誤記であり、正しくは「ステップとを含み、」である。
これらのことを考慮して、本願の請求項10に係る発明(以下、「本願発明」という。)は、上記した請求項10の記載において、「前記標準通信インターフェイス」の部分を「前記標準カートリッジインターフェイス」とし、「前記経路」の部分を「経路」とし、「前記仮想パスマネージャが、前記メタデータに基づいて、前記カートリッジが前記URLにマッピングされることを判断して、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより、前記ディスパッチャに応答するステップと、」の末尾における「ステップと、」を「ステップとを含み、」とした、以下のとおりのものと認められる。

「分散システムのカートリッジに分散を意識させない態様でオペレーションを行なわせるための方法であって、前記分散システムは、第1のマシンと第2のマシンとを含み、前記第1のマシンと前記第2のマシンとは異なるものであり、前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり、
ある特定のマシン上で前記カートリッジを実行するステップと、
前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内のディスパッチャから前記カートリッジに複数のリクエストを渡すステップとを含み、前記カートリッジ実行エンジンは前記カートリッジの実行を制御し、前記リクエストは標準カートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され、
前記カートリッジに関連付けられる前記カートリッジ実行エンジンを介して返答を前記カートリッジから前記ディスパッチャに渡すステップとを含み、
前記複数のリクエストの各リクエストは、ユニフォーム・リソース・ロケータ(URL)を含み、前記ディスパッチャは、URLをカートリッジにマッピングするメタデータを調べる仮想パスマネージャに対して、当該URLを送信することにより、経路を選択し、
前記仮想パスマネージャが、前記メタデータに基づいて、前記カートリッジが前記URLにマッピングされることを判断して、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより、前記ディスパッチャに応答するステップとを含み、
前記カートリッジは、前記分散システムにおける複数のカートリッジの1つであり、
前記複数のカートリッジの各々特定のカートリッジは、前記標準カートリッジインターフェイスを介してリクエストを受信し、
前記カートリッジ実行エンジンおよび前記カートリッジは前記第1のマシン上で実行しており、
前記ディスパッチャは前記第2のマシン上で実行しており、
各前記ステップは、1つ以上のコンピュータプロセッサで実行される、方法。」

この本願発明は、同拒絶理由通知の【理由E】における「本願請求項10記載の発明」に相当する。

第4.平成22年3月4日付け最後の拒絶理由通知で通知した拒絶理由
平成22年9月9日付けの手続補正は「第2.補正却下の決定」のとおり却下された。これを踏まえて、平成22年3月4日付け最後の拒絶理由通知で通知した拒絶理由を以下の項目にて検討する。
平成22年3月4日付け最後の拒絶理由通知で通知した拒絶理由は下記のとおりである。

「【理由A】この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第6項第2号に規定する要件を満たしていない。

記

(1)請求項1に記載されている「第1のマシン」、「第2のマシン」と、請求項1に記載されている「1つ以上のコンピュータプロセッサ」の関係が不明であり、請求項1の記載は明確ではない。前記「1つ以上のコンピュータプロセッサ」とは、前記「第1のマシン」、「第2のマシン」が有しているコンピュータプロセッサであるのか、或いは、前記「第1のマシン」、「第2のマシン」の外部に存在するコンピュータプロセッサであるのか、どちらであるのか不明である。外部に存在するコンピュータプロセッサであるとすると、該コンピュータプロセッサと、前記「第1のマシン」、「第2のマシン」とはどのような接続関係にあるのかも、請求項1の記載からは不明である。同様の記載を有する請求項10にも、同様の記載不備がある。同様の記載を有する請求項15にも、同様の記載不備がある(請求項15は、「コンピュータプロセッサ」ではなく「プロセッサ」という表記になっている点を除けば、請求項1について上述した記載不備と同様の記載不備を有している)。請求項1、10、15を引用して記載されているその他の請求項についても、同様の記載不備がある。

(2)請求項10には「前記標準通信インターフェイス」という記載が存在するが、この記載よりも前には「標準通信インターフェイス」は記載されていない(すなわち、「前記」されていない)ので、請求項10の「前記標準通信インターフェイス」という記載は矛盾しており、請求項10の記載は明確ではない。請求項10を引用して記載されているその他の請求項についても、同様の記載不備がある。

(3)請求項10の「標準通信インターフェイス」と、請求項10の「標準カートリッジインターフェイス」の関係が不明であり、請求項10の記載は明確ではない(同じものであるならば用語を統一すべきであるし、別のものであるならば両者の関係が明確になるように請求項10を記載されたい)。同様の記載を有する請求項15にも、同様の記載不備がある。請求項10、15を引用して記載されているその他の請求項についても、同様の記載不備がある。

(4)請求項10には「前記経路」という記載が存在するが、この記載よりも前には「経路」は記載されていない(すなわち、「前記」されていない)ので、請求項10の「前記経路」という記載は矛盾しており、請求項10の記載は明確ではない。同様の記載を有する請求項15にも、同様の記載不備がある。請求項10、15を引用して記載されているその他の請求項についても、同様の記載不備がある。

(5)請求項10には「前記経路」という記載が存在するが、何の経路であるのか不明であり、したがって請求項10の記載は明確ではない。同様の記載を有する請求項15にも、同様の記載不備がある。請求項10、15を引用して記載されているその他の請求項についても、同様の記載不備がある。

(6)請求項8には「前記カートリッジの各々は標準カートリッジインターフェイスを介して呼出される「exec()」ルーチンを含み」、「前記複数のカートリッジ内の前記「exec()」ルーチン」、「特定のカートリッジ内のexec()ルーチン」という記載が存在し、これらの記載は、「カートリッジ」の中に「exec()ルーチン」が含まれているという趣旨の記載である。しかしながら、これらの記載は、「カートリッジ」の中に含まれているルーチンの名前が「exec()」という名前であるに過ぎないという趣旨であるのか、或いは、特定の性質や特徴を備えたルーチンを意味する用語として「exec()ルーチン」という用語を用いているのか、どちらであるのか不明である。また、仮に、特定の性質や特徴を備えたルーチンを意味する用語として「exec()ルーチン」という用語を請求項8において用いていると仮定すると、当該「特定の性質や特徴」とは何であるのかも不明である。したがって、請求項8の記載は明確ではない。同様の記載を有するその他の請求項についても、同様の記載不備がある。
(以上、理由A)

【理由B】特許法第184条の4第1項の規定により、平成12年4月28日付けで明細書の翻訳文(以下、「当初翻訳文」という。)及び翻訳図面(以下、「当初翻訳図面」という。)が提出されており、これら当初翻訳文及び当初翻訳図面は、特許法第184条の6第2項の規定により、願書に最初に添付された明細書及び図面とみなされるものであるが、平成22年2月1日付けでした手続補正は、下記の点で当初翻訳文又は当初翻訳図面に記載した事項の範囲内においてしたものではないから、特許法第17条の2第3項に規定する要件を満たしていない。

記

(1)請求項10、15の「標準通信インターフェイス」は、当初翻訳文にも当初翻訳図面にも記載されておらず、当初翻訳文又は当初翻訳図面の記載から自明でもない。請求項10、15を引用して記載されているその他の請求項についても同様。

(2)請求項10、15には、「標準カートリッジインターフェイス」とは別に「標準通信インターフェイス」が存在し、該「標準通信インターフェイス」を用いて「カートリッジ」が「リクエスト」を「受信」する旨の記載が存在するが、そのようなことは当初翻訳文にも当初翻訳図面にも記載されておらず、当初翻訳文又は当初翻訳図面の記載から自明でもない。請求項10、15を引用して記載されているその他の請求項についても同様。

(3)請求項10には、「前記複数のリクエストの各リクエストは、ユニフォーム・リソース・ロケータ(URL)を含み」という記載(以下、便宜的に「記載A」という。)が存在し、この記載Aは、「リクエスト」が「ユニフォーム・リソース・ロケータ(URL)」を「含」んでいるという趣旨(以下、便宜的に「趣旨B」という。)を含む記載である。
一方、請求項10には、「前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内のディスパッチャから前記カートリッジに複数のリクエストを渡すステップとを含み、前記カートリッジ実行エンジンは前記カートリッジの実行を制御し、前記リクエストは標準カートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され」という記載(以下、便宜的に「記載C」という。)が存在し、この記載Cは、「リクエスト」は、「ディスパッチャ」から「カートリッジ実行エンジン」を介して「カートリッジ」に渡されるという趣旨(以下、便宜的に「趣旨D」という。)と、「リクエスト」は「標準カートリッジインターフェイス」を介して「カートリッジ実行エンジン」から「カートリッジ」に渡されるという趣旨(以下、便宜的に「趣旨E」という。)とを含む記載である。
そして、請求項10において、前記記載Aよりも前に「複数のリクエスト」という記述が出現するのは前記記載C内のみであることから、前記記載Aに含まれる「前記複数のリクエスト」は、前記記載Cに含まれる「複数のリクエスト」を指すという解釈しかできない。
すると、前記記載Aが含む前記趣旨Bと、前記記載Cが含む前記趣旨Dとを総合することで得られる、「ユニフォーム・リソース・ロケータ(URL)」を「含」んでいる「リクエスト」が、「ディスパッチャ」から「カートリッジ実行エンジン」を介して「カートリッジ」に渡されるという趣旨、すなわち、「ユニフォーム・リソース・ロケータ(URL)」そのものが「ディスパッチャ」から「カートリッジ実行エンジン」を介して「カートリッジ」に渡されるという趣旨(以下、便宜的に「趣旨F」という。)を、請求項10は含むことになる。
同様に、前記記載Aが含む前記趣旨Bと、前記記載Cが含む前記趣旨Eとを総合することで得られる、「ユニフォーム・リソース・ロケータ(URL)」を「含」んでいる「リクエスト」が、「標準カートリッジインターフェイス」を介して「カートリッジ実行エンジン」から「カートリッジ」に渡されるという趣旨、すなわち、「ユニフォーム・リソース・ロケータ(URL)」そのものが「標準カートリッジインターフェイス」を介して「カートリッジ実行エンジン」から「カートリッジ」に渡されるという趣旨(以下、便宜的に「趣旨G」という。)を、請求項10は含むことになる。
しかしながら、前記趣旨F及び趣旨Gは、当初翻訳文にも当初翻訳図面にも記載されておらず、当初翻訳文及び当初翻訳図面の記載から自明でもない。
当初翻訳文の段落【0003】、【0037】、【0048】、【0053】、【0056】?【0059】には、

「【0003】
ワールド・ワイド・ウェブのユーザはブラウザと呼ばれるクライアントプログラムを用いてリスナから情報をリクエストし、デコードし、表示する。ブラウザのユーザがあるHTMLページ上のリンクを選択すると、そのページを表示しているブラウザはそのリンク内で特定されるユニバーサル・リソース・ロケータ(URL:Universal Resource Locator)と関連付けられるリスナにインターネットを通じてリクエストを送る。そのリクエストに応答して、リスナはそのリクエストを発行したブラウザにリクエストされた情報を送信する。ブラウザは情報を受取り、受取った情報をユーザに示し、次のユーザリクエストを待つ。」、

「【0037】
カートリッジ
カートリッジは特定のアプリケーションまたはシステム機能を行なうためのコードのモジュールである。カートリッジはシステム200における分散の基本単位を形成する。この発明の一実施例によれば、カートリッジはユニバーサル・リソース・ロケータ(URL)を用いて名付けられる。すなわち、カートリッジ名には2つの部分、すなわちカートリッジが存在するサーバのIPアドレスと、コンパイルされたカートリッジコードのサーバディレクトリ構造における仮想パスとがある。カートリッジはURLを用いて名付けられるため、カートリッジ名空間はグローバルであり、文書などの他のウェブリソースにアクセスするのに用いられるのと同じメッセージ通信技術を用いてカートリッジにアクセスすることができる。」、

「【0048】
たとえば、リスナ210がユニフォーム・リソース・ロケータ(URL:Uniform Resource Locator)の形態で運ばれるブラウザリクエストをインターネット208から受取ると仮定する。このブラウザリクエストは、たとえばHTMLページまたは実行すべきオペレーションであるウェブオブジェクトに対する識別子の役割を果たす。リスナ210はそのブラウザリクエストの解釈を全く試みることなくディスパッチャ214に受渡す。ブラウザリクエストを受取ると、ディスパッチャ214は、
(1)仮想パスマネージャ250と通信してブラウザリクエストによって選択されるカートリッジを識別し、かつそのカートリッジが認証を要するかどうかを判定し、
(2)そのカートリッジが認証を必要とする場合、認証サーバ252と通信してブラウザがその選択されたカートリッジにアクセスすることが許されるかどうかを判定し、
(3)アクセスが許可された場合に、リソースマネージャと通信してブラウザリクエストを送るべき選択されたカートリッジの特定のインスタンスを定め、
(4)カートリッジの特定されたインスタンスによる実行のため、変更されたブラウザリクエストを作りかつディスパッチする。」、

「【0053】
オブジェクト識別子は、対応するカートリッジによるオペレーションの実行をリクエストするためにブラウザリクエストが供給しなければならないデータを特定する。オブジェクトタイプは特定のワードまたはURLであってもよく、または「/java」などの仮想パスを含んでいてもよい。」、

「【0056】
仮想パスマネージャ
上に述べたように、ディスパッチャは仮想パスマネージャ250と通信して各々の変更されたブラウザリクエストをどこに経路選択するかを定める。特定的には、各ブラウザリクエストは典型的にURLを含む。ブラウザリクエストを受取ると、ディスパッチャはそのリクエスト内のURLを仮想パスマネージャ250に送る。仮想パスマネージャ250はこれに応答して、もしあれば、URLに関連付けられるカートリッジを識別するデータをディスパッチャに送る。
【0057】
必要とされる情報をディスパッチャに供給するため、仮想パスマネージャ250はURLをカートリッジにマッピングするメタデータ258を調べる。ブラウザリクエストを受取ったことに応答して、仮想パスマネージャ250はマッピングデータを用いて、もしあれば、ブラウザリクエストに含まれるURLに対応するカートリッジを判定する。
【0058】
たとえば、ブラウザリクエストが仮想パス「/java」で始まるURLリクエストである場合、マッピングにより、JAVAインタプリタカートリッジが仮想パス「/java」を有するリクエストを取扱うよう構成されていることが示されるかもしれない。
【0059】
この発明の一実施例によれば、仮想パスマネージャ250はまた、URLに関連付けられたカートリッジが認証を必要とするかどうかを判定する。カートリッジが認証を要する場合、仮想パスマネージャ250はディスパッチャに送る応答において、認証が必要であることを示す。認証が必要でない場合、ディスパッチャは認証サーバ252を呼出すことなく、カートリッジのインスタンスに対する変更されたブラウザリクエストを作って送る。認証が必要である場合、変更されたリクエストをカートリッジのインスタンスに送出してもよいことを認証サーバが示した後に初めてディスパッチャはそのカートリッジのインスタンスに変更されたリクエストを送る。」

という記載が存在するが、前記趣旨Fのように「ユニフォーム・リソース・ロケータ(URL)」そのものが「ディスパッチャ」から「カートリッジ実行エンジン」を介して「カートリッジ」に渡されることや、前記趣旨Gのように、「ユニフォーム・リソース・ロケータ(URL)」そのものが「標準カートリッジインターフェイス」を介して「カートリッジ実行エンジン」から「カートリッジ」に渡されることは、当初翻訳文にも当初翻訳図面にも記載されておらず、当初翻訳文又は当初翻訳図面に記載した事項から自明でもない。
したがって、請求項10についてした補正は、当初翻訳文又は当初翻訳図面に記載した事項の範囲内で行われていない。
請求項10と同様の記載を有する請求項1?9、11?17についても、同様に、当初翻訳文又は当初翻訳図面に記載した事項の範囲内で補正が行われていない。
(以上、理由B)

【理由C】この出願は、特許請求の範囲の記載が下記の点で、特許法第36条第6項第1号に規定する要件を満たしていない。

記

(1)請求項10、15の「標準通信インターフェイス」に対応する記載は、発明の詳細な説明に記載されていない。したがって、請求項10、15として記載されている特許を受けようとする発明が、発明の詳細な説明に記載したものではない。請求項10、15を引用して記載されているその他の請求項についても同様の記載不備がある。

(2)請求項10、15には、「標準カートリッジインターフェイス」とは別に「標準通信インターフェイス」が存在し、該「標準通信インターフェイス」を用いて「カートリッジ」が「リクエスト」を「受信」する旨の記載が存在するが、これに対応する記載は、発明の詳細な説明に記載されていない。したがって、請求項10、15として記載されている特許を受けようとする発明が、発明の詳細な説明に記載したものではない。請求項10、15を引用して記載されているその他の請求項についても同様の記載不備がある。

(3)請求項1?17には、前記【理由B】の(3)で指摘した趣旨F及び趣旨Gが記載されているが、そのようなことは発明の詳細な説明には記載されていない。したがって、請求項1?17として記載されている特許を受けようとする発明が、発明の詳細な説明に記載したものではない。
(以上、理由C)

【理由D】この出願は、発明の詳細な説明の記載が下記の点で、特許法第36条第4項に規定する要件を満たしていない。

記

(1)請求項10、15、並びに、請求項10、15をそれぞれ引用して記載されているその他の請求項には、「標準通信インターフェイス」が記載されているが、この「標準通信インターフェイス」の具体的な実現手法が、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。

(2)請求項10、15、並びに、請求項10、15をそれぞれ引用して記載されているその他の請求項には、「標準カートリッジインターフェイス」とは別に「標準通信インターフェイス」が存在し、該「標準通信インターフェイス」を用いて「カートリッジ」が「リクエスト」を「受信」する旨の記載が存在するが、この記載の具体的な実現手法が、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない。

(3)当初翻訳文の段落【0038】?【0043】には、

「【0038】
この発明の一実施例によれば、各カートリッジはすべてのカートリッジに対して共通の全体構造をもたらす標準インターフェイスを有する。この標準インターフェイスは、特定の条件の下でウェブアプリケーションサーバ280により呼出されるルーチンのインターフェイスを規定する。この発明の一実施例によれば、抽象カートリッジインターフェイスは以下のとおりである。
【0039】
【表1】
interface Cartridge
{
boolean init();
boolean authenticate(in Principal user_passwd);
boolean exec(in Request req_obj, out Response resp_obj);
boolean shutdown();
}

【0040】
init()ルーチンはカートリッジインスタンスを初期化する役割を果たす。このことには、いくつかのサブオブジェクトのコンストラクタを呼出すことと、スレッドを予め分岐させることと、他のすべての必要となる共用リソースを獲得することとが含まれ得る。
【0041】
shutdown()ルーチンはすべてのリソースを片付けカートリッジインスタンスをシャットダウンする役割を果たす。カートリッジインスタンスに対して一度shutdown()ルーチンが呼出されると、直ちにカートリッジインスタンスは後続のリクエストを処理するのに利用不可能となる。
【0042】
authenticate()ルーチンではカートリッジのサービスをリクエストしているクライアントがそのサービスを用いることを許可されているかどうかを検証する。
【0043】
exec()ルーチンはカートリッジに対してすべてのサービスリクエストをディスパッチする包括的なやり方である。」

という記載が存在するが、前記段落【0043】に記載されている「包括的なやり方」とは、具体的にどのような手法であるのか不明である。また、前記段落【0039】のexecというルーチンの引数として使用されている「Request req_obj」、「Response resp_obj」というのが、具体的にどのような引数であるのかも不明である。当初翻訳文の段落【0044】?【0045】には「各カートリッジは、明確に定義された機能を行なうカートリッジとして構成されるか、またはあるアプリケーションのためのインタプリタまたはルーチン環境として作用するプログラム可能なカートリッジとして構成される。プログラム可能なカートリッジの一例はPL/SQLランタイムであり、(中略)プログラム可能なカートリッジの別の例はJAVAランタイムインタプリタである。(中略)同様に、たとえば第三者のサーバによって実行されるプロセスにアクセスするなどの動的オペレーションをもたらすために、カスタムサーバをカートリッジとして構成してもよい」と記載されているように、本願発明では、異なる処理を行う複数の種類のカートリッジが存在することが前提となっており、そのような異なる処理を行う複数のカートリッジのそれぞれが使用する引数(前記「Request req_obj」と前記「Response resp_obj」)は、当然ながら各カートリッジごとに異なる筈であって共通ではない筈であるから、前記段落【0043】の「包括的なやり方」という記載と矛盾せずにカートリッジごとに異なる引数を授受する手法が不明である。したがって、発明の詳細な説明は、当業者が実施できる程度に明確かつ十分に記載されていない。
(以上、理由D)

【理由E】この出願の下記の請求項に係る発明は、その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。

記

・請求項1?17
引用文献:
1.斎藤圭、「Oｒacle WebSeｒｖeｒ 2.0」、月刊Oｒacle LIFE(月刊オラクルライフ)、株式会社ビー・エヌ・エヌ、1996年12月13日、第1巻第7号(通巻第7号)、第40?43頁

2.斎藤淳(外1名),「OPOアプリケーションがブラウザ上で快適に動作 Oracle Web Server2.0とPower Objects2.0」,日経オープンシステム,日経BP社,1996年12月15日,第45号,第197?206頁,ISSN:0918-581X

備考:
(1)請求項10について
引用文献1には、図面とともに以下の(1-1)?(1-7)の記載が存在する(なお、下線部は便宜的に当審において付与したもの。以下同じ。)。

(1-1)「次に、Oracle WebServer2.0の主要な3つのコンポーネントである、Web Listener、Web Request Broker、そしてWebServer SDKについて、くわしく解説する。
■Oracle Web Listener
Web Listenerは入ってくるリクエストをWeb Request Brokerに引き渡す。引き渡されたリクエストはWeb Request Brokerで処理されるか、WebServer SDKで構築されたサービスヘディスパッチされる。
オラクルのHTTP Serverは、優れた拡張性を備えた高性能ネットワーク・デーモンとして設計されている。これは、マルチスレッドの単一プロセス非同期エンジンとしてインプリメントされ、標準HTTP、またはSSL上のHTTP を利用して、複数の並行リクエストが同時に処理できるようになっている。HTTP Serverは、Oracle WebServerのレイヤ・コンポーネントである。これは、入ってくるHTTPリクエストを待ち受け、スタティックなファイルを配信し、単純なCGIプログラムを実行するが、それ以外の作業はすべてWeb Request Broker(WRB)にまかせてしまい、WRBでサーバ拡張機能がリクエストを処理する。」(第41頁左コラム第8行?同頁中央コラム第7行)

(1-2)「このような問題に対して、Oracle WebServer 2.0では、2つの基礎的なコンポーネントから成り立つものと考え、それを効果的に重ねるというアーキテクチャを採用している。基礎的な2つの層とは、HTTPエンジン(Oracle Web Listener)と、それとは別のプロセスで稼働するサーバの拡張機能にリクエストを経路指定する高速ディスパッチ・メカニズム(Web Request Broker)である」(第41頁右コラム第11?19行)

(1-3)「■Web Request Broker
WRB(Web Request Broker)は、オラクルの提供するCGIに代わる新しいWebサーバ拡張機能の仕組みである。WRBは、要求の内容を判断し実行部分に要求を送るWRB Dispatcherと、要求を実際に実行するWRB Serviceから構成されている」(第42頁左コラム第19?25行)

(1-4)「・WRB Dispatcher
WRB Dispatcherはどのような種類の要求がされているのかをWRBの仮想ディレクトリの設定とURLを比べることで判断し、相当するWRB Execution(WRBX)にその要求をディスパッチする。もし、適切なWRB Serviceが存在しない場合、WRB DispatcherはOracle Web Listenerに要求を返す。
WRB Dispatcherは必要な数のWRB Serviceのインスタンスを動的に立ち上げるダイナミック・ロード・バランシングという機能を持っており、サーバ側は常に最適数のインスタンスを持つ仕組みになっている(インスタンスとはUNIXでいうプロセスに相当するものである)。また、サーバ管理者はWRB Serviceのインスタンスの最小値と最大値を決定することできる。これにより、従来のCGIのようにクライアントからの要求の数だけプロセスがサーバに上がりパフォーマンスを落とすというようなこともなく、サーバ側の負荷を管理者の意図するとおり、自動的かつ継続的に、最小に抑えることが可能となっている。
サーバ内でのプロセス間通信は、トランスポートに依存しないWRBプロトコルによって処理されている。WebServer2.0は標準IPCメカニズムをサポートしているが、今後のリリースでは、OracleのCORBA2.0に準拠したObject Request Broker、OMXやその他のメカニズムもサポートする予定である。これにより、WRB Serviceを業界標準の分散オブジェクトとしてインプリメントし、複数ノードにわたって真の分散とスケーラビリティを実現できるようになる」(第42頁左コラム第26行?同頁右コラム第4行)

(1-5)「・WRB Execution Engine
それぞれのWRB Serviceは、共通のWRB Execution Engine(WRBX)と、実行時に動的にロードされる共有ライブラリで構成されている。オープンなWRBXのAPIを提供することで、オラクルはパートナーおよびカスタマーが各自の拡張機能を統合できるようにしている。WRB APIによって、開発者は基本的なコールバック関数をWRBXに登録することができる。サーバとの統合はCGIや多くのHTTPサーバAPIよりもはるかに高いレベルで行われる」(第42頁右コラム第5?16行)

(1-6)「・WRB API
Oracle Web Server2.0では独自の拡張を行いたい開発者のためWRBのオープンなAPI(WRB API)を提供している。開発音はこれを用いてカスタムカートリッジを作成することにより、Oracle WebServerと完全に統合されたアプリケーションの開発をすることが可能となる。このAPIは言語非依存なためCOBOLやC/C++といった開発者の慣れ親しんだ環境での開発を行うことが可能であり、これまでのアプリケーション資産を生かせると共に開発期間を大幅に短縮することが可能となる」(第42頁右コラム第17行?第43頁左コラム第2行)

(1-7)「WebServer SDK
Oracle WebServer 2.0のカートリッジには、適切に定義された関数を実行するシステム・カートリッジと、アプリケーション用のインタープリタまたは実行時環境の役割を果たすプログラム式カートリッジの2つのタイプがある。システム・カートリッジの例としては、Verifone VPOS(Virtual Point Of Sale)カートリッジがある。これは、Webアプリケーション上で電子支払いトランザクションを実行できるようにする(注意:VPOSカートリッジはOracle WebServer 2.0には入っていないが、これに関する詳細はhttp://www.verifone.comで入手できる)。プログラム式カートリッジには、PL/SQL Agent、Java Interpreter、LiveHTMLがある」(第43頁左コラム第3?19行)

引用文献1の上記(1-1)に「次に、Oracle Web Server2.0の主要な3つのコンポーネントである、Web Listener、Web Request Broker、そしてWebServer SDKについて、くわしく解説する」と記載されているように、引用文献1にはOracle Web Server2.0の構成が記載されている。
引用文献1の上記(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)」と「実行時に動的にロードされる共有ライブラリ」とで「それぞれのWRB Service」が構成されるという趣旨の記載が存在することから、以上を総合すると、引用文献1のOracle Web Server2.0においては、WRB Execution Engine(WRBX)と、該WRB Execution Engine(WRBX)からWRB APIを用いて呼び出されるコールバック関数であるところの「カスタムカートリッジ」とが対をなして1つの「WRB Service」を構成するものと解される(なお、上記(1-5)には、「共通のWRB Execution Engine(WRBX)」という記載が存在するが、図1には4個の「WRBX」が図示されていることから、前記「共通」とは、「WRB Execution Engine(WRBX)」が1個だけしか存在しないという意味ではなく、複数存在する「WRB Execution Engine(WRBX)」のそれぞれの構造が共通であるという趣旨と解される。)。また、「コールバック関数」が、呼び出し元に処理結果を返す関数であることは、当業者の技術常識である。
次に、引用文献1の上記(1-4)には、「サーバ内でのプロセス間通信」が、CORBA2.0に準拠したプロトコルで複数ノードに渡って行われる旨の記載が存在し、前記記載に含まれる「サーバ」とは、前記「Oracle Web Server2.0」であると解され、このように前記「Oracle Web Server2.0」は複数のノードを有しているから、前記「WRB Execution Engine(WRBX)」及び前記「カスタムカートリッジ」並びに後述の「WRB Dispatcher」は、それら複数のノードのいずれかの上で実行されるものと解される。
次に、引用文献1の図1には、4つの「WRBX」が図示され、それぞれの「WRBX」に対応付けて「PL/SQL Agenｔ」、「Jaｖaインタープリタ」、「Liｖe HTML Agenｔ」、「カスタムカートリッジ」が図示されていることから、前記「カスタムカートリッジ」は、「PL/SQL Agenｔ」、「Jaｖaインタープリタ」、「Liｖe HTML Agenｔ」と併存するものと解される。
次に、引用文献1の上記(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を介して前記要求を受信するもの)と解される。
次に、引用文献1のOracle Web Server2.0は、上記(1-4)に記載されているように、「WRB Serviceのインスタンスを動的に立ち上げ」るようになっている。前記「WRB Service」のそれぞれは、上述のように、WRB Execution Engine(WRBX)と、該WRB Execution Engine(WRBX)からWRB APIを用いて呼び出されるコールバック関数であるところの「カスタムカートリッジ」とが対になって1つの「WRB Service」を構成するものである。
また、上記(1-4)には、「WRB Dispatcherはどのような種類の要求がされているのかをWRBの仮想ディレクトリの設定とURLを比べることで判断し、相当するWRB Execution(WRBX)にその要求をディスパッチする」という記載が存在する。この記載において、仮想ディレクトリには、URLに相当するWRB Execution(WRBX)を識別するデータ及び、該データとURLとの対応関係が格納されているものと解される。
上記(1-4)の「WRB Dispatcherはどのような種類の要求がされているのかをWRBの仮想ディレクトリの設定とURLを比べることで判断し」という記載における「要求」とは、上記(1-1)の「Web Listenerは入ってくるリクエストをWeb Request Brokerに引き渡す」と記載されているところの、「Web Listener」から引き渡されたリクエストである。そして、上記(1-2)の「HTTPエンジン(Oracle Web Listener)」という記載から、Web ListenerとはHTTPエンジンであるから、「Web Listener」から引き渡されるリクエストとは、HTTPエンジンから引き渡されるリクエストのことである。そして、上記(1-1)の「オラクルのHTTP Serverは、優れた拡張性を備えた高性能ネットワーク・デーモンとして設計されている。これは、マルチスレッドの単一プロセス非同期エンジンとしてインプリメントされ、標準HTTP、またはSSL上のHTTP を利用して、複数の並行リクエストが同時に処理できるようになっている。HTTP Serverは、Oracle WebServerのレイヤ・コンポーネントである。これは、入ってくるHTTPリクエストを待ち受け、スタティックなファイルを配信し、単純なCGIプログラムを実行するが、それ以外の作業はすべてWeb Request Broker(WRB)にまかせてしまい、WRBでサーバ拡張機能がリクエストを処理する」という記載から、HTTPエンジンから引き渡されるリクエストとは、HTTPリクエストである。そして、HTTPリクエストにURLが含まれることは、当業者にとっての技術常識である。以上を総合すると、上記(1-4)の「WRB Dispatcherはどのような種類の要求がされているのかをWRBの仮想ディレクトリの設定とURLを比べることで判断し」という記載における「URL」とは「要求」に含まれているURLであると解される。

したがって、引用文献1には次の発明(以下、「引用発明」という。)が記載されているものと認められる。

(引用発明)
Oracle Web Server2.0のカスタムカートリッジにWRB APIによって呼び出されることにより処理を行わせるための方法であって、
前記Oracle Web Server2.0内のプロセス間通信は、CORBA2.0に準拠したプロトコルで複数ノードに渡って行われるものであり、
前記カスタムカートリッジは前記Oracle Web Server2.0において実行されるソフトウェアであってPL/SQL Agenｔ、Jaｖaインタープリタ、Liｖe HTML Agenｔと併存するものであり、
前記Oracle Web Server2.0内の複数のノードのうちの少なくとも1つのノード上で前記カスタムカートリッジを実行するステップと、
前記カスタムカートリッジと対をなして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は、前記複数のノードのうちのいずれかの上で実行している、方法。

次に、本願請求項10記載の発明と、引用発明とを対比する。

引用発明の「Oracle Web Server2.0」を上位概念化して把握すると、本願請求項10記載の発明の「分散システム」に相当する。
引用発明の「カスタムカートリッジ」を上位概念化して把握すると、本願請求項10記載の発明の「カートリッジ」に相当する。
次に、APIを用いて呼び出されたプログラムは、該APIにおいて取り決められているデータ受け渡し用の記憶領域(例えば、事前に決められたメモリ内のデータ領域又はスタック領域などにおける所定の記憶位置)から、該APIにおいて取り決められているデータ型(例えば1バイトの整数型など)で引数を受け取り、受け取った引数を、事前にプログラマによってプログラミングされたとおりのロジックに基づいて処理し、その処理の結果を前記APIにおいて取り決められているデータ型を用いて前記APIにおいて取り決められているデータ受け渡し用の記憶領域に書き込むことで処理結果を返すようになっており、該APIを用いて呼び出される側のプログラムは、前記データ受け渡し用の記憶領域から読み取った引数に基づいて計算した処理結果を前記データ受け渡し用の記憶領域に書き込むだけであり、呼び出し側のプログラム(前記データ受け渡し用の記憶領域に呼び出し前に引数を書き込み、前記データ受け渡し用の記憶領域から処理結果を読み出す側のプログラム)が、呼ばれる側のプログラムと同じ計算機で動作しているか否かには無関係に、前記事前にプログラマによってプログラミングされたとおりのロジックに基づいて処理を行うだけである(すなわち、分散を意識しない態様で処理を行う)ことは、当業者にとっての技術常識であるから、引用発明の「カスタムカートリッジにWRB APIによって呼び出されることにより処理を行わせる」が、本願請求項10記載の発明の「カートリッジに分散を意識させない態様でオペレーションを行なわせる」に相当する。
次に、引用発明の「ノード」が本願請求項10記載の発明の「マシン」に相当するから、引用発明の「前記Oracle Web Server2.0内のプロセス間通信は、CORBA2.0に準拠したプロトコルで複数ノードに渡って行われるものであり」と、本願請求項10記載の発明の「前記分散システムは、第1のマシンと第2のマシンとを含み、前記第1のマシンと前記第2のマシンとは異なるものであり」とは、ともに、「前記分散システムは、異なる複数のマシンを含み」という点において共通する。
引用発明の「前記カスタムカートリッジは前記Oracle Web Server2.0において実行されるソフトウェアであってPL/SQL Agenｔ、Jaｖaインタープリタ、Liｖe HTML Agenｔと併存するものであり」を上位概念化して把握すると、本願請求項10記載の発明の「前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり」に相当する。
引用発明の「前記Oracle Web Server2.0内の複数のノードのうちの少なくとも1つのノード上で前記カスタムカートリッジを実行するステップ」を上位概念化して把握すると、本願請求項10記載の発明の「ある特定のマシン上で前記カートリッジを実行するステップ」に相当する。
引用発明の「前記カスタムカートリッジと対をなしてWRB Serviceを構成するWRB Execution Engine(WRBX)」を上位概念化して把握すると、本願請求項10記載の発明の「前記カートリッジに関連付けられるカートリッジ実行エンジン」に相当する。
引用発明の「前記Oracle Web Server2.0のWRB Dispatcher」を上位概念化して把握すると、本願請求項10記載の発明の「前記分散システム内のディスパッチャ」に相当する。
したがって、引用発明の「前記カスタムカートリッジと対をなしてWRB Serviceを構成するWRB Execution Engine(WRBX)を介して、前記Oracle Web Server2.0のWRB Dispatcherから前記カスタムカートリッジに要求を渡すステップ」と、本願請求項10記載の発明の「前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内のディスパッチャから前記カートリッジに複数のリクエストを渡すステップ」とは、ともに、「前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内のディスパッチャから前記カートリッジにリクエストを渡すステップ」である点において共通する。
次に、引用発明の「前記WRB Execution Engine(WRBX)と前記カスタムカートリッジとから成る前記WRB Serviceのインスタンスは動的に立ち上げられ」は、「動的に立ち上げ」を上位概念化して把握すると「制御する」と言えることから、本願請求項10記載の発明の「前記カートリッジ実行エンジンは前記カートリッジの実行を制御し」に相当する。
次に、引用発明の「前記要求は、オープンな前記WRB APIを介して前記WRB Execution Engine(WRBX)から前記カスタムカートリッジに渡され」と、本願請求項10記載の発明の「前記リクエストは標準カートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され」とは、ともに、「前記リクエストはカートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され」である点において共通する。
上述のように、引用発明の「前記カスタムカートリッジと対をなしてWRB Serviceを構成するWRB Execution Engine(WRBX)」を上位概念化して把握すると、本願請求項10記載の発明の「前記カートリッジに関連付けられるカートリッジ実行エンジン」に相当するから、引用発明の「前記カスタムカートリッジと対をなしてWRB Serviceを構成するWRB Execution Engine(WRBX)に前記カスタムカートリッジから処理結果を渡すステップ」と、本願請求項10記載の発明の「前記カートリッジに関連付けられる前記カートリッジ実行エンジンを介して返答を前記カートリッジから前記ディスパッチャに渡すステップ」とは、ともに、「前記カートリッジに関連付けられる前記カートリッジ実行エンジンに返答を前記カートリッジから渡すステップ」である点において共通する。
本願の当初翻訳文の段落【0057】には「必要とされる情報をディスパッチャに供給するため、仮想パスマネージャ250はURLをカートリッジにマッピングするメタデータ258を調べる」と記載されているように、「メタデータ」とはURLに対する対応付けを行うためのデータであるから、引用発明の「仮想ディレクトリ」も「メタデータ」の一種であるということができ、したがって、引用発明の「前記要求はURLを含み、前記WRB Dispatcherは、URLを相当するWRB Execution (WRBX)と対応付ける仮想ディレクトリと当該URLとを比べ、前記仮想ディレクトリに基づいて、前記相当するWRB Execution(WRBX)が前記URLに対応付けられることを判断して、前記相当するWRB Execution(WRBX)を識別するデータを知るステップ」と、本願請求項10記載の発明の「前記複数のリクエストの各リクエストは、ユニフォーム・リソース・ロケータ(URL)を含み、前記ディスパッチャは、URLをカートリッジにマッピングするメタデータを調べる仮想パスマネージャに対して、当該URLを送信することにより、前記経路を選択し、前記仮想パスマネージャが、前記メタデータに基づいて、前記カートリッジが前記URLにマッピングされることを判断して、前記カートリッジを識別するデータを前記ディスパッチャに送信することにより、前記ディスパッチャに応答するステップ」とは、ともに、「前記リクエストは、ユニフォーム・リソース・ロケータ(URL)を含み、前記ディスパッチャは、URLをマッピングするメタデータを調べることにより、前記経路を選択し、前記メタデータに基づいて、前記URLにマッピングされることを判断して、マッピングされている対象を識別するデータを前記ディスパッチャが知るステップ」である点において共通する。
引用発明の「前記カスタムカートリッジは、前記Oracle Web Server2.0におけるカスタムカートリッジであり、該カスタムカートリッジは前記WRB APIを介して要求を受け取り」と、本願請求項10記載の発明の「前記カートリッジは、前記分散システムにおける複数のカートリッジの1つであり、前記複数のカートリッジの各々特定のカートリッジは、前記標準通信インターフェイスを介してリクエストを受信し」とは、ともに、「前記カートリッジは、前記分散システムにおけるカートリッジであり、前記カートリッジは、前記カートリッジインターフェイスを介してリクエストを受信し」である点において共通する(なお、本願請求項10には、上記【理由A】の(2)及び(3)並びに上記【理由B】の(1)及び(2)並びに上記【理由C】の(1)及び(2)において指摘した記載不備が存在しているので、現時点では本願請求項10の「前記標準通信インターフェイス」は、正しくは「前記標準カートリッジインターフェイス」とすべき誤記と解釈して検討を行う。)。
引用発明の「前記WRB Execution Engine(WRBX)および前記カスタムカートリッジ並びに前記WRB Dispatcherは、前記複数のノードのうちのいずれかの上で実行している」と、本願請求項10記載の発明の「前記カートリッジ実行エンジンおよび前記カートリッジは前記第1のマシン上で実行しており、前記ディスパッチャは前記第2のマシン上で実行しており」とは、ともに、「前記カートリッジ実行エンジンおよび前記カートリッジ並びに前記ディスパッチャは、前記複数のマシンのいずれかの上で実行している」という点において共通する。

したがって、引用発明と本願請求項10記載の発明は、以下の点で一致し、また、相違する。

(一致点)
分散システムのカートリッジに分散を意識させない態様でオペレーションを行なわせるための方法であって、前記分散システムは、異なる複数のマシンを含み、前記カートリッジは前記分散システムにおいて実行されるコードのモジュールであり、
ある特定のマシン上で前記カートリッジを実行するステップと、
前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内のディスパッチャから前記カートリッジにリクエストを渡すステップとを含み、前記カートリッジ実行エンジンは、前記カートリッジの実行を制御し、前記リクエストはカートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され、
前記カートリッジに関連付けられる前記カートリッジ実行エンジンに返答を前記カートリッジから渡すステップとを含み、
前記リクエストは、ユニフォーム・リソース・ロケータ(URL)を含み、前記ディスパッチャは、URLをマッピングするメタデータを調べることにより、前記経路を選択し、
前記メタデータに基づいて、前記URLにマッピングされることを判断して、マッピングされている対象を識別するデータを前記ディスパッチャが知るステップと、
前記カートリッジは、前記分散システムにおけるカートリッジであり、前記カートリッジは、前記カートリッジインターフェイスを介してリクエストを受信し、
前記カートリッジ実行エンジンおよび前記カートリッジ並びに前記ディスパッチャは、前記複数のマシンのいずれかの上で実行している、方法。

(相違点1)
前記一致点における「異なる複数のマシン」が、本願請求項10記載の発明では第1のマシンと第2のマシンであるのに対し、引用発明では「複数ノード」ではあるが、「第1のノードと第2のノード」ではない点。

(相違点2)
本願請求項10記載の発明では、カートリッジに渡されるリクエストが複数であるのに対し、引用発明ではカスタムカートリッジに渡される要求が複数であるか否かは不明である点。

(相違点3)
前記一致点における「カートリッジインターフェイス」が、本願請求項10記載の発明では「標準カートリッジインターフェイス」であるのに対し、引用発明のWRB APIは「標準」的なAPIであるか否かは不明である点。

(相違点4)
前記一致点において前記カートリッジから前記カートリッジ実行エンジンに渡されている返答が、本願請求項10記載の発明では前記カートリッジ実行エンジンを介して前記分散システムの前記ディスパッチャに渡されているのに対し、引用発明では、カスタムカートリッジからWRB Execution Engine(WRBX)に渡された処理結果は、前記WRB Dispatcherに渡されているか否かは不明である点。

(相違点5)
本願請求項10記載の発明では、「メタデータ」はURLをカートリッジにマッピングするためのものであり、ディスパッチャがメタデータを調べる仮想パスマネージャにURLを送信し、仮想パスマネージャがメタデータに基づいてカートリッジがURLにマッピングされることを判断して、カートリッジを識別するデータをディスパッチャに送信することによりディスパッチャに応答するのに対し、引用発明では、仮想ディレクトリはURLを相当するWRB Execution(WRBX)と対応付けるためのものであり、WRB DispatcherがURLを仮想ディレクトリと比べることで、仮想ディレクトリに基づいて、前記相当するWRB Execution(WRBX)が前記URLに対応付けられることを判断して、前記相当するWRB Execution(WRBX)を識別するデータを知る点。

(相違点6)
本願請求項10記載の発明ではカートリッジが複数存在するのに対し、引用発明ではカスタムカートリッジが複数存在するか否かは不明である点。

(相違点7)
本願請求項10記載の発明では、前記カートリッジ実行エンジンおよび前記カートリッジは前記第1のマシン上で実行しており、前記ディスパッチャは前記第2のマシン上で実行しているのに対し、引用発明では、前記WRB Execution Engine(WRBX)および前記カスタムカートリッジ並びに前記WRB Dispatcherの三者は、前記複数のノードのうちのいずれかの上で実行しているものの、それら三者のうち、どれとどれが同じノードで実行されていて、どれとどれが異なるノードで実行されているのかは不明である点。

(相違点8)
本願請求項10記載の発明では、各ステップが1つ以上のコンピュータプロセッサで実行されるのに対し、引用発明では各ステップが1つ以上のコンピュータプロセッサで実行されるか否かが不明である点。

次に、上記相違点の各々について検討する。

まず、上記相違点1及び7について検討する。
引用発明は、「前記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)とを同じノードで実行させることは、当業者が容易に想到し得た事項に過ぎない。
したがって、上記相違点1及び7は、格別のものではない。

次に、上記相違点2について検討する。
要求を受け取って処理を行うものに対して複数の要求を渡すことは、周知技術であり、引用発明のカスタムカートリッジに渡す要求を複数とすることは、当業者が容易に想到し得た事項に過ぎない。
したがって、上記相違点2は、格別のものではない。

次に、上記相違点3について検討する。
APIを標準化することは周知技術であるから、引用発明のWRB APIを標準化されたAPIとすることは、当業者が容易に想到し得た事項に過ぎない。
したがって、上記相違点3は、格別のものではない。

次に、上記相違点4について検討する。
第1のプログラムからの処理要求を、第2のプログラムが中継して第3のプログラムに渡す場合に、第3の処理プログラムの処理結果を第2のプログラムが中継して第1のプログラムに返すことは周知技術であり、第1のプログラムが処理結果を利用するためには当然採用すべき構成に過ぎず、引用発明ではWRB Execution Engine(WRBX)を介してWRB Dispatcherからカスタムカートリッジに要求を渡しており、また、前記カスタムカートリッジから処理結果をWRB Execution Engine(WRBX)に渡しているから、その処理結果を更にWRB Execution Engine(WRBX)からWRB Dispatcherへ渡すことは、当業者が容易に想到し得た事項に過ぎない。
したがって、上記相違点4は格別のものではない。

次に、上記相違点5について検討する。
引用発明では、WRB Execution Engine(WRBX)はカスタムカートリッジと対をなしているから、引用発明において仮想ディレクトリに基づいて、URLに対応付けられた相当するWRB Execution(WRBX)を識別するデータを知ることは、間接的に、該WRB Execution(WRBX)と対をなすカスタムカートリッジを識別するデータを知ることに他ならない。
第1のデータと第2のデータが対応するという対応関係と、第2のデータが第3のデータと対応するという対応関係が判明している場合に、それら2つの対応関係に基づいて第1のデータが第3のデータに対応するという対応関係を間接的に得る代わりに、第1のデータが第3のデータに対応するという対応関係を直接的に表現するデータを設けるようにすることは周知技術であるから、引用発明の仮想ディレクトリにおいて、URLに対応付けてWRB Execution(WRBX)を識別するデータを格納する代わりに、該WRB Execution(WRBX)と対をなすカスタムカートリッジを識別するデータをURLに対応付けて格納するようにすることは、当業者が容易に想到し得た事項に過ぎない。
また、一般に、第1のプログラムが第1の情報に基づいて第2の情報を調べて第3の情報を知る手法として、第1のプログラムが第2のプログラムに第1の情報を送り、第2のプログラムが受け取った第1の情報に基づいて第2の情報を調べて第3の情報を得て、得られた第3の情報を第2のプログラムが第1のプログラムに送り返す手法(例えば、ディレクトリサーバや、検索エンジンなど)は周知技術であり、この周知技術に基づいて、引用発明においてWRB DispatcherがURLを仮想ディレクトリと比べる代わりに、WRB DispatcherがURLを別のプログラムへ送り、前記別のプログラムが受け取ったURLに基づいて仮想ディレクトリを調べてURLに対応付けられているデータを得て、得られたデータを前記別のプログラムがWRB Dispatcherへ送り返す構成とすることは、当業者が容易に想到し得た事項に過ぎない。そして、前記別のプログラムをどのような名前で呼ぶかは当業者が必要に応じて適宜決定すればよい事項に過ぎず、引用発明の「仮想ディレクトリ」が、実際にはURLに含まれる仮想的なパスを管理するためのものであることは、後述の【補足説明】に記載するように引用文献2の記載から明らかであるから、そのような仮想的なパスを管理するための引用発明の仮想ディレクトリを調べる前記「別のプログラム」の名称を「仮想パスマネージャ」とすることも、当業者が容易に想到し得た事項に過ぎない。

【補足説明】
引用発明の「仮想ディレクトリ」とは、引用文献1の「Oracle WebServer 2.0」という製品を説明する記事の中に登場する用語であるが、同じ「Oracle WebServer 2.0」という製品を説明する記事が掲載されている引用文献2の第201頁には、「仮想ディレクトリ名で処理を呼ぶ」という題名がついた節(その一部を、(2-1)及び(2-2)として後で挙げる。)が存在し、引用文献2の「仮想ディレクトリ」と引用発明(引用文献1)の「仮想ディレクトリ」は同じものを指すと解される。
引用文献2には、
(2-1)「仮想ディレクトリ名で処理を呼ぶ
OWSは、WWWブラウザから送られてきたURLの中のディレクトリ・パス名を見て、OWS上のファイルを送るのか、サーバー側プログラムを起動するのかを判断する。この「バーチャル・ディレクトリ」と呼ぶ仕組みは(図2)、ユーザーに対してバックエンドの処理を隠す効果がある。DBサーバーを起動して結果を見ているのか、ファイルを開いているのかは、まったく判断できない。例えば、URLに「/books/owa/」というパス名が含まれていればWRB経由でカートリッジを起動し、動的に生成したHTMLファイルを返す、というように設定できる」(第201頁左コラムの下から8行目?同頁中央コラム第8行)

(2-2)「登録したPL/SQLプログラムをWWWブラウザ側から実行させるには、PL/SQLカートリッジの起動用のバーチャル・ディレクトリ名に、プロシージャ名を付けて送信すればよい。例えば、写真7に示すような検索の初期画面を生成するプロシージャ「main」を起動するには、URLを「http://www.server.co.jp/books/owa/main」としてリクエストする。」(第201頁右コラム第6?15行)

と記載され、引用文献2の第201頁の図2には「バーチャル・ディレクトリ設定」として「/books/owa/ → エージェントOWA」と図示されているように、「Oracle WebServer 2.0」における「仮想ディレクトリ」とは、URL内のパス名(例えば「/books/owa/」というパス名)と、起動すべきカートリッジとを対応付けるものであり、前記「/books/owa/」というパス名はファイルシステム内のファイルと対応付けられているのではなく、プログラムと対応付けられている点において、前記「/books/owa/」というパス名は仮想的なパス名であるということができ、仮想ディレクトリとは、そのような仮想的なパス名を管理するための情報である。
(以上、補足説明)

したがって、上記相違点5も格別のものではない。

次に、上記相違点6について検討する。
呼び出されて処理を行うプログラムを複数設けることは周知技術であるから、引用発明に存在するカスタムカートリッジを複数とすることは、当業者が容易に想到し得た事項に過ぎない。
したがって、上記相違点6は、格別のものではない。

次に、上記相違点8について検討する。
「ノード」が、1つ以上のコンピュータプロセッサを有する計算機で実現され、該1つ以上のコンピュータプロセッサによって処理ステップを実行することは周知技術であり、この周知技術を用いて引用発明のノードを1つ以上のコンピュータプロセッサを有する計算機で実現し、該1つ以上のコンピュータプロセッサによって引用発明の各ステップを実行するようにすることは、当業者が容易に想到し得た事項に過ぎない。
したがって、上記相違点8は、格別のものではない。

以上述べたように、相違点1乃至8はいずれも格別のものではなく、本願請求項10記載の発明は引用文献1記載の引用発明に上述の周知技術の各々を適用することによって、当業者が容易に想到し得たものである。
そして、当該構成の採用によって奏される作用効果も、当業者であれば当然に予測し得る程度のものであって、格別顕著なものではない。
よって、本願請求項10記載の発明は、引用文献1記載の引用発明に基づいて当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により、特許を受けることができない。
…(中略)…
(以上、理由E) 」

第5.平成22年3月4日付け最後の拒絶理由通知のうち、【理由A】?【理由D】(2)の検討
「第4.平成22年3月4日付け最後の拒絶理由通知で通知した拒絶理由」にて示した拒絶理由のうち、【理由A】の(1)?(6)、【理由B】の(1)?(3)、【理由C】の(1)?(3)、【理由D】の(1)?(2)は、いずれも妥当である。そして、「第2.補正却下の決定」にて示したように、平成22年9月9日付け手続補正(本件補正)は却下された。そのため、拒絶理由は解消していない。

なお、同拒絶理由通知で通知した拒絶理由のうち、【理由A】の(1)?(6)、【理由B】の(1)?(3)、【理由C】の(1)?(3)、【理由D】の(1)?(2)に対応して、請求人は平成22年9月9日付けで手続補正(本件補正)を行い、請求項の記載のうち、拒絶理由として指摘された箇所を削除することまたは異なる記載に変更することを内容とした補正を行うことにより拒絶理由を解消することを意図している。その意図は同日付けで提出された意見書においても下記のとおり言明されている。

「第3 拒絶の理由A(特許法第36条第6項第2号)が解消していることについて
(3-1) 記(1)について
審判官殿は、請求項1に記載されている「第1のマシン」、「第2のマシン」と、請求項1に記載されている「1つ以上のコンピュータプロセッサ」の関係が不明であり、請求項1の記載は明確ではない旨の見解、および、同様の記載を有する請求項10,15の記載も明確でない旨の見解、これらの請求項を引用する他の請求項についても、同様の記載不備がある旨の見解を示されました。
これに対して出願人は、当該記載を、「複数のマシンのコンピュータプロセッサの一部」、「複数のマシンのうちの第1のマシン」、「前記複数のマシンのうちの第2のマシンのコンピュータプロセッサ」との記載に補正致しました。補正後の記載によれば、各マシンとコンピュータプロセッサとの関係が明確になりますので、ご指摘の不備は解消したものと思料致します。
(3-2) 記(2)について
審判官殿は、請求項10における「前記標準通信インターフェイス」との記載が不備である旨の見解を示されました。
これに対して出願人は、当該記載を、「前記標準カートリッジインターフェイス」との記載に補正致しました。補正後の当該記載は、請求項10において既に記載されているものでありますので、ご指摘の不備は解消したものと思料致します。
(3-3) 記(3)について
審判官殿は、請求項10における「標準通信インターフェイス」と、同請求項の「標準カートリッジインターフェイス」との関係が不明であり、請求項10の記載は明確ではない旨の見解を示されました。
これに対して出願人は、「標準通信インターフェイス」との記載を「標準カートリッジインターフェイス」との記載に補正致しましたので、ご指摘の不備は解消したものと思料致します。
(3-4) 記(4)について
審判官殿は、請求項10における「前記経路」との記載が不備である旨の見解を示されました。
これに対して出願人は、「前記」との記載を削除しましたので、ご指摘の不備は解消したものと思料致します。
(3-5) 記(5)について
審判官殿は、請求項10における「前記経路」との記載について、何の経路であるのか不明である旨の見解を示されました。
これに対して出願人は、当該記載を、「前記特定のリクエストに対応する処理を実行するカートリッジへの経路」との記載に補正致しましたので、ご指摘の不備は解消したものと思料致します。
(3-6) 記(6)について
審判官殿は、請求項8における「前記カートリッジの各々は標準カートリッジインターフェイスを介して呼出される「exec()」ルーチンを含み」、「前記複数のカートリッジ内の前記「exec()」ルーチン」、「特定のカートリッジ内のexec()ルーチン」との記載が明確でない旨の見解、および、同様の記載を有するその他の請求項についても、同様の見解を示されました。
これに対して出願人は、当該記載を削除しましたので、ご指摘の不備は解消したものと思料致します。

第4 拒絶の理由B(特許法第17条の2第3項)が解消していることについて
(4-1) 記(1)について
審判官殿は、請求項10、15の「標準通信インターフェイス」との記載が、当初翻訳文にも当初翻訳図面にも記載されておらず、当初翻訳文又は当初翻訳図面の記載から自明でもない旨の見解、請求項10、15を引用して記載されているその他の請求項についても同様の見解を示されました。
これに対して出願人は、当該記載を「標準カートリッジインターフェイス」との記載に補正致しました。補正後の記載は、当初翻訳文に記載されておりますので(段落0093ご参照)、ご指摘の不備は解消したものと思料致します。
(4-2) 記(2)について
審判官殿は、請求項10、15について、「標準カートリッジインターフェイス」とは別に「標準通信インターフェイス」が存在し、該「標準通信インターフェイス」を用いて「カートリッジ」が「リクエスト」を「受信」する旨の記載が存在するが、そのようなことは当初翻訳文にも当初翻訳図面にも記載されておらず、当初翻訳文又は当初翻訳図面の記載から自明でもない旨の見解を示されました。
これに対して出願人は、当該「標準通信インターフェイス」との記載を、「標準カートリッジインターフェイス」との記載に補正致しましたので、ご指摘の不備は解消したものと思料致します。
(4-3) 記(3)について
審判官殿は、請求項10における「前記複数のリクエストの各リクエストは、ユニフォーム・リソース・ロケータ(URL)を含み」という記載、および、「前記カートリッジに関連付けられるカートリッジ実行エンジンを介して、前記分散システム内のディスパッチャから前記カートリッジに複数のリクエストを渡すステップとを含み、前記カートリッジ実行エンジンは前記カートリッジの実行を制御し、前記リクエストは標準カートリッジインターフェイスを介して前記カートリッジ実行エンジンから前記カートリッジに渡され」という記載について、「ユニフォーム・リソース・ロケータ(URL)」そのものが「ディスパッチャ」から「カートリッジ実行エンジン」を介して「カートリッジ」に渡されるという趣旨と、「ユニフォーム・リソース・ロケータ(URL)」そのものが「標準カートリッジインターフェイス」を介して「カートリッジ実行エンジン」から「カートリッジ」に渡されるという趣旨とは、当初翻訳文にも当初翻訳図面にも記載されておらず、当初翻訳文及び当初翻訳図面の記載から自明でもないため、請求項10についてした補正、および、同様の記載を有する請求項1?9,11?17の補正が、当初翻訳文又は当初翻訳図面に記載した事項の範囲内で行われていない旨の見解を示されました。
これに対して出願人は、当該記載を削除しましたので、ご指摘の不備は解消したものと思料致します。

第5 拒絶の理由C(特許法第36条第6項第1号)が解消していることについて
(5-1) 記(1)について
審判官殿は、請求項10、15の「標準通信インターフェイス」に対応する記載が発明の詳細な説明に記載されていない旨の見解を示されました。
これに対して出願人は、当該記載を「標準カートリッジインターフェイス」との記載に補正致しました。補正後の記載は、発明の詳細な説明に記載されていますので、ご指摘の不備は解消したものと思料致します。
(5-2) 記(2)について
審判官殿は、請求項10、15における、「標準カートリッジインターフェイス」とは別に「標準通信インターフェイス」が存在し、該「標準通信インターフェイス」を用いて「カートリッジ」が「リクエスト」を「受信」する旨の記載について、これに対応する記載が発明の詳細な説明に記載されていない旨の見解を示されました。
これに対して出願人は、「標準通信インターフェイス」との記載を「標準カートリッジインターフェイス」との記載に補正致しました。補正後の記載内容に対応する記載は、発明の詳細な説明に記載されておりますので、ご指摘の不備は解消したものと思料致します。
(5-3) 記(3)について
審判官殿は、請求項1?17について、[理由B]の(3)で指摘された趣旨の記載が発明の詳細な説明には記載されていない旨の見解を示されました。
これに対して出願人は、「前記複数のリクエストの各リクエストは、ユニフォーム・リソース・ロケータ(URL)を含み」に係る記載を削除しましたので、各請求項は、ご指摘の趣旨を含まなくなります。これにより、ご指摘の不備は解消したものと思料致します。

第6 拒絶の理由D(特許法第36条第4項)が解消していることについて
(6-1) 記(1)について
審判官殿は、請求項10等における「標準通信インターフェイス」との記載について、「標準通信インターフェイス」の具体的な実現手法が、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない旨の見解を示されました。
これに対して出願人は、当該記載を削除しましたので、ご指摘の不備は解消したものと思料致します。
(6-2) 記(2)について
審判官殿は、請求項10等について、「標準カートリッジインターフェイス」とは別に「標準通信インターフェイス」が存在し、該「標準通信インターフェイス」を用いて「カートリッジ」が「リクエスト」を「受信」する旨の記載が存在するが、この記載の具体的な実現手法が、当業者が実施できる程度に明確かつ十分に発明の詳細な説明に記載されていない旨の見解を示されました。
これに対して出願人は、当該記載を削除しましたので、ご指摘の不備は解消したものと思料致します。」

つまり、平成22年3月4日付け最後の拒絶理由通知で通知した拒絶理由のうち、【理由A】の(1)?(6)、【理由B】の(1)?(3)、【理由C】の(1)?(3)、【理由D】の(1)?(2)については、請求人は同意見書において、平成22年9月9日付け手続補正(本件補正)を前提とした主張をするのにとどまるものであり、拒絶理由の妥当性については反論していない。そして、平成22年9月9日付け手続補正(本件補正)は却下されたのであるから、請求人の同意見書による上記主張は採用することができない。

よって、【理由A】の(1)?(6)で示されるように、本願は、平成14年法律第24号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第36条第6項第2号の規定を満たさない。また、【理由B】の(1)?(3)で示されるように、平成22年2月1日付け手続補正は、平成14年法律第24号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第184条の12第2項で読み替える同法第17条の2第3項の規定に違反する。さらに、【理由C】の(1)?(3)で示されるように、本願は、平成14年法律第24号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第36条第6項第1号の規定を満たさない。加えて、【理由D】の(1)?(2)で示されるように、本願は平成14年法律第24号改正附則第2条第1項によりなお従前の例によるとされる同法による改正前の特許法第36条第4項の規定を満たさない。

第6.平成22年3月4日付け最後の拒絶理由通知のうち、【理由D】(3)の検討
「第2.補正却下の決定」の「2の3の1.特許法第36条第4項の規定を満たすか否かの検討」の項目にて検討したことと、「第4.平成22年3月4日付け最後の拒絶理由通知で通知した拒絶理由」にて示した拒絶理由のうち、【理由D】の(3)は同様のものである。また、この拒絶理由に対して、請求人は平成22年9月9日付け意見書において主張しているが、当該主張は採用できないことも「第2.補正却下の決定」の「2の3の1.特許法第36条第4項の規定を満たすか否かの検討」の項目にて示したとおりである。そのため、【理由D】の(3)の拒絶理由は妥当である。
よって、【理由D】の(3)で示されるように、本願は平成14年法律第24号改正附則第2条第1項によりなお従前の例によるとされる同法による改正前の特許法第36条第4項の規定を満たさない。

第7.平成22年3月4日付け最後の拒絶理由通知のうち、【理由E】の検討
平成22年3月4日付け最後の拒絶理由通知のうち、【理由E】にて、斎藤圭,”Oracle WebServer 2.0”,Oracle LIFE,株式会社ビー・エヌ・エヌ,1996年12月13日,第1巻,第7号,Pages:40-43(以下、「引用文献1」という。)と、斎藤淳,外1名,”OPOアプリケーションがブラウザ上で快適に動作 Oracle Web Server2.0とPower Objects2.0”,日経オープンシステム,日経BP社,1996年12月15日,第45号,Pages:197-206(以下、「引用文献2」という。)を引用文献として取り上げている。
引用文献1には、同拒絶理由通知の【理由E】の「(1)請求項10について」における(1-1)乃至(1-7)のとおりの記載があり、引用文献1には、同【理由E】の「(1)請求項10について」において引用発明として認定されたとおりの発明が記載されていると認められる。本願発明と引用発明とを対比すると、同【理由E】の「(1)請求項10について」において(一致点)として記載されたとおりの点で両者は一致し、同【理由E】の「(1)請求項10について」において(相違点1)乃至(相違点8)と記載されたとおりの点で両者は相違する。そして、本願発明と引用発明の相違点について検討すると、同【理由E】の「(1)請求項10について」において相違点1乃至相違点8について検討したとおり、いずれの相違点も格別のものではない。
したがって、本願発明は、引用文献1記載の引用発明と周知技術に基いて当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により、特許を受けることができない。

なお、本願発明は、平成22年3月4日付け最後の拒絶理由通知における「本願請求項10記載の発明」に相当するものであるところ、同拒絶理由通知に応答する平成22年9月9日付け意見書において、「本願請求項10記載の発明」に対する同拒絶理由通知の【理由E】に対する意見として、請求人は下記のように主張している。

「第7 拒絶の理由E(特許法第29条第2項)が解消していることについて
(7-1) オラクル・ウェブサーバ(Oracle WebServer)2.0のディスパッチャ
引用文献1は、ウェブサーバを開示しており、そこには、一つのWRBディスパッチャがあります。このWRBディスパッチャは、入来する各リクエストのタイプを判断して、対応するWRBExecution(WRBX)に対してIPCメカニズムを介して当該リクエストを送信します(引用文献1の第42ページ左欄「Web Request Broker」?右第4行目)。加えて、WRBディスパッチャは、WRBサービスインスタンスの数を制御し維持します(第42ページ中欄第8?21行)。
しかしながら、Oracle WebServer 2.0で記述されるシステムは、複数のディスパッチャを取り入れるように構成を変更することができません。引用文献1に開示された各ディスパッチャは、カートリッジインスタンスの数を個別に管理しますので、あるカートリッジが、他のディスパッチャによって現在用いられているカートリッジを削除したり、二つのカートリッジが同時に同じカートリッジを用いようとするような問題が生じます。それゆえに、単一のディスパッチャを用いるOracle WebServer 2.0で記述されたシステムによって必要とされず、また予期すらされない複数のディスパッチャを用いるときに、中央制御のためのマネージャが必要となります。
(7-2) 本願発明と引用文献との対比
…(中略)…
(7-2-3) 請求項10
(a) 補正後の独立の請求項10に係る発明は、「前記複数のディスパッチャは、リソースマネージャにリクエストを送信し、前記リソースマネージャは、一つの特定のディスパッチャからの特定のリクエストに応じて、前記特定のリクエストに対応する処理を実行する、前記複数のディスパッチャによって使用されていないカートリッジへの経路を選択し、前記カートリッジが見つかった場合に、前記特定のディスパッチャのための当該カートリッジを予約」するという構成を備えます。
(b) これに対して、引用文献1,2のいずれも、当該構成に相当する技術的特徴を開示も示唆もしておりません。当該示唆がないことは、たとえば、引用文献1の上記開示内容からも明らかです。また、当該技術的特徴は、周知慣用技術でもありません。そのため、当業者といえども、引用文献1,2に基づいて、個別的にも又は組み合わせによっても、さらには周知慣用技術を付加しても、当該構成を導くことはできません。したがいまして、補正後の請求項10に係る発明は、当業者が引用文献1,2に基づいて容易に想到し得ない発明であると思料致します。」

しかしながら、請求人の同意見書における上記主張は、平成22年9月9日付け手続補正(本件補正)による補正後の請求項10の記載を根拠としたものである。「第2.補正却下の決定」にて平成22年9月9日付け手続補正(本件補正)は却下されたのであるから、上記主張には請求項10の記載における根拠がない。特に、上記主張にあるような、ディスパッチャを複数備えること、及び、リソースマネージャを備えることは、本願発明における発明特定事項には含まれない。よって、上記主張を採用することはできない。

第8.むすび
「第5.平成22年3月4日付け最後の拒絶理由通知のうち、【理由A】?【理由D】(2)の検討」の項目で示したように、本願は、平成14年法律第24号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第36条第6項第2号の規定を満たさないから、本願は特許を受けることができない。
同様に、平成22年2月1日付け手続補正は、平成14年法律第24号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第184条の12第2項で読み替える同法第17条の2第3項の規定に違反するから、本願は特許を受けることができない。
同様に、本願は、平成14年法律第24号改正附則第3条第1項によりなお従前の例によるとされる同法による改正前の特許法第36条第6項第1号の規定を満たさないから、本願は特許を受けることができない。
同様に、本願は平成14年法律第24号改正附則第2条第1項によりなお従前の例によるとされる同法による改正前の特許法第36条第4項の規定を満たさないから、本願は特許を受けることができない。
また、「第6.平成22年3月4日付け最後の拒絶理由通知のうち、【理由D】(3)の検討」の項目で示したように、本願は平成14年法律第24号改正附則第2条第1項によりなお従前の例によるとされる同法による改正前の特許法第36条第4項の規定を満たさないから、本願は特許を受けることができない。
さらに、「第7.平成22年3月4日付け最後の拒絶理由通知のうち、【理由E】の検討」の項目で示したように、本願の請求項10に係る発明は、その優先日前に日本国内又は外国において頒布された刊行物に記載された発明に基いて、当業者が容易に発明をすることができたものであるから、他の請求項について検討をするまでもなく、本願は特許法第29条第2項の規定により特許を受けることができない。

よって、結論のとおり審決する。
 
審理終結日 2011-03-07 
結審通知日 2011-03-08 
審決日 2011-03-22 
出願番号 特願2000-519524(P2000-519524)
審決分類 P 1 8・ 574- WZ (G06F)
P 1 8・ 572- WZ (G06F)
P 1 8・ 536- WZ (G06F)
P 1 8・ 55- WZ (G06F)
P 1 8・ 537- WZ (G06F)
P 1 8・ 121- WZ (G06F)
最終処分 不成立  
前審関与審査官 殿川 雅也  
特許庁審判長 山崎 達也
特許庁審判官 石井 茂和
清木 泰
発明の名称 分散を意識させない態様で分散ソフトウェア開発を容易にするための方法およびシステム  
代理人 深見 久郎  
代理人 仲村 義平  
代理人 堀井 豊  
代理人 森田 俊雄  
代理人 野田 久登  
代理人 酒井 將行  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ