JP2005539294A - 物流システムの利用者への通知の伝達のための方法とそのシステム - Google Patents

Abstract

本発明は、物流システムの利用者への通知の伝達のための方法とシステムに関する。本発明は、物流システムにおける複数の異なるイベントを、それぞれ関連付けられた関数を有する異なるモジュールを呼び出すために用いることを特徴とする。該モジュールは、中央送信コンポーネント（３０）へと送信される通知指令を生成する。該送信コンポーネントは該要求に対応した通知を生成し、該通知を利用者へ送信する。

Description

本発明は、物流システムの利用者への通知の伝達方法に関し、該物流システムは、１人以上の登録利用者を有する１つ以上の小包区分システムを含む。通知指令は中央送信コンポーネントに伝達され、該コンポーネントは該指令に基づいて適当な通知を生成し、それを利用者へ送信する。該通知の生成のために、送信コンポーネントは１つ以上のデータベースにアクセスする。
本発明はまた、１つ以上の小包区分システムを運用する物流システムの利用者への通知の伝達システムに関する。

複数の利用者と１以上の物流提供者を有する物流システムの運用のためには、正確な情報がシステムの加入者へ送信される必要がある。以下において、この情報の送信を通知と呼ぶ。このような通知は、一以上の異なる種類の通信によって行うことができる。

通知は、物流システム内で発生したイベントに基づいて送られる。このような関係においては、物流システム内の１つのイベントは通知を引き起こせないか、あるいは１つ以上の通知を引き起こすことができる。通知コンポーネントにおいて、物流システムのイベントをビジネスロジックの関数として通知へ割り付けることができる。

通知は異なる複数の通信の種類によって送信できる。ここで、通信の種類とは通知が配信される様式である。原則的に、同じ情報内容を有する通知を複数の種類の通信によって配信できる。

特に輸送・配信会社が登録利用者の小包区分システムを運用する場合において、複数の異なる通知と通信の種類を有する物流システムが必要となる。このような小包区分システム、または自動販売装置は、例えば、小包や他の荷物を配達人によってシステムの区分装置への配達を受ける登録利用者のための郵便サービス提供者によって運用される。その後、小包が利用者へ配達されたことを利用者に通知する必要がある。さらに、例えば利用者が自身の小包を受け取ったかどうかに関して、物流システムに通知する必要がある。そのうえ、新たな顧客の登録、顧客のデータ、受け取り期限、および代引手数料の情報を、物流システム内において交換する必要がある。

小包区分システムによる物流システムにおいて、通知は一般に電子メールまたはＳＭＳによって送信される。通知の生成、管理および送信は、さまざまなデータベースと処理手順を伴ってなされることが好ましい。

物流システムを物品の流通に利用することが知られている。流通される物品としては、あらゆる種類の製品、材料や物件が可能である。物流システムは、例えば倉庫、中間保管施設、コンテナ、輸送機関、配達人、および受取人の間における、異なる輸送経路による当該物品の流通を組織し監視する役割を果たす。例えば輸送経路、設備稼働率、保管時間およびデータ送信の点において、物品の流通を最適化するという要求に、物流システムの機能は有利に適応される。

本出願者は、特に手紙、物品（小包、包み）、輸送箱、パレットおよびコンテナの流通のための物流システムを利用するものである。これに関連する物流システムは、配達人と受取人の間において荷物を流通させる役割を果たすことが好ましく、そのため例えば輸送速度、倉庫と輸送手段の利用、および荷物データの送信のような基準が重要である。

例えば、ドイツ実用新案２０１０３５６４Ｕ１公報において、特に電子商取引に適していると思われる、荷物の配達と受け取りのためのシステムが開示されている。該システムは、荷物が預けられ回収される複数の自動配達装置（ＡＤＭ）を有する。該システムはまた、システムの運用のためのＬＡＭＩＳサーバー・計算機プログラムを有する。顧客は、例えば電子メール等のさまざまな種類の通信によって、ＡＤＭにおいて該顧客へと預けられた荷物について通知される。

さらに、米国特許６０４７２６４号公報において、利用者が荷物を注文すると中央データベースへの入力が生成される、利用者の荷物の状態を伝達するための方法が開示されている。荷物の状態が変わった場合、例えば配達会社へ移された際、様々な駅に輸送された際、あるいは届け先へ到着した際には、データベースにおいて状態の変化が収集される。この収集は手動で、または電子的に行うことができる。クエリーモジュールによって、通知コンポーネントはデータベースに継続的に状態の変化を要求し、状態が変化した荷物の利用者へのメッセージを生成する。通知は電子メールによってなされることが好ましい。

国際特許出願ＷＯ ０２／５０７０５ Ａ１において、電子メール等の電子ドキュメントの配達システムが開示されている。これらの電子メールは、例えば宣伝目的の添付ファイルを含む。該システムの狙いは、例えば受信者が電子メールの添付ファイルを開封したかどうか、あるいはファイルの開封に必要なソフトウェアを持っているかどうか、といった情報を送信者が受けられないという、既存の電子メールシステムの欠点を防止することである。そのうえ、受信者が電子ドキュメントを開封すると、統計情報が送信者に送信される。該システムは本質的には、テンプレートと送信者の選択情報とからマスタードキュメントを生成する生成モジュールからなる。該マスタードキュメントは確認され、ドキュメントを１人以上の受信者に送信する送信モジュールへと転送される。

米国特許６２２０５０９Ｂ１公報において、荷物の状態情報を顧客データベースに直接記録する小包追跡システムが開示されている。この場合、インターネットのウェブページから顧客データベースにアクセスすることが好ましい。

欧州特許出願ＥＰ ０ ４９１ ３６７ Ａ２において、指令を制御された様式で実行するためにキューに保存するメッセージ処理の方法が開示されている。ここで、指令は届け先の異なる状況や特色、および通信接続に適応できる。該方法は電子メールシステムにおける利用に特に適している。

本発明の目標は、システムにおける異なるイベントのそれぞれに対するありうる最も柔軟な応答、および利用者特有通知の生成を可能とする、物流システム利用者への通知の伝達のための方法と装置の提供にある。このような関係において、物流システムは少なくとも１つの小包区分システムの操作を包含するべきである。
本発明によって、この目的は独立の請求項１および５の内容によって達成される。本発明の有利な実施形態は従属の請求項２から４の結果として得られる。

本発明によってこの目的は以下のように達成される。つまり、物流システムにおける異なるイベントに応じて、それぞれの場合に、関連付けられた関数を有する異なるモジュールが呼び出され、それによってモジュールは中央送信コンポーネントへと送信される通知指令を生成し、該コンポーネントは該要求に基づいて適当な通知を生成しこれを利用者へ送信するものとする。

前記目標はまた、前記方法を実行するためのシステムによって達成される。

物流システムにおけるイベントに応答するための関連付けられた関数を有するモジュールは、異なる使用状況をそれぞれ対応付けする外部インターフェースを形成する。本発明の特に好ましい実施例においては、モジュールに生成される通知指令は、特別な状況の送信コンポーネントへ直接送信されるのみであり、それらは通常、通信要求キューに記述される。キューリーダーは通信要求キューから、タイマー制御の様式によって要求を読み取り、それを中央送信コンポーネントへと送信する。これより前に、通知の状態が確認される。状態の変更は、例えば小包が回収される間に、または回収者が変更された際に行うことが可能である。

本発明の１つの様相においては、送信コンポーネントは、１つ以上のデータベースからのデータに基づいて通知を生成する。これらのデータベースとは、１つ以上の顧客データベース、小包データベース、自動販売装置データベース、およびドキュメントデータベースであることが有利となる。顧客データベースは、例えば物流システムの登録顧客についてのデータを含み、それによって各顧客は識別のためのＩＤを受信する。このデータは住所、電話番号、またはその他の情報を含み得る。小包データベースは物流システムによって輸送される小包の情報を含み、したがって小包は同様にＩＤによって識別される。自動販売装置データベースは、物流システム内で用いられる小包区分システムについてのデータを含む。これも同様にＩＤを含む。

ドキュメントデータベースは、利用者に特有な通知の生成のためのテンプレートを含む。このためには、電子メールおよびＳＭＳの通知のためのテンプレートを含むことが好ましい。テンプレートは、データベースからの利用者特有データが挿入されるプレースホルダーを有する。

送信コンポーネントは、生成された通知をゲートウェイへ送信し、利用者へと送信する。

本発明のさらなる利点、特別な特徴、および実地の実施例は、従属の請求項、および図を参照した以下の好ましい実施例の提示に続く。

図１は特に好ましい実施例における、外部インターフェース、中央送信コンポーネント、および通信要求キューの間での処理シーケンス、図２は通信要求キュー、中央送信コンポーネント、および配達契約ロジックの間での処理シーケンス、図３は中央送信コンポーネント、さまざまなデータベース、およびゲートウェイの間での処理シーケンス、図４は通知の送信のためのシステムにおけるシーケンスの全体概略図である。

以下、多数の登録利用者を有する１つ以上の小包区分システムを含むシステムを運用するための、物流システムについて説明する。これは本発明の特に好ましい実施例であるが、本発明による方法は通知を送信する他の物流システムにも適している。

１つ以上の小包区分システムを操作するための物流システムは、例えば、少なくとも以下の関数に基づく処理段階に分けられる。
ＵＣ ＢＮＫ１：顧客の登録の確認
ＵＣ ＢＮＫ２：顧客データの変更
ＵＣ ＢＮＫ３：新たな小包の通知
ＵＣ ＢＮＫ５：小包回収の通知
ＵＣ ＢＮＫ６：小包返送の通知
ＵＣ ＢＮＫ７：代理人追加の通知
ＵＣ ＢＮＫ８：代理人解任の通知

通知は、システムにおける前述のイベントに関して利用者へ送信され、これらの通知は利用者に該イベントを報知し、そして／あるいはそれを確認する。本発明の特に好ましい実施例においては、個々の処理段階の実行は物流システムのさまざまなモジュールおよび／またはユニットによってなされる。これらのモジュールとは、例えば物流システムの顧客データベース、登録ユニットまたはシステム管理ユニットであり得る。これらのモジュールは、随意に他のコンポーネントとともに、外部インターフェース１０を形成する。

モジュール内のシーケンスと関数手続き呼び出しについて以下で説明する。モジュールに生成される通知指令は、中央送信コンポーネント３０へ転送され直ちに送信されるか、あるいは通信要求キュー４０に読み込まれ遅れて送信され得る。全ての待機中の通知指令は、一様にこのキューから読み出され、適当な通知が送信される。生成される通知は、電子メールまたはＳＭＳによって送信されることが好ましい。

［ＵＣ ＢＮＫ１ 登録の確認］ 小包区分システムの物流システムの新たな顧客の登録の後で、登録モジュールは確認通知を送信するために関数
ｎｅｗＲｅｃｉｐｉｅｎｔ （Ｕｓｅｒ）
を呼び出す。この関数は、顧客に関連付けられた委任者の委任者ロジックに基づいて必要な通知を決定し、該関数はこれを通信要求キューに入れ、これを遅れて送信することができる。

［ＵＣ ＢＮＫ２ 顧客データの変更］ 顧客データベースに保存される自身の顧客データを顧客が変更した後で、顧客データベースは確認通知を送信するために関数
ｕｐｄａｔｅＲｅｃｉｐｉｅｎｔ （Ｕｓｅｒ）
を呼び出す。この関数は同様に、顧客と関連付けられた委任者の委任者ロジックに基づいて必要な通知を決定し、該関数はこれを通信要求キューに入れ、これを遅れて送信することができる。

［ＵＣ ＢＮＫ３ 新たな小包の通知］ 小包が物流システムの自動販売装置に配達されると、この結果の情報が物流システムのシステム管理ユニットへ送信される。物流システムのシステム管理ユニットは確認通知を送信するために関数
ｎｏｔｉｆｙＤｅｌｉｖｅｒｙ （Ｐａｒｃｅｌ）
を呼び出す。この関数は、小包と関連付けられた委任者の委任者ロジックに基づいて必要な通知を決定し、該関数はこれを通信要求キューに入れ、これを遅れて送信することができる。

［ＵＣ ＢＮＫ５ 小包回収の通知］ 小包が物流システムの自動販売装置から回収されると、この結果の情報が物流システムのシステム管理ユニットへ送信される。物流システムのシステム管理ユニットは確認通知を送信するために関数
ｎｏｔｉｆｙＰｉｃｋｕｐ （Ｐａｒｃｅｌ）
を呼び出す。この関数は、小包と関連付けられた委任者の委任者ロジックに基づいて必要な通知を決定し、該関数はこれを通信要求キューに入れる。

［ＵＣ ＢＮＫ６ 小包返送の通知］ 小包が確定した回収期限までに回収されず、物流システムの自動販売装置から返送されると、この結果の情報が物流システムのシステム管理ユニットへ送信される。物流システムのシステム管理ユニットは確認通知を送信するために関数
ｐａｒｃｅｌＦａｉｌｅｄ （Ｐａｒｃｅｌ）
を呼び出す。この関数は、小包と関連付けられた委任者の委任者ロジックに基づいて必要な通知を決定し、該関数はこれを通信要求キューに入れる。

［ＵＣ ＢＮＫ７ 代理人追加の通知］ 物流システムの自動販売装置内の待機中の小包に代理人が追加されると、この結果の情報が物流システムのシステム管理ユニットへ送信される。物流システムのシステム管理ユニットは、それから確認通知を送信するために関数
ａｄｄＳｕｂｓｔｉｔｕｔｅ （Ｐａｒｃｅｌ， Ｕｓｅｒ）
を呼び出す。この関数は、小包と関連付けられた委任者の委任者ロジックに基づいて必要な通知を決定し、該関数はこれを通信要求キューに入れる。

［ＵＣ ＢＮＫ８ 代理人解任の通知］ 物流システムの自動販売装置内の待機中の小包から、追加された代理人が解任されると、この結果の情報が物流システムのシステム管理ユニットへ送信される。物流システムのシステム管理ユニットは確認通知を送信するために関数
ｒｅｍｏｖｅＳｕｂｓｔｉｔｕｔｅ （Ｐａｒｃｅｌ， Ｕｓｅｒ）
を呼び出す。この関数は、小包と関連付けられた委任者の委任者ロジックに基づいて必要な通知を決定し、該関数はこれを通信要求キューに入れる。

加えて、モジュール内の関数によって、例えば以下のイベントが対応付けされ得る。
関数の適用されない自動販売装置：ｎｏｔｉｆｙＡＤＭｆａｉｌｅｄ （Ｐａｒｃｅｌ ｐａｒｃｅｌ， ｂｏｏｌｅａｎ ｆａｉｌｕｒｅ）
包括的通知：ｇｅｎｅｒｉｃＮｏｔｉｆｉｃａｔｉｏｎ （Ｐａｒｃｅｌ ｐａｒｃｅｌ， Ａｄｄｒｅｓｓａｂｌｅ ａｄｄ， ｉｎｔ ｔｙｐｅ）
配達業者への小包配達通知：ｎｏｔｉｆｙＤｅｌｉｖｅｒｙＰｒｏｖｉｄｅｒ （Ｐａｒｃｅｌ ｐａｒｃｅｌ）
配達業者への小包回収の通知：ｎｏｔｉｆｙＰｉｃｋｕｐＰｒｏｖｉｄｅｒ （Ｐａｒｃｅｌ ｐａｒｃｅｌ）
支店：ｎｏｔｉｆｙＢｒａｎｃｈ （Ｓｔｒｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎ， ＤｅｌｉｖｅｒｙＭａｃｈｉｎｅ ａｄｍ， Ａｄｄｒｅｓｓａｂｌｅ ｒｅｃｉｐｉｅｎｔ， Ｂｏｏｌｅａｎ ｂｒａｎｃｈＣＯＤｐａｒｃｅｌ）
商品保管：ｎｏｔｉｆｙＷａｒｅｈｏｕｓｅＤｅｌｉｖｅｒｙ （Ｓｔｒｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎ， ＤｅｌｉｖｅｒｙＭａｃｈｉｎｅ ａｄｍ， Ａｄｄｒｅｓｓａｂｌｅ ｒｅｃｉｐｉｅｎｔ）
住所チェック失敗：ｎｏｔｉｆｙＡｄｒｅｓｓＣｈｅｃｋＦａｉｌｅｄ （Ｓｔｒｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎ， Ａｄｄｒｅｓｓａｂｌｅ ｒｅｃｉｐｉｅｎｔ）
インターネットパスワード：ｎｏｔｉｆｙｌｎｔｅｒｎｅｔＰａｓｓｗｏｒｄ （Ｓｔｒｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎ， Ａｄｄｒｅｓｓａｂｌｅ ｒｅｃｉｐｉｅｎｔ）
包括的メッセージテキスト：ｎｏｔｉｆｙＧｅｎｅｒｉｃＭｅｓｓａｇｅＴｅｘｔ （Ｓｔｒｉｎｇ ｄｅｓｃｒｉｐｔｉｏｎ， Ａｄｄｒｅｓｓａｂｌｅ ｒｅｃｉｐｉｅｎｔ）
配達返送業者：ｎｏｔｉｆｙＤｅｌｉｖｅｒｙＲｅｔｕｒｎｓＰｒｏｖｉｄｅｒ （Ｐａｒｃｅｌ ｐａｒｃｅｌ）
回収返送業者：ｎｏｔｉｆｙＰｉｃｋｕｐＲｅｔｕｒｎｓＰｒｏｖｉｄｅｒ （Ｐａｒｃｅｌ ｐａｒｃｅｌ）
配達代理業者による回収：ｎｏｔｉｆｙＰｉｃｋｕｐＢｙＤｅｌｉｖｅｒｙＡｇｅｎｔＰｒｏｖｉｄｅｒ （Ｐａｒｃｅｌ ｐａｒｃｅｌ）
電子メール変更：ｎｏｔｉｆｙＥｍａｉｌＣｈａｎｇｅｄ （Ａｄｄｒｅｓｓａｂｌｅ ｒｅｃｉｐｉｅｎｔ）
携帯電話番号変更：ｎｏｔｉｆｙＭｏｂｉｌｅＮｕｍｂｅｒＣｈａｎｇｅｄ （Ａｄｄｒｅｓｓａｂｌｅ ｒｅｃｉｐｉｅｎｔ）
郵便ＰＩＮ変更：ｎｏｔｉｆｙＰｏｓｔＰｉｎＣｈａｎｇｅｄ （Ａｄｄｒｅｓｓａｂｌｅ ｒｅｃｉｐｉｅｎｔ）
パスワード変更：ｎｏｔｉｆｙＩｎｔｅｒｎｅｔＰａｓｓｗｏｒｄＣｈａｎｇｅｄ （Ａｄｄｒｅｓｓａｂｌｅ ｒｅｃｉｐｉｅｎｔ）

通知は電子メールまたはＳＭＳによって送信されることが好ましい。例えば、電子メールまたはＳＭＳゲートウェイをこのために使用できる。

実地において本発明による方法を用いるためには、配達不能通知のリストが一定の間隔で（例えば２４時間毎に）手動で訂正されることが有利であることがわかっている。

図１乃至図４は、本発明によるシステムの特に好ましい実施例における、コンポーネントの最も重要な部分の概観を示す。外部のシステムは交差斜線をつけられ、通知システムに属する部分は白く示される。

図１は、通知コンポーネントの特に好ましい実施例の構造を示す。通知コンポーネントは、物流システムの特定のイベントが起こると外部から呼び出される外部インターフェース１０に接続される。該インターフェースは、それぞれが関連付けられた関数を有する複数のモジュールによって形成される。物流システムのイベントは、図示しないＢ２Ｂアカウントロジックコンポーネントによって通知指令に変換される。特定の特殊な場合のために、これらの要求を中央送信コンポーネント３０へと直接送信することができる。しかし、標準の手続きとしては、該要求は通信要求キュー４０に書き込まれ、それからタイマー制御の様式によって中央送信コンポーネント３０へと送信される。これによって、例えば、後の時点（例えば２日後または７日後）に定義される延滞通知が可能となる。キューへの書き込みは、失敗した送信の試みがここで自動的に繰り返されるという点でも有利である。

図２は、通知指令が通信要求キュー４０に書き込まれた後の処理シーケンスを示す。通信要求キュー４０内にある要求は、タイマー制御の様式によってキューリーダー５０に読み込まれる。確認手続きによって、Ｂ２Ｂ配達契約ロジック２０に対し、状態がその間に変わったかどうかが再度確認される。例えば預けられた小包が回収されるか、その回収者が変更されると、状態変化が起こる。確認が成功すると、通信要求が送信コンポーネント３０へと送信される。

図３は、中央送信コンポーネント６０に関連する処理シーケンスを示す。該送信コンポーネント内での処理フローは矢印で示される。送信コンポーネントは外部からの要求を受信し、それから通知の送信のために、接続されたデータベースから要件データを読み込む。これらのデータベースには１つ以上の顧客データベース７０、小包データベース８０および自動販売装置データベース９０が含まれる。自動販売装置データベースはシステムの小包区分ユニットについてのデータを含む。そして、Ｂ２Ｂコンポーネント２０によって規定されるテンプレート１１０がドキュメントデータベース１００から読み出され、テンプレート内のプレースホルダーは現在のデータに置き換えられる。この様式で生成された電子メールまたはＳＭＳは、例えば電子メールおよびＳＭＳゲートウェイ１２０によって送信できる。

図４は通知コンポーネントの３つの部分を組み合わせた全体概略図である。ここで、右手側の中央送信コンポーネント３０と左手側のビジネスロジックコンポーネントの部分との間の分割が明らかに示されている。

以下、本発明による方法の特に好ましい実施例における、システムの個々のコンポーネントとその関数について、より詳細に説明する。

［外部インターフェース］ 外部インターフェース１０は通知コンポーネントに接続され、結局、さまざまな使用事例に起因した直通的な様式となっている。各使用事例において、好ましくは自身の関数が定義され、通知コンポーネント内での要件相関性が達成される。これらの関数は物流システムのイベントに対応し、例えば小包オブジェクトおよび／または利用者オブジェクトに関連する。もちろん、該関数は拡張し他のオブジェクトに関連付けることができる。
ｎｅｗＲｅｃｉｐｉｅｎｔ （Ｕｓｅｒ）は、新たな顧客の登録の後で呼び出される。
ｕｐｄａｔｅＲｅｃｉｐｉｅｎｔ （Ｕｓｅｒ）は、顧客が顧客データベース内に保存される自身の顧客データを変更した後で呼び出される。
ｎｏｔｉｆｙＤｅｌｉｖｅｒｙ （Ｐａｒｃｅｌ）は、小包が物流システムの自動販売装置に配達されると呼び出される。
ｎｏｔｉｆｙＰｉｃｋｕｐ （Ｐａｒｃｅｌ）は、小包が物流システムの自動販売装置から回収されると呼び出される。
ｐａｒｃｅｌＦａｉｌｅｄ （Ｐａｒｃｅｌ）は、小包が確定した回収期限までに回収されず物流システムの自動販売装置から返送されると呼び出される。
ａｄｄＳｕｂｓｔｉｔｕｔｅ （Ｐａｒｃｅｌ， Ｕｓｅｒ）は、物流システムの自動販売装置内で待機中の小包に追加の代理人が追加されると呼び出される。
ｒｅｍｏｖｅＳｕｂｓｔｉｔｕｔｅ （Ｐａｒｃｅｌ， Ｕｓｅｒ）は、物流システムの自動販売装置内で待機中の小包から代理人が解任されると呼び出される。

当該小包または利用者オブジェクトは、それぞれメソッドを与えられる。内部において、一時的に通信要求キュー４０内に保存された物流システムのイベントは通知に変換される。該メソッドから得られる結果により、この変換と一時的保存が機能したかどうかに関してフィードバックが得られる。

＜テンプレート機構＞
［要件テンプレート］ テンプレート１１０の生成とこれらのドキュメントデータベースへの保存に有利であることがわかっている、さまざまな種類の通知を送信することができる。通知の情報内容のレベルでテンプレートを分類するテンプレート名によって、通知の種類が対応付けされる。例えばＢ２Ｂの場合、以下のテンプレートが必要である。
新たな顧客の登録：ＢＮＫ１
顧客データの変更：ＢＮＫ２
小包配達：ＢＮＫ３、 ＢＮＫ３Ｎ
小包が４８時間待機している：ＢＮＫ４、 ＢＮＫ４Ｎ
小包が４８時間で返送される：ＢＮＫ５、 ＢＮＫ５Ｎ

代金引換の小包および代金引換でない小包のためのテンプレートの変化形は、最後の３種類の小包通知に利用できる。名称に加えて、テンプレートはまた配達契約、通信の種類および言語から識別される。もちろん、前述のテンプレートに加えて、かなり多数の他のテンプレートも利用できる。

テンプレートは全ての通知の、電子メールに加えてＳＭＳの形態での送信に利用可能とすべきである。電子メールでの送信のために、テンプレートを、文書番号記入欄に加えてメッセージテキストにも利用できることが好ましい。

［データベース保存］ テンプレート１１０の管理を平易にするために、これらをデータベース１００内に保存する。本発明の特に好ましい実施例において、このデータベースは表１に描かれる複数のフィールドを有する。

通知のための物流システムのイベントの関数として、データベースキー「Ｃｏｎｔｒａｃｔ」が物流提供者または物流契約者（ＢＮＫ１およびＢＮＫ２の場合）、あるいは配達契約（ＢＮＫ３からＢＮＫ５の場合）でありうることは注目されるべきである。

［プレースホルダー機構］ 具体的な情報と置き換えることができるテンプレート１１０内のさまざまなプレースホルダーを用いることが有利であることは明らかである。ＨＴＭＬ形式の電子メールの利用においては、これらのプレースホルダーをＨＴＭＬタグとして定義しないことが有利となる。

少なくとも以下のプレースホルダーを提供できる。
＞Ｍ＿ＮＲ＜：物流システム顧客番号のイベント
＞Ｍ＿Ａｄｄｒｅｓｓ＜：住所の記入欄
＞Ｍ＿ＦｉｒｓｔＮａｍｅ＜：名
＞Ｍ＿ＳｕｒＮａｍｅ＜：姓
＞Ｍ＿ＳＭＳ＜：顧客のＳＭＳ番号
＞Ｍ＿Ｍａｉｌ＜：顧客の電子メールアドレス
＞Ｍ＿Ｓｔｒｅｅｔ＜：顧客の街路および住居番号
＞Ｍ＿ＺｉｐＣｏｄｅ＜：顧客の郵便番号
＞Ｍ＿Ｃｉｔｙ＜：顧客の都市名
＞ＡＵＴ＿Ｓｔｒｅｅｔ＜：自動販売装置の街路および住居番号
＞ＡＵＴ＿ＺｉｐＣｏｄｅ＜：自動販売装置の郵便番号
＞ＡＵＴ＿Ｃｉｔｙ＜：自動販売装置の都市名
＞ＰＯＤ＿Ａｍｏｕｎｔ＜：代金引換金額と通貨
もちろん、前述のプレースホルダーに加えて、この他のプレースホルダーも同様に利用できる。

［メッセージの長さ］ ＳＭＳメッセージの最大の長さは一般に１６０文字である。物流システムの自動販売装置のイベントの配置のような、特定の情報はさまざまな長さであり得るので、過剰に長いフィールド（例えば、都市地区情報の街路または都市）は１６０文字の「桁あふれ」を起こし得る。このような「桁あふれ」を避けるために、本発明の特に好ましい実施例においては、個々のフィールドの長さが各フィールドの重要性および利用可能な残りの長さに依存する、全ての必須の情報を可能な範囲で含む知能機構を用いる。

知能機構に代わるものには、適当なデータベース内の全てのフィールドの短いバージョンを保存する方法があり、１６０文字の最大の長さを超えないようにしている。しかし、これには変更されるＳＭＳテンプレートが新たな長さ制限を伴うという欠点がある。したがって、顧客に入力された住所のような一定の情報は容易に適合できない。

［Ｂ２Ｂ配達契約ロジック］ Ｂ２Ｂ配達契約ロジック２０は、個々のビジネスロジックが特定の物流提供者、特定の物流契約者、および特定の配達契約（特定の物流提供者と特定の物流契約者との間での）を探すことを定義する。このために、個々のイベントは通知指令に変換される。物流システムのイベント「ｎｅｗＲｅｃｉｐｉｅｎｔ」および「ｕｐｄａｔｅＲｅｃｉｐｉｅｎｔ」は、対応する利用者が関連する物流提供者または物流契約者のみに依存する。物流システムの他のイベントは小包の配達に関連し、すなわち、物流契約者（小包の受取人または配達人を定義する）と同様に物流提供者（小包を輸送する）に依存する。ロジックを実行するために、送信される通知（通信要求）のリストが物流システムのそれぞれのイベントのために定義される。通信要求は設定可能な複数のパラメータを含む。

［物流システムのイベント］ 例えば繰り返しの通知が生成された場合、あるいは異なる役割を有する複数の人に通知する必要がある場合のようなそれぞれのイベントのために複数の通知を保存できる。

通知を受けるのは通知されることになっている人である。可能な値は「Ｒｅｃｉｐｉｅｎｔ」（受取人）、「Ｓｕｂｓｔｉｔｕｔｅ」（代理人）、「ＬｏｇｉｓｔｉｃＰｒｏｖｉｄｅｒ」（物流提供者）あるいは「ＬｏｇｉｓｔｉｃＣｏｎｔｒａｃｔｏｒ」（物流契約者）である。

通知が送信される日付けを規定する。このロジックにおいては相対的な日付けのみが保存され、そしてこれと物流システムのイベントの日付けとから、絶対的な日付けが算出される。ここであり得る値は、例えば次のとおりである。
即時：通知を直ちに送信する
＋Ｘ単位時間：通知をＸ単位時間後に送信する
−Ｘ単位時間：通知を小包の満期よりＸ時間単位前に送信する

特定の通信の種類を規定できる。これは、例えば特定のロジックがＳＭＳによる通知のみを許容するだけの場合に必要である。あり得る値は「Ｍａｉｌ」、「ＳＭＳ」および「Ｕｓｅｒ」（利用者のために指定された通信の種類）である。この様式において、例えば、特定の種類の通信による通知のみを許容するだけの配達契約ロジックを対応付けできる。

送信のために用いられるテンプレート１１０を選択可能とすることが好ましい。これは、例えば物流システムの異なるイベントのために、異なるテキストを同じ配達契約において利用可能にできるという点で有利である。加えて、テンプレートは常に現在の配達契約によってさらに制限される。したがって、特定のテンプレート（例えばＢＮＫ１）に異なる２つの配達契約のための異なる内容を持たせることもできる。そのうえ、異なる種類の通信のために同じテンプレートの異なるバージョンを利用可能に維持できる。

さらに、以下で述べる２つの可能な情報の断片のように、ビジネスロジック内での区別に用いられ、あるいはロジックを後で確認するために用いられる、追加の情報を保存できる。

［代金引換小包の場合の区別］ ここで、異なるテンプレートは設定された代金引換金額を有する小包のために用いられる。このテンプレートは、例えば小包の回収者のための情報としての代金引換金額を含む。
Ｂ２Ｂ処理内に小包のための代金引換金額があるが、代金引換は例えば連結請求によって送り状が作られるので、この金額は小包の回収者に送信されない。

［小包が回収されたかの確認］ これは、小包がまだ物流システムの自動販売装置内にあるかどうか、あるいはその間に回収されたかどうかを、確認する確認操作である。これは特に、延滞通知が例えば数日後に送信される場合に有効である。
「小包」オブジェクトは、小包が自動販売装置から取り出される満了期日に、フィードバックを提供するメソッドを提供する必要がある。これは、満了のＸ日前に通知を送信するために必要である。満了期日が設定されていない場合は、標準の手続きとして、特定の複数の暦日を仮定することができる。

［物流提供者 ＤＰＡＧ（Ｂ２Ｃの場合）］ 表２は、物流提供者のために利用者の登録の時に送信される通知（通信要求）を定義する例である。これらが配達人であれば、通知は送信されない。

［物流契約者 最終の顧客（Ｂ２Ｃの場合）］ 表３は、仮想の物流契約者「最終の顧客」のために利用者の登録の時に送信される通知（通信要求）を定義する例である。ここで、Ｂ２Ｃの場合に登録される全ての利用者が編集される。

［配達契約ロジック → 最終の顧客（Ｂ２Ｃの場合）］ 表４は、物流提供者と最終の顧客との間のＢ２Ｃロジックのために送信される通知（通信要求）を定義する例である。

［物流提供者 ＬＰ（Ｂ２Ｂの場合）］

［物流契約者 ＬＣ（Ｂ２Ｂの場合）］

［配達契約ロジック ＬＰ → ＬＣ（Ｂ２Ｂの場合）］

［通信要求キュー］ 送信される通知の指令（通信要求）が一時的に保存される専用データベース表が必要である。該表はキューの管理の役割のみを果たすことが好ましく、小包と受取人についての具体的な情報は、例えば顧客データベース７０または小包データベース８０から常に読み出される。

しかし、通信要求キューのフィールドを拡大することは有利になり得る。例えば、自動販売装置番号とフリーテキストの記述を追加できる。この様式においては、通知は小包だけでなく、郵便番号、イベントおよび自動販売装置番号の組み合わせにも随意に組み合わせることができる。そのうえ、通知を動的に生成することが可能である。

値「Ｕｓｅｒ」を「Ｃｏｍｍ＿Ｔｙｐｅ」へ入力することによって、利用者に応じて種類が規定される通信によって通知がなされることを明記できる。類似して、利用者の設定が用いられる場合は、言語設定「Ｌａｎｇ」には値「Ｕｓｅｒ」を入力できる。入力の記録（ステータス＝３）が必要かどうか、およびその範囲は、具体的な実装に依存する。

［データベースへのアクセス］ 物流システムの以下のデータベースへのアクセスが提供される必要がある。
・顧客データベース：顧客番号によって識別される顧客に関する情報を供給する。
・物流提供者データベース：物流提供者に関する情報を供給する。
・物流契約者データベース：物流契約者に関する情報を供給する。
・配達契約データベース：物流契約者に関する情報を供給する。
・小包データベース：一義の小包番号によって識別される小包に関する情報を供給する。
・自動販売装置データベース：自動販売装置ＩＤによって識別される自動販売装置に関する情報を供給する。

＜通知の送信のシーケンス＞
［タイマー］ 通知コンポーネントは定期的に通信要求キュー４０内の全ての指令を確認する。これは通知コンポーネント内のタイマー４１によって開始される。タイマーの間隔は自由に設定できることが好ましい。

［通信キューリーダー］ タイマー関数が呼び出されると、その送信の日付けが現在の日付けより後である全ての入力が、通信要求キュー４０から読み込まれる。

［オブジェクトの再構成］ キューから読み込まれたそれぞれの入力は「通知指令」オブジェクトに変換される。利用者に通知される一義のＩＤ（ＲｅｃｉｐｉｅｎｔＩＤ）および小包のＩＤ（ＰａｒｃｅｌＩＤ）に基づいて、当該の部分的オブジェクトが再構成される。これは、例えば電子メールアドレスのような、オブジェクトの現在のデータを問い合わせることを可能とするために必要である。

この場合における用語「利用者」は「利用者」、「物流提供者」オブジェクトまたは「物流契約者」オブジェクトを示す。これらの全てのオブジェクトは共用インターフェース「要通知」を実行する。これによって、所属するオブジェクトに通知を送信するために必要なメソッドが提供される。「小包」オブジェクトは、例えば顧客登録の時のように、小包配達とは無関係に通知が送信される場合等には、随意に省略できる。
また、「小包」オブジェクトは、その中に小包がある自動販売装置へのアクセスを可能とするメソッドを提供する。

オブジェクトの読み出されたデータは、制御データ（電子メールおよび／またはＳＭＳ、電子メールアドレス等）に加えて送信されるデータ（名前、住所、自動販売装置の位置等）を含む。

［ロジック確認］ キュー４０から読み込まれた通信要求は、それらがまだ有効な通知であるかどうかを調べるために、Ｂ２Ｂ配達契約ロジック２０に対して確認される。単一の確認手続きのみがなされた場合、小包がまだ回収されていないかどうかを確かめるため、小包データベース８０からのデータに対して確認する必要がある。小包がその間に回収されていた場合は、通知は「完了」であると考えられる。このために、通信要求の状態は未処理である指令の内部キューから除かれる（状態は２＝「処理完了」に設定される）。
小包データベース８０内の小包が既に存在しない場合、それはその間に回収されたと想定され、通信要求は未処理である指令の内部リストから同様に除かれる。

［中央送信コンポーネント］ 通知は中央送信コンポーネント３０に送信される。そして、通信要求に示される通信の種類および利用者の設定に基づき、通知の送信に用いられる通信の種類を確認する。ここでは特定の通信の種類が規定されているが、しかし利用者がその通信の種類に対応していない場合、エラーが起こるかもしれない。

１種類の通信のみが希望される場合、希望されたいわゆるＳＰＩ（サービス提供者インターフェース）が直接呼び出される。利用者が複数の種類の通信での通知を希望するならば、通知が第一の種類の通信でのみ成功し第二ではできない場合に備えて手段を選ぶ必要がある。そのときは、第一の種類の通信を再度用いずに、第二の種類の通信を繰り返し試みる必要がある。このために、「通信要求」オブジェクトの複製を各々に希望される種類の通信で出し、それから適当なＳＰＩに転送することが最も好ましい。

［個々の種類の通信による送信］ 個々の種類の通信はいわゆるＳＰＩ（サービス提供者インターフェース）によって対応付けされる。それぞれの種類の通信のためのＳＰＩがある。それぞれのＳＰＩは通信要求オブジェクトで呼び出される。このオブジェクト内のデータの関数として、電子メールおよび／またはＳＭＳが生成される。このために、適当なテンプレート１１０が読み込まれ、適当なデータベースから読み込まれた情報によってプレースホルダーが置換される。

［送信の遅延］ 通知の送信に付属した、望ましい可能な制限は、夜間（例えば午後１０時から午前６時）の処理を完全に抑制したり、またはＳＭＳ通知のみを抑制することである。送信の完全な停止が希望される場合、例えばタイマーの手段によってこれが達成される。しかし、電子メールは障害を引き起こさないので、ＳＭＳ通知の送信のみを夜間に抑制することが好ましい。このために、ＳＭＳのＳＰＩにおける送信を中断し、送信日を許容時間内の次の適当な時間に設定する。タイマーがこの許容時間に達する最初の時に、通信要求を再度読み込み実行する。

［妥当性の確認］ 通知コンポーネントは送信の日付けの妥当性を確認する。顧客は顧客データベース７０内に存在する必要があり、小包は小包データベース８０内に存在する必要がある。例えば、顧客が既に削除されていた場合、通知はもはや送信されない。そのうえ、自動販売装置の情報（位置）が存在する必要がある。受取人のアドレス（電子メールまたは携帯電話番号）が可能性として正しいかどうか、およびテンプレート１１０内の全てのプレースホルダーがデータで埋められているかどうかが確認される。そのうえ、現存するテンプレートが確かな妥当性を有している必要があり、テンプレートの種類（これは順番に、言語、通信の種類およびＢ２Ｂロジックによって変わる）の関数として、以下の重要なデータのフィールドがテンプレート内に存在する必要がある。

テンプレートが存在しない場合、あるいは適当な入力を持たない場合は、送信は中断され、ＬＯＧファイル内に適当なエラーメッセージが生成される。テンプレートは確認されるべきである。ＳＭＳによって送信がなされる場合、知能機構がメッセージを１６０字の最大長さに適合させる。

［送信の実行］ “＜テンプレート機構＞”のセクションで述べられた機構が、送信される文章を生成する。該文章と受取人情報は電子メールまたはＳＭＳのゲートウェイ１２０によって送信の種類の関数として送信される。ゲートウェイへの送信が失敗すると、一時的な不調をより容易に克服できるように、第２の送信をすぐに試みることができる。

［結果の保存］ 全体の手続きが成功した場合、そのときは、本発明の特に好ましい実施例においては、フィールドの状態が「２」に設定された未決着指令のキューから入力が削除される。同時に、フィールド「ＣｏｍｐｌｅｔｉｏｎＤａｔｅ」は現在の日付け＋時刻に設定される。通信キュー４０内のこのような入力はこれ以上処理されない。通知が送信できないかもしれない不測の場合に備えて、入力が特定の期間通信キュー内に利用可能に保たれることが有利である。

複数の理由によってエラーが生じ得る。
・顧客が顧客データベース７０内にない、あるいは自動販売装置が自動販売装置データベース９０内にない。
・読み込まれたデータが妥当でない（例えば完全に埋められていない）。
・テンプレートが誤っている、あるいは存在しない。
・技術的な理由で通知が送信できない（複数の試行の後で）。

エラーが生じた場合、フィールド「ＲｅｔｒｙＣｏｕｎｔ」が増加する。「ＲｅｔｒｙＣｏｕｎｔ」が既定の量（これもタイマーの頻度に依存する）を超える場合、ＬＯＧファイル内に適当なエラーメッセージが生成され、例えば手動での再処理が開始される。これは、例えば保存されているデータの確認または入力の通信キューからの手動除去であり得る。これらの誤った通知が再三にわたって試みられることを防ぐために、「ＲｅｔｒｙＣｏｕｎｔ」が特定の値に到達したらすぐに状態を「９」に設定する。これらの通知は処理されない。そのうえ、現在の日付けがフィールド「ＣｏｍｐｌｅｔｉｏｎＤａｔｅ」に中断の日付けとして保存される。エラーの除去の後で、状態を再び手動で「１」に設定する必要がある。「ＣｏｍｐｌｅｔｉｏｎＤａｔｅ」と「ＲｅｔｒｙＣｏｕｎｔ」は同様にリセットする必要がある。

［定期的クリーンアップ］ 通信要求キューの定期的な「クリーンアップ」が必要である。一定の期間（例えば１週間）より前に終了された全ての完了した事例は、データベースから除去されるべきである。そのうえ、１ヶ月以上古い全てのエラーの事例は、通信要求キューから除去されるべきである。完了または中断の日付けはフィールド「ＣｏｍｐｌｅｔｉｏｎＤａｔｅ」に保存される。例えば、以下が実行される。

［記録機構］ 電子メールまたはＳＭＳの送信におけるエラーもまたＬＯＧファイル内に記録されるべきである。これらのＬＯＧファイルは、例えばゲートウェイの失敗を確認可能とするために、定期的に監視される必要がある。さらに、少なくとも最初の段階において、全ての送信された通知は同様に保存されるべきである。このために、エラー監視を単純化するために専用のＬＯＧファイルが用いられる。

［提案と制限の設計］ タイマーの実装のためには複数の代替が存在する。それは、アプリケーションサーバーの内部タイマー、定時ジョブ、データベースタイマー、または他の発展したメソッドによって実現できる。

最初の別案を選択できる。電子メールおよびＳＭＳの送信手続きの実行にも複数の代替が存在する。それは、ＪＭＡＰＩ （Ｊａｖａ Ｍｅｓｓａｇｅ ＡＰＩ）、ＪＭＳ、アプリケーションサーバーの適当な電子メールサービスの利用等である。ここでは、最初の２つの変形が好ましい。

［レイアウト］ 通知コンポーネントは外観またはインターネットのページを有する必要がない。しかし、個々の通知のためには複数の異なるテンプレートが必要である。ここで、テンプレートが容易変換可能であることは利点となる。以下のセクションにおいて描写されるテンプレートは単に実施例にすぎない。もちろん、どのような希望される通知テキストも、適当なプレースホルダーに統合できる。

＜ＢＮＫ１＝登録の確認＞
［電子メールによる通知］

［ＳＭＳによる通知］

＜ＢＮＫ２＝顧客データ変更の確認＞
［電子メールによる通知］

［ＳＭＳによる通知］

＜ＢＮＫ３＝「新たな小包」という通知＞
［電子メールによる通知］

［ＳＭＳによる通知］

＜ＢＮＫ３Ｎ＝「代金引換の新たな小包」という通知＞
［電子メールによる通知］

［ＳＭＳによる通知］

＜ＢＮＫ４＝「小包が４８時間待機している」という通知＞
［電子メールによる通知］

［ＳＭＳによる通知］

＜ＢＮＫ４Ｎ＝「代金引換小包が４８時間待機している」という通知＞
［電子メールによる通知］

［ＳＭＳによる通知］

＜ＢＮＫ５＝「小包が４８時間以内に取り除かれる」という通知＞
［電子メールによる通知］

［ＳＭＳによる通知］

＜ＢＮＫ５Ｎ＝「代金引換小包が４８時間以内に取り除かれる」という通知＞
［電子メールによる通知］

［ＳＭＳによる通知］

＜他のコンポーネントの要求＞
［オブジェクト「小包」］ 一義の小包番号によって識別される小包に関する情報を供給するオブジェクト「小包」が提供される必要がある。
・小包が自動販売装置から取り除かれる満了の日付けのフィードバックを提供するメソッドを、小包が提供する必要がある。これは期日のＸ日前に通知を送信するために必要である。期日が設定されていない場合は、標準の手続きとして、歴日の特定の数（例えば９日）を想定することができる。
・「配達契約」オブジェクトはあるメソッドによって送信される必要がある。
・「小包」オブジェクトは、小包がある自動販売装置にアクセスするためのメソッドを提供する。

［オブジェクト「マシン」］ オブジェクト「マシン」は、自動販売装置ＩＤによって識別される自動販売装置データベース９０へのアクセスを許容する。
・このオブジェクトのメソッドによって、自動販売装置の位置に関する情報を提供する必要がある。

［通知を受けるオブジェクト（「要通知」オブジェクト）：「利用者」、「物流提供者」および「物流契約者」］ オブジェクト「利用者」は顧客番号によって識別される顧客に関する情報を供給する。オブジェクト「物流提供者」は物流提供者データベースへのアクセスを許容する。オブジェクト「物流契約者」は物流契約者に関する情報を供給する。
・全てのオブジェクトは共用のインターフェース「要通知」を実行する。これは、例えば電子メールアドレスやアドレスの形式の読み込みといった、属するオブジェクトへの通知の送信に必須のメソッドを提供する。
・一義のＩＤによって「要通知」オブジェクトを識別可能にする必要がある。このために、例えば、「利用者」、「物流提供者」オブジェクトおよび「物流契約者」オブジェクトのＩＤは、オブジェクトの種類（ＵＳ＿、ＬＰ＿、ＬＣ＿）の識別に結びつけられるが、これらのＩＤをメソッド「ｇｅｔＵｎｉｑｕｅＩＤ」によって返送可能とする。このメソッドはインターフェース「要通知」において定義される点で有利である。
・このＩＤによって「要通知」オブジェクトを再構成するために、そのようなＩＤに基づいて適当なオブジェクトを生成するオブジェクト「ファクトリー」が実行される。

［ロジックオブジェクト「配達契約」、「物流提供者」および「物流契約者」］
・Ｂ２Ｂロジックは全てのオブジェクトについて、例えば共用のインターフェースによって問われる必要がある。
・このようなオブジェクトは一義のＩＤによって識別される必要がある。このために、「物流提供者」および「物流契約者」について既に存在する「要通知」オブジェクト（ｇｅｔＵｎｉｑｕｅＩＤ）のＩＤを利用できる。対応するメソッドは「配達契約」にも存在し、そしてそれは、オブジェクトの種類（ＤＣ＿）の識別に結びつけられるオブジェクトのＩＤにフィードバックを提供する。

この手続きをさらに改善するために、以下の対策を個々にあるいは合わせて実行することは有利となり得る。
・全ての電子メールはオフラインで送信され通信キューに書き込まれ、一定の間隔で読み出され処理される。
・実装はどのような言語も（好ましくは固定の言語を）サポートできる。
・電子メールは好ましくは平文で送信される。

しかし、本発明の特に好ましい実施例は、
・ＨＴＭＬ形式の電子メールをサポートする。
・ここで、登録の際に、顧客が電子メールを受信する形式（平文またはＨＴＭＬ）を選択できる。したがって、送信手続きにおいて異なるテンプレートが用いられる。
・多言語能力：登録の際に、顧客が自身の好ましい言語を選択できる。したがって、送信手続きにおいて異なるテンプレートが用いられる。
・ＲＦＣ１１４９規格による通知をサポートする。
・そのうえ、内容管理システムを用いて、電子メールとＳＭＳのためのテンプレートの管理を容易とすることができる。

特に好ましい実施例における、外部インターフェース、中央送信コンポーネント、および通信要求キューの間での処理シーケンス。 通信要求キュー、中央送信コンポーネント、および配達契約ロジックの間での処理シーケンス。 図３は中央送信コンポーネント、さまざまなデータベース、およびゲートウェイの間での処理シーケンス。 通知の送信のためのシステムにおけるシーケンスの全体概略図。

符号の説明

１０ 外部インターフェース
２０ 配達契約ロジック
３０ 中央送信コンポーネント
４０ 通信要求キュー
４１ タイマー
５０ キューリーダー
７０ 顧客データベース
８０ 小包データベース
９０ 自動販売装置データベース
１００ ドキュメントデータベース
１１０ テンプレート
１２０ ゲートウェイ

Claims (17)

1. 物流システム内の異なるイベントに応じて、関連した関数を有する異なるモジュールがそれぞれの場合において呼び出され、それによって該モジュールが中央送信コンポーネント（３０）に伝達される通知指令を生成し、該中央送信コンポーネントが該指令に基づいて適当な通知を生成し利用者に伝達することを特徴とする物流システムの利用者への通知の伝達方法。
2. 前記物流システムが、１人以上の登録利用者を有する１つ以上の小包区分システムを操作することを特徴とする、請求項１に記載の方法。
3. 通知を生成するために、前記送信コンポーネント（３０）が１つ以上のデータベースにアクセスすることを特徴とする、請求項１および２の一方あるいは両方に記載の方法。
4. 前記送信コンポーネント（３０）が１つ以上の顧客データベース（７０）、小包データベース（８０）、自動販売装置データベース（９０）、およびドキュメントデータベース（１００）にアクセスすることを特徴とする、請求項３に記載の方法。
5. 顧客データ、小包データおよび小包区分システムデータが、ＩＤを用いて前記データベース内に割り付けられることを特徴とする、請求項４に記載の方法。
6. 前記イベントが、少なくとも
   新たな利用者の登録、
   利用者データの変更、
   新たな小包の小包区分システム内への配置、
   小包の小包区分システムからの回収、
   小包の返送、
   小包への回収のための代替値の追加、
   代替値の除去、
   を含むことを特徴とする、請求項２から５のうちの１つ以上に記載の方法。
7. 前記モジュールによって生成された通知指令は、前記中央送信コンポーネント（３０）に伝達され直ちに伝達可能となるか、あるいは通信要求キュー（４０）に書き込まれ遅れて伝達可能となることを特徴とする、上記の請求項のうち１つ以上に記載の方法。
8. 前記通知指令は前記通信要求キュー（４０）からキューリーダー（５０）によってタイマー制御の様式で読み出されて前記中央送信コンポーネント（３０）に伝達され、該中央送信コンポーネントは適当な利用者固有の通知を生成し、そしてゲートウェイ（１２０）によって利用者へ伝達することを特徴とする、請求項７に記載の方法。
9. 前記中央送信コンポーネント（３０）へ伝達される前に、前記通知指令の状態が配達契約ロジック（６０）によって確認されることを特徴とする、請求項８に記載の方法。
10. 前記通知は電子メールおよび／またはＳＭＳの形で利用者に伝達されることを特徴とする、上記の請求項のうち１つ以上に記載の方法。
11. 物流システムの利用者へ通知を伝達するシステムであって、
    請求項１から１０の１つ以上に記載の方法の実行に適していることを特徴とするシステム。
12. 少なくとも、それぞれに通知指令の生成のための関数を有するモジュール、中央送信コンポーネント（３０）、通信要求キュー（４０）、および１つ以上のデータベースからなることを特徴とする、請求項１０に記載のシステム。
13. 特定の利用者のための個々の通知を生成するためのテンプレート（１１０）を有するドキュメントデータベース（１００）を含むことを特徴とする、請求項１２に記載のシステム。
14. 顧客に関する情報を有する顧客データベース（７０）を含むことを特徴とする、請求項１１から１３のうちの１つ以上に記載のシステム。
15. 小包に関する情報を有する小包データベース（８０）を含むことを特徴とする、請求項１１から１４のうちの１つ以上に記載のシステム。
16. 自動小包区分システムに関する情報を有する自動販売装置データベース（９０）を含むことを特徴とする、請求項１１から１５のうちの１つ以上に記載のシステム。
17. 通知の伝達のためのゲートウェイ（１２０）を有することを特徴とする、請求項１１から１６のうちの１つ以上に記載のシステム。