JP2003216709A - 配送情報処理方法 - Google Patents

Abstract

(57)【要約】 【課題】異なる店舗において購入した物品についても一
括して配送する。 【解決手段】ユーザは店舗Aで商品Aを購入すると(1)、
ユーザ端末により宅配要求を送信する(2)。宅配便受付
業務サービスセンタはICタグ情報を店舗A等に送信する
(3)。店舗AではICタグに情報を書き込み(4)、商品Aに添
付する。サービスセンタは集荷指示を配送業者に送信す
る(5)。ユーザはこのような買い物を繰り返す。配送業
者は店舗に商品の集荷に行く(11)。集荷が完了すれば集
荷完了通知をサービスセンタに送信する(12)。そしてユ
ーザは買い物終了時に購入完了指示をサービスセンタに
送信する(13)。これに応じてサービスセンタは梱包指示
を配送業者に送信する(14)。配送業者はこれに応じて梱
包を行い(15)、料金が確定すると料金通知をサービスセ
ンタに送信する(16)。そして配送業者はユーザ宅に配送
を実施し(17)、配送が完了すると配送完了をサービスセ
ンタに送信する(18)。

Description

【発明の詳細な説明】

【０００１】

【発明が属する技術分野】本発明は、複数物品の一括配
送のための情報処理技術に関する。

【０００２】

【従来の技術】観光地で土産物等を購入する際、観光を
しながら次々と土産物等を購入すると、購入した土産物
を手に持って移動する必要があり、重くなって持ち運び
が大変であったり、次に買いたいものがあっても持ちき
れなくて購入を断念せざるを得ない場合が生ずる。ま
た、観光地ではその周辺住民等が利用する宅配取扱店も
存在しているが、そのような宅配取扱店はどこにでもあ
るわけではなく、観光中に時間を割いて探さなければな
らない。又は、どこにあるのか分からないため、結局購
入した土産物等を手に持って観光することになるため、
十分に観光を楽しむことができなくなってしまう。

【０００３】また、観光地にも、土産物等の宅配便配送
を取り扱っている店舗等（観光施設等を含む）が存在し
ているが、そのような店舗等では当該店舗等で購入した
土産物等のみを送ることが前提となっている場合が多
い。従って、異なる店舗で買い物をする場合には、その
都度配送料がかかり、観光客の負担は大きい。

【０００４】

【発明が解決しようとする課題】従って本発明の目的
は、異なる店舗において購入した物品についても一括し
て配送できるようにするための情報処理技術を提供する
ことである。

【０００５】

【課題を解決するための手段】本発明に第１の態様に係
る配送情報処理方法は、ユーザの端末から購入商品の購
入店舗からの配送の要求を受信した場合、当該配送の要
求に関する情報を記憶装置に格納する配送要求受信ステ
ップと、ユーザの端末から購入完了指示を受信した場
合、当該ユーザの端末から購入完了指示受信までに受信
された配送の要求に係る全購入商品のうち所定の条件に
合致した購入商品の梱包指示を配送業者に対して送信す
る梱包指示送信ステップとを含む。

【０００６】このようにすることにより、ユーザは例え
ば商品を購入する毎に配送の要求を、ショッピング終了
時には購入完了指示を本配送情報処理方法を実施するコ
ンピュータに送信するだけで購入物品が一括して配送さ
れるようになるため、利便性が高くなる。なお、配送業
者は、個々の購入物品を集荷して梱包することになる
が、このシステムにより多くのユーザが配送を依頼する
ようになれば収益が向上するようになる。店舗について
もユーザは持ち運びを考慮せずに土産物等を購入できる
ようになるため、販売量が増加して収益が向上するよう
になる。

【０００７】なお、ユーザの端末から最初の配送の要求
を受信してから所定時間経過したにもかかわらず購入完
了指示を受信しない場合、ユーザの端末から所定時間経
過までに受信された配送の要求に係る全購入商品のうち
所定の条件に合致した購入商品の梱包指示を配送業者に
対して送信する梱包指示送信ステップをさらに含むよう
な構成であってもよい。ユーザが購入完了指示の送信を
忘れる場合もあり、集荷した購入商品の管理の都合から
も所定時間を設定して自動的に購入完了指示が行われた
ものとして取り扱うものである。

【０００８】また、ユーザの端末から所定時間の延長要
求を受信した場合には、所定時間の延長を記憶装置に設
定するステップをさらに含むような構成であってもよ
い。ショッピングを長く行うユーザのためである。

【０００９】また、ユーザの端末から最初の配送の要求
を受信してから所定時間経過したにもかかわらず購入完
了指示を受信しない場合、ユーザに対して配送の要求の
受付完了を通知するステップをさらに含むような構成で
あってもよい。自動的に購入完了処理が行われた場合に
はこれ以上配送の要求を受け付けないことをユーザに通
知する方がよいためである。

【００１０】さらに、所定時間経過前の所定のタイミン
グにて、ユーザに対して配送の要求の受付完了を予告す
るステップをさらに含むような構成であってもよい。配
送の要求の受付期限をユーザに認識させるためである。

【００１１】また、ユーザの端末から要求に応じて、記
憶装置に格納された配送の要求に関する情報を用いて配
送料の見積りを実施し、当該配送料の見積りの情報をユ
ーザの端末に送信するステップをさらに含むような構成
であってもよい。ユーザは配送料の見積りを目処に配送
の要求を加減することができる。

【００１２】さらに、ユーザの端末から購入商品の購入
店舗からの配送の要求を受信した場合、当該購入商品の
集荷指示を配送業者のコンピュータに送信するステップ
をさらに含むような構成とすることも可能である。配送
の要求を受信する毎に集荷指示を送信することも可能で
あるし、配送業者が集荷指示が無くとも定期的に所定の
店舗に集荷に行くような構成も可能である。

【００１３】また、特定の購入店舗からの配送の要求を
ユーザの端末から所定数以上受信した場合に、特定の購
入店舗及び当該特定の購入店舗に関連付けられた店舗に
ついての購入商品の集荷要求を配送業者に対して送信す
るステップをさらに含むような構成であってもよい。こ
のようにすることにより、ある程度まとまった集荷を行
うことができるため効率的な集荷を行うことができるよ
うになる。

【００１４】なお、梱包指示に、ユーザにより指示され
た配送先の情報を含むような構成であってもよい。すな
わち梱包指示が配送指示を兼ねている場合である。

【００１５】さらに、ユーザの端末から購入商品の購入
店舗からの配送の要求を受信した場合、当該購入商品の
配送業者による少なくとも梱包に用いるための情報をユ
ーザの端末又は購入店舗のコンピュータに送信するステ
ップをさらに含むような構成であってもよい。例えば集
荷や梱包を正確且つ効率的に行うためＩＣタグを用いる
場合には、ＩＣタグに書き込むべき例えばユーザの識別
情報や一括配送される購入商品群の識別情報（例えば実
施の形態に係る代表番号）等である。このような情報を
用いることにより、ユーザは送付状を書き込むといった
手間も無くなる。

【００１６】また、上で述べた所定の条件が、購入店舗
が予め特定された店舗以外の店舗であること又は購入商
品が予め特定された商品以外の商品であることである場
合もある。所定の集荷範囲から外れる店舗の場合や特別
な取り扱いが必要な生鮮食品などについては一括梱包が
不可能であるためである。

【００１７】本発明の第２の態様に係る配送情報処理方
法は、ユーザの端末から購入商品の購入店舗からの配送
の要求を受信した場合、当該配送の要求に関する情報を
記憶装置に格納する配送要求受信ステップと、所定のタ
イミング（例えば最初の配送の要求から所定時間経過後
又は所定の時刻）以降に、ユーザの端末から当該所定の
タイミングまでに受信された配送の要求に係る全購入商
品のうち所定の条件に合致した購入商品の梱包指示を配
送業者に対して送信する梱包指示送信ステップとを含
む。このように、ユーザが購入完了指示を行わないとい
うことを前提とする構成にすることも可能である。

【００１８】本発明の第３の態様に係る配送要求処理方
法は、購入商品及び購入店舗についての情報を含む購入
商品の配送要求を少なくとも購入店舗毎にセンタ・サー
バに送信するステップと、全購入商品のうち所定の条件
を満たした購入商品の指定場所への一括配送開始要求を
センタ・サーバに送信するステップとを含む。

【００１９】なお、上述の方法はプログラム及びコンピ
ュータにて実施することができ、このプログラムは、例
えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディ
スク、半導体メモリ、ハードディスク等の記憶媒体又は
記憶装置に格納される。また、ネットワークなどを介し
て配布される場合もある。尚、中間的な処理結果はメモ
リに一時保管される。

【００２０】

【発明の実施の形態】最初に図１を用いて本発明におけ
るビジネスフローの一例を示す。ユーザは例えば店舗Ａ
にて商品Ａを購入する（ステップ（１））。その際例え
ば携帯電話機を用いて宅配便受付業務サービス・センタ
にユーザＩＤ、店舗Ａ、商品Ａの識別情報及び商品サイ
ズ等の情報を含む宅配要求を送信する（ステップ
（２））。宅配便受付業務サービス・センタのセンタ・
サーバは、当該宅配要求を受信すると、一括配送商品を
特定するための代表番号及び個々の商品を識別する追番
の組み合わせである受付番号やユーザＩＤ等のユーザ情
報を含むＩＣタグ情報を生成して、ユーザの携帯電話機
又は店舗Ａに設置されたＩＣタグライタに送信する（ス
テップ（３））。ユーザの携帯電話機にＩＣタグ情報が
送信される場合には、携帯電話機から例えばBlutoothや
無線ＬＡＮ又はケーブル接続等の通信手段により店舗Ａ
のＩＣタグライタにＩＣタグ情報を送信する（ステップ
（３）'）。店舗ＡではＩＣタグライタによりＩＣタグ
に受信した情報を書き込み（ステップ（４））、商品Ａ
又は商品Ａの包装物に添付する。伝票をＩＣタグ情報を
用いて印刷し、商品Ａ等に添付しても良い。なお、ユー
ザの携帯電話機から宅配要求を送信するのではなく、店
舗ＡのＰＯＳレジスタ等の機器から宅配便受付業務サー
ビス・センタのセンタ・サーバに送信してもよい。宅配
便受付業務サービス・センタのセンタ・サーバは、店舗
Ａからの商品Ａの集荷指示を配送業者のサーバに送信す
る（ステップ（５））。なお、ユーザの携帯電話機に
は、宅配便受付業務サービス・センタのセンタ・サーバ
から配送料の見積り結果を送信する。

【００２１】ユーザは次に店舗Ｂに行き、商品Ｂを購入
する（ステップ（６））。その際例えば携帯電話機を用
いて宅配便受付業務サービス・センタにユーザＩＤ、店
舗Ｂ、商品Ｂの識別情報及び商品サイズ等の情報を含む
宅配要求を送信する（ステップ（７））。宅配便受付業
務サービス・センタのセンタ・サーバは、当該宅配要求
を受信すると、受付番号やユーザＩＤ等のユーザ情報を
含むＩＣタグ情報を生成して、ユーザの携帯電話機又は
店舗Ｂに設置されたＩＣタグライタに送信する（ステッ
プ（８））。ユーザの携帯電話機にＩＣタグ情報が送信
される場合には、携帯電話機から何らかの通信手段によ
り店舗ＢのＩＣタグライタにＩＣタグ情報を送信する
（ステップ（８）'）。店舗ＢではＩＣタグライタによ
りＩＣタグに受信した情報を書き込み（ステップ
（９））、商品Ｂ又は商品Ｂの包装物に添付する。伝票
をＩＣタグ情報を用いて印刷し、商品Ｂ等に添付しても
良い。宅配便受付業務サービス・センタのセンタ・サー
バは、店舗Ｂからの商品Ｂの集荷指示を配送業者のサー
バに送信する（ステップ（１０））。また、ユーザの携
帯電話機には、宅配便受付業務サービス・センタのセン
タ・サーバから配送料の見積り結果を送信する。

【００２２】配送業者は、ＩＣタグの付いた商品Ａを商
店Ａから、商品Ｂを商品Ｂから集荷する（ステップ（１
１）及び（１１）'）。配送業者は、配送業者のサーバ
から集荷した商品の受付番号等を含む集荷完了通知を宅
配便受付業務サービス・センタのセンタ・サーバに送信
する（ステップ（１２））。

【００２３】このような処理を繰り返し、ショッピング
の終了をユーザが決心した場合には、ユーザは例えば携
帯電話機を用いてユーザＩＤを含む購入完了指示を宅配
便受付業務サービス・センタのセンタ・サーバに送信す
る（ステップ（１３））。宅配便受付業務サービス・セ
ンタのセンタ・サーバは、購入完了指示を受信すると、
配送業者のサーバに梱包指示を送信する（ステップ（１
４））。配送業者のサーバが梱包指示を受信すると、当
該配送業者は、商品に添付されているＩＣタグなどを用
いて一括配送すべき商品群を集めて、梱包を行う（ステ
ップ（１５））。梱包指示には、配送先の情報や、梱包
すべき商品群の情報等が含まれ、梱包及び配送に使用さ
れる。配送業者は、梱包した時点で配送料が確定するた
め当該確定配送料の情報を配送業者のサーバに入力し、
配送業者のサーバは代表番号及び確定配送料等を含む料
金通知を宅配便受付業務サービス・センタのセンタ・サ
ーバに送信する（ステップ（１６））。宅配便受付業務
サービス・センタのセンタ・サーバは、ユーザの携帯電
話機等に当該確定配送料を通知するようにしてもよい。

【００２４】そして、配送業者はユーザの自宅など指定
の場所に梱包した商品群を配送する（ステップ（１
７））。配送が完了すると、配送完了が配送業者のサー
バに登録され、配送完了通知が配送業者のサーバから宅
配便受付業務サービス・センタのセンタ・サーバに送信
される（ステップ（１８））。

【００２５】このようにすれば、ユーザは複数の店舗等
を回ってショッピングを行う場合であっても、購入した
商品を持ち歩く必要は無く、観光等における負担が低減
される。配送業者は、集荷及び梱包という手数がかかる
が、ユーザにとって利便性が高いので宅配便利用が増加
して、収益が向上することが期待できる。さらに、店舗
は、持ち運びを気にせずにショッピングができるためユ
ーザによる購入量が増え、収益が向上することが期待で
きる。

【００２６】なお、配送料の決済については着払いであ
ってもよいし、宅配便受付業務サービス・センタにクレ
ジットカードや銀行口座等を登録してそれらにより行っ
てもよい。また、図１ではユーザが購入完了指示を行う
例を示しているが、商品Ａを購入した際に行った宅配要
求から所定時間内に購入完了指示が行われなかった場合
には、自動的に購入完了と判断してステップ（１４）以
降の処理を実施してもよい。しかし、ユーザのショッピ
ングの都合によっては、ユーザの携帯電話機等から延長
指示を宅配便受付業務サービス・センタのセンタ・サー
バに送信する場合もある（ステップ（１３）'）。延長
指示を受け付けた宅配便受付業務サービス・センタのセ
ンタ・サーバは、期限時刻を所定時間だけ延長する。

【００２７】なお、ユーザは携帯電話機等により、宅配
要求の状況を宅配便受付業務サービス・センタのセンタ
・サーバから取得することができる。また、本システム
を利用する店舗及びユーザに対してはポイントを付与し
て、利用を促進する場合もある。

【００２８】次に図１に示したようなビジネスフローを
実施するために用いるコンピュータ・システムの一例を
図２に示す。宅配便受付業務サービス・センタに設置さ
れるセンタ・サーバ３は、インターネット等のネットワ
ーク１に接続される。ネットワーク１には、ＰＤＡ（Pe
rsonal Digital Assistance）５や携帯電話機７等のユ
ーザ端末、例えば店舗Ａ等の店舗に設置されるＩＣタグ
ライタ９やＰＯＳレジスタ１３、配送業者の施設等に設
置される配送業者サーバ１５などが接続される。ＩＣタ
グライタ９には伝票プリンタ１１が接続されている。

【００２９】なお、店舗に設置されるＩＣタグライタ９
と携帯電話機７等のユーザ端末がBluetooth（詳細につ
いてはhttp://www.bluetooth.comを参照のこと。）や無
線ＬＡＮ、ケーブル接続などにより通信できれば、ＩＣ
タグライタ９はネットワーク１に接続せずともよい。ま
た、ＰＯＳレジスタ１３についても、携帯電話機７等の
ユーザ端末により宅配要求をセンタ・サーバ３に送信す
る場合には、ネットワーク１に接続しなくともよい。

【００３０】ＩＣタグライタ９、ＰＯＳレジスタ１３、
配送業者サーバ１５については、専用回線等携帯電話機
７等のユーザ端末が使用するネットワークとは別のネッ
トワークにてセンタ・サーバ３に接続するようにしても
よい。

【００３１】センタ・サーバ３は、携帯電話機７等のユ
ーザ端末やＰＯＳレジスタ１３等から宅配要求を受信
し、処理する宅配要求受付処理部３１と、宅配要求に係
る物品の集荷に関連する処理を実施する集荷関連処理部
３２と、購入完了指示又は自動購入完了以降の配送業者
における梱包や配送に関連する処理を実施する梱包配送
関連処理部３３と、ユーザや店舗に付与されるポイント
を管理するためのポイント管理部３４とが含まれる。ま
た、センタ・サーバ３は、ユーザに関する個人情報を格
納するユーザマスタＤＢ３５、店舗についての情報を格
納する店舗マスタＤＢ３６、本システムにおいて取り扱
われる荷物を管理するためのテーブルを格納する荷物管
理テーブル格納部３７、及びユーザや店舗に付与される
ポイントについての情報を格納するポイントＤＢ３８を
管理している。

【００３２】次にユーザマスタＤＢ３５に格納されるデ
ータの一例を図３に示す。図３の例では、ユーザＩＤの
欄６０１と、ユーザの携帯電話番号の欄６０２と、個々
の携帯電話機を識別するために用いられるサブスクライ
バ（Subscriber）ＩＤ又はＩＰｖ６のアドレスの欄６０
３と、ユーザのメール・アドレスの欄６０４と、ユーザ
の氏名の欄６０５と、ユーザの住所の欄６０６と、ユー
ザの生年月日の欄６０７と、ユーザの性別の欄６０８
と、ユーザの既婚／未婚の別を示す情報を格納するため
の欄６０９と、ユーザの自宅電話番号の欄６１０と、ユ
ーザが用いるパスワードの欄６１１とが含まれる。より
多くの個人属性を格納するような構成であってもよい。
決済のための情報を格納する場合もある。

【００３３】また、店舗マスタＤＢ３６に格納されるデ
ータの一例を図４に示す。図４の例では、店舗等の登録
番号の欄７０１と、店舗等の名称の欄７０２と、店舗等
の住所の欄７０３と、店舗等の電話番号の欄７０４と、
店舗等が用いるパスワードの欄７０５と、店舗等の種別
の欄７０６と、当該店舗等が配送業者による通常集荷の
範囲外である離島などにある場合に当該店舗における購
入商品の集荷・配送又は配送料見積りで特別な取り扱い
を行うために用いる集荷範囲フラグ（１は通常集荷範
囲：０は通常集荷範囲外）の欄７０７と、集荷要求を配
送業者に対して出力する際の基準となる店舗であるアン
テナ店の集荷荷物個数についての集荷基準の欄７０８
と、アンテナ店において集荷基準以上の集荷荷物がある
場合に一緒に集荷すべき店舗等のグループを示す集荷グ
ループの欄７０９とを含む。より多くの店舗属性を格納
するような構成であってもよい。

【００３４】荷物管理テーブル格納部３７に格納される
テーブルは、代表番号管理テーブル、宅配受付テーブ
ル、集荷管理テーブル及び配送管理テーブルである。な
お、補助データとして、同梱見積テーブル及び特種品配
送料テーブルも格納される。

【００３５】荷物管理テーブル格納部３７に格納される
代表番号管理テーブルの一例を図５に示す。代表番号
は、一括して配送する商品群を識別するための識別情報
である。図５の例では、代表番号の欄５０１と、当該代
表番号に係る宅配要求元であるユーザのユーザＩＤの欄
５０２と、宅配要求の指示開始時刻の欄５０３と、購入
期限時刻の欄５０４と、購入完了か否かを表す状態フラ
グの欄５０５と、購入期限時刻前にユーザに期限時刻を
警告したか否かを表す通知フラグの欄５０６と、購入期
限時刻の延長を行ったか否かを表す延長フラグの欄５０
７とが含まれる。

【００３６】荷物管理テーブル格納部３７に格納される
宅配受付テーブルの一例を図６に示す。図６の例では、
宅配要求を送信したユーザのユーザＩＤの欄６２０と、
宅配要求受信の年月日及び時刻の欄６２１と、ユーザが
商品等を購入した店舗等の登録番号の欄６２２と、代表
番号（例えばＮ１００）と購入商品の通し番号（追番：
例えば０１）とで構成される受付番号の欄６２３と、宅
配要求の対象商品の商品名又は番号の欄６２４と、当該
宅配要求の対象商品が特種品か否かを表す特種品フラグ
の欄６２５と、ＩＣタグ情報を送信したか否かを表すＩ
Ｃタグ情報送信済チェック（１は送信済み：０は未送
信）の欄６２６とが含まれる。図６には、商品サイズ格
納欄が示されていないが、このテーブルに格納されるも
のとする。

【００３７】荷物管理テーブル格納部３７に格納される
集荷管理テーブルの一例を図７に示す。図７の例では、
宅配要求を送信したユーザのユーザＩＤの欄６４０と、
ユーザが商品等を購入した店舗等の登録番号の欄６４１
と、受付番号の欄６４２と、宅配要求の対象商品の商品
名又は番号の欄６４３と、当該宅配要求の対象商品が特
種品か否かを表す特種品フラグの欄６４４と、配送業者
に対して集荷指示を送信したか否かを表す集荷指示済チ
ェック（１は指示済み：０は未指示）の欄６４５と、集
荷指示の年月日及び時刻の欄６４６と、配送業者から集
荷完了通知を受信したか否かを表す集荷完了チェック
（１は受信済み：０は未受信）の欄６４７と、集荷完了
年月日及び時刻の欄６４８とが含まれる。

【００３８】荷物管理テーブル格納部３７に格納される
配送管理テーブルの一例を図８に示す。図８の例では、
代表番号の欄８５１と、ユーザから購入完了指示を受信
したか否かを表す購入完了指示チェック（１は受信済
み：０は未受信）の欄８５２と、購入完了指示受付の年
月日及び時刻の欄８５３と、梱包指示を配送業者に対し
て送信したか否かを表す梱包指示チェック（１は送信済
み：０は未送信）の欄８５４と、梱包指示の年月日及び
時刻の欄８５５と、配送業者から梱包物の発送済通知を
受信したか否かを表す発送済チェックの欄８５６と、発
送済通知受付の年月日及び時刻の欄８５７と、発送済通
知に含まれる確定配送料の欄８５８と、配送完了通知を
配送業者サーバ１５から受信したか否か表す配送完了チ
ェック（１は受信済み：０は未受信）の欄８５９とが含
まれる。

【００３９】荷物管理テーブル格納部３７に格納される
同梱見積テーブルの一例を図９に示す。図９の例では、
箱サイズ１（縦、横、高さ）の欄６９０と、箱サイズ１
に対する配送料１の欄６９１と、箱サイズ２（縦、横、
高さ）の欄６９２と、箱サイズ２に対する配送料２の欄
６９３と、．．．が含まれる。ここでは複数の購入商品
の梱包に用いられる全ての種類の箱の定義を行う。

【００４０】荷物管理テーブル格納部３７に格納される
特種品配送料テーブルの一例を図１０に示す。第１の特
種品の名称を格納する特種品１の欄６９４と、特種品１
の配送料である料金１の欄６９５と、第２の特種品の名
称を格納する特種品２の欄６９６と、特種品２の配送料
である料金２の欄６９７とが含まれる。図１０に示した
ような冷凍品や規定外サイズの商品については、本実施
の形態では他の購入商品と同梱されること無く、この特
種品配送料テーブルの配送料がそのまま適用される。

【００４１】ポイントＤＢ３８に格納されるデータ構造
の一例を図１１に示す。図１１の例では、ユーザの場合
にはユーザＩＤ、店舗等の場合には登録番号の欄５１０
と、ポイントが付与された年月日及び時刻１の欄５１１
と、年月日及び時刻１における付加ポイント数１の欄５
１２と、．．．．ポイントが付与された年月日及び時刻
ｎの欄５１３と、年月日及び時刻ｎにおける付加ポイン
ト数ｎの欄５１４と、ユーザＩＤ又は登録番号の合計ポ
イント数の欄５１５とが含まれる。

【００４２】以下図１２乃至図２９を用いて図２に示し
たシステムの処理フローを説明する。最初に、図１２を
用いて処理の概要を示す。ユーザは、店舗において商品
を購入して、本サービスを利用することを決心したもの
とする。そこでユーザは携帯電話機７等のユーザ端末を
操作して、センタ・サーバ３が提供する宅配要求ページ
へアクセスする（ステップＳ１）。センタ・サーバ３の
宅配要求受付処理部３１は、ユーザ端末からのアクセス
に応答して、宅配要求ページ・データを送信する（ステ
ップＳ３）。ユーザ端末は、センタ・サーバ３から宅配
要求ページ・データを受信し、ウェブ(Ｗｅｂ）ブラウ
ザ等により表示装置に表示する（ステップＳ５）。例え
ば図１３に示すような画面が表示される。図１３は、比
較的大きな画面サイズを前提としているが、携帯電話機
７等の場合にはこれらの情報を複数画面に分割して表示
するようにしてもよい。図１３の例では、ユーザＩＤの
入力欄８０１と、パスワードの入力欄８０２と、商品を
購入した店舗の登録番号の入力欄８０３と、宅配希望商
品名又は商品番号の入力欄８０４と、宅配希望商品サイ
ズの縦サイズ入力欄８０５と、横サイズ入力欄８０７
と、高さサイズ入力欄８０７と、送信ボタン８０８とが
設けられている。なお、商品の種類がある程度特定され
る場合には、センタ・サーバ３に商品名又は商品番号に
対応してサイズの情報を登録した商品マスタＤＢを設
け、ユーザのサイズ入力ではなく当該商品マスタＤＢの
データを用いるようにしてもよい。

【００４３】ユーザは、各入力欄にデータを入力し、送
信ボタン８０８をクリックする。そうすると、ユーザ端
末は、入力されたユーザＩＤ、パスワード、店舗の登録
番号、商品名又は商品番号等の商品情報及びサイズを含
む宅配要求をセンタ・サーバ３に送信する（ステップＳ
７）。センタ・サーバ３の宅配要求受付処理部３１は、
ユーザ端末から上記のような宅配要求を受信すると、受
信ユーザＩＤ及びパスワード並びにユーザマスタＤＢ３
５のデータを用いた認証処理及び宅配要求受付処理を実
施する（ステップＳ９）。この宅配要求受付処理につい
ては、後に詳述する。センタ・サーバ３の宅配要求受付
処理部３１は、配送料見積結果を含む宅配依頼受付ペー
ジ・データを生成して、ユーザ端末に送信する。ユーザ
端末は、センタ・サーバ３から配送料見積結果を含む宅
配依頼受付ページ・データを受信し、表示装置に表示す
る（ステップＳ１１）。

【００４４】また、センタ・サーバ３の宅配要求受付処
理部３１は、ユーザマスタＤＢ３５に格納された情報を
用いてユーザＩＤ等のユーザ情報、代表番号及び追番を
含む受付番号等を含むＩＣタグ情報を生成し、送信先を
決定して当該ＩＣタグ情報を送信する（ステップＳ１
３）。送信先は例えば携帯電話機７等のユーザ端末又は
店舗に設置されたＩＣタグライタ９である。この決定
は、例えばＩＣタグライタ９がネットワーク１に接続さ
れているか、又はユーザ端末とＩＣタグライタ９が通信
可能か等で判断される。なお、固定的にユーザ端末又は
ＩＣタグライタ９に送信するようにしてもよい。ユーザ
端末が、センタ・サーバ３からＩＣタグ情報を受信した
場合には、ＩＣタグ情報をＩＣタグライタ９に転送する
（ステップＳ１５）。ＩＣタグライタ９は、センタ・サ
ーバ３又はユーザ端末からＩＣタグ情報を受信すると、
一旦記憶装置に格納し、ＩＣタグライタ９にセットされ
たＩＣタグにＩＣタグ情報を書き込む。また、ＩＣタグ
ライタ９に接続された伝票プリンタ１１により配送伝票
を印刷する（ステップＳ１７）。ユーザ情報に含まれる
住所などの情報が配送伝票に印刷される。配送伝票は３
通印刷され、１通はユーザの控え、１通は店舗の控え、
１通は配送業者用である。

【００４５】店舗の店員は、書き込みのなされたＩＣタ
グをユーザの購入商品又はその包装物に添付したり、印
刷された配送伝票などを貼り付けるなど、店舗における
梱包を実施する（ステップＳ１９）。

【００４６】またセンタ・サーバ３の集荷関連処理部３
２は、図７に示した集荷管理テーブルのレコードを新た
に生成し、ユーザＩＤ、登録番号、受付番号、宅配要求
に係る商品名又は商品番号、特種品フラグの設定、集荷
指示済チェック及び集荷指示年月日及び時刻等の基礎情
報を登録する（ステップＳ２１）。そして、ユーザＩ
Ｄ、登録番号、受付番号等を含む集荷指示を配送業者サ
ーバ１５に送信する（ステップＳ２３）。配送業者サー
バ１５は、センタ・サーバ３からユーザＩＤ、登録番
号、受付番号等を含む集荷指示を受信し、記憶装置に格
納する（ステップＳ２５）。配送業者は、受信した集荷
指示の情報を用いて店舗への集荷を実施する（ステップ
Ｓ２７）。なお、集荷指示に応じて集荷を実施せずとも
よい。すなわち、配送業者の通常の集荷ルートに載って
いるような店舗であれば、当該集荷ルートで集荷しても
よい。このような場合であっても、後に梱包を実施する
必要があるので、集荷指示の情報については記憶装置に
登録しておき、集荷後の梱包準備などに用いることがで
きる。また、集荷指示に応じて直ぐに集荷を行わなくと
もよい。なお、集荷については後に他の実施の形態を説
明する。

【００４７】集荷が完了すれば、配送業者は集荷完了
を、ＩＣタグからＩＣタグ情報を読み出すこと等により
配送業者サーバ１５に登録する。そして、配送業者サー
バ１５は、ＩＣタグ情報に含まれる受付番号等を含む集
荷完了通知をセンタ・サーバ３に送信する（ステップＳ
２９）。センタ・サーバ３の集荷関連処理部３２は、配
送業者サーバ１５から受付番号等を含む集荷完了通知を
受信すると、集荷管理テーブル（図７）の集荷完了チェ
ックの欄６４７に１をセットし、集荷完了通知受信年月
日及び時刻を集荷完了年月日及び時刻の欄６４８に登録
する（ステップＳ３１）。

【００４８】この後に購入完了処理、購入期限警告処
理、購入期限超過処理、宅配依頼受付確認処理を実施す
る。これらの処理については後に詳細に説明する。

【００４９】その後、センタ・サーバ３の梱包配送関連
処理部３３が、梱包指示処理を実施し、ユーザ情報及び
受付番号等の情報を含む梱包指示の情報を生成し、配送
業者サーバ１５に送信する（ステップＳ３５）。なお、
梱包指示処理において、配送管理テーブル（図８）の梱
包指示チェックの欄８５４に１をセットし、梱包指示送
信の年月日及び時刻を梱包指示年月日及び時刻の欄８５
５に登録する。梱包指示処理については後に詳しく述べ
る。配送業者サーバ１５は、ユーザ情報及び受付番号等
の情報を含む梱包指示情報を受信し、記憶装置に格納す
る（ステップＳ３７）。そして、配送業者は、梱包指示
の情報を及び購入商品に含まれるＩＣタグに書き込まれ
た情報を用いて、購入商品の梱包を実施する（ステップ
Ｓ３９）。なお、本実施の形態においては、梱包指示は
配送指示の意味を含むものである。但し両者を別に指示
するような構成でもよい。

【００５０】この後の処理は図１４に移行する。梱包
（ステップＳ３９）すると配送料が確定するため、配送
業者は配送業者サーバ１５に確定配送料を入力し、記憶
装置に格納する（ステップＳ４１）。また、代表番号及
び確定配送料情報を含む発送済通知をセンタ・サーバ３
に送信する（ステップＳ４３）。配送業者は、ユーザ指
定の場所に梱包物を配送する（ステップＳ５０）。

【００５１】センタ・サーバ１５の梱包配送関連処理部
３３は、代表番号及び確定配送料情報を含む発送済通知
を受信し（ステップＳ４５）、配送管理テーブル（図
８）の発送済チェックの欄８５６に１をセットし、発送
済通知受信の年月日及び時刻を発送済通知受信年月日及
び時刻の欄８５７並びに確定配送料の情報を確定配送料
の欄８５８に登録する（ステップＳ４７）。この時点に
おいて、ユーザに対して確定配送料の通知を例えば電子
メールにて送付してもよい（ステップＳ４９）。

【００５２】配送業者は、配送が完了すると、配送業者
サーバ１５に代表番号と配送完了年月日等の情報を入力
する。そうすると、配送業者サーバ１５は当該情報を記
憶装置に格納する。そして、配送業者サーバ１５は、代
表番号を含む配送完了通知を生成し、センタ・サーバ３
に送信する（ステップＳ５１）。センタ・サーバ３の梱
包配送関連処理部３３は、配送業者サーバ１５から代表
番号を含む配送完了通知を受信すると（ステップＳ５
３）、配送管理テーブルの配送完了チェックの欄８５９
に１をセットする（ステップＳ５５）。

【００５３】その後ポイント管理部３４は、配送管理テ
ーブル（図８）の配送完了チェックの欄８５９において
１がセットされたレコードを読み出し、代表番号を取得
し、宅配受付テーブル（図６）等から対応するユーザＩ
Ｄ及び登録番号を取得して、当該ユーザＩＤのユーザ及
び登録番号の店舗に対して所定のポイントを付与する
（ステップＳ５７）。ポイントについては、図１１に示
したポイントＤＢ３８のデータ構造に従って、ポイント
付加年月日及び時刻と付加ポイント値とを登録し、合計
ポイント値を計算し直して登録する。

【００５４】図１５乃至図１７を用いて宅配要求受付処
理の詳細処理フローを説明する。センタ・サーバ３の宅
配要求受付処理部３１は、ユーザ端末から、ユーザＩ
Ｄ、店舗の登録番号、商品情報及びサイズ等を含む宅配
要求を受信する（ステップＳ６１）。図１３のような画
面にユーザが情報を入力してユーザ端末が入力情報を送
信してくる場合には、ＩＤ及びパスワードが宅配要求に
含まれるので、ここでユーザマスタＤＢ３５に格納され
た情報を用いて認証処理を実施する。ここでは認証処理
が成功したものとする。

【００５５】宅配要求受付処理部３１は、宅配要求に含
まれるユーザＩＤを用いて代表番号管理テーブル（図
５）を検索し、当該ユーザＩＤが登録されており且つ状
態フラグ＝０（購入完了状態ではない）のレコードを探
す（ステップＳ６３）。もし、当該ユーザＩＤであり且
つ状態フラグ＝０のレコードが見つからない場合には、
最初の宅配要求であると判断して、代表番号管理テーブ
ル（図５）に新規レコードを作成する（ステップＳ９
５）。そして、当該新規レコードの指示開始時刻の欄５
０３に現在時刻を記録する（ステップＳ９７）。また、
当該新規レコードの期限時刻を現在時刻＋所定時間Ａ
（例えば４時間）に設定し、期限時刻の欄５０４に記録
する（ステップＳ９９）。さらに、当該新規レコードの
延長フラグ、通知フラグ、状態フラグを全て０にセット
して、代表番号管理テーブル（図５）の各欄に記録する
（ステップＳ１０１）。さらに、新規代表番号を発番し
て、新規レコードの代表番号の欄５０１に記録する（ス
テップＳ１０３）。さらに、新規レコードを宅配受付テ
ーブル（図６）に生成し（ステップＳ１０５）、受付番
号（追番）を発番し、ユーザ端末から受信した情報等
（ユーザＩＤ、受信年月日及び時刻、登録番号、対象商
品名又は番号、特種品フラグなど）と共に新規レコード
に記録する（ステップＳ１０７）。そして、配送料見積
処理を実施する（ステップＳ１０９）。この配送料見積
処理については後に説明する。そして配送料見積処理に
より生成された配送料見積結果と新規宅配受付メッセー
ジを含む宅配依頼受付ページ・データを生成し、ユーザ
端末に送信する（ステップＳ１１１）。

【００５６】宅配依頼受付ページの画面例を図１６に示
す。図１６の例では、ユーザＩＤの表示欄８１０と、代
表番号の表示欄８１１と、梱包個数の表示欄８１２と、
宅配商品数の表示欄８１３と、宅配料金（配送料）の表
示欄８１４と、確認メッセージの表示欄８１５と、残り
時間表示部分８１６とが含まれる。新規宅配受付メッセ
ージとして、確認メッセージの表示欄８１５に例えば
「新規に宅配依頼を受け付けました。」といったメッセ
ージが含まれるものである。なお、図１６には、「店舗
が集荷範囲を超えます。別口になります。」といったメ
ッセージ例が示されている。

【００５７】一方、代表番号管理テーブル（図５）に受
信ユーザＩＤであり且つ状態フラグ＝０のレコードが存
在していると判断された場合には、追加の商品宅配要求
がなされたことが確認される。次に、今回の宅配要求に
係る商品が特種品等の同梱基準を満たさない商品であっ
たり、商品購入店舗が通常の集荷範囲の外にあるか（店
舗マスタＤＢ３６（図４）の集荷範囲フラグ７０７が０
の店舗であるか）を判断する（ステップＳ６５）。

【００５８】もし、特種品等の同梱基準を満たさない商
品について宅配要求がなされた場合には、ここでは別途
個別配送するようにする。また店舗が通常の集荷範囲の
外である場合にも同様である。従って、代表番号管理テ
ーブル（図５）に新規レコードを生成し（ステップＳ７
９）、当該新規レコードの指示開始時刻の欄５０３及び
期限時刻の欄５０４に現在時刻を記録する（ステップＳ
８１）。さらに、当該新規レコードの延長フラグ、通知
フラグ、状態フラグを全て１にセットして、代表番号管
理テーブル（図５）の各欄に記録する（ステップＳ８
３）。さらに、新規代表番号を発番して、新規レコード
の代表番号の欄５０１に記録する（ステップＳ８５）。
さらに、新規レコードを宅配受付テーブル（図６）に生
成し（ステップＳ８７）、受付番号（追番）を発番し、
ユーザ端末から受信した情報（ユーザＩＤ、受信年月日
及び時刻、登録番号、対象商品名又は番号、特種品フラ
グなど）と共に新規レコードに記録する（ステップＳ８
９）。そして、配送料見積処理を実施する（ステップＳ
９１）。この配送料見積処理については後に説明する。
そして配送料見積処理により生成された配送料見積結果
と別口メッセージを含む宅配依頼受付ページ・データを
生成し、ユーザ端末に送信する（ステップＳ９３）。別
口メッセージは、図１６に示すような「店舗が集荷範囲
を超えます。別口になります。」や「特種品です。別口
になります。」といったメッセージである。

【００５９】なお、本実施の形態では宅配要求に係る商
品が特種品であったり、当該商品の購入店舗が通常の集
荷の範囲外である場合に、別口配送となるような構成と
した。しかし、本発明はこれに限定されず、例えば冷凍
品ならば冷凍品を一括梱包及び配送し、通常の商品は通
常の商品ごとに一括梱包及び配送するような構成であっ
てもよい。この場合には、受信ユーザＩＤ且つ状態フラ
グ＝０のレコードが複数検出されるので、いずれの梱包
に関連する商品についての宅配要求なのかを判別し、そ
のための情報を代表番号管理テーブル（図５）等に用意
する必要がある。

【００６０】ステップＳ６５において商品及び店舗が規
定外ではないと判断された場合には、該当する代表番号
を代表番号管理テーブル（図５）から識別する（ステッ
プＳ６７）。そして、代表番号が一致する宅配受付テー
ブル（図６）内のレコードを識別し、新規レコードを生
成する（ステップＳ６９）。そして、代表番号が一致す
るレコードを元に受付番号（追番）を発番し、ユーザ端
末からの受信情報（ユーザＩＤ、受信年月日及び時刻、
登録番号、対象商品名又は番号、特種品フラグなど）と
共に新規レコードに登録する（ステップＳ７１）。そし
て、配送料見積処理を実施する（ステップＳ７３）。こ
の配送料見積処理については後に説明する。そして、残
り時間を代表番号管理テーブル（図５）の指示開始時刻
と期限時刻との差にて算出する（ステップＳ７５）。そ
して、残り時間及び配送料見積処理結果を含む宅配依頼
受付ページ・データを生成し、ユーザ端末に送信する
（ステップＳ７７）。追加の宅配要求については、あと
どの程度宅配要求を受け付けるのかをユーザに知らせる
ために、図１６の例における残り時間の表示欄８１６が
設けられている。ステップＳ９３、ステップＳ７７又は
ステップＳ１１１の後に元の処理に戻る。

【００６１】このようにすることにより、新規の宅配要
求、追加の宅配要求、及び宅配要求に係る商品又は店舗
が規定外のケースに対処することができるようになる。

【００６２】次に図１７を用いて配送料見積処理につい
て説明する。最初に、今回購入商品の寸法が本サービス
で準備した箱より大きいか又は店舗又は商品が規定外の
ものかを判断する（ステップＳ１１５）。大きすぎた
り、冷凍品であったり、店舗が通常の集荷範囲外にある
場合等は、同梱することができないため、別口扱いとな
る。従って、ステップＳ１１５における条件を満たすと
判断されると、冷凍品や大きすぎる商品の場合には特種
品配送料テーブル（図１０）に従って単純に配送料を計
算し、店舗が通常の集荷範囲外であるような場合には図
示しない通常取り扱い配送料テーブルを用いて配送料を
計算する（ステップＳ１１７）。

【００６３】一方、同梱取り扱いできる商品及び通常の
集荷範囲内の店舗である場合には、これまでの全購入商
品が一番小さい箱に入るかを判断する（ステップＳ１１
７）。この判断にはユーザ端末から送信されてくる商品
のサイズ情報が用いられる。もし、全購入商品が一番小
さい箱に入る場合には、その箱の大きさ及び自宅（又は
ユーザ指定の場所）までの距離に応じて料金計算を実施
する（ステップＳ１１９）。その際に、同梱見積テーブ
ル（図９）を用いる。図９の例では、距離のデータは示
されていないが、距離の情報も考慮する。但し、大きさ
だけで配送料が確定されるようにしてもよい。

【００６４】一方、一番小さな箱に入らない場合には、
次の大きさの箱に全購入商品が入るか判断する（ステッ
プＳ１２１）。もし、入るようであればステップＳ１１
９に移行して、その箱の大きさ及び自宅等までの距離に
応じた料金計算を実施する。

【００６５】もしステップＳ１２１にて全購入商品が箱
に入らないと判断された場合には、次に選べる大きさの
箱があるか判断する（ステップＳ１２３）。もし、その
ような箱が準備されている場合にはステップＳ１２１に
戻る。一方、もう次に選べる大きさの箱が無い場合に
は、ひとつの箱で梱包できなくなったことを示す。従っ
てとりあえず一番大きい箱に入るだけ入れたとして、箱
の大きさ及び自宅等までの距離に応じた配送料の計算を
実施する（ステップＳ１２５）。また、箱の数（初期値
１）を１インクリメントする。そして、現在の箱に詰め
られるだけ詰めた場合に入らない商品を特定する（ステ
ップＳ１２７）。そして、一番小さい新たな箱を選択す
る（ステップＳ１２９）。

【００６６】そしてステップＳ１２７において特定され
た購入商品がステップＳ１２９で選択した箱に入るか判
断する（ステップＳ１３１）。もし入るようであれば、
新たな箱の大きさ及び自宅等までの距離に応じた配送料
を計算し、前に計算された別の箱の配送料に加算する
（ステップＳ１３５）。一方、ステップＳ１２７で特定
された購入商品が今回の箱に入らないようであれば次の
大きさの箱に入るか判断する（ステップＳ１３３）。も
し、入るようであれば、当該箱の大きさ及び自宅等まで
の距離に応じた配送料を計算し、前に計算された別の箱
の配送料に加算する。もし、ステップＳ１３３で次の大
きさの箱に入らないと判断された場合には、次に選べる
大きさの箱が存在しているか判断する（ステップＳ１３
７）。もし、まだ次の大きさの箱が準備されているよう
であればステップＳ１３３に戻る。一方、次に選べる大
きさの箱がもうない場合にはステップＳ１２５に戻る。
すなわち、再度最も大きい箱がいっぱいになったことを
意味するので、当該箱の配送料を計算しておく。また、
箱の数を１インクリメントする。そして梱包できていな
い購入商品の配送料の計算を上で述べたように実施す
る。

【００６７】このような処理を実施することにより、よ
り少ない口数で配送料を計算できるため、ユーザには大
きなコストメリットが発生する。

【００６８】上で述べたように、ユーザは、複数の店舗
等で商品の購入を実施することができる。すなわち、図
１２のステップＳ１乃至ステップＳ３１までが繰り返さ
れる。

【００６９】本実施の形態では、図１５のステップＳ９
９で設定されるように所定時間Ａだけ宅配要求を受け付
けるようになっている。これは、配送業者における購入
商品の集荷、管理、梱包、配送の手数を考慮して決定さ
れるものである。但し、所定時間Ａについては延長可能
として、ユーザのショッピングなどの都合に合わせるこ
とも可能である。延長に関しては１回の延長で所定時間
Ｄだけ延長するようにしているが、延長の回数制限を設
ける場合もある。本実施の形態では１回のみ延長できる
ようになっている。

【００７０】次に、最初の宅配要求時刻である指示開始
時刻（図５：指示開始時刻の欄５０３に格納された時
刻）から時間が経過した場合の処理を説明する。最初
に、宅配要求を受け付ける期限時刻が迫っていることを
ユーザに通知するための購入期限警告通知処理について
図１８を用いて説明する。梱包配送関連処理部３３は、
代表番号管理テーブル（図５）の第１レコードを読み出
す（ステップＳ１４１）。そして、当該レコードの通知
フラグが０（警告未通知）であるか判断する（ステップ
Ｓ１４３）。もし、通知フラグが１であれば、次のレコ
ードを代表番号管理テーブルから読み出して（ステップ
Ｓ１５３）、ステップＳ１４３に戻る。

【００７１】一方、梱包配送関連処理部３３は、通知フ
ラグが０であれば、現在時刻が当該レコードに含まれる
期限時刻の所定時間Ｂ（例えば１０分）前以降であるか
を確認する（ステップＳ１４５）。例えば期限時刻が１
８：００であれば１７：５０以降になっているかを確認
する。もし、現在時刻が期限時刻の所定時間Ｂ前に達し
ていない場合には、ステップＳ１５３に移行する。一
方、現在時刻が期限時刻の所定時間Ｂ前以降である場合
には、購入期限時刻の警告通知を例えば電子メールで送
信する（ステップＳ１４７）。電子メール・アドレス
は、ユーザマスタＤＢ３５（図３）から取得する。その
他ユーザの携帯電話機７等に電話をかけるようにしても
良い。そして、代表番号管理テーブル（図５）の通知フ
ラグを１にセットする（ステップＳ１４９）。そしてス
テップＳ１５３に戻る。なお、ステップＳ１５３におい
て次のレコードがない場合には第１のレコードに戻る。

【００７２】このようにして常に購入期限時刻の警告通
知を行っていないレコードのうち期限時刻の所定時間Ｂ
前以降となったレコードを探し出して、当該レコードに
関連するユーザに対して購入期限時刻の警告通知を実施
する。

【００７３】次に、ショッピングの終了時にユーザが自
主的に購入完了をセンタ・サーバ３に通知する場合の処
理フローを図１９乃至図２３を用いて説明する。携帯電
話機７等のユーザ端末は、ユーザの指示に応じて購入完
了指示ページにアクセスする（ステップＳ１５１）。セ
ンタ・サーバ３の梱包配送関連処理部３３は、アクセス
に応じて購入完了ページ・データをユーザ端末に送信す
る（ステップＳ１５３）。ユーザ端末は、センタ・サー
バ３から購入完了ページ・データを受信し、表示装置に
表示する（ステップＳ１５５）。例えば、図２０に示す
ような画面が表示される。図２０の例では、ユーザＩＤ
の入力欄８２０と、パスワードの入力欄８２１と、購入
完了ボタン８２２とが設けられている。

【００７４】ユーザは、ユーザ端末を操作してユーザＩ
Ｄ及びパスワードを入力し、購入完了ボタン８２２をク
リックする。そうすると、ユーザ端末は、ユーザＩＤ及
びパスワードを含む購入完了通知をセンタ・サーバ３に
送信する（ステップＳ１５７）。センタ・サーバ３の梱
包配送関連処理部３３は、ユーザ端末からユーザＩＤ及
びパスワードを含む購入完了通知を受信すると、当該ユ
ーザＩＤ及びパスワード並びにユーザマスタＤＢ３５に
格納された情報を用いて認証処理を実施する（ステップ
Ｓ１５９）。認証処理自体は従来と変わらないので説明
は省略し、ここでは認証処理が成功したものとする。

【００７５】またユーザＩＤを用いて代表番号管理テー
ブル（図５）を検索し、代表番号管理テーブルに受信ユ
ーザＩＤ且つ状態フラグ＝０（０は購入完了又は自動購
入完了処理未実施）であるレコードが存在しているか判
断する（ステップＳ１６１）。もし、存在しなければエ
ラー通知をユーザ端末に送信する。ユーザ端末は、セン
タ・サーバ３からエラー通知を受信し、表示装置に表示
する（ステップＳ１６３）。

【００７６】一方、受信ユーザＩＤ且つ状態フラグ＝０
であるレコードが存在する場合には、当該レコードの代
表番号を有する全レコードを宅配受付テーブル（図６）
から読み出す（ステップＳ１６５）。そして、読み出し
たレコードの情報を用いて配送料見積処理（図１７）を
実施する（ステップＳ１６７）。そして、配送料見積結
果を含む宅配依頼受付確認ページ・データを生成し、ユ
ーザ端末に送信する（ステップＳ１６９）。ユーザ端末
は、宅配依頼受付確認ページ・データを受信し、Ｗｅｂ
ブラウザにより表示装置に表示する（ステップＳ１７
１）。

【００７７】宅配依頼受付ページ・データの一例を図２
１に示す。図２１の例では、ユーザＩＤの表示欄９０
１、代表番号の表示欄９０２、店舗名の表示欄９０３、
店舗の登録番号の表示欄９０４、受付年月日及び時刻の
表示欄９０５、商品名の表示欄９０６、個数の表示欄９
０７、配送料の表示欄９０８、宅配依頼受付内容の確認
を指示するためのＹＥＳボタン９０９、宅配依頼の修正
ボタン９１０、購入期限の延長ボタン９１１、購入期限
までの残り時間表示欄９１２などが含まれる。なお、ユ
ーザが自主的に購入完了指示を行う場合には延長の可能
性は無いので、ステップＳ１７１で表示される宅配依頼
受付確認ページにおいては延長ボタン９１１は含まれな
い。

【００７８】ユーザは、表示された宅配依頼受付確認ペ
ージの内容を確認する。もし、問題があれば「問い合わ
せ先」に電話をかけても良い。問題が無ければＹＥＳボ
タン９０９をクリックし、修正を画面上で行う場合には
修正ボタン９１０をクリックする。ユーザ端末は、ユー
ザによるクリックに従って応答をセンタ・サーバ３に送
信する（ステップＳ１７３）。センタ・サーバ３の梱包
配送関連処理部３３は、ユーザ端末から応答を受信し
（ステップＳ１７７）、当該応答が確認応答であるかを
判断する（ステップＳ１７７）。もし、確認応答ではな
く、修正応答である場合には端子Ａを介して図２３に移
行する。一方、確認応答であれば、梱包及び配送を開始
する旨のメッセージを含む受付完了ページ・データに送
信する（ステップＳ１７９）。ユーザ端末は、センタ・
サーバ３から受付完了ページ・データを受信し、表示装
置に表示する（ステップＳ１８１）。そして、配送業者
への梱包指示情報を生成し、配送業者サーバ１５に送信
する（ステップＳ１８３）。例えば図２２にような情報
が梱包指示情報として送信される。図２２の例では、ユ
ーザＩＤの欄８７１と、氏名の欄８７２と、住所の欄８
７３と、電話番号の欄８７４と、購入店舗の登録番号８
７５と、受付番号の欄８７６と、宅配要求の受付商品又
は番号の欄８７７と、特種品フラグの欄８７８とが含ま
れる。配送業者サーバ１５は、センタ・サーバ３から梱
包指示情報を受信すると、記憶装置に格納する。配送業
者は、この梱包指示情報と、集荷指示情報、ＩＣタグか
ら読み取られた情報をマッチングさせて、適切に梱包を
行い、当該梱包物を配送する。

【００７９】また、センタ・サーバ３の梱包配送関連処
理部３３は、代表番号管理テーブルにおいて当該レコー
ドの状態フラグ及び通知フラグを１に設定する。なお、
通知フラグについては既に１にセットされている場合も
あるが、その場合にはそのままにする。また、配送管理
テーブル（図８）に新規レコードを生成する（ステップ
Ｓ１８５）。新規レコードには、当該代表番号を登録
し、購入完了指示チェックを１にセットし、購入完了指
示を受信した年月日及び時刻の情報を記録する。また、
梱包指示チェックを１にセットし、梱包指示を送信した
年月日及び時刻の情報を記録する。

【００８０】次に、ユーザ端末から受信した応答が修正
応答である場合の処理について図２３を用いて説明す
る。処理は図１９から端子Ａを介して図２３に移行す
る。この場合、梱包配送関連処理部３３は、修正すべき
宅配要求についての情報を指示可能とした修正用ページ
・データを生成し、ユーザ端末に送信する（ステップＳ
１８７）。ユーザ端末は、センタ・サーバ３から修正用
ページ・データを受信し、表示装置に表示する（ステッ
プＳ１８９）。ユーザは、表示された修正用ページを見
て、適切な修正指示を入力し、当該修正指示の送信を命
ずる。ユーザ端末は、指示に従って、修正指示情報をセ
ンタ・サーバ３に送信する（ステップＳ１９１）。セン
タ・サーバ３の梱包配送関連処理部３３は、ユーザ端末
から修正指示を受信すると、修正指示に従って宅配受付
テーブル（図６）を修正する（ステップＳ１９３）。そ
して、端子Ｂを介して図１９のステップＳ１６７に戻
る。

【００８１】このようにしてユーザによる購入完了指示
に従って梱包・配送が行われるようになる。また、宅配
依頼受付確認ページで宅配要求の内容を確認でき、修正
が必要な場合には修正を指示することもできる。

【００８２】次に、ユーザが自発的に購入完了指示を行
わずに宅配要求受付の期限時刻に達した場合の処理につ
いて図２４を用いて説明する。梱包配送関連処理部３３
は、代表番号管理テーブル（図５）の第１レコードを読
み出す（ステップＳ２０１）。そして、当該レコードの
状態フラグが０（購入完了又は自動購入完了処理未了）
であるか確認する（ステップＳ２０３）。もし、状態フ
ラグ＝０ではない場合、すなわち状態フラグ＝１である
場合には、次のレコードを読み出す（ステップＳ２０
５）。そしてステップＳ２０３に戻る。

【００８３】状態フラグ＝０である場合には、現在時刻
が当該レコードの期限時刻以降になっているか確認する
（ステップＳ２０７）。もし、現在時刻が期限時刻より
前である場合にはステップＳ２０５に移行する。一方、
現在時刻が期限時刻以降である場合には、代表番号管理
テーブルの当該レコードの状態フラグを１に設定する
（ステップＳ２０９）。すなわち、自動的に購入完了指
示がなされたことにして、宅配要求の受付を締め切る。
そして、制限時刻超過による自動購入完了の通知を当該
代表番号に対応するユーザに対して例えば電子メールで
送信する（ステップＳ２１１）。例えば、「制限時刻ま
でに購入完了通知を受け取りませんでしたので、自動的
に締め切りました」といったメッセージを含む通知を行
う。電子メール・アドレスなどのユーザへの通知先につ
いてはユーザマスタＤＢ３５に格納された情報を用い
る。ステップＳ２１１の後にステップＳ２０５に戻る。
なお、ステップＳ２０５で次のレコードがない場合には
第１レコードに戻るようにする。

【００８４】これにより次に述べる梱包指示処理が自動
的に行われるようになり、配送業者による梱包及び配送
が開始される。図２５を用いて梱包指示処理について説
明する。最初に、梱包配送関連処理部３３は、代表番号
管理テーブルの第１レコードを読み出す（ステップＳ２
１３）。そして、当該レコードの状態フラグが１である
か判断する（ステップＳ２１５）。すなわち、購入完了
が設定されたか否かを確認する。もし、状態フラグ＝０
であれば次のレコードを読み出し（ステップＳ２１
７）、ステップＳ２１５に移行する。

【００８５】一方、状態フラグ＝１の場合には、現在時
刻が期限時刻から所定時間Ｃ（例えば５分）経過した時
刻以降であるか確認する（ステップＳ２１７）。所定時
間Ｃは期限時刻経過後ユーザによる延長指示を受け付け
る時間である。なお、延長指示を受け付けない場合には
現在時刻が期限時刻を経過したかを確認すればよい。も
し、現在時刻が期限時刻から所定時間Ｃ経過した時刻よ
り前の場合にはステップＳ２１７に移行する。

【００８６】もし、現在時刻が期限時刻から所定時間Ｃ
経過した時刻より遅い場合には、配送業者への配送指示
情報（図２２）を生成し、配送業者サーバ１５に送信す
る（ステップＳ２１９）。そして、配送管理テーブル
（図８）に新規レコードを生成し、当該代表番号を登録
し、購入完了指示チェックを１にセットし、購入完了指
示を受信した年月日及び時刻の情報を記録する。また、
梱包指示チェックを１にセットし、梱包指示を送信した
年月日及び時刻として本処理時の時刻の情報を記憶する
（ステップＳ２２１）。そしてステップＳ２１７に移行
する。ステップＳ２１７では、次のレコードがなければ
第１レコードを読み出す。

【００８７】ユーザは、任意の時間に自己の宅配要求の
確認を行うことができる。例えば、購入期限時刻の警告
通知や自動購入完了の通知の電子メールには、宅配依頼
受付確認ページへのリンクを含めておく。ユーザは、当
該リンクを選択することにより、宅配依頼受付確認ペー
ジにアクセスすることができる。その他、センタ・サー
バ３のメインメニューから辿って宅配依頼受付確認ペー
ジに遷移するようにしてもよい。なお、宅配依頼受付確
認ページの内容は、アクセスのタイミングにより異な
る。以下、購入完了指示に伴って宅配依頼受付確認ペー
ジが表示される場合を除き、宅配依頼受付確認ページに
アクセスする際の処理について図２６乃至図２８を用い
て説明する。

【００８８】携帯電話機７等のユーザ端末は、ユーザの
指示に従って、宅配依頼受付確認ページへアクセスする
（ステップＳ２３１）。センタ・サーバ３の梱包配送関
連処理部３３は、ユーザ端末から宅配依頼受付確認ペー
ジへのアクセスを受信する（ステップＳ２３３）。梱包
配送関連処理部３３は、アクセスに応じてユーザＩＤ及
び代表番号を識別する（ステップＳ２３５）。例えば購
入期限時刻の警告通知や自動購入完了の通知に含まれる
リンク・アドレスがユーザＩＤと代表番号の組み合わせ
にて構成されているような場合には、この情報を用いれ
ばよい。また、このページへのアクセスまでにユーザＩ
Ｄ及び代表番号が入力されていれば、その情報を用い
る。なお、ユーザＩＤで代表番号管理テーブル（図５）
を検索し、代表番号を抽出しても良い。認証処理を実施
するような場合もある。

【００８９】次に、代表番号で代表番号管理テーブルを
検索して該当レコードを読み出し、現在時刻が当該レコ
ードの期限時刻から所定時間Ｃ経過した時刻以降になっ
ているか確認する（ステップＳ２３７）。すなわち、延
長可能な時刻を経過したか否かを判断する。もし、現在
時刻が制限時刻から所定時間Ｃ経過した時刻以降であれ
ば、端子Ｆを介して図２７の処理に移行する。一方、現
在時刻が制限時刻から所定時間Ｃ経過した時刻より前で
あれば、延長フラグが０であるか判断する（ステップＳ
２３９）。延長フラグ＝０は、まだ一度も購入期限を延
長したことがないということである。本実施の形態では
延長は１回のみであり、既に一度延長している場合には
端子Ｇを介して図１９のステップＳ１６７に移行する。
すなわち、現在時刻は延長可能な時間ではあるが、既に
一度延長していてもう延長できないので、延長を指示で
きないような宅配依頼受付確認ページを表示するように
する。これは、ユーザにより購入完了指示が行われた場
合と同じである。

【００９０】一方、延長フラグ＝０である場合には、当
該代表番号に関係する宅配受付テーブル（図６）の全レ
コードの情報を読み出し（ステップＳ２４１）、配送料
見積処理（図１７）を実施する（ステップＳ２４３）。
そして、配送料見積結果及び残り時間（＝期限時刻−現
在時刻）を含む宅配依頼受付確認ページ・データ（図２
１）を生成し、ユーザ端末に送信する（ステップＳ２４
５）。ユーザ端末は、宅配依頼受付確認ページ・データ
を受信し、表示装置に表示する（ステップＳ２４７）。
ステップＳ２４７において表示される宅配依頼受付確認
ページには、ＹＥＳボタン９０９、修正ボタン９１０、
延長ボタン９１１とが設けられている。従って、ユーザ
は、確認応答、修正応答、延長応答を指示することがで
きる。

【００９１】ユーザ端末は、ユーザの指示に従って応答
をセンタ・サーバ３に送信する（ステップＳ２４９）。
センタ・サーバ３の梱包配送関連処理部３３は、ユーザ
端末から応答を受信し（ステップＳ２５１）、確認応答
であるか判断する（ステップＳ２５３）。確認応答であ
れば、端子Ｃを介して図１９のステップＳ１７９に移行
する。一方、確認応答でなければ延長応答であるか判断
する（ステップＳ２５５）。延長応答であれば端子Ｅを
介して図２８の処理に移行する。一方、延長応答でなけ
れば修正応答であり、この場合には端子Ｈを介して図２
３の処理に移行する。なお、図２３において端子Ｈから
遷移してきた場合には、端子Ｄを介して図２６のステッ
プＳ２４３に戻る。

【００９２】次に、端子Ｆを介して図２６のステップＳ
２３７から遷移した場合の処理を図２７を用いて説明す
る。梱包配送関連処理部３３は、まず配送業者サーバ１
５から確定配送料を受信したか判断する（ステップＳ２
６１）。もし配送業者サーバ１５から確定配送料を受信
していれば、配送管理テーブル（図８）に確定配送料が
登録されている（発送済チェックが１である）ので、そ
れにより判断することができる。もし、確定配送料を受
信していれば、当該代表番号に関係する宅配受付テーブ
ル（図６）の全レコードの情報を読み出す（ステップＳ
２６７）。また、配送管理テーブル（図８）から確定配
送料の情報を読み出す（ステップＳ２６９）。

【００９３】一方、確定配送料を受信していない場合に
は、当該代表番号に関連する宅配受付テーブル（図６）
の全レコードの情報を読み出し（ステップＳ２６３）、
配送料見積処理（図１７）を実施する（ステップＳ２６
５）。

【００９４】そして、ステップＳ２６５又はステップＳ
２６９の後に、宅配受付テーブル（図６）の関連する全
レコードの情報及び配送料見積結果又は確定配送料の情
報を含む宅配依頼受付確認ページ・データを生成し、ユ
ーザ端末に送信する（ステップＳ２７１）。ユーザ端末
は、センタ・サーバ３から宅配依頼受付確認ページ・デ
ータを受信し、表示装置に表示する（ステップＳ２７
３）。このステップＳ２７３において表示される宅配依
頼受付確認ページには、修正ボタン９１０、延長ボタン
９１１は無い。この段階においては既に梱包指示を配送
業者サーバ１５に送信してしまっているので、修正も延
長も不可能な状態にある。従って、本ステップにおいて
はそのためのボタンが表示されないようになっている。
従って、ユーザが指示する応答は、確認応答しかない。
ユーザが、ＹＥＳボタン９０９をクリックすると、ユー
ザ端末は応答をセンタ・サーバ３に送信する（ステップ
Ｓ２７５）。センタ・サーバ３は、ユーザ端末から応答
を受信する（ステップＳ２７７）。これ以上の処理は、
例えば他のメニュー画面に遷移するような構成であって
も良い。

【００９５】次に、図２８を用いて図２６のステップＳ
２５５で延長応答であると判断された場合の処理を説明
する。この処理は端子Ｅを介して図２８に遷移してい
る。最初に梱包配送関連処理部３３は、代表番号管理テ
ーブル（図５）の当該代表番号のレコードについて期限
時刻を現在の期限時刻＋所定時間Ｄ（例えば１時間）の
時刻に更新する（ステップＳ２８１）。また、当該レコ
ードの延長フラグを１にセットし、状態フラグ及び通知
フラグを０に設定する（ステップＳ２８３）。そして、
延長了承ページ・データを生成し、ユーザ端末に送信す
る（ステップＳ２８５）。ユーザ端末は、センタ・サー
バ３から延長了承ページ・データを受信し、表示装置に
表示する（ステップＳ２８７）。

【００９６】このようにして期限時刻の延長が行われ、
ユーザはショッピングを継続して追加の宅配要求を送信
することができるようになる。なお、状態フラグ＝０で
あるから、再度購入完了又は自動購入完了処理が必要に
なる。また、通知フラグ＝０であるから、新たな期限前
に再度通知を受けることができる。

【００９７】以上本発明の一実施の形態を説明したが、
本発明はこれに限定されるものではない。特に、集荷指
示処理については、単純に宅配要求をユーザ端末から受
信する毎に実施しても良いが、図２９のような処理を実
施するようにしても良い。

【００９８】すなわち、集荷関連処理部３２は、店舗マ
スタＤＢ３６を参照して商品購入店舗がグループ登録さ
れているか判断する（ステップＳ２９１）。すなわち、
店舗マスタＤＢ３６の集荷グループの欄７０９にグルー
プ番号が登録されているかを判断する。もし、登録され
ていない場合には、直ぐに集荷指示を生成して、配送業
者サーバ１５に送信する（ステップＳ３０７）。そし
て、集荷管理テーブル（図７）の集荷指示チェックを１
にセットし、送信年月日及び時刻を登録する（ステップ
Ｓ３０９）。そして元の処理に戻る。

【００９９】一方、グループ登録されている店舗である
場合には、商品購入店舗がアンテナ店であるか判断する
（ステップＳ２９３）。店舗マスタＤＢ３６（図４）の
アンテナ店の集荷基準の欄７０８に何らかの数字が登録
されているかで判断する。もし、アンテナ店でなけれ
ば、ステップＳ３０３に移行する。一方、アンテナ店で
あれば、集荷管理テーブル（図７）を商品購入店舗の登
録番号で検索して、集荷基準データを取得する（ステッ
プＳ２９５）。そして、購入数が当該商品購入店舗の集
荷基準を超えたか判断する（ステップＳ２９７）。な
お、集荷指示済チェックが０であるレコードのみカウン
トする。もし集荷管理テーブル（図７）において購入数
が集荷基準を超えていない場合にはステップＳ３０３に
移行する。

【０１００】もし集荷管理テーブルにおいて購入数が集
荷基準を超えている場合には、当該アンテナ店と同一グ
ループに属する店舗の購入商品を、集荷管理テーブルか
ら抽出する。この際集荷指示済チェックが０であるレコ
ードのみを抽出する。そして、抽出された購入商品に係
る集荷指示の情報を生成し、配送業者サーバ１５に送信
する（ステップＳ２９９）。集荷管理テーブルにおいて
集荷指示に係るレコードの集荷指示済フラグを１にセッ
トし、集荷指示送信の年月日及び時刻を登録する（ステ
ップＳ３０１）。そして元の処理に戻る。

【０１０１】なお、アンテナ店において集荷基準に達し
ないと集荷指示を出さないということにすると、何日か
集荷がなされない場合も生じ得るので、本実施の形態で
はステップＳ２９３でアンテナ店ではないと判断された
場合及びアンテナ店で購入数が集荷基準を超えない場
合、所定の時刻において、集荷指示を出していない購入
商品（集荷指示済チェックが０）を集荷管理テーブルを
抽出し、抽出した購入商品についての集荷指示の情報を
生成し、配送業者サーバ１５に送信する（ステップＳ３
０３）。そして、集荷管理テーブルにおいて集荷指示に
係るレコードの集荷指示済チェックを１にセットし、集
荷指示送信の年月日及び時刻を登録する（ステップＳ３
０５）。そして元の処理に戻る。

【０１０２】また、上では必ず店舗に配送業者が集荷に
行くことを前提としているが、近年配送業者が自己の倉
庫に複数の店舗の商品をストックしておき、その倉庫か
ら顧客に対して配送するような場合もあるため、本発明
においてもこのような構成をそのまま適用することがで
きる。その際には、センタ・サーバ３から集荷指示をそ
のまま配送業者サーバ１５に送信し、配送業者サーバ１
５において倉庫からピッキングするような商品であるか
否かを判断するようにすればよい。

【０１０３】また、上では店舗が通常の集荷範囲外であ
る場合及び商品が特種品又は過大サイズの場合に、別口
配送するような構成を示したが、これらをさらに分類し
て配送の仕方を変えるようにしても良い。

【０１０４】さらに図２のシステム概要図における機能
ブロックは一例であり、実際のプログラムのモジュール
を別の態様にて分けることも可能である。また、データ
の格納態様についても図２に示したような分け方でなく
とも良い。図１３、図１６、図２０、図２１の画面例の
画面構成は一例であって、これに限定されず、同様の内
容を表示するものであればよい。上でも述べたが各画面
は複数の画面に分割して提示される場合もある。

【０１０５】ＩＤの入力を求める画面例を示している
が、ユーザＩＤの入力については、サブスクライバＩＤ
やＩＰｖ６のアドレスにより省略される場合もある。ユ
ーザＩＤ入力欄についてはユーザＩＤが埋め込まれた状
態でＷｅｂページ・データが生成・送信・表示される場
合もある。

【０１０６】なお、上で述べた例では配送業者が１社で
あるような例を示しているが、複数の配送業者が連携す
る場合もあり得る。また、別の交通機関、例えばタクシ
ー等を本発明の集荷処理部分に組み込むような場合もあ
り得る。

【０１０７】（付記１）ユーザの端末から購入商品の購
入店舗からの配送の要求を受信した場合、当該配送の要
求に関する情報を記憶装置に格納する配送要求受信ステ
ップと、前記ユーザの端末から購入完了指示を受信した
場合、当該ユーザの端末から前記購入完了指示受信まで
に受信された前記配送の要求に係る全購入商品のうち所
定の条件に合致した購入商品の梱包指示を配送業者に対
して送信する梱包指示送信ステップと、を含む配送情報
処理方法。

【０１０８】（付記２）前記ユーザの端末から最初の配
送の要求を受信してから所定時間経過したにもかかわら
ず購入完了指示を受信しない場合、前記ユーザの端末か
ら前記所定時間経過までに受信された前記配送の要求に
係る全購入商品のうち所定の条件に合致した購入商品の
梱包指示を配送業者に対して送信する梱包指示送信ステ
ップ、をさらに含む付記１記載の配送情報処理方法。

【０１０９】（付記３）前記ユーザの端末から前記所定
時間の延長要求を受信した場合には、前記所定時間の延
長を記憶装置に設定するステップをさらに含む付記２記
載の配送情報処理方法。

【０１１０】（付記４）前記ユーザの端末から最初の配
送の要求を受信してから所定時間経過したにもかかわら
ず購入完了指示を受信しない場合、前記ユーザに対して
配送の要求の受付完了を通知するステップ、をさらに含
む付記２記載の配送情報処理方法。

【０１１１】（付記５）前記所定時間経過前の所定のタ
イミングにて、前記ユーザに対して配送の要求の受付完
了を予告するステップ、をさらに含む付記２記載の配送
情報処理方法。

【０１１２】（付記６）前記ユーザの端末から要求に応
じて、前記記憶装置に格納された前記配送の要求に関す
る情報を用いて配送料の見積りを実施し、当該配送料の
見積りの情報を前記ユーザの端末に送信するステップを
さらに含む付記１乃至５のいずれか１つ記載の配送情報
処理方法。

【０１１３】（付記７）前記ユーザの端末から購入商品
の購入店舗からの配送の要求を受信した場合、当該購入
商品の集荷指示を配送業者のコンピュータに送信するス
テップをさらに含む付記１乃至６のいずれか１つ記載の
配送情報処理方法。

【０１１４】（付記８）前記梱包指示に、前記ユーザに
より指示された配送先の情報を含むことを特徴とする付
記１乃至７のいずれか１つ記載の配送情報処理方法。

【０１１５】（付記９）前記ユーザの端末から購入商品
の購入店舗からの配送の要求を受信した場合、当該購入
商品の配送業者による少なくとも梱包に用いるための情
報を前記ユーザの端末又は前記購入店舗のコンピュータ
に送信するステップ、をさらに含む付記１乃至８のいず
れか１つ記載の配送情報処理方法。

【０１１６】（付記１０）前記所定の条件が、前記購入
店舗が予め特定された店舗以外の店舗であること又は前
記購入商品が予め特定された商品以外の商品であること
であることを特徴とする付記１乃至９のいずれか１つ記
載の配送情報処理方法。

【０１１７】（付記１１）前記配送業者における梱包に
より確定した配送料の情報を受信した場合、当該確定し
た配送料の情報を前記ユーザに対して通知するステップ
をさらに含む付記１乃至１０のいずれか１つ記載の配送
情報処理方法。

【０１１８】（付記１２）特定の購入店舗からの配送の
要求をユーザの端末から所定数以上受信した場合に、前
記特定の購入店舗及び当該特定の購入店舗に関連付けら
れた店舗についての購入商品の集荷要求を配送業者に対
して送信するステップをさらに含む付記１乃至１１記載
のいずれか１つ記載の配送情報処理方法。

【０１１９】（付記１３）前記ユーザの端末から配送要
求状況の確認要求を受信した場合、既に確定した配送料
の情報を配送業者から受信したか判断するステップと、
既に前記確定した配送料の情報を配送業者から受信して
いる場合には前記記憶装置に格納された前記配送の要求
に関する情報に含まれる購入商品の情報と前記確定した
配送料の情報とを前記ユーザに対して送信し、未だ前記
確定した配送料の情報を配送業者から受信していない場
合には前記記憶装置に格納された前記配送の要求に関す
る情報に含まれる購入商品の情報と配送料の見積結果と
を前記ユーザに対して送信するステップをさらに含む付
記１乃至１２のいずれか１つ記載の配送情報処理方法。

【０１２０】（付記１４）ユーザの端末から購入商品の
購入店舗からの配送の要求を受信した場合、当該配送の
要求に関する情報を記憶装置に格納する配送要求受信ス
テップと、所定のタイミング以降に、前記ユーザの端末
から前記所定のタイミングまでに受信された前記配送の
要求に係る全購入商品のうち所定の条件に合致した購入
商品の梱包指示を配送業者に対して送信する梱包指示送
信ステップと、を含む配送情報処理方法。

【０１２１】（付記１５）購入商品及び購入店舗につい
ての情報を含む購入商品の配送要求を少なくとも購入店
舗毎にセンタ・サーバに送信するステップと、全購入商
品のうち所定の条件を満たした購入商品の指定場所への
一括配送開始要求を前記センタ・サーバに送信するステ
ップと、を含む配送要求処理方法。

【０１２２】（付記１６）付記１乃至１４のいずれか１
つ記載の配送情報処理方法をコンピュータに実行させる
ためのプログラム。

【０１２３】（付記１７）ユーザの端末から購入商品の
購入店舗からの配送の要求を受信した場合、当該配送の
要求に関する情報を記憶装置に格納する配送要求受信手
段と、前記ユーザの端末から購入完了指示を受信した場
合、当該ユーザの端末から前記購入完了指示受信までに
受信された前記配送の要求に係る全購入商品のうち所定
の条件に合致した購入商品の梱包指示を配送業者に対し
て送信する梱包指示送信手段と、を含む配送情報処理シ
ステム。

【０１２４】

【発明の効果】以上のように本発明によれば、異なる店
舗において購入した物品についても一括して配送できる
ようになる。

【図面の簡単な説明】

【図１】本発明の一実施の形態に係るビジネスフローを
示す図である。

【図２】本発明の一実施の形態におけるシステム構成例
を示す図である。

【図３】ユーザマスタＤＢに格納されるデータの一例を
示す図である。

【図４】店舗マスタＤＢに格納されるデータの一例を示
す図である。

【図５】代表番号管理テーブルに格納されるデータの一
例を示す図である。

【図６】宅配受付テーブルに格納されるデータの一例を
示す図である。

【図７】集荷管理テーブルに格納されるデータの一例を
示す図である。

【図８】配送管理テーブルに格納されるデータの一例を
示す図である。

【図９】同梱見積りテーブルに格納されるデータの一例
を示す図である。

【図１０】特種品配送料テーブルに格納されるデータの
一例を示す図である。

【図１１】ポイントＤＢに格納されるデータの一例を示
す図である。

【図１２】本発明の一実施の形態に係る全体の処理フロ
ー（その１）を示す図である。

【図１３】宅配要求ページの一例を示す図である。

【図１４】本発明の一実施の形態に係る全体の処理フロ
ー（その２）を示す図である。

【図１５】宅配要求受付処理の処理フローを示す図であ
る。

【図１６】宅配依頼受付ページの一例を示す図である。

【図１７】配送料見積処理の処理フローを示す図であ
る。

【図１８】購入期限警告通知処理の処理フローを示す図
である。

【図１９】購入完了指示処理の処理フローを示す図であ
る。

【図２０】購入完了指示ページの一例を示す図である。

【図２１】宅配依頼受付完了ページの一例を示す図であ
る。

【図２２】梱包指示データの一例を示す図である。

【図２３】宅配要求の修正指示処理の処理フローを示す
図である。

【図２４】購入期限超過処理の処理フローを示す図であ
る。

【図２５】梱包指示処理の処理フローを示す図である。

【図２６】宅配依頼受付確認処理の処理フローを示す図
である。

【図２７】購入期限経過後の宅配依頼受付確認処理の処
理フローを示す図である。

【図２８】購入期限延長処理の処理フローを示す図であ
る。

【図２９】集荷指示処理の処理フローを示す図である。

【符号の説明】

１ ネットワーク ３ センタ・サーバ ５ ＰＤＡ ７ 携帯電話機 ９ ＩＣタグライタ １１ 伝票プリンタ １３ ＰＯＳレジスタ １５ 配送業者サーバ ３１ 宅配要求受付処理部 ３２ 集荷関連処理部 ３３ 梱包配送関連処理部 ３４ ポイント管理部 ３５ ユーザマスタＤＢ ３６ 店舗マスタＤＢ ３７ 荷物管理テーブル格納部 ３８ ポイントＤＢ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 國吉 房之 沖縄県那覇市久茂地１丁目12番12号 株式 会社沖縄富士通システムエンジニアリング 内 (72)発明者 平良 道彦 沖縄県那覇市久茂地１丁目12番12号 株式 会社沖縄富士通システムエンジニアリング 内

Claims (5)

【特許請求の範囲】
1. 【請求項１】ユーザの端末から購入商品の購入店舗から
   の配送の要求を受信した場合、当該配送の要求に関する
   情報を記憶装置に格納する配送要求受信ステップと、 前記ユーザの端末から購入完了指示を受信した場合、当
   該ユーザの端末から前記購入完了指示受信までに受信さ
   れた前記配送の要求に係る全購入商品のうち所定の条件
   に合致した購入商品の梱包指示を配送業者に対して送信
   する梱包指示送信ステップと、 を含む配送情報処理方法。
2. 【請求項２】前記ユーザの端末から最初の配送の要求を
   受信してから所定時間経過したにもかかわらず購入完了
   指示を受信しない場合、前記ユーザの端末から前記所定
   時間経過までに受信された前記配送の要求に係る全購入
   商品のうち所定の条件に合致した購入商品の梱包指示を
   配送業者に対して送信する梱包指示送信ステップ、 をさらに含む請求項１記載の配送情報処理方法。
3. 【請求項３】前記ユーザの端末から前記所定時間の延長
   要求を受信した場合には、前記所定時間の延長を記憶装
   置に設定するステップをさらに含む請求項２記載の配送
   情報処理方法。
4. 【請求項４】前記ユーザの端末から最初の配送の要求を
   受信してから所定時間経過したにもかかわらず購入完了
   指示を受信しない場合、前記ユーザに対して配送の要求
   の受付完了を通知するステップ、 をさらに含む請求項２記載の配送情報処理方法。
5. 【請求項５】前記所定時間経過前の所定のタイミングに
   て、前記ユーザに対して配送の要求の受付完了を予告す
   るステップ、 をさらに含む請求項２記載の配送情報処理方法。