JP7436486B2 - 通信サーバ装置およびその運用方法、通信システム、コンピュータ読み取り可能な媒体、並びにコンピュータプログラム - Google Patents

Description

本発明は、車両による輸送に対するペイロードを管理するための通信サーバ装置に関するものである。また、本発明は、車両による輸送のためのペイロードを管理するための方法と、その方法を実施するためのオーダーを含むコンピュータプログラムおよびコンピュータプログラム製品とに関する。

本発明は、特に、輸送車両のペイロードアイテムおよびペイロードオーダーのリアルタイムプーリングに適用されるが、排他的ではない。

車両による輸送のためのペイロードを管理する方法は、ペイロードがそのペイロードの輸送のための命令で特定される方法などが知られている。例えば、車両の容量に応じてペイロードを割り当てる方法が知られている。以前に検討された１つの方法では、組み合わせられたオーダーの複雑さに応じて、車両の容量が制限される。以前に検討された別の方法では、ペイロードはルート内の所定のプーリングポイントでプーリングされ、オーダーのレグ間の互換性は、レグにまたがる重複する時間ウィンドウがあるかどうかを判断することによって検討される。以前に検討された別の方法では、オーダーは類似性によってグループ化される。さらに以前に検討された方法では、オーダーは配送先の住所に応じて分類される。

しかし、このような方法では、異なる種類のペイロードを考慮していないため、車両内に異なる種類の容量が必要になる場合がある。さらに、これらの方法は、ペイロードやオーダーのリアルタイムのプーリングには対応していない。さらに、これらの方法は、プールやクラスター化されていないオーダーやペイロードの管理方法を考慮していない。

本発明の側面は、独立請求項で定義されている。本発明のいくつかの任意の特徴は、従属請求項で定義される。

ここに開示されている技術を実装することで、大きな技術的利点を得ることができる。例えば、異なる種類のペイロードおよびペイロードアイテムを同じ輸送システムで効率的に管理またはプールすることができ、輸送能力をはるかに効率的に使用することができる。異なる種類のペイロードを同じプーリング配置で管理することによる、このより効率的な輸送能力の使用は、今度は、同じ量のペイロードアイテムに対してより少ない車両および車両の輸送計画が必要とされるため、例えば、より大きなデータ処理能力および管理システムに対する計算負担の軽減を可能にする。さらに、本明細書に記載されている輸送手配の例に使用される車両は、乗り換え効率が向上するため、システムへの同じ量のペイロードオーダーに対して、より少ないメンテナンスを必要とし、より少ない消耗を経験することになる。

さらに、管理やプーリングは、システムの車両がすでに使用されているか、または輸送中に行うことができ、他の方法では使用されなかったか、または十分に使用されなかった容量を利用することができる。さらに、初期段階でプールされていない、またはマッチしていないオーダーまたはペイロードは、バンドルまたはプーリングプロセスのさらなる段階で再プールまたは再割り当てすることができ、より多くのオーダーおよび／またはペイロードをプールし、より多くの使用されていない車両の容量を使用することができる。少なくともいくつかの実装において、本明細書に開示された技術は、異なるカテゴリーのペイロードに対する車両能力を示すペイロード属性を決定し、これらを車両のペイロード能力と比較することを可能にし、異なるタイプの車両能力を必要とする異なるタイプのペイロードを管理するために、以前に検討された方法の能力不足に対処する。

以下、本発明を例示しながら、添付の図面を参照して説明する。
車両による輸送のためのペイロードを管理するための例示的な通信サーバ装置を有する通信システムを示す概略ブロック図である。 車両による輸送のためにペイロードを管理する例示的な方法のステップを示すフローチャートである。 一連のペイロードとオーダーの一例を示す模式図である。 車両による輸送のためにペイロードを管理するための例示的な通信システムを示す概略ブロック図である。 車両による輸送のためのペイロードを管理するためのデータ記録およびそれらのデータ記録の処理の例を示す模式図である。 車両による輸送のためのペイロードを管理するためのデータ記録およびそれらのデータ記録の処理の例を示す模式図である。 車両による輸送のためにペイロードを管理する例示的な方法のステップを示すフローチャートである。

まず、図１を参照すると、通信システム１００が示されている。通信システム１００は、通信サーバ装置１０２、サービスプロバイダ通信装置１０４、ユーザ通信装置１０６から構成される。これらの装置は、それぞれの通信リンク１１０，１１２，１１４を介して、通信ネットワーク１０８（例えばインターネット）で接続されている。通信装置１０４，１０６は、移動体セルラー通信網を含む公衆交換電話網（ＰＳＴＮ網）などの他の通信網を介して通信することもできるが、図１では分かりやすくするためにこれらを省略している。

通信サーバ装置１０２は、図１に模式的に示されているように単一のサーバであってもよいし、サーバ装置１０２によって実行される機能を複数のサーバコンポーネントに分散させたものであってもよい。図１の例では、通信サーバ装置１０２は、マイクロプロセッサ１１６と、実行可能な命令１２０をロードするためのメモリ１１８（例えば、ＲＡＭなどの揮発性メモリ）とを含む（ただし、これらに限定されない）多数の個々のコンポーネントで構成されてもよく、実行可能な命令は、プロセッサ１１６の制御の下でサーバ装置１０２が実行する機能を定義するものである。また、通信サーバ装置１０２は、通信ネットワーク１０８を介した通信を可能にする入出力モジュール１２２を備えている。ユーザインタフェース１２４は、ユーザ制御のために提供され、例えば、ディスプレイモニタ、コンピュータキーボードなどの従来のコンピューティング周辺機器で構成されてもよい。また、サーバ装置１０２は、データベース１２６を構成してもよい。

サービスプロバイダ通信デバイス１０４は、マイクロプロセッサ１２８、プロセッサ１２８の制御下でデバイス１０４が遂行する機能性を定義する実行可能な命令１３２をロードするためのメモリ１３０（例えば、ＲＡＭなどの揮発性メモリ）を含む多数の個別コンポーネントで構成される、これらに限定されない。また、デバイス１０４は、デバイス１０４が通信ネットワーク１０８を介して通信することを可能にする入力／出力モジュール１３４を備える。ユーザインタフェース１３６は、ユーザ制御のために提供される。サービスプロバイダ通信デバイス１０４が、例えば、スマートフォンやタブレットデバイス（または、車両に設置されたユーザインタフェース）である場合、ユーザインタフェース１３６は、多くのスマートフォンや他のハンドヘルドデバイスで普及しているようなタッチパネルディスプレイの形態になる。あるいは、サービスプロバイダ通信デバイスが、例えば、従来のデスクトップまたはラップトップコンピュータである場合、ユーザインタフェースは、例えば、ディスプレイモニタ、コンピュータキーボードなどの従来のコンピューティング周辺機器の形態をとる。その他、サービスプロバイダ通信デバイス１０４が、例えば、ハブまたは監視デバイス、コントローラまたはサーバ、または他のシステム処理デバイスである場合、ユーザインタフェースは、タッチパネルまたは従来のコンピューティングのいずれかの形態をとることができる。

ユーザ通信装置１０６は、例えば、ラベル通信装置１０４と同じまたは類似のハードウェアアーキテクチャを持つスマートフォンやタブレット端末であってもよい。

図２をさらに参照すると、例示的な通信サーバ装置１０２は、車両による輸送のためのペイロードを管理するためのものであり、例えば上記で概説したように、プロセッサ１１６とメモリ１１８とを備える。本装置は、それぞれ異なるペイロードカテゴリーの複数のペイロードに対応しており、各ペイロードカテゴリーは、ペイロードカテゴリーＡ（２０２）およびペイロードカテゴリーＢ（２０４）などの固有の車両能力要件に関連付けられている。通信サーバ装置は、プロセッサの制御下で、メモリ内の命令１２０を実行して以下を行うように構成される。第１のペイロードカテゴリー（カテゴリーＡ）の第１のペイロードについて、第１の車両能力要件を示す第１のペイロード属性パラメータの値を決定するステップ２０６と、第２のペイロードカテゴリー（カテゴリーＢ）の第２のペイロードについて、第２の車両能力要件を示す第２のペイロード属性パラメータの値を決定するステップ２０８と、第１および第２のペイロード属性パラメータの値を、車両に関連付けられたペイロード能力データと比較するステップ２１０と、比較結果を使用して、第１および第２のペイロードの両方を輸送するための車両の能力を決定するステップ２１２と、を実行するように、プロセッサの制御下で構成される。

上述したように、本明細書に記載の技術は、複数のタイプのペイロードを車両輸送フレームワークに管理またはプールすることに関するものである。ペイロード、コンテンツ、または貨物の多くの異なるタイプまたはカテゴリーが考慮されており、例えば、乗客、およびパッケージ、食品、医薬品、花、家具などの商品が挙げられる。このように、ペイロードは、例えば、貨物や乗客などを考慮するだけの従来のシステムのように同種のものではなく、異種のものとなる。

各車両について、異なる種類のペイロードまたはコンテンツに関連する異なる種類の容量が決定または取得される（以前または他の場所で決定された場合）。これらの異なるタイプの容量の量も、各車両に対して決定される。これにより、異なる種類のペイロードを含むまたはリストされた輸送オーダーをプールし、車両の容量を効率的に使用することができる。オーダー自体は、例えば、図１に示したユーザ１０６またはサービスプロバイダ１０４のデバイスから発信されることがある。ユーザは、例えば、乗客の送迎サービスをオーダーすることができ、サービスプロバイダは、顧客に配送するための小包をネットワーク経由で輸送することを決定することができる。

例示的な手法では、多くの制約や条件が導入され、オーダーからのペイロードおよびペイロードアイテムの管理またはプーリングを最適化し、プーリングプロセスにおいてペイロードまたは貨物を効率的に割り当てることができる。例えば、与えられた車両の各ペイロードタイプに対して現在占有されている容量、車両に対するペイロードタイプの互換性、および車両内の異なるペイロードタイプ間の互換性、各ペイロードタイプおよび各オーダーに対するサービスレベル、これらすべては、与えられた車両および比較されるオーダーまたはペイロードに対する有効なソリューションを決定するための制約として使用することができる。

一例として、ペイロードカテゴリーＡは、乗客、貨物、生鮮品のいずれかとして定義されている。もちろん、カテゴリーは組み合わせることができるが（例えば、乗客には荷物などの貨物が付いている場合があります）、組み合わせのために追加のカテゴリーを定義することもできる（例えば、「乗客＋貨物」という追加のカテゴリーを定義する場合など）。そのため、１つのペイロードカテゴリー（またはクラス、タイプ）は、異なるペイロードアイテム（または、１つのペイロード内の複数のペイロードアイテム）を対象とすることができる。例えば、貨物には様々なサイズや形状があり、乗客には様々な旅の要件がある。その他、様々な要素を考慮して、ペイロードアイテムを効率的に収容することができる。

このように、各ペイロードカテゴリーまたはペイロード（またはペイロードアイテム）には、関連する属性、特性、または分類子／分類があり、それによってそのペイロードの固有または特定の要件を管理することができる。例えば、あるペイロードについて、ペイロードの属性には、車両のどのエリアでペイロードを輸送することができるか、ペイロードのサイズまたは形状、ペイロードをどの程度緊急に輸送しなければならないか、ペイロードの最高温度または最低温度があるかどうか、などが含まれる。

特定のペイロードカテゴリーでは、特定のペイロード属性が暗示され、他の属性が定義され（例えば、オーダーの処理中に指定されたり、データベースから保存された詳細情報を取得したりする）、他の属性はそのペイロードカテゴリーに割り当てられないことがある。乗客カテゴリーのペイロードでは、乗客は（トランクではなく）車両のキャビンで輸送されなければならないことが暗黙の了解となっている。望ましい最大停車回数や、車両の他の乗客の最小／最大人数など、乗客が他の要件を持っているかどうかを定義することができる。これらは、乗客のオーダーから取得してもよいし、保存されたプリファレンスから取得してもよい。他の属性は、例えばトランクの容量をどれだけ使用するかなど、乗客に割り当てられない場合がある。

各ペイロード属性には、ペイロード属性パラメータの値が設定され、ペイロードまたはペイロードアイテムに対する正確な車両能力の要求を定義する。例えば、最大温度というペイロード属性には、ペイロード属性パラメータの値として、その最大温度、例えば４℃が設定される。必要なキャビンの位置というペイロード属性に対して、パラメータ値は、“トランク”または“キャビン”または“冷蔵セクション”となる。サイズのペイロード属性の場合、複数の属性パラメータが存在し、それぞれが値を持つことがある。例えば、幅Ｘｃｍ、長さＹｃｍ、奥行きＺｃｍ。同様または代替のペイロード属性である占有率の場合、パラメータ値は、例えば、利用可能な乗客スペースの数を表す１から４までの値、または占有されている標準化された貨物スペースの数を表す１からｎまでの値とすることができる。重量属性の場合、パラメータ値は例えば１０ｋｇのような重量である。緊急性属性の場合、パラメータ値は、例えば、熱い食品が冷めすぎてしまう時間、生物学的な医療品の最大輸送時間、医療用放射性同位元素の半減期など、配達が制限される時間であることがある。ペイロードカテゴリーが「壊れやすい」の場合、属性パラメータには、ルート上の最大停車数、走行の安定性やルートの品質の最大閾値（これらのパラメータの値を決定するために安定性／品質が評価されている）などが含まれる。

これに対応して、車両に関連するペイロード能力は、車両属性および／または車両属性パラメータ値によって表されてもよい。これらの属性または値は、それぞれのペイロード属性パラメータの収容に対応してもよい。例えば、必要なキャビン位置というペイロード属性について、値が「トランク」である場合、車両属性パラメータ値が「トランク」および「キャビン」であるキャビンタイプの車両属性を有する車両が適合する。また、車両属性の乗車定員に対して、パラメータ値は、５人乗りの場合は“４”とすることができる。これらの車両属性とパラメータ値は、図５ｂに例示されているようなデータレコードの車両能力データコンポーネントに記録することができる。

図２を再び参照すると、ペイロードカテゴリーＡには、固有のまたは特定の車両能力要件Ａ’があり、輸送車両に必要な能力は、乗客ペイロードの場合と貨物ペイロードの場合とで大きく異なる。例えば、配送車には乗客用のキャビンがない場合が多く、同様に、乗客でいっぱいの車でも、トランクに貨物用のスペースがある場合がある。

しかし、ペイロードのカテゴリーが異なれば、必要とされる車両性能も大きく異なる属性を有するが、異なるカテゴリーに共通する属性も存在する。例えば、乗客も貨物も、ある時間までに配達や降車が必要な場合がある。

さらに、ペイロードの属性パラメータ値と車両に関連する能力との比較には、属性パラメータ値を別のペイロード（例えば、既に車両に搭載されている（または搭載が予定されている）ペイロード）の属性パラメータ値と比較することが含まれる（または、これに限定される）。例えば、カーゴペイロードアイテムのサイズパラメータ値を別のカーゴペイロードアイテムのサイズパラメータ値と比較して、両者が車両のトランクに収まるかどうかを確認することができる。２つのペイロードがともに、１つのペイロードアイテムに限定された食品貯蔵エリアの使用を必要とする場合、トランジットの異なる段階で輸送されない限り、両方を輸送するための車両能力が制限される。

さらに、与えられたペイロードまたはペイロードのカテゴリーと属性の組み合わせに最適な車両を決定するために、１台だけでなく複数の車両と比較することもできる。

例として、あるペイロードまたはオーダーのペイロードカテゴリーは、パラメータ値を取得する必要がある複数のカテゴリーを組み合わせたものであったり、複数のカテゴリーを含むものであったりする。例えば、乗客が荷物を持っている場合、荷物と乗客の両方の属性を考慮する必要がある。

また、この例では、車両の能力と比較して、カテゴリー、属性、およびそのパラメータ値で表されるシステムの様々な制約が、お互いに影響し合うことにも注意が必要である。例えば、貨物ペイロードがキャビンエリアを占有することが予定されている場合、その能力がその車両で最初に利用可能であったにもかかわらず、乗客はそこに座ることができなくなる。また、いくつかのペイロードアイテムが時間制限のある属性を持っている場合、ペイロードで車両を完全に占有するソリューションは、すべての時間制限制約を満たすソリューションではない可能性がありますが、これはペイロードの数が多すぎて、すべてのペイロードが時間内に目的地に到達しない場合である。したがって、ペイロードの属性と車両の能力を比較する際には、すべての属性とパラメータを考慮して、複数のペイロードを効率的に管理するための１つ以上の最適なソリューションを見つけることになる。

ペイロードの属性パラメータ値を車両に関連する能力データと比較した後、この比較の結果を用いて、車両が実際にこれらのペイロードを輸送できるかどうかを判断することができる。このようにして、ペイロードの特性または属性は、利用可能な車両を充填または占有するための可能なソリューションに対する制約として使用することができる。その結果、これらの技術は、利用可能な車両のセットの間でペイロードのセットの割り当てまたは分配を最適化するための方法として使用することができる。同様に、これらの技術は、逆に、利用可能な車両のセットを、与えられたペイロードのセットに割り当てることを最適化するために、逆方向の最適化に使用することもできる。

もちろん、車両の能力に応じてペイロードの属性を制限するシステムが確立されていれば、それを利用してオーダーを束ねたり、プールしたりすることができる。これらのオーダーには、ペイロードの詳細、そのカテゴリー、または属性が含まれ、ペイロードの乗車（ピックアップ）および降車（ドロップオフ）の場所が指定される場合がある。上述のオーダーは、例えば、ユーザからのものであり、例えば、拠点間の旅客輸送をオーダーする、またはサービスプロバイダからのものであり、サービスプロバイダは、貨物と乗車および降車の場所をオーダーにまとめている場合がある。

図３は、一連のペイロードとオーダーの一例を示す模式図である。所定の車両は、初期位置１を有している。２には、第１のパッケージの送り主の場所があり、３には第２のパッケージの異なる送り主の場所がある。車両は、初期位置を出発し、２と３を乗車するために移動する。その後、車両は、第１のフードオーダーレストランの場所４で第１のフードペイロードをピックアップし、第２のフードオーダーレストランの場所５で第２のフードペイロードを乗車するために移動する。次に、車両は、場所６で第１の乗客をピックアップし、場所７で第２の乗客をピックアップする。その後、車両は、これらのそれぞれのペイロードのためのそれぞれの降車位置に移動する。１人目の乗客は位置８に、２人目の乗客は位置９に降車する。最初にオーダーした食品は１０に、２番目の食品は１１に置かれる。最後に、１つ目の荷物は１２の場所に、２つ目の荷物は１３の場所に置かれる。

これらのペイロードは、もちろん、ユーザやサービスプロバイダによる複数のオーダーに由来するものである。例えば、別々の場所にある第１と第２の乗客は、２人の異なるユーザによる別々のオーダーに起因すると考えられる。別々の場所にある２つのパッケージは、同じまたは異なるユーザまたはサービスプロバイダによる、異なるオーダーによるものかもしれない。２つの食品は、同じユーザのためにオーダーされたものかもしれないし、異なる場所からオーダーされたものかもしれないし、異なるユーザのためにオーダーされたものかもしれない。

この場合、これらのペイロードは、すべて同じ車両に収容することができる。これは、例えば、上述のプロセスによって、ペイロードの属性を制約し、属性パラメータの値を決定し、車両の能力と比較し、また、このオーダーの集合体（本明細書ではオーダーバンドルと呼ぶ）の中の他のペイロードによる計画された占有率と比較することによって決定されたものである。

さらに、乗車と降車の場所を管理することで、オーダーの収集、集約、束ねを行い、能力的に有効なだけでなく、車両の移動距離の観点からも効率的なオーダーの束やセットを作成することができる。

例えば、ペイロードと位置を含むオーダーの初期グループが与えられた場合、最初は（例えば初期オーダーから）所定の閾値距離外の位置を持つペイロードまたはオーダーを拒否することができる。したがって、オーダーの比較は、最初に場所の類似性によってオーダーをグループ化し、その後、上述のように効率的な車両使用によって最適化するか、またはその逆を行うことができる。第３のモードでは、両方の面を並行して最適化することができる。

例示的な手法では、オーダー場所をグラフ問題として分析することで、オーダー場所の比較が行われる。すべてのオーダーの乗車および降車の場所は、グラフのノードとして表される。任意の２つのノード間のリンクは、グラフ内のアークとして表される。さらに、現在の車両位置をグラフ分析に含めることもできる。

ある例では、２組のオーダーが比較され、各オーダーはペイロードと位置を含んでいる。２つのオーダーグループのマッチングスコアは、当技術分野で知られているモデリングパラダイムである移動セールスマン問題（ＴＳＰ）としてのソリューションのモデリングに基づいて計算される。基本的に、この種のモデリングは、グラフ内のすべてのノードを訪問する最短ルートを決定する。そのため、２組のオーダーを満たすためにどれだけの距離を移動する必要があるかを判断することで、２組のオーダーを比較することができる。したがって、移動時間の増加を比較することで、オーダーのグループの異なる比較を評価することができる。直接的な移動時間を組み合わせた閾値を設定して、移動時間を過度に増加させるオーダーまたはオーダー群を拒否することができる。一例として、オーダーバッチの効率スコアは以下のように計算される。

オーダーバッチ効率＝総オーダー走行時間／バッチされたドライバーの移動時間

ここで、総オーダー走行時間は、各グループのオーダーが別々のトリップで履行されるのにかかる時間であり、バッチされたドライバーの移動時間は、すべてのオーダーが統合された移動で履行されるのにかかる時間である。

このようにオーダーを集めたり束ねたりする一方で、上述の制約を適用することもできる。そのため、例示的な技術のマッチングプロセスでは、オーダーを比較して適切に効率的なバンドルを見つけることができるが、オーダーのペイロードが車両と互換性がない場合、または互いに互換性がない場合、またはオーダー／ペイロード／移動時間のサービスレベル要件と互換性がない場合、または車両が特定のペイロードに対してすでに満杯である場合、オーダーは拒否される可能性がある。

さらに、オーダーやペイロードは、車両が移動中に車両互換性データと比較されることもある。例えば、ペイロードやオーダーは、他のペイロードのピック＆ドロップ位置間を既に移動中の車両と比較されることがあり、また、既にペイロードが割り当てられ、車両に積み込まれていることがある。比較は、ペイロードまたはオーダーと、車両のペイロードまたは割り当てられたオーダーの間で、リアルタイムに行われる。同様の例示的な技術は、以下の図６を参照してより詳細に説明される。

図４は、車両による輸送のためのペイロードを管理するための例示的な通信システムを示す概略ブロック図である。サービスプロバイダのサーバ４０２（これは、図１のデバイス１０４に類似していてもよい）およびユーザデバイス４０４（これは、図１のデバイス１０２に類似していてもよい）は、オーダーを作成するデバイスである。次に、オーダーは、通信サーバ４０６に送信され、通信サーバ４０６は、オーダーおよびペイロードを効率的に管理および／またはプールするために、本明細書に記載の技術に従ってオーダーおよびペイロードを処理する。通信サーバ４０６はまた、１つまたは複数の車両４０８、およびサーバまたはデータベース４１０と通信している。サーバ４１０は、輸送ネットワークの車両のためのバックアップデータ提供を提供してもよいし、車両が行った、または行っている往復の詳細、または車両が行う可能性のある定期的または反復的な往復の詳細を保存してもよい。

車両４０８およびサーバまたはデータベース４１０からの情報は、本明細書で説明したように、それらのペイロードおよび／またはオーダーに対する車両の能力を決定するために、ペイロードおよび／またはオーダー間の比較を行うために、通信サーバ４０６によって使用される。サーバ４０２および４１０、ユーザ装置４０４および車両４０８と通信サーバ４０６との間の通信は、もちろん、図１に示すネットワーク１０８のようなネットワークを介して行われてもよい。

もちろん、車両４０８が自律的な車両であってもよいことに留意されたい。そのような場合、車両のプログラミングは、本明細書に記載されている技術に従って、ペイロードとオーダーの比較によって決定されるルートを含んでもよい。

装置４０２および４０４の場合、ソフトウェアアプリケーションは、以下の１つまたは複数を含むインターフェースまたはＧＵＩの特徴および機能を含むことができる：要求されているサービスの開始場所または出発場所を入力するためのセクション；要求されているサービスの目的地場所を入力するためのセクション、サービスの種類を選択するためのセクション（例えば、タクシー、自家用車、ライドシェアまたはカープール、シャトル、バス、配送など）；地図（ユーザのコンピューティングデバイスの現在の位置、要求されているサービスの開始または開始場所、要求されているサービスの終了または終了場所、または１つ以上の利用可能なサービスプロバイダの位置の表示を含む）；お気に入りの出発地および目的地の位置；および他の機能へのリンク。

ペイロードを管理するプロセスのいくつかは、交通関連サービス（タクシー、自家用車サービス、シャトル、ライドシェア、ｅ－ｈａｉｌｉｎｇサービス、配送サービスなど）を管理するための既知の技術と類似している可能性があり、オーダーを受けること、ユーザの所在地（またはユーザが提供した開始または出発の場所）の近くにある適切で利用可能なサービスプロバイダまたは車両の検索を実行すること、および適切で利用可能なサービスプロバイダをサービス要求にマッチングさせることを含む。

図５ａおよび図５ｂは、車両による輸送のためのペイロードを管理するためのデータレコード５５０およびそれらのデータレコードの処理の例を示す模式図である。本明細書に記載されたシステムの使用例では、ユーザ通信装置（例えば携帯電話）は、ユーザがオーダーを希望するときに、ユーザの装置上で実行されているアプリケーションを使用して、オーダーのためのデータを生成する。サービス要求者のアプリケーションは、典型的には、パケットのＩＤおよびアドレス情報を示すヘッダを有するパケットの形態で、メッセージを出力する。図５ａおよび図５ｂに示すように、パケットのコンテンツ（ペイロード、フィールド）は、ユーザのオーダー情報で構成されており、この図５ａの例では、ペイロード属性データコンポーネント５０４と、位置データコンポーネント５０６で構成されている。同様のデータレコード（別のソース、おそらく別のユーザからのもの）は、同様に、ヘッダ５０３、ペイロード属性データコンポーネント５０５、および位置データコンポーネント５０７を有する。

例示的な通信サーバ装置で実施される本明細書に記載の技術は、データレコード５５０のデータフィールドを使用して、データレコード間の比較を決定することができる。例えば、これらのデータレコードの位置データコンポーネント５０６および５０７を処理して、比較を生成することができる。この場合、データレコードは、ヘッダ５２２と、バンドル属性データコンポーネント５２４（データレコード５５０のオーダーペイロード属性データコンポーネントを処理することによって生成される）と、同様にバンドル位置データコンポーネント５２６（位置コンポーネントの比較によって生成される）とを有する、オーダーバンドルデータレコードに結合されている。

図５ｂでは、１つのデータレコードからの車両能力データコンポーネント５５４が、別のデータレコードからのペイロード属性データコンポーネント５０４と比較処理されて、別のデータレコード（ヘッダ５６２）のデータコンポーネントフィールド５６４が生成され、このフィールドには、車両能力データコンポーネント５５４と属性データコンポーネント５０４との間の比較のための比較結果が入力される。

ペイロードやオーダーを束ねてプールする例示的な手法では、いくつかのステップが行われる。

１．輸送オーダーは、例えば場所ごとに束ねられる。あるバンドルが、決められた効率のしきい値を超えた場合、またはバンドル内のオーダーが遅れた場合（（２）でマッチングするには遅すぎた場合）、バンドルは新しい／無人の車両に割り当てられる。オーダーは、乗車場所と降車場所が互いに近い場合、束ねられる。オーダーを束ねることで、問題の大きさが小さくなり、リアルタイムプーリングの高速な解答を促すことができる。新規オーダーの束ねやプーリングの利点は、スケール効果にある。移動中のプーリングに比べて候補者のセットが大きい場合、新規オーダーのプーリングの品質はしばしば向上する。プールされたバンドルは、ほとんどが同じような集荷場所からのものである。

２．この効率性のしきい値以下のバンドルについては、バンドルと、占有／通過中の車両が現在実行しているトランジットプランとの間でマッチングスコアが決定される。各バンドルは、各移動中の車両のトランジットプランと比較される。閾値以上のマッチングスコアの場合は、マッチングしたトランジットプランを持つ車両に対してオーダーバンドルが追加される。乗り継ぎプーリングが行われると、乗り継ぎ車両のドライバープランが直ちに更新される。輸送中のプーリングでは、すべての輸送中の車両に対して検索が行われる。オーダーを受けた場所から遠く離れた車両は、候補から除外される。この手法により，前処理時間と解答時間が短縮される．輸送中プーリングの利点は，輸送中の車両の能力を最大限に利用できることと，車両が現在のトリップが終わる前に，より多くのオーダーに対応できることである。

３．残りのオーダーバンドルは、（ａ）プールされて新しい／無人の車両に割り当てられるか、そのプールが十分に効率的でない場合は、（ｂ）個々のオーダーに分解され、（１）に戻されて再びバンドルされる。

他の例示的な技術では、上述または図６を参照して説明した技術の特徴を、別々に（または別々の組み合わせで）使用することができる。例えば、図６を参照して説明した方法よりも単純な方法では、オーダー束を提供するために、オーダーを比較する予備段階を使用することができる。他の手法では、オーダー（またはオーダーバンドル）は、車両のオーダー履行旅行中に、車両に割り当てられたオーダーと比較することができる。オプションとして、複数のオーダーをクラスター化して、オーダーまたはペイロードの比較の効率化を図ることができる。

図６は、車両による輸送のためにペイロードを管理するための例示的な方法のステップを示すフローチャート６００である。ステップ１（６０２）では、上述したように、個々のオーダーからオーダーバンドルが作成される。これらのオーダーバンドルは、全く新しいオーダーから作成されるか、リサイクルされたオーダー（下記参照）から作成されるか、またはその両方の組み合わせから作成される。

バンドル化ステップ６０２は、上述したようなＴＳＰモデリングを構成してもよい。しかし、オーダーバンドルが、互いの属性に互換性のあるペイロードで既に入力されているように、上述したような制約を考慮してもよい。

オーダーの束が効率的に利用されている場合、その束は空の車両に割り当てられるように渡される。束の十分な効率を決定するために、上述したように、閾値を適用することができる。一例では、効率はこのように計算される。
（ａ）オーダーバッチ効率＝総オーダー走行時間／バッチされたドライバーの移動時間
（ｂ）ドライバーの移動経路＝オーダーの数
（ａ）と（ｂ）の両方は、（６０２からの）束を空車６２０に割り当てるかどうかを判断するための基準である。

ステップ１において、オーダーバンドルに遅延オーダーが含まれている場合、２つの基準が満たされていなくても（あるいは効率が閾値を超えていなくても）、バンドルは同様に新しい車両への割り当てに渡される。これは、遅延オーダーは緊急に対応する必要があり、そのためにオーダープーリング処理の効率をある程度犠牲にしなければならないからである。

ステップ１において、オーダーバンドルが未利用（遅延オーダーがない）場合、ステップ２．１（６０４）に渡され、各移動中のドライバープランとの（または各）オーダーバンドルのペアについてマッチングスコアが計算される。マッチングスコアの比較処理は、上述のようにすることができる。ＴＳＰモデリングを使用して、オーダーバンドルと各ドライバープランの位置がどの程度類似しているかを判断し、さらに（または代わりに）ペイロードと制約を使用した輸送中の車両の能力との比較を上述のように実施することができる。

ステップ２．２（６０６）では、いくつかの比較のスコアが十分に高く、高い比較スコアまたはマッチングスコアを与えたその輸送中のドライバープランに、所定のオーダーバンドルを６３０に割り当てることができる。特定の手法では、比較スコアは、例えば既知のＫｕｈｎ－Ｍｕｎｋｒｅｓアルゴリズムなどの割り当てアルゴリズムまたは組合せ最適化アルゴリズムを使用して最適化され、バンドルを輸送中のドライバープランにマッチングする際に全体的な効率が最大化されるようにする。

このステップでもオーダーバンドルにマッチするものが見つからない場合は、ステップ３．１（６０８）で、利用されていない、マッチしていないオーダーバンドルがクラスタリングされる。これは単純にオーダーバンドルの各バッチを順番に取ることで行うことができるが、この例ではクラスタサイズを制限した凝集性クラスタリング法を用いてクラスタリングを行う。このクラスタリング手法では、クラスターの数を事前に定義する必要はない。クラスタサイズの制約と最大距離の制約を加えた最近傍連鎖アルゴリズムをベースにしている。

オーダーバンドルがクラスター化されると、ステップ３．２（６１０）で、各クラスター内のオーダーバンドルの数が（ステップ３．１の利用可能なマッチしないバンドルの数と比較して）減らされ、さらにプーリングステップが行われる。これは、ＴＳＰモデリング、または制約適用比較、またはその両方を使用することができる。これにより、プールされたオーダーバンドルから往復プランを提供することができる。このプーリング段階では、他の技術を使用することができる。例えば、ＣＶＲＰ（Ｃａｐａｃｉｔａｔｅｄ Ｖｅｈｉｃｌｅ Ｒｏｕｔｉｎｇ Ｐｒｏｂｌｅｍ）アルゴリズムを使用して（ＣＶＲＰＰＤＴＷ（Ｃａｐａｃｉｔａｔｅｄ Ｖｅｈｉｃｌｅ Ｒｏｕｔｉｎｇ Ｐｒｏｂｌｅｍ ｗｉｔｈ Ｐｉｃｋｕｐ Ｄｅｌｉｖｅｒｙ ａｎｄ Ｔｉｍｅ Ｗｉｎｄｏｗ Ｃｏｎｓｔｒａｉｎｔ）など）、これらのバンドルに対するプールされた往復プランを提供することができる。

この最終段階で、（ステップ１で定義したものと同様に）効率性の閾値を超えたオーダーバンドルのトリッププランが作成された場合、結果として得られたドライバープランは空車に割り当てられる。

ステップ３．２の後、効率の悪いオーダーバンドルが残っている場合、それらは構成するオーダーに分割され、ステップ１で最初のオーダーバンドルを作成するためのリサイクルオーダーとして使用される。

本発明は、例示のみによって説明されていることが理解されるであろう。添付の特許請求の範囲の精神と範囲から逸脱することなく、本明細書に記載された技術に様々な変更を加えることができる。開示された技術は、独立した方法で提供されてもよいし、互いに組み合わせて提供されてもよい技術からなる。したがって、ある技法に関して記載された特徴は、別の技法と組み合わせて提示することもできる。

Claims (22)

1. 車両による輸送のためのペイロードを管理するための通信サーバ装置であって、
   プロセッサと、
   メモリとを備え、
   前記通信サーバ装置は、前記プロセッサの制御下で、前記メモリで
   それぞれの異なるペイロードカテゴリーの複数のペイロードに対して、各ペイロードカテゴリーは固有の車両能力要件に関連付けられ、
   第１のペイロードカテゴリーの第１のペイロードについて、第１の車両能力要件を示す第１のペイロード属性パラメータの値を決定し、
   第２のペイロードカテゴリーの第２のペイロードについて、第２の車両能力要件を示す第２のペイロード属性パラメータの値を決定し、
   前記第１および第２のペイロード属性パラメータの値を、前記車両に関連付けられたペイロード能力データと比較し、前記比較は、前記第１のペイロード属性パラメータの値と前記第２のペイロード属性パラメータの値とを比較することを含み、
   前記比較の結果を用いて、前記第１のペイロードと、前記第２のペイロードが互いに互換性を有するかを判定することを含む、前記第１および第２のペイロードの両方を輸送する車両の能力を判定する、命令を実行するように構成され、
   前記第１のペイロードの種類は、前記第２のペイロードの種類と異なることを特徴とする通信サーバ装置。
2. 前記通信サーバ装置は、最初に前記第１のペイロード属性パラメータの値をペイロード能力データと比較し、後に前記第２のペイロード属性パラメータの値をペイロード能力データと比較するように構成されていることを特徴とする、
   請求項１に記載の通信サーバ装置。
3. 前記第１のペイロードカテゴリーは、乗客、貨物、および生鮮品のうちの１つを含むことを特徴とする、
   請求項１または２に記載の通信サーバ装置。
4. 前記第１のペイロードカテゴリーは貨物を含み、
   前記第１のペイロード属性パラメータは、サイズ、形状、重量、指定積載領域、緊急性、必要温度、および壊れやすさのうちの１つ以上であることを特徴とする、
   請求項３に記載の通信サーバ装置。
5. 前記第１のペイロードカテゴリーは乗客を含み、前記第１のペイロード属性パラメータは、緊急性および要求されるサービスレベルのうちの１つ以上であることを特徴とする、
   請求項３に記載の通信サーバ装置。
6. 前記第１のペイロードカテゴリーは生鮮品を含み、前記第１のペイロード属性パラメータは、サイズ、形状、重量、生鮮性、指定積載エリア、緊急性、必要温度、および壊れやすさのうちの１つ以上であることを特徴とする、
   請求項３に記載の通信サーバ装置。
7. 前記車両に関連付けられたペイロード能力データは、それぞれのペイロード属性パラメータの収容力に対応する１つ以上の車両属性パラメータ値を含んでいることを特徴とする、
   請求項１乃至６のいずれか一項に記載の通信サーバ装置。
8. 前記通信サーバ装置は、ペイロード属性パラメータ値および車両ペイロード能力データを使用して、それぞれのペイロードを輸送するためのソリューションの計算に制約を割り当てるように構成されていることを特徴とする、
   請求項１乃至７のいずれか一項に記載の通信サーバ装置。
9. 前記通信サーバ装置は、前記車両の走行中に、前記第１および第２のペイロード属性パラメータの値を、前記車両に関連付けられたペイロード能力データと比較するように構成されていることを特徴とする、
   請求項１乃至８のいずれか一項に記載の通信サーバ装置。
10. 前記通信サーバ装置は、ペイロードを輸送するためのオーダーを取得するように構成され、
    第１のオーダーは、少なくとも前記第１のペイロードおよび少なくとも１つの第１のオーダーの位置を含み、
    第２のオーダーは、少なくとも前記第２のペイロードおよび少なくとも１つの第２のオーダーの位置を含む、
    請求項１乃至９のいずれか一項に記載の通信サーバ装置。
11. 少なくとも前記第１のオーダーは、通信機器との通信リンクを介して取得されることを特徴とする、
    請求項１０に記載の通信サーバ装置。
12. 前記通信サーバ装置は、前記第１のオーダーおよび前記第２のオーダーの位置を、前記車両に関連する位置データと比較するように構成されていることを特徴とする、
    請求項１０または請求項１１に記載の通信サーバ装置。
13. 前記通信サーバ装置は、前記車両のオーダー履行走行中に、前記第１および第２のペイロード属性パラメータの値を、前記車両に関連付けられたペイロード能力データと比較し、前記第１のオーダーおよび前記第２のオーダーの位置を、前記車両に関連付けられた位置データと比較するように構成されていることを特徴とする、
    請求項１２に記載の通信サーバ装置。
14. 前記通信サーバ装置は、前記第１および第２のペイロード属性パラメータの値を、前記車両に関連付けられたペイロード能力データと比較する前の予備段階で、
    前記第１のオーダーと第２のオーダーを予備的な比較を行い、
    前記予備的な比較の結果に応じて、前記第１および第２のペイロード属性パラメータの値を、前記車両に関連付けられたペイロード能力データと比較する
    ように構成されることを特徴とする、
    請求項１０乃至１３のいずれか一項に記載の通信サーバ装置。
15. 前記通信サーバ装置は、前記第１および第２のオーダーの予備的な比較に続いて、前記第１および第２のオーダーを、前記車両のオーダー履行走行中に、前記車両に割り当てられたオーダーと比較するように構成されていることを特徴とする、
    請求項１４に記載の通信サーバ装置。
16. 前記通信サーバ装置は、
    前記第１および第２のオーダーを、前記車両に割り当てられたオーダーと比較した後、前記第１および第２のオーダーを含む複数のオーダーをクラスタリングし、
    前記第１のオーダーを、前記第１のオーダーからのクラスタリング距離が最小であると判断された第３のオーダーと比較するに構成されていることを特徴とする、
    請求項１５に記載の通信サーバ装置。
17. 前記通信サーバ装置は、前記判定された能力を使用して、前記車両に送信するための履行命令を生成するように構成されている、
    請求項１乃至１６のいずれか一項に記載の通信サーバ装置。
18. 車両による輸送のためのペイロードを管理するための通信システムであって、通信サーバ装置と、少なくとも１つの通信装置と、前記通信サーバ装置および前記少なくとも１つの通信装置がその中で互いに通信を確立するために動作可能な通信ネットワーク装置とを備え、
    前記少なくとも１つの通信装置は、第１のプロセッサおよび第１のメモリを備え、
    前記少なくとも１つの通信装置は、前記第１のプロセッサの制御下で、前記第１のメモリにおいて、少なくとも第１のペイロードを輸送するためのオーダーを生成するための第１の命令を実行するように構成され、
    前記通信サーバ装置は、第２のプロセッサと第２のメモリとを備え、
    前記通信サーバ装置は、前記第２のプロセッサの制御下で、前記第２のメモリにおいて、
    それぞれの異なるペイロードカテゴリーの複数のペイロードに対して、各ペイロードカテゴリーは固有の車両能力要件に関連付けられ、
    第１のペイロードカテゴリーの第１のペイロードについて、第１の車両能力要件を示す第１のペイロード属性パラメータの値を決定し、
    第２のペイロードカテゴリーの第２のペイロードについて、第２の車両能力要件を示す第２のペイロード属性パラメータの値を決定し、
    前記第１および第２のペイロード属性パラメータの値を、前記車両に関連付けられたペイロード能力データと比較し、前記比較は、前記第１のペイロード属性パラメータの値と前記第２のペイロード属性パラメータの値とを比較することを含み、
    前記比較の結果を用いて、前記第１のペイロードと、前記第２のペイロードが互いに互換性を有するかを判定することを含む、前記第１および第２のペイロードの両方を輸送する車両の能力を判定する、第２の命令を実行するように構成され、
    前記第１のペイロードの種類は、前記第２のペイロードの種類と異なることを特徴とする通信システム。
19. 車両で輸送するためのペイロードを管理する通信サーバ装置で実行される方法であって、前記方法は、前記通信サーバ装置のプロセッサの制御の下で、
    それぞれの異なるペイロードカテゴリーの複数のペイロードに対して、各ペイロードカテゴリーは固有の車両能力要件に関連付けられ、
    第１のペイロードカテゴリーの第１のペイロードについて、第１の車両能力要件を示す第１のペイロード属性パラメータの値を決定し、
    第２のペイロードカテゴリーの第２のペイロードについて、第２の車両能力要件を示す第２のペイロード属性パラメータの値を決定し、
    前記第１および第２のペイロード属性パラメータの値を、前記車両に関連付けられたペイロード能力データと比較し、前記比較は、前記第１のペイロード属性パラメータの値と前記第２のペイロード属性パラメータの値とを比較することを含み、
    前記比較の結果を用いて、前記第１のペイロードと、前記第２のペイロードが互いに互換性を有するかを判定することを含む、前記第１および第２のペイロードの両方を輸送する車両の能力を判定することを含み、
    前記第１のペイロードの種類は、前記第２のペイロードの種類と異なることを特徴とする
    方法。
20. 前記第１および第２のペイロード属性パラメータの値を、１つまたは複数の車両に関連するペイロード能力データと比較し、
    比較結果を用いて、前記第１および第２のペイロードの両方を輸送するさらなる車両の能力を決定し、
    前記決定された能力を用いて、前記第１および第２のペイロードの両方を輸送するために前記車両の１つを割り当てることを含む、
    請求項１９に記載の方法。
21. 請求項１９に記載の方法を実施するための命令を含む、
    コンピュータ読み取り可能な媒体。
22. 請求項１９の方法を実施するための命令を含む、
    コンピュータプログラム。