(57)【要約】  通知の安全な処理を検証及び／又は保証するための方法及び装置を提供する。一実施形態では、この方法は、通知を受信するステップと、通知受領ポリシーに従って通知を処理するよう静的に検証された通知ハンドラを有するプログラムコードを使用して通知を安全に処理するステップと、を含む。【選択図】  図１
2009516887.tif 000002
【特許請求の範囲】
【請求項１】
通知を受信するステップと、
通知受領ポリシーに従って前記通知を処理するように静的に検証された通知ハンドラを有するプログラムコードを使用して、前記通知を安全に処理するステップと、
を含む方法。
【請求項２】
命令を格納する一以上のコンピュータ可読記憶媒体を有する製品であって、前記命令は、システムによる実行時に、該システムに、
通知を受信するステップと、
通知受領ポリシーに従って前記通知を処理するよう静的に検証された通知ハンドラを有するプログラムコードを使用して、前記通知を安全に処理するステップと、
を含む方法を実行させる、製品。
【請求項３】
通知を処理するプログラムコードに対する静的な検証を実行するステップであって、前記静的な検証が通知受領ポリシーに従って実行される、該ステップと、
通知を受信する前に、前記プログラムコードが通知を安全に処理することができないと判定された場合に、前記通知受領ポリシーに準拠するよう動的なチェックを前記プログラムコードに動的に組み込むステップと、
通知を受信するステップと、
前記通知受領ポリシーに従って前記通知を安全に処理するためのハンドラを含むプログラムを実行するステップと、
を含む方法。
【発明の詳細な説明】
【関連出願】
【０００１】
[0001]本願は、２００５年１１月２１日に出願された「Ａ  Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｖｅｒｉｆｙｉｎｇ  ａｎｄ  Ｅｎｓｕｒｉｎｇ  Ｓａｆｅ  Ｈａｎｄｌｉｎｇ  ｏｆ  Ｎｏｔｉｆｉｃａｔｉｏｎｓ」と題する米国特許仮出願第６０／７３９０７６号の利点を主張するものであり、当該仮出願を参照することによって援用する。
【発明の分野】
【０００２】
[0002]本発明はコンピュータプログラムの実行の分野に関するものであり、より具体的には、本発明はコンピュータプログラムによる通知の安全な処理に関するものである。
【発明の背景】
【０００３】
[0003]通知は、ネットワークシステム又は分散システムにおいて他のプログラムと通信するプログラムの基本機能である。プログラムの状態の変化を伝達するために、サーバクライアントプログラムの初期接続を確立するために、又は、その他の種類の非同期通信のために、通知は不可欠である。通知の一つの特徴は、当該通知がプログラムによって自ら開始され得ることである。
【０００４】
[0004]通知のサポートは、オペレーティングシステムのネットワークプロトコルスタックからアプリケーションプログラムまで幅広くプログラム内に現れる。インターネット用の基本的プロトコルの一つであるＴＣＰ／ＩＰは、この機能を有して、ネットワークに接続されたデバイス間の通信を可能にしている。アプリケーションレベルでは、例えば、インスタントメッセージ（ＩＭ）及び電子メール等の多くの事例が存在する。ＩＭプロトコルは、ユーザの利用可能性についての通知を、その他の興味を持ったユーザ又は「登録した（subscribed）」ユーザのＩＭクライアントに送信することが必要である。電子メールもアプリケーション特有の通知とみなすことができる。即ち、特定の受信者に向けられた電子メールは、電子メールサーバによって、その受信者にのみ送信される。
【０００５】
[0005]移動体通信では、アプリケーションは、真の分散アプリケーション及びクライアント−サーバアプリケーションを可能とするために、通知を受領する能力をサポートする必要がある。この場合に、アプリケーションは、その受信が望まれている通知を失わないことが重要であり、また、ネットワーク化システム内のその他のエンティティからの通知であってその受信が望まれない通知によって、当該アプリケーションが溢れることを防ぐことが重要である。
【０００６】
[0006]通知プロトコルの成功には、適切に動作し、且つ、プロトコルの規則に従うよう通信プログラム間の取り決めが必要である。これらの規則が、参加しているプログラムのうちの何れかによって破られると、様々な攻撃（サービス妨害、スパムなど）が生じ得る。なお、通常は、電子メールリーダ又はＩＭクライアント等のクライアントコードは信頼されており、通知を適切に処理するものと仮定されている。一部のサーバが、利己的で収益本意の理由をもって通知を送信し、また、適正なソフトウェアを記述する複雑性を有するものとすると、この仮定は不確かなものとなる。
【０００７】
[0007]典型的なサービス妨害攻撃は、クライアントでの計算処理が要求していない通知を処理するために割かれ、リソースをクライアント上のその他のプログラムから逸らすことから生じ得る。この攻撃の例は、ＴＣＰプロトコル上のＳＹＮフラッド攻撃であり、当該攻撃によって、サーバは、攻撃者が作成した偽のクライアントのためにメモリ内に状態を蓄えることを強いられ、このようにしてサーバ上のサービス妨害が引き起こされる。アプリケーションレベルでは、サービス妨害攻撃は、当該攻撃が各通知に対してユーザの入力を要求することができるので、より悪質となり得る。望まない通知によってユーザを溢れさせることによって、本質的にそれらユーザの計算デバイスが役に立たなくなる。幾つかのウィルス、スパムエンジン、並びに、悪意のあるスクリプト及びアプレットは、このようなサービス妨害攻撃を使用して、エンドユーザを徹底的に妨害する。サービス妨害攻撃には、二つの本質的な要素、即ち、第１に膨大な通知を送信すること、第２にこれら通知が、クライアントが感心のある通知でないこと、が存在する。
【０００８】
[0008]一部のスクリプト言語は通知を受領する能力を提供しておらず、したがって全ての恩恵を放棄することによって問題を解決している。通知は、通信プログラムを用いる一部のシステムの不可欠で有用な要素とみなされるので、明らかにこれは受け入れられる解決策ではない。
【０００９】
[0009]セッション認証を使用すること、及び、サーバから送信される通知を暗号化することによって、信頼できる関係者によって作り出されたクライアントコードにより通知が処理されることを保証することができる。このアプローチの欠点は、信頼できるパーティによって作り出されたコードが、その検証可能な証明が無くとも、通知を安全に処理することを仮定しているということである。
【００１０】
[0010]型付きの環境は、アプリケーションロジックを型付きイベントとマッチングするものであり、開発者がイベント処理の単純ミスを防ぐのに役立つ。しかしながら、このような技術は型のマッチング以上のことは見ず、クライアントコードの振る舞い、特にどのような条件下でそのクライアントコードが通知を処理するのかを無視する。さらに、これらの技術は、安全でないクライアントコードを計測するためのいかなる機能も提供しない。
【００１１】
[0011]ビジネスプロセス実行言語（ＢＰＥＬ）は、ウェブサービスを構成するためのＸＭＬベースのメタプログラミング言語を定義する。ＢＰＥＬは、カリフォルニア州Ｓａｎ  ＪｏｓｅのＢＥＡ  Ｓｙｓｔｅｍｓ、ＮＹ州ＰｏｕｇｈｋｅｅｐｓｉｅのＩＢＭ、及びワシントン州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎの開発者によって書かれたものである。ＢＰＥＬのための実行エンジンも提供されている。プログラミング言語として、ＢＰＥＬは、手続き型プログラミング機能とイベント駆動型プログラミング機能の双方を提供する。したがって、サーバによって提供されるサービスがウェブサービスとして利用可能である場合には、サーバインスタンスをＢＰＥＬによって構成することができる。ＢＰＥＬは、ウェブサービス用の拡張仕様を提供しているが、通知の安全な処理を保証するための如何なる方法も提供していない。
【発明の概要】
【００１２】
[0012]通知の安全な処理を検証及び／又は保証するための方法及び装置を提供する。一実施形態において、この方法は、通知を受信するステップと、通知受領ポリシーに従って通知を処理するよう静的に検証された通知ハンドラを有するプログラムコードを使用して通知を安全に処理するステップと、を含む。
【００１３】
[0013]本発明は、以下の詳細な説明及び本発明の種々の実施形態に関する添付の図面から、より完全に理解されるであろう。しかしながら、これらの詳細な説明及び図面は本発明を特定の実施形態に限定するものと解釈されるべきではなく、説明及び理解のみを目的としている。
【本発明の詳細な説明】
【００１４】
[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]通知は通知型（notification type）に属するものである。一実施形態では、通知型の仕様は、関数部については代数的性質を有し、データ部については抽象データ型の性質を有する。一実施形態では、通知の仕様は、以下のもの、即ち、型の名前と、この型の通知に対して機能することができる関数の集合と、通知型に属する基本通知オブジェクトの集合と、この型の通知についての推論を行うために使用し得る公理の集合とを含む。一実施形態では、型の名前は、型が処理されている名前空間内の一意的なＩＤである。一意的な名前を実施するための様々な実装方法を、ここでは使用することができる。
【００４６】
[0055]一実施形態では、この型の通知に対して機能することができる関数の集合だけが、この型の通知に対して機能することができる関数である。一実施形態では、これらの関数は、データコンストラクタ、計算関数、及びポリシーコンストラクタを含む。データコンストラクタは、当該データコンストラクタが一部をなす通知の型と同じ戻り型を有し、当該データコンストラクタは、この型の新しい通知を構築するために使用される。計算関数は、この型の仕様の通知をその計算関数の引数のうちの一つとして受け取る。ポリシーコンストラクタは、この型の通知の処理を制限するためにクライアントによって使用され得る述語を記述する。一実施形態では、ポリシーコンストラクタ内の述語は、通知の仕様の任意の部分を参照することができ、ブール結合子ＡＮＤ、ＯＲ、又はＮＯＴ、及び同等性の論理概念を使用することができる。一実施形態では、ポリシーコンストラクタはポリシーによって表現された意図する制限が如何なるものかについての自然言語記述も含み、この記述は後に通知コンシューマーによる検証に使用され得る。
【００４７】
＜クライアントの通知受領ポリシー（ＮＡＰ）の仕様の例＞
[0056]一実施形態では、クライアントのＮＡＰは、以下の形態をとる。
ポリシーの述語Ｐ⇔｛サーバＳ，通知型Ｎｔ，クライアントの通知ハンドラＣ｝
上記ポリシーは、ポリシーの述語Ｐが真である場合に及びその場合に限り、通知ハンドラコードＣがサーバＳから来る型Ｎｔの通知を処理することを規定している。一実施形態では、上記ＮＡＰのより緩い概念であって、（１）「の場合」、又は（２）「の場合に限る」ものへと通知を制限する概念が使用される。
（１）ポリシーの述語Ｐ→｛サーバＳ，通知の型Ｎｔ，クライアントの通知ハンドラＣ｝
（２）ポリシーの述語Ｐ←｛サーバＳ，通知の型Ｎｔ，クライアントの通知ハンドラＣ｝
【００４８】
[0057]上記矢印は、ポリシーの述語ＰがサーバＳ、通知の型Ｎｔ、及びクライアントの通知ハンドラＣを含意する（→）か、又はサーバＳ、通知の型Ｎｔ、及びクライアントの通知ハンドラＣによって含意される（←）ことを示唆することに留意されたい。一実施形態では、ポリシーの述語Ｐは、通知型Ｎｔに関する仕様において記載したポリシーコンストラクタからのみ構築され得る。
【００４９】
＜言語仕様の例＞
[0058]言語の一実施形態について、一般的技術の例及び実例であって当該言語に対して例示したものを使用して本明細書に示す。
Literal:=Var｜Const
Var:=a,b,c,...(シンボルの無限リスト)
Const:=０、１、．．．などの、言語のデータ型の仕様からの定数の集合
VarList:=Var+
LiteralList:=Literal+
Term:=Literal｜ft(LiteralList)  ここで、ｆｔは対応するデータ型の仕様における正しい引数の数（arity）をもつ関数である。
Cmd:=Var←Term
｜if BoolCond then Cmd else Cmd
｜Cmd;Cmd
｜defn f(VarList)[Cmd]
｜f(LiteralList)
｜process_notif
BoolCond:= ft(Literal)
｜BoolCond and BoolCond
｜BoolCond or BoolCond
｜not BoolCond
【００５０】
[0059]上記の定義の主なポイントは、標準的な言語定義形式に従っており、データ型の要素に対して作用することができる関数を規定するために代数的に規定されている。特殊な命令ｐｒｏｃｅｓｓ＿ｎｏｔｉｆは、着信通知が処理されるときのクライアントの通知ハンドラコード内のポイントの抽象化である。一実施形態では、上記の定義内の関数ｆｔは対応するデータ型（又は通知の型）の仕様内の任意の関数であることができ、クライアントのＮＡＰに現れる関数とは対照的にその関数に対する制限を持たない。
【００５１】
＜ポリシーの生成を検証するためのプロセスの例＞
[0060]図７は、第三者（例えば、ドメインエキスパート、ＧＵＩ駆動型プログラム等）によって生成されたクライアントＮＡＰを検証するためのコンシューマープロセスを示している。この検証は、ＮＡＰとしてインストールする前に行われる。
【００５２】
[0061]以下、図７を参照する。通知の仕様７０１を与えられると、第三者は、通知の仕様７０１内のポリシーコンストラクタを用い、様々なポリシーを、ポリシーライタ７０２を使用して生成する。中間的なＮＡＰ７０３が生成され、一実施形態では、通知の規定７０１内の利用可能なポリシーコンストラクタによって全て表される。ポリシーディスクリプタモジュール７０４は、意図するＮＡＰが何を行うかを、コンシューマーに対して記述する。一実施形態では、ポリシーディスクリプタモジュール７０４は、ポリシーディスクリプタの自然言語記述を使用して、意図するＮＡＰが何を行うかをコンシューマーに対して記述する。このように、ポリシーディスクリプタモジュール７０４は、人間が読めるポリシー７０５を生成し、出力する。人間が読めるポリシー７０５を使用して、コンシューマーは、ＮＡＰの記述を読み、このＮＡＰが望まれているＮＡＰであることを確認する。一実施形態では、全てのその他の第三者は悪意を持っている可能性があり、ポリシーディスクリプタモジュール７４０だけが信頼されている。したがって、ポリシーコンストラクタの存在は、基礎をなす通知の仕様の関数によってクライアントの意図を明確に符号化することを可能にする。
【００５３】
＜ＮＡＰの静的な検証及び動的な組み込み＞
[0062]図８は、ＮＡＰを静的に検証するためのプロセスの一実施形態を示している。一実施形態では、このプロセスは、図１のコード検証・組み込みユニット１０２によって実行される。以下、図８を参照する。クライアントの通知ハンドラコード（プログラムＰ）８０１が与えられると、実行ツリージェネレータ８０２が、プログラム８０１に対する実行ツリーを生成する。一実施形態では、実行ツリー内のノードはプログラム内の個々の命令に対応し、特定のノードｎの子はｎに対応する命令の直後に実行され得る命令である。したがって、実行ツリーは、プログラムＰの互いに素な実行トレースの集合を定義する。それぞれのこのようなトレースｔについて、計算ユニット８０３は、「更新述語」Ｐｕ（ｔ）を計算する。一実施形態では、更新述語Ｐｕ（ｔ）は、関数ｐｒｏｃｅｓｓ＿ｎｏｔｉｆがＰのこの特定の実行トレースｔにおいて呼び出される場合及びその場合に限り、Ｐｕ（ｔ）が真であるという性質を有する。一実施形態では、プログラムＰ全体に対する更新述語は、Ｐのトレースに対する全ての更新述語の論理和である。この更新述語はＰｕ（Ｐ）と表記される。
【００５４】
[0063]一実施形態では、更新述語は、命令のトレースに対して機能する。トレースに対する更新述語の計算は、以下に示されており、命令の構造に対する帰納によって計算される。
Pu(process_notif,U) =U
Pu(Cmd1;Cmd2,U)     =Pu(Cmd1, Pu,(Cmd2,U))
Pu(f(LiteralList),U)=U
Pu(if BoolCond then Cmd1else Cmd2,U)
= BoolCond and U  ｉｆの「はい」の分岐にいる場合
Pu(if BoolCond then Cmd1,else Cmd3,U)
= not BoolCond and U  ｉｆの「いいえ」の分岐にいる場合
Pu(Var←Term,U)=U[Var←Term]
【００５５】
[0064]一実施形態では、関数定義は、関数定義が実行トレース内に現れず、関数呼び出しだけが現れるので、静的検証の目的で無視され得る。更新述語の計算は、ｐｒｏｃｅｓｓ＿ｎｏｔｉｆが最初に呼び出されるときの実行ツリー内のノードから始まる最弱事前条件の計算に似ていることに留意されたい。更新述語は、その更新述語がトレース内の命令を移動するにつれて述語を増加的に評価し続ける。プログラムＰに対する更新述語を計算するために、Ｐｕ（Ｐ，ｔｒｕｅ）が計算される。Ｕ[Ｖａｒ←Ｔｅｒｍ］は、述語Ｕにおいて全てのＶａｒの出現箇所をＴｅｒｍで置き換えることを表すことに留意されたい。
【００５６】
[0065]クライアントの通知ハンドラに関する更新述語（例えば、Ｕ）が与えられ、ＮＡＰ内のポリシーの述語がＰであるとすると、安全の検証の問題は、元のＮＡＰ内の論理結合子に対応してＰ⇔Ｕ、Ｐ→Ｕ、又はＵ→Ｐを証明することに帰着する。これは、クライアントコードがＮＡＰによって許可された通知だけを処理することを保証する。この証明が失敗する場合には、当該証明の失敗によって、クライアントコードにチェックを動的に挿入することができ、結果として得られるコードに対する更新述語がＮＡＰ内のポリシーの述語との必要な論理関係を立証できる形で満足することを保証する。
【００５７】
[0066]ＮＡＰが、ＮＡＰ内のポリシーの述語Ｐが真であるときに限りハンドラコードが呼び出される形態をとる場合には、ハンドラコードの全体を、そのハンドラコードをＰの計算用のバージョンによってラップすることによって、動的に組み込むことが可能である。この計算用のバージョンは、通知の仕様から直接アクセス可能である。
【００５８】
＜ＮＡＰの検証の例＞
[0067]以下の二つの例では、コンシューマーがレストランＲ（Ａ）用のクーポンを手に入れ、次に、そのレストランの任意の支店用のクーポンを、いつでもその支店が近い範囲内にあるときに当該コンシューマーに送るようにクーポンサーバに命じる。そうするために、コンシューマーは、クーポンサーバ及び地図サーバの双方と対話する。
【００５９】
１）高レベルの人間が読めるＮＡＰ（暗黙的ポリシーが抽出されていない）：昼食時間に近い場合、且つ、私がレストランＲに近い場合、私にＲの方向を送信せよ。
【００６０】
２）低レベルの人間が読めるＮＡＰ（暗黙的ポリシーが抽出されている）：現在の時間が昼食時間から３０分以内である場合、且つ、私がレストランＲから５マイル以内である場合、私に現在位置からＲに向かう方向を送信せよ。
【００６１】
[0068]以下の定義（definition）は、データ型の仕様の関連する部分をキャプチャしたものである。
Definitions：
Types:
Time(Varv)                #時間は１０：１５であり、ｖ＝１０×６０＋１５＝６１５であるものとする
Location(Var lat, Var long)  #位置の緯度、経度
Region(Location loc,Varvar)      #半径ｖａｒマイル内の領域
Duration(Time t,Varvar)     #（時間−ｖａｒ分）から時間までの期間
Coupon(Var,Location)            #店／レストランのクーポンＩＤ及び位置
Literals：
Tc:Time     #現在の時間
Tl:Time     #昼食時間
Lc:Location  #現在位置
Lr:Location  #レストランの位置
Rc:Region    #物理的に近いと定義される領域
Dc:Duration  #時間的に近いとされる期間
関数（命令）：
Location get_current_location(void) 
Time get_current_time (void)
Bool is_within_duration(Time, Duration) 
Bool is_within_region (Location, Region) 
Void process_notif()
Void ignore_ notif()
Void main_exec()
良いコードの例：
#メイン関数
L1: void main_exec (void){
L2:     Duration Dc= (Tl,30);      #昼食時間に近い期間を定義する
L3:     Region Rc= (Lr,5);   #レストランに近い領域を定義する
L4:     Location Lcget_curreut_location(); #現在位置を取得する
L5:     Time Tc=get_current_time();          #現在の時間を取得する
L6:     if(is_within_duration(Tc,Dc))
L7:       then if ( is_within_location(Lc,Rc) )
L8:          then process_notif();
L9:       else ignore_notif();
L10:    else ignore_notif();
L11: }  
#関数定義
L12:  Bool_is_within_duration (Time t,Duration d){
L13:    if (t >= d.t -d.v && t <= d.t)
L14:       then return True;
L15:    else return False;
L16: } 
#関数定義
L17:  Bool is_within_egion (Location1, Region r){
L18:    if ( (r.loc.lat~1.lat)^2 ÷(r.loc.long -1.long)A2 <= r.var^2)
L19:      then return True;
L20:    else return False;
L21: }
【００６２】
[0069]図９及び１０は、実行ツリーと、更新述語の計算を処理する当該実行ツリーの部分とを示している。
【００６３】
[0070]本発明の多くの変更形態及び修正形態が、上述の説明を読めば、当業者には間違いなく明らかになるであろうが、例として示して説明した如何なる特定の実施形態も限定するものとみなされることを全く意図していないことを理解されたい。したがって、様々な実施形態の詳細に関する言及は、本発明に必須と考えられる特徴だけを記載する特許請求の範囲を限定することを意図していない。
【図面の簡単な説明】
【００６４】
【図１】通知の安全な処理を検証及び保証するためのシステムの一実施形態のブロック図である。
【図２】通知を生成することができるシステム内の主な通信経路及びコンポーネントのアーキテクチャを説明する図である。
【図３】全ての通知ハンドラがクライアントドメインの一部であるシステムを示す図である。
【図４Ａ】要求を通知に関連付けるクライアント−サーバ間通信の幾つかの考え得る形態を示す図である。
【図４Ｂ】要求を通知に関連付けるクライアント−サーバ間通信の幾つかの考え得る形態を示す図である。
【図５】要求を通知に関連付けるクライアント−サーバ間通信の幾つかの考え得る形態を示す図であり、クライアントによって開始された要求に応じた通知であって異なる受信者への通知を示す図である。
【図６】要求を通知に関連付けるクライアント−サーバ間の通信の幾つかの考え得る形態を示す図であり、要求のサーバ間処理を示す図である。
【図７】第三者よって生成されたクライアントのＮＡＰを検証するためのコンシューマーのプロセスを示す図である。
【図８】ＮＡＰを静的に検証するためのプロセスの一実施形態を示す図である。
【図９】クライアントの通知ハンドラコードの例に関して、実行ツリーと、更新述語の計算を処理する当該実行ツリーの部分とを示す図である。
【図１０】クライアントの通知ハンドラコードの例に関して、実行ツリーと、更新述語の計算を処理する当該実行ツリーの部分とを示す図である。
【図１】
2009516887.tif 000003
【図２】
2009516887.tif 000004
【図３】
2009516887.tif 000005
【図４Ａ】
2009516887.tif 000006
【図４Ｂ】
2009516887.tif 000007
【図５】
2009516887.tif 000008
【図６】
2009516887.tif 000009
【図７】
2009516887.tif 000010
【図８】
2009516887.tif 000011
【図９】
2009516887.tif 000012
【図１０】
2009516887.tif 000013
【手続補正書】
【提出日】平成20年7月23日(2008.7.23)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
通知を受信するステップと、
通知受領ポリシーに従って前記通知を処理するように静的に検証された通知ハンドラを有するプログラムコードを使用して、前記通知を安全に処理するステップと、
を含む方法。
【請求項２】
前記通知を受信する前に、前記プログラムコードが通知を安全に処理することができないと判定された場合に、前記通知受領ポリシーに準拠するように、動的なチェックが前記通知ハンドラに動的に組み込まれている、請求項１に記載の方法。
【請求項３】
前記通知受領ポリシーが代数的に規定されている、請求項１に記載の方法。
【請求項４】
前記通知受領ポリシーは、前記ハンドラが前記通知の型とポリシーの述語とに基づいて前記通知を処理することを規定する、請求項１に記載の方法。
【請求項５】
前記ポリシーの述語が、同じ通知の型を有する前記通知用の仕様において規定されたポリシーコンストラクタから構築される、請求項４に記載の方法。
【請求項６】
前記通知受領ポリシーが別のパーティーによって生成され、
前記通知を処理する際に前記通知受領ポリシーを使用する前に、前記通知受領ポリシーを検証するステップを更に含む、請求項１に記載の方法。
【請求項７】
前記通知受領ポリシーを検証するステップが、通知の仕様を用いて一以上のポリシーを生成するステップと、ポリシーディスクリプタの自然言語記述を使用して前記通知受領ポリシーがどのように動作するかを記述するステップと、を含む請求項６に記載の方法。
【請求項８】
前記ハンドラに対応する前記プログラムコードの静的検証を、
前記プログラムコードに対する実行ツリーを生成するステップであって、前記実行ツリー内のノードが前記プログラムコード内の個々の命令に対応する、該ステップと、
通知がアクセスされる前記プログラムコードの部分用の更新述語を計算するステップと、
によって実行するステップを更に含む、請求項１に記載の方法。
【請求項９】
前記プログラムコード内の通知ハンドラを、前記通知受領ポリシーへの安全性準拠に関してチェックするステップを更に含む、請求項１に記載の方法。
【請求項１０】
前記通知受領ポリシーが前記通知のコンシューマーによって規定される、請求項１に記載の方法。
【請求項１１】
要求していない通知がファーストクラスデータオブジェクトとして規定される、請求項１に記載の方法。
【請求項１２】
前記ファーストクラスデータオブジェクトのうちの少なくとも一つのファーストクラスデータオブジェクトが、該一つのファーストクラスデータオブジェクトが前記通知ポリシーに対してどのように計算され得るか、及び、該一つのファーストクラスデータオブジェクトが前記通知ポリシー内のポリシーにおいてどのように使用され得るかを示す仕様を含む、請求項１１に記載の方法。
【請求項１３】
一以上のポリシーの集合内において通知を安全に処理するための少なくとも一つのポリシーが、通知受領ポリシー（ＮＡＰ）として規定される、請求項１に記載の方法。
【請求項１４】
前記通知が、サーバから、前記通知ハンドラを有する前記プログラムコードを実行するクライアントに送信される、請求項１に記載の方法。
【請求項１５】
前記通知が、前記プログラムコードを実行するクライアントからの要求に応答して送信される、請求項１に記載の方法。
【請求項１６】
前記通知が、前記プログラムコードを実行する第２のクライアントとは異なる第１のクライアントからの要求に応答して送信される、請求項１に記載の方法。
【請求項１７】
前記通知が、サーバ間通信に応答して送信される、請求項１に記載の方法。
【請求項１８】
命令を格納する一以上のコンピュータ可読記憶媒体を有する製品であって、前記命令は、システムによる実行時に、該システムに、
通知を受信するステップと、
通知受領ポリシーに従って前記通知を処理するよう静的に検証された通知ハンドラを有するプログラムコードを使用して、前記通知を安全に処理するステップと、
を含む方法を実行させる、製品。
【請求項１９】
前記通知を受信する前に、前記プログラムコードが通知を安全に処理することができないと判定された場合に、前記通知受領ポリシーに準拠するように、動的なチェックが前記通知ハンドラに動的に組み込まれている、請求項１９に記載の製品。
【請求項２０】
前記通知受領ポリシーが代数的に規定されている、請求項１９に記載の製品。
【請求項２１】
前記通知受領ポリシーは、ポリシーの述語が所定の論理状態にある場合に、前記ハンドラが前記通知の型に基づいて前記通知を処理することを規定する、請求項１９に記載の製品。
【請求項２２】
前記ポリシーの述語が、同じ通知の型を有する前記通知に関する仕様において規定されたポリシーコンストラクタから構築される、請求項２１に記載の製品。
【請求項２３】
前記方法が、通知の仕様を用いて一以上のポリシーを生成するステップと、ポリシーディスクリプタの自然言語記述を使用して前記通知受領ポリシーがどのように動作するかを記述するステップと、によって前記通知受領ポリシーを検証するステップを更に含む、請求項１９に記載の製品。
【請求項２４】
前記方法が、前記ハンドラに対応する前記プログラムコードの静的検証を、
前記プログラムコードに対する実行ツリーを生成するステップであって、前記実行ツリー内のノードが前記プログラムコード内の個々の命令に対応する、該ステップと、
通知がアクセスされる前記プログラムコードの部分に対して更新述語を計算するステップと、
によって実行するステップを更に含む、請求項１９に記載の製品。
【請求項２５】
通知を処理するプログラムコードに対する静的な検証を実行するステップであって、前記静的な検証が通知受領ポリシーに従って実行される、該ステップと、
通知を受信する前に、前記プログラムコードが通知を安全に処理することができないと判定された場合に、前記通知受領ポリシーに準拠するよう動的なチェックを前記プログラムコードに動的に組み込むステップと、
通知を受信するステップと、
前記通知受領ポリシーに従って前記通知を安全に処理するためのハンドラを含むプログラムを実行するステップと、
を含む方法。
【請求項２６】
前記通知受領ポリシーが代数的に規定される、請求項２５に記載の方法。
【請求項２７】
前記通知受領ポリシーは、前記ハンドラが前記通知の型とポリシーの述語とに基づいて前記通知を処理することを規定する、請求項２５に記載の方法製造。
【請求項２８】
前記ポリシーの述語が、同じ通知の型を有する前記通知に関する規定において規定されたポリシーコンストラクタから構築される、請求項２５に記載の方法。
【請求項２９】
通知の仕様を用いて一以上のポリシーを生成するステップと、ポリシーディスクリプタの自然言語記述を使用して前記通知受領ポリシーがどのように動作するかを記述するステップと、によって前記通知受領ポリシーを検証するステップを更に含む、請求項２５に記載の方法。
【請求項３０】
前記ハンドラに対応する前記プログラムコードの静的検証を、
前記プログラムコードに対する実行ツリーを生成するステップであって、前記実行ツリー内のノードが前記プログラムコード内の個々の命令に対応する、該ステップと、
通知がアクセスされる前記プログラムコードの部分に対して更新述語を計算するステップと、
によって実行するステップをさらに含む請求項２５に記載の方法。
【国際調査報告】
2009516887.tif 000014
2009516887.tif 000015
2009516887.tif 000016