(57)【特許請求の範囲】
【請求項１】
各顧客用の端末からの要求に従い、要求された物品を配送するための巡回ルートを決定するサーバであって、
各顧客の所在位置情報を記憶するデータベースと、
該データベースを検索することで物品配送要求を行なった各顧客の所在位置情報を取得し、各顧客への物品の配送のための巡回ルートを決定する巡回ルート決定手段とを有し、
前記巡回ルート決定手段は、
巡回可能範囲である地理的範囲を、複数のブロックに分割し、１以上の顧客が存在するブロックについては当該ブロック内の顧客をまとめることで１つの仮想顧客ブロックを設定する仮想顧客ブロック設定手段と、
一度の巡回ルートを算出可能な拠点数の上限値をＮｍａｘとしたとき、前記仮想顧客ブロック設定手段で設定した仮想顧客ブロックの数が前記Ｎｍａｘを越える場合、前記仮想顧客ブロックの数が前記Ｎｍａｘ以下になるまで、前記ブロックのサイズを大きくするブロックサイズ変更手段と、
前記仮想顧客ブロックの数が前記Ｎｍａｘ以下となった場合、前記仮想顧客ブロック間の距離の総和が最短となる巡回ルートを演算し、且つ、複数の顧客が存在する仮想顧客ブロックについては、当該仮想顧客ブロックの範囲を前記地理的範囲とし、前記仮想顧客ブロック設定手段、前記ブロックサイズ変更手段を再帰的に実行することで、前記物品配送要求を行った顧客の巡回ルートを演算する演算手段とを備える
ことを特徴とするサーバ。
【請求項２】
更に、各顧客用の端末からの要求に従い、要求された使用済み物品の回収要求を受信する受信手段を備え、
前記巡回ルート決定手段は、巡回ルートの距離が短い順に複数の巡回ルートの候補を決定し、
前記巡回ルート決定手段は、前記巡回ルートの距離が短い順に、物品の配送と回収によって、運送車の許容量を越える拠点があるルートを除外し、運送車の許容量を超えないで巡回可能なルートを、最終の巡回ルートして決定することを特徴とする請求項１に記載のサーバ。
【請求項３】
更に、前記巡回ルート決定手段で決定した巡回ルートを、前記配送車を運営する端末に、メールとして送信する送信手段を備えることを特徴とする請求項１又は２に記載のサーバ。
【請求項４】
前記巡回ルート決定手段は、（Ａ）物品配送要求を受信してから予め設定された日数が経過した、（Ｂ）配送要求された物品の個数が予め設定された個数以上になった、の条件（Ａ），（Ｂ）のいずれかの一方の条件を満たす場合に、巡回ルートを決定する処理を実行することを特徴とする請求項１乃至３のいずれか１項に記載のサーバ。
【請求項５】
各顧客の所在位置情報を記憶するデータベースを有し、各顧客用の端末からの要求に従い、要求された物品を配送するための巡回ルートを決定するサーバの制御方法であって、
該データベースを検索することで物品配送要求を行なった各顧客の所在位置情報を取得し、各顧客への物品の配送のための巡回ルートを決定する巡回ルート決定工程とを有し、
前記巡回ルート決定工程は、
巡回可能範囲である地理的範囲を、複数のブロックに分割し、１以上の顧客が存在するブロックについては当該ブロック内の顧客をまとめることで１つの仮想顧客ブロックを設定する仮想顧客ブロック設定工程と、
一度の巡回ルートを算出可能な拠点数の上限値をＮｍａｘとしたとき、前記仮想顧客ブロック設定工程で設定した仮想顧客ブロックの数が前記Ｎｍａｘを越える場合、前記仮想顧客ブロックの数が前記Ｎｍａｘ以下になるまで、前記ブロックのサイズを大きくするブロックサイズ変更工程と、
前記仮想顧客ブロックの数が前記Ｎｍａｘ以下となった場合、前記仮想顧客ブロック間の距離の総和が最短となる巡回ルートを演算し、且つ、複数の顧客が存在する仮想顧客ブロックについては、当該仮想顧客ブロックの範囲を前記地理的範囲とし、前記仮想顧客ブロック設定工程、前記ブロックサイズ変更工程を再帰的に実行することで、前記物品配送要求を行った顧客の巡回ルートを演算する演算工程とを備える
ことを特徴とするサーバの制御方法。
【請求項６】
コンピュータに読込ませ実行させることで、前記コンピュータを、請求項１乃至４のいずれか１項に記載のサーバとして機能させることを特徴とするコンピュータプログラム。
【請求項７】
請求項６に記載のコンピュータプログラムを格納したことを特徴とするコンピュータ可読記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、複数の顧客への物品配送の技術に関するものである。
【０００２】
【従来の技術】
近年のＯＡ機器、特に、印刷機能を有する装置では電子写真方式を利用するものが多い。例えば、複写機、プリンタ、ＦＡＸ等が挙げられる。
【０００３】
通常、これらのＯＡ機器では、メンテナンスの容易さ及び高い印刷品質を維持するため、記録材であるトナーと感光ドラムを一体にしたトナーカートリッジを採用してきている。
【０００４】
また、トナーカートリッジを回収してリサイクルすることで、省資源及び省エネに寄与することも行われている。
【０００５】
一方で、顧客からはトナーカートリッジの納品依頼があると、要求されたカートリッジを納品作業も行われている。
【０００６】
【発明が解決しようとする課題】
販売会社にしれみれば、顧客先に顧客からの注文されたカートリッジを納品する場合、或いは、回収する場合には、運送と手間ひまの関係からも、その数がある程度まとまったものであることが望まれる。
【０００７】
一方、顧客にとっては、たとえ１本のカートリッジであっても納品してほしいし、回収してほしいものであると言える。
【０００８】
そこで、複数の顧客からの依頼を受けつけ、それらを巡回することでかかる問題点が解決できるが、いくつも顧客を訪問することになるので、自然、訪問する時刻は当初予定した時刻と食い違ってくることが往々にしてある。
【０００９】
本発明は、かかる問題点に鑑みなされたものであり、一度の巡回によって複数の顧客に対して納品を行うことで、小口の依頼に対しても十分に応えることができ、且つ、単純な構成でもって、物品の配送先を巡る効率の良いルートを見つけ出す技術を提供しようとするものである。また、第２には、使用済みの物品の回収も併せて行ない、配送車の許容量を超えないルートを見つけ出す技術を提供しようとするものである。
【００１０】
【課題を解決するための手段】
上記課題を解決するため、例えば本発明のサーバは以下の構成を備える。すな
わち、
各顧客用の端末からの要求に従い、要求された物品を配送するための巡回ルートを決定するサーバであって、
各顧客の所在位置情報を記憶するデータベースと、
該データベースを検索することで物品配送要求を行なった各顧客の所在位置情報を取得し、各顧客への物品の配送のための巡回ルートを決定する巡回ルート決定手段とを有し、
前記巡回ルート決定手段は、
巡回可能範囲である地理的範囲を、複数のブロックに分割し、１以上の顧客が存在するブロックについては当該ブロック内の顧客をまとめることで１つの仮想顧客ブロックを設定する仮想顧客ブロック設定手段と、
一度の巡回ルートを算出可能な拠点数の上限値をＮｍａｘとしたとき、前記仮想顧客ブロック設定手段で設定した仮想顧客ブロックの数が前記Ｎｍａｘを越える場合、前記仮想顧客ブロックの数が前記Ｎｍａｘ以下になるまで、前記ブロックのサイズを大きくするブロックサイズ変更手段と、
前記仮想顧客ブロックの数が前記Ｎｍａｘ以下となった場合、前記仮想顧客ブロック間の距離の総和が最短となる巡回ルートを演算し、且つ、複数の顧客が存在する仮想顧客ブロックについては、当該仮想顧客ブロックの範囲を前記地理的範囲とし、前記仮想顧客ブロック設定手段、前記ブロックサイズ変更手段を再帰的に実行することで、前記物品配送要求を行った顧客の巡回ルートを演算する演算手段とを備える。
【００１１】
【発明の実施の形態】
以下、添付図面に従って本発明にかかる実施形態を詳細に説明する。実施形態における発注／回収の対象物として、ＯＡ機器（複写機、プリンタ、ＦＡＸ等）で使用されるトナーカートリッジ（以下、単にカートリッジという）を例に説明する。
【００１２】
＜概要の説明＞
図１は、実施形態におけるシステム全体の構成図を示している。図示において、１００乃至１０２は顧客に設置された端末（以下、顧客端末という）、２００は発注／回収の運用を行うサーバ（Ｗｅｂサーバを兼ねている）、３００は運送会社に設置された端末（以下、運送会社端末という）である。顧客端末１００乃至１０２、サーバ２００、運送会社端末３００はインターネットに接続しブラウズする機能及びメール機能を備えていれば如何なるものでも良く、一般にはパーソナルコンピュータやワークステーションで構成することになる。
【００１３】
上記構成において、各顧客は自身の端末を操作して、サーバ２００にブラウザを使用してアクセスし、ユーザ登録（顧客名、住所、Ｅメールアドレスの登録、使用しているＯＡ機器の種類）を行う。サーバ２００は、登録がなされたユーザーに対してＩＤを発行する（実施形態ではＷｅｂ上で通知しても良するものとするが、メールで通知しても良い）。
【００１４】
この後、各ユーザは、割り当てられたＩＤでサーバ２００にアクセスし、使用済みカートリッジの回収依頼、或いは／及びカートリッジの発注依頼を行うことになる。
【００１５】
サーバ２００は、各ユーザからの上記依頼を受けて、新品カートリッジの受注と配送、さらには、使用済みカートリッジの回収にかかるスケジュール（巡回ルート）を決定し、それを運送会社端末３００に通知する。この通知はメールで行われる。
【００１６】
運送会社では、この通知を受け、新品カートリッジの積載を行い（もし在れば）、その通知スケジュールに従って納品と回収を行うことになる。回収されたカートリッジは所定の倉庫に配送するものとする。
【００１７】
＜ユーザ登録と発注／回収依頼の説明＞
図２は実施形態における顧客端末でサーバ２００にアクセスし、初期メニュー（トップホームページ）上で新規ユーザ登録を指示（クリック）した際に表示される画面を示している。
【００１８】
図示に示す如く、顧客名（会社名等）、メールアドレス、住所、電話番号、さらには、使用しているＯＡ機器を入力する欄で構成されている。ＯＡ機器の入力は、例えばコンボボックス形式で、予め用意されたテーブルの中から該当するものを選択することで行い、その他の名称やメールアドレスは直接キーボード等で入力するものとする。
【００１９】
かかる入力を終え、ユーザが「登録」ボタンをクリックすることで、ユーザ登録が完了する。ユーザ登録が完了すると、サーバ２００は、図３に示すページを作成し、登録依頼したユーザに対してＩＤを通知する。
【００２０】
なお、サーバ２００は、ユーザ登録があったとき、住所欄に入力された住所をキーにして、マップＤＢを参照することで管轄地位域内での座標位置（ｘ、ｙ）を検索し、その座標位置データもその顧客ＩＤに関連付けて登録する（詳細は後述）。
【００２１】
サーバ２００における構成の詳細は後述するが、機種データベース（以下、単にＤＢと記す）及びユーザＤＢが設けられている。機種ＤＢは例えば図４に示すように、カートリッジを用いるＯＡ機器の機種名、使用するカートリッジ機種名、そして、サイズである（サイズについての詳細は後述する）。ユーザ登録の際の機種名を登録する場合には、この機種ＤＢを参照して、その一覧をコンボボックスに表示させ、その中から選択させるようになる。なお、図示の機種名「複写機Ａ０００１」はカートリッジが４種類あることを示している。これは同機種がカラー複写機であり、シアン（Ｃ）、マゼンタ（Ｍ）、イエロー（Ｙ）、ブラック（Ｂｋ）の４種類を搭載することが可能であることを示している。モノクロプリンタ等の場合、通常は黒トナーカートリッジの１種類のみということになる。
【００２２】
一方、ユーザＤＢは、図５に示すような構造を成し、図２で登録した情報以外に、ユーザＩＤ、ユーザの所在位置（座標位置）を記憶する領域が設けられている。ユーザ所在地は、入力された住所（番地を含む）に基づき、実施形態における運営会社（販売店等）のサービスする管轄区域内における座標を、サーバ２００が別途計算し、それを登録するものである（その理由は後述する）。
【００２３】
＜サーバの構成とその処理概要＞
図６に実施形態におけるサーバ２００の構成図を示す。サーバ２００は、装置全体の制御を司るＣＰＵ２０１、ＢＩＯＳやブートプログラムを記憶しているＲＯＭ２０２、ＯＳや動作処理プログラムをロードしたり、ワークエリアとして使用するＲＡＭ２０３をはじめ以下の構成を備える。
【００２４】
ハードディスク２０４には、ＯＳや実施形態のサーバ２００がサーバとして動作するプログラム以外に、先に図５を用いて説明したユーザＤＢ２０４ａ、図４を用いて説明した機種ＤＢ２０４ｂ、後述する巡回リスト作成領域２０４ｃ、マップＤＢ２０４ｄ、依頼ＤＢ２０４ｅ、巡回ルートテーブル２０４ｆが存在する。
【００２５】
２０５はインターネットとの接続を行うためのネットワークインターフェースである。２０６はキーボード、マウス等の入力装置である。２０７は表示制御部であり、不図示のビデオＲＡＭを内蔵し画像の表示の制御を司る共にビデオＲＡＭに展開されたイメージデータをビデオ信号として表示装置２０８へ出力するものである。
【００２６】
なお、上記のうち、マップＤＢは、例えば図２１に示すような構造をなしている。すなわち、住所（丁目、番地を含む）に対応する、装置が管理しやすい座標データが対になって格納されている。
【００２７】
サーバ２００のハードウェアとしての構成は概ね上記の通りであるが、以下、その動作概要について説明する。
【００２８】
サーバ２００のメインとなる処理は大きく分けると、各登録ユーザ（顧客端末）からカートリッジの注文及び使用済みカートリッジの回収の依頼受け処理、運送車の巡回ルートの決定処理、決定した巡回ルートの運送会社端末３００への通知処理、運送車の作業員による納品・回収に伴うデータ収集処理、さらには、顧客への現在の状況通知処理がある。以下、各処理について説明する。
【００２９】
・［依頼受け処理］
ユーザ登録を行った顧客は、自身の端末を操作してサーバ２００のトップホームページで、注文・回収依頼ボタン（不図示）をクリックし、ユーザＩＤを入力することで、カートリッジの注文及び回収の依頼を受けることができる。
【００３０】
図７はサーバ２００がユーザに送信するページの例を示している。ユーザは先ずＩＤを入力することで、自身の名称が表示されていることを確認できるようになっている。また、ユーザはカートリッジの注文と、回収とをそれぞれ設定できるが、設定する機種名としては機種ＤＢに登録された全ての中から選択するのではなく、ユーザ登録時に設定した機種の中から探し出すようにした。
【００３１】
図示の場合、「注文」では、機種名として「複写機Ａ００１」が指定されているが、その機種名の右側の▽をクリックすると、ユーザＤＢの中のそのユーザＩＤで示されるレコードから、登録使用機種が一覧が表示されるようになっている。
【００３２】
機種名が入力されると、その機種名をキーとして機種ＤＢを参照することで、使用できるカートリッジ名が判明するので、その中の１つをデフォルトのカートリッジ名として図示の「カートリッジ名」に表示させる。例えば、機種名「複写機Ａ００１」は、図４を参照すると、カラー複写機であるので、先頭のカートリッジ名「カートリッジＣＴ００１Ｂｋ」を表示する。ユーザーは、この画面を見て、カートリッジ名を、機種名選択と同様、▽をクリックすることで他のものにすることができる。なお、機種名「プリンタＰ０２０」については使用できるカートリッジ名は１種類しか存在しないので、図示の如く、カートリッジ名を選択するための「▽」は操作不能状態を示すように表示させている。あとは、この注文する本数をキーボードより入力するだけである。なお、注文するカートリッジの種類が多数になることもあるので、図示の如く、スクロールバー７０を付加するようにした。
【００３３】
一方、「回収」についての入力方法は、「注文」と同じであり、機種名、カートリッジ名、本数を入力する。また、必要に応じてスクロールバー７１を操作して、多数設定できるのも「注文」と同様である。なお、注文のみ、或いは回収のみであっても良いのは勿論であるし、注文用のページと、回収用のページとを独立させるようにしてもよい。
【００３４】
こうして、ユーザは「送信」ボタン７２をクリックすることで、設定内容がサーバ２００に通知（送信）されることになる。なお、「キャンセル」ボタン７３をクリックすると、ログイン画面（トップホームページ）に戻ることになる。
【００３５】
さて、「送信」ボタン７２がクリックされ、その設定内容がサーバ２００に通知されると、サーバ２００は、依頼ＤＢ２０４ｅに依頼されたデータを登録し、その受付標（受け付け番号とその受け付け番号を示すバーコードイメージ付き）を作成して保存すると共に、その保存した受付標の所在を示すＵＲＬを有する受け付けが完了した旨の画面を表示する。
【００３６】
図８は依頼ＤＢ２０４ｅの内容を示している。図示の如く、回収、発注はそれぞれ１つの依頼として受け付け、受付番号としてユーザＩＤにそのユーザの依頼した数を組み合わせて受付番号を作成する。また、発注と回収の違いは、図示の「種類」で特定し、受け付けた日付も記憶する。また、この時点では、この依頼に対しては作業が完了していないので、図示の如く状態を「未完」にして作成する。
【００３７】
また、受付完了を示す画面は図９に示すようなものである。同図（ａ）は回収依頼のあった場合に表示されるメッセージを示し、同図（ｂ）は注文があった場合のメッセージであり、いずれも受け付け標の所在を示すＵＲＬが記述されている。なお、回収・注文の両方ともあった場合には、２つのメッセージを接続して表示する（ただし、２つ目の先頭の宛て名は除外する）。
【００３８】
ユーザはこのメッセージを見て、表示されたＵＲＬをクリックして、受け付け標を入手することになるが、そのイメージは例えば図１０に示すようなものである。同図（ａ）は回収依頼の受付標を示し、同図（ｂ）は注文受付標を示すものであり、いずれにも内部にバーコード（受付番号）が含まれるものである。
【００３９】
ここで、ユーザーはメッセージに沿ってそれぞれの受付標を印刷することになるが、回収標についてはその印刷結果を回収させたいカートリッジに張り付けておく。また、注文受付標については、実際に納品に来た者に手渡す等の作業のために保管しておいてもらう。
【００４０】
詳細は後述するが、後述する運送車の巡回ルートの決定が行われると、ユーザーに対する納品、回収の日程が別途メールで通知される。メールの内容は、例えば図１１（ａ）、（ｂ）に示す通りである。同図（ａ）は回収日程通知メールの一例であり、同図（ｂ）は納品（配送）の日程通知メールの一例を示している。
【００４１】
・［運送車の作業員による納品・回収に伴うデータ収集処理］
次に、運送車の作業員による納品・回収に伴うデータ収集処理について説明する。
【００４２】
サーバ２００は後述する運送車の巡回ルートの決定が行われると、運送会社宛に巡回ルートのスケジュールを示すメールを送信する。図１２はこのメールの内容を示している。
【００４３】
運送会社では、このメールを受け、注文品の積載した後、各顧客への巡回と納品及び／又は回収を繰り返し、最終的に回収されたカートリッジを所定の倉庫に搬送する作業を行うことになる。
【００４４】
各顧客には、注文受付標或いは／及び、使用済カートリッジに添付されている回収受付標が存在することになる。従って、少なくとも回収する場合には、どれが回収すべきものであるのかが一目瞭然となり、一々顧客に確かめる必要もなくなり、作業がスムースに行われる。いずれにしても、作業者（運送車の運転手及び／又は助手）は、携帯バーコードリーダで受け付け標のバーコードを読み取り、読み取ったバーコードのデータ（受付番号）をサーバ２００に通知することで、その顧客に対する納品及び／或いは回収が完了したことを通知する。これを受け、依頼ＤＢ内の該当するデータの「状態」を「完了」とし、削除する対象として設定する。
【００４５】
・［顧客への現在の状況通知処理］
図１３は、後述する運送車の巡回ルートの決定処理を行った際に作成される巡回ルートテーブル２０４ｆの内容を示している。この巡回ルート決定処理を行うことで、各顧客の巡回順が決定され、その距離に応じた移動時間及び訪問して納品／回収に係る作業時間を加算することで、顧客間の移動時間が決定される。
【００４６】
また、最初に、未使用カートリッジを倉庫で積載することが必要になるので、図示の場合の先頭には９：００に積載完了予定時刻を設定し、これ以降は移動距離と作業時間を加算することで、各訪問する顧客の時刻を類推する。この類推時刻が、先に説明したメールで通知される予定時刻である。なお、倉庫での積載が未完のときは、図示の初回予定時刻と実予定時刻は同じとなる。
【００４７】
また、巡回番号が“１”と“２”の間での時間差がないのは、これらは同一顧客先であり、一方が注文品の納品を示し、もう一方が回収のためである（上６桁が顧客ＩＤであり、図示の場合に同じであることがその理由である）。
【００４８】
さて、実際に、倉庫に到着し、未使用カートリッジを搭載すると、作業者はサーバ２００にその旨を通知する。このときの通知は、未使用カートリッジ搭載を示す予め用意されたバーコードを読み取ることで行われる（車に搭載しておく）。図示の場合、現実には９時１５分に積載が完了し、巡回番号“１”に向けて移動したことが示されている。この通知をサーバ２００が受けると、予定時刻に対して１５分遅れたことがわかるので、「実予定時刻」に「９時１５」を書き入れ、尚且つ、作業完了を示すフラグを「済」に設定し、依頼ＤＢ２０４ｅ内の該当する「状態」を完了に設定する。そして、それ以降の訪問先の時刻を「初回予定時刻」を元に類推し、「実予定時刻」を更新する。図示の場合、受付番号１２３５５５−１０、１２３５５５−１１に対する作業が完了したのが９：４４分であったので、この完了フラグも「済」に設定する。この結果、それ以降の巡回番号３以降の実予定時刻を、初回予定時刻を元に再度更新する。
【００４９】
つまり、顧客を訪問し、納品／回収が済むみ、先に説明したバーコードを読み取り、その結果をサーバ２００に通知する度に、その作業に係る「完了フラグ」を「済」にし、それに従い、それ以降に訪問する先の「実予定時刻」を更新していく。
【００５０】
この結果、運送当日の交通の状況が反映された、より確からしい時刻に随時更新することが可能となる。
【００５１】
登録ユーザは自端末を操作し、初期画面上で配送／回収予定時刻（不図示）をクリックし、ユーザＩＤを入力すると、その時の最新の予定時刻（実予定時刻）が表示される。
【００５２】
例えば、図１３の状態で、受付番号１２３４５６−１０の依頼をしたユーザ（実施形態では○×△株式会社）の表示画面は、図１４に示すようなものとなる。
【００５３】
なお、上記例では、顧客が積極的にサーバ２００にアクセスして時刻を問い合わせる例を示したが、サーバ２００が逐一顧客宛にメールを配送するようにしても良い。
【００５４】
＜サーバ２００における処理手順に説明＞
以上説明したサーバ２００における発注・回収受付にはじまる動作処理手順（サーバ２００で動作しているプログラム）を図１５、図１６のフローチャートに従って説明する。
【００５５】
先ず、サーバ２００におけるメイン処理を図１５に従って説明する。
【００５６】
ステップＳ１ではインターネットからのアクセスを待つ。アクセスがあったと判断した場合には、トップホームページを依頼元に送信する。実施形態でのサーバ２００は、クライアントから見るとＷｅｂサーバとして機能することになるので、この送信はｈｔｔｐプロトコルに従って送信することになる。ステップＳ１の結果、依頼元の端末（図１における端末１００乃至１０２等）の表示画面には、サーバ２００のトップホームページ（不図示）が表示されることになる。
【００５７】
クライアントはその表示されたページ中のユーザ登録、配送／回収予定時刻、発注／回収依頼等のボタンをクリックし、それぞれのページを表示させることになる。
【００５８】
ステップＳ３では、このクライアントによる操作内容を判断する。ユーザ登録であれば、図２に示すようなページを送信し、クライアントが「登録」ボタンをクリックした際に送信されてくるデータに基づき、ユーザＩＤの発行を行い、ユーザＤＢ２０４ａに登録し、その確認事項として図３に示すようなページをそのクライアントに向けて送信する。
【００５９】
また、配送／回収予定時刻の問い合わせの場合には、ステップＳ５に進み、そのユーザに対応する配送時刻を図１３のテーブル中の「実予定時刻」から探し出し、それを図１４のようなページとして送信し、ユーザの端末に表示させる。
【００６０】
なお、配送／回収予定時刻の問い合わせがあった場合、ユーザＩＤ及びパスワードを入力するページを表示させ、その認証できた場合にステップＳ５の処理を行うのは勿論である。
【００６１】
一方、発注／回収依頼であったと判断した場合、ステップＳ６に進み、先ず、ステップＳ５と同様の認証処理を行い、それがパスした場合に、図７に示すページを送信し、発注／回収のページをユーザ端末に表示させる。ユーザはここで必要とするカートリッジの注文及び回収に関するデータを入力し、「送信」ボタンをクリックすることになる。この結果、入力したデータが送られてくるので、ステップＳ７からステップＳ８に進み、依頼のあったデータに基づき依頼ＤＢ２０４ｅへ登録すると共に、ステップＳ９で受付標（図１０参照）の作成・保存を行った後、ステップＳ１０で受け付け完了を知らせるページ（図９参照）を送信する。
【００６２】
発注／回収依頼でもないと判断した場合には、ステップＳ１１に進み、対応する処理を行う。ステップＳ１１の詳述はしないが、例えばユーザが所有しているＯＡ機器の追加／削除等の処理がこれに含まれる。
【００６３】
以上は、Ｗｅｂサーバ兼の処理であったが、次に、サーバ２００における定時処理を図１６に従って説明する。この処理は、主に、予め設定した時刻になると起動する、或いは運営会社の操作者の指示により起動するものであり、注文されたカートリッジ及び回収依頼のあったカートリッジの締めと、巡回ルートの決定処理及びその通知を行うためのものである。処理内容は以下の通りである。
【００６４】
先ず、ステップＳ２１において、依頼ＤＢをサーチし、最古の未処理の依頼がいつであるか、及び、注文されたカートリッジのボリューム（ほぼ個数に比例する値）、回収依頼されたカートリッジのボリュームを抽出する。そして、ステップＳ２２で、予め設定されたＮ日（例えば７日）より前のものがあるか否か、運送会社に依頼し得る程度のボリュームがあるか否かを判断する。そして、依頼日がＮ日より前である場合、或いは、ボリュームが設定値を越える場合には、無条件にステップＳ２４に進むが、いずれの条件を満たさない場合には、これ以上の処理は行わない。
【００６５】
ステップＳ２４では、依頼ＤＢ２０４ｅ及びユーザＤＢ２０４ａに基づいて巡回ルートを決定する処理を行う（詳細は後述）。
【００６６】
巡回ルートが決定されると、ステップＳ２５に進み、運送会社の端末３００に向けて決定された巡回ルートのリストをメールで通知すると共に、ステップＳ２６で、巡回ルートテーブルに登録する。次いで、ステップＳ２７に進んで、各依頼元毎に、納品或いは／及び回収の日時を示すメールを送信する。
【００６７】
次に、運送車の巡回中のサーバ２００の動作処理手順を図１９に従い説明する。
【００６８】
顧客先においてカートリッジの納品及び／或いは回収を行った際に、図１０に示すような発注受付標や回収受付標に印刷されたバーコードを運送作業者が専用端末で読み取り、それをサーバ２００に通知することは既に説明した。図１９の処理はこの通知を受けた際のサーバ２０の処理手順を示している。なお、運送車には、例えばバーコードリーダ及び携帯電話（ＰＨＳを含む）を接続する端末（携帯パーソナルコンピュータ等）が設けられおり、これにより無線でサーバ２００に通知される。通知径路はインターネットでもよいが、サーバ２００に対して直接ダイヤルアップ接続するようにしても構わない。むしろ、後者の方が不特定多数から着呼を防ぐことができるので、望ましい。
【００６９】
さて、ステップＳ３１では、運送車からの連絡があるのを待つ。連絡があると、ステップＳ３２に進み、受付番号（バーコードで読み取った情報）を受信し、ステップＳ３３で依頼ＤＢ内の該当する依頼データの状態を「完了」に変更する（図８参照）。また、ステップＳ３４では、巡回ルートテーブル（図１３参照）の該当する受付番号の実予定時間の欄に、受信した時刻（もしくは作業者がバーコードを読み取った時刻を転送してもらい、その時刻としても良い）を書き換えるとともに、完了フラグを「済」に設定する。更に、それ以降に巡回することになっている受付番号に「実予定時刻」を、「初回予定時刻」の相対時間を加算することで、未巡回の顧客に対する「実予定時刻」を書き換える。これによって、巡回ルートテーブル２０４ｆの更新を完了し、次の連絡を待つ。
【００７０】
なお、依頼ＤＢ２０４ｅ内の状態が「完了」となっているデータの削除は、上記の図１６と同様適当な時期或いは運営会社の操作者の指示によって行われるものとし、その説明は省略する。
【００７１】
実施形態のサーバ２００の処理内容は以上であるが、次に、巡回ルートの決定処理（図１６におけるＳ２４）の詳細を説明する。
【００７２】
＜巡回ルートの決定処理＞
実施形態での巡回ルートを決定する条件は以下の２つがある。
１つ目：運送車の走向距離ができるだけ短くする。
２つ目：荷物（実施形態の場合にはカートリッジ）の積み下ろしに無理が生じないようにする。
【００７３】
これら２つの条件は、巡回にかかる時間短縮、燃料費の節約、作業員の負担の軽減に寄与するものとなるのは容易に理解できよう。
【００７４】
なお、顧客間の距離は、現実の道路に沿ったものとすることが望ましいが、実施形態では簡単なものとしたいため、顧客間を直線で結ぶ線分の長さで表し、その距離に所定係数を乗ずることで運送車の移動時間を決定した。
【００７５】
今、運送車が３箇所の顧客先Ａ，Ｂ，Ｃを巡回することを考察する。出発点は、カートリッジの積載する倉庫とする。これを示すのが図１８である。
【００７６】
なお、図示において、「注：」は未使用カートリッジの注文ボリューム（ここではカートリッジの個数と考える）、「回：」は使用済みカートリッジのボリューム（同）である。
【００７７】
従って、顧客Ａは、６０本の未使用カートリッジを注文し、使用済みカートリッジ２０本の回収依頼がなされていることを示している。また、顧客Ａに対する「−４０」とは、運送車に対する積載量が増えるか減るかの度合を示している。つまり、顧客Ａの場合、注文が６０本であり、回収が２０本であるので、この顧客Ａを巡回したとき、差し引き４０本分の空きスペースができることを意味する。
【００７８】
今、運送車の許容積載（ボリューム）量（本数）が１００とする。図示の場合、顧客Ａ，Ｂ，Ｃが注文しているカートリッジの合計本数もちょうど１００（＝６０＋１５＋２５）であるので、運送車は、倉庫でカートリッジを実質的に満載することになる。
【００７９】
単純には３箇所を巡回する場合の取り得るルートは３！（階乗）＝３×２×１＝６通り存在する。実施形態では、その中の最適解（もしくは準最適解）を求めるのに上記２つの条件を加味する。
【００８０】
さて、図１８の状態において、顧客Ｃに最初に巡回するわけにはいかない。なぜなら、顧客Ｃを訪問した際には（既に満載状態）、図示の如く積載量が現状より＋５と増え、許容積載量を越えてしまうからである。顧客Ｂに対しても同様である。
【００８１】
一方、顧客Ａを最初に巡回すると、積載量が−４０となり、空きスペースが発生する。この後、２番目の巡回先としては顧客Ｂ、Ｃの何れであっても積み下ろしには問題は発生しない。従って、あとは、巡回する際の距離が一番短いルートで回れば良いことになる。
【００８２】
なお、カートリッジのサイズは様々なものであり、一律的なものではない。それ故、実際には、各カートリッジのサイズにその本数を乗算した結果で判断することが望まれる。このため、先に説明したように、機種ＤＢ２０４ｂには、図４に示し如く、カートリッジの種別毎にサイズを示すデータを持たせた。図４の場合には、プリンタＰ０２０のカートリッジをサイズを「１」とした場合の、各カートリッジの相対的なサイズを示している。実際の積載量は、これに適当な係数を乗算することで現実の体積になるようにする。先に示したボリュームの真意はこれを意味する。
【００８３】
上記は顧客数が３つの場合であったが、例えば巡回する顧客先が５０箇所になると取り得るルートは５０！（＝５０×４９×４８×…×１）≒３×１０64と途方もない数になり、顧客先が１００箇所にもなると今現在の最速コンピュータをもってしても解くことはできない量になる。そこで、実施形態では次のようにして巡回ルートを決定した。
【００８４】
説明を簡単にするため、巡回ルート（並べ替え）を決定するための最大データ数が１０個までは無理のない時間内で演算できるコンピュータがあるとする。また、巡回先の顧客数がＡ〜Ｔの２０箇所あるとする。また、先に説明したように、実施形態では、運営会社の管轄する区域における各顧客の位置は座標データとしてユーザＤＢ２０４ａで既に保持している。図１９（ａ）は、これを座標に従ってプロットして示した例を示している。
【００８５】
顧客数が「２０」であり、それはコンピュータの処理能力「１０」を上まわるので、このままでは最短ルートを探し出すことはできない。
【００８６】
そこで、同図（ａ）を適当なサイズのブロックで分割する。例えば、同図（ａ）を縦３、横４のブロックに分割すると、同図（ｂ）のようになる。
【００８７】
ここで、各ブロックに含まれる１つ乃至複数の顧客を仮想的な１つの顧客（以下、仮想顧客）と見立てる。例えば、同図（ｂ）において、左上隅のブロックには顧客Ｇ，Ｈ，Ｏが含まれるので、これを１つの仮想顧客Ｘ１と見立てる。仮想顧客Ｘ１は例えば該当するブロックの中心に位置していると仮定する（実顧客の座標位置の重心位置としても良い）。同様に他の顧客が存在するブロックについて同様に仮想顧客と見立てると、図示の如く、９つの顧客Ｘ１乃至Ｘ９が設定できることになる。ここでコンピュータ（サーバ２００）は１０個のデータに対する処理能力を有するものとしているわけであるから、この仮想顧客Ｘ１乃至Ｘ９についての最短となる巡回ルートは算出できることになる。
【００８８】
そして、最短巡回ルートの算出する際に、もう１つの条件を加味する。例えば、仮想顧客Ｘ１内の現実の顧客Ｇの注文ボリュームと回収ボリュームをそれぞれＶGT、ＶGKとし、顧客Ｈ，Ｏについても同様にＶHT、ＶHK、ＶOT、ＶOKを定義すると、仮想顧客Ｘ１における納品ボリュームＶX1T、回収ボリュームＶX1Kは、
ＶX1T＝ＶGT＋ＶHT＋ＶOT
ＶX1K＝ＶGK＋ＶHK＋ＶOK
となる。すなわち、仮想顧客Ｘ１を巡回した際、運送車の増加する積載量はＶX1K−ＶX1Tとして算出できる。
【００８９】
従って、巡回の際に増加する積載量に無理が無い、最短ルートを探せば良いことになる。
【００９０】
要するに、最短巡回ルートとして、未使用カートリッジを積載する倉庫をＹ１、使用済み倉庫をＹ２（Ｙ１、Ｙ２の座標位置は予め登録しておくもので、Ｙ１＝Ｙ２でも構わないし、別でも構わない）とすると、
Ｙ１→Ｘ７→Ｘ４→  …  →Ｘ９→Ｙ２（最短ルートである第１候補）
Ｙ１→Ｘ７→Ｘ８→  …  →Ｘ９→Ｙ２（第２候補）
：                                ：
を探し出した後、最初の候補ルート（最短ルート）で納品／回収を行った際に、積載量が運送車の許容量を越えるタイミングがある場合には、そのルートを除外し、次の２番目の候補巡回ルートについて調べていくことを繰り返していき、最初に見つかった巡回ルートを解とすることで対処した。
【００９１】
なお、仮想顧客に対する巡回ルートが決定されると、今度は各ブロック内での最短ルートを同様の手順で行うことになる（２つ以上の場合）。もし、そのブロック内に許容数を越える顧客が存在する場合には、そのブロックを更に分割して同様に求めていけばよい。
【００９２】
また、ブロックサイズをより大きくすることで、仮想顧客の巡回ルートの取り得る数は減り処理時間は短縮するが、今度は精度が悪くなる。つまり、処理時間と精度とはトレードオフの関係にあると言える。そこで、実施形態では、巡回区域を分割する際のブロックサイズを徐々に大きくしていって、最初にコンピュータの処理能力の許容数以下になったブロックサイズでもって、そのブロックサイズを決定するようにした。
【００９３】
上記処理をまとめると、実施形態における巡回ルート決定処理（図１６のＳ２４）は、例えば図２０に示すフローチャートに従って処理すれば良いことになる。
【００９４】
先ず、ステップＳ４１において依頼ＤＢ２０４２０４ｅ内の未処理のデータを読込むと共に、読み込んだ依頼ＤＢ２０４ｅのデータのユーザＩＤをキーにして、ユーザＤＢ２０４ａから各顧客の座標位置を読込む。この結果、顧客の座標位置は勿論、巡回する顧客数及び各顧客が注文したカートリッジのボリューム及び回収依頼したボリュームを得ることができる。
【００９５】
次いで、ステップＳ４２に進み、ブロックサイズＳに初期値を設定し、ステップＳ４３で設定されたブロックサイズで各顧客の座標データを正規化し、顧客が存在するブロックを仮想顧客として設定し、その数を仮想顧客数Ｎｃとして算出する。
【００９６】
ステップＳ４４では、予め設定しておいた上限演算数Ｎｍａｘ（別途任意に設定できるものである）と比較し、Ｎｃ≦Ｎｍａｘであるか否かを判断する。Ｎｃ＞Ｎｍａｘであると判断した場合には、ステップＳ４５でブロックサイズＳをΔＳだけ大きくし、ステップＳ４３の処理を行う。
【００９７】
こうして、Ｎｃ≦Ｎｍａｘとなると、演算可能な個数になったわけであるから、処理はステップＳ４６に進み、仮想顧客における巡回ルート検索を行い、距離の小さい巡回ルート順に構築していく。このとき、各仮想顧客の座標は、各ブロックの中心位置に位置しているものとして扱うが、先に説明したように、実顧客の座標の重心位置としても良いのは勿論である。
【００９８】
この後、ステップＳ４７で初期値として変数ｉを“１”（最短巡回ルート）に初期化し、ステップＳ４８でｉ番目の巡回ルートを構成する仮想顧客順に巡回した際に、運送車の許容ボリューム（予め設定してある）を越えるタイミングがあるか否かを判断することで、そのルートをチェックする。ステップＳ４９でＮＧであると判断された場合には、ステップＳ５０で次の候補についてチェックするため変数ｉを１つ増やし、ステップＳ４８に戻る。
【００９９】
そして、こうして、順次、候補についてチェックしていって、無理のない巡回ルートが見つかると、ステップＳ５１でその仮想顧客による巡回ルートで決定し、本処理を終える。
【０１００】
なお、上記処理では、仮想顧客の巡回ルートが決定されるが、１つの仮想顧客内に実顧客が複数存在するものについては、それら複数の実顧客を含む全仮想顧客に対して、図２０と同様の処理を行い、最終的に仮想顧客＝１つの実顧客となるまで繰り返すことになる（例えば再帰演算でも実現できよう）。
【０１０１】
以上説明したように、カートリッジの納品及び回収を１台の運送車でもって実現する場合に、コンピュータの処理能力を越える顧客数の場合には、理想とするルートとはいかないまでも、積み下ろしにも無理のない、実質的に問題のないルートを決定できるようになる。
【０１０２】
＜他の実施形態＞
上記実施形態では、仮想顧客を決定する際に、マップ上を１つのサイズのブロックでマス目状に分割することで実現したが、必ずしもこれによって限定されるものではない。例えば、或る顧客に着目し、その顧客から距離Ｌ内にある顧客を１つグループとし、そのグループの重心位置に対して距離Ｌ内ある顧客を追加しては、新に重心位置を設定することを繰り返して、仮想顧客を決定するようにしてもよい。そして、取り込める顧客がいなくなった場合に、新たな未処理の顧客を着目し、同様の処理を行う（この結果、仮想顧客が占める領域（上記のブロックに対応する）は必ずしも同じ大きさにならなくなる）。こうして、全ての仮想顧客の数が許容数を越えた場合には、上記ＬをΔＬだけ大きくして、許容数以下になるものを見つけ出すようにする。後は、仮想顧客の巡回ルートの短い順に並べ、積み下ろしを加味して決定すれば良いであろう。
【０１０３】
また、巡回ルートが決定された際に、その巡回中に積載量のピークが判明するので、それを運送会社の端末３００に通知するようにしてもよい。この結果、運送会社では、必要最低限の積載量の運送車を手配できるようになるので、運送にかかる費用を削減できるようになる。
【０１０４】
また、実施形態のサーバ２００を設置するにしても、そのハードウェアの能力や、かけても良い時間によってもＮｍａｘは変わる。従って、このＮｍａｘはユーザが自由に設定できるようにすることが望ましい。
【０１０５】
また、資源の再利用上、各顧客に対し積極的に回収運動に参加しやすい環境を提供することが望まれる。従って、回収に見合うインセンティブがあった方が望ましい。
【０１０６】
そこで、カートリッジを回収させたとき、カートリッジ１本（のサイズ）につき対応するポイントを累積し、その累積されたポイントに応じて未使用カートリッジの注文の際に、割り引く等の特典を提供することが望ましい。
【０１０７】
この場合、ユーザＤＢ２０４ａの各ユーザデータ（図５）に、ポイント数を記憶保持するフィールドを追加し、回収本数に応じたポイントを累積加算する。そして、例えば、図７に示す画面のいずれかに、現在のポイント数とそれによる割り引き率や金額を提示し、それを使用するか否かを選択するボタンを用意する。ポイントを使用することが決まった場合には、それに応じて、別途請求書を発光する際に、割り引きし、且つ、ユーザのデータ中のポイントフィールドをクリアするれば良い。
【０１０８】
これは運送会社についても同様である。つまり、回収や納品するカートリッジのボリュームに応じて、インセンティブを設定することが望ましい。
。
【０１０９】
更に、上記実施形態では、運送車の作業員が、回収、納品する際に、受付標をバーコードで読み取るものとしたが、必ずしもバーコードである必要もない。要は、納品、回収が完了したことをサーバに通知するものであれば如何なる手段を用いても構わない。ただし、顧客及び運送作業員の手間ひまを考慮するのであれば、上記の通り、受付標にバーコードを印刷させ、それを読み取ることが望ましい。
【０１１０】
また、実施形態では、納品（発注）、回収する対象としてトナーカートリッジを例にして説明したが、これによって本願発明が限定されるものではない。すなわち、ＯＡ機器（ＦＡＸ、プリンタ等）そのものであっても良いし、より小さな消耗部品（例えばインクカートリッジ等）であっても構わない。更に、１種類に限らず、例えばＯＡ機器や消耗品が混在した納品／回収に適用しても良い。それ故、本発明は一般に物品の納品／回収にまで及ぶものである。
【０１１１】
また、更に、上記実施形態で説明したように、実施形態における主要部分のほとんどはサーバ２００によるものであったが、上記処理の一部は別途設けたコンピュータで実現しても構わない。特に、巡回ルートを検索する処理はコンピュータに負担がかかるので、その処理が稼動してしまうとＷｅｂサーバとしてのレスポンスが悪くなることが予想される。従って、運営会社には、いくつかのコンピュータを設置し、それら全体が実施形態のサーバ２００として動作させるようにしても構わない。
【０１１２】
また、上記の如く、実施形態における処理のほとんどはコンピュータのプログラムによるものであるので、当然、本発明は上記実施形態で説明した処理手順を実現するコンピュータプログラムをもその範疇とするものである。また、コンピュータプログラムは、通常、フロッピーディスクやＣＤＲＯＭ等の可搬性コンピュータ可読記憶媒体に格納され、それをコンピュータにセットしてインストールもしくはコピーすることで実現するものであるから、本発明はかかるコンピュータ可読記憶媒体をもその範疇にするのは明らかである。
【０１１３】
【発明の効果】
以上説明したように本発明によれば、巡回によって複数の顧客に対して納品／回収を行うことで、小口の依頼に対しても十分に応えることができ、且つ、単純な構成でもって各顧客先への訪問時刻を精度良く通知することが可能になる。
【図面の簡単な説明】
【図１】実施形態におけるシステム全体の概念図である。
【図２】実施形態におけるユーザ登録画面の内容を示す図である。
【図３】実施形態におけるユーザ登録完了を通知する内容を示す図である。
【図４】実施形態における機種ＤＢの内容を示す図である。
【図５】実施形態におけるユーザＤＢの内容を示す図である。
【図６】実施形態におけるサーバの具体的構成を示す図である。
【図７】実施形態における注文／回収依頼画面の内容を示す図である。
【図８】実施形態における依頼ＤＢの内容を示す図である。
【図９】実施形態における注文及び回収の受付完了の通知画面の内容を示す図である。
【図１０】実施形態における注文及び回収票を示す図である。
【図１１】実施形態における注文／回収の通知メールの内容を示す図である。
【図１２】実施形態における運送会社に通知される巡回ルートを示すメールの一例を示す図である。
【図１３】実施形態における巡回ルートテーブルの一例を示す図である。
【図１４】実施形態における巡回予定時刻の確認画面の内容を示す図である。
【図１５】実施形態におけるサーバのメイン処理を示すフローチャートである。
【図１６】実施形態におけるサーバにおける定時処理内容を示すフローチャートである。
【図１７】実施形態のサーバの、運送車の巡回中における処理手順を示すフローチャートである。
【図１８】実施形態における巡回ルートの決定する原理を示す図である。
【図１９】実施形態における巡回ルートの決定における仮想顧客化の原理を示す図である。
【図２０】実施形態における巡回ルート決定する際の処理手順を示すフローチャートである。
【図２１】実施形態におけるマップＤＢの内容を示す図である。
【図１】
0004086500.tif 000002
【図２】
0004086500.tif 000003
【図３】
0004086500.tif 000004
【図４】
0004086500.tif 000005
【図５】
0004086500.tif 000006
【図６】
0004086500.tif 000007
【図７】
0004086500.tif 000008
【図８】
0004086500.tif 000009
【図９】
0004086500.tif 000010
【図１０】
0004086500.tif 000011
【図１１】
0004086500.tif 000012
【図１２】
0004086500.tif 000013
【図１３】
0004086500.tif 000014
【図１４】
0004086500.tif 000015
【図１５】
0004086500.tif 000016
【図１６】
0004086500.tif 000017
【図１７】
0004086500.tif 000018
【図１８】
0004086500.tif 000019
【図１９】
0004086500.tif 000020
【図２０】
0004086500.tif 000021
【図２１】
0004086500.tif 000022