特表2022-535631異なるオペレーティングシステムのアプリケーション間で再利用可能なコードを有効にするためのシステムおよび方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2022-08-10
(54)【発明の名称】異なるオペレーティングシステムのアプリケーション間で再利用可能なコードを有効にするためのシステムおよび方法
(51)【国際特許分類】
G06F 15/00 20060101AFI20220803BHJP
G06F 8/36 20180101ALI20220803BHJP
【ＦＩ】
G06F15/00 470
G06F8/36
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2021509897
(86)(22)【出願日】2019-09-12
(85)【翻訳文提出日】2021-04-19
(86)【国際出願番号】 US2019050873
(87)【国際公開番号】W WO2020041804
(87)【国際公開日】2020-02-27
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＢＬＵＥＴＯＯＴＨ
(71)【出願人】
【識別番号】518238621
【氏名又は名称】ジーボ インコーポレーテッド
【氏名又は名称原語表記】ＸＥＶＯ ＩＮＣ．
【住所又は居所原語表記】１０９００ ＮＥ ８ｔｈ Ｓｔｒｅｅｔ， Ｓｕｉｔｅ ８００， Ｂｅｌｌｅｖｕｅ， ＷＡ ９８００４ Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】110002664
【氏名又は名称】特許業務法人ナガトアンドパートナーズ
(72)【発明者】
【氏名】ハーター， グレン アール．
(72)【発明者】
【氏名】スペア， ジュニア， スティーブン ケー．
【テーマコード（参考）】
5B376
【Ｆターム（参考）】
5B376BC11
5B376BC23
5B376FA13
(57)【要約】
異なるオペレーティングシステムのアプリケーション間で再利用可能なコードセクションの使用を可能にするための方法およびシステム。第１のオペレーティングシステム（「ＯＳ」）用に設計された第１のアプリケーションの場合、第１のネイティブコードセクションおよび再利用可能なコードセクションは、第１のアプリケーションの一部として定義される。第２のＯＳ用に設計された第２のアプリケーションの場合、第２のネイティブコードセクションおよび再利用可能なコードセクションは、第２のアプリケーションの一部として定義され、第２のアプリケーションは、第１のＯＳ上で実行できない。第１および第２のネイティブコードセクションは、ウェブサービスサーバと通信し、ウェブサービスサーバは、複数のバックエンドサービスサーバと通信し、複数のバックエンドサービスサーバのうちの少なくとも一部は、異なるエンティティによって制御される。ウェブサービスサーバは、第１および第２のアプリケーションに代わってバックエンドサービスサーバとのサービス要求の実行を調整する。再利用可能なコードセクションは、第１および第２のアプリケーションが実行されたときにユーザインターフェース要素の表示を容易にする。
【選択図】図５
【選択図】図５
【特許請求の範囲】
【請求項1】
異なるオペレーティングシステムのアプリケーション間で再利用可能なコードの使用を可能にするための方法であって、第１のオペレーティングシステム用に設計された第１のアプリケーションの場合、第１のネイティブコードセクションを前記第１のアプリケーションの一部として定義することであって、前記第１のネイティブコードセクションが、ウェブサービスサーバと通信するように構成され、前記ウェブサービスサーバが、複数のバックエンドサービスサーバと通信するように構成され、前記複数のバックエンドサービスサーバのうちの少なくとも一部が、異なるエンティティによって制御される、定義することと、
前記第１のアプリケーションの場合、前記第１のアプリケーションの一部として再利用可能なコードセクションを定義することであって、前記再利用可能なコードセクションは、前記第１のアプリケーションが前記第１のオペレーティングシステム上で実行されるときに１つ以上の所定のユーザインターフェース要素の表示を容易にするように構成される、定義することと、
第２のオペレーティングシステム用に設計され、前記第１のオペレーティングシステム上で実行することができない第２のアプリケーションの場合、第２のネイティブコードセクションを前記第２のアプリケーションの一部として定義することであって、前記第２のネイティブコードセクションが、前記ウェブサービスサーバと通信するように構成される、定義することと、
前記第２のアプリケーションの一部として前記第１のアプリケーション用に定義された前記再利用可能なコードセクションを実装することであって、前記再利用可能なコードセクションは、前記第２のアプリケーションが前記第２のオペレーティングシステム上で実行されるときに前記所定のユーザインターフェース要素の前記表示を容易にするように構成される、実装することと、を含む、方法。
【請求項2】
前記第１のアプリケーションと前記ウェブサービスサーバとの間、および前記第２のアプリケーションと前記ウェブサービスサーバとの間の交換のための共通の通信セットを定義することをさらに含む、請求項１に記載の方法。
【請求項3】
前記第１のネイティブコードセクションを定義することが、前記第１のアプリケーションと前記ウェブサービスサーバとの間の通信を容易にするように構成された通信セクションを含むように前記第１のネイティブコードセクションを定義することをさらに含む、請求項１に記載の方法。
【請求項4】
前記第１のネイティブコードセクションを定義することが、前記第１のアプリケーションと車両のヘッドユニットとの間の通信を容易にするように構成されたヘッドユニットセクションを含むように前記第１のネイティブコードセクションを定義することをさらに含む、請求項３に記載の方法。
【請求項5】
前記第２のネイティブコードセクションを定義することが、前記第２のアプリケーションと前記ウェブサービスサーバとの間の通信を管理するように構成された通信セクションを含むように前記第２のネイティブコードセクションを定義することをさらに含む、請求項１に記載の方法。
【請求項6】
前記第２のネイティブコードセクションを定義することが、前記第２のアプリケーションと車両のヘッドユニットとの間の通信を容易にするように構成されたヘッドユニットセクションを含むように前記第２のネイティブコードセクションを定義することをさらに含む、請求項５に記載の方法。
【請求項7】
前記再利用可能なコードセクションは、前記第１のアプリケーションが第１のスマートフォンの前記第１のオペレーティングシステム上で実行されたとき、および前記第２のアプリケーションが第２のスマートフォンの前記第２のオペレーティングシステム上で実行されたとき、車両のヘッドユニット上への前記所定の要素の前記表示を容易にするようにさらに構成される、請求項１に記載の方法。
【請求項8】
前記第１のアプリケーションは、ユーザが前記バックエンドサービスサーバのうちの１つ以上によって提供されるサービスを選択できるように構成され、前記選択されたサービスに関連する通信を前記ウェブサービスサーバのみと交換するようにさらに構成される、請求項１に記載の方法。
【請求項9】
前記ウェブサービスサーバが、前記第１のアプリケーションに代わって、前記ウェブサービスサーバ自体と前記バックエンドサービスサーバとの間の前記選択されたサービスに関連する通信の前記交換を管理するように構成される、請求項８に記載の方法。
【請求項10】
通信交換を管理する方法であって、共通のプロトコルを介して第１のアプリケーションから、１つ以上のバックエンドサービスサーバによって実行されるバックエンドサービスの要求を受信することであって、前記第１のアプリケーションが、製造業者によって制御され、第１のオペレーティングシステム上で実行されるように設計され、前記バックエンドサービスが、前記製造業者が製造した車両の遠隔制御操作に関連する、受信することと、
前記バックエンドサービスの前記第１のアプリケーションからの前記要求の実行を担当する前記バックエンドサービスサーバを識別することと、
前記第１のアプリケーションからの前記要求の前記実行を、前記第１のアプリケーションに代わって前記バックエンドサービスサーバと調整することと、
前記バックエンドサービスに対する前記第１のアプリケーションからの前記要求が完了したかどうかを指示するために、前記共通のプロトコルを介して前記第１のアプリケーションに信号送信することと、
前記共通のプロトコルを介して第２のアプリケーションから、前記バックエンドサービスサーバによって実行される前記バックエンドサービスの要求を受信することであって、前記第２のアプリケーションが、前記製造業者によって制御され、第２のオペレーティングシステム上で実行されるように設計され、前記第２のアプリケーションが、前記第１のオペレーティングシステムと互換性がなく、前記第１のアプリケーションが、前記第２のオペレーティングシステムと互換性がない、受信することと、
前記バックエンドサービスの前記第２のアプリケーションからの前記要求の実行を担当する前記バックエンドサービスサーバを識別することと、
前記第２のアプリケーションからの前記要求の前記実行を、前記第２のアプリケーションに代わって前記バックエンドサービスサーバと調整することと、
前記バックエンドサービスに対する前記第２のアプリケーションからの前記要求が完了したかどうかを指示するために、前記共通のプロトコルを介して前記第２のアプリケーションに信号送信することと、を含む、方法。
【請求項11】
前記第２のアプリケーションからの前記要求の前記実行を前記バックエンドサービスサーバと調整することが、前記第２のアプリケーションからの前記要求の前記実行を、前記第２のアプリケーションに代わって前記バックエンドサービスサーバと調整することと同時に、前記第１のアプリケーションからの前記要求の前記実行を、前記第１のアプリケーションに代わって前記バックエンドサービスサーバと調整することをさらに含む、請求項１０に記載の方法。
【請求項12】
前記共通のプロトコルが、前記製造業者に専有の１つ以上の拡張を含む、請求項１０に記載の方法。
【請求項13】
前記バックエンドサービスサーバが、互いに異なり、前記共通のプロトコルとは異なる通信のためのプロトコルに依存する、請求項１０に記載の方法。
【請求項14】
前記第１のアプリケーションからの前記要求の前記実行を、前記第１のアプリケーションに代わって前記バックエンドサービスサーバと調整することが、前記第１のアプリケーションからの前記要求の前記実行を、前記第１のアプリケーションに代わって前記バックエンドサービスサーバの前記異なるプロトコルを介して前記バックエンドサービスサーバと調整することをさらに含み、前記第２のアプリケーションからの前記要求の前記実行を、前記第２のアプリケーションに代わって前記バックエンドサービスサーバと調整することが、前記第２のアプリケーションからの前記要求の前記実行を、前記第２のアプリケーションに代わって前記バックエンドサービスサーバの前記異なるプロトコルを介して前記バックエンドサービスサーバと調整することを含む、請求項１３に記載の方法。
【請求項15】
前記第１のアプリケーションは、前記第１のアプリケーションが前記第１のオペレーティングシステム上で実行されるときに、前記製造業者に関連する１つ以上の所定のユーザインターフェース要素の表示を容易にするように構成された再利用可能なコードセクションを備え、前記第２のアプリケーションが、前記再利用可能なコードセクションを備え、前記再利用可能なコードセクションは、前記第２のアプリケーションが前記第２のオペレーティングシステム上で実行されるときに、前記製造業者に関連する前記所定のユーザインターフェース要素の前記表示を容易にするように構成される、請求項１０に記載の方法。
【請求項16】
前記第１のアプリケーションが、前記バックエンドサービスに対する前記第１のアプリケーションからの前記要求の生成を前記バックエンドサービスサーバによって実行させるように構成された第１のネイティブコードセクションをさらに備え、前記第２のアプリケーションが、前記バックエンドサービスに対する前記第２のアプリケーションからの前記要求の生成を前記バックエンドサービスサーバによって実行させるように構成された第２のネイティブコードセクションをさらに備える、請求項１５に記載の方法。
【請求項17】
製造業者によって製造された車両の遠隔制御操作に関連するバックエンドサービスの要求を容易にするためのシステムであって、第１のオペレーティングシステム上で実行するように設計された複数のアプリケーションおよび第２のオペレーティングシステム上で実行するように設計された複数のアプリケーションから前記バックエンドサービスの要求を受信するように構成されたネットワークインターフェースカードであって、
前記第１のオペレーティングシステムの前記アプリケーションが、前記第２のオペレーティングシステムと互換性がなく、前記第２のオペレーティングシステムの前記アプリケーションが、前記第１のオペレーティングシステムと互換性がなく、
前記ネットワークインターフェースカードが、共通のプロトコルを介して前記第１のオペレーティングシステムの前記アプリケーションおよび前記第２のオペレーティングシステムの前記アプリケーションからの前記要求を受信するようにさらに構成されており、
前記第１のオペレーティングシステムの前記アプリケーションおよび前記第２のオペレーティングシステムの前記アプリケーションが、前記製造業者に関連する共通のユーザインターフェース要素の前記表示を容易にするように構成された再利用可能なコードセクションを共有する、ネットワークインターフェースカードと、
前記ネットワークインターフェースカードに通信可能に結合されたプロセッサであって、
第１のプロトコルを介して第１のバックエンドサービスサーバと通信することと、
第２のプロトコルを介して第２のバックエンドサービスサーバと通信することであって、前記第１のプロトコルおよび前記第２のプロトコルが、互いに異なり、前記共通のプロトコルとも異なる、通信することと、
前記第１のオペレーティングシステムの前記アプリケーションからの前記要求の実行を、前記第１のプロトコルを介して前記第１のバックエンドサービスサーバと、および前記第２のプロトコルを介して前記第２のバックエンドサービスサーバと調整することと、
前記第２のオペレーティングシステムの前記アプリケーションからの前記要求の実行を、前記第１のプロトコルを介して前記第１のバックエンドサービスサーバと、および前記第２のプロトコルを介して前記第２のバックエンドサービスサーバと調整することと、
前記共通のプロトコルを介して前記第１のオペレーティングシステムの前記アプリケーションに、前記バックエンドサービスの要求のステータスの指示を信号送信することと、
前記共通のプロトコルを介して前記第２のオペレーティングシステムの前記アプリケーションに、前記バックエンドサービスの要求の前記ステータスの指示を信号送信することと、を行うように構成された、プロセッサと、を備える、システム。
【請求項18】
前記第１のオペレーティングシステムの前記アプリケーションが、前記共通のプロトコルを介して前記システムによって受信されるように前記バックエンドサービスの前記要求を生成するように構成された第１のネイティブコードセクションを含み、前記第２のオペレーティングシステムの前記アプリケーションが、前記共通のプロトコルを介して前記システムによって受信されるように前記バックエンドサービスの前記要求を生成するように構成された第２のネイティブコードセクションを含む、請求項１７に記載のシステム。
【請求項19】
前記共通のプロトコルが、前記製造業者に専有の拡張を含む、請求項１７に記載のシステム。
【請求項20】
前記第１のバックエンドサービスサーバまたは前記第２のバックエンドサービスサーバからの情報をキャッシュするように構成されたメモリをさらに備え、前記プロセッサが、前記第１のオペレーティングシステムの前記アプリケーション、または前記メモリから前記キャッシュされた情報を取得することによる前記第２のオペレーティングシステムの前記アプリケーションからの前記要求のうちのいくつかに応答するようにさらに構成されている、請求項１７に記載のシステム。
【請求項21】
製造業者によって製造された車両の遠隔制御操作に関連するバックエンドサービスの要求を容易にするためのシステムであって、第１のオペレーティングシステム上で実行するように設計された複数のアプリケーション、および前記第１のオペレーティングシステムと互換性のない第２のオペレーティングシステム上で実行するように設計された複数のアプリケーションから前記バックエンドサービスの要求を受信するための手段であって、
前記第１のオペレーティングシステムの前記アプリケーションおよび前記第２のオペレーティングシステムの前記アプリケーションからの前記要求が、共通のプロトコルを介して受信され、
前記第１のオペレーティングシステムの前記アプリケーションおよび前記第２のオペレーティングシステムの前記アプリケーションが、前記製造業者に関連する共通のユーザインターフェース要素の表示を容易にするように構成された再利用可能なコードセクションを共有する、受信するための手段と、
第１のプロトコルを介して第１のバックエンドサービスサーバと通信し、第２のプロトコルを介して第２のバックエンドサービスサーバと通信するための手段であって、前記第１のプロトコルおよび前記第２のプロトコルが、互いに異なり、前記共通のプロトコルとも異なる、通信するための手段と、
前記第１のオペレーティングシステムの前記アプリケーションからの前記要求の実行を、前記第１のプロトコルを介して前記第１のバックエンドサービスサーバと、および前記第２のプロトコルを介して前記第２のバックエンドサービスサーバと調整し、前記第２のオペレーティングシステムの前記アプリケーションからの前記要求の実行を、前記第１のプロトコルを介した前記第１のバックエンドサービスサーバと、および前記第２のプロトコルを介した前記第２のバックエンドサービスサーバと調整するための手段と、
前記共通のプロトコルを介して前記第１のオペレーティングシステムの前記アプリケーションに、前記バックエンドサービスの要求のステータスの指示を信号送信し、前記共通のプロトコルを介して前記第２のオペレーティングシステムの前記アプリケーションに、前記バックエンドサービスの要求の前記ステータスの指示を信号送信するための手段と、を備える、システム。
【請求項22】
前記第１のオペレーティングシステムの前記アプリケーションが、前記共通のプロトコルを介して前記システムによって受信されるように前記バックエンドサービスの前記要求を生成するように構成された第１のネイティブコードセクションを含み、前記第２のオペレーティングシステムの前記アプリケーションが、前記共通のプロトコルを介して前記システムによって受信されるように前記バックエンドサービスの前記要求を生成するように構成された第２のネイティブコードセクションを含む、請求項２１に記載のシステム。
【請求項23】
前記第１のバックエンドサービスサーバまたは前記第２のバックエンドサービスサーバからの情報をキャッシュするための手段と、前記キャッシュされた情報を取得することによって、前記第１のオペレーティングシステムの前記アプリケーションまたは前記第２のオペレーティングシステムの前記アプリケーションからの前記要求に応答するための手段と、をさらに備える、請求項２１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、一般に、アプリケーションとバックエンドサービスとの間の通信をサポートするシステムに関する。
【背景技術】
【0002】
多くの自動車製造業者は、製造業者または関連する第三者が提供するバックエンドサービスにアクセスするために顧客がアプリをダウンロードできるようにするために、アプリケーションまたはアプリを顧客に提供している。例えば、車の所有者は、所有者のスマートフォンを介してそのようなアプリにアクセスし、所有者の車両のロック解除を遠隔ですることができる。これらのモバイルアプリは一般に、２つの異なるオペレーティングシステム（「ＯＳ」）（１）カリフォルニア州ＣｕｐｅｒｔｉｎｏのＡｐｐｌｅ Ｉｎｃ．によって作成されたｉＯＳ（ＩＯＳ（登録商標））および（２）カリフォルニア州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＧｏｏｇｌｅ Ｉｎｃ．によって開発されたＡｎｄｒｏｉｄ（商標）のうちの１つで機能するように設計されている。
【0003】
この設定でのモバイルアプリの設計は、所有者が開始したタスクを実行するために、各々が異なる会社によって運営されている複数のバックエンドサービスと通信する必要がある場合があるため、複雑になることがよくある。さらに、製造業者は、ｉＯＳアプリ専用の開発チームとＡｎｄｒｏｉｄアプリ用の別個の開発チームを維持する必要がある。この複雑さとスタッフの増員の必要性は、バックエンドサービスの量、およびそれらを提供するために協力して運営している会社の数が増加するにつれて、さらに悪化する。複数のブランド（または型）の車両を提供する製造業者は、この非効率的な構成によってさらに負担をかけられる。
【発明の概要】
【0004】
本明細書では、異なるオペレーティングシステム（「ＯＳ」）のアプリケーション間で再利用可能なコードの使用を可能にするための方法が説明される。第１のＯＳ用に設計された第１のアプリケーションの場合、第１のネイティブコードセクションを第１のアプリケーションの一部として定義し、第１のネイティブコードセクションをウェブサービスサーバと通信するように構成することができる。ウェブサービスサーバは、複数のバックエンドサービスサーバと通信するように構成することができ、そのうちの少なくとも一部は、異なるエンティティによって制御され得る。再利用可能なコードセクションはまた、第１のアプリケーションの一部として定義することもでき、再利用可能なコードセクションは、第１のアプリケーションが第１のＯＳ上で実行されるときに、１つ以上の所定のユーザインターフェース（「ＵＩ」）要素の表示を容易にするように構成することができる。
【0005】
第２のＯＳ用に設計され、第１のＯＳ上で実行できない第２のアプリケーションの場合、第２のネイティブコードセクションを第２のアプリケーションの一部として定義し、第２のネイティブコードセクションは、ウェブサービスサーバと通信するように構成することができる。第１のアプリケーション用に定義された再利用可能なコードセクションは、第２のアプリケーションの一部として実装できる。再利用可能なコードセクションは、第２のアプリケーションが第２のオペレーティングシステム上で実行されるときに、所定のＵＩ要素の表示を容易にするように構成されてもよい。オプションとして、第１のアプリケーションとウェブサービスサーバとの間、および第２のアプリケーションとウェブサービスサーバとの間の交換用に、共通の通信セットを定義できる。
【0006】
一実施形態では、第１のネイティブコードセクションは、第１のアプリケーションとウェブサービスサーバとの間の通信を管理するように構成された通信セクションを有してもよく、第１のアプリケーションと車両のＨＵとの間の通信を容易にするように構成されたヘッドユニット（「ＨＵ」）セクションを含むことができる。第２のネイティブコードセクションは、第２のアプリケーションとウェブサービスサーバとの間の通信を管理するように構成された通信セクションを含むことができ、第２のアプリケーションと車両のＨＵとの間の通信を容易にするように構成されたＨＵセクションを有することができる。
【0007】
一実施形態では、再利用可能なコードセクションは、第１のアプリケーションが第１のスマートフォンの第１のＯＳ上で実行されるとき、および第２のアプリケーションが第２のスマートフォンの第２のＯＳ上で実行されるとき、車両のＨＵ上の所定のＵＩ要素の表示を容易にするように構成できる。第１のアプリケーションは、ユーザがバックエンドサービスサーバのうちの１つ以上によって提供されるサービスを選択できるように構成でき、選択したサービスに関連する通信をウェブサービスサーバのみと交換するようにさらに構成できる。さらに、ウェブサービスサーバは、第１のアプリケーションに代わって、それウェブサービスサーバ自体とバックエンドサービスサーバとの間の選択されたサービスに関連する通信の交換を管理するように構成されてもよい。
【0008】
通信交換を管理する方法もまた、本明細書に説明される。この方法では、１つ以上のバックエンドサービスサーバによって実行されるバックエンドサービスの要求を、共通のプロトコルを介して第１のアプリケーションから受信できる。第１のアプリケーションは製造業者によって制御されてもよく、第１のＯＳ上で実行するように設計できる。バックエンドサービスは、製造業者が製造した車両の遠隔制御操作に関連し得る。バックエンドサービスの第１のアプリケーションからの要求の実行を担当するバックエンドサービスサーバを識別でき、第１のアプリケーションからの要求の実行を、第１のアプリケーションに代わってバックエンドサービスサーバと調整できる。第１のアプリケーションは、共通のプロトコルを介して信号送信され、バックエンドサービスに対する第１のアプリケーションからの要求が完了したかどうかを指示することができる。
【0009】
また、バックエンドサービスサーバによって実行されるバックエンドサービスに対する要求は、共通のプロトコルを介して第２のアプリケーションから受信できる。第１のアプリケーションと同様に、第２のアプリケーションは、製造業者によって制御される場合があるが、第２のＯＳ上で実行するように設計されてもよい。第２のアプリケーションは第１のＯＳと互換性がなく、第１のアプリケーションは第２のＯＳと互換性がない。バックエンドサービスに対する第２のアプリケーションからの要求の実行を担当するバックエンドサービスサーバを識別でき、第２のアプリケーションからの要求の実行を、第２のアプリケーションに代わってバックエンドサービスサーバと調整できる。第２のアプリケーションは、共通のプロトコルを介して信号送信され、バックエンドサービスに対する第２のアプリケーションからの要求が完了したかどうかを指示することもできる。一構成では、バックエンドサービスサーバとの第２のアプリケーションからの要求の実行の調整は、第１のアプリケーションに代わってバックエンドサービスサーバとの第１のアプリケーションからの要求の実行の調整と同時に行うことができる。
【0010】
一例として、共通のプロトコルには、製造業者に専有の１つ以上の拡張が含まれる場合があるが、バックエンドサービスサーバは、互いに異なる通信用のプロトコル、および共通のプロトコルに依存する場合がある。別の例として、バックエンドサービスサーバとの第１のアプリケーションからの要求の実行の調整は、第１のアプリケーションに代わってバックエンドサービスサーバの異なるプロトコルを介して行うことができる。同様に、バックエンドサービスサーバとの第２のアプリケーションからの要求の実行の調整は、第２のアプリケーションに代わってバックエンドサービスサーバの異なるプロトコルを介して行うことができる。
【0011】
一構成では、第１のアプリケーションは、第１のアプリケーションが第１のＯＳ上で実行されるときに、製造業者に関連する１つ以上の所定のＵＩ要素の表示を容易にするように構成された再利用可能なコードセクションを含むことができる。また、第２のアプリケーションは、再利用可能なコードセクションを含むことができ、再利用可能なコードセクションは、第２のアプリケーションが第２のＯＳ上で実行されるときに、製造業者に関連する所定のＵＩ要素の表示を容易にするように構成される。第１のアプリケーションはまた、バックエンドサービスに対する第１のアプリケーションからの要求の生成をバックエンドサービスサーバによって実行させるように構成された第１のネイティブコードセクションを含むことができる。同様に、第２のアプリケーションは、バックエンドサービスに対する第２のアプリケーションからの要求の生成をバックエンドサービスサーバによって実行させるように構成された第２のネイティブコードセクションを含むことができる。
【0012】
製造業者によって製造された車両の遠隔制御操作に関連するバックエンドサービスの要求を容易にするためのシステムもまた、本明細書に説明される。このシステムは、第１のＯＳ上で実行するように設計された複数のアプリケーションおよび第２のＯＳ上で実行するように設計された複数のアプリケーションからバックエンドサービスの要求を受信するように構成された１つ以上のネットワークインターフェースカード（「ＮＩＣ」）を含むことができる。第２のＯＳのアプリケーションは、第１のＯＳと互換性がない。ＮＩＣは、共通のプロトコルを介して、第１のＯＳのアプリケーションおよび第２のＯＳのアプリケーションからの要求を受信するようにさらに構成される。第１のＯＳのアプリケーションおよび第２のＯＳのアプリケーションは、製造業者に関連する共通のＵＩ要素の表示を容易にするように構成された再利用可能なコードセクションを共有してもよい。
【0013】
このシステムには、１つ以上のプロセッサを含むこともできる。プロセッサは、ＮＩＣに通信可能に結合でき、第１のプロトコルを介して第１のバックエンドサービスサーバと通信し、第２のプロトコルを介して第２のバックエンドサービスサーバと通信するように構成できる。第１のプロトコルおよび第２のプロトコルは、互いに異なり、共通のプロトコルである。
【0014】
プロセッサは、第１のＯＳのアプリケーションからの要求の実行を、第１のプロトコルを介して第１のバックエンドサービスサーバと、および第２のプロトコルを介して第２のバックエンドサービスサーバと調整するように構成できる。プロセッサはまた、第２のＯＳのアプリケーションからの要求の実行を、第１のプロトコルを介して第１のバックエンドサービスサーバと、および第２のプロトコルを介して第２のバックエンドサービスサーバと調整するように構成できる。プロセッサは、バックエンドサービスに対する要求のステータスを示す共通のプロトコルを介して、第１のＯＳのアプリケーションおよび第２のＯＳのアプリケーションに信号送信するようにさらに構成できる。
【0015】
一例として、第１のＯＳのアプリケーションは、共通のプロトコルを介してシステムによって受信されるためのバックエンドサービスの要求を生成するように構成された第１のネイティブコードセクションを含む。第２のＯＳのアプリケーションはまた、共通のプロトコルを介してシステムによって受信されるためのバックエンドサービスの要求を生成するように構成された第２のネイティブコードセクションを含むこともできる。
【0016】
一実施形態では、共通のプロトコルは、製造業者に専有の拡張を含むことができる。システムは、第１のバックエンドサービスサーバまたは第２のバックエンドサービスサーバからの情報をキャッシュするように構成されたメモリをさらに含むことができる。プロセッサは、メモリからキャッシュされた情報を取得することによって、第１のＯＳのアプリケーションまたは第２のＯＳのアプリケーションからの要求うちのいくつかに応答するようにさらに構成できる。
【0017】
製造業者によって製造された車両の遠隔制御操作に関連するバックエンドサービスの要求を容易にするためのシステムもまた、本明細書に説明される。このシステムは、第１のＯＳ上で実行するように設計された複数のアプリケーションおよび第２のＯＳ上で実行するように設計された複数のアプリケーションからバックエンドサービスの要求を受信するための手段を含む。このような手段に対応する構造は、ウェブサービスサーバのＮＩＣである。第１のＯＳのアプリケーションは第２のＯＳと互換性がなく、第２のＯＳのアプリケーションは第１のＯＳと互換性がない。加えて、第１のＯＳのアプリケーションおよび第２のＯＳのアプリケーションからの要求は、共通のプロトコルを介して受信される。第１のＯＳのアプリケーションおよび第２のＯＳのアプリケーションは、製造業者に関連する共通のＵＩ要素の表示を容易にするように構成された再利用可能なコードセクションを共有してもよい。
【0018】
システムはまた、第１のプロトコルを介して第１のバックエンドサービスサーバと通信するための手段、および第２のプロトコルを介して第２のバックエンドサービスサーバと通信するための手段を含むこともできる。第１のプロトコルおよび第２のプロトコルは、互いに異なってもよいし、共通のプロトコルであってもよい。
【0019】
システムは、第１のＯＳのアプリケーションからの要求の実行を、第１のプロトコルを介して第１のバックエンドサービスサーバと、および第２のプロトコルを介して第２のバックエンドサービスサーバと調整し、第２のＯＳのアプリケーションからの要求の実行を、第１のプロトコルを介して第１のバックエンドサービスサーバと、および第２のプロトコルを介して第２のバックエンドサービスサーバと調整するための手段をさらに含むことができる。システムはまた、バックエンドサービスの要求のステータスを指示する共通のプロトコルを介して第１のＯＳのアプリケーションに信号送信する手段、およびバックエンドサービスの要求のステータスを指示する共通のプロトコルを介して第２のＯＳのアプリケーションに信号送信する手段を有することもできる。通信、調整、および信号送信のためのそのような手段に対応する構造は、本明細書に記載のプロセスおよびステップを実施するように構成され、特別にプログラムされたウェブサービスサーバのプロセッサである。
【0020】
一例として、第１のＯＳのアプリケーションは、共通のプロトコルを介してシステムによって受信されるためのバックエンドサービスの要求を生成するように構成された第１のネイティブコードセクションを含むことができる。この例の一部として、第２のＯＳのアプリケーションには、共通のプロトコルを介してシステムによって受信されるバックエンドサービスの要求を生成するように構成された第２のネイティブコードセクションを含むことができる。システムはまた、第１のバックエンドサービスサーバまたは第２のバックエンドサービスサーバから情報をキャッシュするための手段、およびキャッシュされた情報を取得することによって第１のＯＳのアプリケーションまたは第２のＯＳのアプリケーションからの要求に応答するための手段を含むこともできる。キャッシュおよび応答のためのそのような手段に対応する構造は、本明細書に記載のプロセスおよびステップを実施するように構成および特別にプログラムされたウェブサービスサーバのプロセッサ、および本明細書に記載のウェブサービスサーバのメモリを互いに組み合わせたものである。
【図面の簡単な説明】
【0021】
以下の図面を参照して、非限定的かつ非網羅的な実施形態を説明する。図面において、同様の参照番号は、特に明記しない限り、様々な図全体を通して同様の部分を指す。
【0022】
本明細書に記載されている主題をよりよく理解するために、以下の「発明を実施するための形態」と題されたセクションを参照する。これは、添付の図面と併せて読むべきである。
【0023】
【図1】アプリケーションとバックエンドサービスサーバとの間の通信をサポートする従来技術のシステムを示す。
【図2】アプリケーション、ウェブサービスサーバ、およびバックエンドサービスサーバ間の通信をサポートするシステムの一例を示す。
【図3】ウェブサービスサーバの一例およびいくつかのバックエンドサービスサーバの例を示す。
【図4】通信交換の管理方法の一例を示す。
【図5】異なるオペレーティングシステムのアプリケーション間で再利用可能なコードセクションの使用を可能にする方法の一例を示す。
【図6】いくつかのクライアントの例を示す。
【発明を実施するための形態】
【0024】
前述のように、アプリケーション（「アプリ」）の設計は、ユーザが開始したタスクを実行するために、各々が異なる会社によって運営されている複数のバックエンドサービスと通信する必要がある場合があるため、複雑になることがよくある。さらに、特定のオペレーティングシステム（「ＯＳ」）用に設計されたアプリごとに、個別の開発チームを配置する必要がある。この現在の構成は簡単に拡張できず、ユーザに追加のサービスを効率的に提供することを妨げる。
【0025】
この非効率的な構成を克服するために、異なるＯＳのアプリ間で再利用可能なコードの使用を可能にするための方法およびシステムを本明細書に提示する。第１のＯＳ用に設計された第１のアプリの場合、第１のネイティブコードセクションは、第１のアプリの一部として定義され、第１のネイティブコードセクションは、ウェブサービスサーバと通信するように構成される。ウェブサービスサーバは、複数のバックエンドサービスサーバと通信するように構成されており、そのうちの少なくとも一部は、異なるエンティティによって制御される。第１のアプリの場合、再利用可能なコードセクションもまた、第１のアプリの一部として定義される。再利用可能なコードセクションは、第１のアプリが第１のＯＳ上で実行されるときに、１つ以上の所定のユーザインターフェース（「ＵＩ」）要素の表示を容易にするように構成される。
【0026】
加えて、第２のＯＳ用に設計され、第１のＯＳ上で実行できない第２のアプリの場合、第２のネイティブコードセクションが、第２のアプリの一部として定義される。第２のネイティブコードセクションは、ウェブサービスサーバと通信するように構成される。さらに、第１のアプリ用に定義された再利用可能なコードセクションは、第２のアプリの一部として実装される。第１のアプリと同様に、再利用可能なコードセクションは、第２のアプリが第２のＯＳ上で実行されたときに、所定のＵＩ要素の表示を容易にするように構成される。このスキームでは、ウェブサービスサーバは、バックエンドサービスサーバと調整して、第１および第２のアプリからのバックエンドサービスの要求を処理し、したがって、第１および第２のアプリからそのような複雑なステップを軽減することができる。
【0027】
通常、第１および第２のアプリに関連する複雑さの多くがウェブサービスサーバに課せられているため、車両製造業者などのエンティティのアプリを様々なＯＳ間で構築および維持するために必要な個体数が大幅に削減される。さらに、この大幅な改善は、アプリの機能が失われるという結果にはならない。実際、この構成は非常に拡張可能であり、アプリの追加の機能につながり得、より多くのバックエンドサービスプロバイダが参加する機会を提供する。
【0028】
詳細な実施形態が本明細書に開示されている。しかしながら、開示された実施形態は、本質的に例示的なものである。したがって、本明細書に開示される特定の構造的および機能的詳細は、限定的であると解釈されるべきではなく、単に請求項の代表的な基礎として、および実質的に任意の適切に詳細な構造で本明細書の態様を様々に使用することを当業者に教示するためのものである。さらに、本明細書で使用される用語および句は、限定することを意図するのではなく、可能な実装の理解可能な説明を提供することを意図する。様々な実施形態が図１～図６に示されているが、実施形態は、示された構造または用途に限定されない。
【0029】
ここで適用できるいくつかの定義を次に示す。「再利用可能」という用語は、アプリケーションに他と互換性がない環境を含む様々な環境に関連する場合など、複数回使用、共有、実装、統合、配布、コピー、インストール、ロード、処理、またはさもなければリサイクルできるとして定義される。「再利用可能なコードセクション」という用語は、再利用可能または少なくとも９０％再利用可能な、人間または機械の形式のコンピュータコードまたは命令として定義される。「ネイティブコードセクション」という用語は、ＯＳまたはプロセッサなどの特定のシステム用に設計された、人間または機械の形式のコンピュータコードまたは命令として定義される。「オペレーティングシステム」という用語は、コンピュータの操作を指示または制御するソフトウェアとして定義される。「サーバ」とは、コンピュータプログラムまたは他のコンピュータに機能を提供するソフトウェアでプログラムされたコンピュータとして定義される。「バックエンドサービス」という用語は、個別に、または任意の数の他のサーバまたはコンピュータと組み合わせて、サーバまたは他のコンピュータによって提供される任意のサービスまたは機能として定義される。
【0030】
「容易にする」という言葉は、行動、コマンド、命令、またはプロセスを支援、可能化、有効化、迅速化、加速、前進、促進、またはサポートすることとして定義される。「調整する」という言葉は、１つ以上の行動またはプロセスを管理、有効化、監視、調和、同期、規制、または編成することとして定義される。「制御する」という言葉は、直接、もしくは１つ以上の媒介または他のエンティティを介することを含む、権限または影響力を持つものとして定義される。「互換性がない」という言葉は、設計または意図されたとおりに機能、操作、運転、または実行できない、またはそのような機能、操作、運転、または実行が妨げられているとして定義される。「同時」という言葉は、存在、発生、または操作全体の間に、またはそのような存在、発生、または操作の一部のみに対して、同時に存在、発生、または操作することとして定義される。「専有」という言葉は、１つ以上のエンティティに属しているか、もしくは所有、制御、または独占的に保持されているとして定義される。「アプリケーションの一部としてのコードセクションの定義」という句は、静的または動的にリンクされたコンポーネントを含む、アプリケーションの少なくとも一部のコンピュータコードの設計、モデリング、開発、記述、実装、確立、またはテスト（または前述の任意の組み合わせ）として定義される。
【0031】
「ヘッドユニット」は、車両内または車両上のヒューマンツーマシン（ＨＭＩ）ハードウェアインターフェースとして定義される。「車両」は、人間、動物、または貨物（またはそれらの任意の組み合わせ）を輸送するための可動構造として定義され、例には、車、トラック、バス、列車（または他の鉄道ベースの機械、飛行機もしくは他の形態の飛行、またはボートもしくは他の形態の水上移動）が含まれる。「プロトコル」は、事前定義されたルール、手順、プロセス、命令、コマンド、呼び出し、または通信のセット、もしくは確立された基準、標準、または要件として定義される。「共通のプロトコル」という用語は、その全体または少なくとも半分で、２つ以上のエンティティ、デバイス、プロセス、機械、またはアプリケーションに後続、実践、使用、受容、採用、順守、または使用、または固執、または準拠されるプロトコルとして定義される。一例として、２つのプロセスによるプロトコルの少なくとも５０％の共有使用により、プロトコルはプロセスに関して共通になる。「ネットワークインターフェースカード」（ＮＩＣ）という用語は、コンピュータがネットワークに接続できるように構成されたコンピュータハードウェアコンポーネントとして定義される。
【0032】
「プロセッサ」は、いくつかの回路を備えたコンポーネント、もしくは命令を実行するように構成された回路を備えた、または本明細書に記載のプロセスを実行するまたは容易にするための実行命令（またはその両方）をプログラムされた、それらのうちの少なくとも一部を備えたコンポーネントのグループとして定義される。例には、シングルコアおよびマルチコアプロセッサまたはコプロセッサが含まれる。「メモリ」または「メモリ要素」という用語は、少なくともいくつかの回路を含み（おそらく操作用のサポートソフトウェアまたはファイルシステムとともに）、一時的または永続的にデータを格納するように構成された構造として定義される。「通信回路」は、任意の数およびタイプの通信プロトコルに従って、有線または無線通信（またはその両方）をサポートまたは容易にするように構成された回路ベースのコンポーネントとして定義される。「通信可能に結合」という句は、信号が単方向、双方向、または多方向に基づいて異なるコンポーネントの間またはコンポーネントの中で交換される可能性がある状態として定義され、有線または無線（または両方）の直接または間接接続を含む。
【0033】
「本明細書に」という言葉は、本出願の明細書、特許請求の範囲、および図面を意味する。「ａ」および「ａｎ」という用語は、１つまたは２つ以上として定義される。「複数」という用語は、２つまたは３つ以上として定義される。「別の」という用語は、少なくとも二番目以上として定義される。「含む」および「有する」という用語は、備える（すなわち、オープンランゲージ）として定義される。「…および…のうちの少なくとも１つ」および「…または…のうちの少なくとも１つ」という句は、１つ以上の関連するリストされたアイテムのすべての可能な組み合わせを包含するように定義される。一例として、「Ａ、ＢおよびＣのうちの少なくとも１つ」という句は、Ａのみ、Ｂのみ、Ｃのみ、またはそれらの任意の組み合わせ（例えば、ＡＢ、ＡＣ、ＢＣまたはＡＢＣ）を含む。追加の定義を以下に提示する。
【0034】
図１を参照すると、既存のアプリとバックエンドサービスサーバとの間の相互作用を示す従来技術のシステム１００が提示される。システム１００は、モバイルＯＳ上で実行するように設計されたアプリ１０５と、異なるモバイルＯＳ上で実行するように構成された第２のアプリ１１０とを含む。アプリ１０５は、第１のスマートフォン１１５にインストールされ、第２のアプリ１１０は、第２のスマートフォン１２０にインストールされる。システム１００はまた、バックエンドサービスサーバ１２５、バックエンドサービスサーバ１３０、およびバックエンドサービスサーバ１３５などの複数のバックエンドサービスサーバを含み、これらのサーバは各々、様々なネットワーク（図示せず）を介して第１のスマートフォン１１５および第２のスマートフォン１２０に接続される。
【0035】
これらの接続を介して、バックエンドサービスサーバ１２５、バックエンドサービスサーバ１３０、およびバックエンドサービスサーバ１３５は、第１のアプリ１０５および第２のアプリ１１０にサービスを提供する。例えば、バックエンドサービスサーバ１２５は、自動車製造業者によって操作され得、バックエンドサービスサーバ１３０、１３５は、第三者によって管理され得、その両方は、製造業者に代わって第１のアプリ１０５および第２のアプリ１１０にサービスを提供するために製造業者と契約している。重要なことに、第三者と製造業者の両方が独立したエンティティであり、そのため、バックエンドサービスサーバ１２５、１３０、１３５の各々と通信するプロセスは、非常に複雑になる可能性がある。
【0036】
これらのコンポーネント間の相互作用の一例は、車両を遠隔でロック解除する要求である（図示せず）。特に、車両の所有者は、第１のアプリ１０５を介して要求を開始することができ、第１のアプリ１０５は、車両の製造業者によって維持されるバックエンドサービスサーバ１２５、およびバックエンドサービスサーバ１３０との通信を確立し、これは、第三者によって制御され、遠隔ロック解除コマンドを車両に送信する。第１のアプリ１０５、バックエンドサービスサーバ１２５、およびバックエンドサービスサーバ１３０の間の通信の交換は、異なるプロトコルにわたる複数のコマンドおよび確認応答を含み、これは、システム１００を複雑にする。したがって、第１のアプリ１０５は、バックエンドサービスサーバ１２５およびバックエンドサービスサーバ１３０の両方の実装およびそれらの相互運用性を説明するように記述されなければならない。さらに悪いことに、バックエンドサービスの数と種類が増えるにつれて、新しい機能をサポートするために、第１のアプリと第２のアプリ１０５、１１０の両方を絶えず更新する必要がある。そうするために、そのような更新を提供し、第１および第２のアプリ１０５、１１０をデバッグするために、別個の開発チームを維持する必要がある。
【0037】
図２を参照すると、図１の従来技術のシステム１００の深刻な非効率性を克服するシステム２００の一例が示されている。システム２００は、デバイス上でのユーザの相互作用をサポートするために、各々がアプリの形態であり得る１つ以上のクライアント２０２を含むことができる。例えば、システム２００は、第１のアプリ２０５、第１のアプリ２０５がインストールされている第１のスマートフォン２１０、第２のアプリ２１５、および第２のアプリ２１５がインストールされている第２のスマートフォン２２０を含むことができる。一実施形態では、第１および第２のアプリ２０５、２１５は、モバイル動作環境で動作するように設計されたモバイルアプリである。例えば、第１のスマートフォン２１０は、ｉＯＳ（ＩＯＳ（登録商標））のような第１のモバイルＯＳを備えていてもよく、第１のアプリ２０５は、このＯＳ上で実行するように設計されている。この例を続けると、第２のスマートフォン２２０は、アンドロイド（商標）などの第２のモバイルＯＳで構成され得、第２のアプリ２１５は、このＯＳのために特別に開発される。第１のアプリ２０５および第２のアプリ２１５の両方は、それが設計されたモバイルＯＳのみと互換性があり得、すなわち、第１のアプリ２０５は、第２のモバイルＯＳを動かすデバイス上で実行され得ず、逆もまた同様である。それにもかかわらず、以下で説明するように、第１のアプリ２０５および第２のアプリ２１５は、コードベースを共有することができ、これにより、各々の複雑さが軽減される。
【0038】
システム２００はまた、ウェブサービスサーバ２２５および複数のバックエンドサービスサーバ２３０を含むことができる。一例として、バックエンドサービスサーバ２３０の１つは、車両製造業者などの製造業者によって制御され、バックエンドサービスサーバ２３０の１つ以上は、製造業者の顧客などの特定のユーザにサービスを提供する第三者によって制御される。この例では、製造業者によって制御されるバックエンドサービスサーバ２３０は、製造業者バックエンドサービスサーバ２３５または製造業者サーバ２３５と呼ばれる。加えて、第三者によって制御される２つのバックエンドサービスサーバ２３０は、（それぞれ）第三者バックエンドサービスサーバ２４０および第三者バックエンドサービスサーバ２４５、またはは第三者サーバ２４０および第三者サーバ２４５と呼ばれる。
【0039】
バックエンドサービスサーバ２３０は、ユーザにバックエンドサービスを提供するように構成される。例えば、ユーザは、車両（図示せず）を所有、リース、または運転することができ、１つ以上のバックエンドサービスサーバ２３０は、１つ以上の機能を実施することができ、時には、車両に対して、互いに連携して操作することができる。これらのサービスのいくつかの例を以下に提示する。
【0040】
多くのサービスが複数のバックエンドサービスサーバ２３０間の相互作用を必要とし得るので、ウェブサービスサーバ２２５は、バックエンドサービスサーバ２３０に関してユーザからの要求の実行を調整するように構成される。一例として、ユーザは、ウェブサービスサーバ２２５が受信することができる、第１のアプリ２０５を介してサービスを要求することができる。それに応答して、ウェブサービスサーバ２２５は、１つ以上のバックエンドサービスサーバ２３０とのいくつかの交換を通じて、第１のアプリ２０５に代わって要求の実行を管理することができる。要求されたサービスが完了すると、ウェブサービスサーバ２２５は、第１のアプリ２０５を介してユーザに通知することができる。したがって、バックエンドの相互作用の観点から要求を実行するために必要な論理は、第１のアプリ２０５とは対照的に、ウェブサービスサーバ２２５に含まれている。
【0041】
この態様を容易にするために、ウェブサービスサーバ２２５は、それが参加しているバックエンドサービスサーバ２３０の各々と信号を登録および交換することを可能にするために必要な論理で構成される。この信号の登録および交換は、必要な認証データおよび参加しているバックエンドサービスサーバ２３０の各々のメッセージングプロトコルを提供されるウェブサービスサービサーバ２２５を含むことができる。認証データは、これらのバックエンドサービスサーバ２３０の完全性を維持することができ、ウェブサービスサーバ２２５は、サーバ２３０のプロトコルに適応するので、これらのサーバ２３０の既存のメッセージング構造に変更を加える必要はない。したがって、ウェブサービスサーバ２２５の実装は、バックエンドサービスサーバ２３０を制御するエンティティが、バックエンドサービスを提供するための現在のアプリケーションプログラミングインターフェース（「ＡＰＩ」）または他のソフトウェアインターフェースまたはコネクタを維持することを可能にする。さらに、バックエンドサービスサーバ２３０に関連するＡＰＩの追加または削除を含む、既存のメッセージング構造への任意の変更は、クライアント２０２を再適応させるのではなく、単一のプラットフォーム、ウェブサービスサーバ２２５に容易に統合することができ、それらの配布を可能にする。
【0042】
ウェブサービスサーバ２２５はまた、サービスを提供するときに、様々なバックエンドサービスサーバ２３０間（またはそれらの中）の相互運用性に対応するようにプログラムすることができる。例えば、いくつかのサービスは、複数のサーバ２３０の関与を必要とし得、ウェブサービスサーバ２２５は、複数のサーバ２３０の各々によって実施される操作を説明するように構成され得る。この構成により、ウェブサービスサーバ２２５は、利用可能なすべてのバックエンドサービスの実行を効率的に調整することができる。さらに、この設定により、システム２００は大いに拡張可能になり、多数の（無関係の）エンティティによって制御され得る多くの異なるバックエンドサービスサーバ２３０が、必要に応じてウェブサービスサーバ２２５を再構成するだけでシステム２００に統合できる。このプロセスはまた、クライアント２０２を実質的に再構成する必要なしに、ユーザに提供することができるサービスの数およびタイプを増加させることができる。
【0043】
ウェブサービスサーバ２２５は、バックエンドサービスの実行を調整する責任を負っているので、サーバ２２５とクライアント２０２との間のメッセージングプロトコルは、単純で均一であり得る。特に、クライアント２０２は、共通のプロトコルを介してウェブサービスサーバ２２５と通信することができる。例えば、ＡＰＩまたは他のメッセージングスキームの標準セットを実装して、第１のアプリ２０５とウェブサービスサーバ２２５との間、および第２のアプリ２１５とサーバ２２５との間の通信を容易にすることができる。したがって、第１のアプリ２０５および第２のアプリ２１５が異なるＯＳ用に開発され得るとしても、これらのクライアント２０２は、ウェブサービスサーバ２２５とメッセージを交換するために同じプロトコルに依存し得る。この均一性に加えて、クライアント２０２とウェブサービスサーバ２２５との間のＡＰＩの複雑さは、サーバ２２５がクライアント２０２に代わってサービスの実行を調整する機能を任されているので、大幅に減らすことができる。
【0044】
一実施形態では、クライアント２０２がウェブサービスサーバ２２５と通信するために使用するプロトコルの共通性のパーセンテージは、１００％または同一の使用法から、少なくとも５０％までの範囲であり得る。例えば、共通のプロトコルがＡＰＩのセットを含む場合、クライアント２０２は、それらの少なくとも半分からすべてまでのどこでも共有することができる。さらに、共通のプロトコルは拡張可能であり得、これにより、開発者は、クライアント２０２に追加の機能を実装することができる。例えば、ＡＰＩの場合、拡張を共通のプロトコルの１つ以上のＡＰＩに追加して、機能を向上させることができる。拡張は共有することができ、つまり、参加しているクライアント２０２は、ウェブサービスサーバ２２５との呼び出しに追加のデータを埋め込む機能を利用できる。このデータは、適切なバックエンドサービスサーバ２３０によって処理できる。
【0045】
別の場合では、拡張機能の少なくとも一部またはすべてが１つ以上のエンティティに専有であり得、これらのエンティティによって制御または関連するクライアント２０２のみが、これらの拡張機能を使用するか、使用できる。これらのエンティティによって制御されないまたは関連していないクライアント２０２の場合、無関連のクライアント２０２、ウェブサービスサーバ２２５、および関連するバックエンドサービスサーバ（複数可）２３０は、それらが無関連のクライアント２０２に関して着信または発信呼び出しの一部であるかどうかにせよ、処理を防止するか、または専有の拡張を無視することができる。この説明の目的のために、ＡＰＩが共有または専有であるかどうかにかかわらず拡張を含む場合、ＡＰＩは、クライアント２０２が、拡張を使用することを意図されているか許可されているかに関係なく、共通のプロトコルの一部としてＡＰＩを使用するクライアント２０２に共通であると見なされる。
【0046】
一実施形態では、第１のスマートフォン２１０および第２のスマートフォン２２０の両方は、車両のヘッドユニット（「ＨＵ」）２５０と相互作用するように構成され得る。ＨＵ２５０は、プロセッサ２５５、メモリ２６０、およびディスプレイ２６５を含むことができ、プロセッサ２５５は、メモリ２６０およびディスプレイ２６５に通信可能に結合されている。一構成では、ＨＵ２５０はまた、ハードウェアインターフェース２７０、第１のトランシーバ２７５、および第２のトランシーバ２８０を含み得、これらの各々は、プロセッサ２５５に通信可能に結合され得る。したがって、プロセッサ２５５は、ＨＵ２５０のこれらのコンポーネントの各々の動作を管理することができる。
【0047】
一例として、ハードウェアインターフェース２７０は、ＨＵ２５０と、第１のスマートフォン２１０または第２のスマートフォン２２０などの別のデバイスとの間の有線接続を可能にする接続構造とすることができる。有線接続は、あらゆる世代のユニバーサルシリアルバス（「ＵＳＢ」）など、任意の好適な業界標準に基づくことができる。加えて、第１のトランシーバ２７５は、ネットワークの支援なしに、第１のスマートフォン２１０または第２のスマートフォン２２０などの別のデバイスとの無線通信を確立するように構成された短距離無線トランシーバであり得る。ワイヤレス接続は、Ｂｌｕｅｔｏｏｔｈまたは任意のＷｉ－Ｆｉプロトコルなどの任意の業界標準に準拠できる。この設定では、第１のスマートフォン２１０または第２のスマートフォン２２０は、そのような交換をサポートする第１のスマートフォン２１０または第２のスマートフォン２２０のトランシーバ（図示せず）との、ＨＵ２５０と、セルラーネットワークなどの無線ネットワークとの間の通信を可能にする導管として機能し得る。この構成に加えて、またはこの構成の代わりに、ＨＵ２５０の第２のトランシーバ２８０は、セルラーネットワークなどの任意の好適な長距離無線ネットワークと通信するように構成された長距離無線トランシーバであり得る。そのため、ＨＵ２５０は、スマートフォンの支援を用いずに長距離通信を確立および維持できる可能性がある。
【0048】
一構成では、第１のスマートフォン２１０、第２のスマートフォン２２０、およびＨＵ２５０は、スマートフォン２１０、２２０がＨＵ２５０と相互作用してＨＵ２５０の機能を向上させることを可能にするように構成することができる。例えば、第１のスマートフォン２１０は、ＨＵ２５０をスマートフォン２１０の外部ディスプレイとしてサーバ化するように構成することができ、これにより、スマートフォン２１０にインストールされたサポートされるアプリを、ＨＵ２５０のディスプレイ２６５上に表示し、そのディスプレイを介してアクセスできるようにすることができる。サポートされるアプリの例には、ナビゲーション、音楽再生、メッセージング、音声通話、ウェブ検索用のアプリが含まれる。音量および再生用のソフトボタンまたは音声コマンドを有効にするためのコンポーネントなどのＨＵ２５０に関連する制御もまた、第１のスマートフォン２１０または第２のスマートフォン２２０の動作を操作するために使用され得る。
【0049】
このスキームを通じて、クライアント２０２はまた、ＨＵ２５０上でミラーリングすることもでき、これにより、ユーザは、ＨＵ２５０を介してクライアント２０２と相互作用することができる。これらの相互作用は、例えば、ディスプレイ２６５を介して、またはＨＵ２５０によって受信された音声コマンドを介して実施することができ、ユーザが１つ以上のバックエンドサービスを要求することを可能にすることができる。他のクライアント（またはアプリ）も、ユーザにアクセスを提供するためにＨＵ２５０上でミラーリングされる場合がある。
【0050】
クライアント２０２はまた、１つ以上の所定のユーザインターフェース（「ＵＩ」）要素を、ＨＵ２５０のディスプレイ２６５または他の何らかのデバイス上に出現させるように構成され得る。例えば、第１のアプリ２０５および第２のアプリ２１５の両方は、ＨＵ２５０を含む車両の製造業者に関連付けることができ、実行されると、製造業者に関連するＵＩ要素を、ディスプレイ２６５または他の何らかのデバイス上に出現させ得る。これらの要素の一部には、製造業者のロゴ、または製造業者を識別する他のマーク、色、または背景デザインが含まれる場合がある。これらのＵＩ要素はまた、製造業者が生産した車両のタイプに固有の場合もある。一実施形態では、第１のアプリ２０５および第２のアプリ２１５が異なるＯＳ用に設計されている場合でも、第１のアプリ２０５によって表示されるようにされる所定のＵＩ要素は、第２のアプリ２１５に由来するものと同一または少なくとも実質的に同様であり得る。
【0051】
別の場合では、クライアント２０２は、スマートフォンによって投影される代わりに、ＨＵ２５０にインストールされ、直接実行され得る。この例では、ユーザは、ＨＵ２５０を介して第１のアプリ２０５または第２のアプリ２１５と相互作用することができ、上記のＵＩ要素はまた、ディスプレイ２６５または他のいくつかのコンポーネント上に表示することもできる。そのようにインストールされるクライアント２０２は、ＨＵ２５０のＯＳのために特別に設計され得、すなわち、それらは、ＨＵ２５０上でネイティブに動き得る。スマートフォンまたはＨＵに加えて、クライアント２０２は、ラップトップもしくはタブレット、またはインフォテインメントシステムの後部座席ディスプレイなどの車両の他のコンポーネントなどの他の好適なデバイス上にインストールおよび実行することができる。さらに、ユーザは、ＨＵ２５０の存在なしに、クライアント２０２と相互作用することができる。例えば、ユーザは、車外またはＨＵを有さない車内で、第１のスマートフォン２１０上の第１のアプリ２０５にアクセスしてもよい。
【0052】
クライアント２０２がどのようにユーザに利用可能にされても、ユーザは、バックエンドサービスの要求を開始することができる。前述のように、一部のバックエンドサービスは、車両に向けられる場合がある。例えば、サービスのうちのいくつかは、車両のロック解除またはロック、エンジンの開始または停止、ヘッドライトまたは警笛のアクティブ化または非アクティブ化、気候システムの開始または停止（またはその開始または停止のスケジューリング）、またはバッテリ充電の開始、停止、スケジューリング、または駐車料金の支払いなど、遠隔でトリガされる車両によって実行されるアクションである場合がある。
【0053】
別の例として、一部のサービスは、燃料レベル、給油計算（給油までに何マイルまたはどのくらいの時間が必要か）、エンジン診断、燃費、走行距離計の読み取り値、車両識別番号（「ＶＩＮ」）、メンテナンス履歴、有料駐車スペースの残り時間、現在の車両の場所、またはガソリンスタンドもしくは充電ステーションもしくはディーラーの場所など、車両またはその周辺地域に関するデータの要求を満たす場合がある。条件またはイベントによってプロンプトが表示されるサービスなどの他のサービスは、必ずしもユーザによって要求されるとは限らない場合がある。例としては、リコール通知、定期メンテナンス、もしくはブレーキ、バッテリ、またはタイヤなどのコンポーネントの既存または潜在的な故障または劣化など、車両に関する通知または警告を提供することが含まれる。
【0054】
バックエンドサービスはまた、バックエンドサービスサーバ２３０の１つなどの他のプラットフォームからも要求され得る。例えば、製造業者サーバ２３５は、車両に関連する操作データまたはユーザに関連する消費データなど、ユーザの車両からデータを取得しようとするサービスを要求することができる。このスキーム下で、製造業者サーバ２３５は、ユーザの車両の現在の走行距離計の読み取りを要求することができ、次いでこれを使用して、ユーザに配信されるメンテナンスリマインダを生成することができる。一例として、消費データは、給油停止の頻度を含むことができ、そこから、製造業者サーバ２３５は、ユーザを特定のブランドの燃料に誘導するための金銭的誘因を生成することができる。バックエンドサービスの配信は、どのコンポーネントまたはエンティティがそれらを開始するかに関係なく、共通のプロトコルを介してウェブサービスサーバ２２５によって調整され得る。
【0055】
ユーザに配信できるバックエンドサービスは他にもたくさんあるが、ここに記載されている例は限定的なものを意図するものではない。実際、他の機械または構造がこの構成を利用できるため、バックエンドサービスは、必ずしも車両に向けられたものに限定されない場合がある。
【0056】
オプションとして、バックエンドサービスが車両用である場合、ユーザは、そのようなサービスを受けるために複数の車両を登録してもよい。例えば、ユーザは、クライアント２０２にアクセスし、ユーザの車両およびユーザの家族のメンバーが所有する１つ以上の他の車両を登録してもよい。クライアント２０２は、ユーザが登録された車両を切り替えることを可能にするスイッチング機能を含むようにさらに構成することができ、それにより、サービスを各車両に選択的に与えることができる。家族の各メンバーはまた、スマートフォン上のクライアント２０２を介して自分の車両（および他の車両）を登録してもよい。
【0057】
共通のプロトコルは構造化されるが、１つのオプションとして、バックエンドサービスの標準セットを実装してもよい。例えば、共通のプロトコルがＡＰＩの標準セットで構成されている場合、これらのＡＰＩは、上記のバックエンドサービスまたは他の好適なサービスのいずれかを実装するように設計できる。そのため、アプリが異なるＯＳ用に構成されている場合でも、事前定義された均一のメッセージングスキームを、様々な車両製造業者などの様々なエンティティのアプリで容易に使用可能であり得る。一例として、第１の製造業者のｉＯＳおよびアンドロイドアプリならびに第２の製造業者のｉＯＳおよびアンドロイドアプリはすべて、共通のプロトコルを利用して、ウェブサービスサーバ２２５と信号を交換し、ユーザまたはいくつかの他のエンティティが多種多様なバックエンドサービスをリクエストすることを可能にし得る。このプロセスは、そのようなサービスを開始するために通常必要なすべての論理でアプリに負担をかけることなく実行できる。
【0058】
共通のプロトコルはまた、異なるＯＳの存在から生じるあらゆるバリエーションに対応するように構成することもできる。例えば、ほとんどすべてのモバイルデバイスは、プッシュ通知を処理する必要があり、あるＯＳで処理するためのスキームは、別のＯＳのスキームとは異なる場合がある。共通のプロトコルは、これらのプラットフォーム固有のバリエーションを考慮に入れて、ウェブサービスサーバ２２５が異なるクライアント２０２にプッシュ通知を配信できるようにすることができる。
【0059】
一実施形態では、共通のプロトコルは、クライアント２０２がバックエンドサービスを実行するために必要となる可能性があるデータを供給することを要求するように設計できる。例えば、共通のプロトコルがＡＰＩで構築されている場合、ＡＰＩは、車両に関する特定の情報（ＶＩＮ、現在地、またはアカウント識別（「ＩＤ」）など）、またはサービスの要求の一部として送信される所有者を要求する場合がある。このデータは、可能であれば、クライアント２０２またはウェブサービスサーバ２２５を含めてキャッシュして、待ち時間を短縮することができ、一構成では、データフィールドの選択は、プロトコルの均一性を増加させるために車両の製造業者に関して依存しない場合がある。先に述べたように、共通のプロトコルは拡張可能（専有または共有）である可能性があるため、拡張は、１つ以上の製造業者または製造業者のブランドの、もしくは製造業者の特定のクライアント２０２の特定のデータフィールドに対応するように実装され得る。（このようなデータフィールドの一例は、車両のブランドまたはバージョンであり得る。）さらに、特定の製造業者のクライアント２０２によってのみ使用され得る共通のプロトコルのＡＰＩのセットなど、共通のプロトコルの一部は、１つ以上の製造業者に制限される場合がある。
【0060】
図３を参照すると、ウェブサービスサーバ２２５およびいくつかのバックエンドサービスサーバ２３０が示されている。この図では、バックエンドサービスサーバ２３０の１つは、製造業者サーバ２３５であり、別のサーバ２３０は、第三者サーバ２４０であるが、他の構成も可能である。一例として、製造業者サーバ２３５は、車両の製造業者によって制御され、第三者サーバ２４０は、そのような車両に衛星ベースの娯楽サービスを提供する第三者によって制御される。
【0061】
一実施形態では、ウェブサービスサーバ２２５は、プロセッサ３０５、メモリ３１０、第１のネットワークインターフェースカード（「ＮＩＣ」）３１５、第２のＮＩＣ３２０、および分析エンジン３２５を含むことができる。プロセッサ３０５は、メモリ３１０、第１のＮＩＣ３１５、第２のＮＩＣ３２０、および分析エンジン３２５のそれぞれに通信可能に結合され、その動作を管理することができる。
【0062】
メモリ３１０は、命令を含む様々なデータを格納して、ウェブサービスサーバ２２５が本明細書に記載のプロセスを実施できるようにすることができる。一例として、メモリ３１０はまた、クライアント２０２またはバックエンドサービスサーバ２３０からの情報をキャッシュするための１つ以上のキャッシュ３３０を含むことができる。一構成では、第１のＮＩＣ３１５は、ウェブサービスサーバ２２５とクライアント２０２との間の有線または無線（または両方の）通信を容易にするように構成することができ、第２のＮＩＣ３２０は、バックエンドサービスサーバ２３０との交換のために同じことを行うように構成することができる。そうするために、第１のＮＩＣ３１５および第２のＮＩＣ３２０の両方は、有線または無線信号（またはその両方）を送受信するための回路およびソフトウェアを含むことができる。しかしながら、別個のＮＩＣは必要とされない場合があり、一実施形態では、ウェブサービスサーバ２２５は、単一のＮＩＣを有することができる。
【0063】
分析エンジン３２５は、クライアント２０２、ウェブサービスサーバ２２５、およびバックエンドサービスサーバ２３０またはこれらのコンポーネントの任意の他の好適なセットの間の相互作用に基づいてデータを分析し、この分析に基づいてレポートを生成するように構成することができる。分析エンジン３２５は、このデータを分析することを可能にするための回路およびソフトウェアを含むことができ、一例として、機械学習（「ＭＬ」）または人工知能（「ＡＩ」）モデルが、そのソフトウェアの一部であり得る。これらのモデルは、収集されたデータを処理し、レポートの一部となり得る傾向または他の基準を識別することができる。傾向または基準の例には、車両の診断またはパフォーマンス、およびバックエンドサービスの使用に関連するユーザの習慣が含まれ得る。これらのモデルはまた、他の車両など、他のコンポーネントにインストールされている他のＡＩまたはＭＬソフトウェアを更新するために使用できる。別のオプションでは、分析エンジン３２５は、車両またはいくつかの他のサーバなどのいくつかの他のデバイス上にインストールすることができるが、ウェブサービスサーバ２２５は、依然としてユーザまたはその車両に関連するデータを、遠隔に位置する分析エンジン３２５に提供することができる。
【0064】
一構成では、製造業者サーバ２３５は、プロセッサ３３５、メモリ３４０、およびＮＩＣ３４５を含むことができ、プロセッサ３３５は、メモリ３４０およびＮＩＣ３４５の両方に通信可能に結合され、その動作を制御することができる。ここには示されていないが、第三者サーバ２４０は、同様の構成を含むことができる。一例として、メモリ３４０は、製造業者サーバ２３５の動作を可能にするデータを記憶することができ、このデータの一部は、製造業者が販売またはリースした車両の所有者、借手、またはユーザに関する情報を含むことができる。第三者サーバ２４０の場合、そのメモリが格納するデータの一部は、サーバ２４０を制御する第三者から衛星ベースの娯楽サービスを受信またはサブスクライブする製造業者の車両の所有者、借手、またはユーザに関する情報を含むことができる。ＮＩＣ３４５は、製造業者サーバ２３５とウェブサービスサーバ２２５との間、および製造業者サーバ２３５と第三者サーバ２４０との間の通信交換をサポートするように構成することができる。一実施形態では、製造業者サーバ２３５および第三者サーバ２４０の両方は、デバイス上に１つ以上のクライアント２０２をインストールしたユーザが、製造業者サーバ２３５または第三者サーバ２４０と直接データを交換することを可能にし得るＮＩＣまたはいくつかの他のインターフェースを含むことができる。
【0065】
図４を参照すると、通信交換を管理する方法４００が示されている。方法４００のステップは、ここでは時系列順で提示されているが、本明細書で説明される方法４００および他の概念は、必ずしもこの順序に限定されない。さらに、方法４００は、図４に示されているものと比較して、追加のまたはさらに少ないステップを含むように変更してもよい。方法４００の一般的な概要が最初に提示され、その後、ステップおよびいくつかの例のより詳細な（ただし、非限定的な）説明が続く。方法４００は他のシステムまたはコンポーネントで実施することができるが、方法４００を説明するのを助けるために図２および図３を参照する。
【0066】
ステップ４０５で、ユーザは、クライアントを登録してバックエンドサービスを要求することができ、ステップ４１０で、ユーザは、クライアントを起動し、クライアントを介して１つ以上のサービスを要求することができる。ステップ４１５で、要求は、共通のプロトコルを介して送信することができ、ステップ４２０で、要求は、ウェブサービスサーバによって受信することができる。ステップ４２５で、ウェブサービスサーバは、サービス要求を実行するために必要な任意のバックエンドサービスサーバを識別でき、ステップ４３０に示されるように、識別されたバックエンドサービスサーバと、この要求の実行を調整することができる。決定ブロック４３５で、バックエンドサービスの要求に対する応答が受信された場合、ウェブサービスサーバは、ステップ４４０に示されるように、共通のプロトコルを介してクライアントに指示を送信することができる。ステップ４４５で、方法４００は、共通のプロトコルを使用する第２のクライアントを介して第２のユーザに対して繰り返すことができる。
【0067】
第１のスマートフォン２１０上に第１のアプリ２０５をインストールしたユーザが所有する車両のロックを遠隔で解除する要求の次の例を考察する。最初に、ユーザは、第１のアプリ２０５を起動してもよく、これにより、一意の識別（「ＩＤ」）を生成し、ウェブサービスサーバ２２５に対してユーザのアカウントの登録および認証を容易にすることができる。このアカウントは、ユーザの車両の製造業者に関連付けることができる。この例では、ユーザは、ユーザの車両を介して第三者から衛星ベースの娯楽サービスを受信するようにサブスクライブすることができる。一実施形態では、第１のアプリ２０５は、ウェブサービスサーバ２２５を介して、第三者に関するユーザのアカウントの登録および認証を可能にすることもできる。次に、ウェブサービスサーバ２２５は、製造業者サーバ２３５を用いて製造業者に関連するユーザのアカウント、および第三者サーバ２４０を用いて第三者に関連付けられたユーザのアカウントを登録および認証することができる。
【0068】
他の構成は、ここで可能である。例えば、第１のアプリ２０５とは異なる可能性がある第三者に関連するアプリは、第三者サーバ２４０を用いて第三者へのユーザのアカウントの登録および認証を可能にすることができる。別の例として、ユーザは、第１のアプリ２０５を使用して、製造業者サーバ２３５を用いて製造業者へのユーザのアカウントを最初に登録および認証することができる。これらの場合、製造業者サーバ２３５および第三者サーバ２４０は、ウェブサービスサーバ２２５を用いて製造業者および第三者へのユーザのアカウントを（それぞれ）登録および認証することができる。別のオプションでは、第１のアプリ２０５および第三者のアプリ（必要な場合）を車両（またはいくつかの他のデバイス）のＨＵ２５０上にインストールしてもよく、そこから登録および認証を始めることができる。登録および認証ステップの一部として、ユーザは、製造年、モデル、型、現在の走行距離、ＶＩＮ、アカウント番号、または他の関連情報など、ユーザおよびユーザの車両に関する関連情報を提供できる。
【0069】
登録および認証プロセスに続いて、ユーザは、第１のスマートフォン２１０上の第１のアプリ２０５を介して、ユーザの車両を遠隔でロック解除するバックエンドサービスを要求してもよい。一構成では、第１のアプリ２０５およびウェブサービスサーバ２２５は、セッションを認証することができ、この認証を使用して、製造業者サーバ２３５および第三者サーバ２４０の任意の検証要件を普遍的に満たすことができる。第１のアプリ２０５とウェブサービスサーバ２２５との間の交換は、それらの使用のために確立された共通のプロトコルを介して行われ得る。一例として、第１のアプリ２０５は、車両の遠隔ロック解除をトリガするように特別に設計されたＡＰＩを介して、ウェブサービスサーバ２２５に信号送信することができる。要求は、ＶＩＮおよびアカウントＩＤなど、それを実行するために必要な任意のデータを含み得、ウェブサービスサーバ２２５のプロセッサ３０５は、それがキャッシュされている場合、メモリ３１０からこのデータの少なくとも一部を取得し得る。
【0070】
ウェブサービスサーバ２２５は、製造業者サーバ２３５および第三者サーバ２４０の実装詳細で構成されているので、ウェブサービスサーバ２２５がサービス要求を受信すると、ウェブサービスサーバ２２５のプロセッサ３０５は、第１のアプリ２０５に代わって製造業者サーバ２３５および第三者サーバ２４０と、この要求の実行を調整することができる。例えば、プロセッサ３０５は、製造業者サーバ２３５と通信して、ロック解除要求について製造業者サーバ２３５から許可を受信することができる。この信号の交換は、製造業者サーバ２３５用に確立された既存のプロトコルに準拠できる。つまり、このサービスを実施するために製造業者サーバ２３５のＡＰＩを変更する必要はない。製造業者サーバ２３５との通信のためのプロトコルは、主に、製造業者プロトコルが製造業者に専有または固有であり得るため、共通のプロトコルとは異なる。
【0071】
許可に続いて、ウェブサービスサーバ２２５のプロセッサ３０５は、第三者サーバ２４０と通信して、遠隔ロック解除コマンドを開始することができる。この交換の一部として、ウェブサービスサーバ２２５は、第三者サーバ２４０に、製造業者サーバ２３５からの要求に対する許可、および遠隔ロック解除を実行するために必要な任意のデータを提供することができる。
【0072】
第三者サーバ２４０がサービスを実施している間、ウェブサービスサーバ２２５のプロセッサ３０５は、応答についてサーバ２４０をポーリングし得、遠隔ロック解除が完了すると、サーバ２４０は、プロセッサ３０５に適切な指示で信号送信し得る。車両に接触できなかった場合など、第三者サーバ２４０が要求を処理できなかった場合、サーバ２４０は、ウェブサービスサーバ２２５のプロセッサ３０５にエラー状態を返すことができる。いずれの場合も、製造業者サーバ２３５のように、遠隔ロック解除サービス（または任意の他の既存のサービス）のために第三者サーバ２４０のＡＰＩに変更を加える必要はない。また、サーバ２４０のプロトコルが第三者に専有または固有であり得るため、第三者サーバ２４０との通信のためのプロトコルもまた、共通のプロトコルとは異なり、製造業者サーバ２３５に関連するプロトコルとは異なる可能性がある。
【0073】
第三者サーバ２４０からどちらの指示を受信しても、ウェブサービスサーバ２２５のプロセッサ３０５は、結果の指示で製造業者サーバ２３５に信号送信し得る。加えて、ウェブサービスサーバ２２５のプロセッサ３０５は、共通のプロトコルを介して第１のアプリ２０５に信号送信し、バックエンドサービスが正常に完了したかどうかなどの要求のステータスを指示することができる。クライアント２０２から発信される交換と同様に、（共通のプロトコルを介した）ウェブサービスサーバ２２５からのメッセージは、様々な製造業者に関連する複数のクライアント２０２に対して均一であり得る。したがって、ウェブサービスサーバ２２５のプロセッサ３０５は、様々なバックエンドサービスサーバ２３０からの多様なメッセージを変換し、それらをクライアント２０２が期待する形式に変換することができる。それに応答して、第１のアプリ２０５は、ユーザのための指示を生成することができる。
【0074】
別の例では、第２のユーザは、クライアント２０２、この場合、第２のスマートフォン２２０上にインストールされた第２のアプリ２１５のための登録および認証プロセスを完了した可能性がある。次に、第２のユーザは、第２のアプリ２１５を介してバックエンドサービスの要求を開始し得る。この例では、サービスは、第２のユーザの車両の遠隔ロック解除のためのものであり、上記のプロセスは、第２のユーザの車両に関して繰り返すことができる。このプロセスの一部として、ウェブサービスサーバ２２５は、第１のアプリ２０５の場合と同様に、共通のプロトコルを介して第２のアプリ２１５と信号を交換することができる。実際、ウェブサービスサーバ２２５は、第１のユーザおよび第２のユーザに対する両方の遠隔ロック解除要求の実行を互いに同時に調整することができる。したがって、バックエンドサービスは、ユーザが使用するクライアント２０２が異なるＯＳ用に設計されている場合でも、共通のプロトコルを使用して、複数のユーザに対して同時に（または少なくとも時間的にいくらか重複して）実行することができる。この原理は、他のバックエンドサービスが関与する場合、ユーザが異なるブランドの車両を所有する場合、またはユーザの車両が異なる製造業者によって製造され、各々が独自の製造業者サーバ２３５を制御する場合など、追加の状況に拡張される。
【0075】
前の例では、ユーザは、クライアント２０２を介してバックエンドサービスを開始した。しかしながら、バックエンドサービスはまた、バックエンドサービスサーバ２３０またはウェブサービスサーバ２２５から始めてもよい。例えば、製造業者は、その車両のグループに対してリコール通知を発行することを望む場合があり、製造業者サーバ２３５は、通知を生成し、それをウェブサービスサーバ２２５に送信してもよい。通知は、ウェブサービスサーバ２２５が影響を受ける車両を識別するために使用できる関連データを含み得、必要に応じて、サーバ２２５は、それ自体のメモリ３１０からデータを検索するか、または様々なクライアント２０２に追加情報をポーリングすることができる。
【0076】
次に、通知に応答して、ウェブサービスサーバ２２５は、影響を受ける車両に関連付けられたクライアント２０２に（共通のプロトコルを介して）信号送信することができ、クライアント２０２は、リコール通知をユーザのために人間が知覚できる形式でレンダリングさせることができる。ウェブサービスサーバ２２５はまた、影響を受けた車両へのリコール通知の配信の成功（または失敗）を示す１つ以上のリターンを用いて製造業者サーバ２３５に信号送信することができる。この例では、製造業者は、製造業者サーバ２３５に関連するＡＰＩを変更する必要なしに、単純な通知を生成し、それを多種多様のプラットフォーム上にインストールされた多数のクライアント２０２に首尾よく配布するタスクをウェブサービスサーバ２２５に引き渡すことができる。
【0077】
上記のように、ウェブサービスサーバ２２５は、バックエンドサービスサーバ２３０から受信したデータをキャッシュし得る。例えば、ユーザが、クライアント２０２を介してエンジン診断レポートを要求した可能性があり、このデータは、第三者サーバ２４０によって生成され得る。ウェブサービスサーバ２２５が第三者サーバ２４０から診断データを受信すると、サーバ２２５は、この情報をキャッシュすることができる。
【0078】
この方法でデータをキャッシュすることにより、ウェブサービスサーバ２２５は、そのようなサービスが利用可能であり得る場合に、バックエンドサービスの要求に応答することを可能にし得る。例えば、製造業者は、特定のクライアント２０２について、エンジン診断レポートの生成を３０分ごとに１回に制限してもよい。これは、製造業者が、このサービスの過度の使用について第三者サーバ２４０を制御するエンティティによって課金される可能性があるためである。したがって、３０分の期間が満了する前にユーザが別の診断レポートを要求する場合、ウェブサービスサーバ２２５のプロセッサ３０５は、キャッシュされたデータを単に検索することができ、サーバ２２５は、データを要求するクライアント２０２に向けることができる。ウェブサービスサーバ２２５は、第三者サーバ２４０（または任意の他のバックエンドサービスサーバ２３０）に信号送信する必要なしに、この応答を実行することができる。
【0079】
３０分の期間が満了すると、ウェブサービスサーバ２２５は、通常の方法で診断レポートの新しい要求に応答することができる。このキャッシング手順は、他のバックエンドサービスに適用することができ、バックエンドサービスサーバ２３０のいずれも、キャッシュされたデータを取得することによってウェブサービスサーバ２２５に要求に応答するように強制し得る制限を実装し得る。このキャッシング機能はまた、ウェブサービスサーバ２２５とクライアント２０２との間の相互作用に適用されるルールの開発を可能にし、これらのルールは、バックエンドサービスサーバ２３０によって設定された任意のルールから逸脱し得る。
【0080】
上に提示された例では、バックエンドサービスは、複数のバックエンドサービスサーバ２３０または単一のサーバ２３０の参加を含み得る。したがって、ウェブサービスサーバ２２５は、それらがすべて異なるエンティティによって制御され、各々が異なるＡＰＩのセットを公開している場合でも、多くの異なるバックエンドサービスサーバ２３０へのサービスの配信を調整するように構成することができる。さらに、システム２００は、ユーザの増加に対応するため、またはユーザに新しいサービスを提供するために新しいバックエンドサービスサーバ２３０を実装することができるので、容易に拡張可能である。ウェブサービスサーバ２２５と複数のバックエンドサービスサーバ２３０との間の構成がどれほど複雑であり得るかに関係なく、クライアント２０２は、共通のプロトコルを介してサービスの利益を受け取り続けることができる。したがって、複数のバックエンドサービスサーバ２３０との相互作用とは対照的に、共通のプロトコルを介したクライアント２０２のウェブサービスサーバ２２５への通信を制限することにより、クライアント２０２の複雑さを軽減することができる。
【0081】
一実施形態では、クライアント２０２は、ウェブサービスサーバ２２５とのみ通信を交換することに限定され得、これは、バックエンドサービスを要求（または受信）するときに、他のデバイスと通信できないことを意味する。（ＨＵ２５０のような特定のコンポーネントに対して、ただし、特に相互作用がＨＵ２５０への投影に限定されている場合、例外を実施することができる。）この制限は、クライアント２０２のセキュリティを強化し、それらをさらに開発しやすくすることができる。
【0082】
上で説明したように、バックエンドサービスを調整することでウェブサービスサーバ２２５にタスクを課すことは、クライアント２０２がそのようなサービスを受信することを可能にし、複数のバックエンドサービスサーバ２３０と相互作用する負担からクライアントを解放する。さらに、クライアント２０２は、サービスのための共通のプロトコルに依存しているので、クライアント２０２は、それらが異なるＯＳ用に設計されている場合でも、コードのかなりの部分を共有するように開発することができる。
【0083】
図５を参照すると、異なるＯＳのアプリ間で再利用可能なコードベースの使用を有効にするための方法５００が示されている。方法５００のステップは、ここでは時系列順で提示されているが、本明細書で説明される方法５００および他の概念は、必ずしもこの順序に限定されない。さらに、方法５００は、図５に示されているものと比較して、追加のまたはさらに少ないステップを含むように変更されてもよい。方法５００の一般的な概要が最初に提示され、その後、ステップおよびいくつかの例のより詳細な（ただし、非限定的な）説明が続く。
【0084】
ステップ５０５で、ネイティブコードセクションを第１のアプリの一部として定義することができる。ステップ５１０で、再利用可能なコードセクションもまた、第１のアプリの一部として定義することができる。ステップ５１５で、ステップ５２０に示されるように、第２のネイティブコードセクションを第２のアプリの一部として定義することができ、再利用可能なコードセクションを第２のアプリの一部として実装することができる。ステップ５２５で、サーバとの交換のための第１および第２のアプリに対して共通の通信セットを定義することができる。
【0085】
図６を参照すると、ブロック図形式の２つのクライアント２０２の例が示されている。方法５００を説明するのを助けるために図２、図３、および図６を参照するが、方法５００は、他のシステム、コンポーネント、またはオブジェクトを用いて実施してもよい。この例では、クライアント２０２のうちの１つは、第１のスマートフォン２１０上にインストールすることができる第１のアプリ２０５であり、他のクライアント２０２は、第２のスマートフォン２２０上にあり得る第２のアプリ２１５である。第１のスマートフォン２１０は、第１のアプリ２０５が設計された第１のＯＳをロードされ得、第２のスマートフォン２２０は、その上にインストールされた第２のＯＳを有し得、そのために第２のアプリ２１５は開発されている。また、この例では、第１のアプリ２０５は第２のＯＳと互換性がなく、第２のアプリ２１５は第１のＯＳと互換性がない。
【0086】
クライアント２０２の部分は、それらがクライアント２０２の最終的な構成において互いに静的にリンクされているように埋め込まれ得る。代替的に、任意の数の部分が、クライアント２０２に関連して個別のアイテムとして配信またはアクセスされ得、それらは、クライアント２０２が実行されるときに動的にリンクされ得る。
【0087】
一構成では、第１のアプリ２０５は、ネイティブコードセクション６０５および再利用可能なコードセクション６１０を含むことができ、ネイティブコードセクション６０５は、通信モジュール６１５、ヘッドユニット（「ＨＵ」）モジュール６２０、デバイス仕様モジュール６２５、およびユーザインターフェース（「ＵＩ」）仕様モジュール６３０などのいくつかのセクションまたはモジュールから構成することができる。同様に、第２のアプリ２１５は、ネイティブコードセクション６３５および再利用可能なコードセクション６４０を含むことができ、ネイティブコードセクション６３５は、通信モジュール６４５、ＨＵモジュール６５０、デバイス仕様モジュール６５５、およびＵＩ仕様をモジュール６６０を有することができる。
【0088】
ネイティブコードセクション６０５およびネイティブコードセクション６３５は、クライアント２０２の対応するＯＳにネイティブであるコードを用いて開発され得る。具体的には、ネイティブコードセクション６０５のコードは、第１のＯＳにネイティブであり得、ネイティブコードセクション６３５のコードは、第２のＯＳにネイティブであり得る。一実施形態では、ネイティブコードセクション６０５、６３５の開発および構造は、共通のプロトコルに基づき得る。すなわち、ネイティブコードセクション６０５、６３５は、共通のプロトコルの均一性、したがって、ウェブサービスサーバ２２５との相互作用を利用するように設計され得る。ネイティブコードセクション６０５の基礎となるネイティブコードは第２のＯＳと互換性がないが、ネイティブコードセクション６０５のすべてまたは少なくとも実質的な部分は、第１のＯＳ上で実行される任意のクライアント２０２に実装され得る。同じ原理が、ネイティブコードセクション６３５に適用され、なぜなら、それは、第２のＯＳ上で実行される任意のクライアント２０２に統合され得るからである。
【0089】
しかしながら、再利用可能なコードセクション６１０は、クロスプラットフォームコード、または異なるＯＳを含む異なるプラットフォーム上で実行可能であるかまたは異なるプラットフォームに依存しないコードを用いて開発され得る。したがって、再利用可能なコードセクション６１０は、第１のＯＳおよび第２のＯＳの両方と互換性があり、第１のアプリ２０５用に開発され得るが、再利用可能なコードセクション６４０として第２のアプリ２１５に再利用および実装することができる。例として、Ｒｅａｃｔ－Ｎａｔｉｖｅのようなクロスプラットフォーム開発ツールを使用して、再利用可能なコードセクションを開発できる。一実施形態では、再利用可能なコードセクション６１０は、第１のアプリ２０５の全コードの約９０％を構成し得、残りの１０％は、ネイティブコードセクション６０５の一部として開発される。第２のアプリ２１５に対するネイティブコードセクション６３５および再利用可能なコードセクション６４０の比率は同等であり得る。したがって、クライアント２０２のかなりのシェアが、異なるＯＳ間で再利用可能であり得る。
【0090】
一構成では、再利用可能なコードセクション６１０、６４０は、対応するクライアント２０２が実行されるときに表示するための所定のＵＩ要素の生成を担当することができる。一例として、ＵＩ要素は、第１のスマートフォン２１０、第２のスマートフォン２２０、ＨＵ２５０のディスプレイ２６５、またはいくつかの他の好適なデバイス上に表示することができる。例えば、第１のアプリ２０５が車両製造業者に関連する場合、再利用可能なコードセクション６１０は、第１のアプリ２０５が実行されたとき、製造業者またはそのブランドのいずれかに関連付けられた、もしくはそれを示す１つ以上のＵＩが第１のスマートフォン２１０またはディスプレイ２６５上に表示されるように構成することができる。一例として、第１のアプリ２０５のために表示されるＵＩ要素は、第２のアプリ２１５のために提示されるものと同一であり得る。これは、単一の組織が第１のアプリ２０５および第２のアプリ２１５の操作または配布を担当または制御する場合、または複数の組織が同様のＵＩを提示したい場合に有用であり得る。この概念はまた、クライアント２０２が実行されるときに、ブロードキャストされるオーディオまたはトリガされるハプティックスなど、人間が知覚できる他の任意の要素にも適用することができる。
【0091】
ローカル通知がどのようにレンダリングされるかなど、主に第１のＯＳと第２のＯＳとの違いに基づいて、再利用可能なコードセクション６１０と再利用可能なコードセクション６４０との間に若干のバリエーションが存在し得る。それにもかかわらず、異なるＯＳ用に設計されたクライアント２０２間で再利用可能なコードの量はかなりのものであり、典型的に、少なくとも９０％または９５％である。
【0092】
ネイティブコードセクション６０５、６３５に戻ると、通信モジュール６１５、６４５は、ウェブサービスサーバ２２５との交換を容易にし、それらの対応する車両に関するデータを維持するように構成され得る。さらに、ＨＵモジュール６２０、６５０は、例えば、ＨＵ２５０との交換を容易にし、ＨＵ２５０との接続データを維持し、場合によっては、モバイルネットワークと、ＨＵ２５０上に投影されるアプリとの間の交換を管理するように設計され得る。デバイス仕様モジュール６２５、６５５は、例えば、第１のスマートフォン２１０および第２のスマートフォン２２０の特定の特性を（それぞれ）維持するように開発することができる。ＵＩ要素を表示するときにアクセスできるこれらの特性の例には、デバイスの確立された場所（北米またはアジアなど）、選択した言語（英語またはフランス語など）、または画面サイズおよび解像度が挙げられる。ＵＩ仕様モジュール６３０、６６０は、第１のスマートフォン２１０または第２のスマートフォン２２０、もしくはＨＵ２５０またはいくつかの他のデバイスのディスプレイ２６５上に（それぞれ）提示される、スキンまたはテーマなどのＵＩのタイプを指定するように設計することができる。一例として、この選択は、車両の製造業者または製造業者の特定のブランドの同一性に基づく。オプションとして、この選択機能により、異なる製造業者または他のエンティティに関連する再利用可能なコードを再利用可能なコードセクション６１０、６４０の一部にすることができ、選択されていない製造業者（またはエンティティ）のコードは単に無視できる。ネイティブコードセクション６０５およびネイティブコードセクション６３５は、上記の各モジュールを含まない場合があるか、またはここに提示されていない他のモジュールを含む場合があるため、必ずしもこの構成に限定されない。
【0093】
この例示的な構造を考慮すると、クライアント２０２は用途が広く、効率を改善する機会を提供する。例えば、ネイティブコードセクション６０５は、第１のＯＳのために第１のアプリ２０５を配信したい異なる組織のために開発された複数のクライアント２０２に統合され得、なぜなら、それは、ウェブサービスサーバ２２５、または共通のプロトコルとの交換のための共通の通信セットのために設計され得るからである。同様に、ネイティブコードセクション６３５は、第２のＯＳで動作するアプリをリリースしたいこれらの組織の第２のアプリ２１５に実装され得る。様々なクライアント２０２に統合され得るネイティブコードセクション６０５、６３５は、各エンティティの特定の要件に対応するように構成され得る。それにもかかわらず、各ネイティブコードセクション６０５、６３５の９０％以上のようなコードのかなりの部分は、それぞれのＯＳの異なるクライアント２０２間で再利用（または共有）され得る。
【0094】
この利点はまた、組織が複数の部門で構成されており、各部門が第１のＯＳと第２のＯＳの両方のクライアント２０２をリリースする場合にも実現できる。一例として、製造業者は、いくつかの部門を有し、各々が１つ以上の異なるブランドの車両を提供している場合がある。各部門は、その車両ブランドごとに、第１のＯＳおよび第２のＯＳのクライアント２０２をリリースし得る。この場合、ネイティブコードセクション６０５は、（もしあれば）最小限の変更で、各ブランド用の第１のＯＳのクライアント２０２間で共有され得、この構成は、部門によってリリースされる第２のＯＳのクライアント２０２のために複製され得る。クライアント２０２のためにネイティブコードセクション６０５、６３５を再利用するという概念は、同じ組織の部門に限定されないが、それらは、互いに独立している企業を含む異なる組織間でリサイクルされ得る。
【0095】
クライアント２０２の設計はまた、再利用可能なコードセクション６１０、６４０に関して同等の利点を提供する。複数の部門を持つ車両製造業者に関する上記の例を考察する。ここで、再利用可能なコードセクション６１０、６４０は、部門に表示されるＵＩ要素の違いによって必要とされるものを除いて、セクション６１０、６４０に実際に変更を加えることなく、これらの部門のクライアント２０２間で共有され得る。製造業者が実質的に同様のＵＩを表示したい場合には、部門のＵＩのバリエーションに起因する変更でさえ最小限に抑えることができる。（前に説明したように、ＯＳ要件に基づいて、再利用可能なコードセクション６１０と再利用可能なコードセクション６４０の間にはわずかなバリエーションが存在し得る。）この同じ原理は、製造業者が合弁事業またはプロジェクトの一部であった場合など、いくつかの製造業者にさえも適用できる。
【0096】
クライアント２０２によって提供される多様性は、クライアント２０２からウェブサービスサーバ２２５へのバックエンドサービスの実行を容易にするために必要な論理を再配置するプロセスから実現することができる。クライアント２０２とウェブサービスサーバ２２５との間の交換のために共通のプロトコルを採用することもまた、この適応性に寄与できる。他の利点は、クライアント２０２間の共通性および複雑さの低減から生じ得る。例えば、品質保証（「ＱＡ」）テストを含む、アプリ開発に必要なリソースが少なくてすむ可能性があるため、組織はアプリ（更新またはアップグレードを含む）をはるかに迅速に市場に配信できる可能性がある。実際、この設計は、クライアント２０２の均一性のために、重大な欠陥を検出するための１つ以上の「スモークテスト」のような標準の自動化されたテストの実装を可能にし得る。このようなテストでは、ＱＡプロセスに人間が関与する前に欠陥を検出できる。ただし、ここで概説する利点は、組織のアプリに関連する機能の数または品質を低下させることはない。
【0097】
上記のように、図２～図６のシステム、デバイス、方法、プロセス、およびオブジェクトは、本明細書に記載の機能を実現するために、１つ以上のプロセッサおよびメモリ要素を使用し得るか、またはそれに依存し得る。任意の数のプロセッサは、他のデバイスおよびシステムの動作を監視し、デバイスおよびシステムのすべてまたは任意の数のコンポーネント間のプロセスを調整するように特別にプログラムされ得る。プロセッサには、任意の好適なアーキテクチャまたは設計を使用してもよい。例えば、プロセッサは、１つ以上のシングルコアまたはマルチコアアーキテクチャ（またはその両方）で実装されてもよい。
【0098】
本明細書で使用できるプロセッサの例には、マイクロプロセッサ、マイクロコントローラ、デジタルシグナルプロセッサ（「ＤＳＰ」）、およびソフトウェアを実行するか、またはソフトウェアを実行させることができる他の回路（または前述の任意の組み合わせ）が挙げられる。好適なプロセッサのさらなる例には、中央処理装置（「ＣＰＵ」）、アレイプロセッサ（またはベクトルプロセッサ）、グラフィックス処理ユニット（「ＧＰＵ」）、機械学習プロセッサ（「ＭＬＰ」）、フィールドプログラマブルゲートアレイ（「ＦＰＧＡ」）、プログラマブル論理アレイ（「ＰＬＡ」）、特定用途向け集積回路（「ＡＳＩＣ」）、およびプログラマブル論理回路が挙げられる。プロセッサは、プログラムコードに含まれる命令を実行するように構成された少なくとも１つのハードウェア回路（例えば、集積回路）を含むことができる。
【0099】
一構成では、プロセッサは、車両の一部であり得るか、またはスマートフォンに含まれ得るか、もしくはスマートフォンまたは車両から遠隔に配置されているものを含む、ネットワークまたはいくつかの他のシステムのいくつかのコンポーネントの一部として含まれ得る。プロセッサが車両の一部である場合、プロセッサは、例えば、ＨＵまたは車両のいくつかの他のコンポーネントに統合することができる。別の構成では、システムまたはデバイスは、車両、スマートフォン、またはネットワーク（またはそれらの任意の組み合わせ）などの別々の場所に複数のプロセッサを含むことができ、システムまたはデバイスのための処理は、ともに動作するこれらのプロセッサの任意の組み合わせによって処理することができる。別の例として、車両は、ラップトップまたはいくつかの他の機械のような携帯型デバイスの一部であり得る補助プロセッサのプラグインを受け入れるように構成された１つ以上のコネクタまたはインターフェースを有することができる。本明細書に記載のプロセッサのいずれも、特定のタスク（ビデオデータの処理など）に専用であり得るか、または同時か否かにかかわらず、複数の機能を処理するように設計され得る。
【0100】
メモリ（またはメモリ要素）は、システムまたはデバイスの任意のコンポーネントが１つ以上の機能を実施できるようにするための命令などの、データを格納するための任意の数の構造を含むことができる。メモリは、本質的に揮発性または非揮発性（またはその両方）であり得、メモリの例には、ランダムアクセスメモリ（「ＲＡＭ」）、フラッシュメモリ、読み取り専用メモリ（「ＲＯＭ」）、プログラム可能な読み取り専用メモリ（「ＰＲＯＭ」）、消去可能なプログラム可能な読み取り専用メモリ（「ＥＰＲＯＭ」）、電気的に消去可能なプログラム可能な読み取り専用メモリ（「ＥＥＰＲＯＭ」）、レジスタ、キャッシュ、磁気ディスク、光ディスク、ハードドライブ、他の記憶媒体（例えば、半導体、磁気、または光学ベース）、またはそれらの任意の組み合わせが含まれる。
【0101】
プロセッサおよびメモリのいずれも、有線または無線ネットワークを介して他のデバイスに相互に通信可能に結合されてもよい。例えば、有線ネットワークの場合、プロセッサまたはメモリは、ローカルエリアネットワーク（コントローラエリアネットワーク（「ＣＡＮ」）バスなど）を介して通信可能に結合されてもよい。別の例として、プロセッサまたはメモリは、ＢｌｕｅｔｏｏｔｈまたはＷｉＦｉリンク、あるいは専有仕様に基づくものを介して通信可能に結合されてもよい。
【0102】
本出願は、２０１８年８月２１日に出願された米国非仮出願第１６／１０７，７３１号に対する優先権の利益を主張し、この出願は、参照によりその全体が本明細書に組み込まれる。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【国際調査報告】