JP3940356B2 - プロキシ・サーバ、アクセス制御方法、アクセス制御プログラム - Google Patents
プロキシ・サーバ、アクセス制御方法、アクセス制御プログラム Download PDFInfo
- Publication number
- JP3940356B2 JP3940356B2 JP2002381655A JP2002381655A JP3940356B2 JP 3940356 B2 JP3940356 B2 JP 3940356B2 JP 2002381655 A JP2002381655 A JP 2002381655A JP 2002381655 A JP2002381655 A JP 2002381655A JP 3940356 B2 JP3940356 B2 JP 3940356B2
- Authority
- JP
- Japan
- Prior art keywords
- response data
- access
- access request
- server
- proxy server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0281—Proxies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/101—Access control lists [ACL]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2101/00—Indexing scheme associated with group H04L61/00
- H04L2101/30—Types of network names
- H04L2101/32—Types of network names containing non-Latin characters, e.g. Chinese domain names
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/30—Managing network names, e.g. use of aliases or nicknames
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/35—Network arrangements, protocols or services for addressing or naming involving non-standard use of addresses for implementing network functionalities, e.g. coding subscription information within the address or functional addressing, i.e. assigning an address to a function
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
一般的には、本発明はネットワーク・セキュリティ技術に関する。より具体的には、本発明はプロキシ・サーバにおけるアクセス制御技術に関する。
【０００２】
【従来の技術】
パーソナル・コンピュータ（ＰＣ）のような情報処理技術およびインターネット、イントラネットなどのネットワーク技術が普及し、ビジネス用途にそれらの技術が使用される機会が増している。その結果、不正アクセスによる顧客情報の漏洩などの危険が増大し、ネットワーク・セキュリティ技術に関心が非常に集まっている。
【０００３】
そのような背景の下で、インターネットのような外部ネットワークから社内ＬＡＮのようなイントラネット内のサーバへの不正アクセスを防止する必要が生じている。また、イントラネットから外部ネットワークへの不適切なアクセスを制限する必要もある。これらの必要のため、通常、外部ネットワークとイントラネットの間にプロキシ・サーバが設置される。
【０００４】
プロキシ・サーバは、外部ネットワーク上のコンピュータにアクセスしようとするイントラネット上のコンピュータに代わってサーバへのアクセス要求を中継する。このようなプロキシ・サーバの機能をフォワード・プロキシという。フォワード・プロキシとして機能する場合、プロキシ・サーバは、イントラネットからのアクセス要求を中継する際に、そのアクセス要求の中継の許可／不許可をチェックし、アクセス制御を行う。
【０００５】
また、プロキシ・サーバはイントラネット内のコンピュータにアクセスしようとする外部ネットワーク上のコンピュータに代わって、アクセス要求をイントラネット内のコンピュータに中継する。このようなプロキシ・サーバの機能をリバース・プロキシという。リバース・プロキシとして機能する場合も、プロキシ・サーバは、外部ネットワークからのアクセス要求を中継する際に、そのアクセス要求の中継の許可／不許可をチェックし、アクセス制御を行う。
【０００６】
現在、様々なプロキシ・サーバによるアクセス制御技術が存在する。プロキシ・サーバによるアクセス制御技術の１つとして、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒの略）をベースにしたアクセス制御（以下、ＵＲＬベース・アクセス制御という。）がある。なお、ＵＲＬは、インターネット、イントラネットのようなＴＣＰ／ＩＰネットワーク上のリソースのアドレス・ロケーションであり、所定の規則に従った任意の文字列で表現される。
【０００７】
ＵＲＬベース・アクセス制御を実現するソフトウェア製品として、インターナショナル・ビジネス・マシーンズが提供するＩＢＭ Ｔｉｖｏｌｉ Ａｃｃｅｓｓ Ｍａｎａｇｅｒ（Ｒ）製品が存在する。現在のＩＢＭ Ｔｉｖｏｌｉ Ａｃｃｅｓｓ Ｍａｎａｇｅｒ（Ｒ）製品によるＵＲＬベース・アクセス制御を実現するシステムの一例を以下に簡単に説明する。
【０００８】
現在のＩＢＭ Ｔｉｖｏｌｉ Ａｃｃｅｓｓ Ｍａｎａｇｅｒ（Ｒ）によるＵＲＬベース・アクセス制御を実現するシステムの一例は、プロキシ・サーバ、クライアントおよびウェブ・サーバを含む。プロキシ・サーバはインターネットを介してクライアントとネットワーク接続されている。プロキシ・サーバは、イントラネットを介してウェブ・サーバとネットワーク接続されている。
【０００９】
プロキシ・サーバは、アクセス制御リスト（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔの略。以下、ＡＣＬという。）を備える。ＡＣＬは、図６に例示するような、あるＵＲＬに対するアクセスの許可／不許可を決定するために必要な情報を含むリストである。図６に例示するＡＣＬ１０７には、"http://www.ibm.com/CustomApp?confidential"および"http://www.ibm.com/CustomApp?一般文書"がアクセスが許されないＵＲＬ（アクセス禁止ＵＲＬ）としてリストされている。
【００１０】
プロキシ・サーバは、クライアントからアクセス要求（周知のＨＴＴＰプロトコルに従うＨＴＴＰリクエストとして実現され得る）を受信する。その後、プロキシ・サーバは、アクセス要求の要求先ＵＲＬの文字列とＡＣＬを解釈して得られたアクセス禁止ＵＲＬの文字列の照合を行い、当該アクセス要求に対してアクセス許可／不許可を判定する。アクセス要求のアクセスが許可された場合は、プロキシ・サーバは、当該アクセス要求をウェブ・サーバに中継（転送）する。中継されたアクセス要求を受信したウェブ・サーバは、当該アクセス要求に対して返答データをプロキシ・サーバに送信する。プロキシ・サーバは、受信した返答データを更にクライアントに中継する。このようにして、クライアントは所望の返答データを受信し、一連の処理（セッション）を終了する。
【００１１】
また、照合の結果、アクセス要求のアクセスが許可されない場合は、プロキシ・サーバは当該アクセス要求をウェブ・サーバに中継せず、クライアントにアクセス禁止のメッセージを返信し、セッションを終了する。
【００１２】
具体的には、例えば、要求先ＵＲＬを"http://www.ibm.com/CustomApp?confidential"とするアクセス要求がクライアントからネットワークに送出されたとする。この場合は、ＡＣＬに当該ＵＲＬ（"http://www.ibm.com/CustomApp?confidential"）がアクセス禁止ＵＲＬとしてリストされているので、プロキシ・サーバで照合が行われると、プロキシ・サーバはアクセスが許されないと判定する。アクセス要求はウェブ・サーバに中継されず、クライアントは当該ＵＲＬの指し示すリソースを入手することができない。
【００１３】
また、要求先ＵＲＬを"http://www.ibm.com/CustomApp?public"とするアクセス要求がクライアントからネットワークに送出された場合を考える。この場合、ＡＣＬに当該ＵＲＬ（"http://www.ibm.com/CustomApp?public"）がアクセス禁止ＵＲＬとしてリストされていないので、プロキシ・サーバで照合が行われると、プロキシ・サーバはアクセスが許されると判定する。アクセス要求はウェブ・サーバに中継され、クライアントは当該ＵＲＬの指し示すネットワーク上のアドレス・ロケーションに存在するリソース（例えば、ウェブ・ページのデータ）を入手する。
【００１４】
現在のＩＢＭ Ｔｉｖｏｌｉ Ａｃｃｅｓｓ Ｍａｎａｇｅｒ（Ｒ）によるＵＲＬベース・アクセス制御を実現するシステムの一例においては、上記の手法で、クライアントからウェブ・サーバへのアクセス要求は制御される。
【００１５】
ところで、クライアントのＨＴＴＰリクエストによるアクセス要求は、クライアントにおいて、要求先ＵＲＬの文字列に英数字などのいわゆるシングルバイト・コード以外の文字（例えば、ひらがなや漢字の日本語などのようないわゆる「ダブルバイト・コード」）やコンピュータには可読だが人間には可読でない文字（いわゆる「バイナリ・コード」））を含めてＨＴＴＰリクエストを生成することが許されている（少なくとも、明示的には禁止されていない）。
【００１６】
ところが、要求先ＵＲＬの文字列にシングルバイト・コード以外が含められたアクセス要求（ＨＴＴＰリクエスト）を、ネットワークにそのまま送出することは、ＨＴＴＰプロトコルの規約上、一般的に許されていない。よって、クライアントは、シングルバイト・コード以外が含められた要求先ＵＲＬの文字列を適当なエンコード方式に従ってエンコード処理し、シングルバイト・コードのみを含む文字列を要求先ＵＲＬとするアクセス要求をネットワークに送出しなければならない。
【００１７】
具体的には、例えば、クライアントにおいて、ダブルバイト・コードである日本語「一般文書」を含む"http://www.ibm.com/CustomApp?一般文書"を要求先ＵＲＬとするアクセス要求が生成され、エンコード方式にＵＴＦ−８が採用されたとする。この場合、要求先ＵＲＬの文字列は、シングル・コードのみからなる"http://www.ibm.com/CustomApp?%E4%B8%80%E8%88%AC%E6%96%87%E6%9B%B8"という文字列にエンコードされて、ネットワークに送出される。なお、ＵＴＦ−８は、インターネット上で最も広く使用されている、当業者にとって周知のエンコード方式である。
【００１８】
次に、プロキシ・サーバは、エンコードされた要求先ＵＲＬ（"http://www.ibm.com/CustomApp?%E4%B8%80%E8%88%AC%E6%96%87%E6%9B%B8"）を含むアクセス要求を受信して要求先ＵＲＬの文字列をデコードする。その後、デコードされた要求先ＵＲＬの文字列（"http://www.ibm.com/CustomApp?一般文書"）とＡＣＬを使用して得たアクセス禁止ＵＲＬの文字列と照合し、アクセスの許可／不許可を判定する。図６に例示するＡＣＬには、当該ＵＲＬ（"http://www.ibm.com/CustomApp?一般文書"）が、アクセス禁止ＵＲＬとしてリストされているので、プロキシ・サーバはアクセスが許されないと判断し、アクセス要求が中継しない。
【００１９】
しかし、エンコード方式は、ＵＴＦ−８だけでなく、当業者に周知なものだけを挙げても、例えば、Ｓｈｉｆｔ−ＪＩＳ、ＥＵＣ（Ｅｘｔｅｎｄｅｄ Ｕｎｉｘ Ｃｏｄｅ）など、様々なものが存在する。そのため、図７を見れば明らかなように、シングルバイト・コード以外が含められたＵＲＬをエンコード処理した結果の文字列は、必ずしも一意ではない。換言すれば、ウェブ・サーバ上のあるリソースを呼び出すためにクライアントからネットワークに送出されるアクセス要求のエンコードされた要求先ＵＲＬの表現は、クライアントが採用したエンコード方式によって異なる。
【００２０】
その結果、従来のＵＲＬベース・アクセス制御を採用するプロキシ・サーバにおけるアクセス許可／不許可の判定で、エンコードされたＵＲＬ文字列を使うことはセキュリティ・ホールを生じる可能性がある。例えば、プロキシ・サーバにおいて、アクセス禁止ＵＲＬを要求先ＵＲＬとするアクセス要求に対してブラウザでＳｈｉｆｔ−ＪＩＳでエンコードを行ったとする。その場合に、プロキシで誤ってＥＵＣでデコードを行ってアクセスの許可／不許可を判定することもあり得る。そのような場合、そのアクセス要求は、アクセスが許されないにもかかわらずプロキシ・サーバでのアクセス制御をすり抜けてしまうことがある。
【００２１】
さらに状況を悪化させているのは、ダブルバイト・コード（日本語等）を含むＨＴＴＰリクエストの要求先ＵＲＬの文字列に対して、複数のエンコード方式の使用を許すウェブ・サーバ構築ソフトウェア製品があるということである。例えば、マイクロソフト社のＭｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｅｒ（Ｒ）（インターネット・インフォメーション・サーバ、ＩＩＳ）では、"http://www.ibm.com/CustomApp?一般文書"というＵＲＬに存在するリソースを呼び出す場合は、ＵＲＬ中の「一般文書」の部分を、ＵＴＦ−８エンコード方式で表現したＵＲＬも受容するし、Ｓｈｉｆｔ−ＪＩＳエンコード方式で表現されたＵＲＬも受容する。
【００２２】
以上より、複数のエンコード方式が採用されることによるプロキシ・サーバでのアクセス制御のすり抜けを防ぐために、アクセス要求の要求先ＵＲＬのエンコード方式を判別し、プロキシ・サーバにおいて判別したエンコード方式に従ってデコードを行いアクセス制御を行うことに対する現実の要求があることが理解されるであろう。
【００２３】
また、他の従来技術である特開２０００−３３０８５号公報（特許文献１）は、指定されたＵＲＬに対するアクセスを許可されているのか否かを確認するセキュリティ管理部３３を備える情報送受信システム３０を開示する。しかし、特開２０００−３３０８５号公報には、シングルバイト・コード以外がＵＲＬの文字列に含まれる場合について、なんら言及されていない。
【００２４】
さらに、他の従来技術である特開２０００−２０４４４号公報（特許文献２）は、ＵＲＬに任意の文字列（漢字、ひらがな、カタカナ、記号など）を含むことを可能とする機能拡張装置を開示する。しかし、任意の文字列を含むことを可能としてＵＲＬの文字列の表現力を高めることに終始しており、漢字等が含まれるＵＲＬに対してアクセス制御を行うことについて、なんら言及はない。
【００２５】
【特許文献１】
特開２０００−３３０８５号公報
【特許文献２】
特開２０００−２０４４４号公報
【００２６】
【発明が解決しようとする課題】
本発明の１つの目的は、よりセキュア（安全）な、プロキシ・サーバにおけるアクセス制御を実現することである。
【００２７】
本発明の他の目的は、エンコードされた文字列を要求先のアドレス・ロケーションとして含むアクセス要求に対する、よりセキュアな、プロキシ・サーバにおけるアクセス制御を実現することである。
【００２８】
本発明の他の目的は、よりセキュアな、プロキシ・サーバにおけるＵＲＬベースのアクセス制御を実現することである。
【００２９】
本発明の他の目的は、シングルバイト・コード以外の文字が含まれるＵＲＬを要求先ＵＲＬとするアクセス要求に対する、よりセキュアな、プロキシ・サーバにおけるアクセス制御を実現することである。
【００３０】
【課題を解決するための手段】
上述の目的は、クライアントのアクセス要求をサーバに中継し、アクセス要求に対するサーバの返答データをクライアントに中継するプロキシ・サーバであって、プロキシ・サーバが中継した返答データのアドレス・ロケーションおよび当該返答データのエンコード方式を記憶する手段と、当該アクセス要求が生成される以前にクライアントが受信した返答データのアドレス・ロケーションと当該返答データのエンコード方式でエンコードされた要求先アドレス・ロケーションを含むアクセス要求をクライアントから受信する手段と、アクセス要求に含まれる返答データのアドレス・ロケーションと記憶する手段に記憶されたアドレス・ロケーションを照合する手段と、照合が成功した場合に、記憶する手段に記憶されたエンコード方式で、アクセス要求に含まれるエンコードされた要求先アドレス・ロケーションの文字列をデコードする手段とを含むプロキシ・サーバによって達成される。
【００３１】
前述のプロキシ・サーバには、デコードされた要求先アドレス・ロケーションの文字列を用いて、アクセス要求のアクセス許可／不許可を判定する手段と、判定する手段が、前記アクセス要求をアクセスが許可されると判定した場合に、当該アクセス要求をサーバに送信する手段とを更に含むようにすることが可能である。
【００３２】
また、前述のプロキシ・サーバにおいては、アクセス要求が含む、以前にクライアントが受信した返答データのアドレス・ロケーションが、クライアントが直前にアクセスしたアドレス・ロケーションであるようにすることもできる。
【００３３】
さらに、前述のプロキシ・サーバにおいては、サーバから受信した返答データを解析することによって、返答データのアドレス・ロケーションおよび当該返答データのエンコード方式の情報を入手して、各々を記憶手段に記憶するようにすることも可能である。
【００３４】
前述のプロキシ・サーバにおいては、アクセス要求がＨＴＴＰリクエストであり、アドレス・ロケーションがＵＲＬであり、返答データがウェブ・ページであり、返答データのエンコード方式が当該返答データのｃｈａｒｓｅｔの属性値であり、アクセス要求に含まれる前記返答データのアドレス・ロケーションがｒｅｆｅｒｅｒの属性値であり、サーバがウェブ・サーバであるようにすることができる。好適には、クライアントとプロキシ・サーバがインターネットでネットワーク接続され、プロキシ・サーバとサーバがイントラネットでネットワーク接続される。また、エンコード方式は、ＵＴＦ−８、ＥＵＣ、Ｕｎｉｃｏｄｅ、Ｓｈｉｆｔ−ＪＩＳのいずれかであるようにすることが可能である。
【００３５】
なお、本発明は前述した「プロキシ・サーバ（プロキシ機能を持つコンピュータ・システム）」としての発明の他、「アクセス制御方法」および「アクセス制御プログラム（コンピュータ・プログラム）」としての発明として把握することも可能である。
【００３６】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。ただし、本発明は多くの異なる態様で実施することが可能であり、本実施の形態の記載内容に限定して解釈すべきではない。なお、実施の形態の全体を通して同じ要素には同じ番号を付している。
【００３７】
本実施の形態では、主にアクセス制御の方法またはシステムについて説明するが、当業者であれば明らかな通り、本発明はコンピュータで使用可能なプログラムとしても実施できる。したがって、本発明は、ハードウェアとしての実施形態、ソフトウェアとしての実施形態またはソフトウェアとハードウェアとの組合せの実施形態をとることができる。プログラムは、ハードディスク、ＣＤ−ＲＯＭ、光記憶装置または磁気記憶装置などの任意のコンピュータ可読媒体に記録できる。
【００３８】
また、本実施の形態では、プロキシ・サーバがリバース・プロキシとして機能する場合を想定して本発明を説明している。しかし、本発明の適用対象はリバース・プロキシに限定されず、フォワード・プロキシの場合を含め、ＵＲＬを用いたアクセス制御を行うシステムであればどのようなシステムにおいても本発明を適用し得ることに留意されたい。
【００３９】
本実施の形態では、ＵＲＬの文字列を用いてアクセス制御を行っている。しかし、当業者には自明であるが、ネットワーク上のリソースのアドレス・ロケーションを文字列で表現するシステムであれば、どのようなシステムであっても本発明を適用し得ることは勿論である。
【００４０】
[システム概念図]
図１は、本発明のアクセス制御方法を適用するシステムの構成の一例を示した概念図である。本実施の形態のシステムは、インターネット２００およびイントラネット４００にネットワーク接続されたプロキシ・サーバ１００を含む。クライアント３００はインターネット２００にネットワーク接続されている。ウェブ・サーバ５００はイントラネット４００にネットワーク接続されている。
【００４１】
本発明の実施の形態では、プロキシ・サーバ１００は、クライアント３００からウェブ・サーバ５００へのアクセス要求をインターネット２００を介して受信する。好適には、アクセス要求は、当業者に周知のＨＴＴＰリクエストとして実現される。プロキシ・サーバ１００は、受信したアクセス要求がウェブ・サーバ５００へ中継（転送）が許されるものかどうかを判定する。中継が許されると判断した場合、プロキシ・サーバ１００は、当該アクセス要求をウェブ・サーバ５００にイントラネット４００を介して中継する。
【００４２】
また、本発明の実施の形態では、プロキシ・サーバ１００は、中継したアクセス要求に対する返答データをウェブ・サーバ５００からイントラネット４００を介して受信し、受信した返答データをクライアント３００にインターネット２００を介して中継する。
【００４３】
本発明の実施の形態では、クライアント３００は、ウェブ・サーバ５００から所望のデータを入手するために、インターネット２００を介してプロキシ・サーバ１００にアクセス要求を送信する。クライアント３００は、プロキシ・サーバ１００からインターネット２００を介して、所望の返答データを受け取る。クライアント３００は、周知のインターネットに接続可能な端末で当業者は適宜実現可能である。クライアント３００とインターネット２００の接続は、ダイアルアップ接続等によりＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｅｒ、図示せず）を介して行うとよい。クライアント３００からＩＳＰへの接続はダイアルアップ接続に限られず、専用線、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）、ＣＡＴＶ（Ｃａｂｌｅ Ｔｅｌｅｖｉｓｉｏｎ）等を用いた常時接続により行ってもよい。
【００４４】
本発明の実施の形態では、ウェブ・サーバ５００は、プロキシ・サーバ１００から転送されたクライアント３００のアクセス要求に応じて、適切な返答データをプロキシ・サーバ１００に返す。ウェブ・サーバ５００の構築方法は一般に周知であり、具体的には、マイクロソフト社が提供するマイクロソフト社のＭｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｅｒ（Ｒ）（インターネット・インフォメーション・サーバ、ＩＩＳ）やフリーソフトウェアであるＡｐａｃｈｅなどのソフトウェアを使用して当業者は適宜実現可能である。
【００４５】
本発明の実施の形態では、インターネット２００はクライアント３００とプロキシ・サーバ１００を接続する通信経路として機能する。また、イントラネット４００はプロキシ・サーバ１００とウェブ・サーバ５００を接続する通信経路として機能する。当業者に周知の通り、インターネット２００およびイントラネット４００は、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を用いてコンピュータ・システム間を接続する。インターネット２００およびイントラネット４００ではグローバル・アドレスまたはローカル・アドレスで表されるＩＰアドレスによって相互に通信するコンピュータが特定される。
【００４６】
[ハードウェア構成]
本発明の実施の形態において、プロキシ・サーバ１００は、図２のようなハードウェア構成を有するコンピュータ・システムで実現することができる。コンピュータ・システムは、中央処理装置（ＣＰＵ）１とメインメモリ４を含んでいる。ＣＰＵ１とメインメモリ４は、バス２を介して、補助記憶装置としてのハードディスク装置３と接続されている。また、フレキシブルディスク装置２０、ＭＯ装置２８、ＣＲ−ＲＯＭ装置２６、２９などのリムーバブルストレージ（記録メディアを交換可能な外部記憶システム）が関連するフレキシブルディスク・コントローラ１９、ＩＤＥコントローラ２５、ＳＣＳＩコントローラ２７などを介してバス２へ接続されている。
【００４７】
フレキシブルディスク装置２０、ＭＯ装置２８、ＣＲ−ＲＯＭ装置２６、２９などのリムーバブルストレージには、それぞれフレキシブルディスク、ＭＯ、ＣＤ−ＲＯＭなどの記憶媒体が挿入され、このフレキシブルディスク等やハードディスク装置１３、ＲＯＭ１４には、オペレーティング・システムと協働してＣＰＵ等に命令を与え、本発明を実施するためのコンピュータ・プログラムのコードを記録することができる。メインメモリ４にロードされることによってコンピュータプログラムは実行される。コンピュータ・プログラムは圧縮し、また複数に分割して複数の媒体に記録することもできる。
【００４８】
コンピュータ・システムは、さらに、ユーザ・インターフェイス・ハードウェアとして、マウス等のポインティング・デバイス７、キーボード６や視覚データをユーザに提示するためのディスプレイ１２を有することができる。また、パラレルポート１６を介してプリンタ（図示せず）と接続することや、シリアルポート１５を介してモデム（図示せず）を接続することが可能である。コンピュータ・システムは、シリアルポート１５及びモデムを介し、また、通信アダプタ１８（イーサネット（Ｒ）・カードやトークンリング・カード）等を介してネットワークに接続し、他のコンピュータ等と通信を行うことが可能である。
【００４９】
スピーカ２３は、オーディオ・コントローラ２１によってＤ／Ａ変換（デジタル／アナログ変換）された音声信号をアンプ２２を介して受け取り、音声として出力する。また、オーディオ・コントローラ２１は、マイクロフォン２４から受け取った音声情報をＡ／Ｄ変換（アナログ／デジタル変換）し、システム外部の音声情報をシステムに取り込むことを可能にしている。
【００５０】
以上の説明により、本発明の実施の形態におけるプロキシ・サーバ１００は、メインフレーム、ワークステーション、通常のパーソナル・コンピュータ（ＰＣ）、ラップトップＰＣ、ノートブックＰＣ、パームトップＰＣ、ネットワークコンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄａｔａ Ａｓｓｉｓｔａｎｔ）等の情報処理装置、または、これらの組み合わせによって実現されることが容易に理解されるであろう。ただし、これらの構成要素は例示であり、そのすべての構成要素が本発明の必須構成要素となるわけではない。
【００５１】
クライアント３００、ウェブ・サーバ５００も同様のハードウェア構成を有するコンピュータ・システムによって実現可能である。本発明の実施に使用されるプロキシ・サーバ、クライアント、ウェブ・サーバの各ハードウェア構成要素を、複数のマシンを組み合わせ、それらに機能を配分し実施する等の種々の変更は当業者によって容易に想定され得るものであり、それらの変更は、当然に本発明の思想に包含される概念である。
【００５２】
プロキシ・サーバ１００、クライアント３００、ウェブ・サーバ５００には、ハードウェア資源を活用するためのオペレーティングシステムあるいはミドルウェア等のソフトウェアを備えることが好ましい。プロキシ・サーバ１００およびウェブ・サーバ５００は、好適には、インターナショナル・ビジネス・マシーンズが提供するオペレーティング・システムであるＡＩＸ（Ｒ）を備えたサーバ・コンピュータであるｅＳｅｒｖｅｒ ｐＳｅｒｉｅｓ（Ｒ）で実現される。また、クライアント３００は、好適には、マイクロソフト社が提供するオペレーティング・システムであるＷｉｎｄｏｗｓ２０００（Ｒ）を備えたパーソナル・コンピュータ（ＰＣ）で実現される。
【００５３】
[機能ブロック図]
図３に本実施の形態のシステムの機能ブロック図を示す。システムは、プロキシ・サーバ１００、クライアント３００およびびウェブ・サーバ５００を含む。本実施の形態のシステムにおいては、図３の各機能ブロックは図２に示すハードウェア構成を持つコンピュータ・システムであるプロキシ・サーバ１００、クライアント３００、ウェブ・サーバ５００のハードウェア資源と各ハードウェア資源において実行されるオペレーティング・システム、アクセス制御プログラムなどのソフトウェアが協働することによって実現される。
【００５４】
本実施の形態のシステムにおいては、プロキシ・サーバ１００は、受信手段１０１、アクセス許可／不許可判定手段１０２、送信手段１０３、第１のＵＲＬ比較手段１０４、デコーダ１０５、第２のＵＲＬ比較手段１０６、アクセス制御リスト（ＡＣＬ）１０７、ＵＲＬ記憶手段１０８、エンコード方式記憶手段１０９、受信手段１１０及び送信手段１１１を含む。
【００５５】
受信手段１０１は、クライアント３００からのアクセス要求を受信する。送信手段１０３は、アクセス許可／不許可判定手段１０２がアクセス要求をアクセス許可と判定した場合に、ウェブ・サーバ５００に当該アクセス要求をイントラネット４００を介して転送する。
【００５６】
受信手段１１０は、ウェブ・サーバ５００からの返答データを受信する。受信手段１１０によって受信された返答データは解析され、ウェブ・サーバ５００内の返答データの存在するＵＲＬの文字列および当該返答データのエンコード方式（文字コード）の属性値が各々ＵＲＬ記憶手段１０８およびエンコード方式記憶手段１０９に記憶される。好適には、返答データがＨＴＭＬフォーマットで記述されたウェブ・ページであり、ウェブ・ページの文字コードを表しているウェブ・ページ内の”ｃｈａｒｓｅｔ”という属性の値が、エンコード方式記憶手段１０９に記憶される。送信手段１１１は、受信手段１１０によって受信された返答データをクライアント３００へインターネット２００を介して転送する。
【００５７】
第１のＵＲＬ比較手段１０４は、受信手段１０１によって受信されたアクセス要求に含まれる、クライアント３００のブラウザ３１０よって含められた、クライアント３００が当該アクセス要求が生成される以前にダウンロード（アクセス）した返答データの存在するＵＲＬの文字列とＵＲＬ記憶手段に記憶されたＵＲＬの文字列を照合する。好適には、クライアント３００のブラウザ３１０よってアクセス要求に含められたＵＲＬの文字列は、ＨＴＴＰリクエストにおけるｒｅｆｅｒｅｒという属性の値としてアクセス要求に含められた、クライアント３００が直前にダウンロードした返答データのＵＲＬの文字列である。
【００５８】
第１のＵＲＬ比較手段１０４による照合が一致した場合、第１のＵＲＬ比較手段１０４は、エンコード方式記憶手段１０９に記憶されたエンコード方式で受信手段１０１によって受信されたアクセス要求の要求先ＵＲＬの文字列をデコードすべきことをデコーダ１０５に命令する。デコーダ１０５は、エンコードされたアクセス要求の要求先ＵＲＬの文字列を、後述する方法（ロジック）に従って決定されたエンコード方式でデコードする。
【００５９】
ＡＣＬ１０７は、プロキシ・サーバ１００がアクセス要求の要求先ＵＲＬと照合することによりアクセス許可／不許可を判定するための情報を記述したリストである。図９に例示する本発明の実施形態におけるＡＣＬ１０７は、"http://www.ibm.com/CustomApp?confidential"、"http://www.ibm.com/CustomApp?一般文書"がアクセス禁止ＵＲＬとしてリストされている。
【００６０】
なお、図６に例示される本発明の実施形態におけるＡＣＬはアクセス禁止ＵＲＬをリストするように構成されているが、逆にアクセスが許されるＵＲＬをリストするように構成してもよいし、メタ・キャラクタ等を用いて表現するように構成してもよい。すなわち、所定の規則に従い解釈を施すことで、プロキシ・サーバがアクセス許可／不許可を判断するための情報を得ることができるものであれば、ＡＣＬはどのような形式であっても本発明の技術的思想に含まれることに留意されたい。
【００６１】
第２のＵＲＬ比較手段１０６は、デコーダから出力された要求先ＵＲＬの文字列と、ＡＣＬを使用して得られたアクセス許可／不許可の情報を照合する。アクセス許可／不許可判定手段１０２は、第２のＵＲＬ比較手段１０６での照合の結果を使用して、アクセス要求に対するアクセス許可／不許可を判定する。
【００６２】
クライアント３００は、ブラウザ３１０を含む。ブラウザ３１０は、送信手段３１１、アクセス要求生成手段３１２を含む。アクセス要求生成手段３１２によって、アクセス要求（ＨＴＴＰリクエスト）が生成される。アクセス要求生成手段３１２は、生成するアクセス要求に、クライアント３００が以前にダウンロード（アクセス）した返答データの存在するＵＲＬの文字列を含めることができる。好適には、直前にクライアント３００がダウンロード（アクセス）したデータ（ウェブ・ページ）、すなわち、ブラウザ３１０のページ表示手段３１３に現在表示されているウェブ・ページ）のＵＲＬの文字列がｒｅｆｅｒｅｒという属性の値として含められる。送信手段３１１は、生成されたアクセス要求をインターネット２００を介してプロキシ・サーバ１００に送信する。
【００６３】
クライアント３００のブラウザ３１０は、ページ表示手段３１３、受信手段３１４を更に含んでいる。受信手段３１４は、プロキシ・サーバ１００からインターネット２００を介して返答データを入手する。ページ表示手段３１３は、受信手段３１５によって受信された返答データを表示装置等を介してユーザに提示する。
【００６４】
なお、ブラウザ３１０は、マイクロソフト社のインターネット・エクスプローラ（Ｒ）、ネットスケープ・コミュニケーションズ社のネットスケープ・ナビゲータ（Ｒ）などの任意のウェブ・ブラウザで実現可能である。
【００６５】
本発明の実施形態においては、ウェブ・サーバ５００は、受信手段５０１、アクセス要求処理手段５０２、送信手段５０３を含む。受信手段５０２はプロキシ・サーバ１００から転送されたクライアント３００のアクセス要求をイントラネット４００を介して受信し、アクセス要求処理手段５０２へ引き渡す。アクセス要求処理手段５０２は、受信したアクセス要求に応答して、データベース等の記憶装置（図示せず）などから適切なデータを取り出し、加工するなどの処理を行って返答データを生成し、送信手段５０３に引き渡す。送信手段５０３は、イントラネット４００を介して返答データをプロキシ・サーバ１００に送信する。
【００６６】
[アクセス制御の処理の流れ]
次に、初期状態のクライアント３００がウェブ・サーバ５００のホームページ（ＵＲＬを"http://www.ibm.com"とする）にアクセス要求を行った後に、当該ホームページ内のＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）フィールドを使用して、アクセス禁止ＵＲＬである"http://www.ibm.com/AppCustom?一般文書"へアクセスを試みた場合のシステムの動作について、図４および図６乃至図８のフローチャートを参照して説明をする。
【００６７】
まず、クライアント３００がウェブ・サーバ５００のホームページである"http://www.ibm.com"にアクセス要求を行ったときのシステムの動作（以下、第１のセッションという）を図４のフローチャートを使用して説明する。処理は図４のステップ４０００からスタートする。ステップ４０１０では、クライアントが、"http://www.ibm.com"を要求先ＵＲＬとするアクセス要求を生成する。ブラウザ３１０は、（１）ユーザがマウス等を操作してブラウザに表示されたウェブ・ページのハイパーリンクをクリックする、（２）ユーザがキーボード等を操作して直接ＵＲＬをブラウザのアドレス・バーに入力する、あるいは（３）アプレット等のプログラムがブラウザにＵＲＬ遷移イベントを自動的に発生させる、などを契機としてアクセス要求を生成する。
【００６８】
本実施の形態においては、アクセス要求はＨＴＴＰプロトコルに従ってなされる。ＨＴＴＰプロトコルはＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）により管理されるＲＦＣ２６１６にＨＴＴＰ１．１が規定されており、当業者には周知である。もちろんＨＴＴＰ１．０など、他のバージョンのＨＴＴＰプロトコルを使用しても本発明は実現可能である。
【００６９】
生成されたアクセス要求は、クライアント３００からプロキシ・サーバ１００にインターネット２００を介して送信される。第１のセッションにおいては、アクセス要求の要求先ＵＲＬの文字列（"http://www.ibm.com"）はシングルバイト・コードのみからなるので、要求先ＵＲＬの文字列のエンコード処理はされず、生成されたアクセス要求はそのままネットワークに送出され、ＤＮＳサーバ（図示せず）でＩＰアドレス変換がなされ、プロキシ・サーバ１００に到着する。
【００７０】
ステップ４０２０では、プロキシ・サーバ１００が、アクセス要求の要求先ＵＲＬの文字列をＡＣＬを使用して得られたアクセス許可／不許可の情報を照合して、当該アクセス要求のアクセス許可／不許可を判定する。なお、アクセス要求の要求先ＵＲＬの文字列（"http://www.ibm.com"）はシングルバイト・コードのみからなるので、第１のセッションのアクセス許可／不許可の判定においてはデコード処理は不要である（すなわち、デコーダは要求先ＵＲＬの文字列をそのまま出力する）ことに留意されたい。
【００７１】
本発明の実施の形態の第１のセッションでは、図６に示されるように、アクセス制御リストでは"http://www.ibm.com"はアクセス禁止ＵＲＬとされていないので、アクセス要求は、アクセス許可と判定される。アクセス許可と判定されたことに応答して、プロキシ・サーバ１００は当該アクセス要求をイントラネット４００を介してウェブ・サーバ５００へ転送する。
【００７２】
処理はステップ４０３０へ進み、プロキシ・サーバ１００からアクセス要求を受信したウェブ・サーバ５００は、当該アクセス要求を処理して返答データを作成し、プロキシ・サーバ１００へ送信する。処理はステップ４１４０へ進み、返答データをウェブ・サーバ５００から受信したプロキシ・サーバ１００は、その返答データのＵＲＬ（"http://www.ibm.com"）とエンコード方式（すなわち、ｃｈａｒｓｅｔの属性値）を記憶し保持する。本発明の実施の形態では、当該返答データのエンコード方式は、Ｓｈｉｆｔ−ＪＩＳであるとする。
【００７３】
処理はステップ４０５０へ進み、プロキシ・サーバ１００が、返答データをクライアント３００へ送信する。クライアント３００はウェブ・サーバ５００のホームページ（"http://www.ibm.com"）のウェブ・ページのデータを受信し、クライアント３００のブラウザ３１０に当該データの表示を行う。本発明の実施の形態における、返答データのブラウザ表示のイメージを図５に示す。処理はステップ４０６０へ進み、"http://www.ibm.com"を要求先ＵＲＬとするアクセス要求に対する第１のセッションは終了する。
【００７４】
次に、図５に示すブラウザ３１０に表示されたウェブ・ページ内のＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）フィールドを使用して、アクセス禁止ＵＲＬである"http://www.ibm.com/AppCustom?一般文書"へアクセスを試みた場合のシステムの動作（第２のセッション）について、図６のフローチャートを使用して説明をする。
【００７５】
本発明の実施形態においては、図５に示すブラウザ３１０に表示されたウェブ・ページ内のＣＧＩフィールド５０２０にキーボード等を使用して文字列が入力される。次に、マウスを使用してポインタをあわせてクリックを行うことによって送信ボタン５０３０を押し下げると、"http://www.ibm.com/CustomApp?文字列"（ＵＲＬ中の「文字列」はフィールド５０２０に入力された文字列を表している）を要求先ＵＲＬとし、クライアント３００が以前にダウンロード（アクセス）した返答データの存在するＵＲＬの文字列を含むアクセス要求が生成される。好適には、直前にダウンロードされたウェブ・ページ（すなわち、現在表示されているウェブ・ページ）のＵＲＬをｒｅｆｅｒｅｒという属性の値として含められる。また、生成されたアクセス要求の要求先ＵＲＬは、前述の以前にアクセス（ダウンロード）したデータのエンコード方式でエンコードされ、ネットワークへ送出される。この仕組みは、周知のＣＧＩ技術等によって、当業者は適宜容易に実現することができることに留意されたい。
【００７６】
処理はステップ６０００からスタートし、ステップ６０１０でブラウザ３１０に表示されたウェブ・ページ内の入力フィールド５０２０に文字列「一般文書」と入力され、送信ボタン５０３０が押し下げられる。すると、要求先ＵＲＬを"http://www.ibm.com/CustomApp?一般文書"とし、ｒｅｆｅｒｅｒを"http"//www.ibm.com"とするアクセス要求が生成する。
【００７７】
さらにステップ６０１０では、生成したアクセス要求の要求先ＵＲＬの文字列がエンコードされ、エンコードされたアクセス要求がクライアント３００からインターネット２００を介してプロキシ・サーバ１００に送信される。エンコードは、アクセス要求にそのＵＲＬが含められた、以前にダウンロードされたウェブ・ページのエンコード方式、すなわち、"http://www.ibm.com"のエンコード方式（ｃｈａｒｓｅｔ）であるＳｈｉｆｔ−ＪＩＳで行われる。
【００７８】
処理はステップ６０２０に進み、プロキシ・サーバ１００は、受信したアクセス要求のアクセス許可／不許可の判定を、図７および図８のフローチャートに従って行う。図７および図８のフローチャートは、後に詳述する。その結果、アクセス要求は、アクセス不許可と判定されるので、アクセス要求はウェブ・サーバ５００には中継されず、その代わりにプロキシ・サーバ１００からクライアント３００にアクセス不許可のメッセージが送信される。
【００７９】
処理はステップ６０３０へ進み、クライアント３００を操作するユーザにアクセス不許可の情報を伝えるために、クライアント３００はブラウザ３１０に受け取ったアクセス不許可のメッセージを表示する。処理はステップ６０４０へ進み、"http://www.ibm.com/CustomApp?一般文書"を要求先ＵＲＬとするアクセス要求に対する第２のセッションは終了する。
【００８０】
次に、図６に示す第２のセッションのステップ６０２０でのプロキシ・サーバ１００のアクセス許可／不許可の判定処理を図７および図８のフローチャートを使用して詳細に説明をする。
【００８１】
処理はステップ７０００からスタートし、ステップ７０１０でプロキシ・サーバ１００はクライアント３００からのアクセス要求を受信する。受信されたアクセス要求の要求先ＵＲＬは、エンコードされているのでデコード処理がなされる。ステップ７０２０において、要求先ＵＲＬがＵＴＦ−８でデコードできるかどうかが判定される。現在、インターネット上を流れるアクセス要求はほとんどがＵＴＦ−８でエンコードされており、最初にＵＴＦ−８でデコード処理を試みる方が処理効率が向上することが本発明者によって発見されている。
【００８２】
ステップ７０２０で要求先ＵＲＬがＵＴＦ−８でデコードできると判定された場合、処理はＹｅｓの矢印を通じてステップ７０３０へ進み、ＵＴＦ−８でデコード処理がされた後に、処理は更にステップ７１００へ進む。しかし、本発明の実施の形態では、要求先ＵＲＬはＳｈｉｆｔ−ＪＩＳでデコードされているので、ステップ７０２０での判定は失敗し、処理はＮｏの矢印を通じてステップ７０４０へ進む。
【００８３】
ステップ７０４０では、エンコード方式記憶手段１０９にエンコード方式（ｃｈａｒｓｅｔ）が記憶されているかどうかが判定される。本発明の実施の形態では、第１のセッションでエンコード方式記憶手段１０９にＳｈｉｆｔ−ＪＩＳという値が記憶されているので、処理はＹｅｓの矢印を通じてステップ７０５０へ進む。ステップ７０５０では、アクセス要求内のｒｅｆｅｒｅｒが、ＵＲＬ記憶手段１０８に記憶されたＵＲＬと一致するかどうかが判定される。
【００８４】
前述したようにＵＲＬ記憶手段１０８には、第１のセッションで"http://www.ibm.com"が記憶されており、また、アクセス要求内のｒｅｆｅｒｅｒにも、ステップ６０１０で"http"//www.ibm.com"が格納されているので、一致すると判定され、処理はＹｅｓの矢印を通じてステップ７０６０へ進む。ステップ７０６０では、エンコード方式記憶手段１０９にエンコード方式であるＳｈｉｆｔ−ＪＩＳでデコードが行われ、要求先ＵＲＬの文字列は正しく"http://www.ibm.com/CustomApp?一般文書"と戻される。デコードの後、処理は更にステップ７１００へ進む。
【００８５】
なお、仮に、ステップ７０４０または７０５０で判定に失敗した場合は、処理はＮｏの矢印を通じてステップ７０７０へ進み、アクセス要求によってアクセスしようとされているウェブ・サーバに対するあらかじめ設定されたデフォルトの文字コードがあるかどうかが判定される。ステップ７０７０でデフォルトの文字コードがあると判定された場合、処理はステップ７０８０へ進み、当該デフォルトの文字コードで要求先ＵＲＬの文字列がデコードされ、処理は更にステップ７１００へ進む。
【００８６】
また、本実施の形態においては、ステップ７０７０でデフォルトの文字コードがないと判定された場合は、処理はステップ７０９０へ進み、最後の選択肢として、プロキシ・サーバ１００で採用されている文字コードで要求先ＵＲＬの文字列がデコードされる。ステップ７０９０のデコードが行われた後、処理は更にステップ７１００へ進む。
【００８７】
説明を図８へ進め、ステップ７１００では、ステップ７０３０、７０６０、７０８０または７０９０でデコードされたアクセス要求の要求先ＵＲＬの文字列と、ＡＣＬ１０７を解釈して得られたアクセス禁止ＵＲＬの文字列が照合される。本発明の実施の形態においては、デコードされたアクセス要求の要求先ＵＲＬの文字列は、"http"//www.ibm.com/CustomApp?一般文書"である。また、図９に例示するＡＣＬ１０７には、"http"//www.ibm.com/CustomApp?一般文書"がアクセス禁止ＵＲＬとしてリストされているので、ステップ７１００における照合は一致することとなる。
【００８８】
処理はステップ７１１０へ進み、アクセス要求のアクセス許可／不許可がステップ７１００の照合結果を元に判定される。本発明の実施の形態では、照合が一致してアクセス不許可と判断されるので、処理はＮｏの矢印を通じてステップ７１２０へ進み、プロキシ・サーバ１００からクライアント３００に対してアクセス不許可のメッセージが返され、処理がステップ７１４０で終了する。
【００８９】
なお、ステップ７１００で照合が失敗し、ステップ７１１０でアクセス要求に対してアクセス許可と判定された場合には、処理はＹｅｓの矢印を通じてステップ７１３０へ進む。ステップ７１３０では、プロキシ・サーバ１００はアクセス要求をウェブ・サーバ５００へ転送し、ステップ７１４０で処理は終了する。
【００９０】
上記の本発明の好適な実施例は、説明を目的として記述されたものあって、すべての実施態様を記述するものではなく、実施例に開示された形式に発明を限定する意図ではない。上記の開示によれば、多くの変更例とバリエーションが実現可能である。本発明の範囲は発明の詳細な説明の記載により制限されるのではなく、特許請求の範囲により定まるものであることに留意されたい。上記の仕様、例、データにより本発明の一態様の製造および使用が完全に説明される。本発明の多くの実施例が本発明の精神と範囲を離れることなく実現される。
【００９１】
【効果】
以上から、本発明によれば、クライアントでエンコードされたアクセス要求の要求先ＵＲＬの文字列がプロキシ・サーバでより高い精度で正しくデコードされることが理解される。本発明によれば、よりセキュア（安全）なＵＲＬベース・アクセス制御が可能となるという効果を得ることができる。
【図面の簡単な説明】
【図１】 本発明のＵＲＬベース・アクセス制御方法を適用するシステム構成の一例を示した概念図である。
【図２】 本発明の実施の形態におけるプロキシ・サーバ、クライアント、ウェブ・サーバのハードウェア構成の一例を示した図である。
【図３】 本発明の実施の形態のシステムの機能ブロック図である。
【図４】 本発明の実施の形態のシステムの第１のセッションでの動作を示したフローチャートである。
【図５】 本発明の実施の形態におけるウェブ・サーバのホームページのブラウザ表示のイメージである。
【図６】 本発明の実施の形態のシステムの第２のセッションでの動作を示したフローチャートである。
【図７】 本発明の実施の形態のシステムのプロキシ・サーバでのアクセス制御の手順（前半部分）を示したフローチャートである。
【図８】 本発明の実施の形態のシステムのプロキシ・サーバでのアクセス制御の手順（後半部分）を示したフローチャートである。
【図９】 本発明の実施の形態のシステムのプロキシ・サーバが備えるアクセス制御リストのイメージである。
【図１０】日本語を含むＵＲＬのエンコード前後の文字列を示した対応図である。
【発明の属する技術分野】
一般的には、本発明はネットワーク・セキュリティ技術に関する。より具体的には、本発明はプロキシ・サーバにおけるアクセス制御技術に関する。
【０００２】
【従来の技術】
パーソナル・コンピュータ（ＰＣ）のような情報処理技術およびインターネット、イントラネットなどのネットワーク技術が普及し、ビジネス用途にそれらの技術が使用される機会が増している。その結果、不正アクセスによる顧客情報の漏洩などの危険が増大し、ネットワーク・セキュリティ技術に関心が非常に集まっている。
【０００３】
そのような背景の下で、インターネットのような外部ネットワークから社内ＬＡＮのようなイントラネット内のサーバへの不正アクセスを防止する必要が生じている。また、イントラネットから外部ネットワークへの不適切なアクセスを制限する必要もある。これらの必要のため、通常、外部ネットワークとイントラネットの間にプロキシ・サーバが設置される。
【０００４】
プロキシ・サーバは、外部ネットワーク上のコンピュータにアクセスしようとするイントラネット上のコンピュータに代わってサーバへのアクセス要求を中継する。このようなプロキシ・サーバの機能をフォワード・プロキシという。フォワード・プロキシとして機能する場合、プロキシ・サーバは、イントラネットからのアクセス要求を中継する際に、そのアクセス要求の中継の許可／不許可をチェックし、アクセス制御を行う。
【０００５】
また、プロキシ・サーバはイントラネット内のコンピュータにアクセスしようとする外部ネットワーク上のコンピュータに代わって、アクセス要求をイントラネット内のコンピュータに中継する。このようなプロキシ・サーバの機能をリバース・プロキシという。リバース・プロキシとして機能する場合も、プロキシ・サーバは、外部ネットワークからのアクセス要求を中継する際に、そのアクセス要求の中継の許可／不許可をチェックし、アクセス制御を行う。
【０００６】
現在、様々なプロキシ・サーバによるアクセス制御技術が存在する。プロキシ・サーバによるアクセス制御技術の１つとして、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒの略）をベースにしたアクセス制御（以下、ＵＲＬベース・アクセス制御という。）がある。なお、ＵＲＬは、インターネット、イントラネットのようなＴＣＰ／ＩＰネットワーク上のリソースのアドレス・ロケーションであり、所定の規則に従った任意の文字列で表現される。
【０００７】
ＵＲＬベース・アクセス制御を実現するソフトウェア製品として、インターナショナル・ビジネス・マシーンズが提供するＩＢＭ Ｔｉｖｏｌｉ Ａｃｃｅｓｓ Ｍａｎａｇｅｒ（Ｒ）製品が存在する。現在のＩＢＭ Ｔｉｖｏｌｉ Ａｃｃｅｓｓ Ｍａｎａｇｅｒ（Ｒ）製品によるＵＲＬベース・アクセス制御を実現するシステムの一例を以下に簡単に説明する。
【０００８】
現在のＩＢＭ Ｔｉｖｏｌｉ Ａｃｃｅｓｓ Ｍａｎａｇｅｒ（Ｒ）によるＵＲＬベース・アクセス制御を実現するシステムの一例は、プロキシ・サーバ、クライアントおよびウェブ・サーバを含む。プロキシ・サーバはインターネットを介してクライアントとネットワーク接続されている。プロキシ・サーバは、イントラネットを介してウェブ・サーバとネットワーク接続されている。
【０００９】
プロキシ・サーバは、アクセス制御リスト（Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｌｉｓｔの略。以下、ＡＣＬという。）を備える。ＡＣＬは、図６に例示するような、あるＵＲＬに対するアクセスの許可／不許可を決定するために必要な情報を含むリストである。図６に例示するＡＣＬ１０７には、"http://www.ibm.com/CustomApp?confidential"および"http://www.ibm.com/CustomApp?一般文書"がアクセスが許されないＵＲＬ（アクセス禁止ＵＲＬ）としてリストされている。
【００１０】
プロキシ・サーバは、クライアントからアクセス要求（周知のＨＴＴＰプロトコルに従うＨＴＴＰリクエストとして実現され得る）を受信する。その後、プロキシ・サーバは、アクセス要求の要求先ＵＲＬの文字列とＡＣＬを解釈して得られたアクセス禁止ＵＲＬの文字列の照合を行い、当該アクセス要求に対してアクセス許可／不許可を判定する。アクセス要求のアクセスが許可された場合は、プロキシ・サーバは、当該アクセス要求をウェブ・サーバに中継（転送）する。中継されたアクセス要求を受信したウェブ・サーバは、当該アクセス要求に対して返答データをプロキシ・サーバに送信する。プロキシ・サーバは、受信した返答データを更にクライアントに中継する。このようにして、クライアントは所望の返答データを受信し、一連の処理（セッション）を終了する。
【００１１】
また、照合の結果、アクセス要求のアクセスが許可されない場合は、プロキシ・サーバは当該アクセス要求をウェブ・サーバに中継せず、クライアントにアクセス禁止のメッセージを返信し、セッションを終了する。
【００１２】
具体的には、例えば、要求先ＵＲＬを"http://www.ibm.com/CustomApp?confidential"とするアクセス要求がクライアントからネットワークに送出されたとする。この場合は、ＡＣＬに当該ＵＲＬ（"http://www.ibm.com/CustomApp?confidential"）がアクセス禁止ＵＲＬとしてリストされているので、プロキシ・サーバで照合が行われると、プロキシ・サーバはアクセスが許されないと判定する。アクセス要求はウェブ・サーバに中継されず、クライアントは当該ＵＲＬの指し示すリソースを入手することができない。
【００１３】
また、要求先ＵＲＬを"http://www.ibm.com/CustomApp?public"とするアクセス要求がクライアントからネットワークに送出された場合を考える。この場合、ＡＣＬに当該ＵＲＬ（"http://www.ibm.com/CustomApp?public"）がアクセス禁止ＵＲＬとしてリストされていないので、プロキシ・サーバで照合が行われると、プロキシ・サーバはアクセスが許されると判定する。アクセス要求はウェブ・サーバに中継され、クライアントは当該ＵＲＬの指し示すネットワーク上のアドレス・ロケーションに存在するリソース（例えば、ウェブ・ページのデータ）を入手する。
【００１４】
現在のＩＢＭ Ｔｉｖｏｌｉ Ａｃｃｅｓｓ Ｍａｎａｇｅｒ（Ｒ）によるＵＲＬベース・アクセス制御を実現するシステムの一例においては、上記の手法で、クライアントからウェブ・サーバへのアクセス要求は制御される。
【００１５】
ところで、クライアントのＨＴＴＰリクエストによるアクセス要求は、クライアントにおいて、要求先ＵＲＬの文字列に英数字などのいわゆるシングルバイト・コード以外の文字（例えば、ひらがなや漢字の日本語などのようないわゆる「ダブルバイト・コード」）やコンピュータには可読だが人間には可読でない文字（いわゆる「バイナリ・コード」））を含めてＨＴＴＰリクエストを生成することが許されている（少なくとも、明示的には禁止されていない）。
【００１６】
ところが、要求先ＵＲＬの文字列にシングルバイト・コード以外が含められたアクセス要求（ＨＴＴＰリクエスト）を、ネットワークにそのまま送出することは、ＨＴＴＰプロトコルの規約上、一般的に許されていない。よって、クライアントは、シングルバイト・コード以外が含められた要求先ＵＲＬの文字列を適当なエンコード方式に従ってエンコード処理し、シングルバイト・コードのみを含む文字列を要求先ＵＲＬとするアクセス要求をネットワークに送出しなければならない。
【００１７】
具体的には、例えば、クライアントにおいて、ダブルバイト・コードである日本語「一般文書」を含む"http://www.ibm.com/CustomApp?一般文書"を要求先ＵＲＬとするアクセス要求が生成され、エンコード方式にＵＴＦ−８が採用されたとする。この場合、要求先ＵＲＬの文字列は、シングル・コードのみからなる"http://www.ibm.com/CustomApp?%E4%B8%80%E8%88%AC%E6%96%87%E6%9B%B8"という文字列にエンコードされて、ネットワークに送出される。なお、ＵＴＦ−８は、インターネット上で最も広く使用されている、当業者にとって周知のエンコード方式である。
【００１８】
次に、プロキシ・サーバは、エンコードされた要求先ＵＲＬ（"http://www.ibm.com/CustomApp?%E4%B8%80%E8%88%AC%E6%96%87%E6%9B%B8"）を含むアクセス要求を受信して要求先ＵＲＬの文字列をデコードする。その後、デコードされた要求先ＵＲＬの文字列（"http://www.ibm.com/CustomApp?一般文書"）とＡＣＬを使用して得たアクセス禁止ＵＲＬの文字列と照合し、アクセスの許可／不許可を判定する。図６に例示するＡＣＬには、当該ＵＲＬ（"http://www.ibm.com/CustomApp?一般文書"）が、アクセス禁止ＵＲＬとしてリストされているので、プロキシ・サーバはアクセスが許されないと判断し、アクセス要求が中継しない。
【００１９】
しかし、エンコード方式は、ＵＴＦ−８だけでなく、当業者に周知なものだけを挙げても、例えば、Ｓｈｉｆｔ−ＪＩＳ、ＥＵＣ（Ｅｘｔｅｎｄｅｄ Ｕｎｉｘ Ｃｏｄｅ）など、様々なものが存在する。そのため、図７を見れば明らかなように、シングルバイト・コード以外が含められたＵＲＬをエンコード処理した結果の文字列は、必ずしも一意ではない。換言すれば、ウェブ・サーバ上のあるリソースを呼び出すためにクライアントからネットワークに送出されるアクセス要求のエンコードされた要求先ＵＲＬの表現は、クライアントが採用したエンコード方式によって異なる。
【００２０】
その結果、従来のＵＲＬベース・アクセス制御を採用するプロキシ・サーバにおけるアクセス許可／不許可の判定で、エンコードされたＵＲＬ文字列を使うことはセキュリティ・ホールを生じる可能性がある。例えば、プロキシ・サーバにおいて、アクセス禁止ＵＲＬを要求先ＵＲＬとするアクセス要求に対してブラウザでＳｈｉｆｔ−ＪＩＳでエンコードを行ったとする。その場合に、プロキシで誤ってＥＵＣでデコードを行ってアクセスの許可／不許可を判定することもあり得る。そのような場合、そのアクセス要求は、アクセスが許されないにもかかわらずプロキシ・サーバでのアクセス制御をすり抜けてしまうことがある。
【００２１】
さらに状況を悪化させているのは、ダブルバイト・コード（日本語等）を含むＨＴＴＰリクエストの要求先ＵＲＬの文字列に対して、複数のエンコード方式の使用を許すウェブ・サーバ構築ソフトウェア製品があるということである。例えば、マイクロソフト社のＭｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｅｒ（Ｒ）（インターネット・インフォメーション・サーバ、ＩＩＳ）では、"http://www.ibm.com/CustomApp?一般文書"というＵＲＬに存在するリソースを呼び出す場合は、ＵＲＬ中の「一般文書」の部分を、ＵＴＦ−８エンコード方式で表現したＵＲＬも受容するし、Ｓｈｉｆｔ−ＪＩＳエンコード方式で表現されたＵＲＬも受容する。
【００２２】
以上より、複数のエンコード方式が採用されることによるプロキシ・サーバでのアクセス制御のすり抜けを防ぐために、アクセス要求の要求先ＵＲＬのエンコード方式を判別し、プロキシ・サーバにおいて判別したエンコード方式に従ってデコードを行いアクセス制御を行うことに対する現実の要求があることが理解されるであろう。
【００２３】
また、他の従来技術である特開２０００−３３０８５号公報（特許文献１）は、指定されたＵＲＬに対するアクセスを許可されているのか否かを確認するセキュリティ管理部３３を備える情報送受信システム３０を開示する。しかし、特開２０００−３３０８５号公報には、シングルバイト・コード以外がＵＲＬの文字列に含まれる場合について、なんら言及されていない。
【００２４】
さらに、他の従来技術である特開２０００−２０４４４号公報（特許文献２）は、ＵＲＬに任意の文字列（漢字、ひらがな、カタカナ、記号など）を含むことを可能とする機能拡張装置を開示する。しかし、任意の文字列を含むことを可能としてＵＲＬの文字列の表現力を高めることに終始しており、漢字等が含まれるＵＲＬに対してアクセス制御を行うことについて、なんら言及はない。
【００２５】
【特許文献１】
特開２０００−３３０８５号公報
【特許文献２】
特開２０００−２０４４４号公報
【００２６】
【発明が解決しようとする課題】
本発明の１つの目的は、よりセキュア（安全）な、プロキシ・サーバにおけるアクセス制御を実現することである。
【００２７】
本発明の他の目的は、エンコードされた文字列を要求先のアドレス・ロケーションとして含むアクセス要求に対する、よりセキュアな、プロキシ・サーバにおけるアクセス制御を実現することである。
【００２８】
本発明の他の目的は、よりセキュアな、プロキシ・サーバにおけるＵＲＬベースのアクセス制御を実現することである。
【００２９】
本発明の他の目的は、シングルバイト・コード以外の文字が含まれるＵＲＬを要求先ＵＲＬとするアクセス要求に対する、よりセキュアな、プロキシ・サーバにおけるアクセス制御を実現することである。
【００３０】
【課題を解決するための手段】
上述の目的は、クライアントのアクセス要求をサーバに中継し、アクセス要求に対するサーバの返答データをクライアントに中継するプロキシ・サーバであって、プロキシ・サーバが中継した返答データのアドレス・ロケーションおよび当該返答データのエンコード方式を記憶する手段と、当該アクセス要求が生成される以前にクライアントが受信した返答データのアドレス・ロケーションと当該返答データのエンコード方式でエンコードされた要求先アドレス・ロケーションを含むアクセス要求をクライアントから受信する手段と、アクセス要求に含まれる返答データのアドレス・ロケーションと記憶する手段に記憶されたアドレス・ロケーションを照合する手段と、照合が成功した場合に、記憶する手段に記憶されたエンコード方式で、アクセス要求に含まれるエンコードされた要求先アドレス・ロケーションの文字列をデコードする手段とを含むプロキシ・サーバによって達成される。
【００３１】
前述のプロキシ・サーバには、デコードされた要求先アドレス・ロケーションの文字列を用いて、アクセス要求のアクセス許可／不許可を判定する手段と、判定する手段が、前記アクセス要求をアクセスが許可されると判定した場合に、当該アクセス要求をサーバに送信する手段とを更に含むようにすることが可能である。
【００３２】
また、前述のプロキシ・サーバにおいては、アクセス要求が含む、以前にクライアントが受信した返答データのアドレス・ロケーションが、クライアントが直前にアクセスしたアドレス・ロケーションであるようにすることもできる。
【００３３】
さらに、前述のプロキシ・サーバにおいては、サーバから受信した返答データを解析することによって、返答データのアドレス・ロケーションおよび当該返答データのエンコード方式の情報を入手して、各々を記憶手段に記憶するようにすることも可能である。
【００３４】
前述のプロキシ・サーバにおいては、アクセス要求がＨＴＴＰリクエストであり、アドレス・ロケーションがＵＲＬであり、返答データがウェブ・ページであり、返答データのエンコード方式が当該返答データのｃｈａｒｓｅｔの属性値であり、アクセス要求に含まれる前記返答データのアドレス・ロケーションがｒｅｆｅｒｅｒの属性値であり、サーバがウェブ・サーバであるようにすることができる。好適には、クライアントとプロキシ・サーバがインターネットでネットワーク接続され、プロキシ・サーバとサーバがイントラネットでネットワーク接続される。また、エンコード方式は、ＵＴＦ−８、ＥＵＣ、Ｕｎｉｃｏｄｅ、Ｓｈｉｆｔ−ＪＩＳのいずれかであるようにすることが可能である。
【００３５】
なお、本発明は前述した「プロキシ・サーバ（プロキシ機能を持つコンピュータ・システム）」としての発明の他、「アクセス制御方法」および「アクセス制御プログラム（コンピュータ・プログラム）」としての発明として把握することも可能である。
【００３６】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。ただし、本発明は多くの異なる態様で実施することが可能であり、本実施の形態の記載内容に限定して解釈すべきではない。なお、実施の形態の全体を通して同じ要素には同じ番号を付している。
【００３７】
本実施の形態では、主にアクセス制御の方法またはシステムについて説明するが、当業者であれば明らかな通り、本発明はコンピュータで使用可能なプログラムとしても実施できる。したがって、本発明は、ハードウェアとしての実施形態、ソフトウェアとしての実施形態またはソフトウェアとハードウェアとの組合せの実施形態をとることができる。プログラムは、ハードディスク、ＣＤ−ＲＯＭ、光記憶装置または磁気記憶装置などの任意のコンピュータ可読媒体に記録できる。
【００３８】
また、本実施の形態では、プロキシ・サーバがリバース・プロキシとして機能する場合を想定して本発明を説明している。しかし、本発明の適用対象はリバース・プロキシに限定されず、フォワード・プロキシの場合を含め、ＵＲＬを用いたアクセス制御を行うシステムであればどのようなシステムにおいても本発明を適用し得ることに留意されたい。
【００３９】
本実施の形態では、ＵＲＬの文字列を用いてアクセス制御を行っている。しかし、当業者には自明であるが、ネットワーク上のリソースのアドレス・ロケーションを文字列で表現するシステムであれば、どのようなシステムであっても本発明を適用し得ることは勿論である。
【００４０】
[システム概念図]
図１は、本発明のアクセス制御方法を適用するシステムの構成の一例を示した概念図である。本実施の形態のシステムは、インターネット２００およびイントラネット４００にネットワーク接続されたプロキシ・サーバ１００を含む。クライアント３００はインターネット２００にネットワーク接続されている。ウェブ・サーバ５００はイントラネット４００にネットワーク接続されている。
【００４１】
本発明の実施の形態では、プロキシ・サーバ１００は、クライアント３００からウェブ・サーバ５００へのアクセス要求をインターネット２００を介して受信する。好適には、アクセス要求は、当業者に周知のＨＴＴＰリクエストとして実現される。プロキシ・サーバ１００は、受信したアクセス要求がウェブ・サーバ５００へ中継（転送）が許されるものかどうかを判定する。中継が許されると判断した場合、プロキシ・サーバ１００は、当該アクセス要求をウェブ・サーバ５００にイントラネット４００を介して中継する。
【００４２】
また、本発明の実施の形態では、プロキシ・サーバ１００は、中継したアクセス要求に対する返答データをウェブ・サーバ５００からイントラネット４００を介して受信し、受信した返答データをクライアント３００にインターネット２００を介して中継する。
【００４３】
本発明の実施の形態では、クライアント３００は、ウェブ・サーバ５００から所望のデータを入手するために、インターネット２００を介してプロキシ・サーバ１００にアクセス要求を送信する。クライアント３００は、プロキシ・サーバ１００からインターネット２００を介して、所望の返答データを受け取る。クライアント３００は、周知のインターネットに接続可能な端末で当業者は適宜実現可能である。クライアント３００とインターネット２００の接続は、ダイアルアップ接続等によりＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｅｒ、図示せず）を介して行うとよい。クライアント３００からＩＳＰへの接続はダイアルアップ接続に限られず、専用線、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）、ＣＡＴＶ（Ｃａｂｌｅ Ｔｅｌｅｖｉｓｉｏｎ）等を用いた常時接続により行ってもよい。
【００４４】
本発明の実施の形態では、ウェブ・サーバ５００は、プロキシ・サーバ１００から転送されたクライアント３００のアクセス要求に応じて、適切な返答データをプロキシ・サーバ１００に返す。ウェブ・サーバ５００の構築方法は一般に周知であり、具体的には、マイクロソフト社が提供するマイクロソフト社のＭｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｅｒ（Ｒ）（インターネット・インフォメーション・サーバ、ＩＩＳ）やフリーソフトウェアであるＡｐａｃｈｅなどのソフトウェアを使用して当業者は適宜実現可能である。
【００４５】
本発明の実施の形態では、インターネット２００はクライアント３００とプロキシ・サーバ１００を接続する通信経路として機能する。また、イントラネット４００はプロキシ・サーバ１００とウェブ・サーバ５００を接続する通信経路として機能する。当業者に周知の通り、インターネット２００およびイントラネット４００は、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を用いてコンピュータ・システム間を接続する。インターネット２００およびイントラネット４００ではグローバル・アドレスまたはローカル・アドレスで表されるＩＰアドレスによって相互に通信するコンピュータが特定される。
【００４６】
[ハードウェア構成]
本発明の実施の形態において、プロキシ・サーバ１００は、図２のようなハードウェア構成を有するコンピュータ・システムで実現することができる。コンピュータ・システムは、中央処理装置（ＣＰＵ）１とメインメモリ４を含んでいる。ＣＰＵ１とメインメモリ４は、バス２を介して、補助記憶装置としてのハードディスク装置３と接続されている。また、フレキシブルディスク装置２０、ＭＯ装置２８、ＣＲ−ＲＯＭ装置２６、２９などのリムーバブルストレージ（記録メディアを交換可能な外部記憶システム）が関連するフレキシブルディスク・コントローラ１９、ＩＤＥコントローラ２５、ＳＣＳＩコントローラ２７などを介してバス２へ接続されている。
【００４７】
フレキシブルディスク装置２０、ＭＯ装置２８、ＣＲ−ＲＯＭ装置２６、２９などのリムーバブルストレージには、それぞれフレキシブルディスク、ＭＯ、ＣＤ−ＲＯＭなどの記憶媒体が挿入され、このフレキシブルディスク等やハードディスク装置１３、ＲＯＭ１４には、オペレーティング・システムと協働してＣＰＵ等に命令を与え、本発明を実施するためのコンピュータ・プログラムのコードを記録することができる。メインメモリ４にロードされることによってコンピュータプログラムは実行される。コンピュータ・プログラムは圧縮し、また複数に分割して複数の媒体に記録することもできる。
【００４８】
コンピュータ・システムは、さらに、ユーザ・インターフェイス・ハードウェアとして、マウス等のポインティング・デバイス７、キーボード６や視覚データをユーザに提示するためのディスプレイ１２を有することができる。また、パラレルポート１６を介してプリンタ（図示せず）と接続することや、シリアルポート１５を介してモデム（図示せず）を接続することが可能である。コンピュータ・システムは、シリアルポート１５及びモデムを介し、また、通信アダプタ１８（イーサネット（Ｒ）・カードやトークンリング・カード）等を介してネットワークに接続し、他のコンピュータ等と通信を行うことが可能である。
【００４９】
スピーカ２３は、オーディオ・コントローラ２１によってＤ／Ａ変換（デジタル／アナログ変換）された音声信号をアンプ２２を介して受け取り、音声として出力する。また、オーディオ・コントローラ２１は、マイクロフォン２４から受け取った音声情報をＡ／Ｄ変換（アナログ／デジタル変換）し、システム外部の音声情報をシステムに取り込むことを可能にしている。
【００５０】
以上の説明により、本発明の実施の形態におけるプロキシ・サーバ１００は、メインフレーム、ワークステーション、通常のパーソナル・コンピュータ（ＰＣ）、ラップトップＰＣ、ノートブックＰＣ、パームトップＰＣ、ネットワークコンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄａｔａ Ａｓｓｉｓｔａｎｔ）等の情報処理装置、または、これらの組み合わせによって実現されることが容易に理解されるであろう。ただし、これらの構成要素は例示であり、そのすべての構成要素が本発明の必須構成要素となるわけではない。
【００５１】
クライアント３００、ウェブ・サーバ５００も同様のハードウェア構成を有するコンピュータ・システムによって実現可能である。本発明の実施に使用されるプロキシ・サーバ、クライアント、ウェブ・サーバの各ハードウェア構成要素を、複数のマシンを組み合わせ、それらに機能を配分し実施する等の種々の変更は当業者によって容易に想定され得るものであり、それらの変更は、当然に本発明の思想に包含される概念である。
【００５２】
プロキシ・サーバ１００、クライアント３００、ウェブ・サーバ５００には、ハードウェア資源を活用するためのオペレーティングシステムあるいはミドルウェア等のソフトウェアを備えることが好ましい。プロキシ・サーバ１００およびウェブ・サーバ５００は、好適には、インターナショナル・ビジネス・マシーンズが提供するオペレーティング・システムであるＡＩＸ（Ｒ）を備えたサーバ・コンピュータであるｅＳｅｒｖｅｒ ｐＳｅｒｉｅｓ（Ｒ）で実現される。また、クライアント３００は、好適には、マイクロソフト社が提供するオペレーティング・システムであるＷｉｎｄｏｗｓ２０００（Ｒ）を備えたパーソナル・コンピュータ（ＰＣ）で実現される。
【００５３】
[機能ブロック図]
図３に本実施の形態のシステムの機能ブロック図を示す。システムは、プロキシ・サーバ１００、クライアント３００およびびウェブ・サーバ５００を含む。本実施の形態のシステムにおいては、図３の各機能ブロックは図２に示すハードウェア構成を持つコンピュータ・システムであるプロキシ・サーバ１００、クライアント３００、ウェブ・サーバ５００のハードウェア資源と各ハードウェア資源において実行されるオペレーティング・システム、アクセス制御プログラムなどのソフトウェアが協働することによって実現される。
【００５４】
本実施の形態のシステムにおいては、プロキシ・サーバ１００は、受信手段１０１、アクセス許可／不許可判定手段１０２、送信手段１０３、第１のＵＲＬ比較手段１０４、デコーダ１０５、第２のＵＲＬ比較手段１０６、アクセス制御リスト（ＡＣＬ）１０７、ＵＲＬ記憶手段１０８、エンコード方式記憶手段１０９、受信手段１１０及び送信手段１１１を含む。
【００５５】
受信手段１０１は、クライアント３００からのアクセス要求を受信する。送信手段１０３は、アクセス許可／不許可判定手段１０２がアクセス要求をアクセス許可と判定した場合に、ウェブ・サーバ５００に当該アクセス要求をイントラネット４００を介して転送する。
【００５６】
受信手段１１０は、ウェブ・サーバ５００からの返答データを受信する。受信手段１１０によって受信された返答データは解析され、ウェブ・サーバ５００内の返答データの存在するＵＲＬの文字列および当該返答データのエンコード方式（文字コード）の属性値が各々ＵＲＬ記憶手段１０８およびエンコード方式記憶手段１０９に記憶される。好適には、返答データがＨＴＭＬフォーマットで記述されたウェブ・ページであり、ウェブ・ページの文字コードを表しているウェブ・ページ内の”ｃｈａｒｓｅｔ”という属性の値が、エンコード方式記憶手段１０９に記憶される。送信手段１１１は、受信手段１１０によって受信された返答データをクライアント３００へインターネット２００を介して転送する。
【００５７】
第１のＵＲＬ比較手段１０４は、受信手段１０１によって受信されたアクセス要求に含まれる、クライアント３００のブラウザ３１０よって含められた、クライアント３００が当該アクセス要求が生成される以前にダウンロード（アクセス）した返答データの存在するＵＲＬの文字列とＵＲＬ記憶手段に記憶されたＵＲＬの文字列を照合する。好適には、クライアント３００のブラウザ３１０よってアクセス要求に含められたＵＲＬの文字列は、ＨＴＴＰリクエストにおけるｒｅｆｅｒｅｒという属性の値としてアクセス要求に含められた、クライアント３００が直前にダウンロードした返答データのＵＲＬの文字列である。
【００５８】
第１のＵＲＬ比較手段１０４による照合が一致した場合、第１のＵＲＬ比較手段１０４は、エンコード方式記憶手段１０９に記憶されたエンコード方式で受信手段１０１によって受信されたアクセス要求の要求先ＵＲＬの文字列をデコードすべきことをデコーダ１０５に命令する。デコーダ１０５は、エンコードされたアクセス要求の要求先ＵＲＬの文字列を、後述する方法（ロジック）に従って決定されたエンコード方式でデコードする。
【００５９】
ＡＣＬ１０７は、プロキシ・サーバ１００がアクセス要求の要求先ＵＲＬと照合することによりアクセス許可／不許可を判定するための情報を記述したリストである。図９に例示する本発明の実施形態におけるＡＣＬ１０７は、"http://www.ibm.com/CustomApp?confidential"、"http://www.ibm.com/CustomApp?一般文書"がアクセス禁止ＵＲＬとしてリストされている。
【００６０】
なお、図６に例示される本発明の実施形態におけるＡＣＬはアクセス禁止ＵＲＬをリストするように構成されているが、逆にアクセスが許されるＵＲＬをリストするように構成してもよいし、メタ・キャラクタ等を用いて表現するように構成してもよい。すなわち、所定の規則に従い解釈を施すことで、プロキシ・サーバがアクセス許可／不許可を判断するための情報を得ることができるものであれば、ＡＣＬはどのような形式であっても本発明の技術的思想に含まれることに留意されたい。
【００６１】
第２のＵＲＬ比較手段１０６は、デコーダから出力された要求先ＵＲＬの文字列と、ＡＣＬを使用して得られたアクセス許可／不許可の情報を照合する。アクセス許可／不許可判定手段１０２は、第２のＵＲＬ比較手段１０６での照合の結果を使用して、アクセス要求に対するアクセス許可／不許可を判定する。
【００６２】
クライアント３００は、ブラウザ３１０を含む。ブラウザ３１０は、送信手段３１１、アクセス要求生成手段３１２を含む。アクセス要求生成手段３１２によって、アクセス要求（ＨＴＴＰリクエスト）が生成される。アクセス要求生成手段３１２は、生成するアクセス要求に、クライアント３００が以前にダウンロード（アクセス）した返答データの存在するＵＲＬの文字列を含めることができる。好適には、直前にクライアント３００がダウンロード（アクセス）したデータ（ウェブ・ページ）、すなわち、ブラウザ３１０のページ表示手段３１３に現在表示されているウェブ・ページ）のＵＲＬの文字列がｒｅｆｅｒｅｒという属性の値として含められる。送信手段３１１は、生成されたアクセス要求をインターネット２００を介してプロキシ・サーバ１００に送信する。
【００６３】
クライアント３００のブラウザ３１０は、ページ表示手段３１３、受信手段３１４を更に含んでいる。受信手段３１４は、プロキシ・サーバ１００からインターネット２００を介して返答データを入手する。ページ表示手段３１３は、受信手段３１５によって受信された返答データを表示装置等を介してユーザに提示する。
【００６４】
なお、ブラウザ３１０は、マイクロソフト社のインターネット・エクスプローラ（Ｒ）、ネットスケープ・コミュニケーションズ社のネットスケープ・ナビゲータ（Ｒ）などの任意のウェブ・ブラウザで実現可能である。
【００６５】
本発明の実施形態においては、ウェブ・サーバ５００は、受信手段５０１、アクセス要求処理手段５０２、送信手段５０３を含む。受信手段５０２はプロキシ・サーバ１００から転送されたクライアント３００のアクセス要求をイントラネット４００を介して受信し、アクセス要求処理手段５０２へ引き渡す。アクセス要求処理手段５０２は、受信したアクセス要求に応答して、データベース等の記憶装置（図示せず）などから適切なデータを取り出し、加工するなどの処理を行って返答データを生成し、送信手段５０３に引き渡す。送信手段５０３は、イントラネット４００を介して返答データをプロキシ・サーバ１００に送信する。
【００６６】
[アクセス制御の処理の流れ]
次に、初期状態のクライアント３００がウェブ・サーバ５００のホームページ（ＵＲＬを"http://www.ibm.com"とする）にアクセス要求を行った後に、当該ホームページ内のＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）フィールドを使用して、アクセス禁止ＵＲＬである"http://www.ibm.com/AppCustom?一般文書"へアクセスを試みた場合のシステムの動作について、図４および図６乃至図８のフローチャートを参照して説明をする。
【００６７】
まず、クライアント３００がウェブ・サーバ５００のホームページである"http://www.ibm.com"にアクセス要求を行ったときのシステムの動作（以下、第１のセッションという）を図４のフローチャートを使用して説明する。処理は図４のステップ４０００からスタートする。ステップ４０１０では、クライアントが、"http://www.ibm.com"を要求先ＵＲＬとするアクセス要求を生成する。ブラウザ３１０は、（１）ユーザがマウス等を操作してブラウザに表示されたウェブ・ページのハイパーリンクをクリックする、（２）ユーザがキーボード等を操作して直接ＵＲＬをブラウザのアドレス・バーに入力する、あるいは（３）アプレット等のプログラムがブラウザにＵＲＬ遷移イベントを自動的に発生させる、などを契機としてアクセス要求を生成する。
【００６８】
本実施の形態においては、アクセス要求はＨＴＴＰプロトコルに従ってなされる。ＨＴＴＰプロトコルはＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）により管理されるＲＦＣ２６１６にＨＴＴＰ１．１が規定されており、当業者には周知である。もちろんＨＴＴＰ１．０など、他のバージョンのＨＴＴＰプロトコルを使用しても本発明は実現可能である。
【００６９】
生成されたアクセス要求は、クライアント３００からプロキシ・サーバ１００にインターネット２００を介して送信される。第１のセッションにおいては、アクセス要求の要求先ＵＲＬの文字列（"http://www.ibm.com"）はシングルバイト・コードのみからなるので、要求先ＵＲＬの文字列のエンコード処理はされず、生成されたアクセス要求はそのままネットワークに送出され、ＤＮＳサーバ（図示せず）でＩＰアドレス変換がなされ、プロキシ・サーバ１００に到着する。
【００７０】
ステップ４０２０では、プロキシ・サーバ１００が、アクセス要求の要求先ＵＲＬの文字列をＡＣＬを使用して得られたアクセス許可／不許可の情報を照合して、当該アクセス要求のアクセス許可／不許可を判定する。なお、アクセス要求の要求先ＵＲＬの文字列（"http://www.ibm.com"）はシングルバイト・コードのみからなるので、第１のセッションのアクセス許可／不許可の判定においてはデコード処理は不要である（すなわち、デコーダは要求先ＵＲＬの文字列をそのまま出力する）ことに留意されたい。
【００７１】
本発明の実施の形態の第１のセッションでは、図６に示されるように、アクセス制御リストでは"http://www.ibm.com"はアクセス禁止ＵＲＬとされていないので、アクセス要求は、アクセス許可と判定される。アクセス許可と判定されたことに応答して、プロキシ・サーバ１００は当該アクセス要求をイントラネット４００を介してウェブ・サーバ５００へ転送する。
【００７２】
処理はステップ４０３０へ進み、プロキシ・サーバ１００からアクセス要求を受信したウェブ・サーバ５００は、当該アクセス要求を処理して返答データを作成し、プロキシ・サーバ１００へ送信する。処理はステップ４１４０へ進み、返答データをウェブ・サーバ５００から受信したプロキシ・サーバ１００は、その返答データのＵＲＬ（"http://www.ibm.com"）とエンコード方式（すなわち、ｃｈａｒｓｅｔの属性値）を記憶し保持する。本発明の実施の形態では、当該返答データのエンコード方式は、Ｓｈｉｆｔ−ＪＩＳであるとする。
【００７３】
処理はステップ４０５０へ進み、プロキシ・サーバ１００が、返答データをクライアント３００へ送信する。クライアント３００はウェブ・サーバ５００のホームページ（"http://www.ibm.com"）のウェブ・ページのデータを受信し、クライアント３００のブラウザ３１０に当該データの表示を行う。本発明の実施の形態における、返答データのブラウザ表示のイメージを図５に示す。処理はステップ４０６０へ進み、"http://www.ibm.com"を要求先ＵＲＬとするアクセス要求に対する第１のセッションは終了する。
【００７４】
次に、図５に示すブラウザ３１０に表示されたウェブ・ページ内のＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）フィールドを使用して、アクセス禁止ＵＲＬである"http://www.ibm.com/AppCustom?一般文書"へアクセスを試みた場合のシステムの動作（第２のセッション）について、図６のフローチャートを使用して説明をする。
【００７５】
本発明の実施形態においては、図５に示すブラウザ３１０に表示されたウェブ・ページ内のＣＧＩフィールド５０２０にキーボード等を使用して文字列が入力される。次に、マウスを使用してポインタをあわせてクリックを行うことによって送信ボタン５０３０を押し下げると、"http://www.ibm.com/CustomApp?文字列"（ＵＲＬ中の「文字列」はフィールド５０２０に入力された文字列を表している）を要求先ＵＲＬとし、クライアント３００が以前にダウンロード（アクセス）した返答データの存在するＵＲＬの文字列を含むアクセス要求が生成される。好適には、直前にダウンロードされたウェブ・ページ（すなわち、現在表示されているウェブ・ページ）のＵＲＬをｒｅｆｅｒｅｒという属性の値として含められる。また、生成されたアクセス要求の要求先ＵＲＬは、前述の以前にアクセス（ダウンロード）したデータのエンコード方式でエンコードされ、ネットワークへ送出される。この仕組みは、周知のＣＧＩ技術等によって、当業者は適宜容易に実現することができることに留意されたい。
【００７６】
処理はステップ６０００からスタートし、ステップ６０１０でブラウザ３１０に表示されたウェブ・ページ内の入力フィールド５０２０に文字列「一般文書」と入力され、送信ボタン５０３０が押し下げられる。すると、要求先ＵＲＬを"http://www.ibm.com/CustomApp?一般文書"とし、ｒｅｆｅｒｅｒを"http"//www.ibm.com"とするアクセス要求が生成する。
【００７７】
さらにステップ６０１０では、生成したアクセス要求の要求先ＵＲＬの文字列がエンコードされ、エンコードされたアクセス要求がクライアント３００からインターネット２００を介してプロキシ・サーバ１００に送信される。エンコードは、アクセス要求にそのＵＲＬが含められた、以前にダウンロードされたウェブ・ページのエンコード方式、すなわち、"http://www.ibm.com"のエンコード方式（ｃｈａｒｓｅｔ）であるＳｈｉｆｔ−ＪＩＳで行われる。
【００７８】
処理はステップ６０２０に進み、プロキシ・サーバ１００は、受信したアクセス要求のアクセス許可／不許可の判定を、図７および図８のフローチャートに従って行う。図７および図８のフローチャートは、後に詳述する。その結果、アクセス要求は、アクセス不許可と判定されるので、アクセス要求はウェブ・サーバ５００には中継されず、その代わりにプロキシ・サーバ１００からクライアント３００にアクセス不許可のメッセージが送信される。
【００７９】
処理はステップ６０３０へ進み、クライアント３００を操作するユーザにアクセス不許可の情報を伝えるために、クライアント３００はブラウザ３１０に受け取ったアクセス不許可のメッセージを表示する。処理はステップ６０４０へ進み、"http://www.ibm.com/CustomApp?一般文書"を要求先ＵＲＬとするアクセス要求に対する第２のセッションは終了する。
【００８０】
次に、図６に示す第２のセッションのステップ６０２０でのプロキシ・サーバ１００のアクセス許可／不許可の判定処理を図７および図８のフローチャートを使用して詳細に説明をする。
【００８１】
処理はステップ７０００からスタートし、ステップ７０１０でプロキシ・サーバ１００はクライアント３００からのアクセス要求を受信する。受信されたアクセス要求の要求先ＵＲＬは、エンコードされているのでデコード処理がなされる。ステップ７０２０において、要求先ＵＲＬがＵＴＦ−８でデコードできるかどうかが判定される。現在、インターネット上を流れるアクセス要求はほとんどがＵＴＦ−８でエンコードされており、最初にＵＴＦ−８でデコード処理を試みる方が処理効率が向上することが本発明者によって発見されている。
【００８２】
ステップ７０２０で要求先ＵＲＬがＵＴＦ−８でデコードできると判定された場合、処理はＹｅｓの矢印を通じてステップ７０３０へ進み、ＵＴＦ−８でデコード処理がされた後に、処理は更にステップ７１００へ進む。しかし、本発明の実施の形態では、要求先ＵＲＬはＳｈｉｆｔ−ＪＩＳでデコードされているので、ステップ７０２０での判定は失敗し、処理はＮｏの矢印を通じてステップ７０４０へ進む。
【００８３】
ステップ７０４０では、エンコード方式記憶手段１０９にエンコード方式（ｃｈａｒｓｅｔ）が記憶されているかどうかが判定される。本発明の実施の形態では、第１のセッションでエンコード方式記憶手段１０９にＳｈｉｆｔ−ＪＩＳという値が記憶されているので、処理はＹｅｓの矢印を通じてステップ７０５０へ進む。ステップ７０５０では、アクセス要求内のｒｅｆｅｒｅｒが、ＵＲＬ記憶手段１０８に記憶されたＵＲＬと一致するかどうかが判定される。
【００８４】
前述したようにＵＲＬ記憶手段１０８には、第１のセッションで"http://www.ibm.com"が記憶されており、また、アクセス要求内のｒｅｆｅｒｅｒにも、ステップ６０１０で"http"//www.ibm.com"が格納されているので、一致すると判定され、処理はＹｅｓの矢印を通じてステップ７０６０へ進む。ステップ７０６０では、エンコード方式記憶手段１０９にエンコード方式であるＳｈｉｆｔ−ＪＩＳでデコードが行われ、要求先ＵＲＬの文字列は正しく"http://www.ibm.com/CustomApp?一般文書"と戻される。デコードの後、処理は更にステップ７１００へ進む。
【００８５】
なお、仮に、ステップ７０４０または７０５０で判定に失敗した場合は、処理はＮｏの矢印を通じてステップ７０７０へ進み、アクセス要求によってアクセスしようとされているウェブ・サーバに対するあらかじめ設定されたデフォルトの文字コードがあるかどうかが判定される。ステップ７０７０でデフォルトの文字コードがあると判定された場合、処理はステップ７０８０へ進み、当該デフォルトの文字コードで要求先ＵＲＬの文字列がデコードされ、処理は更にステップ７１００へ進む。
【００８６】
また、本実施の形態においては、ステップ７０７０でデフォルトの文字コードがないと判定された場合は、処理はステップ７０９０へ進み、最後の選択肢として、プロキシ・サーバ１００で採用されている文字コードで要求先ＵＲＬの文字列がデコードされる。ステップ７０９０のデコードが行われた後、処理は更にステップ７１００へ進む。
【００８７】
説明を図８へ進め、ステップ７１００では、ステップ７０３０、７０６０、７０８０または７０９０でデコードされたアクセス要求の要求先ＵＲＬの文字列と、ＡＣＬ１０７を解釈して得られたアクセス禁止ＵＲＬの文字列が照合される。本発明の実施の形態においては、デコードされたアクセス要求の要求先ＵＲＬの文字列は、"http"//www.ibm.com/CustomApp?一般文書"である。また、図９に例示するＡＣＬ１０７には、"http"//www.ibm.com/CustomApp?一般文書"がアクセス禁止ＵＲＬとしてリストされているので、ステップ７１００における照合は一致することとなる。
【００８８】
処理はステップ７１１０へ進み、アクセス要求のアクセス許可／不許可がステップ７１００の照合結果を元に判定される。本発明の実施の形態では、照合が一致してアクセス不許可と判断されるので、処理はＮｏの矢印を通じてステップ７１２０へ進み、プロキシ・サーバ１００からクライアント３００に対してアクセス不許可のメッセージが返され、処理がステップ７１４０で終了する。
【００８９】
なお、ステップ７１００で照合が失敗し、ステップ７１１０でアクセス要求に対してアクセス許可と判定された場合には、処理はＹｅｓの矢印を通じてステップ７１３０へ進む。ステップ７１３０では、プロキシ・サーバ１００はアクセス要求をウェブ・サーバ５００へ転送し、ステップ７１４０で処理は終了する。
【００９０】
上記の本発明の好適な実施例は、説明を目的として記述されたものあって、すべての実施態様を記述するものではなく、実施例に開示された形式に発明を限定する意図ではない。上記の開示によれば、多くの変更例とバリエーションが実現可能である。本発明の範囲は発明の詳細な説明の記載により制限されるのではなく、特許請求の範囲により定まるものであることに留意されたい。上記の仕様、例、データにより本発明の一態様の製造および使用が完全に説明される。本発明の多くの実施例が本発明の精神と範囲を離れることなく実現される。
【００９１】
【効果】
以上から、本発明によれば、クライアントでエンコードされたアクセス要求の要求先ＵＲＬの文字列がプロキシ・サーバでより高い精度で正しくデコードされることが理解される。本発明によれば、よりセキュア（安全）なＵＲＬベース・アクセス制御が可能となるという効果を得ることができる。
【図面の簡単な説明】
【図１】 本発明のＵＲＬベース・アクセス制御方法を適用するシステム構成の一例を示した概念図である。
【図２】 本発明の実施の形態におけるプロキシ・サーバ、クライアント、ウェブ・サーバのハードウェア構成の一例を示した図である。
【図３】 本発明の実施の形態のシステムの機能ブロック図である。
【図４】 本発明の実施の形態のシステムの第１のセッションでの動作を示したフローチャートである。
【図５】 本発明の実施の形態におけるウェブ・サーバのホームページのブラウザ表示のイメージである。
【図６】 本発明の実施の形態のシステムの第２のセッションでの動作を示したフローチャートである。
【図７】 本発明の実施の形態のシステムのプロキシ・サーバでのアクセス制御の手順（前半部分）を示したフローチャートである。
【図８】 本発明の実施の形態のシステムのプロキシ・サーバでのアクセス制御の手順（後半部分）を示したフローチャートである。
【図９】 本発明の実施の形態のシステムのプロキシ・サーバが備えるアクセス制御リストのイメージである。
【図１０】日本語を含むＵＲＬのエンコード前後の文字列を示した対応図である。
Claims (18)
- サーバのＵＲＬへのクライアントのアクセス要求を前記サーバに中継し、アクセス要求に対する前記サーバの返答データをクライアントに中継するプロキシ・サーバであって、
前記クライアントに対し前記プロキシ・サーバが中継した返答データのアドレス・ロケーションおよび当該返答データのエンコード方式を記憶する手段と、
当該アクセス要求が生成される以前に前記クライアントが受信した返答データのアドレス・ロケーションと当該返答データのエンコード方式でエンコードされた要求先アドレス・ロケーションを含むアクセス要求をクライアントから受信する手段と、
前記アクセス要求を第１のエンコード方式を使用してデコードし、デコードが成功した場合には前記第２のデコード前に前記アクセス要求に含まれる前記返答データのアドレス・ロケーションと前記記憶する手段に記憶されたアドレス・ロケーションを照合する手段と、
前記第１のエンコード方式を使用したデコードに失敗した場合には、前記エンコード方式を記憶する手段を検索して第２のエンコード方式が前記エンコード方式を記憶する手段に記憶されているか否かを判断し、記憶されている場合には、前記第２のエンコード方式によるデコード前に前記アクセス要求に含まれる前記返答データのアドレス・ロケーションと前記記憶する手段に記憶されたアドレス・ロケーションを照合する手段と、
前記照合が成功した場合に、前記記憶する手段に記憶されたエンコード方式で、前記アクセス要求に含まれるエンコードされた要求先アドレス・ロケーションの文字列をデコードする手段と、
を含むプロキシ・サーバ。 - 前記デコードされた要求先アドレス・ロケーションの文字列を用いて、前記アクセス要求のアクセス許可／不許可を判定する手段と、
前記判定する手段が、前記アクセス要求をアクセスが許可されると判定した場合に、当該アクセス要求をサーバに送信する手段と
を更に含む請求項１に記載のプロキシ・サーバ。 - 前記判定する手段が、前記デコードされた要求先アドレス・ロケーションと予めプロキシ・サーバに保持されたアクセス許可／不許可の情報を照合する手段と含む、請求項２に記載のプロキシ・サーバ。
- 前記アクセス要求が含む、以前に前記クライアントが受信した返答データのアドレス・ロケーションが、前記クライアントが直前にアクセスしたアドレス・ロケーションである、請求項１に記載のプロキシ・サーバ。
- 前記プロキシ・サーバが、前記サーバから受信した返答データを解析することによって、返答データのアドレス・ロケーションおよび当該返答データのエンコード方式の情報を入手して、各々を前記記憶手段に記憶する、請求項１に記載のプロキシ・サーバ。
- 前記アクセス要求がＨＴＴＰリクエストであり、前記アドレス・ロケーションがＵＲＬであり、前記返答データがウェブ・ページであり、前記返答データのエンコード方式が当該返答データのｃｈａｒｓｅｔの属性値であり、前記アクセス要求に含まれる前記返答データのアドレス・ロケーションがｒｅｆｅｒｅｒの属性値であり、前記サーバがウェブ・サーバであり、前記クライアントと前記プロキシ・サーバがインターネットでネットワーク接続され、前記プロキシ・サーバと前記サーバがイントラネットでネットワーク接続される、請求項１記載のプロキシ・サーバ。
- サーバのＵＲＬへのクライアントのアクセス要求を前記サーバに中継し、アクセス要求に対するサーバの返答データをクライアントに中継するプロキシ・サーバにおいて、前記クライアントから前記サーバへのアクセス要求のアクセス制御を行う方法であって、
前記プロキシ・サーバが中継した返答データのアドレス・ロケーションおよび当該返答データのエンコード方式を記憶する手段に記憶させるステップと、
前記アクセス要求を第１のエンコード方式を使用してデコードし、デコードが成功した場合には前記第２のデコード前に前記アクセス要求に含まれる前記返答データのアドレス・ロケーションと前記記憶する手段に記憶されたアドレス・ロケーションを照合するステップと、
前記第１のエンコード方式を使用したデコードに失敗した場合には、前記エンコード方式を記憶する手段を検索して第２のエンコード方式が前記エンコード方式を記憶する手段に記憶されているか否かを判断し、記憶されている場合には、前記第２のエンコード方式によるデコード前に前記アクセス要求に含まれる前記返答データのアドレス・ロケーションと前記記憶する手段に記憶されたアドレス・ロケーションを照合するステップと、
前記照合が成功した場合に、前記記憶する手段に記憶されたエンコード方式で、前記アクセス要求に含まれるエンコードされた要求先アドレス・ロケーションの文字列をデコードするステップと、
を含むアクセス制御方法。 - 前記デコードされた要求先アドレス・ロケーションの文字列を用いて、前記アクセス要求のアクセス許可／不許可を判定するステップと、
前記判定するステップにおいて、前記アクセス要求をアクセスが許可されると判定した場合に、当該アクセス要求をサーバに送信するステップと
を更に含む請求項７に記載のアクセス制御方法。 - 前記判定するステップが、前記デコードされた要求先アドレス・ロケーションと予めプロキシ・サーバに保持されたアクセス許可／不許可の情報を照合するステップと含む、請求項８に記載のアクセス制御方法。
- 前記アクセス要求が含む、以前に前記クライアントが受信した返答データのアドレス・ロケーションが、前記クライアントが直前にアクセスしたアドレス・ロケーションである、請求項７に記載のアクセス制御方法。
- 前記プロキシ・サーバが、前記サーバから受信した返答データを解析することによって、返答データのアドレス・ロケーションおよび当該返答データのエンコード方式の情報を入手して記憶する、請求項７に記載のアクセス制御方法。
- 前記アクセス要求がＨＴＴＰリクエストであり、前記アドレス・ロケーションがＵＲＬであり、前記返答データがウェブ・ページであり、前記返答データのエンコード方式が当該返答データのｃｈａｒｓｅｔの属性値であり、前記アクセス要求に含まれる前記返答データのアドレス・ロケーションがｒｅｆｅｒｅｒの属性値であり、前記サーバがウェブ・サーバであり、前記クライアントと前記プロキシ・サーバがインターネットでネットワーク接続され、前記プロキシ・サーバと前記サーバがイントラネットでネットワーク接続される、請求項７記載のアクセス制御方法。
- サーバのＵＲＬへのクライアントのアクセス要求を前記サーバに中継し、アクセス要求に対する前記サーバの返答データを前記クライアントに中継するプロキシ・サーバによって実行され、クライアントからサーバへのアクセス要求のアクセス制御を行うためアクセス制御プログラムであって、前記プロキシ・サーバに、
前記プロキシ・サーバが中継した返答データのアドレス・ロケーションおよび当該返答データのエンコード方式を記憶手段に記憶させる機能手段と、
前記アクセス要求を第１のエンコード方式を使用してデコードし、デコードが成功した場合には前記第２のデコード前に前記アクセス要求に含まれる前記返答データのアドレス・ロケーションと前記記憶手段に記憶されたアドレス・ロケーションを照合する機能手段と、
前記第１のエンコード方式を使用したデコードに失敗した場合には、前記記憶手段を検索して第２のエンコード方式が前記記憶手段に記憶されているか否かを判断し、記憶されている場合には、前記第２のエンコード方式によるデコード前に前記アクセス要求に含まれる前記返答データのアドレス・ロケーションと前記記憶手段に記憶されたアドレス・ロケーションを照合する機能手段と、
前記照合が成功した場合に、前記記憶手段に記憶されたエンコード方式で、前記アクセス要求に含まれるエンコードされた要求先アドレス・ロケーションの文字列をデコードする機能手段と、
を実現する、コンピュータ実行可能なアクセス制御プログラム。 - 前記デコードされた要求先アドレス・ロケーションの文字列を用いて、前記アクセス要求のアクセス許可／不許可を判定する機能手段と、
前記判定する機能手段において、前記アクセス要求をアクセスが許可されると判定した場合に、当該アクセス要求をサーバに送信する機能手段と
を更にプロキシ・サーバに実行させる、請求項１３に記載のアクセス制御プログラム。 - 前記判定する機能手段が、前記デコードされた要求先アドレス・ロケーションと予めプロキシ・サーバに保持されたアクセス許可／不許可の情報を照合する機能手段を含む、請求項１４に記載のアクセス制御プログラム。
- 前記アクセス要求が含む、以前に前記クライアントが受信した返答データのアドレス・ロケーションが、前記クライアントが直前にアクセスしたアドレス・ロケーションである、請求項１３に記載のアクセス制御プログラム。
- 前記プロキシ・サーバが、前記サーバから受信した返答データを解析することによって、返答データのアドレス・ロケーションおよび当該返答データのエンコード方式の情報を入手して記憶する、請求項１３に記載のアクセス制御プログラム。
- 前記アクセス要求がＨＴＴＰリクエストであり、前記アドレス・ロケーションがＵＲＬであり、前記返答データがウェブ・ページであり、前記返答データのエンコード方式が当該返答データのｃｈａｒｓｅｔの属性値であり、前記アクセス要求に含まれる前記返答データのアドレス・ロケーションがｒｅｆｅｒｅｒの属性値であり、前記サーバがウェブ・サーバであり、前記クライアントと前記プロキシ・サーバがインターネットでネットワーク接続され、前記プロキシ・サーバと前記サーバがイントラネットでネットワーク接続される、請求項１３に記載のアクセス制御プログラム。
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002381655A JP3940356B2 (ja) | 2002-12-27 | 2002-12-27 | プロキシ・サーバ、アクセス制御方法、アクセス制御プログラム |
| US10/738,703 US7437468B2 (en) | 2002-12-27 | 2003-12-16 | Method and system for secure URL-based access control |
| CNB2003101234395A CN100492963C (zh) | 2002-12-27 | 2003-12-26 | 代理服务器和访问控制方法 |
| US12/201,360 US7865604B2 (en) | 2002-12-27 | 2008-08-29 | System and program for access control |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002381655A JP3940356B2 (ja) | 2002-12-27 | 2002-12-27 | プロキシ・サーバ、アクセス制御方法、アクセス制御プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004213288A JP2004213288A (ja) | 2004-07-29 |
| JP3940356B2 true JP3940356B2 (ja) | 2007-07-04 |
Family
ID=32817516
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002381655A Expired - Lifetime JP3940356B2 (ja) | 2002-12-27 | 2002-12-27 | プロキシ・サーバ、アクセス制御方法、アクセス制御プログラム |
Country Status (3)
| Country | Link |
|---|---|
| US (2) | US7437468B2 (ja) |
| JP (1) | JP3940356B2 (ja) |
| CN (1) | CN100492963C (ja) |
Families Citing this family (45)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9003295B2 (en) * | 2003-03-17 | 2015-04-07 | Leo Martin Baschy | User interface driven access control system and method |
| FR2858896A1 (fr) * | 2003-08-12 | 2005-02-18 | France Telecom | Procede de masquage des traitements applicatifs d'une requete d'acces a un serveur et systeme de masquage correspondant |
| US20070208946A1 (en) * | 2004-07-06 | 2007-09-06 | Oracle International Corporation | High performance secure caching in the mid-tier |
| JP2006140841A (ja) * | 2004-11-12 | 2006-06-01 | Canon Inc | 情報処理装置、サーバ装置、ネットワークシステム、データ通信方法、及びコンピュータプログラム |
| US7774825B2 (en) * | 2004-12-16 | 2010-08-10 | At&T Intellectual Property I, L.P. | Methods & apparatuses for controlling access to secured servers |
| CN1842071B (zh) * | 2005-03-28 | 2010-06-23 | 华为技术有限公司 | 应用程序访问Web服务器端对象的实现方法和装置 |
| US9176934B2 (en) * | 2005-05-06 | 2015-11-03 | Leo Baschy | User interface for nonuniform access control system and methods |
| US9129088B1 (en) | 2005-06-04 | 2015-09-08 | Leo Martin Baschy | User interface driven access control system and methods for multiple users as one audience |
| US20060282884A1 (en) * | 2005-06-09 | 2006-12-14 | Ori Pomerantz | Method and apparatus for using a proxy to manage confidential information |
| US8032657B2 (en) | 2005-09-12 | 2011-10-04 | Microsoft Corporation | Preservation of type information between a client and a server |
| US9202068B2 (en) | 2006-03-29 | 2015-12-01 | Leo M. Baschy | User interface for variable access control system |
| JP4978537B2 (ja) * | 2008-03-31 | 2012-07-18 | 富士通株式会社 | アクセス要求転送システム、アクセス要求転送方法およびアクセス要求転送プログラム |
| US7991418B2 (en) * | 2008-04-28 | 2011-08-02 | Qualcomm Incorporated | Method and apparatus for retrieving data from one or more wireless communication devices |
| US8090852B2 (en) * | 2008-06-04 | 2012-01-03 | Sophos Plc | Managing use of proxies to access restricted network locations |
| CN101753606B (zh) * | 2008-12-03 | 2013-01-09 | 北京天融信科技有限公司 | 一种实现web反向代理的方法 |
| JP5035373B2 (ja) * | 2010-03-18 | 2012-09-26 | コニカミノルタビジネステクノロジーズ株式会社 | 画像処理装置及び同装置におけるデータ処理方法並びにデータ処理プログラム |
| US8805938B2 (en) * | 2010-06-04 | 2014-08-12 | Xiben New Line Stock Co., Ltd. | Enterprise service bus and message processing method thereof |
| CN102299812A (zh) * | 2010-06-22 | 2011-12-28 | 华为技术有限公司 | 一种访问控制方法及网络设备 |
| JP5133387B2 (ja) | 2010-10-22 | 2013-01-30 | シャープ株式会社 | 複合機、制御プログラムおよび記録媒体 |
| US9395885B1 (en) | 2010-12-10 | 2016-07-19 | Wyse Technology L.L.C. | Methods and systems for a remote desktop session utilizing HTTP header |
| US8949726B2 (en) | 2010-12-10 | 2015-02-03 | Wyse Technology L.L.C. | Methods and systems for conducting a remote desktop session via HTML that supports a 2D canvas and dynamic drawing |
| US9244912B1 (en) | 2010-12-10 | 2016-01-26 | Wyse Technology L.L.C. | Methods and systems for facilitating a remote desktop redrawing session utilizing HTML |
| US9245047B2 (en) * | 2010-12-10 | 2016-01-26 | Wyse Technology L.L.C. | Methods and systems for facilitating a remote desktop session utilizing a remote desktop client common interface |
| US9430036B1 (en) | 2010-12-10 | 2016-08-30 | Wyse Technology L.L.C. | Methods and systems for facilitating accessing and controlling a remote desktop of a remote machine in real time by a windows web browser utilizing HTTP |
| US9535560B1 (en) | 2010-12-10 | 2017-01-03 | Wyse Technology L.L.C. | Methods and systems for facilitating a remote desktop session for a web browser and a remote desktop server |
| US8966376B2 (en) | 2010-12-10 | 2015-02-24 | Wyse Technology L.L.C. | Methods and systems for remote desktop session redrawing via HTTP headers |
| US20130212201A1 (en) * | 2012-02-14 | 2013-08-15 | Brian Walters | On-demand marketing literature distribution system |
| CN103257966A (zh) * | 2012-02-17 | 2013-08-21 | 阿里巴巴集团控股有限公司 | 搜索资源静态化的实现方法及系统 |
| CN103379184B (zh) * | 2012-04-23 | 2016-03-16 | 深圳市腾讯计算机系统有限公司 | 网络业务访问的方法及系统 |
| US9021037B2 (en) | 2012-12-06 | 2015-04-28 | Airwatch Llc | Systems and methods for controlling email access |
| US8862868B2 (en) | 2012-12-06 | 2014-10-14 | Airwatch, Llc | Systems and methods for controlling email access |
| US8826432B2 (en) | 2012-12-06 | 2014-09-02 | Airwatch, Llc | Systems and methods for controlling email access |
| US8978110B2 (en) | 2012-12-06 | 2015-03-10 | Airwatch Llc | Systems and methods for controlling email access |
| US9787686B2 (en) | 2013-04-12 | 2017-10-10 | Airwatch Llc | On-demand security policy activation |
| WO2016028198A1 (en) * | 2014-08-20 | 2016-02-25 | Telefonaktiebolaget L M Ericsson (Publ) | Methods, devices and management terminals for establishing a secure session with a service |
| US10362059B2 (en) * | 2014-09-24 | 2019-07-23 | Oracle International Corporation | Proxy servers within computer subnetworks |
| US9832199B2 (en) * | 2015-09-25 | 2017-11-28 | International Business Machines Corporation | Protecting access to hardware devices through use of a secure processor |
| WO2017062680A1 (en) | 2015-10-07 | 2017-04-13 | Impossible Ventures, LLC | Automated sequential site navigation |
| CN106911735B (zh) * | 2015-12-22 | 2021-12-21 | 北京奇虎科技有限公司 | 数据获取方法及装置 |
| CN106911736B (zh) * | 2015-12-22 | 2021-11-26 | 北京奇虎科技有限公司 | 云代理服务器、云代理的纯异步数据传输方法及系统 |
| CN106161451B (zh) * | 2016-07-19 | 2019-09-17 | 青松智慧（北京）科技有限公司 | 防御cc攻击的方法、装置及系统 |
| KR101907621B1 (ko) * | 2017-06-12 | 2018-10-15 | 주식회사 시큐아이 | 접근 제어 규칙 검증 방법 및 그 장치 |
| CN109150796B (zh) * | 2017-06-15 | 2022-02-22 | 阿里巴巴（中国）有限公司 | 数据访问方法和装置 |
| CN108040014B (zh) * | 2017-10-30 | 2022-01-11 | 维沃移动通信有限公司 | 一种流量控制方法和装置 |
| US11032270B1 (en) * | 2020-04-07 | 2021-06-08 | Cyberark Software Ltd. | Secure provisioning and validation of access tokens in network environments |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7062781B2 (en) * | 1997-02-12 | 2006-06-13 | Verizon Laboratories Inc. | Method for providing simultaneous parallel secure command execution on multiple remote hosts |
| US6256739B1 (en) * | 1997-10-30 | 2001-07-03 | Juno Online Services, Inc. | Method and apparatus to determine user identity and limit access to a communications network |
| JP2001243143A (ja) | 2000-02-28 | 2001-09-07 | Densuke Shokai:Kk | インターネットのアクセス方法、インターネットのアクセスシステム、及びｕｒｌ検索サーバ |
| WO2002031702A1 (en) * | 2000-10-09 | 2002-04-18 | Enic Corporation | Registering and using multilingual domain names |
| JP3714599B2 (ja) | 2001-01-30 | 2005-11-09 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 送信制御システム、サーバ、端末装置、送信制御方法、プログラム及び記憶媒体 |
| JP2002312279A (ja) | 2001-04-11 | 2002-10-25 | Kenwood Corp | 情報通信システム、ゲートウェイサーバ、その通信方法、及び情報通信端末 |
| US7054917B1 (en) * | 2002-08-07 | 2006-05-30 | Propel Software Corporation | Method for accelerating delivery of content in a computer network |
-
2002
- 2002-12-27 JP JP2002381655A patent/JP3940356B2/ja not_active Expired - Lifetime
-
2003
- 2003-12-16 US US10/738,703 patent/US7437468B2/en not_active Expired - Fee Related
- 2003-12-26 CN CNB2003101234395A patent/CN100492963C/zh not_active Expired - Lifetime
-
2008
- 2008-08-29 US US12/201,360 patent/US7865604B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US7437468B2 (en) | 2008-10-14 |
| CN100492963C (zh) | 2009-05-27 |
| US20090064298A1 (en) | 2009-03-05 |
| CN1512707A (zh) | 2004-07-14 |
| US7865604B2 (en) | 2011-01-04 |
| JP2004213288A (ja) | 2004-07-29 |
| US20040260821A1 (en) | 2004-12-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3940356B2 (ja) | プロキシ・サーバ、アクセス制御方法、アクセス制御プログラム | |
| CN109194673B (zh) | 基于用户授权信息的认证方法、系统、设备及存储介质 | |
| JP3995338B2 (ja) | ネットワーク接続制御方法及びシステム | |
| KR100286499B1 (ko) | 쿠키를이용한분산형파일시스템웹서버사용자인증방법 | |
| EP1346548B1 (en) | Secure session management and authentication for web sites | |
| JP4734592B2 (ja) | クライアントリダイレクトによるプライベートネットワークへの安全なアクセス提供方法およびシステム | |
| US6311269B2 (en) | Trusted services broker for web page fine-grained security labeling | |
| JP5022141B2 (ja) | データ通信を中継する中継装置、中継方法及び中継用プログラム | |
| US20030065956A1 (en) | Challenge-response data communication protocol | |
| US20050262557A1 (en) | Method and system for monitoring personal computer documents for sensitive data | |
| JP2003271477A (ja) | セッション情報の引継ぎ方法、アプリケーションサーバ、Ｗｅｂサイト、およびプログラム | |
| JP2000508153A (ja) | ネットワーク・コンピュータに関する汎用のユーザ認証方法 | |
| US20050246427A1 (en) | Communications apparatus and service providing technique using communications apparatus | |
| KR20060040661A (ko) | 클라이언트 서버 환경에서 클라이언트를 인증하는 시스템및 방법 | |
| JPWO2007110951A1 (ja) | ユーザ確認装置、方法及びプログラム | |
| JP2005011098A (ja) | 代理認証プログラム、代理認証方法、および代理認証装置 | |
| US8996715B2 (en) | Application firewall validation bypass for impromptu components | |
| JP6099384B2 (ja) | 情報通信システム及び認証装置及び情報通信システムのアクセス制御方法及びアクセス制御プログラム | |
| JP2002189646A (ja) | 中継装置 | |
| JP5039053B2 (ja) | マクロ・サポートによりｈｔｔｐセキュリティ・メッセージ処理を外部化するための方法およびシステム | |
| EP3033866B1 (en) | Secure transfers of files within network-based storage | |
| US20050198283A1 (en) | Managing a network using generic policy definitions | |
| CN114244616B (zh) | 登录验证方法、登录验证系统、电子设备以及存储介质 | |
| JP4675921B2 (ja) | 情報処理システム及びコンピュータプログラム | |
| JP2010128651A (ja) | コンテンツ提供システム及びコンテンツ提供システムにおけるパーソナライズ方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060428 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060613 |
|
| RD12 | Notification of acceptance of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7432 Effective date: 20060623 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20060623 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060809 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070327 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20070327 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070330 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 3940356 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100406 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100406 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110406 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110406 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120406 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130406 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130406 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140406 Year of fee payment: 7 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |