(57)【要約】【課題】複数人の個々のユーザにより共有可能なスケジュールの登録を容易にし、且つ、各ユーザが他ユーザのスケジュールを容易に閲覧可能とする。【解決手段】携帯電話装置は、他のユーザの携帯電話装置から電子メールのデータフォーマットで送信されてきたデータを受信し（ステップＳ２１）、その受信データがスケジュールデータであるか判定する（ステップＳ２２）。次に携帯電話装置は、その受信したスケジュールデータを蓄積し（ステップＳ２４，ステップＳ２５）、さらに電子メールのデータフォーマットで送られてきているスケジュールデータを、スケジュールデータ本来のデータフォーマットへ戻す（ステップＳ２６，ステップＳ２７）。その後、携帯電話装置は、そのスケジュールデータを、自己のスケジュール帳へ自動的に登録する（ステップＳ２８）。【選択図】      図１３
2004199224.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも、送信されてきたデータを受信する通信部と、
スケジュール帳に登録されたスケジュールデータを蓄積するスケジュールデータ蓄積部と、
上記通信部からの受信データがスケジュールデータであるか否かを判別するデータ判別部と、
上記スケジュール帳を管理すると共に、受信されたスケジュールデータを上記スケジュール帳へ自動登録するスケジュール帳管理部とを有する
ことを特徴とする情報通信装置。
【請求項２】
請求項１記載の情報通信装置であって、
上記判別部は、上記受信データに付加されている判別フラグにより、当該受信データがスケジュールデータか否かを判別することを特徴とする情報通信装置。
【請求項３】
請求項１記載の情報通信装置であって、
上記通信部はパケット単位で送信されてきたデータを受信し、
複数パケットの受信データを併合して一つのスケジュールデータを生成するデータ併合部を有することを特徴とする情報通信装置。
【請求項４】
請求項３記載の情報通信装置であって、
上記各パケットは、少なくとも、各パケットを識別するためのパケット識別情報と、スケジュールデータを一意に示すスケジュールデータ識別情報と、最終パケットを示す最終フラグとを含み、
上記データ併合部は、上記パケット識別情報とスケジュールデータ識別情報と最終フラグとにより、上記一つのスケジュールデータを生成するために併合すべき各パケットを決定することを特徴とする情報通信装置。
【請求項５】
請求項１記載の情報通信装置であって、
上記通信部は電子メールのデータフォーマットで送信されてきたデータを受信し、
当該電子メールのデータフォーマットのスケジュールデータを、所定のデータフォーマットのスケジュールデータへ変換するフォーマット変換部を有し、
上記スケジュール帳管理部は、上記所定のデータフォーマットのスケジュールデータを管理することを特徴とする情報通信装置。
【請求項６】
請求項５記載の情報通信装置であって、
上記電子メールのデータフォーマットは、通信データ量に制限が設けられた簡易型電子メールのデータフォーマットを含むことを特徴とする情報通信装置。
【請求項７】
請求項１記載の情報通信装置であって、
使用者の指示に応じて、送信するスケジュールデータを決定するデータ決定部を有し、
上記通信部は、当該決定されたスケジュールデータを送信することを特徴とする情報通信装置。
【請求項８】
請求項７記載の情報通信装置であって、
上記送信するデータにスケジュールデータか否かを判別するための判別フラグを付加する判別フラグ付加部を有することを特徴とする情報通信装置。
【請求項９】
請求項７記載の情報通信装置であって、
送信する一つのスケジュールデータを複数に分割し、各分割データをパケット化する送信パケット生成部を有し、
上記通信部は上記パケット単位のデータを送信することを特徴とする情報通信装置。
【請求項１０】
請求項９記載の情報通信装置であって、
上記送信パケット生成部は、少なくとも、各パケットを識別するためのパケット識別情報と、スケジュールデータを一意に示すスケジュールデータ識別情報と、最終パケットを示す最終フラグとを、各送信パケットに付加することを特徴とする情報通信装置。
【請求項１１】
請求項７記載の情報通信装置であって、
所定のデータフォーマットのスケジュールデータを、電子メールのデータフォーマットへ変換するフォーマット変換部を有し、
上記通信部は上記電子メールのデータフォーマットによりデータを送信することを特徴とする情報通信装置。
【請求項１２】
請求項１１記載の情報通信装置であって、
上記電子メールのデータフォーマットは、通信データ量に制限が設けられた簡易型電子メールのデータフォーマットを含むことを特徴とする情報通信装置。
【請求項１３】
請求項７記載の情報通信装置であって、
複数の送信先を決定する送信先決定部を有し、
上記通信部は、上記決定された複数の送信先へ上記スケジュールデータを同時に送信することを特徴とする情報通信装置。
【請求項１４】
請求項１３記載の情報通信装置であって、
上記送信先決定部は、グループ分けされた送信先の少なくとも一つのグループを決定することを特徴とする情報通信装置。
【請求項１５】
請求項１記載の情報通信装置であって、
上記通信部は、電話の発呼を行う機能を備え、
上記スケジュール帳を参照し、発呼相手先のスケジュールと当該発呼が重なるとき、所定のアラート信号を生成するアラート生成部を有することを特徴とする情報通信装置。
【請求項１６】
請求項１５記載の情報通信装置であって、
上記スケジュール帳管理部は、各スケジュールデータに重要度の情報を付加し、
上記アラート生成部は、上記スケジュールデータの重要度に応じたアラート信号を生成することを特徴とする情報通信装置。
【請求項１７】
請求項１６記載の情報通信装置であって、
上記アラート生成部は、上記スケジュールデータの重要度に応じた回数だけ、上記アラート信号を生成することを特徴とする情報通信装置。
【請求項１８】
請求項１６記載の情報通信装置であって、
上記スケジュールデータの重要度に応じて、上記発呼相手先への発呼の諾否を決定する発呼制御部を有することを特徴とする情報通信装置。
【請求項１９】
請求項１８記載の情報通信装置であって、
上記発呼制御部は、上記スケジュールデータの重要度に応じた回数だけ、上記発呼の諾否を決定することを特徴とする情報通信装置。
【請求項２０】
請求項１５記載の情報通信装置であって、
少なくとも文字情報を表示する表示部を有し、
上記アラート生成部は、上記表示部に表示するアラートメッセージを上記アラート信号として生成することを特徴とする情報通信装置。
【請求項２１】
少なくとも、送信されてきたデータを受信し、
その受信データがスケジュールデータであるか否かを判別し、
上記受信されたスケジュールデータをスケジュール帳へ自動登録する
ことを特徴とする情報通信方法。
【請求項２２】
使用者の指示に応じて、送信するスケジュールデータを決定し、
当該決定されたスケジュールデータを送信し、
上記送信されてきたデータを受信し、
その受信データがスケジュールデータであるか否かを判別し、
当該受信されたスケジュールデータをスケジュール帳へ自動登録する
ことを特徴とする情報通信方法。
【請求項２３】
少なくとも、送信されてきたデータを受信するステップと、  スケジュール帳に登録されたスケジュールデータを蓄積するステップと、
上記受信データがスケジュールデータであるか否かを判別するステップと、
上記スケジュール帳を管理すると共に、受信されたスケジュールデータを上記スケジュール帳へ自動登録するステップとを、
コンピュータに実行させるためのスケジュール共有プログラム。
【請求項２４】
使用者の指示に応じて、送信するスケジュールデータを決定するデータ決定部と、当該決定されたスケジュールデータを送信する通信部とを有する第１の情報通信装置と、
送信されてきたデータを受信する通信部と、スケジュール帳に登録されたスケジュールデータを蓄積するスケジュールデータ蓄積部と、上記通信部からの受信データがスケジュールデータであるか否かを判別するデータ判別部と、上記スケジュール帳を管理すると共に、受信されたスケジュールデータを上記スケジュール帳へ自動登録するスケジュール帳管理部とを有する第２の情報通信装置とからなる
ことを特徴とする情報通信システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、複数人のユーザが個々のユーザのスケジュールを共有可能にするための情報通信装置及び情報通信方法、スケジュール共有プログラム、情報通信システムに関する。
【０００２】
【従来の技術】
従来より、使用者のスケジュールを編集及び登録可能な電子メールソフトウェア（例えばマイクロソフト社の「Outlook」）と、電子メールを中継すると同時に複数のユーザのスケジュールを調整するための機能を備えた電子メール管理サーバ用ソフトウェア（例えばマイクロソフト社の「ExchangeServer」）とを使用することにより、複数人のユーザの個々のスケジュールを、ネットワークを介してそれら各ユーザにより共有可能となされたシステムが存在している。また、このシステムのサーバには、ネットワークへ接続可能な携帯電話装置からもアクセス可能になされていることが多い。
【０００３】
また、特許文献１には、各要員がアクセス可能な共有個人情報（例えば仕事のスケジュール）を格納するためのメールボックスをサーバ内に設け、外勤中の各要員がその共有個人情報のメールボックスへアクセスすることで、各要員がそれぞれ属するグループ内の他の要員の諸情報を取得可能としたシステムが開示されている。さらに、このシステムによれば、サーバは、手配に応じる用意のある各要員に対して、派遣依頼者からの手配要求が有った旨及びその手配に対する諾否の返答を求める旨の通知を行うことが記載されている。
【０００４】
【特許文献１】
特開２００１−２０９７１７号公報（図８）
【０００５】
【発明が解決しようとする課題】
ところで、スケジュールの登録、閲覧といった行為は極めて日常的な動作であり、したがって、例えば各ユーザが他ユーザと共有可能なスケジュールを簡単に登録できたり、また、各ユーザが他ユーザのスケジュールを何時でも何処でも気軽に閲覧できれば非常に便利である。
【０００６】
しかしながら、上述した従来のシステムは、サーバが複数ユーザのスケジュールを一元管理するようになされているため、各ユーザが自己のスケジュールを登録したり、他のユーザのスケジュールを閲覧するためには、必ずサーバへのアクセスが必要となっている。
【０００７】
したがって、例えば携帯電話装置のようにネットワークと常時接続されていない情報通信装置を使用している場合、ユーザは、スケジュールの登録，閲覧を行う際に、それら登録，閲覧の行為以外に、サーバへのアクセスのための手間と時間をかけなければならない。また、携帯電話装置の場合、無線通信圏外に入ってしまうと、サーバへのアクセスができなくなるため、スケジュールの登録，閲覧の行為そのものが不可能となる。このように、従来のシステムは、複数ユーザのスケジュールの共有という観点から、手軽な仕組みであるとは到底言い難い。
【０００８】
本発明は、このような課題に鑑みてなされたものであり、複数人の個々のユーザにより共有可能なスケジュールを容易に登録でき、且つ、各ユーザが他ユーザのスケジュールを容易に閲覧可能とする、情報通信装置及び情報通信方法、スケジュール共有プログラム、情報通信システムを提供することを目的とする。
【０００９】
【課題を解決するための手段】
本発明の情報通信装置は、少なくとも、送信されてきたデータを受信する通信部と、受信データがスケジュールデータであるか否かを判別するデータ判別部と、受信されたスケジュールデータをスケジュール帳へ自動登録するスケジュール帳管理部とを有する。
【００１０】
本発明の情報通信方法は、少なくとも、送信されてきたデータを受信し、その受信データがスケジュールデータであるか否かを判別し、受信されたスケジュールデータをスケジュール帳へ自動登録する。
【００１１】
また、本発明の情報通信方法は、使用者の指示に応じて、送信するスケジュールデータを決定して送信し、その送信されてきたデータがスケジュールデータであるか否かを判別し、当該スケジュールデータをスケジュール帳へ自動登録する。
【００１２】
本発明のスケジュール共有プログラムは、少なくとも、送信されてきたデータを受信するステップと、受信データがスケジュールデータであるか否かを判別するステップと、受信されたスケジュールデータをスケジュール帳へ自動登録するステップとをコンピュータに実行させる。
【００１３】
本発明の情報通信システムは、使用者の指示に応じて、送信するスケジュールデータを決定して送信する第１の情報通信装置と、送信されてきたデータを受信し、その受信データがスケジュールデータであるか否かを判別し、スケジュールデータであるときそのデータをスケジュール帳へ自動登録する第２の情報通信装置とからなる。
【００１４】
すなわち本発明によれば、サーバ等の外部のスケジュール管理機関を設けず、各情報通信装置間でスケジュールデータを共有し、直接且つ自動的にスケジュールを登録可能としている。
【００１５】
【発明の実施の形態】
以下、本発明の好ましい実施の形態について、図面を参照しながら説明する。
【００１６】
図１には、本発明の情報通信装置の一実施の形態として、携帯電話装置の概略構成を示す。なお、本発明の情報通信装置は、携帯電話装置だけでなく、ＰＨＳ（PHS：Personal Handyphone System、登録商標）電話装置、カーナビゲーション装置等の移動体通信端末や、通信機能を備えたＰＤＡ装置（PDA：Personal Digital Assistants）やパーソナルコンピュータ等であっても良い。
【００１７】
本実施の形態の携帯電話装置は、図１に示すように、送受信信号処理部２１と、コミュニケーション処理部２２と、アプリケーション制御処理部２３とを備えている。コミュニケーション処理部２２とアプリケーション制御処理部２３は、ＣＰＵインターフェイス部２４（ＣＰＵＩ／Ｆ部）を介して接続されている。上記コミュニケーション処理部２２は、通話等のコミュニケーションを制御するためのコミュニケーションＣＰＵ６１を備え、上記アプリケーション制御処理部２３は、待ち受け画像の表示処理や着信メロディの音声処理の他、一般の電子メールや簡易型の電子メールの送受信機能、及び、それら電子メールを利用した後述する本実施の形態のスケジュール登録，閲覧機能を実現するためのアプリケーション（本発明にかかるスケジュール共有プログラム）などの各種のアプリケーションを制御するためのアプリケーションＣＰＵ７１を備えている。なお、一般の電子メールとはいわゆるインターネット等を使用して送受信される電子メールであり、上記簡易型電子メールとは所定の携帯電話通信システムの通信網内でのみ使用され且つ１回当たりの通信データ量を制限（例えば１００バイト）することで安価な送受信を可能にし、また、相手先にて受信されていないときには自動的に再送するようになされた電子メールであるとする。以下、本実施の形態において、上記簡易型電子メールの表記は、一般の電子メールと区別して説明する場合にのみ使用し、それ以外では単に電子メールと表記する。また、本実施の形態では、コミュニケーション処理部２２での処理とアプリケーション制御処理部２３での処理をそれぞれ別のＣＰＵが担当した例を挙げているが、それら処理を一つのＣＰＵが担当しても良いし、それら処理を３つ以上のＣＰＵに分けて担当させても良い。
【００１８】
［信号受信時の動作］
受信信号処理部２１は、図示しない基地局からの無線電波をアンテナ３１により受信すると、その受信信号を共用器３２を介して受信ＲＦ部３３に送る。受信ＲＦ部３３は、当該受信信号を増幅し、次の周波数変換部３５へ送る。周波数変換部３５は、局発部３４からの局部発振信号を用いて、高周波の受信信号をベースバンド信号へダウンコンバートする。当該ベースバンド信号は、受信Ｉ／Ｆ部３６へ送られてＡ／Ｄ（アナログ／ディジタル）変換されて受信データとなされた後、受信レベル検出部３７へ送られる。
【００１９】
上記受信レベル検出部３７は、受信データから受信レベルを検出し、その検出した受信レベル情報をコミュニケーション処理部２２へ送る。また、受信レベル検出部３７は、上記受信データを受信復調部３８へ送る。
【００２０】
受信復調部３８は、受信データからフェージング成分を除去し、さらに拡散符号の復調を行うと共に、受信データが音声データかその他の通信データ（例えばパケット通信データ）かの種別判別と分離を行い、当該種別判別により分離された音声データを音声復号部３９へ、通信データを通信データ復号部４２へ送る。
【００２１】
音声復号部３９は、音声データの伸張処理、デインターリーブ処理、エラー訂正処理等の復号化処理を行った後、さらにＤ／Ａ（ディジタル／アナログ）変換処理を施す。当該Ｄ／Ａ変換後のアナログ音声信号は、アンプ４０により増幅されてスピーカ４１に供給される。これにより、受信された音声が、スピーカ４１を介して出力されることになる。
【００２２】
上記通信データ復号部４２は、電子メール等の各種の通信データの伸張処理、デインターリーブ処理、エラー訂正処理等の復号化処理を行い、得られた通信データを、コミュニケーション処理部２２及びＣＰＵＩ／Ｆ部２４を介してアプリケーション制御処理部２３へ送る。
【００２３】
［信号送信時の動作］
一方、マイクロホン４３を介して入力されたアナログ音声信号は、アンプ４４にて所定のレベルに調整された後、音声符号化部４５に送られる。音声符号化部４５は、音声信号をＡ／Ｄ（アナログ／ディジタル）変換処理し、さらに圧縮処理、インターリーブ処理、エラー訂正符号の付加処理等を行い、得られた音声データを送信変調部４６に送る。
【００２４】
また、コミュニケーション処理部２２から入力された電子メール等の通信データは、通信データ符号化部４７に送られる。当該通信データ符号化部４７は、通信データの圧縮処理、インターリーブ処理、エラー訂正符号の付加処理等を行い、得られた通信データを送信変調部４６に送る。
【００２５】
送信変調部４６は、供給された音声データや通信データに対して拡散符号による変調処理を施し、得られたＩ，Ｑ成分が送信Ｉ／Ｆ部４８へ送られる。送信Ｉ／Ｆ部４８は、Ｉ，Ｑ成分をＤ／Ａ変換し、それをベースバンドの送信信号として周波数変換部４９へ送る。
【００２６】
周波数変換部４９は、局発部３４からの局部発振信号を用いて、上記ベースバンドの送信信号を高周波の送信信号へアップコンバートし、送信ＲＦ部５０へ送る。送信ＲＦ部５０は、上記送信信号を増幅した後、その送信信号を共用器３２へ送る。この時の共用器３２は、上記送信信号をアンテナ３１へ送る。これにより、アンテナ３１からは、送信信号が無線電波として送信されることになる。
【００２７】
［コミュニケーション処理部の構成及び基本動作］
コミュニケーション処理部２２のコミュニケーションＣＰＵ６１は、上記送受信信号処理部２１における上述した信号送受信処理を制御する。具体的には、コミュニケーションＣＰＵ６１が、ＲＯＭ６３（Read Only Memory）に記憶されている通信制御プログラムに従って各種通信制御処理を行う。
【００２８】
なお、コミュニケーションＣＰＵ６１は、バスライン６２を介して、ＲＯＭ６３、ＲＡＭ６４(Random Access Memory)、ＥＥＰＲＯＭ６５（Electrically Erasable and Programmable Read Only Memory）と接続されている。ＲＡＭ６４は、コミュニケーションＣＰＵ６１の作業領域として使用され、コミュニケーションＣＰＵ６１のプログラム実行中において必要に応じて計算途中のデータなどを記憶したり、他の各部と送受信するデータを一時的に記憶する。ＥＥＰＲＯＭ６５は、不揮発性メモリであって、携帯電話装置の電源がオフ操作されても、例えば直前の通信設定条件の情報を記憶しておくことができる。したがって、コミュニケーションＣＰＵ６１は、次回に電源がオン操作された際に、このＥＥＰＲＯＭ６５に記憶されている情報に基づいて各部を設定制御することで、電源がオフ操作される直前の設定を再現するようになっている。
【００２９】
このようなコミュニケーション処理部２２は、上記通信制御プログラムによって信号の送受信処理等の各種の通信制御処理を行う。
【００３０】
［アプリケーション制御処理部の構成及び基本動作］
アプリケーション制御処理部２３は、キー入力等のユーザインターフェース制御や、待ち受け画像の表示処理、着信メロディの音声処理、スケジュールの編集及び閲覧と電子メールを使用したスケジュールの共有及び登録を実現するためのスケジュール共有プログラムなどの各種のアプリケーションプログラムを実行する。具体的には、アプリケーションＣＰＵ７１が、ＲＯＭ７２に記憶されているアプリケーションプログラムを起動し、アプリケーション用バスライン７３を介して接続された各部を制御することにより、上記アプリケーション機能を実現する。
【００３１】
アプリケーション用バスライン７３を介して上記アプリケーションＣＰＵ７１と接続されている各構成要素のうち、ＲＡＭ７４は、アプリケーションＣＰＵ７１の作業領域として使用され、ＥＥＰＲＯＭ７５はアプリケーションの設定条件等を記憶している。また、ＲＯＭ７２は、当該携帯電話装置の初期化のための情報や、表示部８２（ＬＣＤ）に文字を表示するための表示用のフォントデータや、リンガ（着信音用等を出力するためのスピーカ）７８による音響出力を得るための音響サンプルデータ、バイブレータ７９を動作させるための振動パターンなどを記憶している。内部ストレージ８９は、例えばフラッシュメモリ等の記憶保持動作が不要な書き換え可能な記憶媒体であり、例えば上記各種のアプリケーションプログラムや、電話番号や電子メールアドレス及びそれに対応した氏名，名称などの情報からなる電話帳データ、送受信された電子メールデータ、スケジュール帳データ、発着信の通信履歴データ、メモ帳データ、ユーザのプロフィールデータ、キャラクタデータ、画像データ、音声データ等の各種のデータを記憶する。なお、これらデータはＥＥＰＲＯＭ７５に記憶されても良い。また、内部ストレージ８９とＥＥＰＲＯＭ７５は、別構成ではなく、同一のメモリ内の記憶領域を分割して実現されていても良い。
【００３２】
キー操作部７６は、電話番号やアルファベット、仮名文字、記号等の入力使用されるボタンや、画面上でカーソルを移動させたりメニュー項目の選択に使用される回転機能及びプッシュボタン機能を備えたジョグダイヤル等の操作子、電話の発着信、電源オン／オフなど、ユーザにより操作される各種のキーやボタン、ダイヤルからなる。なお、カーソル操作やメニュー項目の選択等に使用される操作子はジョグダイヤルに限定されないことは言うまでもない。
【００３３】
当該携帯電話装置において、キー操作部７６がユーザにより操作されると、キーＩ／Ｆ７７はその操作情報をアプリケーションＣＰＵ７１に送る。この時のアプリケーションＣＰＵ７１は、そのキー操作に従ったアプリケーション処理を実行する。
【００３４】
また、アプリケーションＣＰＵ７１は、リンガ７８やバイブレータ７９、ＬＥＤ（Light Emitting Diode）８０を駆動させて呼び出しをユーザに通知したり、待ち受け画像や各種メッセージ等をＬＣＤＩ／Ｆ８１を介して表示部８２に表示させる制御を行う。
【００３５】
また、本実施の形態の携帯電話装置は、例えばＳＩＭ（Subscriber Identity Module Card）カード８３を装着可能なカードドライブ８４や、外部ストレージ８６を接続可能なストレージＩ／Ｆ８７をも備えているものとする。当該カードドライブ８４に上記ＳＩＭカード８３が装着されると、カードドライブ８４は、そのＳＩＭカード８３に記録されているユーザの電話番号等の個人ＩＤなどを読み出し、カードＩ／Ｆ８５、ＣＰＵＩ／Ｆ部２４を介してコミュニケーションＣＰＵ６１に供給する。このときのコミュニケーションＣＰＵ６１は、それら情報により、例えばユーザの認証を行う。また、上記外部ストレージ８６がストレージＩ／Ｆ８７に接続されると、アプリケーションＣＰＵ７１は、その外部ストレージ８６の記録内容をストレージＩ／Ｆ８７を介して読み込む。この外部ストレージ８６から読み出された情報は、必要に応じてコミュニケーションＣＰＵ６１にも供給される。なお、上記外部ストレージ８６は、例えばスティック状或いはカード状の半導体メモリであっても良い。当該外部ストレージ８６は、例えば大容量を有しており、本実施の形態のスケジュール共有プログラムを含む各種のアプリケーションプログラムや、通信機能を改善や拡充を図るためのアプリケーションプログラム，待ち受け画面，着信メロディ，フォント等のデータを記憶可能なものである。また、本実施の形態の携帯電話装置において、コミュニケーションＣＰＵ６１及びアプリケーションＣＰＵ７１は、上記外部ストレージ８６に記憶されたプログラムを読み出し、既存のプログラムを書き換え制御（バージョンアップ，アップデート）することも可能となっている。勿論、本実施の形態の携帯電話装置は、受信したり外部Ｉ／Ｆ８８を介してダウンロードされたプログラムによるバージョンアップやアップデートも可能となされている。
【００３６】
［スケジュール共有プログラムの基本構成］
以下、上記アプリケーションＣＰＵ７１が本実施の形態のスケジュール共有プログラムを実行している時の処理の流れ、及び、表示部８２の画面表示例について説明する。
【００３７】
ここで、本実施の形態のスケジュール共有プログラムは、大別して、一般的なスケジュール作成編集プログラムと同様に自己のスケジュールを作成及び編集するためのスケジュール作成編集処理ステップと、自己のスケジュールデータを電子メールを使用して他のユーザの携帯電話装置へ送信するためのスケジュールデータ送信処理ステップと、他のユーザの携帯電話装置から電子メールを利用して送信されてきたスケジュールデータを受信し、自己のスケジュールと併合して登録及び閲覧可能するためのスケジュールデータ受信登録処理ステップとから構成されている。
【００３８】
［スケジュールデータ送信処理ステップ］
図２は、上記スケジュールデータ送信処理ステップの流れを示している。なお、図２は、スケジュールデータを簡易型電子メールを利用して送信する場合を例に挙げて説明する。また、図２の例は、スケジュール作成編集処理ステップ（ステップＳ１）により自己のスケジュールデータの作成若しくは編集が完了した後の、スケジュールデータ送信処理ステップの流れを示している。図３には、上記スケジュール作成編集処理ステップ（ステップＳ１）により作成若しくは編集された後のスケジュールの内容が、図１の表示部８２の画面９０上に表示された状態の一例を示している。すなわち図３は、２００２年１０月２５日（金）のスケジュールとして、９時から資料作成、１３時から発表会が行われるなどの内容が、画面９０上に表示された状態の例である。
【００３９】
上記ステップＳ１にてスケジュールの作成若しくは編集が完了すると、アプリケーションＣＰＵ７１は、ステップＳ２の判定処理に進み、図４に示すように、表示部８２の画面９０にポップアップウィンドウ９２を表示させる。このポップアップウィンドウ９２は、自己のスケジュールを他のユーザと共有するか否かをユーザに確認するための文字メッセージ（例えば「スケジュールを共有しますか？」）が表示されるメッセージ表示エリア９２と、スケジュールの共有の諾否（例えば「はい」、「いいえ」）をユーザに確認する確認エリア９３，９４とからなる。そして、アプリケーションＣＰＵ７１は、例えば、ユーザによるキー操作部７６の操作子の操作（一例としてジョグダイヤル回転操作）に応じて、上記確認エリア９３，９４の何れか一方を選択可能状態とし、さらに、ユーザによる操作子の操作（一例としてジョグダイヤルのプッシュ操作）に応じて、上記選択可能状態となされている方のエリアの選択を確定する。なお、選択可能状態となっている確認エリア９３又は９４は、例えばハイライト表示される。これにより、ユーザは、何れの確認エリアが選択可能であるのかを知ることができる。アプリケーションＣＰＵ７１は、当該ステップＳ２の判定処理において、ユーザにより、「いいえ」の確認エリア９４が選択されたと判定した場合、つまりスケジュールを共有しない旨の指示がユーザによりなされたと判定した場合には、ステップＳ３の処理としてスケジュール作成編集の処理へ戻る。一方、アプリケーションＣＰＵ７１は、ステップＳ２の判定処理において、ユーザにより「はい」の確認エリア９３が選択されたと判定した場合、つまりスケジュールの共有を許可する旨の指示がユーザによりなされたと判定した場合には、ステップＳ４へ処理を進める。
【００４０】
ステップＳ４に進むと、アプリケーションＣＰＵ７１は、前記電話帳データに登録されている電子メールアドレスがグループ分けされているか否か判定する。このステップＳ４において、グループ分けがなされていると判定した場合、アプリケーションＣＰＵ７１は、次のステップＳ６へ処理を進める。一方、ステップＳ４にてグループ分けされていないと判定した場合、アプリケーションＣＰＵ７１は、ステップＳ５の処理として、ユーザにグループ分けを行うように促し、それに応じて各電子メールアドレスのグループ設定がユーザによりなされると、ステップＳ６へ処理を進める。
【００４１】
ステップＳ６に進むと、アプリケーションＣＰＵ７１は、例えば図５に示すような送信先グループの選択画面９５を表示部８２に表示させる。なお、この図５は、それぞれ一以上の電子メールアドレスにより構成されている各グループの名前（「開発プロジェクトＡ」〜「開発プロジェクトＣ」，「野球チーム」等）が表示された例を示している。そして、アプリケーションＣＰＵ７１は、ユーザによる操作子の操作（例えばジョグダイヤル回転操作）に応じて、図５の画面９５に表示された各グループのうちの何れかを選択可能状態とし、さらに操作子の操作（例えばジョグダイヤルのプッシュ操作）に応じてユーザが何れのグループを選択したかを検出する。なお、選択可能状態となっているグループ名は、例えばハイライト表示される。これにより、ユーザは、何れのグループが選択可能であるのかを知ることができる。このステップＳ６において、ユーザによりグループの選択がなされると、アプリケーションＣＰＵ７１は、ステップＳ７へ処理を進める。
【００４２】
ステップＳ７に進むと、アプリケーションＣＰＵ７１は、ステップＳ２で共有が許可されたスケジュールデータを簡易型電子メールのデータフォーマットに変換する。ここで、前記図３に示した内容のスケジュールの共有がユーザにより許可された場合、この時のスケジュールデータは、例えば図６に示すデータ構成となる。すなわち図６のスケジュールデータは、図３のスケジュールを例えば上から順にデータ化したものであり、「２００２年１０月２５日」を表す日付データ、「９時」を表す時間データ、スケジュールの内容を表す「資料作成」のメッセージ本文のバイト数データ、「資料作成」のメッセージ本文のデータ、「１３時」を表す時間データ、スケジュールの内容を表す「発表会」のメッセージ本文のバイト数データ、「発表会」のメッセージ本文のテキストデータのように順に続くものとなる。なお、上記バイト数のデータは、メッセージ本文の長さが可変であるために、そのメッセージ本文の可変のデータ長を表すために設けられている。また、上記簡易型電子メールのデータフォーマットが例えばＳＪＩＳ（シフトＪＩＳ）である場合、アプリケーションＣＰＵ７１は、上記図６のスケジュールデータを、上記簡易型電子メールに対応したＳＪＩＳデータフォーマットのデータに変換する。このステップＳ７の処理が終了すると、アプリケーションＣＰＵ７１は、ステップＳ８へ処理を進める。
【００４３】
ステップＳ８に進むと、アプリケーションＣＰＵ７１は、上記ＳＪＩＳのデータフォーマットに変換されたスケジュールデータが上記簡易型電子メールの１パケット当たりの通信データ量（例えば１００バイト）を超えている場合、図７に示すように、当該スケジュールデータを上記１パケットの通信データ量に合わせて複数に分割する。そして、アプリケーションＣＰＵ７１は、それら分割データに対して、簡易型電子メールの送受信に使用されるヘッダ（メールヘッダ）を付加する。上記ヘッダは、図８に示すように、通常の簡易型電子メールであるのか或いは共有されるスケジュールデータを送信するための簡易型電子メールであるのかを示す判別フラグと、このスケジュールを一意に表すスケジュールＩＤ（他の携帯電話装置で受信されたときにもその内部で一意となるＩＤ）と、簡易型電子メールとして送信されるパケットの通し番号であるパケットＩＤと、当該パケットが最終パケットであるのか否かを示す最終パケット判別フラグとからなる。なお、当該ヘッダには、通常の簡易型電子メールに付加されているヘッダ情報、つまり相手先のアドレスや発信元のアドレス等を示す情報も含まれているが、簡略化のために図８にはそれらの情報の図示を省略している。上記ステップＳ８の処理が終了すると、アプリケーションＣＰＵ７１は、ステップＳ９へ処理を進める。
【００４４】
ステップＳ９に進むと、アプリケーションＣＰＵ７１は、上記各分割データ毎のスケジュールデータを、コミュニケーションＣＰＵ６１へ渡し、それら各分割データ毎のスケジュールデータを送信させる。ここで、当該スケジュールデータの送信先は、先のステップＳ６で選択されたグループ内の各電子メールアドレス宛となるため、このステップＳ９にて行われる送信は、図９に示すように、ある携帯電話装置１００Ａから同じ内容を複数の携帯電話装置１００Ｂ〜１００Ｄへ同時に送信する、いわゆる同報メール送信となる。また、当該ステップＳ９のとき、アプリケーションＣＰＵ７１は、図１０に示すように、共有されるスケジュールデータの送信中であることを表すメッセージ（「スケジュール送信中」）とアイコンを画面９６を表示部８２に表示させる。これにより、ユーザは、現在、共有させるスケジュールデータが送信されていることを知ることができる。
【００４５】
また当該ステップＳ９の処理中、アプリケーションＣＰＵ７１は、ステップＳ１０の処理として、全てのパケットの送信が終了したか否かの判断も行う。すなわち、アプリケーションＣＰＵ７１は、ステップＳ１０において、送信すべきパケットの残り数が「０」になったか否かを判断し、残りパケット数が「０」になったとき（全てのパケットの送信が終了したとき）、ステップＳ１１へ処理を進める。
【００４６】
ステップＳ１１に進むと、アプリケーションＣＰＵ７１は、上記送信完了後のスケジュールデータを、内部のスケジュール帳に登録する。また、このときのアプリケーションＣＰＵ７１は、図１１に示すように、スケジュールデータをスケジュール帳に登録したことを表すメッセージ（「スケジュールに登録しました」）のポップアップウィンドウ９８を、画面９０上に表示する。これにより、ユーザは、スケジュールデータの送信と登録が完了したことを知ることができる。
【００４７】
その後、アプリケーションＣＰＵ７１は、図１２に示すような登録完了後のスケジュールを、表示部８２の画面９９に表示する。
【００４８】
［スケジュールデータ受信登録処理ステップ］
次に、上述のようにして、ある携帯電話装置１００Ａから同報メールの形態で送信されたスケジュールデータを、他の携帯電話装置１００Ｂ〜１００Ｄが受信し、それら携帯電話装置１００Ｂ〜１００Ｄ内部において上記受信したスケジュールデータを自己のスケジュールと併合して登録及び閲覧可能にするためのスケジュールデータ受信登録処理ステップの流れを、図１３を用いて説明する。なお、ここでは、上記携帯電話装置１００Ｂ〜１００Ｄのうちの何れか一つ（例えば携帯電話装置１００Ｂ）を挙げて説明している。
【００４９】
図１３において、ステップＳ２１にて携帯電話装置１００Ａから送信されてきた簡易型電子メールのフォーマットのデータを受信すると、当該携帯電話装置１００ＢのアプリケーションＣＰＵ７１は、ステップＳ２２の処理に進む。
【００５０】
ステップＳ２２に進むと、アプリケーションＣＰＵ７１は、上記受信した簡易型電子メールのフォーマットのデータが、通常の簡易型電子メールのデータであるか、或いは共有されるスケジュールデータであるか否かを判定する。すなわちこのときのアプリケーションＣＰＵ７１は、受信したデータのヘッダ（図８のヘッダ）の判別フラグにより上記判定を行う。当該ステップＳ２２において通常の簡易型電子メールのデータであると判定した場合、アプリケーションＣＰＵ７１は、ステップＳ２３の処理として通常の簡易型電子メールの受信処理を行う。一方、ステップＳ２２において共有されるスケジュールデータであると判定した場合、アプリケーションＣＰＵ７１は、ステップＳ２４へ処理を進める。
【００５１】
ステップＳ２４に進むと、アプリケーションＣＰＵ７１は、前記図７のように複数のパケットに分割されたスケジュールデータを、例えばＲＡＭ７４等に順次蓄積させる。
【００５２】
また、上記ステップＳ２２とステップＳ２４の処理中、アプリケーションＣＰＵ７１は、ステップＳ２５の処理として、受信すべき全てのパケットの受信が完了したか否かの判定を行う。すなわちこのときのアプリケーションＣＰＵ７１は、受信したデータのヘッダ（図８のヘッダ）のパケットＩＤと最終パケット判別フラグにより、受信パケット数が受信すべき総パケット数になったか否かを判定する。そして、アプリケーションＣＰＵ７１は、ステップＳ２５において受信すべき全てのパケットの受信が完了したと判定した場合、ステップＳ２６へ処理を進める。
【００５３】
ステップＳ２６に進むと、アプリケーションＣＰＵ７１は、図１４に示すように、上記蓄積した各受信パケットからそれぞれヘッダを除去し、その除去後の各データを併合する。このステップＳ２６でのデータ併合処理が終了すると、アプリケーションＣＰＵ７１は、ステップＳ２７へ処理を進める。
【００５４】
ステップＳ２７に進むと、アプリケーションＣＰＵ７１は、簡易型電子メールのＳＪＩＳフォーマットの状態のスケジュールデータを元のデータフォーマットに戻し、更にステップＳ２８の処理として、そのスケジュールデータを自己のスケジュール帳に登録する。なお、当該送信されてきたスケジュールをスケジュール帳へ登録する際には、必要に応じて、そのスケジュールがどの程度重要であるのかを表す重要度を設定しても良い。当該重要度及びその用途の詳細については後述する。勿論、スケジュールの重要度は、送信側において設定されるものであっても良い。
【００５５】
ここで、上記携帯電話装置１００Ａから送られてきたスケジュールデータを受信して、そのスケジュールデータを自己のスケジュール帳に登録するまでの処理は、当該携帯電話装置１００Ｂ内部で自動的に行われる。また、当該携帯電話装置１００Ｂが待ち受け状態となっていて、表示部８２に例えば図１５のような待ち受け画面１１０が表示されているときに、上記スケジュールデータを受信してその登録がなされると、アプリケーションＣＰＵ７１は、例えば図１６のようなポップアップウィンドウ１１２を待ち受け画面１１０上に表示させる。これにより、当該携帯電話装置１００Ｂのユーザは、スケジュールの共有がなされたことを知ることができる。
【００５６】
そして、例えばユーザによりスケジュール帳の表示指示がなされると、アプリケーションＣＰＵ７１は、例えば図１７に示すような共有されたスケジュールを表す「（共）」の文字が付加されたスケジュール帳画面１１３を表示部８２に表示させる。これにより、当該携帯電話装置１００Ｂのユーザは、どのスケジュールが共有されたものであるのかを知ることができる。
【００５７】
以上説明したように、本実施の形態によれば、各携帯電話装置１００Ａ〜１００Ｄのユーザのスケジュールは、電子メールを介して直接、他の携帯電話装置のスケジュール帳に共有可能に登録される。したがって、本実施の形態の情報通信システムによれば、サーバがスケジュールを一元管理する従来のシステムのように、各携帯電話装置のユーザが他のユーザのスケジュールを閲覧するためにサーバへログインする等のアクセスは不要となり、ユーザの手間や時間の浪費を無くすことができ、さらに、システム管理者を置く必要もないため、システム全体の運営コストを削減できる。また、本実施の形態によれば、各自の携帯電話装置内のスケジュール帳に他のユーザのスケジュールが登録されるため、例えば携帯電話装置が通信圏外に入っていたり電波状態が悪い場合であっても、上記スケジュール帳により他のユーザのスケジュールを何時でも何処でも閲覧することができる。さらに、本実施の形態によれば、他のユーザのスケジュールの共有は自動的に行われるため、ユーザは共有されるスケジュールの登録等の煩雑な操作を行う事なく、極めて簡単且つ何時如何なる場所或いは他のユーザとでも、スケジュールの共有と登録、及び閲覧が可能となり、スケジュール機能をより身近なものとして扱えるようになる。このように、本実施の形態の情報通信システムは、複数人の個々のユーザにより共有可能なスケジュールを容易に登録でき、且つ、各ユーザが他ユーザのスケジュールを容易に閲覧可能となっている。
【００５８】
また、本実施の形態によれば、携帯電話装置１００Ｂ内のスケジュール帳に携帯電話装置１００Ａのユーザ（以下、ユーザＡとする）のスケジュールが登録されていれば、例えば携帯電話装置１００Ｂのユーザ（以下、ユーザＢとする）は、ユーザＡへ電話を掛ける時に、そのスケジュール帳を参照することで、ユーザＡへ電話を掛けても良いかどうかを判断することができる。すなわち例えば、ユーザＡのスケジュールから当該ユーザＡが現在会議中であることがわかった場合、ユーザＢは、電話を掛けことは好ましくないと判断できる。また例えば、ユーザＡのスケジュールから当該ユーザＡが現在休憩中であることがわかった場合、ユーザＢは、電話を掛けても大丈夫であると判断できる。勿論、ユーザＢの携帯電話装置１００ＢにユーザＡのスケジュールが何も登録されていなければ、ユーザＢはユーザＡへ電話を掛けても良いと判断できる。
【００５９】
［アラート表示機能］
さらに、本実施の形態の携帯電話装置は、上記スケジュール帳と通話機能とを連動させることで、電話を掛けても良いか否かの判断をユーザが容易に行えるようにするためのアラート表示機能を備えていても良い。すなわち例えば、携帯電話装置１００ＢのアプリケーションＣＰＵ７１は、ユーザＢがユーザＡへ電話を掛けるための発信操作（発呼操作）を行ったとき、内部のスケジュール帳のデータを参照してユーザＡのスケジュールが登録されているか否かを判定し、当該ユーザＢにより発信要求（発呼要求）がなされた時間とユーザＡのスケジュールの時間とが重なっていることを検出した場合には、ユーザＢに対して注意を促すアラートを表示部８２の画面上に表示させる。これにより、ユーザＢは、自らスケジュール帳の内容を見ることなく、ユーザＡへ電話を掛けても良いか否かを判断することができる。
【００６０】
また、上記アラートは、上記共有されるスケジュールの登録時に設定された重要度に応じて表示されるものであっても良い。ここで、上記重要度は、例えば「０，１，２，…，MAX（MAXは最大値）」等の数値により表されるものである。そして、この場合のアプリケーションＣＰＵ７１は、ユーザＢにより発信操作が行われたとき、先ずその発信先のユーザＡのスケジュールが登録されているか否かの判断を行い、登録されているときにはそのスケジュールに設定されている重要度の値を元に、発信を中止するか否かの判断を行うと同時に、アラート表示を行うか否か、アラートを何回表示するか、或いは、数種類のうちの何れのアラートを表示するか等の判断を行う。なお、本実施の形態において、携帯電話装置１００ＢのアプリケーションＣＰＵ７１は、例えば重要度「０」のときアラートを表示させず、ユーザＢの電話発信要求に対してはユーザＡのスケジュール内容によらずにその電話発信を許可するものとする。また、アプリケーションＣＰＵ７１は、例えば重要度「１」のときにはアラートを１回表示させると共にユーザＢによる発信要求を拒否し、当該アラート表示後にユーザＢからユーザＡへ再度発信要求が行われたときにはその電話発信を許可することにする。またアプリケーションＣＰＵ７１は、例えば重要度「２」のときにはアラートを１回表示させると共にユーザＢによる発信要求を拒否し、そのアラート表示後にユーザＢからユーザＡへ再度発信要求がなされたときにはもう一度アラートを表示（合計２回のアラート表示）させると共に当該発信要求を再度拒否し、さらに、当該２回目のアラート表示の後にユーザＢからユーザＡへ再度発信要求（合計３回の発信要求）がなされたときにはその電話発信を許可することにする。以下同様とする。そして、アプリケーションＣＰＵ７１は、例えば重要度「MAX」のときには、ユーザＡのスケジュールが終了するまでユーザＢからの全ての発信要求を拒否すると共に、その旨のアラートを表示させることとする。
【００６１】
以下、図１８を用い、上記スケジュールの重要度に応じたアラート表示と発信制限の流れを説明する。
【００６２】
図１８のステップＳ３１において、携帯電話装置１００ＢのアプリケーションＣＰＵ７１は、ユーザＢによるキー操作部７６の操作信号により他のユーザＡの携帯電話装置１００Ａへの発信要求を受け取ると、ステップＳ３２へ処理を進める。
【００６３】
ステップＳ３２に進むと、アプリケーションＣＰＵ７１は、自己のスケジュール帳に登録されているスケジュールのうち、他のユーザにより共有されているスケジュールを参照し、次のステップＳ３３において上記発信先の携帯電話装置１００ＡのユーザＡに対応したスケジュールが登録されているか否か、及び、スケジュールが登録されていた場合にはそのスケジュールの重要度の値が「０」であるか否かの判定を行う。このステップＳ３３において、発信先のユーザＡに対応したスケジュールが自己のスケジュール帳内に登録されていないとき、若しくは、登録されていてもそのスケジュールの重要度の値が「０」であるとき、アプリケーションＣＰＵ７１は、ステップＳ４０へ処理を進め、上記ユーザＢの発信要求に応じた通常の電話発信処理を行う。一方、ステップＳ３３において、発信先のユーザＡのスケジュールが自己のスケジュール帳内に登録されており、且つ、そのスケジュールの重要度の値が「０」より大きいと判定した場合、アプリケーションＣＰＵ７１は、ステップＳ３４において、発信を中止し、次のステップＳ３５以降へ処理を進める。
【００６４】
ステップＳ３５において、アプリケーションＣＰＵ７１は、上記発信先のユーザＡに対応したスケジュールの重要度の値が「MAX」か否かを判定し、「MAX」である場合にはステップＳ３６へ処理を進め、「MAX」でない場合にはステップＳ３７へ処理を進める。
【００６５】
ステップＳ３５において重要度の値が「MAX」と判定されてステップＳ３６へ進むと、アプリケーションＣＰＵ７１は、ユーザＡのスケジュールが終了するまでユーザＢからの発信要求を拒否する旨のアラートを、表示部８２に表示させて処理を終了する。
【００６６】
一方、ステップＳ３７に進むと、アプリケーションＣＰＵ７１は、重要度の値に応じてユーザＢからの発信要求を拒否すると共に、例えば図１９に示すようなポップアップアラート１１５を表示部８２に表示させる。すなわちこの図１９に示すポップアップアラート１１５は、発信相手先のユーザのスケジュールの内容に応じた文字メッセージ（例えば「会議中ですよ！！  いいの？」）が表示されるメッセージ表示エリア１１６と、再度の発信を行うか否かの諾否（例えば「はい」、「いいえ」）をユーザに確認する確認エリア１１７，１１８とからなる。そして、アプリケーションＣＰＵ７１は、例えばユーザＢによるキー操作部７６の操作子の操作（例えばジョグダイヤル回転操作）に応じて、上記確認エリア１１７，１１８の何れか一方を選択可能状態とし、さらに、ユーザＢによる操作子の操作（例えばジョグダイヤルのプッシュ操作）に応じて、上記選択可能状態となされている方のエリアの選択を確定する。なお、選択可能状態となっている確認エリア１１７又は１１８は、例えばハイライト表示される。これにより、ユーザＢは、何れの確認エリアが選択可能であるのかを知ることができる。
【００６７】
そして、アプリケーションＣＰＵ７１は、次のステップＳ３８にて、ユーザＢにより上記「はい」又は「いいえ」の確認エリア１１７、１１８の何れが選択されたか判定する。このステップＳ３８において、上記「いいえ」の確認エリア１１８が選択されたと判断した場合、アプリケーションＣＰＵ７１はこの図１８の処理を終了する。一方、ステップＳ３８において、上記「はい」の確認エリア１１７が選択されたと判断した場合、つまり発信する旨の指示がなされた場合、アプリケーションＣＰＵ７１は、ステップＳ３９へ処理を進める。
【００６８】
ステップＳ３９へ進むと、アプリケーションＣＰＵ７１は、アラート表示の回数が重要度の値を超えたかか否か判定し、アラート表示回数が重要度の値以下のときにはステップＳ３７へ処理を戻す。一方、ステップＳ３９において、アラート表示回数が重要度の値を超えることになった時、アプリケーションＣＰＵ７１は、ステップＳ４０へ処理を進め、上記ユーザＢの発信要求に応じた電話発信処理を行う。
【００６９】
上述の説明によれば、上記スケジュールの共有機能とアラート表示の機能は、ユーザＢがユーザＡへ電話を掛けるか否かの判断に用いられているが、本発明はその逆の用途にも使用可能である。すなわち、本実施の形態のスケジュール共有機能とアラート表示機能によれば、例えばユーザＡが自分のスケジュールを予め他のユーザ（ユーザＢ等）の携帯電話装置へ送信して登録させておくことで、ユーザＡは、電話を掛けて欲しくない時間帯を、他のユーザへ直接連絡することなく知らせることができることになる。
【００７０】
なお、上述した実施の形態の説明は、本発明の一例である。このため、本発明は上述した実施の形態に限定されることなく、本発明に係る技術的思想を逸脱しない範囲であれば、設計等に応じて種々の変更が可能であることはもちろんである。
【００７１】
本発明実施の形態では、スケジュール送信の手段として簡易型電子メールシステムを例に挙げているが、本発明はそれに限定される物ではない。一般の電子メールシステムを用いて実現することも勿論可能である。なお、一般の電子メールシステムを用いた場合、前述したスケジュールデータの分割や併合の処理は不要となる。
【００７２】
また本実施の形態では、スケジュールの共有や登録等、或いはアラートをユーザに知らせるためにポップアップウィンドウを表示する例を挙げたが、本発明はこれに限定されず、例えばそれぞれ対応したアイコンの表示や音声によりそれらをユーザに知らせるようにしても良い。
【００７３】
【発明の効果】
本発明によれば、他のユーザの情報通信装置から送信されてきたスケジュールデータを自己の情報通信装置のスケジュール帳へ自動登録可能にしているため、複数人の個々のユーザは共有スケジュールを容易に登録でき、且つ、各ユーザが他ユーザのスケジュールを容易に閲覧可能である。
【図面の簡単な説明】
【図１】本発明の携帯電話装置の概略構成を示すブロック図である。
【図２】本実施の形態のスケジュール共有プログラムのうち、スケジュールデータ送信処理ステップの流れを示すフローチャートである。
【図３】スケジュール作成編集処理ステップにより作成若しくは編集された後のスケジュールの内容を表示した画面例を示す図である。
【図４】自己のスケジュールを他のユーザへ共有させるか否かの確認用ポップアップウィンドウが表示された画面例を示す図である。
【図５】送信先グループの選択画面例を示す図である。
【図６】メッセージデータのデータ構造を示す図である。
【図７】スケジュールデータの分割の様子を説明するための図である。
【図８】分割されたスケジュールデータに付加されるヘッダの説明に用いる図である。
【図９】同報メールの形式でスケジュールデータを送信する概念の説明に用いる図である。
【図１０】共有スケジュールデータの送信中のメッセージ表示画面例を示す図である。
【図１１】スケジュール登録の確認用ポップアップウィンドウが表示された画面例を示す図である。
【図１２】共有スケジュールデータの送信後に登録が完了したスケジュールの表示画面例を示す図である。
【図１３】本実施の形態のスケジュール共有プログラムのうち、スケジュールデータ受信登録処理ステップの流れを示すフローチャートである。
【図１４】分割されたスケジュールデータを併合する様子を説明するための図である。
【図１５】待ち受け画面例を示す図である。
【図１６】受信側の携帯電話装置において、共有スケジュールの登録がなされたことの確認用ポップアップウィンドウが表示された画面例を示す図である。
【図１７】受信側の携帯電話装置において、共有スケジュールが登録された後のスケジュール内容の表示画面例を示す図である。
【図１８】スケジュールの重要度に応じたアラート表示と発信制限の流れを示すフローチャートである。
【図１９】ポップアップアラートが表示された画面例を示す図である。
【符号の説明】
２１…送受信信号処理部、２２…コミュニケーション処理部、２３…アプリケーション制御処理部、６１…コミュニケーションＣＰＵ、７１…アプリケーションＣＰＵ、８２…表示部、９０，９５，９６，９９，１１０，１１３…表示部の画面、９１，９８，１１２…ポップアップウィンドウ、１００Ａ〜１００Ｄ…携帯電話装置、１１５…ポップアップアラート
【図１】
2004199224.tif 000003
【図２】
2004199224.tif 000004
【図３】
2004199224.tif 000005
【図４】
2004199224.tif 000006
【図５】
2004199224.tif 000007
【図６】
2004199224.tif 000008
【図７】
2004199224.tif 000009
【図８】
2004199224.tif 000010
【図９】
2004199224.tif 000011
【図１０】
2004199224.tif 000012
【図１１】
2004199224.tif 000013
【図１２】
2004199224.tif 000014
【図１３】
2004199224.tif 000015
【図１４】
2004199224.tif 000016
【図１５】
2004199224.tif 000017
【図１６】
2004199224.tif 000018
【図１７】
2004199224.tif 000019
【図１８】
2004199224.tif 000020
【図１９】
2004199224.tif 000021