JP2008129081A - 対話形式講義支援システム - Google Patents

Abstract

【目的】講師紹介等の情報配信と講師及び生徒間の双方向通話との円滑な連携を可能とする対話形式講義支援システムを提供する。
【構成】複数の生徒端末と複数の講師端末との間で双方向通話を可能とすることで、該端末間でなされる対話形式講義を支援する対話形式講義支援システムであり、該生徒端末に講師選択メニューを配信し、該生徒端末の１から発せられる講師選択指令に応じて、選択された講師に対応する講師端末と該生徒端末の１との間に、該双方向通話のための通話セッションを確立する。
【選択図】図１

Description

本発明は、インターネット英会話レッスンのように、インターネット等のネットワークを介して生徒端末と講師端末との間に双方向通話を可能とすることで、該端末間でなされる対話形式講義を支援する対話形式講義支援システムに関する。

例えば、従来のインターネット英会話レッスンを例にとると、利用者は、先ずＷｅｂサイトで講師の紹介情報を閲覧し希望する講師を指定して講義を申し込み、その後にソフトフォン等の通話手段を利用して当該講師との間でオンライン双方向通話による英会話受講を行うなどの複数段階からなる運用を行っていた。

かかる運用が必要となる理由は、ホームページ配信を実現するＨＴＴＰプロトコルを用いたサーバクライアント構成であるＷｅｂ（World Wide Web）環境と、ＶｏＩＰ（Voice Over Internet Protocol）を実現するＳＩＰ（Session Initiation Protocol）プロトコルを用いたピアツーピア構成であるＳＩＰ環境との融合が図られていないことに起因する。英会話レッスンの場合においては、利用者に適切な講師を紹介するアプリケーションプログラム（ＡＰ：Application Program）はＷｅｂ環境で動作し、会話をオンラインで行う通話機能を提供するアプリケーションプログラムはＳＩＰ環境で動作していた。ＳＩＰ環境におけるアプリケーションプログラムの動作を実現する方法としては、例えば、非特許文献１において公開されるＪＳＲ１１６：SipServletＡＰＩ（Application Program Interface）仕様が参照される。
http://jcp.org/aboutJava/communityprocess/final/jsr116/index.html

従って、従来の構成では円滑な運用が行えないという問題があった。

本発明の目的は、講師紹介等の情報配信と講師及び生徒間の双方向通話との円滑な連携を可能とする対話形式講義支援システムを提供することである。

本発明による対話形式講義支援システムは、複数の生徒端末と複数の講師端末との間で双方向通話を可能とすることで、該端末間でなされる対話形式講義を支援する対話形式講義支援システムであり、該生徒端末に講師選択メニューを配信する講師選択メニュー配信手段と、該生徒端末の１から発せられる講師選択指令に応じて、選択された講師に対応する講師端末と該生徒端末の１との間に、該双方向通話のための通話セッションを確立する通話セッション確立手段とを含むことを特徴とする。

本発明による対話形式講義支援システムによれば、講師紹介等の情報配信と講師及び生徒間の双方向通話との円滑な連携が可能となる。

本発明の実施例について添付の図面を参照しつつ詳細に説明する。

図１は、本発明の実施例を示し、英会話レッスン提供システムの全体構成を示している。英会話レッスン提供システム10は、本発明による対話形式講義支援システムであり、インターネット40を介して利用者、すなわち生徒に英会話レッスンを提供するシステムである。該システムにより、世界中に居住し英語を教える事が出来る講師と英会話を学びたい生徒とをＷｅｂサイト上でマッチングして、安全な英会話レッスンを提供するインターネット英会話サービスが実現される。

本図を参照すると、生徒となるべき利用者は、クライアントＡに含まれるＷｅｂブラウザ51を使用してＷｅｂサイト等から情報配信を受けると共に、クライアントＡに含まれるソフトフォン52を使用して音声通信サービスの提供を受ける。一方、生徒にレッスンを提供する講師は、クライアントＢに含まれるＷｅｂブラウザ61を使用してＷｅｂサイト等から情報配信を受けると共に、クライアントＢに含まれるソフトフォン62を使用して音声通信サービスの提供を受ける。本実施例では、クライアントＡを生徒端末とし且つクライントＢを講師端末とする例が説明されるが、本発明にはかかる限定はなく、２つ以上のクライアントが存在して多数の生徒あるいは講師の使用に供されることが前提とされる。

Ｗｅｂブラウザ51及び61は、Ｗｅｂサーバ32と接続し、Ｗｅｂ−ＡＰ35が提供する機能を利用するためのクライアント環境である。ソフトフォン52及び62は、ＳＩＰ対応のＩＰ電話端末であり、ＳＩＰ環境20との間はインターネット40を介して接続される。

英会話レッスン提供システム10は、第１通信環境であるＳＩＰ環境20と、第２通信環境であるＷｅｂ環境30とを含み、双方はＬＡＮ41を介して相互に接続されていると共にインターネット40に接続されている。ＳＩＰ環境20とＷｅｂ環境30とは、ＬＡＮ41を介することなくインターネット40に直接接続されても良い。すなわち、ＳＩＰ環境20とＷｅｂ環境30とは、異なるネットワークドメインに属するネットワーク環境上に配置されても良いし、あるいはＳＩＰ環境20及びＷｅｂ環境30が同一のサーバ計算機装置内に配置されても良い。

図２は、ＳＩＰ環境20及びＷｅｂ環境30のより詳細の構成を示している。
＜ＳＩＰ環境20の構成＞
先ず、ＳＩＰ環境20の構成について説明すると、ＳＩＰサーバ22は、ＩＥＴＦで規定される、例えば、ＲＦＣ３２６１に準拠したＳＩＰをハンドリング及び管理するサーバであり、ＳＩＰプロキシサーバ機能、ＳＩＰレジストラサーバ機能、及びＳＩＰロケーションサーバ機能を有する。ＳＩＰプロキシサーバ機能はクライアントの代理としてＳＩＰメッセージの中継を行う機能である。ＳＩＰレジストラサーバ機能はクライアントの登録を管理する機能である。ＳＩＰロケーションサーバ機能は登録されたクライアントのアドレス情報等を管理する機能である。

ＳＩＰ−ＤＢ21は、ＳＩＰサーバ22が管理する情報、例えば、ユーザ情報、プレゼンス情報及び講師状態等の状態管理ＤＢを格納するデータベースである（図８の（ｃ）参照）。ここで、ユーザー情報とは生徒や講師等のクライアントのアドレス情報や認証を行うための情報である。プレゼンス情報とはクライアントが接続されているか否か、クライアントが起動或いは利用されているか否か、更には別のクライアントと接続中であるか否か等のクライアントの状態を表す情報である。講師状態とはマッチングＡＰが管理するＳＩＰ関連情報である。また、講師のプレゼンス及び講義履歴とは講師と利用者との接続状態や通信履歴の情報である。

ＳＩＰ−ＡＰサーバ23は、ＳＩＰサーバ22により管理されるＳＩＰプロトコルを操作するＡＰを稼働するサーバである。ＳＩＰサーバ22で受信するＳＩＰリクエスト、例えば、セッション確立、確認応答、通話終了及びプレゼンス変更等のリクエストを操作する機能を有し、更に、ＳＩＰサーバ22へのリクエストを発行する機能を有する。

ＳＩＰ−ＡＰＩ24は、ＳＩＰ−ＡＰサーバ23が提供するＡＰインターフェースであり、代表的には、ＪＣＰ（Java Community Process）において標準化作業が進められているSIP Servlet ＡＰＩを用いて実現される。ＳＩＰ−ＡＰ25は、ＳＩＰ−ＡＰＩ24により構築され、ＳＩＰ−ＡＰサーバ23上で稼働するＳＩＰ対応ＡＰ（Application Program）であり、例えば、ＩＰ電話、インスタントメッセージ、ＴＶ電話、プレゼンスコミュニケーション等を実現するＡＰを含む。

Ｗｅｂアクセッサコンポーネント26は、ＳＩＰ−ＡＰ25がＷｅｂ環境30と連携するためのコンポーネント群、すなわちライブラリソフトウェア部品の総称である。Ｗｅｂアクセッサコンポーネント26は、プレゼンス管理261と、シグナリング管理262と、コール管理263と、連携管理269とを含む。

プレゼンス管理261は、ＳＩＰ環境20内で管理するプレゼンス情報を操作管理するためのコンポーネントである。シグナリング管理262は、ＳＩＰ環境20内の構成要素であるＳＩＰサーバ22を利用して、ＳＩＰシグナリング操作管理するためのコンポーネントである。コール管理263は、ＳＩＰ環境20内で管理するコール状態を操作管理するためのコンポーネントである。連携管理269は、Ｗｅｂ環境30内の対応する機構と連携し、Ｗｅｂ環境30側からＳＩＰ環境20にアクセスする、またはＳＩＰ環境20からＷｅｂ環境30側にアクセスするための通信環境であり、例えば、ＳＯＡＰ（Simple Object Access Protocol）やＣＯＲＢＡ（Common Object Request Broker Architecture）を用いて実現され得る。
＜Ｗｅｂ環境30の構成＞
次に、Ｗｅｂ環境30の構成について説明すると、Ｗｅｂサーバ32は、ＨＴＴＰをハンドリング及び管理するサーバである。Ｗｅｂ−ＤＢ31は、Ｗｅｂサーバ32が管理する情報、例えば、利用ログ、マッチングＡＰ用生徒情報、講師情報等の生徒ＤＢ及び講師ＤＢを格納するデータベースである（図８の（ａ）及び（ｂ）参照）。生徒ＤＢは、生徒毎に当該生徒と講師による生徒評価とを対応付ける対応テーブルを構成する。一方、講師ＤＢは、当該講師と生徒による講師評価とを対応付ける対応テーブルを構成する。

利用ログとはＷｅｂアクセスの利用状況を表す情報である。生徒情報とは後述するマッチングＡＰで管理する情報であり、例えば、利用者の氏名及びＴＯＥＩＣ点数を含む基本情報と、受講目的、希望金額、性別、年齢及び国籍を含む検索条件と、講師、講師評価を含む受講履歴などの情報からなる。講師情報とはマッチングＡＰで管理する情報であり、講師の氏名、講義レベルやＴＯＥＩＣ点数を含む基本情報と、得意分野、希望金額、性別、年齢及び国籍を含む検索条件と、利用者及び評価結果を含む講義履歴とからなる。

Ｗｅｂ−ＡＰサーバ33は、Ｗｅｂサーバ32により管理されるＷｅｂプロトコル、すなわち、ＨＴＴＰを操作するＡＰ（Application Program）を稼働するサーバであり、例えば、オープンソースのＴＯＭＣＡＴ及びＢＥＡ社が提供するＷｅｂＬｏｇｉｃを用いて実現され得る。Ｗｅｂ−ＡＰＩ34は、Ｗｅｂ−ＡＰサーバ33が提供するＡＰインターフェースであり、代表的には、Ｊ２ＥＥ（Java 2 Enterprise Edition）環境で規定されているＨＴＴＰ Servlet ＡＰＩやＥＪＢ（Enterprise Java Beans）を用いて実現される。

Ｗｅｂ−ＡＰ35は、Ｗｅｂ−ＡＰＩ34により構築され、Ｗｅｂ−ＡＰサーバ217上で動作するＷｅｂ−ＡＰであり、マッチングＡＰ226を含む。マッチングＡＰ226の機能については後述する（図６の説明参照）。

ＳＩＰアクセッサコンポーネント36は、Ｗｅｂ−ＡＰ35がＳＩＰ環境20と連携するためのコンポーネント群の総称であり、Ｗｅｂ−ＡＰ35がＳＩＰ環境20上の機能、すなわちＷｅｂアクセッサコンポーネント26と交信する際に利用される。ＳＩＰアクセッサコンポーネント36は、プレゼンス管理361と、シグナリング管理362と、コール管理363と、連携管理369とを含む。

プレゼンス管理361は、ＳＩＰ環境20内で管理されるプレゼンス情報をアクセスするためのＷｅｂ環境30内のコンポーネントである。シグナリング管理362は、ＳＩＰ環境20内の構成要素であるＳＩＰサーバ22を利用して、ＳＩＰシグナリングを利用するためのＷｅｂ環境30内のコンポーネントである。コール管理363は、ＳＩＰ環境20内で管理されるコール状態をアクセスするためのＷｅｂ環境30内のコンポーネントである。

連携管理369は、ＳＩＰ環境20内の対応する機構と連携し、コール管理223を利用してＷｅｂ環境30からＳＩＰ環境20側にアクセスする、またはＳＩＰ環境20側からＷｅｂ環境30側にアクセスさせるための通信環境である。かかる通信環境は、ＳＩＰ環境20内の連携管理269に対応して、ＳＯＡＰ（Simple Object Access Protocol）やＣＯＲＢＡ（Common Object Request Broker Architecture）を用いて実現され得る。

図３は、図２に示されたプレゼンス管理261及びプレゼンス管理361のより詳細の構成を示している。ここでは、プレゼンス管理261をＳＩＰ側プレゼンス管理261とし、プレゼンス管理361をＷｅｂ側プレゼンス管理361として以下説明する。コンポーネントＡＰＩ268は、プレゼンス管理261をＳＩＰ−ＡＰ25が利用するためのＡＰＩ（application program interface）であり、コンポーネントＡＰＩ368は、プレゼンス管理361をＷｅｂ−ＡＰ35が利用するためのＡＰＩである。

ＳＩＰ側プレゼンス管理261は、ＳＩＰ−ＤＢ21上で管理されるプレゼンス情報の操作管理を行うコンポーネントである。ＳＩＰ側プレゼンス管理261は、プレゼンス情報を登録するプレゼンス情報登録2611と、登録されたプレゼンス情報を最新の情報に変更するプレゼンス情報変更2612と、登録されたプレゼンス情報を検索するプレゼンス情報検索2613と、ＳＩＰサーバ22を介して更新された最新のプレゼンス情報を、Ｗｅｂ側プレゼンス管理モジュール222に通知するプレゼンス情報更新通知アクセスモジュール2614とからなる。

Ｗｅｂ側プレゼンス管理361は、上記したＳＩＰ側プレゼンス管理261内の各機能を、連携管理269と連携管理369との通信によりアクセスするためのモジュールから構成される。Ｗｅｂ側プレゼンス管理361は、プレゼンス情報登録アクセスモジュール3611と、プレゼンス情報変更アクセスモジュール3612と、プレゼンス情報検索アクセスモジュール3613と、プレゼンス情報更新通知3614とからなる。これらは、ＳＩＰ側プレゼンス管理261内の対応する機能と連携することでアクセス機能を実現する。

図４は、図２に示されたシグナリング管理262及びシグナリング管理362のより詳細の構成を示している。ここでは、シグナリング管理262をＳＩＰ側シグナリング管理262とし、シグナリング管理362をＷｅｂ側シグナリング管理362として以下説明する。コンポーネントＡＰＩ268は、シグナリング管理262をＳＩＰ−ＡＰ25が利用するためのＡＰＩ（application program interface）であり、コンポーネントＡＰＩ368は、シグナリング管理362をＷｅｂ−ＡＰ35が利用するためのＡＰＩである。

ＳＩＰ側シグナリング管理262は、ＳＩＰサーバ22を利用してＳＩＰシグナリングの操作管理を行うコンポーネントであり、ＳＩＰサーバ22を利用して２者間のコミュニケーション機能を提供しClick To Dial等の操作を可能とする３ＰＣＣ（3rd Party Call Control）管理2621と、２者間コミュニケーションを２つの分かれたＳＩＰセッションとして実現するＢ2ＢＵＡ（Back To Back User Agent）管理2622と、ＳＩＰサーバ22を介して実行された３ＰＣＣの完了をＷｅｂ側シグナリング管理362に通知する３ＰＣＣ完了通知アクセスモジュール2623とからなる。

Ｗｅｂ側シグナリング管理362は、上記したＳＩＰ側シグナリング管理262内の各モジュールとの相互通信を、連携管理269と連携管理369との通信により実現するためのモジュールから構成される。Ｗｅｂ側シグナリング管理362は、Ｗｅｂ環境30内からＳＩＰ側シグナリング管理262内の３ＰＣＣ管理にアクセスする３ＰＣＣ管理アクセスモジュール3621と、Ｗｅｂ環境30内からＳＩＰ側シグナリング管理262内のＢ2ＢＵＡ管理にアクセスするＢ2ＢＵＡ管理アクセスモジュール3622と、ＳＩＰ側シグナリング管理262内の３ＰＣＣ管理の実行完了の通知を受け取り、Ｗｅｂ環境30内から要求された３ＰＣＣの実行が完了されたことを認識する３ＰＣＣ完了通知3623とからなる。

図５は、図２に示されたコール管理263及びコール管理363のより詳細の構成を示している。ここでは、コール管理263をＳＩＰ側コール管理263とし、コール管理363をＷｅｂ側コール管理363として以下説明する。コンポーネントＡＰＩ268は、コール管理263をＳＩＰ−ＡＰ25が利用するためのＡＰＩ（application program interface）であり、コンポーネントＡＰＩ368は、コール管理363をＷｅｂ−ＡＰ35が利用するためのＡＰＩである。

コール管理263は、ＳＩＰ−ＤＢ21に含まれる状態管理ＤＢに基づいてコール状態の操作管理を行うコンポーネントであり、コール状態を登録するコール状態登録2631と、登録されたコール状態を最新の情報に変更するコール状態更新2632と、登録されたコール状態を検索するコール状態検索2633と、登録されたコール状態を削除するコール状態削除2634とからなる。

Ｗｅｂ側コール管理363は、上記したコール管理263内の各モジュールを連携管理269と連携管理369との通信によりアクセスするためのモジュールから構成される。Ｗｅｂ側コール管理363は、コール状態登録アクセスモジュール3631と、コール状態更新アクセスモジュール3632と、コール状態検索アクセスモジュール3633と、コール状態削除アクセスモジュール3634とを含み、これらは、コール管理263内の対応する機能と連携することでアクセス機能を実現する。

図６は、マッチングＡＰ351の構成を示している。マッチングＡＰ351は、情報登録機能3511と、検索条件メニュー表示機能3512と、マッチング機能3513と、検索結果表示機能3514と、評価メニュー表示機能3515と、評価結果集計機能3516と、評価結果送信機能3517と、評価結果登録機能3518とを含む。マッチングＡＰ351は、生徒ＤＢと講師ＤＢとを含むＷｅｂ−ＤＢ31と状態管理ＤＢを含むＳＩＰ−ＤＢ21にアクセスする。

情報登録機能3511は、Ｗｅｂブラウザに講師用の登録画面、利用者用の登録画面を表示し登録講師情報ＤＢと登録利用者情報ＤＢに情報を登録するためのモジュールである。検索条件メニュー表示機能3512は、利用者が検索条件を入力する画面を表示するためのモジュールである。

マッチング機能3513は、マッチング優先順位設定機能を有するマッチング検索モジュールであり、利用者が登録したＷｅｂ−ＤＢの生徒情報ＤＢをもとに、登録された講師情報ＤＢから、利用者が設定した優先順位で、講師をリストアップする。更にＳＩＰ−ＤＢの講師情報ＤＢから講師のプレゼンス情報を抽出し、講義可能なオンラインの講師のみをピックアップする検索機能を有する。また、サービス運用者側は必要に応じて優先順位を変更することができ、また、利用者側も自分の検索条件入力時に優先順位を設定できる（図７（ａ）参照）。

検索結果表示機能3514は、利用者のＷｅｂブラウザへマッチングＡＰによる検索結果を表示するモジュールである。評価メニュー表示機能3515は、利用者と講師のセッションが切断された時に、利用者は講師の評価を、講師は利用者の評価をできる評価シートの入力画面をそれぞれのＷｅｂブラウザに表示するモジュールである。

評価結果集計機能3516は、利用者による講師の評価結果、及び講師による利用者の評価結果を集計するモジュールであり、例えば、個別の評価結果をもとに様々な基準で総合判定を行うことができる（図７（ｂ）参照）。

評価結果送信機能3517は、利用者による講師の評価結果を講師に、また、講師による利用者の評価結果を生徒に通知するモジュールである。評価結果登録機能3518は、利用者と講師が評価シートに記入及び登録に応じて、それぞれの情報をＷｅｂ−ＤＢに登録するモジュールである。

図９は、講師選択のための検索依頼から検索結果表示に至る動作シーケンスを示している。

先ず、ＷｅｂブラウザＡは、利用者の操作に応じてマッチングＡＰの入力画面表示要求をＷｅｂサーバ／Ｗｅｂ−ＡＰサーバに向けて依頼する（ステップS101）。これに応じて、Ｗｅｂサーバ／Ｗｅｂ−ＡＰサーバは、マッチングＡＰに入力画面表示要求を送信する（ステップS102）。次に、マッチングＡＰは要求された入力画面を送信する（ステップS103）。次に、Ｗｅｂサーバ／Ｗｅｂ−ＡＰサーバはＷｅｂブラウザＡに入力画面を表示する（ステップS104）。ここで、図１２に示す如く、入力画面70には、利用者のＴＯＥＩＣ点数、受講目的、講義料金、講師の性別、年齢及び国籍などの検索条件を入力する入力欄71や検索ボタン72が実装されている。なお、好ましくは入力画面は優先順位が指定できる。

次に、ＷｅｂブラウザＡは、利用者の操作に応じて講師の情報検索を依頼する（ステップS105）。ここで、検索対象となる情報は、講師の講義レベル（ＴＯＥＩＣの点数に換算）得意分野、講師料金、性別、年齢、国籍及び講師のプレゼンス情報などの情報が含まれる。

次に、マッチングＡＰはＷｅｂサーバ／Ｗｅｂ−ＡＰサーバから情報検索依頼を受信する（ステップS106）。次に、マッチングＡＰは利用者の入力情報をＷｅｂ−ＤＢに含まれる生徒ＤＢに登録する（ステップS107）。次に、生徒ＤＢは登録完了結果を送信する（ステップS108）。マッチングＡＰは、マッチングＡＰ内の優先順位設定機能により利用者の入力情報をもとに、優先項目順にＷｅｂ−ＤＢに含まれる講師ＤＢに検索を依頼する（ステップS109）。検索終了に応じて、講師ＤＢは検索結果をマッチングＡＰへ送信する（ステップS110）。以上のステップS109〜S110を優先項目の数だけ実行することにより最終的に講師一覧が抽出される。

次に、マッチングＡＰは、検索結果として抽出された講師一覧の中からオンラインである講師を抽出するためプレゼンスの“検索依頼”をＷｅｂ側プレゼンス管理に発行する（ステップS111）。これに応じて、Ｗｅｂ側プレゼンス管理は、ＳＩＰ側プレゼンス管理との間で連携を行うことで、ＳＩＰ側にプレゼンスの検索依頼を転送する（ステップS112）。

これに応じて、ＳＩＰ側プレゼンス管理はＳＩＰ−ＡＰサーバ／ＳＩＰサーバへ検索依頼を送信する（ステップS113）。ＳＩＰ−ＡＰサーバ／ＳＩＰサーバはＳＩＰ−ＤＢへ検索依頼を発行する（ステップS114）。ＳＩＰ−ＤＢに含まれる状態管理ＤＢは、登録された講師のプレゼンス情報を抽出する検索を行い、その検索結果をＳＩＰ−ＡＰサーバ／ＳＩＰサーバへ送信する（ステップS115）。ＳＩＰ−ＡＰサーバ／ＳＩＰサーバは、該検索結果をＳＩＰ側プレゼンス管理に通知する（ステップS116）。ＳＩＰ側プレゼンス管理は、Ｗｅｂ側プレゼンス管理との間で連携を行うことで、Ｗｅｂ側に該検索結果を転送する（ステップS117）。該検索結果はオンライン状態の講師一覧が含まれている。

以上の結果、上記した“検索依頼”に対応する検索結果がＷｅｂ側プレゼンス管理にて受信される。次いで、Ｗｅｂプレゼンス管理は該検索結果をマッチングＡＰに返却する（ステップS118）。マッチングＡＰは、検索結果の表示をＷｅｂ−ＡＰサーバ／Ｗｅｂサーバへ要求する（ステップS119）。次いで、Ｗｅｂ−ＡＰサーバ／Ｗｅｂサーバは、利用者のＷｅｂブラウザＡに、当該利用者にマッチしたオンライン状態の講師の検索結果を講師選択メニューとして表示する（ステップS120）。この状態で、図１２に示す如く、利用者が検索結果73の講師一覧を選択肢とする講師のうちの１つに対応する発信依頼ボタン74をクリックすることにより当該講師に向けた発信依頼を発行することができる。発信依頼ボタン74をクリックすることに替えて、表示される講師の写真や名前をクリックすることで発信依頼が入力されるようにしても良い。

図１０は、検索結果を基にした講師選択から講義のための通話セッション開始に至る動作シーケンスを示している。

先ず、利用者がＷｅｂブラウザＢに表示される発信依頼ボタンをクリックすることにより、ＷｅｂブラウザＢは電話の発信依頼をＷｅｂサーバ／Ｗｅｂ−ＡＰサーバに向けて送信する（ステップS201）。次に、マッチングＡＰはＷｅｂサーバ／Ｗｅｂ−ＡＰサーバから当該発信依頼を受信する（ステップS202）。次いで、マッチングＡＰは、Ｗｅｂ側シグナリング管理に“発信依頼”を発行する（ステップS203）。Ｗｅｂ側シグナリング管理は、ＳＩＰ側シグナリング管理との間で連携を行うことで、ＳＩＰ側に該“発信依頼”を転送する（ステップS204）。

これに応じて、ＳＩＰ側シグナリング管理は、ＳＩＰ−ＡＰサーバ／ＳＩＰサーバに向けて、電話を繋ぐべき２者の電話番号の検索要求を送信する（ステップS205）。ＳＩＰ−ＡＰサーバ／ＳＩＰサーバは、ＳＩＰ−ＤＢ25に含まれる状態管理ＤＢに検索依頼を送信する（ステップS206）。状態管理ＤＢは当該２者の電話番号を検索し、その検索結果をＳＩＰ−ＡＰサーバ／ＳＩＰサーバに返却する（ステップS207）。

次に、ＳＩＰ−ＡＰサーバ／ＳＩＰサーバは、状態管理ＤＢからの検索結果に基づき、まず、利用者が利用するソフトフォンＡに向けて発信し（ステップS208）、次いで、ソフトフォンＡから応答通知を受信する（ステップS209）。次に、ＳＩＰ−ＡＰサーバ／ＳＩＰサーバは、講師が使用するソフトフォンＢに向けて発信し（ステップS210）、次いで、ソフトフォンＢから応答通知を受信する（ステップS211）。これにより、ソフトフォンＡとソフトフォンＢとの間で双方向通話のための通話セッションが確立される（ステップS212）。これにより、利用者は生徒として講師との間で英会話レッスンのための音声通話を行うことができる。

一方、ＳＩＰ−ＡＰサーバ／ＳＩＰサーバは、ソフトフォンＡとソフトフォンＢとの間のセッション状態を状態管理ＤＢへ登録する（ステップS213）。この後、ステップS214〜S218を経て、該セッション状態はＷｅｂサーバ／Ｗｅｂ−ＡＰサーバにより認識される。

図１１は、講義終了に伴う通話セッション切断から評価結果登録に至る動作シーケンスを示している。ここで、上記した動作シーケンスにより確立された通話セッションを介して英会話レッスンの如き講義が行われ、その後に講義が終了したものとする。

先ず、ＳＩＰ−ＡＰサーバ／ＳＩＰサーバは、利用者が使用するソフトフォンＡから切断通知を受信する（ステップS301）。これに応じて、ＳＩＰ−ＡＰサーバ／ＳＩＰサーバは、ＳＩＰ−ＤＢに含まれる状態管理ＤＢに状態変更を依頼する（ステップS302）。状態管理ＤＢは登録していたセッション状態を切断状態に変更し、変更完了通知をＳＩＰ−ＡＰサーバ／ＳＩＰサーバに向けて発行する（ステップS303）。ＳＩＰ−ＡＰサーバ／ＳＩＰサーバは、状態管理ＤＢの変更結果に基づき、ＳＩＰ側コール管理に“状態変更”の通知を送信する（ステップS304）。ＳＩＰ側コール状態管理は、Ｗｅｂ側コール管理と連携して、Ｗｅｂ側に該“状態変更”を転送する（ステップS305）。

これに応じて、Ｗｅｂ側コール管理は、該“状態変更”をマッチングＡＰに送信する（ステップS306）。これに応じて、マッチングＡＰは、例えば、講師に対する評価アンケート等の表示依頼をＷｅｂ−ＡＰサーバ／Ｗｅｂサーバに要求する（ステップS307）。Ｗｅｂ−ＡＰサーバ／Ｗｅｂサーバは、ＷｅｂブラウザＡの表示を該表示依頼に応じて変更する（ステップS308）。

変更された表示内容に応じて、利用者がＷｅｂブラウザＡに表示された評価アンケートを記入して送信ボタンを押下することにより、ＷｅｂブラウザＡは、Ｗｅｂ−ＡＰサーバ／Ｗｅｂサーバに向けて該評価アンケートに基づく評価結果の登録要求を送信する（ステップS309）。Ｗｅｂ−ＡＰサーバ／ＷｅｂサーバはマッチングＡＰへ該登録要求を発行する（ステップS310）。マッチングＡＰは利用者ＤＢと講師ＤＢに該評価結果の登録要求をなす（ステップS311）。利用者ＤＢと講師ＤＢは、要求された登録を行い登録完了通知をマッチングＡＰに発行する（ステップS312）。

次に、マッチングＡＰは、Ｗｅｂ−ＡＰサーバ／Ｗｅｂサーバに向けて能力判定シート等の表示依頼を要求する（ステップS313）。Ｗｅｂ−ＡＰサーバ／Ｗｅｂサーバは、ＷｅｂブラウザＢの表示を能力判定シート等の表示に変更する（ステップS314）。これに応じて、講師がＷｅｂブラウザＢに表示される能力判定シートに記入して送信ボタンを押下することにより、ＷｅｂブラウザＢは、Ｗｅｂ−ＡＰサーバ／Ｗｅｂサーバに向けて該能力判定シートに基づく評価結果の登録要求を送信する（ステップS315）。Ｗｅｂ−ＡＰサーバ／ＷｅｂサーバはマッチングＡＰへ該登録要求を発行する（ステップS316）。

次に、マッチングＡＰは、その評価結果集計機能により、利用者による講師の評価結果と講師による利用者の評価結果とを、それぞれ様々な方法で集計する（ステップS317）。講師による生徒の評価結果は、例えば、ボキャブラリ、発音、伝達力、交渉力及び流暢さなどの点数から、ある基準をベースにＡ、ＢまたはＣなどの総合評価点をつけることによりなされる。また、生徒による講師の評価結果は、例えば、親しみ易い、楽しかった、態度が悪かった、話題が豊富及び教え方が上手などの点数からある基準をベースにＡ、ＢまたはＣなどの総合評価点を付けることでなされる。さらに、この講師のレッスンは受けたくない場合は、チェックボックスを設けて、この結果が次回の検索条件に反映できるようにしても良い。

次に、マッチングＡＰは、集計された評価結果をＷｅｂブラウザＡに表示するようにＷｅｂ−ＡＰサーバ／Ｗｅｂサーバに依頼する（ステップS318）。Ｗｅｂ−ＡＰサーバ／Ｗｅｂサーバは、生徒の使用するＷｅｂブラウザＡに当該評価結果を表示する（ステップS319）。同様にして、マッチングＡＰは、集計された評価結果をＷｅｂブラウザＢに表示するようＷｅｂ−ＡＰサーバ／Ｗｅｂサーバに依頼する（ステップS320）。Ｗｅｂ−ＡＰサーバ／Ｗｅｂサーバは、講師の使用するＷｅｂブラウザＢに当該評価結果を表示する（ステップS321）。一方、マッチングＡＰは、生徒ＤＢに向けて該評価結果の登録を要求する（ステップS322）。生徒ＤＢは該評価結果を登録して、登録完了通知をマッチングＡＰに発行する（ステップS323）。

登録された生徒や講師の評価結果は、次回の検索における検索条件に反映されると共に講師選択メニューにおける表示情報となる。

以上の実施例において、Ｗｅｂ環境上に構築されるＡＰと、ＳＩＰ環境上に構築されるＡＰとが相互に連携可能となり、ＷｅｂとＶｏＩＰとの融合型ＡＰの構築、実行及び運用が容易に実現される。本発明の適用は多面の利点をもたらす。

第１に、利便性向上としては情報漏洩防止がなされる。３ＰＣＣ（3rd Party Call Control）技術を利用することにより、利用者はＷｅｂ画面をクリックするだけで、講師とインターネット英会話が出来る。講師と利用者はお互いに電話番号を教えあわなくても良いので、両者間のトラブル、個人情報の漏洩を防止できる。

第２に、新サービスの実現として、登録された講師のプレゼンスと講師の情報と利用者の情報やリクエストを照合し、システムが現時点でレッスンが可能な最適な講師一覧を、利用者に対して提示するため、利用者は現時点で自分に合った先生を容易に探す事ができる。

第３に、新サービスの実現として、講義の終了後、講師と利用者がお互いを評価し、その結果がデータベースへ反映される仕組みを自動化することで、利用者が利用すればするほど、マッチングの精度が向上されて自分により合った講師の一覧が表示されるサービスが実現される。

また、講師の評価機能を組み込む事により、講師が自分で設定した講義料に対して生徒が評価を行うことになる。これは講義価格の市場原理を取り入れることになる。つまり、講師が良い講義をすれば、高い講義料でも生徒がつくことになる仕組みになる。例えば、オークション型個人英会話教室が実現できる利点がある。

第４に、生産性向上として、企業競争力が強化される。例えば、日時や時間などの講師と利用者の通信利用状況の情報をＳＩＰサーバで管理できるので、時期や時間に応じた講師の取り揃えや最適雇用人数の推測が可能となり雇用の最適化が実現できる。

以上の実施例では、ＳＩＰ−ＡＰとＷｅｂ−ＡＰの融合方法の例に関して説明したが、本発明を利用することにより、様々な異なるプロトコル間の融合に適用することも可能である。また、本発明を利用することにより、インターネット英会話サービス以外にも、インターネット家庭教師、インターネットピアノ教室など、世界中で特定のスキルをもった人と、それらのスキルを身につけたい人をマッチングして、双方を音声や画像で繋げるといった新しいサービスが実現できる。

本発明の実施例を示し、本発明による対話形式講義支援システムである英会話レッスン提供システムの全体構成を示すブロック図である。 ＳＩＰ環境及びＷｅｂ環境のより詳細の構成を示すブロック図である。 図２に示されたプレゼンス管理のより詳細の構成を示すブロック図である。 図２に示されたシグナリング管理のより詳細の構成を示すブロック図である。 図２に示されたコール管理のより詳細の構成を示すブロック図である。 図２に示されたマッチングＡＰの構成を示すブロック図である。 運用者が設定する優先順位と、生徒が設定する優先順位との関係を説明している説明図である。 生徒ＤＢ、講師ＤＢ及び状態管理ＤＢの内容例を示している図である。 講師選択のための検索依頼から検索結果表示に至る動作シーケンスを示すシーケンス図である。 検索結果を基にした講師選択から講義のための通話セッション開始に至る動作シーケンスを示すシーケンス図である。 講義終了に伴う通話セッション切断から評価結果登録に至る動作シーケンスを示すシーケンス図である。 生徒となる利用者のＷｅｂブラウザに表示される画面表示例を示している図である。

符号の説明

10 英会話レッスン提供システム
20 ＳＩＰ環境
21 ＳＩＰ−ＤＢ
22 ＳＩＰサーバ
24 ＳＩＰ−ＡＰＩ
25 ＳＩＰ−ＡＰ
26 Ｗｅｂアクセッサコンポーネント
30 Ｗｅｂ環境
31 Ｗｅｂ−ＤＢ
32 Ｗｅｂサーバ
33 Ｗｅｂ−ＡＰサーバ
34 Ｗｅｂ−ＡＰI
35 Ｗｅｂ−ＡＰ
36 ＳＩＰアクセッサコンポーネント
40 インターネット
41 ＬＡＮ
51、61 Ｗｅｂブラウザ
52、62 ソフトフォン
261、361 プレゼンス管理
262、362 シグナリング管理
263、363 コール管理
269、369 連携管理
351 マッチングＡＰ

Claims (8)

1. 複数の生徒端末と複数の講師端末との間で双方向通話を可能とすることで、前記端末間でなされる対話形式講義を支援する対話形式講義支援システムであって、
   前記生徒端末に講師選択メニューを配信する講師選択メニュー配信手段と、
   前記生徒端末の１から発せられる講師選択指令に応じて、選択された講師に対応する講師端末と前記生徒端末の１との間に、前記双方向通話のための通話セッションを確立する通話セッション確立手段と、
   を含むことを特徴とする対話形式講義支援システム。
2. 前記講師選択メニュー配信手段は、前記講師端末うちから講義可能な講師に対応する講師端末を抽出し、抽出した講師端末に対応する講師を選択肢とする講師選択メニューを配信することを特徴とする請求項１記載の対話形式講義支援システム。
3. 前記講師選択メニュー配信手段は、前記生徒端末から供給される検索条件に適合する少なくとも１人の講師を検索し、検索した講師を選択肢とする講師選択メニューを配信することを特徴とする請求項１記載の対話形式講義支援システム。
4. 前記講師選択メニュー配信手段は、前記検索条件に適合すると共に予め登録された優先条件に従って少なくとも１人の講師を他に優先して検索することを特徴とする請求項３記載の対話形式講義支援システム。
5. 前記講師端末から供給される生徒評価を生徒毎に集計する生徒評価集計手段と、
   集計された生徒評価により更新される前記講師と前記生徒評価との対応テーブルと、
   を含み、
   前記講師選択メニュー配信手段は、当該生徒端末に対応する生徒に適合する少なくとも１人の講師を前記対応テーブルから検索し、検索した講師を選択肢とする講師選択メニューを配信することを特徴とする請求項１記載の対話形式講義支援システム。
6. 前記生徒端末から供給される講師評価を講師毎に集計する講師評価集計手段と、
   集計された講師評価により更新される前記生徒と前記講師評価との対応テーブルと、
   を含み、
   前記講師選択メニュー配信手段は、当該生徒端末に対応する生徒に適合する少なくとも１人の講師を前記対応テーブルから検索し、検索した講師を選択肢とする講師選択メニューを配信することを特徴とする請求項１記載の対話形式講義支援システム。
7. 前記講師選択メニュー配信手段は、サーバクライアント型の第１通信環境において前記選択メニューを配信し、前記通話セッション確立手段は、前記第１通信環境において供給された講師選択指令に連携して、ピアツゥピア型の第２の通信環境において前記通話セッションを確立することを特徴とする請求項１記載の対話形式講義支援システム。
8. 前記通話セッション確立手段は、前記生徒端末と前記講師端末の双方に発信をなすことで前記通信セッションを確立することを特徴とする請求項１記載の対話形式講義支援システム。

Images