(57)【要約】      （修正有）【課題】利用者登録後の戻り先を各ユーザ毎にナビゲーションする。【解決手段】登録情報入力を促す１乃至複数のコンテンツページそれぞれに識別情報を付しておき、この識別情報を含むユーザ登録情報を受信した場合には、識別情報に基づき特定される当該識別情報に対応する戻り先URLに関連づけられた固有のセッションIDを確認用URLに含ませて、ユーザに対して電子メールにより通知する。こうすると、ユーザが前記電子メールに記載された確認用URLへアクセスして本人確認あるいは登録確定作業を行う過程でサイト閲覧あるいはサービス利用が中断されても（セッションが途切れたとしても）、サイト閲覧中断時点あるいはサービス利用中断時点に表示していたユーザがサービスを受けるべくユーザ登録を要求した特定のサービス画面へユーザを導くことから、ユーザに対し閲覧サイトやサービスに連続性を持たせて提供することが容易にできるようになる。【選択図】図５
2008226253.tif 000002
【特許請求の範囲】
【請求項１】
登録済みの利用者に対してのみに限定した所定のサービスを通信ネットワークを介して提供可能なサーバ装置において、
ユーザクライアントに対して登録情報入力を促す１乃至複数のコンテンツページであって、各コンテンツページ毎に識別情報が付されたものを提供する手段と、
新規利用者の電子メールアドレス及び前記コンテンツページに付された識別情報を含むユーザ登録情報を前記ユーザクライアントから受信する手段と、
前記受信したユーザ登録情報に含まれる識別情報に基づいて当該識別情報に対応する戻り先ＵＲＬを特定する手段と、
前記受信したユーザ登録情報に対し固有のセッションＩＤを生成する手段と、
前記セッションＩＤと前記特定した戻り先ＵＲＬとを関連づけて記憶する手段と、
前記セッションＩＤを指示する情報を含む確認用ＵＲＬを前記ユーザ登録情報に含まれる電子メールアドレス宛に通知する手段と、
前記確認用ＵＲＬへのアクセスに応じて、前記セッションＩＤに対応する前記受信したユーザ登録情報に基づくユーザ登録を確定するとともに、前記記憶された内容に基づき前記セッションＩＤに関連づけられた戻り先ＵＲＬへのナビゲーションを行う手段と
を具備したサーバ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、予め登録済みの利用者に対してのみに限定したサービスを通信ネットワークを介して提供することが可能なサーバ装置に関する。特に、電子メールを使用して利用者登録を行う場合に、利用者登録後の戻り先を各ユーザ毎にナビゲーションすることのできるようにしたオンライン登録手続き用のサーバ装置に関する。
【背景技術】
【０００２】
最近ではインターネットに代表されるような有線若しくは無線の通信ネットワークの発展及び一般家庭における高速通信環境（所謂ブロードバンドと呼ばれるADSL、FTTH、CATVなど）の普及に伴い、通信ネットワークを介したオンラインサービスが提供されつつある。これによると、ユーザは自宅等に設置したパーソナルコンピュータ等を用いて、自宅に居ながらにして好きな時間に自由にサービスの提供を受けることができる。上記オンラインサービスとして予め登録済みのユーザに対してのみに限定したサービスを提供するものが知られており、こうした限定されたオンラインサービスの提供を受けたいユーザは予め所定の画面（ページとも呼ぶ）から利用者登録を行っておく必要がある。従来、限定したサービスを受けるためにユーザが行うべき利用者登録（あるいは登録内容の変更）は、該オンラインサービスを提供しているサーバ内のWWW（World wide Web）サイト上にある単一の利用者登録のためのオンライン利用者登録画面から行うように構成されている。また、利用者登録を行う際には、一旦WWWサイト上の登録画面において電子メールアドレスを含む所定の登録情報の入力を行わせることによって利用者を仮登録し、該入力された電子メールアドレス宛に固有の確認用URL（Uniform Resource Locator）へのアクセスを促す内容を記述した電子メールを送付して、ユーザによるこの確認用URLへのアクセスでもって本人確認と登録確認を併せて行うように構成されている。ここでURLとは、インターネット上に存在するリソース（各種ファイル等）の場所を指し示す記述方式である。例えば、URL「http：//hoo.bar/script.php?param=value」は、通信プロトコルがHTTP（HyperText Transfer Protocol）であって、「hoo.bar」で特定されるサーバ上のドキュメントルートに存在している「script.php」なるリソースに対して値が「value」であるパラメータ「param」を渡すことを意味する。
なお、この明細書において予め登録済みのユーザに対してのみに提供する限定サービスとはユーザから費用を徴収する有料サービスに限られるものでなく、例えばユーザ毎にオンラインサービスの表示配置等を異ならせて設定（カスタマイズ）した画面を提供したり、単に登録されたユーザ名あるいはユーザID等を表示するなどの、ユーザから費用を徴収しない無料サービスも含む。
【特許文献１】特開2001-209720号公報
【０００３】
上述したように、予め登録済みのユーザのみに利用を限定したオンラインサービスを新たに受けるためにユーザが行うべき利用者登録の手順として、電子メールを利用したユーザによる確認操作が行われることが従来から必要とされている。この手順によると、ユーザはサービス提供用のサーバから送付されてきた電子メールの内容を見て確認用URLにアクセスする必要があることから、現在閲覧中のWeb画面の閲覧や提供されているサービスの利用を一旦中断しなければならない（つまり、セッション切れが生ずる）。また、電子メールで通知される確認用URLへのアクセスに伴い表示される確認用URLに対応したWeb画面（例えば登録完了画面など）と、他の画面（例えば各サービスを提供する各Web画面など）とは何ら関連性がないために、前記表示されるWeb画面上には当該WWWサイトにおける先頭画面や利用者登録のためのオンライン登録画面などをハイパーリンク先として設定している場合が多い。したがって、ユーザは確認用URLに対応したWeb画面を閲覧した後には一旦当該WWWサイトの先頭画面や前記登録画面などに必ず戻るしかなく、閲覧を中断したWeb画面や利用を中断したサービスなどの元々利用していたWeb画面やサービスを提供しているWeb画面を再度探さなければならず手間がかかる、という問題点があった。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明は上述の点に鑑みてなされたもので、利用者登録を行ったユーザが電子メールにより通知された確認用URLへアクセスして本人確認あるいは登録確定作業を行った後に、ユーザがWWWサイト上で迷子になることなくかつユーザが元々利用していたWeb画面やサービスを提供しているWeb画面を探す手間を低減するために、各ユーザがオンライン登録画面に辿り着くまでの経路に応じて、利用者登録後の戻り先を各ユーザ毎にナビゲーションすることのできるようにしたサーバ装置を提供することを目的とする。
【課題を解決するための手段】
【０００５】
本発明の第１の請求項に係るサーバ装置は、登録済みの利用者に対してのみに限定した所定のサービスを通信ネットワークを介して提供可能なサーバ装置において、ユーザクライアントに対して登録情報入力を促す１乃至複数のコンテンツページであって、各コンテンツページ毎に識別情報が付されたものを提供する手段と、新規利用者の電子メールアドレス及び前記コンテンツページに付された識別情報を含むユーザ登録情報を前記ユーザクライアントから受信する手段と、前記受信したユーザ登録情報に含まれる識別情報に基づいて当該識別情報に対応する戻り先ＵＲＬを特定する手段と、前記受信したユーザ登録情報に対し固有のセッションＩＤを生成する手段と、前記セッションＩＤと前記特定した戻り先ＵＲＬとを関連づけて記憶する手段と、前記セッションＩＤを指示する情報を含む確認用ＵＲＬを前記ユーザ登録情報に含まれる電子メールアドレス宛に通知する手段と、前記確認用ＵＲＬへのアクセスに応じて、前記セッションＩＤに対応する前記受信したユーザ登録情報に基づくユーザ登録を確定するとともに、前記記憶された内容に基づき前記セッションＩＤに関連づけられた戻り先ＵＲＬへのナビゲーションを行う手段とを具備する。
【０００６】
この発明によると、ユーザクライアントに対して登録情報入力を促すためのコンテンツページを提供するが、この登録情報入力を促すためのコンテンツページは１乃至複数あって、それぞれに識別情報が付されている。ユーザクライアントから受信するユーザ登録情報には新規利用者の電子メールアドレスの他に、この新規利用者が登録情報を入力した際に利用した前記１乃至複数のコンテンツページのいずれかに付されていた識別情報が含まれる。前記受信したユーザ登録情報に対して固有のセッションIDを生成し、該生成したセッションIDを指示する情報を含む確認用URLを、前記ユーザ登録情報に含まれる電子メールアドレス宛に通知する。前記固有のセッションIDは、前記受信したユーザ登録情報に含まれる識別情報に基づいて特定された当該識別情報に対応する戻り先URLと関連づけて記憶される。こうすると、ユーザにより前記通知した確認用URLへのアクセスがなされた場合には、前記受信したユーザ登録情報に基づくユーザ登録を確定することに加えて、前記セッションIDに関連づけられた戻り先URLに基づき、ユーザがサービスを受けるべくユーザ登録を要求した元のページ（コンテンツページ移行前のページ）へのナビゲーションが行われる。すなわち、ユーザが確認用URLへアクセスしユーザ登録確定作業を行うことによる元のページへのセッション切れが生じた場合であっても、ユーザ登録確定後には必ず個々のユーザが登録手続きしたサービスに関連した元のページを戻り先としてナビゲーションすることから、ユーザクライアントにおけるサイトの閲覧や提供されるサービスに連続性を持たせることが容易にできるようになる。
【０００７】
本発明は装置の発明として構成し実施することができるのみならず、方法の発明として構成し実施することができる。また、本発明は、コンピュータまたはＤＳＰ等のプロセッサのプログラムの形態で実施することができるし、そのようなプログラムを記憶した記憶媒体の形態で実施することもできる。
【発明の効果】
【０００８】
この発明によれば、登録情報入力を促す１乃至複数のコンテンツページそれぞれに識別情報を付しておき、この識別情報を含むユーザ登録情報を受信した場合には、前記識別情報に基づき特定される当該識別情報に対応する戻り先URLに関連づけられた固有のセッションIDを確認用URLに含ませて、ユーザに対して電子メールにより通知する。こうすると、ユーザが前記電子メールに記載された確認用URLへアクセスして本人確認あるいは登録確定作業を行う過程でサイト閲覧あるいはサービス利用が中断されても（セッションが途切れたとしても）、サイト閲覧中断時点あるいはサービス利用中断時点に表示していたユーザがサービスを受けるべくユーザ登録を要求した特定のサービス画面（元のページ）へユーザを導くことから、ユーザに対して提供する閲覧サイトやサービスに連続性を持たせて、ユーザがサイト上で迷子にならないようにすることができる、という効果を奏する。
【発明を実施するための最良の形態】
【０００９】
以下、この発明の実施の形態を添付図面に従って詳細に説明する。
【００１０】
図１は、本発明に係るサーバ装置を適用したオンラインサービスシステムの全体構成の一実施例を示すシステムブロック図である。この実施例に示すオンラインサービスシステムは通信ネットワークを介して各種サービスを提供するシステムであって、サービスを受ける側であるパソコン端末や携帯通信端末（例えば、携帯電話やPDA）などのユーザクライアントＰＣと、サービスを提供する側であるサーバＭＳと、インターネットなどの通信ネットワークＸとにより構成される。詳しくは後述するが、該オンラインサービスシステムを構成する各々の装置（上記クライアントＰＣ及びサーバＭＳ）は、各々がＣＰＵ、ＲＯＭ、ＲＡＭ、通信インタフェース等を含む独立したコンピュータにより構成されてなり、各々の装置はインターネットや専用線等を利用した有線若しくは無線などの通信ネットワークＸを介して、互いの装置間において各種情報を送受信することができるようになっている。こうしたオンラインサービスシステムにより提供可能なサービス内容の一例としては、例えばユーザ別に個々のユーザの習熟度にあわせた楽器の演奏練習行程に従って、練習曲の曲データを提供する、練習曲を弾く際の運指及び演奏強弱などの演奏テクニックを動画により画面上に表示する、あるいはユーザに対する音楽的な指導（アドバイス）を画面上に表示するなどして、楽器や演奏機器の演奏教習を指導する教習サービス（所謂ｅラーニングサービス）などがある。
なお、こうしたオンラインサービスシステムは図１に示す以外のハードウェアを有する場合もあるが、ここでは必要最小限の資源を用いた場合について説明する。なお、サーバＭＳあるいはクライアントＰＣはそれぞれ複数の装置により構成されたものであってよく、そうした場合にはそれら複数の装置を互いに通信ネットワークＸを介して結合した形態のものをサーバＭＳあるいはクライアントＰＣとして用いてかまわないことは言及するまでもない。
【００１１】
クライアントＰＣは、ユーザ操作に応じたURL（Uniform Resource Locatorの略）の指定を受け付けて当該URLへのアクセスを行い、サーバＭＳから前記URLに対応して発せられるページ記述情報などのレスポンスを順次受信して、該受信したページ記述情報に基づきWeb画面を提示する処理を行う他、電子メールの送受信乃至表示処理などを行う装置である。サーバＭＳから受信したページ記述情報に基づくWeb画面の提示は周知の技術であることから、ここでは説明を省略する。
一方、サーバＭＳはサービスの提供及び利用者登録手続きを行う装置であって、利用者登録手続きに関する各処理（後述する図６及び図７参照）の他に、通常のHTTPサーバとしての各種処理と電子メールの送受信処理を適宜に実行する。このサーバＭＳは異なるサービスを提供する複数のWWWサイト毎に該WWWサイトを構成する多数のWeb画面のページ記述情報（詳しくは図４参照）や、登録利用者に関する各種情報などをデータベース（ＤＢ）Ｙに記憶しており、通信ネットワークＸを介して接続されたクライアントＰＣからのアクセス要求（例えばURLの指定など）に応じて該当するページ記述情報をデータベースＹから読み出しクライアントＰＣへと返信する、あるいはクライアントＰＣからの登録情報に基づき登録利用者に関する各種情報を更新する。こうしたクライアントＰＣとサーバＭＳとの間における各種情報や電子メール等の送受信は、インターネット用ブラウザやメールソフトなどの所定のソフトウエアプログラムを用いて行われる。
【００１２】
なお、この明細書において、サーバＭＳからクライアントＰＣに対して送信されるWeb画面の基となる「ページ記述情報」はHTML（Hyper Text Markup Languageの略）等のプログラムで記述されるものであるが、主体となるHTMLソースプログラムの他に、該ソース中に挿入あるいは実行される画像や音声、動画、スクリプトやクッキー（Cookie）等、所謂HTTPに基づき伝送及び提示可能なリソースデータを含んでいてよい。つまり、ページ記述情報にはクライアントＰＣ上で表示乃至再生される情報の他に、非表示の情報（上記スクリプトや各種パラメータ情報など）が含まれていてよい。さらに、少なくとも上記HTMLソースプログラムには固有の「URL ID」が割り振られており、データベースＹ内のURLテーブル（後述する）に登録されて管理されている。
【００１３】
なお、上記オンラインサービスシステムに通信ネットワークＸを介して接続可能なクライアントＰＣとして用いられる機器は上述したようなパソコン端末や携帯通信端末等に限らず、通信ネットワークＸを介してサーバＭＳとの間で各種情報を送受信して処理できるものであればどのような形態の機器であってもよい。すなわち、カラオケや自動演奏ピアノのような自動演奏装置であってもよいし、ゲーム機器若しくは電子楽器などであってもよい。また、オンラインサービスシステムに対して、複数のクライアントＰＣやサーバＭＳなどが通信ネットワークＸを介して接続されていてよいことは言うまでもない。
【００１４】
次に、図１に示したクライアントＰＣ又はサーバＭＳいずれかのハード構成の一実施例について、図２を用いて簡単に説明する。図２は、上記各装置いずれか１つの全体構成の一実施例を示すハード構成ブロック図である。ただし、上記各装置は同じようなハード構成を用いるものとして説明することができることから、代表としてサーバＭＳについてのブロック図を１つだけ用いて説明する。
【００１５】
本実施例に示すサーバＭＳは、マイクロプロセッサユニット（ＣＰＵ）１、リードオンリメモリ（ＲＯＭ）２、ランダムアクセスメモリ（ＲＡＭ）３からなるマイクロコンピュータによって制御されるようになっている。ＣＰＵ１は、このサーバＭＳ全体の動作を制御するものである。このＣＰＵ１に対して、データ及びアドレスバス１Ｄを介してリードオンリメモリ（ＲＯＭ）２、ランダムアクセスメモリ（ＲＡＭ）３、出力デバイス４、入力デバイス５、通信デバイス６がそれぞれ接続されている。ＲＯＭ２は、ＣＰＵ１により実行あるいは参照される各種プログラムや各種データ等を格納するものである。ＲＡＭ３は、クライアントＰＣから送信された各種情報等、若しくはＣＰＵ１が所定のプログラムを実行する際に発生する各種データなどを一時的に記憶するワーキングメモリとして、あるいは現在実行中のプログラムやそれに関連するデータを記憶するメモリ等として使用される。ＲＡＭ３の所定のアドレス領域がそれぞれの機能に割り当てられ、レジスタやフラグ、テーブル、メモリなどとして利用される。出力デバイス４はクライアントＰＣに対して提示するWeb画面、例えば「サービス画面１」、「登録画面」、「仮登録通知」画面、「登録完了通知」画面（図５参照）やこれらの各Web画面の基となるページ記述情報などを表示する、例えば液晶表示パネル（LCD）やCRTなどのディスプレイなどの出力機器である。入力デバイス５は、前記ページ記述情報を生成する際に用いる文字データ入力用のキーボードや数値データ入力用のテンキー、若しくはディスプレイ上に表示されたポインタを操作するマウスなどのポインティングデバイスなどの入力機器である。
【００１６】
通信デバイス６は、例えばLANやインターネット、電話回線等の通信ネットワークＸに接続されており、該通信ネットワークＸを介して所定のクライアントＰＣ等と接続されることによって、当該クライアントＰＣに対してWeb画面の基となるページ記述情報や各種処理を実行するアプリケーション・プログラムあるいは電子メールなどを送信する、当該クライアントＰＣから登録情報や電子メールなどを受信するための通信インタフェースである。こうした通信デバイス６は有線のものに限らず無線のものであってもよく、また双方を具えていてよい。さらに、通信デバイス６として、外部のMIDI機器等からMIDI規格の楽音情報（つまり、MIDIデータ）を当該サーバＭＳへ入力したり、あるいは当該サーバＭＳからMIDI規格の楽音情報（MIDIデータ）を外部のMIDI機器等へ出力するためのMIDIインタフェースを具えていてもよい。
【００１７】
なお、クライアントＰＣから受信した登録利用者に関する各種情報、若しくはWeb画面の基となるページ記述情報やＣＰＵ１が実行する各種アプリケーション・プログラム等を記憶するためのハードディスク等の外部記憶装置を具えていてよい。勿論、ハードディスク（HD）に限られず、フロッピィーディスク（FD）、コンパクトディスク（CD）、光磁気ディスク（MO）、DVD（Digital Versatile Diskの略）等の着脱自在な様々な形態の外部記憶媒体を利用する記憶装置であってもよい。若しくは、半導体メモリなどであってもよい。
なお、クライアントＰＣやサーバＭＳは出力デバイス４や入力デバイス５などを１つの装置本体に内蔵したものに限らず、それぞれが別々に構成され、所定のインタフェースを用いて前記各装置を接続するように構成されたものにも同様に適用できることは言うまでもない。
【００１８】
ここで、サーバＭＳが具備するデータベースＹについて、図３を用いて説明する。図３は、データベースＹのデータ構成の一実施例を示す概念図である。ここに示すデータベースは、例えばセッションIDテーブル、セッション管理テーブル、顧客マスタテーブル、URLテーブルの各テーブルデータから構成されている。
【００１９】
セッションIDテーブルはセッションIDのユニーク性をチェックするためのテーブルであり、例えばハッシュテーブルなどからなる。このセッションIDテーブルには、過去から今までに生成されたセッションIDが蓄積される。セッション管理テーブルはセッションIDに関連させる各種情報（これをセッション情報と呼ぶ）を保持するためのテーブルであり、１つのテーブルレコードにはKEYとなるセッションIDの他に、ユーザID、有効日、仮登録データ、戻り先URL_IDなどを記憶するフィールド（記憶領域）が含まれる。「セッションID」は、利用者登録時において生成したセッションID（詳しくは後述する）である。「ユーザID」はこのレコードのセッションを行った顧客のユーザID、「有効日」はセッション情報登録時に設定された該セッション情報を有効に扱うことのできる期限である。「仮登録データ」は所定の登録フォーム等を用いてサーバＭＳに対して送信されたユーザが入力した登録内容であり、該当するフィールドに一時的に保持される。「URL_ID」は、登録確認操作後にユーザをナビゲートする先の戻り先URL情報である。顧客マスタテーブルは各種顧客情報を保持するテーブルであり、１つのテーブルレコードにはKEYとなるユーザIDの他に、メールアドレス、その他情報、セッションIDなどを記憶するフィールドが含まれる。「ユーザID」は各ユーザ固有の識別IDであり、初回の利用者登録時に各ユーザ毎にサーバＭＳ側で自動的に発行する固有のIDが付与される。「メールアドレス」は、各ユーザが登録した電子メールアドレスである。「その他情報」は、各ユーザの住所氏名等の個人情報、利用登録中のサービス内容、サービス利用履歴等の所謂顧客情報である。「セッションＩＤ」は各ユーザが最後に取得したセッションIDであり、常に最新のものに更新されている。
【００２０】
URLテーブルは当該サーバＭＳで提供可能なリソース（HTML等によりページ単位で記述されたページ記述言語等のリソース）個別に固有のIDとURLとを割り当てたテーブルであり、１つのテーブルレコードには各リソース固有のIDやKEYを記憶する「URL  ID」、各リソースに割当てられたURLを記憶する「URL」などのフィールドを含む。すなわち、サーバＭＳに記憶される各々のWWWサイトを構成する多数のWeb画面はHTML等のページ記述情報により記述されており、それぞれのページ記述情報には固有のIDが割り当てられ、所定の文字列情報で構成されるインターネットアドレスを示すURLによりクライアントＰＣから参照される。URLテーブルは、当該サーバＭＳで提供可能なURLをID管理するためのテーブルである。
【００２１】
上記したURLテーブルにより管理されるURLに対応するWeb画面、つまりサーバＭＳが提供するWWWサイトの構成は図４に示すような階層的なディレクトリ構造となっている。図４において、最上位のURL「http://hoo.bar/」で示されるWeb画面はサービス全体の概要を示すホームページなどのトップ画面であり、その下位に複数の異なるサービス毎に各サービスの概要を示すサービストップ画面が配置されている（/svc1/index.htmlや/svc2/index.htmlなど）。これらの各サービストップ画面には、サービスを提供するWeb画面である多数の「サービス画面１」や「サービス画面２」などが含まれる（/svc1/page1.htmlや/svc1/page2.htmlなど）。更に、こうした各「サービス画面」の下位に複数のサブ画面を含むように構成してあってもよい（/svc2/sub/page1.htmlや/svc2/sub/page2.htmlなど）。そして、この実施例においては、利用者登録を行うための「登録画面」が、「/svc1/register.html」や「/svc2/sub/register.html」などのように各サービスにおけるWeb画面の最下位の位置、あるいは「/svc2/register.html」などのように「サービス画面」（/svc2/page1.htmlや/svc2/page2.htmlなど）と同等の位置に配置される。
【００２２】
また、上記各「登録画面」から利用者登録が行われた場合に、次に画面表示される「仮登録完了通知」画面（図５参照）については、各サービスにおいて共通に用いられるものが用意されている（/script/register.php）。すなわち、図中において一点鎖線で示すように、各サービス毎に用意された「登録画面」からの登録実行操作に従って「/script/register.php」が実行されると、各サービス毎に用意された「登録画面」から共通の「仮登録完了通知」画面へと表示を移行する。さらに、この際にはクライアントＰＣに対して所定のURL（/script/confirm.php）を記述した電子メールを送付する。つまり、前記「/script/register.php」 は、登録確認処理を実行するスクリプトプログラム等で構成されている（この場合、HTML Processer として知られるスクリプト言語である。勿論、perl やコンパイルされたアプリケーションなど、他の実行可能なCGIアプリケーションであってもよい）。こうした「register.php」に対して前記「登録画面」から入力された登録情報を受け渡すと登録情報受付処理（図６参照）が実行され、「仮登録完了通知」画面へと表示を移行すると共に電子メールを送付する。送付された電子メール内に記述されたURL（/script/confirm.php）がユーザによりクリックされた場合に表示される「登録完了通知」（図５参照）についても各サービスで共通に使用するものが用意されており、前記「/script/confirm.php」が実行されることにより「登録完了通知」画面へと表示を移行する。すなわち、この「/script/confirm.php」は登録確認処理を実行するスクリプトプログラム等で構成されており、この「confirm.php」 にセッションIDを受け渡すと確認URLアクセス処理（図７参照）が実行され、「登録完了通知」画面へと表示を移行すると共に利用者の本登録を行う。
【００２３】
ユーザが通信ネットワークＸを介したオンラインサービスを受けるためには、オンラインサービスを提供するサーバＭＳが立ち上げたサービスに対応した所定のWWWサイトに対して適宜にアクセスし、該サービスの利用者登録を行うことが必要である。そこで、こうしたオンラインサービスの利用者登録手順について、サーバＭＳがクライアントＰＣに対して提示するWeb画面及び電子メールの表示例を用いながら簡単に説明する。図５は、利用者登録手順を説明するための概念図である。ただし、ここでは図４に示したWWWサイト構成に従って説明を行うものとする。
【００２４】
まず、ユーザにより図示しないサービストップ画面から所望のサービスが選択されると、該選択されたサービスの内容を紹介する画面として「サービス画面１」（http：//hoo.bar/svc1/page1.html）を最初に提示する。例えば、楽器演奏の教習を提供するオンラインサービスにおいて、各楽器毎に複数のレッスンコースがあるような場合には、サービストップ画面上においてユーザが所望のレッスンコースを選択することに従い各レッスンコース毎に専用のサービス画面１を提示する。このサービス画面１では、当該レッスンコースで行う大まかなレッスン（コンテンツ）の概要紹介や、当該レッスンで使用する教材の紹介など、提供するサービス内容の紹介を行う。勿論、上記以外の内容を表示してよい。
【００２５】
次に、上記サービス画面１の右下に表示されている「登録する」ボタンＡがクリックされると、「登録画面」（http：//hoo.bar/svc1/register.html）を提示する。この「登録画面」はユーザに対して登録情報の入力を促すために提示する画面であって、例えばあるサービスに利用申込みを行うような場合の最小限の入力フォームと入力内容としては、図示のように「メールアドレス」や「パスワード」の入力を促すように構成される。この他にも、ユーザが自身に対してつけたニックネームや、住所氏名などの個人情報等の入力を当該画面で促すようにしておいてもよい。こうした登録情報の内容あるいは該登録画面の表示態様等は、サイトのポリシーにより適宜構成されるものであることから詳細については説明を省略する。ユーザにより登録画面右下に表示されている「送信」ボタンＢがクリックされるとCGIアプリケーション（http：//hoo.bar/script/register.php）が起動されて、該登録画面から入力された登録情報がサーバＭＳに対して送信される。なお、登録済みである既存のユーザは事前にログイン手続きを行っており、ログイン済みであることを示す情報がクッキー（Cookie）としてクライアントＰＣ上に保持されているものとする。
【００２６】
また、この登録画面には、当該登録画面から登録情報を送信したユーザが後述する電子メール（確認メール）にて通知された「確認用URL」へアクセスした際にナビゲーションすべき「戻り先URL」に対応する「URL_ID」が非表示のパラメータとしてページ記述情報に含まれていることから（登録画面では非表示の部分を点線で囲んで概念的に示した）、入力された登録情報と共にこの「URL_ID」がサーバＭＳに対して送信される。さらに、ユーザ識別情報であるユーザIDが登録情報及び「URL_ID」と共に送信される（ただし、新規ユーザ又は未ログインユーザである場合にはユーザIDが未確定であるので、ユーザIDに対応するパラメータの値はnullとして送信される）。
【００２７】
上記登録画面において「送信」ボタンＢがクリックされると、「仮登録完了通知」画面及び電子メールを提示する。ここで、一旦セッション切れが生ずる。「仮登録完了通知」画面及び電子メールは、入力した登録情報がサーバＭＳに仮登録されたことを通知する内容と共に、登録情報を本登録するために必要な操作をユーザに対して促す内容を提示する。本登録するために必要な操作とは、電子メールに記述された確認用URL（http：//hoo.bar/script/confirm.php?key=e7fecb37a9）にアクセスする操作である。電子メールに記述された確認用URLには、リソースのアロケーション情報の他、リソースに渡されるパラメータ情報も適宜含む。図示の例においては、"?" の前まで（つまり、http：//hoo.bar/script/ confirm.phpで示されるホスト名とパス）がアロケーション情報であり、以降（key=e7fecb37a9）がパラメータ情報である。
【００２８】
上記電子メール上に記述されている確認用URLがクリックされると、「登録完了通知」画面を提示してユーザ登録が完了したことを通知する。この「登録完了通知」画面上の「確認」ボタンＣ（勿論、ボタンでなくてもテキストに設定されていてもよい）には、セッションIDに関連づけられていた「戻り先URL」を指し示すハイパーリンクが設定されており、ユーザがこの確認ボタンＣを押すと、適切なURLに対応するページ記述情報がサーバＭＳから送信されてクライアントＰＣに提示される。ここでは、戻り先として「サービス画面１」に戻る例を示している。戻った先の「サービス画面１」からは、「スタート」ボタンＤをクリックすることによって、図示しないログイン画面や適宜のサービス本体の画面に表示を移行する。
【００２９】
ユーザが通信ネットワークＸを介したオンラインサービスを受けるためには、上述したような利用者登録手順に従って利用者登録を行うことが必要である。そこで、上記利用者登録手順に従って利用者登録を実現するサーバ処理について、図６及び図７を用いて説明する。以下では、「登録画面」（図５参照）の送信ボタンＢがクリックされた際に実行する「登録情報受付処理」について図６を用いて、電子メールに記述された確認URLがクリックされた際に実行する「確認URL処理」について図７を用いて、それぞれ説明する。図６は、「登録情報受付処理」の一実施例を示すフローチャートである。図７は、「確認URL処理」の一実施例を示すフローチャートである。これらの各処理はサーバＭＳが稼動中常駐し常に所定の待機状態にある常駐プログラム、あるいはWWWサーバプログラム等他の常駐プログラムから必要に応じて呼び出され実行されるプログラムであり、クライアントＰＣ側で所定の対応する操作がユーザにより行われた場合に当該サーバＭＳに対して送信されるリクエストあるいはコマンドに応じてそれぞれ実行される。
【００３０】
まず、「登録画面」の送信ボタンＢがクリックされた際に実行する登録情報受付処理の動作について、図６に示したフローチャートに従って説明する。送信ボタンＢがクリックされた場合にはregister.phpに登録情報が受け渡されて、当該登録情報受付処理が実行される。
ステップＳ１では、通信ネットワークＸを介して接続されたクライアントＰＣから登録情報を受付ける。この登録情報は、「登録画面」を用いてユーザが入力したメールアドレスやパスワードなどであり、「登録画面」の送信ボタンＢのクリックに応じて送信されるデータである。登録情報受付待機状態にあるサーバＭＳは、クライアントＰＣから登録情報を受付けると該受信した登録情報に誤り（エラー）があるかないかを判定する（ステップＳ２）。登録情報にエラーがある場合、例えば必須の入力事項に入力漏れがあるような場合には（ステップＳ２の「あり」）、エラーが発生した情報の再入力を促すエラーレスポンスをクライアントＰＣに対して返送する（ステップＳ３）。登録情報にエラーがない場合には（ステップＳ２の「なし」）、該登録情報の入力を行ったユーザが未登録の「新規」な利用者であるか、既に「登録済み」の利用者であるかを判定する（ステップＳ４）。この新規のユーザであるか否かの判定は、受信した登録情報内のユーザIDが空（null）であり、かつ、顧客マスタテーブル中に同一の電子メールアドレスで登録したユーザがいない場合を新規ユーザであると判定する。新規ユーザである場合には（ステップＳ４の「新規」）、ユニークなユーザIDを新たに発行してレコード追加、つまりデータベースに登録する（ステップＳ５）。既に登録済みのユーザである場合には（ステップＳ４の「登録済」）、該ユーザに対して既に発行済みのユーザIDを特定する（ステップＳ６）。この際、登録情報内のユーザIDに対応するレコードがデータベースに存在するか否か、すなわち登録情報に含まれるユーザIDが正規のものであるか否かをも併せて検査するようにし、正規のユーザでない場合はステップＳ３と同様にエラーレスポンスをクライアントＰＣに返送し、正規のユーザである場合にのみ後続のステップＳ７に処理を移行するよう構成してもよい。ステップＳ７では、日時情報を取得する。ステップＳ８では、前記新たに発行したユーザID又は特定した既存のユーザIDと、該取得した日時情報とに基づき、セッションIDを生成する。すなわち、受信した登録情報にエラーが無ければ、登録情報を受け付けた日時に関する時刻情報（典型的には長整数値）を取得して、ユーザＩＤと日時情報に基づいてセッションIDを生成する。
【００３１】
ここで、簡単にセッションIDの生成手順の一例について説明する。
まず、ユーザIDと日時情報の文字列表現とを結合する。例えば、2003年1月1日0時0分0秒0 ミリ秒にアクセスがあった場合、1970/1/1 0:0:0:0 を起点とした日時情報1041346800000 （ミリ秒）を取得する。また、ユーザIDが"poo"であった場合には、「poo + 1041346800000 -> poo1041346800000」のようにユーザIDと日時情報とを結合した文字列を生成する。次に、該結合した文字列を暗号化して適当な長さの、当該ユーザ登録セッションに固有のセッションIDを得る。このときに用いる暗号化のアルゴリズムは、一方向性の関数であればどのようなアルゴリズムであってもよい。ただし、暗号化アルゴリズムは次の２条件、演算結果からソースの文字列を特定することが数理上困難であること、異なるソースから同じ結果を生成する可能性が極めて低いこと、を少なくとも満たすものであることが望ましい。上記結合した文字列を暗号した結果、例えば「e7fecb37a9」なる文字列が取得される。この取得された文字列が、生成されたセッションIDである。このようにして、セッションIDを生成する。
【００３２】
なお、セッションIDとして採用する文字列はなるべく短い方が望ましい。すなわち、電子メールに確認用URLを記述する場合、余りにセッションIDが長い文字列であると、メールソフトウェアによる電子メールの表示上、確認用URLを一行に収めて表示することができなくなる場合が生ずる。こういった場合、メールソフトウェアによっては行の折り返しに改行文字列を挿入してしまうことがあり、ユーザが正しく確認用URLを参照することができなくなることがあり得る。また、反対に余りにも短い文字列であるとユニーク性が損なわれやすい。そこで、セッションIDは、上記したような１０文字程度の文字列で生成するのが望ましい。
【００３３】
図６に示したフローチャートの説明に戻って、ステップＳ９では、上記生成したセッションIDがユニーク（固有）のものであるかの判定、つまりセッションIDのユニーク性を検証する。すなわち、仮に暗号化アルゴリズムが上記２条件を満たすものであったとしても、確率的に同じセッションIDが生成されてしまう可能性は皆無ではない。そこで、セッションIDの重複を回避する目的で、セッションIDテーブル（図３参照）に以前生成した全てのセッションIDを登録しておき、今回生成したセッションIDと同じ値のセッションIDが存在するか否かを検査する。セッションIDが重複している場合には（ステップＳ９の「重複」）、セッションIDの取得をやり直して再取得する（ステップＳ１０）。こうしてユニークなセッションIDが得られると、登録情報とともに送信されたURL_IDを取得する、有効期限を設定する、他の情報とともにセッション管理テーブルにレコードを追加する（ステップＳ１１）。すなわち、ユニークなセッションIDが得られた場合には、セッション管理テーブルに当該セッションIDをキーとする新規なレコードを追加する。「ユーザID」フィールドには、既に特定されているユーザIDをコピーする。「有効日」フィールドには、上記セッションIDを生成した日時を起点とした所定時間後（例えば７日後）に設定した日時情報を挿入する。「仮登録データ」フィールドには、ユーザクライアントから受信した登録情報をまとめてコピーする。「戻り先URL_ID」フィールドには、登録情報の一部として送信されてきたURL_ID（戻り先URL）を格納する。また、顧客管理マスタの「セッションID」フィールドに最新のセッションIDを記述しておく。
なお、この実施例では有効な登録セッションは最新のもののみに制限する。これは、ユーザ誤操作による重複入力防止のためである。
【００３４】
ステップＳ１２ではユーザの電子メールアドレスを取得して、パラメータにセッションIDを付加した確認用URLを記述した電子メールをユーザに対して送信する。つまり、http：//hoo.bar/script/confirm.php?key=e7fecb37a9などの確認用URLを記述した電子メールをユーザの電子メールアドレス宛に送信する。以上の処理を行った後に、例えば図５に示した「仮登録完了通知」のような受付レスポンスをクライアントＰＣに対して送信する（ステップＳ１３）。
【００３５】
次に、電子メールに記述された確認用URLがクリックされた際に実行する確認URL処理の動作について、図７に示したフローチャートに従って説明する。確認用URLがクリックされた場合にはconfirm.phpにセッションIDが受け渡されて、当該確認用URLアクセス処理が実行される。
ステップＳ２１では、通信ネットワークＸを介して接続されたクライアントＰＣからの確認URLのアクセスを受付ける。ステップＳ２２では、セッションIDを特定してセッション管理テーブルから対応するレコードを読み出す。この際、受け渡されたセッションIDに対応するレコードがデータベースに存在するか否か、すなわちセッションIDが正規のものであるか否かをも併せて検査するようにし、正規のセッションIDでない場合は後述するステップＳ２５等と同様にエラーレスポンスをクライアントＰＣに返送し、正規のセッションIDである場合にのみ後続のステップＳ２３に処理を移行するよう構成してもよい。ステップＳ２３では、ユーザIDを特定して顧客マスタテーブルから対応するレコードを読み出す。ステップＳ２４ではセッションIDが対応するか否かを判定し、不一致である場合にはエラーレスポンスを発する（ステップＳ２５）。すなわち、顧客管理マスタテーブルに保持されている最終のセッションIDと今回受け渡されたセッションIDとの一致を確認して、 一致していなければ当該アクセスは無効であるとして、セッションIDの確認あるいは登録作業のやり直しを促すエラーレスポンスをクライアントＰＣに対して送信する。ステップＳ２６では対応するレコードがあるか否かを判定し、存在しない場合にはエラーレスポンスを発する（ステップＳ２７）。ステップＳ２８では有効期限を超過しているか否かを判定し、超過している場合には再登録を促すエラーレスポンスを生成する（ステップＳ２９）。有効期限内であれば（ステップＳ２８の「超過していない」）、セッション管理テーブルに保存してあった登録情報（つまり仮登録データの内容）を適宜顧客管理マスタテーブルに適用し、顧客管理情報を最新の状態へ更新する（ステップＳ３０）。すなわち、仮登録を本登録とする。ステップＳ３１では、戻り先URL_IDに対応するURLへのナビゲーションを含むレスポンスページ（例えば登録完了通知）を生成する。この後に、セッション管理テーブルからセッションIDのレコードを削除するように構成してもよい。ステップＳ３２では、更新レスポンスをユーザクライアントに戻す。このようにして、顧客管理マスタテーブルの更新が完了した場合には、上記「登録完了通知」のような更新レスポンスをクライアントＰＣに対して送信する。
【００３６】
なお、上述した各処理は、各々の装置におけるＣＰＵ１が所定のプログラム（ソフトウエア）を実行することにより実施される。勿論、コンピュータソフトウエアの形態に限らず、DSP（ディジタル・シグナル・プロセッサ）によって処理されるマイクロプログラムの形態でも実施可能であり、また、この種のプログラムの形態に限らず、ディスクリート回路又は集積回路若しくは大規模集積回路あるいはゲートアレイ等を含んで構成された専用ハードウエア装置の形態で実施してもよい。
【００３７】
上述した実施例においては図５に示すように登録画面のページ記述情報に戻り先とするURLのID（戻り先URL_ID）を記述しておき、登録情報と共に該戻り先URL_IDを取得する（図６のステップＳ１１参照）ことにより、ユーザに対して送付する電子メールに記述する確認用URLを決定するようにしたがこれに限らない。例えば図８（ａ）に示すようにURLテーブルに「戻り先URL_ID」フィールドを定義しておき、そこに戻り先とするURLのIDを記述しておくと共に、図８（ｂ）に示すように登録画面のページ記述情報に該登録画面自体のURL_IDを記述しておくことによっても、電子メールに記述する確認用URLを決定することができる。簡単に説明すると、まず図６に示した「登録情報受付処理」のステップＳ１〜ステップＳ９までの処理を実行して、セッションIDを生成する。次に、図６のステップＳ１１の処理の代わりとして以下の処理を実行する。すなわち、登録画面のページ記述情報に該登録画面自体のURL_IDが記述されていることから、登録情報とともにクライアントＰＣから送信された該登録画面自体のURL_IDを取得する。受信した登録画面のURL_IDをKeyとして図８（ａ）に示すURLテーブルを参照し、該当するURLテーブルの「戻り先URL_ID」フィールドに定義されているIDを取得して、セッション管理テーブルに格納しておく。そして、図６のステップＳ１２の処理に戻る。以下の処理は同様であることから説明を省略する。この構成によれば、戻り先URLを変更しようとする場合にはURLテーブルの「戻り先URL_ID」フィールドの定義を書き直すだけでよい。したがって、WWWサイトの構成を変更したりする際等の戻り先URLを変更する必要がある場合のサイト構築作業を効率よく行うことができるようになり有利である。
【００３８】
また、上述した実施例においては各サービス毎に「登録画面」を配置するものとしたが（図４参照）、図９（ｂ）に示すようにWWWサイト上に各サービスで共通に用いる単一の「登録画面」（/script/input.php）を１つ用意しておき、下記のような態様を採用することにより、ユーザに対して送付する電子メールに記述する確認用URLを決定するようにしてもよい。この場合、図９（ｂ）に示すように、各サービス画面毎に「申し込む」ボタン（あるいは「登録」ボタンなどでもよい）といった共通の「登録画面」のレスポンスを要求する表示要素と共に、各サービスを識別するサービスIDがページ記述情報に定義されている。そのため、「登録画面」のレスポンスを要求するリクエストと共に当該サービスのサービスIDがパラメータとしてサーバＭＳに対して送信される。「登録画面」のレスポンスに相当するページ記述情報として、サーバＭＳにおいて上記サービスIDに応じて各サービス対応のページ記述情報が動的に生成される。サーバＭＳ上のデータベースには上記説明した各テーブルに加え、上記サービスのIDと戻り先のURLとを定義したテーブルを具備しており、受信したサービスIDに対応する戻り先URLをセッション管理テーブルに格納する。そして、これを用いてユーザに対して送付する電子メールに記述する確認用URLを決定するが、該処理については説明済みであることから説明を省略する。
【００３９】
なお、セッションIDは、例えば乱数を利用したアルゴリズム、RFC1321（MD5）で知られるメッセージダイジェストアルゴリズム等により生成することができるようにしてよい。乱数を利用する場合、例えば、適当な乱数系列を上記アクセス時刻（ミリ秒）を種として初期化し、適宜取得する乱数の値を適当な値（例えば16）で除算した値を必要な文字数分取得し、これを文字表記したものをセッションIDとして採用する。こうして採用したセッションIDが重複した場合には、種を変更するか、異なるセッションIDが得られるまで同じ乱数系列から乱数を取得すればよい。また、MD5を利用する場合、結合文字列からは32文字分のメッセージダイジェストが得られる。このメッセージダイジェスト（あるいはこの一部の10文字など）をセッションIDとして採用する。こうして採用したセッションIDが重複した場合は、ソースとなる結合文字列を変更（日時情報対応部分を現時刻に差し替える、末尾に非数字文字を追加する等）してメッセージダイジェストを再生成すればよい。メッセージダイジェストの一部をセッションIDに用いる場合は、32文字中異なる10文字をセッションIDとして再取得してもよい。
【００４０】
なお、ユーザは登録情報を「登録画面」（register.html）からだけでなく、「登録完了通知」（confirm.php）から入力乃至確認あるいは登録できるようになっていてもよい。
なお、セッションIDを含むURLを確認用URLとして電子メールによりユーザに対し通知するようにしたが、セッションIDのみをユーザに対して通知し、適当な画面（好適には登録画面あるいは登録完了通知）にセッションIDを入力するフォームを用意しておき、当該フォームから「confirm.php」 にセッションIDをパラメータとして渡すように構成してもよい。上記いずれの態様でユーザに対して通知するかは、ユーザが登録した電子メールアドレスに基づいて判定するようにしてもよい（例えば、携帯電話がプラットフォームであることが明らかな電子メールアドレスであればこのなお書きの態様で通知し、他の場合であれば上記実施態様の態様で通知するようにすればよい）。
【図面の簡単な説明】
【００４１】
【図１】本発明に係るサーバ装置を適用したオンラインサービスシステムの全体構成の一実施例を示すシステムブロック図である。
【図２】図１に示したクライアント又はサーバいずれか１つの全体構成の一実施例を示すハード構成ブロック図である。
【図３】サーバが具備するデータベースのデータ構成の一実施例を示す概念図である。
【図４】サーバが提供するWWWサイトの構成の一実施形態を示す概念図である。
【図５】利用者登録手順を説明するための概念図である。
【図６】登録情報受付処理の一実施例を示すフローチャートである。
【図７】確認URL処理の一実施例を示すフローチャートである。
【図８】戻り先URLの別の設定例について説明するための概念図であり、図８（ａ）はURLテーブルのデータ構成、図８（ｂ）は登録画面の一実施例である。
【図９】WWWサイト上に共通の「登録画面」を用意した場合における戻り先URLの設定例について説明するための概念図であり、図９（ａ）はWWWサイト構成、図９（ｂ）はサービス画面及び登録画面の一実施例である。
【符号の説明】
【００４２】
１…ＣＰＵ、２…ＲＯＭ、３…ＲＡＭ、４…出力デバイス、５…入力デバイス、６…通信デバイス、Ｘ…通信ネットワーク、１Ｄ…データ及びアドレスバス、ＰＣ…クライアント、ＭＳ…サーバ
【図１】
2008226253.tif 000003
【図２】
2008226253.tif 000004
【図３】
2008226253.tif 000005
【図４】
2008226253.tif 000006
【図５】
2008226253.tif 000007
【図６】
2008226253.tif 000008
【図７】
2008226253.tif 000009
【図８】
2008226253.tif 000010
【図９】
2008226253.tif 000011