JP6664533B1 - サーバ装置、プログラム、および情報処理方法 - Google Patents

Abstract

【課題】 送り手や受け手からの荷物の配送状況を確認しにいくアクションがなくても、受け手に届いていない荷物の配送状況を送り手や受け手が把握できるサーバ装置等を提供する。【解決手段】 サーバ装置は、荷物の送り手の第１情報処理装置から、当該荷物の受け手に発送された荷物を示す荷物情報を受け付ける受付部と、荷物情報に基づいて、荷物を配送する配送者の配送サーバから、荷物の配送状況を示す配送情報を取得する取得部と、配送情報に基づいて、第１情報処理装置および受け手の第２情報処理装置の少なくとも一つに荷物の配送状況を通知するか否かを判定し、当該判定の結果に基づいて第１情報処理装置および受け手の第２情報処理装置の少なくとも一つに配送状況を通知する通知部と、を備える。【選択図】図１

Description

本発明は、サーバ装置、プログラム、および情報処理方法に関する。

従来、ＥＣサイトを通じて商品を購入したユーザが、注文番号や配送番号等を用いて荷物を追跡できる技術が知られている。例えば、特許文献１には、ＥＣサイトを通じて商品を購入したユーザが、購入した商品に紐づけられた配送識別番号を用いてＥＣサイトのウェブページから商品の配送状況を確認できる技術が記載されている。

特開２００２−３１２６９３号公報

しかしながら、特許文献１の技術において、ＥＣサイトのユーザ等の荷物を受ける側（以下、「受け手」という）が荷物の配送状況を把握するためには、自ら配送状況を確認しにいく必要がある。受け手は長期不在や転居の場合等必ずしも配送状況に気を配れるとは限らず、荷物の配送状況の確認や再配達依頼を受け手が忘れるという問題があった。

また、ＥＣサイトや販売店舗の商品等の荷物を送る側（以下、「送り手」という）においても、自ら配送状況を確認しにいかないと、ＥＣサイトのユーザ等の荷物を受ける側（以下、「受け手」という）に荷物が届いていないという状況を把握することが困難であった。例えば、送り手は、荷物の配送の際、受け手が不在等のため配送業者に持ち戻られて荷物の保管期間後に荷物が送り手に返送されてはじめて、荷物が受け手に届いていないことを把握することがあった。このため、送り手は、荷物の保管期間を過ぎて荷物が送り手に返送されるまでの期間、荷物の配送状況を把握できないという問題があった。

そこで、本発明は、上記課題を解決するため、送り手や受け手が荷物の配送状況を確認しにいくアクションを行わなくても、受け手に届いていない荷物の配送状況を送り手や受け手が把握できるサーバ装置、プログラム、および情報処理方法を提供することを目的とする。

本発明の一態様に係るサーバ装置は、荷物の送り手の第１情報処理装置から、当該荷物の受け手に発送された荷物を示す荷物情報を受け付ける受付部と、荷物情報に基づいて、荷物を配送する配送者の配送サーバから、荷物の配送状況を示す配送情報を取得する取得部と、配送情報に基づいて、第１情報処理装置および受け手の第２情報処理装置の少なくとも一つに荷物の配送状況を通知するか否かを判定し、当該判定の結果に基づいて第１情報処理装置および第２情報処理装置の少なくとも一つに配送状況を通知する通知部と、を備える。

本発明の一態様に係るプログラムは、コンピュータに、荷物の送り手の第１情報処理装置から、当該荷物の受け手に発送された荷物を示す荷物情報を受け付ける受付機能と、荷物情報に基づいて、荷物を配送する配送者の配送サーバから、荷物の配送状況を示す配送情報を取得する取得機能と、配送情報に基づいて、第１情報処理装置および受け手の第２情報処理装置の少なくとも一つに荷物の配送状況を通知するか否かを判定し、当該判定の結果に基づいて第１情報処理装置および第２情報処理装置の少なくとも一つに配送状況を通知する通知機能と、を実現する。

本発明の一態様に係る情報処理方法は、コンピュータが、荷物の送り手の第１情報処理装置から、当該荷物の受け手に発送された荷物を示す荷物情報を受け付けるステップと、荷物情報に基づいて、荷物を配送する配送者の配送サーバから、荷物の配送状況を示す配送情報を取得するステップと、配送情報に基づいて、第１情報処理装置および受け手の第２情報処理装置の少なくとも一つに荷物の配送状況を通知するか否かを判定し、当該判定の結果に基づいて第１情報処理装置および第２情報処理装置の少なくとも一つに配送状況を通知するステップと、を含む。

上記の態様によれば、送り手が発送した荷物について、配送がまだ完了していない等の配送状況に基づいて、送り手や受け手に配送状況が通知される。そのため、送り手や受け手は、送り手のフォローが必要な荷物についてタイミングよく荷物の配送状況を把握することができる。

本発明によれば、送り手や受け手が荷物の配送状況を確認しにいくアクションを行わなくても、受け手に届いていない荷物の配送状況を送り手や受け手が把握できるサーバ装置、プログラム、および情報処理方法を提供することができる。

本発明の一実施形態に係る配送状況管理システムのシステム構成例を示す概略図である。 本発明の一実施形態に係るサーバ装置の機能構成例を示すブロック図である。 本発明の一実施形態に係る配送状況管理情報の例を示す表である。 本発明の一実施形態に係る通知設定情報の例を示す表である。 本発明の一実施形態に係る判定情報の例を示す表である。 本発明の一実施形態に係るサーバ装置の動作例を示すフローチャートである。 本発明の一実施形態に係るサーバ装置の動作例を示すフローチャートである。 本発明の一実施形態に係るサーバ装置の動作例を示すフローチャートである。 本発明の一実施形態に係るサーバ装置のハードウェア構成例を示すブロック図である。

添付図面を参照して、本発明の好適な実施形態（以下、「本実施形態」という）について説明する。なお、各図において、同一の符号を付したものは、同一又は同様の構成を有する。

＜１．システム構成＞
図１を参照して、本実施形態に係る配送状況管理システム１のシステム構成の例を説明する。本実施形態では、いわゆるモール型のＥＣサイト（以下、「ＥＣサイトＡ」という）でユーザＵが商品を注文し、当該注文を受けた店舗がユーザＵに当該商品を荷物として配送する例を説明する。また、本例では、ＥＣサイトＡを運営するＥＣ事業者および上記商品を販売する店舗を荷物として当該商品を送る側（以下、「送り手」ともいう）とし、ユーザＵを荷物として当該商品を受ける側（以下、「受け手」ともいう）とする。また、荷物の送り手が使用する情報処理装置を第１情報処理装置、荷物の受け手が使用する情報処理装置を第２情報処理装置という。

本実施形態では、上記の例を用いて本発明を説明するが、本発明を上記の例に限る主旨ではない。本発明は、諸々の荷物の配送に適用することができる。例えば、本発明は、上記の例のＢｔｏＣビジネス以外にも、ＣｔｏＢビジネス、ＢｔｏＢビジネス、ＣｔｏＣビジネス、自社内の配送または個人間の荷物の配送等にも適用することができる。本発明は、例えば、本社から工場への部品の配送状況を管理する際にも適用することができる。

配送状況管理システム１は、荷物の配送状況を管理するためのシステムである。図１に示すように、配送状況管理システム１は、荷物の配送状況を管理するサーバ装置２と、第１情報処理装置でありＥＣサイトＡを提供するＥＣサーバ４と、同様に第１情報処理装置でありＥＣサイトＡを通じて商品を販売する店舗の店舗サーバ５と、荷物を配送する配送者（例えば、配送業者等）の配送サーバ６と、第２情報処理装置でありユーザＵが使用するユーザ端末３と、を含む。配送状況管理システム１では、サーバ装置２が、ネットワークＮを介して、ユーザ端末３と、ＥＣサーバ４と、店舗サーバ５と、配送サーバ６とに接続されている。なお、配送状況管理システム１は、ユーザ端末３、ＥＣサーバ４、店舗サーバ５、および配送サーバ６を全て含まなくてもよく、例えば、サーバ装置２のみを含みその他を外部のシステムとしてもよい。以下、ＥＣサーバ４および／または店舗サーバ５を、「ＥＣサーバ４等」という。

配送状況管理システム１は、例えば、後述の宅配場所情報を管理する宅配場所管理サーバを含んでもよい。宅配場所管理サーバは、例えば、受け手の配達先である宅配ボックスを管理する会社のサーバ等であってもよい。また、サーバ装置２は、ネットワークＮを介して、宅配場所管理サーバと接続されてもよい。

本例では、第１情報処理装置をＥＣサーバ４および店舗サーバ５とする例を説明しているがいずれか一つでもよく、例えば、ＥＣサイトがいわゆる自社ＥＣサイトで店舗サーバがＥＣサーバの機能を備える場合には、第１情報処理装置は店舗サーバのみでもよい。また、本例では、ＥＣサーバ４とサーバ装置２とを別の装置として説明するが、サーバ装置２がＥＣサーバとしての機能を備えてもよい。その場合、ＥＣサーバ４（第１情報処理装置）とサーバ装置２は、同一の装置であってもよい。

ネットワークＮは、無線ネットワークや有線ネットワークにより構成される。ネットワークの一例としては、携帯電話網や、ＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙ−ｐｈｏｎｅ Ｓｙｓｔｅｍ）網、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、３Ｇ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ）、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、４Ｇ（４ｔｈ Ｇｅｎｅｒａｔｉｏｎ）、ＷｉＭａｘ（登録商標）、赤外線通信、Ｂｌｕｅｔｏｏｔｈ（登録商標）、有線ＬＡＮ、電話線、電灯線ネットワーク、ＩＥＥＥ１３９４、５Ｇ（５ｔｈ Ｇｅｎｅｒａｔｉｏｎ）等に準拠したネットワークがある。

サーバ装置２は、荷物の配送状況を管理するための情報処理装置であり、ユーザ端末３、ＥＣサーバ４等、または配送サーバ６との通信や配送状況の管理可能な情報処理装置である。サーバ装置２は、所定のプログラムを実行することにより、ＥＣサーバ４等と連携して荷物の配送に関する情報（例えば、後述の荷物情報や配送情報等）を取得する。サーバ装置２は、これらの取得した情報を参照して荷物の配送状況、または配送状況の通知先、通知タイミングもしくは通知方法等を判定する。サーバ装置２は、当該判定の結果に基づいて、ＥＣサーバ４等に当該配送状況等をタイミングよく通知する機能を実現する。

ユーザ端末３は、ユーザＵからの荷物の配送状況の問い合わせ等の入力や当該問い合わせの応答として配送状況の出力が可能なスマートフォンやラップトップ端末等の端末装置である。ユーザ端末３は、例えば、ネットワークＮに接続したスマートスピーカ―やスマートテレビ等のいわゆるスマート家電であってもよい。ユーザ端末３は、所定のプログラムを実行することにより、サーバ装置２と連携して荷物に関する情報を送受信したり荷物の配送状況を把握するための画面を表示したりする。

ＥＣサイトＡは、店舗が出品した商品を販売する形式、ＥＣサイトＡに仮想店舗を出店する形式のいずれであってもよい。

本実施形態に係る配送状況管理システム１の概要について、次の（１）〜（６）で説明する。

（１）ユーザＵはユーザ端末３を用いてＥＣサイトＡで商品を注文する。（２）ＥＣサイトＡが当該注文を受注すると、ＥＣサーバ４が店舗サーバ５に連携し、当該注文された商品が荷物として店舗からユーザＵに配送業者に依頼して発送される。（３）荷物が発送されたことをトリガーとして、ＥＣサーバ４（または店舗サーバ５）が、サーバ装置２に、当該荷物を示す荷物情報を送信する。

（４）サーバ装置２が荷物情報を受信して受け付けると、サーバ装置２は当該荷物の配送状況の管理を開始する。（５）サーバ装置２は、当該荷物情報に示された荷物の配送状況を上記配送者の配送サーバ６から取得する。具体的には、サーバ装置２は、配送サーバ６に該当の荷物の配送状況を示す配送情報の取得要求を送信し、当該取得要求の応答として配送サーバ６から配送情報を受信する。（６）サーバ装置２は、当該受信した配送情報に基づいて、ユーザＵやＥＣ事業者または店舗のフォローが必要と判定した場合には、ＥＣサーバ４等またはユーザ端末３に荷物の配送状況を通知する。具体的には、荷物が保管期間終了間近になってもユーザＵに届いていない等の配送が滞っている状況をサーバ装置２が判定した場合、サーバ装置２はユーザ端末３に当該配送状況を通知する。このような通知をすることで、サーバ装置２は、ユーザＵに荷物の再配達依頼等をさせるためのフォローを行う。

上記構成によれば、ＥＣ事業者や店舗が発送した荷物について、配送情報に基づいて配送がまだ完了していない等の状況が送り手のＥＣ事業者や店舗に通知される。このため、上記構成によれば、自らのフォローが必要な荷物について、送り手のＥＣ事業者や店舗はタイミングよく荷物の配送状況を把握することができる。

受け手においても、上記構成によれば、ユーザＵは、自らのフォローが必要な荷物についてタイミングよく荷物の配送状況を把握することができる。ひいては、長期不在や転居の場合等において必ずしもユーザＵが配送状況に気を配れなかったりユーザＵが雑事に紛れて注文した商品を忘れていたりしても、上記構成によれば、ユーザＵが荷物の配送状況の確認や再配達依頼を忘れるといった事態を解消することもできる。

＜２．機能構成＞
図２を参照して、本実施形態に係るサーバ装置２の機能構成の例を説明する。図２に示すように、サーバ装置２は、制御部２１と、記憶部３０と、通信部２２とを備える。

サーバ装置２は、サーバ装置２全体を制御する制御部２１と、他の装置との通信を行う通信部２２と、荷物の荷物情報等を記憶する記憶部３０と、を備える。

制御部２１は、受付部２３と、取得部２４と、通知部２６とを備える。また、制御部２１は、例えば、判定部２５を備えてもよい。

受付部２３は、荷物の送り手の第１情報処理装置から、当該荷物の受け手に発送された荷物を示す荷物情報を受け付ける。受付部２３は、例えば、通信部２２を介してＥＣサーバ４等から荷物情報を受信し、当該荷物情報に示された荷物について後述の記憶部３０に記憶されている配送状況管理情報２７に新規登録してもよい。サーバ装置２は、受付部２３が荷物情報を受け付けたことをトリガーに、当該荷物情報に示された荷物の配送状況の管理を開始してもよい。

「荷物情報」とは、荷物の送り手から当該荷物の受け手に発送された荷物を示す情報である。荷物情報は、例えば、サーバ６が荷物ごとに付与し各荷物を識別するための「荷物番号」と、荷物に紐づく商品の受注を識別するための「受注番号」と、荷物に紐づく商品の販売元を識別するための「販売元」と、を含んでもよい。また、荷物情報は、後述の「配送者」を含んでもよい。

「配送状況管理情報」とは、各荷物の配送状況を管理するための情報である。配送状況管理情報は、荷物情報、または荷物情報および配送情報によって構成される。

「配送情報」とは、荷物ごとの配送状況を示す情報である。配送情報は、例えば、「荷物番号」と、各配送者を識別するための「配送者」と、各荷物の配送状況を示す「ステータス」と、含んでもよい。また、配送情報は、荷物の送り主を識別するための「送り主」と、荷物の受け手の配達先（例えば、受け手の自宅または荷物の転送先等）を示す「配達先」と、ワレモノやナマモノ等の荷物の中身を示す「品名」と、送り手が設定した荷物の配達希望日時（配達希望日時の有無を含む）を示す「配達希望日時」と、を含んでもよい。なお、本実施形態では、送り主と配達先は同じ商品を購入したユーザＵであるが、送り主と配達先は異なってもよい。

図３を参照して、配送状況管理情報の一例について説明する。図３に示すように、配送状況管理情報２７は、カラム「登録日／販売元／受注番号／荷物番号／配送者／ステータス／監視フラグ」を含む。図３では、説明のため、便宜的にカラム「レコード番号」を付与している。それぞれ、「登録日」は受付部２３が配送状況管理情報２７に新しいレコードを登録した日、「販売元」はユーザＵに配送される商品の販売元であり荷物の送り手のＥＣサーバ４または店舗サーバ５を識別するための情報、「受注番号」はユーザＵの注文ごとにＥＣサーバ４が付与した番号、「荷物番号」、「配送者」は荷物を配送する配送者の配送サーバ６を識別するための情報、「ステータス」は荷物の配送状況、「監視フラグ」は各荷物が配送状況を監視される対象であるか否かを示す情報である。

配送状況管理情報２７への新規レコードの追加は、受付部２３が実施してもよい。例えば、ユーザ端末３からＥＣサーバ４の「ＥＣサイトＡ」に注文が入り荷物が発送されると、ＥＣサーバ４等からサーバ装置２に当該荷物の荷物情報が送信される。サーバ装置２が当該荷物情報を受信すると、受付部２３は、配送状況管理情報２７に当該荷物情報をもって新規レコードを追加登録する。具体的には、レコード番号「１０」の荷物においては、販売元「ＥＣサイトＡ」、受注番号「Ａ００３」、配送者「Ｋ運送」、荷物番号「Ｋ０００２」が登録される。なお、配送状況管理情報２７に新規レコードが追加される際のデフォルト値として、ステータスには「発送済」と、監視フラグには「対象」といった値が予め設定されてもよい。

受付部２３は、上記のように受け付けた荷物情報を、荷物の配送履歴情報として記憶部３０に第４所定期間蓄積させてもよい。ここで「配送履歴情報」とは、第４所定期間における荷物の配送履歴を示す情報である。配送履歴情報は、例えば、荷物情報に含まれる荷物番号等の項目を少なくとも一つ含んでもよい。また、ここで「第４所定期間」とは、荷物の配送履歴を保管するための期間である。第４所定期間は、例えば、荷物情報の記憶部３０への登録から１年、５年、１０年等適宜設定可能である。

受付部２３は、ＥＣサーバ４等およびユーザ端末３の少なくとも一つから、アクション情報を受け付けてもよい。「アクション情報」とは、所定のアクションを示す情報であり、「所定のアクション」とは、送り手または受け手の荷物の配送に関するアクションである。所定のアクションは、例えば、送り手または受け手が荷物の配送を促すためのアクションであってもよい。所定のアクションは、例えば、受け手が不在のため荷物が配送者に保管されている場合における受け手からの再配達依頼であってもよい。

受付部２３は、受け手の配達先に係る宅配場所情報を管理する宅配場所管理サーバから、宅配場所情報を受け付けてもよい。ここで「宅配場所情報」とは、ポストや宅配ボックス等の宅配場所ごとのサイズおよび使用状況の少なくともいずれか一つを示す情報である。宅配場所情報は、例えば、宅配場所を管理する管理者を識別するための「管理者ＩＤ」と、受け手を識別するための「受け手ＩＤ」、配達先の住所を識別するための「配達先住所」、宅配場所の荷物を収容できるサイズ（宅配ボックスの規格を含む）を示す「サイズ」と、空きがあるか否か等の宅配ボックスの使用状況を示す「使用状況」とを含んでもよい。

取得部２４は、荷物情報に基づいて、当該荷物情報が示す荷物を配送する配送者の配送サーバ６から、当該荷物の配送情報を取得する。取得部２４は、例えば、通信部２２を介して、荷物情報または配送状況管理情報に示された荷物の配送状況の問い合わせ要求を配送サーバ６に送信してもよい。そして、取得部２４は、その応答として当該荷物の配送情報を受信してもよい。そして、取得部２４は、当該受信した配送情報に基づいて、該当する荷物の配送状況（配送状況管理情報の「ステータス」）を更新してもよい。

取得部２４は、配送情報に基づいて荷物の配送状況を監視し、当該監視の結果に基づいて当該荷物の配送情報を取得する対象か否か判定してもよい。取得部２４は、例えば、配送情報に基づいて荷物の配送状況を監視する。そして、取得部２４は、当該監視の結果に基づいて荷物の配送が完了しているか否か判定する。取得部２４は、荷物の配送が完了している場合には監視の対象外と判定し、荷物の配送が完了していない場合には監視の対象と判定してもよい。取得部２４は、このように監視の対象と判定した荷物について、当該荷物の配送情報をさらに配送サーバ６から取得してもよい。ここでいう「荷物の配送が完了」とは、受け手に荷物が届いて配達完了となった場合の他に、配送者における荷物の保管期間が過ぎて店舗やＥＣ事業者に返送（返品）されて返送完了（返品完了）となった場合も含めてもよい。

取得部２４は、例えば、配送情報に基づいて、配送状況管理情報２７のステータスを更新してもよい。取得部２４は、例えば、所定の周期または所定の時刻に、配送状況管理情報２７を走査し、監視フラグが「対象」のレコードについて、各レコードに保存された配送者の配送サーバ６から配送情報を取得する。取得部２４は、例えば、まず、レコード番号「１」のレコードを参照し、監視フラグが「非対象」であるため、配送情報を取得せずに次のレコード番号「２」のレコードを参照する。レコード番号「２」のレコードは、監視フラグ「対象」であるため、取得部２４は、配送者「Ｆ運送」のサーバから、荷物番号「Ｆ０００１」を用いてレコード番号「２」の荷物の配送情報を取得する。そして、当該荷物の配送状況が「不在」であれば、取得部２４は、ステータスを「不在」と更新する。

取得部２４は、例えば、荷物の配送が完了している場合、すなわち配送状況管理情報２７のステータスが「配達完了」あるいは「返品完了」となった場合には、併せて、監視フラグを「非対象」と更新してもよい。このように更新することで、監視フラグが「非対象」となった荷物については、取得部２４は、以後の配送情報の取得や後述の通知アクションを実施しないようにしてもよい。取得部２４は、配送状況管理情報２７に含まれる全てのレコードについて、同様の処理を実施してもよい。なお、取得部２４における上記の処理は、所定の周期でサイクリックに実行されてもよいし、所定の時刻やＥＣサーバ４等やユーザ端末３から荷物の配送状況の確認要求があった際にイベントドリブンで実行されてもよい。また、取得部２４において、サイクリックに実行する場合の周期は、１時間、半日、１日、１週間等、適宜設定可能である。

取得部２４は、上記のように取得した配送情報を、荷物情報と紐づけて、荷物の配送履歴として記憶部３０に第４所定期間蓄積させてもよい。配送履歴情報には、荷物情報に含まれる項目に加え、配送情報に含まれる項目の少なくとも一つを含んでもよい。

判定部２５は、配送情報および配送履歴情報に基づいて、荷物が配送者の保管場所に持ち戻られるまたは送り手に返送される可能性の度合い（以下、「戻り度」という）を判定する。判定部２５は、例えば、配送情報および配送履歴情報に基づいて対象の荷物が所定の判定基準を満たすか否かを判定し、当該判定の結果に基づいて戻り度を判定してもよい。
ここで「所定の判定基準」とは、戻り度を判定するための基準である。またここで、判定部２５における所定の判定基準による判定の一例について、図５を用いて説明する。図５は、所定の判定基準を示す判定情報の一例を示す表である。

図５に示すように、判定情報は、所定の判定基準を示す「判定基準」と、「戻り度」と、を含む。判定情報は、戻り先の分類（例えば、不在票対応となり配送者の保管場所（本例では「Ａ」と示す）またはＥＣ事業者や店舗などの送り手（本例では「Ｂ」と示す））を示す「戻り先分類」と、戻り度に基づいて送り手または受け手に配送状況等を通知する際のメッセージを示す「通知メッセージ」とを含んでもよい。判定部２５は、配送情報および配送履歴情報に基づいて、対象の荷物を「過去に宛先不明（引っ越し）となった受け手への荷物」と判定した場合、配送情報のＮｏ．４の判定基準を満たすため、分類「Ａ」および戻り度「３０（％）」と判定する。判定部２５は、複数の判定基準を満たす場合は、戻り先分類ごとに合計して戻り度を算出してもよいし、戻り先分類関係なく合計して戻り度を算出してもよい。また、判定部２５は、図５に示すように判定基準ごとの戻り度を設定せず、戻り先分類ごとに一律同じ戻り度を設定してもよい。

判定部２５は、宅配場所情報に基づいて、戻り度を判定してもよい。判定部２５は、例えば、配送情報および宅配場所情報に基づいて、配送状況が「不在」で宅配場所情報に「（受け手の配達先の宅配ボックスの）空きなし」と示されていた場合は、戻り先分類「Ａ（配送者の保管場所）」および／または戻り度「７０（％）」と判定してもよい。上記構成によれば、判定部２５は、宅配場所のサイズや状況に応じた戻り度を判定することができる。このため、ＥＣ事業者やユーザＵは、より精度よく事前に持ち戻られる可能性がある荷物を把握することができる。

判定部２５は、配送情報および配送履歴情報に基づいて、受け手および第５所定期間ごとの受け取り確率を判定してもよい。ここで「受け取り確率」とは、受け手が第５所定期間ごとに配送された荷物を受け取る確率を示す情報である。ここで「第５所定期間」とは、受け取り確率を設定するための期間である。第５所定期間は、例えば、発送日からの一定期間を１時間刻みで区切った期間であってもよく、判定部２５は、発送日から２日間における１時間ごとの受け取り確率を判定してもよい。判定部２５は、例えば、配送履歴情報に基づいて、一定期間における受け手ごとの荷物を受け取った確率を算出し、受け取り確率を判定してもよい。判定部２５は、例えば、当該一定期間の時間帯（例えば、午前、午後、または正午等）ごとに受け取り確率を算出し、当該時間帯を第５所定期間として当該時間帯ごとの受け取り確率を判定してもよい。

通知部２６は、配送情報に基づいて、ＥＣサーバ４等およびユーザ端末３の少なくとも一つに荷物の配送状況を通知するか否かを判定し、当該判定の結果に基づいてＥＣサーバ等およびユーザ端末３の少なくとも一つに配送状況を通知する。また、通知部２６は、配送情報に基づいて、荷物の配送状況を通知するか否かに加えて、通知先、通知タイミングおよび通知方法等の当該通知に関するアクション（以下、単に「通知アクション」ともいう）を判定してもよい。通知部２６におけるＥＣサーバ４等やユーザ端末３への通知の態様は、どのような態様でもよく、例えば、通知部２６がＥＣサーバ４等へ通知メッセージを送信したり、通知部２６がＥＣ事業者等や店舗が指定するアドレスにメールを送信したり、通知部２６が所定のＷｅｂサイト上に通知内容を出力（例えば、通知先ごとに荷物の配送状況を一覧で出力）したりしてもよい。

上記構成によれば、送り手であるＥＣ事業者や受け手であるユーザＵのフォローが必要な荷物について、通知部２６は、ＥＣサーバ４等やユーザ端末３に、タイミングよく荷物の配送状況を通知することができる。したがって、上記構成によれば、ＥＣサーバ４等やユーザＵは、自らのフォローが必要な荷物について、タイミングよく当該荷物の配送状況を把握することができる。また、上記構成によれば、ＥＣサーバ４等やユーザＵに自らのフォローが必要な荷物についてのみ通知されるため、ＥＣサーバ４等やユーザＵは効率よく荷物の配送状況を把握することができる。

通知部２６は、配送情報に加えて第１所定期間に基づいて、ＥＣサーバ４等に荷物の配送状況を通知するか否かを判定し、当該判定の結果に基づいてＥＣサーバ４等に配送状況を通知してもよい。「第１所定期間」とは、荷物の配送が一定期間滞留していることを示す期間である。第１所定期間は、言い換えれば、ＥＣサーバ４等やユーザ端末３に荷物の配送状況の通知が必要と通知部２６が判定するための閾値である。第１所定期間は、例えば、配送者における荷物の保管期間、荷物が発送されてからの経過時間、または配送状況管理情報２７の登録日からの経過時間等であってもよい。

通知部２６は、例えば、ＥＣサーバ等やユーザ端末３に配送状況を通知するか否かを判定にあたって、配送情報に加えて通知設定情報２８に基づいてもよい。ここで「通知設定情報」とは、荷物の配送状況（ステータス）ごとに、通知アクションの内容が設定された情報である。ここで、配送状況管理情報の一例について、図４を用いて説明する。

図４に示すように、通知設定情報２８は、カラム「ステータス／通知アクション１／通知アクション２／通知アクション３／・・・／通知アクションｎ」を含む。それぞれ、「ステータス」は荷物の配送状況、「通知アクション１」〜「通知アクションｎ」は、ステータスに応じて実施される通知アクションの内容についての情報である。通知アクションは、配送状況管理情報２７の登録日からの経過時間に応じて添え字１〜ｎの順に選択されてもよい。また、別の一例として、通知アクションは、荷物が発送されてからの経過時間に応じて添え字１〜ｎの順に選択されてもよい。

通知部２６は、例えば、所定の周期または所定の時刻に、配送状況管理情報２７を走査し、監視フラグが「対象」の荷物について、ステータスを検索キーに用いて、通知設定情報２８を検索する。通知部２６は、具体的には、先ずレコード番号「１」のレコードを参照する。通知部２６は、当該レコードの監視フラグが「非対象」であるため、通知設定情報２８の検索をせずに次のレコード番号「２」のレコードを参照する。レコード番号「２」のレコードは監視フラグ「対象」であるため、通知部２６は、ステータス「不在」を検索キーに用いて、通知設定情報２８を検索する。

通知部２６は、次に、配送状況管理情報２７の登録日からの経過時間（本例では、経過日数）を算出する。そして、経過日数に応じて通知アクションの添え字を選択する場合、例えば、登録日から３日経過していた場合には、通知部２６は、ステータス「不在」のカラム「アクション３」を参照する。通知部２６は、当該参照の結果、「店舗にメール」とする通知アクションの内容を取得する。そして、「ＥＣサイトＢ、受注番号：Ａ００１、店舗にメール」という情報をセットで保存する。通知部２６は、配送状況管理情報２７に含まれる全てのレコードについて、同様の処理を実施してもよい。

通知部２６は、上記の例のように配送状況および第１所定期間とする判定条件に基づいて通知アクションを判定する以外にも、例えば、荷物の品名、または配達希望日時といった判定条件の少なくとも一つに基づいて判定してもよい。通知部２６におけるこれらの判定条件は、いずれか一つの条件を用いてもよいし、複数の条件の組み合わせを用いてもよい。

通知部２６において、上記の例では、ステータスが「不在」および登録日からの経過日数が３日の場合には「店舗にメール」とする通知アクションを判定する例を示している。しかしながら、荷物の品名が「ナマモノ」の場合には、通知部２６において、店舗にメールして通知するよりは直接荷物の受け手（配達先）に通知して荷物を受け取らせた方がいい場合がある。このため、通知部２６は、配送情報および第１所定期間に加えて荷物情報の品名を参照し、荷物の品名が「ナマモノ」であった場合には、「配達先のアドレスにメール」といったように異なる通知アクションを判定してもよい。

通知部２６は、ＥＣサーバ４、店舗サーバ５またはユーザ端末３ごとに、第２所定期間における荷物の配送状況を一括して通知してもよい。「第２所定期間」とは、通知先ごとに一括対象の通知を蓄積する期間である。第２所定期間は、例えば、１時間、３時間、半日、または１日等といった期間を適宜設定すればよい。

通知部２６は、例えば、上記の例のようなセットで保存された「ＥＣサイトＢ、受注番号：Ａ００１、店舗にメール」情報等を第２所定期間蓄積して、該当する店舗ごとに第２所定期間における荷物の配送状況を通知するレポートを生成してもよい。通知部２６は、各店舗に当該レポートを送信することで配送状況を一括通知してもよい。

上記構成によれば、また、通知部２６は、通知先ごとに第２所定期間分の通知を一括してすることができる。このため、上記構成によれば、ＥＣサーバ４等が大量の通知メッセージを受信する処理負荷を低減し、また、送り手や受け手が当該通知を確認する手間を省くことができる。また、上記構成によれば、通知部２６は、ユーザ端末３ごとに、異なるＥＣサイトや店舗から送られた荷物の配送状況を一括して通知することができる。このため、ユーザは、これらの配送状況をまとめて把握することができる。また、上記構成によれば、通知部２６は、店舗サーバ５ごとに、異なるＥＣサイトから注文された荷物の配送状況を一括して通知することができる。このため、店舗は、これらの配送状況をまとめて把握することができる。

通知部２６は、戻り度に基づいて、ＥＣサーバ４等およびユーザ端末３の少なくとも一つに荷物の配送状況と当該荷物の戻り度とを通知するか否かを判定し、当該判定の結果に基づいてＥＣサーバ４等およびユーザ端末３の少なくとも一つに荷物の配送状況と当該荷物の戻り度とを通知してもよい。

通知部２６は、例えば、所定の閾値（本例では、「２５（％）」とする）を予め設定し、配送状況が「発送済」の荷物について判定部２５における上記の例のように戻り度「３０（％）」の荷物の場合、所定の閾値を超過するため、ＥＣサーバ４等およびユーザ端末３の少なくとも一つに荷物の配送状況と当該荷物の戻り度を通知してもよい。また、通知部２６は、判定情報における該当する判定基準に紐づく通知メッセージを当該通知の際に通知してもよい。

上記構成によれば、通知部２６は、荷物が配送者の保管場所に持ち戻られるまたは送り手に戻される可能性の度合いに基づいて、事前にＥＣサーバ４等やユーザ端末３に通知することができる。このため、ＥＣ事業者やユーザＵ等は、事前に持ち戻られる可能性がある荷物を把握することができる。また、従来送り手に荷物が戻されてしまうことで受け手にも配送の費用の負担を強いる等の不利益が発生することがあったが、上記構成によれば、このような受け手の不利益が発生することも低減することができる。また、上記構成によれば、配送者においても、例えば、受け手が不在のため配達できない荷物を何度も配達先に届けに行くというような無駄な工数を低減することができる。

通知部２６は、アクション情報を参照して、第３所定期間において所定のアクションがない場合に、ＥＣサーバ４等およびユーザ端末３の少なくとも一つに荷物の配送状況を通知してもよい。ここで「第３所定期間」とは、荷物の配送が一定期間滞留し、かつ送り手や受け手が荷物の配送を促すための所定のアクションを行っていないことを示す期間である。第３所定期間は、言い換えれば、ＥＣサーバ４等やユーザ端末３に荷物の配送状況の通知が必要とサーバ装置２が判定するための第１所定期間とは異なる閾値である。通知部２６は、例えば、アクション情報を参照して、第３所定期間において受け手が再配達依頼を行っていないと判定した場合、ユーザ端末３に再配達依頼をさせるために荷物の配送状況を通知してもよい。

上記構成によれば、通知部２６は、送り手や受け手が荷物の配送を促すためのアクションを既に行っているがタイムラグにより配送状況が更新されていない期間において、送り手や受け手に配送状況の通知することを抑止することができる。よって、上記構成によれば、通知部２６は、冗長で煩わしい通知を抑止することができる。

通知部２６は、例えば、配送情報に基づいて、配達希望日時が無い荷物について、受け取り確率を配送サーバ６に通知してもよい。また、通知部２６は、戻り度が所定の閾値を超過している場合に、このような通知をしてもよい。このような構成によれば、通知部２６は、受け手が受け取りそうな配達タイミングを配送者にファクトベースで提案することができる。なお、通知部２６は、配達希望日時が無い荷物について、このような受け取り確率の通知ではなく、ユーザＵに配達希望日時を問い合わせるユーザ端末３に通知をしてもよい。

通信部２２は、ネットワークＮを介して、ＥＣサーバ４、店舗サーバ５またはユーザ端末３等に各種情報を送受信する。通信部２２は、例えば、ネットワークＮを介して、ＥＣサーバ４から荷物情報を受信したり、荷物の配送状況を通知するための通知メッセージをユーザ端末３に送信したりする。

記憶部３０は、荷物情報と、配送情報と、配送状況管理情報２７と、通知設定情報２８と、配送履歴情報と、宅配場所情報を記憶してもよい。記憶部３０は、データベースマネジメントシステム（ＤＢＭＳ）を利用して各情報を記憶してもよいし、ファイルシステムを利用して各情報を記憶してもよい。ＤＢＭＳを利用する場合は、図３、４に示すように、上記情報ごとにテーブルを設けて、当該テーブル間を関連付けて各情報を管理してもよい。

＜３．動作＞
図６〜８を参照して、本実施形態に係る配送状況管理システム１またはサーバ装置２の動作例を説明する。まず、配送状況管理システム１の動作の概要として、（１）ユーザＵがＥＣサイトＡを通じて商品を注文すると、ＥＣサイトＡのＥＣサーバ４がサーバ装置２に荷物情報を連携し、サーバ装置２が発送された荷物を配送状況管理情報２７に登録する。そして、配送状況管理システム１では、サーバ装置２が、登録された配送状況管理情報２７を用いて、所定の周期または所定の時刻に、配送情報の取得や通知処理を実行する。

図６は、本実施形態に係るサーバ装置２において、発送された荷物を受け付け、当該荷物の発送状況をＥＣサーバ４等の送り手や受け手に通知する処理の流れを示すフロー図である。なお、以下に示す処理の順番は一例であって、適宜、変更されてもよい。

図６に示すように、受付部２３は、荷物の送り手のＥＣサーバ４等から、当該荷物の受け手に発送された荷物を示す荷物情報を受け付ける（Ｓ１１）。受付部２３が荷物情報を受け付けると、取得部２４は、荷物情報に基づいて、当該荷物を配送する配送者の配送サーバ６から、当該荷物の配送状況を示す配送情報を取得する（Ｓ１２）。

取得部２４が配送情報を取得すると、通知部２６は、配送情報に基づいて、ＥＣサーバ４等およびユーザ端末３の少なくともいずれか一つに上記荷物の配送状況を通知するか否かを判定し、当該判定の結果に基づいてＥＣサーバ４等およびユーザ端末３に当該配送状況を通知する（Ｓ１４）。

図７は、本実施形態に係るサーバ装置２において、配送状況管理情報２７の監視フラグを用いて配送状況を監視し、荷物の配送状況を取得し通知する処理の流れを示すフロー図である。図７に示すように、取得部２４は、配送状況管理情報２７を参照し、レコードを読み出す（Ｓ２１）。取得部２４は、読み出したレコードの監視フラグが「非対象」である場合は（Ｓ２２：Ｎｏ）、次のレコードを読み出す（Ｓ２１）。一方、監視フラグが「対象」である場合は（Ｓ２２：Ｙｅｓ）、取得部２４は、荷物番号を用いて、配送サーバ６から配送状況を示す配送情報を取得する（Ｓ２３）。そして、取得部２４は、取得した配送情報に基づいて配送状況管理情報２７のステータスを更新する（Ｓ２４）。また、取得部２４は、当該ステータスに応じて監視フラグを更新する（Ｓ２５）。その後、取得部２４は、配送状況管理情報２７から次のレコードを読み出す（Ｓ２１）。このように、取得部２４は、配送状況管理情報２７に含まれる全てのレコードに対して、同様の処理を実行してもよい。

図８は、本実施形態に係るサーバ装置２において、通知先ごとに一括して配送状況を通知する処理の流れを示すフロー図である。図８に示すように、通知部２６は、まず、配送状況管理情報２７を参照し、レコードを読み出す（Ｓ３１）。通知部２６は、読み出したレコードの監視フラグが「非対象」である場合は（Ｓ３２：Ｎｏ）、次のレコードを読み出す（Ｓ１）。一方、監視フラグが「対象」である場合は（Ｓ３２：Ｙｅｓ）、通知部２６は、配送状況を検索キーに用いて、通知設定情報２８を検索し、第２所定期間に基づいてアクションを読み出し、通知先ごとに一括して保存する（Ｓ３４）。このとき、通知部２６は、配送状況管理情報２７の最終レコードでない場合は（Ｓ３５：Ｎｏ）、再び配送状況管理情報２７を参照し、次のレコードを読み出す。一方、配送状況管理情報２７の最終レコードである場合は（Ｓ５：Ｙｅｓ）、通知部２６は、通知先毎に一括して、通知アクションに登録された通知内容を実行する（Ｓ６）。

＜４．ハードウェア構成＞
図９を参照して、上述してきたサーバ装置２をコンピュータ８００により実現する場合のハードウェア構成の一例を説明する。なお、それぞれの装置の機能は、複数台の装置に分けて実現することもできる。

図９に示すように、コンピュータ８００は、プロセッサ８０１と、メモリ８０３と、記憶装置８０５と、入力Ｉ／Ｆ部８０７と、データＩ／Ｆ部８０９と、通信Ｉ／Ｆ部８１１とを含む。

プロセッサ８０１は、メモリ８０３に記憶されているプログラムを実行することによりコンピュータ８００における様々な処理を制御する。例えば、サーバ装置２の制御部２１が備える各機能部等は、メモリ８０３に一時記憶された上で、主にプロセッサ８０１上で動作するプログラムとして実現可能である。

メモリ８０３は、例えばＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の記憶媒体である。メモリ８０３は、プロセッサ８０１によって実行されるプログラムのプログラムコードや、プログラムの実行時に必要となるデータを一時的に記憶する。

記憶装置８０５は、例えばハードディスクドライブ（ＨＤＤ）やフラッシュメモリ等の不揮発性の記憶媒体である。記憶装置８０５は、オペレーティングシステムや、上記各構成を実現するための各種プログラムを記憶する。この他、記憶装置８０５は、荷物情報、配送情報、配送状況管理情報または通知設定情報を登録するテーブルと、当該テーブルを管理するＤＢを記憶することも可能である。このようなプログラムやデータは、必要に応じてメモリ８０３にロードされることにより、プロセッサ８０１から参照される。

入力Ｉ／Ｆ部８０７は、ユーザからの入力を受け付けるためのデバイスである。入力Ｉ／Ｆ部８０７の具体例としては、キーボードやマウス、タッチパネル、各種センサ、ウェアラブル・デバイス等が挙げられる。入力Ｉ／Ｆ部８０７は、例えばＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）等のインタフェースを介してコンピュータ８００に接続されても良い。

データＩ／Ｆ部８０９は、コンピュータ８００の外部からデータを入力するためのデバイスである。データＩ／Ｆ部８０９の具体例としては、各種記憶媒体に記憶されているデータを読み取るためのドライブ装置等がある。データＩ／Ｆ部８０９は、コンピュータ８００の外部に設けられることも考えられる。その場合、データＩ／Ｆ部８０９は、例えばＵＳＢ等のインタフェースを介してコンピュータ８００へと接続される。

通信Ｉ／Ｆ部８１１は、コンピュータ８００の外部の装置と有線又は無線により、インターネットＮを介したデータ通信を行うためのデバイスである。通信Ｉ／Ｆ部８１１は、コンピュータ８００の外部に設けられることも考えられる。その場合、通信Ｉ／Ｆ部８１１は、例えばＵＳＢ等のインタフェースを介してコンピュータ８００に接続される。

以上のように構成された配送状況管理システム１によれば、サーバ装置２に配送状況管理情報２７を設け、所定の周期または時刻に配送状況を確認するとともに、経過時間に応じてメール等により通知するため、ＥＣ事業者や店舗が配送状況を確認しにいく手間を省き、タイミングよく荷物の配送状況を把握できるという効果を有する。また、ＥＣサーバ４等の通知先ごとに一括して通知するため、ＥＣ事業者等が大量のメールを確認する手間を回避できるという効果も有する。

［変形例］
本発明を上記実施形態に基づいて説明したが、本発明はこれらの形態に限定されない。以下のような変形例も本発明に含まれる。

（１）上記実施の形態で示した例の他に、サーバ装置２は、対象の荷物が図５の判定情報のＮｏ．２の判定基準を満たした場合、以降の荷物について受け手不在の扱いとしてもよい。サーバ装置２は、このように受け手不在の扱いとした場合、例えば、配送者の配送サーバ６に通知して、以降の荷物は一定期間配送者に発送させず不在票の番号を発番させて受け手に通知してもよい。このような構成によれば、サーバ装置２は、配送者の配送を効率よくサポートすることができる。このような構成は、特に、受け手が複数のＥＣサイトで購入し、これらのＥＣサイトがそれぞれ異なる配送会社を利用しているような場合に有効である。

（２）上記実施の形態で示した例の他に、サーバ装置２は、対象の荷物が図５の判定情報のＮｏ．８の判定基準を満たした場合、過去のいわゆる「置き配」等の受け手が指定した配達形態（例えば、受け手が配達時に不在だった場合に玄関先や宅配ボックス等に荷物を置いて配達完了とする配達形態等）を、他の配送者の配送サーバ６に通知してもよい。サーバ装置２は、当該通知にあたって、事前にユーザ端末３からユーザＵの許可を取得してもよい。このような構成によれば、サーバ装置２は、他の配送者に受け手が過去に指定した配達形態を通知することができるため、配送者の配送を効率よくサポートすることができる。

なお、本実施形態は、本発明を説明するための例示であり、本発明をその実施の形態のみに限定する趣旨ではない。また、本発明は、その要旨を逸脱しない限り、さまざまな変形が可能である。さらに、当業者であれば、以下に述べる各要素を均等なものに置換した実施の形態を採用することが可能であり、かかる実施の形態も本発明の範囲に含まれる。
例えば、サーバ装置２が配送状況を取得したり通知したりする周期を１時間、半日、１日、１週間等、適宜変更することが可能である。

１…配送状況管理システム、２…サーバ装置、３…ユーザ端末、４…ＥＣサーバ、５…店舗サーバ、６…配送サーバ、２１…制御部、２２…通信部、２３…受付部、２４…取得部、２５…判定部、２６…通知部、３０…記憶部、２７…配送状況管理情報、２８…通知設定情報、Ｎ…ネットワーク。

Claims (10)

1. 荷物の送り手の第１情報処理装置から、当該荷物の受け手に発送された荷物を示す荷物情報を受け付ける受付部と、
   前記荷物情報に基づいて、前記荷物を配送する配送者の配送サーバから、前記荷物の配送状況を示す配送情報を取得する取得部と、
   前記配送情報に基づいて、前記第１情報処理装置および前記受け手の第２情報処理装置の少なくとも一つに前記荷物の配送状況を通知するか否かを判定し、当該判定の結果に基づいて前記第１情報処理装置および前記第２情報処理装置の少なくとも一つに前記配送状況を通知する通知部であって、前記第１情報処理装置または前記第２情報処理装置ごとに、第２所定期間における前記荷物の前記配送状況を一括して通知する通知部と、を備える、
   サーバ装置。
2. 荷物の送り手の第１情報処理装置から、当該荷物の受け手に発送された荷物を示す荷物情報を受け付ける受付部と、
   前記荷物情報に基づいて、前記荷物を配送する配送者の配送サーバから、前記荷物の配送状況を示す配送情報を取得する取得部と、
   第４所定期間における前記荷物の配送履歴を示す配送履歴情報を記憶する記憶部と、
   前記配送情報および前記配送履歴情報に基づいて、前記荷物が前記配送者の保管場所に持ち戻られるまたは前記送り手に戻される可能性の度合いを判定する判定部と、
   前記配送情報および前記度合いに基づいて前記第１情報処理装置および前記受け手の第２情報処理装置の少なくとも一つに前記荷物の配送状況と前記度合いとを通知するか否かを判定し、当該判定の結果に基づいて前記第１情報処理装置および前記第２情報処理装置の少なくとも一つに前記配送状況と前記度合いとを通知する通知部と、を備える、
   サーバ装置。
3. 前記受付部は、前記受け手の配達先に係る宅配場所のサイズおよび使用状況の少なくともいずれか一つを示す宅配場所情報を管理する宅配場所管理サーバから、前記宅配場所情報を受け付け、
   前記判定部は、前記宅配場所情報に基づいて前記度合いを判定する、
   請求項２に記載のサーバ装置。
4. 前記配送情報は、前記荷物の配達希望日時の有無を含み、
   前記判定部は、前記配送情報および前記配送履歴情報に基づいて、前記受け手および第５所定期間ごとの前記荷物を受け取る確率を示す受け取り確率を判定し、
   前記通知部は、前記配送情報に基づいて、前記配達希望日時が無い前記荷物について、前記受け取り確率を前記配送サーバに通知する、
   請求項２または３に記載のサーバ装置。
5. 前記取得部は、前記配送情報に基づいて前記荷物の配送状況を監視し、当該監視の結果に基づいて当該荷物の配送情報を取得する対象か否か判定する、
   請求項１から４のいずれか一項に記載のサーバ装置。
6. 前記通知部は、前記荷物の配送が一定期間滞留していることを示す第１所定期間に基づいて、前記第１情報処理装置および前記第２情報処理装置の少なくとも一つに前記荷物の配送状況を通知するか否かを判定し、当該判定の結果に基づいて前記第１情報処理装置および前記第２情報処理装置の少なくとも一つに前記配送状況を通知する、
   請求項１から５のいずれか一項に記載のサーバ装置。
7. 前記受付部は、前記第１情報処理装置および前記第２情報処理装置の少なくとも一つから、前記荷物の配送に関する前記送り手または前記受け手の所定のアクションを示すアクション情報を受け付け、
   前記通知部は、前記アクション情報を参照して、第３所定期間において前記所定のアクションがない場合に、前記第１情報処理装置および前記第２情報処理装置の少なくとも一つに前記荷物の配送状況を通知する、
   請求項１から６のいずれか一項に記載のサーバ装置。
8. コンピュータに、
   荷物の送り手の第１情報処理装置から、当該荷物の受け手に発送された荷物を示す荷物情報を受け付ける受付機能と、
   前記荷物情報に基づいて、前記荷物を配送する配送者の配送サーバから、前記荷物の配送状況を示す配送情報を取得する取得機能と、
   前記配送情報に基づいて、前記第１情報処理装置および前記受け手の第２情報処理装置の少なくとも一つに前記荷物の配送状況を通知するか否かを判定し、当該判定の結果に基づいて前記第１情報処理装置および前記第２情報処理装置の少なくとも一つに前記配送状況を通知する通知機能であって、前記第１情報処理装置または前記第２情報処理装置ごとに、第２所定期間における前記荷物の前記配送状況を一括して通知する通知機能と、を実現する、
   プログラム。
9. コンピュータが、
   荷物の送り手の第１情報処理装置から、当該荷物の受け手に発送された荷物を示す荷物情報を受け付けるステップと、
   前記荷物情報に基づいて、前記荷物を配送する配送者の配送サーバから、前記荷物の配送状況を示す配送情報を取得するステップと、
   前記配送情報に基づいて、前記第１情報処理装置および前記受け手の第２情報処理装置の少なくとも一つに前記荷物の配送状況を通知するか否かを判定し、当該判定の結果に基づいて前記第１情報処理装置および前記第２情報処理装置の少なくとも一つに前記配送状況を通知するステップであって、前記第１情報処理装置または前記第２情報処理装置ごとに、第２所定期間における前記荷物の前記配送状況を一括して通知するステップと、を含む、
   情報処理方法。
10. コンピュータに、
    荷物の送り手の第１情報処理装置から、当該荷物の受け手に発送された荷物を示す荷物情報を受け付ける受付機能と、
    前記荷物情報に基づいて、前記荷物を配送する配送者の配送サーバから、前記荷物の配送状況を示す配送情報を取得する取得機能と、
    第４所定期間における前記荷物の配送履歴を示す配送履歴情報を記憶する記憶機能と、
    前記配送情報および前記配送履歴情報に基づいて、前記荷物が前記配送者の保管場所に持ち戻られるまたは前記送り手に戻される可能性の度合いを判定する判定機能と、
    前記配送情報および前記度合いに基づいて前記第１情報処理装置および前記受け手の第２情報処理装置の少なくとも一つに前記荷物の配送状況と前記度合いとを通知するか否かを判定し、当該判定の結果に基づいて前記第１情報処理装置および前記第２情報処理装置の少なくとも一つに前記配送状況と前記度合いとを通知する通知機能と、を実現する、
    プログラム。