特表2024-530431 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ 華為技術有限公司の特許一覧

特表2024-530431オーバーザエア（ＯＴＡ）アップグレード方法および装置

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-08-21

(54)【発明の名称】オーバーザエア（ＯＴＡ）アップグレード方法および装置

(51)【国際特許分類】

G06F 8/654 20180101AFI20240814BHJP

B60R 16/02 20060101ALI20240814BHJP

【ＦＩ】

G06F8/654

B60R16/02 660U

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024504233

(86)(22)【出願日】2021-07-23

(85)【翻訳文提出日】2024-03-05

(86)【国際出願番号】 CN2021108210

(87)【国際公開番号】W WO2023000320

(87)【国際公開日】2023-01-26

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＢＬＵＥＴＯＯＴＨ

２．ＺＩＧＢＥＥ

(71)【出願人】

【識別番号】503433420

【氏名又は名称】華為技術有限公司

【氏名又は名称原語表記】ＨＵＡＷＥＩＴＥＣＨＮＯＬＯＧＩＥＳＣＯ．，ＬＴＤ．

【住所又は居所原語表記】ＨｕａｗｅｉＡｄｍｉｎｉｓｔｒａｔｉｏｎＢｕｉｌｄｉｎｇ，Ｂａｎｔｉａｎ，ＬｏｎｇｇａｎｇＤｉｓｔｒｉｃｔ，Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ５１８１２９，Ｐ．Ｒ．Ｃｈｉｎａ

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広信哉

(74)【代理人】

【識別番号】100133569

【弁理士】

【氏名又は名称】野村進

(72)【発明者】

【氏名】▲馬▼ 涛

【テーマコード（参考）】

5B376

【Ｆターム（参考）】

5B376AB25

5B376CA05

5B376CA27

5B376CA32

5B376CA36

5B376CA41

5B376CA60

5B376CA76

5B376FA11

5B376GA08

(57)【要約】

本出願の実施形態は、OTAアップグレード方法および装置を提供し、車両のインターネットの分野に適用される。特定のアプリケーションでは、サーバは、第1のアップグレードタスクを生成し、第1のアップグレードタスクは第1の実施条件に対応し、第1の実施条件は端末デバイスの状況を含み、状況は端末デバイスに生物が存在しないことを含む。サーバは、第1のアップグレードタスクを端末デバイスに送信する。第1のアップグレードタスクを受信した後、端末デバイスは、第1のアップグレードタスクに対応する第1の実施条件に基づいて、第1の生体認識結果を含む第1の状況を取得し、異なる第1の生体認識結果に基づいて、第1の状況に対応する第1の動作を実行する。このようにして、OTAアップグレードタスクは、安全性が保証された環境で実施することができる。

【特許請求の範囲】

【請求項1】

アップグレード方法であって、前記方法は、
第1のアップグレードタスクを受信するステップであって、前記第1のアップグレードタスクが第1の実施条件に対応する、ステップと、
前記第1の実施条件に基づいて端末デバイスの第1の状況を取得するステップであって、前記第1の状況が第1の生体認識結果を含む、ステップと、
前記第1の状況に対応する第1の動作を実行するステップと、
を含む、方法。

【請求項2】

前記第1の状況に対応する第1の動作を実行する前記ステップは、
前記第1の生体認識結果が、前記端末デバイスに生物が存在するというものである場合、前記第1の状況に対応する前記第1の動作を実行するステップは第1のプロンプトを出力するステップであって、前記第1のプロンプトは、前記第1のアップグレードタスクを実施することができないことを示す、ステップ、または、
前記第1の生体認識結果が、前記端末デバイスに生物が存在しないというものである場合、前記第1の状況に対応する前記第1の動作を実行するステップは前記第1のアップグレードタスクを実施するステップ
を含む、請求項1に記載の方法。

【請求項3】

前記第1の状況に対応する前記第1の動作を実行するステップが、前記第1のアップグレードタスクを実施するステップであるとき、前記方法は、
前記端末デバイスのドアロックをロック状態になるように制御するステップ、および／または第2のプロンプトを出力するステップであって、前記第2のプロンプトが、前記端末デバイスに生物が存在しないはずであることを示す、ステップ
をさらに含む、請求項2に記載の方法。

【請求項4】

前記第1の状況に対応する前記第1の動作を実行するステップが、前記第1のアップグレードタスクを実施するステップであるとき、前記方法は、
前記端末デバイスのドアロック状況を取得するステップであって、前記端末デバイスの前記ドアロック状況が、前記ドアロックが開かれていることを含む、ステップ、および／または
前記端末デバイスの第2の状況を取得するステップであって、前記第2の状況が第2の生体認識結果を含み、前記第2の生体認識結果が、前記端末デバイスに生物が存在することである、ステップ、および
前記第1のアップグレードタスクの実施を中断もしくは終了するステップ
をさらに含む、請求項2または3に記載の方法。

【請求項5】

前記第1の状況に対応する前記第1の動作を実行するステップが、前記第1のアップグレードタスクを実施するステップであるとき、前記方法は、
前記端末デバイスのドアロック状況を取得するステップであって、前記端末デバイスの前記ドアロック状況が、前記ドアロックが開かれていることを含む、ステップ、および／または
前記端末デバイスの第2の状況を取得するステップであって、前記第2の状況が第2の生体認識結果を含み、前記第2の生体認識結果が、前記端末デバイスに生物が存在することである、ステップ、
前記第1のアップグレードタスクに含まれる第1のアップグレードサブタスクが完了したと決定するステップであって、前記第1のアップグレードサブタスクがバイオセーフティ関連コンポーネントのアップグレードに対応する、ステップ、および
前記第1のアップグレードタスクの実施を継続するステップ
をさらに含む、請求項2または3に記載の方法。

【請求項6】

前記第1の状況に対応する前記第1の動作を実行するステップが、前記第1のプロンプトを出力するステップであるとき、前記方法は、
第3のプロンプトを出力するステップであって、前記第3のプロンプトが、前記第1のアップグレードタスクを実施することができない理由および／または前記第1のアップグレードタスクを再実施するための条件を示す、ステップ
をさらに含む、請求項2に記載の方法。

【請求項7】

端末デバイスの第1の状況を取得する前記ステップの前に、前記方法は、
第4のプロンプトを出力するステップであって、前記第4のプロンプトが前記第1の実施条件を示す、ステップ
をさらに含む、請求項1から6のいずれか一項に記載の方法。

【請求項8】

前記方法は、
サーバから前記第1の実施条件を受信するステップ、または
アップグレードタスクと実施条件との間の構成されたもしくは定義されたマッピング関係に基づいて前記第1の実施条件を決定するステップ
をさらに含む、請求項1から7のいずれか一項に記載の方法。

【請求項9】

端末デバイスの第1の状況を取得する前記ステップは、前記端末デバイス内のセンサを使用して前記第1の状況を取得するステップであって、前記センサが、カメラ、圧力センサ、ミリ波レーダセンサ、およびLidarのうちの1つまたは複数を含む、ステップを含む、請求項1から8のいずれか一項に記載の方法。

【請求項10】

アップグレード方法であって、前記方法は、
第1のアップグレードタスクを生成するステップであって、前記第1のアップグレードタスクが第1の実施条件に対応し、前記第1の実施条件が端末デバイスの状況を含み、前記端末デバイスの前記状況が、前記端末デバイスに生物が存在しないことを含む、ステップと、
前記第1のアップグレードタスクを送信するステップと、
を含む、方法。

【請求項11】

前記方法は、
前記第1のアップグレードタスクに基づいて前記第1の実施条件を構成するステップと、
前記第1の実施条件を送信するステップと、
をさらに含む、請求項10に記載の方法。

【請求項12】

前記第1のアップグレードタスクは第1のアップグレードサブタスクを含み、前記第1のアップグレードサブタスクはバイオセーフティ関連コンポーネントのアップグレードに対応する、請求項10または11に記載の方法。

【請求項13】

第1のアップグレードタスクを受信するように構成された送受信部であって、前記第1のアップグレードタスクが第1の実施条件に対応する、送受信部と、
前記第1の実施条件に基づいて端末デバイスの第1の状況を取得するように構成された処理部であって、前記第1の状況が第1の生体認識結果を含み、前記処理部は前記第1の状況に対応する第1の動作を実行するように構成される、処理部と、
を備える、通信装置。

【請求項14】

前記処理部によって前記第1の状況に対応する第1の動作を実行する前記ステップは、
前記第1の生体認識結果が、前記端末デバイスに生物が存在するというものである場合、前記処理部によって前記第1の状況に対応する前記第1の動作を実行するステップは、前記処理部によって第1のプロンプトを出力するステップであって、前記第1のプロンプトは、前記第1のアップグレードタスクを実施することができないことを示す、ステップ、または、
前記第1の生体認識結果が、前記端末デバイスに生物が存在しないというものである場合、前記処理部によって前記第1の状況に対応する前記第1の動作を実行するステップは、前記処理部によって前記第1のアップグレードタスクを実施するステップ
を含む、請求項13に記載の装置。

【請求項15】

前記処理部によって前記第1の状況に対応する前記第1の動作を実行するステップが、前記処理部によって前記第1のアップグレードタスクを実施するステップであるとき、前記処理部は、
前記端末デバイスのドアロックをロック状態になるように制御し、および／または第2のプロンプトを出力し、前記第2のプロンプトが、前記端末デバイスに生物が存在しないはずであることを示す、
ようにさらに構成される、請求項14に記載の装置。

【請求項16】

前記処理部によって前記第1の状況に対応する前記第1の動作を実行するステップが、前記処理部によって前記第1のアップグレードタスクを実施するステップであるとき、前記処理部は、
前記端末デバイスのドアロック状況を取得し、前記端末デバイスの前記ドアロック状況が、前記ドアロックが開かれていることを含み、および／または
前記端末デバイスの第2の状況を取得し、前記第2の状況が第2の生体認識結果を含み、前記第2の生体認識結果が、前記端末デバイスに生物が存在することであり、および
前記第1のアップグレードタスクの実施を中断もしくは終了する、
ようにさらに構成される、請求項14または15に記載の装置。

【請求項17】

前記処理部によって前記第1の状況に対応する前記第1の動作を実行するステップが、前記処理部によって前記第1のアップグレードタスクを実施するステップであるとき、前記処理部は、
前記端末デバイスのドアロック状況を取得し、前記端末デバイスの前記ドアロック状況が、前記ドアロックが開かれていることを含み、および／または
前記端末デバイスの第2の状況を取得し、前記第2の状況が第2の生体認識結果を含み、前記第2の生体認識結果が、前記端末デバイスに生物が存在することであり、
前記第1のアップグレードタスクに含まれる第1のアップグレードサブタスクが完了したと決定し、前記第1のアップグレードサブタスクがバイオセーフティ関連コンポーネントのアップグレードに対応し、および
前記第1のアップグレードタスクの実施を継続する、
ようにさらに構成される、請求項14または15に記載の装置。

【請求項18】

前記処理部によって前記第1の状況に対応する前記第1の動作を実行するステップが、前記処理部によって前記第1のプロンプトを出力するステップであるとき、前記処理部は、
第3のプロンプトを出力し、前記第3のプロンプトが、前記第1のアップグレードタスクを実施することができない理由および／または前記第1のアップグレードタスクを再実施するための条件を示す、
ようにさらに構成される、請求項14に記載の装置。

【請求項19】

前記処理部は、
第4のプロンプトを出力し、前記第4のプロンプトが前記第1の実施条件を示す、
ようにさらに構成される、請求項13から18のいずれか一項に記載の装置。

【請求項20】

前記送受信部は、サーバから前記第1の実施条件を受信するようにさらに構成される、または前記処理部は、アップグレードタスクと実施条件との間の構成されたもしくは定義されたマッピング関係に基づいて前記第1の実施条件を決定するようにさらに構成される、請求項13から19のいずれか一項に記載の装置。

【請求項21】

第1のアップグレードタスクを生成するように構成された処理部であって、前記第1のアップグレードタスクが第1の実施条件に対応し、前記第1の実施条件が端末デバイスの状況を含み、前記端末デバイスの前記状況が、前記端末デバイスに生物が存在しないことを含む、処理部と、
前記第1のアップグレードタスクを送信するように構成された送受信部と、
を備える、通信装置。

【請求項22】

前記処理部は、前記第1のアップグレードタスクに基づいて前記第1の実施条件を構成するようにさらに構成され、前記送受信部は、前記第1の実施条件を送信するようにさらに構成される、請求項21に記載の装置。

【請求項23】

前記第1のアップグレードタスクは第1のアップグレードサブタスクを含み、前記第1のアップグレードサブタスクはバイオセーフティ関連コンポーネントのアップグレードに対応する、請求項22に記載の装置。

【請求項24】

通信装置であって、前記通信装置は、少なくとも1つのプロセッサおよび送受信機を備え、前記少なくとも1つのプロセッサは、少なくとも1つのメモリに格納されたコンピュータプログラムを呼び出して、請求項1から9のいずれか一項または請求項10から12のいずれか一項に記載の方法を実行するように構成される、通信装置。

【請求項25】

請求項1から9のいずれか一項に記載の方法を実行するように構成された通信装置を備える、端末デバイス。

【請求項26】

請求項10から12のいずれか一項に記載の方法を実行するように構成された通信装置を備える、サーバ。

【請求項27】

請求項1から9のいずれか一項に記載の方法を実行するように構成された通信装置と、請求項10から12のいずれか一項に記載の方法を実行するように構成された通信装置と、を備える、通信システム。

【請求項28】

1つまたは複数のプロセッサおよびインターフェース回路を備えるチップであって、前記インターフェース回路は、前記1つまたは複数のプロセッサのための情報入力および／または情報出力を提供するように構成され、前記チップは、請求項1から9のいずれか一項または請求項10から12のいずれか一項に記載の方法を実行するように構成される、チップ。

【請求項29】

コンピュータ可読記憶媒体であって、前記コンピュータ可読記憶媒体はコンピュータプログラムまたは命令を記憶しており、前記コンピュータプログラムまたは命令が通信装置によって実施されると、請求項1から9のいずれか一項または請求項10から12のいずれか一項に記載の方法が実現される、コンピュータ可読記憶媒体。

【請求項30】

コンピュータプログラム製品であって、前記コンピュータプログラム製品が1つまたは複数のプロセッサ上で動作するとき、請求項1から9のいずれか一項または請求項10から12のいずれか一項に記載の方法が実現される、コンピュータプログラム製品。

【発明の詳細な説明】

【技術分野】

【0001】

本出願の実施形態は、車両のインターネットの技術の分野に関し、特に、OTAアップグレード方法および装置に関する。

【背景技術】

【0002】

社会の発展および科学技術の進歩に伴い、インテリジェント車両は、インテリジェント運転および無人運転の分野でますます広く適用されている。インテリジェント車両は、数十または数百の電子制御ユニット（electronic control unit、ECU）を含む複雑なシステムである。インテリジェント車両の様々な複雑な機能は、ECU間の協調によって実現される。

【0003】

インテリジェント車両の製造業者（original equipment manufacturer、OEM）は、主にこれらの機能に関連するECUをアップグレードすることによって、インテリジェント車両の様々な機能を維持およびアップグレードする。製造業者がリコールコストを削減し、要件を迅速に満たし、ユーザ体験を改善するのを助けるために、オーバーザエア（over the air、OTA）技術を使用して、車両の関連するハードウェアまたはソフトウェアをアップグレードすることができる。しかしながら、インテリジェント車両がOTAアップグレードタスクを実施するとき、元のソフトウェアまたはハードウェア機能は利用できない状態にあり、安全上の問題を引き起こす。OTAアップグレードタスクの実施中に、安全性が保証された環境でOTAアップグレードタスクが実施されることを保証する方法は、当業者が緊急に解決すべき技術的問題である。

【発明の概要】

【0004】

本出願の実施形態は、安全なOTAアップグレードを実現するための、すなわち、OTAアップグレードを安全性（特に個人の安全性）が保証された環境で実施することができることを保証するための、OTAアップグレード方法および対応する装置を開示する。

【課題を解決するための手段】

【0005】

第1の態様によれば、アップグレード方法が提供される。本方法は、端末デバイス、または端末デバイスに構成されたチップによって実行されてもよい。本方法は、第1のアップグレードタスクを受信するステップであって、第1のアップグレードタスクが第1の実施条件に対応する、ステップと、第1の実施条件に基づいて端末デバイスの第1の状況を取得するステップであって、第1の状況が第1の生体認識結果を含む、ステップと、第1の状況に対応する第1の動作を実行するステップと、を含む。

【0006】

任意選択の設計では、本方法は、端末デバイスに含まれるOTA管理モジュールまたはOTA管理モジュールに構成されたチップによって代替的に実行されてもよい。

【0007】

この解決策によれば、OTAタスクが実施される前に、最初に第1の生体認識結果が取得され、第1の生体認識結果に基づいて対応する第1の動作が実行される。端末デバイスの第1の状況が考慮されるため、OTAアップグレードは、安全性が保証された環境で実施することができる。

【0008】

第1の態様に関連して、第1の態様のいくつかの実装形態では、第1の状況に対応する第1の動作を実行するステップは、第1の生体認識結果が、端末デバイスに生物が存在するというものである場合、第1の状況に対応する第1の動作を実行するステップは第1のプロンプトを出力するステップであって、第1のプロンプトは、第1のアップグレードタスクを実施することができないことを示す、ステップ、または、第1の生体認識結果が、端末デバイスに生物が存在しないというものである場合、第1の状況に対応する第1の動作を実行するステップは第1のアップグレードタスクを実施するステップを含む。

【0009】

この解決策によれば、異なる生体認識結果に基づいて異なる動作が実行されるので、OTAアップグレードは、安全性が保証された環境で実施することができる。

【0010】

任意選択の設計では、第1のプロンプトは、携帯電話、ウェアラブルデバイス、タブレットコンピュータ、ノートブックコンピュータ、およびHMIインターフェースのうちの1つまたは複数を使用して出力されてもよい。

【0011】

任意選択の設計では、第1のプロンプトは目立つように強調表示される。これに基づいて、第1のアップグレードタスクの実施状況を容易に確認することができる。

【0012】

第1の態様に関連して、第1の態様のいくつかの実装形態では、第1の状況に対応する第1の動作を実行するステップが、第1のアップグレードタスクを実施するステップであるとき、本方法は、端末デバイスのドアロックをロック状態になるように制御するステップ、および／または第2のプロンプトを出力するステップであって、第2のプロンプトが、端末デバイスに生物が存在しないはずであることを示す、ステップをさらに含む。

【0013】

この解決策によれば、第1のアップグレードタスクを実施するプロセスにおいて、端末デバイスの外部の人が端末デバイスに入るのを防ぐことができる。これにより、第1のアップグレードタスクを実施するプロセスにおいて、OTAアップグレードを安全性（特に個人の安全性）が保証された環境で実施することが保証される。

【0014】

任意選択の設計では、第2のプロンプトは、時間情報Tをさらに含むことができ、時間情報Tを満たす時間範囲内に端末デバイスに生物が存在しないはずであることを示す。これに基づいて、端末デバイスは、第1のアップグレードタスクの実施が完了した後に時間内に使用することができる。

【0015】

任意選択の設計では、第2のプロンプトは、携帯電話、ウェアラブルデバイス、タブレットコンピュータ、およびノートブックコンピュータのうちの1つまたは複数を使用して出力されてもよい。

【0016】

任意選択の設計では、第2のプロンプトは目立つように強調表示される。このようにして、第1のアップグレードタスクを安全性が保証された環境で実施することができることを保証するために、第1のアップグレードタスクの実施条件を容易に確認することができる。

【0017】

第1の態様に関連して、第1の態様のいくつかの実装形態では、第1の状況に対応する第1の動作を実行するステップが、第1のアップグレードタスクを実施するステップであるとき、本方法は、端末デバイスのドアロック状況を取得するステップであって、端末デバイスのドアロック状況が、ドアロックが開かれていることを含む、ステップ、および／または端末デバイスの第2の状況を取得するステップであって、第2の状況が第2の生体認識結果を含み、第2の生体認識結果が、端末デバイスに生物が存在することである、ステップ、および第1のアップグレードタスクの実施を中断もしくは終了するステップをさらに含む。

【0018】

この解決策によれば、第1のアップグレードタスクを実施するプロセスにおいて、端末デバイスの外部の人が端末デバイスに入ろうとしているか、または端末デバイスに入ったことが判明すると、第1のアップグレードタスクの実施を中断または終了することができる。これに基づいて、第1のアップグレードタスクを実施するプロセスにおいて、OTAアップグレードを安全性（特に個人の安全性）が保証された環境で実施することができる。加えて、この解決策によれば、特定のシナリオにおける端末デバイスの正常な使用をさらに保証することができる。

【0019】

第1の態様に関連して、第1の態様のいくつかの実装形態では、第1の状況に対応する第1の動作を実行するステップが、第1のアップグレードタスクを実施するステップであるとき、本方法は、端末デバイスのドアロック状況を取得するステップであって、端末デバイスのドアロック状況が、ドアロックが開かれていることを含む、ステップ、および／または端末デバイスの第2の状況を取得するステップであって、第2の状況が第2の生体認識結果を含み、第2の生体認識結果が、端末デバイスに生物が存在することである、ステップ、第1のアップグレードタスクに含まれる第1のアップグレードサブタスクが完了したと決定するステップであって、第1のアップグレードサブタスクがバイオセーフティ関連コンポーネントのアップグレードに対応する、ステップ、および第1のアップグレードタスクの実施を継続するステップをさらに含む。

【0020】

この解決策によれば、バイオセーフティ関連コンポーネントに対応するアップグレードタスクは、他のアップグレードタスクの実施に影響を及ぼすことなく、安全性が保証された環境で実施することができる。これにより、アップグレードタスクの実施効率が保証される。

【0021】

第1の態様に関連して、第1の態様のいくつかの実装形態では、第1の状況に対応する第1の動作を実行するステップが、第1のプロンプトを出力するステップであるとき、本方法は、第3のプロンプトを出力するステップであって、第3のプロンプトが、第1のアップグレードタスクを実施することができない理由および／または第1のアップグレードタスクを再実施するための条件を示す、ステップをさらに含む。

【0022】

この解決策によれば、第1のアップグレードタスクが実施されなかった理由および／または第1のアップグレードタスクを実施することができる条件を知ることができる。これにより、その後安全な環境でOTAアップグレードを実施できることが保証される。

【0023】

任意選択の設計では、第3のプロンプトは、携帯電話、ウェアラブルデバイス、タブレットコンピュータ、ノートブックコンピュータ、およびHMIインターフェースのうちの1つまたは複数を使用して出力されてもよい。

【0024】

任意選択の設計では、第3のプロンプトは目立つように強調表示される。これにより、第1のアップグレードタスクが実施されなかった理由および第1の実施条件を容易に確認することができる。

【0025】

第1の態様に関連して、第1の態様のいくつかの実装形態では、この解決策は、第4のプロンプトを出力するステップであって、第4のプロンプトが第1の実施条件を示す、ステップをさらに含む。

【0026】

第1の態様に関連して、第1の態様のいくつかの実装形態では、この解決策は、設定に基づいて、第4のプロンプトに応答した確認情報に基づいて第1の状況を取得するかどうかを決定するステップをさらに含む。この解決策によれば、OTAアップグレードの柔軟性を実現することができる。第4の情報に対応する確認情報に基づいてアップグレードタスクに関連付けられた動作が実行される必要があると指定された場合、端末デバイスのユーザは、適切なシナリオで第1のアップグレードタスクの実施の開始を選択することができる。これにより、端末デバイスの正常な使用を保証することができ、OTAアップグレードを安全な環境で実施することを保証することができる。

【0027】

第1の態様に関連して、第1の態様のいくつかの実装形態では、この解決策は、サーバから第1の実施条件を受信するステップ、または、アップグレードタスクと実施条件との間の構成されたもしくは定義されたマッピング関係に基づいて第1の実施条件を決定するステップをさらに含む。

【0028】

この解決策によれば、OTAアップグレードが適切な実施環境で実施されることを保証するために、第1の実施条件を決定することができる。これにより、OTAアップグレードの安全性が保証される。

【0029】

第1の態様に関連して、第1の態様のいくつかの実装形態では、端末デバイスの第1の状況を取得するステップは、端末デバイス内のセンサを使用して第1の状況を取得するステップであって、センサが、カメラ、圧力センサ、ミリ波レーダセンサ、およびLidarのうちの1つまたは複数を含む、ステップを含む

【0030】

第2の態様によれば、アップグレード方法が提供される。本方法は、サーバ、またはサーバ内に構成されたチップによって実行されてもよい。本方法は、第1のアップグレードタスクを生成するステップであって、第1のアップグレードタスクが第1の実施条件に対応し、第1の実施条件が端末デバイスの状況を含み、端末デバイスの状況が、端末デバイスに生物が存在しないことを含む、ステップと、第1のアップグレードタスクを送信するステップと、を含む、方法。

【0031】

第2の態様に関連して、第2の態様のいくつかの実装形態では、本方法は、第1のアップグレードタスクに基づいて第1の実施条件を構成するステップと、第1の実施条件を送信するステップと、をさらに含んでもよい。

【0032】

任意選択の設計では、第1のアップグレードタスクが第1のアップグレードサブタスクを含み、第1のアップグレードサブタスクがバイオセーフティ関連コンポーネントのアップグレードに対応する。

【0033】

第3の態様によれば、第1の態様もしくは第1の態様の可能な実装形態のいずれか1つにおける方法を実行するか、または第2の態様もしくは第2の態様の可能な実装形態のいずれか1つにおける方法を実行するための、処理部および送受信部を含む、通信装置が提供される。

【0034】

第4の態様によれば、少なくとも1つのプロセッサ、および送受信機を含む通信装置が提供される。少なくとも1つのプロセッサは、少なくとも1つのメモリに格納されたコンピュータプログラムを呼び出して、第1の態様もしくは第1の態様の可能な実装形態のいずれか1つにおける方法を実行するか、または第2の態様もしくは第2の態様の可能な実装形態のいずれか1つにおける方法を実行するように構成される。送受信機は、送信および受信に関連する機能を実行するように構成される。任意選択の設計では、送受信機は、受信機および送信機を含むか、または受信セットおよび送信セットを含む。

【0035】

第4の態様に関連して、第4の態様のいくつかの実装形態では、通信装置はメモリをさらに含み、メモリは通信装置に含まれるプロセッサに結合され、プロセッサはメモリ内の命令を実施するように構成されてもよく、その結果、装置は、第1の態様もしくは第1の態様の可能な実装形態のいずれか1つにおける方法を実行するか、または第2の態様もしくは第2の態様の可能な実装形態のいずれか1つにおける方法を実行する。任意選択の設計では、本装置はインターフェース回路をさらに含んでもよく、プロセッサはインターフェース回路に結合される。

【0036】

第4の態様に関連して、第4の態様のいくつかの実装形態では、通信装置は通信チップであり、送受信機は通信チップの入出力回路またはポートであってもよい。

【0037】

第5の態様によれば、端末デバイスが提供される。端末デバイスは、第1の態様または第1の態様の可能な実装形態のいずれか1つにおける方法を実行するように構成された通信装置を含む。

【0038】

第6の態様によれば、サーバが提供される。サーバは、第2の態様または第2の態様の可能な実装形態のいずれか1つにおける方法を実行するように構成された通信装置を含む。

【0039】

第7の態様によれば、通信システムが提供される。通信システムは、第1の態様もしくは第1の態様の可能な実装形態のいずれか1つにおける方法を実行するように構成された通信装置、および／または第2の態様もしくは第2の態様の可能な実装形態のいずれか1つにおける方法を実行するように構成された通信装置を含む。

【0040】

第8の態様によれば、チップが提供される。チップは、1つまたは複数のプロセッサおよびインターフェース回路を含む。チップは、第1の態様もしくは第1の態様の可能な実装形態のうちのいずれか1つにおける方法を実行するか、または第2の態様もしくは第2の態様の可能な実装形態のうちのいずれか1つにおける方法を実行するように構成される。

【0041】

第9の態様によれば、コンピュータ可読記憶媒体が提供される。コンピュータ可読記憶媒体は、コンピュータプログラムまたは命令を記憶する。コンピュータプログラムまたは命令が通信装置によって実施されると、通信装置は、第1の態様もしくは第1の態様の可能な実装形態のうちのいずれか1つにおける方法を実行することが可能になるか、または通信装置は、第2の態様もしくは第2の態様の可能な実装形態のうちのいずれか1つにおける方法を実行することが可能になる。

【0042】

第10の態様によれば、コンピュータプログラム製品が提供される。コンピュータプログラム製品は、コンピュータプログラムまたは命令を含む。コンピュータプログラムまたは命令が通信装置によって実施されると、通信装置は、第1の態様もしくは第1の態様の可能な実装形態のうちのいずれか1つにおける方法を実行することが可能になるか、または通信装置は、第2の態様もしくは第2の態様の可能な実装形態のうちのいずれか1つにおける方法を実行することが可能になる。

【0043】

以下、本出願の実施形態で使用される添付の図面について説明する。

【図面の簡単な説明】

【0044】

【図1】本出願の一実施形態による、アップグレードシステムアーキテクチャの概略図である。

【図2】本願の一実施形態による、端末デバイスの概略図である。

【図3】本出願の一実施形態による、別のアップグレードシステムアーキテクチャの概略図である。

【図4】本出願の一実施形態による、別のアップグレードシステムアーキテクチャの概略図である。

【図5】本願における実施形態による、アップグレード方法に対応する概略的なフローチャートである。

【図6】本出願の一実施形態による、通信装置の概略図である。

【図7】本出願の一実施形態による、別の通信装置の概略図である。

【図8】本出願の一実施形態による、チップの構造の概略図である。

【発明を実施するための形態】

【0045】

以下は、本出願の実施形態における添付の図面を参照しながら本出願の実施形態における技術的解決策を詳細に説明する。

【0046】

本出願の実施形態では、「例」または「例えば」などの用語は、例、図示、または説明を与えることを表すために使用されることに留意されたい。本出願において「例」または「例えば」として説明されているあらゆる実施形態または設計方式は、他の実施形態または設計方式よりもより好ましいものとして、またはより多くの利点を有するものとして解釈されるべきではない。厳密には、「例」、「例えば」などの用語の使用は、関連するコンセプトを特定の方式で提示することを意図している。

【0047】

本出願の実施形態で言及される「および／または」という用語は、関連する対象を説明するための関連性の関係を説明するために使用され、3つの関係が存在し得ることを表す。例えば、Aおよび／またはBは、以下の3つの場合を、すなわちAのみが存在する場合と、AおよびBの両方が存在する場合と、Bのみが存在する場合と、を表す。AおよびBは、それぞれ単数形であっても複数形であってもよい。文字「／」は、一般に、関連付けられる対象間の「または」関係を示す。

【0048】

加えて、特に明記されない限り、本出願の実施形態における「第1」および「第2」などの序数は、複数の対象物を区別するために使用され、複数の対象物の順序、時系列、優先度または重要性を限定することは意図されていない。例えば、第1の情報および第2の情報は、単に異なる情報を区別するために使用されるにすぎず、内容、優先度、送信順序、または重要度における2つのタイプの情報間の違いを示すものではない。

【0049】

以下では、最初に、本出願の実施形態におけるシステムアーキテクチャおよびサービスシナリオについて説明する。本出願で説明されるシステムアーキテクチャおよびサービスシナリオは、本出願における技術的解決策をより明確に説明することを意図しているが、本出願で提供される技術的解決策に対する限定を構成するものではないことに留意されたい。当業者は、システムアーキテクチャの進化および新しいサービスシナリオの出現に伴い、本出願で提供される技術的解決策が同様の技術的問題にやはり適用可能であることを知ることができる。

【0050】

図1は、本出願の実施形態が適用可能であるアップグレードシステムアーキテクチャの概略図である。図1に示されているように、アップグレードシステムアーキテクチャは、サーバ、無線通信リンク、および端末デバイスを含んでもよい。

【0051】

例えば、本出願のこの実施形態におけるサーバは、製造業者またはOEMによって端末デバイスにOTAアップグレードを提供することができる装置である。具体的には、サーバは、無線通信機能および記憶機能を有する電子デバイス上に配置されてもよく、またはクラウド側の仮想マシンまたはコンテナ上に配置されてもよい。クラウド側は、複数の電子デバイスを含むクラスタであってもよい。

【0052】

例えば、本出願のこの実施形態における無線通信リンクは、通信ネットワークを使用して実現されるリンクであってもよい。通信ネットワークは、ローカルエリアネットワークであってもよいし、リレー（relay）デバイスを用いて転送される広域ネットワークであってもよいし、ローカルエリアネットワークおよび広域ネットワークを含んでもよい。通信ネットワークがローカルエリアネットワークである場合、通信ネットワークは、wifiホットスポットネットワーク、wifiポイントツーポイント（point to point、P2P）ネットワーク、Bluetoothネットワーク、zigbeeネットワーク、近距離通信（near field communication、NFC）ネットワーク、可能な将来のユニバーサル近距離通信ネットワークなどであり得る。通信ネットワークが広域ネットワークである場合、通信ネットワークは、第3世代移動通信技術（3rd－generation wireless telephone technology、3G）ネットワーク、第4世代移動通信技術（the 4th generation mobile communication technology、4G）ネットワーク、第5世代移動通信技術（5th－generation mobile communication technology、5G）ネットワーク、将来の進化型移動通信技術ネットワーク（6Gを含むがこれに限定されない）、公衆陸上移動ネットワーク（public land mobile network、PLMN）、またはインターネット（Internet）であってもよい。これは本出願の実施形態では限定されない。

【0053】

例えば、本出願のこの実施形態における端末デバイスは、サーバによって提供されるOTAアップグレードサービスをサポートする装置である。例えば、端末デバイスは、トランスポート手段またはインテリジェントデバイスであり得る。具体的には、トランスポート手段は、自動車（例えば、無人車両、インテリジェント車両、電気車両、またはデジタル車両）、無人航空機、鉄道車両、信号機などを含んでもよい。

【0054】

図2は、本願の一実施形態による、端末デバイスの概略図である。図2に示されているように、端末デバイスは、OTA管理モジュール（OTA Masterモジュールと呼ばれることもある）と、複数のOTAアップグレードモジュール（OTA Slaveモジュールと呼ばれることもある）と、を含む。OTA管理モジュールは、サーバからアップグレードパッケージを受信し、OTAアップグレードモジュールが担当するアップグレードオブジェクトのアップグレードパッケージをOTAアップグレードモジュールに送信するように構成される。OTAアップグレードモジュールは、アップグレードパッケージをインストールし、アップグレードパッケージのインストール結果をOTA管理モジュールにフィードバックするように構成される。任意選択の設計では、アップグレードオブジェクトの具体的な形態は、本出願の実施形態では限定されない。一例として、インテリジェント車両が使用される。アップグレードオブジェクトは、車両内のコンポーネントであってもよく、コンポーネント内のソフトウェアであってもよい。

【0055】

一例として、インテリジェント車両が使用される。図3は、本出願の実施形態が適用可能である別のアップグレードシステムアーキテクチャの概略図である。図3に示されているように、アップグレードシステムアーキテクチャは、OTAサーバ、無線通信リンク、および車両を含んでもよい。車両は、少なくとも、ゲートウェイ（gateway、GW）、インテリジェント運転をサポートするために使用される統合ソフトウェアおよびハードウェアプラットフォーム、すなわち、車両コンピューティングプラットフォーム（vehicle computing platform、VCP）、人間機械対話（human－machine interaction、HMI）システム、テレマティクス制御ユニット（telematics control unit、TCU）、テレマティクスボックス（telematics box、Tbox）、および電子制御ユニットECUなどのコンポーネントを含む。GWは、車両の電子および電気アーキテクチャにおけるコアコンポーネントである。車両のネットワークのデータ交換ハブとして、GWは、異なるネットワークにおいて、コントローラエリアネットワーク（controller area network、CAN）、ローカル相互接続ネットワーク（local interconnect network、LIN）、およびメディア指向システムトランスポート（media oriented system transport、MOST）ネットワークなどのネットワークのデータをルーティングし得る。VCPは、車両の自動運転機能を実現するように構成されてもよい。HMIは、人間と機械との対話情報を表示するように構成されてもよい。TCUおよびTboxは、主として車両の外部デバイス（例えば、携帯電話またはバックグラウンドシステム）と通信するように構成される。ECUは、車両固有のマイクロコンピュータコントローラである。ECUは、車両統合ユニット（vehicle integrated／integration unit、VIU）、コックピットドメインコントローラ（cockpit domain controller、CDC）、車両ドメインコントローラ（vehicle domain controller、VDC）などを含むが、これらに限定されない。例えば、アップグレードされるコンポーネントは、GW、VCP、HMI、TCU、Tbox、およびECUを含むが、これらに限定されず、アップグレードされるコンポーネントは、GW、VCP、HMI、TCU、Tbox、およびECUのうちの1つまたは複数を含んでもよい。

【0056】

車両のOTAアップグレードは、通常、車両内の複数のコンポーネントのアップグレードを含む。インテリジェント車両に配置されたOTA管理モジュールは、コンポーネント、例えば、車両のGWまたはTbox上で動作し、他のコンポーネントのOTAアップグレードモジュールと連携して、車両のアップグレードを共同で完了することができる。図4は、本出願の実施形態が適用可能である別のアップグレードシステムアーキテクチャの概略図である。図4に示されているように、OTA管理モジュールは車両のGWに配置され、OTAアップグレードモジュールは車両の他のコンポーネントに配置される。OTA管理モジュールは、コンポーネントに配置されたOTAアップグレードモジュールと連携して、車両のOTAアップグレードを共同で完了することができる。

【0057】

端末デバイスがアップグレードタスクを実施するプロセスでは、端末デバイスに含まれる元のソフトウェアまたはハードウェア機能は利用できない状態にあり、安全上の問題を引き起こす可能性がある。一例として、インテリジェント車両が使用される。アップグレードタスクがインテリジェント車両の電源に対応するアップグレードタスクを含む場合、インテリジェント車両がアップグレードタスクを実施すると、インテリジェント車両内の他の電子制御ユニットECUの電源がオフになり、ECUが担当するさらなる車載コンポーネントが一時的に故障する。例えば、電源に対応するアップグレードタスクが実施されると、エアバッグを担当する関連ECUの電源がオフになり、エアバッグが一時的に故障する。この場合、インテリジェント車両に運転者または搭乗者が存在し、衝突が発生すると、エアバッグの一時的な故障が車両内の運転者または搭乗者の傷害の原因となる。

【0058】

これを踏まえ、本出願の一実施形態は、アップグレード方法を提供する。本方法では、端末デバイスは、第1のアップグレードタスクを受信し、第1のアップグレードタスクが第1の実施条件に対応し、第1の実施条件に基づいて端末デバイスの第1の状況を取得し、第1の状況が第1の生体認識結果を含み、第1の状況に対応する第1の動作を実行する。このようにして、異なる第1の生体認識結果に基づいて異なる第1の動作を実行することができ、その結果、安全性が保証されたときにアップグレードタスクが実施される。

【0059】

特定の実施形態を参照して、以下では、本出願のこの実施形態で提供されるアップグレード方法を説明する。説明を明確にするために、以下の実施形態では、説明のための例としてOTA管理モジュールが使用されることに留意されたい。あるいは、OTA管理モジュールは端末デバイスと置き換えられてもよい。図5は、本願における実施形態による、アップグレード方法に対応する概略的なフローチャートである。さらに、本方法は、図1から図4に示すアップグレードシステムアーキテクチャに基づいて実現することができる。本方法は以下のステップを含み得る。

【0060】

S501：サーバは、第1のアップグレードタスクを生成する。

【0061】

第1のアップグレードタスクは第1の実施条件に対応し、第1の実施条件は端末デバイスの状況を含み、端末デバイスの状況は端末デバイスに生物が存在しないことを含む。

【0062】

本出願のこの実施形態では、サーバは、アップグレードタスクを作成し、アップグレードタスクを管理することができ、アップグレードタスクを展開すること、アップグレードタスクを終了すること、アップグレードタスクを中断すること、アップグレードタスクを再実行すること、複数のアップグレードタスクの優先度を決定することなどを含む。例えば、サーバによってアップグレードタスクを生成することは、サーバによってアップグレードタスクを作成することとして理解することができる。アップグレードタスクは、1つまたは複数のアップグレードパッケージを含んでもよい。

【0063】

一例として、車両が使用される。アップグレードタスクは、アップグレードされるべき車両の1つまたはバッチのアップグレードプロセスを指定する。例えば、アップグレードタスクは、一般に、車両または車両のバッチ内のどの車載デバイスをアップグレードする必要があるか、アップグレード前にユーザにどの通知を送信する必要があるか、ユーザにどのプロンプトを与える必要があるか、およびアップグレードにどのアップグレードパッケージが使用されるかを指定する。さらに、車載デバイスは、HMI、電池管理システム（battery management system、BMS）、インフォテインメントシステム、車載パワーモジュールなどを含んでもよい。これは本出願の実施形態では限定されない。

【0064】

例えば、異なるアップグレードタスクは、異なる機能に対応し得る。一例として、インテリジェント車両が使用される。アップグレードタスク1は、BMSをアップグレードするために使用され、アップグレードタスク2は、コックピットおよび座席のメモリ機能を改善するために使用され、それによってより良いユーザ体験を提供する。

【0065】

例えば、異なるアップグレードタスクは、異なるアップグレードオブジェクトに対応し得る。一例として、インテリジェント車両が使用される。アップグレードタスク3はファームウェアオーバーザエア（firmware over the air、FOTA）に対応し、アップグレードタスク4はソフトウェアオーバーザエア（software over the air、SOTA）に対応する。FOTAアップグレードは、ハードウェア、例えば、ECUのフラッシュメモリ用の完全なイメージのダウンロードまたは既存のファームウェアの修復またはフラッシュメモリの更新を含む。SOTAは、アプリケーションソフトウェアのアップグレード、例えば、インテリジェント車両上のHMIインターフェースの表示の更新に焦点を合わせている。

【0066】

本出願のこの実施形態では、第1のアップグレードタスクはアップグレードタスクの一例であることを理解されたい。

【0067】

任意選択の設計では、第1のアップグレードタスクは、第1のアップグレードタスクに対応するアップグレードパッケージをさらに含んでもよい。これに対応して、サーバによって第1のアップグレードタスクを生成するステップは、対応するアップグレードパッケージを生成するステップをさらに含んでもよい。

【0068】

本出願のこの実施形態では、第1のアップグレードタスクが第1の実施条件に対応することは、第1のアップグレードタスクを実施するために第1の実施条件が満たされる必要があることを含んでもよい。言い換えると、第1のアップグレードタスクは、第1の実施条件が満たされたときにのみ実施される。

【0069】

本出願のこの実施形態では、第1の実施条件は、端末デバイスの状況を含む。

【0070】

可能な実装形態では、端末デバイスの状況は、端末デバイスに生物が存在しないことを含む。例えば、この場合、第1のアップグレードタスクは、第1のアップグレードタスクに対応する端末デバイスに生物が存在しない場合にのみ実施される。さらに、任意選択の設計では、端末デバイスの状況は、端末デバイスの走行速度が定義されたまたは構成された第1の閾値未満である（例えば、端末デバイスの走行速度は0である）こと、端末デバイスの電気量が定義されたまたは構成された第2の閾値以上であること、端末デバイスの車両ギアがパーキングギアであること、および端末デバイスが位置する領域が安全であることのうちの1つまたは複数をさらに含んでもよい。

【0071】

別の可能な実装形態では、端末デバイスの状況は、端末デバイスの属性を含んでもよい。例えば、第1の実施条件が端末デバイスの属性を含む場合、第1のアップグレードタスクは、第1のアップグレードタスクに対応する端末デバイスの属性が事前設定条件を満たす場合にのみ実施される。例えば、端末デバイスは、生物を含む。この場合、第1のアップグレードタスクを実施することができるかどうかは、端末デバイス内の生物の状況に基づいて決定される必要がある。例えば、第1のアップグレードタスクは、端末デバイス内の生物の状況が事前設定条件を満たすときにのみ実施される。さらに、任意選択の設計では、端末デバイスの状況は、走行速度、電気量、車両ギア、および端末デバイスが位置する領域のうちの1つまたは複数をさらに含んでもよい。端末デバイスの異なる属性に対応する事前設定条件は異なることを理解されたい。加えて、事前設定条件は、プロトコルで定義されてもよく、端末デバイスのためにサーバによって事前構成されてもよく、または別の方式で実現されてもよい。これは特に限定されない。

【0072】

本出願のこの実施形態では、端末デバイスに存在する生物は、運転者、搭乗者、およびペットのうちの1つまたは複数を含んでもよい。

【0073】

任意選択の設計では、第1のアップグレードタスクは、複数のアップグレードサブタスクを含んでもよい。例えば、サーバは、アップグレードタスクに対応するアップグレードコンポーネントに基づいて、1つのアップグレードタスクに含まれる特定のタスクを分類することができ、例えば、アップグレードタスク内のバッテリソフトウェアのためのアップグレードタスクをサブタスクとして使用し、アップグレードタスクに含まれるブレーキ制御ソフトウェアのためのアップグレードタスクを別のサブタスクとして使用することができる。別の例として、サーバは、アップグレードタスクによって実装された機能に基づいて、1つのアップグレードタスクに含まれる複数のサブタスクを分類することができ、例えば、アップグレードタスクにおける自動運転知覚機能のためのアップグレードタスクを1つのサブタスクとして使用し、アップグレードタスク内の、自動運転計画機能に対応するタスクを別のサブタスクとして使用することができる。あるいは、サーバは、別の規則に従って、第1のアップグレードタスクに含まれる特定のタスクを異なるアップグレードサブタスクに分類することができる。

【0074】

例えば、第1のアップグレードタスクが第1のアップグレードサブタスクを含み、第1のアップグレードサブタスクがバイオセーフティ関連コンポーネントのアップグレードに対応する。バイオセーフティ関連コンポーネントは、端末デバイスに含まれる。例えば、バイオセーフティ関連コンポーネントは、インテリジェント車両内のコンポーネントである。本出願のこの実施形態では、任意選択の設計では、バイオセーフティ関連コンポーネントは、バイオセーフティに直接的または間接的に影響を及ぼすコンポーネントとして理解することができる。例えば、バイオセーフティ関連コンポーネントは、車両内の運転者または搭乗者の安全を保護するために使用されるシステムもしくはコンポーネント（例えば、エアバッグシステムまたはコンポーネント）、および車両内の電源システムもしくはコンポーネントのうちの1つまたは複数を含んでもよい。事故が発生したとき（例えば、車両に衝突が発生した場合）、エアバッグシステムまたはコンポーネントは、車両内の運転者または搭乗者の安全を保護することができることを理解されたい。したがって、エアバッグシステムまたはコンポーネントは、バイオセーフティに直接影響を及ぼすコンポーネントと考えることができる。車両内の電源システムまたはコンポーネントは、車両内のECUへの電力供給に影響を及ぼす。例えば、電源システムまたはコンポーネントが故障している場合、車両内の他のECUは電源オフのために利用できない。したがって、電源システムまたはコンポーネントは、バイオセーフティに間接的に影響を及ぼすコンポーネントと考えることができる。加えて、第1のアップグレードサブタスクは、FOTAまたはSOTAに対応し得る。これは、本出願の実施形態では特に限定されない。

【0075】

可能な実装形態では、第1のアップグレードサブタスクに加えて、第1のアップグレードタスクは、別のアップグレードサブタスクをさらに含んでもよい。例えば、第1のアップグレードサブタスクは、車載パワーモジュールのアップグレードに対応し、別のアップグレードサブタスクは、インテリジェント車両上のHMIインターフェースの表示に対する更新に対応する。別の可能な実装形態では、第1のアップグレードタスクは、代替的に、第1のアップグレードサブタスクのみを含むことができ、または第1のアップグレードタスクは、バイオセーフティ関連コンポーネントのアップグレードに対応するアップグレードタスクである。本出願のこの実施形態では、第1のアップグレードタスクに含まれる特定のアップグレード内容に基づいて、第1のアップグレードタスクは1つまたは複数の異なる実施条件に対応することができることを理解されたい。1つまたは複数の異なる実施条件は、第1の実施条件に含まれると理解することができる。

【0076】

S502：サーバは、第1のアップグレードタスクをOTA管理モジュールに送信する。

【0077】

これに対応して、OTA管理モジュールは、第1のアップグレードタスクを受信する。さらに、任意選択の設計では、第1のアップグレードタスクは、アップグレードパッケージを含む。

【0078】

任意選択の設計では、本出願のこの実施形態におけるアップグレード方法は、ステップS503およびステップS504をさらに含んでもよい。このステップは、いくつかの特定のシナリオでは必須であり得る。詳細は以下の通りである。

【0079】

S503：サーバは、第1の実施条件を構成する。

【0080】

例えば、サーバは、第1のアップグレードタスクの内容に基づいて、第1のアップグレードタスクに対応する第1の実施条件を構成する。第1のアップグレードタスクが第1のアップグレードサブタスクを含むことを識別した場合、サーバは、第1の実施条件が端末デバイスの状況を含み、端末デバイスの状況が、端末デバイスに生物が存在しないことを含むと決定する。端末デバイスの状況については、ステップS501の関連説明を参照されたい。ここでは詳細を繰り返さない。

【0081】

S504：サーバは、第1の実施条件を送信する。

【0082】

これに対応して、OTA管理モジュールは、第1の実施条件を受信する。

【0083】

サーバは、送信用の同じシグナリングに第1のアップグレードタスクおよび第1の実施条件を含むことができ、または異なるシグナリングを使用して第1のアップグレードタスクおよび第1の実施条件を別々に送信することができることを理解されたい。

【0084】

S505：OTA管理モジュールは、第1のアップグレードタスクに対応する第1の実施条件に基づいて、端末デバイスの第1の状況を取得する。

【0085】

第1の状況は、第1の生体認識結果を含む。

【0086】

例えば、第1のアップグレードタスクを受信した後、OTA管理モジュールは、第1のアップグレードタスクに対応する第1の実施条件を決定することができ、第1の実施条件は、端末デバイスの状況を含む。これに基づいて、第1のアップグレードタスクを実施する前に、OTA管理モジュールは、端末デバイスの第1の状況を最初に取得する必要がある。例えば、端末デバイスの状況が、端末デバイスに生物が存在しないことを含む場合、第1のアップグレードタスクを実施する前に、OTA管理モジュールは、端末デバイスの第1の状況を最初に取得する必要がある。第1の状況は、第1の生体認識結果を含み、第1の生体認識結果は、端末デバイスに生物が存在すること、または端末デバイスに生物が存在しないことを含む。ステップS501で説明した端末デバイスの状況の別の実装形態に対応して、すなわち、端末デバイスの状況は端末デバイスの属性を含み、OTA管理モジュールは、同様の方式で、属性に対応する第1の状況を取得することができることを理解されたい。例えば、端末デバイスが、生物を含む場合、第1のアップグレードタスクを実施する前に、OTA管理モジュールは、端末デバイスの第1の状況を最初に取得する必要がある。第1の状況は、第1の生体認識結果を含み、第1の生体認識結果は、端末デバイスに生物が存在すること、または端末デバイスに生物が存在しないことを含む。

【0087】

例えば、本出願のこの実施形態では、OTA管理モジュールは、端末デバイスのセンサを使用して第1の生体認識結果を取得することができる。例えば、OTA管理モジュールは、センサからのデータを処理して、第1の生体認識結果を取得する。別の例として、センサからのデータは、第1の生体認識結果を直接識別することができる。これに基づいて、OTA管理モジュールは、第1の生体認識結果を直接取得することができる。OTA管理モジュールは、代替的に、別の方式で第1の生体認識結果を取得してもよいことを理解されたい。これは本出願の実施形態では限定されない。加えて、本出願のこの実施形態では、センサは、カメラ、圧力センサ、ミリ波レーダセンサ、Lidar、または別の形態のセンサのうちの1つまたは複数を含む。センサは、端末デバイスの内部にインストールされてもよいし、端末デバイスの外部にインストールされてもよい。センサの具体的な形態およびインストール場所は、本出願の実施形態では特に限定されない。

【0088】

加えて、さらに、任意選択の設計では、例えば、端末デバイスの状況が、端末デバイスの走行速度が定義されたまたは構成された第1の閾値未満であることをさらに含む場合、これに対応して、第1の状況は、第1の走行速度結果をさらに含み、第1の走行速度結果は、端末デバイスの走行速度が第1の閾値未満であること、または端末デバイスの走行速度が第1の閾値以下であることを含む。別の例として、端末デバイスの状況が、端末デバイスの電気量が第2の閾値以上であることをさらに含む場合、これに対応して、第1の状況は、第1の電気量結果をさらに含み、第1の電気量結果は、端末デバイスの電気量が第2の閾値未満であること、または端末デバイスの電気量が第2の閾値以上であることを含む。さらに別の例として、端末デバイスの状況が、端末デバイスの車両ギアがパーキングギアであることをさらに含む場合、これに対応して、第1の状況は、第1のギア結果をさらに含み、第1のギア結果は、端末デバイスのギアがパーキングギアであること、またはパーキングギアではないことを含む。さらに別の例として、端末デバイスの状況が、端末デバイスが位置する領域が安全であることをさらに含む場合、これに対応して、第1の状況は、第1の領域識別結果をさらに含み、第1の領域識別結果は、端末デバイスが位置する領域が安全または安全でないことを含む。端末デバイスの状況が属性を使用して実現される場合、例えば、端末デバイスの状況が、以下、すなわち、走行速度、電気量、車両ギア、および端末デバイスが位置する領域のうちの1つまたは複数をさらに含む場合、OTA管理モジュールは、前述の方式と同様の方式で、属性に対応する第1の状況を取得することができることを理解されたい。

【0089】

S506：第1の状況に対応する第1の動作を実行する

【0090】

本出願のこの実施形態では、異なる第1の生体認識結果に対応して、OTA管理モジュールは、異なる第1の動作を実行する。説明を明確にするために、以下では、第1の生体認識結果の異なる場合におけるOTA管理モジュールの異なる動作を具体的に説明する。

【0091】

ケース1：第1の生体認識結果は、端末デバイスに生物が存在しないことである。

【0092】

この場合、OTA管理モジュールによって、第1の状況に対応する第1の動作を実行するステップは、OTA管理モジュールによって、第1のアップグレードタスクを実施するステップを含んでもよい。第1の生体測定結果が、端末デバイスに生物が存在しないというものである場合、端末デバイスの現在の状況が第1の実施条件を満たすことを示し得ることを理解されたい。したがって、この場合、OTA管理モジュールは、第1のアップグレードタスクを実施することができる。例えば、車載カメラを使用することにより、OTA管理モジュールは、車両が運転者または搭乗者を含まないと決定するか、または車両が運転者、搭乗者、またはペットを含まないと決定し、次いで第1のアップグレードタスクを実施することができる。

【0093】

第1のアップグレードタスクを実施するプロセスでは、車載コンポーネントが一時的に故障する可能性がある、例えば、エアバッグシステムが一時的に故障する可能性があることを理解されたい。したがって、このようにして、端末デバイスに生物が存在しないと決定された場合にのみ、第1のアップグレードタスクの実施を開始することができる。これに基づいて、第1のアップグレードタスクに含まれるアップグレードパッケージは、安全性（特に個人の安全性）が保証された環境にインストールすることができ、すなわち、安全なOTAアップグレードが実現される。

【0094】

加えて、例えば、OTA管理モジュールが第1のアップグレードタスクを実施することは、以下を含むことができる：OTA管理モジュールは、第1のアップグレードタスクに含まれるアップグレードパッケージを対応するOTAアップグレードモジュールに配布することができ、次いで、OTAアップグレードモジュールは、アップグレードパッケージの特定のインストールを担当する、または、OTA管理モジュールは、アップグレードパッケージの特定のインストールを直接担当する。例えば、第1のアップグレードタスクは、車載パワーモジュールのアップグレードに対応するアップグレードパッケージを含む。OTA管理モジュールは、パワーモジュールのアップグレードを担当するOTAアップグレードモジュール（例えば、車体制御モジュール（body control module、BCM））にアップグレードパッケージを送信することができ、アップグレードモジュールは、アップグレードパッケージのインストールを担当する、または、OTA管理モジュールは、車載パワーモジュールのアップグレードに対応するアップグレードパッケージを直接インストールすることができる。

【0095】

さらに、任意選択の設計では、OTA管理モジュールは、以下の方式のうちの1つ以上で、OTAアップグレードタスクが安全性（特に個人の安全性）が保証された環境で常に実施されることをさらに保証することができる。例えば、第1のアップグレードタスクを実施するプロセスにおいて、OTA管理モジュールは、以下の方式のうちの1つ以上でOTAアップグレードの安全性を保証することができる。

【0096】

方式1：端末デバイスのドアロックをロック状態に制御し、および／または第2のプロンプトを出力する。

【0097】

ここでの端末デバイスは、第1のアップグレードタスクに対応する端末デバイスである。

【0098】

例えば、OTA管理モジュールは、端末デバイスのドアロックをロック状態に制御することができる。このようにして、端末デバイスの外部の人は端末デバイスに入ることができないことを理解されたい。さらに、任意選択の設計では、OTA管理モジュールは、ある期間内に端末デバイスのドアロックをロック状態に制御することができる。例えば、第1のアップグレードタスクの実施が完了すると、OTA管理モジュールは、端末デバイスのドアロックをロック状態に制御しなくてもよい。この場合、端末デバイスの外部の人は、端末デバイスに入ることができ、例えば、車両のロックを開くことによって端末デバイスに入ることができる。

【0099】

任意選択の設計では、OTA管理モジュールが端末デバイスのドアロックをロック状態に制御することは、以下の方式で実現されてもよい：可能な実装形態では、OTA管理モジュールは、端末デバイスのドアロックをロック状態に直接制御する。別の可能な実装形態では、OTA管理モジュールは、指示情報Aを端末デバイス内の他のコンポーネントに送信し、指示情報Aは、端末デバイスのドアロックがロック状態にあることを示す。指示情報Aを受信した後、他のコンポーネントは、端末デバイスのドアロックをロック状態に制御する。本明細書における他のコンポーネントは、例えば、ドアロックを制御することができる他のコンポーネント（BCMなど）を含むことができる。OTA管理モジュールは、代替的に、別の方式で端末デバイスのドアロックをロック状態に制御することができる。これは特に限定されない。

【0100】

例えば、第2のプロンプトは、第1のアップグレードタスクを実施するプロセスにおいて、端末デバイスの外部の人が端末デバイスに戻ることを許可されないことを示すために出力されてもよい。第2のプロンプトは、端末デバイスに生物が存在しないはずであることを示す。あるいは、第2のプロンプトは、第1のアップグレードタスクが実施されていること、および第1の実施条件の一方または両方を示す。第1のアップグレードタスクは第1の実施条件が満たされたときにのみ実施されるため、第1のアップグレードタスクが実施されていることを示すことによって、または第1の実施条件を示すことによって、第2のプロンプトは、端末デバイスに生物が存在しないはずであることを示すことができることを理解されたい。第2のプロンプトを取得した後、端末デバイスのユーザは、ユーザが端末デバイスに入ることができないことを知る。任意選択の設計では、端末デバイスのユーザは、端末デバイスの所有者、例えば車両所有者として理解することができ、または端末デバイスを離れる運転者および／もしくは搭乗者として理解することができ、または端末デバイスに入ることができる別のユーザとして理解することができる。

【0101】

さらに、任意選択の設計では、第2のプロンプトは、時間情報Tをさらに含むことができ、時間情報Tを満たす時間範囲内で端末デバイスに生物が存在しないはずであることを示す。説明を明確にするために、本明細書では、第2のプロンプトが端末デバイスに生物が存在しないはずであることを示す例が説明のために使用される。例えば、時間情報Tは、第1のアップグレードタスクのインストールを開始してから第1のアップグレードタスクのインストールを完了するまでに要する時間、例えば2時間である。この場合、第2のプロンプトを取得した後、端末デバイスのユーザは、第2のプロンプトが受信された時間（または、第2のプロンプトが送信された時間から開始する、または第1のアップグレードタスクの実施が開始された時間から開始する）から始まって2時間以内は端末デバイスに生物が存在しないはずであると決定することができる。別の例では、時間情報Tは絶対時間であり、絶対時間は、第1のアップグレードタスクのインストールが完了した時間、例えば2：00PMに対応することができる。この場合、第2のプロンプトを取得した後、端末デバイスのユーザは、2：00PMまでは端末デバイスに生物が存在しないはずであると決定することができる。

【0102】

任意選択の設計では、本出願のこの実施形態では、第2のプロンプトを出力するステップは、OTA管理モジュールによって、第2のプロンプトを端末デバイスのユーザに直接出力するステップ、例えば、第2のプロンプトを運転者に直接出力するステップ、または、OTA管理モジュールによって、ネットワークデバイスを使用して第2のプロンプトを端末デバイスのユーザに出力するステップを含んでもよい。

【0103】

任意選択の設計では、第2のプロンプトは、携帯電話、ウェアラブルデバイス、タブレットコンピュータ、およびノートブックコンピュータのうちの1つまたは複数を使用して出力されてもよい。任意選択の設計では、第2のプロンプトは、目立つようにさらに強調表示されてもよい。例えば、プロンプトインターフェース（例えば、携帯電話、ウェアラブルデバイス、タブレットコンピュータ、またはノートブックコンピュータ）では、第2のプロンプトのフォント色は他のアップグレードタスクに対応するプロンプトのフォント色とは異なり、および／または第2のプロンプトのフォントサイズは他のアップグレードタスクに対応するプロンプトのフォントサイズとは異なる。ここで、他のアップグレードタスクは、第1のアップグレードタスク以外のアップグレードタスクであってもよいし、第1の実施条件とは異なる別の実施条件に対応するアップグレードタスクであってもよい。このようにして、端末デバイスのユーザは、第1のアップグレードタスクを安全性が保証された環境で実施することができることを保証するために、第1のアップグレードタスクの実施条件により容易に注意を払うことができる。

【0104】

例えば、本出願のこの実施形態では、安全性が保証された環境でOTAアップグレードが実施されることを保証するために、端末デバイスのドアロックがロック状態になるようにさらに制御され、第2のプロンプトがさらに出力されてもよい。

【0105】

方式1では、車両のロックを閉じること、および／またはプロンプトを出力することによって、第1のアップグレードタスクを実施するプロセスにおいて、端末デバイスの外部の人が端末デバイスに入るのを防ぐことができる。これにより、第1のアップグレードタスクを実施するプロセスにおいて、OTAアップグレードを安全性（特に個人の安全性）が保証された環境で実施することが保証される。さらに、第2のプロンプトが時間情報Tを含む場合、端末デバイスのユーザは、第1のアップグレードタスクの実施が完了した後に時間内に端末デバイスをさらに使用することができる。

【0106】

方式2：端末デバイスのドアロック状況を取得し、および／または端末デバイスの第2の状況を取得し、第1のアップグレードタスクの実施を中断または終了する。

【0107】

ドアロック状況は、ドアロックが開いていることを含む。第2の状況は、第2の生体認識結果を含み、第2の生体認識結果は、端末デバイスに生物が存在することである。

【0108】

例えば、OTA管理モジュールは、端末デバイスのドアロック状況を取得することによって、第1のアップグレードタスクを実施するプロセスにおいて、端末デバイスの外部の人が端末デバイスに入ろうとしているかどうかを決定することができる。例えば、取得されたドアロック状況が、ドアロックが開いていることを含む場合、OTA管理モジュールは、端末デバイスの外部の人が端末デバイスに入ろうとしているか、または端末デバイスに入ったと決定することができ、次いで、OTA管理モジュールは、第1のアップグレードタスクの実施を中断または終了することができる。

【0109】

例えば、OTA管理モジュールは、端末デバイスの第2の状況を取得することによって、第1のアップグレードタスクを実施するプロセスにおいて、端末デバイスの外部の人が端末デバイスに入るどうかを決定することができる。取得された第2の生体測定結果が、端末デバイスに生物が存在することである場合、OTA管理モジュールは、第1のアップグレードタスクの実施を中断または終了することができる。OTA管理モジュールによって端末デバイスの第2の状況を取得することについては、ステップS505でOTA管理モジュールが第1の状況を取得する方式を参照されたい。例えば、OTA管理モジュールは、端末デバイスのセンサを使用して第2の生体認識結果を取得することができる。ここでは詳細を繰り返さない。

【0110】

例えば、OTA管理モジュールは、端末デバイスのドアロック状況を取得し、端末デバイスの第2の状況を取得することによって、第1のアップグレードタスクの実施をさらに中断または終了することができる。ドアロック状況および第2の状況については、前述の説明を参照されたい。ここでは詳細を繰り返さない。

【0111】

さらに、任意選択の設計では、方式2では、OTA管理モジュールが第1のアップグレードタスクの実施を中断または終了した後、端末デバイスは、第1のアップグレードタスクが実施される前の状況に復元することができ、それによって端末デバイスの正常な使用が保証される。

【0112】

方式2では、第1のアップグレードタスクを実施するプロセスにおいて、端末デバイスの外部の人が端末デバイスに入ろうとしているか、または端末デバイスに入ったことが判明すると、第1のアップグレードタスクの実施を中断または終了することができることを理解されたい。このようにして、第1のアップグレードタスクを実施するプロセスにおいて、OTAアップグレードがまた、安全性（特に個人の安全性）が保証された環境で実施される。言い換えれば、OTAアップグレードは、安全性（特に個人の安全性）が保証された環境で常に実施されることが保証される。加えて、方式2では、特別な場合に端末デバイスをさらに使用することができる。例えば、いくつかの特別な場合には、端末デバイスの外部の人は、端末デバイスに再び入る必要があり、例えば、重要な物品または材料を取り出すために端末デバイスに戻る必要がある。別の例では、端末デバイスは、緊急時に再利用される必要がある。この場合、これらのシナリオにおける端末デバイスの正常な使用を、方式2でさらに保証することができる。

【0113】

方法3：端末デバイスのドアロック状況を取得し、および／または端末デバイスの第2の状況を取得し、第1のアップグレードタスクに含まれる第1のアップグレードサブタスクが完了したと決定し、第1のアップグレードタスクを実施し続ける。

【0114】

ドアロック状況および第2の状況については、方式2の具体的な説明を参照されたい。第1のアップグレードサブタスクについては、ステップS501の関連説明を参照されたい。ここでは詳細を繰り返さない。

【0115】

例えば、OTA管理モジュールは、端末デバイスのドアロック状況および／または第2の状況に基づいて、第1のアップグレードタスクを実施するプロセスにおいて、端末デバイスの外部の人が端末デバイスに入ろうとしているか、または端末デバイスに入ったかを決定することができる。しかしながら、この場合、バイオセーフティ関連コンポーネントに対応するアップグレードが完了している場合、OTA管理モジュールは、第1のアップグレードタスクを実施し続けることができる。例えば、第1のアップグレードタスクは、車載パワーモジュールのアップグレードに対応するアップグレードタスク（第1のアップグレードサブタスク）と、インテリジェント車両上のHMIインターフェースの表示に対する更新に対応するアップグレードタスク（別のアップグレードサブタスク）と、を含む。方式3では、OTA管理モジュールが、ドアロック状況および／または第2の状況に基づいて、端末デバイスの外部の人が端末デバイスに入ろうとしているか、または端末デバイスに入ったが、この場合、車載パワーモジュールのアップグレードに対応するアップグレードタスクが完了していると判定した場合、OTA管理モジュールは、第1のアップグレードタスクを中断または終了せず、インテリジェント車両上のHMIインターフェースの表示への更新に対応するアップグレードタスクを実施し続けることができる。第1のアップグレードサブタスクが完了していない場合、OTA管理モジュールは、第1のアップグレードタスクの実施を中断または終了することができることを理解されたい。

【0116】

方式3では、バイオセーフティ関連コンポーネントに対応するアップグレードタスクが、他のアップグレードタスクの実施に影響を及ぼすことなく、安全性が保証された環境で実施することができることを保証することができる。これにより、アップグレードタスクの実施効率が保証される。

【0117】

本出願のこの実施形態では、OTAアップグレードの安全性は、前述の方式1から方式3の組み合わせを使用して代替的に実装されてもよいことに留意されたい。例えば、第1のアップグレードタスクを実施するプロセスにおいて、OTAアップグレードがまた、安全性（特に個人の安全性）が保証された環境で実施される。例えば、OTA管理モジュールは、方式1において、第1のアップグレードタスクを実施するプロセスにおいて、端末デバイスの外部の人が端末デバイスに入るのを防ぐことができる。しかしながら、第1のアップグレードタスクを実施するプロセスにおいて、端末デバイスの外部の人が端末デバイスに入った場合、OTA管理モジュールは、方法2を参照して、第1のアップグレードタスクの実施をさらに中断または終了することができる。これにより、OTAアップグレードが常に安全性（特に個人の安全性）が保証された環境で実施されることを保証することができ、第1のアップグレードタスクが完了していないときに端末デバイスの正常な使用を実現することができる。あるいは、第1のアップグレードサブタスクが完了したと決定した場合、OTA管理モジュールは、方法3を参照して、第1のアップグレードタスクに含まれる他のアップグレードタスクを実施し続けることができる。これにより、OTAアップグレードが常に安全性（特に個人の安全性）が保証された環境で実施されることを保証することができ、また、アップグレードタスクの実施効率を保証することができる。

【0118】

ケース2：第1の生体認識結果は、端末デバイスに生物が存在することである。

【0119】

この場合、OTA管理モジュールによって、第1の状況に対応する第1の動作を実行するステップは、第1のアップグレードタスクの実施をスキップするステップおよび／またはOTA管理モジュールによって第1のプロンプトを出力するステップであって、第1のプロンプトが、第1のアップグレードタスクを実施することができないことを示す、ステップを含んでもよい。端末デバイスが依然として生物を含む場合、それは第1のアップグレードタスクに対応する第1の実施条件が満たされないことを示すことを理解されたい。この場合、第1のアップグレードタスクの実施をスキップすることにより、端末デバイスにおける生物の安全性を保証することができる。加えて、端末デバイスのユーザは、第1のプロンプトを出力することによって、第1のアップグレードタスクの実施状況を知ることができる。

【0120】

さらに、任意選択の設計では、第1のプロンプトは、第1のアップグレードタスクを実施することができない理由および／または第1のアップグレードタスクを再実施するための条件をさらに示すことができる。例えば、第1のプロンプトは、端末デバイスに生物が存在しないことが保証されるときに第1のアップグレードタスクが実施される必要があることをさらに示すことができる。端末デバイスのユーザは、プロンプトを使用することにより、第1のアップグレードタスクを実施するために必要な条件を知ることができる。このようにして、ユーザが第1のアップグレードタスクを実施することを決定する前に、端末デバイスが生物を含まないことを保証することができる。例えば、端末デバイス内のすべての人員および／またはペットが端末デバイスを離れる。このプロンプト方式で、安全なOTAアップグレードを実現することができる。

【0121】

本出願のこの実施形態では、第1のアップグレードタスクを実施することができない理由および／または第1のアップグレードタスクを再実施するための条件を示す情報は、第1のプロンプトを使用して実現されてもよく、または別の方式で実現されてもよく、例えば、第3のプロンプトを使用して実現されてもよいことに留意されたい。これは本出願の実施形態では限定されない。

【0122】

任意選択の設計では、本出願のこの実施形態では、第1のプロンプトを出力するステップは、OTA管理モジュールによって、第1のプロンプトを端末デバイスのユーザに直接出力するステップ、例えば、第1のプロンプトを運転者に直接出力するステップ、または、OTA管理モジュールによって、ネットワークデバイスを使用して第1のプロンプトを端末デバイスのユーザに出力するステップを含んでもよい。

【0123】

【0124】

第3のプロンプトの実装形態については、第1のプロンプトの実装形態を参照されたいことを理解されたい。ここでは詳細を繰り返さない。

【0125】

任意選択の設計では、第1のプロンプトまたは第3のプロンプトは、目立つようにさらに強調表示されてもよい。例えば、プロンプトインターフェース（例えば、HMIインターフェース、携帯電話、ウェアラブルデバイス、タブレットコンピュータ、またはノートブックコンピュータ）では、第1のプロンプトもしくは第3のプロンプトのフォント色は他のアップグレードタスクに対応するプロンプトのフォント色とは異なり、および／または第1のプロンプトもしくは第3のプロンプトのフォントサイズは他のアップグレードタスクに対応するプロンプトのフォントサイズとは異なる。ここで、他のアップグレードタスクは、第1のアップグレードタスク以外のアップグレードタスクであってもよいし、第1の実施条件とは異なる別の実施条件に対応するアップグレードタスクであってもよい。このようにして、端末デバイスのユーザは、第1のアップグレードタスクの実施条件および実施状況により容易に注意を払うことができ、第1のアップグレードタスクを実施することができる条件をより迅速に知ることができ、第1のアップグレードタスクを安全性が保証された環境で実施することができることを保証することができる。

【0126】

任意選択の設計では、本出願のこの実施形態におけるアップグレード方法は、ステップS505の前にステップS507をさらに含んでもよい。このステップは、いくつかの特定のシナリオでは必須であり得る。ステップS507は、具体的には以下の通りである。

【0127】

S507：第4のプロンプトを出力する。

【0128】

第4のプロンプトは、第1の実施条件を示す。

【0129】

任意選択の設計では、本出願のこの実施形態では、第4のプロンプトを出力するステップは、OTA管理モジュールによって、第1のプロンプトを端末デバイスのユーザに直接出力するステップ、例えば、第4のプロンプトを運転者に直接出力するステップ、または、OTA管理モジュールによって、ネットワークデバイスを使用して第4のプロンプトを端末デバイスのユーザに出力するステップを含んでもよい。

【0130】

任意選択の設計では、第4のプロンプトは、携帯電話、ウェアラブルデバイス、タブレットコンピュータ、ノートブックコンピュータ、およびHMIインターフェースのうちの1つまたは複数を使用して出力されてもよい。

【0131】

任意選択の設計では、第4のプロンプトは、目立つようにさらに強調表示されてもよい。例えば、プロンプトインターフェース（例えば、HMIインターフェース、携帯電話、ウェアラブルデバイス、タブレットコンピュータ、またはノートブックコンピュータ）では、第4のプロンプトのフォント色は他のアップグレードタスクに対応するプロンプトのフォント色とは異なり、および／または第4のプロンプトのフォントサイズは他のアップグレードタスクに対応するプロンプトのフォントサイズとは異なる。ここで、他のアップグレードタスクは、第1のアップグレードタスク以外のアップグレードタスクであってもよいし、第1の実施条件とは異なる別の実施条件に対応するアップグレードタスクであってもよい。このようにして、端末デバイスのユーザは、第1のアップグレードタスクの実施条件により容易に注意を払うことができ、第1のアップグレードタスクを実施することができる条件をより迅速に知ることができ、第1のアップグレードタスクを安全性が保証された環境で実施することができることを保証することができる。

【0132】

さらに、任意選択の設計では、OTA管理モジュールは、端末デバイスのユーザ設定に基づいて、第4のプロンプトに応答した確認情報Bに基づいて端末デバイスの第1の状況の取得を開始するかどうかをさらに決定することができる。任意選択の設計では、アップグレードタスクが実施される前に端末デバイスのユーザによって確認される必要があるかどうかは、端末デバイスのユーザによって事前設定されてもよい。説明を明確にするために、本明細書では、運転者が端末デバイスのユーザである例が説明のために使用される。アップグレードタスクの場合、運転者は、情報Bに基づいてアップグレードタスクを実施するかどうかを事前設定することができる。例えば、運転者は、携帯電話で、確認情報Bに対応する設定またはアップグレードタスクに対応する設定を有効にすることができる。この場合、第1のアップグレードタスクを受信し、第1のアップグレードタスクに関連するアクションを実行する前に、OTA管理モジュールは、運転者の確認情報（確認情報Bに対応する）を最初に取得する必要がある。ここで、第1のアップグレードタスクに関連する動作は、端末デバイスの第1の状況を取得すること、および／または第1のアップグレードタスクを実施することを含んでもよい。具体的には、第4のプロンプトが出力された後、OTA管理モジュールは、運転者の確認が得られた後にのみ端末デバイスの第1の状況を取得することができる（例えば、確認は、携帯電話のアプリケーション（application、APP）を使用して実現される）。別の例では、運転者は、携帯電話上で、情報Bに対応する設定またはアップグレードタスクに対応する設定を無効にすることができる。この場合、第1のアップグレードタスクを受信し、第1のアップグレードタスクに関連するアクションを実行する前に、OTA管理モジュールは、運転者の確認情報（確認情報Bに対応する）を取得する必要がない。具体的には、第4のプロンプトを出力した後、OTA管理モジュールは、第1のアップグレードタスクに関連するアクションの実行を開始することができ、例えば、端末デバイスの第1の状況を取得することができる。このようにして、OTAアップグレードの柔軟性を実現することができる。さらに、第4の情報に対応する確認情報に基づいてアップグレードタスクに関連付けられた動作が実行される必要があると指定された場合、端末デバイスのユーザは、適切なシナリオで第1のアップグレードタスクの実施の開始を選択することができる。これにより、端末デバイスの正常な使用を保証することができ、OTAアップグレードを安全な環境で実施することを保証することができる。具体的には、例えば、端末デバイスが使用されているとき、端末デバイスのユーザは、受信した第4のプロンプトを確認しない場合がある。この場合、第1のアップグレードタスクは一時的に実施されない。端末デバイスのユーザが、第1のアップグレードタスクを実施することができると決定した場合、端末デバイスのユーザは、受信した第4のプロンプトを確認することができる。この場合、OTA管理モジュールは、端末デバイスの第1の状況の取得を開始することができる。

【0133】

任意選択の設計では、本出願のこの実施形態におけるアップグレード方法は、ステップS505の前にステップS508をさらに含んでもよい。このステップは、いくつかの特定のシナリオでは必須であり得る。ステップS508は、具体的には以下の通りである。

【0134】

S508：第1の実施条件を決定する。

【0135】

一実装態様では、OTA管理モジュールは、サーバから第1の実施条件を受信し、第1の実施条件を決定する。

【0136】

別の実装形態では、OTA管理モジュールは、アップグレードタスクと実施条件との間のマッピング関係に基づいて第1の実施条件を決定する。例えば、マッピング関係は、構成または定義されてもよい。例えば、OTAサーバは、マッピング関係を構成または定義し、マッピング関係を事前にOTA管理モジュールに送信することができる。第1のアップグレードタスクを受信した後、OTA管理モジュールは、マッピング関係に基づいて、第1のアップグレードタスクに対応する第1の実施条件を決定することができる。例えば、OTA管理モジュールは、第1のアップグレードタスクに含まれる内容に基づいて、マッピング関係を参照して第1の実施条件を決定することができる。このようにして、シグナリングオーバーヘッドが低減されることができる。

【0137】

前述の説明に基づいて、本出願のこの実施形態に示される方式では、第1のアップグレードタスクが実施される前に、第1の生体認識結果を含む第1の状況が取得され、第1の状況に対応する第1の動作が異なる第1の生体認識結果に基づいて実行され、その結果、安全なOTAアップグレードを実現することができる。言い換えれば、OTAアップグレードは、安全性（特に個人の安全性）が保証された環境で実施することができることが保証される。

【0138】

本出願の実施形態の方法に含まれるステップの順序は調整されてもよく、または実際の要件に応じてステップは組み合わされても削除されてもよいことに留意されたい。

【0139】

以上、図5を参照して、本出願の実施形態で提供されるアップグレード方法を説明した。以下、図6～図8を参照して、本出願の実施形態で提供される装置について詳細に説明する。

【0140】

図6は、本出願の一実施形態による通信装置の概略ブロック図である。図6に示されているように、通信装置は、前述の可能な実装形態のいずれか1つにおける方法を実行するために、少なくとも1つのプロセッサおよび送受信機を含んでもよい。少なくとも1つのプロセッサは、装置の内部処理を実行する、例えば、第1の実施条件に基づいて端末デバイスの第1の状況を取得する、別の例として、第1のプロンプトを出力し、第1のプロンプトは、第1のアップグレードタスクを実施することができないことを示す、さらに別の例として、第1のアップグレードタスクを実施する、さらに別の例として、第1のアップグレードタスクを生成するように構成されてもよい。送受信機は、例えば、別の装置に情報を送信するか、または別の装置から情報を受信する、送受信に関連する機能を実行するように構成される。

【0141】

さらに、任意選択の設計では、通信装置は、図7の破線のボックスに示すように、少なくとも1つのメモリをさらに含んでもよい。図7は、本出願の一実施形態による通信装置の概略ブロック図である。少なくとも1つのメモリは、通信装置に含まれる少なくとも1つのプロセッサおよび送受信機に結合される。少なくとも1つのメモリ、少なくとも1つのプロセッサ、および送受信機は、内部接続経路を使用することによって互いに通信することが理解され得る。具体的には、少なくとも1つのプロセッサは、少なくとも1つのメモリ内の命令を実施するように構成されてもよく、その結果、装置は、本出願の実施形態における可能な実装形態のうちのいずれか1つの方法を実行する。

【0142】

別の実施態様では、通信装置は、本出願の実施形態における可能な実装形態のいずれか1つの方法を実行するように構成された処理部および送受信部を含む。

【0143】

任意選択の設計では、通信装置は、端末デバイスの装置またはOTA管理モジュールの装置であってもよく、この場合、通信装置は、前述の説明において端末デバイスまたはOTA管理モジュールによって実行される任意の方法を実行するように構成されてもよい。あるいは、通信装置はサーバの装置であってもよく、この場合、通信装置は、前述の説明においてサーバによって実行される任意の方法を実行するように構成されてもよい。

【0144】

任意選択の設計では、通信装置は通信チップであり、送受信機は通信チップの入出力回路またはポートであってもよい。別の任意選択の設計では、通信装置に含まれる送受信機は、送信機および受信機を含んでもよく、または送信セットおよび受信セットを含んでもよい。

【0145】

本出願のこの実施形態では、通信装置は、本出願の実施形態における可能な実装形態のいずれか1つにおける端末デバイスのチップに対応してもよく、または本出願の実施形態における可能な実装形態のいずれか1つにおけるOTA管理モジュールのチップに対応してもよい。

【0146】

本出願の一実施形態は、端末デバイスをさらに提供する。端末デバイスは、OTA管理モジュールによって実行される前述の可能な実装形態のいずれか1つの方法を実行するように構成された通信装置を含む。

【0147】

本出願の一実施形態は、サーバをさらに提供する。サーバは、サーバによって実行される前述の可能な実装形態のいずれか1つの方法を実行するように構成された通信装置を含む。

【0148】

本出願の一実施形態は、通信システムをさらに提供する。通信システムは、OTA管理モジュールによって実行される前述の可能な実装形態のいずれか1つで方法を実行するように構成された通信装置、およびサーバによって実行される前述の可能な実装形態のいずれか1つで方法を実行するように構成された通信装置のうちの1つまたは複数を含む。

【0149】

加えて、図8に示されているように、本出願の実施形態はチップをさらに提供する。図8は、チップの構造の概略図である。チップは、1つまたは複数のプロセッサおよびインターフェース回路を含む。インターフェース回路は、1つまたは複数のプロセッサが前述の可能な実装形態のいずれか1つにおける方法を実行するための情報入力および／または出力を提供するように構成される。任意選択の設計では、チップは、バスをさらに含んでもよい。

【0150】

例えば、プロセッサは、集積回路チップであり、信号処理能力を有する。例えば、プロセッサは、フィールドプログラマブルゲートアレイ（field programmable gate array、FPGA）、汎用プロセッサ、デジタル信号プロセッサ（digital signal processor、DSP）、特定用途向け集積回路（application specific integrated circuit、ASIC）、別のプログラマブルロジックデバイス、ディスクリートゲート、トランジスタロジックデバイス、ディスクリートハードウェアコンポーネント、システムオンチップ（system on chip、SoC）、中央処理装置（central processor unit、CPU）、ネットワークプロセッサ（network processor、NP）、マイクロコントローラ（micro controller unit、MCU）、プログラマブルコントローラ（programmable logic device、PLD）、または別の集積チップであってよい。プロセッサは、本出願の実施形態において開示された方法、ステップ、および論理ブロック図を実現または実行することができる。汎用プロセッサはマイクロプロセッサであり得るか、またはプロセッサは任意の従来のプロセッサなどであり得る。本出願の実施形態を参照して開示された方法のステップは、ハードウェア復号プロセッサによって直接実現されてもよいし、または復号プロセッサ内のハードウェアとソフトウェアモジュールとの組み合わせによって実現されてもよい。ソフトウェアモジュールは、当技術の成熟した記憶媒体、例えば、ランダム・アクセス・メモリ、フラッシュメモリ、読み取り専用メモリ、プログラム可能読み取り専用メモリ、電気的消去可能プログラム可能メモリ、またはレジスタ内にあってもよい。ストレージメディアはメモリに配置され、プロセッサは、メモリから情報を読み取り、プロセッサのハードウェアと組み合わせて上述の方法のステップを完了する。

【0151】

インターフェース回路は、データ、命令、または情報を送信または受信するように構成されてもよい。プロセッサは、インターフェース回路によって受信されたデータ、命令、または他の情報を使用して処理を実行してもよく、インターフェース回路を使用して処理によって得られた情報を送信してもよい。

【0152】

任意選択の設計では、チップはメモリをさらに含み、メモリは揮発性メモリもしくは不揮発性メモリであってもよく、または揮発性メモリおよび不揮発性メモリの両方を含んでもよい。不揮発性メモリは、読み出し専用メモリ（read－only memory、ROM）、プログラム可能読み出し専用メモリ（programmable ROM、PROM）、消去可能プログラム可能読み出し専用メモリ（erasable PROM、EPROM）、電気的消去可能プログラム可能読み出し専用メモリ（electrically EPROM、略してEEPROM）、またはフラッシュメモリであってもよい。揮発性メモリは、ランダム・アクセス・メモリ（random access memory、RAM）であってよく、外部キャッシュとして使用される。限定的な説明ではなく例として、多くの形態のRAMが、例えば、スタティック・ランダム・アクセス・メモリ（static RAM、SRAM）、ダイナミック・ランダム・アクセス・メモリ（dynamic RAM、DRAM）、シンクロナス・ダイナミック・ランダム・アクセス・メモリ（synchronous DRAM、SDRAM）、ダブル・データ・レート・シンクロナス・ダイナミック・ランダム・アクセス・メモリ（double data rate SDRAM、DDR SDRAM）、エンハンスト・シンクロナス・ダイナミック・ランダム・アクセス・メモリ（enhanced SDRAM、ESDRAM）、シンクリンク・ダイナミック・ランダム・アクセス・メモリ（synchlink DRAM、SLDRAM）、およびダイレクト・ラムバス・ランダム・アクセス・メモリ（direct rambus RAM、DR RAM）が、利用可能である。

【0153】

プロセッサおよびインターフェース回路の各々に対応する機能は、ハードウェア設計を使用して実施されてもよく、ソフトウェア設計を使用して実施されてもよく、またはソフトウェアとハードウェアとの組み合わせを使用して実施されてもよいことに留意されたい。これはここでは限定されない。

【0154】

本明細書に記載されたシステムおよび方法のメモリは、これらのメモリおよび任意の他の適切なタイプのメモリを含むことが意図されているが、これらに限定されないことに留意されたい。

【0155】

本出願の一実施形態は、コンピュータプログラム製品をさらに提供する。コンピュータプログラム製品は、コンピュータプログラムコードを含む。コンピュータプログラムコードがコンピュータ上で実行されると、コンピュータは、前述の説明において第1のノードによって実行される可能な実装形態のいずれか1つで方法を実行するか、または前述の説明において第2のノードによって実行される可能な実装形態のいずれか1つで方法を実行することが可能になる。

【0156】

本出願は、コンピュータ可読媒体をさらに提供する。コンピュータ可読媒体はプログラムコードを記憶する。プログラムコードがコンピュータ上で実行されると、コンピュータは前述の可能な実装形態のいずれか1つにおける方法を実行することが可能になる。

【0157】

上記の実施形態の全部または一部はソフトウェア、ハードウェア、ファームウェアまたはこれらの任意の組み合わせを用いて実施されてもよい。ソフトウェアが前述の実施形態を実施するために使用されるとき、前述の実施形態の全部または一部は、コンピュータプログラム製品の形態で実現されてもよい。コンピュータプログラム製品は1つまたは複数のコンピュータ命令を含む。コンピュータ命令がコンピュータにロードされて実施されると、本出願の実施形態による手順または機能が全面的または部分的に生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、または他のプログラマブル装置であってもよい。コンピュータ命令は、コンピュータ可読記憶媒体に記憶されてもよく、またはコンピュータ可読記憶媒体から別のコンピュータ可読記憶媒体に伝送されてもよい。例えば、コンピュータ命令は、あるウェブサイト、コンピュータ、サーバ、またはデータセンタから、他のウェブサイト、コンピュータ、サーバ、またはデータセンタへ、有線方式（例えば、同軸ケーブル、光ファイバ、もしくはデジタル加入者回線（digital subscriber line、DSL））で、または無線方式（例えば、赤外線、電波、もしくはマイクロ波）で伝送されてよい。コンピュータ可読記憶媒体は、コンピュータにとってアクセス可能な任意の使用可能な媒体、または1つ以上の使用可能な媒体を統合したサーバやデータセンタなどのデータ記憶装置であってよい。使用可能な媒体は、磁気媒体（例えば、フロッピーディスク、ハードディスク、磁気テープ）、光媒体（例えば、デジタルビデオディスク（digital video disc、DVD））、半導体媒体（例えば、ソリッドステートドライブ（solid state disk、SSD））などであり得る。

【0158】

本明細書に開示されている実施形態に記載された例と組み合わせて、ユニットおよびアルゴリズムステップが、電子ハードウェア、またはコンピュータソフトウェアと電子ハードウェアとの組み合わせによって実現することができることを当業者は認識し得る。機能がハードウェアとソフトウェアのどちらによって実行されるかは、技術的解決策の特定の用途および設計上の制約に依存する。当業者は、様々な方法を使用して、特定の用途ごとに記載された機能を実装することができるが、その実装形態が本出願の範囲を超えると考えられるべきではない。

【0159】

使いやすく簡潔な説明のために、システム、装置、およびユニットの詳細な作業プロセスについて、本方法の実施形態における対応するプロセスを指すことは、当業者によって明確に理解され得る。ここでは詳細を繰り返さない。

【0160】

本出願で提供されるいくつかの実施形態では、開示されたシステム、装置、および方法は、他の方式で実現されてもよいことを理解されたい。例えば、説明されている装置の実施形態は単なる例である。例えば、ユニットへの分割は、単なる論理的な機能分割にすぎず、実際の実装に際しては他の分割も可能である。例えば、複数のユニットもしくはコンポーネントが組み合わされてもよく、もしくは別のシステムに統合されてもよく、または、一部の機能が無視されるか、もしくは実行されなくてもよい。加えて、表示または考察された相互結合または直接結合または通信接続が、いくつかのインターフェースを介して実装されてもよい。装置間またはユニット間の間接的な結合または通信接続は、電気的形態、機械的形態、または別の形態で実施されてもよい。

【0161】

別個の部分として説明されたユニットは、物理的に別個であってもなくてもよく、ユニットとして提示された部分は物理ユニットであってもなくてもよく、1つの位置に配置されてもよく、または複数のネットワークユニットに分散されてもよい。ユニットの一部またはすべては、実施形態の解決策の目的を達成するために、実際の要件に応じて選択されてもよい。

【0162】

加えて、本出願の実施形態における機能ユニットは、1つの処理部に統合されてもよく、ユニットの各々は、物理的に単独で存在してもよく、または少なくとも2つのユニットが1つのユニットに統合されてもよい。

【0163】

前述の説明は、本出願の特定の実施態様にすぎず、本出願の保護範囲を限定することが意図されるものではない。本出願に開示されている技術的範囲内で当業者によって容易に考え出されるいかなる変形または置換も、本出願の保護範囲内にあるものとする。したがって、本出願の保護範囲は、特許請求の範囲の保護範囲に従うものとする。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【手続補正書】

【提出日】2024-03-05

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】