(57)【要約】  明確なメッセージは一般的なメッセージ標準のセキュリティセマンティックスによって負わされた処理およびリソースの要求を低減するために、送信装置から受信装置に伝送されてもよい。明確なメッセージは、メッセージ内に含まれたセキュリティセマンティックスの集合的なインテントの表現を含んでもよい。メッセージ内のセキュリティセマンティックスの表現は、メッセージを処理する装置の開示処理を簡易化する。明確なメッセージは、それが送信装置から受信装置に伝送されるように、明確なメッセージを処理する任意の媒介装置もセキュリティセマンティックスの表現された集合的なインテントを追随することをさらに要求してもよい。媒介装置が表現されたインテントを理解または順守できない場合、明確なメッセージは拒絶されなければならない。
2011519190.tif 000002
【特許請求の範囲】
【請求項１】
装置間の明確なメッセージを伝送する方法を実行するためのプロセッサにより実行可能なコンピュータ読み取り可能な命令をエンコードするコンピュータ記憶媒体であって、前記方法は、
メッセージを生成するステップ（１０２）であって、前記メッセージはセキュリティセマンティックス（１０４）の内蔵型のブロックの集合的なインテントの表現を含み、前記メッセージは、前記メッセージ内に表現された集合的なインテントに順守するまたは前記メッセージを拒絶するべきメッセージを受信する任意の装置を必要とするステップと、
メッセージを送信するステップ（１０６）と
を含むことを特徴とする方法。
【請求項２】
前記集合的なインテントの表現は、セキュリティヘッダ内に含まれることを特徴とする請求項１に記載の方法。
【請求項３】
前記集合的なインテントの表現は、特定メッセージプロトコルを使用する意図をさらに含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記集合的なインテントの表現は、前記メッセージの処理のための特定アルゴリズムスイートの表示をさらに含み、前記アルゴリズムスイートは、単一のアルゴリズムを含んでもよいことを特徴とする請求項１に記載の方法。
【請求項５】
前記集合的なインテントの表現は、発信者を識別するために署名の特定的用法の表示をさらに含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記集合的なインテントの表現は、メッセージ暗号化の特殊型式を使用する意図をさらに含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記集合的なインテントの表現は、正規化の特殊型式を使用する意図をさらに含むことを特徴とする請求項１に記載の方法。
【請求項８】
装置間の明確なメッセージを伝送する方法であって、前記方法は、
メッセージを生成するステップ（１０２）であって、前記メッセージは、
セキュリティ処理命令を示すネクストホップセキュリティエレメントであって、前記メッセージを処理するすべての媒介装置によって順守されなければならない一種の正規化を規定するネクストホップセキュリティエレメントと、
セキュリティセマンティックス（１０４）の内蔵型のブロックの集合的なインテントの表現であって、前記メッセージは前記メッセージにおいて表現された前記集合的なインテントに順守するまたは前記メッセージを拒絶する前記メッセージを受信する任意の装置を必要とする集合的なインテントの表現とを含む前記ステップと、
前記メッセージを格納するステップ（６０８）と、
前記メッセージを送信するステップ（１０６）と
を含むことを特徴とする方法。
【請求項９】
包まれた署名によってカバーされたメッセージの一部に正規化の型が適用されることを保証するために、前記ネクストホップセキュリティエレメントとともに前記包まれた署名が使用されることを特徴とする請求項８に記載の方法。
【請求項１０】
前記ネクストホップセキュリティエレメントは、前記メッセージのヘッダであることを特徴とする請求項８に記載の方法。
【請求項１１】
前記ネクストホップセキュリティエレメントは、前記セキュリティ処理命令に準拠することを理解しないまたはできない媒介が前記メッセージを拒絶しなければならないことを要求することを特徴とする請求項８に記載の方法。
【請求項１２】
前記ネクストホップセキュリティエレメントは、さらに署名に関するステートメントを含み、前記署名に関するステートメントが前記メッセージを処理するすべての媒介によって順守されなければならないことを特徴とする請求項８に記載の方法。
【請求項１３】
前記ネクストホップセキュリティエレメントは、前記メッセージと共に使用される署名の型をさらに規定することを特徴とする請求項１２に記載の方法。
【請求項１４】
前記集合的なインテントを表現するステップは、
特定メッセージプロトコルを使用する意図を表現するステップと、
前記メッセージを処理するための特定アルゴリズムスイートを示すステップと、
発信者を識別するために署名の特定的用法を示すステップと、
必要とされたメッセージ暗号化の特殊型式を示すステップと
の少なくとも１つをさらに含むことを特徴とする請求項８に記載の方法。
【請求項１５】
コンピュータ装置間の明確なメッセージを伝送するためのシステムであって、前記システムは、
メッセージを生成するための送信装置（５０２）であって、前記メッセージの生成は、
前記メッセージに署名された明白な要素を挿入するステップであって、前記明白な要素はセキュリティセマンティックスの内蔵型のブロックの集合的なインテントを表現するステップと、
正規化を規定するネクストホップヘッダを挿入するステップであって、前記正規化は前記メッセージを処理するすべての媒介によって順守されなければならないステップとを含む前記送信装置と、
送信者から前記メッセージを受信するための第１の媒介装置（５０８）であって、前記集合的なインテントおよび前記正規化に順守することができない場合、前記メッセージを拒絶する前記第１の媒介装置と、
前記第１の媒介装置（５０８）から前記メッセージを受信するための受信装置（５０４）であって、前記集合的なインテントおよび前記正規化が前記第１の媒介装置（５０８）によって順守されたことを保証するために、前記受信装置はチェックし、そうでなければメッセージを拒絶する前記受信装置（５０４）と
を含むことを特徴とするシステム。
【請求項１６】
第２の媒介装置であって、前記第１の媒介装置が前記メッセージを拒絶しなければ、前記第１の媒介装置から前記第２の媒介装置間に対して前記メッセージが通過される前記第２の媒介装置をさらに含むことを特徴とする請求項１５に記載のシステム。
【請求項１７】
前記第１の媒介装置および前記第２の媒介装置５０８は、前記集合的なインテントおよび前記正規化に順守しなければならないことを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記第１の媒介装置は、情報が前記集合的なインテントおよび前記正規化に順守する限り、前記メッセージに情報を追加してもよいことを特徴とする請求項１５に記載のシステム。
【請求項１９】
前記受信装置は、前記明白な要素が前記第１の媒介装置によって除去される場合に前記メッセージを拒絶することを特徴とする請求項１５に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、送信装置と受信装置との間の明確なメッセージ（ｗｅｌｌ−ｄｅｆｉｎｅｄ  ｍｅｓｓａｇｅ）を生成し、送信するためのシステムおよび方法に関する。
【背景技術】
【０００２】
装置間で伝送されたメッセージにセキュリティを提供する標準方式は、特に装置の処理およびメモリリソースに負担をかけている傾向がある。多くの実例において、この事実は、多くのメッセージ標準の冗長および豊富な機能性に起因する。豊富な機能性により、メッセージを受信する装置は、機能性の限定されたサブセットのみが実際にメッセージ内に存在しているにもかかわらず、メッセージ標準によって提供される機能性をすべて処理する準備をしなければならない。さらに、最新のメッセージ標準の豊富さは、様々な型のデジタル署名ブロックを可能にする。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
これは多くの場合、最新のメッセージ標準がアドレス指定することを試みる多くのシナリオ、展開性オプションおよび正規化オプションにより表現したものを広く接続することに帰着する。そのような要因により提示された処理とリソースコストにより、多くの装置が、最新のメッセージ標準のセキュリティポリシーの複雑さに対処することができない、または選択できない。本明細書の実施形態が想定されたのは、この一般的な環境に関するものである。
【課題を解決するための手段】
【０００４】
本明細書の実施形態は、送信装置と受信装置との間の明確なメッセージ（ｗｅｌｌ−ｄｅｆｉｎｅｄ  ｍｅｓｓａｇｅ）を生成し、送信するためのシステムおよび方法に関する。明確なメッセージは、セキュリティセマンティックスの集合的なインテントを明確に表現するメッセージである。そのようにする際に、メッセージは、認証情報、プロトコル情報、アルゴリズムスイート、署名、暗号化、セッション情報および／または、メッセージ正規化に関する情報のようなメッセージと関連するセキュリティ情報および／または処理情報を明確に表現してもよい。明確なメッセージの表現されたインテントは、そのような情報を決定するためにメッセージを解析するための受信装置の負担を減らすことにより、明確なメッセージを解釈する装置によって、必要とされる処理と必要メモリを低減する。表現されたインテントは、セキュリティ利点を提供する一方で、さらになお他のメッセージ標準に含まれる複数のアルゴリズム、署名および正規化要求のために準備される装置の負荷を軽減する。
【０００５】
本明細書の付加的な実施形態は、メッセージが受信装置に向かう間に明確なメッセージの保全性を保つことを提供する。実施形態において、メッセージ要素またはヘッダは、メッセージのためのセキュリティセマンティックスの表現された集合的なインテントを強化するために利用されてもよい。実施形態において、受取側に向かう明確なメッセージを受信するまたは処理するあらゆる媒介は、明確なメッセージの表現された集合的なインテントを理解し順守しなければならなく、さもないと、メッセージは媒介または受取人によって拒絶される。
【０００６】
この発明の概要は、以下の発明の詳細な説明においてさらに記述される、簡易化された形式の概念の抜粋を紹介するために提供される。この発明の概要は、請求項の内容の主要な特徴または本質的な特徴を特定するようには意図するものでもないし、請求項の内容の範囲を限定するために使用されることを意図するものでもない。
【発明の効果】
【０００７】
本明細書の実施形態は、同様な数字が同様な要素を指す添付の図面への参照によってより容易に描写されてもよい。
【図面の簡単な説明】
【０００８】
【図１】送信装置によりセキュリティセマンティックスの集合的なインテントを表現するメッセージを生成する方法１００の実施形態を表現するフローチャートである。
【図２】セキュリティセマンティックスの集合的なインテントを表現する方法２００の実施形態を表現するフローチャートである。
【図３】媒介装置によりセキュリティセマンティックスの集合的なインテントを表現するメッセージを処理する方法３００の実施形態を表現するフローチャートである。
【図４】受信装置によりセキュリティセマンティックスの集合的なインテントを表現するメッセージを受け取る方法４００の実施形態を表現するフローチャートである。
【図５】送信者装置から受信装置に対してセキュリティセマンティックスの集合的なインテントを表現するメッセージを送信するためのシステム５００の実施形態を図示する機能図である。
【図６】本明細書の実施形態を実行するために動作可能なコンピュータ環境とコンピュータシステム６００を図示する機能図である。
【発明を実施するための形態】
【０００９】
この明細書は、可能な実施形態のいくつかを表示する添付の図面に関連して典型的な実施形態をより十分に描写する。但し、他の態様が様々な形式で具体化されてもよいし、明細書の特定の実施形態の介在物は、ここに述べられる実施形態にそのような態様を限定するように解釈されるべきでない。むしろ、図面に表現された実施形態は、充分で、完全で、当業者に意図した範囲を十分に伝える明細書の情報を提供するように含まれている。図を参照する場合、同様な構成および全体にわたって表示される要素は、同様な参照符号により示される。
【００１０】
本明細書の実施形態は、送信装置と受信装置との間の明確なメッセージを送信するためのシステムおよび方法に関する。実施形態において、明確なメッセージは、メッセージに適用される（されている）内蔵型のブロックセキュリティセマンティックスの集合的なインテントの表現に関連付けられるメッセージである。１つの実施形態において、セキュリティセマンティックスの内蔵型のブロックの集合的なインテントは、明確なメッセージに適用された異なる型のセキュリティ（例えば、暗号化、プロトコルなど）の全ての結合した結果であってもよい。別の実施形態において、セキュリティセマンティックスの集合的なインテントは、グルーピング、または明確なメッセージに適用された異なる型のセキュリティ（例えば、暗号化、プロトコルなど）の全てのリストであってもよい。実施形態において、内蔵型のブロックは、セキュリティセマンティックスが適用されるメッセージの一部であってもよい。例えば、表現されたセキュリティセマンティックスは、図２に関してさらに説明される、包まれた署名（ｅｎｖｅｌｏｐｅｄ  ｓｉｇｎａｔｕｒｅ）などのようなヘッダまたは署名内に含まれていてもよい。そのような実施形態において、ヘッダまたは署名は、メッセージの一部に適用される。ヘッダまたは署名によって包まれたメッセージの一部は、セキュリティセマンティックスが適用する内蔵型ブロックである。他の実施形態において、内蔵型のブロックは全体のメッセージであってもよい。当業者は、内蔵型のブロックがセキュリティセマンティックスに従う全メッセージを含むメッセージの任意の一部であることを理解するであろう。明確なメッセージは、認証情報、プロトコル情報、アルゴリズムスイート、署名、暗号化、セッション情報および／またはメッセージ正規化に関する情報などのようなメッセージと関連するセキュリティまたは処理情報を表現してもよい。他の実施形態において、他のメッセージ処理情報は、メッセージ内で表現されてもよい。メッセージ内の明瞭な表現処理情報（特にメッセージセキュリティと関連する処理情報）は、処理要求を低減するだけでなく、低減されたメッセージサイズを可能にする。一方、そのような処理情報を明らかに表現しないメッセージを受信する装置は、処理情報を決定するためにメッセージを解析するように義務づけられる。例えば、エクステンシブルマークアップランゲージ（ＸＭＬ）は、機能性に富んだ冗長な標準規格である。ＸＭＬメッセージを処理する装置は、標準規格を使用してＸＭＬメッセージを処理し通信するために、正規化の実現性をすべて含む、ＸＭＬの機能性をすべて処理することができるはずである。これは、一般に装置に対して、大幅な処理および必要メモリを負わせる。但し、メッセージ内の処理情報の型を明瞭に表現することは、メッセージを容易に受信し処理するために、一般に標準のコンピュータ装置より少ない処理パワーおよびメモリを有する小型装置（例えば、携帯情報端末（ＰＤＡ）、ユニバーサルシリアルバス（ＵＳＢ）装置、スマートフォン、携帯電話など）を可能にする。実施形態において、明示要素は、メッセージ処理情報を記述するメッセージに導入されてもよく、それによってセキュリティ開示（ｓ���ｃｕｒｉｔｙ  ｄｉｓｃｏｖｅｒｙ）および処理セマンティックスを単純化する。
【００１１】
さらなる実施形態において、本明細書に開示されたシステムおよび方法は、送信装置から受信装置に対して明確なメッセージの保全性を途中で維持することを提供する。メッセージが送信装置から受信装置（例えば、媒介装置の利用なしで、または直接接続を介して）に直接送信される場合、メッセージの保全性は伝送の間に保たれてもよい。但し、受信装置へ向かう途中で、インターネットなどのようなネットワークを通して伝送されたメッセージは、一般に１つ以上の媒介装置を介して通過する。最新のメッセージ規格は、トランシットの間に媒介装置がメッセージに情報を追加することを可能にする。例えば、媒介装置は、メッセージが媒介装置によって処理されたという表示へのメッセージに署名を追加してもよい。そのような情報の追加は、最良の場合、受信装置による受け取りに際してメッセージの処理に関連付けたリソース要求（例えば、処理パワー、メモリ量など）を増加させ、最悪の場合、明確なメッセージのセキュリティセマンティックスを順守できない。本明細書の実施形態は、メッセージを処理する全ての装置によって順守するメッセージ内の特定のステートメントを提供する。実施形態において、これらの特定のステートメントは、メッセージ内の要素および／またはヘッダの形式をとってもよい。例えば、ネクストホップ（次の相手）セキュリティヘッダ（Ｎｅｘｔ−ｈｏｐ  Ｓｅｃｕｒｉｔｙ  Ｈｅａｄｅｒ）は、メッセージを処理する媒介のために命令を提供するメッセージ内に含まれていてもよい。
【００１２】
表１は、本明細書の情報の実施形態と共に使用されてもよい、明確なメッセージのサンプルを提供する。表１のメッセージ例はＸＭＬメッセージであるが、当業者は、ハイパーテキストマークアップ言語（ＨＴＭＬ）メッセージ、拡張可能なＨＴＭＬ（ＸＨＴＭＬ）メッセージ、簡易オブジェクトアクセスプロトコル（ＳＯＡＰ）メッセージなどのような他の型のメッセージが本明細書の実施形態により利用されてもよいことを十分に理解するであろう。さらに、本明細書の実施形態において使用される明確なメッセージは、Ｗｅｂサービスセキュリティ（ＷＳ−Ｓｅｃｕｒｉｔｙ）プロトコル、または他の型のセキュリティ、トランスポートまたは当業に既知のメッセージプロトコルに準拠してもよい。サンプルメッセージの要素は、本明細書の情報を通じて参照されるであろう。
【００１３】
［表１］
明確なメッセージ例
<?xml version=" 1.0" encoding="utf-8"?> 
<S:Envelope 
xmlns:S="http://www.w3.org/2003/05/soap-envelope" 
xmlns:A="http://www.w3.org/2005/08/addressing" 
xmlns:U="http://docs. oasis-open.org/wss/2004/01/oasis-200401-wss- 
wssecurity-utility- 1.0.xsd" 
xmlns:E="http://docs. oasis-open.org/wss/2004/01/oasis-200401-wss- 
wssecurity-secext- 1.0.xsd" xmlns:C="http://schemas. microsoft.com/2006/02/sxs" 
>
<S:Header> 
<C:NextHopSecurity S:mustUnderstand=" l" S:Actor=".../Next">
<C:EolCanonicalizationInUse /> 
</C:NextHopSecurity> 
<A:To U:Id=" 1" S:mustUnderstand=" l"> 
http://example.org/ 
</A:To>
<A:MessageID U:Id="_2">_123456789</A:MessageID> 
<E:Security S:mustUnderstand=" 1 ">
<U:Timestamp U:Id="_3">
<U:Created>2006-02-02T19:59:47.329Z</U:Created> 
<U:Expires>2006-02-02T19:59:47.329Z</U:Expires>
</U:Timestamp>
<E:SecurityTokenReference U:Id="_4">
…
</E:SecurityTokenReference> 
<C:Sig 
U:Id="_5"
Alg="http://schemas. microsoft.com/2006/02/sxs/suites/Basic256Eol" 
Key="_4" 
AEL="3" 
SEL="_3" 
PEL=" 1_2" 
Bod=" l">
<C : Sig Val>mLPyJkI4e2wdezj YRUOGVj FsEp4=</C : SigVal>
</C:Sig> 
</E:Security>
</S:Header>
<S:Body>
<X:ApplicationStuff/>
</S:Body>
</S:Envelope>
【００１４】
図１は、セキュリティセマンティックスの集合的なインテントを表現するメッセージを生成する方法１００の実施形態を表現するフローチャートである。実施形態において、明確なメッセージは送信装置によって生成されてもよい。他の実施形態において、送信装置は、後に媒介装置による修正によって明確なメッセージになるメッセージを生成してもよい。フローは、送信装置がメッセージを生成するステップ１０２で開始する。ステップ１０２で生成されるメッセージは、表１の例のメッセージなどのようなＸＭＬメッセージ、ＨＴＭＬメッセージ、ＸＨＴＭＬメッセージ、ＳＯＡＰメッセージまたは当業に既知の任意の他の型のメッセージであってもよい。実施形態において、生成されたメッセージは、受信装置を対象とする送信装置からの情報および／または命令を伝える。実施形態において、ステップ１０２で生成されたメッセージは、本明細書の実施形態において記載されているような明確なメッセージである。他の実施形態において、ステップ１０２で生成されたメッセージは、明確なメッセージではない。
【００１５】
フローは、メッセージのセキュリティセマンティックスの集合的なインテントがメッセージ内で表現されるステップ１０４に移る。実施形態において、メッセージのセキュリティセマンティックスは、セキュリティ、または認証情報、プロトコル情報、アルゴリズムスイート、署名、暗号化、セッション情報および／またはメッセージ正規化に関する情報などのようなメッセージと関連する処理情報を含めることにより、明確に表現されてもよい。他の実施形態において、他のメッセージ処理情報は、メッセージ内で表現されてもよい。さらに、メッセージは、セキュリティ処理および／またはメッセージの正規化に関連するメッセージのさらなる特性を記載してもよい。
【００１６】
１つの非限定的な実施形態において、ある明示（例えば、＜Ｃ：Ｍａｎｉｆｅｓｔ＞）は、セキュリティプロセッサに関連する様々なセキュリティ作用、メッセージ処理情報またはメタデータのハイレベルな特性を記載するために使用されてもよい。例えば、＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素は、以下のような情報を含んでもよい。あるプロトコルがメッセージと共に使用されていると識別する普遍的リソース識別子（ＵＲＩ）、主要な目的と同様にメッセージを備えたキーの利用に関する情報、明示が生成された時に使用される（例えば、デフォルトアルゴリズムスイートまたは他のアルゴリズムスイート）アルゴリズムスイートと関連する情報、またはセキュリティおよび／またはメッセージの処理に関連する任意の他の型の情報。実施形態において、＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素は、セキュリティプロセッサに付加的なメタデータを提供してもよい。そのような実施形態において、＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素内に含まれているメタデータは、メッセージと共に関連付けられたセキュリティ情報を処理する場合に受信装置の処理手法を導くために使用されてもよい。表２は、本明細書の実施形態と共に使用されてもよい＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素のスキーマ例を提供する。＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素の属性を、図２に関してさらに説明する。
【００１７】
［表２］
＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素のスキーマ例
<C Manifest
V:Id="xs:ID"
?ro="xs:anyUIU"?
SID=" 'xs :any URT"?
A\g="xs:anyURT}?
SK="xs:ID List"?
CSK="xs:ID List"?
EK=" xs :ID List"?
…>
<U:Created>xs:DateTime"</lJ:Created>?
<U:Expires>xi':JDate7z'me"<U:Expires>?
…
</C:Manifest>
/C:Manifest
メッセージセキュリティ明示要素。
/C:Manifest/@U:Id
明示のために必要な識別名。
/C:Manifest/@Pro
使用されているプロトコルを識別するオプションのＵＲＩ。存在しない場合、この値はこのドキュメントの範囲外のメカニズムを使用して、両方のパーティによって識別されており一致されていなければならない。
/C:Manifest/@SID
使用されるセキュリティセッションを識別する「ＵＲＩ」を含むオプションの属性。
/C:Manifest/@Alg
署名と暗号化の実行のために使用する、アルゴリズムスイートを識別するオプションのＵＲＩ。その場合、この値は、それらの要素上で無指定の場合の特定の署名および暗号化のための値をポピュレートするために使用されてもよい。
/C:Manifest/@SK
トークンを含む要素への「ＩＤ」レファレンス、またはメッセージに署名するために使用されるトークンへのレファレンスのリストを含むオプションの属性。
/C:Manifest/@CSK
トークンを含む要素への「ＩＤ」レファレンス、またはメッセージに連署するために使用されるトークンへのレファレンスを含むリストを含むオプションの属性。
/C:Manifest/@EK
トークンを含む要素への「ＩＤ」レファレンス、またはメッセージを暗号化するために使用されるトークンへのレファレンスのリストを含むオプションの属性。
/C:Manifest/@{any}
これは付加的な属性を可能にする展開性ポイントである。
/C:Manifest/U:Created
明示が作成された日時を示す値を含むオプションのサブエレメント。ＷＳセキュリティエレメントは再度使用されるが、処理を簡易化するために明示の内部に配置される。
/C:Manifest/U:Expires
明示が終了するべき日時を示す値を含むオプションのサブエレメント。ＷＳセキュリティエレメントは再度使用されるが、処理を簡易化するために明示の内部に配置される。
/C:Manifest/{any}
これは追加エレメントが明示において含まれることを可能にする、展開性ポイントである。これらの要素は、明示を含むあらゆる署名において含まれている。任意のサブエレメントも、このドキュメントにおいて指定された動作からの処理動作を変更してはならない。
【００１８】
実施形態において、＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素が、明確なメッセージ、または代わりに明確なメッセージに含まれていたヘッダ内のヘッダとして出現してもよい。例えば、メッセージがＷＳセキュリティプロトコルに準拠する実施形態において、セキュリティの開示および処理セマンティックスを簡易化するために、例えば＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素は、＜Ｅ：Ｓｅｃｕｒｉｔｙ＞ヘッダ内に含まれていてもよい。当業者は、＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素がメッセージ処理およびメッセージセキュリティ情報をなお識別する一方でメッセージの異なる部分において含まれていてもよいことを十分に理解するであろう。ステップ１０２は、＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素の利用に関して記述されたが、当業者はさらに、要素はもっぱら説明のしやすさのために提供されたことを十分に理解するであろう。当業に既知のメッセージ処理およびメッセージセキュリティ情報を識別する他の要素または他の手段は、本明細書の実施形態により利用されてもよい。
【００１９】
さらなる実施形態において、メッセージの正規化（標準表現への１つ以上の可能な表現を有するデータを変換するプロセス）に関する情報も、ステップ１０２においてメッセージ内で表現されてもよい。実施形態において、ステップ１０２で生成されたメッセージと共に使用される正規化アルゴリズムを記述する情報は、ステップ１０４においてメッセージ内に含まれていてもよい。実施形態において、メッセージが送信装置から受信装置に伝送されるように、特定の正規化アルゴリズムが強化されてもよい。例えば、受信装置へ向かう途中のメッセージを処理する任意の媒介装置も、メッセージ（例えば、媒介装置はメッセージの正規化を変更するメッセージにデータを修正および／または追加することができない）内に規定された正規化アルゴリズムを使用せざるをえない。そのような実施形態において、正規化アルゴリズムの規定は単刀直入の正規化変換を提供し、それによってメッセージの署名の生成および検証に関連付けた処理とメモリコストを削減する。これは、ＰＤＡ、ＵＳＢ装置、スマートフォンおよび携帯電話などのような低出力の装置用にメッセージを処理することを可能にする。
【００２０】
実施形態において、ネクストホップセキュリティヘッダ要素（例えば、表１を参照）は、送信装置から受信装置に伝送されるように、明確なメッセージを処理する媒介装置のための命令を提供するために使用されてもよい。実施形態において、ネクストホップセキュリティヘッダは、メッセージをエンコードした送信装置によって使用される任意のシリアライゼーションおよび／または仮定の処理を保存し繰り越してもよい。これは、正規化および包まれた署名の利用などのような態様を含んでもよく、図２に関してさらに以下で説明される。実施形態において、ネクストホップセキュリティヘッダは、単刀直入の正規化変換を提供するために使用されてもよい。これは、正規化の様々な形式を可能にするＸＭＬなどのようなマークアップ言語では典型的である、コストのかかる正規化および署名検証の回避を可能にする。単刀直入の正規化の提供により、明確なメッセージを処理する装置は、様々な正規化変換を処理しなければならないことから軽減される。さらなる実施形態において、ネクストホップセキュリティヘッダは、明確なメッセージが受取人へ向かう途中で通過できる媒介装置が、ネクストホップセキュリティヘッダによって示された仮定を理解し順守しなければならないことを示してもよい。さもないと、媒介装置は、メッセージを拒絶するに違いなく、それは図４に関してさらに説明される。さらなる実施形態において、ネクストホップセキュリティヘッダは、メッセージ（例えば、メッセージにより使用されている正規化の型を宣言する正規化要素、包まれた署名が利用中と宣言する包まれた署名要素、など）のための様々なセキュリティ処理命令を含むことができるコンテナヘッダ要素であってもよい。それらが命令を理解しない場合、媒介がメッセージを拒絶するという要求も、ネクストホップセキュリティヘッダのレベルで表現されてもよい。明細書はネクストホップセキュリティをメッセージヘッダのように記述しているが、当業者はネクストホップセキュリティが要素、属性またはメッセージの他の一部の形式で表現されてもよいことを十分に理解するであろう。表３は、ＳＯＡＰメッセージと共に使用されるネクストホップセキュリティヘッダのスキーマ例を提供する。
【００２１】
［表３］
＜／Ｃ：ＮｅｘｔＨｏｐＳｅｃｕｒｉｔｙ＞要素のスキーマ例
<C:NextHopSecurity S:mustUnderstand=" 1" S:role=".../Next" ...> 
…
</C:NextHopSecurity>
/C:NextHopSecurity
このヘッダ要素は、媒介のためのセキュリティに特有の命令を含む。
/C :NextHopSecurity/@S:mustUnderstand
このヘッダ上の「ＳＯＡＰ  Ｍｕｓｔ  Ｕｎｄｅｒｓｔａｎｄ」の属性は存在しなければならないし、「真（ｔｒｕｅ）」に設定されていなければならない。
/C:NextHopSecurity/@S:role
「ＳＯＡＰ  Ａｃｔｏｒ  ｏｒ  Ｒｏｌｅ」の属性は存在しなければならないし、「次（Ｎｅｘｔ）」に設定されなければならない。「Ｎｅｘｔ」の属性名及び実際の値は使用されるＳＯＡＰのバージョンに特有である。
【００２２】
本明細書の実施形態は、ネクストホップセキュリティヘッダに関して記述されている一方、当業者は、他の型のヘッダおよび／またはシリアライゼーションを表現する手段および／または仮定の処理が本明細書の実施形態により利用されてもよいことを十分に理解するであろう。当業者は、セキュリティセマンティックスの集合的なインテントを表わす際、集合的なインテントがどのように表現されるかに関係なく、ステップ１０２で生成されたメッセージが本明細書の実施形態による明確なメッセージになることを十分に理解するであろう。
【００２３】
メッセージ内のセキュリティセマンティックスの集合的なインテントを表現した後に、明確なメッセージが指定受取人に伝送される場合、フローはステップ１０６に移る。他の実施形態において、明確なメッセージは、送信者装置から受信装置に直接伝送される。他の実施形態において、明確なメッセージは送信者装置から受信装置に１つ以上の媒介装置を介して伝送される。ステップ１０４に関して記述されるように、明確なメッセージは、明確なメッセージの集合的なインテントを生成するおよび／または表現する際に装置によって使用される仮定を保存し、それによって受信装置が生成装置の仮定による明確なメッセージを受信することを保証する情報（例えば、＜Ｃ：ＮｅｘｔＨｏｐＳｅｃｕｒｉｔｙ＞ヘッダ（表１および表３）などのようなヘッダ）を含んでもよい。さらなる実施形態において、明確なメッセージは、送信される前の装置の揮発性または不揮発性メモリに保存されてもよい。そのような実施形態において、送信者から受取人までの伝送の間にメッセージが失われるか、破壊されるか、および／または拒絶される場合、メッセージを保存することによって、メッセージのバックアップが提供される。
【００２４】
他の実施形態において、ステップ１０４は送信装置によってステップ１０２と同時に実行されてもよい。例えば、ステップ１０２で生成されるように、セキュリティセマンティックスの集合的なインテントを表現することと関連する情報は、メッセージ内に含まれていてもよい。他の実施形態において、セキュリティセマンティックスの集合的なインテントの表現は、送信者以外の装置によってメッセージへ挿入されてもよい。例えば、媒介装置は、メッセージ内の集合的なインテントと関連する情報を挿入してもよい。本明細書の実施形態は、インテントが表現された後、集合的なインテントが、メッセージを処理するすべての装置によって順守される限り、どの装置がメッセージに集合的なインテントを挿入したのかに関係なく動作するであろう。さらなる実施形態において、集合的なインテントは、メッセージ自体内に表現されなくてもよいが、メッセージまたはメッセージに伴うアタッチメントにおいてあってもよい。
【００２５】
図２は、セキュリティセマンティックスの集合的なインテントを表現する方法２００の実施形態を表現するフローチャートである。実施形態において、セキュリティセマンティックスの集合的なインテントを表現することは、セキュリティ関連の情報をメッセージに関連付けることを含む。例えば、セキュリティ関連の情報は、メッセージへ挿入されてもよいし、または代替の実施形態において、メッセージ（例えば、別のメッセージまたはアタッチメント内）を伴ってもよい。図２のステップは、メッセージ内のセキュリティセマンティックスの集合的なインテントを表現するために利用できるセキュリティセマンティックスに関連した情報の型の非限定的な例を提供する。当業者は、セキュリティセマンティックスの集合的なインテントを表現する場合、図２に関して記述されない他の型の情報もメッセージに関連付けてもよいことを理解するであろう。
【００２６】
フローは、認証情報にメッセージが提供される場合、ステップ２０２で開始する。実施形態において、認証情報は、パスワード、キーまたはメッセージの認証の技術には公知である他の型の情報を含んでもよい。他の実施形態において、ステップ２０２で提供される情報は、ユーザ、送信者装置、媒介装置またはメッセージで関連付けた任意の他の装置を認証するために使用されてもよい。
【００２７】
フローは、メッセージと共に使用されているプロトコルの１つ以上の表示がメッセージと関連付けられている場合、ステップ２０４に移る。実施形態において、プロトコルは、伝送プロトコル、メッセージ処理プロトコル、セキュリティプロトコルまたは当該技術に既知の任意の他の型のプロトコルに関連してもよい。
【００２８】
例えば、１つの実施形態において、Ｘ５０９プロトコルは、メッセージと共に使用され、それにより、ステップ２０４で示されてもよい。Ｘ５０９プロトコルは、２つの証明書、サービスを識別する１つのもの、およびクライアントを識別するためにもう１つを使用する。Ｘ５０９プロトコルを使用する実施形態において、１つのＸ５０９トークンは、メッセージ開始者を識別するために使用されてもよく、別のトークンは、メッセージ受取人を識別するために使用されてもよい。そのような実施形態において、Ｘ５０９プロトコルは、メッセージとプロトコルを関連付けることにより示されてもよい。プロトコルは、メッセージとプロトコルポリシーを関連付けることにより、メッセージとプロトコルのＵＲＩを関連付けることにより、または当業に既知のメッセージとプロトコルを関連付ける任意の他の手段により、メッセージと関連付けてもよい。表２の＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素を使用する実施形態において、Ｘ５０９プロトコルを識別するＵＲＩが、／Ｃ：Ｍａｎｉｆｅｓｔ／＠Ｐｒｏ属性によって識別されてもよい。表４は、本明細書の実施形態と共に使用されてもよいＸ５０９プロトコルのためのポリシー例を提供する。
【００２９】
［表４］
Ｘ５０９プロトコルのためのポリシー例
<wsp:Policy> 
<sp:AsymmetricBinding> 
<wsp:Policy> 
<sp :InitiatorToken> 
<wsp:Policy>
<sp:X509Token /> 
</wsp:Policy> 
</sp :InitiatorToken> 
<sp:RecipientToken> 
<wsp:Policy>
<sp:X509Token /> 
</wsp:Policy> 
</sp:RecipientToken> 
<sp : AlgorithmSuite> 
<wsp:Policy>
<C:Basic256Eol /> 
</wsp:Policy> 
</sp:AlgorithmSuite> 
<sp:IncludeTimestamp /> 
<sp:EncryptSignature /> 
<sp:OnlySignEntireHeadersAndBody /> 
<C:SxsSignature /> 
<C:SxsEncryption /> 
<C:SxsNextHopSecurity /> 
</wsp:Policy> 
</sp : AsymmetricBinding> 
</wsp:Policy> 
【００３０】
他の実施形態において、ユーザ名メッセージプロトコルは、ステップ２０４で示されてもよい。ユーザ名メッセージプロトコルは、メッセージ開始者を識別するためにユーザ名トークンを、およびメッセージ受取人を識別するためにＸ５０９トークン利用する。実施形態において、ユーザ名メッセージプロトコルは、メッセージでプロトコルを関連付けることにより示されてもよい。プロトコルは、メッセージ内のプロトコルポリシーを含めることにより、メッセージを備えたプロトコルのＵＲＩを含むことにより、または当業に既知のメッセージでプロトコルを関連付ける任意の他の手段により、メッセージを関連付けてもよい。表２の＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素を使用する実施形態において、ユーザ名メッセージプロトコルを識別するＵＲＩが、／Ｃ：Ｍａｎｉｆｅｓｔ／＠Ｐｒｏ属性によって識別されてもよい。表５は、本明細書の実施形態と共に使用されてもよいユーザ名メッセージプロトコルのためのポリシー例を提供する。
【００３１】
［表５］
ユーザ名メッセージプロトコルのポリシー例
<wsp:Policy> 
<sp:SymmetricBinding> 
<wsp:Policy> 
<sp:ProtectionToken> 
<wsp:Policy>
<C:X509Token /> 
</wsp:Policy> 
</sp:ProtectionToken> 
<sp:AlgorithmSuite> 
<wsp:Policy>
<C:Basic256Eol /> 
</wsp:Policy> 
</sp:AlgorithmSuite> 
<sp:IncludeTimestamp /> 
<sp:EncryptSignature /> 
<sp:OnlySignEntireHeadersAndBody /> 
<C:SxsSignature /> 
<C:SxsEncryption /> 
</wsp:Policy> 
</sp:SymmetricBinding> 
<sp:SignedSupportingTokens> 
<wsp:Policy>
<sp:UsernameToken />
</wsp:Policy>
</sp :SignedSupportingTokens> </wsp:Policy>
【００３２】
表４および表５において提供される特定のプロトコルは、ステップ２０４で示されてもよいプロトコルの例として提供される。当業者は、本明細書の実施形態の範囲内にとどまる一方で、メッセージ内のメッセージセキュリティ、処理および／またはトランスポートにおいて使用される他の型のプロトコルが示されてもよいことを十分に理解するだろう。
【００３３】
フローは、セキュリティ、生成および／またはメッセージの処理の目的のために使用されたアルゴリズムが、メッセージと関連付けられる動作２０６に移る。実施形態において、メッセージと共に使用される任意の型のアルゴリズムは、ステップ２０６で示されてもよい。アルゴリズムは、画像でアルゴリズムの表現したものを関連付けることにより示されてもよい。他の実施形態において、アルゴリズムは、アルゴリズムを識別するＵＲＩによって示されてもよい。例えば、表２において記載された＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素を使用する実施形態において、アルゴリズムは、  ＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素の／Ｃ：Ｍａｎｉｆｅｓｔ／＠ＡＩｇ属性で関連付けたＵＲＩによって識別されてもよい。当業者は、メッセージとアルゴリズムを関連付ける多くの方法があることを理解するであろう。本明細書の実施形態は、アルゴリズムがどのようにメッセージに関連付けられるのかに関係なく動作するであろう。
【００３４】
別の実施形態において、アルゴリズムスイートは、メッセージと関連付けられてもよい。例えば、アルゴリズムスイートは、メカニズムであってもよく、それによって単一のＵＲＩがメッセージと共に使用されるために選択された一連のアルゴリズムを表現するために、使用される。ある実施形態において、アルゴリズムスイートは、複数のアルゴリズムを含んでいてもよい一方、単一のアルゴリズムのみが各々の特定タスクのために規定されてもよい。ほとんどのメッセージシステムにおいて、多くの異なるアルゴリズムは、特定タスクと関連付けられてもよい。そのようなメッセージシステムを使用することを必要とする装置は、潜在的に各々の作業に複数のアルゴリズムを適用する準備を用意しているに違いなく、処理リソースの重要な量を得る。各々の特定タスクに単一のアルゴリズムを関連付けることは、各々のタスクに関連付けたアルゴリズムの数を削減し、順々にメッセージを処理するのに必要な処理の量を削減する。例えば、異なるタスクのための複数のアルゴリズムを備えたアルゴリズムスイートは、ＳＨＡ−１などのような単一の要約アルゴリズムを含んでいてもよい。そのような例において、メッセージを処理する装置は、単に要約アルゴリズムとしてＳＨＡ−１を適用するべきであり、したがって、他の要約アルゴリズムを処理することおよび／または適用するための装置の必要性を削減する。但し、他の実施形態において、複数のアルゴリズムは各々のタスクのために規定されてもよい。
【００３５】
実施形態において、メッセージに関連付けられたアルゴリズムまたはアルゴリズムのスイートは、メッセージにアサーション要素を挿入することにより関連付けられてもよい。例えば、Ｂａｓｉｃ２５６Ｅｏｌアルゴリズムスイートなどのようなアルゴリズムまたはアルゴリズムのスイートの場合、＜Ｃ：Ｂａｓｉｃ２５６Ｅｏｌ／＞アサーション要素を使用するメッセージへ挿入されてもよい。＜Ｃ：Ｂａｓｉｃ２５６Ｅｏｌ／＞アサーション要素は、Ｂａｓｉｃ２５６Ｅｏｌアルゴリズムスイートを識別する。実施形態において、＜Ｃ：Ｂａｓｉｃ２５６Ｅｏｌ／＞アサーション要素などのようなアサーション要素は、表示としてＵＲＩを使用する代わりにメッセージで組み入れられたアルゴリズムの表示として規定され使用されてもよい。さらなる実施形態において、両方のアサーション要素およびＵＲＩは、メッセージで組み入れられた表示アルゴリズムに使用されてもよい。実施形態において、アサーション要素の任意数は、異なるアルゴリズムまたはアルゴリズムスイートを識別するために規定されてもよい。ＷＳセキュリティを使用するさらなる実施形態において、アルゴリズムアサーション要素は、＜ｓｐ：ＡｌｇｏｒｉｔｈｍＳｕｉｔｅ＞アサーションの下でサブアサーションとして出現してもよい。
【００３６】
当業者は、前のアルゴリズムおよびアルゴリズムスイートが単に例として提供され限定的ではないことを十分に理解するであろう。本明細書の実施形態は、ステップ２０６で示されたアルゴリズムまたはアルゴリズムのスイートに関係なく動作するであろう。さらに、メッセージに関連付けられた任意のアルゴリズムが明らかに示されている限り、アルゴリズムを識別する任意の方法は本明細書の実施形態に組み入れられてもよい。
【００３７】
フローは、メッセージに関連付けられた任意の署名が示されるステップ２０８に移る。実施形態において、署名は、装置がメッセージを処理したものを示すメッセージと共に使用されるキーを規定するために、認証情報を提供するために、メッセージの発信者を示すために、または当業に既知の任意の他の目的のために、使用されてもよい。実施形態において、署名は全体のメッセージまたはメッセージの一部に適用されてもよい。本明細書の実施形態において、署名は、トークン、トークンへのレファレンスまたは証明書の利用によって示されてもよい。例えば、表２の＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素を使用する実施形態において、署名は、／Ｃ：Ｍａｎｉｆｅｓｔ／＠ＳＫに関連付けられたレファレンスまたは＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素に関連付けられた／Ｃ：Ｍａｎｉｆｅｓｔ／＠ＣＳＫ属性によって識別されてもよい。
【００３８】
他の実施形態において、署名は署名要素の利用によって示されてもよい。署名要素の任意数は規定され、メッセージに組み入れられてもよい。ＷＳセキュリティを使用する本明細書の実施形態において、署名要素は、＜Ｅ：Ｓｅｃｕｒｉｔｙ＞ヘッダまたは＜Ｃ：ＥｍｂＳｅｃ＞要素に挿入されてもよい。様々な型の署名および署名要素は、本明細書の実施形態に定義されてもおよび／または組み入れられてもよい。例えば、選択的な署名は、メッセージ内で識別されてもよい。実施形態において、選択的な署名は、メッセージ、署名の部分へのレファレンス、署名値などと共に使用されるキーを規定してもよい。選択的な署名は、さらに中間の要約の利用なしで直接暗号化することができるアルゴリズムスイート、外部トークン参照および署名値を含んでもよい。表６は、署名または選択的な署名を識別するために使用することができる署名要素例を提供する。
【００３９】
［表６］
署名要素例
<C:Sig
U:Id="xs:ID"
Alg="xs:anyURT"?
Key="xs:ID"?
EKey="xs:ID"?
Dec="xs:Boolean"? 
AEL="xs:ID List"? 
SEL="xs:ID List"? 
PEL="xs:ID List"? 
Usg="xs:anyURIList"?
…>
<C :SigVal>xs:base64</C:SigVal>
…
</C:Sig>
/C:Sig
署名要素。
/C:Sig/@U:Id
署名のために必要な識別名。次の共同署名が可能なように全ての署名はＩＤを有する。
/C:Sig/@Alg
署名の計算のための使用するアルゴリズムスイートを識別するオプションのＵＲＩ。存在しない場合、この値はこのドキュメントの範囲外のメカニズムを使用して、両方のパーティによって識別されており一致しなければならない。セクション２．２において記載されていた表からの値が使用されてもよい。
/C:Sig/@Key
署名を計算するために使用されるトークンまたはトークンレファレンスへのオプションのＩＤレファレンス。
/C:Sig/@Ekey
署名値を暗号化するために使用されるトークンまたはトークンレファレンスへのオプションのＩＤレファレンス。
/C:Sig/@Dec
署名においてＸＭＬ宣言を含むべきかどうかを指定するオプションの属性。この属性は「偽（ｆａｌｓｅ）」のデフォルト値を有する。
/C:Sig/@AEL
署名（レベルによる）において含める上位要素宣言の数を規定するオプションの属性。この属性にはデフォルト値がない。
/C:Sig/@SEL
署名において含めるべき署名の要素に関する兄弟要素の「ＩＤ」レファレンスのリストを含むオプションの属性。この属性にはデフォルト値がない。
/C:Sig/@PEL
署名において含めるべき署名の要素の親要素に関する兄弟要素の「ＩＤ」レファレンスのリストを含んでいるオプションの属性。この属性にはデフォルト値がない。
/C:Sig/@Usg
署名が含まれる理由をレファレンスが示す絶対的なＵＲＩのリストを含むオプションの属性。本明細書は事前ＵＲＩ値を規定しない。ＷＳ−Ｓｅｃｕｒｉｔｙ＠Ｕｓａｇｅの属性のための規定された任意の値はここで使用されてもよい。
/C:Sig/@{any}
これは、付加的な属性が指定されることを可能にする（署名されるだろう）展開性ポイントである。処理モデルを詰め込む、またはセマンティックスをこのドキュメントにおいて記載されていた以外のものにする属性は、ここで配置することができない。
/C:Sig/C:SigVal
計算された署名値をコード化したベース−６４を含む必要なサブエレメント。
/C:Sig/{any}
これは指定されるために署名される必要のある追加要素を可能にする展開性ポイントである。処理モデルを詰め込むか、セマンティックスをこのドキュメントにおいて記載されていた以外のものにする要素は、ここで配置することができない。
【００４０】
他の実施形態において、共同署名がメッセージに追加されてもよい。実施形態において、共同署名は一次署名上に生成される署名である。一次署名が文脈情報を提供するので、共同署名は文脈情報を含む必要はない。署名および選択的な署名と同様に、共同署名も、署名要素の利用によって示されてもよい。但し、実施形態において、特定の署名要素は共同署名を示すために生成されてもよい。表７は、その属性の議論だけでなく共同署名要素例も提供する。
【００４１】
［表７］
共同署名要素例
<C:CoSig
Alg="xs:anyURT"? 
Key="xs:ID"? 
EKey="xs:ID"? 
SEL="xs:ID List"? 
Usg="xs :anyURT"?
…> 
<C:SigVa\>xs:base64</C:SigVal>
…
</C:CoSig>
/C:CoSig
共同署名要素。
/C:CoSig/@Alg
署名の計算のために使用するアルゴリズムスイートを識別するオプションのＵＲＩ。この属性にはデフォルト値がない。存在しない場合、この値はこのドキュメントの範囲外のメカニズムを使用して、両方のパーティによって識別されており一致しなければならない。セクション２．２において記載されていた表からの値が使用されてもよい。
/C:CoSig/@Key
署名を計算するために使用されるトークンまたはトークンレファレンスへのオプションのＩＤレファレンス。
/C:CoSig/@Ekey
署名値を暗号化するために使用されるトークンまたはトークンレファレンスへのオプションのＩＤレファレンス。
/C:CoSig/@SEL
署名において含めるべき署名要素に関する兄弟要素の「ＩＤ」レファレンスのリストを含むオプションの属性。この属性にはデフォルト値がない。この属性は、＜Ｃ：Ｓｉｇ＞要素への少なくとも１つのレファレンスを有するべきである。
/C:CoSig/@Usg
署名が含まれる理由をレファレンスが示す絶対的なＵＲＩレファレンスのリストを含むオプションの属性。本明細書は事前にＵＲＩ値を規定しない。ＷＳ−Ｓｅｃｕｒｉｔｙ＠Ｕｓａｇｅの属性のための規定された任意の値はここで使用されてもよい。
/C:CoSig/@{any}
これは、付加的な属性が指定されることを可能にする（署名されるだろう）展開性ポイントである。処理モデルを詰め込む、またはセマンティックスをこのドキュメントにおいて記載されていた以外のものにする属性は、ここで配置することができない。
/C:CoSig/C:SigVal
計算された署名値をコード化するベース−６４を含む必要なサブエレメント。
/C:CoSig/{any}
これは指定されるために署名される必要のある追加要素を可能にする展開性ポイントである。処理モデルを詰め込むか、セマンティックスをこのドキュメントにおいて記載されていた以外のものにする要素は、ここで配置することができない。
【００４２】
さらなる実施形態において、包まれた署名は、メッセージに追加されてもよい。実施形態において、包まれた署名は、包まれた署名を即先行するメッセージの任意の一部により開始して、メッセージ全体に署名するために使用されてもよい。（例えば、署名は全体のメッセージを覆うおよび／またはカバーするために使用される）。例えば、マークアップ言語（例えばＸＭＬ、ＨＴＭＬ、など）において使用される包まれた署名は、包まれた署名の上の指定レベルで上位要素を含むメッセージ全体をカバーしてもよい。他の実施形態において、包まれた署名は、メッセージの一部のみをカバーしてもよい。署名および共同署名と同様に、包まれた署名の要素は、署名の要素を使用して、メッセージ内に示されてもよい。表８は、本明細書の実施形態と共に使用されてもよい包まれた署名要素および属性の例を提供する。
【００４３】
［表８］
包まれた署名要素例
<C:EnvSig
Mg="xs:anyURT"? >
Key="xs:ID"?
Ekey="xs:ID"? 
Lev="xs:inf"? 
Oec="xs:Boolean"? 
…>
<C :SigVal>xs:base64</C:SigVal>
…
/>
/C:EnvSig
包まれた署名要素。
/C:EnvSig/@Alg
署名の計算のための使用するアルゴリズムスイートを識別するオプションのＵＲＩ。存在しない場合、この値はこのドキュメントの範囲外のメカニズムを使用して、両方のパーティによって識別されており一致しなければならない。セクション２．２において記載されていた表からの値が使用されてもよい。
/C:EnvSig/@Key
署名を計算するために使用されるトークンまたはトークンレファレンスへのオプションのＩＤレファレンス。
/C:EnvSig/@Ekey
署名値を暗号化するために使用されるトークンまたはトークンレファレンスへのオプションのＩＤレファレンス。
/C:EnvSig/@Lev
署名の計算が開始するべきこの＜Ｃ：ＥｎｖＳｉｇ＞要素に関連する祖先（親）軸をレベルアップする数を記述するオプションの属性。包まれた署名は、この属性およびそのコンテンツのすべてによって識別された要素をカバーするだろう。この属性にはデフォルト値がない。存在しない場合、この値はこのドキュメントの範囲外のメカニズムを使用して、両方のパーティによって識別されており一致しなければならない。
/C:Sig/@Dec
署名においてＸＭＬ宣言を含むべきかどうかを指定するオプションの属性。この属性は「偽（ｆａｌｓｅ）」のデフォルト値を有する。
/C:EnvSig/@{any}
これは、付加的な属性が指定されることを可能にする（署名されるだろう）展開性ポイントである。処理モデルを詰め込む、またはセマンティックスをこのドキュメントにおいて記載されていた以外のものにする属性は、ここで配置することができない。
/C:EnvSig/C:SigVal
計算された署名値をコード化するベース−６４を含む必要なサブエレメント。
/C:EnvSig/{any}
これは指定されるために署名される必要のある追加要素を可能にする展開性ポイントである。処理モデルを詰め込むか、セマンティックスをこのドキュメントにおいて記載されていた以外のものにする要素は、ここで配置することができない。
【００４４】
包まれた署名は、それらが全体のメッセージを包含してもよいという事実により付加的な利点を提供している。例えば、包まれた署名は、全体のメッセージに＜ＮｅｘｔＨｏｐＳｅｃｕｒｉｔｙ＞要素の正規化要求を適用するために表３の＜ＮｅｘｔＨｏｐＳｅｃｕｒｉｔｙ＞要素と結合してもよい。このように、セキュリティおよび正規化インテントは全体のメッセージのために維持することができる。
【００４５】
表６〜表８が署名の表示を提供するのに使用される署名要素の特定の実施形態を記述している一方で、当業者はメッセージ内の表示を提供する任意の他の手段がステップ２０８の実施形態により利用されてもよいことを認識するであろう。更に、他の実施形態において、署名要素は、署名の表示ではなく、実際の署名を表現するために使用されてもよい。
【００４６】
フローは、メッセージと共に使用される暗号化の表示が提供されるステップ２１０に移る。実施形態において、暗号化は、処理を簡易化し、かつ一般的な暗号化技術でサポートされたオプションの数の制限により、配線サイズを最小化するためにメッセージ内に示されてもよい。実施形態において、使用される暗号化の型は、メッセージ内に明確に明示されてもよい。例えば、メッセージは、メッセージがＡＥＳまたはＤＥＳ暗号化を使用して暗号化されるという表示を含んでいてもよい。したがって、メッセージの受信に際して、受信装置は、その暗号化を決定するメッセージへの最初の処理を行うことなしにメッセージに適用する復号化の型を理解する。これは、受信装置の側のメモリを多く使用せずに済む処理を可能にする。更に、そのような削減は、送信装置と受信装置との間でメッセージを送信する時、使用されるであろう暗号化の型に関して事前同意を確立せずに行なうことができる。実施形態において、暗号化はメッセージ内のプレーンテキストステートメントによって示されてもよい。他の実施形態において、トークンまたはトークンへのレファレンスは、暗号化の型を示すために使用されてもよい。＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素を使用する他の実施形態において、／Ｃ：Ｍａｎｉｆｅｓｔ／＠ＥＫ属性は、暗号化が使用されていることを示すために使用されてもよい。
【００４７】
他の実施形態において、要素は、暗号化を表示するために規定され使用されてもよい。そのような実施形態において、ドキュメントの暗号化された部分を具体的には識別する要素が規定されてもよい。表９は、そのような暗号化基準要素および属性の例を提供する。
【００４８】
［表９］
暗号化基準要素の例
<C:EncRef
Mg="xs:anyURT"? 
Key="xs:ID"? 
SEL="xs:ID List"?
EL="xs:ID List"?
… >
</C:EncRef>
/C:EncRef
暗号化基準要素。
/C:EncRef/@Alg
暗号化の実行のために使用するアルゴリズムスイートを識別するオプションのＵＲＩ。存在しない場合、この値はこのドキュメントの範囲外のメカニズムを使用して、両方のパーティによって識別されており一致しなければならない。セクション２．２において記載されていた表からの値が使用されてもよい。
/C:EncRef/@Key
復号化動作のために使用されたトークンまたはトークンレファレンスへのオプションのＩＤレファレンス。
/C:EncRef/@SEL
暗号化される暗号化基準要素に関する兄弟要素の「ＩＤ」レファレンスのリストを含んでいるオプションの属性。この属性にはデフォルト値がない。
/C:EncRef/@PEL
暗号化される暗号化基準要素の親要素に関する兄弟要素の「ＩＤ」レファレンスのリストを含むオプションの属性。この属性にはデフォルト値がない。
/C:EncRef/@{any}
これは付加的な属性を可能にする展開性ポイントである。
/C:EncRef/{any}
これは追加要素を可能にする展開性ポイントである。
【００４９】
他の実施形態において、メッセージの暗号化コンテンツのために暗号化要素も置換として使用するために規定されてもよい。そのような実施形態において、これらの置換要素はメッセージと共に使用される暗号化の型の表示を提供するためにメッセージへ挿入されてもよい。さらなる実施形態において、要素も、暗号化されたキーを識別するために規定されてもよい。これらの暗号化されたキー要素は、さらにメッセージと共に使用される暗号化の表示として取り扱ってもよい。ステップ２１０は特定の実施形態によって記述されている一方で、当業者は、記述された実施形態が説明の目的のみのためであることを認識するであろう。メッセージと共に使用される一種の暗号化を示す任意の方法は、本明細書の実施形態により実施されてもよい。
【００５０】
フローは、メッセージ特定情報が示される動作２１２に移る。実施形態において、メッセージ特定情報は、セキュリティと関係がある、メッセージ作成時間、メッセージ終了時間、メッセージセッションＩＤ、セキュリティセッションＩＤなどのようなメッセージと関連する任意の型の情報であってもよい。例えば、メッセージ作成時間およびメッセージ終了時間は、メッセージの妥当性を決定するために使用されてもよい。例えば、予定するメッセージの作成時間が知られている場合、既知の作成時間は、受信メッセージが確かに予定するメッセージかどうかを判定するために受信メッセージの作成時間と比較することができる。そのような比較は、中間者攻撃（ｍａｎ  ｉｎ  ｔｈｅ  ｍｉｄｄｌｅ  ｔｙｐｅ  ａｔｔａｃｋｓ）を防ぐのに有用かもしれない。さらに、メッセージ終了時間の介在物は、メッセージが終了時間が経過した廃棄された１つであることを提供することにより、処理およびメモリリソースを保存してもよい。＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素を使用する実施形態において、メッセージ作成時間およびメッセージ終了時間は、／Ｃ：Ｍａｎｉｆｅｓｔ／Ｕ：Ｃｒｅａｔｅｄおよび／Ｃ：Ｍａｎｉｆｅｓｔ／Ｕ：Ｅｘｐｉｒｅｓ属性において示されてもよい。セキュリティセッションＩＤ情報などのような他の型の情報も、＜Ｃ：Ｍａｎｉｆｅｓｔ＞／Ｃ：Ｍａｎｉｆｅｓｔ／＠ＳＩＤ要素内に示されてもよい。
【００５１】
図２の実施形態は、認証情報、プロトコル、アルゴリズム、署名、暗号化およびセッションの多種類を示すための特定方法に関して記述されている一方、当業者は、特定方法がもっぱら記述的な目的のために使用されていることを十分に理解するであろう。本明細書の実施形態は、様々な表示がなされる方法に関係なく動作するであろう。表示がなされる限り、受信する装置および／またはメッセージの処理は、示された情報の型を発見するために典型的には実行されたメッセージ解析の型を無効にすることにより、処理パワーとリソースを保存する。これは、小さなコンピュータ装置が、装置がリソースの不足によりあらかじめ処理することができない異なる型のメッセージを受信し処理することを可能にする。
【００５２】
実施形態において、明確なメッセージは、受信装置に到着する前に１つ以上の媒介装置によって処理されてもよい。この意味で、媒介装置によりメッセージを処理することは、別の媒介装置または受信装置へのメッセージの経路をまさに選択することを含んでもよい。例えば、メッセージがインターネットなどのようなネットワークに亘って送信装置から受信装置に対して通過される場合、受信装置へ向かう途中の多くのサーバおよびルータを、メッセージはたぶん通過するだろう。一般に、これらの媒介装置は、メッセージを処理する場合に、メッセージを追加および／または修正する能力を有している。例えば、媒介装置は、メッセージが送信装置から受信装置までに使用するパスの記録をとるために処理するという任意のメッセージに署名を追加してもよい。但し、明確なメッセージを処理する場合、本明細書の実施形態は、明確なメッセージの保全性が維持されることを提供する。言い換えれば、本明細書の実施形態は、ステップ１０２（図２）でメッセージ内に表現されたセキュリティセマンティックスの集合的なインテントが維持されることを提供する。
【００５３】
実施形態において、セキュリティセマンティックスの集合的なインテントは、明確なメッセージを処理する装置間の直前の一致によって順守される。例えば、装置は直前の一致を確立してもよく、例えばすべての表現されたセキュリティの意図や、＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素に表現されたすべてのセキュリティの表示は、順守され変わらない。別の実施形態において、集合的なインテントへの順守は、明確なメッセージ自体によって強化されてもよい。例えば、明確なメッセージは＜ＮｅｘｔＨｏｐＳｅｃｕｒｉｔｙ＞要素を含んでもよく、図２に関して予め説明されたように、＜ＮｅｘｔＨｏｐＳｅｃｕｒｉｔｙ＞要素またはメッセージ内の他の要素内に表現された正規化と署名の要求を順守するメッセージを処理する媒介装置を全て必要とする。ステップ２０８（図２）で説明されたように、これらの要求は、包まれた署名と共に＜ＮｅｘｔＨｏｐＳｅｃｕｒｉｔｙ＞要素を使用することにより、全体のメッセージに接続されてもよい。本明細書の実施形態は、さらに、以前にメッセージが明確に定義されることを提供し、＜ＮｅｘｔＨｏｐＳｅｃｕｒｉｔｙ＞および＜Ｃ：Ｍａｎｉｆｅｓｔ＞要素などのような、ヘッダ、要素またはコンテンツはメッセージから取り除くことができない。取り除く制約が順守されなければ、メッセージは続いて拒絶され廃棄されるだろう。
【００５４】
図３は、媒介装置によりセキュリティセマンティックスの集合的なインテントを表現する、明確なメッセージを処理する方法３００の実施形態を表現するフローチャートである。媒介または媒介装置は、明確なメッセージがその指定受信者へ向かう途中で通過する装置である。フローは、媒介装置が明確なメッセージを受信するステップ３０２で開始する。この例におけるこのポイントでは、セキュリティセマンティックスの集合的なインテントが、メッセージ内に既に表現されており、それにより、メッセージを明確なメッセージにする。媒介装置は、メッセージを発信した送信装置、または別の媒介装置から明確なメッセージを受信してもよい。フローは、媒介装置が明確なメッセージのセキュリティ要件を処理する動作３０４に移る。実施形態において、明確なメッセージのセキュリティ要件の処理は、明確なメッセージセキュリティセマンティックスの表現された集合的なインテントを決定するために明確なメッセージを解析するまたは閲覧することを含んでもよい。予め言及したように、表現された集合的なインテントは、媒介装置がある作用（例えば追加するコンテンツまたはメッセージへの署名）の実行から制限してもよい。他の実施形態において、表現された集合的なインテントは、メッセージ上で特殊動作を実行するための媒介装置を必要としてもよい。フローは、明確なメッセージの要求を満たすことができるかどうかを媒介装置が判定する判定ステップ３０６に移る。媒介装置が要求を満たすことができない場合、または媒介装置が要求を理解することができない場合、フローは、メッセージが拒絶されるステップ３０８へのＮＯに分岐する。実施形態において、メッセージは、メッセージの連続の伝送により帯域幅または処理リソースを保存するために受信装置上へメッセージを転送せずにステップ３０８で廃棄される。これは、本書明細書の実施形態において、受信装置が図４に関してさらに説明されるように、セキュリティセマンティックスが媒介装置によって順守されていない明確なメッセージを拒絶するだろうという事実による。
【００５５】
媒介装置が明確なメッセージの表現された集合的なインテントを理解し順守することができる場合、フローはステップ３１０へのＹＥＳに分岐する。一旦装置が明確なメッセージ内のセキュリティセマンティックスの集合的なインテントで準拠したならば、媒介装置は、別の媒介装置または受信装置のどちらかへ明確なメッセージを伝送する。メッセージが別の媒介装置に伝送される場合、図３の方法は再び次の媒介装置のために続く。
【００５６】
受信装置による明確なメッセージの受け取りに際して、図４のフローチャートに図示された方法の実施形態が利用されてもよい。フローは、受信装置が明確なメッセージを受信する動作４０２で開始する。受信装置は明確なメッセージの指定受信者である。明確なメッセージの受け取りに際して、フローは、受信装置が明確なメッセージのセキュリティ要件を処理するステップ４０４に移る。図１および２において記載されているように、明確なメッセージのセキュリティ要件が明確に表現されるので、受信装置は従来のメッセージを処理するために必要とされるより少数のリソースを使用して、これらの要件を処理することができる。例えば、受信装置は、単に明確なメッセージ内の公言されたセキュリティセマンティックスの表現された集合的なインテントを理解する必要がある。明確なメッセージからのセキュリティ要件を決定する際、フローは、集合的なインテントのセキュリティ要件が満たされたかどうかに関して判定が下される判定ステップ４０６に移る。要求が満たされていない場合、フローは動作４０８へのＮＯに分岐し、受信装置はメッセージを拒絶する。要求が満たされている場合、フローは、受信装置がメッセージを処理するおよび／または応答することを含んでもよいメッセージを受け取る動作４１０へのＹＥＳに分岐する。
【００５７】
図５は、送信装置５０２から受信装置５０４にセキュリティセマンティックスの集合的なインテントを表現するメッセージの伝送のためのシステム５００の実施形態を図示する機能図である。実施形態において、送信装置５０２は、パーソナルコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、ワークステーション、サーバなどのようなコンピュータ装置であってもよい。さらなる実施形態において、送信装置５０２は、ＰＤＡ、スマートフォン、携帯電話などのような小さなコンピュータ装置であってもよい。実施形態において、受信装置は、ＰＤＡ、スマートフォン、携帯電話などのような小さなコンピュータ装置であってもよい。他の実施形態において、受信装置は、パーソナルコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、ワークステーション、サーバなどであってもよい。
【００５８】
実施形態において、送信装置５０２は、メッセージを生成する。メッセージは、図２において提示された方法により生成されてもよい。実施形態において、送信者装置５０２によって生成されたメッセージは、明確なメッセージであってもよい。そのような実施形態において、メッセージは送信装置５０２から受信装置５０４に送信されてもよい。１つの実施形態において、明確なメッセージは、送信装置５０２と受信装置５０４（図示せず）との間の直接接続を介して伝送されてもよい。他の実施形態において、明確なメッセージは、送信者装置５０２から受信装置５０４にネットワーク５０６を介して送信されてもよい。実施形態において、ネットワーク５０６はインターネットであってもよい。他の実施形態において、ネットワーク５０６は、イントラネット、エクストラネット、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、公衆交換電話網、セルラネットワーク、無線ＬＡＮ、無線の都市内ネットワーク（ＭＡＮ）、または装置間でメッセージを伝送することができる任意の他の型のネットワークなどのような別の型のネットワークであってもよい。
【００５９】
実施形態において、送信装置５０２と受信装置５０４との間を通過したメッセージは、通過してもよいおよび／または１つ以上の媒介装置５０８によって処理されてもよい。実施形態において、媒介装置５０８は、サーバ、ネットワークサーバ、ゲートウェイサーバ、パーソナルコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、ワークステーションまたはメッセージを受信および伝送することができる任意の他の型のコンピュータ装置であってもよい。１つ以上の中間装置５０８が明確なメッセージを受信する実施形態において、媒介装置は図３において提示された方法によりメッセージを処理してもよい。媒介装置５０８が表現された集合的なインテントを理解しない、または順守することができない場合、明確なメッセージは廃棄される。媒介装置５０８が明確なメッセージの表現された集合的なインテントを理解し順守することができる場合、媒介装置５０８は、別の媒介装置５０８または受信装置５０４のいずれかにメッセージを転送する。受信装置５０４による明確なメッセージの受け取りに際して、受信装置５０４は、図４に関して記述された方法による明確なメッセージを受け取るべきか拒絶するべきかを判定してもよい。他の実施形態において、受信装置は、明確なメッセージを受け取るべきか拒絶するべきかを判定するために当業で知られた他の方法を利用してもよい。
【００６０】
代替の実施形態において、送信者装置５０２は、明確なメッセージではないメッセージを生成してもよい。そのような実施形態において、送信装置５０２によって生成されたメッセージは、受信装置５０４へ向かう途中の１つ以上の媒介装置５０８に伝送されてもよい。そのような実施形態において、図２に関して記述されるように、１つ以上の媒介装置の１つは、メッセージ内のセキュリティ情報の表示の提供によりメッセージを修正してもよい。一旦、セキュリティメッセージの表示がメッセージに関連付けられれば、装置を処理する他のすべての媒介装置５０８が、明確なメッセージ内のセキュリティセマンティックスの表現された集合的なインテントに順守するに違いない時機を見計らう際に、メッセージは明確なメッセージになる。この実施形態から、メッセージがセキュリティセマンティックスの明白な意図を示すように、送信装置５０２以外の装置がメッセージを修正してもよいことは明らかになる。
【００６１】
図６に関連して、本明細書に記述された様々な実施形態を実施するためのコンピュータ環境の実施形態は、コンピュータシステム６００などのようなコンピュータシステムを含む。記述された実施形態のあらゆるコンポーネントは、クライアントコンピュータシステム、サーバコンピュータシステム、クライアントとサーバコンピュータシステムとの組み合わせ、ハンドヘルド装置および他の可能なコンピュータ環境または本明細書で記述したシステム上でまたはとして、実行してもよい。そのため、これらのすべての環境に適用可能な基本的なコンピュータシステムは以下に記述される。
【００６２】
そのほとんどの基本構成において、コンピュータシステム６００は、少なくとも１つの処理装置またはプロセッサ６０４およびシステムメモリ６０６を含む。コンピュータシステム６００の最も基本的な構成は、破線６０２によって図８で示される。ある実施形態において、記述されたシステムの１つ以上のコンポーネントは、システムメモリ６０６にロードされ、システムメモリ６０６からの処理装置６０４によって実行される。コンピュータシステム６００の正確な構成および型によって、システムメモリ６０６は、不揮発性（ＲＯＭ、フラッシュメモリ、などのように）、揮発性（ＲＡＭなどのように）、または２つのいくつかの組み合わせであってもよい。
【００６３】
また、コンピュータシステム６００には、さらに追加機構／機能性があってもよい。例えば、コンピュータシステム６００は、磁気または光ディスクまたはテープを含む（しかし限定的ではない）リムーバブルおよび／または非リムーバブルストレージなどのような追加記憶媒体６０８を含む。ある実施形態において、ソフトウェアまたは実行可能コード、および記述されたシステムのために使用される任意のデータが、記憶媒体６０８において永続的に格納される。記憶媒体６０８は、揮発性、不揮発性、コンピュータ読取り可能な命令などのような情報の記憶のための任意の方法または技術で実施されたリムーバブルおよび非リムーバブル媒体、データ構造、プログラムモジュールまたは他のデータを含む。実施形態において、マンモグラム画像および／または確率判定の結果は、記憶媒体６０８において格納される。
【００６４】
システムメモリ６０６および記憶媒体６０８は、コンピュータ記憶媒体の例である。コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（ディジタルバーサタイルディスク）または他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、他の磁気記憶装置、または所望の情報を格納するために使用され、コンピュータシステム６００およびプロセッサ６０４によってアクセスされる他の媒体を含むが、限定的でない。任意のそのようなコンピュータ記憶媒体もコンピュータシステム６００の一部であってもよい。ある実施形態において、マンモグラム画像および／または確率判定の結果は、システムメモリ６０６において格納される。実施形態において、明確なメッセージを生成する、セキュリティセマンティックスの集合的なインテントを表現する、明確なメッセージなどを受け取りおよび／または拒絶するなどのような、本明細書に開示した方法を実行するまたはシステムを形成するために使用されるデータは、システムメモリ６０６および／または記憶媒体６０８が格納する。実施形態において、システムメモリ６０６は、メッセージデータ６１４および生成命令６１６などのような情報を格納するだろう。実施形態において、メッセージデータ６１４は、メッセージ本文、メッセージのセキュリティセマンティックス、メッセージ上で使用される暗号アルゴリズム、メッセージによって使用されるプロトコル、メッセージ署名などに関連するデータなどのようなメッセージを生成するために使用されるデータを含むかもしれない。実施形態において、生成命令６１６は、メッセージを生成するおよび／または開示された方法およびシステムを実行するために必要な命令を格納する。例えば、アプリケーションデータ６１６は、メッセージを生成して、メッセージのためのセキュリティセマンティックスの集合的なインテントの表現を生成して、メッセージを処理するなどのための機能または処理を含んでもよい。
【００６５】
コンピュータシステム６００は、さらに装置が他の装置と共に通信することを可能にする通信接続６１０を含んでいてもよい。実施形態において、通信接続６１０は、送信装置と媒介装置および受信装置との間のメッセージを送受信するために使用されてもよい。通信接続６１０は、通信媒体の一例である。通信媒体は、キャリア波または他の移送機構などのように、変調データ信号を具体化し任意の情報配送メディアも含み、それはコンピュータ読取り可能な命令、データ構造、プログラムモジュールまたは変調データ信号の他のデータを具体化してもよい。用語「変調データ信号」は、データ信号内の情報またはメッセージをエンコードするような方式で設定または変更される、１つ以上の特性を有する信号を意味する。限定ではなく具体例として、通信媒体は、有線ネットワークまたはダイレクトな有線接続などのような有線の媒体、および吸音、ＲＦ、赤外線、他の無線媒体などのような無線媒体を含む。実施形態において、マンモグラム画像または確率結果の判定は、通信接続６１０を通して伝送されてもよい。
【００６６】
ある実施形態において、コンピュータシステム６００は、入出力接続６１２、およびグラフィカルユーザインタフェースなどのようなインタフェースおよび周辺機器をさらに含む。入力装置もユーザインタフェースセレクション装置と呼ばれ、キーボード、マウス、ペン、音声入力デバイス、タッチ入力装置などを含むが、限定的ではない。出力装置もディスプレイと呼ばれ、ブラウン管ディスプレイ、プラズマスクリーンディスプレイ、液晶スクリーンディスプレイ、スピーカ、プリンタなどを含むが、限定的ではない。入出力接続６１２に接続されたこれらの装置のいずれか個々にまたは組み合わせは、本明細書に記述されたように情報を表示するために使用される。これらの装置はすべて当業においてよく知られていて、ここで詳細に説明する必要はない。
【００６７】
ある実施形態において、本明細書に記述されたコンポーネントは、コンピュータ記憶媒体および他の有形的表現媒体上に格納され通信媒体で伝送されてもよいコンピュータシステム６００により実行可能なモジュールまたは命令実行可能ファイルを含む。コンピュータ記憶媒体は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュールまたは他のデータなどのような情報を記憶するための任意の方法または技術で実装された、揮発性、不揮発性、リムーバブル・非リムーバブル媒体を含む。上述のいかなるものの組み合わせでも、読み取り可能な媒体の範囲内に含まれるべきである。ある実施形態において、コンピュータシステム６００は、コンピュータシステム６００による利用のためのリモート記憶媒体においてデータを格納するネットワークの一部である。
【００６８】
この明細書の情報は、可能な実施形態のいくつかのみが表示された添付の図面に関連して、本明細書のある実施形態を記述した。但し、ここに述べられた実施形態に限定されたように、他の態様は様々な形式で具体化され解釈されるべきでない。むしろ、この明細書の情報が、充分で、完結し、当業者に可能な実施形態の範囲を十分に伝えたように、これらの実施形態は提供された。
【００６９】
実施形態は、構造的特徴、方法論の作用、およびそのような作用を含んでいるコンピュータ読み取り可能な媒体に特有の言語において記載されているが、可能な実施形態が、添付された請求項において規定されたように、特定構造、作用または記述された媒体に必ずしも限定されていないことは理解されるべきである。当業者は、本明細書の範囲や精神にある他の実施形態または改良を認識するであろう。したがって、特定構造、作用または媒体は、例示の実施形態としてのみ開示される。本明細書の情報は、添付された請求項によって規定される。
【図１】
2011519190.tif 000003
【図２】
2011519190.tif 000004
【図３】
2011519190.tif 000005
【図４】
2011519190.tif 000006
【図５】
2011519190.tif 000007
【図６】
2011519190.tif 000008
【国際調査報告】
2011519190.tif 000009
2011519190.tif 000010