JP2010191812A - 携帯電話端末及び通信方法 - Google Patents

Abstract

【課題】メッセージの送信を通して、予約要求及び予約のスケジュール帳への登録を行えるようにする。
【解決手段】他の端末との間で無線通信によるデータの送受信を行う通信処理部１０１と、スケジュール帳への、スケジュール情報の登録又は読み出しを行うスケジュール機能部１２０とを備えた。また、無線通信を行う通信相手の宛先情報と、スケジュール帳に登録させたいスケジュール情報を含んだ予約要求を生成して、予約要求を通信処理部１０１に出力するメッセージ生成部１３１と、通信処理部１０１を介して受信した予約要求の中からスケジュール情報を抽出するメッセージ解析部１３３とを備えた。その上で、ユーザより予約要求を承諾する指示が入力された場合に、メッセージ解析部１３３で抽出されたスケジュール情報を、スケジュール機能部１２０に出力してスケジュール情報をスケジュール帳に登録させるようにした。
【選択図】図２

Description

本発明は、携帯電話端末及び通信方法に関し、特に、メッセージの送受信によってスケジュールの予約又は登録を行う技術に関する。

従来、仕事上の関係者や友人に対する面会や会合などの約束は、電話や電子メール等を通して行われてきた。ところが、約束の予約を電話で行う場合には、予約を取りたい相手との電話が繋がらない限り、予定を確定できないという問題があった。つまり、約束を取りたい相手が多忙の場合などには相手との電話がなかなか繋がらないため、予定を決定することができなかった。またこのとき、予約の電話を受ける側においては多くの着信履歴が残る結果となり、そのことが電話を着信した人を苛立たせてしまう場合もあった。

仮に電話が繋がって予約を確定できたとしても、予約を受けた相手は、携帯電話端末内のスケジュール表、もしくはカレンダ等にマニュアルで予定を記入する必要があり、手間がかかるという問題もあった。この手間は、電子メールを通して約束の依頼が送信されてきた場合にも同様に発生する。このため、例えば特許文献１には、電子メール中に記載された予定情報を、スケジュール帳に自動的に登録する技術が記載されている。

特開２００６−５３７０５号公報

ところで、特許文献１に記載された技術を用いれば、電子メールに記載された予定情報を、ユーザがスケジュール帳に記入する手間を省くことができる。しかし、特許文献１に記載の手法では、予定情報のスケジュール帳への登録が自動的に行われるため、スケジュール帳に登録したくない予定情報も登録されてしまうという問題があった。

本発明はかかる点に鑑みてなされたものであり、予約要求側においてはメッセージの送信を通して予約要求を行うことができるようにするとともに、予約要求受信側においては、スケジュール帳への登録を行いたいスケジュール情報のみを、容易な操作で登録できるようにすることを目的とする。

本発明は、他の端末との間で無線通信によるデータの送受信を行う通信処理部と、ユーザのスケジュール情報を登録するスケジュール帳への、スケジュール情報の登録又は読み出しを行うスケジュール機能部とを備えた。また、無線通信を行う通信相手の宛先情報と、スケジュール帳に登録させたいスケジュール情報を含んだ予約要求を生成して、予約要求を通信処理部に出力するメッセージ生成部と、通信処理部を介して受信した予約要求の中からスケジュール情報を抽出するメッセージ解析部とを備えた。その上で、ユーザより予約要求を承諾する指示が入力された場合に、メッセージ解析部で抽出されたスケジュール情報を、スケジュール機能部に出力してスケジュール情報をスケジュール帳に登録させる制御を行うようにしたものである。

このようにしたことで、ＳＭＳ（Short Message Service）又はＭＭＳ（Multimedia Messaging Service）等のメッセージサービスによって予約要求が相手に送信され、予約要求の承認をトリガとして、予約がスケジュール帳に自動的に反映されるようになる。

本発明によると、予約要求側においてはメッセージの送信を通して予約要求を行うことができるようになり、予約要求受信側においては、スケジュール帳への登録を行いたいスケジュール情報のみを、容易な操作で登録できるようになる。

本発明の一実施の形態による携帯電話端末の内部構成例を示すブロック図である。 本発明の一実施の形態によるメッセージサービス処理部の構成例を示すブロック図である。 本発明の一実施の形態によるメッセージサービス処理部での処理の例を示すフローチャートである。 本発明の一実施の形態による予約要求作成画面の構成例（１）を示す説明図である。 本発明の一実施の形態による予約要求作成画面の構成例（２）を示す説明図である。 本発明の一実施の形態による予約要求の記述例を示す説明図である。 本発明の一実施の形態による日付フォーマットを記述したルックアップテーブルの構成例を示す説明図である。 本発明の一実施の形態による時刻フォーマットを記述したルックアップテーブルの構成例を示す説明図である。 本発明の一実施の形態による予約要求の受信画面の構成例（１）を示す説明図である。 本発明の一実施の形態によるポップアップ画面表示の際の処理の例を示す説明図である。 本発明の一実施の形態による予約要求受信画面の構成例（２）を示す説明図である。 本発明の一実施の形態によるスケジュール帳の構成例を示す説明図である。 本発明の一実施の形態による予約要求応答の記述例を示す説明図である。 本発明の一実施の形態による予約要求応答通知の画面表示例（１）及び（２）を示す説明図である。 本発明の一実施の形態によるスケジュール帳の構成例を示す説明図である。 本発明の他の実施例による予約要求作成画面の構成例を示す説明図である。 本発明の他の実施例による日時入力画面の構成例を示す説明図である。

以下、本発明の一実施の形態を、添付図面を参照して説明する。本実施の形態においては、本発明の通信端末を、ＳＭＳ又はＭＭＳを利用可能な携帯電話端末に適用している。そして本例では、ＳＭＳやＭＭＳ等のメッセージサービスを用いて、約束の予約を要求する予約要求や、予約要求に対する応答である予約要求応答を送受信するものである。予約要求を受信した受信者（以下、予約要求受信者と称する）によって予約要求が承諾されると、予約要求受信者と、予約要求送信者の携帯電話端末内のスケジュール帳に、予約要求に記載されたスケジュール（予定）が自動的に登録される。

本実施の形態は、以下の順序で説明する。なお、本例ではＳＭＳとＭＭＳを利用可能な場合を例に挙げるが、ＥＭＳ（Enhanced Messaging Service）等の他のメッセージサービスを利用する形態に適用してもよい。
１．携帯電話端末の構成例
２．携帯電話端末の動作例
３．実施の形態の効果
４．変形例

［１．携帯電話端末の構成例］
以下に説明する携帯電話端末の構成は、予約要求送信者側と予約要求受信者側の両方において、共通するものである。

本実施の形態の携帯電話端末１００は、マイクロプロセッサ等よりなる制御部１１０を備え、制御部１１０は、制御信号が伝送される制御ライン１５０又はデータが伝送されるデータライン１６０を介して、携帯電話端末１００内の各部と接続されている。そして制御部１１０は、これらのラインを通して各部と通信を行い、各部の動作制御を行う。

また携帯電話端末１００は、通信端末として必要な無線通信処理を行う無線電話用の通信処理部１０１を備え、通信処理部１０１にはアンテナ１０２が接続されている。この通信処理部１０１が、無線電話用の基地局と無線通信を行って、基地局との間で、双方向のデータ伝送を行う。通信処理部１０１は、基地局側から受信したデータを、データライン１６０を介して端末内の各部に送出する。また、端末内の各部からデータライン１６０を介して伝送されたデータを、基地局側に送信させる。

データライン１６０には、通信処理部１０１の他に、表示部１０３と操作部１０４とメモリ１０５とが接続されている。表示部１０３は、液晶表示ディスプレイや有機ＥＬディスプレイなどが表示手段として使用され、制御部１１０による制御に基づいて、各種情報の表示を行う。表示部１０３に表示される各種情報には、ＳＭＳやＭＭＳによって送受信されるメッセージや、予約要求、予約要求に対する応答である予約要求応答等が含まれる。

操作部１０４は、携帯電話端末として必要な数字や記号などのダイヤルキー、各種機能キーなどで構成される。これらの操作部１０４を構成する各キーの操作情報は、制御部１１０に供給される。各種設定操作を行う際には、例えば表示部１０３で操作を案内する表示を行い、その表示に従ってユーザは操作部１０４で操作を行って、該当する設定が行われる。メモリ１０５は、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）で構成され、本実施の形態の端末を動作させるために必要なプログラムや、ユーザが記憶させた各種データなどを記憶する。

またデータライン１６０には、音声処理部１０６とスケジュール機能部１２０とメッセージサービス処理部１３０も接続されている。音声処理部１０６は、音声信号の処理を行う処理部であり、スピーカ１０７及びマイクロフォン１０８が接続してある。このスピーカ１０７及びマイクロフォン１０８は、通話時に受話器として使用されるものである。即ち、通信処理部１０１から音声処理部１０６に供給される音声データを、音声処理部１０６で復調してアナログ音声信号とし、増幅などのアナログ処理を行ってスピーカ１０７から放音させる。また、マイクロフォン１０８が集音した音声信号を、音声処理部１０６でデジタル音声データに変調し、その変調された音声データを通信処理部１０１に供給して、無線送信などを行う。

スケジュール機能部１２０は、ユーザのスケジュール情報を日付や時間、場所などの情報により管理するスケジュール帳（図示略）を有し、スケジュール帳へのスケジュール情報の書き込み又は読み出しの制御を行う。なお、スケジュール帳におけるスケジュール情報の管理形態は、日単位でも週単位でも、月単位でもよいものとする。

メッセージサービス処理部１３０は、ＳＭＳやＭＭＳにより他の通信端末とやりとりされるメッセージを作成したり、受信したメッセージを蓄積する処理を行う。ここでいうメッセージには、通常のメッセージだけでなく、本例による予約要求や予約要求応答も含まれる。また、メッセージサービス処理部１３０は、メッセージ予約要求を受信した場合で、ユーザにより予約要求を承諾する指示が入力された場合や、予約を承諾する旨が記載された予約要求応答を受信した場合に、スケジュール機能部１２０を起動させる処理も行う。そして、スケジュール機能部１２０の起動後に、予約要求又は予約要求応答に含まれるスケジュール情報を、スケジュール機能部１２０内のスケジュール帳に書き込ませる制御を行う。メッセージサービス処理部１３０の詳細については、次の図２を参照して後述する。

なお、本例ではスケジュール帳をスケジュール機能部１２０内に設ける構成としてあるが、スケジュール帳をメモリ１０５等に記憶させるようにしてもよい。

次に、メッセージサービス処理部１３０の詳細について、図２のブロック図を参照して説明する。図２において、データの流れは実線で示し、制御信号の流れは破線で示している。メッセージサービス処理部１３０には、メッセージ生成部１３１と、メッセージ蓄積・削除制御部１３２と、メッセージ解析部１３３と、メッセージ表示処理部１３４と、メッセージ蓄積部１３５と、スケジュール連携部１３６とが含まれる。

メッセージ生成部１３１は、操作部１０４への操作入力に基づき制御部１１０で行われる制御に基づいて、通常のメッセージ又は予約要求、予約要求応答を生成する。予約要求又は予約要求応答は、ＸＭＬ（Extensible Markup Language）等のマークアップ言語で記述されるものであり、予約要求又は予約要求応答の記述例については後述する。メッセージ生成部１３１は、予約要求又は予約要求応答を生成した場合には、それらの情報をメッセージ蓄積・削除制御部１３２にも出力する。

メッセージ蓄積・削除制御部１３２は、入力されたメッセージを、メッセージ蓄積部１３５に蓄積あるいは削除する制御を行う。メッセージ蓄積・削除制御部１３２によるメッセージの蓄積又は削除の処理は、操作部１０４から入力される操作情報に従って制御部１１０で行われる制御に基づいて行われる。

メッセージ解析部１３３は、通信処理部１０１を通して受信したメッセージを解析し、メッセージが通常のメッセージであった場合には、メッセージのデータをメッセージ表示処理部１３４及びメッセージ蓄積部１３５にそのまま出力する。受信したメッセージが予約要求又は予約要求応答であった場合には、予約要求又は予約要求応答から、スケジュール情報や送信者又は受信者の情報を抽出して、メッセージ表示処理部１３４及びメッセージ蓄積・削除制御部１３２に出力する。

メッセージ表示処理部１３４は、メッセージ解析部１３３から供給されるメッセージの内容を表示部１０３に表示するための画面を生成して、表示部１０３に出力する。本例では、メッセージ表示処理部１３４は、通信処理部１０１で得られたメッセージが予約要求又は予約要求応答であった場合には、メッセージが予約要求又は予約要求応答であることを示す通知用の画面を作成して表示部１０３に出力することも行う。

メッセージ蓄積部１３５は、メッセージ解析部１３３から供給されたメッセージ又は、メッセージ蓄積・削除制御部１３２から供給されたメッセージを蓄積する。スケジュール連携部１３６は、操作部１０４から入力される操作情報に従って行われる制御部１１０による制御に基づいて、スケジュール機能部１２０を起動させ、メッセージ蓄積部１３５に蓄積されたスケジュール情報をスケジュール機能部１２０に供給する。そして、スケジュール機能部１２０内のスケジュール帳に、読み出したスケジュール情報を登録させる制御を行う。

［２．携帯電話端末の動作例］
次に、予約要求送信者から予約要求が送信されてから、予約要求受信者及び／又は予約要求受信者におけるスケジュール帳にスケジュール情報が登録されるまでの処理の例について、図３のフローチャートを参照して説明する。図３に示す各処理を行う各ブロックの符号は、図１又は図２に示したものと対応している。

まず、予約要求送信者が所有する携帯電話端末１００において、メッセージ生成部１３１で予約要求が生成されると（ステップＳ１）、生成された予約要求が、通信処理部１０１によって予約要求受信者側に送信される（ステップＳ２）。予約要求受信者側では、予約要求を受信すると（ステップＳ３）、メッセージ表示処理部１３４によって、受信した予約要求が表示部１０３上に表示される（ステップＳ４）。

そして、ユーザ（予約要求受信者）によってその予約が承諾されたか否かの判断がされる（ステップＳ５）。予約要求が承諾された場合には、スケジュール連携部１３６によってスケジュール機能部１２０が起動され、予約要求に含まれるスケジュール情報が、スケジュール機能部１２０内のスケジュール帳に記録される（ステップＳ６）。一方、予約要求が拒絶された場合には、予約要求に含まれるスケジュール情報は、メッセージ蓄積・削除制御部１３２によって削除される（ステップＳ７）。

続いて、予約要求が承諾又は拒絶されたことを示す予約要求応答が、予約要求受信者側のメッセージ生成部１３１によって生成され、通信処理部１０１によって、予約要求送信者側に送信される（ステップＳ８）。

予約要求送信側では、予約要求応答を受信すると（ステップＳ９）、予約要求応答の内容が表示部１０３の画面上に表示されるとともに（ステップＳ１０）、予約が受け付けられたか否かが判断される（ステップＳ１１）。すなわち、予約要求応答が、予約要求が承諾されたことを示すものであったのか、あるいは拒絶されたことを示すものであったのかが判断される。

予約要求が承諾された場合には、スケジュール連携部１３６によってスケジュール機能部１２０が起動され、予約要求に含まれるスケジュール情報が、スケジュール機能部１２０内のスケジュール帳に記録される（ステップＳ１２）。一方、予約要求が拒絶された場合には、予約要求に含まれるスケジュール情報は、メッセージ蓄積・削除制御部１３２によって削除される（ステップＳ１３）。

次に、上述した各処理のより具体的な例について、図４〜図１４を参照して説明する。 図４は、図３のステップＳ１で予約要求が生成される場合の、予約要求作成画面の例を示したものである。図４に示す画面は、予定を予約したいユーザによって、操作部１０４を通してメールの作成メニュー（メッセージサービスメニュー）を起動させる操作が入力された場合に、表示部１０３上に表示される。

図４（ａ）は、メッセージサービスメニューの構成例を示したものである。メニューの項目の例として、「新規作成（ＳＭＳ）」と「新規作成（ＭＭＳ）」と「受信ボックス」と「送信ボックス」が表示されている。「新規作成（ＳＭＳ）」は、ＳＭＳによるメッセージの作成を行うための項目であり、「新規作成（ＭＭＳ）」は、ＭＭＳによるメッセージの作成を行うための項目である。図４（ａ）に示した画面で、「新規作成（ＳＭＳ）」が選択された場合の画面の例を、図４（ｂ）に示してある。

図４（ｂ）示した「送信メール作成」画面においては、操作部１０４への操作入力によって、ユーザが任意の文字や数字を入力することができる。図４（ｂ）に示した例では、
Golf at TokyoCC;
September27;
10am;
のように入力されている。つまり、予定の内容と場所を示す“Golf at TokyoCC”と、予定の日付を示す“September27”と、予定の時間を示す“10am”が、セミコロンと改行によって区切られている。なお、日付や文字間を区切る記号はセミコロンと改行に限定されるものではなく、コロンや空白等他の記号を用いるようにしてもよい。

図４（ｂ）に示した画面上の右下方には、入力した予約要求を、予約したい相手に送信するための送信ボタンＢ１が配置されている。

ユーザによって送信ボタンＢ１が押下された場合には、次に図４（ｃ）に示すような画面が表示される。図４（ｃ）には、作成したメッセージを、通常のメールとして送信するための項目（「通常メールとして送信」）と、予約要求として送信するための項目（「予約要求として送信」）とが示されている。

「通常メールとして送信」が選択された場合には、図４（ｂ）の画面上で作成されたメールが、通常のＳＭＳメールとして送信相手に送信される。「予約要求として送信」が選択された場合には、図４（ｂ）の画面上で作成されたメールから、ＸＭＬ等により記述される予約要求が生成されて、送信相手（予約要求受信側）に送信される（図３のステップＳ２）。

なお、図４では、メールの生成後に、そのメールを通常のメールとして送信するか、予約要求として送信するかを選択させるようにしているが、メールの作成時に、どちらのメールとして作成するかを選択させる構成としてもよい。

図５は、予約要求作成画面の他の構成例を示した図である。図５に示した画面は、通常のメールとして作成するのか、予約要求として作成するのかをメールの作成時に選択させる場合の例を示したものである。図５（ａ）は、メッセージサービスメニューが表示された画面の例を示したものであり、図４（ａ）に示したものと同一の画面である。ここで、「新規作成（ＳＭＳ）」が選択された場合の画面を、図５（ｂ）に示してある。

図５（ｂ）には、通常のメールを作成するための項目（「メール作成」）と、予約要求を作成するための項目（「予約要求作成」）とが示されている。この画面で「予約要求作成」が選択されると、画面は図５（ｃ）に示したものに遷移する。図５（ｃ）に示した画面は、予約要求を作成するための画面であり、標題が「予約要求」である以外は、図４（ｃ）に示した画面と同一である。

次に、図６を参照して、図３のステップＳ１で生成される予約要求の記述例について説明する。図６に示した予約要求はＸＭＬで記述されており、ヘッダと（“message-header”）とボディ（“message-body”）とで構成されている。ヘッダには、“message-type”と“message-type-id”と“message-type-informationと“message-from”と“message-to”の情報が含まれている。

“message-type”とは、メッセージのタイプを示すタグである。図６に示した例では、メッセージは「予約要求」であるため、ここには「予約要求」であることを示す“SMS Appointment Request”が記述されている。“message-type-id”とは、メッセージのタイプ毎に割り振られたＩＤであり、ここには、「予約要求」又は後述する「予約要求応答」に割り振られたＩＤである“012345”が記述されている。メッセージ解析部１３３は、このＩＤをみて、予約要求と予約要求応答との対応を判断する。すなわち、予約要求応答を受信した場合に、その予約要求応答がどの予約要求と対応しているものであるかを判定する。

“message-from”とは、メッセージの送信者（予約要求送信者）を示すタグであり、送信者の電話番号である“09012345678”が“contact-number”タグにより表現され、送信者の名前である“Bob”が“contact-name”のタグにより表現されている。また、“message-to”とは、メッセージの受信者（予約要求受信者）を示すタグであり、受信者の電話番号である“09056789012”が“contact-number”タグにより表現され、受信者の名前である“Steve”が“contact-name”のタグにより表現されている。

ボディの部分には、ユーザにより入力された“Golf at Tokyo CC”の情報が、場所を示すタグである“message-place”により表現され、“September 27”の情報が、日付を示すタグである“message-date”により表現され、“10am”の情報が、時刻を示す“message-time”のタグにより表現されている。ユーザによって入力された各種情報をどのタグで記述するかは、メッセージ生成部１３１によって判断される。

メッセージ生成部１３１は、図７に示したようなルックアップテーブルを参照して、ユーザにより入力された文字列から、日付の情報を取り出す処理を行う。図７に示したルックアップテーブルには、メッセージ生成部１３１によって解読可能なデータのフォーマットが記載されている。図７では、説明を分かりやすくするため、右側の列に各データフォーマットの例も示してある。

メッセージ生成部１３１は、図７に示したルックアップテーブルに記載された、09/27のようなMM/DDのフォーマットや、9/27のようなM/DDのフォーマット、9-27-2008のようなM-DD-YYYYのフォーマットで入力された文字を、「日付」の情報であると判断する。MMの“M”は、“Month（月）”の頭文字であり、“M”の数は桁を示す。つまり、“MM”で示されるフォーマットによれば、“01”〜“12”で示される文字が「月」として認識される。同様に、“DD”で示されるフォーマットによれば、“01”〜“31”で示される文字が「日（Day）」として認識される。メッセージ生成部１３１は、このようなルックアップテーブルに記載の内容に基づいて日付の情報を抽出し、これらをＸＭＬの“message-date”タグ内に記述する。

図８は、入力された文字列から時刻の情報を取り出すためのルックアップテーブルの例を示したものである。メッセージ生成部１３１は、図８に示したルックアップテーブルに記載された、10:00又は19:00のようなHH:MMのフォーマットや、3:00のようなH:MMのフォーマット、10amのようなHH[am/pm]のフォーマットで入力された文字を、「時刻」の情報であると判断する。HHの“H”は、“Hour（時間）”の頭文字であり、“H”の数は桁を示す。つまり、“HH”で示されるフォーマットによれば、“01”〜“12”又は“01”〜“24”で示される文字が「時」として認識される。同様に、“MM”で示されるフォーマットによれば、“01”〜“59”で示される文字が「時間（Minutes）」として認識される。メッセージ生成部１３１は、このようなルックアップテーブルに記載の内容に基づいて時間の情報を抽出し、ＸＭＬの“message-time”タグ内に記述する。

これらのルックアップテーブルは、例えばメモリ１０５等に記憶されているものとする。また、これらのフォーマットは、図７や図８に示したルックアップテーブルに記載されたものに限定されるものではなく、他の様々なフォーマットを適用可能であるものとする。

このようにして生成された予約要求が、予約要求受信者によって受信されると（図３のステップＳ３）、予約要求受信者側の携帯電話端末１００の表示部１０３には、図９（ａ）に示すような画面が表示される。画面には、「１件の予約要求が届いています」のメッセージとともに、予約要求の送信者の情報が「送信者：Bob＜09012345678＞」のように記載されている。画面の下方には“表示”と“キャンセル”の文字が示されており、ユーザは“表示”の文字を選択することで、予約要求の詳細を画面上に表示させることができる。“キャンセル”が選択された場合には、画面が閉じるようになっている。

この予約要求通知は、メッセージ生成部１３１（図２参照）によって、メッセージ解析部１３３での解析結果に基づいて作成される。メッセージ解析部１３３は、図６に示したＸＭＬで記載された予約要求をパース（解析）して、このメッセージが予約要求であると判断する。続いてメッセージ解析部１３３によって、“message-from”のタグから、送信者の名前（Bob）と電話番号（09012345678）が抽出され、メッセージ表示処理部１１２に供給される。メッセージ表示処理部１１２では、これらの情報を含んだ予約要求通知が生成される。

図９（ｂ）は、図９（ａ）に示した予約要求通知の画面上で、ユーザによって「表示」の文字が選択された場合の画面の例を示したものである。標題には「予約要求（送信者：Bob）」のように示されており、このメッセージが予約要求であり、送信者はBobであることが分かる。本文の欄には、予約の内容が
Golf at TokyoCC;
September27;
10am;
のように表示されている。

この画面が表示された状態で、ユーザによって、操作部１０４等を通して画面を下方向にスクロールする操作が入力されると、図９（ｃ）に示したように、画面の下方に承諾ボタンＢ３と拒絶ボタンＢ４を含むポップアップ画面が表示される。本例では、ユーザが画面上に表示された予約要求をすべて確認できた段階で図９（ｃ）に示したポップアップ画面を表示させるようにしてあり、このポップアップ画面を表示させる際の処理の詳細を図１０に示してある。

図１０には、メッセージを構成する各文字をバツで示してあり、メッセージの長さＬｍが６行であることが示されている。破線の四角で示されているのは、携帯電話端末１００の表示画面の領域であり、表示画面に表示可能なライン数Ｌｄは４行であることが示されている。また、ユーザによるスクロール操作Ｓｒを矢印で示してあり、１回のスクロール操作で移動できる量が４行であることが示されている。なお、これらの値は一例であり、他の様々な値を適用可能である。

携帯電話端末１００の制御部１１０（図１参照）は、表示画面に可能なライン数Ｌｄと、一度のスクロール操作での移動可能量を予め把握している。画面に表示させるメッセージの長さＬｍは、メッセージのボディ部分（図６の<message-bodyのタグで囲まれた部分>のライン数を取得することで把握する。そして、すべてのメッセージが画面上に表示された状態でユーザよりスクロールの操作が入力された場合に、図９（ｃ）に示したポップアップ画面を表示させる制御を行う。

「すべてのメッセージが画面上に表示された状態」とは、スクロール操作Ｓｒ１が入力されたことにより、メッセージの５行目と６行目が画面上に表示された状態、すなわち、破線で示した四角の２段目の領域が画面上に表示された状態である。この状態でさらにスクロール操作Ｓｒ２が入力されると、制御部１１０によって、承諾ボタンＢ３と拒絶ボタンＢ４とを含むポップアップ画面の表示制御が行われる。

なお、画面上にメッセージの最終行が表示されたことを検知した時点で、制御部１１０がポップアップ画面の表示を行うようにしてもよい。

また、図９及び図１０に示した例では、承諾ボタンＢ３と拒絶ボタンＢ４とを、ユーザからの所定の操作入力があった場合に表示させるようにしているが、このような表示に限定されるものではない。例えば図１１に示すように、画面の下方に固定的に承諾ボタンＢ３′と拒絶ボタンＢ４′を表示させるようにしてもよい。この場合は、ユーザによるスクロールダウン操作に伴ってスクロールされるのは、標題の部分と承諾ボタンＢ３′及び拒絶ボタンＢ４′の部分を除く領域となる。

予約要求通知が表示された画面上で、ユーザ（予約要求受信者）により承諾ボタンＢ３が押下されると、予約要求中に記載されたスケジュール情報が、ユーザの携帯電話端末１００のスケジュール帳に反映される。

図１２は、スケジュール情報が登録されたスケジュール帳の表示例を示すものである。スケジュール帳の９月２７日（“September 27”）の欄には、
Meet Bob
10am, Golf at TokyoCC
のように記載されている。つまり、予約要求に記載の内容に基づいて、予約要求送信者であるBobと、午前10時からTokyo CCでゴルフする予定がスケジュール帳に登録されている。

予約要求受信者によって、予約要求が承諾又は拒絶された後は、予約要求が承諾又は拒絶されたことを示す予約要求応答が生成されて、通信処理部１０１によって、予約要求送信者側に送信される。

図１３は、予約要求応答の記述例を示したものである。図６に示した予約要求と同様に、ＸＭＬで記述されており、こちらも、ヘッダと（“message-header”）とボディ（“message-body”）とで構成されている。予約要求との相違点は、ヘッダに“message-type-notification”のタグが追加されている点と、送信者（“message-from”）と受信者（“message-to”）の内容が、入れ替わっている点である。

“message-type-notification”は、予約要求が、予約要求受信者側で承諾されたのか拒絶されたのかを示す項目である。図１３に示した例では“ACCEPT”と記述されており、この予約要求応答が、予約要求が承諾されたことを示すものであることが分かる。このメッセージは、予約要求受信者、すなわち予約要求応答の送信者（“message-from”）であるSteveの携帯電話端末１００から、予約要求送信者、すなわち予約要求応答の受信者（“message-to”）であるBobの携帯電話端末１００に対して送信される。

図１４（ａ）は、予約要求応答の受信を通知する、予約要求応答通知の表示例を示すものである。予約応答通知には、「１件の予約要求応答（承諾）が届いています」のメッセージとともに、予約要求応答の送信者の情報が「送信者：Steve＜09056789012＞」のように記載されている。画面の下方には“スケジュール帳の表示”と“キャンセル”の文字が示されており、ユーザは“スケジュール帳表示”の文字を選択することで、スケジュール帳を画面上に表示させることができる。“キャンセル”が選択された場合には、画面が閉じるようになっている。

この予約要求応答通知も、メッセージ生成部１３１（図２参照）によって、メッセージ解析部１３３での解析結果に基づいて作成される。メッセージ解析部１３３は、図１４（ａ）に示したＸＭＬで記載された予約要求をパースして、まずこのメッセージが予約要求応答であり、かつ、以前送信した予約要求が「承諾」されたことを示すものであると判断する。続いてメッセージ解析部１３３によって、“message-from”のタグから、送信者の名前（Steve）と電話番号（09056789012）が抽出され、メッセージ表示処理部１１２に供給される。メッセージ表示処理部１１２では、これらの情報を含んだ予約要求応答通知が生成され、予約要求応答通知が表示部１０３上に表示される。

また、予約要求応答通知が、承諾を示すものであった場合には、メッセージ解析部１３３（ａ）で抽出されたスケジュール情報は、メッセージ蓄積部１１５に蓄積されるとともに、スケジュール連携部１３６を通してスケジュール機能部１２０にも供給される。

図１５は、スケジュール情報が追加されたスケジュール帳の表示例を示すものである。スケジュール帳の９月２７日（“September 27”）の欄には、
Meet Steve
10am, Golf at TokyoCC
のように記載されている。つまり、予約要求受信者であるSteveと、午前10時からTokyo CCでゴルフする予定が追加されている。

［３．実施の形態による効果］
上述した実施の形態によれば、ＳＭＳやＭＭＳ等のメッセージサービスを利用して容易に予約要求を送信することができるため、新たに予約要求用の機能を追加する必要がなくなり、携帯電話端末１００の製造コストも節減することができる。

なお、従来の技術においても、インターネット上でカレンダ（スケジュール帳）を共有できる機能が提供されており、この機能を利用すれば、カレンダを共有する他のメンバーに対して、予定の予約を要求する招待通知を送信できる。しかし、この機能を利用するには専用のＩＤを取得する必要があり、さらにカレンダを利用する際に、必ずインターネットに接続しなければならない。本実施の形態によれば、特定のＩＤを取得する必要もなく、またインターネットに接続することなく予約要求の機能を使用することができるようになる。

また、上述した実施の形態によれば、予約要求受信側において、予約を承諾した場合にその予約情報（スケジュール情報）が自動的に携帯電話端末１００内のスケジュール帳に登録されるため、スケジュールをユーザが手入力する手間を省くことができる。

またこの場合、スケジュール帳へのスケジュール情報の反映は、予約を承諾した場合にのみ行われるため、承諾したくない予定が勝手にスケジュール帳に反映されてしまうようなことがなくなる。さらに、承諾したくない予定は、拒絶ボタンＢ４を押下することにより削除することができるため、メッセージの蓄積領域の容量を削減することができる。

また、上述した実施の形態によれば、予約要求受信側において予約が承諾された場合には、予約要求の受信者だけでなく予約要求を送信した送信者における携帯電話端末１００のスケジュール帳にも、予約情報（スケジュール情報）が登録されるようになる。これにより、予定の予約を申し入れた側（予約要求送信側）においても、予定をマニュアルでスケジュール帳に登録する手間がかからなくなる。

［４．変形例］
なお、上述した実施の形態では、予約要求作成時に予約したい日付や時間をユーザがフリースタイルで画面に入力する例を挙げたが、これに限定されるものではない。例えば、日付や時間の入力用画面から、日付や時間を入力できるように構成してもよい。

図１６は、このように構成した場合の予約要求作成画面の例を示した図である。画面の左下方に、「日時入力ボタンＢ２」が設けられており、ユーザによりこのボタンＢ２が押下されることで、図１７に示したような日時入力画面が起動するように構成している。

図１７に示した日時入力画面には、日付をYYYY/MM/DDのフォーマットで入力させ、時間をHH:MMのフォーマットで入力させるための各テキストボックスが配置されている。日付を入力するボックスには、YYYYのボックスには“2008”が、MMのボックスには09が、DDのボックスには27が入力されている。時間を入力するボックスには、HHのボックスには10が、MMのボックスには00が入力されており、午前か午後かを設定するボックスには、午前を示すAMの文字が入力されている。

ここに入力された各数字又は文字は、ユーザにより画面左下の「設定ボタンＢ５」が押下されたタイミングで、ＸＭＬのフォーマットに変換される。具体的には、
<message-date>2008/09/27;</message-date>
<message-time>10:00am;</message-time>
のように変換される。

このように、ユーザによる日時の入力を補助するボックスを設けることで、上述したルックアップテーブル（図７参照）を使用することなく、ＸＭＬ等のマークアップ言語で記載される日時を容易に設定することができるようになる。

また、ここまで説明した実施の形態では、本発明の通信端末を携帯電話端末に適用した例を挙げたが、これに限定されるものではない。例えば、メッセージサービスによるメッセージの送受信を行える機能を有するものであれば、ＰＤＡ（Personal Digital Assistants）やゲーム機等の他の装置に適用してもよい。

１００…携帯電話端末、１０１…通信処理部、１０２…アンテナ、１０３…表示部、１０４…操作部、１０５…メモリ、１０６…音声処理部、１０７…スピーカ、１０８…マイクロフォン、１１０…制御部、１１２…メッセージ表示処理部、１１５…メッセージ蓄積部、１２０…スケジュール機能部、１３０…メッセージサービス処理部、１３１…メッセージ生成部、１３２…メッセージ蓄積・削除制御部、１３３…メッセージ解析部、１３４…メッセージ表示処理部、１３５…メッセージ蓄積部、１３６…スケジュール連携部、１５０…制御ライン、１６０…データライン、Ｂ１…送信ボタン

Claims (8)

1. 他の端末との間で無線通信によるデータの送受信を行う通信処理部と、
   ユーザのスケジュール情報を登録するスケジュール帳への、前記スケジュール情報の登録又は読み出しを行うスケジュール機能部と、
   前記無線通信を行う通信相手の宛先情報と、前記スケジュール帳に登録させたい前記スケジュール情報を含んだ予約要求を生成して、前記予約要求を前記通信処理部に出力するメッセージ生成部と、
   前記通信処理部を介して受信した前記予約要求の中から前記スケジュール情報を抽出するメッセージ解析部と、
   前記ユーザより前記予約要求を承諾する指示が入力された場合に、前記メッセージ解析部で抽出された前記スケジュール情報を、前記スケジュール機能部に出力して前記スケジュール情報を前記スケジュール帳に登録させる制御を行うスケジュール連携部とを含む
   通信端末。
2. 前記メッセージ生成部は、前記ユーザより前記予約要求を承諾する指示又は拒絶する指示が入力された場合に、前記予約要求が承諾又は拒絶されたことを示す予約要求応答を生成して、前記予約要求応答を前記通信処理部に出力する
   請求項１記載の通信端末。
3. 前記スケジュール連携部による前記スケジュール機能部への前記スケジュール情報の登録制御は、
   前記通信処理部を介して、前記予約要求が承諾されたことを示す前記予約要求応答が受信された場合にも行われる
   請求項２記載の通信端末。
4. 文字や画像を表示する表示部と、
   前記メッセージ解析部で抽出された前記スケジュール情報と、前記予約要求の承諾又は拒絶の指示を受け付けるためのユーザインタフェースとを含む画面を生成して、前記表示部に出力する表示処理部とを備え、
   前記予約要求を承諾又は拒絶する指示は、前記表示部の画面上に表示された前記ユーザインタフェースを通して、前記承諾又は拒絶が選択されることにより入力される
   請求項３記載の通信端末。
5. 前記予約要求及び前記予約要求応答は、前記通信処理部によって、メッセージサービスを用いて送受信される
   請求項４記載の通信端末。
6. 前記ユーザより前記予約要求を拒絶する指示が入力された場合又は、前記予約要求が拒絶されたことを示す前記予約要求応答が受信された場合に、前記スケジュール情報を削除するスケジュール情報削除部を含む
   請求項５記載の通信端末。
7. 無線通信を行う通信相手の宛先情報と、ユーザのスケジュール情報を登録するスケジュール帳に登録させたい前記スケジュール情報を含んだ予約要求を生成して、前記通信相手に送信するステップと、
   前記通信相手から送信された、前記予約要求が承諾されたことを示す予約要求応答を受信した場合に、前記予約要求応答に含まれるスケジュール情報を抽出するステップと、
   前記抽出されたスケジュール情報を、前記スケジュール帳に登録するステップとを含む
   通信方法。
8. 前記通信相手から送信された、前記予約要求を受信した場合に、前記予約要求中に記載された前記スケジュール情報と、前記予約要求の承諾又は拒絶の指示を受け付けるためのユーザインタフェースとを含む画面を生成して表示部に出力するステップと、
   前記表示部の画面上に表示された前記ユーザインタフェースを通して、前記ユーザより前記予約要求を承諾する指示が入力された場合に、前記予約要求応答に含まれるスケジュール情報を、前記スケジュール帳に登録するステップとを含む
   請求項７記載の通信方法。
   

Images