JP2018147487A - アプリケーション配信コントローラ - Google Patents

Abstract

【課題】改良されたアプリケーション配信コントローラのためのシステム及び方法を提供することである。【解決手段】本発明の一態様は、コンピュータにより実現される方法であって、計算デバイスが、クライアントデバイスからサービスリクエストを受信するステップと、サービスリクエストに基づきルーティングパラメータを決定するステップと、リクエストされたサービス、リクエストされたサービスのセキュリティゾーン及びトークンに基づき、クライアントデバイスによるアクセスを認証するステップと、ルーティングパラメータと認証されたアクセスとに基づき、リクエストされたサービスを前記クライアントデバイスにルーティングするステップとを有する方法に関する。【選択図】図４

Description

本開示は、アプリケーション配信コントローラの分野に関する。特に、本開示は、リモートヘルスケアサービスを改良するためのアプリケーション配信コントローラに関する。

世界の多くの部分では、適切なヘルスケアの提供が、患者の近くに居る十分な医師の数の欠落のため複雑になってきている。低コストの接続性及び計算パワーを提供する先進的なデジタル／モバイル技術は、大規模な遠隔医療の選択肢を可能にしてきており、先進的なクラウドベースシステムが配置されている。これらのシステムは、各種ケアがローカルシステムを用いて便利且つコスト効率的に患者に提供されると共に、ビデオ会議を用いて付添人及びリモートの医師に提供されることを可能にする。

さらに、遠隔医療は、既存のシステムによっては十分には対処されない多数のセキュリティ及び効率性の問題を情報の秘匿性の性質のため提示する。ルーティングをサポートする既存のサーバは高価であり、多くのサービスが利用可能なシステムのニーズを充足しない限定的な特徴セットを有する。

本発明の課題は、改良されたアプリケーション配信コントローラのためのシステム及び方法を提供することである。

一実施例では、アプリケーション配信コントローラは、遠隔医療システムにおいて利用されうる。例えば、アプリケーション配信コントローラは、クライアントとサービスシステムとの間の境界を提供し、クライアントデバイスからサービスリクエストを受信し、サービスリクエストのリクエストされたサービスに基づくルーティングパラメータを決定してもよい。アプリケーション配信コントローラは、リクエストされたサービス、リクエストされたサービスのセキュリティゾーン及びトークンに基づき、クライアントデバイスによるアクセスを認証してもよい。そして、アプリケーション配信コントローラは、ルーティングパラメータ及び認証されたアクセスに基づきリクエストされたサービスをクライアントデバイスにルーティングしてもよい。

これらの態様の１つ以上の他の実現形態は、コンピュータストレージデバイスに符号化された方法のアクションを実行するよう構成される対応するシステム、装置、方法及びコンピュータプログラムを含む。上記の全てが包含的であるとは限らず、多くの追加的なステップ、特徴及び効果が想到され、本開示の範囲内に属することが理解されるべきである。さらに、本開示において用いられる言語は可読性及び教示的目的のために原理的には選択されており、ここに開示される主題の範囲を限定するものでないことが理解されるべきである。

これらの態様は、同様の参照数字が同様の要素を参照するのに用いられる添付図面の図において限定することなく例示的に示される。

本発明によると、改良されたアプリケーション配信コントローラのためのシステム及び方法を提供することができる。

図１は、ここに記載される技術のいくつかの実現形態による先進的な遠隔医療システムの具体例のブロック図を示す。 図２は、ここに記載される技術のいくつかの実現形態によるアプリケーション配信コントローラの具体例のブロック図を示す。 図３Ａは、ここに記載される技術のいくつかの実現形態によるアプリケーション配信コントローラを介しサービスを提供するためのルーティングテーブルの具体例を示す。 図３Ｂは、ここに記載される技術のいくつかの実現形態によるアプリケーション配信コントローラを介しサービスを提供するためのサービステーブルの具体例を示す。 図４は、ここに記載される技術のいくつかの実現形態によるアプリケーション配信コントローラを用いてサービスをルーティングする方法の具体例のフローチャートを示す。 図５は、ここに記載される技術のいくつかの実現形態によるリクエストされたサービスのルーティングパラメータを決定する方法の具体例のフローチャートを示す。 図６Ａは、ここに記載される技術のいくつかの実現形態による複数のアプリケーション配信コントローラのカスケード化されたパラレルな実現形態の具体例のブロック図を示す。 図６Ｂは、ここに記載される技術のいくつかの実現形態による複数のアプリケーション配信コントローラのカスケード化されたパラレルな実現形態の具体例のブロック図を示す。 図７は、ここに記載される技術のいくつかの実現形態によるリクエストされたサービスについてクライアントデバイスからのアクセスを認証する方法の具体例のフローチャートを示す。 図８Ａは、ここに記載される技術のいくつかの実現形態によるクライアントデバイスからのトークンを検証するか、クライアントデバイス上にないトークンが必要とされる場合、トークンを割当て検証するワークフローの具体例のフローチャートを示す。 図８Ｂは、ここに記載される技術のいくつかの実現形態によるクライアントデバイスからのトークンを検証するか、クライアントデバイス上にないトークンが必要とされる場合、トークンを割当て検証するワークフローの具体例のフローチャートを示す。 図９は、ここに記載される技術のいくつかの実現形態によるアプリケーション配信コントローラを介しエマージェンシサービスを提供するためのルーティングテーブルの具体例を示す。 図１０は、ここに記載される技術のいくつかの実現形態による符号化されたユーザ証明書及びシグネチャの具体例を備えたテーブルを示す。

サービスをセキュアにルーティングするシステム及び方法が説明される。以下の説明では、説明のために、実現形態の完全な理解を提供するために、多数の具体的な詳細が提供される。しかしながら、実現形態がこれら具体的な詳細なしに実施可能であることは当業者に明らかであろう。他の例では、実現形態を不明瞭にすることを回避するため、構造及びデバイスはブロック図形式で示される。

“一実現形態”又は“実現形態”という明細書における言及は、当該実現形態に関して説明される特定の特徴、構造又は特性が少なくとも１つの実現形態に含まれることを意味する。明細書の各所における“一実現形態では”というフレーズの出現は、必ずしも全てが同一の実現形態を参照しているとは限らない。

本実現形態はまた、ここでの処理を実行するための装置に関する。本装置は、特に必要とされる目的のために構成されてもよいし、あるいは、それはコンピュータに記憶されたコンピュータプログラムによって選択的に起動又は再構成される汎用コンピュータを含むものであってもよい。このようなコンピュータプログラムは、限定することなく、フロッピーディスク（登録商標）、光ディスク、ＣＤ−ＲＯＭ及び磁気ディスクを含む何れかのタイプのディスク、ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気若しくは光カード、フラッシュメモリ又は電子命令を記憶するのに適した何れかのタイプの媒体を含むコンピュータ可読記憶媒体に記憶されてもよい。

実現形態は、完全なハードウェア実現形態、完全なソフトウェア実現形態又はハードウェアとソフトウェア要素との双方を含む実現形態の形態をとりうる。一例となる実現形態は、限定することなく、ファームウェア、常駐ソフトウェア、マイクロコードなどを含むソフトウェアにより実現される。

さらに、実現形態は、コンピュータ又は何れかの命令実行システムによる利用のため、又は関連してプログラムコードを提供する非一時的なコンピュータ利用可能又はコンピュータ可読媒体からアクセス可能なコンピュータプログラムプロダクトの形態をとりうる。本説明のため、コンピュータ利用可能又はコンピュータ可読媒体は、命令実行システム、装置又はデバイスによる利用のため、又は関連してプログラムを内蔵、記憶又は移転可能な何れかの装置とすることができる。

ここに開示される技術及びシステムは、改良されたアプリケーション配信コントローラに独自の特徴セットを提供することによって従来技術の欠点を解消する。特に、アプリケーション配信コントローラは、例えば、ネットワーク（例えば、図１を参照して説明されるネットワーク１０２）を介しサービス（例えば、図１を参照して説明されるウェブサービス１３０）と外部のクライアント計算デバイス（例えば、図１を参照して説明されるノード１０８、ハブ１１０など）との間のインタフェースを提供する。いくつかの実現形態では、改良されたアプリケーション配信コントローラは、ユーザの役割、セキュリティのゾーン、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）ベースのルーティング及び／又は冗長性のサポートを用いて、方法又はＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）のレベルでのアクセスを提供するよう構成される。いくつかの実現形態では、改良されたアプリケーション配信コントローラはまた、又はあるいは、ＨＴＴＰ ｔｏ ＨＴＴＰＳプロトコルブリッジ、ＨＴＴＰＳ ｔｏ ＨＴＴＰプロトコルブリッジ、エマージェンシサービス、トークンの検証及び割当て及び／又は他のセキュリティサービスを提供するよう構成されてもよい。上記及び他の実現形態及び特徴は、本開示を通じて更に詳細に説明される。

ここに説明される技術による改良されたアプリケーション配信コントローラ（以降、単にアプリケーション配信コントローラとして参照される）は、単一のインタフェースを介し外部の計算デバイスに特権サービスへのアクセスを提供しうるサービスルーティングフレームワークを提供する。アプリケーション配信コントローラを用いて入力パケットを適切なサービスにルーティングすることによって、ディープパケットインスペクションが、パケットがルーティングされる前に実行可能である。例えば、ＡＰＩは様々なサービスに分離されうるため、アプリケーション配信コントローラは、サービスリクエストのＵＲＬを調べ、当該サービスを適切なサービスに転送し、いくつかの例では、これらのＡＰＩによってサービスをルーティングする前にパケットを検査しうるサービスルーティングフレームワークを提供してもよい。ディープパケット分析は、更なるセキュリティを提供し（例えば、トークン及び／又はシグネチャのデハッシュ処理、階層化されたセキュリティの複数の階層の提供など）、ユーザ又はクライアントデバイスを（例えば、ユーザ及び／又はトークンの役割に基づき）認証し、リクエストされたサービスがチェック及びバランシングされることを可能にし、リクエストをルーティングするための単一のインタフェースを提供するなどであってもよい。

いくつかの実現形態では、ここに説明される技術によるユーザの認証は、アプリケーション配信コントローラが当該ユーザの役割に基づき特定のサービスへの具体的なアクセスレベルを提供することを可能にする。例えば、説明されるように、ファイルシステム上の特定のサービス及び／又はディレクトリへのアクセスは、ホワイトリストディレクトリを用いて提供可能である（例えば、リスとされた役割／ユーザのみがサービスへのアクセスが許可される）。従って、認証プリミティブはユーザ又は役割に関して構築されてもよい。

ここに説明される技術及びシステムは更に、状況が人工知能システム（例えば、エクスパートシステム又は知識ベースシステム）による良好な取扱いを導くケースにおいて、リモートの医師をバーチャルな医師に置き換えるインテリジェントトリアージを遠隔医療システムに提供しうる。遠隔医療システムは、ローカルな付添人とソフトウェアとを用いて、患者が人間の医師によって診てもらう必要があるか、あるいは、バーチャル医師ＡＩシステムによるサービスで十分であるか判断する遠隔クリニックにおけるトリアージ手順を含んでもよい。遠隔医療システムは更に、知識ベース、推論エンジン、入力モジュール、出力モジュール、中央／モニタリングモジュール及び学習モジュールを含むＡＩシステム（例えば、エキスパート又は知識ベースシステム）を含んでもよい。いくつかの実現形態では、遠隔医療システムは、バーチャル医師の処理が必要に応じて介入することを選択可能な人間の医師群によって監視可能なリモートセンタ又は処理センタを含む。制御又は処理センタは、診察群が個々のダッシュボード上に示される／共有される各自の場所において運営される個々の医師を備えた大規模な制御／処理センタ又は分散センタとすることが可能である。

ＡＩによるトリアージを利用したレバレッジの同じ原理が、看護師／医師のアシスタントなどの他のタイプの医療専門職に適用可能である（例えば、明確なワークフローを有するバーチャルヘルスケア専門職及び各種特殊ケアオプションへのバーチャル医師の拡張）。遠隔医療システムのいくつかの効果は、かなり低いコストにおいてケアのより高い可用性である。既存の遠隔医療システムに対する更なる効果は、ルーチンケースの大部分がバーチャル医師によって取扱い可能であるため、特に重要でないヘルスケア問題について診られる患者数の増加を含む。さらに、小さな医師のチームが、例外が指摘される場合（バーチャル医師又は監視中の医師によって）、介入する相対的に多数のバーチャル医師のセッションを監視してもよい。従って、ここに説明される技術及びシステムを適用して、サービスルーティング、パケット処理及びセキュリティマネージメントが既存のシステムより迅速且つ効率的に実行可能であるため、より多くの患者が既存の遠隔医療システムより少ないリソースで診てもらうことが可能である。

図１は、ここに説明される技術の一実現形態による一例となる先進的な遠隔医療システム１００のブロック図を示す。図示されるシステム１００は、１つ以上のノード１０８、１つ以上のハブ１１０、１つ以上のアプリケーション配信コントローラ（ＡＤＣ）１２０及び複数のウェブサービスサーバ１２８を含む。図示される実現形態では、これらのエンティティはネットワーク１２８を介し通信結合される。システム１００が遠隔医療システムに関してここで説明されるが、システムは他の観点で配置されてもよいことが理解されるべきである。

図１に明示的には示されていないが、いくつかの実現形態では、クライアントデバイスは、ノード１０８又はハブ１１０において計算デバイス１１４を含んでもよいことが留意されるべきであるが、クライアントデバイスはパーソナルコンピュータ、ラップトップ、デスクトップ、スマートフォン、タブレットなどの何れかのユーザアクセス可能な計算デバイスを含んでもよいことが留意されるべきである。

図１は３つのノード１０８及び３つのハブ１１０を示しているが、ここに紹介される技術は、何れかの数のノード１０８又はハブ１１０を有する何れかのシステムアーキテクチャ上で実現されてもよい。さらに、図１の具体例は、１つのみのネットワーク１０２がノード１０８、ハブ１１０及びアプリケーション配信コントローラ１２０に結合することを示しているが、実際には、任意数のネットワーク１０２がエンティティを接続するため利用可能である。

一実現形態では、ウェブサーバ１２８ｂは、認証モジュール１２６を有し、アプリケーション配信コントローラ１２０を介しネットワーク１０２に接続される。認証モジュール１２６は、ユーザを登録し、及び／又はユーザのためにトークンを生成するコード及び／又はルーチンである。一実現形態では、認証モジュール１２６は、プロセッサにより実行可能な命令セットである。他の実現形態では、認証モジュール１２６は、メモリに記憶され、プロセッサによりアクセス可能及び実行可能である。

認証モジュール１２６は、ウェブサービスサーバ１２８及びウェブサービス１３０へのユーザアクセスを管理するためのゲートキーパとして機能しうる。いくつかの実現形態では、認証モジュール１２６は、ウェブサービスサーバ１２８へのアクセスをセキュアにするため、ランダムなシークレット数をアプリケーション配信コントローラ１２０及びクライアントデバイス（例えば、計算デバイス１１４）と別々に交換する。さらに、認証モジュール１２６は、ここで更に詳細に説明されるように、トークンを割当て、当該トークンをクライアントデバイスと通信しうる。

一実現形態では、認証モジュール１２６は、医療サービスプロバイダ、ノードスタッフ及び患者の１つ以上を含むユーザを登録する。一実現形態では、医療サービスプロバイダの登録は、医療サービスプロバイダログインを受信することを含む。例えば、認証モジュール１２６は、認証モジュール１２６がハブ１１０から医療サービスプロバイダに関するログインリクエストを受信し、ログインを許可すると判断すると（例えば、ここの何れかに説明されるように、有効なトークンを割り当てることによって）、医療サービスプロバイダを登録してもよい。一実現形態では、医療サービスプロバイダを登録することは、医療サービスプロバイダの役割を含む医療サービスプロバイダアカウントを維持することを含む。一実現形態では、医療サービスプロバイダアカウントは、関連する医療サービスプロバイダの教育、経験、医療専門性及び役割の１つ以上に関する情報を含む。

一実現形態では、認証モジュール１２６は、ノードスタッフを登録する。一実現形態では、ノードスタッフの登録は、ノードスタッフログインを受信することを含む。例えば、一実現形態では、認証モジュール１２６は、認証モジュール１２６は、ノード１０８から（ここに説明されるように、アプリケーション配信コントローラを介し）技師に関するログインリクエストを受信し、ログインを許可すると判断すると（例えば、ここの何れかに説明されるように、有効なトークンを割り当てることによって）、ノード１０８に技師を登録する。一実現形態では、ノードスタッフの登録は、ノードスタッフの役割を含むノードスタッフアカウントを維持することを含む。

一実現形態では、認証モジュール１２６は患者を登録する。一実現形態では、患者の登録は、バーチャル医師モジュールを用いて、患者をトリアージ及び／又は処置することを含む。バーチャル医師モジュール（図示せず）は、ノード１０８に配置された患者をトリアージ及び／又は処置するためにプロセッサにより実行可能なコード及びルーチンであってもよい。例えば、診察を求める患者がノード１０８に到着したと仮定すると、一実現形態では、認証モジュール１２６は、患者チェックイン信号をバーチャル医師モジュールにわたすことによって患者を登録し、バーチャル医師モジュールは、当該患者の処置方法を判断する。一実現形態では、患者の登録は患者の取り込みを含む。例えば、診察を求める患者がノード１０８に到着したと仮定すると、一実現形態では、認証モジュール１２６は、ストレージ１０６における患者の電子医療記録を更新するようリクエストすることによって、又は（患者が新規である場合）ストレージ１０６において新たな電子医療記録を作成するようリクエストすることによって患者を登録する。さらに、患者の役割ベースのアクセスレベルが割り当てられて維持されてもよい。

一実現形態では、認証モジュール１２６は、ユーザを登録し、各ユーザにトークンを発行する。例えば、ノード１０８における看護師は、例えば、ログイン／パスワード又は認証された証明書を含む登録情報を提供し、認証モジュール１２６は、看護師にトークンを発行する。いくつかの実現形態では、ウェブサービスサーバ１２８ｎはトークンを生成し、認証モジュール１２６はトークンを利用して、ウェブサービス１３０ｎへのアクセスをユーザに提供する前にユーザの身元を検証する。トークンは、ユーザの身元を特定するのに利用される。認証処理は、サインオンプロセスとして（例えば、サービスとしてＩＤをサポートするプロセス）又はＨＴＴＰＳを介し実現可能である。トークンを割り当てる認証モジュール１２６の処理は、例えば、図７及び８において、本明細書を通じて更に詳細に説明される。

図１は、ウェブサービスサーバ１２８ｂの一部として認証モジュール１２６を示す。他の実現形態では、認証モジュール１２６及びその機能は、システム１００の１つ以上のコンポーネント上で動作する（例えば、ノード１０８、ハブ１１０及び／又はウェブサービスサーバ１２８にわたって）。異なるサーバに機能を分散させることは、ロードバランシング配置技術において有用でありうる。

アプリケーション配信コントローラ（ＡＤＣ）１２０は、サービスをルーティングするためのハードウェア又はソフトウェア機構を有してもよい。図１の具体例において示されるように、アプリケーション配信コントローラ１２０は、サービスリクエストを受信し、ウェブサービス１３０を外部の計算デバイス（例えば、ノード１０８又はハブ１１０における計算デバイス１１４）にルーティングするため、ネットワーク１０２とウェブサービスサーバ１２８との間に配置される。いくつかの実現形態では、システム１００は、ウェブサービスサーバ１２８とネットワーク１０２との間にファイアウォールを有してもよい。このような実現形態では、アプリケーション配信コントローラ１２０は、ファイアウォールとウェブサービスサーバ１２８との間に配置されてもよい。アプリケーション配信コントローラ１２０は、内部のサービスと外部の計算デバイスとの間のブリッジとして機能するため、１つ以上の内部のサービス（例えば、ウェブサービスサーバ１２８及び／又は他のサービスなどのファイアウォールの背後のサービス）とネットワーク１０２との間に単一のインタフェースを提供してもよい。

いくつかの実現形態では、アプリケーション配信コントローラ１２０は、ネットワーク１０２上のクライアントデバイスによるトランスポートレイヤセキュリティ（ＴＬＳ）セッションを維持することによって、システム１００を簡単化する。アプリケーション配信コントローラ１２０がない場合、クライアントデバイスは各サービスとのセッションを確立する必要があり、そのメンテナンスは困難なタスクとなる。従って、アプリケーション配信コントローラ１２０をサービスとクライアントデバイスとの間のインタフェースとして利用することによって、メンテナンス及び計算リソースの使用が実質的に低減される。

いくつかの実現形態では、複数のアプリケーション配信コントローラ１２０は、図８Ａ及び８Ｂを参照して説明されるように、例えば、パラレルな階層に配置されてもよい。アプリケーション配信コントローラ１２０のこのような構成の利用は、ここで何れにおいて説明されるように、より高いセキュリティ粒度、ロードバランシングなどを提供しうる。

一実現形態では、ウェブサービス１３０は、ウェブサービスサーバ１２８によって提供される。一実現形態では、ウェブサービス１３０は、ウェブサービス１３０は、ここに説明される機能を実行するよう互いに連携する複数の分散されたモジュールを含む。サービスの具体例は、バーチャル医師モジュール、ビデオサービス、キューイングサービス、電子医療記録サービス及びここで述べられる他のサービスを含むが、他のサービスがここに説明される技術において可能であり、想到されることが理解されるべきである。さらに、いくつかのサービスは１つ以上のカテゴリをそれに関連付けたことが理解されるべきである。例えば、特定のサービスは、ストリーミングデータがアプリケーション配信コントローラ１２０によって当該特定のサービスから受信される限り、ソケット接続をオープンに維持するストリーミングカテゴリを有してもよい。同様に、いくつかのサービスは１つ以上のプロトコルをそれと関連付けていてもよい。例えば、特定のサービスは、ＨＴＴＰを用いてアプリケーション配信コントローラ１２０と通信してもよいが、アプリケーション配信コントローラ１２０は、当該サービスへのクライアントデバイスによるＨＴＴＰＳアクセスを提供する。

ネットワーク１０２は、ノード１０８、電子医療記録サーバ１０４、ハブ１１０及びアプリケーション配信コントローラ１２０との間の通信を可能にしうる。従って、ネットワーク１０２は、例えば、Ｗｉ−Ｆｉ、Ｗｉ−Ｍａｘ、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）、３Ｇ、イーサネット（登録商標）、８０２．１１、ＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）、ＤＳＬ（Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）、ＩｎｆｉｎｉＢａｎｄ、ＰＣＩ Ｅｘｐｒｅｓｓ Ａｄｖａｎｃｅｄ Ｓｗｉｔｃｈｉｎｇなどを含む技術を利用したリンクを含むことが可能である。同様に、ネットワーク１０２上で利用されるネットワーキングプロトコルは、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、ＭＰＬＳ（Ｍｕｌｔｉ−Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＬＤＰＡ（Ｌｉｇｈｔｗｅｉｇｈｔ Ｄｉｒｅｃｔｏｒｙ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）、ＣＤＭＡ（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、ＷＣＤＭＡ（登録商標）（Ｗｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、ＧＳＭ（登録商標）（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、ＨＳＤＰＡ（Ｈｉｇｈ−Ｓｐｅｅｄ Ｄｏｗｎｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）などを含むことができる。ネットワーク１０２上でやりとりされるデータは、ＨＴＭＬ（Ｈｙｐｅｒｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などを含む技術及び／又はフォーマットを利用して表現できる。さらに、リンクの全て又は一部は、例えば、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）、Ｓｅｃｕｒｅ ＨＴＴＰ及び／又はＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）又はＩＰｓｅｃ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｓｅｃｕｒｉｔｙ）などの従来の暗号化技術を利用して暗号化可能である。他の実現形態では、エンティティは、上述したものの代わりに、あるいは追加してカスタム及び／又は専用データ通信を利用可能である。実現形態に依存して、ネットワーク１０２はまた他のネットワークとのリンクを含むことが可能である。

一実現形態では、ネットワーク１０２は、例えば、インターネットなどの部分的に公衆又は完全に公衆のネットワークである。ネットワーク１０２は、プライベートネットワークとすることが可能であり、あるいは、１つ以上の別個の又は論理的なプライベートネットワーク（例えば、バーチャルプライベートネットワーク、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）及び／又はＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ））を含むことができる。さらに、ネットワーク１０２との間の通信リンクは、有線又は無線（すなわち、地上又は衛星ベースの送受信機）とすることができる。一実現形態では、ネットワーク１０２はＩＰベースのワイド又はメトロポリタンエリアネットワークである。

一実現形態では、ウェブサービスサーバ１２８ｎは、任意的なストレージ１０６を含む。一実現形態では、ストレージ１０６は、システム１００の患者の電子医療記録を含むデータベースである。一実現形態では、ノード１０８又はハブ１１０が患者に関する情報を送信する毎に、ストレージ１０６は当該患者の電子医療記録を更新する。

一実現形態では、ノード１０８は、患者が診察を受ける場所であり、計算デバイス１１４ａ及び各種医療デバイス１１２を含みうる。一実現形態では、ノード１０８は、ハブ１１０から遠隔に配置される。例えば、ノード１０８は、地方エリアに物理的に配置された施設であり、ハブ１１０は、都市又は他の都市エリアに物理的に配置される。他の具体例では、ノード１０８は患者の自宅であり、ハブ１１０は近所の病院である。上記はハブから遠隔に配置されるノード１０８の単なる具体例であり、他の具体例が存在することが認識されうる。一実現形態では、ノード１０８は可動的である。例えば、ノード１０８は、様々な場所に移動し、患者が車両において診察を受ける計算デバイス１１４ａ及び医療デバイス１１２を備えた車両である。医療サービス１１２の具体例は、限定することなく、聴診器、血圧メータ、パルスオキシメータ、温度計、検眼鏡、身長体重計、耳鏡、カメラ、遠隔心臓病デバイス（例えば、ＥＣＧマシーン）、遠隔病理デバイス（例えば、マイクロスコープ）、遠隔皮膚病デバイス（例えば、高解像度カメラ）、遠隔放射線デバイス（例えば、超音波マシーン）などを含む。

一実現形態では、医療デバイス１１２の１つ以上がノード１０８に統合される。一実現形態では、統合された医療デバイスは、格納及び転送機能を可能にするため、ノード１０８に通信結合される。例えば、一実現形態では、統合された医療デバイス１１２は、計算デバイス１１４ａに統合された医療デバイス１１２の出力を自動送信するため、ノードの計算デバイス１１４ａに通信結合される。統合された医療デバイスの出力は、一実現形態によると、ノードの計算デバイス１１４ａ上のソフトウェアによって取得され、電子医療記録サーバ１０４に転送される。このような実現形態は、ノードスタッフが医療デバイス１１２を読み間違うことからのエラーと、ノードスタッフが医療デバイス１１２の出力を記録ミスすることからの転記ミスとを効果的に減少させうる。

格納及び転送は、遠隔医療の非同期的な非インタラクティブな形態である。一実現形態では、格納及び転送は、患者及び医師が同時に利用可能でないときに適用される。例えば、一実現形態では、患者データは、ノード１０８によって収集又は取得され、ノード１０８における計算デバイス１１４ａ上に格納され、その後、ネットワーク１０２を介しハブ医師に転送される。ハブ医師は、以降において情報を確認し、診断、推奨、更なる情報に対するリクエストなどによって応答する。

いくつかの実現形態では、ノード１０８は、ノード１０８とハブ１１０との間に直接的な接続がないとき、格納及び転送を利用する。ノード１０８は、患者データのローカルコピーを格納し、ノード１０８がネットワーク１０２に接続されると、ハブ１１０と同期する。これは、ノード１０８が不良なネットワーク接続をしばしば受ける可能性があるため、特に有用である。例えば、患者を手助けする技師が遠隔地域に外出しているとき、技師は患者データを収集し、ノード１０８がより良好な接続を有するまで待機し、データを電子医療記録サーバ１０４に同期し、ケースを確認し、診断を実行するのに適した医師に通知が送信される。医師から診断を受信した後、技師は処方された薬を提供するか、あるいは、患者についてリクエストされた更なる検査を実行する。

ノード１０８は、計算デバイス１１４ａ及び医療デバイス１１２を操作するためスタッフが配置されてもよい。例えば、スタッフは、医療デバイス１１２を用いて患者の医療情報を取得し、計算デバイス１１４ａを用いて診断のため患者を登録するよう訓練された看護師であってもよい。一実現形態では、ノード１０８におけるスタッフは、ハブ１１０における医療サービスプロバイダほどは高度な教育を受けず、及び／又は専門的でない。例えば、ノードは看護師、医療技師、ラボ技師、医師の助手の１人以上が配置され、医療サービスプロバイダは医師（例えば、一般開業医又は専門医）であると仮定する。

医療サービスプロバイダでないスタッフをノード１０８に配置することは、システム１００における各医療サービスプロバイダの効果を効果的に増大させうる。例えば、地域に医師が不足している場合、各遠隔ノード１０８は、医師より迅速に訓練されうる医療技師を含む。一実現形態では、医療技師は、患者を登録し、患者のバイタルサインをとり、病気に基づき更なる医療デバイス１１２を利用する。さらに、ノードのスタッフは、医師による治療を必要としない状態の患者を処置してもよい。医師は、医療技師によって部分的に収集された患者の医療情報を受信し、患者を診察する。例えば、患者が発疹について訴えている場合、技師は高解像度カメラを用いて問題のあるエリアの写真を撮影し、医師はそれを確認し、患者と話し合いをしてもよい。従って、医療サービスプロバイダが患者を診察及び診断するのにより多くの時間を費やし、患者の様々な遠隔地に移動し、患者登録、基本的なバイタルサインの収集などの専門性の低いタスクを実行する時間を節約することを可能にすることによって、医師の有効性が増加する。

ノード１０８は、少なくとも１つの計算デバイス１１４ａを有する。一実現形態では、計算デバイス１１４ａは、診察のためハブ１１０における医療サービスプロバイダにアクセスするため、ノードにおける患者によって利用される。例えば、計算デバイス１１４ａは、ラップトップコンピュータ、デスクトップコンピュータ、携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、モバイル電子メールデバイス、埋め込み若しくは結合された１つ以上のプロセッサを備えたテレビ又はネットワーク１０２にアクセス可能な他の何れかの電子デバイスである。

一実現形態では、ノード１０８はテレビ会議ユニット１１６ａを有する。一実現形態では、テレビ会議ユニット１１６ａは、ハードウェアベースの手段である。他の実現形態では、テレビ会議ユニット１１６ａは、ソフトウェアベースの手段である。一実現形態では、テレビ会議ユニット１１６ａは、患者のビデオをキャプチャするウェブカメラ若しくは他のデバイスと、テレビ会議ソフトウェアとを含む計算デバイス１１６ａである。実現形態に関係なく、患者のビデオは、ライブの医師との遠隔医療セッションが開始された後、ハブ１１０に送信されてもよい。診察のためハブ１１０における医療サービスプロバイダにアクセスするためノード１０８における患者によって利用されるテレビ会議ユニット１１６ａは、ここでは診察デバイスとして参照されることがある。

各種実現形態では、ハブ１１０は、医師又は他の医療サービスプロバイダ（例えば、看護師、医師の助手など）が先進的な遠隔医療システムに接続する何れかの場所であってもよい。例えば、ハブ１１０は、医師のオフィス、病院、他のヘルスケア施設、医師の自宅などであってもよい。他の実現形態では、ハブ１１０は、医師のチームが遠隔医療システムに接続される１人以上の患者をモニタしうる遠隔オペレーションセンタであってもよい。一実現形態では、遠隔オペレーションセンタは、専門的訓練を受けた集中治療医がモニタし、ノード１０８において医師及び／又は患者と話し合い、重要なヘルスケア問題を有する患者を処置する集中治療医のハブであってもよい。ハブ１１０は、ノード１０８と接続し、医療サービスプロバイダが情報技術インフラストラクチャを利用して必要ベースでノード１０８における患者を遠隔診断及び診察することを可能にする。ハブ１１０の情報技術インフラストラクチャは、例えば、計算デバイス１１４ｂ、テレビ会議ユニット１１６ｂ、モニタリングモジュール１１８、デジタルクリップボード、モニタ、コラボレーションディスプレイ、プリンタなどを含む。モニタリングモジュール１１８は、医師又は他の医療サービスプロバイダがバーチャル医師モジュールの処置をモニタし、状況がライブの医師との遠隔医療セッションを保証すべきである場合、介入することを可能にする。

ハブ１１０は、少なくとも１つの計算デバイス１１４ｂを含む。一実現形態では、計算デバイス１１４ｂは、患者情報にアクセスし、ノード１０８において患者を診察するため、ハブ１１０において医療サービスプロバイダによって利用される。例えば、計算デバイス１１４ｂは、ラップトップコンピュータ、デスクトップコンピュータ、タブレットコンピュータ、携帯電話、ＰＤＡ、モバイル電子メールデバイス、受け込み又は結合された１つ以上のプロセッサを備えたテレビ、又は医師がシステムにログインし、患者を検索し、患者をスケジューリングし、処方箋を注文し、ノートをとり、テレビ会議を実行し、レポートを生成して解析を実行し、バーチャル医師セッションをモニタすることを可能にするソフトウェアを含む。

一実現形態では、ハブ１１０はテレビ会議ユニット１１６ｂを有する。一実現形態では、テレビ会議ユニット１１６ｂはハードウェアベースの手段である。他の実現形態では、テレビ会議ユニット１１６ｂはソフトウェアベースの手段である。一実現形態では、テレビ会議ユニットは、医療サービスプロバイダのビデオをキャプチャするウェブカメラ若しくは他のデバイスと、テレビ会議ソフトウェアとを含む計算デバイス１１４ｂである。実現形態に関係なく、医療サービスプロバイダのビデオは、医療サービスプロバイダがノード１０８において患者を診察しているときにノード１０８に送信される。

ハブにおける医療サービスプロバイダによるノードにおける患者の遠隔診察を可能にすることによって、医療サービスプロバイダがより効果的に利用され、患者はより高い品質の医療ケアを受けうる。例えば、医療サービスプロバイダが、ハブ１１０が配置される大都市における心臓専門医であると仮定する。また、都市から遠く離れた地方にいる患者が心臓関連の問題を有していると仮定する。一実現形態では、ハブは心臓専門医が患者の所に移動することなく地方にいる患者を遠隔に診察及び診断することを可能にする。従って、心臓専門医は、患者に移動するのに費やす時間を利用して、更なる患者を診察及び診断し、これにより、心臓専門医の利用性を向上させることができる。さらに、地方の患者は、そうでない場合には患者の選択肢ではなかった専門家（例えば、心臓専門医）による診察及び診断を受けることが可能になり、これにより、患者が受ける医療ケアの品質を向上させることができる。上記はハブ１１０における医療サービスプロバイダによるノード１０８における患者の遠隔診察が医療サービスプロバイダの利用をどのように増大し、患者が受ける医療ケアの品質を増大させるかの単なる具体例であることが認識されるであろう。

図２は、ここに説明される技術のいくつかの実現形態によるアプリケーション配信コントローラ１２０のブロック図２００である。アプリケーション配信コントローラ１２０は特殊なハードウェア計算デバイス／サーバであるとして示されているが、それはプロセッサ上で実行可能なソフトウェアモジュール又はハードウェアとソフトウェアとの組み合わせとして実現されてもよいことが留意されるべきである。図２に示されるように、アプリケーション配信コントローラ１２０は、バス２０２に結合されたプロセッサ２０４、メモリ２０６、通信ユニット２０８及びストレージ２１０を有する。一実現形態では、バス２０２の機能は相互接続するチップセットによって提供される。

通信ユニット２０８は、ノード１０８、ハブ１１０及び電子医療記録サーバ１０４からデータを受信する。通信ユニット２０８は、バス２０２に結合される。一実現形態では、通信ユニット２０８は、ネットワーク１０２との直接的な物理的接続又は他の通信チャネルのためのポートを有する。他の実現形態では、通信ユニット２０８は、１つ以上の無線通信方法を利用して、ネットワーク１０２又は他の通信チャネルとデータをやりとりする無線送受信機を有する。

プロセッサ２０４は、何れかの汎用プロセッサであってもよい。プロセッサ２０４は、算術論理ユニット、マイクロプロセッサ、汎用コントローラ又は計算を実行し、コード及びルーチンを実行する他のプロセッサアレイを有する。プロセッサ２０４は、ウェブサービスサーバ１２８の他のコンポーネントとの通信用のバス２０２に結合される。プロセッサ２０４は、データ信号を処理し、ＣＩＳＣ（Ｃｏｍｐｌｅｘ Ｉｎｓｔｒｕｃｔｉｏｎ Ｓｅｔ Ｃｏｍｐｕｔｅｒ）アーキテクチャ、ＲＩＳＣ（Ｒｅｄｕｃｅｄ Ｉｎｓｔｒｕｃｔｉｏｎ Ｓｅｔ Ｃｏｍｐｕｔｅｒ）アーキテクチャ、又は命令セットの組み合わせを実現するアーキテクチャを含む各種計算アーキテクチャを有してもよい。図２には１つのみのプロセッサが示されているが、複数のプロセッサが含まれてもよい。他のプロセッサ、オペレーティングシステム、センサ、ディスプレイ及び物理的構成が可能であることが当業者に明らかであろう。

メモリ２０６は、非一時的な記憶媒体である。メモリ２０６は、プロセッサ２０４により実行可能な命令及び／又はデータを保持する。一実現形態では、メモリ２０６に記憶される命令及び／又はデータは、ここに説明される技術の何れか及び／又は全てを実行するためのコードを含む。メモリ２０６は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）デバイス、ＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）デバイス、フラッシュメモリ又は当該分野において知られる他のメモリデバイスであってもよい。一実現形態では、メモリ２０６はまた、例えば、ハードディスクドライブ、フロッピーディスク（登録商標）ドライブ、ＣＤ−ＲＯＭデバイス、ＤＶＤ−ＲＯＭデバイス、ＤＶＤ−ＲＡＭデバイス、ＤＶＤ−ＲＷデバイス、フラッシュメモリデバイス又はより永続的に情報を記憶するための当該分野において知られる他のマスストレージデバイスなど、不揮発性メモリ又は同様の永続的ストレージデバイス及び媒体を含む。メモリ２０６は、アプリケーション配信コントローラ１２０の他のコンポーネントとの通信用のバス２０２に結合される。一実現形態では、コントローラモジュール２２２は、メモリ２０６に格納され、プロセッサ２０４により実行可能である。

コントローラモジュール２２２は、アプリケーション配信コントローラ１２０の機能を提供するため、プロセッサ２０４により実行可能なコード及びルーチンである。一実現形態では、コントローラモジュール２２２は、プロセッサ２０４により実行可能な命令セットである。他の実現形態では、コントローラモジュール２２２はメモリ２０６に格納され、プロセッサ２０４によりアクセス及び実行可能である。本開示の目的のため、例えば、より多い、より少ない又は異なるコンポーネントが利用されるなど、他の実現形態が可能であるが、アプリケーション配信コントローラ１２０の機能は、コントローラモジュールなどのアプリケーション配信コントローラ１２０の１つ以上のコンポーネントによって実行されてもよい。

ストレージデバイス２１０は、例えば、ハードドライブ又はソリッドステートメモリデバイスなど、データを保持可能な何れかのデバイスである。ストレージデバイス２１０は、不揮発性メモリデバイス又は同様の永続的ストレージデバイス及び媒体である。一実現形態では、ストレージデバイス２１０は、アプリケーション配信コントローラ１２０のデータ及び情報を格納する。いくつかの実現形態では、ここに説明されるようなルーティング及びサービステーブルの１つ以上は、ストレージ２１０に格納されてもよい。

ここで用いられるように、モジュールという用語は指定された機能を提供するのに利用されるコンピュータプログラムロジックを参照する。従って、モジュールは、ハードウェア、ファームウェア及び／又はソフトウェアにより実現可能である。一実現形態では、プログラムモジュールは、ストレージデバイス２１０に格納され、メモリ２０６にロードされ、プロセッサ２０４により実行される。ここに説明されるエンティティの実現形態は、ここに説明されるもの以外及び／又は異なるモジュールを含むことができる。さらに、モジュールに付属される機能は、他の実現形態では他の又は異なるモジュールによって実行可能である。さらに、本説明は簡潔性及び便宜性のため、モジュールという用語を省略することもある。

アプリケーション配信コントローラ１２０を参照して説明されるコンポーネント２０２〜２１０はまた、ウェブサービス１３０、認証モジュール１２６及び／又はストレージ１０６を実行するのに利用されてもよいことが留意されるべきである。

図３Ａ及び３Ｂはそれぞれ、アプリケーション配信コントローラ１２０を介しサービスを提供するための一例となるルーティングテーブル３００ａ及び一例となるサービステーブル３００ｂを示す。単一のモノリシックアプリケーションより、現代のシステムにおけるアプリケーションは、分散されたシステムを介しモジュール形式で提供されるサービスセットに緩く結合されうる。いくつかの実現形態では、アプリケーション配信コントローラ１２０は、クライアントデバイスがバックエンドサービス（例えば、ウェブサービス１３０）のアーキテクチャに類似したアプリケーション又はサービスセットに接続する単一の接触点又はインタフェースを提供する。

アプリケーション配信コントローラ１２０は、データ構造を維持することによって（例えば、ストレージ２１０に）サービスルーティングを実現してもよい。これらのデータ構造は、ルーティングテーブルと、いくつかの実現形態ではサービステーブルとを含むものであってもよい。ルーティングテーブルは、各種サービスのためのルーティング情報を取得し、サービステーブルは、これらのサービスのための情報を提供する。ルーティングテーブル及びサービステーブルは、サービス定義によってリンクされる。情報が２つのテーブル間で異なる具体例では、サービステーブルにおけるデータはルーティングテーブルにおいてデータを無効にしうる。

アプリケーション配信コントローラ１２０は、例えば、実行時若しくはアプリケーション配信コントローラ１２０に知られるリロードサービスに動的に応答して、ルーティングテーブル及びサービステーブルにおける情報をリロードするよう構成されてもよい。リロードサービスは、ルーティング又はサービステーブル全体をリロードしてもよい。例えば、所与のノード１０８においてエラーが発生した場合、又はサービス若しくはルーティングテーブルが更新される必要がある場合（例えば、新たなサービス又はサービスに関する情報への変更のため）、リロードされたサービスは、ルーティング及び／又はサービステーブルが更新された正確なルーティング情報を有するようリフレッシュされることを可能にする。

いくつかの実現形態では、ルーティング及び／又はサービステーブルは、図３Ａ及び３Ｂに示されるような情報特定の順序及び有無を含むものであってもよいが、他の実現形態が可能であることが理解されるべきである。各種実施例では、ルーティング及びサービステーブルは特定のドメインに特有のものであってもよく、ユーザが各種ドメイン上で異なる特権を有することが可能であるか、あるいはドメインのホワイトリスト上に存在しないことを意味する。さらに、アプリケーション配信コントローラの１つの具体例は、複数のドメインに対するルーティング及びサービステーブルを含んでもよい。いくつかの実現形態では、異なるドメインに特有のルーティング及びサービステーブルは、異なるルーティングテーブル及びサービステーブルの名前によって区別される。さらに、いくつかの実現形態では、何れかのドメインに関連付けされず、多くのドメインに共通する汎用的なルーティング及びサービステーブルが、アプリケーション配信コントローラによって維持されてもよい。

図３Ａは、ここに説明される技術のいくつかの実現形態によるアプリケーション配信コントローラ１２０を介しサービスを提供するための一例となるルーティングテーブル３００ａを示す。一例となるルーティングテーブルでは、各ラインは、単一のスペース、複数のスペース、タブなどによって分離されうる複数のデータタイプを含んでもよい。一例となるルーティングテーブル３００ａは、例えば、ＳＥＲＶＩＣＥ３０２、ＤＳＴＩＰ３０４、ＤＳＴＰＯＲＴ３０６、ＰＲＯＴＯＣＯＬ３０８、ＳＴＲＰ３１０、ＴＹＰＥ３１２、ＳＲＶＣＤＥＦＩＮＩＴＩＯＮ３１４、ＴＯＫＥＮＮＥＥＤＥＤ３１６、ＷＬＲＯＬＥＳ３１８及びＳＥＣＵＲＩＴＹＺＯＮＥ３２０を含むサービスのためのエンティティを含む。ＳＥＲＶＩＣＥ３０２は、クライアントによって求められたサービス（例えば、リクエストされたサービス）の名前を表す。ＤＳＴＩＰ３０４は、サービスリクエストがルーティングされるべきデスティネーションＩＰアドレス、すなわち、サービスが運営されているＩＰアドレスを表す。ＤＳＴＰＯＲＴ３０６は、サービスが運営されているデスティネーションポートを表す。ＰＲＯＴＯＣＯＬ３０８は、アプリケーション配信コントローラ１２０とサービスとの間に確立されるべき接続プロトコルのタイプを表す。ＳＴＲＰ３１０は、アプリケーション配信コントローラ１２０に固有のものであり、例えば、図６Ａ及び６Ｂを参照して説明されるように、コマンドにおいてプリフィックスを外すか否かを示す。ＴＹＰＥ３１２は、ＡＰＩコールのカテゴリを示す。いくつかの実現形態では、カテゴリは、“ｎｏｒｍａｌ”、“ｇｅｔｓｔｒｅａｍ”、“ｐｏｓｔｓｔｒｅａｍ”、“ｅｖｅｎｔ”、“ｒｅｓｅｔ”、“ｓｅｃｕｒｅ”及び“ｔｏｋｅｎ”の１つとして定義（及びいくつかの実現形態では制限）されてもよい。カテゴリの具体例は、ここの何れかにおいてさらに詳細に説明される。ＳＲＶＣＤＥＦＩＮＩＴＩＯＮ３１４は、サービスの定義を表し、ルーティングテーブル（例えば、ルーティングテーブル３００ａ）とサービステーブル（例えば、サービステーブル３００ｂ）との間のリンクとして機能しうる。ＴＯＫＥＮＮＥＥＤＥＤ３１６は、サービスへのアクセスがトークンを必要とするか否かを示す（例えば、ここの何れかにおいて説明されるように）。いくつかの実現形態では、ＴＯＫＥＮＮＥＥＤＥＤ３１６が１の値を有する場合、トークンが必要とされ、ＴＯＫＥＮＮＥＥＤＥＤ３１６が０の値を有する場合、トークンは必要とされず、サービスは、ここの何れかにおいて説明されるように、エマージェンシにおいて迅速なアクセスを提供するのに役立つトークン検証なしのフリーアクセス又は他の認証チェックを有する。ＷＬＲＯＬＥＳ３１８は、サービスについてホワイトリストされた１つ以上の役割（例えば、コンマによって分離されうる）を示す。サービスについてホワイトリストされた役割又はユーザは、何れのユーザがサービスへのアクセスが付与されうるかを示す。ＳＥＣＵＲＩＴＹＺＯＮＥ３２０は、以下で更に詳細に説明されるように、サービス又はＡＰＩコールが属するセキュリティゾーンを表す。

図３Ｂは、ここに説明された技術のいくつかの実現形態によるアプリケーション配信コントローラ１２０を介しサービスを提供するための一例となるサービステーブル３００ｂを示す。一例となるサービステーブル３００ｂは、ＳＥＲＶＩＣＥＮＡＭＥ３５２、ＭＥＴＨＯＤ３５４、ＡＰＩ３５６、ＴＹＰＥ３６０、ＴＯＫＥＮＮＥＥＤＥＤ３６０、ＷＬＲＯＬＥＳ３６２及びＳＥＣＵＲＩＴＹＺＯＮＥ３６４を含むサービスのためのエンティティを含む。ＳＥＲＶＩＣＥＮＡＭＥ３５２は、ルーティングテーブルのＳＲＶＣＤＥＦＩＮＩＴＩＯＮ３１４に対応する。ＭＥＴＨＯＤ３５４は、ｇｅｔ、ｐｏｓｔ、ｐｕｔ、ｈｅａｄ、ｄｅｌｅｔｅ、ｃｏｎｎｅｃｔ、ｔｒａｃｅ、ｏｐｔｉｏｎｓなどの複数の可能な入力メソッド又はコマンドの１つを表す。ＡＰＩ３５６は、レジスタからリクエストされたアプリケーションプログラミングインタフェースを表し、ＵＲＬに含まれてもよい。

ＳＥＣＵＲＩＴＹＺＯＮＥ３６４は、ルーティングテーブルにリストされたＳＥＣＵＲＩＴＹＺＯＮＥ３２０と同じであるが、異なる値を含んでもよい。サービステーブル３００ｂにおけるＳＥＣＵＲＩＴＹＺＯＮＥ３６４の値がルーティングテーブル３２０におけるＳＥＣＵＲＩＴＹＺＯＮＥ３２０と異なる場合、ルーティングテーブルにおけるセキュリティゾーンが利用される。例えば、クライアントがＳｔｒｅａｍ３に対応するサービス（例えば、ＳＥＲＶＩＣＥ３２０にリストされるような）にポストすることを試みている場合（例えば、ＭＥＴＨＯＤ３５４）、セキュリティゾーンは更なるセキュリティ検証をコールしてもよい。メソッド間を区別することによって、アプリケーション配信コントローラ１２０は、セキュリティに増大した粒度を提供する（例えば、特定の役割はサービス内の異なるメソッド又はＡＰＩへのアクセスを有してもよい）。具体例では、技師（例えば、看護師）がライブストリームを取得するためのアクセスを有してもよいが、管理者はライブストリームをポストするためのアクセスを有してもよい。

具体例では、全てのサービスが例外（例えば、デフォルト値への修正）を有しうるＡＰＩのセットを有してもよい。ストリーミングサーバ上のＳｔｒｅａｍ３と呼ばれるサービスでは、医師は第１のメソッド及びＡＰＩに対するアクセスを有してもよく、管理者及び技師は第２のメソッド及びＡＰＩに対するアクセスを有してもよく、管理者は第３のメソッド及びＡＰＩに対するアクセスを有してもよい。例えば、メソッド及びＡＰＩに基づき特定の例外が存在しうる（例えば、医師はサービスへの標準的なアクセスを有しうるが、管理者は当該サービスの特定のメソッドへのアクセスを有しうる）。一実現形態では、ＡＰＩの処理はＵＲＬを解析することによって実行される。例えば、アプリケーション配信コントローラ１２０は、ドメイン名／サービス名／ＡＰＩなどのＵＲＬを解析し、サービス及びＡＰＩを決定してもよい。

アプリケーション配信コントローラ１２０によるルーティングテーブル及びサービステーブルのシナリオの具体的な利用シナリオとして、アプリケーション配信コントローラ１２０は、例えば、ＨＴＴＰＳポートを利用して、ＵＲＬの形式によりサービスリクエストを受信する。アプリケーション配信コントローラ１２０は、ＵＲＬにおけるサービス名を検出する（例えば、ＵＲＬがｗｗｗ．ｄｏｍａｉｎ．ｃｏｍ／ｓｔｒｅａｍ３／ｌｉｖｅｓｔｒｅａｍである場合、サービス名はドメインの直後に現れてもよく、本例では、ｓｔｒｅａｍ３がサービス名である）。アプリケーション配信コントローラ１２０はまた、ＵＲＬにおけるＡＰＩを検出してもよい（例えば、前の具体例では、ライブストリームがＡＰＩである）。アプリケーション配信コントローラ１２０は、ＵＲＬに提示される具体的なサービス名がルーティングテーブルに存在するか確認し、ルーティングを処理すべきか判断してもよい。アプリケーション配信コントローラ１２０がルーティングテーブル（例えば、ルーティングテーブル３００ａ）におけるサービス名（例えば、ＳＥＲＶＩＣＥ３０２フィールドにおける）のエントリを検出した場合、アプリケーション配信コントローラ１２０は、デスティネーションＩＰ（例えば、ＤＳＴＩＰ３０４フィールドにおける）、デスティネーションポート（例えば、ＤＳＴＰＯＲＴ３０６フィールドにおける）、プロトコル（例えば、ＰＲＯＴＯＣＯＬ３０８フィールドにおける）、呼び出し対象のコマンドのカテゴリ（例えば、ＴＹＰＥ３１２フィールドにおける）などをロードしてもよい。

アプリケーション配信コントローラ１２０は、所与のＡＰＩ名（例えば、ライブストリーム）がサービステーブル（例えば、サービステーブル３００ｂ）に存在するかチェックしてもよい。いくつかの実現形態では、アプリケーション配信コントローラ１２０は、サービスのサービスデスティネーション（例えば、ＳＲＶＣＤＥＦＩＮＩＴＩＯＮ３１４フィールドにおける）に対応する１つ以上のサービステーブル（例えば、サービステーブル３００ｂ）エントリを検出してもよい。サービステーブル情報が存在する場合、アプリケーション配信コントローラ１２０は、ＵＲＬにおけるメソッド（例えば、ＭＥＴＨＯＤ３５４フィールドにおける）とＡＰＩ（例えば、ＡＰＩ３５６フィールドにおける）との組み合わせ、ホワイトリスト役割（例えば、ＷＬＲＯＬＥＳ３６２フィールドにおける）、セキュリティのゾーン（例えば、ＳＥＣＵＲＩＴＹＺＯＮＥ３６４フィールドにおける）、トークンのニーズ（例えば、ＴＯＫＥＮＮＥＥＤＥＤ３６０フィールドにおける）及びカテゴリ（例えば、ＴＹＰＥ３５８フィールドにおける）をチェックしてもよい。

いくつかの実現形態では、アプリケーション配信コントローラ１２０がルーティングテーブルにおいてサービス名を検出したが、サービステーブルにおいてリクエストされたメソッド／ＡＰＩを検出しなかった場合、アプリケーション配信コントローラ１２０は、リクエストされたメソッドの粒度情報がなく、ルーティングテーブルにおけるデフォルト値が利用されると判断する。従って、サービステーブルにおける値は、存在する場合には、ルーティングテーブルにおける値を無効にしうるが、サービステーブルにおいてそのような値又はエントリがない場合、ルーティングテーブルにおけるデフォルト値が利用される。

図４は、ここに説明される技術のいくつかの実現形態によるアプリケーション配信コントローラ１２０を利用してサービスをルーティングするための一例となる方法４００のフローチャートを示す。４０２において、アプリケーション配信コントローラ１２０は、クライアントデバイスからサービスリクエストを受信してもよい。いくつかの実現形態では、サービスリクエストは、ここで何れにおいて更に詳細に説明されるように、ＵＲＬの形式で受信される。

４０４において、アプリケーション配信コントローラ１２０は、サービスリクエストのリクエストされたサービスに基づきルーティングパラメータを決定してもよい。いくつかの実現形態では、ルーティングパラメータは、例えば、図３Ａ及び３Ｂを参照して説明されるように、ルーティング又はサービステーブルを用いて決定される。パラメータを決定するプロセスは、図５を参照して更に詳細に説明される。

４０４において、アプリケーション配信コントローラ１２０は、サービスリクエストのリクエストされたサービス、リクエストされたサービスのセキュリティゾーン及び／又は検証されたトークンに基づきクライアントデバイスによるアクセスを認証してもよい。セキュリティゾーン、トークンなどの何れが呼び出されているかの判定は、例えば、図３Ａ及び３Ｂを参照して説明されるように、ルーティング及びサービステーブルに基づき決定可能である。アクセスを認証するプロセスは、図７〜８Ｂを参照して更に詳細に説明される。

４０６において、アプリケーション配信コントローラ１２０は、ルーティングパラメータ及び認証されたアクセスに基づきリクエストされたサービスをクライアントデバイスにルーティングしてもよい。

図５は、ここに説明される技術のいくつかの実現形態によるリクエストされたサービスのルーティングパラメータを決定する一例となる方法５００のフローチャートを示す。一例となる方法５００は、図４の４０４における処理を実行するための更なる詳細を表す。５０２において、アプリケーション配信コントローラ１２０は、サービスリクエストに基づきリクエストされたサービスを決定してもよい。いくつかの実現形態では、アプリケーション配信コントローラ１２０は、上述されたように、サービスリクエストのＵＲＬを用いてリクエストされたサービスを決定する。

５０４において、アプリケーション配信コントローラ１２０は、リクエストされたサービスをルーティングするためのプロトコルブリッジに利用されるリクエストされたサービスのプロトコルを決定してもよい。例えば、いくつかの実現形態では、アプリケーション配信コントローラ１２０は、ルーティングテーブルから（例えば、ルーティングテーブル３００ａのＰＲＯＴＯＣＯＬ３０８フィールドから）プロトコルを決定してもよい。例えば、プロトコルはＨＴＴＰ又はＨＴＴＰＳを含んでもよい。いくつかの実現形態では、アプリケーション配信コントローラ１２０がプロトコルブリッジを提供するとき、アプリケーション配信コントローラ１２０は、クライアントデバイスに単一のＨＴＴＰＳインタフェースを提供してもよい（例えば、これらはネットワーク１０２を介しウェブサービス１３０にアクセスする）。従って、ウェブサービス１３０（又は電子医療記録サーバ１０４など）は、ＨＴＴＰＳセキュリティを必ずしも充たす必要なく（例えば、ウェブサービス１３０のそれぞれにおいて証明書を有する）、ＨＴＴＰＳの証明書管理を簡単化することなく、ＨＴＴＰインタフェースを維持してもよい。

プロトコルがリクエストされたサービスとのＨＴＴＰを呼び出す具体例では、アプリケーション配信コントローラ１２０は、ＨＴＴＰＳ ｔｏ ＨＴＴＰブリッジを提供してもよい。アプリケーション配信コントローラ１２０は、クライアントデバイスとリクエストされたサービスとの間のセキュアなブリッジとして機能しうる。例えば、当該ブリッジは、クライアントデバイスとアプリケーション配信コントローラ１２０との間のＨＴＴＰＳ ＯｐｅｎＳＳＬ接続と、信頼されたネットワーク内のウェブサービス１３０とのＨＴＴＰ接続（例えば、アプリケーション配信コントローラ１２０とウェブサービスサーバ１２８との間の接続）とをセットアップすることによって実現されてもよい。

プロトコルがリクエストされたサービスとのＨＴＴＰＳを呼び出す具体例では、アプリケーション配信コントローラ１２０は、信頼されたネットワーク内のアプリケーション配信コントローラ１２０からのセキュア接続（例えば、ウェブサービスサーバ１２８ｂ上の認証モジュール１２６との接続と同様に）とのインタフェースを提供しうる。従って、アプリケーション配信コントローラ１２０は、外部デバイスと内部デバイスとの双方とのＨＴＴＰＳ接続を提供するよう構成されてもよい。

５０６において、アプリケーション配信コントローラ１２０は、リクエストされたサービスのカテゴリに基づきソケットハンドリングを決定してもよい。いくつかの実現形態では、アプリケーション配信コントローラ１２０は、ルーティングテーブルから（例えば、ルーティングテーブル３００ａにおけるＴＹＰＥ３１２フィールドから）カテゴリを決定してもよい。サービスは変動する可能性があり、各サービスには、ソケットハンドリングが現在のシステムよりも細かく当該サービスに調製されることを可能にするカテゴリが割り当てられてもよい。各カテゴリに関するソケットハンドリングは、アプリケーション配信コントローラ１２０が、ノーマルカテゴリに対応するものなど、単一タイプのソケットハンドリングのみに従って通信を処理する既存のシステムよりはるかに万能なものになることを可能にする。

一例となるカテゴリは、ノーマル、ストリーミング、イベント、セキュア、リセット及びトークンを含んでもよい。ノーマルカテゴリでは、出力される接続パスはコンスタントにライブ状態であるが、リターンパスは、リターンパス上のソケット通信のエンドがコンテンツの長さに依存するようコンテンツの長さに基づきライブ状態に維持される。ストリーミングカテゴリでは、ストリーミングデータがアプリケーション配信コントローラ１２０を到達し続ける限り、ソケット接続がライブ状態となる。イベントカテゴリでは、ソケット通信は、データのエンド（例えば、＼ｒ＼ｎによってマーク付けされる）が受信されるまでオープン状態に維持される。セキュアカテゴリでは、信頼されるネットワーク内のアプリケーション配信コントローラ１２０からの接続はＨＴＴＰＳであってもよい。セキュアカテゴリは、複数のアプリケーション配信コントローラが存在する（例えば、図６Ａ及び６Ｂを参照して説明されるように）、内部通信（例えば、ウェブサービスサーバ１２８とアプリケーション配信コントローラ１２０との間などの信頼されるネットワーク内のもの）がセキュアである必要があるなどの実現形態において利用されてもよい。リセットカテゴリは、自らを動的に再構成するためにアプリケーション配信コントローラ１２０によってサポートされる内部カテゴリである。トークンカテゴリは、後述されるように、例えば、認証モジュール１２６から入力されたトークンを処理するためにアプリケーション配信コントローラ１２０によってサポートされる内部カテゴリである。

いくつかの実現形態では、アプリケーション配信コントローラ１２０は、それがサポートするサービスの範囲のため、これらのカテゴリのそれぞれを処理するよう構成されてもよい。例えば、ストリーミングカテゴリにおけるサービスについて、ストリーミングオーディオ又はビデオは、ロードバランシングのため異なって処理されてもよく、アプリケーション配信コントローラ１２０は、データが送信に利用可能である限り、データを送信し続けてもよい。他の具体例では、イベントについて、ストリーミングソケットハンドラは、アプリケーション配信コントローラ１２０がエンドマーカ（例えば、＼ｒ＼ｎ）を検出するまで入力されたデータストリームを解析する必要があるため、不良な適合となる。従って、アプリケーション配信コントローラ１２０によって処理される各種サービスのため、カテゴリは各タイプのサービスを処理するソケットを示すため、ルーティング又はサービステーブルにおけるサービス属性であってもよい。

図５に戻って、５０８において、アプリケーション配信コントローラ１２０は、ストリップ通知（例えば、ルーティングテーブル３００ａにおけるＳＴＲＰ３１０フィールドにおける）に基づきサービスリクエストのＵＲＬからサービス名を取り除く。ストリップ通知は、アプリケーション配信コントローラ１２０の内部の処理を表す。サービス名がコマンドの一部であって、下位レイヤサービスにわたされる特定のコマンド（例えば、サービスリクエスト）であって、サービス名が下位レイヤサービスにわたされる必要がない他のコマンドがある。例えば、ストリップ通知は、コマンドパケットにおけるサービス名を保持するか（例えば、ＳＴＲＰ３１０における値が０である場合）、あるいは、コマンドパケットからサービス名を取り除く（例えば、ＳＴＲＰ３１０における値が０である場合）。

いくつかの実現形態では、コマンドパケットのデスティネーションサービスがサービス名を用いて決定され、コマンドパケットが当該特定のサービスにルーティングされると、サービス名を再び利用する必要がないため、ストリップ処理が可能とされる（例えば、サービスの名前がコマンド／リクエストパケット／ＵＲＬから取り除かれる）。しかしながら、いくつかの具体例では、ストリップ処理は不可とされ（例えば、サービスの名前がコマンドパケットから取り除かれない）、この結果、サービス名が再利用可能である。ストリップ処理が不可とされるこのような一例は、図６Ａ及び６Ｂを参照して説明されるなど、複数のアプリケーション配信コントローラ１２０があるときであり（例えば、特に同じレベルの階層において）、この結果、適切なアプリケーション配信コントローラがコマンドパケットからサービス名を決定できる。

１つ以上のアプリケーション配信コントローラ１２０を介したサービスのルーティングは、複数の方法で実現されうる。図６Ａにおいて、ブロック図６００ａは、ここに説明される技術のいくつかの実現形態による階層的又はカスケード化された構成における複数のアプリケーション配信コントローラ６０２，６０４，６０６の実現形態を示す。例えば、アプリケーション配信コントローラ６０２は６１２においてサービス１にルーティングし、アプリケーション配信コントローラ６０４は６１４においてサービス２及び６１６においてサービス３にルーティングし、アプリケーション配信コントローラ６０６は６１８においてサービス４にルーティングしてもよい。

いくつかの実現形態では、サービス名は階層として複数のサービスを含むことができる（例えば、コマンド又はＵＲＬは複数のサービス名を含む複合サービス名を含むことができる）。例えば、サービス名がＡＤＣ１．ＡＤＣ２．ＡＤＣ３．ｓｅｒｖｉｃｅ４である場合、コマンドパケットはアプリケーション配信コントローラの各レベル間で転送されてもよく、ストリップ処理が可能とされる場合、サービス名は各時点で取り除かれる。例えば、６０２におけるアプリケーション配信コントローラ１はサービス名からＡＤＣ１を取り除き、６０４におけるアプリケーション配信コントローラ２はサービス名からＡＤＣ２を取り除き、６０６におけるアプリケーション配信コントローラ３はＡＤＣ３を取り除いてもよい。最終的に、コマンドパケットが６０６におけるアプリケーション配信コントローラ３に到達するためにカスケード化されたアプリケーション配信コントローラの各レベルを介し浸透する時点まで、サービス名は単にサービス４であってもよい。

図６Ｂにおいて、ブロック図６００ｂは、ここに説明された技術のいくつかの実現形態によるパラレルな複数のアプリケーション配信コントローラの実現形態を示す。図６００ｂの実現形態は、高い可用性、災害復元配置及びロードバランシングに特に有用である。例えば、パラレルな複数のアプリケーション配信コントローラは、故障又は高いシステム需要がある具体例に対してより良好な冗長性を提供する。ブロック図６００ｂにおいて、アプリケーション配信コントローラ６５２及び６５４は同じレベルの階層にある。アプリケーション配信コントローラ６５２及び６５４は、２つのクライアントがロードバランシングを提供し、故障の場合には重複するパスを提供するため、同じ名前を有するが、異なるＩＰアドレスを有するアプリケーション配信コントローラに直面することを表しうる。ＩＰアドレス１におけるアプリケーション配信コントローラ６５２は、６６２においてサービス１に、６６４においてサービス２に、及び／又は６６６においてサービス３にルーティングしてもよく、ＩＰアドレス２におけるアプリケーション配信コントローラ６５４は、実現形態に依存して６６６においてサービス３又は他のサービスにルーティングしてもよい。図６Ｂの具体例では、サービスリクエストは、ＡＤＣ１．ｓｅｒｖｉｃｅ３のサービス名を有してもよい。“ｐａｓｓ２”によって示されるように、コマンドパケットがアプリケーション配信コントローラ６５２から６６６におけるサービス３に直接わたされる場合、アプリケーション配信コントローラ６５２はストリップ処理を実行してもよい。例えば、“ｐａｓｓ１”により示されるように、コマンドパケットがアプリケーション配信コントローラ６５２からアプリケーション配信コントローラ６５４及びその後に６６６におけるサービス３にわたされる場合、アプリケーション配信コントローラ６５２はストリップ処理を実行せず、アプリケーション配信コントローラ６５４がストリップ処理を実行する。アプリケーション配信コントローラ６５２が接続故障のために６６６におけるサービス３にアクセスできない具体例では、アプリケーション配信コントローラ６５２は、アプリケーション配信コントローラ６５４を介し６６６におけるサービス３と通信するか、あるいは、クライアントデバイスにアプリケーション配信コントローラ６５４にリダイレクトするよう依頼してもよい。

図７は、ここに説明される技術のいくつかの実現形態によるリクエストされたサービスのクライアントデバイスからのアクセスを認証する一例となる方法７００のフローチャートを示す。７０２において、アプリケーション配信コントローラ１２０は、クライアントデバイスによるトークンを有効にするか、あるいは、トークンが必要とされるが（例えば、ルーティング又はサービステーブルに示されるように）、クライアントデバイス上に存在しない場合、トークンを割当て及び有効にしてもよい。いくつかのサービス（又はメソッド）はセキュリティ目的のためトークンを必要とするが、他のサービスは実行のためにトークンを必要としないかもしれない（例えば、セキュリティが重要でないサービス、エマージェンシサービスなど）。従って、アプリケーション配信コントローラ１２０は、トークンが必要とされるか、トークンがクライアントデバイス上に存在するか、及びトークンが有効であるか判断してもよい。クライアントデバイス上にトークンが存在しない場合、アプリケーション配信コントローラ１２０は、トークンをクライアントデバイスに割当て、当該トークンを有効にするよう認証モジュール１２６と連携してもよい。トークンの有効化又は割当て及び有効化は、特に図８Ａ及び８Ｂを参照して、ここで何れかにおいて更に詳細に説明される。

７０４において、アプリケーション配信コントローラ１２０は、ユーザの役割に基づきクライアントデバイスによるユーザアクセスを提供してもよい。いくつかの実現形態では、ユーザの役割はホワイトリストを用いて規定されてもよい。ホワイトリストは、役割ベースのアクセスのためのＡＰＩレベル及び各サービスにおいて定義されるコンマで分離された役割のリストであってもよい（例えば、これらリスとされた役割又はユーザにはこれらのサービス又はメソッドへのアクセスが提供される）。ホワイトリストは、特定のサービスがシステムのセキュリティを拡張するために特定の役割のセットにアクセス可能であることを保証する。誰もアクセスが許可されていないサービスがあってもよい。同様に、全てがアクセスすることが許可されているサービスがあってもよい（例えば、ＴＯＫＥＮＮＥＥＤＥＤ３１６フィールドの値が０に設定されることにより示されるように）。

図３Ａ及び３Ｂを参照して説明されるように、ホワイトリストはルーティングテーブル及びサービステーブルの双方のレベルにおいて存在してもよい。サービステーブルレベルにおけるホワイトリスト（例えば、ＡＰＩ又はメソッドレベルのための）は、ルーティングテーブルレベルにおけるホワイトリストより詳細なユーザアクセスに対する制御を提供する。例えば、サービステーブルレベルのホワイトリストは、サービステーブルにおいて規定される特定のメソッド又はＡＰＩへのユーザアクセスに対する詳細な制御を提供するため、ルーティングテーブルレベルのホワイトリストを無効にしてもよい。

７０６において、アプリケーション配信コントローラ１２０はリクエストされたサービスのセキュリティゾーンを決定してもよく、７０８において、アプリケーション配信コントローラ１２０はリクエストされたサービスのセキュリティゾーンに基づき１つ以上のシグネチャを解読及び有効にしてもよく、１つ以上のシグネチャはセキュリティゾーンに基づく順序により有効にされる。いくつかの実現形態では、アプリケーション配信コントローラ１２０は、各セキュリティゾーンがセキュリティが増加した階層を含む複数のセキュリティゾーンを提供する。例えば、いくつかのセキュリティレベルは極めて計算量が高いため、低いセキュリティアイテム又はサービスが、より高いセキュリティアイテム又はサービスと同程度に高い暗号化レベルを求めない。より高いセキュリティへのアクセス（例えば、役割に基づく）を有する人数が、より低いセキュリティへのアクセスを有する人数よりはるかに少ないため、最も高いレベルのセキュリティに対するアクセスリクエストの数は、より低いレベルのセキュリティに対するものよりはるかに少なくなる。例えば、より低い階層のセキュリティはＳＨＡ２５６（ＳＨＡは当該分野において知られるセキュアなハッシュアルゴリズムである）ベースのシグネチャを利用しうるが、より高いセキュリティ階層は、２０４２ビットＲＳＡ（ＲＳＡはメッセージを暗号化及び解読するため当該分野において知られるアルゴリズムである）に類似したセキュリティレベルであり得るシグネチャ方式に結合されるＳＨＡ５１２を利用してもよい。

いくつかの実現形態では、アプリケーション配信コントローラ１２０及び認証モジュール１２６のみに知られる乱数を利用してセキュリティが強化される。例えば、サービスリクエスト又はサービスルーティングとは別に、アプリケーション配信コントローラ１２０及び認証モジュール１２６は乱数をやりとりしてもよい。乱数があるため、より弱い暗号化が十分なデータセキュリティを維持しながら利用される計算リソースを減少させるのに利用されてもよい。乱数は図１０を参照して更に詳細に説明される。

いくつかの実現形態では、各サービスはルーティング及び／又はサービステーブルにおけるセキュリティゾーンに基づき分類されてもよい。各セキュリティゾーンは、複雑さ及びセキュリティ強度の増加順にシグネチャのための異なる解読方式を有してもよい。例えば、セキュリティゾーン１は、アクセスが付与される前に、第１のシグネチャが解読及び検証される必要がありうる。セキュリティゾーン２は、アクセスが付与される前に、第１のシグネチャが解読及び検証され、その後に第２のより高いセキュリティレベルのシグネチャが解読及び検証される必要がありうる。セキュリティゾーン３は、アクセスが付与される前に、第１及び第２のシグネチャと共に、更により高いセキュリティレベルのシグネチャが解読及び検証される必要がありうる。例えば、各シグネチャは、第１のシグネチャについてＳＨＡ２５６、第２のシグネチャについてＳＨＡ５１２及び第３のシグネチャについてＲＳＡなどの増加するセキュリティレベルを有してもよい。

セキュリティゾーンの解読が処理される方法は、より高いセキュリティゾーンにおいてより高いセキュリティのシグネチャを解読するのに利用される多くの計算リソースのため効率的である必要がある。いくつかの実現形態では、アプリケーション配信コントローラ１２０は、より高いレベルのより多くのリソースが必要なシグネチャに進む前に、より低いレベルのより少ないリソースで済むシグネチャを解読及び検証してもよい。パイプラインにおいて何れかのシグネチャが不調である場合、解読はより高いセキュリティのシグネチャが検証される前に中止され、このため、使用される計算リソースは攻撃について減少し、サービス及び／又はデータへのアクセスのため真正な認証について依然として利用可能である。

図８Ａ及び８Ｂは、ここに説明される技術のいくつかの実現形態によるクライアントデバイスからのトークンを検証するか、あるいは、トークンが必要とされるが、クライアントデバイス上に存在しない場合にトークンを割当て及び検証するための一例となるワークフロー８００ａ、８００ｂのフローチャートを示す。８０２において、アプリケーション配信コントローラ１２０は、サービス１によるＵＲＬを受信する。例えば、アプリケーション配信コントローラ１２０は、リクエストされたサービス１を示すＵＲＬによる、又は形式によるサービスリクエストを受信してもよい。

８０４において、アプリケーション配信コントローラ１２０は、トークンが必要とされるか判断する（例えば、上述されたようにルーティング又はサービステーブルを利用して）。アプリケーション配信コントローラ１２０がトークンが必要ないと判断した場合、８０６において、サービスが実行及び／又はクライアントデバイスにルーティングされる。いくつかのサービスは秘匿性のある情報へのアクセスを有さず、従って、トークンは必要とされず、効率性の目的のため、トークンの割当て及び検証がバイパスされる。

いくつかの実現形態では、アプリケーション配信コントローラ１２０は、リクエストされたサービスがエマージェンシサービスであることに基づきトークンが不要である（あるいは、例えば、ここの何れかに説明されるトリアージと同様に、サービスがエマージェンシにおいてリクエストされている）と判断してもよい。例えば、アプリケーション配信コントローラ１２０は、認証のための処理用のノーマルパイプラインをバイパスすることによって危機におけるサービスを処理し、サービスのシームレスで瞬時なルーティングを提供するよう構成されてもよい。例えば、エマージェンシサービスは、トークンが必要とならないようにマーク付けされてもよい（例えば、エマージェンシサービスのためのルーティングテーブル３００ａ又はサービステーブル３００ｂにおけるＴＯＫＥＮＮＥＥＤＥＤフィールド３１６又は３６０が０に設定された値を有する）。

一例では、図９は、ここに説明された技術のいくつかの実現形態によるアプリケーション配信コントローラ１２０を介しエマージェンシサービスを提供するための値を示す一例となるルーティングテーブル９００を示す。図９において、９０２におけるカラム８は、ロー９０４におけるサービス“ｅｑｓ１”が、トークンがサービスにアクセスするのに必要とされることを示すＴＯＫＥＮＮＥＥＤＥＤフィールドにおける１の値を有することを示す。さらに、サービス“ｅｑｓ１”は、デフォルトによって医師、看護師又は転記者の役割のユーザによってアクセスされうる。しかしながら、９０２におけるカラム８は、ロー９０６におけるサービス“ｅｍｅｒｇｅｎｃｙｅｑｓ１”がＴＯＫＥＮＮＥＥＤＥＤフィールドにおいて０の値を有することを示し、このため、トークンは必要とされず、認証手順がバイパス可能である。従って、同じＡＰＩが双方のサービスに利用されてもよいが、エマージェンシケースと非エマージェンシケースとの双方を提供するために異なるサービス名にマッピングされてもよい。

図８Ａに戻って、８０８において、アプリケーション配信コントローラ１２０は接続をクローズしてもよい（例えば、上述されるようにソケットハンドリングに基づく）。

アプリケーション配信コントローラ１２０が、トークンが８０４において必要とされると判断した場合、８１０において、アプリケーション配信コントローラ１２０は、トークンがクライアントデバイス上のｃｏｏｋｉｅに存在するか判断してもよい。例えば、アプリケーション配信コントローラ１２０は、認証サーバによってクライアントデバイス上に格納されるｃｏｏｋｉｅにおけるサービスのためのトークンが存在するか判断するため、クライアントデバイスをクエリしてもよい。

アプリケーション配信コントローラ１２０が、８１０において、トークンがｃｏｏｋｉｅに存在すると判断した場合、８１２において、アプリケーション配信コントローラ１２０は、トークン、役割及びセキュリティゾーンが有効であるか判断してもよい。アプリケーション配信コントローラ１２０は、ユーザの証明書（例えば、証明書はトークンの一部であってもよい）と共にｃｏｏｋｉｅを検証し、トークンが有効であり、ユーザが自身が主張している人であると検証してもよい。

いくつかの実現形態では、アプリケーション配信コントローラ１２０がｃｏｏｋｉｅにおいてトークンを受信すると、ｃｏｏｋｉｅはキーワード（例えば、“トークン”）の有無について解析される。キーワードは、証明書、シークレットインデックス及び／又はシグネチャの始めを示すものであってもよい。シークレットインデックス（例えば、それぞれが乱数を表す８つの８ビットのランダムインデックス）は、例えば、上述されたように、アプリケーション配信コントローラ１２０及び認証サーバ１２６に知られている乱数を表すものであってもよい。シークレットナンバーは、例えば、アプリケーション配信コントローラ１２０のスタートアップ中に別々の双方向のＴＬＳセッションを用いて、アプリケーション配信コントローラ１２０と認証サーバ１２６との間でやりとりされてもよい。シグネチャは、例えば、ＳＨＡ１など、上述されたような各種メソッドを用いて暗号化されてもよい。

図１０は、ｃｏｏｋｉｅに存在するデータの具体例を示す。例えば、図１０は、ここに説明される技術のいくつかの実現形態による一例となる符号化されたユーザ証明書１００２及びシグネチャ１００４によるテーブル１０００を示す。図示されるように、証明書は、復号化されたとき、

のようになるベース６４符号化を用いて符号化されてもよい。図示されるように、トークン内の各フィールドはフィールド名、“＝”記号及びフィールドのエンドをマーク付けし、フィールドを区別するセミコロンからスタートしてもよい。例えば、トークンの構成は、フィールドのＳＨＡ１（又は他の形態の暗号化）であってもよいシグネチャによって付加されたユーザ名、ユーザの役割、ｃｏｏｋｉｅの期限及び８つの乱数のインデックスを含んでもよく、いくつかの具体例では、乱数はペイロードの一部としてインデックスを構成する。

いくつかの実現形態では、アプリケーション配信コントローラ１２０は、復号化された証明書が改ざんされていないことを証明する。アプリケーション配信コントローラ１２０は、ｃｏｏｋｉｅに存在するインデックスに対応するシークレットナンバーを取得し、実際のシークレット乱数と共にユーザ証明書全体に対してＳＨＡを実行することによって、トークンの完全性を検証し、入力されたシグネチャを比較してもよい。

さらに、アプリケーション配信コントローラ１２０は、証明書に含まれる役割がルーティング及び／又はサービステーブルにリストされた役割と一致しているか検証してもよい。

図８Ａに戻って、アプリケーション配信コントローラ１２０が、８１２において、トークン、役割及びゾーンが有効であると判断した場合、８１４において、サービスは、トークンがタイムアウトしたか判断するためチェックしてもよい。トークンがタイムアウトしていない場合、８０６において、サービスが実行及び／又はルーティングされてもよい。アプリケーション配信コントローラ１２０が、トークン、役割又はゾーンが無効であると判断した場合、８０８において、接続はクローズされるか、あるいは、クライアントデバイスは有効なｃｏｏｋｉｅ及びトークンを受信するため（図示せず）、認証サーバ１２６にリダイレクトされてもよい。

８１０において、アプリケーション配信コントローラ１２０が、ｃｏｏｋｉｅにトークンがないと判断した場合、アプリケーション配信コントローラ１２０は、８１６において、ＵＲＬを用いて現在のドメイン及びＵＲＬによってｃｏｏｋｉｅを設定してもよい。サービスリクエストが認証サーバ１２６からトークンを受信する処理を介して実行されるため、アプリケーション配信コントローラ１２０は、現在のドメイン及び現在のＵＲＬ（例えば、サービス名、ＡＰＩなどを含んでもよい）によりｃｏｏｋｉｅを設定してもよい。現在のドメイン及びＵＲＬによるｃｏｏｋｉｅは、アプリケーション配信コントローラ１２０が、トークンが有効にされると、何れかのサービス、ＡＰＩ又はメソッドをクライアントが最初にリクエストしたか知ることを可能にする。いくつかの実現形態では、ｃｏｏｋｉｅは以下のように設定されてもよい。

例えば、トークンが期待されるが、欠落しているケースでは、アプリケーション配信コントローラ１２０は、ＵＲＬｃｏｏｋｉｅを設定し、クライアントデバイスがトークンを受信できるように、クライアントデバイスを認証サーバ１２６にリダイレクトしてもよい。いくつかの実現形態では、処理フロー全体がクライアントに不透明であることに留意すべきである。例えば、全てのリダイレクションはアプリケーション配信コントローラ１２０によって内部的に処理される。ユーザの体感は、トークンが取得及び有効にされると、リクエストされたサービスへのアクセスが、ユーザがサービスリクエストを再入力／再リクエストする必要なく可能とされるようになる。

８１８において、ｃｏｏｋｉｅが設定されると、アプリケーション配信コントローラ１２０は、トークンを取得するため、サービスのユーザのクライアントデバイスの認証モジュール１２６（例えば、アプリケーション配信コントローラ１２０から分離された又は統合された認証モジュール１２６）にクライアントをリダイレクトしてもよい。例えば、認証モジュール１２６は、トークンを生成し、ＵＲＬ及び／又はＵＲＬ ｃｏｏｋｉｅの一部としてトークンを設定し、特定のサービスリクエストによってアプリケーション配信コントローラ１２０を呼び出してもよい（例えば、サービスリクエストのサービス名は、以下で更に詳細に説明されるように、トークンハンドラであってもよい）。

いくつかの実現形態では、アプリケーション配信コントローラ１２０は、特定のサービスリクエスト（例えば、サービス“トークンハンドラ”について）を受信してもよい。特定のサービスリクエストは、アプリケーション配信コントローラ１２０及び認証モジュール１２６に知られているサービスに対するものであってもよく、ルーティング又はサービステーブルにおいて規定されてもよい。

８２０において、アプリケーション配信コントローラ１２０は、ホストを決定してもよい。例えば、アプリケーション配信コントローラ１２０が特定のサービスリクエストを受信すると、アプリケーション配信コントローラ１２０は、呼び出しが認証モジュール１２６からであり、ＵＲＬの一部としてアプリケーション配信コントローラ１２０にトークンが提示されていると判断する。

８２２において、アプリケーション配信コントローラ１２０は、設定されたＵＲＬ ｃｏｏｋｉｅからサービス１によりＵＲＬを取得し、８２４において、アプリケーション配信コントローラ１２０は、設定されたＵＲＬ ｃｏｏｋｉｅを削除してもよい。いくつかの実現形態では、初期的なＵＲＬ（例えば、クライアントデバイスがサービスについて元々リクエストした）が抽出されると、アプリケーション配信コントローラ１２０は、ＵＲＬを再解析し、ＵＲＬからトークンを抽出し、ＵＲＬ ｃｏｏｋｉｅがもはや必要でないため、ＵＲＬ ｃｏｏｋｉｅを削除又はアンセットしてもよい。

８２６において、アプリケーション配信コントローラ１２０は、トークンの現在時間がトークン付与時間に基づき有効であるかチェックし、８２８において、アプリケーション配信コントローラ１２０は、トークンを有効にしてもよい（例えば、ここでの何れかに説明されるように）。例えば、トークンが抽出されると、アプリケーション配信コントローラ１２０は、トークンを有効にし、現在時間がトークン付与時間の許容リミットの範囲内であるかチェックする。タイムリミットが満了している場合、アプリケーション配信コントローラ１２０は、有効なトークンを受信するため、クライアントデバイスを認証モジュール１２６にリダイレクトしてもよい。

８３０において、アプリケーション配信コントローラ１２０は、ＵＲＬを用いてトークンｃｏｏｋｉｅを設定し、８３２において、アプリケーション配信コントローラ１２０は、トークンの検証のためアプリケーション配信コントローラ１２０にクライアントデバイスをリダイレクトしてもよい（例えば、ワークフロー８００ａにおける８０２へ）。例えば、８２６において、現在の時間がリミット内にある場合、アプリケーション配信コントローラ１２０は、トークンｃｏｏｋｉｅを設定し、ＵＲＬ ｃｏｏｋｉｅからのパスを入力リクエストとして利用して、自ら（アプリケーション配信コントローラ１２０）への自己リダイレクトをポストしてもよい。例えば、自己リダイレクトは、基本的にはユーザのサービスリクエストをアプリケーション配信コントローラ１２０に再規定するが、ここで、トークンはトークンｃｏｏｋｉｅに設定されており、アプリケーション配信コントローラ１２０は、リクエストされたサービスへのアクセスを許可する前に、トークン及びユーザ証明書を有効にするよう進捗することができる（例えば、８０２〜８１４を参照して説明されるように）。
上記の実現形態の説明は、図示及び説明の目的のために提示された。本実現形態を開示された正確な形態に限定し、あるいは、包括的であることは意図していない。多くの修正及び変形が上記教示に基づき可能である。本実現形態の範囲はこの詳細な説明でなく、本出願の請求項によって限定されることが意図される。当業者によって理解されるように、本実現形態はそれの精神又は必須の特性から逸脱することなく他の具体的な形態をとりうる。同様に、モジュール、ルーチン、特徴、属性、方法及び他の態様の特定の名称及び分割は必須又は重要でなく、一実現形態又はそれの特徴を実現する機構は異なる名前、分割及び／又はフォーマットを有してもよい。さらに、明らかであるように、実現形態のモジュール、ルーチン、特徴、属性、方法及び他の態様は、ソフトウェア、ハードウェア、ファームウェア又はこれら３つの何れかの組み合わせとして実現可能である。また、その具体例がモジュールであるコンポーネントがソフトウェアとして実現される場合、コンポーネントは、スタンドアローンプログラムとして、より大きなプログラムの一部として、複数の個別のプログラムとして、静的若しくは動的にリンクされたライブラリとして、カーネルがロード可能なモジュールとして、デバイスドライバとして、及び／又は現在若しくは将来に知られる全て及び他の何れかの方法において実現可能である。さらに、実現形態は、何れか特定のプログラミング言語による実現形態又は何れか特定のオペレーティングシステム若しくは環境に限定されない。従って、開示は限定的でなく例示的であると意図され、その範囲は以下の請求項において与えられる。

Claims (20)

1. コンピュータにより実現される方法であって、
   計算デバイスが、クライアントデバイスからサービスリクエストを受信するステップと、
   前記計算デバイスが、前記サービスリクエストに基づきルーティングパラメータを決定するステップと、
   前記計算デバイスが、リクエストされたサービス、前記リクエストされたサービスのセキュリティゾーン及びトークンに基づき、前記クライアントデバイスによるアクセスを認証するステップと、
   前記計算デバイスが、前記ルーティングパラメータと前記認証されたアクセスとに基づき、前記リクエストされたサービスを前記クライアントデバイスにルーティングするステップと、
   を有する方法。
2. 前記ルーティングパラメータを決定するステップは、前記計算デバイスが、前記リクエストされたサービスのカテゴリに基づきソケットハンドリングを決定するステップを含み、
   前記リクエストされたサービスを前記クライアントデバイスにルーティングするステップは、前記サービスリクエストのＵＲＬと前記クライアントデバイスのユーザの役割とに更に基づき、
   前記認証されたアクセスは、ディレクトリとファイルとの１つ以上へのアクセスを含む、請求項１記載の方法。
3. 前記クライアントデバイスによるアクセスを認証するステップは、前記トークンが前記リクエストされたサービスに対して必要とされ、前記トークンが前記クライアントデバイス上に存在しないと判定したことに応答して、前記トークンを前記クライアントデバイスに割り当てるステップを含む、請求項１記載の方法。
4. 前記クライアントデバイスによるアクセスを認証するステップは、前記リクエストされたサービスのセキュリティゾーンを決定するステップを含む、請求項１記載の方法。
5. 前記クライアントデバイスによるアクセスを認証するステップは、前記計算デバイスが、前記クライアントデバイスに割り当てられたシグネチャを検証するステップを含み、前記シグネチャは前記リクエストされたサービスのセキュリティゾーンとシークレットナンバーとに基づき、前記シークレットナンバーは前記計算デバイスと認証サービスとの間の別の通信においてやりとりされる、請求項４記載の方法。
6. 前記クライアントデバイスによるアクセスを認証するステップは、
   前記計算デバイスが、前記リクエストされたサービスがエマージェンシサービスであるか判断するステップと、
   前記計算デバイスが、前記リクエストされたサービスが前記エマージェンシサービスであると判断したことに基づき、前記クライアントデバイスによる前記リクエストされたサービスへのアクセスを認証するステップと、
   を含む、請求項１記載の方法。
7. 前記クライアントデバイスによるアクセスを認証するステップは、前記トークンが前記トークンの付与時間に基づき有効であるか判断するステップを含む、請求項１記載の方法。
8. １つ以上のプロセッサと、
   命令を格納するメモリと、
   を有するシステムであって、
   前記命令は、前記１つ以上のプロセッサによって実行されると、
   クライアントデバイスからサービスリクエストを受信するステップと、
   前記サービスリクエストのリクエストされたサービスに基づきルーティングパラメータを決定するステップと、
   前記リクエストされたサービス、前記リクエストされたサービスのセキュリティゾーン及びトークンに基づき、前記クライアントデバイスによるアクセスを認証するステップと、
   前記ルーティングパラメータと前記認証されたアクセスとに基づき、前記リクエストされたサービスを前記クライアントデバイスにルーティングするステップと、
   を前記システムに実行させるシステム。
9. 前記ルーティングパラメータを決定するステップは、前記リクエストされたサービスのカテゴリに基づきソケットハンドリングを決定するステップを含み、
   前記リクエストされたサービスを前記クライアントデバイスにルーティングするステップは、前記サービスリクエストのＵＲＬと前記クライアントデバイスのユーザの役割とに更に基づき、
   前記認証されたアクセスは、ディレクトリとファイルとの１つ以上へのアクセスを含む、請求項８記載のシステム。
10. 前記クライアントデバイスによるアクセスを認証するステップは、前記トークンが前記リクエストされたサービスに対して必要とされ、前記トークンが前記クライアントデバイス上に存在しないと判定したことに応答して、前記トークンを前記クライアントデバイスに割り当てるステップを含む、請求項８記載のシステム。
11. 前記クライアントデバイスによるアクセスを認証するステップは、前記リクエストされたサービスのセキュリティゾーンを決定するステップを含む、請求項８記載のシステム。
12. 前記クライアントデバイスによるアクセスを認証するステップは、前記クライアントデバイスに割り当てられたシグネチャを検証するステップを含み、前記シグネチャは前記リクエストされたサービスのセキュリティゾーンとシークレットナンバーとに基づき、前記シークレットナンバーは当該システムと認証サービスとの間の別の通信においてやりとりされる、請求項１１記載のシステム。
13. 前記クライアントデバイスによるアクセスを認証するステップは、
    前記リクエストされたサービスがエマージェンシサービスであるか判断するステップと、
    前記リクエストされたサービスが前記エマージェンシサービスであると判断したことに基づき、前記クライアントデバイスによる前記リクエストされたサービスへのアクセスを認証するステップと、
    を含む、請求項８記載のシステム。
14. 前記クライアントデバイスによるアクセスを認証するステップは、前記トークンが前記トークンの付与時間に基づき有効であるか判断するステップを含む、請求項８記載のシステム。
15. クライアントデバイスからサービスリクエストを受信するステップと、
    前記サービスリクエストのリクエストされたサービスに基づきルーティングパラメータを決定するステップと、
    前記リクエストされたサービス、前記リクエストされたサービスのセキュリティゾーン及びトークンに基づき、前記クライアントデバイスによるアクセスを認証するステップと、
    前記ルーティングパラメータと前記認証されたアクセスとに基づき、前記リクエストされたサービスを前記クライアントデバイスにルーティングするステップと、
    をコンピュータに実行させるプログラム。
16. 前記ルーティングパラメータを決定するステップは、前記リクエストされたサービスのカテゴリに基づきソケットハンドリングを決定するステップを含み、
    前記リクエストされたサービスを前記クライアントデバイスにルーティングするステップは、前記サービスリクエストのＵＲＬと前記クライアントデバイスのユーザの役割とに更に基づき、
    前記認証されたアクセスは、ディレクトリとファイルとの１つ以上へのアクセスを含む、請求項１５記載のプログラム。
17. 前記クライアントデバイスによるアクセスを認証するステップは、前記トークンが前記リクエストされたサービスに対して必要とされ、前記トークンが前記クライアントデバイス上に存在しないと判定したことに応答して、前記トークンを前記クライアントデバイスに割り当てるステップを含む、請求項１５記載のプログラム。
18. 前記クライアントデバイスによるアクセスを認証するステップは、前記リクエストされたサービスのセキュリティゾーンを決定するステップを含む、請求項１５記載のプログラム。
19. 前記クライアントデバイスによるアクセスを認証するステップは、前記クライアントデバイスに割り当てられたシグネチャを検証するステップを含み、前記シグネチャは前記リクエストされたサービスのセキュリティゾーンとシークレットナンバーとに基づき、前記シークレットナンバーは当該コンピュータと認証サービスとの間の別の通信においてやりとりされる、請求項１８記載のプログラム。
20. 前記クライアントデバイスによるアクセスを認証するステップは、前記トークンが前記トークンの付与時間に基づき有効であるか判断するステップを含む、請求項１５記載のプログラム。

Images