JP2001156931A

JP2001156931A - ブラウザ付き電話機、及びブラウザ付き電話機においてｕｒｌを音声とともに留守録する方法

Info

Publication number: JP2001156931A
Application number: JP32163499A
Authority: JP
Inventors: Michiyoshi Kusuda; 理佳楠田; Yoichi Yoshida; 洋一吉田; Akira Daimon; 昭大門
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1999-11-11
Filing date: 1999-11-11
Publication date: 2001-06-08
Also published as: US7158618B1

Abstract

(57)【要約】（修正有）【課題】ブラウザ付き電話機において、着信側が留守録
状態である場合に、ＵＲＬを音声とともに送付すること
を可能とし、留守録メッセージの再生時には、ＵＲＬ情
報を抽出してブラウザに渡すことを可能とすること。【解決手段】本発明のブラウザ付き電話機は、ウェブ・
ページのＵＲＬを入力する入力手段と、前記入力手段に
よって入力されたＵＲＬを音声メッセージとは区別でき
る形で送信する送信手段と、外部からのＵＲＬ及び関連
する音声メッセージを受信する受信手段と、前記受信手
段が受信したＵＲＬ及び関連する音声メッセージを記録
し再生する留守録手段と、前記留守録手段から再生され
たＵＲＬを文字形式に変換して前記ブラウザに供給する
デコーダ手段と、を具備している。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はブラウザ付き電話機
に関し、特に電話に付属のブラウザで見ているウェブ・
ページのＵＲＬ（Uniform Resource Locator）を留守録
モードにある相手側のブラウザ付き電話機に送る技術に
関する。

【０００２】

【従来の技術】インターネットの爆発的な普及に伴い、
パーソナル・コンピュータがなくても家庭で手軽にアク
セスできることを目的として、スクリーンフォンのよう
なブラウザ付き電話機（多機能電話機）が登場してき
た。スクリーンフォンは、通常の電話機能の他に、ＷＷ
Ｗブラウザや電子メール機能を備えており、１台のスク
リーンフォンで２回線利用できれば、電話をしながら、
インターネットのウェブ・ページにアクセスすることが
できる。ＩＳＲＦ（Internet Screenphone Reference F
orum）が１９９９年６月８日に発表したスクリーンフォ
ンのインターネット接続規格案（"http://www.isrf.or
g"からｐｄｆ形式の仕様書をダウンロードできる）によ
れば、スマート・カードやオンラインのプログラム・ア
ップデートのサポートも予定されており、インターネッ
トのアクセスに限れば、パーソナル・コンピュータと比
べても、機能的にそれほど遜色のないものになってい
る。

【０００３】上述のようなスクリーンフォンが電話の発
呼側および着呼側の両方で使用されていれば、両方で同
じウェブ・ページを見ながら話をするということが考え
られる。その場合、自分が今見ているページのＵＲＬを
どうやって相手に伝えるかが問題である。もちろん言葉
で伝えることは可能であるが、そうすると、相手側はス
クリーンフォンに付属のキーあるいはボタンを使って手
でＵＲＬを入力しなければならず、面倒である。

【０００４】上述のＵＲＬ伝達の問題を解決するため、
相手装置の画面で所望のページを自動的に表示するよう
にしたテレビ電話装置が特開平１１−１２２５９０号公
報に開示されている。これは、一方のテレビ電話装置の
ＷＷＷブラウザを他方のテレビ電話装置のＷＷＷブラウ
ザ表示画面に連動して遷移させるもので、相手装置から
のＨＴＭＬファイルロード指令に対する処理をＷＷＷブ
ラウザタスクに組み込むことで、ＷＷＷブラウザ表示画
面の遠隔制御を実現している。

【０００５】また、電話機とは直接の関係はないが、イ
ンターネットの二人以上の利用者が同時にＨＴＭＬペー
ジの共同作業（いわゆるウェブ・コラボレーション）を
行うことができるようにするシステムおよび方法が特開
平１０−１２４４６１号公報に開示されている。これ
は、基本的に、オリジナルのブラウザ要求をリダイレク
トすることによって、複数のクライアントで同じウェブ
・ページを同時に表示するようにしている。

【０００６】

【発明が解決しようとする課題】スクリーンフォンのよ
うなブラウザ付き電話機では、相手がすぐ電話に出れ
ば、例えば特開平１１−１２２５９０号のようにして、
同じウェブ・ページを両方で同時に見ることができる
が、相手の電話機が留守録モードにあった場合には、Ｕ
ＲＬを伝えることはできない。もちろん、音声メッセー
ジとして留守録に残すことは可能であるが、そうすると
相手側は、留守録に音声で残されているＵＲＬを一旦メ
モ用紙に書き取った後に（周知のように、ＵＲＬは多数
の英数字の羅列からなっているので、頭で覚えるよりも
メモ用紙に書き取った方が確実である）、手でブラウザ
に入力しなければならない。もし通常の音声メッセージ
とともに、それに関連づけて、ＵＲＬを、ブラウザに直
接渡すことができる形で留守録に残すことができれば、
そのような面倒な手続きは不要になる。

【０００７】従って本発明の目的は、ブラウザ付き電話
機において、着信側が留守録状態である場合に、ＵＲＬ
を音声とともに送付することを可能とし、留守録メッセ
ージの再生時には、ＵＲＬ情報を抽出してブラウザに渡
すことを可能とすることにある。

【０００８】

【課題を解決するための手段】上記の目的は請求項１に
記載のブラウザ付き電話機又は請求項７に記載の方法に
より達成される。すなわち、本発明のブラウザ付き電話
機は、ウェブ・ページのＵＲＬを入力する入力手段と、
前記入力手段によって入力されたＵＲＬを音声メッセー
ジとは区別できる形で送信する送信手段と、外部からの
ＵＲＬ及び関連する音声メッセージを受信する受信手段
と、前記受信手段が受信したＵＲＬ及び関連する音声メ
ッセージを記録し再生する留守録手段と、前記留守録手
段から再生されたＵＲＬを文字形式に変換して前記ブラ
ウザに供給するデコーダ手段と、を具備している。

【０００９】また、本発明の方法は、ブラウザによりウ
ェブ・ページを表示できるブラウザ付き電話機において
ウェブ・ページのＵＲＬを音声とともに留守録する方法
であって、ＵＲＬを入力するステップと、前記ＵＲＬを
音声メッセージとは区別できる形で送信するステップ
と、外部からのＵＲＬ及び関連する音声メッセージを受
信するステップと、受信したＵＲＬ及び関連する音声メ
ッセージを記録し再生するステップと、再生したＵＲＬ
を文字形式に変換して前記ブラウザに供給するステップ
と、を含んでいる。

【００１０】相手の電話機に送るＵＲＬは、入力の手間
を考えると、ブラウザで現在表示されているウェブ・ペ
ージから自動的に取り込むようにするのが望ましい。ま
た、相手の電話機がＵＲＬ機能を持っていない場合に
は、ＵＲＬを送信しても仕方がないので、相手の電話機
がＵＲＬ機能を持っているかどうかを予め調べるのが望
ましい。

【００１１】以下、添付図面を参照しながら、本発明の
良好な実施形態について詳しく説明する。

【００１２】

【発明の実施の形態】本発明に従うブラウザ付き電話機
の構成を図１に示す。図１において、ブラウザ付き電話
機１０は、大まかに、従来の電話機が持っている各種機
能を実装した電話系回路部と、ブラウザ機能実現のため
のブラウザ系回路部と、両回路部に共通の回路部とに分
けることができる。電話系回路部は、音声入力用のマイ
ク１２、音声出力用のスピーカ１４、フックスイッチ１
６、留守録用の録音再生部１８、応答部２０、着信制御
部２２、及びアナログ音声回路／トーン生成・認識部２
４を含んでいる。これらの各構成要素は共通のバス２６
に接続される。電話系回路部のこれらの構成要素はいず
れも周知である。トーン・コマンド検知部２８は、留守
録を行う際に、留守録に含まれているトーンで構成され
ているコマンドを検知するものである。詳細については
後で述べるが、ＵＲＬはトーン・コマンド（デリミッ
タ）とそれに伴うデータとして生成される。

【００１３】ブラウザ系回路部は、ウェブ・ブラウザ３
０（パソコンでは、Netscape NavigatorやInternet Exp
lorerが有名であるが、ブラウザ付き電話機の場合、通
常は専用のブラウザを備えている）、液晶ディスプレイ
（ＬＣＤ）などの表示装置３２、２地点間プロトコル
（ＰＰＰ）やハイパー・テキスト転送プロトコル（ＨＴ
ＴＰ）などの各種プロトコルを実装したプロトコル・ス
タック３６、表示装置３２で表示されているウェブ・ペ
ージのＵＲＬの自動取込及び表示を行うＵＲＬ自動取込
・表示部３８、トーン信号形式のＵＲＬを文字形式に変
換するＵＲＬデコーダ４０、それと反対に文字形式のＵ
ＲＬをトーン信号形式に変換するＵＲＬエンコーダ４
２、相手側の電話機がＵＲＬ機能を持っているかどうか
を識別するＵＲＬ機能識別部４４、並びにアナログ音声
回路／トーン生成・認識部２４、トーン・コマンド検知
部２８、ＵＲＬデコーダ４０、ＵＲＬエンコーダ４２、
及びＵＲＬ機能識別部４４に接続され、トーン・コマン
ドの生成及び解析を実行するトーン・コマンド生成・解
析部４６を含んでいる。最後のトーン・コマンド生成・
解析部４６は、上述のトーン・コマンド検知部２８によ
って検知された一連のトーン・コマンドを解析する機能
と、ウェブ・ブラウザ３０上で利用者によって指定され
たＵＲＬを着呼側に送出するためにトーン・コマンドを
生成する機能とを有している。

【００１４】上述の電話系回路部及びブラウザ系回路部
に共通の回路部は、入力装置３４及び通信制御部４８で
ある。入力装置３４は、ＵＲＬ、電話番号及び各種コマ
ンドを入力するためのもので、電話機のボタン、キーボ
ード、マウス、タッチパネル等の任意の形態をとり得
る。通信制御部４８は、外部のネットワークに接続され
て、ウェブ・サイトや相手側電話機との接続の確立、管
理などを実行する。本発明に従いＵＲＬ及び音声を送信
するために通信制御部４８により制御される通信形態と
して、例えば次のようなものが可能である。

【００１５】１．２つの通信回線図２に示すように、ＩＳＤＮ回線５０を利用すれば、ブ
ラウザ用及びアナログ音声用に別々の通信回線を確保す
ることができる。ＩＳＤＮ制御回路５２は周知のもので
よい。ＩＳＤＮ回線の代わりに２つのアナログ回線を利
用しても同様な効果が得られる。

【００１６】２．アナログ回線及びモデム図３に示すように、モデム５４を内蔵し、１つのアナロ
グ回線５６をスイッチ５８でモデム５４又はアナログ音
声回路２４の方に切り換えて使用する。現在のところ、
自宅でインターネットを利用する利用者にとって最も一
般的な通信形態であろう。

【００１７】３．ボイス・データ・モデム図４に示すように、アナログ音声回路２４と電話回線
（例えばＩＳＤＮ回線）との間にボイス・データ・モデ
ム６０を挿入し、このモデム６０に対して音声の開始、
終了を指示して音声と信号を切り換えることによって、
ＵＲＬと音声を切り換えることができる。ボイス・デー
タ・モデム６０として、例えばU.S. Robotics社の56K V
oice Faxmodem External Model#5605を使用することが
できる。

【００１８】４．ＳＶＤモデム図５に示すように、音声とデータを同時に送受信できる
ＳＶＤ（SimultaneousVoice and Data）モデム６２を使
用し、１つの音声回線上にＵＲＬ送受信専用のデータ・
チャネルと、通話用の音声チャネルとを実現することが
できる。ＳＶＤモデム６２として、例えばHayes社のACC
URA 56K External Speakerphone Signature Seriesを使
用することができる。

【００１９】以上の他に、ＩＳＤＮ回線の１つのＢチャ
ネルをＵＲＬエンコーダ４２、ＵＲＬデコーダ４０、及
びプロトコル・スタック３６の間で切り換えて使用する
ことも可能である。このように、本発明のブラウザ付き
電話機は、通信形態に関する限りは任意のものでよい。
ただし、図２及び図３に示す通信形態の場合は、発呼側
及び着呼側の電話機はいずれの通信形態でもよいが、図
４及び図５に示す通信形態の場合は、両方の電話機が同
じ通信形態でなければならない。

【００２０】次に、図６〜図１０のフローチャートを参
照しながら、本発明に従うブラウザ付き電話機の全般的
な動作について説明する。図６〜図８は発呼側のフロー
を示し、図９及び図１０は着呼側のフローを示してい
る。本発明はＵＲＬの留守録に特徴があるので、以下で
は、着呼側の電話機は留守録モードにあるものとする。

【００２１】まず発呼側の電話機において、オフフック
により図６のフローが開始される。最初のステップ１０
０で、着呼側の電話機がＵＲＬ機能を持っていることを
示すＵＲＬ機能検出フラグがクリアされる。このフラグ
については図８のところで説明する。次のステップ１０
１で、電話回線が接続されるまで待つ。接続されると、
ステップ１０２に進んで、発呼電話機の受信側回線を利
用者音声回路（電話機のハンドセットあるいはスピーカ
１４）及びＵＲＬ機能識別部４４に接続し、送信側回線
はＵＲＬ機能識別部４４にのみ接続する（利用者音声回
路には接続しない）。次のステップ１０３で、ＵＲＬ機
能識別部４４から通信制御部４８を介して相手の電話機
にＵＲＬ機能識別要求を送信し、タイマ４５に対してイ
ベントの設定を行う（後で図７を参照して説明する）。
ＵＲＬ機能識別要求はトーン信号の形で送られるが、こ
れはＵＲＬ機能のない電話機から送信され得るいかなる
トーン信号とも同じであってはならない。従って、本実
施形態では、ＵＲＬ機能識別要求は、合計で２．５秒の
次の信号シーケンスで送られる。もちろん、本発明はこ
のシーケンスに限定されるものではなく、他のシーケン
スも可能である。１０００Ｈｚ０．５秒間無音０．５秒間５００Ｈｚ０．５秒間無音０．５秒間１５００Ｈｚ０．５秒間

【００２２】図７のタイマ・イベントから戻ると、ステ
ップ１０４で、送信側回線を利用者音声回路に切り換
え、次のステップ１０５で、着呼側の電話機（前述のよ
うに留守録モードにある）に音声メッセージと、着呼側
の電話機がＵＲＬ機能を持っていた場合（図８のフロー
により検出される）はＵＲＬとを送信する。着呼側の電
話機が留守録モードにあった場合には、一般にステップ
１０３のあたりで、「ただいま留守にしております・・
・」といった不在メッセージが返ってくるので、発呼側
電話機の利用者はそれを聞いてステップ１０５で音声メ
ッセージ及び可能であればＵＲＬを送信することにな
る。この送信信号のシーケンスの一例を図１１に示す。
図示のように、このシーケンスは、マイク１２から入力
された第１の音声メッセージ（例えば、「このＵＲＬを
見て下さい」）、ＵＲＬの始まりを示す第１のデリミッ
タＤ１、利用者が指定したＵＲＬ（例えば、「http://w
ww.ibm.co.jp/」）、ＵＲＬの終わりを示す第２のデリ
ミッタＤ２、及び第２の音声メッセージ（例えば、「そ
れではさようなら」）を含んでいる。ＵＲＬの前後にデ
リミッタＤ１及びＤ２を付けておけば、１つのシーケン
スで複数のＵＲＬを送ることも可能である。図１１のシ
ーケンスは単なる一例であり、本発明はこれに限定され
るものではない。図１１のシーケンスの送信方法の詳細
については後で説明する。

【００２３】図７のタイマ・イベントは、図６のステッ
プ１０３により定期的（例えば１秒ごと）に設定され
る。最初のステップ２００で、ＵＲＬ機能識別要求の送
信後所定の時間ｔ１（例えば３０秒）が経過したかどう
かをチェックする。これは、ＵＲＬ機能識別要求の送信
時刻と現在の時刻との差から判断することができる。ま
だ時間ｔ１が経過していなければ、終了して図６のステ
ップ１０３に戻り、経過しているとステップ２０１に進
む。ステップ２０１では、相手の電話機がＵＲＬ機能を
持っていないことがわかったので、受信側回線とＵＲＬ
機能識別部４４との接続を切る（利用者音声回路との接
続は維持している）。次にステップ２０２でタイマ４５
を停止し、終了する。

【００２４】図６のステップ１０３でＵＲＬ機能識別要
求を送信した後、着呼側の電話機から音声入力がある
と、図８のフローに入る。最初のステップ３００で、音
声入力がＵＲＬ機能識別応答信号かどうかを調べる。本
実施形態では、この応答信号は合計で２．５秒の次の信
号シーケンスから成っている。これも、前述のＵＲＬ機
能識別要求と同じく、他のシーケンスでもよい。５００Ｈｚ０．５秒無音０．５秒１５００Ｈｚ０．５秒無音０．５秒１０００Ｈｚ０．５秒ＵＲＬ機能識別応答信号が検出されると、ステップ３０
１に進んで、ＵＲＬ機能を検出したことを示すフラグが
セットされる。このフラグがセットされると、発呼側電
話機でＵＲＬ送信ボタン（図示せず）がイネーブルさ
れ、ＵＲＬの送信が可能になる。ＵＲＬ送信ボタンは、
電話機１０に取り付けられる専用のハードウェア・ボタ
ン、電話機１０が持っている機能ボタン（「＃」、
「＊」など）と特定の番号のボタンの組み合わせ、表示
装置３２の画面に表示されるソフトウェア・ボタンなど
の任意の形態をとり得る。ステップ３００でＵＲＬ機能
識別応答信号が検出されないか、又はステップ３０１で
ＵＲＬ機能検出フラグがセットされると、図８のフロー
は終了する。

【００２５】次に図９及び図１０を参照しながら、着呼
側電話機の動作について説明する。図９のフローは呼び
出し信号の検出により開始される。最初のステップ４０
０で、ＵＲＬ機能応答フラグをクリアする。このフラグ
は、前の呼び出しで上述のＵＲＬ機能識別応答信号を送
信したときにセットされていたものである（図１０のス
テップ５０１）。次のステップ４０１で、受信側回線を
利用者音声回路及びＵＲＬ機能識別部４４に接続する。
前述のように、着呼側電話機は留守録モードにあるの
で、次のステップ４０２で、送信側回線を不在メッセー
ジ再生用の応答部２０に接続し、ステップ４０３で不在
メッセージを再生して、送信側回線に送り出す。続いて
ステップ４０４で、ＵＲＬ機能応答フラグがセットされ
ているかどうかを調べる。このフラグは最初のステップ
４００でクリアされているので、このときまだ図１０の
ステップ５０１でセットされていなければステップ４０
６に進み、セットされていればステップ４０５に進ん
で、前述のＵＲＬ機能識別応答を送出するとともに、Ｕ
ＲＬ機能検出フラグをセットする。ここでセットされる
ＵＲＬ機能検出フラグは、発呼側及び着呼側で互いに会
話しながらＵＲＬの送受信を行う場合に使用されるもの
で、着呼側が留守録モードにある場合には不要である。
ステップ４０６では、受信側回線を留守録用の録音再生
部１８に接続し、発呼側電話機からの音声メッセージ及
びＵＲＬ（もしあれば）を留守録する。

【００２６】発呼側電話機からの最初の音声入力は、例
えばステップ４０３の実行中に受信される。音声入力受
信が検出されると、図１０のフローが呼び出され、ステ
ップ５００で音声入力がＵＲＬ機能識別要求かどうかを
調べる。ＵＲＬ機能識別要求であれば、ステップ５０１
に進んでＵＲＬ機能応答フラグをセットする。音声入力
がＵＲＬ機能識別要求でない場合、又はＵＲＬ機能応答
フラグがセットされると、図１０のフローは終了する。

【００２７】なお、図６〜図１０の実施形態では、発呼
側からのＵＲＬ機能識別要求を送信し、着呼側がそれを
検出してＵＲＬ機能識別応答を発呼側に返すようになっ
ているが、ＵＲＬ機能識別に関しては着呼側に主導権を
持たせるようにしてもよい。その場合、図６〜図１０に
おいて、ＵＲＬ機能識別要求及びＵＲＬ機能識別応答に
関するステップが発呼側と着呼側で逆になる。発呼側は
通常の発呼を行うだけで、たとえＵＲＬ機能を持ってい
たとしてもＵＲＬ機能識別要求は送信しない。着呼側
は、発呼に応答して、図６のステップ１０３と同様のス
テップによりＵＲＬ機能識別要求を発呼側に送り、タイ
マ・イベントを設定する（図７のフローは着呼側で実行
される）。発呼側は、図１０と同様のフローによりＵＲ
Ｌ機能識別要求を検出して、図９のステップ４０５と同
様のステップによりＵＲＬ識別応答を着呼側に返す。こ
れで、発呼側は音声メッセージに加えてＵＲＬを送信で
きるようになる。

【００２８】次に、本発明の主題であるＵＲＬの留守録
についてもう少し詳しく説明する。前述のように、発呼
側電話機の利用者は、不在メッセージを受け取ったとき
に、相手に伝えたい音声メッセージをマイク１２から入
力し、更にＵＲＬを入力装置３４又はＵＲＬ自動取込・
表示部３８から入力する。入力ミスの防止及び入力の負
担軽減という点では、ブラウザ３０で現在表示している
ウェブ・ページのＵＲＬをＵＲＬ自動取込・表示部３８
で自動的に取り込んで送信するのが好ましい。図２の通
信形態のように２回線が利用可能である場合には、１回
線でインターネットに接続中に、他の回線で電話をかけ
て、本発明の機能を使用することが可能である。さら
に、望ましい実施の形態では、ブラウザ３０にはキャッ
シュ機能が装備されており、回線の切断された直後であ
れば、回線を再度接続することなく、ページ内容とその
ＵＲＬを表示することができる。このようなブラウザ機
能は、既知の技術であり、例えば、Internet Explorer
4.0で実現されている。従って、ブラウザ部で表示して
いるＵＲＬを送信するとしても、ブラウザ部がオンライ
ン表示である必要はないため、１回線のみにおいても実
施可能である。ただし、キャッシュが無い場合でも、特
定のＵＲＬを表示した状態で回線を切断して音声電話に
切り換え、表示しているＵＲＬを送信することは可能で
あるため、ブラウザ部のキャッシュは本発明の必須要件
ではない。

【００２９】入力装置３４からＵＲＬを入力する場合
は、キーボードからの直接入力か、現在携帯電話で使用
されているような番号ボタンに複数の文字を割り当てて
おき、押した回数で文字を決定する方法を使用する。ま
た、好ましい実施の形態では入力中に電話料金が課金さ
れることを防ぐため通話開始前に入力しておく機能も提
供される。例えばブラウザに入っているＵＲＬを使用す
ることができる。なお、ブラウザで特定のページを表示
した後にブラウザの通信を終了して、音声電話として使
用することも可能であるため、電話回線が一つの場合で
も実施可能である。

【００３０】利用者によってＵＲＬの送信が指定される
と、入力装置３４から入力されたＵＲＬ又はＵＲＬ自動
取込・表示部３８により自動的に取り込まれたＵＲＬが
ＵＲＬエンコーダ４２に渡される。図２又は図３の通信
形態の場合、ＵＲＬエンコーダ４２は、ノイズによるＵ
ＲＬの字化けを防ぐためにマイク１２からアナログ音声
回路２４への入力を一時的に中止し、予め定められたＵ
ＲＬ開始を示すトーン信号（デリミッタＤ１）を発生し
た後、ＵＲＬをエンコードした結果の信号をアナログ音
声回路２４へ送付する。ＵＲＬ送信の間は、このエンコ
ード結果のトーンをスピーカ１４またはハンドセットか
ら出力し、マイク１２による音声が送信できないことを
示す。利用者はＵＲＬ送信の間は、エンコード結果で
はなく、無音状態、あるいは予め選択した音楽を聞くよ
うに設定することも可能である。ＵＲＬ送信が終了する
と、ＵＲＬエンコードの終了を示すトーン信号（デリミ
ッタＤ２）を発生した後、マイク１２からアナログ音声
回路２４への入力を復活させる。

【００３１】図４の通信形態では、ＵＲＬと音声の切り
換えは、アナログ音声回路２４と電話回線の間に挿入さ
れているボイス・データ・モデム６０に対して音声の開
始、終了を指示して音声と信号を切り換えることによっ
て行う。図５の通信形態では、ＵＲＬと音声を同時に送
信することが可能であり、ＵＲＬの送信中も音声を送信
できる。

【００３２】着呼側電話機が留守録モードにある場合に
は、着信制御部２２が電話線の状態を監視しており、着
信があると着信トーンをスピーカ１４から流し、一定時
間にハンドセットを持ち上げるといったオフフック操作
が行われない場合に、留守録を開始する。留守録の開始
時には、まず応答部２０を利用して不在であることを示
すメッセージを送信する（図９のステップ４０３）。次
に、ＵＲＬ機能識別部４４によりＵＲＬ機能があること
を通知し（図９のステップ４０５）、それによってＵＲ
Ｌ送受信が可能であることを示す。その後、録音再生部
１８を利用して、アナログ音声回路２４の出力を録音す
る。ただし、この留守録における利用では、送信側にＵ
ＲＬ送信機能があることを認識することは必須ではな
く、受信側にＵＲＬ受信機能があることを通知し、ＵＲ
Ｌが送信されてくればこれを受け取るという形態も可能
である。

【００３３】なお、図２及び図３の通信形態では、アナ
ログ音声回路２４の出力は常にＵＲＬデコーダ４０にも
送られ、ＵＲＬ開始トーン及びＵＲＬ終了トーンを検知
してＵＲＬを取得して、文字情報とし、録音再生部１８
が使用するメモリ（図示せず）に合わせて記録する。音
声情報にはＵＲＬ開始トーンは記録され、ＵＲＬ自体及
びＵＲＬ終了トーンは記録されない。これにより、留守
録件数の表示にＵＲＬの有無や件数も表示することが可
能になる。なお、望ましい実施の形態では、ＵＲＬ受信
中は、スピーカ１４への出力を中断するかどうかを利用
者が選択することができる。

【００３４】ここで述べた実施形態では、ＵＲＬ情報自
体は文字として記録しているが、ＵＲＬデコーダ４０は
ＵＲＬ信号の有無の検出と、必要に応じたスピーカ１４
への出力の中断のみを行い、ＵＲＬ自体は音声情報（ト
ーン信号）として記録しておくことも可能である。

【００３５】図４の通信形態では、アナログ音声回路２
４と電話回線の間にボイス・データ・モデム６０が存在
し、発呼側でモデム６０に対して音声の開始、終了を指
示して音声と信号を切り替える。この場合ＵＲＬ情報は
文字として記録し、さらに切り替えのタイミングでＵＲ
Ｌ再生タイミングトーンを発生して音声の一部として記
録しておくことが可能である。図５の通信形態では、デ
ータと音声は同時に受信可能であるため、データとして
受信したＵＲＬを録音した会話と関連して記録する。

【００３６】留守番電話の利用者が帰宅して留守録メッ
セージがあることを知ると、入力装置３４から再生を指
示する。それに応答して録音再生部１８は、録音してお
いたメッセージを再生する。図１１に示すように、メッ
セージにＵＲＬが含まれていた場合には、その再生時
に、ＵＲＬの存在が表示される。また、図２〜図４の通
信形態ではＵＲＬ開始トーンをメッセージに含めること
が可能であるので、ＵＲＬデコーダ４０はそのタイミン
グでＵＲＬをメモリから取得して、ＵＲＬを表示装置３
２に表示し、合わせてメッセージの再生を一時中断す
る。利用者が、ＵＲＬの表示を指示すると、ブラウザ３
０が起動されていない場合にはＵＲＬを指定してブラウ
ザ３０を起動する。利用者が再生の継続を指示すると、
ＵＲＬの表示は維持したままで、メッセージの再生を再
開する。利用者がＵＲＬの破棄を指示すると、ＵＲＬの
表示はクリアされる。なお、メッセージの再生後にＵＲ
Ｌの表示を指示することも可能である。

【００３７】図５の通信形態では、ＵＲＬと音声とのタ
イミング同期は行わず、留守録メッセージの再生開始と
同時にＵＲＬが表示され、ブラウザ３０を起動するか、
ＵＲＬを破棄するか、次のＵＲＬを表示するかを選択す
る。ＵＲＬを破棄しなかった場合には、留守録メッセー
ジの再生後にＵＲＬの表示を指示することも可能であ
る。

【００３８】なお、留守録メッセージの再生中には電話
回線は使用していないため、メッセージの再生中でもブ
ラウザは使用可能であり、電話回線が一回線でも、実施
可能である。また、図２及び図３の通信形態でＵＲＬ情
報をトーン信号として記録している場合には、メッセー
ジの再生中にＵＲＬ開始トーンを検出してスピーカ出力
の中断とＵＲＬ取得の開始を行い、ＵＲＬ取得後にスピ
ーカ出力を再開することも可能である。

【００３９】留守録ではない通常の音声通話において
も、ＵＲＬ送受信機能の検出によって、通話している双
方で、相手側にＵＲＬの送受信機能があることが分か
る。この検出結果に基づいて、留守録ではない、通常の
音声通話状態でも、ＵＲＬの送受信機能の使用の可否を
表示することが可能である。さらに、ＵＲＬ送受信機能
が使用可能である場合には、通話中にＵＲＬ送信ボタン
を押すと、留守録時と同様の方式によってＵＲＬを送信
し、留守録時と同様の方式によってＵＲＬを受信し、受
信側では、ＵＲＬを受信した時点でブラウザ３０が起動
していない場合に、これを起動し、受信したＵＲＬを表
示することが可能である。また、受信したＵＲＬを保管
しておき、音声通話回線の切断後にブラウザ３０を起動
して受信したＵＲＬを閲覧することによって、一回線で
のＵＲＬの伝達も可能である。

【００４０】音声認識機能を電話機１０に内蔵すること
により、発信側は通常の電話機を使用することも可能で
ある。留守録の場合には、不在メッセージの一部でＵＲ
Ｌ音声認識機能があることと識別開始キーワードを通知
し、通常会話の場合には、着信側利用者が会話中にＵＲ
Ｌ音声認識機能があること、あるいはＵＲＬ音声認識機
能があることと識別開始キーワードの両方を通知する。
着信側では、受信した音声は常に音声認識機能にも送ら
れ、キーワードを検出する。なお、ここでキーワードと
は、「ゆーあーるえるかいし」といった実際のキーワー
ドまたは、電話ボタンの操作によって発生するトーンの
特定の組み合わせといった識別に利用できる音全般を含
む概念である。

【００４１】発信者がキーワードを使用すると、音声識
別モードに入り、発信者はＵＲＬを発音することで受信
側にＵＲＬを伝えることが可能である。留守録の場合に
は、ＵＲＬの開始キーワードを受領すると一時的に音声
の録音を中断する。ＵＲＬの終了を示すキーワードの受
信後に発信側のボタン操作（例えば、「１」で終了、
「２」で確認）によって受信側がＵＲＬを読み上げて確
認することができる。確認した場合、あるいは確認を省
略した場合には、ＵＲＬは文字データとして録音と関連
づけて保管され、音声の録音が再開される。確認結果が
誤っていた場合には、発信者はボタン操作によってＵＲ
Ｌをキャンセルし、再度発声するか、中止するかを選択
できる。留守録メッセージの再生時には、音声メッセー
ジ毎に対応するＵＲＬの数が表示または読み上げられ、
利用者は（１）順次表示、（２）ＵＲＬを一覧してその
中から選択表示、（３）すべて廃棄の操作を選択でき
る。

【００４２】留守録でない場合にも同様の手順でＵＲＬ
を受信することができるが、ＵＲＬ受信側利用者の操作
によって音声認識モードに入ることも可能である。ま
た、確認結果もＵＲＬ受信側電話機に表示し、利用者が
確認することも可能である。電話線を経由した音声の認
識は、IBM ViaVoice Speech Recognitionのように、既
存の技術であり、文字データの音声への変換も、IBM Di
rect Talkのように、既存の技術である。

【００４３】以上、本発明の良好な実施形態について説
明してきたが、本発明はそれに限られるものではなく、
様々な修正、変更が可能であることは当業者であれば明
らかであろう。

【図面の簡単な説明】

【図１】本発明に従うブラウザ付き電話機の構成を示す
ブロック図。

【図２】本発明のブラウザ付き電話機が使用し得る第１
の通信形態を示す図。

【図３】本発明のブラウザ付き電話機が使用し得る第２
の通信形態を示す図。

【図４】本発明のブラウザ付き電話機が使用し得る第３
の通信形態を示す図。

【図５】本発明のブラウザ付き電話機が使用し得る第４
の通信形態を示す図。

【図６】発呼側電話機の動作を示すフローチャート。

【図７】図６のフローから呼び出されるタイマ・イベン
ト示すフローチャート。

【図８】発呼側電話機に音声入力があった場合の動作を
示すフローチャート。

【図９】留守録モードにある着呼側電話機の動作を示す
フローチャート。

【図１０】着呼側電話機に音声入力があった場合の動作
を示すフローチャート。

【図１１】発呼側電話機から着呼側電話機に送られる留
守録用のメッセージ・シーケンスを示す図。

【符号の説明】

１０ブラウザ付き電話機１２マイク１４スピーカ１６フックスイッチ１８録音再生部２０応答部２２着信制御部２４アナログ音声回路／トーン生成・認識部２８トーン・コマンド検知部３０ウェブ・ブラウザ３２表示装置３４入力装置３６プロトコル・スタック３８ＵＲＬ自動取込・表示部４０ＵＲＬデコーダ４２ＵＲＬエンコーダ４４ＵＲＬ機能識別部４６トーン・コマンド生成・解析部４８通信制御部

フロントページの続き (72)発明者吉田洋一神奈川県大和市下鶴間1623番地14 日本アイ・ビー・エム株式会社大和事業所内 (72)発明者大門昭神奈川県大和市下鶴間1623番地14 日本アイ・ビー・エム株式会社大和事業所内Ｆターム(参考） 5B089 GA26 GB04 HA02 HA03 JB05 JB14 KA01 KA04 KB07 KC59 KH14 LB13 LB25 5K101 KK02 KK06 LL03 NN01 NN17 UU03

Claims

【特許請求の範囲】

【請求項１】ブラウザによりウェブ・ページを表示でき
る電話機であって、ウェブ・ページのＵＲＬを入力する入力手段と、前記入力手段によって入力されたＵＲＬを音声メッセー
ジとは区別できる形で送信する送信手段と、外部からのＵＲＬ及び関連する音声メッセージを受信す
る受信手段と、前記受信手段が受信したＵＲＬ及び関連する音声メッセ
ージを記録し再生する留守録手段と、前記留守録手段から再生されたＵＲＬを文字形式に変換
して前記ブラウザに供給するデコーダ手段と、を含むブラウザ付き電話機。
【請求項２】前記入力手段が、表示中のウェブ・ページ
のＵＲＬを自動的に取り込んで、前記送信手段に送る、
請求項１に記載のブラウザ付き電話機。
【請求項３】前記入力手段により入力された文字形式の
ＵＲＬをトーン信号形式に変換するＵＲＬエンコーダを
更に含み、前記デコーダ手段が前記受信手段により受信
されたトーン信号形式のＵＲＬを文字形式に変換する、
請求項１又は請求項２に記載のブラウザ付き電話機。
【請求項４】相手の電話機がＵＲＬ機能を持っているか
どうかを検査するためのＵＲＬ機能識別部を更に含む、
請求項１乃至請求項３のいずれかに記載のブラウザ付き
電話機。
【請求項５】前記ＵＲＬ機能識別部は、発呼時にＵＲＬ
機能識別要求を送信し、着呼時に相手からのＵＲＬ機能
識別要求に対してＵＲＬ機能識別応答を返す、請求項４
に記載のブラウザ付き電話機。
【請求項６】前記ＵＲＬ機能識別部は、着呼時にＵＲＬ
機能識別要求を発呼側に送信し、着呼側からのＵＲＬ機
能識別要求に対してＵＲＬ機能識別応答を着呼側に返
す、請求項４に記載のブラウザ付き電話機。
【請求項７】前記送信手段は、前記ＵＲＬの前後にデリ
ミッタを付けて音声メッセージと共に送信する、請求項
１乃至請求項６のいずれかに記載のブラウザ付き電話
機。
【請求項８】ブラウザによりウェブ・ページを表示でき
るブラウザ付き電話機においてウェブ・ページのＵＲＬ
を音声とともに留守録する方法であって、ＵＲＬを入力するステップと、前記ＵＲＬを音声メッセージとは区別できる形で送信す
るステップと、外部からのＵＲＬ及び関連する音声メッセージを受信す
るステップと、受信したＵＲＬ及び関連する音声メッセージを記録し再
生するステップと、再生したＵＲＬを文字形式に変換して前記ブラウザに供
給するステップと、を含む方法。
【請求項９】前記ＵＲＬを入力するステップが、表示中
のウェブ・ページのＵＲＬを自動的に取り込む、請求項
８に記載の方法。
【請求項１０】入力された文字形式のＵＲＬをトーン信
号形式に変換するステップを更に含み、前記再生したＵ
ＲＬを文字形式に変換して前記ブラウザに供給するステ
ップが、前記受信したＵＲＬをトーン信号形式から文字
形式に変換する、請求項８又は請求項９に記載の方法。
【請求項１１】相手の電話機がＵＲＬ機能を持っている
かどうかを検査するためのステップを更に含む、請求項
８乃至請求項１０のいずれかに記載の方法。
【請求項１２】前記検査するためのステップは、発呼時
にＵＲＬ機能識別要求を送信し、着呼時に相手からのＵ
ＲＬ機能識別要求に対してＵＲＬ機能識別応答を返す、
請求項１１に記載の方法。
【請求項１３】前記検査するためのステップは、着呼時
にＵＲＬ機能識別要求を発呼側に送信し、着呼側からの
ＵＲＬ機能識別要求に対してＵＲＬ機能識別応答を着呼
側に返す、請求項１１に記載の方法。
【請求項１４】前記送信するステップは、前記ＵＲＬの
前後にデリミッタを付けて音声メッセージと共に送信す
る、請求項８乃至請求項１３のいずれかに記載の方法。