JP2002160826A

JP2002160826A - 配送管理システム

Info

Publication number: JP2002160826A
Application number: JP2001265212A
Authority: JP
Inventors: Gunji Tsukuda; 軍治佃
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2001-09-03
Filing date: 2001-09-03
Publication date: 2002-06-04

Abstract

(57)【要約】【課題】オンラインショッピングなどで購入した商品
の、物流業者から購入者への受け渡しを円滑に行う。【解決手段】物流業者の地区毎の配送情報と購入者のス
ケジュール情報より、購入品の配達予定日時を決定する
手段と、配達品に関する取次店利用基準の情報を利用し
て、配達品の受け渡しを取次店経由で行うことかどうか
を決定する手段と、取次店経由で物流業者から購入者に
商品を受け渡す場合、取次店に長期保管されている商品
を検出する手段を持つ。その結果、配達予定日が明確に
なっているため、配達時に在宅である可能性が高く、商
品の早期の受け渡しが可能になる。取次店を利用するこ
とにより、物流業者の営業時間に拘束されずに、商品を
受け取ることができる。取次店への受取り忘れを早期に
解決することができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、購入した商品を含
む物品の配送管理についての情報処理に関し、その中で
も特にオンラインショッピングや通信販売において商品
を購入した場合の、物流拠点から購入者への商品の受け
渡しを円滑に行うことを支援するシステムに関する。ま
た、本発明は、他者から送付される物品の配送管理にも
関わる。

【０００２】

【従来の技術】インタネットなどによるオンラインショ
ッピングの広がりにより、今まで以上に宅配が増加する
ことが予想される。一方で、結婚年齢の高年齢化や共稼
ぎ家庭の増加により、購入者が配達時に不在となる可能
性が高くなりつつある。これにより、物流業者にとって
は、再配達のコストが問題となる。また、購入者にとっ
ては、購入物をなかなか受取ることができない、という
問題が生じる。物流業者、配達先家庭双方にとって、商
品の受け渡しを円滑に行うことが、今後重要な課題とな
る。

【０００３】この課題を解決するため、不在時の商品の
受取りを可能にする技術がある。例えば、従来技術で
は、個々の家庭において、宅配ボックスを玄関先に設置
し、宅配ボックスの暗証番号を物流業者に連絡すること
で物流業者以外の他人によるボックスの開閉を阻止し、
安全性を確保する方法（特開平02-101572）や、集合住
宅の共有場所に、複数のボックスを持ち共有で用いる宅
配ロッカーを設置し、一戸の居住室に対する複数の宅配
物の受け渡しを可能にする方法（従来技術２、特開平06
-270992）などがある。なお、以下では、１つの荷物を
格納する区画をボックスと呼び、１つ以上のボックスを
もつ全体の構造物を宅配ロッカーと呼ぶことにする。

【０００４】また、上記課題を解決するための他の手段
として、電話による配達先住人から物流業者への配達希
望日時の連絡を受けた場合、プッシュボタンにより、自
動的に物流業者のデータベースに配達先希望日時が登録
され、それを利用することにより、不在時の配達を減少
させる方法がある（特開平05-165847)。この方法では、
さらに、配達先希望日時を蓄積することにより在宅日時
の傾向を検出し、ある配達に関して、配達先からの連絡
がない場合でも、傾向を利用することにより、不在時の
配達を減少させることについて記載されている。

【０００５】

【発明が解決しようとする課題】従来技術の宅配ボック
スを利用することにより、不在時に購入者に宅配物を届
けることが可能になる。しかし、スペースの問題ですべ
ての自宅前に宅配ボックスに設置することや、すべての
集合住宅の共有スペースに共有宅配ロッカーを設置する
のは困難である。

【０００６】また、集合住宅の共有スペースに共有宅配
ボックスを設置した場合でも、宅配物の受取り忘れが問
題となる。物流業者側では、宅配ボックスに収納した宅
配物が取り出されたかどうかわからないため、配達先住
人による受取りの確認ができない。そのため、宅配先住
人に対して受取りのフォローを行うことができない。

【０００７】また、従来技術の配達希望日の連絡による
不在配達を減少させる方法では、配達先住人が配達物が
あることを知る必要がある。このため、物流業者は、電
話または不在票などを用いて、配達物があることを配達
先住人に知らせなければならない。これは物流業者にと
ってはかなりの負担となる。また、配達希望日時から検
出した傾向は、たまたま今まで、ある曜日のある時間帯
に在宅であったことを示すだけである。在宅の可能性の
高い日時を利用して配達した場合でも、不在である可能
性は高いし、その日時よりも早く商品の受け渡しを行う
ことが可能である場合もかなりある。

【０００８】本発明の目的は、上記の従来技術の問題点
を解決し、オンラインショッピングなどで購入した商品
の、物流業者から購入者への受け渡しを円滑にすること
である。

【０００９】

【課題を解決するための手段】前記目的を達成するた
め、本発明では、物流業者の配送情報と購入者のスケジ
ュール情報より、購入品の配達予定日時を決定する手段
を持つ。

【００１０】

【発明の実施の形態】本発明の実施例を図面を用いて説
明する。図１は、本発明の第一の実施例の機能構成図で
ある。本実施例では、物流サーバ、クライアント（利用
者装置）、取次店サーバの３種類のサーバが存在し、各
サーバはネットワークで接続されている。３種類のサー
バは、ネットワーク上にそれぞれ複数存在する。１１１
は、物流サーバ上の機能の集合であり、１１２は、クラ
イアント上の機能の集合であり、１１３は、取次店サー
バ上の機能の集合である。図１上の矢印に付与した番号
は大まかな処理順番を示している。本発明の実施例で
は、オンラインショッピングにおいて、販売者と購入者
の契約が成立後の、物流業者から受取人への物の受け渡
しの方法について記載している。ただし、贈答などの場
合があるので、受取人が購入者であるとは限らない。

【００１１】契約した物について、実施例中では、配達
品、取次品、購入品の3種類の呼び方をしている。これ
は、物流業者の視点、取次店の視点、購入者の視点によ
る呼び方の違いである。ただし、配達品情報、取次品情
報、購入品情報と呼んだ場合には、それぞれの立場で管
理に利用する情報が異なるため、別のものを指してい
る。配達品情報１２２、購入品情報１２４の基本的な情
報である「契約コード」や「商品名」などは契約時に作
成された情報であり、本実施例では既に存在している情
報として扱っている。ただし、購入者と受取人が異なる
場合には、受取人のクライアントには、購入品情報は存
在しない。配達品情報１２２、購入品情報１２４、取次
品情報１２５において、同一の「契約コード」であれ
ば、同一の物を扱っていることを示す。本実施例では、
「契約コード」を４桁の数字で表現している。しかし、
実際には、「契約コード」はすべての契約に関して一意
にする必要があるため、販売者の名称などを含む形式と
なる。

【００１２】図２は、各サーバのハードウエア構成を示
している。入力装置には、キーボード、マウス以外にも
必要に応じてバーコードリーダ、カードリーダなどを含
む。出力装置には、画面、プリンタ以外にも必要に応じ
てバーコードライタ、カードライタなども含む。

【００１３】以下、図１に従って、第一の実施例を詳細
に説明する。ステップ１０１は、配送情報１２１と配達
品情報１２２を用いて、配達予定日時の一覧をクライア
ントに通知するステップである。

【００１４】配送情報１２１の例を図３に、配達品情報
１２２の例を図４に示す。配達予定日欄４１１が空白の
場合は、配達予定日や取次店が決定していないことを示
し、数字の場合は、配達予定日時を示し、文字列の場合
には、利用する取次店を示している。配達状況欄４１２
が空白の場合は、配達品が物流拠点にあることを示し、
数字の場合は、それは配達完了の日時であり、配達品が
配達先にあることを示し、文字列の場合は、配達品が取
次店にあることを示している。配達品到着日欄４１３に
は、通信ネットワ−ク経由で送付された物流拠点到達予
定日時、または実際に物流拠点へ搬入された日時が格納
されている。配送情報の編集は、物流サーバ上の機能と
して必要である。しかし、本実施例では、配送情報を既
に存在する情報として扱い、配送情報の編集機能につい
て言及しない。配達品情報の「契約コード」、「配達先
住所」、「配達品」、及び「配達先電子アドレス」は、
販売者と購入者の契約時に作成された情報であり、販売
者から通知された情報である。

【００１５】ステップ１０１の詳細フローを図５に示
す。ステップ５０１では、配達予定日が空欄である配達
品情報を取得する。例えば、配達品情報４０１を取得す
る。

【００１６】ステップ５０２では、取得した配達品情報
の配達先住所と配送情報１２１から、配達先住所に配達
する予定の日時の一覧を取得する。例えば、配達品情報
４０１の配達先住所は「美しが丘」であるので、「美し
が丘」の配達開始／終了日時である３０１、３０２を取
得する。

【００１７】ステップ５０３は、ステップ５０２で取得
した配達予定日時と配達品の契約コードを配達品情報１
２２の配達先電子アドレスに通知する。例えば、配達品
情報４０１の場合、電子アドレス「tsukuda@aaa.bbb」
に契約コード「1001」、配達開始／終了日時３０１、３
０２を通知する。購入者と受取人が異なる場合には、契
約コ−ド以外の配達品の情報も送付する。

【００１８】ステップ１０２は、物流サーバから受け取
った配達予定日時一覧とスケジュール情報１２３、購入
品情報１２４から配達予定日時を決定し、通知元の物流
サーバに決定した配達予定日時を通知するステップであ
る。

【００１９】スケジュール情報１２３の例を図６に、購
入品情報１２４の例を図７に示す。保管場所７０３は、
購入品が保管されている場所を示している。本実施例で
は、スケジュール情報を既に存在する情報として扱う。
スケジュール情報の編集機能は、クライアント上の機能
として必要であるが、本実施例の範囲外とする。購入品
情報の「契約コード」「購入品」は、販売者と購入者の
契約時に作成された情報であり、「取次店利用基準」
「利用取次店」は、購入者が契約時、または契約後に設
定した情報である。

【００２０】ステップ１０２の詳細フローを図８に示
す。ステップ８０１は、配達予定日時一覧とスケジュー
ル情報より、最も早い配達予定日時を取得するステップ
である。例えば、配達開始／終了日時３０１は、スケジ
ュール情報６０１により不可能であり、３０２の間は予
定がないため、３０２を配達予定日時として決定する
（この時点では、スケジュール情報６０２はまだ存在し
ていないものとする）。実際には、配達予定時間として
決定するためには、配達予定の開始時間が、直前の予定
の終了時間に移動時間を加味した時間よりも遅いことを
確認する必要がある。また、直後の予定との関係につい
ても同様に確認する必要がある。スケジュ−ル情報が存
在しない場合には、予定が全然ないものとして処理を行
なう。

【００２１】ステップ８０２は、取次店へ配達するか、
配達先住所に配達するかを判定するステップである。物
流拠点に到着した日と配達可能な最も早い配達予定日と
の間隔が、取次店利用基準７０１の日数以上である場合
には、取次店の利用を決定し、次にステップ８０３を実
行し、そうでない場合には、次にステップ８０４を実行
する。例えば、配達品情報４０１の場合、契約コード
「1001」の購入品情報７０５の取次店利用基準は、「５
日」であり、物流拠点到着日４０２「960922(15)」と最
も早い配達予定日「960925(16)」の間隔は、５日以上経
過していないので、配達先住所に配達することを決定す
る。取次店利用基準７０１に「利用せず」と記述されて
いる場合には、利用基準日数を無限大と見なす。取次店
利用基準としては、上記以外に「○月×日までに宅配で
きない場合」、「購入契約日から△日経過しても宅配で
きない場合」、「一度配達して不在の場合」などもあ
る。また、取次店利用基準が記述されていない配達品に
ついては、デフォルトの基準を利用することも考えられ
る。これにより、配達品の購入者と受取人が異なる場合
でも、取次店を利用することが可能になる。

【００２２】ステップ８０３では、配達予定日時一覧の
通知元の物流サーバに利用する取次店を通知する。例え
ば、契約コード「1001」の商品の場合、購入品情報７０
５より、「Ｘ取次店」を物流サーバに通知する。

【００２３】任意の取次店において、すべての商品の取
次が可能であるとは限らない。例えば、ある程度以上大
きい商品は、取り次げないとか、取次品を置く場所が一
時的になくなった場合に取次ぎ不可能になる。そのた
め、複数の取次店を物流サ−バに通知することもある。

【００２４】ステップ８０４では、配達予定日時一覧の
通知元の物流サーバに最も早い配達予定日時を通知する
と共に、配達予定日時をスケジュール情報１２３、購入
品情報１２４に登録する。例えば、契約コード「1001」
に関するスケジュール情報として、「開始日時：960925
(16)、終了日時：960925(18)、場所：自宅、内容：配達
品受取り」（６０２）をスケジュール情報１２３に登録
し、７０４に「960925(16)」を登録する。

【００２５】ステップ８０５では、配達予定日時一覧の
通知元の物流サーバを現在の保管場所として、購入品情
報１２４の保管場所７０３に登録する。

【００２６】ステップ１０３は、クライアントからの配
達予定日時または利用取次店を配達品情報１２２に登録
するステップである。例えば、契約コード１００１に関
して通知された配達予定日７０４を４０３に登録する。
このとき、配達品の情報を利用する取次店へ通知する場
合もある。取次店から取次ぎ不可能という通知が返って
きた場合には、別の取次店へ通知する。利用予定の取次
店の全てが利用不可能の場合には、クライアントへ通知
する。

【００２７】配達品の受け渡しを取次店で行う場合、配
達品自体は物流拠点から取次店に搬送される。このと
き、配達品に関する情報をバーコードリーダやカードリ
ーダなどの入力装置を用いて入力する。既に配達品の情
報が通信ネットワ−クを介して取次店サ−バに通知され
ている場合には、ネットワ−ク経由の購入品情報と入力
装置経由の購入品情報とを比較することにより、購入品
の認証を行なうステップ１０４では、取次店へ搬送する
配達品の情報を文字列またはバーコードの形式で紙に出
力するか、あるいは、カードに出力する。出力する情報
には、物流業者の電子アドレスも含む。

【００２８】ステップ１０５では、取次店へ配送完了し
た購入品を受取るために、購入品の情報を文字列または
バーコードの形式で紙に出力するか、あるいは、カード
に出力する。

【００２９】テップ１０６は、入力装置から入力された
購入品情報を、図９に示す取次品情報１２５に登録し、
入庫したことを関係する物流サーバとクライアントに通
知するステップである。入力には、ステップ１０４で作
成されたバーコードあるいはカードも利用できる。この
時、物流業者から取次店の間へ物の受け渡しを行う。

【００３０】ステップ１０６の詳細処理フローを図１０
に示す。ステップ１００１では、入力装置から入力され
た情報を取次品情報１２５に登録する。例えば、入力装
置から入力された情報が「契約コード：２５２９、購入
品：本、物流業者電子アドレス：info@a-butu.co、購入
者電子アドレス：tsukuda@aaa.bbb」の場合、これらの
情報が入力された日を入庫日とし、取次品情報９０１を
設定する。

【００３１】ステップ１００２では、配達品が取次店に
入庫されたことを物流サーバに通知する。例えば、取次
品情報９０１の場合、配達品の識別番号「２５２９」と
入庫フラグを物流業者のアドレス「info@a-butu.co」に
通知する。

【００３２】ステップ１００３では、ステップ１００２
と同様に、配達品が取次店に入庫されたことをクライア
ントに通知する。

【００３３】ステップ１０７は、入力装置から入力され
た取次品の契約コードを利用して、出庫日を取次品情報
１２５に登録し、出庫したことを関係する物流サーバと
クライアントに通知するステップである。入力には、ス
テップ１０５で作成されたバーコードあるいはカードも
利用できる。この時、取次店から購入者へ物の受け渡し
を行う。

【００３４】ステップ１０７の詳細処理フローを図１１
に示す。ステップ１１０１では、入力装置から入力され
た契約コードに一致する取次品が存在するかどうか判定
するステップである。

【００３５】ステップ１１０２では、契約コードが入力
装置から入力された時の日付を契約コードに関係する取
次品情報の出庫日欄に登録するステップである。例え
ば、契約コード「２５２９」が入力された場合、取次品
情報９０１の出庫日欄に日付を設定する。

【００３６】ステップ１１０３では、配達品が取次店か
ら出庫されたことを物流サーバに通知する。例えば、取
次品情報９０１の場合、配達品の識別番号「２５２９」
と出庫フラグを物流業者のアドレス「info@a-butu.co」
に通知する。

【００３７】ステップ１１０４では、ステップ１１０３
と同様に、配達品が取次店から出庫されたことをクライ
アントに通知する。

【００３８】ステップ１０８は、取次店サーバから通知
される情報に基づいて配達品情報１２２を更新するステ
ップである。取次店サーバからの通知情報が契約コード
と入庫フラグの場合、契約コードに関係する配達品情報
の配達状況欄に「取次店」と登録する。取次店サーバか
らの通知情報が契約コードと出庫フラグの場合、契約コ
ードに関係する配達品情報の配達状況欄に出庫した日を
登録する。ステップ１０８では、直接配達先に配達した
商品の配達完了情報が入力された場合には、その配達品
の配達状況欄に配達日時を登録することも行う。

【００３９】ステップ１０９は、取次店サーバから通知
される情報に基づいて購入品情報１２４を更新するステ
ップである。取次店サーバからの通知情報が契約コード
と入庫フラグの場合、契約コードに関係する購入品情報
の保管場所欄に取次店名を登録する。取次店サーバから
の通知情報が契約コードと出庫フラグの場合、契約コー
ドに関係する配達品情報の保管場所欄に出庫した日を登
録する。

【００４０】ステップ１１０は、配達品の異常状態を検
出するステップである。例えば、ある日数以上経過して
も、取次店にある配達品を購入者が受取りにきていない
商品について検出する。本実施例では、ステップ１１０
は物流サーバの機能としているが、ステップ１１０は、
クライアントや取次店サーバに持たすことも可能であ
る。

【００４１】以上で説明したステップ以外にも、物流サ
ーバ１１１、クライアント１１２、取次店サーバ１１３
は、各サーバで扱っている情報を出力する手段も持って
いる。第一の実施例により、以下の効果がある。

【００４２】（１）物流業者は、利用者の在宅を確認し
てから配達することになり、不在時の配達の割合が減少
し、配達コストを削減できる。（ただし、確認しても購
入者が出かけることはあり、不在時の配達はなくならな
い）。

【００４３】（２）購入者は、予め配達日時が明確にな
っているため、買い物などのちょっとした外出を控え
て、購入品を自宅で早期に受取ることができる。

【００４４】（３）購入者が物流業者の配達時間内に何
日間も帰宅しない場合、取次店を利用することにより、
早期に商品を受取ることが可能になる（取次店が物流業
者の配達時間より遅くまで営業している、という前提は
必要）。

【００４５】（４）取次店に何日間も保管され、購入者
が受取りを忘れている商品に対して、物流業者や取次店
から購入者に受取りを催促することができ、購入者の受
取り忘れを早期に解決することができる。また、購入者
自身が受取り忘れをチェックすることが可能であり、受
取りに行くことや、自宅への配達に切り替えるなどの対
処を早期に行うことができる。

【００４６】図１２は、本発明の第二の実施例の機能構
成図である。実施例１と同一の符号が付与されている箇
所は、実施例１と同一の処理や情報であることを示す。
本実施例では、第一の実施例と異なる部分のみを説明す
る。１２１１は、第二の実施例における物流サーバの機
能の集合を示し、１２１３は、取次店サーバの機能の集
合を示している。

【００４７】第一の実施例では、取次店での物の引き渡
しに人が介在することを前提としていた。すわわち、取
次店に常時いる人が、物流拠点からの物の受取りを確認
し、配達先の住人への物の引き渡しを行っている。第二
の実施例では、取次店の無人化を行うために、取次店に
宅配ロッカーを設置する。宅配ロッカーとは、物の引き
渡しを行うためのボックスの集合体であり、駅などに設
置してあるコインロッカーと同様の形状のものである。
各ボックスには、電子的な鍵があり、鍵の施錠、開錠を
行うボックス開閉装置と、ボックス内の物の存在の確認
を行うボックス監視装置がある。

【００４８】図１３に第二の実施例における取次店サー
バのハードウエア構成を示す。以下、図１２に従って、
第二の実施例を詳細に説明する。

【００４９】ステップ１２０４では、ステップ１０４で
出力する情報に追加して、配達品情報１２２２を利用し
て、配達品を宅配ロッカーに格納するときの条件（大き
さや冷蔵要否など）を出力する。

【００５０】図１４に配達品情報１２２と配達品情報１
２２２の差分のみを例を示す。配達品情報１２２２は、
配達品情報１２２の項目に、配達品の収納条件である
「大きさ」、「冷蔵要否」の項目を追加した構成となっ
ている。

【００５１】ステップ１２０６は、入力装置から入力さ
れた情報を取次品情報１２５、ロッカー情報１２２７に
登録し、入庫したことを関係する物流サーバ、クライア
ントに通知するステップである。入力には、ステップ１
２０４で作成したバーコードあるいはカードも利用でき
る。

【００５２】ロッカー情報１２２７の例を図１５に示
す。ロッカー情報には、「番号」以外に、「大きさ」、
「冷蔵可能？」などの各ボックスの利用条件を持つ。ま
た、各ボックスに格納している取次品の契約コードを格
納する契約コード欄もある。

【００５３】ステップ１２０６の詳細処理フローを図１
６に示す。

【００５４】ステップ１６０１は、物流業者情報１２２
６を利用して、入力情報中の物流業者の電子アドレスが
物流業者一覧に存在するかどうかチェックするステップ
である。このステップは、登録された物流業者以外の業
者による使用を禁止するためや、いたずらを防止するた
めに行う。そのようなこと意図しない場合にはこの処理
は不要である。図１７に物流業者情報１２２６の例を示
す。

【００５５】ステップ１６０２は、入庫予定の配達品に
対して、条件を満たすロッカーが存在するかチェックす
るステップである。例えば、契約番号「７２８１」の配
達品の場合の入庫条件は１４０１であり、ロッカー情報
１５０１により条件を満たすボックスが存在するため、
チェックＯＫとなる。

【００５６】ステップ１６０３は、ステップ１６０２に
より検出した、条件を満たすボックスの開閉装置に開錠
を指示するステップである。この後、物流業者は開錠し
たボックスの扉を開け、配達品を納入し、扉を閉める。

【００５７】ステップ１６０４は、開錠したボックスの
扉が閉められたかどうかチェックするステップである。
扉が閉められた場合、ボックス開閉装置から通知がく
る。この通知の有無によりチェックを行う。

【００５８】ステップ１６０５は、扉が閉められたボッ
クスの開閉装置に施錠を指示するステップである。ステ
ップ１６０６は、施錠したボックスの中に物が存在する
かチェックするステップであり、チェックには、赤外線
センサなどのボックス監視装置を用いる。チェックがＯ
Ｋである場合には、ステップ１０６（実施例１で説明済
み）の出庫処理を実行する。

【００５９】ステップ１２０７は、出庫日付を取次品情
報１２５に登録し、出庫したことを関係する物流サー
バ、クライアントに通知するステップである。入力に
は、ステップ１０５で作成されたバーコードあるいはカ
ードも利用できる。

【００６０】ステップ１２０７の詳細な処理フローを図
１８に示す。ステップ１８０１は、ロッカー情報１２２
７を利用して、入力した契約コードに関係する取次品が
ロッカーに格納されているかどうかチェックするステッ
プである。例えば、入力した契約コードが「４２９３」
の場合、ロッカー情報１５０２の契約コードと一致する
ため、チェックＯＫとなる。

【００６１】ステップ１８０２は、契約コードに関係す
る取次品を格納しているボックスの開閉装置に開錠を指
示するステップである。例えば、入力した契約コードが
「４２９３」の場合、ロッカー情報１５０２のボックス
番号「３」のロッカー開閉装置に開錠を指示する。

【００６２】この後、購入者は開錠したボックスの扉を
開け、購入品を取り出し、扉を閉める。さらに、ステッ
プ１６０４、ステップ１６０５、ステップ１６０６を実
行する。ステップ１６０６のチェックがＮＧの場合、次
にステップ１８０３を実行する。

【００６３】ステップ１８０３は、購入品を取り出した
ロッカーのロッカー情報の契約コード欄を削除するステ
ップである。扉が閉められた場合、ボックス開閉装置か
ら通知がくる。この通知の有無によりチェックを行う。

【００６４】第二の実施例では、物流業者が配達品を宅
配ロッカーに格納し、購入者が宅配ロッカーから配達物
を取り出すことを可能にしている。これにより、取次店
の無人化が実現でき、購入者の取次店での受取りに関し
て、時間の制約を受けない。よって、購入者が早期に商
品を受取ることができる。

【００６５】図１９は、本発明の第三の実施例の機能構
成図である。実施例１と同一の符号が付与されている箇
所は、実施例１と同一の処理、情報であることを示す。
１９１１は、第三の実施例における物流サーバの機能の
集合を示し、１１３は、取次店サーバの機能の集合を示
している。本実施例では、第一の実施例と異なる部分の
みを説明する。

【００６６】第一の実施例では、配送情報１２２、スケ
ジュール情報１２３の編集機能を発明の範囲外とし、こ
られの情報の削除による他のサーバへの影響を考慮しな
かった。本実施例では、配送情報、スケジュール情報の
削除による他のサーバへの影響を考慮した配達品統合管
理システムについて説明する。

【００６７】以下、図１９に従って、第三の実施例を詳
細に説明する。ステップ１９０１は、配送情報を編集す
るステップである。配送情報の編集は任意の時点で行う
ことができる。配送情報が削除された場合、ステップ１
９０２を呼び出す。

【００６８】ステップ１９０２は、削除された配送情報
に関する配達先のクライアントに配達予定日時の取消を
通知するステップである。例えば、配送情報３０１が削
除された場合、地区名「美しが丘」、配達開始時間「96
0925(16)」に該当する配達品情報４０４を検出し、クラ
イアントである配達先電子アドレス「yamada@aaa.ccc」
に契約コード「1001」の配達品の配達予定日時の取消を
通知する。ステップ１９０２による取消し通知後は、取
り消した配達品情報に基づいて、ステップ１０１を実行
する。

【００６９】ステップ１９０３は、クライアントからの
配達予定日時取消の通知を受け、配達品情報の該当する
配達予定日欄を空白にする。例えば、契約コード「120
5」の配達取消通知を受けた場合、配達品情報４０４の
配達予定日欄を空白にする。ステップ１９０３の実行
後、配達予定日欄を空白にした配達品情報に関して、ス
テップ１０１を実行する。

【００７０】ステップ１９０４は、スケジュール情報を
編集するステップである。スケジュール情報の編集は任
意の時点で行うことができる。配達品受取りに関するス
ケジュール情報が削除された場合、ステップ１９０５を
呼び出す。

【００７１】ステップ１９０５は、削除された配達品受
取りに関するスケジュールに関係する購入品情報の配達
予定欄を空白にし、かつ関係する物流サーバに配達予定
日時の取消を通知する。例えば、スケジュール６０２が
削除された場合、スケジュール６０２の開始日時と一致
する配達予定日を持つ購入品情報７０５の配達予定日欄
を空白にし、契約コード「1001」の配達予定日時の取消
を「Ａ物流」に通知する。

【００７２】ステップ１９０６は、物流サーバからの配
達予定日時取消の通知を受け、該当する購入品情報の配
達予定日欄を空白にし、関係するスケジュールの削除を
行う。例えば、契約コード「1001」の配達取消通知を受
けた場合、配達予定日７０４を空白にし、７０４と同一
の日時を開始日時欄に持つスケジュール情報６０２を削
除する。

【００７３】ステップ１９０７では、ステップ１０３と
同様にクライアントからの通知を受け、配達品情報に登
録する。ただし、ステップ１０１とステップ１０２の実
行の間にステップ１９０１により配送情報が削除される
場合がある。そこで、配達予定日時が配送情報に存在す
ることを確認後に配達品情報に登録する。

【００７４】本実施例によれば、購入者が商品受取りの
予定を取り消した場合、物流業者へ自動的に通知し、再
び物流業者から配達可能日時一覧が送付され、受取りの
予定を登録することができる。よって、購入者は商品受
取りの予定に縛られることなく、容易にスケジュールの
再調整を行うことができる。また、物流業者が配送予定
の予定を取り消した場合、購入者へ自動的に通知し、再
び物流業者から配送可能日時一覧が送付され、受取りの
予定を確保することができる。よって、物流業者は購入
者への影響を極力押さえられる。

【００７５】図１、図１２、及び図１９に示した処理を
実行するためのプログラムをフロッピィディスクや光デ
ィスクなどの可搬記憶媒体に格納し、これを主記憶に読
み込んで実行することもできる。

【００７６】上述した各実施例により、以下のような効
果がある。（１）物流業者は、利用者の在宅を確認してから配達す
ることになり、不在時の配達の割合が減少し、配達コス
トを削減できる。（ただし、確認しても購入者が出かけ
ることはあり、不在時の配達はなくならない）。（２）購入者は、予め配達日時が明確になっているた
め、買い物などのちょっとした外出を控えて、購入品を
自宅で早期に受取ることが可能になる。（３）購入者が物流業者の配達時間内に何日間も帰宅し
ない場合、取次店を利用することにより、早期に商品を
受取ることが可能になる（取次店が物流業者の配達時間
より遅くまで営業しているという前提は必要。取次店に
宅配ロッカーを設置した場合、取次店の無人化が行える
ので、上記前提の実現が容易になる）。（４）取次店に何日間も保管され、購入者が受取りを忘
れている商品に対して、物流業者や取次店から購入者に
受取りを催促することができ、購入者の受取り忘れを早
期に解決することができる。また、購入者自身が受取り
忘れをチェックすることが可能であり、受取りに行くこ
とや、自宅への配達に切り替えるなどの対処を早期に行
うことができる。（５）購入者が商品受取りの予定を取り消した場合、物
流業者へ自動的に通知し、再び物流業者から配達可能日
時一覧が送付され、受取りの予定を登録することができ
る。よって、購入者は商品受取りの予定に縛られること
なく、容易にスケジュールの再調整を行うことができ
る。（６）物流業者が配送予定の予定を取り消した場合、購
入者へ自動的に通知し、再び物流業者から配送可能日時
一覧が送付され、受取りの予定を確保することができ
る。よって、物流業者は購入者への影響を最低限に留め
ることができる。

【００７７】

【発明の効果】本発明によれば、より利用者の都合を考
慮した配送が可能になる。

【図面の簡単な説明】

【図１】第一の実施例の機能構成図である。

【図２】ハードウエア構成である。

【図３】配送情報の例である。

【図４】配達品情報の例である。

【図５】ステップ１０１の詳細処理フローである。

【図６】スケジュール情報の例である。

【図７】購入品情報の例である。

【図８】ステップ１０２の詳細処理フローである。

【図９】取次店情報の例である。

【図１０】ステップ１０６の詳細処理フローである。

【図１１】ステップ１０７の詳細処理フローである。

【図１２】第二の実施例の機能構成図である。

【図１３】取次店サーバ１２１３のハードウエア構成で
ある。

【図１４】第二の実施例における配達品情報の例、ただ
し第一の実施例の配達品情報からの増加項目のみを示し
た図である。

【図１５】ロッカー情報の例である。

【図１６】ステップ１２０６の詳細処理フローである。

【図１７】物流業者一覧情報の例である。

【図１８】ステップ１２０７の詳細処理フローである。

【図１９】第三の実施例の機能構成図である。

【符号の説明】

１１１・・・物流サーバの機能構成、１１２・・・クラ
イアントの機能構成、１１３・・・取次店サーバの機能
構成、１０１・・・配達可能日一覧通知ステップ、１０
２・・・クライアント側配達予定日登録ステップ、１０
３・・・物流サーバ側配達予定日登録ステップ、１０６
・・・入庫処理ステップ、１０７・・・出庫処理ステッ
プ、１０８・・・配達品情報更新ステップ、１０９・・
・購入品情報更新ステップ、１１０・・・配達品の異常
状態を検出するステップ、１２１・・・配送情報、１２
２・・・配達品情報、１２３・・・スケジュール情報、
１２４・・・購入品情報、１２５・・・取次品情報、４
１１・・・配達予定日欄、４１２・・・配達状況欄、７
０１・・・取次店利用基準欄、７０２・・・利用取次
店、７０３・・・保管場所欄、１２２７・・・ロッカー
情報、１９０１・・・配送情報編集ステップ、１９０４
・・・スケジュール情報編集ステップ

Claims

【特許請求の範囲】

【請求項１】配送される商品を受け取る利用者が利用す
る利用者装置と、前記商品の配送を管理する物流サーバ
とが互いにネットワークを介して接続された配送管理シ
ステムにおいて、前記物流サーバは、前記ネットワークを介して前記利用
者装置に、前記商品を配送する物流業者の配送スケジュ
ールを送信する手段を有し、前記利用者装置は、前記利用者の予定を示すスケジュー
ル情報の入力を受付ける手段と、送信された前記配送ス
ケジュールおよび前記スケジュール情報に基づいて、前
記商品の配送予定日時を決定する手段と、前記ネットワ
ークを介して前記物流サーバへ、決定された前記配送予
定日時を送信する手段を有し、前記商品が前記配送予定日時に従って配送されることを
特徴とする配送管理システム。
【請求項２】請求項1に記載の配送管理システムにおい
て、前記決定する手段は、前記配送スケジュールがあいてお
り、前記利用者の予定がない日時を前記配送予定日時と
して決定することを特徴とする配送管理システム。
【請求項３】請求項２に記載の配送管理システムにおい
て、前記配送予定日時を決定する手段は、前記利用者の予定
がない日時のうち、直前の配送予定地から当該商品の配
送先への移動時間が確保され、当該商品の配送先から直
後の配送予定地への移動時間が確保される日時を前記配
送予定日時として決定することを特徴とする配送管理シ
ステム。
【請求項４】請求項１乃至３のいずれかに記載の配送管
理システムにおいて、前記利用者装置は、前記スケジュール情報を記憶する手
段をさらに有することを特徴とする配送管理システム。
【請求項５】配送対象である商品の配送を管理する物流
サーバとネットワークを介して接続され、前記商品を受
け取る利用者が利用する配送管理システムにおける利用
者装置において、前記物流サーバから前記ネットワークを介して送信され
る、前記商品を配送する物流業者の配送スケジュールを
受信する手段と、前記利用者の予定を示すスケジュール情報の入力を受付
ける手段と、送信された前記配送スケジュールおよび前記スケジュー
ル情報に基づいて、前記商品の配送予定日時を決定する
手段と、前記ネットワークを介して前記物流サーバへ、決定され
た前記配送予定日時を送信する手段を有することを特徴
とする配送管理システムにおける利用者装置。
【請求項６】請求項５に記載の配送管理システムにおけ
る利用者装置において、前記決定する手段は、前記配送スケジュールがあいてお
り、前記利用者の予定がない日時を前記配送予定日時と
して決定することを特徴とする配送管理システムにおけ
る利用者装置。
【請求項７】請求項６に記載の配送管理システムにおけ
る利用者装置において、前記配送予定日時を決定する手段は、前記利用者の予定
がない日時のうち、直前の配送予定地から当該商品の配
送先への移動時間が確保され、当該商品の配送先から直
後の配送予定地への移動時間が確保される日時を前記配
送予定日時として決定することを特徴とする配送管理シ
ステムにおける利用者装置。
【請求項８】請求項５乃至７のいずれかに記載の配送管
理システムにおける利用者装置において、前記スケジュール情報を記憶する手段をさらに有するこ
とを特徴とする配送管理システム。
【請求項９】配送される商品を受け取る利用者が利用す
る利用者装置と、前記商品の配送を管理する物流サーバ
とが互いにネットワークを介して接続された配送管理シ
ステムを用いた配送管理方法において、前記物流サーバから前記ネットワークを介して前記利用
者装置に、前記商品を配送する物流業者の配送スケジュ
ールを送信し、前記利用者装置が、前記利用者の予定を示すスケジュー
ル情報の入力を受付け、送信された前記配送スケジュー
ルおよび前記スケジュール情報に基づいて、前記商品の
配送予定日時を決定し、前記ネットワークを介して前記
物流サーバへ、決定された前記配送予定日時を送信し、前記商品が前記配送予定日時に従って配送されることを
特徴とする配送管理方法。
【請求項１０】請求項９に記載の配送管理方法におい
て、前記配送予定日時の決定は、前記配送スケジュールがあ
いており、前記利用者の予定がない日時を前記配送予定
日時として決定することを特徴とする配送管理方法。
【請求項１１】請求項１０に記載の配送管理方法におい
て、前記配送予定日時は、前記利用者の予定がない日時のう
ち、直前の配送予定地から当該商品の配送先への移動時
間が確保され、当該商品の配送先から直後の配送予定地
への移動時間が確保される日時を前記配送予定日時とし
て決定することを特徴とする配送管理方法。
【請求項１２】請求項９乃至１１のいずれかに記載の配
送管理方法において、前記利用者装置が、前記スケジュール情報を記憶する手
段を有することを特徴とする配送管理方法。