【事件の表示】
　平成１０年特許願第２４１５５９号「複数サーバ間送信数最適化システムおよびその方法」拒絶査定不服審判事件〔平成１２年　３月１４日出願公開、特開２０００−　７６３３２〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続きの経緯・本願発明
　本願は、平成１０年８月２７に出願されたものであって、平成１４年７月２日付けで拒絶査定がなされ、これに対し平成１４年１０月７日に拒絶査定に対する審判請求がなされると共に同日付けで手続補正がなされたものである。
　
２．平成１４年１０月７日付けの手続補正についての補正却下の決定
［補正却下の決定の結論］
　平成１４年１０月７日付けの手続補正を却下する。
［理由］
（１）補正後の本願発明
　平成１４年１０月７日付けの本件補正により、補正前の特許請求の範囲の請求項１〜２０は、
　「【請求項１】資源を総合的に管理するホームサーバであって、前記ホームサーバは、各々が資源を有する複数のサーバに接続されており、前記ホームサーバが、
（１）前記複数サーバ内の１つのサーバから、資源の送信要求を受け取る手段と、
（２）要求された資源以上の資源を前記１つのサーバへ送信する手段と、
（３）前記要求された資源以上の資源がホームサーバにない場合は、ホームサーバが前記複数サーバ内の１つ以上のサーバへ不足資源をホームサーバへ送信するように要求を出し、該要求を受け取ったサーバの有する資源の半分をホームサーバが受信し、資源を集めて前記１つのサーバへ送信する手段と、
 を具備することを特徴とする、ホームサーバ。
【請求項２】前記資源を集めて前記１つサーバへ送信する手段（３）が、資源を集めるにあたり、仮想資源残高リストを用いて、１つ以上のサーバへ資源の送信要求を出す手段を含む、請求項１記載のホームサーバ。
【請求項３】前記資源を集めて前記１つサーバへ送信する手段（３）が、ホームサーバが他のサーバから資源を受信するにあたり、該他のサーバの資源残高を受信し、これに基づき前記仮想資源残高リストを更新する手段を含む、請求項２記載のホームサーバ。
【請求項４】前記資源を集めて前記１つサーバへ送信する手段（３）が、前記仮想資源残高リストを用いて残高のあるサーバから、資源の送信要求を出す手段を含む、請求項３記載のホームサーバ。
【請求項５】複数サーバ間において送信数を最適化するシステムであって、前記複数のサーバは資源を有し、前記複数のサーバには前記資源を総合的に管理する少なくとも１つのホームサーバが含まれており、
（１）ある１つのサーバへ資源の要求が、サーバの有する資源を超える要求であった場合、前記ホームサーバに資源の送信要求を出す手段と、
（２）前記送信要求以上の資源をホームサーバから前記１つのサーバへ送信する手段と、
（３）前記送信要求以上の資源がホームサーバにない場合は、ホームサーバが前記複数サーバ内の１つ以上のサーバへ不足資源をホームサーバへ送信するように要求を出し、該要求を受け取ったサーバの有する資源の半分をホームサーバが受信し、資源を集めて前記１つのサーバへ送信する手段と、
 を具備することを特徴とする、複数サーバ間送信数最適化システム。
【請求項６】前記資源を集めて前記１つのサーバへ送信する手段（３）が、資源を集めるにあたり、仮想資源残高リストを用いて、１つ以上のサーバへ資源の送信要求を出す手段を含む、請求項５記載のシステム。
【請求項７】前記資源を集めて前記１つのサーバへ送信する手段（３）が、ホームサーバが他のサーバから資源を受信するにあたり、該他のサーバの資源残高を受信し、これに基づき前記仮想資源残高リストを更新する手段を含む、請求項６記載のシステム。
【請求項８】前記資源を集めて前記１つのサーバへ送信する手段（３）が、前記仮想資源残高リストを用いて残高のあるサーバから、資源の送信要求を出す手段を含む、請求項７記載のシステム。
【請求項９】前記資源が電子マネーであり、前記送信要求が送金要求であり、前記仮想資源残高リストが、仮想電子マネー残高見積表である、請求項１乃至８の何れかに記載のシステム。
【請求項１０】複数サーバ間において送信数を最適化する方法であって、前記複数のサーバは資源を有し、前記複数のサーバには前記資源を総合的に管理する少なくとも１つのホームサーバが含まれており、
（１）ある１つのサーバへ資源の要求が、サーバの有する資源を超える要求であった場合、前記ホームサーバに資源の送信要求を出す段階と、
（２）前記送信要求以上の資源をホームサーバから前記１つのサーバへ送信する段階と、
（３）前記送信要求以上の資源がホームサーバにない場合は、ホームサーバが前記複数サーバ内の１つ以上のサーバへ不足資源をホームサーバへ送信するように要求を出し、該要求を受け取ったサーバの有する資源の半分をホームサーバが受信し、資源を集めて前記１つのサーバへ送信する段階と、
 を具備することを特徴とする、複数サーバ間送信数最適化方法。
【請求項１１】前記資源を集めて前記１つのサーバへ送信する段階（３）が、資源を集めるにあたり、仮想資源残高リストを用いて、１つ以上のサーバへ資源の送信要求を出す段階を含む、請求項１０記載の方法。
【請求項１２】前記資源を集めて前記１つのサーバへ送信する段階（３）が、ホームサーバが他のサーバから資源を受信するにあたり、該他のサーバの資源残高を受信し、これに基づき前記仮想資源残高リストを更新する段階を含む、請求項１１記載の方法。
【請求項１３】前記資源を集めて前記１つのサーバへ送信する段階（３）が、前記仮想資源残高リストを用いて残高のあるサーバから、資源の送信要求を出す段階を含む、請求項１２記載の方法。
【請求項１４】複数サーバ間において送信数を最適化するプログラムを記録したコンピュータ読取り可能な記録媒体であって、前記複数のサーバは資源を有し、前記複数のサーバには前記資源を総合的に管理する少なくとも１つのホームサーバが含まれており、前記プログラムが、
（１）ある１つのサーバへ資源の要求が、サーバの有する資源を超える要求であった場合、前記ホームサーバに資源の送信要求を出す機能と、
（２）前記送信要求以上の資源をホームサーバから前記１つのサーバへ送信する機能と、
（３）前記送信要求以上の資源がホームサーバにない場合は、ホームサーバが前記複数サーバ内の１つ以上のサーバへ不足資源をホームサーバへ送信するように要求を出し、該要求を受け取ったサーバの有する資源の半分をホームサーバが受信し、資源を集めて前記１つのサーバへ送信する機能と、
 をコンピュータに実行させる、コンピュータ読取り可能な記録媒体。」
と補正された。
　前記補正は、本件補正前の請求項１及び２、請求項７及び８、そして請求項１４及び１５を削除し、それに伴い各請求項の番号を繰り上げるものであり、また、前記補正は、本件補正前の請求項２０に記載した発明を特定するために必要な事項の「あるサーバ」、「前記サーバ」、及び「該要求に対して送信された資源」について、「ある１つのサーバ」、「前記１つのサーバ」、及び「該要求を受け取ったサーバの有する資源の半分」との限定を付加するものであり、特許法第１７条の２第４項第１及び２号で規定する特許請求の範囲の削除及び特許請求の範囲の減縮を目的とするものに該当する。
　そこで、本件補正後の前記請求項１に記載された発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか、すなわち平成１５年改正前特許法第１７条の２第５項において準用する同法第１２６条第４項の規定に適合するかどうかについて以下に検討する。
　
（２）引用例
　原査定の拒絶の理由に引用した特開平６−２９５３０４号公報（平成６年１０月２１日出願公開。以下、「引用例１」という。）には、図面と共に次の各記載がある。
　
（ア）「【請求項９】請求項１、２、６、７のいずれかにおいて、第１のコンピュータシステムで販売するチケット等の予約・販売対象物がある一定量以下になれば、チケット等の予約・販売を受け付けるためのファイルを保有している第２のコンピュータシステムを探し、第１のコンピュータシステムに、予約・販売を受け付けるためのファイルを移動させることを特徴とした予約販売方法。
【請求項１０】請求項１、２、３、４のいずれかにおいて、第１のコンピュータに、残席数及び、第２のコンピュータが稼働中か、それとも第１のコンピュータにファイルを移動済みか、を示すテーブルを設けて、第１のコンピュータシステムで販売するチケット等の予約・販売対象物がある一定量以下になれば、チケット等の予約・販売を受け付けるためのファイルを保有している第２のコンピュータシステムの中から、在庫を持っている第２のコンピュータシステムを該テーブルから探し、第１のコンピュータシステムに、予約・販売を受け付けるためのファイルを移動させることを特徴とした予約販売方法。
【請求項１１】請求項１、２、３、４のいずれかにおいて、第１のコンピュータに、残席数及び、第２のコンピュータが稼働中か、それとも第１のコンピュータにファイルを移動済みか、を示すテーブルを設けて、第１のコンピュータシステムで販売するチケット等の予約・販売対象物がある一定量以下になれば、チケット等の予約・販売を受け付けるためのファイルを保有している第２のコンピュータシステムの中から、在庫を持っている第２のコンピュータシステムを該テーブルから探し、その中から第１のコンピュータシステムに、予約・販売を受け付けるためのファイルを移動させることを特徴とした予約販売方法。
【請求項１２】請求項１、２、３、４のいずれかにおいて、第１のコンピュータに、残席数及び、第２のコンピュータが稼働中か、それとも第１のコンピュータにファイルを移動済みか、を示すテーブルを設けて、第１のコンピュータシステムで販売するチケット等の予約・販売対象物がある一定量以下になれば、チケット等の予約・販売を受け付けるためのファイルを保有している第２のコンピュータシステムの中から、在庫を持っている第２のコンピュータシステムを該テーブルから探し、販売速度の遅い第２のコンピュータシステムの中から、第１のコンピュータシステムに、予約・販売を受け付けるためのファイルを移動させることを特徴とした予約販売方法。
【請求項１３】請求項１２において、販売速度が遅いとは、
（１）予約・売上げ枚数が少ない、
（２）予約・売上げ枚数／割当て枚数が少ない
（３）在庫数が多い
（４）在庫数／割当て枚数が多い
のいずれかであることを特徴とした予約販売方法。
【請求項１４】請求項１、２、３、６、７、８のいずれかにおいて、ファイルの移動の指示は第１のコンピュータシステムが出すことを特徴とした予約販売方法。
【請求項１５】請求項１、２、３、６、７、８のいずれかにおいて、ファイルの移動の指示は第２のコンピュータシステムが出すことを特徴とした予約販売方法。
（中略）
【請求項１９】請求項１、２、３、６のいずれかにおいて、ある１つの第２のコンピュータシステムで販売するチケット等の予約・販売対象物がある一定量以下になるか、またはある所定の時間が経過したら、チケット等の予約・販売を受け付けるためのファイルを保有している他の第２のコンピュータシステムを探し、前記の第２のコンピュータシステムに、予約・販売を受け付けるためのファイルを移動させることを特徴とした予約販売方法。
【請求項２０】請求項１、２、３、６のいずれかにおいて、ある１つの第２のコンピュータシステムで販売するチケット等の予約・販売対象物がある一定量以下になるか、またはある所定の時間が経過したら、チケット等の予約・販売を受け付けるためのファイルを保有している他の第２のコンピュータシステムを探し、第１のコンピュータシステムに、予約・販売を受け付けるためのファイルを移動させることを特徴とした予約販売方法。
【請求項２１】請求項１、２、３、６のいずれかにおいて、ある１つの第２のコンピュータシステムで販売するチケット等の予約・販売対象物がある一定量以下になるか、またはある所定の時間が経過したら、チケット等の予約・販売を受け付けるためのファイルを保有している第１のコンピュータシステムから、前記の第２のコンピュータシステムに、予約・販売を受け付けるためのファイルを移動させることを特徴とした予約販売方法。」（特許請求の範囲の請求項９〜２１）
　
（イ）「【０００４】
【課題を解決するための手段】ホストコンピュータで管理している販売に必要なファイル（以下在庫ファイルという）を分割してファイルサーバーに記憶させ、ホストとファイルサーバーはＬＡＮで接続する。顧客からの販売の問合せは、端末を用い、ファイルサーバーと端末は公衆回線網で接続する。端末から販売の問合せがあった場合、その端末と接続されているファイルサーバーは、そのファイルがファイルサーバーに格納されていて、かつまだ在庫がある場合は、そこで販売の手続きを終了し、ホストコンピュータにアクセスしない。そうでない場合だけホストコンピュータにアクセスする。これによって、ホストコンピュータへの負荷集中が軽減できる。
【０００５】
【作用】列車の指定席券の販売を例にとって説明する。ホストコンピュータには、出発日時、列車名、及びその座席数を記憶した列車ファイル（ＲＦ）と座席別に販売状況を記憶した座席ファイル（ＺＦ）がある。販売開始直前にホストコンピュータは、各列車の在庫を（一部分をホストコンピュータに残して）単数または複数のファイルサーバーに、分割してダウンロードする。ダウンロードされたＲＦ、ＺＦの１つのファイルをそれぞれＲＦ’、ＺＦ’と呼ぶ。ＺＦには、座席ごとの販売状況（空席または販売済み）または、ファイルサーバーで販売中の場合はダウンロード先のファイルサーバーの番号を記憶させておく。
【０００６】端末から販売の問合せがあった場合、その端末と接続されているファイルサーバーは、該当する列車のＲＦ’、ＺＦ’を参照し、在庫があれば、その座席を販売する。在庫がなければ、ホストコンピュータにアクセスする。
【０００７】販売開始からある所定の時間が経過、あるいは所定の割合の枚数を販売、あるいは所定時間あたりの売上枚数が一定値以下になった場合は、ＲＦ’、ＺＦ’をホストコンピュータにアップロードする。
【０００８】また、ホストコンピュータに在庫がなくなれば、売れ残っているファイルサーバーを検索し、アップロードする。このようにして、販売ニーズがあるにもかかわらず、売れ残りが生じる、ということがないようにする。」（段落【０００４】〜【０００８】）
　
（ウ）「【００１６】次にファイルの分散方法を述べる。販売開始直後には、多数の端末からホストコンピュータ１１に負荷が集中するので、販売開始前に、列車ファイルＲＦ（列車ごとの残席数を示すファイル）と座席ファイルＺＦ（座席ごとの販売状況を示すファイル）を分割して、ファイルサーバー１からファイルサーバーｎにダウンロードしておく（ホストコンピュータ１１にも一部分残しておく）。図２に分割した概要を示す。ＣＰＵ１０１、１０２、１０３はそれぞれファイルサーバ１、２、３のＣＰＵである。例えば、ひかりＡ号のＲＦ、ＺＦをＡ０、Ａ１、Ａ２、Ａ３、・・・に分割し、Ａ０をホストコンピュータ１１の磁気ディスクに残し、Ａ１、Ａ２、Ａ３をそれぞれファイルサーバー１、２、３に分割して、記憶させる。ひかりＢ号、Ｃ号も同様である。
（中略）
【００２７】図３にチケットを販売する時の手順を示す。
ステップ３０１：販売開始前に、ホストで管理しているＲＦ、ＺＦを（一部分をホストに残して）ファイルサーバーにダウンロードする。
ステップ３０２：ファイルサーバーは端末からの予約または販売の問合せが発生するのを待つ。発生すれば、ステップ３０３へ。
ステップ３０３：操作している端末と接続されたファイルサーバーのファイルにアクセス可であるか否かを判断する。ホストからファイルサーバーにダウンロード中、またはファイルサーバーからホストへアップロード中あるいは、ファイルサーバーで当該ファイルにアクセス中であれば、ファイルサーバーにアクセスできないので、ステップ３０７へ進みホストで処理する。ファイルサーバーにアクセス可ならステップ３０４へ。
ステップ３０４：乗客の希望する列車の在庫がファイルサーバーにあるか否かＲＦ’を調べる。在庫があれば、ステップ３０５へ、なければステップ３０７へ。
【００２８】ステップ３０５：ＺＦ’から空席の座席を見つけ、販売する。
ステップ３０６：ＲＦ’の在庫数を減算し、ＺＦ’のフラグを’１０’（予約のみで未発券）または’１１’（発券済み）にする。
ステップ３０７：ファイルサーバーで販売できない時、ホストで販売する。
ステップ３０８：販売のピークは過ぎたか否か、を判断する。判断の方法は何通りか考えられる。例えば、販売開始からある所定の時間が経過、あるいは所定の割合の枚数を販売、あるいは所定時間あたりの売上枚数が一定値以下になった場合、等がある。これらの場合は、ピークを過ぎた、と判断し、ステップ３０９へ、そうでなければステップ３０２へ進む。
ステップ３０９：ＺＦ’、ＲＦ’をホストへアップロードし、ホストでＺＦ、ＲＦを更新する。
【００２９】ステップ３０３で、ファイルサーバにアクセス不可の場合、ここでは、「ホストへアクセスする」と述べたが、他にも方法は考えられる。
（１）当該ファイルへのダウンロード等のアクセスが終わるまで、端末からの問合せを待たせる。
（２）１列車を１ファイルとしてＺＦ’を構成すると（ＺＦ’１、ＺＦ’２、・・）、ある列車ファイルへはアクセス不可でも他の列車へは、アクセス可能となる。また、同一ファイルへ２つのトランザクションがアクセスしようとした時でも、該ファイルへのアクセスが可となるまで、１つのトランザクションからの問合せを待たせる。
（３）１列車を１車両ごとに分けて別ファイルとしてＺＦ’を構成し、該ファイルへのアクセスが可となるまで、端末からの問合せを待たせる。または、他の車両のファイルにアクセスする。
【００３０】（２）や（３）の場合は、待ち時間は（１）と比べて、極めて小さい。
【００３１】図３では省略したが、先に述べたように、ステップ３０７でホストに在庫がなければ、ＲＦを調べ、稼働中のファイルサーバーにアクセスして、在庫を検索し、販売を行う。稼働中のすべてのファイルサーバーに在庫がなければ、売り切れということになる。」（段落【００１６】〜【００３１】）
　
（エ）「【００３７】次に、ファイルサーバーの一部に在庫があるにもかかわらず、ホストコンピュータ１１に在庫がなくなった時、あるいは在庫がなくなる直前の対処を図６を用いて説明する。
ステップ６０１：ＲＦのファイルサーバー稼働フラグの中で’１’になっているファイルサーバーを探す。
ステップ６０２：’１’になっているファイルサーバーがあればステップ６０３へ進む。しかし、すべてのファイルサーバーが’０’ならば、アップロード済みであるので、ホストコンピュータ１１に在庫がなければ、売り切れたことになる。
ステップ６０３：その中から、販売速度の遅いファイルサーバーを選ぶ。その方法は、（１）売上枚数が最小のもの（２）売上枚数／アサイン枚数が最小のもの、（３）残枚数が最大のもの（４）残枚数／アサイン枚数が最大のもの、等がある。そのために、ＲＦ，ＺＦ以外に、列車ごとにホスト、各ファイルサーバーに何枚ずつアサインしたかを記憶させておくファイルを、ダウンロード時に準備しておく。販売速度の遅いファイルサーバーが決まったら、ホストへアップロードさせる。
ステップ６０４：アップロードしたファイルサーバーのＲＦ’、ＺＦ’を減算し、ホストのＲＦ、ＺＦを加算する。
【００３８】その他、ファイルサーバーへダウンロード後、所定の時間が過ぎれば、ホストコンピュータ１１へアップロードさせる、という方法でも良い。
【００３９】これによって、ファイルサーバーに在庫があるにもかかわらず、乗客がチケットを購入できない、という不都合を解消する。なお、図１の構成では、ホストコンピュータ１１が１台、ファイルサーバーが複数台の例を述べたが、ホストコンピュータが複数台でもよいし、ファイルサーバーが１台でも本実施例は適用可能であることは言うまでもない。」（段落【００３７】〜【００３９】）
　
（オ）「【００４０】第１の実施例では、ファイルのダウンロード、アップロードの権限は、ホストコンピュータ１１にあった。第２の実施例では、ファイルサーバーにその権限を持たせ、ファイルサーバーが上記指示を行うものとする。ファイルの管理の容易性からピーク時以外のファイルの格納場所はホストコンピュータ１１とする。ファイルサーバー１、２、・・・ｎが、権限を持ったＲＦを、それぞれ列車１、列車２、・・・列車ｎとする。表５にファイルサーバーの権限とＲＦ名の関係を示す。
（中略）
【００４８】図７に本実施例の手順を示す。
ステップ７０１：販売前に、各ファイルサーバーが権限を持ったファイルをどう分配するのか、ホストコンピュータ１１に指示をする。ホストコンピュータ１１は、表５を参照し、権限のあるファイルサーバーであるかをチェックした後、各ファイルサーバーからの指示に従って、ダウンロードする。
ステップ７０２：ファイルサーバーは端末からの予約または販売の問合せの発生を待つ。問合せが発生すれば、ステップ７０３へ進む。
ステップ７０３：ファイルサーバーに在庫があれば、ステップ７０５へ進み、なければ、ステップ７０４へ進む。
ステップ７０４：ホストコンピュータ１１で予約または販売を受け付ける。
ステップ７０５：ＲＦ’の在庫数を減算する。
ステップ７０６：ファイルサーバーが有している座席を販売する。
ステップ７０７：ＺＦ’のフラグを’１０’または’１１’にする。
ステップ７０８：各ファイルサーバーには、自分に権限のあるファイルと他のファイルサーバーからアサインしてもらった２種類の性格を持ったファイルを有している。この２種類のファイルともホストコンピュータ１１へアップロードする権限は、（表５で示したように）今そのファイルが存在しているファイルサーバーにある、とする。アップロードする（販売を終了する）ならステップ７０９へ、まだアップロードしない（販売を続ける）ならステップ７０２へ進む。
ステップ７０９：ホストコンピュータ１１へアップロードして、ファイルサーバーでは、ＲＦ’、ＺＦ’を更新し該ファイルサーバーでの販売は終了する。ホストコンピュータ１１では、ＲＦ、ＺＦを更新する。
【００４９】本実施例では、各ファイルサーバーを有している組織が、他の組織に販売を依頼する量、自分が販売を引き受ける量を決めることができるので、柔軟な販売方法ができる。
【００５０】また、ステップ７０８で、「アップロードする権限は、今そのファイルが存在しているファイルサーバーにある」と述べたが、ファイルサーバーで売れ残っても何の損失もファイルサーバー側になければ、ファイルサーバー側からは、積極的には、アップロードしないことが考えられる。その場合は、各ファイルに対して、アップロードする権限もダウンロードする権限のあるファイルサーバーに持たせればよい。
【００５１】そのために、表５、及び表６または表７をホストコンピュータ１１だけでなく、各ファイルサーバーにも持たせる。例えば、表５で列車１というＲＦは、ダウンロードもアップロードもその権限はファイルサーバー１のみに持たせる。この場合、ファイルサーバー１に在庫が少なくなれば、ファイルサーバー１は他のファイルサーバー、ホストコンピュータ１１に在庫を問合せる。在庫を参照されたファイルサーバー（及びホストコンピュータ１１）は、表５でファイルサーバー１は列車１というＲＦをアップロード（ホストコンピュータ１１に対してはダウンロード）させる権限を持っているファイルサーバーであるか否かをチェックする。権限が有る、と確認できれば、表６または表７で、自分が有している列車１のＺＦを検索し、在庫数を回答する。または、ＺＦを検索するかわりに、各ＺＦの残席数を管理するファイルを用意しておき、その値を回答しても良い。
【００５２】ファイルサーバー１は、在庫の多いファイルサーバーにアップロードを指示したり、ホストコンピュータ１１にファイルサーバー１にダウンロードするように指示したりする。指示を受けたファイルサーバー及びホストコンピュータ１１は、自分が有しているＺＦをそのファイルサーバーからホストコンピュータ１１にアップロードしたり、ホストコンピュータ１１からファイルサーバー１にダウンロードしたりする。
【００５３】上記の説明では、表５、及び表６または表７をホストコンピュータ１１、全ファイルサーバーに記憶させる、と述べたが、表５を分割し、ダウンロードさせる権限を持ったファイルサーバーの表をホストコンピュータ１１に、アップロードさせる権限を持ったファイルサーバーの表を全ファイルサーバーに記憶させても良い。表６、表７も分割し、ファイルサーバーに持たせる情報は、自ファイルサーバーが有しているＺＦ名だけに限定しても良い。例えば表５において、ファイルサーバー１に記憶させるＺＦは、’座席１４’、’座席１５’、’座席１６’、’座席１７だけにしてもよい。
【００５４】この例では、各ファイルサーバーを有している組織が、他の組織に販売を依頼する量を決めたり、売れ行きを見て、依頼を取りやめて自分で販売をする、と決めることができるので、柔軟な販売方法ができる。」（段落【００４０】〜【００５４】）
　
（カ）「【００６４】第４の実施例として図９に、図３と図８を組み合わせたフローチャートを示す。（ファイルを動的に移動させる例である。）ステップ８０１、８０２、３０１がホストコンピュータ１１側での処理であり、それ以降がファイルサーバー側での処理である。ファイルサーバー側では、図９の処理と並行して、図８のステップ８０３、８０４、８０５、８０６の処理を行い、ＲＦ、ＺＦのファイルのアンロックを行う。これによって、ステップ３０３でファイルサーバーのファイルにアクセス可となる。
【００６５】第４の実施例では、ファイルのダウンロード、アップロードの権限が、ホストコンピュータ１１にあるが、その権限をファイルサーバーに持たせることも可能である。ステップ３０１で、ステップ７０１のように、各ファイルサーバーがＲＦ、ＺＦの分割の仕方を指示し、ホスト側では、ステップ８０３、８０４、８０５、８０６でファイルをアンロックし、アンロックしたファイルをステップ３０１の指示に従って、各ファイルサーバーにダウンロードする、という方法がある。
【００６６】その他、ステップ３０１で指示すれば、すぐにファイルサーバーにダウンロードし、ファイルサーバー側でステップ８０３からステップ８０６の処理を繰り返して、ファイルをアンロックする、という方法でもよい。
【００６７】また、第２の実施例で述べたように、あるファイルに対してアップロードもダウンロードの権限も有るファイルサーバーが、自ファイルサーバー内に在庫が少なくなったり、またはダウンロード後、ある時間が経過すれば、他のファイルサーバーから自ファイルサーバーに在庫ファイルを移動させたり、ホストコンピュータにアップロードさせたり、ホストコンピュータにある在庫ファイルを自ファイルサーバーにダウンロードさせたりすることは、もちろん可能である。
【００６８】第３、第４の実施例では、図１の構成を引用したが、ホストコンピュータが複数台あってもよいし、ファイルサーバーが１台でも本実施例は適用可能であることは言うまでもない。
【００６９】第３、第４の実施例では、負荷のピークが特定時刻に集中しない、という効果がある。
【００７０】第１から第４の実施例では、列車のチケット販売を例にとって説明したが、コンサート、野球場等、在庫が限られていて、販売開始時に申込みが集中するシステムに適用可能であることは言うまでもない。」（段落【００７０】〜【００６７】）
　
　以上の記載から見て、引用例１には、次のような発明が記載されているものと認められる。
　
　「座席指定又はチケットの予約販売方法であって、ホストコンピュータ１１は、ＬＡＮ１２を介して、ファイルサーバ１〜ｎと接続され、各ファイルサーバ１〜ｎは、公衆回線１０，２０，…，３０を介して端末１ａ〜１ｚ；２ａ〜２ｚ；…；ｎａ〜ｎｚと接続されており、
　販売開始直前に、ホストコンピュータ１１にある列車ファイルＲＦと座席ファイルＺＦを分割してファイルサーバ１〜ｎにダウンロードし、
　販売頻度の高い期間中に、或る１つのファイルサーバの在庫が一定量以下となった場合、ホストコンピュータ１１が保有する在庫ファイルＲＦ及びＺＦを前記或る１つのファイルサーバにダウンロードすることにより、前記或る１つのファイルサーバが一定量以上の在庫を持つようにし、
　販売頻度の高い期間中に、或る１つのファイルサーバの在庫が一定量以下となった場合、在庫を有する他のファイルサーバを探し出し、他のファイルサーバの在庫ファイルＲＦ’及びＺＦ’を前記或る１つのファイルサーバに移動させ、前記或る１つのファイルサーバが一定量以上の在庫を持つようにし、
　販売頻度の高い期間中に、或る１つのファイルサーバの在庫が一定量以下となった場合、在庫を有する他のファイルサーバを探し出し、他のファイルサーバの在庫ファイルＲＦ’及びＺＦ’をホストコンピュータ１１に移動させるようにし、、
　販売頻度の高い期間中に、ホストコンピュータ１１の在庫が一定量以下となった場合、ファイルサーバ１〜ｎの中から、在庫を有するファイルサーバを探し出し、そのファイルサーバの在庫ファイルＲＦ’及びＺＦ’をホストコンピュータ１１に移動させ、ホストコンピュータ１１が一定量以上の在庫を持つようにし、
　販売開始からある所定の時間が経過し販売ピークを過ぎた場合、所定の枚数を販売した場合、或いは所定時間あたりの売上げ枚数が一定値以下となった場合、各ファイルサーバ１〜ｎは、在庫ファイル、すなわち列車ファイルＲＦ’及び座席ファイルＺＦ’を、ホストコンピュータ１１にアップロードし、これ以後ホストコンピュータ１１は、列車ファイルＲＦ、座席ファイルＺＦを一元管理するようにして、
　ホストコンピュータ１１及びファイルサーバ１〜ｎ間で座席指定の在庫を適正に分散する予約販売方法。」
　
（３）対比
　本願補正発明と引用例１に記載された発明を対比すると、本願補正発明の「資源」は、引用例１に記載された発明の「座席指定席券」に相当し、本願補正発明の「ホームサーバ」、「サーバ」は、引用例１に記載された発明の「ホストコンピュータ１１」、「ファイルサーバ１〜ｎ」に相当することは、明らかである。
　そして、引用例１には、ホストコンピュータ１１が、座席指定の予約販売等の状況を示す列車ファイルＲＦ’及び座席ファイルＺＦ’を各々有する複数のファイルサーバ１〜ｎに、ＬＡＮ１２を介して接続され、そして該ホストコンピュータ１１は、列車の座席指定席券の予約販売状況を総合的に管理することが記載されている（段落【０００４】，【００１１】参照。）から、本願補正発明と引用例１に記載された発明とは、
　「資源を総合的に管理するホームサーバであって、前記ホームサーバは、各々が資源を有する複数のサーバに接続されている」
点で差異はない。
　また、引用例１には、
(i)座席指定の予約販売中に、ホストコンピュータ１１の在庫が一定量以下になった場合、在庫ファイルを保有しているファイルサーバを探し出し、該探し出したファイルサーバの在庫ファイルをホストコンピュータ１１に移動させ、ホストコンピュータ１１の在庫量を一定量以上とすることが記載されており（特許請求の範囲の請求項９、段落【０００８】、及び前記（カ）参照。）、
(ii)座席指定の予約販売中に、ホストコンピュータ１１の在庫が一定量以下になった場合、在庫ファイルを保有しかつ在庫を有するファイルサーバを探し出し、該探し出したファイルサーバの在庫ファイルをホストコンピュータ１１に移動させ、ホストコンピュータ１１の在庫量を一定量以上とすることが記載されており（特許請求の範囲の請求項１０〜１２、及び前記（カ）参照。）、
(iii)座席指定の予約販売中に、複数のファイルサーバ１〜ｎの中の或るファイルサーバの在庫が一定量以下になった場合、在庫ファイルを保有している他のファイルサーバを探し出し、該探し出した他のファイルサーバの在庫ファイルを前記或るファイルサーバに移動させ、前記或るファイルサーバの在庫量を一定量以上とすることが記載されており（特許請求の範囲の請求項１９、及び前記（カ）参照。）、
(iv)座席指定の予約販売実行中に、複数のファイルサーバ１〜ｎの中の或るファイルサーバの在庫が一定量以下になった場合、在庫ファイルを保有している他のファイルサーバを探し出し、該探し出した他のファイルサーバの在庫ファイルをホストコンピュータ１１に移動させることが記載されており（特許請求の範囲の請求項２０、及び前記（カ）参照。）、
(v)座席指定の予約販売実行中に、複数のファイルサーバ１〜ｎの中の或るファイルサーバの在庫が一定量以下になった場合、ホストコンピュータ１１が保有する在庫ファイルを前記ファイルサーバに移動させ、前記或るファイルサーバの在庫量を一定量以上とすることが記載されており（特許請求の範囲の請求項２１、及び前記（カ）参照。）、
(vi)ホストコンピュータ１１及びファイルサーバが有する在庫ファイルに対する移動の指示は、ホストコンピュータ１１及びファイルサーバの何れもが出すことができることが記載されている（特許請求の範囲の請求項１４，１５、及び前記（カ）参照。）。
　これらの記載及び引用例１に記載された発明の趣旨に鑑みるに、引用例１に記載された発明は、座席指定の予約販売中に、ホストコンピュータ１１がファイルサーバ１〜ｎの中の１つのファイルサーバから在庫ファイルの移動指示すなわち転送要求を受け取った時（前記(vi)参照。）、要求された座席指定がホストコンピュータ１１に有る場合は、ホストコンピュータ１１の在庫ファイルを前記１つのファイルサーバへ移動し（前記(v)参照。）、要求された座席指定がホストコンピュータ１１にない場合は、ホストコンピュータ１１がファイルサーバ１〜ｎの中の１つ以上のファイルサーバへ不足する座席指定が乗っている在庫ファイルをホストコンピュータ１１へ移動するように指示を出し（前記(vi)参照。）、移動指示を受け取ったファイルサーバの在庫ファイルをホストコンピュータ１１が受信し、座席指定が登録されている在庫ファイルを集めて前記１つのファイルサーバへ送信する（前記(ii)に示される操作を必要なだけ実行することに相当。）ものである。
　そうすると、本願補正発明と引用例１に記載された発明とは、
　「前記ホームサーバが、
（１）前記複数サーバ内の１つのサーバから、資源の送信要求を受け取る手段と、
（２）要求された資源以上の資源を前記１つのサーバへ送信する手段と、
（３）前記要求された資源以上の資源がホームサーバにない場合は、ホームサーバが前記複数サーバ内の１つ以上のサーバへ不足資源をホームサーバへ送信するように要求を出し、該要求を受け取ったサーバの有する資源をホームサーバが受信し、資源を集めて前記１つのサーバへ送信する手段」
を有する点で差異はない。
　したがって、本願補正発明と引用例１に記載された発明とは、次の点で相違し、その余の点で一致する。
（相違点１）
　本願補正発明は、不足資源のホームサーバへの送信要求を受け取ったサーバの有する資源の半分をホームサーバが受信するのに対して、
　引用例１に記載された発明は、不足座席指定のホストコンピュータ１１への移動指示を受け取ったファイルサーバの有する座席指定が登録されている在庫ファイルをホストコンピュータ１１が受信する点。
（相違点２）
　本願補正発明が「物の発明」であるのに対して、引用例１に記載された発明は、「方法の発明」である点。
　
（４）判断
（相違点１について）
　先に述べたように、引用例１に記載された発明は、在庫ファイルの移動指示を受けたファイルサーバが、その在庫ファイルＲＦ’及びＺＦ’を、ホストコンピュータ１１へ送信するもの、すなわち、移動指示を受けたファイルサーバは、自己が有するすべての在庫を、ホストコンピュータ１１へ送信するものである。
　然るに、或るサーバの資源が不足しそのサーバが他のサーバへ資源を要求する時、該要求を受けた他のサーバが自己の保有する資源の内どれだけの資源を或るサーバへ送信するかは、単なる設計上の「決め」の問題に過ぎず（例えば、自己の保有する資源の全部、半分、三分の一、又はある一定の量等々が考えられる。）、しかもこのことは当業者が従来より自由に設計しかつ決定していたことである。
　したがって、引用例１に記載された発明に於いて、ファイルサーバが自己の保有する在庫（資源）全部を送信していたものを、自己の保有する在庫の半分を送信するようにして、本願補正発明の如く構成することは、当業者が適宜なし得ることである。
（相違点２について）
　「物の発明」と「方法の発明」とは、単にカテゴリー名が相違するだけのことであるから、引用例１に記載された発明のカテゴリー名を、「方法の発明」から「物の発明」に変えることは、当業者が適宜なし得ることである。
　　
（５）むすび
　以上のとおり、本願補正発明は、特許法第２９条第２項の規定により特許出願の際、独立して特許を受けることができるものではなく、特許法第１７条の２第５項で準用する同法１２６条第４項の規定に違反するものであるから、平成１４年１１月６日付けの手続補正は、平成１５年改正前特許法第１５９条第１項で準用する同法第５３条第１項の規定により却下すべきものである。
　
３．本願発明について
　平成１４年１０月７日付けの手続補正は、前記のとおり却下されるから、本願の特許請求の範囲の請求項１に係る発明（以下、「本願発明」という。）は、平成１４年２月１３日付けの手続補正書により補正された特許請求の範囲の請求項１に記載された次のとおりのものである。
　
　「【請求項１】資源を総合的に管理するホームサーバであって、前記ホームサーバは、各々が資源を有する複数のサーバに接続されており、前記ホームサーバが、
（１）前記複数サーバ内の１つのサーバから、資源の送信要求を受け取る手段と、
（２）要求された資源以上の資源を前記１つのサーバへ送信する手段と、
（３）前記要求された資源以上の資源がホームサーバにない場合は、ホームサーバが前記複数サーバ内の１つ以上のサーバへ不足資源をホームサーバへ送信するように要求を出し、該要求に対して送信された資源をホームサーバが受信し、資源を集めて前記１つのサーバへ送信する手段と、
 を具備することを特徴とする、ホームサーバ。」
　
（１）引用例
　原査定の拒絶理由に引用された引用例、及びその記載事項は、前記「２．（２）」項に記載したとおりである。
　
（２）対比・判断
　本願発明は、前記「２．」項で検討した本願補正発明における「要求を受け取ったサーバの有する資源の半分」からその限定事項である「半分」を省き、「要求に対して送信された資源」としたものである。
　そうすると、本願発明を特定する事項をすべて含み、さらに他の特定する事項を付加したものに相当する本願補正発明が、前記「２．（４）」項に記載したとおり、引用例１に記載された発明及び周知技術とに基づいて当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用例１に記載された発明及び周知技術とに基づいて当業者が容易に発明をすることができたものである。
　
（３）むすび
　以上のとおり、本願発明は、引用例１に記載された発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。