知財求人 - 知財ポータルサイト「IP Force」
特開2024-104730付与された許可に基づく動的アクセスのための方法およびシステム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024104730
(43)【公開日】2024-08-05
(54)【発明の名称】付与された許可に基づく動的アクセスのための方法およびシステム
(51)【国際特許分類】
G06F 21/62 20130101AFI20240729BHJP
【ＦＩ】
G06F21/62
【審査請求】未請求
【請求項の数】19
【出願形態】ＯＬ
(21)【出願番号】P 2023212723
(22)【出願日】2023-12-18
(31)【優先権主張番号】18/100,921
(32)【優先日】2023-01-24
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】500043574
【氏名又は名称】ブラックベリー リミテッド
【氏名又は名称原語表記】ＢｌａｃｋＢｅｒｒｙ Ｌｉｍｉｔｅｄ
【住所又は居所原語表記】２２００ Ｕｎｉｖｅｒｓｉｔｙ Ａｖｅｎｕｅ Ｅａｓｔ， Ｗａｔｅｒｌｏｏ ＯＮ Ｎ２Ｋ ０Ａ７， Ｃａｎａｄａ
(74)【代理人】
【識別番号】100107489
【弁理士】
【氏名又は名称】大塩 竹志
(72)【発明者】
【氏名】カロル フラツキエヴィチ
(72)【発明者】
【氏名】ダレン エドワード ロジャース
(72)【発明者】
【氏名】ビスワループ ムケルジー
(72)【発明者】
【氏名】ジョーダン トーマス ファーガソン
(72)【発明者】
【氏名】ピエール ピエール ブレ
(57)【要約】
【課題】許可を管理するためのコンピューティングデバイス上の許可サービスにおける方法の提供。
【解決手段】方法は、第１のアプリケーションから、許可サービスにおけるリクエストを受信することであって、リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための第２のアプリケーションに対する許可とを含む、ことと、受信されたリクエストに基づいて、許可サービスにおいてアクションを実行することと、第１のアプリケーションに、第２のアプリケーションがリソースにアクセスするための許可を有しているかどうかを示すアクションの結果を返すこととを含む。
【選択図】なし
【解決手段】方法は、第１のアプリケーションから、許可サービスにおけるリクエストを受信することであって、リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための第２のアプリケーションに対する許可とを含む、ことと、受信されたリクエストに基づいて、許可サービスにおいてアクションを実行することと、第１のアプリケーションに、第２のアプリケーションがリソースにアクセスするための許可を有しているかどうかを示すアクションの結果を返すこととを含む。
【選択図】なし
【特許請求の範囲】
【請求項1】
許可を管理するためのコンピューティングデバイス上の許可サービスにおける方法であって、前記方法は、
第１のアプリケーションから、前記許可サービスにおけるリクエストを受信することであって、前記リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための前記第２のアプリケーションに対する許可とを含む、ことと、
前記受信されたリクエストに基づいて、前記許可サービスにおいてアクションを実行することと、
前記第１のアプリケーションに、前記第２のアプリケーションが前記リソースにアクセスするための前記許可を有しているかどうかを示す前記アクションの結果を返すことと
を含む、方法。
第１のアプリケーションから、前記許可サービスにおけるリクエストを受信することであって、前記リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための前記第２のアプリケーションに対する許可とを含む、ことと、
前記受信されたリクエストに基づいて、前記許可サービスにおいてアクションを実行することと、
前記第１のアプリケーションに、前記第２のアプリケーションが前記リソースにアクセスするための前記許可を有しているかどうかを示す前記アクションの結果を返すことと
を含む、方法。
【請求項2】
前記アクションは、前記識別子が前記許可サービスにおける前記許可と関連付けられているかどうかを決定するためのチェックである、請求項１に記載の方法。
【請求項3】
前記アクションは、前記識別子に前記許可を付与することであり、前記リクエストは、前記第１のアプリケーションの識別子をさらに含み、前記方法は、
前記第１のアプリケーションの前記識別子に基づいて、前記第１のアプリケーションが前記第２のアプリケーションに許可を付与するための許可を有していることを決定すること
をさらに含む、請求項１に記載の方法。
前記第１のアプリケーションの前記識別子に基づいて、前記第１のアプリケーションが前記第２のアプリケーションに許可を付与するための許可を有していることを決定すること
をさらに含む、請求項１に記載の方法。
【請求項4】
前記識別子は、前記オペレーティングシステムに対するユーザ識別子である、請求項１に記載の方法。
【請求項5】
前記許可は、ドメイン、アクション、およびサブジェクトから成る許可ネームを含む、請求項１に記載の方法。
【請求項6】
前記ドメインは、コンピューティングシステム内で一意的なプレフィックスを含む、請求項５に記載の方法。
【請求項7】
前記許可ネームは、前記ドメイン内で一意的である、請求項５に記載の方法。
【請求項8】
前記第１のアプリケーションは、前記許可サービスに対する前記リクエストを使用して前記許可を執行するサービスである、請求項１に記載の方法。
【請求項9】
前記許可サービスは、識別子と許可との間の関連付けを用いて、ランタイムにおいて静的に構成され、かつ、ランタイムの後に動的に構成される、請求項１に記載の方法。
【請求項10】
許可を管理するための許可サービスとして構成されたコンピューティングデバイスであって、前記コンピューティングデバイスは、
プロセッサと、
通信サブシステムと
を備え、
前記コンピューティングデバイスは、
第１のアプリケーションから、前記許可サービスにおけるリクエストを受信することであって、前記リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための前記第２のアプリケーションに対する許可とを含む、ことと、
前記受信されたリクエストに基づいて、前記許可サービスにおいてアクションを実行することと、
前記第１のアプリケーションに、前記第２のアプリケーションが前記リソースにアクセスするための前記許可を有しているかどうかを示す前記アクションの結果を返すことと
を行うように構成されている、コンピューティングデバイス。
プロセッサと、
通信サブシステムと
を備え、
前記コンピューティングデバイスは、
第１のアプリケーションから、前記許可サービスにおけるリクエストを受信することであって、前記リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための前記第２のアプリケーションに対する許可とを含む、ことと、
前記受信されたリクエストに基づいて、前記許可サービスにおいてアクションを実行することと、
前記第１のアプリケーションに、前記第２のアプリケーションが前記リソースにアクセスするための前記許可を有しているかどうかを示す前記アクションの結果を返すことと
を行うように構成されている、コンピューティングデバイス。
【請求項11】
前記アクションは、前記識別子が前記許可サービスにおける前記許可と関連付けられているかどうかを決定するためのチェックである、請求項１０に記載のコンピューティングデバイス。
【請求項12】
前記アクションは、前記識別子に前記許可を付与することであり、前記リクエストは、前記第１のアプリケーションの識別子をさらに含み、前記コンピューティングデバイスは、
前記第１のアプリケーションの前記識別子に基づいて、前記第１のアプリケーションが前記第２のアプリケーションに許可を付与するための許可を有していることを決定すること
を行うようにさらに構成されている、請求項１０に記載のコンピューティングデバイス。
前記第１のアプリケーションの前記識別子に基づいて、前記第１のアプリケーションが前記第２のアプリケーションに許可を付与するための許可を有していることを決定すること
を行うようにさらに構成されている、請求項１０に記載のコンピューティングデバイス。
【請求項13】
前記識別子は、前記オペレーティングシステムに対するユーザ識別子である、請求項１０に記載のコンピューティングデバイス。
【請求項14】
前記許可は、ドメイン、アクション、およびサブジェクトから成る許可ネームを含む、請求項１０に記載のコンピューティングデバイス。
【請求項15】
前記ドメインは、コンピューティングシステム内で一意的なプレフィックスを含む、請求項１４に記載のコンピューティングデバイス。
【請求項16】
前記許可ネームは、前記ドメイン内で一意的である、請求項１４に記載のコンピューティングデバイス。
【請求項17】
前記第１のアプリケーションは、前記許可サービスに対する前記リクエストを使用して前記許可を執行するサービスである、請求項１０に記載のコンピューティングデバイス。
【請求項18】
前記許可サービスは、識別子と許可との間の関連付けを用いて、ランタイムにおいて静的に構成され、かつ、ランタイムの後に動的に構成される、請求項１０に記載のコンピューティングデバイス。
【請求項19】
命令コードを格納するためのコンピュータ読み取り可能な媒体であって、前記命令コードは、許可を管理するための許可サービスとして構成されたコンピューティングデバイスのプロセッサによって実行されると、前記コンピューティングデバイスに、
第１のアプリケーションから、前記許可サービスにおけるリクエストを受信することであって、前記リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための前記第２のアプリケーションに対する許可とを含む、ことと、
前記受信されたリクエストに基づいて、前記許可サービスにおいてアクションを実行することと、
前記第１のアプリケーションに、前記第２のアプリケーションが前記リソースにアクセスするための前記許可を有しているかどうかを示す前記アクションの結果を返すことと
を行わせる、コンピュータ読み取り可能な媒体。
第１のアプリケーションから、前記許可サービスにおけるリクエストを受信することであって、前記リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための前記第２のアプリケーションに対する許可とを含む、ことと、
前記受信されたリクエストに基づいて、前記許可サービスにおいてアクションを実行することと、
前記第１のアプリケーションに、前記第２のアプリケーションが前記リソースにアクセスするための前記許可を有しているかどうかを示す前記アクションの結果を返すことと
を行わせる、コンピュータ読み取り可能な媒体。
【発明の詳細な説明】
【技術分野】
【0001】
（開示の分野）
本開示は、ソフトウェアシステムに関し、特に、ソフトウェアシステムにおける許可管理に関する。
本開示は、ソフトウェアシステムに関し、特に、ソフトウェアシステムにおける許可管理に関する。
【背景技術】
【0002】
（背景）
とりわけ、典型的なオペレーティングシステム（ＯＳ）ファイルシステムネーム空間、ライフファイル、ディレクトリ、またはＵｎｉｘ（登録商標）ドメインソケットにおける各リソースは、有効なユーザおよびグループによって所有される。リソースに対する読み取り、書き込み、および検索／実行アクセスは、所有者、グループ、およびその他全員によって個々に指定される。
とりわけ、典型的なオペレーティングシステム（ＯＳ）ファイルシステムネーム空間、ライフファイル、ディレクトリ、またはＵｎｉｘ（登録商標）ドメインソケットにおける各リソースは、有効なユーザおよびグループによって所有される。リソースに対する読み取り、書き込み、および検索／実行アクセスは、所有者、グループ、およびその他全員によって個々に指定される。
【0003】
各ユーザ、アプリケーション、またはこれらのオペレーティングシステム上のプロセスは、ユーザネームおよびユーザ識別子（ＵＩＤ）によって識別され、グループ識別子（ＧＩＤ）によって識別されたプライマリグループに属する。ユーザはまた、１つ以上の補足グループに属し、また、ＧＩＤによって識別される。
【0004】
システム上で実行される各プロセスは、最初に、例えばシェルのコーリングプロセスのＵＩＤを仮定する。稼働中のプロセスがシステム上のリソースにアクセスすることを必要とする場合、全てのユーザにアクセス許可が与えられていない限り、リソースは、稼働中のプロセスと同じユーザによって所有されなければならないか、または、ユーザはリソースのグループのメンバーでなければならない。
【0005】
複雑なソフトウェアシステムは、多くのユーザを使用し得、多くのユーザおよびグループを伴う多くのリソースを提供し得る。実際のユーザおよびグループは、ソフトウェアがインストールされている異なるホストの間で異なり得る。これは、ユーザグループのメンバーシップおよびリソースに対するアクセス管理を非常に複雑なものにし得る。
【0006】
そのようなソフトウェアシステムにおいて、ＵＩＤおよびＧＩＤは、典型的に、これらのファイルおよびその他のファイルに変更することからシステムを保護するために、リードオンリーファイルシステム上に配置され得るオペレーティングシステムファイル内で追跡される。これは、いったんシステムが配備されてからのＵＩＤおよびＧＩＤの動的作成を防止する。
【発明の概要】
【課題を解決するための手段】
【0007】
本発明は、例えば、以下の項目を提供する。
（項目１）
許可を管理するためのコンピューティングデバイス上の許可サービスにおける方法であって、前記方法は、
第１のアプリケーションから、前記許可サービスにおけるリクエストを受信することであって、前記リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための前記第２のアプリケーションに対する許可とを含む、ことと、
前記受信されたリクエストに基づいて、前記許可サービスにおいてアクションを実行することと、
前記第１のアプリケーションに、前記第２のアプリケーションが前記リソースにアクセスするための前記許可を有しているかどうかを示す前記アクションの結果を返すことと
を含む、方法。
（項目２）
前記アクションは、前記識別子が前記許可サービスにおける前記許可と関連付けられているかどうかを決定するためのチェックである、上記項目に記載の方法。
（項目３）
前記アクションは、前記識別子に前記許可を付与することであり、前記リクエストは、前記第１のアプリケーションの識別子をさらに含み、前記方法は、
前記第１のアプリケーションの前記識別子に基づいて、前記第１のアプリケーションが前記第２のアプリケーションに許可を付与するための許可を有していることを決定すること
をさらに含む、上記項目のいずれか１項に記載の方法。
（項目４）
前記識別子は、前記オペレーティングシステムに対するユーザ識別子である、上記項目のいずれか１項に記載の方法。
（項目５）
前記許可は、ドメイン、アクション、およびサブジェクトから成る許可ネームを含む、上記項目のいずれか１項に記載の方法。
（項目６）
前記ドメインは、コンピューティングシステム内で一意的なプレフィックスを含む、上記項目のいずれか１項に記載の方法。
（項目７）
前記許可ネームは、前記ドメイン内で一意的である、上記項目のいずれか１項に記載の方法。
（項目８）
前記第１のアプリケーションは、前記許可サービスに対する前記リクエストを使用して前記許可を執行するサービスである、上記項目のいずれか１項に記載の方法。
（項目９）
前記許可サービスは、識別子と許可との間の関連付けを用いて、ランタイムにおいて静的に構成され、かつ、ランタイムの後に動的に構成される、上記項目のいずれか１項に記載の方法。
（項目１０）
許可を管理するための許可サービスとして構成されたコンピューティングデバイスであって、前記コンピューティングデバイスは、
プロセッサと、
通信サブシステムと
を備え、
前記コンピューティングデバイスは、
第１のアプリケーションから、前記許可サービスにおけるリクエストを受信することであって、前記リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための前記第２のアプリケーションに対する許可とを含む、ことと、
前記受信されたリクエストに基づいて、前記許可サービスにおいてアクションを実行することと、
前記第１のアプリケーションに、前記第２のアプリケーションが前記リソースにアクセスするための前記許可を有しているかどうかを示す前記アクションの結果を返すことと
を行うように構成されている、コンピューティングデバイス。
（項目１１）
前記アクションは、前記識別子が前記許可サービスにおける前記許可と関連付けられているかどうかを決定するためのチェックである、上記項目のいずれか１項に記載のコンピューティングデバイス。
（項目１２）
前記アクションは、前記識別子に前記許可を付与することであり、前記リクエストは、前記第１のアプリケーションの識別子をさらに含み、前記コンピューティングデバイスは、
前記第１のアプリケーションの前記識別子に基づいて、前記第１のアプリケーションが前記第２のアプリケーションに許可を付与するための許可を有していることを決定すること
を行うようにさらに構成されている、上記項目のいずれか１項に記載のコンピューティングデバイス。
（項目１３）
前記識別子は、前記オペレーティングシステムに対するユーザ識別子である、上記項目のいずれか１項に記載のコンピューティングデバイス。
（項目１４）
前記許可は、ドメイン、アクション、およびサブジェクトから成る許可ネームを含む、上記項目のいずれか１項に記載のコンピューティングデバイス。
（項目１５）
前記ドメインは、コンピューティングシステム内で一意的なプレフィックスを含む、上記項目のいずれか１項に記載のコンピューティングデバイス。
（項目１６）
前記許可ネームは、前記ドメイン内で一意的である、上記項目のいずれか１項に記載のコンピューティングデバイス。
（項目１７）
前記第１のアプリケーションは、前記許可サービスに対する前記リクエストを使用して前記許可を執行するサービスである、上記項目のいずれか１項に記載のコンピューティングデバイス。
（項目１８）
前記許可サービスは、識別子と許可との間の関連付けを用いて、ランタイムにおいて静的に構成され、かつ、ランタイムの後に動的に構成される、上記項目のいずれか１項に記載のコンピューティングデバイス。
（項目１９）
命令コードを格納するためのコンピュータ読み取り可能な媒体であって、前記命令コードは、許可を管理するための許可サービスとして構成されたコンピューティングデバイスのプロセッサによって実行されると、前記コンピューティングデバイスに、
第１のアプリケーションから、前記許可サービスにおけるリクエストを受信することであって、前記リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための前記第２のアプリケーションに対する許可とを含む、ことと、
前記受信されたリクエストに基づいて、前記許可サービスにおいてアクションを実行することと、
前記第１のアプリケーションに、前記第２のアプリケーションが前記リソースにアクセスするための前記許可を有しているかどうかを示す前記アクションの結果を返すことと
を行わせる、コンピュータ読み取り可能な媒体。
（摘要）
許可を管理するためのコンピューティングデバイス上の許可サービスにおける方法であって、前記方法は、第１のアプリケーションから、前記許可サービスにおけるリクエストを受信することであって、前記リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための前記第２のアプリケーションに対する許可とを含む、ことと、前記受信されたリクエストに基づいて、前記許可サービスにおいてアクションを実行することと、前記第１のアプリケーションに、前記第２のアプリケーションが前記リソースにアクセスするための前記許可を有しているかどうかを示す前記アクションの結果を返すこととを含む、方法。
（項目１）
許可を管理するためのコンピューティングデバイス上の許可サービスにおける方法であって、前記方法は、
第１のアプリケーションから、前記許可サービスにおけるリクエストを受信することであって、前記リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための前記第２のアプリケーションに対する許可とを含む、ことと、
前記受信されたリクエストに基づいて、前記許可サービスにおいてアクションを実行することと、
前記第１のアプリケーションに、前記第２のアプリケーションが前記リソースにアクセスするための前記許可を有しているかどうかを示す前記アクションの結果を返すことと
を含む、方法。
（項目２）
前記アクションは、前記識別子が前記許可サービスにおける前記許可と関連付けられているかどうかを決定するためのチェックである、上記項目に記載の方法。
（項目３）
前記アクションは、前記識別子に前記許可を付与することであり、前記リクエストは、前記第１のアプリケーションの識別子をさらに含み、前記方法は、
前記第１のアプリケーションの前記識別子に基づいて、前記第１のアプリケーションが前記第２のアプリケーションに許可を付与するための許可を有していることを決定すること
をさらに含む、上記項目のいずれか１項に記載の方法。
（項目４）
前記識別子は、前記オペレーティングシステムに対するユーザ識別子である、上記項目のいずれか１項に記載の方法。
（項目５）
前記許可は、ドメイン、アクション、およびサブジェクトから成る許可ネームを含む、上記項目のいずれか１項に記載の方法。
（項目６）
前記ドメインは、コンピューティングシステム内で一意的なプレフィックスを含む、上記項目のいずれか１項に記載の方法。
（項目７）
前記許可ネームは、前記ドメイン内で一意的である、上記項目のいずれか１項に記載の方法。
（項目８）
前記第１のアプリケーションは、前記許可サービスに対する前記リクエストを使用して前記許可を執行するサービスである、上記項目のいずれか１項に記載の方法。
（項目９）
前記許可サービスは、識別子と許可との間の関連付けを用いて、ランタイムにおいて静的に構成され、かつ、ランタイムの後に動的に構成される、上記項目のいずれか１項に記載の方法。
（項目１０）
許可を管理するための許可サービスとして構成されたコンピューティングデバイスであって、前記コンピューティングデバイスは、
プロセッサと、
通信サブシステムと
を備え、
前記コンピューティングデバイスは、
第１のアプリケーションから、前記許可サービスにおけるリクエストを受信することであって、前記リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための前記第２のアプリケーションに対する許可とを含む、ことと、
前記受信されたリクエストに基づいて、前記許可サービスにおいてアクションを実行することと、
前記第１のアプリケーションに、前記第２のアプリケーションが前記リソースにアクセスするための前記許可を有しているかどうかを示す前記アクションの結果を返すことと
を行うように構成されている、コンピューティングデバイス。
（項目１１）
前記アクションは、前記識別子が前記許可サービスにおける前記許可と関連付けられているかどうかを決定するためのチェックである、上記項目のいずれか１項に記載のコンピューティングデバイス。
（項目１２）
前記アクションは、前記識別子に前記許可を付与することであり、前記リクエストは、前記第１のアプリケーションの識別子をさらに含み、前記コンピューティングデバイスは、
前記第１のアプリケーションの前記識別子に基づいて、前記第１のアプリケーションが前記第２のアプリケーションに許可を付与するための許可を有していることを決定すること
を行うようにさらに構成されている、上記項目のいずれか１項に記載のコンピューティングデバイス。
（項目１３）
前記識別子は、前記オペレーティングシステムに対するユーザ識別子である、上記項目のいずれか１項に記載のコンピューティングデバイス。
（項目１４）
前記許可は、ドメイン、アクション、およびサブジェクトから成る許可ネームを含む、上記項目のいずれか１項に記載のコンピューティングデバイス。
（項目１５）
前記ドメインは、コンピューティングシステム内で一意的なプレフィックスを含む、上記項目のいずれか１項に記載のコンピューティングデバイス。
（項目１６）
前記許可ネームは、前記ドメイン内で一意的である、上記項目のいずれか１項に記載のコンピューティングデバイス。
（項目１７）
前記第１のアプリケーションは、前記許可サービスに対する前記リクエストを使用して前記許可を執行するサービスである、上記項目のいずれか１項に記載のコンピューティングデバイス。
（項目１８）
前記許可サービスは、識別子と許可との間の関連付けを用いて、ランタイムにおいて静的に構成され、かつ、ランタイムの後に動的に構成される、上記項目のいずれか１項に記載のコンピューティングデバイス。
（項目１９）
命令コードを格納するためのコンピュータ読み取り可能な媒体であって、前記命令コードは、許可を管理するための許可サービスとして構成されたコンピューティングデバイスのプロセッサによって実行されると、前記コンピューティングデバイスに、
第１のアプリケーションから、前記許可サービスにおけるリクエストを受信することであって、前記リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための前記第２のアプリケーションに対する許可とを含む、ことと、
前記受信されたリクエストに基づいて、前記許可サービスにおいてアクションを実行することと、
前記第１のアプリケーションに、前記第２のアプリケーションが前記リソースにアクセスするための前記許可を有しているかどうかを示す前記アクションの結果を返すことと
を行わせる、コンピュータ読み取り可能な媒体。
（摘要）
許可を管理するためのコンピューティングデバイス上の許可サービスにおける方法であって、前記方法は、第１のアプリケーションから、前記許可サービスにおけるリクエストを受信することであって、前記リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための前記第２のアプリケーションに対する許可とを含む、ことと、前記受信されたリクエストに基づいて、前記許可サービスにおいてアクションを実行することと、前記第１のアプリケーションに、前記第２のアプリケーションが前記リソースにアクセスするための前記許可を有しているかどうかを示す前記アクションの結果を返すこととを含む、方法。
【図面の簡単な説明】
【0008】
本開示は、図面を参照することによってより良く理解され得る。
【0009】
【0010】
【0011】
【0012】
【0013】
【0014】
【0015】
【0016】
【0017】
【0018】
【0019】
【発明を実施するための形態】
【0020】
（図面の詳細な説明）
本開示は、許可を管理するためのコンピューティングデバイス上の許可サービスにおける方法を提供し、方法は、第１のアプリケーションから、許可サービスにおけるリクエストを受信することであって、リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための第２のアプリケーションに対する許可とを含む、ことと、受信されたリクエストに基づいて、許可サービスにおいてアクションを実行することと、第１のアプリケーションに、第２のアプリケーションがリソースにアクセスするための許可を有しているかどうかを示すアクションの結果を返すこととを含む。
本開示は、許可を管理するためのコンピューティングデバイス上の許可サービスにおける方法を提供し、方法は、第１のアプリケーションから、許可サービスにおけるリクエストを受信することであって、リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための第２のアプリケーションに対する許可とを含む、ことと、受信されたリクエストに基づいて、許可サービスにおいてアクションを実行することと、第１のアプリケーションに、第２のアプリケーションがリソースにアクセスするための許可を有しているかどうかを示すアクションの結果を返すこととを含む。
【0021】
本開示は、許可を管理するための許可サービスとして構成されたコンピューティングデバイスをさらに提供し、コンピューティングデバイスは、プロセッサと、通信サブシステムとを備え、コンピューティングデバイスは、第１のアプリケーションから、許可サービスにおけるリクエストを受信することであって、リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための第２のアプリケーションに対する許可とを含む、ことと、受信されたリクエストに基づいて、許可サービスにおいてアクションを実行することと、第１のアプリケーションに、第２のアプリケーションがリソースにアクセスするための許可を有しているかどうかを示すアクションの結果を返すこととを行うように構成されている。
【0022】
本開示は、命令コードを格納するためのコンピュータ読み取り可能な媒体をさらに提供し、命令コードは、許可を管理するための許可サービスとして構成されたコンピューティングデバイスのプロセッサによって実行されると、コンピューティングデバイスに、第１のアプリケーションから、許可サービスにおけるリクエストを受信することであって、リクエストは、第２のアプリケーションに対するオペレーティングシステムと関連付けられた識別子と、リソースにアクセスするための第２のアプリケーションに対する許可とを含む、ことと、受信されたリクエストに基づいて、許可サービスにおいてアクションを実行することと、第１のアプリケーションに、第２のアプリケーションがリソースにアクセスするための許可を有しているかどうかを示すアクションの結果を返すこととを行わせる。
【0023】
本開示は、ソフトウェア特有のＯＳアグノスティックな許可マネージャに対するリソースグループメンバーシップの管理の委任に関する。特に、システム内の各インストールされたソフトウェアアプリケーションは、それによって提供されるサービスにアクセスすることが必要とされるカスタム許可のセットを宣言し得る。これらの許可は、その後、ＵＩＤによって特定のユーザに付与され、これらの許可が付与されたユーザとして実行されるプロセスのみが、サービスにアクセスし得る。
【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】
各許可ドメインは、構造化されたネームを有し得る。例えば、許可ドメインネームは、以下の表１において提供される文法を用いて、５１２までの小文字の長さであり得る。
【表1】
【0088】
表１に見られるように、許可ドメインは、ドメインまたはドット表示を伴うドメインから成り得る。各ドメインは、小文字または別のドメインに添加された小文字から成る。
【0089】
一実施形態において、許可ドメインは、構成を通して静的に宣言される。許可ドメインは、いくつかの場合、ネスト化または階層化されない。
【0090】
許可ネーム
【0091】
各カスタム許可は、ネームを与えられる。したがって、許可ネームは、文字列としての各カスタム許可の表現である。許可ネームに対する文法の非限定的な例は、以下の表２において提供される。
【表2】
【0092】
表２に見られるように、許可は、ネーム内の＜ｖｅｒｂ＞を使用してアクションを示し得る。さらに、アクションの主語も、許可ネームの一部であり得、主語に対する形容詞を含み得る。表２の実施形態において、そのような動詞および主語は、大文字であり得る。
【0093】
例えば、許可ネームは、“ｖｅｈｉｃｌｅ”ドメインのためにリザーブされ、車両における信号サービスに対するアクセスを可能にする。この場合、許可ネームは、“ｖｅｈｉｃｌｅ．ＡＣＣＥＳＳ＿ＳＩＧＮＡＬ＿ＳＥＲＶＩＣＥ”であり得る。この場合、“ｖｅｈｉｃｌｅ”は、“ｖｅｈｉｃｌｅ”ドメインのためにリザーブされたプレフィックスであり、許可は、動詞“ＡＣＣＥＳＳ”を含み、主語“ＳＩＧＮＡＬ ＳＥＲＶＩＣＥ”をさらに含み、したがって、許可が何に対して使用されているかの明確なインジケーションを提供する。より一般的には、任意のプレフィックスも使用され得る。例えば、“ｉｇｎｉｔｉｏｎ．ＳＴＡＲＴ＿ＥＮＧＩＮＥ”は、“ｖｅｈｉｃｌｅ”リザーブドプレフィックスではなく、“ｉｇｎｉｔｉｏｎ”リザーブドプレフィックスを使用し得、“ｉｇｎｉｔｉｏｎ”は、“ｖｅｈｉｃｌｅ”ドメインに対して定義された別のリザーブドプレフィックスである。換言すると、許可ネームは、許可がどのようなリソースを保護しており、それがどのアクションを保護しているかを明確化する記述的ネームを持ち得る。
【0094】
いくつかの実施形態において、許可ネームは、許可ドメインにわたって一意的であり得る。このようにして、許可チェックは、許可チェックに先立ってドメインチェックを必要としない。
【0095】
当業者によって理解され得るように、許可ネームの構文および文法は、単なる例として提供されているに過ぎず、非限定的である。許可ネームに対するその他の文法形式も可能である。
【0096】
許可プレフィックス
【0097】
いくつかの実施形態において、プレフィックスのセットは、ドメイン内のサービスに対してリザーブされ得る。新規許可を作成するための許可を有するその他のドメイン内のサービスは、別のドメインによってリザーブされたプレフィックスに合致するプレフィックスを有する許可を作成することが可能ではない。プレフィックスをリザーブしているドメインは、リザーブされたプレフィックスを使用する許可を作成することに限定されない。
【0098】
例えば、“ｖｅｈｉｃｌｅ”ドメイン内でプレフィックス“ｉｇｎｉｔｉｏｎ”をリザーブすることは、そのネームが“ｉｇｎｉｔｉｏｎ”で開始する許可が、“ｖｅｈｉｃｌｅ”ドメイン内でのみ宣言され得ることを意味し得る。しかしながら、ドメイン内の許可は、リザーブされたプレフィックスを持つ必要はない。
【0099】
静的および動的な許可構成
【0100】
上記の表１および表２の文法を使用することにより、許可ドメインおよび許可ネームは、それらが、クライアントアプリケーションとは対照的に、システムアプリケーションに対してリザーブされ得るように、予め定義され得る。これは、ネーム空間の占拠を防止するために許可ネームのプレフィックスをリザーブすることによって達成され、したがって、或る許可ネームプレフィックスが或る許可ドメインのためにリザーブされることを保証する。
【0101】
各許可ドメインに対し、ドメインネームは、リザーブされた許可ネームプレフィックスとして暗示的または明示的に定義され得る。例えば、許可ドメイン“ｖｅｈｉｃｌｅ”を作成することは、ドメインに対する“ｖｅｈｉｃｌｅ”許可ネームプレフィックスを暗示的にリザーブし、“ｖｅｈｉｃｌｅ”で開始する許可が、“ｖｅｈｉｃｌｅ”ドメインにのみ宣言または追加され得ることを確実にする。ドメインネームはまた、以下の表３に示されるようなリザーブド許可ネームプレフィックスとして明示的に定義され得る。より一般的には、任意のプレフィックスが使用され得る。例えば、“ｉｇｎｉｔｉｏｎ．ＳＴＡＲＴ＿ＥＮＧＩＮＥ”は、ドメインネームプレフィックスではなく、プレフィックス“ｉｇｎｉｔｉｏｎ”を使用し得る。
【0102】
２つのタイプの許可構成が存在する。第１のものは、許可の定義であり、第２のものは、許可の付与を包含する。許可構成は静的であり、ランタイム時に改変されることはできない。システムは、静的な許可構成が変更される必要がある場合、再起動される必要があり得る。
【0103】
当業者によって理解され得るように、これは、許可がランタイム時に取り消しまたは付与されることができないことを意味しない。これは、許可ドメイン、許可プレフィックス、および許可が、ランタイム時に予め定義されることができないことを意味する。加えて、これは、構成を介して行われた任意の付与が、ランタイム時に取り消されることができないことを暗示する。
【0104】
これに関し、許可構成は、許可ドメインの定義および許可付与の両方から成り得る。許可ドメインの定義は、ドメインに対する一意的なネーム、ドメインが表すものの記述、リザーブド許可プレフィックスのリスト、および許可のリストを含み得る。
【0105】
例えば、許可構成の例が、表３に関して示される。
【表3-1】
【表3-2】
【表3-3】
【0106】
表３の例において、“ｖｅｈｉｃｌｅ”ドメインが定義される。このドメインの下で、“ｖｅｈｉｃｌｅ”、“ｉｇｎｉｔｉｏｎ”、および“ｌｉｇｈｔｓ”プレフィックスがリザーブされる。さらに、“ｓｙｎｔｈｅｔｉｃ．ｓｅｎｓｏｒｓ”ドメインが定義され、“ｓｙｎｓｅｎ”プレフィックスをリザーブしている。
【0107】
４つの許可付与が静的に定義される。具体的には、“ｖｅｈｉｃｌｅ．ＡＣＣＥＳＳ＿ＳＩＧＮＡＬ＿ＳＥＲＶＩＣＥ”許可は、ＵＩＤ１０００が信号サービスにアクセスすることを可能にする。“ｖｅｈｉｃｌｅ．ＡＣＣＥＳＳ＿ＣＡＢＩＮ＿ＳＩＧＮＡＬＳ”許可は、ＵＩＤ１０００がキャビン信号にアクセスすることを可能にする。
【0108】
“ｖｅｈｉｃｌｅ．ＧＲＡＮＴ＿ＰＥＲＭＩＳＳＩＯＮＳ”許可は、ＵＩＤ０および１０００に付与され、これは、これらのＵＩＤを有するプロセスが、“ｖｅｈｉｃｌｅ”、“ｉｇｎｉｔｉｏｎ”、または“ｌｉｇｈｔｓ”プレフィックスを有する許可を任意のＵＩＤに対して動的に付与し得ることを意味する。
【0109】
“ｓｙｎｔｈｅｔｉｃ．ｓｅｎｓｏｒｓ．ＧＲＡＮＴ＿ＰＥＲＭＩＳＳＩＯＮＳ”許可は、ＵＩＤ２０００に付与され、これは、このＵＩＤを有するプロセスが、“ｓｙｎｓｅｎ”プレフィックスを有する許可を任意のＵＩＤに動的に付与し得ることを意味する。
【0110】
このように、“ｖｅｈｉｃｌｅ．ＧＲＡＮＴ＿ＰＥＲＭＩＳＳＩＯＮＳ”が暗示的に定義されるが、２つの追加的な許可、すなわち“ｖｅｈｉｃｌｅ．ＡＣＣＥＳＳ＿ＳＩＧＮＡＬ＿ＳＥＲＶＩＣＥ”および“ｖｅｈｉｃｌｅ．ＡＣＣＥＳＳ＿ＣＡＢＩＮ＿ＳＩＧＮＡＬＳ”が明示的に定義される。信号サービスのクライアントは、“ｐｅｒｍｉｓｓｉｏｎ－ｇｒａｎｔｓ”構成を通して（例えば、“ｖｅｈｉｃｌｅ．ＧＲＡＮＴ＿ＰＥＲＭＩＳＳＩＯＮＳ”を通して）“ｖｅｈｉｃｌｅ．ＡＣＣＥＳＳ＿ＳＩＧＮＡＬ＿ＳＥＲＶＩＣＥ”を付与され得、この場合、ＵＩＤ１０００を有するユーザは、この許可を付与される。
【0111】
したがって、表３の構成は、例えばランタイム時にファイル、表、またはデータベースからロードされ得る静的構成である。しかしながら、全ての許可が予め定義される必要があるわけではない、または、予め定義され得るわけではない。いくつかの許可は、システム上にどのようなアプリケーションが配備されるかに依存して、ランタイム時にのみ動的に作成され得る。これをサポートするために、“ＧＲＡＮＴ＿ＰＥＲＭＩＳＳＩＯＮＳ”（例えば、“ｖｅｈｉｃｌｅ．ＧＲＡＮＴ＿ＰＥＲＭＩＳＳＩＯＮＳ”または“ｓｙｎｔｈｅｔｉｃ．ｓｅｎｓｏｒｓ．ＧＲＡＮＴ＿ＰＥＲＭＩＳＳＩＯＮＳ等）と呼ばれる特別な許可が、各ドメインに対して暗示的に定義される。この許可は、クライアントがその後にドメイン内でそれら独自の許可を動的に作成および付与し得るように、ランタイム時にクライアントに付与され得る。
【0112】
例えば、ここで図５に対する参照がなされる。図５の実施形態において、合成センサ５１０は、システムに導入されている新規合成センサであり得る。このように、合成センサ５１０は、ファクターの中でもとりわけ、例えばインストール、統合のために、信号サービス５１２と通信し得る。さらに、許可サービス５１４は、システム内の許可を管理するように構成され得る。許可サービス５１４は、例えば、図２の実施形態からの許可サービス２７２であり得るか、または、図３の実施形態からの許可サービス３２０であり得るか、または、図４の実施形態からの許可サービス４３０であり得る。
【0113】
図２、３、および４に関して提供されるように、許可サービス５１４は、システムに対する許可を管理するＯＳアグノスティックなアプリケーションである。インストールすると、許可サービス５１４は、その構成（例えば、表３）から静的な許可を収集する。これはその後、各ドメインに対する暗示的なプレフィックスを設定する。
【0114】
許可サービス５１４は、登録されたクライアントに許可変更について通知し、これは、動的な許可の追加および取り消しをサポートするために重要である。したがって、許可サービス５１４のクライアントは、許可変更アップデート通知にサブスクライブするために、そのＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍ ｉｎｔｅｒｆａｃｅ）を使用し得る。
【0115】
そのＡＰＩを通して、許可サービス５１４は、ＵＩＤに許可を付与するように命令され得る。このＡＰＩへのコール元は、以下に記載されるように、許可のドメインに対して“ＧＲＡＮＴ＿ＰＥＲＭＩＳＳＩＯＮＳ”許可を有していなければならない。
【0116】
同様に、許可サービス５１４は、ＵＩＤから許可を取り消すように命令され得る。このＡＰＩへのコール元は、許可のドメインに対して“ＧＲＡＮＴ＿ＰＥＲＭＩＳＳＩＯＮＳ”許可を有していなければならない。
【0117】
ＡＰＩの別の部分は、クライアントがドメイン内に許可を追加することを可能にし得る。このＡＰＩへのコール元は、許可のドメインに対して“ＧＲＡＮＴ＿ＰＥＲＭＩＳＳＩＯＮＳ”許可を有していなければならない。
【0118】
同様に、許可サービス５１４は、ＵＩＤが許可を付与されているかどうかをチェックするためにコールされ得るＡＰＩを提供する。コール元は、このＡＰＩを呼び出すために任意の特別な許可を必要としない。これは、以下の図６に関して示されている。
【0119】
さらに、クライアントは、ＵＩＤに付与された許可のリストを取得するために、許可サービスＡＰＩを使用し得る。クライアントは、このＡＰＩを呼び出すために任意の特別な許可を必要としない。
【0120】
したがって、図５の実施形態において、合成センサ５１０は、１０４５のＵＩＤを有する。さらに、信号サービス５１２は、１０００のＵＩＤを有する。これに関し、上記の表３から、信号サービス５１２は、許可を付与する権限が与えられている（すなわち、“ｖｅｈｉｃｌｅ．ＧＲＡＮＴ＿ＰＥＲＭＩＳＳＩＯＮＳ”がＵＩＤ１０００の信号サービス５１２に付与される）。
【0121】
合成センサ５１０がインストールされると（または、任意の後続の時間において）、それはアクセスをリクエストし得、メッセージ５２０として示されるそのＵＩＤを提供し得る。メッセージ５２０は、明示的なメッセージまたは暗示的なメッセージであり得る。具体的には、合成センサ５１０のインストールのみで、信号サービス５１２が許可を付与しようと試みることを引き起こし得る。その他の場合、合成センサ５１０は、合成センサに依存して、様々なサービスに対するアクセスを明示的にリクエストし得る。
【0122】
一実施形態では、メッセージ５２０におけるリクエストは、具体的リソースに対するアクセスをリクエストし得る。例えば、合成センサ５１０は、様々なサービス（例えば、信号サービスまたはキャビンサービス等）に由来する具体的なセンサからのデータを使用し得、したがって、メッセージ５２０におけるリクエストは、これらのサービスに対するアクセスをリクエストし得る。
【0123】
メッセージ５２０を受信すると、信号サービス５１２は、メッセージ５３０で示されているように、許可サービス５１４に許可付与リクエストを送信し得る。メッセージ５３０は、例えば、付与が求められている特定の許可だけではなく、合成センサ５１０のＵＩＤを含み得る。さらに、メッセージ５３０は、典型的には、信号サービス５１２のＵＩＤを含み得る。合成センサ５１０のＵＩＤおよび信号サービス５１２のＵＩＤは、オペレーティングシステムによって割り当てられ得る。
【0124】
許可サービス５１４は、信号サービス５１２が許可を付与する権限を有していることをチェックし得、それに該当する場合、許可サービス５１４において許可が付与され得、記録され得る。いくつかの場合、許可サービス５１４は、信号サービス５１２のＵＩＤに基づいて、信号サービス５１２が許可を付与する権限を有しているかどうかをチェックし得る。さらに、許可サービス５１４は、応答５３２を送信し得、そこでは、ＵＩＤ１０４５が現在、許可“ｖｅｈｉｃｌｅ．ＡＣＣＥＳＳ＿ＳＩＧＮＡＬ＿ＳＥＲＶＩＣＥ”に対するアクセスを付与されたことのインジケーションが提供される。
【0125】
さらに、いくつかの場合、許可サービス５１４のサブスクライバに対するメッセージは、許可の付与を示すメッセージを送信し得る。
【0126】
いくつかの場合、信号サービス５１２は、ブロック５３６において示されているように、応答をキャッシュし得る。
【0127】
いくつかの場合、さらなる許可のためのさらなるメッセージが、合成センサ５１０から受信され得る。その他の場合、メッセージ５２０は、複数の許可に対するリクエストを含み得る。図５の例において、メッセージ５２０は、信号サービスおよびキャビン信号の両方に対するアクセスをリクエストしていることがあり得る。これに関し、信号サービス５１２は、許可サービス５１４に付与許可メッセージ５４０を送信し得る。メッセージ５４０は、許可付与が求められている許可だけではなく、合成センサ５１０のＵＩＤを含み得る。
【0128】
ここでも、許可サービス５１４は、信号サービス５１２が許可を付与する能力を有していることをチェックし、「はい」の場合、許可サービス５１４は、ＵＩＤ１０４５がキャビン信号に対するアクセスのための許可を有していることに留意し得る。許可サービス５１４は、その後、アクセスが付与された（すなわち、許可“ｖｅｈｉｃｌｅ．ＡＣＣＥＳＳ＿ＣＡＢＩＮ＿ＳＩＧＮＡＬＳ”が合成センサ５１０に付与される）ことを示す応答５４２を信号サービス５１２に返送し得る。
【0129】
さらに、いくつかの場合、許可サービス５１４のサブスクライバに対するメッセージは、許可の付与を示すメッセージが送信され得る。
【0130】
信号サービス５１２は、いくつかの場合、ブロック５４６で示されているように、将来におけるより高速な処理のために応答をキャッシュし得る。
【0131】
図５の例において、メッセージ５２０に対する応答は、応答５５０として送信され得、そこでは、サービス５１２は、合成センサ５１０に、求められている許可に対するアクセスが付与されたとことを通知する。
【0132】
当業者によって理解され得るように、信号サービス５１２が許可を付与する能力を有していない場合、許可サービス５１４は、メッセージ５３０および５４０を拒絶し、この場合、合成センサ５１０に対して許可は付与されないことがあり得る。
【0133】
可能にされるアクセスおよび否認されるアクセスの例
【0134】
さらなる実施形態において、アプリケーションは、特定のサービスに対するアクセスをリクエストし得る。ここで、図６に対する参照がなされる。
【0135】
図６の実施形態において、アプリケーション６１０は、車両内のドライバ位置を決定するために、信号サービス６１２に対するアクセスを求める。例えば、アプリケーション６１０は、運転席の窓が上であるかまたは下であるかを決定しようと試みていることがあり得、したがって、車両が左ハンドル車両であるかまたは右ハンドル車両であるかを知ることを必要とし得る。
【0136】
信号サービス６１２は、許可サービス６１４と通信し得る。許可サービス６１４は、例えば、図２の実施形態からの許可サービス２７２、図３からの許可サービス３２０、または図４の実施形態からの許可サービス４３０であり得る。
【0137】
アプリケーション６１０は、リクエストアクセスメッセージ６２０を信号サービス６１２に送信する。リクエストアクセスメッセージは、いくつかの実施形態では、アプリケーション６１０のＵＩＤ１０００を含み得る。しかしながら、その他の実施形態において、ＵＩＤは、ＯＳによって管理され、メッセージ６２０の一部である。この場合、ＵＩＤは、信号サービス６１２によって読み取られ得、これにより、メッセージ６２０を送信している当事者の身元に関するＯＳレベルのセキュリティを提供する。
【0138】
信号サービス６１２は、その後、許可サービス６１４にチェックメッセージ６３０を送信し得る。チェックメッセージは、アプリケーション６１０のＵＩＤ１０００ならびにアプリケーションが求めている許可を含み得る。この場合、許可は“ｖｅｈｉｃｌｅ． ＡＣＣＥＳＳ＿ＳＩＧＮＡＬ＿ＳＥＲＶＩＣＥ”である。メッセージ６３０はまた、信号サービス６１２のＵＩＤを含み得る。
【0139】
許可サービス６１４は、それの記録（例えば、図３の実施形態からの許可キャッシュ３４０または許可ストア３８０等）をチェックし得、ＵＩＤ１０００がアクセスを可能にされていることを決定し得る。これは、例えば、表３における構成（ＵＩＤ １０００は、表３によって構成された許可“ｖｅｈｉｃｌｅ．ＡＣＣＥＳＳ＿ＳＩＧＮＡＬ＿ＳＥＲＶＩＣＥ”を与えられる）または図５の許可付与を利用することにより、サービス開始時に静的に構成され得るか、または、サービス開始後に動的に構成され得る。
【0140】
したがって、許可サービス６１４は、ＵＩＤがアクセスを可能にされていることを示す信号サービス６１２に応答メッセージ６３２を返送する。上記で示されているように、許可サービス６１４は、許可を執行しない。むしろ、これは、信号サービス６１２の責任である。したがって、信号サービス６１２は、信号サービス６１２によって管理されるリソースに対するアクセスを求めるものが、許可サービス６１４にクエリすることによって正しい許可を有しているかどうかをチェックする責任を有する。
【0141】
メッセージ６３２を受信すると、信号サービス６１２は、いくつかの場合において、ブロック６３６に示されているように、応答をキャッシュし得る。これは、将来におけるアクセスリクエストに対するより高速な許可決定を可能にする。しかしながら、ブロック６３６におけるキャッシュはオプションである。別の場合、メッセージ６３０および６３２は、将来において繰り返され得る。
【0142】
メッセージ６３２に応答して、信号サービス６１２は、アクセスが可能にされていることを示す応答メッセージ６４０をアプリケーション６１０に返送し得る。
【0143】
アプリケーション６１０は、その後、リクエストメッセージ６５０において、ドライバ位置を見出すことを求め得る。ここでもまた、ＵＩＤは、いくつかの場合、メッセージ６５０の一部であるＯＳベースのＵＩＤであり得る。
【0144】
信号サービス６１２は、メッセージ６５０を受信し、ブロック６５２に示されているように、任意のキャッシュされた許可がセーブされているかどうかを決定するために、ローカルチェックを実行し得る。ブロック６５２におけるチェックに対して代替的に、または追加的に、信号サービス６１２は、チェックメッセージ６５４を許可サービス６１４に送信し得る。この場合、チェックメッセージは、チェックされている許可だけではなく、アプリケーション６１０のＵＩＤを含み、オプションとして、信号サービス６１２のＵＩＤを含み得る。この場合、許可は“ｖｅｈｉｃｌｅ ＡＣＣＥＳＳ＿ＣＡＢＩＮ＿ＳＩＧＮＡＬＳ”である。
【0145】
許可サービス６１４は、ＵＩＤが許可に対するアクセスを付与されていることをチェックし（例えば、ＵＩＤ１０００は、表３によって構成された許可“ｖｅｈｉｃｌｅ．ＡＣＣＥＳＳ＿ ＣＡＢＩＮ＿ＳＩＧＮＡＬＳ”を付与されている）、「はい」の場合、応答メッセージ６５６を信号サービス６１２に返送し得る。いくつかの場合、信号サービス６１２は、応答をキャッシュし得る（図示されていない）。さらに、ブロック６５２におけるチェックまたはブロック６５６における応答に基づいて、信号サービス６１２は、ドライバ位置を示す応答メッセージ６６０をアプリケーション６１０に返送し得る。ここでもまた、信号サービス６１２は、応答６６０を提供する前に、許可サービス６１４を利用することにより、サービスのセキュリティに対して責任を持っている
【0146】
その他の場合、信号サービスは、そのようなアクセスをリクエストするＵＩＤが特定の許可を有していない場合、リソースに対するアクセスを否定し得る。ここで、図７に対する参照がなされる。
【0147】
図７の実施形態において、アプリケーション７１０は、信号サービス７１２からの情報を求める。さらに、許可サービス７１４は、許可に関してクエリされ得る。ここでもまた、許可サービス７１４は、図２の実施形態からの許可サービス２７２、図３の実施形態からの許可サービス３２０、および／または図４の実施形態からの許可サービス４３０と同じであり得る。
【0148】
この場合、アプリケーション７１０は、５０００のＵＩＤを有する。したがって、アプリケーション７１０は、メッセージ７２０で示されているように、このＵＩＤを利用することによってアクセスをリクエストする。ＵＩＤは、メッセージ７２０のＯＳレベルＵＩＤ部分であり得る。
【0149】
メッセージ７２０を受信すると、信号サービス７１２は、チェックメッセージ７３０を許可サービス７１４に送信し得る。チェックメッセージ７３０は、チェックされる許可とともに、リクエストアプリケーション７１０のＵＩＤ、信号サービス７１２のＵＩＤを含み得る。この場合、許可は、“ｖｅｈｉｃｌｅ．ＡＣＣＥＳＳ＿ＳＩＧＮＡＬ＿ＳＥＲＶＩＣＥ”である。
【0150】
許可サービス７１４は、ＵＩＤが関連付けられた許可を有しているかどうかを決定するためにチェックする。この場合、上記の表３の構成が使用された場合（ＵＩＤ５０００は、表３の許可“ｖｅｈｉｃｌｅ．ＡＣＣＥＳＳ＿ＳＩＧＮＡＬ＿ＳＥＲＶＩＣＥ”を付与されていない）、またはＵＩＤ５０００を有するアプリケーションに動的な許可が付与されていない場合、許可サービス７１４は、アプリケーション７１０が適切な許可を有していないことを発見する。この場合、許可サービス７１４は、ＵＩＤ５０００が否認されたアクセスであることを示す応答メッセージ７３２を送信し得る。
【0151】
いくつかの場合、信号サービス７１２は、ブロック７３６において示されているように、メッセージ７３２を受信し得、応答をキャッシュし得る。しかしながら、キャッシュはオプションである。
【0152】
信号サービス７１２は、その後、アクセスが否認されたことを示すメッセージ７４０をアプリケーション７１０に返送することによって、許可を執行し得る。
【0153】
図７の例において、アプリケーション７１０は、持続的であり得、メッセージ７５０においてドライバ位置をリクエストし得る。この場合、信号サービス７１２は、ブロック７５２において、それのキャッシュのローカルチェックを実行し、許可が付与されてているかどうかを決定し得る。しかしながら、このローカルチェックはオプションである。いくつかの場合、信号サービス７１２は、その代わりに、または追加として、チェックメッセージ７５４を許可サービス７１４に送信し得る。チェックメッセージ７５４は、チェックされる許可だけではなく、アプリケーション７１０のＵＩＤ、信号サービス７１２のＵＩＤを含み得る。図７の例において、この許可は、“ｖｅｈｉｃｌｅ．ＡＣＣＥＳＳ＿ＣＡＢＩＮ＿ＳＩＧＮＡＬＳ”である。
【0154】
許可サービス７１４は、ＵＩＤがチェックメッセージ７５４において見出された許可を付与されているかどうかをチェックし得、そのような許可が付与されていないことを決定し得る。例えば、許可“ｖｅｈｉｃｌｅ．ＡＣＣＥＳＳ＿ＣＡＢＩＮ＿ＳＩＧＮＡＬＳ”は、ＵＩＤ５０００に、（表３によって）静的に付与されておらず、または、動的に付与されていない。したがって、許可サービス７１４は、ＵＩＤ５０００が否認されたアクセスであることを示す応答メッセージ７５６を送信し得る。
【0155】
いくつかの場合、信号サービス７１２は、メッセージ７５６を受信し得、応答をキャッシュし得る。信号サービス７１２は、さらに、アクセスが否認されたことを示す応答メッセージ７６０をアプリケーション７１０に返送し得る。
【0156】
ここでもまた、このようにして、信号サービス７１２は、クエリを許可サービス７１４に送信することにより、信号サービス７１２のリソースに対するアクセスを制御する。
【0157】
インストール
【0158】
別の合成センサからのインサイトに関心のある合成センサは、その合成センサからのインサイトをアップデートするためにサブスクライブするための許可を付与される必要があり得る。これは、合成センサが、車両内のシステム上に配備されたときに、それ独自の許可を定義することが可能である必要があり得ることを意味する。これはまた、この合成センサが、そのインサイトを合成するために必要とする車両信号にアクセスするための許可を有している必要があり得ることを意味する。これらの信号に対するそのようなアクセスは、例えば、図７の実施形態のように、信号サービスによって制御される。
【0159】
車両上で稼働中のシステムの中に合成センサを配備すると、合成センサは、それ独自の許可を定義するための許可を付与される。これは、インストーラサービスが、合成センサ許可ドメイン内で許可に対するプレフィックスとして合成センサのネーム（これは、いくつかの実施形態においては、一意的でなければならない）を使用することによって、そのような許可を定義することによって行われ得る。
【0160】
一実施例が、図８に関して示されている。図８の例において、“ｃｈｉｌｄ．ｄａｎｇｅｒ．ｄｅｔｅｃｔｉｏｎ”合成センサがシステム上にインストールされている。この合成センサは、インストール時間においてＵＩＤ３０００を割り当てられている。
【0161】
より具体的には、インストーラサービス８１０は、許可サービス８１２と通信し得る。ここでもまた、許可サービス８１２は、図２の実施形態からの許可サービス２７２、図３の実施形態からの許可サービス３２０、および／または図４の実施形態からの許可サービス４３０と同じであり得る。インストーラサービス８１０は、ブロック８２０において示されているように、“ｃｈｉｌｄ．ｄａｎｇｅｒ．ｄｅｔｅｃｔｉｏｎ”と呼ばれる新規合成センサ８１４をインストールするためのリクエストを受信し得る。インストーラサービス８１０は、この合成センサに対してＵＩＤ３０００を割り当て得る。
【0162】
インストーラサービス８１０は、その後、メッセージ８２２を許可サービス８１２に送信し得る。メッセージ８２２は、ＵＩＤと、ドメインと、付与されることが求められている許可とを指定する付与であり得る。具体的には、図８の例において、メッセージ８２２は、「ｓｙｎｔｈｅｔｉｃ． ｓｅｎｓｏｒｓ．ＧＲＡＮＴ＿ＰＥＲＭＩＳＳＩＯＮＳ」をＵＩＤ３０００に付与するためのリクエストである。
【0163】
許可サービス８１２は、メッセージ８２２を受信し、インストーラがｓｙｎｔｈｅｔｉｃ．ｓｅｎｓｏｒｓドメイン内で許可を付与することを可能にされているかどうかを決定する。この場合、許可サービス８１２は、インストーラサービス８１０がｓｙｎｔｈｅｔｉｃ．ｓｅｎｓｏｒｓドメインに許可を付与する能力を有しているので、応答８２４をインストーラサービス８１０に返送する。応答メッセージ８２４は、合成センサをインストールするための許可が付与されていることを示す。
【0164】
応答８２４の受信に基づいて、インストーラサービス８１０は、点線矢印８３０で示されているように、合成センサ８１４をインストールし得る。
【0165】
新規にインストールされたｃｈｉｌｄ．ｄａｎｇｅｒ．ｄｅｔｅｃｔｉｏｎ合成センサ８１４は、ここでは、そのような許可が一意的である限り、合成センサドメインの下でそれが望む任意の許可を作成し得る。その他の許可との衝突が存在しないことを確実にするために、これは、いくつかの場合、それら自身のネームをプレフィックスとして用いてこれらの許可を定義し得る。
【0166】
例えば、図８の実施形態において、合成センサ８１４は、許可を追加することを求めるリクエストを許可サービス８１２に送信し得、許可およびドメインを示し得る。これは、図８の例において、ＡｄｄＰｅｒｍｉｓｓｉｏｎ（“ｃｈｉｌｄ．ｄａｎｇｅｒ．ｄｅｔｅｃｔｉｏｎ．ＡＣＣＥＳＳ＿ＩＮＳＩＧＨＴ”；ｓｙｎｔｈｅｔｉｃ．ｓｅｎｓｏｒｓ）を指定するメッセージ８４０で示されている。この例において、許可は、プロキシ“ｃｈｉｌｄ．ｄａｎｇｅｒ．ｄｅｔｅｃｔｉｏｎ”で提供され、ドメインは“ｓｙｎｔｈｅｔｉｃ．ｓｅｎｓｏｒｓ”として指定される。いくつかの場合、メッセージ８４０は、リクエストを行ったＵＩＤ３０００を含み得る。
【0167】
メッセージ８４０を受信することに応答して、許可サービス８１２は、ｃｈｉｌｄ．ｄａｎｇｅｒ．ｄｅｔｅｃｔｉｏｎ合成センサがｓｙｎｔｈｅｔｉｃ．ｓｅｎｓｏｒｓ．ＧＲＡＮＴ＿ＰＥＲＭＩＳＳＩＯＮＳ許可を付与されているかどうかを尋ねるためにローカルチェックを実行する。図８の例において、許可が付与されているので、許可が定義されていることを示す応答メッセージ８４２は、合成センサ８１４に戻るように提供される。
【0168】
その後、ＵＩＤ３５００を有する別の構成センサ（合成センサ８１６が示されている）が、メッセージ８５０によって示されているように、合成センサ８１４によって生成された合成センサインサイトに対するアクセスをリクエストし得る。合成センサ８１６は、例えばメッセージ８２２および８２４に関して上記と同じプロセスを利用することによって作成されたばかりであり得、ここでは、それが必要とするデータを取得しようと試みている。その他の場合、合成センサ８１６は、アップデートされ得、ここでは、新規情報を必要とし得る。その他のオプションも可能である。
【0169】
メッセージ８５０を受信すると、合成センサ８１４は、リクエストメッセージ８５０を許可サービス８１２に送信し得る。当業者によって理解され得るように、リクエストメッセージ８５０は、オプションの中でもとりわけ、ＡＰＩコール、特定のアドレスまたはポートに対するメッセージであり得る。メッセージ８５０は、合成センサ８１４がｃｈｉｌｄ．ｄａｎｇｅｒ．ｄｅｔｅｃｔｉｏｎ．ＡＣＣＥＳＳ＿ＩＮＳＩＧＨＴ許可をＵＩＤ３５００に付与していることのインジケーションを含み得る。メッセージ８５０は、付与された許可だけではなく、合成センサ８１４および８１６のＵＩＤを含み得る。
【0170】
メッセージ８５０を受信すると、許可サービス８１２は、ｃｈｉｌｄ．ｄａｎｇｅｒ．ｄｅｔｅｃｔｉｏｎ合成センサがｓｙｎｔｈｅｔｉｃ．ｓｅｎｓｏｒｓドメインに対する許可を付与する能力を有しているかどうかを決定するためのチェックを実行する。図８の例において、この決定は、ｃｈｉｌｄ．ｄａｎｇｅｒ．ｄｅｔｅｃｔｉｏｎ合成センサ８１４がこの許可を有することを見出し、したがって、許可サービス８１２は、合成センサ８１４がリクエストが付与されたことを伝えられる応答メッセージ８５２を生成する。付与は、合成センサ８１６に戻るように通信され得る（図示されていない）。
【0171】
したがって、図８の例は、合成センサのインストール、合成センサによる動的な許可のプロビジョニング、およびその他の合成センサに対する動的な許可の付与を示している。その後、合成センサ８１６は、例えば図６に関して記載されているようなプロセスを使用して、合成センサ８１４からインサイトをリクエストし得る。
【0172】
ＧＩＤベースの許可
【0173】
本開示の様々な実施形態は、オペレーティングシステムのグループＩＤ（ＧＩＤ）管理に依拠する必要なしに、許可の定義および管理をサポートするが、ＧＩＤを使用することが望ましい状況（例えば、ファイルシステム構成要素（ファイル、ソケット、デバイス等）に対するアクセスを制御するため等）が残っている。
【0174】
これらの状況において、例えば図２～４に記載されているように、許可管理のための単一の連絡窓口である許可サービスを有していることが有益であり得る。この理由により、いくつかの場合、許可サービスは、上記で定義されたような許可をサポートするだけではなく、ＧＩＤベースの許可もサポートし得る。これは、システムのリソースにアクセスするためのＯＳ許可の抽象化を可能にする。
【0175】
これは、ＯＳがファイルシステム内のリードオンリーパーティションにインストールされており、（例えば、Ｌｉｎｕｘ（登録商標）の／ｅｔｃ／ｇｒｏｕｐファイルが、リードオンリーパーティション内に存在するので、アップデートされ得ないとき）ＯＳ機能性を使用することによって新規ＧＩＤを作成することが可能ではない環境において有用である。
【0176】
上記で図５～８に関して議論されているように、許可サービスは、執行を実行しないが、単に誰が許可を付与されたかに関する情報を提供するに過ぎない。許可サービスの使用を行うサービスは、それら自身で執行を行う。いくつかの場合、基礎となるＯＳが、執行を行うために使用され得る。この場合、ＧＩＤは、単にＧＩＤを使用することにより、ＯＳ機能性を使用してＧＩＤを作成することなしに、許可と関連付けられ得る。
【0177】
許可と関連付けられたＧＩＤは、ＯＳ ＧＩＤサポート機能性を使用して既に定義されているＧＩＤであり得るか、または、定義されていないＧＩＤであり得る。
【0178】
ＧＩＤベースの許可は、それらが静的に定義され付与されるので、許可サービス構成を通して定義される。
【表4-1】
【表4-2】
【0179】
上記の表４において、“ｐｅｒｍｉｓｓｉｏｎｓ”の下で、未定義のＧＩＤ１２３４が、“ｅｘａｍｐｌｅ”ドメインの下の許可（“ｅｘａｍｐｌｅ．ＣＯＭＭＵＮＩＣＡＴＥ＿ＯＶＥＲ＿ＳＯＣＫＥＴ”）と関連付けられている。この例において、ＧＩＤ値１２３４は、ＯＳ内で定義されていない（例えば、Ｌｉｎｕｘ（登録商標）の／ｅｔｃ／ｇｒｏｕｐファイル内に存在しない）
【0180】
表４における“ｐｅｒｍｉｓｓｉｏｎ－ｇｒａｎｔｓ”エンティティを通して、“Ｅｘａｍｐｌｅ－Ａｐｐ”アプリケーション（ＵＩＤ ６５００が割り当てられている）は、その作成時に構成要素に割り当てられたファイルシステムアクセス許可のセット（読み取り、書き込み、実行等）に基づいて、許可“ｅｘａｍｐｌｅ．ＣＯＭＭＵＮＩＣＡＴＥ＿ＯＶＥＲ＿ＳＯＣＫＥＴ”を介して、ＧＩＤ１２３４が割り当てられた全ファイルシステム構成要素に対するアクセスを付与される。
【0181】
立ち上がると、許可サービスは、その構成を読み取り、“ｅｘａｍｐｌｅ．ＣＯＭＭＵＮＩＣＡＴＥ＿ＯＶＥＲ＿ＳＯＣＫＥＴ”許可と関連付ける１２３４のＧＩＤを作成する。
【0182】
具体的には、ここで図９に対する参照がなされ、これは、ＧＩＤおよびグループ許可を取得するためのプロセスを示している。特に、プロセスサービス９１２は、許可サービス９１４と通信する。
【0183】
許可サービス９１４がアクティベートされ、表４におけるその構成を読み取った後、プロセスサービス９１２は、ブロック９３０に示されているように、“Ｅｘａｍｐｌｅ－Ａｐｐ”アプリケーションを配備し、それに６５００ ＵＩＤを割り当てる。プロセスサービス９１２は、その後、メッセージ９４０で示されているように、どのようなＧＩＤベースの許可が“Ｅｘａｍｐｌｅ－Ａｐｐ”に付与されているかを許可サービスに尋ねる。
【0184】
許可サービス９１４は、その後、ブロック９５０に示されているように、もしあれば、どのようなＧＩＤベースの許可が、Ｅｘａｍｐｌｅ－Ａｐｐに付与されているかを決定するために、構成をチェックする。許可サービス９１４は、その後、メッセージ９６０として示されているように、ＧＩＤ１２３４を有する“ｅｘａｍｐｌｅ．ＣＯＭＭＵＮＩＣＡＴＥ＿ＯＶＥＲ＿ＳＯＣＫＥＴ”許可が、“Ｅｘａｍｐｌｅ－Ａｐｐ”アプリケーションに付与されていると応答する。
【0185】
プロセスサービス９１４は、その後、補足グループをＵＩＤに追加することをサポートするＯＳインターフェースを使用して、ＧＩＤ１２３４を６５００ ＵＩＤに追加し得る（図示されていない）。
【0186】
いったん許可が割り当てられると、例示的Ａｐｐは、或るアクションを実行し得る。例えば、図１０を参照すると、例示的Ａｐｐは、ソケットにアクセスし得る。
【0187】
特に、図１０は、例示的Ａｐｐ１０１０、例示的サービス１０１２、およびファイルシステム１０１４を示している。
【0188】
インストール時に、ＵＩＤ６５００が割り当てられた“Ｅｘａｍｐｌｅ－Ａｐｐ”アプリケーションは、ブロック１０２０に示されているように、構成に基づいて許可サービスによって自動的に１２３４のＧＩＤを有するファイルに対するアクセスを付与される。
【0189】
立ち上がると、例示的サービス１０１２は、例示的サービス１０１２に接続するようにアプリケーションによって使用され得る“ｅｘａｍｐｌｅ－ｓｏｃｋｅｔ”と呼ばれるソケットを作成する。これは、図１０の実施形態において、ファイルシステム１０１４からのソケット作成メッセージ１０３０と、成功応答メッセージ１０３２とを用いて示されている。
【0190】
例示的サービス１０１２は、その後、図１０においてｃｈｇｒｐ（）メッセージ１０４０で示されているように、ＧＩＤ１２３４をこのソケットに割り当てる。ファイルシステム１０１４は、割り当てを可能にすると、成功応答メッセージ１０４２を例示的サービス１０１２に返送する。
【0191】
例示的サービスは、さらに、図１０においてｃｈｍｏｄ（）メッセージ１０５０を使用して示されているように、このソケットに対するグループアクセス許可を設定する。ファイルシステム１０１４は、ソケットに対するグループアクセス許可を設定することに成功すると、成功応答メッセージ１０５２を例示的サービス１０１２に返送し得る。
【0192】
その後、“Ｅｘａｍｐｌｅ－Ａｐｐ”１０１０は、それがｃｈｍｏｄ（）を使用して付与されたアクセス許可を尊重する限り、例示的サービス１０１２によってファイルシステム１０１４内に作成されたソケットにアクセスし得る。例えば、図１０の実施形態において、例示的Ａｐｐ１０１０は、メッセージ１０６０に示されているように、例示的ソケットを用いて書き込むことを試み得る。ファイルシステム１０１４は、ブロック１０６２に示されているように、例示的Ａｐｐ１０１０が例示的ソケットファイルにアクセスすることを可能にされたＧＩＤ１２３４を有していることを検証し得る。いくつかの場合、ファイルシステム１０１４は、許可サービスによって、例示的Ａｐｐ１０１０がＧＩＤ１２３４と関連付けられていることを通知され得る。
【0193】
ブロック１０６２におけるチェックの結果に依存して、ファイルシステム１０１４は、成功応答メッセージ１０６４を例示的Ａｐｐ１０１０に返送し得る。
【0194】
上記のドメイン、ネットワーク要素、クラウドサービス、ノード、許可サービス、サービス、およびその他のコンピューティングプラットフォームは、任意のコンピューティングデバイスを使用して実装され得る。コンピューティングデバイスの１つの簡略図が、図１１に関して示されている。図１１のコンピューティングデバイスは、任意の固定コンピューティングデバイスまたはモバイルコンピューティングデバイスであり得る。
【0195】
図１１において、デバイス１１１０は、プロセッサ１１２０および通信サブシステム１１３０を含み、プロセッサ１１２０および通信サブシステム１１３０は、上述された実施形態の方法を実施するために協働する。通信サブシステム１１３０は、デバイス１１１０がその他のデバイスまたはネットワーク要素と通信することを可能にし、実施される通信のタイプに基づいて変動し得る。さらに、通信サブシステム１１３０は、複数の通信技術（任意の有線または無線通信技術を含む）を含み得る。
【0196】
プロセッサ１１２０は、プログラム可能論理を実行するように構成され、これは、データとともにデバイス１１１０上に格納され得、図１１の例ではメモリ１１３２として示されている。メモリ１１３２は、命令コードを格納する任意の有形、非一過性のコンピュータ読み取り可能な格納媒体であり得、上記命令は、プロセッサ１１２０によって実行されると、デバイス１１１０に、本開示の方法を実施させる。コンピュータ読み取り可能な格納媒体は、例えば光学（例えば、ＣＤ、ＤＶＤ等）、磁気（例えば、テープ）、フラッシュドライブ、ハードドライブ、または当該技術分野において公知のその他のメモリ等の有形または一過性／非一過性の媒体であり得る。
【0197】
代替的に、またはメモリ１１３２に加えて、デバイス１１１０は、例えば通信サブシステム１１３０を通して、外部格納媒体からデータまたはプログラム可能論理にアクセスし得る。
【0198】
図１１の例において、１つ以上のセンサ１１４０は、コンピューティングデバイスと関連付けられ得る。しかしながら、これは、オプションであり、いくつかの場合、コンピューティングデバイス１１１０は、センサとは関連付けられていない可能性がある。
【0199】
デバイス１１１０の様々な要素間の通信は、１つの実施形態では、内部バス１１６０を通したものであり得る。しかしながら、その他の形式の通信も可能である。
【0200】
本明細書中に記載されている実施形態は、本願の技術の要素に対応する要素を有している構造、システム、方法の例である。本明細書の記載は、当業者が本願の技術の要素に同様に対応する代替的な要素を有する実施形態を構成および使用することを可能にし得る。本願の技術の意図された範囲は、したがって、本明細書に記載された本願の技術とは異ならないその他の構造、システムまたは方法を含み、本明細書に記載された本願の技術からの非実質的な差異を有するその他の構造、システムまたは方法をさらに含む。
【0201】
動作は、特定の順序で図面に描写されているが、これは、所望の結果を達成するために、そのような動作が示されている特定の順序または連続的順序で実施されるべきであること、または、全ての例証されている動作が実施されるべきであることを必要としているとして理解されるべきではない。或る状況において、マルチタスク処理および並列処理が、採用され得る。さらに、上述された実装における様々なシステムコンポーネントの分離は、全ての実装においてそのような分離を必要としているとして理解されるべきではなく、記載されたプログラムコンポーネントおよびシステムは、概して、単一のソフトウェア製品内に一緒に統合され得るか、または、複数のソフトウェア製品にパッケージ化され得ることが理解されるべきである。
【0202】
また、離散的または分離的であるとして様々な実装において記載され、例証された技術、システム、サブシステム、および方法は、その他のシステム、モジュール、技術、または方法と組み合わされ得るか、または統合され得る。相互に結合されるかまたは直接的に結合されるかまたは通信するとして示されるかまたは議論されたその他のアイテムは、電気的、機械的、またはその他に関わらず、いくつかのインターフェース、デバイス、または中間コンポーネントを通して間接的に結合され得るかまたは通信し得る。その他の変更、置換、および代替は、当業者によって確かめられることができ、構成され得る。
【0203】
上記の詳細な記載は、様々な実装に適用されるものとして本開示の基本的な新規な特徴を示し、記載し、指摘してきたが、例証されたシステムの形式および詳細における様々な省略、置換、および変更が、当業者によってなされ得ることが理解され得る。加えて、方法ステップの順序は、それらが特許請求の範囲内に現れる順序によって示唆されてはいない。
【0204】
メッセージが電子デバイスに送信される／電子デバイスから送信されるとき、そのような動作は、即時的なものまたはサーバから直接的なものではない可能性がある。それらは、本明細書に記載されるデバイス／方法／システムをサポートするサーバまたはその他のコンピューティングシステムインフラストラクチャから、同期的または非同期的に送達され得る。上述のステップは、全体的または部分的に、デバイス／インフラストラクチャに対する／デバイス／インフラストラクチャからの同期的／非同期的通信を含み得る。さらに、電子デバイスからの通信は、ネットワーク上の１つ以上のエンドポイントに対するものであり得る。これらのエンドポイントは、例えばサーバ、分散コンピューティングシステム、ストリームプロセッサ等によってサービス提供され得る。また、コンテンツ配信ネットワーク（ＣＤＮ）は、電子デバイスに通信を提供し得る。例えば、典型的なサーバ応答とは異なり、サーバは、コンテンツ配信ネットワーク（ＣＤＮ）に対するデータを提供するかまたは示し得、例えば電子デバイスの後続のアクティビティ等の後の時間における電子デバイスによるダウンロードを待機し得る。したがって、データは、サーバから直接的に送信され得るか、または、システムの一部として、またはシステムとは別個に、その他のインフラストラクチャ（例えば、分散インフラストラクチャまたはＣＤＮ等）から送信され得る。
【0205】
典型的には、格納媒体は、半導体メモリデバイス（例えば、ダイナミックまたはスタティックランダムアクセスメモリ（ＤＲＡＭまたはＳＲＡＭ）、消去可能およびプログラム可能リードオンリーメモリ（ＥＰＲＯＭ）、電気的消去可能およびプログラム可能リードオンリーメモリ（ＥＥＰＲＯＭ）、およびフラッシュメモリ等）、磁気ディスク（例えば、固定ディスク、フロッピー（登録商標）ディスク、リムーバブルディスク等）、テープを含む別の磁気媒体、光学媒体（例えば、コンパクトディスク（ＣＤ）またはデジタルビデオディスク（ＤＶＤ）等）、または別のタイプの格納デバイスのうち任意のまたはいくつかの組み合わせを含み得る。上述された命令は、１つのコンピュータ読み取り可能または機械読み取り可能な格納媒体上に提供され得、または、代替的に、複数のノードを有している可能性がある大きなシステム内に分散された複数のコンピュータ読み取り可能または機械読み取り可能な格納媒体上に提供され得る。そのようなコンピュータ読み取り可能または機械読み取り可能な格納媒体または複数のコンピュータ読み取り可能または機械読み取り可能な格納媒体は、品物（または製品）の一部であると考えられる。品物または製品は、任意の製造された単一のコンポーネントまたは複数のコンポーネントを参照し得る。格納媒体または複数の格納媒体は、機械読み取り可能な命令を実行する機械内に配置され得るか、または、そこから機械読み取り可能な命令が実行のためにネットワークにわたってダウンロードされ得る遠隔サイトに配置され得る。
【0206】
上述の記載では、多数の詳細が本明細書中に開示された対象の理解を提供するために述べられている。しかしながら、実装は、これらの詳細のうちのいくつかを伴わずに実践され得る。その他の実装は、上述された詳細からの改変またはバリエーションを含み得る。添付の特許請求の範囲は、そのような改変およびバリエーションをカバーすることが意図されている。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
