(57)【特許請求の範囲】
【請求項１】
宅配要求受付処理部と、梱包配送関連処理部と、ユーザの識別情報と当該ユーザの購入商品を特定する購入商品情報と当該購入商品の購入店舗の識別情報とを前記購入商品毎に格納する荷物管理テーブル格納部と、前記ユーザの識別情報と当該ユーザの送り先の情報とを前記ユーザ毎に格納するユーザマスタデータベースとを有するコンピュータにより実行される配送情報処理方法であって、
前記ユーザの端末から前記購入商品情報と前記購入店舗の識別情報とを含む配送要求を受信した場合、前記宅配要求受付処理部により、前記購入商品情報及び前記購入店舗の識別情報と当該ユーザの識別情報とを対応付けて前記荷物管理テーブル格納部に格納する配送要求受信ステップと、
前記ユーザの端末から購入完了指示を受信した場合、又は前記ユーザの端末から最初の前記配送要求を受信してから所定時間経過したにもかかわらず前記購入完了指示を受信しない場合、前記梱包配送関連処理部により、当該ユーザの識別情報に基づき前記ユーザマスタデータベースから抽出される前記ユーザの送り先の情報と、当該ユーザの識別情報に基づき前記荷物管理テーブル格納部から抽出される前記購入商品情報のうち所定の条件に合致した購入商品に関する前記購入商品情報と、前記所定の条件に合致した購入商品に関する前記購入商品情報に対応し且つ前記荷物管理テーブル格納部に格納されている前記購入店舗の識別情報とを含む梱包指示の情報を生成し、配送業者サーバに送信する梱包指示送信ステップと、
を含む配送情報処理方法。
【請求項２】
前記ユーザの端末から前記所定時間の延長要求を受信した場合には、前記所定時間に所定の延長時間を加算することにより、第２の所定時間を計算し、記憶装置に設定するステップ
をさらに含み、
前記梱包指示送信ステップが、
前記ユーザの端末から最初の前記配送要求を受信してから前記第２の所定時間経過しかた否か判断するステップ
を含む請求項１記載の配送情報処理方法。
【請求項３】
前記ユーザの端末から最初の前記配送要求を受信してから所定時間経過したにもかかわらず購入完了指示を受信しない場合、前記ユーザに対して前記配送要求の受付完了を通知するステップ、
をさらに含む請求項１記載の配送情報処理方法。
【請求項４】
前記所定時間経過前の所定のタイミングにて、前記ユーザに対して前記配送要求の受付完了となる購入期限時刻を通知するステップ、
をさらに含む請求項１記載の配送情報処理方法。
【請求項５】
ユーザの識別情報と当該ユーザの購入商品を特定する購入商品情報と当該購入商品の購入店舗の識別情報とを前記購入商品毎に格納する荷物管理テーブル格納部と、
前記ユーザの識別情報と当該ユーザの送り先の情報とを前記ユーザ毎に格納するユーザマスタデータベースと、
前記ユーザの端末から前記購入商品情報と前記購入店舗の識別情報とを含む配送要求を受信した場合、前記購入商品情報及び前記購入店舗の識別情報と当該ユーザの識別情報とを対応付けて前記荷物管理テーブル格納部に格納する配送要求受信手段と、
前記ユーザの端末から購入完了指示を受信した場合、又は前記ユーザの端末から最初の前記配送要求を受信してから所定時間経過したにもかかわらず前記購入完了指示を受信しない場合、当該ユーザの識別情報に基づき前記ユーザマスタデータベースから抽出される前記ユーザの送り先の情報と、当該ユーザの識別情報に基づき前記荷物管理テーブル格納部から抽出される前記購入商品情報のうち所定の条件に合致した購入商品に関する前記購入商品情報と、前記所定の条件に合致した購入商品に関する前記購入商品情報に対応し且つ前記荷物管理テーブル格納部に格納されている前記購入店舗の識別情報とを含む梱包指示の情報を生成し、配送業者サーバに送信する梱包指示送信手段と、
を有する配送情報処理装置。
【発明の詳細な説明】
【０００１】
【発明が属する技術分野】
本発明は、複数物品の一括配送のための情報処理技術に関する。
【０００２】
【従来の技術】
観光地で土産物等を購入する際、観光をしながら次々と土産物等を購入すると、購入した土産物を手に持って移動する必要があり、重くなって持ち運びが大変であったり、次に買いたいものがあっても持ちきれなくて購入を断念せざるを得ない場合が生ずる。また、観光地ではその周辺住民等が利用する宅配取扱店も存在しているが、そのような宅配取扱店はどこにでもあるわけではなく、観光中に時間を割いて探さなければならない。又は、どこにあるのか分からないため、結局購入した土産物等を手に持って観光することになるため、十分に観光を楽しむことができなくなってしまう。
【０００３】
また、観光地にも、土産物等の宅配便配送を取り扱っている店舗等（観光施設等を含む）が存在しているが、そのような店舗等では当該店舗等で購入した土産物等のみを送ることが前提となっている場合が多い。従って、異なる店舗で買い物をする場合には、その都度配送料がかかり、観光客の負担は大きい。
【０００４】
【発明が解決しようとする課題】
従って本発明の目的は、異なる店舗において購入した物品についても一括して配送できるようにするための情報処理技術を提供することである。
【０００５】
【課題を解決するための手段】
本発明に第１の態様に係る配送情報処理方法は、ユーザの端末から購入商品の購入店舗からの配送の要求を受信した場合、当該配送の要求に関する情報を記憶装置に格納する配送要求受信ステップと、ユーザの端末から購入完了指示を受信した場合、当該ユーザの端末から購入完了指示受信までに受信された配送の要求に係る全購入商品のうち所定の条件に合致した購入商品の梱包指示を配送業者に対して送信する梱包指示送信ステップとを含む。
【０００６】
このようにすることにより、ユーザは例えば商品を購入する毎に配送の要求を、ショッピング終了時には購入完了指示を本配送情報処理方法を実施するコンピュータに送信するだけで購入物品が一括して配送されるようになるため、利便性が高くなる。なお、配送業者は、個々の購入物品を集荷して梱包することになるが、このシステムにより多くのユーザが配送を依頼するようになれば収益が向上するようになる。店舗についてもユーザは持ち運びを考慮せずに土産物等を購入できるようになるため、販売量が増加して収益が向上するようになる。
【０００７】
なお、ユーザの端末から最初の配送の要求を受信してから所定時間経過したにもかかわらず購入完了指示を受信しない場合、ユーザの端末から所定時間経過までに受信された配送の要求に係る全購入商品のうち所定の条件に合致した購入商品の梱包指示を配送業者に対して送信する梱包指示送信ステップをさらに含むような構成であってもよい。ユーザが購入完了指示の送信を忘れる場合もあり、集荷した購入商品の管理の都合からも所定時間を設定して自動的に購入完了指示が行われたものとして取り扱うものである。
【０００８】
また、ユーザの端末から所定時間の延長要求を受信した場合には、所定時間の延長を記憶装置に設定するステップをさらに含むような構成であってもよい。ショッピングを長く行うユーザのためである。
【０００９】
また、ユーザの端末から最初の配送の要求を受信してから所定時間経過したにもかかわらず購入完了指示を受信しない場合、ユーザに対して配送の要求の受付完了を通知するステップをさらに含むような構成であってもよい。自動的に購入完了処理が行われた場合にはこれ以上配送の要求を受け付けないことをユーザに通知する方がよいためである。
【００１０】
さらに、所定時間経過前の所定のタイミングにて、ユーザに対して配送の要求の受付完了を予告するステップをさらに含むような構成であってもよい。配送の要求の受付期限をユーザに認識させるためである。
【００１１】
また、ユーザの端末からの要求に応じて、記憶装置に格納された配送の要求に関する情報を用いて配送料の見積りを実施し、当該配送料の見積りの情報をユーザの端末に送信するステップをさらに含むような構成であってもよい。ユーザは配送料の見積りを目処に配送の要求を加減することができる。
【００１２】
さらに、ユーザの端末から購入商品の購入店舗からの配送の要求を受信した場合、当該購入商品の集荷指示を配送業者のコンピュータに送信するステップをさらに含むような構成とすることも可能である。配送の要求を受信する毎に集荷指示を送信することも可能であるし、配送業者が集荷指示が無くとも定期的に所定の店舗に集荷に行くような構成も可能である。
【００１３】
また、特定の購入店舗からの配送の要求をユーザの端末から所定数以上受信した場合に、特定の購入店舗及び当該特定の購入店舗に関連付けられた店舗についての購入商品の集荷要求を配送業者に対して送信するステップをさらに含むような構成であってもよい。このようにすることにより、ある程度まとまった集荷を行うことができるため効率的な集荷を行うことができるようになる。
【００１４】
なお、梱包指示に、ユーザにより指示された配送先の情報を含むような構成であってもよい。すなわち梱包指示が配送指示を兼ねている場合である。
【００１５】
さらに、ユーザの端末から購入商品の購入店舗からの配送の要求を受信した場合、当該購入商品の配送業者による少なくとも梱包に用いるための情報をユーザの端末又は購入店舗のコンピュータに送信するステップをさらに含むような構成であってもよい。例えば集荷や梱包を正確且つ効率的に行うためＩＣタグを用いる場合には、ＩＣタグに書き込むべき例えばユーザの識別情報や一括配送される購入商品群の識別情報（例えば実施の形態に係る代表番号）等である。このような情報を用いることにより、ユーザは送付状を書き込むといった手間も無くなる。
【００１６】
また、上で述べた所定の条件が、購入店舗が予め特定された店舗以外の店舗であること又は購入商品が予め特定された商品以外の商品であることである場合もある。所定の集荷範囲から外れる店舗の場合や特別な取り扱いが必要な生鮮食品などについては一括梱包が不可能であるためである。
【００１７】
本発明の第２の態様に係る配送情報処理方法は、ユーザの端末から購入商品の購入店舗からの配送の要求を受信した場合、当該配送の要求に関する情報を記憶装置に格納する配送要求受信ステップと、所定のタイミング（例えば最初の配送の要求から所定時間経過後又は所定の時刻）以降に、ユーザの端末から当該所定のタイミングまでに受信された配送の要求に係る全購入商品のうち所定の条件に合致した購入商品の梱包指示を配送業者に対して送信する梱包指示送信ステップとを含む。このように、ユーザが購入完了指示を行わないということを前提とする構成にすることも可能である。
【００１８】
本発明の第３の態様に係る配送要求処理方法は、購入商品及び購入店舗についての情報を含む購入商品の配送要求を少なくとも購入店舗毎にセンタ・サーバに送信するステップと、全購入商品のうち所定の条件を満たした購入商品の指定場所への一括配送開始要求をセンタ・サーバに送信するステップとを含む。
【００１９】
なお、上述の方法はプログラム及びコンピュータにて実施することができ、このプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介して配布される場合もある。尚、中間的な処理結果はメモリに一時保管される。
【００２０】
【発明の実施の形態】
最初に図１を用いて本発明におけるビジネスフローの一例を示す。ユーザは例えば店舗Ａにて商品Ａを購入する（ステップ（１））。その際例えば携帯電話機を用いて宅配便受付業務サービス・センタにユーザＩＤ、店舗Ａ、商品Ａの識別情報及び商品サイズ等の情報を含む宅配要求を送信する（ステップ（２））。宅配便受付業務サービス・センタのセンタ・サーバは、当該宅配要求を受信すると、一括配送商品を特定するための代表番号及び個々の商品を識別する追番の組み合わせである受付番号やユーザＩＤ等のユーザ情報を含むＩＣタグ情報を生成して、ユーザの携帯電話機又は店舗Ａに設置されたＩＣタグライタに送信する（ステップ（３））。ユーザの携帯電話機にＩＣタグ情報が送信される場合には、携帯電話機から例えばBluetoothや無線ＬＡＮ又はケーブル接続等の通信手段により店舗ＡのＩＣタグライタにＩＣタグ情報を送信する（ステップ（３）'）。店舗ＡではＩＣタグライタによりＩＣタグに受信した情報を書き込み（ステップ（４））、商品Ａ又は商品Ａの包装物に添付する。伝票をＩＣタグ情報を用いて印刷し、商品Ａ等に添付しても良い。なお、ユーザの携帯電話機から宅配要求を送信するのではなく、店舗ＡのＰＯＳレジスタ等の機器から宅配便受付業務サービス・センタのセンタ・サーバに送信してもよい。宅配便受付業務サービス・センタのセンタ・サーバは、店舗Ａからの商品Ａの集荷指示を配送業者のサーバに送信する（ステップ（５））。なお、ユーザの携帯電話機には、宅配便受付業務サービス・センタのセンタ・サーバから配送料の見積り結果を送信する。
【００２１】
ユーザは次に店舗Ｂに行き、商品Ｂを購入する（ステップ（６））。その際例えば携帯電話機を用いて宅配便受付業務サービス・センタにユーザＩＤ、店舗Ｂ、商品Ｂの識別情報及び商品サイズ等の情報を含む宅配要求を送信する（ステップ（７））。宅配便受付業務サービス・センタのセンタ・サーバは、当該宅配要求を受信すると、受付番号やユーザＩＤ等のユーザ情報を含むＩＣタグ情報を生成して、ユーザの携帯電話機又は店舗Ｂに設置されたＩＣタグライタに送信する（ステップ（８））。ユーザの携帯電話機にＩＣタグ情報が送信される場合には、携帯電話機から何らかの通信手段により店舗ＢのＩＣタグライタにＩＣタグ情報を送信する（ステップ（８）'）。店舗ＢではＩＣタグライタによりＩＣタグに受信した情報を書き込み（ステップ（９））、商品Ｂ又は商品Ｂの包装物に添付する。伝票をＩＣタグ情報を用いて印刷し、商品Ｂ等に添付しても良い。宅配便受付業務サービス・センタのセンタ・サーバは、店舗Ｂからの商品Ｂの集荷指示を配送業者のサーバに送信する（ステップ（１０））。また、ユーザの携帯電話機には、宅配便受付業務サービス・センタのセンタ・サーバから配送料の見積り結果を送信する。
【００２２】
配送業者は、ＩＣタグの付いた商品Ａを商店Ａから、商品Ｂを商品Ｂから集荷する（ステップ（１１）及び（１１）'）。配送業者は、配送業者のサーバから集荷した商品の受付番号等を含む集荷完了通知を宅配便受付業務サービス・センタのセンタ・サーバに送信する（ステップ（１２））。
【００２３】
このような処理を繰り返し、ショッピングの終了をユーザが決心した場合には、ユーザは例えば携帯電話機を用いてユーザＩＤを含む購入完了指示を宅配便受付業務サービス・センタのセンタ・サーバに送信する（ステップ（１３））。宅配便受付業務サービス・センタのセンタ・サーバは、購入完了指示を受信すると、配送業者のサーバに梱包指示を送信する（ステップ（１４））。配送業者のサーバが梱包指示を受信すると、当該配送業者は、商品に添付されているＩＣタグなどを用いて一括配送すべき商品群を集めて、梱包を行う（ステップ（１５））。梱包指示には、配送先の情報や、梱包すべき商品群の情報等が含まれ、梱包及び配送に使用される。配送業者は、梱包した時点で配送料が確定するため当該確定配送料の情報を配送業者のサーバに入力し、配送業者のサーバは代表番号及び確定配送料等を含む料金通知を宅配便受付業務サービス・センタのセンタ・サーバに送信する（ステップ（１６））。宅配便受付業務サービス・センタのセンタ・サーバは、ユーザの携帯電話機等に当該確定配送料を通知するようにしてもよい。
【００２４】
そして、配送業者はユーザの自宅など指定の場所に梱包した商品群を配送する（ステップ（１７））。配送が完了すると、配送完了が配送業者のサーバに登録され、配送完了通知が配送業者のサーバから宅配便受付業務サービス・センタのセンタ・サーバに送信される（ステップ（１８））。
【００２５】
このようにすれば、ユーザは複数の店舗等を回ってショッピングを行う場合であっても、購入した商品を持ち歩く必要は無く、観光等における負担が低減される。配送業者は、集荷及び梱包という手数がかかるが、ユーザにとって利便性が高いので宅配便利用が増加して、収益が向上することが期待できる。さらに、店舗は、持ち運びを気にせずにショッピングができるためユーザによる購入量が増え、収益が向上することが期待できる。
【００２６】
なお、配送料の決済については着払いであってもよいし、宅配便受付業務サービス・センタにクレジットカードや銀行口座等を登録してそれらにより行ってもよい。また、図１ではユーザが購入完了指示を行う例を示しているが、商品Ａを購入した際に行った宅配要求から所定時間内に購入完了指示が行われなかった場合には、自動的に購入完了と判断してステップ（１４）以降の処理を実施してもよい。しかし、ユーザのショッピングの都合によっては、ユーザの携帯電話機等から延長指示を宅配便受付業務サービス・センタのセンタ・サーバに送信する場合もある（ステップ（１３）'）。延長指示を受け付けた宅配便受付業務サービス・センタのセンタ・サーバは、期限時刻を所定時間だけ延長する。
【００２７】
なお、ユーザは携帯電話機等により、宅配要求の状況を宅配便受付業務サービス・センタのセンタ・サーバから取得することができる。また、本システムを利用する店舗及びユーザに対してはポイントを付与して、利用を促進する場合もある。
【００２８】
次に図１に示したようなビジネスフローを実施するために用いるコンピュータ・システムの一例を図２に示す。宅配便受付業務サービス・センタに設置されるセンタ・サーバ３は、インターネット等のネットワーク１に接続される。ネットワーク１には、ＰＤＡ（Personal Digital Assistance）５や携帯電話機７等のユーザ端末、例えば店舗Ａ等の店舗に設置されるＩＣタグライタ９やＰＯＳレジスタ１３、配送業者の施設等に設置される配送業者サーバ１５などが接続される。ＩＣタグライタ９には伝票プリンタ１１が接続されている。
【００２９】
なお、店舗に設置されるＩＣタグライタ９と携帯電話機７等のユーザ端末がBluetooth（詳細についてはhttp://www.bluetooth.comを参照のこと。）や無線ＬＡＮ、ケーブル接続などにより通信できれば、ＩＣタグライタ９はネットワーク１に接続せずともよい。また、ＰＯＳレジスタ１３についても、携帯電話機７等のユーザ端末により宅配要求をセンタ・サーバ３に送信する場合には、ネットワーク１に接続しなくともよい。
【００３０】
ＩＣタグライタ９、ＰＯＳレジスタ１３、配送業者サーバ１５については、専用回線等携帯電話機７等のユーザ端末が使用するネットワークとは別のネットワークにてセンタ・サーバ３に接続するようにしてもよい。
【００３１】
センタ・サーバ３は、携帯電話機７等のユーザ端末やＰＯＳレジスタ１３等から宅配要求を受信し、処理する宅配要求受付処理部３１と、宅配要求に係る物品の集荷に関連する処理を実施する集荷関連処理部３２と、購入完了指示又は自動購入完了以降の配送業者における梱包や配送に関連する処理を実施する梱包配送関連処理部３３と、ユーザや店舗に付与されるポイントを管理するためのポイント管理部３４とが含まれる。また、センタ・サーバ３は、ユーザに関する個人情報を格納するユーザマスタＤＢ３５、店舗についての情報を格納する店舗マスタＤＢ３６、本システムにおいて取り扱われる荷物を管理するためのテーブルを格納する荷物管理テーブル格納部３７、及びユーザや店舗に付与されるポイントについての情報を格納するポイントＤＢ３８を管理している。
【００３２】
次にユーザマスタＤＢ３５に格納されるデータの一例を図３に示す。図３の例では、ユーザＩＤの欄６０１と、ユーザの携帯電話番号の欄６０２と、個々の携帯電話機を識別するために用いられるサブスクライバ（Subscriber）ＩＤ又はＩＰｖ６のアドレスの欄６０３と、ユーザのメール・アドレスの欄６０４と、ユーザの氏名の欄６０５と、ユーザの住所の欄６０６と、ユーザの生年月日の欄６０７と、ユーザの性別の欄６０８と、ユーザの既婚／未婚の別を示す情報を格納するための欄６０９と、ユーザの自宅電話番号の欄６１０と、ユーザが用いるパスワードの欄６１１とが含まれる。より多くの個人属性を格納するような構成であってもよい。決済のための情報を格納する場合もある。
【００３３】
また、店舗マスタＤＢ３６に格納されるデータの一例を図４に示す。図４の例では、店舗等の登録番号の欄７０１と、店舗等の名称の欄７０２と、店舗等の住所の欄７０３と、店舗等の電話番号の欄７０４と、店舗等が用いるパスワードの欄７０５と、店舗等の種別の欄７０６と、当該店舗等が配送業者による通常集荷の範囲外である離島などにある場合に当該店舗における購入商品の集荷・配送又は配送料見積りで特別な取り扱いを行うために用いる集荷範囲フラグ（１は通常集荷範囲：０は通常集荷範囲外）の欄７０７と、集荷要求を配送業者に対して出力する際の基準となる店舗であるアンテナ店の集荷荷物個数についての集荷基準の欄７０８と、アンテナ店において集荷基準以上の集荷荷物がある場合に一緒に集荷すべき店舗等のグループを示す集荷グループの欄７０９とを含む。より多くの店舗属性を格納するような構成であってもよい。
【００３４】
荷物管理テーブル格納部３７に格納されるテーブルは、代表番号管理テーブル、宅配受付テーブル、集荷管理テーブル及び配送管理テーブルである。なお、補助データとして、同梱見積テーブル及び特種品配送料テーブルも格納される。
【００３５】
荷物管理テーブル格納部３７に格納される代表番号管理テーブルの一例を図５に示す。代表番号は、一括して配送する商品群を識別するための識別情報である。図５の例では、代表番号の欄５０１と、当該代表番号に係る宅配要求元であるユーザのユーザＩＤの欄５０２と、宅配要求の指示開始時刻の欄５０３と、購入期限時刻の欄５０４と、購入完了か否かを表す状態フラグの欄５０５と、購入期限時刻前にユーザに期限時刻を警告したか否かを表す通知フラグの欄５０６と、購入期限時刻の延長を行ったか否かを表す延長フラグの欄５０７とが含まれる。
【００３６】
荷物管理テーブル格納部３７に格納される宅配受付テーブルの一例を図６に示す。図６の例では、宅配要求を送信したユーザのユーザＩＤの欄６２０と、宅配要求受信の年月日及び時刻の欄６２１と、ユーザが商品等を購入した店舗等の登録番号の欄６２２と、代表番号（例えばＮ１００）と購入商品の通し番号（追番：例えば０１）とで構成される受付番号の欄６２３と、宅配要求の対象商品の商品名又は番号の欄６２４と、当該宅配要求の対象商品が特種品か否かを表す特種品フラグの欄６２５と、ＩＣタグ情報を送信したか否かを表すＩＣタグ情報送信済チェック（１は送信済み：０は未送信）の欄６２６とが含まれる。図６には、商品サイズ格納欄が示されていないが、このテーブルに格納されるものとする。
【００３７】
荷物管理テーブル格納部３７に格納される集荷管理テーブルの一例を図７に示す。図７の例では、宅配要求を送信したユーザのユーザＩＤの欄６４０と、ユーザが商品等を購入した店舗等の登録番号の欄６４１と、受付番号の欄６４２と、宅配要求の対象商品の商品名又は番号の欄６４３と、当該宅配要求の対象商品が特種品か否かを表す特種品フラグの欄６４４と、配送業者に対して集荷指示を送信したか否かを表す集荷指示済チェック（１は指示済み：０は未指示）の欄６４５と、集荷指示の年月日及び時刻の欄６４６と、配送業者から集荷完了通知を受信したか否かを表す集荷完了チェック（１は受信済み：０は未受信）の欄６４７と、集荷完了年月日及び時刻の欄６４８とが含まれる。
【００３８】
荷物管理テーブル格納部３７に格納される配送管理テーブルの一例を図８に示す。図８の例では、代表番号の欄８５１と、ユーザから購入完了指示を受信したか否かを表す購入完了指示チェック（１は受信済み：０は未受信）の欄８５２と、購入完了指示受付の年月日及び時刻の欄８５３と、梱包指示を配送業者に対して送信したか否かを表す梱包指示チェック（１は送信済み：０は未送信）の欄８５４と、梱包指示の年月日及び時刻の欄８５５と、配送業者から梱包物の発送済通知を受信したか否かを表す発送済チェックの欄８５６と、発送済通知受付の年月日及び時刻の欄８５７と、発送済通知に含まれる確定配送料の欄８５８と、配送完了通知を配送業者サーバ１５から受信したか否か表す配送完了チェック（１は受信済み：０は未受信）の欄８５９とが含まれる。
【００３９】
荷物管理テーブル格納部３７に格納される同梱見積テーブルの一例を図９に示す。図９の例では、箱サイズ１（縦、横、高さ）の欄６９０と、箱サイズ１に対する配送料１の欄６９１と、箱サイズ２（縦、横、高さ）の欄６９２と、箱サイズ２に対する配送料２の欄６９３と、．．．が含まれる。ここでは複数の購入商品の梱包に用いられる全ての種類の箱の定義を行う。
【００４０】
荷物管理テーブル格納部３７に格納される特種品配送料テーブルの一例を図１０に示す。第１の特種品の名称を格納する特種品１の欄６９４と、特種品１の配送料である料金１の欄６９５と、第２の特種品の名称を格納する特種品２の欄６９６と、特種品２の配送料である料金２の欄６９７とが含まれる。図１０に示したような冷凍品や規定外サイズの商品については、本実施の形態では他の購入商品と同梱されること無く、この特種品配送料テーブルの配送料がそのまま適用される。
【００４１】
ポイントＤＢ３８に格納されるデータ構造の一例を図１１に示す。図１１の例では、ユーザの場合にはユーザＩＤ、店舗等の場合には登録番号の欄５１０と、ポイントが付与された年月日及び時刻１の欄５１１と、年月日及び時刻１における付加ポイント数１の欄５１２と、．．．．ポイントが付与された年月日及び時刻ｎの欄５１３と、年月日及び時刻ｎにおける付加ポイント数ｎの欄５１４と、ユーザＩＤ又は登録番号の合計ポイント数の欄５１５とが含まれる。
【００４２】
以下図１２乃至図２９を用いて図２に示したシステムの処理フローを説明する。最初に、図１２を用いて処理の概要を示す。ユーザは、店舗において商品を購入して、本サービスを利用することを決心したものとする。そこでユーザは携帯電話機７等のユーザ端末を操作して、センタ・サーバ３が提供する宅配要求ページへアクセスする（ステップＳ１）。センタ・サーバ３の宅配要求受付処理部３１は、ユーザ端末からのアクセスに応答して、宅配要求ページ・データを送信する（ステップＳ３）。ユーザ端末は、センタ・サーバ３から宅配要求ページ・データを受信し、ウェブ(Ｗｅｂ）ブラウザ等により表示装置に表示する（ステップＳ５）。例えば図１３に示すような画面が表示される。図１３は、比較的大きな画面サイズを前提としているが、携帯電話機７等の場合にはこれらの情報を複数画面に分割して表示するようにしてもよい。図１３の例では、ユーザＩＤの入力欄８０１と、パスワードの入力欄８０２と、商品を購入した店舗の登録番号の入力欄８０３と、宅配希望商品名又は商品番号の入力欄８０４と、宅配希望商品サイズの縦サイズ入力欄８０５と、横サイズ入力欄８０６と、高さサイズ入力欄８０７と、送信ボタン８０８とが設けられている。なお、商品の種類がある程度特定される場合には、センタ・サーバ３に商品名又は商品番号に対応してサイズの情報を登録した商品マスタＤＢを設け、ユーザのサイズ入力ではなく当該商品マスタＤＢのデータを用いるようにしてもよい。
【００４３】
ユーザは、各入力欄にデータを入力し、送信ボタン８０８をクリックする。そうすると、ユーザ端末は、入力されたユーザＩＤ、パスワード、店舗の登録番号、商品名又は商品番号等の商品情報及びサイズを含む宅配要求をセンタ・サーバ３に送信する（ステップＳ７）。センタ・サーバ３の宅配要求受付処理部３１は、ユーザ端末から上記のような宅配要求を受信すると、受信ユーザＩＤ及びパスワード並びにユーザマスタＤＢ３５のデータを用いた認証処理及び宅配要求受付処理を実施する（ステップＳ９）。この宅配要求受付処理については、後に詳述する。センタ・サーバ３の宅配要求受付処理部３１は、配送料見積結果を含む宅配依頼受付ページ・データを生成して、ユーザ端末に送信する。ユーザ端末は、センタ・サーバ３から配送料見積結果を含む宅配依頼受付ページ・データを受信し、表示装置に表示する（ステップＳ１１）。
【００４４】
また、センタ・サーバ３の宅配要求受付処理部３１は、ユーザマスタＤＢ３５に格納された情報を用いてユーザＩＤ等のユーザ情報、代表番号及び追番を含む受付番号等を含むＩＣタグ情報を生成し、送信先を決定して当該ＩＣタグ情報を送信する（ステップＳ１３）。送信先は例えば携帯電話機７等のユーザ端末又は店舗に設置されたＩＣタグライタ９である。この決定は、例えばＩＣタグライタ９がネットワーク１に接続されているか、又はユーザ端末とＩＣタグライタ９が通信可能か等で判断される。なお、固定的にユーザ端末又はＩＣタグライタ９に送信するようにしてもよい。ユーザ端末が、センタ・サーバ３からＩＣタグ情報を受信した場合には、ＩＣタグ情報をＩＣタグライタ９に転送する（ステップＳ１５）。ＩＣタグライタ９は、センタ・サーバ３又はユーザ端末からＩＣタグ情報を受信すると、一旦記憶装置に格納し、ＩＣタグライタ９にセットされたＩＣタグにＩＣタグ情報を書き込む。また、ＩＣタグライタ９に接続された伝票プリンタ１１により配送伝票を印刷する（ステップＳ１７）。ユーザ情報に含まれる住所などの情報が配送伝票に印刷される。配送伝票は３通印刷され、１通はユーザの控え、１通は店舗の控え、１通は配送業者用である。
【００４５】
店舗の店員は、書き込みのなされたＩＣタグをユーザの購入商品又はその包装物に添付したり、印刷された配送伝票などを貼り付けるなど、店舗における梱包を実施する（ステップＳ１９）。
【００４６】
またセンタ・サーバ３の集荷関連処理部３２は、図７に示した集荷管理テーブルのレコードを新たに生成し、ユーザＩＤ、登録番号、受付番号、宅配要求に係る商品名又は商品番号、特種品フラグの設定、集荷指示済チェック及び集荷指示年月日及び時刻等の基礎情報を登録する（ステップＳ２１）。そして、ユーザＩＤ、登録番号、受付番号等を含む集荷指示を配送業者サーバ１５に送信する（ステップＳ２３）。配送業者サーバ１５は、センタ・サーバ３からユーザＩＤ、登録番号、受付番号等を含む集荷指示を受信し、記憶装置に格納する（ステップＳ２５）。配送業者は、受信した集荷指示の情報を用いて店舗への集荷を実施する（ステップＳ２７）。なお、集荷指示に応じて集荷を実施せずともよい。すなわち、配送業者の通常の集荷ルートに載っているような店舗であれば、当該集荷ルートで集荷してもよい。このような場合であっても、後に梱包を実施する必要があるので、集荷指示の情報については記憶装置に登録しておき、集荷後の梱包準備などに用いることができる。また、集荷指示に応じて直ぐに集荷を行わなくともよい。なお、集荷については後に他の実施の形態を説明する。
【００４７】
集荷が完了すれば、配送業者は集荷完了を、ＩＣタグからＩＣタグ情報を読み出すこと等により配送業者サーバ１５に登録する。そして、配送業者サーバ１５は、ＩＣタグ情報に含まれる受付番号等を含む集荷完了通知をセンタ・サーバ３に送信する（ステップＳ２９）。センタ・サーバ３の集荷関連処理部３２は、配送業者サーバ１５から受付番号等を含む集荷完了通知を受信すると、集荷管理テーブル（図７）の集荷完了チェックの欄６４７に１をセットし、集荷完了通知受信年月日及び時刻を集荷完了年月日及び時刻の欄６４８に登録する（ステップＳ３１）。
【００４８】
この後に購入完了処理、購入期限警告処理、購入期限超過処理、宅配依頼受付確認処理を実施する（ステップＳ３３）。これらの処理については後に詳細に説明する。
【００４９】
その後、センタ・サーバ３の梱包配送関連処理部３３が、梱包指示処理を実施し、ユーザ情報及び受付番号等の情報を含む梱包指示の情報を生成し、配送業者サーバ１５に送信する（ステップＳ３５）。なお、梱包指示処理において、配送管理テーブル（図８）の梱包指示チェックの欄８５４に１をセットし、梱包指示送信の年月日及び時刻を梱包指示年月日及び時刻の欄８５５に登録する。梱包指示処理については後に詳しく述べる。配送業者サーバ１５は、ユーザ情報及び受付番号等の情報を含む梱包指示情報を受信し、記憶装置に格納する（ステップＳ３７）。そして、配送業者は、梱包指示の情報及び購入商品に含まれるＩＣタグに書き込まれた情報を用いて、購入商品の梱包を実施する（ステップＳ３９）。なお、本実施の形態においては、梱包指示は配送指示の意味を含むものである。但し両者を別に指示するような構成でもよい。
【００５０】
この後の処理は図１４に移行する。梱包（ステップＳ３９）すると配送料が確定するため、配送業者は配送業者サーバ１５に確定配送料を入力し、記憶装置に格納する（ステップＳ４１）。また、代表番号及び確定配送料情報を含む発送済通知をセンタ・サーバ３に送信する（ステップＳ４３）。配送業者は、ユーザ指定の場所に梱包物を配送する（ステップＳ５０）。
【００５１】
センタ・サーバ３の梱包配送関連処理部３３は、代表番号及び確定配送料情報を含む発送済通知を受信し（ステップＳ４５）、配送管理テーブル（図８）の発送済チェックの欄８５６に１をセットし、発送済通知受信の年月日及び時刻を発送済通知受付年月日及び時刻の欄８５７並びに確定配送料の情報を確定配送料の欄８５８に登録する（ステップＳ４７）。この時点において、ユーザに対して確定配送料の通知を例えば電子メールにて送付してもよい（ステップＳ４９）。
【００５２】
配送業者は、配送が完了すると、配送業者サーバ１５に代表番号と配送完了年月日等の情報を入力する。そうすると、配送業者サーバ１５は当該情報を記憶装置に格納する。そして、配送業者サーバ１５は、代表番号を含む配送完了通知を生成し、センタ・サーバ３に送信する（ステップＳ５１）。センタ・サーバ３の梱包配送関連処理部３３は、配送業者サーバ１５から代表番号を含む配送完了通知を受信すると（ステップＳ５３）、配送管理テーブルの配送完了チェックの欄８５９に１をセットする（ステップＳ５５）。
【００５３】
その後ポイント管理部３４は、配送管理テーブル（図８）の配送完了チェックの欄８５９において１がセットされたレコードを読み出し、代表番号を取得し、宅配受付テーブル（図６）等から対応するユーザＩＤ及び登録番号を取得して、当該ユーザＩＤのユーザ及び登録番号の店舗に対して所定のポイントを付与する（ステップＳ５７）。ポイントについては、図１１に示したポイントＤＢ３８のデータ構造に従って、ポイント付加年月日及び時刻と付加ポイント値とを登録し、合計ポイント値を計算し直して登録する。
【００５４】
図１５乃至図１７を用いて宅配要求受付処理の詳細処理フローを説明する。センタ・サーバ３の宅配要求受付処理部３１は、ユーザ端末から、ユーザＩＤ、店舗の登録番号、商品情報及びサイズ等を含む宅配要求を受信する（ステップＳ６１）。図１３のような画面にユーザが情報を入力してユーザ端末が入力情報を送信してくる場合には、ＩＤ及びパスワードが宅配要求に含まれるので、ここでユーザマスタＤＢ３５に格納された情報を用いて認証処理を実施する。ここでは認証処理が成功したものとする。
【００５５】
宅配要求受付処理部３１は、宅配要求に含まれるユーザＩＤを用いて代表番号管理テーブル（図５）を検索し、当該ユーザＩＤが登録されており且つ状態フラグ＝０（購入完了状態ではない）のレコードを探す（ステップＳ６３）。もし、当該ユーザＩＤであり且つ状態フラグ＝０のレコードが見つからない場合には、最初の宅配要求であると判断して、代表番号管理テーブル（図５）に新規レコードを作成する（ステップＳ９５）。そして、当該新規レコードの指示開始時刻の欄５０３に現在時刻を記録する（ステップＳ９７）。また、当該新規レコードの期限時刻を現在時刻＋所定時間Ａ（例えば４時間）に設定し、期限時刻の欄５０４に記録する（ステップＳ９９）。さらに、当該新規レコードの延長フラグ、通知フラグ、状態フラグを全て０にセットして、代表番号管理テーブル（図５）の各欄に記録する（ステップＳ１０１）。さらに、新規代表番号を発番して、新規レコードの代表番号の欄５０１に記録する（ステップＳ１０３）。さらに、新規レコードを宅配受付テーブル（図６）に生成し（ステップＳ１０５）、受付番号（追番）を発番し、ユーザ端末から受信した情報等（ユーザＩＤ、受信年月日及び時刻、登録番号、対象商品名又は番号、特種品フラグなど）と共に新規レコードに記録する（ステップＳ１０７）。そして、配送料見積処理を実施する（ステップＳ１０９）。この配送料見積処理については後に説明する。そして配送料見積処理により生成された配送料見積結果と新規宅配受付メッセージを含む宅配依頼受付ページ・データを生成し、ユーザ端末に送信する（ステップＳ１１１）。
【００５６】
宅配依頼受付ページの画面例を図１６に示す。図１６の例では、ユーザＩＤの表示欄８１０と、代表番号の表示欄８１１と、梱包個数の表示欄８１２と、宅配商品数の表示欄８１３と、宅配料金（配送料）の表示欄８１４と、確認メッセージの表示欄８１５と、残り時間表示部分８１６とが含まれる。新規宅配受付メッセージとして、確認メッセージの表示欄８１５に例えば「新規に宅配依頼を受け付けました。」といったメッセージが含まれるものである。なお、図１６には、「店舗が集荷範囲を超えます。別口になります。」といったメッセージ例が示されている。
【００５７】
一方、代表番号管理テーブル（図５）に受信ユーザＩＤであり且つ状態フラグ＝０のレコードが存在していると判断された場合には、追加の商品宅配要求がなされたことが確認される。次に、今回の宅配要求に係る商品が特種品等の同梱基準を満たさない商品であったり、商品購入店舗が通常の集荷範囲の外にあるか（店舗マスタＤＢ３６（図４）の集荷範囲フラグ７０７が０の店舗であるか）を判断する（ステップＳ６５）。
【００５８】
もし、特種品等の同梱基準を満たさない商品について宅配要求がなされた場合には、ここでは別途個別配送するようにする。また店舗が通常の集荷範囲の外である場合にも同様である。従って、代表番号管理テーブル（図５）に新規レコードを生成し（ステップＳ７９）、当該新規レコードの指示開始時刻の欄５０３及び期限時刻の欄５０４に現在時刻を記録する（ステップＳ８１）。さらに、当該新規レコードの延長フラグ、通知フラグ、状態フラグを全て１にセットして、代表番号管理テーブル（図５）の各欄に記録する（ステップＳ８３）。さらに、新規代表番号を発番して、新規レコードの代表番号の欄５０１に記録する（ステップＳ８５）。さらに、新規レコードを宅配受付テーブル（図６）に生成し（ステップＳ８７）、受付番号（追番）を発番し、ユーザ端末から受信した情報（ユーザＩＤ、受信年月日及び時刻、登録番号、対象商品名又は番号、特種品フラグなど）と共に新規レコードに記録する（ステップＳ８９）。そして、配送料見積処理を実施する（ステップＳ９１）。この配送料見積処理については後に説明する。そして配送料見積処理により生成された配送料見積結果と別口メッセージを含む宅配依頼受付ページ・データを生成し、ユーザ端末に送信する（ステップＳ９３）。別口メッセージは、図１６に示すような「店舗が集荷範囲を超えます。別口になります。」や「特種品です。別口になります。」といったメッセージである。
【００５９】
なお、本実施の形態では宅配要求に係る商品が特種品であったり、当該商品の購入店舗が通常の集荷の範囲外である場合に、別口配送となるような構成とした。しかし、本発明はこれに限定されず、例えば冷凍品ならば冷凍品を一括梱包及び配送し、通常の商品は通常の商品ごとに一括梱包及び配送するような構成であってもよい。この場合には、受信ユーザＩＤ且つ状態フラグ＝０のレコードが複数検出されるので、いずれの梱包に関連する商品についての宅配要求なのかを判別し、そのための情報を代表番号管理テーブル（図５）等に用意する必要がある。
【００６０】
ステップＳ６５において商品及び店舗が規定外ではないと判断された場合には、該当する代表番号を代表番号管理テーブル（図５）から識別する（ステップＳ６７）。そして、代表番号が一致する宅配受付テーブル（図６）内のレコードを識別し、新規レコードを生成する（ステップＳ６９）。そして、代表番号が一致するレコードを元に受付番号（追番）を発番し、ユーザ端末からの受信情報（ユーザＩＤ、受信年月日及び時刻、登録番号、対象商品名又は番号、特種品フラグなど）と共に新規レコードに登録する（ステップＳ７１）。そして、配送料見積処理を実施する（ステップＳ７３）。この配送料見積処理については後に説明する。そして、残り時間を代表番号管理テーブル（図５）の指示開始時刻と期限時刻との差にて算出する（ステップＳ７５）。そして、残り時間及び配送料見積処理結果を含む宅配依頼受付ページ・データを生成し、ユーザ端末に送信する（ステップＳ７７）。追加の宅配要求については、あとどの程度宅配要求を受け付けるのかをユーザに知らせるために、図１６の例における残り時間の表示欄８１６が設けられている。ステップＳ９３、ステップＳ７７又はステップＳ１１１の後に元の処理に戻る。
【００６１】
このようにすることにより、新規の宅配要求、追加の宅配要求、及び宅配要求に係る商品又は店舗が規定外のケースに対処することができるようになる。
【００６２】
次に図１７を用いて配送料見積処理について説明する。最初に、今回購入商品の寸法が本サービスで準備した箱より大きいか又は店舗又は商品が規定外のものかを判断する（ステップＳ１１５）。大きすぎたり、冷凍品であったり、店舗が通常の集荷範囲外にある場合等は、同梱することができないため、別口扱いとなる。従って、ステップＳ１１５における条件を満たすと判断されると、冷凍品や大きすぎる商品の場合には特種品配送料テーブル（図１０）に従って単純に配送料を計算し、店舗が通常の集荷範囲外であるような場合には図示しない通常取り扱い配送料テーブルを用いて配送料を計算する（ステップＳ１１７）。
【００６３】
一方、同梱取り扱いできる商品及び通常の集荷範囲内の店舗である場合には、これまでの全購入商品が一番小さい箱に入るかを判断する（ステップＳ１１７）。この判断にはユーザ端末から送信されてくる商品のサイズ情報が用いられる。もし、全購入商品が一番小さい箱に入る場合には、その箱の大きさ及び自宅（又はユーザ指定の場所）までの距離に応じて料金計算を実施する（ステップＳ１１９）。その際に、同梱見積テーブル（図９）を用いる。図９の例では、距離のデータは示されていないが、距離の情報も考慮する。但し、大きさだけで配送料が確定されるようにしてもよい。
【００６４】
一方、一番小さな箱に入らない場合には、次の大きさの箱に全購入商品が入るか判断する（ステップＳ１２１）。もし、入るようであればステップＳ１１９に移行して、その箱の大きさ及び自宅等までの距離に応じた料金計算を実施する。
【００６５】
もしステップＳ１２１にて全購入商品が箱に入らないと判断された場合には、次に選べる大きさの箱があるか判断する（ステップＳ１２３）。もし、そのような箱が準備されている場合にはステップＳ１２１に戻る。一方、もう次に選べる大きさの箱が無い場合には、ひとつの箱で梱包できなくなったことを示す。従ってとりあえず一番大きい箱に入るだけ入れたとして、箱の大きさ及び自宅等までの距離に応じた配送料の計算を実施する（ステップＳ１２５）。また、箱の数（初期値１）を１インクリメントする。そして、現在の箱に詰められるだけ詰めた場合に入らない商品を特定する（ステップＳ１２７）。そして、一番小さい新たな箱を選択する（ステップＳ１２９）。
【００６６】
そしてステップＳ１２７において特定された購入商品がステップＳ１２９で選択した箱に入るか判断する（ステップＳ１３１）。もし入るようであれば、新たな箱の大きさ及び自宅等までの距離に応じた配送料を計算し、前に計算された別の箱の配送料に加算する（ステップＳ１３５）。一方、ステップＳ１２７で特定された購入商品が今回の箱に入らないようであれば次の大きさの箱に入るか判断する（ステップＳ１３３）。もし、入るようであれば、当該箱の大きさ及び自宅等までの距離に応じた配送料を計算し、前に計算された別の箱の配送料に加算する（ステップＳ１３５）。もし、ステップＳ１３３で次の大きさの箱に入らないと判断された場合には、次に選べる大きさの箱が存在しているか判断する（ステップＳ１３７）。もし、まだ次の大きさの箱が準備されているようであればステップＳ１３３に戻る。一方、次に選べる大きさの箱がもうない場合にはステップＳ１２５に戻る。すなわち、再度最も大きい箱がいっぱいになったことを意味するので、当該箱の配送料を計算しておく。また、箱の数を１インクリメントする。そして梱包できていない購入商品の配送料の計算を上で述べたように実施する。
【００６７】
このような処理を実施することにより、より少ない口数で配送料を計算できるため、ユーザには大きなコストメリットが発生する。
【００６８】
上で述べたように、ユーザは、複数の店舗等で商品の購入を実施することができる。すなわち、図１２のステップＳ１乃至ステップＳ３１までが繰り返される。
【００６９】
本実施の形態では、図１５のステップＳ９９で設定されるように所定時間Ａだけ宅配要求を受け付けるようになっている。これは、配送業者における購入商品の集荷、管理、梱包、配送の手数を考慮して決定されるものである。但し、所定時間Ａについては延長可能として、ユーザのショッピングなどの都合に合わせることも可能である。延長に関しては１回の延長で所定時間Ｄだけ延長するようにしているが、延長の回数制限を設ける場合もある。本実施の形態では１回のみ延長できるようになっている。
【００７０】
次に、最初の宅配要求時刻である指示開始時刻（図５：指示開始時刻の欄５０３に格納された時刻）から時間が経過した場合の処理を説明する。最初に、宅配要求を受け付ける期限時刻が迫っていることをユーザに通知するための購入期限警告通知処理について図１８を用いて説明する。梱包配送関連処理部３３は、代表番号管理テーブル（図５）の第１レコードを読み出す（ステップＳ１４１）。そして、当該レコードの通知フラグが０（警告未通知）であるか判断する（ステップＳ１４３）。もし、通知フラグが１であれば、次のレコードを代表番号管理テーブルから読み出して（ステップＳ１５３）、ステップＳ１４３に戻る。
【００７１】
一方、梱包配送関連処理部３３は、通知フラグが０であれば、現在時刻が当該レコードに含まれる期限時刻の所定時間Ｂ（例えば１０分）前以降であるかを確認する（ステップＳ１４５）。例えば期限時刻が１８：００であれば１７：５０以降になっているかを確認する。もし、現在時刻が期限時刻の所定時間Ｂ前に達していない場合には、ステップＳ１５３に移行する。一方、現在時刻が期限時刻の所定時間Ｂ前以降である場合には、購入期限時刻の警告通知を例えば電子メールで送信する（ステップＳ１４７）。電子メール・アドレスは、ユーザマスタＤＢ３５（図３）から取得する。その他ユーザの携帯電話機７等に電話をかけるようにしても良い。そして、代表番号管理テーブル（図５）の通知フラグを１にセットする（ステップＳ１４９）。そしてステップＳ１５３に戻る。なお、ステップＳ１５３において次のレコードがない場合には第１のレコードに戻る。
【００７２】
このようにして常に購入期限時刻の警告通知を行っていないレコードのうち期限時刻の所定時間Ｂ前以降となったレコードを探し出して、当該レコードに関連するユーザに対して購入期限時刻の警告通知を実施する。
【００７３】
次に、ショッピングの終了時にユーザが自主的に購入完了をセンタ・サーバ３に通知する場合の処理フローを図１９乃至図２３を用いて説明する。携帯電話機７等のユーザ端末は、ユーザの指示に応じて購入完了指示ページにアクセスする（ステップＳ１５１）。センタ・サーバ３の梱包配送関連処理部３３は、アクセスに応じて購入完了ページ・データをユーザ端末に送信する（ステップＳ１５３）。ユーザ端末は、センタ・サーバ３から購入完了ページ・データを受信し、表示装置に表示する（ステップＳ１５５）。例えば、図２０に示すような画面が表示される。図２０の例では、ユーザＩＤの入力欄８２０と、パスワードの入力欄８２１と、購入完了ボタン８２２とが設けられている。
【００７４】
ユーザは、ユーザ端末を操作してユーザＩＤ及びパスワードを入力し、購入完了ボタン８２２をクリックする。そうすると、ユーザ端末は、ユーザＩＤ及びパスワードを含む購入完了通知をセンタ・サーバ３に送信する（ステップＳ１５７）。センタ・サーバ３の梱包配送関連処理部３３は、ユーザ端末からユーザＩＤ及びパスワードを含む購入完了通知を受信すると、当該ユーザＩＤ及びパスワード並びにユーザマスタＤＢ３５に格納された情報を用いて認証処理を実施する（ステップＳ１５９）。認証処理自体は従来と変わらないので説明は省略し、ここでは認証処理が成功したものとする。
【００７５】
またユーザＩＤを用いて代表番号管理テーブル（図５）を検索し、代表番号管理テーブルに受信ユーザＩＤ且つ状態フラグ＝０（０は購入完了又は自動購入完了処理未実施）であるレコードが存在しているか判断する（ステップＳ１６１）。もし、存在しなければエラー通知をユーザ端末に送信する。ユーザ端末は、センタ・サーバ３からエラー通知を受信し、表示装置に表示する（ステップＳ１６３）。
【００７６】
一方、受信ユーザＩＤ且つ状態フラグ＝０であるレコードが存在する場合には、当該レコードの代表番号を有する全レコードを宅配受付テーブル（図６）から読み出す（ステップＳ１６５）。そして、読み出したレコードの情報を用いて配送料見積処理（図１７）を実施する（ステップＳ１６７）。そして、配送料見積結果を含む宅配依頼受付確認ページ・データを生成し、ユーザ端末に送信する（ステップＳ１６９）。ユーザ端末は、宅配依頼受付確認ページ・データを受信し、Ｗｅｂブラウザにより表示装置に表示する（ステップＳ１７１）。
【００７７】
宅配依頼受付確認ページ・データの一例を図２１に示す。図２１の例では、ユーザＩＤの表示欄９０１、代表番号の表示欄９０２、店舗名の表示欄９０３、店舗の登録番号の表示欄９０４、受付年月日及び時刻の表示欄９０５、商品名の表示欄９０６、個数の表示欄９０７、配送料の表示欄９０８、宅配依頼受付内容の確認を指示するためのＹＥＳボタン９０９、宅配依頼の修正ボタン９１０、購入期限の延長ボタン９１１、購入期限までの残り時間表示欄９１２などが含まれる。なお、ユーザが自主的に購入完了指示を行う場合には延長の可能性は無いので、ステップＳ１７１で表示される宅配依頼受付確認ページにおいては延長ボタン９１１は含まれない。
【００７８】
ユーザは、表示された宅配依頼受付確認ページの内容を確認する。もし、問題があれば「問い合わせ先」に電話をかけても良い。問題が無ければＹＥＳボタン９０９をクリックし、修正を画面上で行う場合には修正ボタン９１０をクリックする。ユーザ端末は、ユーザによるクリックに従って応答をセンタ・サーバ３に送信する（ステップＳ１７３）。センタ・サーバ３の梱包配送関連処理部３３は、ユーザ端末から応答を受信し（ステップＳ１７５）、当該応答が確認応答であるかを判断する（ステップＳ１７７）。もし、確認応答ではなく、修正応答である場合には端子Ａを介して図２３に移行する。一方、確認応答であれば、梱包及び配送を開始する旨のメッセージを含む受付完了ページ・データを送信する（ステップＳ１７９）。ユーザ端末は、センタ・サーバ３から受付完了ページ・データを受信し、表示装置に表示する（ステップＳ１８１）。そして、配送業者への梱包指示情報を生成し、配送業者サーバ１５に送信する（ステップＳ１８３）。例えば図２２のような情報が梱包指示情報として送信される。図２２の例では、ユーザＩＤの欄８７１と、氏名の欄８７２と、住所の欄８７３と、電話番号の欄８７４と、購入店舗の登録番号の欄８７５と、受付番号の欄８７６と、宅配要求の受付商品又は番号の欄８７７と、特種品フラグの欄８７８とが含まれる。配送業者サーバ１５は、センタ・サーバ３から梱包指示情報を受信すると、記憶装置に格納する。配送業者は、この梱包指示情報と、集荷指示情報、ＩＣタグから読み取られた情報をマッチングさせて、適切に梱包を行い、当該梱包物を配送する。
【００７９】
また、センタ・サーバ３の梱包配送関連処理部３３は、代表番号管理テーブルにおいて当該レコードの状態フラグ及び通知フラグを１に設定する。なお、通知フラグについては既に１にセットされている場合もあるが、その場合にはそのままにする。また、配送管理テーブル（図８）に新規レコードを生成する（ステップＳ１８５）。新規レコードには、当該代表番号を登録し、購入完了指示チェックを１にセットし、購入完了指示を受信した年月日及び時刻の情報を記録する。また、梱包指示チェックを１にセットし、梱包指示を送信した年月日及び時刻の情報を記録する。
【００８０】
次に、ユーザ端末から受信した応答が修正応答である場合の処理について図２３を用いて説明する。処理は図１９から端子Ａを介して図２３に移行する。この場合、梱包配送関連処理部３３は、修正すべき宅配要求についての情報を指示可能とした修正用ページ・データを生成し、ユーザ端末に送信する（ステップＳ１８７）。ユーザ端末は、センタ・サーバ３から修正用ページ・データを受信し、表示装置に表示する（ステップＳ１８９）。ユーザは、表示された修正用ページを見て、適切な修正指示を入力し、当該修正指示の送信を命ずる。ユーザ端末は、指示に従って、修正指示情報をセンタ・サーバ３に送信する（ステップＳ１９１）。センタ・サーバ３の梱包配送関連処理部３３は、ユーザ端末から修正指示を受信すると、修正指示に従って宅配受付テーブル（図６）を修正する（ステップＳ１９３）。そして、端子Ｂを介して図１９のステップＳ１６７に戻る。
【００８１】
このようにしてユーザによる購入完了指示に従って梱包・配送が行われるようになる。また、宅配依頼受付確認ページで宅配要求の内容を確認でき、修正が必要な場合には修正を指示することもできる。
【００８２】
次に、ユーザが自発的に購入完了指示を行わずに宅配要求受付の期限時刻に達した場合の処理について図２４を用いて説明する。梱包配送関連処理部３３は、代表番号管理テーブル（図５）の第１レコードを読み出す（ステップＳ２０１）。そして、当該レコードの状態フラグが０（購入完了又は自動購入完了処理未了）であるか確認する（ステップＳ２０３）。もし、状態フラグ＝０ではない場合、すなわち状態フラグ＝１である場合には、次のレコードを読み出す（ステップＳ２０５）。そしてステップＳ２０３に戻る。
【００８３】
状態フラグ＝０である場合には、現在時刻が当該レコードの期限時刻以降になっているか確認する（ステップＳ２０７）。もし、現在時刻が期限時刻より前である場合にはステップＳ２０５に移行する。一方、現在時刻が期限時刻以降である場合には、代表番号管理テーブルの当該レコードの状態フラグを１に設定する（ステップＳ２０９）。すなわち、自動的に購入完了指示がなされたことにして、宅配要求の受付を締め切る。そして、制限時刻超過による自動購入完了の通知を当該代表番号に対応するユーザに対して例えば電子メールで送信する（ステップＳ２１１）。例えば、「制限時刻までに購入完了通知を受け取りませんでしたので、自動的に締め切りました」といったメッセージを含む通知を行う。電子メール・アドレスなどのユーザへの通知先についてはユーザマスタＤＢ３５に格納された情報を用いる。ステップＳ２１１の後にステップＳ２０５に戻る。なお、ステップＳ２０５で次のレコードがない場合には第１レコードに戻るようにする。
【００８４】
これにより次に述べる梱包指示処理が自動的に行われるようになり、配送業者による梱包及び配送が開始される。図２５を用いて梱包指示処理について説明する。最初に、梱包配送関連処理部３３は、代表番号管理テーブルの第１レコードを読み出す（ステップＳ２１３）。そして、当該レコードの状態フラグが１であるか判断する（ステップＳ２１５）。すなわち、購入完了が設定されたか否かを確認する。もし、状態フラグ＝０であれば次のレコードを読み出し（ステップＳ２１７）、ステップＳ２１５に移行する。
【００８５】
一方、状態フラグ＝１の場合には、現在時刻が期限時刻から所定時間Ｃ（例えば５分）経過した時刻以降であるか確認する（ステップＳ２１７）。所定時間Ｃは期限時刻経過後ユーザによる延長指示を受け付ける時間である。なお、延長指示を受け付けない場合には現在時刻が期限時刻を経過したかを確認すればよい。もし、現在時刻が期限時刻から所定時間Ｃ経過した時刻より前の場合にはステップＳ２１７に移行する。
【００８６】
もし、現在時刻が期限時刻から所定時間Ｃ経過した時刻より遅い場合には、配送業者への梱包指示情報（図２２）を生成し、配送業者サーバ１５に送信する（ステップＳ２１９）。そして、配送管理テーブル（図８）に新規レコードを生成し、当該代表番号を登録し、購入完了指示チェックを１にセットし、購入完了指示を受信した年月日及び時刻の情報を記録する。また、梱包指示チェックを１にセットし、梱包指示を送信した年月日及び時刻として本処理時の時刻の情報を記憶する（ステップＳ２２１）。そしてステップＳ２１７に移行する。ステップＳ２１７では、次のレコードがなければ第１レコードを読み出す。
【００８７】
ユーザは、任意の時間に自己の宅配要求の確認を行うことができる。例えば、購入期限時刻の警告通知や自動購入完了の通知の電子メールには、宅配依頼受付確認ページへのリンクを含めておく。ユーザは、当該リンクを選択することにより、宅配依頼受付確認ページにアクセスすることができる。その他、センタ・サーバ３のメインメニューから辿って宅配依頼受付確認ページに遷移するようにしてもよい。なお、宅配依頼受付確認ページの内容は、アクセスのタイミングにより異なる。以下、購入完了指示に伴って宅配依頼受付確認ページが表示される場合を除き、宅配依頼受付確認ページにアクセスする際の処理について図２６乃至図２８を用いて説明する。
【００８８】
携帯電話機７等のユーザ端末は、ユーザの指示に従って、宅配依頼受付確認ページへアクセスする（ステップＳ２３１）。センタ・サーバ３の梱包配送関連処理部３３は、ユーザ端末から宅配依頼受付確認ページへのアクセスを受信する（ステップＳ２３３）。梱包配送関連処理部３３は、アクセスに応じてユーザＩＤ及び代表番号を識別する（ステップＳ２３５）。例えば購入期限時刻の警告通知や自動購入完了の通知に含まれるリンク・アドレスがユーザＩＤと代表番号の組み合わせにて構成されているような場合には、この情報を用いればよい。また、このページへのアクセスまでにユーザＩＤ及び代表番号が入力されていれば、その情報を用いる。なお、ユーザＩＤで代表番号管理テーブル（図５）を検索し、代表番号を抽出しても良い。認証処理を実施するような場合もある。
【００８９】
次に、代表番号で代表番号管理テーブルを検索して該当レコードを読み出し、現在時刻が当該レコードの期限時刻から所定時間Ｃ経過した時刻以降になっているか確認する（ステップＳ２３７）。すなわち、延長可能な時刻を経過したか否かを判断する。もし、現在時刻が制限時刻から所定時間Ｃ経過した時刻以降であれば、端子Ｆを介して図２７の処理に移行する。一方、現在時刻が制限時刻から所定時間Ｃ経過した時刻より前であれば、延長フラグが０であるか判断する（ステップＳ２３９）。延長フラグ＝０は、まだ一度も購入期限を延長したことがないということである。本実施の形態では延長は１回のみであり、既に一度延長している場合には端子Ｇを介して図１９のステップＳ１６５に移行する。すなわち、現在時刻は延長可能な時間ではあるが、既に一度延長していてもう延長できないので、延長を指示できないような宅配依頼受付確認ページを表示するようにする。これは、ユーザにより購入完了指示が行われた場合と同じである。
【００９０】
一方、延長フラグ＝０である場合には、当該代表番号に関係する宅配受付テーブル（図６）の全レコードの情報を読み出し（ステップＳ２４１）、配送料見積処理（図１７）を実施する（ステップＳ２４３）。そして、配送料見積結果及び残り時間（＝期限時刻−現在時刻）を含む宅配依頼受付確認ページ・データ（図２１）を生成し、ユーザ端末に送信する（ステップＳ２４５）。ユーザ端末は、宅配依頼受付確認ページ・データを受信し、表示装置に表示する（ステップＳ２４７）。ステップＳ２４７において表示される宅配依頼受付確認ページには、ＹＥＳボタン９０９、修正ボタン９１０、延長ボタン９１１とが設けられている。従って、ユーザは、確認応答、修正応答、延長応答を指示することができる。
【００９１】
ユーザ端末は、ユーザの指示に従って応答をセンタ・サーバ３に送信する（ステップＳ２４９）。センタ・サーバ３の梱包配送関連処理部３３は、ユーザ端末から応答を受信し（ステップＳ２５１）、確認応答であるか判断する（ステップＳ２５３）。確認応答であれば、端子Ｃを介して図１９のステップＳ１７９に移行する。一方、確認応答でなければ延長応答であるか判断する（ステップＳ２５５）。延長応答であれば端子Ｅを介して図２８の処理に移行する。一方、延長応答でなければ修正応答であり、この場合には端子Ｈを介して図２３の処理に移行する。なお、図２３において端子Ｈから遷移してきた場合には、端子Ｄを介して図２６のステップＳ２４３に戻る。
【００９２】
次に、端子Ｆを介して図２６のステップＳ２３７から遷移した場合の処理を図２７を用いて説明する。梱包配送関連処理部３３は、まず配送業者サーバ１５から確定配送料を受信したか判断する（ステップＳ２６１）。もし配送業者サーバ１５から確定配送料を受信していれば、配送管理テーブル（図８）に確定配送料が登録されている（発送済チェックが１である）ので、それにより判断することができる。もし、確定配送料を受信していれば、当該代表番号に関係する宅配受付テーブル（図６）の全レコードの情報を読み出す（ステップＳ２６７）。また、配送管理テーブル（図８）から確定配送料の情報を読み出す（ステップＳ２６９）。
【００９３】
一方、確定配送料を受信していない場合には、当該代表番号に関連する宅配受付テーブル（図６）の全レコードの情報を読み出し（ステップＳ２６３）、配送料見積処理（図１７）を実施する（ステップＳ２６５）。
【００９４】
そして、ステップＳ２６５又はステップＳ２６９の後に、宅配受付テーブル（図６）の関連する全レコードの情報及び配送料見積結果又は確定配送料の情報を含む宅配依頼受付確認ページ・データを生成し、ユーザ端末に送信する（ステップＳ２７１）。ユーザ端末は、センタ・サーバ３から宅配依頼受付確認ページ・データを受信し、表示装置に表示する（ステップＳ２７３）。このステップＳ２７３において表示される宅配依頼受付確認ページには、修正ボタン９１０、延長ボタン９１１は無い。この段階においては既に梱包指示を配送業者サーバ１５に送信してしまっているので、修正も延長も不可能な状態にある。従って、本ステップにおいてはそのためのボタンが表示されないようになっている。従って、ユーザが指示する応答は、確認応答しかない。ユーザが、ＹＥＳボタン９０９をクリックすると、ユーザ端末は応答をセンタ・サーバ３に送信する（ステップＳ２７５）。センタ・サーバ３は、ユーザ端末から応答を受信する（ステップＳ２７７）。これ以上の処理は、例えば他のメニュー画面に遷移するような構成であっても良い。
【００９５】
次に、図２８を用いて図２６のステップＳ２５５で延長応答であると判断された場合の処理を説明する。この処理は端子Ｅを介して図２８に遷移している。最初に梱包配送関連処理部３３は、代表番号管理テーブル（図５）の当該代表番号のレコードについて期限時刻を現在の期限時刻＋所定時間Ｄ（例えば１時間）の時刻に更新する（ステップＳ２８１）。また、当該レコードの延長フラグを１にセットし、状態フラグ及び通知フラグを０に設定する（ステップＳ２８３）。そして、延長了承ページ・データを生成し、ユーザ端末に送信する（ステップＳ２８５）。ユーザ端末は、センタ・サーバ３から延長了承ページ・データを受信し、表示装置に表示する（ステップＳ２８７）。
【００９６】
このようにして期限時刻の延長が行われ、ユーザはショッピングを継続して追加の宅配要求を送信することができるようになる。なお、状態フラグ＝０であるから、再度購入完了又は自動購入完了処理が必要になる。また、通知フラグ＝０であるから、新たな期限前に再度通知を受けることができる。
【００９７】
以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。特に、集荷指示処理については、単純に宅配要求をユーザ端末から受信する毎に実施しても良いが、図２９のような処理を実施するようにしても良い。
【００９８】
すなわち、集荷関連処理部３２は、店舗マスタＤＢ３６を参照して商品購入店舗がグループ登録されているか判断する（ステップＳ２９１）。すなわち、店舗マスタＤＢ３６の集荷グループの欄７０９にグループ番号が登録されているかを判断する。もし、登録されていない場合には、直ぐに集荷指示を生成して、配送業者サーバ１５に送信する（ステップＳ３０７）。そして、集荷管理テーブル（図７）の集荷指示チェックを１にセットし、送信年月日及び時刻を登録する（ステップＳ３０９）。そして元の処理に戻る。
【００９９】
一方、グループ登録されている店舗である場合には、商品購入店舗がアンテナ店であるか判断する（ステップＳ２９３）。店舗マスタＤＢ３６（図４）のアンテナ店の集荷基準の欄７０８に何らかの数字が登録されているかで判断する。もし、アンテナ店でなければ、ステップＳ３０３に移行する。一方、アンテナ店であれば、集荷管理テーブル（図７）を商品購入店舗の登録番号で検索して、集荷基準データを取得する（ステップＳ２９５）。そして、購入数が当該商品購入店舗の集荷基準を超えたか判断する（ステップＳ２９７）。なお、集荷指示済チェックが０であるレコードのみカウントする。もし集荷管理テーブル（図７）において購入数が集荷基準を超えていない場合にはステップＳ３０３に移行する。
【０１００】
もし集荷管理テーブルにおいて購入数が集荷基準を超えている場合には、当該アンテナ店と同一グループに属する店舗の購入商品を、集荷管理テーブルから抽出する。この際集荷指示済チェックが０であるレコードのみを抽出する。そして、抽出された購入商品に係る集荷指示の情報を生成し、配送業者サーバ１５に送信する（ステップＳ２９９）。集荷管理テーブルにおいて集荷指示に係るレコードの集荷指示済フラグを１にセットし、集荷指示送信の年月日及び時刻を登録する（ステップＳ３０１）。そして元の処理に戻る。
【０１０１】
なお、アンテナ店において集荷基準に達しないと集荷指示を出さないということにすると、何日か集荷がなされない場合も生じ得るので、本実施の形態ではステップＳ２９３でアンテナ店ではないと判断された場合及びアンテナ店で購入数が集荷基準を超えない場合、所定の時刻において、集荷指示を出していない購入商品（集荷指示済チェックが０）を集荷管理テーブルから抽出し、抽出した購入商品についての集荷指示の情報を生成し、配送業者サーバ１５に送信する（ステップＳ３０３）。そして、集荷管理テーブルにおいて集荷指示に係るレコードの集荷指示済チェックを１にセットし、集荷指示送信の年月日及び時刻を登録する（ステップＳ３０５）。そして元の処理に戻る。
【０１０２】
また、上では必ず店舗に配送業者が集荷に行くことを前提としているが、近年配送業者が自己の倉庫に複数の店舗の商品をストックしておき、その倉庫から顧客に対して配送するような場合もあるため、本発明においてもこのような構成をそのまま適用することができる。その際には、センタ・サーバ３から集荷指示をそのまま配送業者サーバ１５に送信し、配送業者サーバ１５において倉庫からピッキングするような商品であるか否かを判断するようにすればよい。
【０１０３】
また、上では店舗が通常の集荷範囲外である場合及び商品が特種品又は過大サイズの場合に、別口配送するような構成を示したが、これらをさらに分類して配送の仕方を変えるようにしても良い。
【０１０４】
さらに図２のシステム概要図における機能ブロックは一例であり、実際のプログラムのモジュールを別の態様にて分けることも可能である。また、データの格納態様についても図２に示したような分け方でなくとも良い。図１３、図１６、図２０、図２１の画面例の画面構成は一例であって、これに限定されず、同様の内容を表示するものであればよい。上でも述べたが各画面は複数の画面に分割して提示される場合もある。
【０１０５】
ＩＤの入力を求める画面例を示しているが、ユーザＩＤの入力については、サブスクライバＩＤやＩＰｖ６のアドレスにより省略される場合もある。ユーザＩＤ入力欄についてはユーザＩＤが埋め込まれた状態でＷｅｂページ・データが生成・送信・表示される場合もある。
【０１０６】
なお、上で述べた例では配送業者が１社であるような例を示しているが、複数の配送業者が連携する場合もあり得る。また、別の交通機関、例えばタクシー等を本発明の集荷処理部分に組み込むような場合もあり得る。
【０１０７】
（付記１）
ユーザの端末から購入商品の購入店舗からの配送の要求を受信した場合、当該配送の要求に関する情報を記憶装置に格納する配送要求受信ステップと、
前記ユーザの端末から購入完了指示を受信した場合、当該ユーザの端末から前記購入完了指示受信までに受信された前記配送の要求に係る全購入商品のうち所定の条件に合致した購入商品の梱包指示を配送業者に対して送信する梱包指示送信ステップと、
を含む配送情報処理方法。
【０１０８】
（付記２）
前記ユーザの端末から最初の配送の要求を受信してから所定時間経過したにもかかわらず購入完了指示を受信しない場合、前記ユーザの端末から前記所定時間経過までに受信された前記配送の要求に係る全購入商品のうち所定の条件に合致した購入商品の梱包指示を配送業者に対して送信する梱包指示送信ステップ、
をさらに含む付記１記載の配送情報処理方法。
【０１０９】
（付記３）
前記ユーザの端末から前記所定時間の延長要求を受信した場合には、前記所定時間の延長を記憶装置に設定するステップ
をさらに含む付記２記載の配送情報処理方法。
【０１１０】
（付記４）
前記ユーザの端末から最初の配送の要求を受信してから所定時間経過したにもかかわらず購入完了指示を受信しない場合、前記ユーザに対して配送の要求の受付完了を通知するステップ、
をさらに含む付記２記載の配送情報処理方法。
【０１１１】
（付記５）
前記所定時間経過前の所定のタイミングにて、前記ユーザに対して配送の要求の受付完了を予告するステップ、
をさらに含む付記２記載の配送情報処理方法。
【０１１２】
（付記６）
前記ユーザの端末から要求に応じて、前記記憶装置に格納された前記配送の要求に関する情報を用いて配送料の見積りを実施し、当該配送料の見積りの情報を前記ユーザの端末に送信するステップ
をさらに含む付記１乃至５のいずれか１つ記載の配送情報処理方法。
【０１１３】
（付記７）
前記ユーザの端末から購入商品の購入店舗からの配送の要求を受信した場合、当該購入商品の集荷指示を配送業者のコンピュータに送信するステップ
をさらに含む付記１乃至６のいずれか１つ記載の配送情報処理方法。
【０１１４】
（付記８）
前記梱包指示に、前記ユーザにより指示された配送先の情報を含む
ことを特徴とする付記１乃至７のいずれか１つ記載の配送情報処理方法。
【０１１５】
（付記９）
前記ユーザの端末から購入商品の購入店舗からの配送の要求を受信した場合、当該購入商品の配送業者による少なくとも梱包に用いるための情報を前記ユーザの端末又は前記購入店舗のコンピュータに送信するステップ、
をさらに含む付記１乃至８のいずれか１つ記載の配送情報処理方法。
【０１１６】
（付記１０）
前記所定の条件が、前記購入店舗が予め特定された店舗以外の店舗であること又は前記購入商品が予め特定された商品以外の商品であること
であることを特徴とする付記１乃至９のいずれか１つ記載の配送情報処理方法。
【０１１７】
（付記１１）
前記配送業者における梱包により確定した配送料の情報を受信した場合、当該確定した配送料の情報を前記ユーザに対して通知するステップ
をさらに含む付記１乃至１０のいずれか１つ記載の配送情報処理方法。
【０１１８】
（付記１２）
特定の購入店舗からの配送の要求をユーザの端末から所定数以上受信した場合に、前記特定の購入店舗及び当該特定の購入店舗に関連付けられた店舗についての購入商品の集荷要求を配送業者に対して送信するステップ
をさらに含む付記１乃至１１記載のいずれか１つ記載の配送情報処理方法。
【０１１９】
（付記１３）
前記ユーザの端末から配送要求状況の確認要求を受信した場合、既に確定した配送料の情報を配送業者から受信したか判断するステップと、
既に前記確定した配送料の情報を配送業者から受信している場合には前記記憶装置に格納された前記配送の要求に関する情報に含まれる購入商品の情報と前記確定した配送料の情報とを前記ユーザに対して送信し、未だ前記確定した配送料の情報を配送業者から受信していない場合には前記記憶装置に格納された前記配送の要求に関する情報に含まれる購入商品の情報と配送料の見積結果とを前記ユーザに対して送信するステップ
をさらに含む付記１乃至１２のいずれか１つ記載の配送情報処理方法。
【０１２０】
（付記１４）
ユーザの端末から購入商品の購入店舗からの配送の要求を受信した場合、当該配送の要求に関する情報を記憶装置に格納する配送要求受信ステップと、
所定のタイミング以降に、前記ユーザの端末から前記所定のタイミングまでに受信された前記配送の要求に係る全購入商品のうち所定の条件に合致した購入商品の梱包指示を配送業者に対して送信する梱包指示送信ステップと、
を含む配送情報処理方法。
【０１２１】
（付記１５）
購入商品及び購入店舗についての情報を含む購入商品の配送要求を少なくとも購入店舗毎にセンタ・サーバに送信するステップと、
全購入商品のうち所定の条件を満たした購入商品の指定場所への一括配送開始要求を前記センタ・サーバに送信するステップと、
を含む配送要求処理方法。
【０１２２】
（付記１６）
付記１乃至１４のいずれか１つ記載の配送情報処理方法をコンピュータに実行させるためのプログラム。
【０１２３】
（付記１７）
ユーザの端末から購入商品の購入店舗からの配送の要求を受信した場合、当該配送の要求に関する情報を記憶装置に格納する配送要求受信手段と、
前記ユーザの端末から購入完了指示を受信した場合、当該ユーザの端末から前記購入完了指示受信までに受信された前記配送の要求に係る全購入商品のうち所定の条件に合致した購入商品の梱包指示を配送業者に対して送信する梱包指示送信手段と、
を含む配送情報処理システム。
【０１２４】
【発明の効果】
以上のように本発明によれば、異なる店舗において購入した物品についても一括して配送できるようになる。
【図面の簡単な説明】
【図１】  本発明の一実施の形態に係るビジネスフローを示す図である。
【図２】  本発明の一実施の形態におけるシステム構成例を示す図である。
【図３】  ユーザマスタＤＢに格納されるデータの一例を示す図である。
【図４】  店舗マスタＤＢに格納されるデータの一例を示す図である。
【図５】  代表番号管理テーブルに格納されるデータの一例を示す図である。
【図６】  宅配受付テーブルに格納されるデータの一例を示す図である。
【図７】  集荷管理テーブルに格納されるデータの一例を示す図である。
【図８】  配送管理テーブルに格納されるデータの一例を示す図である。
【図９】  同梱見積りテーブルに格納されるデータの一例を示す図である。
【図１０】  特種品配送料テーブルに格納されるデータの一例を示す図である。
【図１１】  ポイントＤＢに格納されるデータの一例を示す図である。
【図１２】  本発明の一実施の形態に係る全体の処理フロー（その１）を示す図である。
【図１３】  宅配要求ページの一例を示す図である。
【図１４】  本発明の一実施の形態に係る全体の処理フロー（その２）を示す図である。
【図１５】  宅配要求受付処理の処理フローを示す図である。
【図１６】  宅配依頼受付ページの一例を示す図である。
【図１７】  配送料見積処理の処理フローを示す図である。
【図１８】  購入期限警告通知処理の処理フローを示す図である。
【図１９】  購入完了指示処理の処理フローを示す図である。
【図２０】  購入完了指示ページの一例を示す図である。
【図２１】  宅配依頼受付確認ページの一例を示す図である。
【図２２】  梱包指示データの一例を示す図である。
【図２３】  宅配要求の修正指示処理の処理フローを示す図である。
【図２４】  購入期限超過処理の処理フローを示す図である。
【図２５】  梱包指示処理の処理フローを示す図である。
【図２６】  宅配依頼受付確認処理の処理フローを示す図である。
【図２７】  購入期限経過後の宅配依頼受付確認処理の処理フローを示す図である。
【図２８】  購入期限延長処理の処理フローを示す図である。
【図２９】  集荷指示処理の処理フローを示す図である。
【図１】
0003844437.tif 000002
【図２】
0003844437.tif 000003
【図３】
0003844437.tif 000004
【図４】
0003844437.tif 000005
【図５】
0003844437.tif 000006
【図６】
0003844437.tif 000007
【図７】
0003844437.tif 000008
【図８】
0003844437.tif 000009
【図９】
0003844437.tif 000010
【図１０】
0003844437.tif 000011
【図１１】
0003844437.tif 000012
【図１２】
0003844437.tif 000013
【図１３】
0003844437.tif 000014
【図１４】
0003844437.tif 000015
【図１５】
0003844437.tif 000016
【図１６】
0003844437.tif 000017
【図１７】
0003844437.tif 000018
【図１８】
0003844437.tif 000019
【図１９】
0003844437.tif 000020
【図２０】
0003844437.tif 000021
【図２１】
0003844437.tif 000022
【図２２】
0003844437.tif 000023
【図２３】
0003844437.tif 000024
【図２４】
0003844437.tif 000025
【図２５】
0003844437.tif 000026
【図２６】
0003844437.tif 000027
【図２７】
0003844437.tif 000028
【図２８】
0003844437.tif 000029
【図２９】
0003844437.tif 000030