JP4939450B2 - 通信システム、認証方法およびＷｅｂサービス提供方法 - Google Patents

Description

本発明は、端末同士の通話とＷｅｂサービスを統合する通信システム、認証方法およびＷｅｂサービス提供方法に関し、特にＳＩＰ（Session Initiation Protocol）プロトコルによるセッション制御技術とＷｅｂ（World Wide Web）サービスを提供するアプリケーションサーバの認証技術とを統合する通信システム、認証方法およびＷｅｂサービス提供方法に関する。

従来から、ユーザが、インターネットを介してＷｅｂにアクセスして、Ｗｅｂからサービスを受けることが行われている。一方、インターネット上でＳＩＰプロトコルによって端末同士にＳＩＰセッションを確立して、端末同士がＩＰ電話などにより情報を交換することもよく行われている。しかしながら、Ｗｅｂサービスを行うＷｅｂサービスサーバと、ＳＩＰプロトコルによるセッション制御を行うＳＩＰサーバとは独立して構成されており、ＳＩＰサーバとＷｅｂサーバとの間での情報交換を行うようなことはなかった。したがって、ＳＩＰセッションとＷｅｂサービスとを連携させるサービスはなかった。

なお、コンピュータと電話の機能を統合したシステムについて、インターネットで接続されたコンピュータ端末から通知された接続先電話番号と接続要求元電話番号とを受信する第１の手段と、受信した接続要求元電話番号の電話機を収容する交換機を特定する第２の手段と、特定した交換機に受信した接続先電話番号と接続要求元電話番号を共通線信号網を介して通知し当該電話機間を接続させる第3の手段とを有する電話機接続サービス装置が提案されている（特許文献１参照）。この電話機接続サービスでは、インターネットで接続されたコンピュータ端末から通話開始要求を受けた場合、広告サーバにより所定の広告情報を読み出してコンピュータ端末に表示させるようにしている。
特開２００２−３３５３３７号公報

ネットワーク上での新たなサービスとして、通話中のユーザのみが共有できるＷｅｂサービスを提供することが考えられる。このようなＷｅｂサービスの一例は、通話セッションを確立したユーザが、Ｗｅｂを介して当該ユーザにのみ公開されるディレクトリ内のファィルを閲覧あるいは編集しながら通話することができるようなサービスである。また、通話セッションを確立したユーザが、Ｗｅｂからのストリーミングによる共通の映像を見ながら通話することができるサービスも考えられる。

例えばＳＩＰセッションを確立しているユーザのみにＷｅｂサービスする場合、確立したＳＩＰセッションの情報をＷｅｂサーバが知る必要がある。ＳＩＰセッションの情報をＷｅｂサーバが取得するには、例えば、ＳＩＰサーバが保持している通話状態の情報をＷｅｂサーバに通知するようにすることが考えられる。しかしながら、既存のＳＩＰサーバは、通話状態の情報をＷｅｂサーバに通知する機能を有していない。現在運用中のＳＩＰサーバを改造して通話状態通知機能を組み込むことは、ＳＩＰセッションにどのような障害が発生するかがわからないというリスクを負うことになる。したがって、ＳＩＰサーバからＷｅｂサーバに情報を通知する方法は実現困難である。

ＳＩＰサーバからＷｅｂサーバに情報を通知することが困難であるとすると、ＳＩＰセッションを確立している端末からＷｅｂサーバにＳＩＰセッションの情報を通知することが考えられる。しかしながら、悪意の第三者がＷｅｂサーバに通話を通知して、不正にＷｅｂサービスを受けることを防止する手段を講じる必要がある。したがって、ＳＩＰセッションを含む通話セッションを確立している端末からＷｅｂサーバに通話情報を通知してＷｅｂサービスを受けることができ、かつ第三者が不正にＷｅｂサービスを受けることを防止できるシステムが望まれている。

本通信システムは、発信者側通話端末と着信者側通話端末と、Ｗｅｂサービスを提供するＷｅｂサーバであって、少なくとも発信者側通話端末識別番号と、着信者側通話端末識別番号と、発信者側通話端末および受信者側通話端末の通話通知状態とを記録するデータ管理テーブルを有するＷｅｂサーバと、前記Ｗｅｂサーバにアクセスするための発信者側Ｗｅｂ端末および着信者側Ｗｅｂ端末とを備え、前記発信者側通話端末および前記着信者側通話端末は、通話セッションが確立すると、発信者側通話端末識別番号と着信者側通話端末識別番号とを記録した通話通知を前記Ｗｅｂサーバに送信する。

前記Ｗｅｂサーバは、前記発信者側通話端末と着信者側通話端末のいずれか一方から通話通知を受信する際前記データ管理テーブルを検索し、当該発信者側通話端末識別番号および着信者側通話端末識別番号が前記データ管理テーブルに存在しない場合、当該発信者側通話端末識別番号および着信者側通話端末識別番号と通話通知を送信した前記一方の端末の通話通知状態を前記データ管理テーブルに記録することができる。

前記Ｗｅｂサーバは、前記データ管理テーブルへの記録に伴って動作するサービス開始待ちタイマを有し、該サービス開始待ちサービスタイマが規定する所定期間内に前記発信者側通話端末と着信者側通話端末との双方から通話通知を受信すると、前記データ管理テーブルの通話通知状態を発信者通話通知済みおよび着信者通話通知済みとすることができる。

前記発信者側Ｗｅｂ端末または前記着信者側Ｗｅｂ端末は、少なくとも自端末識別番号を用いて、前記Ｗｅｂサーバにアクセスし、前記Ｗｅｂサーバは、前記データ管理テーブルの通話通知状態が、発信者通話通知済みかつ着信者通話通知済みであることを確認して、前記発信者側Ｗｅｂ端末または前記着信者側Ｗｅｂ端末に前記Ｗｅｂサービスを与えることができる。

前記Ｗｅｂサーバは、前記Ｗｅｂサービスの継続時間を管理するサービス継続タイマを備え、前記Ｗｅｂサービスを受けている間、前記発信者側通話端末および前記着信者側通話端末の少なくとも一方は前記Ｗｅｂサーバに通話通知を送信して、サービス継続タイマに対して継続要求を行うことができる。

本認証方法は、通話中の発信者と着信者にＷｅｂサービスを提供するＷｅｂサーバにおける認証方法であって、該Ｗｅｂサーバは、通話セッションを確立した発信者側通話端末と着信者側通話端末の一方から、発信者側通話端末識別番号と着信者側通話端末識別番号とを記録した通話通知を受信すると、当該発信者側通話端末識別番号と、当該着信者側通話端末識別番号と、当該発信者側通話端末あるいは着信者側通話端末の通話通知状態とをデータ管理テーブルに記録し、前記発信者側通話端末と前記着信者側通話端末の他方から、発信者側通話端末識別番号と着信者側通話端末識別番号とを記録した通話通知を受信すると、前記データ管理テーブルの前記通話通知状態を発信者および着信者の双方からの通話通知済みに変更し、前記発信者側Ｗｅｂ端末と前記着信者側Ｗｅｂ端末のいずれか一方から、少なくとも自端末識別番号をログイン識別番号としてログインされると、前記データ管理テーブルをログイン識別番号に基づいて検索し、通話通知状態が、発信者と着信者の双方からの通話通知済みであることを確認する。

前記Ｗｅｂサーバは、前記発信者側通話端末と着信者側通話端末のいずれか一方から通話通知を受信すると、パスワードを生成し、前記通話通知のあった端末に該パスワードを送信し、前記前記発信者側Ｗｅｂ端末と前記着信者側Ｗｅｂ端末は、該パスワードを自端末識別番号とともに前記ログイン識別番号とすることができる。

本Ｗｅｂサービス提供方法は、通話中の発信者と着信者にＷｅｂサーバからＷｅｂサービスを提供するＷｅｂサービス提供方法であって、該Ｗｅｂサーバは、通話セッションを確立した発信者側通話端末と着信者側通話端末の一方から、発信者側通話端末識別番号と着信者側通話端末識別番号とを記録した通話通知を受信すると、当該発信者側通話端末識別番号と、当該着信者側通話端末識別番号と、当該発信者側通話端末あるいは着信者側通話端末の通話通知状態とをデータ管理テーブルに記録し、前記発信者側通話端末と前記着信者側通話端末の他方から、発信者側通話端末識別番号と着信者側通話端末識別番号とを記録した通話通知を受信すると、前記データ管理テーブルの前記通話通知状態を発信者および着信者の双方からの通話通知済みに変更し、前記発信者側Ｗｅｂ端末と前記着信者側Ｗｅｂ端末のいずれか一方から、少なくとも自端末識別番号をログイン識別番号としてログインされると、前記データ管理テーブルをログイン識別番号に基づいて検索し、通話通知状態が、発信者と着信者の双方からの通話通知済みであることを確認して、前記Ｗｅｂサービスの提供を開始する。

本通信システム、本認証方法およびＷｅｂサービス提供方法では、通話セッションを確立した発信者と着信者とにＷｅｂサーバがＷｅｂサービスを与えることができるとともに、第三者の不正なＷｅｂサービスへのログインを防止することができる。

本実施形態は、ＳＩＰセッションを確立した端末同士が、ファイル共有サービスサーバを介して共有ファイルを閲覧、編集するサービスを受ける例である。図１は、本実施形態のサービスを行うシステムの説明図である。このシステムは、発信者側の通話端末である発側ＳＩＰ端末１１と、着信者側の通話端末である着側ＳＩＰ端末２１と、ＳＩＰサーバ３０とを有する。さらに、発側Ｗｅｂブラウザ１２と、着側Ｗｅｂブラウザ２２と、Ｗｅｂサーバであるファイル共有サービスサーバ４０とを有する。

ファイル共有サービスサーバ４０は、ファイル共有サービスに関するデータを管理するデータ管理テーブル４１と、サービス開始時間を管理するサービス開始待ちタイマ４２と、サービス開始後のサービス継続時間を管理するサービス継続タイマ４３とを有する。なお、サーバは、ネットワークで繋がった他のコンピュータにファイルやデータ等を提供するコンピュータとプログラムからなる。したがって、サーバのハードウェア構成はコンピュータと同様であり、説明を省略する。

図１に示す実線は、ＳＩＰセッションを示し、破線は、ＨＴＴＰセッションを示す。以下に詳細に説明するが、本実施形態では、ＳＩＰセッションを確立した発側ＳＩＰ端末１１と、着側ＳＩＰ端末２１とが、ファイル共有サーバ４０へ通話状態を通知する。その後、発側Ｗｅｂブラウザ１２と着側Ｗｅｂブラウザ２２により、ファイル共有サーバ４０にアクセスして、ファイル共有サービスを受ける。図１では、ＳＩＰ端末とＷｅｂブラウザとを独立して記載したが、両者が一体に構成された情報処理装置あるいは携帯端末やＰＤＡであってもよい。さらに、本システムは、発側と着側でそれぞれ１台のＳＩＰ端末を有するものに限らず、複数台のＳＩＰ端末でＳＩＰセッションを構成するものでもよい。

図２は、本実施形態のシステムの処理フロー（その１）を示す図である。まず、電話番号ＸＸＸ１１１１２２２２をもつ発側ＳＩＰ端末１１が、電話番号ＸＸＸ３３３３４４４４をもつ着側ＳＩＰ端末２１との間で、以下の手順に従ってＳＩＰセッションを確立する。

すなわち、発側ＳＩＰ端末１１はＳＩＰプロトコルに従って、着側ＳＩＰ端末２１に対してセッション参加をリクエストするＩＮＶＩＴＥメッセージを、ＳＩＰプロキシサーバ３０へ送信する。ＳＩＰプロキシサーバ３０は、リクエストが受信され、処理中であることを示す１００Ｔｒｙｉｎｇを発側ＳＩＰ端末１１に返す。次いで、着側ＳＩＰ端末２１にＩＮＶＩＴＥメッセージを送信する。

着側ＳＩＰ端末２１は、リクエストが受信され、処理中であることを示す１００ＴｒｙｉｎｇをＳＩＰプロキシサーバ３０へ返す。次いで、１８０Ｒｉｎｇｉｎｇを、ＳＩＰプロキシサーバ３０を介して、発側ＳＩＰ端末に返す。着側ＳＩＰ端末２１での着信処理が終了すると、着側ＳＩＰ端末２１は、リクエストが成功したことを示す２００ＯＫを、ＳＩＰプロキシサーバ３０を介して、発側ＳＩＰ端末に返す。発側ＳＩＰ端末１１は、ＳＩＰプロキシサーバ３０を介して、着側ＳＩＰ端末２１に肯定応答（Ａｃｋ）を送信する。このようにして、発側ＳＩＰ端末１１と着側ＳＩＰ端末２１との間に、ＳＩＰセッションが確立される（Ｓ１０１）。

その後、発側ＳＩＰ端末１１は、通話中であることを示す通話状態通知をファイル共有サーバ４０に送信するために、ＩＮＶＩＴＥメッセージのヘッダフィールドから、発信者電話番号ＸＸＸ１１１１２２２２と着信者電話番号ＸＸＸ３３３３４４４４とを取得する。そして、発側ＳＩＰ端末１１では、取得した発信者と着信者の電話番号を通話状態の通知のユーザＩＤ項目に設定する（Ｓ１０２）。通話通知の通話状態項目には、通話中を示すＡＣＴＩＶＥを設定する。そして、発側ＳＩＰ端末から、ハイパーテキスト転送プロトコル（ＨＴＴＰ）に従って、通話通知をファイル共有サーバ４０に送信する（Ｓ１０３）。

図３に、ＨＴＴＰに従って、ファイル共有サーバに送信される通話状態の通知の一例を示す。図３に示すように、通話状態通知のボディ部分には、ＳＩＰセッション発信者情報と、ＳＩＰセッション着信者情報が記載され、通話状態を示すactiveあるいはアイドル状態を示すinactiveが記載される。

通話状態であることを通知する通話通知の一例は、次のとおりである。
<cc:origuser>XXX11112222</cc:origuser> ：ＳＩＰセッション発信者情報
<cc:termuser>XXX33334444</cc:termuser> ：ＳＩＰセッション着信者情報
<status><basic>active</basic></status> ：通話状態：active
なお、この通話状態通知が、発信者から通知されたものであることは、図３の「entity=」から始まる行の記載XXX11112222によりわかる。

図２のステップＳ１０４からは、発側ＳＩＰ端末１１から通話通知を受けたファイル共有サーバ４０は、サーバ４０内にあるデータ管理テーブル４１を検索するが、ここでデータ管理テーブルの構成と検索フローさらに通話状態の遷移について、図４〜７を用いて説明する。

データ管理テーブル４１は、ファイル共有サービスを管理するためのデータが格納されているテーブルである。図４に、本実施形態のデータ管理テーブルの項目を示す。データ管理テーブル４１の項目１にはサービスＩＤが格納される。サービスＩＤは、ファイル共有サーバ４０の行うサービスを識別するＩＤである。項目２の発信者ユーザＩＤは、セッションを開始した加入者である発側ＳＩＰ端末のＳＩＰ−ＵＲＬ（Uniform Resource Locator）のユーザ情報（user-info）部から取得した電話番号である。項目の着信者ユーザＩＤは、セッションを開始した加入者の相手である着側ＳＩＰ端末のＳＩＰ−ＵＲＬのユーザ情報部から取得した電話番号である。

項目４のパスワードは、このサービスを受けるためのパスワードで、ファイル共有サーバ４０が当該サービスに対して付与する。このパスワードは、サービスを受けるための１回限りのワンタイムパスワードである。項目５は、発側と着側の通話状態を示す情報である。発側／着側通話状態には、（１）発信者からも着信者からも通話通知を受け付けていないアイドル状態、（２）発信者からのみ通話通知を受け付けている発信者通知済み状態、（３）着信者からのみ通話通知を受け付けている着信者通知済み状態、（４）発信者および着信者の双方から通話通知を受け付けている発側着側通知状態がある。なお、着信者からのみ通話通知を受け付けている状態が設定されるのは、発信者からの通話通知の前に着信者から通話通知が送信される場合である。

図５、６を参照して、本実施形態のＳＩＰ端末から通話通知を受けたＷｅｂサーバの一般的な処理を説明する。通話通知を受け付ける（Ｓ２０１）と、まず、通話通知で指示される通話状態がＡＣＴＩＶＥで通話中であるか否かを確認する（Ｓ２０２）。通話中でなければ、アイドル状態で待機する（Ｓ２０３）。

次に、通話通知が示す発信者ユーザＩＤと着信者ユーザＩＤとで、データ管理テーブルを検索する（Ｓ２０４）。そして、当該発信者ユーザＩＤと着信者ユーザＩＤを項目にもつサービスＩＤが存在するか否かを判断する（Ｓ２０５）。その結果、サービスＩＤが存在しないとすると、通話通知の発信者ユーザＩＤと着信者ユーザＩＤとに基づいて、データ管理テーブルに新たなレコードを生成する（Ｓ２０６）。生成されたレコードには、サービスＩＤが付与される。さらに、付与されたサービスＩＤに対して、固有のワンタイムパスワードが生成される。

レコードが生成されると、サービス開始待ちタイマ４２（図１参照）が起動され（Ｓ２０６）、他方のＳＩＰ端末からの通話状態通知を待つ。サービス開始待ちタイマ４２は、一方のＳＩＰ端末からの通話状態通知があったのち、予め定められた時間内に他方のＳＩＰ端末からの通話状態通知があるか否かを監視する。予め定められた時間内に他方のＳＩＰ端末からの通話状態通知がなければ、サービスを開始しない。

ステップＳ２０５で、データ管理テーブルに、該当の発信者ユーザＩＤと着信者ユーザＩＤを項目にもつサービスＩＤが存在すれば、図６のステップＳ２０８で、通話状態通知は発信者からのものか、着信者からのものかが判断される。次のステップでは、その時の状態が、発信者からも受信者からも通話通知がある状態か、発信者からのみ通話通知がある状態か、着信者からのみ通話通知がある状態か、によって処理が異なる。図６のフローの次のステップを説明する前に、図７を参照して、ＨＴＴＰセッションである通話通知の状態遷移を説明する。

図７に説明するように、アイドル状態５１から、発信者から通話状態であることを示す発信者通話通知（ａ）があると、発信者通知済み状態５２に遷移し、サービス開始待ちタイマ４２が起動される。

サービス開始待ちタイマ４２が所定の時間を過ぎるまで着信者から応答がなかった場合などでは、タイマ満了（ｃ）でサービスは開始されず、終了状態５５を経て、アイドル状態５１へ遷移する。また、通話終了通知（ｄ）を受信したときにも、終了状態５５を経て、アイドル状態へ遷移する。

発信者通知済み状態５２において、サービス開始待ちタイマ４２の所定の時間内に、着信者から通話状態であることを示す着信者通話通知（ｂ）を受信すると、発側着側通知済み状態５４に遷移する。発側着側通知済み状態５４では、サービス開始通知待ちタイマを停止し、サービス継続タイマが起動される。サービス継続タイマは、発信者通話通知（ａ）あるいは着信者通話通知（ｂ）によって更新される。サービス更新を要求する発信者通話通知（ａ）あるいは着信者通話通知（ｂ）を受信せずタイマ満了（ｄ）となるか、通話終了通知（ｄ）を受信すると、サービス終了５５を経て、アイドル状態５１に戻る。

また、アイドル状態５１から、着信者から通話状態であることを示す着信者通話状態通知（ｂ）があると、着信者通知済み状態５３に遷移し、サービス開始待ちタイマが起動される。サービス開始待ちタイマが所定の時間を過ぎるまで発信者から応答がなかった場合などでは、タイマ満了（ｃ）でサービスは開始されず、終了状態５５を経て、アイドル状態５１へ遷移する。また、通話終了通知（ｄ）を受信したときにも、終了状態５５を経て、アイドル状態へ遷移する。

着信者通知済み状態５３で、サービス開始待ちタイマの所定の時間内に、発信者から通話状態であることを示す発信者通話状態通知（ｂ）を受信すると、発側着側通知済み状態５４に遷移する。発側着側通知済み状態５４では、サービス開始通知待ちタイマを停止し、サービス継続タイマが起動される。サービス継続タイマは、発信者通話状態通知（ａ）あるいは着信者通話状態通知（ｂ）をサービス更新信号として更新される。発信者通話状態通知（ａ）あるいは着信者通話状態通知（ｂ）を受信せずタイマ満了（ｄ）となるか、通話終了通知（ｄ）を受信すると、サービス終了５５を経て、アイドル状態５１に戻る。

図６に戻ると、ステップＳ２０８で、通話状態通知が発信者であることが分ると、その時点の状態が、図７に示す、発側着側通知済み状態５４、着信者通知済み状態５３、および発信者通知済み状態５２のうちのいずれかによって、処理が異なる。発側着側通知済み状態５４では、起動されているサービス継続タイマが更新され（Ｓ２１１）、引き続きサービスを受けることができる。

着信者通知済み状態５３では、着信者からの通話通知のある状態で、今回発信者からの通話通知を受信するので、発側着側通知済み状態５４に遷移して、サービス開始が可能となる（Ｓ２１２）。したがって、サービス開始待ちタイマ４２を停止し（Ｓ２１４）、サービス継続タイマを起動し（Ｓ２１４）、サービスを開始する。

発信者通知済み状態５２では、発信者からの通話通知がすでに受信されているので、さらに発信者からの通話通知があっても、状態に変更はなく、なんらの処理も行わない（Ｓ２１３）。

ステップＳ２０８で、通話状態通知が着信者であることが分ると、その時点の状態が、図７に示す、発側着側通知済み状態５４、着信者通知済み状態５３、および発信者通知済み状態５２のうちのいずれかによって、処理が異なる。発側着側通知済み状態５４では、起動されているサービス継続タイマが更新され（Ｓ２１６）、引き続きサービスを受けることができる。

着信者通知済み状態５３では、着信者からの通話通知がすでに受信されているので、さらに着信者からの通話通知があっても、状態に変更はなく、なんらの処理も行わない（Ｓ２１７）。

発信者通知済み状態５２では、発信者からの通話通知がある状態で、今回着信者から通話通知を受信するので、発側着側通知済み状態５４に遷移して、サービス開始が可能となる（Ｓ２１８）。したがって、サービス開始タイマを停止し（Ｓ２１９）、サービス継続タイマを起動し（Ｓ２２０）、サービスを開始する。

図２に戻り、本実施形態の処理フロー（その１）をさらに説明する。図２のステップ１０３では、発側ＳＩＰ端末から、ＨＴＴＰに従って、通話通知をファイル共有サーバ４０に送信する。ファイル共有サーバ４０は、図５のフローに従って、データ管理テーブルを検索し、発信者ユーザＩＤと着信者ユーザＩＤからサービスＩＤを検索する（Ｓ１０４）。

しかしながら、この場合サービスＩＤが見つからないので、通話状態通知の発信者ユーザＩＤと着信者ユーザＩＤとに基づいて、データ管理テーブルに新たなレコードが生成される（Ｓ１０５）。生成されたレコードには、サービスＩＤが付与される。さらに、付与されたサービスＩＤに対して、固有のワンタイムパスワードが生成される。

図８に、データ管理テーブルに生成されるレコードの一例を示す。図８の例では、サービスＩＤの項目には、service0001が設定され、発信者ユーザＩＤの項目には、発側ＳＩＰ端末の電話番号が格納され、着信者ユーザＩＤの項目には着側ＳＩＰ端末の電話番号が格納される。パスワードの項目には、生成されたパスワードであるabcd-efghが格納され、発側着側通話通知状態の項目には、発信者から通知があったことを示す発信者通知済みが格納される。

図２に戻り、ステップＳ１０５で、レコードが生成されると、サービス開始待ちタイマ４２が起動され（Ｓ１０６）、着側ＳＩＰ端末からの通話通知を待つ。サービス開始待ちタイマ４２により規定される時間内に着側ＳＩＰ端末からの通話通知がなく、当該レコードが発側着側通知済みに遷移することがなければ、当該レコードは削除される。なお、図２のステップＳ１０４〜Ｓ１０６のフローは、図５のステップＳ２０５〜Ｓ２０７のフローと同様である。

図９は、図２の処理フロー（その１）に続く、本実施形態のシステムの処理フロー（その２）を示す図である。図９を参照して、データ管理テーブルのワンタイムパスワードabcd-efghは、ファイル共有サーバ４０からのレスポンスとして発側ＳＩＰ端末１１に送信される（Ｓ１０７）。

確立したセッションの他方の着側ＳＩＰ端末２１も、通話通知をファイル共有サーバ４０に送信するために、ＩＮＶＩＴＥメッセージのヘッダフィールドから発信者電話番号ＸＸＸ１１１１２２２２と着信者電話番号ＸＸＸ３３３３４４４４とを取得する。そして、取得した両者の電話番号をユーザＩＤに設定する（Ｓ１０８）。次いで、通話中であることを示す通話通知をファイル共有サーバ４０に送信する（Ｓ１０９）。ＨＴＴＰによる通話通知のボディ部分には、発側ＳＩＰ端末からの通話通知と同様に、次ぎのように記載される。

<cc:origuser>XXX11112222</cc:origuser>
<cc:termuser>XXX33334444</cc:termuser>
<status><basic>active</basic></status>

着側ＳＩＰ端末２１から通話状態通知を受けたファイル共有サーバ４０は、図５のフローで説明したように、データ管理テーブル４１を検索し、発信者ユーザＩＤと着信者ユーザＩＤとに基づいて、サービスＩＤを検索する（Ｓ１１０）。今回は、発側ＳＩＰ端末からの通話状態通知により生成されたサービスＩＤservice0001のレコードが検出される（図８参照）。図６のフローに従って、ファイル共有サービスサーバ４０は、サービスＩＤservice0001のレコードの項目５の発／着通話通知状態を、発信者通知済みから発側着側通知済みに変更する（Ｓ１１１）。図１０に、発／着通話通知状態が発側着側通知済みに変更されたレコードを示す。

発側着側通知済みとなったので、サービスを開始することができる。サービス開始待ちタイマ４２を停止して（Ｓ１１２）、サービス継続タイマ４３（図１参照）を起動する（Ｓ１１３）。サービス継続タイマ４３は、予め定められた時間をカウントすると、サービスを終了させることができる。以下に説明するように、本実施形態では、サービスを継続するために、通話中の端末のいずれかから定期的に通話通知を送信する。

サービス継続タイマ４３が起動した後、ファイル共有サービスサーバ４０は、着側ＳＩＰ端末２１にレスポンスを返す（Ｓ１１４）。着側ＳＩＰ端末２１は、このレスポンスにより、発側ＳＩＰ端末画受信したパスワードと同じパスワードａｂｃｄ−ｅｆｇを受信する。一方、発側ＳＩＰ端末１１では、ステップＳ１０７で受信したパスワードが、発側ＳＩＰ端末１１のディスプレイに表示される（Ｓ１１５）。これにより、発側ＳＩＰ端末のユーザは、Ｗｅｂサーバにアクセスするためパスワードを取得することができる。

図１１は、図９の処理フロー（その２）に続く、本実施形態のシステムの処理フロー（その３）を示す図である。Ｗｅｂサーバにアクセスするためのパスワードを取得した発側ＳＩＰ端末のユーザは、ユーザＩＤである発側ＳＩＰ端末の電話番号ＸＸＸ１１１１２２２２と受信したパスワードａｂｃｄ−ｅｆｇｈを用いて、発側Ｗｅｂブラウザ端末１２からファイル共有サービスサーバ４０を有するポータルサイトにログインする（Ｓ１１６）。

発側Ｗｅｂブラウザ端末１２がログインすると、ファイル共有サービスサーバ４０は、ユーザＩＤに基づいてデータ管理テーブルのサービスＩＤを検索する（Ｓ１１７）。データ管理テーブルにユーザＩＤを発見すると、テーブルに設定してあるパスワードと受信したパスワードとを照合する（Ｓ１１８）。さらに、発／着通話通知状態が発着通知済みであるかがチェックされる（Ｓ１１９）。データ管理テーブルにユーザＩＤが存在し、パスワードが一致し、発着通知済みであれば、発側Ｗｅｂブラウザ端末１２にサービスを提供する（Ｓ１２０）。

図１２を参照して、ブラウザ端末がファイル共有サービスサーバにログインするときのフローをさらに説明する。Ｗｅｂサーバ４０にログインすると、電話番号であるユーザＩＤに基づいて、Ｗｅｂサーバ内のデータ管理テーブル４１を検索し（Ｓ４０１）、ユーザＩＤを項目にもつサービスＩＤがあるか否かが判断される（Ｓ４０２）。サービスＩＤが存在しなければ、認証は失敗であり、ログインできない。

サービスＩＤが存在すれば、テーブルに設定してあるパスワードと受信したパスワードとを照合する（Ｓ４０３）。照合により、双方のパスワードが一致するか否かが判断される（Ｓ４０４）。双方のパスワードが一致しなければ、やはり認証は失敗であり、ログインできない。

双方のパスワードが一致すれば、さらに、発／着通話状態がチェックされ、発信者、着信者の双方からの通話通知が受信されている状態であるか否かが判断される（Ｓ４０５）。発信者あるいは着信者からの通話通知が受信されている状態であっても、発信者、着信者の双方から通話通知が受信されている状態でなければ、認証は失敗であり、ログインできない。発信者、着信者の双方から通話通知が受信されている状態であれば、ファイル共有サービスを開始することができる。

図１３は、図１１の処理フロー（その３）に続く本実施形態のシステムの処理フロー（その４）を示す図である。図１１のフローに示されているように、着側ＳＩＰ端末２１では、ステップＳ１１４（図９）で受信したパスワードが、着側ＳＩＰ端末２１のディスプレイに表示されている（Ｓ１２１）。したがって、図１３に示すように、着信側ユーザは、ユーザＩＤを、着側ＳＩＰ端末の電話番号ＸＸＸ３３３３４４４４とし、パスワードを、受信したパスワードａｂｃｄ−ｅｆｇｈとして、着側Ｗｅｂブラウザ端末２２を用いてファイル共有サービスサーバ４０を有するポータルサイトにログインする（Ｓ１２２）。

着側Ｗｅｂブラウザ端末２２のログイン時の処理は、発側Ｗｅｂブラウザ端末２２のログイン時の処理と同様である。ログインされたファイル共有サービスサーバ４０は、送信されたユーザＩＤに基づいてデータ管理テーブルにサービスＩＤを検索する（Ｓ１２３）。データ管理テーブルにユーザＩＤを発見すると、テーブルに設定してあるパスワードとログインしたパスワードとを照合する（Ｓ１２４）。さらに、発／着通話通知状態が発着通知済みであるかがチェックされる（Ｓ１２５）。データ管理テーブルにユーザＩＤが存在し、パスワードが一致し、発信者と着信者の双方から通知済みであれば、着側Ｗｅｂブラウザ端末２２にサービスを提供する（Ｓ１２６）。

以上のように、発側Ｗｅｂブラウザ端末１２および着側Ｗｅｂブラウザ端末２２からの送信信号は、ファイル共有サービスサーバ４０においてユーザＩＤ、パスワード、発／着通話通知状態がチェックされて、サービスが提供される。

本実施形態では、一例として、発側Ｗｅｂブラウザ端末１２からファイルをファイル共有サービスサーバ４０にアップロードする（Ｓ１２７）。発信者および着信者は、Ｗｅｂブラウザ端末１２、２２を用いて、アップロードされたファイルを参照しながら、通話することができる。そして、必要であればファイルに情報を追加、削除、訂正する作業をして、発側Ｗｅｂブラウザ端末と同様に、着側Ｗｅｂブラウザ端末２２はアップロードされたファイルを取得することができる（Ｓ１２８）。

図１４は、本実施形態の処理フロー（その５）を示す図である。図１４に示すように、ＳＩＰセッションが継続している間中、発側ＳＩＰ端末１１は、サービス継続を要求するために、定期的に通話通知を送信する（Ｓ１２９）。通話通知は、当該サービスの開始要求信号と同じ信号が用いられる。すなわち、ＨＴＴＰによる通話状態通知のボディ部分には、次ぎのように記載される。

<cc:origuser>XXX11112222</cc:origuser>
<cc:termuser>XXX33334444</cc:termuser>
<status><basic>active</basic></status>

通話通知を受信すると、図５、６に示すフローに従って、ファイル共有サーバ４０は、発信者ユーザＩＤと着信者ユーザＩＤとに基づいて、データ管理テーブルを検索する（Ｓ１３０）。登録されているサービスＩＤservice0001のレコードが検出されると、レコードの項目５の発／着通話通知状態が発着通知済みであるか否かをチェックする（Ｓ１３１）。次いで、発着通知済みの状態であれば、サービス継続タイマ４３を更新する（Ｓ１３２）。発ＳＩＰ端末には、通話通知のレスポンスが返される（Ｓ１３３）。

本実施形態では、定期的にサービス継続要求すなわち通話通知を送信して、サービス継続タイマを更新してゆくことで、サービスの継続を確保する。サービス継続要求がなく、予め定められた時間が経過すると、サービスは終了する。例えば、ＳＩＰ端末の電源ＯＦＦにより、ＳＩＰセッションが切断されるような場合である。なお、サービス継続要求は、発側ＳＩＰ端末１１からではなく、着側ＳＩＰ端末２１から送信するようにしてもよい。

図１５は、本実施形態の処理フロー（その６）を示す図である。図１５に示すように、通話を終了すると、発側ＳＩＰ端末１１は、ＳＩＰプロキシサーバ３０を介して、ＢＹＥメッセージを着側ＳＩＰ端末２１に送信する。ＢＹＥメッセージを受信した着側ＳＩＰ端末２１は、ＳＩＰプロキシサーバ３０を介して、２００ＯＫメッセージを発側ＳＩＰ端末１１に送信する。この結果、ＳＩＰセッションが切断される。ＳＩＰセッションが切断されると、発側ＳＩＰ端末１１は、セッション終了通知として不通話通知をファイル共有サービスサーバ４０に送信する（Ｓ１３４）。ＨＴＴＰによる不通話通知のボディ部分には、以下のように、発信者と着信者の電話番号と、通話中ではないことを示すinactiveが記載されている。

<cc:origuser>XXX11112222</cc:origuser>
<cc:termuser>XXX33334444</cc:termuser>
<status><basic>inactive</basic></status>

セッション終了通知を受信すると、ファイル共有サービスサーバ４０では、発信者のユーザＩＤに基づいて、データ管理テーブル４１を検索する（Ｓ１３５）。サービスＩＤservice0001のレコードが検出されると、レコードの項目５の発／着通話通知状態が発着通知済みであるかをチェックする（Ｓ１３６）。次いで、該当サービスＩＤをもつレコードを削除して（Ｓ１３７）、サービス継続タイマ４３を停止する（Ｓ１３８）。その後、発ＳＩＰ端末に、セッション終了通知に対するレスポンスを返し（Ｓ１３９)、発側Ｗｅｂブラウザ端末１２と着側Ｗｅｂブラウザ端末に、サービスが終了したことを知らせる（Ｓ１４０、Ｓ１４１）。なお、ステップＳ１３４のセッション終了通知は、発側ＳＩＰ端末１１からではなく、着側ＳＩＰ端末２１から送信することもできる。

次に、本実施形態により、悪意のある第三者がＷｅｂサービスサーバにログインすることを防止できることを説明する。

図１６は、図１に示す本実施形態のシステムに対して、悪意のある第三者がＷｅｂサービスサーバにログインを試みる場合を説明する図である。図１６では、発側ＳＩＰ端末１１と着側ＳＩＰ端末２１とは、ＳＩＰサーバ３０を介してＳＩＰセッションを確立している。さらに、発側ＳＩＰ端末１１と着側ＳＩＰ端末２１とは、ファイル共有サービスサーバ４０に通話状態通知を送信済みであり、Ｗｅｂブラウザ端末２１、２２は、ファイル共有サービスを受けることができる状態にある。

図１６の状態で、電話に加入している悪意の第三者が、架空の通話状態通知をファイル共有サービスサーバ４０に行って、サービスを受けようとする可能性がある。すなわち、この第三者が、Ｗｅｂブラウザ端末２５を用いてＨＴＴＰに従って、自分の電話番号ＸＸＸ５５５５６６６６と電話番号ＸＸＸ３３３３４４４４を用いて、架空の通話をファイル共有サービスサーバ４０に通知する。この通話通知を受けたファイル共有サービスサーバ４０では、データ管理テーブル４１に、図１７に示すようなサービスＩＤservice0002のレコードを作成する。その結果、パスワードCccc-1234が生成され、第三者に通知される。

第三者が、ユーザＩＤXXX55556666とパスワードCccc-1234を用いて、Ｗｅｂブラウザ端末２５からファイル共有サービスサーバ４０にログインしようとする場合、ファイル共有サービスサーバ４０では、データ管理テーブル４１の発／着通知状態をチェックする。その結果、サービスＩＤservice0002の発／着通知状態が、発信者通知済みの状態であるので、サービス提供不可と判断する。したがって、受信者ＩＤを知った悪意の加入者である第三者が、ファイル共有サービスに不正にログインすることを防止することができる。

図１６の状態で、電話に加入していない悪意の第三者が、発ＳＩＰ端末１１の電話番号を知っていて、Ｗｅｂブラウザ端末２５を用いて、ＨＴＴＰに従って架空の通話をファイル共有サービスサーバ４０に通知するようなことが考えられる。あるいは、第三者が適当に入力した架空の電話番号が発ＳＩＰ端末２１の電話番号と一致するようなことも考えられる。このような場合、第三者が、発ＳＩＰ端末２１の電話番号ＸＸＸ１１１１２２２２と、架空の電話番号ＸＸＸ５５５５６６６６を用いて、架空の通話をファイル共有サービスサーバ４０に通知すると、ファイル共有サービスサーバ４０では、データ管理テーブルに、図１８に示すような、サービスＩＤをservice0002とするレコードが作成される。パスワードＣｃｃｃ−１２３４が生成されている。

第三者が、ユーザＩＤＸＸＸ１１１１２２２２とパスワードＣｃｃｃ−１２３４を用いて、Ｗｅｂブラウザ端末２５からファイル共有サービスサーバ４０にログインしようとする場合、ファイル共有サービスサーバ４０では、データ管理テーブル４１の発／着通知状態をチェックする。その結果、サービスＩＤservice0002の発／着通知状態は、発信者通知済みの状態であるので、サービス提供不可と判断される。したがって、発信者ＩＤを知った悪意の第三者が、ファイル共有サービスに不正にログインすることは防止される。

なお、発ＳＩＰ端末１１と着ＳＩＰ端末２１のセッションが切断された後は、データ管理テーブルから、発ＳＩＰ端末１１と着ＳＩＰ端末２１とに与えられたサービスＩＤがすべて削除されるので、削除された後は、悪意のある第三者が、削除されたサービスＩＤに合致する条件でログインしようとしてもできない。

以上のように、本実施形態では、ＳＩＰセッションとＷｅｂサービスを組み合わせたセキュリティの高いサービスを提供することができる。具体的には、発信者と着信者双方の電話番号と、通話通知状態とをチェックするので、第三者が不正にＷｅｂサービスにログインすることを有効に防止できる。

以上、説明した実施形態の態様は以下のとおりである。

（付記１）
発信者側通話端末と着信者側通話端末と、
Ｗｅｂサービスを提供するＷｅｂサーバであって、少なくとも発信者側通話端末識別番号と、着信者側通話端末識別番号と、発信者側通話端末および受信者側通話端末の通話通知状態とを記録するデータ管理テーブルを有するＷｅｂサーバと、
前記Ｗｅｂサーバにアクセスするための発信者側Ｗｅｂ端末および着信者側Ｗｅｂ端末と
を備え、
前記発信者側通話端末および前記着信者側通話端末は、通話セッションが確立すると、発信者側通話端末識別番号と着信者側通話端末識別番号とを記録した通話通知を前記Ｗｅｂサーバに送信する通信システム。
（付記２）
前記Ｗｅｂサーバは、前記発信者側通話端末と着信者側通話端末のいずれか一方から通話通知を受信する際前記データ管理テーブルを検索し、当該発信者側通話端末識別番号および着信者側通話端末識別番号が前記データ管理テーブルに存在しない場合、当該発信者側通話端末識別番号および着信者側通話端末識別番号と通話通知を送信した前記一方の端末の通話通知状態を前記データ管理テーブルに記録する付記１に記載の通信システム。
（付記３）
前記Ｗｅｂサーバは、前記データ管理テーブルへの記録に伴って動作するサービス開始待ちタイマを有し、該サービス開始待ちサービスタイマが規定する所定期間内に前記発信者側通話端末と着信者側通話端末との双方から通話通知を受信すると、前記データ管理テーブルの通話通知状態を発信者通話通知済みおよび着信者通話通知済みとする付記２に記載の通信システム。
（付記４）
前記Ｗｅｂサーバは、前記発信者側通話端末または着信者側通話端末から通話通知を受信すると、パスワードを生成して、前記通話通知を送信した通話端末に該生成されたパスワードを送信する付記２または３に記載の通信システム。
（付記５）
前記発信者側Ｗｅｂ端末または前記着信者側Ｗｅｂ端末は、少なくとも自端末識別番号を用いて、前記Ｗｅｂサーバにアクセスし、前記Ｗｅｂサーバは、前記データ管理テーブルの通話通知状態が、発信者通話通知済みかつ着信者通話通知済みであることを確認して、前記発信者側Ｗｅｂ端末または前記着信者側Ｗｅｂ端末に前記Ｗｅｂサービスを与える付記２〜４のいずれか１項に記載の通信システム。
（付記６）
前記Ｗｅｂサーバは、前記Ｗｅｂサービスの継続時間を管理するサービス継続タイマを備え、前記Ｗｅｂサービスを受けている間、前記発信者側通話端末および前記着信者側通話端末の少なくとも一方は前記Ｗｅｂサーバに通話通知を送信して、サービス継続タイマに対して継続要求を行う付記５に記載の通信システム。
（付記７）
前記サービス継続タイマの規定する所定時間内に、前記Ｗｅｂサーバが通話通知を受信しなければ、前記データ管理テーブルの当該通話に関する記録が削除される付記６に記載の通信システム。
（付記８）
前記Ｗｅｂサービスを受けている間、前記発信者側通話端末および前記着信者側通話端末のいずれかが、前記Ｗｅｂサーバに通話終了通知を送信すると、前記Ｗｅｂサーバは、前記データ管理テーブルの当該通話に関するデータをすべて削除する付記６又は７に記載の通信システム。
（付記９）
前記Ｗｅｂサーバは、前記発信者側通話端末または着信者側通話端末から通話通知を受信すると、パスワードを生成して、前記通話通知を送信した通話端末に該生成されたパスワードを送信し、前記発信者側Ｗｅｂ端末または着信者側Ｗｅｂ端末が前記Ｗｅｂサーバにアクセスする際のパスワードとして用いる付記４または５に記載の通信システム。
（付記１０）
通話中の発信者と着信者にＷｅｂサービスを提供するＷｅｂサーバにおける認証方法であって、該Ｗｅｂサーバは、
通話セッションを確立した発信者側通話端末と着信者側通話端末の一方から、発信者側通話端末識別番号と着信者側通話端末識別番号とを記録した通話通知を受信すると、当該発信者側通話端末識別番号と、当該着信者側通話端末識別番号と、当該発信者側通話端末あるいは着信者側通話端末の通話通知状態とをデータ管理テーブルに記録し、
前記発信者側通話端末と前記着信者側通話端末の他方から、発信者側通話端末識別番号と着信者側通話端末識別番号とを記録した通話通知を受信すると、前記データ管理テーブルの前記通話通知状態を発信者および着信者の双方からの通話通知済みに変更し、
前記発信者側Ｗｅｂ端末と前記着信者側Ｗｅｂ端末のいずれか一方から、少なくとも自端末識別番号をログイン識別番号としてログインされると、前記データ管理テーブルをログイン識別番号に基づいて検索し、通話通知状態が、発信者と着信者の双方からの通話通知済みであることを確認する認証方法。
（付記１１）
前記Ｗｅｂサーバは、前記発信者側通話端末と着信者側通話端末のいずれか一方から通話通知を受信すると、パスワードを生成し、前記通話通知のあった端末に該パスワードを送信し、前記前記発信者側Ｗｅｂ端末と前記着信者側Ｗｅｂ端末は、該パスワードを自端末識別番号とともに前記ログイン識別番号とする付記１０に記載の認証方法。
（付記１２）
通話中の発信者と着信者にＷｅｂサーバからＷｅｂサービスを提供するＷｅｂサービス提供方法であって、該Ｗｅｂサーバは、
通話セッションを確立した発信者側通話端末と着信者側通話端末の一方から、発信者側通話端末識別番号と着信者側通話端末識別番号とを記録した通話通知を受信すると、当該発信者側通話端末識別番号と、当該着信者側通話端末識別番号と、当該発信者側通話端末あるいは着信者側通話端末の通話通知状態とをデータ管理テーブルに記録し、
前記発信者側通話端末と前記着信者側通話端末の他方から、発信者側通話端末識別番号と着信者側通話端末識別番号とを記録した通話通知を受信すると、前記データ管理テーブルの前記通話通知状態を発信者および着信者の双方からの通話通知済みに変更し、
前記発信者側Ｗｅｂ端末と前記着信者側Ｗｅｂ端末のいずれか一方から、少なくとも自端末識別番号をログイン識別番号としてログインされると、前記データ管理テーブルをログイン識別番号に基づいて検索し、通話通知状態が、発信者と着信者の双方からの通話通知済みであることを確認して、前記Ｗｅｂサービスの提供を開始するＷｅｂサービス提供方法。
（付記１３）
前記Ｗｅｂサーバは、前記発信者側通話端末と着信者側通話端末のいずれか一方から通話通知を受信すると、パスワードを生成し、前記通話通知のあった端末に該パスワードを送信し、前記前記発信者側Ｗｅｂ端末と前記着信者側Ｗｅｂ端末は、該パスワードを自端末識別番号とともに前記ログイン識別番号とする付記１２に記載のＷｅｂサービス提供方法。
（付記１４）
前記Ｗｅｂサーバは、前記データ管理テーブルの前記通話通知状態を発信者および着信者の双方からの通話通知済みに変更した後、サービス継続時間を管理するサービス継続タイマを起動する付記１３に記載のＷｅｂサービス提供方法。
（付記１５）
前記Ｗｅｂサービスを受けている間、前記発信者側通話端末および前記信者側通話端末のいずれかが、前記Ｗｅｂサーバに通話通知を送信して、前記サービス継続タイマの継続要求を行う付記１４に記載のＷｅｂサービス提供方法。
（付記１６）
前記Ｗｅｂサービスを受けている間、前記発信者側通話端末および前記着信者側通話端末のいずれかが、前記Ｗｅｂサーバに通話終了通知を送信すると、前記Ｗｅｂサーバは、前記データ管理テーブルの前記発信者と前記着信者との通話に関するデータを削除する付記１４又は１５に記載のＷｅｂサービス提供方法。

本実施形態のサービスシステムの概略を示す図である。 本実施形態のサービスシステムの処理フロー（その１）を示す図である。 本実施形態のＳＩＰ端末からＷｅｂサーバに送信されるＨＴＴＰに従う通話状態通知の一例を示す図である。 本実施形態のデータ管理テーブルの項目を説明する図である。 本実施形態のＷｅｂサーバによる通話状態通知の処理フロー（その１）を示す図である。 本実施形態のＷｅｂサーバによる通話状態通知の処理フロー（その２）を示す図である。 本実施形態の通話状態の遷移を示す図である。 本実施形態のデータ管理テーブルのレコードの一例を示す図である。 本実施形態のサービスシステムの処理フロー（その２）を示す図である。 本実施形態のデータ管理テーブルのレコードの他の例を示す図である。 本実施形態のサービスシステムの処理フロー（その３）を示す図である。 本実施形態のＷｅｂサーバによるログイン処理フローを示す図である。 本実施形態のサービスシステムの処理フロー（その４）を示す図である。 本実施形態のサービスシステムの処理フロー（その５）を示す図である。 本実施形態のサービスシステムの処理フロー（その６）を示す図である。 本実施形態のサービスシステムへの不正侵入防止を説明する図である。 本実施形態のサービスシステムへの不正侵入防止が可能なデータ管理テーブルのレコードの一例を示す図である。 本実施形態のサービスシステムへの不正侵入防止が可能なデータ管理テーブルのレコードの他の例を示す図である。

符号の説明

１１ 発側ＳＩＰ端末
１２ 発側Ｗｅｂブラウザ端末
２１ 着側ＳＩＰ端末
２２ 着側Ｗｅｂブラウザ端末
３０ ＳＩＰサーバ
４０ Ｗｅｂサーバ（ファイル共有サービスサーバ）
４１ データ管理テーブル
４２ サービス開始待ちタイマ
４３ サービス継続タイマ

Claims (8)

1. 発信者側通話端末と着信者側通話端末と、
   Ｗｅｂサービスを提供するＷｅｂサーバであって、少なくとも発信者側通話端末識別番号と、着信者側通話端末識別番号と、発信者側通話端末および受信者側通話端末の通話通知状態とを記録するデータ管理テーブルを有するＷｅｂサーバと、
   前記Ｗｅｂサーバにアクセスするための発信者側Ｗｅｂ端末および着信者側Ｗｅｂ端末と
   を備え、
   前記発信者側通話端末および前記着信者側通話端末は、通話セッションが確立すると、発信者側通話端末識別番号と着信者側通話端末識別番号とを記録した通話通知を前記Ｗｅｂサーバに送信する通信システム。
2. 前記Ｗｅｂサーバは、前記発信者側通話端末と着信者側通話端末のいずれか一方から通話通知を受信する際前記データ管理テーブルを検索し、当該発信者側通話端末識別番号および着信者側通話端末識別番号が前記データ管理テーブルに存在しない場合、当該発信者側通話端末識別番号および着信者側通話端末識別番号と通話通知を送信した前記一方の端末の通話通知状態を前記データ管理テーブルに記録する請求項１に記載の通信システム。
3. 前記Ｗｅｂサーバは、前記データ管理テーブルへの記録に伴って動作するサービス開始待ちタイマを有し、該サービス開始待ちサービスタイマが規定する所定期間内に前記発信者側通話端末と着信者側通話端末との双方から通話通知を受信すると、前記データ管理テーブルの通話通知状態を発信者通話通知済みおよび着信者通話通知済みとする請求項２に記載の通信システム。
4. 前記発信者側Ｗｅｂ端末または前記着信者側Ｗｅｂ端末は、少なくとも自端末識別番号を用いて、前記Ｗｅｂサーバにアクセスし、前記Ｗｅｂサーバは、前記データ管理テーブルの通話通知状態が、発信者通話通知済みかつ着信者通話通知済みであることを確認して、前記発信者側Ｗｅｂ端末または前記着信者側Ｗｅｂ端末に前記Ｗｅｂサービスを与える請求項２または３に記載の通信システム。
5. 前記Ｗｅｂサーバは、前記Ｗｅｂサービスの継続時間を管理するサービス継続タイマを備え、前記Ｗｅｂサービスを受けている間、前記発信者側通話端末および前記着信者側通話端末の少なくとも一方は前記Ｗｅｂサーバに通話通知を送信して、サービス継続タイマに対して継続要求を行う請求項２〜４のいずれか１項に記載の通信システム。
6. 通話中の発信者と着信者にＷｅｂサービスを提供するＷｅｂサーバにおける認証方法であって、該Ｗｅｂサーバは、
   通話セッションを確立した発信者側通話端末と着信者側通話端末の一方から、発信者側通話端末識別番号と着信者側通話端末識別番号とを記録した通話通知を受信すると、当該発信者側通話端末識別番号と、当該着信者側通話端末識別番号と、当該発信者側通話端末あるいは着信者側通話端末の通話通知状態とをデータ管理テーブルに記録し、
   前記発信者側通話端末と前記着信者側通話端末の他方から、発信者側通話端末識別番号と着信者側通話端末識別番号とを記録した通話通知を受信すると、前記データ管理テーブルの前記通話通知状態を発信者および着信者の双方からの通話通知済みに変更し、
   前記発信者側Ｗｅｂ端末と前記着信者側Ｗｅｂ端末のいずれか一方から、少なくとも自端末識別番号をログイン識別番号としてログインされると、前記データ管理テーブルをログイン識別番号に基づいて検索し、通話通知状態が、発信者と着信者の双方からの通話通知済みであることを確認する認証方法。
7. 前記Ｗｅｂサーバは、前記発信者側通話端末と着信者側通話端末のいずれか一方から通話通知を受信すると、パスワードを生成し、前記通話通知のあった端末に該パスワードを送信し、前記前記発信者側Ｗｅｂ端末と前記着信者側Ｗｅｂ端末は、該パスワードを自端末識別番号とともに前記ログイン識別番号とする請求項６に記載の認証方法。
8. 通話中の発信者と着信者にＷｅｂサーバからＷｅｂサービスを提供するＷｅｂサービス提供方法であって、該Ｗｅｂサーバは、
   通話セッションを確立した発信者側通話端末と着信者側通話端末の一方から、発信者側通話端末識別番号と着信者側通話端末識別番号とを記録した通話通知を受信すると、当該発信者側通話端末識別番号と、当該着信者側通話端末識別番号と、当該発信者側通話端末あるいは着信者側通話端末の通話通知状態とをデータ管理テーブルに記録し、
   前記発信者側通話端末と前記着信者側通話端末の他方から、発信者側通話端末識別番号と着信者側通話端末識別番号とを記録した通話通知を受信すると、前記データ管理テーブルの前記通話通知状態を発信者および着信者の双方からの通話通知済みに変更し、
   前記発信者側Ｗｅｂ端末と前記着信者側Ｗｅｂ端末のいずれか一方から、少なくとも自端末識別番号をログイン識別番号としてログインされると、前記データ管理テーブルをログイン識別番号に基づいて検索し、通話通知状態が、発信者と着信者の双方からの通話通知済みであることを確認して、前記Ｗｅｂサービスの提供を開始するＷｅｂサービス提供方法。

Images