JP2007200316A - ネットワーク通信システムおよびネットワーク・サーバとクライアント・デバイスの間に、コンピュータネットワークを通じてセキュアな通信リンクを確立する方法 - Google Patents

Abstract

【課題】既存のインターネット通信プロトコルとの互換性を持ちながら、セキュアなネットワーク接続およびネットワーク送信を確立するネットワーク通信システムおよびネットワーク通信方法を提供すること。
【解決手段】セキュアなネットワーク接続が、３つの認証ルーチンを必要とする。システム・アクセス認証ルーチンは、クライアント・ネットワーク・デバイスが、ネットワーク・サーバにユーザ認証情報を提示することを必要とする。ユーザ認証の成功に基づいて、ネットワーク・サーバが、クライアント・サービス・アクセス・パスを生成して、このパスを、クライアント・デバイスに送信される動的ウェブ・ページに組み込む。
【選択図】図２

Description

本発明は、ネットワーク・アクセス・セキュリティの分野を対象とするものである。詳細には、本発明は、公衆網を通じてネットワーク・アクセスを形成する場合のセキュリティの改良に向けられたものである。

以前には、ネットワーク・セキュリティは、比較的直接的であった。人は、個別の私的ネットワークを維持し、そして、誰が、その私的ネットワークにアクセスすることができるか、また、どのような権限が、その私的ネットワークにログオンするクライアント・デバイスに許諾されるのかに関して、完全に制御していた。しかしながら、公衆インターネットの成長とともに、特に、私的イントラネット、即ち、私的ネットワークが、公衆インターネットにリンクされるときには、セキュリティは、はるかに複雑になっている。

ワールド・ワイド・ウェブ（以下、ウェブと言う）は、データ公開の便利で、安価で、迅速な手段を提供する。これは、自社の私的イントラネット上のデータベースを選択するためにウェブ・アクセスを設けている企業にとって、大きな魅力となっている。しかしながら、情報がウェブ上に撒き散らされる、この極端な容易さは、同時に、情報が、その情報にアクセスする権利を持つ人々によってしかアクセス可能でないことを確実にすることが重要であることを意味する。

以前には、特殊なクライアント・ソフトウェアが、イントラネット上の情報にアクセスするために必要とされた。今では、ウェブ・ブラウザを持つ誰もが、インターネットにリンクしたデータベース内のデータを、それが適切に保護されていなければ、見ることができる。ウェブ・サーバが、内部データベースからのデータを持つウェブ・ページの動的生成を行えば、脆弱な箇所の数は、さらに増加する。

通常、ウェブ・セキュリティは、３つのカテゴリ：サーバ・セキュリティ、即ち、サーバ上に格納されているデータおよび／またはウェブ・ページの保護；ユーザ認証、即ち、情報への未承認のアクセスの防止（通常、ログオン・セキュリティを通じて）；セッション・セキュリティ、即ち、インターネットを通じて送信されるデータの保護、に分類される。

サーバ・セキュリティ、即ち、サーバ上のデータの保護は、データが分散している方法に依存して、いくつかの形態をとる。サーバが、静的ウェブ・ページ〔即ち、以前にデータベース情報から生成されて、サーバ上に静的に格納されている静的ＨＴＭＬ（HyperText Markup Language：ハイパーテキスト・マークアップ言語）ファイル〕だけしか備えていない場合には、ディレクトリ閲覧の制限によって、基本的な保護を得ることができる。ＦＴＰ（File Transfer Protocol：ファイル転送プロトコル）およびウェブ・サーバは、通常、ディレクトリを、そのなかに格納されているファイルを読むことはできるが、それらのファイルをディレクトリ内容のリスト内には示さないように設定しておく。それでもなお、ファイルの正確な名前を知っている誰もが、依然として、それに直接アクセスすることができる。さらに、ディレクトリとファイル属性との使用のように、オペレーティング・システムの統合システム・セキュリティを用いてディレクトリを保護することもできる。

しかしながら、動的ページ作成の使用のますますの増加が、さらなるセキュリティ・リスクを生み出している。情報に対する照会が受信されるように、情報データベースへの直接アクセスを用いているウェブ・サーバによって、動的ページが、活発に作成されている。通常、動的ウェブ・ページは、ＨＴＭＬコードのテンプレートおよびクエリとしてサーバ上に格納される。クライアントが、そのページにアクセスすると、クエリが、実行され、適した情報が、データベースから抽出され、そして、テンプレート・スロットに入れられている所望のデータを含むＨＴＭＬページが、作成される。これは、ウェブ・サーバ上の少なくともただ１つのデータソースに、データベースに対する広いアクセス能力を与えなければならないことを意味する。

さらに、動的ウェブ・ページを作成するツールは、サーバベースのミドルウェア、または、より一般には、ＣＧＩ（即ち、Common Gate Interface：共通ゲート・インターフェイス）スクリプトである。これに伴うトラブルは、その１つのデータソースにアクセスするサーバに、ＣＧＩスクリプトのような実行可能なスクリプトをアップロードすることができる人なら誰でも、そのデータベースに完全にアクセスして、悪意のあるプログラムを実行することができるということである。さらに、そのデータベースとインターフェイスするサーバ上のデータソースを、他の独立したプログラム（ＣＧＩスクリプト以外の）が、支配して、それによって、そのデータにアクセスすることになりかねない。したがって、誰が、サーバへのアクセスを得ることができるかに関する制御が、最高に重要であり、それは、ユーザ認証の問題につながる。

ユーザ認証セキュリティは、基本的に、ユーザが、特定の情報へのアクセスまたは特権を得る前に、通過しなければならないバリアを形成する。ユーザ認証を検証する最も一般的な方法は、ログイン・ウィンドウのような識別シーケンスの検証によるものである。ログイン操作は、通常、ＨＴＭＬ形式を用いて、または、ＨＴＴＰ（HyperText Transfer Protocol：ハイパーテキスト転送プロトコル）セキュリティ要求を用いて行われる。ＨＴＭＬログイン・ページは、単純に、ユーザ名およびパスワードのフィールドを含むＨＴＭＬフォーム・ページである。実際の識別名およびパスワードが、サーバ上のテーブルに格納される。この情報は、通常、ユーザ識別データベースの検索のために、ＣＧＩスクリプト、または、他のタイプのデータベース・ミドルウェアを通じてサーバにもたらされる。通常、一旦、ログインが発生すると、ユーザ接続セッションを追跡するための「クッキー」が、クライアント・マシン上に書き込まれる。

クッキーは、通常、ウェブ・ブラウザ・ソフトウェアが格納されるディレクトリの、あらかじめ定められた上位に格納される、基本的にテキスト・ファイルである。クッキーは、ある寿命を割り当てられ、その寿命が切れてしまうまで、クライアント・マシン上に格納され続ける。この寿命は、有限の期間を持ってもよく、または、ユーザ・セッションが終了したときに過ぎ去るのでもよい。ウェブ・ブラウザは、標準ＨＴＴＰ通信プロトコルを用いてイントラネットをナビゲートし、また、したがって、各メッセージは、ヘッダ部と、それに続くボディ部とを持つデータ・パケットで送られる。ボディ部は、ユーザが送信しようとしている実際のデータを保持し、一方、ヘッダ部は、送り手と受け手が、互いを知り、受信した情報を体系付け、エラーを回復する、などに必要な情報を保つ記録を保持する。即ち、ヘッダは、何よりも、送り手のアドレス、あて先のアドレス、何らかのエラー回復コード情報、送信されるデータ・パケットのシーケンスを識別するシーケンス情報、および、他のあらかじめ定められたテキスト情報を含んでいる。

このヘッダ・テキスト情報に混じって、ウェブ・ブラウザ・ソフトウェアが、クッキーを含んでいる。サーバが、クライアントにクッキーを送信することによって、クライアントに応答すると、そのクッキーが、クライアント・マシンに格納される。クライアントのウェブ・ブラウザが、特定のウェブ・サーバと交信するごとに、そのウェブ・ブラウザは、その特定のウェブ・サーバが、クライアント・マシン内に格納されているいずれかのクッキーを持っているか否かを決定し、持っている場合には、そのクッキーが、その特定のウェブ・サーバに送信されるヘッダ情報に含められる。より具体的に言うと、クッキーは、名前、値、ドメイン、およびパスを持つ。あるＵＲＬ（Uniform Resource Locator）が、あるクッキーのパスに沿った任意のファイルにアクセスするために、そのクッキーのドメインに送られた場合は常に、そのクッキーの名前および値が、そのＵＲＬが開かれているサーバに渡される。

突き詰めると、クライアントとサーバの間のすべてのＨＴＴＰベースのインタラクションは、要求に関する情報（通信がクライアントからサーバに対するものであるとき）、または、応答に関する情報（通信がサーバからクライアンに対するものであるとき）が入っているヘッダを含んでいる。サーバが、要求を受信する場合、そのヘッダは、要求タイプ（例えば、ＧＥＴまたはＰＯＳＴ）、および、そのサーバによってクライアント・マシンに以前に格納されているクッキーのような情報を含んでいる。サーバが、その応答を処方する場合、そのヘッダ情報は、そのサーバがクライアントのコンピュータに格納させたい、いかなる追加のクッキーでも含んでいる。クライアントのウェブ・ブラウザが、サーバに要求を行うとき、そのサーバによってクライアントに以前に送られたクッキーが、そのウェブ・ブラウザによって処方された要求の一部としてサーバに返送される。例えば、ウェブ・ブラウザＮｅｔｓｃａｐｅ（登録商標）は、サーバにクッキー名−値ペアを渡すために用いられる「Cookie（クッキー）」と呼ばれる要求ヘッダ・タグを定めており、サーバは、その応答ヘッダで「Set Cookie（クッキーをセット）」タグを送ることによって、ブラウザ中にクッキー値をセットすることができる。クッキーは、ＨＴＴＰ標準の一部であるから、確定されたネットワーク・ソケットでＨＴＴＰプロトコルを通してしか送信されないことは、強調していいであろう。

クッキーは、「shopping cart（買い物かご）」の内容、以前の購入、以前に見た品目などを追跡して、クライアントに追加の検討品目を、より適切に提示するために、オンライン・ショッピングのような非セキュリティ関連活動に用いることができる。しかしながら、認証セキュリティのフィールドで用いられるときには、クッキーは、通常、ユーザ認証ＩＤ（Identification Data：識別データ）／パスワード・シーケンスを繰り返さないようにするために、また、ウェブ・ブラウザに、開かれているセッションをモニタするための手段を与えるために、クライアント・ウェブ・ブラウザが、そのセッションが開かれている間に、ウェブ・サーバに提示するテキスト・アクセス・コードである。

特許文献１は、このタイプの認証セキュリティを行う。ユーザ・クライアントが、最初に、ユーザ認証シーケンスを受け、一旦、ウェブ・サーバによって認証されると、そのウェブ・サーバが、承認されたユーザによって現在用いられているクライアント・マシンに、環境情報を要求する。環境情報は、クライアント・マシンのハードウェア設定のようなマシン固有情報の形態をしている。次いで、ウェブ・サーバが、クライアント・マシン環境情報を、ハッシュ・コードのベースとして用いて、クライアント・マシンのアクセスコードを作成し、その後、それを、クッキーとしてクライアント・デバイスに送る。当技術分野において公知のように、ハッシュ・コードは、任意のデータに、ある数学関数、即ち、ハッシュ・アルゴリズムを適用することによって得られるコード化シーケンスである。そのアクセスコードは、特定のクライアント・マシンに結び付いているから、このユーザ認証シーケンスは、複数の人間が異なるマシンから、そのウェブ・サーバに同時にログオンすることを防止する。これは、当然、ユーザのマシンの能力に関するプライバシーの問題を提起し、特許文献１は、クライアント・マシンの環境情報を、ウェブ・サーバに送信するに先立ってコード化してもよいことを提案することによって、この課題に対処している。さらなるセキュリティとして、特許文献１は、ウェブ・サーバまたは他のプロキシ・ウェブ・サーバが、次回のウェブ・アクセス中に、同じ環境情報を用いて、アクセスコード・クッキーを任意選択にリハッシュしてもよいことを提案している。

特許文献１は、ただ１つのＩＤ／パスワード組み合わせが、複数のマシンからの複数のログイン・セッションに用いられることを防止するのに役立つが、それは、同一のマシンを通じての複数のログイン・セッションを防止しない。さらに、アクセスコードが、クッキーとしてクライアント・デバイスに格納されるから、そのアクセスコードは、クライアント・マシン内の、クッキーのあらかじめ定められたディレクトリに簡単に置かれたテキスト・ファイルである。さらに、ウェブ上の送信は、一方向、即ち、送り手から受け手に対してであるように見えるかもしれないが、ネットワーク送信は、全てのネットワーク・ノードへの事実上のブロードキャストであり、そして、通信プロトコルは、ブロードキャスト・データ・パケットの指名されたアドレスしか、その送信を開かないことを期待しているということにも注意しなければならない。しかしながら、いかなる数のネットワーク監視ソフトウェアでも、これらのブロードキャスト送信を捕獲して、そのクッキー・アクセスコードを容易に抽出することができる。

ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol：伝送制御プロトコル／インターネット・プロトコル）、即ち、インターネット通信プロトコルは、セキュリティに向けて設計されなかったから、それは、実際に極めてセキュアでなく、ウェブ・データ送信が、ウェブ・セッション接続中に傍受されたり、妨害されたりしないことを確実にするための、付加的なステップを取らなければならない。これは、通常、データ送信の暗号化を通して行われ、それは、セッション・セキュリティの問題につながる。

セッション・セキュリティ、即ち、データがネットワーク（即ち、インターネット）上をブロードキャストしているときのデータ傍受の防止は、通常、セキュア・ソケット・レイヤ（ＳＳＬ）プロトコルの使用によって維持されており、そのプロトコルは、通常、「ＨＴＴＰＳ（HTTP Security）」として、接尾文字「Ｓ」を加えることによって基本「ＨＴＴＰ」アドレスと区別される。ＳＳＬプロトコルは、ほとんどのウェブ・ブラウザ・ソフトウェア企業間の協定によって支持されており、暗号化キーを交換して、暗号化された接続を生成するために接続を確立するときにハンドシェークを用いる。ＨＴＴＰＳウェブサイトは、公開／秘密キー・システムを用いて、クライアントとウェブ・サーバの間のデータ送信を暗号化し、したがって、信頼できるソースによって作成された私有キー（秘密キー）および公開キーの使用を必要とする。インターネット・ブロードキャストのために、これらのキーは、通常、ベリサイン（VeriSign）社のような若干の企業によって、手数料を徴収して供給されている。ＳＳＬは、データ送信のセキュリティを改善するが、ユーザ認証を供給しない。したがって、所望のサイトのＨＴＴＰＳ ＵＲＬを知っている誰もが、依然として、データ・ファイルをアップロードし、また、ダウンロードすることができる。

必要なものは、公に広く知られており、したがって、攻撃を受けやすい、標準的なＨＴＭＬプロトコルに頼らないで、インターネット・ネットワーク通信にセキュリティを付加するネットワーク通信システムである。しかしながら、その必要とされるネットワーク通信システムは、インターネット・アクセスを維持するために、依然として、標準的なインターネット通信プロトコルと互換性をもたなければならない。

米国特許出願公開第２００２／０１６９９６１号明細書

本発明の１つの目的は、セキュアなネットワーク接続およびネットワーク送信を確立するネットワーク通信システムおよびネットワーク通信方法を提供することである。

さらなる１つの目的は、そのネットワーク通信システムが、既存のインターネット通信プロトコルと互換性を持つことである。

本目的は、求めているクライアントにネットワーク・アクセスを選択的に供給するためのネットワーク・サーバと、前記ネットワーク・サーバと交信して、ネットワーク・アクセスを求めるためのクライアント・デバイスと、を備えてなるネットワーク通信システムであって、前記ネットワーク・サーバが、前記クライアント・デバイスに認証情報を要求することと、実行可能なルーチンの内部の第１の発行キーコードとして、前記クライアント・デバイスに送信される第１のアクセス・キーコードを作成することにより、前記クライアント・デバイスからの、検証された認証情報の受信に応答することと、によって、ネットワーク・アクセスを求めている前記クライアント・デバイスに応答するように設定されているネットワーク通信システムにおいて達成される。前記実行可能なルーチンが、前記クライアント・デバイス上のクライアント・アプリケーションを作動させ、そして、前記作動したクライアント・アプリケーションに、前記第１の発行キーコードを渡すのに有効である。その後、前記クライアント・アプリケーションが、前記第１の発行キーコードを、第１の返送キーコードとして、通信セッションの確立の要求とともに、前記ネットワーク・サーバに送信する。前記ネットワーク・サーバが、前記第１のアクセス・キーコードを無効化し、前記クライアント・アプリケーションとの通信セッションを確立し、前記クライアント・デバイスとのドキュメント通信のためのドキュメント・チャネルを確立し、前記第１のアクセス・キーコードと無関係な第２のアクセス・キーコードを作成し、そして、前記第２のアクセス・キーコードを、第２の発行キーコードとして、前記ドキュメント・チャネルを介して前記クライアント・アプリケーションに送信することによって、前記第１の発行キーコードに一致する前記第１の返送キーコードに応答する。

前記ネットワーク・サーバと前記クライアント・デバイスが、インターネットを通じて通信し、そして、前記実行可能なルーチンが、動的ウェブ・ページであるのが好ましい。さらに、前記クライアント・アプリケーションが、前記クライアント・デバイス上のいずれのインターネット・ブラウザ・アプリケーションからも独立しているのが好ましい。例えば、クライアント・アプリケーションは、セルフスタンディング（self-standing）ＪＡＶＡ（登録商標）アプリケーションであってもよい。さらに、前記第１のアクセス・キーコードが、前記クライアント・デバイスと無関係であるのが好ましく、および／または、前記第２のアクセス・キーコードが、前記第１のアクセス・キーコードと無関係である。

好適な一実施例において、前記クライアント・デバイスから前記ネットワーク・サーバへの全てのドキュメント提示およびドキュメント要求は、前記クライアント・デバイスが、現在の返送キーコードとして、前記ネットワーク・サーバから最も最近に受信した前記発行キーコードを提示することを必要とする。前記クライアント・デバイスからの各ドキュメント提示およびドキュメント要求を受信して、前記クライアント・デバイスによって提示された前記現在の返送アクセス・キーコードが、前記ネットワーク・サーバによって前記クライアント・デバイスに発行された、最も最近の発行キーコードと一致すれば、前記ネットワーク・サーバが、前記提示されたドキュメントまたは提示されたドキュメント要求を受け取り、新しいアクセス・キーコードを作成し、そして、前記新しく作成されたアクセス・キーコードを、現在の発行キーコードとして、前記クライアント・アプリケーションに送信する。

本発明の好適な一実施例において、ネットワーク・サーバによって作成された、それらのアクセス・キーコードのいずれもが、互いに無関係である。

本発明の一代替実施例において、前記クライアント・デバイスが、前記クライアント・デバイスに対して外部のメモリ・クエリによって直接アクセス可能な、少なくとも１つのあらかじめ定められたアーカイブ・メモリ空間を持ち、そして、前記クライアント・アプリケーションによって受信された各発行キーコードが、前記クライアント・デバイスの揮発性メモリ内に存在するアクティブなパラメータとして保持され、いかなるあらかじめ定められたアーカイブ・メモリ空間にも位置せず、そして、前記クライアント・アプリケーションの終了と同時に無効化される。より詳細には、前記クライアント・アプリケーションによって受信された各発行キーコードが、前記クライアント・デバイスの中央コントローラ部内の一時レジスタのエントリとして保持され、そして、前記クライアント・デバイスのいかなる不揮発性の、またはアーカイブなメモリにも転送されないのが好ましい。

前記ネットワーク・サーバと前記クライアント・デバイスの間の送信が、送信パケットの形態であり、そして、前記クライアント・デバイスから前記ネットワーク・サーバへのネットワーク送信パケットが、テキスト送信パラメータ情報を持つヘッダ部と、前記クライアント・アプリケーションによって供給されるデータを持つボディ部とを含み、そして、前記クライアント・アプリケーションによって前記ネットワーク・サーバに供給される前記返送アクセス・キーコードが、前記ヘッダ部から締め出されるのが好ましい。

本発明の一代替実施例において、ネットワーク・サーバとクライアント・デバイスの間に、コンピュータネットワークを通じてセキュアな通信リンクを確立する方法が、前記ネットワーク・サーバと前記クライアント・デバイスの間に、通信セッションが確立されるステップと、前記クライアント・デバイスが、前記ネットワーク・サーバにドキュメント提示要求を提示するか、または、前記ネットワーク・サーバにドキュメント要求を提示するステップと、を含んでなり、前記ネットワーク・サーバと前記クライアント・デバイスの間に、前記通信セッションが確立される前記ステップは、前記クライアント・デバイスが、前記ネットワーク・サーバにアクセス要求を送信するステップと、前記ネットワーク・サーバが、前記クライアント・デバイスにユーザ認証情報を要求することと、第１のアクセス・キーコードを作成して、前記第１のアクセス・キーコードを、実行可能なルーチンの内部の第１の発行キーコードとして、前記クライアント・デバイスに送信することにより、前記クライアント・デバイスからの有効なユーザ認証情報の受信に応答することと、によって、前記アクセス要求に応答するステップと、前記クライアント・デバイスが、前記受信した、実行可能なルーチンを実行するステップと、前記実行可能なルーチンが、前記クライアント・デバイス上のクライアント・アプリケーションを作動させるステップであって、実行可能なルーチンが、前記クライアント・アプリケーションに、前記第１のアクセス・キーコードを渡すステップと、前記クライアント・アプリケーションが、前記ネットワーク・サーバに、通信セッションのための新しい要求を提示し、また、前記第１のアクセス・キーコードを、第１の返送キーコードとして提示するステップと、前記ネットワーク・サーバが、前記第１のアクセス・キーコードを無効化し、前記クライアント・アプリケーションとの通信セッションを確立し、第２のアクセス・キーコードを作成し、そして、前記第２のアクセス・キーコードを、第２の発行キーコードとして、前記クライアント・アプリケーションに送信することによって、前記第１のアクセス・キーコードに一致する前記第１の返送キーコードに応答するステップと、を含む。

本発明の好適な一実施例において、前記実行可能なルーチンが、アクティブなウェブ・ページ、即ち、動的ウェブ・ページである。また、前記第１のアクセス・キーコードが、前記クライアント・デバイスと無関係である。さらに、前記第２のアクセス・キーコードが、前記第１のアクセス・キーコードと無関係であるのが好ましい。

好適な一実施例において、前記ネットワーク・サーバが、さらに、前記クライアント・デバイスとのドキュメント通信のためのドキュメント・チャネルを確立し、そして、前記第２の発行キーコードを、前記ドキュメント・チャネルを介して、前記クライアント・アプリケーションに送信することによって、前記第１の発行キーコードに一致する前記第１の返送キーコードに応答する。

さらに、本発明によれば、前記クライアント・デバイスから前記ネットワーク・サーバへのドキュメントの提示は、前記クライアント・デバイスが、前記第２の発行キーコードを、第２の返送アクセス・キーコードとして、ドキュメント提示の要求とともに提示することを必要とし、そして、前記ネットワーク・サーバは、前記第２の返送アクセス・キーコードが、前記第２のアクセス・キーコードと一致すると、前記ドキュメント提示を受け入れ、前記第２のアクセス・キーコードを無効化し、前記第２のアクセス・キーコードと無関係な第３のアクセス・キーコードを作成し、そして、前記第３のアクセス・キーコードを、第３の発行キーコードとして、前記クライアント・アプリケーションに送信することによって、前記ドキュメント提示の要求に応答する。

本発明による一代替実施例において、前記クライアント・デバイスから前記ネットワーク・サーバへのドキュメント要求の提示は、前記クライアント・デバイスが、前記第２の発行キーコードを、第２の返送アクセス・キーコードとして、前記ドキュメント要求とともに提示することを必要とし、そして、前記ネットワーク・サーバは、前記第２の返送アクセス・キーコードが、前記第２のアクセス・キーコードと一致すると、前記要求されたドキュメントを送信し、前記第２のアクセス・キーコードを無効化し、第３のアクセス・キーコードを作成し、そして、前記第３のアクセス・キーコードを、第３の発行キーコードとして、前記クライアント・アプリケーションに送信することによって、前記ドキュメント要求に応答する。

さらに、本発明によれば、前記クライアント・デバイスからの全てのドキュメント提示およびドキュメント要求は、前記クライアント・デバイスが、現在の返送キーコードとして、前記ネットワーク・サーバから最も最近に受信した前記発行キーコードを提示することを必要とし、そして、前記クライアント・デバイスから前記ネットワーク・サーバへの各ドキュメント提示およびドキュメント要求を受信して、前記クライアント・デバイスによって提示された前記現在の返送アクセス・キーコードが、前記ネットワーク・サーバによって前記クライアント・デバイスに発行された、最も最近の発行キーコードと一致すれば、前記ネットワーク・サーバが、前記提示されたドキュメントまたは提示されたドキュメント要求を受け取り、新しいアクセス・キーコードを作成し、そして、前記新しく作成されたアクセス・キーコードを、現在の発行キーコードとして、前記クライアント・アプリケーションに送信する。

さらに、前記クライアント・デバイスが、前記クライアント・デバイスに対して外部のメモリ・クエリによって直接アクセス可能な、少なくとも１つのあらかじめ定められたアーカイブ・メモリ空間を持ち、そして、前記クライアント・アプリケーションによって受信された各発行キーコードが、前記クライアント・デバイスの揮発性メモリ内に存在するアクティブなパラメータとして保持され、いかなるあらかじめ定められたアーカイブ・メモリ空間にも位置せず、そして、前記クライアント・アプリケーションの終了と同時に無効化されるのが好ましい。特に、前記クライアント・アプリケーションによって受信された各発行キーコードが、前記クライアント・デバイスの中央コントローラ内の一時レジスタのエントリとして保持され、そして、前記クライアント・デバイスのいかなる不揮発性の、または、アーカイブなメモリにも転送されないのが好ましい。

さらに、本発明によれば、前記ネットワーク・サーバから前記クライアント・デバイスに送信される前記アクセス・キーコードが、コード化される。さらに、前記ネットワーク・サーバと前記クライアント・デバイスの間の送信が、送信パケットの形態であり、そして、前記クライアント・デバイスから前記ネットワーク・サーバへのネットワーク送信パケットが、テキスト送信パラメータ情報を持つヘッダ部と、前記クライアント・アプリケーションによって供給されるデータを持つボディ部とを含み、そして、前記クライアント・アプリケーションによって前記ネットワーク・サーバに供給される前記返送アクセス・キーコードが、前記ヘッダ部から締め出されるのが好ましい。

本発明の、より完全な理解とともに、その他の目的および達成が、添付する図面に連係して書かれている以下の記述および請求項を参照することによって、明白になり、また、その真価が理解されるであろう。

図面において、同じ参照番号が、同等の部分を表わす。

本発明は、ネットワーク・サーバ、詳細にはインターネット・ウェブ・サーバに複数の層の保護を設ける。最初に、当のウェブ・サーバへのアクセスを得るに先立って、クライアント・デバイスは、まず、ユーザ・ログイン・シーケンスを受けて、認証されなければならない。しかしながら、ログインした後でも、クライアント・デバイスは、依然として、サーバのアプリケーションおよび／または情報へのアクセスを持たない。ログイン・シーケンスの成功は、単に、ウェブ・サーバとのウェブ・セッションを確立したにすぎない、即ち、ウェブ・サーバが、クライアント・デバイスとのオープン・ネットワーク接続を確立している。しかしながら、クライアント・デバイスは、ウェブ・サービスにアクセスしようとするときに、依然として、さらなる検証を受けなければならない。

本発明によるサーバは、複数の情報カテゴリを保持し、そして、いずれの特定の情報カテゴリへのアクセスを得るためにも、クライアント・デバイスが、ウェブ・サーバ上の対応するサービス・アプリケーションにアクセスすることを必要とするのが好ましい。例えば、本発明の好適な一実施例において、ウェブ・サーバは、複数のユーザにネットワーク（即ち、オンライン）会議アクセスを提供するネットワーク会議サーバである。そのウェブ・サーバは、様々なグループの人々に対して、複数の会議アプリケーションをサポートしてもよいし、または、デフォルト会議グループに対してデフォルト・ネットワーク・アプリケーションを持ってもよい。ウェブ・サーバは、各会議グループに対して、メディア情報の個別のデータベース、即ち、データ・ファイルおよび／またはメディア・ファイルを保持するのが好ましい。したがって、特定のメディア情報のデータベースへのアクセスを得るために、人は、最初に、その特定のメディア情報のデータベースに関連した適切な会議グループに加わらなければならない。

ウェブ・サーバに対するセキュリティの２つの主要なポイントは、アクセス認証とデータ暗号化である。アクセス認証は、未承認のユーザが、ウェブ・サーバ上のメディア・ファイル（または、他の情報）にアクセスすることを防止する。インターネットにのって送られるデータの暗号化は、データの機密性を危険にさらすことを回避するのに役立つ。本発明は、ほとんど、アクセス認証を取り扱い、それは、ログイン・ページを介するシステム・アクセス、ウェブ・サーバ上の特定のアプリケーションへのアクセスを管理するためのクライアント・アプリケーション・アクセス制御、および、メディア（または、他のデータ・タイプ）・ファイル・アクセス制御に分けることができる。

システム・アクセスに関して言えば、当のウェブ・サーバへのアクセスを得ることを望むクライアント・デバイスは、そのウェブ・サーバ上のいずれのウェブ・ページへのアクセスを得る前にも認証されなければならない。ログイン・ページ以外のいずれのページに試みられたいずれのアクセスも、図１に示すようなログイン・ページ１００にリダイレクトするのが好ましい。ユーザは、全て、システム・アクセスを得る前に、有効な電子メールアドレス（または、ユーザ名）１０２およびパスワード１０４を入力しなければならないのが好ましい。

ネットワーク・クライアント・ソフトウェア・アプリケーション・アクセス（以後、クライアント・アプリケーション・アクセスと言う）に関して言えば、このアクセス制御は、クライアント・デバイスがウェブ・サーバとなす全てのインタラクションについて、クライアント・デバイスの身元を保証するためのルーチンを必要とする。好適な本実施例において、クライアント・デバイスの識別は、クライアント・デバイスに常駐しているネットワーク・クライアント・アプリケーションを識別することによって得られる。即ち、ログイン後のクライアント・デバイスのウェブ・サーバとのインタラクション毎に、クライアント・デバイス上を走るクライアント・アプリケーションの使用を必要とするのが好ましい。さらに、クライアント・アプリケーションが、サーバに対してそれ自身を検証するための認証情報を備えることを必要とするのが好ましい。何らの有効なクライアント・アプリケーション認証情報も、サーバに送られない場合には、サーバは、接続を中断することができる。

メディア・ファイル・アクセスに関しては、メディア・ファイルが、暗号化セキュリティのために、ＨＴＴＰＳプロトコルを介してアクセスされることが指摘される。しかしながら、上に説明したように、基本ＨＴＴＰＳプロトコルは、ユーザ認証サービスを持っておらず、したがって、もし、補足の認証が必要とされない場合には、特定のサイトのＨＴＴＰＳ ＵＲＬを知っている誰もが、ファイルを自由にアップロードし、また、ダウンロードすることができる。本発明は、各メディア・ファイル・アクセス要求に対して、即ち、各アップロードまたはダウンロード・ファイル・アクセス要求に対して、メディア・ファイル認証情報を必要とすることによって、メディア・ファイル・アクセス・セキュリティのさらなる強化を図っている。

システム・アクセス（即ち、ユーザ・ログオン認証）、クライアント・アプリケーション・アクセス（即ち、ネットワーク・サービスの選択および起動）、および、メディア・ファイル・アクセス（即ち、サービス・ファイル、好ましくはマルチメディア・ファイル、の交換）を含む、本発明によるネットワーク・サービス・セッションのライフサイクルの一般的な概要が、図２を参照して最もよく理解される。本発明によるネットワーク・サービス・システムは、ネットワーク・サーバ９、および、ユーザアクセス可能なネットワーク・クライアント・デバイス１５を含むのが好ましく、その両方が、インターネット１０へのネットワーク・アクセスを持つのが好ましい。

本実施例において、ユーザは、観念的に、既に、ネットワーク・サーバ９に登録されている既存のユーザ・アカウントを持っており、ネットワーク・クライアント・デバイス１５を使用して、インターネット１０を介してネットワーク・サーバ９にアクセスするとする。そのようなユーザ・アカウントを確立する多くの方法が、公知であり、また、その方法を特定することは、本発明に重要な意味を持たない。例えば、個々のユーザは、セキュアな私的ネットワーク（図示せず）と、通常、私的ネットワークよりもセキュアでない、インターネット１０のような公衆網との両方を介して、ネットワーク・サーバ９上の情報へのネットワーク・アクセスを供給する機関のメンバであってもよい。この場合、その機関は、個々のユーザのユーザ・アカウントを生成しており、そして、個々のユーザが、インターネット１０のようなセキュアでないネットワーク・アクセス手段を通じて、ネットワーク・サーバ９上のセキュアな情報（または、他のネットワーク・サービス）にアクセスすることを望むときに用いられるユーザ認証情報を、個々のユーザに供給していてもよい。

ネットワーク・サーバ９は、インターネット１０を介してアクセス可能であって、インターネット・ウェブ・サーバ１１およびメディア・ストレージ・サーバ１３を含んでいるのが好ましい。ドキュメント・チャネル・サーバ５が、さらに、ウェブ・サーバ１１内に統合して示されている。以下に、より完全に説明するように、ドキュメント・チャネル・サーバ５は、ネットワーク・サーバ９上で利用可能な種々のネットワーク・サービスに対するユーザ要求を文書化し、そして、それらのサービスへのアクセスを許諾するための私的インターネット・チャネル（即ち、非ＨＴＴＰ通信チャネル）を供給する。

さらに、ネットワーク・サーバ９は、複数のネットワーク設定を表わすために、破線で示されている。例えば、ウェブ・サーバ１１とメディア・ストレージ・サーバ１３を、単一の物理ネットワーク・サーバに合体させてもよい。それに代えて、ウェブ・サーバ１１とメディア・ストレージ・サーバ１３は、物理的に互いに離れていて、各々がインターネット１０に対する独立したネットワーク・アクセスを持つ、個別のサーバであってもよい。いずれの場合においても、以下に、より完全に説明するように、メディア・ストレージ・サーバ１３、ウェブ・サーバ１１、および、ドキュメント・チャネル・サーバ５の間で通信して、種々の認証情報の分配を可能にするための通信リンク８が存在することが好ましい。同様に、ドキュメント・チャネル・サーバ５が、ウェブ・サーバ１１の内部に統合して示されているが、それは、ウェブ・サーバ１１の外部にあってもよい。その場合、ウェブ・サーバ１１、メディア・ストレージ・サーバ１３、および、ドキュメント・チャネル・サーバ５の間の通信リンクは、保持されなければならない。

ネットワーク・クライアント・デバイス１５は、ウェブ・ブラウザ・モジュール１７、および、ネットワーク・クライアント・アプリケーション・モジュール１９を実行することができる電子デバイスである。ネットワーク・クライアント・デバイス１５は、パーソナルコンピュータ・デバイス、携帯情報端末デバイス、携帯電話、または、ネットワーク・アクセスを持つ他のマルチメディア・デバイスであってもよい。しかしながら、ウェブ・ブラウザ・モジュール１７と、クライアント・アプリケーション・モジュール１９とは、互いに独立したネットワーク・ソフトウェア・アプリケーションであって、各々が、クライアント・デバイス１５上を独立に走ることができ、そして、各々が、異なるネットワーク通信プロトコルを用いてもよいことは、理解されるであろう。例えば、ウェブ・ブラウザ１７は、ワールド・ワイド・ウェブ（以後、ウェブと言う）へのアクセスを備え、そして、ウェブ・サーバ１１上のウェブ・ページにアクセスすることが望ましい。したがって、ウェブ・ブラウザ１７は、ＨＴＴＰ、即ち、ウェブ・ブラウザおよびウェブ・サーバによって用いられているワールド・ワイド・ウェブ通信のためのハイパーテキスト転送プロトコルを用いて、インターネット１０を介してウェブ・サーバ１１と通信することが、理解される。

しかしながら、ドキュメント・チャネル・サーバ５は、非ウェブ・リンクを介して、インターネット１０を通じてアクセスされるのが好ましい。クライアント・アプリケーション１９は、インターネット１０を通じてドキュメント・チャネル・サーバ５と通信することが望ましいから、クライアント・アプリケーション１９は、ＴＣＰ／ＩＰ、または、インターネット通信に適した他の通信プロトコルを用いて通信するのが好ましい。

本例において、３つの線対（１２／１２'、１４／１４'、１６／１６'）が、ネットワーク・クライアント・デバイス１５とネットワーク・サーバ９の間の往復の情報トランザクションを表わすために示されている。これは、以下に記述するデータ・トランザクションの検討を容易にするための、純粋に例示的な目的のためのものであるが、ネットワーク・クライアント・デバイス１５とインターネット１０の間、および、インターネット１０とネットワーク・サーバ９の間に、単一の双方向通信リンクを持つだけで十分であることは、理解されるであろう。

最初、ウェブ・ブラウザ１７とクライアント・アプリケーション１９とのどちらも、ネットワーク・クライアント・デバイス１５内でインスタンス化されていない。好適な一実施例において、ネットワーク・クライアント・デバイス１５の内部のウェブ・ブラウザ１７をインスタンス化し、そして、ネットワーク・クライアント・デバイス１５に、ウェブ・ブラウザ・モジュール１７を用いさせて、ＨＴＴＰ通信プロトコルを使い、リンク１４を介し、インターネット１０を通じてウェブ・サーバ１１との交信を取ることによって、ネットワーク・サービス・セッションが、開始される。即ち、ウェブ・ブラウザ１７が、ウェブ・サーバ１１によって供給される（１４'）ログイン・ウェブ・ページを要求することによって、ログイン・アクセスのための要求を送信する（１４）。

セキュアなＨＴＴＰプロトコル（ＨＴＴＰＳ）が、知られているが、ウェブ・サーバ１１とウェブ・ブラウザ・モジュール１７の間の、この最初のログイン通信トランザクションは、普通の（即ち、セキュアでない）ＨＴＴＰプロトコルを用いて、実施してもよい。ＨＴＴＰＳを用いることは、サーバとクライアント・マシンの間に初期レベルの信頼を必ず伴うから、本実施例では、ＨＴＴＰＳは、用いられない。上に説明したように、ＨＴＴＰＳプロトコルは、サーバとクライアント・マシンの両方が、コード・キーを交換し合うことを必要とするが、本実施例においては、ユーザ認証が検証されてしまうまで、ユーザ志望者、即ち、クライアント・デバイスに、どのようなレベルの信頼も許諾するのを避けることが好ましい。

図１に示すように、サンプルのログイン・ウェブ・ページ１００は、ユーザ名またはユーザの電子メール・フィールド１０２、および、パスワード・フィールド１０４を含んでもよい。ウェブ・ブラウザ１７を用いて、その２つのフィールドに書き込んだ後、送信ボタン１０６を選択すると、入力された情報が、検証のために、ウェブ・サーバ１１に送信される（１４）。

図２に戻って、ウェブ・サーバ１１が、提示されたユーザ認証情報を検証すると、そのウェブ・サーバ１１は、クライアント・デバイス１５に対するウェブ・セッションを生成する。この時点で、種々のネットワーク・サービス・オプションを、選択のためにリストしてもよい。例えば、ネットワーク・サービスは、presentation creation（プレゼンテーション生成）／printing services（印字サービス）／data storage services（データ格納サービス）／data access services（データ・アクセス・サービス）／などのような、ソフトウェア・アプリケーションの選択であってもよい。

しかしながら、本例においては、ネットワーク・サーバ９が、インターネット会議サービスを提供するのが好ましい。この場合、ネットワーク・サーバ９は、会議のリストを供給してもよく、それらの会議のうちのいくつかは、以前に終了してしまっていて、アーカイブ情報を含んでいてもよく、他のものは、進行中であってもよく、または、さらに他のものは、まだ始まっていなくてもよい。一実施例において、ネットワーク・クライアント・デバイス１５のユーザが、ウェブ・ブラウザ１７を介して、ネットワーク・サービスを選んでもよい。それに代えて、ネットワーク・サーバ９が、ユーザの認証情報によって識別された、あらかじめ定められた１つのサービス（あらかじめ定められた１つの会議のような）だけを提供してもよい。この場合には、ネットワーク・サーバは、複数のネットワーク・サービスのうちの１つを選ぶことをユーザに要求することなく、検証されているユーザ認証情報に自動的に応答することができる。いずれの場合にも、一旦、ネットワーク・サービス要求が識別される（手動的に、または、自動的に）と、ウェブ・サーバ１１が、クライアント・サービス・アクセス・パス（または、特に、ネットワーク会議サービスの場合には、「会議接続セキュリティ・パス」）を作成し、動的ウェブ・ページを生成し、そして、クライアント・サービス・アクセス・パスを、動的ウェブ・ページの実行可能なコード内に組み込む、または、統合する。

上に説明したように、ウェブ・ブラウザ１７とネットワーク・サーバ１１の間の通信（１４／１４'）は、セキュアでないＨＴＴＰ通信プロトコルを用いてもよく、それは、悪徳な第三者による傍受を受けやすい通信を残す。しかしながら、クライアント・サービス・アクセス・パスを動的ウェブ・ページの実行可能なコード内に統合することによって、たとえ、その動的ウェブ・ページが傍受されたとしても、クライアント・サービス・アクセス・パスは、セキュアなままである。コード化されたクライアント・サービス・アクセス・パスの抽出は、ネットワーク・クライアント・デバイス１５に常駐しているクライアント・アプリケーション１９の使用を必要とするから、これは、格別に真実である。セキュリティを追加するために、あらかじめ定められたコード化スキームを用いて、好ましくは、１２８ビット長整数を用いて、クライアント・サービス・アクセス・パスをさらにコード化してもよい。この場合には、デコード・アルゴリズムが、クライアント・アプリケーション１９内に統合される。

その後、ウェブ・サーバ１１が、起動のために、ウェブ・ブラウザ１７に動的ウェブ・ページを送信する（１４'）。ウェブ・ブラウザ１７が、受信した動的ウェブ・ページを実行すると、その動的ウェブ・ページが、クライアント・アプリケーション１９をインスタンス化し、そして、クライアント・アプリケーション１９に、クライアント・サービス・アクセス・パスを渡す。必要に応じて、クライアント・サービス・アクセス・パスがクライアント・アプリケーション１９に渡されるに先立って、動的ウェブ・ページと、インスタンス化されたクライアント・アプリケーション１９の間で、ハンドシェーク・シーケンスを行ってもよい。例えば、ウェブ・サーバ１１によってサービスされる全クライアント・デバイス１５に常駐している各クライアント・アプリケーション１９は、ウェブ・サーバ１１内に記録されている、ユニークな（一意に定められた）識別子キーワードを持ってもよい。動的ウェブ・ページは、クライアント・サービス・アクセス・パスをクライアント・アプリケーション１９に渡すに先立って、検証のために、そのユニークな識別子キーワードに関して、クライアント・アプリケーション１９に問い合わせを行ってもよい。

クライアント・アプリケーション１９が、コード化された形態の、そのユニークな識別子キーワードを、動的ウェブ・ページに供給し、動的ウェブ・ページが、受け取った識別子情報をデコードし、そして、それをウェブ・サーバ１１によって供給される情報と比較することによって、それを検証しなければならないのであってもよい。それに代えて、動的ウェブ・ページが、受け取った、コード化された識別子キーワードを、ウェブ・サーバ１１によるデコーディングおよび検証のために、ウェブ・サーバ１１に送ってもよい。この場合には、デコード・アルゴリズムは、ウェブ・サーバ１１の内部でセキュアなままである。

受け取った、コード化された識別子キーワードをウェブ・サーバ１１に送るに先立って、動的ウェブ・ページに、それ自身のコード化アルゴリズム（動的ウェブ・ページをユニークに識別するコード化キーを用いた）を、そのキーワードに対して適用させることによって、さらなるセキュリティ層を設けてもよい。それは、識別子キーワードを抽出するための２つのデコード・シーケンスを備え、その第１のデコード・シーケンスは、ウェブ・サーバ１１によってウェブ・ブラウザ１７に送られた特定の動的ウェブ・ページをユニークに識別し、そして、その第２のデコード・シーケンスは、クライアント・アプリケーション１９をユニークに識別する。

一旦、動的ウェブ・ページが、クライアント・アプリケーション１９に、クライアント・サービス・アクセス・パスを渡せる状態になると、その動的ウェブ・ページは、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）のウェブ・ブラウザによって供給されるＡｃｔｉｖｅＸ（登録商標）サービスを用いて、そうしてもよい。あるいは、動的ウェブ・ページが、ウェブ・ブラウザ１７内を走っているために、そして、しばしば、ウェブ・ブラウザが、ネットワークのセキュリティ問題によって、コンピュータ・デバイス内の許可を非常に制限しているために、ＡｃｔｉｖｅＸ（登録商標）サービスが利用可能でない場合には、動的ウェブ・ページは、単純に、ウェブ・ブラウザ１７と独立に走っているクライアント・アプリケーション１９に、直接に、サービス・アクセス・パスを渡すことができなくてもよい。

この場合に、動的ウェブ・ページは、クライアント・アプリケーション１９の動作についての知識を利用して、セキュリティ許可を犯すことなく、クライアント・アプリケーション１９に、サービス・アクセス・パスを渡すことができる。例えば、当技術分野において公知のように、コンピュータ・デバイスは、多くの利用可能なソフトウェア・ネットワーク・ポートのうちの１つを用いて、ネットワークと通信する。実際には、ネットワーク・ポートは、コンピュータ・デバイスの利用可能なメモリ空間内の指定されたメモリ・アドレスである。しかしながら、コンピュータ規格が、ネットワーク通信サービスに対して、これらのポートのいくつかを指定している。動的ウェブ・ページが、ネットワーク（即ち、インターネット１０）にアクセスするためにクライアント・アプリケーション１９によって用いられている特定のソフトウェア・ネットワーク・ポートを知っていて、そして、コード化されたサービス・アクセス・パスを、この知っているソフトウェア・ネットワーク・ポートに送ってもよい。クライアント・アプリケーション１９は、このポートをリッスン（即ち、観察）しており、クライアント・サービス・アクセス・パスが、ポートに到着したとき、それを捕獲する。一旦、クライアント・アプリケーション１９が、クライアント・サービス・アクセス・パスを取得してしまうと、それは、そのクライアント・サービス・アクセス・パスを解読して、使用することができる。

クライアント・サービス・アクセス・パスが、動的ウェブ・ページの内部に組み込まれていたから、クライアント・サービス・アクセス・パスは、ウェブ・ブラウザ１７からは、常に隠されたままであり、また、クライアント・アプリケーション１９からは、それに渡されるまで隠されたままであることは、強調しておかなければならない。これは、クライアント・サービス・アクセス・パスが、動的ウェブ・ページの終了によって無効化されるまで、常に、アクティブ・メモリ〔即ち、クライアント・デバイス１５のＣＰＵ（Central Processing Unit：中央演算処理装置）内の一時レジスタ〕内にとどまるからである。

これは、上で検討したネットワーク・クッキーとは異なっている。既に説明したように、ネットワーク・クッキーは、ＨＴＴＰトランザクション・パケットのあらかじめ定められたヘッダ位置に送られたテキスト・ファイル、または、テキスト・メッセージであり、ネットワーク・クライアント・デバイス１５内のあらかじめ定められたメモリ位置に格納される。それらのあらかじめ定められたメモリ位置は、通常、ネットワーク・クライアント・デバイス１５のユーザによって、そのユーザが承認されているか否かに関わらず、完全にアクセス可能である。例えば、そのあらかじめ定められた位置は、通常、ネットワーク・クライアント・デバイス１５の固定メモリ装置（即ち、ハードドライブ）内のあらかじめ定められた、そして、広く知られているディレクトリである。これは、第三者によるネットワーク・クッキー情報のアクセスを、比較的容易にする。しかしながら、本例においては、クライアント・サービス・アクセス・パスは、動的ウェブ・ページの実行可能なコード内に組み込まれており、したがって、ＨＴＴＰトランザクション・パケットのヘッダ情報内に見つけられることもなく、クライアント・デバイス１５内の、いかなるあらかじめ定められたメモリ位置に格納されることもない。したがって、とりわけ、クライアント・サービス・アクセス・パスが、動的ウェブ・ページに組み込まれるに先立って、ウェブ・サーバ１１によってコード化された場合には、クライアント・サービス・アクセス・パスが、インスタンス化されたクライアント・アプリケーション１９に渡されるとき、それは、秘密のままであり、クライアント・アプリケーション１９にしか知られない。

したがって、本実施例においては、ウェブ・サーバ１１が、ウェブ・ブラウザ１７に動的ウェブ・ページを送るに先立って、クライアント・アプリケーション１９が、クライアント・デバイス１５内に常駐していると仮定されている。即ち、動的ウェブ・ページは、クライアント・アプリケーション１９を立ち上げる（起動させる）が、必ずしも、それをインストールしない。ユーザ・アカウントが、ユーザに対して生成されたとき、クライアント・アプリケーション１９は、それ以前に、クライアント・デバイス１５にダウンロードされて、インストールされていてもよいし、または、それに代えて、ロードされていてもよい。あるいは、クライアント・アプリケーション１９が、まだ、クライアント・デバイス１５内に常駐していない場合には、動的ウェブ・ページが、クライアント・デバイス１５にインストールするために、インストール可能なクライアント・アプリケーション・ファイルをネットワーク・サーバ９に要求し、そして、ダウンロードしてもよい。しかしながら、一般に、クライアント・アプリケーション１９は、ネットワーク・サーバ９によって供給されると前提され、それによって、ネットワーク・サーバ９は、全クライアント・デバイス１５にロードされたクライアント・アプリケーション１９の全インスタンス化に識別子コードワードを割り当てて、それらをユニークに識別することができる。

ユーザが、複数のネットワーク・サービス・オプションから選ぶ場合には、動的ウェブ・ページが、クライアント・アプリケーション１９にクライアント・サービス・アクセス・パスを渡すのと同様のやり方で、この場合も、動的ウェブ・ページが、クライアント・アプリケーション１９に、選択されたサービス・オプションを識別する情報を渡す。しかしながら、上に説明したように、好適な本実施例は、ウェブ・サーバ１１が、ユーザ認証情報に基づいて、あらかじめ定められたサービス（即ち、あらかじめ定められたネットワーク会議サービス）を自動的に選択すると仮定している。クライアント・アプリケーション１９が、そのユーザに対応する１つのネットワーク会議サービスを知っている場合には、動的ウェブ・ページは、このサービス選択情報を、クライアント・アプリケーション１９に渡す必要はない。一旦、動的ウェブ・ページが、全ての必要な情報を、クライアント・アプリケーション１９に渡してしまえば、それは、それ自身を終了させ、そして、それによって、それに組み込まれたセキュリティ情報（即ち、クライアント・サービス・アクセス・パス）を無効化してもよい。

好適な本実施例において、クライアント・アプリケーション１９は、ネットワーク・サーバ９からの所望のネットワーク・サービスにアクセスするために、ネットワーク・サーバ９との全てのさらなる通信を制御する。しかしながら、まず第一に、クライアント・アプリケーション１９は、ネットワーク・サーバ９に対してそれ自身を認証して、所望のネットワーク・サービスにアクセスする許可を持っていることを証明しなければならない。この２番目の認証ステップは、最初のユーザ認証サービスが、主として、セキュアでないＨＴＴＰチャネル（１４／１４'）を通じて行われたために、行われる。この２番目の認証処理は、ネットワーク・チャネル１２／１２'に沿って、非ＨＴＰＰリンクを通じて（即ち、好ましくは、ＴＣＰ／ＩＰリンクを通じて）遂行される。このリンクは、本質的に、ネットワーク・サーバ９によって供給される、限定されたリンクであるから、独自仕様のセキュリティ対策のいくつかの層を、ネットワーク・チャネル１２／１２'に適用してもよい。独自仕様のセキュリティ技術の使用は、弱点が、多くの人々によって知られており、そして、一部の人々によって悪用されている、公的に利用可能なセキュリティ手段を用いることに伴う危険を取り除く。例えば、全てのキーが、ネットワーク・サーバ９、または、ネットワーク・サーバ９に関連した、いくつかの他の私的ネットワークによって供給されて、管理される場合には、ネットワーク・チャネル１２／１２'上の通信に、セキュアな私有キー（または、私有／公開キー）を用いることができる。

この２番目の認証処理（クライアント・アプリケーション・アクセスを検証する）は、クライアント・アプリケーション１９が、非ＨＴＴＰチャネル１２／１２'に沿って、ドキュメント・チャネル・サーバ５に、クライアント・サービス・アクセス・パスを送信することによって開始する。クライアント・アプリケーション１９は、クライアント・サービス・アクセス・パスをドキュメント・チャネル・サーバ５に提示するに先立って、それを暗号化するのが好ましい。そもそも、ウェブ・サーバ１１が、そのクライアント・サービス・アクセス・パスを、クライアント・アプリケーション１９に供給したのであるから、ドキュメント・チャネル・サーバ５は、受信したクライアント・サービス・アクセス・パスを適切に認証するために、ウェブ・サーバ１１と通信することを必要としてもよい。ドキュメント・チャネル・サーバ５が、受信したクライアント・サービス・アクセス・パスを認証するのに成功すれば、それは、ユニークなメディア・ファイル・アクセス・パス（１２８ビット長整数であってもよい）を生成する。しかしながら、ドキュメント・チャネル・サーバ５が、受信したクライアント・サービス・アクセス・パスを認証することができなかった場合には、それは、再認証のために、セキュアなチャネル１２／１２'に沿って、ドキュメント・チャネル・サーバ５に対して直接に、ユーザ認証情報を再提示する機会を、クライアント・アプリケーション１９に与えてもよい。それに代えて、ドキュメント・チャネル・サーバ５が、再認証のために、ウェブ・サーバ１１に、クライアント・サービス・アクセス・パスを送り返してもよい。しかしながら、ドキュメント・チャネル・サーバ５は、認証を検証することができなければ、クライアント・アプリケーション１９との、その接続を終了するのが好ましい。

ドキュメント・チャネル・サーバ５が、クライアント・アプリケーション１９によって送信されたクライアント・サービス・アクセス・パスを適切に認証し、したがって、ユニークなメディア・ファイル・アクセス・パスを作成したとすると、ドキュメント・チャネル・サーバ５は、そのユニークなメディア・ファイル・アクセス・パスを、セキュアなチャネル１２／１２'に沿って、クライアント・アプリケーション１９に送信する。メディア・ファイル・アクセス・パスを、クライアント・アプリケーション１９に送信するに先立って、コード化してもよいことは、理解されるであろう。

メディア・ファイル・アクセス・パスを得ると、クライアント・アプリケーション１９は、今や、インターネット・チャネル１６／１６'に沿って、ネットワーク・サーバ９に、必要なネットワーク・サービスを要求することができる。メディア・ストレージ・サーバ１３に対するネットワーク・サービスの要求には、メディア・ファイル・アクセス・パスが、伴う。要求されたネットワーク・サービスが、ネットワーク会議である場合には、メディア・ストレージ・サーバ１３が、その会議のストリーミング・メディア・ファイルまたはマルチメディア・ファイルを供給してもよく、また、その会議のマルチメディア・ファイルを受信（格納のために）してもよいことは理解されるであろう。即ち、クライアント・アプリケーション１９によるファイルの要求または提示の全てに対して、クライアント・アプリケーション１９に割り当てられた、ユニークなメディア・ファイル・アクセス・パスが、伴わなければならない。このように、ネットワーク・サーバ９は、どの特定のクライアント・アプリケーション１９（そして、その結果、どの特定のクライアント・デバイス１５）が、どんな特定のファイルを提示またはダウンロードしたかを追跡することができる。

必要に応じて、メディア・ストレージ・サーバ１３は、クライアント・アプリケーション１９から各アクセス要求とともに受信した各メディア・ファイル・アクセス・パスを無効化し、そして、ドキュメント・チャネル・サーバ５に命じて、クライアント・アプリケーション１９からの次のアクセス要求において用いるための新しいメディア・ファイル・アクセス・パスを、セキュアなチャネル１２／１２'を介して、クライアント・アプリケーション１９に供給させてもよい。このように、たとえ、インターネット・チャネル１６／１６'が、セキュアでないチャネルであり、また、第三者が、クライアント・アプリケーション１９によってメディア・ストレージ・サーバ１３に送られたメディア・ファイル・アクセス・パスを、何とか見たとしても、このシステムは、それにもかかわらず、メディア・ストレージ・サーバ１３が、送られてくるメディア・ファイル・アクセス・パスを１回しか受け取らないから、セキュアなままである。即ち、たとえ、第三者が、クライアント・アプリケーション１９からメディア・ストレージ・サーバ１３への経路において、メディア・ファイル・アクセス・パスを、どうにか見たとしても、そのパスが、メディア・ストレージ・サーバ１３に到達するとすぐに、有効なパスであることを終えるから、その第三者は、見たメディア・ファイル・アクセス・パスを利用することができない。受信のすぐ後で、メディア・ストレージ・サーバ１３が、受信したメディア・ファイル・アクセス・パスを無効化し（即ち、無効にし）、そして、ドキュメント・チャネル・サーバ５が、クライアント・デバイス１９が、次回、メディア・ストレージ・サーバ１３に対してファイル・アクセス要求を行うときに用いるための、新しい有効なメディア・ファイル・アクセス・パスを、セキュアなチャネル１２／１２'を介して、クライアント・デバイス１９に送る。メディア・ファイル・アクセス・パスは、全て、インターネット・チャネル１６／１６'が、セキュアであるか、セキュアでないかに関わらず、セキュアなチャネル１２／１２'を通じて、ドキュメント・チャネル・サーバ５によって供給されるのが好ましい。このように、有効なメディア・ファイル・アクセス・パスの配布を管理するほうが、より容易であり、また、システムのチャネル・セキュリティ対策を、１つのチャネル１２／１２'に集中させることができる。さらに、いずれの与えられたクライアント・アプリケーション１９についても（いずれの与えられたクライアント・デバイス１５においても）、その唯一の有効なメディア・ファイル・アクセス・パスは、最も最近に、ドキュメント・チャネル・サーバ５からクライアント・アプリケーション１９に送られたメディア・ファイル・アクセス・パスであることは理解されるであろう。したがって、もし、クライアント・アプリケーション１９が、たまたま、未使用のメディア・ファイル・アクセス・パスを持っているが、新しいメディア・ファイル・アクセス・パスを受信したとしても、クライアント・アプリケーション１９は、より最近に受信したメディア・ファイル・アクセス・パスを容認して、前のメディア・ファイル・アクセス・パスを自動的に廃棄していることに気付く。要約のために、クライアント・デバイス１５と、クライアント・デバイス１５に対して、ネットワーク・サーバ９上のネットワーク・サービスにアクセスする許可を与えるネットワーク・サーバ９との間の通信の概観が、図３に示されている。最初に、クライアント・デバイス１５が、ネットワーク・サーバ９と交信して、ログイン・ウェブ・ページを開いてセッション・アクセスを要求することによって、ユーザ検証シーケンスを開始する（ステップ１０１）。ネットワーク・サーバ９が、検証シーケンス（ステップ１０１）において提示されたユーザ認証情報に基づいてユーザを認証しようと試みるために、提示されたユーザ検証情報をチェックする（ステップ１０３）。検証が成功しない（ステップ１０３が「いいえ」を返す）と、セッション・アクセスが、生成されず、そして、ユーザが、ユーザ認証情報を再提示するために、ユーザ検証シーケンス（ステップ１０１）に戻るように命令される。しかしながら、ユーザ検証が成功する（ステップ１０３が「はい」を返す）と、ウェブ・セッションが、ユーザに対して開かれ（ステップ１０５）、そして、ユーザが、利用可能なオンライン・サービスのリストを供給される。ユーザが、１つのサービスを要求する（ネットワーク会議の「Join（参加）」オプションを「クリックすること」によって、のように）（ステップ１０７が「はい」を返す）と、ネットワーク・サーバ９が、クライアント・デバイス１５に対して、新しいクライアント・サービス・アクセス・パス（即ち、最初の発行キー・コード）を作成し、そして、動的ウェブ・ページによって、クライアント・デバイス１５上のネットワーク・クライアント・アプリケーション１９を起動させる（ステップ１０９）。

クライアント・デバイス１５においては、起動されたネットワーク・クライアント・アプリケーション１９が、選択されたネットワーク・サービスをクライアント・デバイス１５に供給するネットワーク・サーバ９と通信する。しかしながら、起動されたネットワーク・クライアント・アプリケーション１９が、ネットワーク・サーバ９上の、選択されたネットワーク・サービスへのアクセスを得る前に、そのクライアント・アプリケーション１９は、まず、ネットワーク・サーバ９に対して、自分自身を検証しなければならない（ステップ１１１）。これは、そっくりな第三者ネットワーク・アプリケーションが、ネットワーク・クライアント・アプリケーション１９を装うことによって、ネットワーク・サーバ９上のネットワーク・サービスへのアクセスを得る可能性を回避するのに役立つ。起動したネットワーク・クライアント・アプリケーション１９が、非ＨＴＴＰネットワーク・チャネル（即ち、任意選択に独自仕様のコード化スキームを用いるＴＣＰ／ＩＰチャネル）を介して、ネットワーク・サーバ９と交信して、ネットワーク・サーバ９によって以前に供給されたクライアント・サービス・アクセス・パス（即ち、最初の返送キー・コード）を提示することによって、それ自身を検証する（ステップ１１１）。ネットワーク・クライアント・アプリケーション１９が、認証されない（ステップ１１１が「いいえ」を返す）と、ネットワーク・サーバが、通信チャネルを閉じて、ユーザ検証のための最初のログイン・ページ（ステップ１０１）に、クライアント・デバイス１５をリダイレクトする。しかしながら、ネットワーク・クライアント・アプリケーション１９の認証が、成功する（ステップ１１１が「はい」を返す）と、サービス・セッションが、クライアント・アプリケーション１９に対して開かれ、そして、メディア・ファイル・アクセス・パス（即ち、２番目のアクセス・キーコード）が、セキュアな通信によって、ネットワーク・クライアント・アプリケーション１９に送られる（ステップ１１３）。このメディア・ファイル・アクセス・パスは、クライアント・アプリケーション１９が、アクセスを許諾されているネットワーク・サービスの一部としてファイル・アクセス（即ち、アップロードまたはダウンロード・ファイル・アクセス）を望むときには、常に、用いられる。

ネットワーク・クライアント・アプリケーション１９が、ネットワーク・サーバ９に対して、ファイルをダウンロードまたはアップロードする要求を提示する（ステップ１１５が「はい」を返す）と、ネットワーク・サーバ９が、クライアント・アプリケーション１９に対して、要求されたファイル・アクセスを許諾すべきか否かを決定するためのファイル・アクセス検証シーケンスを開始する（ステップ１１７）。そのファイル・アクセス検証シーケンスの一部として、ネットワーク・クライアント・アプリケーション１９が、そのメディア・ファイル・アクセス・パス（即ち、現在の返送キーコード）を提示する。メディア・ファイル・アクセス・パスを検証することができない（ステップ１１９が「いいえ」を返す）と、ネットワーク・サーバ９が、ネットワーク・チャネルを閉じて、アップロード／ダウンロード要求を拒絶し（ステップ１２１）、そして、ログイン・ウェブ・ページ（ステップ１０１）にクライアント・デバイス１５を戻す。あるいはまた、メディア・ファイル・アクセス・パスの検証に成功する（ステップ１１９が「はい」を返す）と、ネットワーク・サーバ９が、要求されたアップロード／ダウンロード要求を許諾する（ステップ１２３）。

クライアント・アプリケーションが、それ自身で接続を切っていない（ステップ１２５が「いいえ」を返す）限り、クライアント・アプリケーション１９は、好ましくは、ネットワーク・サーバ９へのファイル・アクセスを得るために用いるのと同じメディア・ファイル・アクセス・パスを用いて、アップロード／ダウンロード要求を提示し続けてもよい。それに代えて（図３には示されていない）、ネットワーク・サーバ９が、クライアント・アプリケーション１９に対して、それが要求したファイル・アクセスを許諾するに先立って、クライアント・アプリケーション１９から受信した、各有効なメディア・ファイル・アクセス・パス（現在の返送キーコード）を無効化してもよい（即ち、無効にしてもよい）。この場合には、ネットワーク・サーバ９が、新しいメディア・ファイル・アクセス・パス（即ち、現在の発行キーコードとしての新しいアクセス・キーコード）を作成し、そして、セキュアな通信チャネルを通じて、それを、クライアント・アプリケーション１９に送信する。このセキュアな通信チャネルは、ネットワーク・サーバ９が、クライアント・アプリケーション１９からのファイル・アクセス要求を許諾する通信チャネルと異なるのが好ましい。その次の、その後のファイル・アクセス要求において、クライアント・アプリケーションは、そのファイル・アクセス要求とともに、最も最近に受信したメディア・ファイル・アクセス・パスを、ネットワーク・サーバ９に提示しなければならない。

クライアント・アプリケーション１９が、それ自身で接続を切っている、即ち、そのサービス・セッションを終了している（ステップ１２５が「はい」を返す）ときには、ネットワーク・サーバ９が、接続を閉じ、そして、ユーザに、ログイン・ウェブ・ページ（ステップ１０１）を供給してもよい。

上述から分かるように、本通信シーケンスは、３つのサブシーケンス：ＨＴＴＰログイン・ページによって与えられるシステム・アクセス・シーケンス；セキュアな非ＨＴＴＰ通信リンクを用いて、クライアント・アプリケーションのアクセス権を検証するクライアント・アプリケーション・アクセス・シーケンス；メディア・ファイル・アクセス権を検証するメディア・ファイル・アクセス・シーケンス、に分解することができる。これら３つのサブルーチンの、より詳細な分解は、以下のとおりである。

図４を参照すると、システム・アクセス・シーケンスは、ユーザが、ウェブ・ブラウザ１７を用いて、ウェブ・サーバ１１（ネットワーク・サーバ９内の）にアクセスし、ウェブ・サーバ１１が、ウェブ・ブラウザ１７にＨＴＭＬログイン・ページを送って応答することによって始まる。その後、ユーザが、ユーザ名（または、電子メールアドレス）およびパスワードを、認証情報としてログイン・ページに入力し、そして、入力された情報が、認証のために、ウェブ・サーバ１１に送られる（ステップ３１）。ウェブ・サーバ１１が、ユーザ認証情報を受信すると、それは、受信した情報に一致する、ユーザ・データベース中のエントリ（記載事項）を見つけようと試みる（ステップ３３）。提示された認証情報が、ユーザ・データベース中の対応する情報に一致すると、有効なウェブ・セッションが、そのユーザに対して生成される。

以下に、より明らかになるように、本発明は、各アクセス・トランザクションに対して、ネットワーク・サーバ９への認証情報の提示を必要とするが、本発明は、ウェブ・セッションを確立し、そして、それによって、ネットワーク・サーバ９において利用可能な種々のサービスへのアクセスを得るためには、個人のユーザ認証情報を、一度だけ、ウェブ・サーバ１１に提示すればよいように設計されている。

提示されたユーザ名（または、ユーザの電子メールのアカウント名）およびパスワードが、ウェブ・サーバ１３によってアクセス可能な（または、その内部に格納されている）ユーザ認証情報データベース中の１つのエントリと一致した（ステップ３３が「はい」を返す）とき、有効なウェブ・セッションを生成してもよい（ステップ３７）。しかしながら、その前に、ウェブ・サーバ１１は、その同じ認証されたユーザに対する既存のウェブ・セッションが既に存在するか否かを決定する（ステップ３５）のが好ましい。既存のウェブ・セッションが存在する（ステップ３５が「はい」を返す）と、現在認証されているユーザに対して、新しい有効なウェブ・セッションを生成する（ステップ３７）に先立って、より以前のウェブ・セッション（即ち、その既存のウェブ・セッション）が、無効化される（即ち、閉じられる）（ステップ３９）。あるいはまた、既存のウェブ・セッションが存在しない（ステップ３５が「いいえ」を返す）と、新しい有効なウェブ・セッションが、直ちに生成される（ステップ３７）。

現在のウェブ・セッションが、タイムアウトしている（ステップ４１が「はい」を返す）場合、即ち、あらかじめ定められた期間が、ユーザからの活動なしに経過した場合、または、ユーザが、故意にログアウトしている（ステップ４５が「はい」を返す）場合、現在のウェブ・セッションも、無効化できる（ステップ４７）のが好ましい。このように、認証されたユーザが、ログアウトした（ステップ４５）とき、ユーザが、ウェブ・セッションがタイムアウトすることを容認した（ステップ４１）とき、または、ユーザが、別のウェブ・ブラウザ・アプリケーションから、あらためてログインした(それは、ユーザが、前のウェブ・セッションを放棄していることを表わすであろう）（ステップ３５）とき、ウェブ・セッションは無効化される。

ユーザは、ネットワーク・サーバ９上のいずれのネットワーク・サービスにアクセスするためにも、有効なウェブ・セッションを必要とするが、まだ、いかなるタイプのセキュアなアクセス・パスも、ユーザに送られていないことに注意されたい。

上で説明したように、ネットワーク・サーバ９は、デフォルト（初期設定）で、ネットワーク会議サービスを供給するのが好ましいが、ユーザが、いくつかの利用可能なネットワーク・サービスから選択することが可能であってもよい。したがって、ウェブ・サーバ１１によって確立された、有効なウェブ・セッションが、ネットワーク会議ウェブ・ページ、または、任意の他のタイプのネットワーク・サービスにアクセスするために必要である。

クライアント・アプリケーション・アクセス・シーケンスは、ドキュメント・チャネル・セッション、即ち、ネットワーク・サービスの選択および起動が行われる処理のライフサイクルで具現化される。図５を参照すると、ユーザが、会議を選択するか、または、ウェブ・サーバ１１にリストされている他の任意のオンライン・サービスを選択する（ステップ５１）と、ウェブ・サーバ１１が、クライアント・サービス・アクセス・パスを生成して、それを、動的ウェブ・ページ内に統合する（ステップ５３）。このサービス選択は、ウェブ・サーバ１１によって供給される「Join」オプションをクリックする（即ち、選択する）ことによって遂行されるのであってもよい。動的ウェブ・ページは、それが実行される時、クライアント・デバイス１５上のクライアント・アプリケーションを立ち上げる（ステップ５５）のが好ましい。ウェブ・サーバ１１が、クライアント・デバイス５３に、動的ウェブ・ページを送る。動的ウェブ・ページを受信して、ウェブ・ブラウザ１７が、その動的ウェブ・ページを実行し、そして、それによって、クライアント・アプリケーションを立ち上げる（ステップ５５）。クライアント・アプリケーションが、クライアント・マシン上に既に常駐しているのが好ましいことは、理解されるであろう。常駐していなければ、動的ウェブ・ページは、クライアント・アプリケーションを立ち上げるに先立って、それをダウンロードして、インストールするためのインストール・ルーチンを促してもよい。

クライアント・アプリケーションは、動的ウェブ・ページによってしか、立ち上げられないのが好ましい。即ち、クライアント・デバイスは、動的ウェブ・ページを用いること以外のいかなる手段によっても、直接、クライアント・アプリケーションを立ち上げることができないのが好ましい。このように、まず先に、ネットワーク・サーバ９にログインして、クライアント・サービス・アクセス・パスを受信しておくことなく、クライアント・デバイス１５が、ネットワーク・サーバ９内のサービスにアクセスするために用いられるクライアント・アプリケーション１９を起動させることができないことが、確保される。これは、クライアント・アプリケーション１９の実行可能なコードに、動的ウェブ・ページの有効性を確認する初始動ルーチンをコード化することによって遂行してもよく、動的ウェブ・ページの有効性を確認することができない場合には、クライアント・アプリケーションが、それ自体を終了させてもよい。ネットワーク・サーバ９は、クライアント・デバイス１５からのサービス要求を受信した後、新しい動的ウェブ・ページを作成するから、ネットワーク・サーバ９は、各動的ウェブ・ページをクライアント・デバイスに送るに先立って、それに、識別クライアント・コードを割り当ててもよい。その後、動的ウェブ・ページが、その識別クライアント・コードを、クライアント・サービス・アクセス・パスとともに、クライアント・アプリケーションに渡してもよく、クライアント・アプリケーションが、その識別クライアント・コードを用いて、動的ウェブ・ページの有効性を確認してもよい。即ち、識別クライアント・コードは、クライアント・アプリケーションに知られている、ユニークな数列を基にしたものであってもよく、それによって、クライアント・アプリケーションは、供給されたクライアント・コードが、その知っているユニークな数列から得られるか否かを決定することによって、動的ウェブ・ページの有効性を確認することができる。それに代えて、クライアント・アプリケーション１９は、ネットワーク・サーバ９によって供給されたものか、または、少なくともネットワーク・サーバ９に知られているから、ネットワーク・サーバ９によってクライアント・デバイス１５に送られた、いかなる動的ウェブ・ページも認証することができるアプリケーション識別番号を、クライアント・アプリケーション１９に与えてもよい。

クライアント・アプリケーション１９が、立ち上げられたとき、それは、ネットワーク・サーバ９によって生成された会議クライアント・サービス・アクセス・パスをピックアップする（ステップ５５）。

立ち上がったクライアント・アプリケーションが、その後、ドキュメント・チャネル・サーバ５に接続する。クライアント・アプリケーション１９が、ドキュメント・チャネル・サーバ５に、有効な会議クライアント・サービス・アクセス・パス（１２８ビット長整数であってもよい）を提示する（ステップ５７）のが好ましい。一代替実施例において、クライアント・アプリケーション１９が、会議クライアント・サービス・アクセス・パスを見つけることができなかった場合には、そのクライアント・アプリケーションは、ユーザに対して、ユーザ名およびパスワードの入力を促し、そして、それらを、再認証のためにウェブ・サーバ１１に送るか、または、それに代えて、それらを、ドキュメント・チャネル・サーバ５に送る。ドキュメント・チャネル・サーバ５は、認証のために、ウェブ・サーバ１１と通信する。このように、クライアント・アプリケーション１９が、ドキュメント・チャネル・サーバ５に接続するとき、クライアント・アプリケーション１９は、クライアントを接続させ続けるために、有効な会議クライアント・サービス・アクセス・パスか、または、ユーザ認証情報のいずれかを送らなければならない。提示された情報のどれもが、有効でない（ステップ５９が「いいえ」を返す）と、クライアント・アプリケーション１９が、ドキュメント・チャネル・サーバ５との接続を切られ（ステップ６３）、そして、ウェブ・サーバ１１上のユーザ・ログイン・サービスにリダイレクトされる（ステップ６５）。

ドキュメント・チャネル・サーバ５が、クライアント・サービス・アクセス・パスを検証する（ステップ５９）。クライアント・サービス・アクセス・パスが、有効である（ステップ５９が「はい」を返す）と、ドキュメント・チャネル・サーバ５が、クライアント・アプリケーション１９を接続し続ける。有効でない（ステップ５９が「いいえ」を返す）と、ドキュメント・チャネル・サーバ５は、クライアント・アプリケーション１９が敵対的であるとみなして、接続を閉じ（ステップ６３）、そして、ユーザ・ログイン情報を要求する（ステップ６５）。

クライアント・サービス・アクセス・パスが、検証された後、提示されたクライアント・サービス・アクセス・パスが、無効化される（ステップ６１）。その後、同じユーザによって生成された別のセッションが既に開かれているか否かが、決定される。開かれている既存のセッションが存在する（ステップ６７が「はい」を返す）と、その既存のセッションが、維持されて、この後のセッションに対する新しい接続は、全く生成されず、そして、この後のセッションに対して、接続が閉じられる（ステップ６３）。既存のセッションが、存在していない（ステップ６７が「いいえ」を返す）と、新しいサービス・セッションが、生成される（ステップ６９）。

その後、ドキュメント・チャネル・サーバ５が、メディア・ファイル・アクセス・パスを生成し、そして、そのメディア・ファイル・アクセス・パスを、ドキュメント・チャネル１２'を介して、クライアント・アプリケーション１９に送る（ステップ７１）。メディア・ファイル・セキュリティ・パスが、ＨＴＴＰプロトコルを回避して、直接、クライアント・アプリケーションに送られるのであるから、メディア・ファイル・セキュリティ・パスが外部に漏れることを避けるための独自仕様のコード化スキームを用いて、そのメディア・ファイル・セキュリティ・パスを暗号化することができる。さらに言えば、クライアント・サービス・アクセス・パスの代わりに、メディア・ファイル・セキュリティ・パスを用いることができないこと、および、したがって、破った接続を再確立するために、メディア・ファイル・アクセス・パスを用いることができないことは、理解されるであろう。接続が、上述の種々の方法の１つによって閉じられるまで、そのセッションは開いたままである（ステップ７３）。しかしながら、一旦、接続が閉じられる（ステップ７３が「はい」を返す）と、そのセッションは、無効化され（ステップ７５）、そして、ドキュメント・チャネル・サーバ５は、その後のいかなるサービス・アクセス要求も、ウェブ・サーバ１１上のログイン・サービスにリダイレクトする（ステップ６５）。

メディア・ファイル・アクセス・シーケンスの、より詳細な概括が、図６を参照すると、最もよく理解される。一旦、クライアント・デバイス１５が、メディア・ファイル・アクセス・パスを受信してしまえば、それは、メディア・ストレージ・サーバ１３へのアクセスを要求することができる。最初に、クライアント・アプリケーション１９が、アップロード・ファイル要求またはダウンロード・ファイル要求とともに、そのメディア・ファイル・アクセス・パスを、メディア・ストレージ・サーバ１３に提示する（ステップ８３）。即ち、クライアントが、メディア・ファイルをアップロード／ダウンロードしようと試みるとき、それは、メディア・ファイルにアクセスするためのパラメータの１つとして、メディア・ファイル・アクセス・パス（１２８ビット長整数であることが好ましい）を送る。

メディア・ストレージ・サーバ１３が、メディア・ファイル・アップロード／ダウンロード要求を受信したときには、それは、メディア・ファイル・アクセス・パスを検証する（ステップ８５）。そのメディア・ファイル・アクセス・パスが、有効でない（ステップ８５が「いいえ」を返す）と、メディア・ストレージ・サーバ１３が、クライアント・アプリケーション１９にエラーコード（４０４）を送り、そして、さらに、クライアント・アプリケーション１９との接続を切る（ステップ８７）のが好ましい。

メディア・ファイル・アクセス・パスが、選択されているサービス（即ち、特定のオンライン会議サービス）に対して有効であり、そのクライアント・セッションが終了していない（ステップ８９が「いいえ」と返す）と決定されると、メディア・ストレージ・サーバ１３が、クライアント・アプリケーションに対してネットワーク接続を許諾し（ステップ９１）、そして、アップロード要求またはダウンロード要求を受理して、それにしたがって行動する（ステップ９３）。

クライアント・アプリケーション１９が、ネットワーク・サーバ９との接続を切っている（ステップ８９が「はい」を返す）ときには、そのメディア・ファイル・アクセス・パスが、有効なアクセス・パス・コードの記録から無効化され（ステップ９５）、そして、メディア・ストレージ・サーバ１３が、クライアント・アプリケーション１９との接続を、それ自身で切る（ステップ８７）。このように、クライアント・アプリケーション１９によって用いられたメディア・ファイル・アクセス・パスを、再度、用いることはできない。

一実施例において、セッションが終了して、メディア・ファイル・セキュリティ・パスが無効化されるまでは、クライアント・アプリケーション１９が、メディア・ストレージ・サーバ１３への複数のファイル・アクセス要求に対して、同一のメディア・ファイル・アクセス・パスを用いてもよい。それに代えて、メディア・ストレージ・サーバ１３が、クライアント・アプリケーション１９からの各ファイル・アクセス要求と同時に、前のメディア・ファイル・セキュリティ・パスを無効化し、そして、次のファイル・アクセス要求において用いるために、新しいメディア・ファイル・セキュリティ・パスを作成して、その新しいメディア・ファイル・セキュリティ・パスを、クライアント・アプリケーション１９に送ってもよい。

本発明が、いくつかの特定の実施例に結び付けて記述されているが、当業者には、多くのさらなる代替形態、変更形態、および変形形態が、前記述に照らして明白になることは明らかである。したがって、本明細書に記述されている本発明は、付随する請求項の精神および範囲に含まれる代替形態、変更形態、出願、および変形形態を包含するように意図されている。

本発明によるログイン・ウェブ・ページである。 本発明によるネットワーク・コンポーネントおよびデータ・トラフィックのブロック図である。 本発明によるネットワーク・プロセスの一般的な概要のフロー・チャートである。 本発明によるユーザ認証プロセスの詳細なフロー・チャートである。 本発明によるクライアント・アプリケーション認証プロセスの詳細なフロー・チャートである。 本発明による、ネットワーク・サーバにアクセスを要求しているクライアント・アプリケーションのファイル・アクセス権を検証するプロセスの詳細なフロー・チャートである。

符号の説明

５…ドキュメント・チャネル・サーバ、８…認証情報の分配を可能にするための通信リンク、９…ネットワーク・サーバ、１０…インターネット、１１…ウェブ・サーバ、１２，１２'…セキュアな非ＨＴＴＰチャネル、１３…メディア・ストレージ・サーバ、１４，１４'…セキュアでないＨＴＴＰチャネル、１５…クライアント・デバイス、１６，１６'…インターネット・チャネル、１７…ウェブ・ブラウザ、１９…クライアント・アプリケーション、１００…ログイン・ページ、１０２…ユーザ名またはユーザの電子メール・フィールド、１０４…パスワード・フィールド、１０６…送信ボタン。

Claims (24)

1. 求めているネットワーク・クライアントにネットワーク・アクセスを選択的に供給するためのネットワーク・サーバと、
   前記ネットワーク・サーバと交信して、ネットワーク・アクセスを求めるためのクライアント・デバイスと、
   を備えてなるネットワーク通信システムであって、
   前記ネットワーク・サーバが、前記クライアント・デバイスに認証情報を要求することと、実行可能なソフトウェア・コードの内部に組み込まれた第１の発行キーコードとして、前記クライアント・デバイスに送信される第１のアクセス・キーコードを作成することにより、前記クライアント・デバイスからの、検証された認証情報の受信に応答することと、によって、ネットワーク・アクセスを求めている前記クライアント・デバイスに応答するように設定され、
   前記実行可能なソフトウェア・コードが、前記クライアント・デバイス上のクライアント・アプリケーションを立ち上げ、そして、前記立ち上げられたクライアント・アプリケーションに、前記第１の発行キーコードを渡すのに有効であり、
   前記クライアント・アプリケーションが、前記第１の発行キーコードを、第１の返送キーコードとして、通信セッションの確立の要求とともに、前記ネットワーク・サーバに送信するのに有効であり、そして、
   前記ネットワーク・サーバが、前記第１のアクセス・キーコードを無効化し、前記クライアント・アプリケーションとの通信セッションを確立し、前記第１のアクセス・キーコードと無関係な第２のアクセス・キーコードを作成し、そして、前記第２のアクセス・キーコードを、第２の発行キーコードとして、前記クライアント・アプリケーションに送信することによって、前記第１の発行キーコードに一致する前記第１の返送キーコードに応答する、ネットワーク通信システム。
2. 前記ネットワーク・サーバと前記クライアント・デバイスが、インターネットを通じて通信し、そして、前記実行可能なソフトウェア・コードが、動的ウェブ・ページ内に統合される請求項１に記載のネットワーク通信システム。
3. 前記ネットワーク・サーバと前記クライアント・デバイスが、インターネットを通じて通信し、そして、前記クライアント・アプリケーションが、前記クライアント・デバイス上のいずれのインターネット・ブラウザ・アプリケーションからも独立している請求項１に記載のネットワーク通信システム。
4. 前記第１のアクセス・キーコードが、前記クライアント・デバイスと無関係である請求項１に記載のネットワーク通信システム。
5. 前記クライアント・デバイスからの全てのドキュメント提示およびドキュメント要求は、前記クライアント・デバイスが、現在の返送キーコードとして、前記ネットワーク・サーバから最も最近に受信した前記発行キーコードを提示することを必要とし、そして、
   前記クライアント・デバイスから前記ネットワーク・サーバへの各ドキュメント提示およびドキュメント要求を受信して、前記クライアント・デバイスによって提示された前記現在の返送アクセス・キーコードが、前記ネットワーク・サーバによって前記クライアント・デバイスに発行された、最も最近の発行キーコードと一致すれば、前記ネットワーク・サーバが、前記提示されたドキュメントまたはドキュメント要求を受け取り、新しいアクセス・キーコードを作成し、そして、前記新しく作成されたアクセス・キーコードを、現在の発行キーコードとして、前記クライアント・アプリケーションに送信する、
   請求項１に記載のネットワーク通信システム。
6. 前記クライアント・アプリケーションは、前記実行可能なソフトウェア・コード以外の何らかの手段によって立ち上げられると、自動的に、それ自身を終了させる請求項１に記載のネットワーク通信システム。
7. 前記ネットワーク・サーバが、前記実行可能なソフトウェア・コードに、識別ＩＤコードを割り当て、
   前記クライアント・アプリケーションが、あらかじめ定められた立ち上げ識別コードを保持し、
   前記実行可能なソフトウェア・コードが、その識別ＩＤコードを、前記クライアント・アプリケーションに渡し、そして、
   前記クライアント・アプリケーションは、前記識別ＩＤコードが、前記あらかじめ定められた立ち上げ識別コードによって認証されないと、それ自身を終了させる、
   請求項６に記載のネットワーク通信システム。
8. 前記クライアント・アプリケーションが、あらかじめ定められたクライアント・アプリケーション識別コードを保持し、
   前記実行可能なソフトウェア・コードは、前記クライアント・アプリケーション識別コードが、前記実行可能なソフトウェア・コードによって認証されたときしか、前記立ち上げられたクライアント・アプリケーションに、前記第１の発行キーコードを渡さない、
   請求項１に記載のネットワーク通信システム。
9. 前記ネットワーク・サーバが、クライアント・アプリケーションを識別するためのアプリケーションＩＤコードの蓄積を保持し、
   前記ネットワーク・サーバが、前記実行可能なソフトウェア・コードに、予期されるクライアント・アプリケーションに対応する特定のアプリケーションＩＤコードを組み込み、そして、
   前記実行可能なソフトウェア・コードが、前記組み込まれた特定のアプリケーションＩＤコードを用いて、前記クライアント・アプリケーション識別コードを認証する、
   請求項８に記載のネットワーク通信システム。
10. 前記ネットワーク・サーバが、クライアント・アプリケーションを識別するためのアプリケーションＩＤコードの蓄積を保持し、そして、
    前記実行可能なソフトウェア・コードが、認証のために、前記ネットワーク・サーバに、前記クライアント・アプリケーション識別コードを転送する、
    請求項８に記載のネットワーク通信システム。
11. 前記クライアント・デバイスが、前記クライアント・デバイスに対して外部のメモリ・クエリによって直接アクセス可能な、少なくとも１つのあらかじめ定められたアーカイブ・メモリ空間を持ち、そして、
    前記クライアント・アプリケーションによって受信された各発行キーコードが、前記クライアント・デバイスの揮発性メモリ内に存在するアクティブなパラメータとして保持され、いかなるあらかじめ定められたアーカイブ・メモリ空間にも位置せず、そして、前記クライアント・アプリケーションの終了と同時に無効化される、
    請求項１に記載のネットワーク通信システム。
12. 前記クライアント・アプリケーションによって受信された各発行キーコードが、前記クライアント・デバイスの中央コントローラ部内の一時レジスタのエントリとして保持され、そして、前記クライアント・デバイスのいかなる不揮発性メモリにも転送不可能である請求項１に記載のネットワーク通信システム。
13. 前記ネットワーク・サーバと前記クライアント・デバイスの間の送信が、送信パケットの形態であり、そして、前記クライアント・デバイスから前記ネットワーク・サーバへのネットワーク送信パケットが、テキスト送信パラメータ情報を持つヘッダ部と、前記クライアント・アプリケーションによって供給されるデータを持つボディ部とを含み、そして、前記クライアント・アプリケーションによって前記ネットワーク・サーバに供給される前記返送アクセス・キーコードが、前記ヘッダ部から締め出される請求項１に記載のネットワーク通信システム。
14. ネットワーク・サーバとクライアント・デバイスの間に、コンピュータネットワークを通じてセキュアな通信リンクを確立する方法であって、
    前記ネットワーク・サーバと前記クライアント・デバイスの間に、通信セッションが確立されるステップと、
    前記クライアント・デバイスが、前記ネットワーク・サーバにドキュメントを提示するか、または、前記ネットワーク・サーバにドキュメント要求を提示するステップと、を含んでなる方法において、
    前記ネットワーク・サーバと前記クライアント・デバイスの間に、前記通信セッションが確立される前記ステップが、
    前記クライアント・デバイスが、前記ネットワーク・サーバにアクセス要求を送信するステップと、
    前記ネットワーク・サーバが、前記クライアント・デバイスにユーザ認証情報を要求することと、第１のアクセス・キーコードを作成して、前記第１のアクセス・キーコードを、実行可能なソフトウェア・コードの内部に組み込まれた第１の発行キーコードとして、前記クライアント・デバイスに送信することにより、前記クライアント・デバイスからの有効なユーザ認証情報の受信に応答することと、によって、前記アクセス要求に応答するステップと、
    前記クライアント・デバイスが、前記受信した、実行可能なソフトウェア・コードを実行するステップと、前記実行可能なソフトウェア・コードが、前記クライアント・デバイス上のクライアント・アプリケーションを立ち上げるステップであって、前記実行可能なソフトウェア・コードが、前記クライアント・アプリケーションに、前記第１のアクセス・キーコードを渡すステップと、
    前記クライアント・アプリケーションが、前記ネットワーク・サーバに、通信セッションのための新しい要求を提示し、また、前記第１のアクセス・キーコードを、第１の返送キーコードとして提示するステップと、
    前記ネットワーク・サーバが、前記第１のアクセス・キーコードを無効化し、前記クライアント・アプリケーションとの通信セッションを確立し、第２のアクセス・キーコードを作成し、そして、前記第２のアクセス・キーコードを、第２の発行キーコードとして、前記クライアント・アプリケーションに送信することによって、前記第１のアクセス・キーコードに一致する前記第１の返送キーコードに応答するステップと、を含む方法。
15. 前記実行可能なソフトウェア・コードが、動的ウェブ・ページ内に統合される請求項１４に記載の方法。
16. 前記第１のアクセス・キーコードが、前記クライアント・デバイスと無関係である請求項１４に記載の方法。
17. 前記第２のアクセス・キーコードが、前記第１のアクセス・キーコードと無関係である請求項１４に記載の方法。
18. 前記クライアント・デバイスから前記ネットワーク・サーバへのドキュメントの提示は、前記クライアント・デバイスが、前記第２の発行キーコードを、第２の返送アクセス・キーコードとして、ドキュメント提示の要求とともに提示することを必要とし、そして、
    前記ネットワーク・サーバは、前記第２の返送アクセス・キーコードが、前記第２のアクセス・キーコードと一致すると、前記ドキュメント提示を受け入れ、前記第２のアクセス・キーコードを無効化し、前記第２のアクセス・キーコードと無関係な第３のアクセス・キーコードを作成し、そして、前記第３のアクセス・キーコードを、第３の発行キーコードとして、前記クライアント・アプリケーションに送信することによって、前記ドキュメント提示の要求に応答する、
    請求項１４に記載の方法。
19. 前記クライアント・デバイスから前記ネットワーク・サーバへのドキュメント要求の提示は、前記クライアント・デバイスが、前記第２の発行キーコードを、第２の返送アクセス・キーコードとして、前記ドキュメント要求とともに提示することを必要とし、そして、
    前記ネットワーク・サーバは、前記第２の返送アクセス・キーコードが、前記第２のアクセス・キーコードと一致すると、前記要求されたドキュメントを送信し、前記第２のアクセス・キーコードを無効化し、第３のアクセス・キーコードを作成し、そして、前記第３のアクセス・キーコードを、第３の発行キーコードとして、前記クライアント・アプリケーションに送信することによって、前記ドキュメント要求に応答する、
    請求項１４に記載の方法。
20. 前記クライアント・デバイスからの全てのドキュメント提示およびドキュメント要求は、前記クライアント・デバイスが、現在の返送キーコードとして、前記ネットワーク・サーバから最も最近に受信した前記発行キーコードを提示することを必要とし、そして、
    前記クライアント・デバイスから前記ネットワーク・サーバへの各ドキュメント提示およびドキュメント要求を受信して、前記クライアント・デバイスによって提示された前記現在の返送アクセス・キーコードが、前記ネットワーク・サーバによって前記クライアント・デバイスに発行された、最も最近の発行キーコードと一致すれば、前記ネットワーク・サーバが、前記提示されたドキュメントまたは前記提示されたドキュメント要求を受け取り、新しいアクセス・キーコードを作成し、そして、前記新しく作成されたアクセス・キーコードを、現在の発行キーコードとして、前記クライアント・アプリケーションに送信する、
    請求項１４に記載の方法。
21. 前記クライアント・デバイスが、前記クライアント・デバイスに対して外部のメモリ・クエリによって直接アクセス可能な、少なくとも１つのあらかじめ定められたアーカイブ・メモリ空間を持ち、そして、
    前記クライアント・アプリケーションによって受信された各発行キーコードが、前記クライアント・デバイスの揮発性メモリ内に存在するアクティブなパラメータとして保持され、いかなるあらかじめ定められたアーカイブ・メモリ空間にも位置せず、そして、前記クライアント・アプリケーションの終了と同時に無効化される、
    請求項１４に記載の方法。
22. 前記クライアント・アプリケーションによって受信された各発行キーコードが、前記クライアント・デバイスの中央コントローラ内の一時レジスタのエントリとして保持され、そして、前記クライアント・デバイスのいかなる不揮発性メモリにも転送されない請求項２１に記載の方法。
23. 前記ネットワーク・サーバから前記クライアント・デバイスに送信される前記アクセス・キーコードが、コード化される請求項１４に記載の方法。
24. 前記ネットワーク・サーバと前記クライアント・デバイスの間の送信が、送信パケットの形態であり、そして、前記クライアント・デバイスから前記ネットワーク・サーバへのネットワーク送信パケットが、テキスト送信パラメータ情報を持つヘッダ部と、前記クライアント・アプリケーションによって供給されるデータを持つボディ部とを含み、そして、前記クライアント・アプリケーションによって前記ネットワーク・サーバに供給される前記返送アクセス・キーコードが、前記ヘッダ部から締め出される請求項１４に記載の方法。

Images