配送計画を動的に更新するシステムおよび装置
配達サービスを提供する配達車両を主に運転する要員が使用するポータブルコンピュータで、入力を受け取るシステムおよび方法が開示される。その入力は、一定の配達基準に従って事前作成された配送計画の完了に、場合によっては影響を及ぼす。入力は、積荷目録の修正、気象状態若しくは交通状況に関する更新、または残りの配達に影響を及ぼす他の要因を含む。最初の配送計画の修正が正当化されるかどうかを判定するために、入力は調査され、正当化される場合、信号を生成し、最初の配送計画の処理を開始させ、一定の配達基準を満足する更新配送計画を作成する。一定の配達基準は、一定の時間帯までに配達を完了する保証を含んでもよい。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、経路上のサービス車両にかかわるサービスストップに関して、ポータブルコンピュータにより配送計画（ｄｉｓｐａｔｃｈ ｐｌａｎ）の更新を開始するタイミングを決定することに関する。更新は、様々な形態であってもよく、様々な種類の入力を処理することにより開始される。一実施形態では、提供サービスは小包の配達である。
【背景技術】
【０００２】
宅配産業および様々な場所にサービス要員を派遣する他の産業の事業実施の課題は、所与の日の作業を完了するために、運転手に最新で正確且つ効率的な指示を与える能力を付けることである。多くの車両を有する企業は、運転手ができるだけ大きい受け持ち区域をできるだけ少ない時間で効率的に担当できる配送計画を開発するために、多くの時間と金をかける。経路が毎日変わることのある日々の配達サービス（例えば、自動販売機サービス経路や宅配サービス）に関しては、所与の日に運転手が使用する配送計画と経路は、通常、前日中または遅くとも作業日の始業時までに作成される。運転手に割り当てられる作業は、それまでの実績の平均配達量に基づき、運転手が実行できる作業量の統計分析またはヒューリスティック分析にたいてい基づく。
【０００３】
所与の経路上のサービスストップ数は、通常、それまでの作業日中の運転手の平均作業量を観察することに基づいている。基本的な経路計画を使用し、当日完了することが必要な予定された配達またはサービスストップを使用して、配送計画または配達スケジュールは導き出される。配送計画の変更（例えば、サービスストップの追加または削除）は、移動経路に影響を及ぼすことがあり、容易または効率的に受け入れられないことがある。配送計画のリアルタイムの変更の中には、所与の経路に精通した経験豊富な運転手が、自己発見的に適応できるものもあるが、作業日中に発生するリアルタイムの変更の中には、経験豊富な運転手にさえ効果的に対応できないものがあり、ましてや経路に精通していない運転手にはとても対応できない。
【０００４】
配達プロセスを複雑にする別の側面は、高級なサービスレベルおよび／または配達時間保証の発達である。多くのサービス提供業者は、保証されたサービス保証時刻（「サービス責務」、「サービス保証」とも呼ばれる）に関する高級なサービスレベルを提供する。これらの保証は、小包の配達が一定の時刻までに、または指定された時間帯に完了することを必要とする。サービス保証は、経路に沿って作業を割り当てることと、その経路上の個別の小包配達時間保証に責任を負うこととを必要とするので、配送計画の作成または修正を複雑にする。驚くほどのことではないが、サービス要員は、配達保証時刻が過ぎてはじめて、小包に保証時刻があることを確認することもある。別の場合には、運転手は、サービス配達時間保証を満足させるために計画経路を逸れることもある。しかし、このことは他の配達の完了を非効率にすることがある。
【０００５】
これらの問題は、小包配達サービスに特有のものではなく、修理、設置、販売または現場視察のために要員を派遣するなどの、他のサービスの実行にも当てはまる。通常、顧客は、サービス訪問を受ける時間帯を指定される。サービス要員の到着予定に関して、顧客は、狭い時間帯を希望するのに対して、サービス提供業者は、サービス要員に融通性を与えるために、広い時間帯を希望する。他の場合には、サービスが提供されてもよい、または提供されてはならない時間に関して、顧客は、全面的な制約を持っていることもある。例えば、顧客によっては、配達が受け入れられる、またはサービスが提供されてもよい時間を限定することがある。
【０００６】
さらに、配送計画の実行は、天候、道路状況、サービス車両の機械的故障などの日常的な出来事で影響を受けることがある。これらの出来事のどれもが、個別または一緒に、配送計画の実行に影響を及ぼすことがあり、配達時間保証を果たせなくさせるか、または少なくとも効率を悪化させる。配送計画は、最初に決定されたとき、出来事の発生を考慮しなかった（そして、できなかった）からである。例えば、道路閉鎖または交通事故は、運転手に、配送計画に関するサービス車両の経路を変更させて非効率にすることがある。特定のサービス担当地域に精通している運転手は、個人的な知識に基づき自己発見的にその経路を変更できることがあるが、そのようなその場その場の逸脱は、最適な解決策を提供しないこともある。まだ所与の経路に精通していない場合は、経験豊富な運転手でさえ、そのようなその場その場の逸脱を行い、例外的な状況のもとですべての配達時間保証を確実に果たすことは期待できない。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
それ故、サービス産業内には、様々な種類の状況検出時における配送計画の更新手段を、運転手に提供する改良されたシステムおよび方法に対する満たされていない要求が存在する。
【課題を解決するための手段】
【０００８】
本発明は、一般に、配送計画を格納、処理および更新するポータブルコンピューティングデバイスを使用するシステムおよび方法に関する。配送計画は、論理的な一連のレコードと見なしてもよく、各レコードはサービスストップを表し、各サービスストップは小包の配達などのサービスの実行に関連する。ポータブルコンピュータは、ポータブルコンピューティングデバイスに通常無線で送信される更新データを含む入力メッセージを受信する能力がある。更新データは、新しいレコードの追加、レコードの削除、またはレコード内容の修正などの配送計画の内容に影響を及ぼすデータを含む、様々な形式のものであってもよい。その情報は、場合によっては、配送計画へのサービスストップの追加、サービスストップの削除、またはサービスストップで実行すべき活動の変更をもたらす。配送計画に影響を及ぼす他の種類のデータには、配送計画に関連するサービス地域に関する交通および／または気象関連データの受信が含まれる。また別の形式のデータには、時刻と場所の定期的な入力が含まれ、その入力は、予定されたスケジュールに照らして配送計画の相対的実行を判定するために使用される。
【０００９】
ポータブルコンピューティングデバイスは、配送計画の実行に影響があるかどうかを判定するために入力データを処理し、現在のスケジュール進捗状況に基づき、まだ実行されていないサービス保証を確実に果たすために、場合によっては一連のレコードの再順序付けを含む、必要に応じた配送計画の更新もできる。スケジュール進捗状況は、配送計画の進捗状況に基づき、現在位置および／または時刻と予定位置および／または時刻との検討に基づく方法を含む、様々な方法で判定してもよい。
【００１０】
ポータブルコンピューティングデバイスが、一旦入力データを処理すると、受信した入力データ、配送計画へのその影響、および／または配送計画実行の有力な代替案を含む様々な結果を、ユーザに提示してもよい。結果は、テキストベースのテーブルフォーマットおよびグラフィック地図ベースのフォーマットを含む様々な形式で、サービスを完了するための補助としてユーザに提示されてもよい。グラフィック地図ベースのフォーマットでは、配送計画に示される様々なサービスストップに関連する場所などの様々な場所が描画されてもよい。
【００１１】
上記の要約は、本発明の態様の１つのサブセットだけを表し、決して特許請求の範囲を限定する意図はない。
【発明を実施するための最良の形態】
【００１２】
これより、添付の図面を参照して、以下に本発明をより詳細に説明する。本発明の実施形態の中には、図面で示されているものもあるが、すべてが示されているわけではない。実際のところ、本発明は多くの異なる形態で具現されてもよく、本明細書中に記載する実施形態に限定されると解釈すべきではない。正確に言えば、これらの実施形態は、この開示が適用される法的要件を満たすために提供される。同様の参照番号は、初めから終わりまで同様の要素を示す。
【００１３】
前述の説明および関連図面に提示された教示を利用して、本発明に関連する技術分野の業者は、本明細書中に記載する本発明の修正形態および他の実施形態を多数思い浮かべるであろう。それ故、当然のことながら、本発明は開示した特定の実施形態に限定されず、添付の特許請求の範囲内に修正形態および他の実施形態が含まれることを意図している。本明細書中では特定の用語が使用されるが、一般的および説明的意味でだけ使用されており、限定のためではない。
【００１４】
本発明の一実施形態による方法、システムおよびコンピュータプログラムのブロック図およびフローチャート図を参照して、以下に本発明を記述する。ブロック図およびフローチャート図の各ブロックは、コンピュータプログラム命令で実施してもよいことは理解されるであろう。コンピュータまたは他のプログラム可能データ処理装置で実行される命令が、システムまたはフローチャートのブロックで指定される機能を実施する手段を作り出すようなマシンを製造するために、これらのコンピュータプログラム命令は、汎用コンピュータ、専用ポータブルコンピュータ、情報携帯端末（ＰＤＡ）、または他のプログラム可能データ処理装置にロードされてもよい。
【００１５】
これらのコンピュータプログラム命令は、コンピュータで読み取り可能なメモリにも格納されてもよい。コンピュータで読み取り可能なメモリは、自装置に格納した命令が、フローチャートの１つ以上のブロックに指定された機能を実施する命令手段を含む製品を作り出すような特定の方法で機能するように、コンピュータまたは他のプログラム可能なデータ処理装置に指示してもよい。コンピュータまたは他のプログラム可能な装置で実行される命令がフローチャートの１つ以上のブロックに指定された機能を実施する工程を提供するようなコンピュータ実施プロセスを、コンピュータまたは他のプログラム可能な装置で実行される一連の操作ステップによって作り出すためにも、コンピュータプログラム命令は、コンピュータまたは他のプログラム可能なデータ処理装置にロードされてもよい。
【００１６】
コンピュータは、配送サービス業界で既知のデバイスなどのポータブルコンピューティングデバイスであってもよい。一実施形態は、ＤＩＡＤ（Ｄｅｌｉｖｅｒｙ Ｉｎｆｏｒｍａｔｉｏｎ Ａｃｑｕｉｓｉｔｉｏｎ Ｄｅｖｉｃｅ）として知られ、１つには宅配関連データを管理するために、本発明の譲受人であるＵＰＳ（Ｕｎｉｔｅｄ Ｐａｒｃｅｌ Ｓｅｒｖｉｃｅ Ｉｎｃ．）が使用し、ＵＰＳの運転手が携行している。ＤＩＡＤの機能に関する詳細な情報は、２００３年６月１９日発表の米国特許出願公開の第２００３／０１１４２０６号の「発明の名称：Ｐｏｒｔａｂｌｅ Ｄａｔａ Ａｃｑｕｉｓｉｏｎ ａｎｄ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ ａｎｄ Ａｓｓｏｃｉａｔｅｄ Ｄｅｖｉｃｅ ａｎｄ Ｍｅｔｈｏｄ（携帯データ収集管理システムおよび関連装置ならびに方法）」（出願第１０／２２７，１４７号）に見つけることができる。その内容は、ここでの引用により組み込まれる。配達すべき特定の小包についての情報および集配すべき小包などの他の情報は、始業時に積荷目録をアップロードすることで、ＤＩＡＤに格納される。ＤＩＡＤは、通信手段に融通性があり、様々な実施形態では、場所、利用法または伝達する情報の種類に基づき、種々のエンティティと通信するために種々の技術（例えば、有線ベースの通信手段、赤外線通信手段および／または無線通信手段）を用いてもよい。しかし、ラップトップコンピュータを含む、他の様々な種類のポータブルコンピューティングデバイスが使用されてもよい。また、コンピューティングデバイスは、テキストベースの情報やグラフィック表示を含む様々な方法で、ユーザに配送計画に関する結果を提示してもよい。
【００１７】
典型的な宅配サービスは、一定のサービス担当地域内の経路上の様々な場所にストップし、各ストップでサービスを提供することを含む。各サービスストップは、通常、１個以上の小包の配達に加えて、また１個以上の小包の集配も伴う。各サービスストップ（単に「ストップ」とも呼ぶ）は、通常、所定の経路に沿った一連のストップの１つとして計画される。経路に沿った一連のストップは、本明細書中では配送計画と呼ぶ。一連のストップは、後で示されるように、表形式またはグラフィック形式でユーザに提示されてもよい。多くの場合において、地理的なサービス担当地域は、通常、ある程度静的である。すなわち、一般に地理的地域内の同じ道路に関係する。しかし、各道路上のあらゆる場所が通常はサービスストップに関連するわけではないので、所与の日にすべての道路を必ずしも移動する必要はない。他の場合には、サービス担当地域は、配送計画の全体的な所要の配達に基づき、範囲が変わる（サイズの増大または縮小）。従って、サービス車両が走る実際の経路（例えば、一連の道路）は、特定の日の作業量に基づき、または季節的な変化に基づき、変わってもよい。おおむね静的な経路を使用することにより、運転手は経路に精通し、通常の運転時間および他の状況についての経験を積むことが可能になり、それから逸脱するときに、参照され得る基準を提供する。移動経路またはサービス担当地域は静的であってもよいのに対して、所与の日の経路に沿って予定される個々のサービスストップは、たいてい変わる。配送計画は、通常、配達すべき小包（「配達物」）、集配すべき小包（「集配物」）、または両方に基づき決定される。配送計画は、通常、紙形式かそれとも運転手が必要によりアクセスできるポータブルコンピューティングデバイス（例えば、ＤＩＡＤ）に電子的に伝達されるかで、運転手に提供される。もちろん、宅配以外のサービスに関係する利用も可能であり、本発明の原理をそのような利用にも容易に適合させることができる。
【００１８】
このように、所与の車両に対する配送計画は、通常、配達すべき小包に基づき当日の配達開始前に決定される。場合によっては、小包集配に関する情報が始業時にわからなくて、配達車両の出発前にＤＩＡＤにロードされないことがある。あるいは、追加配達についての情報が、配達開始後に提供されることもある（その場合は、配達する追加の小包は、荷降ろし場所で運転手が受け取ってもよい）。他の場合には、顧客からのサービス要求を受け付けるのが遅すぎて、当日のサービスストップの開始前にＤＩＡＤにロードできないことがある。以前は、出発前に運転手が新しいストップについて知らされていなかった場合、顧客は次の営業日まで集配を待たなければならなかった可能性がある。
【００１９】
顧客からのサービス要求が遅すぎて、当日作業を実行できない可能性は常にあるが、無線通信の使用は、ほとんどの都市部と農村部で容易に可能であり、予定外のサービスストップを通知するために使用されている（例えば、これは、携帯電話機またはプライベートディスパッチ無線を介して行われる）。当日の配送計画の修正に関して途中で、配達車両の運転手（または、場合によっては遠隔のポータブルコンピュータ）に遠隔で通知することは可能である。多くの状況で、翌営業日に集配をスケジュールすることなく小包を集配することを可能としつつ、計画外のサービスストップを受け入れることができる。
【００２０】
予定外のサービスストップの追加により、有限量の時間を消費する。そのような計画外のストップの幾つかで要する時間により、まだ実行していないサービスストップが遅れることがあり、それ故、他のサービスストップのサービス保証を危うくする。
【００２１】
本発明の適用を説明する１つの状況を図１に示す。図１は、３つのストップを備える配達経路を示す。普段の経路は、ストップＡ、ストップＢ、次いでストップＣの順番に定められていると想定する。この順番のサービスストップを、配達スケジュールである配送計画（２）に示す。配送計画（２）は、通常、各ストップに対応するレコードを有するデータベースとして具現され、各レコードは、各ストップで配達する１個の小包に対する小包識別子（「小包ＩＤ」）を示す。小包識別子により、運転手およびポータブルコンピュータは、特定の小包または小包に関する関連情報を一意に特定することができる。それ故、レコードは、小包識別子を使用してコンピュータにより配送計画内で特定されてもよく、小包識別子は小包にも（人間が読み取り可能な形式とマシンが読み取り可能な形式との両方で）印刷される。潜在的なサービスストップのすべてで常に小包配達があるわけではないが（例えば、サービスストップによっては、小包集配であってもよい）、説明のために、図１では、各サービスストップで小包１個を配達し、３つの場所のどこでも小包の集配はないことを示している。最後に、テーブル（２）の配送計画は、ストップＣ宛の小包１個が午前１０：００までに配達されなければならないことを示す。
【００２２】
図１は、サービス配達車両（４）が、午前９：００の現在時刻（１）に所与の場所「Ｘ」にいることを示す。現在位置からの様々なストップ間のパスに、任意の作業単位またはコスト単位を割り当ててもよい。これらの単位は、運転時間、距離、または他の作業関連測定基準を表してもよい。時間と動作の研究用の作業単位を定量化するために実績データを収集することは、生産工学では周知のことである。この図では、各作業単位は時間で５分に相当すると想定する。従って、配達車両が午前９：００にストップＡにある場合、現在時刻の午前９：００から午前１０：００の間に５分が１２回ある。ストップＡからストップＢまでの定期経路は、通常１０単位を消費し、ストップＢからストップＣへの移動では４単位を消費する。合計時間（１４単位）は１２単位限界を超え、配送計画２で示される経路の使用は、ストップＣで必要なサービス保証を果たすことが出来なくなるおそれがある。他方、経路をまずストップＡからストップＣに進むように変更すると、５単位しか消費しないので、この経路の使用により、サービス保証配達時刻に間に合うようになる。ストップＡとストップＢでの配達に関しては、同様の配達時間保証がないので、代替経路の選択は、それらのストップに関する配達時刻（すなわち、サービス保証）に影響を及ぼさない。
【００２３】
通常、配送計画は、サービス保証を果たすことを見込んで前もって準備される。例えば、上記の説明では、最初の配送計画で示される元の経路は、過去の時間測定に基づき所要時刻までに配達する結果になっていたかもしれない。具体的に言うと、過去の配達データが車両は通常午前８：００にストップＡに到着することを示す場合、このことは、実績の移動時間に基づき、所要時刻内にストップＣに小包の配達をするのに十分な時間を与えるであろう。しかし、特定の作業日の予期せぬ状況により、配達車両がいつもより遅くストップＡに到着することがある。配達車両は午前９：００にストップＡに到着するので、保証したサービスレベルを満足させるためには、単に経路を変更するだけでよい。
【００２４】
上記の例は、解決策がサービス保証を果たすための最初の配送計画の動的変更という、簡単な問題を説明している。比較的簡単な問題に関しては、経路に精通している経験豊富な運転手は、予想移動時間および当日の配送計画を使用して、自己発見的に解決策に到着することがある。上の説明では、サービスストップ数が限定され、小包数が限定され、１個の小包しかサービス保証されてなく、代替経路および所要の相対的作業単位についての情報が明らかにされている。しかし実際には、追加の制約がたいてい課される。例えば、多くの営業施設が、配達を一定の時刻に限定する。昼食時に客に料理を提供するレストランの多くは、従業員に午前１１：００から午後２：００まで顧客に料理を提供することを命じ、この時間帯中に配達を受け取らない。従って、あるストップには、配達をしてはならない一定の時間帯があることがある。他の場合には、荷受人は、一定の時間帯での配達／集配を好むことがあるが、翌営業日にその作業を延期するよりは、別時刻の配達／集配を受け入れるであろう。他にも多くの制約および例外的な状況が起こることがある。
【００２５】
配送計画の配達要件が首尾よく満たされるかどうか、配送計画の修正が必要かどうかの判定にかかわる多くの要因があることは明らかである。さらに、未熟なサービス要員かそれとも特定の経路に精通していない代用運転手がかかわる配送計画では、配達要件が容易に見落とされることがあることも明らかである。配送計画の実行に影響を及ぼす別の要因は、配送計画の完了またはサービス保証時刻に対して、予想外の出来事が何時発生するかである。計画の実行がほぼ完了している場合（例えば、残り２ストップ）、配送計画への影響および／または修正を判定することは、重要ではないこともある。それに対して、配送計画の実行が始まったばかりの場合（例えば、１２０ストップが残っている）、影響の分析および計画の修正は、はるかに複雑になる。
【００２６】
上記の例では、計画の最も効率的な実行でないにしても、所与の日に対する計画サービスストップ数は静的である。例えば、小包集配の可能性のあるサービス拠点における１つの方法は、集配が起こる可能性がある各営業施設にサービス車両をストップさせることである。これは決定論的な計画であり、計画スケジュールを容易にするのに対して、拠点で受け取る小包がなく、ストップを正当化する小包配達の予定もない場合は非効率的である。この場合、不必要なサービスストップが発生したことになる。ストップが必要かどうかを示す視覚インジケータを、運転手が見えるように置くなどのその場その場の解決策の中には、必ずしも実用性、信頼性、また効率性があるといえないものがある。
【００２７】
今では多くの顧客が、集配される小包に関連する積荷情報を伝達する出荷システムを使用しており、運送業者が小包の集配が必要かどうか、および小包に関する小包レベル詳細（ＰＬＤ）を前もって知ることができる。出荷システムの使用は小包の集配を容易にする。運送業者は、集配がいつ必要かを知り、サービス車両は、小包が実際に待っている拠点でだけ小包集配のためのストップが必要となるからである。その出荷システムの１つは、ヨーロッパ特許第０８２９０５７号明細書「発明の名称：Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｐｒｅｐａｒｉｎｇ Ａｎ Ｅｌｅｃｔｒｏｎｉｃ Ｒｅｃｏｒｄｓ Ｆｏｒ Ｓｈｉｐｐｉｎｇ Ａ Ｐａｒｃｅｌ（小包を配送するための電子レコードを準備する方法およびシステム）」に開示されている。
【００２８】
サービス要員が携帯するまたは配達車両に搭載されたポータブルコンピュータ（例えば、ＤＩＡＤ）との無線通信と併せて、その出荷システムを使用することにより、配達車両が当日の配達に出発した後であっても、小包集配に関する配送計画の更新が遠隔から可能になる。例えば、図２を参照して、出荷システム（２０１）は、パーソナルコンピュータ（２００）とそれにローカル接続したプリンタ（２０２）とを備えてもよく、それにより、顧客は、出荷データの入力および集配小包（２０４）用のラベルの印刷が可能になる。コンピュータ（２００）は、インターネットや他のよく知られている通信ネットワークなどの通信ネットワーク（２０６）に接続されており、それにより、小包集配要求を中央配送システム（ｃｅｎｔｒａｌ ｄｉｓｐａｔｃｈ ｓｙｓｔｅｍ）（２０８）に送信することが可能になる。中央配送システム（２０８）は、サービスストップの地理的基点を判定し、各車両のサービス担当地域および／または現在位置に基づき、数台の配達車両（２１６、２１８）の中から１台を選択する。図２で、中央配送システム（２０８）は、車両Ａ（２１６）が最適の車両であると決定する。無線通信サービス（２１０）の使用により、アンテナ（２１２）から車両の運転手が持ち運ぶ適切なＤＩＡＤに無線メッセージが送信される。中央配送システム（２０８）は、集配場所と各配達車両のサービス地域の地図とを比較することにより、あるいは各ＤＩＡＤの正確な位置を問い合わせることにより、適切な車両を決定してもよい。集配場所は、出荷システム（２００）が示す所在地住所により特定されるのが好ましいが、他の方法が使用されてもよい。例えば、顧客が、顧客サービスエージェント（図に示されていない）に電話で依頼する場合、発呼者の発信者番号が地理的位置を決定するために使用されてもよく、その地理的位置は、次いで適切な配達車両を決定するために地図と比較されてもよい。代わりに、顧客サービスエージェントは、配送コンピュータ（２０８）に住所を提供するコンピュータを使用して、集配場所を入力してもよい。従って、このシナリオでは、予定サービスストップ数は、最初の配送計画が実行されている時間中、増加または減少してもよい。
【００２９】
様々な実施形態において、ポータブルコンピュータは、車両運転手が持ち運んでもよいし、また車両に搭載されてもよい。従って、本明細書に記述する集配をスケジュールするためのサービス車両へのメッセージの送信は、ＤＩＡＤのようなデバイスを使用することに必ずしも限定されない。つまり、コンピュータは車載されてもよい。他の実施形態では、協調して動作するポータブルコンピュータと車載ユニットの両方を使用してもよい。従って、中央配送システムから配達車両にメッセージが送信されると本明細書に記述するとき、情報は、実際には、配達車両の運転手が持ち運ぶポータブルコンピュータに伝達されてもよい。従って、様々な前後関係において本明細書を解釈するには、融通性が必要なこともある。例えば、車両位置が記録または報告される場合、運転手が身に着けて持ち運ぶＤＩＡＤ内のＧＰＳデバイスは、車両の位置を近似するのに十分であると想定してもよい。同様に、運転手が持ち運ぶＤＩＡＤのようなポータブルコンピュータにメッセージが送信されるとの記述は、車載のコンピュータを使用する実施形態を排除しない。
【００３０】
また、派遣される車両は、通常、「配達車両」、「サービス車両」、「小包配達車両」と呼ぶが、この用語は、自動車ベースの車両に限定されると見なすべきではないし、配達のためだけに使用される車両と見なすべきでもない。それどころか、これらの用語は、サービスの実行をやり遂げるあらゆる種類の品物運搬手段に適応可能であると見なしてもよい。従って、これには、建物の調査、デバイスの修理若しくは取替え等の要員を運ぶことができる飛行機、船、列車、バス、ライトバン、トラック、オートバイ、トレーラトラック等が含まれるであろう。
【００３１】
無線通信は、いくつかの派遣サービスによって使用されているプライベート・ポイント・ツー・ポイント移動無線に基づいてもよいし、また、周知のデジタルセルラ、デジタルデータ、若しくは衛星ベースの通信サービス（ＥＤＧＥ、ＧＰＲＳ、ＣＤＭＡ２０００ １ｘ−ＲＴＴ、ショートメッセージサービス、ＭＭＤＳ、他の種類の３Ｇデータサービス等を含むが、それに限定されない）などの公衆通信事業者の無線サービスに基づいてもよい。本発明は、様々な方式の無線通信技術に基づいてもよい。詳細情報は、引用により組み込まれた前述の特許出願に見つけられることもある。
【００３２】
無線通信のフォーマットは変わってもよく、図１５に使用してもよい代表的な１プロトコル構造を示す。図１５に示されている、プロトコルデータユニット（ＰＤＵ）は、デジタル情報を運ぶ代表的なフォーマットである。ＰＤＵは、通常、通信の特定のレイヤに関係し、通常、ヘッダ（２２１）、ペイロード（２２２）、トレーラ（２２３）を備える。物理レイヤプロトコルデータユニット（２２０）は、特定の無線変調プロトコルを使用して情報を運ぶ。物理レイヤＰＤＵは、リンクレイヤＰＤＵ（通常はリンクレイヤとメディアアクセスコントロール（「ＭＡＣ」）レイヤとの複合）（２２４）を運び、リンクレイヤＰＤＵ（２２４）は、同様にネットワークレイヤ・プロトコルデータユニット（２２６）を運ぶ。これらのそれぞれは、ヘッダ、ペイロードおよびトレーラからなる同様のフォーマットを有し、無線通信業界では、様々な種類のフォーマットが広く知られている。最後に、アプリケーションレイヤＰＤＵ（２２８）が運ばれる（他のプロトコルレイヤが介在してもよい）。アプリケーションレイヤＰＤＵは、配送計画に関するデータ、またはポータブルコンピュータデバイス（例えば、ＤＩＡＤ）と中央配送システムとの間で交換される他の情報を転送する。アプリケーションレイヤＰＤＵのフォーマットは、独自仕様であってもよい。図１５に示すフィールドは、配送計画に関連するレコード（２２９）、および実行すべき活動を示すインジケータ（２３０）を運ぶ。例えば、追加のレコードが配送計画に加えられる場合（例えば、小包集配のための別のサービスストップを示す）、追加のレコードは、何の動作を実行すべきかのインジケータ（例えば、「レコードの追加」）と一緒に、アプリケーションレイヤＰＤＵにより運ばれてもよい。レコードの修正、レコードの削除などの、別のフィールドと機能が規定されてもよい。プロトコルおよびサービス設計の業者なら、ポータブルコンピューティングデバイスと配送サーバとの間で、情報および機能呼び出しを伝達することができる様々な方法を容易に特定するであろう。通常、既存の通信プロトコルが下位レイヤで使用されてもよい。一方、アプリケーション固有のプロトコルは、配送計画関連情報を運ぶように容易に設計されることがある。
【００３３】
小包集配を伝える通信は、出荷システムや中央配送システム以外のエンティティを含んでもよい。図２に、インテリジェント小包ポスト（ｐａｒｃｅｌ ｄｅｐｏｓｉｔ ｂｏｘ）（２１４）を開示する。この種の小包ポストにより、顧客は、小包を発送する営業施設での配達車両のストップを要求することなく、集配用の小包を預けることが可能になる。ポストは、サービス車両が通常移動する経路に沿った、便利で目に付く場所に通常置かれる。インテリジェント小包ポスト（２１４）は、小包が預けられたときにそれを検出する適切なセンサを有し、無線通信システム（２１０）を使用して中央配送システム（２０８）に無線で通知してもよい。同様に、中央配送システム（２０８）は、サービスストップが必要なとき、小包ポストのサービスを担当する適切な車両を決定し、その車両に通知してもよい。図２で、車両Ｂ（２１８）は、小包ポストに立ち寄り、小包を集配するように通知を受ける。このスキームにより、小包ポストが実際には空のときに、小包を収容しているかどうかを判定するために、運転手が小包ポストに立ち寄る必要性がなくなる。
【００３４】
配達期間中に追加の小包が車両に割り当てられることとなる状況に関係なく、中央配送システムは、各配達車両の現在のサービス担当地域と関連して、集配の地理的位置に基づき、または場所、作業量若しくは車両に関する他の要因を考慮して、どの配達車両が要求を担当するのに最適かに基づき、小包を取り扱う車両を選択してもよい。例えば、図２では、小包（２０４）がある地理的地域を車両Ａ（２１６）が担当しているので、車両Ａ（２１６）が選択されてもよい。あるいは、車両Ａが２番目に近い車両であっても、車両Ｂが小包集配を割り当てられた場合に達成が困難になる配達時間保証を有しているときは、車両Ａが選択されてもよい。対象車両がどのように選択されるかにかかわらず、中央配送システム（２０８）は、適切な派遣車両に更新情報を無線送信する。
【００３５】
実際には、他の種類の情報も、配送計画の実行および配達時間保証の達成に影響を及ぼすことがある。配送計画の将来の実行達成を妨げる潜在的な影響を判定することは、「危機」、「危機状況」、「サービス保証危機」または「スケジュール危機」と呼んでもよい（他の同様な用語を使用してもよい）。危機状況であると判定した場合、ポータブルコンピューティングデバイスのプロセッサは、実行すべき残りのサービスストップを分析し、保証を満足するために残りのサービスストップを最適化する再順序付けが適切かどうかを判定してもよい。前述のように、すでに実行したサービスストップに関しては、検討の必要はない。配送スケジュールに影響を及ぼし、最初の配送計画の更新のきっかけとなる、よくある種類の入力を以下に記述する。
【００３６】
［積荷目録および配送計画］
積荷目録（ｍａｎｉｆｅｓｔ）は、通常、配達すべき積荷のリストと定義される。この実施形態では、積荷は配達用の小包を含む。しかし、本発明の原理は、小包、手紙、部品、手荷物等を含む他の種類の品物の配達にも適用できる。また、本発明は、所定の場所に派遣されるサービス要員が行うサービス（ｒｅｎｄｉｎｇ ｓｅｒｖｉｃｅｓ）に適用してもよい。従って、「積荷目録」を配達される品目の観点から検討するが、他の状況では、用語「積荷目録（ｍａｎｉｆｅｓｔ）」は、実行すべき作業活動のリストと広く解釈できよう。積荷目録は、通常、「配達積荷目録」すなわち配達用小包のリストであり、通常、小包についての関連情報を含む。しかし、積荷目録は、集配すべき小包の情報も含んでもよい。この状況は、積荷目録を「集配積荷目録」と記述することで区別してもよい。本明細書中で限定なしで使用するとき、積荷目録は、集配、配達または必要な他の特定の活動のいずれかで予定される商品に関する情報を有すると、広く解釈してもよい。
【００３７】
積荷目録が作業を実行する順番を表して配列される場合、配送計画（Ｄｉｓｐａｔｃｈ Ｐｌａｎ）と呼んでもよい。あるいは、配送計画は、積荷目録から導き出した別の情報セットであってもよい。一般に、配送計画は、積荷目録を順序付けした系列と概念的に考えられるが、後で示すように、データベースを使用して積荷目録および配送計画を格納および体系化する種々の方法があり、データの論理的な表現は、一定の実施またはデータ構造を必要とするとは解釈されない。
【００３８】
［配達積荷目録更新］
通常、小包配達車両は、小包中央仕分け施設で当日配達用の小包を積み込み、経路に出発する。運転手は、配達、集配または他のサービス関連情報についての情報を含み、ＤＩＡＤにダウンロードされた配送計画（この場合もやはり、配送計画は積荷目録の順序付けした系列と見なしてもよい）のコピーを提供される。配送計画情報は、通常、荷受人（宛先住所）および関連する小包サービスレベルおよび／または配達保証時刻（配達時間保証）を含む。サービスストップ、配達または他のサービス活動に関連する情報の各グループは、データベースのレコードと見なしてもよい。従って、配送計画は、一連のレコードを備えると見なしてもよい。また、各レコードは、例えば、一定の配達時間帯、場所の案内、好ましい配達場所、出荷事務員名等の顧客固有の要件に関する追加情報を含んでもよい。他の実施形態では、配送計画の更新は、運送業者と提携している取扱店などの代替場所に小包の宛先変更という顧客要望を反映してもよい。関連情報は、同時継続出願で、２００３年１２月２２日に出願の米国特許出願第１０／７４５，４６８号、「発明の名称：Ｍａｎｉｆｅｓｔ Ｇｅｎｅｒａｔｉｏｎ ａｎｄ Ｄｏｗｎｌｏａｄ Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ（積荷目録生成およびダウンロードシステムならびに方法）」、および２００２年８月２３日出願の米国特許出願第１０／２２７，１４７号、「発明の名称：Ｐｏｒｔａｂｌｅ Ｄａｔａ Ａｃｑｕｉｓｉｏｎ ａｎｄ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ ａｎｄ Ａｓｓｏｃｉａｔｅｄ Ｄｅｖｉｃｅ ａｎｄ Ｍｅｔｈｏｄ（携帯データ収集管理システムおよび関連装置ならびに方法）」に見つけることができる。それらの内容は、引用により本願に組み込まれる。
【００３９】
従来は、所与の日の作業活動用の積荷目録データまたは配送計画は、一旦運転手に提供されると、修正されなかった。しかし、図２を参照して検討したように、新技術は、車両が経路でのサービス開始後に、配送計画の更新を可能にする。配送計画の遠隔更新に加えて、配送計画情報は、運転手または他のローカルコンピューティングデバイスによりローカルで修正されてもよい。例えば、第２の積み込み場所にストップし、配達用の追加の小包を受け取った運転手により、配達用の追加の品物が追加されてもよい。情報は、手入力されてもよいし、またポイント・ツー・ポイント接続の別のローカルコンピュータまたはＤＩＡＤから受信されてもよい。配達車両のスペースに、配達車両への１回の積み込みで１日分の全配達物を運ぶことができないような制限がある場合、第２の積み込み場所を使用することは役に立つ。あるいは、車両は、第２の配達車両から小包を移し変えることにより、途中で小包を受け取ってもよい。第２の配達車両が故障し小包の積み下ろしが必要な場合、または２台の車両間の負荷を均等にするために小包を移し変えるとき、これは発生することがある。そのような状況は、季節的なある種の出荷のピーク時によく起こる（例えば、休暇時期の配達）。
【００４０】
［集配配送計画更新］
集配配送計画は、集配を行うべき順番を表わすように順序付けられている、集配するべき品目の積荷目録と見なしてもよい。一旦順序付けられると、集配積荷目録は集配配送計画と見なしてもよい。集配配送計画は、前述の無線通信方法の使用を含む幾つかの方法で修正されてもよい。集配配送計画の修正の中には、再検討の必要性が生じ、場合によってはサービスストップの順番を変更する場合があるのに対して、配送計画の修正の中には順番を変更しない場合もある。その後の配達の順番を変更しない積荷目録の変更の一例は、顧客が、集配される小包のサービスクラスを変更するときである。例えば、小包集配は元々２日配達サービスクラスと示されていたが、サービスクラスが通常の陸輸送に変更されると想定する。中央仕分け施設における小包のその後の取り扱いは変更されることもあるが、小包を集配する車両の配送計画は、通常、サービスレベルの変更によって影響を受けない。配達車両は、依然として小包を集配すべき場所でサービスストップしなければならず、その後の集配の順番を変更する必要はない。
【００４１】
配送計画の達成または実行に影響を及ぼさない変更、すなわち、その後のサービスストップのスケジュールに悪影響がない配送計画の変更には、他の例もある。例えば、顧客による小包集配の取り消しは、車両がその場所にストップする必要がなくなることがある（その場所への配達はないと想定する）という点で配送計画を変更するが、この種の変更は、運転手に追加の時間要件を課さない。同様に、集配する小包数の減少は、追加の時間要件を課さない。どちらかと言えば、そのような変更は、元のスケジュールと比較してスケジュールの実行を前倒しにする。
【００４２】
しかし、集配配送計画の他の変更は、その後の作業活動に影響を及ぼすことがある。例えば、顧客が集配用の小包数を増加する場合、特に大幅に増加する場合、運転手が必要とする追加の時間は、当日の残りの作業のスケジュールに影響を及ぼすことがある。また、車両への追加の小包の積み込みは、スペースの問題を生じ、小包の整理に影響を及ぼし、かつその後の配達で他の小包を仕分けし見つけるために、運転手が必要とする時間を増すことがある。
【００４３】
集配配送計画に起こり得る別の修正は、前もって予定されていない場所での集配を加えることである。ポータブルコンピュータにダウンロードされた配送計画に盛り込まれるべき情報に関して、顧客が集配用の小包を準備するのが間に合わなかったときによく起こる状況を、これは反映する。しかし、その情報は、サービス車両の出発後、前述の無線通信を使用してＤＩＡＤに提供されてもよい。これは、小包を集配するために作業スケジュール（例えば、サービスストップのスケジュール）の変更を必要とする。この種の作業スケジュールの修正は、運転手に追加の時間を必要として、常に作業スケジュールに影響を及ぼす。しかし、集配に必要な追加時間は、配達の実施が既に予定されている場合、最小限で済む場合がある。運送業者によっては、配達を遅らせるのを避け、且つ集配する小包のために車両スペースを作るために、配達後に集配を行うように段取りするところもある。
【００４４】
［種々の出来事］
最後に、サービスストップのスケジュールに影響を及ぼす可能性のある他の不測の要因がある。例えば、集配を行った後で運転手は、小包を顧客に返さなければならないと気が付くことがある（例えば、破損している、包装またはラベルが不適切である、有害な液体が漏れている等）。このことは、小包の返却または特別の取り扱いを反映するために、運転手が集配積荷目録の修正をすることを必要とすることがある。商品配達の経験が豊富な者であれば、配送計画の他の種類の例外および修正が起こり得ることをおそらく了解するであろう。
【００４５】
［天候更新］
気象状態は、通常、配送計画の実行に影響を及ぼす。暴風雨または吹雪などの荒れ模様の天候は、一般に交通を妨げ、スケジュールを遅らせると予想され得る。天気予報は周知の科学ではあるが、配達経路に沿った当日の以降の天候が正確にどうなるかを始業時に予測するほどには、特定の場所の予報はまだ十分に信頼できない。予想外の厳しい気象状態は、経路の一部に影響を及ぼし、サービス車両の配達スケジュールに悪影響を及ぼすことがある。従って、天候は、当日の配達の開始後、配達計画のスケジュールに影響を及ぼすもう1つの状況である。
【００４６】
［交通状況］
交通状況は通常予測が困難であり、たいてい起こったことに反応する方法で報告される。これには、事故の発生、渋滞、道路建設等が含まれ、そのすべてが交通に影響を及ぼす。経験豊富な配達車両運転手は、標準的な交通量および交通状況のプロファイルを自己学習的に作り上げることがあるが、異常状況は常に起こり得る。よく起こる１つの出来事は、道路の閉鎖である（例えば、建設、緊急道路修理、天候が原因の倒木、道路冠水等）。多くの場合、運転手は、その場その場の通信（例えば、ラジオ速報、個人的な電話の呼び出し等）を受信してもよく、配送計画の経路を修正するために個人的知識を役立ててもよい。配達時間保証が存在する場合は、予想配達時刻を見直しするのが適切である。
【００４７】
［他の状況］
他の様々な状況および出来事が、配送計画の実行に関して配達車両のスケジュールに影響を及ぼすことがある。各状況は、必ずしもサービス配達時間保証を達成する能力に悪影響を及ぼさない。悪影響が発生するかどうかは、配送計画に関して状況の深刻さの見積りを必要とする。
【００４８】
［プロセス概観−主要構成要素］
図３は、配送計画を更新するために使用される高レベルプロセスの一実施形態を示す。明らかとなることだが、プロセスの変形形態でも、依然として本発明の原理を具現することは可能である。
【００４９】
図３で、積荷目録データ（２０）は、配達車両に関する所与の作業日の配達データを表す。積荷目録データは、小包配達および集配の両方に関する情報を含む。積荷目録データは、配達用のファイルと集配関連データ用の別ファイルの、２つの個別ファイルとして実装されてもよいし、また１つのファイルとして実装されてもよい。他の実施形態では、積荷目録データは、サービス訪問を含む他のデータ、またはサービスストップに関する他のデータを有してもよい。この段階では、積荷目録データ内のレコードの順番は重要でない。一旦順序付けられると、積荷目録データは、配送計画と見なしてもよい。
【００５０】
積荷目録データを表すデータベースファイルの説明用のフォーマットを図９に示す。図９では、積荷目録データテーブル（１３１）は、数行すなわち数レコードからなる情報を有する。各レコードは、サービスストップに関する情報の、互いに独立した収集物と見なしてもよい。レコードが、サービスストップの実行を容易にする特定の順番に並べられているので、テーブルは、配送計画と見なしてもよい。
【００５１】
各レコードの収集情報は、数列すなわち数フィールドの情報を備える。通常、積荷目録には、もっと多くのフィールドの情報が含まれるが、図９では、ほんのわずかのフィールドだけを示す。例えば、名称、通り、市等はすべて個別のフィールドであってもよい。他のフォーマット、順番および各フィールドの構造も可能である。１列目は、小包識別子であり、小包問い合わせ番号（１３６）を提供することが示されている。テーブル（１３１）で、配達すべき各小包は、問い合わせ番号または他のある種の小包識別子により特定され、この識別子は、テーブルのインデックスとして使用される。他の実施形態では、テーブルは、他の種類のサービスに関連するサービスストップを表してもよく、最初の列は、作業順序番号を表してもよい。代わりに、住所がインデックスとして使用されてもよい。しかし、テーブル（１３１）は、代表的な実施形態として小包配達サービスに基づき、本発明の原理を説明するのに十分である。
【００５２】
次に、荷受人または荷送人の住所情報を（１３７）に示す。小包が配達に関する場合、荷受人住所（宛先）が提供される。小包が集配される場合、住所は荷送人（小包の発送人）を示す。次の列は、ストップに関する小包番号（１３８）を示し、１つのサービスストップにおける複数の小包間の連結を可能にする。例えば、配達は、幾つかの小包を含んでもよく、連結は、通常、所与のストップに関する全小包間で行われる。これにより、配達要員は、配達が必要な小包すべてを確実に配達できる。テーブル（１３１）に提示する例では、Ｐｅｒｒｙ漬物店のサービスストップに関連する２個の小包（１５４ａ、１５４ｂ）がある。次の列（１３９）は、ストップが集配かそれとも配達かを示す（Ｐｅｒｒｙ漬物店の例では、２個の小包が配達される）。他の場合には、サービスストップは、配達と集配の両方を含むこともある。最後に、もう１つの列は、示されている場合、小包に関する配達保証時刻を提供する。図９の例では、Ｐｅｒｒｙ漬物店に配達される小包の１個は、配達保証時刻午後４：００（１３５）を有する。
【００５３】
多くのフォーマットおよびファイル構造の変形形態が可能であるが、図９には、本発明の例示目的で一実施形態だけを示す。例として、配達と集配とを論理的に分割したファイルが実装されてもよい。また、個別の論理的順番インジケータファイルが、サービスストップの順番を示すために、積荷目録データと併せて使用されてもよい。その順番は、積荷目録の住所情報により定められるであろう。また、追加情報は、通常、サービスレベル、発送人情報、小包を取り扱う内部仕分け施設、重量などの各小包に関する。本発明の原理を示すためには、配送計画または積荷目録に収容可能な全情報を示す必要はない。また、ＰＬＤ情報の中には次のサービスストップを効果的に特定するために必要でない情報があるので、配送計画の作成に積荷目録情報のサブセットを使用することは可能である。
【００５４】
図３に戻って、図示の別の構成要素は経路計画（２２）である。図３の経路計画（２２）は、配達車両が移動する経路に関する情報を備える。通常、経路は、事前に決定された地理的地域内に限定され、特定の順番で移動する道路のセットを備える。道路の領域はたいてい地理的に限定される（例えば、配達地域は町、郡または州の限定された区画内に境界が定められる）。これは、サービス車両の派遣に確定したサービス担当地域が使用されるときの、典型的な状況である。他の実施形態では、地理的地域は非常に大きくてもよく（例えば、州または国の区画）、論理的に無制限または際限がないと見なしてもよい。例えば、引越しサービスは、米国本土でサービスを提供してもよい。このサービス担当地域の制限はないと見なしてもよいが、実際は限定されている。状況によっては、制限のないサービス担当地域は、定まった移動経路を持たない地域と見なしてもよい。
【００５５】
本明細書で提供する実施形態では、経路計画はいくぶん静的である。すなわち、経路は、配達が頻繁に行われ、定期的に移動に使用されるパスを反映する（しかし、必ずしも、あらゆる道路のあらゆるストップではない）。静的な経路に加えて、ビジネスの状況では、配達は一般に同じ時刻に行われるのが望ましい。例えば、小包の収集と配達は、所与の場所で毎日ほぼ同時刻に行われるように計画されてもよい。他の状況では、サービスストップは何時に行われてもよい。例えば、小包配達サービスではなく、修理サービスに関してサービス車両を派遣する場合、配送計画のストップの順番を決定するために、サービス訪問の優先度が使用される。通常、修理車両の派遣は、以前のサービス訪問に関する修理車両のその場所への到着時刻の実績には基づかない。他の状況では、営業施設への配達は、従業員が他の活動を調整できるように（例えば、営業施設で配達物を受け取る従業員が休憩時間をいつ取るべきか（またはある時刻に休憩を取るのを避けるべきか）わかる）通例の時間フレームで行う、あるいはその反対に、簡単に中断できない仕事が始まる時刻を避けることが望ましいことがある。
【００５６】
経路計画（２２）は、所与の地域で配達を実行する１台の車両に対するものでよいし、また車両のグループを考慮してもよい。実施形態によっては、顧客に特定の順番でまたは通例の時刻に配達物を受け取りたいという好みがないとき、動的経路計画が使用されてもよい。経路計画は、実績平均、好ましい配達時刻などの他のデータと関係なく、積荷目録データにより部分的には決定されてもよい。
【００５７】
経路計画（２２）は、種々の方法で表されてもよく、部分的にはどのようにデータが操作され提示されるかに依存する。場合によっては、ＧＩＳ（地理情報システム）ベースのシステムが利用されてもよい。他の実装は、配達ストップのテーブルリストを提供してもよい。経路計画は、実際の配達計画（例えば、配送計画）ではなく、最初の配送計画を作成するために使用される参照モデルなので、必ずしもポータブルコンピュータに組み込まれなくてもよいし、運転手に提示されなくてもよい。
【００５８】
経路計画を概念的に説明するために、図８は、潜在的なサービスストップのテーブルリストに基づく一実施形態を示す。図８では、経路計画データ（１１７）は、一連の住所を備える。図８は、メインストリートにある商店に対応するレコードのサブセットを示す。各レコードは、小包配達かそれとも小包集配のための潜在的なストップを表す。住所（１１１）は、レコード番号（１１６）と呼ばれるインデックスに関連し、そのレコード番号は選択した住所の処理を容易にする。経路計画の住所は、通常、所望の配達計画に相当する順番で記載されているのが好ましい。例えば、テーブル（１１７）によれば、Ｎｅｉｌｌ新聞販売店（レコード（４３６））はＭｅｒｅｄｉｔｈ食堂（レコード（４３７））の前に記載されているので、両方の場所に配達が行われた場合、Ｎｅｉｌｌ新聞販売店への配達がまず行われるであろう。
【００５９】
この実施形態は、多数のレコードを格納することになり、各レコードは、所与の日の実際のサービスストップではなく、潜在的なサービスストップを表す。他の実施形態は、一連の住所の範囲で経路を表してもよい。これは、格納スペースを節約し、見易い形式でデータの提示を可能にする。このデータは、ポータブルコンピュータから切り離して格納され処理されてもよいので、メモリ要件、処理スピード等はポータブルコンピュータに関する要因ではない。従って、経路計画の住所は、個別の所在地および居住者名の記載なしに、範囲で表されてもよい（例えば、「メインストリート１００〜３００」）。この方法は、新しい居住者がその住所に関連するときに毎回データを更新しなければならないということを回避することができる（例えば、居住者の所在地からの引っ越し／所在地への引っ越し、または商店の移転、開店若しくは閉店）。
【００６０】
要約すれば、図３における経路計画は、配達車両が取る一般的経路を示すのに対して、積荷目録データは、所要のサービスストップに関するデータを示す。積荷目録データは、必ずしもサービスストップへ配達する所望の順番を反映して編成または論理的に順序付けられていないので、当初すなわち最初の配送計画（２４）を作成するためには、データを順序付ける形態の追加処理（２５）が必要である。図３の最初の配送計画（２４）は、配達車両の運転手が実行するサービスストップを順序付けしたリストである。概念的に、配送計画を作成する処理（２５）は、経路データに基づき配達場所の逐次的順番を反映するように、積荷目録データを単に処理（２５）するものであってもよい。
【００６１】
最初の配送計画（２４）を作成するために、様々な方法が可能である。配送計画は、様々な配送業者が長年にわたり使用しており、本発明の範囲外である。配送計画は当業者には周知であり、いくつもある有名な配送ソフトウェアアプリケーションにより作成されてもよい。ソフトウェアアプリケーションの中には、ＲＯＡＤＮＥＴ５０００ＴＭ、Ｔｅｒｒｉｔｏｒｙ ＰｌａｎｎｅｒＴＭ、およびＭｏｂｉｌｅｃａｓｔＴＭがある。最初の配送計画（２４）は、ポータブルコンピュータにダウンロードされ、グラフィック、テーブル（例えば、テキスト指向の）、または両方を含む様々な方法で構造化されてもよい。最初の配送計画のデータを積荷目録データおよび／または経路計画データと同様に構造化すると、効率的なこともあるが、これは、本発明の原理から恩恵を得るためには必須ではない。
【００６２】
図３は、ポータブルコンピューティングデバイスが処理（２９）してもよい様々な更新／入力（２６）も示す。更新／入力（２６）は、最初の配送計画の更新または修正を開始させ、ひいては更新配送計画（２７）を作成する。更新／入力（２６）は、気象情報、交通情報および積荷目録変更を含む前述の入力を含む。ポータブルコンピュータによる入力の処理（２９）は、更新／入力が最初の配送計画の残りの配達に影響を及ぼすことがあるかどうかをまず判定することを含む。すべての入力がその後の配達に影響を及ぼすわけではなく、影響があるかどうかを判定するために、様々な方法およびデータが使用されてもよい。
【００６３】
例えば、処理（２９）は、実績データ（２８）を収容するファイルにアクセスしてもよい。実績データは、最初の配送計画を更新するかどうか、およびどのように更新するかを判定する補助材料として使用してもよい参照データである。その実績データは、経路計画（２２）を決定するために使用される個別プロセス（図示せず）で使用される実績データのサブセットであってもよい。ポータブルコンピュータに格納された実績データ（２８）は、１台のサービス車両のサービス担当地域にだけ限定される必要がある。実績データの内容は、業務アプリケーション、メモリ要件、および分析される入力の種類に基づき変わってもよい。例えば、実績データは、当日の積荷目録の完了したサービスストップ（例えば、完了した配達または集配）を示してもよい。運転手が既に完了した配達は、天候または交通などのその後の展開によって影響されないので、更新配送計画を作成するために分析されなければならないのは、配送計画内の残っている配達だけである。図３が実績データと積荷目録データとを別に図解しているのは、概念的な目的だけであり、実績データがどのように格納されるかを限定する意図はない。実施形態によっては、どの配達／集配が完了したかの表示は、積荷目録データまたは配送計画と併せて格納される。従って、概念的に、実績データのこの部分は、配送計画の拡大と見なしてもよい。通常、配送計画内のサービスストップ完了フラグは、サービスストップが完了したことを示して記録される。どのように表示が記録されるかにかかわらず、過去の配達を表示するデータは実績データとしてモデル化してもよい。
【００６４】
実績データ（２８）は、他の種類の実績データを備えてもよい。実績データは、潜在的な配達ストップのそれぞれに関する時刻および所在地情報の移動平均実績を備えてもよい。この種の情報は、現在の状態を比較することができる参照項目の役割を果たす。
【００６５】
実績データのこの側面は、配送計画の実行がスケジュールどおりか、それともスケジュールより遅れているかを判定する基準を提供するために使用される過去の配達情報を蓄積することにより、運転手の「経験」の側面をある程度捉える。スケジュールより遅れている場合、最初の配送計画内の残りの配達を修正（例えば、再最適化）する必要がある場合がある。例えば、ある経路に経験豊富な運転手は、既知の目印の場所と現在時刻とを比較し、これらの目印に出会ったときの過去の経験とを頭の中で比較することにより、１日を通して実施状況を評価する。あるいは、現在の時刻と所要の仕事の進捗状況とを比較してもよい。所与の経路の過去の平均時刻および場所の測定結果に対して配達車両の現在時刻および場所を比較することにより、相当の「経験」がシステムに組み込まれてもよく、それにより、スケジュール進捗状況（「進んでいる」、「遅れている」または「スケジュールどおり」）の判定と、残りのサービスストップの完了に必要な時間とを決定できる。
【００６６】
更新配送計画（２７）を作成する処理（２９）は、最初の配送計画（２４）を作成するために使用される処理（２５）とは、通常は同じではない（それ故、処理アイコン（２５）と（２９）は、別に表示してある）。最初の配送計画の処理は、メインフレームで行われてもよく、複合サービス担当地域内の車両グループに対する小包配達情報の処理を含む。更新配送計画の処理は、その性質から、当初の配送計画の変更が適切かどうか、その変更をどのように行うべきかを判定するために、１つの既存の最初の配送計画のサブセット（例えば、まだ実行されていないストップ）に関して、特定の入力を処理する。前述のように、配送計画の更新または入力が、常に、残りのサービスストップの実行またはその順番に影響まで及ぼすというわけではない。サービスストップの順番の修正が必要である場合、個別のプロセスが、最初の配送計画を修正して、更新配送計画を作成してもよい。最初の配送計画を修正するプロセスは、最初の配送計画を確立するプロセスとは異なる。その異なる点は、新配送計画は、局部的な状態を考慮し、前に決定された特定の配送計画に関する配達時間保証を果たすように、１台の配達車両に関して作成されることである。また、最初の配送計画の修正は、通常、少なくとも一部は実績データ（例えば、既に配達した小包）を考慮に入れるのに対して、最初の配送計画は、まだ配達されていない小包のリストから始まる。従って、状況が最初の配送計画の更新を正当化する場合、更新配送計画の算定は、最初の配送計画の算定に使用されたプロセスとは異なるプロセスを使用して通常は算定される。
【００６７】
最初の配送計画のデータ構造と更新配送計画のデータ構造とは、通常はよく似ている。このことは、データの処理およびユーザへの提示（最初の配送計画または更新配送計画のどちらか）を容易にする。以下に検討するように、ユーザに配送計画を提示するフォーマットは、様々な形式であってもよい。
【００６８】
最初の配送計画の更新は、様々な方法で行われてもよい。更新には、レコード情報の変更、レコードの追加、レコードの論理的順番の再順序付け等を含んでもよい。場合によっては、最初の配送計画の更新は、再最適化（例えば、ストップの再順序付けのための順番の分析）を必要としない。配送計画の実行に悪影響を及ぼさない様々な種類の積荷目録更新があることを想起されたい。他の場合には、更新は配送計画の実行に影響を及ぼすこともあるが、順番の分析を正当化しないこともある。例えば、ある通り上の既存のストップと同じ通り上の直ぐ手前に新しいサービスストップを単に追加するだけであれば、再順序付けすべきかどうかを判定するための、レコードの順番の分析を正当化することはないであろう。しかし、異なる道路上に新ストップを追加することは、最適化が妥当かどうかを判定するために、レコードの順番の分析を正当化してもよい。また、最初の配送計画を更新するかどうか、およびどのように更新すべきかを判定するために、例えば業務規定などの異なる基準を適用してもよい。例えば、予定外のストップを追加することにより配送計画が更新されるが、その後の配達保証時刻はないと想定する。従って、残りのサービスストップに関しては、どの時刻またはどの特定の順番で実行されるべきかの制約はない。業務規定は、最適化経路を反映するために残りのストップを再順序付けするようには、配送計画の分析を指示しなくてもよい。しかし、まだ実行されていないサービスストップの１つが時間保証を有する場合、残りのストップの分析および再順序付けは望ましい場合がある。
【００６９】
また、業務利用によっては、更新配送計画を決定するために使用される基準を規定してもよい。利用によっては、最適経路（例えば、移動距離）を必要としてもよいのに対して、他の業務利用では、移動距離が最適でない場合であっても、最初の配送計画からできるだけ逸れない経路の使用を選択してもよい。例えば、定期的にサービスストップをしている配達サービス会社は、最初の配送計画に関連する通常の予定到着時刻からできるだけ逸脱しないことを望んでもよい。これにより、配達車両はいつもと同様の時刻に配達を完了し、配達時刻帯に関して顧客の期待を維持することができる。このことは、小売店や商売をしている顧客などの小企業を担当するとき、重大である場合がある。従って、都市環境では、小さな小包配達サービス会社は、運転距離が少し長くなる場合でも、一定の交通パターンを避けるためかまたは配達時刻を維持するために、一定のスケジュールの維持を選択してもよい。５０マイルの都市経路で、運転距離が１０％増になる小さな逸脱は、５マイルの距離の追加になる。利用によっては、これは許容出来る場合がある。他方、全国的に配達サービスを提供するトラック運送会社は、元の予定配達時刻からより大きな逸脱を意味する場合であっても、最も効率的な配送計画の維持を選択してもよい。移動距離２０００マイルを伴う配送計画に関しては、運転距離１０％（例えば、２００マイル）増は、許容出来ない場合がある。さらに、トラック運送会社による所与の受取人への配達は、不定期である場合があり、荷受人は何時でも容易に配達を受け入れる場合がある。
【００７０】
要約すれば、業務規定は、レコードの再順序付けが必要かどうか、または望ましいかどうかを判定するとき、更新配送計画をどのように、ならびに何時検討するかに影響を及ぼす。本発明の原理は、更新配送計画を作成するために最初の配送計画をどのように／何時変更すべきかを判定する様々なアルゴリズムを網羅する。
【００７１】
図３のアイコン（２９）が表わす処理を具現するシステムを図４に示す。図４を参照して、配送マネージャ（ＤＭ）（４５）は、様々な入力を受け取るプロセスまたはソフトウェアモジュールであり、配送計画の更新が適切かどうかを判定する。ＤＭは、ユーザおよび他のプロセスから入力を受け取るのに加えて、ユーザに提示した情報も管理してよい。
【００７２】
ＤＭが受け取る入力の１つの種類には、ローカル入力（４６）を含む。ローカル入力は通常ユーザ入力であり、図４のシステムを内蔵するポータブルコンピュータ（例えば、ＰＤＡ、ラップトップまたは他のデバイス）のキーパッドから入力される。キーパッド入力は、「ソフトキー」の使用によりユーザが示す様々な機能を含んでもよい。ソフトキーは、操作状況によって機能を変更可能なキーであり、ディスプレイ情報と一般的なキーパッドとを関連付けることにより通常実装され、キーパッドの機能はディスプレイに示される。この方法で、キーパッドに関連する機能はプログラムで定めるように変更可能である。
【００７３】
他の形態の入力には、定評ある音声認識アルゴリズムの使用に基づく音声入力を含む。音声認識は、より便利な入力手段として、ユーザが頻繁に使用するコマンドに対して使用されてもよい。「ポインティングデバイス」（タッチパッド、マウス、ジョイスティック等を含む）の種類を通常使用する入力の選択は、データ入力の別の手段である。最後に、システムはセンサからも様々な入力を受け取ることができる。センサは、小包の配達に遅れをもたらしそうな配達車両に関する状態を検出してもよい。例えば、サービス車両のエンジン故障状態は報告されてもよく、ＤＭは、運転手または他のシステムに、配達遅延の可能性を警告するであろう。これらの入力は、無線または有線接続を介して受信されてもよい。
【００７４】
ＤＭは、遠隔入力（４７）に分類される入力も受信してもよい。遠隔入力は、無線通信インタフェースに関連するアンテナ（４８）を介して通常受信される。遠隔データ入力は、主として配送サービスからデータの受信を可能にし、追加のサービスストップの指示、特定の小包に対する所要配達時刻の変更、最新の交通状況および気象状態などで配送計画を修正する。
【００７５】
ＤＭは、ポータブルコンピューティングデバイスの現在位置をＤＭに提供するＧＰＳデバイス（３２）からも入力を受け取る（ポータブルコンピューティングデバイスは、サービス車両の場所を近似するために使用されてもよい）。この入力は、通常、経度および緯度の測定値の形態であり、継続的に更新され、周期的にＤＭに提供される。ＤＭは、現在時刻情報を提供する時計（３３）からも入力を受け取る。実施形態によっては、ＧＰＳデバイスは現在時刻情報を提供してもよい。
【００７６】
ＤＭは、現在位置と現在時刻を使用して、経路に沿った車両の位置と予定場所および時刻とを比べてもよい。これには、実績データ（例えば、過去の配達関連時刻および位置データを含む）の使用を伴い、それにより、ＤＭは、本日の配送計画の実行がスケジュールどおりか、スケジュールより遅れているか、またはスケジュールより進んでいるかの見込みを判定することが可能になる。この比較を実行するために、ＤＭは、実績配送位置および時刻データ（３６）を含む実績データを収容するデータベースにアクセスする。実績位置および時刻データは、様々な形態で格納されてもよく、所与の位置に関する標準的な時刻の移動平均を含んでもよい。
【００７７】
ＤＭは、様々なユーザの好み、オプションおよびデフォルト値を選択するために使用される、管理パラメータ（３４）の形態のデータにもアクセスしてもよい。これについてはさらに検討する。明らかになるように、処理の様々なオプションが可能であり、管理パラメータは、ユーザまたは特定のアプリケーション用にカスタマイズされたデフォルト値の選択を可能にする。例えば、都市環境では、道路地図を使用する配送計画のグラフィック描写は、不必要な場合もあるし、また望ましくない場合もある。それに対して、田舎の環境では、サービスストップを表す印を使用した道路地図の形態による配送計画のグラフィック描写は、望ましい場合がある。
【００７８】
ＤＭは、積荷目録データ・データベース（４０）（これは最初の配送計画として具現されてもよい）、配達完了データベース（４２）（これも最初の配送計画内に具現されてもよい）、および場合によってはＧＩＳ（地理情報システム）データベース（４３）にもアクセスする。前述のように、積荷目録データは、当日の小包配達および小包集配に関する情報を含み、配送計画を作成するために順序付けされてもよい。配達完了データは、完了した配達（または他の種類の作業活動）に関するデータを示し、実績データ（３６）、配送計画（３８）、または積荷目録データ（４０）内にも具現されてもよい。例えば、サービスストップを表す配送計画内の各レコードに関する完了インジケータまたは完了フラグの設定は、代表的な実施形態である。従って、図４は論理的種類のデータを図解するが、データの実施形態は、様々な形態で行われてもよい。例えば、配達完了データは、個別の論理データベースであってもよいし、またそれを積荷目録データまたは実績データと合同して実装してもよい。これらの実装オプションは、可能な様々な実施形態を反映する。
【００７９】
また、「配達完了」と呼ぶが、このデータは、完了した小包集配を含む他の種類の非配達関連データを含んでもよい。始業時、配達完了データベース（４２）は、基本的に空である（配達は少しも完了していないので）。配達日の終了までには、配達完了データベース（４３）は、積荷目録データ・データベース（４０）と基本的に同じサイズである（積荷目録の項目はすべて配達されているので）。
【００８０】
管理パラメータにより規定されるこれらの様々な入力およびパラメータに基づき、配送マネージャ（４５）は、配送計画更新アルゴリズム（３０）に最初の配送計画を更新するように命令する。更新配送計画を決定するアルゴリズムは、様々な既存のアルゴリズムに基づいてもよいし、管理パラメータ（３４）に保持されるであろう様々な業務規定により規定されてもよい。更新配送計画（３５）を作成するために、配送計画更新アルゴリズム（３０）は、配達完了データ（４２）および最初の配送計画（３８）へのアクセスに加えて、どの項目が配達されるべきかを示す積荷目録データ（４０）にアクセス可能でなければならない。更新配送計画は、まだ行われていない配達またはサービスストップに関する計画だけに焦点が当てられる。既に完了した配達に関する計画を作成する必要はない。配送計画更新アルゴリズムは、道路および地理的位置情報を考慮して最適配送計画を決定する入力として、ＧＩＳ／経路計画データ（４３）にもアクセスしてもよい。配送計画更新アルゴリズムは、更新配送計画の作成に使用する基準を規定するどの業務規定を使用すべきかを示すパラメータも有してもよい。例えば、管理パラメータは、最初の配送計画を更新するとき、移動距離の最短化が主要な優先事項であることを示してもよい。あるいは、管理規則は、サービス訪問の優先度は移動距離を覆すことを示してもよい。
【００８１】
配送計画更新アルゴリズム（３０）は、一旦更新配送計画を作成すると、通常、前の配送計画である旧配送計画（３８）と一緒に、更新配送計画をメモリに格納する。最新と前の両配送計画は、ＤＭアルゴリズム（４５）によりアクセス可能であり、出力ディスプレイ（４４）上でユーザに表示されてもよい。出力ディスプレイ（４４）は、通常、ポータブルコンピューティングデバイスのビットマップＬＣＤを使用して具現される。各配送計画は、通常個別に閲覧され、ユーザは、どの配送計画を表示するかに関し前後に切り替え可能であってもよい。代わりに、新旧の両配送計画が、同時にユーザに提示されてもよい。旧（以前）と新（現在）の配送計画を維持することにより、ユーザは、システムの処理を比較、拒否または受け入れ可能になる。場合によっては、システムは、「旧」配送計画を保持しないであろう。例えば、配送計画のレコードが修正される場合、システムは、ユーザに更新配送計画を「拒否」するオプションを提示できない。従って、システムは、ユーザに２つの配送計画を閲覧し比較するオプションを提示さえしない場合がある。更新配送計画を作成するために、システムがレコードの順番を再順序付けする他の場合では、ユーザ（例えば、運転手）は、システムが入手できない情報を有する場合があり、更新計画を「拒否」し、その代わりに以前のサービスストップの順番を好む場合がある。一旦運転手が新配送計画を受け入れると、メモリを開放するために旧配送計画を消去し、更新配送計画を現行配送計画と名付けてもよい。
【００８２】
配送計画関連情報のユーザへの表示は、幾つかの形式であってもよい。一実施形態では、配送計画の表示は、一行ずつ、行われる順番にストップを列挙する、表形式またはテキストベース形式であってもよい。レコード内の全情報の表示は必要でない場合があるので、次の５つのストップなどの配送計画のサブセットだけが通常は提示される。通常は、少なくともレコード内のサービスストップの住所は表示される。
【００８３】
代替または追加として、ＤＭは、所要のストップを示すアイコンを使用して経路のグラフィック地図（例えば、道路または通りの地図）を策定するＧＩＳデータベースを使用して、更新配送計画を表示してもよい。ユーザへのデフォルト提示フォーマット選択に関する好みは、管理パラメータ（３４）に収容されてもよい。例えば、図１１は、グラフィック配送計画の一実施形態を図解する。図１１では、ポータブルコンピュータのディスプレイ（１７９）は、配送計画に関連する地図または地図の一部を示す。ディスプレイは、幹線道路のＲｉｄｇｅ Ｖｉｅｗロード（１８０）を示す。車両の現在位置は、アイコン（１８３）を使用して示される。Ｃａｎｙｏｎロード（１８１）およびＲｉｄｇｅｃｒｅｓｔロード（１８２）などの関連する脇道も示される。サービスストップ場所は、短縮した住所情報（通常、通り名だけで、市も州も郵便番号も含まない）で地図上に相対的位置が描画され、運転手は、次のストップに行くために使用すべき経路が容易にわかる。具体的に言うと、現在位置に基づき、第１のストップはＣａｎｙｏｎンロード１０３４（１８４）で、続いてＲｉｄｇｅ Ｖｉｅｗロード５３２４（１８５）等であろう。
【００８４】
図４に戻って、図４のＤＭ（４５）は、配送計画更新アルゴリズム（３０）を自動的に呼び出すべきかどうかを判定するために、入力を使用する。場合によっては、配送計画更新アルゴリズム（ＤＵＰ）は、配送計画を更新し、旧配送計画を消去し、ユーザに変更を通知するであろう（新しいストップが追加される場合）。実施形態によっては、次いで配送計画更新アルゴリズムは、最も効率的な経路を取得するために、場合によってはレコードを再順序付けするように、配送計画の処理を自動または手動で要求するであろう。実施形態によっては、ユーザは、受信入力（例えば、新しいサービスストップの追加）の通知を受け、更新（例えば、新しいサービスストップ）を何処に挿入すべきかを手動で指示してもよい。例えば、ユーザは、システムによって考慮されない外部状況を認識し、自動更新を無効にしたいと望む場合がある。場合によっては、配送計画に影響を及ぼす入力の受信は、ユーザによる入力の検討の必要性を示すために、ディスプレイ上のアイコンをフラッシュさせることにより、および／または可聴信号若しくは他の視覚信号を提供することにより、ユーザの注意を喚起してもよい。その時点で、ユーザは、適切な入力を与えることにより、配送計画の更新を手動で開始させてもよいし、また検討してもよい。実施形態によっては、配送計画の変更（それにより、更新配送計画の作成）が行われてもよく、ユーザに信号で送られてもよいが、潜在的なレコードの再順序付けの必要はないし、またユーザからの許可も必要ない。例えば、集配用の小包のサービスクラスの変更は、サービス経路の再順序付けを通常必要としないであろうし、またレコードを場合によっては再順序付けするために、ユーザに配送計画の処理を手動で開始することも要求しないであろう。
【００８５】
別の実施形態では、配送計画は、グラフィック形式でユーザに提示される。この実施形態では、ポータブルコンピューティングデバイスが配送ファイルの再順序付けまたは構造変更をすることなしに（と言っても、この可能性は除外されない）、ユーザは、サービスストップの順番を自己発見的に、頭の中で再分析および／または再順序付けしてもよい。例えば、図１２を参照して、システムが、Ｒｉｄｇｅ Ｖｉｅｗロード５３２１における小包集配の更新サービスストップを受信したと仮定する。システムは、地図上にサービスストップを表す印（例えば、点、丸または他のアイコン）をオーバーレイすることにより、地図上にこの場所（１８６）を描画する。これは、当業界で周知のソフトウェアを使用して行ってもよい。システムは、ユーザが新情報を容易に特定できるようにするために、新情報を強調表示してもよい（この場所（１８６）は、図１２では二重線のボックスで表されているが、他の実施形態では、テキストの明滅、種々のフォント、色等が、ユーザに配送計画の更新についての注意を喚起するために使用されてもよい）。システムは、画像の閲覧に基づき、運転手が自己発見的に経路を決定するのに頼ってもよいので、システムは、運転手が使用する経路を必ずしも決定しない。このケースでは、運転手はＲｉｄｇｅ Ｖｉｅｗロード５３２４（１８５）での配達の直ぐ前のＲｉｄｇｅ Ｖｉｅｗロード５３２１（１８６）の場所に新しいストップを追加すべきであることは、明らかである。それに対して、経路を両方向に移動する（例えば、Ｒｉｄｇｅ Ｖｉｅｗロードが行き止まりで、Ｒｉｄｇｅ Ｖｉｅｗロード５００３でストップした後で、配達車両が方向転換を必要とする）場合、新しいストップは、経路の戻りの行程でサービスされるであろう。
【００８６】
表ベースのリストでは、配送計画更新アルゴリズムによる更新は、配送計画を構成する既存の一連のレコードに新しい住所を収容するレコードを単に挿入することにより達成されてもよい。ここで、レコードの挿入は、同じ道路上の他のサービスストップと比べた新しいサービスストップの番号の順番（住所により表される）に基づく。従って、配送計画の更新は、一連のレコード内でＲｉｄｇｅ Ｖｉｅｗロード５３２４に関するレコードの直ぐ前にレコードを論理的に配置することにより、新しいサービスストップ（例えば、Ｒｉｄｇｅ Ｖｉｅｗロード５３２１）に対する新しいレコードの追加を伴ってもよい。残りの全ストップに対する最適経路の再分析は必要ない。
【００８７】
新しいサービスストップが、他の既存のサービスストップが存在しない道路に関連している場合、新しいストップを配送計画のどこに挿入すべきかを判定するために、他のアルゴリズムを使用してもよい。例えば、経路を表すデータ構造は、リスト上のどこに新しいストップを配置するかを決定するために使用されてもよい。図１３を参照して、この実施形態では、Ｒｉｄｇｅ Ｖｉｅｗロード（１８０）の住所は、Ｒｉｄｇｅ Ｖｉｅｗ５５００（１８９）で始まり、脇道なしでＲｉｄｇｅ Ｖｉｅｗ５４００（１８８）に続く。Ｒｉｄｇｅ Ｖｉｅｗ５４００（１８８）とＲｉｄｇｅ Ｖｉｅｗ５３９８（１８７）との間には脇道Ｃａｎｙｏｎロード（１８１）がある。それ故、Ｃａｎｙｏｎロード１０３４（１８４）を含むＣａｎｙｏｎロードの住所は、リスト上でＲｉｄｇｅ Ｖｉｅｗロード５４００とＲｉｄｇｅ Ｖｉｅｗロード５３９８との間に配置されるべきである。配送計画が一連のレコードとして実装される場合、Ｃａｎｙｏｎロードに関連するレコードは、Ｒｉｄｇｅ Ｖｉｅｗロード５４００の後で且つＲｉｄｇｅ Ｖｉｅｗロード５３９８の前に論理的に追加されるべきである。様々なアルゴリズムが、そのようなデータを表し、データの更新および効率的な検索を可能にするために使用されてもよいことを、データ構造に関する当業者であれば理解するであろう。
【００８８】
代替スキームは、グラフィック地図を使用して、新しいサービスストップとすべての既存サービスストップとの間の最短距離を判定し、リスト内のその直ぐ前に新しいサービスストップを挿入することである。距離は、最短地理的距離に基づいてもよいし、また道路移動に基づく最短距離に基づいてもよい。これは、必ずしも最も効率的な順番を反映しないことがあるが（一方通行の通りやポータブルコンピュータが知らない他の道路状態が、実際の距離または移動時間に影響を及ぼすことがある）、この簡略化アルゴリズムはアプリケーションによっては好ましいことがある。
【００８９】
前述のプロセスを実行するポータブルコンピュータのハードウェアアーキテクチャの一実施形態を、図５に図解する。これは、ＤＩＡＤタイプのデバイスでも実行されてよいが、個別の汎用コンピュータ（例えば、ＰＤＡまたはラップトップ）およびサービス車両に搭載されたコンピュータも使用されてよい。図５は、ハードウェア構成要素の一実施形態と、その構成要素の高レベル機能および相互作用とを図解する。通常、プロセッサ（５１）は、充電式バッテリ電源（６７）から主として電力供給され、配送計画を動的に更新するプロセスを含む、様々なアプリケーションに関連する命令を実行する。プロセッサは、データバス（５５）を介して様々な種類のメモリと通信する。メモリには、ＲＡＭなどの主（揮発性）記憶装置（５２）を含み、主（揮発性）記憶装置（５２）は、通常、アプリケーションソフトウェア、入力データ（配送計画とは別に格納された場合、当日の積荷目録など）および更新配送計画の結果を格納する。メモリには、不揮発性記憶装置（５３）も含み、不揮発性記憶装置（５３）は、様々なパラメータ、ＢＩＯＳ（基本入出力システム）ルーチン、ならびにシステムおよびアプリケーションレベルのデフォルトデータを格納してもよい。補助記憶装置（５４）は、実績配送データ（３６）およびＧＩＳ（４３）などの他のデータベースを格納できる。様々な実施形態は、部分的には記憶容量および性能要件に基づいて、様々な種類のメモリにデータを格納してもよい。
【００９０】
プロセッサ（５１）は、アンテナ（６５）とデータを送受信できる無線インタフェース（６６）などの様々な構成要素と通信するために、Ｉ／Ｏバス（５６）も使用する。このインタフェースは、免許不要の低電力スペクトラム（様々なＩＥＥＥ８０２．１１標準の１つにより使用されるスペクトラムなど）に基づいてもよいし、また免許を受けたスペクトラム（ＧＰＲＳ、ＥＤＧＥまたはＣＤＭＡベースのデータ通信プロトコルを含むセルラシステムで使用されるスペクトラムなど）に基づいてもよい。無線インタフェースは、前述のように、一旦配達車両が移動中になると遠隔入力を受信するために使用される。主にデータ用に使用されるが、無線インタフェースは音声も伝達できる。
【００９１】
プロセッサは、有線ＬＡＮインタフェース（６４）、電話通信（６３）（インターネットへのアクセスを含む）、または他の種類（６２）（赤外線、高速シリアル通信等を含む）を含む当業界で周知のインタフェースを含む他のインタフェース（６１）を使用しても通信してよい。これらのインタフェースは、作業日の始業／終業時にポータブルコンピューティングデバイスを配送サーバに接続し、データをダウンロード／アップロードするとき、使用されてもよい。
【００９２】
プロセッサは、マウス、タッチパッド、署名パッド、スタイラスなどの様々な形態で具現されてもよい触覚入力デバイス（６０）を含む、他のローカル入力／出力デバイスと通信してもよい。プロセッサは、一般的にキーパッド（５９）からもユーザ入力を受け取り、主としてカラービットマップのＬＣＤディスプレイ（５８）上に情報を表示する。プロセッサは、ユーザからのデータ入力値またはコマンドを認識する音声認識を実行するために、マイクロホン（６９）を介して音声入力も受け取ってもよい。プロセッサは、プリンタ（６８）と通信してもよい。この通信は、システムが配達車両内で動作しているときは通常実行されないが、顧客の構内で行われてもよい。有線接続で図解されているが、プリンタへの通信は無線インタフェース（例えば、ＩｒＤＡ、Ｗｉ−Ｆｉ等）を使用しても行われてもよい。
【００９３】
次いで、図６の、配送更新プロセスへの入力の処理の一実施形態を図解する高レベルのフローチャートを参照する。高レベルでは、システムは入力を受け取り、入力に基づき、配達進捗状況が「スケジュールどおり」かどうか、配達責務の達成に関して問題になる可能性があるかどうか、配送計画に関し残りの作業項目を再検討する必要が有るかどうかを判定してもよい。配達進捗状況が「スケジュールどおり」である（少なくとも配達責務達成が危機にさらされている可能性がないことを意味する）場合、配送計画内の現在の一連のレコードを維持するように（業務規定に基づき）構成してもよい。しかし、将来の配達責務の達成が危機にさらされている場合、システムは、配送計画を再順序付けして潜在的な問題を正してもよいし、および／または起こり得る状況をユーザまたは遠隔システムに通知してもよい。一連のレコードの再最適化は、ポータブルコンピュータによる反復プロセスの呼び出しを必要としてもよい。そのプロセスでは、プロセッサは、幾つかの更新配送計画を算定してもよく、それらの更新配送計画は、好ましい更新配送計画が作成／選択されユーザに提示される前に、内部でテストされる。他の実施形態では、更新配送計画は、サービスストップのグラフィック描写だけでもよく、実行すべきレコードの順番を最適化することは行わない。
【００９４】
図６で、プロセスは開始アイコン（７０）で始まり、その後、工程（７１）で更新データを受け取る。更新データは、ローカルで（例えば、キーパッド、ＧＰＳデータ）または遠隔から（無線インタフェースを使用して）受け取ってもよい。更新データは、自動と手動の２種類のうちの１つであると分類されてもよい。その区別は、自動更新ではオペレータの介在を伴わず、配送計画の更新が配送更新プロセス自体により決定されることにある。他方では、自動更新は、通常、システムが受信した積荷目録の変更（例えば、サービス担当すべき新しい集配場所）などの新しい配達関連情報に基づき開始される（しかし、常にではない）。自動更新を開始させる別の代表的なものは、現在時刻入力に基づく。この場合、ポータブルコンピュータ内の周期的ローカルプロセスが、更新が適切であると判定する。
【００９５】
きっかけとなる別の代表的なものは、ユーザ（通常は車両の運転手）が入力する手動更新である。手動更新で、ユーザは、単に進捗状況の「チェック」を要求してもよいし、またユーザは、積荷目録関連情報をさらに手動で追加してもよい。典型的な実施形態は、現在の配達進捗状況に基づき、オペレータが進捗状況チェックを要求することである。例えば、運転手は、配達がスケジュールより遅れているのではないかと疑い、システムに配送計画の更新が適切かどうかを確かめるように要求してもよい。次いでシステムは、現在時刻および／または現在位置と積荷目録および／または実績データとを比較し、現在の配達進捗状況に関するベンチマーク指標を取得する。別の実施形態では、手動による開始（または更新要求）は、サービスストップの完了表示（例えば、小包がサービスストップに配達された）などの別の活動と対であってもよい。従って、ユーザがタスクの完了を通知するときはいつも、システムは、まだ実行されていないサービスストップを自動的に分析し、新しい最適化の実施を決定することができるかどうかを判定する。
【００９６】
他の実施形態では、遠隔入力データを受信すると、ユーザに受信したことの通知を開始してもよく、プロセッサは、更新プロセスまたは場合によっては配送計画内のレコードの再順序付けを行うために、ユーザの許可を求めてもよい。手動入力の他の場合では、オペレータは、更新情報を手動で提供してもよく、次いで最初の配送計画の更新を要求してもよい。車両運転手が状況（例えば、道路閉鎖または交通混雑）を見て、手動でシステムに状況を通知し、システムに配送計画を更新するよう要求するのが、そのような場合であってもよい。
【００９７】
多くの異なる状況および手動入力の種類があるので、図６には、１つの簡略化した実施形態だけを図解する。この実施形態では、ユーザが提供した手動更新は、ポータブルコンピュータに追加情報を提供せずに、時刻および／または場所に基づき更新を行う。この実施形態は、本発明の原理を説明するには十分であり、そのようなシステムを設計する当業者であれば、他の変形形態を発見可能であろう。
【００９８】
更新処理の説明では、まず手動更新を検討する。それは通常範囲が狭く、更新をもたらすことのある他の種類の入力を説明する基礎を提供するからである。この実施形態では、手動更新要求はユーザが指示し、要求は追加情報を一切含まないと想定する。代表的な利用は、ポータブルコンピュータを使用する車両運転手が、配達がスケジュールより遅れているのではないかと疑い、またはサービス訪問を完了し、システムにスケジュールの進捗状況（特に、まだ実行または完了していないサービスストップに関して）を確認するように要求するときである。システムに更新の実行を要求するために、ユーザは、タッチスクリーン上のアイコン、ソフトキー、または専用機能キーを選択して、ユーザ入力を指示してもよい。
【００９９】
この実施形態では、システムは、時刻更新（７７）かそれとも位置更新（７８）に基づきシステムが自動的に処理する入力と同様に、手動の更新要求を処理する。これらは、配送計画の実行進捗状況（例えば、スケジュールどおりか、それとも遅れているか）を確かめるために使用することができる２つの方法を表す。
【０１００】
図１４は、これがどのように達成されるかについて、高レベルの概観を提供する。図１４では、１本の線（３０１）は実行すべき作業を表す。これは、サービスストップ、配達完了小包、サービス完了等で測定してもよい。本実施形態では、大体はサービスストップまたは小包配達の完了が、最小の作業単位である。他の実施形態は、他の基準を使用してもよい。実行すべき作業は、０％完了（３０１）、５０％完了（３０２）、および１００％完了（３０３）を表す点を持ち、連続的と見なすことができるため、線は連続して表される。実行すべき作業は、積荷目録または配送計画により定められる（配送計画は順序付けした積荷目録と見なしてもよいので、両方とも完了する必要があるサービスストップを定める）。配送計画の完了のレベル（「完了進捗状況」）は、完了したサービスストップ（または配達した小包）数とサービスストップ（または小包）の合計数との割合を比較することにより簡単に判定することができる。前述の完了フラグまたは完了インジケータは、レコード内の対応するサービスストップが実行されたかどうかの表示を提供する。従って、合計１２０のうち３０サービスストップの完了は、３０／１２０＝．２５すなわち２５％の完了に相当する。これは、線上の点（３０４）に相当するであろう。
【０１０１】
図１４の別の線（３１０）は、作業を実行するために割り当てられた時間を表す。通常、これは作業日であり、決められた時間数がある（例えば、８時間）。この場合もやはり、基準（時間）は連続と考えてもよく、点は割り当てられた時間の０％、５０％、および１００％を表す。決められた毎日の作業スケジュールと一緒に現在時刻の時計を使用して、この基準に沿った進捗は容易に測定できる。例えば、割り当てられた時間の５０％は、通常、作業日の４時間に相当し、午前８：００に始まった場合は、正午の１２時に相当するであろう。同様に、１日８時間の２５％の経過は、２時間の経過に相当し、午前１０：００に相当するであろう。これは、線（３１０）上の点（３０６）に相当するであろう。
【０１０２】
最後に、図１４に示す別の基準は、順序付けした一連の位置データ（３０８）を表す。場所それ自体は必ずしも直線（例えば、通りに沿った）ではなく、ポータブルコンピュータが操作するのは場所を表すデータなので、この基準は、位置データ（例えば、ＧＰＳの座標）により特定される場所を表す点により論理的に表される。この基準は、配送計画の中に見つけられる順序付けした一連の位置データ（３０８）により表される。位置データに関するサービスストップの完了の割合の決定は、幾つかの方法で行うことが出来る。まず、ストップ数は位置データのレコード数（これは、ストップ数と等しいはずである）を数えることにより決定してもよく、特定の位置データは、系列の中の相対的順番により特定してもよい。従って、合計１０のうちの３番目のレコードの位置データは、３０％完了と考えてもよい。１０ストップしかない場合、２５％完了は、２番目と３番目のストップとの間で起こるであろう。完了を判定するこの基準を使用する別の方法は、ポータブルコンピュータ内のＧＰＳデバイスを使用して現在位置を読み取り、順序付けしたリスト内の最も近くにあるサービスストップを特定することである。一旦それがわかると、完了進捗状況を決定することができる。従って、（合計１０の中の）２番目と３番目のストップとの間に相当する場所は、完了率２５％と見なしてもよい。
【０１０３】
これらの基準のこれら３つは相互に関係があり、これらの基準のそれぞれからマッピングが行われてもよい。ポータブルコンピュータは、時刻、その位置を追跡し、配送計画にサービスストップの完了を記録してもよい。次いで、ポータブルコンピュータは、各基準の相対的完了進捗状況を比較してもよい。時間の進行は一定なので、この基準は通常ベースラインとして使用される。従って、配送計画の進捗状況は、基本的に、実行すべき作業の完了進捗状況と割り当てられた時間とを比較するか、または割り当てられた時間を含めた予定サービスストップに対して現在位置を比較する。
【０１０４】
作業日の進行に連れて（例えば、時間が経過すると）、実行すべき作業が完了し、同様に一連の位置データに関連するサービスストップも完了する。スケジュールどおりか否かの判定は、様々な方法で定められてもよく、また様々な方法で算定されてもよいことが明らかになる。
【０１０５】
例えば、図６に示す更新の種類には、配送計画の現在の実行進捗状況（「配送計画スケジュール」、「スケジュール進捗状況」または単に「進捗状況」）を判定するために使用される時刻更新（７７）がある。システムは、実行した作業と合計作業との比率を決定し、作業完了進捗状況を導き出す。図１４の１つの点は、２５％（３０４）に相当する。この割合は、時間完了進捗状況にマッピング（３０５）されてもよい。その時間完了進捗状況は、普通の状況でも、２５％（３０６）のはずである。作業日の作業時間および始業時刻についての知識に基づき、作業日の２５％は既知の時刻に対応し、午前１０：００であると想定してもよい。その時刻は、また「予定時刻」と考えてもよい。ポータブルコンピュータは、内部時間記録時計を介して現在時刻を知る。現在時刻が午前１０：００である場合、予定時刻と現在時刻は同じであり、配送計画はスケジュールどおりである。それに対して、現在時刻が午後１２：３０である場合、配達または進捗状況は、スケジュールより遅れていると見なしてもよい。同様に、現在時刻が予定時刻より早い場合、配送計画はスケジュールより進んでいる。管理パラメータは、閾値（例えば、実際の時刻と予定時刻との差の限界）を定めてもよく、その閾値を超えると、配達は「スケジュールより進んでいる」、「スケジュールどおり」、または「スケジュールより遅れている」と見なされる。従って、現在時刻と予定時刻とが１分離れている場合、配送計画は、遅れているまたは進んでいるではなく、「スケジュールどおり」であると見なされるおそれがある。
【０１０６】
システムは、配達が「スケジュールより遅れている」と判定した場合、配送計画内のレコードをもっと効率的に順序付けできるかどうか判定するように配送更新プロセスを開始してもよいし、また単にユーザに適切に通知してもよい。ポータブルコンピュータは、中央配送システムにさえ通知してもよく、中央配送システムは場合によっては追加のリソースを割り当ててもよいし、また特定の問題に遭遇したかどうかを運転手に尋ねてもよい。
【０１０７】
遅延によりスケジュールより遅れたが、残りのサービスストップが既に最も効率的な順番である場合は、重ねて残りのサービスストップの順番を再分析する理由がないことは明らかである。
【０１０８】
代わりに、配送計画のスケジュール進捗状況の算定は、車両の現在位置に基づき実行されてもよい。手動更新が図６の工程（７８）に示すように場所に基づく場合、システムは、工程（８３）で現在の完了進捗状況を使用して、予定位置に対する現在位置を確かめる。
【０１０９】
この場合もやはり、様々なアルゴリズムが使用されてもよく、図１４に戻って、一実施形態では、最も近いサービスストップを決定するために、（前述のＧＰＳ入力を使用して）配達車両の現在位置を比較してもよい。従って、図１４では、「Ｘ」（３１１）で表される現在位置が、配送計画内の位置データ３（３１０）に最も近いと判定されてもよい。ストップは、通常直線状に一定の間隔をおいて配列されないので、３番目のレコードが使用されてもよく、相対的進捗状況は３０％であろう。これは、割り当て時刻の２５％に近い。システムは、その差を取るに足らないと見なし、配送計画を「スケジュールどおり」と判定してもよい。
【０１１０】
代わりに、経路が田舎にあり、ストップ間の距離が長い地域における利用では、上記の推定は実績位置データを使用することにより、もっと正確に行われてもよい。例えば、ストップが２０あり、それぞれが１０マイル離れている、合計２００マイルの田舎の経路を検討する。位置データの使用（代わりに、走行距離計の示度数を使用してもよい）により、システムは、全体の経路距離および移動距離を判定することが可能になる。移動距離が２００マイルの経路上で５０マイルの場合、これは経路の２５％完了に相当する。従って、配送計画の実行はスケジュールどおりであろう。
【０１１１】
実績データは、固定時間間隔で定期的にその位置を記録し、所与の時刻の平均位置を決定することにより、ポータブルコンピュータで収集してもよい。代わりに、ポータブルコンピュータは、各サービスストップに関する位置データを維持し、それをポータブルコンピュータが配送計画のどこにいるか、および相対的な完了進捗状況がどうであるかを判定するために使用してもよい。この種の算定は、過去の配達データの移動平均または情報を必要としないが、データは他の目的で収集されてもよい。
【０１１２】
従って、手動更新は、現在時刻、現在位置、またはその２つの組み合わせと、実績平均配達データまたは現行配送計画との比較に基づいてもよい。好みは、管理パラメータまたはルーチンにハードコードして指示してもよい。その方法の選択は、配達経路の特徴に基づき行われてもよい。例えば、ストップ数が少なくストップ間の距離が長い（田舎または郊外の経路の特色）ことが特徴の配達経路では、位置判定に基づく現在のスケジュール進捗状況の処理に基礎を置くほうが、より正確であるとわかる場合がある。この利用では、サービスストップ間の距離は相対的距離であってもよく、移動時間が割り当てられた作業時間を圧倒的に占めてもよい。従って、サービスストップが１つだけ（１つの目的地への長距離トラック輸送）のとき、運転手に配送計画進捗状況情報を提供しても、ほとんど利益にならないであろう。その場合、配達が行われるまで、配送計画は０％完了と見なされ、一旦配達が完了すると、配送計画は１００％完了する。この利用では、時間と併せて位置を使用することにより、運転手により有益な進捗状況表示を与える。
【０１１３】
他方、ストップが多く各ストップ間の距離が短い（都市経路の特色）配送計画を実行する運転手は、時間ベースの配送計画進捗状況表示をより有益で正確であると気づく場合がある。都市経路では、移動時間が少なく、運転手（およびポータブルコンピュータ）は、ＧＰＳ信号が利用できないことのある建物内部でより多くの時間、作業に従事する。このことは、時間ベースの進捗状況更新ルーチンの使用に適する。また、１つのストップの場所（例えば、ショッピングモール、オフィスビルディング）は、運転手の時間を大幅に必要とすることがある、１つの場所に相当する。他の実施形態では、両方の組み合わせを使用してもよい。
【０１１４】
図６に戻って、一旦進捗状況を決定すると（進捗状況決定に使用する基準にかかわらず）、システムは、配達問題が起こる可能性があるかどうかを判定する（８４）。配達問題が起こる可能性があるかどうかの判定は、予定スケジュールに関する閾値を超えたかどうかを含む幾つかの基準に基づいてもよい。残りの配達時間保証に影響があるかどうか、また現行配送計画内の残りのサービス訪問が最適でないかどうかの判定を含んでもよい。問題となるものは、達成できない配達時間保証に限定されず、広範囲に定めてもよい。例えば、横幅の大きい荷物は、日没後州間ハイウェイでは禁止されている。配送計画が、目的地への到着が日没後の時間になることを示す場合、これは、運転手の注意を必要とする問題と見なしてもよい。
【０１１５】
問題が起こるかどうかの判定は、作業活動またはサービスストップがまだ実行されていない、配送計画内のレコードだけの検討を必要とする。例えば、配達時間保証を持つ小包がない場合、現在の配達がスケジュールより遅れている場合でさえ、システムは、問題の可能性はないと判断してもよい。それに対して、所用の配達時間要件を満たす残りのサービスストップがある場合、閾値を超える遅れは、配達問題の可能性をもたらす場合がある。完了したサービスストップを検討する必要はない。
【０１１６】
問題になる可能性がない場合、プロセスは終了する（８８）。問題になる可能性がある場合、幾つかの利用可能なアルゴリズムのどれか１つを使用して、更新配送計画を作成し（８５）、再最適化が必要かどうか、最適化により問題が軽減するかどうかを見てもよい。更新は、前述のように、グラフィック、表またはその両方であってもよい。次いで工程（８６）で、システムは、配達時間保証は更新配送計画で満足されるかどうかを検討する。満足されない場合、配送計画は再算定される（８５）。ここでは、解決は可能であると仮定するが、場合によっては、配達時間保証は、配送計画の修正では、達成できないこともある。そのような場合、ポータブルコンピュータは、配送サーバに状況を報告してもよく、それによりサービス提供業者は、場合によっては追加車両の派遣が可能になる。代わりに、配送計画については、不利な影響を最小限にする更新配送計画を選択してもよい。一旦更新配送計画が作成されると、工程（８７）で、適切なフォーマットを使用して、ユーザの検討のために提示される。
【０１１７】
図６の一番上に戻って、これから自動更新を考慮する。時刻更新（７７）および位置更新（７８）は、これらの入力をシステムが通常定期的に自動開始することを除いては、前述と同様の方法で動作する。従って、長距離トラック輸送での利用に戻って、システムは、周期的（例えば、１５分毎）自動的に配送計画の位置ベースの更新を実行して、運転手に進捗状況を提示してもよい。
【０１１８】
システムが自動的に受け取る他の更新には、気象状態および交通状況に関するものがある。気象データ更新（７５）は、電子的に気象の更新を提供する商業サービスまたは車両運転手に提供される個人用サービスに基づいてもよい。どちらであろうと、工程（８０）で、システムは気象データ更新の影響を確かめる。通常、気象データ更新は、当初の配送計画が当日早くに作成されたとき、入手可能でなかった情報を提供する。その結果、ある場所で暴風雨、降雪、ひょうなどの予想外の天候が発達した場合、この情報の影響は定量化され、所定の規則により影響を判定するポータブルコンピュータに送信されてもよい。例えば、激しい暴風雨は、現行スケジュールの時間に対して一定の遅延時間（例えば、３０分）を加えることで定量化してもよい。代わりに、全体のスケジュールを、配送計画の完了に応じて遅らせてもよい（例えば、残っている作業の各残り時間に対して余分に１０分）。
【０１１９】
同様に、商業サービス、地方政府の交通部門、または他の情報源が提供することがある交通データ更新情報（７６）を、システムが受け取ってもよい。同様に、道路閉鎖、事故、交通混雑、または他の状況は、所定の規則を使用して定量化してもよい。通常、交通情報は、位置データおよび交通事象の表示を有して伝達されてもよい。位置データは、通り名若しくは道路名とブロックの住所若しくはマイル標識とであってもよいし、代わりにＧＰＳ座標の形態であってもよい。交通事象の表示は、深刻さまたは一般化遅延係数を示してもよい。例えば、交通情報が、ある道路に沿った交通状況は一定の通勤時間について追加の遅延時間が生じていると述べるのは、珍しいことではない。同様に、交通事故の影響は、予想配達スケジュールに一定量の全体時間を追加して定量化してもよい。一旦定量化すると、交通データを、分析し（８１）、未完了の配達に関して配達問題になる可能性があるかどうか、または危機状況をもたらすかどうかを判定してもよい。
【０１２０】
他の実施形態では、サービスストップに向かって運転していようと、出発場所に戻っていようと、運転手による目的地への代替経路の選択を可能にするように、配達運転手に単にグラフィック情報を提示することにより、交通データ更新を処理してもよい。この実施形態では、配送計画を更新する必要があるかどうかを判定する試みは行わず、運転手に交通状況を単に通知し、運転手はそれに応じて経路を調整してもよい。この実施形態では、システムは、交通事変の場所が配送計画のサービス地域内かどうかを確かめてもよい。システムは、事象の表示と併せて印（例えば、アイコン）を使用して、グラフィック地図上に単に位置を描画するであろう。これは、ユーザにグラフィック形式（例えば、道路地図）で提示されるであろう。実施形態によっては、ユーザは、道路状況をチェックするために、この情報の表示を手動で切り替えてもよいのに対して、他の実施形態では、システムは検出した事象をユーザに通知して、入力を待ってから地図を提示するようにディスプレイを切り替えてもよい。また別の実施形態では、天候または交通の影響は、他のチャネル（例えば、交通ラジオレポート）を通じた情報の取得に基づき、運転手がポータブルコンピュータに手動で入力してもよい。
【０１２１】
最後に、配送計画に影響を及ぼすことがある、システムが受信する別の種類の自動更新は、図６の工程（７４）に示してあり、図７にその詳細を図解する。この入力は、配送計画の修正、または同等に積荷目録の修正を伴う。（配送計画は高レベルでは順序付けした積荷目録と見なしてもよいことを思い出されたい。だからこの場合、両方は類似している）。図７を参照して、配送計画の変更処理プロセスは、変更は配達責務の実行に影響を及ぼすことがある種類かどうかをまず試験する（９１）。ある種の配送計画更新は、配達責務に影響を及ぼす可能性がないことがある。例えば、更新は、配送計画内の配送先住所の変更、集配する小包数の減少、または集配の取り消しの場合がある。これらの変更は、配送計画を実行するために追加の時間を必要としないし、配送計画内のレコードの再最適化も必要としないであろう。配送計画のこれらの変更は、作業負荷を減らし、配達スケジュールを進めても、遅らせはしない。そのような場合は、最初の配送計画内のレコードを再順序付けする必要がないので、システムは工程（１０１）に進む。
【０１２２】
４種類のよく起こる積荷目録更新を特定している（９２）が、他の分類も可能である。１番目の事例では、入力は、集配用の追加の小包を備える（９３）。小包は、既存の予定サービスストップに関連するが、顧客が示した集配用小包数が増加する。各小包には、最小限度の取扱時間が割り当てられてもよい。従って、集配用小包数が２個から５０個に増加する配送計画の変更は、システムがスケジュールの予定時間に最小限度の時間を追加することになるであろう。次いでシステムは、悪い影響があるかどうか見るためにその後の配達スケジュールを検討してもよい。さらに、システムは、小包を受け入れる十分なスペースがあるかどうか、またストップでサービスを行うために他のリソースが必要かどうかを判定してもよい。
【０１２３】
工程（９４）に示す別の種類の配送計画更新は、小包の配達保証時刻を変更する。荷受人がサービスを受ける時間帯を指定または修正することを認める、運送業者のサービスをこれは反映するであろう。この場合、予定のストップは変更されないが、ストップに関する配達責務が変更されている。場合によっては、荷受人が予定時刻にいないかまたはある時間以降に応じられることを、これは反映してもよい。住宅への配達では、所有者が仕事日に対応できないことや、一時的に家を離れていることはよくある。
【０１２４】
予定外の小包集配がスケジュールに追加される、別の種類の配送計画更新を工程（９５）に示す。この事例は、顧客が時間ぎりぎりに小包集配を依頼した場合に相当してもよい。これは、顧客が出荷システムにデータを入力するか、または配送事務所に集配依頼の電話を掛けることにより行われてもよい。通常、予定外の場所で集配を実行するには最低限の時間は必要であり、システムは、配送計画のサービスストップに関する予定時間にこれを加えてもよい。予定外の集配を追加する事例では、配送車両が同じ道を戻るのを避けるために、最初の配送計画を分析すべきであり、またその後の配達時間保証を守れなくなるのを避けるためにも分析すべきである。
【０１２５】
新サービスまたは性能を反映して配送計画を更新してもよい、他の種類の情報があってもよい（９６）。その新しいサービスまたは性能は、その後の配達責務に影響を及ぼすことがあるか、または最初の配送計画の処理を開始させることがある。
【０１２６】
図６に戻って、配達問題になる可能性の確認（８４）、配送計画の更新の再算定（８５）、配達基準達成の確保（８６）、およびオペレータに更新配送計画の提示（８７）を含む図６の残りの工程は、前述と同様である。
【０１２７】
次いで、本発明で使用するデータファイルを検討する。構造化およびデータ構造とデータベースファイルを関連付ける様々な技術があることは、データベースに精通している人であればわかるであろう。それ故、開示の実施形態は１つの方法に過ぎず、他の変形形態も容易に考えることができる。
【０１２８】
図８を参照して、異なるが関連する２つのファイルを開示する。１つのファイルは、経路計画データ（１１７）であり、そのデータは、図４のＧＩＳ／経路計画データベース（４３）に収容されたデータに相当する。経路計画データファイル（１１７）は、潜在的なサービスストップの経路に沿った様々な住所または住所のグループのテーブルファイル（例えば、テキストベースで一連のレコードを備える）である。住所によっては小包を受け取るだけのこともあるので、必ずしもすべての住所が小包配達サービスに出荷口座を作っていなくてもよい。図８に示すように、データは、インデックスとして機能するレコード番号（１１０）の列と、名称／住所データ（１１１）の列とを備える。従って、サービスストップの可能性がある全住所が、関連する商店名または居住者名と一緒に列挙されてもよい。この実施形態で、まず住所を示しているのは、経路の順番の性質を説明するためである。通常、経路計画データは、最適経路を反映するように編成され、地理的サービス担当地域内の複数の配達車両に対する幾つかの経路計画と併せて決定される。他の実施形態では、経路計画は、住所の範囲を記載してもよく、そのことは、メモリ要件を非常に簡素化し、名称も格納しない。これにより、所有者が移動するたびに経路リストを更新する必要がなくなる。
【０１２９】
実績配送計画データ（１１８）は、図８に個別のテーブルファイルで示すが、説明のためだけである。経路計画データ（１１７）に追加の列を付けることで実装してもよい。この実施形態では、実績配送計画データは、レコード番号インデックス（１１２）および住所／名称データ（１１３）を複製し、ＧＰＳ座標位置データ（１１４）および平均到着時刻データ（１１５）を付ける。ＧＰＳ座標位置データは、通常、各場所の経度と緯度を示す。図８に示す値は見本であり、現在のデバイスから入手可能な精度を必ずしも反映していないことがある。相互間が比較的近い都市環境でのサービスストップは、ストップ間の位置座標の差は小さいのに対して、田舎の経路では、ストップ間の位置座標の差は大きい。実績位置データは時間が経過しても変わらず（住所位置は動かないので）、実績配送計画データ（１１８）内のデータが一旦多くなると、位置データは通常まれにしか更新されない。データは、配送計画の実行中のサービスストップ完了時に、システムにより個別に記録されてもよい。代替実施形態では、ある区域（例えば、小規模ショッピングセンタ）は１つの場所で表してもよく、アルゴリズムは、所定の距離限界（例えば、１つの場所から１００ｍ以内の範囲は小規模ショッピングセンタに関連する）に基づき、現在場所を１つの場所に描いてもよい。
【０１３０】
また一方、平均到着時刻データは、通常その場所に関する到着時刻の実績移動平均を反映する。経路上のすべてのストップが、通常は、サービスを受けるわけではないが、ストップがサービスを受けるときはいつでも、到着時刻は観察され記録される。従って、テーブル（１１８）で、２つの場所（例えば、メインストリート１２５とメインストリート１２８）は、所与の日の配送計画に両方が載っていないとしても、同じまたは似た平均到着時刻（例えば、午前１０：３９）を持つことは可能である。平均時刻は、最近の３０配達日内のサービスストップに基づいてもよいし、また平均および／または季節的な値を反映する他の値に基づいてもよい。実施形態によっては、同じ月に対する過去複数年の平均に基づく一般水準を反映して、算定されてもよい。平均時刻は変わってもよいので、その場所に対する平均時刻の一定の限界（例えば、１０分）内の現在時刻が「時間どおり」と見なされるように、限界は定められる。どのように平均到着時刻が算定されるかにかかわらず、実績配送計画データは、過去の実績に対して現在の配送計画の実行を比較する基準を提供する。
【０１３１】
住所範囲を使用するときなどの他の実施形態では、実績配送計画（１１８）は、基準場所として少数の場所だけを格納してもよい。基準場所は、通常、頻繁にサービスを提供する顧客に関連するサービスストップ、または所定の地域内の最後のサービスストップになる可能性を示す場所（通りまたは区画の最後のサービスストップ）である。個別の住所位置でなくて範囲を使用することにより、メモリ要件は緩和される。配送計画の現在の実行の正確な推定を取得するためには、ほんの少数の基準場所しかメモリに格納する必要がない。
【０１３２】
次いで、図９は、最初の配送計画（１３０）と積荷目録データ（１３１）との関係の一実施形態を説明する。本発明の原理を説明するために、２つの個別のテーブルを使用しているが、実施形態によっては、テーブルを１つだけ使用してもよい。積荷目録データファイル（１３１）は、集配または配達が予定された小包を列挙するテーブルファイルとして示す。小包は予定のストップの順番に列挙されているので、テーブル（１３１）は、配送計画の変形とも見なすことができる。積荷目録データ（１３１）の内容は、先に検討しており、重ねて検討はしない。
【０１３３】
積荷目録データ内の各小包は、最初の配送計画（１３０）を作成するために、経路計画のサービスストップと関連付けられてもよい。これにより、最初の配送計画は、積荷目録データのサブセット情報を収容することが可能になる。代わりに、積荷目録それ自体が、最初の配送計画（１３０）に示される順番を反映するように再編成されてもよく、場合によっては、住所により索引されてもよい。また代わりに、積荷目録は、配送計画内での相対的位置を示す個別のインジケータを有してもよい。種々の実装が可能なことは、データベースの当業者であれば容易に理解するであろう。また別の実施形態では、積荷目録は、集配または配達用の小包のリストと論理的に見なしてもよいのに対して、配送計画はサービスストップの論理的一覧であり、積荷目録に基づいている。
【０１３４】
図９に示すように、Ｐｅｒｒｙ漬物店に配達される２個の小包（１５４ａ、１５４ｂ）は、配送計画内の３番目のストップ（１５０）に関連付けられている。小包の１個（１５４ｂ）は、配達保証時刻午後４：００を有すると積荷目録に表示されている。
【０１３５】
最初の配送計画（１３０）を作成するプロセスは、通常、中央配送施設（ｃｅｎｔｒａｌ ｄｉｓｐａｔｃｈ ｌｏｃａｔｉｏｎ）内の個別のシステムで実行され、一旦決定されると、ポータブルコンピュータにダウンロードされる。最初の配送計画を作成する方法と取り組みは様々あり、最初の配送計画を作成する特定のアルゴリズムは、本発明の範囲内ではない。提示のように、配送計画に関して様々な実施形態が可能であり、その中には、順番に配列した積荷目録形式の１つのテーブル、各レコードに連続番号を付加して論理的順番を示した積荷目録、または一連の住所を備える個別に編成された配送計画を含む。また別の実施形態を図９Ａに示す。
【０１３６】
図９Ａは、荷受人住所（１３７）に基づきレコードを論理的に順序付けしたテーブル（２３５）を備える配送計画を示す。各住所は小包に関連しており、それ故、レコードは、問い合わせ番号（１３６）および配達若しくは集配すべき小包番号（１３８）も有する。そこにある残りのフィールドは、図９の積荷目録で以前検討したのと同じである。要約すれば、積荷目録および配送計画は、統合テーブルとしてまた個別テーブルとして、様々な方法で表現されてもよい。上記の表現のすべておよび他の形態は、本発明の範囲内にある。
【０１３７】
図９ａに示す最初の配送計画のフォーマットがポータブルコンピューティングデバイスにロードされていると想定すると、図４の配送マネージャは、入力を受け取り、最初の配送計画の更新および再順序付けが適切かどうかを判定する。説明のために、３つのサービスストップを実行する予定の配送車両を含む図１に示す配送計画に似た仮の配送計画を考慮する。この例では、小包の１個に対して、配達保証時刻午後４：００が要求されている。
【０１３８】
配達車両がそのサービス経路に出発したが、スケジュールを遅れさせる様々な状況に遭遇したと想定する。車両が配送計画の実行途中、ポータブルコンピュータが深刻な交通状況の通知を受信した。交通状況更新は無線で受信してもよいし、また運転手が情報をポータブルコンピュータに手入力してもよい。交通状況更新は場所を示し、ポータブルコンピュータは、その場所が配送計画のサービス地域内にあると判定する。この実施形態では、交通状況は、本質的に遅延を加えるように定量化してもよい（例えば、現在時刻を進めるか、または各サービスストップへの予定到着時刻を遅らせる）。
【０１３９】
システムは、残りのサービスストップに関する配達要件（予定時刻）を判定可能である。Ｐｅｒｒｙ漬物店（２５０）への３番目のストップに関する配達は配達保証時刻午後４：００を定めており、予定到着時刻が前述の遅延により遅れた場合、配達保証時刻の達成は危うくなるであろうと判定することにより、システムは配達問題の可能性を特定する。配送計画では、サービスストップの順番は次の通りである。
【０１４０】
１）Ｊｏｎ花店（２４０）
２）Ｊｅｆｆ宝石店（２５１）
３）Ｐｅｒｒｙ漬物店（２５０）
現在時刻および／または現在位置を考慮して、システムは、配送計画（２３５）の順番で（すなわち、１番目にＪｏｎ花店（２４０）、次いで２番目にＪｅｆｆ宝石店（２５１））店舗にサービスすると、Ｐｅｒｒｙ漬物店（２５０）への配達保証時刻の午後４：００に遅れることになるおそれがあると判定する。システムは、配送計画を分析するアルゴリズムの呼び出しは適切であると判定し、配達保証時刻の達成を可能にするために、配送計画の順番を再順序付けする。更新配送計画を図１０に示す。
【０１４１】
図１０では、更新配送計画（１６０）は、配達の新しい順番を反映する。すなわち、Ｐｅｒｒｙ漬物店（２５０）がいまや２番目のストップであるのに対して、３番目のストップは今やＪｅｆｆ宝石店（２５１）である。この方法で、更新配送計画は、配達基準を満足する配達計画の変更を反映して最適化される。図１０は、ポータブルコンピューティングデバイスを使用して運転手に提示してもよい、配送計画の表出力の１形式を示す。
【０１４２】
ユーザに提示してもよい配送計画の別形式の表出力を図１０ａに示す。図１０ａでは、一連のレコード（２４０、２５０、２５１）を持つ更新配送計画（２６０）が、ユーザに提示され、１番目の列はストップ番号識別子（２６１）である。ストップ番号はストップの順番を表し、住所（２６２）および受取人名（２６３）に関連する。従って、各レコードは、図９ａの場合の小包とは対照的に、サービスストップ（例えば住所）に対応する。図１０ａでは、別の列（２６４）がサービスストップに関連する小包数を示し、最後の列（２６５）は、サービスが集配かそれとも配達かを示す。この種のフォーマットは、運転手に住所位置の順番を強調しており、ストップと小包レベル詳細情報とを結ぶ別のスクリーンが具現されてもよい。これにより、次いで運転手は、住所と特定の小包とを関連付けることが可能になる。
【０１４３】
前述のように、配送計画のグラフィック（例えば、地図ベースの）フォーマットも提示してよい。システムは、ポータブルコンピューティングデバイスのＬＣＤディスプレイ上にグラフィックフォーマット（例えば、地図を使用して）で、ユーザに更新配送計画を表示してもよい（例えば、図１２参照）。システムは、種々のフォント、アイコン、フラッシングインジケータ等を使用して、最初の配送計画に対する変更を強調してもよい。システムは、関連する配達要件または最初の配送計画の他の変更も特定してよい。これは、ユーザがスタイラスを使用してサービスストップに相当する表示場所を選択し、システムが関連するサービスストップ情報を提示するようにディスプレイを切り替えることにより応答し、次いで配送計画に戻っているディスプレイに戻ることにより達成されてもよい。
【０１４４】
システムが更新配送計画を作成するとき、システムは前のバージョンを保持してもよい。それによりユーザは、更新配送計画を受け入れるかどうかを決定するだけでなく、配送計画間の差を確認するための比較を容易にするためにも、前の計画を閲覧してもよい。通常これは、レコードの順番の変更が実行されるときだけ行われる。レコードの順番が維持される既存のレコードの修正またはストップの追加などの他の変更は、ユーザがその受け入れを知らせることをたいてい正当化しない。
【０１４５】
システム設計の当業者には当然のことながら、様々なデータ構造、機能構成要素、およびハードウェア実装態様を含む多くの変形形態が、開示の実施形態について可能である。また、フローチャートのブロックのプロセスの記述は、特定の論理機能またはプロセスの工程を実施する１つ以上の実行可能命令を含む、モジュール、セグメントまたはコードの一部を表していると理解すべきであり、代替実施は本発明の範囲内に含まれ、機能が追加機能を含んでもよいことは、本発明の当業者であれば理解する。
【０１４６】
システムソフトウェアは、順序付けしたステップのリストを備え、命令実行システム、装置またはデバイスから命令をフェッチし、命令を実行できるコンピュータベースのシステム、プロセッサ内蔵システム、または他のシステムなどの命令実行システム、装置またはデバイスにより、またはそれらと併せて、使用されるコンピュータで読み取り可能な記憶媒体として具現されてもよい。本文書の文脈では、「コンピュータで読み取り可能な記憶媒体」は、命令実行システム、装置またはデバイスにより、またはそれらと併せて、使用されるプログラムを収容、格納、通信、伝播またはトランスポートできるどんな手段であってもよい。コンピュータで読み取り可能な記憶媒体は、例えば電子、磁気、光、電磁気、赤外線または半導体のシステム、装置、デバイスまたは伝播媒体であってもよいが、それに限定されない。コンピュータで読み取り可能な記憶媒体のより具体的な例（網羅的なリストではない）には次のものを含むであろう。それらは、１本以上の線を持つ電気的（電子的）接続、ポータブルコンピュータディスケット（磁気）、ランダムアクセスメモリ（ＲＡＭ）（磁気）、リードオンリメモリ（ＲＯＭ）（磁気）、消去可能プログラマブルリードオンリメモリ（ＥＰＲＯＭまたはフラッシュメモリ）（磁気）、光ファイバ（光）、およびポータブルコンパクトディスク（光）リードオンリメモリ（ＣＤ−ＲＯＭ）である。
【０１４７】
詳細な説明の最後に、本発明の原理から大幅に逸脱することなしに、好ましい実施形態の多くの変形形態および修正形態を作成できることに留意すべきである。そのような変形形態および修正形態は、添付の特許請求の範囲に記載する本発明の範囲内に含むことをここでは意図している。さらに、明細書は、特許請求項の言葉それ自体を超えて、特許請求の範囲を多少とも限定する意図はまったくない。
【図面の簡単な説明】
【０１４８】
上記のように本発明を一般用語で説明したが、これより添付の図を参照する。以下の図があるが、必ずしも縮尺で描かれていない。
【図１】配達時間保証を確実に守るための配送計画の修正の一実施形態を示す図である。
【図２】配送計画修正に関連する通信フローを含む、別のプロセスの一実施形態を示す図である。
【図３】更新配送計画の作成にかかわる様々なプロセスの一実施形態を示す図である。
【図４】更新配送計画の開始に関連する様々な機能、プロセス、モジュールおよび入力の一実施形態を示す図である。
【図５】更新配送計画を作成するプロセスを実行するシステムに関連する、様々なハードウェア構成要素、モジュールおよび機能の一実施形態を示す図である。
【図６】更新配送計画を開始させる様々な種類の更新の一実施形態を示す図である。
【図７】積荷目録の様々な種類の更新の一実施形態を示す図である。
【図８】経路計画データファイルおよび実績配送計画データファイルの一実施形態を示す図である。
【図９】最初の配送計画ファイルおよび積荷目録データファイルの一実施形態を示す図である。
【図９ａ】配送計画の別の実施形態を示す図である。
【図１０】更新配送計画の一実施形態を示す図である。
【図１０ａ】更新配送計画の別の実施形態を示す図である。
【図１１】配送計画のグラフィック提示の一実施形態を示す図である。
【図１２】配送計画のグラフィック提示の修正の一実施形態を示す図である。
【図１３】配送計画のグラフィック提示の修正の別の実施形態を示す図である。
【図１４】時刻、位置および実行すべき作業に関するスケジュール進捗状況の概念マッピングを示す図である。
【図１５】ポータブルコンピューティングデバイスに無線で伝達されてもよいメッセージの一実施形態を示す図である。
【技術分野】
【０００１】
本発明は、一般に、経路上のサービス車両にかかわるサービスストップに関して、ポータブルコンピュータにより配送計画（ｄｉｓｐａｔｃｈ ｐｌａｎ）の更新を開始するタイミングを決定することに関する。更新は、様々な形態であってもよく、様々な種類の入力を処理することにより開始される。一実施形態では、提供サービスは小包の配達である。
【背景技術】
【０００２】
宅配産業および様々な場所にサービス要員を派遣する他の産業の事業実施の課題は、所与の日の作業を完了するために、運転手に最新で正確且つ効率的な指示を与える能力を付けることである。多くの車両を有する企業は、運転手ができるだけ大きい受け持ち区域をできるだけ少ない時間で効率的に担当できる配送計画を開発するために、多くの時間と金をかける。経路が毎日変わることのある日々の配達サービス（例えば、自動販売機サービス経路や宅配サービス）に関しては、所与の日に運転手が使用する配送計画と経路は、通常、前日中または遅くとも作業日の始業時までに作成される。運転手に割り当てられる作業は、それまでの実績の平均配達量に基づき、運転手が実行できる作業量の統計分析またはヒューリスティック分析にたいてい基づく。
【０００３】
所与の経路上のサービスストップ数は、通常、それまでの作業日中の運転手の平均作業量を観察することに基づいている。基本的な経路計画を使用し、当日完了することが必要な予定された配達またはサービスストップを使用して、配送計画または配達スケジュールは導き出される。配送計画の変更（例えば、サービスストップの追加または削除）は、移動経路に影響を及ぼすことがあり、容易または効率的に受け入れられないことがある。配送計画のリアルタイムの変更の中には、所与の経路に精通した経験豊富な運転手が、自己発見的に適応できるものもあるが、作業日中に発生するリアルタイムの変更の中には、経験豊富な運転手にさえ効果的に対応できないものがあり、ましてや経路に精通していない運転手にはとても対応できない。
【０００４】
配達プロセスを複雑にする別の側面は、高級なサービスレベルおよび／または配達時間保証の発達である。多くのサービス提供業者は、保証されたサービス保証時刻（「サービス責務」、「サービス保証」とも呼ばれる）に関する高級なサービスレベルを提供する。これらの保証は、小包の配達が一定の時刻までに、または指定された時間帯に完了することを必要とする。サービス保証は、経路に沿って作業を割り当てることと、その経路上の個別の小包配達時間保証に責任を負うこととを必要とするので、配送計画の作成または修正を複雑にする。驚くほどのことではないが、サービス要員は、配達保証時刻が過ぎてはじめて、小包に保証時刻があることを確認することもある。別の場合には、運転手は、サービス配達時間保証を満足させるために計画経路を逸れることもある。しかし、このことは他の配達の完了を非効率にすることがある。
【０００５】
これらの問題は、小包配達サービスに特有のものではなく、修理、設置、販売または現場視察のために要員を派遣するなどの、他のサービスの実行にも当てはまる。通常、顧客は、サービス訪問を受ける時間帯を指定される。サービス要員の到着予定に関して、顧客は、狭い時間帯を希望するのに対して、サービス提供業者は、サービス要員に融通性を与えるために、広い時間帯を希望する。他の場合には、サービスが提供されてもよい、または提供されてはならない時間に関して、顧客は、全面的な制約を持っていることもある。例えば、顧客によっては、配達が受け入れられる、またはサービスが提供されてもよい時間を限定することがある。
【０００６】
さらに、配送計画の実行は、天候、道路状況、サービス車両の機械的故障などの日常的な出来事で影響を受けることがある。これらの出来事のどれもが、個別または一緒に、配送計画の実行に影響を及ぼすことがあり、配達時間保証を果たせなくさせるか、または少なくとも効率を悪化させる。配送計画は、最初に決定されたとき、出来事の発生を考慮しなかった（そして、できなかった）からである。例えば、道路閉鎖または交通事故は、運転手に、配送計画に関するサービス車両の経路を変更させて非効率にすることがある。特定のサービス担当地域に精通している運転手は、個人的な知識に基づき自己発見的にその経路を変更できることがあるが、そのようなその場その場の逸脱は、最適な解決策を提供しないこともある。まだ所与の経路に精通していない場合は、経験豊富な運転手でさえ、そのようなその場その場の逸脱を行い、例外的な状況のもとですべての配達時間保証を確実に果たすことは期待できない。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
それ故、サービス産業内には、様々な種類の状況検出時における配送計画の更新手段を、運転手に提供する改良されたシステムおよび方法に対する満たされていない要求が存在する。
【課題を解決するための手段】
【０００８】
本発明は、一般に、配送計画を格納、処理および更新するポータブルコンピューティングデバイスを使用するシステムおよび方法に関する。配送計画は、論理的な一連のレコードと見なしてもよく、各レコードはサービスストップを表し、各サービスストップは小包の配達などのサービスの実行に関連する。ポータブルコンピュータは、ポータブルコンピューティングデバイスに通常無線で送信される更新データを含む入力メッセージを受信する能力がある。更新データは、新しいレコードの追加、レコードの削除、またはレコード内容の修正などの配送計画の内容に影響を及ぼすデータを含む、様々な形式のものであってもよい。その情報は、場合によっては、配送計画へのサービスストップの追加、サービスストップの削除、またはサービスストップで実行すべき活動の変更をもたらす。配送計画に影響を及ぼす他の種類のデータには、配送計画に関連するサービス地域に関する交通および／または気象関連データの受信が含まれる。また別の形式のデータには、時刻と場所の定期的な入力が含まれ、その入力は、予定されたスケジュールに照らして配送計画の相対的実行を判定するために使用される。
【０００９】
ポータブルコンピューティングデバイスは、配送計画の実行に影響があるかどうかを判定するために入力データを処理し、現在のスケジュール進捗状況に基づき、まだ実行されていないサービス保証を確実に果たすために、場合によっては一連のレコードの再順序付けを含む、必要に応じた配送計画の更新もできる。スケジュール進捗状況は、配送計画の進捗状況に基づき、現在位置および／または時刻と予定位置および／または時刻との検討に基づく方法を含む、様々な方法で判定してもよい。
【００１０】
ポータブルコンピューティングデバイスが、一旦入力データを処理すると、受信した入力データ、配送計画へのその影響、および／または配送計画実行の有力な代替案を含む様々な結果を、ユーザに提示してもよい。結果は、テキストベースのテーブルフォーマットおよびグラフィック地図ベースのフォーマットを含む様々な形式で、サービスを完了するための補助としてユーザに提示されてもよい。グラフィック地図ベースのフォーマットでは、配送計画に示される様々なサービスストップに関連する場所などの様々な場所が描画されてもよい。
【００１１】
上記の要約は、本発明の態様の１つのサブセットだけを表し、決して特許請求の範囲を限定する意図はない。
【発明を実施するための最良の形態】
【００１２】
これより、添付の図面を参照して、以下に本発明をより詳細に説明する。本発明の実施形態の中には、図面で示されているものもあるが、すべてが示されているわけではない。実際のところ、本発明は多くの異なる形態で具現されてもよく、本明細書中に記載する実施形態に限定されると解釈すべきではない。正確に言えば、これらの実施形態は、この開示が適用される法的要件を満たすために提供される。同様の参照番号は、初めから終わりまで同様の要素を示す。
【００１３】
前述の説明および関連図面に提示された教示を利用して、本発明に関連する技術分野の業者は、本明細書中に記載する本発明の修正形態および他の実施形態を多数思い浮かべるであろう。それ故、当然のことながら、本発明は開示した特定の実施形態に限定されず、添付の特許請求の範囲内に修正形態および他の実施形態が含まれることを意図している。本明細書中では特定の用語が使用されるが、一般的および説明的意味でだけ使用されており、限定のためではない。
【００１４】
本発明の一実施形態による方法、システムおよびコンピュータプログラムのブロック図およびフローチャート図を参照して、以下に本発明を記述する。ブロック図およびフローチャート図の各ブロックは、コンピュータプログラム命令で実施してもよいことは理解されるであろう。コンピュータまたは他のプログラム可能データ処理装置で実行される命令が、システムまたはフローチャートのブロックで指定される機能を実施する手段を作り出すようなマシンを製造するために、これらのコンピュータプログラム命令は、汎用コンピュータ、専用ポータブルコンピュータ、情報携帯端末（ＰＤＡ）、または他のプログラム可能データ処理装置にロードされてもよい。
【００１５】
これらのコンピュータプログラム命令は、コンピュータで読み取り可能なメモリにも格納されてもよい。コンピュータで読み取り可能なメモリは、自装置に格納した命令が、フローチャートの１つ以上のブロックに指定された機能を実施する命令手段を含む製品を作り出すような特定の方法で機能するように、コンピュータまたは他のプログラム可能なデータ処理装置に指示してもよい。コンピュータまたは他のプログラム可能な装置で実行される命令がフローチャートの１つ以上のブロックに指定された機能を実施する工程を提供するようなコンピュータ実施プロセスを、コンピュータまたは他のプログラム可能な装置で実行される一連の操作ステップによって作り出すためにも、コンピュータプログラム命令は、コンピュータまたは他のプログラム可能なデータ処理装置にロードされてもよい。
【００１６】
コンピュータは、配送サービス業界で既知のデバイスなどのポータブルコンピューティングデバイスであってもよい。一実施形態は、ＤＩＡＤ（Ｄｅｌｉｖｅｒｙ Ｉｎｆｏｒｍａｔｉｏｎ Ａｃｑｕｉｓｉｔｉｏｎ Ｄｅｖｉｃｅ）として知られ、１つには宅配関連データを管理するために、本発明の譲受人であるＵＰＳ（Ｕｎｉｔｅｄ Ｐａｒｃｅｌ Ｓｅｒｖｉｃｅ Ｉｎｃ．）が使用し、ＵＰＳの運転手が携行している。ＤＩＡＤの機能に関する詳細な情報は、２００３年６月１９日発表の米国特許出願公開の第２００３／０１１４２０６号の「発明の名称：Ｐｏｒｔａｂｌｅ Ｄａｔａ Ａｃｑｕｉｓｉｏｎ ａｎｄ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ ａｎｄ Ａｓｓｏｃｉａｔｅｄ Ｄｅｖｉｃｅ ａｎｄ Ｍｅｔｈｏｄ（携帯データ収集管理システムおよび関連装置ならびに方法）」（出願第１０／２２７，１４７号）に見つけることができる。その内容は、ここでの引用により組み込まれる。配達すべき特定の小包についての情報および集配すべき小包などの他の情報は、始業時に積荷目録をアップロードすることで、ＤＩＡＤに格納される。ＤＩＡＤは、通信手段に融通性があり、様々な実施形態では、場所、利用法または伝達する情報の種類に基づき、種々のエンティティと通信するために種々の技術（例えば、有線ベースの通信手段、赤外線通信手段および／または無線通信手段）を用いてもよい。しかし、ラップトップコンピュータを含む、他の様々な種類のポータブルコンピューティングデバイスが使用されてもよい。また、コンピューティングデバイスは、テキストベースの情報やグラフィック表示を含む様々な方法で、ユーザに配送計画に関する結果を提示してもよい。
【００１７】
典型的な宅配サービスは、一定のサービス担当地域内の経路上の様々な場所にストップし、各ストップでサービスを提供することを含む。各サービスストップは、通常、１個以上の小包の配達に加えて、また１個以上の小包の集配も伴う。各サービスストップ（単に「ストップ」とも呼ぶ）は、通常、所定の経路に沿った一連のストップの１つとして計画される。経路に沿った一連のストップは、本明細書中では配送計画と呼ぶ。一連のストップは、後で示されるように、表形式またはグラフィック形式でユーザに提示されてもよい。多くの場合において、地理的なサービス担当地域は、通常、ある程度静的である。すなわち、一般に地理的地域内の同じ道路に関係する。しかし、各道路上のあらゆる場所が通常はサービスストップに関連するわけではないので、所与の日にすべての道路を必ずしも移動する必要はない。他の場合には、サービス担当地域は、配送計画の全体的な所要の配達に基づき、範囲が変わる（サイズの増大または縮小）。従って、サービス車両が走る実際の経路（例えば、一連の道路）は、特定の日の作業量に基づき、または季節的な変化に基づき、変わってもよい。おおむね静的な経路を使用することにより、運転手は経路に精通し、通常の運転時間および他の状況についての経験を積むことが可能になり、それから逸脱するときに、参照され得る基準を提供する。移動経路またはサービス担当地域は静的であってもよいのに対して、所与の日の経路に沿って予定される個々のサービスストップは、たいてい変わる。配送計画は、通常、配達すべき小包（「配達物」）、集配すべき小包（「集配物」）、または両方に基づき決定される。配送計画は、通常、紙形式かそれとも運転手が必要によりアクセスできるポータブルコンピューティングデバイス（例えば、ＤＩＡＤ）に電子的に伝達されるかで、運転手に提供される。もちろん、宅配以外のサービスに関係する利用も可能であり、本発明の原理をそのような利用にも容易に適合させることができる。
【００１８】
このように、所与の車両に対する配送計画は、通常、配達すべき小包に基づき当日の配達開始前に決定される。場合によっては、小包集配に関する情報が始業時にわからなくて、配達車両の出発前にＤＩＡＤにロードされないことがある。あるいは、追加配達についての情報が、配達開始後に提供されることもある（その場合は、配達する追加の小包は、荷降ろし場所で運転手が受け取ってもよい）。他の場合には、顧客からのサービス要求を受け付けるのが遅すぎて、当日のサービスストップの開始前にＤＩＡＤにロードできないことがある。以前は、出発前に運転手が新しいストップについて知らされていなかった場合、顧客は次の営業日まで集配を待たなければならなかった可能性がある。
【００１９】
顧客からのサービス要求が遅すぎて、当日作業を実行できない可能性は常にあるが、無線通信の使用は、ほとんどの都市部と農村部で容易に可能であり、予定外のサービスストップを通知するために使用されている（例えば、これは、携帯電話機またはプライベートディスパッチ無線を介して行われる）。当日の配送計画の修正に関して途中で、配達車両の運転手（または、場合によっては遠隔のポータブルコンピュータ）に遠隔で通知することは可能である。多くの状況で、翌営業日に集配をスケジュールすることなく小包を集配することを可能としつつ、計画外のサービスストップを受け入れることができる。
【００２０】
予定外のサービスストップの追加により、有限量の時間を消費する。そのような計画外のストップの幾つかで要する時間により、まだ実行していないサービスストップが遅れることがあり、それ故、他のサービスストップのサービス保証を危うくする。
【００２１】
本発明の適用を説明する１つの状況を図１に示す。図１は、３つのストップを備える配達経路を示す。普段の経路は、ストップＡ、ストップＢ、次いでストップＣの順番に定められていると想定する。この順番のサービスストップを、配達スケジュールである配送計画（２）に示す。配送計画（２）は、通常、各ストップに対応するレコードを有するデータベースとして具現され、各レコードは、各ストップで配達する１個の小包に対する小包識別子（「小包ＩＤ」）を示す。小包識別子により、運転手およびポータブルコンピュータは、特定の小包または小包に関する関連情報を一意に特定することができる。それ故、レコードは、小包識別子を使用してコンピュータにより配送計画内で特定されてもよく、小包識別子は小包にも（人間が読み取り可能な形式とマシンが読み取り可能な形式との両方で）印刷される。潜在的なサービスストップのすべてで常に小包配達があるわけではないが（例えば、サービスストップによっては、小包集配であってもよい）、説明のために、図１では、各サービスストップで小包１個を配達し、３つの場所のどこでも小包の集配はないことを示している。最後に、テーブル（２）の配送計画は、ストップＣ宛の小包１個が午前１０：００までに配達されなければならないことを示す。
【００２２】
図１は、サービス配達車両（４）が、午前９：００の現在時刻（１）に所与の場所「Ｘ」にいることを示す。現在位置からの様々なストップ間のパスに、任意の作業単位またはコスト単位を割り当ててもよい。これらの単位は、運転時間、距離、または他の作業関連測定基準を表してもよい。時間と動作の研究用の作業単位を定量化するために実績データを収集することは、生産工学では周知のことである。この図では、各作業単位は時間で５分に相当すると想定する。従って、配達車両が午前９：００にストップＡにある場合、現在時刻の午前９：００から午前１０：００の間に５分が１２回ある。ストップＡからストップＢまでの定期経路は、通常１０単位を消費し、ストップＢからストップＣへの移動では４単位を消費する。合計時間（１４単位）は１２単位限界を超え、配送計画２で示される経路の使用は、ストップＣで必要なサービス保証を果たすことが出来なくなるおそれがある。他方、経路をまずストップＡからストップＣに進むように変更すると、５単位しか消費しないので、この経路の使用により、サービス保証配達時刻に間に合うようになる。ストップＡとストップＢでの配達に関しては、同様の配達時間保証がないので、代替経路の選択は、それらのストップに関する配達時刻（すなわち、サービス保証）に影響を及ぼさない。
【００２３】
通常、配送計画は、サービス保証を果たすことを見込んで前もって準備される。例えば、上記の説明では、最初の配送計画で示される元の経路は、過去の時間測定に基づき所要時刻までに配達する結果になっていたかもしれない。具体的に言うと、過去の配達データが車両は通常午前８：００にストップＡに到着することを示す場合、このことは、実績の移動時間に基づき、所要時刻内にストップＣに小包の配達をするのに十分な時間を与えるであろう。しかし、特定の作業日の予期せぬ状況により、配達車両がいつもより遅くストップＡに到着することがある。配達車両は午前９：００にストップＡに到着するので、保証したサービスレベルを満足させるためには、単に経路を変更するだけでよい。
【００２４】
上記の例は、解決策がサービス保証を果たすための最初の配送計画の動的変更という、簡単な問題を説明している。比較的簡単な問題に関しては、経路に精通している経験豊富な運転手は、予想移動時間および当日の配送計画を使用して、自己発見的に解決策に到着することがある。上の説明では、サービスストップ数が限定され、小包数が限定され、１個の小包しかサービス保証されてなく、代替経路および所要の相対的作業単位についての情報が明らかにされている。しかし実際には、追加の制約がたいてい課される。例えば、多くの営業施設が、配達を一定の時刻に限定する。昼食時に客に料理を提供するレストランの多くは、従業員に午前１１：００から午後２：００まで顧客に料理を提供することを命じ、この時間帯中に配達を受け取らない。従って、あるストップには、配達をしてはならない一定の時間帯があることがある。他の場合には、荷受人は、一定の時間帯での配達／集配を好むことがあるが、翌営業日にその作業を延期するよりは、別時刻の配達／集配を受け入れるであろう。他にも多くの制約および例外的な状況が起こることがある。
【００２５】
配送計画の配達要件が首尾よく満たされるかどうか、配送計画の修正が必要かどうかの判定にかかわる多くの要因があることは明らかである。さらに、未熟なサービス要員かそれとも特定の経路に精通していない代用運転手がかかわる配送計画では、配達要件が容易に見落とされることがあることも明らかである。配送計画の実行に影響を及ぼす別の要因は、配送計画の完了またはサービス保証時刻に対して、予想外の出来事が何時発生するかである。計画の実行がほぼ完了している場合（例えば、残り２ストップ）、配送計画への影響および／または修正を判定することは、重要ではないこともある。それに対して、配送計画の実行が始まったばかりの場合（例えば、１２０ストップが残っている）、影響の分析および計画の修正は、はるかに複雑になる。
【００２６】
上記の例では、計画の最も効率的な実行でないにしても、所与の日に対する計画サービスストップ数は静的である。例えば、小包集配の可能性のあるサービス拠点における１つの方法は、集配が起こる可能性がある各営業施設にサービス車両をストップさせることである。これは決定論的な計画であり、計画スケジュールを容易にするのに対して、拠点で受け取る小包がなく、ストップを正当化する小包配達の予定もない場合は非効率的である。この場合、不必要なサービスストップが発生したことになる。ストップが必要かどうかを示す視覚インジケータを、運転手が見えるように置くなどのその場その場の解決策の中には、必ずしも実用性、信頼性、また効率性があるといえないものがある。
【００２７】
今では多くの顧客が、集配される小包に関連する積荷情報を伝達する出荷システムを使用しており、運送業者が小包の集配が必要かどうか、および小包に関する小包レベル詳細（ＰＬＤ）を前もって知ることができる。出荷システムの使用は小包の集配を容易にする。運送業者は、集配がいつ必要かを知り、サービス車両は、小包が実際に待っている拠点でだけ小包集配のためのストップが必要となるからである。その出荷システムの１つは、ヨーロッパ特許第０８２９０５７号明細書「発明の名称：Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｐｒｅｐａｒｉｎｇ Ａｎ Ｅｌｅｃｔｒｏｎｉｃ Ｒｅｃｏｒｄｓ Ｆｏｒ Ｓｈｉｐｐｉｎｇ Ａ Ｐａｒｃｅｌ（小包を配送するための電子レコードを準備する方法およびシステム）」に開示されている。
【００２８】
サービス要員が携帯するまたは配達車両に搭載されたポータブルコンピュータ（例えば、ＤＩＡＤ）との無線通信と併せて、その出荷システムを使用することにより、配達車両が当日の配達に出発した後であっても、小包集配に関する配送計画の更新が遠隔から可能になる。例えば、図２を参照して、出荷システム（２０１）は、パーソナルコンピュータ（２００）とそれにローカル接続したプリンタ（２０２）とを備えてもよく、それにより、顧客は、出荷データの入力および集配小包（２０４）用のラベルの印刷が可能になる。コンピュータ（２００）は、インターネットや他のよく知られている通信ネットワークなどの通信ネットワーク（２０６）に接続されており、それにより、小包集配要求を中央配送システム（ｃｅｎｔｒａｌ ｄｉｓｐａｔｃｈ ｓｙｓｔｅｍ）（２０８）に送信することが可能になる。中央配送システム（２０８）は、サービスストップの地理的基点を判定し、各車両のサービス担当地域および／または現在位置に基づき、数台の配達車両（２１６、２１８）の中から１台を選択する。図２で、中央配送システム（２０８）は、車両Ａ（２１６）が最適の車両であると決定する。無線通信サービス（２１０）の使用により、アンテナ（２１２）から車両の運転手が持ち運ぶ適切なＤＩＡＤに無線メッセージが送信される。中央配送システム（２０８）は、集配場所と各配達車両のサービス地域の地図とを比較することにより、あるいは各ＤＩＡＤの正確な位置を問い合わせることにより、適切な車両を決定してもよい。集配場所は、出荷システム（２００）が示す所在地住所により特定されるのが好ましいが、他の方法が使用されてもよい。例えば、顧客が、顧客サービスエージェント（図に示されていない）に電話で依頼する場合、発呼者の発信者番号が地理的位置を決定するために使用されてもよく、その地理的位置は、次いで適切な配達車両を決定するために地図と比較されてもよい。代わりに、顧客サービスエージェントは、配送コンピュータ（２０８）に住所を提供するコンピュータを使用して、集配場所を入力してもよい。従って、このシナリオでは、予定サービスストップ数は、最初の配送計画が実行されている時間中、増加または減少してもよい。
【００２９】
様々な実施形態において、ポータブルコンピュータは、車両運転手が持ち運んでもよいし、また車両に搭載されてもよい。従って、本明細書に記述する集配をスケジュールするためのサービス車両へのメッセージの送信は、ＤＩＡＤのようなデバイスを使用することに必ずしも限定されない。つまり、コンピュータは車載されてもよい。他の実施形態では、協調して動作するポータブルコンピュータと車載ユニットの両方を使用してもよい。従って、中央配送システムから配達車両にメッセージが送信されると本明細書に記述するとき、情報は、実際には、配達車両の運転手が持ち運ぶポータブルコンピュータに伝達されてもよい。従って、様々な前後関係において本明細書を解釈するには、融通性が必要なこともある。例えば、車両位置が記録または報告される場合、運転手が身に着けて持ち運ぶＤＩＡＤ内のＧＰＳデバイスは、車両の位置を近似するのに十分であると想定してもよい。同様に、運転手が持ち運ぶＤＩＡＤのようなポータブルコンピュータにメッセージが送信されるとの記述は、車載のコンピュータを使用する実施形態を排除しない。
【００３０】
また、派遣される車両は、通常、「配達車両」、「サービス車両」、「小包配達車両」と呼ぶが、この用語は、自動車ベースの車両に限定されると見なすべきではないし、配達のためだけに使用される車両と見なすべきでもない。それどころか、これらの用語は、サービスの実行をやり遂げるあらゆる種類の品物運搬手段に適応可能であると見なしてもよい。従って、これには、建物の調査、デバイスの修理若しくは取替え等の要員を運ぶことができる飛行機、船、列車、バス、ライトバン、トラック、オートバイ、トレーラトラック等が含まれるであろう。
【００３１】
無線通信は、いくつかの派遣サービスによって使用されているプライベート・ポイント・ツー・ポイント移動無線に基づいてもよいし、また、周知のデジタルセルラ、デジタルデータ、若しくは衛星ベースの通信サービス（ＥＤＧＥ、ＧＰＲＳ、ＣＤＭＡ２０００ １ｘ−ＲＴＴ、ショートメッセージサービス、ＭＭＤＳ、他の種類の３Ｇデータサービス等を含むが、それに限定されない）などの公衆通信事業者の無線サービスに基づいてもよい。本発明は、様々な方式の無線通信技術に基づいてもよい。詳細情報は、引用により組み込まれた前述の特許出願に見つけられることもある。
【００３２】
無線通信のフォーマットは変わってもよく、図１５に使用してもよい代表的な１プロトコル構造を示す。図１５に示されている、プロトコルデータユニット（ＰＤＵ）は、デジタル情報を運ぶ代表的なフォーマットである。ＰＤＵは、通常、通信の特定のレイヤに関係し、通常、ヘッダ（２２１）、ペイロード（２２２）、トレーラ（２２３）を備える。物理レイヤプロトコルデータユニット（２２０）は、特定の無線変調プロトコルを使用して情報を運ぶ。物理レイヤＰＤＵは、リンクレイヤＰＤＵ（通常はリンクレイヤとメディアアクセスコントロール（「ＭＡＣ」）レイヤとの複合）（２２４）を運び、リンクレイヤＰＤＵ（２２４）は、同様にネットワークレイヤ・プロトコルデータユニット（２２６）を運ぶ。これらのそれぞれは、ヘッダ、ペイロードおよびトレーラからなる同様のフォーマットを有し、無線通信業界では、様々な種類のフォーマットが広く知られている。最後に、アプリケーションレイヤＰＤＵ（２２８）が運ばれる（他のプロトコルレイヤが介在してもよい）。アプリケーションレイヤＰＤＵは、配送計画に関するデータ、またはポータブルコンピュータデバイス（例えば、ＤＩＡＤ）と中央配送システムとの間で交換される他の情報を転送する。アプリケーションレイヤＰＤＵのフォーマットは、独自仕様であってもよい。図１５に示すフィールドは、配送計画に関連するレコード（２２９）、および実行すべき活動を示すインジケータ（２３０）を運ぶ。例えば、追加のレコードが配送計画に加えられる場合（例えば、小包集配のための別のサービスストップを示す）、追加のレコードは、何の動作を実行すべきかのインジケータ（例えば、「レコードの追加」）と一緒に、アプリケーションレイヤＰＤＵにより運ばれてもよい。レコードの修正、レコードの削除などの、別のフィールドと機能が規定されてもよい。プロトコルおよびサービス設計の業者なら、ポータブルコンピューティングデバイスと配送サーバとの間で、情報および機能呼び出しを伝達することができる様々な方法を容易に特定するであろう。通常、既存の通信プロトコルが下位レイヤで使用されてもよい。一方、アプリケーション固有のプロトコルは、配送計画関連情報を運ぶように容易に設計されることがある。
【００３３】
小包集配を伝える通信は、出荷システムや中央配送システム以外のエンティティを含んでもよい。図２に、インテリジェント小包ポスト（ｐａｒｃｅｌ ｄｅｐｏｓｉｔ ｂｏｘ）（２１４）を開示する。この種の小包ポストにより、顧客は、小包を発送する営業施設での配達車両のストップを要求することなく、集配用の小包を預けることが可能になる。ポストは、サービス車両が通常移動する経路に沿った、便利で目に付く場所に通常置かれる。インテリジェント小包ポスト（２１４）は、小包が預けられたときにそれを検出する適切なセンサを有し、無線通信システム（２１０）を使用して中央配送システム（２０８）に無線で通知してもよい。同様に、中央配送システム（２０８）は、サービスストップが必要なとき、小包ポストのサービスを担当する適切な車両を決定し、その車両に通知してもよい。図２で、車両Ｂ（２１８）は、小包ポストに立ち寄り、小包を集配するように通知を受ける。このスキームにより、小包ポストが実際には空のときに、小包を収容しているかどうかを判定するために、運転手が小包ポストに立ち寄る必要性がなくなる。
【００３４】
配達期間中に追加の小包が車両に割り当てられることとなる状況に関係なく、中央配送システムは、各配達車両の現在のサービス担当地域と関連して、集配の地理的位置に基づき、または場所、作業量若しくは車両に関する他の要因を考慮して、どの配達車両が要求を担当するのに最適かに基づき、小包を取り扱う車両を選択してもよい。例えば、図２では、小包（２０４）がある地理的地域を車両Ａ（２１６）が担当しているので、車両Ａ（２１６）が選択されてもよい。あるいは、車両Ａが２番目に近い車両であっても、車両Ｂが小包集配を割り当てられた場合に達成が困難になる配達時間保証を有しているときは、車両Ａが選択されてもよい。対象車両がどのように選択されるかにかかわらず、中央配送システム（２０８）は、適切な派遣車両に更新情報を無線送信する。
【００３５】
実際には、他の種類の情報も、配送計画の実行および配達時間保証の達成に影響を及ぼすことがある。配送計画の将来の実行達成を妨げる潜在的な影響を判定することは、「危機」、「危機状況」、「サービス保証危機」または「スケジュール危機」と呼んでもよい（他の同様な用語を使用してもよい）。危機状況であると判定した場合、ポータブルコンピューティングデバイスのプロセッサは、実行すべき残りのサービスストップを分析し、保証を満足するために残りのサービスストップを最適化する再順序付けが適切かどうかを判定してもよい。前述のように、すでに実行したサービスストップに関しては、検討の必要はない。配送スケジュールに影響を及ぼし、最初の配送計画の更新のきっかけとなる、よくある種類の入力を以下に記述する。
【００３６】
［積荷目録および配送計画］
積荷目録（ｍａｎｉｆｅｓｔ）は、通常、配達すべき積荷のリストと定義される。この実施形態では、積荷は配達用の小包を含む。しかし、本発明の原理は、小包、手紙、部品、手荷物等を含む他の種類の品物の配達にも適用できる。また、本発明は、所定の場所に派遣されるサービス要員が行うサービス（ｒｅｎｄｉｎｇ ｓｅｒｖｉｃｅｓ）に適用してもよい。従って、「積荷目録」を配達される品目の観点から検討するが、他の状況では、用語「積荷目録（ｍａｎｉｆｅｓｔ）」は、実行すべき作業活動のリストと広く解釈できよう。積荷目録は、通常、「配達積荷目録」すなわち配達用小包のリストであり、通常、小包についての関連情報を含む。しかし、積荷目録は、集配すべき小包の情報も含んでもよい。この状況は、積荷目録を「集配積荷目録」と記述することで区別してもよい。本明細書中で限定なしで使用するとき、積荷目録は、集配、配達または必要な他の特定の活動のいずれかで予定される商品に関する情報を有すると、広く解釈してもよい。
【００３７】
積荷目録が作業を実行する順番を表して配列される場合、配送計画（Ｄｉｓｐａｔｃｈ Ｐｌａｎ）と呼んでもよい。あるいは、配送計画は、積荷目録から導き出した別の情報セットであってもよい。一般に、配送計画は、積荷目録を順序付けした系列と概念的に考えられるが、後で示すように、データベースを使用して積荷目録および配送計画を格納および体系化する種々の方法があり、データの論理的な表現は、一定の実施またはデータ構造を必要とするとは解釈されない。
【００３８】
［配達積荷目録更新］
通常、小包配達車両は、小包中央仕分け施設で当日配達用の小包を積み込み、経路に出発する。運転手は、配達、集配または他のサービス関連情報についての情報を含み、ＤＩＡＤにダウンロードされた配送計画（この場合もやはり、配送計画は積荷目録の順序付けした系列と見なしてもよい）のコピーを提供される。配送計画情報は、通常、荷受人（宛先住所）および関連する小包サービスレベルおよび／または配達保証時刻（配達時間保証）を含む。サービスストップ、配達または他のサービス活動に関連する情報の各グループは、データベースのレコードと見なしてもよい。従って、配送計画は、一連のレコードを備えると見なしてもよい。また、各レコードは、例えば、一定の配達時間帯、場所の案内、好ましい配達場所、出荷事務員名等の顧客固有の要件に関する追加情報を含んでもよい。他の実施形態では、配送計画の更新は、運送業者と提携している取扱店などの代替場所に小包の宛先変更という顧客要望を反映してもよい。関連情報は、同時継続出願で、２００３年１２月２２日に出願の米国特許出願第１０／７４５，４６８号、「発明の名称：Ｍａｎｉｆｅｓｔ Ｇｅｎｅｒａｔｉｏｎ ａｎｄ Ｄｏｗｎｌｏａｄ Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ（積荷目録生成およびダウンロードシステムならびに方法）」、および２００２年８月２３日出願の米国特許出願第１０／２２７，１４７号、「発明の名称：Ｐｏｒｔａｂｌｅ Ｄａｔａ Ａｃｑｕｉｓｉｏｎ ａｎｄ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ ａｎｄ Ａｓｓｏｃｉａｔｅｄ Ｄｅｖｉｃｅ ａｎｄ Ｍｅｔｈｏｄ（携帯データ収集管理システムおよび関連装置ならびに方法）」に見つけることができる。それらの内容は、引用により本願に組み込まれる。
【００３９】
従来は、所与の日の作業活動用の積荷目録データまたは配送計画は、一旦運転手に提供されると、修正されなかった。しかし、図２を参照して検討したように、新技術は、車両が経路でのサービス開始後に、配送計画の更新を可能にする。配送計画の遠隔更新に加えて、配送計画情報は、運転手または他のローカルコンピューティングデバイスによりローカルで修正されてもよい。例えば、第２の積み込み場所にストップし、配達用の追加の小包を受け取った運転手により、配達用の追加の品物が追加されてもよい。情報は、手入力されてもよいし、またポイント・ツー・ポイント接続の別のローカルコンピュータまたはＤＩＡＤから受信されてもよい。配達車両のスペースに、配達車両への１回の積み込みで１日分の全配達物を運ぶことができないような制限がある場合、第２の積み込み場所を使用することは役に立つ。あるいは、車両は、第２の配達車両から小包を移し変えることにより、途中で小包を受け取ってもよい。第２の配達車両が故障し小包の積み下ろしが必要な場合、または２台の車両間の負荷を均等にするために小包を移し変えるとき、これは発生することがある。そのような状況は、季節的なある種の出荷のピーク時によく起こる（例えば、休暇時期の配達）。
【００４０】
［集配配送計画更新］
集配配送計画は、集配を行うべき順番を表わすように順序付けられている、集配するべき品目の積荷目録と見なしてもよい。一旦順序付けられると、集配積荷目録は集配配送計画と見なしてもよい。集配配送計画は、前述の無線通信方法の使用を含む幾つかの方法で修正されてもよい。集配配送計画の修正の中には、再検討の必要性が生じ、場合によってはサービスストップの順番を変更する場合があるのに対して、配送計画の修正の中には順番を変更しない場合もある。その後の配達の順番を変更しない積荷目録の変更の一例は、顧客が、集配される小包のサービスクラスを変更するときである。例えば、小包集配は元々２日配達サービスクラスと示されていたが、サービスクラスが通常の陸輸送に変更されると想定する。中央仕分け施設における小包のその後の取り扱いは変更されることもあるが、小包を集配する車両の配送計画は、通常、サービスレベルの変更によって影響を受けない。配達車両は、依然として小包を集配すべき場所でサービスストップしなければならず、その後の集配の順番を変更する必要はない。
【００４１】
配送計画の達成または実行に影響を及ぼさない変更、すなわち、その後のサービスストップのスケジュールに悪影響がない配送計画の変更には、他の例もある。例えば、顧客による小包集配の取り消しは、車両がその場所にストップする必要がなくなることがある（その場所への配達はないと想定する）という点で配送計画を変更するが、この種の変更は、運転手に追加の時間要件を課さない。同様に、集配する小包数の減少は、追加の時間要件を課さない。どちらかと言えば、そのような変更は、元のスケジュールと比較してスケジュールの実行を前倒しにする。
【００４２】
しかし、集配配送計画の他の変更は、その後の作業活動に影響を及ぼすことがある。例えば、顧客が集配用の小包数を増加する場合、特に大幅に増加する場合、運転手が必要とする追加の時間は、当日の残りの作業のスケジュールに影響を及ぼすことがある。また、車両への追加の小包の積み込みは、スペースの問題を生じ、小包の整理に影響を及ぼし、かつその後の配達で他の小包を仕分けし見つけるために、運転手が必要とする時間を増すことがある。
【００４３】
集配配送計画に起こり得る別の修正は、前もって予定されていない場所での集配を加えることである。ポータブルコンピュータにダウンロードされた配送計画に盛り込まれるべき情報に関して、顧客が集配用の小包を準備するのが間に合わなかったときによく起こる状況を、これは反映する。しかし、その情報は、サービス車両の出発後、前述の無線通信を使用してＤＩＡＤに提供されてもよい。これは、小包を集配するために作業スケジュール（例えば、サービスストップのスケジュール）の変更を必要とする。この種の作業スケジュールの修正は、運転手に追加の時間を必要として、常に作業スケジュールに影響を及ぼす。しかし、集配に必要な追加時間は、配達の実施が既に予定されている場合、最小限で済む場合がある。運送業者によっては、配達を遅らせるのを避け、且つ集配する小包のために車両スペースを作るために、配達後に集配を行うように段取りするところもある。
【００４４】
［種々の出来事］
最後に、サービスストップのスケジュールに影響を及ぼす可能性のある他の不測の要因がある。例えば、集配を行った後で運転手は、小包を顧客に返さなければならないと気が付くことがある（例えば、破損している、包装またはラベルが不適切である、有害な液体が漏れている等）。このことは、小包の返却または特別の取り扱いを反映するために、運転手が集配積荷目録の修正をすることを必要とすることがある。商品配達の経験が豊富な者であれば、配送計画の他の種類の例外および修正が起こり得ることをおそらく了解するであろう。
【００４５】
［天候更新］
気象状態は、通常、配送計画の実行に影響を及ぼす。暴風雨または吹雪などの荒れ模様の天候は、一般に交通を妨げ、スケジュールを遅らせると予想され得る。天気予報は周知の科学ではあるが、配達経路に沿った当日の以降の天候が正確にどうなるかを始業時に予測するほどには、特定の場所の予報はまだ十分に信頼できない。予想外の厳しい気象状態は、経路の一部に影響を及ぼし、サービス車両の配達スケジュールに悪影響を及ぼすことがある。従って、天候は、当日の配達の開始後、配達計画のスケジュールに影響を及ぼすもう1つの状況である。
【００４６】
［交通状況］
交通状況は通常予測が困難であり、たいてい起こったことに反応する方法で報告される。これには、事故の発生、渋滞、道路建設等が含まれ、そのすべてが交通に影響を及ぼす。経験豊富な配達車両運転手は、標準的な交通量および交通状況のプロファイルを自己学習的に作り上げることがあるが、異常状況は常に起こり得る。よく起こる１つの出来事は、道路の閉鎖である（例えば、建設、緊急道路修理、天候が原因の倒木、道路冠水等）。多くの場合、運転手は、その場その場の通信（例えば、ラジオ速報、個人的な電話の呼び出し等）を受信してもよく、配送計画の経路を修正するために個人的知識を役立ててもよい。配達時間保証が存在する場合は、予想配達時刻を見直しするのが適切である。
【００４７】
［他の状況］
他の様々な状況および出来事が、配送計画の実行に関して配達車両のスケジュールに影響を及ぼすことがある。各状況は、必ずしもサービス配達時間保証を達成する能力に悪影響を及ぼさない。悪影響が発生するかどうかは、配送計画に関して状況の深刻さの見積りを必要とする。
【００４８】
［プロセス概観−主要構成要素］
図３は、配送計画を更新するために使用される高レベルプロセスの一実施形態を示す。明らかとなることだが、プロセスの変形形態でも、依然として本発明の原理を具現することは可能である。
【００４９】
図３で、積荷目録データ（２０）は、配達車両に関する所与の作業日の配達データを表す。積荷目録データは、小包配達および集配の両方に関する情報を含む。積荷目録データは、配達用のファイルと集配関連データ用の別ファイルの、２つの個別ファイルとして実装されてもよいし、また１つのファイルとして実装されてもよい。他の実施形態では、積荷目録データは、サービス訪問を含む他のデータ、またはサービスストップに関する他のデータを有してもよい。この段階では、積荷目録データ内のレコードの順番は重要でない。一旦順序付けられると、積荷目録データは、配送計画と見なしてもよい。
【００５０】
積荷目録データを表すデータベースファイルの説明用のフォーマットを図９に示す。図９では、積荷目録データテーブル（１３１）は、数行すなわち数レコードからなる情報を有する。各レコードは、サービスストップに関する情報の、互いに独立した収集物と見なしてもよい。レコードが、サービスストップの実行を容易にする特定の順番に並べられているので、テーブルは、配送計画と見なしてもよい。
【００５１】
各レコードの収集情報は、数列すなわち数フィールドの情報を備える。通常、積荷目録には、もっと多くのフィールドの情報が含まれるが、図９では、ほんのわずかのフィールドだけを示す。例えば、名称、通り、市等はすべて個別のフィールドであってもよい。他のフォーマット、順番および各フィールドの構造も可能である。１列目は、小包識別子であり、小包問い合わせ番号（１３６）を提供することが示されている。テーブル（１３１）で、配達すべき各小包は、問い合わせ番号または他のある種の小包識別子により特定され、この識別子は、テーブルのインデックスとして使用される。他の実施形態では、テーブルは、他の種類のサービスに関連するサービスストップを表してもよく、最初の列は、作業順序番号を表してもよい。代わりに、住所がインデックスとして使用されてもよい。しかし、テーブル（１３１）は、代表的な実施形態として小包配達サービスに基づき、本発明の原理を説明するのに十分である。
【００５２】
次に、荷受人または荷送人の住所情報を（１３７）に示す。小包が配達に関する場合、荷受人住所（宛先）が提供される。小包が集配される場合、住所は荷送人（小包の発送人）を示す。次の列は、ストップに関する小包番号（１３８）を示し、１つのサービスストップにおける複数の小包間の連結を可能にする。例えば、配達は、幾つかの小包を含んでもよく、連結は、通常、所与のストップに関する全小包間で行われる。これにより、配達要員は、配達が必要な小包すべてを確実に配達できる。テーブル（１３１）に提示する例では、Ｐｅｒｒｙ漬物店のサービスストップに関連する２個の小包（１５４ａ、１５４ｂ）がある。次の列（１３９）は、ストップが集配かそれとも配達かを示す（Ｐｅｒｒｙ漬物店の例では、２個の小包が配達される）。他の場合には、サービスストップは、配達と集配の両方を含むこともある。最後に、もう１つの列は、示されている場合、小包に関する配達保証時刻を提供する。図９の例では、Ｐｅｒｒｙ漬物店に配達される小包の１個は、配達保証時刻午後４：００（１３５）を有する。
【００５３】
多くのフォーマットおよびファイル構造の変形形態が可能であるが、図９には、本発明の例示目的で一実施形態だけを示す。例として、配達と集配とを論理的に分割したファイルが実装されてもよい。また、個別の論理的順番インジケータファイルが、サービスストップの順番を示すために、積荷目録データと併せて使用されてもよい。その順番は、積荷目録の住所情報により定められるであろう。また、追加情報は、通常、サービスレベル、発送人情報、小包を取り扱う内部仕分け施設、重量などの各小包に関する。本発明の原理を示すためには、配送計画または積荷目録に収容可能な全情報を示す必要はない。また、ＰＬＤ情報の中には次のサービスストップを効果的に特定するために必要でない情報があるので、配送計画の作成に積荷目録情報のサブセットを使用することは可能である。
【００５４】
図３に戻って、図示の別の構成要素は経路計画（２２）である。図３の経路計画（２２）は、配達車両が移動する経路に関する情報を備える。通常、経路は、事前に決定された地理的地域内に限定され、特定の順番で移動する道路のセットを備える。道路の領域はたいてい地理的に限定される（例えば、配達地域は町、郡または州の限定された区画内に境界が定められる）。これは、サービス車両の派遣に確定したサービス担当地域が使用されるときの、典型的な状況である。他の実施形態では、地理的地域は非常に大きくてもよく（例えば、州または国の区画）、論理的に無制限または際限がないと見なしてもよい。例えば、引越しサービスは、米国本土でサービスを提供してもよい。このサービス担当地域の制限はないと見なしてもよいが、実際は限定されている。状況によっては、制限のないサービス担当地域は、定まった移動経路を持たない地域と見なしてもよい。
【００５５】
本明細書で提供する実施形態では、経路計画はいくぶん静的である。すなわち、経路は、配達が頻繁に行われ、定期的に移動に使用されるパスを反映する（しかし、必ずしも、あらゆる道路のあらゆるストップではない）。静的な経路に加えて、ビジネスの状況では、配達は一般に同じ時刻に行われるのが望ましい。例えば、小包の収集と配達は、所与の場所で毎日ほぼ同時刻に行われるように計画されてもよい。他の状況では、サービスストップは何時に行われてもよい。例えば、小包配達サービスではなく、修理サービスに関してサービス車両を派遣する場合、配送計画のストップの順番を決定するために、サービス訪問の優先度が使用される。通常、修理車両の派遣は、以前のサービス訪問に関する修理車両のその場所への到着時刻の実績には基づかない。他の状況では、営業施設への配達は、従業員が他の活動を調整できるように（例えば、営業施設で配達物を受け取る従業員が休憩時間をいつ取るべきか（またはある時刻に休憩を取るのを避けるべきか）わかる）通例の時間フレームで行う、あるいはその反対に、簡単に中断できない仕事が始まる時刻を避けることが望ましいことがある。
【００５６】
経路計画（２２）は、所与の地域で配達を実行する１台の車両に対するものでよいし、また車両のグループを考慮してもよい。実施形態によっては、顧客に特定の順番でまたは通例の時刻に配達物を受け取りたいという好みがないとき、動的経路計画が使用されてもよい。経路計画は、実績平均、好ましい配達時刻などの他のデータと関係なく、積荷目録データにより部分的には決定されてもよい。
【００５７】
経路計画（２２）は、種々の方法で表されてもよく、部分的にはどのようにデータが操作され提示されるかに依存する。場合によっては、ＧＩＳ（地理情報システム）ベースのシステムが利用されてもよい。他の実装は、配達ストップのテーブルリストを提供してもよい。経路計画は、実際の配達計画（例えば、配送計画）ではなく、最初の配送計画を作成するために使用される参照モデルなので、必ずしもポータブルコンピュータに組み込まれなくてもよいし、運転手に提示されなくてもよい。
【００５８】
経路計画を概念的に説明するために、図８は、潜在的なサービスストップのテーブルリストに基づく一実施形態を示す。図８では、経路計画データ（１１７）は、一連の住所を備える。図８は、メインストリートにある商店に対応するレコードのサブセットを示す。各レコードは、小包配達かそれとも小包集配のための潜在的なストップを表す。住所（１１１）は、レコード番号（１１６）と呼ばれるインデックスに関連し、そのレコード番号は選択した住所の処理を容易にする。経路計画の住所は、通常、所望の配達計画に相当する順番で記載されているのが好ましい。例えば、テーブル（１１７）によれば、Ｎｅｉｌｌ新聞販売店（レコード（４３６））はＭｅｒｅｄｉｔｈ食堂（レコード（４３７））の前に記載されているので、両方の場所に配達が行われた場合、Ｎｅｉｌｌ新聞販売店への配達がまず行われるであろう。
【００５９】
この実施形態は、多数のレコードを格納することになり、各レコードは、所与の日の実際のサービスストップではなく、潜在的なサービスストップを表す。他の実施形態は、一連の住所の範囲で経路を表してもよい。これは、格納スペースを節約し、見易い形式でデータの提示を可能にする。このデータは、ポータブルコンピュータから切り離して格納され処理されてもよいので、メモリ要件、処理スピード等はポータブルコンピュータに関する要因ではない。従って、経路計画の住所は、個別の所在地および居住者名の記載なしに、範囲で表されてもよい（例えば、「メインストリート１００〜３００」）。この方法は、新しい居住者がその住所に関連するときに毎回データを更新しなければならないということを回避することができる（例えば、居住者の所在地からの引っ越し／所在地への引っ越し、または商店の移転、開店若しくは閉店）。
【００６０】
要約すれば、図３における経路計画は、配達車両が取る一般的経路を示すのに対して、積荷目録データは、所要のサービスストップに関するデータを示す。積荷目録データは、必ずしもサービスストップへ配達する所望の順番を反映して編成または論理的に順序付けられていないので、当初すなわち最初の配送計画（２４）を作成するためには、データを順序付ける形態の追加処理（２５）が必要である。図３の最初の配送計画（２４）は、配達車両の運転手が実行するサービスストップを順序付けしたリストである。概念的に、配送計画を作成する処理（２５）は、経路データに基づき配達場所の逐次的順番を反映するように、積荷目録データを単に処理（２５）するものであってもよい。
【００６１】
最初の配送計画（２４）を作成するために、様々な方法が可能である。配送計画は、様々な配送業者が長年にわたり使用しており、本発明の範囲外である。配送計画は当業者には周知であり、いくつもある有名な配送ソフトウェアアプリケーションにより作成されてもよい。ソフトウェアアプリケーションの中には、ＲＯＡＤＮＥＴ５０００ＴＭ、Ｔｅｒｒｉｔｏｒｙ ＰｌａｎｎｅｒＴＭ、およびＭｏｂｉｌｅｃａｓｔＴＭがある。最初の配送計画（２４）は、ポータブルコンピュータにダウンロードされ、グラフィック、テーブル（例えば、テキスト指向の）、または両方を含む様々な方法で構造化されてもよい。最初の配送計画のデータを積荷目録データおよび／または経路計画データと同様に構造化すると、効率的なこともあるが、これは、本発明の原理から恩恵を得るためには必須ではない。
【００６２】
図３は、ポータブルコンピューティングデバイスが処理（２９）してもよい様々な更新／入力（２６）も示す。更新／入力（２６）は、最初の配送計画の更新または修正を開始させ、ひいては更新配送計画（２７）を作成する。更新／入力（２６）は、気象情報、交通情報および積荷目録変更を含む前述の入力を含む。ポータブルコンピュータによる入力の処理（２９）は、更新／入力が最初の配送計画の残りの配達に影響を及ぼすことがあるかどうかをまず判定することを含む。すべての入力がその後の配達に影響を及ぼすわけではなく、影響があるかどうかを判定するために、様々な方法およびデータが使用されてもよい。
【００６３】
例えば、処理（２９）は、実績データ（２８）を収容するファイルにアクセスしてもよい。実績データは、最初の配送計画を更新するかどうか、およびどのように更新するかを判定する補助材料として使用してもよい参照データである。その実績データは、経路計画（２２）を決定するために使用される個別プロセス（図示せず）で使用される実績データのサブセットであってもよい。ポータブルコンピュータに格納された実績データ（２８）は、１台のサービス車両のサービス担当地域にだけ限定される必要がある。実績データの内容は、業務アプリケーション、メモリ要件、および分析される入力の種類に基づき変わってもよい。例えば、実績データは、当日の積荷目録の完了したサービスストップ（例えば、完了した配達または集配）を示してもよい。運転手が既に完了した配達は、天候または交通などのその後の展開によって影響されないので、更新配送計画を作成するために分析されなければならないのは、配送計画内の残っている配達だけである。図３が実績データと積荷目録データとを別に図解しているのは、概念的な目的だけであり、実績データがどのように格納されるかを限定する意図はない。実施形態によっては、どの配達／集配が完了したかの表示は、積荷目録データまたは配送計画と併せて格納される。従って、概念的に、実績データのこの部分は、配送計画の拡大と見なしてもよい。通常、配送計画内のサービスストップ完了フラグは、サービスストップが完了したことを示して記録される。どのように表示が記録されるかにかかわらず、過去の配達を表示するデータは実績データとしてモデル化してもよい。
【００６４】
実績データ（２８）は、他の種類の実績データを備えてもよい。実績データは、潜在的な配達ストップのそれぞれに関する時刻および所在地情報の移動平均実績を備えてもよい。この種の情報は、現在の状態を比較することができる参照項目の役割を果たす。
【００６５】
実績データのこの側面は、配送計画の実行がスケジュールどおりか、それともスケジュールより遅れているかを判定する基準を提供するために使用される過去の配達情報を蓄積することにより、運転手の「経験」の側面をある程度捉える。スケジュールより遅れている場合、最初の配送計画内の残りの配達を修正（例えば、再最適化）する必要がある場合がある。例えば、ある経路に経験豊富な運転手は、既知の目印の場所と現在時刻とを比較し、これらの目印に出会ったときの過去の経験とを頭の中で比較することにより、１日を通して実施状況を評価する。あるいは、現在の時刻と所要の仕事の進捗状況とを比較してもよい。所与の経路の過去の平均時刻および場所の測定結果に対して配達車両の現在時刻および場所を比較することにより、相当の「経験」がシステムに組み込まれてもよく、それにより、スケジュール進捗状況（「進んでいる」、「遅れている」または「スケジュールどおり」）の判定と、残りのサービスストップの完了に必要な時間とを決定できる。
【００６６】
更新配送計画（２７）を作成する処理（２９）は、最初の配送計画（２４）を作成するために使用される処理（２５）とは、通常は同じではない（それ故、処理アイコン（２５）と（２９）は、別に表示してある）。最初の配送計画の処理は、メインフレームで行われてもよく、複合サービス担当地域内の車両グループに対する小包配達情報の処理を含む。更新配送計画の処理は、その性質から、当初の配送計画の変更が適切かどうか、その変更をどのように行うべきかを判定するために、１つの既存の最初の配送計画のサブセット（例えば、まだ実行されていないストップ）に関して、特定の入力を処理する。前述のように、配送計画の更新または入力が、常に、残りのサービスストップの実行またはその順番に影響まで及ぼすというわけではない。サービスストップの順番の修正が必要である場合、個別のプロセスが、最初の配送計画を修正して、更新配送計画を作成してもよい。最初の配送計画を修正するプロセスは、最初の配送計画を確立するプロセスとは異なる。その異なる点は、新配送計画は、局部的な状態を考慮し、前に決定された特定の配送計画に関する配達時間保証を果たすように、１台の配達車両に関して作成されることである。また、最初の配送計画の修正は、通常、少なくとも一部は実績データ（例えば、既に配達した小包）を考慮に入れるのに対して、最初の配送計画は、まだ配達されていない小包のリストから始まる。従って、状況が最初の配送計画の更新を正当化する場合、更新配送計画の算定は、最初の配送計画の算定に使用されたプロセスとは異なるプロセスを使用して通常は算定される。
【００６７】
最初の配送計画のデータ構造と更新配送計画のデータ構造とは、通常はよく似ている。このことは、データの処理およびユーザへの提示（最初の配送計画または更新配送計画のどちらか）を容易にする。以下に検討するように、ユーザに配送計画を提示するフォーマットは、様々な形式であってもよい。
【００６８】
最初の配送計画の更新は、様々な方法で行われてもよい。更新には、レコード情報の変更、レコードの追加、レコードの論理的順番の再順序付け等を含んでもよい。場合によっては、最初の配送計画の更新は、再最適化（例えば、ストップの再順序付けのための順番の分析）を必要としない。配送計画の実行に悪影響を及ぼさない様々な種類の積荷目録更新があることを想起されたい。他の場合には、更新は配送計画の実行に影響を及ぼすこともあるが、順番の分析を正当化しないこともある。例えば、ある通り上の既存のストップと同じ通り上の直ぐ手前に新しいサービスストップを単に追加するだけであれば、再順序付けすべきかどうかを判定するための、レコードの順番の分析を正当化することはないであろう。しかし、異なる道路上に新ストップを追加することは、最適化が妥当かどうかを判定するために、レコードの順番の分析を正当化してもよい。また、最初の配送計画を更新するかどうか、およびどのように更新すべきかを判定するために、例えば業務規定などの異なる基準を適用してもよい。例えば、予定外のストップを追加することにより配送計画が更新されるが、その後の配達保証時刻はないと想定する。従って、残りのサービスストップに関しては、どの時刻またはどの特定の順番で実行されるべきかの制約はない。業務規定は、最適化経路を反映するために残りのストップを再順序付けするようには、配送計画の分析を指示しなくてもよい。しかし、まだ実行されていないサービスストップの１つが時間保証を有する場合、残りのストップの分析および再順序付けは望ましい場合がある。
【００６９】
また、業務利用によっては、更新配送計画を決定するために使用される基準を規定してもよい。利用によっては、最適経路（例えば、移動距離）を必要としてもよいのに対して、他の業務利用では、移動距離が最適でない場合であっても、最初の配送計画からできるだけ逸れない経路の使用を選択してもよい。例えば、定期的にサービスストップをしている配達サービス会社は、最初の配送計画に関連する通常の予定到着時刻からできるだけ逸脱しないことを望んでもよい。これにより、配達車両はいつもと同様の時刻に配達を完了し、配達時刻帯に関して顧客の期待を維持することができる。このことは、小売店や商売をしている顧客などの小企業を担当するとき、重大である場合がある。従って、都市環境では、小さな小包配達サービス会社は、運転距離が少し長くなる場合でも、一定の交通パターンを避けるためかまたは配達時刻を維持するために、一定のスケジュールの維持を選択してもよい。５０マイルの都市経路で、運転距離が１０％増になる小さな逸脱は、５マイルの距離の追加になる。利用によっては、これは許容出来る場合がある。他方、全国的に配達サービスを提供するトラック運送会社は、元の予定配達時刻からより大きな逸脱を意味する場合であっても、最も効率的な配送計画の維持を選択してもよい。移動距離２０００マイルを伴う配送計画に関しては、運転距離１０％（例えば、２００マイル）増は、許容出来ない場合がある。さらに、トラック運送会社による所与の受取人への配達は、不定期である場合があり、荷受人は何時でも容易に配達を受け入れる場合がある。
【００７０】
要約すれば、業務規定は、レコードの再順序付けが必要かどうか、または望ましいかどうかを判定するとき、更新配送計画をどのように、ならびに何時検討するかに影響を及ぼす。本発明の原理は、更新配送計画を作成するために最初の配送計画をどのように／何時変更すべきかを判定する様々なアルゴリズムを網羅する。
【００７１】
図３のアイコン（２９）が表わす処理を具現するシステムを図４に示す。図４を参照して、配送マネージャ（ＤＭ）（４５）は、様々な入力を受け取るプロセスまたはソフトウェアモジュールであり、配送計画の更新が適切かどうかを判定する。ＤＭは、ユーザおよび他のプロセスから入力を受け取るのに加えて、ユーザに提示した情報も管理してよい。
【００７２】
ＤＭが受け取る入力の１つの種類には、ローカル入力（４６）を含む。ローカル入力は通常ユーザ入力であり、図４のシステムを内蔵するポータブルコンピュータ（例えば、ＰＤＡ、ラップトップまたは他のデバイス）のキーパッドから入力される。キーパッド入力は、「ソフトキー」の使用によりユーザが示す様々な機能を含んでもよい。ソフトキーは、操作状況によって機能を変更可能なキーであり、ディスプレイ情報と一般的なキーパッドとを関連付けることにより通常実装され、キーパッドの機能はディスプレイに示される。この方法で、キーパッドに関連する機能はプログラムで定めるように変更可能である。
【００７３】
他の形態の入力には、定評ある音声認識アルゴリズムの使用に基づく音声入力を含む。音声認識は、より便利な入力手段として、ユーザが頻繁に使用するコマンドに対して使用されてもよい。「ポインティングデバイス」（タッチパッド、マウス、ジョイスティック等を含む）の種類を通常使用する入力の選択は、データ入力の別の手段である。最後に、システムはセンサからも様々な入力を受け取ることができる。センサは、小包の配達に遅れをもたらしそうな配達車両に関する状態を検出してもよい。例えば、サービス車両のエンジン故障状態は報告されてもよく、ＤＭは、運転手または他のシステムに、配達遅延の可能性を警告するであろう。これらの入力は、無線または有線接続を介して受信されてもよい。
【００７４】
ＤＭは、遠隔入力（４７）に分類される入力も受信してもよい。遠隔入力は、無線通信インタフェースに関連するアンテナ（４８）を介して通常受信される。遠隔データ入力は、主として配送サービスからデータの受信を可能にし、追加のサービスストップの指示、特定の小包に対する所要配達時刻の変更、最新の交通状況および気象状態などで配送計画を修正する。
【００７５】
ＤＭは、ポータブルコンピューティングデバイスの現在位置をＤＭに提供するＧＰＳデバイス（３２）からも入力を受け取る（ポータブルコンピューティングデバイスは、サービス車両の場所を近似するために使用されてもよい）。この入力は、通常、経度および緯度の測定値の形態であり、継続的に更新され、周期的にＤＭに提供される。ＤＭは、現在時刻情報を提供する時計（３３）からも入力を受け取る。実施形態によっては、ＧＰＳデバイスは現在時刻情報を提供してもよい。
【００７６】
ＤＭは、現在位置と現在時刻を使用して、経路に沿った車両の位置と予定場所および時刻とを比べてもよい。これには、実績データ（例えば、過去の配達関連時刻および位置データを含む）の使用を伴い、それにより、ＤＭは、本日の配送計画の実行がスケジュールどおりか、スケジュールより遅れているか、またはスケジュールより進んでいるかの見込みを判定することが可能になる。この比較を実行するために、ＤＭは、実績配送位置および時刻データ（３６）を含む実績データを収容するデータベースにアクセスする。実績位置および時刻データは、様々な形態で格納されてもよく、所与の位置に関する標準的な時刻の移動平均を含んでもよい。
【００７７】
ＤＭは、様々なユーザの好み、オプションおよびデフォルト値を選択するために使用される、管理パラメータ（３４）の形態のデータにもアクセスしてもよい。これについてはさらに検討する。明らかになるように、処理の様々なオプションが可能であり、管理パラメータは、ユーザまたは特定のアプリケーション用にカスタマイズされたデフォルト値の選択を可能にする。例えば、都市環境では、道路地図を使用する配送計画のグラフィック描写は、不必要な場合もあるし、また望ましくない場合もある。それに対して、田舎の環境では、サービスストップを表す印を使用した道路地図の形態による配送計画のグラフィック描写は、望ましい場合がある。
【００７８】
ＤＭは、積荷目録データ・データベース（４０）（これは最初の配送計画として具現されてもよい）、配達完了データベース（４２）（これも最初の配送計画内に具現されてもよい）、および場合によってはＧＩＳ（地理情報システム）データベース（４３）にもアクセスする。前述のように、積荷目録データは、当日の小包配達および小包集配に関する情報を含み、配送計画を作成するために順序付けされてもよい。配達完了データは、完了した配達（または他の種類の作業活動）に関するデータを示し、実績データ（３６）、配送計画（３８）、または積荷目録データ（４０）内にも具現されてもよい。例えば、サービスストップを表す配送計画内の各レコードに関する完了インジケータまたは完了フラグの設定は、代表的な実施形態である。従って、図４は論理的種類のデータを図解するが、データの実施形態は、様々な形態で行われてもよい。例えば、配達完了データは、個別の論理データベースであってもよいし、またそれを積荷目録データまたは実績データと合同して実装してもよい。これらの実装オプションは、可能な様々な実施形態を反映する。
【００７９】
また、「配達完了」と呼ぶが、このデータは、完了した小包集配を含む他の種類の非配達関連データを含んでもよい。始業時、配達完了データベース（４２）は、基本的に空である（配達は少しも完了していないので）。配達日の終了までには、配達完了データベース（４３）は、積荷目録データ・データベース（４０）と基本的に同じサイズである（積荷目録の項目はすべて配達されているので）。
【００８０】
管理パラメータにより規定されるこれらの様々な入力およびパラメータに基づき、配送マネージャ（４５）は、配送計画更新アルゴリズム（３０）に最初の配送計画を更新するように命令する。更新配送計画を決定するアルゴリズムは、様々な既存のアルゴリズムに基づいてもよいし、管理パラメータ（３４）に保持されるであろう様々な業務規定により規定されてもよい。更新配送計画（３５）を作成するために、配送計画更新アルゴリズム（３０）は、配達完了データ（４２）および最初の配送計画（３８）へのアクセスに加えて、どの項目が配達されるべきかを示す積荷目録データ（４０）にアクセス可能でなければならない。更新配送計画は、まだ行われていない配達またはサービスストップに関する計画だけに焦点が当てられる。既に完了した配達に関する計画を作成する必要はない。配送計画更新アルゴリズムは、道路および地理的位置情報を考慮して最適配送計画を決定する入力として、ＧＩＳ／経路計画データ（４３）にもアクセスしてもよい。配送計画更新アルゴリズムは、更新配送計画の作成に使用する基準を規定するどの業務規定を使用すべきかを示すパラメータも有してもよい。例えば、管理パラメータは、最初の配送計画を更新するとき、移動距離の最短化が主要な優先事項であることを示してもよい。あるいは、管理規則は、サービス訪問の優先度は移動距離を覆すことを示してもよい。
【００８１】
配送計画更新アルゴリズム（３０）は、一旦更新配送計画を作成すると、通常、前の配送計画である旧配送計画（３８）と一緒に、更新配送計画をメモリに格納する。最新と前の両配送計画は、ＤＭアルゴリズム（４５）によりアクセス可能であり、出力ディスプレイ（４４）上でユーザに表示されてもよい。出力ディスプレイ（４４）は、通常、ポータブルコンピューティングデバイスのビットマップＬＣＤを使用して具現される。各配送計画は、通常個別に閲覧され、ユーザは、どの配送計画を表示するかに関し前後に切り替え可能であってもよい。代わりに、新旧の両配送計画が、同時にユーザに提示されてもよい。旧（以前）と新（現在）の配送計画を維持することにより、ユーザは、システムの処理を比較、拒否または受け入れ可能になる。場合によっては、システムは、「旧」配送計画を保持しないであろう。例えば、配送計画のレコードが修正される場合、システムは、ユーザに更新配送計画を「拒否」するオプションを提示できない。従って、システムは、ユーザに２つの配送計画を閲覧し比較するオプションを提示さえしない場合がある。更新配送計画を作成するために、システムがレコードの順番を再順序付けする他の場合では、ユーザ（例えば、運転手）は、システムが入手できない情報を有する場合があり、更新計画を「拒否」し、その代わりに以前のサービスストップの順番を好む場合がある。一旦運転手が新配送計画を受け入れると、メモリを開放するために旧配送計画を消去し、更新配送計画を現行配送計画と名付けてもよい。
【００８２】
配送計画関連情報のユーザへの表示は、幾つかの形式であってもよい。一実施形態では、配送計画の表示は、一行ずつ、行われる順番にストップを列挙する、表形式またはテキストベース形式であってもよい。レコード内の全情報の表示は必要でない場合があるので、次の５つのストップなどの配送計画のサブセットだけが通常は提示される。通常は、少なくともレコード内のサービスストップの住所は表示される。
【００８３】
代替または追加として、ＤＭは、所要のストップを示すアイコンを使用して経路のグラフィック地図（例えば、道路または通りの地図）を策定するＧＩＳデータベースを使用して、更新配送計画を表示してもよい。ユーザへのデフォルト提示フォーマット選択に関する好みは、管理パラメータ（３４）に収容されてもよい。例えば、図１１は、グラフィック配送計画の一実施形態を図解する。図１１では、ポータブルコンピュータのディスプレイ（１７９）は、配送計画に関連する地図または地図の一部を示す。ディスプレイは、幹線道路のＲｉｄｇｅ Ｖｉｅｗロード（１８０）を示す。車両の現在位置は、アイコン（１８３）を使用して示される。Ｃａｎｙｏｎロード（１８１）およびＲｉｄｇｅｃｒｅｓｔロード（１８２）などの関連する脇道も示される。サービスストップ場所は、短縮した住所情報（通常、通り名だけで、市も州も郵便番号も含まない）で地図上に相対的位置が描画され、運転手は、次のストップに行くために使用すべき経路が容易にわかる。具体的に言うと、現在位置に基づき、第１のストップはＣａｎｙｏｎンロード１０３４（１８４）で、続いてＲｉｄｇｅ Ｖｉｅｗロード５３２４（１８５）等であろう。
【００８４】
図４に戻って、図４のＤＭ（４５）は、配送計画更新アルゴリズム（３０）を自動的に呼び出すべきかどうかを判定するために、入力を使用する。場合によっては、配送計画更新アルゴリズム（ＤＵＰ）は、配送計画を更新し、旧配送計画を消去し、ユーザに変更を通知するであろう（新しいストップが追加される場合）。実施形態によっては、次いで配送計画更新アルゴリズムは、最も効率的な経路を取得するために、場合によってはレコードを再順序付けするように、配送計画の処理を自動または手動で要求するであろう。実施形態によっては、ユーザは、受信入力（例えば、新しいサービスストップの追加）の通知を受け、更新（例えば、新しいサービスストップ）を何処に挿入すべきかを手動で指示してもよい。例えば、ユーザは、システムによって考慮されない外部状況を認識し、自動更新を無効にしたいと望む場合がある。場合によっては、配送計画に影響を及ぼす入力の受信は、ユーザによる入力の検討の必要性を示すために、ディスプレイ上のアイコンをフラッシュさせることにより、および／または可聴信号若しくは他の視覚信号を提供することにより、ユーザの注意を喚起してもよい。その時点で、ユーザは、適切な入力を与えることにより、配送計画の更新を手動で開始させてもよいし、また検討してもよい。実施形態によっては、配送計画の変更（それにより、更新配送計画の作成）が行われてもよく、ユーザに信号で送られてもよいが、潜在的なレコードの再順序付けの必要はないし、またユーザからの許可も必要ない。例えば、集配用の小包のサービスクラスの変更は、サービス経路の再順序付けを通常必要としないであろうし、またレコードを場合によっては再順序付けするために、ユーザに配送計画の処理を手動で開始することも要求しないであろう。
【００８５】
別の実施形態では、配送計画は、グラフィック形式でユーザに提示される。この実施形態では、ポータブルコンピューティングデバイスが配送ファイルの再順序付けまたは構造変更をすることなしに（と言っても、この可能性は除外されない）、ユーザは、サービスストップの順番を自己発見的に、頭の中で再分析および／または再順序付けしてもよい。例えば、図１２を参照して、システムが、Ｒｉｄｇｅ Ｖｉｅｗロード５３２１における小包集配の更新サービスストップを受信したと仮定する。システムは、地図上にサービスストップを表す印（例えば、点、丸または他のアイコン）をオーバーレイすることにより、地図上にこの場所（１８６）を描画する。これは、当業界で周知のソフトウェアを使用して行ってもよい。システムは、ユーザが新情報を容易に特定できるようにするために、新情報を強調表示してもよい（この場所（１８６）は、図１２では二重線のボックスで表されているが、他の実施形態では、テキストの明滅、種々のフォント、色等が、ユーザに配送計画の更新についての注意を喚起するために使用されてもよい）。システムは、画像の閲覧に基づき、運転手が自己発見的に経路を決定するのに頼ってもよいので、システムは、運転手が使用する経路を必ずしも決定しない。このケースでは、運転手はＲｉｄｇｅ Ｖｉｅｗロード５３２４（１８５）での配達の直ぐ前のＲｉｄｇｅ Ｖｉｅｗロード５３２１（１８６）の場所に新しいストップを追加すべきであることは、明らかである。それに対して、経路を両方向に移動する（例えば、Ｒｉｄｇｅ Ｖｉｅｗロードが行き止まりで、Ｒｉｄｇｅ Ｖｉｅｗロード５００３でストップした後で、配達車両が方向転換を必要とする）場合、新しいストップは、経路の戻りの行程でサービスされるであろう。
【００８６】
表ベースのリストでは、配送計画更新アルゴリズムによる更新は、配送計画を構成する既存の一連のレコードに新しい住所を収容するレコードを単に挿入することにより達成されてもよい。ここで、レコードの挿入は、同じ道路上の他のサービスストップと比べた新しいサービスストップの番号の順番（住所により表される）に基づく。従って、配送計画の更新は、一連のレコード内でＲｉｄｇｅ Ｖｉｅｗロード５３２４に関するレコードの直ぐ前にレコードを論理的に配置することにより、新しいサービスストップ（例えば、Ｒｉｄｇｅ Ｖｉｅｗロード５３２１）に対する新しいレコードの追加を伴ってもよい。残りの全ストップに対する最適経路の再分析は必要ない。
【００８７】
新しいサービスストップが、他の既存のサービスストップが存在しない道路に関連している場合、新しいストップを配送計画のどこに挿入すべきかを判定するために、他のアルゴリズムを使用してもよい。例えば、経路を表すデータ構造は、リスト上のどこに新しいストップを配置するかを決定するために使用されてもよい。図１３を参照して、この実施形態では、Ｒｉｄｇｅ Ｖｉｅｗロード（１８０）の住所は、Ｒｉｄｇｅ Ｖｉｅｗ５５００（１８９）で始まり、脇道なしでＲｉｄｇｅ Ｖｉｅｗ５４００（１８８）に続く。Ｒｉｄｇｅ Ｖｉｅｗ５４００（１８８）とＲｉｄｇｅ Ｖｉｅｗ５３９８（１８７）との間には脇道Ｃａｎｙｏｎロード（１８１）がある。それ故、Ｃａｎｙｏｎロード１０３４（１８４）を含むＣａｎｙｏｎロードの住所は、リスト上でＲｉｄｇｅ Ｖｉｅｗロード５４００とＲｉｄｇｅ Ｖｉｅｗロード５３９８との間に配置されるべきである。配送計画が一連のレコードとして実装される場合、Ｃａｎｙｏｎロードに関連するレコードは、Ｒｉｄｇｅ Ｖｉｅｗロード５４００の後で且つＲｉｄｇｅ Ｖｉｅｗロード５３９８の前に論理的に追加されるべきである。様々なアルゴリズムが、そのようなデータを表し、データの更新および効率的な検索を可能にするために使用されてもよいことを、データ構造に関する当業者であれば理解するであろう。
【００８８】
代替スキームは、グラフィック地図を使用して、新しいサービスストップとすべての既存サービスストップとの間の最短距離を判定し、リスト内のその直ぐ前に新しいサービスストップを挿入することである。距離は、最短地理的距離に基づいてもよいし、また道路移動に基づく最短距離に基づいてもよい。これは、必ずしも最も効率的な順番を反映しないことがあるが（一方通行の通りやポータブルコンピュータが知らない他の道路状態が、実際の距離または移動時間に影響を及ぼすことがある）、この簡略化アルゴリズムはアプリケーションによっては好ましいことがある。
【００８９】
前述のプロセスを実行するポータブルコンピュータのハードウェアアーキテクチャの一実施形態を、図５に図解する。これは、ＤＩＡＤタイプのデバイスでも実行されてよいが、個別の汎用コンピュータ（例えば、ＰＤＡまたはラップトップ）およびサービス車両に搭載されたコンピュータも使用されてよい。図５は、ハードウェア構成要素の一実施形態と、その構成要素の高レベル機能および相互作用とを図解する。通常、プロセッサ（５１）は、充電式バッテリ電源（６７）から主として電力供給され、配送計画を動的に更新するプロセスを含む、様々なアプリケーションに関連する命令を実行する。プロセッサは、データバス（５５）を介して様々な種類のメモリと通信する。メモリには、ＲＡＭなどの主（揮発性）記憶装置（５２）を含み、主（揮発性）記憶装置（５２）は、通常、アプリケーションソフトウェア、入力データ（配送計画とは別に格納された場合、当日の積荷目録など）および更新配送計画の結果を格納する。メモリには、不揮発性記憶装置（５３）も含み、不揮発性記憶装置（５３）は、様々なパラメータ、ＢＩＯＳ（基本入出力システム）ルーチン、ならびにシステムおよびアプリケーションレベルのデフォルトデータを格納してもよい。補助記憶装置（５４）は、実績配送データ（３６）およびＧＩＳ（４３）などの他のデータベースを格納できる。様々な実施形態は、部分的には記憶容量および性能要件に基づいて、様々な種類のメモリにデータを格納してもよい。
【００９０】
プロセッサ（５１）は、アンテナ（６５）とデータを送受信できる無線インタフェース（６６）などの様々な構成要素と通信するために、Ｉ／Ｏバス（５６）も使用する。このインタフェースは、免許不要の低電力スペクトラム（様々なＩＥＥＥ８０２．１１標準の１つにより使用されるスペクトラムなど）に基づいてもよいし、また免許を受けたスペクトラム（ＧＰＲＳ、ＥＤＧＥまたはＣＤＭＡベースのデータ通信プロトコルを含むセルラシステムで使用されるスペクトラムなど）に基づいてもよい。無線インタフェースは、前述のように、一旦配達車両が移動中になると遠隔入力を受信するために使用される。主にデータ用に使用されるが、無線インタフェースは音声も伝達できる。
【００９１】
プロセッサは、有線ＬＡＮインタフェース（６４）、電話通信（６３）（インターネットへのアクセスを含む）、または他の種類（６２）（赤外線、高速シリアル通信等を含む）を含む当業界で周知のインタフェースを含む他のインタフェース（６１）を使用しても通信してよい。これらのインタフェースは、作業日の始業／終業時にポータブルコンピューティングデバイスを配送サーバに接続し、データをダウンロード／アップロードするとき、使用されてもよい。
【００９２】
プロセッサは、マウス、タッチパッド、署名パッド、スタイラスなどの様々な形態で具現されてもよい触覚入力デバイス（６０）を含む、他のローカル入力／出力デバイスと通信してもよい。プロセッサは、一般的にキーパッド（５９）からもユーザ入力を受け取り、主としてカラービットマップのＬＣＤディスプレイ（５８）上に情報を表示する。プロセッサは、ユーザからのデータ入力値またはコマンドを認識する音声認識を実行するために、マイクロホン（６９）を介して音声入力も受け取ってもよい。プロセッサは、プリンタ（６８）と通信してもよい。この通信は、システムが配達車両内で動作しているときは通常実行されないが、顧客の構内で行われてもよい。有線接続で図解されているが、プリンタへの通信は無線インタフェース（例えば、ＩｒＤＡ、Ｗｉ−Ｆｉ等）を使用しても行われてもよい。
【００９３】
次いで、図６の、配送更新プロセスへの入力の処理の一実施形態を図解する高レベルのフローチャートを参照する。高レベルでは、システムは入力を受け取り、入力に基づき、配達進捗状況が「スケジュールどおり」かどうか、配達責務の達成に関して問題になる可能性があるかどうか、配送計画に関し残りの作業項目を再検討する必要が有るかどうかを判定してもよい。配達進捗状況が「スケジュールどおり」である（少なくとも配達責務達成が危機にさらされている可能性がないことを意味する）場合、配送計画内の現在の一連のレコードを維持するように（業務規定に基づき）構成してもよい。しかし、将来の配達責務の達成が危機にさらされている場合、システムは、配送計画を再順序付けして潜在的な問題を正してもよいし、および／または起こり得る状況をユーザまたは遠隔システムに通知してもよい。一連のレコードの再最適化は、ポータブルコンピュータによる反復プロセスの呼び出しを必要としてもよい。そのプロセスでは、プロセッサは、幾つかの更新配送計画を算定してもよく、それらの更新配送計画は、好ましい更新配送計画が作成／選択されユーザに提示される前に、内部でテストされる。他の実施形態では、更新配送計画は、サービスストップのグラフィック描写だけでもよく、実行すべきレコードの順番を最適化することは行わない。
【００９４】
図６で、プロセスは開始アイコン（７０）で始まり、その後、工程（７１）で更新データを受け取る。更新データは、ローカルで（例えば、キーパッド、ＧＰＳデータ）または遠隔から（無線インタフェースを使用して）受け取ってもよい。更新データは、自動と手動の２種類のうちの１つであると分類されてもよい。その区別は、自動更新ではオペレータの介在を伴わず、配送計画の更新が配送更新プロセス自体により決定されることにある。他方では、自動更新は、通常、システムが受信した積荷目録の変更（例えば、サービス担当すべき新しい集配場所）などの新しい配達関連情報に基づき開始される（しかし、常にではない）。自動更新を開始させる別の代表的なものは、現在時刻入力に基づく。この場合、ポータブルコンピュータ内の周期的ローカルプロセスが、更新が適切であると判定する。
【００９５】
きっかけとなる別の代表的なものは、ユーザ（通常は車両の運転手）が入力する手動更新である。手動更新で、ユーザは、単に進捗状況の「チェック」を要求してもよいし、またユーザは、積荷目録関連情報をさらに手動で追加してもよい。典型的な実施形態は、現在の配達進捗状況に基づき、オペレータが進捗状況チェックを要求することである。例えば、運転手は、配達がスケジュールより遅れているのではないかと疑い、システムに配送計画の更新が適切かどうかを確かめるように要求してもよい。次いでシステムは、現在時刻および／または現在位置と積荷目録および／または実績データとを比較し、現在の配達進捗状況に関するベンチマーク指標を取得する。別の実施形態では、手動による開始（または更新要求）は、サービスストップの完了表示（例えば、小包がサービスストップに配達された）などの別の活動と対であってもよい。従って、ユーザがタスクの完了を通知するときはいつも、システムは、まだ実行されていないサービスストップを自動的に分析し、新しい最適化の実施を決定することができるかどうかを判定する。
【００９６】
他の実施形態では、遠隔入力データを受信すると、ユーザに受信したことの通知を開始してもよく、プロセッサは、更新プロセスまたは場合によっては配送計画内のレコードの再順序付けを行うために、ユーザの許可を求めてもよい。手動入力の他の場合では、オペレータは、更新情報を手動で提供してもよく、次いで最初の配送計画の更新を要求してもよい。車両運転手が状況（例えば、道路閉鎖または交通混雑）を見て、手動でシステムに状況を通知し、システムに配送計画を更新するよう要求するのが、そのような場合であってもよい。
【００９７】
多くの異なる状況および手動入力の種類があるので、図６には、１つの簡略化した実施形態だけを図解する。この実施形態では、ユーザが提供した手動更新は、ポータブルコンピュータに追加情報を提供せずに、時刻および／または場所に基づき更新を行う。この実施形態は、本発明の原理を説明するには十分であり、そのようなシステムを設計する当業者であれば、他の変形形態を発見可能であろう。
【００９８】
更新処理の説明では、まず手動更新を検討する。それは通常範囲が狭く、更新をもたらすことのある他の種類の入力を説明する基礎を提供するからである。この実施形態では、手動更新要求はユーザが指示し、要求は追加情報を一切含まないと想定する。代表的な利用は、ポータブルコンピュータを使用する車両運転手が、配達がスケジュールより遅れているのではないかと疑い、またはサービス訪問を完了し、システムにスケジュールの進捗状況（特に、まだ実行または完了していないサービスストップに関して）を確認するように要求するときである。システムに更新の実行を要求するために、ユーザは、タッチスクリーン上のアイコン、ソフトキー、または専用機能キーを選択して、ユーザ入力を指示してもよい。
【００９９】
この実施形態では、システムは、時刻更新（７７）かそれとも位置更新（７８）に基づきシステムが自動的に処理する入力と同様に、手動の更新要求を処理する。これらは、配送計画の実行進捗状況（例えば、スケジュールどおりか、それとも遅れているか）を確かめるために使用することができる２つの方法を表す。
【０１００】
図１４は、これがどのように達成されるかについて、高レベルの概観を提供する。図１４では、１本の線（３０１）は実行すべき作業を表す。これは、サービスストップ、配達完了小包、サービス完了等で測定してもよい。本実施形態では、大体はサービスストップまたは小包配達の完了が、最小の作業単位である。他の実施形態は、他の基準を使用してもよい。実行すべき作業は、０％完了（３０１）、５０％完了（３０２）、および１００％完了（３０３）を表す点を持ち、連続的と見なすことができるため、線は連続して表される。実行すべき作業は、積荷目録または配送計画により定められる（配送計画は順序付けした積荷目録と見なしてもよいので、両方とも完了する必要があるサービスストップを定める）。配送計画の完了のレベル（「完了進捗状況」）は、完了したサービスストップ（または配達した小包）数とサービスストップ（または小包）の合計数との割合を比較することにより簡単に判定することができる。前述の完了フラグまたは完了インジケータは、レコード内の対応するサービスストップが実行されたかどうかの表示を提供する。従って、合計１２０のうち３０サービスストップの完了は、３０／１２０＝．２５すなわち２５％の完了に相当する。これは、線上の点（３０４）に相当するであろう。
【０１０１】
図１４の別の線（３１０）は、作業を実行するために割り当てられた時間を表す。通常、これは作業日であり、決められた時間数がある（例えば、８時間）。この場合もやはり、基準（時間）は連続と考えてもよく、点は割り当てられた時間の０％、５０％、および１００％を表す。決められた毎日の作業スケジュールと一緒に現在時刻の時計を使用して、この基準に沿った進捗は容易に測定できる。例えば、割り当てられた時間の５０％は、通常、作業日の４時間に相当し、午前８：００に始まった場合は、正午の１２時に相当するであろう。同様に、１日８時間の２５％の経過は、２時間の経過に相当し、午前１０：００に相当するであろう。これは、線（３１０）上の点（３０６）に相当するであろう。
【０１０２】
最後に、図１４に示す別の基準は、順序付けした一連の位置データ（３０８）を表す。場所それ自体は必ずしも直線（例えば、通りに沿った）ではなく、ポータブルコンピュータが操作するのは場所を表すデータなので、この基準は、位置データ（例えば、ＧＰＳの座標）により特定される場所を表す点により論理的に表される。この基準は、配送計画の中に見つけられる順序付けした一連の位置データ（３０８）により表される。位置データに関するサービスストップの完了の割合の決定は、幾つかの方法で行うことが出来る。まず、ストップ数は位置データのレコード数（これは、ストップ数と等しいはずである）を数えることにより決定してもよく、特定の位置データは、系列の中の相対的順番により特定してもよい。従って、合計１０のうちの３番目のレコードの位置データは、３０％完了と考えてもよい。１０ストップしかない場合、２５％完了は、２番目と３番目のストップとの間で起こるであろう。完了を判定するこの基準を使用する別の方法は、ポータブルコンピュータ内のＧＰＳデバイスを使用して現在位置を読み取り、順序付けしたリスト内の最も近くにあるサービスストップを特定することである。一旦それがわかると、完了進捗状況を決定することができる。従って、（合計１０の中の）２番目と３番目のストップとの間に相当する場所は、完了率２５％と見なしてもよい。
【０１０３】
これらの基準のこれら３つは相互に関係があり、これらの基準のそれぞれからマッピングが行われてもよい。ポータブルコンピュータは、時刻、その位置を追跡し、配送計画にサービスストップの完了を記録してもよい。次いで、ポータブルコンピュータは、各基準の相対的完了進捗状況を比較してもよい。時間の進行は一定なので、この基準は通常ベースラインとして使用される。従って、配送計画の進捗状況は、基本的に、実行すべき作業の完了進捗状況と割り当てられた時間とを比較するか、または割り当てられた時間を含めた予定サービスストップに対して現在位置を比較する。
【０１０４】
作業日の進行に連れて（例えば、時間が経過すると）、実行すべき作業が完了し、同様に一連の位置データに関連するサービスストップも完了する。スケジュールどおりか否かの判定は、様々な方法で定められてもよく、また様々な方法で算定されてもよいことが明らかになる。
【０１０５】
例えば、図６に示す更新の種類には、配送計画の現在の実行進捗状況（「配送計画スケジュール」、「スケジュール進捗状況」または単に「進捗状況」）を判定するために使用される時刻更新（７７）がある。システムは、実行した作業と合計作業との比率を決定し、作業完了進捗状況を導き出す。図１４の１つの点は、２５％（３０４）に相当する。この割合は、時間完了進捗状況にマッピング（３０５）されてもよい。その時間完了進捗状況は、普通の状況でも、２５％（３０６）のはずである。作業日の作業時間および始業時刻についての知識に基づき、作業日の２５％は既知の時刻に対応し、午前１０：００であると想定してもよい。その時刻は、また「予定時刻」と考えてもよい。ポータブルコンピュータは、内部時間記録時計を介して現在時刻を知る。現在時刻が午前１０：００である場合、予定時刻と現在時刻は同じであり、配送計画はスケジュールどおりである。それに対して、現在時刻が午後１２：３０である場合、配達または進捗状況は、スケジュールより遅れていると見なしてもよい。同様に、現在時刻が予定時刻より早い場合、配送計画はスケジュールより進んでいる。管理パラメータは、閾値（例えば、実際の時刻と予定時刻との差の限界）を定めてもよく、その閾値を超えると、配達は「スケジュールより進んでいる」、「スケジュールどおり」、または「スケジュールより遅れている」と見なされる。従って、現在時刻と予定時刻とが１分離れている場合、配送計画は、遅れているまたは進んでいるではなく、「スケジュールどおり」であると見なされるおそれがある。
【０１０６】
システムは、配達が「スケジュールより遅れている」と判定した場合、配送計画内のレコードをもっと効率的に順序付けできるかどうか判定するように配送更新プロセスを開始してもよいし、また単にユーザに適切に通知してもよい。ポータブルコンピュータは、中央配送システムにさえ通知してもよく、中央配送システムは場合によっては追加のリソースを割り当ててもよいし、また特定の問題に遭遇したかどうかを運転手に尋ねてもよい。
【０１０７】
遅延によりスケジュールより遅れたが、残りのサービスストップが既に最も効率的な順番である場合は、重ねて残りのサービスストップの順番を再分析する理由がないことは明らかである。
【０１０８】
代わりに、配送計画のスケジュール進捗状況の算定は、車両の現在位置に基づき実行されてもよい。手動更新が図６の工程（７８）に示すように場所に基づく場合、システムは、工程（８３）で現在の完了進捗状況を使用して、予定位置に対する現在位置を確かめる。
【０１０９】
この場合もやはり、様々なアルゴリズムが使用されてもよく、図１４に戻って、一実施形態では、最も近いサービスストップを決定するために、（前述のＧＰＳ入力を使用して）配達車両の現在位置を比較してもよい。従って、図１４では、「Ｘ」（３１１）で表される現在位置が、配送計画内の位置データ３（３１０）に最も近いと判定されてもよい。ストップは、通常直線状に一定の間隔をおいて配列されないので、３番目のレコードが使用されてもよく、相対的進捗状況は３０％であろう。これは、割り当て時刻の２５％に近い。システムは、その差を取るに足らないと見なし、配送計画を「スケジュールどおり」と判定してもよい。
【０１１０】
代わりに、経路が田舎にあり、ストップ間の距離が長い地域における利用では、上記の推定は実績位置データを使用することにより、もっと正確に行われてもよい。例えば、ストップが２０あり、それぞれが１０マイル離れている、合計２００マイルの田舎の経路を検討する。位置データの使用（代わりに、走行距離計の示度数を使用してもよい）により、システムは、全体の経路距離および移動距離を判定することが可能になる。移動距離が２００マイルの経路上で５０マイルの場合、これは経路の２５％完了に相当する。従って、配送計画の実行はスケジュールどおりであろう。
【０１１１】
実績データは、固定時間間隔で定期的にその位置を記録し、所与の時刻の平均位置を決定することにより、ポータブルコンピュータで収集してもよい。代わりに、ポータブルコンピュータは、各サービスストップに関する位置データを維持し、それをポータブルコンピュータが配送計画のどこにいるか、および相対的な完了進捗状況がどうであるかを判定するために使用してもよい。この種の算定は、過去の配達データの移動平均または情報を必要としないが、データは他の目的で収集されてもよい。
【０１１２】
従って、手動更新は、現在時刻、現在位置、またはその２つの組み合わせと、実績平均配達データまたは現行配送計画との比較に基づいてもよい。好みは、管理パラメータまたはルーチンにハードコードして指示してもよい。その方法の選択は、配達経路の特徴に基づき行われてもよい。例えば、ストップ数が少なくストップ間の距離が長い（田舎または郊外の経路の特色）ことが特徴の配達経路では、位置判定に基づく現在のスケジュール進捗状況の処理に基礎を置くほうが、より正確であるとわかる場合がある。この利用では、サービスストップ間の距離は相対的距離であってもよく、移動時間が割り当てられた作業時間を圧倒的に占めてもよい。従って、サービスストップが１つだけ（１つの目的地への長距離トラック輸送）のとき、運転手に配送計画進捗状況情報を提供しても、ほとんど利益にならないであろう。その場合、配達が行われるまで、配送計画は０％完了と見なされ、一旦配達が完了すると、配送計画は１００％完了する。この利用では、時間と併せて位置を使用することにより、運転手により有益な進捗状況表示を与える。
【０１１３】
他方、ストップが多く各ストップ間の距離が短い（都市経路の特色）配送計画を実行する運転手は、時間ベースの配送計画進捗状況表示をより有益で正確であると気づく場合がある。都市経路では、移動時間が少なく、運転手（およびポータブルコンピュータ）は、ＧＰＳ信号が利用できないことのある建物内部でより多くの時間、作業に従事する。このことは、時間ベースの進捗状況更新ルーチンの使用に適する。また、１つのストップの場所（例えば、ショッピングモール、オフィスビルディング）は、運転手の時間を大幅に必要とすることがある、１つの場所に相当する。他の実施形態では、両方の組み合わせを使用してもよい。
【０１１４】
図６に戻って、一旦進捗状況を決定すると（進捗状況決定に使用する基準にかかわらず）、システムは、配達問題が起こる可能性があるかどうかを判定する（８４）。配達問題が起こる可能性があるかどうかの判定は、予定スケジュールに関する閾値を超えたかどうかを含む幾つかの基準に基づいてもよい。残りの配達時間保証に影響があるかどうか、また現行配送計画内の残りのサービス訪問が最適でないかどうかの判定を含んでもよい。問題となるものは、達成できない配達時間保証に限定されず、広範囲に定めてもよい。例えば、横幅の大きい荷物は、日没後州間ハイウェイでは禁止されている。配送計画が、目的地への到着が日没後の時間になることを示す場合、これは、運転手の注意を必要とする問題と見なしてもよい。
【０１１５】
問題が起こるかどうかの判定は、作業活動またはサービスストップがまだ実行されていない、配送計画内のレコードだけの検討を必要とする。例えば、配達時間保証を持つ小包がない場合、現在の配達がスケジュールより遅れている場合でさえ、システムは、問題の可能性はないと判断してもよい。それに対して、所用の配達時間要件を満たす残りのサービスストップがある場合、閾値を超える遅れは、配達問題の可能性をもたらす場合がある。完了したサービスストップを検討する必要はない。
【０１１６】
問題になる可能性がない場合、プロセスは終了する（８８）。問題になる可能性がある場合、幾つかの利用可能なアルゴリズムのどれか１つを使用して、更新配送計画を作成し（８５）、再最適化が必要かどうか、最適化により問題が軽減するかどうかを見てもよい。更新は、前述のように、グラフィック、表またはその両方であってもよい。次いで工程（８６）で、システムは、配達時間保証は更新配送計画で満足されるかどうかを検討する。満足されない場合、配送計画は再算定される（８５）。ここでは、解決は可能であると仮定するが、場合によっては、配達時間保証は、配送計画の修正では、達成できないこともある。そのような場合、ポータブルコンピュータは、配送サーバに状況を報告してもよく、それによりサービス提供業者は、場合によっては追加車両の派遣が可能になる。代わりに、配送計画については、不利な影響を最小限にする更新配送計画を選択してもよい。一旦更新配送計画が作成されると、工程（８７）で、適切なフォーマットを使用して、ユーザの検討のために提示される。
【０１１７】
図６の一番上に戻って、これから自動更新を考慮する。時刻更新（７７）および位置更新（７８）は、これらの入力をシステムが通常定期的に自動開始することを除いては、前述と同様の方法で動作する。従って、長距離トラック輸送での利用に戻って、システムは、周期的（例えば、１５分毎）自動的に配送計画の位置ベースの更新を実行して、運転手に進捗状況を提示してもよい。
【０１１８】
システムが自動的に受け取る他の更新には、気象状態および交通状況に関するものがある。気象データ更新（７５）は、電子的に気象の更新を提供する商業サービスまたは車両運転手に提供される個人用サービスに基づいてもよい。どちらであろうと、工程（８０）で、システムは気象データ更新の影響を確かめる。通常、気象データ更新は、当初の配送計画が当日早くに作成されたとき、入手可能でなかった情報を提供する。その結果、ある場所で暴風雨、降雪、ひょうなどの予想外の天候が発達した場合、この情報の影響は定量化され、所定の規則により影響を判定するポータブルコンピュータに送信されてもよい。例えば、激しい暴風雨は、現行スケジュールの時間に対して一定の遅延時間（例えば、３０分）を加えることで定量化してもよい。代わりに、全体のスケジュールを、配送計画の完了に応じて遅らせてもよい（例えば、残っている作業の各残り時間に対して余分に１０分）。
【０１１９】
同様に、商業サービス、地方政府の交通部門、または他の情報源が提供することがある交通データ更新情報（７６）を、システムが受け取ってもよい。同様に、道路閉鎖、事故、交通混雑、または他の状況は、所定の規則を使用して定量化してもよい。通常、交通情報は、位置データおよび交通事象の表示を有して伝達されてもよい。位置データは、通り名若しくは道路名とブロックの住所若しくはマイル標識とであってもよいし、代わりにＧＰＳ座標の形態であってもよい。交通事象の表示は、深刻さまたは一般化遅延係数を示してもよい。例えば、交通情報が、ある道路に沿った交通状況は一定の通勤時間について追加の遅延時間が生じていると述べるのは、珍しいことではない。同様に、交通事故の影響は、予想配達スケジュールに一定量の全体時間を追加して定量化してもよい。一旦定量化すると、交通データを、分析し（８１）、未完了の配達に関して配達問題になる可能性があるかどうか、または危機状況をもたらすかどうかを判定してもよい。
【０１２０】
他の実施形態では、サービスストップに向かって運転していようと、出発場所に戻っていようと、運転手による目的地への代替経路の選択を可能にするように、配達運転手に単にグラフィック情報を提示することにより、交通データ更新を処理してもよい。この実施形態では、配送計画を更新する必要があるかどうかを判定する試みは行わず、運転手に交通状況を単に通知し、運転手はそれに応じて経路を調整してもよい。この実施形態では、システムは、交通事変の場所が配送計画のサービス地域内かどうかを確かめてもよい。システムは、事象の表示と併せて印（例えば、アイコン）を使用して、グラフィック地図上に単に位置を描画するであろう。これは、ユーザにグラフィック形式（例えば、道路地図）で提示されるであろう。実施形態によっては、ユーザは、道路状況をチェックするために、この情報の表示を手動で切り替えてもよいのに対して、他の実施形態では、システムは検出した事象をユーザに通知して、入力を待ってから地図を提示するようにディスプレイを切り替えてもよい。また別の実施形態では、天候または交通の影響は、他のチャネル（例えば、交通ラジオレポート）を通じた情報の取得に基づき、運転手がポータブルコンピュータに手動で入力してもよい。
【０１２１】
最後に、配送計画に影響を及ぼすことがある、システムが受信する別の種類の自動更新は、図６の工程（７４）に示してあり、図７にその詳細を図解する。この入力は、配送計画の修正、または同等に積荷目録の修正を伴う。（配送計画は高レベルでは順序付けした積荷目録と見なしてもよいことを思い出されたい。だからこの場合、両方は類似している）。図７を参照して、配送計画の変更処理プロセスは、変更は配達責務の実行に影響を及ぼすことがある種類かどうかをまず試験する（９１）。ある種の配送計画更新は、配達責務に影響を及ぼす可能性がないことがある。例えば、更新は、配送計画内の配送先住所の変更、集配する小包数の減少、または集配の取り消しの場合がある。これらの変更は、配送計画を実行するために追加の時間を必要としないし、配送計画内のレコードの再最適化も必要としないであろう。配送計画のこれらの変更は、作業負荷を減らし、配達スケジュールを進めても、遅らせはしない。そのような場合は、最初の配送計画内のレコードを再順序付けする必要がないので、システムは工程（１０１）に進む。
【０１２２】
４種類のよく起こる積荷目録更新を特定している（９２）が、他の分類も可能である。１番目の事例では、入力は、集配用の追加の小包を備える（９３）。小包は、既存の予定サービスストップに関連するが、顧客が示した集配用小包数が増加する。各小包には、最小限度の取扱時間が割り当てられてもよい。従って、集配用小包数が２個から５０個に増加する配送計画の変更は、システムがスケジュールの予定時間に最小限度の時間を追加することになるであろう。次いでシステムは、悪い影響があるかどうか見るためにその後の配達スケジュールを検討してもよい。さらに、システムは、小包を受け入れる十分なスペースがあるかどうか、またストップでサービスを行うために他のリソースが必要かどうかを判定してもよい。
【０１２３】
工程（９４）に示す別の種類の配送計画更新は、小包の配達保証時刻を変更する。荷受人がサービスを受ける時間帯を指定または修正することを認める、運送業者のサービスをこれは反映するであろう。この場合、予定のストップは変更されないが、ストップに関する配達責務が変更されている。場合によっては、荷受人が予定時刻にいないかまたはある時間以降に応じられることを、これは反映してもよい。住宅への配達では、所有者が仕事日に対応できないことや、一時的に家を離れていることはよくある。
【０１２４】
予定外の小包集配がスケジュールに追加される、別の種類の配送計画更新を工程（９５）に示す。この事例は、顧客が時間ぎりぎりに小包集配を依頼した場合に相当してもよい。これは、顧客が出荷システムにデータを入力するか、または配送事務所に集配依頼の電話を掛けることにより行われてもよい。通常、予定外の場所で集配を実行するには最低限の時間は必要であり、システムは、配送計画のサービスストップに関する予定時間にこれを加えてもよい。予定外の集配を追加する事例では、配送車両が同じ道を戻るのを避けるために、最初の配送計画を分析すべきであり、またその後の配達時間保証を守れなくなるのを避けるためにも分析すべきである。
【０１２５】
新サービスまたは性能を反映して配送計画を更新してもよい、他の種類の情報があってもよい（９６）。その新しいサービスまたは性能は、その後の配達責務に影響を及ぼすことがあるか、または最初の配送計画の処理を開始させることがある。
【０１２６】
図６に戻って、配達問題になる可能性の確認（８４）、配送計画の更新の再算定（８５）、配達基準達成の確保（８６）、およびオペレータに更新配送計画の提示（８７）を含む図６の残りの工程は、前述と同様である。
【０１２７】
次いで、本発明で使用するデータファイルを検討する。構造化およびデータ構造とデータベースファイルを関連付ける様々な技術があることは、データベースに精通している人であればわかるであろう。それ故、開示の実施形態は１つの方法に過ぎず、他の変形形態も容易に考えることができる。
【０１２８】
図８を参照して、異なるが関連する２つのファイルを開示する。１つのファイルは、経路計画データ（１１７）であり、そのデータは、図４のＧＩＳ／経路計画データベース（４３）に収容されたデータに相当する。経路計画データファイル（１１７）は、潜在的なサービスストップの経路に沿った様々な住所または住所のグループのテーブルファイル（例えば、テキストベースで一連のレコードを備える）である。住所によっては小包を受け取るだけのこともあるので、必ずしもすべての住所が小包配達サービスに出荷口座を作っていなくてもよい。図８に示すように、データは、インデックスとして機能するレコード番号（１１０）の列と、名称／住所データ（１１１）の列とを備える。従って、サービスストップの可能性がある全住所が、関連する商店名または居住者名と一緒に列挙されてもよい。この実施形態で、まず住所を示しているのは、経路の順番の性質を説明するためである。通常、経路計画データは、最適経路を反映するように編成され、地理的サービス担当地域内の複数の配達車両に対する幾つかの経路計画と併せて決定される。他の実施形態では、経路計画は、住所の範囲を記載してもよく、そのことは、メモリ要件を非常に簡素化し、名称も格納しない。これにより、所有者が移動するたびに経路リストを更新する必要がなくなる。
【０１２９】
実績配送計画データ（１１８）は、図８に個別のテーブルファイルで示すが、説明のためだけである。経路計画データ（１１７）に追加の列を付けることで実装してもよい。この実施形態では、実績配送計画データは、レコード番号インデックス（１１２）および住所／名称データ（１１３）を複製し、ＧＰＳ座標位置データ（１１４）および平均到着時刻データ（１１５）を付ける。ＧＰＳ座標位置データは、通常、各場所の経度と緯度を示す。図８に示す値は見本であり、現在のデバイスから入手可能な精度を必ずしも反映していないことがある。相互間が比較的近い都市環境でのサービスストップは、ストップ間の位置座標の差は小さいのに対して、田舎の経路では、ストップ間の位置座標の差は大きい。実績位置データは時間が経過しても変わらず（住所位置は動かないので）、実績配送計画データ（１１８）内のデータが一旦多くなると、位置データは通常まれにしか更新されない。データは、配送計画の実行中のサービスストップ完了時に、システムにより個別に記録されてもよい。代替実施形態では、ある区域（例えば、小規模ショッピングセンタ）は１つの場所で表してもよく、アルゴリズムは、所定の距離限界（例えば、１つの場所から１００ｍ以内の範囲は小規模ショッピングセンタに関連する）に基づき、現在場所を１つの場所に描いてもよい。
【０１３０】
また一方、平均到着時刻データは、通常その場所に関する到着時刻の実績移動平均を反映する。経路上のすべてのストップが、通常は、サービスを受けるわけではないが、ストップがサービスを受けるときはいつでも、到着時刻は観察され記録される。従って、テーブル（１１８）で、２つの場所（例えば、メインストリート１２５とメインストリート１２８）は、所与の日の配送計画に両方が載っていないとしても、同じまたは似た平均到着時刻（例えば、午前１０：３９）を持つことは可能である。平均時刻は、最近の３０配達日内のサービスストップに基づいてもよいし、また平均および／または季節的な値を反映する他の値に基づいてもよい。実施形態によっては、同じ月に対する過去複数年の平均に基づく一般水準を反映して、算定されてもよい。平均時刻は変わってもよいので、その場所に対する平均時刻の一定の限界（例えば、１０分）内の現在時刻が「時間どおり」と見なされるように、限界は定められる。どのように平均到着時刻が算定されるかにかかわらず、実績配送計画データは、過去の実績に対して現在の配送計画の実行を比較する基準を提供する。
【０１３１】
住所範囲を使用するときなどの他の実施形態では、実績配送計画（１１８）は、基準場所として少数の場所だけを格納してもよい。基準場所は、通常、頻繁にサービスを提供する顧客に関連するサービスストップ、または所定の地域内の最後のサービスストップになる可能性を示す場所（通りまたは区画の最後のサービスストップ）である。個別の住所位置でなくて範囲を使用することにより、メモリ要件は緩和される。配送計画の現在の実行の正確な推定を取得するためには、ほんの少数の基準場所しかメモリに格納する必要がない。
【０１３２】
次いで、図９は、最初の配送計画（１３０）と積荷目録データ（１３１）との関係の一実施形態を説明する。本発明の原理を説明するために、２つの個別のテーブルを使用しているが、実施形態によっては、テーブルを１つだけ使用してもよい。積荷目録データファイル（１３１）は、集配または配達が予定された小包を列挙するテーブルファイルとして示す。小包は予定のストップの順番に列挙されているので、テーブル（１３１）は、配送計画の変形とも見なすことができる。積荷目録データ（１３１）の内容は、先に検討しており、重ねて検討はしない。
【０１３３】
積荷目録データ内の各小包は、最初の配送計画（１３０）を作成するために、経路計画のサービスストップと関連付けられてもよい。これにより、最初の配送計画は、積荷目録データのサブセット情報を収容することが可能になる。代わりに、積荷目録それ自体が、最初の配送計画（１３０）に示される順番を反映するように再編成されてもよく、場合によっては、住所により索引されてもよい。また代わりに、積荷目録は、配送計画内での相対的位置を示す個別のインジケータを有してもよい。種々の実装が可能なことは、データベースの当業者であれば容易に理解するであろう。また別の実施形態では、積荷目録は、集配または配達用の小包のリストと論理的に見なしてもよいのに対して、配送計画はサービスストップの論理的一覧であり、積荷目録に基づいている。
【０１３４】
図９に示すように、Ｐｅｒｒｙ漬物店に配達される２個の小包（１５４ａ、１５４ｂ）は、配送計画内の３番目のストップ（１５０）に関連付けられている。小包の１個（１５４ｂ）は、配達保証時刻午後４：００を有すると積荷目録に表示されている。
【０１３５】
最初の配送計画（１３０）を作成するプロセスは、通常、中央配送施設（ｃｅｎｔｒａｌ ｄｉｓｐａｔｃｈ ｌｏｃａｔｉｏｎ）内の個別のシステムで実行され、一旦決定されると、ポータブルコンピュータにダウンロードされる。最初の配送計画を作成する方法と取り組みは様々あり、最初の配送計画を作成する特定のアルゴリズムは、本発明の範囲内ではない。提示のように、配送計画に関して様々な実施形態が可能であり、その中には、順番に配列した積荷目録形式の１つのテーブル、各レコードに連続番号を付加して論理的順番を示した積荷目録、または一連の住所を備える個別に編成された配送計画を含む。また別の実施形態を図９Ａに示す。
【０１３６】
図９Ａは、荷受人住所（１３７）に基づきレコードを論理的に順序付けしたテーブル（２３５）を備える配送計画を示す。各住所は小包に関連しており、それ故、レコードは、問い合わせ番号（１３６）および配達若しくは集配すべき小包番号（１３８）も有する。そこにある残りのフィールドは、図９の積荷目録で以前検討したのと同じである。要約すれば、積荷目録および配送計画は、統合テーブルとしてまた個別テーブルとして、様々な方法で表現されてもよい。上記の表現のすべておよび他の形態は、本発明の範囲内にある。
【０１３７】
図９ａに示す最初の配送計画のフォーマットがポータブルコンピューティングデバイスにロードされていると想定すると、図４の配送マネージャは、入力を受け取り、最初の配送計画の更新および再順序付けが適切かどうかを判定する。説明のために、３つのサービスストップを実行する予定の配送車両を含む図１に示す配送計画に似た仮の配送計画を考慮する。この例では、小包の１個に対して、配達保証時刻午後４：００が要求されている。
【０１３８】
配達車両がそのサービス経路に出発したが、スケジュールを遅れさせる様々な状況に遭遇したと想定する。車両が配送計画の実行途中、ポータブルコンピュータが深刻な交通状況の通知を受信した。交通状況更新は無線で受信してもよいし、また運転手が情報をポータブルコンピュータに手入力してもよい。交通状況更新は場所を示し、ポータブルコンピュータは、その場所が配送計画のサービス地域内にあると判定する。この実施形態では、交通状況は、本質的に遅延を加えるように定量化してもよい（例えば、現在時刻を進めるか、または各サービスストップへの予定到着時刻を遅らせる）。
【０１３９】
システムは、残りのサービスストップに関する配達要件（予定時刻）を判定可能である。Ｐｅｒｒｙ漬物店（２５０）への３番目のストップに関する配達は配達保証時刻午後４：００を定めており、予定到着時刻が前述の遅延により遅れた場合、配達保証時刻の達成は危うくなるであろうと判定することにより、システムは配達問題の可能性を特定する。配送計画では、サービスストップの順番は次の通りである。
【０１４０】
１）Ｊｏｎ花店（２４０）
２）Ｊｅｆｆ宝石店（２５１）
３）Ｐｅｒｒｙ漬物店（２５０）
現在時刻および／または現在位置を考慮して、システムは、配送計画（２３５）の順番で（すなわち、１番目にＪｏｎ花店（２４０）、次いで２番目にＪｅｆｆ宝石店（２５１））店舗にサービスすると、Ｐｅｒｒｙ漬物店（２５０）への配達保証時刻の午後４：００に遅れることになるおそれがあると判定する。システムは、配送計画を分析するアルゴリズムの呼び出しは適切であると判定し、配達保証時刻の達成を可能にするために、配送計画の順番を再順序付けする。更新配送計画を図１０に示す。
【０１４１】
図１０では、更新配送計画（１６０）は、配達の新しい順番を反映する。すなわち、Ｐｅｒｒｙ漬物店（２５０）がいまや２番目のストップであるのに対して、３番目のストップは今やＪｅｆｆ宝石店（２５１）である。この方法で、更新配送計画は、配達基準を満足する配達計画の変更を反映して最適化される。図１０は、ポータブルコンピューティングデバイスを使用して運転手に提示してもよい、配送計画の表出力の１形式を示す。
【０１４２】
ユーザに提示してもよい配送計画の別形式の表出力を図１０ａに示す。図１０ａでは、一連のレコード（２４０、２５０、２５１）を持つ更新配送計画（２６０）が、ユーザに提示され、１番目の列はストップ番号識別子（２６１）である。ストップ番号はストップの順番を表し、住所（２６２）および受取人名（２６３）に関連する。従って、各レコードは、図９ａの場合の小包とは対照的に、サービスストップ（例えば住所）に対応する。図１０ａでは、別の列（２６４）がサービスストップに関連する小包数を示し、最後の列（２６５）は、サービスが集配かそれとも配達かを示す。この種のフォーマットは、運転手に住所位置の順番を強調しており、ストップと小包レベル詳細情報とを結ぶ別のスクリーンが具現されてもよい。これにより、次いで運転手は、住所と特定の小包とを関連付けることが可能になる。
【０１４３】
前述のように、配送計画のグラフィック（例えば、地図ベースの）フォーマットも提示してよい。システムは、ポータブルコンピューティングデバイスのＬＣＤディスプレイ上にグラフィックフォーマット（例えば、地図を使用して）で、ユーザに更新配送計画を表示してもよい（例えば、図１２参照）。システムは、種々のフォント、アイコン、フラッシングインジケータ等を使用して、最初の配送計画に対する変更を強調してもよい。システムは、関連する配達要件または最初の配送計画の他の変更も特定してよい。これは、ユーザがスタイラスを使用してサービスストップに相当する表示場所を選択し、システムが関連するサービスストップ情報を提示するようにディスプレイを切り替えることにより応答し、次いで配送計画に戻っているディスプレイに戻ることにより達成されてもよい。
【０１４４】
システムが更新配送計画を作成するとき、システムは前のバージョンを保持してもよい。それによりユーザは、更新配送計画を受け入れるかどうかを決定するだけでなく、配送計画間の差を確認するための比較を容易にするためにも、前の計画を閲覧してもよい。通常これは、レコードの順番の変更が実行されるときだけ行われる。レコードの順番が維持される既存のレコードの修正またはストップの追加などの他の変更は、ユーザがその受け入れを知らせることをたいてい正当化しない。
【０１４５】
システム設計の当業者には当然のことながら、様々なデータ構造、機能構成要素、およびハードウェア実装態様を含む多くの変形形態が、開示の実施形態について可能である。また、フローチャートのブロックのプロセスの記述は、特定の論理機能またはプロセスの工程を実施する１つ以上の実行可能命令を含む、モジュール、セグメントまたはコードの一部を表していると理解すべきであり、代替実施は本発明の範囲内に含まれ、機能が追加機能を含んでもよいことは、本発明の当業者であれば理解する。
【０１４６】
システムソフトウェアは、順序付けしたステップのリストを備え、命令実行システム、装置またはデバイスから命令をフェッチし、命令を実行できるコンピュータベースのシステム、プロセッサ内蔵システム、または他のシステムなどの命令実行システム、装置またはデバイスにより、またはそれらと併せて、使用されるコンピュータで読み取り可能な記憶媒体として具現されてもよい。本文書の文脈では、「コンピュータで読み取り可能な記憶媒体」は、命令実行システム、装置またはデバイスにより、またはそれらと併せて、使用されるプログラムを収容、格納、通信、伝播またはトランスポートできるどんな手段であってもよい。コンピュータで読み取り可能な記憶媒体は、例えば電子、磁気、光、電磁気、赤外線または半導体のシステム、装置、デバイスまたは伝播媒体であってもよいが、それに限定されない。コンピュータで読み取り可能な記憶媒体のより具体的な例（網羅的なリストではない）には次のものを含むであろう。それらは、１本以上の線を持つ電気的（電子的）接続、ポータブルコンピュータディスケット（磁気）、ランダムアクセスメモリ（ＲＡＭ）（磁気）、リードオンリメモリ（ＲＯＭ）（磁気）、消去可能プログラマブルリードオンリメモリ（ＥＰＲＯＭまたはフラッシュメモリ）（磁気）、光ファイバ（光）、およびポータブルコンパクトディスク（光）リードオンリメモリ（ＣＤ−ＲＯＭ）である。
【０１４７】
詳細な説明の最後に、本発明の原理から大幅に逸脱することなしに、好ましい実施形態の多くの変形形態および修正形態を作成できることに留意すべきである。そのような変形形態および修正形態は、添付の特許請求の範囲に記載する本発明の範囲内に含むことをここでは意図している。さらに、明細書は、特許請求項の言葉それ自体を超えて、特許請求の範囲を多少とも限定する意図はまったくない。
【図面の簡単な説明】
【０１４８】
上記のように本発明を一般用語で説明したが、これより添付の図を参照する。以下の図があるが、必ずしも縮尺で描かれていない。
【図１】配達時間保証を確実に守るための配送計画の修正の一実施形態を示す図である。
【図２】配送計画修正に関連する通信フローを含む、別のプロセスの一実施形態を示す図である。
【図３】更新配送計画の作成にかかわる様々なプロセスの一実施形態を示す図である。
【図４】更新配送計画の開始に関連する様々な機能、プロセス、モジュールおよび入力の一実施形態を示す図である。
【図５】更新配送計画を作成するプロセスを実行するシステムに関連する、様々なハードウェア構成要素、モジュールおよび機能の一実施形態を示す図である。
【図６】更新配送計画を開始させる様々な種類の更新の一実施形態を示す図である。
【図７】積荷目録の様々な種類の更新の一実施形態を示す図である。
【図８】経路計画データファイルおよび実績配送計画データファイルの一実施形態を示す図である。
【図９】最初の配送計画ファイルおよび積荷目録データファイルの一実施形態を示す図である。
【図９ａ】配送計画の別の実施形態を示す図である。
【図１０】更新配送計画の一実施形態を示す図である。
【図１０ａ】更新配送計画の別の実施形態を示す図である。
【図１１】配送計画のグラフィック提示の一実施形態を示す図である。
【図１２】配送計画のグラフィック提示の修正の一実施形態を示す図である。
【図１３】配送計画のグラフィック提示の修正の別の実施形態を示す図である。
【図１４】時刻、位置および実行すべき作業に関するスケジュール進捗状況の概念マッピングを示す図である。
【図１５】ポータブルコンピューティングデバイスに無線で伝達されてもよいメッセージの一実施形態を示す図である。
【特許請求の範囲】
【請求項１】
配送計画データを処理するポータブルデバイスであって、
各レコードが住所部、サービス完了フラグ、および小包識別データを備える、論理的に順序付けられたレコードを備える配送計画を格納するメモリと、
第１のレコードおよび前記第１のレコードは前記配送計画に追加されるという指示を備える配送計画更新メッセージを受信することができる無線インタフェースと、
前記メッセージを処理し、前記第１のレコードの前記住所部内の第１の住所データに基づく論理的順番で、前記第１のレコードは前記配送計画に追加されると判定し、それにより、更新配送計画を作成することができるプロセッサであって、さらに前記更新配送計画作成の信号を提供することができる前記プロセッサと、
前記プロセッサからの前記信号の受信に応えて視覚インジケータを提示することができるディスプレイであって、さらに前記第１のレコードに関連するテキストを提示することができる前記ディスプレイと、
を備えるデバイス。
【請求項２】
前記ディスプレイは、前記プロセッサからのグラフィックイメージを表す信号を提示することができるビットマップＬＣＤディスプレイであり、前記グラフィックイメージには、少なくとも２つの場所を有する道路地図が表され、前記２つの場所の少なくとも１つは前記第１のレコードに関連する、請求項１に記載のデバイス。
【請求項３】
前記ディスプレイは、各行のテキストが前記配送計画内のレコードに関連する情報を提示する、複数行のテキストを提示することができるＬＣＤベースのディスプレイである、請求項２に記載のデバイス。
【請求項４】
サービス配達車両で運ばれる、配送計画データを処理するポータブル装置であって、
各レコードが住所部、サービス完了フラグ、および小包識別データを備える、論理的に順序付けられたレコードを備える配送計画を格納するメモリと、
前記配送計画内の第１のレコードを修正する配送計画更新メッセージであって、さらに前記更新データは第１の住所または小包識別データを示す前記配送計画更新メッセージを受信し、前記メッセージを前記メモリ内に格納することができる無線インタフェースと、
修正された第１のレコードを作成するために、前記更新メッセージを使用して、前記配送計画内の前記第１のレコードを識別することができるプロセッサであって、さらに前記配送計画内の前記修正された第１のレコードを格納するように構成された前記プロセッサであって、さらに前記修正された第１のレコードに基づき表示信号を生成するように構成された前記プロセッサと、
前記表示信号を受信し、ユーザに対する前記第１の住所または小包識別データの１つを含む前記更新データを、前記サービス車両の運転手に提示することができるディスプレイと、
を備える装置。
【請求項５】
前記プロセッサは、さらに現在時刻データを定期的に取得し、前記現在時刻および配送計画完了進捗状況を使用して計算される予定時刻に基づき、現在配送計画スケジュール進捗状況を判定するように構成され、前記プロセッサは、さらに前記ディスプレイに前記現在配送計画スケジュール進捗状況を表す表示信号を提供するように構成される、請求項４に記載の装置。
【請求項６】
前記プロセッサは、さらにＧＰＳモジュールから位置データを定期的に取得し、前記配送計画内の前記レコードに関する実績位置データを一部使用して配送計画スケジュール進捗状況を判定するために前記位置データを処理するように構成される、請求項４に記載の装置。
【請求項７】
ポータブルコンピューティングデバイス内の配送計画向けのサービス関連更新データを処理する方法であって、
前記ポータブルコンピューティングデバイスに無線で送信された前記サービス関連更新データを、前記ポータブルコンピューティングデバイスで受信する工程と、
前記サービス関連更新データ内の住所データであり、且つ前記配送計画内にも収容される前記住所データを識別するために、前記ポータブルコンピューティングデバイス内のマイクロプロセッサで前記サービス関連更新データを処理する工程と、
前記ポータブルコンピューティングデバイス内のメモリから、各レコードが住所部を含む一連のレコードのファイルを備える前記配送計画内の第１のレコードを識別する工程と、
前記住所データと前記配送計画内の前記第１のレコードに関連する前記住所部とを比較する工程と、
前記住所データは前記第１のレコードの前記住所部に一致すると判定する工程と、
前記配送計画サービス関連更新データを使用して、前記第１のレコードの内容を修正する工程と、
メモリに前記修正された配送計画を格納する工程と、
前記ユーザに前記配送計画の修正を通知する工程と、
を備える方法。
【請求項８】
前記サービス関連更新データは、前記配送計画のレコードに関するサービス保証を修正するかどうかを判定する工程と、
前記サービス保証は、前記配送計画の前記現在完了進捗状況に基づき達成されそうであるかどうかを判定する工程と、
をさらに備える、請求項３１に記載の方法。
【請求項９】
前記配送計画の前記現在完了進捗状況は、前記現在時刻と予定時刻とを比較することにより判定される、請求項３２に記載の方法。
【請求項１０】
前記予定時刻は、第１の値を持つ前記配送計画内の完了フラグセットを有する第１のレコード数と、第２の値を持つ前記配送計画内の前記完了フラグセットを有する第２のレコード数との両方を識別することにより判定される、請求項９に記載の方法。
【請求項１１】
前記予定時刻は、完了サービス数とサービスストップ合計数との比を計算することにより決定される、請求項９に記載の方法。
【請求項１２】
前記現在配送計画進捗状況は、前記現在場所と予定場所とを比較することにより決定される、請求項３２に記載の方法。
【請求項１３】
前記予定場所は、実績データを使用して決定される、請求項３６に記載の方法。
【請求項１４】
前記予定場所は、完了サービスストップとサービスストップ合計数および合計移動距離との比を計算することにより決定される、請求項１３に記載の方法。
【請求項１５】
前記配送計画内の前記レコードの順番は、前記サービス保証に基づき論理的に再順序付けされる、請求項３６に記載の方法。
【請求項１６】
ポータブルコンピューティングデバイス内のメモリに格納された、論理的に順序付けられた複数のレコードを備える配送計画に関するスケジュール進捗状況を確かめる、前記ポータブルコンピューティングデバイス用の方法であって、
前記ポータブルコンピューティングデバイス内のリアルタイムクロックにより生成される現在時刻を取得する工程と、
第１のサブセット内の各レコードが、前記レコードに関連するサービスストップが実行されていないことを示すフラグを有する、前記複数のレコードの前記第１のサブセットを識別する工程と、
前記第１のサブセット内の第１のレコード数と前記複数のレコード内の第２のレコード数との比に基づき、前記配送計画の現在完了進捗状況を判定する工程と、
前記現在完了進捗状況に基づき予定時刻を判定する工程と、
前記予定時刻と現在時刻との差が所定の閾値を超えると判定する工程と、
前記ポータブルコンピューティングデバイスのディスプレイ上でユーザにスケジュール進捗状況の表示を提示する工程と、
を備える方法。
【請求項１７】
前記ポータブルコンピューティングデバイスのキーパッドから、小包の配達が行われたという入力を受け付ける工程
をさらに備える、請求項１６に記載の方法。
【請求項１８】
前記スケジュール進捗状況の表示は、前記現在時刻が前記予定時刻より遅い場合、スケジュールより遅れていると表示される、請求項１７に記載の方法。
【請求項１９】
前記ポータブルコンピューティングデバイスの識別子と共に前記現在スケジュール進捗状況を示す無線データメッセージを、配送サーバに送信する工程、
をさらに備える、請求項１８に記載の方法。
【請求項２０】
前記予定時刻は前記現在時刻より早いと判定する工程と、
前記配送計画更新を更新するプロセスを実行するために、前記ポータブルコンピュータ内のプロセッサによる要求を開始する工程と、
前記配送計画内の前記一連のレコードが修正されたという表示を前記ディスプレイで前記ユーザに提示する工程と、
をさらに備える、請求項１６に記載の方法。
【請求項２１】
ポータブルコンピューティングデバイス内のメモリに格納された、論理的に順序付けされた複数のレコードを備える配送計画に関するスケジュール進捗状況を確かめる、前記ポータブルコンピューティングデバイス用の方法であって、
前記ポータブルコンピューティングデバイス内に配置された、ＧＰＳベースの位置測定装置によって生成される前記ポータブルコンピューティングデバイスの現在位置座標を表す位置データを取得する工程と、
各レコードがサービスストップに対応する位置座標を備える複数のレコードを備え、前記ポータブルコンピューティングデバイスのメモリに格納される配送計画を読み出す工程と、
前記選択されたレコードの前記位置座標が前記現在位置に関して最も近いサービスストップを示す、前記複数のレコードからレコードを選択するための前記位置データを使用する工程と、
前記選択されたレコードを使用して、前記配送計画の現在完了進捗状況を判定する工程と、
予定時刻を決定するために前記現在完了進捗状況を使用する工程と、
前記予定時刻と現在時刻との差が所定の閾値を超えるかどうかを判定する工程と、
前記ポータブルコンピューティングデバイスのユーザに、前記スケジュール進捗状況の表示を提示する工程と、
を備える方法。
【請求項２２】
前記ユーザに前記現在位置を表す印を表示するグラフィック地図を提示する工程
をさらに備える、請求項２１に記載の方法。
【請求項２３】
前記配送計画内の前記一連のレコードを修正するプロセスを実行するために、前記ポータブルコンピュータ内のプロセッサにより、要求を開始する工程と、
前記ユーザに前記ポータブルコンピュータのディスプレイ上で、前記一連のレコードの再順序付けが行われたかどうかの表示を提示する工程と、
をさらに備える、請求項４９に記載の方法。
【請求項２４】
前記サービスストップは小包を配達する場所を表す、請求項２１に記載の方法。
【請求項２５】
前記配送計画の前記現在完了進捗状況を判定する工程は、前記配送計画内の前記複数のレコードに対する前記選択されたレコードの前記論理的順番に基づく、請求項２１に記載の方法。
【請求項２６】
前記配送計画の前記現在完了進捗状況を判定する工程は、前記現在時刻と前記配送計画内の前記複数のレコードに対する前記選択されたレコードに基づく予定時刻との比較に基づく、請求項２１に記載の方法。
【請求項２７】
配送更新モジュールの実行を開始する方法であって、
ポータブルコンピューティングデバイスで、サービスストップの完了を示すユーザ入力を受け付ける工程と、
前記ポータブルコンピューティングデバイス内のメモリから、各レコードがサービスストップ完了インジケータを備える複数のレコードを備える配送計画を読み出す工程と、
前記サービスストップの完了に関する、前記レコードの前記サービスストップ完了インジケータの前記表示を設定する工程と、
前記配送計画の相対的完了進捗状況を判定する工程と、
前記配送計画のスケジュール進捗状況を判定するために、前記相対的完了進捗状況および現在時刻を使用する工程と、
前記ユーザに前記ポータブルコンピュータのディスプレイ上で、前記配送計画はスケジュールより遅れているという表示を提示する工程と、
を備える方法。
【請求項２８】
前記ディスプレイは、前記ユーザに配送計画更新の開始するための入力をするように指示する、請求項２７に記載の方法。
【請求項２９】
前記配送計画はスケジュールより遅れていると判定後、プロセッサが配送計画更新モジュールを呼び出す、請求項２７に記載の方法。
【請求項３０】
前記配送計画内の、前記サービスストップがまだ完了していないという第１の表示を有する第１のレコードに関するサービス保証時刻を識別する工程と、
前記現在時刻に基づき前記第１のレコードに関連する前記サービスストップに対する予定完了時刻を判定する工程と、
前記予定完了時刻は前記サービス保証時刻を過ぎると判定する工程と、
をさらに備える、請求項２７に記載の方法。
【請求項３１】
ポータブルコンピューティングデバイスのメモリに格納された配送計画内のレコードの論理的順番により示される一連のサービスストップに、サービス車両を使用してサービスを提供する方法であって、
前記ポータブルコンピューティングデバイスに無線で送信される、サービスに関する第１のレコードを備える更新データを受信する工程と、
前記第１のレコード内の住所データおよび前記住所データが前記配送計画に追加されるという指示を識別するために、前記ポータブルコンピューティングデバイス内のマイクロプロセッサを使用して、前記更新データを処理する工程と、
前記メモリから前記配送計画の、前記一連のサービスストップの１つに関する住所フィールドを備える少なくとも１つの第２のレコードを読み出す工程と、
前記第２のレコードに対する前記第１のレコードの前記相対的順番を判定する工程と、
前記相対的順番に基づき、前記配送計画に前記第１のレコードを追加し、更新配送計画を作成する工程と、
メモリに前記更新配送計画を格納する工程と、
前記サービス車両の運転手に、前記ポータブルコンピューティングデバイスによる、前記更新配送計画の作成を通知する工程と、
まだサービスされていない前記一連のサービスストップの１つに関する少なくとも１つの住所を有する前記更新配送計画の少なくとも一部を、前記ポータブルコンピューティングデバイスにより制御されるディスプレイ上で、前記運転手により閲覧する工程と、
を備える方法。
【請求項３２】
前記運転手は、まだサービスされていない前記一連のサービスストップの１つに関連する少なくとも１つの住所に関連する場所に、前記サービス車両を運転する、請求項３１に記載の方法。
【請求項３３】
前記サービスは小包の配達である、請求項３２に記載の方法。
【請求項３４】
前記サービスは小包の集配である、請求項３２に記載の方法。
【請求項３５】
前記サービスは施設の調査を含む、請求項３２に記載の方法。
【請求項３６】
前記運転手により閲覧される前記更新配送計画は、各行のテキストが前記一連のサービスストップの１つに関連する住所位置を備える、複数行のテキストを備える表形式で提示される、請求項３１に記載の方法。
【請求項３７】
前記第１のデータ内の前記住所データを強調表示するフォーマットを使用して、前記一連のサービスストップの１つに関連する少なくとも１つの住所を表示する工程をさらに備える、請求項３６に記載の方法。
【請求項３８】
前記運転手により閲覧される前記更新配送計画は、各印が前記一連のサービスストップの１つに関連する場所を表す複数の印を有する地図を備えるグラフィック形式で提示される、請求項３１に記載の方法。
【請求項３９】
サブセット内の各レコードが、
それぞれのサービスストップがまだ実行されていないことを示すサービス完了フラグを備える、前記レコードの前記サブセットを識別する工程と、
前記現在時刻に基づき所要時刻までに実行されないと予想される前記レコードのサブセットの第２のレコードのサービス保証を識別する工程と、
前記サービスストップを実行する順番を表す、前記レコードの前記サブセットの前記論理的順番を再順序付けする工程と、
再順序付けされた論理的な一連のレコード内の最初のレコードに関連するサービスストップの実行を開始する工程と、
をさらに備える、請求項３１に記載の方法。
【請求項１】
配送計画データを処理するポータブルデバイスであって、
各レコードが住所部、サービス完了フラグ、および小包識別データを備える、論理的に順序付けられたレコードを備える配送計画を格納するメモリと、
第１のレコードおよび前記第１のレコードは前記配送計画に追加されるという指示を備える配送計画更新メッセージを受信することができる無線インタフェースと、
前記メッセージを処理し、前記第１のレコードの前記住所部内の第１の住所データに基づく論理的順番で、前記第１のレコードは前記配送計画に追加されると判定し、それにより、更新配送計画を作成することができるプロセッサであって、さらに前記更新配送計画作成の信号を提供することができる前記プロセッサと、
前記プロセッサからの前記信号の受信に応えて視覚インジケータを提示することができるディスプレイであって、さらに前記第１のレコードに関連するテキストを提示することができる前記ディスプレイと、
を備えるデバイス。
【請求項２】
前記ディスプレイは、前記プロセッサからのグラフィックイメージを表す信号を提示することができるビットマップＬＣＤディスプレイであり、前記グラフィックイメージには、少なくとも２つの場所を有する道路地図が表され、前記２つの場所の少なくとも１つは前記第１のレコードに関連する、請求項１に記載のデバイス。
【請求項３】
前記ディスプレイは、各行のテキストが前記配送計画内のレコードに関連する情報を提示する、複数行のテキストを提示することができるＬＣＤベースのディスプレイである、請求項２に記載のデバイス。
【請求項４】
サービス配達車両で運ばれる、配送計画データを処理するポータブル装置であって、
各レコードが住所部、サービス完了フラグ、および小包識別データを備える、論理的に順序付けられたレコードを備える配送計画を格納するメモリと、
前記配送計画内の第１のレコードを修正する配送計画更新メッセージであって、さらに前記更新データは第１の住所または小包識別データを示す前記配送計画更新メッセージを受信し、前記メッセージを前記メモリ内に格納することができる無線インタフェースと、
修正された第１のレコードを作成するために、前記更新メッセージを使用して、前記配送計画内の前記第１のレコードを識別することができるプロセッサであって、さらに前記配送計画内の前記修正された第１のレコードを格納するように構成された前記プロセッサであって、さらに前記修正された第１のレコードに基づき表示信号を生成するように構成された前記プロセッサと、
前記表示信号を受信し、ユーザに対する前記第１の住所または小包識別データの１つを含む前記更新データを、前記サービス車両の運転手に提示することができるディスプレイと、
を備える装置。
【請求項５】
前記プロセッサは、さらに現在時刻データを定期的に取得し、前記現在時刻および配送計画完了進捗状況を使用して計算される予定時刻に基づき、現在配送計画スケジュール進捗状況を判定するように構成され、前記プロセッサは、さらに前記ディスプレイに前記現在配送計画スケジュール進捗状況を表す表示信号を提供するように構成される、請求項４に記載の装置。
【請求項６】
前記プロセッサは、さらにＧＰＳモジュールから位置データを定期的に取得し、前記配送計画内の前記レコードに関する実績位置データを一部使用して配送計画スケジュール進捗状況を判定するために前記位置データを処理するように構成される、請求項４に記載の装置。
【請求項７】
ポータブルコンピューティングデバイス内の配送計画向けのサービス関連更新データを処理する方法であって、
前記ポータブルコンピューティングデバイスに無線で送信された前記サービス関連更新データを、前記ポータブルコンピューティングデバイスで受信する工程と、
前記サービス関連更新データ内の住所データであり、且つ前記配送計画内にも収容される前記住所データを識別するために、前記ポータブルコンピューティングデバイス内のマイクロプロセッサで前記サービス関連更新データを処理する工程と、
前記ポータブルコンピューティングデバイス内のメモリから、各レコードが住所部を含む一連のレコードのファイルを備える前記配送計画内の第１のレコードを識別する工程と、
前記住所データと前記配送計画内の前記第１のレコードに関連する前記住所部とを比較する工程と、
前記住所データは前記第１のレコードの前記住所部に一致すると判定する工程と、
前記配送計画サービス関連更新データを使用して、前記第１のレコードの内容を修正する工程と、
メモリに前記修正された配送計画を格納する工程と、
前記ユーザに前記配送計画の修正を通知する工程と、
を備える方法。
【請求項８】
前記サービス関連更新データは、前記配送計画のレコードに関するサービス保証を修正するかどうかを判定する工程と、
前記サービス保証は、前記配送計画の前記現在完了進捗状況に基づき達成されそうであるかどうかを判定する工程と、
をさらに備える、請求項３１に記載の方法。
【請求項９】
前記配送計画の前記現在完了進捗状況は、前記現在時刻と予定時刻とを比較することにより判定される、請求項３２に記載の方法。
【請求項１０】
前記予定時刻は、第１の値を持つ前記配送計画内の完了フラグセットを有する第１のレコード数と、第２の値を持つ前記配送計画内の前記完了フラグセットを有する第２のレコード数との両方を識別することにより判定される、請求項９に記載の方法。
【請求項１１】
前記予定時刻は、完了サービス数とサービスストップ合計数との比を計算することにより決定される、請求項９に記載の方法。
【請求項１２】
前記現在配送計画進捗状況は、前記現在場所と予定場所とを比較することにより決定される、請求項３２に記載の方法。
【請求項１３】
前記予定場所は、実績データを使用して決定される、請求項３６に記載の方法。
【請求項１４】
前記予定場所は、完了サービスストップとサービスストップ合計数および合計移動距離との比を計算することにより決定される、請求項１３に記載の方法。
【請求項１５】
前記配送計画内の前記レコードの順番は、前記サービス保証に基づき論理的に再順序付けされる、請求項３６に記載の方法。
【請求項１６】
ポータブルコンピューティングデバイス内のメモリに格納された、論理的に順序付けられた複数のレコードを備える配送計画に関するスケジュール進捗状況を確かめる、前記ポータブルコンピューティングデバイス用の方法であって、
前記ポータブルコンピューティングデバイス内のリアルタイムクロックにより生成される現在時刻を取得する工程と、
第１のサブセット内の各レコードが、前記レコードに関連するサービスストップが実行されていないことを示すフラグを有する、前記複数のレコードの前記第１のサブセットを識別する工程と、
前記第１のサブセット内の第１のレコード数と前記複数のレコード内の第２のレコード数との比に基づき、前記配送計画の現在完了進捗状況を判定する工程と、
前記現在完了進捗状況に基づき予定時刻を判定する工程と、
前記予定時刻と現在時刻との差が所定の閾値を超えると判定する工程と、
前記ポータブルコンピューティングデバイスのディスプレイ上でユーザにスケジュール進捗状況の表示を提示する工程と、
を備える方法。
【請求項１７】
前記ポータブルコンピューティングデバイスのキーパッドから、小包の配達が行われたという入力を受け付ける工程
をさらに備える、請求項１６に記載の方法。
【請求項１８】
前記スケジュール進捗状況の表示は、前記現在時刻が前記予定時刻より遅い場合、スケジュールより遅れていると表示される、請求項１７に記載の方法。
【請求項１９】
前記ポータブルコンピューティングデバイスの識別子と共に前記現在スケジュール進捗状況を示す無線データメッセージを、配送サーバに送信する工程、
をさらに備える、請求項１８に記載の方法。
【請求項２０】
前記予定時刻は前記現在時刻より早いと判定する工程と、
前記配送計画更新を更新するプロセスを実行するために、前記ポータブルコンピュータ内のプロセッサによる要求を開始する工程と、
前記配送計画内の前記一連のレコードが修正されたという表示を前記ディスプレイで前記ユーザに提示する工程と、
をさらに備える、請求項１６に記載の方法。
【請求項２１】
ポータブルコンピューティングデバイス内のメモリに格納された、論理的に順序付けされた複数のレコードを備える配送計画に関するスケジュール進捗状況を確かめる、前記ポータブルコンピューティングデバイス用の方法であって、
前記ポータブルコンピューティングデバイス内に配置された、ＧＰＳベースの位置測定装置によって生成される前記ポータブルコンピューティングデバイスの現在位置座標を表す位置データを取得する工程と、
各レコードがサービスストップに対応する位置座標を備える複数のレコードを備え、前記ポータブルコンピューティングデバイスのメモリに格納される配送計画を読み出す工程と、
前記選択されたレコードの前記位置座標が前記現在位置に関して最も近いサービスストップを示す、前記複数のレコードからレコードを選択するための前記位置データを使用する工程と、
前記選択されたレコードを使用して、前記配送計画の現在完了進捗状況を判定する工程と、
予定時刻を決定するために前記現在完了進捗状況を使用する工程と、
前記予定時刻と現在時刻との差が所定の閾値を超えるかどうかを判定する工程と、
前記ポータブルコンピューティングデバイスのユーザに、前記スケジュール進捗状況の表示を提示する工程と、
を備える方法。
【請求項２２】
前記ユーザに前記現在位置を表す印を表示するグラフィック地図を提示する工程
をさらに備える、請求項２１に記載の方法。
【請求項２３】
前記配送計画内の前記一連のレコードを修正するプロセスを実行するために、前記ポータブルコンピュータ内のプロセッサにより、要求を開始する工程と、
前記ユーザに前記ポータブルコンピュータのディスプレイ上で、前記一連のレコードの再順序付けが行われたかどうかの表示を提示する工程と、
をさらに備える、請求項４９に記載の方法。
【請求項２４】
前記サービスストップは小包を配達する場所を表す、請求項２１に記載の方法。
【請求項２５】
前記配送計画の前記現在完了進捗状況を判定する工程は、前記配送計画内の前記複数のレコードに対する前記選択されたレコードの前記論理的順番に基づく、請求項２１に記載の方法。
【請求項２６】
前記配送計画の前記現在完了進捗状況を判定する工程は、前記現在時刻と前記配送計画内の前記複数のレコードに対する前記選択されたレコードに基づく予定時刻との比較に基づく、請求項２１に記載の方法。
【請求項２７】
配送更新モジュールの実行を開始する方法であって、
ポータブルコンピューティングデバイスで、サービスストップの完了を示すユーザ入力を受け付ける工程と、
前記ポータブルコンピューティングデバイス内のメモリから、各レコードがサービスストップ完了インジケータを備える複数のレコードを備える配送計画を読み出す工程と、
前記サービスストップの完了に関する、前記レコードの前記サービスストップ完了インジケータの前記表示を設定する工程と、
前記配送計画の相対的完了進捗状況を判定する工程と、
前記配送計画のスケジュール進捗状況を判定するために、前記相対的完了進捗状況および現在時刻を使用する工程と、
前記ユーザに前記ポータブルコンピュータのディスプレイ上で、前記配送計画はスケジュールより遅れているという表示を提示する工程と、
を備える方法。
【請求項２８】
前記ディスプレイは、前記ユーザに配送計画更新の開始するための入力をするように指示する、請求項２７に記載の方法。
【請求項２９】
前記配送計画はスケジュールより遅れていると判定後、プロセッサが配送計画更新モジュールを呼び出す、請求項２７に記載の方法。
【請求項３０】
前記配送計画内の、前記サービスストップがまだ完了していないという第１の表示を有する第１のレコードに関するサービス保証時刻を識別する工程と、
前記現在時刻に基づき前記第１のレコードに関連する前記サービスストップに対する予定完了時刻を判定する工程と、
前記予定完了時刻は前記サービス保証時刻を過ぎると判定する工程と、
をさらに備える、請求項２７に記載の方法。
【請求項３１】
ポータブルコンピューティングデバイスのメモリに格納された配送計画内のレコードの論理的順番により示される一連のサービスストップに、サービス車両を使用してサービスを提供する方法であって、
前記ポータブルコンピューティングデバイスに無線で送信される、サービスに関する第１のレコードを備える更新データを受信する工程と、
前記第１のレコード内の住所データおよび前記住所データが前記配送計画に追加されるという指示を識別するために、前記ポータブルコンピューティングデバイス内のマイクロプロセッサを使用して、前記更新データを処理する工程と、
前記メモリから前記配送計画の、前記一連のサービスストップの１つに関する住所フィールドを備える少なくとも１つの第２のレコードを読み出す工程と、
前記第２のレコードに対する前記第１のレコードの前記相対的順番を判定する工程と、
前記相対的順番に基づき、前記配送計画に前記第１のレコードを追加し、更新配送計画を作成する工程と、
メモリに前記更新配送計画を格納する工程と、
前記サービス車両の運転手に、前記ポータブルコンピューティングデバイスによる、前記更新配送計画の作成を通知する工程と、
まだサービスされていない前記一連のサービスストップの１つに関する少なくとも１つの住所を有する前記更新配送計画の少なくとも一部を、前記ポータブルコンピューティングデバイスにより制御されるディスプレイ上で、前記運転手により閲覧する工程と、
を備える方法。
【請求項３２】
前記運転手は、まだサービスされていない前記一連のサービスストップの１つに関連する少なくとも１つの住所に関連する場所に、前記サービス車両を運転する、請求項３１に記載の方法。
【請求項３３】
前記サービスは小包の配達である、請求項３２に記載の方法。
【請求項３４】
前記サービスは小包の集配である、請求項３２に記載の方法。
【請求項３５】
前記サービスは施設の調査を含む、請求項３２に記載の方法。
【請求項３６】
前記運転手により閲覧される前記更新配送計画は、各行のテキストが前記一連のサービスストップの１つに関連する住所位置を備える、複数行のテキストを備える表形式で提示される、請求項３１に記載の方法。
【請求項３７】
前記第１のデータ内の前記住所データを強調表示するフォーマットを使用して、前記一連のサービスストップの１つに関連する少なくとも１つの住所を表示する工程をさらに備える、請求項３６に記載の方法。
【請求項３８】
前記運転手により閲覧される前記更新配送計画は、各印が前記一連のサービスストップの１つに関連する場所を表す複数の印を有する地図を備えるグラフィック形式で提示される、請求項３１に記載の方法。
【請求項３９】
サブセット内の各レコードが、
それぞれのサービスストップがまだ実行されていないことを示すサービス完了フラグを備える、前記レコードの前記サブセットを識別する工程と、
前記現在時刻に基づき所要時刻までに実行されないと予想される前記レコードのサブセットの第２のレコードのサービス保証を識別する工程と、
前記サービスストップを実行する順番を表す、前記レコードの前記サブセットの前記論理的順番を再順序付けする工程と、
再順序付けされた論理的な一連のレコード内の最初のレコードに関連するサービスストップの実行を開始する工程と、
をさらに備える、請求項３１に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図９ａ】
【図１０】
【図１０ａ】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図９ａ】
【図１０】
【図１０ａ】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公表番号】特表２００８−５３６７７８（Ｐ２００８−５３６７７８Ａ）
【公表日】平成２０年９月１１日（２００８．９．１１）
【国際特許分類】
【出願番号】特願２００８−５０７７６９（Ｐ２００８−５０７７６９）
【出願日】平成１８年４月１７日（２００６．４．１７）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０１４３４４
【国際公開番号】ＷＯ２００６／１１３５８８
【国際公開日】平成１８年１０月２６日（２００６．１０．２６）
【出願人】（３９７００８３３９）ユナイテッド パーセル サービス オブ アメリカ インコーポレイテッド (49)
【氏名又は名称原語表記】Ｕｎｉｔｅｄ Ｐａｒｃｅｌ Ｓｅｒｖｉｃｅ ｏｆ Ａｍｅｒｉｃａ， Ｉｎｃ．
【住所又は居所原語表記】５５ Ｇｌｅｎｌａｋｅ Ｐａｒｋｗａｙ， ＮＥ， Ａｔｌａｎｔａ，Ｇｅｏｒｇｉａ ３０３２８， Ｕ．Ｓ．Ａ．
【公表日】平成２０年９月１１日（２００８．９．１１）
【国際特許分類】
【出願日】平成１８年４月１７日（２００６．４．１７）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０１４３４４
【国際公開番号】ＷＯ２００６／１１３５８８
【国際公開日】平成１８年１０月２６日（２００６．１０．２６）
【出願人】（３９７００８３３９）ユナイテッド パーセル サービス オブ アメリカ インコーポレイテッド (49)
【氏名又は名称原語表記】Ｕｎｉｔｅｄ Ｐａｒｃｅｌ Ｓｅｒｖｉｃｅ ｏｆ Ａｍｅｒｉｃａ， Ｉｎｃ．
【住所又は居所原語表記】５５ Ｇｌｅｎｌａｋｅ Ｐａｒｋｗａｙ， ＮＥ， Ａｔｌａｎｔａ，Ｇｅｏｒｇｉａ ３０３２８， Ｕ．Ｓ．Ａ．
[ Back to top ]