ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 取り消して特許、登録 G06F |
|---|---|
| 管理番号 | 1081072 |
| 審判番号 | 不服2003-7772 |
| 総通号数 | 45 |
| 発行国 | 日本国特許庁(JP) |
| 公報種別 | 特許審決公報 |
| 発行日 | 1991-06-24 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2003-05-06 |
| 確定日 | 2003-08-26 |
| 事件の表示 | 平成 2年特許願第295139号「共通ルーチンを用いた移植性の資源共用ファイルサーバ」拒絶査定に対する審判事件〔平成 3年 6月24日出願公開、特開平 3-147151、請求項の数(10)〕について、次のとおり審決する。 |
| 結論 | 原査定を取り消す。 本願の発明は、特許すべきものとする。 |
| 理由 |
1.手続きの経緯および本件発明 本件審判請求に係る特許出願は、平成2年10月31日(パリ条約による優先権主張1989年10月31日、米国)に出願されたものであって、平成15年2月4日付で拒絶査定の謄本が送達され、これに対して同年5月6日に拒絶査定に対する審判請求がなされ、平成15年7月18日付拒絶理由通知に対して平成15年7月29日付で手続補正がなされたものであり、 本件審判請求に係る請求項1の発明(以下、本件発明1という)は、平成9年10月29日付手続補正、平成12年10月5日付手続補正、平成15年7月29日付手続補正により補正された本件明細書の特許請求の範囲の請求項1に記載された次のとおりのものである。 「ネットワーク上の資源を共有するための資源サーバシステムにおいて、 共用すべき前記資源を含み、前記ネットワークに接続されるホスト処理手段と、 各々が前記ネットワークに接続される複数のクライアントコンピュータと、 前記処理手段により前記資源にアクセスするために、各々が前記ホスト処理手段内に配置される複数のセッションワーカ手段であって、各セッションワーカ手段の実行が、他の全てのセッションワーカタスクと同時に実行するために、前記ホスト処理手段内のオペレーティングシステムによりスケジューリングされる、複数のセッションワーカ手段と、 前記ネットワークを介して複数の呼び出しを受け取るために、前記ホスト処理手段内に配置される監視手段であって、前記複数のクライアントコンピュータの各々に関する第1の呼び出しの受信に基づき、前記複数のセッションワーカ手段のうちの一つを開始し、また、後続する全ての呼び出しを、1つのクライアントコンピュータから、開始された前記複数のセッションワーカ手段のうちの前記一つへと向け、前記クライアントコンピュータからの呼び出しを処理する監視手段と、 1つのクライアントコンピュータから受信した呼び出しを同時処理するために、前記複数のセッションワーカ手段の各々内に配置される複数のコルーチン手段と、 該コルーチン手段の同時実行をスケジューリングするための複数のスケジューリング手段であって、該スケジューリング手段のうちの一つは、前記セッションワーカ手段の各々内に配置される、複数のスケジューリング手段と、 からなる資源サーバシステム。」 また、請求項2から請求項6の発明は、平成9年10月29日付手続補正、平成12年10月5日付手続補正、平成15年7月29日付手続補正により補正された本件明細書の特許請求の範囲の請求項2から請求項6に記載された以下のとおりのものである。 「【請求項2】 前記複数のスケジューリング手段の各々は更に、 1つのコルーチンが、1つの事象が完了するのを待たねばならない場合に、該コルーチンを保留にするための手段と、 前記事象が完了した場合に、前記コルーチンの保留を解除するための手段と、 前記保留にするための手段が、第1のコルーチンにより動作される場合に、該第1のコルーチンを中断処理して、第2のコルーチンの処理を開始するための手段であって、それにより、前記第1のコルーチンの動作が延期されて、前記第2のコルーチンの動作が開始される手段と、 からなる、請求項1に記載の資源サーバシステム。 【請求項3】 前記セッションワーカ手段に含まれるスタックを、複数のスタック空間に分割するための手段であって、前記複数のコルーチンの各々に対して1つのスタック空間が割り当てられるようにする手段をさらに含む、請求項1に記載の資源サーバシステム。 【請求項4】 前記複数のスタック空間を超えた場合を判断するための手段から更になる、請求項3に記載の資源サーバシステム。 【請求項5】 前記判断するための手段は、 1つのスタック空間内に1つのタツーを配置するための手段と、 前記スタック空間を用いる前記コルーチンが、実行に際しスケジューリングされる度に 、前記タツーをチェックするための手段と、 前記タツーが変更される場合はいつも前記セッションワーカを取り消すための手段と、 からなる、請求項4に記載の資源サーバシステム。 【請求項6】 前記セッションワーカ手段は更に、 前記セッションワーカが開始される場合に、前記複数のコルーチンを生成するための手段と、 前記セッションワーカが開始される場合に、前記複数のスタック空間を生成するための手段と、 前記クライアントコンピュータからの資源アクセス要求の受信に基づき、前記複数のコルーチンのうちの一つを開始するための手段と、 からなる、請求項3に記載の資源サーバシステム。」 さらに、請求項7の発明(以下、本件発明2という)は、平成9年10月29日付手続補正、平成12年10月5日付け手続補正、平成15年7月29日付手続補正により補正された本件明細書の特許請求の範囲の請求項7に記載された以下のとおりのものである。 「ローカルエリアネットワーク内の複数のクライアントコンピュータの各々からの複数の同時資源アクセス要求を、ホストコンピュータにより処理する方法において、 (a) 前記複数のクライアントコンピュータの各々と前記ホストコンピュータの間で接続を確立し、該接続の各々は、前記ホストコンピュータ内の監視ソフトウェアにより確立される、ステップ(a) であって、 (a1)前記ホストコンピュータ内で複数の別個のセッションワーカタスクを生成し、前記複数の別個のセッションワーカタスクの一つは、前記複数のクライアントコンピュータの各々からの前記同時資源アクセス要求を処理して、1つのスタックを前記複数の別個のセッションワーカタスクの各々に割り当てるために確立され、前記複数のセッションワーカタスクの各々は、前記ホストコンピュータ内のオペレーティングシステムによりスケジューリングされて、前記複数のセッションワーカタスクのうちの他の全てと同時に動作する、ステップと、 (a2)前記複数の別個のセッションワーカタスクの各々内で、複数のコルーチンタスクを生成するステップと、 (a3) 1つのセッションワーカタスクが、対応する1つのクライアントコンピュータからの資源アクセス要求を処理するように、前記複数の別個のセッションワーカタスクの各々を、前記複数のクライアントコンピュータのうちの対応する各クライアントコンピュータに接続するステップと、 を含む接続を確立するステップ(a) と、 (b) 複数のコルーチンが内部で生成される1つのセッションワーカタスク内で、前記複数の同時資源アクセス要求を同時に処理するステップ(b) であって、 (b1)前記セッションワーカに割り当てられた前記スタックを、複数のスタック領域のパーティションに分割するステップと、 (b2)前記セッションワーカタスク内で生成された前記複数のコルーチンの各々に、前記複数のスタック領域の1つを割り当て、前記複数のコルーチンの各々に対してスタック空間を設け、資源アクセス要求を処理する際に用いるための1つの記憶領域を設けるステップと、 (b3)要求が有効である場合、 (b3a) 前記ローカルエリアネットワークから前記要求を検索するステップと、 (b3b) 前記検索された要求を処理するために、前記セッションワーカ内で、前記複数のコルーチンのうちの1つの自由なコルーチンを準備して、該自由なコルーチンに前記要求を供給するステップと、 を含む前記要求を受信するステップと、 (b4)前記複数のコルーチンのうちのいずれかの準備が整い、且ついずれも保留状態にない場合、1つの実行コルーチンとなる前記1つのコルーチンを実行するステップと、 (b5)前記実行コルーチンが、1つの事象が完了するのを待たねばならないと判断した場合、前記実行コルーチンを保留するステップと、 (b6)1つの事象が完了した場合、該事象に関して保留状態にある前記複数のコルーチンのいずれかの保留を解除するステップと、 (b7)1つの要求の処理を完了した前記複数のコルーチンのいずれかを自由にするステップと、 (b8)ステップ(b3)を継続するステップと、 を含む、同時資源アクセス要求を同時に処理するステップ(b) と、 からなる方法。」 加えて、請求項8から請求項10の発明は、平成9年10月29日付手続補正、平成12年10月5日付手続補正、平成15年7月29日付手続補正により補正された本件明細書の特許請求の範囲の請求項8から請求項10に記載された以下のとおりのものである。 「【請求項8】 前記ステップ(b4)の前記コルーチンを実行するステップは、 任意の以前の実行コルーチンのコンテキストを格納するステップと、 前記準備が整い且つ保留状態にないコルーチンのコンテキストをロードするステップと、 前記準備が整い且つ保留状態にないコルーチンに、プロセッサの制御を移すステップと、 を含む、請求項7に記載の方法。 【請求項9】 前記ステップ(b2)は更に、前記コルーチンの各々に割り当てられた各スタック領域内に、1つのスタックタツーをインストールするステップを含む、請求項7に記載の方法。 【請求項10】 前記ステップ(b5)は更に、前記タツーを調べて、前記タツーが変更されている場合、前記セッションワーカを取り消すステップを含む、請求項9に記載の方法。」 2.引用文献記載の発明 一方、原査定の拒絶の理由に引用された、Howard,J.H.,ほか,Scale and Performance in a Distributed File System,ACM Transactions on Computer Systems,Vol.6,No.1,1988年2月発行,P.51-P.81(以下、引用文献1という)には、位置透過(location transparent)な分散ファイルシステムAndrew File Systemに関して、以下のことが記載されている。 「3.3 Commnication and Server Process Structure As the context switching and paging overheads in our prototype indicated, the use of a server process per client did not scale well.(中略) Since multiple thread of control provide a convenient programming abstraction, we have built a user-level mechanism to support multiple nonpreemptive Lightweight Process(LWP) within on process.Context switching between LWPs is only on the order of a few procedure-call times. The number pf LWPs (typically five) is determined when a server is initialized and remains fixed thereafter. An LWP is bound to a particular client only for the duration of a single server operation.」 (第60頁左欄第6行から第5頁右欄第42行) (訳:3.3 通信とサーバプロセスの構造 我々のプロトタイプにおいて示されたコンテクスト切換とぺージングのオーバーヘッドのため、クライアント1つに対してサーバプロセス1つを用いることはうまくスケールしない。(中略)複数スレッド制御は便利なプログラミング抽象をもたらすので、我々は複数の横取り可能な軽量プロセス(LWPｓ)を1つのプロセスにサポートするというユーザレベル機構を構築した。 LWP間でのコンテクスト切換はプロシージャ呼出し数回分のオーダの時間しかかからない。LWPの数(典型的には5つ)はサーバが初期化され固定される時に決定される。1つのLWPはある1つのサーバ操作の期間中は特定のクライアント1つに結びつけられる。) そして、上記の記載から見て、引用文献1には、 ファイルサーバにおいて、クライアント1つに対してサーバプロセス1つを対応させるのではコンテクスト切換の負荷が大きいので、1つのサーバプロセス中に複数の軽量プロセスを備え、この軽量プロセスがある1つのサーバ操作期間中は特定のクライアント1つと対応させるようにすること、 が開示されているものと認める。 また、原査定において示された、Spector,A.Z.他,広域ファイルシステムAndrew File System,UNIX MAGAZINE,株式会社アスキー,1989年8月1日, 第4巻, 第8号(通巻34号), P.54-65(以下、引用文献2という)には、広域ファイルシステムAndrew File Systemに関して以下のことが記載されている。 「各ワークステーションにつき1つのUNIXプロセスを使うのではなく、ligth-weight threadsを使うようにファイルサーバを書き直した。」 (第58頁囲み記事「AFSプロジェクトの歴史」の右段第11行から第14行) そして、上記の記載から見て、引用文献2には、 引用文献1に記載されるファイルシステムAndrew File Systemに関して、以前はファイルサーバが1つのワークステーションに対して1つのUNIXプロセスを使用していたが、これをスレッドを使うように書き直された、 ことが開示されているものと認められる。 3.本件発明と引用文献記載の発明との対比 本件発明1または本件発明2と引用文献1または2記載の発明とを対比すると、両者は少なくとも以下の点で相違するものと認める。 本件発明1においては、 ネットワークを介して複数の呼び出しを受け取るために、前記ホスト処理手段内に配置される監視手段であって、前記複数のクライアントコンピュータの各々に関する第1の呼び出しの受信に基づき、前記複数のセッションワーカ手段のうちの一つを開始し、また、後続する全ての呼び出しを、1つのクライアントコンピュータから、開始された前記複数のセッションワーカ手段のうちの前記一つへと向け、前記クライアントコンピュータからの呼び出しを処理する監視手段と、 1つのクライアントコンピュータから受信した呼び出しを同時処理するために、前記複数のセッションワーカ手段の各々内に配置される複数のコルーチン手段と、 を備え、 本件発明2においては、 1つのセッションワーカタスクが、対応する1つのクライアントコンピュータからの資源アクセス要求を処理するように、前記複数の別個のセッションワーカタスクの各々を、前記複数のクライアントコンピュータのうちの対応する各クライアントコンピュータに接続するステップを含む接続を確立するステップ(a)と、複数のコルーチンが内部で生成される1つのセッションワーカタスク内で、前記複数の同時資源アクセス要求を同時に処理するステップ、 を行うのに対して 引用文献1または2記載の発明においては、 元々は1つのサーバプロセスが1つのクライアントからの要求を処理していたが、これを改良して1つのサーバプロセスに含まれる複数のスレッドのそれぞれが、あるクライアントからの要求を処理するように構成されているファイルサーバが開示されているにすぎない点。 そして、上記の相違点は、 本件発明1または2が、 サーバにおける1つのセッションワーカに対して1つのクライアントコンピュータが対応付けられ、該1つのクライアントコンピュータからの複数の要求は該セッションワーカ内の複数のコルーチンにおいて処理される、 のに対して、 引用文献1または2記載の発明においては、 サーバにおけるファイル要求を処理するプロセスはマルチスレッド化されているものの、該マルチスレッド化されたプロセスとクライアントコンピュータの対応付けについては示唆がなく、ただ以前マルチスレッド化されていなかったサーバプロセスは1つのクライアントからの要求を受け付けていた、 という点に帰するものである。 4.相違点の判断 上記相違点について検討するに、 引用文献1、2記載の発明からでは「サーバにおける1つのセッションワーカ内の複数のコルーチンによって、サーバに接続された複数のクライアントコンピュータからの複数の要求が処理される」ということが導き出せるにすぎず、 本件発明1、2に共通する「サーバにおける1つのセッションワーカに対して1つのクライアントコンピュータが対応付けられ、該1つのクライアントコンピュータからの複数の要求は該セッションワーカ内の複数のコルーチンにおいて処理される」という技術思想、およびこれを具現化した、 本件発明1の、 ネットワークを介して複数の呼び出しを受け取るために、前記ホスト処理手段内に配置される監視手段であって、前記複数のクライアントコンピュータの各々に関する第1の呼び出しの受信に基づき、前記複数のセッションワーカ手段のうちの一つを開始し、また、後続する全ての呼び出しを、1つのクライアントコンピュータから、開始された前記複数のセッションワーカ手段のうちの前記一つへと向け、前記クライアントコンピュータからの呼び出しを処理する監視手段と、 1つのクライアントコンピュータから受信した呼び出しを同時処理するために、前記複数のセッションワーカ手段の各々内に配置される複数のコルーチン手段、 あるいは本件発明2の、 1つのセッションワーカタスクが、対応する1つのクライアントコンピュータからの資源アクセス要求を処理するように、前記複数の別個のセッションワーカタスクの各々を、前記複数のクライアントコンピュータのうちの対応する各クライアントコンピュータに接続するステップを含む接続を確立するステップ(a)と、複数のコルーチンが内部で生成される1つのセッションワーカタスク内で、前記複数の同時資源アクセス要求を同時に処理するステップ、 を想到することは、当業者が容易になし得ることはできないものである。 そして、上記各事項により、本件発明1または本件発明2は、本件明細書の発明の【課題を解決するための手段】に記載された、 「各セッションワーカプロセスは、1つのクライアントのコンピュータ、及び1つだけのクライアントのコンピュータに専用である。したがって、セッションワーカプロセッサは、クライアントのコンピュータのファイル間にファイル保護を設ける必要はなく、こうしたファイル保護については基本的なオペレーティングシステムに頼ることができる」 という効果を奏するものである。 また、請求項2から請求項6の発明または請求項8から請求項10の発明は、それぞれ本件発明1または本件発明2を引用するものであり、本件発明1または本件発明2の構成を備えるものであるが、本件発明1または本件発明2は当業者が容易になし得ることはできないものである以上、請求項2から請求項6の発明、請求項8から請求項10の発明も当業者といえども容易になし得ることはできず、またこれらの事項を備えることにより本件発明1ないし2と同様の効果を奏するものである。 4.結び 以上のとおり、本件発明は、引用文献1、2記載の発明に基づいて当業者が容易に発明をすることができたものということはできない。 また、他に拒絶の理由を発見しない。 よって、結論のとおり審決する。 |
| 審決日 | 2003-08-11 |
| 出願番号 | 特願平2-295139 |
| 審決分類 |
P
1
8・
121-
WY
(G06F)
|
| 最終処分 | 成立 |
| 前審関与審査官 | 前田 仁、原 秀人 |
| 特許庁審判長 |
西川 正俊 |
| 特許庁審判官 |
新井 則和 川崎 優 |
| 発明の名称 | 共通ルーチンを用いた移植性の資源共用ファイルサーバ |
| 代理人 | 古谷 聡 |
| 代理人 | 溝部 孝彦 |