• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない。 G06F
管理番号 1122203
審判番号 不服2002-19538  
総通号数 70 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2000-03-14 
種別 拒絶査定不服の審決 
審判請求日 2002-10-07 
確定日 2005-08-24 
事件の表示 平成10年特許願第241559号「複数サーバ間送信数最適化システムおよびその方法」拒絶査定不服審判事件〔平成12年 3月14日出願公開、特開2000- 76332〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続きの経緯・本願発明
本願は、平成10年8月27に出願されたものであって、平成14年7月2日付けで拒絶査定がなされ、これに対し平成14年10月7日に拒絶査定に対する審判請求がなされると共に同日付けで手続補正がなされたものである。

2.平成14年10月7日付けの手続補正についての補正却下の決定
[補正却下の決定の結論]
平成14年10月7日付けの手続補正を却下する。
[理由]
(1)補正後の本願発明
平成14年10月7日付けの本件補正により、補正前の特許請求の範囲の請求項1〜20は、
「【請求項1】資源を総合的に管理するホームサーバであって、前記ホームサーバは、各々が資源を有する複数のサーバに接続されており、前記ホームサーバが、
(1)前記複数サーバ内の1つのサーバから、資源の送信要求を受け取る手段と、
(2)要求された資源以上の資源を前記1つのサーバへ送信する手段と、
(3)前記要求された資源以上の資源がホームサーバにない場合は、ホームサーバが前記複数サーバ内の1つ以上のサーバへ不足資源をホームサーバへ送信するように要求を出し、該要求を受け取ったサーバの有する資源の半分をホームサーバが受信し、資源を集めて前記1つのサーバへ送信する手段と、
を具備することを特徴とする、ホームサーバ。
【請求項2】前記資源を集めて前記1つサーバへ送信する手段(3)が、資源を集めるにあたり、仮想資源残高リストを用いて、1つ以上のサーバへ資源の送信要求を出す手段を含む、請求項1記載のホームサーバ。
【請求項3】前記資源を集めて前記1つサーバへ送信する手段(3)が、ホームサーバが他のサーバから資源を受信するにあたり、該他のサーバの資源残高を受信し、これに基づき前記仮想資源残高リストを更新する手段を含む、請求項2記載のホームサーバ。
【請求項4】前記資源を集めて前記1つサーバへ送信する手段(3)が、前記仮想資源残高リストを用いて残高のあるサーバから、資源の送信要求を出す手段を含む、請求項3記載のホームサーバ。
【請求項5】複数サーバ間において送信数を最適化するシステムであって、前記複数のサーバは資源を有し、前記複数のサーバには前記資源を総合的に管理する少なくとも1つのホームサーバが含まれており、
(1)ある1つのサーバへ資源の要求が、サーバの有する資源を超える要求であった場合、前記ホームサーバに資源の送信要求を出す手段と、
(2)前記送信要求以上の資源をホームサーバから前記1つのサーバへ送信する手段と、
(3)前記送信要求以上の資源がホームサーバにない場合は、ホームサーバが前記複数サーバ内の1つ以上のサーバへ不足資源をホームサーバへ送信するように要求を出し、該要求を受け取ったサーバの有する資源の半分をホームサーバが受信し、資源を集めて前記1つのサーバへ送信する手段と、
を具備することを特徴とする、複数サーバ間送信数最適化システム。
【請求項6】前記資源を集めて前記1つのサーバへ送信する手段(3)が、資源を集めるにあたり、仮想資源残高リストを用いて、1つ以上のサーバへ資源の送信要求を出す手段を含む、請求項5記載のシステム。
【請求項7】前記資源を集めて前記1つのサーバへ送信する手段(3)が、ホームサーバが他のサーバから資源を受信するにあたり、該他のサーバの資源残高を受信し、これに基づき前記仮想資源残高リストを更新する手段を含む、請求項6記載のシステム。
【請求項8】前記資源を集めて前記1つのサーバへ送信する手段(3)が、前記仮想資源残高リストを用いて残高のあるサーバから、資源の送信要求を出す手段を含む、請求項7記載のシステム。
【請求項9】前記資源が電子マネーであり、前記送信要求が送金要求であり、前記仮想資源残高リストが、仮想電子マネー残高見積表である、請求項1乃至8の何れかに記載のシステム。
【請求項10】複数サーバ間において送信数を最適化する方法であって、前記複数のサーバは資源を有し、前記複数のサーバには前記資源を総合的に管理する少なくとも1つのホームサーバが含まれており、
(1)ある1つのサーバへ資源の要求が、サーバの有する資源を超える要求であった場合、前記ホームサーバに資源の送信要求を出す段階と、
(2)前記送信要求以上の資源をホームサーバから前記1つのサーバへ送信する段階と、
(3)前記送信要求以上の資源がホームサーバにない場合は、ホームサーバが前記複数サーバ内の1つ以上のサーバへ不足資源をホームサーバへ送信するように要求を出し、該要求を受け取ったサーバの有する資源の半分をホームサーバが受信し、資源を集めて前記1つのサーバへ送信する段階と、
を具備することを特徴とする、複数サーバ間送信数最適化方法。
【請求項11】前記資源を集めて前記1つのサーバへ送信する段階(3)が、資源を集めるにあたり、仮想資源残高リストを用いて、1つ以上のサーバへ資源の送信要求を出す段階を含む、請求項10記載の方法。
【請求項12】前記資源を集めて前記1つのサーバへ送信する段階(3)が、ホームサーバが他のサーバから資源を受信するにあたり、該他のサーバの資源残高を受信し、これに基づき前記仮想資源残高リストを更新する段階を含む、請求項11記載の方法。
【請求項13】前記資源を集めて前記1つのサーバへ送信する段階(3)が、前記仮想資源残高リストを用いて残高のあるサーバから、資源の送信要求を出す段階を含む、請求項12記載の方法。
【請求項14】複数サーバ間において送信数を最適化するプログラムを記録したコンピュータ読取り可能な記録媒体であって、前記複数のサーバは資源を有し、前記複数のサーバには前記資源を総合的に管理する少なくとも1つのホームサーバが含まれており、前記プログラムが、
(1)ある1つのサーバへ資源の要求が、サーバの有する資源を超える要求であった場合、前記ホームサーバに資源の送信要求を出す機能と、
(2)前記送信要求以上の資源をホームサーバから前記1つのサーバへ送信する機能と、
(3)前記送信要求以上の資源がホームサーバにない場合は、ホームサーバが前記複数サーバ内の1つ以上のサーバへ不足資源をホームサーバへ送信するように要求を出し、該要求を受け取ったサーバの有する資源の半分をホームサーバが受信し、資源を集めて前記1つのサーバへ送信する機能と、
をコンピュータに実行させる、コンピュータ読取り可能な記録媒体。」
と補正された。
前記補正は、本件補正前の請求項1及び2、請求項7及び8、そして請求項14及び15を削除し、それに伴い各請求項の番号を繰り上げるものであり、また、前記補正は、本件補正前の請求項20に記載した発明を特定するために必要な事項の「あるサーバ」、「前記サーバ」、及び「該要求に対して送信された資源」について、「ある1つのサーバ」、「前記1つのサーバ」、及び「該要求を受け取ったサーバの有する資源の半分」との限定を付加するものであり、特許法第17条の2第4項第1及び2号で規定する特許請求の範囲の削除及び特許請求の範囲の減縮を目的とするものに該当する。
そこで、本件補正後の前記請求項1に記載された発明(以下、「本願補正発明」という。)が特許出願の際独立して特許を受けることができるものであるか、すなわち平成15年改正前特許法第17条の2第5項において準用する同法第126条第4項の規定に適合するかどうかについて以下に検討する。

(2)引用例
原査定の拒絶の理由に引用した特開平6-295304号公報(平成6年10月21日出願公開。以下、「引用例1」という。)には、図面と共に次の各記載がある。

(ア)「【請求項9】請求項1、2、6、7のいずれかにおいて、第1のコンピュータシステムで販売するチケット等の予約・販売対象物がある一定量以下になれば、チケット等の予約・販売を受け付けるためのファイルを保有している第2のコンピュータシステムを探し、第1のコンピュータシステムに、予約・販売を受け付けるためのファイルを移動させることを特徴とした予約販売方法。
【請求項10】請求項1、2、3、4のいずれかにおいて、第1のコンピュータに、残席数及び、第2のコンピュータが稼働中か、それとも第1のコンピュータにファイルを移動済みか、を示すテーブルを設けて、第1のコンピュータシステムで販売するチケット等の予約・販売対象物がある一定量以下になれば、チケット等の予約・販売を受け付けるためのファイルを保有している第2のコンピュータシステムの中から、在庫を持っている第2のコンピュータシステムを該テーブルから探し、第1のコンピュータシステムに、予約・販売を受け付けるためのファイルを移動させることを特徴とした予約販売方法。
【請求項11】請求項1、2、3、4のいずれかにおいて、第1のコンピュータに、残席数及び、第2のコンピュータが稼働中か、それとも第1のコンピュータにファイルを移動済みか、を示すテーブルを設けて、第1のコンピュータシステムで販売するチケット等の予約・販売対象物がある一定量以下になれば、チケット等の予約・販売を受け付けるためのファイルを保有している第2のコンピュータシステムの中から、在庫を持っている第2のコンピュータシステムを該テーブルから探し、その中から第1のコンピュータシステムに、予約・販売を受け付けるためのファイルを移動させることを特徴とした予約販売方法。
【請求項12】請求項1、2、3、4のいずれかにおいて、第1のコンピュータに、残席数及び、第2のコンピュータが稼働中か、それとも第1のコンピュータにファイルを移動済みか、を示すテーブルを設けて、第1のコンピュータシステムで販売するチケット等の予約・販売対象物がある一定量以下になれば、チケット等の予約・販売を受け付けるためのファイルを保有している第2のコンピュータシステムの中から、在庫を持っている第2のコンピュータシステムを該テーブルから探し、販売速度の遅い第2のコンピュータシステムの中から、第1のコンピュータシステムに、予約・販売を受け付けるためのファイルを移動させることを特徴とした予約販売方法。
【請求項13】請求項12において、販売速度が遅いとは、
(1)予約・売上げ枚数が少ない、
(2)予約・売上げ枚数/割当て枚数が少ない
(3)在庫数が多い
(4)在庫数/割当て枚数が多い
のいずれかであることを特徴とした予約販売方法。
【請求項14】請求項1、2、3、6、7、8のいずれかにおいて、ファイルの移動の指示は第1のコンピュータシステムが出すことを特徴とした予約販売方法。
【請求項15】請求項1、2、3、6、7、8のいずれかにおいて、ファイルの移動の指示は第2のコンピュータシステムが出すことを特徴とした予約販売方法。
(中略)
【請求項19】請求項1、2、3、6のいずれかにおいて、ある1つの第2のコンピュータシステムで販売するチケット等の予約・販売対象物がある一定量以下になるか、またはある所定の時間が経過したら、チケット等の予約・販売を受け付けるためのファイルを保有している他の第2のコンピュータシステムを探し、前記の第2のコンピュータシステムに、予約・販売を受け付けるためのファイルを移動させることを特徴とした予約販売方法。
【請求項20】請求項1、2、3、6のいずれかにおいて、ある1つの第2のコンピュータシステムで販売するチケット等の予約・販売対象物がある一定量以下になるか、またはある所定の時間が経過したら、チケット等の予約・販売を受け付けるためのファイルを保有している他の第2のコンピュータシステムを探し、第1のコンピュータシステムに、予約・販売を受け付けるためのファイルを移動させることを特徴とした予約販売方法。
【請求項21】請求項1、2、3、6のいずれかにおいて、ある1つの第2のコンピュータシステムで販売するチケット等の予約・販売対象物がある一定量以下になるか、またはある所定の時間が経過したら、チケット等の予約・販売を受け付けるためのファイルを保有している第1のコンピュータシステムから、前記の第2のコンピュータシステムに、予約・販売を受け付けるためのファイルを移動させることを特徴とした予約販売方法。」(特許請求の範囲の請求項9〜21)

(イ)「【0004】
【課題を解決するための手段】ホストコンピュータで管理している販売に必要なファイル(以下在庫ファイルという)を分割してファイルサーバーに記憶させ、ホストとファイルサーバーはLANで接続する。顧客からの販売の問合せは、端末を用い、ファイルサーバーと端末は公衆回線網で接続する。端末から販売の問合せがあった場合、その端末と接続されているファイルサーバーは、そのファイルがファイルサーバーに格納されていて、かつまだ在庫がある場合は、そこで販売の手続きを終了し、ホストコンピュータにアクセスしない。そうでない場合だけホストコンピュータにアクセスする。これによって、ホストコンピュータへの負荷集中が軽減できる。
【0005】
【作用】列車の指定席券の販売を例にとって説明する。ホストコンピュータには、出発日時、列車名、及びその座席数を記憶した列車ファイル(RF)と座席別に販売状況を記憶した座席ファイル(ZF)がある。販売開始直前にホストコンピュータは、各列車の在庫を(一部分をホストコンピュータに残して)単数または複数のファイルサーバーに、分割してダウンロードする。ダウンロードされたRF、ZFの1つのファイルをそれぞれRF’、ZF’と呼ぶ。ZFには、座席ごとの販売状況(空席または販売済み)または、ファイルサーバーで販売中の場合はダウンロード先のファイルサーバーの番号を記憶させておく。
【0006】端末から販売の問合せがあった場合、その端末と接続されているファイルサーバーは、該当する列車のRF’、ZF’を参照し、在庫があれば、その座席を販売する。在庫がなければ、ホストコンピュータにアクセスする。
【0007】販売開始からある所定の時間が経過、あるいは所定の割合の枚数を販売、あるいは所定時間あたりの売上枚数が一定値以下になった場合は、RF’、ZF’をホストコンピュータにアップロードする。
【0008】また、ホストコンピュータに在庫がなくなれば、売れ残っているファイルサーバーを検索し、アップロードする。このようにして、販売ニーズがあるにもかかわらず、売れ残りが生じる、ということがないようにする。」(段落【0004】〜【0008】)

(ウ)「【0016】次にファイルの分散方法を述べる。販売開始直後には、多数の端末からホストコンピュータ11に負荷が集中するので、販売開始前に、列車ファイルRF(列車ごとの残席数を示すファイル)と座席ファイルZF(座席ごとの販売状況を示すファイル)を分割して、ファイルサーバー1からファイルサーバーnにダウンロードしておく(ホストコンピュータ11にも一部分残しておく)。図2に分割した概要を示す。CPU101、102、103はそれぞれファイルサーバ1、2、3のCPUである。例えば、ひかりA号のRF、ZFをA0、A1、A2、A3、・・・に分割し、A0をホストコンピュータ11の磁気ディスクに残し、A1、A2、A3をそれぞれファイルサーバー1、2、3に分割して、記憶させる。ひかりB号、C号も同様である。
(中略)
【0027】図3にチケットを販売する時の手順を示す。
ステップ301:販売開始前に、ホストで管理しているRF、ZFを(一部分をホストに残して)ファイルサーバーにダウンロードする。
ステップ302:ファイルサーバーは端末からの予約または販売の問合せが発生するのを待つ。発生すれば、ステップ303へ。
ステップ303:操作している端末と接続されたファイルサーバーのファイルにアクセス可であるか否かを判断する。ホストからファイルサーバーにダウンロード中、またはファイルサーバーからホストへアップロード中あるいは、ファイルサーバーで当該ファイルにアクセス中であれば、ファイルサーバーにアクセスできないので、ステップ307へ進みホストで処理する。ファイルサーバーにアクセス可ならステップ304へ。
ステップ304:乗客の希望する列車の在庫がファイルサーバーにあるか否かRF’を調べる。在庫があれば、ステップ305へ、なければステップ307へ。
【0028】ステップ305:ZF’から空席の座席を見つけ、販売する。
ステップ306:RF’の在庫数を減算し、ZF’のフラグを’10’(予約のみで未発券)または’11’(発券済み)にする。
ステップ307:ファイルサーバーで販売できない時、ホストで販売する。
ステップ308:販売のピークは過ぎたか否か、を判断する。判断の方法は何通りか考えられる。例えば、販売開始からある所定の時間が経過、あるいは所定の割合の枚数を販売、あるいは所定時間あたりの売上枚数が一定値以下になった場合、等がある。これらの場合は、ピークを過ぎた、と判断し、ステップ309へ、そうでなければステップ302へ進む。
ステップ309:ZF’、RF’をホストへアップロードし、ホストでZF、RFを更新する。
【0029】ステップ303で、ファイルサーバにアクセス不可の場合、ここでは、「ホストへアクセスする」と述べたが、他にも方法は考えられる。
(1)当該ファイルへのダウンロード等のアクセスが終わるまで、端末からの問合せを待たせる。
(2)1列車を1ファイルとしてZF’を構成すると(ZF’1、ZF’2、・・)、ある列車ファイルへはアクセス不可でも他の列車へは、アクセス可能となる。また、同一ファイルへ2つのトランザクションがアクセスしようとした時でも、該ファイルへのアクセスが可となるまで、1つのトランザクションからの問合せを待たせる。
(3)1列車を1車両ごとに分けて別ファイルとしてZF’を構成し、該ファイルへのアクセスが可となるまで、端末からの問合せを待たせる。または、他の車両のファイルにアクセスする。
【0030】(2)や(3)の場合は、待ち時間は(1)と比べて、極めて小さい。
【0031】図3では省略したが、先に述べたように、ステップ307でホストに在庫がなければ、RFを調べ、稼働中のファイルサーバーにアクセスして、在庫を検索し、販売を行う。稼働中のすべてのファイルサーバーに在庫がなければ、売り切れということになる。」(段落【0016】〜【0031】)

(エ)「【0037】次に、ファイルサーバーの一部に在庫があるにもかかわらず、ホストコンピュータ11に在庫がなくなった時、あるいは在庫がなくなる直前の対処を図6を用いて説明する。
ステップ601:RFのファイルサーバー稼働フラグの中で’1’になっているファイルサーバーを探す。
ステップ602:’1’になっているファイルサーバーがあればステップ603へ進む。しかし、すべてのファイルサーバーが’0’ならば、アップロード済みであるので、ホストコンピュータ11に在庫がなければ、売り切れたことになる。
ステップ603:その中から、販売速度の遅いファイルサーバーを選ぶ。その方法は、(1)売上枚数が最小のもの(2)売上枚数/アサイン枚数が最小のもの、(3)残枚数が最大のもの(4)残枚数/アサイン枚数が最大のもの、等がある。そのために、RF,ZF以外に、列車ごとにホスト、各ファイルサーバーに何枚ずつアサインしたかを記憶させておくファイルを、ダウンロード時に準備しておく。販売速度の遅いファイルサーバーが決まったら、ホストへアップロードさせる。
ステップ604:アップロードしたファイルサーバーのRF’、ZF’を減算し、ホストのRF、ZFを加算する。
【0038】その他、ファイルサーバーへダウンロード後、所定の時間が過ぎれば、ホストコンピュータ11へアップロードさせる、という方法でも良い。
【0039】これによって、ファイルサーバーに在庫があるにもかかわらず、乗客がチケットを購入できない、という不都合を解消する。なお、図1の構成では、ホストコンピュータ11が1台、ファイルサーバーが複数台の例を述べたが、ホストコンピュータが複数台でもよいし、ファイルサーバーが1台でも本実施例は適用可能であることは言うまでもない。」(段落【0037】〜【0039】)

(オ)「【0040】第1の実施例では、ファイルのダウンロード、アップロードの権限は、ホストコンピュータ11にあった。第2の実施例では、ファイルサーバーにその権限を持たせ、ファイルサーバーが上記指示を行うものとする。ファイルの管理の容易性からピーク時以外のファイルの格納場所はホストコンピュータ11とする。ファイルサーバー1、2、・・・nが、権限を持ったRFを、それぞれ列車1、列車2、・・・列車nとする。表5にファイルサーバーの権限とRF名の関係を示す。
(中略)
【0048】図7に本実施例の手順を示す。
ステップ701:販売前に、各ファイルサーバーが権限を持ったファイルをどう分配するのか、ホストコンピュータ11に指示をする。ホストコンピュータ11は、表5を参照し、権限のあるファイルサーバーであるかをチェックした後、各ファイルサーバーからの指示に従って、ダウンロードする。
ステップ702:ファイルサーバーは端末からの予約または販売の問合せの発生を待つ。問合せが発生すれば、ステップ703へ進む。
ステップ703:ファイルサーバーに在庫があれば、ステップ705へ進み、なければ、ステップ704へ進む。
ステップ704:ホストコンピュータ11で予約または販売を受け付ける。
ステップ705:RF’の在庫数を減算する。
ステップ706:ファイルサーバーが有している座席を販売する。
ステップ707:ZF’のフラグを’10’または’11’にする。
ステップ708:各ファイルサーバーには、自分に権限のあるファイルと他のファイルサーバーからアサインしてもらった2種類の性格を持ったファイルを有している。この2種類のファイルともホストコンピュータ11へアップロードする権限は、(表5で示したように)今そのファイルが存在しているファイルサーバーにある、とする。アップロードする(販売を終了する)ならステップ709へ、まだアップロードしない(販売を続ける)ならステップ702へ進む。
ステップ709:ホストコンピュータ11へアップロードして、ファイルサーバーでは、RF’、ZF’を更新し該ファイルサーバーでの販売は終了する。ホストコンピュータ11では、RF、ZFを更新する。
【0049】本実施例では、各ファイルサーバーを有している組織が、他の組織に販売を依頼する量、自分が販売を引き受ける量を決めることができるので、柔軟な販売方法ができる。
【0050】また、ステップ708で、「アップロードする権限は、今そのファイルが存在しているファイルサーバーにある」と述べたが、ファイルサーバーで売れ残っても何の損失もファイルサーバー側になければ、ファイルサーバー側からは、積極的には、アップロードしないことが考えられる。その場合は、各ファイルに対して、アップロードする権限もダウンロードする権限のあるファイルサーバーに持たせればよい。
【0051】そのために、表5、及び表6または表7をホストコンピュータ11だけでなく、各ファイルサーバーにも持たせる。例えば、表5で列車1というRFは、ダウンロードもアップロードもその権限はファイルサーバー1のみに持たせる。この場合、ファイルサーバー1に在庫が少なくなれば、ファイルサーバー1は他のファイルサーバー、ホストコンピュータ11に在庫を問合せる。在庫を参照されたファイルサーバー(及びホストコンピュータ11)は、表5でファイルサーバー1は列車1というRFをアップロード(ホストコンピュータ11に対してはダウンロード)させる権限を持っているファイルサーバーであるか否かをチェックする。権限が有る、と確認できれば、表6または表7で、自分が有している列車1のZFを検索し、在庫数を回答する。または、ZFを検索するかわりに、各ZFの残席数を管理するファイルを用意しておき、その値を回答しても良い。
【0052】ファイルサーバー1は、在庫の多いファイルサーバーにアップロードを指示したり、ホストコンピュータ11にファイルサーバー1にダウンロードするように指示したりする。指示を受けたファイルサーバー及びホストコンピュータ11は、自分が有しているZFをそのファイルサーバーからホストコンピュータ11にアップロードしたり、ホストコンピュータ11からファイルサーバー1にダウンロードしたりする。
【0053】上記の説明では、表5、及び表6または表7をホストコンピュータ11、全ファイルサーバーに記憶させる、と述べたが、表5を分割し、ダウンロードさせる権限を持ったファイルサーバーの表をホストコンピュータ11に、アップロードさせる権限を持ったファイルサーバーの表を全ファイルサーバーに記憶させても良い。表6、表7も分割し、ファイルサーバーに持たせる情報は、自ファイルサーバーが有しているZF名だけに限定しても良い。例えば表5において、ファイルサーバー1に記憶させるZFは、’座席14’、’座席15’、’座席16’、’座席17だけにしてもよい。
【0054】この例では、各ファイルサーバーを有している組織が、他の組織に販売を依頼する量を決めたり、売れ行きを見て、依頼を取りやめて自分で販売をする、と決めることができるので、柔軟な販売方法ができる。」(段落【0040】〜【0054】)

(カ)「【0064】第4の実施例として図9に、図3と図8を組み合わせたフローチャートを示す。(ファイルを動的に移動させる例である。)ステップ801、802、301がホストコンピュータ11側での処理であり、それ以降がファイルサーバー側での処理である。ファイルサーバー側では、図9の処理と並行して、図8のステップ803、804、805、806の処理を行い、RF、ZFのファイルのアンロックを行う。これによって、ステップ303でファイルサーバーのファイルにアクセス可となる。
【0065】第4の実施例では、ファイルのダウンロード、アップロードの権限が、ホストコンピュータ11にあるが、その権限をファイルサーバーに持たせることも可能である。ステップ301で、ステップ701のように、各ファイルサーバーがRF、ZFの分割の仕方を指示し、ホスト側では、ステップ803、804、805、806でファイルをアンロックし、アンロックしたファイルをステップ301の指示に従って、各ファイルサーバーにダウンロードする、という方法がある。
【0066】その他、ステップ301で指示すれば、すぐにファイルサーバーにダウンロードし、ファイルサーバー側でステップ803からステップ806の処理を繰り返して、ファイルをアンロックする、という方法でもよい。
【0067】また、第2の実施例で述べたように、あるファイルに対してアップロードもダウンロードの権限も有るファイルサーバーが、自ファイルサーバー内に在庫が少なくなったり、またはダウンロード後、ある時間が経過すれば、他のファイルサーバーから自ファイルサーバーに在庫ファイルを移動させたり、ホストコンピュータにアップロードさせたり、ホストコンピュータにある在庫ファイルを自ファイルサーバーにダウンロードさせたりすることは、もちろん可能である。
【0068】第3、第4の実施例では、図1の構成を引用したが、ホストコンピュータが複数台あってもよいし、ファイルサーバーが1台でも本実施例は適用可能であることは言うまでもない。
【0069】第3、第4の実施例では、負荷のピークが特定時刻に集中しない、という効果がある。
【0070】第1から第4の実施例では、列車のチケット販売を例にとって説明したが、コンサート、野球場等、在庫が限られていて、販売開始時に申込みが集中するシステムに適用可能であることは言うまでもない。」(段落【0070】〜【0067】)

以上の記載から見て、引用例1には、次のような発明が記載されているものと認められる。

「座席指定又はチケットの予約販売方法であって、ホストコンピュータ11は、LAN12を介して、ファイルサーバ1〜nと接続され、各ファイルサーバ1〜nは、公衆回線10,20,…,30を介して端末1a〜1z;2a〜2z;…;na〜nzと接続されており、
販売開始直前に、ホストコンピュータ11にある列車ファイルRFと座席ファイルZFを分割してファイルサーバ1〜nにダウンロードし、
販売頻度の高い期間中に、或る1つのファイルサーバの在庫が一定量以下となった場合、ホストコンピュータ11が保有する在庫ファイルRF及びZFを前記或る1つのファイルサーバにダウンロードすることにより、前記或る1つのファイルサーバが一定量以上の在庫を持つようにし、
販売頻度の高い期間中に、或る1つのファイルサーバの在庫が一定量以下となった場合、在庫を有する他のファイルサーバを探し出し、他のファイルサーバの在庫ファイルRF’及びZF’を前記或る1つのファイルサーバに移動させ、前記或る1つのファイルサーバが一定量以上の在庫を持つようにし、
販売頻度の高い期間中に、或る1つのファイルサーバの在庫が一定量以下となった場合、在庫を有する他のファイルサーバを探し出し、他のファイルサーバの在庫ファイルRF’及びZF’をホストコンピュータ11に移動させるようにし、、
販売頻度の高い期間中に、ホストコンピュータ11の在庫が一定量以下となった場合、ファイルサーバ1〜nの中から、在庫を有するファイルサーバを探し出し、そのファイルサーバの在庫ファイルRF’及びZF’をホストコンピュータ11に移動させ、ホストコンピュータ11が一定量以上の在庫を持つようにし、
販売開始からある所定の時間が経過し販売ピークを過ぎた場合、所定の枚数を販売した場合、或いは所定時間あたりの売上げ枚数が一定値以下となった場合、各ファイルサーバ1〜nは、在庫ファイル、すなわち列車ファイルRF’及び座席ファイルZF’を、ホストコンピュータ11にアップロードし、これ以後ホストコンピュータ11は、列車ファイルRF、座席ファイルZFを一元管理するようにして、
ホストコンピュータ11及びファイルサーバ1〜n間で座席指定の在庫を適正に分散する予約販売方法。」

(3)対比
本願補正発明と引用例1に記載された発明を対比すると、本願補正発明の「資源」は、引用例1に記載された発明の「座席指定席券」に相当し、本願補正発明の「ホームサーバ」、「サーバ」は、引用例1に記載された発明の「ホストコンピュータ11」、「ファイルサーバ1〜n」に相当することは、明らかである。
そして、引用例1には、ホストコンピュータ11が、座席指定の予約販売等の状況を示す列車ファイルRF’及び座席ファイルZF’を各々有する複数のファイルサーバ1〜nに、LAN12を介して接続され、そして該ホストコンピュータ11は、列車の座席指定席券の予約販売状況を総合的に管理することが記載されている(段落【0004】,【0011】参照。)から、本願補正発明と引用例1に記載された発明とは、
「資源を総合的に管理するホームサーバであって、前記ホームサーバは、各々が資源を有する複数のサーバに接続されている」
点で差異はない。
また、引用例1には、
(i)座席指定の予約販売中に、ホストコンピュータ11の在庫が一定量以下になった場合、在庫ファイルを保有しているファイルサーバを探し出し、該探し出したファイルサーバの在庫ファイルをホストコンピュータ11に移動させ、ホストコンピュータ11の在庫量を一定量以上とすることが記載されており(特許請求の範囲の請求項9、段落【0008】、及び前記(カ)参照。)、
(ii)座席指定の予約販売中に、ホストコンピュータ11の在庫が一定量以下になった場合、在庫ファイルを保有しかつ在庫を有するファイルサーバを探し出し、該探し出したファイルサーバの在庫ファイルをホストコンピュータ11に移動させ、ホストコンピュータ11の在庫量を一定量以上とすることが記載されており(特許請求の範囲の請求項10〜12、及び前記(カ)参照。)、
(iii)座席指定の予約販売中に、複数のファイルサーバ1〜nの中の或るファイルサーバの在庫が一定量以下になった場合、在庫ファイルを保有している他のファイルサーバを探し出し、該探し出した他のファイルサーバの在庫ファイルを前記或るファイルサーバに移動させ、前記或るファイルサーバの在庫量を一定量以上とすることが記載されており(特許請求の範囲の請求項19、及び前記(カ)参照。)、
(iv)座席指定の予約販売実行中に、複数のファイルサーバ1〜nの中の或るファイルサーバの在庫が一定量以下になった場合、在庫ファイルを保有している他のファイルサーバを探し出し、該探し出した他のファイルサーバの在庫ファイルをホストコンピュータ11に移動させることが記載されており(特許請求の範囲の請求項20、及び前記(カ)参照。)、
(v)座席指定の予約販売実行中に、複数のファイルサーバ1〜nの中の或るファイルサーバの在庫が一定量以下になった場合、ホストコンピュータ11が保有する在庫ファイルを前記ファイルサーバに移動させ、前記或るファイルサーバの在庫量を一定量以上とすることが記載されており(特許請求の範囲の請求項21、及び前記(カ)参照。)、
(vi)ホストコンピュータ11及びファイルサーバが有する在庫ファイルに対する移動の指示は、ホストコンピュータ11及びファイルサーバの何れもが出すことができることが記載されている(特許請求の範囲の請求項14,15、及び前記(カ)参照。)。
これらの記載及び引用例1に記載された発明の趣旨に鑑みるに、引用例1に記載された発明は、座席指定の予約販売中に、ホストコンピュータ11がファイルサーバ1〜nの中の1つのファイルサーバから在庫ファイルの移動指示すなわち転送要求を受け取った時(前記(vi)参照。)、要求された座席指定がホストコンピュータ11に有る場合は、ホストコンピュータ11の在庫ファイルを前記1つのファイルサーバへ移動し(前記(v)参照。)、要求された座席指定がホストコンピュータ11にない場合は、ホストコンピュータ11がファイルサーバ1〜nの中の1つ以上のファイルサーバへ不足する座席指定が乗っている在庫ファイルをホストコンピュータ11へ移動するように指示を出し(前記(vi)参照。)、移動指示を受け取ったファイルサーバの在庫ファイルをホストコンピュータ11が受信し、座席指定が登録されている在庫ファイルを集めて前記1つのファイルサーバへ送信する(前記(ii)に示される操作を必要なだけ実行することに相当。)ものである。
そうすると、本願補正発明と引用例1に記載された発明とは、
「前記ホームサーバが、
(1)前記複数サーバ内の1つのサーバから、資源の送信要求を受け取る手段と、
(2)要求された資源以上の資源を前記1つのサーバへ送信する手段と、
(3)前記要求された資源以上の資源がホームサーバにない場合は、ホームサーバが前記複数サーバ内の1つ以上のサーバへ不足資源をホームサーバへ送信するように要求を出し、該要求を受け取ったサーバの有する資源をホームサーバが受信し、資源を集めて前記1つのサーバへ送信する手段」
を有する点で差異はない。
したがって、本願補正発明と引用例1に記載された発明とは、次の点で相違し、その余の点で一致する。
(相違点1)
本願補正発明は、不足資源のホームサーバへの送信要求を受け取ったサーバの有する資源の半分をホームサーバが受信するのに対して、
引用例1に記載された発明は、不足座席指定のホストコンピュータ11への移動指示を受け取ったファイルサーバの有する座席指定が登録されている在庫ファイルをホストコンピュータ11が受信する点。
(相違点2)
本願補正発明が「物の発明」であるのに対して、引用例1に記載された発明は、「方法の発明」である点。

(4)判断
(相違点1について)
先に述べたように、引用例1に記載された発明は、在庫ファイルの移動指示を受けたファイルサーバが、その在庫ファイルRF’及びZF’を、ホストコンピュータ11へ送信するもの、すなわち、移動指示を受けたファイルサーバは、自己が有するすべての在庫を、ホストコンピュータ11へ送信するものである。
然るに、或るサーバの資源が不足しそのサーバが他のサーバへ資源を要求する時、該要求を受けた他のサーバが自己の保有する資源の内どれだけの資源を或るサーバへ送信するかは、単なる設計上の「決め」の問題に過ぎず(例えば、自己の保有する資源の全部、半分、三分の一、又はある一定の量等々が考えられる。)、しかもこのことは当業者が従来より自由に設計しかつ決定していたことである。
したがって、引用例1に記載された発明に於いて、ファイルサーバが自己の保有する在庫(資源)全部を送信していたものを、自己の保有する在庫の半分を送信するようにして、本願補正発明の如く構成することは、当業者が適宜なし得ることである。
(相違点2について)
「物の発明」と「方法の発明」とは、単にカテゴリー名が相違するだけのことであるから、引用例1に記載された発明のカテゴリー名を、「方法の発明」から「物の発明」に変えることは、当業者が適宜なし得ることである。

(5)むすび
以上のとおり、本願補正発明は、特許法第29条第2項の規定により特許出願の際、独立して特許を受けることができるものではなく、特許法第17条の2第5項で準用する同法126条第4項の規定に違反するものであるから、平成14年11月6日付けの手続補正は、平成15年改正前特許法第159条第1項で準用する同法第53条第1項の規定により却下すべきものである。

3.本願発明について
平成14年10月7日付けの手続補正は、前記のとおり却下されるから、本願の特許請求の範囲の請求項1に係る発明(以下、「本願発明」という。)は、平成14年2月13日付けの手続補正書により補正された特許請求の範囲の請求項1に記載された次のとおりのものである。

「【請求項1】資源を総合的に管理するホームサーバであって、前記ホームサーバは、各々が資源を有する複数のサーバに接続されており、前記ホームサーバが、
(1)前記複数サーバ内の1つのサーバから、資源の送信要求を受け取る手段と、
(2)要求された資源以上の資源を前記1つのサーバへ送信する手段と、
(3)前記要求された資源以上の資源がホームサーバにない場合は、ホームサーバが前記複数サーバ内の1つ以上のサーバへ不足資源をホームサーバへ送信するように要求を出し、該要求に対して送信された資源をホームサーバが受信し、資源を集めて前記1つのサーバへ送信する手段と、
を具備することを特徴とする、ホームサーバ。」

(1)引用例
原査定の拒絶理由に引用された引用例、及びその記載事項は、前記「2.(2)」項に記載したとおりである。

(2)対比・判断
本願発明は、前記「2.」項で検討した本願補正発明における「要求を受け取ったサーバの有する資源の半分」からその限定事項である「半分」を省き、「要求に対して送信された資源」としたものである。
そうすると、本願発明を特定する事項をすべて含み、さらに他の特定する事項を付加したものに相当する本願補正発明が、前記「2.(4)」項に記載したとおり、引用例1に記載された発明及び周知技術とに基づいて当業者が容易に発明をすることができたものであるから、本願発明も、同様の理由により、引用例1に記載された発明及び周知技術とに基づいて当業者が容易に発明をすることができたものである。

(3)むすび
以上のとおり、本願発明は、引用例1に記載された発明及び周知技術に基づいて当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。
よって、結論のとおり審決する。
 
審理終結日 2005-03-23 
結審通知日 2005-03-29 
審決日 2005-04-13 
出願番号 特願平10-241559
審決分類 P 1 8・ 121- Z (G06F)
最終処分 不成立  
前審関与審査官 青柳 光代  
特許庁審判長 関川 正志
特許庁審判官 大野 弘
山下 弘綱
発明の名称 複数サーバ間送信数最適化システムおよびその方法  
代理人 市位 嘉宏  
代理人 坂口 博  
代理人 上野 剛史  
  • この表をプリントする

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