【事件の表示】
　平成　２年特許願第２９５１３９号「共通ルーチンを用いた移植性の資源共用ファイルサーバ」拒絶査定に対する審判事件〔平成　３年　６月２４日出願公開、特開平　３−１４７１５１、請求項の数（１０）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
１．手続きの経緯および本件発明
　
　本件審判請求に係る特許出願は、平成２年１０月３１日（パリ条約による優先権主張１９８９年１０月３１日、米国）に出願されたものであって、平成１５年２月４日付で拒絶査定の謄本が送達され、これに対して同年５月６日に拒絶査定に対する審判請求がなされ、平成１５年７月１８日付拒絶理由通知に対して平成１５年７月２９日付で手続補正がなされたものであり、
　本件審判請求に係る請求項１の発明（以下、本件発明１という）は、平成９年１０月２９日付手続補正、平成１２年１０月５日付手続補正、平成１５年７月２９日付手続補正により補正された本件明細書の特許請求の範囲の請求項１に記載された次のとおりのものである。
　「ネットワーク上の資源を共有するための資源サーバシステムにおいて、
　共用すべき前記資源を含み、前記ネットワークに接続されるホスト処理手段と、
　各々が前記ネットワークに接続される複数のクライアントコンピュータと、
　前記処理手段により前記資源にアクセスするために、各々が前記ホスト処理手段内に配置される複数のセッションワーカ手段であって、各セッションワーカ手段の実行が、他の全てのセッションワーカタスクと同時に実行するために、前記ホスト処理手段内のオペレーティングシステムによりスケジューリングされる、複数のセッションワーカ手段と、
　前記ネットワークを介して複数の呼び出しを受け取るために、前記ホスト処理手段内に配置される監視手段であって、前記複数のクライアントコンピュータの各々に関する第１の呼び出しの受信に基づき、前記複数のセッションワーカ手段のうちの一つを開始し、また、後続する全ての呼び出しを、１つのクライアントコンピュータから、開始された前記複数のセッションワーカ手段のうちの前記一つへと向け、前記クライアントコンピュータからの呼び出しを処理する監視手段と、
　１つのクライアントコンピュータから受信した呼び出しを同時処理するために、前記複数のセッションワーカ手段の各々内に配置される複数のコルーチン手段と、
　該コルーチン手段の同時実行をスケジューリングするための複数のスケジューリング手段であって、該スケジューリング手段のうちの一つは、前記セッションワーカ手段の各々内に配置される、複数のスケジューリング手段と、
からなる資源サーバシステム。」
　
また、請求項２から請求項６の発明は、平成９年１０月２９日付手続補正、平成１２年１０月５日付手続補正、平成１５年７月２９日付手続補正により補正された本件明細書の特許請求の範囲の請求項２から請求項６に記載された以下のとおりのものである。
　
「【請求項２】
　前記複数のスケジューリング手段の各々は更に、
　１つのコルーチンが、１つの事象が完了するのを待たねばならない場合に、該コルーチンを保留にするための手段と、
　前記事象が完了した場合に、前記コルーチンの保留を解除するための手段と、
　前記保留にするための手段が、第１のコルーチンにより動作される場合に、該第１のコルーチンを中断処理して、第２のコルーチンの処理を開始するための手段であって、それにより、前記第１のコルーチンの動作が延期されて、前記第２のコルーチンの動作が開始される手段と、
からなる、請求項１に記載の資源サーバシステム。
　【請求項３】
　前記セッションワーカ手段に含まれるスタックを、複数のスタック空間に分割するための手段であって、前記複数のコルーチンの各々に対して１つのスタック空間が割り当てられるようにする手段をさらに含む、請求項１に記載の資源サーバシステム。
　【請求項４】
　前記複数のスタック空間を超えた場合を判断するための手段から更になる、請求項３に記載の資源サーバシステム。
　【請求項５】
　前記判断するための手段は、
　１つのスタック空間内に１つのタツーを配置するための手段と、
　前記スタック空間を用いる前記コルーチンが、実行に際しスケジューリングされる度に
、前記タツーをチェックするための手段と、
　前記タツーが変更される場合はいつも前記セッションワーカを取り消すための手段と、
からなる、請求項４に記載の資源サーバシステム。
　【請求項６】
　前記セッションワーカ手段は更に、
　前記セッションワーカが開始される場合に、前記複数のコルーチンを生成するための手段と、
　前記セッションワーカが開始される場合に、前記複数のスタック空間を生成するための手段と、
　前記クライアントコンピュータからの資源アクセス要求の受信に基づき、前記複数のコルーチンのうちの一つを開始するための手段と、
からなる、請求項３に記載の資源サーバシステム。」
　
さらに、請求項７の発明（以下、本件発明２という）は、平成９年１０月２９日付手続補正、平成１２年１０月５日付け手続補正、平成１５年７月２９日付手続補正により補正された本件明細書の特許請求の範囲の請求項７に記載された以下のとおりのものである。
　
「ローカルエリアネットワーク内の複数のクライアントコンピュータの各々からの複数の同時資源アクセス要求を、ホストコンピュータにより処理する方法において、
　(a) 前記複数のクライアントコンピュータの各々と前記ホストコンピュータの間で接続を確立し、該接続の各々は、前記ホストコンピュータ内の監視ソフトウェアにより確立される、ステップ(a) であって、
　　(a1)前記ホストコンピュータ内で複数の別個のセッションワーカタスクを生成し、前記複数の別個のセッションワーカタスクの一つは、前記複数のクライアントコンピュータの各々からの前記同時資源アクセス要求を処理して、１つのスタックを前記複数の別個のセッションワーカタスクの各々に割り当てるために確立され、前記複数のセッションワーカタスクの各々は、前記ホストコンピュータ内のオペレーティングシステムによりスケジューリングされて、前記複数のセッションワーカタスクのうちの他の全てと同時に動作する、ステップと、
　　(a2)前記複数の別個のセッションワーカタスクの各々内で、複数のコルーチンタスクを生成するステップと、
　　(a3) １つのセッションワーカタスクが、対応する１つのクライアントコンピュータからの資源アクセス要求を処理するように、前記複数の別個のセッションワーカタスクの各々を、前記複数のクライアントコンピュータのうちの対応する各クライアントコンピュータに接続するステップと、
を含む接続を確立するステップ(a) と、
　(b) 複数のコルーチンが内部で生成される１つのセッションワーカタスク内で、前記複数の同時資源アクセス要求を同時に処理するステップ(b) であって、
　　(b1)前記セッションワーカに割り当てられた前記スタックを、複数のスタック領域のパーティションに分割するステップと、
　　(b2)前記セッションワーカタスク内で生成された前記複数のコルーチンの各々に、前記複数のスタック領域の１つを割り当て、前記複数のコルーチンの各々に対してスタック空間を設け、資源アクセス要求を処理する際に用いるための１つの記憶領域を設けるステップと、
　　(b3)要求が有効である場合、
　　　　(b3a) 前記ローカルエリアネットワークから前記要求を検索するステップと、
　　　　(b3b) 前記検索された要求を処理するために、前記セッションワーカ内で、前記複数のコルーチンのうちの１つの自由なコルーチンを準備して、該自由なコルーチンに前記要求を供給するステップと、
を含む前記要求を受信するステップと、
　　(b4)前記複数のコルーチンのうちのいずれかの準備が整い、且ついずれも保留状態にない場合、１つの実行コルーチンとなる前記１つのコルーチンを実行するステップと、
　　(b5)前記実行コルーチンが、１つの事象が完了するのを待たねばならないと判断した場合、前記実行コルーチンを保留するステップと、
　　(b6)１つの事象が完了した場合、該事象に関して保留状態にある前記複数のコルーチンのいずれかの保留を解除するステップと、
　　(b7)１つの要求の処理を完了した前記複数のコルーチンのいずれかを自由にするステップと、
　　(b8)ステップ(b3)を継続するステップと、
を含む、同時資源アクセス要求を同時に処理するステップ(b) と、
からなる方法。」
　
加えて、請求項８から請求項１０の発明は、平成９年１０月２９日付手続補正、平成１２年１０月５日付手続補正、平成１５年７月２９日付手続補正により補正された本件明細書の特許請求の範囲の請求項８から請求項１０に記載された以下のとおりのものである。
　
「【請求項８】
　前記ステップ(b4)の前記コルーチンを実行するステップは、
　任意の以前の実行コルーチンのコンテキストを格納するステップと、
　前記準備が整い且つ保留状態にないコルーチンのコンテキストをロードするステップと、
　前記準備が整い且つ保留状態にないコルーチンに、プロセッサの制御を移すステップと、
を含む、請求項７に記載の方法。
　【請求項９】
　前記ステップ(b2)は更に、前記コルーチンの各々に割り当てられた各スタック領域内に、１つのスタックタツーをインストールするステップを含む、請求項７に記載の方法。
　【請求項10】　
　前記ステップ(b5)は更に、前記タツーを調べて、前記タツーが変更されている場合、前記セッションワーカを取り消すステップを含む、請求項９に記載の方法。」
　
２．引用文献記載の発明
　
　一方、原査定の拒絶の理由に引用された、Howard,J.H.,ほか，Scale and Performance in a Distributed File System，ACM Transactions on Computer Systems，Vol.６，No.1，１９８８年２月発行，P.51-P.81（以下、引用文献１という）には、位置透過(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.」
（第６０頁左欄第６行から第５頁右欄第４２行）
（訳：３．３　通信とサーバプロセスの構造
我々のプロトタイプにおいて示されたコンテクスト切換とぺージングのオーバーヘッドのため、クライアント１つに対してサーバプロセス１つを用いることはうまくスケールしない。（中略）複数スレッド制御は便利なプログラミング抽象をもたらすので、我々は複数の横取り可能な軽量プロセス（ＬＷＰｓ）を１つのプロセスにサポートするというユーザレベル機構を構築した。
ＬＷＰ間でのコンテクスト切換はプロシージャ呼出し数回分のオーダの時間しかかからない。ＬＷＰの数（典型的には５つ）はサーバが初期化され固定される時に決定される。１つのＬＷＰはある１つのサーバ操作の期間中は特定のクライアント１つに結びつけられる。）
　
そして、上記の記載から見て、引用文献１には、
ファイルサーバにおいて、クライアント１つに対してサーバプロセス１つを対応させるのではコンテクスト切換の負荷が大きいので、１つのサーバプロセス中に複数の軽量プロセスを備え、この軽量プロセスがある１つのサーバ操作期間中は特定のクライアント１つと対応させるようにすること、
が開示されているものと認める。
　
　また、原査定において示された、Spector,A.Z.他，広域ファイルシステムAndrew File System，ＵＮＩＸ　ＭＡＧＡＺＩＮＥ，株式会社アスキー，１９８９年８月１日, 第４巻, 第８号(通巻３４号), Ｐ．５４−６５（以下、引用文献２という）には、広域ファイルシステムAndrew File Systemに関して以下のことが記載されている。
　
「各ワークステーションにつき１つのＵＮＩＸプロセスを使うのではなく、ligth-weight threadsを使うようにファイルサーバを書き直した。」
（第５８頁囲み記事「ＡＦＳプロジェクトの歴史」の右段第１１行から第１４行）
　
そして、上記の記載から見て、引用文献２には、
　
引用文献１に記載されるファイルシステムAndrew File Systemに関して、以前はファイルサーバが１つのワークステーションに対して１つのＵＮＩＸプロセスを使用していたが、これをスレッドを使うように書き直された、
　
ことが開示されているものと認められる。
　
３．本件発明と引用文献記載の発明との対比
　
　本件発明１または本件発明２と引用文献１または２記載の発明とを対比すると、両者は少なくとも以下の点で相違するものと認める。
　
　本件発明１においては、
　ネットワークを介して複数の呼び出しを受け取るために、前記ホスト処理手段内に配置される監視手段であって、前記複数のクライアントコンピュータの各々に関する第１の呼び出しの受信に基づき、前記複数のセッションワーカ手段のうちの一つを開始し、また、後続する全ての呼び出しを、１つのクライアントコンピュータから、開始された前記複数のセッションワーカ手段のうちの前記一つへと向け、前記クライアントコンピュータからの呼び出しを処理する監視手段と、
　１つのクライアントコンピュータから受信した呼び出しを同時処理するために、前記複数のセッションワーカ手段の各々内に配置される複数のコルーチン手段と、
を備え、
　
　本件発明２においては、
　１つのセッションワーカタスクが、対応する１つのクライアントコンピュータからの資源アクセス要求を処理するように、前記複数の別個のセッションワーカタスクの各々を、前記複数のクライアントコンピュータのうちの対応する各クライアントコンピュータに接続するステップを含む接続を確立するステップ(a)と、複数のコルーチンが内部で生成される１つのセッションワーカタスク内で、前記複数の同時資源アクセス要求を同時に処理するステップ、
を行うのに対して
　
　引用文献１または２記載の発明においては、
元々は１つのサーバプロセスが１つのクライアントからの要求を処理していたが、これを改良して１つのサーバプロセスに含まれる複数のスレッドのそれぞれが、あるクライアントからの要求を処理するように構成されているファイルサーバが開示されているにすぎない点。
　
そして、上記の相違点は、
本件発明１または２が、
サーバにおける１つのセッションワーカに対して１つのクライアントコンピュータが対応付けられ、該１つのクライアントコンピュータからの複数の要求は該セッションワーカ内の複数のコルーチンにおいて処理される、
のに対して、
引用文献１または２記載の発明においては、
サーバにおけるファイル要求を処理するプロセスはマルチスレッド化されているものの、該マルチスレッド化されたプロセスとクライアントコンピュータの対応付けについては示唆がなく、ただ以前マルチスレッド化されていなかったサーバプロセスは１つのクライアントからの要求を受け付けていた、
という点に帰するものである。
　
４．相違点の判断
　
　上記相違点について検討するに、
　
　引用文献１、２記載の発明からでは「サーバにおける１つのセッションワーカ内の複数のコルーチンによって、サーバに接続された複数のクライアントコンピュータからの複数の要求が処理される」ということが導き出せるにすぎず、
　
本件発明１、２に共通する「サーバにおける１つのセッションワーカに対して１つのクライアントコンピュータが対応付けられ、該１つのクライアントコンピュータからの複数の要求は該セッションワーカ内の複数のコルーチンにおいて処理される」という技術思想、およびこれを具現化した、
本件発明１の、
　
ネットワークを介して複数の呼び出しを受け取るために、前記ホスト処理手段内に配置される監視手段であって、前記複数のクライアントコンピュータの各々に関する第１の呼び出しの受信に基づき、前記複数のセッションワーカ手段のうちの一つを開始し、また、後続する全ての呼び出しを、１つのクライアントコンピュータから、開始された前記複数のセッションワーカ手段のうちの前記一つへと向け、前記クライアントコンピュータからの呼び出しを処理する監視手段と、
　１つのクライアントコンピュータから受信した呼び出しを同時処理するために、前記複数のセッションワーカ手段の各々内に配置される複数のコルーチン手段、
　
あるいは本件発明２の、
　
　１つのセッションワーカタスクが、対応する１つのクライアントコンピュータからの資源アクセス要求を処理するように、前記複数の別個のセッションワーカタスクの各々を、前記複数のクライアントコンピュータのうちの対応する各クライアントコンピュータに接続するステップを含む接続を確立するステップ(a)と、複数のコルーチンが内部で生成される１つのセッションワーカタスク内で、前記複数の同時資源アクセス要求を同時に処理するステップ、
　
を想到することは、当業者が容易になし得ることはできないものである。
　
そして、上記各事項により、本件発明１または本件発明２は、本件明細書の発明の【課題を解決するための手段】に記載された、
　
「各セッションワーカプロセスは、１つのクライアントのコンピュータ、及び１つだけのクライアントのコンピュータに専用である。したがって、セッションワーカプロセッサは、クライアントのコンピュータのファイル間にファイル保護を設ける必要はなく、こうしたファイル保護については基本的なオペレーティングシステムに頼ることができる」
　
という効果を奏するものである。
　
また、請求項２から請求項６の発明または請求項８から請求項１０の発明は、それぞれ本件発明１または本件発明２を引用するものであり、本件発明１または本件発明２の構成を備えるものであるが、本件発明１または本件発明２は当業者が容易になし得ることはできないものである以上、請求項２から請求項６の発明、請求項８から請求項１０の発明も当業者といえども容易になし得ることはできず、またこれらの事項を備えることにより本件発明１ないし２と同様の効果を奏するものである。
　
４．結び
　
　以上のとおり、本件発明は、引用文献１、２記載の発明に基づいて当業者が容易に発明をすることができたものということはできない。
　また、他に拒絶の理由を発見しない。
　
よって、結論のとおり審決する。