以下、図面を参照して本発明の実施形態について詳細に説明する。なお、以下に説明する実施の形態は、配送システムに対して本発明を適用した場合の実施形態である。
[1.配送システムの構成及び機能概要]
先ず、本実施形態に係る配送システムSの構成及び機能概要について、図1及び図2を用いて説明する。図1は、本実施形態に係る配送システムSの概要構成の一例を示す図である。
図1に示すように、配送システムSは、データベース管理サーバ1と、電子商店街サーバ2と、宅配便サーバ3と、提携宅配業者サーバ4と、複数の配送センター端末5と、複数の配達員端末6と、複数の店舗端末7と、複数のユーザ端末8と、を含んで構成されている。電子商店街サーバ2及び宅配便サーバ3と、提携宅配業者サーバ4、配送センター端末5、配達員端末6、店舗端末7及びユーザ端末8とは、ネットワークNWを介して、例えば、通信プロトコルにTCP/IP等を用いて相互にデータの送受信が可能になっている。なお、ネットワークNWは、例えば、インターネット、専用通信回線(例えば、CATV(Community Antenna Television)回線)、移動体通信網(基地局等を含む)、及びゲートウェイ等により構築されている。また、データベース管理サーバ1と電子商店街サーバ2と宅配便サーバ3とは、ネットワークNLを介して相互にデータの送受信が可能になっている。ネットワークNLは、例えば、LAN(Local Area Network)である。
データベース管理サーバ1、電子商店街サーバ2及び宅配便サーバ3は、インターネット総合サービスを提供する会社であるX社が運営するサービス提供サイトのドメインに属するサーバ装置である。サービス提供サイトは、ネットワークを通じてユーザに各種のサービスを提供するためのWebサイトである。ユーザがサービス提供サイトへの会員登録を行うと、ユーザは、サービス提供サイトに属する各種サイトのサービスを利用することができる。
データベース管理サーバ1は、サービス提供サイトのドメインに属する各種サーバ装置が共通に使用する情報を登録しているデータベースを管理する。例えば、データベース管理サーバ1は、サービス提供サイトの会員に関する情報のデータベースである会員情報DB(データベース)1aを管理する。なお、本実施形態において、電子商店街サーバ2または宅配便サーバ3が会員情報DB1aから情報を取得するというとき、宅配便サーバ3または電子商店街サーバ2が、データベース管理サーバ1にリクエストを送信することにより、会員情報DB1aに登録されている情報をデータベース管理サーバ1から受信することを意味する。
電子商店街サーバ2は、サービス提供サイトに属する電子商店街に関する各種処理を実行するサーバ装置である。電子商店街においては、商品の販売者側として複数の店舗が出店している。各店舗は、電子商店街において購入された商品をユーザ等へ送付することにより、商品を提供する。ユーザは、電子商店街を利用することにより、所望の店舗から所望の商品を購入することができる。電子商店街サーバ2は、ユーザ端末8からのリクエストに応じて、例えば、電子商店街のWebページを送信したり、商品の検索や購入等に関する処理を行ったりする。
宅配便サーバ3は、電子商店街宅配便に関する各種の処理を実行するサーバ装置である。宅配便サーバ3は、本発明における情報処理装置の一例である。電子商店街宅配便は、電子商店街において購入された商品を配送するための宅配便である。ユーザは、電子商店街において商品を注文するとき、商品の配送方法を選択することができる。電子商店街宅配便は、選択可能な配送方法のうちの1つである。ユーザは、電子商店街宅配便を利用することにより、例えば、他の宅配便よりも配送料が安くなったり、商品の配送状況の確認や配達日時の変更をWebサイトで行ったりすることができる等のメリットを享受することができる。X社は、電子商店街宅配便を運営するため、各地に配送センターを設けたり、輸送トラックをチャーターしたりしている。配送センターは、商品を集荷したり、集荷した商品を配送したりするための施設である。現時点では、日本全国のうち一部の地域に、電子商店街宅配便の配送センターが設けられている。そのため、商品の配送先として、電子商店街宅配便を利用可能な地域が限られている。なお、将来的には、電子商店街宅配便の配送センターが日本全国に設けられ、何れの地域でも電子商店街宅配便を利用することができるようになる可能性もある。
提携宅配業者サーバ4は、宅配事業者であるY社により設置されたサーバ装置である。提携宅配業者サーバ4は、Y社により運営される宅配便に関する各種の処理を実行するサーバ装置である。電子商店街宅配便で商品の配送を行う場合、配送先として電子商店街宅配便を利用することができない地域にある店舗からも商品を集荷する必要がある。そのため、X社はY社と業務提携をしている。Y社は、配送先として電子商店街宅配便を利用することができない地域における商品の集荷を担当している。宅配便サーバ3と提携宅配業者サーバ4とが互いに情報をやりとりすることにより、例えば、X社からY社へ商品の集荷を依頼したり、Y社からX社へ商品の集荷状況を通知したりする。
配送センター端末5は、配送センターに設置された端末装置である。配送センター端末5としては、電子商店街宅配便の配送センターに設置された端末装置と、Y社の配送センターに設置された端末装置とがある。電子商店街宅配便の配送センターの配送センター端末5は、配送センターの従業員からの操作に基づいて宅配便サーバ3にアクセスする。また、Y社の配送センターの配送センター端末5は、提携宅配業者サーバ4にアクセスする。これらにより、配送センター端末5は、サーバ装置からWebページを受信して表示する。配送センター端末5には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。また、配送センター端末5には、商品に付された配送伝票から伝票番号を読み込むためのバーコードリーダ等が接続されている。配送伝票は、電子商店街宅配便での配送に用いられる伝票である。伝票番号は、配送伝票を識別するための識別番号である。従業員は、配送センター端末5を利用することにより、例えば、商品の配達予定日時等の情報を確認したり、商品の集荷状況や配送状況を登録したりする。配達予定日時は、商品の配達が予定されている日付及び時間帯である。配達予定日時における日付は、本発明における配達情報に含まれる配達日の一例である。配送センター端末5としては、例えば、パーソナルコンピュータ等が用いられる。
配達員端末6は、輸送トラックで商品を集荷したり配達したりする配達員により利用される携帯用の端末装置である。配達員端末6としては、電子商店街宅配便の端末装置と、Y社の端末装置とがある。電子商店街宅配便の配達員端末6は、配達員からの操作に基づいて宅配便サーバ3にアクセスする。また、Y社の配達員端末6は、提携宅配業者サーバ4にアクセスする。これらにより、配達員は、例えば、商品の集荷状況や配送状況を登録したりする。配達員端末6は、配送伝票から伝票番号を読み込むためのバーコードリーダ等を備える。
店舗端末7は、電子商店街に出店している店舗の従業員等により利用される端末装置である。店舗端末7は、従業員等からの操作に基づいて電子商店街サーバ2等のサーバ装置にアクセスする。これにより、店舗端末7は、サーバ装置からWebページを受信して表示する。店舗端末7には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。従業員は、店舗端末7を利用することにより、例えば、販売する商品の情報を電子商店街に登録したり、商品の注文内容を確認したりする。店舗端末7としては、例えば、パーソナルコンピュータ等が用いられる。
ユーザ端末8は、各種Webサイトを利用するユーザの端末装置である。ユーザ端末8は、ユーザからの操作に基づいて電子商店街サーバ2や宅配便サーバ3等のサーバ装置にアクセスする。これにより、ユーザ端末8は、サーバ装置からWebページを受信して表示する。ユーザ端末8には、ブラウザや電子メールクライアント等のソフトウェアが組み込まれている。ユーザ端末8としては、例えば、パーソナルコンピュータ、PDA(Personal Digital Assistant)、スマートフォン等の携帯情報端末、携帯電話機等が用いられる。
図2は、電子商店街宅配便において、商品の注文から商品の配達までの流れを示す図である。
図2に示すように、ユーザは、ユーザ端末8を操作して、電子商店街において、商品を注文する(図2(1))。このとき、ユーザは、配送方法として、電子商店街宅配便を指定する。また、ユーザは、必要に応じて、配達日時を指定する。なお、商品を注文するユーザを、「注文者」という。また、今回注文される商品を、「注文商品」という。
電子商店街サーバ2は、電子商店街宅配便を配送方法として指定した注文を受け付けると、配送依頼情報を宅配便サーバ3に送信する(図2(2))。配送依頼情報は、電子商店街から電子商店街宅配便へ商品の配送の依頼をするための情報である。宅配便サーバ3は、配送依頼情報に基づいて、配送管理情報を登録する。配送管理情報は、商品の配送の管理に用いられる情報である。配送管理情報は、本発明における配達情報の一例である。
宅配便サーバ3は、配送管理情報に基づいて、商品の注文先の店舗の店舗端末7へ、発送依頼情報を送信する(図2(3))。発送依頼情報は、店舗へ商品の発送を依頼するための情報である。店舗端末7は、例えば、発送依頼情報を画面に表示する。店舗は、発送依頼情報に基づいて商品の発送の準備を行うとともに、注文商品の配送伝票に表示する伝票番号の発行を電子商店街宅配便へ依頼する。すると、宅配便サーバ3は、伝票番号を発行して店舗端末7へ送信する。店舗は、発行された伝票番号、送付先の住所、氏名、郵便番号、電話番号等を配送伝票に印刷したり記載したりする。そして、店舗は、配送伝票を商品の包装に貼り付ける。商品によっては、注文先の店舗にその商品がなく、商品の製造者からの取り寄せとなる場合がある。この場合、店舗は、商品の発送を製造者に依頼するとともに、配送伝票を製造者に送付する。なお、宅配便サーバ3が発送依頼情報を送信する代わりに、電子商店街サーバ2が、発送依頼情報を店舗端末7へ送信してもよい。電子商店街サーバ2も、配送管理情報と同等の情報を保持しているので、発送依頼情報の送信が可能である。
また、宅配便サーバ3は、配送管理情報に基づいて、注文商品の集荷を担当する配送センターの配送センター端末5へ、集荷依頼情報を送信する(図2(4))。集荷依頼情報は、配送センターへ商品の集荷を依頼するための情報である。ここで、集荷を担当する配送センターがY社の配送センターである場合、宅配便サーバ3は提携宅配業者サーバ4へ集荷依頼情報を送信する。そして、提携宅配業者サーバ4が、集荷依頼情報を配送センター端末5へ送信する。配送センター端末5は、例えば、集荷依頼情報を画面に表示する。配送センターの従業員は、集荷依頼情報に基づいて、商品の集荷の準備を行う。
配送管理情報が登録されると、宅配便サーバ3は、注文商品の配送状況をユーザへ提供可能とさせる(図2(5))。例えば、店舗から商品が発送されたとき、商品が配送センターに運ばれてきたとき、商品が配送センターから商品の受取人へ配達されるとき、商品の配達が完了したとき等に、配達員が配達員端末6に商品の配送状況を入力したり、配送センターの従業員が配送センター端末5に商品の配送状況を入力したりする。入力された配送状況は、宅配便サーバ3により管理される。ユーザは、配送状況を表示するWebページである配送状況一覧ページにおいて、商品の配送状況や配達予定日を確認することができる。また、ユーザは、必要に応じて配達予定日時を変更することができる。なお、商品の注文時にユーザが配達日時を指定した場合、指定された配達日時が配達予定日時となる。
配送センターは、集荷依頼情報に基づいて、注文商品を店舗から集荷する(図2(6))。具体的に、配達員が輸送トラックで店舗や製造者の住所へ行き、店舗や製造者から商品を受け取る。そして、配達員は、受け取った商品を配送センターへ輸送する。その後、集荷された商品は、送付先の住所への配達を担当する配送センターへ回送される。Y社の配送センターに集荷された商品も、最終的には電子商店街宅配便の配送センターへ送られる。X社は、例えば、個々の配送センターを大規模化したり、配送センターの数を減らしたりする。これにより、X社は、商品を集荷した配送センターから配達を担当する配送センターまでに商品が経由する配送センターの数を減らす。これにより、電子商店街宅配便では、商品の配達に要する日数の削減が図られている。
商品の配達を担当する配送センターが、商品を配達するために商品を輸送トラックに積み込む前に、その旨が配送センター端末5から宅配便サーバ3へ送信される。そして、宅配便サーバ3は、輸送トラックに積み込まれる商品の配達予定日時を連絡するための電子メールである配達日時通知メールをユーザ宛てに送信する(図2(7))。
ユーザは、配達予定日時の直前になって、例えばその配達予定日時に外出する等、商品を受け取ることができなくなる場合がある。そこで、配達日時通知メールにより配達予定日時を確認したユーザは、配達日時通知メールに対して返信することにより、配達日時を変更する。このとき、ユーザは、返信する電子メールに、新しい配達予定日時を記入する。これにより、ユーザは、配達予定日時を変更することができる(図2(8))。ユーザが外出している場合であっても、配達予定日時が確実にユーザに通知されるように、配達日時通知メールの宛先の電子メールアドレスとして、携帯電話機の電子メールアドレスが用いられる。なお、ユーザは、配送状況一覧ページにアクセスすることにより、いつでも配達予定日時を変更することができる。
宅配便サーバ3は、配達予定日時が変更された場合、変更後の配達予定日時を、商品の配達を担当する配送センターの配送センター端末5や、商品を配達する配達員の配達員端末6へ送信する(図2(9))。
配達員は、配達予定日時が示す日付及び時間帯に、商品をユーザの住所へ配達する(図2(10))。配達予定日時が変更された場合には、変更後の配達予定日時に商品が配達される。
[2.配達日時の指定]
電子商店街宅配便においては、商品の注文時にユーザが配達日時を指定することができる。本実施形態における配達日時とは、商品が配達される日付及び時間帯である。指定可能な時間帯としては、例えば、午前中(8:00〜12:00)、12:00〜14:00、14:00〜16:00、16:00〜18:00、18:00〜20:00、20:00〜21:00等がある。電子商店街宅配便には、電子商店街で注文される商品の配達日時をユーザが容易に指定することができるようにする仕組みがある。その仕組みについて、図3及び図4を用いて説明する。
[2−1.受取可能日時の設定]
電子商店街宅配便では、商品を受け取ることができる日時をユーザが予め設定しておくことができる。商品を受け取ることができる日付及び時間帯を、「受取可能日時」という。受取可能日時における日付は、本発明における予め設定された日の一例である。受取可能日時は複数設定可能である。ユーザが商品の注文時に配達日時を指定しなかった場合、予め設定された受取可能日時が、その商品の配達予定日時として自動的に設定される。そのため、ユーザは、注文のたびにいちいち配達日時を指定しなくても、ユーザの都合がよい日時に商品を受け取ることができる。電子商店街で商品を頻繁に購入するユーザにとっては、特に便利である。
図3は、受取可能日時設定カレンダーページの画面表示例である。受取可能日時設定カレンダーページは、受取可能日時をユーザが設定するためのWebページである。受取可能日時設定カレンダーページは、ユーザ端末8が宅配便サーバ3にアクセスすることにより、宅配便サーバ3から送信される。
図3に示すように、受取可能日時設定カレンダーページには、カレンダー110等が表示される。カレンダー110は、受取可能日時を示すカレンダーである。具体的に、カレンダー110は、各曜日の欄を含むとともに、各曜日の欄に対応して、ユーザに指定された年月における各日付の欄が表示される。商品の受け取りが可能な日としてユーザにより指定された日付の欄には、商品の受け取りが可能な時間帯が表示される。なお、ユーザが日付のみを指定し、時間帯を指定しなかった場合には、その日付の欄には、「全日」が表示される。図3の例では、10月10日の16:00〜18:00等が受取可能日時として設定されている。
ユーザが何れかの日付の欄を選択すると、ユーザ端末8には、時間帯選択ウインドウが表示される。時間帯選択ウインドウには、受取可能時間帯を選択するためのチェックボックス等が表示される。時間帯選択ウインドウにおいて、ユーザが何れかの時間帯を選択すると、選択された日付及び時間帯が受取可能日時として設定される。また、時間帯選択ウインドウにおいて、全日を選択すると、選択された日付の全日が受取可能時間帯として設定される。この場合、実際には、選択された日付及び8:00〜21:00が受取可能日時として設定されたことと同様である。また、時間帯選択ウインドウにおいて、ユーザが全ての時間帯及び全日の選択を解除すると、選択された日付が、受取可能日から削除される。また、ユーザが何れかの曜日の欄を選択したときにも、時間帯選択ウインドウが表示される。これにより、ユーザは、曜日単位で受取可能日時を指定することができる。図3の例では、土曜日の午前中が受取可能日時として設定されている。
図4(a)及び図4(b)は、ユーザが商品の注文時に配達日時を指定しなかった場合における配達予定日時の決定例を示す図である。なお、理解を容易にするため、受取可能日時として、受取可能日及び受取可能時間帯のうち受取可能日のみが設定された場合を例として説明する。
図4(a)に示すように、ユーザが、例えば、10月1日、10月8日及び10月10日を受取可能日として設定していたとする。そして、ユーザは、商品Aを、配達日時を指定しないで注文したとする。この場合には、宅配便サーバ3において、配達予定日時が決定される。
商品の注文が受け付けられると、注文商品を最も早く配達可能な日時が算出される。この日時を、「最短配達可能日時」という。最短配達可能日時以降であれば、商品の配達が可能である。最短配達可能日時は、例えば、商品の配達に要する日数等によって決定される。この日数等は、例えば、注文された商品や、商品の送付先の住所等によって決まる。図4(a)の例では、商品Aの最短配達可能日時が10月3日に決定されたとする。
宅配便サーバ3は、設定されている受取可能日時のうち、商品を配達可能な最先の日時を、配達予定日時として決定する。図4(a)の例では、受取可能日のうち、商品Aの配達が可能な日は10月8日及び10月10日である。また、10月8日及び10月10日のうち、10月8日の方が早い。そのため、図4(b)に示すように、10月8日が配達予定日として決定される。これにより、ユーザは、自分の都合がよい日時のうち極力早い日時に、商品を受け取ることができる。
また例えば、商品Aの最短配達可能日が10月12日であるとする。この場合、商品Aを配達可能な受取可能日が存在しない。そのため、この場合は、最短配達可能日である10月12日が、配達予定日として決定される。受取可能日が1つも設定されていない場合にも、最短配達可能日が配達予定日として決定される。
また、注文商品が注文先の店舗から発送される場合には、その商品が店舗からいつ頃発送されるかが、ある程度決まっている。そのため、注文が行われた時点で最短配達可能日時を決定することができる。一方、注文商品が製造者から取り寄せとなる場合、製造者からその商品がいつ頃発送されるかが不明である。そのため、注文が行われた時点では最短配達可能日時は決定されない。この場合、製造者から商品が発送されるとき、すなわち、配達員が製造者から商品を受け取ったときに、最短配達可能日時が決定される。
なお、配達日時として、配達日及び配達時間帯のうち、配達時間帯のみが指定された場合の配達予定日時の決定方法は任意である。例えば、宅配便サーバ3は、最短配達可能日時以降に、指定された配達時間帯が最初に到来する日を、配達予定日時とし、指定された配達時間帯を配達予定時間帯としてもよい。例えば、指定された時間帯が14:00〜16:00であり、最短配達可能日時が10月1日の20:00〜21:00であるとする。この場合、10月2日の14:00〜16:00が配達予定日時となる。また例えば、宅配便サーバ3は、受取可能時間帯が、指定された配達時間帯を含む受取可能日時のうち、受取可能日が最も早い受取可能日時の受取可能日を配達予定日時とし、指定された配達時間帯を配達予定時間帯としてもよい。例えば、指定された時間帯が14:00〜16:00であり、最短配達可能日時以降の受取可能日時が、10月2日の12:00〜14:00、10月3日の全日、及び10月4日の14:00〜16:00であるとする。この場合、10月3日の14:00〜16:00が配達予定日時となる。
[2−2.注文済商品の配達予定日時の自動変更]
電子商店街宅配便では、ユーザが、配達日時として、配達日及び配達時間帯のうち少なくとも配達日を指定して商品を注文した場合、既に注文されている商品の配達予定日時が、今回指定された配達日時に変更される。既に注文されている商品を、「注文済商品」という。ユーザは、受取可能日時を設定することにより、配達日時を指定せずに注文した商品の配達予定日時が自動的に設定されるが、その後、その配達予定日時に商品を受け取ることができなくなる場合がある。その場合、配達予定日時を変更する必要がある。
一方、受取可能日時の設定により、注文される商品の配達予定日時が自動的に設定されるにもかかわらず、ユーザが配達日時を指定する場合には、設定されている受取可能日時以外の日時に商品を受け取りたいとユーザが考えている蓋然性がある。または、設定されている複数の受取可能日時のうち商品を受け取る日時を明示的に指定したいとユーザが考えている蓋然性がある。この場合、ユーザは、注文済商品の配達予定日時を、今回指定した配達日時に変更したいと考えている蓋然性がある。そこで、この場合に、宅配便サーバ3が注文済商品の配達予定日時を変更することで、ユーザは、注文済商品についていちいち配達予定日時を変更する操作を行う必要がない。なお、ユーザが注文済商品の配達予定日時を変更したいと考えていなかったとしても、ユーザは、自分が指定した配達日時に注文済商品を受け取ることができるものと考えられる。よって、注文済商品の配達予定日時が変更されても差し支えはない。
図4(c)及び図4(d)は、ユーザが商品の注文時に配達日時を指定した場合における配達予定日時の決定例を示す図である。
図4(a)及び図4(b)を用いて説明したように、商品Aの配達予定日が10月8日に決定されたとする。その後、図4(c)に示すように、ユーザは、商品Bを、配達日を指定して注文したとする。このときの配達日は、10月4日である。すると、図4(d)に示すように、商品Bの配達予定日時は10月4日となる。また、注文済商品である商品Aの配達予定日時は、10月8日から10月4日に変更される。
なお、例えば、指定配達日時が10月2日であったとする。商品Aの最短配達可能日は、10月3日であるため、商品Aを10月2日に配達することはできない。そのため、商品Bの配達予定日時は10月2日となるが、商品Aの配達日時は変更されない。
その後も、ユーザが商品の注文時に配達日時を指定した場合、注文済商品の配達予定日時が変更される。例えば、ユーザが配達日時として10月5日を指定して商品Cを注文した場合、商品Cの配達予定日時は10月5日となるとともに、商品A及びBの配達予定日時が10月5日に変更される。
注文済商品の配達予定日時が変更されることによって、注文済商品の配達予定日時が変更前の注文済商品の配達予定日時よりも早くなった場合、宅配便サーバ3は、配達日時変更通知メールを送信する。配達日時変更通知メールは、本発明における配達予定日時が変更されたことを通知する電子メールの一例である。配達日時変更通知メールが送信される理由は、ユーザが知らないうちに、変更後の配達予定日時に配達員が商品の配達に向かうことを防止するためである。ユーザは、配達日時変更通知メールにより、配達予定日時が繰り上げられたことを知ると、必要に応じて、配達予定日時を変更することができる。
また、ユーザは、商品を注文するときに、注文する商品の配達予定日時が自動的に変更されないように選択することも可能である。
[2−3.注文者の住所と受取人の住所とが異なる場合]
ユーザが商品を注文すると、通常は注文したユーザの住所へ商品が配達される。具体的には、注文者の会員情報に設定されている住所へ商品が配達される。注文者の会員情報に設定されている住所を、「会員登録した住所」という。その一方で、ユーザは、商品を注文するとき、商品の送付先として、商品の受取人の住所、氏名等の情報を入力することにより、自分以外の者を受取人として指定することができる。商品の送付先を示す情報を、「送付先情報」という。この場合における商品の配達予定日時の決定方法について説明する。商品の注文の際にユーザが入力する送付先情報は、本発明における特定情報の一例である。送付先情報は、商品の受取人を特定することができる情報である。
注文者が配達日時を指定しないで商品を注文した場合であって、且つ、受取人がサービス提供サイトの会員である場合には、受取人が設定した受取可能日時のうち、注文された商品を配達可能な最先の日時が、配達予定日時として決定される。例えば、受取人がサービス提供サイトの会員であるか否かは、入力された送付先情報に基づいて判定することができる。
注文者が配達日時を指定しないで商品を注文した場合であって、且つ、受取人がサービス提供サイトの会員ではない場合には、注文された商品の最短配達可能日時が、配達予定日時として決定される。
注文者が配達日時を指定して商品を注文した場合には、指定された配達日時が配達予定日時として決定される。また、この場合は、受取人がサービス提供サイトの会員であるか否かにかかわらず、受取人に配達される注文済商品の配達予定日時は変更されない。他人による配達日時の指定により、受取人の注文済商品の配達予定日時が変更されることは妥当ではないからである。
[2−4.家族登録]
サービス提供サイトにおいては、会員登録されているユーザが家族であることを登録しておくことができる。これを、「家族登録」という。これにより、ユーザは、家族として登録された他のユーザの情報を利用したサービスの提供を受けることができる。電子商店街宅配便においては、家族として登録されたユーザの情報に基づいて、商品の配達予定日時が決定される場合がある。
以下、ユーザU1とユーザU2とが家族として登録する場合を例として説明する。ユーザU1及びユーザU2は、それぞれサービス提供サイトの会員登録を行う。このとき、ユーザU1及びユーザU2は、それぞれ氏名、郵便番号、住所、電話番号等を入力する。入力された情報は、会員情報として、データベース管理サーバ1により会員情報DB1aに登録される。会員登録が行われると、登録されたそれぞれのユーザに、ユーザIDが付与される。ユーザIDは、ユーザを識別する情報である。ユーザIDは、本発明における識別情報の一例である。その後、ユーザU1が、家族登録を行うために、ユーザU1の家族のユーザIDとして、ユーザ2のユーザIDを指定する。すると、サービス提供サイトからユーザU2宛てに、家族登録が行われようとする旨を通知する電子メールが送信される。ユーザU2は、ユーザ端末8を操作してサービス提供サイトにアクセスし、ユーザU1による家族登録を許可する操作を行うと、データベース管理サーバ1により、ユーザU1とユーザU2とが家族として関連付けられる。ユーザIDが指定された方のユーザを、「家族の代表者」という。この場合、ユーザU2が家族の代表者である。
また、ユーザU1は、電子商店街で購入する商品の送付先情報として、ユーザU2の会員登録した住所を利用してよいか否かを選択する。つまり、ユーザU1の住所がユーザU2の住所と同じでよいか否かを選択する。ここで、ユーザU2の会員登録した住所を利用すると選択された場合、ユーザU1が注文した商品は、ユーザU2の会員登録した住所に配達される。つまり、ユーザU1の住所がユーザU2の住所と同じであるとみなされる。そして、ユーザU1が注文した商品とユーザU2が注文した商品とは互いに同じ住所に配達されることになる。
注文者としてユーザU1及びユーザU2の何れか一方が、会員登録した住所を商品の送付先とし、配達日時を指定しないで商品を注文した場合、ユーザU1が設定した受取可能日時と、ユーザU2が設定した受取可能日時とのうち、注文された商品を配達可能な最先の日時が、配達予定日時として決定される。つまり、家族全体を受取人自身とみなして配達予定日時が決定される。
また、ユーザU1及びユーザU2の何れか一方が、会員登録した住所を商品の送付先とし、配達日時を指定して商品を注文した場合、ユーザU1に配達される注文済商品の配達予定日時及びユーザU2に配達される注文済商品の配達予定日時の何れもが、注文者が今回指定した配達日時に変更される。つまり、家族全体を注文者自身とみなして配達予定日時が変更される。
なお、ユーザは、商品を注文するとき、他の家族とは別途商品を配達することを選択することができる。この場合、その商品については、家族が設定した受取可能日時が配達予定日時としては設定されず、また、家族が配達日時を指定したことによっては、配達予定日時は変更されない。
家族登録時に、ユーザU1が、電子商店街で購入する商品の送付先情報として、ユーザU2の会員登録した住所を利用しないと選択された場合、ユーザU1が注文した商品は、ユーザU1の会員登録した住所に配達される。この場合、ユーザU1及びユーザU2の何れか一方が注文した商品については、他方が設定した受取可能日時が配達予定日時としては設定されない。また、ユーザU1及びユーザU2の何れか一方が配達日時を指定した場合、他方を受取人とする注文済商品の配達予定日時は変更されない。
[2−5.ポイントの付与]
サービス提供サイトにおいては、ユーザによるサービス提供サイトの利用状況に応じて、ユーザにポイントが付与される。ポイントは、サービス提供サイトにおいて、金銭と同等の価値を有するものとして、例えばサービスの利用代金等に充てることができるものである。例えば、ユーザが電子商店街で商品を購入するときに、ポイントの購入代金の一部または全部に充てることができる。つまり、ポイントは、商品やサービス等の取引対象の売買の際に交換手段として用いられる。
電子商店街宅配便においては、商品の配送コストを削減するような態様で商品を受け取ったユーザに対し、その対価、報酬または謝礼としてポイントが付与される。この仕組みが、配送料が安くするための一助となっている。ユーザに付与されるポイントは、本発明における報酬情報の一例である。
具体的に、注文された商品の1回目の配達でユーザが商品を受け取った場合、そのユーザに対してポイントが付与される。配達員が商品を配達しようとした場合に受取人が不在であった場合、配達員は、改めて商品の再配達に行かなければならない。1回目の配達でユーザが商品を受け取った場合には、再配達が不要な分、配送コストを削減することができる。
ユーザは、予め受取可能日時を設定しておくことができる。また、ユーザは、配達予定日時の変更を行うことができる。これらにより、1回目の配達で商品を受け取る割合が高くなることが期待される。
また、配送伝票の伝票番号が互いに異なる複数の商品を一括してユーザが受け取った場合、そのユーザに対してポイントが付与される。商品には、配送される単位で配送伝票が付され、伝票番号ごとに商品の配送が管理される。つまり、伝票番号が互いに異なる複数の商品は、配送に関しては基本的に互いに独立して扱われる。配達員が、複数の商品のそれぞれを別々の日時に配達すると、配達する回数分の配送コストを要する。これに対して、配達員がこれらの商品を一括して配達すれば、配達コストを1回分のコストに削減することができる。なお、ユーザが同時に受け取った商品の数が多くなるほど、付与されるポイント数が多くなるようになっていてもよい。
ユーザは、予め受取可能日時を設定しておくことができる。そのため、受取可能日時に、ある程度まとめて複数の商品が配達されることが期待される。また、ユーザが配達日時を指定して商品を注文した場合、注文済商品の配達予定日時が、今回注文された商品の配達予定日時と同一となる。そのため、複数の商品が一括で配達されることになる。また、ユーザは、配達予定日時を変更することにより、複数の商品の配達日時を互いに一致させることができる。
また、ユーザは、商品の注文完了時に、任意の注文済商品を、今回注文する商品と一括で配達するように指定することができる。このとき、今回注文した商品の注文先の店舗と、注文済商品の注文先の店舗とが異なっていてもよい。つまり、ユーザは、伝票番号が互いに異なる複数の商品を一括して配達するように指定することができる。ユーザからの指定によって伝票番号が互いに異なる複数の商品を一括して配達することを、「一括配達」という。
ユーザが商品の注文時に配達日時を指定せずに、注文済商品との一括配達を指定した場合には、今回注文された商品と、指定された注文済商品との何れもが配達可能な受取可能日時の中から、今回注文された商品の配達予定日時が決定される。また、指定された注文済商品の配達予定日時が、今回注文された商品の配達予定日時に変更される。
また、ユーザが商品の注文時に配達日時を指定して、注文済商品との一括配達を指定した場合には、上述したように注文済商品の配達予定日時は、今回指定された配達日時に変更される。つまり、ユーザが注文時に配達日時を指定するか否かにかかわらず、一括配達が指定された複数の商品の配達予定日時は、互いに同一となる。
その後、一括配達が指定された複数の商品は、配達日時に関しては一括して扱われることになる。具体的に、ユーザが商品の注文時に配達日時を指定した場合であって、注文済商品の中に既に一括配達が指定された複数の注文済商品が存在する場合、その複数の注文済商品の何れもが、今回指定された配達日時に配達可能である場合にのみ、一括配達が指定された複数の注文済商品の配達予定日時が一括して変更される。つまり、今回指定された配達日時に配達可能ではない商品が1つでも存在する場合には、一括配達が指定された注文済商品の配達予定日時は変更されない。こうして、ユーザが一括配達を指定した複数の商品は、一括で配達されることが担保される。
[3.各サーバ装置及びデータベースの構成]
次に、各サーバ装置の構成及びデータベースの構成について、図5乃至図8を用いて説明する。
[3−1.データベースサーバの構成]
図5(a)は会員情報DB1aに登録される内容の一例を示す図である。データベース管理サーバ1は、CPU(Central Processing Unit)等により構成されているシステム制御部、ハードディスクドライブ等により構成されている記憶部、通信部等を備える。データベース管理サーバ1の記憶部には、会員情報DB1aが構築されている。
会員情報DB1aには、サービス提供サイトに会員登録しているユーザに関する会員情報が登録されている。具体的に、会員情報DB1aには、ユーザID、パスワード、ニックネーム、氏名、生年月日、性別、郵便番号、住所、電話番号、主メールアドレス、携帯メールアドレス、保有ポイント数、家族登録情報等のユーザの属性が、ユーザごとに対応付けて登録される。
主メールアドレスは、ユーザが主に利用する電子メールアドレスである。携帯メールアドレスは、携帯電話機の電子メールアドレスである。具体的に、携帯メールアドレスは、携帯電話機の利用契約先の移動体通信事業者からユーザに付与された電子メールアドレスである。保有ポイント数は、ユーザが保有しているポイントの数である。
家族登録情報は、家族登録に関する情報である。例えば、家族登録情報は、会員情報が示すユーザの家族として登録された他のユーザのユーザIDを含む。また、家族登録情報は、会員情報が示すユーザが家族の代表者であるか否かを示す情報を含む。また、会員情報が示すユーザが家族の代表者ではない場合、家族登録情報は、何れのユーザが家族の代表者であるか否かを示す情報と、会員情報が示すユーザが家族の代表者の会員登録された住所を商品の送付先の住所として利用することが選択されているか否かを示す情報を含む。また、家族登録情報は、家族の代表者の会員登録された住所を商品の送付先の住所として利用することを選択したユーザのユーザIDを別途含む。
[3−2.電子商店街サーバの構成]
図6は、本実施形態に係る電子商店街サーバ2の概要構成の一例を示すブロック図である。図6に示すように、電子商店街サーバ2は、通信部21と、記憶部22と、入出力インターフェース23と、システム制御部24と、を備えている。そして、システム制御部24と入出力インターフェース23とは、システムバス25を介して接続されている。
通信部21は、ネットワークNWやNLに接続して、他のサーバ装置や端末装置との通信状態を制御するようになっている。
記憶部22は、例えば、ハードディスクドライブ等により構成されている。この記憶部22には、商品情報DB22a、購入履歴DB22b等のデータベースが構築されている。
図5(b)は、商品情報DB22aに登録される内容の一例を示す図である。商品情報DB22aには、電子商店街で販売されている商品に関する商品情報が登録される。商品情報は、店舗によって設定される。具体的に、商品情報DB22aには、商品ID、店舗ID、商品コード、ジャンル情報、商品名、商品画像のURL(Uniform Resource Locator)、商品説明、商品価格、配達日時指定可能フラグ、配達可能日時算出用情報、指定可能配達日時算出用情報等の商品の属性が、店舗が販売する商品ごとに対応付けて登録される。
商品IDは、店舗等が、販売する商品を管理するための商品の識別情報である。商品IDは、基本的に商品ページと一対一で対応する。商品ページは、1つの商品に関する詳細な情報が表示されるWebページである。従って、実際には同一の商品であっても、販売元の店舗が異なる複数の商品に対しては、互いに異なる商品IDが付与される。店舗IDは、商品の販売元の店舗の識別情報である。商品コードは、商品を識別するコード番号である。同一の商品に対しては同一の商品コードが付与される。商品コードとしては、例えば、JAN(Japanese Article Number Code)コードがある。ジャンル情報は、商品が属する商品のジャンルを示す情報である。
配達日時指定可能フラグは、商品の注文時にユーザが配達日時を指定可能であるか否かを示す。配達日時指定可能フラグがONに設定されている場合、配達日時を指定可能であることを示し、配達日時指定可能フラグがOFFに設定されている場合、配達日時を指定可能ではないことを示す。商品の注文時に商品がいつ発送可能となるかが不明である場合、配達日時指定可能フラグがOFFに設定される。例えば、製造者からの取り寄せとなる商品は、いつ発送可能となるかが商品の注文時に不明である。
配達可能日時算出用情報は、商品の注文時に最短配達可能日時を計算するために用いられる情報である。配達可能日時算出用情報は、配達日時指定可能フラグがONである場合に登録される。具体的に、配達可能日時算出用情報には、例えば、商品の送付先の住所の郵便番号ごとに、郵便番号と配達所要日数時間とが対応付けて設定されている。配達所要日数時間は、配送に要する日数及び時間である。配達所要日数時間は、商品が注文されてから受取人へ配達されるまでに要する日数及び時間である。商品の販売元の店舗から郵便番号が示す地区までの距離が長いほど、配達所要日数時間が長くなる傾向にある。商品が注文された日時に配達所要日数時間が加算されることにより、最短配達可能日時が算出される。
指定可能配達日時算出用情報は、商品の注文時にユーザが配達日時を指定する際において、指定可能な最も早い日時を計算するために用いられる情報である。指定可能配達日時算出用情報は、配達日時指定可能フラグがONである場合に登録される。具体的に、配達可能日時算出用情報には、例えば、配送先の住所の郵便番号ごとに、郵便番号と配達所要日数時間とが対応付けて設定されている。つまり、指定可能配達日時算出用情報のフォーマットは、配達可能日時算出用情報のフォーマットと基本的に同じである。商品が注文された日時に配達所要日数時間が加算されることにより、指定可能な最も早い配達日時が算出される。指定可能配達日時算出用情報が配達可能日時算出用情報とは別に登録される理由は、指定可能な最も早い配達日時を、最短配達可能日時よりも遅くするためである。これは、ユーザにより指定された配達日時に、商品を確実に配達するためである。そのため、指定可能配達日時算出用情報に設定されている配達所要日数時間は、配達可能日時算出用情報に設定されている配達所要日数時間よりも長くなっている。なお、指定可能配達日時算出用情報が配達可能日時算出用情報と同一であってもよい。
図5(c)は、購入履歴DB22bに登録される内容の一例を示す図である。購入履歴DB22bには、ユーザによる商品の購入履歴が登録される。具体的に、購入履歴DB22bには、注文番号、購入日時、ユーザID、店舗ID、商品ID、支払い方法、送付先情報、配送方法、指定配達日時、伝票番号等が、商品の購入ごとに対応付けて登録される。
注文番号は、商品の注文が行われるたびに付与される注文の識別情報である。購入日時は、商品が注文された日付及び時刻を示す。ユーザIDは、購入したユーザを示す。店舗IDは、購入先の店舗を示す。商品IDは、購入された商品を示す。複数の商品が同時に複数注文された場合、複数の商品IDが登録される。送付先情報は、注文された商品の送付先を示す。具体的に、送付先情報は、送付先となる受取人の氏名、郵便番号、住所及び電話番号を含む。配送方法は、注文された商品が何れの方法によって配送されるかを示す。指定配達日時は、商品の注文時に注文者により指定された配達日時である。指定配達日時は、日付及び時間帯を含む。
伝票番号は、注文された商品の配送伝票に表示される伝票番号である。ユーザが同時に複数の商品を注文した場合、この複数の商品は原則として一括して配送される。そのため、配送に用いられる配送伝票は1つであるため、購入履歴には伝票番号が1つ登録される。しかしながら、複数の商品が別々に配送される場合がある。例えば、ユーザが、店舗から発送される商品と、製造者から取り寄せになる商品とを注文した場合、店舗から発送される商品は一括して配送され、製造者から取り寄せになる商品は、商品ごとに配送される。この場合、配送伝票が複数必要になるため、購入履歴には伝票番号が複数登録される。
次に、記憶部22に記憶されるその他の情報について説明する。記憶部22には、電子商店街のWebページを構成するHTML(Hyper Text Markup Language)文書、XML(Extensible Markup Language)文書、画像データ、テキストデータ、電子文書等の各種データが記憶されている。
また、記憶部22には、オペレーティングシステム、WWW(World Wide Web)サーバプログラム、DBMS(DataBase Management System)、電子商取引管理プログラム等の各種プログラムが記憶されている。電子商取引管理プログラムは、電子商店街に関する処理を実行するためのプログラムである。なお、各種プログラムは、例えば、他のサーバ装置等からネットワークNWを介して取得されるようにしてもよいし、DVD(Digital Versatile Disc)等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしてもよい。
入出力インターフェース23は、通信部21及び記憶部22とシステム制御部24との間のインターフェース処理を行うようになっている。
システム制御部24は、CPU24a、ROM24(Read Only Memory)b、RAM(Random Access Memory)24c等により構成されている。そして、システム制御部24は、CPU24aが、各種プログラムを読み出し実行することにより、電子商店街サーバ2全体を統括制御する。
なお、電子商店街サーバ2が、複数のサーバ装置で構成されてもよい。例えば、電子商取引に関する処理を行うサーバ装置、端末装置からのリクエストに応じて電子商店街のWebページを送信するサーバ装置、及びデータベースを管理するサーバ装置等が、互いにLAN等で接続されてもよい。
[3−3.宅配便サーバの構成]
図7は、本実施形態に係る宅配便サーバ3の概要構成の一例を示すブロック図である。図7に示すように、宅配便サーバ3は、通信部31と、記憶部32と、入出力インターフェース33と、システム制御部34と、を備えている。そして、システム制御部34と入出力インターフェース33とは、システムバス35を介して接続されている。
通信部31は、ネットワークNWやNLに接続して、他のサーバ装置や端末装置との通信状態を制御するようになっている。
記憶部32は、例えば、ハードディスクドライブ等により構成されている。記憶部32は、本発明における日記憶手段、配達情報記憶手段及び履歴記憶手段の一例である。この記憶部32には、対応地域情報DB32a、配送センター情報DB32b、受取可能日時情報DB32c、配送管理情報DB32d、配送状況履歴DB32e等のデータベースが構築されている。
図8(a)は、対応地域情報DB32aに登録される内容の一例を示す図である。対応地域情報DB32aには、電子商店街宅配便を利用して商品を配達可能な地域を示す情報が登録されている。具体的に、対応地域情報DB32aには、商品を配達可能な地域内にある各地区の郵便番号が登録されている。
図8(b)は、配送センター情報DB32bに登録される内容の一例を示す図である。配送センター情報DB32bには、電子商店街宅配便の配送センターに関する配送センター情報が登録されている。具体的に、配送センター情報DB32bには、センターID、郵便番号、配達可能日時算出用情報等の配送センターの属性が、配送センターごとに対応付けて登録されている。
センターIDは、配送センターの識別情報である。郵便番号は、配送センターが商品の集荷及び配達を担当する地域の郵便番号である。この郵便番号は、必要に応じて複数登録される。配達可能日時算出用情報は、例えば、配達員が店舗や製造者から商品を受け取ったときや、商品が配送センターに運ばれてきたとき等に、最短配達可能日時を計算するために用いられる情報である。配送センター情報DB32bに登録されている配達可能日時算出用情報のフォーマットは、商品情報DB22aに登録されている配達可能日時算出用情報のフォーマットと同様である。配送センター情報DB32bに登録されている配達可能日時算出用情報に含まれる配達所要日数時間は、商品が配送センターに到着してから受取人へ配達されるまでに要する日数及び時間である。配送センターから郵便番号が示す地区までの距離が長いほど、配達所要日数時間が長くなる傾向にある。また、配送センターから郵便番号が示す地区までの距離が長いほど、余裕をもった配達所要日数時間が設定されている。つまり、配送センターから郵便番号が示す地区までの距離が短いほど、配達所要日数時間がより正確になる。商品が配送センターに到着した日時に配達所要日数時間が加算されることにより、最短配達可能日時が算出される。なお、配達員が店舗や製造者から商品を受け取ったときには、例えば、配達員が商品を受け取った日時に、配達所要日数時間と、予め設定された時間とが加算されることにより、最短配達可能日時が算出される。この予め設定された時間は、配達員が商品を配達センターに運び込むまでに要する時間である。なお、Y社の配達員が商品を受け取ったり、Y社の配送センターに商品が運ばれてきた場合には、提携宅配業者サーバ4により最短配達可能日時が計算され、計算された最短配達可能日時が、宅配便サーバ3へ送信される。また例えば、配送センター情報DB32bにY社の配送センターの配送センター情報が登録されていてもよい。そして、Y社の配送センターに商品が運ばれてきた場合には、宅配便サーバ3が、配送センター情報に含まれる配達可能日時算出用情報に基づいて、最短配達可能日時を計算してもよい。
図8(c)は、受取可能日時情報DB32cに登録される内容の一例を示す図である。受取可能日時情報DB32cには、ユーザにより設定された受取可能日時に関する受取可能日時情報が登録される。具体的に、受取可能日時情報DB32cには、ユーザID及び受取可能日時が、設定された受取可能日時ごとに登録される。ユーザIDは、受取可能日時を設定したユーザを示す。受取可能日時は、日付及び時間帯を含む。
図8(d)は、配送管理情報DB32dに登録される内容の一例を示す図である。配送管理情報DB32dには、電子商店街宅配便で配送される商品の配送に用いられる管理情報が登録される。具体的に、配送管理情報DB32dには、伝票番号、注文番号、ユーザID、店舗ID、商品ID、送付先情報、配達日指定フラグ、最短配達可能日時、配達予定日時、一括配達フラグ、一括配達ID、配達日時変更可能フラグ、別途配達フラグ、配送ステータス、配達完了日時等が、配送伝票ごとに対応付けて登録される。
伝票番号は、配送される商品の配送伝票に表示される伝票番号である。また、伝票番号は、配送管理情報を識別する情報でもある。注文番号は、配送される商品の注文番号である。配送管理情報には、原則として注文番号が1つ登録される。しかしながら、ユーザが、同一の店舗から別々に注文した複数の商品のうち、店舗からまだ発送していない複数の商品を一括で配達するように、注文先の店舗に依頼する場合がある。この場合、店舗は、一括で配達するように依頼された複数の商品を同梱して、1つの配送伝票で商品を発送することがある。この場合、配送管理情報には、複数の注文番号が登録される。
ユーザIDは、配送される商品の受取人のユーザを示す。ユーザIDは、受取人がサービス提供サイトに会員登録している場合に登録される。店舗IDは、配送される商品の注文先の店舗を示す。商品IDは、配送される商品を示す。1つの配送伝票で複数の商品が一括して配送される場合、商品IDは複数登録される。また、注文番号と商品IDとの組み合わせも、配送管理情報を識別する情報である。
送付先情報は、配送される商品の送付先を示す。配送管理情報DB32dに登録される送付先情報のフォーマットは、購入履歴DB22bに登録される送付先情報のフォーマットと同じである。
配達日指定フラグは、商品の注文時に注文者により配達日が指定されたか否かを示す。配達日指定フラグがONに設定されている場合、配達日が指定されたことを示し、配達日指定フラグがOFFに設定されている場合、配達日が指定されていないことを示す。
最短配達可能日時は、配送される商品を最も早く配達可能な日時である。最短配達可能日時は、日付及び時間帯を含む。配達予定日時は、配送される商品の配達が予定されている日時である。配達予定日時は、日付及び時間帯を含む。
一括配達フラグは、配送される商品とは伝票番号が異なる他の商品との一括配達が指定されているか否かを示す。一括配達フラグがONに設定されている場合、一括配達が指定されていることを示し、一括配達フラグがOFFに設定されている場合、一括配達が指定されていないことを示す。
一括配達IDは、一括配達が指定された一群の商品を識別するための情報である。一括配達IDは、一括配達フラグがONに設定されている場合に登録される。複数の配送管理情報に同一の一括配達IDが設定されている場合、その複数の配送管理情報が対応する一群の商品は一括で配達される。
配達日時変更可能フラグは、注文済商品の配達予定日時を、ユーザが配達日時を指定して商品を注文したときに変更することが可能であるか否かを示す。配達日時変更可能フラグは、配達日時変更可能フラグがONに設定されている場合、配達日時の変更が可能であることを示し、配達日時変更可能フラグがOFFに設定されている場合、配達日時の変更が不可能であることを示す。ユーザが、商品を注文するときに注文する商品の配達予定日時が変更されないように選択された場合に、配達日時変更可能フラグがONに設定される。
別途配達フラグは、配送される商品を注文した注文者が、注文者の家族とは別途商品を配達することを指定したか否かを示す。別途配達フラグは、注文者に、家族登録されたユーザが存在する場合に登録される。別途配達フラグがONに設定されている場合、別途商品を配達することが指定されたことを示し、別途配達フラグがOFFに設定されている場合、別途商品を配達することが指定されていないことを示す。
配送ステータスは、商品の配送状況を示す。配送ステータスは、配送センターの従業員や配達員による配送状況の入力に応じて変化する。配送ステータスとしては、例えば、「未発送」、「配達員受取」、「非担当配送センター到着」、「回送」、「担当配送センター到着」、「配達中」、「受取人不在」、「配達完了」等のうち何れかが設定される。「未発送」は、商品が店舗または製造者からまだ発送していないことを示す。配達員が店舗または製造者から商品を受け取ったとき、配送ステータスが「配達員受取」に変更される。商品の配達を担当する配送センター以外の配送センターに、その商品が運び込まれたとき、配送ステータスは「非担当配送センター到着」に変更される。配送センターから他の配送センターへ商品を回送するために、配送センターから商品が運び出されたとき、配送ステータスが「回送」に変更される。商品の配達を担当する配送センターに、その商品が運び込まれたとき、配送ステータスは「担当配送センター到着」に変更される。商品の配達を担当する配送センターから受取人へ商品を配達するために、配送センターから商品が運び出されたとき、配送ステータスは「配達中」に変更される。配達員が商品を受取人に配達に行ったときに受取人が不在であったとき、配送ステータスは「受取人不在」に変更される。商品の配達が完了したとき、配送ステータスは「配達完了」に変更される。
図8(e)は、配送状況履歴DB32eに登録される内容の一例を示す図である。配送状況履歴DB32eは、配送センターの従業員や配達員により入力された商品の配送状況の履歴を示す配送状況履歴が登録される。配送状況履歴により、店舗または製造者から受取人まで、商品が如何なる過程を経て配送されたかを把握することができる。具体的に、配送状況履歴DB32eは、伝票番号、記録日時、センターID、配送ステータス等の情報が、配送状況の入力ごとに登録される。伝票番号は、配送状況が入力された商品の配送伝票の伝票番号を示す。記録日時は、配送状況が入力された日付及び時刻を示す。センターIDは、配送状況を入力した配送センターまたは配送状況を入力した配達員が属する配送センターを示す。配送ステータスは、入力された配送状況を示す。
次に、記憶部32に記憶されるその他の情報について説明する。記憶部32には、宅配便サーバ3から送信されるWebページを構成するHTML文書、XML文書、画像データ、テキストデータ、電子文書等の各種データが記憶されている。
また、記憶部32には、オペレーティングシステム、WWWサーバプログラム、DBMS、配送管理プログラム等の各種プログラムが記憶されている。配送管理プログラムは、電子商店街宅配便による商品の配送の管理に関する各種処理を実行するためのプログラムである。なお、配送管理プログラム等の各種プログラム(本発明における情報処理プログラムの一例を含む)は、例えば、他のサーバ装置等からネットワークNWを介して取得されるようにしてもよいし、DVD等の記録媒体に記録されてドライブ装置を介して読み込まれるようにしてもよい。
入出力インターフェース33は、通信部31及び記憶部32とシステム制御部34との間のインターフェース処理を行うようになっている。
システム制御部34は、CPU34a、ROM34b、RAM34c等により構成されている。そして、システム制御部34は、CPU34aが、各種プログラムを読み出し実行することにより、本発明における日取得手段、配達情報記憶制御手段、変更手段、第1判定手段、識別情報取得手段、第2判定手段、送信手段、完了情報取得手段、第3判定手段、第1報酬情報記憶制御手段、第4判定手段、第2報酬情報記憶制御手段として機能するようになっている。
なお、宅配便サーバ3が、複数のサーバ装置で構成されてもよい。例えば、商品の配送の管理するサーバ装置、ユーザ端末8等からのリクエストに応じて店舗情報サイトのWebページを送信するサーバ装置及びデータベースを管理するサーバ装置等が、互いにLAN等で接続されてもよい。
[4.配送システムの動作]
次に、配送システムSの動作について、図9乃至図24を用いて説明する。なお、以降においては、商品が1つのみ注文される場合の動作を主として説明する。そして、商品が複数注文される場合の動作については適宜補足する。また、注文者が配達日時として、配達日及び配達時間帯のうち配達時間帯のみを指定した場合の動作内容の説明は省略する。
[4−1.受取可能日時設定時の動作]
先ず、受取可能日時を設定する場合の動作について説明する。
ユーザは、例えば、予めサービス提供サイトに対するログイン操作を行っている。この場合、電子商店街サーバ2または宅配便サーバ3は、ログイン時に、ユーザ端末8からユーザIDを受信し、受信したユーザIDをクッキーとしてユーザ端末8に保存させている。そのため、ユーザ端末8から電子商店街サーバ2や宅配便サーバ3に送信されるリクエストにはクッキーが付加されているので、電子商店街サーバ2及び宅配便サーバ3は、リクエストの受信ごとに、ユーザ端末8からこのユーザ端末8を利用するユーザのユーザIDを取得することができる。
例えば、ユーザ端末8に電子商店街のWebページが表示されている状態において、ユーザが、受取可能日時の設定を選択すると、ユーザ端末8は、受取可能日時設定カレンダーページのリクエストを宅配便サーバ3へ送信する。なお、受取可能日時の設定を選択したユーザを、「設定者」という。
宅配便サーバ3は、リクエストを受信すると、設定者のユーザIDに対応する受取可能日時を、受取可能日時情報DB32cから検索する。そして、宅配便サーバ3は、検索した受取可能日時に基づいて受取可能日時設定カレンダーページを生成し、生成した受取可能日時設定カレンダーページをユーザ端末8へ送信する。
受取可能日時設定カレンダーページにおいて、ユーザは何れかの日付を選択して、時間帯選択ウインドウを画面に表示させる。次いで、ユーザは、時間帯の選択操作を行う。すると、ユーザ端末8は、選択された日付及び選択された時間帯を含む受取可能日時設定リクエストを宅配便サーバ3へ送信する。
宅配便サーバ3は、受取可能日時設定リクエストに含まれる日付及び時間帯を受取可能日時とする。このとき、時間帯として全日が選択されている場合には、受取可能日時設定リクエストに含まれる日付のみを受取可能日時とする。そして、宅配便サーバ3は、この受取可能日時と設定者のユーザIDとを含む受取可能日時情報を受取可能日時情報DB32cに登録する。
[4−2.商品の注文時の動作]
[4−2−1.動作概要]
次に、商品の注文時における動作を、Webページの遷移とともに説明する。図9は、商品の注文が完了するまでのWebページの遷移の一例を示す図である。
商品ページには、その商品ページに情報が表示されている商品を買い物かごに入れるための買い物かご投入ボタンが表示される。本実施形態における買い物かごとは、電子商店街において、購入する候補としてユーザが選択した商品が入れられる仮想的な入れ物である。
ある商品の商品ページがユーザ端末8の画面に表示されているとき(図9(1))、ユーザが買い物かご投入ボタンを投入すると、その商品が買い物かごに入れられる。そして、電子商店街サーバ2からユーザ端末8へ買い物かごページが送信され、ユーザ端末8の画面に買い物かごページが表示される(図9(2))。買い物かごページは、ユーザが買い物かごに入れている商品の一覧を表示するWebページである。買い物かごページは、買い物かごに入れられている商品の注文手続きに進むための注文手続きボタンも表示される。
ユーザが注文手続きボタンを選択すると、電子商店街サーバ2からユーザ端末8へ注文者情報入力ページが送信され、ユーザ端末8の画面に注文者情報入力ページが表示される(図9(3))。注文者情報入力ページは、注文手続きボタンを選択したユーザのユーザID及びパスワードを入力するためのWebページである。また、注文者情報入力ページは、注文商品を、会員登録した住所へ送付させるか、会員登録した住所とは別の住所へ送付させるかを選択するためのWebページである。なお、ユーザが注文手続きボタンを選択した時点で、このユーザを注文者とする。
注文者情報入力ページにおいて、ユーザは、ユーザID及びパスワードを入力する。また、ユーザは、会員登録した住所へ送付する否かを選択する。すると、ユーザ端末8は、入力されたユーザID及びパスワードと、注文商品を会員登録した住所へ送付するか否かを示す情報とを含む認証リクエストを、電子商店街サーバ2へ送信する。
電子商店街サーバ2は、受信した認証リクエストに含まれるユーザID及びパスワードを用いてユーザ認証を行う。そして、電子商店街サーバ2は、ユーザ認証が成功すると、注文商品を会員登録した住所へ送付するか否かを判定する。このとき、電子商店街サーバ2は、会員登録した住所へ送付しないと判定した場合には、支払い方法・配送方法選択ページをユーザ端末8へ送信する。ユーザ端末8は、受信した支払い方法・配送方法選択ページを画面に表示する(図9(5))。支払い方法・配送方法選択ページは、注文商品の購入代金の支払い方法及び配送方法等を選択するためのWebページである。
一方、電子商店街サーバ2は、会員登録した住所へ送付しないと判定した場合、つまり、会員登録した住所とは別の住所へ送付する場合には、送付先情報入力ページをユーザ端末8へ送信する。ユーザ端末8は、受信した送付先情報入力ページを画面に表示する(図9(4))。送付先情報入力ページは、送付先情報を入力するためのWebページである。
送付先情報入力ページにおいて、ユーザが、送付先情報として、注文商品の受取人の氏名、郵便番号、住所、電話番号を入力する。すると、ユーザ端末8は、入力された送付先情報を電子商店街サーバ2へ送信する。電子商店街サーバ2は、受信した送付先情報を、注文者のユーザIDに対応付けてRAM24cに一時的に記憶させる。そして、電子商店街サーバ2は、支払い方法・配送方法選択ページをユーザ端末8へ送信する。ユーザ端末8は、受信した支払い方法・配送方法選択ページを画面に表示する(図9(5))。
図10は、支払い方法・配送方法選択ページの画面表示例を示す図である。図10に示すように、支払い方法・配送方法選択ページは、支払い方法選択領域210、配送方法選択領域220、配達日時指定領域230、次ボタン240等を含む。
支払い方法選択領域210には、購入代金の支払い方法として選択可能な方法の一覧が表示される。また、支払い方法選択領域210には、一覧表示された方法の中から、支払い方法を選択するためのラジオボタンが表示される。支払い方法として選択可能な方法としては、例えば、クレジットカードによる決済、代金引換、銀行振り込み等がある。
配送方法選択領域220には、注文商品の配送方法として選択可能な方法の一覧が表示される。また、配送方法選択領域220には、一覧表示された方法の中から、配送方法を選択するためのラジオボタンが表示される。配送方法として選択可能な方法としては、電子商店街宅配便がある。注文商品の送付先の住所が、電子商店街宅配便で配達可能な地域に含まれている場合に、電子商店街宅配便が表示される。また、電子商店街宅配便が表示されている場合、電子商店街宅配便が、配送方法としてデフォルトで選択されている状態になっている。また、配送方法として選択可能な他の方法としては、他の宅配便や郵送等がある。電子商店街宅配便以外の方法として如何なる方法が選択可能であるかは、例えば、注文商品や、注文先の店舗等によって異なる。なお、選択可能な宅配便として、Y社の宅配便が含まれていてもよい。
配達日時指定領域230には、配達日を選択するためのプルダウンメニュー及び配達時間帯を選択するためのラジオボタンが表示される。また、配達日時指定領域230には、商品の配送に関して注文先の店舗に対する希望を入力するための希望欄が表示される。また、配達日時指定領域230には、他の商品の注文時に配達日時が指定された場合に、今回の注文商品の配達予定日時の変更を許可するか否かを選択するためのチェックボックスが表示される。また、配達日時指定領域230には、注文者の家族により指定された配達日時(注文者の家族により設定された受取可能日時を含む)が、注文商品の配達予定日時として設定されることを許可するか否かを選択するためのチェックボックスが表示される。なお、これらのチェックボックスは、ユーザが注文商品を会員登録した住所へ送付することを選択した場合に表示される。注文者の家族により指定された配達日時が注文商品の配達予定日時として設定されることを許可するか否かを選択するためのチェックボックスは、この条件に加えて、注文者について家族登録が行われている場合にのみ表示される。
支払い方法・配送方法選択ページにおいて、ユーザは、支払い方法及び配送方法を選択する。このとき、ユーザは、配送方法として電子商店街宅配便を選択する。また、ユーザは、配達日時指定領域230に対する選択操作により、必要に応じて配達日時を指定する。また、ユーザは、必要に応じて、配達予定日時の変更を許可するか否か、及び、家族により指定された配達日時が配達予定日時として設定されることを許可するか否かを選択する。そして、ユーザは、次ボタン240を選択する。すると、ユーザ端末8は、注文内容確認リクエストを、電子商店街サーバ2へ送信する。注文内容確認リクエストは、選択された支払い方法及び配送方法を示す情報、指定された配達日時を含む。また、配達予定日時の変更を許可することが選択された場合には、ONに設定された配達日時変更可能フラグが注文内容確認リクエストに含まれ、配達予定日時の変更を許可しないことが選択された場合には、OFFに設定された配達日時変更可能フラグが注文内容確認リクエストに含まれる。また、家族が指定した配達日時が配達予定日時として設定されることを許可することが選択された場合には、OFFに設定された別途配達フラグが注文内容確認リクエストに含まれ、家族が指定した配達日時が配達予定日時として設定されることを許可しないことが選択された場合には、ONに設定された別途配達フラグが注文内容確認リクエストに含まれる。
注文内容確認リクエストを受信した電子商店街サーバ2は、注文内容確認リクエストに含まれる情報を、注文者のユーザIDに対応付けてRAM24cに一時的に記憶させる。また、電子商店街サーバ2は、注文内容確認ページをユーザ端末8へ送信する。ユーザ端末8は、注文内容確認ページを画面に表示する(図9(6))。注文内容確認ページは、これから注文される内容を表示するWebページである。例えば、注文内容確認ページには、注文商品の商品名、注文先の店舗の店舗名、送付先情報、支払い方法、配送方法、配達日時等が表示される。
注文内容確認ページにおいて、ユーザが、注文を確定するためのボタンを選択すると、ユーザ端末8は、注文確定リクエストを電子商店街サーバ2へ送信する。注文確定リクエストを受信した電子商店街サーバ2は、商品の注文に必要な処理を実行する。例えば、電子商店街サーバ2は、新しい注文番号を生成する。また、電子商店街サーバ2は、注文者のユーザIDに対応付けてRAM24cに記憶されていた情報等に基づいて、購入履歴を購入履歴DB22bに登録する。また、電子商店街サーバ2は、電子商店街宅配便が配送方法として選択されたと判定すると、注文者のユーザIDに対応付けてRAM24cに記憶されていた情報等に基づいて、配送依頼情報を生成する。配送依頼情報には、例えば、注文商品の商品情報、注文番号、注文者のユーザID、送付先情報、注文者により指定された配達日時、配達日時変更可能フラグ、別途配達フラグ等が含まれる。そして、電子商店街サーバ2は、生成した配送依頼情報を宅配便サーバ3へ送信する。
宅配便サーバ3は、受信した配送依頼情報に基づいて、配送管理情報を配送管理情報DB32dに登録する。このとき、宅配便サーバ3は、注文者が配達日時を指定した場合には、指定された配達日時を配達予定日時として設定する。また、宅配便サーバ3は、注文者が配達日時を指定した場合であって、会員登録した住所に注文商品を送付することが選択されている場合には、注文済商品の配達予定日時を、今回指定された配達日時に設定する。一方、宅配便サーバ3は、注文者が配達日時を指定していない場合であって、且つ、注文商品の受取人がサービス提供サイトの会員である場合には、受取人等が設定した受取可能日時のうち注文商品を配達可能な最先の日時を、配達予定日として設定する。
次いで、宅配便サーバ3は、登録した配送管理情報に基づいて、発送依頼情報を、商品の注文先の店舗の店舗端末7へ送信する。発送依頼情報には、例えば、注文番号、注文商品の商品ID及び商品名、送付先情報、配達予定日時等の情報が含まれる。また、宅配便サーバ3は、配送管理情報に基づいて、集荷依頼情報を、注文商品の集荷を担当する配送センターの配送センター端末5または提携宅配業者サーバ4へ送信する。集荷依頼情報には、例えば、注文番号、注文商品の商品ID及び商品名、注文先の店舗の店舗ID、店舗名及び住所、送付先情報、配達予定日時等の情報が含まれる。
宅配便サーバ3は、配送管理情報を登録すると、受信した配送依頼情報に対応する応答メッセージを電子商店街サーバ2へ送信する。電子商店街サーバ2は、応答メッセージを受信すると、注文完了ページをユーザ端末8へ送信する。ユーザ端末8は、注文完了ページを画面に表示する(図9(7))。注文完了ページは、注文が完了した旨を表示するWebページである。会員登録した住所に注文商品を送付することが選択されている場合、注文完了ページには、一括配達商品選択ページを表示するための一括配達商品選択ボタンが表示される。一括配達商品選択ページは、注文済商品の中から注文商品と一括配達する商品を選択するためのWebページである。ユーザが一括配達商品選択ボタンを選択すると、ユーザ端末8は、一括配達商品選択ページリクエストを宅配便サーバ3へ送信する。一括配達商品選択ページリクエストには、注文商品の注文番号が含まれている。宅配便サーバ3は、一括配達商品選択ページリクエストを受信すると、一括配達商品選択ページをユーザ端末8へ送信する。ユーザ端末8は、一括配達商品選択ページを画面に表示する(図9(8))。
図11は、一括配達商品選択ページの画面表示例を示す図である。図11に示すように、一括配達商品選択ページは、商品選択領域310、決定ボタン320等を含む。
商品選択領域310には、注文商品と一括して配達可能な商品の一覧が表示される。具体的に、配達可能な商品ごとに、注文番号、商品名、配達予定日時、注文商品と一括して配達するか否かを選択するためのチェックボックス等が表示される。なお、注文済商品の中に既に一括配達が指定されている一群の商品が存在する場合、一群の商品単位で配達予定日時及びチェックボックスが表示される。つまり、一群の商品単位で、注文商品と一括して配達するか否かを選択することができる。
注文者が配達日時を指定していない場合、注文商品と一括して配達可能な商品は、現時点で最短配達可能日時が判明している商品である。最短配達可能日時が判明していない商品は、いつ発送されるかが不明であるからである。そのため、このような商品は、選択対象から除外される。一方、注文者が配達日時を指定した場合、注文商品と一括して配達可能な商品は、配達予定日時が今回指定された配達日時に変更された商品である。
一括配達商品選択ページにおいて、ユーザは、必要に応じて、注文商品と一括して配達する商品を選択する。そして、ユーザは、決定ボタン320を選択する。すると、ユーザ端末8は、一括配達情報を宅配便サーバ3へ送信する。ユーザが商品を選択した場合、一括配達情報には、選択された商品の注文番号及び商品IDが含まれる。
一括配達情報を受信した宅配便サーバ3は、注文者が配達日時を指定していない場合であって、且つ、一括配達する注文済商品が選択されている場合には、注文商品の配達予定日時を改めて決定する。注文商品と選択された注文済商品とが同じ日時に配達されるようにするためである。具体的に、宅配便サーバ3は、一括配達する注文済商品が選択されている場合には、注文者等が設定した受取可能日時のうち、注文商品及び選択された注文済商品の何れも配達可能な最先の日時を、配達予定日として設定する。また、注文商品の配達予定日に、一括配達する注文済商品の配達予定日時を設定する。
宅配便サーバ3は、注文商品の配達予定日時を改めて決定することによって、注文商品または注文済商品の配達予定日時が変更された場合には、配達日時変更通知情報を、その注文済商品の集荷を担当する配送センターの配送センター端末5へ送信する。配達日時変更通知情報は、配達予定日時が変更されたことを通知する情報である。配送センター端末5は、例えば、配達日時変更通知情報を画面に表示する。
[4−2−2.支払い方法・配送方法選択ページ送信時の動作]
次に、電子商店街サーバ2が、支払い方法・配送方法選択ページを生成してユーザ端末8に送信するときの動作について説明する。図12は、本実施形態に係る電子商店街サーバ2のシステム制御部24の支払い方法・配送方法選択ページ送信処理における処理例を示すフローチャートである。支払い方法・配送方法選択ページ送信処理は、宅配便サーバ3が、注文者情報入力ページを表示しているユーザ端末8から認証リクエストを受信したときに、会員登録した住所に注文商品を送付することが選択されたと判定した場合に実行される。また、支払い方法・配送方法選択ページ送信処理は、宅配便サーバ3が、送付先情報入力ページにおいて入力された送付先情報をユーザ端末8から受信したときに実行される。
先ず、システム制御部24は、会員登録した住所に注文商品を送付するか否かを判定する(ステップS11)。このとき、システム制御部24は、会員登録した住所に送付すると判定した場合には(ステップS11:YES)、注文者の家族の送付先情報を、注文商品の送付先情報として利用するか否かを判定する(ステップS12)。ここで、システム制御部24は、注文者のユーザIDに対応する会員情報に含まれる家族登録情報に基づいて判定を行う。具体的に、システム制御部24は、注文者に家族登録しているユーザが存在し、注文者が家族の代表者ではなく、且つ、注文者が家族の代表者の送付先情報の利用を選択している場合には、注文者の家族の送付先情報を利用すると判定する(ステップS12:YES)。この場合、システム制御部24は、注文者の家族登録情報から、家族の代表者のユーザIDを取得する。そして、システム制御部24は、家族の代表者のユーザIDに対応する会員情報に含まれる氏名、郵便番号、住所及び電話番号を、送付先情報として取得する(ステップS14)。
一方、システム制御部24は、注文者に家族登録しているユーザが存在しないか、注文者が家族の代表者であるか、または、注文者が家族の代表者の送付先情報の利用を選択していない場合には、注文者の家族の送付先情報を利用しないと判定する(ステップS12:NO)。この場合、システム制御部24は、注文者のユーザIDに対応する会員情報に含まれる氏名、郵便番号、住所及び電話番号を、送付先情報として取得する(ステップS13)。
ステップS11において、システム制御部24は、会員登録した住所に送付しないと判定した場合には(ステップS11:NO)、ユーザ端末8から受信した送付先情報を取得する(ステップS15)。
システム制御部24は、ステップS13〜S15の何れかの処理を終えると、注文商品の送付先が電子商店街宅配便の対象地域であるか否かを判定する(ステップS16)。具体的に、システム制御部24は、取得した送付先情報に含まれる郵便番号を宅配便サーバ3へ送信する。宅配便サーバ3は、受信した郵便番号で対応地域情報DB32aを検索する。次いで、宅配便サーバ3は、受信した郵便番号が対応地域情報DB32aに登録されているか否かを判定する。そして、宅配便サーバ3は、この判定結果を電子商店街サーバ2へ送信する。
システム制御部24は、受信した判定結果に基づいて、送付先の郵便番号が対応地域情報DB32aに登録されているか否かを判定する。そして、システム制御部24は、送付先の郵便番号が登録されている場合には、注文商品の送付先が電子商店街宅配便の対象地域であると判定する(ステップS16:YES)。この場合、システム制御部24は、配送方法の選択肢として電子商店街宅配便を配送方法選択領域220に含む支払い方法・配送方法選択ページのHTML文書を記憶部22から取得する(ステップS17)。
次いで、システム制御部24は、注文商品の商品IDに対応する商品情報に含まれる配達日時指定可能フラグがONであるか否かを判定する(ステップS18)。このとき、システム制御部24は、配達日時指定可能フラグがONであると判定した場合には(ステップS18:YES)、注文商品の商品IDに対応する商品情報に含まれる指定可能配達日時算出用情報に基づいて、指定可能な最も早い配達日時を計算する(ステップS19)。具体的に、システム制御部24は、指定可能配達日時算出用情報から、注文商品の送付先の郵便番号に対応する配達所要日数時間を取得する。次いで、システム制御部24は、取得した配達所要日数時間を現在日時に加算して、仮の配達日時を計算する。次いで、システム制御部24は、仮の配達日時以降であって、実際に配達可能な最も早い日付及び時間帯を特定する。システム制御部24は、この日付及び時間帯を、指定可能な最も早い配達日時とする。
次いで、システム制御部24は、配達日時指定領域230において、注文商品の配達日時として、計算した最も早い配達日時以降を選択可能なように、取得したHTML文書に対する設定を行う(ステップS20)。つまり、システム制御部24は、計算した最も早い配達日時よりも前の日時を選択することができないようにする。
ステップS18において、システム制御部24は、配達日時指定可能フラグがONではないと判定した場合には、配送方法として電子商店街宅配便が選択された場合には配達日時を指定することができないように、取得したHTML文書に対する設定を行う(ステップS21)。
システム制御部24は、ステップS20またはS21の処理を終えた場合には、設定を行ったHTML文書を、ユーザ端末8へ送信する(ステップS22)。システム制御部24は、この処理を終えると、支払い方法・配送方法選択ページ送信処理を終了させる。
ここで、注文商品が複数存在する場合について補足する。ステップS18において、システム制御部24は、複数の注文商品のそれぞれの配達日時指定可能フラグのうち、少なくとも1つの配達日時指定可能フラグがONである場合には、ステップS19に移行する。ステップS19において、システム制御部24は、配達日時指定可能フラグがONである注文商品ごとに、仮の配達日時を計算する。そして、システム制御部24は、計算した仮の配達日時のうち最も遅い配達日時に基づいて、指定可能な最も早い配達日時を特定する。なお、この場合、配達日時指定可能フラグがONである商品に対してのみ、配達日時の指定が可能である。
ステップS16において、システム制御部24は、送付先の郵便番号が対応地域情報DB32aに登録されていない場合には、注文商品の送付先が電子商店街宅配便の対象地域ではないと判定する(ステップS16:NO)。この場合、システム制御部24は、配送方法の選択肢として電子商店街宅配便を配送方法選択領域220に含まない支払い方法・配送方法選択ページのHTML文書を記憶部22から取得する(ステップS23)。次いで、システム制御部24は、取得したHTML文書を、ユーザ端末8へ送信して(ステップS22)、支払い方法・配送方法選択ページ送信処理を終了させる。
[4−2−3.配送依頼情報受信時の動作]
次に、宅配便サーバ3が、電子商店街サーバ2から配送依頼情報を受信した場合の動作について説明する。図13及び図14は、本実施形態に係る宅配便サーバ3のシステム制御部34の配送依頼情報受信時処理における処理例を示すフローチャートである。
図13に示すように、システム制御部34は、受信した配送依頼情報に基づいて、注文商品の配送管理情報を初期化する(ステップS51)。具体的に、システム制御部34は、RAM34cに、配送管理情報を生成する。このとき、システム制御部34は、配送依頼情報に含まれる注文番号、店舗ID、商品ID、送付先情報、配達日時変更可能フラグ及び別途配送フラグを、配送管理情報に設定する。また、システム制御部34は、配送ステータスを「未発送」に設定する。また、システム制御部34は、残りの情報を未設定とし、また、残りのフラグをOFFに設定する。
次いで、システム制御部34は、注文商品の商品情報に含まれる配達日時指定可能フラグがONであるか否かを判定する(ステップS52)。このとき、システム制御部34は、配達日時指定可能フラグがONであると判定した場合には(ステップS52:YES)、注文商品の商品情報に含まれる配達可能日時算出用情報に基づいて、最短配達可能日時を計算する(ステップS53)。具体的に、システム制御部34は、配達可能日時算出用情報から、注文商品の送付先の郵便番号に対応する配達所要日数時間を取得する。次いで、システム制御部34は、取得した配達所要日数時間を現在日時に加算して、仮の配達日時を計算する。次いで、システム制御部34は、仮の配達日時以降であって、実際に配達可能な最も早い日付及び時間帯を特定する。システム制御部34は、この日付及び時間帯を、最短配達可能日時として、注文商品の配送管理情報に設定する。
システム制御部34は、配達日時指定可能フラグがONではないと判定した場合(ステップS52:NO)、または、ステップS53の処理を終えた場合には、配送依頼情報に基づいて、会員登録した住所へ注文商品を送付するか否かを判定する(ステップS54)。このとき、システム制御部34は、会員登録した住所へ送付すると判定した場合には(ステップS54:YES)、注文者のユーザIDを受取人のユーザIDとして、注文商品の配送管理情報に設定する(ステップS55)。
次いで、システム制御部34は、注文商品の商品情報に含まれる配達日時指定可能フラグがONであるか否かを判定する(ステップS56)。このとき、システム制御部34は、配達日時指定可能フラグがONではないと判定した場合には(ステップS56:NO)、注文商品の配送管理情報を配送管理情報DB32dに登録する(ステップS57)。次いで、システム制御部34は、注文商品と注文済商品との一括配達が不可能であることを示す応答メッセージを、電子商店街サーバ2へ送信する(ステップS58)。システム制御部34は、この処理を終えると、配送依頼情報受信時処理を終了させる。この場合、注文商品がいつ頃発送されるかが不明であるので、配送管理情報には、最短配達日時及び配送予定日時は設定されない。また、システム制御部34は、注文商品と一括で配達する注文済商品を選択することができないようにする。
一方、システム制御部34は、配達日時指定可能フラグがONであると判定した場合には(ステップS56:YES)、配送依頼情報に基づいて、配達日時として、配達日及び配達時間帯のうち少なくとも配達日が注文者により指定されているか否かを判定する(ステップS59)。このとき、システム制御部34は、配達日が指定されていないと判定した場合には(ステップS59:NO)、配達予定日時決定処理を実行する(ステップS60)。このとき、システム制御部34は、ステップS53において計算した最短配達可能日時を、引数として設定する。配達予定日時決定処理では、注文者等が設定した受取可能日時のうち、注文商品を配達可能な最先の日時が、配達予定日として決定される。注文商品を配達可能な日時は、引数として設定された最短配達可能日時以降の日時である。配達予定日時決定処理の詳細については後述する。次いで、システム制御部34は、配達予定日時決定処理において決定された配達予定日時を、注文商品の配送管理情報に設定する(ステップS61)。こうして、システム制御部34は、日取得手段として、注文者等が設定した受取可能日時のうち注文商品を配達可能な最先の日時を記憶部32から取得する。
次いで、システム制御部34は、注文商品の配送管理情報を配送管理情報DB32dに登録する(ステップS62)。こうして、システム制御部34は、配達情報記憶制御手段として、配達予定日時決定処理において決定された配達予定日時を含む配送管理情報を記憶部32に記憶させる。次いで、システム制御部34は、注文商品と注文済商品との一括配達が可能であることを示す応答メッセージを、電子商店街サーバ2へ送信する(ステップS63)。つまり、システム制御部34は、注文商品と一括で配達する注文済商品を選択することができるようにする。システム制御部34は、この処理を終えると、配送依頼情報受信時処理を終了させる。
ステップS59において、システム制御部34は、配達日が指定されていると判定した場合には(ステップS59:YES)、配送依頼情報から、指定された配達日時を取得する。そして、システム制御部34は、指定された配達日時を配達予定日時として、注文商品の配送管理情報に設定する。また、システム制御部34は、注文商品の配送管理情報の配達日時指定フラグをONに設定する(ステップS64)。
次いで、システム制御部34は、配達予定日時変更処理を実行する(ステップS65)。配達予定日時変更処理では、注文者等の注文済商品の配達予定日時が、今回指定された配達日時に変更される。配達予定日時変更処理の詳細については後述する。次いで、システム制御部34は、ステップS62に移行する。
ステップS54において、システム制御部34は、会員登録した住所へ送付しないと判定した場合には(ステップS54:NO)、図14に示すように、配送依頼情報に含まれる送付先情報から、氏名、電話番号及び郵便番号を取得する。そして、システム制御部34は、会員情報DB1aから、取得した氏名、電話番号及び郵便番号と同一の氏名、電話番号及び郵便番号を含む会員情報を検索する(ステップS81)。つまり、システム制御部34は、送付先情報により特定された受取人の会員情報を検索する。なお、システム制御部34は、例えば、送付先情報に含まれる氏名及び住所で、受取人の会員情報を検索してもよい。次いで、システム制御部34は、該当する会員情報が検索されたか否かを判定する(ステップS82)。このとき、システム制御部34は、該当する会員情報が検索されなかったと判定した場合には(ステップS82:NO)、ステップS57に移行する。このとき、システム制御部34は、配達日時が指定されている場合には、指定された配達日時を注文商品の配達予定日時として設定する。
一方、システム制御部34は、該当する会員情報が検索されたと判定した場合には(ステップS82:YES)、識別情報取得手段として、検索された会員情報からユーザIDを取得する。そして、システム制御部34は、取得したユーザIDを受取人のユーザIDとして、注文商品の配送管理情報に設定する(ステップS83)。次いで、システム制御部34は、注文商品の商品情報に含まれる配達日時指定可能フラグがONであるか否かを判定する(ステップS84)。このとき、システム制御部34は、配達日時指定可能フラグがONではないと判定した場合には(ステップS84:NO)、ステップS57に移行する。
一方、システム制御部34は、配達日時指定可能フラグがONであると判定した場合には(ステップS84:YES)、配送依頼情報に基づいて、配達日時として、配達日及び配達時間帯のうち少なくとも配達日が注文者により指定されているか否かを判定する(ステップS85)。このとき、システム制御部34は、配達日が指定されていないと判定した場合には(ステップS85:NO)、配達予定日時決定処理を実行する(ステップS86)。このとき、システム制御部34は、ステップS53において計算した最短配達可能日時を、引数として設定する。次いで、システム制御部34は、配達予定日時決定処理において決定された配達予定日時を、注文商品の配送管理情報に設定する(ステップS87)。次いで、システム制御部34は、注文商品の配送管理情報を配送管理情報DB32dに登録する(ステップS88)。こうして、システム制御部34は、日取得手段として、注文者等が設定した受取可能日時のうち注文商品を配達可能な最先の日時を記憶部32から取得し、配達情報記憶制御手段として、取得された日時を配達予定日時として含む配送管理情報を記憶部32に記憶させる。次いで、システム制御部34は、注文商品と注文済商品との一括配達が不可能であることを示す応答メッセージを、電子商店街サーバ2へ送信する(ステップS89)。
次いで、システム制御部34は、注文通知メールを送信する(ステップS90)。注文通知メールは、注文者と、商品の受取人とが異なる場合に、商品が注文されたことを受取人に通知する電子メールである。具体的に、システム制御部34は、注文商品の配送管理情報に設定されている受取人のユーザIDに対応する会員情報から、主メールアドレスを取得する。次いで、システム制御部34は、取得した主メールアドレスを、注文通知メールの宛先として設定する。次いで、システム制御部34は、注文通知メールの本文に、受取人を送付先とする商品が注文されたことを示すメッセージを設定する。また、システム制御部34は、注文通知メールの本文に、選択した配送管理情報に設定されている注文番号、注文者の氏名等を設定する。そして、システム制御部34は、注文通知メールを送信する。システム制御部34は、この処理を終えると、配送依頼情報受信時処理を終了させる。
ステップS85において、システム制御部34は、配達日が指定されていると判定した場合には(ステップS85:YES)、配送依頼情報から、指定された配達日時を取得する。そして、システム制御部34は、指定された配達日時を配達予定日時として、注文商品の配送管理情報に設定する。また、システム制御部34は、注文商品の配送管理情報の配達日時指定フラグをONに設定する(ステップS91)。次いで、システム制御部34は、ステップS88へ移行する。
このように、システム制御部34は、会員登録した住所とは別の住所に注文商品を送付することが選択されることにより、注文者と受取人とが異なる場合には、注文商品(つまり、受取人の住所に配送される商品)と一括で配達する注文済商品(つまり、注文者の住所に配送される商品)を選択することができないようにする。注文が完了した後に表示されるべき一括配達商品選択ページは、注文者に対して配送される商品の一括配達を設定するためのWebページである。つまり、今回の注文商品が注文者に配送される商品であるからこそ、注文者の注文済商品との一括配達を設定することができるのである。今回の注文商品が、注文者とは異なるユーザに配送される商品である場合、そもそも、注文商品は、注文者の注文済商品と一括で配達することができない。なお、この場合、注文商品の受取人は、配送状況一覧ページにおいて、今回の注文商品と他の商品との一括配達の設定が可能である。
電子商店街サーバ2は、宅配便サーバ3から応答メッセージを受信すると、注文完了ページをユーザ端末8へ送信する。このとき、電子商店街サーバ2は、応答メッセージが、一括配達が可能であることを示す場合には、一括配達商品選択ボタンが表示される注文完了ページを送信する。
ここで、注文商品が複数存在する場合について補足する。システム制御部34は、複数の注文商品を、配達日時指定可能フラグがONである注文商品と、配達日時指定可能フラグがOFFである注文商品とに分類する。次いで、システム制御部34は、配達日時指定可能フラグがONである注文商品については、まとめて1つの配送管理情報の登録を行う。このときの処理内容は、図13及び図14において、配達日時指定可能フラグがONである場合の処理内容と基本的に同様である。この場合、配送管理情報には、複数の商品IDが設定される。また、システム制御部34は、ステップS53において、最短配達可能日時を商品ごとに計算する。そして、計算された最短配達可能日時のうち最も遅い最短配達可能日時を、注文商品の配送管理情報に設定する。
一方、システム制御部34は、配達日時指定可能フラグがOFFである注文商品については、それぞれ別々に配送管理情報の登録を行う。このときの処理内容は、図13及び図14において、配達日時指定可能フラグがOFFである場合の処理内容と基本的に同様である。
システム制御部34は、全ての注文商品について配送管理情報を登録した後、複数の注文商品に、配達日時指定可能フラグがONである注文商品と、配達日時指定可能フラグがOFFである注文商品とが混在している場合には、注文商品と注文済商品との一括配達が可能であることを示す応答メッセージを電子商店街サーバ2へ送信する。この場合、複数の注文商品のうち、配達日時指定可能フラグがONである注文商品のみが一括配達の対象となる。
図15は、本実施形態に係る宅配便サーバ3のシステム制御部34の配達予定日時決定処理における処理例を示すフローチャートである。配達予定日時決定処理は、配送依頼情報受信時処理、後述する一括配達情報受信時処理及び後述する配送状況情報受信時処理から、それぞれ呼び出される。つまり、配達予定日時決定処理は、ユーザが配達日時を指定しないで商品を注文したときに実行される。また、配達予定日時決定処理は、注文時点において配送予定日時が不明であった商品を配達員が店舗または製造者から商品を受け取ったときに実行される。また、配達予定日時決定処理は、一括配達商品選択ページにおいてユーザが注文商品と一括して配達する商品を選択して決定ボタン320を選択したときに実行される。
図15に示すように、システム制御部34は、注文商品の受取人と、受取人の家族とで同じ住所に商品を送付することが選択されているか否かを判定する(ステップS101)。ここで、システム制御部34は、受取人のユーザIDに対応する会員情報に含まれる家族登録情報に基づいて判定を行う。
具体的に、システム制御部34は、受取人に家族登録しているユーザが存在しない場合には、受取人と家族とで同じ住所に商品を送付することが選択されていないと判定する。一方、システム制御部34は、受取人に家族登録しているユーザが存在する場合には、受取人が家族の代表者であるか否かを判定する。このとき、システム制御部34は、受取人が家族の代表者であると判定した場合には、受取人の会員登録された住所を商品の送付先の住所として利用することを選択しているユーザが存在するか否かを判定する。このとき、システム制御部34は、存在すると判定した場合には、受取人と家族とで同じ住所に商品を送付することが選択されていると判定し、存在しないと判定した場合には、受取人と家族とで同じ住所に商品を送付することが選択されていないと判定する。システム制御部34は、受取人が家族の代表者ではないと判定した場合には、受取人が家族の代表者の会員登録された住所を商品の送付先の住所として利用することを選択しているか否かを判定する。このとき、選択されていると判定した場合には、受取人と家族とで同じ住所に商品を送付することが選択されていると判定し、選択していないと判定した場合には、受取人と家族とで同じ住所に商品を送付することが選択されていないと判定する。
システム制御部34は、受取人と家族とで同じ住所に商品を送付することが選択されていないと判定した場合には(ステップS101:NO)、受取人のユーザIDに対応する受取可能日時を受取可能日時情報DB32cから検索する(ステップS103)。
一方、システム制御部34は、受取人と家族とで同じ住所に商品を送付することが選択されていると判定した場合には(ステップS101:YES)、注文商品の配送管理情報に設定された別途配達フラグがONであるか否かを判定する(ステップS102)。このとき、システム制御部34は、別途配達フラグがONであると判定した場合には(ステップS102:YES)、ステップS103に移行する。つまり、今回の注文商品については、他の家族とは別途配達することが選択されているので、システム制御部34は、受取人の受取可能日時のみに基づいて、配達予定日時が決定されるようにする。
一方、システム制御部34は、別途配達フラグがONではないと判定した場合には(ステップS102:NO)、受取人と同じ住所に商品を送付することが選択されている家族のユーザIDを取得する(ステップS104)。具体的に、システム制御部34は、受取人が家族の代表者である場合には、家族登録情報から、代表者の会員登録した住所を商品の送付先の住所として利用することを選択しているユーザのユーザIDを取得する。一方、システム制御部34は、受取人が家族の代表者ではない場合には、家族登録情報から、代表者のユーザIDと、代表者の会員登録した住所を商品の送付先の住所として利用することを選択しているユーザのユーザIDを取得する。
次いで、システム制御部34は、受取人のユーザIDに対応する受取可能日時を受取可能日時情報DB32cから検索するとともに、取得した家族のユーザIDに対応する受取可能日時を受取可能日時情報DB32cから検索する(ステップS105)。
システム制御部34は、ステップS103またはS105の処理を終えると、該当する受取可能日時が検索されたか否かを判定する(ステップS106)。このとき、システム制御部34は、受取可能日時が検索されなかったと判定した場合には(ステップS106:NO)、注文商品の配送管理情報に設定された最短配達可能日時を、配達予定日時として決定する(ステップS107)。システム制御部34は、この処理を終えると、配達予定日時決定処理を終了させる。
一方、システム制御部34は、受取可能日時が検索されたと判定した場合には(ステップS106:YES)、検索された受取可能日時から、引数として設定された最短配達可能日時以降である受取可能日時を抽出する(ステップS108)。次いで、システム制御部34は、該当する受取可能日時が抽出されたか否かを判定する(ステップS109)。このとき、システム制御部34は、受取可能日時が抽出されなかったと判定した場合には(ステップS109:NO)、ステップS107に移行する。
一方、システム制御部34は受取可能日時が抽出されたと判定した場合には(ステップS109:YES)、抽出された受取可能日時のうち最先の受取可能日時を、配達予定日時として決定する(ステップS110)。システム制御部34は、この処理を終えると、配達予定日時決定処理を終了させる。
図16及び図17は、本実施形態に係る宅配便サーバ3のシステム制御部34の配達予定日時変更処理における処理例を示すフローチャートである。配達予定日時変更処理は、配送依頼情報受信時処理から呼び出される。つまり、配達予定日時変更処理は、ユーザが配達日時を指定して商品を注文したときに実行される。
図16に示すように、システム制御部34は、注文商品の受取人と、受取人の家族とで同じ住所に商品を送付することが選択されているか否かを判定する(ステップS131)。この判定方法は、図15に示すステップS101の判定方法と同様である。このとき、システム制御部34は、受取人と家族とで同じ住所に商品を送付することが選択されていないと判定した場合には(ステップS131:NO)、受取人のユーザIDを含む配送管理情報を、配送管理情報DB32dから検索する。このとき、システム制御部34は、設定されている配送ステータスが「配達完了」または「配達中」である配送管理情報を、検索対象から除外する。そして、システム制御部34は、検索された配送管理情報を含む検索結果リストを生成する(ステップS133)。
一方、システム制御部34は、受取人と家族とで同じ住所に商品を送付することが選択されていると判定した場合には(ステップS131:YES)、注文商品の配送管理情報に設定された別途配達フラグがONであるか否かを判定する(ステップS132)。このとき、システム制御部34は、別途配達フラグがONであると判定した場合には(ステップS132:YES)、ステップS133に移行する。つまり、今回の注文商品については、他の家族とは別途配達することが選択されているので、システム制御部34は、受取人の家族の注文済商品の配達予定日時が、今回指定された配達日時に変更されないようにする。
一方、システム制御部34は、別途配達フラグがONではないと判定した場合には(ステップS132:NO)、受取人と同じ住所に商品を送付することが選択されている家族のユーザIDを取得する(ステップS134)。この処理内容は、図15に示すステップS104の処理内容と同様である。次いで、システム制御部34は、受取人のユーザIDを含む配送管理情報を、配送管理情報DB32dから検索するとともに、取得した家族のユーザIDを含む配送管理情報を検索する。このとき、システム制御部34は、設定されている配送ステータスが「配達完了」または「配達中」である配送管理情報を、検索対象から除外する。そして、システム制御部34は、検索された配送管理情報を含む検索結果リストを生成する(ステップS135)。
システム制御部34は、ステップS133またはS135の処理を終えると、検索結果リストから配送管理情報を1つ選択する(ステップS136)。
次いで、システム制御部34は、図17に示すように、選択した配送管理情報に設定された一括配達フラグがONであるか否かを判定する(ステップS151)。このとき、システム制御部34は、一括配達フラグがONではないと判定された場合には(ステップS151:NO)、選択した配送管理情報に含まれる配達日時変更可能フラグがONに設定されているか否かを判定する(ステップS152)。このとき、システム制御部34は、配達日時変更可能フラグがONに設定されていないと判定した場合には(ステップS152:NO)、図16に示すように、選択した配送管理情報を、検索結果リストから削除する(ステップS137)。この場合、選択した配送管理情報に設定された配達予定日時は変更されない。
一方、システム制御部34は、配達日時変更可能フラグがONに設定されていると判定した場合には(ステップS152:YES)、選択した配送管理情報に設定されている受取人のユーザIDと注文者のユーザIDとが一致するか否かを判定する(ステップS153)。このとき、システム制御部34は、一致しないと判定した場合には(ステップS153:NO)、選択した配送管理情報に含まれる別途配達フラグがONに設定されているか否かを判定する(ステップS154)。このとき、システム制御部34は、別途配達フラグがONに設定されていると判定した場合には(ステップS154:YES)、ステップS137に移行する。この場合、選択された配送管理情報に対応する注文済商品の受取人は、注文者の家族である。そして、受取人は、注文済商品を、他の家族とは別途配達することを選択している。そのため、配達予定日時は変更されない。
一方、システム制御部34は、ステップS153において選択した配送管理情報に設定されている受取人のユーザIDと注文者のユーザIDとが一致すると判定した場合(ステップS153:YES)、または、ステップS154において別途配達フラグがONに設定されていないと判定した場合には(ステップS154:NO)、選択した配送管理情報に含まれる最短配達可能日時が、今回指定された配達日時よりも遅いか否かを判定する(ステップS155)。つまり、システム制御部34は、第1判定手段として、選択した配送管理情報に対応する注文済商品が、今回指定された配達日時に配達可能であるか否かを判定する。このとき、システム制御部34は、最短配達可能日時が今回指定された配達日時よりも遅いと判定した場合には(ステップS155:YES)、ステップS137に移行する。この場合、選択された配送管理情報に対応する注文済商品は、今回指定された配達日時に配達することができない商品である。そのため、配達予定日時は変更されない。
一方、システム制御部34は、最短配達可能日時が今回指定された配達日時よりも遅くはないと判定した場合には(ステップS155:NO)、選択した配送管理情報に設定されている配達予定日時が、今回指定された配達日時よりも遅いか否かを判定する(ステップS156)。このとき、システム制御部34は、配達予定日時が今回指定された配達日時よりも遅いと判定した場合には(ステップS156:YES)、送信手段として、配達日時変更通知メールを送信する(ステップS157)。具体的に、システム制御部34は、選択した配送管理情報に設定されている受取人のユーザIDに対応する会員情報から、主メールアドレスを取得する。次いで、システム制御部34は、取得した主メールアドレスを、配達日時変更通知メールの宛先として設定する。次いで、システム制御部34は、配達日時変更通知メールの本文に、配達予定日が繰り上げられたことを示すメッセージを設定する。また、システム制御部34は、配達日時変更通知メールの本文に、選択した配送管理情報に設定されている注文番号、配送管理情報に設定されている商品IDに対応する商品の商品名、今回指定された配達日時等を設定する。そして、システム制御部34は、配達日時変更通知メールを送信する。
システム制御部34は、配達予定日時が今回指定された配達日時よりも遅くはないと判定した場合(ステップS156:NO)、または、ステップS157の処理を終えた場合には、変更手段として、選択した配送管理情報の配達予定日時を、今回指定された配達日時に変更する(ステップS158)。次いで、システム制御部34は、ステップS137に移行する。
ステップS151において、システム制御部34は、一括配達フラグがONであると判定した場合には(ステップS151:YES)、選択した配送管理情報から一括配達IDを取得する。次いで、システム制御部34は、検索結果リストから、取得した一括配達IDと同一の一括配達IDを含む配送管理情報を検索する。そして、システム制御部34は、選択した配送管理情報と、検索された配送管理情報とを一群の配送管理情報として選択する(ステップS159)。
次いで、システム制御部34は、選択した一群の配送管理情報の中に、配達日時変更可能フラグがOFFに設定されている配送管理情報があるか否かを判定する(ステップS160)。このとき、システム制御部34は、配達日時変更可能フラグがOFFに設定されている配送管理情報があると判定した場合には(ステップS160:YES)、選択した一群の配送管理情報を、検索結果リストから削除する(ステップS137)。この場合、選択した一群の配送管理情報に設定された配達予定日時は変更されない。
一方、システム制御部34は、配達日時変更可能フラグがOFFに設定されている配送管理情報がないと判定した場合には(ステップS160:NO)、選択した配送管理情報に設定されている受取人のユーザIDと注文者のユーザIDとが一致するか否かを判定する(ステップS161)。このとき、システム制御部34は、一致しないと判定した場合には(ステップS161:NO)、選択した一群の配送管理情報の中に、別途配達フラグがONに設定されている配送管理情報があるか否かを判定する(ステップS162)。このとき、システム制御部34は、別途配達フラグがONに設定されている配送管理情報があると判定した場合には(ステップS162:YES)、ステップS137に移行する。
一方、システム制御部34は、ステップS161において、選択した配送管理情報に設定されている受取人のユーザIDと注文者のユーザIDとが一致すると判定した場合(ステップS161:YES)、または、ステップS162において別途配達フラグがONに設定されている配送管理情報がないと判定した場合には(ステップS162:NO)、選択した一群の配送管理情報の中に、今回指定された配達日時よりも遅い最短配達可能日時が設定されている配送管理情報があるか否かを判定する(ステップS163)。このとき、システム制御部34は、今回指定された配達日時よりも遅い最短配達可能日時が設定されている配送管理情報があると判定した場合には(ステップS163:YES)、ステップS137に移行する。こうして、システム制御部34は、第1判定手段として、選択した配送管理情報に対応する注文済商品が、今回指定された配達日時に配達可能であるか否かを判定し、一括配達が指定された複数の注文済商品のうち少なくとも何れか1つの注文済商品が配達可能ではないと判定した場合には、この一群の注文済商品の配達予定日時を変更しない。
一方、システム制御部34は、今回指定された配達日時よりも遅い最短配達可能日時が設定されている配送管理情報がないと判定した場合には(ステップS163:NO)、ステップS156に移行する。つまり、システム制御部34は、選択した一群の配送管理情報のそれぞれに含まれる配達予定日時を、今回指定された配達日時に変更する。
図16に示すように、システム制御部34は、ステップS137の処理を終えると、検索結果リストにまだ配送管理情報が含まれているか否かを判定する(ステップS138)。このとき、システム制御部34は、検索結果リストにまだ配送管理情報が含まれていると判定した場合には(ステップS138:YES)、ステップS136に移行する。システム制御部34は、ステップS136〜138、151〜S163の処理を繰り返すことにより、受取人の各注文済商品、または、受取人と受取人の家族の各注文済商品について、配送予定日時が変更可能である場合には、配送予定日時を今回指定された配達日時に変更する。そして、システム制御部34は、検索結果リストに配送管理情報が含まれていないと判定した場合には(ステップS138:NO)、配達予定日時変更処理を終了させる。
[4−2−4.一括配達商品選択ページリクエスト受信時の動作]
次に、宅配便サーバ3が、注文完了ページを表示しているユーザ端末8から一括配達商品選択ページリクエストを受信した場合の動作について説明する。図18は、本実施形態に係る宅配便サーバ3のシステム制御部34の一括配達商品選択ページリクエスト受信時処理における処理例を示すフローチャートである。
図18に示すように、システム制御部34は、一括配達商品選択ページリクエストから注文番号を取得する(ステップS171)。次いで、システム制御部34は、取得した注文番号を、注文者のユーザIDに対応付けてRAM34cに一時的に記憶させる。次いで、システム制御部34は、取得した注文番号を含む配送管理情報を、配送管理情報DB32dから検索する(ステップS172)。このとき、システム制御部34は、設定されている配送ステータスが「配達完了」または「配達中」である配送管理情報を、検索対象から除外する。次いで、システム制御部34は、検索した配送管理情報に含まれる配達日時指定フラグがONであるか否かを判定する(ステップS173)。
このとき、システム制御部34は、配達日時指定フラグがONではないと判定した場合には(ステップS173:NO)、注文者のユーザIDを受取人のユーザIDとして含む配送管理情報のうち、最短配達可能日時が設定されている配送管理情報を、配送管理情報DB32dから検索する(ステップS174)。このとき、システム制御部34は、設定されている配送ステータスが「配達完了」または「配達中」である配送管理情報を、検索対象から除外する。また、システム制御部34は、ステップS172において検索した配送管理情報を検索結果から削除する。
次いで、システム制御部34は、検索した配送管理情報に基づいて、一括配達商品選択ページのHTML文書を生成する(ステップS175)。具体的に、システム制御部34は、注文済商品の情報が配送管理情報ごとに商品選択領域310に表示されるようにHTML文書を生成する。このとき、システム制御部34は、同一の一括配達IDが設定されている一群の配送管理情報については、一括配達が指定された一群の注文済商品の単位で選択可能なように、HTML文書を生成する。次いで、システム制御部34は、生成したHTML文書を、ユーザ端末8へ送信する(ステップS176)。システム制御部34は、この処理を終えると、一括配達商品選択ページリクエスト受信時処理を終了させる。
ステップS173において、システム制御部34は、配達日時指定フラグがONであると判定した場合には(ステップS173:YES)、検索した配送管理情報から配達予定日時を取得する(ステップS177)。この配達予定日時は、注文者により今回指定された配達日時である。次いで、システム制御部34は、注文者のユーザIDを受取人のユーザIDとして含む配送管理情報のうち、取得した配達予定日時と同一の配達予定日時が設定されている配送管理情報を、配送管理情報DB32dから検索する(ステップS178)。このとき、システム制御部34は、設定されている配送ステータスが「配達中」である配送管理情報を、検索対象から除外する。また、システム制御部34は、ステップS172において検索した配送管理情報を検索結果から削除する。次いで、システム制御部34は、検索した配送管理情報に基づいて、一括配達商品選択ページのHTML文書を生成し、HTML文書を送信する(ステップS175及びS176)。
HTML文書を受信したユーザ端末8は、受信したHTML文書に基づいて、一括配達商品選択ページを、例えば図11に示すように、画面に表示する。
[4−2−5.一括配達情報受信時の動作]
次に、宅配便サーバ3が、一括配達商品選択ページを表示しているユーザ端末8から一括配達情報を受信した場合の動作について説明する。図19は、本実施形態に係る宅配便サーバ3のシステム制御部34の一括配達情報受信時処理における処理例を示すフローチャートである。一括配達情報は、図11に示す一括配達商品選択ページにおいてユーザが決定ボタン320を選択したときに、ユーザ端末8から送信される。
図19に示すように、システム制御部34は、受信した一括配達情報に、注文番号及び商品IDが含まれているか否かを判定する(ステップS201)。つまり、システム制御部34は、注文商品と一括配達する注文済商品が選択されたか否かを判定する。このとき、システム制御部34は、注文番号及び商品IDが含まれていないと判定した場合には(ステップS201:NO)、一括配達情報受信時処理を終了させる。
一方、システム制御部34は、注文番号及び商品IDが含まれていると判定した場合には(ステップS201:YES)、RAM24cから、注文者のユーザIDに対応付けられた注文番号を取得する。次いで、システム制御部34は、取得した注文番号を含む配送管理情報を、配送管理情報DB32dから検索する(ステップS202)。つまり、システム制御部34は、注文商品の配送管理情報を検索する。次いで、システム制御部34は、一括配達情報から注文番号及び商品IDを取得する。次いで、システム制御部34は、取得した注文番号及び商品IDを含む配送管理情報を、配送管理情報DB32dから検索する(ステップS203)。つまり、システム制御部34は、注文商品と一括で配達される注文済商品の配送管理情報を検索する。このとき、システム制御部34は、一括配達情報に、注文番号及び商品IDの組が複数含まれている場合には、組ごとに検索を行う。
次いで、システム制御部34は、注文商品の配送管理情報及びS203において検索した配送管理情報の一括配達フラグをONに設定する(ステップS204)。次いで、システム制御部34は、新しい一括配達IDを生成する。次いで、システム制御部34は、注文商品の配送管理情報及びS203において検索した配送管理情報に、生成した一括配達IDを設定する(ステップS205)。
次いで、システム制御部34は、注文商品の配送管理情報に含まれる配達日時指定フラグがONであるか否かを判定する(ステップS206)。このとき、システム制御部34は、配達日時指定フラグがONであると判定した場合には(ステップS206:YES)、一括配達情報受信時処理を終了させる。
一方、システム制御部34は、配達日時指定フラグがONではないと判定した場合には(ステップS206:NO)、注文商品の配送管理情報と、S203において検索した配送管理情報とから、それぞれ最短配達可能日時を取得する(ステップS207)。次いで、システム制御部34は、取得した最短配達可能日時のうち最も遅い最短配達可能日時を、配達予定日時決定処理の引数として選択する(ステップS208)。
次いで、システム制御部34は、配達予定日時決定処理を実行する(ステップS209)(図15参照)。この場合、配達予定日時決定処理では、注文者等が設定した受取可能日時のうち、注文商品及び注文商品と一括配達する商品として選択された注文済商品の何れもが配達可能な最先の日時が、配達予定日として決定される。次いで、システム制御部34は、配達予定日時決定処理において決定された配達予定日時を、注文商品の配送管理情報に設定する(ステップS210)。システム制御部34は、この処理を終えると、一括配達情報受信時処理を終了させる。
[4−3.伝票番号発行の動作]
次に、伝票番号発行時における配送システムSの動作について説明する。
店舗の従業員は、注文された商品の注文番号を店舗端末7に入力する。そして、従業員は、伝票番号の発行を選択する。すると、店舗端末7は、入力された注文番号を宅配便サーバ3へ送信する。
宅配便サーバ3は、受信した注文番号を含む配送管理情報を、配送管理情報DB32dから検索する。次いで、宅配便サーバ3は、新しい伝票番号を生成する。次いで、宅配便サーバ3は、検索した配送管理情報に、生成した伝票番号を設定する。また、宅配便サーバ3は、検索した配送管理情報から注文番号を取得する。次いで、宅配便サーバ3は、取得した注文番号を含む購入履歴を購入履歴DB22bから検索する。そして、宅配便サーバ3は、検索した購入履歴に伝票番号を設定する。次いで、宅配便サーバ3は、生成した伝票番号を店舗端末7へ送信する。
なお、注文者が同時に複数の商品を注文した場合、配送管理情報DB32dには、店舗の従業員により入力された注文番号と同じ注文番号を含む配送管理情報が複数登録されている場合がある。その場合、宅配便サーバ3は、例えば、配送管理情報ごとに伝票番号を生成して、店舗端末7へ送信してもよい。
また、注文者が、支払い方法・配送方法選択ページの希望入力欄において、今回注文する商品と、店舗からまだ発送されていない注文済商品とを同梱して配達するように依頼するメッセージを入力する場合がある。この場合、メッセージを確認した従業員は、それぞれの商品の注文番号を店舗端末7に入力する。すると、店舗端末7は、入力された複数の注文番号を宅配便サーバ3へ送信する。
宅配便サーバ3は、複数の注文番号を受信した場合には、それぞれの注文番号を含む配送管理情報を検索する。そして、宅配便サーバ3は、検索した配送管理情報を統合する。このとき、宅配便サーバ3は、統合前の配送管理情報に設定されている情報を、必要に応じて新しい配送管理情報に引き継がせる。このとき、宅配便サーバ3は、統合前のそれぞれの配送管理情報に設定されている注文番号及び商品IDをそれぞれ新しい配送管理情報に引き継がせる。また、宅配便サーバ3は、統合前のそれぞれの配送管理情報に設定されていた最短配達可能日時のうち最も遅い最短配達可能日時を、新しい配送管理情報に引き継がせる。また、宅配便サーバ3は、統合前のそれぞれの配送管理情報に設定されて配達予定日時のうち最も遅い配達予定日時を、新しい配送管理情報に引き継がせる。次いで、宅配便サーバ3は、新しい伝票番号を1つ生成する。次いで、宅配便サーバ3は、新しい配送管理情報に、生成した伝票番号を設定する。次いで、宅配便サーバ3は、生成した伝票番号を店舗端末7へ送信する。
[4−4.配送状況入力時の動作]
次に、配送センターの従業員や配達員が商品の配送状況を入力した場合における動作について説明する。
配送センターの従業員が配送状況を入力する場合、従業員は、バーコードリーダ等により、商品に付された配送伝票から伝票番号を入力する。また、従業員は、配送センター端末5を操作して、配送状況に対応する配送ステータスを選択する。すると、配送センター端末5は、配送状況情報を宅配便サーバ3へ送信する。
また、配達員が配送状況入力する場合も同様に、配達員は、商品に付された配送伝票から伝票番号を入力し、配達員端末6を操作して、配送ステータスを選択する。すると、配達員端末6は、配送状況情報を宅配便サーバ3へ送信する。
配送状況情報は、入力された伝票番号及び選択された配送ステータスを含む。また、配送状況情報は、現在日時を記録日時として含む。また、配送状況情報は、配送状況の入力を行った従業員または配達員が属する配送センターのセンターIDを含む。なお、配送センターの従業員や配達員がY社に属する場合、配送センター端末5や配達員端末6から提携宅配業者サーバ4へ配送状況情報が送信され、提携宅配業者サーバ4から宅配便サーバ3へ配送状況情報が転送される。
図20及び図21は、本実施形態に係る宅配便サーバ3のシステム制御部34の配送状況情報受信時処理における処理例を示すフローチャートである。配送状況情報受信時処理は、宅配便サーバ3が配送状況情報を受信したときに開始される。
図20に示すように、システム制御部34は、受信した配送状況情報を、配送状況履歴として配送状況履歴DB32eに登録する(ステップS251)。次いで、システム制御部34は、配送状況情報から伝票番号を取得する。次いで、システム制御部34は、取得した伝票番号を含む配送管理情報を、配送管理情報DB32dから検索する(ステップS252)。次いで、システム制御部34は、検索した配送管理情報に含まれる配送ステータスを、受信した配送状況情報に含まれる配送ステータスに変更する(ステップS253)。
次いで、システム制御部34は、受信した配送状況情報に含まれる配送ステータスが「配達員受取」、「非担当配送センター到着」及び「担当配送センター到着」のうち何れかであるか否かを判定する(ステップS254)。このとき、システム制御部34は、配送ステータスが「配達員受取」、「非担当配送センター到着」及び「担当配送センター到着」のうち何れかであると判定した場合には(ステップS254:YES)、受信した配送状況情報に含まれる配送センターIDと、検索した配送管理情報の送付先情報に含まれる郵便番号と、に対応する配達可能日時算出用情報を、配送センター情報DB32bから検索する(ステップS255)。次いで、システム制御部34は、配達可能日時算出用情報に基づいて、最短配達可能日時を計算する(ステップS256)。この計算方法は、図13に示すステップS53における計算方法と基本的に同様である。次いで、システム制御部34は、計算した最短配達可能日時を、検索した配送管理情報に設定する(ステップS257)。つまり、システム制御部34は、商品が発送されたときに最短配達可能日時を改めて設定するとともに、商品が配送センターに運び込まれてくる都度、最短配達可能日時を改めて設定する。これにより、商品が配送センター間を回送されている過程において、商品がユーザの住所へ近づくほど、最短配達可能日時がより正確になる。基本的には、商品がユーザの住所へ近づくほど、最短配達可能日時が短くなるようになっている。
次いで、システム制御部34は、受信した配送状況情報に含まれる配送ステータスが「配達員受取」であるか否かを判定する(ステップS258)。このとき、システム制御部34は、配送ステータスが「配達員受取」ではないと判定した場合には(ステップS258:NO)、配送状況情報受信時処理を終了させる。一方、システム制御部34は、配送ステータスが「配達員受取」であると判定した場合には(ステップS258:YES)、検索した配送管理情報に設定した最短配達可能日時に、配達員が商品を配達センターに運び込むまでに要する時間として予め設定された時間を加算する(ステップS259)。
次いで、システム制御部34は、検索した配送管理情報に配達予定日時が設定されているか否かを判定する(ステップS260)。このとき、システム制御部34は、配達予定日時が設定されていると判定した場合には(ステップS260:YES)、配送状況情報受信時処理を終了させる。
一方、システム制御部34は、配達予定日時が設定されていないと判定した場合には(ステップS260:NO)、検索した配送管理情報に受取人のユーザIDが設定されているか否かを判定する(ステップS261)。つまり、システム制御部34は、受取人がサービス提供サイトの会員であるか否かを判定する。このとき、システム制御部34は、受取人のユーザIDが設定されていると判定した場合には(ステップS261:YES)、配達予定日時決定処理を実行する(ステップS262)。このとき、システム制御部34は、計算した最短配達可能日時を引数として設定する。次いで、システム制御部34は、配達予定日時決定処理において決定された配達予定日時を、検索した配送管理情報に設定する(ステップS263)。つまり、システム制御部34は、注文時点ではいつ発送されるか不明であった商品の配送予定日時を、発送の時点で設定する。こうして、システム制御部34は、日取得手段として、受取人等が設定した受取可能日時のうち注文商品を配達可能な最先の日時を記憶部32から取得し、配達情報記憶制御手段として、取得された日時を配達予定日時として含む配送管理情報を記憶部32に記憶させる。システム制御部34は、この処理を終えると、配送状況情報受信時処理を終了させる。
一方、システム制御部34は、受取人のユーザIDが設定されていないと判定した場合には(ステップS261:NO)、計算した最短配達可能日時を配達予定日時として、検索した配送管理情報に設定する(ステップS264)。システム制御部34は、この処理を終えると、配送状況情報受信時処理を終了させる。
ステップS254において、システム制御部34は、配送ステータスが「配達員受取」、「非担当配送センター到着」及び「担当配送センター到着」の何れでもないと判定した場合には(ステップS254:NO)、図21に示すように、受信した配送状況情報に含まれる配送ステータスが「配達中」であるか否かを判定する(ステップS281)。このとき、システム制御部34は、配送ステータスが「配達中」であると判定した場合には(ステップS281:YES)、配達日時通知メールを送信する(ステップS282)。具体的に、システム制御部34は、検索した配送管理情報に設定されている受取人のユーザIDに対応する会員情報から、携帯メールアドレスを取得する。次いで、システム制御部34は、取得した携帯メールアドレスを、配達日時通知メールの宛先として設定する。次いで、システム制御部34は、配達日時通知メールの本文に、これから受取人へ配達が行われることを示すメッセージを設定する。また、システム制御部34は、配達日時通知メールの本文に、検索した配送管理情報に設定されている注文番号、伝票番号及び配達予定日時、配送管理情報に設定されている商品IDに対応する商品の商品名等を設定する。そして、システム制御部34は、配達日時通知メールを送信する。システム制御部34は、この処理を終えると、配送状況情報受信時処理を終了させる。
一方、システム制御部34は、配送ステータスが「配達中」ではないと判定した場合には(ステップS281:NO)、受信した配送状況情報に含まれる配送ステータスが「配達完了」であるか否かを判定する(ステップS283)。このとき、システム制御部34は、配送ステータスが「配達完了」ではないと判定した場合には(ステップS283:NO)、配送状況情報受信時処理を終了させる。
一方、システム制御部34は、配送ステータスが「配達完了」であると判定した場合には(ステップS283:YES)、受信した配送状況情報に含まれる記録日時を配達完了日時として取得する。そして、システム制御部34は、取得した配達完了日時を、ステップS252において検索した配送管理情報に設定する(ステップS284)。なお、「配達完了」が設定された配送ステータスを含む配送状況情報は、本発明における配達完了情報の一例である。次いで、システム制御部34は、検索した配送管理情報に受取人のユーザIDが設定されているか否かを判定する(ステップS285)。このとき、システム制御部34は、受取人のユーザIDが設定されていないと判定した場合には(ステップS285:NO)、配送状況情報受信時処理を終了させる。
一方、システム制御部34は、受取人のユーザIDが設定されていると判定した場合には(ステップS285:YES)、ステップS252において検索した配送管理情報から取得した伝票番号を含む配送状況履歴を、配送状況履歴DB32eから検索する(ステップS286)。次いで、システム制御部34は、ステップS286において検索した配送状況履歴の中に、配送ステータスが「受取人不在」に設定されている配送状況履歴があるか否かを判定する(ステップS287)。このとき、システム制御部34は、配送ステータスが「受取人不在」に設定されている配送状況履歴がないと判定した場合には(ステップS287:NO)、受取人の保有ポイント数にポイントを加算する(ステップS288)。つまり、受取人が1回目の配達で商品を受け取ったため、受取人にポイントが付与される。具体的に、システム制御部34は、検索した配送管理情報から受取人のユーザIDを取得する。次いで、システム制御部34は、取得したユーザIDに対応する会員情報に含まれる保有ポイント数に、予め設定されたポイント数を加算する。
こうして、システム制御部34は、第4判定手段として、配送状況履歴に基づいて、商品の1回目の配達で商品が受け取られたか否かを判定する。そして、システム制御部34は、1回目の配達で商品が受け取られたと判定した場合には、第2報酬情報記憶制御手段として、報酬としてのポイント数が加算された保有ポイント数を記憶部32に記憶させる。
システム制御部34は、ステップS287において配送ステータスが「受取人不在」に設定されている配送状況履歴があると判定した場合(ステップS287:YES)、または、ステップS288の処理を終えた場合には、ステップS252において検索した配送管理情報から受取人のユーザIDを取得する。次いで、システム制御部34は、取得したユーザIDと同一のユーザIDを含む配送管理情報のうち、配送ステータスが「配達完了」に設定されている配送管理情報を、配送管理情報DB32dから検索する(ステップS289)。つまり、システム制御部34は、受取人への配達が完了した商品に対応する配送状況履歴を検索する。このとき、システム制御部34は、ステップS252において検索した配送管理情報を、検索結果から削除する。
次いで、システム制御部34は、ステップS289において検索した配送管理情報から、配達完了日時を取得する。次いで、システム制御部34は、取得した配達完了日時のうち最新の配達完了日時を選択する。次いで、システム制御部34は、選択した最新の配達完了日時と、ステップS284において取得した配達完了日時との差が、記憶部32に記憶されている設定時間以下であるか否かを判定する(ステップS290)。つまり、システム制御部34は、配達員が、同一の受取人について、ある商品の配達が完了したことを配達員端末6に入力してから設定時間内に別の商品の配達が完了したことを配達員端末6に入力したか否かを判定する。
このとき、システム制御部34は、差が設定時間以下であると判定した場合には(ステップS290:YES)、受取人の保有ポイント数にポイントを加算する(ステップS291)。この処理内容は、ステップS288と同様である。システム制御部34は、配達員が、同一の受取人について、ある商品の配達が完了したことを入力してから設定時間内に別の商品の配達が完了したことを入力した場合には、これらの商品を受取人が一括で受け取ったものとみなして、受取人にポイントを付与する。設定時間は、例えば、宅配便サーバ3の管理者により予め設定される。例えば、設定時間は、配達時間帯として指定可能な配達時間帯のうち最も短い配達時間帯(本実施形態においては、1時間)よりも短い時間である。そして、設定時間は、受取人が2つの商品を一括して受け取ったとみなす程度の長さに設定される。例えば、設定時間は、10分等に設定される。なお、受取人が同時に受け取った商品の数が多いほど、加算されるポイント数が多くなる。例えば、商品A、B及びCを受取人が受け取ったとする。配達員は、商品A、B及びCの順で、配達が完了したことを入力したとする。ここで、商品Aについての入力から商品Bについての入力までに要した時間が設定時間内であれば、予め設定されたポイント数が加算される。また、商品Bについての入力から商品Cについての入力までに要した時間が設定時間内であれば、予め設定されたポイント数が更に加算される。
なお、配達員が、配達する商品を配送センターから運び出すとき、運び出される商品の中には、受取人が同一である複数の商品が含まれている場合がある。この場合、受取人が同一である複数の商品は、通常一括で配達される。そのため、システム制御部34は、受取人が同一である複数の商品が配送センターから同時に運び出され、これらの商品のうち少なくとも何れか1つの配達が完了した時点で、受取人が複数の商品を一括で受け取ったものとみなして、受取人にポイントを付与してもよい。具体的に、受取人が同一であり、且つ、配達予定日時が同一の複数の商品は、一括で配達される。そのため、システム制御部34は、このような条件を満たす複数の商品のうち1つの配達が完了した時点で、受取人が複数の商品を一括で受け取ったものとみなしてもよい。システム制御部34は、配送ステータスが「配達完了」である配送状況情報を受信したとき、対応する配送管理情報から、受取人のユーザID及び配達予定日時を取得する。次いで、システム制御部34は、取得したユーザID及び配達予定日時を含む配送管理情報を、配送管理情報DB32dから検索する。このとき、複数の配送管理情報が検索された場合には、複数の商品が一括で配送されることになっている。そこで、システム制御部34は、複数の配送管理情報が検索された場合には、受取人にポイントを付与する。なお、このとき、システム制御部34は、配送ステータスが「配達中」になっている配送管理情報のみを検索してもよい。ただし、システム制御部34は、配送管理情報の更新を、商品ごとに行う。そのため、配達員は、配達員端末6に対して、商品ごとに、配送が完了した旨の操作を行う。システム制御部34は、一括で配達中である複数の商品のそれぞれについて、配送状況情報を受信する。ここで、システム制御部34は、最初に受信した配送状況情報に応じて、受取人にポイントを付与すればよい。そして、システム制御部34は、その後に受信した配送状況情報については、受取人にポイントを付与しなくてもよい。
こうして、システム制御部34は、第3判定手段として、受信した配送状況情報に含まれる配達完了日時に基づいて、複数の商品が一括で受け取られたか否かを判定する。そして、システム制御部34は、複数の商品が一括で受け取られたと判定した場合には、第1報酬情報記憶制御手段として、報酬としてのポイント数が加算された保有ポイント数を記憶部32に記憶させる。
システム制御部34は、ステップS290において差が設定時間以下ではないと判定した場合(ステップS290:NO)、または、ステップS291の処理を終えた場合には、配送状況情報受信時処理を終了させる。
[4−5.配送状況閲覧時の動作]
次に、ユーザが商品の配送状況を閲覧する場合の動作について説明する。図22は、本実施形態に係る配送システムSの配送状況閲覧時における処理例を示すシーケンス図である。
例えば、ユーザ端末8に電子商店街のWebページが表示されている状態において、ユーザが、配送状況の閲覧を選択すると、ユーザ端末8は、配送状況一覧ページのリクエストを宅配便サーバ3へ送信する(ステップS301)。配送状況一覧ページは、商品の配送状況の一覧を表示するWebページである。なお、配送状況の閲覧するユーザを、「閲覧者」という。
宅配便サーバ3は、リクエストを受信すると、閲覧者のユーザIDを含む配送管理情報を配送管理情報DB32dから検索する。なお、宅配便サーバ3は、配送ステータスが「配達完了」に設定されている配送管理情報については、配達完了日が現時点から予め設定された期間内(例えば、過去1ヶ月以内)である配送管理情報のみを検索対象としてもよい。そして、宅配便サーバ3は、検索した配送管理情報に基づいて配送状況一覧ページを生成する(ステップS302)。具体的に、宅配便サーバ3は、配送管理情報ごとに、配送状況が表示されるように、配送状況一覧ページ生成する。また、宅配便サーバ3は、配送ステータスが「配達完了」ではなく、且つ、配達予定日時が設定されている配送管理情報について、閲覧者が配達日時を変更可能なように、配送状況一覧ページ生成する。このとき、宅配便サーバ3は、一括配達フラグがONであり、且つ、一括配達IDが同一である一群の配送管理情報については、一括でのみ配達日時を変更可能なようにする。宅配便サーバ3は、生成した配送状況一覧ページをユーザ端末8へ送信する(ステップS303)。ユーザ端末8は、受信した配送状況一覧ページを画面に表示する(ステップS304)。
図23は、配送状況一覧ページの画面表示例を示す図である。図23に示すように、配送状況一覧ページは、配送状況一覧表示領域410等を含む。
配送状況一覧表示領域410には、配送状況の一覧が表示される。具体的に、伝票番号、注文番号、商品名、配送状況、配達予定日時(配達が完了した場合は配達完了日時)等が、伝票番号ごとに表示される。なお、宅配便サーバ3は、注文者と受取人とが異なる商品については、商品名が表示されないようにしてもよい。例えば、注文者が受取人へのプレゼントとして商品を注文した場合には、如何なる商品が送られてくるかを受取人が事前に知らない方がよい場合があるからである。
配送状況としては、例えば、「未発送」、「発送」、「配達可能」、「配達中」、「配達完了」等がある。配送ステータスが「未発送」である場合、配送状況は「未発送」となる。また、配送ステータスが「配達員受取」、「非担当配送センター到着」及び「回送」の何れかである場合、配送状況は「発送」となる。また、配送ステータスが「担当配送センター到着」及び「受取人不在」の何れかである場合、配送状況は「配達可能」となる。また、配送ステータスが「配達中」である場合、配送状況は「配達中」となる。また、配送ステータスが「配達完了」である場合、配送状況は「配達完了」となる。
なお、配送状況に加えて、現在商品を保管している配送センターや、商品を配送している配達員が属する配送センターの名称が表示されてもよい。現在商品を保管している配送センター及び商品を配送している配達員が属する配送センターを、「取扱中配送センター」という。具体的に、システム制御部34は、配送管理情報DB32dに登録される配送管理情報に、取扱中配送センターのセンターIDが登録されるようにする。電子商店街サーバ1が配送センター端末5や配達員端末6等から受信する配送状況情報には、配送状況の入力を行った従業員または配達員が属する配送センターのセンターIDが含まれている。そこで、システム制御部34は、配送状況情報を受信して、配送管理情報の配送ステータスを更新するとき、配送状況情報に含まれるセンターIDを、取扱中配送センターのセンターIDとして、配送管理情報に設定する。そして、システム制御部34は、配送管理情報に含まれるセンターIDが示す配送センターの名称が配送状況一覧表示領域410に表示されるように、配送状況一覧ページを生成する。
また、配送状況一覧表示領域410には、配送状況が「配達完了」ではなく、且つ、配達予定日時が表示されている商品に対応して、変更ボタンが表示される。
ユーザが何れかの変更ボタンを選択すると、ユーザ端末8は、配達日時変更ウインドウを画面に表示する(ステップS305)。配達日時変更ウインドウは、新しい配達日時を指定するためのウインドウである。ユーザは、配達日時変更ウインドウに表示されたプルダウンメニューやチェックボックスに対して操作を行うことにより、変更後の配達日時を指定すると、ユーザ端末8は、選択された変更ボタンに対応する伝票番号と、指定された配達日時とを含む配達日時変更リクエストを宅配便サーバ3へ送信する(ステップS306)。
宅配便サーバ3は、受信した配達日時変更リクエストに含まれる伝票番号を含む配送管理情報を、配送管理情報DB32dから検索する。そして、宅配便サーバ3は、検索した配送管理情報に含まれる配達予定日時を、受信した配達日時変更リクエストに含まれる配達日時に変更する(ステップS307)。
また、宅配便サーバ3は、閲覧者のユーザIDを受取人のユーザIDとして含む配送管理情報のうち、配送ステータスが「配達完了」ではなく、且つ、最短配達可能日時が、変更後の配達予定日よりも早い配送管理情報を配送管理情報DB32dから検索する。そして、宅配便サーバ3は、検索した配送管理情報に基づいて配達日時変更候補一覧ページを生成する(ステップS308)。配達日時変更候補一覧ページは、配達予定日時が変更された商品と同じ日時に配達予定日時を変更可能な商品の一覧を表示するWebページである。宅配便サーバ3は、生成した配達日時変更候補一覧ページをユーザ端末8へ送信する(ステップS309)。ユーザ端末8は、受信した配達日時変更候補一覧ページを画面に表示する(ステップS310)。
図24は、配達日時変更候補一覧ページの画面表示例を示す図である。図24に示すように、配達日時変更候補一覧ページは、変更候補一覧表示領域510、変更ボタン520等を含む。
変更候補一覧表示領域510には、配達予定日時の変更候補とされた商品の配送状況の一覧が表示される。具体的に、伝票番号、注文番号、商品名、配送状況、配達予定日時、配達予定日時を変更するか否かを選択するためのチェックボックス等が、伝票番号ごとに表示される。
配達日時変更候補一覧ページにおいて、ユーザは、必要に応じて商品の選択操作を行い、変更ボタン520を選択する。すると、ユーザ端末8は、選択された商品の伝票番号を含む配達日時一括変更リクエストを宅配便サーバ3へ送信する(ステップS311)。
宅配便サーバ3は、受信した配達日時一括変更リクエストに含まれる伝票番号を含む配送管理情報を、配送管理情報DB32dから検索する。そして、宅配便サーバ3は、検索した配送管理情報に含まれる配達予定日時を、先に受信した配達日時変更リクエストに含まれる配達日時に変更する(ステップS312)。このとき、宅配便サーバ3は、配達日時一括変更リクエストに複数の伝票番号が含まれている場合、全ての伝票番号について配達予定日時を変更する。
このように、ユーザは、自分を受取人とする商品の配送状況を確認することができる。また、ユーザは、商品の配達日時を自由に変更することができる。また、ユーザは、複数の商品の配達日時を一括して同じ配達日時に容易に変更することができる。
商品の配送状況は、購入履歴からも閲覧可能である。例えば、ユーザ端末8に電子商店街のWebページが表示されている状態において、閲覧者が、商品の購入履歴の閲覧を選択すると、ユーザ端末8は、購入履歴一覧ページのリクエストを電子商店街サーバ2へ送信する。購入履歴一覧ページは、購入履歴の一覧を表示するWebページである。電子商店街サーバ2は、閲覧者のユーザIDを含む購入履歴を購入履歴DB22bから検索する。そして、電子商店街サーバ2は、検索した購入履歴に基づいて、購入履歴一覧ページを生成する。そして、電子商店街サーバ2は、生成した購入履歴一覧ページをユーザ端末8へ送信する。購入履歴一覧ページには、過去の注文ごとに、購入日時、注文先の店舗の店舗名、注文された商品の商品名、配送方法等が表示される。配送方法が電子商店街宅配便である場合には、更に、配送状況を閲覧するための配送状況ボタンが表示される。
閲覧者が配送状況ボタンを選択すると、ユーザ端末8は、配送状況ページのリクエストを宅配便サーバ3へ送信する。配送状況ページは、ユーザに指定された商品の配送状況が表示されるWebページである。配送状況ページのリクエストは、選択された配送状況ボタンに対応する商品の伝票番号を含む。宅配便サーバ3は、受信したリクエストに含まれる伝票番号を含む配送管理情報を配送管理情報DB32dから検索し、検索した配送管理情報に基づいて、配送状況ページを生成する。配送状況ページの生成方法は、配送状況一覧ページの生成方法と基本的に同様である。宅配便サーバ3は、生成した配送状況ページをユーザ端末8へ送信する。
なお、配達日時変更候補一覧ページにおいてユーザが選択した商品と、先に配達予定日時が変更された商品とを一括で配達するように、ユーザが指定することができるようになっていてもよい。この場合、これらの商品は、一群の商品として一括配達の対象となる。
また、配達日時通知メールに対してユーザが返信した場合の配達予定日時の変更は、例えば、宅配便サーバ3の管理者が手作業で行ってもよいし、宅配便サーバ3が、返信された電子メールに基づいて行ってもよい。
以上説明したように、本実施形態によれば、宅配便サーバ3のシステム制御部34が、注文者により配達日が指定されずに商品が注文された場合、そのユーザが予め設定した日として記憶部32に記憶されている受取可能日のうち、注文商品の配達が可能な最先の受取可能日を取得し、取得された受取可能日を注文商品の配達予定日として含む配送管理情報を記憶部32に記憶させる。また、システム制御部34が、注文者により配達日が指定されて商品が注文された場合、記憶部32に既に記憶されている配送管理情報に含まれる配達予定日を、今回指定された配達日に変更する。従って、注文者が予め設定した日が、注文商品の配達日となった後に、その配達日を容易に変更することができる。
また、システム制御部34が、注文者により配達日が指定されずに商品が注文された場合であって、注文済商品と今回の注文商品との一括配達が指定された場合、注文済商品と今回の注文商品との何れも配達可能な最先の受取可能日を記憶部32から取得し、取得された受取可能日を配達予定日として含む配送管理情報を記憶部32に記憶させ、今回の注文商品と一括で配達されるように指定された注文済商品の配送管理情報に含まれる配達予定日に、取得された受取可能日を設定する。従って、注文者は、商品を一括して受け取ることができる。
また、システム制御部34が、注文者により配達日が指定されて商品が注文された場合、注文済商品が今回指定された配達日に配達可能であるか否かを判定し、注文済商品のうち今回指定された配達日に配達可能であると判定された注文済商品の配達予定日を変更し、一括配達が指定された複数の注文済商品のうち少なくとも何れか1つが今回指定された配達日に配達可能ではないと判定された場合、この複数の商品それぞれの配送管理情報に含まれる配達予定日を変更しない。従って、一括配達が指定された複数の商品のうち一部の商品のみの配達予定日が変更されることを防止することができる。よって、この複数の商品の配達予定日は互いに同一のままとなるので、注文者は、商品を一括して受け取ることができる。
また、システム制御部34が、注文者により配達日が指定されずに商品が注文された場合、注文者のユーザIDと、注文者と家族登録がされたユーザであって注文者と住所が同じとみなされたユーザのユーザIDと、の何れかに対応付けて記憶部32に記憶されている受取可能日時のうち、注文商品の配達が可能な最先の受取可能日を取得し、取得された受取可能日を注文商品の配達予定日として含む配送管理情報を記憶部32に記憶させる。従って、注文者が商品を受け取るのに都合がよくない日であっても、他のユーザが商品を受け取ることができる。その結果、商品を注文した注文者が商品を受け取ることができる。
また、システム制御部34が、注文者により配達日が指定されて商品が注文された場合、記憶部32に既に記憶されている配送管理情報のうち、注文者のユーザIDと、注文者と家族登録がされたユーザであって注文者と住所が同じとみなされたユーザのユーザIDと、の何れかに対応付けられている配送管理情報に含まれる配達予定日を、今回指定された配達日に変更する。従って、他のユーザが注文した商品を、今回商品を注文したユーザが受け取ることができる。その結果、他のユーザは、自分が注文した商品を受け取ることができる。
また、システム制御部34が、注文者により配達日が指定されずに商品が注文された場合であって、注文者により受取人の送付先情報が入力された場合、この送付先情報に基づいて、受取人のユーザIDを取得し、取得されたユーザIDに対応付けて記憶部32に記憶されている受取可能日のうち、注文された商品の配達が可能な最先の受取可能日を取得し、取得された受取可能日を注文商品の配達予定日として含む配送管理情報を記憶部32に記憶させる。従って、受取人が注文者とは別人であっても、受取人は、自分の都合がよい日に商品を受け取ることができる。
また、システム制御部34が、記憶部32に記憶されている配送管理情報に含まれる配達予定日がこの配達予定日よりも早い配達日に変更された場合、受取人宛てに配達日時変更通知メールを送信する。従って、受取人が知らないうちに、配達員が商品の配達に向かうことを防止することができる。
また、システム制御部34が、配達員端末6から配達ステータスが「配達完了」に設定されている配送状況情報を取得した場合、配送伝票が互いに異なる複数の商品が一括でユーザに受け取られたか否かを判定し、受け取られたと判定された場合、このユーザの会員情報に含まれる保有ポイント数に、予め設定されたポイント数を加算する。従って、ユーザが複数の商品を一括で受け取るようになることが期待されるので、配達員が同じ住所へ何度も配達に向かうことを防止することができる。
また、システム制御部34が、記憶部32に記憶された配送状況履歴に基づいて、商品の1回目の配達でこの商品がユーザにより受け取られたか否かを判定し、受け取られたと判定された場合、このユーザの会員情報に含まれる保有ポイント数に、予め設定されたポイント数を加算する。従って、ユーザが配達予定日に商品を受け取るようになることが期待される。そのため、配達員が同じ商品について何度も配達に向かうことを防止することができる。
なお、上記実施形態において、宅配便サーバ3は、注文者により配達日時が指定されて商品が注文された場合、注文済商品の配達予定日時が、指定された配達日時よりも早いか遅いかにかかわらず、注文済商品の配達予定日時を変更していた。しかしながら、宅配便サーバ3は、注文済商品の配達予定日時が、指定された配達日時よりも遅い場合にのみ、配達予定日時を変更してもよい。これにより、ユーザは、注文済商品をより早く受け取ることができるとともに、注文済商品の配達日時が遅くなることを防止することができる。
具体的に、システム制御部34は、図17に示す配達予定日時変更処理のステップS156において、選択した配送管理情報に設定されている配達予定日時が、今回指定された配達日時よりも遅いか否かを判定し、配達予定日時が今回指定された配達日時よりも遅いと判定した場合には(ステップS156:YES)、配達日時変更通知メールの送信し(ステップS157)、選択した配送管理情報の配達予定日時を、今回指定された配達日時に変更する(ステップS158)。この点は、変わらない。一方、システム制御部34は、配達予定日時が今回指定された配達日時よりも遅いと判定した場合には(ステップS156:NO)、配達予定日時を変更しないで、ステップS137に移行する。
また、上記実施形態において、宅配便サーバ3は、注文者が、会員登録した住所とは別の住所へ商品を送付することを選択した場合、注文者が入力した送付先情報に基づいて受取人を特定して、受取人のユーザIDを取得していた。しかしながら、注文者により送付先情報とともに、受取人の電子メールアドレスが入力されるようにしてもよい。そして、宅配便サーバ3は、入力された電子メールアドレスに基づいて受取人のユーザIDを取得してもよい。この場合の受取人の電子メールアドレスは、本発明における特定情報の一例である。
具体的に、注文者情報入力ページには、受取人の電子メールアドレスを入力するための入力欄を含む。注文者が、送付先情報及び電子メールアドレスを入力すると、ユーザ端末8は、入力された送付先情報及び電子メールアドレスを電子商店街サーバ2へ送信する。電子商店街サーバ2は、宅配便サーバ3へ配送依頼情報を送信するとき、受取人の電子メールアドレスを配送依頼情報に含める。
宅配便サーバ3のシステム制御部34は、図13に示す配送依頼情報受信時処理のステップS54において、会員登録した住所へ送付しないと判定した場合には(ステップS54:NO)、図14に示すステップS81〜S84の処理を実行しないで、ステップS85に移行する。また、システム制御部34は、ステップS85において配達日が指定されていないと判定した場合には(ステップS85:NO)、ステップS86及びS87を実行せずに、ステップS88に移行する。つまり、システム制御部34は、この時点では、注文商品の配達予定日時を設定しない。そして、システム制御部34は、ステップS90において、注文通知メールを送信する。この場合、システム制御部34は、注文通知メールの宛先に、注文者により入力された電子メールアドレスを設定する。また、システム制御部34は、注文通知メールの本文に、注文商品と受取人とを関連付けるためのURLを設定する。このとき、システム制御部34は、このURLに、注文商品の注文番号を付加する。
受取人は、ユーザ端末8を操作して注文通知メールを受信する。そして、受取人は、注文通知メールの本文に記載されたURLを選択する。すると、ユーザ端末8は、選択されたURLを含む関連付けリクエストを宅配便サーバ3へ送信する。関連付けリクエストを受信した宅配便サーバ3は、認証ページをユーザ端末8へ送信する。認証ページは、ユーザID及びパスワードを入力するためのWebページである。これらの情報を受取人に入力させる理由は、受取人がサービス提供サイトの会員であるか否かを判定するため、及び、受取人を特定するためである。受取人がユーザID及びパスワードを入力すると、ユーザ端末8は、入力されたユーザID及びパスワードを含む認証リクエストを、宅配便サーバ3へ送信する。
宅配便サーバ3は、受信した認証リクエストに含まれるユーザIDに対応する会員情報を会員情報DB1aから検索し、検索した会員情報を、認証リクエストに含まれるパスワードが一致するか否かを判定する。これにより、システム制御部34は、ユーザ認証を行い、ユーザ認証が成功すると、関連付けリクエストに含まれる注文番号を含む配送管理情報を、配送管理情報DB32dから検索する。次いで、宅配便サーバ3は、検索した配送管理情報に、認証リクエストに含まれるユーザIDを設定する。これにより、注文商品と受取人とが関連付けられる。このとき、宅配便サーバ3は、受取人等が設定した受取可能日時のうち注文商品を配達可能な最先の日時を、注文商品の配達予定日として設定してもよい。関連付けを終えると、宅配便サーバ3は、配送状況ページをユーザ端末8へ送信する。配送状況ページには、今回受取人と関連付けられた注文商品の配送状況が表示される。
なお、宅配便サーバ3は、ユーザ端末8から、関連付けリクエストとともにユーザIDを含むクッキーを受信した場合、つまり、ユーザが既にログインしている場合には、ユーザ認証を行わずに、配送状況一覧ページを送信してもよい。
また、宅配便サーバ3は、注文商品と受取人との関連付けを行ったときに、注文者により入力された送付先情報の変更が可能なようにしてもよい。例えば、宅配便サーバ3は、ユーザ認証が成功した後、注文者により入力された送付先情報をユーザ端末8に送信する。ユーザ端末8は、受信した送付先情報を画面に表示する。ここで、受取人は、表示された送付先情報で問題ない場合には、この送付先情報で承諾する旨の操作を行う。この場合、送付先情報は変更されない。一方、受取人は、送付先情報を変更したい場合には、変更する旨の操作を行って、新しい送付先情報を入力する。すると、ユーザ端末8は、入力された送付先情報を宅配便サーバ3へ送信する。宅配便サーバ3は、注文商品の管理情報に含まれる送付先情報を、受信した送付先情報に変更する。また、宅配便サーバ3は、受取人の会員情報から送付先情報を取得して、注文商品の管理情報に含まれる送付先情報を、会員情報から取得した送付先情報に変更してもよい。
また、宅配便サーバ3は、ユーザが配達日時を指定して商品を注文したとき、注文済商品によっては、配達予定日の繰り上げのみを許可し、配達予定日の繰り下げは行わないようにしてもよい。例えば、生成食品等、消費期限が数日である食品は、配達予定日が繰り下げられると、消費期限が切れた後に配達されてしまう場合がある。これを防止するため、このような商品については、配達予定日の繰り下げを禁止される。
具体的に、各商品情報に、配達日時繰り下げ可能フラグが登録される。配達日時繰り下げ可能フラグは、配達予定日時の繰り下げが可能であるか否か示す。配達日時変更可能フラグは、配達日時繰り下げ可能フラグがONに設定されている場合、配達予定日時の繰り下げが可能であることを示し、配達日時繰り下げ可能フラグがOFFに設定されている場合、配達予定日時の繰り下げが不可能であることを示す。
システム制御部34は、図13に示す配送依頼情報受信時処理において、注文商品の配送管理情報を初期化するとき(ステップS51)、注文商品の商品情報に含まれる配達日時繰り下げ可能フラグを、注文商品の配送管理情報に設定する。その後、システム制御部34は、図17に示す配達予定日時変更処理において、選択した配送管理情報に設定された最短配達可能日時が今回指定された配達日時よりも遅くはないと判定された場合(ステップS155:NO)、または、今回指定された配達日時よりも遅い最短配達可能日時が設定されている配送管理情報がないと判定した場合には(ステップS163:NO)、選択した配送管理情報に設定されている配達予定日時が、今回指定された配達日時よりも早いか否かを判定する。このとき、システム制御部34は、配達予定日時が今回指定された配達日時よりも早くはないと判定した場合には、ステップS156へ移行する。つまり、システム制御部34は、注文済商品の配達予定日時を今回指定された配達日時に変更する。一方、システム制御部34は、配達予定日時が今回指定された配達日時よりも早いと判定した場合には、選択した配送管理情報に含まれる配達日時繰り下げ可能フラグがONに設定されているか否かを判定する。このとき、システム制御部34は、配達日時繰り下げ可能フラグがONに設定されていると判定した場合には、ステップS156へ移行する。つまり、システム制御部34は、注文済商品の配達予定日時を今回指定された配達日時に変更する。一方、システム制御部34は、配達日時繰り下げ可能フラグがOFFに設定されている場合には、ステップS137へ移行する。つまり、システム制御部34は、注文済商品の配達予定日時を変更しない。
また、配達予定日時の繰り下げを不可能とする商品の注文時に、支払い方法・配送方法選択ページにおいて、その商品の消費期限等よりも遅い配達日時を指定することができないようになっていてもよい。
また、ユーザが商品を注文するとき、注文商品の配達予定日時を繰り下げることを許可するか否かを、ユーザが選択することができるようにしてもよい。ユーザが配達予定日時の繰り下げを許可しなかった場合の処理内容は、上記の内容と基本的に同様である。
また、上記実施形態において、宅配便サーバ3は、ユーザが配達日時を指定して商品を注文した場合、配達予定日時を今回指定した配達日時に変更可能な注文済商品については、配達予定日時を必ず変更するようになっていた。しかしながら、宅配便サーバ3は、一括配達商品選択ページにおいてユーザにより選択された注文済商品についてのみ、配達予定日時を変更してもよい。この場合、宅配便サーバ3は、配達予定日時を今回指定した配達日時に変更可能な注文済商品のみが選択の候補として表示されるように配達商品選択ページを生成する。
また、上記実施形態において、宅配便サーバ3は、店舗が伝票番号を発行するための操作を行ったときに、伝票番号を発行していた。しかしながら、宅配便サーバ3は、商品の注文時に伝票番号を発行してもよい。具体的に、システム制御部34は、図13に示す配送依頼情報受信時処理において、注文商品の配送管理情報を初期化したときに(ステップS51)、新しい伝票番号を生成する。そして、システム制御部34は、生成した伝票番号を、注文商品の配送管理情報に設定する。宅配便サーバ3は、発送依頼情報を店舗端末7に送信するとき、生成した伝票番号を発送依頼情報に含める。
また、上記実施形態においては、ユーザに対する報酬として、ポイントが付与されていた。しかしながら、例えば、金銭、電子マネー、クーポン等が付与されるようにしてもよい。そして、本発明の報酬情報の一例として、ユーザに付与される金銭等の情報が記憶部32に記憶されるようになっていてもよい。
また、上記実施形態においては、商品の配達日時として、配達日と配達時間帯との両方を指定可能となっていた。しかしながら、配達日のみが指定可能となっていてもよい。
また、データベース管理サーバ1の代わりに、電子商店街サーバ2または宅配便サーバ3が、データベース管理サーバ1に相当する構成を備えていてもよい。また、例えば、宅配便サーバ3の代わりに、電子商店街サーバ2が、宅配便サーバ3に相当する構成を備えていてもよい。
また、電子商店街と電子商店街宅配便とを運営する主体が同一の主体ではなくてもよい。
また、本実施形態においては、複数の店舗からそれぞれ商品を注文可能な電子商店街において注文された商品の配達に本発明が適用されていた。しかしながら、例えば、単一の販売者から商品を注文するためのWebサイト等において注文された商品の配達に本発明が適用されてもよい。
請求項2に記載の発明は、請求項1に記載の情報処理装置において、前記配達情報記憶手段には、商品の配達に用いられる伝票ごとに前記配達情報が記憶され、前記日取得手段は、前記配達情報記憶手段に前記配達情報が記憶されている何れかの商品が、今回注文された前記第1商品と一括で配達される第3商品としてユーザにより指定された場合、前記第3商品と前記第1商品との何れも配達可能な最先の日を前記日記憶手段から取得し、前記第1配達情報記憶制御手段は、前記日取得手段により取得された日を配達日として含む前記第1商品の前記配達情報を前記配達情報記憶手段に記憶させ、前記第3商品の前記配達情報に含まれる配達日に、前記日取得手段により取得された日を設定することを特徴とする。
請求項4に記載の発明は、請求項1乃至3の何れか1項に記載の情報処理装置において、前記日記憶手段には、商品の受け取りが可能な日を設定したユーザを識別する識別情報に対応付けて該日が記憶されており、前記日取得手段は、前記第1商品を注文したユーザの前記識別情報に対応付けられた日と、該ユーザと住所が同じである他のユーザの前記識別情報に対応付けられた日とのうち、前記第1商品の配達が可能な最先の日を取得することを特徴とする。
請求項5に記載の発明は、請求項1乃至4の何れか1項に記載の情報処理装置において、前記配達情報記憶手段には、商品を注文したユーザの前記識別情報に対応付けて前記配達情報が記憶され、前記変更手段は、前記第2商品を注文したユーザの前記識別情報に対応付けられた前記第1商品の前記配達情報に含まれる配達日と、該ユーザと住所が同じである他のユーザの前記識別情報に対応付けられた前記配達情報に含まれる配達日と、を変更することを特徴とする。
請求項6に記載の発明は、請求項1乃至5の何れか1項に記載の情報処理装置において、前記日記憶手段には、商品の受け取りが可能な日を設定したユーザを識別する識別情報に対応付けて該日が記憶されており、前記第1商品を注文するユーザにより、前記第1商品を受け取る他のユーザを特定する特定情報が入力された場合、前記特定情報に基づいて、該他のユーザの前記識別情報を取得する識別情報取得手段を更に備え、前記日取得手段は、前記識別情報取得手段により取得された前記識別情報に対応付けられた日のうち、前記第1商品の配達が可能な最先の日を取得することを特徴とする。