JP7252264B2 - アイテムを管理するためのシステムおよび方法 - Google Patents

Description

関連出願の相互参照
本願は、2018年6月1日に出願された中国特許出願第201810559370．7号および2018年6月1日に出願された中国特許出願第201810559368．X号に基づく優先権を主張し、これらの全ての内容は参照により本明細書に組み込まれる。

本開示は、概して、情報通信技術に関連し、特に、モノのインターネット（IoT）プラットフォームに接続されたアイテムを管理するための、例えば、車両の少なくとも部分的な制御を遠隔で達成するように構成された車両管理プラットフォームによって車両を制御するための、システムおよび方法に関する。

モノのインターネット（IoT）は、様々な装置、例えば車両、ユーザ端末、および／または家電製品を接続するネットワークであり、電子機器、ソフトウェア、アクチュエータ、およびこれらのものが接続し、対話し、データを交換することを可能にする接続を含む。例えば、ユーザは、アイテムが接続されているIoTプラットフォームと対話することによって、アイテムを管理する（例えば、利用するアイテムをチェックアウトする）ことができる。一方では、IoTプラットフォームがアイテムを制御または監視できるように、アイテムは常に1つまたは複数のネットワークを介してIoTプラットフォームに接続されている必要がある。アイテムは、IoTプラットフォームとの接続を維持するために、エネルギー（例えば電気エネルギー）を消費する必要がある。電気エネルギーが使い果たされると、アイテムはIoTプラットフォームとの接続を失い、アイテムがIoTプラットフォームによって適時にかつ効果的に管理されなくなる可能性がある。さらに、IoTプラットフォームは、アイテムを遠隔で制御する、例えば、アイテムのモードを例えばロックからロック解除に変更する必要があり得る。IoTプラットフォームは、それに接続されているアイテムを制御するための安全な解決策を提供する必要がある。したがって、IoTプラットフォームに接続されたアイテムを効果的かつ安全に管理するためのシステムおよび方法を開発することが望ましい。

本開示の一態様によれば、オブジェクトを介してモノのインターネット（IoT）プラットフォームに接続されたアイテムを管理するための方法が提供される。IoTプラットフォームは、アイテムの共有使用を提供するように構成されている。本方法は、以下の動作のうちの1つまたは複数を含みうる。少なくとも1つのプロセッサは、IoTプラットフォーム上のユーザ端末からアイテムに関連するアクションについての要求を受信しうる。少なくとも1つのプロセッサは、要求に応じて、アイテムに関連するアクションを処理するための第1の命令を生成しうる。少なくとも1つのプロセッサは、IoTプラットフォームから、オブジェクトおよび／またはユーザ端末へ第1の命令を与えうる。少なくとも1つのプロセッサは、IoTプラットフォーム上で、第1の命令に従って、アイテムに関連するアクションが完了すると、アイテムに関するフィードバック情報を受信しうる。少なくとも1つのプロセッサは、フィードバック情報に基づいて、アクションの完了に基づいて、オブジェクトの動作モードをトリガするための第2の命令を生成しうる。

いくつかの実施形態では、アイテムに関連するアクションは、アイテムの返却、アイテムのロック、アイテムのチェックアウト、またはアイテムのロック解除のうちの少なくとも1つを含みうる。

いくつかの実施形態では、オブジェクトの動作モードは、省エネモード、スリープモード、または作動モードのうちの少なくとも1つを含む。

いくつかの実施形態では、第2の命令は、秘密鍵をさらに含みうる。少なくとも1つのプロセッサは、IoTプラットフォームから、秘密鍵をオブジェクトに送信しうる。

いくつかの実施形態では、少なくとも1つのプロセッサは、第2のユーザ端末から、アイテムに関連する第2のアクションについての第2の要求を受信しうる。第2の要求に応じて、少なくとも1つのプロセッサは、オブジェクトを動作モードから第2の動作モードに変更するための第3の命令を生成しうる。

いくつかの実施形態では、第3の命令は、第2の秘密鍵をさらに含みうる。少なくとも1つのプロセッサは、IoTプラットフォームから、第2の秘密鍵を第2のユーザ端末および／またはオブジェクトに送信しうる。

いくつかの実施形態では、秘密鍵または第2の秘密鍵のうちの少なくとも一方は、Bluetoothペアリングコードまたはメッセージ検証コードを含みうる。

いくつかの実施形態では、少なくとも1つのプロセッサは、秘密鍵と第2の秘密鍵との関係に基づいて、オブジェクトを動作モードから第2の動作モードに変更するかどうかを決定しうる。

いくつかの実施形態では、動作モードは省エネモードであってもよく、第2の動作モードは作動モードであってもよい。少なくとも1つのプロセッサは、秘密鍵と第2の秘密鍵との間のマッチング動作を実行し、秘密鍵と第2の秘密鍵との一致に応じて、オブジェクトを省エネモードから作動モードにトリガしうる。

いくつかの実施形態では、第2の命令は、アイテムおよび第3の秘密鍵をロックするための命令をさらに含むことができ、第3の命令は、アイテムおよび第4の秘密鍵をロック解除するための命令をさらに含みうる。少なくとも1つのプロセッサは、第3の秘密鍵と第4の秘密鍵との間のマッチング動作を実行し、第3の秘密鍵と第4の秘密鍵との一致に応じてアイテムをロック解除しうる。

いくつかの実施形態では、第3の秘密鍵または第4の秘密鍵のうちの少なくとも一方は、Bluetoothペアリングコードまたはメッセージ検証コードを含みうる。

本開示の他の態様によれば、オブジェクトを介してモノのインターネット（IoT）プラットフォームに接続されたアイテムを管理するためのシステムが提供される。IoTプラットフォームは、アイテムの共有使用を提供するように構成されている。システムは、少なくとも1つの記憶装置、少なくとも1つの記憶装置と通信する少なくとも1つのプロセッサを含みうる。少なくとも1つの記憶装置は、1つまたは複数の命令セットを含みうる。1つまたは複数の命令セットを実行すると、少なくとも1つのプロセッサは、IoTプラットフォーム上のユーザ端末からアイテムに関連するアクションについての要求を受信しうる。少なくとも1つのプロセッサは、要求に応じて、アイテムに関連するアクションを処理するための第1の命令を生成しうる。少なくとも1つのプロセッサは、IoTプラットフォームから、オブジェクトおよび／またはユーザ端末へ第1の命令を与えうる。少なくとも1つのプロセッサは、IoTプラットフォーム上で、第1の命令に従って、アイテムに関連するアクションが完了すると、アイテムに関するフィードバック情報を受信しうる。少なくとも1つのプロセッサは、フィードバック情報に基づいて、アクションの完了に基づいて、オブジェクトの動作モードをトリガするための第2の命令を生成しうる。

本開示の他の態様によれば、非一時的コンピュータ可読媒体は、オブジェクトを介してモノのインターネット（IoT）プラットフォームに接続されたアイテムを管理するために提供される。IoTプラットフォームは、アイテムの共有使用を提供するように構成されている。非一時的コンピュータ可読媒体は、少なくとも1つのプロセッサに方法を実行させる実行可能命令を含みうる。本方法は、以下の動作のうちの1つまたは複数を含みうる。少なくとも1つのプロセッサは、IoTプラットフォーム上のユーザ端末からアイテムに関連するアクションについての要求を受信しうる。少なくとも1つのプロセッサは、要求に応じて、アイテムに関連するアクションを処理するための第1の命令を生成しうる。少なくとも1つのプロセッサは、IoTプラットフォームから、オブジェクトおよび／またはユーザ端末へ第1の命令を与えうる。少なくとも1つのプロセッサは、IoTプラットフォーム上で、第1の命令に従って、アイテムに関連するアクションが完了すると、アイテムに関するフィードバック情報を受信しうる。少なくとも1つのプロセッサは、フィードバック情報に基づいて、アクションの完了に基づいて、オブジェクトの動作モードをトリガするための第2の命令を生成しうる。

本開示の他の態様によれば、車両のテレマティクスボックス（Tbox）を制御するための方法が提供される。車両のTboxは、車両の共有使用を提供するように構成された車両管理プラットフォームに接続され得る。本方法は、以下の動作のうちの1つまたは複数を含みうる。少なくとも1つのプロセッサは、車両管理プラットフォーム上で、ユーザ端末から、車両を返却するアクションについての要求を受信することができ、要求は車両のTboxの識別子を含む。少なくとも1つのプロセッサは、要求に応じて車両を返却するアクションを処理するための第1の命令を生成しうる。少なくとも1つのプロセッサは、車両管理プラットフォームから、車両のTboxへ第1の命令を与えうる。少なくとも1つのプロセッサは、車両管理プラットフォーム上で、第1の命令に従って車両を返却するアクションが完了すると、車両に関するフィードバック情報を受信しうる。少なくとも1つのプロセッサは、フィードバック情報に基づいて、作動モードからスリープモードへのTboxのモード変更をトリガするための第2の命令を生成しうる。

いくつかの実施形態では、第2の命令は、秘密鍵をさらに含みうる。少なくとも1つのプロセッサは、車両管理プラットフォームから、秘密鍵を車両のTboxに送信しうる。

いくつかの実施形態では、少なくとも1つのプロセッサは、車両管理プラットフォーム上で、第2のユーザ端末から、車両をチェックアウトする第2のアクションについての第2の要求を受信しうる。第2の要求は、車両のTboxの識別子を含みうる。第2の要求に応じて、少なくとも1つのプロセッサは、Tboxをスリープモードから作動モードに変更するための第3の命令を生成しうる。第3の命令は、第2の秘密鍵を含みうる。プロセッサは、車両管理プラットフォームから第2のユーザ端末に、第2の秘密鍵を送信しうる。

いくつかの実施形態では、少なくとも1つのプロセッサは、秘密鍵と第2の秘密鍵との間のマッチング動作を実行し、秘密鍵と第2の秘密鍵との一致に応じて、スリープモードから作動モードへのTboxのモード変更をトリガしうる。

いくつかの実施形態では、第3の命令は、メッセージ検証コードをさらに含みうる。少なくとも1つのプロセッサは、車両管理プラットフォームから、メッセージ検証コードを直接Tboxに送信して、スリープモードから作動モードへのTboxのモード変更をトリガしうる。

本開示の他の態様によれば、車両のテレマティクスボックス（Tbox）を制御するためのシステムが提供される。車両のTboxは、車両の共有使用を提供するように構成された車両管理プラットフォームに接続され得る。システムは、少なくとも1つの記憶装置、少なくとも1つの記憶装置と通信する少なくとも1つのプロセッサを含みうる。少なくとも1つの記憶装置は、1つまたは複数の命令セットを含みうる。1つまたは複数の命令セットを実行すると、少なくとも1つのプロセッサは、車両管理プラットフォーム上で、ユーザ端末から、車両を返却するアクションについての要求を受信することができ、要求は車両のTboxの識別子を含む。少なくとも1つのプロセッサは、要求に応じて車両を返却するアクションを処理するための第1の命令を生成しうる。少なくとも1つのプロセッサは、車両管理プラットフォームから、車両のTboxへ第1の命令を与えうる。少なくとも1つのプロセッサは、車両管理プラットフォーム上で、第1の命令に従って車両を返却するアクションが完了すると、車両に関するフィードバック情報を受信しうる。少なくとも1つのプロセッサは、フィードバック情報に基づいて、作動モードからスリープモードへのTboxのモード変更をトリガするための第2の命令を生成しうる。

本開示の他の態様によれば、非一時的コンピュータ可読媒体が、車両のテレマティクスボックス（Tbox）を制御するために提供される。車両のTboxは、車両の共有使用を提供するように構成された車両管理プラットフォームに接続され得る。非一時的コンピュータ可読媒体は、少なくとも1つのプロセッサに方法を実行させる実行可能命令を含みうる。本方法は、以下の動作のうちの1つまたは複数を含みうる。少なくとも1つのプロセッサは、車両管理プラットフォーム上で、ユーザ端末から、車両を返却するアクションについての要求を受信することができ、要求は車両のTboxの識別子を含む。少なくとも1つのプロセッサは、要求に応じて車両を返却するアクションを処理するための第1の命令を生成しうる。少なくとも1つのプロセッサは、車両管理プラットフォームから、車両のTboxへ第1の命令を与えうる。少なくとも1つのプロセッサは、車両管理プラットフォーム上で、第1の命令に従って車両を返却するアクションが完了すると、車両に関するフィードバック情報を受信しうる。少なくとも1つのプロセッサは、フィードバック情報に基づいて、作動モードからスリープモードへのTboxのモード変更をトリガするための第2の命令を生成しうる。

本開示の他の態様によれば、車両のテレマティクスボックス（Tbox）を制御するための方法が提供される。車両のTboxは、車両の共有使用を提供するように構成された車両管理プラットフォームに接続され得る。本方法は、以下の動作のうちの1つまたは複数を含みうる。少なくとも1つのプロセッサは、Tbox上で、車両管理プラットフォームから車両を返却するアクションを処理するための第1の命令を受信しうる。少なくとも1つのプロセッサは、Tbox上で、第1の命令に応じて車両を返却するアクションを実行しうる。少なくとも1つのプロセッサは、車両を返却するアクションが完了すると、Tboxから、車両に関するフィードバック情報を車両管理プラットフォームに送信しうる。少なくとも1つのプロセッサは、Tbox上で、車両管理プラットフォームから、作動モードからスリープモードへのTboxのモード変更をトリガするための第2の命令を受信しうる。第2の命令は、フィードバック情報に従って車両管理プラットフォームによって生成され得る。

いくつかの実施形態では、第2の命令は、秘密鍵をさらに含みうる。少なくとも1つのプロセッサは、Tbox上で、車両管理プラットフォームから秘密鍵を受信しうる。少なくとも1つのプロセッサは、Tbox上で、非一時的コンピュータ可読媒体に秘密鍵を格納しうる。

いくつかの実施形態では、少なくとも1つのプロセッサは、Tbox上で、第2のユーザ端末から、第2の秘密鍵を受信しうる。第2の秘密鍵は、車両管理プラットフォームがTboxに関連する車両をチェックアウトするための要求を受信したときに、車両管理プラットフォームによって生成される第3の命令の一部であってもよく、第2の秘密鍵は、車両管理プラットフォームから第2のユーザ端末に送信され得る。少なくとも1つのプロセッサは、秘密鍵と第2の秘密鍵との間のマッチング動作を実行しうる。少なくとも1つのプロセッサは、秘密鍵と第2の秘密鍵との一致に応じて、スリープモードから作動モードへのTboxのモード変更をトリガしうる。

いくつかの実施形態では、少なくとも1つのプロセッサは、Tbox上で、車両管理プラットフォームから、メッセージ検証コードを受信しうる。少なくとも1つのプロセッサは、Tbox上で、メッセージ検証コードを検証しうる。少なくとも1つのプロセッサは、良好な検証に応じて、スリープモードから作動モードへのTboxのモード変更をトリガしうる。

いくつかの実施形態では、少なくとも1つのプロセッサは、Tbox上で車両の振動状態を検出し、車両の検出された振動状態に基づいて、スリープモードから作動モードへのTboxのモード変更をトリガしうる。

いくつかの実施形態では、少なくとも1つのプロセッサは、車両管理プラットフォームに、車両の検出された振動状態を報告しうる。

本開示の他の態様によれば、車両のテレマティクスボックス（Tbox）を制御するためのシステムが提供される。車両のTboxは、車両の共有使用を提供するように構成された車両管理プラットフォームに接続され得る。システムは、少なくとも1つの記憶装置、少なくとも1つの記憶装置と通信する少なくとも1つのプロセッサを含みうる。少なくとも1つの記憶装置は、1つまたは複数の命令セットを含みうる。1つまたは複数の命令セットを実行すると、少なくとも1つのプロセッサは、Tbox上で、車両管理プラットフォームから車両を返却するアクションを処理するための第1の命令を受信しうる。少なくとも1つのプロセッサは、Tbox上で、第1の命令に応じて車両を返却するアクションを実行しうる。少なくとも1つのプロセッサは、車両を返却するアクションが完了すると、Tboxから、車両に関するフィードバック情報を車両管理プラットフォームに送信しうる。少なくとも1つのプロセッサは、Tbox上で、車両管理プラットフォームから、作動モードからスリープモードへのTboxのモード変更をトリガするための第2の命令を受信しうる。第2の命令は、フィードバック情報に従って車両管理プラットフォームによって生成され得る。

本開示の他の態様によれば、非一時的コンピュータ可読媒体が、車両のテレマティクスボックス（Tbox）を制御するために提供される。車両のTboxは、車両の共有使用を提供するように構成された車両管理プラットフォームに接続され得る。非一時的コンピュータ可読媒体は、少なくとも1つのプロセッサに方法を実行させる実行可能命令を含みうる。本方法は、以下の動作のうちの1つまたは複数を含みうる。少なくとも1つのプロセッサは、Tbox上で、車両管理プラットフォームから車両を返却するアクションを処理するための第1の命令を受信しうる。少なくとも1つのプロセッサは、Tbox上で、第1の命令に応じて車両を返却するアクションを実行しうる。少なくとも1つのプロセッサは、車両を返却するアクションが完了すると、Tboxから、車両に関するフィードバック情報を車両管理プラットフォームに送信しうる。少なくとも1つのプロセッサは、Tbox上で、車両管理プラットフォームから、作動モードからスリープモードへのTboxのモード変更をトリガするための第2の命令を受信しうる。第2の命令は、フィードバック情報に従って車両管理プラットフォームによって生成され得る。

本開示の他の態様によれば、車両をロック解除するための方法が提供される。テレマティクスボックス（Tbox）を有するように構成された車両は、車両の共有使用を提供するように構成された車両管理プラットフォームに接続され得る。本方法は、以下の動作のうちの1つまたは複数を含みうる。少なくとも1つのプロセッサは、車両管理プラットフォーム上で、ユーザ端末から、車両を返却するアクションについての要求を受信することができ、要求は車両のTboxの識別子を含む。少なくとも1つのプロセッサは、要求の受信時に秘密鍵を生成しうる。少なくとも1つのプロセッサは、車両管理プラットフォームから、Tboxへの秘密鍵を含む命令を与えることができ、秘密鍵は車両をロック解除するように構成される。

いくつかの実施形態では、少なくとも1つのプロセッサは、車両管理プラットフォーム上で、第2のユーザ端末から、車両をロック解除するアクションについての第2の要求を受信することができ、要求は車両のTboxの識別子を含む。第2の要求に応じて、少なくとも1つのプロセッサは、車両管理プラットフォームから、第2の秘密鍵を含む第2の命令を第2のユーザ端末に与えうる。少なくとも1つのプロセッサは、秘密鍵と第2の秘密鍵との間のマッチング動作を実行しうる。少なくとも1つのプロセッサは、秘密鍵と第2の秘密鍵との一致に応じて、車両をロック解除しうる。

いくつかの実施形態では、少なくとも1つのプロセッサは、車両管理プラットフォーム上で、第2のユーザ端末または車両から、車両がロック解除に失敗したことを示す情報を受信しうる。車両がロック解除に失敗したことを示す受信情報に応じて、少なくとも1つのプロセッサは、車両管理プラットフォームからTboxに、秘密鍵を再設定するための第3の命令を与えうる。

いくつかの実施形態では、少なくとも1つのプロセッサは、車両管理プラットフォーム上で、Tboxの秘密鍵の正常な再設定を示す情報を受信しうる。Tboxの秘密鍵の正常な再設定を示す情報に応じて、少なくとも1つのプロセッサは、車両管理プラットフォームを介して、車両のロック解除を再試行するように促すための第2のユーザ端末への第4の命令を生成しうる。

本開示の他の態様によれば、車両をロック解除するためのシステムが提供される。テレマティクスボックス（Tbox）を有するように構成された車両は、車両の共有使用を提供するように構成された車両管理プラットフォームに接続され得る。システムは、少なくとも1つの記憶装置、少なくとも1つの記憶装置と通信する少なくとも1つのプロセッサを含みうる。少なくとも1つの記憶装置は、1つまたは複数の命令セットを含みうる。1つまたは複数の命令セットを実行すると、少なくとも1つのプロセッサは、車両管理プラットフォーム上で、ユーザ端末から、車両を返却するアクションについての要求を受信することができ、要求は車両のTboxの識別子を含む。少なくとも1つのプロセッサは、要求の受信時に秘密鍵を生成しうる。少なくとも1つのプロセッサは、車両管理プラットフォームから、Tboxへの秘密鍵を含む命令を与えることができ、秘密鍵は車両をロック解除するように構成される。

本開示の他の態様によれば、車両をロック解除するために、非一時的コンピュータ可読媒体が提供される。テレマティクスボックス（Tbox）を有するように構成された車両は、車両の共有使用を提供するように構成された車両管理プラットフォームに接続され得る。非一時的コンピュータ可読媒体は、少なくとも1つのプロセッサに方法を実行させる実行可能命令を含みうる。本方法は、以下の動作のうちの1つまたは複数を含みうる。少なくとも1つのプロセッサは、車両管理プラットフォーム上で、ユーザ端末から、車両を返却するアクションについての要求を受信することができ、要求は車両のTboxの識別子を含む。少なくとも1つのプロセッサは、要求の受信時に秘密鍵を生成しうる。少なくとも1つのプロセッサは、車両管理プラットフォームから、Tboxへの秘密鍵を含む命令を与えることができ、秘密鍵は車両をロック解除するように構成される。

本開示の他の態様によれば、車両をロック解除するための方法が提供される。テレマティクスボックス（Tbox）を有するように構成された車両は、車両の共有使用を提供するように構成された車両管理プラットフォームに接続され得る。本方法は、以下の動作のうちの1つまたは複数を含みうる。少なくとも1つのプロセッサは、Tbox上で、車両管理プラットフォームから命令を受信することができ、命令は、車両をロック解除するように構成された秘密鍵を含む。少なくとも1つのプロセッサは、命令に基づいて、秘密鍵をTboxのターゲット秘密鍵として再設定しうる。

いくつかの実施形態では、少なくとも1つのプロセッサは、Tbox上で、第2のユーザ端末から第2の秘密鍵を受信しうる。第2の秘密鍵は、車両管理プラットフォームが第2のユーザ端末から車両をロック解除するアクションについての要求を受信したときに、車両管理プラットフォームによって生成される第2の命令の一部であってもよく、第2の秘密鍵は、車両管理プラットフォームから第2のユーザ端末に送信され得る。少なくとも1つのプロセッサは、秘密鍵と第2の秘密鍵との間のマッチング動作を実行し、秘密鍵と第2の秘密鍵との一致に応じて車両をロック解除しうる。

いくつかの実施形態では、少なくとも1つのプロセッサは、Tbox上で、車両管理プラットフォームから、秘密鍵を再設定するための第3の命令を受信しうる。少なくとも1つのプロセッサは、第3の命令に応じてTboxの秘密鍵を再設定し、Tboxから車両管理プラットフォームに、Tboxの秘密鍵の正常な再設定を示す情報を送信しうる。

本開示の他の態様によれば、車両をロック解除するためのシステムが提供される。テレマティクスボックス（Tbox）を有するように構成された車両は、車両の共有使用を提供するように構成された車両管理プラットフォームに接続され得る。システムは、少なくとも1つの記憶装置、少なくとも1つの記憶装置と通信する少なくとも1つのプロセッサを含みうる。少なくとも1つの記憶装置は、1つまたは複数の命令セットを含みうる。1つまたは複数の命令セットを実行すると、少なくとも1つのプロセッサは、Tbox上で、車両管理プラットフォームから命令を受信することができ、命令は、車両をロック解除するように構成された秘密鍵を含む。少なくとも1つのプロセッサは、命令に基づいて、秘密鍵をTboxのターゲット秘密鍵として再設定しうる。

本開示の他の態様によれば、車両をロック解除するために、非一時的コンピュータ可読媒体が提供される。テレマティクスボックス（Tbox）を有するように構成された車両は、車両の共有使用を提供するように構成された車両管理プラットフォームに接続され得る。非一時的コンピュータ可読媒体は、少なくとも1つのプロセッサに方法を実行させる実行可能命令を含みうる。本方法は、以下の動作のうちの1つまたは複数を含みうる。少なくとも1つのプロセッサは、Tbox上で、車両管理プラットフォームから命令を受信することができ、命令は、車両をロック解除するように構成された秘密鍵を含む。少なくとも1つのプロセッサは、命令に基づいて、秘密鍵をTboxのターゲット秘密鍵として再設定しうる。

追加の特徴は、以下の説明に部分的に記載され、部分的には、以下および添付した図面を検討することにより当業者に明らかになるか、または実施例の製造または動作によって学習され得る。本開示の特徴は、以下で説明される詳細な例に示す方法論、手段、および組み合わせの様々な側面の実践または使用によって実現および達成され得る。

本開示は、例示的な実施形態によりさらに説明される。これらの例示的な実施形態は、図面を参照して詳細に説明される。図面は原寸に比例していない。これらの実施形態は、非限定的な例示的な実施形態であり、図面のいくつかの図全体を通して、同様の符号は同様の構造を表す。

本開示のいくつかの実施形態による、例示的なモノのインターネット（IoT）システムを示す概略図である。 本開示のいくつかの実施形態による、IoTプラットフォームが実装され得るコンピューティングデバイスの例示的な構成要素を示す概略図である。 本開示のいくつかの実施形態による、端末が実装され得る例示的なモバイルデバイスの例示的なハードウェアおよび／またはソフトウェア構成要素を示す概略図である。 本開示のいくつかの実施形態による、オブジェクトが実装され得るコンピューティングデバイスの例示的な構成要素を示す概略図である。 本開示のいくつかの実施形態による、IoTプラットフォームが実装され得る例示的な処理装置を示すブロック図である。 本開示のいくつかの実施形態による、図5に示す処理装置の例示的な処理モジュールを示すブロック図である。 本開示のいくつかの実施形態による、オブジェクトが実装され得る例示的な処理装置を示すブロック図である。 本開示のいくつかの実施形態による、図7に示す処理装置の例示的な処理モジュールを示すブロック図である。 本開示のいくつかの実施形態による、アイテムを管理するための例示的なプロセスを示すフローチャートである。 本開示のいくつかの実施形態による、アイテムを管理するための例示的なパイプラインプロセスを示すフローチャートである。 本開示のいくつかの実施形態による、アイテムを管理するための例示的なパイプラインプロセスを示すフローチャートである。 本開示のいくつかの実施形態による、車両のTboxを制御するための例示的なプロセスを示すフローチャートである。 本開示のいくつかの実施形態による、車両のTboxを制御するための例示的なパイプラインプロセスを示すフローチャートである。 本開示のいくつかの実施形態による、車両のTboxを制御するための例示的なプロセスを示すフローチャートである。 本開示のいくつかの実施形態による、車両をロック解除するための例示的なプロセスを示すフローチャートである。 本開示のいくつかの実施形態による、車両をロック解除するための例示的なプロセスを示すフローチャートである。 本開示のいくつかの実施形態による、車両をロック解除するための例示的なプロセスを示すフローチャートである。

以下の説明は、当業者が本開示を作製および使用できるようにするために提示され、特定の用途およびその要件の文脈で提供される。開示された実施形態に対する様々な修正は、当業者には容易に明らかであり、本明細書で定義された一般原理は、本開示の趣旨および範囲から逸脱することなく、他の実施形態および用途に適用され得る。したがって、本開示は、示された実施形態に限定されず、特許請求の範囲と矛盾しない最も広い範囲が与えられるべきである。

本明細書で使用される用語は、特定の例示的な実施形態を説明するためだけであり、限定することを意図するものではない。本明細書で使用される単数形「a」、「an」、および「the」は、文脈がそうでないことを明確に示さない限り、複数形も含むことが意図され得る。本明細書で使用される場合、「備える」、「備える」、および／または「備える」、「含む」、「含む」、および／または「含む」という用語は、述べられた特徴、整数、ステップ、動作、要素、および／または構成要素の存在を指定するが、1つまたは複数の他の特徴、整数、ステップ、動作、要素、構成要素、および／またはそれらのグループの存在または追加を排除するものではないことがさらに理解されよう。

本開示のこれらのおよび他の特徴、ならびに特性、ならびに動作の方法および構造の関連する要素の機能ならびに部品の組み合わせおよび製造の経済性は、添付の図面を参照して以下の説明を検討すると、より明確になり得るが、これらの図面はすべて本開示の一部を形成する。しかし、図面は例示および説明のみを目的としており、本開示の範囲を限定することを意図していないことを明確に理解されたい。図面は縮尺通りではないことが理解される。

本開示で使用されるフローチャートは、本開示のいくつかの実施形態に従ってシステムが実施する動作を示す。明確に理解されるべきことであるが、フローチャートの動作は、順不同で実施されてもよい。逆に、動作は逆の順序で、または同時に実施されてもよい。さらに、フローチャートに1つまたは複数の他の動作が追加されてもよい。フローチャートから1つまたは複数の動作が削除されてもよい。

さらに、本開示のシステムおよび方法は、主にアイテムの共有使用（例えば、共有サービス）を提供することに関して説明されているが、これは例示目的であり、限定することを意図するものではないことも理解されたい。本開示のシステムまたは方法は、モノのインターネット（IoT）に関連する他の任意の種類のオンラインからオフライン（O2O）サービスに適用され得る。例えば、本開示のシステムまたは方法は、陸上、海洋、航空宇宙など、またはそれらの任意の組み合わせを含む異なる環境の輸送システムに適用され得る。輸送システムの車両は、タクシー、自家用車、ヒッチ、バス、電車、新幹線、高速鉄道、地下鉄、船舶、航空機、宇宙船、熱気球、無人車両、e－バイク、自転車など、またはそれらの任意の組み合わせを含んでもよい。輸送システムはまた、管理および／または配布のための任意の輸送システム、例えば、至急便を送付および／または受け取るためのシステムを含んでもよい。本開示のシステムまたは方法の用途は、ユーザデバイス上で実施されてもよく、ウェブページ、ブラウザのプラグイン、クライアント端末、カスタムシステム、内部解析システム、人工知能ロボットなど、またはそれらの任意の組み合わせを含んでもよい。

本開示における「要求者」、「サービス要求者」、および「顧客」という用語は、サービスを要求または発注しうる個人、エンティティ、またはツールを指すために交換可能に使用される。また、本開示における「提供者」、「サービス提供者」、および「販売業者」という用語は、サービスを提供しうる、またはサービスの提供を容易にしうる個人、エンティティ、またはツールを指すために交換可能に使用される。

本開示における「サービス要求」、「サービスに対する要求」、「要求」、および「発注」という用語は、同義的に使用され、サービス要求者、顧客、提供者、サービス提供者など、またはそれらの任意の組み合わせによって開始され得る要求を指す。サービス要求は、プラットフォーム（例えば、車両管理プラットフォーム）を介して、サービス要求者、顧客、提供者、またはサービス提供者のいずれかによって受け入れられ得る。サービス要求は有料または無料であってもよい。

「テレマティクス」という用語は、長距離通信のための電気通信と情報科学（情報学）の複合語である。これは、自動車、航空会社、船舶、列車に組み込まれたサービスシステムとして定義され得、コンピュータシステム、インターネット技術、無線通信技術、衛星航法装置、およびデータ交換技術を通じて情報を提供する。言い換えれば、車両は無線ネットワークを介してインターネットに接続され、運転および生活に必要な情報を所有者に提供しうる。

「テレマティクスボックス」という用語は、車両のTboxとして知られており、車両管理プラットフォームまたはモバイルアプリケーションと通信して、車両情報を表示し、車両の動作を制御するために使用される。Tboxは、人と車の間の対話的なインテリジェント情報端末を指しうる。ユーザは、GPRS（2G／3G／4G／5Gなどの汎用パケット無線サービス）、Bluetooth、WIFI、および／またはモバイルデバイスまたは車両管理プラットフォームを介したその他の通信方法を使用して、車両と通信しうる。例えば、ユーザまたは車両管理プラットフォームは、安全監視、故障診断、遠隔制御、情報共有、車両システム更新などの車両操作を実行するためにTboxを制御しうる。

「車両管理プラットフォーム」という用語は、GPRS（2G／3G／4G／5Gなどの汎用パケット無線サービス）、Bluetooth、もしくはWIFI、および／または車両と通信するための他の通信機構を使用するバックエンドシステムを指しうる。例えば、車両管理プラットフォームは、安全監視、故障診断、遠隔制御、情報共有、車両システム更新などの車両操作を実行するためにTboxを制御しうる。

図1は、本開示のいくつかの実施形態による、例示的なモノのインターネット（IoT）システムを示す概略図である。IoTシステム100は、データおよび／または情報処理、例えば、IoTシステム100に含まれる1つまたは複数の構成要素に関する情報を処理するためのプラットフォームであってもよい。いくつかの実施形態では、IoTシステム100は、例えば、チェックアウトアクションまたは返却アクションを実行するために、車両の共有使用に関連するサービス要求を処理するためのシステム（例えば、車両管理システム）を含んでもよい。いくつかの実施形態では、サービスは、カーシェアリングサービス、自転車シェアリングサービスなどのような輸送サービスであってもよい。いくつかの実施形態では、サービスは、ドローン、エアロカー、車椅子、充電器など、またはそれらの任意の組み合わせを共有するなど、他のオンラインからオフラインへの（O2O）サービスであってもよい。

IoTシステム100は、第1の情報交換ポート101、第2の情報交換ポート102、IoTプラットフォーム110、ユーザ端末システム130、ターゲットアイテムシステム140を含む情報交換ポートシステムを含みうる。IoTプラットフォーム110は、サーバ111および記憶装置113を含みうる。ユーザ端末システム130は、サービス要求者に関連する1つまたは複数のユーザ端末を含みうる。ターゲットアイテムシステム140は、サービス要求に応じてサービスを提供しうる1つまたは複数のアイテムを含みうる。例えば、IoTプラットフォーム110は、カーシェアリングサービスを提供するように構成された車両管理プラットフォームを含むことができ、ユーザ端末システム130は、車両管理プラットフォームに登録されたユーザに関連する1つまたは複数のユーザ端末を含むことができ、ターゲットアイテムシステム140は、1つまたは複数の共有車両を含みうる。

いくつかの実施形態では、IoTプラットフォーム110は、第1の情報交換ポート101および第2の情報交換ポート102を介して、1つもしくは複数のユーザ端末および1つもしくは複数のターゲットアイテムとそれぞれ通信しうる。例えば、IoTプラットフォーム110のサーバ111は、第1の情報交換ポート101を介して、サービス要求者のモバイルデバイスからの注文要求に関連する情報および／またはデータを受信しうる。他の例として、IoTプラットフォーム110のサーバ111は、第2の情報交換ポート102を介して、ターゲットアイテム（例えば、車両のTbox）のコントローラからの情報および／またはデータにアクセスしうる。さらに他の例として、IoTプラットフォーム110のサーバ111は、情報交換ポートシステムを介して、情報および／またはデータをサービス要求者のモバイルデバイスまたはターゲットアイテムのコントローラに送信しうる。いくつかの実施形態では、情報交換ポートシステム（すなわち、第1の情報交換ポート101および第2の情報交換ポート102）は、単一のデバイスに統合されてもよい。いくつかの実施形態では、第1の情報交換ポート101および第2の情報交換ポート102は、分離されて、異なる装置の一部であってもよい。例えば、第1の情報交換ポート101は、ユーザ端末システム130の一部であってもよく、第2の情報交換ポート102は、ターゲットアイテムシステム140の一部であってもよい。

いくつかの実施形態では、サーバ111は、単一のサーバまたはサーバグループであってもよい。サーバグループは、集中型または分散型であってもよい（例えば、サーバ111は分散型システムであってもよい）。いくつかの実施形態では、サーバ111は、クラウドプラットフォーム上に実装されてもよい。単なる例として、クラウドプラットフォームは、プライベートクラウド、パブリッククラウド、ハイブリッドクラウド、コミュニティクラウド、分散クラウド、インタークラウド、マルチクラウドなど、またはそれらの任意の組み合わせを含んでもよい。いくつかの実施形態では、サーバ111は、本開示の図2に示す1つまたは複数の構成要素を有するコンピューティングデバイス上に実装されてもよい。

いくつかの実施形態では、サーバ111は、処理装置112を含んでもよい。処理装置112は、本開示で説明される1つまたは複数の機能を実行するために、要求に関する情報および／またはデータを処理しうる。例えば、処理装置112は、第1の情報交換ポート101を介してモバイルデバイス130－1から要求を取得し、要求に応じてモバイルデバイス130－1および／またはターゲットアイテム140－1に関連する1つまたは複数の命令を生成しうる。いくつかの実施形態では、処理装置112は、1つまたは複数のプロセッサ（例えば、シングルコアプロセッサまたはマルチコアプロセッサ）を含んでもよい。単なる例として、処理装置112は、中央処理装置（CPU）、特定用途向け集積閉路（ASIC）、特定用途向け命令セットプロセッサ（ASIP）、グラフィック処理装置（GPU）、物理処理装置（PPU）、デジタルシグナルプロセッサ（DSP）、フィールドプログラマブルゲートアレイ（FPGA）、プログラマブルロジックデバイス（PLD）、コントローラ、マイクロコントローラユニット、縮小命令セットコンピュータ（RISC）、マイクロプロセッサなど、またはそれらの任意の組み合わせを含んでもよい。

記憶装置113は、データおよび／または命令を格納しうる。いくつかの実施形態では、記憶装置113は、ユーザ端末システム130および／またはターゲットアイテムシステム140から取得／獲得されたデータを格納しうる。いくつかの実施形態では、記憶装置113は、本開示で説明される例示的な方法および／またはプロセスを実行するためにサーバ111が実行または使用しうるデータおよび／または命令を格納しうる。いくつかの実施形態では、記憶装置113は、大容量記憶装置、取り外し可能な記憶装置、揮発性読み書きメモリ、読み出し専用メモリ（ROM）など、またはそれらの任意の組み合わせを含んでもよい。例示的な大容量記憶装置は、磁気ディスク、光ディスク、ソリッドステートドライブなどを含んでもよい。例示的な取り外し可能な記憶装置は、フラッシュドライブ、フロッピーディスク、光ディスク、メモリカード、zipディスク、磁気テープなどを含んでもよい。例示的な揮発性読み書きメモリは、ランダムアクセスメモリ（RAM）を含んでもよい。例示的なRAMは、ダイナミックRAM（DRAM）、ダブルデータレート同期ダイナミックRAM（DDR SDRAM）、スタティックRAM（SRAM）、サイリスタRAM（T－RAM）、およびゼロキャパシタRAM（Z－RAM）などを含んでもよい。例示的なROMは、マスクROM（MROM）、プログラム可能ROM（PROM）、消去可能プログラム可能ROM（PEROM）、電気的消去可能プログラム可能ROM（EEPROM）、コンパクトディスクROM（CD－ROM）、およびデジタル多用途ディスクROMなどを含んでもよい。いくつかの実施形態では、記憶装置113は、クラウドプラットフォーム上に実装されてもよい。単なる例として、クラウドプラットフォームは、プライベートクラウド、パブリッククラウド、ハイブリッドクラウド、コミュニティクラウド、分散クラウド、インタークラウド、マルチクラウドなど、またはそれらの任意の組み合わせを含んでもよい。

いくつかの実施形態では、記憶装置113は、サーバ111に接続されるか、またはサーバ111と通信しうる。サーバ111は、記憶装置113に直接またはネットワークを介して格納されたデータまたは命令にアクセスしうる。いくつかの実施形態では、記憶装置113は、サーバ111の一部であってもよい。

いくつかの実施形態では、ユーザ端末システム130は、モバイルデバイス130－1、タブレットコンピュータ130－2、ラップトップコンピュータ130－3、車両内の組み込みデバイス130－4など、またはそれらの任意の組み合わせを含んでもよい。サービス要求者は、ユーザ端末システム130に含まれるユーザ端末を介して、ターゲットアイテムに関連するサービスを要求しうる。いくつかの実施形態では、モバイルデバイス130－1は、スマートホームデバイス、ウェアラブルデバイス、スマートモバイルデバイス、仮想現実デバイス、拡張現実デバイスなど、またはそれらの任意の組み合わせを含んでもよい。いくつかの実施形態では、スマートホームデバイスは、スマート照明デバイス、インテリジェント電気装置の制御デバイス、スマートモニタリングデバイス、スマートテレビ、スマートビデオカメラ、インターホンなど、またはそれらの任意の組み合わせを含んでもよい。いくつかの実施形態では、ウェアラブルデバイスは、スマートブレスレット、スマートフットギア、スマートメガネ、スマートヘルメット、スマートウォッチ、スマート衣類、スマートバックパック、スマートアクセサリなど、またはそれらの任意の組み合わせを含んでもよい。いくつかの実施形態では、スマートモバイルデバイスは、スマートフォン、携帯情報端末（PDA）、ゲームデバイス、ナビゲーションデバイス、販売時点情報管理（POS）デバイスなど、またはそれらの任意の組み合わせを含んでもよい。いくつかの実施形態では、仮想現実デバイスおよび／または拡張現実デバイスは、仮想現実ヘルメット、仮想現実メガネ、仮想現実パッチ、拡張現実ヘルメット、拡張現実メガネ、拡張現実パッチなど、またはそれらの任意の組み合わせを含んでもよい。例えば、仮想現実デバイスおよび／または拡張現実デバイスは、Google（商標）Glass、Oculus Rift、HoloLens、Gear VRなどを含んでもよい。いくつかの実施形態では、車両の組み込みデバイス130－4は、車載コンピュータ、車載テレビなどを含んでもよい。いくつかの実施形態では、ユーザ端末は、要求者および／またはユーザ端末の位置を特定するための測位技術（例えば、GPS）を備えたデバイスであってもよい。

いくつかの実施形態では、ターゲットアイテムシステム140は、IoTプラットフォーム110に関連して1つまたは複数のアイテムを含みうる。例えば、ターゲットアイテムシステム140は、複数のターゲットデバイス（またはターゲットアイテム）140－1、140－2、140－3を含みうる。ターゲットデバイスは、車両、自転車、ドローンなどの1つまたは複数、あるいはそれらの組み合わせであってもよい。他の例として、ターゲットアイテムシステム140は、1つもしくは複数の車両、1つもしくは複数の自転車、および／または1つもしくは複数のドローンを含みうる。いくつかの実施形態では、ターゲットアイテムは、アイテムを制御するように構成されたコントローラ（例えば、車両のTbox、または自転車の処理装置）を含みうる。コントローラは、ユーザ端末システム130および／またはIoTプラットフォーム110と通信しうる。例えば、IoTシステム100は、コントローラの動作モードを変更するための1つまたは複数の命令をコントローラに送信しうる。他の例として、ユーザ端末は、アイテムをロック解除するための1つまたは複数の命令をコントローラに送信しうる。いくつかの実施形態では、アイテムは、1つのタイプのサービス（例えば、カーシェアリングサービス、自転車シェアリングサービス、またはドローンシェアリングサービスなど）に対応しうる。

測位システム160は、オブジェクトまたはターゲット、例えば、1つまたは複数のユーザ端末、1つまたは複数の車両に関連する情報を決定しうる。いくつかの実施形態では、測位システム160は、全地球測位システム（GPS）、全地球航法衛星システム（GLONASS）、コンパス航法システム（COMPASS）、北斗航法衛星システム、ガリレオ測位システム、準天頂衛星システム（QZSS）などであってもよい。情報には、オブジェクトの位置、高度、速度、加速度、または現在の時刻が含まれてもよい。測位システム160は、1つまたは複数の衛星、例えば、衛星160－1、衛星160－2、および衛星160－3を含んでもよい。衛星160－1～160－3は、独立してまたは共同で上記の情報を決定しうる。測位システム160は、無線接続を介して、上記の情報をユーザ端末システム130、ターゲットアイテムシステム140に送信しうる。いくつかの実施形態では、測位システム160は、情報をサーバ111に直接送信しうる。

ネットワーク170－1から170－3は、情報および／またはデータの交換を容易にしうる。いくつかの実施形態では、IoTプラットフォーム110内の1つまたは複数の構成要素（例えば、サーバ111および／または記憶装置113）は、ネットワーク170－1～170－3を介してユーザ端末システム130および／またはターゲットアイテムシステム140との間で情報および／またはデータを送信および／または受信しうる。例えば、サーバ111は、ネットワーク170－1を介してサービス要求に関連するデータを取得しうる。他の例として、サーバ111は、ネットワーク170－2を介してターゲットアイテムの利用可能性ステータスを取得しうる。いくつかの実施形態では、ネットワーク170－1～170－3は、任意のタイプの有線または無線ネットワーク、あるいはそれらの組み合わせであってもよい。単なる例として、ネットワーク170は、ケーブルネットワーク、有線ネットワーク、光ファイバネットワーク、電気通信ネットワーク、イントラネット、インターネット、ローカルエリアネットワーク（LAN）、ワイドエリアネットワーク（WAN）、無線ローカルエリアネットワーク（WLAN）、メトロポリタンエリアネットワーク（MAN）、ワイドエリアネットワーク（WAN）、公衆電話交換ネットワーク（PSTN）、Bluetooth（商標）ネットワーク、ZigBee（商標）ネットワーク、近接場通信（NFC）ネットワーク、モバイル通信（GSM）ネットワーク用グローバルシステム、符号分割多重アクセス（CDMA）ネットワーク、時間分割多重アクセス（TDMA）ネットワーク、汎用パケット無線サービス（GPRS）ネットワーク、GSMエボリューション用拡張データレート（EDGE）ネットワーク、広帯域符号分割多重アクセス（WCDMA（登録商標））ネットワーク、高速ダウンリンクパケットアクセス（HSDPA）ネットワーク、ロングタームエボリューション（LTE）ネットワーク、ユーザデータグラムプロトコル（UDP）ネットワーク、伝送制御プロトコル／インターネットプロトコル（TCP／IP）ネットワーク、ショートメッセージサービス（SMS）ネットワーク、無線アプリケーションプロトコル（WAP）ネットワーク、超広帯域（UWB）ネットワーク、赤外線など、またはこれらの任意の組み合わせを含んでもよい。

図2は、本開示のいくつかの実施形態による、IoTプラットフォームが実装され得るコンピューティングデバイスの例示的な構成要素を示す概略図である。本明細書で使用されるように、IoTプラットフォーム110は、図2に示すコンピューティングデバイス200上に実装され得る。

特定のシステムは、機能ブロック図を使用して、1つまたは複数のユーザインターフェースを含むハードウェアプラットフォームを説明しうる。コンピューティングデバイスは、一般的または特定の機能を備えたコンピュータであってもよい。両方のタイプのコンピュータは、本開示のいくつかの実施形態による任意の特定のシステムを実装するように構成され得る。コンピューティングデバイス200は、本開示で開示される1つまたは複数の機能を実行する任意の構成要素を実装するように構成され得る。例えば、ROM230および／またはRAM240は、プロセッサ220が本開示に記載された例示的な方法および／またはプロセスを実行するために実行または使用しうるデータおよび／または命令を格納しうる。いくつかの実施形態では、プロセッサ220は、ユーザ端末からアイテムに関連するアクションについての要求を受信しうる。プロセッサ220は、要求に応じてアクションを処理するための第1の命令を生成しうる。プロセッサ220は、アイテムのオブジェクト（例えば、車両のTbox）またはユーザ端末に第1の命令を与えうる。プロセッサ220は、アクションが完了するとアイテムに関するフィードバック情報を取得しうる。プロセッサ220は、オブジェクト（例えば、Tbox）の動作モードをトリガするための第2の命令を生成しうる。

単に例示のために、いくつかの実施形態では、プロセッサ220は、第1のユーザ端末から車両管理プラットフォームに接続されたステーションに車両を返却するための第1の要求を受信しうる。プロセッサ220は、第1の命令を生成し、第1の要求に含まれる識別子に対応するTboxに送信しうる。第1の命令は、車両の返却を処理するために使用され得る。受信した第1の命令に応じて、Tboxは、車両の返却を実行し、車両の返却に関するフィードバック情報を送信しうる。フィードバック情報を受信すると、プロセッサ220は、Tboxを作動モードからスリープモードにトリガするための第2の命令を生成しうる。第2の命令に応じて、Tboxは作動モードからスリープモードに変更され得る。車両の返却が終了すると、Tboxはスリープモードに入りうる。スリープモード中、車両はTboxを呼び起こすために通信機能を開くだけで、他の機能は閉じられることができ、これにより、Tboxの消費電力を削減し、Tboxの寿命を延ばしうる。

いくつかの実施形態では、第1のユーザからの車両の返却を完了すると、プロセッサ220は、車両のTboxに対応する少なくとも1つの秘密鍵を生成しうる。プロセッサ220は、秘密鍵再設定命令をTboxに与えうる。秘密鍵再設定命令は、第1の秘密鍵を含む。Tboxは、第1の秘密鍵をTboxのターゲット秘密鍵として再設定しうる。第2のユーザが車両管理プラットフォームから車両をチェックアウトしたい場合、第2のユーザは車両をロック解除するためにTboxのターゲット秘密鍵を要求する必要がある。Tboxのターゲット秘密鍵は動的に更新され得、これにより車両の安全性を向上させうる。場合によっては、ターゲットの秘密鍵は常にTbox自体によって生成され、変更されない。ユーザがターゲット秘密鍵を取得すると、ユーザは秘密鍵を使用して何度も車両をロック解除することができ、これは車両の大きなセキュリティリスクを引き起こす。したがって、動的に更新された秘密鍵は、車両の安全性を向上させうる。

コンピューティングデバイス200は、本明細書で説明するように、IoTプラットフォーム110の任意の構成要素を実装しうる。図1～図2では、単に便宜上の目的で、このようなコンピュータデバイスが1つだけ示されている。当業者は、本願の出願時に、本明細書に記載されるサービスに関連するコンピュータ機能が、多くの同様のプラットフォーム上に分散して実装され、処理負荷を分散しうることを理解するであろう。

コンピューティングデバイス200は、例えば、データ通信を容易にするために、それに接続されたネットワークに接続され、かつネットワークから接続されたCOMポート250を含んでもよい。コンピューティングデバイス200はまた、プログラム命令を実行するための1つまたは複数のプロセッサ（例えば、論理回路）の形態のプロセッサ（例えば、プロセッサ220）を含みうる。例えば、プロセッサは、その中にインターフェース回路および処理回路を含みうる。インターフェース回路は、バス210から電子信号を受信するように構成され得、電子信号は、処理回路が処理するための構造化データおよび／または命令をエンコードする。処理回路は、論理計算を行い、次に電子信号としてエンコードされた結論、結果、および／または命令を決定しうる。次に、インターフェース回路は、バス210を介して処理回路から電子信号を送信しうる。

例示的なコンピューティングデバイスは、コンピューティングデバイスによって処理および／または送信される様々なデータファイルのために、内部通信バス210、例えば、ディスク270、および読み取り専用メモリ（ROM）230、またはランダムアクセスメモリ（RAM）240を含む、異なる形式のプログラムストレージおよびデータストレージを含んでもよい。例示的なコンピューティングデバイスはまた、ROM230、RAM240、および／またはプロセッサ220によって実行される他のタイプの非一時的記憶媒体に格納されたプログラム命令を含んでもよい。本開示の方法および／またはプロセスは、プログラム命令として実装されてもよい。コンピューティングデバイス200はまた、コンピュータと他の構成要素との間の入力／出力をサポートするI／O構成要素260を含む。コンピューティングデバイス200はまた、ネットワーク通信を介してプログラミングおよびデータを受信してもよい。

単に説明のために、1つのプロセッサおよび／またはプロセッサのみが図2に示されている。複数のCPUおよび／またはプロセッサも考慮され、したがって、本開示で説明するように、1つのCPUおよび／またはプロセッサによって実行される動作および／または方法ステップはまた、複数のCPUおよび／またはプロセッサによって共同してまたは別々に実行されてもよい。例えば、本開示において、コンピューティングデバイス200のCPUおよび／またはプロセッサが動作Aおよび動作Bの両方を実行する場合には、動作Aおよび動作Bはまた、2つの異なるCPUおよび／またはプロセッサによって共同で実行されるか、あるいはコンピューティングデバイス200内で別々に実行されてもよいことを理解されたい（例えば、第1のプロセッサが動作Aを実行し、かつ第2のプロセッサが動作Bを実行する、あるいは第1および第2のプロセッサが共同で動作AおよびBを実行する）。

図3は、本開示のいくつかの実施形態による、端末が実装され得る例示的なモバイルデバイスの例示的なハードウェアおよび／またはソフトウェア構成要素を示す概略図である。本明細書で使用される場合、ユーザ端末システム130のユーザ端末は、本開示のいくつかの実施形態によるモバイルデバイス300上に実装され得る。図3に示すように、モバイルデバイス300は、通信モジュール310、ディスプレイ320、グラフィック処理ユニット（GPU）330、中央処理装置（CPU）340、I／O 350、メモリ360、およびストレージ390を含みうる。CPU340は、プロセッサ220と同様のインターフェース回路および処理回路を含みうる。いくつかの実施形態では、システムバスまたはコントローラ（図示せず）を含むが、これらに限定されない他の任意の適切な構成要素がモバイルデバイス300に含まれてもよい。いくつかの実施形態では、モバイルオペレーティングシステム370（例えば、iOS（商標）、Android（商標）、Windows Phone（商標）など）ならびに1つまたは複数のアプリケーション380は、CPU340によって実行されるために、ストレージ390からメモリ360にロードされてもよい。アプリケーション380は、モバイルデバイス300上のIoTプラットフォーム110からのサービス要求または他の情報に関連する情報を受信およびレンダリングするためのブラウザまたは任意の他の適切なモバイルアプリを含みうる。ユーザの情報ストリームとの対話は、I／Oデバイス350を介して達成され得、ネットワーク（例えば、ネットワーク170－1、170－2または170－3）を介して、処理装置112および／またはIoTプラットフォーム110の他の構成要素に提供され得る。

上記の様々なモジュール、ユニット、およびそれらの機能を実装するために、コンピュータハードウェアプラットフォームは1つまたは複数の要素（例えば、図1に記載のサーバ111の構成要素）のハードウェアプラットフォームとして使用され得る。これらのハードウェア要素、オペレーティングシステム、およびプログラム言語は一般的であるため、当業者はこれらの技術に精通しており、本開示に記載された技術に従って注文要求識別に必要な情報を提供しうる可能性があると想定され得る。ユーザインターフェースを備えたコンピュータは、パーソナルコンピューター（PC）、または他のタイプのワークステーションまたは端末装置として使用され得る。適切にプログラムされた後に、ユーザインターフェースを備えたコンピュータはサーバとして使用され得る。当業者はまた、このタイプのコンピュータデバイスのそのような構造、プログラム、または一般的な動作に精通している可能性があると考えられ得る。したがって、図については追加の説明は記載されていない。

図4は、本開示のいくつかの実施形態による、オブジェクトが実装され得るコンピューティングデバイスの例示的な構成要素を示す概略図である。例えば、ターゲットアイテムシステム140のアイテムのターゲットオブジェクト（例えば、車両管理システムの車両のTbox）は、本開示のいくつかの実施形態による、コンピューティングデバイス400上に実装され得る。コンピューティングデバイス400は、少なくとも通信バス410、プロセッサ420、および記憶装置430を含みうる。いくつかの実施形態では、プロセッサ420は、通信バス410を介して、記憶装置430、または外部のシステムもしくは装置（例えば、ユーザ端末システム130およびIoTプラットフォーム110）と通信しうる。いくつかの実施形態では、記憶装置430は、本開示で説明される例示的な方法および／またはプロセスを実行するためにプロセッサ420が実行または使用しうるデータおよび／または命令を格納しうる。

単に例示のために、いくつかの実施形態では、プロセッサ420は、車両管理プラットフォームから車両を返却するアクションを処理するための第1の命令を受信しうる。プロセッサ420は、第1の命令に応じて車両を返却するアクションを実行しうる。プロセッサ420は、車両を返却するアクションが完了すると、車両に関するフィードバック情報を車両管理プラットフォームに送信しうる。プロセッサ420は、例えば、作動モードからスリープモードへの、車両のTboxのモード変更をトリガするための第2の命令を受信しうる。第2の命令は、フィードバック情報に従って車両管理プラットフォームによって生成され得る。車両のTboxのモード変更をトリガすることのより多くの説明は、本開示の他の箇所（例えば、図12～図14、およびその説明）で見つけることができる。

いくつかの実施形態では、プロセッサ420は、車両管理プラットフォームから命令を受信しうる。命令は、車両をロック解除するように構成された秘密鍵を含みうる。プロセッサ420は、命令に基づいて、受信した秘密鍵をTboxのターゲット秘密鍵として再設定しうる。プロセッサ420は、ターゲット秘密鍵とユーザ端末から受信した秘密鍵との間のマッチング動作を実行しうる。プロセッサ420は、一致した結果に応じて車両をロック解除しうる。秘密鍵に従って車両をロック解除することのより多くの説明は、本開示の他の箇所（例えば、図15～図17、およびその説明）で見つけることができる。

図5は、本開示のいくつかの実施形態による、IoTプラットフォームが実装され得る例示的な処理装置を示すブロック図である。処理装置112は、第1の取得モジュール510、第1の処理モジュール520、および第1の送信モジュール530を含みうる。いくつかの実施形態では、第1の処理モジュール520は、図6に示すように、第1の処理ユニット610および第1のモードトリガユニット620をさらに含みうる。モジュールは、処理装置112の少なくとも一部のハードウェア回路であってもよい。モジュールはまた、処理装置112によって読み出されて実行されるアプリケーションまたは命令セットとして実装されてもよい。さらに、モジュールは、ハードウェア回路およびアプリケーション／命令の任意の組み合わせであってもよい。例えば、モジュールは、処理装置112がアプリケーション／命令セットを実行している場合に、処理装置112の一部であってもよい。

いくつかの実施形態では、第1の取得モジュール510は、サービス要求者のユーザ端末からアイテムに関連するアクションについての要求を受信しうる。いくつかの実施形態では、アイテムは、車両、自転車、ドローン、エアロカー、車椅子、充電器など、またはそれらの任意の組み合わせを含みうる。アイテムは、IoTプラットフォーム（例えば、IoTプラットフォーム110）に接続されたターゲットオブジェクトによって制御または管理され得る。例えば、ターゲットオブジェクトは、アイテムに組み込まれたコントローラ（例えば、車両のTbox）であってもよい。いくつかの実施形態では、アイテムに関連するアクションは、アイテムを返却すること、アイテムをロックすること、アイテムをチェックアウトすること、またはアイテムをロック解除することを含むがこれらに限定されない。車両共有サービスを例にとると、第1の取得モジュール510は、第1のサービス要求者が車両の使用を終了した後に第1のサービス要求者の第1のユーザ端末を介して、車両を車両管理プラットフォーム（例えば、車両を管理または制御するためのIoTプラットフォーム）に接続されたステーションに返却するための要求を受信しうる。第2のサービス要求者が車両の使用を望む場合、第1の取得モジュール510は、第2のサービス要求者の第2のユーザ端末を介して、車両管理プラットフォームから車両をチェックアウトするための要求を受信しうる。いくつかの実施形態では、第1の取得モジュール510は、車両をロックするための要求を受信しうる。いくつかの実施形態では、第1の取得モジュール510は、車両をロック解除するための要求を受信しうる。

いくつかの実施形態では、処理モジュール520の第1の処理ユニット610は、アクションを処理するための命令を生成しうる。例えば、第1の処理ユニット610は、要求を解析し、アクションを処理するための第1の命令を生成しうる。いくつかの実施形態では、第1の命令は、ターゲットオブジェクトのターゲット秘密鍵を設定または再設定するための秘密鍵再設定命令を含みうる。秘密再設定命令は、少なくとも1つの秘密鍵を含みうる。秘密鍵は、Bluetoothペアリングコード、メッセージ検証コードなど、またはこれらの任意の組み合わせを含みうる。例えば、秘密再設定命令は、第1のBluetoothペアリングコードを含み、第1のBluetoothペアリングコードは、車両のTboxのターゲット秘密鍵として再設定され得る。いくつかの実施形態では、第1の送信モジュール530は、生成された命令をユーザ端末またはアイテムのターゲットオブジェクトに送信または与えうる。アクションが完了すると、第1の取得モジュール510は、アクションに関するフィードバック情報を受信しうる。第1の取得モジュール510は、フィードバック情報を第1のモードトリガユニット620にさらに送信することができ、第1のモードトリガユニット620は、フィードバック情報に基づいてターゲットオブジェクトの動作モードをトリガするための第2の命令を生成しうる。いくつかの実施形態では、第2の命令は、少なくとも1つの秘密鍵を含みうる。少なくとも1つの秘密鍵が使用されて、動作モードをトリガしうる。いくつかの実施形態では、動作モードは、省エネモード、スリープモード、または作動モードを含みうるが、これらに限定されない。例えば、第1のモードトリガユニット620は、車両のTboxを作動モードからスリープモードにトリガするための命令を生成しうる。例として、第1のモードトリガユニット620は、車両のTboxをスリープモードから作動モードにトリガするための命令を生成しうる。

単に説明のために、いくつかの実施形態では、第1の取得モジュール510は、第1のユーザ端末から車両管理プラットフォームに接続されたステーションに車両を返却するための第1の要求を受信しうる。第1の処理ユニット610は、車両の返却を処理するための第1の命令を生成しうる。第1の送信モジュール530は、第1の要求に含まれる識別子に対応するTboxに第1の命令を送信しうる。受信した第1の命令に応じて、Tboxは、車両の返却を実行し、車両の返却に関するフィードバック情報を送信しうる。フィードバック情報を受信すると、第1のモードトリガユニット620は、Tboxを作動モードからスリープモードにトリガするための第2の命令を生成しうる。第2の命令に応じて、Tboxは作動モードからスリープモードに変更され得る。車両の返却が終了すると、Tboxはスリープモードに入りうる。スリープモード中、車両はTboxを呼び起こすために通信機能を開くだけで、他の機能は閉じられることができ、これにより、Tboxの消費電力を削減し、Tboxの寿命を延ばしうる。

いくつかの実施形態では、第1のユーザからの車両の返却を完了すると、第1の処理ユニット610は、車両のTboxに対応する少なくとも1つの秘密鍵を生成しうる。第1の送信モジュール530は、秘密鍵再設定命令をTboxに送信しうる。秘密鍵再設定命令は、第1の秘密鍵を含む。Tboxは、第1の秘密鍵をTboxのターゲット秘密鍵として再設定しうる。第2のユーザが車両管理プラットフォームから車両をチェックアウトしたい場合、第2のユーザは車両をロック解除するためにTboxのターゲット秘密鍵を要求する必要がある。Tboxのターゲット秘密鍵は動的に更新され得、これにより車両の安全性を向上させうる。場合によっては、ターゲットの秘密鍵は常にTbox自体によって生成され、変更されない。ユーザがターゲット秘密鍵を取得すると、ユーザは秘密鍵を使用して何度も車両をロック解除することができ、これは車両の大きなセキュリティリスクを引き起こす。したがって、動的に更新された秘密鍵は、車両の安全性を向上させうる。

処理装置112の上記の説明は、単に例示の目的で提供されており、本開示の範囲を限定することを意図していないことに留意されたい。当業者の場合、本開示の教示の下で、複数の変形および修正を行うことができる。例えば、処理装置112は、データの格納ジを容易にするストレージモジュールをさらに含みうる。しかし、それらの変形および修正は、本開示の範囲から逸脱しない。

図7は、本開示のいくつかの実施形態による、オブジェクトが実装され得る例示的な処理装置を示すブロック図である。プロセッサ420は、第2の取得モジュール710、第2の処理モジュール720、および第2の送信モジュール730を含みうる。いくつかの実施形態では、第2の処理モジュール720は、図8に示すように、第2の処理ユニット810および第2のモードトリガユニット820をさらに含みうる。モジュールは、プロセッサ420の少なくとも一部のハードウェア回路であってもよい。モジュールはまた、プロセッサ420によって読み出されて実行されるアプリケーションまたは命令セットとして実装されてもよい。さらに、モジュールは、ハードウェア回路およびアプリケーション／命令の任意の組み合わせであってもよい。例えば、モジュールは、プロセッサ420がアプリケーション／命令セットを実行している場合に、プロセッサ420の一部であってもよい。

第2の取得モジュール710は、ユーザ端末システム130またはIoTプラットフォーム110からデータまたは情報を取得しうる。いくつかの実施形態では、第2の取得モジュール710は、処理装置112によって生成された少なくとも1つの命令を受信しうる。例えば、第2の取得モジュール710は、サービス要求に含まれるアクションを処理するための第1の命令を受信しうる。アイテムに関するアクションは、アイテムの返却、アイテムのロック、アイテムのチェックアウト、またはアイテムのロック解除を含みうる。いくつかの実施形態では、アイテムは、車両、自転車、ドローン、エアロカー、車椅子、充電器など、またはそれらの任意の組み合わせを含みうる。アイテムは、IoTプラットフォーム（例えば、IoTプラットフォーム110）に接続されたターゲットオブジェクトによって制御または管理され得る。他の例として、第2の取得モジュール710は、ターゲットオブジェクト（例えば、車両のTbox）の動作モードをトリガするための第2の命令を受信しうる。

第2の処理モジュール720の第2の処理ユニット810は、処理装置112によって生成された1つまたは複数の命令に応じてアクションを処理しうる。例えば、第2の処理ユニット810は、アイテムの返却、アイテムのチェックアウト、アイテムのロック、またはアイテムのロック解除を含む1つまたは複数の動作を実行しうる。第2の処理モジュール720の第2のモードトリガユニット820は、ターゲットオブジェクトの動作モードをトリガしうる。例えば、第2のモードトリガユニット820は、ターゲットオブジェクトを作動モードからスリープモードにトリガしうる。他の例として、第2のトリガモードユニット820は、ターゲットオブジェクトをスリープモードから作動モードにトリガしうる。

第2の送信モジュール730は、ターゲットオブジェクトからユーザ端末システム130またはIoTプラットフォーム110にデータまたは情報を送信しうる。例えば、第2の処理ユニット810がサービス要求に含まれるアクションを終了すると、第2の送信モジュール730は、フィードバック情報をIoTプラットフォーム110（例えば、IoTプラットフォーム110の処理装置112またはIoTプラットフォーム110のプロセッサ220）に送信しうる。

単に例示のために、いくつかの実施形態では、第2の取得モジュール710は、車両管理プラットフォームから車両を返却するアクションを処理するための第1の命令を受信しうる。第2の処理ユニット810は、第1の命令に応じて車両を返却するアクションを実行しうる。第2の送信モジュール730は、車両を返却するアクションが完了すると、車両に関するフィードバック情報を車両管理プラットフォームに送信しうる。第2の取得モジュール710は、車両のTboxの作動モードからスリープモードへのモード変更をトリガするための第2の命令を受信しうる。第2の命令は、フィードバック情報に従って車両管理プラットフォームによって生成され得る。第2のモードトリガユニット820は、Tboxのモード変更をトリガすることができ、例えば、第2のモードトリガ820は、Tboxを作動モードからスリープモードにトリガしうる。車両のTboxのモード変更をトリガすることのより多くの説明は、本開示の他の箇所（例えば、図12～図14、およびその説明）で見つけることができる。

いくつかの実施形態では、第2の取得モジュール710は、車両管理プラットフォームから命令を受信しうる。命令は、車両をロック解除するように構成された秘密鍵を含みうる。第2の処理ユニット810は、命令に基づいて、受信した秘密鍵をTboxのターゲット秘密鍵として再設定しうる。第2の処理ユニット810は、ターゲット秘密鍵とユーザ端末から受信した秘密鍵との間のマッチング動作を実行しうる。第2の処理ユニット810は、一致した結果に応じて車両をロック解除しうる。秘密鍵に従って車両をロック解除することのより多くの説明は、本開示の他の箇所（例えば、図15～図17、およびその説明）で見つけることができる。

プロセッサ420の上記の説明は、単に例示の目的で提供されており、本開示の範囲を限定することを意図していないことに留意されたい。当業者の場合、本開示の教示の下で、複数の変形および修正を行うことができる。例えば、プロセッサ420は、データの格納を容易にするストレージモジュールをさらに含みうる。しかし、それらの変形および修正は、本開示の範囲から逸脱しない。

図9は、本開示のいくつかの実施形態による、アイテムを管理するための例示的なプロセスを示すフローチャートである。いくつかの実施形態では、プロセス900は、IoTシステム100上に実装されてもよい。例えば、プロセス900は、命令の形で記憶装置113および／またはストレージ（例えば、ROM230、RAM240、またはストレージ390）に格納され、サーバ111（例えば、サーバ111の処理装置112、またはコンピューティングデバイス200のプロセッサ220）によって呼び出され、および／または実行されてもよい。

ステップ902で、プロセッサ（例えば、処理装置112の第1の取得モジュール510）は、要求者のユーザ端末（例えば、モバイルデバイス130－1）から、アイテムに関連するアクションについての要求を受信しうる。いくつかの実施形態では、アイテムは、車両、自転車、ドローン、エアロカー、車椅子、充電器など、またはそれらの任意の組み合わせを含みうる。アイテムは、IoTプラットフォーム（例えば、IoTプラットフォーム110）に接続されたターゲットオブジェクトによって制御または管理され得る。例えば、ターゲットオブジェクトは、アイテムに組み込まれたコントローラ（例えば、車両のTbox）であってもよい。IoTプラットフォームは、要求者にオブジェクトの使用を許可しうる。いくつかの実施形態では、アイテムのターゲットオブジェクト（例えば、コントローラ）は、少なくとも、アイテムを制御するように構成された処理装置を含みうる。車両を例にとると、車両のTboxは、IoTシステム100からの1つまたは複数の命令を実行することによって、車両を制御または管理する（例えば、車両をロックする、車両をロック解除する、またはTboxの動作モードをトリガする）ように構成され得る。いくつかの実施形態では、アイテムに関連するアクションは、アイテムを返却すること、アイテムをロックすること、アイテムをチェックアウトすること、またはアイテムをロック解除することを含むがこれらに限定されない。

単に例示のために、アイテムが共有サービスを提供するために利用可能な車両（例えば、共有車）であるとすると、アイテムのターゲットオブジェクトは車両のTboxであり、車両は車両管理プラットフォーム（すなわち、IoTプラットフォーム）によって管理され得る。例えば、車両管理プラットフォームは、1つまたは複数の動作（例えば、Tboxをスリープモードに保つ、またはTboxを呼び起こす）をさらに実行するために、車両のTboxに1つまたは複数の命令を与える。車両管理プラットフォーム、要求者のユーザ端末、および車両のTboxは、互いに通信しうる。要求者は、ユーザ端末（またはユーザ端末にインストールされたアプリケーション）を介して、IoTプラットフォームに接続されたアイテムに関連するサービスを要求しうる。例えば、要求者は、車両管理プラットフォームに接続されたステーションから車両をチェックアウトするために要求しうる。他の例として、要求者は、車両の使用を終了するときに、車両管理プラットフォームに接続されたステーションに車両を返却するために要求しうる。さらなる例として、要求者は、ステーションから車両をチェックアウトすることを望むときに、車両のロック解除を要求しうる。さらに他の例として、要求者は、車両の返却を終了するときに車両のロックを要求しうる。

ステップ904で、プロセッサ（例えば、処理装置112の第1の処理モジュール520の第1の処理ユニット610）は、要求に応じて、アイテムに関連するアクションを処理するための第1の命令を生成しうる。例えば、第1の処理ユニット610は、要求を解析し、処理されるアクションを決定しうる。第1の処理ユニット610は、ユーザ端末またはアイテムのターゲットオブジェクトにアクションを処理するように促すための第1の命令を生成しうる。

いくつかの実施形態では、要求は、要求者に関するユーザ情報、オブジェクト情報などを含みうる。例えば、ユーザ情報は、年齢、性別、認証ステータス、信用履歴、連絡先情報など、またはこれらの任意の組み合わせを含みうる。認証ステータスは、ユーザがアイテムを使用する資格があるかどうかを示しうる。他の例として、オブジェクト情報は、オブジェクト、現在の動作モード、利用可能性ステータスなど、またはそれらの任意の組み合わせを示す固有の識別子を含みうる。動作モードは、作動モード、スリープモード、または省エネモードなどを含みうる。利用可能性ステータスは、アイテムが共有されることができるかどうかを示しうる。

ステップ906で、プロセッサ（例えば、処理装置112の第1の送信モジュール530）は、生成された第1の命令をオブジェクトおよび／またはユーザ端末に与えうる。例えば、第1の送信モジュール530は、ネットワークを介して、第1の命令をターゲットアイテム140－1、および／またはモバイルデバイス130－1に送信しうる。

ステップ908で、プロセッサ（例えば、処理装置112の第1の取得モジュール510）は、第1の命令に従って、アイテムに関連するアクションが完了すると、アイテムに関するフィードバック情報を受信しうる。いくつかの実施形態では、フィードバック情報は、アイテム、アイテムの場所、アクションの実行時刻など、またはこれらの任意の組み合わせに関する固有の識別子を含みうる。

例えば、要求者が車両の使用を終了したときに、要求者は車両管理プラットフォームに接続されたステーションに車両を返却するために要求すると仮定する。第1の処理ユニット610は、車両（例えば、車両のTbox）に返却動作（例えば、車両のロック、車両のエンジンの停止など）を処理するように促すための第1の命令を生成しうる。第1の命令に従って車両の返却が完了すると、車両のプロセッサ（例えば、プロセッサ420の第2の送信モジュール730）は、フィードバック情報を第1の取得モジュール510に送信しうる。フィードバック情報は、Tboxの固有の識別子、車両の現在の位置、車両を返却する時刻、車両の使用状態（例えば、残留燃料、ダンプエネルギー）など、またはそれらの任意の組み合わせを含みうる。車両管理プラットフォームに接続されたステーションに車両が返却されると、車両がロックされる可能性があることに留意されたく、これにより、許可されていないユーザが車両を使用することを防止しうる。第2の要求者がステーションから車両をチェックアウトしたい場合には、車両はロック解除される必要があり得る。

ステップ910で、プロセッサ（例えば、処理装置112の第1の処理モジュール520の第1のモードトリガユニット620）は、フィードバック情報に基づいて、オブジェクトの動作モードをトリガまたは開始するための第2の命令を生成しうる。例えば、アクションの完了を示すフィードバック情報を受信すると、第1のモードトリガユニット620は、第2の命令を生成し、第2の命令をオブジェクトの第2の取得モジュール710に送信しうる。第2の取得モジュール710はさらに、第2の命令を第2の処理モジュール720に送信しうる。オブジェクトの第2の処理モジュール720は、第2の命令によって示される動作モードをトリガしうる。いくつかの実施形態では、第1の処理モジュール520は、第2の命令に従って、オブジェクトを動作モードに直接変更させうる。

いくつかの実施形態では、動作モードは、作動モード、スリープモード、省エネモードなど、またはこれらの任意の組み合わせを含みうる。作動モードとは、オブジェクトが通常の動作状態にあることを意味し、例えば、Tboxが作動モードにあるときには、車両のTboxのディスプレイは比較的高い電力で照明される。スリープモードとは、オブジェクトが低電力状態にあることを意味し、例えば、Tboxがスリープモードにあるときには、車両のTboxのディスプレイは比較的低い電力で照明される。省エネモデルとは、オブジェクトが省エネ状態にあることを意味し、例えば、Tboxの少なくとも一部が動作する、および／またはTboxの少なくとも一部が低い能力で動作するか、動作を停止する。例えば、省エネモードでは、Tboxは、車両管理プラットフォームとリアルタイムで通信するのではなく、定期的に車両管理プラットフォームと通信しうる。他の例として、省エネモードでは、Tboxは、例えば、車両管理プラットフォームに接続されたディスプレイ装置またはデータ報告装置をオフにするなど、機能の一部をオフにしうる。データ報告装置がオフにされている場合、Tboxは、データを車両管理プラットフォームに報告する代わりに、ローカルストレージ（例えば、記憶装置430）にデータを格納しうる。いくつかの実施形態では、省エネモードは、スリープモードを含みうる。

いくつかの実施形態では、第2の命令が、オブジェクトが省エネモードに変更される必要があることを示す場合には、第2の処理モジュール720は、第2の命令に基づいてオブジェクトの省エネモードをトリガしうる。第2の命令が、オブジェクトが作動モードに変更される必要があることを示す場合には、第2の処理モジュール720は、第2の命令に基づいてオブジェクトの作動モードをトリガしうる。

いくつかの実施形態では、第2の命令は、オブジェクトおよび秘密鍵の動作モードをトリガするための命令を含みうる。秘密鍵が使用されて、現在の動作モードを第2の動作モードに変更しうる。具体的には、秘密鍵は、オブジェクトの第2の取得モジュール710に送信され得る。秘密鍵は、記憶装置（例えば、オブジェクトの記憶装置430）に格納され得る。本明細書で使用される場合、記憶装置430に格納された秘密鍵は、第1の秘密鍵と呼ばれてもよい。いくつかの実施形態では、第2の取得モジュール710が第2の秘密鍵を受信すると、第2の処理モジュール720は、第1の秘密鍵と第2の秘密鍵との間のマッチング動作を実行しうる。第1の秘密鍵が第2の秘密鍵と一致する場合には、第2の処理モジュール720は、オブジェクトを現在の動作モード（例えば、省エネモード）から第2の動作モード（例えば、作動モード）にトリガしうる。第1の秘密鍵が第2の秘密鍵と一致しない場合には、第2の処理モジュール720は、現在の動作モード（例えば、省エネモード）から第2の動作モード（例えば、作動モード）へのオブジェクトのトリガを拒否しうる。第2の秘密鍵は、第1の取得モジュール510が第2のユーザ端末からアイテムをチェックアウトするための要求を受信したときに、第1の処理モジュール520によって生成され得る。第2の取得モジュール710は、第2のユーザ端末から第2の秘密鍵を取得しうる。いくつかの実施形態では、第1の秘密鍵および第2の秘密鍵は、Bluetoothペアリングコード、またはメッセージ検証コードを含みうる。

いくつかの実施形態では、第2の命令は、アイテムをロックする（例えば、車両のパワーエンジンをロックする）ための命令および第3の秘密鍵をさらに含みうる。第3の秘密鍵は、アイテムのロックを解除する（例えば、車両のパワーエンジンのロックを解除する）ために使用されうる。具体的には、第3の秘密鍵は、オブジェクトの第2の取得モジュール710に送信され得る。第3の秘密鍵は、記憶装置（例えば、記憶装置430）に格納され得る。いくつかの実施形態では、アイテムは、アイテムがIoTプラットフォームに接続されたステーションに返却されるときに、第2の命令に従ってロックされ得る。第2の取得モジュール710が第4の秘密鍵を受信すると、第2の処理モジュール720は、第3の秘密鍵と第4の秘密鍵との間のマッチング動作を実行しうる。第3の秘密鍵が第4の秘密鍵と一致する場合には、第2の処理モジュール720は、アイテムのロックを解除しうる。第3の秘密鍵が第4の秘密鍵と一致しない場合には、第2の処理モジュール720は、アイテムのロック解除を拒否しうる。第4の秘密鍵は、第1の取得モジュール510が第2のユーザ端末からアイテムをチェックアウトまたはロック解除する要求を受信したときに、第1の処理モジュール520によって生成され得る。第2の取得モジュール710は、第2のユーザ端末から第4の秘密鍵を取得しうる。いくつかの実施形態では、第3の秘密鍵および第4の秘密鍵は、Bluetoothペアリングコードまたはメッセージ検証コードを含みうる。

図10～図11は、本開示のいくつかの実施形態による、アイテムを管理するための例示的なパイプラインプロセスを示すフローチャートである。図10に示すパイプラインプロセス1000および図11に示すパイプラインプロセスは、ユーザ端末、IoTプラットフォーム、およびアイテムのオブジェクトの間の対話を示す。図9に関連して説明したように、IoTプラットフォームは、要求者のユーザ端末および要求者が望むアイテムのオブジェクトと通信しうる。本明細書で使用される場合、アイテムのオブジェクト（例えば、コントローラ）は、少なくとも、アイテムを制御するように構成された処理装置を含みうる。車両を例にとると、車両のTboxは、IoTシステム100からの1つまたは複数の命令を実行することによって、車両を制御または管理する（例えば、車両をロックする、車両をロック解除する、またはTboxの動作モードをトリガする）ように構成され得る。

ステップ1002で、第1のユーザ端末は、アイテムに関連するアクションについての第1の要求を送信しうる。第1の要求は、IoTプラットフォーム（例えば、第1の取得モジュール510）に送信され得る。例えば、第1のユーザ端末は、IoTプラットフォームに接続されたステーションにアイテムを返却するための第1の要求を送信する。アイテム自体もIoTプラットフォームに接続でき、IoTプラットフォームに接続されたステーションを経由せずにIoTプラットフォームと直接通信しうる。

ステップ1004で、IoTプラットフォーム（例えば、第1の処理モジュール520）は、第1のユーザ端末からの第1の要求に応じてアクションを処理するための第1の命令を生成しうる。IoTプラットフォーム（例えば、第1の送信モジュール530）は、第1の命令をアイテムのオブジェクト（例えば、第2の取得モジュール710）にさらに送信しうる。

ステップ1006で、オブジェクト（例えば、第2の処理モジュール720）は、第1の命令に従って、第1の要求によって示されたアクションを完了しうる。例えば、第2の処理モジュール720は、アイテムの返却を完了する（例えば、アイテムのエンジンをロックする）ようにオブジェクトに命令しうる。

ステップ1008で、アクションが完了すると、オブジェクト（例えば、第2の送信モジュール730）は、アイテムに関するフィードバック情報をIoTプラットフォームに送信しうる。フィードバック情報は、アイテム、アイテムの場所、アクションの実行時刻など、またはこれらの任意の組み合わせに関する固有の識別子を含みうる。

ステップ1010で、フィードバック情報を受信すると、IoTプラットフォーム（例えば、第1の処理モジュール520）は、オブジェクトの動作モードをトリガするための第2の命令を生成し、第2の命令をオブジェクトに送信しうる。いくつかの実施形態では、第2の命令が使用されて、オブジェクト（例えば、車両のTbox）の省エネモードをトリガしうる。いくつかの実施形態では、第2の命令は、少なくとも1つの第1の秘密鍵を含みうる。少なくとも1つの第1の秘密鍵は、Bluetoothペアリングコードまたはメッセージ検証コードを含みうる。

ステップ1012で、第2の命令に応じて、オブジェクト（例えば、第2の処理モジュール720）は、第2の命令を実行し、少なくとも1つの秘密鍵を記憶装置（例えば、記憶装置430）に格納しうる。例えば、第2の処理モジュール720は、第2の命令によって示される動作モード（例えば、省エネモード）に変更するようにオブジェクトに命令しうる。本明細書で使用される場合、第2の命令によって示される動作モードは、第1の動作モードと呼ばれる。

ステップ1014で、第2のユーザ端末は、アイテムに関連する第2のアクションについての第2の要求をIoTプラットフォームに送信しうる。第2の要求は、IoTプラットフォーム（例えば、第1の取得モジュール510）に送信され得る。例えば、第2のユーザ端末は、IoTプラットフォームに関連するステーションからオブジェクトをチェックアウトするための第2の要求を送信する。

ステップ1016で、IoTプラットフォーム（例えば、第1の処理モジュール520）は、第3の命令を生成し、第3の命令を第2のユーザ端末に送信しうる。第3の命令は、オブジェクトを第1の動作モードから第2の動作モードに変更するための命令を含みうる。第3の命令は、第2の秘密鍵を含みうる。いくつかの実施形態では、第1の動作モードは省エネモードであり、第2の動作モードは作動モードである。

ステップ1018で、第2のユーザ端末は、生成された第2の秘密鍵をオブジェクトに直接送信しうる。

ステップ1020で、オブジェクト（例えば、第2の取得モジュール710）は、第2の秘密鍵を受信し、第1の秘密鍵と第2の秘密鍵との間のマッチング動作を実行しうる。例えば、第1の秘密鍵が第1のBluetoothペアリングコードを含み、第2の秘密鍵が第2のBluetoothペアリングコードを含むと仮定すると、第2の処理モジュール720は、第1のBluetoothペアリングコードおよび第2のBluetoothペアリングコードが良好に一致されるかどうかを決定しうる。いくつかの実施形態では、第1のBluetoothペアリングコードが第2のBluetoothペアリングコードと同じであり得る場合には、これは、第1のBluetoothペアリングコードが第2のBluetoothペアリングコードと一致することを意味する。

いくつかの実施形態では、第1の秘密鍵が第2の秘密鍵と一致する場合には、オブジェクトの動作モードが第2の動作モードに変更されることができる。例えば、第2の処理モジュール720は、オブジェクトを省エネモードから作動モードにトリガしうる。

いくつかの実施形態では、第1の秘密鍵が第2の秘密鍵と一致しない場合には、オブジェクトは現在の動作モードの変更を拒否することができ、オブジェクトの動作モードが変更されないままにしうる（例えば、オブジェクトは第1の動作モード（例えば省エネモード）を維持する）。オブジェクト（例えば、第2の送信モジュール730）は、一致しないことを示す情報をIoTプラットフォームに送信しうる。

いくつかの実施形態では、図11のステップ1118およびステップ1120に示すように、IoTプラットフォーム（例えば、第1の取得モジュール510）は、第2のユーザ端末およびオブジェクトから第2の秘密鍵および第1の秘密鍵をそれぞれ受信しうる。IoTプラットフォーム（例えば、第1の処理モジュール520）は、第1の秘密鍵と第2の秘密鍵との間のマッチング動作を実行しうる。第1の秘密鍵が第2の秘密鍵と一致する場合には、第1の処理モジュール520はまた、省エネモードを作動モードに変更するようにオブジェクトに命令しうる。

いくつかの実施形態では、第2の命令は、アイテムをロックする（例えば、車両のエンジンをロックする）ための命令も含みうる。例えば、アイテムがIoTプラットフォームに接続されたステーションに返却されるときに、アイテムがロックされる必要があり得る。オブジェクトは、第2の命令に従ってロック動作を実行しうる。例えば、Tboxは、第2の命令に応じて車両のエンジンをロックしうる。いくつかの実施形態では、第2の命令は、第3の秘密鍵を含みうる。第3の秘密鍵は、オブジェクトのロックを解除するために使用され得る。第3の秘密鍵は、記憶装置（例えば、記憶装置430）に格納され得る。

IoTプラットフォームが第2のユーザ端末からアイテムをチェックアウトするための第2の要求を受信すると、IoTプラットフォームは第3の命令を第2のユーザ端末に送信しうる。第3の命令は、アイテムのロックを解除するための命令をさらに含みうる。いくつかの実施形態では、第3の命令は第4の秘密鍵を含みうる。アイテムは、第3の秘密鍵と第4の秘密鍵との関係に基づいてロックを解除しうる。第2のユーザ端末は、第4の秘密鍵をオブジェクトに送信しうる。いくつかの実施形態では、オブジェクトは、第3の秘密鍵と第4の秘密鍵との間のマッチング動作を実行しうる。例えば、第3の秘密鍵が第3のBluetoothペアリングコードを含み、第4の秘密鍵が第4のBluetoothペアリングコードを含むと仮定すると、オブジェクトの第2の処理モジュール720は、第3のBluetoothペアリングコードおよび第4のBluetoothペアリングコードが良好に一致されるかどうかを決定しうる。いくつかの実施形態では、第3のBluetoothペアリングコードが第4のBluetoothペアリングコードと同じであり得る場合には、これは、第3のBluetoothペアリングコードが第4のBluetoothペアリングコードと一致することを意味する。いくつかの実施形態では、第3のBluetoothペアリングコードが第4のBluetoothペアリングコードと一致する場合には、アイテムはロック解除され得る。アイテムのロックを解除した後に、第2のユーザはアイテムを自由に利用しうる。

本開示の理解を容易にするために、様々な例が提供され得る。例えば、IoTプラットフォーム100は、車両の共有使用を提供するように構成された車両管理システムとして提供されてもよい。共有車両は、車両管理システムを介して管理および制御され得る。具体的には、車両管理システムは、車両のテレマティクスプロセッサ（「テレマティクスボックス」とも呼ばれ、略して「Tbox」と呼ばれる）を制御して、車両の制御を達成しうる。

以下の例は、例示を目的として提供されており、限定するものではない。

例1
図12は、本開示のいくつかの実施形態による、車両のTboxを制御するための例示的なプロセスを示す。本開示の実施形態は、Tboxが車両管理プラットフォームとの接続を維持する必要があるので、Tboxの大きな電力消費によって引き起こされる問題または他の問題を解決するためのTbox制御プロセス／方法1200を提供する。いくつかの実施形態では、プロセス1200は、命令の形で記憶装置113および／またはストレージ（例えば、ROM230、RAM240、またはストレージ390）に格納され、サーバ111（例えば、サーバ111の処理装置112、またはコンピューティングデバイス200のプロセッサ220）によって呼び出され、および／または実行されてもよい。

ステップ1202で、プロセッサ（例えば、処理装置112の第1の取得モジュール510）は、要求者のユーザ端末から車両を返却するアクションについての要求を受信しうる。要求は、車両のTboxの識別子を含みうる。

要求者が車両の使用を終了した場合には、要求者は、自分のユーザ端末（例えば、ユーザ端末にインストールされたアプリケーション）を介して、車両を車両管理プラットフォームに返却するための要求を送信する。要求は、車両のTboxに対応する識別子を含む。識別子は、車両のTboxに対応する固有の識別子であり得る。識別子は、車両のTboxを識別するために使用され得る。具体的には、固有の識別子は、文字列、文字、画像、数字などの様々な形式であってもよい。

ステップ1204で、プロセッサ（例えば、処理装置112の第1の処理モジュール520の第1の処理ユニット610）は、要求に応じて車両を返却するアクションを処理するための第1の命令を生成しうる。

ステップ1206で、プロセッサ（例えば、処理装置112の第1の送信モジュール530）は、第1の命令を車両のTbox（例えば、第2の取得モジュール710）に与える／送信しうる。第1の命令は、車両の返却を処理するようにTboxに命令し、車両の返却に関する情報をフィードバックするために使用され得る。

例えば、車両管理プラットフォームは、要求に含まれる識別子に従って、対応する車両のTboxに第1の命令を送信する。

ステップ1208で、プロセッサ（例えば、処理装置112の第1の取得モジュール510）は、第1の命令に従って、アクションが完了すると車両に関するフィードバック情報を受信しうる。

例えば、ユーザ端末から車両を返却するための要求を受信した後に、車両管理プラットフォームは、識別子に対応するTboxに第1の命令を送信する。Tboxは、第1の命令を受けた後に、車両を返却するための予め設定された手順（例えば、車両をロックすること）を実行し、車両の返却に関するフィードバック情報を取得し、その後フィードバック情報を車両管理プラットフォームに送信する。

いくつかの実施形態では、フィードバック情報は、車両のTboxの固有の識別子、車両の現在の位置、車両を返却する時刻、車両の使用状態（例えば、残留燃料、ダンプエネルギー）など、またはこれらの任意の組み合わせを含みうる。

ステップ1210で、プロセッサ（例えば、処理装置112の第1の処理モジュール520の第1のモードトリガユニット620）は、フィードバック情報に基づいて、作動モードからスリープモードへのTboxのモード変更をトリガするための第2の命令を生成しうる。

例えば、フィードバック情報を受信した後に、車両管理プラットフォームは、スリープモードをトリガするための第2の命令を車両のTboxに送信する。Tboxは、第2の命令に応じて、作動モードからスリープモードに変更され得る。スリープモードの間、Tboxの少なくとも1つの通信機能構成要素（例えば、第2の送信モジュール730）は作動し続けるので、少なくとも1つの通信機能構成要素によって受信された作動モードをトリガするための命令に応じてTboxが呼び起こされ得る。他の機能構成要素が閉じられてスリープモードに入ることができ、例えば、車両のパワーエンジンをオフにする、Tboxのディスプレイ装置をオフにする、音声コマンドシステムをオフにする、GPSをオフにする、車両管理プラットフォームとのリアルタイムデータ交換を停止するなどである。

さらにまたは代わりに、Tboxからフィードバック情報を受信した後に、車両管理プラットフォームは、フィードバック情報を記憶装置（例えば、記憶装置113）に格納し、車両を返却するプロセスを終了しうる。

図12に関連して説明したように、車両管理プラットフォームは、第1のユーザ端末から車両を返却するための第1の要求を受信しうる。車両管理プラットフォームは、第1の命令を生成し、第1の要求に含まれる識別子に対応するTboxに送信しうる。第1の命令は、車両の返却を処理するために使用され得る。受信した第1の命令に応じて、Tboxは、車両の返却を実行し、車両の返却に関するフィードバック情報を送信しうる。フィードバック情報を受信すると、車両管理プラットフォームは、作動モードからスリープモードにTboxをトリガするための第2の命令を生成しうる。第2の命令に応じて、Tboxは作動モードからスリープモードに変更され得る。車両の返却が終了すると、Tboxはスリープモードに入りうる。スリープモード中、車両はTboxを呼び起こすために通信機能を開くだけで、他の機能は閉じられることができ、これにより、Tboxの消費電力を削減し、Tboxの寿命を延ばしうる。

例2
図12に示すプロセス1200の前述の説明に基づいて、特定の実施形態では、車両管理プラットフォームから車両をチェックアウトするための第2の要求を受信した後に、車両管理プラットフォームは、Tboxを呼び起こしうる、すなわち、Tboxはスリープモードから作動モードに変更され得る。異なるシナリオでは、車両管理プラットフォームが様々な方法でTboxを呼び起こすので、Tboxが作動モードに切り替えられ得ることに留意されたい。

いくつかの実施形態では、第2のユーザが車両管理プラットフォームから車両をチェックアウトすることを望む場合、または車両ディスパッチャが車両を動かすことを望む場合には、第2のユーザまたは車両ディスパッチャは、彼／彼女のユーザ端末（またはユーザ端末にインストールされているアプリケーション）によって車両のTboxを呼び起こしうる。

いくつかの実施形態では、ユーザ端末は、車両管理プラットフォームに関連してクライアントアプリケーションをインストールするモバイルデバイス、例えば、ユーザの携帯電話であってもよい。ユーザは、クライアントアプリケーションを介して車両をチェックアウト／返却しうる。いくつかの実施形態では、ユーザ端末は、車両管理プラットフォームに関連してサーバアプリケーションをインストールするモバイルデバイスであってもよい。車両ディスパッチャは、サーバアプリケーションを介して車両をローンチすることまたは管理しうる。

いくつかの実施形態では、Tboxがスリープモードに入る前に、車両管理プラットフォームは、Tboxをスリープモードから作動モードにトリガするための第1の秘密鍵（例えば、第1のBluetoothペアリングコード）をTboxに送信しうる。Tboxがスリープモードに入る間に、車両管理プラットフォームが車両をチェックアウトするための要求を受信した場合には、車両管理プラットフォームは、第2の秘密鍵（例えば、第2のBluetoothペアリングコード）をユーザ端末に送信しうる。要求者は、第1の秘密鍵および第2の秘密鍵とのペアリングを要求しうる。Tboxは、第2の秘密鍵が第1の秘密鍵と一致するかどうかを判定しうる。第2の秘密鍵が第1の秘密鍵と一致する場合には、Tboxはスリープモードから作動モードに変更され得る、すなわち、Tboxが呼び起こされる。第2の秘密鍵が第1の秘密鍵と一致しない場合には、Tboxは作動モードに変更されず、スリープモードのままであり得る。

いくつかの実施形態では、車両の返却に関するフィードバック情報を受信した後に、車両管理プラットフォームは、第1の秘密鍵を生成して、第1の秘密鍵をTboxに送信することができ、次いで、Tboxは、第1の秘密鍵を記憶装置（例えば、記憶装置430）に格納しうる。第1の秘密鍵は、第2の命令に含まれてもよい。

いくつかの実施形態では、車両管理プラットフォームは、予め設定された規則に従って、Tboxに対応する秘密鍵、例えば、第1の秘密鍵および第2の秘密鍵を生成しうる。いくつかの実施形態では、技術者は、車両管理プラットフォームを介して、予め設定された規則に従って、第1の秘密鍵および第2の秘密鍵を予め設定しうる。例えば、第1の秘密鍵は第1のBluetoothペアリングコードを含むことができ、第1のBluetoothペアリングコードは6桁を含む。第2の秘密鍵はまた、第2のBluetoothペアリングコードを含むことができ、第2の秘密鍵は第1の秘密鍵と同じであってもよい。車両管理プラットフォームは、様々な方法で秘密鍵を生成するものであり、限定することを意図したものではないことに留意されたい。

いくつかの実施形態では、車両の返却に関するフィードバック情報を受信した後で、第2の命令をTboxに送信する前に、車両管理プラットフォームは、第1の秘密鍵をTboxに送信しうるので、Tboxがスリープモードに入る前に、Tboxが第1の秘密鍵を受信して格納しうる。

いくつかの実施形態では、車両の返却に関するフィードバック情報を受信した後に、第1の秘密鍵が第2の命令で搬送され得て、車両管理プラットフォームは、第1の秘密鍵を含む第2の命令をTboxに送信しうる。Tboxは第1の秘密鍵を記憶装置に格納しうる。同時に、第2の命令に従ってTboxは作動モードからスリープモードに変更されることができる。

いくつかの実施形態では、Tboxがスリープモードに入る間、Bluetooth通信を容易にするように構成された構成要素が常に開かれているようにしうる。車両管理プラットフォームは、Bluetooth通信を介してTboxを呼び起こしうる。例えば、車両管理プラットフォームは、ユーザ端末から車両をチェックアウトするための要求を受信し、その要求は車両のTboxに対応する識別子を含む。車両管理プラットフォームは、識別子に従って車両のTboxに対応する第2の秘密鍵を提供しうる。第2の秘密鍵は第1の秘密鍵に対応する。車両管理プラットフォームは、第2の秘密鍵をユーザ端末に送信しうる。ユーザ端末は、第2の秘密鍵を使用してTboxを呼び起こすことができ、Tboxはスリープモードから作動モードに変更される。

いくつかの実施形態では、Tboxを呼び起こした後に、車両管理プラットフォームは、Tboxにそれぞれ対応する新しい第1の秘密鍵および新しい第2の秘密鍵を生成し、新しい第1の秘密鍵および新しい第2の秘密鍵を格納しうる。車両管理プラットフォームは、新しい第1の秘密鍵をTboxに送信して、Tboxに格納されている第1の秘密鍵を更新することができ、これにより、ユーザが古い秘密鍵を使用してTboxを再度呼び起こして、車両を不正に使用するのを防ぎうる。したがって、車両のセキュリティが改善され得る。

図13は、本開示のいくつかの実施形態による、車両のTboxを制御するための例示的なパイプラインプロセスを示すフローチャートである。図13のパイプラインプロセス1300に示すように、ユーザ端末、車両管理プラットフォーム、および車両のTboxは、以下のように互いに通信され得る。

ステップ1302で、車両管理プラットフォームは、車両を返却する第1のアクションについての第1の要求を受信しうる。例えば、第1のユーザ端末が第1の要求を車両管理プラットフォームに送信し、車両管理プラットフォームが第1の要求を受信する。

ステップ1304で、車両管理プラットフォームは、アクションを処理するための第1の命令を生成し、車両のTboxに送信しうる。本明細書で使用されるように、第1の命令は、車両を車両管理プラットフォームに接続されたステーションに返却するようにTboxに命令するために使用され得る。車両管理プラットフォームは、第1の要求に含まれるTboxの識別子に従って車両のTboxを識別し、第1の命令を対応するTboxに送信しうる。

ステップ1306で、Tboxは第1のアクションを完了しうる。例えば、第1の命令は、車両のTboxに、料金の清算または車両のロックなど、車両の返却を実行するように促す。

ステップ1308で、Tboxは、車両の返却に関するフィードバック情報を車両管理プラットフォームに送信しうる。

ステップ1310で、車両管理プラットフォームは、第1のBluetoothペアリングコードを含む第2の命令を生成し、車両のTboxに送信しうる。

ステップ1312で、Tboxは第2の命令を実行し、例えば、動作モードをスリープモードに変更し、第1のBluetoothペアリングコードを格納しうる。

ステップ1314で、車両管理プラットフォームは、車両をチェックアウトする第2のアクションについての第2の要求を受信しうる。例えば、第2のユーザ端末が第2の要求を車両管理プラットフォームに送信し、車両管理プラットフォームが第2の要求を受信する。

ステップ1316で、第2の要求に応じて、車両管理プラットフォームは、第2のBluetoothペアリングコードを含む第3の命令を生成し、第2のユーザ端末に送信しうる。

ステップ1318で、第2のユーザ端末は、第2のBluetoothペアリングコードをTboxに送信し、第2のBluetoothペアリングコードおよび第1のBluetoothペアリングコードとのBluetoothペアリングを要求しうる。

ステップ1320では、Bluetoothペアリングに応じて、Tboxは第2のBluetoothペアリングコードと第1のBluetoothペアリングコードとの間のマッチング動作を実行しうる。第2のBluetoothペアリングコードが第1のBluetoothペアリングコードと一致する場合には、Tboxはスリープモードから作動モードに変更され得る。

図13に示すように、点線の上の動作1302～1312は、Tboxを作動モードからスリープモードに制御する第1のプロセスを示し、点線の下の動作1314～1320は、Tboxをスリープモードから作動モードに呼び起こす第2のプロセスを示すことに留意されたい。

車両管理プラットフォームが車両に関するリアルタイムデータを取得するために車両のTboxを呼び起こしたい場合、または車両ディスパッチャが車両管理プラットフォームを介して車両を遠隔制御したい場合には、これらの場合、車両管理プラットフォームはTboxを直接呼び起こしうる。具体的には、Tboxがスリープモードに入る間、メッセージ通信を容易にするように構成された構成要素が常に開かれているようにしうる。車両プラットフォームは、メッセージ通信によってTboxを呼び起こしうる。

例えば、車両管理プラットフォームは、車両ディスパッチャから車両を制御するための命令を受信し、その命令は車両のTboxの識別子を含む。車両管理プラットフォームは、メッセージ検証コードを識別子に対応するTboxに送信しうる。メッセージ検証コードを受信すると、Tboxはメッセージ検証コードを検証しうる。メッセージ検証コードが正常に検証された場合には、Tboxがスリープモードから作動モードに変更され得る。いくつかの実施形態では、メッセージ検証コードは、文字列、文字、画像、数字などの、様々な形態で存在し得る。

例3
図14は、本開示のいくつかの実施形態による、車両のTboxを制御するための例示的なプロセスを示すフローチャートである。この例は、Tboxが車両管理プラットフォームとの接続を維持する必要があるので、Tboxの大きな電力消費によって引き起こされる問題または他の問題を解決するためのTbox制御プロセス／方法1400を提供する。プロセス1400は、アイテムのターゲットオブジェクト（例えば、車両のTbox）に実装され得る。いくつかの実施形態では、プロセス1400は、命令の形態で記憶装置430に格納されて、プロセッサ420によって呼び出され、および／または実行されてもよい。

ステップ1402で、プロセッサ（例えば、プロセッサ420の第2の取得モジュール710）は、車両管理プラットフォームから車両を返却するアクションを処理するための第1の命令を受信しうる。

図12～図13に関連して説明したように、第1の要求者が車両の使用を終了すると、第1の要求者は、車両を車両管理プラットフォームに接続されたステーションに返却するための第1の要求を送信する。第1の要求は、車両のTboxに対応する識別子を含む。識別子は、車両のTboxに対応する固有の識別子であってもよく、車両のTboxを識別するために使用される。固有の識別子は、文字列、文字、画像、数字など、様々な形式で存在してもよい。第1の要求に応じて、車両管理プラットフォームは、識別子に対応するTboxに第1の命令を与えうる。本明細書で使用されるように、第1の命令は、車両の返却を実行するようにTboxに命令するために使用され得る。

ステップ1404で、プロセッサ（例えば、プロセッサ420の第2の処理モジュール720の第2の処理ユニット810）は、第1の命令に応じて車両を返却するアクションを実行しうる。第2の処理ユニット810は、車両の返却に関するフィードバック情報をさらに生成しうる。

ステップ1406で、車両の返却に関連するアクションが完了すると、プロセッサ（例えば、プロセッサ420の第2の送信モジュール730）は、車両に関するフィードバック情報を車両管理プラットフォームに送信しうる。

具体的には、第1の命令は、Tboxに車両の返却（例えば、料金の清算、車両のロック）を実行するように促し、車両の返却に関するフィードバック情報を生成し、次にフィードバック情報を車両管理プラットフォームに送信しうる。

いくつかの実施形態では、フィードバック情報は、車両のTboxの固有の識別子、車両の現在の位置、車両を返却する時刻、車両の使用状態（例えば、残留燃料、ダンプエネルギー）など、またはこれらの任意の組み合わせを含みうる。

ステップ1408で、プロセッサ（例えば、Tboxのプロセッサ420の第2の取得モジュール710）は、車両管理プラットフォームから、作動モードからスリープモードへのTboxのモード変更をトリガするための第2の命令を受信しうる。例えば、車両管理プラットフォームは、フィードバック情報を受信した後に、第2の命令を生成し、Tboxに送信しうる。本明細書で使用されるように、第2の命令は、スリープモードをトリガするために使用され得る。

ステップ1410で、プロセッサ（例えば、Tboxのプロセッサ420の第2の処理モジュール720の第2のモードトリガユニット820）は、第2の命令に基づいて、作動モードからスリープモードにTboxをトリガしうる。

スリープモードの間、Tboxの少なくとも1つの通信構成要素（例えば、第2の送信モジュール730）は作動し続けうるので、少なくとも1つの通信機能構成要素によって受信された作動モードをトリガするための命令に応じてTboxが呼び起こされ得る。他の機能構成要素が閉じられてスリープモードに入ることができ、例えば、車両のパワーエンジンをオフにする、Tboxのディスプレイ装置をオフにする、音声コマンドシステムをオフにする、GPSをオフにする、車両管理プラットフォームとのデータ交換を停止するなどである。

図14に関連して説明したように、車両管理プラットフォームは、第1のユーザ端末から車両を返却するための第1の要求を受信しうる。車両管理プラットフォームは、第1の命令を生成し、第1の要求に含まれる識別子に対応するTboxに送信しうる。第1の命令は、車両の返却を処理するために使用され得る。受信した第1の命令に応じて、Tboxは、車両の返却を実行し、車両の返却に関するフィードバック情報を送信しうる。フィードバック情報を受信すると、車両管理プラットフォームは、作動モードからスリープモードにTboxをトリガするための第2の命令を生成しうる。第2の命令に応じて、Tboxは作動モードからスリープモードに変更され得る。車両の返却が終了すると、Tboxはスリープモードに入りうる。スリープモード中、車両はTboxを呼び起こすために通信機能を開くだけで、他の機能は閉じられえ、これにより、Tboxの消費電力を削減し、Tboxの寿命を延ばしうる。

例4
図14に示すプロセス1400の前述の説明に基づいて、Tboxがスリープモードに入った後に、異なるシナリオでは、Tboxが様々な方法で呼び起こされ得、Tboxが作動モードに切り替えられる。

いくつかの実施形態では、第2のユーザが車両管理プラットフォームから車両をチェックアウトすることを望む場合、または車両ディスパッチャが車両を動かすことを望む場合には、第2のユーザまたは車両ディスパッチャは、彼／彼女のユーザ端末（またはユーザ端末にインストールされているアプリケーション）によって車両のTboxを呼び起こしうる。

いくつかの実施形態では、ユーザ端末は、車両管理プラットフォームに関連してクライアントアプリケーションをインストールするモバイルデバイス、例えば、ユーザの携帯電話であってもよい。ユーザは、クライアントアプリケーションを介して車両をチェックアウト／返却しうる。いくつかの実施形態では、ユーザ端末は、車両管理プラットフォームに関連してサーバアプリケーションをインストールするモバイルデバイスであってもよい。車両ディスパッチャは、サーバアプリケーションを介して車両をローンチすることまたは管理しうる。

いくつかの実施形態では、車両の返却に関するフィードバック情報を受信した後で、Tboxがスリープモードに入る前に、Tboxは、作動モードをトリガするための第1の秘密鍵（例えば、第1のBluetoothペアリングコード）を受信し、第1の秘密鍵を格納しうる。第2のユーザが車両管理プラットフォームから車両をチェックアウトすることを望む場合、第2のユーザは、第2のユーザ端末を介して車両管理プラットフォームから車両をチェックアウトするための第2の要求を送信しうる。要求は、車両のTboxに対応する識別子を含む。車両管理プラットフォームは、Tboxに対応する第2の秘密鍵（例えば、第2のBluetoothペアリングコード）を提供し、第2の秘密鍵を第2のユーザ端末に送信しうる。

第2の秘密鍵（例えば、第2のBluetoothペアリングコード）を受信した後に、第2のユーザ端末は、Tboxを呼び起こすための命令を送信し、その命令は第2の秘密鍵を含む。具体的には、第2のユーザ端末は、第2の秘密鍵をTboxに送信し、第2の秘密鍵と第1の秘密鍵との間のペアリングを要求する。次に、Tboxは第2の秘密鍵と第1の秘密鍵との間のマッチング動作を実行しうる。第2の秘密鍵が第1の秘密鍵と一致する場合には、Tboxはスリープモードから作動モードに変更され得る、すなわち、Tboxが呼び起こされる。第2の秘密鍵が第1の秘密鍵と一致しない場合には、Tboxは作動モードに変更されず、スリープモードのままであり得る。

いくつかの実施形態では、車両管理プラットフォームが車両に関するリアルタイムデータを取得するために車両のTboxを呼び起こしたい場合、または車両ディスパッチャが車両管理プラットフォームを介して車両を遠隔制御したい場合には、これらの場合、車両管理プラットフォームはTboxを直接呼び起こしうる。具体的には、Tboxがスリープモードに入る間、メッセージ通信を容易にするように構成された構成要素が常にオンであるようにしうる。車両プラットフォームは、メッセージ通信によってTboxを呼び起こしうる。

例えば、車両管理プラットフォームは、車両ディスパッチャから車両を制御するための命令を受信し、その命令は車両のTboxの識別子を含む。車両管理プラットフォームは、メッセージ検証コードを識別子に対応するTboxに送信しうる。メッセージ検証コードを受信すると、Tboxはメッセージ検証コードを検証しうる。メッセージ検証コードが正常に検証された場合には、Tboxがスリープモードから作動モードに変更され得る。メッセージ検証コードの検証に失敗した場合には、Tboxはスリープモードのままにしうる。いくつかの実施形態では、メッセージ検証コードは、文字列、文字、画像、数字などの、様々な形態で存在し得る。

いくつかの実施形態では、Tboxがスリープモードに入る間、車両が他のもの（例えば、他の車、壁）と衝突した場合には、Tboxは、スリープモードから作動モードに自動的に変更され得る。具体的には、Tboxは車両の振動状態を検出しうる。Tboxは、車両の振動状態に基づいて、スリープモードから作動モードに変更され得る。例えば、車両の振動状態は、1つまたは複数のレベル、例えば、わずかな振動を示す低レベル、激しい振動を示す高レベルに分類され得る。Tboxに接続された振動センサによって高レベルが検出されると、Tboxはスリープモードから作動モードに変更され得る。いくつかの実施形態では、Tboxは、検出された振動状態を車両管理プラットフォームに報告しうる。

いくつかの実施形態では、車両のTboxがスリープモードに入る間、車両の振動センサとのデータ交換を容易にするように構成された構成要素がオンにされ得る。振動センサが車両の振動を検出すると、振動センサは振動に関するデータをTboxに送信しうる。振動に関するデータを受信すると、Tboxはスリープモードから作動モードに変更され得る。同時に、Tboxは振動に関するデータを車両管理プラットフォームに送信または報告しうる。

例5
車両管理プラットフォームはTboxと通信し、Tboxから車両に関する様々なデータ（例えば、車両のドアが閉じているかどうか、ドアロックがロックされているかどうか、パワーロックがロックされているかどうかなどを含む、車両の現在の状態データ）を取得し、様々な動作（パワーロックのロック解除、車両ドアの閉鎖、車両窓の閉鎖など）を実行するように車両を制御する。車両管理プラットフォームはまた、ユーザ端末からの様々なサービス要求（例えば、車両の予約、車両のロック解除、車両ドアの開放など）に応じて、ユーザ端末と通信する。車両管理プラットフォームは、1つもしくは複数のTboxまたは1つもしくは複数のユーザ端末と通信する。

図15は、本開示のいくつかの実施形態による、車両をロック解除するための例示的なプロセスを示すフローチャートである。図15に示すプロセス1500は、IoTシステム100（例えば、車両管理プラットフォーム）上に実装され得る。いくつかの実施形態では、プロセス1500は、命令の形で記憶装置113および／またはストレージ（例えば、ROM230、RAM240、またはストレージ390）に格納され、サーバ111（例えば、サーバ111の処理装置112、またはコンピューティングデバイス200のプロセッサ220）によって呼び出され、および／または実行されてもよい。

ステップ1502で、プロセッサ（例えば、処理装置112の第1の取得モジュール510）は、ユーザ端末から車両を返却するアクションについての要求を受信することができ、その要求は車両のTboxの識別子を含む。

ステップ1504で、プロセッサ（例えば、処理装置112の第1の処理モジュール520）は、要求の受信時に少なくとも1つの秘密鍵を生成しうる。いくつかの実施形態では、少なくとも1つの秘密鍵は、Bluetoothペアリングコードを含みうる。いくつかの実施形態では、少なくとも1つの秘密鍵は、車両をロック解除するために使用される第1の秘密鍵および／または第2の秘密鍵を含みうる。

第1のユーザが車両の使用を終了し、車両を返却したい場合、第1のユーザは、第1のユーザ端末を使用して、車両を返却するための要求を車両管理プラットフォームに送信しうる。車両を返却する要求を受信すると、車両管理プラットフォームは、車両に対応する少なくとも1つの秘密鍵を生成しうる。車両管理プラットフォームは、様々な方法で秘密鍵を生成しうる。上記の例は、限定することを意図したものではない。

いくつかの実施形態では、車両管理プラットフォームは、少なくとも1つの秘密鍵と車両のTboxの識別子との間の対応関係を格納しうる。第1のユーザが車両のロック解除に失敗した場合には、車両管理プラットフォームは、格納された関係に基づいて新しい秘密鍵を再設定しうる。

ステップ1506で、プロセッサ（例えば、処理装置112の第1の送信モジュール530）は、Tboxに少なくとも1つの秘密鍵を含む命令を与えうる。本明細書で使用される場合、この命令は、秘密鍵再設定命令と呼ばれる。秘密鍵再設定命令が使用されて、提供された秘密鍵をターゲット秘密鍵として再設定するようにTboxに命令しうる。例えば、秘密鍵再設定命令は、車両をロック解除するために使用されるターゲット秘密鍵として第1の秘密鍵を再設定するようにTboxに促す。

車両管理プラットフォームが車両に対応する秘密鍵を生成する場合、車両管理プラットフォームは、生成された秘密鍵を含む秘密鍵再設定命令を車両のTboxに送信しうる。次に、Tboxが秘密鍵再設定命令を実行して秘密鍵を再設定する。

いくつかの実施形態では、Tboxの識別子とTboxとの間の対応関係は、車両管理プラットフォームの記憶装置（例えば、記憶装置113）に格納され得る。車両管理プラットフォームが少なくとも1つの秘密鍵を生成した後に、車両管理プラットフォームは、要求に含まれる識別子に対応するTboxを検索しうる。車両管理プラットフォームは、ネットワークを介してTboxと通信しうる。車両管理プラットフォームは、秘密鍵再設定命令をTboxに送信しうる。秘密鍵再設定命令を受信した後に、Tboxは、古い秘密鍵を置き換えるために、受信した秘密鍵を新しい秘密鍵（すなわち、ターゲット秘密鍵）として再設定することができ、これにより、秘密鍵の動的更新を達成しうる。車両が再度使用される場合、ユーザは新しい秘密鍵を使用して車両をロック解除する必要があり、これにより、不正使用を防ぐための車両の安全性が向上しうる。

いくつかの実施形態では、少なくとも1つの秘密鍵は、第1のBluetoothペアリングコードを含みうる。第2のユーザが車両管理プラットフォームから車両をチェックアウトすることを望む場合、車両管理プラットフォームは、第1のBluetoothペアリングコードを第2のユーザの第2のユーザ端末に送信しうる。第2のユーザは、第1のBluetoothペアリングコードとTboxに格納されたBluetoothペアリングコードとの間のBluetoothペアリングを要求しうる。ペアリングが成功すると、車両のロックが解除される。

いくつかの実施形態では、少なくとも1つの秘密鍵は、第2のBluetoothペアリングコードを含みうる。第2のユーザが車両管理プラットフォームから車両をチェックアウトすることを望む場合、車両管理プラットフォームは、第2のBluetoothペアリングコードを第2のユーザの第2のユーザ端末に送信しうる。第2のユーザは、第2のBluetoothペアリングコードと車両のTboxに格納されているBluetoothペアリングコードとの間のBluetoothペアリングを要求しうる。ペアリングが成功すると、車両のロックが解除される。

図15に関連して説明したように、車両の返却を終了すると、車両管理プラットフォームは、車両のTboxに対応する少なくとも1つの秘密鍵を生成しうる。車両管理プラットフォームは、秘密鍵再設定命令をTboxに与えうる。秘密鍵再設定命令は、生成された少なくとも1つの秘密鍵を含む。Tboxは、生成された少なくとも1つの秘密鍵をTboxのターゲット秘密鍵として再設定しうる。第2のユーザが車両管理プラットフォームから車両をチェックアウトしたい場合、第2のユーザは車両をロック解除するためにTboxのターゲット秘密鍵を要求する必要がある。Tboxのターゲット秘密鍵は、図15に記載されているように動的に更新され得、これにより車両の安全性を改善しうる。場合によっては、ターゲットの秘密鍵は常にTbox自体によって生成され、変更されない。ユーザがターゲット秘密鍵を取得すると、ユーザは秘密鍵を使用して何度も車両をロック解除することができ、これは車両の大きなセキュリティリスクを引き起こす。したがって、動的に更新された秘密鍵は、車両の安全性を向上させうる。

例6
図15に示すプロセス1500の前述の説明に基づいて、秘密鍵再設定命令に含まれる第1の秘密鍵は、Tboxに送信され、記憶装置（例えば、記憶装置430）に格納され得る。本明細書で使用されるように、第1の秘密鍵は、Tboxのターゲット秘密鍵として指定され得る。特定の実施形態では、車両管理プラットフォームから車両をロック解除するための第2の要求を受信した後に、車両管理プラットフォームは、第2の秘密鍵を第2のユーザ端末に送信しうる。車両のロックが解除されるかどうかは、Tboxに格納されている第1の秘密鍵と第2の秘密鍵との一致に依存する。図16は、本開示のいくつかの実施形態による、車両をロック解除するための例示的なプロセスを示すフローチャートである。

プロセス1600のステップ1602で、車両管理プラットフォーム（例えば、第1の取得モジュール510）は、第2のユーザ端末から車両をロック解除するアクションについての要求（本明細書ではロック解除要求とも呼ばれる）を受信しうる。要求は、ロック解除される車両のTboxに対応する識別子を含む。

例えば、第2のユーザが車両のロックを解除したい場合、第2のユーザは、第2のユーザ端末を介してロック解除要求を車両管理プラットフォームに送信する。車両管理プラットフォームは、それに応じて、第2のユーザ端末からロック解除要求を受信する。

いくつかの実施形態では、第2のユーザ端末がロック解除要求を車両管理プラットフォームに送信する前に、第2のユーザ端末はまた、車両をチェックアウトするための要求、ドアを開けるための要求、および／または他の要求を車両管理プラットフォームに送信しうる。いくつかの実施形態では、ロック解除要求は、これらの要求に埋め込まれ得る。

プロセス1600のステップ1604で、車両管理プラットフォーム（例えば、第1の送信モジュール530）は、第2の秘密鍵を含む命令を第2のユーザ端末に与えうる。したがって、車両管理プラットフォームは、第2の秘密鍵を第2のユーザ端末に送信しうる。第2の秘密鍵は、車両をロック解除するために使用され得る。

いくつかの実施形態では、ロック解除要求を受信した後に、車両管理プラットフォームは、記憶装置430から第2の秘密鍵を取得し、第2の秘密鍵を第2のユーザ端末に送信しうる。

いくつかの実施形態では、車両管理プラットフォームは、Tboxの識別子と第1の秘密鍵および第2の秘密鍵との間の対応関係を格納する。第1の秘密鍵および第2の秘密鍵は、予め設定された規則に従って決定され得る。当業者にとって、予め設定された規則は、任意の適切なペアリングルールであってもよく、限定することを意図するものではない。例えば、第1の秘密鍵は第2の秘密鍵と同じであってもよい。Tboxは、第2のユーザ端末から検証要求を受信したときに、第2の秘密鍵がTboxに格納された第1の秘密鍵と同じであるかどうかを判定しうる。第2の秘密鍵が第1の秘密鍵と同じである場合には、それらが良好に一致されていることを意味する。他の例として、第2の秘密鍵は第1の秘密鍵とは異なるが、第2の秘密鍵と第1の秘密鍵との間には予め設定された関係がある。Tboxは、予め設定された関係および第1の秘密鍵に基づいて結果を決定し、結果が第2の秘密鍵と同じであるかどうかを判定しうる。結果が第2の秘密鍵と同じである場合には、第2の秘密鍵と第1の秘密鍵が良好に一致されていることを意味する。

いくつかの実施形態では、第2のユーザ端末が第2の秘密鍵を受信すると、第2のユーザは、第2の秘密鍵と第1の秘密鍵との間のペアリングを要求しうる。例えば、第2のユーザ端末が要求をTboxに送信すると、Tboxは、ステップ1606に示すように、第1の秘密鍵と第2の秘密鍵との間のマッチング動作を実行しうる。

プロセス1600のステップ1608で、車両は、第1の秘密鍵と第2の秘密鍵との一致に応じてロック解除され得る。第1の秘密鍵が第2の秘密鍵と一致する場合には、Tboxが車両をロック解除しうる。車両のロックを解除した後に、第2のユーザは車両を自由に使用しうる。

いくつかの実施形態では、第1の秘密鍵が第2の秘密鍵と一致しない場合には、Tboxは車両のロックを解除しないことがある。車両管理プラットフォームは、車両が第2のユーザ端末からロック解除に失敗したことを示す情報を受信しうる。この情報は、Tboxの識別子も含みうる。

例えば、Tboxは、第1のユーザ端末が第1の秘密鍵を送信した後に、第1の秘密鍵をターゲット秘密鍵として再設定することに失敗するか、または第1の秘密鍵に関するデータを失う。その場合、ターゲットの秘密鍵はエラー秘密鍵であり得る。第2のユーザ端末が第2の秘密鍵とターゲット秘密鍵とのペアリング要求を送信すると、それに応じて第2の秘密鍵がエラーターゲット秘密鍵と一致しない可能性がある。この場合、第2のユーザ端末は、車両がロック解除に失敗したことを示す情報を車両管理プラットフォームに送信しうる。

車両がロック解除に失敗したことを示す受信情報に応じて、車両管理プラットフォームは、秘密鍵を再設定するための第2の命令（第2の秘密鍵再設定命令とも呼ばれる）をTboxに送信する。第2の秘密鍵再設定命令は、Tboxに対応する識別子を含む。Tboxは、第2の秘密鍵再設定命令に従って、第1の秘密鍵をターゲット秘密鍵として再び再設定しうる。再設定が成功すると、TboxはTboxのターゲット秘密鍵の再設定が成功したことを示す情報を送信しうる。

車両管理プラットフォームは、第2のユーザ端末から失敗したロック解除情報を受信した後に、車両管理プラットフォームは、第2の秘密鍵再設定命令をTboxに送信する。Tboxは、第2の秘密鍵再設定命令に従って再設定動作を実行し、成功した再設定情報を車両管理プラットフォームに送信する。第2の秘密鍵再設定命令は、Tboxの識別子に対応する第1の秘密鍵を含む。Tboxは、第1の秘密鍵をターゲット秘密鍵として再度更新する。

いくつかの実施形態では、車両管理プラットフォームは、Tboxの秘密鍵の正常な再設定を示す情報を受信する。Tboxの秘密鍵の再設定が成功したことを示す情報に応じて、車両管理プラットフォームは、第2のユーザ端末に車両のロック解除を再試行するように思い出させるための命令を生成し、その命令を第2のユーザ端末に送信しうる。第2のユーザ端末は、第2の秘密鍵とターゲット秘密鍵（すなわち、第1の秘密鍵）とをペアリングするための要求を送信しうる。Tboxが第1の秘密鍵が第2の秘密鍵と一致すると判断した場合には、車両管理プラットフォームはTboxに車両をロック解除するように命令しうる。

例7
図17は、本開示のいくつかの実施形態による、車両をロック解除するための例示的なプロセスを示すフローチャートである。プロセス1700は、アイテムのターゲット制御（例えば、車両のTbox）に実装され得る。いくつかの実施形態では、プロセス1700は、命令の形態で記憶装置430に格納されて、プロセッサ420によって呼び出され、および／または実行されてもよい。

ステップ1702で、Tbox（例えば、第2の取得モジュール710）は、車両管理プラットフォームから秘密鍵再設定命令を受信しうる。秘密鍵再設定命令が使用されて、Tboxにターゲット秘密鍵を再設定するように命令しうる。例えば、秘密鍵再設定命令は、車両をロック解除するために使用されるターゲット秘密鍵として第1の秘密鍵を再設定するようにTboxに促す。いくつかの実施形態では、秘密鍵再設定命令は、第1の秘密鍵を含む。第1の秘密鍵は、車両をロック解除するために使用される。

ステップ1704で、Tbox（例えば、第2の処理モジュール720）は、命令に従って、第1の秘密鍵をTboxのターゲット秘密鍵として設定しうる。

第1のユーザが車両の使用を終了し、車両を返却したい場合、第1のユーザは、第1のユーザ端末を使用して、車両を返却するための要求を車両管理プラットフォームに送信しうる。車両を返却する要求を受信すると、車両管理プラットフォームは、車両に対応する少なくとも1つの秘密鍵を生成しうる。例えば、少なくとも1つの秘密鍵は、第1の秘密鍵および第2の秘密鍵を含む。車両動力のロックを解除するために、少なくとも1つの秘密鍵が使用され得る。車両管理プラットフォームは、様々な方法で秘密鍵を生成しうる。上記の例は、限定することを意図したものではない。

少なくとも1つの秘密鍵を生成した後に、車両管理プラットフォームは、第1の秘密鍵を含む秘密鍵再設定命令をTboxに与えうる。秘密鍵再設定命令が使用されて、第1の秘密鍵をターゲット秘密鍵として再設定するようにTboxに命令しうる。

いくつかの実施形態では、Tboxの識別子とTboxとの間の対応関係は、車両管理プラットフォームの記憶装置（例えば、記憶装置113）に格納され得る。車両管理プラットフォームが少なくとも1つの秘密鍵を生成した後に、車両管理プラットフォームは、要求に含まれる識別子に対応するTboxを検索しうる。車両管理プラットフォームは、ネットワークを介してTboxと通信しうる。車両管理プラットフォームは、秘密鍵再設定命令をTboxに送信しうる。秘密鍵再設定命令を受信した後に、Tboxは、古い秘密鍵を置き換えるために、受信した秘密鍵を新しい秘密鍵（すなわち、ターゲット秘密鍵）として再設定することができ、これにより、秘密鍵の動的更新を達成しうる。車両が再度使用される場合、ユーザは新しい秘密鍵を使用して車両をロック解除する必要があり、これにより、不正使用を防ぐための車両の安全性が向上しうる。

いくつかの実施形態では、少なくとも1つの秘密鍵は、第1のBluetoothペアリングコードを含みうる。第2のユーザが車両管理プラットフォームから車両をチェックアウトすることを望む場合、車両管理プラットフォームは、第1のBluetoothペアリングコードを第2のユーザの第2のユーザ端末に送信しうる。第2のユーザ端末は、第1のBluetoothペアリングコードとTboxに格納されたBluetoothペアリングコードとの間のBluetoothペアリングを要求しうる。ペアリングが成功すると、車両のロックが解除される。

いくつかの実施形態では、少なくとも1つの秘密鍵は、第2のBluetoothペアリングコードを含みうる。第2のユーザが車両管理プラットフォームから車両をチェックアウトすることを望む場合、車両管理プラットフォームは、第2のBluetoothペアリングコードを第2のユーザの第2のユーザ端末に送信しうる。第2のユーザ端末は、第2のBluetoothペアリングコードと車両のTboxに格納されているBluetoothペアリングコードとの間のBluetoothペアリングを要求しうる。ペアリングが成功すると、車両のロックが解除される。

図17に関連して説明したように、第1のユーザからの車両の返却を終了すると、車両管理プラットフォームは、車両のTboxに対応する少なくとも1つの秘密鍵を生成しうる。車両管理プラットフォームは、秘密鍵再設定命令をTboxに与えうる。秘密鍵再設定命令は、第1の秘密鍵を含む。Tboxは、第1の秘密鍵をTboxのターゲット秘密鍵として再設定しうる。第2のユーザが車両管理プラットフォームから車両をチェックアウトしたい場合、第2のユーザは車両をロック解除するためにTboxのターゲット秘密鍵を要求する必要がある。Tboxのターゲット秘密鍵は、図17に記載されているように動的に更新され得、これにより車両の安全性を改善しうる。場合によっては、ターゲットの秘密鍵は常にTbox自体によって生成され、変更されない。ユーザがターゲット秘密鍵を取得すると、ユーザは秘密鍵を使用して何度も車両をロック解除することができ、これは車両の大きなセキュリティリスクを引き起こす。したがって、動的に更新された秘密鍵は、車両の安全性を向上させうる。

例8
図17に示すプロセス1700の前述の説明に基づいて、Tboxは、第2のユーザ端末から第2の秘密鍵を検証するための要求を受信しうる。例えば、第2のユーザ端末は、第2の秘密鍵とTboxのターゲット秘密鍵との間のペアリング要求を送信する。いくつかの実施形態では、第2のユーザ端末から車両をロック解除するための要求を受信すると、車両管理プラットフォームは、第2の秘密鍵を含む命令を第2のユーザ端末に与える。いくつかの実施形態では、第2のユーザ端末が第2の秘密鍵を受信すると、第2のユーザ端末は、第2の秘密鍵を検証するための要求をTboxに送信しうる。同時に、さらなる検証のために第2の秘密鍵がTboxに送信され得る。

検証要求に応じて、Tboxは、第1の秘密鍵と第2の秘密鍵との間のマッチング動作を実行しうる。第1の秘密鍵が第2の秘密鍵と一致する場合には、Tboxが車両をロック解除しうる。

いくつかの実施形態では、第1の秘密鍵が第2の秘密鍵と一致しない場合には、Tboxは車両のロックを解除しないことができる。この場合、Tboxは車両管理プラットフォームから第2の秘密鍵再設定命令を受信しうる。第2の秘密鍵再設定命令は、第1の秘密鍵を含む。

Tboxは、第2の秘密鍵再設定命令に従って秘密鍵を再設定し、成功した再設定情報を車両管理プラットフォームに送信しうる。Tboxの秘密鍵の成功した再設定情報に応じて、車両管理プラットフォームは、第2のユーザ端末に車両のロック解除を再試行するように思い出させるための命令を生成し、その命令を第2のユーザ端末に送信しうる。

例えば、Tboxは、第1のユーザ端末が第1の秘密鍵を送信した後に、第1の秘密鍵をターゲット秘密鍵として再設定することに失敗するか、または第1の秘密鍵に関するデータを失う。その場合、ターゲットの秘密鍵はエラー秘密鍵であり得る。第2のユーザ端末が第2の秘密鍵とターゲット秘密鍵とのペアリング要求を送信すると、それに応じて第2の秘密鍵がエラーターゲット秘密鍵と一致しない可能性がある。この場合、第2のユーザ端末は、車両がロック解除に失敗したことを示す情報を車両管理プラットフォームに送信しうる。

車両がロック解除に失敗したことを示す受信情報に応じて、車両管理プラットフォームは、秘密鍵を再設定するための第2の命令（第2の秘密鍵再設定命令とも呼ばれる）をTboxに送信する。第2の秘密鍵再設定命令は、Tboxに対応する識別子を含む。Tboxは、第2の秘密鍵再設定命令に従って、第1の秘密鍵をターゲット秘密鍵として再び再設定しうる。再設定が成功すると、TboxはTboxのターゲット秘密鍵の再設定が成功したことを示す情報を送信しうる。

いくつかの実施形態では、第1のユーザ端末から車両を返却するための要求を受信すると、車両管理プラットフォームは、車両をロックするための命令を与えうる。Tboxはロック命令を受信しうる。ロック命令に応じて、Tboxは、車両の現在の状態データを取得し、現在の状態データに基づいて、車両が現在ロック条件を満たしているかどうかを判定しうる。ロック条件は、ハンドブレーキが解除されているかどうか、エアコンがオフになっているかどうか、車両の窓が閉じているかどうかを含みうるが、これらに限定されない。ロック条件が満たされた場合には、Tboxが車両をロックしうる。

基本的な概念をこのように説明してきたが、この詳細な開示を読んだ後に、前述の詳細な開示は例としてのみ提示されることを意図しており、限定的ではないことが当業者には明らかであろう。本明細書では明示的に述べられていないが、当業者には、様々な変更、改良、および修正が可能であり、意図される。これらの変更、改良、および修正は、本開示によって示唆されることが意図されており、本開示の例示的な実施形態の趣旨および範囲内にある。

さらに、本開示の実施形態を説明するために特定の用語が使用されている。例えば、「一実施形態」、「実施形態」、および「いくつかの実施形態」という用語は、実施形態に関連して説明される特定の特徴、構造または特性が本開示の少なくとも1つの実施形態に含まれることを意味する。したがって、本明細書の様々な部分における「実施形態」、または「一実施形態」、または「代替的な実施形態」への2つ以上の言及は、必ずしもすべてが同じ実施形態を指しているわけではないことが強調されており、それを理解されたい。さらに、特定の特徴、構造、または特性は、本開示の1つまたは複数の実施形態において適切であるように組み合わせられうる。

さらに、当業者には理解されるであろうが、本開示の態様は、新規で有用なプロセス、機械、製造、または物質の組成、またはその新しい有用な改良を含む、いくつかの特許可能なクラスまたはコンテキストのいずれかで本明細書に図示および記載され得る。したがって、本開示の態様は、完全にハードウェア、完全にソフトウェア（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、または本明細書で「モジュール」、「ユニット」、「構成要素」、「デバイス」、もしくは「システム」と一般的に総称されるソフトウェアおよびハードウェア実装の組み合わせで実装され得る。さらに、本開示の態様は、コンピュータ可読プログラムコードが具体化された1つまたは複数のコンピュータ可読媒体で具体化されたコンピュータプログラム製品の形をとりうる。

コンピュータ可読信号媒体は、例えば、ベースバンド内または搬送波の一部として、コンピュータ可読プログラムコードがその中に具体化された伝搬データ信号を含んでもよい。そのような伝搬信号は、電磁的、光学的など、またはそれらの任意の適切な組み合わせを含む、様々な形態のいずれかをとりうる。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体ではなく、命令実行システム、装置、またはデバイスによって、またはそれらに関連して使用するためのプログラムを通信、伝播、または移送しうる任意のコンピュータ可読媒体であってもよい。コンピュータ可読信号媒体上で具体化されたプログラムコードは、無線、有線、光ファイバケーブル、RFなど、または前述の任意の適切な組み合わせを含む、任意の適切な媒体を使用して送信されてもよい。

本開示の態様の動作を実行するためのコンピュータプログラムコードは、Java、Scala、Smalltalk、Eiffel、JADE、Emerald、C＋＋、C＃、VB．NET、Pythonなどのオブジェクト指向プログラミング言語、「C」プログラミング言語、Visual Basic、Fortran 2003、Perl、COBOL 2002、PHP、ABAPなどの従来の手続き型プログラミング言語、Python、Ruby、Groovyなどの動的プログラミング言語、またはその他のプログラミング言語を含む、1つまたは複数のプログラミング言語の任意の組み合わせで書かれうる。プログラムコードは、完全にユーザのコンピュータで、一部はユーザのコンピュータで、スタンドアロンソフトウェアパッケージとして、一部はユーザのコンピュータで、一部はリモートコンピュータで、または完全にリモートコンピュータもしくはサーバで実行しうる。後者のシナリオでは、リモートコンピュータは、ローカルエリアネットワーク（LAN）またはワイドエリアネットワーク（WAN）を含む任意のタイプのネットワークを介してユーザのコンピュータに接続されてもよく、あるいは、外部コンピュータへの接続（例えば、インターネットサービスプロバイダを使用したインターネットを通して）、またはクラウドコンピューティング環境での接続、またはサービスとしてのソフトウェア（SaaS）などのサービスとして提供される接続が行われてもよい。

さらに、処理要素またはシーケンスの列挙された順序、または数字、文字、または他の指定の使用は、したがって、特許請求されたプロセスおよび方法を、特許請求の範囲で指定される場合を除いて、任意の順序に限定することを意図しない。上記の開示は、現在開示の様々な有用な実施形態であると考えられるものを様々な例を通して説明しているが、そのような詳細は単にその目的のためであり、添付の特許請求の範囲は開示された実施形態に限定されないが、反対に、開示された実施形態の趣旨および範囲内にある修正および等価な配置を包含することを意図していることを理解されたい。例えば、上記の様々な構成要素の実施態様はハードウェアデバイスで具体化できるが、ソフトウェアのみの解決策、例えば既存のサーバまたはモバイルデバイスへのインストールとして実施されうる。

同様に、本開示の実施形態の前述の説明では、様々な特徴が、様々な実施形態の1つまたは複数の理解を助ける開示を簡素化する目的で、単一の実施形態、図面、またはその説明に一緒にグループ化されることがあることを理解されたい。しかしながら、この開示の方法は、特許請求される主題が各請求項で明示的に列挙されるよりも多くの特徴を必要とするという意図を反映するものとして解釈されるべきではない。むしろ、特許請求される主題は、前述の単一の開示された実施形態のすべての特徴より少ないところにある。

100 IoTシステム
101 第1の情報交換ポート
102 第2の情報交換ポート
110 IoTプラットフォーム
111 サーバ
112 処理装置
113 記憶装置
130 ユーザ端末システム
130－1 モバイルデバイス
130－2 タブレットコンピュータ
130－3 ラップトップコンピュータ
130－4 車両内の組み込みデバイス
140 ターゲットアイテムシステム
140－1 ターゲットアイテム
140－2 ターゲットアイテム
140－3 ターゲットアイテム
160 測位システム
160－1 衛星
160－2 衛星
160－3 衛星
170 ネットワーク
170－1 ネットワーク
170－2 ネットワーク
170－3 ネットワーク
200 コンピューティングデバイス
210 バス
220 プロセッサ
230 ROM
240 RAM
250 COMポート
260 I／O構成要素
270 ディスク
300 モバイルデバイス
310 通信モジュール
320 ディスプレイ
330 グラフィック処理ユニット（GPU）
340 中央処理装置（CPU）
350 I／Oデバイス
360 メモリ
370 モバイルオペレーティングシステム
380 アプリケーション
390 ストレージ
400 コンピューティングデバイス
410 通信バス
420 プロセッサ
430 記憶装置
510 第1の取得モジュール
520 第1の処理モジュール
530 第1の送信モジュール
610 第1の処理ユニット
620 第1のモードトリガユニット
710 第2の取得モジュール
720 第2の処理モジュール
730 第2の送信モジュール
810 第2の処理ユニット
820 第2のモードトリガユニット
900 プロセス
1000 パイプラインプロセス
1200 Tbox制御プロセス／方法
1300 パイプラインプロセス
1400 Tbox制御プロセス／方法
1500 プロセス
1600 プロセス
1700 プロセス

Claims (15)

1. 車両の共有使用を提供するように構成された車両管理プラットフォームに接続された前記車両のテレマティクスボックス（Tbox）を制御するための方法であって、
   前記車両管理プラットフォーム上で、ユーザ端末から、前記車両を返却するアクションについての要求を受信するステップであって、前記要求は前記車両の前記Tboxの識別子を含む、ステップと、
   前記要求に応じて前記車両を返却する前記アクションを処理するための第1の命令を生成するステップと、
   前記車両管理プラットフォームから、前記車両の前記Tboxへ前記第1の命令を与えるステップと、
   前記車両管理プラットフォーム上で、前記第1の命令に従って前記車両を前記返却する前記アクションが完了すると前記車両に関するフィードバック情報を受信するステップと、
   前記フィードバック情報に基づいて、前記Tboxの動作モードからスリープモードへのモード変更をトリガするための第2の命令を生成するステップと、
   を含む方法。
2. 前記第2の命令は秘密鍵をさらに含み、前記方法は、
   前記車両管理プラットフォームから、前記車両の前記Tboxに前記秘密鍵を送信するステップをさらに含む、請求項1に記載の方法。
3. 前記車両管理プラットフォーム上で、第2のユーザ端末から、前記車両をチェックアウトする第2のアクションについての第2の要求を受信するステップであって、前記第2の要求は前記車両の前記Tboxの前記識別子を含む、ステップと、
   前記第2の要求に応じて、前記Tboxを前記スリープモードから前記動作モードに変更するための第3の命令を生成ステップであって、前記第3の命令は第2の秘密鍵を含む、ステップと、
   前記車両管理プラットフォームから前記第2のユーザ端末に前記第2の秘密鍵を送信するステップと、
   をさらに含む、請求項2に記載の方法。
4. 車両の共有使用を提供するように構成された車両管理プラットフォームに接続された前記車両のテレマティクスボックス（Tbox）を制御するための方法であって、
   前記Tbox上で、前記車両管理プラットフォームから前記車両を返却するアクションを処理するための第1の命令を受信するステップと、
   前記Tbox上で、前記第1の命令に応じて前記車両を返却する前記アクションを実行するステップと、
   前記車両を返却する前記アクションが完了すると、前記Tboxから、前記車両に関するフィードバック情報を前記車両管理プラットフォームに送信するステップと、
   前記Tbox上で、前記車両管理プラットフォームから、前記Tboxの動作モードからスリープモードへのモード変更をトリガするための第2の命令を受信するステップであって、前記第2の命令は前記フィードバック情報に従って前記車両管理プラットフォームによって生成される、ステップと、
   を含む方法。
5. 前記第2の命令は秘密鍵をさらに含み、前記方法は、
   前記Tbox上で、前記車両管理プラットフォームから、前記秘密鍵を受信するステップと、
   前記Tbox上で、前記秘密鍵を非一時的コンピュータ可読媒体に保管するステップと、
   をさらに含む、請求項4に記載の方法。
6. 車両の共有使用を提供するように構成された車両管理プラットフォームに接続された前記車両のテレマティクスボックス（Tbox）を制御するためのシステムであって、
   前記車両管理プラットフォーム上で、ユーザ端末から、前記車両を返却するアクションについての要求を受信するように構成され、前記要求は前記車両の前記Tboxの識別子を含む、取得モジュールと、
   前記要求に応じて前記車両を返却する前記アクションを処理するための第1の命令を生成するように構成された処理モジュールと、
   前記車両管理プラットフォームから、前記車両の前記Tboxへ前記第1の命令を与えるように構成された送信モジュールと、を含み、
   前記取得モジュールは、前記車両管理プラットフォーム上で、前記第1の命令に従って前記車両を前記返却する前記アクションが完了すると前記車両に関するフィードバック情報を受信するようにさらに構成され、
   前記処理モジュールは、前記フィードバック情報に基づいて、前記Tboxの動作モードからスリープモードへのモード変更をトリガするための第2の命令を生成するようにさらに構成される、
   システム。
7. 前記第2の命令は、秘密鍵をさらに含み、前記送信モジュールは、
   前記車両管理プラットフォームから、前記秘密鍵を前記車両の前記Tboxに送信する
   ようにさらに構成される、請求項6に記載のシステム。
8. 前記取得モジュールは、前記車両管理プラットフォーム上で、第2のユーザ端末から、前記車両をチェックアウトする第2のアクションについての第2の要求を受信するようにさらに構成され、前記第2の要求は前記車両の前記Tboxの前記識別子を含み、
   前記第2の要求に応じて、前記処理モジュールは、前記Tboxを前記スリープモードから前記動作モードに変更するための第3の命令を生成するようにさらに構成され、前記第3の命令は第2の秘密鍵を含み、
   前記送信モジュールは、前記車両管理プラットフォームから前記第2の秘密鍵を前記第2のユーザ端末に送信するようにさらに構成される、請求項6または7に記載のシステム。
9. 前記第3の命令は、メッセージ検証コードをさらに含み、前記送信モジュールは、
   前記Tboxの前記スリープモードから前記動作モードへの前記モード変更をトリガするために、前記メッセージ検証コードを前記車両管理プラットフォームから前記Tboxに直接送信するようさらに構成される、請求項8に記載のシステム。
10. 車両の共有使用を提供するように構成された車両管理プラットフォームに接続された前記車両のテレマティクスボックス（Tbox）を制御するためのシステムであって、
    取得モジュールは、前記Tbox上で、前記車両管理プラットフォームから前記車両を返却するアクションを処理するための第1の命令を受信するように構成され、
    処理モジュールは、前記Tbox上で、前記第1の命令に応じて前記車両を返却する前記アクションを実行するように構成され、
    送信モジュールは、前記車両を返却する前記アクションが完了すると、前記Tboxから、前記車両に関するフィードバック情報を前記車両管理プラットフォームに送信するように構成され、
    前記取得モジュールは、前記Tbox上で、前記車両管理プラットフォームから、前記Tboxの動作モードからスリープモードへのモード変更をトリガするための第2の命令を受信するようにさらに構成され、前記第2の命令は前記フィードバック情報に従って前記車両管理プラットフォームによって生成される、
    システム。
11. 前記第2の命令は秘密鍵をさらに含み、
    前記取得モジュールは、前記Tbox上で、前記車両管理プラットフォームから前記秘密鍵を受信するようにさらに構成され、
    前記処理モジュールは、前記Tbox上で、前記秘密鍵を非一時的コンピュータ可読媒体に保管する、
    ように構成される、請求項10に記載のシステム。
12. 前記取得モジュールは、前記Tbox上で、第2のユーザ端末から第2の秘密鍵を受信するようにさらに構成され、前記第2の秘密鍵は、前記車両管理プラットフォームが前記Tboxに関連する前記車両をチェックアウトするための要求を受信したときに、前記車両管理プラットフォームによって生成される第3の命令の一部であり、前記第2の秘密鍵は、前記車両管理プラットフォームから前記第2のユーザ端末に送信され、
    前記処理モジュールは、
    前記秘密鍵と前記第2の秘密鍵との間のマッチング動作を実行し、
    前記秘密鍵と前記第2の秘密鍵との一致に応じて、前記Tboxの前記スリープモードから前記動作モードへのモード変更をトリガする、
    ようにさらに構成される、請求項10または11に記載のシステム。
13. 前記取得モジュールは、前記Tbox上で、前記車両管理プラットフォームから、メッセージ検証コードを受信するようにさらに構成され、
    前記処理モジュールは、
    前記Tbox上で、前記メッセージ検証コードを検証し、
    良好な検証に応じて、前記Tboxの前記スリープモードから前記動作モードへのモード変更をトリガする、
    ようにさらに構成される、請求項10から12のいずれか一項に記載のシステム。
14. 前記処理モジュールは、
    前記Tbox上で、前記車両の振動状態を検出し、
    前記車両の前記検出された振動状態に基づいて、前記Tboxの前記スリープモードから前記動作モードへの前記モード変更をトリガする、
    ようにさらに構成される、請求項10から13のいずれか一項に記載のシステム。
15. 前記送信モジュールは、
    前記車両の前記検出された振動状態を前記車両管理プラットフォームに報告する
    ようにさらに構成される、請求項14に記載のシステム。

Images